Magas rendelkezésre állás az Azure Arc által engedélyezett felügyelt SQL-példánysal

Cikk
10/16/2024

Az Azure Arc által engedélyezett felügyelt SQL-példány tárolóalapú alkalmazásként van üzembe helyezve a Kubernetesben. Kubernetes-szerkezeteket, például állapotalapú készleteket és állandó tárterületet használ a beépített szolgáltatások biztosításához:

Állapotfigyelés
Hibadetektálás
Automatikus feladatátvétel a szolgáltatás állapotának fenntartásához.

A nagyobb megbízhatóság érdekében konfigurálhatja az Azure Arc által engedélyezett felügyelt SQL-példányt is, hogy magas rendelkezésre állású konfigurációban további replikákkal telepítsen. Az Arc-adatszolgáltatások adatkezelője a következőt kezeli:

Figyelés
Hibadetektálás
Automatikus feladatátvétel

Az Arc-kompatibilis adatszolgáltatás felhasználói beavatkozás nélkül biztosítja ezt a szolgáltatást. A szolgáltatás:

A rendelkezésre állási csoport beállítása
Adatbázis-tükrözési végpontok konfigurálása
Adatbázisok hozzáadása a rendelkezésre állási csoporthoz
Koordinálja a feladatátvételt és a frissítést.

Ez a dokumentum a magas rendelkezésre állás mindkét típusát ismerteti.

Az Azure Arc által engedélyezett felügyelt SQL-példány különböző magas rendelkezésre állást biztosít attól függően, hogy a felügyelt SQL-példány általános célú szolgáltatási szintként vagy üzletileg kritikus szolgáltatási szintként lett-e üzembe helyezve.

Magas rendelkezésre állás az általános célú szolgáltatási szinten

Az Általános célú szolgáltatási szinten csak egy replika érhető el, és a magas rendelkezésre állás a Kubernetes vezénylésével érhető el. Ha például egy felügyelt példány tárolólemezképét tartalmazó pod vagy csomópont összeomlik, a Kubernetes megpróbál felállni egy másik podot vagy csomópontot, és ugyanahhoz az állandó tárhoz csatlakozik. Ez idő alatt a felügyelt SQL-példány nem érhető el az alkalmazások számára. Az alkalmazásoknak újra kell csatlakozniuk, és újra kell próbálkoznia a tranzakcióval, amikor az új pod fel van állítva. Ha load balancer a szolgáltatástípust használja, akkor az alkalmazások újra csatlakozhatnak ugyanahhoz az elsődleges végponthoz, és a Kubernetes átirányítja a kapcsolatot az új elsődlegesre. Ha a szolgáltatás típusa az, nodeport akkor az alkalmazásoknak újra csatlakozniuk kell az új IP-címhez.

A beépített magas rendelkezésre állás ellenőrzése

A Kubernetes által biztosított magas rendelkezésre állás ellenőrzéséhez:

Meglévő felügyelt példány podjának törlése
Ellenőrizze, hogy a Kubernetes helyreáll-e ebből a műveletből

A helyreállítás során a Kubernetes egy másik podot indít el, és csatolja az állandó tárolót.

Előfeltételek

A Kubernetes-fürt megosztott, távoli tárolást igényel
Az Azure Arc által egy replikával üzembe helyezett felügyelt SQL-példány (alapértelmezett)

A podok megtekintése.

kubectl get pods -n <namespace of data controller>

Törölje a felügyelt példány podot.

kubectl delete pod <name of managed instance>-0 -n <namespace of data controller>

Példa:

user@pc:/# kubectl delete pod sql1-0 -n arc
pod "sql1-0" deleted

Tekintse meg a podokat annak ellenőrzéséhez, hogy a felügyelt példány helyreáll-e.

kubectl get pods -n <namespace of data controller>

Példa:

user@pc:/# kubectl get pods -n arc
NAME                 READY   STATUS    RESTARTS   AGE
sql1-0               2/3     Running   0          22s

A podon belüli összes tároló helyreállítása után csatlakozhat a felügyelt példányhoz.

Magas rendelkezésre állás üzletileg kritikus szolgáltatási szinten

A üzletileg kritikus szolgáltatásszinten a Kubernetes vezénylésével natív módon biztosítottak mellett az Azure Archoz készült FELÜGYELT SQL-példány tartalmazott rendelkezésre állási csoportot is biztosít. A tartalmazott rendelkezésre állási csoport az SQL Server Always On technológiára épül. Magasabb rendelkezésre állást biztosít. Az Azure Arc által üzletileg kritikus szolgáltatásszinttel üzembe helyezett felügyelt SQL-példány 2 vagy 3 replikával telepíthető. Ezek a replikák mindig szinkronban vannak egymással.

