Discussion :

[Arrau]

Bonjour,

J'ai actuellement un seul serveur avec un site WSS 3.0 + une base SQL Server Express. Je souhaiterais ajouter un deuxième serveur dans la ferme, avec une répartition de charge entre les deux.

Est-il possible avec 2 serveurs dans ma ferme, d'avoir une redondance du site ET de la base de données (pour que le site soit toujours accessible en cas de crash de l'un des serveurs) ?

Merci d'avance.

[nonoxp]

Salut,

Le fait d'avoir un SQL Express n'est-il pas déjà limitant à la fois en termes de licences et en termes de fonctionnalités ? Regarde bien les conditions d'utilisations de WSS et de SQL Express car je crois bien que c'est le cas.

[Arrau]

Apparemment, d'après la comparaison des fonctionnalités des différentes versions de SQL Server, l'édition Express ne permet de toute façon pas le clustering.

J'ai pensé à une architecture de la sorte:

Serveur 1:
Frontal Web
Instance de base de données

Serveur 2:
Frontal Web redondant

La base de données étant répliquée sur le serveur 2. En cas de défaillance du premier serveur, la base de données de contenu de SP serait modifiée manuellement pour passer sur l'instance SQL Server du serveur 2.

Est-ce possible?

[nonoxp]

Ok, ce serait de la copie brute de l'instance de ton archi 1 vers la 2 ? Temps réel ou asynchrone ?

[Arrau]

A vrai dire, je recherche n'importe quelle solution qui me permettrait d'avoir un même site WSS installé sur 2 serveurs et d'assurer la disponibilité en cas de défaillance de l'un d'eux...

[nonoxp]

Ce genre de système n'est à mon avis concevable que si l'on a une liste des contraintes en termes de disponibilité.

Par exemple, si tu peux te permettre une coupure de 10~20 minutes et une reprise des dernières données sur 12 ou 24h, tu peux te contenter d'un export/import, c'est facilement automatisable et à mettre en place aussi.

Si au contraire il faut une copie temps réel, avec les moyens qu'on te donne ça va être très difficile, il y aura un investissement conséquent pour mettre quelque chose en place (en temps et en outils selon ce que tu veux faire).

Dis toi que de la haute dispo avec peu de moyens est toujours difficilement compatible.

[Arrau]

Merci de ta réponse.

Étant donné que je n'ai pas de moyen pour réaliser ça, je vais partir sur une solution avec 2 serveurs WSS + BDD indépendants et un script de copie du site du serveur 1 vers le 2 déclenché à intervalles réguliers.
Les modifications n'étant effectuées que sur le 1er serveur (pour celà il faut pouvoir passer outre le load-balancing).

Quelle est la meilleure solution pour la copie? Export/Import stsadm, ou export/import de la bdd? Est-il possible simplement de ne copier que les modifications (j'en doute)?

Il s'agit d'un petit site, un import stsadm ne prend pas plus de 4 minutes.
Le seul soucis est la taille de l'image: une trentaine de Mo, non compressée.

[nonoxp]

Je ne me suis pas tenté à bouger les bdd directement. L'utilisation de stsadm est d'ailleurs à privilégier dans 99% des cas de figure. Après je sais que ça reste du domaine du faisable en tapant directement dans les bases, mais ça nécessite plus de travail (tu trouveras des exemples sur des blogs ça et là).

A toi de voir selon la prévision de l'évolution de la taille de ton site. A l'heure actuelle pour 30 ridicules Mo je ne vois aucun problème. Par contre le jour où ça dépassera le Go, attention il faudra peut-être changer ton fusil d'épaule.

La copie des modifs uniquement... cf. paragraphe précédent. Planifier les duplications automatiques n'est déjà pas si anodin sous MOSS, alors sous WSS on est vraiment à poil. L'avantage de l'import/export c'est qu'il embarque les schémas de listes, les nouveaux content types, les workflows et leur état, etc... Difficile de copier ça à la volée sans un bon outil. Ca dépend encore une fois de tes spécifications et du caractère variable de ta structure logique sur ton serveur 1.

[Arrau]

Ok merci de ton aide