Quel est le bon moment pour introduire la haute disponibilité pour le site Web?


16

Quel est le bon moment pour introduire la haute disponibilité pour le site Web?

Il existe de nombreux articles sur les options de haute disponibilité. Ce n'est pas si évident cependant QUAND est le bon moment pour passer d'un serveur unique à une configuration à haute disponibilité.

Veuillez considérer ma situation:
http://www.postjobfree.com est un site Web 24/7 avec un trafic important:
http://www.similarweb.com/website/postjobfree.com

Actuellement, je l'exécute sur un seul serveur: le serveur Web IIS 7.0 et SQL Server 2008 s'exécutent sur la même boîte matérielle.

Il y a occasionnellement (~ un par mois) ~ 5 minutes d'indisponibilité généralement provoquées par le redémarrage requis par certaines mises à jour de Windows Server. Habituellement, les temps d'arrêt sont prévus et se produisent la nuit. C'est toujours désagréable, car Google Bot et certains utilisateurs sont toujours actifs la nuit.

Les revenus actuels du site Web sont d'environ 8 000 $ / mois.

J'envisage de passer à la configuration à deux serveurs (batterie de serveurs Web de 2 serveurs Web et cluster de 2 serveurs SQL hébergés sur deux serveurs matériels).

Avantages:
1) Haute disponibilité (théoriquement aucun temps d'arrêt). Même si l'un des serveurs tombe en panne - un autre serveur prendrait le relais.
2) Aucune perte de données: sans cluster SQL, jusqu'à un jour de données peut être perdu en cas de panne matérielle (nous effectuons une sauvegarde quotidienne).

Inconvénients:
1) Plus d'efforts pour installer et maintenir une telle configuration.
2) Coût d'hébergement plus élevé. Au lieu de ~ 600 $ / mois, ce serait environ 1 200 $ / mois.

Quelle serait votre recommandation?


La réponse à ma question pourrait affecter le développement. Par exemple, je peux envisager de diviser la base de données en plusieurs parties et de conserver les données qui nécessitent une grande fiabilité (entrée utilisateur) séparément des données qui nécessitent de hautes performances (calculs).

2
Salut Dennis, ce n'est pas vraiment une recommandation, donc je l'ai collé en tant que commentaire, mais vos coûts d'hébergement semblent assez élevés pour un seul serveur Windows? Je suppose que c'est un serveur entièrement dédié (pas une machine virtuelle), mais même alors, vous devriez peut-être regarder la moitié de ce coût pour un serveur de spécifications décent avec 8 Go de RAM, une bonne quantité d'espace disque, etc. Cela pourrait valoir la peine de parler avec votre hébergeur pour obtenir un meilleur prix.
Ewan Leith

6
Je pense que la Haute Disponibilité devrait être planifiée dès le premier moment de la conception du projet.
Tom O'Connor

Ewan, je veux que mon site Web fonctionne rapidement, j'ai donc un processeur Quad avec 8 Go de mémoire et un lecteur SDD. Facteur de coût des licences logicielles (Windows, SQL Server), SSL et support technique. Avez-vous une bonne solution à bas prix pour cela? J'utilise actuellement Server Intellect (soutenu par SoftLayer) pour l'hébergement. Recommanderiez-vous quelque chose de mieux?
Dennis Gorelik

2
La mise à jour Windows vient avec des mises à jour de sécurité. Si je ne corrige pas mon serveur, il pourrait être vulnérable aux attaques. Quelle fréquence de mise à jour recommanderiez-vous pour le serveur de production Windows?
Dennis Gorelik

Réponses:


15

Réponse courte: lorsque le temps d'arrêt ou son risque vous coûte plus cher qu'il ne vous en coûterait d'avoir une haute disponibilité.

C'est fondamentalement une décision économique. Par exemple. 8 000 $ / mois implique qu'une interruption de 2 heures vous coûtera 22 $. Si vous pouvez configurer votre système de sorte que vous puissiez passer de zéro à un site entièrement fonctionnel en 2 heures, la haute disponibilité ne vous rapportera que 22 $ de fonctionnalités au-delà.

