¿Por qué hiperconvergencia? Descripción general y pruebas de Cisco HyperFlex

En TI, lo principal son tres letras


La tarea de cualquier infraestructura de TI es proporcionar una plataforma confiable para los procesos comerciales de la empresa. Tradicionalmente se cree que la calidad de la infraestructura de tecnología de la información se evalúa de acuerdo con tres parámetros principales: accesibilidad, seguridad, confiabilidad. Sin embargo, la evaluación de este triple no está relacionada de ninguna manera con el negocio y los ingresos / pérdidas directas de la empresa.

Tres letras principales rigen la TI. Si las letras "RUB" no están al frente de la jerarquía de TI, entonces está construyendo su infraestructura de TI incorrectamente. Por supuesto, es difícil construir TI directamente, comenzando solo por los ingresos / gastos, por lo tanto, existe una jerarquía de "tres letras", desde las más importantes hasta las más privadas. SLA, RPO, RTO, GRC: todo esto es conocido por los expertos de la industria y se ha utilizado durante mucho tiempo en la construcción de infraestructuras. Desafortunadamente, no siempre se vinculan estos indicadores en una jerarquía de extremo a extremo.



Muchas empresas hoy en día están construyendo infraestructura para el futuro utilizando la tecnología de ayer en la arquitectura de ayer. Y al mismo tiempo, el desarrollo acelerado de TI muestra que los servicios modernos están cambiando fundamentalmente no solo los negocios sino también la sociedad: las personas de la era digital están acostumbradas al hecho de que unos segundos son suficientes para acceder a cualquier información. La tecnología de la información de una tecnología incomprensible se ha convertido en un lugar común para las masas, como una hamburguesa o una cafetería. Esto ha agregado tres letras extremadamente importantes a TI. Estas cartas - TTM (Time to market) - el tiempo antes del lanzamiento de un servicio productivo en el mercado.



Sds


Por otro lado, un kraken surgió de las profundidades de la tecnología, volcando la TI y el estilo de vida tradicionales. A medida que crecía la potencia informática de los procesadores x86, los sistemas de almacenamiento de software se convirtieron en el primer tentáculo. Los sistemas de almacenamiento clásicos eran piezas de hierro muy específicas llenas de "silicio personalizado", varios aceleradores de hardware patentados y software especializado. Y fue administrado por una persona especialmente entrenada que era prácticamente adorada en la compañía como sacerdote de un culto oscuro. Ampliar el sistema de almacenamiento de datos que operaba en la empresa fue un proyecto completo, con muchos cálculos y aprobaciones. Después de todo, ¡es costoso!

El alto costo y la complejidad impulsaron la creación de sistemas de almacenamiento de software sobre el hardware x86 habitual con un sistema operativo común de uso general: Windows, Linux, FreeBSD o Solaris. Solo quedaba software del complejo hardware personalizado, que funcionaba ni siquiera en el núcleo, sino a nivel de usuario. Los primeros sistemas de software eran, por supuesto, bastante simples y de funcionalidad limitada, a menudo eran soluciones especializadas de nicho, pero el tiempo pasó. Y ahora, incluso los grandes proveedores de sistemas de almacenamiento han comenzado a abandonar las soluciones de hardware especializadas: TTM para tales sistemas ya no podía soportar la competencia, y el costo del error se volvió muy alto. De hecho, con raras excepciones, incluso los sistemas de almacenamiento clásicos para 2020 se convirtieron en los servidores x86 más comunes, solo con hermosos bozales de plástico y un montón de estantes de disco.

El segundo tentáculo del kraken que se aproxima es la aparición y la adopción masiva por parte del mercado de la tecnología de memoria flash, que se ha convertido en un pilar concreto que rompe la espalda de un elefante.
El rendimiento de los discos magnéticos no ha cambiado en muchos años y los procesadores de los controladores de almacenamiento se las arreglaron completamente con cientos de discos. Pero, por desgracia, la cantidad tarde o temprano se convertirá en calidad, y el sistema de almacenamiento ya está en un nivel promedio, sin mencionar el inicial, tiene un límite superior en el número significativo de unidades flash. Con una cierta cantidad (literalmente de diez discos), el rendimiento del sistema no deja de crecer, pero también puede comenzar a disminuir debido a la necesidad de procesar un volumen cada vez mayor. Después de todo, la potencia de procesamiento y el rendimiento de los controladores no cambian con el aumento de la capacidad. La solución, en teoría, fue la aparición de sistemas escalables que pueden ensamblar muchos estantes independientes con discos y recursos de procesador en un solo clúster que se ve desde el exterior como un único sistema de almacenamiento de múltiples controladores. Solo quedaba un paso.

