Opslagdisciplines voor SQL Managed Instance met Azure Arc

Opslag is een essentieel onderdeel in een implementatie met Azure Arc SQL Managed Instance (Arc-enabled SQL Managed Instance). Inzicht in de invloed van de opslagconcepten die in dit document worden beschreven op de werking van Kubernetes-clusters is een belangrijk aspect van de keuzen en het beheer van opslagontwerpen.

In plaats van rechtstreeks te communiceren met onderliggende opslag, biedt Kubernetes een abstractielaag voor verschillende opslagtechnologieën via opslagklassen. Cloudproviders, hardwareleveranciers en andere door Kubernetes beheerde platforms bieden verschillende StorageClass-opties voor specifieke omgevingen en implementatiescenario's.

Arc-SQL Managed Instance beperkt of dwingt het gebruik van opslagklassen niet af, dus het is belangrijk om het juiste opslagontwerp en de juiste configuratie te kiezen. Het opslagontwerp voor SQL Managed Instance met Arc is net zo belangrijk als wanneer u de back-upopslagapparaten kiest voor een SQL Server wanneer u op bare-metal- of virtuele machines wordt uitgevoerd. Deze keuzes vertegenwoordigen uiteindelijk uw vereisten met betrekking tot RPO, RTO, capaciteit en prestaties.

Voor implementaties van arc-SQL Managed Instance is het van cruciaal belang om de opslagmogelijkheden en configuratie effectief te plannen om succesvol te kunnen werken. Lees verder voor meer informatie over de opslaggerelateerde factoren waarmee u rekening moet houden, gevolgd door aanbevelingen voor het configureren van arc-SQL Managed Instance.

Architectuur

In het volgende architectuurdiagram ziet u het logische ontwerp van gegevensservicesonderdelen met Azure Arc. Deze onderdelen omvatten een vereiste Azure Arc-gegevenscontroller en een of meer arc-SQL Managed Instance(s) die databases bevatten die ter referentie zijn ingericht. Zowel de Azure Arc-gegevenscontroller als de arc-SQL Managed Instance bieden opties voor het maken van back-ups van opslagapparaten, die afhankelijk zijn van kubernetes-distributie- en opslaginfrastructuurproviders.

Overwegingen bij het ontwerpen

Hier volgen overwegingen voor uw opslagontwerp en -configuratie.

Opslagklassen

Het kiezen van de juiste Kubernetes StorageClass en configuratie voor de onderdelen van uw Azure Arc-gegevensservices is belangrijk voor de prestaties, tolerantie en capaciteit van uw gegevensopslag.

StorageClass, PersistentVolume (PV) en PersistentVolumeClaim (PVC) zijn Kubernetes-resourceobjecten die het systeem maakt in uw Kubernetes-cluster bij het inrichten van de onderdelen van de gegevensservices met Azure Arc.

StorageClass-opties variëren afhankelijk van wat uw cloudprovider, hardwareleverancier aanbiedt en wat de Kubernetes-beheerder heeft geconfigureerd. PersistentVolumeClaim vraagt om een PersistentVolume te maken voor de StorageClass en de aangevraagde grootte. Het volgende diagram is een verwijzing naar de relatie tussen deze Kubernetes-resources en mogelijke opties voor de opslagklassen.

De PV- en PVC Kubernetes-resources worden geconfigureerd bij het inrichten van respectievelijk de Azure Arc-gegevenscontroller en arc-SQL Managed Instance.

Er zijn twee verschillende opslagtypen waaruit u kunt kiezen:

• Lokale: Een volume dat is gekoppeld aan een lokaal opslagapparaat dat is gekoppeld aan het Kubernetes-knooppunt waarop de pod wordt uitgevoerd. Dit type opslag biedt meestal een lagere latentie, samen met een hogere invoer/uitvoerbewerkingen per seconde (IOPS) en doorvoer in vergelijking met externe/gedeelde opslag.
• Externe/gedeelde opslag: Aan het netwerk gekoppelde opslagapparaten die meestal worden geleverd met ingebouwde redundantie. Veelvoorkomende opslagopties zijn NAS- en SAN-apparaten.

