Storage-konfiguration
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:
kubectl get storageclass
Exempel på utdata från ett AKS-kluster (Azure Kubernetes Service):
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:
kubectl describe storageclass/<storage class name>
Exempel:
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:
kubectl get persistentvolumes -n <namespace>
kubectl get persistentvolumeclaims -n <namespace>
Exempel på beständiga volymer:
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:
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:
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.
Kommentar
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. |