Discipline di archiviazione per le Istanza gestita di SQL abilitate per Azure Arc

L'archiviazione è un componente critico in una distribuzione di Istanza gestita di SQL abilitata per Azure Arc (Istanza gestita di SQL abilitata per Arc). Comprendere in che modo i concetti relativi all'archiviazione descritti in questo documento influiscono sul funzionamento dei cluster Kubernetes è un aspetto importante delle scelte e della gestione della progettazione dell'archiviazione.

Anziché interagire direttamente con l'archiviazione sottostante, Kubernetes fornisce un livello di astrazione a varie tecnologie di archiviazione tramite classi di archiviazione. I provider di servizi cloud, i fornitori di hardware e altre piattaforme gestite da Kubernetes offrono opzioni StorageClass diverse in base a ambienti e scenari di implementazione specifici.

Le Istanza gestita di SQL abilitate per Arc non limitano o applicano l'uso di classi di archiviazione, quindi è importante scegliere la progettazione e la configurazione di archiviazione corrette. La progettazione di archiviazione per le Istanza gestita di SQL abilitate per Arc è importante come se si scegliessero i dispositivi di archiviazione di supporto per un SQL Server in esecuzione in macchine virtuali o bare metal. Queste scelte rappresentano infine i requisiti relativi a RPO, RTO, capacità e prestazioni.

Per le distribuzioni di Istanza gestita di SQL abilitate per Arc, la pianificazione efficace delle funzionalità di archiviazione e della configurazione è fondamentale per il corretto funzionamento. Per altre informazioni sui fattori correlati all'archiviazione da considerare, seguire le indicazioni per la configurazione delle Istanza gestita di SQL abilitate per Arc.

Architettura

Il diagramma dell'architettura seguente illustra la progettazione logica dei componenti dei servizi dati abilitati per Azure Arc. Questi componenti includono un controller di dati di Azure Arc necessario e uno o più Istanza gestita di SQL abilitati per Arc che contengono database di cui è stato effettuato il provisioning per riferimento. Sia il controller di dati di Azure Arc che i Istanza gestita di SQL abilitati per Arc offrono opzioni per il supporto dei dispositivi di archiviazione, che dipendono dai provider di infrastruttura di archiviazione e distribuzione Kubernetes.

Considerazioni relative alla progettazione

Di seguito sono riportate alcune considerazioni per la progettazione e la configurazione dell'archiviazione.

Classi di archiviazione

La scelta della configurazione e della classe di archiviazione Kubernetes appropriata per i componenti dei servizi dati abilitati per Azure Arc è importante per le prestazioni, la resilienza e la capacità di archiviazione dei dati.

StorageClass, PersistentVolume (PV) e PersistentVolumeClaim (PVC) sono oggetti risorsa Kubernetes creati dal sistema nel cluster Kubernetes durante il provisioning dei componenti dei servizi dati abilitati per Azure Arc.

Le opzioni StorageClass variano a seconda del provider di servizi cloud, del fornitore dell'hardware e dell'impostazione configurata dall'amministratore di Kubernetes. PersistentVolumeClaim richiede la creazione di un oggetto PersistentVolume per StorageClass e le dimensioni richieste. Il diagramma seguente è un riferimento alla relazione tra queste risorse Kubernetes e le possibili opzioni per le classi di archiviazione.

Le risorse Kubernetes PV e PVC vengono configurate rispettivamente durante il provisioning del controller di dati di Azure Arc e delle Istanza gestita di SQL abilitate per Arc.

Esistono due tipi di archiviazione diversi tra cui scegliere:

• Locale: Volume montato in un dispositivo di archiviazione locale collegato al nodo Kubernetes in cui è in esecuzione il pod. Questo tipo di archiviazione offre in genere una latenza inferiore, oltre a operazioni di input/output superiori al secondo (IOPS) e velocità effettiva rispetto all'archiviazione remota/condivisa.
• Archiviazione remota/condivisa: Dispositivi di archiviazione collegati alla rete che tendono a essere dotati di ridondanza predefinita. Le opzioni di archiviazione comuni sono dispositivi NAS e SAN.

Quando si sceglie storageClass, considerare gli standard seguenti. Questi criteri sono valide anche per qualsiasi server di database compilato:

