Question 100% de disponibilité pour une application Web


Nous avons reçu une "exigence" intéressante d'un client aujourd'hui.

Ils veulent 100% de disponibilité avec hors site Basculement sur une application Web. Du point de vue de notre application Web, ce n'est pas un problème. Il a été conçu pour pouvoir évoluer sur plusieurs serveurs de base de données, etc.

Cependant, d'un problème de mise en réseau, je n'arrive pas à comprendre comment le faire fonctionner.

En un mot, l'application vivra sur des serveurs du réseau du client. Il est accessible à la fois par des personnes internes et externes. Ils veulent que nous conservions une copie du système hors site qui, en cas de panne grave dans leurs locaux, serait immédiatement récupérée et prise en charge.

Nous savons maintenant qu’il n’ya absolument aucun moyen de résoudre le problème pour les employés internes (pigeon voyageur?), Mais ils souhaitent que les utilisateurs externes ne le remarquent même pas.

Franchement, je n'ai pas la moindre idée de la façon dont cela pourrait être possible. Il semble que s’ils perdent la connectivité Internet, nous devons procéder à un changement de DNS pour transférer le trafic vers les machines externes ... Ce qui, bien sûr, prend du temps.

Des idées?

METTRE À JOUR

J'ai eu une discussion avec le client aujourd'hui et ils ont clarifié la question.

Ils se sont contentés du nombre de 100%, affirmant que l'application devrait rester active même en cas d'inondation. Cependant, cette exigence ne prend effet que si nous l'accueillons pour eux. Ils ont déclaré qu'ils répondraient aux exigences de disponibilité si l'application résidait entièrement sur leurs serveurs. Vous pouvez deviner ma réponse.


310
2017-09-29 00:31


origine


Ne sous-estimez pas le temps d'immobilisation énorme causé par le piratage, jetez un œil à Sony et au réseau PlayStation. vous pouvez garantir qu'ils ont eu la même idée de disponibilité de 100% et l'argent / le matériel pour le sauvegarder. expliquez clairement au client que la disponibilité de 100% est une attente irréalisable, même les techniciens de Google hésiteraient à marmonner une "disponibilité de 100%". Un conseil est d’envisager d’utiliser DNS dynamique, ils ne mettent en cache que pendant 60 secondes, cela devrait inclure les serveurs OS et DNS locaux. - Silverfire
Je voudrais personnellement COURIR de ce client aussi vite que possible. Je soupçonne que ce ne sera pas la dernière idée folle qu’ils pourraient avoir (d’un point de vue technologique). - GregD
Je voudrais pouvoir réduire votre client. - joeqwerty
Si vous obtenez une disponibilité de 100%, faites-le-moi savoir. Je vais créer une entreprise avec elle et la vendre à Google. Il est impossible de garantir à 100%. Même des entreprises telles que Microsoft, Amazon ou Google n'iront pas aussi loin, car elles savent que c'est impossible. Le meilleur que j'ai vu est 99,999% et même c'est un bout droit (5 minutes par an). Le mieux que vous puissiez faire est probablement fiable à 99,99%. - Matt
Il suffit juste d’avoir un prix exorbitant pour répondre à leur demande insensée. Cela va probablement les ramener à la raison. Soit que, ou cela les enverra chercher quelqu'un prêt à leur mentir. - Nate C-K


Réponses:


Voici WikipédiaLe graphique pratique de la poursuite du neuf:

enter image description here

Fait intéressant, seulement 3 des 20 meilleurs sites ont réussi à atteindre les mythiques 5 nines ou une disponibilité de 99,999% en 2007. Ils étaient Yahoo, AOL et Comcast. Au cours des quatre premiers mois de 2008, certains des plus réseaux sociaux populaires, ne s'est même pas approché de ça.

Le graphique indique à quel point la poursuite de la disponibilité à 100% est ridicule ...


363
2017-09-29 01:03



