Aunque a fecha de hoy no existe documentación oficial de Best Practices de configuración de Multipathing para la MSA P2000 en entornos VMware, existen multitud de opiniones y foros al respecto. De todas las configuraciones que he probado me quedo con la que explicare a continuación, es la que mejor resultados me ha dado en las pruebas de failover y de rendimiento.
Se asume que para esta configuración disponemos de dos controladoras en la MSA asi como 2 switches para iSCSI o 2 VLANs para separar las dos subredes que configuraremos. También se asume que disponemos de 2 NICs en cada host ESXi para uso con iSCSI.
Si el servidor dispone de 2 tarjetas Ethernet (Placa base y PCI, por ejemplo) intentaremos dedicar una NIC de cada una de ellas por temas de redundancia de hardware.
Cableado:
Conectaremos cada NIC a un switch dedicado para iSCSI, por ejemplo, por cada host la NIC1 al switch1 y la NIC2 al switch2. Asimismo conectaremos el puerto 1 de la controladora A de la MSA al switch1 y el puerto 2 de la controladora A al switch2. Lo mismo con la controladora B. Ver el diagrama.
ESXi Networking:
9·3 | IOMeter
Cuando instalamos una cabina de almacenamiento, ya sea NAS o SAN, es importante conocer el rendimiento de la misma, especialmente si disponemos de discos de diferentes tecnologías y niveles RAID necesitaremos saber cual es el mas apropiado para cada caso, no necesita el mismo rendimiento en almacenamiento un servidor con bases de datos SQL o de Exchange que un Gateway de Terminal Server por ejemplo. Ademas, sin esta información se hace difícil la gestión y el crecimiento. Con IOMeter podemos identificar donde están los cuellos de botella de nuestro sistema de almacenamiento. En alguna ocasión he tenido que testear un disco RDM, desconectarlo y presentárselo a un servidor físico para volverlo a testear y determinar si tengo algún problema en el host (Controladora inadecuada, firmware inadecuada, switch con problemas, Storage Adapter mal configurado, etc..).
Además de medir el rendimiento de I/O disponemos de un componente llamado Dynamo que genera carga de trabajo (Workload) simulando diferentes escenarios de forma granular.
Siempre que sea posible, intentar que el host que contenga la VM que generar los test no contenga mas VMs en marcha para conseguir un resultado mas preciso.
Instalación:
La instalación de IOMeter no tiene ningún secreto, tan solo ha de ejecutarse en la VM sobre la que lanzaremos los tests.
Existen multitud de variables en la configuración de los tests con IOMeter, yo acostumbro a utilizar la siguiente de forma genérica para medir el numero de R/W MB/s secuenciales, IOPS totales, IOPS de escritura, IOPS de lectura y latencia en ms.
A no ser que queramos testear el rendimiento de un disco local de la VM crearemos un disco RDM o VMDK en el datastore o LUN que queramos medir.
Disk Targets:
Crear 4 workers por disco de destino a testear, especificar el disco de destino creado.
El campo sectores "sectors", indica el tamaño de archivo para el test, con 4GB. sera suficiente para Datastores locales, no obstante si vamos a testear una NAS o SAN con caches de controladoras de 4,8 o mas GB. el tamaño de archivo debera ser mayor. Como se ve en la configuración siguiente suelo usar archivos de 32GB. que acustumbran a superar el tamaño de cache de la mayoria de cabinas.
Si lo que queremos es testear subsistemas de discos, caches, etc. usaremos valores mas pequeños para que el workload no llege al disco.
Worker 1:
Maximum Disk Size: 67.108.864 sectores (32 GB para que no quepa todo en la memoria)
Starting Disk Sector: 1
# of Outstanding I/Os: 32
Worker 2:
Maximum Disk Size: 67.108.864 sectores (32 GB para que no quepa todo en la memoria)
Starting Disk Sector: 2
# of Outstanding I/Os: 32
Worker 3:
Maximum Disk Size: 67.108.864 sectores (32 GB para que no quepa todo en la memoria)
Starting Disk Sector: 3
# of Outstanding I/Os: 32
Worker 4:
Maximum Disk Size: 67.108.864 sectores (32 GB para que no quepa todo en la memoria)
Starting Disk Sector: 4
# of Outstanding I/Os: 32
Access Specifications:
Crear dos reglas de Access Specifications para todos los Workers al 50% cada una.
Para testear almacenamiento en entornos virtualizados se recomiendan bloques de 8k.
8K;100% read;0% random (lectura).
8K;0% read;0% random(escritura).
Test Setup:
Ramp Up Time: 30 s
Run Time: 3 minutes
Y por ultimo, en results Display modificaremos la frecuencia de actualización a 1 segundo:
Update Frequency: 1 s
Además de medir el rendimiento de I/O disponemos de un componente llamado Dynamo que genera carga de trabajo (Workload) simulando diferentes escenarios de forma granular.
Siempre que sea posible, intentar que el host que contenga la VM que generar los test no contenga mas VMs en marcha para conseguir un resultado mas preciso.
Instalación:
La instalación de IOMeter no tiene ningún secreto, tan solo ha de ejecutarse en la VM sobre la que lanzaremos los tests.
Existen multitud de variables en la configuración de los tests con IOMeter, yo acostumbro a utilizar la siguiente de forma genérica para medir el numero de R/W MB/s secuenciales, IOPS totales, IOPS de escritura, IOPS de lectura y latencia en ms.
A no ser que queramos testear el rendimiento de un disco local de la VM crearemos un disco RDM o VMDK en el datastore o LUN que queramos medir.
Disk Targets:
Crear 4 workers por disco de destino a testear, especificar el disco de destino creado.
El campo sectores "sectors", indica el tamaño de archivo para el test, con 4GB. sera suficiente para Datastores locales, no obstante si vamos a testear una NAS o SAN con caches de controladoras de 4,8 o mas GB. el tamaño de archivo debera ser mayor. Como se ve en la configuración siguiente suelo usar archivos de 32GB. que acustumbran a superar el tamaño de cache de la mayoria de cabinas.
Si lo que queremos es testear subsistemas de discos, caches, etc. usaremos valores mas pequeños para que el workload no llege al disco.
Worker 1:
Maximum Disk Size: 67.108.864 sectores (32 GB para que no quepa todo en la memoria)
Starting Disk Sector: 1
# of Outstanding I/Os: 32
Worker 2:
Maximum Disk Size: 67.108.864 sectores (32 GB para que no quepa todo en la memoria)
Starting Disk Sector: 2
# of Outstanding I/Os: 32
Worker 3:
Maximum Disk Size: 67.108.864 sectores (32 GB para que no quepa todo en la memoria)
Starting Disk Sector: 3
# of Outstanding I/Os: 32
Worker 4:
Maximum Disk Size: 67.108.864 sectores (32 GB para que no quepa todo en la memoria)
Starting Disk Sector: 4
# of Outstanding I/Os: 32
Access Specifications:
Crear dos reglas de Access Specifications para todos los Workers al 50% cada una.
Para testear almacenamiento en entornos virtualizados se recomiendan bloques de 8k.
8K;100% read;0% random (lectura).
8K;0% read;0% random(escritura).
Test Setup:
Ramp Up Time: 30 s
Run Time: 3 minutes
Y por ultimo, en results Display modificaremos la frecuencia de actualización a 1 segundo:
Update Frequency: 1 s
8·3 | QNap NFS
Configurar un Datastore NFS
En varias ocasiones he utilizado dispositivos NAS QNap como destino de copias o laboratorios, incluso en alguna ocasión los he montado para servidores en producción (Desarrollo) con resultados óptimos, personalmente pienso que son unos dispositivos muy buenos en relación calidad/precio.
En este caso vamos a utilizar un QNap TS-419+ para montar un Datastore NFS
Vamos a la practica, para comenzar prepararemos los requisitos del QNap, estos son:
-Habilitar el servicio NFS.
-Desactivar la cache de escritura para EXT4
Iremos a Herramientas de Administración > Configuración de Hardware y desmarcaremos "habilitar caché de escritura (solo EXT4)".
Imagen. Configuración de Hardware.
Seguidamente iremos a Servicio de Red > Servicio NFS y habilitamos el servicio.
Imagen. Servicio NFS.
Bien, ahora crearemos el Share, según el modelo de QNap y la cantidad de discos de que disponga podremos montar uno o mas volúmenes y dedicar uno para NFS, en este caso tengo 4 discos en un único volumen RAID5 y en el tengo Shares y LUNs, por lo tanto no tendré disponible la opción de donde ubicar el Share NFS.
Configuración de Share:
Vamos a Administración de Derechos de Acceso > Carpeta de Recursos Compartidos y crearemos un nuevo Recurso compartido de red.
Imagen. Crear un recurso compartido de red.
Imagen. Siguiente.
En el siguiente paso especificaremos un nombre para el Share y el volumen de destino (en este caso solo tengo uno).
Deberemos ocultar la carpeta, no obstante seguiría siendo visible al acceder a Mis Sitios de red en el caso que la QNap estuviera en la red LAN con el peligro que eso conlleva, en este caso, al ser un dispositivo dedicado para Backup y Laboratorios ira en una LAN dedicada para NFS e iSCSI.
Especificaremos que no bloquee el archivo, no procede para NFS y asignaremos una ruta de forma automática o manualmente, en este caso dejare que la asigne de forma automática.
Imagen. Configuración de el Share
A continuación marcaremos que solo el usuario Admin tiene privilegios de acceso total a el Share y los usuarios invitados no podrán acceder.
Imagen. Privilegios de acceso.
Imagen. Confirmación de la configuración.
Con esto ya tenemos el Share exportado, hemos configurado los privilegios de acceso de usuario, ahora vamos a configurar los de NFS.
Imagen. Configuración Completa.
Volvemos a Administración de Derechos de Acceso > Carpeta de Recursos Compartidos y abrimos el apartado de Control de acceso NFS haciendo clic en el icono NFS.
Imagen. Control de acceso NFS
Especificaremos como derecho de acceso NFS Sin Limite y especificaremos las IPs que podrán acceder, estas IPs son las que configuraremos mas adelante en los puertos VMKernel de los hosts y conectaremos sus NICs a la VLAN de Backup. En este caso especifico 3 IPs ya que tengo 3 hosts ESXi en el Cluster.
Imagen. Control de Acceso NFS
Configuración del Networking (QNap):
QNap permite realizar agregacion de puertos (802.3ad) y Load Balancing (port bonding “Balance-alb”), para ello deberemos configurarlo en el dispositivo y asignar dos NICs a cada puerto VMKernel, en este caso vamos a configurar un unico puerto LAN de la QNap.
Configuración del Networking (VMware):
Ahora configuraremos el networking de los hosts, para ello iremos al vCenter, a la administración del primer host a configurar.
Una vez en el iremos al apartado Networking.
Imagen. Networking ESXi
Crearemos un nuevo Networking, un nuevo vSwitch y un puerto del tipo VMKernel. En un puerto VMKernel podemos configurar iSCSI, NFS, vMotion y Management, en este caso lo usaremos para NFS.
Imagen. Puerto VMKernel.
Le asignaremos la NIC que hemos designado para NFS, en este caso he conectado la NIC para NFS de cada host a un Switch físico Gigabit y a su vez a el puerto de la QNap, no obstante podríamos conectarlo a un Switch LAN y separar el trafico mediante una VLAN.
Imagen. Creación de un nuevo vSwitch y asignación de la NIC.
Especificamos una etiqueta para el Port Group, en este caso NFS Storage, si se va a utilizar una VLAN para separar el trafico la especificaremos, también podríamos habilitar la administración en este Port Group a modo de "puerta trasera" pero en este caso no sera necesario.
Imagen. Propiedades del Port Group.Configuraremos la IP designada para este host, es una de las que hemos definido en la configuración de acceso NFS del Share. También la mascara de subred.
Con esto ya tenemos el networking. Ahora habra que repetir el proceso con el resto de hosts si es que disponemos de ellos, lógicamente cada uno con su IP.
Creación del Datastore NFS:
Llegados a este punto vamos a montar el Datastore, desde el apartado Configuration de los hosts vamos a Storage y lo añadimos con Add Storage..
Imagen. Apartado Datastores
Seleccionamos Network File Systems (NFS).
Imagen. Tipo de almacenamiento.
Comprobamos la ruta que ha asignado automaticamente al Share en las propiedades del mismo.
Y la especificamos junto a la dirección IP de la QNap y un nombre para el Datastore.
Suscribirse a:
Entradas (Atom)