• Prestazione: La velocità effettiva di input/output del dispositivo di archiviazione (I/O) e le operazioni di I/O al secondo devono soddisfare le esigenze del database.
• Rapporto lettura/scrittura: Comprendere il carico di lavoro consente di scegliere l'hardware di supporto per soddisfare al meglio le esigenze con i costi appropriati. I carichi di lavoro di scrittura pesanti possono sfruttare le configurazioni RAID 0, mentre i dati a cui si accede raramente potrebbero essere gestiti meglio usando un'archiviazione del dispositivo SAN.
• Isolamento del database e co-posizione: Tutti i database in un'istanza di Istanza gestita di SQL abilitata per Arc condividono pv, quindi è possibile scegliere di spostare i database in istanze separate di Istanza gestita di SQL abilitate per Arc ed evitare conflitti di risorse di archiviazione.
• Capacità: Le dimensioni di archiviazione definite devono soddisfare la capacità futura del controller di dati e delle istanze del database per evitare di dover ridimensionare un PVC. Prendere in considerazione eventuali limitazioni di archiviazione che potrebbero essere state applicate a StorageClass scelto.
• Modalità di accesso: I provider di classi di archiviazione hanno modalità di accesso diverse, supportando diverse funzionalità per la modalità di montaggio e lettura o scrittura da parte dei pod. RWX (Read Write Many) è necessario per il volume di backup SQL.
• Ridondanza: Replica dei dati a livello di archiviazione fisica (RAID) per supportare il failover facile se si verifica un errore del disco hardware, che è separato dalla ridondanza a livello di database eseguita dai gruppi di disponibilità (AG).

Sia il controller di dati di Azure Arc che i servizi dati arc abilitati Istanza gestita di SQL per Arc offrono opzioni granulari per la configurazione di classi di archiviazione diverse per i dati del database. Questi servizi dati forniscono anche log, che consentono di scegliere classi di archiviazione per soddisfare le esigenze.

Titolare del trattamento dei dati

Per un cluster Kubernetes è necessario un singolo controller di dati di Azure Arc come prerequisito per la creazione di istanze di Istanza gestita di SQL abilitate per Arc. Non è supportato più controller di dati in esecuzione in un cluster.

Il controller di dati di Azure Arc avrà quattro pod con stato diversi in esecuzione nel cluster Kubernetes: controller SQL, API controller, database dei log e database delle metriche. Ogni pod richiede due volumi persistenti per i volumi di dati e log. Tutti i componenti del controller di dati richiedono una classe di archiviazione remota per garantire la durabilità dei dati, in quanto i componenti del controller dei dati stessi non garantiscono la durabilità dei dati in modo nativo.

Assicurarsi di prendere in considerazione le risorse di calcolo e memoria richieste dal controller di dati di Azure Arc. Il diagramma seguente rappresenta le risorse kubernetes di archiviazione, pv e PVC del controller dati.

Il ridimensionamento del volume predefinito del controller dati è il minimo consigliato. L'archiviazione usata dipende dal numero di database, dal modo in cui si usano i database e dal numero di log generati. Azure Arc Data Controller StorageClass non è sensibile alla bassa latenza. Anche in questo caso, gli utenti potrebbero riscontrare vantaggi nelle interfacce Grafana e Kibana con risorse di archiviazione con prestazioni più veloci se sono presenti molte distribuzioni di Istanza gestita di SQL abilitate per Arc in un cluster. Grafana e Kibana sono open source strumenti di visualizzazione di monitoraggio distribuiti con il titolare del trattamento dei dati e con provisioning con dashboard per la visualizzazione di metriche e log per le Istanza gestita di SQL abilitate per Arc.

Provisioning del titolare del trattamento dei dati

Quando si effettua il provisioning del controller di dati di Azure Arc, configurare StorageClass e la capacità di archiviazione sia per i log che per i dati. La configurazione dell'archiviazione sia per i log che per i dati si applica quindi a tutti e otto i PC creati per i pod del controller dati. Durante il provisioning, è possibile specificare un modello di distribuzione personalizzato che sostituisce i parametri predefiniti, ad esempio capacità, conservazione dei log e elementi correlati alla sicurezza, ad esempio i tipi di servizio Kubernetes. Al termine del provisioning, vengono creati gli oggetti Kubernetes PV e PVC.

