[ #SharePoint 2010][ #SQLServer 2012] AlwaysOn pour SharePoint (3/5) : documentation et supportabilité…
| 3e article d’une série de 5 articles sur AlwaysOn pour SharePoint -
-
-
-
-
|
| Suite à la publication des deux premiers articles, j’ai découvert la mise en ligne de la documentation et le besoin d’apporter quelques précisions sur la supportabilité de la solution qui justifient de rajouter un article dans cette série. |
|
|
Ainsi donc vous pouvez trouver ici : Configure and manage SQL Server availability groups for SharePoint Server ou là (site FR-FR mais pas encore traduit en français) la documentation officielle pour les manipulations décrites dans les deux premiers billets de cette série.
Elle est assez aride mais assez bien faite.
Par contre elle n’aborde pas le point important de la supportabilité. Pour cela il faut aller sur la partie Référence technique et plus particulièrement Types et descriptions des bases de données (SharePoint Server 2010) pour vérifier pour chaque base de données de SharePoint le support du Database Mirroring (et donc par extension des groupes AlwaysON).
En synthèse, on retiendra :
| Bases de données (noms par défaut) | Support de de la réplication synchrone | Support de la réplication asynchrone |
| SharePoint_Config
SharePoint_AdminContent
Bdc_Service_DB_
Application_Registry_server_DB_
SubscriptionSettings_
StateService
Search_Service_Application_DB_
Search_Service_Application_CrawlStoreDB_
Search_Service_Application_PropertyStoreDB_
User Profile Service Application_ProfileDB_
User Profile Service Application_SocialDB_
WordAutomationServices_
PerformancePoint Service Application_ | Oui | Non |
| WSS_Content
Secure_Store_Service_DB_
WebAnalyticsServiceApplication_ReportingDB_
Managed Metadata Service_
DefaultPowerPivotServiceApplicationDB | Oui | Oui |
| WSS_UsageApplication | Oui mais non recommandé | Oui mais non recommandé |
| WebAnalyticsServiceApplication_StagingDB_ | Non | Oui |
| User Profile Service Application_SyncDB_
FASTSearchAdminDatabase | Non | Non |
Cela soulève le cas particulier des bases ne supportant aucune des deux méthodes de réplication.
- Ainsi une ferme utilisant FAST ne pourra pas être protégée par un mécanisme de réplication SQL Server.
- Par contre, pour la base de données de synchronisation de l’application de service de profil utilisateur ce n’est pas un gros problème, cela signifie simplement qu’en cas de bascule pendant une synchronisation, la synchronisation échouera.
- De manière similaire, pour la base de données de la zone de transit Web Analytics (WebAnalyticsServiceApplication_StagingDB_), comme elle n’est pas supportée en réplication synchrone, en cas de basculement en cours de transfert les dernières données devront être transférées à nouveau.
De plus, pour la base de données de collecte de données relatives à l’état et à l’utilisation (WSS_UsageApplication) sa mise en miroir n’est pas recommandée à cause de sa taille potentiellement importante et du nombre important d’écriture pouvant l’affecter. Cependant si l’on a l’infrastructure disques et réseau qui peut le supporter cette réplication est souhaitable car sinon des données d’utilisation seront perdues.
Nous supprimerons donc les bases suivantes du groupe de disponibilité :
- SP__Sync
- SP__WebAnalyticsStagingDB
Nous conserverons donc les bases suivantes dans notre ferme exemple configurée dans les deux précédents messages :
Enfin, on notera que de nombreuses bases (notamment la principale SharePoint_Config) ne supporte que la réplication synchrone et non l’asynchrone donc cela implique que si l’on souhaite créer un site de secours éloigné avec de la réplication asynchrone, on devra créer une deuxième ferme sur le site distant et répliquer uniquement les bases qui le supporte.
cf. Planification de la récupération d’urgence (SharePoint Server 2010)
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 :
