Läs på engelska

Dela via

Storage-konfiguration

  • Artikel

Kubernetes-lagringsbegrepp

Kubernetes tillhandahåller ett abstraktionslager för infrastruktur över den underliggande virtualiseringsteknikstacken (valfritt) och maskinvaran. Det sätt som Kubernetes abstraherar bort lagring på är via lagringsklasser. När du etablerar en podd kan du ange en lagringsklass för varje volym. När podden etableras anropas etableringsverktyget för lagringsklassen för att etablera lagringen, och sedan skapas en beständig volym på den etablerade lagringen och sedan monteras podden på den beständiga volymen av ett beständigt volymanspråk.

Kubernetes är ett sätt för lagringsinfrastrukturprovidrar att ansluta drivrutiner (kallas även "Addons") som utökar Kubernetes. Lagringstillägg måste uppfylla standarden för containerlagringsgränssnittet. Det finns dussintals tillägg som finns i denna icke-slutgiltiga lista över CSI-drivrutiner. Vilken CSI-drivrutin du använder beror på faktorer som om du kör i en molnbaserad, hanterad Kubernetes-tjänst eller vilken OEM-leverantör du använder för din maskinvara.

Om du vill visa de lagringsklasser som konfigurerats i kubernetes-klustret kör du det här kommandot:

Console 
kubectl get storageclass

Exempel på utdata från ett AKS-kluster (Azure Kubernetes Service):

Console 
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

Du kan få information om en lagringsklass genom att köra det här kommandot:

Console 
kubectl describe storageclass/<storage class name>

Exempel:

Console 
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>

Du kan se de för närvarande etablerade beständiga volymerna och beständiga volymanspråken genom att köra följande kommandon:

Console 
kubectl get persistentvolumes -n <namespace>

kubectl get persistentvolumeclaims -n <namespace>

Exempel på beständiga volymer:

Console 

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

Exempel på beständiga volymanspråk:

Console 

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

Faktorer att tänka på när du väljer lagringskonfiguration

Att välja rätt lagringsklass är viktigt för dataåterhämtning och prestanda. Om du väljer fel lagringsklass kan dina data riskera total dataförlust i händelse av maskinvarufel eller leda till mindre optimala prestanda.

Det finns vanligtvis två typer av lagring:

  • Lokal lagring – lagring som etableras på lokala hårddiskar på en viss nod. Den här typen av lagring kan vara perfekt när det gäller prestanda, men kräver särskilt design för dataredundans genom att replikera data över flera noder.
  • Fjärransluten, delad lagring – lagring som etableras på en fjärrlagringsenhet – till exempel en SAN-, NAS- eller molnlagringstjänst som EBS eller Azure Files. Den här typen av lagring ger vanligtvis dataredundans automatiskt, men är inte så snabb som lokal lagring kan vara.

NFS-baserade lagringsklasser

Beroende på konfigurationen av NFS-servern och lagringsklassetableraren kan du behöva ange supplementalGroups i poddkonfigurationerna för databasinstanser, och du kan behöva ändra NFS-serverkonfigurationen för att använda grupp-ID:n som skickas av klienten (i stället för att leta upp grupp-ID:n på servern med hjälp av det skickade användar-ID:t). Kontakta NFS-administratören för att avgöra om så är fallet.

Egenskapen supplementalGroups tar en matris med värden som du kan ange vid distributionen. Azure Arc-datakontrollanten tillämpar dessa på alla databasinstanser som skapas.

Om du vill ange den här egenskapen kör du följande kommando:

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

Lagringskonfiguration för datastyrenhet

Vissa tjänster i Azure Arc för datatjänster är beroende av att konfigureras för att använda fjärrlagring, delad lagring eftersom tjänsterna inte har möjlighet att replikera data. Dessa tjänster finns i samlingen av datastyrenhetspoddar:

Tjänst Beständiga volymanspråk
OpenSearch <namespace>/logs-logsdb-0, <namespace>/data-logsdb-0
InfluxDB <namespace>/logs-metricsdb-0, <namespace>/data-metricsdb-0
Sql-instans för kontrollant <namespace>/logs-controldb, <namespace>/data-controldb
Api-tjänst för kontrollant <namespace>/data-controller

När datakontrollanten etableras anges lagringsklassen som ska användas för var och en av dessa beständiga volymer genom att antingen skicka --storage-class | -sc-parametern az arcdata dc create till kommandot eller genom att ange lagringsklasserna i den control.json distributionsmallfil som används. Om du använder Azure Portal för att skapa datakontrollanten i direkt anslutet läge har distributionsmallen som du väljer antingen lagringsklassen fördefinierade i mallen eller så kan du välja en mall som inte har någon fördefinierad lagringsklass. Om mallen inte definierar en lagringsklass uppmanar portalen dig att ange en. Om du använder en anpassad distributionsmall kan du ange lagringsklassen.

