Cette page a été traduite par l'API Cloud Translation.

Déployer un serveur Web récupérable à froid à l'aide d'instantanés de disque persistant

Last reviewed 2021-08-04 UTC

Ce document explique comment déployer une topologie de basculement à froid pour un serveur Web à l'aide d'un groupe d'instances géré et d'instantanés de disque persistant. Ce document est destiné aux architectes et aux personnes travaillant dans les équipes opérationnelles et administratives.

Vous créez un groupe d'instances géré qui exécute une VM unique avec un disque persistant qui stocke des données. Les instantanés planifiés du disque persistant minimisent la perte de données dans un scénario de basculement. Un équilibreur de charge d'application externe dirige les utilisateurs vers la VM qui s'exécute dans le groupe d'instances géré, comme illustré dans l'image suivante :

Un équilibreur de charge d'application externe dirige les utilisateurs vers une VM unique qui s'exécute dans un groupe d'instances géré. Une règle de ressources crée des instantanés réguliers d'un disque persistant associé à la VM.

En cas de défaillance d'une instance, le groupe d'instances géré tente de recréer la VM dans la même zone. Si la défaillance se produit au niveau d'une zone, Cloud Monitoring ou une autre méthode similaire peut vous avertir et créer manuellement un autre groupe d'instances géré dans une autre zone ou région. Dans les deux scénarios de basculement, la plate-forme utilise le dernier instantané de disque persistant pour créer un disque de remplacement et l'associer à la nouvelle VM du groupe d'instances.

Dans ce document, vous utilisez l'adresse IP externe de la VM ou de l'équilibreur de charge pour afficher une page de base sur le serveur Web. Cette approche vous permet de tester le modèle de basculement à froid si vous n'avez pas de nom de domaine enregistré, sans aucune modification DNS. Dans un environnement de production, créez et configurez une zone et un enregistrement Cloud DNS associés à l'adresse IP externe attribuée à l'équilibreur de charge.

Ce modèle équilibre le coût d'exécution de plusieurs VM ou disques persistants régionaux tout en maintenant un certain niveau de protection des données. Les coûts sont réduits lorsque vous n'exécutez qu'une VM avec un seul disque persistant, mais le risque de perte de données est élevé car les instantanés de disque persistant ne sont pris qu'à un intervalle défini.

Le tableau suivant souligne les principales différences entre les options de protection des données des approches de récupération à froid utilisant des disques persistants régionaux ou des instantanés de disques persistants. Pour plus d'informations, consultez la section Options de haute disponibilité avec des disques persistants.

	Disques persistants régionaux	Instantanés de disque persistant
Perte de données : objectif de point de récupération (RPO)	Zéro pour une seule défaillance, telle qu'une interruption continue dans une zone ou une déconnexion du réseau.	Toutes les données depuis la dernière prise d'instantané, soit généralement une heure ou plus. La perte potentielle de données dépend de votre programmation d'instantanés, qui contrôle la fréquence à laquelle les instantanés sont pris.
Objectif de temps de récupération (RTO)	Temps de déploiement d'une nouvelle VM, plus quelques secondes pour la réinstallation du disque persistant régional.	Temps de déploiement d'une nouvelle VM, plus temps de création d'un disque persistant à partir du dernier instantané. Le temps de création du disque dépend de la taille de l'instantané et peut durer plusieurs dizaines de minutes, voire plusieurs heures.
Coût	Les coûts de stockage sont doublés, car le disque persistant régional est répliqué en continu dans une autre zone.	Vous ne payez que le montant pour l'espace d'instantané utilisé.
	Pour en savoir plus, consultez la section Tarifs des disques et des images.

Objectifs

Créer un groupe d'instances géré pour exécuter une VM avec un disque persistant.
Configurer une programmation d'instantanés pour prendre des instantanés réguliers du disque persistant.
Créer un modèle d'instance et un script de démarrage.
Créer et configurer un équilibreur de charge d'application externe.
Tester le basculement du serveur Web à froid avec un groupe d'instances géré de remplacement.

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Avant de commencer

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the Compute Engine API.

Enable the API

Install the Google Cloud CLI.

To initialize the gcloud CLI, run the following command:

gcloud init

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the Compute Engine API.

Enable the API

Install the Google Cloud CLI.

To initialize the gcloud CLI, run the following command:

gcloud init

Vous pouvez exécuter Google Cloud CLI dans la console Google Cloud sans avoir à installer Google Cloud CLI. Pour exécuter gcloud CLI dans la console Google Cloud, utilisez Cloud Shell.

Préparer l'environnement

Dans cette section, vous allez définir des variables pour les noms et les emplacements de vos ressources. Ces variables sont utilisées par les commandes de Google Cloud CLI lors du déploiement des ressources.

Tout au long de ce tutoriel, sauf indication contraire, vous devez saisir les commandes dans Cloud Shell ou dans votre environnement de développement local.

Remplacez PROJECT_ID par votre ID de projet : Si nécessaire, indiquez votre propre suffixe de nom pour les ressources, par exemple app.