Pingdom également ne vérifie pas chaque seconde. En plus de cela, ceux qui ont rencontré cinq personnes sur neuf avaient probablement encore des perturbations localisées que Pingdom n'avait peut-être pas détectées, ou des problèmes rendant certains services indisponibles tout en répondant aux requêtes ping. - ceejayoz
Ce qui en soi rend douteux les cinq neuf ... - GregD
Précisément. Et ils ont des milliards de dollars avec lesquels travailler! - ceejayoz
Désolé de déranger le débat en cours, mais la question du PO était de savoir comment s'y prendre pour atteindre l'objectif de 100% de temps de disponibilité sur un plan technique non conceptuel. Je suis sûr qu'il sait que ce n'est pas toujours possible en raison d'événements naturels qui affectent le matériel. et l'environnement. Pouvons-nous l'aider avec ça? - David d C e Freitas
Pour le PO: j'ai vu des contrats de niveau de service qui garantissaient la disponibilité dans le contexte "en dehors de la maintenance normale". La maintenance normale du cours est normalement planifiée par mois pour les mises à jour, les correctifs, etc., qui surviennent généralement le jour le moins occupé du mois au cours de la période la moins occupée du mois (généralement au milieu de la nuit). Ils doivent avoir un certain type de métrique pour leurs activités commerciales. Vous pourrait offrir une meilleure disponibilité (4 neuf) pour eux seulement pendant ces moments. - GregD


Leur demander de définir 100% et comment il sera mesuré sur quelle période. Ils signifient probablement aussi près de 100% qu'ils peuvent se permettre. Donnez-leur les coûts.

Élaborer. Au fil des ans, j'ai eu des discussions avec des clients avec des exigences supposées ridicules. Dans tous les cas, ils utilisaient en fait un langage assez peu précis.

Bien souvent, ils décrivent les choses de manière apparente - 100%, mais en réalité, ils sont suffisamment raisonnables pour effectuer les analyses coûts / avantages nécessaires lorsque les coûts sont comparés aux données d'atténuation des risques. Leur demander comment ils vont mesurer la disponibilité est une question cruciale. S'ils ne le savent pas, vous êtes alors en mesure de leur suggérer de définir cela en premier.

Je demanderais au client de définir ce qui se produirait en termes d’impact / de coûts sur les affaires si le site venait à s’effondrer dans les circonstances suivantes:

  • Aux heures les plus occupées pendant x heures
  • À leurs heures les moins occupées pendant x heures

Et aussi comment ils vont mesurer cela.

De cette façon, vous pouvez travailler avec eux pour déterminer le niveau approprié de «100%». Je suppose qu'en posant ce genre de questions, ils seront en mesure de mieux déterminer les priorités de leurs autres besoins. Par exemple, ils peuvent vouloir payer certains niveaux de SLA et compromettre d'autres fonctionnalités pour y parvenir.


186
2017-09-29 09:45



D'accord. Ils peuvent simplement vouloir dire une disponibilité «très élevée» (90% supérieure?) Avec une stratégie de basculement plutôt solide. Sinon, une explication de l'échelle des coûts en jeu les persuaderait ... - Martin Dow
+1 pour ne pas sauter aux conclusions et demander simplement au client d'expliquer ce qu'il a en tête. - sleske
Je fais écho à la déclaration "ne saute pas aux conclusions" ... si le client signifie une disponibilité de 100% (moins la maintenance programmée), il peut être plus d'une exigence raisonnable. - Tim Reddy
En ce qui concerne l'impact commercial, nous connaissons et comprenons parfaitement leur activité et les coûts liés à la fermeture du site ne sont pas financiers. Un peu plus loin dans le genre des indigènes se présentant avec des fourches, des suspensions potentielles, etc.;) Imaginez 40 000 personnes en train de crier à votre porte. C'est ce qu'ils veulent éviter avec passion. - NotMe
@ChrisLively Raison de plus pour que vous compreniez mieux le risque. Le paradigme dominant en matière d’ingénierie de la sécurité est évaluation probabiliste des risques. Il existe des systèmes qui pourraient tuer (pas seulement ennuyer) des milliers de personnes et ils ont toujours une probabilité d'échec faible, espérons bien comprise, mais non nulle. - poolie


Vos clients sont fous. 100% de disponibilité est impossible peu importe combien d'argent vous dépensez dessus. Clair et simple - impossible. Regardez Google, Amazon, etc. Ils ont des quantités presque infinies d'argent à investir dans leur infrastructure et pourtant, ils parviennent toujours à avoir du temps libre. Vous devez leur transmettre ce message, et s'ils persistent à insister pour qu'ils offrent des exigences raisonnables. S'ils ne reconnaissent pas ça certains quantité de temps d'arrêt est inévitable, puis les abandonner.

Cela dit, vous semblez avoir les mécanismes de la mise à l'échelle / distribution de l'application elle-même. La partie mise en réseau devra impliquer des liaisons montantes redondantes vers différents FAI, obtenir une attribution d'ASN et d'IP, ainsi que des connaissances approfondies en matière de routage BGP et d'équipement de routage réel, de sorte que l'espace d'adresses IP puisse se déplacer entre les FAI si nécessaire.