A foglalt rendelkezésre állási csoportok esetén a pod-összeomlások vagy csomóponthibák transzparensek az alkalmazás számára. A tartalmazott rendelkezésre állási csoport legalább egy másik podot biztosít, amely az elsődlegestől származó összes adatot tartalmazza, és készen áll a kapcsolatokra.

Tartalmazott rendelkezésre állási csoportok

A rendelkezésre állási csoportok egy vagy több felhasználói adatbázist logikai csoporthoz kötnek, így feladatátvétel esetén a teljes adatbáziscsoport egyetlen egységként a másodlagos replikára kerül. A rendelkezésre állási csoportok csak a felhasználói adatbázisokban replikálják az adatokat, a rendszeradatbázisokban lévő adatokat azonban nem, például bejelentkezéseket, engedélyeket vagy ügynökfeladatokat. A tartalmazott rendelkezésre állási csoport a rendszeradatbázisokból, például msdb az adatbázisokból származó master metaadatokat tartalmazza. Amikor a bejelentkezések az elsődleges replikában jönnek létre vagy módosulnak, azok automatikusan a másodlagos replikákban is létrejönnek. Hasonlóképpen, ha az elsődleges replikában létrehoz vagy módosít egy ügynökfeladatot, a másodlagos replikák is megkapják ezeket a módosításokat.

Az Azure Arc által engedélyezett felügyelt SQL-példány a tartalmazott rendelkezésre állási csoport fogalmát használja, és hozzáadja a Kubernetes-operátort, hogy ezek nagy méretekben üzembe helyezhetők és kezelhetők legyenek.

A rendelkezésre állási csoportokat tartalmazó képességek az alábbiakat teszik lehetővé:

Ha több replikával van üzembe helyezve, egyetlen rendelkezésre állási csoport jön létre, amelynek neve megegyezik az Arc-kompatibilis felügyelt SQL-példány nevével. Alapértelmezés szerint a tartalmazott AG három replikával rendelkezik, köztük az elsődleges replikákkal. A rendelkezésre állási csoport összes CRUD-művelete belsőleg van felügyelve, beleértve a rendelkezésre állási csoport létrehozását vagy a replikáknak a létrehozott rendelkezésre állási csoporthoz való csatlakoztatását. Nem hozhat létre több rendelkezésre állási csoportot egy példányban.
A rendszer automatikusan hozzáadja az összes adatbázist a rendelkezésre állási csoporthoz, beleértve az összes felhasználói és rendszeradatbázist, például master és msdb. Ez a funkció egyetlen rendszernézetet biztosít a rendelkezésre állási csoport replikái között. Figyelje meg mind containedag_master az containedag_msdb adatbázisokat, ha közvetlenül a példányhoz csatlakozik. Az containedag_* adatbázisok a rendelkezésre állási master csoporton belüli és msdb azon belüli adatbázisokat jelölik.
A külső végpont automatikusan ki van építve a rendelkezésre állási csoporton belüli adatbázisokhoz való csatlakozáshoz. Ez a végpont <managed_instance_name>-external-svc tölti be a rendelkezésre állási csoport figyelőjének szerepét.

Az Azure Arc által engedélyezett felügyelt SQL-példány üzembe helyezése több replikával az Azure Portal használatával

Az Azure Portalon az Azure Arc által engedélyezett felügyelt SQL-példány létrehozása lapon:

Válassza a Compute + Storage konfigurálása lehetőséget a Compute + Storage területen. A portál speciális beállításokat jelenít meg.
A Szolgáltatási szint területen válassza a üzletileg kritikus.
Ha fejlesztési célokra használja, ellenőrizze a "Csak fejlesztési célokra használható" jelölőnégyzetet.
A Magas rendelkezésre állás csoportban válasszon 2 vagy 3 replikát.

Magas rendelkezésre állási beállítások

Üzembe helyezés több replikával az Azure CLI használatával

Ha az Azure Arc által engedélyezett felügyelt SQL-példány üzletileg kritikus szolgáltatási szinten van üzembe helyezve, az üzembe helyezés több replikát hoz létre. A példányok között található rendelkezésre állási csoportok beállítása és konfigurálása automatikusan megtörténik a kiépítés során.

Az alábbi parancs például létrehoz egy felügyelt példányt 3 replikával.

Közvetetten csatlakoztatott mód:

