Recommandations pour assurer la résilience des environnements sur le IaaS 3DS OUTSCALE

Cette page a pour objectif de présenter quelques recommandations de déploiement afin de minimiser les risques d’interruption de service sur l’infrastructure de 3DS OUTSCALE.

Prérequis

Nous conservons les préconisations habituelles, permettant d’assurer une bonne résilience dans le déploiement de vos services :

  • Assurez-vous de la mise en place d’un monitoring adéquat pour être alerté en cas d’incident sur les machines directement liées ou non à 3DS OUTSCALE. Cela vous permet de réagir dans les plus brefs délais.

  • Dans la mesure du possible, redondez tout ou une partie de l’architecture sur plusieurs machines (actif-passif ou actif-actif), ou mieux encore prévoyez un plan de continuité d’activité (PCA) ou un plan de reprise d’activité (PRA).

Afin de compléter ces préconisations, nous présentons ici le service de tags avec les metadata, qui vous aideront à répartir efficacement les machines virtuelles de votre architecture dans le Cloud OUTSCALE.

Utilisation des tags repulse et attract

Principe de placement des VM

Chez 3DS OUTSCALE, nous utilisons notre orchestrateur TINA OS, développé par nos équipes de recherche et développement depuis 2010. Cet orchestrateur est utilisé pour gérer toutes les ressources du Cloud. Par exemple, lorsqu’un utilisateur déploie une VM, notre orchestrateur détermine la position la plus adéquate pour cette dernière sur un hôte physique en fonction de plusieurs paramètres : le nombre de vCPU, le nombre de gibioctets de RAM et la génération de vCPU demandée.

Afin d’influencer le choix de la position de votre VM, nous pouvons indiquer des choix à travers des tags. Nous allons présenter deux scénarios possibles : repulse_server et attract_server, afin de diminuer les risques d’indisponibilité liés à une défaillance d’hyperviseur. Nous recommandons fortement, lorsque cela est possible sur la Région concernée, d’utiliser plusieurs Sous-régions pour vos architectures déployées dans le Cloud.

À titre d’exemple : si on souhaite positionner deux VM sur des hyperviseurs différents (pour une base de données en cluster par exemple), alors sur chacune des VM du cluster on ajoute un tag repulse_server de cette façon :

osc.fcu.repulse_server = host-db

Toutes les VM avec la même valeur de tag (ici "host-db") essaieront alors de se "repousser" et de se positionner sur des hyperviseurs différents. En agissant sur le placement de la VM, nous pouvons donc supprimer le risque d’avoir deux VM du même cluster sur le même serveur physique. Dans cet exemple, avec ce positionnement fin, nous augmentons la robustesse de notre cluster de base de données.

Si on souhaite un mécanisme inverse au tag repulse_server, il faut utiliser le tag attract_server. Typiquement, dans le cas où on souhaite diminuer la latence réseau entre des VM, on peut les positionner sur le même serveur physique : si les VM sont sur le même hôte physique, les performances réseau sont améliorées.

Le même mécanisme existe avec des clusters Cisco UCS. Dans ce cas, les tags à utiliser sont repulse_cluster et attract_cluster.

Application stricte

Ces mécanismes de répulsion et d’attraction fonctionnent en best effort, c’est-à-dire que TINA OS essaie dans la mesure du possible de positionner les VM selon les tags spécifiés. Si l’application des tags n’est pas possible à un instant T, alors TINA OS démarre quand même les VM sans tenir compte des tags spécifiés.

Pour empêcher le démarrage des VM, vous pouvez ajouter aux tags le suffixe _strict. Dans ce cas, s’il n’est pas possible d’appliquer les tags spécifiés, alors les VM ne démarrent pas et une erreur InsufficientCapacity est renvoyée. Le suffixe _strict vous permet ainsi d’avoir une gestion plus fine de votre infrastructure.

Exemples

$ cat repulse.clair
-----BEGIN OUTSCALE SECTION-----
tags.osc.fcu.repulse_server=host-db
-----END OUTSCALE SECTION-----

