Este es un mito bastante común en el campo del hardware de servidores. En la práctica, se necesitan soluciones hiperconvergentes (cuando todo está en uno) para muchas cosas. Históricamente, las primeras arquitecturas fueron desarrolladas por Amazon y Google para sus servicios. Entonces surgió la idea de crear una granja de computación a partir de nodos idénticos, cada uno de los cuales tenía sus propios discos. Todo esto estaba unido por algún software formador de sistemas (hipervisor) y dividido en máquinas virtuales. El objetivo principal es un mínimo de esfuerzo para dar servicio a un nodo y un mínimo de problemas al escalar: simplemente compre otros mil o dos servidores iguales y conéctelos cerca. En la práctica, estos son casos aislados, y mucho más a menudo estamos hablando de un número menor de nodos y una arquitectura ligeramente diferente.
Pero la ventaja sigue siendo la misma: increíble facilidad de escalado y gestión. La desventaja es que diferentes tareas consumen recursos de manera diferente, y en algunos lugares habrá muchos discos locales, en otros habrá poca RAM, etc., es decir, para diferentes tipos de tareas, la utilización de recursos disminuirá.
Resulta que paga entre un 10% y un 15% más por la facilidad de configuración. Esto es lo que desató el mito del título. Pasamos mucho tiempo buscando dónde se aplicaría de manera óptima la tecnología y lo encontramos. El caso es que Cisco no tenía sistemas de almacenamiento propios, pero quería un mercado de servidores completo. Y crearon Cisco Hyperflex, una solución con almacenamiento local en nodos.
Y de repente resultó ser una muy buena solución para los centros de datos de respaldo (Recuperación de desastres). Te diré por qué y cómo ahora. Y les mostraré las pruebas de clúster.
Donde sea necesario
La hiperconvergencia es:
- Transferir discos a nodos de computación.
- Integración total del subsistema de almacenamiento con el subsistema de virtualización.
- Transferencia/integración con el subsistema de red.
Esta combinación le permite implementar muchas funciones del sistema de almacenamiento a nivel de virtualización y todo desde una ventana de control.
En nuestra empresa, los proyectos para diseñar centros de datos redundantes tienen una gran demanda y, a menudo, se elige una solución hiperconvergente debido a la gran cantidad de opciones de replicación (hasta un metrocluster) listas para usar.
En el caso de los centros de datos de respaldo, generalmente hablamos de una instalación remota en un sitio al otro lado de la ciudad o en otra ciudad completamente. Le permite restaurar sistemas críticos en caso de una falla parcial o total del centro de datos principal. Los datos de ventas se replican allí constantemente, y esta replicación puede ser a nivel de aplicación o a nivel de dispositivo de bloque (almacenamiento).
Por lo tanto, ahora hablaré sobre el diseño y las pruebas del sistema, y luego sobre un par de escenarios de aplicación de la vida real con datos de ahorro.
Pruebas
Nuestra instancia consta de cuatro servidores, cada uno de los cuales tiene 10 unidades SSD de 960 GB. Hay un disco dedicado para almacenar en caché las operaciones de escritura y almacenar la máquina virtual del servicio. La solución en sí es la cuarta versión. El primero es francamente tosco (a juzgar por las revisiones), el segundo está húmedo, el tercero ya es bastante estable y este puede considerarse un lanzamiento después del final de las pruebas beta para el público en general. Durante las pruebas no vi ningún problema, todo funciona como un reloj.
Cambios en v4Se han solucionado un montón de errores.
Inicialmente, la plataforma solo podía funcionar con el hipervisor VMware ESXi y admitía una pequeña cantidad de nodos. Además, el proceso de implementación no siempre terminaba exitosamente, algunos pasos tuvieron que reiniciarse, hubo problemas con la actualización de versiones anteriores, los datos en la GUI no siempre se mostraban correctamente (aunque todavía no estoy satisfecho con la visualización de los gráficos de rendimiento). ), a veces surgían problemas en la interfaz con la virtualización.
Ahora que se han solucionado todos los problemas de la infancia, HyperFlex puede manejar tanto ESXi como Hyper-V, además es posible:
- Creando un cluster extendido.
- Creación de un cluster para oficinas sin utilizar Fabric Interconnect, de dos a cuatro nodos (compramos solo servidores).
- Capacidad para trabajar con sistemas de almacenamiento externos.
- Soporte para contenedores y Kubernetes.
- Creación de zonas de disponibilidad.
- Integración con VMware SRM si la funcionalidad integrada no es satisfactoria.
La arquitectura no difiere mucho de las soluciones de sus principales competidores: ellos no crearon una bicicleta. Todo se ejecuta en la plataforma de virtualización VMware o Hyper-V. El hardware está alojado en servidores propietarios de Cisco UCS. Hay quienes odian la plataforma por la relativa complejidad de la configuración inicial, muchos botones, un sistema no trivial de plantillas y dependencias, pero también hay quienes han aprendido Zen, se inspiran en la idea y ya no quieren para trabajar con otros servidores.
Consideraremos la solución para VMware, ya que la solución se creó originalmente para él y tiene más funcionalidad; en el camino se agregó Hyper-V para mantenerse al día con la competencia y cumplir con las expectativas del mercado.
Hay un grupo de servidores llenos de discos. Hay discos para almacenamiento de datos (SSD o HDD, según sus gustos y necesidades), hay un disco SSD para almacenamiento en caché. Al escribir datos en el almacén de datos, los datos se guardan en la capa de almacenamiento en caché (disco SSD dedicado y RAM de la VM del servicio). En paralelo, se envía un bloque de datos a los nodos del clúster (la cantidad de nodos depende del factor de replicación del clúster). Después de la confirmación de todos los nodos sobre la grabación exitosa, la confirmación de la grabación se envía al hipervisor y luego a la VM. Los datos grabados se deduplican, se comprimen y se escriben en discos de almacenamiento en segundo plano. Al mismo tiempo, siempre se escribe un bloque grande en los discos de almacenamiento y de forma secuencial, lo que reduce la carga en los discos de almacenamiento.
La deduplicación y la compresión siempre están habilitadas y no se pueden deshabilitar. Los datos se leen directamente desde los discos de almacenamiento o desde la memoria caché de la RAM. Si se utiliza una configuración híbrida, las lecturas también se almacenan en caché en el SSD.
Los datos no están vinculados a la ubicación actual de la máquina virtual y se distribuyen uniformemente entre los nodos. Este enfoque le permite cargar todos los discos e interfaces de red por igual. Existe una desventaja obvia: no podemos reducir la latencia de lectura tanto como sea posible, ya que no hay garantía de disponibilidad de datos localmente. Pero creo que este es un sacrificio menor comparado con los beneficios recibidos. Además, los retrasos en la red han alcanzado valores tales que prácticamente no afectan el resultado general.
Un controlador de plataforma de datos Cisco HyperFlex de VM de servicio especial, que se crea en cada nodo de almacenamiento, es responsable de toda la lógica de operación del subsistema de disco. En nuestra configuración de VM de servicio se asignaron ocho vCPU y 72 GB de RAM, lo cual no es tan poco. Permítanme recordarles que el host en sí tiene 28 núcleos físicos y 512 GB de RAM.
La VM de servicio tiene acceso a los discos físicos directamente al reenviar el controlador SAS a la VM. La comunicación con el hipervisor se produce a través de un módulo especial IOVisor, que intercepta las operaciones de E/S y mediante un agente que permite enviar comandos a la API del hipervisor. El agente es responsable de trabajar con instantáneas y clones de HyperFlex.
Los recursos de disco se montan en el hipervisor como recursos compartidos NFS o SMB (según el tipo de hipervisor, adivine cuál está y dónde). Y bajo el capó, este es un sistema de archivos distribuido que le permite agregar características de sistemas de almacenamiento completos para adultos: asignación de volúmenes delgados, compresión y deduplicación, instantáneas que usan tecnología Redirect-on-Write, replicación sincrónica/asincrónica.
La máquina virtual de servicio proporciona acceso a la interfaz de administración WEB del subsistema HyperFlex. Existe integración con vCenter y la mayoría de las tareas cotidianas se pueden realizar desde él, pero es más conveniente cortar los almacenes de datos, por ejemplo, desde una cámara web separada si ya ha cambiado a una interfaz HTML5 rápida o utiliza un cliente Flash completo. con plena integración. En la cámara web de servicio puede ver el rendimiento y el estado detallado del sistema.
Hay otro tipo de nodo en un clúster: los nodos informáticos. Pueden ser servidores en rack o blade sin discos integrados. Estos servidores pueden ejecutar máquinas virtuales cuyos datos se almacenan en servidores con discos. Desde el punto de vista del acceso a los datos, no existe diferencia entre los tipos de nodos, porque la arquitectura implica la abstracción de la ubicación física de los datos. La proporción máxima entre nodos informáticos y nodos de almacenamiento es 2:1.
El uso de nodos de computación aumenta la flexibilidad al escalar los recursos del clúster: no tenemos que comprar nodos adicionales con discos si solo necesitamos CPU/RAM. Además, podemos agregar una jaula para blades y ahorrar en la colocación de servidores en rack.
Como resultado, tenemos una plataforma hiperconvergente con las siguientes características:
- Hasta 64 nodos en un clúster (hasta 32 nodos de almacenamiento).
- La cantidad mínima de nodos en un clúster es tres (dos para un clúster Edge).
- Mecanismo de redundancia de datos: duplicación con factor de replicación 2 y 3.
- Clúster metropolitano.
- Replicación asincrónica de VM a otro clúster HyperFlex.
- Orquestación de conmutación de máquinas virtuales a un centro de datos remoto.
- Instantáneas nativas que utilizan tecnología Redirect-on-Write.
- Hasta 1 PB de espacio utilizable con factor de replicación 3 y sin deduplicación. No tomamos en cuenta el factor de replicación 2, porque esta no es una opción para ventas serias.
Otra gran ventaja es la facilidad de gestión e implementación. Todas las complejidades de la configuración de servidores UCS están a cargo de una máquina virtual especializada preparada por ingenieros de Cisco.
Configuración del banco de pruebas:
- 2 x Cisco UCS Fabric Interconnect 6248UP como clúster de administración y componentes de red (48 puertos que funcionan en modo Ethernet 10G/FC 16G).
- Cuatro servidores Cisco UCS HXAF240 M4.
Características del servidor:
CPU
2 procesadores Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400 MHz RDIMM/PC4-19200/doble rango/x4/1.2 v
Nuestra red
UCSC-MLOM-CSC-02 (VIC 1227). 2 puertos Ethernet de 10G
Almacenamiento HBA
Controlador de paso SAS modular Cisco 12G
Discos de almacenamiento
1 SSD Intel S3520 de 120 GB, 1 SSD Samsung MZ-IES800D, 10 SSD Samsung PM863a de 960 GB
Más opciones de configuraciónAdemás del hardware seleccionado, actualmente están disponibles las siguientes opciones:
- HXAF240c M5.
- Una o dos CPU que van desde Intel Silver 4110 hasta Intel Platinum I8260Y. Segunda generación disponible.
- 24 slots de memoria, tiras desde 16 GB RDIMM 2600 hasta 128 GB LRDIMM 2933.
- De 6 a 23 discos de datos, un disco de caché, un disco de sistema y un disco de arranque.
Unidades de capacidad
- HX-SD960G61X-EV SSD SATA 960G de valor empresarial de 2.5 GB y 6 pulgadas (resistencia 1X) SAS de 960 GB.
- HX-SD38T61X-EV SSD SATA 3.8G de valor empresarial de 2.5 TB y 6 pulgadas (resistencia 1X) SAS de 3.8 TB.
- Unidades de almacenamiento en caché
- HX-NVMEXPB-I375 Unidad Intel Optane de 375 GB y 2.5 pulgadas, rendimiento y resistencia extremos.
- HX-NVMEHW-H1600* Ent. de 1.6 TB y 2.5 pulgadas. Rendimiento. SSD NVMe (resistencia 3X) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400 GB 2.5 pulgadas Ent. Rendimiento. SSD SAS 12G (resistencia 10X) SAS 400 GB.
- HX-SD800GBENK9** 800 GB 2.5 pulgadas Ent. Rendimiento. SSD SED SAS 12G (resistencia 10X) SAS 800 GB.
- HX-SD16T123X-EP SSD SAS 1.6G de rendimiento empresarial de 2.5 TB y 12 pulgadas (resistencia 3X).
Unidades de sistema/registro
- HX-SD240GM1X-EV SSD SATA 240G Enterprise Value de 2.5 GB y 6 pulgadas (requiere actualización).
Unidades de arranque
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240GB.
Conéctese a la red a través de puertos Ethernet 40G, 25G o 10G.
La FI puede ser HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
La prueba en sí
Para probar el subsistema de disco, utilicé HCIBench 2.2.1. Esta es una utilidad gratuita que le permite automatizar la creación de una carga desde múltiples máquinas virtuales. La carga en sí es generada por el fio habitual.
Nuestro clúster consta de cuatro nodos, factor de replicación 3, todos los discos son Flash.
Para las pruebas, creé cuatro almacenes de datos y ocho máquinas virtuales. Para las pruebas de escritura, se supone que el disco de caché no está lleno.
Los resultados de la prueba son los siguientes:
100% leído 100% aleatorio
0% Leer 100%Aleatorio
Profundidad de bloque/cola
128
256
512
1024
2048
128
256
512
1024
2048
4K
0,59 ms 213804 IOPS
0,84 ms 303540 IOPS
1,36 ms 374348 IOPS
2.47 ms 414116 IOPS
4,86 ms 420180 IOPS
2,22 ms 57408 IOPS
3,09 ms 82744 IOPS
5,02 ms 101824 IPOS
8,75 ms 116912 IOPS
17,2 ms 118592 IOPS
8K
0,67 ms 188416 IOPS
0,93 ms 273280 IOPS
1,7 ms 299932 IOPS
2,72 ms 376,484 IOPS
5,47 ms 373,176 IOPS
3,1 ms 41148 IOPS
4,7 ms 54396 IOPS
7,09 ms 72192 IOPS
12,77 ms 80132 IOPS
16K
0,77 ms 164116 IOPS
1,12 ms 228328 IOPS
1,9 ms 268140 IOPS
3,96 ms 258480 IOPS
3,8 ms 33640 IOPS
6,97 ms 36696 IOPS
11,35 ms 45060 IOPS
32K
1,07 ms 119292 IOPS
1,79 ms 142888 IOPS
3,56 ms 143760 IOPS
7,17 ms 17810 IOPS
11,96 ms 21396 IOPS
64K
1,84 ms 69440 IOPS
3,6 ms 71008 IOPS
7,26 ms 70404 IOPS
11,37 ms 11248 IOPS
Negrita indica valores después de los cuales no hay aumento en la productividad, a veces incluso la degradación es visible. Esto se debe al hecho de que estamos limitados por el rendimiento de la red/controladores/discos.
- Lectura secuencial 4432 MB/s.
- Escritura secuencial 804 MB/s.
- Si falla un controlador (fallo de una máquina virtual o un host), la caída del rendimiento es doble.
- Si el disco de almacenamiento falla, la reducción es 1/3. La reconstrucción del disco requiere el 5% de los recursos de cada controlador.
En un bloque pequeño, estamos limitados por el rendimiento del controlador (máquina virtual), su CPU está cargada al 100% y cuando el bloque aumenta, estamos limitados por el ancho de banda del puerto. 10 Gbps no son suficientes para desbloquear el potencial del sistema AllFlash. Desafortunadamente, los parámetros del soporte de demostración proporcionado no nos permiten probar el funcionamiento a 40 Gbit/s.
En mi impresión de las pruebas y el estudio de la arquitectura, gracias al algoritmo que coloca los datos entre todos los hosts, obtenemos un rendimiento escalable y predecible, pero esto también es una limitación a la hora de leer, porque sería posible exprimir más de los discos locales. aquí puede salvar una red más productiva, por ejemplo, está disponible FI a 40 Gbit/s.
Además, un disco para almacenamiento en caché y deduplicación puede ser una limitación; de hecho, en este banco de pruebas podemos escribir en cuatro discos SSD. Sería fantástico poder aumentar la cantidad de unidades de almacenamiento en caché y ver la diferencia.
uso real
Para organizar un centro de datos de respaldo, puede utilizar dos enfoques (no consideramos colocar una copia de seguridad en un sitio remoto):
- Activo pasivo. Todas las aplicaciones están alojadas en el centro de datos principal. La replicación es sincrónica o asincrónica. Si el centro de datos principal falla, debemos activar el de respaldo. Esto se puede hacer manualmente/guiones/aplicaciones de orquestación. Aquí obtendremos un RPO acorde con la frecuencia de replicación, y el RTO depende de la reacción y las habilidades del administrador y la calidad del desarrollo/depuración del plan de conmutación.
- Activo-Activo. En este caso, solo hay replicación sincrónica; la disponibilidad de los centros de datos está determinada por un quórum/árbitro ubicado estrictamente en el tercer sitio. RPO = 0 y RTO puede llegar a 0 (si la aplicación lo permite) o igual al tiempo de conmutación por error de un nodo en un clúster de virtualización. En el nivel de virtualización, se crea un clúster extendido (Metro) que requiere almacenamiento Activo-Activo.
Generalmente vemos que los clientes ya han implementado una arquitectura con un sistema de almacenamiento clásico en el centro de datos principal, por lo que diseñamos otro para replicación. Como mencioné, Cisco HyperFlex ofrece replicación asíncrona y creación de clústeres de virtualización ampliada. Al mismo tiempo, no necesitamos un sistema de almacenamiento dedicado de nivel medio y superior con costosas funciones de replicación y acceso a datos activo-activo en dos sistemas de almacenamiento.
Script 1: Contamos con centros de datos primarios y de respaldo, una plataforma de virtualización en VMware vSphere. Todos los sistemas productivos están ubicados en el centro de datos principal y la replicación de las máquinas virtuales se realiza a nivel de hipervisor, esto evitará mantener las VM encendidas en el centro de datos de respaldo. Replicamos bases de datos y aplicaciones especiales utilizando herramientas integradas y mantenemos las máquinas virtuales encendidas. Si el centro de datos principal falla, lanzamos sistemas en el centro de datos de respaldo. Creemos que tenemos alrededor de 100 máquinas virtuales. Mientras el centro de datos principal está operativo, el centro de datos en espera puede ejecutar entornos de prueba y otros sistemas que pueden apagarse si el centro de datos principal cambia. También es posible que utilicemos replicación bidireccional. Desde el punto de vista del hardware, nada cambiará.
En el caso de la arquitectura clásica, instalaremos en cada centro de datos un sistema de almacenamiento híbrido con acceso vía FibreChannel, tiering, deduplicación y compresión (pero no online), 8 servidores para cada sitio, 2 switches FibreChannel y Ethernet 10G. Para la gestión de replicación y conmutación en una arquitectura clásica, podemos utilizar herramientas de VMware (Replicación + SRM) o herramientas de terceros, que serán un poco más económicas y, en ocasiones, más convenientes.
La figura muestra el diagrama.
Al utilizar Cisco HyperFlex, se obtiene la siguiente arquitectura:
Para HyperFlex, utilicé servidores con grandes recursos de CPU/RAM, porque... Algunos de los recursos irán a la VM del controlador HyperFlex; en términos de CPU y memoria, incluso reconfigure un poco la configuración de HyperFlex para no seguir el juego de Cisco y garantizar recursos para las VM restantes. Pero podemos abandonar los conmutadores FibreChannel y no necesitaremos puertos Ethernet para cada servidor; el tráfico local se conmuta dentro de FI.
El resultado fue la siguiente configuración para cada centro de datos:
Servidores
8 servidores de 1U (384 GB de RAM, 2 Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 GB de RAM, 2 x Intel Gold 6150, SSD de 3,2 GB, 10 x 6 TB NL-SAS)
Almacenamiento
Sistema de almacenamiento híbrido con FC Front-End (SSD de 20 TB, NL-SAS de 130 TB)
-
LAN
2 x conmutador Ethernet 10G 12 puertos
-
SAN
2 x conmutador FC 32/16Gb 24 puertos
2 x Cisco UCS FI 6332
Licencias
VMware EntPlus
Replicación y/u orquestación de conmutación de VM
VMware EntPlus
No proporcioné licencias de software de replicación para Hyperflex, ya que está disponible para nosotros.
Para la arquitectura clásica elegí un proveedor que se ha consolidado como un fabricante económico y de alta calidad. Para ambas opciones, apliqué el descuento estándar para una solución específica y como resultado obtuve precios reales.
La solución Cisco HyperFlex resultó ser un 13% más barata.
Script 2: Creación de dos centros de datos activos. En este escenario, estamos diseñando un clúster ampliado en VMware.
La arquitectura clásica consta de servidores de virtualización, una SAN (protocolo FC) y dos sistemas de almacenamiento que pueden leer y escribir en el volumen que se extiende entre ellos. A cada sistema de almacenamiento le ponemos una capacidad útil para el almacenamiento.
En HyperFlex simplemente creamos un Stretch Cluster con la misma cantidad de nodos en ambos sitios. En este caso, se utiliza un factor de replicación de 2+2.
El resultado es la siguiente configuración:
arquitectura clásica
HiperFlex
Servidores
Servidor de 16 x 1U (384 GB de RAM, 2 x Intel Gold 6132, FC HBA, 2 x NIC 10G)
16 x HX240C-M5L (512 GB de RAM, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)
Almacenamiento
2 x sistemas de almacenamiento AllFlash (SSD de 150 TB)
-
LAN
4 x conmutador Ethernet 10G 24 puertos
-
SAN
4 x conmutador FC 32/16Gb 24 puertos
4 x Cisco UCS FI 6332
Licencias
VMware EntPlus
VMware EntPlus
En todos los cálculos no tuve en cuenta la infraestructura de red, los costes del centro de datos, etc.: serán los mismos para la arquitectura clásica y para la solución HyperFlex.
En términos de costo, HyperFlex resultó ser un 5% más caro. Vale la pena señalar aquí que en términos de recursos de CPU/RAM tenía un sesgo hacia Cisco, porque en la configuración llené los canales del controlador de memoria de manera uniforme. El costo es ligeramente mayor, pero no en un orden de magnitud, lo que indica claramente que la hiperconvergencia no es necesariamente un "juguete para los ricos", pero puede competir con el enfoque estándar para construir un centro de datos. Esto también puede ser de interés para quienes ya cuentan con servidores Cisco UCS y la infraestructura correspondiente para los mismos.
Entre las ventajas, obtenemos la ausencia de costos de administración de SAN y sistemas de almacenamiento, compresión y deduplicación en línea, un único punto de entrada para soporte (virtualización, servidores, también son sistemas de almacenamiento), ahorro de espacio (pero no en todos los escenarios), simplificando la operación.
En cuanto al soporte, aquí lo obtiene de un proveedor: Cisco. A juzgar por mi experiencia con los servidores Cisco UCS, me gusta, no tuve que abrirlo en HyperFlex, todo funcionó igual. Los ingenieros responden rápidamente y pueden resolver no solo problemas típicos, sino también casos extremos complejos. A veces me dirijo a ellos con preguntas: "¿Es posible hacer esto, atornillarlo?" o “Configuré algo aquí y no quiere funcionar. ¡Ayuda!" - allí encontrarán pacientemente la guía necesaria y les indicarán las acciones correctas, no responderán: "Sólo solucionamos problemas de hardware".
referencias
- Mi correo - [email protected]
Fuente: habr.com