Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

Focus sur le stockage Azure

Poster un commentaire

Un autre focus, cette fois sur le stockage Azure. Vous savez certainement que l’on dispose de 4 outils:

  1. Les Blobs
  2. Les Tables
  3. Les Queues
  4. Les Files

Le dernier est une nouveauté encore en prévisualisation qui a été présentée dans un article précédent:

https://amethyste16.wordpress.com/2015/05/20/le-stockage-des-fichiers-sous-azure-file/

Au programme:

  • Architecture des comptes de stockage et des différents stockages
  • Création depuis le portail
  • Les points de terminaison
  • Diagnostics, monitoring, analyse
  • Le support PowerShell

Présentation générale

Le blog de l’équipe de dev:

http://blogs.msdn.com/b/windowsazurestorage/

Architecture des comptes de stockage

Le point d’entrée du stockage Azure est le compte de stockage qui procure un espace de noms unique pour accéder aux données.

On en distingue deux types :

  1. les comptes standards
    Ce compte contient des blobs, des tables, des queues ou des files.
  2. les comptes premiums
    Ne peut contenir que des disques Azure. Ce type est encore en prévisualisation et doit être activé.

 

La facturation d’un stockage dépend de 4 critères:

  1. Capacité de stockage utilisée
  2. options de réplication
  3. nombre de transactions (IOPS)
  4. le data egress (données qui quittent une région Azure)

 

Au moment de la création d’un compte on sélectionne son niveau de facturation:

 

2015-05-18_13-47-51

 

Les niveaux L, G et R sont les niveaux les plus complets puisqu’ils supportent les 4 types de stockage tandis que P et Z sont limités aux blobs et avec des restrictions encore.

P correspond à l’option Premium évoquée précédemment. On observe qu’elle est limitée aux blobs de type Page, mais offre de bien meilleures performances IOPS (10 fois meilleures).

 

On peut associer des modes de réplication aux conteneurs afin d’en assurer la persistance en cas de désastre:

 

2015-05-18_17-20-15 On dispose de 4 options qui ne sont pas forcément disponibles pour tous les niveaux:

  1. Standard_LRS (Locally Redundant Storage)
    Effectue 3 copies synchrones des données dans le même data center.  En d’autres termes, toutes les ressources posées dans un stockage  sont dupliquées au moins 3 fois et ces copies sont effectives une fois que la commande d’écriture rend la main.
    Ce service coûte environ 2/3 de GRS.
  2. Standard_ZRS (Zone Redundant Storage)
    Effectue 2 à 3 copies dans plusieurs data centers éventuellement situés dans plusieurs régions. La durabilité est donc meilleures que LRS.
    Valide uniquement pour les block blob
  3. Standard_GRS (Geo Redundant Storage)
    Comme LRS, mais avec en plus 3 copies asynchrones dans un deuxième data center couplé au centre primaire. On a donc 6 copies en tout et la copie dans le centre secondaire n’est pas accessible.Elle n’existe que dans le cas où le centre primaire est perdue. A ce moment là Microsoft reroutera les requêtes vers le centre secondaire.
  4. Standard_RAGRS (Read-Access Geo-Redundant Storage)
    Comme GRS (asynchrone donc), mais on a en plus un accès en lecture seule aux données secondaires.
    Le centre secondaire a son propre espace de noms, nous verrons ce point plus loin.

Concernant les options de géo-localisation, la clef d’authentification est la même pour chaque centre ce qui assure que la bascule sera transparente pour vos applications.

Important: Puisque la réplication sur le serveur secondaire est asynchrone, il existe donc une possibilité de perte de données en cas de désastre sur le centre principal.

 

Si RA-GRS est actif l’affichage dans le panneau de contrôle est similaire à celui-ci:

2015-05-20_23-03-58

On remarque la présence des colonnes SECONDARY ENDPOINT qui est l’url d’accès au centre secondaire ainsi que la date de la dernière synchronisation. Pour les autres options seules les deux premières colonnes apparaissent.

 

De façon synthétique l’architecture générale d’un compte de stockage est la suivante:

2015-05-20_21-24-53

 

Je n’aborderai pas l’accessibilité dans cet article, le sujet a été présenté ici:

https://amethyste16.wordpress.com/2015/05/21/prise-en-charge-des-accessibilites-dans-le-stockage-azure/

Architecture des blobs

Les blobs sont destinés à stocker des données non structurées: images, vidéos, logs ou fichiers en tout genre… et bien entendu les VHD avec lesquels on peut créer des VM Azure. J’ai déjà réalisé une étude complète des VM, mais aussi ici.

Les blobs sont proposés en 2 saveurs:

  1. Page blob
  2. Block blob

Ils ont leurs propres particularités et ne sont pas interchangeables. On ne peut pas non plus convertir l’un vers l’autre.
De plus, tout objet blob peut être dupliqué dans un instantané.

 

Page Blob est optimisé pour les accès aléatoires en écriture et en lecture. C’est pour cela qu’un VHD doit être stocké dans un Page blob. Chaque page blob est découpé en pages de 512 octets jusqu’à un total de 1 To disposées de façon continue. Ce type de stockage est donc optimisé pour le streaming vidéo.

Un block blob est composé d’une série de blocs chaînés pour créer un fichier unique.
Contrairement à Page ils ne sont donc pas continues.
Cette organisation autorise des lectures/écritures concurrentielles afin d’offrir de meilleures performances en téléchargement et est donc optimisé pour la manipulation de fichiers volumineux.

Voici les métriques utiles:

  • Taille maximale d’un block: 4 Mo
  • Nombre maximal de blocks dans un blob: 50 000
  • Taille maximale d’un objet block blob: 200 Go (4 * 50 000)

 

Et pour un article plus complet sur les différences entre blob:

https://msdn.microsoft.com/fr-fr/library/azure/ee691964.aspx

 

 

Les blobs sont structurés de la façon suivante:

2015-05-18_15-00-42

 

Un compte de stockage amethystedemo est associé à plusieurs conteneurs. Un conteneur est un regroupement pour un ensemble de blobs.

 

Si vous souhaitez accéder à des blobs via C# lisez par exemple:

https://www.simple-talk.com/cloud/cloud-data/an-introduction-to-windows-azure-blob-storage-/

Architecture des TABLES

Le service de stockage TABLE d’Azure est un stockage NoSQL pour des données structurées en grande quantité.

2015-05-21_07-43-12

  • Compte de stockage
    Point d’entrée pour accéder à une ressource du service de stockage
  • Table
    Une collection d’entités. La table n’a pas de schéma pour les entités, cela signifie qu’une même table peut contenir des entités structurées de façon très différentes.
  • Entité
    Un ensemble de propriétés similaires à une ligne de base de données. Une entité peut faire jusqu’à 1 M0.
    Une propriété est une paire clé/valeur. Chaque entité peut avoir jusqu’à 255 propriétés dont les 3 propriétés système suivantes:clef de partition (partitionkey)
    clef de ligne (rowkey)
    horodatage (timestamp)Les entités ayant la même clef de partition peuvent être interrogées plus rapidement et insérées/modifiées de façon atomiques car elles sont sur le même serveur.
    La clef de ligne est un identificateur unique au sein d’une partition et la combinaison partition + ligne donne une clef primaire à l’entité.
    L’horodatage indique la date et heure de la dernière modification de l’entité.

On peut interroger les Table soit via leur point de terminaison ou bien avec OData.

2015-05-21_13-47-45

La figure qui précède représente un extrait d’une TABLE avec deux partitions. Comme on le voit une partition est entièrement conservée sur un même serveur. Un serveur peut par contre héberger plusieurs partitions.

 

Voici deux documentations qu’il peut être utile de lire:

https://msdn.microsoft.com/fr-fr/library/azure/hh508997.aspx

http://azure.microsoft.com/fr-fr/documentation/articles/fundamentals-data-management-business-analytics/

Architecture des QUEUES