Ceci est, bien évidemment, une réponse très laconique. Vous n'avez pas d'expérience avec des applications nécessitant une telle disponibilité, vous devez donc faire appel à un professionnel si vous souhaitez vous rapprocher de la mythique disponibilité de 100%.


141
2017-09-29 00:39



D'accord. Totalement. Fou. - jdw
ils avaient l'habitude ?? - Sirex
@Sirex Se référant à la récente expérience @CERN où il a été constaté que les neutrinos voyagent plus rapidement que la lumière. Les résultats doivent encore être confirmés par des scientifiques indépendants. - TC1
@ TC1 Je te parie 200 $ ça ne marche pas. - dpatchery
@ErikA Une demande de disponibilité de 100% indique la méconnaissance des caractéristiques techniques des systèmes. Ce n'est pas grave, car le travail du client consiste à faire tout ce qu'il fait. Votre travail consiste à concevoir des systèmes informatiques. Les clients difficiles comme celui-ci peuvent être des cauchemars, mais ils peuvent également devenir vos meilleurs clients. - duffbeer703


Eh bien, c’est vraiment intéressant. Je ne suis pas sûr de vouloir m'engager contractuellement à une disponibilité de 100%, mais si je devais le faire, je pense que cela ressemblerait à ceci:

Commencez avec l'IP publique sur un équilibreur de charge complètement hors du réseau et créez-en au moins deux afin que l'un puisse basculer sur l'autre. Un programme tel que Heatbeart peut vous aider à effectuer un basculement automatique.

Varnish est principalement connu en tant que solution de cache, mais il effectue également un équilibrage de charge très décent. Ce serait peut-être un bon choix pour gérer l’équilibrage de charge. Il peut être configuré pour avoir 1 à n backends éventuellement regroupés en directeurs qui chargeront l’équilibrage de manière aléatoire ou alternée. Le vernis peut être suffisamment intelligent pour vérifier l’état de santé de chaque serveur et supprimer les arrières malsains jusqu’à ce qu’ils reviennent en ligne. Les moteurs ne doivent pas nécessairement être sur le même réseau.

Je suis un peu amoureux des adresses IP élastiques d'Amazon EC2 ces jours-ci; par conséquent, je construirais probablement mes équilibreurs de charge dans EC2 dans différentes régions ou au moins dans différentes zones de disponibilité dans la même région. Cela vous donnerait la possibilité de lancer manuellement un nouvel équilibreur de charge, si vous le deviez, et de déplacer l'adresse IP d'enregistrement A existante vers la nouvelle boîte.

Varnish ne peut pas mettre fin à SSL, cependant, si cela vous pose problème, vous voudrez peut-être regarder quelque chose comme Nginx.

Vous pouvez avoir la plupart de vos serveurs dans votre réseau de clients et un ou plusieurs en dehors de leur réseau. Je crois, mais je ne suis pas tout à fait sûr, que vous pouvez hiérarchiser les backends de manière à ce que les ordinateurs de vos clients soient prioritaires jusqu'à ce que tous deviennent malsains.

C’est là que je commencerais si j’avais cette tâche et que je l’affinerais sans aucun doute au fur et à mesure.

Toutefois, comme @ErikA l'indique, il s'agit d'Internet et il y aura toujours des parties du réseau qui échappent à votre contrôle. Vous voudrez vous assurer que vos obligations légales vous lient uniquement à des éléments sous votre contrôle.


54
2017-09-29 00:47



Pendant un moment, je pensais à Amazon et à MS pour un déploiement dans le cloud, mais ils ont tous deux connu des pannes majeures au cours des deux derniers mois. SSL est critique. - NotMe
Si vous deviez utiliser Amazon, vous voudriez certainement répartir vos machines autour des 5 zones de disponibilité. Il est peu probable que toutes leurs zones disparaissent en même temps. - jdw
+1 pour répondre à la question principale du PO. - Phil
vous aurez toujours un point d’échec, jdw, tant qu’il ya un élément non distribué dans la chaîne (dans votre cas, si vous avez plusieurs instances de cette exécution sur des machines distantes, toutes surveillées serveurs, qu’ils peuvent voir ou non en raison d’un problème de réseau le long du routage). Ce qui nous amène à "temps d'arrêt". Les serveurs peuvent être opérationnels et toujours indisponibles pour le client sans que Heartbeat ne le détecte jamais si l'incident ne se produit pas dans le chemin de routage. - jwenting
D'accord. Comme tout le monde l'a souligné, il n'y a pas de temps de disponibilité 100%. Tout ce que vous pouvez faire, c'est essayer. Ce que j'ai décrit est la façon dont je commencerais à essayer. - jdw


Pas de problème - révision légèrement rédigée du libellé du contrat:

... garantit une disponibilité de 100% (arrondi à zéro décimale).


29
2017-09-29 10:13



+1 pour noter que 100% n'est pas 100,0% ou 100 000% etc. Les chiffres décimaux sont importants, ils indiquent la précision;) - Danubian Sailor
Selon certaines conventions, "100%" a un seul chiffre significatif, de sorte que tous les nombres compris entre un demi et un arrondiraient à "100%"; 50% arrondiraient à 100%. - Thomas Levine
Selon la norme de calcul, certains diront que 50% a deux chiffres énormes, où 100% en a trois. 50,5 et 100 sont donc tout aussi précis. D'autres compteront les chiffres après le point décimal. Ensuite, 50,5 et 100,4 seront aussi précis. Si rien d'autre n'est dit, je supposerais que 100% est égal à 99,5% et plus. 100,0% est 99,95% et plus etc. - Tillebeck


Ajouter la réponse d'oconnore de Hacker News

Je ne comprends pas quel est le problème. Le client veut que vous planifiiez en cas de catastrophe et ne sont pas orientés vers les mathématiques. Demander une probabilité de 100% semble raisonnable. L’ingénieur, comme les ingénieurs sont enclins à le faire, s’est souvenu de son premier jour de prob & stat 101, sans considérer que le client pouvait ne pas le faire. Quand ils disent cela, ils ne pensent pas à l'hiver nucléaire, ils pensent à Fred de jeter son café sur le serveur de son bureau, un disque qui tombe en panne ou un fournisseur de services Internet qui tombe en panne. En outre, vous pouvez accomplir cela. Avec des serveurs à surveillance automatique indépendants et géographiquement distincts, vous n’avez pratiquement aucun temps mort. Avec 3 serveurs fonctionnant de manière indépendante (1) trois 9, avec de bons modes de basculement, votre temps d'indisponibilité prévu est inférieur à une seconde par an (2). Même si cela se produit en même temps, vous êtes toujours dans un SLA raisonnable pour les connexions Web et par conséquent, le temps d'indisponibilité n'existe pratiquement pas. Le client doit encore faire face à des scénarios catastrophiques, mais à l'exception de Godzilla, il disposera d'un service "toujours" actif.

(1) Un serveur à Los Angeles est raisonnablement indépendant du serveur à Boston, mais oui, je comprends qu'il existe une intersection impliquant une guerre nucléaire, des pirates chinois qui plantent sur le réseau électrique, etc. Je ne pense pas que votre client sera contrarié par ce.

(2) Le basculement DNS peut ajouter quelques secondes. Vous êtes toujours dans un scénario dans lequel le client doit réessayer une demande une fois par an, ce qui correspond à nouveau à un accord de niveau de service raisonnable et n'est généralement pas considéré dans la même veine que le "temps mort". Avec une application qui redirige automatiquement vers un nœud disponible en cas d'échec, cela peut être imperceptible.


25
2017-09-30 15:49



Le problème est qu'ils le disent dans les contrats. Ce qui signifie que si une catastrophe Est-ce que survient et vous avez besoin de plus de dix secondes pour remettre le site en ligne via des sauvegardes qu’ils auraient le droit de poursuivre. - Shadur
@Shadur: S'ils vraiment le veux, alors vous devez vraiment les charger. Répartissez les serveurs géographiquement au loin, espérons qu'il n'y aura pas de catastrophe partout. - Jungle Hunter
J'ai vu un site qui offrait une garantie de disponibilité de 100% ou un remboursement. Le truc était qu'ils chargeaient un chargement de bateau et se séparaient en mois. Donc, certains mois ne sont pas payés et vous planifiez tout autour de cela, et vous couvrez la perte avec les mois qui vous conviennent. - jldugger


Si Facebook et Amazon ne peuvent pas le faire, alors vous ne pouvez pas. C'est aussi simple que ça.


25
2017-09-29 01:10



