Benjamin Dos Santos

Parfois il peut être intéressant de “drainer” un membre de son cluster Elasticsearch de toutes ses données, avant de réaliser une maintenance planifiée par exemple.

Vous pouvez réaliser cette action en vous basant sur l’IP du noeud, son nom ou hostname :

curl -XPUT 'localhost:9200/_cluster/settings?pretty' -d '{
  "transient" : {
    "cluster.routing.allocation.exclude._ip" : "10.0.0.1"
  }
}'

curl -XPUT 'localhost:9200/_cluster/settings?pretty' -d '{
  "transient" : {
    "cluster.routing.allocation.exclude._ip" : "10.0.0.*"
  }
}'

curl -XPUT 'localhost:9200/_cluster/settings?pretty' -d '{
  "transient" : {
    "cluster.routing.allocation.exclude._name" : "els01"
  }
}'

curl -XPUT 'localhost:9200/_cluster/settings?pretty' -d '{
  "transient" : {
    "cluster.routing.allocation.exclude._hostname" : "els01.prd.sfo.domain.tld"
  }
}'

D’après les recommandations LSI, les paramètres à utiliser pour tirer les meilleurs performances d’un RAID SSD sont :

Read Cache: DISABLED
Write Cache: WriteThrough
IO: DIRECT

En pratique :

Activer le WriteThrough

MegaCli -LDSetProp -WT -Immediate -Lall -aAll

Désactiver ReadAhead / Read Caching

MegaCli -LDSetProp -NORA -Immediate -Lall -aAll

Activer Direct IO

MegaCli -LDSetProp -Direct -Immediate -Lall -aAll

MegaCli est probablement l’un des pires utilitaires CLI jamais écrit. Voici quelques commandes très utiles.

# Show status
MegaCli -AdpAllInfo -aAll

# Get physical drive info
MegaCli -PDList -aAll

# Get virtual disk info
MegaCli -LDInfo -Lall -aAll

# Display configuration
MegaCli -CfgDsply -aAll

# Dump eventlog events to file 'events' and open it
MegaCli -AdpEventLog -GetEvents -f events -aAll && less events

# Disable autoLearnMode for the RAID battery
echo "autoLearnMode=1" > tmp.txt \
  && MegaCli -AdpBbuCmd -SetBbuProperties -f tmp.txt -a0

# Disable cache when battery broken
MegaCli -LDSetProp NoCachedBadBBU -LALL -aALL

Warmup votre cache peut être indispensable afin d’éviter un léger pic de charge inutile lorsque vous dirigez du trafic sur une instance fraichement spawn.

La première solution se base sur le sitemap de votre site. Simple, probablement Quick & Dirty, mais efficace :

#!/usr/bin/env bash

while test -n "$1"; do
  case $1 in
    --sitemap|-s)
      sitemap=$2
      shift
      ;;
    --http_verb|-h)
      http_verb=$2
      shift
      ;;
    *)
      echo "Unknown argument: $1"
      exit 3
      ;;
  esac
  shift
done

tmpfile=$(mktemp /tmp/$(basename $0).XXXXXX)
sitemap=${sitemap:='http://myawesometenmillionsvisitorsmediawebsite.tld/sitemap.xml'}
http_verb=${http_verb:='GET'}

curl --silent $sitemap | grep \<loc\> | sed 's/.*<loc>//' | sed 's|</loc>||' \
  >> $tmpfile

cat $tmpfile | xargs -I % -n 1 -P 16 curl -X$http_verb %
rm $tmpfile

À noter que vous pouvez également vous en servir pour PURGE le cache en modifiant le verbe HTTP.

La seconde méthode consiste à utiliser varnishreplay :

ssh www.varnish-cache.org varnishlog -w - | varnishreplay -a localhost:6081 -r -

Généralement j’utilise la première méthode tout en ajustant le trafic en adaptant le poids de ces nouvelles instances.