Baie iSCSI unique, snapshots et projet de migration ERP vers le cloud

Hiérarchie des risques :

1. Perte de données totale. Une baie iSCSI unique porte les 62 VM et les snapshots Veeam. Une panne de baie, un firmware défaillant ou un rançongiciel qui chiffre les datastores détruit à la fois la production et les sauvegardes conservées 7 jours. Les bandes hebdomadaires limitent la casse à 7 jours de perte, bien au-delà du RPO annoncé de 24 h. C'est le risque numéro un, avant même la performance.
2. RTO non tenu. Le RTO de 4 h pour l'ERP n'est démontré par rien : aucun test depuis 14 mois, 18 VM redémarrées à la main en 6 h lors du dernier incident, pas de runbook. Un RTO non testé est une hypothèse, pas un engagement.
3. RAID 5 sur 24 To. Avec des disques de forte capacité, la reconstruction après une panne dure des heures à des jours et le risque d'erreur de lecture irrécupérable pendant la reconstruction est réel. Un RAID 6 ou un RAID 10 avec disque de secours est préférable, et une seconde baie ou un stockage distinct pour les sauvegardes est indispensable.
4. Surallocation et absence de N+1. À 6:1 en CPU et 1,4:1 en mémoire, la perte d'un hôte ne laisse pas assez de ressources pour redémarrer les 18 VM, surtout avec un ERP à 16 vCPU : le contrôle d'admission de HA refusera le redémarrage ou le fera en dégradant tout le monde. La surallocation CPU est acceptable pour des serveurs peu chargés, pas pour une base de données.
5. Dépendance à la baie pour le stockage des sauvegardes : le référentiel Veeam doit être ailleurs, avec une copie immuable.

Le classement suit l'impact : d'abord la perte irréversible de données, ensuite l'incapacité à redémarrer dans les délais, enfin la performance.

Cible proposée, avec les arbitrages :

• Réplica de l'ERP sur un second site ou un second stockage, via Veeam Replication ou la réplication de baie, avec un point de reprise toutes les heures. Le RPO contractuel est de 24 h, mais une réplication horaire donne de la marge pour un RTO serré et coûte peu pour une seule VM. Le RTO de 4 h suppose un démarrage planifié et testé, pas une reconstruction depuis la bande : une VM de 64 Go restaurée depuis bande prend plusieurs heures à elle seule.
• Référentiel de sauvegarde distinct et immuable : un serveur de sauvegarde durci (disque Linux en mode immuable ou appliance dédiée) avec des identifiants qui ne sont pas ceux du domaine. Les snapshots Veeam sur la baie de production restent utiles pour un retour arrière rapide mais ne constituent pas une sauvegarde.
• Plan de reprise documenté et ordonné : AD et DNS d'abord, puis ERP, puis messagerie, puis les autres. Les dépendances (SQL, partages, certificats) doivent être écrites et les VM regroupées dans un plan de reprise Veeam exécutable en une action. Le RTO se mesure sur l'ERP, pas sur la moyenne.
• Test semestriel obligatoire, avec chronométrage et rapport : restauration de l'ERP dans un réseau isolé, validation applicative par le métier, mesure du temps réel. C'est le seul moyen de savoir si les 4 h sont tenues.
• Dimensionnement N+1 : activer le contrôle d'admission HA, vérifier que deux hôtes absorbent la charge, et découper l'ERP en 2 × 8 vCPU pour qu'il reste ordonnançable. Ajouter un hôte ou réduire la surallocation est probablement nécessaire.
• Redondance du stockage : baie en RAID 6 avec disque de secours, ou réplication vers une seconde baie ; surveiller l'état des disques et la latence iSCSI.

Le coût d'un second site complet est difficile à justifier ; répliquer uniquement les VM de rang 1 et conserver une copie immuable des autres est le bon compromis.

Quatre questions à trancher avant de signer :

1. Nature de l'application. Un ERP client/serveur avec base relationnelle et clients lourds est très sensible à la latence entre le siège et le cloud. Un lift-and-shift sans étude des flux (impressions, accès fichiers, traitements batch) aboutit à une dégradation que les utilisateurs refuseront. Si l'éditeur propose une version SaaS, c'est elle qu'il faut comparer, pas un IaaS.
2. Licences et support. Vérifier les droits de mutualisation et d'hébergement chez un tiers (Microsoft, Oracle, éditeur de l'ERP), le mode de facturation (par cœur, par utilisateur nommé) et les contraintes de localisation des données. Une migration qui oblige à racheter des licences peut annuler le gain.
3. Dépendances et exploitation. L'ERP dépend de l'AD, du DNS, des certificats et des sauvegardes. En cloud, il faut un lien dédié ou un VPN IPsec avec débit et latence garantis, une authentification fédérée, et une équipe capable d'exploiter les deux environnements. Trois personnes ne peuvent pas maintenir deux infrastructures distinctes.
4. Réversibilité et coût complet. Exiger un plan de sortie (formats d'export, délais, coûts de sortie), un engagement de disponibilité avec pénalités, et comparer sur cinq ans avec l'option PRA sur site : le coût du cloud ne se limite pas à la VM, il inclut le réseau, le stockage, la sauvegarde et l'exploitation.

Recommandation : ne pas commencer par l'ERP. Migrer d'abord des charges peu critiques (messagerie, intranet, environnement de test) pour apprendre, sécuriser l'ERP sur site avec une réplication et un PRA testé, et ne migrer l'ERP que si l'éditeur fournit un mode hébergé supporté ou si le lien réseau et le plan de reprise sont contractualisés. Une migration IaaS subie serait plus risquée que l'architecture actuelle corrigée.