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

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



• 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


• 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




















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



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


• 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

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






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


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

https://manage.windowsazure.com/





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



• 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



• 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


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

queuesUnlimited

10,000


can be increased)

Maximum number of


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


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

http://blogs.msdn.com/b/windowsazurestorage/archive/2010/06/25/nagle-s-algorithm-is-not-friendly-towards-small-requests.aspx


• 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

queuesUnlimited

10,000


can be increased)

Maximum number of


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

queuesUnlimited

10,000


can be increased)

Maximum number of


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/2011/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 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


Technology

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