3 votes

Comment fonctionne la haute disponibilité ?

Je ne comprends pas comment mettre en place une bascule pour mon scénario assez simple. Je construis une passerelle de services pour API. Ce que je veux, c'est avoir deux serveurs hébergés dans des centres de données différents. Et je veux simplement que l'utilisateur puisse accéder au service même si l'un des serveurs est hors service. Il n'y a pas de problème de synchronisation de la base de données, je me soucie uniquement de la disponibilité du service.

Comment faire cela tout en empêchant l'utilisateur de mettre en œuvre tout type de logique de bascule de leur côté? Je veux que l'utilisateur se voie attribuer un seul domaine ou une seule adresse IP et puisse accéder au service tout le temps en utilisant ce seul point d'entrée.

Ce que je ne comprends pas, c'est comment cela peut être réalisé. Je sais que je peux configurer un nœud réseau qui redirigera les demandes vers le premier ou le deuxième serveur, en fonction de celui qui est actuellement en ligne. Cependant, je ne vois pas comment cette configuration résout le problème de disponibilité car nous venons d'introduire un point de défaillance unique dans le système - le nœud de redirection. Donc, si ce nœud tombe en panne, le service est indisponible.

Pourriez-vous expliquer comment mettre en œuvre cela dans le monde réel? Est-il possible d'obtenir cela à un coût raisonnable (c'est-à-dire pas plus cher que le coût d'hébergement des serveurs eux-mêmes).

Édition: Il a été suggéré que l'exigence de centres de données différents est coûteuse. Alors, n'hésitez pas à fournir des suggestions pour 2 serveurs au sein d'un seul centre de données.

Édition 2: N'hésitez pas à mentionner quel est un coût raisonnable pour cette configuration.

0 votes

Dans différents centres de données? Non, cela coûtera cher.

0 votes

Je pense que oui, car s'ils sont hébergés dans 1 datacenter, il est facile d'imaginer que les deux serveurs tomberont en panne en même temps. Je ne dis pas deux sociétés différentes, mais oui, deux datacenters différents me semblent raisonnables - ou est-ce une demande anormale?

0 votes

Ce n'est pas, mais cela complique encore plus la solution, car cela nécessite des mesures sophistiquées et coûteuses. En même temps, vous n'avez actuellement aucun type de haute disponibilité. Commencez par une solution simple, pour sauvegarder vos propres échecs de service. Vous passerez à la sauvegarde des pannes du centre de données à l'étape suivante, au cas où vous en auriez toujours besoin.

7voto

Ondra Sniper Flidr Points 2563

Cela fonctionne très simplement. La première règle est que vous devez avoir quelque chose de plus d'une fois. Pour simplifier, je le mettrai en place dans un centre de données avec des adresses IP appartenant à ce centre de données (vous pouvez le faire avec vos propres adresses IP et plusieurs centres de données, mais nous parlons de certaines choses AS multihoming, BGP et d'autres choses qui ne sont pas si bon marché et faciles à mettre en œuvre).

Vous aurez besoin d'au moins 4 serveurs (vous pouvez le faire avec seulement deux, mais ce n'est pas une bonne façon de faire). 2 pour l'application et 2 pour l'équilibrage de charge, chaque serveur avec plusieurs cartes réseau.

La configuration de base est la suivante:

       /---\     /------\     /----------\
       | S |-----| LB 1 |-----| SERVEUR 1 |
--NET--| W |     \------/\   /\----------/
       | I |              \_/
       | T |              / \
--NET--| C |     /------\/   \/----------\
       | H |-----| LB 2 |-----| SERVEUR 2 |
       \---/     \------/     \----------/

Vous avez deux lignes séparées vers Internet fournies par votre centre de données. Les deux lignes sont dans le même VLAN et sont connectées à un commutateur (la meilleure solution est d'avoir 2 commutateurs). Les 2 équilibreurs de charge sont connectés à ces commutateurs et partagent une adresse IP virtuelle. C'est une adresse IP qui peut passer entre ces deux machines. Vous pouvez utiliser VRRP et keepalived pour y parvenir assez bien.

Derrière ces deux équilibreurs de charge, deux serveurs en miroir sont placés. Et voici la magie:

  1. Vous allez pointer votre enregistrement DNS vers cette adresse IP virtuelle
  2. Lorsqu'une personne accédera à votre application, elle passera par un LB et arrivera à un serveur
  3. Lorsqu'un serveur tombe en panne, l'équilibreur de charge le remarquera avec quelque chose comme un contrôle de santé et désactivera ce serveur. Chaque nouvelle demande sera envoyée au serveur sain.
  4. Lorsqu'un équilibreur de charge tombe en panne, keepalived le remarquera (encore une fois via un contrôle de santé) et déplacera cette adresse IP flottante vers l'équilibreur de charge sain et personne ne le remarquera.

Vous devez savoir que la HA est une méthode coûteuse et que vous ne pouvez pas la mettre en œuvre avec un petit budget. Vous devez calculer si l'interruption de votre service n'est pas moins chère que le coût de la HA, parfois c'est le cas.

Vous devriez vous renseigner sur les mots-clés vrrp, keepalived et haproxy pour avoir des idées et des façons de penser à ce sujet.

0 votes

Merci, c'est informatif - je n'étais pas au courant du "IP virtuel flottant". C'est ce que je devrai en savoir plus.

1voto

drookie Points 7850

L'approche habituelle consiste bien sûr à utiliser deux nœuds de transfert (équilibrage) sous une forme de cluster HA. La cohérence du point de vue du monde extérieur est obtenue par diverses formes d'adresse IP partagée - VRRP, CARP (similaire à VRRP, mais en open source), etc. Ainsi, vous aurez la redondance sur les deux couches - sur la couche d'équilibrage et sur la couche de données/service.

La cohérence de la couche de données/service dépasse le cadre de cette réponse, cependant, elle est généralement assez simple. Vous utilisez un magasin de session centralisé (probablement répliqué également, comme redis ou memcached) et un ensemble répliqué de bases de données.

En général, cela est réalisable sur seulement deux serveurs physiques, chacun jouant des rôles différents à la fois : un équilibreur, un serveur de base de données, et ainsi de suite.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X