Spécifiez une région, telle que us-central1, et deux zones de cette région, telles que us-central1-a et us-central1-f. Ces zones définissent l'emplacement où le disque persistant initial et le groupe d'instances géré sont déployés, et où vous pouvez basculer manuellement si nécessaire.
```
PROJECT_ID=PROJECT_ID
NAME_SUFFIX=app
REGION=us-central1
ZONE1=us-central1-a
ZONE2=us-central1-f
```

Créer un VPC et un sous-réseau

Pour fournir un accès réseau aux VM, créez un cloud privé virtuel (VPC) et un sous-réseau. Étant donné que le groupe d'instances géré fonctionne dans les zones d'une même région, un seul sous-réseau est créé. Pour en savoir plus sur les avantages du mode de sous-réseau personnalisé afin de gérer les plages d'adresses IP utilisées dans votre environnement, consultez la section Utiliser des réseaux VPC en mode personnalisé.

Créez le VPC avec un mode de sous-réseau personnalisé :
```
gcloud compute networks create network-$NAME_SUFFIX \
    --subnet-mode=custom
```
Si une invite Cloud Shell s'affiche, autorisez cette première requête à effectuer des appels d'API.

Créez un sous-réseau dans le nouveau VPC. Définissez votre propre plage d'adresses, telle que 10.1.0.0/20, en fonction de votre plage réseau :

gcloud compute networks subnets create subnet-$NAME_SUFFIX-$REGION \
    --network=network-$NAME_SUFFIX \
    --range=10.1.0.0/20 \
    --region=$REGION

Créer des règles de pare-feu

Créez des règles de pare-feu pour autoriser le trafic Web et les vérifications d'état pour l'équilibreur de charge et les groupes d'instances gérés :

gcloud compute firewall-rules create allow-http-$NAME_SUFFIX \
    --network=network-$NAME_SUFFIX \
    --direction=INGRESS \
    --priority=1000 \
    --action=ALLOW \
    --rules=tcp:80 \
    --source-ranges=0.0.0.0/0 \
    --target-tags=http-server

gcloud compute firewall-rules create allow-health-check-$NAME_SUFFIX \
    --network=network-$NAME_SUFFIX \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=allow-health-check \
    --rules=tcp:80

La règle HTTP suivante autorise le trafic vers toutes les VM sur lesquelles l'option http-server est appliquée, et depuis n'importe quelle source utilisant la plage 0.0.0.0/0. Concernant la règle de vérification de l'état, les plages par défaut de Google Cloud sont définies pour permettre à la plate-forme de vérifier correctement l'état des ressources.

Afin d'autoriser le trafic SSH pour la configuration initiale d'une image de VM de base, définissez le champ d'application de la règle de pare-feu dans votre environnement à l'aide du paramètre --source-range. Vous devrez peut-être collaborer avec votre équipe réseau pour déterminer les plages sources utilisées par votre organisation.

Important : Nous vous déconseillons d'utiliser une large plage de 0.0.0.0/0 qui pourrait autoriser tout le trafic. Pour acheminer le trafic vers une seule adresse IP, utilisez un masque de réseau /32, tel que 35.230.62.163/32.

Remplacez IP_ADDRESS_SCOPE par vos propres champs d'application d'adresses IP :
```
gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX \
    --network=network-$NAME_SUFFIX \
    --direction=INGRESS \
    --priority=1000 \
    --action=ALLOW \
    --rules=tcp:22 \
    --source-ranges=IP_ADDRESS_SCOPE
```

Après avoir créé les règles de pare-feu, vérifiez que les trois règles ont bien été ajoutées :

gcloud compute firewall-rules list \
    --project=$PROJECT_ID \
    --filter="NETWORK=network-$NAME_SUFFIX"

L'exemple de résultat suivant montre que les trois règles ont été correctement créées :

NAME                    NETWORK      DIRECTION  PRIORITY  ALLOW
allow-health-check-app  network-app  INGRESS    1000      tcp:80
allow-http-app          network-app  INGRESS    1000      tcp:80
allow-ssh-app           network-app  INGRESS    1000      tcp:22

Créer et configurer une image de VM de base

Pour créer des VM identiques que vous déployez sans configuration supplémentaire, utilisez une image de VM personnalisée. Cette image capture la configuration du système d'exploitation et d'Apache et permet de créer chaque VM dans le groupe d'instances géré lors des étapes suivantes.

Vous allez utiliser un disque persistant pour stocker les données d'application. Dans le cadre du présent document, vous utilisez un site Web Apache de base pour diffuser l'application. Par la suite, vous créerez une programmation d'instantanés associée à ce disque persistant afin de créer des instantanés de disque automatisés.

Sur la VM, créez un fichier index.html de base sur le disque persistant et installez-le sur /var/www/example.com. Un fichier de configuration Apache sous /etc/apache2/sites-available/example.com.conf diffuse le contenu Web à partir de l'emplacement de disque persistant installé.

Le schéma suivant illustre la page HTML de base diffusée par Apache, stockée sur le disque persistant.

La VM dispose d'une page HTML de base stockée sur le disque persistant avec un fichier de configuration Apache à charger à partir de l'emplacement où est installé le disque.

Pour créer cet environnement, procédez comme suit :

Créez un disque SSD de 10 Gio. Déterminez vos besoins de stockage et les coûts associés au paiement de l'espace provisionné, et non de l'espace utilisé. Pour en savoir plus, consultez la section Tarifs des disques persistants.
```
gcloud compute disks create disk-$NAME_SUFFIX \
    --zone $ZONE1 \
    --size=10 \
    --type=pd-ssd
```

Créez une VM de base à laquelle un disque persistant est associé :

gcloud compute instances create vm-base-$NAME_SUFFIX \
    --zone=$ZONE1 \
    --machine-type=n1-standard-1 \
    --subnet=subnet-$NAME_SUFFIX-$REGION \
    --tags=http-server \
    --image=debian-10-buster-v20210721 \
    --image-project=debian-cloud \
    --boot-disk-size=10GB \
    --boot-disk-type=pd-balanced \
    --boot-disk-device-name=vm-base-$NAME_SUFFIX \
    --disk=mode=rw,name=disk-$NAME_SUFFIX,device-name=disk-$NAME_SUFFIX

Vous utilisez les paramètres définis au début de ce document pour nommer la VM et vous connecter au sous-réseau approprié. Les noms sont également attribués à partir des paramètres du disque de démarrage et du disque de données.

Pour installer et configurer le site Web simple, connectez-vous d'abord à la VM de base via SSH :
```
gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE1
```

Dans votre session SSH vers la VM, créez un script pour configurer la VM dans l'éditeur de votre choix. L'exemple suivant utilise Nano en tant qu'éditeur :

nano configure-vm.sh

Collez le script suivant dans le fichier. Mettez à jour la variable NAME_SUFFIX pour qu'elle corresponde à la valeur définie au début de ce document, par exemple app :

#!/bin/bash

NAME_SUFFIX=app

# Create directory for the basic website files
sudo mkdir -p /var/www/example.com
sudo chmod a+w /var/www/example.com
sudo chown -R www-data: /var/www/example.com

# Find the disk name, then format and mount it
DISK_NAME="google-disk-$NAME_SUFFIX"
DISK_PATH="$(find /dev/disk/by-id -name "${DISK_NAME}" | xargs -I '{}' readlink -f '{}')"

sudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard $DISK_PATH
sudo mount -o discard,defaults $DISK_PATH /var/www/example.com

# Install Apache, additional utilities, and cloud-init
sudo apt-get update && sudo apt-get -y install apache2 moreutils cloud-init

# Write out a basic HTML file to the mounted persistent disk
sudo tee -a /var/www/example.com/index.html >/dev/null <<'EOF'
<!doctype html>
<html lang=en>
<head>
<meta charset=utf-8>
    <title>HA / DR example</title>
</head>
<body>
    <p>Welcome to a test web server with persistent disk snapshots!</p>
</body>
</html>
EOF

# Write out an Apache configuration file
sudo tee -a /etc/apache2/sites-available/example.com.conf >/dev/null <<'EOF'
<VirtualHost *:80>
        ServerName www.example.com

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/example.com

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
EOF

# Enable the Apache configuration file and reload service
sudo a2dissite 000-default
sudo a2ensite example.com.conf
sudo systemctl reload apache2

Écrivez le fichier et quittez votre éditeur. Par exemple, dans Nano, vous utilisez Ctrl-O pour écrire le fichier, puis vous quittez avec Ctrl-X.
Rendez le script de configuration exécutable, puis exécutez-le :
```
chmod +x configure-vm.sh
./configure-vm.sh
```

En cas de défaillance d'une instance et si le groupe d'instances géré doit créer une instance de remplacement à partir de cette VM de base, les données d'application doivent être disponibles. Les étapes suivantes doivent s'exécuter automatiquement sur chaque nouvelle VM :

Obtenir des informations auprès du serveur de métadonnées.
Obtenir le dernier instantané du disque persistant.
Créer un disque à partir du dernier instantané.
Installer le nouveau disque sur la VM.
Installer le disque dans la VM.

Créez un script de démarrage nommé app-startup.sh qui effectue ces étapes requises pour la VM. Ce script de démarrage est appliqué à un modèle d'instance lors de l'étape suivante.

sudo mkdir /opt/cloud-init-scripts

sudo tee -a /opt/cloud-init-scripts/app-startup.sh >/dev/null <<'EOF'
#!/bin/bash