È importante comprendere che StorageClass per il titolare del trattamento dei dati non può essere modificato dopo il provisioning. Se non si specifica storageClass, il controller di dati usa storageClass predefinito di Kubernetes, che può variare a seconda dell'istanza o del provider Kubernetes.

Quando si disinstalla azure Arc Data Controller, tutti i volumi persistenti associati vengono eliminati. Archiviare tutti i log del piano di controllo dei servizi dati abilitati per Azure Arc che l'organizzazione deve salvare prima di disinstallare il titolare del trattamento dei dati.

Istanza gestita di SQL abilitata per Azure Arc

Le Istanza gestita di SQL abilitate per Arc offrono due livelli diversi a seconda dei requisiti aziendali: per utilizzo generico e business critical. Per entrambi i livelli, è importante esaminare i limiti di Istanza gestita di SQL abilitati per Arc minimo e massimo, configurabili e assicurarsi che il cluster Kubernetes distribuito abbia la capacità di calcolo e memoria appropriata.

Negli scenari con più database in una determinata istanza di database, tutti i database usano la stessa classe StorageClass, PVC e PV specificati per il Istanza gestita di SQL abilitato per Arc. È possibile avere più istanze di Istanza gestita di SQL abilitate per Arc in un singolo cluster Kubernetes. Questa configurazione consente volumi persistenti indipendenti e consente di separare la contesa di I/O da database diversi distribuendo i database in istanze diverse di Istanza gestita di SQL abilitate per Arc.

Nella tabella seguente vengono descritti i diversi volumi persistenti usati da ogni pod abilitato per Arc Istanza gestita di SQL e il relativo scopo.

Livello di servizio Utilizzo generico

Il livello per utilizzo generico abilitato per Arc Istanza gestita di SQL deve usare l'archiviazione remota per l'istanza del database in modo che, in caso di errore di un pod, i dati rimangano disponibili per i pod appena creati. Il failover viene gestito dal pod Kubernetes e dall'orchestrazione dei nodi. Questa configurazione è meno complessa rispetto a business critical, che usa gruppi di disponibilità SQL e più repliche di Istanza gestita di SQL abilitate per Arc. La configurazione a pod singolo del livello per utilizzo generico significa che è possibile ridurre al minimo la quantità di spazio di archiviazione perché non è necessario duplicare la capacità di archiviazione per altre repliche.

Livello di servizio business critical

business critical livello usa un modello a più pod in cui i volumi di dati e log possono essere archiviati in classi di archiviazione locali o remote. Le classi di archiviazione locali offrono in genere prestazioni migliori in termini di latenza e velocità effettiva perché il dispositivo di archiviazione è collegato direttamente al nodo. L'archiviazione remota offre in genere ridondanza predefinita, ma spesso presenta una latenza e una velocità effettiva inferiori rispetto all'archiviazione locale. Tenere presente che l'uso di più repliche di database business critical richiede volumi persistenti aggiuntivi per dati, log e datalog. La capacità di archiviazione totale necessaria è molto più elevata.

Il diagramma seguente illustra la configurazione di archiviazione business critical per Arc-Enabled Istanza gestita di SQL con due repliche.

business critical consente di configurare due o tre repliche secondarie. Il failover viene gestito dal gruppo di disponibilità SQL Always On, che fornisce meno tempo di inattività per gli aggiornamenti e gli errori rispetto al livello per utilizzo generico.

La configurazione di più repliche con la replica dei dati in modalità commit sincrono garantisce una migliore protezione da errori, ad esempio un pod, un nodo o un hardware di archiviazione non riuscito. Protegge da errori perché sono presenti più copie dei dati nelle repliche. È consigliabile configurare le repliche secondarie come istanze di scalabilità orizzontale di lettura, a cui i client possono connettersi quando si usa l'endpoint del listener secondario.

Provisioning e disinstallazione di Azure Arc Istanza gestita di SQL

Quando si esegue il provisioning di Istanza gestita di SQL abilitati per Arc, è possibile assegnare classi di archiviazione diverse a ognuna delle Istanza gestita di SQL volumi persistenti abilitati per Arc necessari. È possibile che si vogliano opzioni di archiviazione con prestazioni superiori per Data e DataLogs, ma i volumi log e backup potrebbero usare opzioni StorageClass più efficienti per risparmiare sui costi. Negli scenari in cui si usa l'archiviazione locale, assicurarsi che i volumi siano in grado di atterrare su nodi diversi e dispositivi di archiviazione fisica per evitare contese su disco I/O. L'inserimento dei dati e dei datalog nella stessa unità fisica può causare conflitti per tale unità di archiviazione, causando prestazioni scarse. Prendere invece in considerazione l'inserimento dei dati e dei datalog su unità di archiviazione separate per parallelizzare i/O per i dati e i log del database.

Quando si eliminano Istanza gestita di SQL abilitati per Arc, non vengono rimossi i pc virtuali e i pc virtuali associati. Questo comportamento garantisce che sia possibile accedere ai file di database nel caso in cui l'eliminazione sia stata accidentale.

Suggerimenti per la progettazione

Di seguito sono riportati i consigli per la progettazione e la configurazione dell'archiviazione.

Classi di archiviazione per carichi di lavoro di produzione

Per cloud pubblici specifici, le classi di archiviazione consigliate per i carichi di lavoro di produzione sono visualizzate nella tabella seguente.

Quando si sceglie una classe di archiviazione di produzione in scenari locali o multicloud, assicurarsi che sia in grado di soddisfare le esigenze di capacità di archiviazione previste, operazioni di I/O al secondo, ridondanza e velocità effettiva. Le sezioni seguenti forniscono altre raccomandazioni per questi scenari.

Progettazione del titolare del trattamento dei dati

Scegliere un oggetto StorageClass remoto e condiviso per garantire la durabilità dei dati. Nel caso in cui venga rimosso un pod o un nodo, è possibile ripristinare il backup del pod e connettersi di nuovo al volume persistente. La sottolineatura StorageClass deve fornire ridondanza e disponibilità elevata.

È consigliabile usare un modello di distribuzione personalizzato quando si crea il titolare del trattamento dei dati abilitato per Arc. Un modello personalizzato consente di ottimizzare le classi di archiviazione, le dimensioni di archiviazione per i dati e i log, la sicurezza e i tipi di servizio Kubernetes. È possibile personalizzarli per l'ambiente e le esigenze aziendali. Il titolare del trattamento dei dati di Azure Arc richiede un totale di otto volumi persistenti. La configurazione minima predefinita consente 15Gi per i dati e 10Gi per i log nei PV. Configurare la capacità che non soddisfa solo le raccomandazioni minime, ma supporta una maggiore crescita dalla presenza di numerose implementazioni di Istanza gestita di SQL abilitate per Arc in esecuzione in un cluster. Questa configurazione impedirà la necessità di ridimensionare le schede pvc in futuro.

È consigliabile scegliere un oggetto StorageClass a bassa latenza nel caso in cui il cluster disponga di molti database e distribuzioni di Istanza gestita di SQL abilitate per Arc. La latenza inferiore migliora l'esperienza utente nelle interfacce Grafana e Kibana.

Migrazione Istanza gestita di SQL abilitata per Azure Arc

È consigliabile pianificare e tenere conto di tutti i database nuovi e esistenti coinvolti nella migrazione e nella distribuzione dell'Istanza gestita di SQL abilitata per Arc. La pianificazione impedisce la necessità di spostare i database tra istanze in un secondo momento.

A seconda dell'organizzazione del cluster Kubernetes, effettuare il provisioning di distribuzioni di Istanza gestita di SQL abilitate per Arc in cluster Kubernetes diversi in base alla necessità di separare gli ambienti (non prod, prod), aree e altri fattori aziendali. Esaminare l'area progettazione dell'organizzazione delle risorse per altre raccomandazioni. Quando si configurano più istanze di database in un cluster, assicurarsi di separare i database occupati nella propria istanza per evitare conflitti di I/O.

Usare le etichette dei nodi per assicurarsi che le istanze del database vengano inserite in nodi separati per distribuire il traffico di I/O complessivo tra più nodi, vedere Etichette del nodo Kubernetes insieme all'affinità del nodo Kubernetes e alle etichette anti-affinità per la configurazione delle etichette. Se si opera in un ambiente virtualizzato, assicurarsi che l'I/O sia distribuito in modo appropriato a livello di host fisico.