Hiperconvergencia


El paso más obvio hacia el futuro fue la unificación de puntos de procesamiento y almacenamiento de datos previamente dispares. En otras palabras, ¿por qué no implementar almacenamiento distribuido no en servidores separados, sino directamente en los hosts de virtualización, rechazando así una red de almacenamiento especial y hardware dedicado, y combinando así funciones? El kraken se despertó.
Pero déjame decirte, ya ves, porque la combinación es la convergencia. ¿De dónde vino este estúpido prefijo hiper?
. + + . . , “ ”.

, , , . — SDS.

:

  • — , , , /. .
  • Sistema convergente: todo de una fuente, un soporte, un número de socio. No debe confundirse con el autoensamblaje de un proveedor.

Y resulta que el término para nuestra arquitectura convergente ya está tomado. Exactamente la misma situación que con el supervisor.

Sistema hiperconvergente: un sistema convergente con arquitectura convergente.

Las definiciones están tomadas del artículo " Teoría general y arqueología de la virtualización ", en el que tomé parte animada.

¿Qué da el enfoque hiperconvergente en la aplicación a las tres letras mencionadas?

  • Comience con un volumen mínimo (y un costo mínimo)
  • La capacidad de almacenamiento crece con la potencia informática
  • Cada nodo del sistema es su controlador, y se elimina el problema del "techo de cristal" (los discos pueden, pero el controlador ya no existe)
  • La gestión del almacenamiento se simplificó dramáticamente

Para el último párrafo, a los sistemas hiperconvergentes les disgustan mucho los administradores de almacenamiento en modo antiguo que se utilizan para administrar colas en puertos Fibre Channel. El espacio se asigna con solo unos pocos clics del mouse desde la consola de administración de infraestructura virtual.

En otras palabras, solo las nubes son más rápidas que los sistemas hiperconvergentes al lanzar un producto, pero las nubes no son adecuadas para todos y / o no siempre.

Si usted es un administrador técnico y leyó hasta aquí, alégrate, las palabras generales han terminado y ahora te contaré sobre mi visión personal del sistema Cisco Hyperflex, que obtuve en las patas tenaces para realizar varias pruebas en él.

Cisco Hyperflex


¿Por qué Cisco?


Cisco es conocido principalmente como el proveedor dominante en el mercado de equipos de red, pero al mismo tiempo está ampliamente presente en otros segmentos del mercado de centros de datos, ofreciendo soluciones de servidor e hiperconvergentes, así como sistemas de automatización y control.

Sorprendentemente, para 2020, todavía hay personas: “¿Servidores Cisco? ¿Y de quién se los quita?
Cisco comenzó a tratar con servidores ya en 2009, eligiendo el camino de las soluciones blade de crecimiento activo en ese momento. La idea de Cisco era implementar el enfoque de calculadoras anónimas. El resultado fue un sistema UCS (Unified Computing System) que consta de dos conmutadores especializados (se llamaron Fabric Interconnect) y de 1 a 20 chasis (8 blades de tamaño medio) o hasta 160 servidores. Al mismo tiempo, el chasis se volvió generalmente estúpido con una pieza de hierro con alimentación, toda la lógica y la conmutación se realizan en Fabric Interconnect; El chasis es solo una forma de alojar servidores y conectarlos al sistema. Fabric Interconnect es totalmente responsable de todas las interacciones del servidor con el mundo exterior: Ethernet, FC y administración. Parecería que los blades y blades, lo que hay allí, excepto la conmutación externa, y no como todos los demás en el chasis.

