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 pagina's van 512 bytes met een totale grootte van maximaal 8 TB 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 pagina's van 512 bytes, die de mogelijkheid bieden om willekeurige bereiken van bytes te lezen/schrijven. Pagina-blobs zijn daarom ideaal voor het opslaan van op indexen gebaseerde en sparse gegevensstructuren, zoals besturingssysteem en gegevensschijven voor Virtual Machines en databases. Azure SQL DB gebruikt bijvoorbeeld pagina-blobs als de onderliggende permanente opslag voor de databases. Bovendien worden pagina-blobs ook vaak gebruikt voor bestanden met Range-Based-updates.
Belangrijke functies van Azure-pagina-blobs zijn de REST-interface, de duurzaamheid van de onderliggende opslag en de naadloze migratiemogelijkheden naar Azure. Deze functies worden uitgebreid 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. Standaardopslagaccounts zijn rendabeler voor het uitvoeren van werkbelastingen die niet gevoelig zijn voor latentie.
Beperkingen
Pagina-blobs kunnen alleen gebruikmaken van de dynamische toegangslaag, ze kunnen geen gebruikmaken van de statische of archieflaag . Zie Dynamische, statische en archieftoegangslagen voor blobgegevens voor meer informatie over toegangslagen.
Voorbeelden van toepassingsscenario’s
Laten we een aantal gebruiksvoorbeelden 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 aan de virtuele machines worden geleverd voor maximale prestaties. Azure-schijven worden persistent gemaakt in Hyper-V VHD-indeling en opgeslagen als een pagina-blob in Azure Storage. Naast het gebruik van virtuele schijven voor Azure IaaS-VM's maken pagina-blobs ook PaaS- en DBaaS-scenario's mogelijk, zoals 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 toepassingen voor het bewerken van video's in samenwerking, pagina-blobs snelle toegang tot willekeurige locaties in de media mogelijk maken. Het maakt ook snelle en efficiënte bewerking en samenvoeging van dezelfde media door meerdere gebruikers mogelijk.
Eigen Microsoft-services zoals Azure Site Recovery, Azure Backup en veel externe ontwikkelaars hebben toonaangevende innovaties geïmplementeerd met behulp van de REST-interface van pagina-blob. Hieronder volgen enkele van de unieke scenario's die zijn geïmplementeerd in Azure:
- Toepassingsgericht incrementeel momentopnamebeheer: toepassingen kunnen gebruikmaken van momentopnamen van paginablobs en REST API's om de controlepunten van de toepassing op te slaan zonder dure duplicatie van gegevens. Azure Storage ondersteunt lokale momentopnamen voor pagina-blobs, waarvoor niet de hele blob hoeft te worden gekopieerd. Met deze openbare momentopname-API's kunt u ook verschillen tussen momentopnamen openen en kopiëren.
- 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 wordt uitgevoerd. Zodra het doel is ingehaald, kunt u snel een failover uitvoeren naar azure-VM met behulp van die gegevens. Op deze manier kunt u uw VIRTUELE machines 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 , die scenario's zoals meerdere lezers en één schrijver mogelijk maakt met ondersteuning voor gelijktijdigheidsbeheer.
Niet-beheerde schijven worden buiten gebruik gesteld. Zie Uw niet-beheerde Azure-schijven migreren tegen 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 op 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 het ontwikkelen met behulp van pagina-blobs. Bekijk bijvoorbeeld hoe u pagina-blobs kunt openen met behulp van de 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 moet worden gemaakt. 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 na het maken, gebruikt u de methode Formaat wijzigen . De aangevraagde grootte moet een veelvoud van 512 bytes zijn.
pageBlobClient.Resize(32 * OneGigabyteAsBytes);
Pagina's naar een pagina-blob schrijven
Als u pagina's wilt schrijven, gebruikt u de methode PageBlobClient.UploadPages .
pageBlobClient.UploadPages(dataStream, startingOffset);
Hiermee kunt u een opeenvolgende set pagina's van maximaal 4 MB schrijven. De offset die naar wordt geschreven, moet beginnen op een grens van 512 bytes (begindatum % 512 == 0) en eindigen op een grens van 512 - 1.
Zodra een schrijfaanvraag voor een sequentiële set pagina's slaagt in de blobservice en wordt gerepliceerd voor duurzaamheid en tolerantie, is de schrijfbewerking doorgevoerd en wordt het succes teruggegeven aan de client.
In het onderstaande diagram ziet u twee afzonderlijke schrijfbewerkingen:
- Een schrijfbewerking vanaf offset 0 van lengte 1024 bytes
- Een schrijfbewerking vanaf offset 4096 van lengte 1024
Pagina's lezen van 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 verschuiving niet te beginnen op een veelvoud van 512. Bij het lezen van bytes van 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 dun 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 door gegevens worden ondersteund. Vervolgens kunt u de geretourneerde bereiken opsommen 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 voor schrijf- en verwijderbewerkingen tot stand genomen en beheerd. 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 slechts door één virtuele machine wordt beheerd. De vergrendelingsduur kan 15 tot 60 seconden of 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 worden deze voordelen nader besproken.
Gelijktijdige toegang
Met de REST API voor pagina-blobs en het bijbehorende leasemechanisme kunnen toepassingen toegang krijgen tot de pagina-blob vanaf meerdere clients. Stel dat u een gedistribueerde cloudservice moet bouwen die opslagobjecten met meerdere gebruikers deelt. Het kan een webtoepassing zijn die een grote verzameling afbeeldingen aan meerdere gebruikers biedt. Een optie voor het implementeren hiervan is het gebruik van een VIRTUELE machine met gekoppelde schijven. Nadelen hiervan zijn onder andere(i) de beperking dat een schijf slechts 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 wordt onderbroken; en (ii) Extra kosten voor het gebruik 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 vanaf meerdere clients, vereenvoudigt het klassieke implementatiemodel door het koppelen/loskoppelen van schijven te elimineren en elimineert het risico op problemen op de VM. 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 biedt consistent duurzaamheid op bedrijfsniveau voor IaaS-schijven en pagina-blobs, met een toonaangevend foutpercentage van nul procent op jaarbasis.
Zie Azure Storage-redundantie en deze twee secties specifiek voor meer informatie over Azure Storage-redundantie voor Standard- en Premium-opslagaccounts:
Naadloze migratie naar Azure
Voor 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. Met deze functie worden de kosten van de eerste volledige kopie vermeden, waardoor de back-upkosten aanzienlijk worden verlaagd. Samen met 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 eersteklas ervaring voor back-up en noodherstel (DR) in Azure. U kunt uw eigen back-up- of DR-oplossing instellen voor uw VM's in Azure met blobmomentopname , samen met de API Paginabereiken ophalen en de blob-API voor incrementeel kopiëren , die u kunt gebruiken om eenvoudig de incrementele gegevens voor herstel na noodgevallen te kopiëren.
Bovendien hebben veel ondernemingen al kritieke workloads die al worden uitgevoerd in on-premises datacenters. Voor het migreren van de workload naar de cloud is een van de belangrijkste aandachtspunten de hoeveelheid downtime die nodig is voor het kopiëren van de gegevens en het risico op onvoorziene problemen na de overgang. In veel gevallen kan de downtime een showstopper zijn voor migratie naar de cloud. Met behulp van de PAGINA-blobs REST API lost Azure dit probleem op door cloudmigratie in te schakelen met minimale onderbreking van kritieke workloads.
Raadpleeg het artikel Een back-upproces instellen met incrementele momentopnamen voor voorbeelden over het maken van een momentopname en het herstellen van een pagina-blob vanuit een momentopname.