• Partagez
  • E-mail
  • Intégrer
  • J'aime
  • Contenu privé
Monter en charge, tester et surveiller avec une application Windows Azure : les bonnes pratiques
 

Monter en charge, tester et surveiller avec une application Windows Azure : les bonnes pratiques

on

  • 441 vues

La plateforme Windows Azure dispose d’une offre de services riche qui s’étend rapidement. En fonction des projets, vous devez faire des choix d’architecture sur les services à utiliser et leur ...

La plateforme Windows Azure dispose d’une offre de services riche qui s’étend rapidement. En fonction des projets, vous devez faire des choix d’architecture sur les services à utiliser et leur mise en œuvre. Quelles sont les bonnes pratiques, mais également les mauvaises pratiques à éviter. Les experts Azure MCS partagent leurs retours d’expérience issus de leurs engagements terrain parmi les sujets suivants : connaître les limites de charge (Scalability) de Windows Azure incluant SQL Database, comment monter en charge pour un certain nombre de services, tester en charge une application, puis surveiller et exploiter une application ou une VM Windows Azure.

Statistiques

Vues

Total des vues
441
Vues sur SlideShare
441
Vues externes
0

Actions

J'aime
0
Téléchargements
7
Commentaires
0

0 Ajouts 0

No embeds

Accessibilité

Catégories

Détails de l'import

Uploaded via as Microsoft PowerPoint

Droits d'utilisation

© Tous droits réservés

Report content

Signalé comme inapproprié Signaler comme inapproprié
Signaler comme inapproprié

Indiquez la raison pour laquelle vous avez signalé cette présentation comme n'étant pas appropriée.

Annuler
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Votre message apparaîtra ici
    Processing...