Un momento clave en la implementación de esas mismas "calculadoras anónimas". Como parte del concepto Cisco UCS, los servidores no tienen otra personalidad que un número de serie. Ni MAC, ni WWN, ni nada más. El sistema de administración UCS con tecnología de Fabric Interconnect se basa en perfiles y plantillas de servidor. Después de conectar un conjunto de servidores en el chasis, se les debe asignar un perfil apropiado, dentro del cual se configuran todas las direcciones e identificadores. Por supuesto, si solo tienes una docena de servidores, entonces el juego no valdría la pena. Pero cuando hay al menos dos, o incluso tres docenas, es una gran ventaja. Es fácil y rápido migrar configuraciones o, lo que es más importante, replicar configuraciones de servidor en la cantidad correcta, aplicar los cambios inmediatamente a una gran cantidad de servidores,esencialmente administrando un conjunto de servidores (por ejemplo, una granja de virtualización) como una sola entidad. El enfoque propuesto dentro del sistema UCS permite, con el enfoque correcto, simplificar seriamente la vida de los administradores, aumentar la flexibilidad y reducir significativamente los riesgos, por lo que los blades UCS literalmente en 2-3 años se han convertido en la plataforma blade más vendida en el Hemisferio Occidental, y hoy son globalmente Una de las dos plataformas dominantes, junto con HPE.

Rápidamente se hizo evidente que el mismo enfoque basado en una fábrica universal con gestión integrada basada en políticas y plantillas es totalmente demandado y se aplica no solo a los blades, sino también a los servidores en rack. Y en este sentido, los servidores de montaje en bastidor de Cisco conectados a Fabric Interconnect obtienen los mismos beneficios que hacen que los blades sean tan populares.

Hoy hablaré sobre HyperFlex, una solución hiperconvergente de Cisco construida en servidores de montaje en rack conectados a Fabric Interconnect. Lo que hace que HyperFlex sea interesante y que valga la pena considerar en la revisión:

  • Cisco , , «» – , HyperFlex; , , , HyperFlex ;
  • – ; HyperFlex , , ; , .
  • « » — « », , ;
  • Fabric Interconnect Cisco -, SAN , native FC;
  • “” – , , ;
  • Cisco , , , ;
  • , , Cisco HCI, , HyperFlex , , .


HyperFlex es un verdadero sistema hiperconvergente con máquinas virtuales dedicadas al controlador. Permítame recordarle que la principal ventaja de tal arquitectura es su portabilidad potencial para diferentes hipervisores. Hoy, Cisco ha implementado el soporte para VMware ESXi y Microsoft Hyper-V, pero es posible que una de las opciones de KVM aparezca a medida que su popularidad crezca en el segmento corporativo.

Considere el mecanismo de trabajo en el ejemplo de ESXi.

Los dispositivos que utilizan la tecnología VM_DIRECT_PATH (disco de caché y discos de nivel de almacenamiento) se lanzan directamente a la VM del controlador (en adelante CVM). Por lo tanto, excluimos el efecto de la pila de disco del hipervisor en el rendimiento. Se instalan paquetes VIB adicionales en el propio hipervisor:

  • IO Visor: proporciona el punto de montaje para el almacén de datos NFS para el hipervisor
  • VAAI: VMware API « »

Los bloques de disco virtual se distribuyen uniformemente entre todos los hosts en un clúster con relativamente poca granularidad. Cuando la VM en el host realiza algunas operaciones de disco, a través de la pila de discos del hipervisor, la operación va al almacén de datos, luego a IO Visor y luego se convierte en el CVM responsable de estos bloques. En este caso, CVM puede ubicarse en cualquier host del clúster. Dados los recursos muy limitados de IO Visor, por supuesto no hay tablas de metadatos y la elección se determina matemáticamente. Luego, el CVM al que llegó la solicitud la procesa. En el caso de la lectura, envía datos desde uno de los niveles de caché (RAM, caché de escritura, caché de lectura) o desde los discos de su host. En el caso de la grabación, escribe en el diario local y duplica la operación para uno (RF2) o dos (RF3) CVM.



Quizás esto sea suficiente para comprender el principio del trabajo dentro del marco de esta publicación, de lo contrario tomaré el pan de los entrenadores de Cisco y me avergonzaré. En realidad no, pero sí lo suficiente.

Pregunta sobre pruebas sintéticas



- Navegador, electrodomésticos!
- 36!
- ¿Qué es 36?
- ¿Qué pasa con los electrodomésticos?

