Déployer ElasticSearch sur plusieurs réseaux avec des restrictions et sans se prendre la tête

Une fois n’est pas coutume, un article vraiment technique, et sans troll. J’ai récemment du déployer un cluster ElasticSearch dans un environnement un peu particulier : chacune des machines était connectée à Internet, avec plusieurs interfaces réseau, et un certain nombre de contraintes et restrictions :

  • eth0 : IP externe écoutant sur Internet, avec des règles de Firewall pour bloquer les ports 9200 et 9300.
  • eth1 : IP RFC 1918.
  • lo:0 : IP RFC 1918, la même sur tous les noeuds pour de l’IPVS (load balancing et fail over).

Difficultés rencontrées

Les difficultés étaient principalement dues à ElasticSearch lui-même, pas vraiment fait pour tourner sur un tel setup.

  1. Par défaut, ElasticSearch écoute sur eth0 si l’interface existe et est activée. Couper l’interface, lancer ElasticSearch puis activer l’interface va juste tout foutre en l’air. Utiliser la configuration réseau par défaut et mettre des règles iptables aura un effet catastrophique.
  2. Vous ne pouvez pas dire à ElasticSearch d’écouter sur une liste d’interfaces ou d’IPs, c’est tout ou rien.

Configuration

Nous utilisons de l’unicast avec une liste de serveurs prédéfinie afin d’éviter à ElasticSearch de s’intéresser de près ou de loin à eth0. C’est moins bien en termes de dimensionnement, si quelqu’un a une meilleure solution, je suis évidemment preneur.

<typo:code lang=”json”> “discovery”: { “zen”: {

"ping": {
  "multicast": {
    "enabled": false
  },
  "unicast": {
    "hosts": ["es1", "es2", "es3"]
  }
}

} }, </typo:code>

Nous indiquons ensuite à ElasticSearch d’utiliser eth1 comme adresse de publication dans le cluster, en IPv4 uniquement (ou avec de l’IPv6 si ça vous chante, mais je n’en avais pas besoin).

<typo:code lang=”json”> “network” : { “publishhost”: ”eth1:ipv4_” }, </typo:code>

On fait pareil avec l’adresse de transport :

<typo:code lang=”json”> “transport” : { “host”: ”eth1:ipv4” }, </typo:code>

Ce setup permet à l’interface REST d’ElasticSearch d’être accessible de partout, tout en limitant les adresses de transport et de publication aux adresses souhaitées.