Нагрузка балансировки с Varnish

Varnish — это мощный балансировщик нагрузки HTTP (обратный прокси), который также очень хорошо справляется с кэшированием. При запуске нескольких TSD Varnish удобно для распределения трафика HTTP между TSD. Имейте в виду, что трафик записи по умолчанию не использует протокол HTTP, и поэтому вы можете использовать Varnish только для чтений. Использование Varnish поможет вам легко масштабировать объем читаемой емкости вашего кластера TSD.

Ниже приведен пример конфигурации Varnish, рекомендуемой для использования с OpenTSDB. Он использует слегка настраиваемую стратегию балансировки нагрузки для достижения оптимальной частоты попадания в кэш на уровне TSD. Эта конфигурация требует как минимум Varnish 2.1.0 для работы, но использование Varnish 3.0 или выше настоятельно рекомендуется.

Этот пример конфигурации предназначен для 2 бэкэндов, названных foo и bar. Вам нужно заменить как минимум имена хостов.

# VCL configuration for OpenTSDB.

backend foo {
  .host = "foo";
  .port = "4242";
  .probe = {
    .url = "/version";
    .interval = 30s;
    .timeout = 10s;
    .window = 5;
    .threshold = 3;
  }
}

backend bar {
  .host = "bar";
  .port = "4242";
  .probe = {
    .url = "/version";
    .interval = 30s;
    .timeout = 10s;
    .window = 5;
    .threshold = 3;
  }
}

# The `client' director will select a backend based on `client.identity'.
# It's normally used to implement session stickiness but here we abuse it
# to try to send pairs of requests to the same TSD, in order to achieve a
# higher cache hit rate.  The UI sends queries first with a "&json" at the
# end, in order to get meta-data back about the results, and then it sends
# the same query again with "&png".  If the second query goes to a different
# TSD, then that TSD will have to fetch the data from HBase again.  Whereas
# if it goes to the same TSD that served the "&json" query, it'll hit the
# cache of that TSD and produce the PNG directly without using HBase.
#
# Note that we cannot use the `hash' director here, because otherwise Varnish
# would hash both the "&json" and the "&png" requests identically, and it
# would thus serve a cached JSON response to a "&png" request.
director tsd client {
  { .backend = foo; .weight = 100; }
  { .backend = bar; .weight = 100; }
}

sub vcl_recv {
  set req.backend = tsd;
  # Make sure we hit the same backend based on the URL requested,
  # but ignore some parameters before hashing the URL.
  set client.identity = regsuball(req.url, "&(o|ignore|png|json|html|y2?range|y2?label|y2?log|key|nokey)\b(=[^&]*)?", "");
}

sub vcl_hash {
  # Remove the `ignore' parameter from the URL we hash, so that two
  # identical requests modulo that parameter will hit Varnish's cache.
  hash_data(regsuball(req.url, "&ignore\b(=[^&]*)?", ""));
  if (req.http.host) {
    hash_data(req.http.host);
  } else {
    hash_data(server.ip);
  }
  return (hash);
}

На многих дистрибутивах Linux (включая Debian и Ubuntu) вам нужно поместить приведенную выше конфигурацию в /etc/varnish/default.vcl. Мы также рекомендуем настроить параметры командной строки varnishd для использования кэша на основе памяти объемом около 1 ГБ, если вы можете это себе позволить. В системах Debian/Ubuntu это делается путем редактирования /etc/default/varnish, чтобы убедиться, что -s malloc,1G передается в varnishd.

Подробнее о Varnish:

• Язык конфигурации VCL
• Проверка работоспособности бэкэндов
• Настройка стратегии балансировки нагрузки