100% de disponibilité pour une application Web
Nous avons reçu une "exigence" intéressante d'un client aujourd'hui.
Ils veulent une disponibilité de 100% 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 réseautage, 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 par des personnes internes et externes. Ils veulent que nous conservions une copie hors site du système qui, en cas de panne grave dans leurs locaux, serait immédiatement récupérée et prise en charge.
Maintenant, nous savons qu'il n'y a absolument aucun moyen de le résoudre pour les personnes internes (pigeon voyageur?), Mais ils veulent que les utilisateurs externes ne le remarquent même pas.
Franchement, je n'ai pas la moindre idée de comment cela pourrait être possible. Il semble que s'ils perdent la connectivité Internet, nous devrons faire un changement 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 tenus à 100%, affirmant que l'application devrait rester active même en cas d'inondation. Cependant, cette exigence ne se déclenche que si nous l'hébergeons pour eux. Ils ont dit qu'ils géreraient l'exigence de disponibilité si l'application vit entièrement sur leurs serveurs. Vous pouvez deviner ma réponse.
Voici Wikipedia tableau pratique de la poursuite des neuf:
Fait intéressant, seuls des 20 meilleurs sites Web ont pu atteindre les mythiques 5 neuf ou 99,999% de disponibilité en 2007. Ils étaient Yahoo, AOL et Comcast. Au cours des 4 premiers mois de 2008, certains des plus réseaux sociaux populaires , ne s'en sont même pas approchés.
D'après le tableau, il devrait être évident à quel point la poursuite de la disponibilité à 100% est ridicule ...
Demandez-leur de définir 100% et comment il sera mesuré sur quelle période de temps. Ils signifient probablement aussi près de 100% qu'ils peuvent se le permettre. Donnez-leur les coûts.
Élaborer. J'ai eu des discussions avec des clients au fil des ans avec des exigences prétendument ridicules. Dans tous les cas, ils utilisaient simplement un langage assez précis.
Très souvent, ils encadrent les choses d'une manière qui semble absolue - comme 100%, mais en réalité, sur une enquête plus approfondie, ils sont suffisamment raisonnables pour effectuer les analyses coûts/avantages qui sont nécessaires lorsqu'ils sont présentés avec les coûts pour atténuer les données d'atténuation des risques. Leur demander comment ils mesureront la disponibilité est une question cruciale. S'ils ne le savent pas, vous êtes en mesure de leur suggérer que cela doit être défini en premier.
Je demanderais au client de définir ce qui se passerait en termes d'impact/coûts commerciaux 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 bon niveau 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 exigences. Par exemple, ils peuvent vouloir payer certains niveaux de SLA et compromettre d'autres fonctionnalités pour y parvenir.
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 sommes d'argent presque infinies à jeter sur leur infrastructure et pourtant ils parviennent toujours à avoir des temps d'arrêt. Vous devez leur transmettre ce message, et s'ils continuent d'insister pour qu'ils proposent des demandes raisonnables. S'ils ne reconnaissent pas que certains le nombre de temps d'arrêt est inévitable, alors abandonnez-les.
Cela dit, vous semblez avoir la mécanique de 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 allocation ASN et IP, et se familiariser avec BGP et un équipement de routage réel afin que l'espace d'adressage IP puisse se déplacer entre les FAI si nécessaire.
C'est, bien évidemment, une réponse très laconique. Vous n'avez pas d'expérience avec les applications nécessitant ce degré de disponibilité, vous devez donc vraiment impliquer un professionnel si vous voulez vous rapprocher du mythique 100% de disponibilité.
Eh bien, c'est certainement intéressant. Je ne suis pas sûr de vouloir m'obliger contractuellement à 100% de disponibilité, mais si je le devais, je pense que cela ressemblerait à quelque chose comme ceci:
Commencez avec l'IP publique sur un équilibreur de charge complètement hors du réseau et créez au moins deux d'entre eux afin que l'un puisse basculer vers l'autre. Un programme comme Heatbeart peut vous aider avec le basculement automatique de ceux-ci.
Le vernis est principalement connu comme une solution de mise en cache, mais il fait é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'équilibre soit au hasard, soit en round-robin. Le vernis peut être rendu suffisamment intelligent pour vérifier la santé de chaque back-end et laisser tomber les backs malsains de la boucle jusqu'à ce qu'il revienne en ligne. Les backends n'ont pas besoin d'ê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 faire tourner manuellement (à Dieu ne plaise) 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 c'est un problème, vous voudrez peut-être regarder quelque chose comme Nginx à la place.
Vous pouvez avoir la plupart de vos backends dans le réseau de vos clients et un ou plusieurs en dehors de leur réseau. Je crois, mais je ne suis pas sûr à 100%, que vous pouvez hiérarchiser les backends afin que les machines de vos clients reçoivent la priorité jusqu'à ce qu'elles deviennent toutes malsaines.
C'est là que je commencerais si j'avais cette tâche et sans aucun doute l'affiner au fur et à mesure.
Cependant, comme l'indique @ErikA, c'est Internet et il y aura toujours des parties du réseau qui échappent à votre contrôle. Vous voudrez vous assurer que votre avocat ne vous lie qu'avec des choses qui sont sous votre contrôle.
Pas de problème - formulation du contrat légèrement révisée cependant:
... garantissent une disponibilité de 100% (arrondie à zéro décimale).
Si Facebook et Amazon ne peuvent pas le faire, vous ne pouvez pas. C'est aussi simple que ça.
Pour ajouter 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 ils ne sont pas orientés vers les mathématiques, donc demander une probabilité de 100% semble raisonnable. L'ingénieur, comme les ingénieurs ont tendance à le faire, se souvenait de son premier jour de prob & stat 101, sans considérer que le client ne le pouvait pas. Quand ils disent cela, ils ne pensent pas à l'hiver nucléaire, ils pensent à Fred jetant son café sur le serveur de bureau, à un crash de disque ou à une panne de FAI. De plus, vous pouvez accomplir cela. Avec des serveurs géographiquement distincts, indépendants et autosurveillés, vous n'aurez pratiquement aucun temps d'arrêt. Avec 3 serveurs fonctionnant avec une fiabilité 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 êtes toujours dans un délai raisonnable SLA pour les connexions Web, et donc le temps d'arrêt n'existe pratiquement pas. Le client doit toujours faire face aux scénarios apocalyptiques, mais Godzilla exclu , il aura un service qui est "toujours" en place.
(1) Un serveur à LA est raisonnablement indépendant du serveur de Boston, mais oui, je comprends qu'il y a une intersection impliquant une guerre nucléaire, des pirates chinois écrasant 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 où le client doit réessayer une demande une fois par an, ce qui est, encore une fois, dans un SLA raisonnable, et n'est généralement pas considéré dans la même veine que le "temps d'arrêt". Avec une application qui redirige automatiquement vers un nœud disponible en cas d'échec, cela peut être imperceptible.
On vous demande quelque chose d'impossible.
Passez en revue les autres réponses ici, asseyez-vous avec votre client et expliquez POURQUOI c'est impossible, et évaluez sa réponse.
S'ils insistent toujours sur une disponibilité à 100%, informez-les poliment que cela ne peut pas être fait et refusez le contrat. Vous ne répondrez jamais à leur demande, et si le contrat n'est pas totalement nul, vous serez embrouillé avec des pénalités.
Prix en conséquence, puis stipuler dans le contrat que tout temps d'arrêt après le SLA sera remboursé au taux qu'ils paient.
Le FAI de mon dernier emploi a fait ça. Nous avions le choix entre une ligne DSL "régulière" à 99,9% de disponibilité pour 40 $/mois, ou un trio de T1 liés à 99,99% de disponibilité pour 1100 $/mois. Il y avait des pannes fréquentes de plus de 10 heures par mois, ce qui a amené leur temps de disponibilité bien en dessous de la DSL de 40 $/mois, mais nous n'avons été remboursés qu'environ 15 $, car c'est à cela que le taux horaire * a abouti. Ils ont fait comme des bandits de l'accord.
Si vous facturez 450 000 $ par mois pour une disponibilité de 100% et que vous atteignez seulement 99,999%, vous devrez les rembourser 324 $. Je suis prêt à parier que les coûts d'infrastructure pour atteindre 99,999% sont de l'ordre de 45000 $ par mois en supposant des colos entièrement distribués, plusieurs liaisons montantes de niveau 1, du matériel de fantaisie, etc.
Il existe deux types de personnes qui demandent une disponibilité à 100%:
- Personnes n'ayant aucune connaissance des ordinateurs, des systèmes informatiques ou d'Internet. *
- Ceux qui se font intentionnellement un cul, soit pour tester votre capacité à dire non (Google "le Orange Juice Test"), soit pour essayer d'obtenir une sorte de contrat SLA effet de levier afin de sortir de vous payer plus tard.
Mon conseil, ayant souffert de ces deux types de clients à plusieurs reprises, est de ne pas prendre ce client. Laissez-les rendre fou quelqu'un d'autre.
* Cette même personne pourrait ne pas être gênée de se renseigner sur les voyages plus rapides que la lumière, le mouvement perpétuel, la fusion froide, etc.
Si les professionnels se demandent si ne disponibilité de 99,999% [est] toujours une possibilité pratique ou financièrement viable , alors une disponibilité de 99,9999% est encore moins possible ou pratique. Encore moins à 100%.
Vous n'atteindrez pas l'objectif de disponibilité à 100% 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 responsable. Le rejet peut aller de la réputation endommagée (vous avez promis, vous n'avez pas livré) à la faillite d'amendes contractuelles.
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 différence entre 99% de disponibilité et 100% de disponibilité. Pour la plupart des gens (c'est-à-dire pas les administrateurs de serveur), ces deux nombres sont les mêmes.
100% de disponibilité?
Voici ce dont vous avez besoin:
Plusieurs serveurs DNS (et redondants), pointant vers plusieurs sites partout dans le monde, avec des SLA appropriés avec chaque FAI.
Assurez-vous que les serveurs DNS sont correctement configurés, avec TTL reconnu efficacement.
C'est facile. Amazon EC2 SLA indique clairement:
Le "pourcentage de disponibilité annuel" est calculé en soustrayant de 100% le pourcentage de périodes de 5 minutes au cours de l'année de service pendant laquelle Amazon EC2 était dans l'état de "région non disponible".
http://aws.Amazon.com/ec2-sla/
Définissez simplement le "temps de disponibilité" comme étant relatif à l'ensemble complet de services, vous pouvez en fait rester opérationnel à 100% du temps, et vous ne devriez avoir aucun problème.
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 si le client demande 3 neuf ou 5 neuf ou un million de neuf - la question est de savoir ce qu'ils obtiennent quand/si vous ne pouvez pas livrer. La réponse évidente est de fournir un élément de ligne pour une disponibilité de 100% à 5 fois le prix que vous souhaitez facturer, puis ils obtenez un remboursement 4x si vous manquez cet objectif. Vous pourriez marquer!
Tu sais que c'est impossible.
Il ne fait aucun doute que le client se concentre sur "100%", donc le mieux que vous puissiez faire est de promettre 100%, sauf [toutes les causes raisonnables qui ne sont pas de votre faute].
Les modifications DNS ne prennent du temps que si elles sont configurées pour prendre du temps. Vous pouvez définir le TTL sur un enregistrement à une seconde - votre seul problème serait de vous assurer de fournir une réponse rapide aux requêtes DNS et que les serveurs DNS puissent faire face à ce niveau de requêtes .
C'est exactement comment GTM fonctionne dans F5 Big IP - le DNS TTL par défaut est défini sur 30 secondes et si un membre du cluster doit prendre le relais, le DNS est mis à jour et la nouvelle IP est prise en charge presque immédiatement. Maximum de 30 secondes d'interruption, mais c'est le cas Edge, la moyenne serait de 15 secondes.
Honnêtement, 100% est complètement fou sans au moins une hésitation en termes d'attaque de piratage. Votre meilleur pari est de faire ce que Google et Amazon font en ce que vous avez une solution d'hébergement géo-distribuée où vous avez votre site et votre base de données répliqués sur plusieurs serveurs dans plusieurs emplacements géographiques. Cela le garantira dans tout sauf un désastre majeur tel que la dorsale Internet coupée 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 de dorsale Internet, attaque terroriste apocalyptique ou grande guerre, etc.).
À part cela, examinez les services cloud Amazon S3 ou Rackspace. Essentiellement, la configuration du cloud offrira non seulement la redondance dans chaque emplacement, mais également l'évolutivité et la géo-distribution du trafic ainsi que la possibilité de rediriger autour des zones géographiques défaillantes. Bien que je sache, la géo-distribution coûte plus cher.
Bien que je doute que 100% soit possible, vous voudrez peut-être considérer Azure (ou quelque chose avec un SLA similaire) comme une 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 s'occupe de la redirection afin que le client ne voit aucun temps d'arrêt (bien que je ne sois pas sûr de la façon dont l'état de vos sessions serait affecté).
Cela dit, même avec ce basculement, la différence entre 99,999 et 100 frise la folie.
Vous devrez avoir un contrôle total sur les facteurs suivants.
- Facteurs humains, internes et externes, à la fois malveillance et impuissance. Un exemple de cela est que quelqu'un pousse 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 cesse de fonctionner ou oublie de payer ses factures d'électricité, ou décide simplement d'arrêter de prendre en charge votre infrastructure sans avertissement suffisant?
- La nature. Que se passe-t-il si des tornades indépendantes frappent simultanément suffisamment de centres de données pour dépasser la capacité de sauvegarde?
- Un environnement totalement exempt de bogues. Êtes-vous sûr il n'y a pas de cas Edge avec un contrôle de système tiers ou principal qui ne se soit pas manifesté mais pourrait encore le faire à l'avenir?
- Même si vous avez un contrôle total sur les facteurs ci-dessus, êtes-vous sûr que le logiciel/la personne qui surveille cela ne vous présentera pas de faux négatifs lors de la vérification si votre système est en marche?
Alors que certaines personnes ont noté ici que 100% est fo ou impossible, ils ont en quelque sorte raté le vrai point. Ils ont fait valoir que la raison en est le fait que même les meilleures entreprises/services ne peuvent pas 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, les détruisant tous. Agréablement, c'est une probabilité ridiculement petite, mais ce n'est pas 0. Tous les fournisseurs d'accès Internet pourraient faire face à une attaque terroriste/cyber simultanée. Encore une fois, pas très probable, mais pas nul non plus. Quoi que vous fournissiez, vous pouvez obtenir un scénario de probabilité non nul qui réduit l'ensemble du service. Parce que cela, votre disponibilité ne peut pas non plus être de 100%.
Repensez votre méthodologie de mesure de la disponibilité, puis travaillez avec votre client pour définir cibles significatives.
Si vous utilisez un grand site Web, la disponibilité n'est pas du tout utile. Si vous supprimez des requêtes pendant 10 minutes lorsque vos clients en ont le plus besoin (pic de trafic), cela pourrait être plus dommageable pour l'entreprise qu'une interruption d'une heure à 3 heures du matin un dimanche.
Parfois, les grandes sociétés Web mesurent la disponibilité ou la fiabilité à l'aide des mesures suivantes:
- pourcentage de requêtes qui ont répondu avec succès, sans erreur côté serveur (HTTP 500s).
- pourcentage de requêtes auxquelles une réponse est inférieure à une certaine cible latence.
- les requêtes abandonnées devraient compter contre vos statistiques (voir ci-dessous).
La disponibilité doit pas être mesurée à l'aide d'échantillons de sondes, ce que sont en mesure de signaler une entité externe telle que pingdom et pingability. Ne vous fiez pas uniquement à cela. Si vous voulez le faire correctement, chaque requête doit compter. Mesurez votre disponibilité en examinant 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 devrait également être pris en compte dans vos statistiques. Elle peut être comptabilisée 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 comme DNS ou les équilibreurs de charge, vous pouvez utiliser des calculs simples pour estimer le nombre de requêtes que vous avez perdues . Si vous vous attendiez à X requêtes pour ce jour de la semaine mais que vous avez obtenu 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 supprimé les requêtes. Utilisez géométrie de base pour mesurer l'aire de ces espaces, ce qui vous donne le nombre total de requêtes abandonnées.
Discutez de cette méthodologie avec votre client et expliquez ses avantages. Définissez un ligne de base en mesurant leur disponibilité actuelle. Il leur apparaîtra clairement que 100% est une cible impossible.
Ensuite, vous pouvez signer un contrat basé sur des améliorations sur la base de référence. Disons que s'ils connaissent actuellement 95% de disponibilité, vous pourriez promettre d'améliorer la situation décuplé en atteignant 98,5%.
Remarque: cette méthode de mesure de la disponibilité présente des inconvénients. Tout d'abord, la collecte des journaux, le traitement et la génération des rapports vous-même peuvent ne pas être triviaux, sauf si vous utilisez les outils existants pour le faire. Deuxièmement, bogues d'application peut nuire à votre disponibilité. Si l'application est de mauvaise qualité, elle générera plus d'erreurs. La solution est de ne considérer que les 500 créés par l'équilibreur de charge au lieu de 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 mesure de la disponibilité de votre serveur .
Je voulais juste ajouter une autre voix à la soirée "ça peut (théoriquement) se faire".
Je n'accepterais pas un contrat qui aurait spécifié cela, peu importe combien ils m'ont payé, mais en tant que problème de recherche, il a des solutions plutôt intéressantes. Je ne suis pas assez familier avec la mise en réseau pour décrire les étapes, mais j'imagine qu'une combinaison de configurations liées au réseau + de basculements de câblage électrique/matériel + de basculements de logiciels, peut-être, dans une configuration ou l'autre, pourrait réellement le faire.
Il y a presque toujours un seul point d'échec quelque part dans n'importe quelle configuration, mais si vous travaillez assez dur, vous pouvez pousser ce point d'échec pour qu'il soit réparable "en direct" (c'est-à-dire que le DNS racine descend, mais les valeurs sont toujours mises en cache partout ailleurs donc vous avez le temps de le réparer).
Encore une fois, je ne dis pas que c'est faisable ... Je n'ai tout simplement pas aimé comment aucune réponse unique n'a abordé le fait que ce n'est pas "loin d'ici" - ce n'est tout simplement pas quelque chose qu'ils veulent vraiment s'ils y réfléchissent.
Allez prendre un livre sur le contrôle de la qualité de fabrication en utilisant l'échantillonnage statistique. Une discussion générale dans ce livre, les concepts auxquels n'importe quel gestionnaire aurait été exposé dans un cours de statistique générale au collège, dicte les coûts pour passer de 1 exception sur mille, à 1 sur dix mille à 1 sur un million à 1 sur un milliard augmente de façon exponentielle. Essentiellement, la capacité d'atteindre 100% de disponibilité coûterait un montant presque illimité de fonds, 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 l'exigence comme étant non testable et déraisonnable, que cette expression soit davantage un désir qu'une véritable exigence. Avec les dépendances des applications qui existent en dehors de toute application de mise en réseau, de résolution de noms, de routage, de défauts propagés des composants architecturaux sous-jacents ou des outils de développement, il devient une impossibilité pratique de garantir à 100% la disponibilité de quiconque.
Je ne pense pas que le client demande réellement une disponibilité de 100%, ni même une disponibilité 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 supprime leur centre de données sur site.
Si l'exigence est que des personnes extérieures ne s'en rendent même pas compte, à quel point cela doit-il être drastique? Est-ce que faire une nouvelle tentative Ajax et montrer un spinner pendant 30 secondes à l'utilisateur final serait acceptable?
Voilà le genre de choses dont le client se soucie. Si le client pensait réellement à des SLA précis, il en saurait assez pour l'exprimer en 99,99 ou 99,999.
mes 2 cents. J'étais responsable d'un site Web très populaire pour une entreprise de fortune-5 qui sortirait des publicités pour le super bowl. J'ai dû faire face à d'énormes pics de trafic et la façon dont je l'ai résolu était d'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 sous forte charge ou en panne et peut acheminer le trafic en conséquence.
La chose intéressante à propos de leur service était que je n'avais vraiment rien à faire 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, je sais qu'en travaillant avec eux, ils ont beaucoup utilisé les serveurs HTTP Apache.
Bien que la disponibilité ne soit pas de 100%, vous pouvez envisager de telles options pour diffuser du contenu dans le monde entier. Si je comprenais les choses, Akamai avait également la capacité de localiser le trafic, ce qui signifie que si j'étais au Michigan, j'obtenais du contenu d'un serveur Michigan/Chicago et si j'étais en Californie, j'aurais supposément obtenu le contenu d'un serveur basé en Californie.
Au lieu d'un basculement hors site, exécutez simplement l'application à partir de deux emplacements simultanément, interne et externe. Et synchroniser les deux bases de données ... Ensuite, si l'interne tombe en panne, les personnes internes pourront toujours travailler et les personnes externes pourront toujours utiliser l'application. Lorsque l'interne revient en ligne, synchronisez les modifications. Vous pouvez avoir deux entrées DNS pour un nom de domaine ou même un routeur réseau avec round robin.
Pour les sites hébergés en externe, le plus proche de 100% de disponibilité 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 données centres en temps réel. De même, les serveurs frontaux App Engine sont automatiquement mis à l'échelle/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é App Engine SLA n'est que "99,95% du temps au cours d'un mois civil".
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 transcontinental redondant et à faible latence.
Mais gardez également à l'esprit qu'il est impossible d'avoir 100% de disponibilité et que les coûts pour passer de 99,999% à 99,9999% sont BEAUCOUP plus importants.