Archi d'un site de haute disponibilité

Hello les zesteurs / zesteuses !

Je me demande comment un site de Haute Disponibilité dois être composé.

Pour moi je pense que c'est ça :

• Deux (voir plus) de serveur http Nginx couplé à un load balancer (qui peut être Nginx aussi)
• Un serveur de cache (Varnish par exemple)
• Deux (ou plus) noeuds de base de données master/slaves

Mais je voudrais savoir si il y a d'autre disponibilté

Merci d'avance !

Arck.

Hello,

Cette question n'a pas de réponse. Tout dépend de beaucoup plus de paramètres que n'en admet ta question :

• Quel niveau de « haute disponibilité » tu veux atteindre :
  • 24/24 7/7 ?
  • Pendant les heures de bureau seulement ?
  • Combien de temps de coupure autorisé tous les combien de temps ?
  • Est-ce qu'il est possible de prévoir des coupures pour maintenance en prévenant les utilisateurs ?
• Les contraintes de réactivité :
  • Est-ce qu'il y a un temps de réponse minimal en service normal ?
  • Idem, y compris quand le service est en mode dégradé (pic de charge, maintenance, …)
• Les technologies utilisées.
• La charge cible et en pointe à tenir.
• Dans quelle mesure le système doit être résistant à la disparition totale du datacenter principal ? En combien de temps doit se faire la reprise de service ?
• Quelles équipes pour gérer cette infrastructure ?
• Les contraintes budgétaires.

Quand tu as tout ça, tu peux concevoir ton architecture.

ce qui se passe souvent en vrai, c'est que les clients demandent des chiffres délirants sur tous les points sans contrainte de budget définie. Ils voient arriver le premier devis, et se rendent compte qu'en fait, ils n'ont absolument pas besoin d'une telle disponibilité.

Merci de ta réponse SpaceFox, je voulais juste savoir l'archi "type" d'un site avec un traffic élevé je pense comme zestedesavoir par exemple.

Tout dépend aussi de ce que tu définis par « trafic élevé ». De mon point de vue, Zeste de Savoir n'entre pas dans cette catégorie.

Arckazur, il n'existe pas d'architecture « type ». Et Zeste de Savoir n'a pas de trafic élevé pour moi non plus.

Mmmh, j'aurais dit que ZDS avait un fort traffic.

Donc de ce que j'ai retenue c'est en fonction des stats du site que nous allons définir l'archi.

Pour 200 connexions secondes qu'elle type d'archi il faudrait mettre en place ?

Arck.

Le serveur HTTP de Zeste de Savoir sert entre 2 et 4 ressources par seconde en pleine journée.

On ne peut pas répondre à cette question non plus sans beaucoup plus de précisions : cf la liste des points à prendre en compte dans mon premier message.

Quel niveau de « haute disponibilité » tu veux atteindre : - 24/24 7/7

Combien de temps de coupure autorisé tous les combien de temps ? : Le moins possible

Est-ce qu'il est possible de prévoir des coupures pour maintenance en prévenant les utilisateurs ? Non Voilà : Les technologies utilisées. : PHP / FPM | Nginx

En combien de temps doit se faire la reprise de service ? Je ne sais pas vraiment, moins d'une heure je dirais.

Quelles équipes pour gérer cette infrastructure ? Les OPS.

Dans quelle mesure le système doit être résistant à la disparition totale du datacenter principal ? En combien de temps doit se faire la reprise de service ? Le site doit pourvoir refonctionner dans la journée.

Les contraintes budgétaires. : On va dire aucune.

Merci. Arck

Surtout pas, à moins que le trafic n'ait pas vocation d’évoluer. Tu dois au contraire définir ton architecture en fonction de tes objectifs, et viser un maximum de souplesse.