Architecture serveurs "haute dispo"

[franquis]

Bonjour à tous!

J'aimerais déployer 1 ou 2 serveurs physiques sur le(s)quel(s) serait déployé une application web (bdd et tout le tsoin tsoin), cette application nécessitant une "haute" disponibilité. (24h de panne max par exemple)

Quelles peuvent être les solutions d'architecture pour assurer la redondance des données et la disponibilité de l'appli?
- 1 serveur avec disques en RAID mais sensible à la panne franche?
- 2 serveurs master/slave gérés par VRRP/HSRP/CARP (sachant que j'ai jamais fait comme on dis)


Je compte installer un ESXi sur les machines géré par vSphere (version gratuite) et je dispose d'un budget de 5k€.

Merci pour vos conseils!

[vpourchet]

au pire soluce du pauvre, une tache cron avec un ghettovcb qui backup tes vms le soir sur la machine B et en cas de crash sur A tu as 24h pour demarrer la vm de B avec peut etre la perte d'un peu de donnees....

sinon tu prends des serveurs san stockage avec esxi embeeded et tu inclus dans ton budget un bon nas avec fonctionnalites iscsi

[franquis]

Merci pour ta réponse. Je vais réfléchir à tout ça et reviendrais surement d'içi peu pour avoir des avis d'initiés!

+

[vpourchet]

je suis initié

[franquis]

Oulala mauvaise entente et mauvaise expression
Je parlais de toi en tant qu'initié justement!

No offense!

[vpourchet]

j'avais compris

no worries

[gregory.broissard]

1/ L'idéal c'est quand meme de séparer la BD des serveurs Web
2/ En Haute dispo basique, cluster de 2 machines

3/ Solution idéale : 2 serveurs Web en répartition de charge + un cluster de base de données.

apres honnetement, la contrainte de redémarrer en 24h n'en est pas vraiment une. C'est une fausse haute disponibilité...
La haute disponibilité, c'est pas de coupure de service d'où les clusters et fermes de serveurs Web...

[vpourchet]

1/ L'idéal c'est quand meme de séparer la BD des serveurs Web

la dessus on est d'acord, surtout si c'est pour mettre une BD en DMZ ... pas top !

2/ En Haute dispo basique, cluster de 2 machines

-> deux machines par service donc deux web servers et deux serveurs pour la BD

3/ Solution idéale : 2 serveurs Web en répartition de charge + un cluster de base de données.

--> en utilisant aussi les mecanismes internes au serveur web et sgbd s'il en dispose !

apres honnetement, la contrainte de redémarrer en 24h n'en est pas vraiment une. C'est une fausse haute disponibilité...
La haute disponibilité, c'est pas de coupure de service d'où les clusters et fermes de serveurs Web...

oui c'est sur apres ca depends de l'utilisation/utilite et des moyens, si c'est pour un site perso ...

[suchiwa]

Bonjour,

1 seule ESX ? 2 serveurs physiques ? Seulement 5K€...


Donc ici, c'est simple, si l'on veut de la haute disponibilité, c'est au niveau applicatif qu'il faut agir.

Comme le dit Gregory, ce n'est plus de la haute dispo si tu redémarres sous 24h, la haute dispo c'est du 99,99 % de disponibilité soit 53 minutes d'indisponibilité par an... Plus on veut de dispo, plus on ajoute de serveur pour les noeuds de cluster et on le jumelle avec de la répartition de charge.

Pour moi il est évident de séparer tes serveurs front-end (WEB,FTP...), de tes serveurs back-end(SQL,AD,FS..). La haute dispo est à créer pour les 2 (un serveur web clusterisé qui ne parvient plus à contacter sa BDD est inutilisable...)

Ici, je verrai bien un cluster MSCS pour les serveurs web, mais demande une version entreprise de windows et un domaine, le budget et le temps n'étant plus le même. Ensuite pour la BBD un cluster natif SQL. Pas donné non plus ,demande des connecteurs sous licence.

Ensuite, as tu du SAN, NAS ou as tu les disques en local ? C'est tout aussi important que le nombre de cartes réseaux sur ton ESX/ESXi.

Vincent

[franquis]

Oula! J'avais pas vu toutes ces jolies réponses. Merci!

Concernant vos remarques sur la Haute Dispo, je suis bien conscient que ce n'est pas vraiment ce que je recherche, d'où l'utilisation des guillemets dans mon premier post!

Je précise cependant ma situation: il s'agit de déployer un outil de production assez sensible malgré le fait que cet outil soit on ne peut plus basique... Un front-end web tout bête (des tableaux de bord et des formulaires) et une BDD qui aura à tout casser 5000 entrées..
La production en question n'est pas industrialisée: une production par semaine max (d'où les 24h ^^)

Autant dire qu'au niveau des ressources, je n'ai pas besoin de grand chose.


J'ai juste besoin d'assurer une redondance des données, car si jamais la BDD est corrompue, les conséquences peuvent s'élever à plusieurs centaines de k€ pour le coup.

Il s'agit en outre d'une solution "temporaire" (d'où le faible budget), en attendant que le SI de mon entreprise propose une offre pérenne.

Mon objectif étant de définir une architecture résistante à la panne franche, sachant que je pars de zéro.

Merci en tout cas pour votre implication et pour votre aide!

PS:J'ai opté pour une solution LAMP. Je crois savoir que MySQL permet de faire du clustering non?

[gregory.broissard]

Si tu as 24h pour remonter ta base de données et peu de volume de données

une sauvegarde des données de ta base suffit amplement. Pas besoin de plus...

Le clustering construit une architecture logique de 2 serveurs mais les données reste à un seul endroit (intégrité des données oblige...)

Si tu veux tout de même répliquer tes données, alors il faut mirrorer tes disques ou ton disque de données tout simplement...

[suchiwa]

Envoyé par gregory.broissard

une sauvegarde des données de ta base suffit amplement. Pas besoin de plus...

Si tu veux tout de même répliquer tes données, alors il faut mirrorer tes disques ou ton disque de données tout simplement...

Bonjour,

Je confirme l'analyse de Gregory si le cluster n'est pas la priorité.
Un raid 0 pour le système, un raid 5 d'au moins 3 disques pour les données sql, qui me paraissent les plus sensibles.

Ensuite, un espace assez conséquent, toujours dans un raid 5, le backup de tes données, en back-end sur un serveur de fichier, au pire. Un SAN, au mieux.

Pour connaitre la taille de ton backup j'ai une formule (emprunté à Microsoft, bien sure... ):

K = (L+S)2.5
soit les (logs + data) x 2.5 = backup
admettons ceci S = 16 Go et sachant que L = S/4 donc 4 Go, alors nous avons besoin de 50 Go de backup.

Ici n'est pris en compte que la sauvegarde des données de la BDD.

N'est pas pris en compte le système (systemDB) et les données temporaire (tempDB)

Vincent