J'utilise un système OLTP qui permet des connexions SSL sur Internet sur plusieurs sites. Je voudrais trouver une solution efficace pour rediriger de manière transparente et automatique les connexions de transaction lorsqu'un site est en panne. Points bonus pour considérer le site en panne quand il n'est pas réellement inaccessible ou incapable de se connecter mais juste retardé ou surchargé ou renvoyant de mauvais résultats. Par exemple, le système utilisateur se connecterait à www.abcdef.com ou 123.234.56.7 et serait redirigé vers one.abcdef.com/two.abcdef.com ou 99.5.2.1/68.96.79.1 selon le site travaille. Cela ressemble beaucoup à l'équilibrage de charge, mais c'est principalement comment utiliser le réseau pour éviter un seul point de défaillance, par opposition à la façon de répartir le travail entre les serveurs. Les avantages pour l'utilisateur sont les suivants: (1) il lui suffit de connaître une URL ou une adresse IP pour se connecter et (2) ses transactions fonctionnent dans plusieurs scénarios de défaillance différents. Par exemple, si le réseau public à proximité d'un des sites tombe en panne ou est mal acheminé, si la boucle locale de ce FAI échoue, si les routeurs ou les serveurs internes échouent. Bien sûr, les transactions échouent toujours si le problème est proche de l'utilisateur.L'Internet peut-il rediriger les demandes de connexion entre des serveurs distants lorsque l'un d'entre eux est hors service?
Répondre
Je pense que peut-être un moyen de le faire est d'avoir des serveurs frontaux redondants qui se trouvent derrière un équilibreur de charge. Ce système frontal répond simplement aux demandes en les redirigeant vers vos serveurs réels qui sont distribués dans divers endroits. Votre serveur frontal peut périodiquement vérifier si les autres serveurs sont ouverts et, dans le cas contraire, retirer ce serveur du mixage. Avoir des frontaux redondants derrière l'équilibreur de charge (ou peut-être juste dans un cluster) l'empêche de devenir un point de défaillance unique. Vous pouvez également avoir plusieurs serveurs frontaux à l'aide de la solution DNS à tour de rôle, située à divers endroits. Vous devrez probablement prendre en compte cette architecture dans votre application.
Vous souhaitez probablement également avoir des liens de réseau redondants vers tous les sites.
ifstated peut être utilisé en tant que frontal avec pf (sous OpenBSD et FreeBSD) pour rediriger le trafic vers des serveurs en ligne.
Blockquote ifstated - Interface Etat démon
Le ifstated démon exécute des commandes en réponse à des réseaux changements d'état, qu'elle détermine en surveillant l'état de liaison de l'interface ou la course exter- nal tests. Par exemple, il peut être utilisé avec carp(4) pour modifier les services ou pour s'assurer que les interfaces carp(4) restent synchronisées ou avec pf(4) pour tester la disponibilité du serveur ou de la liaison et pour modifier la traduction ou le routage des règles . Les options sont les suivantes:
Je pense que la chose qui va condamner c'est SSL. Le cert appartient à un système particulier et la redirection vers un autre système de manière transparente entraînera probablement des problèmes de certificat. Il pourrait être correct s'ils sont derrière un équilibreur de charge et l'équilibreur de charge gère SSL, mais il voulait des systèmes distribués. – tvanfosson
Bon point sur le SSL. Cependant, dans cette situation, je pense que cela peut être contourné en demandant aux clients d'accepter le certificat de toute façon (ne le validez pas). Nous ne cherchons pas l'authentification juste le cryptage pendant la transmission. – user43458
Une fois, j'ai posé une question similaire il y a des années et la réponse a beaucoup à voir avec combien d'argent vous êtes prêt à dépenser. Il existe des solutions matérielles, des périphériques dont le seul but est de s'asseoir devant vos serveurs A et B de sorte que lorsque le serveur A tombe, il cesse d'envoyer des requêtes et n'utilise que le serveur B. L'avantage de le faire dans le matériel est la performance et la fiabilité.
Il est également utile de connaître la fiabilité relative de tous les composants de votre système.Si c'est un composant qui vous inquiète alors vous pouvez rendre cette pièce redondante et concevoir le reste du système pour basculer de l'un à l'autre. La raison pour laquelle je dis cela est qu'il n'y a pas de réponse parfaite.
À moins bien sûr que vous essayez de construire quelque chose comme un système de traitement de carte de crédit ou autre système similaire de transaction financière où l'argent est sans objet: P
Le scénario le plus courant est un fail-over configuration où un rebascule Si vous recherchez le basculement parfait, vous pouvez implémenter un système entre le client et A et B qui réessayera automatiquement etc. et retourner la réponse sans que le client ne voit une seule erreur. Mais cela peut gâcher la performance et vous avez alors la question d'un autre système qui peut échouer ou non. Et maintenant nous sommes de retour à mon deuxième paragraphe .... :)
Ce n'est pas une mauvaise question, mais en savoir plus sur ce que vous essayez de faire (et si vous êtes déjà enfermé dans une implémentation particulière) aiderait.
C'est la meilleure solution pour le moment - 05/12/08 midi CT. C'est une autre description de l'idée «créer un site très bien connecté, très à l'épreuve des balles et exécuter un équilibreur de charge réseau». Mais il ne suffit pas de fixer le seul PoF pour atteindre ce site frontal. – user43458
On commence à avoir l'impression de décrire un système DNS amélioré. Mais cela ne fait que déplacer le point de défaillance dans DNS (et complique le DNS). Peut-être que c'est juste des tortues tout le long. En d'autres termes, le problème peut toujours exister quelque part, peu importe le nombre de couches utilisées. – user43458