Houd rekening met de volgende standaarden bij het kiezen van een StorageClass. Deze criteria gelden ook voor elke databaseserver die u bouwt:

• Prestaties: De invoer/uitvoer van het opslagapparaat (I/O) en IOPS moeten voldoen aan de behoeften van uw database.
• Verhouding lezen/schrijven: Inzicht in de workload kan u helpen bij het kiezen van de ondersteuningshardware die het beste aan uw behoeften voldoet met de juiste kosten. Zware schrijfworkloads kunnen profiteren van RAID 0-configuraties, terwijl zelden gebruikte gegevens het beste kunnen worden gebruikt met behulp van een SAN-apparaatopslag.
• Database-isolatie en co-locatie: Alle databases op een exemplaar van een SQL Managed Instance met Arc delen HW, zodat u ervoor kunt kiezen om databases te verplaatsen naar afzonderlijke exemplaren van arc-SQL Managed Instance en conflicten met opslagresources te voorkomen.
• Capaciteit: De gedefinieerde opslaggrootte moet voldoen aan de toekomstige capaciteit van uw gegevenscontroller en database-exemplaren om te voorkomen dat u het formaat van een PVC moet wijzigen. Houd rekening met eventuele opslagbeperkingen die uw gekozen StorageClass kan hebben.
• Toegangsmodus: Storage Class-providers hebben verschillende toegangsmodi en ondersteunen verschillende mogelijkheden voor het koppelen en lezen of schrijven van opslag door pods. RWX (Read Write Many) is vereist voor het SQL Backup-volume.
• Redundantie: Replicatie van de gegevens op de fysieke opslaglaag (RAID) ter ondersteuning van naadloze failover als er een hardwareschijffout optreedt. Dit staat los van de redundantie op databaseniveau die door beschikbaarheidsgroepen (AG) wordt uitgevoerd.

Zowel de Azure Arc-gegevenscontroller als de arc-SQL Managed Instance Arc-gegevensservices bieden gedetailleerde opties voor het configureren van verschillende opslagklassen voor databasegegevens. Deze gegevensservices bieden ook logboeken, die flexibiliteit bieden bij het kiezen van opslagklassen om aan de behoeften te voldoen.

Gegevenscontroller

Er is één Azure Arc-gegevenscontroller vereist voor een Kubernetes-cluster als een vereiste voor het maken van exemplaren van arc-SQL Managed Instance. Meer dan één gegevenscontroller die in een cluster wordt uitgevoerd, wordt niet ondersteund.

De Azure Arc-gegevenscontroller heeft vier verschillende stateful pods die worden uitgevoerd in het Kubernetes-cluster: Controller SQL, Controller API, Logs DB en Metrics DB. Voor elke pod zijn twee permanente volumes vereist voor de gegevens- en logboekvolumes. Alle onderdelen van de gegevenscontroller vereisen een externe StorageClass om de duurzaamheid van gegevens te garanderen, omdat de onderdelen van de gegevenscontroller zelf geen systeemeigen duurzaamheid van gegevens bieden.

Houd rekening met de reken- en geheugenresources die nodig zijn voor de Azure Arc-gegevenscontroller. Het volgende diagram geeft de gegevenscontrolleropslag, PV en PVC Kubernetes-resources weer.

De standaardgrootte van het volume van de gegevenscontroller is het aanbevolen minimum. De opslag die u gebruikt, is afhankelijk van het aantal databases, hoe u de databases gebruikt en het aantal gegenereerde logboeken. De Azure Arc Data Controller StorageClass is niet gevoelig voor lage latentie. Toch kunnen gebruikers voordelen zien in de Grafana- en Kibana-interfaces met sneller presterende opslag als u veel Arc-SQL Managed Instance-implementaties in een cluster hebt. Grafana en Kibana zijn open source hulpprogramma's voor bewakingsvisualisatie die zijn geïmplementeerd met de gegevenscontroller en zijn ingericht met dashboards voor het weergeven van metrische gegevens en logboeken voor arc-SQL Managed Instance.

