[MOSS] bascule SQL en cas de crash
Le
TSC
Bonjour,
J'aimerai avoir votre avis coté environnement Sharepoint, et surtout
du coté serveur SQL :
Pour le moment, nous disposons d'une ferme MOSS standard avec un
frontal web (+search+index) et un SQL2005. Chacun de ces serveurs est
virtualisé.
Etant donné le coût important d'un cluster SQL, pour le moment nous
souhaitons disposer d'un ensemble moins couteux qui pourrait être
remonté rapidement en cas de crash du serveur.
- Pour le frontal, un clone de la VM suffit je pense
- Pour le SQL, je vois plusieurs solutions, mais je ne sais pas si
elles sont réalisables, et si supportée par MS.
On dispose d'un serveur SQL secondaire passif, copie identique quasi
temps réel.
1) En cas de crash, changer la référence au niveau du SSP vers le
serveur SQL secondaire + réindexation. Faisabilité ?? (je pense qu'il
faut alors refaire le SSP = bcp de travail et downtime élevé)
2) copie/clone de la VM SQL. en cas de crash on remplace la VM
complète, + reindexation (rapide, mais on perd alors les modifs faites
depuis le dernier clonage, environ 1 jour)
3) sur le frontal, utiliser un alias local pour le serveur SQL, et
modifier cet alias en cas de crash pour pointer vers le serveur
secondaire. Faisabilité ?? support MS ?? (rapide)
4) Utilisation d'un outil tiers qui permettrait cela, type AvePoint
(faisabilité ?)
Merci par avance pour vos conseils éclairés !
TSC
J'aimerai avoir votre avis coté environnement Sharepoint, et surtout
du coté serveur SQL :
Pour le moment, nous disposons d'une ferme MOSS standard avec un
frontal web (+search+index) et un SQL2005. Chacun de ces serveurs est
virtualisé.
Etant donné le coût important d'un cluster SQL, pour le moment nous
souhaitons disposer d'un ensemble moins couteux qui pourrait être
remonté rapidement en cas de crash du serveur.
- Pour le frontal, un clone de la VM suffit je pense
- Pour le SQL, je vois plusieurs solutions, mais je ne sais pas si
elles sont réalisables, et si supportée par MS.
On dispose d'un serveur SQL secondaire passif, copie identique quasi
temps réel.
1) En cas de crash, changer la référence au niveau du SSP vers le
serveur SQL secondaire + réindexation. Faisabilité ?? (je pense qu'il
faut alors refaire le SSP = bcp de travail et downtime élevé)
2) copie/clone de la VM SQL. en cas de crash on remplace la VM
complète, + reindexation (rapide, mais on perd alors les modifs faites
depuis le dernier clonage, environ 1 jour)
3) sur le frontal, utiliser un alias local pour le serveur SQL, et
modifier cet alias en cas de crash pour pointer vers le serveur
secondaire. Faisabilité ?? support MS ?? (rapide)
4) Utilisation d'un outil tiers qui permettrait cela, type AvePoint
(faisabilité ?)
Merci par avance pour vos conseils éclairés !
TSC
Pour augmenter la disponibilité de SQL tout en gardant le budget
relativement bas, il n'y a que le mirroring. Voir le très bon white paper
couvrant ce sujet http://technet.microsoft.com/en-us/library/cc262910.aspx.
En ce qui concerne les autres serveurs/services, je ne comprends pas très
bien les techniques employées, le "clonage" en particulier.
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
"TSC" news:
__________ Information from ESET NOD32 Antivirus, version of virus signature database 3953 (20090321) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
Merci Marc pour ce lien intéressant.
Ce whitepaper répond donc à la faisbilité du point 1) avec
Sinon, le "clonage" consiste à faire une copie "image" de la machine
virtuelle hébergeant le SQL, en général pendant la nuit, mais suivant
la taille de la VM (donc des bases SQL), le temps de retablissement
peu être plus élevé que dans le mirroring...
Est ce que des solutions tierces existes ?
des retours d'expérience ?
merci
TSC
Hello,
Regarde si pour le deuxième point tu ne peux pas industrialiser ce
processus de suivi avec
la gamme de produit System Center de Microsoft.
Il existe des outils de supervision, et/ou restauration intéressant.
David REI
Blog : http://blog.developpeur.org/davidrei
J'ai tendance à proscrire ce que vous appeller le "clonage" -> je ne suis
pas du tout certain que Windows et/ou SQL apprécient ce type de manipulation
régulièrement et ce, même si certains vendeurs de virtualisation y vont de
leur blabla marketing pour convaincre...
Pour augmenter la disponibilité de SQL: Clustering, mirroring ou log
shipping. Avec dans votre cas une préférence pour le mirroring dans votre
cas, car il combine simplicité et bonne performance pour un implémentation
de taille petite à moyenne.
David, je suis d'accord sur le fait que les produits de la gamme SC
permettent la détection de panne et la sauvegarder/restauration mais pas
(encore?) la haute disponibilité.
De plus, je trouve personnellement DPM peu performant avec SharePoint dans
le cadre d'un disaster recovery. Des procédure dites "manuelles" sont au
moins aussi efficaces et moins couteuses.
--
Marc [MCSE, MCTS, MVP]
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
[Blog: http://www.marc-antho-etc.net/blog/]
__________ Information from ESET NOD32 Antivirus, version of virus signature database 3953 (20090321) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
Effectivement, une solution de type mirroring est plus "propre" à
mettre en place que le "clonage".
De plus, au vu du document, c'est la solution poussée par MS (en
dehors du clustering SQL).
TSC
On 25 mar, 09:05, "Lognoul Marc [MVP]"