100% de disponibilité pour une application Web


312

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

Ils veulent une disponibilité de 100% avec le basculement hors site 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, à cause d'un problème de réseau, je n'arrive pas à comprendre comment le faire fonctionner.

En bref, l'application vivra sur des serveurs au sein 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 ce 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?

MISE À 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 n'entre en jeu 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.


49
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 la sauvegarder. indiquer 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 60 secondes, cela devrait inclure les serveurs OS et DNS locaux.
Silverfire

182
Personnellement, je courrais à partir 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

137
Je voudrais pouvoir réduire votre client.
joeqwerty

81
Si vous pensez que votre temps de disponibilité est 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

39
Il suffit juste d’obtenir un prix exorbitant pour 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 CK

Réponses:


368

Voici Wikipedia tableau pratique de la recherche de nines:

entrez la description de l'image ici

Il est intéressant de noter que seuls 3 des 20 sites Web les plus performants ont réussi à atteindre la période mythique des 5 neuf, soit 99,999%, en 2007: Yahoo, AOL et Comcast. Au cours des quatre premiers mois de 2008, certains des réseaux sociaux les plus populaires ne se sont même pas approchés de cela.

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


62
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

8
Ce qui en soi rend les cinq-neuf douteux ...
GregD

5
Précisément. Et ils ont des milliards de dollars avec lesquels travailler!
ceejayoz

43
Désolé de déranger le débat, 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, mais je suis sûr qu'il sait que ce n'est pas toujours possible en raison d'événements naturels qui surviennent dans le matériel. et l'environnement. Pouvons-nous l'aider avec ça?
David d C e Freitas

5
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 des périodes les moins occupées 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 pouvez offrir une meilleure disponibilité (4 neuf) pour eux uniquement pendant ces périodes.
GregD

186

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 d'une manière qui semble absolue - 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 pour l’entreprise si le site tombait en panne 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.


21
D'accord. Ils peuvent simplement vouloir dire une disponibilité «très élevée» (90% supérieure?) Avec une stratégie de basculement assez solide. Dans le cas contraire, une explication de l'échelle des coûts en jeu les persuaderait ...
Martin Dow

32
+1 pour ne pas sauter aux conclusions et demander simplement au client d'expliquer ce qu'il a en tête.
Sleske

4
Je fais écho à la déclaration "ne pas sauter aux conclusions" ... si le client signifie une disponibilité de 100% (moins la maintenance prévue), il peut s'agir d'une exigence plus raisonnable.
Tim Reddy

1
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

7
@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 l'é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 le

140

Vos clients sont fous. Une disponibilité de 100% est impossible, peu importe le montant que vous dépensez dessus. Clair et simple - impossible. Regardez Google, Amazon, etc. Ils ont des quantités d'argent presque infinies à 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. Si elles ne reconnaissent pas que certains temps d'arrêt est inévitable, alors fossé « em.

Cela dit, vous semblez avoir les mécanismes de la mise à l'échelle / distribution de l'application elle-même. La partie réseau devra impliquer des liaisons montantes redondantes vers différents FAI, obtenir une attribution d'ASN et d'IP, et se familiariser avec BGP et un véritable équipement de routage afin que l'espace d'adressage 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%.


7
D'accord. Totalement. Fou.
Jdw

2
ils avaient l'habitude ??
Sirex le

2
@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

9
@ TC1 Je te parie 200 $ qui ne se vendent pas.
Dpatchery

4
@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

54

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 aider au basculement automatique de ceux-ci.

Varnish est principalement connu comme solution de mise en cache, mais il effectue également un équilibrage de la 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 à tour de rôle. Le vernis peut être suffisamment intelligent pour vérifier l’état de santé de tous les systèmes dorsaux et éliminer 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, donc 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 (sauf à Dieu) un nouvel équilibreur de charge si vous deviez le faire 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 utiliser quelque chose comme Nginx.

Vous pourriez avoir la plupart de vos moteurs 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 qu'ils deviennent tous 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.


2
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

3
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

11
+1 pour répondre à la question principale du PO.
Phil le

