When the shit hits the fan… littéralement!

Je me demandais ce que j’allais écrire dans mes premières entrées de blog. Eh bien, le destin m’a donné une merveilleuse opportunité !

« When the shit hits the fan »
Connaissez-vous cette expression anglaise?
Grosso-modo, cela décrit les conséquences fâcheuses mais passionnantes d’une information secrète devenue publique.

Mon expérience récente chez un client m’a permis de tester cela, littéralement !
Voici l’histoire : alors que je faisais une mission chez un client pour mettre en place une nouvelle plateforme SharePoint 2013, j’ai été le témoin d’une catastrophe dans la salle serveur à quelques mètres du bureau ou je travaillais.

Une canalisation d’eau usée avait cédé au-dessus de la salle serveur se trouvant, tout comme le reste du département informatique, au quasi sous-sol d’un bâtiment de 9 étages (les fenêtres donnaient sur un mur).

Résultat : les eaux usées s’étaient accumulés dans une gouttière qui fuyait comme une fontaine sur la moitié des châssis ou tournait l’infra du client. D’où l’expression « the shit has hit the fan » (des serveurs).
Panique, cri, une dizaine de personnes essayant de sauver ce qu’ils pouvaient en mettant une bâche sur les racks.
Résultat des courses : plus de peur que de mal, mais surtout une sacré odeur qui allait rester.

Ironiquement, le client avait spécifiquement demandé à ce que la nouvelle plateforme SharePoint 2013 que j’allais mettre en place, ai un plan de reprise d’activité en béton.

La conclusion de cette petite expérience : ne pas sous-estimé le Plan de Reprise d’Activité car « shit happens ».

Commençons par les bases :

Haute Disponibilité versus Plan de Reprise d’Activité

La haute disponibilité permet d’avoir un arrêt de service minimum (quelques secondes) en cas d’incident mineur, généralement sans perte de données, mais quelques fois avec un mode « dégradé » (certaines applications de service ou autres briques SharePoint inopérantes, contenu à réindexer s’il y a…etc).

Le Plan de Reprise d’Activité (Disaster Recovery) est beaucoup plus long à mettre en marche car la cause est un incident majeur du type décrit ci-dessus.

Pour une ferme SharePoint 2013, la haute disponibilité est assurée par :
Minimum 2 Serveur web frontal. Cela nécessite un répartiteur de charge matériel (préféré) ou logiciel. Celui-ci assurera la redirection des flux http/https d’un serveur web à un autre. Une requête http/https est généralement envoyée à une page spécifique sur chaque serveur, à une fréquence donnée. Ainsi si cette page est indisponible sur un serveur web, alors les flux utilisateurs sont coupés vers celui-ci. Chez un client, on avait mis en place un petit site IIS avec une seule page. Cela nous permettait d’effectuer la maintenance sur ce serveur web tout en pouvant tester les pages SharePoint mais sans la contrainte d’avoir des utilisateurs dessus.

Minimum 2 serveurs d’application. Suivant l’application de service, la haute disponibilité se fait nativement dans SharePoint lui-même, à condition que :
Le paramétrage de quel service tournant sur quel serveur soit bien effectué.
Pour le service de recherche de SharePoint 2013 (dérivé de FAST), une bonne topologie de recherche permet d’avoir des composants répliqués sur plusieurs serveurs d’application.

Minimum 2 serveurs SQL Server 2012, soit en AlwaysOn Failover Cluster Instance (nouveau nom pour Cluster SQL) ou AlwaysOn Availibility Groups (technologie dérivé des DAGs Exchange, ayant grosso-modo les mêmes fonctionnalités que le mirroring et le log shipping mais en mieux !).
Personnellement, je préfère AlwaysOn Availibility Groups car il est moins difficile à mettre en place qu’un cluster SQL. Plus de détails dans d’autres entrées à ce sujet.

Mettez chaque type de serveur (physique ou virtuel) sur un châssis différent et vous avez déjà un début de haute disponibilité sur votre ferme.