# Install jq and get an access token for API requests
apt-get install -y jq
OAUTH_TOKEN=$(curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" \
    -H "Metadata-Flavor: Google" --silent | jq -r '.access_token')

# Make a request against the metadata server to determine the project name,
# instance name, and what zone it's running in
ZONE_INFO=$(curl http://metadata.google.internal/computeMetadata/v1/instance/zone \
    -H "Metadata-Flavor: Google" --silent)
PROJECT_NAME=$(curl http://metadata.google.internal/computeMetadata/v1/instance/zone \
    -H "Metadata-Flavor: Google" --silent | awk -v FS="/" '{print $2}')
ZONE_NAME=$(curl http://metadata.google.internal/computeMetadata/v1/instance/zone \
    -H "Metadata-Flavor: Google" --silent | sed 's:.*/::')
INSTANCE_NAME=$(curl http://metadata.google.internal/computeMetadata/v1/instance/name \
    -H "Metadata-Flavor: Google" --silent)

# Get the latest snapshot of the app disk
LATEST_SNAPSHOT=$(curl -X GET -H "Authorization: Bearer $OAUTH_TOKEN" \
    https://compute.googleapis.com/compute/v1/projects/$PROJECT_NAME/global/snapshots \
    --silent | jq -s '.[].items[] | select(.name | contains("disk-$NAME")) | .name' \
    | sort -r | head -n 1 | tr -d '"')

# Create a persistent disk using the latest persistent disk snapshot
curl -X POST -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json; charset=utf-8" \
    https://compute.googleapis.com/compute/v1/$ZONE_INFO/disks \
    --data '{"name":"'$LATEST_SNAPSHOT'-restored","sizeGb":"10","type":"zones/'$ZONE_NAME'/diskTypes/pd-ssd","sourceSnapshot":"https://www.googleapis.com/compute/v1/projects/'$PROJECT_NAME'/global/snapshots/'$LATEST_SNAPSHOT'"}'

# Wait for the persistent disk to be created from the disk snapshot
DISK_STATUS=$(curl -X GET -H "Authorization: Bearer $OAUTH_TOKEN" \
    https://compute.googleapis.com/compute/v1/projects/$PROJECT_NAME/zones/$ZONE_NAME/disks/$LATEST_SNAPSHOT-restored \
    --silent | jq -r .status)

while [ $DISK_STATUS != "READY" ]
do
    sleep 2
    DISK_STATUS=$(curl -X GET -H "Authorization: Bearer $OAUTH_TOKEN" \
        https://compute.googleapis.com/compute/v1/projects/$PROJECT_NAME/zones/$ZONE_NAME/disks/$LATEST_SNAPSHOT-restored \
        --silent | jq -r .status)
done

# Attach the new persistent disk created from the snapshot to the VM
curl -X POST -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json; charset=utf-8" \
    https://compute.googleapis.com/compute/v1/$ZONE_INFO/instances/$INSTANCE_NAME/attachDisk \
    --data '{ "source": "/compute/v1/'$ZONE_INFO'/disks/'$LATEST_SNAPSHOT'-restored"}'

# Wait for the persistent disk to be attached before mounting
ATTACH_STATUS=$(curl -X GET -H "Authorization: Bearer $OAUTH_TOKEN" \
    https://compute.googleapis.com/compute/v1/projects/$PROJECT_NAME/zones/$ZONE_NAME/instances/$INSTANCE_NAME \
    --silent | jq '.disks[] | select(.source | contains("disk-"))')

while [ -z "$ATTACH_STATUS" ]
do
    sleep 2
    ATTACH_STATUS=$(curl -X GET -H "Authorization: Bearer $OAUTH_TOKEN" GET \
        https://compute.googleapis.com/compute/v1/projects/$PROJECT_NAME/zones/$ZONE_NAME/instances/$INSTANCE_NAME \
        --silent | jq '.disks[] | select(.source | contains("disk-"))')
done

# With the disk attached, mount the disk and restart Apache
echo UUID=`blkid -s UUID -o value /dev/sdb` /var/www/example.com ext4 discard,defaults,nofail 0 2 \
    | tee -a /etc/fstab
mount -a
systemctl reload apache2

# Remove jq so it's not left on the VM
apt-get remove -y jq
EOF

Pour appliquer la variable NAME_SUFFIX définie au début du document dans le script de démarrage, par exemple app, utilisez la commande envsubst :
```
export NAME=app
envsubst '$NAME' < "/opt/cloud-init-scripts/app-startup.sh" \
 | sudo sponge "/opt/cloud-init-scripts/app-startup.sh"
```
Quittez la session SSH sur la VM :
```
exit
```
Obtenez l'adresse IP de la VM et utilisez curl pour afficher la page Web de base :
```
curl $(gcloud compute instances describe vm-base-$NAME_SUFFIX \
 --zone $ZONE1 \
 --format="value(networkInterfaces.accessConfigs.[0].natIP)")
```
Le site Web de base est renvoyé, comme illustré dans l'exemple de résultat suivant :
```
<!doctype html>

<html lang=en>
<head>
<meta charset=utf-8>
 <title>HA / DR example</title>
</head>
<body>
 Welcome to a test web server with persistent disk snapshots!
</body>
</html>
```
Cette étape confirme qu'Apache est configuré correctement et que la page est chargée à partir du disque persistant associé. Au cours des étapes suivantes, vous allez créer une image à l'aide de cette VM de base et configurer un modèle d'instance avec un script de démarrage.

Créer une programmation d'instantanés de disque persistant

Pour vous assurer que les VM créées dans le groupe d'instances géré disposent toujours des données les plus récentes du disque persistant, créez une programmation d'instantanés. Cette programmation prend des instantanés automatiques d'un disque persistant à des horaires prédéfinis et détermine la durée de conservation des instantanés. L'image suivante illustre le fonctionnement de ce processus de création d'instantané :

Une règle de ressources est créée. Celle-ci définit une programmation d'instantanés et est associée au disque persistant pour prendre des instantanés réguliers.

Réfléchissez aux besoins de votre application et aux objectifs commerciaux pour déterminer la fréquence de création d'instantanés. Par exemple, un site Web statique nécessite des instantanés moins fréquents qu'une application active écrivant des données sur le disque.

Pour déterminer la meilleure approche pour vos propres applications et la méthode de récupération à utiliser, consultez le Guide de planification de reprise après sinistre.

Dans ce scénario, vous utilisez une programmation d'instantanés pour créer des instantanés de disque persistant standards. Vous définissez cette programmation d'instantanés dans une règle de ressource. Les règles de ressources vous permettent de définir des actions à exécuter et de les associer aux ressources de votre environnement.

Avec cette règle de ressources, vous définissez une programmation pour créer un instantané avec les paramètres suivants :
- Prendre un instantané toutes les 4 heures à partir de 22 h UTC
- Conserver les instantanés pendant 1 jour
Configurez cette programmation selon les besoins de votre environnement tels que l'heure de début et la fréquence à laquelle vous souhaitez créer les instantanés :
```
gcloud compute resource-policies create snapshot-schedule snapshot-schedule-$NAME_SUFFIX \
    --description "Snapshot persistent disk every 4 hours" \
    --max-retention-days 1 \
    --start-time 22:00 \
    --hourly-schedule 4 \
    --region $REGION
```
Pour plus d'informations, découvrez comment utiliser une programmation d'instantanés avec les disques persistants.
Pour utiliser la programmation d'instantanés, associez la règle de ressources à votre disque persistant. Spécifiez le nom de votre disque persistant ainsi que la règle de ressources créée à l'étape précédente :
```
gcloud compute disks add-resource-policies disk-$NAME_SUFFIX \
    --resource-policies snapshot-schedule-$NAME_SUFFIX \
    --zone $ZONE1
```
Vous ne pouvez pas aller au bout de ce document et voir le groupe d'instances géré en action avant la création du premier instantané de disque. Créez manuellement un instantané de disque, puis laissez la programmation d'instantanés de la règle de ressources créer des instantanés supplémentaires tels que vous l'avez défini :
```
gcloud compute disks snapshot disk-$NAME_SUFFIX \
    --zone=$ZONE1 \
    --snapshot-names=disk-$NAME_SUFFIX-$(date "+%Y%m%d%H%M%S")
```

Créer un compte de service

Chaque VM du groupe d'instances géré créé lors des étapes suivantes doit exécuter un script de démarrage. Ce script de démarrage crée un disque persistant à partir d'un instantané, puis l'associe à la VM. Il est recommandé de créer un compte de service ne disposant que des autorisations requises pour effectuer ces opérations sur disque. Il vous faudra ensuite attribuer ce compte de service à la VM.

Créez un compte de service à utiliser avec les VM du groupe d'instances géré :

gcloud iam service-accounts create instance-sa-$NAME_SUFFIX \
    --description="Service account for HA/DR example" \
    --display-name="HA/DR for VM instances"

Créez un rôle personnalisé et attribuez-lui uniquement les autorisations nécessaires pour effectuer les tâches de gestion des disques. Les autorisations suivantes sont requises :

compute.snapshots.list
compute.snapshots.useReadOnly
compute.disks.get
compute.disks.create
compute.instances.get
compute.instances.attachDisk
compute.disks.use

gcloud iam roles create instance_snapshot_management_$NAME_SUFFIX \
    --project=$PROJECT_ID \
    --title="Snapshot management for VM instances" \
    --description="Custom role to allow an instance to create a persistent disk from a snapshot and attach to VM." \
    --permissions=compute.snapshots.list,compute.snapshots.useReadOnly,compute.disks.get,compute.disks.create,compute.instances.get,compute.instances.attachDisk,compute.disks.use \
    --stage=GA

Ajoutez les liaisons de rôles requises pour le nouveau compte de service :

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:instance-sa-$NAME_SUFFIX@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="projects/$PROJECT_ID/roles/instance_snapshot_management_$NAME_SUFFIX"

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:instance-sa-$NAME_SUFFIX@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/iam.serviceAccountUser"

Créer une image de VM et un modèle d'instance

Pour créer des VM identiques qui peuvent être déployées automatiquement sans configuration supplémentaire, vous devez utiliser une image de VM personnalisée. Cette image capture la configuration du système d'exploitation et d'Apache. Chaque VM créée dans le groupe d'instances géré lors des étapes suivantes utilisera cette image.

Avant de pouvoir créer une image, vous devez arrêter la VM :

gcloud compute instances stop vm-base-$NAME_SUFFIX --zone=$ZONE1

Créez une image de la VM de base configurée dans la section précédente :

gcloud compute images create image-$NAME_SUFFIX \
    --source-disk=vm-base-$NAME_SUFFIX \
    --source-disk-zone=$ZONE1 \
    --storage-location=$REGION

Vous utilisez cloud-init pour exécuter le script de démarrage précédent lors du premier démarrage d'une VM dans les groupes d'instances gérés. Un script de démarrage standard appliqué à la VM s'exécute à chaque démarrage de la VM, par exemple si vous la redémarrez après des mises à jour.

Créez un fichier de configuration cloud-init à utiliser avec le modèle d'instance :
```
tee -a cloud-init.yaml >/dev/null <<'EOF'
#cloud-config

runcmd:
 - [ bash, /opt/cloud-init-scripts/app-startup.sh ]
EOF
```

Créez un modèle d'instance qui applique la configuration de cloud-init pour exécuter le script de démarrage qui crée un disque à partir d'un instantané, puis associe et installe le disque sur la VM :

gcloud compute instance-templates create template-$NAME_SUFFIX \
    --machine-type=n1-standard-1 \
    --subnet=projects/$PROJECT_ID/regions/$REGION/subnetworks/subnet-$NAME_SUFFIX-$REGION \
    --tags=http-server \
    --image=image-$NAME_SUFFIX \
    --scopes cloud-platform \
    --service-account="instance-sa-$NAME_SUFFIX@$PROJECT_ID.iam.gserviceaccount.com" \
    --metadata-from-file user-data=cloud-init.yaml

Créer un groupe d'instances géré

Un groupe d'instances géré exécute les VM. Le groupe d'instances géré s'exécute dans une zone définie et surveille l'état des VM. En cas de défaillance et si la VM s'arrête, le groupe d'instances géré tente de recréer une autre VM dans la même zone et crée un disque persistant à partir du dernier instantané. Si l'échec est au niveau de la zone, vous devez effectuer manuellement le basculement à froid et créer un autre groupe d'instances géré dans une zone différente. La même image personnalisée et le même modèle d'instance sont alors utilisés pour configurer automatiquement la VM de la même manière.

Créez une vérification d'état pour surveiller les VM du groupe d'instances géré. Cette vérification d'état garantit que la VM répond sur le port 80. Pour vos propres applications, surveillez les ports adéquats pour vérifier l'état de la VM.
```
gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX --port 80
```

Créez un groupe d'instances géré avec une seule VM. Cette VM unique démarre et crée un disque persistant à partir du dernier instantané, puis l'installe et commence à diffuser le trafic Web.

gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$ZONE1 \
    --base-instance-name=instance-vm-$NAME_SUFFIX \
    --template=template-$NAME_SUFFIX \
    --size=1 \
    --zone=$ZONE1 \
    --health-check=http-basic-check-$NAME_SUFFIX

Créer et configurer un équilibreur de charge

Pour que les utilisateurs puissent accéder à votre site Web, vous devez autoriser le trafic vers les VM exécutées dans le groupe d'instances géré. Vous souhaitez également rediriger automatiquement le trafic vers de nouvelles VM en cas de défaillance d'une zone dans un groupe d'instances géré.

Dans la section suivante, vous allez créer un équilibreur de charge externe avec un service de backend pour le trafic HTTP sur le port 80, utiliser la vérification d'état créée lors des étapes précédentes et effectuer le mappage d'une adresse IP externe vers le service de backend.

Pour en savoir plus, consultez la section Configurer un simple équilibreur de charge HTTP externe.

Créez et configurez l'équilibreur de charge de votre application :

# Configure port rules for HTTP port 80
gcloud compute instance-groups set-named-ports \
    instance-group-$NAME_SUFFIX-$ZONE1 \
    --named-ports http:80 \
    --zone $ZONE1

# Create a backend service and add the managed instance group to it
gcloud compute backend-services create \
    web-backend-service-$NAME_SUFFIX \
    --protocol=HTTP \
    --port-name=http \
    --health-checks=http-basic-check-$NAME_SUFFIX \
    --global

gcloud compute backend-services add-backend \
    web-backend-service-$NAME_SUFFIX \
    --instance-group=instance-group-$NAME_SUFFIX-$ZONE1 \
    --instance-group-zone=$ZONE1 \
    --global

# Create a URL map for the backend service
gcloud compute url-maps create web-map-http-$NAME_SUFFIX \
    --default-service web-backend-service-$NAME_SUFFIX

# Configure forwarding for the HTTP traffic
gcloud compute target-http-proxies create \
    http-lb-proxy-$NAME_SUFFIX \
    --url-map web-map-http-$NAME_SUFFIX

gcloud compute forwarding-rules create \
    http-content-rule-$NAME_SUFFIX \
    --global \
    --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \
    --ports=80

Obtenez l'adresse IP de la règle de transfert pour le trafic Web :

IP_ADDRESS=$(gcloud compute forwarding-rules describe http-content-rule-$NAME_SUFFIX \
    --global \
    --format="value(IPAddress)")

Utilisez curl ou ouvrez votre navigateur Web pour afficher le site Web à l'aide de l'adresse IP de l'équilibreur de charge de l'étape précédente :
```
curl $IP_ADDRESS
```
Quelques minutes sont nécessaires pour que le déploiement de l'équilibreur de charge s'achève et que le trafic soit correctement dirigé vers votre backend. Une erreur HTTP 404 ou 502 est renvoyée si l'équilibreur de charge est toujours en cours de déploiement. Si nécessaire, attendez quelques minutes et réessayez d'accéder au site Web.

Le site Web de base est renvoyé, comme illustré dans l'exemple de résultat suivant :
```
<!doctype html>

<html lang=en>
<head>
<meta charset=utf-8>
 <title>HA / DR example</title>
</head>
<body>
 Welcome to a Compute Engine website with warm failover to Cloud Storage!
</body>
</html>
```

Simuler une défaillance de zone et une récupération

Examinez les déploiements de ressources avant de simuler une défaillance au niveau de la zone. Toutes les ressources ont été créées pour prendre en charge l'environnement suivant :

Une VM s'exécute dans un groupe d'instances géré avec un disque persistant associé qui stocke un site Web de base.
Les instantanés du disque persistant sont régulièrement pris à l'aide d'une programmation d'instantanés via une règle de ressources.
Un script de démarrage est appliqué à un modèle d'instance, de sorte que toutes les VM créées dans le groupe d'instances géré créent un disque persistant à partir du dernier instantané de disque et l'installent.
Une vérification d'état surveille l'état de la VM au sein du groupe d'instances géré.
L'équilibreur de charge d'application externe dirige les utilisateurs vers la VM exécutée dans le groupe d'instances géré.
En cas de défaillance de la VM, le groupe d'instances géré tente de recréer une VM dans la même zone. Si la défaillance est au niveau de la zone, vous devez créer manuellement un groupe d'instances géré de remplacement dans une autre zone de travail.

Dans un environnement de production, vous pouvez recevoir une alerte provenant de Cloud Monitoring ou d'une autre solution de surveillance en cas de problème. Cette alerte invite l'utilisateur à comprendre l'étendue de la défaillance avant de créer manuellement un groupe d'instances géré de remplacement dans une autre zone de travail. Une autre approche consiste à utiliser votre solution de surveillance pour répondre automatiquement aux interruptions avec le groupe d'instances géré.

Lorsque vous ou votre solution de surveillance déterminez que l'action la plus appropriée est un basculement, créez un groupe d'instances géré de remplacement. Dans ce document, vous créez manuellement cette ressource de remplacement.

Pour simuler une défaillance au niveau de la zone, supprimez le backend de l'équilibreur de charge et le groupe d'instances géré :
```
gcloud compute backend-services remove-backend \
    web-backend-service-$NAME_SUFFIX \
    --instance-group=instance-group-$NAME_SUFFIX-$ZONE1 \
    --instance-group-zone=$ZONE1 \
    --global

gcloud compute instance-groups managed delete instance-group-$NAME_SUFFIX-$ZONE1 \
      --zone=$ZONE1
```
Lorsque vous y êtes invité, confirmez la demande de suppression du groupe d'instances géré.

Dans un environnement de production, votre système de surveillance génère une alerte vous invitant à demander une action de basculement à froid.
Utilisez de nouveau curl ou votre navigateur Web pour accéder à l'adresse IP de l'équilibreur de charge :
```
curl $IP_ADDRESS --max-time 5
```
La requête curl échoue, car il n'existe aucune cible opérationnelle pour l'équilibreur de charge.
Pour simuler le basculement à froid, créez un groupe d'instances géré dans une zone différente :
```
gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$ZONE2 \
    --template=template-$NAME_SUFFIX \
    --size=1 \
    --zone=$ZONE2 \
    --health-check=http-basic-check-$NAME_SUFFIX
```
L'image de VM, le modèle d'instance et le disque persistant conservent la configuration de l'instance d'application.

Mettez à jour l'équilibreur de charge pour ajouter le nouveau groupe d'instances géré et la nouvelle VM :

gcloud compute instance-groups set-named-ports \
    instance-group-$NAME_SUFFIX-$ZONE2 \
    --named-ports http:80 \
    --zone $ZONE2

gcloud compute backend-services add-backend \
    web-backend-service-$NAME_SUFFIX \
    --instance-group=instance-group-$NAME_SUFFIX-$ZONE2 \
    --instance-group-zone=$ZONE2 \
    --global

Utilisez à nouveau curl ou votre navigateur Web pour accéder à l'adresse IP de l'équilibreur de charge qui dirige le trafic vers la VM exécutée dans le groupe d'instances géré :
```
curl $IP_ADDRESS
```
La VM a besoin de quelques minutes pour terminer le déploiement et la restauration des données du dernier instantané de disque persistant. Une erreur HTTP 404 ou 502 est renvoyée si la VM est en cours de déploiement et le fichier Apache par défaut s'affiche si les données sont encore en cours de restauration. Si nécessaire, attendez quelques minutes et réessayez d'accéder au site Web.

L'exemple de réponse suivant montre que la page Web s'exécute correctement sur la VM :
```
<!doctype html>
<html lang=en>
<head>
<meta charset=utf-8>
 <title>HA / DR example</title>
</head>
<body>
 Welcome to a test web server with persistent disk snapshots!
</body>
</html>
```

Vérifiez l'état de fonctionnement du groupe d'instances géré :

gcloud compute instance-groups managed list-instances instance-group-$NAME_SUFFIX-$ZONE2 \
    --zone $ZONE2

L'exemple de résultat suivant affiche un état de VM RUNNING et HEALTHY :

NAME             ZONE           STATUS   HEALTH_STATE  ACTION
instance-vm-app  us-central1-f  RUNNING  HEALTHY       NONE

Pour vérifier que le disque persistant installé a été créé à partir d'un instantané, examinez la source. Spécifiez l'instance NAME affichée à l'aide de la commande list-instances précédente.
```
gcloud compute instances describe NAME \
    --zone=$ZONE2 \
    --format="value(disks.[1].source)"
```
L'exemple de sortie suivant montre que le disque persistant s'appelle disk-app-us-central1-a-20210630165529-umopkt17-restored. Le suffixe -restored est ajouté par le script de démarrage au nom du dernier instantané de disque :
```
https://www.googleapis.com/compute/v1/projects/project/zones/us-central1-f/disks/disk-app-us-central1-a-20210630165529-umopkt17-restored
```

Nettoyer

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.

Pour supprimer les ressources individuelles créées dans ce document, procédez comme suit :

Supprimez la configuration de l'équilibreur de charge :

gcloud compute forwarding-rules delete \
    http-content-rule-$NAME_SUFFIX --global --quiet

gcloud compute target-http-proxies delete \
    http-lb-proxy-$NAME_SUFFIX --quiet

gcloud compute url-maps delete web-map-http-$NAME_SUFFIX --quiet

gcloud compute backend-services delete \
    web-backend-service-$NAME_SUFFIX --global --quiet

Supprimez le groupe d'instances géré et la vérification d'état :

gcloud compute instance-groups managed delete instance-group-$NAME_SUFFIX-$ZONE2 \
    --zone=$ZONE2 --quiet

gcloud compute health-checks delete http-basic-check-$NAME_SUFFIX --quiet

Supprimez le modèle d'instance, la configuration de cloud-init, les images, la VM de base, le disque persistant et la programmation d'instantanés.

gcloud compute instance-templates delete template-$NAME_SUFFIX --quiet

rm cloud-init.yaml

gcloud compute images delete image-$NAME_SUFFIX --quiet

gcloud compute instances delete vm-base-$NAME_SUFFIX --zone=$ZONE1 --quiet

gcloud compute disks delete disk-$NAME_SUFFIX --zone=$ZONE1 --quiet

gcloud compute resource-policies delete \
    snapshot-schedule-$NAME_SUFFIX --region $REGION --quiet

Répertoriez ensuite et effacez les instantanés et les disques créés par les instances :

gcloud compute disks list --filter="name:disk-$NAME_SUFFIX" \
    --uri | xargs gcloud compute disks delete

gcloud compute snapshots list --filter="name:disk-$NAME_SUFFIX" \
    --uri | xargs gcloud compute snapshots delete

Supprimez le rôle personnalisé et le compte de service :

gcloud iam roles delete instance_snapshot_management_$NAME_SUFFIX \
  --project=$PROJECT_ID --quiet

gcloud iam service-accounts delete \
    instance-sa-$NAME_SUFFIX@$PROJECT_ID.iam.gserviceaccount.com --quiet

Supprimez les règles de pare-feu :

gcloud compute firewall-rules delete allow-health-check-$NAME_SUFFIX --quiet

gcloud compute firewall-rules delete allow-ssh-$NAME_SUFFIX --quiet

gcloud compute firewall-rules delete allow-http-$NAME_SUFFIX --quiet

Supprimez le sous-réseau et le réseau VPC :

gcloud compute networks subnets delete \
    subnet-$NAME_SUFFIX-$REGION --region=$REGION --quiet

gcloud compute networks delete network-$NAME_SUFFIX --quiet

Étape suivante

Pour savoir comment déterminer la meilleure approche pour vos propres applications et la méthode de récupération à utiliser, consultez le Guide de planification de reprise après sinistre.
Pour découvrir d'autres modèles d'applications, tels que le basculement à froid et à chaud, consultez la section Scénarios de reprise après sinistre pour les applications.
Pour découvrir d'autres façons de gérer l'évolutivité et la disponibilité, consultez la page Modèles d'applications évolutives et résilientes.
Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.