vous aurez toujours un point d’échec, jdw, tant qu’il y a un élément non distribué dans la chaîne (dans votre cas, si vous avez plusieurs instances exécutées sur des ordinateurs distants, 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 fait remarquer, la disponibilité à 100% n’existe pas. Tout ce que vous pouvez faire est d'essayer, et ce que j'ai décrit est la façon dont je commencerais à essayer.
Jdw

30

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).


2
+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 le

4
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

1
Selon la norme de calcul, certains diront que 50% a deux nombres é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%, c'est 99,95% et plus, etc.
Tillebeck,

26

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


17
il pourrait être plus intelligent que tous leurs concitoyens réunis, qui sait: p
Matt, le

3
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 font l’entretien 1 seconde une fois par an que leur objectif de 100% de disponibilité est atteint.
David d C e Freitas

13
@ DavidFreitas - Je pense que dans les contrats, c'est en général assez littéral ...
UpTheCreek le

2
@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 sont confrontés à des problèmes beaucoup plus difficiles à résoudre qu'un site plus petit.
Xorlev

1
donc ce que vous dites est que vous n'avez pas eu le temps de disponibilité de 100% depuis que vous avez eu quelques clients qui avaient des erreurs .. plus de dns n'est pas un interrupteur instantané puisque vous avez les FAI qui ne tiennent pas à court TTLs
Mike

25

Pour 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 donc 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'aurez pratiquement aucun temps d'arrêt. 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 tout à la fois, vous vous trouvez 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" opérationnel.