Pianificare la capacità di Istanza gestita di SQL abilitata per Arc per includere dimensioni di archiviazione adeguate per Dati, Log, DataLogs e Backup. Quando si pianifica la capacità di soddisfare sia le esigenze correnti che la crescita proiettata per tutti i database che saranno in tempo reale sulle istanze di Istanza gestita di SQL abilitate per Arc, impedisce di dover ridimensionare le schede virtuali in futuro. Scegliere unità fisiche separate per Data e DataLogs per consentire l'esecuzione di attività di I/O parallele. L'attività di I/O parallela comporta prestazioni migliorate evitando la possibile contesa causata quando si usa un'unità condivisa.

Sebbene siano presenti diversi fattori che potrebbero determinare una distribuzione del livello di business critical o di per utilizzo generico livello di Istanza gestita di SQL abilitato per Arc, business critical usando l'archiviazione locale offre la latenza più bassa e la massima disponibilità. Esaminare l'area Istanza gestita di SQL di progettazione di continuità aziendale abilitata per Arc per le raccomandazioni relative al ripristino temporizzato, alla disponibilità elevata e al ripristino di emergenza. Esaminare inoltre l'area di progettazione della governance dei costi abilitata per Arc Istanza gestita di SQL per altre informazioni sulle implicazioni sui costi tra livelli.

Le sottosezioni seguenti forniscono raccomandazioni più specifiche per ogni livello:

raccomandazioni per utilizzo generico livello di servizio

È consigliabile scegliere una classe di archiviazione remota a bassa latenza per i volumipersistenti Data e DataLogs per prestazioni ottimali. Evitare l'uso di storageClass che introduce partizioni di rete, ad esempio la configurazione di un cluster locale per l'uso di StorageClass fornito da Internet per i volumi persistenti di backup e log .

raccomandazioni business critical livello di servizio

È consigliabile esaminare le differenze della modalità di disponibilità, che richiederanno una configurazione diversa per ogni modalità scelta.

Per gli scenari di requisiti di latenza più bassi possibile, scegliere archiviazione locale se è un'opzione per l'infrastruttura Kubernetes. I volumi di archiviazione locali devono essere terreni su dispositivi di archiviazione sottostanti diversi per evitare conflitti su disco I/O e ottimizzare le prestazioni. Il dispositivo di archiviazione non deve avere più funzioni, ad esempio l'hosting della partizione del sistema operativo.

Per carichi di lavoro a elevato utilizzo di lettura e disponibilità elevata, configurare più repliche e configurare le applicazioni o i client per usare repliche secondarie come istanze di lettura Scale-Out. Le repliche secondarie non sono leggibili per impostazione predefinita; è possibile configurare l'impostazione.

Monitoraggio

È consigliabile monitorare tutte le schede virtuali create dai servizi dati abilitati per Arc, tra cui il titolare del trattamento dati di Azure Arc e tutte le istanze di Istanza gestita di SQL abilitate per Arc in un cluster. Impostare avvisi per notificare quando un PVC si avvicina alla capacità. La notifica consente di ridimensionare il PVC prima di raggiungere la capacità. Per i cluster connessi direttamente, il monitoraggio delle schede virtuali e l'avviso sono eseguiti da Monitoraggio di Azure e Informazioni dettagliate sui contenitori. Quando si usano cluster connessi indiretti, eseguire il monitoraggio e l'avviso in Grafana e Kibana. L'installazione di Grafana include dashboard per le metriche di Istanza gestita di SQL abilitate per Arc e le risorse Kubernetes.

Esaminare le discipline di governance abilitate per Arc per Istanza gestita di SQL per altre raccomandazioni sul monitoraggio delle Istanza gestita di SQL abilitate per Arc.

Passaggi successivi

Per altre informazioni sul percorso cloud ibrido e multicloud, vedere gli articoli seguenti:

• Esaminare la configurazione di archiviazione per i servizi dati abilitati per Azure Arc.
• Esaminare le distribuzioni kubernetes convalidate per i servizi dati abilitati per Azure Arc.
• Esaminare le linee guida per il ridimensionamento dei servizi dati abilitati per Azure Arc.
• Esaminare il monitoraggio con Grafana e Kibana di un Istanza gestita di SQL abilitato per Arc.
• Esperienza di Istanza gestita di SQL scenari automatizzati abilitati per Arc con Azure Arc Jumpstart.
• Per altre informazioni su Azure Arc, vedere il percorso di apprendimento di Azure Arc in Microsoft Learn.