En este documento, se describe cómo se puede acceder a los discos persistentes desde las instancias de máquina virtual (VM) y el proceso de replicación de los discos persistentes. También describe la infraestructura central de los discos persistentes. Este documento está dirigido a los arquitectos y ingenieros de Google Cloud que deseen usar discos persistentes en sus sistemas.
Los discos persistentes no son discos locales conectados a las máquinas físicas, sino servicios de herramientas de redes conectados a las VM como dispositivos de bloqueo de red. Cuando lees o escribes desde un disco persistente, los datos se transmiten a través de la red. Los discos persistentes son dispositivos de almacenamiento de red, pero habilitan muchos casos prácticos y funcionalidades en términos de capacidad, flexibilidad y confiabilidad, los que los discos convencionales no pueden proporcionar.
Discos persistentes y Colossus
Los discos persistentes están diseñados para ejecutarse en conjunto con el sistema de archivos de Google, Colossus, que es un sistema de almacenamiento de bloques distribuido. Los controladores de discos persistentes encriptan los datos de la VM de forma automática antes de que se transmitan a la red. Luego, Colossus conserva los datos. Cuando Colossus lee los datos, el controlador los desencripta.
Los discos persistentes usan Colossus para el backend de almacenamiento.
Tener discos como servicio es útil en varios casos, por ejemplo:
- Cambiar el tamaño de los discos mientras se ejecuta la VM se vuelve más fácil que detener la VM primero. Puedes aumentar el tamaño del disco sin detener la VM.
- Conectar y desconectar discos es más fácil cuando los discos y las VM no tienen que compartir el mismo ciclo de vida ni ubicarse en el mismo lugar. Es posible detener una VM y usar su disco de arranque persistente para iniciar otra VM.
- Las funciones de alta disponibilidad, como la replicación, se vuelven más fáciles porque el controlador del disco puede ocultar los detalles de la replicación y proporcionar replicación automática durante la escritura.
Latencia del disco
Existen varias herramientas de comparativas que puedes usar para supervisar la latencia de sobrecarga del uso de discos como un servicio de herramientas de redes. En el siguiente ejemplo, se usa la interfaz del disco SCSI y no de la interfaz de NVMe, y se muestra el resultado de la VM haciendo algunas lecturas de 4 bloques de KiB de un disco persistente. En el siguiente ejemplo, se muestra un ejemplo de la latencia que ves en las lecturas:
$ 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 también permite conectar SSD locales a máquinas virtuales en casos en los que necesitas que el proceso sea lo más rápido posible. Cuando ejecutas un servidor de caché o trabajos de procesamiento de datos grandes donde hay una salida intermedia, te recomendamos que elijas SSD locales. A diferencia de los discos persistentes, los datos en SSD locales no son persistentes y, como resultado, la VM borra los datos cada vez que se reinicia la máquina virtual. Los SSD locales solo son adecuados para casos de optimización.
El siguiente resultado es un ejemplo de la latencia que ves con 4 KiB de lecturas de un SSD local mediante la interfaz de disco 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
Replicación
Cuando creas un disco persistente nuevo, puedes crear el disco en una zona o replicarlo en dos zonas dentro de la misma región.
Por ejemplo, si creas un disco en una zona, como en us-west1-a, tendrás una copia del disco. Estos se denominan discos zonales.
Puedes aumentar la disponibilidad del disco si almacenas otra copia del disco en una zona diferente dentro de la región, como en us-west1-b.
Los discos replicados en dos zonas de la misma región se denominan discos persistentes regionales.
Es poco probable que una región falle por completo, pero pueden ocurrir fallas zonales. Replicar dentro de la región en diferentes zonas, como se muestra en la siguiente imagen, ayuda con la disponibilidad y reduce la latencia del disco. Si fallan ambas zonas de replicación, se considera una falla en toda la región.
El disco se replica en dos zonas.
En la situación replicada, los datos están disponibles en la zona local (us-west1-a), que es la zona en la que se está ejecutando la máquina virtual. Luego, los datos se replican en otra instancia de Colossus en otra zona (us-west1-b). Al menos una de las zonas debe ser la misma en la que se ejecuta la VM.
Ten en cuenta que la replicación del disco persistente es solo para la alta disponibilidad de los discos. Las interrupciones zonales también pueden afectar las máquinas virtuales o cualquier otro componente, que también pueden causar interrupciones.
Secuencias de lectura y escritura
Para determinar las secuencias de lectura y escritura, o el orden en el que se leen y escriben los datos en el disco, el controlador de disco de tu VM realiza la mayor parte del trabajo. Como usuario, no tienes que lidiar con la semántica de replicación y puedes interactuar con el sistema de archivos como de costumbre. El controlador subyacente controla la secuencia para lectura y escritura.
De forma predeterminada, el sistema opera en modo de replicación completa, en el que las solicitudes para leer o escribir desde el disco se envían a ambas réplicas.
En el modo de replicación completa, ocurre lo siguiente:
- Cuando se escribe, una solicitud de escritura intenta escribir en ambas réplicas y confirma cuando ambas operaciones de escritura se realizan correctamente.
- Cuando se realiza la lectura, la VM envía una solicitud de lectura a ambas réplicas y muestra los resultados de la que se ejecuta de forma correcta. Si se agota el tiempo de espera de la solicitud de lectura, se envía otra solicitud de lectura.
Si una réplica se retrasa y falla en confirmar que las solicitudes de lectura o escritura se completaron, entonces las lecturas y escrituras ya no se envían a la réplica. La réplica debe pasar por un proceso de conciliación para volver a un estado actual antes de que la replicación pueda continuar.
¿Qué sigue?
- Aprende a configurar discos para cumplir con los requisitos de rendimiento.
- Consulta Prácticas recomendadas para las instantáneas de discos persistentes.