Algo así parece hoy la mayoría de las pruebas sintéticas de los sistemas de almacenamiento. ¿Porqué es eso?

Hasta hace relativamente poco, la mayoría de los sistemas de almacenamiento eran planos con acceso uniforme. ¿Qué significa esto?

El espacio total disponible en el disco se recopiló de discos con las mismas características. Por ejemplo, 300 unidades de 15k. Y el rendimiento fue el mismo en todo el espacio. Con el advenimiento de la tecnología de almacenamiento en niveles, los sistemas de almacenamiento se han vuelto no planos: el rendimiento varía dentro de un solo espacio de disco. Y no solo es diferente, sino también impredecible, dependiendo de los algoritmos y capacidades de un modelo de almacenamiento en particular.

Y todo no sería tan interesante si no aparecieran sistemas hiperconvergentes con localización de datos. Además de la irregularidad del espacio del disco en sí (tirings, cachés flash), también hay un acceso desigual al mismo, dependiendo de si una de las copias de datos se encuentra en los discos locales del nodo o debe accederse a través de la red. Todo esto lleva al hecho de que el número de pruebas sintéticas puede ser absolutamente cualquiera, y no hablar de nada prácticamente significativo. Por ejemplo, el consumo de combustible de un automóvil según un folleto publicitario que nunca se puede lograr en la vida real.

Pregunta sobre dimensionamiento


El otro lado de los números de prueba sintéticos fue dimensionar números y especificaciones debajo del teclado de preventa. Las preventas en este caso se dividen en dos categorías: algunas simplemente introducen su TK en el configurador del proveedor, y la segunda lo tomarán ellos mismos, porque entienden cómo funciona. Pero con el segundo tendrá que considerar en detalle lo que escribió en su TK.

Como saben, sin un claro TK, el resultado de HZ.



Por experiencia práctica: cuando dimensioné un sistema hiperconvergente bastante pesado en una competencia con uno de los clientes, personalmente, después del piloto, tomé los indicadores de carga del sistema y los comparé con lo que estaba escrito en los TOR. Resultó como en una broma:
- Rabinovich, ¿es cierto que ganaste un millón en la lotería?
- ¿Quién te dijo eso? No un millón, sino diez rublos, no en la lotería, sino de preferencia, y no ganó, sino que perdió.


En otras palabras, la situación clásica de GIGO es Garbage In Garbage Out - Garbage in = Garbage in.

El tamaño práctico aplicable para la hiperconvergencia casi garantiza que sea de dos tipos: llevarnos con un margen, o durante mucho tiempo manejaremos un piloto y tomaremos indicadores.

Hay un punto más con el dimensionamiento y la evaluación de las especificaciones. Los diferentes sistemas se construyen de manera diferente y funcionan de manera diferente con los discos; sus controladores interactúan de manera diferente. Por lo tanto, es prácticamente inútil comparar "cabeza a cabeza" de acuerdo con las especificaciones, el número y el volumen de los discos. Tiene algún tipo de conocimientos tradicionales, dentro del cual comprende el nivel de carga. Y luego hay una cierta cantidad de cajas de cambios, dentro de las cuales se le ofrecen varios sistemas que cumplen con los requisitos de rendimiento y confiabilidad. ¿Cuál es la diferencia fundamental, cuánto cuesta un disco y qué tipo de sistema 1, y que en el sistema 2 hay más / menos de ellos si ambos satisfacen con éxito la tarea?

Dado que el rendimiento a menudo está determinado por los controladores que viven en los mismos hosts que las máquinas virtuales, para algunos tipos de cargas puede flotar de manera significativa simplemente porque los procesadores con diferentes frecuencias se colocan en diferentes grupos, todas las demás cosas son iguales.

En otras palabras, incluso el arquitecto archimago de preventa más experimentado no le dirá la especificación más precisamente de lo que formula los requisitos, y más precisamente, que "bueno, en algún lugar SAM-VOSEM" sin proyectos piloto.



Acerca de las instantáneas


HyperFlex puede hacer sus instantáneas nativas de máquinas virtuales utilizando la tecnología Redirect-on-Write. Y aquí es necesario detenerse por separado para considerar diferentes tecnologías de instantáneas.
Inicialmente, había instantáneas del tipo Copiar en escritura (CoW), y las instantáneas nativas de VMware vSphere se pueden tomar como un ejemplo clásico. El principio de funcionamiento es el mismo con vmdk sobre VMFS o NFS, que con sistemas de archivos nativos como VSAN. Después de crear una instantánea CoW, los datos originales (bloques o archivos vmdk) se congelan, y cuando intenta escribir en bloques congelados, se crea una copia y los datos se escriben en un nuevo bloque / archivo (archivo delta para vmdk). Como resultado, a medida que crece el árbol de instantáneas, aumenta el número de accesos de disco "espurios" que no tienen ningún significado productivo, yel rendimiento cae / los retrasos crecen .

Luego se inventaron las instantáneas Redirect-on-Write (RoW), en las que en lugar de crear copias de bloques con datos, se crea una copia de metadatos, y el registro simplemente continúa sin demoras y lecturas y comprobaciones adicionales. Con la implementación correcta de las instantáneas RoW, el efecto en el sistema de disco es casi nulo. El segundo efecto de trabajar con metadatos en lugar de los datos en vivo no es solo la creación instantánea de instantáneas, sino también los clones de VM, que inmediatamente después de la creación no ocupan espacio en absoluto (no consideramos la sobrecarga del sistema para los archivos de servicio de VM).

Y el tercer punto clave que distingue radicalmente las instantáneas de RoW de CoW para sistemas productivos es la eliminación instantánea de instantáneas. Parece que esto es así? Sin embargo, debe recordar cómo funcionan las instantáneas de CoW y que eliminar una instantánea no es realmente una eliminación delta, sino su confirmación. Y aquí, el momento de su confirmación depende en gran medida del tamaño del delta acumulado y del rendimiento del sistema de disco. Las instantáneas RoW se confirman instantáneamente simplemente porque no importa cuántos terabytes de diferencia se acumulen, eliminar (confirmar) las instantáneas RoW es una actualización de la tabla de metadatos.

Y aquí aparece una aplicación interesante de instantáneas RoW: baje el RPO a valores de decenas de minutos. Hacer copias de seguridad cada 30 minutos es casi imposible en el caso general, y en la mayoría de los casos se realizan una vez al día, lo que da un RPO de 24 horas. Pero al mismo tiempo, solo podemos hacer instantáneas de RoW en un horario, llevando el RPO a 15-30 minutos, y almacenarlas durante un día o dos. No hay penalización para el rendimiento, gastando solo capacidad.

Pero hay algunos matices.

Para el correcto funcionamiento de las instantáneas nativas y la integración con VMware, HyperFlex requiere una instantánea oficial llamada Sentinel. La instantánea de Sentinel se crea automáticamente cuando crea una instantánea para una VM determinada a través de HXConnect, y no debe eliminarla, no debe "volver" a ella, solo tiene que soportar el hecho de que en la interfaz en la lista de instantáneas esta es la primera instantánea de servicio de Sentinel.



Las instantáneas HyperFlex pueden ejecutarse en modo consistente con el bloqueo o en modo consistente con la aplicación. El segundo tipo implica "búferes de vaciado" dentro de la VM, requiere VMTools y se inicia si la casilla de verificación "Quiesce" está marcada en el menú de instantáneas de HXConnect.
Además de las instantáneas HyperFlex, nadie prohíbe el uso de instantáneas VMware "nativas". Vale la pena que una máquina virtual específica determine qué instantáneas usará y, en el futuro, se centre en esta tecnología, "no molestando" diferentes instantáneas para una VM.

Como parte de la prueba, traté de crear instantáneas y verificar su FIO. Y, sin embargo, sí, puedo confirmar que las instantáneas son realmente ROW, no afectan el rendimiento. Las instantáneas se crean realmente rápidamente (unos segundos dependiendo del perfil de carga y el tamaño del conjunto de datos), de acuerdo con los resultados, puedo dar la siguiente recomendación: si su carga tiene muchas operaciones de escritura aleatoria, debe comenzar a crear una instantánea desde la interfaz HXConnect, con la marca de verificación "Quiesce" y con una marca preliminar la presencia de una instantánea de Sentinel.

Pruebas


Plataforma de prueba


