Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

Focus sur les Windows Azure Virtual Machine

Poster un commentaire

[Edit 20/01/2013: J’ai fais des compléments et des corrections un peu partout dans cet article. Certains passages étaient carrément incompréhensibles]

 

Les deux notions très proches de VM Role et Windows Azure Virtual Machine (Azure VM) rendent les choses fort confuses.  En plus de cela les VM Role sont un service Azure en béta depuis plus de deux ans et accessibles uniquement à un nombre limité d’utilisateurs.

La bonne nouvelle est que le programme VM Role est abandonné depuis le 15 mai 2013 et depuis le 31 tous les VM Roles existants ont été supprimés par Microsoft.

Dans le même temps le programme Azure VM est passé en phase General Availability depuis le 16 avril 2013. C’est à dire que l’on est à la version finale du service.

Do I have VM Roles that I should migrate?

Donc en ce qui concerne l’offre VM d’Azure ne subsiste plus pour le moment que l’offre IAAS.

Note: tant que l’on y est, on peut aussi noter que 2013 a aussi été fatale à un autre service: Windows Azure Connect disparu en mer, le 7 mars dernier et remplacé par Windows Azure Network.

Peut être est t’il temps de regarder ensemble ce qu’est justement une Azure VM. On dira VM par la suite…

Au sommaire:

  • Quelques rappels généraux
  • Création d’une VM
  • Structure d’une VM
  • Attacher un disque
  • Créer une image
  • Les groupes de haute disponibilité
  • VM et cloud service
  • Supprimer une VM
  • VM et adresse IP
  • Choisir entre Web site, VM et cloud service
  • Bibliographie

Une vision globale

Une VM est un serveur dans Azure que l’on peut contrôler et gérer. On peut accéder à la VM exactement comme pour n’importe quel autre serveur sur son réseau. On créée des VM à partir de fichiers vhd (seul format supporté dans Azure) stockés dans un blob. Ces fichiers sont lancés sous Hyper-V. Graphiquement on a donc ceci:

19-01-2014 12-35-06

Note: si vous ne vous sentez pas très à l’aise avec les vhd, lisez ces tutoriels:

Des fichiers .vhd issus de la galerie Azure ou bien créés par vos propres moyens sont poussés dans le blob. Ces fichiers provisionnent des VM dans Windows Azure que l’on peut contrôler via le portail ou les api REST d’Azure. Il est également possible de se connecter à ces VM via un fichier RDP.

Azure peut héberger toute sorte de VM aussi bien Windows que Linux. La galerie fournit des modèles de VM prêt à l’emploi pour différentes situations.

Les vhd existent en version fixe ou dynamique. Actuellement Azure ne supporte que le format fixe. Dans Azure les vhd fixes sont stockés au format sparse ce qui offre un compromis entre les deux options. Il existe des outils comme CSUpload capables de convertir un format dynamique en format fixe.

Chaque VM réside dans un cloud service, soi seule, soit regroupée avec d’autres VM afin d’être load balancées ou pouvoir communiquer entre elles comme illustré ci-dessous:

19-01-2014 12-35-06

Deux VM sont provisionnées en stand-alone dans leur service cloud respectifs et se voient affecter chacune une adresse publique. Les VM qui partagent le même service disposent elle de la même adresse publique et sont load balancées par Azure. On peut créer des VM à partir de deux types de vhd:

  1. Image
  2. Disque

Une image est un template, que l’on utilise pour créer une ou plusieurs VM. Une image n’a pas de paramètres particuliers tels le nom du serveur, des comptes de login… Si on utilise une image afin de créer une VM, un OS y sera automatiquement attaché.

Un disque est un vhd que l’on peut monter et booter, attacher à un lecteur réseau… exactement comme un disque. Il est possible de créer une et une seule VM depuis un disque.

Lorsque l’on créée une VM à partir d’une image, on créé un disque. Ce disque est lui aussi stocké dans un blob. Ce peut être un disque avec un OS ou juste un disque de données.
L’accès ultérieur à notre VM s’effectue soit par des api REST, soit par le portail via un fichier RDP que l’on obtient en cliquant sur Connect:

19-01-2014 12-35-06

Est-ce performant? Voici un exemple de tests réalisé depuis une VM:

ping C’est pas mal.

Création d’une VM

Il existe plusieurs façons de créer une VM, nous allons les passer en revue. Elles se classent en deux familles:

  1. Depuis le portail Azure
  2. Depuis un vhd créé on premises

Depuis le portail newvm

Quick create permet de créer un vhd directement dans Azure, le fonctionnement est très simple il suffit de renseigner le formulaire qui s’ouvre.