az sql mi-arc create -n <instanceName> --k8s-namespace <namespace> --use-k8s --tier <tier> --replicas <number of replicas>

Példa:

az sql mi-arc create -n sqldemo --k8s-namespace my-namespace --use-k8s --tier BusinessCritical --replicas 3

Közvetlenül csatlakoztatott mód:

az sql mi-arc create --name <name> --resource-group <group>  --location <Azure location> –subscription <subscription>  --custom-location <custom-location> --tier <tier> --replicas <number of replicas>

Példa:

az sql mi-arc create --name sqldemo --resource-group rg  --location uswest2 –subscription xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  --custom-location private-location --tier BusinessCritical --replcias 3

Alapértelmezés szerint az összes replika szinkron módban van konfigurálva. Ez azt jelenti, hogy az elsődleges példányon lévő frissítések szinkron módon replikálódnak az egyes másodlagos példányokra.

Magas rendelkezésre állási állapot megtekintése és figyelése

Az üzembe helyezés befejezése után csatlakozzon az elsődleges végponthoz az SQL Server Management Studióból.

Ellenőrizze és kérje le az elsődleges replika végpontját, és csatlakozzon hozzá az SQL Server Management Studióból. Ha például az SQL-példányt a következő paranccsal service-type=loadbalancertelepítették, futtassa az alábbi parancsot a végpont lekéréséhez a csatlakozáshoz:

az sql mi-arc list --k8s-namespace my-namespace --use-k8s

vagy

kubectl get sqlmi -A

Az elsődleges és másodlagos végpontok és az AG állapotának lekérése

Az elsődleges és másodlagos végpontok és a magas rendelkezésre állási állapot megtekintéséhez használja a kubectl describe sqlmi parancsokat az sql mi-arc show vagy parancsokat.

Példa:

kubectl describe sqlmi sqldemo -n my-namespace

vagy

az sql mi-arc show --name sqldemo --k8s-namespace my-namespace --use-k8s

Példa a kimenetre:

 "status": {
    "endpoints": {
      "logSearchDashboard": "https://10.120.230.404:5601/app/kibana#/discover?_a=(query:(language:kuery,query:'custom_resource_name:sqldemo'))",
      "metricsDashboard": "https://10.120.230.46:3000/d/40q72HnGk/sql-managed-instance-metrics?var-hostname=sqldemo-0",
      "mirroring": "10.15.100.150:5022",
      "primary": "10.15.100.150,1433",
      "secondary": "10.15.100.156,1433"
    },
    "highAvailability": {
      "healthState": "OK",
      "mirroringCertificate": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----"
    },
    "observedGeneration": 1,
    "readyReplicas": "2/2",
    "state": "Ready"
  }

Csatlakozhat az elsődleges végponthoz az SQL Server Management Studióval, és ellenőrizheti a DMV-ket a következő módon:

SELECT * FROM sys.dm_hadr_availability_replica_states

Rendelkezésreállási csoport

És a tartalmazott rendelkezésre állási irányítópult:

Tároló rendelkezésre állási csoport irányítópultja

Feladatátvételi forgatókönyvek

Az SQL Server Always On rendelkezésre állási csoportokkal ellentétben a tartalmazott rendelkezésre állási csoport egy felügyelt magas rendelkezésre állású megoldás. Ezért a feladatátvételi módok korlátozottak az SQL Server Always On rendelkezésre állási csoportokban elérhető tipikus módokhoz képest.

Helyezzen üzembe üzletileg kritikus szolgáltatásszinten felügyelt SQL-példányokat kétreplika-konfigurációban vagy három replikakonfigurációban. A hibák hatása és az azt követő helyreállítás különböző az egyes konfigurációk esetében. A három replikapéldány magasabb rendelkezésre állást és helyreállítást biztosít, mint két replikapéldány.

Két replikakonfigurációban, ha mindkét csomópont állapota SYNCHRONIZEDelérhetetlenné válik, a másodlagos replika automatikusan előléptetődik az elsődlegesre. Amikor a sikertelen replika elérhetővé válik, az összes függőben lévő módosítással frissül. Ha csatlakozási problémák merülnek fel a replikák között, akkor előfordulhat, hogy az elsődleges replika nem véglegesíti a tranzakciókat, mivel minden tranzakciót le kell véglegesíteni mindkét replikán, mielőtt a sikeresség visszakerül az elsődlegesre.

Három replikakonfiguráció esetén a tranzakciónak a 3 replika közül legalább 2-ben véglegesítenie kell, mielőtt sikeres üzenetet ad vissza az alkalmazásnak. Hiba esetén a rendszer automatikusan előlépteti az egyik másodfokot az elsődlegesre, míg a Kubernetes megpróbálja helyreállítani a sikertelen replikát. Amikor a replika elérhetővé válik, a rendszer automatikusan újra csatlakozik a foglalt rendelkezésre állási csoporthoz, és a függőben lévő módosítások szinkronizálódnak. Ha csatlakozási problémák lépnek fel a replikák között, és több mint 2 replika nincs szinkronizálva, az elsődleges replika nem véglegesíti a tranzakciókat.

Feljegyzés

Javasoljuk, hogy egy üzletileg kritikus felügyelt SQL-példányt három replikakonfigurációban helyezzen üzembe, mint két replikakonfigurációban, hogy közel nulla adatvesztést érjen el.

Ha az elsődleges replikáról az egyik másodikra szeretne feladatátvételt végrehajtani, egy tervezett eseményhez futtassa a következő parancsot:

Ha elsődlegeshez csatlakozik, a következő T-SQL használatával feladatátvételt végezhet az SQL-példányon az egyik másodfokon:

ALTER AVAILABILITY GROUP current SET (ROLE = SECONDARY);

Ha a másodlagoshoz csatlakozik, a következő T-SQL használatával előléptetheti a kívánt másodlagost az elsődleges replikához.

ALTER AVAILABILITY GROUP current SET (ROLE = PRIMARY);

Előnyben részesített elsődleges replika

Egy adott replikát is beállíthat elsődleges replikának az AZ CLI használatával az alábbiak szerint:

az sql mi-arc update --name <sqlinstance name> --k8s-namespace <namespace> --use-k8s --preferred-primary-replica <replica>

Példa:

az sql mi-arc update --name sqldemo --k8s-namespace my-namespace --use-k8s --preferred-primary-replica sqldemo-3

Feljegyzés

A Kubernetes megpróbálja beállítani az előnyben részesített replikát, de ez nem garantált.

Adatbázis visszaállítása több replikapéldányra

Az adatbázis rendelkezésre állási csoportba való visszaállításához további lépések szükségesek. Az alábbi lépések bemutatják, hogyan állíthatja vissza az adatbázist egy felügyelt példányba, és hogyan adhat hozzá egy rendelkezésre állási csoporthoz.

Az elsődleges példány külső végpontjának elérhetővé tétele új Kubernetes-szolgáltatás létrehozásával.

Határozza meg az elsődleges replikát üzemeltető podot. Csatlakozzon a felügyelt példányhoz, és futtassa a következőt:
```
SELECT @@SERVERNAME
```
A lekérdezés az elsődleges replikát üzemeltető podot adja vissza.

Hozza létre a Kubernetes-szolgáltatást az elsődleges példányon az alábbi parancs futtatásával, ha a Kubernetes-fürt szolgáltatásokat használ NodePort . Cserélje le <podName> az előző lépésben visszaadott kiszolgáló nevére a <serviceName> létrehozott Kubernetes szolgáltatás előnyben részesített nevét.
```
kubectl -n <namespaceName> expose pod <podName> --port=1533  --name=<serviceName> --type=NodePort
```
LoadBalancer-szolgáltatás esetén futtassa ugyanazt a parancsot, kivéve, hogy a létrehozott szolgáltatás típusa.LoadBalancer Példa:
```
kubectl -n <namespaceName> expose pod <podName> --port=1533  --name=<serviceName> --type=LoadBalancer
```
Íme egy példa erre a parancsra, amely az Azure Kubernetes Service-ben fut, ahol az elsődleges pod a következő sql2-0:
```
kubectl -n arc-cluster expose pod sql2-0 --port=1533  --name=sql2-0-p --type=LoadBalancer
```
Hozza létre a Kubernetes-szolgáltatás IP-címét:
```
kubectl get services -n <namespaceName>
```

Állítsa vissza az adatbázist az elsődleges példány végpontjának.

Adja hozzá az adatbázis biztonsági mentési fájljának az elsődleges példány tárolójába.

kubectl cp <source file location> <pod name>:var/opt/mssql/data/<file name> -c <serviceName> -n <namespaceName>

Példa

kubectl cp /home/WideWorldImporters-Full.bak sql2-1:var/opt/mssql/data/WideWorldImporters-Full.bak -c arc-sqlmi -n arc

Az adatbázis biztonsági mentési fájljának visszaállítása az alábbi parancs futtatásával.