# Encodage des user data en Base64 avec remplacement des \n
$ openssl enc -base64 -in repulse.clair | tr -d "\n" > repulse
$ cat repulse
LS0tLS1CRUdJTiBPVVRTQ0FMRSBTRUNUSU9OLS0tLS0KdGFncy5vc2MuZmN1LnJlcHVsc2Vfc2VydmVyPXRvdG8KLS0tLS1FTkQgT1VUU0NBTEUgU0VDVElPTi0tLS0t=

# Creation de la VM avec le tag repulse_server
$ osc-cli api CreateVms \
    --ImageId "ami-976177b8" \
    --KeypairName "MyKey" \
    --VmType "tinav4.c4r4" \
    --Placement '{"SubregionName": "eu-west-2a", "Tenancy": "default"}' \
    --UserData "LS0tLS1CRUdJTiBPVVRTQ0FMRSBTRUNUSU9OLS0tLS0KdGFncy5vc2MuZmN1LnJlcHVsc2Vfc2VydmVyPXRvdG8KLS0tLS1FTkQgT1VUU0NBTEUgU0VDVElPTi0tLS0t="

Une façon efficace de vérifier l’application des tags de placement est de vérifier depuis la VM en téléchargeant un hash du serveur ou du cluster (correspondant à un châssis de 8 serveurs) sur lequel la machine est positionnée, et de le comparer avec une autre VM. Ces informations sont disponibles sur le serveur de metadata accessible sur n’importe quelle VM du Cloud :

# Pour le cluster
$ curl http://169.254.169.254/latest/meta-data/placement/cluster
042c0d0863ef30fcd4e8ae28d1b21021730738a

# Pour le serveur (= hyperviseur)
$ curl http://169.254.169.254/latest/meta-data/placement/server
15e5a7d3ccf781868601140d46d2ad23588ff55b

Si les hashes renvoyés par deux VM sont identiques, alors il s’agit du même serveur (ou du même cluster). Sinon, il s’agit de serveurs (ou clusters) différents.

Utilisation de l’attribut ShutDownBehavior

Toutes les VM dans le Cloud OUTSCALE possèdent une liste d’attributs. Nous allons nous intéresser à l’attribut vmInitiatedShutdownBehavior (ou instanceInitiatedShutdownBehavior selon l’API que vous souhaitez utiliser). Vous pouvez bien entendu modifier l’attribut directement depuis l’interface web Cockpit.

Cet attribut permet de définir le comportement de la VM en cas d’interruption du processus d’hyperviseur qui porte la VM. Le fait de lancer un appel API pour demander l’arrêt d’une VM correspond à une interruption du processus rattaché à votre VM.

Dans le cas d’un dysfonctionnement majeur, 3DS OUTSCALE peut éventuellement réaliser des opérations de migration de VM, afin que les services associés à vos VM puissent redémarrer le plus rapidement possible.

Nous recommandons, lorsque possible, de spécifier pour cet attribut la valeur restart. Ainsi, en cas de migration de la VM sur un autre hyperviseur, la VM pourra redémarrer automatiquement sans intervention de votre part. En conséquence, il vous faudra alors changer l’attribut avant de faire un appel API d’arrêt si vous souhaitez éteindre la VM.

Voici un exemple d’appel API renvoyant des informations sur une VM donnée, dont notamment la valeur de l’attribut vmInitiatedShutdownBehavior :

$ osc-cli api ReadVms --Filters '{"VmIds": ["i-7965861d"]}'

Conclusion

Quelles que soient les applications que vous déployez dans le Cloud, il est fortement recommandé d’utiliser des tags de répulsion et d’attraction et de déployer sur plusieurs Sous-région, afin d’améliorer la résilience de ces applications. Ne pas se soucier de l’emplacement des VM représente un risque non nul de voir celles-ci placées sur le même hyperviseur. Ceci aura potentiellement pour conséquence de provoquer une interruption de service en cas de défaillance matérielle de l’hyperviseur.

Pages connexes

Exporter en PDF