Question de configuration globale de haute disponibilité

Je possède et exploite visualwebsiteoptimizer.com /. L'application fournit un extrait de code que mes clients insèrent dans leurs sites Web pour suivre certaines mesures. Étant donné que l'extrait de code est du JavaScript externe (en haut du code du site), avant d'afficher un site Web client, le navigateur d'un visiteur contacte notre serveur d'applications. En cas de panne de notre serveur d'applications, le navigateur continuera à essayer d'établir la connexion avant son expiration (généralement 60 secondes). Comme vous pouvez l'imaginer, nous ne pouvons pas nous permettre d'arrêter notre serveur d'applications dans tous les scénarios, car cela affectera négativement l'expérience non seulement des visiteurs de notre site Web, mais aussi des visiteurs du site Web de nos clients!

Nous utilisons actuellement le mécanisme de basculement DNS avec un serveur de sauvegarde situé dans un centre de données différent (en fait un continent différent). Autrement dit, nous surveillons notre serveur d'applications à partir de 3 emplacements distincts et dès qu'il est détecté en panne, nous modifions un enregistrement pour pointer vers l'IP du serveur de sauvegarde. Cela fonctionne bien pour la plupart des navigateurs (car notre TTL est de 2 minutes), mais IE met en cache le DNS pendant 30 minutes, ce qui pourrait être un tueur de deal. Voir ce récent post de notre visualwebsiteoptimizer.com/split-testing-blog/maximum-theoretical-downtime-for-a-website-30-minutes/

Alors, quel type de configuration pouvons-nous utiliser pour garantir un basculement presque instantané en cas de panne majeure du centre de données de l'application? J'ai lu ici www.tenereillo.com/GSLBPageOfShame.htm qu'avoir plusieurs enregistrements A est une solution mais nous ne pouvons pas encore nous permettre la synchronisation de session. Une autre stratégie que nous explorons est d'avoir deux enregistrements A, l'un pointant vers le serveur d'applications et le second vers un proxy inverse (situé dans un autre centre de données) qui se résout en serveur d'applications principal s'il est en marche et en serveur de sauvegarde s'il est en marche. Pensez-vous que cette stratégie est raisonnable?

Juste pour être sûr de nos priorités, nous pouvons nous permettre de garder notre propre site Web ou application, mais nous ne pouvons pas laisser le site Web des clients ralentir en raison de notre temps d'arrêt. Donc, si nos serveurs d'applications sont en panne, nous n'avons pas l'intention de répondre avec la réponse d'application par défaut. Même une réponse vide suffira, nous avons juste besoin que le navigateur complète cette connexion HTTP (et rien d'autre).

Référence: j'ai lu ce fil qui était utile serverfault.com/questions/69870/multiple-data-centers-and-http-traffic-dns-round-robin-is-the-only-way-to-assure

Votre situation est assez similaire à la nôtre. Nous voulons des centres de données divisés et un basculement de type couche réseau.

Si vous avez le budget pour le faire, alors ce que vous voulez, c'est deux centres de données, plusieurs transits IP vers chacun, une paire de routeurs de périphérie faisant des sessions BGP à vos fournisseurs de transit, annonçant vos adresses IP sur Internet mondial.

C'est le seul moyen d'effectuer un véritable basculement. Lorsque les routeurs remarquent que la route vers vos serveurs n'est plus valide (ce que vous pouvez faire de plusieurs façons), ils arrêtent de publier cette route et le trafic va vers l'autre site.

Le problème est que, pour une paire de routeurs de périphérie, vous envisagez un coût assez élevé au départ pour obtenir cette configuration.
Ensuite, vous devez configurer la mise en réseau derrière tout cela, et vous voudrez peut-être envisager une sorte de connectivité Layer2 entre vos sites comme un lien point à point afin que vous puissiez acheminer le trafic entrant vers un centre de données, directement à l'autre en cas de panne partielle de votre site principal.

BGP Multihomed / Multi-location best practice and Best way to improve resilience? sont des questions que j'ai posées sur des problèmes similaires.