RESTORE DATABASE test FROM DISK = '/var/opt/mssql/data/<file name>.bak'
WITH MOVE '<database name>' to '/var/opt/mssql/data/<file name>.mdf'  
,MOVE '<database name>' to '/var/opt/mssql/data/<file name>_log.ldf'  
,RECOVERY, REPLACE, STATS = 5;  
GO

Példa

RESTORE Database WideWorldImporters
FROM DISK = '/var/opt/mssql/data/WideWorldImporters-Full.BAK'
WITH
MOVE 'WWI_Primary' TO '/var/opt/mssql/data/WideWorldImporters.mdf',
MOVE 'WWI_UserData' TO '/var/opt/mssql/data/WideWorldImporters_UserData.ndf',
MOVE 'WWI_Log' TO '/var/opt/mssql/data/WideWorldImporters.ldf',
MOVE 'WWI_InMemory_Data_1' TO '/var/opt/mssql/data/WideWorldImporters_InMemory_Data_1',
RECOVERY, REPLACE, STATS = 5;  
GO

Adja hozzá az adatbázist a rendelkezésre állási csoporthoz.

Ahhoz, hogy az adatbázis hozzá legyen adva az AG-hez, teljes helyreállítási módban kell futnia, és napló biztonsági mentést kell készítenie. Az alábbi TSQL-utasítások futtatásával adja hozzá a visszaállított adatbázist a rendelkezésre állási csoporthoz.
```
ALTER DATABASE <databaseName> SET RECOVERY FULL;
BACKUP DATABASE <databaseName> TO DISK='<filePath>'
ALTER AVAILABILITY GROUP containedag ADD DATABASE <databaseName>
```
Az alábbi példa egy, a példányon visszaállított adatbázist WideWorldImporters ad hozzá:
```
ALTER DATABASE WideWorldImporters SET RECOVERY FULL;
BACKUP DATABASE WideWorldImporters TO DISK='/var/opt/mssql/data/WideWorldImporters.bak'
ALTER AVAILABILITY GROUP containedag ADD DATABASE WideWorldImporters
```

Fontos

Ajánlott eljárásként törölje a fent létrehozott Kubernetes szolgáltatást a következő parancs futtatásával:

kubectl delete svc sql2-0-p -n arc

Korlátozások

Az Azure Arc rendelkezésre állási csoportjai által engedélyezett FELÜGYELT SQL-példányra ugyanazok a korlátozások vonatkoznak, mint a Big Data Cluster rendelkezésre állási csoportjaira. További információ: SQL Server Big Data-fürt üzembe helyezése magas rendelkezésre állással.

További információ az Azure Arc által engedélyezett felügyelt SQL-példány funkcióiról és képességeiről

Megosztás a következőn keresztül:

Magas rendelkezésre állás az Azure Arc által engedélyezett felügyelt SQL-példánysal

Magas rendelkezésre állás az általános célú szolgáltatási szinten

A beépített magas rendelkezésre állás ellenőrzése

Előfeltételek

Magas rendelkezésre állás üzletileg kritikus szolgáltatási szinten

Tartalmazott rendelkezésre állási csoportok

Az Azure Arc által engedélyezett felügyelt SQL-példány üzembe helyezése több replikával az Azure Portal használatával

Üzembe helyezés több replikával az Azure CLI használatával

Magas rendelkezésre állási állapot megtekintése és figyelése

Az elsődleges és másodlagos végpontok és az AG állapotának lekérése

Feladatátvételi forgatókönyvek

Előnyben részesített elsődleges replika

Adatbázis visszaállítása több replikapéldányra

Korlátozások

Visszajelzés

További források

Megosztás a következőn keresztül:

Magas rendelkezésre állás az Azure Arc által engedélyezett felügyelt SQL-példánysal

Magas rendelkezésre állás az általános célú szolgáltatási szinten

A beépített magas rendelkezésre állás ellenőrzése

Előfeltételek

Magas rendelkezésre állás üzletileg kritikus szolgáltatási szinten

Tartalmazott rendelkezésre állási csoportok

Az Azure Arc által engedélyezett felügyelt SQL-példány üzembe helyezése több replikával az Azure Portal használatával

Üzembe helyezés több replikával az Azure CLI használatával

Magas rendelkezésre állási állapot megtekintése és figyelése

Az elsődleges és másodlagos végpontok és az AG állapotának lekérése

Feladatátvételi forgatókönyvek

Előnyben részesített elsődleges replika

Adatbázis visszaállítása több replikapéldányra

Korlátozások

Kapcsolódó tartalom

Visszajelzés

További források