Delen via

Belangrijke overwegingen voor Azure Data Lake Storage

  • Artikel

Azure Storage biedt diverse opslagopties voor uw gegevens. Dit artikel bevat overwegingen om u te helpen bij het kiezen van de juiste toegangslaag, zodat u kosten en prestaties kunt verdelen. Ook wordt het levenscyclusbeheer van Storage beschreven, inclusief functies en aanbevolen procedures om u te helpen de toegangslagen effectief te gebruiken.

Levenscyclusbeheer

Azure Storage biedt verschillende toegangslagen die u kunt gebruiken om blobobjectgegevens op te slaan. Kies de laag die het beste past bij uw workload om de kosten te optimaliseren.

  • Gebruik een dynamische laag om veelgebruikte gegevens op te slaan.

  • Gebruik een statische laag om gegevens die niet vaak worden geopend, op te slaan. In deze laag worden gegevens minstens 30 dagen opgeslagen.

  • Gebruik een koude laag om onregelmatig geopende of gewijzigde gegevens op te slaan. In deze laag worden gegevens gedurende ten minste 90 dagen opgeslagen. De koude laag heeft lagere opslagkosten en hogere toegangskosten dan de statische laag.

  • Gebruik een archieflaag om zelden geopende gegevens op te slaan. In deze laag worden gegevens gedurende ten minste 180 dagen opgeslagen. Toegang tot deze gegevens kan flexibele latentievereisten hebben, wat betekent dat het uren kan duren om gegevens op te halen.

Belangrijk

De onlinetoegangslagen (hot, cool en cold) hebben geen concessies nodig op het gebied van betrouwbaarheid, beveiliging, operationele uitmuntendheid of prestatie-efficiëntie. Daarom moet u uw beslissing baseren op de kosten voor elke blob. Houd rekening met de grootte van de toegangsdata van uw workload, uw operationele interacties en de tijd voordat de blob wordt verwijderd. Selecteer de juiste laag voor elke blob op basis van deze factoren. Zie Kosten voor Azure Blob Storage plannen en beheren voor meer informatie.

Houd rekening met de volgende factoren wanneer u toegangsmodi gebruikt.

  • Stel alleen de hete en koele toegangslagen in op accountniveau. Het accountniveau biedt geen ondersteuning voor de archieftoegangslaag.

  • Stel de hete, koele en archieflagen op blobniveau in, zowel tijdens als na het uploaden.

  • Gegevens in de statische en koude lagen hebben iets lagere beschikbaarheid, maar deze lagen bieden functies die vergelijkbaar zijn met die van de dynamische laag, zoals hoge duurzaamheid, ophaallatentie en doorvoer. Voor gegevens in de statische of koude lagen zijn lagere beschikbaarheid en hogere toegangskosten acceptabel voor lagere opslagkosten in vergelijking met de dynamische laag.

  • Archiefopslag slaat gegevens offline op en biedt de laagste opslagkosten. Maar er worden ook de hoogste kosten voor gegevensrehydratatie en toegang in rekening gebracht.

Zie Access-lagen voor blobgegevens voor meer informatie.

Belangrijk

Gebruik voor analyses op cloudschaal een aangepaste microservice om levenscyclusbeheerte implementeren. Houd zorgvuldig rekening met de impact van het verplaatsen van door de gebruiker ontdekte gegevens naar koele opslag. Verplaats secties van uw data lake alleen naar de koele laag voor duidelijke werkbelastingen.

Data Lake-connectiviteit

Elke data lake moet privé-eindpunten gebruiken die u integreert in het virtuele netwerk van uw gegevenslandingszone. Als u toegang wilt bieden tussen landingszones, verbindt u uw gegevenslandingszones via peering van virtuele netwerken. Deze verbinding biedt een optimale oplossing vanuit zowel kosten- als toegangsbeheerperspectief.

Zie Privé-eindpunten en landingszone voor gegevensbeheer naar de landingszone voor gegevens voor meer informatie.

Belangrijk

Een gegevenslandingszone heeft toegang tot gegevens in een andere landingszone via peering van virtuele netwerken. Met privé-eindpunten wordt de verbinding tot stand gebracht die is gekoppeld aan elk Data Lake-account. U wordt aangeraden alle openbare toegang tot uw meren uit te schakelen en privé-eindpunten te gebruiken. Uw platformbewerkingsteam moet de netwerkconnectiviteit in uw datalandingszones beheren.

Containers voorlopig verwijderen

Soft delete voor containers helpt uw gegevens te beschermen tegen onbedoelde of schadelijke verwijdering. Als u voorlopig verwijderen van containers inschakelt voor uw opslagaccount, behoudt Storage verwijderde containers en de inhoud ervan gedurende een opgegeven tijdsduur. Tijdens de gegevensretentieperiode kunt u eerder verwijderde containers herstellen. Met deze actie worden ook blobs hersteld die zich in die container bevonden toen deze werd verwijderd.

Schakel de volgende functies voor gegevensbeveiliging in om end-to-end blobgegevensbeveiliging te verbeteren:

Waarschuwing

Nadat u een opslagaccount hebt verwijderd, kunt u de verwijdering niet ongedaan maken. Voorlopig verwijderen van containers beschermt niet tegen het verwijderen van opslagaccounts, alleen tegen het verwijderen van containers binnen een account. Als u een opslagaccount wilt beveiligen tegen verwijdering, configureert u een vergrendeling voor de opslagaccountresource. Zie Resources vergrendelen om onverwachte wijzigingente voorkomen voor meer informatie.

Controleren

Verzend in een gegevenslandingszone alle bewaking naar uw Azure-abonnement voor landingszonebeheer voor analyse.

Zie Azure-resources bewaken met Azure Monitor en Blob Storage-voor meer informatie.

Logboekvermeldingen worden alleen gemaakt voor aanvragen voor het service-eindpunt. De volgende typen geverifieerde aanvragen worden vastgelegd:

  • Geslaagde aanvragen
  • Mislukte verzoeken, waaronder time-outs, limitering, netwerkproblemen, autorisatieproblemen en andere fouten
  • Aanvragen die gebruikmaken van een Shared Access Signature (SAS) of OAuth, inclusief mislukte en geslaagde aanvragen
  • Aanvragen voor analysegegevens, zoals klassieke logboekgegevens in de $logs container en metrische gegevens van klasse in de $metric tabellen

Aanvragen die door de opslagservice zelf worden gedaan, zoals het maken of verwijderen van logboeken, worden niet geregistreerd. De volgende typen anonieme aanvragen worden geregistreerd:

  • Geslaagde aanvragen
  • Serverfouten
  • Time-outfouten voor zowel de client als de server
  • Mislukte HTTP GET-aanvragen met foutcode 304 (Not Modified)

Andere mislukte anonieme aanvragen worden niet geregistreerd.

Belangrijk

Stel uw standaardbewakingsbeleid in om opslag te controleren en logboeken te verzenden naar uw bedrijfsbeheerabonnement.

Beveiliging van Data Lake-zone

We raden de volgende beveiligingspatronen aan voor Data Lake-zones:

  • Ruw gebruik staat alleen toegang tot gegevens toe door gebruik te maken van security principal-namen (SPN's). U wordt aangeraden beheerde identiteiten te gebruiken.

  • Verrijkt gebruik staat alleen toegang tot de gegevens toe met behulp van SPN's. U wordt aangeraden beheerde identiteiten te gebruiken.

  • Beheerd gebruik biedt toegang tot gegevens via SPN's en UPN's (User Principal Names).

Zie Access Control-model in Data Lake Storagevoor meer informatie.

Volgende stap