Windows Azure Pack – IaaS : Installation du Service Provider Foundation

L’installation du Service Provider Foundation en elle-même n’est pas très compliquée. Les prérequis sont disponible ici. La subtilité, c’est que Service Provider Foundation va mettre en place quatre Web Services. Chaque Web Service devant disposer d’un contexte de sécurité qui lui est propre, cela implique un peu d’isolation. Chaque Web Service disposera donc :

  • D’un compte de domaine pour le contexte d’exécution
  • D’un groupe local de Sécurité sur le serveur SPF
  • D’un pool applicatif IIS

 

Compte AD de service

Groupe de sécurité local

Pool applicatif IIS

WAP\FT-SPF-SVC SPF_Admin Admin
WAP\FT-SPF-Provider SPF_Provider Provider
WAP\FT-SPF-VMM SPF_VMM VMM
WAP\FT-SPF-Usage SPF_Usage Usage

 

Pour le détail des explications, je renvoie vers le Technet : Security Planning for Service Provider Foundation. Ma maquette devenant un peu à l’étroit, je suis obligé de réduire la voilure. Je comptais installer le Service provider Foundation sur un serveur dédié pour préparer la haute disponibilité mais j’ai finalement retenu de l’installer sur mon serveur SCVMM. En même temps, ce n’est pas illogique. En plus, cela réduit le nombre de prérequis à installer car la console SCVMM sera déjà présente.

clip_image001

 

D’un point de vue sizing, j’ai retenu les recommandations Microsoft : Capacity Planning for Service Provider Foundation.

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

 

Ça peut paraitre beaucoup mais derrière, le SPF va cracher du PowerShell. Il faut pouvoir paralléliser un tant soit peu. Par défaut, notre SPF est capable de traiter jusqu’à 1000 connexions concurrentes pour ses Web Services.

On peut s’attaquer à l’installation du Service Provider Foundation. Le composant est disponible sur le média d’installation d’Orchestrator 2012 R2.

clip_image002

 

Coté prérequis il y a du monde. D’un côté nous avons Windows Azure Pack qui ne communique que par Web Service (OData). Logiquement, on a donc un IIS pour les prérequis, avec le "Management Odata IIS Extension". De l’autre côté, le Service Provider Foundation doit communiquer avec SCVMM. Pour cela, rien de mieux que la console SCVMM et le module PowerShell associé. Pour les autres, ce ne sont que quelques rôles et fonctionnalités.

clip_image003

 

Le premier besoin de Service Provider Foundation, c’est une base de données. L’objectif est de stocker la configuration mais aussi les éléments tel que les mesures d’usages qui seront remontées au UsageCollector de Windows Azure Pack. Il faut juste se rappeler que les données d’usage sont conservées pendant quarante jours. Pour 25000 machines virtuelles, il faut au prévoir 5Gb pour cette base de données.

clip_image004

 

Pour commencer, il nous faut un site web IIS qui utilisera un port spécifique (8090). Il sera utilisé pour héberger un Web Service qui utilisera un certificat SSL. Pour notre installation, nous avons exclus l’utilisation d’un certificat auto-signé pour un véritable certificat émis par notre autorité de certification interne (C’est une erreur sur l’illustration ci-dessous, je le précise).

clip_image005

 

Le premier Web service est dédié à l’administration de Service Provider Foundation. Un contexte de sécurité spécifique a été mis en place pour cela avec le compte WAP\FT-SPF-SVC.

clip_image006

 

Second Web service va s’interfacer avec Windows Azure Pack sous la forme d’un Resource Provider. On a donc une identité distincte avec le compte WAP\FT-SPF-Provider.

clip_image007

 

Le Service Provider Foundation devant communiquer avec SCVMM, il mettra en place un Web Service chargé de la communication avec ce dernier. C’est un contexte de sécurité distinct : WAP\FT-SPF-VMM.

clip_image008

 

Pour la collecte des usages du service IaaS. Service Provider Foundation doit mettre en place son endpoint pour exposer les usages. Ce sera encore un contexte de sécurité distincte : WAP\FT-SPF-USAGE.

clip_image009

 

Y a plus qu’à installer le tout.

clip_image010

 

Si tout se passe bien, on en arrive là.

clip_image011

 

Dans la console IIS, on trouve un site web dédié à Service Provider Foundation sur lequel on a lié notre certificat.

clip_image012

 

C’est ce site Web qui porte les quatre Web Services suivants :

 

Pour valider notre installation on peut valider que les deux premiers répondent bien en testant les URL localement. Pour le Web Service d’administration, c’est : https://localhost:8090/SC2012/Admin/microsoft.management.odata.svc/

clip_image013

 

On commence à comprendre ce que Service Provider Foundation va offrir à Windows Azure Pack. Pour tester le Web Service en relation avec SCVMM, c’est l’URL suivante : https://localhost:8090/SC2012/VMM/microsoft.management.odata.svc/

clip_image014

 

A voir le contenu, on comprend aussi qu’on va causer exclusivement d’objets en relation avec System Center Virtual machine Manager. Si l’envie vous en prend de tester avec la véritable URL, il faudra utiliser le compte de service correspondant.

 

Notre C3PO est en place, prochaine étape, mettre tous les interlocuteurs autour d’une table de discussion pour cause IaaS.

 

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

Benoit

Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Les derniers articles par Benoit (tout voir)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.