Distributionsmallarna som tillhandahålls direkt har en standardlagringsklass angiven som är lämplig för målmiljön, men den kan åsidosättas under distributionen. Se de detaljerade stegen för att skapa anpassade konfigurationsmallar för att ändra lagringsklasskonfigurationen för datakontrollantpoddarna vid distributionstillfället.

Om du anger lagringsklassen med parametern --storage-class eller -scanvänds lagringsklassen för både logg- och datalagringsklasser. Om du anger lagringsklasserna i distributionsmallfilen kan du ange olika lagringsklasser för loggar och data.

Viktiga faktorer att tänka på när du väljer en lagringsklass för datakontrollantpoddarna:

  • Du måste använda en fjärr- och delad lagringsklass för att säkerställa datahållbarhet och så att om en podd eller nod dör kan den ansluta igen till den beständiga volymen när podden tas upp igen.
  • De data som skrivs till kontrollantens SQL-instans, måttdatabas och loggar DB är vanligtvis ganska låg volym och inte känslig för svarstid så ultrasnabb prestandalagring är inte kritiskt. Om du har användare som ofta använder Grafana- och Kibana-gränssnitten och du har ett stort antal databasinstanser kan dina användare dra nytta av snabbare lagring.
  • Den lagringskapacitet som krävs är variabel med antalet databasinstanser som du har distribuerat eftersom loggar och mått samlas in för varje databasinstans. Data bevaras i logg- och måttdatabasen i två (2) veckor innan de rensas.
  • Att ändra lagringsklassen efter distributionen är svårt, inte dokumenterat och stöds inte. Se till att välja lagringsklassen korrekt vid distributionstillfället.

Anteckning

Om ingen lagringsklass har angetts används standardlagringsklassen. Det kan bara finnas en standardlagringsklass per Kubernetes-kluster. Du kan ändra standardlagringsklassen.

Lagringskonfiguration för databasinstans

Varje databasinstans har data, loggar och beständiga säkerhetskopieringsvolymer. Lagringsklasserna för dessa beständiga volymer kan anges vid distributionstillfället. Om ingen lagringsklass anges används standardlagringsklassen.

När du skapar en instans med antingen az sql mi-arc create eller az postgres server-arc createfinns det fyra parametrar som du kan använda för att ange lagringsklasserna:

Parameternamn, kort namn Används för
--storage-class-data, -d Lagringsklass för alla datafiler (.mdf, ndf). Om det inte anges är lagringsklassen standard för datakontrollanten.
--storage-class-logs, -g Lagringsklass för alla loggfiler. Om det inte anges är lagringsklassen standard för datakontrollanten.
--storage-class-data-logs Lagringsklass för databastransaktionsloggfilerna. Om det inte anges är lagringsklassen standard för datakontrollanten.
--storage-class-backups Lagringsklass för alla säkerhetskopierade filer. Om det inte anges är lagringsklassen standard för data (--storage-class-data).

Använd en RWX-kompatibel lagringsklass (ReadWriteMany) för säkerhetskopior. Läs mer om åtkomstlägen.

Varning

Om du inte anger någon lagringsklass för säkerhetskopior använder distributionen den lagringsklass som angetts för data. Om den här lagringsklassen inte är RWX-kompatibel kanske återställningen till tidpunkt inte fungerar som önskat.

Tabellen nedan visar sökvägarna i azure SQL Managed Instance-containern som mappas till den beständiga volymen för data och loggar:

Parameternamn, kort namn Sökväg inuti mssql-miaa container beskrivning
--storage-class-data, -d /var/opt Innehåller kataloger för mssql-installationen och andra systemprocesser. Katalogen mssql innehåller standarddata (inklusive transaktionsloggar), felloggar och säkerhetskopieringskataloger
--storage-class-logs, -g /var/log Innehåller kataloger som lagrar konsolutdata (stderr, stdout), annan loggningsinformation om processer i containern

Tabellen nedan visar sökvägarna i PostgreSQL-instanscontainern som mappas till den beständiga volymen för data och loggar:

Parameternamn, kort namn Sökväg i postgres-containern beskrivning
--storage-class-data, -d /var/opt/postgresql Innehåller data och loggkataloger för postgres-installationen
--storage-class-logs, -g /var/log Innehåller kataloger som lagrar konsolutdata (stderr, stdout), annan loggningsinformation om processer i containern