quickcreate

Pour l’essentiel on choisit la taille du disque dur ainsi que le template de création parmi un choix possible:

imagevhd

On peut ensuite compléter la configuration de la VM à sa façon.

Note: MS fournit des templates de distribution Linux, mais aussi des templates de VM pour tester certains produits en preview comme VS 2013.

From Gallery offre des possibilités supplémentaires comme nous allons le voir. La première étape démarre comme précédemment avec la possibilité de sélectionner un template de VM.

vhdcustom Mais cette fois on a un peu plus la main sur les paramétrages comme le choix du compte de stockage et du groupe de haute disponibilité (on reparle de cela plus loin).

Si vous avez besoin d’informations sur les tailles disponibles pour le disque dur:

Virtual Machine and Cloud Service Sizes for Windows Azure

Et du modèle de facturation:

Tarification – Machines virtuelles

Une fois la VM créée un nouveau stockage devrait apparaître dans les blobs (à moins que vous ayez utilisé un stockage existant). Ce stockage contient le fichier vhd que l’on peut télécharger sur son poste depuis le menu DOWNLOAD.

Ce n’est pas tout, un cloud service est également apparu, nous reviendrons sur ce point plus tard.

Avec un vhd personnel

Le format du vhd ainsi créé est exactement le même que celui que l’on peut créer on premises. Une autre possibilité est donc de créer son fichier soi-même. Il existe plusieurs outils pour nous aider. Par exemple disk2vhd ou Disk Management. Vous trouverez des tutoriels ici:

Une fois le disque créé et initialisé on n’oublie pas de le détacher. La procédure complète pour uploader un vhd est décrite ici:

Creating and Uploading a Virtual Hard Disk that Contains the Windows Server Operating System

Notez plusieurs points importants:

  1. Une VM DOIT être généralisée avec sysprep pour être utilisée comme une image afin de créer d’autres VM
  2. Une VM NE DOIT PAS être généralisée pour servir comme un disque afin de créer une simple VM (c’est à dire ne pas servir de base à la création de plusieurs VM comme dans le cas précédent).
  3. Lorsque vous poussez le vhd dans le stockage de blob, faites le comme un blob de type page et non pas block. Des outils comme Csupload le feront pour nous en plus de transformer automatiquement les vhd en vhd fixes.
  4. Un vhd ne peut faire plus de 127 Go, un disque de données peut aller jusqu’à 1 To et un disque d’OS ne dépasse pas 127 Go

Comme vous le voyez la grande différence entre disque et image, c’est le sysprep. Avant de créer une image il y a peut être une discussion à prévoir avec un IT. Par exemple pas certain que SQL Server aime beaucoup!

Un peu de lecture complémentaire:

Common issues – uploaded VHDs

Windows Azure Storage Explorers

Mon vhd est très volumineux

Evidemment transférer un vhd sur un serveur distant ou bien le récupérer depuis le serveur c’est douloureux. Microsoft propose une offre plus adaptée pour les fichiers volumineux:

  • Vous envoyez le vhd sur un disque via un courtier (Fedex)
  • MS vous envoie le vhd via ce même courtier

A l’heure de rédaction de cet article elle est en preview pour les clients US seulement.

Scott Gu en à fait l’annonce sur son blog, la procédure complète est détaillée ici. Pour faire simple:

  • Le vhd est préparé et encrypt via un outil fournit
  • dans le dashbord du blob storage vous créez selon le cas un job d’import ou d’export

Quid des licenses?

Une FAQ complète répondra à vos question.

 

Comment est structurée la VM?

Nous venons de créer notre VM, on se connecte par RDP, que voit t’on?

Le gestionnaire de disque dur affiche ceci:

disk

Deux volumes sont donc créés sur C et D. Le premier contient l’OS installé et le second (D) est un stockage non persisté, c’est à dire que son contenu peut disparaître à la moindre démarche administrative de Windows Azure comme redéployer un nœud ce que rappelle justement le volume de ce disque.

Pagefile.sys est un fichier créé par Windows pour pallier le manque en mémoire vive. On l’appelle aussi fichier d’échange (wap file).

Donc vous êtes prévenus au sujet de D!

Le disque D présente l’avantage d’avoir de meilleures performances en I/O que les disque OS ou de données puisqu’il n’y a pas de persistance dans des stockages blobs. Il est donc fréquemment choisit comme disque temporaire de SQL server. Il faudra donc penser à le recréer si la VM migre vers un autre hôte. Voici quelques informations:

Change TEMPDB to Temporary Drive on Azure SQL IaaS

(lisez bien la note de ce document en début de page)

Une fois créé votre VM, quelques conseils utiles:

Security Best Practices for Windows Azure

Attacher un disque

On a la possibilité d’attacher un disque dur supplémentaire à une VM. Une fois la VM démarrée le menu de la VM active diverses commandes comme ATTACH.

menuattache

On sélectionne Empty Disk dans ce menu: attachpopup

Un nouveau disque apparaît dans le dashboard.

dash-disk

Il ne reste plus qu’à l’activer. On se connecte à la VM et on lance Disk Management.

initdisk

On monte le disque dur en cliquant sur le menu New Simple Volume. On doit aussi formater le nouveau disque. On dispose ainsi d’un disque supplémentaire dans la VM.

Il est possible de détacher un disque avec le menu DETACH DISK.
Le disque est lui aussi créé dans le stockage de blobs, il se trouve dans le même conteneur que le disque auquel il est rattaché.

new-disk

Créer une image

On sélectionne VIRTUAL MACHINES et on clique sur l’onglet IMAGES.

create-disk

On a le choix entre récupérer une image sur le site VMDepot ou créer une image à partir d’un de ses vhd. Dans ce dernier cas, il sera nécessaire de préparer le disque avec sysprep ce que nous rappelle la case à cocher.

Une procédure complète est donnée ici:

https://www.windowsazure.com/en-us/manage/windows/common-tasks/upload-a-vhd/?fb=fr-fr

Il est également possible de créer une image en faisant une capture d’une VM:

https://www.windowsazure.com/en-us/manage/windows/how-to-guides/capture-an-image/?fb=fr-fr

 

Les groupes de haute disponibilité

Pour assurer la disponibilité d’une VM, on doit s’assurer que:

  1. la panne d’un des composants matériel (disque, connexion…) ne suffira pas à bloquer toutes les VM d’un cloud service
  2. la mise à jour de l’OS hébergeant le cloud service ne se fera pas au même moment sur toutes les VM.

C’est la constitution d’un groupe de haute disponibilité (availability set) qui assure ces deux garanties.

Un groupe de haute disponibilité comprend un domaine de défaillance et un domaine de mise à jour.

Un domaine de défaillance (domain fault) assure qu’une simple panne de disque, de connexion… ne suffise pas à mettre en panne tout un ensemble de serveurs. D’un point de vue pratique il s’agit d’une façon de répartir des serveurs dans des racks différents comme indiqué ci-dessous:

On voit deux VM liées entre elles par un service cloud. Plutôt que de les disposer dans le même rack, on les distribue dans deux racks différents.

Parfois Windows Azure est amené à mettre à jour les OS qui hébergent une application. Le mécanisme est détaillé ici:

Comment Windows Azure applique un patch

Il faut maintenant éviter que toutes les machines d’un même groupe soient mise à jour simultanément. Lorsque l’on assemble des VM dans un groupe, Windows Azure assure également que les machines sont distribuées dans plusieurs domaines de mise à jour.

Un domaine de mise à jour (update domain) fonctionne un peu comme un domaine de défaillance vis à vis des mises à jour. C’est ce qu’illustre l’image précédente. On y voit deux groupes de haute disponibilité hébergeant chacun deux VM. Le groupe garantit que celles-ci seront distribuées dans au moins deux domaines de défaillance (deux racks concrètement) et au moins deux domaines de mise à jour.

Vous trouverez plus d’explications ici:

Upgrade Domains and Fault Domains in Windows Azure

Par défaut le nombre de domaine de mise à jour est de 5, on peut le paramétrer jusqu’à 20. On le paramètre dans le fichier de définition du rôle:

Windows Azure Service Definition Schema (.csdef File)

On a deux façons de créer un groupe de haute disponibilité.

  1. au moment où l’on crée la VM
  2. ultérieurement

Pour une machine existante, on se rend ici:

config

On créée un groupe ou bien on s’ajoute à un groupe existant. C’est l’option que l’on utilisera si on a par exemple créé la VM depuis le menu Quick Create. Si on créée une VM depuis la galerie, une image ou un disque, l’assistant arrive sur ce formulaire:

availability

Note: on remarquera au passage que la nouvelle VM sera poussée dans un cloud service existant. Mais ce n’est pas obligatoire. On a juste à donner un nom:

myavail

Puis on termine l’assistant. Une fois terminé:

as-end

Il est possible de contrôler la répartition des instances de rôles depuis le portail:

fault

Oh, oh, j’ai cru voir un cloud service!

