Le service numérique duplique-t-il les données uniquement lorsque cela est nécessaire ?
Version 2. Dernière mise à jour le
Objectif
Réduire les ressources informatiques et les ressources de stockage utilisées.
Il s’agit de se poser la question du bon niveau de service sélectionné par rapport au besoin. Plus le taux de disponibilité demandé est haut, plus cela mobilise une infrastructure financièrement et environnementalement coûteuse.
Mise en œuvre
Ne pas systématiquement dupliquer toutes les données mais identifier les données nécessaires à être dupliquées (données critiques ou données très sollicitées par exemple). Un équilibre est à trouver entre sécurisation (pour éviter les pertes de données) et dissémination (en avoir trop partout).
Se questionner sur la pertinence de la redondance du service, pour en établir le bon dosage. Est-ce critique si l’une des fonctionnalités du service n’est pas disponible pendant un certain temps ?
- Le Backup & Restore est ce qu’il y a de moins cher, parfaitement adapté aux applications qui ont un RTO (Recovery Time Objective) ou RPO (Recovery Point Objective) de quelques heures.
- Le Pilot Light, à savoir par exemple une base de données « mirrorée » / dupliquée mais avec des machines virtuelles éteintes. Procédé un peu plus cher qu’un Backup & Restore, il fonctionne pour la plupart des applications qui n’ont pas d’exigences SLA (Service Level Agreement) extrêmes (inférieures à 1 heure).
- Le Warm Standby, lorsque les VMs tournent déjà mais dans une scalabilité limitée, presque en temps réel mais potentiellement en qualité légèrement dégradée s’il y a un incident.
- Le Hot Standby multisite : résilience totale pour des SLAs (Service Level Agreements) temps réel. Aucune perte de service n’est tolérée, mais cela a nécessairement un coût.
Moyen de test ou de contrôle
Pour valider ce critère, vérifier la présence d’un SLA (Service Level Agreement) ajusté selon les besoins.