(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 se brisent sur le réseau électrique, etc. Je ne pense pas que votre client sera contrarié par cette.

(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.


6
Le problème, c'est qu'ils le disent dans des contrats. Ce qui signifie que si une catastrophe ne se produit et vous avez besoin de plus de dix secondes pour prendre le site en ligne via des sauvegardes qu'ils avaient qualité pour agir.
Shadur

@Shadur: S'ils le veulent vraiment , alors vous devez vraiment les accuser. Répartissez les serveurs géographiquement au loin, espérons qu'il n'y aura pas de catastrophe partout.
Jungle Hunter

3
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

17

On vous demande quelque chose d'impossible.

Examinez les autres réponses ici, asseyez-vous avec votre client et expliquez-lui pourquoi c'est impossible, puis évaluez 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 serez jamais à la hauteur de leur demande et si le contrat n’est pas totalement nul, vous risquez des pénalités.


2
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 au plus par mois. Tout dépend de l'objectif et de l'utilisation de l'application Web dans ce cas ...
David d C e Freitas

1
et définir "temps d'arrêt". En théorie, je ne peux même 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 (même si vous pouvez 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. Définitivement pertinent si vous négociez un contrat de niveau de service de 3, 4 ou 5 neuf.
voretaq7

Cela dépend des termes du SLA, n'est-ce pas? Si vous êtes payé 100 000 dollars par mois et que chaque minute d'indisponibilité entraîne une pénalité de 1 000 dollars, cela pourrait être tout à fait faisable (si vous avez d'autres contrats pour amortir le coût des administrateurs système sur place 24h / 24 et 7j / 7).
Michael Borgwardt le

@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 10k $ par mois :-)
voretaq7

13

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 ramène leur temps de disponibilité bien en deçà de la connexion DSL à 40 $ / mois. Pourtant, nous ne sommes remboursés qu’à environ 15 $, car c’est le taux horaire par heure *. 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% sont d'environ 45 000 $ par mois, en supposant des colos entièrement distribués, des liaisons montantes multiples de niveau 1, du matériel fantopants, etc.


3
Si vous voyez quelqu'un promettre une disponibilité de 100%, c'est exactement ce qu'il font. 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

10

Si les professionnels se demandent si la disponibilité à 99,999% est une possibilité pratique ou financièrement viable , la disponibilité à 99,9999% est encore moins possible ou pratique. Laissez seul 100%.

Votre objectif de disponibilité à 100% ne sera pas atteint pendant une période prolongée. Vous pouvez vous en tirer pendant une semaine ou un an, mais alors quelque chose se passera et vous serez tenu pour responsable. La perte peut aller de la réputation endommagée (vous avez promis, vous n'avez pas livré) à la faillite d'amendes contractuelles.


10

Il existe deux types de personnes qui demandent une disponibilité de 100%:

  1. Personnes n'ayant aucune connaissance des ordinateurs, des systèmes informatiques ou d'Internet. *
  2. Ceux qui se préparent volontairement, soit pour tester votre capacité à dire non (Google «le test du jus d’orange»), soit pour tenter d’obtenir un avantage contractuel sur les ANS afin d’éviter de vous payer plus tard.

Mon conseil, après avoir souvent souffert de ces deux types de clients, est de ne pas prendre ce client. Laissez-les rendre quelqu'un d'autre fou.

* Cette même personne pourrait n'avoir aucune gêne à se renseigner sur les déplacements plus rapides que la lumière, le mouvement perpétuel, la fusion à froid, etc.


2
+1 pour le test du jus d'orange .. J'aime et je ne savais pas à ce sujet :)
Oliver M Grech

8

Je voudrais communiquer avec le client pour établir avec lui ce que signifie exactement 100% de disponibilité. Il est possible qu'ils ne voient pas vraiment de distinction entre une disponibilité de 99% et une disponibilité de 100%. Pour la plupart des gens (c.-à-d. Pas les administrateurs de serveur), ces deux numéros sont identiques.


6

100% de disponibilité?

Voici ce dont vous avez besoin:

Plusieurs serveurs DNS (& redondants), pointant vers plusieurs sites du monde entier, avec les SLA appropriés avec chaque fournisseur de services Internet.

Assurez-vous que les serveurs DNS sont correctement configurés et que la durée de vie est reconnue.


1
Oui, le DNS est un bon début - par exemple, nslookup google.comrenvoie 6 adresses IP différentes pour la redondance au cas où certaines ne fonctionneraient pas. Consultez également RobTex.com, un excellent site pour consulter les configurations de certains domaines, par exemple robtex.com/dns/google.com.html#records
David d C e Freitas

6

C'est facile. Le contrat de niveau de service Amazon EC2 indique clairement:

Le «pourcentage de disponibilité annuelle» est calculé en soustrayant à 100% le pourcentage de périodes de 5 minutes au cours de l'année de service dans laquelle Amazon EC2 était dans l'état «Région non disponible».

http://aws.amazon.com/ec2-sla/

Définissez simplement le «temps de disponibilité» comme étant relatif à l'ensemble des services que vous pouvez réellement garder opérationnel 100% du temps, et vous ne devriez pas avoir de problèmes.

En outre, il convient de souligner que l’intérêt d’un SLA est de définir quelles sont vos obligations et ce qui se passe si vous ne pouvez pas les respecter. Peu importe que le client demande 3 neuf ou 5 neuf ou un million de neuf; la question est de savoir ce qu'il aura quand / si vous ne pouvez pas livrer. La solution évidente est de fournir un élément de campagne offrant une disponibilité de 100% à 5 fois le prix que vous souhaitez facturer, puis un remboursement de 4x si vous manquez cette cible. Vous pourriez marquer!


5

Les modifications DNS ne prennent du temps que si elles sont configurées pour prendre du temps. Vous pouvez définir la durée de vie d'un enregistrement sur une seconde. Votre seul problème serait de vous assurer de fournir une réponse rapide aux requêtes DNS et de veiller à ce que les serveurs DNS puissent gérer ce niveau de requêtes.

C’est exactement comme cela que fonctionne GTM dans F5 Big IP: la durée de vie (TTL) du DNS est définie par défaut sur 30 secondes et si un membre du cluster doit prendre le relais, le DNS est mis à jour et la nouvelle adresse IP est utilisée presque immédiatement. Maximum de 30 secondes d'interruption, mais c'est le cas, la moyenne serait de 15 secondes.


10
D'après mon expérience, certains serveurs DNS ne prendront pas en compte une durée de vie qu'ils considèrent comme étant incroyablement basse (malgré le RFC). Tout ce qui reste moins de 5 minutes devient quelque peu peu fiable à l'échelle mondiale.
Jdw

13
Ignorer la réalité de Paul n'est pas une pratique acceptable, peu importe à quel point cela fait chier tout le monde.
MDMarra

5
Je suis avec jdw à ce sujet. J'ai vu de nombreux serveurs DNS ignorer complètement la durée de vie (TTL), même un réglage de 1 heure et un réglage par défaut d'environ 24 heures.
NotMe

6
@Paul - L'OP n'a pas le contrôle sur les résolveurs DNS de tous les FAI de la planète. Par conséquent, ils n'ont pas le choix de dire "si vous utilisez notre site Web, n'utilisez pas Comcast / Roadrunner / quel que soit votre fournisseur d'accès, car ils ignoreront nos paramètres TTL". C'est quelque chose qui est tout simplement hors de leur contrôle et est donc trop fragile pour être considéré comme une solution à ce problème à mon humble avis. La solution doit inclure un moyen de forcer les adresses IP en interne, sans recourir à d'autres bits du réseau qui pourraient ne pas être coopératifs.
Jdw

3
C'est un peu comme ne pas avoir d'onduleur parce que le pouvoir "devrait fonctionner". Ce n'est pas une façon avant-gardiste d'architecter un système. Si vous savez qu'il existe une partie fragile du système, quelle qu'en soit la raison, vous devriez essayer de vous en rendre compte.
Jdw

5

Tu sais que c'est impossible.

Il ne fait aucun doute que le client se concentre sur le «100%». Par conséquent, le mieux que vous puissiez faire est de promettre 100%, sauf pour [toutes les causes raisonnables qui ne sont pas de votre faute].


Nul doute que le client ne veut aucune solution. Ils veulent un déclin. Ils peuvent donc dire qu'ils ont au moins essayé.
MBX

Peut-être. Vous prenez pour acquis un indice élevé.
Marcin

4

Bien que je doute que 100% soit possible, vous pouvez envisager Azure (ou quelque chose avec un contrat de niveau de service similaire) comme possibilité. Ce qui se passe:

Vos serveurs sont des machines virtuelles. En cas de problème matériel sur un serveur, votre machine virtuelle est déplacée vers une nouvelle machine. L'équilibreur de charge prend en charge la redirection afin que le client ne voie aucun temps d'arrêt (bien que je ne sois pas sûr de l'impact de l'état de vos sessions).

Cela dit, même avec ce basculement, la différence entre 99,999 et 100 frôle la folie.

Vous devrez avoir le plein contrôle sur les facteurs suivants.
- Facteurs humains, internes et externes, malveillants et impuissants. Un exemple de ceci est quelqu'un poussant quelque chose dans le code de production qui fait tomber un serveur. Pire encore, qu'en est-il du sabotage?
- Les questions d'affaires. Que se passe-t-il si votre fournisseur quitte son activité ou oublie de payer ses factures d'électricité ou décide simplement de cesser de soutenir votre infrastructure sans préavis?
- La nature. Que faire si des tornades non liées frappent simultanément suffisamment de centres de données pour surcharger la capacité de sauvegarde?
- Un environnement totalement sans bug. Êtes-vous sûr qu'il n'y a pas de cas périphérique avec un contrôle de système tiers ou central qui ne se soit pas manifesté mais qui pourrait le faire à l'avenir?
- Même si vous avez le plein contrôle des facteurs ci-dessus, êtes-vous sûr que le logiciel / la personne surveillant cela ne vous présentera pas de faux négatifs lors de la vérification de l'état de votre système?


2
Azure et EC2 ont récemment eu des échecs presque complets et totaux. Je pense qu'Azure a récemment été arrêté simplement à cause d'une mauvaise entrée de configuration sur un serveur DNS. De toute façon, merci pour l'info.
NotMe

et si votre équilibreur de charge (qui effectue la commutation) tombe inaperçu (son moniteur peut également l'être inaperçu, à l'infini) lorsque le nœud tombe en panne, vous êtes toujours vissé.
Jwenting

1
Je pense que vous vouliez dire «incompétence». L'impuissance ne devrait pas avoir beaucoup d'impact sur la capacité du personnel informatique à faire son travail.
Mfinni

4

Honnêtement, 100% est complètement fou sans au moins une hésitation dans les termes d'une attaque de piratage. Votre meilleur pari est de faire ce que Google et Amazon font en ce sens que vous disposez d'une solution d'hébergement géo-distribuée dans laquelle votre site et votre base de données sont répliqués sur plusieurs serveurs situés dans plusieurs emplacements géographiques. Cela garantira tout sauf une catastrophe majeure, telle que la coupure du réseau Internet dans une région (ce qui arrive de temps en temps) ou quelque chose de presque apocalyptique.

Je mettrais une clause pour de tels cas (DDOS, coupure d'internet, attaque terroriste apocalyptique ou une grande guerre, etc.).

Autre que cela, regardez dans les services de cloud Amazon S3 ou Rackspace. Essentiellement, la configuration du nuage n'offrira pas seulement la redondance dans chaque emplacement, mais également l'évolutivité et la géo-distribution du trafic, ainsi que la possibilité de rediriger les données sur les géo-zones défaillantes. Bien que je sache, la géo-distribution coûte plus cher.


3

Je voulais juste ajouter une autre voix à la fête "ça peut (théoriquement) être fait".

Je ne prendrais pas un contrat qui spécifiait cela, peu importe combien ils me payaient, mais en tant que problème de recherche, il proposait des solutions plutôt intéressantes. Je ne suis pas assez familiarisé avec la mise en réseau pour décrire les étapes, mais j'imagine qu'une combinaison de configurations liées au réseau + défaillances de câblage électrique / matériel + défaillances de logiciels pourrait, éventuellement, dans une configuration ou une autre, fonctionner efficacement.

Il y a presque toujours un point d'échec unique dans n'importe quelle configuration, mais si vous travaillez assez dur, vous pouvez pousser ce point d'échec à être quelque chose qui peut être réparé "en direct" (c'est-à-dire que le DNS racine tombe en panne, mais les valeurs sont toujours mises en cache partout ailleurs, vous avez donc le temps de le réparer).

Encore une fois, je ne dis pas que cela est faisable. Je n’ai simplement pas aimé le fait qu’aucune réponse ne dise que ce n’est pas «une solution», ce n’est tout simplement pas ce qu’ils souhaitent réellement s’ils y réfléchissent.


3

Repensez votre méthodologie de mesure de la disponibilité, puis collaborez avec votre client pour définir des objectifs significatifs .

Si vous utilisez un site Web volumineux, la disponibilité n'est pas utile du tout. Si vous laissez tomber les requêtes pendant 10 minutes lorsque vos clients en ont le plus besoin (trafic achalandé), cela pourrait être plus dommageable pour l'entreprise qu'une interruption d'une heure à 3 heures du matin le dimanche.

Parfois, les grandes entreprises Web mesurent la disponibilité, ou la fiabilité, en utilisant les indicateurs suivants:

  1. pourcentage de requêtes auxquelles il est répondu avec succès, sans erreur côté serveur (HTTP 500).
  2. pourcentage de requêtes dont la réponse est inférieure à une certaine latence cible .
  3. les requêtes abandonnées doivent être prises en compte dans vos statistiques (voir ci-dessous).

La disponibilité ne doit pas être mesurée à l'aide d'échantillons de sondes, ce qu'une entité externe telle que pingdom et pingability peut signaler. Ne comptez pas uniquement sur cela. Si vous voulez le faire correctement, chaque requête doit compter . Mesurez votre disponibilité en regardant votre succès réel perçu.

Le moyen le plus efficace consiste à collecter des journaux ou des statistiques à partir de votre équilibreur de charge et à calculer la disponibilité en fonction des métriques ci-dessus.

Le pourcentage de requêtes abandonnées doit également être pris en compte dans vos statistiques. Il peut être comptabilisé dans le même compartiment que les erreurs côté serveur. S'il y a des problèmes avec le réseau ou avec une autre infrastructure telle que DNS ou les équilibreurs de charge, vous pouvez utiliser un calcul simple pour estimer le nombre de requêtes que vous avez perdues . Si vous attendez des requêtes X pour ce jour de la semaine mais que vous avez X-1000, vous avez probablement abandonné 1000 requêtes. Tracez votre trafic dans des graphiques de requêtes par minute (ou seconde). Si des lacunes apparaissent, vous avez abandonné des requêtes. Utilisez la géométrie de base pour mesurer la surface de ces espaces, ce qui vous donne le nombre total de requêtes supprimées.

Discutez de cette méthodologie avec votre client et expliquez-lui les avantages. Définissez une ligne de base en mesurant leur disponibilité actuelle. Il deviendra clair pour eux que 100% est une cible impossible.

Vous pouvez ensuite signer un contrat en fonction des améliorations apportées à la base de référence. Dites, si elles connaissent actuellement 95% de disponibilité, vous pouvez promettre d'améliorer la situation dix fois en obtenant à 98,5%.

Remarque: cette méthode de mesure de la disponibilité présente des inconvénients. Premièrement, la collecte de journaux, le traitement et la génération de rapports vous-même peuvent ne pas être triviaux, sauf si vous utilisez des outils existants pour le faire. Deuxièmement, les bogues d'application peuvent nuire à votre disponibilité. Si l'application est de mauvaise qualité, cela signifiera plus d'erreurs. La solution à cela est de ne considérer que les 500 créés par l'équilibreur de charge plutôt que ceux provenant de l'application.

Les choses peuvent devenir un peu compliquées de cette façon, mais c'est une étape au-delà de la simple mesure de la disponibilité de votre serveur .


3

Certaines personnes ont noté ici que 100% est fou ou impossible , mais elles ont en quelque sorte manqué le point. Ils ont fait valoir que la raison en est que même les meilleurs entreprises / services ne peuvent y parvenir.

Eh bien, c'est beaucoup plus simple que ça. C'est mathématiquement impossible .

Tout a une probabilité. Il pourrait y avoir un tremblement de terre simultané à tous les endroits où vous stockez vos serveurs, en les détruisant tous. Certes, c'est une probabilité ridiculement petite, mais ce n'est pas égal à 0. Tous vos fournisseurs d'accès Internet pourraient faire face à une attaque terroriste / cybernétique simultanée. Encore une fois, pas très probable, mais pas nul non plus. Quoi que vous fournissiez, vous pouvez obtenir un scénario avec une probabilité non nulle qui réduit tout le service. Pour cette raison, votre temps de disponibilité ne peut pas être à 100% non plus.


En fait, je passerais pour fou ou impossible et dirais que je suis stupide. Les humains ne savent rien, c'est 100%.
Quadruplebucky

2

Allez chercher un livre sur le contrôle de la qualité de fabrication en utilisant un échantillonnage statistique. Une discussion générale dans ce livre, dont les concepts auraient été exposés à n’importe quel manager dans un cours de statistique générale à l’université, dicte le coût pour passer de 1 sur un milliard augmente de façon exponentielle. Essentiellement, la capacité de fonctionner à 100% du temps de disponibilité coûterait une quantité de fonds presque illimitée, un peu comme la quantité de carburant nécessaire pour pousser un objet à la vitesse de la lumière.

Du point de vue de l’ingénierie de la performance, je rejetterais cette exigence, qui est à la fois indiscutable et déraisonnable, selon laquelle cette expression est davantage un désir qu’une exigence réelle. Avec les dépendances d'application qui existent en dehors de toute application pour la mise en réseau, la résolution de nom, le routage, les défauts propagés par des composants architecturaux sous-jacents ou des outils de développement, il devient pratiquement impossible de garantir à quiconque une garantie de disponibilité de 100%.


1

Je ne pense pas que le client demande réellement une disponibilité de 100%, voire de 99,999%. Si vous regardez ce qu'ils décrivent, ils parlent de reprendre là où ils se sont arrêtés si un météore met à jour leur centre de données sur site.

Si l'exigence est que les personnes externes ne remarquent même pas, à quel point cela doit-il être drastique? Est-il acceptable de faire une nouvelle demande Ajax et d'afficher un spinner pendant 30 secondes à l'utilisateur final?

Voilà le genre de choses qui intéressent le client. Si le client pensait réellement à des contrats de niveau de service précis, il en saurait suffisamment pour pouvoir l'exprimer sous la forme 99,99 ou 99,999.


Si le client pense qu'il veut «un temps de disponibilité de 100%» et que cela se termine dans le verbiage du contrat, vous pourriez être tenu responsable si cela aboutissait devant un tribunal. Il vaut mieux en parler et aider le client à comprendre ce qu'il veut vraiment au lieu de supposer que vous savez ce qu'il pense.
Chris S

Oh, je conviens que cela doit être clarifié avant de passer un contrat. Je dis simplement que cela doit être abordé car le client ne communique pas ce qu'il veut réellement, par opposition à ce qu'il demande quelque chose de ridicule.
Kevin Peterson

1

mes 2 cents. J'étais responsable d'un site Web très populaire pour une entreprise du groupe Fort-5 qui publierait des publicités pour le super bowl. J'ai dû faire face à des pics de trafic importants et la façon dont j'ai résolu le problème consistait à utiliser un service comme Akamai. Je ne travaille pas pour Akamai mais j'ai trouvé leur service extrêmement bon. Ils ont leur propre système DNS, plus intelligent, qui sait qu'un nœud / hôte particulier est soumis à une charge importante ou est en panne et peut acheminer le trafic en conséquence.

Ce qui est bien avec leur service, c'est que je n'ai pas vraiment besoin de faire quelque chose de très compliqué pour répliquer le contenu sur les serveurs de mon propre centre de données vers leur centre de données. De plus, en travaillant avec eux, je sais qu’ils ont beaucoup utilisé les serveurs HTTP Apache.

Bien que le temps de disponibilité ne soit pas de 100%, vous pouvez envisager de telles options pour disperser le contenu dans le monde entier. Si j'ai bien compris, Akamai avait également la capacité de localiser le trafic si je me trouvais dans le Michigan. Je recevais du contenu sur un serveur Michigan / Chicago et, si j'étais en Californie, je le recevrais soi-disant d'un serveur basé en Californie.


-1 parce que c'est une réponse pratique mais pas du tout utile. "Engagez quelqu'un d'autre à le faire" pour répondre à toutes les questions de ce site, mais ce n'est pas pour cela que nous sommes ici.
Yves Junqueira

Je ne suis pas d'accord. "Pas utile du tout?" C'était très certainement utile pour moi et contrairement à votre commentaire "engagez quelqu'un d'autre à le faire", je suppose qu'avec votre raisonnement, le gars devrait creuser son propre câble de fibre optique et concevoir ses propres commutateurs plutôt que de les acheter aussi? Es-tu sérieux, Yves? Vous ressemblez à quelqu'un qui n'a pas passé beaucoup de temps dans le domaine informatique.
Kilo

0

Au lieu d'un basculement hors site, exécutez simplement l'application à partir de deux emplacements simultanément, interne et externe. Et synchronisez les deux bases de données ... Ensuite, si l'interne tombe en panne, les employés internes pourront toujours travailler et les utilisateurs externes pourront toujours utiliser l'application. Lorsque interne revient en ligne, synchronisez les modifications. Vous pouvez avoir deux entrées DNS pour un nom de domaine ou même un routeur de réseau avec round robin.


0

Pour les sites hébergés de manière externe, la disponibilité la plus proche de 100% est l'hébergement de votre site sur App Engine de Google et l'utilisation de son magasin de données haute réplication (HRD) , qui réplique automatiquement vos données sur au moins trois centres de données en temps réel. De même, les serveurs frontaux App Engine sont automatiquement redimensionnés / répliqués pour vous.

Cependant, même avec toutes les ressources de Google et la plate-forme la plus sophistiquée au monde, la garantie de disponibilité de App Engine SLA n'est que "99,95% du temps, au cours d'un mois civil".


0

Simple et direct: Anycast

http://en.wikipedia.org/wiki/Anycast

C'est ce que cloudflare, google et toute autre grande entreprise utilisent pour effectuer un basculement / équilibrage redondant, à faible temps de latence et transcontinental.

Mais gardez aussi à l'esprit qu'il est impossible d'avoir une disponibilité de 100% et que le coût pour passer de 99,999% à 99,9999% est BEAUCOUP plus grand.

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.