Overzicht van Azure-pagina-blobs

Azure Storage biedt drie typen blobopslag: blok-blobs, toevoeg-blobs en pagina-blobs. Blok-blobs bestaan uit blokken en zijn ideaal voor het opslaan van tekst- of binaire bestanden en voor het efficiënt uploaden van grote bestanden. Toevoeg-blobs bestaan ook uit blokken, maar ze zijn geoptimaliseerd voor toevoegbewerkingen, waardoor ze ideaal zijn voor logboekregistratiescenario's. Pagina-blobs bestaan uit 512 bytepagina's tot 8 TB in totale grootte en zijn ontworpen voor frequente willekeurige lees-/schrijfbewerkingen. Pagina-blobs vormen de basis van Azure IaaS-schijven. Dit artikel is gericht op het uitleggen van de functies en voordelen van pagina-blobs.

Pagina-blobs zijn een verzameling van 512 bytepagina's, die de mogelijkheid bieden om willekeurige bereiken van bytes te lezen/schrijven. Daarom zijn pagina-blobs ideaal voor het opslaan van op index gebaseerde en sparse-gegevensstructuren, zoals besturingssysteem- en gegevensschijven voor virtuele machines en databases. Azure SQL DB gebruikt bijvoorbeeld pagina-blobs als de onderliggende permanente opslag voor de bijbehorende databases. Bovendien worden pagina-blobs ook vaak gebruikt voor bestanden met op bereik gebaseerde updates.

De belangrijkste functies van Azure-pagina-blobs zijn de REST-interface, de duurzaamheid van de onderliggende opslag en de naadloze migratiemogelijkheden naar Azure. Deze functies worden uitvoeriger besproken in de volgende sectie. Daarnaast worden Azure-pagina-blobs momenteel ondersteund op twee typen opslag: Premium Storage en Standard Storage. Premium Storage is speciaal ontworpen voor workloads die consistente hoge prestaties en lage latentie vereisen, waardoor Premium-pagina-blobs ideaal zijn voor opslagscenario's met hoge prestaties. Standard-opslagaccounts zijn rendabeler voor het uitvoeren van niet-gevoelige workloads met latentie.

Beperkingen

Pagina-blobs kunnen alleen gebruikmaken van de dynamische-toegangslaag . Ze kunnen de lagen Statisch of Archief niet gebruiken. Zie dynamische, statische en archieftoegangslagen voor blobgegevens voor meer informatie over toegangslagen.

Gebruiksvoorbeelden

Laten we een paar use cases bespreken voor pagina-blobs die beginnen met Azure IaaS-schijven. Azure-pagina-blobs vormen de backbone van het platform voor virtuele schijven voor Azure IaaS. Zowel Azure-besturingssysteem- als gegevensschijven worden geïmplementeerd als virtuele schijven waar gegevens permanent worden bewaard in het Azure Storage-platform en vervolgens worden geleverd aan de virtuele machines voor maximale prestaties. Azure Disks blijven behouden in de Hyper-V-VHD-indeling en worden opgeslagen als een pagina-blob in Azure Storage. Naast het gebruik van virtuele schijven voor Virtuele Azure IaaS-machines, schakelen pagina-blobs ook PaaS- en DBaaS-scenario's in, zoals de Azure SQL DB-service, die momenteel pagina-blobs gebruikt voor het opslaan van SQL-gegevens, waardoor snelle willekeurige lees-/schrijfbewerkingen voor de database mogelijk zijn. Een ander voorbeeld is als u een PaaS-service hebt voor gedeelde mediatoegang voor samenwerkingstoepassingen voor het bewerken van video's, kunnen pagina-blobs snel toegang krijgen tot willekeurige locaties in de media. Het maakt het ook mogelijk om snel en efficiënt dezelfde media door meerdere gebruikers te bewerken en samen te voegen.

First party-Microsoft-services zoals Azure Site Recovery, Azure Backup en veel externe ontwikkelaars hebben toonaangevende innovaties geïmplementeerd met behulp van de REST-interface van paginablob. Hieronder volgen enkele van de unieke scenario's die zijn geïmplementeerd in Azure:

• Toepassingsgericht incrementeel momentopnamebeheer: toepassingen kunnen gebruikmaken van pagina-blobmomentopnamen en REST API's om de toepassingscontrolepunten op te slaan zonder kostbare duplicatie van gegevens. Azure Storage ondersteunt lokale momentopnamen voor pagina-blobs. Hiervoor hoeft de hele blob niet te worden gekopieerd. Deze API's voor openbare momentopnamen maken ook het openen en kopiëren van verschillen tussen momentopnamen mogelijk.
• Livemigratie van toepassingen en gegevens van on-premises naar de cloud: kopieer de on-premises gegevens en gebruik REST API's om rechtstreeks naar een Azure-pagina-blob te schrijven terwijl de on-premises VM blijft worden uitgevoerd. Zodra het doel is opgepikt, kunt u snel een failover naar azure-VM uitvoeren met behulp van die gegevens. Op deze manier kunt u uw VM's en virtuele schijven migreren van on-premises naar de cloud met minimale downtime, omdat de gegevensmigratie op de achtergrond plaatsvindt terwijl u de VIRTUELE machine blijft gebruiken en de downtime die nodig is voor failover kort is (in minuten).
• Gedeelde toegang op basis van SAS, waarmee scenario's zoals meerdere lezers en één schrijver met ondersteuning voor gelijktijdigheidsbeheer mogelijk zijn.

