De alguna manera fue necesario integrar Rosplatform (R-Virtualization y R-Storage) con el sistema de almacenamiento de hardware ( 3PAR ), y esto puede ser muy útil en varios escenarios.
Configuración de sinergia
Anteriormente, este tipo de integración se probó en los blades (Blade CH121 v5) del blade central de Huawei con el sistema de almacenamiento Dorado 5000 v3, donde SDS (almacenamiento definido por software) del P-Storage de Rosplatforma en la parte superior del sistema de almacenamiento se mostró bastante bien debido a todo flash, pero con Synergy , si está disponible Discos JBOD del módulo D3940, todo es mucho más interesante y flexible.
3 servidores blades (Synergy 480 Gen10 (871940-B21)):
- Cada uno tiene dos CPU Intel® Xeon® Platinum 8270.
- Red dos puertos de 20 Gb / s.
- RAM 256GB.
- No hay discos duros en los blades.
- En el módulo de disco Synergy 2HDD, 900GB en RAID1 para cada SO / hipervisor y 3SSD HPE VK0960GFDKK 960GB para la función de metadatos + caché (cada uno para un servidor), así como 9HDD EG0900JFCKB para 900GB.
El sistema operativo se cargó a través de un canal a través de un controlador RAID desde un módulo de disco Synergy.
SDS local implementado sobre el canal JBOD desde el módulo de disco Synergy.
Configuración 3PAR
Synergy está conectado a 3PAR (FC16 Gb / s):
Un LUN (uno a muchos) RAID6 de SSD con capacidad de 200GB. 9 LUN RAID6 desde HDD, cada uno con una capacidad de 150 GB (tres LUN por blade).
Figura: 1 Diagrama del banco de pruebas.
Descripción de escenarios
Probamos varias opciones para la integración con 3PAR, que también se pueden usar simultáneamente todas a la vez en una configuración mixta.
Escenario con implementación SDS de Rosplatform en LUN separados de 150 GB cada uno de 3PAR:
Fig. 2
Se presentó un escenario con implementación SDS de Rosplatform en LUN separados con sistemas de almacenamiento para cada nodo de los tres FC con 3 LUN de 150 GB.
En los sistemas de almacenamiento, se configuraron en RAID6 desde discos HDD. En la Fig. 2 muestra esquemáticamente 10 Gb y conmutador, pero la implementación fue en el nivel del conmutador Synergy con puertos de 20 Gb, donde una interfaz es para administración y virtualización y la otra para almacenamiento SDS.
Este escenario se probó para verificar que funcionan las siguientes opciones:
- SDS Rosplatform funciona sobre 3PAR.
- Fortalecimiento de SDS de Rosplatforma sobre 3PAR agregando caché SSD local.
- Creando una pequeña SDS Rosplatform para almacenar archivos de configuración de VM, donde las propias VM se crean en LUN 3PAR.
- Probar SDS Rosplatforma sobre 3PAR, definiéndolo para un guión ligeramente más lento que un guión de discos locales.
2) Escenario con la creación de una VM en un LUN desde 3PAR:
Fig. 3 Escenario con la creación de una máquina virtual en un LUN desde 3PAR.
LUN 200GB RAID6 de SSD para VM se presentó con almacenamiento. La configuración de LUN es de una a varias.
Este escenario se probó para verificar las capacidades:
- Conéctelo a VM LUN desde 3PAR directamente.
- Usando el VM LUN adjunto como disco principal sin usar qcow2.
- Uso de varias máquinas virtuales con el mismo LUN de 200 GB adjunto para la instalación posterior del sistema de archivos del clúster invitado.
- Migración de una máquina virtual con un LUN de 200 GB de 3PAR y un bloqueo del nodo al reiniciar esta máquina virtual en los nodos restantes.
- Usar SDS de 3PAR como almacenamiento de archivos de configuración de VM y el sistema operativo invitado con implementación en LUN de 3PAR directamente.
- Usar SDS en los discos locales del módulo Synergy como almacenamiento de archivos de configuración de VM y el sistema operativo invitado con implementación en LUN 200GB desde 3PAR directamente.
Descripción de la configuración
Para todos los escenarios en cada nodo, antes del despliegue habitual del clúster, se realizaron previamente los mismos ajustes, que se realizaron inmediatamente después de instalar tres nodos de las imágenes de Rosplatform. En el artículo anterior se encuentran disponibles breves instrucciones para instalar y configurar el clúster .
1.Habilitar el servicio de múltiples rutas para la carga automática:
#chkconfig multipathd on2.habilitar la carga de módulos:
#modprobe dm-multipath
#modprobe dm-round-robin3. copiando la plantilla de configuración a la carpeta para la configuración de trabajo:
#cp /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf /etc/4.Verifique el patrón de inclusión debajo de los siguientes parámetros:
defaults {
user_friendly_names yes
find_multipaths yes
}5.agregar un alias para un disco compartido para una VM:
multipaths {
multipath {
# wwid 3600508b4000156d700012000000b0000
# alias yellow
# path_grouping_policy multibus
# path_selector "round-robin 0"
# failback manual
# rr_weight priorities
# no_path_retry 5
# }
multipath {
wwid 360002ac0000000000000000f000049f4
alias test3par
}
}
6.Compruebe para iniciar el servicio:
#systemctl start multipathd7. Comprobación del servicio y visualización de dispositivos con mpath:
#multipath –ll8. Reinicio obligatorio:
#reboot9. Comprobación del servicio y visualización de dispositivos con mpath:
#multipath –llA continuación, se realizaron las configuraciones de clúster estándar.
Figura: 4 interfaz de usuario web antes de habilitar el servicio multirrutas.
Figura: 5 Después de habilitar el servicio de múltiples rutas, aparecieron los dispositivos dm.
Captura de pantalla después de crear un clúster Rosplatforma, donde 200GB LUN para VM es especialmente con un rol no asignado:
Fig. 6 Captura de pantalla después de crear el cluster Rosplatforma.
La captura de pantalla muestra dos tier0 y tier1, donde tier0 es la SDS local y tier1 es SDS sobre 3PAR:
Fig. 7 SDS locales y más de 3PAR.
A continuación, se creó una máquina virtual sin un disco local con un LUN de 200 GB de 3PAR adjunto:
#prlctl set testVM --device-add hdd --device /dev/mapper/ test3parLa máquina virtual se creó con los siguientes parámetros:
- Tipo - CentOS Linux
- CPU virtual - 4
- RAM - 8
- SO invitado - Centos 7 (1908)
Pruebas de migración
Las pruebas de migración se realizaron con o sin las herramientas invitadas instaladas.
En todos los casos, la máquina virtual se migró correctamente sin detenerse.
Figura: 8 Resultado y hora de la migración de la VM.
Test1: una VM normal con los mismos parámetros solo con una imagen de disco local QCOW2 64GB y migración en vivo de una VM test10 con un LUN de 200GB de 3PAR.
El tiempo de migración es menor debido a que durante el proceso no hay ningún paso para cambiar a una copia de la imagen del disco de la VM en otro nodo, solo se copia el archivo de configuración con un enlace al LUN 200GB, que es visible desde cualquier nodo del clúster.
Figura: 9 Resultados de ping.
Durante la migración en vivo, se realizó un ping a la VM con un LUN de 200 GB de 3PAR.
Se registró la pérdida de un solo paquete, lo mismo sucede con una VM normal en SDS, pero la VM permanece accesible a través de la red y continúa funcionando.
Pruebas de parada de emergencia
Cuando se apagó el servidor, en el que había una máquina virtual con un LUN de 200 GB de 3PAR, y después de que el servicio HA detectó el nodo faltante, la máquina virtual bajo prueba se reinició con éxito en otro nodo seleccionado de acuerdo con el algoritmo de drs predeterminado, round robin, y continuó funcionando. Durante el ping, se perdieron 7 paquetes. Al cambiar, solo se lanzó el archivo de configuración de VM y siempre se pudo acceder al SO invitado a través de la ruta adjunta al LUN.
También probamos la creación de una copia de seguridad, donde se realizó una copia de seguridad del archivo de configuración de la VM con éxito y, al restaurar desde esta copia de la VM, se inició correctamente.
Pruebas de escritura secuencial a VM con 200GB LUN de 3PAR, que mostraron el rendimiento de este LUN de 3PAR, donde Rosplatforma no era una capa intermedia, y la prueba muestra el funcionamiento del SO huésped y los sistemas de almacenamiento 3PAR.
Se utilizaron parámetros de fio dentro de la VM con 200 GB de LUN de 3PAR:
[seqwrite]
rw=write
size=4g
numjobs=4
bs=1m
ioengine=libaio
iodepth=32
time_based
#runtime=60
direct=1
filename_format=__testfile'$jobnum'
thread
directory=/sdb/
Pruebas con un sistema de archivos en clúster dentro del sistema operativo invitado
Figura: 10 Sistema de archivos agrupado dentro del SO invitado.
Se probó con éxito un escenario con un LUN de 200 GB conectado a dos VM, en el que el sistema de archivos del clúster GFS2 está instalado dentro de la VM mediante el sistema operativo invitado. Durante la prueba, una de las VM o el host se apagó, después de lo cual la otra VM continuó trabajando con este LUN y escribiendo / leyendo archivos desde allí. A continuación se muestra una captura de pantalla con la configuración de GFS2 dentro de la VM, también se muestran las salidas de los comandos del marcapasos:
Más SDS de Rosplatforma en la parte superior del LUN:
Fig. 11 Configuración con SDS Rosplatform implementado en un LUN de 3PAR.
El mismo escenario se probó con éxito con un LUN de 200 GB conectado a dos VM, en las que se instaló un sistema de archivos de clúster dentro de la VM mediante el sistema operativo invitado, pero el almacén de datos de SDS Rosplatforma creado en el LUN de 3PAR se usó como ubicación de VM. Durante la prueba, una de las VM o el host se apagó, después de lo cual la otra VM continuó trabajando con este LUN y escribiendo / leyendo archivos desde allí.
Figura: 12 Pruebe agregando SSD para la función de caché del módulo de disco Synergy.
El mismo escenario se probó con éxito con un LUN de 200 GB conectado a dos VM, en las que se instaló un sistema de archivos de clúster dentro de la VM mediante el sistema operativo invitado, pero el almacén de datos de SDS Rosplatforma creado en el LUN de 3PAR se usó como ubicación de VM. Además, se ha mejorado el rendimiento de este almacén de datos al agregar un SSD como caché desde un módulo de disco Synergy. Durante la prueba, una de las VM o el host se apagó, después de lo cual la otra VM continuó trabajando con este LUN y escribiendo / leyendo archivos desde allí.
Pruebas del sistema de archivos de clúster en los nodos de Rosplatform
Figura: 13 Se presentó la prueba con archivos de configuración de VM ubicados en SDS Rosplatforma, de 3PAR LUN 200GB.
Se probó un escenario con almacenamiento compartido de 3PAR para imágenes de disco de VM en un sistema de archivos de clúster, que se instaló en los nodos de Rosplatforma, y los archivos de configuración de estas VM se ubicaron en la SDS de Rosplatforma. Durante la prueba, uno de los hosts se apagó, después de lo cual las VM tuvieron que continuar trabajando con sus imágenes de disco debido al trabajo de otros dos hosts según la réplica 3 en el clúster SDS para archivos de configuración de VM y 3 registros del sistema de archivos del clúster para imágenes de disco de VM.
Figura: 14 SDS se lleva a LUN desde 3PAR.
Se probó un escenario con almacenamiento compartido de 3PAR para imágenes de disco de VM en un sistema de archivos de clúster, que se instaló en los nodos de Rosplatforma, y los archivos de configuración de estas VM se ubicaron en SDS de Rosplatforma, donde SDS se elevó al LUN desde 3PAR. Durante la prueba, uno de los hosts se apagó, después de lo cual las VM tuvieron que continuar trabajando con sus imágenes de disco debido al trabajo de otros dos hosts según la réplica 3 en el clúster SDS para archivos de configuración de VM y 3 registros del sistema de archivos del clúster para imágenes de disco de VM.
Figura: 15 SDS tier0 en LUN de 3PAR, SDS tier1 en discos del módulo Synergy.
Se probó un escenario con almacenamiento compartido de 3PAR para imágenes de disco de VM en un sistema de archivos de clúster, que se instaló en los nodos de Rosplatforma, y los archivos de configuración de estas VM se ubicaron en SDS Rosplatforma, donde SDS tier0 se elevó en el LUN de 3PAR y el segundo SDS tier1 en discos del módulo Sinergia. Durante la prueba, uno de los hosts se apagó, después de lo cual las VM tuvieron que trabajar con sus imágenes de disco debido al trabajo de otros dos hosts de acuerdo con la réplica 3 en el clúster SDS para archivos de configuración de VM y 3 registros del sistema de archivos del clúster para imágenes de disco de VM. Pero hubo problemas con el trabajo de kvm-qemu con GFS2, después de una larga investigación, el administrador de bloqueo de GFS2 falló y Rosplatforma no pudo iniciar la VM en otro host del clúster debido a esto. La pregunta permanece abierta. Lo mismo con las opciones de la Figura 13 y 14.Un posible problema con este escenario radica en las peculiaridades de kvm-qemu trabajando con qcow2 y la imagen en bruto, donde las operaciones de escritura son sincrónicas y el administrador de bloqueo de GFS2 está limitado para tales operaciones.
Conclusión
Las opciones de SDS a LUN de 3PAR y presentación de LUN de 3PAR funcionan bastante y se pueden utilizar para trabajar en infraestructura, pero por supuesto tienen algunos inconvenientes.
Por ejemplo, en el caso de SDS en las lunas, el rendimiento siempre será ligeramente inferior al SDS en discos locales, puede mejorar esto utilizando SSD locales con la función de caché, pero SDS regular siempre será predominantemente más rápido. Como opción, SDS en el almacenamiento se puede configurar en una galería de disparos separada. Otro inconveniente importante es la tolerancia a fallas, en SDS cada nodo es un controlador, donde al menos un clúster comienza con tres nodos, luego en el caso de los sistemas de almacenamiento siempre hay dos controladores por rack. Para SDS, este es un único punto de falla, pero a pesar de estas desventajas, tales escenarios tienen lugar durante una transición gradual del almacenamiento externo a SDS o al deshacerse de un sistema de almacenamiento existente. Además, existen capacidades del propio sistema de almacenamiento, como la deduplicación, la compresión, que, debido a las peculiaridades del enfoque arquitectónicono en SDS Rosplatforma, pero 3PAR lo tiene y gracias a los escenarios descritos anteriormente, se pueden utilizar a nivel de almacenamiento.
También son relevantes los escenarios con presentación LUN para VM, para sistemas invitados con su propio sistema de clúster. En el caso de la presentación de los LUN a cada VM por separado, aparecen desventajas como la falta de automatización durante el ciclo de vida de una gran cantidad de VM, lo que podría deberse al sistema de archivos del cluster en los nodos Rosplatform, pero GFS2 con kvm-qemu en este caso falló, si utilizar para cualquier otro archivo, entonces todo funciona incluso en las pruebas de emergencia en Rosplatform, pero tan pronto como las imágenes de VM se colocan allí, el administrador de bloqueo GFS2 falla en las pruebas de emergencia. Quizás este problema se resuelva.
Los escenarios anteriores para el uso de rutas múltiples pueden resultar útiles para vincular bibliotecas de cintas. Rosplatform tiene un sistema de copia de seguridad integrado (SRK), que puede escribir copias en la carpeta del clúster de almacenamiento P o una carpeta local, pero no puede funcionar con dispositivos de cinta hasta que usted mismo escriba un script, o para estos propósitos puede usar SRK externo, por ejemplo , rubackup , que Además de trabajar con cinta, ayudará a realizar copias de VM con LUN adjuntos, lo cual es importante cuando se integra con sistemas de almacenamiento.