En plus des 3 niveaux décrit ci-dessus, une bonne plateforme de virtualisation permet de faire des choses merveilleuses en haute disponibilité! Je ferais une autre entrée de blog à ce sujet.

Plan de Reprise d’Activité

Imaginons que ze « Shit has hit the fan », alors vous n’êtes pas à quelques seconds près.
C’est là que l’on retrouve les bons vieux engagements de service (Service Level Agreement – SLAs) qui va dicter combien d’argent vous voulez mettre pour avoir un plan de reprise d’activité en béton, et surtout si l’infra actuelle le permet.

Avec les technologies des nouvelles baies de stockage, il existe plusieurs façons de redémarrer une plateforme SharePoint dans une autre salle serveur en un temps record. Je parlerais de ces options une autre fois. Pour l’instant, la question est quoi sauvegarder pour pouvoir restaurer et redémarrer le service à partir de… rien.

Sauvegardes

Côté SQL Server :
Plan de maintenance SQL Server (complet, différentiel, journaux de transaction) suivi d’une sauvegarde la partition (S:\ comme sauvegarde) en mode « fichier » par l’outil de sauvegarde en place.
Ou un outil de sauvegarde permettant d’utiliser les APIs SQL Server et stockant les sauvegardes effectuées directement en dehors du serveur SQL. Si cette option est utilisée, attention à vérifier que ce qui a été mis en place permet de tronquer les journaux de transaction des bases de données en mode de récupération complet.

Serveurs SharePoint et SQL :
Si les serveurs sont virtuels, alors sauvegarde en mode « image » des machines virtuelles. De nos jours, les outils de sauvegardes s’appuient sur les APIs VMware et Hyper-V (par exemple) pour effectuer un « snapshot/image » de la VM à chaud.
Si les serveurs sont physiques, alors sauvegarde en mode “bare metal” permettant de tout sauvegarder même le « system state » de Windows Server. Par exemple RSA (Recovery System Agent) de TiNa (Time Navigator). Attention, car généralement, une fois le serveur physique détruit, un nouveau matériel, plus neuf, est amené en remplacement. Cela impliqué nouveau pilote. Par expérience, ce type de restauration ne fonctionne pas. Demandez à votre expert sauvegarde pour plus de détails.
C’est pour cette raison que les serveurs physiques (SharePoint ou SQL Server) doivent toujours être redondés (haute disponibilité). A l’inverse, sur du virtuel, les fonctionnalités portées par la plateforme de virtualisation permettent de redémarrer les VMs sur un autre hyperviseur en un temps record.

Ces 2 types de sauvegardes vont permettre un RTO (Recovery Time Objectif) et un RPO (Recovery Point Objectif) assez bas, en revanche pour le RLO (Recovery Level Objectif), une sauvegarde de toute la ferme SharePoint en PowerShell est nécessaire pour permettre une granularité de restauration plus fine. Il est généralement préconisé d’effectuer ce type sauvegarde PowerShell seulement lors de changement important dans la ferme. L’utilité de ce type de sauvegarde PowerShell reste un débat auquel je ne vais pas rentré (pour l‘instant !) 🙂
Beaucoup d’outil utilise les APIs SharePoint pour effectuer ce type de sauvegarde et de restauration fine (niveau bibliothèque ou document).

En conclusion, plusieurs éléments sont à prendre en compte dans la mise en place d’une architecture SharePoint :
La haute disponibilité en cas d’incident mineur.
Le Plan de Reprise d’Activité avec ces RTO et RPO en cas de sinistre majeur.

Le choix de mettre des serveurs physiques ou non, d’utiliser la haute disponibilité côté SQL Server avec du AlwaysOn seront discutés dans d’autres entrées de blog.

Published by

Jean-François Pironneau

Jean-François Pironneau

Travaillant depuis 2003 sur les versions successives de SharePoint, je me suis spécialisé au fur et à mesure des années dans la partie infrastructure/technique.

Leave a Reply

Your email address will not be published. Required fields are marked *