Inrichten van gegevenscontroller

Wanneer u de Azure Arc-gegevenscontroller inricht, configureert u de StorageClass en de opslagcapaciteit voor zowel logboeken als gegevens. Het configureren van opslag voor zowel logboeken als gegevens is van toepassing op alle acht pc's die u voor de pods van de gegevenscontroller maakt. Tijdens het inrichten kunt u een aangepaste implementatiesjabloon opgeven die standaardparameters overschrijft, zoals capaciteit, logboekretentie en items met betrekking tot beveiliging, zoals Kubernetes-servicetypen. Zodra het inrichten is voltooid, worden Pv- en PVC Kubernetes-objecten gemaakt.

Het is belangrijk om te weten dat de StorageClass voor de gegevenscontroller niet kan worden gewijzigd nadat deze is ingericht. Als u geen StorageClass opgeeft, gebruikt de gegevenscontroller de Standaard-StorageClass van Kubernetes. Deze kan variëren afhankelijk van uw Kubernetes-exemplaar of -provider.

Wanneer u de Azure Arc-gegevenscontroller verwijdert, worden alle permanente volumes die eraan zijn gekoppeld, verwijderd. Archiveer alle logboeken op besturingsvlakniveau van Azure Arc-gegevensservices die uw organisatie moet opslaan voordat u de gegevenscontroller verwijdert.

SQL Managed Instance met Azure Arc

Arc-SQL Managed Instance biedt twee verschillende lagen, afhankelijk van de bedrijfsvereisten: Algemeen en Bedrijfskritiek. Voor beide lagen is het belangrijk om de minimum- en maximumlimieten voor arc-ingeschakelde SQL Managed Instance te controleren, die configureerbaar zijn, en ervoor te zorgen dat het geïmplementeerde Kubernetes-cluster de juiste reken- en geheugencapaciteit heeft.

In scenario's met meerdere databases op een bepaald database-exemplaar gebruiken alle databases dezelfde StorageClass, PVC en PV die zijn opgegeven voor de arc-SQL Managed Instance. Het is mogelijk om meerdere exemplaren van arc-SQL Managed Instance in één Kubernetes-cluster te hebben. Deze configuratie maakt onafhankelijke permanente volumes mogelijk en kan helpen io-conflicten van verschillende databases te scheiden door de databases te implementeren op verschillende exemplaren van arc-SQL Managed Instance.

In de volgende tabel worden de verschillende permanente volumes beschreven die door elke arc-SQL Managed Instance pod worden gebruikt en het doel ervan.

Permanent volume	Beschrijving	Vereisten voor opslagklasse
Gegevens	SQL Database gegevensbestanden (MDF-bestanden)	Is afhankelijk van de laag
DataLogs	SQL Database logboekbestanden (.ldf-bestanden)	Is afhankelijk van de laag
Logboeken	SQL-agent, foutenlogboeken, traceringsbestanden, statuslogboeken	Is afhankelijk van de laag
Back-ups	SQL Server back-upbestanden, waaronder volledig, diff, transactioneel logboek	Extern, ReadWriteMany-toegangsmodus

Servicelaag voor Algemeen gebruik

De Algemeen laag van SQL Managed Instance met Arc moet gebruikmaken van externe opslag voor het database-exemplaar, zodat de gegevens bij uitval van een pod beschikbaar blijven voor nieuw gemaakte pods. Failover wordt beheerd door Kubernetes-pod- en knooppuntindeling. Deze configuratie is minder complex in vergelijking met Bedrijfskritiek, die gebruikmaakt van SQL-beschikbaarheidsgroepen en meerdere arc-SQL Managed Instance-replica's. De configuratie van één pod van de Algemeen-laag betekent dat u de hoeveelheid opslagruimte kunt minimaliseren omdat u de opslagcapaciteit voor andere replica's niet hoeft te dupliceren.

Servicelaag Bedrijfskritiek

Bedrijfskritiek laag maakt gebruik van een model met meerdere pods waarin gegevens en logboekvolumes kunnen worden opgeslagen in lokale of externe opslagklassen. Lokale opslagklassen presteren doorgaans beter in termen van latentie en doorvoer, omdat het opslagapparaat rechtstreeks aan het knooppunt is gekoppeld. Externe opslag biedt doorgaans ingebouwde redundantie, maar heeft vaak een lagere latentie en doorvoer in vergelijking met lokale opslag. Houd er rekening mee dat het gebruik van meer Bedrijfskritiek databasereplica's extra permanente volumes vereist voor gegevens, logboeken en gegevenslogboeken. De vereiste totale opslagcapaciteit is veel hoger.

In het volgende diagram ziet u de Bedrijfskritiek opslagconfiguratie voor Arc-Enabled SQL Managed Instance met twee replica's.

met Bedrijfskritiek kunt u twee of drie secundaire replica's configureren. Failover wordt beheerd door de SQL AlwaysOn-beschikbaarheidsgroep, die minder downtime biedt voor upgrades en fouten dan de Algemeen laag.

Het configureren van meerdere replica's met gegevensreplicatie in de modus Synchroon doorvoeren zorgt voor een betere beveiliging tegen fouten, zoals een mislukte pod, knooppunt of opslaghardware. Het beschermt tegen fouten omdat er meerdere kopieën van de gegevens op de replica's staan. Overweeg secundaire replica's te configureren als instanties voor lezen uitschalen, waarmee clients verbinding kunnen maken wanneer ze het secundaire listener-eindpunt gebruiken.

Azure Arc SQL Managed Instance inrichten en verwijderen

Wanneer u SQL Managed Instance met Arc inricht, hebt u de flexibiliteit om verschillende opslagklassen toe te wijzen aan elk van de vereiste arc-SQL Managed Instance permanente volumes. Mogelijk wilt u opslagopties met hogere prestaties voor Gegevens en DataLogs, maar de logboeken en back-upvolumes kunnen kostenefficiëntere StorageClass-opties gebruiken om kosten te besparen. In scenario's waarin u lokale opslag gebruikt, moet u ervoor zorgen dat de volumes op verschillende knooppunten en fysieke opslagapparaten kunnen landen om conflicten op schijf-I/O te voorkomen. Het plaatsen van de Gegevens en DataLogs op hetzelfde fysieke station kan leiden tot conflicten voor dat opslagstation, wat leidt tot slechte prestaties. In plaats daarvan kunt u overwegen om de gegevens - en gegevenslogboeken op afzonderlijke opslagstations te plaatsen om I/O te parallelliseren voor zowel databasegegevens als logboeken.

Wanneer u SQL Managed Instance met Arc verwijdert, worden de bijbehorende pc's en PVC's niet verwijderd. Dit gedrag zorgt ervoor dat u toegang hebt tot de databasebestanden voor het geval de verwijdering per ongeluk is uitgevoerd.

Ontwerpaanbeveling

Hier volgen aanbevelingen voor uw opslagontwerp en -configuratie.

Opslagklassen voor productieworkloads

Voor specifieke openbare clouds worden de aanbevolen opslagklassen voor productieworkloads weergegeven in de volgende tabel.

Provider	Gevalideerde en aanbevolen opslag
Azure Kubernetes Service (AKS)	Azure Managed Disks (Premium-laag)
Amazon Elastic Kubernetes Service (EKS)	EBS CSI-opslagstuurprogramma
Google (GKE)	Permanente GCE-schijven

