Ce document explique comment accéder aux disques persistants à partir d'instances de machines virtuelles (VM) et le processus de réplication des disques persistants. Il décrit également l'infrastructure principale des disques persistants. Ce document est destiné aux ingénieurs et architectes Google Cloud qui souhaitent utiliser des disques persistants dans leurs systèmes.
Les disques persistants ne sont pas des disques locaux rattachés aux machines physiques, mais plutôt des services réseau associés aux VM en tant qu'appareils de stockage réseau en mode bloc. Lorsque vous lisez ou écrivez à partir d'un disque persistant, les données sont transmises sur le réseau. Les disques persistants sont un périphérique de stockage réseau, mais ils permettent de nombreux cas d'utilisation et fonctionnalités en termes de capacité, de flexibilité et de fiabilité que les disques conventionnels ne peuvent pas fournir.
Disques persistants et Colossus
Les disques persistants sont conçus pour être exécutés en tandem avec le système de fichiers Google, Colossus, qui est un système de stockage de blocs distribué. Les pilotes de disque persistant chiffrent automatiquement les données sur la VM avant qu'elles ne soient transmises depuis la VM sur le réseau. Ensuite, Colossus conserve les données. Lorsque Colossus lit les données, le pilote déchiffre les données entrantes.
Les disques persistants utilisent Colossus pour le backend de stockage.
L'utilisation de disques en tant que service est utile dans de nombreux cas, par exemple :
- Il est plus facile de redimensionner les disques pendant que la VM est en cours d'exécution que d'arrêter d'abord la VM. Vous pouvez augmenter la taille du disque sans arrêter la VM.
- Il est plus facile d'associer et de dissocier des disques lorsque les disques et les VM n'ont pas besoin de partager le même cycle de vie ou n'ont pas besoin d'être colocalisés. Il est possible d'arrêter une VM et d'utiliser son disque de démarrage persistant pour démarrer une autre VM.
- Les fonctionnalités de haute disponibilité telles que la réplication sont simplifiées, car le pilote de disque peut masquer les détails de la réplication et fournir une réplication automatique au moment de l'écriture.
Latence du disque
Vous pouvez utiliser différents outils d'analyse comparative pour surveiller les latences excessives dues à l'utilisation des disques en tant que service de mise en réseau. L'exemple suivant utilise l'interface de disque SCSI, et non l'interface NVMe, et montre la sortie de la VM effectuant quelques lectures de blocs de 4 Kio à partir d'un disque persistant. Voici un exemple de latence que vous voyez dans les lectures :
$ ioping -c 5 /dev/sda1
4 KiB <<< /dev/sda1 (block device 10.00 GiB): time=293.7 us (warmup)
4 KiB <<< /dev/sda1 (block device 10.00 GiB): time=330.0 us
4 KiB <<< /dev/sda1 (block device 10.00 GiB): time=278.1 us
4 KiB <<< /dev/sda1 (block device 10.00 GiB): time=307.7 us
4 KiB <<< /dev/sda1 (block device 10.00 GiB): time=310.1 us
--- /dev/sda1 (block device 10.00 GiB) ioping statistics ---
4 requests completed in 1.23 ms, 16 KiB read, 3.26 k iops, 12.7 MiB/s
generated 5 requests in 4.00 s, 20 KiB, 1 iops, 5.00 KiB/s
min/avg/max/mdev = 278.1 us / 306.5 us / 330.0 us / 18.6 us
Compute Engine vous permet également d'associer des disques SSD locaux aux machines virtuelles lorsque vous souhaitez que le processus soit aussi rapide que possible. Lorsque vous exécutez un serveur de cache ou des tâches de traitement de données volumineuses nécessitant une sortie intermédiaire, nous vous recommandons de choisir des disques SSD locaux. Contrairement aux disques persistants, les données stockées sur des disques SSD locaux ne sont pas persistantes. Par conséquent, la VM efface les données à chaque redémarrage de la machine virtuelle. Les SSD locaux ne conviennent que pour les cas d'optimisation.
Le résultat suivant est un exemple de latence que vous voyez avec des lectures de 4 Kio à partir d'un disque SSD local à l'aide de l'interface de disque NVMe :
$ ioping -c 5 /dev/nvme0n1
4 KiB <<< /dev/nvme0n1 (block device 375 GiB): time=245.3 us(warmup)
4 KiB <<< /dev/nvme0n1 (block device 375 GiB): time=252.3 us
4 KiB <<< /dev/nvme0n1 (block device 375 GiB): time=244.8 us
4 KiB <<< /dev/nvme0n1 (block device 375 GiB): time=289.5 us
4 KiB <<< /dev/nvme0n1 (block device 375 GiB): time=219.9 us
--- /dev/nvme0n1 (block device 375 GiB) ioping statistics ---
4 requests completed in 1.01 ms, 16 KiB read, 3.97 k iops, 15.5 MiB/s
generated 5 requests in 4.00 s, 20 KiB, 1 iops, 5.00 KiB/s
min/avg/max/mdev = 219.9 us / 251.6 us / 289.5 us / 25.0 us
Réplication
Lorsque vous créez un disque persistant, vous pouvez soit le créer dans une zone, soit le répliquer dans deux zones d'une même région.
Par exemple, si vous créez un disque dans une zone, telle que us-west1-a, vous disposez d'une copie du disque. Ces disques sont appelés "disques zonaux".
Vous pouvez augmenter la disponibilité du disque en stockant une autre copie du disque dans une zone différente de la région, telle que us-west1-b.
Les disques répliqués sur deux zones de la même région sont appelés disques persistants régionaux.
Il est peu probable qu'une région soit totalement défaillante, mais des défaillances de zone peuvent se produire. La réplication dans la région sur différentes zones, comme illustré dans l'image suivante, permet de gagner en disponibilité et de réduire la latence des disques. Si les deux zones de réplication sont défaillantes, cela est considéré comme une défaillance à l'échelle de la région.
Le disque est répliqué dans deux zones.
Dans le scénario répliqué, les données sont disponibles dans la zone locale (us-west1-a), qui est la zone dans laquelle la machine virtuelle s'exécute. Ensuite, les données sont répliquées sur une autre instance Colossus dans une autre zone (us-west1-b). Au moins une des zones doit être la même que celle dans laquelle la VM s'exécute.
Notez que la réplication des disques persistants ne sert qu'à assurer la haute disponibilité des disques. Des pannes zonales peuvent également affecter les machines virtuelles ou d'autres composants, ce qui peut également entraîner des pannes.
Séquences lecture/écriture
Pour déterminer les séquences de lecture/écriture, ou l'ordre dans lequel les données sont lues et écrites sur le disque, la majeure partie du travail est effectuée par le pilote de disque de votre VM. En tant qu'utilisateur, vous n'avez pas à vous soucier de la sémantique de réplication et vous pouvez interagir avec le système de fichiers comme d'habitude. Le pilote sous-jacent gère la séquence de lecture et d'écriture.
Par défaut, le système fonctionne en mode de réplication complète, dans lequel les requêtes de lecture ou d'écriture depuis le disque sont envoyées aux deux instances répliquées.
En mode de réplication complète, voici ce qui se produit :
- Lors de l'écriture, une requête d'écriture tente d'écrire sur les deux instances répliquées et renvoie une confirmation lorsque les deux écritures réussissent.
- Lors de la lecture, la VM envoie une requête de lecture aux deux instances répliquées et renvoie les résultats de celle qui a réussi. Si la requête de lecture expire, une autre requête de lecture est envoyée.
Si une instance répliquée prend du retard et ne parvient pas à confirmer que les requêtes de lecture ou d'écriture ont abouti, les lectures et les écritures ne sont plus envoyées à l'instance répliquée. L'instance répliquée doit passer par un processus de rapprochement pour revenir à un état actuel avant que la réplication ne puisse se poursuivre.
Étapes suivantes
- Découvrez comment configurer les disques pour répondre aux exigences de performances.
- Consultez les bonnes pratiques pour les instantanés de disques persistants.