Archives mensuelles : février 2016

Architecture WAP – Design infrastructure IAAS

Le service IaaS de Windows Azure Pack est un monde à part. C’est un sujet que j’avais déjà abordé dans la série de billet Windows Azure Pack – IaaS : Introduction. On est à la frontière entre deux mondes. Le problème, c’est que ces deux univers ne parlent pas le même langage. On a donc besoin d’un interprète. D’un côté Windows Azure Pack cause le JSON nativement et de l’autre SCVMM, ben il cause PowerShell. On ne peut pas dire que ça aide. Service Provider Foundation sera notre traducteur universel (Alias C3PO). Du point de vue de Windows Azure Pack, il sera vu comme un ensemble de Resource Provider.

clip_image001

 

Dans le diagramme ci-dessus, on constate que du point de vue de Windows Azure Pack, la seule notion qui l’intéresse, c’est celle de VM Clouds. C’est la ressource que nous allons mettre à disposition de nos futurs locataires, à savoir un Cloud SCVMM. SCOM et SCVMM sont totalement inconnus, pourtant, ils fournisseur des services. Plus précisément, le Service Provider Foundation assure la mise en place des souscriptions de ce service, son statut et son état de santé. Ça match juste avec les Resources Providers au cœur de Windows Azure Pack que nous venons de voir. Dans les faits, c’est un peu plus compliqué que cela mais pour commencer, on va se contenter de cela.

 

Windows Azure Pack n’a aucune idée de ce qu’est SCVMM. Il ne voit que la ressource mise à disposition. Derrière ce terme, il faut y voir une unité de gestion, on y reviendra plus tard. Pour l’instant, on va se concentrer sur les Resources Providers mis à disposition de Windows Azure Pack, ils sont au nombre de trois :

  • SystemCenter
  • CloudServices
  • Gallery

 

Donc on doit installer Service Provider Foundation. Le comment a déjà été traité ici : Windows Azure Pack – IaaS : Installation du Service Provider Foundation. Les questions qui nous intéressent ici c’est :

  • Ou l’installer ?
  • Comment le rendre hautement disponible?
  • Comment être sûr que ce sera scalable dans le temps ?

 

La réponse la plus évidente à la première question peut sembler facile. On peut l’installer sur l’unique instance de notre infrastructure SCVMM, c’est la solution la plus simple. Problème, adieu la haute disponibilité, idem pour la scalabilité. On n’y coupera pas, il faudra lui dédier un serveur pour notre première instance. Vu que ce sont des Web Services, pour la haute disponibilité, c’est juste une histoire de load-Balancers, voilà pour la seconde question.

clip_image003

 

Dernier point, la scalabilité. Au niveau du Service Provider Foundation, c’est une histoire de configuration matérielle. Selon le Capacity Planning for Service Provider Foundation, avec le bonne configuration on est prêt à tout :

Nombre de VM

CPU

RAM

Moins de 5000 4 cœurs 8 Go RAM
Entre 5 000 et 12 000 VM 8 cœurs 8 Go RAM
Entre 12 000 et 25 000 VM 16 cœurs 8 Go RAM

25 000 machines virtuelles, c’est aussi la limite de notre infrastructure SCVMM. Ça tombe bien. Revenons à nos Resources Providers. Pour les deux premiers (Gallery et CloudServices), il faut comprendre que le Resource Provider se limite à fournir des services au portail des locataires. Pour le dernier, c’est lui qui porte les fonctions principales du Service Provider Foundation. Si on regarde sur le serveur en question, cela correspond aux Web Services exposés, à savoir :

 

Nous avons l’interface entre Windows Azure Pack et Service Provider Foundation. La suite est assez simple puisqu’il nous reste plus qu’à déclarer notre instance SCVMM voire jusqu’qu’à cinq instances. Ce sont des sujets que j’avais déjà abordé dans cet article : Windows Azure Pack – IaaS : Intégration de Service Provider Foundation ainsi que celui-ci Windows Azure Pack – IaaS : Déclaration du VM Cloud.

Pour l’architecture IaaS, il ne nous reste plus qu’un sujet à traiter, à savoir l’accès aux machines virtuelles via RDP. Ce service est mis à disposition par la Remote Desktop Gateway. Le service repose sur la fonctionnalité « Enhanced session mode » de Windows Server 2012 R2. La fonctionnalité est intéressante car elle propose un accès RDS à la machine virtuelle via l’hôte Hyper-V. Cela signifie que même si la machine virtuelle ne dispose pas de connectivité Internet, c’est le mode console. Sous la moquette, cela ressemble à cela :

clip_image005

 

Techniquement, on utilise un certificat (avec un FQDN public) qui est présent sur :

  • La Remote Desktop Gateway
  • Virtual Machine Manager

 

Il est aussi présent sur tous les hôtes Hyper-V mais c’est SCVMM qui se charge de le mettre à disposition de tous les hôtes Hyper-V. Lorsque l’utilisateur va demander l’accès RDP à une de ses machines virtuelles, un fichier RDP sera généré et mis à disposition de l’utilisateur. Il va ensuite le présenter à la Remote Access Gateway. Normalement, le rôle de la RDS Gateway est d’authentifier les utilisateurs avant qu’ils n’accèdent aux sessions RDS. Problème, dans le contexte de Windows Azure Pack, notre RDS Gateway n’a aucune idée du fournisseur d’identité à solliciter. Le package va donc modifier le mode de fonctionnement de la RDS Gateway pour réaliser une authentification à base de certificat.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Un peu de magie avec la QoS Windows

A la base, la fonctionnalité des « Offline Files » est une bonne idée. Le problème, c’est quand on tente de dépasser les limites de nos tuyaux réseau. La volonté de centraliser les données des utilisateurs va rapidement saturer le réseau WAN, c’est ce qui est arrivé à un de mes clients. La situation était telle que les applications métiers devenaient difficile à utiliser à cause de la bande passante consommée pour la synchronisation des données. Un vrai casse-tête, qui a conduit ce client à bloquer le trafic SMB à destination des partages contenant les « Offline Files » en central.

Problématiques posées

Voilà un challenge intéressant. On a beau retourner le problème dans tous les sens, il faudra bien réintroduire le service. C’est pas sans poser quelques problèmes :

  • Réintroduire la fonctionnalité c’est assurément atomiser le réseau. Plus on va attendre, plus les utilisateurs auront accumuler des données à synchroniser
  • Plus on tarde, plus on prend le risque de la perte de données en cas de perte du poste de travail.
  • Les performances du réseau WAN ne sont pas extensibles, rien n’interdit un utilisateur de vouloir synchroniser des Go de données.
  • La dispersion géographique des utilisateurs était pour mon client un véritable problème. Plus de 200 implémentations géographiques avec des utilisateurs essentiellement nomades

 

La solution ne pouvant pas venir de la fonctionnalité « Offline Files », on a donc commencé à chercher ailleurs. Mon premier réflexe a été d’aller faire un tour dans mon éditeur local de stratégies de groupes pour voir si une des nombreuses fonctionnalités natives de Windows ne pourrait pas nous aider. Effectivement, Windows sait faire de la QoS réseau.

clip_image001

 

Si on regarde la fonctionnalité de plus près, c’est pas mal du tout. A la base, cela permet de tagger les flux réseau qui sortent du poste de travail pour que les équipements réseau puissent y associer une politique de QoS. Moins connu, il est aussi possible de maitriser le bande passante consommée directement depuis le poste de travail. En voilà une bonne idée. Techniquement oui mais au final, c’est une fausse bonne idée. Avec plus de 200 implémentations géographiques, c’est autant de situations différentes. Avec les GPO, cela reviendrait à mettre en place autant de stratégie de groupe que d’implémentations géographiques. Après, la fonctionnalité de QoS ne traite réellement que les flux sortants du poste de travail, pas les flux entrants. Lorsqu’on regarde dans la configuration avancée, on constate qu’on ne dispose pas du même niveau de finesse.