La siguiente plataforma cayó en patas tenaces:

  • 4 x C220 M4 (2630v4 10c x 2.20 GHz, 256, 800 + 6 * 960)
  • vSphere 6.7
  • Plataforma de datos HX 4.0.2

Prueba de parche claro


¿Qué tipo de prueba sin CrystalDisk? Así es, esto no puede ser, ¡los chicos normales siempre comienzan un disco cristalizado! Bueno, si es necesario, entonces es necesario.



Para el disco de cristal, se creó una máquina virtual especialmente creada con 2 vCPU de 4 GB y Windows 7 a bordo. Ah, y me cansé de ponerle parches, ¡te lo diré! La prueba se llevó a cabo en las mejores tradiciones de las mejores casas de Londres y París, es decir, se agregó un solo disco virtual siguiente-siguiente-final sin pensarlo y se lanzó la prueba. Sí, y por cierto, CrystalDiskMark en sí no participa en las pruebas, es solo una interfaz, pero carga directamente el sistema de disco con el conocido paquete DiskSpd incluido en el kit.



Lo que me sorprendió literalmente: por alguna razón, todos omitieron la elección de unidades en la esquina superior derecha. Y alle op!



Escucha, sinceramente, ¡no esperaba 75 mil IOPS y más de 1 gigabyte por segundo de la micromáquina en el modo siguiente-siguiente-final!

Para decirlo suavemente, no todas las empresas en Rusia tienen cargas que exceden estos indicadores en total.

Se llevaron a cabo más pruebas con VMware HCI Bench y Nutanix XRay, como "ideológicamente hostiles" a HyperFlex, y en consecuencia, se esperaba que no tomáramos prisioneros. Los números resultaron ser extremadamente cercanos, por lo que los resultados del paquete XRay se tomaron como base simplemente porque tiene un sistema de informes más conveniente y plantillas de carga listas para usar.

Para aquellos que no confían en nadie y desean un control total sobre el proceso, les recuerdo mi artículo sobre cómo construir su propio sistema para generar la carga en una plataforma hiperconvergente: "Pruebas de rendimiento de los sistemas giperkonvergentnyh y SDS con sus propias manos "

Achtung! Uwaga! Pozor!


Todos los resultados adicionales y sus interpretaciones son la opinión del autor del artículo, y se dan por sí mismos en el marco del estudio del sistema. La mayoría de las pruebas son sintéticas y solo son aplicables para comprender los indicadores de límite en casos extremos y degenerados, que nunca alcanzará en la vida real.

Microbench FourCorners


El microtest de 4 lados está diseñado para evaluar el sistema "rápidamente" para obtener el máximo rendimiento teórico y el máximo rendimiento de los controladores. La aplicación práctica para esta prueba es verificar el sistema inmediatamente después del lanzamiento en busca de errores de configuración y entorno, especialmente errores de red. Aquellos. si ejecuta regularmente tales sistemas, entonces solo sabe qué números debe esperar "si todo está bien".









Números finales: 280k / 174k IOPS, 3.77 / 1.72 GBps (lectura / escritura)

¿Cómo se comportaron nuestros controladores?





De lo que se puede observar que el consumo total de recursos para 4 controladores y 4 cargas de VM fue de 49 núcleos de 2.2. Según las estadísticas de VMware, la utilización de CPU de los controladores fue de hasta el 80%, es decir, de hecho, el rendimiento estaba limitado por el rendimiento de los controladores, y específicamente de los procesadores. La velocidad de las operaciones secuenciales se basaba específicamente en la velocidad de la red 10G.

Intentemoslo de nuevo. El rendimiento máximo en un pequeño clúster de 4 nodos con no los procesadores más rápidos de 2.2GHz es de casi 300 mil IOPS a 4U de altura.

La conversación "aquí tenemos 10, 20 o incluso 40% más / menos" carece prácticamente de sentido debido al orden de los números. Lo mismo que comenzar a medir "y puedo tener un auto 240, tengo 280" a pesar de que el límite es 80.

280k / 4 nodos proporciona un rendimiento máximo de 70k / nodo, que por ejemplo excede los números de la calculadora VMware VSAN, que supone que el nodo AF no emite más de 46k por grupo de discos. En nuestro caso, aquí en la terminología de VMware solo hay un grupo de discos, que en realidad se ejecuta en x1.8.

Efecto del tamaño del bloque del almacén de datos


Al crear un almacén de datos HyperFlex, puede elegir el tamaño del bloque de datos: 4k u 8k.

¿A qué afectará? Ejecute la misma prueba cuadrangular.





Si la imagen es casi idéntica a la lectura, entonces el registro por el contrario importa. La prueba cuadrangular utiliza una carga de 8k.

Números totales: 280k / 280k, 172-158k / 200-180k (4k 8k). Cuando el tamaño del bloque coincide, se obtiene + 15% del rendimiento de escritura. Si espera una cantidad significativa de grabación con un bloque pequeño (4k) en la carga, cree un almacén de datos para esta carga en particular con un bloque de 4k, de lo contrario use 8k.

Simulador OLTP


Una imagen mucho más cercana a la realidad viene dada por otra prueba. Como parte de esto, se lanzan dos generadores con un perfil cercano a un DBMS transaccional y un nivel de carga de 6000 + 400 IOPS. Aquí, se mide el retraso, que debe permanecer en un nivel bajo estable.









El retraso para la carga de VM fue de 1.07 / 1.08 ms. En general, un gran resultado, ¡pero agreguemos algo de calor!

Colocación de la base de datos: alta intensidad


Cómo se comportará la base transaccional, dependiendo de los retrasos, si de repente se forma un vecino ruidoso consecutivo. Bueno, muy ruidoso.









Entonces, la base OLTP en el nodo 1 genera 4200 IOPS con un retraso de 0.85 ms. ¿Qué sucede después de que un sistema DSS de repente comienza a consumir recursos en operaciones secuenciales?
Dos generadores en los nodos 2 y 3 cargan la plataforma a 1.18 / 1.08 GBps, respectivamente, esos 2.26 GBps en total. El retraso en OLTP, por supuesto, crece y se vuelve menos plano, pero el valor promedio sigue siendo de 1.85 ms, y la base recibe sus 4200 IOPS sin ningún problema.

Impacto de la instantánea






El sistema toma secuencialmente varias instantáneas una vez por hora en una base OLTP. No hay nada sorprendente en el cronograma y, además, esto generalmente es un indicador de cómo funcionan las instantáneas clásicas de VMware, ya que Nutanix XRay no sabe cómo trabajar con instantáneas nativas, excepto las suyas. No necesita usar instantáneas de vSphere de forma regular, porque no todos los yogures son igualmente útiles.

Las instantáneas nativas de HyperFlex funcionan mucho mejor, úselas y su cabello se volverá suave y sedoso.

Ingestión de grandes datos


¿Cómo HyperFlex digiere una gran cantidad de datos cargados secuencialmente? Bueno, digamos 1 TB.





La prueba tomó 27 minutos, incluida la clonación, el ajuste y el arranque de los generadores.

Escalabilidad de rendimiento



Ahora, cargue gradualmente todo el clúster y observe los números constantes. Para comenzar con la lectura aleatoria, luego la escritura.











Estamos viendo una imagen estable con una disminución gradual en el rendimiento de la carga de la máquina de 78k a 55-57k IOPS, con estantes lisos. Al mismo tiempo, hay un aumento constante en el rendimiento general de 78 a 220k IOPS.











La grabación es un poco menos suave, pero sigue siendo estantes estables de 64k a 19-21k por automóvil. Al mismo tiempo, la carga en los controladores es mucho menor. Si durante la lectura el nivel de carga total del procesador aumentó de 44 a 109, entonces al grabar de 57 a 73 GHz.

Aquí puede observar el ejemplo más simple y obvio de las características de los sistemas hiperconvergentes: el único consumidor simplemente no puede utilizar por completo todos los recursos del sistema, y ​​cuando se agrega la carga, no hay una caída significativa en el rendimiento. La caída que estamos presenciando ya es el resultado de cargas sintéticas extremas diseñadas para exprimir todo hasta la última gota, que casi nunca es el caso en un producto normal.

Romper OLTP


En este momento, incluso se volvió aburrido lo predecible que era HyperFlex. Necesidad urgente de romper algo!





El punto rojo marca el momento en que la VM del controlador se apaga en uno de los hosts con una carga.

