Paper97 Slides Rev2611 20220525 162013

Migration vers une
double infrastructure hyperconvergée

[email protected]
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 [email protected] 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 [email protected]
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
[email protected]
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
[email protected]
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
[email protected]
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 ?
[email protected]
DSI de l’Université de Rennes1,
Responsable de l’équipe système

Paper97 Slides Rev2611 20220525 162013

Transféré par

Droits d'auteur :

Formats disponibles

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