clip_image002

 

C’est une politique est globale, pour tous les flux entrants. Le tableau ci-dessous documente la QoS :

Niveau

QoS

0 64Kb
1 256Kb
2 1Mb
3 16Mb

 

La QoS de Windows a aussi ses limites. Si en face le serveur de fichiers avait été un serveur Windows, on aurait pu aussi utiliser la QoS de la même manière. Vu que ce n’était qu’un simple NAS, il ne disposait pas de la fonctionnalité. Dans la pratique, cela va nous poser quelques problèmes :

  • Si un utilisateur ouvre une session sur un poste de travail qui n’est pas le sien, on ne pourra pas maitriser la copie des fichiers
  • Si un utilisateur se voit doté d’un nouveau poste de travail, même punition

 

Malgré ces limitations, j’ai continué mon exploration de la QoS. Certes elle a ses limites mais on peut déjà l’utiliser pour maitriser le flux sortant à destination du NAS. Fallait juste trouver un moyen d’industrialiser un peu tout cela. Quand on pense, industrialisation, on pense rapidement à Powershell. Bingo, je me souviens maintenant qu’il existe un module Powershell introduit avec Windows 8 et Windows 2012. Un peu de recherche et effectivement, le module NetQoS existe bien. Plus important, il existe bien sur le socle Windows 8 de mon client.

clip_image003

 

Une idée commence à germer. Et si on pouvait industrialiser la mise en place d’une politique de QoS au niveau des postes en fonction de sa situation réseau. En voilà un beau challenge. Faisons quelques expériences :

New-NetQosPolicy « Synchro NAS » -NetworkProfile Domain -DSCPAction 40 -DestinationIpAddress <Adresse du mon NAS> -IPProtocol TCP -IPSrcPort 445 -ThrottleRateActionBitsPerSecond 1Mb

clip_image004

Globalement, on dit à Windows de mettre en place une politique de QoS pour limiter le trafic SMB à destination du NAS uniquement pour le cas où la connectivité réseau est de type domaine (pare-feu). Pour vérifier si cela fonctionne, faut des gros fichiers. J’ai créé le script PowerShell suivant :

$Path = « c:\testFile.Txt »

$File = [IO.File]::Create($path)

$File.Setlength(1Gb)

$File.Close

Get-Item $Path

clip_image005

 

OK, 1Mbits, c’est juste un peu trop hardcore, on va passer à 2Mbits en reconfigurant la policy avec la commande PowerShell suivante :

Set-NetQosPolicy -name « Synchro NAS » -ThrottleRateActionBitsPerSecond 2Mb

clip_image006

 

Maintenant, faut des chiffres et prouver que cela fonctionne. Par expérience, l’explorateur Windows, c’est pas fiable. Le petit script PowerShell ci-dessous devrait nous aider :

cls

$startdate = get-date

Write-host « Début de test de copie d’un fichier de 1Go sur un share SMB $(Get-date) »

Copy « C:\Temp\TESTFILE.TXT » « \\<Adresse IP destination>\partage$\Datas\\TESTFILE.TXT » -Force

Write-host « Fin de test de copie d’un fichier de 1Go sur un share SMB $(Get-date) »

$enddate = get-date

Write-Host (New-TimeSpan -Start $startdate -End $enddate).TotalSeconds

clip_image007

 

A quand même, 1217 secondes pour copier mon fichier de 1Go. Au passage, je suis sur un portable en config « Full patate » avec connexion réseau Gigabit et SSD. Sceptique? Peut-être que le gestionnaire de tâche sera plus parlant alors.

clip_image008

 

Oui, il y a des pics de consommation mais ils sont régulés automatiquement. Tentons la même expérience avec une QoS à 5Mb.

clip_image009

 

