Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Applications Microsoft Office SharePoint [MOSS] bascule SQL en cas de crash

[MOSS] bascule SQL en cas de crash

5 réponses
Avatar
TSC
Bonjour,

J'aimerai avoir votre avis cot=E9 environnement Sharepoint, et surtout
du cot=E9 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=E9.

Etant donn=E9 le co=FBt important d'un cluster SQL, pour le moment nous
souhaitons disposer d'un ensemble moins couteux qui pourrait =EAtre
remont=E9 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=E9alisables, et si support=E9e par MS.
On dispose d'un serveur SQL secondaire passif, copie identique quasi
temps r=E9el.

1) En cas de crash, changer la r=E9f=E9rence au niveau du SSP vers le
serveur SQL secondaire + r=E9indexation. Faisabilit=E9 ?? (je pense qu'il
faut alors refaire le SSP =3D bcp de travail et downtime =E9lev=E9)

2) copie/clone de la VM SQL. en cas de crash on remplace la VM
compl=E8te, + 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=E9 ?? support MS ?? (rapide)

4) Utilisation d'un outil tiers qui permettrait cela, type AvePoint...
(faisabilit=E9 ?)

Merci par avance pour vos conseils =E9clair=E9s !
TSC
Signaler un problème avec ce contenu

5 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Lognoul Marc [MVP]
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" wrote in message
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
Avatar
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 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
Avatar
David REI
On 23 mar, 17:39, TSC wrote:
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
Avatar
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 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
Avatar
TSC
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]" wrote:
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