Questo documento descrive l'accesso ai dischi permanenti dalle istanze di macchine virtuali (VM) e il processo di replica dei disco permanente. Descrive inoltre l'infrastruttura di base dei dischi permanenti. Questo documento è destinato agli ingegneri e agli architect di Google Cloud che vogliono utilizzare dischi permanenti nei loro sistemi.
I dischi permanenti non sono dischi locali collegati alle macchine fisiche, ma piuttosto servizi di networking collegati alle VM come dispositivi a blocchi di rete. Quando leggi o scrivi da un disco permanente, i dati vengono trasmessi attraverso la rete. I dischi permanenti sono un dispositivo di archiviazione di rete, ma consentono molti casi d'uso e funzionalità in termini di capacità, flessibilità e affidabilità, cosa che i dischi convenzionali non sono in grado di fornire.
Dischi permanenti e Colossus
I dischi permanenti sono progettati per essere eseguiti insieme al file system di Google, Colossus, un sistema di archiviazione a blocchi distribuito. I driver di dischi permanenti criptano automaticamente i dati sulla VM prima che vengano trasmessi dalla VM alla rete. Quindi, Colossus conserva i dati. Quando Colossus legge i dati, il driver decripta quelli in entrata.
I dischi permanenti utilizzano Colossus per il backend di archiviazione.
Avere dischi come servizio è utile in diversi casi, ad esempio:
- Il ridimensionamento dei dischi mentre la VM è in esecuzione diventa più semplice rispetto all'arresto della VM. Puoi aumentare le dimensioni del disco senza arrestare la VM.
- Collegare e scollegare i dischi diventa più semplice quando i dischi e le VM non devono condividere lo stesso ciclo di vita o essere collocati insieme. È possibile arrestare una VM e utilizzare il relativo disco di avvio permanente per avviare un'altra VM.
- Le funzionalità ad alta disponibilità come la replica diventano più semplici perché il driver del disco può nascondere i dettagli della replica e fornire la replica automatica in tempo di scrittura.
Latenza disco
Esistono vari strumenti di benchmarking che puoi utilizzare per monitorare la latenza overhead derivante dall'uso dei dischi come servizio di networking. L'esempio seguente utilizza l'interfaccia del disco SCSI e non l'interfaccia NVMe e mostra l'output della VM che esegue alcune letture di blocchi da 4 KiB da un disco permanente. Di seguito è riportato un esempio della latenza che vedi nelle letture:
$ 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 consente inoltre di collegare SSD locali alle macchine virtuali nei casi in cui hai bisogno che il processo sia il più veloce possibile. Quando esegui un server di cache o job di elaborazione dati di grandi dimensioni con un output intermedio, ti consigliamo di scegliere SSD locali. A differenza dei dischi permanenti, i dati sugli SSD locali non sono permanenti e, di conseguenza, la VM cancella i dati a ogni riavvio della macchina virtuale. Le unità SSD locali sono adatte solo per casi di ottimizzazione.
L'output seguente è un esempio della latenza che vedi con letture di 4 KiB da un SSD locale utilizzando l'interfaccia del 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
Replica
Quando crei un nuovo Persistent Disk, puoi creare il disco in una zona o replicarlo in due zone all'interno della stessa regione.
Ad esempio, se crei un disco in una zona, come in us-west1-a, avrai una copia del disco. Questi sono indicati come dischi a livello di zona.
Puoi aumentare la disponibilità del disco archiviando un'altra copia del disco in una zona diversa all'interno della regione, ad esempio in us-west1-b.
I dischi replicati in due zone nella stessa regione sono denominati dischi permanenti a livello di regione.
È improbabile che l'errore si verifichi completamente in una regione, ma possono verificarsi errori a livello di zona. La replica all'interno della regione in zone diverse, come mostrato nell'immagine seguente, favorisce la disponibilità e riduce la latenza del disco. Un errore in entrambe le zone di replica viene considerato a livello di regione.
Il disco viene replicato in due zone.
Nello scenario replicato, i dati sono disponibili nella zona locale (us-west1-a), che è la zona in cui viene eseguita la macchina virtuale. Quindi, i dati vengono replicati in un'altra istanza di Colossus in un'altra zona (us-west1-b). Almeno una delle zone deve trovarsi nella stessa zona in cui è in esecuzione la VM.
Tieni presente che la replica di un disco permanente è solo per l'alta disponibilità dei dischi. Le interruzioni di zona potrebbero influire anche sulle macchine virtuali o su altri componenti, causando anch'essi delle interruzioni.
Sequenze di lettura/scrittura
Nel determinare le sequenze di lettura/scrittura, o l'ordine in cui i dati vengono letti e scritti su disco, la maggior parte del lavoro viene svolta dal driver del disco nella tua VM. Gli utenti non hanno a che fare con la semantica della replica e possono interagire con il file system come di consueto. Il driver sottostante gestisce la sequenza per la lettura e la scrittura.
Per impostazione predefinita, il sistema funziona in modalità di replica completa, in cui le richieste di lettura o scrittura dal disco vengono inviate a entrambe le repliche.
In modalità di replica completa, si verifica quanto segue:
- Durante la scrittura, una richiesta di scrittura tenta di scrivere su entrambe le repliche e conferma quando entrambe le scritture hanno esito positivo.
- Durante la lettura, la VM invia una richiesta di lettura a entrambe le repliche e restituisce i risultati da quella riuscita. Se la richiesta di lettura scade, viene inviata un'altra richiesta di lettura.
Se una replica non riesce a confermare il completamento delle richieste di lettura o scrittura, le operazioni di lettura e scrittura non vengono più inviate alla replica. Per poter continuare la replica, la replica deve essere sottoposta a un processo di riconciliazione per restituirla a uno stato attuale.
Passaggi successivi
- Scopri come configurare i dischi per soddisfare i requisiti delle prestazioni.
- Consulta le best practice per disco permanente permanenti.