La page GSLB de la honte soulève quelques points importants, c'est pourquoi, personnellement, je ne choisirais jamais volontiers un GSLB pour faire le travail de routage BGP.

Vous devez également examiner les autres points de défaillance de votre réseau. Assurez-vous que tous les serveurs ont 2 cartes réseau (connectées à 2 commutateurs distincts), 2 blocs d'alimentation et que votre service est composé de plusieurs serveurs principaux, sous forme de paires redondantes ou de clusters à charge équilibrée.

Fondamentalement, "l'équilibrage de charge" DNS via plusieurs enregistrements A est simplement un "partage de charge" car le serveur DNS n'a aucune idée de la quantité de charge sur chaque serveur. C'est bon marché (gratuit).

Un service GSLB a une certaine idée de la charge des serveurs et de leur disponibilité, et offre une plus grande résistance aux pannes, mais est toujours en proie à des problèmes liés à la mise en cache DNS et au rattachement. C'est moins cher, mais légèrement meilleur.

Un réseau routé BGP, soutenu par une infrastructure solide, est à mon humble avis, le seul moyen de vraiment garantir une bonne disponibilité. Vous pourriez économiser de l'argent en utilisant des serveurs de routage au lieu de routeurs Cisco / Juniper / etc, mais à la fin de la journée, vous devez gérer ces serveurs très soigneusement. Ce n'est en aucun cas une option bon marché, ou quelque chose à entreprendre à la légère, mais c'est une solution très enrichissante, et vous amène sur Internet en tant que fournisseur, plutôt que simplement en tant que consommateur.

OK, cela a été demandé il y a quelque temps, mais je le vois pour la première fois maintenant.

l'extrait de code est du JavaScript externe (en haut du code du site), avant d'afficher un site Web client, le navigateur d'un visiteur contacte notre serveur d'applications.

Vous devriez:

1. Placez votre fichier Javascript sur un bon réseau de diffusion de contenu professionnel, c'est-à-dire achetez une portion HTTP (S) hautement disponible du Javascript auprès de quelqu'un qui a déjà cette expertise.
2. Programmez votre Javascript pour qu'il y ait un bon état de secours, c'est-à-dire que si votre serveur d'application ne répond pas rapidement, l'utilisateur final voit une page normale et non modifiée.

Faire autre chose est vraiment irresponsable. Je suppose que vous l'avez déjà en place.

Vous ne devez pas baser votre service sur des astuces de routage BGP à moins d'avoir ou d'obtenir le savoir-faire pour le faire. Les scénarios de routage BGP complexes sont décidément non triviaux à mettre en œuvre; ne faites pas cela vous-même si vous n'avez pas les connaissances spécifiques au domaine.

Votre question elle-même est un peu confuse. L'analyse de la création d'un service hautement disponible commence par les données d'application , car c'est votre "état". Les pièces sans état sont faciles à rendre hautement disponibles, les pièces à l'état plein ne le sont pas. Donc, au lieu de vous concentrer sur vos serveurs et DNS, regardez où votre application conserve son état . Commencez par vous y optimiser et demandez éventuellement des conseils sur l'algorithme sur Stack Overflow. Pourriez-vous implémenter une notion de transactions et de nouvelle tentative de serveur intelligent dans votre fichier Javascript fx?

En fait, ce que vous voulez pourrait être mis à niveau pour faciliter vos activités de test fractionné si vous combinez les basculements geodns et dns.

L'envoi du groupe A vers ip 1 et du groupe B vers ip 2, même s'ils étaient sur le même serveur, vous permettrait de séparer vos groupes de test. Le groupe A et le groupe B proviennent de différentes régions géographiques. Pour être juste, le jour / semaine / mois suivant, vous inversez les groupes pour vous assurer que vous tenez compte des différences géographiques. Juste pour être rigoureux dans votre méthodologie.

Le service geodns / failover dns sur http://edgedirector.com peut le faire

divulgation: je suis associé au lien ci-dessus, tombé ici en recherchant un article sur l'application d'astuces DNS stupides pour fractionner les tests.