Azure Blob storage

Pojęcie blob to skrót od binary large objects. Azure Blob storage to usługa używana do składowania dużych ilości nieustrukturyzowanych danych takich jak dokumenty, pliku multimedialne, backupy.

 

Identify appropriate blob type for specific storage requirements

Istnieją dwa typy blobs:

  • Block blobs – typ zaprojektowany do efektywnego uploadu danych. Przeznaczony do składowania plików takich jak wideo, obrazki i dokumenty. Każdy blob składa się z bloków, które są identyfikowane przez ID. Maksymalny rozmiar bloku to 200GB. Jedyna usługa storage, która wspiera ZRS.
  • Append blobs – składają się z bloków (blocks) i są optymalizowane do operacji dodawania (append). Modyfikacja blob rodzaju append polega na dołożeniu na końcu bloba kolejnych bloków. Kasowanie lub aktualizowanie istniejącego append bloba nie jest możliwe.
  • Page blobs – nazywane także dyskami ponieważ są optymalizowane pod kątem losowego zapisu i mogą mieć pojemność do 8 TB. Wirtualne twarde dyski w Azure (VHDs) są składowane jako page blob.

Więcej o rodzajach blobs:

https://docs.microsoft.com/en-us/rest/api/storageservices/understanding-block-blobs–append-blobs–and-page-blobs

 

Configure Blob-Level Tiering (Hot, Cool, Archive)

Istnieją trzy poziomy dostępu do blobs różniące się ceną:

  • Hot – przewidziane dla danych, do których wymagany jest częsty dostęp. Wyższy niż cool i archive koszt składowania danych ale niższy koszt dostępu do danych.
  • Cool – dane niezbyt często użytkowane, składowane co najmniej 30 dni. Niższy niż hot koszt składowania danych ale wyższy koszt dostępu. Np. krótkoterminowy backup.
  • Archive – dane rzadko używane i składowane co najmniej 180 dni z czasem dostępu liczonym w godzinach (< 15 godzin). Najniższy koszt składowania i najwyższy koszt dostępu do tych danych.

Poziomy obsługują tylko konta storage typu GPv2 (General Purpose). GPv1 nie mają takiej funkcjonalności. Upgrade kont storage GPv1 do GPv2:

Utworzenie storaga rodzaju BlobStorage i poziom dostępu Hot.

Zmiana poziomu dostępu na cool:

Więcej o poziomach dostępu:

https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-storage-tiers

 

Kontenery.

Jeżeli blob storage przyrównamy do koncepcji folderów i plików to odpowiednikiem folderu będzie kontener, a odpowiednikiem pliku będzie blob.

W sposób przedstawiony poniżej można utworzyć kontener. Ustawienie Parametr Permission ustawia typ dostępu do kontenera:

  • Off – dostęp jest dozwolony tylko do właściciela konta storage. Domyślny poziom dostępu. W portalu Azure ten tryb nazywa się Private.
  • Blob – tryb tylko do odczytu do danych w kontenerze ale nie do samego kontenera.
  • Container – tryb tylko do odczytu do danych w kontenerze i do kontenera.

Lub można przed założeniem kontenera utworzyć kontekst. Wcześniej jednak potrzebujemy odczytać podstawowy klucz dostępu do magazynu.

 

Design blob hierarchies

Usługa blob oparta jest na płaskim schemacie co oznacza, że poniżej poziomu root można utworzyć tylko jeden kontener. Kontenerów nie można zagnieżdżać w innych kontenerach. Płaski schemat Azure Blob storage wygląda następująco:

Object structure:    Storage account » Container » Blob name

Example:    sa » [blob.core.windows.net] » raw » picture1. rif

Najczęściej hierarchię magazynowania blobs realizuje się przez dodawania odpowiednich prefiksów do nazwy blobs.

sa » [blob.core.windows.net] » raw » pictures/picture1.rif
sa » [blob.core.windows.net] » raw » audio/recording1.pcm

pictures/picture1.rif i audio/recording1.pcm to nazwy blobs.

Można to także osiągnąć przed dodaniem prefiksu do nazwy kontenera. Nazwa kontenera nie może jednak zawierać znaku /.

sa » [blob.core.windows.net] » raw-pictures » picture1.rif
sa » [blob.core.windows.net] » raw-audio » recording1.rif

Takie rozwiązanie upraszcza używanie  filtrów  podczas pobierania blobsów. Ponad to można używać innych filtrów bezpieczeństwa opartych o hierarchię.

 

Implement async blob copy

To initiate a blob copy, use the Start-AzureStorageBlobCopy cmdlet. This cmdlet accepts either the source URI (if it is external), or as the example below shows, the blob name, container, and storage context to access the source blob in an Azure Storage account. The destination requires the container name, blob name, and a storage context for the destination storage account.

Let’s review the parameters in the preceding example:

  • The SrcBlob parameter expects the file name of source file to start copying.
  • The SrcContainer parameter is the container the source file resides in.
  • The Context parameter accepts a context object created by the New-AzureStorageContext cmdlet. The context has the storage account name and key for the source storage account and is used for authentication.
  • The DestContainer is the destination container to copy the blob to. The call will fail if this container does not exist on the destination storage account.
  • The DestBlob parameter is the filename of the blob on the destination storage account. The destination blob name does not have to be the same as the source.
  • The DestContext parameter also accepts a context object created with the details of the destination storage account including the authentication key

MULTIPLE SUBSCRIPTIONS REQUIRES A CALL TO SELECT AZURESUBSCRIPTION
To copy between storage accounts in separate subscriptions, you need to call SelectAzureSubscription between the calls to Get-AzureStorageKey to switch to the alternate subscription. Here is a complete example of how to use the Start-AzureStorageBlob copy cmdlet to copy a blob between two storage accounts.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *