D'une manière ou d'une autre, il était nécessaire d'intégrer Rosplatform (R-Virtualization et R-Storage) avec le système de stockage matériel ( 3PAR ), et cela peut être très utile dans divers scénarios.
Configuration de synergie
Auparavant, ce type d'intégration était testé sur les lames (Blade CH121 v5) de la lame centrale Huawei avec le système de stockage Dorado 5000 v3, où le SDS (stockage défini par logiciel) du P-Storage de Rosplatforma au-dessus du système de stockage se montrait assez bien grâce à tout le flash, mais avec Synergy , si disponible Disques JBOD du module D3940, tout est beaucoup plus intéressant et flexible.
3 serveurs lames (Synergy 480 Gen10 (871940-B21)):
- Chacun dispose de deux processeurs Intel® Xeon® Platinum 8270.
- Réseau deux ports de 20 Gb / s.
- RAM 256 Go.
- Il n'y a pas de disques durs dans les lames.
- Dans le module de disque Synergy 2HDD, 900 Go en RAID1 pour chaque OS / hyperviseur et 3SSD HPE VK0960GFDKK 960 Go pour le rôle métadonnées + cache (chacun pour un serveur), ainsi que 9HDD EG0900JFCKB pour 900 Go.
Le système d'exploitation a été chargé via un canal via un contrôleur RAID à partir d'un module de disque Synergy.
SDS local déployé sur un canal JBOD à partir du module de disque Synergy.
Configuration 3PAR
Synergy est connecté à 3PAR (FC16 Gb / s):
un LUN (un à plusieurs) RAID6 à partir d'un SSD d'une capacité de 200 Go. 9 LUN RAID6 à partir du disque dur, chacun d'une capacité de 150 Go (trois LUN par lame).
Figure: 1 Schéma du banc d'essai.
Description des scénarios
Nous avons testé plusieurs options d'intégration avec 3PAR, qui peuvent également être utilisées simultanément en même temps dans une configuration mixte.
Scénario avec déploiement SDS de Rosplatform sur des LUN séparés de 150 Go chacun de 3PAR:
Fig. 2 Le scénario avec le déploiement SDS de Rosplatform sur des LUN séparés
avec des systèmes de stockage pour chaque nœud des trois a été présenté FC avec 3 LUN de 150 Go.
Sur les systèmes de stockage, ils ont été configurés en RAID6 à partir de disques durs. En figue. 2 montre schématiquement 10 Gb et commutateur, mais l'implémentation était au niveau du commutateur Synergy avec des ports 20 Gb, où une interface est pour la gestion et la virtualisation, et l'autre pour le stockage SDS.
Ce scénario a été testé pour vérifier que les options suivantes fonctionnent:
- SDS Rosplatform fonctionne au-dessus de 3PAR.
- Renforcement du SDS de Rosplatforma sur 3PAR en ajoutant un cache SSD local.
- En créant une petite plate-forme SDS Rosplatform pour stocker les fichiers de configuration de VM, où les VM elles-mêmes sont créées sur LUN 3PAR.
- Test de SDS Rosplatforma au-dessus de 3PAR, en le définissant pour un tiret légèrement plus lent qu'un trait de disques locaux.
2) Scénario avec création d'une VM sur un LUN à partir de 3PAR:
Fig. 3 Scénario avec création d'une VM sur un LUN à partir de 3PAR.
Le LUN 200 Go RAID6 de SSD pour VM a été présenté avec le stockage. La configuration du LUN est un à plusieurs.
Ce scénario a été testé pour vérifier les capacités:
- Connectez-vous directement à VM LUN depuis 3PAR.
- Utilisation du VM LUN attaché comme disque principal sans utiliser qcow2.
- Utilisation de plusieurs machines virtuelles avec le même LUN de 200 Go attaché pour l'installation ultérieure du système de fichiers du cluster invité.
- Migration d'une machine virtuelle avec un LUN de 200 Go à partir de 3PAR et des nœuds défaillants avec redémarrage de cette machine virtuelle sur les nœuds restants.
- Utilisation du SDS de 3PAR comme stockage des fichiers de configuration de VM et du système d'exploitation invité avec déploiement sur les LUN depuis 3PAR directement.
- Utilisation du SDS sur les disques locaux du module Synergy comme stockage des fichiers de configuration de la VM, et du système d'exploitation invité avec déploiement sur LUN 200 Go directement depuis 3PAR.
Description des paramètres
Pour tous les scénarios sur chaque nœud, avant le déploiement habituel du cluster, les mêmes paramètres ont été précédemment définis, qui ont été effectués immédiatement après l'installation de trois nœuds à partir des images Rosplatform. De brèves instructions pour l'installation et la configuration du cluster lui-même sont disponibles dans l' article précédent .
1. activation du service multipath pour le chargement automatique:
#chkconfig multipathd on2. activation du chargement des modules:
#modprobe dm-multipath
#modprobe dm-round-robin3. copie du modèle de configuration dans le dossier de la configuration de travail:
#cp /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf /etc/4. vérifiez le modèle d'inclusion sous les paramètres suivants:
defaults {
user_friendly_names yes
find_multipaths yes
}5.ajout d'un alias pour un disque partagé pour une machine virtuelle:
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. cochez pour démarrer le service:
#systemctl start multipathd7. Vérification du service et affichage des périphériques avec mpath:
#multipath –ll8. Redémarrage obligatoire:
#reboot9. Vérification du service et affichage des périphériques avec mpath:
#multipath –llEnsuite, les paramètres de cluster standard ont été effectués.
Figure: 4 interface utilisateur Web avant d'activer le service multivoie.
Figure: 5 Après avoir activé le service multipath, les périphériques dm sont apparus.
Capture d'écran après la création d'un cluster Rosplatforma, où 200 Go de LUN pour les machines virtuelles ont un rôle non attribué:
Fig. 6 Capture d'écran après la création du cluster Rosplatforma.
La capture d'écran montre deux tier0 et tier1, où tier0 est le SDS local et tier1 est SDS over 3PAR:
Fig. 7 SDS local et plus de 3PAR.
Ensuite, une machine virtuelle a été créée sans disque local avec un LUN de 200 Go de 3PAR attaché à la place:
#prlctl set testVM --device-add hdd --device /dev/mapper/ test3parLa VM a été créée avec les paramètres suivants:
- Type - CentOS Linux
- vCPU - 4
- RAM - 8
- Système d'exploitation invité - Centos 7 (1908)
Tests de migration
Les tests de migration ont été effectués avec ou sans les outils invités installés.
Dans tous les cas, la machine virtuelle a migré avec succès sans s'arrêter.
Figure: 8 Résultat et heure de la migration de la VM.
Test1 - une machine virtuelle normale avec les mêmes paramètres uniquement avec une image disque locale QCOW2 64 Go et la migration en direct d'une machine virtuelle test10 avec un LUN de 200 Go de 3PAR.
Le temps de migration est moindre car pendant le processus, il n'y a pas d'étape de basculement vers une copie de l'image disque de la VM sur un autre nœud, seul le fichier de configuration est copié avec un lien vers le LUN 200 Go, visible depuis n'importe quel nœud du cluster.
Figure: 9 Résultats ping.
Lors de la migration en direct, un ping a été envoyé à la VM avec un LUN de 200 Go de 3PAR.
La perte d'un seul paquet a été enregistrée, la même chose se produit avec une VM classique sur SDS, mais la VM reste accessible sur le réseau et continue de fonctionner.
Tests d'arrêt d'urgence
Lorsque le serveur a été mis hors tension, sur lequel se trouvait une machine virtuelle avec un LUN de 200 Go de 3PAR, et une fois que le service HA a détecté le nœud manquant, la machine virtuelle testée a redémarré avec succès sur un autre nœud sélectionné selon l'algorithme drs par défaut, round robin, en continuant à fonctionner. Pendant le ping, 7 paquets ont été perdus. Lors du basculement, seul le fichier de configuration de la VM était lancé et le système d'exploitation invité était toujours accessible via le chemin associé au LUN.
Nous avons également testé la création d'une sauvegarde, où le fichier de configuration de la VM a été sauvegardé avec succès et lors de la restauration à partir de cette copie de VM, il a démarré avec succès.
Tests d'écriture séquentielle sur VM avec 200 Go de LUN de 3PAR, qui ont montré les performances de ce LUN de 3PAR, où Rosplatforma n'était pas une couche intermédiaire, et le test montre le fonctionnement du système d'exploitation invité et des systèmes de stockage 3PAR.
Paramètres fio utilisés dans la VM avec 200 Go 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/
Tests avec un système de fichiers en cluster à l'intérieur du système d'exploitation invité
Figure: 10 Système de fichiers en cluster à l'intérieur du système d'exploitation invité.
Un scénario avec un LUN de 200 Go connecté à deux machines virtuelles a été testé avec succès, sur lequel le système de fichiers du cluster GFS2 est installé à l'intérieur de la machine virtuelle à l'aide du système d'exploitation invité. Pendant le test, l'une des VM ou l'hôte a été désactivé, après quoi l'autre VM a continué à travailler avec ce LUN et à écrire / lire des fichiers à partir de là. Ci-dessous, une capture d'écran avec les paramètres GFS2 à l'intérieur de la VM, les sorties des commandes du stimulateur cardiaque sont également affichées:
SDS supplémentaire de la Rosplatforma au-dessus du LUN:
Fig. 11 Configuration avec SDS Rosplatform déployé sur un 3PAR LUN.
Le même scénario a été testé avec succès avec un LUN de 200 Go connecté à deux machines virtuelles, sur lesquelles un système de fichiers de cluster a été installé à l'intérieur de la machine virtuelle à l'aide du système d'exploitation invité, mais la banque de données de SDS Rosplatforma créée sur le LUN à partir de 3PAR a été utilisée comme emplacement de la machine virtuelle. Pendant le test, l'une des VM ou l'hôte a été désactivé, après quoi l'autre VM a continué à travailler avec ce LUN et à écrire / lire des fichiers à partir de là.
Figure: 12 Testez avec l'ajout de SSD pour le rôle de cache du module de disque Synergy.
Le même scénario a été testé avec succès avec un LUN de 200 Go connecté à deux machines virtuelles, sur lesquelles un système de fichiers de cluster a été installé à l'intérieur de la machine virtuelle à l'aide du système d'exploitation invité, mais la banque de données de SDS Rosplatforma créée sur le LUN à partir de 3PAR a été utilisée comme emplacement de la machine virtuelle. De plus, ce magasin de données a été amélioré en termes de performances en ajoutant un SSD comme cache à partir du module de disque Synergy. Pendant le test, l'une des VM ou l'hôte a été désactivé, après quoi l'autre VM a continué à travailler avec ce LUN et à écrire / lire des fichiers à partir de là.
Tests du système de fichiers de cluster sur les nœuds Rosplatform
Figure: 13 Un test avec des fichiers de configuration VM situés sur SDS Rosplatforma, à partir de 3PAR LUN 200 Go a été présenté.
Un scénario a été testé avec un stockage partagé à partir de 3PAR pour les images disque de VM sur un système de fichiers de cluster, qui a été installé sur les nœuds Rosplatforma, et les fichiers de configuration de ces VM se trouvaient sur le SDS de Rosplatforma. Pendant le test, l'un des hôtes a été désactivé, après quoi les machines virtuelles ont dû continuer à travailler avec leurs images disque en raison du travail de deux autres hôtes selon la réplique 3 sur le cluster SDS pour les fichiers de configuration de la machine virtuelle et 3 journaux du système de fichiers du cluster pour les images disque de la machine virtuelle.
Figure: 14 SDS est amené au LUN à partir de 3PAR.
Un scénario a été testé avec un stockage partagé à partir de 3PAR pour des images de disque de VM sur un système de fichiers de cluster, qui a été installé sur les nœuds Rosplatforma, et les fichiers de configuration de ces machines virtuelles se trouvaient sur le SDS de Rosplatforma, où SDS a été élevé vers le LUN à partir de 3PAR. Pendant le test, l'un des hôtes a été désactivé, après quoi les machines virtuelles ont dû continuer à travailler avec leurs images disque en raison du travail de deux autres hôtes selon la réplique 3 sur le cluster SDS pour les fichiers de configuration de la machine virtuelle et 3 journaux du système de fichiers du cluster pour les images disque de la machine virtuelle.
Figure: 15 SDS tier0 sur les LUN de 3PAR, SDS tier1 sur les disques du module Synergy.
Un scénario a été testé avec un stockage partagé à partir de 3PAR pour des images de disque de machine virtuelle sur un système de fichiers de cluster, qui a été installé sur les nœuds Rosplatforma, et les fichiers de configuration de ces machines virtuelles se trouvaient sur le SDS de Rosplatform, où le SDS tier0 a été généré sur le LUN de 3PAR et le deuxième SDS tier1 sur les disques du module Synergie. Pendant le test, l'un des hôtes a été désactivé, après quoi les VM ont dû travailler avec leurs images disque en raison du travail de deux autres hôtes selon la réplique 3 sur le cluster SDS pour les fichiers de configuration de VM et 3 journaux du système de fichiers du cluster pour les images disque de VM. Mais il y avait des problèmes avec le travail de kvm-qemu avec GFS2, après une longue enquête, le gestionnaire de verrouillage de GFS2 a échoué et la Rosplatforma n'a pas pu démarrer la VM sur un autre hôte du cluster à cause de cela. La question reste ouverte. Il en va de même pour les options des figures 13 et 14.Un problème possible avec ce scénario réside dans les particularités du fonctionnement de kvm-qemu avec qcow2 et l'image brute, où les opérations d'écriture se produisent de manière synchrone, et le gestionnaire de verrouillage de GFS2 est limité pour de telles opérations.
Conclusion
Les options de SDS à LUN de 3PAR et de présentation LUN de 3PAR fonctionnent assez bien et peuvent être utilisées pour travailler en infrastructure, mais elles présentent bien sûr quelques inconvénients.
Par exemple, dans le cas du SDS sur les lunes, les performances seront toujours légèrement inférieures à celles du SDS sur les disques locaux, cela peut être amélioré par des SSD locaux avec le rôle de cache, mais le SDS régulier sera toujours majoritairement plus rapide. En option, le SDS sur les systèmes de stockage peut être configuré dans une galerie de tir séparée. Un autre inconvénient non sans importance est la tolérance aux pannes, sur SDS, chaque nœud est un contrôleur, où au moins un cluster commence avec trois nœuds, puis dans le cas des systèmes de stockage, il y a toujours deux contrôleurs par rack. Pour SDS, il s'agit d'un point de défaillance unique, mais malgré ces inconvénients, de tels scénarios se produisent lors d'une transition progressive du stockage externe vers le SDS ou lors de la mise au rebut d'un système de stockage existant. De plus, il existe des capacités du système de stockage lui-même, telles que la déduplication, la compression, qui, en raison des particularités de l' approche architecturalepas sur SDS Rosplatforma, mais 3PAR l'a et grâce aux scénarios décrits ci-dessus, ils peuvent être utilisés au niveau du stockage.
Les scénarios avec présentation des LUN pour les machines virtuelles, pour les systèmes invités avec leur propre système de cluster sont également pertinents. Dans le cas de la présentation des LUN à chaque machine virtuelle séparément, des inconvénients tels que le manque d'automatisation pendant le cycle de vie d'un grand nombre de machines virtuelles apparaissent, ce qui pourrait être dû au système de fichiers du cluster sur les nœuds Rosplatform, mais GFS2 avec kvm-qemu dans ce cas a échoué, s'il utiliser pour tous les autres fichiers, alors tout fonctionne même dans les tests d'urgence sur la Rosplatform, mais dès que les images de VM y sont placées, le gestionnaire de verrouillage GFS2 ne fait pas face aux tests d'urgence. Peut-être que ce problème sera résolu.
Les scénarios ci-dessus pour l'utilisation de chemins multiples peuvent être utiles pour lier des bibliothèques de bandes. Rosplatform dispose d'un système de sauvegarde intégré (SRK), qui peut écrire des copies dans le dossier du cluster P-storage ou dans un dossier local, mais ne peut pas fonctionner avec des périphériques de bande tant que vous n'avez pas écrit vous-même un script, ou à ces fins, vous pouvez utiliser un SRK externe, par exemple rubackup , qui en plus de travailler avec des bandes, cela aidera à faire des copies de VM avec des LUN attachés, ce qui est important lors de l'intégration avec les systèmes de stockage.