Aanbevolen procedures voor opslag en back-ups in Azure Kubernetes Service (AKS)

Wanneer u clusters in Azure Kubernetes Service (AKS) maakt en beheert, hebben uw toepassingen vaak opslag nodig. Zorg ervoor dat u inzicht hebt in de behoeften en toegangsmethoden voor pods, zodat u de beste opslag voor uw toepassing kunt selecteren. De grootte van het AKS-knooppunt kan van invloed zijn op uw opslagkeuzen. Plan manieren om een back-up te maken en het herstelproces voor gekoppelde opslag te testen.

Dit artikel met aanbevolen procedures is gericht op opslagoverwegingen voor clusteroperators. In dit artikel leert u het volgende:

Het juiste opslagtype kiezen

Richtlijnen voor best practices

Inzicht in de behoeften van uw toepassing om de juiste opslag te kiezen. Gebruik hoogwaardige opslag met SSD-ondersteuning voor productieworkloads. Plan opslag op basis van een netwerk wanneer u meerdere gelijktijdige verbindingen nodig hebt.

Toepassingen vereisen vaak verschillende typen en snelheden van opslag. Bepaal het meest geschikte opslagtype door de volgende vragen te stellen.

• Hebben uw toepassingen opslag nodig die verbinding maakt met afzonderlijke pods?
• Hebben uw toepassingen opslag nodig die wordt gedeeld over meerdere pods?
• Is de opslag voor alleen-lezentoegang tot gegevens?
• Wordt de opslag gebruikt om grote hoeveelheden gestructureerde gegevens te schrijven?

De volgende tabel bevat een overzicht van de beschikbare opslagtypen en de bijbehorende mogelijkheden:

AKS biedt twee primaire typen beveiligde opslag voor volumes die worden ondersteund door Azure Disks of Azure Files. Beide gebruiken de standaard Azure Storage Service Encryption (SSE) die data-at-rest versleutelt. Schijven kunnen niet worden versleuteld met Behulp van Azure Disk Encryption op AKS-knooppuntniveau. Met Azure Files-shares is er geen limiet voor het aantal dat op een knooppunt kan worden gekoppeld.

Zowel Azure Files als Azure Disks zijn beschikbaar in de prestatielagen Standard en Premium:

• Premium-schijven
  • Ondersteund door ssd's (solid-state disks) met hoge prestaties.
  • Aanbevolen voor alle productie-workloads.