Autrement dit, vous pouvez économiser de l'argent à moins que / jusqu'à ce que vous ayez 54 heures d'arrêt non évitables dans un mois donné.


16
Vous devez également tenir compte du risque pour la réputation
gbn

7
Le coût par heure d'indisponibilité dépendra certainement du moment où le serveur tombe en panne. Il est très peu probable que les transactions soient réparties uniformément sur une période de 24 heures. Il est plus normal de se produire pendant seulement quelques heures de pointe, moment auquel la perte serait beaucoup plus importante.
John Gardeniers

Slartibartfast, je comprends votre réponse de cette façon: assurez-vous que le temps de récupération après une panne catastrophique est raisonnable (quelques heures), la perte de données est raisonnable (quelques heures), et permettez-moi d'avoir des temps d'arrêt planifiés de temps en temps (au moins pour l'instant) . Cela signifierait avoir des sauvegardes quotidiennes, des sauvegardes partielles incrémentielles et un serveur disponible pour restaurer toute cette configuration. Est-ce que ça sonne bien?
Dennis Gorelik

Réponses: gbn: D'accord; J'allais pour une explication simple, mais la réputation pourrait facilement être un facteur important. John Gardeniers: Bien sûr, mais si le site n'est utilisé que le dimanche entre 11 h et 13 h, le temps d'arrêt prévu n'est pas vraiment un problème, tandis que le prix de 2 000 $ pour une interruption imprévue de 2 heures à droite l' est. À ce stade, vous devez déterminer la probabilité de cette interruption prématurée (au coût de 2 000 $) par rapport à certains frais de 600 $ / mois pour le serveur addnl. Astuce: à moins que des échecs aléatoires pendant la période critique se produisent plus souvent que 4 / an, cela n'en vaut pas la peine.
Slartibartfast le

Dennis Gorelik: Décidez des risques contre lesquels vous souhaitez vous protéger (par exemple, perte d'activité pendant la maintenance, perte de serveur, perte de centre de données, compte / sécurité / culasse de base de données) et agissez pour vous protéger contre eux. Dans ce cas, vous vous protégez contre les temps d'arrêt dus à la maintenance et aux pannes imprévisibles (pour autant que je sache). Ce que vous décrivez devrait faire l'affaire, mais gardez à l'esprit que vous n'avez pas besoin de posséder le serveur tant que vous pouvez être sûr que vous pouvez vous l'approvisionner et le configurer pendant la période de restauration.
Slartibartfast


2

Je pense que la plupart des utilisateurs peuvent gérer un peu de temps d'arrêt planifié. Considérez que ebay a des mises à jour hebdomadaires le vendredi soir, et les enchères ne fonctionnent parfois pas. Les services bancaires en ligne de ma banque (la plus grande australienne) prévoient des interruptions pendant des heures chaque semaine. Twitter se déconnecte tout le temps. Heroku / EC2 était en panne depuis quelques jours récemment.

Je garderais cela dans cette perspective, si vous ne parlez vraiment que 5 minutes par mois, vous faites du bon travail en tant qu'administrateur système.


1

Vous avez déjà mentionné Google comme un facteur d'indexation, mais il peut également être utile de considérer l'impact que la latence / réactivité du site peut avoir sur le référencement. C'est une boîte noire et tout cela, si difficile à quantifier - bien que pour ce que ça vaut, Matt Cutts estime que c'est un pour cent . Je serais plus préoccupé par la réputation, comme d'autres l'ont dit.


1

Gardez à l'esprit que HA, comme la sécurité, n'est pas un produit, mais plutôt un processus.

Par exemple, la réplication de la base de données ne vous amènera qu'au point où chaque miroir de la base de données pourra continuer seul, mais vous aurez également besoin d'une stratégie de resynchronisation après le remplacement des composants défaillants.

Prenons l'exemple d'un système de commande: le client soumet une commande et, pendant le traitement, le système physique auquel il parlait tombe en panne après avoir stocké les informations de commande dans sa copie locale de la base de données. Impatient, le client appuie à nouveau sur «soumettre» et est dirigé vers un autre serveur, qui accepte la commande. Si vos bases de données se resynchronisent en rejouant simplement les instructions INSERT manquantes de l'autre côté, la commande sera dupliquée, ce qui peut ne pas être ce que vous voulez.

Comme l'a suggéré @Slartibartfast, tout se résume à une décision économique, mais je vous recommande également de planifier quelques années à l'avenir ici. Si vous vous attendez à avoir besoin d'une configuration HA appropriée, alors ce serait le bon moment pour réserver des ressources pour le travail préparatoire.


1

Pendant que vous y réfléchissez, je pense que vous envisagez de créer une page "échec des baleines".

Il existe de nombreuses façons de le faire, mais le combo aws de route53 et s3 fonctionne bien sur mes petits sites.

J'ai configuré le domaine avec des vérifications de santé afin qu'en cas d'échec, DNS envoie les utilisateurs aux utilisateurs vers une page html statique assise en s3; Coûts presque rien.

D'après mon expérience, le fait que votre site dise «les choses sont désolées mais nous y travaillons» fait toute la différence pour les utilisateurs. Un compte Twitter où vous pouvez même communiquer avec les utilisateurs est encore mieux.

Cela permet d'atténuer la «perte de réputation» qui peut être l'impact le plus significatif d'une panne.

voir: https://aws.amazon.com/blogs/aws/create-a-backup-website-using-route-53-dns-failover-and-s3-website-hosting/ pour un guide sur sa configuration.

Le basculement social de DynDns http://dyn.com/managed-dns/social-failover/ est une sorte de chose similaire.

Vous pouvez lancer le vôtre et effectuer vos contrôles de santé, puis scripter les modifications DNS, à condition que vos enregistrements DNS aient un TTL faible et que vous ayez un moyen de les manipuler par programme.


Ces contrôles d'intégrité doivent-ils être exécutés à partir du même serveur qui héberge DNS? Je ne peux pas imaginer comment effectuer une mise à jour DNS conditionnelle.
Dennis Gorelik

@DennisGorelik pas nécessairement, mais vos enregistrements DNS ont besoin d'une courte durée de vie et tout ce qui fait votre bilan de santé doit être en mesure de modifier les enregistrements rapidement. Mise à jour de la réponse avec plus d'informations sur la façon d'y parvenir.
Nath

Un TTL court pour DNS en combinaison avec une dépendance au contrôle de santé peut rendre le système global un peu moins stable (il peut changer même si le serveur principal fonctionne très bien). Cela peut en fait aggraver la situation pour les utilisateurs finaux, pas mieux.
Dennis Gorelik

Le court TTL en soi ne devrait pas être un problème avec un fournisseur DNS décent et si vous définissez une barre assez basse sur vos contrôles de santé (c'est-à-dire un basculement si aucun http 200 pendant 10 minutes), la stabilité n'est pas un problème. Alternativement, vous pouvez ignorer la partie de contrôle de santé et avoir un basculement manuel. Cela signifie une plus longue période de temps lorsque vos utilisateurs obtiennent un "délai de connexion dépassé" et d'autres erreurs laides, mais aucune chance de faux positifs.
Nath

0

Avez-vous envisagé d'utiliser quelque chose comme EC2 qui vous permettra de vous adapter de manière flexible et de nier vos inconvénients? C'est finalement une décision économique si l'utilisation de l'EC2 en vaut la peine ou non, mais c'est au moins une option à considérer.


-2

Pour éviter la perte de données, vous devez examiner les configurations Raid avant les clusters. Vous devez également configurer une IP de basculement que vous pouvez passer d'un serveur à un autre en cas de sinistre sans avoir à attendre la propagation DNS.


D'où est-ce que ça vient? qu'est-ce qui vous fait penser que l'affiche n'utilise pas déjà RAID?
Chopper3

Chopper3. Tout ce que j'ai dit, c'est que Raid résoudrait son problème de perte de données.
yqt

2
Comment? si un disque est mort, mais qu'en est-il si son contrôleur a mal
tourné
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.