Paper97 Slides Rev2611 20220525 162013

Migration vers une
double infrastructure hyperconvergée

Rafael.DiazMaurin@univ-rennes1.fr
DSI de l’Université de Rennes1,
Responsable de l’équipe Système
- 18 mai 2022 JRES Marseille -

Agenda
●
Double HCI : pourquoi, comment
●
Joies et désenchantements
●
Bilan provisoire
Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Rafael DiazMaurin@univ-rennes1.fr JRES Marseille
Contexte de l’établissement
●
L’Université de Rennes1 :
– 31 408 étudiants
– 3 471 personnels
– 30 laboratoires de recherche
– 6 campus
– 500 diplômes et 100 formations en alternance
●
La DSI de l’Université de Rennes1 :
– 200 services numériques et 104 applications
– 580 machines virtuelles, 30 conteneurs (LXC et docker)
Cahier des charges
●
Renouvellement de l’infrastructure de virtualisation et de
stockage
●
Depuis 2013 :
– 1 SAN Compellent (SC8000) répliqué sur 2 salles
– 26 ESX (R7x0) connectés via des fabrics FC
●
250 To utiles
●
550+ VM à migrer
●
Rationaliser nos systèmes de stockage hétérogènes
(baies PowerVault SAS, FC, iSCSI...)
Migration vers une double infrastructure hyperconvergée
Double HCI : pourquoi, comment
Rafael DiazMaurin@univ-rennes1.fr
Difficultés avec notre SAN
●
Fin de vie annoncée par l’éditeur
●
Performances dégradées
●
Résilience limitée dans notre cas
(réplication entre 2 salles, mais basculement manuel)
●
Manque de compétences de l’équipe
●
Volonté de récupérer la maîtrise technique et financière
avec investissements progressifs

Étude des HCI (« matérielles » et « logicielles »)

Atout HCI
Croissance granulaire de l’infra sans remettre en cause l’architecture globale

Couplage vSphere/vSAN
●
vSAN : stockage distribué intégré à vSphere (2014)
●
La politique de résilience s’applique à chaque objet
(VM, disque…)
– stockage bloc uniquement (pour les VM)
– stockage fichier peu étoffé
– pas de stockage objet

vSAN : les diskgroups
●
vSAN agrège des diskgroups entre eux pour
construire 1 DataStore unique et résilient
– 1 à 5 diskgroup par nœud (3)
– 1 SSD cache
– + 5 à 7 SSD/HDD

Le stockage distribué Ceph
●
Robuste, sous Linux, passe à l’échelle
●
Ceph distribue les objets dans des Groupes de
Placement (PG) stockés sur des OSD et assure leur
résilience :
– 1 OSD == 1 SSD (gestion facilitée)
– réplication ou codage à effacement
●
3 types de stockages : objet (S3/Swift), bloc, fichiers

Solution de
Stockage
Unifiée
Stockage
Distribué
Logiciel
Ceph
Linux OS
Matériel
Standard
Source : https://medium.com/@pk0752/ceph-the-next-generation-store-67f7c51780d3
erasure-coding (vSAN et Ceph)
●
Le codage à effacement
– Découpage d’un objet en K fragments
– Codés avec m fragments redondants
●
Assure une parité
– (perte de m fragments)
– +- RAID5
– => SSD

Ceph avec KVM/QEMU
●
vSphere ne supporte pas Ceph nativement
– Passerelles : iSCSI+RBD ou NFS+CephFS
●
=> latence critique pour tourner des VM
●
KVM hyperviseur libre intégré à Linux (2007)
●
QEMU : logiciel libre de machine virtuelle
– peut utiliser le stockage bloc de Ceph (RBD)

Proxmox : Ceph+KVM+QEMU
●
Virtualisation libre sous Debian depuis 2008
●
~ mêmes fonctionnalités que vSphere
(HA, migration à chaud, snapshots)
+ support Ceph + iptables + sauvegardes + admin cluster

- DRS
●
API riche
●
Support payant possible :
=> Attention : pas de récupération de données assurée
Comparaison Proxmox/Ceph VS vSphere/vSAN

Choix d’une double HCI logicielle
●
vSphere est incontournable pour répondre à certaines
contraintes d’éditeurs
●
Ceph est plus élastique
●
Déploiement de 2 HCI en parallèle
– socle de matériel identique
●
redéploiement possible de nœuds ou de SSD
– comparaison en conditions réelles
●
Migration possible des VM de l’une à l’autre
« On ne met pas tous nos nœuds dans le même panier »
Architecture réseau de la double HCI
latence = latence moyenne de chaque LACP