• Standaardschijven
  • Ondersteund door gewone draaiende schijven (HDD's).
  • Geschikt voor archivering of onregelmatig geopende gegevens.

Hoewel de standaardopslaglaag voor het Azure Disk CSI-stuurprogramma Premium SSD is, kan uw aangepaste StorageClass Premium SSD, Standard SSD of Standard HDD gebruiken.

Inzicht in de prestatiebehoeften en toegangspatronen van de toepassing om de juiste opslaglaag te kiezen. Zie het overzicht van Azure Managed Disks voor meer informatie over managed disks-grootten en prestatielagen.

Opslagklassen maken en gebruiken om toepassingsbehoeften te definiëren

Definieer het gewenste type opslag met behulp van Kubernetes-opslagklassen. Er wordt vervolgens naar de opslagklasse verwezen in de pod- of implementatiespecificatie. Definities van opslagklassen werken samen om de juiste opslag te maken en deze te verbinden met pods.

Zie Storage-klassen in AKS voor meer informatie.

De grootte van de knooppunten voor opslagbehoeften aanpassen

Richtlijnen voor best practices

Elke knooppuntgrootte ondersteunt een maximum aantal schijven. Verschillende knooppuntgrootten bieden ook verschillende hoeveelheden lokale opslag en netwerkbandbreedte. Plan uw toepassingsvereisten op de juiste manier om de juiste grootte van knooppunten te implementeren.

AKS-knooppunten worden uitgevoerd als verschillende typen en grootten van azure-VM's. Elke VM-grootte biedt:

• Een andere hoeveelheid kernresources, zoals CPU en geheugen.
• Een maximum aantal schijven dat kan worden gekoppeld.

De opslagprestaties variëren ook tussen VM-grootten voor de maximale lokale en gekoppelde schijf-IOPS (invoer-/uitvoerbewerkingen per seconde).

Als uw toepassingen Azure Disks als opslagoplossing vereisen, kunt u een geschikte VM-grootte voor knooppunten strategiseren. Opslagmogelijkheden en CPU- en geheugenbedragen spelen een belangrijke rol bij het bepalen van een VM-grootte.

Zo zijn zowel de Standard_B2ms alsStandard_DS2_v2 VM-grootten een vergelijkbare hoeveelheid CPU- en geheugenbronnen, maar de mogelijke opslagprestaties verschillen:

In dit voorbeeld biedt de Standard_DS2_v2 twee keer zoveel gekoppelde schijven en drie tot vier keer de hoeveelheid IOPS en schijfdoorvoer. Als u alleen kernresources en vergeleken kosten hebt vergeleken, hebt u mogelijk de Standard_B2ms VM-grootte gekozen met slechte opslagprestaties en -beperkingen.

Werk samen met uw ontwikkelteam van uw toepassing om inzicht te hebben in de opslagcapaciteit en prestatiebehoeften. Kies de juiste VM-grootte voor de AKS-knooppunten om te voldoen aan de prestatiebehoeften of deze te overschrijden. Regelmatig basislijntoepassingen om de VM-grootte zo nodig aan te passen.

Zie Grootten voor virtuele Linux-machines in Azure voor meer informatie over beschikbare VM-grootten.

Overweeg tijdelijke NVMe-gegevensschijven voor maximale prestaties

Richtlijnen voor best practices

Overweeg tijdelijke NVMe-gegevensschijven wanneer u de hoogste opslagdoorvoer en IOPS nodig hebt, en uw workload kan de tijdelijke aard van de lokale knooppuntopslag tolereren. Tijdelijke NVMe-gegevensschijven bieden opslag met lage latentie, met host gekoppelde opslag die de hoogste IOPS en doorvoer levert die beschikbaar is in Azure. NVMe-schijven zijn beschikbaar op L-serie, E-serie en GPU-VM's, met uitbreidingsondersteuning voor de nieuwere Azure VM v6- en v7-families, zoals de D-serie, F-serie, H-serie.

Met NVMe-ondersteunde opslag worden workloads verbeterd waarvoor snelle caching, tijdelijke opslag of tijdelijke gegevensverwerking nodig is. Het elimineert de afhankelijkheid van externe schijven met hoge prestaties, die doorgaans de grootste en meest dure VM-configuraties vereisen om optimale prestaties te bereiken.

Veelvoorkomende scenario's die profiteren van tijdelijke NVMe-gegevensschijven zijn:

• AI-trainingspijplijnen of inferentiepijplijnen die grote gegevenssets of controlepunten tussen iteraties plaatsen
• Krachtige databases of streamingmachines die replica's of logboeken binnen pods onderhouden
• Batchanalyse-taken waarvoor tijdelijke werkruimte of tijdelijke shuffle-opslag is vereist

Omdat NVMe-gegevens aan de knooppuntinstantie zijn gekoppeld, moet u plannen voor pod-onderbrekingsbudgetten en ervoor zorgen dat uw toepassing snel kan worden herbouwd uit duurzame opslag of replicatie. Gegevens die op deze schijven worden geplaatst, gaan verloren wanneer een knooppunt wordt gedealloceerd, heringericht of faalt.

Zie De aanbevolen procedures voor kortstondige NVMe-gegevensschijven in Azure Kubernetes Service (AKS) voor verdere aanbevelingen voor tijdelijke NVMe-gegevensschijven. Als u NVMe-capaciteit beschikbaar wilt maken voor pods, gebruikt u Azure Container Storage, waarmee u tijdelijke of permanente volumes kunt organiseren en maken die worden ondersteund door lokale NVMe-schijven. Zie Azure Container Storage gebruiken met AKS voor implementatierichtlijnen.

Gebruik de gedistribueerde accelerator voor cloudopslag (preview)

Richtlijnen voor best practices

Overweeg een gedistribueerde accelerator voor cloudopslag (DACS) wanneer toepassingen herhaaldelijk modelbestanden of gegevenssets lezen uit Azure Blob Storage. Plan cachecapaciteit, warm-up en herstel rond de toegangspatronen van uw workload.

DACS maakt gebruik van lokale NVMe-schijven op Linux-cacheknooppunten om Azure Blob-gegevens in de cache op te cachen. Het kan de laadtijd van het model voor AI-inferentie verminderen en herhaalde leesbewerkingen van gegevenssets versnellen voor training. U schakelt DACS in en beheert deze via Azure Container Storage. DACS maakt geen permanente volumes of opslagklassen aan.

Wanneer u DACS plant en uitvoert:

• Cacheopslag toewijzen. Gebruik Linux-cacheknooppunten met lokale NVMe-schijven die zijn toegewezen aan DACS. Cachevereisten kunnen die schijven formatteren. Bewaar labels voor cacheknooppunten in de configuratie van de node-pool, zodat ze de vervanging van knooppunten overleven.
• Grootte voor de actieve werkset. Houd rekening met extra marge voor overlappende modelversies en wijzigingen in gegevenssets. Houd rekening met gelijktijdige lezers, knooppunt-CPU en geheugen en netwerkbandbreedte, niet alleen NVMe-capaciteit.
• Plan voor cold reads. Overweeg om modelgegevens vooraf op te halen voordat implementaties voor inferentie of scale-out worden uitgevoerd. Controleer cachetreffers voordat u de gelijktijdigheid verhoogt. Prefetch houdt gegevens niet vast en verwijdering, vervanging van knooppunten of onderhoud kan een andere opwarmactie vereisen. Plan extra Blob-verkeer wanneer gegevens in de cache niet beschikbaar zijn.
• Toepassings- en cachegedrag meten. Vergelijk koude en warme leesacties bij de verwachte mate van gelijktijdigheid. Controleer clientcachetreffers, aanvragen van cacheservers, latentie, capaciteit en Blob-verkeer. Geslaagde of snellere leesbewerkingen alleen bewijzen geen cachegebruik, omdat clients kunnen terugvallen op Azure Blob Storage.
• Zorg dat gezaghebbende gegevens duurzaam behouden blijven. Sla modelbestanden en gegevenssets op in Azure Blob Storage, bij voorkeur bij onveranderbare, geversiede paden. Gecachte data is vluchtig en wordt niet gerepliceerd voor duurzame opslag. Gebruik DACS niet als permanente opslag voor trainingsuitvoer of checkpoints.

Zie voor implementatie- en operationele richtlijnen Gedistribueerde accelerator beheren voor cloudopslag en Gedistribueerde accelerator bewaken voor cloudopslag.

Volumes dynamisch inrichten

Richtlijnen voor best practices

Als u de beheeroverhead wilt verminderen en schalen wilt mogelijk maken, moet u voorkomen dat permanente volumes statisch worden gecreëerd en toegewezen. Gebruik dynamische inrichting Definieer in uw opslagklassen het juiste reclaimbeleid om onnodige opslagkosten te minimaliseren zodra pods zijn verwijderd.

Als u opslag wilt koppelen aan pods, gebruikt u permanente volumes. Permanente volumes kunnen handmatig of dynamisch worden gemaakt. Door handmatig permanente volumes te maken, verhoogt u de beheeroverhead en beperkt u uw mogelijkheid om op te schalen. Richt in plaats daarvan permanent volume dynamisch in om opslagbeheer te vereenvoudigen en uw toepassingen naar behoefte te laten groeien en schalen.

Met een permanente volumeclaim (PVC) kunt u waar nodig dynamisch opslag maken. Onderliggende Azure-schijven worden gemaakt als pods deze aanvragen. Vraag in de poddefinitie een volume aan dat moet worden gemaakt en gekoppeld aan een toegewezen koppelpad.

Zie Permanente volumesclaims voor de concepten over het dynamisch maken en gebruiken van volumes.

Als u deze volumes in actie wilt zien, raadpleegt u hoe u dynamisch een permanent volume maakt en gebruikt met Azure Disks of Azure Files.

Stel als onderdeel van uw opslagklassedefinities de juiste reclaimPolicy in. Met deze reclaimPolicy bepaalt u het gedrag van de onderliggende Azure-opslagresource wanneer de pod wordt verwijderd. De onderliggende opslagresource kan worden verwijderd of bewaard voor toekomstig gebruik van pods. Stel de reclaimPolicy in om te behouden of te verwijderen.

Begrijp de behoeften van uw toepassing en implementeer regelmatig controles op bewaarde opslag om de hoeveelheid ongebruikte en gefactureerde opslag te minimaliseren.

Zie het beleid voor het vrijmaken van opslag voor meer informatie over opties voor opslagklassen.

Uw gegevens beveiligen en er een back-up van maken

Richtlijnen voor best practices

Maak een back-up van uw gegevens met behulp van een geschikt hulpprogramma voor uw opslagtype, zoals Velero of Azure Backup. Controleer de integriteit en beveiliging van deze back-ups.

Wanneer uw toepassingen gegevens opslaan en gebruiken die zijn opgeslagen op schijven of in bestanden, moet u regelmatig back-ups of momentopnamen van die gegevens maken. Azure Disks kan gebruikmaken van ingebouwde momentopnametechnologieën. Mogelijk moeten uw toepassingen schrijfbewerkingen naar schijf flushen voordat u de momentopnamebewerking uitvoert. Velero kan een back-up maken van permanente volumes, samen met extra clusterbronnen en configuraties. Als u de status niet uit uw toepassingen kunt verwijderen, maakt u een back-up van de gegevens uit permanente volumes en test u regelmatig de herstelbewerkingen om de gegevensintegriteit en de vereiste processen te controleren.

Begrijp de beperkingen van de verschillende benaderingen voor databack-ups en of u uw gegevens moet stilzetten voordat u een momentopname maakt. Met gegevensback-ups kunt u uw toepassingsomgeving van clusterimplementatie niet per se herstellen. Zie Best practices voor bedrijfscontinuïteit en herstel na noodgevallen in AKS voor meer informatie over deze scenario's.

Als u DACS gebruikt, beveiligt u de canonieke modelbestanden en gegevenssets in Azure Blob Storage in plaats van een back-up te maken van tijdelijke cache-inhoud. Bewaar de cacheconfiguratie in versiebeheer en test het opnieuw maken en verwarmen van de cache na vervanging van knooppunten of clusterherstel. DACS is geen back-upoplossing.

Volgende stappen

Dit artikel is gericht op aanbevolen procedures voor opslag in AKS. Zie Opslagconcepten voor toepassingen in AKS voor meer informatie over de basisprincipes van opslag in Kubernetes.

Zie de volgende artikelen voor meer informatie over gedistribueerde caching voor Azure Blob-gegevens:

• Wat is een gedistribueerde accelerator voor cloudopslag? (voorvertoning)
• Gedistribueerde accelerator voor cloudopslag beheren
• Gedistribueerde accelerator voor cloudopslag bewaken