Dado que, por defecto, la reconstrucción en HyperFlex comienza inmediatamente solo cuando se pierde el disco, y cuando se pierde el nodo, el tiempo de espera es de 2 horas, el momento de la reconstrucción forzada se marca con un punto verde.

login as: admin
 HyperFlex StorageController 4.0(2a)
admin@192.168.***.***'s password:
<b>admin@SpringpathController0VY9B6ERXT:~$</b> stcli rebalance status
rebalanceStatus:
    percentComplete: 0
    rebalanceState: cluster_rebalance_not_running
rebalanceEnabled: True
<b>admin@SpringpathController0VY9B6ERXT:~$</b> stcli rebalance start -f
msgstr: Successfully started rebalance
params:
msgid: Successfully started rebalance
<b>admin@SpringpathController0VY9B6ERXT:~$</b> stcli rebalance status
rebalanceStatus:
    percentComplete: 16
    rebalanceState: cluster_rebalance_ongoing
rebalanceEnabled: True
<b>admin@SpringpathController0VY9B6ERXT:~$</b>



Las operaciones se congelaron por un par de segundos y continuaron nuevamente, casi notando la reconstrucción. Está en un estado estable cuando está lejos de la sobrecarga del clúster.

¿Por qué 2 horas Cisco no es un problema, aunque los competidores tienen menos números? Cisco recomienda encarecidamente utilizar RF3 como nivel básico de protección de datos para todo, excepto las máquinas que no son una pena. Decidió instalar parches o hacer algo con el host, apáguelo. Y existe la posibilidad de que en ese momento otro host falle, y luego, en el caso de RF2, todo se convertirá en una apuesta, y con RF3 habrá una copia activa de los datos. Y sí, de hecho, es bastante posible sobrevivir 2 horas en un accidente en RF2 hasta que comience la recuperación a RF3.

¡Rómpeme por completo!


Rompiendo, tan rompiendo. Carga completa. En este caso, creé una prueba con un perfil más o menos parecido a una carga real (70% de lectura, 20% al azar, 8k, 6d 128q).



Adivina dónde se apagó CVM y dónde comenzó la reconstrucción.



En la situación con la reconstrucción, HyperFlex funcionó bastante bien, sin causar una caída catastrófica en el rendimiento o un aumento múltiple en los retrasos, incluso bajo carga bajo los mismos tomates. Lo único que realmente me gustaría es querido Cisco, hacer que el tiempo de espera sea igual en menos de 2 horas de forma predeterminada.

recomendaciones


Para concluir, recuerdo el propósito de las pruebas: investigar el sistema Cisco HyperFlex hoy, sin mirar el historial, investigar su rendimiento utilizando sintéticos y sacar conclusiones sobre su aplicabilidad a un producto real.

Conclusión 1 , sobre el rendimiento. El rendimiento es muy bueno, y no harás ningún otro comentario aquí. Como tenía un sistema de la generación anterior en la prueba, puedo decir exactamente una cosa: en HyperFlex All Flash, se encontrará con la capacidad, el procesador, la memoria, pero no los discos. Excepto tal vez el 1% de las aplicaciones supercargadas, pero debe mantener una conversación con ellas personalmente. Las instantáneas RoW nativas funcionan.

Conclusión 2, según disponibilidad. El sistema después de detectar una falla es bastante bueno (sin una caída de rendimiento a veces) cumple con la restauración de la cantidad de copias de datos. Hay una ligera queja en el tiempo de espera predeterminado de 2 horas antes de comenzar la recuperación (si se pierde el host), pero dado el RF3 altamente recomendado, esto es más problemático. La recuperación después de una falla de disco comienza de inmediato.

Conclusión 3, en precio y comparación con la competencia. El precio del sistema puede variar muchas veces dependiendo de la configuración de un proyecto específico. Una gran parte del costo del proyecto será un sistema de licencia y software de aplicación, que funcionará sobre la plataforma de infraestructura. Por lo tanto, la única forma de comparar con la competencia es comparar ofertas comerciales específicas que cumplan con los requisitos técnicos, específicamente para su empresa para un proyecto específico.

Conclusión final : el sistema está funcionando, bastante maduro para su uso en el producto para abril de 2020, si se leen y aplican las recomendaciones del proveedor, en lugar de fumar.

All Articles