il pourrait être plus intelligent que tous leurs gens réunis, qui sait: p - Matt
Une disponibilité de 100% ne doit pas nécessairement être aussi littérale - cela signifie: 100% disponible pendant le temps nécessaire. Par exemple, les systèmes bancaires devraient toujours être disponibles et ils se débrouillent très bien. Ce n’est pas parce qu’ils passent au moins une fois par an à des fins de maintenance que leur objectif de 100% de disponibilité est atteint. - David d C e Freitas
@ DavidFreitas - Je pense que dans les contrats, c'est généralement assez littéral ... - UpTheCreek
@Matt, simplement parce que Facebook / Amazon ne peut pas le faire, ne signifie pas qu'un site plus petit ne peut pas le faire. Un grand nombre de grands sites Web font face à des problèmes beaucoup plus difficiles à résoudre qu'un site plus petit. - Xorlev
vous dites donc que votre temps de disponibilité n'était pas de 100%, car certains clients avaient des erreurs. De plus, DNS n'est pas un commutateur instantané, car vous avez des FAI qui ignorent les TTL courts. - Mike


On vous demande quelque chose d'impossible.

Passez en revue les autres réponses ici, asseyez-vous avec votre client et expliquez-lui POURQUOI c'est impossible, et mesurez leur réponse.

S'ils insistent toujours pour une disponibilité de 100%, informez-les poliment que cela ne peut pas être fait et refusez le contrat. Vous ne rencontrerez jamais leur demande et si le contrat n'est pas totalement nul, vous vous retrouverez avec des pénalités.


17
2017-09-29 03:41



Il faut définir à 100%, c’est-à-dire à 100% disponible sauf pour effectuer des travaux d’entretien ou de mise à niveau, et ce temps sera limité à des heures calmes pendant quelques heures par mois au plus. Tout ça dépend sur le but et l'utilisation de l'application Web dans ce cas ... - David d C e Freitas
et définir "temps d'arrêt". Même en théorie, je ne peux pas garantir qu'ils pourront accéder à un serveur situé à Omaha à partir de leurs bureaux situés à Fairbanks, à moins que vous ne contrôliez l'ensemble du réseau entre eux (bien que vous puissiez donner des assurances quant à la disponibilité du serveur). - jwenting
Les définitions sont, à mon humble avis, sans importance s’ils demandent «une disponibilité de 100%»: même si vous négociez une maintenance programmée et que vous intégrez une redondance N + N si un problème mineur provoque un redémarrage non prévu ou un clignotement du service, vous avez endommagé votre contrat de niveau de service. ABSOLUMENT pertinent si vous négociez un contrat de niveau de service de 3, 4 ou 5 neuf ans. - voretaq7
Cela dépend des termes du SLA, n'est-ce pas? Si vous êtes payé 100 000 USD par mois et que chaque minute d'indisponibilité entraîne une pénalité de 1 000 USD, cela pourrait être tout à fait faisable (si vous avez d'autres contrats pour amortir le coût des administrateurs système sur site 24 heures sur 24, 7 jours sur 7). - Michael Borgwardt
@MichaelBorgwardt, il existe certainement des moyens de "faire en sorte que cela fonctionne" d'un point de vue purement numérique, mais je baisserais quand même à cause du risque de mauvaises relations publiques ($ _CLIENT va sur Twitter et dit au monde 'nous sommes en bas parce que $ _PROVIDER est incompétent et ne peuvent pas rencontrer leur SLA! '). Personnellement, je préférerais que 10 clients plus petits et plus raisonnables me paient 10 000 $ par mois :-) - voretaq7


Prix ​​en conséquence, puis stipuler dans le contrat que tout temps d'arrêt passé après le contrat SLA sera remboursé au taux qu'ils paient.

C'est ce que le FAI à mon dernier emploi a fait. Nous avions le choix entre une ligne DSL "normale" à 99,9% de disponibilité pour 40 $ / mois, ou un trio de T1 sous douane à 99,99% de disponibilité pour 1100 $ / mois. Il y avait de fréquentes interruptions de service de plus de 10 heures par mois, ce qui réduisait leur temps de disponibilité bien en deçà de la connexion DSL à 40 $ / mois. Nous n’avons toutefois été remboursés qu’à environ 15 $, car c’est le taux horaire * final. Ils ont fait comme des bandits de la transaction.

Si vous facturez 450 000 USD par mois pour une disponibilité de 100% et que vous atteignez seulement 99,999%, vous devrez leur rembourser 324 USD. Je suis prêt à parier que les coûts d'infrastructure pour atteindre 99,999% se situent autour de 45 000 $ par mois en supposant des colos entièrement distribués, des liaisons montantes multiples de niveau 1, du matériel fantopants, etc.


13
2017-09-29 19:01



Si vous voyez quelqu'un promettre une disponibilité de 100%, c'est exactement ce qu'il fait. Il y a une différence entre promettre une disponibilité de 100% et le livrer. Ce serait une bonne idée d'expliquer cela au client s'il tente de vous citer le contrat de niveau de service d'un concurrent. - sjbotha