Niet-beheerde schijven worden buiten gebruik gesteld. Zie Uw niet-beheerde Azure-schijven migreren op 30 september 2025 voor meer informatie.

Prijzen

Beide typen opslag die worden aangeboden met pagina-blobs hebben hun eigen prijsmodel. Premium-pagina-blobs volgen het prijsmodel voor beheerde schijven, terwijl standaardpagina-blobs worden gefactureerd voor de gebruikte grootte en bij elke transactie. Zie de pagina met prijzen voor Azure Page Blobs voor meer informatie.

Functies voor pagina-blobs

REST-API

Raadpleeg het volgende document om aan de slag te gaan met ontwikkelen met behulp van pagina-blobs. Bekijk bijvoorbeeld hoe u toegang krijgt tot pagina-blobs met behulp van storage-clientbibliotheek voor .NET.

In het volgende diagram worden de algemene relaties tussen account, containers en pagina-blobs beschreven.

Een lege pagina-blob van een opgegeven grootte maken

Haal eerst een verwijzing naar een container op. Als u een pagina-blob wilt maken, roept u de methode GetPageBlobClient aan en roept u vervolgens de methode PageBlobClient.Create aan . Geef de maximale grootte door voor de blob die u wilt maken. Deze grootte moet een veelvoud van 512 bytes zijn.

long OneGigabyteAsBytes = 1024 * 1024 * 1024;

BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);

var blobContainerClient =
    blobServiceClient.GetBlobContainerClient(Constants.containerName);

var pageBlobClient = blobContainerClient.GetPageBlobClient("0s4.vhd");

pageBlobClient.Create(16 * OneGigabyteAsBytes);

Het formaat van een pagina-blob wijzigen

Als u het formaat van een pagina-blob wilt wijzigen nadat u deze hebt gemaakt, gebruikt u de methode Formaat wijzigen . De aangevraagde grootte moet een veelvoud van 512 bytes zijn.

pageBlobClient.Resize(32 * OneGigabyteAsBytes);

Pagina's schrijven naar een pagina-blob

Als u pagina's wilt schrijven, gebruikt u de methode PageBlobClient.UploadPages .

pageBlobClient.UploadPages(dataStream, startingOffset);

Hiermee kunt u een sequentiële set pagina's schrijven tot 4 MB. De offset die naar wordt geschreven, moet beginnen op een grens van 512 byte (startOffset % 512 == 0) en eindigt op een grens van 512 - 1.

Zodra een schrijfaanvraag voor een sequentiële set pagina's in de blobservice slaagt en wordt gerepliceerd voor duurzaamheid en tolerantie, is de schrijfbewerking doorgevoerd en wordt het succes teruggezet naar de client.

In het onderstaande diagram ziet u twee afzonderlijke schrijfbewerkingen:

1. Een schrijfbewerking vanaf offset 0 van lengte 1024 bytes
2. Een schrijfbewerking vanaf offset 4096 van lengte 1024

Pagina's lezen vanuit een pagina-blob

Als u pagina's wilt lezen, gebruikt u de methode PageBlobClient.Download om een bereik van bytes uit de pagina-blob te lezen.

var pageBlob = pageBlobClient.Download(new HttpRange(bufferOffset, rangeSize));

Hiermee kunt u de volledige blob of het bereik van bytes downloaden vanaf elke offset in de blob. Bij het lezen hoeft de offset niet te beginnen op een veelvoud van 512. Wanneer u bytes leest vanaf een NUL-pagina, retourneert de service nul bytes.

In de volgende afbeelding ziet u een leesbewerking met een offset van 256 en een bereikgrootte van 4352. Geretourneerde gegevens zijn oranje gemarkeerd. Nullen worden geretourneerd voor NUL-pagina's.

Als u een sparse gevulde blob hebt, kunt u de geldige paginaregio's downloaden om te voorkomen dat u betaalt voor uitgaand verkeer van nul bytes en om de downloadlatentie te verminderen.

Gebruik PageBlobClient.GetPageRanges om te bepalen welke pagina's worden ondersteund door gegevens. Vervolgens kunt u de geretourneerde bereiken inventariseren en de gegevens in elk bereik downloaden.

IEnumerable<HttpRange> pageRanges = pageBlobClient.GetPageRanges().Value.PageRanges;

