Roadmap

0. mars-avril et avant: réflexion et recherche

1. avril: rouler hoststated sur le routeur pour pouvoir répondre *quelquechose* quand homere plante (possible que l'on ait besoin de bouger l'IP), tout le traffic vers homere passe vers hoststated 16134 le parefeu peut maintenant prendre le dessus sur n'importe quelle IP et faire du load balancing

2. avril: www1 en test - vserver de test de backup de homere:

   • homere en serveur NFS: (donc export de /var/alternc/{html,mail,tmp}, /var/lib/php{4,5}, /var/lib/mailman (16137)

   • client NFS du vserver (donc chronos, pas besoin de mailman dans l'immédiat) (16136)

   • tout sur le vlan privé (17502) - reste encore à vérifier

3. début juin: server MySQL dédié 15999

4. fin juillet: www1 en beta (embarqué en hoststated come fallback), prendrait une petite partie de la charge puisque c'est une machine peu performante. fait! il est en fallback pour l'instant

5. mi août: www1 en prod 16136

6. début septembre: serveur NFS dédié, homere aurait une conf semblable au vserver test en prod (à partir d'ici, homere peut planter et on perd seulement le bureau et mailman)

7. fin septembre: deuxième hoststated en redondance CARP

8. quelque part en route: deuxième serveur MySQL en redondance (slave ou cluster) ( mysql0.koumbit.net sur remus.koumbit.net)

9. 2008-2009:
   • deuxième uplink

   • AS

   • deuxième serveur NFS

Discussion

Antoine

layer 3 (niveau IP) ou layer 7 (niveau application, proxy http à-la-squid)? voir plus bas pour les détails. Je pencherais pour le layer3, parce que c'est plus simple et qu'on peut mettre des Squid de plus éventuellement.

Mathieu

comment fonctionnera AlternC, les serveurs DNS, Mailman?

Antoine

on peut forcer le traffic du port 53 (dns) vers une seule machine. Le cron de alternc pourrait rouler sur une seule machine. Pas de confs modifiées directement par alternc hors de /var/alternc. Par contre, Mailman appelle des wrappers suid.

Mathieu

on pourrait faire que tout le traffic de .66 SSL soit redirigé vers Homere.

Antoine

le trimestre se termine en fin-mai, donc à partir de juin on peut faire des dépenses pour le load balancing.

Antoine

on peut faire qu'un des deux mails servers est seulement un MX

Mathieu

est-ce qu'on fait un setup que le serveur NFS réplique le MySQL et vice-versa?

Antoine

je ne suis plus sûr que c'est la bonne approche, parce que c'est deux applications différentes (on veut pouvoir optimiser les deux serveurs le plus possible)

Choses à vérifier

• le traitement des logs apache

• l'ip de homere doit elle être migrée vers le load balancer? (oui, mais on a pas à changer les whois et tout le reste, voir 17161

• Mailman:
  • comment gérer mailman en redondance?

  • est-ce qu'on peut migrer vers sympa? (comparaison entre sympa et mailman)

  • comment faire que les listes sont renvoyées vers le serveur mailman?
• FTP:
  • fonctionnement de FTP (2e socket ouvert vers l'autre serveur?) Solution: créer ftp.koumbit.net et le rediriger vers un seul serveur. Autre possibilité: enquêter davantage l'utilisation de sftp avec chroot.

    • 09:34 < birdy> bonne chance pour le FTP 
      09:34 < birdy> keepalived (du moins sur la version qu'on utilise) a un vrai problème avec ca
      09:34 < birdy> enfin c'est super étrange
      09:35 < birdy> c'est pas obligatoirement un pb reproductible
      09:35 < birdy> sachant que nous on fait pas de Lb en direct routing mais en nat
      09:35 < birdy> ca aide encore moins
      
      modprobe ip_vs_ftp devrait le faire !
      

• Bureau AlternC:

  • la création de nouveau membres utilise des scripts suid. Gestion de uid/gid?

    • la gid/uid sont dans mysql, le script add_mem fait juste créer un répertoire dans /var/alternc/html/ (donc OK)
  • gestion des quotas par setquota ? comment ça fonctionne avec NFS?

Service load balancing

file service redundancy

Possible solutions:

• ChironFS

• tahoe

• DRDB

• ext3 external journal man mke2fs -> -J device=external-journal

• OCFS2

• http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems

• Coda
• AFS...

Database service redundancy

• MysqlReplication current solution

• Mysql Clustering

• Postgresql?

Web service load balancing

There's two technical possibilities on how to do this. One is to have a reverse proxy on the frontend and the other is to redirect TCP connections directly.

Reverse proxying (AKA Layer-7 switching)

Possible software

• Pound

• Nginx

• Squid
• Apache mod_proxy

• Hoststated

Realistically, the two mostly in use these days are Pound and Nginx. Squid is a caching proxy, which we don't necessarly want. Apache mod_proxy isn't exactly the best of its breed.

Nginx is interesting because it also proxies email services, although that's a bit bizarre and is regarded by certain people as a bad design decision.

Pound doesn't do that kind of stuff, but/so it's a bit less flexible.

Hoststated is the openbsd-grown solution. Its obvious advantage is that it's shipped with OpenBSD 4.1 and above.

Evaluation

This evaluates the approach in itself, not the available software, which is assumed to be equivalent, apart from the comments above.

Pros

• Fixes the lingering connection problem that could otherwise be fixed by lingerd (see also the debian package)

Cons

• real IP obfuscated on the backend apache servers, which might break authentication and anonymous user tracking on some sites. can be fixed with a module like mod_rpaf or patches to the various applications (like Drupal)

TCP connection redirection (AKA Layer-4 switching)

Possible software

• IPVS

• Hoststated, again!

IPVS is a Linux Netfilter module that implements transport-layer load balancing inside the Linux kernel, so called Layer-4 switching. IPVS running on a host acts as a load balancer at the front of a cluster of real servers, it can direct requests for TCP/UDP based services to the real servers, and makes services of the real servers to appear as a virtual service on a single IP address. It's in use widely and seems to be working well, although I have no personnal experience with it.

Hoststated is the same, for OpenBSD. What's interesting with it, however, is that it can do both layer-4 and layer-7 switching, so it is very flexible. It also integrates with the excellent pf packet filter and has therefore good performance.

Evaluation

Again, this evaluates the approach in itself, not the available software, which is assumed to be equivalent, apart from the comments above.

Pros

• no modification required on the backend, TCP connections are passed as is
• no problem with IP modification

Cons

• session might be confused by the switching of servers, which can be controlled using layer-7 switching
• similar issues with time drifts
• doesn't fix the lingering connection problem
• does not allow for caching
• can only be deployed on a router or something that already does firewalling (ie. needs access to the IP layer so it won't run in a vserver, for example. but it could run on a Xen DomU, i guess...)

Working example: approche "française" ou "diamant"

Cette approche est utilisée par Globenet et l'Autre Net pour l'architecture de leurs services d'hébergement. Le nom est de TheAnarcat. Voir aussi Comment, la page qui présente rapidement comment est montée leur infrastructure.

This is what lautre.net does:

    { big bad ass internet }
          \
           \
        +---------------+
        | load balancer |
        +---------------+
       /        |         \
 +-------+  +-------+     +-------+
 | node1 |  | node2 | ... | nodeN |
 +-------+  +-------+     +-------+
        \       |         /
         +----------------+
         | filer/database |
         +----------------+

Le load balancer est le IPVS, un "Advanced Layer-4 Switching server" de Linux Virtual Server (LVS).

Le mail est géré par la batterie de webservers, donc chaque node roule aussi un postfix qui parle à la DB. Mailman roule sur une seul machine, par contre. Les autres machines ont /var/lib/mailman monté en NFS et exécutent seulement les wrappers pour ajouter/enlever des listes. Le bureau AlternC est aussi sur une seule machine, les autres faisant la redirection.

Finalement, les fichiers dans /var/alternc sont partagés en NFS par le filer.

lautrenet presently has only two "nodes". Apart from that, the diagram is pretty faithful. This setup has two SPF (Single_Point_of_Failure): the database and the load balancer. The database could be made redundant with multiple servers or with RAID disks. The load balancer should be a really simple machine that could be hot-swappable.

The nodes are mostly redundant: if one goes down or is wedged by a PHP bug, the others take over.

MX backups

Setup one or two secondary mail servers that would handle the mail in case of homere crash.

Pro: This would help us avoid losing mails when extended downtimes like we saw recently.

Con: needs coding to create a system similar to alternc-slavedns. Should be fairly simple to implement, however.

emergency contact lists

Have the membres@ mailing list and the root@ alias mirrored on some other machine to have an easy way to contact key people.

Pro: easy to setup, allows us to quickly communicate the situation

Con: patchup solution

Note: we now have a few lists of homere mirrored on lethe.

We also have EscalationProcedures in NagiosMonitoring. -- TheAnarcat 2008-01-20 21:37:19 EST

bandwidth load balancing

TVAC

check how tvac do it.

Torrents

For the CMAQ, it could be really good to be able to seed some video files as well as distribute torrents. It would really alleviate the load on the server.

---

CategorieProjets