Architecture Proxmox/Ceph Architecture vSphere/vSAN

Politiques de stockage

Sauvegardes VM Proxmox (+PRA/PCA)
●
Petit cluster Proxmox/Ceph (POC initial sur 4 nœuds)
– disques plateaux capacitifs
– mêmes configurations réseau et mêmes permissions
– possible de faire tourner des VM (PRA/PCA possible)
●
Snapshots CEPH-RBD quotidiens sur le cluster de production
●
Exportés dans SSH vers cluster de sauvegarde et historisés
●
5 derniers conservés sur la production
(invisibles pour les utilisateurs)
●
Sauvegardes montages CephFS avec TiNa (validé par ATempo)
Sauvegardes VM vSphere
●
Utilisation de TiNa (HVDS) de ATempo
– Réplication des sauvegardes TiNa vers une VM sous Proxmox
avec stockage Ceph validé par ATempo
– Connexion au vCSA
– Plus lent que les exports/restaurations de snapshots Ceph-RBD

Architecture logique de la double HCI

Joies et désenchantements
Joies… 1/2
●
Redéploiement de :
– SSD possibles entre les 2 HCI
– nœuds possibles vers l’une ou l’autre
●
Liberté de déployer des VM sur l’infra la plus appropriée :
– matrice compatibilité, coût associé, performances, stabilité
●
Migration VM scriptée de vSphere vers Proxmox
(utilisation uuid, ajout pilotes (virtio), conversion disques (qemu-
img), renommage interfaces réseau, installation agent)
– En cours de Proxmox vers vSphere
Joies… 2/2
●
Administration des VM indifférenciée :
– déploiement Linux (PXE), windows (template)
– gestion configuration, sauvegarde fichiers, journalisation, supervision,
métrologie
●
Meilleure résilience des services en cluster
– bonne validation (cf. pannes non franches)
●
1 atout pour Proxmox et 1 pour Ceph :
– Hébergement VM hors DSI (filtrage réseau au sein d’un même VLAN)
– Import/Export de snapshots de VM (images RBD)
ou de pools Ceph complets vers un autre cluster
…et désenchantement 3/3
●
Même socle réseau
– une opération de maintenance du cœur de réseau a coupé les 2
HCI quelques minutes
– stockages reconstruits automatiquement
●
Courbe d’apprentissage plus longue (absorbée)
●
et...

…quelques déconvenues avec VMware
●
Coût des multiples licences VMware + support
●
1 seule VM d’administration en HA
●
Si perte SSD de cache => perte du diskgroup
●
Incidents avec vSphere 7.0 (update2, update3b)
– invalidation snapshots, HA, mode maintenance
– support sans gestion centralisée

…retour sur un incident Proxmox
●
MTU à 1500 sur 1 switch d’un mon (au lieu de 9000) :
– perte de messages corosync (quorum Proxmox)
– redémarrages intempestifs de certains nœuds
– résolu rapidement avec le support Proxmox

