PRA SharePoint à base de Log Shipping


Bonjour,

Aujourd’hui, je vous propose de me suivre au travers de la configuration d’un PRA SharePoint se basant sur la technologie SQL de Log Shipping.

Pour cela, il est nécessaire de disposer de deux fermes SharePoint (une principale et une de secours).

Le but de la manipulation est de dupliquer les webapps SharePoint sur les deux fermes et de mettre à jour les bases de contenu de la ferme secondaire via le processus de Log Shipping.

Cet article reprend les concepts du technet suivant http://technet.microsoft.com/en-us/library/dd890507.aspx.

Soit l’architecture suivante :

Noter que seules les bases de contenus sont « Log Shippées » (un peu de franglais).

Nous partons du contexte suivant :

  •  Ferme 1 composée d’un frontal et d’un serveur de bases de données
  • Ferme 2 composée d’un frontal et d’un serveur de bases de données (dans mon cas un cluster SQL, cela ne change aucunement le processus)
  • Une webapp de contenu SharePoint sur la ferme 1

 Nous avons donc une base de données de contenu qui se trouve sur la ferme 1, nous allons donc commencer par la « log shippée » sur le serveur de base de données de la ferme 2

Mise en place du log shipping

Lancer SQL Management Studio et connectez-vous à vos deux serveurs SQL.

La base de contenu sur laquelle nous allons travailler est WSS_Content du serveur CHAURRAY-SQL (srv SQL de la ferme 1)

Faîtes un clic droit sur la base, puis dans la section « Tâches » cliquer sur « Envoyer les journaux de transactions.. »

Commencer par cocher la case « Activer en tant que base de données primaires dans une configuration de la copie des journaux de transactions » (Attention, il est nécessaire que la base de données soit dans un mode de récupération Complet)

Ensuite planifier l’intervalle et l’emplacement des sauvegardes.

Il est maintenant nécessaire de configurer les bases secondaires, dans notre cas une seule base.

 

Connectez-vous au serveur SQL de la ferme 2, puis indiquer le nom de la base de données à créer ou à utiliser sur ce serveur.

Sélectionner le mode de génération de cette base (nouvelle sauvegarde complète ou sauvegarde existante).

Dans l’onglet « Copier les fichiers », indiquer un répertoire partagé de serveur SQL de la ferme 2. Et planifier le Job de copie des logs (transfert des logs du serveur primaire au serveur secondaire).

Dans le dernier onglet « Restaurer le journal des transactions », sélectionner le mode Veille et cocher la case « Déconnecter les utilisateurs … »

La base secondaire sera dans un état de vieille et en lecture seule et nous allons pouvoir attacher cette base de données à une webapp de la ferme 2. L’ensemble de la webapp sera bien évidemment en lecture seule.

Cliquer sur OK pour valider la configuration de cette base de données secondaire.

Terminer la configuration en cliquant sur le bouton OK, la sauvegarde complète de la base commence, suit la restauration sur le serveur secondaire.

Vous avez une nouvelle base sur le serveur SQL de la ferme 2.

Pour résumer, le serveur primaire effectue une sauvegarde de sa base et cela créé des journaux de transaction.

Le serveur secondaire rapatrie ces journaux, puis joue les journaux sur une de ses bases afin de reconstituer cette base.

L’ensemble de ce travail est réalisé par des jobs SQL qui sont eux-mêmes lancé par les agents SQL.

Il est donc nécessaire que l’identité du service SQL Agent ait les droits sur les répertoires utilisés lors de ces jobs.

Création de la webapp de secours sur la ferme 2

Nous disposons maintenant d’une base de contenu sur notre ferme de secours qui se rafraîchit selon la planification indiquée dans l’étape précédente.

Nous allons donc utiliser cette base de contenu sur une webapp de la ferme de secours.

Commencer par créer une nouvelle webapp sur la ferme secondaire en réutilisant le même hostheader (même URL) que la webapp de la ferme 1.

Lors de la création de cette webapp, une base de données de contenu a été créée. Nous allons supprimer cette base de contenu et ajouter (attacher en terme SharePoint) la base de contenu « log shippée ».

Pour cela rendez-vous dans la gestion des bases de contenu.

La capture ci-dessus est issue de SharePoint 2010, l’interface est quasi similaire sous MOSS 2007.

Sélectionner la bonne webapp, puis cliquer sur la base de contenu existante.

Cocher la case supprimer la base de contenu puis cliquer sur le bouton OK.

Cliquer ensuite sur le lien Add a content database, nous allons donc attacher notre base log shippée.

 

Nous avons donc maintenant deux webapps accessible par la même URL (dans mon cas http://CHAURRAY-WFE) sur deux fermes distinctes avec le même contenu (seulement un delta dù à l’intervalle du log shipping).

Dans le cadre d’un PRA seule une ferme est interrogée (1 ferme active et 1 ferme passive de secours), mais pour tester la ferme de secours nous allons modifier le fichier HOSTS afin de forcer l’interrogation de la ferme secondaire.

Pour cela, ouvrez votre fichier HOSTS (C:\Windows\System32\drivers\etc\hosts) et ajouter une entrée du type 172.16.1.1 CHAURRAY-WFE    

CHAURRAY-WFE indique le hostheader renseigné pour la webapp et l’adresse IP doit être celle du serveur frontal de la ferme de secours.

Lancez votre naviguateur et essayer l’URL.

Vous accédez au même contenu mais l’ensemble de la webapp est en lecture seule. Je vous rappelle que vous interrogez la base log shippée qui est en lecture seule (ferme 2).

Attention les personnalisations effectuées sur la ferme 1 (ajout de solutions SharePoint, ajout de thèmes, etc..) doivent impérativement être rejouée sur la ferme 2.

Depuis une autre station, rendez-vous sur cette même URL le contenu est en lecture / écriture donc vous interrogez la ferme 1.

Ajouter un document dans une bibliothèque de document, dons depuis la ferme 1. Puis attendez le temps que les jobs de log shipping soit relancé. Le document apparaît sur la ferme 2.

Bacule sur la ferme de secours

Le but d’un PRA est en cas de crash complet d’une salle info de pouvoir remonter l’architecture sur un autre salle info éloignée de plusieurs kilomètres. Oui cela ne sert pas à grand chose d’avoir deux salles serveur côte à côte en cas de feux ou de catastrophe naturelle les deux salles sont inutilisables.

Donc une ferme SharePoint sur chaque site. Mettons nous dans le cas où notre site primaire est injoignable. Nous avons bien notre site de secours qui est disponible.

Faut-il encore rediriger les utilisateurs sur cette ferme de secours. Le moyen le plus simple est de modifier l’enregistrement DNS action manuelle, il est possible d’automatiser cette manipulation via des boitiers du type RADWARE où autre.

Ok nos utilisateurs accèdent donc à notre ferme de secours. 

  Petit problème le contenu est en lecture seule, il faut donc réactiver la base de données log shippée pour qu’elle soit en lecture écriture. Rappel : à cet instant le log shipping ne fonctionne plus puisque la ferme 1 est injoignable.

Le principe pour « réactiver » une base de données en vieille / lecture seule (warm standby) est de la restaurer avec la commande with recovery.

Pour nous éviter tout problème, nous allons prendre l’accès exclusif sur la base avant de la restaurer.

Les commandes sont les suivantes :

ALTER DATABASE « nom de ma base » SET SINGLE_USER WITH ROLLBACK IMMEDIATE

 RESTORE DATABASE « nom de ma base » WITH RECOVERY

 ALTER DATABASE « nom de ma base » SET MULTI_USER WITH ROLLBACK IMMEDIATE

Afin d’automatiser cette bascule je vous ai concocté un script powershell. Le jour où la ferme 1 tombe, l’état de stress vous enlèvera une partie de vos facultés intélectuelle, plus les choses seront documentées et automatisées mieux ce sera.

param (
  [string] $SQLSERVER,
  [string] $Database
)
$SqlConnection = New-Object System.Data.SqlClient.SqlConnection
$SqlConnection.ConnectionString = « Server=$SQLSERVER;Database=$DATABASE;Integrated Security=True »
$SqlCmd = New-Object System.Data.SqlClient.SqlCommand
$SqlCmd.CommandText = « USE MASTER ALTER DATABASE $DATABASE SET SINGLE_USER WITH ROLLBACK IMMEDIATE RESTORE DATABASE $DATABASE WITH RECOVERY ALTER DATABASE $DATABASE SET MULTI_USER WITH ROLLBACK IMMEDIATE »
$SqlCmd.Connection = $SqlConnection
$SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter
$SqlAdapter.SelectCommand = $SqlCmd
$DataSet = New-Object System.Data.DataSet
$SqlAdapter.Fill($DataSet)
$SqlConnection.Close()
$DataSet.Tables[0]

Copier le texte ci-dessus dans un fichier nommé basculeLogShipping.ps1

Attention il est nécessaire d’autoriser l’éxécution de script PowerShell sur le serveur SQL de secours, voici la commande :

set-ExecutionPolicy unrestricted

Vous pouvez maintenant éxécuter le script comme ceci basculeLogShipping.ps1 « CLUSTERSQL » « WSS_Content_LOGSHIPPED »

C’est la fin de cet article.

Merci d’avoir lu jusqu’au bout.

Damien => Kouilb

Publicités

4 Responses to PRA SharePoint à base de Log Shipping

  1. aurel says:

    j’adore je cherche une doc sur les PRA Sharepoint et je tombe sur toi :-),Normal bon ben ca m’a l’air pas mal comme solution ca

  2. aurel says:

    t ‘as quelques chose de mieux a me proposer que le log shipping pour du PRA ?? du Geoclustering ?

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :