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
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
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
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" <nrk.kiki@gmail.com> wrote in message
news:48b9c422-8335-4524-a86d-a155c3ccd879@b16g2000yqb.googlegroups.com...
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) __________
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
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
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
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
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
On 23 mar, 17:39, TSC <nrk.k...@gmail.com> 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
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]
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
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) __________
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
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
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]" <logno...@hotmail.com> 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) __________
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) __________