Netapp

Instalación y configuración de Ontap Mediator de NetApp

Hol@ a todos,

El día de hoy estaré hablando un poco de como instalar y configurar la aplicación de “Ontap Mediator” que es utilizado como una vía alterna para validar el estado de salud de un conjunto de clúster. Para establecer el rol de esta aplicación utilizaré como referencia la documentación del portal de NetApp:

ONTAP Mediator provides an alternate health path to the peer cluster, with the intercluster LIFs providing the other health path. With the Mediator’s health information, clusters can differentiate between intercluster LIF failure and site failure. When the site goes down, Mediator passes on the health information to the peer cluster on demand, facilitating the peer cluster to fail over. With the Mediator-provided information and the intercluster LIF health check information, ONTAP determines whether to perform an auto failover, if it is failover incapable, continue or stop.

Role of ONTAP Mediator

Esta aplicación puede ser utilizada en escenarios de “MetroCluster” como también con la tecnología de “SnapMirror Business Continuity” (SM-BC). A partir de ONTAP 9.8, “SnapMirror Business Continuity” (SM-BC) puedes ser utilizado para proteger las aplicaciones con LUNs, permitiendo que las aplicaciones puedan migrar de forma transparente, asegurando la continuidad del negocio en caso de desastre. SM-BC utiliza la tecnología de “SnapMirror Synchronous” que permite replicar los datos hacia el destino tan pronto como se escriben en el volumen de origen.

En este laboratorio instalaremos la aplicación Mediator con el propósito de en el futuro poder realizar un laboratorio sobre SM-BC en un ambiente de VMware. La siguiente imagen muestra el rol que posee el Ontap Mediator dentro del diseño de la tecnología de SM-BC.

Como pueden ver el “Mediator” esta constantemente evaluando el estado del Datacenter para identificar posibles fallas y poder reaccionar migrando el acceso a los volumenes al Datacenter que este en función. Puede ser útil entender algunos de los conceptos básicos de recuperación y restauración de SM-BC.

Recuperación planificada:

Una operación manual para cambiar los roles de acceso a los volúmenes en una relación SM-BC. El primario pasa a ser el secundario y el secundario pasa a ser el primario. El reporte del estado de ALUA también es modificado según el estado de la relación.

Recuperación automática no planificada (AUFO):

Una operación automática para realizar una conmutación por error a la copia espejo. La operación requiere la asistencia del Ontap Mediator para detectar que la copia primaria no está disponible.

A continuación les incluyo los requisitos para instalar la aplicación. Para ver el contenido, basta con hacer clic en el icono “+”.

Requisitos

Para validar la lista completa de requisitos puede visitar la documentación de “Ontap Mediator”

Para este laboratorio estaré utilizando Red Hat Enterprise Linux 8.1 corriendo en en una VM de vSphere. Lo primero que debemos hacer es descargar el paquete de instalación de la aplicación. Para esto accedemos el portal de soporte de NetApp según se muestra en la próxima imagen.

Enlace de Ontap Mediator:

https://mysupport.netapp.com/site/products/all/details/ontap-mediator/downloads-tab

Una vez descargado el paquete de instalación copiamos el archivo “ONTAP-MEDIATOR-1.3” al servidor que utilizaremos para este propósito. Luego procedemos a cambiar el archivo de instalación a modo ejecutable con el comando <chmod +x>.

[root@NTAPMED-01V ~]# ls
anaconda-ks.cfg  ONTAP-MEDIATOR-1.3
[root@NTAPMED-01V ~]# chmod +x ONTAP-MEDIATOR-1.3 
[root@NTAPMED-01V ~]#

Ahora procedemos a instalar las dependencias de la aplicación con el comando yum install según se muestra a continuación.

[root@NTAPMED-01V ~]# yum install openssl openssl-devel kernel-devel gcc libselinux-utils make redhat-lsb-core patch bzip2 python36 python36-devel perl-Data-Dumper perl-ExtUtils-MakeMaker python3-pip elfutils-libelf-devel policycoreutils-python-utils -y
Last metadata expiration check: 0:13:59 ago on Tue 29 Jun 2021 10:01:36 PM AST.
Package openssl-1:1.1.1g-15.el8_3.x86_64 is already installed.
Package libselinux-utils-2.9-5.el8.x86_64 is already installed.
Dependencies resolved.
...............
Installed:

Really long Output                                                              

Complete!
[root@NTAPMED-01V ~]#

Una vez hayamos instalado las dependencia podemos comenzar a ejecutar el archivo de instalación de la aplicación. Para este propósito utilizaremos el comando <./ONTAP-MEDIATOR-1.3>.

Nota: Este comando debe ejecutarse en el lugar donde este guardado el archivo de instalación.

[root@NTAPMED-01V ~]# ./ONTAP-MEDIATOR-1.3 

ONTAP Mediator: Self Extracting Installer

ONTAP Mediator requires two user accounts. One for the service (netapp), and one for use by ONTAP to the mediator API (mediatoradmin).
Would you like to use the default account names: netapp + mediatoradmin? (Y(es)/n(o)): Yes
Enter ONTAP Mediator user account (mediatoradmin) password: XXXXXX 

Re-Enter ONTAP Mediator user account (mediatoradmin) password: XXXXX

Checking if SELinux is in enforcing mode
SELinux is set to Enforcing. ONTAP Mediator server requires modifying the SELinux context of the file
/opt/netapp/lib/ontap_mediator/pyenv/bin/uwsgi from type 'lib_t' to 'bin_t'.
This is neccessary to start the ONTAP Mediator service while SELinux is set to Enforcing.
Allow SELinux context change?  Y(es)/n(o): Yes
The installer will change the SELinux context type of
/opt/netapp/lib/ontap_mediator/pyenv/bin/uwsgi from type 'lib_t' to 'bin_t'.




Checking for default Linux firewall
Linux firewall is running. Open ports 31784 and 3260? Y(es)/n(o): Yes
success
success
success


###############################################################
Preparing for installation of ONTAP Mediator packages.


Do you wish to continue? Y(es)/n(o): 

El instalador nos realizara varias preguntas sobre la contraseña de los usuarios utilizados por el servicio de ONTAP Mediator y los puertos TCP que se abrirán en el “Firewall” local del servidor. Una vez todo este debidamente especificado el instalador validara que todos los pre-requisitos de la aplicación estén instalados.

Do you wish to continue? Y(es)/n(o): Y


+ Installing required packages.


Updating Subscription Management repositories.

Really long Output                                                              

Dependencies resolved.
Nothing to do.
Complete!
OS package installations finished
+ Installing ONTAP Mediator. (Log: /tmp/ontap_mediator.7atkl8/ontap-mediator/install_20210709162016.log)
    This step will take several minutes. Use the log file to view progress.
#includedir /etc/sudoers.d
Sudo include verified
ONTAP Mediator logging enabled
+ Install successful. (Moving log to /opt/netapp/lib/ontap_mediator/log/install_20210709162016.log)
+ Note: ONTAP Mediator uses a kernel module compiled specifically for the current
        system OS. Using 'yum update' to upgrade the kernel may cause a service
        interruption.
    For more information, see /opt/netapp/lib/ontap_mediator/README
[root@NTAPMED-01V ~]#

Una vez instalada la aplicación es importante validar que los servicio del Ontap Mediator estén activados y funcionales. Para validar los servicio utilizamos el comando <systemctl status ontap_mediator mediator-scst>.

[root@NTAPMED-01V ~]# systemctl status ontap_mediator mediator-scst
 ontap_mediator.service - ONTAP Mediator
   Loaded: loaded (/etc/systemd/system/ontap_mediator.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2021-07-09 14:21:31 AST; 11min ago
  Process: 1296 ExecStop=/bin/kill -s INT $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 1298 (uwsgi)
   Status: "uWSGI is ready"
    Tasks: 3 (limit: 23832)
   Memory: 61.4M
 Started ONTAP Mediator.

 mediator-scst.service
   Loaded: loaded (/etc/systemd/system/mediator-scst.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2021-07-09 14:21:30 AST; 11min ago
  Process: 1164 ExecStart=/etc/init.d/scst start (code=exited, status=0/SUCCESS)
 Main PID: 1250 (iscsi-scstd)
    Tasks: 1 (limit: 23832)
   Memory: 3.3M
 Started mediator-scst.service.
[root@NTAPMED-01V ~]# 

Adicionalmente es importante validar que los servicios estén utilizando los puertos correctos. Con el comando <netstat -anlt | grep -E ‘3260|31784’> podemos validar que los puertos 3260 y 31784 este en modo “LISTEN”.

[root@NTAPMED-01V ~]# netstat -anlt | grep -E '3260|31784'
tcp        0      0 0.0.0.0:3260            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:31784           0.0.0.0:*               LISTEN     
tcp6       0      0 :::3260                 :::*                    LISTEN     
[root@NTAPMED-01V ~]# 

Con el comando <firewall-cmd –list-all> podemos validar que las reglas para los puertos 31784/tcp y 3260/tcp estén configurados en el “Firewall” local del servidor.

[root@NTAPMED-01V ~]# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources: 
  services: cockpit dhcpv6-client ssh
  ports: 31784/tcp 3260/tcp
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
	
[root@NTAPMED-01V ~]# 

Luego de culminado el proceso de instalación pasamos a añadir el Ontap Mediator a la configuración de los cluster donde deseamos utilizar la tecnología de “SnapMirror Business Continuity” (SM-BC). Para añadir la configuración es necesario ir a [Protection] => [Overview] => [Mediator] => [Configure]. Luego hay que añadir la configuración según se muestra en la siguientes imágenes. Es importante mencionar que el certificado que se añade en esta configuración es el del CA que se encuentra en:

/opt/netapp/lib/ontap_mediator/ontap_mediator/server_config/ca.crt

Nota: Es importante mencionar que para que esta configuración funciones debe de existir una relación de “cluster peer” y “vserver peer” previamente establecida.

Por consola también podemos validar que la configuración del Ontap Mediator este funcionando correctamente. Con el comando <snapmirror mediator show> podemos validar que el estado de la conexión esta “connected” y el “Quorum Status” esta en “true”.

Nota: Este comando debe de ser utilizado en ambos cluster para validar que la conexión esta correctamente establecida.

OnPrem-HQ::> snapmirror mediator show                    
Mediator Address Peer Cluster     Connection Status Quorum Status
---------------- ---------------- ----------------- -------------
192.168.6.16     OnPrem-DR       connected         true

OnPrem-HQ::*> 
OnPrem-DR::> snapmirror mediator show
Mediator Address Peer Cluster     Connection Status Quorum Status
---------------- ---------------- ----------------- -------------
192.168.6.16     OnPrem-HQ       connected       true

OnPrem-DR::> 

A continuación les incluyo como añadir al cluster el Ontap Mediator utilizando el modo de consola de Ontap. Para ver el contenido, basta con hacer clic en el icono “+”.

Ontap Mediator CLI Setup

Con el comando snapmirror mediator add añadimos el Ontap Mediator con la dirección IP de 192.168.6.16 al cluster Onprem-HQ. Es importante mencionar que para que esta configuración funciones debe de existir una relación de “Cluster peer” y “Vserver peer” previamente establecida.

OnPrem-HQ::> snapmirror mediator add -mediator-address 192.168.7.167 -peer-cluster OnPrem-DR -username mediatoradmin 

Notice: Enter the mediator password.

Enter the password: XXXXX
Enter the password again: XXXXX

Info: [Job: 171] 'mediator add' job queued 

OnPrem-HQ::> 

Con el comando snapmirror mediator show podemos validar que el estado de la conexión esta “connected” y el “Quorum Status” esta en “true”.

OnPrem-HQ::> snapmirror mediator show                    
Mediator Address Peer Cluster     Connection Status Quorum Status
---------------- ---------------- ----------------- -------------
192.168.6.16     OnPrem-DR       connected         true

OnPrem-HQ::*> 
OnPrem-DR::> snapmirror mediator show
Mediator Address Peer Cluster     Connection Status Quorum Status
---------------- ---------------- ----------------- -------------
192.168.6.16     OnPrem-HQ       connected       true

OnPrem-DR::> 

Adicionalmente les muestro como remplazar el certificado SSL del servicio de Ontap Mediator por uno generado de un “Certificate Authority” de Microsoft. Para ver el contenido, basta con hacer clic en el icono “+”.

Opcional Remplazo Certificado SSL

Paso1: Generar un archivo de configuración para crear el “Certificate Signing Request” (CSR). En este paso es importante establecer el CN y DNS con el “fully qualified domain name” (FQDN) del nombre del servidor. En mi caso el nombre del servidor es NTAPMED-01V

[root@NTAPMED-01V ~]# nano -w req.conf 
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = PR
L = SJ
O = Zen PR Solutions
OU = IT
CN = NTAPMED-01V
[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = NTAPMED-01V.zenprsolutions.local

Paso2: Utilizar el comando openssl para generar el archivo CSR que utilizaremos como plantilla para crear el certificado que utilizaremos para el servicio de Ontap Mediator.

Nota: Si el comando openssl no esta disponible en el sistema puede utilizar el comando yum install openssl para instalar los paquetes necesarios.

[root@NTAPMED-01V ~]# openssl req -new -out ntapmed.csr -newkey rsa:2048 -nodes -sha256 -keyout ntapmed.key -config req.conf

Una vez ejecutado el comando openssl se crearan dos archivos el ntapmed.csr es la plantilla que utilizaremos para generar el certificado y el ntapmed.key es la llave privada.

[root@NTAPMED-01V ~]# ls -al ntapmed.*
-rw-r--r-- 1 root      root      1123 Jul  9 16:53 ntapmed.csr #Certificate Signing Request
-rw-r--r-- 1 rebelinux rebelinux 1704 Jul  9 16:53 ntapmed.key #Private Key
[root@rebelpc rebelinux]# 

Paso 3: Acceder al servidor de “Certificate Authority” de Microsoft y utilizar el comando certreq.exe para generar el certificado utilizando el archivo ntapmed.csr como plantilla

C:\>certreq.exe -submit -attrib "CertificateTemplate:WebServer" ntapmed.csr ntapmed.cer

Una vez culmine el proceso se creara un archivo con el nombre de ntapmed.cer que utilizaremos para el servicio de Ontap Mediator.

Paso 4: Para remplazar el certificado SSL es necesario también cambiar el certificado publico del CA . Para obtener este certificado del CA utilizamos el comando certutil -ca.cert ca.cer que nos producirá el certificado en el archivo ca.cer.

C:\>certutil -ca.cert ca.cer

Una vez culminado este proceso copiamos todos los archivos (ca.cer, ntapmed.cer y ntapmed.key) al servidor de Ontap Mediator.

Paso 5: Movernos a la carpeta /opt/netapp/lib/ontap_mediator/ontap_mediator/server_config/ y modificar los archivos de los certificados segun se muestra a continuacion.

[root@NTAPMED-01V ~]# cd /opt/netapp/lib/ontap_mediator/ontap_mediator/server_config/
[root@NTAPMED-01V server_config]# ls
ca.crt  ca.srl            config.pyc    logging.conf.yaml  ontap_mediator.config.yaml     ontap_mediator_schema.yaml  ontap_mediator_server.csr  ontap_mediator.user_config.yaml
ca.key  config_migration  __init__.pyc  netapp_sudoers     ontap_mediator.constants.yaml  ontap_mediator_server.crt   ontap_mediator_server.key
[root@NTAPMED-01V server_config]# cp -R /opt/netapp/lib/ontap_mediator/ontap_mediator/server_config /root/
[root@NTAPMED-01V server_config]#
[root@NTAPMED-01V server_config]# nano -w ca.crt
[root@NTAPMED-01V server_config]# openssl x509 -noout -serial -in ca.crt 
serial=5D2E25D9AFFDE4904A05D70BEB7ACBD2
[root@NTAPMED-01V server_config]# 
[root@NTAPMED-01V server_config]# nano -w ontap_mediator_server.crt
[root@NTAPMED-01V server_config]# nano -w ontap_mediator_server.key

Una vez realizado los cambios es necesario reiniciar los servicios utilizando el comando systemctl restart ontap_mediator mediator-scst

[root@NTAPMED-01V server_config]# systemctl restart ontap_mediator mediator-scst
[root@NTAPMED-01V server_config]# systemctl status ontap_mediator mediator-scst
 ontap_mediator.service - ONTAP Mediator
   Loaded: loaded (/etc/systemd/system/ontap_mediator.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2021-07-09 20:31:48 AST; 8s ago
  Process: 22222 ExecStop=/bin/kill -s INT $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 22232 (uwsgi)
   Status: "uWSGI is ready"
    Tasks: 3 (limit: 23832)
   Memory: 56.5M

 mediator-scst.service
   Loaded: loaded (/etc/systemd/system/mediator-scst.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2021-07-09 20:31:50 AST; 5s ago
  Process: 22223 ExecStop=/etc/init.d/scst stop (code=exited, status=0/SUCCESS)
  Process: 22309 ExecStart=/etc/init.d/scst start (code=exited, status=0/SUCCESS)
 Main PID: 22389 (iscsi-scstd)
    Tasks: 1 (limit: 23832)
   Memory: 1.0M

Resumen

En este laboratorio instalamos y configuramos el Ontap Mediator que utilizaremos en un futuro para realizar un laboratorio sobre “SnapMirror Business Continuity” (SM-BC) junto con VMware. Espero que este laboratorio les haya gustado. Si tienes dudas o alguna pregunta sobre este laboratorio, déjalo en los comentarios. Saludos.

Snapshots Nativos en NFS con vSphere 7 Update 2

La versión vSphere 7.0 U2 ofrece la posibilidad de utilizar snapshots nativos cuando se utiliza el protocolo NFS como mecanismo de acceso. Como se describe en el blog de VMware:

Mejoras en NFS

NFS required a clone to be created first for a newly created VM and the subsequent ones could be offloaded to the array. With the release of vSphere 7.0 U2, we have enabled NFS array snapshots of full, non-cloned VMs to not use redo logs but instead use the snapshot technology of the NFS array in order to provide better snapshot performance. The improvement here will remove the requirement/limitation of creating a clone and enables the first snapshot also to be offloaded to the array.

What’s New in vSphere 7 Update 2 Core Storage

En este blog explico la configuración necesaria para probar esta nueva funcionalidad. Para empezar debemos validar los requisitos para poder implementar esta solución. Según el portal de documentación de VMware los requisitorios son los siguientes:

  • Compruebe que la matriz NAS admite la operación de clonación rápida de archivos con el programa VAAI NAS.
  • En su host ESXi, instale el plug-in NAS específico del proveedor que soporta la clonación rápida de archivos con VAAI.
  • Siga las recomendaciones de su proveedor de almacenamiento NAS para configurar los ajustes necesarios tanto en la matriz NAS como en ESXi.

La configuración de NFS se realizará en NetApp Ontap mediante el complemento “NetApp NFS Plug-in for VMware VAAI”, que recientemente ha añadido soporte nativo para la descarga de snapshot en NFS.

Note: El plug-in puede descargarse desde el portal de soporte de NetApp en el siguiente enlace “NetApp Support”.

Una vez que estemos en el portal de soporte de NetApp debemos descargar la versión 2.0 del plugin como se muestra en la siguiente imagen. Para instalar el plugin debemos descomprimir el archivo descargado y renombrar el archivo dentro de la carpeta llamada vib20 con la extensión .vib al nuevo nombre NetAppNasPlugin.vib.

En el siguiente paso utilicé el Ontap Tools de NetApp para instalar el plugin, pero también se puede instalar utilizando VMware Lifecycle Manager.

Para instalar el plugin vaya a [ONTAP tools => Settings => NFS VAAI tools] y en la sección “Existing version:” pulse “BROWSE” para seleccionar donde está almacenado el archivo “NetAppNasPlugin.vib”. Una vez localizado el archivo pulse “UPLOAD” para cargar e instalar el plugin.

En este paso podemos ver cómo instalar el plugin en los servidores ESXi pulsando el botón “INSTALL”.

La siguiente imagen muestra que la instalación del plugin fue exitosa. Una ventaja de la nueva versión del plugin es que no es necesario reiniciar el servidor ESXi.

Una vez instalado el plugin procederemos a validar que Ontap tiene soporte para las características de VMware vStorage APIs for Array Integration (VAAI) en el ambiente de NFS. Esto se puede verificar con el comando <vserver nfs show -fields vstorage>. Como puede ver la función vStorage está actualmente deshabilitada en el SVM llamado NFS. Para habilitar la función vStorage utilice el comando <vserver nfs modify -vstorage enabled>.

OnPrem-HQ::> vserver nfs show -fields vstorage 
vserver vstorage 
------- -------- 
NFS     disabled  

OnPrem-HQ::> vserver nfs modify -vstorage enabled -vserver NFS 

OnPrem-HQ::> vserver nfs show -fields vstorage                 
vserver vstorage 
------- -------- 
NFS     enabled  

OnPrem-HQ::> 

El siguiente requisito para poder utilizar la descarga nativa de snapshot es la creación de un ajuste avanzado en la configuración de la VM llamado <snapshot.alwaysAllowNative>. Para añadir este valor hay que ir a las propiedades de la VM y luego a [VM Options => Advanced => EDIT CONFIGURATION].

La siguiente imagen muestra el valor de la variable <snapshot.alwaysAllowNative> que según la documentación de VMware debe tener un valor igual a “TRUE”. Puede utilizar el siguiente enlace como referencia “VMware Documentation”

Ahora empiezo a hacer pruebas para validar que los snapshots nativo funcionan en Ontap. Primero crearé un snapshot con la función <snapshot.alwaysAllowNative> establecida en “FALSE”. Luego haré cambios en la VM para poder medir la velocidad de eliminación y aplicación de los cambios del snapshot al disco base. En el ejemplo que se muestra a continuación se utilizó el comando <New-Snapshot> en PowerCLI para crear una snapshot de la VM llamada RocaWeb

PS /home/rebelinux> get-vm -Name RocaWeb | New-Snapshot -Name PRE_Native_Array_Snapshot | Format-Table -Wrap -AutoSize  
                                                                                                                                                                                                                                               Name                      Description PowerState                                                                                                                                                                                               ----                      ----------- ----------                                                                                                                                                                                               PRE_Native_Array_Snapshot             PoweredOff                                                                                                                                                                                                                                                                                                                                                                                                                                              
PS /home/rebelinux> 

En este paso se ha copiado un archivo de 10GB para hacer crecer el snapshot y así poder medir la rapidez con la que se aplican los cambios al disco base cuando se elimina el snapshot. En este ejemplo el archivo “RocaWeb_2-000001-delta.vmdk” representa el delta donde se guardan los cambios del snapshot. Esto representa un snapshot tradicional de VMware.

[root@comp-01a:/vmfs/volumes/55ab62ec-2abeb31b/RocaWeb] ls -alh
total 35180596
drwxr-xr-x    2 root     root        4.0K May 31 23:40 .
drwxr-xr-x    7 root     root        4.0K May 31 19:02 ..
-rw-------    1 root     root      276.0K May 31 23:40 RocaWeb-Snapshot15.vmsn
-rw-------    1 root     root        4.0G May 31 23:40 RocaWeb-a03f2017.vswp
-rw-------    1 root     root      264.5K May 31 23:40 RocaWeb.nvram
-rw-------    1 root     root         394 May 31 23:40 RocaWeb.vmsd
-rwxr-xr-x    1 root     root        3.4K May 31 23:40 RocaWeb.vmx
-rw-------    1 root     root       10.0G May 31 23:51 RocaWeb_2-000001-delta.vmdk #Delta (VMFS Based Snapshot)
-rw-------    1 root     root         301 May 31 23:40 RocaWeb_2-000001.vmdk
-rw-------    1 root     root      500.0G May 31 23:37 RocaWeb_2-flat.vmdk
-rw-------    1 root     root         631 May 31 23:37 RocaWeb_2.vmdk
[root@comp-01a:/vmfs/volumes/55ab62ec-2abeb31b/RocaWeb]

La siguiente imagen muestra el tiempo que se tardó en aplicar los cambios del snapshot al disco base cuando se eliminó el snapshot. En resumen, la operación tardó 9 minutos en total utilizando snapshots tradicionales de VMware.

Note: El simulador de Ontap fue utilizado para el laboratorio.

En este último ejemplo también se utilizó el comando <New-Snapshot> para crear el snapshot pero con la opción <snapshot.alwaysAllowNative> establecida en “TRUE”. De esta manera podemos probar el uso de “Native Snapshot Offload” en NFS. Aquí también se copió un archivo de 10GB a la VM para hacer crecer el snapshot, de modo que podamos medir la rapidez con la que se aplican los cambios al disco base cuando se elimina el snapshot.

PS /home/rebelinux> get-vm -Name RocaWeb | New-Snapshot -Name POST_Native_Array_Snapshot | Format-Table -Wrap -AutoSize
                                                                                                                                                                                                                                               Name                       Description PowerState                                                                                                                                                                                              ----                       ----------- ----------                                                                                                                                                                                              POST_Native_Array_Snapshot             PoweredOff                                                                                                                                                                                                                                                                                                                                                                                                                                             
PS /home/rebelinux> 

Aquí podemos ver que no hay ningún archivo “-delta.vmdk” pero hay un archivo llamado “RocaWeb_2-000001-flat.vmdk” con el mismo tamaño de 500GB que el archivo “RocaWeb_2-flat.vmdk”. Esto nos permite confirmar que la función “NFS Native Snapshot Offload” está habilitada en Ontap.

[root@comp-01a:/vmfs/volumes/55ab62ec-2abeb31b/RocaWeb] ls -alh
total 49419672
drwxr-xr-x    2 root     root        4.0K Jun  1 00:07 .
drwxr-xr-x    7 root     root        4.0K May 31 19:02 ..
-rw-------    1 root     root      276.0K Jun  1 00:07 RocaWeb-Snapshot16.vmsn
-rw-------    1 root     root        4.0G Jun  1 00:07 RocaWeb-a03f2017.vswp
-rw-------    1 root     root      264.5K Jun  1 00:07 RocaWeb.nvram
-rw-------    1 root     root         393 Jun  1 00:07 RocaWeb.vmsd
-rwxr-xr-x    1 root     root        3.4K Jun  1 00:07 RocaWeb.vmx
-rw-------    1 root     root      500.0G Jun  1 00:09 RocaWeb_2-000001-flat.vmdk #No Delta (Array Based Snapshot OffLoad)
-rw-------    1 root     root         650 Jun  1 00:07 RocaWeb_2-000001.vmdk
-rw-------    1 root     root      500.0G Jun  1 00:03 RocaWeb_2-flat.vmdk
-rw-------    1 root     root         631 Jun  1 00:07 RocaWeb_2.vmdk
[root@comp-01a:/vmfs/volumes/55ab62ec-2abeb31b/RocaWeb] 

La siguiente imagen muestra el tiempo que se tardó en aplicar los cambios del snapshot al disco base cuando se eliminó el snapshot utilizando “NFS Native Snapshot Offload”. En resumen, se puede ver que la aplicación de los cambios del snapshot al disco base no tardó nada en terminar.

Resumen

Las operaciones con “NFS native snapshot offload” son tan rápidas porque ONTAP hace referencia a la metadata cuando crea una copia Snapshot, en lugar de copiar bloques de datos, que es la razón por la que las copias Snapshot son tan eficientes. Al hacerlo, se elimina el tiempo de búsqueda en el que incurren otros sistemas para localizar los bloques a copiar, así como el coste de realizar la propia copia.¨

Uso de Ontap FlexCache para acelerar el acceso a los datos compartidos de Window

En la versión de Ontap 9.8 NetApp decidió añadirle compatibilidad al protocolo SMB de Windows al utilizar la tecnología de FlexCache, Por fin….

En este laboratorio de práctica crearé un volumen flexcache de origen y uno de caché en un clúster remoto. En el ejemplo de laboratorio también validare el beneficio ofrecido por la capacidad de ampliar un recurso compartido CIFS central de forma nativa.

Para comenzar utilizaré como referencia la documentación de NetApp para definir que rayos es un volumen Flexcache y para que es utilizado:

Un volumen FlexCache es un volumen poco poblado que está respaldado por un volumen de origen. El volumen FlexCache puede estar en el mismo clúster o en un clúster diferente al del volumen de origen. El volumen FlexCache proporciona acceso a los datos del volumen de origen sin necesidad de que todos los datos estén en el volumen FlexCache. A partir de ONTAP 9.8, un volumen FlexCache también soporta el protocolo SMB.

NetApp Documentation Portal

Para este laboratorio utilizaré como referencia el siguiente diagrama donde se muestra un dominio de “Active Directory” con dos “Sites” llamados <Gurabo> y <Ponce>. Ambos “Sites” poseen un clúster de Ontap con la versión 9.8P4. Flexcache requiere la configuración de interfaces tipo “Intercluster”.

Nota: Para el laboratorio se utilizó el simulador de Ontap.

Se añadió la configuración que realicé en el <vserver> remoto <NAS-EDGE> por si les interesa ver como crear desde cero un SVM como comúnmente le llama NetApp. Para acceder solo tienen que presionar el icono de “+”.

Prerrequisitos – configuración de vserver y red

Paso I: Crear SVM NAS-EDGE en el destino.

OnPrem-EDGE::> vserver create -vserver NAS-EDGE -rootvolume NAS_EDGE_root -aggregate OnPrem_DR_01_VM_DISK_1 
[Job 577] Job succeeded: Success                                               
Vserver creation completed.

OnPrem-DR::> 

Referencia: vserver create

Paso II: Crear las interfaces de red lógicas.

OnPrem-EDGE::> network interface create -vserver NAS-EDGE -lif NAS_EDGE_01 -address 10.10.33.20 -netmask-length 24 -home-node OnPrem-DR-01 -home-port e0c -service-policy default-data-files    

OnPrem-EDGE::> network interface create -vserver NAS-EDGE -lif NAS_EDGE_02 -address 10.10.33.21 -netmask-length 24 -home-node OnPrem-DR-02 -home-port e0c -service-policy default-data-files

OnPrem-EDGE::> network interface show -curr-port e0c -vserver NAS-EDGE 
            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
NAS-EDGE
            NAS_EDGE_01  up/up    10.10.33.20/24     OnPrem-EDGE-01 e0c     true
            NAS_EDGE_02  up/up    10.10.33.21/24     OnPrem-EDGE-02 e0c     true
2 entries were displayed.

OnPrem-EDGE::> 

Referencia: network interface create

Paso III: Crear las rutas de red.

OnPrem-EDGE::> network route create -vserver NAS-EDGE -destination 0.0.0.0/0 -gateway 10.10.33.254

OnPrem-EDGE::> network route show -vserver NAS-EDGE
Vserver             Destination     Gateway         Metric
------------------- --------------- --------------- ------
NAS-EDGE
                    0.0.0.0/0       10.10.33.254    20

OnPrem-EDGE::> 

Referencia: network route create

Paso IV: Configurar parámetros de DNS

OnPrem-EDGE::> vserver services dns create -domains zenprsolutions.local -name-servers 192.168.5.1 -vserver NAS-EDGE 

Warning: Only one DNS server is configured. Configure more than one DNS server
         to avoid a single-point-of-failure.

OnPrem-EDGE::> vserver services dns show -vserver NAS-EDGE 

                        Vserver: NAS-EDGE
                        Domains: zenprsolutions.local
                   Name Servers: 192.168.5.1
                 Timeout (secs): 2
               Maximum Attempts: 1

OnPrem-EDGE::> 

Referencia: vserver services dns create

Paso V: Configurar protocolo CIFS y añadir al dominio.

OnPrem-EDGE::> vserver cifs create -vserver NAS-EDGE -domain zenprsolutions.local -cifs-server NAS-EDGE              

In order to create an Active Directory machine account for the CIFS server, you
must supply the name and password of a Windows account with sufficient
privileges to add computers to the "CN=Computers" container within the
"ZENPRSOLUTIONS.LOCAL" domain. 

Enter the user name: administrator

Enter the password: xxxxxxxxxxxx

Notice: SMB1 protocol version is obsolete and considered insecure. Therefore it
is deprecated and disabled on this CIFS server. Support for SMB1 might be
removed in a future release. If required, use the (privilege: advanced)
"vserver cifs options modify -vserver NAS-EDGE -smb1-enabled true" to enable
it.

OnPrem-EDGE::> vserver cifs show                                                                
            Server          Status    Domain/Workgroup Authentication
Vserver     Name            Admin     Name             Style
----------- --------------- --------- ---------------- --------------
NAS-EDGE    NAS-EDGE        up        ZENPRSOLUTIONS          domain
2 entries were displayed.

OnPrem-EDGE::>

Referencia: vserver cifs create

Paso VI: Validar que exista objeto de computadora en “Active Directory” (Powershell).

PS C:\Users\Administrator> Get-ADComputer -Identity NAS-EDGE

DistinguishedName : CN=NAS-EDGE,CN=Computers,DC=zenprsolutions,DC=local
DNSHostName       : NAS-EDGE.zenprsolutions.local
Enabled           : True
Name              : NAS-EDGE
ObjectClass       : computer
ObjectGUID        : 3cfec085-1417-4bac-bff7-d734e4e30049
SamAccountName    : NAS-EDGE$
SID               : S-1-5-21-2867495315-1194516362-180967319-2665
UserPrincipalName : 

PS C:\Users\Administrator> 

Paso VII: Validar conectividad y resolución de nombre (Powershell).

PS C:\Users\Administrator> ping NAS-EDGE.zenprsolutions.local
Ping request could not find host NAS-EDGE.zenprsolutions.LOCAL. Please check the name and try again.

PS C:\Users\Administrator> Add-DnsServerResourceRecordA -Name NAS-EDGE -IPv4Address 10.10.33.20 -CreatePtr -ZoneName zenprsolutions.local

PS C:\Users\Administrator> Add-DnsServerResourceRecordA -Name NAS-EDGE -IPv4Address 10.10.33.21 -CreatePtr -ZoneName zenprsolutions.local

PS C:\Users\Administrator> 
PS C:\Users\Administrator> nslookup NAS-EDGE.zenprsolutions.local
	primary name server = 192.168.5.1
	responsible mail addr = (root)
	serial  = 0
	refresh = 28800 (8 hours)
	retry   = 7200 (2 hours)
	expire  = 604800 (7 days)
	default TTL = 86400 (1 day)
Server:  SERVER-DC-01V.zenprsolutions.local
Address:  192.168.5.1

Name:    NAS-EDGE.zenprsolutions.local
Addresses: 10.10.33.20
	   10.10.33.21


PS C:\Users\Administrator> 

Para poder comenzar con el laboratorio es necesario crear una asociación entre ambos <vservers> el local <NAS> y el remoto <NAS-EDGE>. Para lograr esto utilizamos el comando <vserver peer create> especificando que el “applications” sea como “flexcache”

Referencia: vserver peer create.

Nota: Previamente se realizo la asociación a nivel de clúster con el comando <cluster peer create>.

OnPrem-HQ::> vserver peer create -vserver NAS -peer-cluster OnPrem-EDGE -peer-vserver NAS-EDGE -applications flexcache 

Info: [Job 883] 'vserver peer create' job queued 

Una vez creada la asociación entre ambos vserver podemos comenzar a validar que el volumen que usaremos como origen este creado. Para esto utilizamos el comando <volume show> desde el clúster local. Para éste laboratorio utilizaremos el volumen llamado share. Les dejaré como referencia el cómo crear un volumen en Ontap desde el comienzo. Enlace

OnPrem-HQ::*> volume show -vserver NAS                
Vserver   Volume       Aggregate    State      Type       Size  Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
NAS       NAS_root     OnPrem_HQ_01_SSD_1 online RW      20MB    17.66MB    7%
NAS       share        OnPrem_HQ_01_SSD_1 online RW      10.3GB   8.04GB   20%
19 entries were displayed.

OnPrem-HQ::*> 

Ya identificado el volumen que utilizaremos podemos crear el volumen tipo flexcache utilizando el comando <volume flexcache create>. Es importante mencionar que flexcache utiliza “FlexGroup” para crear el volumen. Es por esta razón, que se utiliza la opción de <aggr-list> para especificar cuales agregados se utilizarán para crear los volúmenes tipo “FlexGroup“.

OnPrem-EDGE::> volume flexcache create -vserver NAS-EDGE -volume share_edge -aggr-list OnPrem_EDGE_0* -origin-vserver NAS -origin-volume share -size 10GB -junction-path /share_edge
[Job 595] Job succeeded: Successful.                                           

OnPrem-EDGE::>

Desde el clúster remoto podemos verificar el volumen creado utilizando el comando <vol flexcache show>.

OnPrem-EDGE::> vol flexcache show
Vserver Volume      Size       Origin-Vserver Origin-Volume Origin-Cluster
------- ----------- ---------- -------------- ------------- --------------
NAS-EDGE share_edge 10GB       NAS            shares            OnPrem-HQ

OnPrem-EDGE::> 

Desde el clúster local podemos ver el volumen de origen con el comando <volume flexcache origin show-caches>. En el resultado del comando podemos ver el volumen flexcache previamente creado.

OnPrem-HQ::*> volume flexcache origin show-caches
Origin-Vserver Origin-Volume  Cache-Vserver  Cache-Volume  Cache-Cluster
-------------- -------------- -------------- ------------- --------------
NAS            share         NAS-EDGE       share_edge    OnPrem-EDGE
1 entries were displayed.

OnPrem-HQ::*> 

Ahora procedemos a compartir el volumen caché share_edge utilizando el protocolo SMB. Para esto el comando <vserver cifs share create> es utilizado con la opción de <-path /share_edge> para especificar el “junction-path” del volumen flexclone.

OnPrem-EDGE::> vserver cifs share create -vserver NAS-EDGE -share-name share_edge -path /share_edge

OnPrem-EDGE::>

Ahora podemos ver que el “Share” fue creado en el volumen <share_edge>.

OnPrem-EDGE::> vserver cifs share show -share-name share_edge
Vserver        Share         Path              Properties Comment  ACL
-------------- ------------- ----------------- ---------- -------- -----------
NAS-EDGE       share_edge    /share_edge       oplocks    -        Everyone / Full Control
                                               browsable
                                               changenotify
                                               show-previous-versions

OnPrem-EDGE::> 

Utilicé la herramienta de smbmap para validar que la carpeta compartida puede ser accedida desde la red.

[rebelinux@blabla ~]$ smbmap.py -H 10.10.33.20 -p "XXXXX" -d ZENPRSOLUTIONS -u administrator 
[+] IP: 10.10.33.20:445	Name: NAS-EDGE.zenprsolutions.local                            
        Disk                                                  	Permissions	Comment
	----                                                  	-----------	-------
	share_edge                                        	READ, WRITE	
	ipc$                                              	NO ACCESS	
	c$                                                	READ, WRITE	
[rebelinux@blabla ~]$

Modifiqué el diagrama original para mostrar como están conectados los clientes que utilizaré para realizar las pruebas de transferencia. Para esta prueba copiaré desde cada “SHARE” el archivo “Very_Big_File.iso“.

En esta parte se puede ver los comandos utilizados para conectar los clientes al “SHARE”. Se utilizó Ubuntu Linux 20.04 para este laboratorio.

CLIENT-HQ-01V
root@CLIENT-HQ-01V:/home/godadmin# mount -t cifs -o username=administrator@zenprsolutions.local,password=XXXXXXXX //nas/shares /mnt/share/
root@CLIENT-HQ-01V:/home/godadmin# cd /mnt/share/
root@CLIENT-HQ-01V:/mnt/share# ls
RecApp-2021-02-20.webm   RecApp-2021-02-27.webm   Very_Big_File.iso   WSUS-Cleanup.ps1
root@CLIENT-HQ-01V:/mnt/share#

CLIENT-EDGE-01V
root@CLIENT-EDGE-01V:/home/godadmin# mount -t cifs -o username=administrator@zenprsolutions.local,password=XXXXXXXX //nas-edge/share_edge /mnt/share_edge/
root@CLIENT-EDGE-01V:/home/godadmin# cd /mnt/share_edge/
root@CLIENT-EDGE-01V:/mnt/share_edge# ls
RecApp-2021-02-20.webm   RecApp-2021-02-27.webm   Very_Big_File.iso   WSUS-Cleanup.ps1
root@CLIENT-EDGE-01V:/mnt/share_edge#
CLIENT-EDGE-02V
root@CLIENT-EDGE-02V:/home/godadmin# mount -t cifs -o username=administrator@zenprsolutions.local,password=XXXXXXXX //nas-edge/share_edge /mnt/share_edge/
root@CLIENT-EDGE-02V:/home/godadmin# cd /mnt/share_edge/
root@CLIENT-EDGE-02V:/mnt/share_edge# ls
RecApp-2021-02-20.webm   RecApp-2021-02-27.webm   Very_Big_File.iso   WSUS-Cleanup.ps1
root@CLIENT-EDGE-02V:/mnt/share_edge#

En esta parte se utilizó el comando <cp> para copiar el archivo “Very_Big_File.iso” desde la carpeta en el clúster hacia la carpeta local en el cliente. Para medir el tiempo de transferencia se utilizó el comando <time>.

CLIENT-HQ-01V
root@CLIENT-HQ-01V:/mnt/share# time cp Very_Big_File.iso /home/godadmin/

real	2m7.513s
user	0m0.016s
sys	0m6.236s
root@CLIENT-HQ-01V:/mnt/share#
CLIENT-EDGE-01V
root@CLIENT-EDGE-01V:/mnt/share_edge# time cp Very_Big_File.iso /home/godadmin/

real	4m2.391s
user	0m0.021s
sys	0m6.902s
root@CLIENT-EDGE-01V:/mnt/share_edge#
CLIENT-EDGE-02V
root@CLIENT-EDGE-02V:/mnt/share_edge# time cp Very_Big_File.iso /home/godadmin/

real	2m16.169s
user	0m0.054s
sys	0m6.128s
root@CLIENT-EDGE-02V:/mnt/share_edge# 

La tabla muestra el tiempo de transferencia de cada prueba realizada. Como pueden ver el cliente CLIENT-HQ-01V ubicado en el “site” Gurabo tiene acceso directo a la carpeta compartida desde el volumen origen teniendo un tiempo menor de transferencia <2m7.513s>. El cliente CLIENT-EDGE-01V esta conectado al “site” de Ponce utilizando la carpeta compartida del volumen de flexcache donde podemos ver que, al no estar el contenido inicialmente en el caché el tiempo de transferencia fue mayor <4m2.391s>. Esto es causado porque es necesario cargar toda la data desde el volumen de origen. Por último, el cliente CLIENT-EDGE-02V tuvo un tiempo de transferencia similar al CLIENT-HQ-01V, ya que el contenido del archivo “Very_Big_File.iso” se encuentra ya en el caché del volumen de flexcache.

Client NameTransfer DurationShareDescription
CLIENT-HQ-01V2m7.513s\\NAS\SHARECopy from OnPrem-HQ Share
CLIENT-EDGE-01V4m2.391s\\NAS-EDGE\SHARE-EDGECopy from OnPrem-EDGE Share without content cached (Flexcache)
CLIENT-EDGE-02V2m16.169s\\NAS-EDGE\SHARE-EDGECopy from OnPrem-EDGE Share with content cached (Flexcache)

Hasta la próxima!

Encriptación a nivel de agregado en ONTAP

© 2021 NetApp

Previament en un post expliqué como configurar un volumen encriptado utilizando un administrador de llaves de encriptación (KMS) especificamente de la compañía HyTrust. En este caso específico cada volumen es encriptado individualmente utilizado llaves independientes. Una desventaja de este método es que afecta la posibilidad de aumentar los niveles de eficiencia de reducción de datos como lo son; de-duplicación, compresión y compactación.

Para eliminar esta desventaja los gurus de NetApp se ingeniaron la idea de aplicar la función de encriptación a nivel de agregado permitiendo que los volúmenes que residan dentro del mismo agregado compartan la llave de encriptación. Esta tecnología es conocida como “NetApp Aggregate Encryption” (NAE). Esto permite que los clientes tengan la opción de aprovecharse de las tecnologías de eficiencia de almacenamiento en conjunto al proceso de encriptación.

Ahora nos toca hablar de como podemos crear un agregado encriptado en Ontap pero primero que nada… ¿Que es un agregado dentro de Ontap?

Utilizando como referencia el portal de “Knowledge Base” de NetApp:

Un agregado es una colección de discos (o particiones) organizados en uno o más grupos de RAID. Es el objeto de almacenamiento más básico dentro de ONTAP y es necesario para permitir el aprovisionamiento de espacio para los dispositivos conectados.

NetApp Knowledge Base
© 2021 flackbox.com

Paso 1: Validar pre-requisitos en Ontap.

Para poder utilizar la opción de encriptación a nivel de agregado en necesario tener una versión de Ontap 9.6 o mayor y que estén instaladas las licencias necesarias en el cluster. En este caso utilizamos el comando <version> para validar la versión actual del cluster y el comando <license show -package VE> para desplegar la información de las licencias.

OnPrem-HQ::> version
NetApp Release 9.9.1RC1: Fri Apr 30 06:35:11 UTC 2021
 
OnPrem-HQ::> license show -package VE -fields package,owner,description,type  
  (system license show)
serial-number                  package owner         description               type    
------------------------------ ------- ------------- ------------------------- ------- 
X-XX-XXXXXXXXXXXXXXXXXXXXXXXXX VE      OnPrem-HQ-01 Volume Encryption License license 
X-XX-XXXXXXXXXXXXXXXXXXXXXXXXX VE      OnPrem-HQ-02 Volume Encryption License license 
2 entries were displayed.

OnPrem-HQ::> 

Nota: previamente he realizado la configuración del KMS externo en Ontap. Enlace

Paso 2: Validar los disco “Spare” disponibles.

Para comenzar, existen dos formas para encriptar un agregado; inicialmente cuando es creado o la conversión en vivo de un agregado existente. Inicialmente estaré creando un agregado nuevo y luego en otro tutorial les mostrare como podemos convertir un agregado existente. Para crear un agregado es necesario tener disco duros disponibles o en el estado de “spare” como comúnmente le llama NetApp.

El comando <storage aggregate show-spare-disks> nos permite ver cuantos discos particionado están disponibles en el nodo donde crearemos el nuevo agregado encriptado. En este caso en particular podemos ver que existen 24 disco particionados utilizando la opción de “Root-Data1-Data2“. Para conocer mas sobre esta estrategia de disco favor de seguir el siguiente enlace:

ADP(v1) and ADPv2 in a nutshell, it’s delicious!

 © 2021 Chris Maki
OnPrem-HQ::> storage aggregate show-spare-disks -original-owner OnPrem-HQ-01 
                                                                      
Original Owner: OnPrem-HQ-01
 Pool0
  Root-Data1-Data2 Partitioned Spares
                                                              Local    Local
                                                               Data     Root Physical
 Disk             Type   Class          RPM Checksum         Usable   Usable     Size Status
 ---------------- ------ ----------- ------ -------------- -------- -------- -------- --------
 VMw-1.1          SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.2          SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.3          SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.4          SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.5          SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.6          SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.7          SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.8          SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.9          SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.10         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.11         SSD    solid-state      - block           11.63GB   3.35GB  26.67GB zeroed
 VMw-1.12         SSD    solid-state      - block           11.63GB   3.35GB  26.67GB zeroed
 VMw-1.13         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.14         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.15         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.16         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.17         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.18         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.19         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.20         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.21         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.22         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.23         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
 VMw-1.24         SSD    solid-state      - block           11.63GB       0B  26.67GB zeroed
24 entries were displayed.

OnPrem-HQ::> 

Paso 3: Crear el agregado encriptado.

Para crear el agregado encriptado utilizamos el comando <storage aggregate create> con la opción de <encrypt-with-aggr-key true>. En este caso creamos un agregado seguro compuesto de 23 disco “particiones”.

Nota: Para este ejemplo se utilizo el tipo de RAID “Dual Parity”

OnPrem-HQ::> storage aggregate create -aggregate OnPrem_HQ_01_SSD_1 -diskcount 23 -node OnPrem-HQ-01 -raidtype raid_dp -encrypt-with-aggr-key true 

Info: The layout for aggregate "OnPrem_HQ_01_SSD_1" on node "OnPrem-HQ-01"
      would be:
      
      First Plex
      
        RAID Group rg0, 23 disks (block checksum, raid_dp)
                                                            Usable Physical
          Position   Disk                      Type           Size     Size
          ---------- ------------------------- ---------- -------- --------
          shared     VMw-1.1                   SSD               -        -
          shared     VMw-1.2                   SSD               -        -
          shared     VMw-1.3                   SSD         11.61GB  11.64GB
          shared     VMw-1.4                   SSD         11.61GB  11.64GB
          shared     VMw-1.5                   SSD         11.61GB  11.64GB
          shared     VMw-1.6                   SSD         11.61GB  11.64GB
          shared     VMw-1.7                   SSD         11.61GB  11.64GB
          shared     VMw-1.8                   SSD         11.61GB  11.64GB
          shared     VMw-1.9                   SSD         11.61GB  11.64GB
          shared     VMw-1.10                  SSD         11.61GB  11.64GB
          shared     VMw-1.18                  SSD         11.61GB  11.64GB
          shared     VMw-1.16                  SSD         11.61GB  11.64GB
          shared     VMw-1.13                  SSD         11.61GB  11.64GB
          shared     VMw-1.14                  SSD         11.61GB  11.64GB
          shared     VMw-1.15                  SSD         11.61GB  11.64GB
          shared     VMw-1.19                  SSD         11.61GB  11.64GB
          shared     VMw-1.20                  SSD         11.61GB  11.64GB
          shared     VMw-1.21                  SSD         11.61GB  11.64GB
          shared     VMw-1.17                  SSD         11.61GB  11.64GB
          shared     VMw-1.22                  SSD         11.61GB  11.64GB
          shared     VMw-1.11                  SSD         11.61GB  11.64GB
          shared     VMw-1.12                  SSD         11.61GB  11.64GB
          shared     VMw-1.23                  SSD         11.61GB  11.64GB
      
      Aggregate capacity available for volume use would be 219.5GB.
      
Do you want to continue? {y|n}: y
[Job 817] Job succeeded: DONE                                                  

OnPrem-HQ::> 

Una vez creado pasaremos a verificar el agregado, para esto utilizaremos el comando <storage aggregate show> y filtraremos el resultado con la opción de <encrypt-with-aggr-key>.

OnPrem-HQ::> storage aggregate show -fields aggregate,size,availsize,usedsize,state,node,raidstatus,encrypt-with-aggr-key 
aggregate           node          availsize raidstatus      size    state  usedsize encrypt-with-aggr-key 
------------------- ------------- --------- --------------- ------- ------ -------- --------------------- 
OnPrem_HQ_01_SSD_1 OnPrem-HQ-01 219.5GB   raid_dp, normal 219.5GB online 480KB    true                  
OnPrem_HQ_02_SSD_1 OnPrem-HQ-02 209.3GB   raid_dp, normal 219.5GB online 10.12GB  false                 
aggr0_OnPrem_HQ_01 OnPrem-HQ-01 1.11GB    raid_dp, normal 22.80GB online 21.69GB  false                 
aggr0_OnPrem_HQ_02 OnPrem-HQ-02 1.11GB    raid_dp, normal 22.80GB online 21.69GB  false                 
4 entries were displayed.

OnPrem-HQ::> 

En el resultado del comando podemos ver que fue creado el agregado con la encriptación habilitada.

Paso 4: Crear un volumen dentro del agregado encriptado.

A diferencia de la encriptación a nivel de volúmenes NVE, al utilizar encriptación a nivel de agregado no es necesario especificar la opción de encriptar a la hora de crear el volumen. El comando <vol create> crea un volumen encriptado de forma predeterminada cuando el volumen reside en un agregado que utiliza NAE.

OnPrem-HQ::> vol create -vserver SAN -volume Secure_Vol -aggregate OnPrem_HQ_01_SSD_1 -size 10GB -space-guarantee none 
[Job 818] Job succeeded: Successful                                            

OnPrem-HQ::>

Al utilizar el comando <vol show> con la opción de <encryption-state full> podemos ver que el volumen fue creado encriptado de forma predeterminada.

OnPrem-HQ::> vol show -encryption-state full -aggregate OnPrem_HQ_01_SSD_1 -fields Vserver,Volume,encrypt,encryption-type,encryption-state 
vserver volume     encryption-type encrypt encryption-state 
------- ---------- --------------- ------- ---------------- 
SAN     Secure_Vol aggregate       true    full             

OnPrem-HQ::>

Resumen

En este tutorial le mostré cómo configurar la tecnología de encriptación de nivel agregado dentro de Ontap que nos permite utilizar una clave única para crear volúmenes encriptados. Esto nos permite utilizar tecnologías de reducción y eficiencia de datos en conjunto con mecanismos de seguridad que mejoran o fortalecen la postura de seguridad de la organización.

Configuración de cifrado en volumen de NetApp con Gestor de llaves externo

Utilizando como referencia la documentación de NetApp:

NetApp Volume Encryption (NVE) de NetApp es una tecnología basada en software para cifrar los datos en reposo de un volumen a la vez. Una clave de cifrado a la que sólo puede acceder el sistema de almacenamiento garantiza que los datos del volumen no puedan leerse si el dispositivo subyacente se reutiliza, se devuelve, se extravía o se roba.

NetApp Documentation

En este tutorial les explico lo fácil que es configurar y administrar esta impresionante característica de seguridad.

Antes de comenzar a configurar esta característica es necesario tener un “Servicio de Gestión de LLaves” existente. Para el propósito de este tutorial usaré el KMS de “HyTrust KeyControl” del que ya explique previamente en el blog. Si quieres saber más sobre el tema, lee el siguiente post.

Paso 1: Crear un certificado de cliente para propósitos de autenticación:

Vaya a [KMIP > Client Certificate] y seleccione Create Certificate en el menú de Actions.

Seleccione un nombre para el certificado y presione Create.

Una vez creado el certificado se debe proceder a guardarlo en un lugar seguro.

El archivo descargado contiene el certificado del Cliente y del Root CA necesarios para configurar la opción de KMS en Ontap.

Paso 2: Validación del clúster Ontap

Los aspectos importantes a tener en cuenta antes de poder configurar esta función de seguridad son el estado del clúster y la licencia necesaria que le brinde soporte a la función de encriptación.

El comando cluster show muestra el estado general del cluster de Ontap.

OnPrem-HQ::> cluster show 
Node                  Health  Eligibility
--------------------- ------- ------------
OnPrem-HQ-01         true    true
OnPrem-HQ-02         true    true
2 entries were displayed.

El comando system node show muestra la salud del nodo y el modelo del sistema.

OnPrem-HQ::> system node show
Node      Health Eligibility Uptime        Model       Owner    Location  
--------- ------ ----------- ------------- ----------- -------- ---------------
OnPrem-HQ-01 true true           00:18:10 SIMBOX
OnPrem-HQ-02 true true           00:18:08 SIMBOX
2 entries were displayed.

Con el comando system license show se puede validar la licencia instalada en el cluster. Aquí se puede ver que la licencia de encriptación de volumen está instalada en ambos nodos.

OnPrem-HQ::> system license show -package VE

Serial Number: X-XX-XXXXXXXXXXXXXXXXXXXXXXXXXX
Owner: OnPrem-HQ-01
Installed License: Legacy Key
Capacity: -
Package           Type     Description           Expiration
----------------- -------- --------------------- -------------------
VE                license  Volume Encryption License 
                                                 -

Serial Number: X-XX-XXXXXXXXXXXXXXXXXXXXXXXXXX
Owner: OnPrem-HQ-02
Installed License: Legacy Key
Capacity: -
Package           Type     Description           Expiration
----------------- -------- --------------------- -------------------
VE                license  Volume Encryption License 
                                                 -
2 entries were displayed.

OnPrem-HQ::> 

Paso 3: Configuración del certificado de KMS en Ontap:

Según establecido en la documentación de NetApp:

El clúster y el servidor KMIP utilizan los certificados SSL de KMIP para verificar la identidad del otro y establecer una conexión SSL. Antes de configurar la conexión SSL con el servidor KMIP, debe instalar los certificados SSL de cliente KMIP para el clúster y el certificado público SSL para la autoridad de certificación (CA) raíz del servidor KMIP.

NetApp KMIP Documentation

Para instalar el certificado de cliente KMIP en el cluster de NetApp, ejecute los siguientes comandos:

Nota: El contendido de los certificados son extraídos de los archivos previamente descargados. Los archivos ONTAPEncryption.pem y cacert.pem contienen la información necesaria.

OnPrem-HQ::> security certificate install –vserver OnPrem-HQ -type client –subtype kmip-cert
Please enter Certificate: Press <Enter> when done
-----BEGIN CERTIFICATE----- 
Certificate Content
-----END CERTIFICATE-----
Please enter Private Key: Press <Enter> when done
-----BEGIN PRIVATE KEY-----  
Certificate Private Key Content
-----END PRIVATE KEY-----
You should keep a copy of the private key and the CA-signed digital certificate for future
reference.

The installed certificate's CA and serial number for reference:
CA: HyTrust KeyControl Certificate Authority
serial: C9A148B9

The certificate's generated name for reference: ONTAPEncryption
OnPrem-HQ::> security certificate install -vserver OnPrem-HQ -type server-ca -subtype kmip-cert 

Please enter Certificate: Press <Enter> when done
-----BEGIN CERTIFICATE-----  
Certificate Content
-----END CERTIFICATE-----
You should keep a copy of the CA-signed digital certificate for future reference.

The installed certificate's CA and serial number for reference:
CA: HyTrust KeyControl Certificate Authority
serial: 60A148B6

The certificate's generated name for reference: HyTrustKeyControlCertificateAuthority

Paso 4: Configuración de la solución Volume Encryption de NetApp:

Para este tutorial es necesario configurar un servidor de gestión de llaves “KMS” externo para que el sistema de almacenamiento pueda almacenar y recuperar de forma segura las llaves de autenticación para la solución de NetApp Volume Encryption (NVE).

Nota: NetApp recomienda un mínimo de dos servidores para la redundancia y la recuperación de desastres.

El siguiente comando permite añadir el servidor de KMS al sistema de Ontap utilizando la dirección de IP 192.168.7.201, el puerto TCP/5696 y utilizando los certificados configurados previamente.

OnPrem-HQ::> security key-manager external enable -vserver OnPrem-HQ -key-servers 192.168.7.201:5696 -client-cert ONTAPEncryption -server-ca-certs HyTrustKeyControlCertificateAuthority 

OnPrem-HQ::> security key-manager external show                                                                                                                                           

                  Vserver: OnPrem-HQ
       Client Certificate: ONTAPEncryption
   Server CA Certificates: HyTrustKeyControlCertificateAuthority
          Security Policy: -

Key Server
------------------------------------------------
192.168.7.201:5696

Es importante validar que el servicio de KMS esté “available” antes de proseguir a crear los volúmenes encriptados. El comando security key-manager external show-status no permite validar el estado del servicio.

OnPrem-HQ::> security key-manager external show-status

Node  Vserver  Key Server                                   Status
----  -------  -------------------------------------------  ---------------
OnPrem-HQ-01
      OnPrem-HQ
               192.168.7.201:5696                           available
OnPrem-HQ-02
      OnPrem-HQ
               192.168.7.201:5696                           available
2 entries were displayed.

OnPrem-HQ::> 

Paso 5: Crear un volumen encriptado (NVE)

En ésta etapa final del tutorial probaremos que la configuración realizada es la correcta al crear un volumen encriptado dentro de Ontap. Para este paso usaremos el comando vol create utilizando la opcion de encrypt true

OnPrem-HQ::> vol create TEST_Encryption -vserver SAN -size 10G -aggregate OnPrem_HQ_01_SSD_1 -encrypt true 
  
[Job 763] Job succeeded: Successful 

Con el comando vol show podemos verificar que el volumen haya sido creado con la opción de encriptación.

OnPrem-HQ::> vol show -encryption -vserver SAN -encryption-state full 
Vserver   Volume       Aggregate    State      Encryption State
--------- ------------ ------------ ---------- ----------------
SAN       TEST_Encryption OnPrem_HQ_01_SSD_1 online full

OnPrem-HQ::> 

Paso 6: Validar en el servidor KMS la información de Encriptación.

En este ultimo paso entramos al portal de administración de la aplicación “HyTrust KeyControl” para validar que las llaves de encriptacion estén grabadas en la plataforma. Para validar ésta información vamos al menú de [KMIP > Objects] donde se puede validar que las llaves fueron creadas luego de creado el volumen dentro de Ontap.

Resumen

En este tutorial mostramos como configurar el servicio de KMS dentro de Ontap que nos permite crear volúmenes encriptados permitiendo aumentar o mejorar la postura de seguridad en nuestra infraestructura u organización.