Archives de catégorie : Dungeon Keeper (Windows Azure Pack)

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)

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)

Architecture WAP–Design SCVMM

On parle enfin virtualisation, SCVMM et Hyper-V. Si on connait un peu son SCVMM, on connait ses limites de sizing :

  • Nombre de hosts Hyper-V : 1000
  • Nombre de machines virtuelles : 25000
  • Nombre de User Roles : 1000

Source : Overview of System Center 2012 – Virtual Machine Manager

 

Après, il y aura les limites d’Hyper-V (2012 R2) à prendre en considération :

  • Nombre maximum de nœuds dans un cluster : 64
  • Nombre de machines virtuelles maximum dans un cluster : 8000

Source : Hyper-V scalability in Windows Server 2012 and Windows Server 2012 R2

 

Première conclusion, la véritable limitation viendra de SCVMM mais pas ou on pourrait l’attendre, ce sera celle du nombre de user-roles dans SCVMM, donc le nombre maximum de locataires que l’on pourra avoir sur une seule infrastructure SCVMM. Est-ce un problème de n’avoir que mille locataires? Le Business répondra invariablement oui. Il faut pouvoir outre passer cette limite technique ? Les grands fournisseurs de services Cloud se sont déjà heurtés à ce type de problème. Si leurs infrastructures n’étaient pas assez scalable, on le saurait depuis longtemps. Leur astuce c’est que l’infrastructure présentée au client n’est qu’une partie de l’infrastructure globale. Derrière Azure, il y a certes des services globalisés tel que le portail mais après, les services sont localisés et même découpés en instances de plus petite tailles, plus faciles à manager. A l’échelle de Windows Azure Pack, on peut faire la même chose avec SCVMM. Individuellement chacun de nos locataires à peu de chances de nous faire atteindre les limites d’une seule instance de SCVMM. Rien n’empêche alors d’avoir plusieurs instances de SCVMM présentées à Windows Azure Pack via le Service provider Foundation. De son point de vue, on publie effectivement plusieurs Clouds SCVMM. Pour nos locataires, ce ne sont que des offres d’abonnement différents. Pour commencer, une seule instance suffira.

Haute disponibilité avec SCVMM

Le nombre d’instances étant réglé, passons à sa disponibilité. Avec SCVMM, on est limité car on ne peut avoir qu’une seule instance du rôle que l’on peut seulement configurer pour opérer au sein d’un cluster. Si le cluster ne fait pas partie de vos choix, l’utilisation d’Hyper-V Replica est vivement recommandée. Personnellement, j’essaie de limiter le nombre d’instances de SCVMM. Même si Windows Azure Pack permet de référencer autant de Service provider Foundation pour lesquelles on peut référencer jusqu’à cinq instances SCVMM distinctes, il n’en reste pas moins que cela reste des instances distinctes du point de vue Gallery et VM Roles. Donc nos choix se limitent à :

  1. Rester dans les limites de support de SCVMM pour n’avoir qu’une seule instance indépendamment du nombre de Datacenters
  2. Placer une instance SCVMM par Datacenter et raccorder les hôtes de virtualisation en conséquence
  3. Placer une instance SCVMM par Datacenter et raccorder les hôtes de virtualisation en répartissant entre les Management group

 

Le choix numéro n°1 est le choix le plus rationnel pour commencer. Du point de vue architecture rien n’empêche d’ajouter d’autres instances en cours de route pour faire face aux besoins / contraintes. La seule limitation concerne la fonctionnalité Gallery de Windows Azure Pack qui est liée à la librairie SCVMM. Le contenu de la Gallery présenté à l’utilisateur référence toutes les VM Roles disponibles, indépendamment des SCVMM. Pour éviter de présenter plusieurs fois la même ressource à nos futurs locataires, il faut reconfigurer les VM Roles avant importation pour les rendre unique. Dans le contexte que nous allons développer, nous resterons sur le scénario n°1. Ci-dessous l’architecture pressentie pour SCVMM.

clip_image001

 

On reste donc dans le simple avec pourtant une subtilité. J’ai bien de l’Hyper-V Replica mais entre deux clusters qui sont dédiés au Fabric Management. On reviendra sur ce point plus tard. Pour finir avec le design d’infrastructure, un petit rappel : Par Défaut, SCVMM est un produit qui vous veut du bien. Pensez donc à sauvegarder les clés dans l’Active Directory ?

clip_image002

 

Haute disponibilité des librairies

Avec SCVMM, il ne faut pas oublier de penser à la librairie SCVMM, ou plutôt aux librairies SCVMM. C’est un peu plus qu’un agent installé sur un serveur qui joue le rôle de serveurs de fichiers. Il en faut au moins une par Datacenter, histoire d’éviter de déployer des VDHX via le WAN. Pour répliquer le contenu, DFS-R peut paraitre le candidat idéal, mais attention à la taille du Staging Folder qui va nécessiter beaucoup d’espace disque pour préparer la réplication. Rien qu’un VHDX pour un système d’exploitation de type Windows Server 2012 R2, il faudra compter entre 15 et 17Go (en disque dynamique). Selon les guidelines de sizing DFS-R, chaque partenaire de réplication doit être en mesure de traiter la réplication de 16 fichiers entrants et 16 fichier sortants. La volumétrie disque nécessaire pour le Staging Folder peut donc être évaluée à l’aide de la taille cumulée des 32 plus gros fichiers à répliquer. A ce niveau, les fonctionnalités de réplication de stockage sont certainement plus économes. Et encore, nous ne parlons que d’une seule instance SCVMM. Une bonne raison pour continuer à se limiter à une seule instance SCVMM.

Du point de vue architecture, on va quand même utiliser DFS-R en mettant en place un groupe de réplication comprenant deux nœuds répartis entre nos deux datacenters. Après, il faut comprendre une chose, nous nous sommes assurés de la disponibilité du contenu avec DFS-R, rien de plus. DFS-N ne peut rien faire pour nous puis que c’est une communication de type BITS entre la librairie SCVMM et l’hôte Hyper-V, il n’y a aucun accès en SMB avec un chemin UNC. Donc en cas d’indisponibilité d’une librairie, tous les objets y faisant référence sont inutilisables depuis SCVMM. Travailler avec plusieurs librairies implique de travailler avec les objets équivalents. C’est un processus qui permet de déclarer manuellement des associations entre plusieurs objets que l’on va déclarer comme équivalent. Là où ça coince, c’est que c’est une fonctionnalité qui ne semble accessible que depuis la console d’administration de SCVMM, fonctionnalité pour laquelle on a pas de commande PowerShell. A ma connaissance, il n’y a qu’un seul cas ou les objets sont automatiquement déclarés comme équivalents, s’ils sont tous tagués avec les mêmes familles, versions et namespaces.

clip_image003

 

Design des Clouds SCVMM

