Web App: Haute Disponibilité / Comment empêcher un point de défaillance unique?

Quelqu'un peut m'expliquer comment la haute-disponibilité ("HA") pour une application web ... car je suppose HA signifie qu'il n'existe aucun point unique de défaillance.

Cependant, même si un équilibreur de charge est utilisé n'est pas que le point de défaillance unique?

  • Pas quand vous avez deux équilibreurs de charge mis en place pour le basculement.
  • Newton, mais comment faire 2 équilibreurs de charge de répondre à la demande unique à venir dans? Je suis en train d'imaginer, donc, nous allons je veux visiter example.com, mon navigateur résout l'adresse IP, puis envoie une requête unique à la propriété intellectuelle des example.com comment est-il possible que plusieurs serveurs (load balancers) peut "répondre" sur le web demande de venir dans mon navigateur? À un certain point, il y a un seul morceau de matériel qui est le point de défaillance?
  • Ils ne le font pas; on n'. Si l'on commence à tomber en panne, l'autre prend la relève. Il existe une variété de mécanismes pour gérer cela, tous au-delà de la portée de une DONC, la question, vraiment. Desmond déjà à peu près tout dit que.
  • Argh. Je ressens de la frustration, nickb. Il est très clair que tout changement de votre adresse IP point à un répartiteur de charge (ou un équilibreur de charge-balancer, ou un équilibreur de charge-balancer-balancer) ne permet pas d'obtenir de haute disponibilité, car alors que l'équilibrage de charge peut échouer. Pourtant, les réponses à cette question sur le net semblent être composé soit d' "il suffit d'ajouter une autre couche de l'équilibrage de la charge!" (qui, manifestement, n'aide pas) ou "C'est un sujet compliqué que vous êtes trop noob pour comprendre". @DaveNewton a réussi à fournir à la fois inutile de licenciements, de ici.
  • La tolérance de panne est bien au-delà de la portée d'une SORTE de réponse, même si elle a été sur le sujet. Néanmoins, malgré vos cris de "oh, cela n'aide pas" c'est la réponse: l'évolution des équilibreurs de charge/serveurs/infra est la solution.
  • Non, c'est vraiment évidemment pas la solution. Faire de votre IP résoudre à un seul point d'entrée de l'équilibreur de charge est tout autant d'un point de défaillance unique comme ayant résolu d'un seul serveur web, si l'équilibrage de charge a un ou 100 fois plus de couches de équilibreurs de charge derrière elle. Qu'est-ce exactement est difficile à comprendre ici? La vraie solution implique clairement autre chose que simplement de l'extension des couches de équilibreurs de charge. (Je pense qu'il implique de faire des choses intelligentes avec BGP, même si c'est en dehors de mon domaine d'expertise.)
  • C'est pourquoi je l'ai dit plusieurs équilibreurs de charge? Je ne suis pas sûr de ce qui est difficile à comprendre ici: pour éliminer les points de défaillance uniques vous de mettre en œuvre les basculements. Ils peuvent aussi échouer—le point est d'avoir de la redondance et de l'espoir les pannes peuvent être résolues. Comment pensez-vous que les grands sites de travail? De multiples points d'entrée, app serveurs, DBs. Commutable tissu de re-router les demandes, interne ou externe, lorsque des défaillances sont détectées. Je ne sais pas du tout à moyenne et à grande échelle du site qui a une seule chose. Haussement d'épaules—il été de travail pour chaque site, j'ai été impliqué avec, à partir de 10sK à 10sM.
  • "C'est pourquoi je l'ai dit plusieurs équilibreurs de charge?" - coordonnées de la façon dont, si ce n'est par un autre programme d'équilibrage de charge en face d'eux? Toute la question est de savoir quel mécanisme il est par lequel il est possible de laisser un serveur (ou d'équilibrage de charge) lorsque l'autre ne parvient pas en plus il suffit de coller un autre SPOF en face d'eux. Je n'ai aucune idée de ce que ce mécanisme est, c'est pourquoi je me suis retrouvé ici; lancer plus de couches à clairement le problème n'est pas le résoudre. C'est peut-être le "commutable tissu" vous faites allusion, bien que je ne sais pas ce "tissu" ou "sK" ou "sM" et aucun d'entre eux rendement à Googler.
  • Ceux sont des nombres d'utilisateurs. Je pense que nous parlons les uns les autres-mais il y a beaucoup de ressources que vous pourriez analyse pour comprendre les bases de l'HA de l'infrastructure.
  • D'accord avec vous, c'est pourquoi je suis en train de lire tous jusqu'à la fin de la conversation

InformationsquelleAutor nickb | 2011-10-30