Déjà, ça va mieux, que 503 secondes. Logiquement avec une QoS à 10Mb, on devrait être deux fois plus rapide, bingo.

clip_image010

 

Avec une QoS à 25Mb, on arrive à 103 secondes. Pour information, sans aucune QoS, le temps de copie de référence est de 42 secondes.

clip_image011

 

Donc, c’est industrialisable. Maintenant, les derniers détails :

  • Comment industrialiser la configuration?
  • Comment centraliser le paramétrage?

 

Comment industrialiser la configuration?

La y a pas 36 solutions. On a vu que les GPO, c’était pas possible. Il faut donc travailler au plus proche du poste. Un script de démarrage exécuté par GPO? Oui mais il ne s’applique que lorsqu’on démarre le système d’exploitation, pas quand l’ordinateur sort de veille. Très logiquement, ce sont les tâches planifiées qui se sont imposées, surtout quand on sait qu’on peut les déclencher quand on en a besoin :

  • A l’ouverture de session
  • Au déverrouillage de session
  • Après période d’activité
  • Sur détection d’un évènement dans les journaux d’évènements

OK pour exécuter un script PowerShell via tâche planifiée mais sous quel contexte? Faudra bien un compte de service, qu’il faudra maintenir. Oui mais c’est pas moi qui vais maintenir ce compte de service. Mon client utilisant Windows 8 sur ses postes de travail, l’utilisation de Group Managed Services Accounts alias GMSA s’impose. Avec Windows 8, ce qui est cool, c’est qu’on peut utiliser ce type de compte pour les tâches planifiées : Windows Server 2012: Group Managed Service Accounts.

 

Comment centraliser le paramétrage?

On sait comment configurer, reste le paramétrage. Un rapide cahier des charges s’impose :

  • Faut que ce soit facile à maintenir et faire évoluer (Que celui qui a proposé une base SQL lève la main, …)
  • Faut que ce soit léger sur le réseau
  • Faut qu’on puisse le faire évoluer rapidement pendant le développement
  • Enfin, toujours respecter la règle de base : Simple by Design

 

OK, on aurait pu développer un Web Service qui délivre la configuration mais c’est un peu too much. On va se contenter d’un simple fichier XML.

clip_image012

 

Effectivement, un fichier XML, c’est simple à maintenir, facile à faire évoluer et ça pèse pas trop lourd sur le réseau. En plus, c’est super simple à utiliser dans le script Powershell que nous exécutons dans notre tâche planifiée.

 

Le tour de magie

Le tour de magie, c’est donc un script Powershell, exécuté dans le contexte d’un compte de service dont nous n’avons pas à maintenir le mot de passe. Ce script va récupérer sa configuration en central dans un partage SMB pour conserver une copie locale en cas d’impossibilité d’accéder au partage. Le script va exploiter le fichier XML pour mettre en place des politiques de QoS pour tous les cas d’usage (interne, externe, VPN …).

clip_image013

 

Au final, ça donne cela.

clip_image014

 

A chaque ouverture de session, déverrouillage de session ou même changement d’état de la connectivité réseau, la politique de QoS est automatiquement adaptée. Donc même en sortie de veille, on s’adapte.

Et maintenant?

Maintenant, le client est en mesure de proposer une politique de QoS pour chaque implémentation géographique. Au début, il va positionner la QoS à une valeur très basse, (genre 1Mb) pour augmenter progressivement jusqu’à trouver le point d’équilibre entre la synchronisation des fichiers des utilisateurs et les applications métiers.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

System Center Update Rollup 9