Varje databasinstans har en separat beständig volym för datafiler, loggar och säkerhetskopior. Det innebär att det finns en uppdelning av I/O för var och en av dessa typer av filer som omfattas av hur volymetableren etablerar lagring. Varje databasinstans har sina egna beständiga volymanspråk och beständiga volymer.

Om det finns flera databaser på en viss databasinstans använder alla databaser samma beständiga volymanspråk, beständiga volym och lagringsklass. Alla säkerhetskopior – både differentiella loggsäkerhetskopieringar och fullständiga säkerhetskopior använder samma beständiga volymanspråk och beständiga volym. De beständiga volymanspråken för databasinstanspoddarna visas nedan:

Instans Beständiga volymanspråk
Hanterad Azure SQL-instans <namespace>/logs-<instance name>-0, <namespace>/data-<instance name>-0
Azure Database for PostgreSQL-instans <namespace>/logs--<instance name>-0, <namespace>/data--<instance name>-0
Azure PostgreSQL <namespace>/logs-<instance name>-<ordinal>, <namespace>/data-<instance name>-0

Viktiga faktorer att tänka på när du väljer en lagringsklass för databasinstanspoddarna:

  • Från och med februari 2022-versionen av Azure Arc-datatjänster måste du ange en ReadWriteMany-kompatibel lagringsklass (RWX) för säkerhetskopior. Läs mer om åtkomstlägen. Om ingen lagringsklass har angetts för säkerhetskopior används standardlagringsklassen i kubernetes och om detta inte är RWX-kompatibelt kanske inte distributionen av en hanterad Azure SQL-instans lyckas.
  • Databasinstanser kan distribueras i antingen ett enda poddmönster eller ett mönster för flera poddar. Ett exempel på ett enda poddmönster är en azure SQL-hanterad instans på prisnivån Generell användning prisnivå. Ett exempel på ett mönster för flera poddar är en azure SQL-hanterad instans med hög tillgänglighet Affärskritisk prisnivå. Databasinstanser som distribueras med ett enda poddmönster måste använda en fjärrklass för delad lagring för att säkerställa datahållbarhet och så att om en podd eller nod dör när podden tas upp igen kan den ansluta igen till den beständiga volymen. En azure SQL-hanterad instans med hög tillgänglighet använder däremot AlwaysOn-tillgänglighetsgrupper för att replikera data från en instans till en annan, antingen synkront eller asynkront. Särskilt om data replikeras synkront finns det alltid flera kopior av data – vanligtvis tre kopior. Därför är det möjligt att använda lokala lagrings- eller fjärrklasser för delade lagringsklasser för data och loggfiler. Om du använder lokal lagring bevaras data fortfarande även om det finns en misslyckad podd-, nod- eller lagringsmaskinvara eftersom det finns flera kopior av data. Med den här flexibiliteten kan du välja att använda lokal lagring för bättre prestanda.
  • Databasprestanda är till stor del en funktion av I/O-dataflödet för en viss lagringsenhet. Om din databas är tung på läsningar eller tung på skrivningar bör du välja en lagringsklass med maskinvara som är utformad för den typen av arbetsbelastning. Om din databas till exempel främst används för skrivningar kan du välja lokal lagring med RAID 0. Om databasen främst används för läsningar av en liten mängd "frekventa data", men det finns en stor total lagringsvolym med kalla data, kan du välja en SAN-enhet som kan nivåindela lagring. Att välja rätt lagringsklass skiljer sig inte från att välja vilken typ av lagring du vill använda för valfri databas.
  • Om du använder en lokal lagringsvolymetabler ser du till att de lokala volymer som etableras för data, loggar och säkerhetskopior varje landning på olika underliggande lagringsenheter för att undvika konkurrens på disk-I/O. Operativsystemet bör också finnas på en volym som är monterad på en separat disk(s). Detta är i stort sett samma vägledning som skulle följas för en databasinstans på fysisk maskinvara.
  • Eftersom alla databaser på en viss instans delar ett beständiga volymanspråk och beständiga volymer ska du inte samplacera upptagna databasinstanser på samma databasinstans. Om möjligt kan du avgränsa upptagna databaser på sina egna databasinstanser för att undvika I/O-konkurrens. Använd dessutom nodetikettens mål för att landa databasinstanser på separata noder för att distribuera övergripande I/O-trafik över flera noder. Om du använder virtualisering bör du överväga att distribuera I/O-trafik, inte bara på nodnivå, utan även den kombinerade I/O-aktiviteten som utförs av alla virtuella noddatorer på en viss fysisk värd.

Beräkna lagringskrav

Varje podd som innehåller tillståndskänsliga data använder minst två beständiga volymer – en beständiga volym för data och en annan beständig volym för loggar. Tabellen nedan visar antalet beständiga volymer som krävs för en enda datakontrollant, Azure SQL Managed-instans, Azure Database for PostgreSQL-instans och Azure PostgreSQL HyperScale-instans:

