Когда приходится развертывать Elasticsearch в продакшине, есть несколько рекомендаций, которые следует учесть. Elasticsearch используется для широкого круга задач и на огромном количестве машин. Но эти рекомендации представляют собой хорошие отправные точки.
Память
Если и есть ресурс, который вы исчерпаете первым, то это, скорее всего, память. Сортировка и агрегация могут требовать много памяти, поэтому важно иметь достаточно места в куче для их размещения. Даже если куча сравнительно мала, дополнительную память можно отдать под кэш файловой системы ОС. Поскольку многие структуры данных, используемые Lucene, представляют собой дисковые форматы, Elasticsearch эффективно использует кэш ОС.
Идеальным вариантом является машина с 64 ГБ оперативной памяти, но также часто встречаются машины с 32 и 16 ГБ. Меньше 8 ГБ, как правило, контрпродуктивно (в итоге вам понадобится много маленьких машин), а больше 64 ГБ имеет проблемы.
Процессор
Большинство установок Elasticsearch, как правило, не требуют большого количества процессоров или ядер. Поэтому точная установка процессора имеет меньшее значение, чем другие ресурсы. Вам следует выбрать современный процессор с несколькими ядрами. В обычных кластерах используются машины с двумя-восемью ядрами.
Если вам нужно выбрать между более быстрым процессором или большим количеством ядер, выбирайте больше ядер. Дополнительный параллелизм, обеспечиваемый несколькими ядрами, намного перевесит немного более высокую тактовую частоту.
Диски
Диски важны для всех кластеров, и вдвойне для кластеров с высокой индексацией (таких как кластеры, в которые поступают данные журналов). Диски являются самой медленной подсистемой в сервере, а это значит, что кластеры, интенсивно использующие запись, могут легко перегрузить свои диски, которые, в свою очередь, станут узким местом кластера.
Если вы можете позволить себе твердотельные накопители, они намного превосходят любые HDD. На узлах с твердотельными накопителями повышается производительность как запросов, так и индексирования. Если вы можете себе это позволить, SSD - это то, что вам нужно.
Если вы используете твердотельные накопители, убедитесь, что планировщик ввода-вывода вашей ОС настроен правильно. Когда вы записываете данные на диск, планировщик ввода-вывода решает, когда эти данные будут отправлены на диск. По умолчанию в большинстве дистрибутивов *nix используется планировщик под названием cfq (Completely Fair Queuing).
Этот планировщик выделяет временные фрагменты для каждого процесса, а затем оптимизирует доставку этих различных очередей на диск. Он оптимизирован для HDD: природа вращающихся пластин означает, что эффективнее записывать данные на диск на основе физического расположения.
Однако для SSD это неэффективно, поскольку там нет вращающихся пластин. Вместо этого следует использовать deadline или noop. Планировщик deadline оптимизирует на основе того, как долго ожидается запись, в то время как noop - это простая очередь FIFO.
Это простое изменение может оказать значительное влияние. Мы наблюдали 500-кратное улучшение пропускной способности записи только за счет использования правильного планировщика.
Если вы используете HDD, постарайтесь приобрести как можно более быстрые диски (высокопроизводительные серверные диски, диски со скоростью вращения шпинделя 15 тыс. об/мин).
Использование RAID 0 является эффективным способом увеличения скорости дисков, как для вращающихся дисков, так и для SSD. Нет необходимости использовать зеркалирование или варианты RAID с контролем четности, поскольку высокая доступность встроена в Elasticsearch с помощью реплик.
Наконец, избегайте сетевых хранилищ (NAS). Люди постоянно утверждают, что их NAS-решение быстрее и надежнее, чем локальные диски. Несмотря на эти заявления, мы никогда не видели, чтобы NAS оправдывал свою шумиху. NAS часто работает медленнее, демонстрирует большие задержки с большим отклонением средней задержки и является единой точкой отказа.
Сеть
Быстрая и надежная сеть, безусловно, важна для производительности распределенной системы. Низкая задержка помогает обеспечить беспрепятственную связь между узлами, а высокая пропускная способность способствует перемещению и восстановлению шардов. Современные сети центров обработки данных (1 GbE, 10 GbE) достаточны для подавляющего большинства кластеров.
Избегайте кластеров, охватывающих несколько центров обработки данных, даже если центры обработки данных расположены в непосредственной близости друг от друга. Определенно избегайте кластеров, которые охватывают большие географические расстояния.
Кластеры Elasticsearch предполагают, что все узлы одинаковы, а не то, что половина узлов находится на расстоянии 150 мс в другом центре обработки данных. Большие задержки, как правило, усугубляют проблемы в распределенных системах и затрудняют отладку и решение.
Как и в случае с NAS, все утверждают, что их каналы связи между центрами обработки данных надежны и имеют низкую задержку. Это действительно так, пока это не так (сбой в сети рано или поздно произойдет; вы можете рассчитывать на это). По нашему опыту, хлопоты, связанные с управлением кластерами между центрами обработки данных, просто не стоят затрат.
Общие моменты
В настоящее время можно получить действительно огромные машины: сотни гигабайт оперативной памяти с десятками ядер процессора. И наоборот, можно запустить тысячи небольших виртуальных машин на облачных платформах, таких как EC2. Какой подход лучше?
В целом, лучше предпочесть средние и большие машины. Избегайте маленьких машин, потому что вы не хотите управлять кластером с тысячей узлов, а накладные расходы, связанные с простым запуском Elasticsearch, более очевидны на таких маленьких машинах.
В то же время избегайте действительно огромных машин. Они часто приводят к несбалансированному использованию ресурсов (например, используется вся память, но не используется процессор) и могут усложнить логистику, если вам придется запускать несколько узлов на одной машине.