…retour sur un incident Ceph
●
Mauvaise répartition des réplicas des PG lors de l’extension
du cluster sur les 3 DC
– règle crush non prise en compte (corrigée)
– plusieurs réplicas étaient sur le même OSD
– ceph osd purge et retrait des disques précoce :
●
stale+undersized+degraded+peered
– résolu avec prestataire ceph
●
mount des OSD en cherchant l’id sur le 1er secteur SSD
– support Proxmox non qualifié pour récupération de données
– script de location des PGs
Bilan provisoire
Quelques chiffres
●
HCI Proxmox/Ceph (12 nœuds + 3 moniteurs)
– 260 VM, 864 vCPU, 9To vRAM, 480 To bruts (avec extension en 2021 )
– ~20 % à réserver pour Ceph et Proxmox (+ seuil 80 % max)
– Début 2022 en moyenne pour 1 VM : 2 vCPU + 23 Go RAM + 450 Go de SSD
●
HCI vSphere/vSAN (10 nœuds + 1 witness)
– 320 VM, 720 vCPU, 7,5To vRAM, 260 To bruts (espace non étendu)
– ~20 % à réserver pour vSphere et vSAN (+ seuil 80 % max)
– Début 2022 en moyenne pour 1 VM : 1,5 vCPU + 15 Go RAM + 250 Go de SSD
●
10 min pour migrer 1 VM (50Go) de vSphere vers Proxmox
●
Disponibilité :
– Proxmox/Ceph sur 2 ans : 99,87 %
– vSphere/vSAN sur 1 an : 99,86 %
Retour sur le projet
●
400 JH sur 4 ans :
– 2017/2018 : 1ères réflexions, études, formations
merci ANF CNRS sur le stockage distribué (2016) puis sur Ceph (2017)
– début 2019 : déploiement réseau et formation Proxmox
– fin 2019 : déploiement Proxmox/Ceph sur 4 nœuds (1ères VM + migrations) et formation vSAN
– avril 2020 : déploiement moodle sur CephFS
– fin 2020 : déploiement vSphere/vSAN + extension Proxmox/Ceph sur 3 sites
– mars 2021 : migration 550 VM depuis l’ancienne infra
– fin 2021 : docker sur CephFS
– début 2022 : ouverture hébergement laboratoires, POC samba sur CephFS
●
4 personnes impliquées :
– 1 orchestrateur (+ Proxmox/Ceph) + 1 Réseau + 1 vSphere/vSAN + 1 VM
●
MCO comparable
●
Ceph : + de services donc + de temps passé
Perspectives et évolutions
●
Ré-internalisation de moodle
●
Internalisation de Learning Analytics
●
Remplacement du NAS FluidFS
– NFS => CephFS (natif dans linux)
– SMB/CIFS => samba dans LXC (Proxmox) au dessus de CephFS
●
Automatiser migration VM Proxmox vers vSphere
●
Remplacement des baies de stockage hétérogènes
●
Scripter bascule VM Proxmox pour PCA/PRA
●
POC à venir de Ceph RADOS Gateway (S3)
– pour Nuxeo (GED), et autres ?
Conclusion
●
Les incidents (bugs ou miss-configs résolus) ne
remettent pas en cause le choix d’une double HCI :
– performantes, stables et fiables
– support Proxmox, Ceph, vSphere, vSAN
●
Nous sommes parvenus à prendre en main les différentes
technologies qui répondent à nos besoins actuels et aux
projets envisagés

Annexes
Performances du stockage
●
Ceph orienté résilience, est plus performant en écritures
aléatoires sur ce test
– 1 seule VM Rockylinux 8.5 : 2 vCPU, 4 GO RAM
– mesure (avec fio) sur vSAN puis migration de la VM sur Ceph

Un socle de matériels uniques
●
Exercice compliqué par vSAN :
– => nécessaire validation dans la matrice de compatibilité
– => 1 SSD de cache pour chaque DiskGroup
●
Serveurs au marché : DELL PowerEdge R740xd
●
Stockage sur SSD uniquement
– SSD SAS RO (1 écriture complète par jour sur 5 ans)
– Caches vSAN : SSD 800 Go WI (10 écritures complètes)
●
Double attachement réseau 10 Gb
– 1 LACP pour chaque VLAN et pour le trunk des VM
– 2 VLAN pour VMware et 3 VLAN pour Proxmox/Ceph
●
Carte RAID dispensable :
– JBOD : OS en RAID1 sur contrôleur BOSS+2 cartes M2 SSD SATA
Quelques divergences matérielles
●
3 moniteurs Ceph dédiés (bonnes pratiques)
– En cas de crash les moniteurs sont très sollicités
– DELL PowerEdge R440
●
1 serveur Witness pour vSphere
– stocke les composants témoins de chaque objet
– arbitre du cluster en cas de cluster étendu (évite le split-brain)
– DELL PowerEdge R440

Merci pour votre attention !
Des questions ?
DSI de l’Université de Rennes1,
Responsable de l’équipe système

Paper97 Slides Rev2611 20220525 162013

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Paper97 Slides Rev2611 20220525 162013

Transféré par

Droits d'auteur :

Formats disponibles

Migration vers une

double infrastructure hyperconvergée

- 18 mai 2022 JRES Marseille -

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Double HCI : pourquoi, comment

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Croissance granulaire de l’infra sans remettre en cause l’architecture globale

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

+ support Ceph + iptables + sauvegardes + admin cluster

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

latence = latence moyenne de chaque LACP

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Migration vers une double infrastructure hyperconvergée 18 mai 2022 –

Vous aimerez peut-être aussi