[SharePoint 2010] Retours d’expérience SharePoint 2010 dans le Cloud Amazon EC2…
En attendant d’avoir la possibilité de déployer SharePoint et SQL Server dans Azure comme cela semble se préciser (lire l’article “Microsoft to enable Linux on its Windows Azure cloud in 2012” sur le blog de Mary-Jo Foley ), je voulais vous faire part de mon retour d’expérience suite à une installation de SharePoint 2010 dans le Cloud Amazon EC2.

En français dans le texte, Amazon Elastic Compute Cloud (ou EC2) est :
un service Web qui fournit une capacité de calcul redimensionnable dans le nuage. Il est conçu pour faciliter l'accès aux ressources informatiques à l'échelle du Web, pour les développeurs.
L'interface simple du service Web d'Amazon EC2 vous permet d'obtenir et de configurer la capacité avec un minimum de friction. Elle fournit un contrôle complet de vos ressources informatiques et vous permet d'exécuter votre application sur l'environnement informatique d'Amazon qui a fait ses preuves. Amazon EC2 réduit le temps requis pour obtenir et démarrer de nouvelles instances de serveurs à quelques minutes, ce qui vous permet de rapidement dimensionner la capacité, de l'augmenter et de la diminuer, au fur et à mesure des modifications de vos besoins de calcul. Amazon EC2 change l'aspect financier de l'informatique en vous permettant de ne payer que pour la capacité que vous utilisez effectivement. Amazon EC2 fournit aux développeurs les outils pour construire des applications résilientes tout en évitant les scénarios de défaillance les plus courants.
Il fournit en résumé un accès à des machines virtuelles hébergées dans les centres de données d’Amazon.
Les types d’instance disponibles sont variés et adaptés à la plupart des besoins. Les principaux sont :
Type | CPU | Mémoire | Stockage | Plateforme |
Petites instances (défaut) | 1 unité EC2 | 1,7 Go | 160 Go perf E/S modérée | 32 bits |
Large | 4 unités EC2 2 cœurs virtuels | 7,5 Go | 850 Go perf E/S élevée | 64 bits |
Extra-large | 8 unités EC2 4 cœurs virtuels | 15 Go de mémoire | 1 690 Go perf E/S élevée | 64 bits
|
Mais il en existe d’autres plus “gonflées” en CPU (jusqu’à 20 unités EC2) ou en mémoire (jusqu’à 68,4 Go de mémoire) pour des besoins spécifiques (HPC par exemple).
Pour une installation SharePoint de type “tout en un” avec le serveur de bases de données, la partie services d’application et frontal web dans la même machine virtuelle, une instance de type large convient tout à fait. Cependant nous n’utiliserons pas l’option “standalone” de l’installeur car nous souhaitons nous appuyer sur une base de SQL Server déjà installée dans la VM.
Les tarifs sont accessibles ici : http://aws.amazon.com/fr/ec2/pricing/
Le tableau de bord de l’état des services est accessible ici : http://status.aws.amazon.com/
Il existe un nombre très important de machines virtuelles préconfigurées utilisables sur EC2. Elles sont publiées ici sur AMI (Amazon Machine Images). Il y en a à ce jour 1077 !

On trouve notamment 101 modèles de machines reposants sur Windows.
Pour notre installation SharePoint “tout en un” , nous sommes partis de la base suivante : Microsoft Windows Server 2008 R2 with SQL Server Standard 2008 R2

Ensuite, nous avons dû faire quelques ajustements sur la configuration SQL Server :
A ce stade le principal problème rencontré vient d’une caractéristique par défaut des VMs hébergées dans le Cloud Amazon : elles changent de noms à chaque redémarrage ! 
La solution à ce problème une fois qu’il est identifié est de cocher la bonne case dans l’interface d’administration comme cela est décrit ici : Setting a permanent Windows Hostname on EC2
Ensuite les problèmes rencontrés sont d’un ordre différent et liés au choix fait de déployer SharePoint dans un environnement hors domaine (attention il s’agit d’une configuration non supportée…). Les utilisateurs sont donc locaux, de type “workgroup” :

Dans ce cas de figure, l’assistant de configuration plante sur la création de la base de configuration de la ferme :

Il est cependant possible de contourner ce problème en procédant à la création via PowerShell :

1: if(-not(Get-PSSnapin "Microsoft.SharePoint.PowerShell" `
2: -ErrorAction SilentlyContinue |
3: Where {$_.Name -eq "Microsoft.SharePoint.PowerShell"}))
4: {
5: Write-Host "Chargement de la librairie SharePoint pour PowerShell"
6: Add-PSSnapin Microsoft.SharePoint.PowerShell
7: }
8:
9: ###
10: ### Create a new farm
11: ###
12:
13: New-SPConfigurationDatabase `
14: -DatabaseName SP2010_ConfigDB `
15: -DatabaseServer IP-XXX `
16: -Passphrase (ConvertTo-SecureString "xxx" –AsPlainText -force) `
17: -FarmCredentials (Get-Credential)
Après cela, on peut relancer l’assistant de configuration pour compléter l’installation.
De même plus loin dans l’installation, les comptes de services locaux ne peuvent être enregistrés dans l’interface graphique. Cela donne l’erreur suivante :

Là encore PowerShell nous permet de contourner cette difficulté en forçant l’enregistrement :

ou :
1: add-pssnapin Microsoft.SharePoint.PowerShell
2:
3: $ServiceAccount1 = Get-Credential IP-XXX\SPAppPool
4: New-SPManagedAccount -Credential $ServiceAccount1
5:
6: $ServiceAccount2 = Get-Credential IP-XXX\SPServices
7: New-SPManagedAccount -Credential $ServiceAccount2
Pour l’installation complète avec des comptes locaux, je vous recommande :
Voilà qui nous permet d’avoir un SharePoint opérationnel à couts minimum dans le Cloud.
Evidemment un accès en mode https:// est alors fortement souhaitable, nous y reviendrons dans un prochain billet !
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :