Stockages et manipulations des données dans Microsoft Azure

Dans le cadre de mes activités en clientèle, j’ai très souvent des remarques concernant le stockage ou la manipulation des données dans Azure. Remarques ayant souvent pour source la méconnaissance de la plateforme. A décharge de mes contacts, Azure évoluant très vite et de nouvelles fonctionnalités étant ajoutées régulièrement il n’est pas forcement facile d’être systématiquement à jour !

D’où ce billet pour recenser les différentes options de stockage et manipulation de données disponible dans Azure.

La plateforme de cloud computing Azure de Microsoft fournit donc de multiples fonctionnalités de stockage. Des plus classiques (comprendre historique) aux plus récentes, commercialisées ou non par Microsoft.

A noter que certaines des options évoquées ci-après ne sont pas obligatoirement accessibles dans les 2 portails de gestion de vos sousciptions Azure (l’officiel http://manage.windowsazure.com, ou celui en beta : http://portal.azure.com/)

 

Par Microsoft dans Azure :

• SQL Azure (relationnel en mode ‘cloud’ SAS, compatible SQL Server)
• SQL Server (relationnel en mode serveur dans une/des machine(s) virtuelle(s))
• Azure Storage 
  • Blob : stockage de donnée ‘binaire’ avec metadata. Utilisable en acces type « stream » ou direct (disque)
  • Queue : file de messages
  • Table : stockage de données non relationnel, par entité/colonne, schéma libre, requêtage limité, haute performance, grand volume de données, support transactionnel limité.
• HDInsight : stockage HBase (nosql, transactionnel avec faible latence), prioritairement destiné à être exploité à travers Hadoop pour la manipulation et l’analyse de données façons ‘BigData’
• Cache (en Preview) : base de donnée clé/valeur en mémoire, basé sur Redis
• DocumentDB (en Preview) : base de données NoSQL orienté document en mode SAS.
• Azure Search (en Preview) : moteur d’indexation en mode SAS (accessible uniquement sur le portail beta http://portal.azure.com ). Permet d’indexer vos jeux de données et fournit des fonctionnalités de type intellisense, correction orthographique, recherches par synonymes ou approchants.
• StorSimple : stockage avec appliance hardware local jouant le rôle de cache avec débord persistant dans Azure. Permet d’avoir de gros volume de données stockés dans Azure avec un cache local dans votre infrastructure afin d’optimiser les temps d’accès et donc améliorer les performances des vos applications.
• Recovery Service : destiné à archiver et gérer les backups de vos systèmes

 

Par Microsoft hors Azure :

• OneDrive (indirectement via les apis)
• Office365 (Sharepoint)

 

Autres éditeurs  avec facturation et réservation totalement ou partiellement intégrée (se reporter aux sites des éditeurs pour plus d’informations) :

• ClearDB : base de données relationnelle compatible MySQL en mode SAS.
• MongoDB : (edition Enterprise) base de données noSQL orienté document en mode SAS
• MongoLab : autre commercialisation de MongoDB  en mode SAS.
• RavenDB : base noSQL orienté document en mode SAS
• Oracle DB 12c Standard/Enterprise Edition + Windows Server 2012
• Oracle DB 11g R2 Standard/Enterprise + Windows Server 2008 R2
• Oracle DB 11g Standard/Enterprise + Windows Server 2008 R2
• Oracle DB 12.1.0.1 + Oracle Linux 6.4

 

 

En se référant au classement de db-engines.com (http://db-engines.com/en/ranking), on constate qu’Azure supporte donc directement 4 moteurs de bases de données du TOP5 . A noter que même si PostgresSQL (ainsi que d’autre bases de données plus exotiques) ne sont pas directement accessible à partir du portail de services Azure, il est tout à fait possible de déployer déployer ces bases sur une machine vituelle en mode IaaS (windows ou linux).

Au final, Azure supporte donc 100% des bases de données du TOP 5 db-engines.com.

 

Attention : la plupart des services évoqués ci-avant ont un coût d’utilisation variable. Reportez-vous aux conditions d’utilisations ou de vente de ces services pour obtenir les informations de tarifications officielles.

Un datacenter en container Made by Microsoft for Azure

Wired vient de publier quelques (trop) rares photos d’un DataCenter Windows Azure à base de container : http://www.wired.com/wiredenterprise/2013/02/boydton/ . Il s’agit du datacenter de Boydton en Virginie (USA) ouvert l’an dernier.

Chaque container est bien un “mini DataCenter in a box”.

Cette vision des datacenters à base de container est très bien expliquée dans la petite vidéo suivante :

 

D’autre Datacenter Azure sont d’une architecture plus classique. Ainsi, en Europe, les datacenters reste des équipements d’architecture plus ‘classique’ :

le datacenter Windows Azure de Dublin (Irlande).

Explication des soucis Azure Storage du 29/12/2012 (South US Region)

Le 29 décembre 2012, Microsoft à eu un soucis avec le service de stockage d’Azure. Contrairement au bug du 29 février, ce soucis a été relativement limité et concernait uniquement une ‘petite’ partie d’Azure Storage de la région “South US”.

Comme lors du précédent incident significatif (voir mon post “Azure – le bug du 29 février expliqué dans le détail !”) Microsoft a choisi de communiquer sur le problème, d’expliquer le soucis, la cause et le remède appliqué.

L’article en détail est ici : http://blogs.msdn.com/b/windowsazure/archive/2013/01/16/details-of-the-december-28th-2012-windows-azure-storage-disruption-in-us-south.aspx

Pour ceux qui ne veulent que le résumé, les causes sont :

1. Une erreur humaine qui a désactivé des mécanismes de protection lors d’une modification de la configuration d’un nœud de stockage.
2. Le système de monitoring avait un bug qui a empêcher le déclenchement des alertes et l’escalade .
3. Une migration du nœud de stockage concerné vers un nouveau nœud à été déclenché le 28/12 à 7:09PST. L’erreur de configuration a permit un formatage de certains disques lors de la création du nouveau nœud alors qu’ils auraient du être préservé.

Pour le détail des procédures de récupération, je vous conseille vivement de lire le billet d’origine qui est très détaillé.

Azure : le bug du 29 février expliqué dans le détail !

L’équipe Windows Azure à publier un excellent article technique expliquant l’origine du bug du 29 février qui a perturbé le fonctionnement d’Azure pendant plus de 12 heures. Azure Storage et SQL Azure n’ont pas été impacté par ce soucis. ACS et le Service Bus ont été affecté indirectement par cet évènement.

http://blogs.msdn.com/b/windowsazure/archive/2012/03/09/summary-of-windows-azure-service-disruption-on-feb-29th-2012.aspx

Voici un résumé simplifié de l’explication technique fournit dans le billet :

L’origine du soucis est lié à un problème de date d’expiration de certificats utilisé pour sécuriser les échanges de données sensibles entre les machines virtuelles (VM) exécutant vos applications et le système de gestion des ressources des datacenter : les Fabric Controler (FC).

• Le certificat est généré/regénérer lors du démarrage des VM (après une mise à jour, un changement de nombre d’instance, un re-création d’image, … ) ou dans certains cas particuliers), afin de permettre le dialoguer enter les logiciels agents du FC tournant dans la VM et le FC lui même. Ce certificat à une durée de vie de 1 an. La génération de la date de fin se fait a partir de la date du jour (à 00h00) et à laquelle on ajoute 1 à l’année en cours. ==> Les tentatives de génération des certificats ayant lieu le 29/02/2012 UST demandaient donc une date d’expiration le ‘29/02/2013 00:00’ ce qui est une date invalide –> La génération du certificat échouait. Ce bug à commencé à se produit le 28 février à 16h00 PST (29 février 00h00 UST).
• Si, au bout de 25min, l’ agent du FC n’a pas reçut le certificat d’une VM il la considère comme problématique et déclenche la création d’une nouvelle VM de remplacement. Le phénomène se reproduit de nouveau car la création de certificat échoue à chaque fois.
• Au bout de 3 tentatives d’affilée de re-création de VM qui échoue, le FC considère le serveur physique hébergeant les VM comme problématique et retire ce serveur du pool de serveurs disponibles en le marquant comme nécessitant une intervention humaine de maintenance (HI : Human Investigate).
• Le FC va alors affecter d’autres serveurs disponibles dans le cluster (un ensemble d’environ 1000 machines) pour re-créer de nouvelles VM … sur lesquels le bug du certificat va se reproduire.
• Au fur et à mesure, de plus en plus de serveurs physiques sont marqués “HI”. Le FC déclenche une sécurité qui bloque ces automatismes quand la quantité de serveur marqué HI atteint un seuil anormal. Cette sécurité à empêcher la mise hors service de l’ensemble des serveurs des cluster mais à aussi stoppé les processus de mise à jours en cours; ce qui eu pour conséquence de laisser parfois des applications dans des états instables ou dégradées.
• Le déclenchement de cette sécurité par le FC a entrainé l’alerte des opérateurs de surveillance des DataCenter pour signifier un problème insoluble par les automatismes et nécessitant une intervention humaine urgente (17h15 PST).
• En parallèle, une mise à jour des logiciels internes du datacenter (FC et ses logiciels agents) se déroulait. Cette mise à jour déclenchait la régénération des certificats d’échanges entre les VM et les agents du FC, ce qui à eu pour conséquence de déclencher le bug dans des VM qui fonctionnait correctement, accentuant ainsi l’effet du bug en forçant la réinitialisation de VM saine. Ceci explique pourquoi des clients n’ayant demandé aucune mise à jour de leurs applications durant cette période ce sont quand même vu impacté par le bug. Les cluster non concerné par cette mise à jour interne ont été moins impacté par le bug. L’augmentation anormale du nombre de cluster en cours de mise à jour avec un seuil HI atteint a entrainé l’alerte des équipes de développement du FC et des ses agents (18h38 PST).
• A ce moment là pour éviter une aggravation de la situation par des clients voulant re-déployer des mise à jour ou forcer des redémarrages pour résoudre les soucis constaté, le service de Management (utilisé par le portail d’administration) a été arrêté pour maintenir un statu-quo (18h55 PST). Il s’agit de la première fois que ce seuil d’intervention à été atteint.
• Les équipes de développement ont codé un correctif, qui fut testé dans un premier cluster de test à 01h50 PST le 29/02, ainsi que sur un cluster de production d’application interne à Microsoft.
• Après une validation sur un cluster de production, la diffusion générale du correctif à été lancé sur tous les clusters problématiques. A 5h23 PST, Microsoft annonce la restauration du service de management.

 

• 7 clusters venaient juste de commencer leur mise à jour (soit environ 7000 serveurs physiques) lors du déclenchement du bug, ce qui a laissé les couches logicielles Azure des VM et des serveurs dans des niveaux versions différentes et incompatibles entre elles. Ces 7 clusters ont donc été traités différemment : retour vers la version précédentes MAIS avec le bug du 29/02 corrigé. Habituellement cette procédure de mise à jour est progressive et prend plusieurs heures pour respecter les disponibilités des applications, mais dans ce cas exceptionnel, une mise à mise à jour simultanée de tous les serveurs a été forcées.
• Malheureusement une mauvaise version de couche réseau a été déployé ce qui a empêché le réseau virtuel reliant les VM de se configurer, privant ainsi toutes les VM concernées de connectivité (02h47 PST). Etant donné que les processeurs utilisé dans Azure ont 8 cœurs : potentiellement jusqu’à 56000 VM de type Small ont pu être impacté par ce 2e soucis (8 cœurs * 7 clusters * 1000 serveurs).
• Ces 7 clusters hébergeait majoritairement les fonctionnalités d’Access Control et du Service Bus, ce qui explique pourquoi ces fonctionnalités ont aussi été impacté par le bug ‘grâce’ à un effet cascade.
• Un correctif du correctif a été déployés sur ces 7 clusters, et à 08h00 PST la quasi totalité des serveurs était de nouveau fonctionnel.
• Un certain nombre de serveurs de ces 7 cluster étaient dans des états instables et/ou corrompus et ont du être restaurés manuellement.
• le 1er Mars à 02h15 PST l’ensemble des services était de nouveaux fonctionnels

Le post de blog d’origine décrit ensuite les conséquences de cet incident, et le plan d’actions que l’équipe Azure va mettre en place.

Précisions sur les différences entre les tailles de VM Azure : Bande passante réseau

Outres les différences connues entre les type de VM Azure (taille mémoire, taille disque, nombre de coeur CPU), une autre caractéristique technique est différentiente : la bande passante réseau disponible. En effet, la vitesse de la connectivité réseau (bien que virtuelle) est différente en fonction de la taille de la VM. La règle est de 100Mbs par cœur de CPU, sauf pour l’ExtraSmall.

Extra small :     5Mbs          
Small : 100Mbs
Medium : 200Mbs    
Large : 400Mbs
ExtraLarge : 800Mbs        

 

En conséquence, si vous avez à effectuer des taches peu consommatrice en temps CPU mais nécessitant un gros débit réseau, il peut être judicieux de choisir des tailles de VM plus grosses. les VM ExtraSmall était clairement destiné à des petites applications ou pour faire du développement/test.

Azure : Baisse de prix depuis le 8 mars 2012

Outre les baisses de prix de SQL Azure annoncé le 15/02 (cf ce billet), Microsoft vient d’annoncer de nouvelles baisses de la tarifications sur d’autres services Azure :

• Azure Storage : le Gb passe à 0.0887€
• Azure Compute : les instances Extra Small voit leur prix divisé par 2 : au lieu d’être compatibilité comme 1/3 d’heure ‘Small’, elles sont comptabilisé comme 1/6 d’heure ‘Small’. (je rappelle de l’heure de VM Small est l’utilisation de comptabilisation du temps de calcul dans Azure Compute)

La baisse de prix des instance ExtraSmall est extrêmement intéressante pour 2 profils de consommateurs :

• site web à très faible montée en charge
• développeur (abonnement MSDN, …) : cette baisse de cout multiplie donc par 2 le nombre d’heure de vm “Extra Small” utilisable gratuitement dans le cadre de ses abonnements. De quoi se sentir moins à l’étroit pour ses tests

Le détail de la tarification se trouve ici : http://www.windowsazure.com/fr-fr/pricing/details/

SQL Azure : déplacement d’un serveur vers une autre souscription

Petite nouveauté dans le portail d’administration Azure, il est maintenant possible de déplacer un serveur SQL Azure vers une autre souscription. Très pratique quand on utilise une souscription à tarif privilégié (type MSDN) qui arrive à expiration , cela évite de reconstruire la base de données dans la nouvelle souscription !

Une fois le nouvel abonnement sélectionné et validé, le serveur se retrouve quasi instantanément attaché à la nouvelle sélection, sans interruption de service au niveau SQL Azure.

A quand le même fonctionnalité sur les Hosted Services ?

Billet sans paroles : De l’intérêt d’une base de données fiable et élastique dans le cloud

Investissement sur le Datacenter Azure de Dublin

Depuis plusieurs mois, lors des formations Windows Azure que je dispense, j’évoque souvent les datacenters Azure, dont celui de Dublin (Irlande) que j’ai eu la chance de visiter fin 2011.

Pour compléter mes propos (et les confirmer ), Microsoft vient d’annoncer un investissement très important sur la DataCenter de Dublin : http://blogs.msdn.com/b/windowsazurefrance/archive/2012/02/23/microsoft-investit-130-millions-de-dollars-pour-son-datacenter-de-dublin-en-irlande.aspx

L’article est très intéressant car il met en évidence certains choix effectués par Microsoft (notamment le refroidissement par exemple).

SQL Azure et les données spatiales, SQL Azure manager online

Comme je le répète souvent aux participants des formations que j’assure ou à mes clients, Windows Azure est une plateforme qui évolue très rapidement et très souvent.

il en est de même pour SQL Azure. Le support des type de données géographiques à été ajouté en juin 2010. Il est donc possible de créer des tables avec des coordonnées spatiales.

CREATE TABLE CityLocation
(
CityName [nvarchar](50) NOT NULL,
Location [geography] NOT NULL
)
CONSTRAINT [PrimaryKey_CityName] PRIMARY KEY CLUSTERED
(
CityName ASC
)

 

L’insertion se fait de manière très classique, avec une syntaxe adaptée pour les types spatiaux :

 

Il est possible d’effectuer des requêtes sur les distances entre des coordonnées. Ainsi, obtenir la liste des villes à moins de 1000km de Lyon s’écrira ainsi :

On obtient bien Lyon, Marseille et Paris.

 

Une des fonctionnalités gravitant autour de SQL Azure est l’outils de management en ligne de la base SQL Azure. Cet outils (écrit en Silverlight) est accessible en vous connectant en https sur votre serveur SQL Azure ( https://[monserveur].database.windows.net ).

Cet outils est mis à jour régulièrement. il est maintenant capable de vous afficher les plans d’exécutions de vos requêtes pour les optimiser. La requête précédente donne ce plan d’exécution :

 

Pour revenir à nos données spatiales, une des fonctionnalités très pratique de cet outil est la représentation sous une forme cartographique de vos données spatiales. Ainsi, le résultat de la requête précédente nous donne :

La vérification du résultat d’une requête spatiale est énormément facilité … car visuel !!