Cloud Computing @ Microsoft France

Le système d'informationset les nuages

[TechDays 2009] Optimizer et exploiter Windows Azure

[TechDays 2009] Optimizer et exploiter Windows Azure

  • Comments 1

Au cours de la session TechDays AZU304, nous avons pu entrer dans le détail de Windows Azure et vous faire part de nos premiers retours d’expérience. UPDATE : La vidéo et le support de présentation sont disponibles

En synthèse : L’infrastructure Windows Azure est optimisée pour l’élasticité. L’automatisation permet de s’affranchir d’une partie des tâches de gestion operationnelle, mais il est nécessaire en contre-partie de ne pas sous-estimer les tâches d’optimisation : un travail amont doit être réalisé en coordination avec les développeurs. De plus, il faut  prévoir une montée en compétences spécifique pour la gestion du cycle de vie des applications.

Pour optimiser Azure, il faut bien comprendre ce qui se passe derrière la toile. Ainsi nous avons commencé par présenter l’essentiel des internes de Windows Azure durant 25 minutes :

  • la constitution des machines virtuelles qui hébergent vos codes,
  • orchestrées par la Fabrique (hautement disponible via 5 à 7 replicas)
  • selon le modèle de Services que vous avez défini (nb de rôles, types, paramètres, structuration en update et fault domaines).

Ensuite, nous avons détaillé sur 20 minutes les éléments essentiels pour le développeur, à savoir :

  • la gestion des environnements : pur Dev, pur Azure et mixte (Développement dans Visual Studio et accès au Storage d’Azure)
  • la gestion des logs (niveau de logs, framework proposé et dump)
  • la sécurité de vos codes : 5 niveaux de sécurité puisque votre code .Net est managé, avec une gestion adaptée des permissions d’exécution (mode dérivé d’ASP.Net Medium Trust), mais aussi de la sécurisation de niveau infrastructure (Firewall, Virtualisation, et filtre IP)
  • la sécurité de vos données qui comprend l’authentification (via une clé de 256 bits et une signature HMAC SHA256) de toutes vos requêtes HTTP, une encryption de niveau transport (HTTPS supporté nativement), la durabilité (toutes vos données à savoir Blobs, Tables et Queues sont repliquées au moins 3 fois), et une surveillance de la détérioration (scan pour éviter le bit rot)

Dans la troisième partie de notre exposé, nous avons fait un inventaire des tâches nécessaires pour migrer et optimiser vos applications sur Windows Azure.

Tâches de migration

  • Mettre en place son framework d’abstraction : Logs, configuration, …
  • Prendre en compte le mode « Medium Trust » : Adapter ses services WCF
  • Porter ses batchs vers le rôle « Worker »
  • Porter son code natif : en attendant la prochaine version d’Azure qui supportera vos codes Win32
  • Utiliser des providers ASP.Net adaptés à Azure : présents dans le Windows Azure SDK
  • Revoir intégralement sa persistance : pour bénéficier de l’élasticité de Windows Azure. Si vous cherchez à préserver vos codes SQL existants, regarder plutôt du côté de SQL Services et de sa roadmap 2009.

Tâches d’optimisation

  • Mettre en place des caches locaux
  • Configurer ses Retry Policies introduites dans l’API d’accès au Windows Storage proposée dans le projet StorageClient du Windows Azure SDK. A adapter au fil de vos retours d’expérience
  • Profiler son code pour économiser les ressources Azure utilisées et donc sa facture au final. Le profiler proposé par Visual Studio peut s’attacher à la Dev Fabric (billet de Régis Mauger sur le sujet).
  • Informer de son état de santé pour tirer encore mieux parti de la Fabrique d’Azure.
  • Persistance : Adapter le partitionnement de ses tables en fonction de l’évolution du volume de ses données, mais aussi gérer le versionning de ses tables. Enfin, penser à supprimer les messages incorrects pour éviter qu’ils n’engorgent vos queues en les plaçant dans une zone spécifique.

Synthèse des valeurs limites pour le stockage

  • Tables
    • Partitions : pas de limite durant la preview
    • Propriétés de type String, Binary < 64 KB
    • Entités moins de 255 propriétés
    • Requêtes : Moins de 1000 entités retournées et moins de 4MB et timeout = 60 secondes
  • Blobs
    • 64 MB
    • 50 GB par paquets de 2MB
  • Queues
    • Pas de limite en terme de nombre de queues
    • 8 KB maximum par message