Partager via


Coach Azure | Atelier 3 : Le stockage sur Windows Azure

Coach Azure : Atelier 3 : Le stockage sur Windows Azure

 

Le développement d’application Web pour dans le Cloud Windows Azure n’est pas très dépaysant pour un développeur ASP.NET qui retrouve un environnement proche de ce qu’il connait « on premise ».

Cependant le stockage diffère d’un environnement On-Premise. En effet, sur Windows Azure nous avons plusieurs solutions pour le stockage de nos données à savoir :

  • Le LocalStorage, espace disque local offert par la VM hébergeant notre application.
  • L’Azure Storage, services mettant à disposition trois services (Queues, Tables et Blob).
  • SQL Azure, version « in the Cloud » de SQL Server.

Parcourons ces différentes solutions.

 

>> Télécharger gratuitement cet atelier (cours, exercices, code-source) <<

Le Local Storage

Le « Local Storage » par traduction offre un espace de stockage « local ».  Physiquement, les données sont donc stockées sur l’espace disque de la machine virtuelle hébergeant votre rôle Azure.

Les données sont alors accessibles en utilisant les opérations standards des streams en .NET (Stream, File, Directory, etc...) contenues dans l’espace de nommage System.IO.

Aucun accès réseau n’est requis car toutes les données sont en local. Mais local signifie aussi que personne d’autre que votre rôle ne peut accéder à cet espace de stockage. En effet, un « Local Storage » est créé par une instance d’un rôle et seulement accessible par cette instance.

Autrement dit, si votre service contient deux rôles (un WebRole et un WorkerRole par exemple), ces deux rôles ne pourront accéder au même « Local Storage ». Il faudra que chacun des deux rôles crée son propre « Local Storage ».

En résumé, il est important de considérer le « Local Storage » comme un stockage temporaire (et volatile) et non comme un stockage persistant et accessible par tous les rôles d’une application cloud.

Pour créer son Local Storage, il suffit de le définir dans le fichier de définition de notre service (ServiceDefinition.csdef) :

Azure Storage

 

Nous créons ici un « Local Storage » nommé « LocalStorage1» d’une taille de 50 Mo.

A savoir que la taille minium pour un « Local Storage » est de 1MB et son maximum est limité à 20GB. Il est cependant possible de créer plusieurs Local Storage pour un rôle donné. La taille totale limite est alors définie par la taille de la VM que vous utilisez pour votre rôle.

Pour utiliser notre « Local Storage » dans notre service, nous allons récupérer la définition du « Local Storage » depuis le RoleEnvironment : 

Azure Storage

 

Il nous est alors possible de récupérer le « RootPath » soit le chemin physique sur le serveur du répertoire de notre  « Local Storage » pour pouvoir accéder à nos données.

Par exemple pour créer un simple fichier texte contenant du texte, nous pourrions écrire :

Azure Storage

Libre à nous d’y stocker ce que l’on veut dans cet espace de stockage. Mais attention ! Toutes ces données sont locales vis-à-vis du rôle et ne sont pas accessibles par d’autres. De plus, vous perdez le « load-balancing » et le « failover » en stockant des données sur un seul espace disque propre à votre rôle.

Pour bénéficier des avantages du « Cloud » sur vos données (fiabilité, haute disponibilité), il faudra alors se tourner vers l’Azure Storage ou SQL Azure.

Vidéo - Exercice 1

Vidéo - Exercice 2

Vidéo - Exercice 3