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

• 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

Introduction
New
Ecosystems
Usage
Based
Elastic
Economics
Solid
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

• 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.
• Performance
Capacité 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

• 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’ensemble
Scale up ou scale out ?
http://blogs.msdn.com/b/windowsazure/archive/2012/11/13/windows-azure-
benchmarks-show-top-performance-for-big-compute.aspx

Montée en charge : vue d’ensemble
Elasticité
Contention
« Verticale »
Taille D’instance
« Horizontale »
Nombre d’instances
Points de contention = points d’attention…

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

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.

Stockage REST Azure - Fonctionnement
http://blogs.msdn.com/b/windowsazurestorage/archive/2010/12/30/windows-azure-storage-architecture-overview.aspx

« 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..

• 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

• 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é.

WINDOWS AZURE SQL DATABASE
Chapitre 4

• 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

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

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

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

• Sharding
Distribution 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 techniques
Exemple : 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 »

• 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

• 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

• 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é.

• 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

• 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

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
GESTION 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 TABLE
CREATE 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

Exemple 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

– 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.

– 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.

AZURE VIRTUAL MACHINES
Chapitre 5

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

• 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 stockage
New-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

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 VMs
IaaS. (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

• 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 Manager
Fonctionnement

AZURE SERVICE BUS
Chapitre 6

• 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

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
queues
Unlimited
10,000
(per service namespace,
can be increased)
Maximum number of
concurrent clients
Unlimited
Unlimited
(100 concurrent
connection limit only
applies to TCP protocol-
based communication)
64 KB
(48 KB when using
Base64 encoding)
256 KB
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 number of
queues
Unlimited
10,000
can be increased)
Maximum number of
concurrent clients
Unlimited
Unlimited
(100 concurrent
Azure Service Bus

• 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

Azure Service Bus - Scénario 1 : relais de service

Scénario 2 : Intégration avec d’autres services

Maximum throughput
Up to 2,000 messages per
second
Up to 2,000 messages per
second
(based on benchmark with 1 KB
messages)
Average latency
10 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

• 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

• 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

• 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

Azure Role Caching - Configuration

64 KB
encoding)
256 KB
and body, maximum
header size: 64 KB)
Maximum queue size
100 TB
account capacity)
1, 2, 3, 4 or 5 GB
a queue)
Maximum number of
queues
Unlimited
10,000
can be increased)
Maximum number of
concurrent clients
Unlimited
Unlimited
(100 concurrent
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%

64 KB
encoding)
256 KB
and body, maximum
header size: 64 KB)
Maximum queue size
100 TB
account capacity)
1, 2, 3, 4 or 5 GB
a queue)
Maximum number of
queues
Unlimited
10,000
can be increased)
Maximum number of
concurrent clients
Unlimited
Unlimited
(100 concurrent
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

• 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

Windows Azure Role Caching – Bonnes Pratiques

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

• 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

• 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/20
11/09/02/load-testing-from-windows-azure-
tests-de-charge-depuis-windows-azure.aspx

• 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

AZURE MONITORING
Chapitre 8

• 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

Superviser une application Azure - Démonstration

SYNTHÈSE
Chapitre 9

• 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 ?

Support Premier
Entreprise
Strategy
Microsoft
Consulting Services
ConcevoiretDéployerImagineret Planifier OptimiseretMaintenir
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

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

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

Ähnlich wie Monter en charge, tester et surveiller avec une application Windows Azure : les bonnes pratiques (20)

Mehr von Microsoft Technet France

Mehr von Microsoft Technet France (20)

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

Hinweis der Redaktion