Download - Monter en charge, tester et surveiller avec une application Windows Azure : les bonnes pratiques
Monter en charge , tester et surveiller
avec une application Azure
Les bonnes pratiques
Olivier Sallaberry , Patrice Mana’ch , Fabrice Meillon
Architectes - Microsoft
Architecture / 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éponses
Agenda
INTRODUCTION
Chapitre 1
Architecture / Azure / Cloud
Architecture / Azure / Cloud
Introduction
New
Ecosystems
Usage
Based
Elastic
EconomicsSolid
Managed
Resources
Les problématiques de montée en charge et de monitoring des applications Azure sont « récurrentes » lors de nos engagements et ont une incidence forte sur la définition d’une architecture cible , le dimensionnement et à fortiori le calcul des OPEX
Cette session a pour objectif de vous apporter un éclairage sur ces sujets issus de nos expériences projets .
Windows Azure est aujourd’hui:• une plateforme riche , • améliorée constamment. Son usage se développe largement…
Architecture / Azure/ Cloud
INTRODUCTION – VUE D’ENSEMBLE DE LA PLATEFORME
http://www.microsoft.com/en-us/download/details.aspx?id=35473
MONTÉE EN CHARGE ET WINDOWS AZURE
VUE D’ENSEMBLE
Chapitre 2
Architecture / Azure / Cloud
Architecture / Azure / Cloud
• Montée en charge Capacité de la solution à servir un nombre croissant d’utilisateurs / consommateurs
simultanés. Au-delà d’un seuil, le service n’est plus rendu.
• PerformanceCapacité de la solution à servir aux utilisateurs / consommateurs un temps de réponse
inférieur à un seuil convenu pour une fonction donnée.
Montée en charge : Vue d’ensemble Capacité à 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 »
– Throttling
Monté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 / Cloud
Montée en charge : vue d’ensemble
Elasticité
Contention
« Verticale »Taille D’instance
« Horizontale »Nombre d’instances
Points de contention = points d’attention…
Architecture / Azure / Cloud
Montée en charge : vue d’ensemble
• Désynchronisation
– Absorber et lisser la charge par
mécanismes asynchrones (via
queues 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 par
les points de contention back-end
– Assurer la scalabilité du cache lui-
même.
LE STOCKAGE REST AZURE
Chapitre 3
Architecture / Azure / Cloud
Architecture / Azure / Cloud
Stockage 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 applications
Windows Azure.
Architecture / Azure / Cloud
Stockage REST Azure - Fonctionnement
http://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)
Cible
Transactions 20000 entités/ messages/ Blobs
par seconde
Bande passante pour un compte géo-redondant Ingress : 5 Go/s
Egress : 10 Go/s
Bande passante pour un compte localement redondant Ingress : 10 Go/s
Egress : 15 Go/s
Stockage REST azure – Quelques chiffres
http://blogs.msdn.com/b/windowsazurestorage/archive/2012/11/04/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx
« Scalability targets » par
partition
Clef de partition Cible
Queue Queue Name 2000 messages/s
Table Partition Key 2000 entités/s
Blob Container Name + Blob Name 60 Mo/s par blob
Des cibles de montée en charge améliorées en 2012..
Architecture / Azure / Cloud
• Prendre en compte les objectifs de scalabilité du compte de stockage , puis celles des blobs, tables et queues
• Distribuer sur plusieurs comptes de stockage, si nécessaire. Se réserver la possibilité de le faire.
• Mise en place systématique de « Retry policies » et « exponential back off »
• Choisir avec attention sa clef de partition pour les tables– Trop petite : limite les requêtes batch (possibles
sur une partition)
– Trop grande : contentions éventuelles
Stockage REST Azure – Pratiques 1/2
• Mettre toutes les ressources REST sous le même compte de stockage après avoir lu la page 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étrie sur le même compte de stockage que les données de production
Quelques bonnes pratiques Quelques pratiques à éviter
Architecture / Azure / Cloud
• Utiliser si possible les Batch transactions pour les tables – maximum 100 entités sur la même partition)
• Utiliser plusieurs queues si plus de 2000 messages secondes
• Dupliquer les blobs sur plusieurs comptes au besoin , penser au CDN…
• Paralléliser les appels – Exemple : upload de Blobs
• Faire un test de charge systématique de la solution « end to end » depuis le même DC Azure
Stockage REST Azure – Pratiques 2/2
• Ne pas utiliser le mécanisme d’écriture de diagnostic 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 que cibler ou traiter par lots – Exemple1 : Multiplier les requêtes de Table générant
des « continuation tokens » (plus de 1000 entités ou 5 secondes , limites de partitionnement)
– Exemple 2: effacer ligne à ligne de milliers d’entités (anticiper l’architecture cible pour plutôt effacer la table..)
• Choisir des noms de propriétés trop long pour les tables , les métadonnées sont écrites en ligne et leur taille entrent en compte dans la limite de 1Mo par entité.
Quelques bonnes pratiques Quelques pratiques à éviter
WINDOWS AZURE SQL DATABASE
Chapitre 4
Architecture / Azure / Cloud
Architecture / Azure / Cloud
• SGBD « as a service »
• Basé sur la technologie SQL Server
• Construit pour le cloud avec haute disponibilité et
tolérance aux pannes.
• Self Service (provisionning / Management)
• Support de TSQL et des outils (SSMS..)
• Différences SQL Server / Windows Azure SQL Database
Windows Azure SQL Database
http://msdn.microsoft.com/en-us/library/windowsazure/ff394115.aspx
Architecture / Azure / Cloud
Windows Azure SQL Database
Application
Internet
LBTDS (tcp)
TDS (tcp)
TDS (tcp)
Apps use standard SQL client libraries: ODBC, ADO.Net, PHP, …
Load balancer forwards ‘sticky’ sessions to TDS protocol tier
Gateway Gateway Gateway Gateway Gateway Gateway
Scalability and Availability: Fabric, Failover, Replication, and Load balancing
SQL SQL SQL SQL SQLSQL
Gateway: TDS protocol gateway, enforces AUTHN/AUTHZ policy; proxy to backend SQL
Architecture / Azure / Cloud
Pourquoi 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 service
Windows Azure SQL Database
Architecture / Azure / Cloud
Pourquoi le « Sharding » ?• Par retour d’expérience projets , une SQL Database supporte
actuellement :– 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 3 copies de chaque base
Windows Azure SQL Database
Architecture / Azure / Cloud
• ShardingDistribution de la charge et/ou du volume sur plusieurs bases
• Sharding « Vertical »Distribution des bases ou du modèle de données entier selon des critères fonctionnels et/ou techniquesExemple : n bases read only et round robin applicatif
• Sharding « Horizontal »Distribution de groupes d’entités atomiquement indépendants , appartenant au même modèle , sur plusieurs bases.Exemple : SQL Azure Federation
Windows Azure SQL Database – Sharding
Sharding « 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 et
les utilisateurs .
– Les transactions sont abandonnée à l’atteinte d’un seuil et le
système prévient l’exécution des suivantes tant qu’un seuil
reste dépassé.
SQL Database - Throttling
http://msdn.microsoft.com/en-us/library/windowsazure/jj717232.aspx
Architecture / Azure / Cloud
• Considérer les options de Sharding dès la phase de conception et si possible ouvrir ces options a défaut de les implémenter dès la première version.
• Minimiser le nombre de requêtes unitaires et préférer les échanges applications / bases de forte granularité
– DTOS (Data Transfert Object)
– requêtes par lots (exemples : TVPs Table Value Parameters).
• Considérer la mise en place de cache et notamment le rôle caching Azure
• Anticiper la capacité de traitement unitaire des bases
– 10 bases de 1 Go ou une base de 10 Go ont le même cout..
SQL Azure Database - Pratiques
• Concevoir l’application en adressant SQL
Database comme un SQL Server « on premise » en
terme de scalabilité.
• Ignorer vos objectifs de montée en charge en
métriques d’usage simultané. – Nombre d’utilisateurs simultanés , nombre de requêtes
par secondes..
• Multiplier les requêtes unitaires
• Constituer des tables de plus de 10 Go (environ) – La limites des logs transactions empêche par exemple la
ré indexation sur les grandes tables
– Si besoin , répartir sur plusieurs tables et utiliser une vue partionnée
Quelques bonnes pratiques Quelques pratiques à éviter
Architecture / Azure / Cloud
• Mise en place systématique de « Retry policies » et « exponential back off » .
– Applicable aussi « On Premise ».
– Connections et Commandes
• Log systématique des erreurs de Throttling et du contexte associé.
• Encapsuler les connections dans un using– using (var conn = new SqlConnection(connStr)) { //
Appel client SQL }
• Effectuer un test de charge de l’application « end to end » et comparer les résultats aux objectifs fixés en terme d’usage simultané.
SQL Azure Database - Pratiques
• Omettre la charge relative à une copie ou
un export – Augmente la charge sur la base de donnée et peut
générer des conditions de Throttling
• Centraliser les métadonnées en base– Crée un « Single Point of Failure » et un point de
contention : préférer une combinaison de cache et / ou distribution 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 shards
SQL 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 charge
avec continuité de service
SQL Database – SQL Azure Federation
http://msdn.microsoft.com/en-us/library/windowsazure/hh597452.aspx
Architecture / Azure / Cloud
CONCEPTS
• 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érence
SQL Database – SQL Azure FederationGESTION DES FEDERATIONS
CREATE FEDERATION …
Crée l’objet fédération dans la base utilisateur
USE FEDERATION ….
Connecte l’utilisateur au membre de la
fédération
ALTER FEDERATION …
Redistribue / efface les donnée s «split at» ou
«drop at»
DROP FEDERATION …
Efface metadata, objets et tous les membres
CREATE 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 / Cloud
SQL Database – SQL Azure FederationExemple de schéma de distribution uniforme en volume indépendant du nombre 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 , autant que possible indépendamment du nombre de shards
– Penser à la compatibilité des outils connexes à 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 le contexte applicatif ou être à même de les reconstituer , 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 » qui
multiplient connections , requêtes et
augmentent les temps de réponse
utilisateurs.
– Multiplier les requêtes vers la base racine
de fédération , point de contention.
Quelques bonnes pratiques Quelques pratiques à éviter
Architecture / Azure / Cloud
– Lors des mises à jour , assurer la compatibilité des applications avec les versions ancienne et nouvelle du modèle de données
• Pas d’intégrité transactionnelle entre Shards lors des mises à jour de schéma et/ou données.
– Utiliser plutôt un « Big int » qu’un « int » pour les clefs de fédérations entières
• Permet de conserver les bits de poids forts pour éventuellement agir sur la clef de fédération
– Effectuer un test de charge de l’application « end to end » et les comparer aux objectifs fixés , en métriques d’usage simultanées.
SQL Azure Federation – Pratiques 2/2
– Omettre de prendre en compte le Load Balancer Azure qui à ce jour supporte au maximum 64000 connections entre deux adresses IP.
• Le connexion pool ADO.NET est par défaut de 100 connections. 64 instances * 10 bases * 100 connections permettent d’atteindre cette limite de connections , ce qui peut donc nécessiter d’ ajuster le nombre de connections par pool ou encore de créer des affinités de connections entre rôles back end (Worker rôles) et bases de données
– Effectuer des shards de plus de 50 Go• Les opérations de copy or backups se rallongent alors
sensiblement . Le service arrête les traitements non terminés après 24h.
– Mettre des GUID dans le clustered index. • NEW_SEQUENTIALID étant non supporté dans SQL
Azure , cela impacte fortement scalabilité et performances.
Quelques bonnes pratiques Quelques pratiques à éviter
AZURE VIRTUAL MACHINES
Chapitre 5
Architecture / Azure / Cloud
Architecture / Azure / Cloud
Machine Virtuelle Azure IaaS• Une machine virtuelle avec disques
persistants sur blobs Azure
• Des accès IO optimisés
• Un cache host est disponible et activé par défaut pour les disques systèmes
Azure Virtual Machines (Preview)
Azure Virtual Machine - Sizes
Each Persistent Data Disk Can be up to 1 TB
Azure Virtual Machines – Host Cache
Disk Type Default Supported
OS Disk ReadWrite ReadOnly / ReadWrite
Data Disk None None, ReadOnly , ReadWrite
Modify 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 virtuelle
disposant 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 REST
par tranches de 128 K.
• Le portail (https://manage.windowsazure.com ) ne permet pas
aujourd’hui d’ajouter un disque de données pointant sur un compte de
stockage différent de celui du disque système.
• Le Windows Azure Powershell (http://msdn.microsoft.com/en-
us/library/windowsazure/jj152841.aspx ) offre heureusement de
nombreuses 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 sous le 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-AzureVM
Informations 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 / Cloud
Machine 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 disques hé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_Capture
Scalabilité des Machines Virtuelles IaaS
• Un compte de stockage , 20000 Transactions REST/s
• 1 Transaction REST par block de 128k (sans hit dans le cache 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 MANAGER
Chapitre 5 Bis
Architecture / Azure / Cloud
Architecture / Azure / Cloud
• Un point d’entrée VIP permettant de gérer les flux vers la plateforme Azure selon 3 modes : – Performance
– Failover
– Load Balancing
• Permet de distribuer la charge sur plusieurs cloud services Azure , dans le même ou sur plusieurs Data Center.
• Permet aussi de réduire les « single points of failures » si besoin de Haute disponibilité
• Permet d’améliorer la latence pour servir des utilisateurs géo-distribués
Windows Azure Traffic Manager
SQL Azure SQL Azure
Cloud Service 1 Cloud Service 2
Synchronisation
Windows Azure Traffic ManagerFonctionnement
AZURE SERVICE BUS
Chapitre 6
Architecture / 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 workflows
Azure Service Bus
Architecture / Azure / CloudComparison Criteria Windows Azure Queues Service Bus Queues
Maximum message size
64 KB
(48 KB when using Base64
encoding)
256 KB
(including both header
and body, maximum
header size: 64 KB)
Maximum queue size
100 TB
(limited to a single storage
account capacity)
1, 2, 3, 4 or 5 GB
(defined upon creation of
a queue)
Maximum message TTL 7 days Unlimited
Maximum number of
queuesUnlimited
10,000
(per service namespace,
can be increased)
Maximum number of
concurrent clientsUnlimited
Unlimited
(100 concurrent
connection limit only
applies to TCP protocol-
based communication)
Comparison Criteria Windows Azure Queues Service Bus Queues
Maximum message size
64 KB
(48 KB when using
Base64 encoding)
256 KB
(including both header
and body, maximum
header size: 64 KB)
Maximum queue size
100 TB
(limited to a single
storage account
capacity)
1, 2, 3, 4 or 5 GB
(defined upon creation
of a queue)
Maximum message TTL 7 days Unlimited
Maximum number of
queuesUnlimited
10,000
(per service namespace,
can be increased)
Maximum number of
concurrent clientsUnlimited
Unlimited
(100 concurrent
connection limit only
applies 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 services
Azure Service Bus
Architecture / Azure / Cloud
Azure Service Bus - Scénario 1 : relais de service
Architecture / Azure / Cloud
Scénario 2 : Intégration avec d’autres services
Architecture / Azure / Cloud
Comparison Criteria Windows Azure Queues Service Bus Queues
Maximum throughputUp to 2,000 messages per
second
Up to 2,000 messages per
second
(based on benchmark with 1 KB
messages)
Average latency10 ms
(with TCP Nagle disabled)20-100 ms
Throttling behavior
Reject with HTTP 503 code
(throttled requests are not
treated as billable)
Reject with exception/HTTP
503
(throttled requests are not
treated 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 une
mê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é un
relais, 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 par
Factory)• Considérez en reception le mode Receive and
delete au mode Peek-lock• Privilégiez le mode batch
AZURE SERVICE BUS - Bonnes pratiques de développement
WINDOWS AZURE ROLE CACHING
(PREVIEW)
Chapitre 6
Architecture / 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 / Cloud
Azure Role Caching - Configuration
Architecture / Azure / CloudComparison Criteria Windows Azure Queues Service Bus Queues
Maximum message size
64 KB
(48 KB when using Base64
encoding)
256 KB
(including both header
and body, maximum
header size: 64 KB)
Maximum queue size
100 TB
(limited to a single storage
account capacity)
1, 2, 3, 4 or 5 GB
(defined upon creation of
a queue)
Maximum message TTL 7 days Unlimited
Maximum number of
queuesUnlimited
10,000
(per service namespace,
can be increased)
Maximum number of
concurrent clientsUnlimited
Unlimited
(100 concurrent
connection limit only
applies to TCP protocol-
based communication)
Azure Role Caching - Taille mémoire disponible (dédiée)
Role Size
Available Memory for
Caching % of RAM Use based on Role Size
Small 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 Queues
Maximum message size
64 KB
(48 KB when using Base64
encoding)
256 KB
(including both header
and body, maximum
header size: 64 KB)
Maximum queue size
100 TB
(limited to a single storage
account capacity)
1, 2, 3, 4 or 5 GB
(defined upon creation of
a queue)
Maximum message TTL 7 days Unlimited
Maximum number of
queuesUnlimited
10,000
(per service namespace,
can be increased)
Maximum number of
concurrent clientsUnlimited
Unlimited
(100 concurrent
connection limit only
applies to TCP protocol-
based communication)
Azure Role Caching - Taille mémoire disponible (non dédiée)
Role Size Total RAM
10%/90%
Reserved/Available
20%/80%
Reserved/Available
40%/60%
Reserved/Available
X-Small 768MB N/A
Small 1.75GB 175MB/1.575GB 350MB/1.4GB 700MB/1.05GB
Medium 3.5GB 350MB/3.15GB 700MB/2.8GB 1.4GB/2.1GB
Large 7GB 700MB/6.3GB 1.4GB/ 5.6GB 2.8GB/4.2GB
X-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 haute
disponibilité
• Ne mettez en haute disponibilité que ce qui est
nécessaire (les données vraiment coûteuses à
recharger)
• Utilisez avec précaution les régions
Windows Azure Role Caching - Bonnes Pratiques
Architecture / Azure / Cloud
Windows Azure Role Caching – Bonnes Pratiques
Architecture / Azure / Cloud
Type of Data Use HA Use Region Dedicated Co-Located
Session X
Output X
General Data X X
Pre-fetch X X
Pre-calc X X
Important Data X
Filterable X X
Windows Azure Role Caching – Bonnes pratiques
AZURE LOAD TESTS
Chapitre 8
Architecture / Azure / Cloud
Architecture / Azure / Cloud
• Exécution de tests de charge au sein même d’un Datacenter Azure– Réduit la latence réseau
– Pas de couts de bande passante
– Automatise le déploiement du nombre agents nécessaires
• Bénéficie des fonctionnalités de tests fonctionnels et de charge de Visual Studio
Windows Azure tests de charge
http://visualstudiomagazine.com/articles/2010/07/08/load-testing-with-visual-studio-2010.aspx
Architecture / Azure / Cloud
• Une solution hybride PaaS / On premise existe et est documentée sur MSDN.– Contrôleurs et injecteurs dans Azure PaaS
– Visual Studio On Premise
– Communication avec Windows Azure Connect
– Stockage des résultats dans SQL Express sur le rôle Contrôleur
– Automatise le déploiement du nombre agents nécessaires
Windows Azure - tests de charge
http://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 agents nécessaires:
– Persistance des résultats (reimaging des rôles PaaS)
Windows Azure - tests de charge
Azure VPN
RDP
DEMONSTRATION
Architecture / Azure / Cloud
AZURE MONITORING
Chapitre 8
Architecture / Azure / Cloud
Architecture / Azure / Cloud
• Management Pack Operations
Manager pour Windows Azure
• Instrumentez l’application Azure
• Activer le mode « Full-trusted » sur
les rôles à surveiller
• Activer et configurer les diagnostics
dans l’application
• Configurer l’écriture des
diagnostics dans un stockage
persistant
• Définissez les éléments à superviser
Rules & Monitor
• Connectez Operations Manager à
l’environnement Azure à superviser
Superviser une application Azure
http://msdn.microsoft.com/en-us/library/windowsazure/gg676009.aspx
Architecture / Azure / Cloud
Superviser une application Azure - Démonstration
SYNTHÈSE
Chapitre 9
Architecture / 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 hautement
disponible mondialement géo-distribué.
• Partitionnement de la charge– Un existant « on premise » basé sur une logique de « Scale up » doit être
partitionné pour tirer partie du cloud.
La prise en compte de ces trois critères associés à la mise en place d’une architecture adaptée permettent de tirer pleinement partie de la plateforme Azure et d’en attendre un ROI significatif.
SYNTHESE
QUESTIONS ?
Architecture / Azure / Cloud
Support PremierEntreprise
StrategyMicrosoft
Consulting Services
Concevoir et DéployerImaginer et Planifier Optimiser et Maintenir
Microsoft Enterprise Services
Environnement de travail et mobilité
La collaboration
La productivité
Applications Uniques et Innovantes
Cloud Privé et Cloud Public
L’automatisation de processus métier
Les réseaux sociaux d’entreprise
Business Intelligence et Big Data
Microsoft
Services
700
Experts en
France
Un
écosystème
Partenaires
Un capital
intellectuel
Architecture / Azure / Cloud