Distribuire applicazioni in cluster in SAN elastico di Azure
I volumi SAN di Elastic in Azure possono essere collegati simultaneamente a più client di calcolo, consentendo di distribuire o eseguire la migrazione di applicazioni cluster in Azure. È necessario usare un gestore cluster per condividere un volume SAN di Elastic, ad esempio Windows Server Failover Cluster (WSFC) o Pacemaker. Gestione cluster gestisce le comunicazioni dei nodi del cluster e il blocco di scrittura. SAN di Elastic non offre in modo nativo un file system completamente gestito accessibile tramite SMB o NFS.
Se usato come volume condiviso, i volumi SAN di Elastic possono essere condivisi tra zone o aree di disponibilità. La condivisione di un volume in una SAN di archiviazione con ridondanza locale tra più zone riduce le prestazioni a causa di una maggiore latenza tra il volume e i client.
Limiti
- Gli script di connessione SAN di Elastic possono essere usati per collegare volumi condivisi alle macchine virtuali nei set di scalabilità di macchine virtuali o nelle macchine virtuali nei set di disponibilità. L'allineamento del dominio di errore non è supportato.
- Il numero massimo di sessioni supportate da un volume condiviso è 128.
- Un singolo client può creare più sessioni in un singolo volume per migliorare le prestazioni. Ad esempio, se si creano 32 sessioni in ognuno dei client, solo quattro client possono connettersi a un singolo volume.
Vedere Supporto per le funzionalità di Archiviazione di Azure per altre limitazioni della SAN di Elastic.
Funzionamento
I volumi condivisi SAN di Elastic usano prenotazioni permanenti SCSI-3 per consentire agli iniziatori (client) di controllare l'accesso a un volume SAN di Elastic condiviso. Questo protocollo consente a un iniziatore di riservare l'accesso a un volume SAN di Elastic, limitare l'accesso in scrittura (o in lettura) da altri iniziatori e rendere persistente la prenotazione in un volume oltre la durata di una sessione per impostazione predefinita.
La richiesta pull SCSI-3 ha un ruolo fondamentale nella gestione della coerenza e dell'integrità dei dati all'interno dei volumi condivisi negli scenari del cluster. I nodi di calcolo in un cluster possono leggere o scrivere nei volumi SAN di Elastici collegati in base alla prenotazione scelta dalle applicazioni cluster.
Flusso di prenotazione permanente
Il diagramma seguente illustra un esempio di applicazione di database in cluster a 2 nodi che usa la richiesta pull SCSI-3 per abilitare il failover da un nodo all'altro.
Il flusso è il seguente:
- L'applicazione in cluster in esecuzione sia nella macchina virtuale Azure VM1 che in VM2 registra il proprio intento di lettura o scrittura sul volume SAN di Elastic.
- L'istanza dell'applicazione in VM1 effettua quindi la prenotazione esclusiva per scrivere sul volume.
- Questa prenotazione viene applicata sul volume e il database può ora scrivere in modo esclusivo sul volume. Eventuali scritture dall'istanza dell'applicazione in VM2 non avranno esito positivo.
- Se l'istanza dell'applicazione in VM1 diventa inattiva, l'istanza in VM2 può avviare un failover del database e assumere il controllo del volume.
- Questa prenotazione viene ora applicata al volume e non accetterà le scritture da VM1, ma solo da VM2.
- L'applicazione in cluster può completare il failover del database e gestire le richieste da VM2.
Il diagramma seguente illustra un altro carico di lavoro in cluster comune costituito da più nodi che leggono dati dal volume SAN di Elastic per l'esecuzione di processi paralleli, ad esempio il training di modelli di Machine Learning.
Il flusso è il seguente:
- L'applicazione in cluster in esecuzione su tutte le macchine virtuali registra il proprio intento di lettura o scrittura sul volume SAN di Elastic.
- L'istanza dell'applicazione in VM1 effettua una prenotazione esclusiva per scrivere sul volume aprendo le letture sul volume da altre macchine virtuali.
- Questa prenotazione viene applicata sul volume.
- Tutti i nodi del cluster possono ora leggere dal volume. Solo un nodo riscrive i risultati sul volume, per conto di tutti i nodi del cluster.
Comandi di richiesta pull SCSI supportati
Con i volumi SAN di Elastic sono supportati i comandi seguenti:
Per interagire con il volume, iniziare con l'azione di prenotazione permanente appropriata:
- PR_REGISTER_KEY
- PR_REGISTER_AND_IGNORE
- PR_GET_CONFIGURATION
- PR_RESERVE
- PR_PREEMPT_RESERVATION
- PR_CLEAR_RESERVATION
- PR_RELEASE_RESERVATION
Quando si usano PR_RESERVE, PR_PREEMPT_RESERVATION o PR_RELEASE_RESERVATION, specificare uno dei tipi di prenotazione permanenti seguenti:
- PR_NONE
- PR_WRITE_EXCLUSIVE
- PR_EXCLUSIVE_ACCESS
- PR_WRITE_EXCLUSIVE_REGISTRANTS_ONLY
- PR_EXCLUSIVE_ACCESS_REGISTRANTS_ONLY
- PR_WRITE_EXCLUSIVE_ALL_REGISTRANTS
- PR_EXCLUSIVE_ACCESS_ALL_REGISTRANTS
Il tipo di prenotazione persistente determina l'accesso al volume da ogni nodo del cluster.
Tipo di prenotazione permanente | Titolare prenotazione | Registrato | Altri |
---|---|---|---|
NO RESERVATION | N/D | Lettura/Scrittura | Lettura/Scrittura |
WRITE EXCLUSIVE | Lettura/Scrittura | Read-Only | Read-Only |
EXCLUSIVE ACCESS | Lettura/Scrittura | Nessun accesso | Nessun accesso |
WRITE EXCLUSIVE - REGISTRANTS ONLY | Lettura/Scrittura | Lettura/Scrittura | Read-Only |
EXCLUSIVE ACCESS - REGISTRANTS ONLY | Lettura/Scrittura | Lettura/Scrittura | Nessun accesso |
WRITE EXCLUSIVE - ALL REGISTRANTS | Lettura/Scrittura | Lettura/Scrittura | Read-Only |
EXCLUSIVE ACCESS - ALL REGISTRANTS | Lettura/Scrittura | Lettura/Scrittura | Nessun accesso |
È anche necessario fornire una chiave di prenotazione permanente quando si usa:
- PR_RESERVE
- PR_REGISTER_AND_IGNORE
- PR_REGISTER_KEY
- PR_PREEMPT_RESERVATION
- PR_CLEAR_RESERVATION
- PR_RELEASE-RESERVATION.