L’infrastructure posé, rentrons dans SCVMM. Sous la notion de cloud, on va pouvoir regrouper plusieurs types de ressources (Host Groups, Logical Networks, accessoirement des Load Balancers et des VIP, du stockage, des librairies SCVMM, des politiques de capacités, …). Commençons avec les Host groups. La première chose à faire est d’isoler les ressources utilisées par le Fabric Management de celles qui seront utilisées par nos futurs locataires. Dédier un Cloud SCVMM pour le Fabric Management n’est pas sans conséquences. Certes, plusieurs Clouds SCVMM peuvent partager des ressources comme les librairies mais pour d’autres, cela pose des problèmes pour les hosts groups

Dédier un host group pour la Fabric Management est obligatoire. C’est un peu un sanctuaire. Sans lui, plus de Windows Azure Pack, donc aucun moyen pour nos locataires de consommer les ressources mises à leur disposition. Il faudra donc associer un Cluster à ce Host-group. Le problème, c’est que cette association est exclusive. Le ou les clusters Hyper-V deviendront donc réservé uniquement pour le Fabric Management. Pour ces clusters, pas la peine d’essayer de le sizer au plus court. Son indisponibilité serait bloquante pour les exploitants mais aussi pour les locataires. Pas la peine de mégoter sur le nœud de cluster pour la réserve. En plus, il faudra bien les patcher un jour ces clusters. S’il n’y a pas les ressources nécessaires pour basculer les workloads du Fabric Management, il faudra donc interrompre le service. C’est moche, surtout quand on vend qu’un cloud est censé être plus disponible que les bonnes vieilles implémentations « On-Premises ».

Plusieurs Cloud SCVMM peuvent partager les mêmes librairies sans problème. Techniquement, c’est vrai. Imaginons que vous voulions proposer à nos locataires la possibilité de faire des checkspoints de leurs machines virtuelles, ou ce contenu serait-il stocké ? Notre locataire est en droit d’attendre que les exploitants de la plateforme Cloud qu’il a retenu ne puissent pas accéder à ce contenu. Pour répondre à cette problématique, il est donc obligatoire de disposer de librairies SCVMM qui seront dédiées au Cloud SCVMM réservé à nos locataires. Si on sépare les librairies en fonction des usages (service et locataires), il faudra donc plusieurs groupes de réplication DFS-R et dédier des serveurs de fichiers pour chaque usage.

Enfin, introduire plusieurs Clouds SCVMM pour nos locataires n’est pas dénué de sens. D’une part cela contribue à proposer plusieurs niveaux de service à nos locataires (Gold, Bronze, Silver, …). Le plus intéressant ici n’est pas la technique mais bien les services proposés à nos locataires. En montant en gamme, on peut proposer de nouveaux services à nos futurs locataires :

  • Le niveau Silver pourrait ne contenir que des host groups référençant des Hyper-V, donc sans haute disponibilité
  • Le niveau Bronze introduirait la haute disponibilité en utilisant des hosts groups contenant des clusters Hyper-V
  • Le niveau Gold lui proposerait carrément la virtualisation réseau avec la NVGRE Gateway ?

 

L’approche est aussi applicable au stockage en proposant une gamme de stockage en fonction :

  • Le niveau Silver ne proposerait que du stockage local de type DAS
  • Le niveau Bronze proposerait du stockage basé sur du Scale-Out File Server
  • Enfin le niveau Gold proposerait lui du stockage géo-répliqué entre les datacenters (par exemple basé sur Storage Replica, inclus dans l’édition Datacenter de Windows Server 2016)

 

Cette approche a cependant une limitation dans Windows Azure Pack. Lorsqu’un utilisateur souscrit à un abonnement IaaS dans son portail, il lui est associé le Cloud SCVMM dans lequel il pourra consommer son service. Si demain cet utilisateur veut bénéficier du niveau de service supérieur, nous devrons migrer la souscription de l’utilisateur vers l’abonnement de niveau supérieur. Le problème, c’est que cela ne migre pas les machines virtuelles entre les clusters.

Synthétisons un peu tout cela dans un diagramme. Donc deux Cloud au sens SCVMM pour distinguer les usages et une organisation des hosts-groups en fonction des Datacenters. Pour commencer, je considère que des clusters Cross-datacenters ne sont pas à l’ordre du jour pour commencer. Il y a beaucoup d’autres choses à monter avant cela. Le modèle a l’avantage d’être simple, avec pour seule réelle limite la scalabilité de SCVMM. Du point de vue de nos locataires, j’ai retenu un seul Cloud, donc un seul niveau de service proposé.

clip_image004

 

Maintenant qu’on l’outil de management en place, peuplons-le avec des clusters Hyper-V.

 

Design des clusters

Coté cluster, on sait déjà qu’il nous faudra au moins deux clusters Hyper-V pour le Fabric Management et d’autres pour les locataires. Il reste dépendant quelques questions en suspens :

  • Combien de clusters pour le Fabric Management ?
  • Doit-on avoir des clusters inter-sites ?
  • Doit-on privilégier les grands clusters ?

 

Combien de clusters pour le Fabric Management ? Facile, tout le monde dans le même cluster ? OK mais s’il tombe, on perd tout. En plus, on est dépendant du stockage. Si on veut pouvoir survivre à la perte d’un Datacenter, c’est du stockage Geo-répliqué qu’il nous faut alors. Difficile de vendre au Business que nous allons claquer un maximum d’argent pour un service qui au final n’est pas consommé par le client final. Il en est dépendant certes mais s’il ne fonctionne pas, le fournisseur reste coupable. C’est entre autre pour cette raison que le diagramme au-dessus référence deux host-group pour le Cloud du Fabric Management. Dans cette configuration, l’impact de la perte du Datacenter n’a aucun impact sur ces clusters. Ce qui manque, c’est d’assurer la haute disponibilité des ressources hébergées. Hyper-V Replica est tout désigné pour cela. En plus, cela simplifiera grandement les opérations de patching.

Doit-on avoir des clusters inter-sites ? Le cluster Hyper-v Inter-site, donc inter-Datacenter implique de disposer d’un stockage partagé entre les datacenters. Technologiquement, c’est possible. Par contre, cela implique d’abandonner l’approche Scale-Out FileServer de Microsoft (génération Windows Server 2012 R2) pour revenir aux baies de disques avec réplication de LUN. D’un point de vue service proposés aux futurs locataires, cela avait un sens pour proposer un mécanisme de failover en cas d’indisponibilité de Datacenter. Le problème, c’est que depuis Hyper-V 2012, on dispose de la fonctionnalité Hyper-V Replica qui permet de maintenir une copie de machine virtuelle sur un autre hôte hyper-V, voire même sur un autre cluster. Au final, on a donc plus besoin de clusters inter-sites.

Doit-on privilégier les grands clusters ? Comme vu précédemment, un cluster peut être composé de 64 nœuds et héberger jusqu’à 8000 machines virtuelles. Mais doit-on aller jusque-là ? Too big to fail ? Personnellement, je vois le cluster comme un domaine de panne. L’indisponibilité d’un nœud va nécessairement avoir des répercussions sur les autres, surtout si on se trouve en situation de surconsommation des ressources (plus de Cluster Reserve). Plus grand sera le cluster, plus important sera l’effet domino en cas de défaillance d’un ou plusieurs nœuds. Autre problème des grands clusters, la maintenance. Avec des grands clusters, le niveau de parallélisation des opérations de maintenance est moins important qu’avec des clusters de taille moins importantes. Cela a donc un impact sur la fenêtre de maintenance dont on disposera pour faire le maintien en condition opérationnel de la plateforme. Pour cette raison, je préfère limiter le nombre de nœuds au sein d’un cluster. Une limite à Seize nœuds me semble un compromis acceptable.

Maintenant, pour le design même des clusters Hyper-V, c’est très dépendant de votre architecture matérielle. D’un point de vue réseau, c’est fortement lié aux capacités d’offloading de vos cartes réseau et des capacités de votre cœur de réseau à accepter du 10Gb ou du 40Gb ou mieux. Du point de vue stockage, Microsoft propose son approche avec le Scale-Out file server mais c’est peut-être du stockage préexistant au sein de votre système d’information que vous voudriez utiliser (SAN). Ou alors êtes-vous prêt à l’hyper-convergence en regroupant compute, storage et network au sein d’une même appliance comme le propose Nutanix ou Windows Server 2016? Bref trop de variables pour proposer quelque chose de générique. Aujourd’hui, il y a une tendance vers l’hyper-convergence. C’est une approche technique intéressante mais elle impliquer de revoir aussi l’organisation. Ce ne sont plus trois équipes qui seront à la manœuvre (stockage, réseau et serveurs) mais bien une seule équipe « Cloud ». Sur ce sujet, quelques lectures intéressantes de collègues MVP qui ont déjà traités ces sujets bien mieux que moi :

 

Prochaine étape SCOM.

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

Architecture WAP – Design SQL Server

Alors, celui qui répond SQL Server 2014 en Always-On pour tout le monde, il sort, le bourreau l’attend à droite en sortant. Avant de répondre bêtement, il faut faire le tour du propriétaire, comprendre les applications que l’on va utiliser et comment on peut les rendre hautement disponible. Le tableau-ci-dessous résume tous les besoins en instances SQL Server et les quelques contraintes qu’on a besoin de connaitre.

Produit

Version SQL supportée

Support du Always On

Authentification

Windows Azure Pack 2008 / 2012 / 2014 depuis UR5 Oui Mixte
ADFS 3.0 2008 /2012/2014 Oui Windows Authentication
SCVMM 2012 R2 2012 et 2014 depuis UR5 Oui Windows Authentication
SCOM 2012 R2 2012 et 2014 depuis UR5 Oui Windows Authentication
SPF 2012 R2 2012 et 2014 depuis UR5 Oui Windows Authentication
Orchestrator 2012 R2 2012 et 2014 depuis UR5 Oui Windows Authentication
SMA 2012 R2 2012 et 2014 depuis UR5 Oui Windows Authentication
Service Reporting 2012 R2 2012 et 2014 depuis UR6 Oui Windows Authentication
Windows Azure Pack WebSites 2012 (pas d’info sur 2014) Attention le Always-On, c’est pas encore disponible.

Ce serait pour l’Update Rollup 9 en 2016.

Mixte
DPM 2012 R2 2012 et 2014 depuis UR6 Non Windows Authentication
Service manager 2012 R2 2012 et 2014 depuis UR6 Oui Windows Authentication
Windows Update Services 2012 et 2014 Pas de contre-indication connue Windows Authentication

Déjà première découverte, SCCM 2012 R2 n’est pas inclus dans la liste. Ce n’est pas une erreur, c’est un choix de ma part. Dans une infrastructure Windows Azure Pack, mon usage de SCCM 2012 R2 se serait limité à gérer le patching de mes hôtes Hyper-V et des machines virtuelles du Fabric Management. WSUS fait cela très bien. Après, SCCM 2012 R2 pourrait avoir d’autres usages mais SCVMM 2012 R2 sera tout à fait capable de :

  • Réaliser le déploiement des hôtes Hyper-V en Bare-Metal
  • Réaliser le déploiement des machines virtuelles

 

Ce choix n’est pas anodin. En retirant SCCM 2012 R2 de l’équation, on supprime au passage bon nombre de contraintes d’architecture. Si le sujet vous tente : Réflexions autour du Patch Management. Un peu d’Orchestrator, de PowerShell et d’huile de de coude et ça fonctionne. L’approche proposée utilisait SCCM mais WSUS sera faire tout aussi bien.

Certains peuvent se demander pourquoi SCSM est toujours présent. C’est que lui, il a quelque chose à offrir : Ses services Requests pour développer des services à destination de nos futurs locataires. Si le sujet vous intéresse, je vous renvoie à la série d’article : A la surface d’un service dans System Center Service Manager. En plus, avec une solution comme Grid-Pro, c’est directement intégré au portail de Windows Azure Pack. L’utilisateur final ne verra jamais Service Manager. Oui, je suis fan de SCSM. Et je m’en porte très bien !

Coté SQL Server, à part une exception avec Windows Azure Pack Web Sites, tous sont éligibles à SQL Server 2014. On a déjà identifié un premier boulet. Maintenant question subsidiaire, tous nos produits System Center pourraient-ils utiliser une même instance SQL Server ? En relisant ce tableau, on sait qu’on a quelques exceptions. Pour cause de mode d’authentification « exotique », la sécurité nous imposera une instance dédiée pour Windows Azure Pack et Windows Azure Pack Web Sites.

 

Maintenant, si on regarde du côté de la haute disponibilité, la liste des boulets va s’étoffer :

  • DPM 2012 R2 est allergique à la fonctionnalité « Always-On » de SQL Server
  • Windows Azure Pack Web Sites devra attendre jusqu’à l’update Rollup 9 pour supporter la fonctionnalité « Always-On » de SQL Server.
  • Windows Azure Pack Web Sites n’est pas encore supporté avec SQL 2014 (Update Rollup 9?)

 

Ce qui signifie que nos besoins peuvent maintenant s’exprimer ainsi :

  • Un Cluster SQL « Always-On « générique » pour tous produits de la gamme System Center sauf DPM
  • Un Failover Cluster SQL pour DPM 2012 R2
  • Un Cluster SQL Always-On pour Windows Azure Pack et son mode d’authentification exotique
  • Un Failover Cluster SQL pour Windows Azure Pack Web Sites (alias boulet en chef)

 

Précisions quelques points pour ce Cluster SQL Always-On « Générique ». Oui, technologiquement c’est faisable mais ce sera une question de performance. Des produits comme SCOM et SCSM sont très consommateurs en I/O. Les ressources CPU et mémoire ne poseront pas de problème si elles sont correctement allouées. Pour SCOM et SCSM, si on peut leur dédier du stockage performant, ce ne sera pas du luxe. Pour approfondir ce sujet, je vous conseille cette lecture : System Center 2012–using a common SQL backend database (#SYSCTR, #SCOM, #SCSM) et Mutualiser des bases de données ConfigMgr et OpsMgr.

 

Pour finir, nos produits de la gamme System Center ont aussi des instances pour leurs usages de Reporting Services. Techniquement, pas de problème pour les héberger sur notre cluster « Always-On Generique ». Après, ce sera nécessairement des serveurs dédiés pour héberger les instances Analysis Reporting Services. Cela concerne SCSM et SCOM. La tentation serait grande de regrouper tous ces besoins. Pas de chance, c’est pas possible : Reporting Services instances cannot be shared between System Center components.

A quelques détails près, on a fait le tour. Mettons tout cela sur un Visio histoire de fixer les choses.

clip_image001

 

Donc on va monter des clusters avec deux nœuds. Le problème, c’est qu’avec un nombre de nœuds pairs, il n’y a pas de majorité en cas de défaillance d’un seul nœud. Il faut un troisième votant qui prendra la forme d’un partage de fichiers. Pour cela, on va configurer nos clusters en mode « Node and File Share Majority ». La seule faiblesse de cette configuration, c’est que si on perd le Datacenter hébergeant la majorité des votants, il n’y a plus la majorité sur l’autre Datacenter. Ce n’est clairement pas parfait mais avec un peu de d’industrialisation, il n’est pas compliqué de déclarer un nouveau votant dans les clusters en cas de défaillance d’un Datacenter. Tous ces clusters et ressources de clusters dépendront du même domaine Active Directory hosting.local.

 

Dernier sujet, le nombre de clusters. Même si techniquement plusieurs instances SQL server peuvent cohabiter au sein d’un même cluster, dans notre contexte, il y a tout de même une distinction à faire au niveau du stockage consommé. Les instances « Failover cluster » utiliseront des ressources disques pour lesquelles un seul nœud ne peut être propriétaire à la fois. Ce n’est pas le cas des instances « SQL Always-On » pour lesquelles chaque nœud du cluster disposera de ressources disques dédiées. Ce sont deux types de stockages bien distincts mais aussi deux usages du cluster différents. Pour cette raison, je recommande de séparer les deux usages en deux clusters distincts.

Prochaine étape SCVMM.

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

Architecture WAP – Design infrastructure Active Directory Certificates Services

Les adeptes de la PKI en mode Click-Next aussi nommé « Quick and Dirty » peuvent s’arrêter ici. Je ne prétends pas proposer une infrastructure « state of the art » en la matière mais au moins une architecture censée, répondre à nos besoins. Tous les produits que nous allons mettre en œuvre dans notre infrastructure Windows Azure Pack vont avoir besoins de certificats délivrés par une autorité de certification. Nous allons avoir deux cas d’usage pour ces certificats :

  • Privé : Utilisés uniquement en interne et donc délivrés par une autorité de certification privée
  • Public : Utilisés en interne et depuis Internet, nécessitant d’être délivrés par une autorité de certification publique

Pour la partie publique cela va aller très vite, il faut juste faire les bons choix :

  • Choix autorité de certification : S’assurer qu’elle et référencée comme « Trusted » par le Windows Root Certificate Program
  • ADFS : Inutile de vouloir utiliser le Cryptographic Next Generation (CNG) pour générer la clé privée du certificat, c’est pas supporté avec Windows Server 2012 R2. Il existe des workarounds publiés ici ou là mais ce n’est certainement pas supporté par Microsoft
  • Référencer des FQDN privés pour des certificats issus d’une AC publique, cela n’est plus possible : All publicly trusted SSL Certificates issued to internal names and reserved IP addresses will expire before November 1, 2015.
  • Certificat Wildcard : La fausse bonne idée. Oui, techniquement, cela fonctionne. Le problème est plus de l’ordre du process. Si on arrive bien à utiliser ce certificat sur l’ensemble de notre infrastructure, seront nous capable de le renouveler et de le remplacer partout où il a été utilisé. Mon avis est que ce sera très difficile d’opérer tous les changements sur une infrastructure en production en un minimum de temps sans perturber le service rendu aux utilisateurs.

 

Remarques :

  • La troisième remarque aura son importance lorsqu’on arrivera à ADFS et la publication avec le Web Application Proxy. Ce sera donc un sujet sur lequel on reviendra à ce moment.
  • Dans certains pays comme la Suisse, le choix de l’autorité de certification publique sera limité à la liste restreinte des services de certification reconnus selon la loi sur la signature électronique (SCSE)

 

La partie publique est close, passons maintenant à l’autorité de certification privée et commençons par le sommet de la hiérarchie avec l’autorité racine.

Design autorité de certification racine

Dans notre contexte, une seule hiérarchie sera nécessaire, cela limite donc le nombre d’autorité racine à une. Problème, nous savons que s’il n’y en a qu’une, sa défaillance peut avoir de fâcheuses conséquences (impossibilité de mettre à disposition une CRL récente, …). Quand on parle défaillance, il peut y avoir deux grandes causes :

  • Physique / Virtuelle : Problème matériel empêchant le démarrage du système d’exploitation
  • Logiciel : Problème lié au système d’exploitation en lui-même empêchant de rendre le service

Dans le contexte d’un projet Windows Azure Pack, déployer notre autorité de certification racine sur une machine virtuelle a du sens. Avec la fonctionnalité Hyper-V Réplica, nous sommes en mesure de répliquer le contenu de la machine virtuelle dans une nouvelle enveloppe située dans le second Datacenter. Pour la défaillance logicielle Hyper-V Réplica ne pourra pas grand-chose pour vous, la seule solution réside dans un bon plan de sauvegarde / restauration. Ceci posé, nous pouvons aborder les choix d’installation :

  • Domaine versus Workgroup : Pour une autorité racine hors ligne ce sera Workgroup.
  • StandAlone versus Enterprise : la réponse va être rapide, ce sera Standalone car j’ai l’intention de respecter les best-practices et de configurer notre autorité de certification racine en mode « Offline »
  • Cryptographie : c’est le moment de faire les bons choix en terme de cryptographie. Typiquement, voilà les mauvais choix à ne pas faire aujourd’hui :

clip_image001

  • Période de validité : Rappeler-vous qu’une autorité de certification ne peut pas délivrer de certificat au-delà de la date d’expiration inscrite dans son certificat. Disons que le choix par défaut de 5 ans est un peu court. 10 ce sera mieux.
  • Durée de vie des CRL : Pour une autorité de certification racine, disons que la CRL aura une durée de vie d’un an. Notre autorité de certification racine devra être remise en ligne au moins une fois par an pour publier de nouvelles CRL et CRL Delta.
  • Séparation des rôles : C’est présent depuis Windows 2003 et ce n’est toujours pas du luxe. Pensez un peu aux RSI & RSSI qui voient se monter une infrastructure de clés publique à usage uniquement techniques
  • Multiples points de mise à disposition des CRL : Au moins un par Datacenter (chemin UNC). Si vous ne savez plus, allez lire un des best-off de la maison : Publier une PKI sur Internet.
  • Et pour finir la sauvegarde de la clé privée. La base de données ADCS ne sert à rien sans le certificat avec sa clé privée, rappel : ADCS CA private key location change (again).

Je suis allé volontairement à l’essentiel. Pour le reste :

Pour finir, un rappel, pour sécuriser cette autorité de certification, on voudra mettre en place Hyper-V Réplica. Dans la logique de vouloir sécuriser la copie entre le serveur Hyper-V primaire et son partenaire, on voudra utiliser l’authentification par certificat. C’est une excellente idée. La subtilité, c’est qu’il faudra attendre d’avoir une autorité de certification intermédiaire / émettrice de certificats pour cela. Passons maintenant aux autorités émettrices de certificats.

Design autorité de certification intermédiaire / émettrice

Le sujet autorité racine étant clos, passons à celui des autorités intermédiaires et émettrices de certificats. Dans le contexte d’un déploiement Windows Azure Pack, je n’ai pas de motif technique, sécurité, règlementaire ou même business nous forçant à avoir une hiérarchie de type trois tiers (racine, intermédiaire, émettrice). Vu que notre autorité racine est « hors ligne », on va logiquement allers vers une hiérarchie de type deux tiers (racine, intermédiaire & émettrice). Maintenant, posons-nous la question, pouvons-nous avoir une seule autorité intermédiaire / émettrice pour tous nos usages ? D’un point de vue purement technique oui. Par contre du point de vue de la sécurité, la logique voudrait que non car tous les certificats qui vont être délivrés n’ont pas la même valeur / criticité. Dans notre contexte, je vois deux usages :

  • Les certificats à usage technique
  • Les certificats à usage d’identité

Lorsqu’on va vouloir renforcer la sécurité du Fabric Management, on aura besoin de certificats permettant à nos exploitants de prouver leur identité. Apporter la preuve de son identité, c’est un process qui peut être plus ou moins complexe mais qui à la fin se finira par une action technique pour délivrer le certificat. Le problème, c’est que si on utilisait une seule autorité de certification pour les deux usages de certificats, il pourrait être assez facile pour un exploitant de se gérer des identités. Pour éviter cela, on va séparer les usages. Nous aurons donc deux autorités intermédiaires / émettrices de certificats. Côté technique, les choix seront quelque peu différents :

  • Domaine versus Workgroup : Pour une autorité intermédiaire / émettrice, elle sera raccordée au domaine
  • StandAlone versus Enterprise : la réponse va être rapide, ce sera Enterprise car cela autorise des scénarios intéressants tel que l’Auto-Enrôlement
  • Cryptographie : Plus possible de faire les mauvais choix, c’est l’autorité racine qui va nous imposer les bons choix
  • Période de validité : Logiquement, la durée de vie sera inférieure à celle de l’autorité racine
  • Durée de vie des CRL : Pour une autorité de certification intermédiaire
  • Séparation des rôles : C’est essentiel pour les autorités de certification intermédiaires
  • Multiples points de mise à disposition des CRL : Au moins un par Datacenter (chemin UNC). Si vous ne savez plus, allez lire un des best-off de la maison : Publier une PKI sur Internet. OCSP serait même un luxe à ne pas négliger

 

L’indisponibilité d’une autorité de certification émettrice de certificats pose aussi beaucoup de problèmes. On devra donc penser haute disponibilité. Immédiatement, on pense à deux fonctionnalités :

  • Hyper-V Réplica
  • Le cluster Hyper-V

Dans un contexte multi-Datacenter, le choix du cluster peut poser problème si on ne dispose pas d’un Geo-Cluster entre les deux Datacenter. Cela implique qu’on soit capable de répliquer le stockage via un réseau WAN très performant. Ce n’est pas forcément possible. Par contre, on peut très bien combiner les deux approches. C’est aussi valable pour notre autorité de certification racine. Toute notre hiérarchie sera hébergée sur un cluster dédié (on verra pourquoi plus tard). Les machines virtuelles seront donc des ressources du cluster en question. On installera le Rôle Hyper-V broker sur ce cluster afin de pouvoir mettre en place Hyper-V Réplica vers un autre cluster situé dans un autre Datacenter.

clip_image002

 

Pour la disponibilité des CRL, j’ai volontairement fait simple avec une double publication :

  • Dans des partages de fichiers hébergés sur des contrôleurs de domaine
  • Dans l’Active Directory

 

Ici encore, je suis allé volontairement à l’essentiel. Pour les détails, je vous renvoie vers d’excellents articles / billets :

 

Pour clore ce billet, cette implémentation n’a pas prétention à être parfaite, il reste encore beaucoup à faire mais cela sort du cadre d’une infrastructure Windows Azure Pack :

  • Pas de HSM pour permettre du Key Archival
  • Pas de support d’Online Responder Revocation Policy (OCSP) en plus des CRL
  • Pas de support de l’enrôlement de certificats par Web Services
  • Pas de gestion de l’auto-enrôlement

On est déjà bien loin du Quick and Dirty.  Prochaine étape SQL Server.

 

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

Architecture WAP : Introduction

Ca faisait quelques temps que nous avions pas fait un tour dans le donjon, le revoilà. On va continuer à parler de Windows Azure Pack. Non pas pour ajouter de nouveaux composants mais pour les revisiter et discuter architecture et répondre principales questions liées au design d’une infrastructure Windows Azure Pack hautement distribuée. Avant de parler de Windows Azure Pack, nous allons avoir beaucoup de sujets de discussions :

Cela va rester du haut niveau. L’idée est de répondre aux questions les plus importantes pour poser les fondations de votre future infrastructure Windows Azure Pack. Je fais l’impasse sur la conception même des Stamps que vous allez déployer, il y a trop de paramètres à prendre en compte, ça dépasse de loin le cadre de l’architecture d’une infrastructure Windows Azure Pack. On commence avec une page blanche, à savoir deux Datacenters interconnectés par un bon WAN :

clip_image001

Bonne lecture, on commence avec un sujet simple pour commencer : Design infrastructure Active Directory.

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

Architecture WAP – Design infrastructure Active Directory

Ça semble tellement simple qu’on se demande pourquoi il faudrait se poser la question. Si simple vous dites? Entrez, on va discuter, … On va effectivement commencer avec un AD pour le cœur de notre infrastructure. On va donc y raccorder :

  • L’infrastructure ADFS
  • Notre infrastructure Windows Azure Pack (partie privilégiée)
  • Notre infrastructure Windows Azure Pack (partie locataire)
  • L’infrastructure SCOM (management Server et Dataware House Server)
  • L’infrastructure Service Manager Automation / Orchestrator
  • L’infrastructure SCVMM avec son Service Provider Foundation

Etrange, je n’ai pas cité les clusters Hyper-V? C’est normal car on va faire les choses correctement. Tous les produits cités précédemment constituent le Fabric Management de notre infrastructure Windows Azure Pack. Une bonne pratique est d’isoler ces composants dans une forêt d’administration dont l’accès sera limité aux seuls exploitants de la plateforme. Maintenant, parlons des Clusters Hyper-V. On va distinguer :

  • Les clusters Hyper-V utilisés pour héberger le Fabric Management
  • Les Clusters hyper-V utilisés pour héberger les workloads de nos futurs locataires

 

Pour le Fabric Management, il est logique de les raccorder à la forêt d’administration. Au passage, c’est dans ce domaine que sera réalisé la préparation de domaine pour stocker les secrets de SCVMM. Pour rappel, lors de l’installation de SCVMM on doit décider si on veut stocker les clés de SCVMM localement ou dans l’Active Directory. C’est ce dernier choix qui sera le bon. Ces clés sont essentielles car sans elles on ne peut pas accéder à la base de données de SCVMM. Je vous laisse deviner ce qui se passerait si on avait retenu de les stocker localement et qu’on ait perdu le serveur physique ou virtuel. Comme une petite piqure de rappel ne fait jamais de mal, autant, quelques lectures saines :

clip_image001

Maintenant attaquons nous au problème des clusters Hyper-V prévus pour héberger les workloads de nos futurs locataires. Doit-on les raccorder à la forêt d’administration? La réponse est dans la question. Il faut une claire séparation entre les usages. On va donc avoir une second forêt que je nomme « hosting.local » qui disposera d’une relation d’approbation unidirectionnelle (sécurité oblige). On y placera les clusters Hyper-V qui hébergeront les workloads de nos locataires. Si tout était si simple ce serait bien. Nous n’avons pas encore parlé de l’infrastructure WebSites. Pour rappel, elle comprend les rôles suivants :

  • Management Server
  • Controller
  • Database
  • Publisher
  • File Server
  • Web Worker
  • Frond-End

L’infrastructure Azure Pack Web Sites présente l’avantage de pouvoir fonctionner indépendamment des domaines avec des machines en Workgroup. Sur le papier, c’est pas mal. Le problème, c’est que cela rend cette infrastructure plus compliquée à exploiter. Essayons de raisonner différemment. Quels sont les rôles qui assurent la gestion de l’infrastructure et quels sont ceux qui sont consommés par les locataires :

  • Management : Participe à la gestion de l’infrastructure
  • Controller : Participe à la gestion de l’infrastructure
  • Database : Participe à la gestion de l’infrastructure
  • Publisher : Participe à la gestion de l’infrastructure
  • File Server : Participe à l’usage par les locataires
  • Web Worker : Participe à l’usage par les locataires
  • Frond-End : Participe à la gestion de l’infrastructure

On comprend que bon nombre de rôles sont liés à la gestion de l’infrastructure. Les instances de ces rôles seront donc déployées sur des machines virtuelles raccordées au domaine d’administration. Il ne nous reste que File Server et Web Worker. Ces deux rôles sont directement liés aux locataires :

  • File Server : Stockage et dépôt des packages WebDeploy des locataires et donc repository des sources pour alimenter les instances Web Worker
  • Web Worker : Consommation des packages Web Deploy en mode cohabitation ou isolé

Pour ces deux rôles, la recommandation est effectivement de les raccorder au domaine « hosting.local ». Pour conclure, voilà les bases de notre infrastructure Active Directory posées :

clip_image002

Avec deux Datacenters, je commence par poser deux zones réseau distinctes pour bien séparer les deux forêt Active Directory qui vont être mises en place. Dans chaque Datacenter, les contrôleurs de domaine de chaque forêt seront hébergés sur des clusters Hyper-V distincts. Nous aurons donc :

  • Deux clusters Hyper-V distincts pour héberges les contrôleurs de domaine du domaine WindowsAzurePack.Local
  • Deux clusters Hyper-V distincts pour héberges les contrôleurs de domaine du domaine hosting.local

De cette manière, chaque Datacenter est indépendant de l’autre. La défaillance d’un Datacenter n’aura donc aucun impact sur le service Active Directory et ce pour les deux forêts.

Remarques :

  • J’ai volontairement exclus le choix Workgroup pour l’infrastructure Web Sites de Windows Azure Pack. Ce mode de fonctionnement nous interdit de proposer à nos locataires une authentification Windows intégrée dans leurs sites web. S’interdire de proposer du service à nos futurs locataires est un non-sens
  • Les contrôleurs de domaine sont nécessairement des serveurs physiques, Pas de concession sur ce point.
  • J’ai volontairement exclus de parler des RODC. Pour la forêt d’administration, il n’y a pas de besoin vu que c’est une forêt isolée. Pour la forêt dédiée aux locataires, ça peut avoir un sens mais uniquement pour le rôle Front-end

Alors, toujours un simple Active Directory posé sur un coin de table?

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

Windows Azure Pack Web Sites, problème de Front-End qui démarre pas

Ca faisait quelques temps que j’avais pas jeté un œil sur ma maquette Windows Azure Pack. En me connectant ce matin, je découvre que mon rôle Font-End est en cours d’installation. C’est ballot. Vu que sur ma maquette, les rôles de l’infrastructure Web Sites ne sont pas configurés en haute disponibilité, sans Font-End, y a plus rien de publié sur Internet. C’est un sujet que j’avais déjà rencontré par le passé. J’avais posé la question sur le forum Technet : Windows Azure Pack WebSites front-end role stuck in starting. A l’époque, j’étais encore en UR6. Ca faisait quelques temps que l’UR7 était en place, j’avais pas rencontré le problème depuis. J’avais donc clos le sujet.

clip_image001

 

Sur le rôle contrôleur, la console Windows Azure WebSites nous indique que le rôle Front-End est en cours de démarrage et que pendant celui-ci, l’installation d’un composant a échoué.

clip_image002

 

Allons faire un tour sur le serveur concerné, plus précisément dans le journal WebFarmFramework/Operational.

clip_image003

 

C’est un problème avec le Certificate Synchronization Service. Plus précisément, impossible d’installer le service. Ce qu’il faut comprendre c’est que dans une architecture WebSites, le contrôleur s’assure régulièrement que tous les composants sont à niveau. Pour cela, il les réinstalle. Ça peut paraitre étonnant mais à grande échelle (nombreux serveurs dans l’infrastructure), c’est un choix d’architecture gagnant. On ne se pose pas la question de savoir ce qui manque, en réinstallant tout, on est assuré que tous les instances du même rôle sont bien installés avec les mêmes versions des composants.

clip_image004

 

Après quelques heures de recherche, je n’ai pas trouvé la cause initiale du problème. En attendant, j’ai quand même trouvé :

  • Une correction
  • Deux contournements

La correction consiste à désinstaller le rôle Font-End puis de demander sa réinstallation sur le même serveur. Pour une raison que j’ignore encore, le service « Certificate Synchronization Service » se réinstalle correctement. Par contre, de ce que j’ai pu observer, cela ne fonctionne pas à tous les coups.

Le premier contournement consiste à disposer d’au moins deux instances pour le rôle Font-End. Ça ne corrige pas le problème mais si au moins une des deux instances est opérationnelle, le service est opérationnel du point de vue des locataires. Cela donne le temps de tenter la correction.

Le second contournement est issu de quelques expériences avec ma plateforme. Après plusieurs redémarrages de l’infrastructure WebSites, j’ai remarqué que le problème ne semblait pas survenir lorsqu’on s’assure que le rôle Font-end démarre en dernier.

Au final, toutes les instances de mes rôles de mon infrastructure WebSites sont de nouveau opérationnels.

clip_image005

­

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

Architecture Windows Azure Pack WebSites – Etape n°4 : Mise en place du rôle Publisher

La liste des rôles a été longue, il n’en reste plus qu’un. Ça veut pas dire pour autant que c’est déjà la fin de la séance de torture, bien au contraire. Allons y. Last but not least, le rôle Publisher. Tout comme pour le rôle Front-end, il est exposé sur Internet, à ce titre, il méritait une zone réseau dédiée sur ma maquette. La bonne pratique est bien entendu de ne pas exposer ce rôle directement sur Internet mais d’utiliser des solutions de type reverse-Proxy pour l’exposer.

clip_image001

 

Pour rappel, c’est grâce à ce rôle que nos futurs locataires vont pouvoir venir déposer le futur contenu de leurs sites web. D’un point de vue sécurité, le contenu de tous les sites Web de nos locataires ne sont pas directement exposés sur Internet. Avant de rentrer dans la configuration du rôle, quelques subtilités. Mes instances du rôle Web-Publisher seront accessible depuis Internet via le nom webpublisher.windowsazurepack.fr mais aussi via les alias (CNAME) suivants :

clip_image002

 

Note : Depuis L’UR7, L’URL de publication de WebDeploy a été modifiée poursite.scm.domain.com.  J’ai donc ajouté l’URL supplémentaire mais pas supprimé l’ancienne.

 

Donc au final, mes instances du rôle Web-Publisher seront accessibles sous trois noms :

C’est nécessaire pour supporter les multiples protocoles d’accès. Vu que ce rôle est visible depuis Internet, il est logique qu’on sécurise les communications. Nous avons donc besoin d’un certificat qui réponde au nom Webpublisher.Windowsazurepack.fr mais aussi aux deux autres noms. Le certificat a été délivré par une autorité de certification publique. Pour vérification, l’attribut DNSNameList contient bien les noms indiqués :

Get-ChildItem Cert:\localMachine\My | Where {$_.Subjectname -eq « cn=webpublisher.windowsazurepack.fr »} | Select Subject, DNSNameList

clip_image003

 

Note : Attention à bien avoir demandé un certificat pour lequel nous pourrons bien exporter la clé privée. Le certificat devant être mis en place sur toutes les instances du rôle Web-Publisher ainsi que mis à disposition de Windows Azure Pack.

 

Nous en avons fini avec les prérequis, passons à la configuration de notre serveur. Il y a un peu moins de travail que pour les autres :

  • Socle : Windows Server 2012 R2 de préférence raccordé au domaine
  • Rôles & Fonctionnalités : Framework Dot.Net 3.5.1 installé (attention, y a un piège)
  • UAC : Désactivé
  • Compte WAP\FT-WAP-WEB01 membre du groupe local administrators
  • Le certificat SAN importé dans le magasin personnel de l’ordinateur
  • Quelques règles de pare-feu entrantes :
    • Protocole « Windows Management Instrumentation (WMI-In) »
    • Protocole WINRM (HTTP TCP 5985)
    • Protocole WINRM (HTTPS TCP 5986)
    • Protocole Web Farm Framework Agent (TCP 8173)
    • Protocole FTP
    • Protocole WebDeploy TCP 443/TCP 8172

Comme pour les autres rôles, nous allons réaliser le déploiement depuis la console Windows Azure pack Web Sites et demander le déploiement de notre première instance du rôle Publisher.

clip_image004

 

Le processus commence par installer l’ensemble des composants nécessaires à son bon fonctionnement du rôle Web-Publisher. Comme pour les rôles précédents, la liste des composants à installer est mise à disposition par le contrôleur ainsi que le contenu.

clip_image005

 

Note : Le processus d’installation va automatiquement redémarrer le serveur pour finaliser l’installation.

On a achevé la mise en place de tous les rôles de l’infrastructure Web Sites, on peut donc passer à l’intégration avec Windows Azure Pack?

clip_image006

 

La séance est presque terminée. C’était le dernier rôle. Normalement, tous devrait répondre présent.

Get-WebSitesServer | Select Name, Role, Status, PlateformVersion | Format-Table -AutoSize

clip_image007

 

On peut facilement s’en assurer avec le Best Practice Analyzer dédié à l’architecture Web Sites. Commencez par installer le Microsoft Baseline Configuration Analyzer 2.0 sur le contrôleur de l’architecture Web Sites ainsi que le package correspondant à l’architecture Web Sites. Dans l’illustration ci-dessous, on constate deux points :

  • Je n’ai qu’une seule instance du rôle contrôleur. C’est effectivement critique car sans elle, y a plus de pilote dans l’avion. C’est assez simple d’ajouter une instance secondaire pour ce rôles.
  • Je n’ai pas nécessairement de multiples instances pour les autres rôles. j’ai donc des domaines de panne dans mon infrastructure.

clip_image008

 

Nous en avons fini avec la mise en place de l’infrastructure Web Sites. Il est temps de la connecter à notre infrastructure Windows Azure Pack. Ce sera pour le prochain billet.

 

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

Architecture Windows Azure Pack WebSites–Introduction

Dans les “Resources Providers » de Windows Azure Pack, s’il y en a un qui mérite qu’on y passe du temps, c’est Web Sites. C’est un univers à part entière, un vrai jeu de Lego. En plus, c’est le Resource Provider qui a le plus évolué dans Windows Azure Pack puisque nous en sommes à la version 2.0 Update 6 et qu’il continue d’évoluer en permanence. On trouve déjà bon nombre d’excellents billets décrivant la mise en œuvre de l’architecture Web Sites. Cependant, la mise en œuvre a bien changé avec le passage à la version 2. C’est pour cette raison que j’ai décidé de blogger sur le sujet.

Le grand changement, c’est sa mise en œuvre qui a été simplifiée avec l’introduction de la console d’administration Windows Azure Pack Web Sites. C’est une bonne vieille console MMC. Les principaux changements apportés par cette version de Web Sites sont :

  • La désactivation de SSL v3 (sécurité oblige)
  • La prise en charge des Web Jobs pour exécuter des tâches sur les Web-Worker (comme son grand frère Microsoft Azure)
  • Intégration du production/staging site slots (comme son grand frère Microsoft Azure)
  • Prise en compte du module IIS HttpPlatformHandler pour permettre à des applications tel que Java d’écouter directement sur HTTP

Vu que l’architecture est un peu compliquée, on va prendre le temps de la détailler avant de rentrer dans le vif du sujet. Commençons par la « Big-Picture ». Ci-dessous une illustration du Technet que l’on va utiliser pour décoder un peu la bête.

clip_image001

 

Première remarque, pas une seule trace de Windows Azure Pack. C’est normal. On y viendra plus tard. Pour commencer, Windows Azure Pack Web Sites, c’est pas un simple serveur web IIS posé dans un coin. C’est une architecture complète pour de l’hébergement de sites Web / Web Services hautement disponible, multi-tenant proposant plusieurs classes d’hébergement partagé ou dédié. Pour le locataires les services proposés sont relativement proches de ceux proposés dans Microsoft Azure (je dis bien relativement proche), le tout en offrant accès à tout ce qu’on peut héberger sur IIS. La liste est longue, trop longue. Ce billet est le premier d’une série à part entière sur cette architecture. Maintenant que les présentations sont faites, entrons dans le vif du sujet. On dénombre les rôles suivants :

  • Controller Server(s)
  • Management Server(s)
  • Runtime DB Server(S)
  • File Server Server(s)
  • Front-End Server(s)
  • Web Worker Server(s)
  • Publisher Server(s)

Première remarque, ça fait du monde à caser sur ma plateforme. Ça tombe bien, en attendant Microsoft Azure Stack, j’avais rien à décortiquer cet été. Seconde remarque, on ne peut pas co-localiser plusieurs rôles sur un même serveur. Il y a des raisons techniques mais aussi des considérations sécurité dont il faut tenir compte. Conclusion, vous pouvez déjà provisionner six nouveaux serveurs sur votre architecture Windows Azure Pack, le double si on veut gérer les domaines de panne et un peu plus si la scalabilité et la performance sont au programme. Tous ces serveurs seront raccordés au domaine pour des raisons de simplicité de mise en œuvre et d’administration. Cependant, il est tout à fait possible de mettre en œuvre une architecture Websites avec des hôtes en workgroup. C’est juste plus compliqué à administrer.

Note : Si on veut pouvoir proposer le mécanisme d’authentification AD dans une infrastructure Web Sites, il est obligatoire que les instances du rôle Web Worker soient installées sur des serveurs membres du même domaine Active Directory : Enable Windows Authentication for Windows Azure Pack: Web Sites.

 

Commençons avec le rôle le plus simple et le premier que nous allons installer : Le rôle Controller. Il va lui jouer le rôle de chef d’orchestre de l’infrastructure Web Sites, organiser le déploiement de tous les rôles et assurer la mise à niveau / réparation de tous les rôles déployés. C’est aussi lui qui sera chargé de réaliser le provisioning des sites web pour le compte des locataires. Une seule instance de ce rôle suffit dans un POC. Par contre, en environnement de production, il faudra au moins en avoir deux, sachant qu’un seul est actif à l’instant T.

Le Management Server. C’est lui qui héberge les Web Services qui vont s’interfacer avec Windows Azure Pack (AdminAPI, Monitoring API, Usage API). La recommandation est d’installer ce rôle sur un / plusieurs serveurs dédiés si on veut la haute disponibilité. Ce rôle est l’interface avec Windows Azure Pack et ses API. Ne pensez même pas co-localiser ce rôle sur votre plateforme Windows Azure Pack, le résultat sera désastreux pour ce dernier.

Le Runtime DB , c’est une instance SQL dédiée qui peut être configurée en « Always On » pour assurer la haute disponibilité du rôle. C’est donc cette base de données qui va contenir toutes les informations à l’architecture Websites ainsi qu’aux sites web hébergés pour les locataires. Dans le contexte de ma maquette, j’ai hébergé cette base de données sur le serveur SQL de mon infrastructure Windows Azure Pack. C’est le seul rôle que l’on puisse mutualiser en fait.

Le rôle File server sert à stocker le contenu des Web Sites qui seront mis en place. Là où cela devient marrant, c’est que ce n’est pas sur ce serveur que les locataires viendront déposer le contenu de leurs futurs sites web. Pour cela on dispose du rôle Publisher.

Le rôle Publisher sera exposé sur Internet et fournira aux locataires plusieurs moyens (FTP, Visual Studio, Web Matrix, … ) pour déposer le contenu qui devra être mis à disposition sur le web Sites du locataire. Lorsque l’architecture Web Sites aura assigné un site IIS à un locataire, le rôle Web-Worker provisionnera le site web avec le package disponible sur le rôle File-Server. C’est WebDeploy qui sera utilisé pour cette tâche.

On parle de Web Sites, pourtant jusqu’à maintenant, on n’en voit pas beaucoup la couleur. Entrons dans le vif du sujet avec le Web Worker Role. C’est lui qui va héberger les sites Webs de nos locataires. On distinguera deux types d’instances proposant chacune plusieurs classes de performance :

  • Dedicated
  • Shared

 

Il ne nous en reste plus qu’un, le rôle Front-End. Nos instances du Web Worker Role ne sont pas directement exposées sur Internet mais au travers du rôle Front-End. C’est lui qui va être chargé de router les requêtes vers la bonne instance du Web Worker Rôle et donc le bon site web. C’est Application Request Routing qui assure cette fonction.

Voilà pour la théorie. Pour la pratique. J’ai déployé mes nouveaux serveurs dans mon infrastructure Windows Azure Pack tel qu’illustré ci-dessous :

clip_image002

 

Pour la répartition, c’est segmenté en deux grandes familles :

  • Les rôles « infrastructure » de l’architecture Web Sites
    • Les instances du rôle Web-Front exposées sur Internet ou via Reverse Proxy
    • Les instances du rôle Web-Publish exposés sur Internet ou via Reverse Proxy
    • Les instances du rôle File-Server qui elles n’ont absolument pas besoin d’être exposées sur Internet
  • Les rôles « Tenant » de l’architecture utilisés par nos futurs locataires
    • Les instances du rôle Web Worker Shared qui n’ont pas besoin d’être exposées sur internet
    • Les instances du rôle Web Worker Dedicated qui n’ont pas besoin d’être exposées sur internet

Normalement, à ce stade, j’ai perdu personne, mais c’est maintenant que cela se complique. L’architecture Web Sites est à la fois complexe et très riche. On ne pourra donc pas tout traiter en un seul billet. Voilà la liste des réjouissances prochaines :

Prêt pour une nouvelle séance de torture? Pour vous mettre dans l’ambiance, un peu de réseau. Les fans de la segmentation réseau à outrance vous pouvoir se faire plaisir ou mal, c’est selon.

clip_image003

 

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