Contrairement au feu VM Role, les Windows Azure Virtual Machine ne sont pas déployées via un rôle. Mais malgré tout une instance de service cloud contenant uniquement la VM est créée lorsque l’on provisionne une VM.

Dans l’ancienne interface ce service était visible, dans la nouvelle il est … parfois visible. C’est le point que nous allons essayer de clarifier.

Tant que le service n’a qu’une seule instance de VM, il n’est pas affiché par le portail. Il n’est pas inexistant pour autant, on le voit très bien avec Powershell. C’est le choix fait par Microsoft, j’en ignore la raison d’autant plus que la suite rend les choses très confuses.

Nous allons faire apparaître ce service!

La première méthode est de supprimer la VM. Le service apparaît et heureusement car autrement on aurait quelque part un service cloud « fantôme » complètement inaccessible via le portail.

On peu également déployer une seconde VM depuis par exemple depuis la galerie et la connecter à une VM existante:

newcloud

Et on voit apparaître un nouveau service de cloud!

Vous avez du remarquer que l’activation d’une VM s’accompagne de la création d’un cloud service. On peut aussi rejoindre un service existant comme on l’a vu précédemment.

http://hhaggan.wordpress.com/2013/04/20/cloud-services-vs-virtual-machines/

Si on souhaite en savoir plus:

Hide-and-seek with Cloud Services containers for Virtual Machines on Azure

Supprimer une VM

Pour une VM Azure, un vhd est donc stocké dans un blob et est enregistré sous la forme d’un disque attaché à la VM.

Supprimer une VM ne fait donc que détacher le disque et par conséquent le vhd de la VM. La VM n’existe plus, mais le disque et le vhd si et continuent à être facturé comme espace de stockage. Par conséquent, pour supprimer une VM et ses ressources on doit:

  1. supprimer la VM
  2. supprimer les disques attachés
  3. supprimer les vhd attachés

Il est possible de supprimer le disque et le vhd en même temps:

En fait ce n’est pas tout. Un service cloud est également créé lorsque l’on provisionne une VM. Celui-ci n’est pas supprimé automatiquement non plus. Il est alors important de se souvenir que le nom DNS est associé au service, pas à la VM.

Peut t’on accidentellement supprimer un vhd une fois attaché à une VM?

La réponse est non, une fois le vhd attaché, Azure pose un contrat (un lease) de longue durée sur le vhd. Il y a tout de même quelques scénarios qui méritent attention:

Error deleting VHD: There is currently a lease on the blob and no lease ID was specified in the request

Virtual Machine et adresse IP

On peut être confronté à deux types d’adresse IP.

  1. L’adresse publique, encore appelée VIP: celle utilisée par les serveurs externes pour accéder à des machines sous Azure
  2. L’adresse interne: adresse IP réelle de la machine. Cette adresse n’est pas visible depuis l’extérieur, d’où son nom.

Chaque instance dans le service dispose de la même adresse VIP, par exemple: 168.63.18.214, mais elles sont chacune une adresse interne spécifique à chacune.

Lorsque l’on invoque l’adresse VIP, Azure se charge de rerouter la requête vers le serveur approprié en fonction du port choisit. Ainsi pour un cloud service avec plusieurs instance on pourra avoir le mappage: IP  Comment ces adresses sont t’elles assignées et dans quelles circonstances elles peuvent être amenées à changer?

Tout d’abord l’adresse que vous recevez dépend de la région où se trouve le Datacenter comme indiqué ici:

Windows Azure Datacenter IP Ranges

L’adresse interne est assignée par Azure, c’est pourquoi elle est dynamique. Contrairement aux adresses fournies par un FAI, elle ne change pas en permanence, elle est réservée à la machine virtuelle… du moins tant qu’elle existe. Un message d’alerte s’affiche lorsque l’on tente d’éteindre une VM depuis le menu SHUTDOWN:

shutdown

Une fois l’opération terminée, le statut de la VM passe à Deallocated ce qui signifie qu’elle n’est plus facturée.

dealloc

Si plusieurs VM partagent le même cloud service, alors la désallocation de l’adresse VIP n’intervient que lorsque la dernière VM a été éteinte. Ce comportement par défaut présente l’avantage qu’une fois éteinte, la VM ne consomme plus de budget Compute.

Une adresse VIP par contre n’est pas associée à l’hôte, mais au déploiement. Tant que le déploiement persiste, l’adresse VIP est conservée même si la VM est relancée, rebootée, déplacée.

Tout ceci est résumé ici:

18-01-2014 22-51-58

On est partit d’une VM en cours d’exécution (premier schéma à gauche). Elle a été successivement arrêtée via le portail puis relancée.

