Archives de catégorie : Design

Découverte Azure Queue

Dans mes projets Azure, j’accompagne souvent des clients qui migrent leurs applications vers Azure. Ces applications sont souvent organisées en front-end / back-end. Généralement, ça prend le forme d’un serveur web IIS/Apache pour la partie frontale et SQL Server / MySQL pour la partie back-end. D’un point de vue technique, il est tout à fait possible de migrer l’application dans Azure tel que. Pour une migration rapide, cela fonctionne. Par contre, il ne faut pas se leurrer, on aura des problèmes de scalabilité. Augmenter le nombre d’instance (scale-out) du composant frontal ne pose pas de problème particulier. Par contre, pour le composant dorsal, c’est un peu plus compliqué. On va être limité au Scale-Up. Or, si on multiplie le nombre de composants Front-end en conservant une unique instance du composant back-end (quel que soit la taille de l’instance), ça va pas le faire. Rien que la saturation des ports TCP, ça va être fatal.

C’est là qu’il est intéressant de passer un peu de temps dans les Design Patterns du Cloud (Azure). Un des Design Patterns va nous intéresser, celui nommé Queue-Based Load leveling. Le mécanisme de la Queue permet de jouer le rôle de buffer entre les multiples instances de notre composant frontal et notre unique composant dorsal. Cette approché permet de réduire l’impact de pics de charge et la disponibilité de notre application.

clip_image001

Dans le contexte de notre application, nous allons donc avoir de multiples instances qui vont déposer des messages dans une file d’attente qui sera dépilée par la partie back-end. Toujours dans les Design Patterns, on en trouve un très intéressant : Competing Consumers Pattern.

clip_image002

Si on arrive à introduire un service qui traite les messages déposés avant d’attaquer la base de données, on autoriser le traitement des messages en parallèle, augmentant la puissance de traitement tout en offrant scalabilité, disponibilité pour notre application. Voilà pour la théorie. Passons maintenant à la pratique dans Azure. Dans Azure, nous avons deux services de queues mis à notre disposition :

  • Azure Queues
  • Azure Service bus Queues

D’un point de vue technique, on peut dire qu’Azure Queues est la version basique et Azure Service bus Queues la version haut de gamme capable de gérer :

  • Des messages de plus grande taille
  • Une file d’attente de plus grande taille

Pour illustrer le propos, regardons ce qu’on peut faire avec la fonctionnalité Azure Queue qui est un sous-composant du Storage Account. On va commencer par se créer un environnement avec un groupe de ressources avec un Storage Account :

New-AzureRmResourceGroup -Name StorageQueue -Location « West Europe »

New-AzureRmStorageAccount -ResourceGroupName StorageQueue -Name storagequeuetp -Location « West Europe » -SkuName « Standard_LRS » -Kind Storage

clip_image003

 

Maintenant, nous avons juste besoin de récupérer la clé primaire d’accès à notre Storage Account pour générer une clé de contexte SAS et générer notre file d’attente :

$keys = Get-AzureRmStorageAccountKey -ResourceGroupName storagequeue -Name storagequeuetp

$context = New-AzureStorageContext -StorageAccountName storagequeuetp -StorageAccountKey $keys[0].value

New-AzureStorageQueue -name « tpabc » -Context $context

$Queue = Get-AzureStorageQueue -Name « tpabc » -Context $context

clip_image004

 

Positionnons-nous du côté de l’émetteur des messages, la partie front-end de notre application. En PowerShell, ce n’est pas aussi simple. Faut jouer un peu avec Dot.Net.

$message = New-Object -TypeName Microsoft.WindowsAzure.Storage.Queue.CloudQueuemessage -ArgumentList « Message à stocker dans la queue »

$Queue.cloudqueue.AddMessage($Message)

$Queue = Get-AzureStorageQueue -Name tpabc -Context $context

$Queue

clip_image005

 

En actualisant la variable $Queue, on constate que l’on a bien un message déposé dans la file d’attente. Maintenant, plaçons nous coté Back-End de l’application et dépilons les messages reçus

$InvisibleTimeout = [System.TimeSpan]::FromSeconds(10)

$dequeuemessage = $queue.cloudqueue.getmessage($InvisibleTimeout)

$dequeuemessage

clip_image006

 

Nous n’avons fait que lire ce message. Une fois le message traité, nous devons le supprimer de la queue :

$Queue.CloudQueue.DeleteMEssage($dequeuemessage)

$Queue = Get-AzureStorageQueue -Name tpabc -Context $context

$Queue

clip_image007

 

Constat : le compteur est revenu à 0.

Conclusion, migrer une application dans le Cloud ne la rend pas « Cloud native ». Cela implique bien souvent de la repenser en fonction des différents Design Patterns. Ça sert de venir à mes cours Azure. Que du TP custom avec des vrais morceaux de projets Azure.

Benoits – Simple and secure by design but Business compliant (with disruptive flag enabled)

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)

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)

Patching out of band, cas concrêt

C’est quand on traite des sujets qui n’arrivent jamais que ça tombe. J’avais publié voilà quelques jours une série de billets sur le Patch Management d’une infrastructure de type cloud privé. Certaines personnes m’ont demandé pourquoi devait-on prévoir un processus pour les patchs out of band, … La réponse est tombée ces jours-ci : Microsoft Security Advisory 3108638.

L’alerte est d’importance car ça touche l’Hyperviseur. En lisant plus précisément le bulletin de sécurité, on découvre que la « faille » ne se trouve pas dans Hyper-V mais dans le processeur lui-même. Conséquence, c’est toutes les versions d’Hyper-V qui sont affectées :

  • Windows 2008
  • Windows 2008 R2
  • Windows 2012
  • Windows 2012 R2
  • Windows 8.1
  • Windows 10

C’est disponible dans Windows Update, donc pour action immédiate. Vu que c’est une problématique indépendante du logiciel, tous les Hyperviseurs sont donc affectés. Une recherche rapide sur Google Bing vous donnera les liens pour les autres hyperviseurs du marché :

Remarque : Il ne faut pas voir de mauvais esprit anti-VMWARE de ma part mais Google / bing n’a pas été mon ami pour trouver l’information chez eux sans accès à la Knowledge Base.

Alors convaincu qu’il est important d’avoir un process de patch management out of band dans votre infrastructure Cloud privé? Maintenant, vous avez deux choix :

  • Choix n°1 : Tester le déploiement en urgence à l’arrache sans concertation avec vos locataires avec un résultat attendu.

clip_image001

clip_image002

Alors, prêt à patcher?

­

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