Konfigurace úložiště

Koncepty úložiště Kubernetes

Kubernetes poskytuje vrstvu abstrakce infrastruktury nad základní technologií virtualizace (volitelné) a hardware. Způsob, jakým Kubernetes abstrahuje úložiště, je prostřednictvím tříd úložiště. Při zřizování podu můžete pro každý svazek zadat třídu úložiště. V době zřízení podu se zavolá zřizovací program třídy úložiště, který zřídí úložiště, a pak se v daném zřízeném úložišti vytvoří trvalý svazek a pak se pod připojí k trvalému svazku pomocí deklarace trvalého svazku.

Kubernetes poskytuje poskytovatelům infrastruktury úložiště způsob, jak připojit ovladače (označované také jako Doplňky), které rozšiřují Kubernetes. Doplňky úložiště musí být v souladu se standardem Rozhraní úložiště kontejnerů. Existuje desítky doplňků, které lze najít v tomto nekonficiálním seznamu ovladačů CSI. Konkrétní ovladač CSI, který používáte, závisí na faktorech, jako je to, jestli používáte službu Kubernetes hostované v cloudu, spravovanou službu Kubernetes nebo na tom, kterého poskytovatele OEM používáte pro váš hardware.

Pokud chcete zobrazit třídy úložiště nakonfigurované v clusteru Kubernetes, spusťte tento příkaz:

kubectl get storageclass

Příklad výstupu z clusteru Azure Kubernetes Service (AKS):

NAME                PROVISIONER                AGE
azurefile           kubernetes.io/azure-file   15d
azurefile-premium   kubernetes.io/azure-file   15d
default (default)   kubernetes.io/azure-disk   4d3h
managed-premium     kubernetes.io/azure-disk   4d3h

Spuštěním tohoto příkazu můžete získat podrobnosti o třídě úložiště:

kubectl describe storageclass/<storage class name>

Příklad:

kubectl describe storageclass/azurefile

Name:            azurefile
IsDefaultClass:  No
Annotations:     kubectl.kubernetes.io/last-applied-configuration={"allowVolumeExpansion":true,"apiVersion":"storage.k8s.io/v1beta1","kind":"StorageClass","metadata":{"annotations":{},"labels":{"kubernetes.io/cluster-service":"true"},"name":"azurefile"},"parameters":{"sku
Name":"Standard_LRS"},"provisioner":"kubernetes.io/azure-file"}

Provisioner:           kubernetes.io/azure-file
Parameters:            skuName=Standard_LRS
AllowVolumeExpansion:  True
MountOptions:          <none>
ReclaimPolicy:         Delete
VolumeBindingMode:     Immediate
Events:                <none>

Aktuálně zřízené trvalé svazky a deklarace identity trvalých svazků můžete zobrazit spuštěním následujících příkazů:

kubectl get persistentvolumes -n <namespace>

kubectl get persistentvolumeclaims -n <namespace>

Příklad zobrazení trvalých svazků:

kubectl get persistentvolumes -n arc

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                      STORAGECLASS   REASON   AGE
pvc-07fc7b9f-9a37-4796-9442-4405147120da   15Gi       RWO            Delete           Bound    arc/sqldemo11-data-claim   default                 7d3h
pvc-3e772f20-ed89-4642-b34d-8bb11b088afa   15Gi       RWO            Delete           Bound    arc/data-metricsdb-0       default                 7d14h
pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665   10Gi       RWO            Delete           Bound    arc/sqldemo11-logs-claim   default                 7d3h
pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad   15Gi       RWO            Delete           Bound    arc/data-controller        default                 7d14h
pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91   10Gi       RWO            Delete           Bound    arc/logs-controller        default                 7d14h
pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493   10Gi       RWO            Delete           Bound    arc/logs-metricsdb-0       default                 7d14h
pvc-8e2cacbc-e953-4901-8591-e77df9af309c   10Gi       RWO            Delete           Bound    arc/sqldemo10-logs-claim   default                 7d14h
pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513   15Gi       RWO            Delete           Bound    arc/sqldemo10-data-claim   default                 7d14h
pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5   15Gi       RWO            Delete           Bound    arc/data-controldb         default                 7d14h
pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb   10Gi       RWO            Delete           Bound    arc/logs-controldb         default                 7d14h
pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4   10Gi       RWO            Delete           Bound    arc/logs-logsdb-0          default                 7d14h
pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd   15Gi       RWO            Delete           Bound    arc/data-logsdb-0          default                 7d14h

Příklad zobrazení trvalých deklarací identity svazku:

kubectl get persistentvolumeclaims -n arc

NAME                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
data-controldb         Bound    pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5   15Gi       RWO            default        7d14h
data-controller        Bound    pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad   15Gi       RWO            default        7d14h
data-logsdb-0          Bound    pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd   15Gi       RWO            default        7d14h
data-metricsdb-0       Bound    pvc-3e772f20-ed89-4642-b34d-8bb11b088afa   15Gi       RWO            default        7d14h
logs-controldb         Bound    pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb   10Gi       RWO            default        7d14h
logs-controller        Bound    pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91   10Gi       RWO            default        7d14h
logs-logsdb-0          Bound    pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4   10Gi       RWO            default        7d14h
logs-metricsdb-0       Bound    pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493   10Gi       RWO            default        7d14h
sqldemo10-data-claim   Bound    pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513   15Gi       RWO            default        7d14h
sqldemo10-logs-claim   Bound    pvc-8e2cacbc-e953-4901-8591-e77df9af309c   10Gi       RWO            default        7d14h
sqldemo11-data-claim   Bound    pvc-07fc7b9f-9a37-4796-9442-4405147120da   15Gi       RWO            default        7d4h
sqldemo11-logs-claim   Bound    pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665   10Gi       RWO            default        7d4h

Faktory, které je potřeba vzít v úvahu při výběru konfigurace úložiště

Výběr správné třídy úložiště je důležitý pro odolnost a výkon dat. Volba nesprávné třídy úložiště může způsobit riziko celkové ztráty dat v případě selhání hardwaru nebo může vést k nižšímu optimálnímu výkonu.

Obecně existují dva typy úložiště:

• Místní úložiště – úložiště zřízené na místních pevných discích na daném uzlu Tento druh úložiště může být ideální z hlediska výkonu, ale vyžaduje speciálně návrh pro redundanci dat tím, že replikuje data napříč několika uzly.
• Vzdálené, sdílené úložiště – úložiště zřízené na některých vzdálených úložných zařízeních – například SÍŤ SAN, NAS nebo cloudová služba úložiště, jako je EBS nebo Azure Files. Tento druh úložiště obvykle poskytuje redundanci dat automaticky, ale není tak rychlé, jak může být místní úložiště.

Třídy úložiště založené na systému souborů NFS

V závislosti na konfiguraci serveru NFS a zřizování třídy úložiště možná budete muset nastavit supplementalGroups v konfiguracích podů pro instance databáze a možná budete muset změnit konfiguraci serveru NFS tak, aby používala ID skupin předávaných klientem (na rozdíl od vyhledávání ID skupin na serveru pomocí předaného ID uživatele). Obraťte se na správce systému souborů NFS a zjistěte, jestli se jedná o tento případ.

Vlastnost supplementalGroups přebírá pole hodnot, které můžete nastavit při nasazení. Kontroler dat Azure Arc je použije pro všechny instance databáze, které vytvoří.

Pokud chcete nastavit tuto vlastnost, spusťte následující příkaz:

az arcdata dc config add --path custom/control.json --json-values 'spec.security.supplementalGroups="1234556"'

Konfigurace úložiště kontroleru dat

Některé služby v Azure Arc pro datové služby závisí na konfiguraci vzdáleného a sdíleného úložiště, protože služby nemají možnost replikovat data. Tyto služby se nacházejí v kolekci podů kontroleru dat:

V době zřízení kontroleru dat je třída úložiště, která se má použít pro každý z těchto trvalých svazků, určena předáním třídy --storage-class | -sc parametr příkazu az arcdata dc create nebo nastavením tříd úložiště v souboru šablony nasazení control.json, který se používá. Pokud k vytvoření kontroleru dat v přímo připojeném režimu používáte Azure Portal, šablona nasazení, kterou zvolíte, má buď předdefinovanou třídu úložiště v šabloně, nebo můžete vybrat šablonu, která nemá předdefinovanou třídu úložiště. Pokud vaše šablona nedefinuje třídu úložiště, portál vás k tomu vyzve. Pokud používáte vlastní šablonu nasazení, můžete zadat třídu úložiště.

Šablony nasazení, které jsou k dispozici, mají zadanou výchozí třídu úložiště, která je vhodná pro cílové prostředí, ale lze ji během nasazení přepsat. Podrobný postup vytvoření vlastních šablon konfigurace pro změnu konfigurace třídy úložiště pro pody kontroleru dat v době nasazení.

Pokud třídu úložiště nastavíte pomocí nebo -scparametru--storage-class, použije se tato třída úložiště pro třídy úložiště protokolů i datových úložišť. Pokud nastavíte třídy úložiště v souboru šablony nasazení, můžete pro protokoly a data zadat různé třídy úložiště.

Důležité faktory, které je potřeba vzít v úvahu při výběru třídy úložiště pro pody kontroleru dat:

• Abyste zajistili stálost dat, musíte použít vzdálenou třídu sdíleného úložiště, aby se v případě, že pod nebo uzel zemře, že se po přenesení podu může znovu připojit k trvalému svazku.
• Data zapsaná do instance SQL kontroleru, databáze metrik a databáze protokolů jsou obvykle poměrně nízká a ne citlivá na latenci, takže úložiště s ultra rychlým výkonem není kritické. Pokud máte uživatele, kteří často používají rozhraní Grafana a Kibana a máte velký počet instancí databáze, můžou uživatelé těžit z rychlejšího výkonu úložiště.
• Požadovaná kapacita úložiště je proměnná s počtem instancí databáze, které jste nasadili, protože se shromažďují protokoly a metriky pro každou instanci databáze. Data se uchovávají v protokolech a databázi metrik po dobu dvou (2) týdnů před vymazáním.
• Změna třídy úložiště po nasazení je obtížná, nezdokumentovaná a nepodporuje se. Nezapomeňte správně zvolit třídu úložiště v době nasazení.

Konfigurace úložiště instancí databáze

Každá instance databáze obsahuje data, protokoly a trvalé svazky zálohování. Třídy úložiště pro tyto trvalé svazky je možné zadat v době nasazení. Pokud není zadaná žádná třída úložiště, použije se výchozí třída úložiště.

Při vytváření instance pomocí jedné az sql mi-arc create nebo az postgres server-arc create, existují čtyři parametry, které můžete použít k nastavení tříd úložiště:

Následující tabulka uvádí cesty v kontejneru spravované instance Azure SQL, který je mapován na trvalý svazek pro data a protokoly:

Následující tabulka uvádí cesty v kontejneru instance PostgreSQL, který je mapován na trvalý svazek pro data a protokoly:

Každá instance databáze má samostatný trvalý svazek pro datové soubory, protokoly a zálohy. To znamená, že pro každý z těchto typů souborů existuje oddělení vstupně-výstupních operací, na které se vztahuje způsob, jakým zřizování svazků zřizuje úložiště. Každá instance databáze má vlastní deklarace identity trvalých svazků a trvalé svazky.

Pokud v dané instanci databáze existuje více databází, všechny databáze používají stejnou trvalou deklaraci identity svazku, trvalý svazek a třídu úložiště. Všechny zálohy – rozdílové zálohování protokolů i úplné zálohování používají stejnou deklaraci trvalého svazku a trvalý svazek. Deklarace identity trvalých svazků pro pody instancí databáze jsou uvedené níže:

Důležité faktory, které je potřeba vzít v úvahu při výběru třídy úložiště pro pody instancí databáze:

• Od verze datových služeb Azure Arc z února 2022 musíte pro zálohování zadat třídu úložiště podporující ReadWriteMany (RWX). Přečtěte si další informace o režimech přístupu. Pokud není pro zálohování zadaná žádná třída úložiště, použije se výchozí třída úložiště v kubernetes a pokud není schopná RWX, nasazení spravované instance Azure SQL nemusí proběhnout úspěšně.
• Databázové instance je možné nasadit buď v jednom vzoru podu, nebo ve více vzorech podů. Příkladem jednoho vzoru podu je cenová úroveň Azure SQL Managed Instance pro obecné účely. Příkladem více podů je vysoce dostupná Pro důležité obchodní informace cenová úroveň spravované instance Azure SQL. Instance databáze nasazené s jedním vzorem podů musí používat vzdálenou třídu sdíleného úložiště, aby se zajistila stálost dat a aby se v případě, že pod nebo uzel zemře, že se po přenesení podu může znovu připojit k trvalému svazku. Naproti tomu vysoce dostupná spravovaná instance Azure SQL používá skupiny dostupnosti AlwaysOn k replikaci dat z jedné instance do jiné synchronně nebo asynchronně. Zejména v případě, kdy se data replikují synchronně, existuje vždy více kopií dat – obvykle tři kopie. Z tohoto důvodu je možné použít místní úložiště nebo vzdálené třídy sdíleného úložiště pro soubory dat a protokolů. Pokud využíváte místní úložiště, data se zachovají i v případě neúspěšného podu, uzlu nebo hardwaru úložiště, protože existuje více kopií dat. Vzhledem k této flexibilitě se můžete rozhodnout použít místní úložiště pro lepší výkon.
• Výkon databáze je z velké části funkcí propustnosti vstupně-výstupních operací daného úložného zařízení. Pokud je vaše databáze silná na čtení nebo náročné zápisy, měli byste zvolit třídu úložiště s hardwarem navrženým pro tento typ úlohy. Pokud se například vaše databáze používá hlavně pro zápisy, můžete zvolit místní úložiště s RAID 0. Pokud se vaše databáze většinou používá pro čtení malého množství "horkých dat", ale existuje velký celkový objem úložiště studených dat, můžete zvolit zařízení SAN schopné vrstvené úložiště. Volba správné třídy úložiště se nijak neliší od výběru typu úložiště, které byste použili pro jakoukoli databázi.
• Pokud používáte zřizovací modul místního svazku úložiště, ujistěte se, že místní svazky zřízené pro data, protokoly a zálohy jsou každá cílová místa na různých podkladových úložných zařízeních, aby nedocházelo ke kolizím na vstupně-výstupních operacích disku. Operační systém by měl být také na svazku, který je připojený k samostatným diskům. Jedná se v podstatě o stejné pokyny jako u instance databáze na fyzickém hardwaru.
• Vzhledem k tomu, že všechny databáze v dané instanci sdílejí trvalou deklaraci identity svazku a trvalý svazek, nezapomeňte uvolnit zaneprázdněné databázové instance ve stejné instanci databáze. Pokud je to možné, oddělte zaneprázdněné databáze na vlastní instance databáze, abyste se vyhnuli kolizím vstupně-výstupních operací. K distribuci celkového vstupně-výstupního provozu mezi více uzlů použijte také cílení popisků uzlů na samostatné instance databáze. Pokud používáte virtualizaci, nezapomeňte zvážit distribuci vstupně-výstupních přenosů nejen na úrovni uzlu, ale také kombinované vstupně-výstupní aktivity probíhající všemi virtuálními počítači uzlů na daném fyzickém hostiteli.

Odhad požadavků na úložiště

Každý pod, který obsahuje stavová data, používá alespoň dva trvalé svazky – jeden trvalý svazek pro data a další trvalý svazek pro protokoly. Následující tabulka uvádí počet trvalých svazků potřebných pro jeden kontroler dat, spravovanou instanci Azure SQL, instanci Azure Database for PostgreSQL a instanci HyperScale Azure PostgreSQL:

Následující tabulka ukazuje celkový počet trvalých svazků potřebných pro ukázkové nasazení:

Tento výpočet lze použít k naplánování úložiště pro cluster Kubernetes na základě zřizovacího modulu úložiště nebo prostředí. Pokud se například pro cluster Kubernetes používá místní zřizování úložiště s pěti (5) uzly, pak pro ukázkové nasazení nad každým uzlem vyžaduje alespoň úložiště pro 10 trvalých svazků. Podobně při zřizování clusteru Azure Kubernetes Service (AKS) s pěti (5) uzly, které vyberou odpovídající velikost virtuálního počítače pro fond uzlů, aby bylo možné připojit 10 datových disků, je důležité. Další podrobnosti o velikosti uzlů pro potřeby úložiště pro uzly AKS najdete tady.

Výběr správné třídy úložiště

Místní a hraniční lokality

Partneři Microsoftu a OEM, OS a Kubernetes mají ověřovací program pro datové služby Azure Arc. Tento program poskytuje srovnatelné výsledky testů ze sady nástrojů pro testování certifikace. Testy vyhodnocují kompatibilitu funkcí, výsledky zátěžového testování a výkon a škálovatelnost. Výsledky testu označují použité operační systém, použité distribuce Kubernetes, použitý HW, použitý doplněk CSI a použité třídy úložiště. To pomáhá zákazníkům zvolit pro své požadavky nejlepší třídu úložiště, operační systém, distribuci Kubernetes a hardware. Další informace o tomto programu a výsledcích testů najdete zde.

Veřejný cloud, spravované služby Kubernetes

Pro veřejné cloudové spravované služby Kubernetes můžeme provést následující doporučení: