Ahora más que nunca, las implementaciones de vSAN están creciendo rápidamente en número. Hay muchos documentos acerca de vSAN disponibles en StorageHub con excelente contenido; desde guías de diseño hasta las operaciones del día 2, pero una pregunta común se relaciona con las consideraciones de implementación de vSAN. Mientras hay muchas áreas que podemos explorar, algunas de ellas varían según el hardware seleccionado, las necesidades y los requisitos, así como los diferentes escenarios de implementación, como los clústeres de 2 nodos o estirados (Stretched Clusters). Sin embargo, hay algunas consideraciones que pueden aplicarse a la mayoría de los escenarios de implementación con respecto a la disponibilidad, el tamaño, el rendimiento y las características. Echemos un vistazo más de cerca a algunas de estas consideraciones.
Numero de Nodos
Número de nodos es probablemente la consideración más común de la que se habla. Tenemos un requisito de un mínimo de tres nodos para un clúster de vSAN (dos nodos físicos, si utiliza la opción de 2 nodos con Witness Appliance), y dicho mínimo se reduce al quórum y las matemáticas. Necesitamos un número desigual de hosts para tener una mayoría, y tres es el número más bajo para cumplir con la política predeterminada. Si bien el número mínimo de nodos es tres, es recomendable tener nodos N+1, lo que significa que para un clúster de tres nodos tendría cuatro nodos en lugar de tres, y así sucesivamente. Tener un nodo adicional más allá del mínimo requerido, aumenta sus dominios de falla; permitiéndole reconstruir datos (vSAN de recuperación automática) en caso de una interrupción del host o un mantenimiento extendido. Tenga en cuenta que algunas capacidades de vSAN dependen de un número mínimo de hosts dentro del clúster, como Erasure Coding. Por ejemplo, con RAID5 se requiere un mínimo de cuatro nodos, y con una opción de decisión de diseño para usar N+1, el nuevo mínimo sería de cinco nodos para cumplir con las políticas durante las interrupciones o períodos de mantenimiento extendidos.
Lo sé … ¿qué pasa con el precio? Otra consideración es ir con los nodos de un solo cpu frente a los nodos de doble cpu. En cuanto a las licencias, vSAN utiliza licencias por cpu en la mayoría de los casos, por lo que la sustitución de un nodo de doble socket con dos nodos de un solo socket mantiene la misma cantidad de licencias de vSAN necesarias (dos, en este caso). Los nodos de un solo cpu son más baratos que los nodos de dos cpus, por lo que le conviene valorar ambas opciones. Consulte la Guía de licencias de vSAN para más detalles.
Dimensionamiento
Como cualquier otra solución de almacenamiento, el dimensionamiento es muy importante. Al realizar un ejercicio de dimensionamiento, tenga en cuenta el crecimiento futuro, la configuración de la política de almacenamiento utilizada (PFTT1 = dos copias de datos), espacio de swap, RAID1 vs Erasure Coding y espacio de extra (Slack Space); que es algo que recomendamos para acomodar las reconstrucciones de objetos y componentes después de un cambio de política.
Otro aspecto importante a considerar es el tamaño adecuado de la capa de caché. Para entornos híbridos, seguimos respetando la regla del 10%; sin embargo, para el entornos All-Flash, recomendamos basar esto en el tipo de carga de trabajo y en el perfil de lectura/escritura. John Nicholson escribió un blog sobre esto aquí.
Para ayudarlo con los ejercicios de dimensionamiento de vSAN, la herramienta de vSAN Sizer es una manera excelente y fácil de utilizar. Esta herramienta tiene en cuenta algunos de los elementos discutidos anteriormente. Esta herramienta se actualiza constantemente para ayudar a facilitar resultados de dimensionamiento más rápidos, de una manera más simplificada.
Hasta vSAN 6.7, SwapThickProvision estaba habilitado de forma predeterminada, lo que significa que el espacio de intercambio creado por las máquinas virtuales basado en RAM/reservas de memoria era aprovisionado al 100% (thick provisioned). A partir de vSAN 6.7, esta configuración está deshabilitada de forma predeterminada, lo que hace que el swap sea creado con aprovisionamiento delgado (thin provisioned) por defecto. Consulte la descripción técnica de vSAN 6.7 en StorageHub. Para versiones anteriores de vSAN, puede cambiar fácilmente esta configuración a través de CLI, PowerCLI, HostProfiles, UI, etc. Más sobre esto aquí.
Consideraciones de Red
Cuando se trata de redes, la versión de vSAN implementada determinará si se usa multicast o unicast para las actualizaciones de membresía de clúster. A partir de vSAN 6.6, el unicast se convirtió en el modo de red elegido. Antes de eso, multicast tenía que configurarse ya sea deshabilitando IGMP o habilitando IGMP y configurando IGMP querier.
Jumbo Frames (MTU 9000), es otra cosa que debe ser considerada. Hay un aumento de rendimiento mediante el uso de jumbo frames, pero para algunas implementaciones, la configuración y la administración pueden convertirse en una gran sobrecarga para el personal. Por lo tanto, si jumbo frames ya está habilitado en el entorno, vSAN los admite. Si jumbo frames no está habilitado, no hay ningún requisito para habilitarlo para vSAN, ya que la leve ganancia de rendimiento puede no justificar la complejidad adicional. Si ha sido implementado, recuerde implementar jumbo frames de extremo a extremo.
Network IO Control es algo que se ha hablado mucho con vSAN. Se recomienda implementar virtual distributed switches con vSAN para implementar NIOC. La licencia de vSAN incluye vDS, y la implementación de NIOC (shares), permitirá que vSAN tenga prioridad en caso de contención de tráfico. Por ejemplo, en una configuración activa/pasiva, una falla en un enlace puede hacer que todos los tipos de tráfico atraviesen un solo enlace, si dicho enlace está saturado, el NIOC podrá darle prioridad al tráfico en función de shares configuradas. Más información en la documentación de NIOC.
Consideraciones de Rendimiento
Cuando se trata de rendimiento, considere las opciones de hardware. En primer lugar, se requiere que el hardware utilizado esté en la Guía de compatibilidad de vSAN VMware (vSAN VCG) como hardware aprobado. El vSAN VCG no solo proporcionará una lista aprobada de hardware, sino que también incluirá las versiones aprobadas de firmware y controladores que se utilizarán. También considere verificar los adaptadores de red dentro de vSphere VCG y asegurarse de que se aplique el nivel adecuado de software, ya que una diferencia entre el nivel del driver y el firmware puede causar problemas.
La selección del disco también es vital. Además de verificar que los dispositivos están en el vSAN VCG, y las clases de resistencia y rendimiento; el protocolo seleccionado tiene una implicación en el rendimiento. Por ejemplo, los dispositivos SATA (SSD) no solo tienen una velocidad de bus más lenta, sino que también tienen un queue depth pequeño en comparación con los dispositivos SAS (SSD). El protocolo SATA también tiene otras desventajas, como el bloqueo de bus, etc. En la mayoría de los casos, las unidades SAS se recomiendan sobre las unidades SATA, por lo que debe seleccionarlas con prudencia.
A medida que se introduce nueva tecnología para los discos (caché y capacidad), algunos diseños de vSAN eliminan la necesidad de un controlador de disco, como es el caso de los dispositivos NVMe. Las rápidas velocidades de procesamiento de estos dispositivos y la eliminación de un posible dispositivo de cuello de botella (HBA) dan como resultado un mayor rendimiento dentro del servidor. Sin embargo, es muy importante prestar mucha atención a otros factores externos como las capacidades de conmutación de red; especialmente tamaños de buffer en los switches de network. Para obtener más información sobre este tema, lea la siguiente actualización. Para todas las configuraciones de NVMe vSAN, los tamaños de buffer pueden desempeñar un papel fundamental según la configuración de los NICs y los requisitos de la aplicación.
El siguiente paso es considerar qué va a respaldar esos dispositivos. Todavía hay algunos controladores RAID en vSAN VCG, pero hay más y más HBA que toman su lugar. No solo los HBA son más baratos, sino que son más simples. No es necesario deshabilitar funciones avanzadas, como es el caso del controlador RAID. Si se necesita un rendimiento adicional, tener HBA adicionales puede ayudar con eso.
Los grupos de discos también pueden desempeñar un papel en el rendimiento. El diseño adecuado de un clúster vSAN también incluye la cantidad de grupos de discos dentro de un host. En general, se recomienda tener dos grupos de discos por nodo vSAN, como mínimo. A medida que se agregan más grupos de discos, aumenta la capacidad de caché, al igual que los dominios de falla. Tener entre dos y cuatro grupos de discos por host, dará un mejor rendimiento.
Es importante tener en cuenta la configuración del BIOS durante una implementación de vSAN. No solo es importante tener la última versión de BIOS durante la implementación de ESXi, sino también que la configuración de rendimiento puede marcar una gran diferencia. La mayoría de los proveedores establecen este perfil en Equilibrado (Balanced), y esto puede causar una reducción del rendimiento de hasta un 30%. Al establecer el perfil de BIOS en Controlado por OS (OS Controlled), y Alto rendimiento (High Performance), se obtendrá un mejor rendimiento en general.
Consideraciones de Escala
El escalamiento suele ser complicado, ya que nadie tiene una bola de cristal para determinar exactamente la tasa de crecimiento o la expansión impredecible. Un enfoque común a esto, es ir con la regla N+1 de tener un host adicional como se explicó anteriormente, pero no rellenar todas las bahías de disco. Este enfoque permite el crecimiento futuro simplemente agregando discos adicionales y grupos de discos; manteniendo un clúster uniforme con la misma generación de CPU, etc. Algunos clientes optan ir por esta ruta, ya que tienen la opción de adquirir discos adicionales como parte de su modelo de gastos operativos, en lugar de tener que solicitar un gasto de capital para agregar más servidores. Este enfoque permite una mayor flexibilidad para las opciones de escala, mientras se mantiene el hardware consistente y la generación de CPU en todo el clúster.
Consideraciones del Dispositivo de Arranque
Por último, pero no menos importante, es bueno tener en cuenta los dispositivos de arranque durante los ejercicios de diseño. Cuando se trata de seleccionar un dispositivo de arranque, algunos aspectos, como el precio, así como la ubicación de los logs y los rastros de vSAN (vSAN traces), son componentes clave que impulsan la decisión de elección del dispositivo de arranque. Los dispositivos M.2 SSD duplicados se están convirtiendo en el dispositivo de arranque preferido; basado en redundancia, resistencia, precio y capacidades de colocación de logs. Una publicación anterior sobre dispositivos de arranque para vSAN, desglosa el costo y registra las consideraciones de ubicación para dichos dispositivos.
Para ver más consideraciones de diseño, consulte la guía de diseño de vSAN.
@GreatWhiteTec