Wanneer u een productieopslagklasse kiest in on-premises of scenario's met meerdere clouds, moet u ervoor zorgen dat deze voldoet aan uw beoogde opslagcapaciteit, IOPS, redundantie en doorvoerbehoeften. De volgende secties bevatten meer aanbevelingen voor deze scenario's.

Ontwerp van gegevenscontroller

Kies een externe, gedeelde StorageClass om de duurzaamheid van gegevens te garanderen. Als een pod of knooppunt wordt verwijderd, kunt u de pod weer omhoog brengen en opnieuw verbinding maken met het permanente volume. De onderstreepte StorageClass moet redundantie en hoge beschikbaarheid bieden.

We raden u aan een aangepaste implementatiesjabloon te gebruiken wanneer u de gegevenscontroller voor gegevensservices met Arc maakt. Met een aangepaste sjabloon kunt u opslagklassen, opslaggrootte voor gegevens en logboeken, beveiliging en Kubernetes-servicetypen nauwkeurig afstemmen. U kunt ze aanpassen aan uw omgeving en bedrijfsbehoeften. Voor de Azure Arc-gegevenscontroller zijn in totaal acht permanente volumes vereist. De standaard minimumconfiguratie staat 15Gi toe voor gegevens en 10Gi voor logboeken op de pc's. Configureer capaciteit die niet alleen voldoet aan de minimumaanbevelingen, maar ook een hogere groei ondersteunt, omdat er veel arc-SQL Managed Instance-implementaties in een cluster worden uitgevoerd. Met deze configuratie voorkomt u dat de grootte van HPC's in de toekomst moet worden gewijzigd.

U wordt aangeraden een StorageClass met een lagere latentie te kiezen als uw cluster veel databases en arc-SQL Managed Instance-implementaties heeft. Een lagere latentie verbetert de gebruikerservaring in Grafana- en Kibana-interfaces.

Migratie van SQL Managed Instance met Azure Arc

We raden u aan alle nieuwe en bestaande databases te plannen en te verantwoorden die betrokken zijn bij de migratie en implementatie van uw arc-SQL Managed Instance. Planning voorkomt dat databases op een later tijdstip tussen exemplaren moeten worden verplaatst.

Afhankelijk van de organisatie van uw Kubernetes-cluster kunt u arc-SQL Managed Instance-implementaties inrichten voor verschillende Kubernetes-clusters op basis van de noodzaak om omgevingen (niet-prod, prod), regio's en andere zakelijke factoren te scheiden. Bekijk het ontwerpgebied Resourceorganisatie voor meer aanbevelingen. Wanneer u meerdere database-exemplaren in een cluster configureert, moet u drukke databases scheiden in hun eigen exemplaar om I/O-conflicten te voorkomen.

Gebruik knooppuntlabels om ervoor te zorgen dat database-exemplaren op afzonderlijke knooppunten worden geplaatst om het algehele I/O-verkeer over meerdere knooppunten te verdelen. Zie Kubernetes-knooppuntlabels samen met Kubernetes Node-affiniteitslabels en anti-affiniteitslabels voor het configureren van de labels. Als u in een gevirtualiseerde omgeving werkt, moet u ervoor zorgen dat de I/O op de juiste wijze wordt gedistribueerd op het fysieke hostniveau.

Plan de capaciteit voor arc-SQL Managed Instance om voldoende opslaggrootten op te nemen voor gegevens, logboeken, gegevenslogboeken en back-ups. Wanneer u capaciteit plant om te voldoen aan zowel de huidige behoeften als de verwachte groei voor alle databases die actief zijn op de exemplaren van arc-SQL Managed Instance, voorkomt dit dat u in de toekomst de grootte van de PVC's moet wijzigen. Kies afzonderlijke fysieke stations voor Gegevens en DataLogs om parallelle I/O-activiteit mogelijk te maken. Parallelle I/O-activiteit resulteert in betere prestaties door mogelijke conflicten te voorkomen die worden veroorzaakt bij het gebruik van een gedeeld station.