Le service Azure Queue est une infrastructure capable de gérer une liste de messages. Le service est surtout optimisé pour les communication one-to-one. Pour faire du one-to-many Windows Azure Service Bus est probablement un meilleur choix.
La queue est organisée dans une structure FIFO.

L’architecture d’une queue est la suivante:

2015-05-21_14-45-45

  • Queue
    Une queue contient une liste de messages. Les messages doivent appartenir à une queue. Dans l’exemple on voit deux queues.
  • Messages
    Un message est une information dans un format quelconque, mais à concurrence de 64 Ko. La durée de vie d’un message dans une queue est de 7 jours.

 

Pour en savoir plus sur les queues:

http://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-how-to-use-queues/

 

Le service Azure Queue ne doit pas être confondu avec Azure Service Bus Queue qui a des similarités, mais est différent et n’est pas un stockage. On trouve des tas d’articles de comparaisons, en voici un:

https://alexandrebrisebois.wordpress.com/2013/10/20/windows-azure-storage-queues-vs-windows-azure-service-bus-queues/

Diagnostics, monitoring, analyse

Azure storage dispose de la capacité de capturer des logs et des métriques à des fin d’analyse et de surveillance.

Le plus simple est de regarder les démos dans le chapitre dédié.

http://azure.microsoft.com/en-us/documentation/articles/storage-monitor-storage-account/

 

Le tutoriel suivant peut être utile pour analyser les résultats:

http://azure.microsoft.com/fr-fr/documentation/articles/storage-monitoring-diagnosing-troubleshooting/

Création d’un compte de stockage

La création d’un compte de stockage peut se faire depuis le portail ou PowerShell, mais on peut aussi utiliser les Api REST, .Net ou Visual Studio. Nous ne nous intéresserons qu’aux deux premières options.

Dans le portail on clique sur NEW:

 

2015-05-18_13-42-20

 

Et on suit la séquence représentée la numérotation sur la figure:

  1. New
  2. Data + Storage
  3. Storage

Le panneau demande un nom qui sera celui de notre compte de stockage. Le nom DOIT être saisit en minuscules et ne peut contenir que des lettres ou des nombres. J’ai choisit amethystedemo. Le nom doit être unique.

Laissons les options par défaut, j’ai juste déplacé le compte dans la zone West Europe. Ce compte servira pour toute la suite.

Création de blobs

Création d’un conteneur

La création d’un conteneur peut se faire depuis le portail:

 

2015-05-18_15-41-30

 

Un clic sur la tuile Containers ouvre:

 

2015-05-18_15-43-03

On découvre qu’il n’y a pas encore de conteneur. On clique sur ADD:

 

2015-05-18_15-45-42

 

Nous allons créer un conteneur appelé logs, on laissera PRIVATE.

 

2015-05-18_15-52-07

Le conteneur est bien entendu vide:

2015-05-18_15-54-55 Un clic sur EDIT permet de modifier le type d’accès au conteneur:

 

2015-05-18_15-56-00

 

J’ai déjà traité ces options dans un article dédié.

Depuis l’ancien portail il est possible d’associer des métadonnées à chaque blob:

2015-05-18_17-06-04 On peut aussi le faire avec un outil tiers:

2015-05-18_17-10-35

Créer un blob

On aura besoin d’un outil externe comme Azure Storage Explorer. On aura aussi besoin de clef de sécurité que l’on trouve dans les paramètres du conteneur:

 

2015-05-18_16-14-52

Note: Ces clefs se terminent toujours par ==.

 

Note importante: Il est possible de lancer une régénération de ces clefs. Dans le cas où le blob héberge une VM Azure, il est préférable de l’arrêter avant, autrement vous serez obligé de la redéployer.

 

Une fois le fichier poussé dans le blob on devrait le voir apparaître dans le portail:

2015-05-18_16-16-47 Si on clique sur le blob:

 

2015-05-18_16-17-53

Les points de terminaison

Un stockage est accessible via un point de terminaison dont la syntaxe dépend de leur nature, mais c’est facile à retenir:

Il est possible de configurer son propre espace de noms si celui proposé en standard par Azure ne vous convient pas.
Un autre point intéressant est que par défaut il est possible d’atteindre un point de terminaison en HTTP ou en HTTPS. Si nous reprenons ce schéma déjà présenté:

2015-05-18_15-00-42

Ainsi avec le compte de stockage amethystedemo créé dans un chapitre précédent on disposera des points de terminaison:

  • https://amethystedemo.blob.core.Windows.net
  • https://amethystedemo.table.core.Windows.net
  • https://amethystedemo.queue.core.Windows.net
  • https://amethystedemo.file.core.Windows.net

Le format général pour accéder à un blob est:

https://%5Bnom du compte].blob.core.Windows.net/[conteneur]/[blob]

Par exemple nous aurons:

https://amethystedemo.blob.core.Windows.net/images/image2.jpg

Le service de blob est basé sur un modèle plat. Il est toutefois autorisé de placer des délimiteurs dans le nom du blob. Ainsi nos images pourraient être nommées:

/janvier/image1.JPG

/mars/image2.jpg

Ce qui donne l’url:

https://amethystedemo.blob.core.Windows.net/images/mars/image2.JPG

 

Il existe un cas particulier, celui où l’on a activé la réplication en lecture seule. L’url du centre secondaire est de la forme:

https://%5Bnom du compte]-secondary.[service].core.Windows.net

Diagnostics, monitoring, analyse

Configurer la surveillance

Dans l’onglet CONFIGURE du portail classique on trouve ceci:

2015-05-20_21-04-43

Sélectionner le niveau que l’on souhaite avoir ainsi que le nombre de jours de rétention des métriques, puis faire SAVE:

2015-05-21_15-13-21

  • Off
    La surveillance est désactivée
  • Minimal
    Collecte des métriques telles ingress/egress, latence et pourcentages de réussite
  • Verbose
    En plus des métriques minimales, collecte le même ensemble de mesures pour chaque opération de stockage de l’API Azure Storage Service

Si aucune stratégie de rétention n’est définie, les données ne seront pas supprimées, mais conservées… à vos frais bien entendu!

Les métriques fixées depuis le portail sont à l’heure. On peut descendre à la minute en PowerShell.

 

Les données de surveillance devraient commencer à apparaître au bout d’1 heure dans le tableau de bord et la page MONITOR.

 

2015-05-21_15-20-58
On remarque que les métriques sont regroupées par stockage (blob, table, queue).

On peut disposer jusqu’à 6 métriques sur le graphe. Celles non actives apparaissent en grisé comme les 3 dernières sur la copie d’écran qui précède. Pour les activer il suffit de cliquer sur leur icône.

 

Vous n’êtes pas limité aux métriques par défaut, d’autres choix sont possibles. On les fait apparaître en cliquant sur le bouton ADD METRICS:

2015-05-21_15-24-49

Les métriques proposées sont très nombreuses.

 

Les mesures sont stockées dans le compte de stockage dans 4 tables appelées:

  1. $MetricsTransactionBlob
  2. $MetricsTransactionTable
  3. $MetricsTransactionQueue
  4. $MetricsCapacityBlob

La documentation de ces tables est ici:

https://msdn.microsoft.com/library/azure/hh343258.aspx

 

Il est également possible d’activer la surveillance par PowerShell. Voir pour cela le chapitre consacré.

Configurer la journalisation

Toujours dans l’onglet CONFIGURE:

2015-05-20_21-05-30

On sélectionne les événements à journaliser, puis SAVE:

2015-05-20_21-06-42

Les journaux son enregistrés dans un conteneur de blob appelé $logs qui sont documentés ici:

https://msdn.microsoft.com/library/azure/hh343262.aspx

 

Il est également possible d’activer la journalisation par PowerShell. Voir pour cela le chapitre consacré.

Le support PowerShell

Compte de stockage

New-AzureStorageAccount permet de créer un compte de stockage.


New-AzureStorageAccount -StorageAccountName "amethystedemo" -Location "West Europe"

 

La propriété TYPE permet de typer le compte, par défaut il s’agit de Standard_GRS.

Il est possible de modifier l’option de réplication avec Set-AzureStorageAccount, mais attention, une fois en Standard_ZRS ou Premium_LRS on ne peut pas revenir en arrière.

 

 

Il est possible d’associer un stockage par défaut à un abonnement et certaines cmdlets utilisent précisément ce stockage. La question a été traitée ici:

https://amethyste16.wordpress.com/2015/04/01/ma-vm-azure-contre-le-storage-fantome/

 

Définissons amethystedemo comme stockage par défaut pour la suite.


Set-AzureSubscription -SubscriptionName "Visual Studio Premium with MSDN" -CurrentStorageAccountName "amethystedemo"

 

Cela nous permet d’inspecter le contenu de notre stockage:

Get-AzureStorageContainer

 

2015-05-18_18-03-53

On peut obtenir des informations sur un conteneur:


(Get-AzureStorageContainer -Name "logs").CloudBlobContainer

 

2015-05-18_18-05-52

On dispose aussi d’une commande permettant de récupérer les informations d’ACL du conteneur:

Get-AzureStorageContainerAcl

Conteneur

Comment créer un conteneur?


New-AzureStorageContainer -Name "logs" -Permission Off

 

Créé le même conteneur que celui construit depuis le portail. Permission attend une des valeurs suivantes:

  • Off (private)
  • Blob
  • Container

On retrouve facilement à quoi elles correspondent.

Blob

PowerShell nous permet toute sorte de manipulations sur les blobs.

On peut tout d’abord interroger le contenu d’un conteneur afin de lister les blobs qu’il contient:

Get-AzureStorageBlob -Container « logs »

2015-05-18_18-08-55

On peut alimenter un conteneur avec Start-AzureStorageBlobCopy qui copie un blob d’une source vers une cible de façon asynchrone. La copie est effectuée d’un conteneur, vers un conteneur par forcément le même.

Cette cmdlet dispose de deux types de paramètres que l’on distingue avec leur préfixe:

  • src Le paramètre se rapporte à la source de la copie
  • dest Le paramètre se rapporte à la cible de la copie

Il y a tout de même une exception Context qui aurait du s’appeler srcContext et désigne le contexte de stockage de la source.

Le script suivant copie un fichier du conteneur demordpstorage vers amethystedemo dans le cas où l’accès n’est pas anonyme:

# contexte de stockage de la cible
$destStorageAccount ="amethystedemo"
$destStorageKey = "NdsmXjtD+.....=="
$destContext = New-AzureStorageContext  –StorageAccountName $destStorageAccount `
                                        -StorageAccountKey $destStorageKey

# contexte de stockage de la source
$srcStorageAccount ="demordpstorage"
$srcStorageKey = "zD2S08........ZtWuoNh=="
$srcContext = New-AzureStorageContext  –StorageAccountName $srcStorageAccount `
                                       -StorageAccountKey $srcStorageKey

$destContainerName = "logs"
$destBlobName = "monscript.jpg"
$srcUri = "https://demordpstorage.blob.core.windows.net/windows-powershell-dsc/config.ps1.zip"

$blob = Start-AzureStorageBlobCopy -srcUri $srcUri `
                          -Context $srcContext `
                          -DestContainer $destContainerName `
                          -DestBlob $destBlobName `
                          -DestContext $destContext

$blob | Get-AzureStorageBlobCopyState
  • srcUri Uri du blob de source
  • Context Contexte de stockage du conteneur source. Ce paramètre est nécessaire uniquement parce que son ACL est PRIVATE
  • destContainer Conteneur cible
  • destBlob Nom du blob cible
  • destContext Contexte du stockage du conteneur cible
  • Force Si un blob du même nom existe, on force son écrasement sans afficher la popin de confirmation

 

La cmdlet Get-AzureStorageBlobCopyState obtient l’état de l’opération ce qui permet au script de faire du monitoring avant de passer à l’action suivante ou bien éventuellement de stopper la copie avec Stop-AzureStorageBlobCopy. Il ne faut pas oublier que la copie est asynchrone.

2015-05-18_20-45-29

On pourrait faire une copie d’un blob entre deux conteneurs du même compte de stockage. On utilise alors srcBlob à la place de srcUri. Le script suivant copie /logs/m_2.jpg vers /newlogs/m_2.jpg. Les deux conteneurs ne sont pas PRIVATE, c’est à dire que l’accès est anonyme ce qui simplifie la syntaxe:

$destContainerName = "newlogs"
$srcContainerName = "logs"
$srcBlob ="m_2.jpg"
$blob = Start-AzureStorageBlobCopy -srcBlob $srcBlob `
                 -srcContainer $srcContainerName `
                 -DestContainer $destContainerName

On trouvera d’autres exemples dans la documentation.

 

Il se peut que le futur objet blob se trouve non pas déjà sur Azure, mais dans un de vos répertoires. Cette fois la cmdlet s’appelle Set-AzureStorageBlobContent:

$ContainerName = "logs"
$pathToFile = "C:\Users\fmirouze\SkyDrive\Images\Pellicule\m_1.jpg"

Set-AzureStorageBlobContent -BlobType Block `
       -Blob "plage.jpg" `
       -Container $ContainerName `
       -File $pathToFile

On voit au passage comment on peut déterminer le type de blob avec BlobType. Si le conteneur était PRIVATE il faudrait ajouter un contexte comme on l’a fait dans le premier exemple.

La preuve en image:

2015-05-19_11-36-17

 

Il existe un cas particulier de copie: l’instantané (snapshot). Un instantané est une version en lecture seule d’un objet blob capturé à un instant donné. Il n’est pas possible de supprimer un objet blob à moins de supprimer également ses instantanés.

# obtient un contexte de stockage
$StorageAccountName = "amethystedemo"
$StorageAccountKey = "NdsmXjtD...=="
$Ctx = New-AzureStorageContext -StorageAccountName $StorageAccountName `
                               -StorageAccountKey $StorageAccountKey

$ContainerName = "logs"
$BlobName = "m_2.jpg"

# obtient une référence au blob à copier
$blob = Get-AzureStorageBlob -Context $Ctx -Container $ContainerName -Blob $BlobName

# création de l'instantané
$snap = $blob.ICloudBlob.CreateSnapshot()

 

Si on tente ensuite de supprimer le blob:

2015-05-18_23-08-51

Il n’est pas possible de supprimer ou de visualiser les instantanés depuis le portail, mais PowerShell peut s’en charger.

On peut les visualiser ainsi:

$StorageAccountName = "amethystedemo"
$StorageAccountKey = "NdsmXjtD+...=="
$Ctx = New-AzureStorageContext -StorageAccountName $StorageAccountName `
                               -StorageAccountKey $StorageAccountKey
$ContainerName = "logs"
$BlobName = "m_2.jpg"
$snaps = Get-AzureStorageBlob –Context $Ctx -Prefix $BlobName -Container $ContainerName  |
Where-Object  { $_.ICloudBlob.IsSnapshot -and $_.Name -eq $BlobName }

 

Pour faire le nettoyage il suffit de rajouter à la fin:

foreach($snap in $snaps){
$snap | Remove-AzureStorageBlob
}

Surveillance et journalisation

La doc n’est pas très claire sur le statut des cmdlets, ça risque d’évoluer.

En attendant les cmdlets stars sont:

Et pour la journalisation:

 

Voici un exemple:

Get-AzureStorageServiceMetricsProperty  -ServiceType Blob -MetricsType Minute

Retrouve les métriques qui ont été paramétrées sur un service donnée et pour une fréquence donnée.

  • ServiceType
    Blob, File, Queue, Table
  • MetricType
    Fréquence des métriques: Minute, hour

Voici un exemple de sortie:

2015-05-21_18-01-37

 

Get-AzureStorageServiceLoggingProperty -ServiceType blob

Affiche quelque chose de ce style:

2015-05-21_18-10-51

 

Pour finir:

Set-AzureStorageServiceMetricsProperty -MetricsType Hour`
-ServiceType Table `
-MetricsLevel ServiceAndApi `
-RetentionDays

Bibliographie

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s