L’adresse VIP est la même, mais l’adresse interne a changée.

Note: n’essayez pas d’attribuer une adresse statique à une machine Azure. Cela ne marchera pas et vous risquez de ne plus pourvoir accéder à la VM.

Oui mais, mon scénario prévoie le déploiement dans Azure d’une machine avec une adresse statique. Je fais quoi? Rien de spécial.

On parle de redéploiement, mais c’est incorrect. La machine est en fait recréée et Azure lui assigne une nouvelle adresse IP.

Il peut arriver qu’Azure déplace votre VM dans un autre noeud du data center. Dans ce cas l’adresse MAC et le processeur vont changer, mais vous conservez votre adresse VIP. Notez également que tout ce que vous aurez placé sur un data disk sera persisté en cas de réimaging ou de déplacement de la VM.

Que se passe t’il si on effectue un swap? Prenons le cas suivant:

Production Déploiement A VIP1 <dnsname>.cloudapp.net
Staging Déploiement B VIP2 <guid>.cloudapp.net

Un déploiement en staging et un déploiement en production disposent chacun de leur adresse publique VIP1 et VIP2.
En interne Azure établie une relation entre VIP1 et l’adresse interne du déploiement A et entre VIP2 et le déploiement B.
On swappe, la situation est alors la suivante:

Production Déploiement B VIP1 <dnsname>.cloudapp.net
Staging Déploiement A VIP2 <guid>.cloudapp.net

Le swapping est un simple échange de serveur, en interne l’opération consiste simplement à lier VIP1 à l’adresse interne du déploiement B et VIP2 à l’adresse interne du déploiement A. Les instances garde leur adresse interne, mais s’échangent leur adresse publique.

Par contre que l’on réimage, met à jour, reboote ou stoppe les VM, les deux adresses VIP1 et VIP2 persistent tant que l’on ne supprime pas le déploiement.

Pour en savoir plus:

Manage Deployments in Windows Azure

On a dit qu’arrêter une VM depuis le portail fait perdre l’adresse interne. Mais que se passe t’il si on stoppe la machine d’une autre façon?
On a 3 façons d’arrêter une VM:

  1. Depuis le menu SHUTDOWN du portail (ce que nous venons de voir)
  2. Depuis l’OS une fois connecté à la VM
  3. Depuis un script Powershell

Dans le premier cas, on l’a vu, les ressources compute sont désalouées et donc perdues, mais plus facturées. Dans le deuxième cas, attention, les ressources sont conservées et donc la VM facture dans le budget Compute.

Si vous souhaitez plus d’informations:

Best of TechEd 2013: Windows Azure – New Choices and Flexibility for Stopped VMs  

Azure Web Site, Cloud service ou Azure Virtual Machine?

Azure propose 3 offres pour déployer des applications:

  1. Azure Web Site
  2. Une offre PAAS avec les cloud service
  3. Une offre IAAS avec Azure Virtual Machine

Peut être est t’il utile de réfléchir à ce qui les différencie.
Un cloud service et un Azure Web Site, tout comme une VM, fonctionnent à partir de vhd. La différence est que dans le cas de la VM celui-ci est stocké dans votre espace de stockage. Vous disposez alors de plus de possibilité de personnalisation et surtout de la persistance des états de vos VM.

Le site web vous donne un accès limité au site lui-même. Tout ce qui démarre à partir de IIS ne vous appartient plus. Vous disposez d’un portail répondant à toutes vos questions au sujet des web sites.

Les VM permettent aussi de déployer d’autres OS que Windows, vous trouverez par exemple sur le site VMDepot des centaines d’exemple.

Les services cloud propose une prise en charge automatique de la plateforme (patches, mises à jour…) ainsi que des services avancés comme les services bus, la fédération d’identité, CDN, traffic management…

Les services cloud sont également déployés dans le cadre d’un rôle ce qui permet de fournir des possibilités de configuration au déploiement et en cours d’usage via les fichiers *.cscfg et *.csdfg.

D’autres informations ici:

Windows Azure is a 3-Lane Highway: How to Drive It

Si vous souhaitez en lire plus:

Cloud Services VS Virtual Machines

Windows Azure Execution Models

Bibliographie complémentaire

10 things you should know about deploying Windows Azure VMs in a hybrid IT environment

Présentation technique des fonctionnalités de sécurité de la plateforme Windows Azure

Sécurité Windows Azure application VM and (virtual) IP Address

Developing and Deploying Windows Azure Cloud Services Using Visual Studio

Creating VM VHDs in Windows Azure

Windows Azure Virtual Machines – Gotcha’s!

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