Hoewel er verschillende factoren zijn die een implementatie van de Bedrijfskritiek of Algemeen laag van arc-SQL Managed Instance kunnen dicteren, biedt Bedrijfskritiek het gebruik van lokale opslag de laagste latentie en de hoogste beschikbaarheid. Bekijk het ontwerpgebied SQL Managed Instance bedrijfscontinuïteit met Arc voor aanbevelingen met betrekking tot herstel naar een bepaald tijdstip, hoge beschikbaarheid en herstel na noodgevallen. Bekijk ook het ontwerpgebied arc-enabled SQL Managed Instance cost governance voor meer informatie over de kostengevolgen tussen lagen.

De volgende subsecties bieden specifiekere aanbevelingen voor elke laag:

Algemeen-servicelaagaanbeveling

Het is raadzaam om een externe StorageClass met lage latentie te kiezen voor de permanente volumes Data en DataLogs voor optimale prestaties. Vermijd het gebruik van een StorageClass die netwerkpartities introduceert, zoals het hebben van een on-premises cluster dat is geconfigureerd voor het gebruik van een via internet geleverde StorageClass voor de permanente volumes back-up en logboeken .

Bedrijfskritiek servicelaagaanbeveling

Het is raadzaam om de verschillen in de beschikbaarheidsmodus te bekijken. Hiervoor is een andere configuratie vereist voor elke gekozen modus.

Voor scenario's met de laagst mogelijke latentievereisten kiest u lokale opslag als dit een optie is voor uw Kubernetes-infrastructuur. De lokale opslagvolumes moeten op verschillende onderliggende opslagapparaten terechtkomen om conflicten op schijf-I/O te voorkomen en de prestaties te maximaliseren. Het opslagapparaat mag niet meerdere functies hebben, zoals het hosten van de besturingssysteempartitie.

Voor leesintensieve workloads en hoge beschikbaarheid configureert u meerdere replica's en configureert u uw toepassingen of clients voor het gebruik van secundaire replica's als Lees-Scale-Out-exemplaren. Secundaire replica's zijn standaard niet leesbaar; u kunt de instelling configureren.

Bewaking

Het wordt aanbevolen om alle HPC's te bewaken die zijn gemaakt door gegevensservices met Arc, inclusief de Azure Arc-gegevenscontroller en alle exemplaren van arc-SQL Managed Instance in een cluster. Stel waarschuwingen in om u te waarschuwen wanneer een PVC bijna de capaciteit nadert. Met een melding kunt u het formaat van het PVC wijzigen voordat de capaciteit wordt bereikt. Voor rechtstreeks verbonden clusters wordt bewaking van HPC's en waarschuwingen uitgevoerd door Azure Monitor en Container Insights. Wanneer u indirect verbonden clusters gebruikt, voert u de bewaking en waarschuwingen uit in Grafana en Kibana. De Grafana-installatie bevat dashboards voor metrische gegevens van arc-SQL Managed Instance en Kubernetes-resources.

Bekijk de met Arc ingeschakelde SQL Managed Instance governancedisciplines voor meer aanbevelingen voor het bewaken van arc-SQL Managed Instance.

Volgende stappen

Zie de volgende artikelen voor meer informatie over uw hybride cloud- en multicloudcloudtraject:

• Controleer de opslagconfiguratie voor gegevensservices met Azure Arc.
• Bekijk de gevalideerde Kubernetes-distributies voor gegevensservices met Azure Arc.
• Bekijk de richtlijnen voor het aanpassen van de grootte van gegevensservices met Azure Arc.
• Controleer de bewaking met Grafana en Kibana van een arc-SQL Managed Instance.
• Ervaar met Azure Arc Jumpstart SQL Managed Instance geautomatiseerde scenario's.
• Raadpleeg het Azure Arc-leertraject op Microsoft Learn voor meer informatie over Azure Arc.