Équilibrage de charge Apache sur un budget?

J'essaie de me familiariser avec le concept d'équilibrage de charge pour garantir la disponibilité et la redondance afin de satisfaire les utilisateurs en cas de problème, plutôt que d'équilibrer la charge dans le but d'offrir une vitesse fulgurante à des millions d'utilisateurs.

Nous sommes sur un budget et essayons de nous en tenir aux choses où il y a beaucoup de connaissances disponibles, donc exécuter Apache sur Ubuntu VPS semble être la stratégie jusqu'à ce qu'un moteur de recherche célèbre nous acquière ( ironie du samedi incluse, veuillez noter ).

Au moins pour moi, c'est une jungle complète de différentes solutions disponibles. Apaches possèdent mod_proxy et HAproxy sont deux que nous avons trouvés par une recherche rapide sur Google, mais n'ayant aucune expérience de l'équilibrage de charge, je n'ai aucune idée de ce qui serait approprié à notre situation, ni de ce que nous rechercherions tout en choisissant une solution pour résoudre notre problèmes de disponibilité.

Quelle est la meilleure option pour nous? Que devons-nous faire pour obtenir une disponibilité élevée tout en respectant nos budgets?

La solution que j'utilise et qui peut être facilement implémentée avec VPS est la suivante:

• Le DNS est à tour de rôle (sp?) Vers 6 adresses IP valides différentes.
• J'ai 3 équilibreurs de charge avec une configuration identique et en utilisant corosync / pacemaker pour distribuer les 6 adresses IP uniformément (donc chaque machine obtient 2 adresses).
• Chacun des équilibreurs de charge a une configuration nginx + vernis . Nginx s'occupe de recevoir les connexions et de faire des réécritures et une portion statique, et de les renvoyer à Varnish qui fait l'équilibrage de charge et la mise en cache.

Cet arc présente les avantages suivants, à mon avis biaisé:

1. corosync / pacemaker redistribuera les adresses IP en cas de défaillance de l'un des LB.
2. nginx peut être utilisé pour servir SSL, certains types de fichiers directement depuis le système de fichiers ou NFS sans utiliser le cache (gros vidéos, audio ou gros fichiers).
3. Le vernis est un très bon équilibreur de charge prenant en charge le poids, la vérification de l'intégrité du backend et fait un travail remarquable en tant que proxy inverse.
4. En cas de besoin de plus de LB pour gérer le trafic, ajoutez simplement plus de machines au cluster et les adresses IP seront rééquilibrées entre toutes les machines. Vous pouvez même le faire automatiquement (ajouter et supprimer des équilibreurs de charge). C'est pourquoi j'utilise 6 ips pour 3 machines, pour laisser de la place à la croissance.

Dans votre cas, avoir des VPS physiquement séparés est une bonne idée, mais rend le partage IP plus difficile. L'objectif est d'avoir un système redondant résistant aux pannes, et certaines configurations pour l'équilibrage de charge / fin HA gâchent l'ajout d'un point de défaillance unique (comme un équilibreur de charge unique pour recevoir tout le trafic).

Je sais aussi que vous avez posé des questions sur apache, mais ces jours-ci, nous avons des outils spécifiques mieux adaptés au travail (comme nginx et vernis). Laissez apache pour exécuter les applications sur le backend et servez-le à l'aide d'autres outils (pas qu'apache ne puisse pas faire un bon équilibrage de charge ou un proxy inverse, il s'agit juste de décharger différentes parties du travail vers plus de services pour que chaque partie puisse bien fonctionner c'est partager).

HAproxy est une bonne solution. La config est assez simple.

Vous aurez besoin d'une autre instance VPS pour vous asseoir devant au moins 2 autres VPS. Donc, pour l'équilibrage de charge / basculement, vous avez besoin d'un minimum de 3 VPS

Il faut également penser à:

1. Terminaison SSL. Si vous utilisez HTTPS: // cette connexion doit se terminer au niveau de l'équilibreur de charge, derrière l'équilibreur de charge, elle doit transmettre tout le trafic via une connexion non chiffrée.

2. Stockage de fichiers. Si un utilisateur télécharge une image, où va-t-elle? Est-il juste assis sur une machine? Vous avez besoin d'une façon ou d'une autre de partager des fichiers instantanément entre des machines - vous pouvez utiliser le service S3 d'Amazon pour stocker tous vos fichiers statiques, ou vous pouvez avoir un autre VPS qui agirait comme un serveur de fichiers, mais je recommanderais S3 car il est redondant et incroyablement bon marché.

3. informations sur la session. chaque machine de votre configuration d'équilibreur de charge doit pouvoir accéder aux informations de session de l'utilisateur, car vous ne savez jamais quelle machine il va toucher.

4. db - avez-vous un serveur db séparé? si vous n'avez qu'une seule machine en ce moment, comment vous assurerez-vous que votre nouvelle machine aura accès au serveur db - et s'il s'agit d'un serveur db VPS séparé, à quel point est-ce redondant. Il n'est pas nécessairement logique d'avoir des frontaux Web haute disponibilité et un point de défaillance unique avec un serveur db, vous devez maintenant également considérer la réplication db et la promotion des esclaves.

J'ai donc été à votre place, c'est le problème avec un site Web qui fait quelques centaines de visites par jour pour une opération réelle. Cela devient complexe rapidement. J'espère que cela vous a donné matière à réflexion :)

Mon vote est pour Linux Virtual Server comme équilibreur de charge. Cela fait du directeur LVS un point de défaillance unique ainsi qu'un goulot d'étranglement, mais

1. D'après mon expérience, le goulot d'étranglement n'est pas un problème; l'étape de redirection LVS est de niveau 3 et extrêmement bon marché (sur le plan des calculs).
2. Le seul point de défaillance devrait être traité en ayant un deuxième directeur, les deux contrôlés par Linux HA .

Le coût peut être réduit en faisant en sorte que le premier directeur se trouve sur la même machine que le premier nœud LVS et le deuxième directeur sur la même machine que le deuxième nœud LVS. Le troisième nœud et les nœuds suivants sont des nœuds purs, sans implications LVS ou HA.

Cela vous laisse également libre d'exécuter n'importe quel logiciel de serveur Web que vous aimez, car la redirection a lieu sous la couche d'application.

Et cette chaîne?

round robin dns> haproxy sur les deux machines> nginx pour séparer les fichiers statiques> apache

Vous pouvez également utiliser ucarp ou battement de coeur pour garantir que haproxy réponde toujours. Stunnel serait assis devant haproxy si vous avez également besoin de SSL

Vous pouvez envisager d'utiliser un logiciel de clustering approprié. RedHat's (ou CentOS) Cluster Suite ou Oracle's ClusterWare . Ceux-ci peuvent être utilisés pour configurer des clusters actifs-passifs et peuvent être utilisés pour redémarrer les services et échouer entre les nœuds en cas de problèmes graves. C'est essentiellement ce que vous recherchez.

Toutes ces solutions de cluster sont incluses dans les licences de système d'exploitation respectives, vous êtes donc probablement au frais. Ils nécessitent une certaine forme de stockage partagé - soit un montage NFS, soit un disque physique accessible par les deux nœuds avec un système de fichiers en cluster. Un exemple de ce dernier serait les disques SAN avec accès à plusieurs hôtes autorisés, formatés avec OCFS2 ou GFS . Je pense que vous pouvez utiliser des disques partagés VMWare pour cela.

Le logiciel de cluster est utilisé pour définir des «services» qui s'exécutent sur des nœuds tout le temps, ou uniquement lorsque ce nœud est «actif». Les nœuds communiquent via des pulsations et surveillent également ces services. Ils peuvent les redémarrer s'ils constatent des pannes et redémarrer s'ils ne peuvent pas être corrigés.

Vous configureriez essentiellement une seule adresse IP «partagée» vers laquelle le trafic serait dirigé. Apache et tous les autres services nécessaires peuvent également être définis et exécutés uniquement sur le serveur actif. Le disque partagé serait utilisé pour tout votre contenu Web, tous les fichiers téléchargés et vos répertoires de configuration apache. (avec httpd.conf, etc.)

D'après mon expérience, cela fonctionne incroyablement bien.

• Il n'y a pas besoin de tourniquet DNS ou de tout autre équilibreur de charge à point de défaillance unique - tout atteint un IP / FQDN.
• Les fichiers téléchargés par l'utilisateur vont dans ce stockage partagé, et donc ne se soucient pas si votre machine bascule.
• Les développeurs téléchargent du contenu sur cet IP / FQDN unique sans aucune formation supplémentaire, et il est toujours à jour en cas de basculement.
• L'administrateur peut retirer la machine hors ligne, en corriger le problème, redémarrer, etc. Ensuite, basculez le nœud actif. Faire une mise à niveau prend un temps d'arrêt minimal.
• Ce nœud désormais obsolète peut rester non corrigé pendant un certain temps, ce qui rend la restauration automatique un processus tout aussi simple. (Plus rapide que les instantanés VMWare)
• Les modifications apportées à la configuration d'Apache sont partagées, de sorte qu'il ne se passe rien de bizarre lors d'un basculement, car un administrateur a oublié d'apporter des modifications sur la boîte hors ligne.

--Christopher Karel

Un équilibrage de charge optimal peut être très coûteux et compliqué. L'équilibrage de charge de base doit simplement garantir que chaque serveur traite à peu près le même nombre de hits à tout moment.

La méthode d'équilibrage de charge la plus simple consiste à fournir plusieurs enregistrements A dans DNS. Par défaut, l'adresse IP sera configurée selon une méthode de tourniquet. Il en résultera une répartition relativement uniforme des utilisateurs sur les serveurs. Cela fonctionne bien pour les sites apatrides. Une méthode un peu plus complexe est requise lorsque vous avez un site avec état.

Pour gérer les exigences avec état, vous pouvez utiliser des redirections. Donnez à chaque serveur Web une adresse alternative telle que www1, www2, www3, etc. Redirigez la connexion www initiale vers l'adresse alternative de l'hôte. Vous pouvez vous retrouver avec des problèmes de signets de cette façon, mais ils doivent être également répartis sur les serveurs.

Alternativement, l'utilisation d'un chemin différent pour indiquer quel serveur gère la session avec état permettrait des sessions de proxy qui ont basculé l'hôte vers le serveur d'origine. Cela peut être un problème lorsque la session d'un serveur défaillant arrive sur le serveur qui a pris le relais du serveur défaillant. Cependant, sauf logiciel de clustering, l'état sera de toute façon manquant. En raison de la mise en cache du navigateur, vous ne rencontrerez peut-être pas beaucoup de sessions changeant de serveur.

Le basculement peut être géré en configurant le serveur pour prendre en charge l'adresse IP d'un serveur défaillant. Cela minimisera les temps d'arrêt en cas de défaillance d'un serveur. Sans logiciel de clustering, les sessions avec état seront perdues si un serveur tombe en panne.

Sans basculement, les utilisateurs subiront un délai jusqu'à ce que leur navigateur bascule vers la prochaine adresse IP.

L'utilisation de services Restful plutôt que de sessions avec état devrait éliminer les problèmes de clustering sur le front-end. Les problèmes de clustering du côté du stockage s'appliqueraient toujours.

Même avec des équilibreurs de charge devant les serveurs, vous aurez probablement un DNS à tour de rôle devant eux. Cela garantira que tous vos équilibreurs de charge seront utilisés. Ils ajouteront une autre couche à votre conception, avec une complexité supplémentaire et un autre point de défaillance. Cependant, ils peuvent fournir certaines fonctionnalités de sécurité.

La meilleure solution dépendra des exigences pertinentes.

L'implémentation de serveurs d'images pour servir du contenu comme des images, des fichiers CSS et d'autres contenus statiques peut alléger la charge sur les serveurs d'applications.

J'utilise généralement une paire de machines OpenBSD identiques:

• Utilisez RelayD pour l'équilibrage de charge, la surveillance du serveur Web et la gestion d'un serveur Web défaillant
• Utilisez CARP pour une haute disponibilité des équilibreurs de charge eux-mêmes.

OpenBSD est léger, stable et assez sécurisé - Parfait pour les services réseau.

• http://www.openbsd.org - Site principal
• http://www.openbsd.org/faq/pf/carp.html - Documentation Carp
• https://calomel.org/relayd.html - Un ensemble décent d'informations pratiques sur RelayD

Pour commencer, je recommande une configuration layer3. Il évite les complications de configuration du pare-feu (PF). Voici un exemple de fichier /etc/relayd.conf qui montre la configuration d'un équilibreur de charge de relais simple avec surveillance des serveurs Web principaux:

# $OpenBSD: relayd.conf,v 1.13 2008/03/03 16:58:41 reyk Exp $
#
# Macros
#

# The production internal load balanced address
intralbaddr="1.1.1.100"

# The interface on this load balancer with the alias for the intralbaddr address
intralbint="carp0"

# The list of web/app servers serving weblbaddress
intra1="1.1.1.90"
intra2="1.1.1.91"

# Global Options
#
# interval 10
timeout 1000
# prefork 5

log updates

# The "relaylb" interface group is assigned to the intralbint carp interface
# The following forces a demotion in carp if relayd stops
demote relaylb

#
# Each table will be mapped to a pf table.
#
table <intrahosts> { $intra1 $intra2 }

# Assumes local webserver that can provide a sorry page
table <fallback> { 127.0.0.1 }

#
# Relay and protocol for HTTP layer 7 loadbalancing and SSL acceleration
#
http protocol httprelay {
        return error
        header append "$REMOTE_ADDR" to "X-Forwarded-For"
        header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By"
        # header change "Connection" to "close"

        # Various TCP performance options
        tcp { nodelay, sack, socket buffer 65536, backlog 128 }

#       ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
#       ssl session cache disable
}

relay intra-httprelay {
        listen on $intralbaddr port 80
        protocol httprelay

        # Forward to hosts in the intrahosts table using a src/dst hash
        # The example shows use of a page with dynamic content to provide
        # application aware site checking.  This page should return a 200 on success,
        # including database or appserver connection, and a 500 or other on failure
        forward to <intrahosts> port http mode loadbalance \
                check http "/nlbcheck.asp" code 200

}

Avez-vous donné ec2 avec cloudfoundry ou peut-être Elastic beanstalk ou tout simplement un vieil AWS simple qui met à l' échelle une pensée. J'ai utilisé cela et il évolue assez bien et être élastique peut augmenter / diminuer sans aucune intervention humaine.

Étant donné que vous dites que vous n'avez aucune expérience de l'équilibrage de charge, je suggère ces options car elles nécessitent un minimum de "friture" du cerveau pour être opérationnel.

Ce pourrait être une meilleure utilisation de votre temps.