Poster un commentaire
Modifier votre commentaire
  • Intro Architecture / Azure / Cloud
  • Service Bus Queues offer simple first in, first out guaranteed message delivery and supports a range of standard protocols (REST, AMQP, WS*) and API’s to put/pull messages on/off a queue. Service Bus Topics deliver messages to multiple subscriptions and easily fan out message delivery at scale to downstream systems.Service Bus Relay solves the challenges of communicating between on-premises applications and the outside world by allowing on-premises web services to project public endpoints. Systems can then access these web services, which continue to run on-premises from anywhere on the planet.A feature of Service Bus currently in preview is the Notification Hub. This provides a simple, scalable way to send out push notifications to apps on popular mobile platforms without needing to understand or directly interface with the many notification mechanisms for each platform.
  • Service Bus Queues offer simple first in, first out guaranteed message delivery and supports a range of standard protocols (REST, AMQP, WS*) and API’s to put/pull messages on/off a queue. Service Bus Topics deliver messages to multiple subscriptions and easily fan out message delivery at scale to downstream systems.Service Bus Relay solves the challenges of communicating between on-premises applications and the outside world by allowing on-premises web services to project public endpoints. Systems can then access these web services, which continue to run on-premises from anywhere on the planet.A feature of Service Bus currently in preview is the Notification Hub. This provides a simple, scalable way to send out push notifications to apps on popular mobile platforms without needing to understand or directly interface with the many notification mechanisms for each platform.Découplage : prise en charge des scénarios de traitement asynchrone des demandes et découplage physique entre les intervenants
  • Service Bus Queues offer simple first in, first out guaranteed message delivery and supports a range of standard protocols (REST, AMQP, WS*) and API’s to put/pull messages on/off a queue. Service Bus Topics deliver messages to multiple subscriptions and easily fan out message delivery at scale to downstream systems.Service Bus Relay solves the challenges of communicating between on-premises applications and the outside world by allowing on-premises web services to project public endpoints. Systems can then access these web services, which continue to run on-premises from anywhere on the planet.A feature of Service Bus currently in preview is the Notification Hub. This provides a simple, scalable way to send out push notifications to apps on popular mobile platforms without needing to understand or directly interface with the many notification mechanisms for each platform.Découplage : prise en charge des scénarios de traitement asynchrone des demandes et découplage physique entre les intervenants
  • Windows Azure Queues is primarily targeting at enabling communication between Web and Worker roles on Windows Azure. Service Bus Queues is a more general purpose queue infrastructure and as a result targets a broader set of messaging scenarios and connections between not just web and worker roles but whole systems
  • Intégrables avec d’autres services : Azure Mobile avec node.js, relais de services hébergés par des Worker Roles
  • Le mode TCP permetaussi le prefetching : http://msdn.microsoft.com/en-us/library/windowsazure/hh528527.aspxClient-side batching enables a queue or topic client to delay the sending of a message for a certain period of time. If the client sends additional messages during this time period, it transmits the messages in a single batch. Client-side batching also causes a queue/subscription client to batch multiple Complete requests into a single request. Batching is only available for asynchronous Send and Complete operations. Synchronous operations are immediately sent to the Service Bus service. Batching does not occur for peek or receive operations, nor does batching occur across clients. If the batch exceeds the maximum message size, the last message is removed from the batch, and the client immediately sends the batch. The last message becomes the first message of the next batch. By default, a client uses a batch interval of 20ms. You can change the batch interval by setting the BatchFlushInterval property before creating the messaging factory. This setting affects all clients that are created by this factory.To disable batching, set the BatchFlushInterval property to TimeSpan.Zero. For example:To increase the throughput of a queue/topic/subscription, the Service Bus service batches multiple messages when it writes to its internal store. If enabled on a queue or topic, writing messages into the store will be batched. If enabled on a queue or subscription, deleting messages from the store will be batched. If batched store access is enabled for an entity, the Service Bus delays a store write operation regarding that entity by up to 20ms. Additional store operations that occur during this interval are added to the batch. Batched store access only affects Send and Complete operations; receive operations are not affected. Batched store access is a property on an entity. Batching occurs across all entities that enable batched store access.
  • Le mode TCP permetaussi le prefetching : http://msdn.microsoft.com/en-us/library/windowsazure/hh528527.aspxClient-side batching enables a queue or topic client to delay the sending of a message for a certain period of time. If the client sends additional messages during this time period, it transmits the messages in a single batch. Client-side batching also causes a queue/subscription client to batch multiple Complete requests into a single request. Batching is only available for asynchronous Send and Complete operations. Synchronous operations are immediately sent to the Service Bus service. Batching does not occur for peek or receive operations, nor does batching occur across clients. If the batch exceeds the maximum message size, the last message is removed from the batch, and the client immediately sends the batch. The last message becomes the first message of the next batch. By default, a client uses a batch interval of 20ms. You can change the batch interval by setting the BatchFlushInterval property before creating the messaging factory. This setting affects all clients that are created by this factory.To disable batching, set the BatchFlushInterval property to TimeSpan.Zero. For example:To increase the throughput of a queue/topic/subscription, the Service Bus service batches multiple messages when it writes to its internal store. If enabled on a queue or topic, writing messages into the store will be batched. If enabled on a queue or subscription, deleting messages from the store will be batched. If batched store access is enabled for an entity, the Service Bus delays a store write operation regarding that entity by up to 20ms. Additional store operations that occur during this interval are added to the batch. Batched store access only affects Send and Complete operations; receive operations are not affected. Batched store access is a property on an entity. Batching occurs across all entities that enable batched store access.
  • Le mode TCP permetaussi le prefetching : http://msdn.microsoft.com/en-us/library/windowsazure/hh528527.aspxClient-side batching enables a queue or topic client to delay the sending of a message for a certain period of time. If the client sends additional messages during this time period, it transmits the messages in a single batch. Client-side batching also causes a queue/subscription client to batch multiple Complete requests into a single request. Batching is only available for asynchronous Send and Complete operations. Synchronous operations are immediately sent to the Service Bus service. Batching does not occur for peek or receive operations, nor does batching occur across clients. If the batch exceeds the maximum message size, the last message is removed from the batch, and the client immediately sends the batch. The last message becomes the first message of the next batch. By default, a client uses a batch interval of 20ms. You can change the batch interval by setting the BatchFlushInterval property before creating the messaging factory. This setting affects all clients that are created by this factory.To disable batching, set the BatchFlushInterval property to TimeSpan.Zero. For example:To increase the throughput of a queue/topic/subscription, the Service Bus service batches multiple messages when it writes to its internal store. If enabled on a queue or topic, writing messages into the store will be batched. If enabled on a queue or subscription, deleting messages from the store will be batched. If batched store access is enabled for an entity, the Service Bus delays a store write operation regarding that entity by up to 20ms. Additional store operations that occur during this interval are added to the batch. Batched store access only affects Send and Complete operations; receive operations are not affected. Batched store access is a property on an entity. Batching occurs across all entities that enable batched store access.
  • Pas disponible pour X-Small
  • Les blocs de couleurs sont éditables et peuvent reprendre la couleur du type de session qui est donnée.Idem pour les textes.
  • The management group must be running Operations Manager 2007 R2 Cumulative Update 3. The Windows Azure role must be published with full trust level. For more information about Windows Azure trust levels, see Windows Azure Partial Trust Policy Reference.Windows Azure Diagnostics must be enabled. For more information about Windows Azure, see Collecting Logging Data by Using Windows Azure Diagnostics.Windows Azure Diagnostics must be configured to forward diagnostic data to a Windows Azure storage account. For more information about configuring Windows Azure Diagnostics, see Transferring Diagnostic Data to Windows Azure Storage.The Microsoft .NET Framework version 2.0 or newer must be installed on the computer that you designate as the proxy agent when you configure the Windows Azure Management Pack.

Monter en charge, tester et surveiller avec une application Windows Azure : les bonnes pratiques Monter en charge, tester et surveiller avec une application Windows Azure : les bonnes pratiques Presentation Transcript

  • Monter en charge , tester et surveilleravec une application AzureLes bonnes pratiquesOlivier Sallaberry , Patrice Mana’ch , Fabrice MeillonArchitectes - MicrosoftArchitecture / Azure / Cloud
  • Architecture / Azure / Cloud• Introduction• Montée en charge avec Windows Azure– Vue d’ensemble– Azure Storage– SQL Database– Azure Virtual Machines– Traffic Manager– Service Bus– Cache• Tests de charge– Mise en place d’une plateforme mixte IaaS / PaaS de tests de charge dans Azure• Monitoring des applications Azure avec SCOM– Mise en place du monitoring– Démonstration d’autoscaling avec SCOM 2012• Questions / RéponsesAgenda
  • INTRODUCTIONChapitre 1Architecture / Azure / Cloud
  • Architecture / Azure / CloudIntroductionNewEcosystemsUsageBasedElasticEconomicsSolidManagedResourcesLes problématiques de montée en charge et de monitoring des applications Azuresont « récurrentes » lors de nos engagements et ont une incidence forte sur la définitiond’une architecture cible , le dimensionnement et à fortiori le calcul des OPEXCette session a pour objectif de vous apporter un éclairage sur ces sujets issus de nosexpériences projets .Windows Azure est aujourd’hui:• une plateforme riche ,• améliorée constamment.Son usage se développe largement…
  • Architecture / Azure/ CloudINTRODUCTION – VUE D’ENSEMBLE DE LA PLATEFORMEhttp://www.microsoft.com/en-us/download/details.aspx?id=35473
  • MONTÉE EN CHARGE ET WINDOWS AZUREVUE D’ENSEMBLEChapitre 2Architecture / Azure / Cloud
  • Architecture / Azure / Cloud• Montée en chargeCapacité de la solution à servir un nombre croissant d’utilisateurs / consommateurssimultanés. Au-delà d’un seuil, le service n’est plus rendu.• PerformanceCapacité de la solution à servir aux utilisateurs / consommateurs un temps de réponseinférieur à un seuil convenu pour une fonction donnée.Montée en charge : Vue d’ensembleCapacité à monter en charge versus performance
  • Architecture / Azure / Cloud• Scale up : l’ « exception » HPC• Scale out : le quotidien..– Ressources• « Commodity hardware »• Illimitées (presque)– Quotas– Notion de « voisinage »– ThrottlingMontée en charge , Vue d’ensembleScale up ou scale out ?http://blogs.msdn.com/b/windowsazure/archive/2012/11/13/windows-azure-benchmarks-show-top-performance-for-big-compute.aspx
  • Architecture / Azure / CloudMontée en charge : vue d’ensembleElasticitéContention« Verticale »Taille D’instance« Horizontale »Nombre d’instancesPoints de contention = points d’attention…
  • Architecture / Azure / CloudMontée en charge : vue d’ensemble• Désynchronisation– Absorber et lisser la charge parmécanismes asynchrones (viaqueues REST ou Service Bus)Quelques patterns utilisés en projet..• Scale Out– Roles (Portail , APIs , Power Shell)– Mécanismes du stockage REST Azure– Optimisation des IO d’une VM IaaS– Sharding horizontal et / ou vertical des bases de données (SQL Azure Federation ou spécifique)– Usage Traffic manager– Séparation des flux de données , ex : ceux de diagnostic de ceux des données de production (...)• Caching– Absorber / limiter la charge portée parles points de contention back-end– Assurer la scalabilité du cache lui-même.
  • LE STOCKAGE REST AZUREChapitre 3Architecture / Azure / Cloud
  • Architecture / Azure / CloudStockage REST Azure - Data Abstractions• Stockage hautement disponible , géo-répliqué• Blobs – Système de fichiers dans le cloud• Tables – Stockage structuré (noSQL) massivement scalable.• Queues – Files d’attentes sur stockage fiable• Drives – Volumes NTFS durables pour les applicationsWindows Azure.
  • Architecture / Azure / CloudStockage REST Azure - Fonctionnementhttp://blogs.msdn.com/b/windowsazurestorage/archive/2010/12/30/windows-azure-storage-architecture-overview.aspx
  • Architecture / Azure / Cloud« Scalability targets » par compte de stockage(compte créé après le 7 Juin 2012)CibleTransactions 20000 entités/ messages/ Blobspar secondeBande passante pour un compte géo-redondant Ingress : 5 Go/sEgress : 10 Go/sBande passante pour un compte localement redondant Ingress : 10 Go/sEgress : 15 Go/sStockage REST azure – Quelques chiffreshttp://blogs.msdn.com/b/windowsazurestorage/archive/2012/11/04/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx« Scalability targets » parpartitionClef de partition CibleQueue Queue Name 2000 messages/sTable Partition Key 2000 entités/sBlob Container Name + Blob Name 60 Mo/s par blobDes cibles de montée en charge améliorées en 2012..
  • Architecture / Azure / Cloud• Prendre en compte les objectifs descalabilité du compte de stockage , puiscelles des blobs, tables et queues• Distribuer sur plusieurs comptes destockage, si nécessaire. Se réserver lapossibilité de le faire.• Mise en place systématique de « Retrypolicies » et « exponential back off »• Choisir avec attention sa clef de partitionpour les tables– Trop petite : limite les requêtes batch (possiblessur une partition)– Trop grande : contentions éventuellesStockage REST Azure – Pratiques 1/2• Mettre toutes les ressources REST sous lemême compte de stockage après avoir lu lapage précédente.• « Oublier » les « retry policies » et« exponential back off »• Utiliser un compte antérieur au 07/06/2012• Ecrire les logs et informations de télémétriesur le même compte de stockage que lesdonnées de productionQuelques bonnes pratiques Quelques pratiques à éviter
  • Architecture / Azure / Cloud• Utiliser si possible les Batch transactionspour les tables– maximum 100 entités sur la même partition)• Utiliser plusieurs queues si plus de 2000messages secondes• Dupliquer les blobs sur plusieurs comptesau besoin , penser au CDN…• Paralléliser les appels– Exemple : upload de Blobs• Faire un test de charge systématique dela solution « end to end » depuis lemême DC AzureStockage REST Azure – Pratiques 2/2• Ne pas utiliser le mécanisme d’écriture dediagnostic par défaut des rôles PaaS– Nous avons rencontré des implémentations « alternatives »générant du Throttling• Multiplier les requêtes REST unitaires plutôt quecibler ou traiter par lots– Exemple1 : Multiplier les requêtes de Table générantdes « continuation tokens » (plus de 1000 entités ou 5secondes , limites de partitionnement)– Exemple 2: effacer ligne à ligne de milliers d’entités(anticiper l’architecture cible pour plutôt effacer latable..)• Choisir des noms de propriétés trop long pourles tables , les métadonnées sont écrites en ligneet leur taille entrent en compte dans la limite de1Mo par entité.Quelques bonnes pratiques Quelques pratiques à éviter
  • WINDOWS AZURE SQL DATABASEChapitre 4Architecture / Azure / Cloud
  • Architecture / Azure / Cloud• SGBD « as a service »• Basé sur la technologie SQL Server• Construit pour le cloud avec haute disponibilité ettolérance aux pannes.• Self Service (provisionning / Management)• Support de TSQL et des outils (SSMS..)• Différences SQL Server / Windows Azure SQL DatabaseWindows Azure SQL Databasehttp://msdn.microsoft.com/en-us/library/windowsazure/ff394115.aspx
  • Architecture / Azure / CloudWindows Azure SQL DatabaseApplicationInternetLBTDS (tcp)TDS (tcp)TDS (tcp)Apps use standard SQL client libraries:ODBC, ADO.Net, PHP, …Load balancer forwards ‘sticky’ sessionsto TDS protocol tierGateway Gateway Gateway Gateway Gateway GatewayScalability and Availability: Fabric, Failover, Replication, and Load balancingSQL SQL SQL SQL SQLSQLGateway: TDS protocol gateway, enforces AUTHN/AUTHZ policy; proxy to backend SQL
  • Architecture / Azure / CloudPourquoi le « Sharding » ?• Limitations en ressources d’une base SQL Database– Taille (< 150 Go)– Capacité de traitement (Requêtes simultanées)• Usage partagés de ressources physiques– Environnement physique « multi-tenant »– « Throttling » pour permettre à tous d’utiliser le serviceWindows Azure SQL Database
  • Architecture / Azure / CloudPourquoi le « Sharding » ?• Par retour d’expérience projets , une SQL Database supporteactuellement :– De 300 à 3000 Transactions par secondes– En moyenne environ 1500 transactions par seconde– Varie selon l’implémentation , le nombre de clients , de rôles…– Dépend de la charge du nœud physique à un instant t.• Automatisation et optimisation du Data Center Azure:– Lissage de la charge et de l’usage des ressources physique au niveau du Data Center– Chaque base SQL Database est redondée via 3 réplicas.– Orientation « transparente » pour l’utilisateur vers le nœud le moins sollicité des 3copies de chaque baseWindows Azure SQL Database
  • Architecture / Azure / Cloud• ShardingDistribution de la charge et/ou du volume surplusieurs bases• Sharding « Vertical »Distribution des bases ou du modèle dedonnées entier selon des critèresfonctionnels et/ou techniquesExemple : n bases read only et round robin applicatif• Sharding « Horizontal »Distribution de groupes d’entitésatomiquement indépendants , appartenantau même modèle , sur plusieurs bases.Exemple : SQL Azure FederationWindows Azure SQL Database – ShardingSharding « vertical »Sharding « horizontal »
  • Architecture / Azure / Cloud• Usage de Ressources partagées– Relations de « bon voisinage » et continuité du service• « Commodity hardware »– Globalement , matériel à bas cout non orienté« performance »• Soft Throttling :– transaction ralenties ou abandonnées à l’atteinte d’un seuil• Hard Throttling :– Impacte le nœud physique , toutes les bases de données etles utilisateurs .– Les transactions sont abandonnée à l’atteinte d’un seuil et lesystème prévient l’exécution des suivantes tant qu’un seuilreste dépassé.SQL Database - Throttlinghttp://msdn.microsoft.com/en-us/library/windowsazure/jj717232.aspx
  • Architecture / Azure / Cloud• Considérer les options de Sharding dès la phasede conception et si possible ouvrir ces options adéfaut de les implémenter dès la premièreversion.• Minimiser le nombre de requêtes unitaires etpréférer les échanges applications / bases deforte granularité– DTOS (Data Transfert Object)– requêtes par lots (exemples : TVPs Table ValueParameters).• Considérer la mise en place de cache etnotamment le rôle caching Azure• Anticiper la capacité de traitement unitaire desbases– 10 bases de 1 Go ou une base de 10 Go ont le mêmecout..SQL Azure Database - Pratiques• Concevoir l’application en adressant SQLDatabase comme un SQL Server « on premise » enterme de scalabilité.• Ignorer vos objectifs de montée en charge enmétriques d’usage simultané.– Nombre d’utilisateurs simultanés , nombre de requêtespar secondes..• Multiplier les requêtes unitaires• Constituer des tables de plus de 10 Go (environ)– La limites des logs transactions empêche par exemple laré indexation sur les grandes tables– Si besoin , répartir sur plusieurs tables et utiliser une vuepartionnéeQuelques bonnes pratiques Quelques pratiques à éviter
  • Architecture / Azure / Cloud• Mise en place systématique de « Retrypolicies » et « exponential back off » .– Applicable aussi « On Premise ».– Connections et Commandes• Log systématique des erreurs deThrottling et du contexte associé.• Encapsuler les connections dans un using– using (var conn = new SqlConnection(connStr)) { //Appel client SQL }• Effectuer un test de charge del’application « end to end » et comparerles résultats aux objectifs fixés en termed’usage simultané.SQL Azure Database - Pratiques• Omettre la charge relative à une copie ouun export– Augmente la charge sur la base de donnée et peutgénérer des conditions de Throttling• Centraliser les métadonnées en base– Crée un « Single Point of Failure » et un point decontention : préférer une combinaison de cache et / oudistribution sur plusieurs bases.• Mettre des GUID dans le clustered index.– NEWSEQUENTIAL ID non supporté dans SQL Azure :impacte fortement performances et scalabilité.Quelques bonnes pratiques Quelques pratiques à éviter
  • Architecture / Azure / Cloud• Gestion des connections• Equilibrer les Shards , en charge , en volumétrie , Rééquilibrer les shards.• Quel shard utiliser pour persister une donnée ?• Comment efficacement lire une donnée , dans quel shard la chercher ?• Comment éviter les requêtes « fan out » ?• Quel algorithme de génération d’ID utiliser pour efficacement lire, écrire et retrouver les données ?• Exécution Parallèle ou séquentielle des requêtes vers les shards ?• Comment identifier le bon shard source pour mettre à jour une donnée ?• Jointures entre shards ?• Gestion relationnelle des données de différents shards• Gestion de la sécurité• Import des données• Disaster Recovery• Compatibilité de l’implémentation du sharding avec les outils connexes (import , applications)• Gestion des données de références• Opérations globales aux Shards : Agrégation / Tri• Transactions distribuées• Gestion des schémas de base de données , des mise à jours de versions• Augmentation de la scalabilité , du nombre de shards• Diminution du nombre de shardsSQL Azure Database Sharding challenges
  • Architecture / Azure / Cloud• Extension du modèle « Scale out »à la Base de données• Implémentation de Sharding« horizontal »• Permet une montée en chargeavec continuité de serviceSQL Database – SQL Azure Federationhttp://msdn.microsoft.com/en-us/library/windowsazure/hh597452.aspx
  • Architecture / Azure / CloudCONCEPTS• Fédération• Membre de fédération• Federation Root• Clef de Federation (Distribution Key)• Entité atomiques• Tables fédérées• Tables de référenceSQL Database – SQL Azure FederationGESTION DES FEDERATIONSCREATE FEDERATION …Crée l’objet fédération dans la base utilisateurUSE FEDERATION ….Connecte l’utilisateur au membre de lafédérationALTER FEDERATION …Redistribue / efface les donnée s «split at» ou«drop at»DROP FEDERATION …Efface metadata, objets et tous les membresCREATE TABLECREATE TABLE[ schema_name . ] table_ame( { <column_definition> |<computed_column_definition> }[ < table_constraint> ] [ ,...n ] )FEDERATED ON (distribution_name =column_name)http://msdn.microsoft.com/en-us/magazine/hh848258.aspx
  • Architecture / Azure / CloudSQL Database – SQL Azure FederationExemple de schéma de distribution uniforme en volume indépendant dunombre de shards avec clef de fédération entière– Distribution via les bits de poids forts de la clef de fédération– Construit avec un entier une distribution « indépendante » du nombre de shards– Fonctionne uniquement avec un nombre de shard = 2^n– Implique le split « au milieu » de tous les shards pour conserver la distribution– La séquence peut être répétée par octet– Faite ci-dessous pour 1 octet (256 shards max)Les GUID permettent également d’obtenir une répartition relativement uniforme
  • Architecture / Azure / Cloud– Définir une clef de fédération répartissant« au mieux » charge et volumétrie , autantque possible indépendamment du nombrede shards– Penser à la compatibilité des outilsconnexes à une base fédérée• exemple : « USE FEDERATION »Statement …– Anticiper l’absence de support de colonne« identity » dans les shards.– Conserver les clef de fédération dans lecontexte applicatif ou être à même de lesreconstituer , afin adresser « directement »le « bon » shard , et éviter les « fan outs »SQL Azure Federation – pratiques 1/2– Effectuer un « SPLIT » sans anticiper unéventuel « MERGE .– Multiplier les requêtes « Fan out » quimultiplient connections , requêtes etaugmentent les temps de réponseutilisateurs.– Multiplier les requêtes vers la base racinede fédération , point de contention.Quelques bonnes pratiques Quelques pratiques à éviter
  • Architecture / Azure / Cloud– Lors des mises à jour , assurer lacompatibilité des applications avecles versions ancienne et nouvelle dumodèle de données• Pas d’intégrité transactionnelle entre Shards lors desmises à jour de schéma et/ou données.– Utiliser plutôt un « Big int » qu’un« int » pour les clefs de fédérationsentières• Permet de conserver les bits de poidsforts pour éventuellement agir sur la clefde fédération– Effectuer un test de charge del’application « end to end » et lescomparer aux objectifs fixés , enmétriques d’usage simultanées.SQL Azure Federation – Pratiques 2/2– Omettre de prendre en compte le LoadBalancer Azure qui à ce jour supporte aumaximum 64000 connections entre deuxadresses IP.• Le connexion pool ADO.NET est par défaut de 100connections. 64 instances * 10 bases * 100 connectionspermettent d’atteindre cette limite de connections , cequi peut donc nécessiter d’ ajuster le nombre deconnections par pool ou encore de créer des affinitésde connections entre rôles back end (Worker rôles) etbases de données– Effectuer des shards de plus de 50 Go• Les opérations de copy or backups se rallongent alorssensiblement . Le service arrête les traitements nonterminés après 24h.– Mettre des GUID dans le clustered index.• NEW_SEQUENTIALID étant non supporté dans SQLAzure , cela impacte fortement scalabilité etperformances.Quelques bonnes pratiques Quelques pratiques à éviter
  • AZURE VIRTUAL MACHINESChapitre 5Architecture / Azure / Cloud
  • Architecture / Azure / CloudMachine Virtuelle Azure IaaS• Une machine virtuelle avec disquespersistants sur blobs Azure• Des accès IO optimisés• Un cache host est disponible etactivé par défaut pour les disquessystèmesAzure Virtual Machines (Preview)
  • Azure Virtual Machine - SizesEach Persistent Data Disk Can be up to 1 TB
  • Azure Virtual Machines – Host CacheDisk Type Default SupportedOS Disk ReadWrite ReadOnly / ReadWriteData Disk None None, ReadOnly , ReadWriteModify using Set-AzureOSDisk or Set-AzureDataDisk• Le cache en lecture est stocké en mémoire et sur le disque du Host• Le cache en écriture est stocké en mémoire du Host
  • Architecture / Azure / Cloud• Importance d’exploiter au mieux les I/O d’une machine virtuelledisposant de plusieurs disques , par exemple un Serveur SQL..– 20000 transactions / seconde par compte de stockage– Chaque IO entre le Host (pas la VM) et le disque génère une transaction RESTpar tranches de 128 K.• Le portail (https://manage.windowsazure.com ) ne permet pasaujourd’hui d’ajouter un disque de données pointant sur un compte destockage différent de celui du disque système.• Le Windows Azure Powershell (http://msdn.microsoft.com/en-us/library/windowsazure/jj152841.aspx ) offre heureusement denombreuses possibilités dont celle-ci..Azure Virtual Machines – Scalabilité des I/O#Exemple avec Windows Azure Powershell#Creation d’un compte de stockageNew-AzureStorageAccount -StorageAccountName “CompteDataDisk1" -Label" CompteDataDisk1 " -Location “Western Europe”#Ajout d’un disque à une machine virtuelle sousle compte crééGet-AzureVM “MySQLServerVM" -Name "MySQLServerVM " | Add-AzureDataDisk -CreateNew -DiskSizeInGB 100 -MediaLocation `"https:// CompteDataDisk1.blob.core.windows.net/vms/Disk1.vhd" -DiskLabel “DataDisk1" -LUN 1 | Update-AzureVMInformations plus détaillées en consultant cet excellent livre blanc sur les machines virtuelles Azure IaaS (anglais) :http://blogs.msdn.com/b/windowsazurestorage/archive/2012/06/28/exploring-windows-azure-drives-disks-and-images.aspx
  • Architecture / Azure / CloudMachine Virtuelle Azure IaaS• Scale out / Scale in aisé pour les rôles PaaS (Portail,REST, Powershell…)• Scale out / Scale in intéressant également pour les VMsIaaS. (Paiement à l’usage, Pic de charges)• Celles-ci sont associées à un ou plusieurs disqueshébergés sur un BLOB Azure.• Les VMS se répliquent sur la base d’images utilisateurs.http://msdn.microsoft.com/en-us/library/windowsazure/jj835082.aspx#BKMK_CaptureScalabilité des Machines Virtuelles IaaS• Un compte de stockage , 20000 Transactions REST/s• 1 Transaction REST par block de 128k (sans hit dans lecache host)• N VM sur 1 compte de stockage = 20000/N REST TPS=> Préférer un compte de stockage dédié pour les disques.Azure Virtual Machines – Scale out
  • AZURE TRAFFIC MANAGERChapitre 5 BisArchitecture / Azure / Cloud
  • Architecture / Azure / Cloud• Un point d’entrée VIP permettant degérer les flux vers la plateforme Azureselon 3 modes :– Performance– Failover– Load Balancing• Permet de distribuer la charge surplusieurs cloud services Azure , dansle même ou sur plusieurs Data Center.• Permet aussi de réduire les « singlepoints of failures » si besoin de Hautedisponibilité• Permet d’améliorer la latence pourservir des utilisateurs géo-distribuésWindows Azure Traffic ManagerSQL Azure SQL AzureCloud Service 1 Cloud Service 2Synchronisation
  • Windows Azure Traffic ManagerFonctionnement
  • AZURE SERVICE BUSChapitre 6Architecture / Azure / Cloud
  • Architecture / Azure / Cloud• Nouvelle capacité :– Relais de services– Relais de messagerie avec ordre garanti– Système d’abonnement Publish/Subscribe• Différent des Queues Azure :– Multi-protocoles– FIFO garantie– Support des transactions, des lectures bloquantes– Mode batch en envoi– Support natif des workflowsAzure Service Bus
  • Architecture / Azure / CloudComparison Criteria Windows Azure Queues Service Bus QueuesMaximum message size64 KB(48 KB when using Base64encoding)256 KB(including both headerand body, maximumheader size: 64 KB)Maximum queue size100 TB(limited to a single storageaccount capacity)1, 2, 3, 4 or 5 GB(defined upon creation ofa queue)Maximum message TTL 7 days UnlimitedMaximum number ofqueuesUnlimited10,000(per service namespace,can be increased)Maximum number ofconcurrent clientsUnlimitedUnlimited(100 concurrentconnection limit onlyapplies to TCP protocol-based communication)Comparison Criteria Windows Azure Queues Service Bus QueuesMaximum message size64 KB(48 KB when usingBase64 encoding)256 KB(including both headerand body, maximumheader size: 64 KB)Maximum queue size100 TB(limited to a singlestorage accountcapacity)1, 2, 3, 4 or 5 GB(defined upon creationof a queue)Maximum message TTL 7 days UnlimitedMaximum number ofqueuesUnlimited10,000(per service namespace,can be increased)Maximum number ofconcurrent clientsUnlimitedUnlimited(100 concurrentconnection limit onlyapplies to TCP protocol-based communication)Azure Service Bus
  • Architecture / Azure / Cloud• Adresse :– Découplage temporel et lissage de charge– Découplage physique des traitements– Pattern de publication (1-n)– Intégration (adaptateur BizTalk 2013, support AMQP)– Interconnections de services Azure et de services “on-premise”.– Mutualisation de servicesAzure Service Bus
  • Architecture / Azure / CloudAzure Service Bus - Scénario 1 : relais de service
  • Architecture / Azure / CloudScénario 2 : Intégration avec d’autres services
  • Architecture / Azure / CloudComparison Criteria Windows Azure Queues Service Bus QueuesMaximum throughputUp to 2,000 messages persecondUp to 2,000 messages persecond(based on benchmark with 1 KBmessages)Average latency10 ms(with TCP Nagle disabled)20-100 msThrottling behaviorReject with HTTP 503 code(throttled requests are nottreated as billable)Reject with exception/HTTP503(throttled requests are nottreated as billable)Scalability targets
  • Architecture / Azure / Cloud• Utilisez plusieurs queues• Concevez les clients en fonction des limites :– Une Factory et ses entités (messages, queues) partagent unemême connection IP. Il y a donc contention implicite deséchanges.– Un relais utilise 25 listeners.– Par exemple, si vous concevez un service qui consommé unrelais, pensez à render le service poolable(ObjectPoolingAttribute)Azure Service Bus - Bonnes pratiques d’architecture
  • Architecture / Azure / Cloud• Privilégiez l’API cliente à l’API WCF ou l’API REST• Mettez en cache les objets QueueClient,MessageSender ou MessagingFactory• Utilisez plusieurs Factory (une connection IP parFactory)• Considérez en reception le mode Receive anddelete au mode Peek-lock• Privilégiez le mode batchAZURE SERVICE BUS - Bonnes pratiques de développement
  • WINDOWS AZURE ROLE CACHING(PREVIEW)Chapitre 6Architecture / Azure / Cloud
  • Architecture / Azure / Cloud• Nouvelle capacité :– Solution dédiée et scalable– Réutilisation possible de vos rôles existants– Proche de AppFabric Caching• Différent du Shared Caching :– Machines dédiées vs multi-tenant– Pas limité à 4 Go– Haute disponibilitéWindows Azure Role Caching
  • Architecture / Azure / CloudAzure Role Caching - Configuration
  • Architecture / Azure / CloudComparison Criteria Windows Azure Queues Service Bus QueuesMaximum message size64 KB(48 KB when using Base64encoding)256 KB(including both headerand body, maximumheader size: 64 KB)Maximum queue size100 TB(limited to a single storageaccount capacity)1, 2, 3, 4 or 5 GB(defined upon creation ofa queue)Maximum message TTL 7 days UnlimitedMaximum number ofqueuesUnlimited10,000(per service namespace,can be increased)Maximum number ofconcurrent clientsUnlimitedUnlimited(100 concurrentconnection limit onlyapplies to TCP protocol-based communication)Azure Role Caching - Taille mémoire disponible (dédiée)Role SizeAvailable Memory forCaching % of RAM Use based on Role SizeSmall Approximately 1GB 57%Medium Approximately 2.5GB 57%Large Approximately 5.5GB 79%X-Large Approximately 11GB 79%
  • Architecture / Azure / CloudComparison Criteria Windows Azure Queues Service Bus QueuesMaximum message size64 KB(48 KB when using Base64encoding)256 KB(including both headerand body, maximumheader size: 64 KB)Maximum queue size100 TB(limited to a single storageaccount capacity)1, 2, 3, 4 or 5 GB(defined upon creation ofa queue)Maximum message TTL 7 days UnlimitedMaximum number ofqueuesUnlimited10,000(per service namespace,can be increased)Maximum number ofconcurrent clientsUnlimitedUnlimited(100 concurrentconnection limit onlyapplies to TCP protocol-based communication)Azure Role Caching - Taille mémoire disponible (non dédiée)Role Size Total RAM10%/90%Reserved/Available20%/80%Reserved/Available40%/60%Reserved/AvailableX-Small 768MB N/ASmall 1.75GB 175MB/1.575GB 350MB/1.4GB 700MB/1.05GBMedium 3.5GB 350MB/3.15GB 700MB/2.8GB 1.4GB/2.1GBLarge 7GB 700MB/6.3GB 1.4GB/ 5.6GB 2.8GB/4.2GBX-Large 14GB 1.4GB/12.6GB 2.8GB / 11.2GB 5.6GB/8.4GB
  • Architecture / Azure / Cloud• Utilisez 3 rôles, voir 4, pour garantir la hautedisponibilité• Ne mettez en haute disponibilité que ce qui estnécessaire (les données vraiment coûteuses àrecharger)• Utilisez avec précaution les régionsWindows Azure Role Caching - Bonnes Pratiques
  • Architecture / Azure / CloudWindows Azure Role Caching – Bonnes Pratiques
  • Architecture / Azure / CloudType of Data Use HA Use Region Dedicated Co-LocatedSession XOutput XGeneral Data X XPre-fetch X XPre-calc X XImportant Data XFilterable X XWindows Azure Role Caching – Bonnes pratiques
  • AZURE LOAD TESTSChapitre 8Architecture / Azure / Cloud
  • Architecture / Azure / Cloud• Exécution de tests de charge ausein même d’un Datacenter Azure– Réduit la latence réseau– Pas de couts de bande passante– Automatise le déploiement du nombreagents nécessaires• Bénéficie des fonctionnalités detests fonctionnels et de charge deVisual StudioWindows Azure tests de chargehttp://visualstudiomagazine.com/articles/2010/07/08/load-testing-with-visual-studio-2010.aspx
  • Architecture / Azure / Cloud• Une solution hybride PaaS / Onpremise existe et est documentéesur MSDN.– Contrôleurs et injecteurs dans Azure PaaS– Visual Studio On Premise– Communication avec Windows AzureConnect– Stockage des résultats dans SQL Expresssur le rôle Contrôleur– Automatise le déploiement du nombreagents nécessairesWindows Azure - tests de chargehttp://blogs.msdn.com/b/benjguin/archive/2011/09/02/load-testing-from-windows-azure-tests-de-charge-depuis-windows-azure.aspx
  • Architecture / Azure / Cloud• Solution IaaS / PaaS– Contrôleur et SQL Server dans Azure IaaS– Injecteurs dans Azure PaaS– Communications via Azure Virtual Network• Bénéfice:– Réduit la latence réseau– Pas de couts de bande passante– Automatise le déploiement du nombre agentsnécessaires:– Persistance des résultats (reimaging des rôles PaaS)Windows Azure - tests de chargeAzureVPNRDP
  • DEMONSTRATIONArchitecture / Azure / Cloud
  • AZURE MONITORINGChapitre 8Architecture / Azure / Cloud
  • Architecture / Azure / Cloud• Management Pack OperationsManager pour Windows Azure• Instrumentez l’application Azure• Activer le mode « Full-trusted » surles rôles à surveiller• Activer et configurer les diagnosticsdans l’application• Configurer l’écriture desdiagnostics dans un stockagepersistant• Définissez les éléments à superviserRules & Monitor• Connectez Operations Manager àl’environnement Azure à superviserSuperviser une application Azurehttp://msdn.microsoft.com/en-us/library/windowsazure/gg676009.aspx
  • Architecture / Azure / CloudSuperviser une application Azure - Démonstration
  • SYNTHÈSEChapitre 9Architecture / Azure / Cloud
  • Architecture / Azure / Cloud• Elasticité– La valeur ajoutée du cloud est basée sur l’élasticité « Scale out » / « Scale in »de la plateforme et le cout à l’usage des ressources.• Géo-distribution– La plateforme Azure donne un accès instantané à un déploiement hautementdisponible mondialement géo-distribué.• Partitionnement de la charge– Un existant « on premise » basé sur une logique de « Scale up » doit êtrepartitionné pour tirer partie du cloud.La prise en compte de ces trois critères associés à la mise en place d’unearchitecture adaptée permettent de tirer pleinement partie de la plateformeAzure et d’en attendre un ROI significatif.SYNTHESE
  • QUESTIONS ?Architecture / Azure / Cloud
  • Support PremierEntrepriseStrategyMicrosoftConsulting ServicesConcevoiretDéployerImagineret Planifier OptimiseretMaintenirMicrosoft Enterprise ServicesEnvironnement de travail et mobilitéLa collaborationLa productivitéApplications Uniques et InnovantesCloud Privé et Cloud PublicL’automatisation de processus métierLes réseaux sociaux d’entrepriseBusiness Intelligence et Big DataMicrosoftServices700Experts enFranceUnécosystèmePartenairesUn capitalintellectuel
  • Architecture / Azure / Cloud