Este é un mito bastante común no campo do hardware de servidores. Na práctica, son necesarias solucións hiperconverxentes (cando todo está nunha soa) para moitas cousas. Históricamente, as primeiras arquitecturas foron desenvolvidas por Amazon e Google para os seus servizos. Entón a idea era facer unha granxa de computación a partir de nodos idénticos, cada un dos cales tiña os seus propios discos. Todo isto estaba unido por algún software de formación de sistemas (hipervisor) e estaba dividido en máquinas virtuais. O obxectivo principal é un mínimo de esforzo para atender un nodo e un mínimo de problemas ao escalar: só tes que mercar outros mil ou dous dos mesmos servidores e conéctalos preto. Na práctica, trátase de casos illados, e moito máis a miúdo estamos a falar dun número menor de nodos e dunha arquitectura lixeiramente diferente.
Pero a vantaxe segue sendo a mesma: unha incrible facilidade de escalado e xestión. A desvantaxe é que as diferentes tarefas consomen recursos de forma diferente, e nalgúns lugares haberá moitos discos locais, noutros haberá pouca memoria RAM, e así por diante, é dicir, para diferentes tipos de tarefas, a utilización de recursos diminuirá.
Resulta que pagas entre un 10 e un 15 % máis para facilitar a configuración. Isto é o que provocou o mito no título. Levamos moito tempo buscando onde se aplicaría de forma óptima a tecnoloxía e atopámolo. O caso é que Cisco non tiña sistemas de almacenamento propios, pero querían un mercado de servidores completo. E crearon Cisco Hyperflex, unha solución con almacenamento local en nodos.
E isto de súpeto resultou ser unha moi boa solución para os centros de datos de copia de seguridade (Disaster Recovery). Xa vos contarei por que e como. E mostrareiche as probas de cluster.
Onde sexa necesario
A hiperconverxencia é:
- Transferencia de discos a nodos de cálculo.
- Integración total do subsistema de almacenamento co subsistema de virtualización.
- Transferencia/integración co subsistema de rede.
Esta combinación permítelle implementar moitas funcións do sistema de almacenamento a nivel de virtualización e todas desde unha ventá de control.
Na nosa empresa, os proxectos para deseñar centros de datos redundantes teñen unha gran demanda, e moitas veces elíxese unha solución hiperconverxente debido a unha morea de opcións de replicación (ata un metroclúster) listas para usar.
No caso dos centros de datos de copia de seguridade, adoitamos falar dunha instalación remota nun sitio ao outro lado da cidade ou noutra cidade. Permítelle restaurar sistemas críticos en caso de falla parcial ou total do centro de datos principal. Os datos de vendas replícanse constantemente alí, e esta replicación pode ser a nivel de aplicación ou de dispositivo de bloque (almacenamento).
Polo tanto, agora falarei do deseño e das probas do sistema, e despois dun par de escenarios de aplicacións da vida real con datos de aforro.
Probas
A nosa instancia consta de catro servidores, cada un dos cales ten 10 unidades SSD de 960 GB. Hai un disco dedicado para almacenar na caché as operacións de escritura e almacenar a máquina virtual do servizo. A solución en si é a cuarta versión. O primeiro é francamente groseiro (a xulgar polas críticas), o segundo está húmido, o terceiro xa é bastante estable, e este pódese chamar un lanzamento despois do final das probas beta para o público en xeral. Durante a proba non vin ningún problema, todo funciona como un reloxo.
Cambios na v4Corrixíronse unha morea de erros.
Inicialmente, a plataforma só podía funcionar co hipervisor VMware ESXi e admitía un pequeno número de nodos. Ademais, o proceso de implantación non sempre rematou correctamente, houbo que reiniciar algúns pasos, houbo problemas coa actualización de versións antigas, os datos da GUI non sempre se mostraban correctamente (aínda que aínda non estou satisfeito coa visualización dos gráficos de rendemento). ), ás veces xurdiron problemas na interface coa virtualización .
Agora todos os problemas da infancia foron solucionados, HyperFlex pode xestionar tanto ESXi como Hyper-V, ademais é posible:
- Creando un clúster estirado.
- Creación dun clúster para oficinas sen utilizar Fabric Interconnect, de dous a catro nodos (compramos só servidores).
- Capacidade para traballar con sistemas de almacenamento externos.
- Soporte para contenedores e Kubernetes.
- Creación de zonas de dispoñibilidade.
- Integración con VMware SRM se a funcionalidade integrada non é satisfactoria.
A arquitectura non é moi diferente das solucións dos seus principais competidores, non crearon unha bicicleta. Todo execútase na plataforma de virtualización VMware ou Hyper-V. O hardware está aloxado en servidores propietarios de Cisco UCS. Hai quen odia a plataforma pola relativa complexidade da configuración inicial, moitos botóns, un sistema de modelos e dependencias non trivial, pero tamén hai quen aprendeu Zen, inspírase na idea e xa non quere. para traballar con outros servidores.
Consideraremos a solución para VMware, xa que a solución foi creada orixinalmente para el e ten máis funcionalidades; Hyper-V engadiuse ao longo do camiño para estar ao día dos competidores e cumprir as expectativas do mercado.
Hai un grupo de servidores cheos de discos. Hai discos para almacenamento de datos (SSD ou HDD - segundo o teu gusto e necesidades), hai un disco SSD para almacenar na caché. Ao escribir datos no almacén de datos, os datos gárdanse na capa de caché (disco SSD dedicado e RAM da máquina virtual do servizo). Paralelamente, envíase un bloque de datos aos nodos do clúster (o número de nós depende do factor de replicación do clúster). Despois da confirmación de todos os nodos sobre a gravación exitosa, a confirmación da gravación envíase ao hipervisor e despois á máquina virtual. Os datos gravados son desduplicados, comprimidos e escritos en discos de almacenamento en segundo plano. Ao mesmo tempo, un bloque grande sempre se escribe nos discos de almacenamento e secuencialmente, o que reduce a carga dos discos de almacenamento.
A deduplicación e a compresión sempre están activadas e non se poden desactivar. Os datos lense directamente desde discos de almacenamento ou desde a caché RAM. Se se usa unha configuración híbrida, as lecturas tamén se almacenan na memoria caché no SSD.
Os datos non están vinculados á localización actual da máquina virtual e distribúense uniformemente entre os nodos. Este enfoque permítelle cargar todos os discos e interfaces de rede por igual. Hai unha desvantaxe obvia: non podemos reducir o máximo posible a latencia de lectura, xa que non hai garantía de dispoñibilidade de datos localmente. Pero creo que este é un sacrificio menor en comparación cos beneficios recibidos. Ademais, os atrasos da rede alcanzaron valores tales que practicamente non afectan ao resultado global.
Un servizo especial VM Cisco HyperFlex Data Platform controlador, que se crea en cada nodo de almacenamento, é responsable de toda a lóxica de operación do subsistema de disco. Na nosa configuración de VM de servizo, asignáronse oito vCPU e 72 GB de RAM, o que non é tan pouco. Permíteme recordarche que o propio host ten 28 núcleos físicos e 512 GB de RAM.
A máquina virtual de servizo ten acceso aos discos físicos directamente reenviando o controlador SAS á máquina virtual. A comunicación co hipervisor prodúcese a través dun módulo especial IOVisor, que intercepta as operacións de E/S e mediante un axente que lle permite enviar comandos á API do hipervisor. O axente é o responsable de traballar con instantáneas e clons de HyperFlex.
Os recursos de disco están montados no hipervisor como recursos compartidos NFS ou SMB (dependendo do tipo de hipervisor, adiviña cal é onde). E baixo o capó, trátase dun sistema de ficheiros distribuído que che permite engadir funcións dos sistemas de almacenamento completos para adultos: asignación de volume fino, compresión e deduplicación, instantáneas mediante a tecnoloxía Redirect-on-Write, replicación síncrona/asíncrona.
O servizo VM proporciona acceso á interface de xestión WEB do subsistema HyperFlex. Hai integración con vCenter, e a maioría das tarefas cotiás pódense realizar desde el, pero os almacéns de datos, por exemplo, son máis cómodos cortar desde unha cámara web separada se xa cambiaches a unha interface HTML5 rápida ou usas un cliente Flash completo. con plena integración. Na webcam do servizo pode ver o rendemento e o estado detallado do sistema.
Hai outro tipo de nodos nun clúster: os nodos informáticos. Estes poden ser servidores en rack ou blade sen discos incorporados. Estes servidores poden executar máquinas virtuales cuxos datos se almacenan en servidores con discos. Desde o punto de vista do acceso aos datos, non hai diferenza entre os tipos de nodos, porque a arquitectura implica a abstracción da localización física dos datos. A relación máxima de nodos de computación e de almacenamento é de 2:1.
O uso de nós de cálculo aumenta a flexibilidade á hora de escalar os recursos do clúster: non temos que comprar nós adicionais con discos se só necesitamos CPU/RAM. Ademais, podemos engadir unha gaiola blade e aforrar na colocación en rack dos servidores.
Como resultado, temos unha plataforma hiperconverxente coas seguintes características:
- Ata 64 nodos nun clúster (ata 32 nodos de almacenamento).
- O número mínimo de nodos nun clúster é tres (dous para un clúster Edge).
- Mecanismo de redundancia de datos: espello con factor de replicación 2 e 3.
- Clúster de metro.
- Replicación de máquina virtual asíncrona a otro clúster HyperFlex.
- Orquestración de conmutación de máquinas virtuales a un centro de datos remoto.
- Instantáneas nativas mediante a tecnoloxía Redirect-on-Write.
- Ata 1 PB de espazo utilizable no factor de replicación 3 e sen deduplicación. Non temos en conta o factor de replicación 2, porque esta non é unha opción para vendas serias.
Outra gran vantaxe é a facilidade de xestión e implantación. Todas as complexidades da configuración dos servidores UCS son atendidas por unha máquina virtual especializada preparada por enxeñeiros de Cisco.
Configuración do banco de probas:
- 2 x Cisco UCS Fabric Interconnect 6248UP como clúster de xestión e compoñentes de rede (48 portos que funcionan en modo Ethernet 10G/FC 16G).
- Catro servidores Cisco UCS HXAF240 M4.
Características do servidor:
CPU
2 x Intel® Xeon® E5-2690 v4
RAM
16 x 32 GB DDR4-2400-MHz RDIMM/PC4-19200/rango dual/x4/1.2 v
Rede
UCSC-MLOM-CSC-02 (VIC 1227). 2 portos Ethernet 10G
Almacenamento HBA
Controlador de paso a través de SAS modular Cisco 12G
Discos de almacenamento
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Máis opcións de configuraciónAdemais do hardware seleccionado, actualmente están dispoñibles as seguintes opcións:
- HXAF240c M5.
- Unha ou dúas CPUs que van desde Intel Silver 4110 ata Intel Platinum I8260Y. Segunda xeración dispoñible.
- 24 ranuras de memoria, tiras de 16 GB RDIMM 2600 a 128 GB LRDIMM 2933.
- De 6 a 23 discos de datos, un disco de caché, un disco do sistema e un disco de arranque.
Unidades de capacidade
- HX-SD960G61X-EV 960 GB 2.5 polgadas Enterprise Value 6G SATA SSD (1X resistencia) SAS 960 GB.
- HX-SD38T61X-EV 3.8 TB 2.5 polgadas Enterprise Value 6G SATA SSD (1X resistencia) SAS 3.8 TB.
- Almacenamento en caché de unidades
- HX-NVMEXPB-I375 375 GB 2.5 polgadas Intel Optane Drive, Extreme Perf & Endurance.
- HX-NVMEHW-H1600* 1.6 TB 2.5 polgadas Ent. Perf. SSD NVMe (resistencia 3X) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400 GB 2.5 polgadas Ent. Perf. 12G SAS SSD (10X de resistencia) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 polgadas Ent. Perf. 12G SAS SED SSD (10X de resistencia) SAS 800 GB.
- HX-SD16T123X-EP 1.6 TB 2.5 polgadas SSD SAS de 12 G de rendemento empresarial (resistencia 3X).
Sistema/Unidades de rexistro
- HX-SD240GM1X-EV 240 GB 2.5 polgadas Enterprise Value 6G SATA SSD (require actualización).
Unidades de arranque
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.
Conéctese á rede a través de portos Ethernet 40G, 25G ou 10G.
O FI pode ser HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
A proba en si
Para probar o subsistema de disco, usei HCIBench 2.2.1. Esta é unha utilidade gratuíta que permite automatizar a creación dunha carga desde varias máquinas virtuais. A carga en si é xerada polo fio habitual.
O noso clúster consta de catro nodos, factor de replicación 3, todos os discos son Flash.
Para probar, creei catro almacéns de datos e oito máquinas virtuais. Para as probas de escritura, suponse que o disco da caché non está cheo.
Os resultados das probas son os seguintes:
100% lido 100% aleatorio
0% Ler 100% Aleatorio
Profundidade 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
Negriña indica valores despois dos cales non hai aumento da produtividade, ás veces ata é visible a degradación. Isto débese ao feito de que estamos limitados polo rendemento da rede/controladores/discos.
- Lectura secuencial 4432 MB/s.
- Escritura secuencial 804 MB/s.
- Se un controlador falla (fallo dunha máquina virtual ou host), a caída do rendemento é dobre.
- Se o disco de almacenamento falla, a redución é de 1/3. A reconstrución do disco ocupa o 5% dos recursos de cada controlador.
Nun bloque pequeno, estamos limitados polo rendemento do controlador (máquina virtual), a súa CPU cárgase ao 100% e, cando o bloque aumenta, estamos limitados polo ancho de banda do porto. 10 Gbps non son suficientes para desbloquear o potencial do sistema AllFlash. Desafortunadamente, os parámetros do soporte de demostración proporcionado non nos permiten probar o funcionamento a 40 Gbit/s.
Na miña impresión das probas e do estudo da arquitectura, debido ao algoritmo que coloca os datos entre todos os hosts, obtemos un rendemento escalable e previsible, pero isto tamén é unha limitación á hora de ler, porque sería posible espremer máis dos discos locais. aquí pode gardar unha rede máis produtiva, por exemplo, está dispoñible FI a 40 Gbit/s.
Ademais, un disco para caché e deduplicación pode ser unha limitación; de feito, neste banco de probas podemos escribir en catro discos SSD. Sería xenial poder aumentar o número de unidades de caché e ver a diferenza.
Uso real
Para organizar un centro de datos de copia de seguridade, pode usar dous enfoques (non consideramos colocar unha copia de seguridade nun sitio remoto):
- Activo-Pasivo. Todas as aplicacións están aloxadas no centro de datos principal. A replicación é sincrónica ou asíncrona. Se o centro de datos principal falla, necesitamos activar o de copia de seguridade. Isto pódese facer manualmente/scripts/aplicacións de orquestración. Aquí obteremos un RPO acorde coa frecuencia de replicación, e o RTO depende da reacción e habilidades do administrador e da calidade do desenvolvemento/depuración do plan de conmutación.
- Activo-Activo. Neste caso, só hai replicación síncrona; a dispoñibilidade dos centros de datos está determinada por un quórum/árbitro situado estrictamente no terceiro sitio. RPO = 0 e RTO pode chegar a 0 (se a aplicación o permite) ou igual ao tempo de conmutación por fallo dun nodo nun clúster de virtualización. A nivel de virtualización, créase un clúster (Metro) estirado que require almacenamento Active-Active.
Normalmente vemos que os clientes xa teñen implantada unha arquitectura cun sistema de almacenamento clásico no centro de datos principal, polo que deseñamos outra para a replicación. Como mencionei, Cisco HyperFlex ofrece replicación asíncrona e creación de clústeres de virtualización estendida. Ao mesmo tempo, non necesitamos un sistema de almacenamento dedicado de nivel medio e superior con funcións de replicación caras e acceso a datos Active-Active en dous sistemas de almacenamento.
Escenario 1: Temos un centro de datos principal e de copia de seguridade, unha plataforma de virtualización en VMware vSphere. Todos os sistemas produtivos están situados no centro de datos principal, e a replicación das máquinas virtuais realízase a nivel de hipervisor, isto evitará manter as máquinas virtuales acendidas no centro de datos de copia de seguridade. Replicamos bases de datos e aplicacións especiais mediante ferramentas integradas e mantemos as máquinas virtuales acendidas. Se o centro de datos principal falla, lanzamos sistemas no centro de datos de copia de seguridade. Cremos que temos unhas 100 máquinas virtuais. Mentres o centro de datos principal está operativo, o centro de datos en espera pode executar ambientes de proba e outros sistemas que se poden apagar se o centro de datos principal cambia. Tamén é posible que usemos a replicación bidireccional. Desde o punto de vista do hardware, nada vai cambiar.
No caso da arquitectura clásica, instalaremos en cada centro de datos un sistema de almacenamento híbrido con acceso a través de FibreChannel, nivelación, deduplicación e compresión (pero non en liña), 8 servidores por cada sitio, 2 conmutadores FibreChannel e Ethernet 10G. Para a xestión de replicación e conmutación nunha arquitectura clásica, podemos utilizar ferramentas de VMware (Replication + SRM) ou ferramentas de terceiros, que serán un pouco máis baratas e ás veces máis cómodas.
A figura mostra o diagrama.
Ao usar Cisco HyperFlex, obtense a seguinte arquitectura:
Para HyperFlex, usei servidores con grandes recursos de CPU/RAM, porque... Algúns dos recursos irán á máquina virtual do controlador HyperFlex; en termos de CPU e memoria, incluso reconfigurei un pouco a configuración de HyperFlex para non xogar xunto con Cisco e garantir os recursos para as máquinas virtuales restantes. Pero podemos abandonar os conmutadores FibreChannel e non necesitaremos portos Ethernet para cada servidor; o tráfico local cambia dentro de FI.
O resultado foi a seguinte configuración para cada centro de datos:
Servidores
8 servidores 1U (384 GB de RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 GB de RAM, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)
SHD
Sistema de almacenamento híbrido con FC Front-End (SSD de 20 TB, NL-SAS de 130 TB)
-
LAN
2 x Switch Ethernet 10G 12 portos
-
SAN
2 x FC Switch 32/16Gb 24 portos
2 x Cisco UCS FI 6332
Licenzas
VMware Ent Plus
Replicación e/ou orquestración de conmutación de VM
VMware Ent Plus
Non proporcionei licenzas de software de replicación para Hyperflex, xa que está dispoñible para nós.
Para a arquitectura clásica, escollín un vendedor que se consolidou como un fabricante de alta calidade e barato. Para ambas as opcións, apliquei o desconto estándar para unha solución específica e, como resultado, recibín prezos reais.
A solución Cisco HyperFlex resultou ser un 13% máis barata.
Escenario 2: creación de dos centros de datos activos. Neste escenario, estamos deseñando un clúster estendido en VMware.
A arquitectura clásica consta de servidores de virtualización, unha SAN (protocolo FC) e dous sistemas de almacenamento que poden ler e escribir no volume estirado entre eles. En cada sistema de almacenamento poñemos unha capacidade útil de almacenamento.
En HyperFlex simplemente creamos un clúster de extensión co mesmo número de nós en ambos sitios. Neste caso, úsase un factor de replicación de 2+2.
O resultado é a seguinte configuración:
arquitectura clásica
HyperFlex
Servidores
16 servidores 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)
SHD
2 x sistemas de almacenamento AllFlash (SSD de 150 TB)
-
LAN
4 x Switch Ethernet 10G 24 portos
-
SAN
4 x FC Switch 32/16Gb 24 portos
4 x Cisco UCS FI 6332
Licenzas
VMware Ent Plus
VMware Ent Plus
En todos os cálculos, non tiven en conta a infraestrutura de rede, os custos do centro de datos, etc.: serán os mesmos para a arquitectura clásica e para a solución HyperFlex.
En termos de custo, HyperFlex resultou ser un 5% máis caro. Paga a pena sinalar aquí que en termos de recursos CPU/RAM tiven un sesgo para Cisco, porque na configuración enchei as canles do controlador de memoria de forma uniforme. O custo é lixeiramente superior, pero non por unha orde de magnitude, o que indica claramente que a hiperconverxencia non é necesariamente un "xoguete para os ricos", senón que pode competir co enfoque estándar para construír un centro de datos. Isto tamén pode ser de interese para aqueles que xa teñan servidores Cisco UCS e a infraestrutura correspondente para eles.
Entre as vantaxes destaca a ausencia de custos de administración de SAN e sistemas de almacenamento, compresión e deduplicación en liña, un único punto de entrada para o soporte (virtualización, servidores, tamén son sistemas de almacenamento), aforro de espazo (pero non en todos os escenarios), simplificación da operación.
En canto ao soporte, aquí o obtés dun provedor: Cisco. A xulgar pola miña experiencia cos servidores Cisco UCS, gústame; non tiven que abrilo en HyperFlex, todo funcionou igual. Os enxeñeiros responden rapidamente e poden resolver non só problemas típicos, senón tamén casos complexos. Ás veces me dirixo a eles con preguntas: "É posible facelo? ou "Configurei algo aquí e non quere funcionar. Axuda!" - atoparán alí pacientemente a guía necesaria e sinalarán as accións correctas; non responderán: "Só resolvemos problemas de hardware".
referencias
- O meu correo - [protexido por correo electrónico]
Fonte: www.habr.com