C’est tombé la même semaine que la Technical Preview 1 de Windows Azure Stack mais Windows Azure Pack a lui aussi son actualité avec la mise à disposition de l’Update Rollup 9. Ca couvre pas tous les composants mais ça va occuper dans la mise à niveau du Fabric Management :

  • Update Rollup 9 for Windows Azure Pack (KB3129786)
  • Update Rollup 9 for Windows Azure Pack Web Sites version 2 (KB3129789)
  • Update Rollup 9 pour SCOM 2012 R2 (KB3129774)
  • Update Rollup 9 pour Service Manager 2012 R2 (KB3129780)
  • Update pour System Center 2012 R2 Service Manager Self-Service Portal (KB3134286)
  • Update Rollup 9 pour System Center 2012 R2 Data Protection Manager (KB3112306)
  • Update Rollup 9 pour System Center 2012 R2 Orchestrator – Service Provider Foundation is now available (KB3133705)

La principale nouveauté pour Windows Azure Pack permet maintenant de changer l’administrateur de la souscription d’un tenant. Une subtilité, le Rollup 9 pour SCSM 2012 R2 a été retiré temporairement après sa publication. Il devrait revenir bientôt.

­

Prochaine étape, le bestiau ; Windows Azure Stack. 

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Architecture WAP–Design infrastructure Windows Azure Pack

Let the fun begin! Windows Azure Pack est de loin la partie la plus intéressante. Avouez, c’est uniquement la partie qui vous intéresse. J’ai déjà développé le sujet ici et la, mais sans vraiment rentrer dans le détail des explications. Pour rappel, Windows Azure Pack, c’est un ensemble de Web Services que l’on peut organiser en deux catégories, selon qu’ils ciblent les locataires ou les administrateurs de la plateforme. Le tableau-ci-dessous résume les rôles et les populations ciblées :

Rôle

Cible

Windows Azure Pack PowerShell API Administrateurs / Tenant
Windows Azure Pack Tenant API Administrateurs
Windows Azure Pack Admin Portal Administrateurs
Windows Azure Pack Tenant Portal Tenant
Windows Azure Pack Tenant Authentication Site Tenant
Windows Azure Pack Tenant Public API Tenant
Windows Azure Pack Admin API Administrateurs
Windows Azure Pack Admin Authentication Site Administrateurs
Windows Azure Pack Best Practice Analyzer Administrateurs

 

Tous ces Web Services peuvent cohabiter sur un même serveur ou être répartis sur plusieurs. Séparer en fonction des cibles est une bonne approche du point de vue de la sécurité. Un premier niveau de découpage logique donc le suivant comme illustré ci-dessous :

  • Un serveur pour héberger les rôles destinés aux Administrateurs (WAPPRIV)
  • Un serveur pour héberger les rôles destinés aux locataires (WAPPUB)

clip_image001

Le premier intérêt de cette séparation est de pouvoir placer chaque serveur dans une zone réseau distincte. Ca plaira aux barons de la sécurité. Pour eux, la Co-localisation des rôles sur un même serveur est problématique d’un point de vue sécurité. Exposer le portail d’administration ou l’API associée directement sur Internet est plutôt risqué. Si une faille impacte le serveur, il serait possible pour un utilisateur externe d’accéder aux rôles privilégiés de Windows Azure Pack. Après, il faut relativiser. Nos serveurs ne seront pas exposés directement sur Internet. Dans notre contexte Cloud privé, nous avons besoin que ces services soient hautement disponible et dans les deux datacenters. Pour le déploiement, que nous en ayons deux ou dix, c’est la même chose, tout ce que nous avons besoin, c’est d’un moyen d’industrialiser le déploiement : Powershell Deployment Toolkit.

clip_image002

 

Si on voulait pousser le vice jusqu’au bout en isoler les fonctions portail et authentification des autres. Techniquement, c’est possible mais cela complexifie l’architecture pour pas grand-chose. D’un point de vue sécurité, nos rôles destinés aux locataires ne seront pas exposés en directe mais via des mécanismes de reverse proxy (vous avez dit Web Application proxy?), l’idée étant de pré-authentifier les locataires. Justement, parlons authentification.

Authentification