foreach (var range in pageRanges)
{
    var pageBlob = pageBlobClient.Download(range);
}

Een pagina-blob leasen

Met de lease-blobbewerking wordt een vergrendeling op een blob tot stand genomen en beheerd voor schrijf- en verwijderbewerkingen. Deze bewerking is handig in scenario's waarin een pagina-blob wordt geopend vanaf meerdere clients om ervoor te zorgen dat slechts één client tegelijk naar de blob kan schrijven. Azure Disks maakt bijvoorbeeld gebruik van dit leasemechanisme om ervoor te zorgen dat de schijf alleen wordt beheerd door één virtuele machine. De vergrendelingsduur kan 15 tot 60 seconden zijn of kan oneindig zijn. Zie de documentatie hier voor meer informatie.

Naast uitgebreide REST API's bieden pagina-blobs ook gedeelde toegang, duurzaamheid en verbeterde beveiliging. In de volgende alinea's zullen we deze voordelen nader bespreken.

Gelijktijdige toegang

Met de REST API voor pagina-blobs en het leasemechanisme kunnen toepassingen toegang krijgen tot de pagina-blob van meerdere clients. Stel dat u een gedistribueerde cloudservice moet bouwen die opslagobjecten deelt met meerdere gebruikers. Het kan een webtoepassing zijn die een grote verzameling afbeeldingen aan verschillende gebruikers biedt. Eén optie voor het implementeren hiervan is het gebruik van een virtuele machine met gekoppelde schijven. Het nadeel hiervan is onder andere: (i) de beperking dat een schijf alleen aan één VIRTUELE machine kan worden gekoppeld, waardoor de schaalbaarheid, flexibiliteit en toenemende risico's worden beperkt. Als er een probleem is met de VM of de service die op de VM wordt uitgevoerd, is de installatiekopieën vanwege de lease niet toegankelijk totdat de lease verloopt of is verbroken; en (ii) Extra kosten voor het hebben van een IaaS-VM.

Een alternatieve optie is om de pagina-blobs rechtstreeks te gebruiken via Azure Storage REST API's. Deze optie elimineert de noodzaak van dure IaaS-VM's, biedt volledige flexibiliteit van directe toegang van meerdere clients, vereenvoudigt het klassieke implementatiemodel door de noodzaak om schijven te koppelen/los te koppelen en elimineert het risico op problemen op de VIRTUELE machine. En het biedt hetzelfde prestatieniveau voor willekeurige lees-/schrijfbewerkingen als een schijf

Duurzaamheid en hoge beschikbaarheid

Zowel Standard- als Premium-opslag zijn duurzame opslag waarbij de pagina-blobgegevens altijd worden gerepliceerd om duurzaamheid en hoge beschikbaarheid te garanderen. Azure heeft consistent duurzaamheid op bedrijfsniveau geleverd voor IaaS-schijven en pagina-blobs, met een toonaangevende nulpercentage jaarlijkse foutpercentage.

Zie Azure Storage-redundantie en deze twee secties specifiek voor meer informatie over Azure Storage-redundantie voor Standard- en Premium-opslagaccounts:

• Ondersteunde Azure Storage-services
• Ondersteunde typen opslagaccounts

Naadloze migratie naar Azure

Voor de klanten en ontwikkelaars die geïnteresseerd zijn in het implementeren van hun eigen aangepaste back-upoplossing, biedt Azure ook incrementele momentopnamen die alleen de delta's bevatten. Deze functie voorkomt de kosten van de eerste volledige kopie, waardoor de back-upkosten aanzienlijk worden verlaagd. Naast de mogelijkheid om differentiële gegevens efficiënt te lezen en te kopiëren, is dit een andere krachtige mogelijkheid die nog meer innovaties van ontwikkelaars mogelijk maakt, wat leidt tot een optimale back-up- en noodherstelervaring (DR) in Azure. U kunt uw eigen back-up- of DR-oplossing instellen voor uw VM's in Azure met behulp van Blob Snapshot , samen met de API Paginabereiken ophalen en de Incrementele blob-API , die u kunt gebruiken voor het eenvoudig kopiëren van de incrementele gegevens voor herstel na noodgeval.

Bovendien hebben veel ondernemingen kritieke workloads die al worden uitgevoerd in on-premises datacenters. Voor het migreren van de workload naar de cloud is een van de belangrijkste problemen de hoeveelheid downtime die nodig is voor het kopiëren van de gegevens en het risico op onvoorziene problemen na de overstap. In veel gevallen kan de downtime een showstopper zijn voor migratie naar de cloud. Met behulp van de REST API van pagina-blobs wordt dit probleem opgelost door cloudmigratie mogelijk te maken met minimale onderbreking van kritieke workloads.

Voor voorbeelden over het maken van een momentopname en het herstellen van een pagina-blob vanuit een momentopname, raadpleegt u het artikel over het instellen van een back-upproces met behulp van incrementele momentopnamen .