Resurstyp Antal tillståndskänsliga poddar Nödvändigt antal beständiga volymer
Data Controller 4 (control, controldb, logsdb, metricsdb) 4 * 2 = 8
Azure SQL Managed Instance 1 2
Azure PostgreSQL 1 2

Tabellen nedan visar det totala antalet beständiga volymer som krävs för en exempeldistribution:

Resurstyp Antal instanser Nödvändigt antal beständiga volymer
Data Controller 1 4 * 2 = 8
Azure SQL Managed Instance 5 5 * 2 = 10
Azure PostgreSQL 5 5 * 2 = 10
Totalt antal beständiga volymer 8 + 10 + 10 = 28

Den här beräkningen kan användas för att planera lagringen för kubernetes-klustret baserat på lagringsetableren eller miljön. Om den lokala lagringsetableraren till exempel används för ett Kubernetes-kluster med fem (5) noder måste minst lagringsutrymme för 10 beständiga volymer för exempeldistributionen ovanför varje nod användas. På samma sätt är det viktigt att etablera ett AkS-kluster (Azure Kubernetes Service) med fem (5) noder som väljer en lämplig VM-storlek för nodpoolen så att 10 datadiskar kan kopplas. Mer information om hur du storleksanpassar noderna för lagringsbehov för AKS-noder finns här.

Välja rätt lagringsklass

Lokala platser och gränsplatser

Microsoft och dess OEM-, OS- och Kubernetes-partner har ett valideringsprogram för Azure Arc-datatjänster. Det här programmet ger jämförbara testresultat från ett verktyg för certifieringstestning. Testerna utvärderar funktionskompatibilitet, stresstestresultat samt prestanda och skalbarhet. Testresultaten anger vilket operativsystem som används, Kubernetes-distribution som används, HW som används, CSI-tillägget som används och de lagringsklasser som används. Detta hjälper kunderna att välja den bästa lagringsklassen, operativsystemet, Kubernetes-distributionen och maskinvaran för sina behov. Mer information om det här programmet och testresultat finns här.

Offentliga moln, hanterade Kubernetes-tjänster

För offentliga molnbaserade, hanterade Kubernetes-tjänster kan vi göra följande rekommendationer:

Offentlig molntjänst Rekommendation
Azure Kubernetes Service (AKS) Azure Kubernetes Service (AKS) har två typer av lagring – Azure Files och Azure Managed Disks. Varje typ av lagring har två pris-/prestandanivåer – standard (HDD) och Premium (SSD). Därför är azurefile de fyra lagringsklasserna som tillhandahålls i AKS (Standardnivå för Azure Files), azurefile-premium (Azure Files premiumnivå), default (Standardnivå för Azure Disks) och managed-premium (Azure Disks Premium-nivå). Standardlagringsklassen är default (Standardnivå för Azure Disks). Det finns betydande prisskillnader mellan de typer och nivåer som du bör överväga. För produktionsarbetsbelastningar med höga prestandakrav rekommenderar vi att du använder managed-premium för alla lagringsklasser. För utvecklings-/testarbetsbelastningar, konceptbevis osv. där kostnaden är ett övervägande är det billigaste azurefile alternativet. Alla fyra alternativen kan användas för situationer som kräver fjärransluten, delad lagring eftersom de alla är nätverksanslutna lagringsenheter i Azure. Läs mer om AKS Storage.
AWS Elastic Kubernetes Service (EKS) Amazons Elastic Kubernetes Service har en primär lagringsklass – baserad på EBS CSI-lagringsdrivrutinen. Detta rekommenderas för produktionsarbetsbelastningar. Det finns en ny lagringsdrivrutin – EFS CSI-lagringsdrivrutin – som kan läggas till i ett EKS-kluster, men den är för närvarande i ett betasteg och kan komma att ändras. Även om AWS säger att den här lagringsdrivrutinen stöds för produktion rekommenderar vi inte att du använder den eftersom den fortfarande är i betaversion och kan komma att ändras. EBS-lagringsklassen är standard och kallas gp2. Läs mer om EKS Storage.
Google Kubernetes Engine (GKE) Google Kubernetes Engine (GKE) har bara en lagringsklass som heter standard. Den här klassen används för GCE-beständiga diskar. Som den enda är det också standardinställningen. Även om det finns en lokal, statisk volymetabler för GKE som du kan använda med direktanslutna SSD:er rekommenderar vi inte att du använder den eftersom den inte underhålls eller stöds av Google. Läs mer om GKE-lagring.