[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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Lognoul Marc [MVP]
Le #18961521
Bonjour,

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:
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

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 3948 (20090319) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com






__________ Information from ESET NOD32 Antivirus, version of virus signature database 3953 (20090321) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
TSC
Le #18963621
Bonjour,

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
David REI
Le #18968341
On 23 mar, 17:39, TSC
Bonjour,

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 suiva nt
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
Lognoul Marc [MVP]
Le #18974561
Bonjour,

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





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.

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


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
TSC
Le #18976181
Merci pour vos retours !

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).
ce que nous allons donc faire.





TSC


On 25 mar, 09:05, "Lognoul Marc [MVP]"
Bonjour,

>> Sinon, le "clonage" consiste à faire une copie "image" de la machine
>> virtuelle hébergeant le SQL, en général pendant la nuit, mais su ivant
>> 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

J'ai tendance à proscrire ce que vous appeller le "clonage" -> je ne su is
pas du tout certain que Windows et/ou SQL apprécient ce type de manipul ation
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 v otre
cas, car il combine simplicité et bonne performance pour un implément ation
de taille petite à moyenne.

> 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

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 pa s
(encore?) la haute disponibilité.
De plus, je trouve personnellement DPM peu performant avec SharePoint dan s
le cadre d'un disaster recovery. Des procédure dites "manuelles" sont a u
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 signat ure database 3953 (20090321) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


Publicité
Poster une réponse
Anonyme