Maintenant que l’infrastructure Windows Azure Pack est en place, on va passer un peu de temps sur la partie authentification. j’ai déjà évoqué ce sujet ici et . Au final, le choix est assez simple. Pour les administrateurs, le choix d’ADFS s’impose de lui-même. Cela permet de centraliser l’authentification et l’autorisation de nos administrateurs en un point unique, au sein de la zone réseau privilégiée, voire même de les pré-authentifier lorsqu’ils arrivent depuis une autre zone réseau. Dans le contexte de notre cloud Privé, cela implique qu’on disposera d’une ferme ADFS dédié à cet usage, avec haute disponibilité. Pour renforcer la sécurité, l’utilisation de Web Application Proxy est recommandé, rien que pour sa fonction External Extranet Lockout. Le bonus, c’est la possibilité d’imposer l’authentification forte à ce niveau avec Azure Multi-Factor Authentication.

clip_image003

 

Pour les locataires ADFS s’impose aussi mais pour une autre raison. Pour Microsoft, le fournisseur d’authentification par défaut ne doit pas être utilisé en environnement de production et recommande l’utilisation d’ADFS. Lorsque l’utilisateur est capable de se présenter avec sa propre identité, cela ne pose pas de problème. Ce sera par exemple le cas de certains de nos futurs clients pour lesquels on sera capable de mettre en place un Federation Trust comme documenté dans cette série de billets : Authentification des locataires de Windows Azure Pack avec ADFS.

clip_image004

 

Avec cette architecture, le client vient avec sa propre identité, charge à lui de s’assurer de sa disponibilité et sa sécurité. Par contre, cela nous coupe d’un certain nombre de nos clients qui n’ont pas encore d’infrastructure de fédération d’annuaire. Il faut bien être en mesure de leur proposer le service, sinon, on va se couper du business des TPE/PME. La question, c’est doit-on héberger ce service (et donc en être responsable) ou peut-on l’externaliser (Chez Microsoft Azure par exemple)? Le premier choix, cela signifie qu’on va :

  • Lui fournir les moyens de gérer son identité (réinitialisation mot de passe, …)
  • Garantir la sécurité de l’identité de nos utilisateurs

Le premier choix implique de mettre en place une infrastructure ADFS dédiée, sécurisée et hautement disponible. Techniquement, c’est donc une évolution de l’architecture ci-dessus dans laquelle on va ajouter une nouvelle infrastructure ADFS pour proposer notre service d’identité à nos clients. C’est facile mais ça nous rend responsable du bon fonctionnement du service et sa sécurité. Le second choix est lui plus sexy. Depuis peu, il est possible de consommer un tenant Windows Azure Active Directory sous forme ADFS. OK, la fonctionnalité est disponible uniquement pour l’édition Premium mais :

  • Microsoft nous fournit un service d’authentification sécurisé et hautement disponible
  • Microsoft nous fournit à nos futurs locataire le moyen de gérer / sécuriser leur identité

Du point de vue architecture, cela ne change strictement rien, ils sont toujours authentifiés et autorisés à accéder à leurs ressources.

 

Resources Providers

Windows Azure Pack ne serait rien d’autre qu’un portail sans ses Resources Providers. Pour ceux qui ont oublié, j’avais écrit ce billet : Introduction aux Resources Providers de Windows Azure Pack. Techniquement, ce sont des Web Services exposés de manière normalisée pour Windows Azure Pack. Avant même d’en ajouter d’autres, le billet s’attachait à configurer les premiers :

  • Monitoring
  • MarketPlace
  • Usage Service

Ils sont tous les trois livrés avec Windows Azure Pack et présents sur le serveur WAPPRIV, ou plutôt toutes les instances de nos WAPPRIV. Par contre dans la configuration par défaut, rien n’est prévu pour la haute disponibilité. Avec un peu de PowerShell, on peut aller revoir la configuration de ces Ressources providers avant configuration.

Import-Module MgmtSvcAdmin

$Securepassword = ConvertTo-SecureString -String « ******** » -AsPlainText -Force

$Cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList « Administrator », $Securepassword

$AdminAPIInfos = Get-MgmtSvcFqdn -Namespace adminapi -Server SQL01.WindowsAzurePack.lan

$AdminUri = « https://$($AdminAPIInfos.FullyQualifiedDomainName):$($AdminAPIInfos.Port)«

$WindowsAuthSiteInfos = Get-MgmtSvcFqdn -Namespace WindowsAuthSite -Server SQL01.WindowsAzurePack.lan

$WindowsAuthSiteUri = « https://$($WindowsAuthSiteInfos.FullyQualifiedDomainName):$($WindowsAuthSiteInfos.Port)«

$token = Get-MgmtSvcToken -Type Windows -AuthenticationSite $WindowsAuthSiteUri -ClientRealm « http://azureservices/AdminSite » -User $cred

$AllRPs = Get-MgmtSvcResourceProvider -IncludeSystemResourceProviders -AdminUri $AdminURI -Token $token

$Allrp | select name, DisplayName, @{e={$_.AdminEndpoint.ForwardingAddress}},@{e={$_.TenantEndpoint.ForwardingAddress}} | Format-Table -AutoSize

clip_image005

 

Dans le billet Introduction aux Resources Providers de Windows Azure Pack, nous commencions par corriger ce point en introduisant une URL générique pour nos premiers Resources Providers. Derrière cette URL générique se cache une adresse IP portée par un boitier HLB qui se charge de rediriger les requêtes entres toutes les instances déclarées. Une fois corrigé, on obtenait le résultat ci-dessous :

clip_image006

 

Ces ressources Providers sont un peu particulier (ils sont « System Resource Provider ») car c’est autour d’eux que les autres Resources providers vont venir d’intégrer. Nos futurs ressources providers vont :

  • Proposer des ressources à nos locataires qui sera exposées via le Resource Provider Marketplace
  • Suivre l’état des ressources mises à disposition qui sera exposé via le Resource Provider Monitoring
  • Suivre la consommation des ressources mises à disposition de nos locataires Resource Provider UsageService

 

On peut maintenant s’attaquer aux autres Resources Providers :

  • MySQLServers
  • SQLServers
  • Automation
  • SystemCenter
  • CloudServices
  • Gallery
  • WebSites

Tous ces Resources Providers sont apportés par les composants additionnels que nous allons installer. Pour certains, leur existence est déjà référencée dans les portails de Windows Azure Pack (pour les plus connus d’entre eux), ne manque que la configuration nécessaire pour les exploiter. Windows Azure Pack impose son modèle avec un ensemble de Web Services :

  • AdminEndPoint (Partie visible du Resource Providers dans le portail des administrateurs)
  • TenantEndPoint (Partie visible du Resource Provider dans le portail des locataires)
  • UsageEndPoint (pour remonter le suivi des usages du Resource Provider pour chaque souscription)
  • NotificationEndPoint (pour notifier dans les portails sur l’avancement des opérations)
  • HealthCheckEndpoint (pour le monitoring du ressource provider)

 

Voilà pour l’essentiel. Maintenant, dans un contexte avec plusieurs Datacenters avec objectif de haute disponibilité, il faudra disposer d’au moins une instance de chaque serveur dans chaque Datacenter avec un mécanisme de répartition de charge réseau (F5/Kemp). Windows Azure Pack nous simplifie grandement la tâche. Ce ne sont que des Web Services pour lesquels on peut disposer d’autant instances que l’on veut. Tout ce qu’on doit faire c’est de placer un équipement d’équilibrage de charge réseau devant. En back-end, notre seule contrainte, c’est de disposer d’une infrastructure SQL Server hautement disponible en Always On, donc opérant en actif/actif. Avec deux Datacenters, cela ressemble déjà à cela :

clip_image007

 

Chaque Resource Provider est un sujet à part entière. C’est simple pour certains, compliqué pour d’autres. Vu que le plus intéressant pour beaucoup d’entre vous est le IAAS, on va commencer par lui dans le prochain billet.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)