Руководство по планированию кластера

Руководство по планированию кластера включает в себя следующие главы необходимые для прочтения перед непосредственной установкой кластера

Рекомендации по настройке Сервера

  1. Рекомендации по аппаратному обеспечению
  • Рекомендации по сети:
  • Избегайте работы по каналам глобальной сети между центрами обработки данных
  • Старайтесь, чтобы между узлами было ноль (или очень мало) переходов.
  • Если у вас несколько сетевых карт
  • разделяйте транспортный и http трафик (транспорт на более быстрой сетевой карте)
  • привязка к разным сетевым интерфейсам
  • используйте отдельные правила брандмауэра для каждого вида трафика
  • Используйте долгоживущие HTTP-соединения
  • клиентские библиотеки поддерживают это или используйте прокси/балансировщик нагрузки
  • Рекомендации по хранению данных:
  • Отдавайте предпочтение твердотельным дискам (SSD) сегменты неизменны поэтому коэффициент усиления записи приближается к единице и не является проблемой
  • Локальный диск - лучше другими словами, избегайте файловых систем NFS, SMB, AWS EFS или Azure
  • ADLS не требует избыточного хранилища реплики программное обеспечение HA
  • локальные диски лучше, чем SAN/NAS
  • RAID1/5/10 не нужен
  • Если у вас несколько дисков на одном сервере вы можете установить RAID 0 или path.data
  • RAID 0
    • равномерно разделяет данные на два или более дисков
    • идеальное распределение данных по дискам

Note

Однако, если вы потеряете один диск, вы потеряете данные на всех дисках

  • path.data
    • позволяет распределить индекс по нескольким дискам
    • возможность иметь несбалансированное распределение (все файлы, принадлежащие осколку, будут храниться по тому же пути к данным)
    • при потере одного диска шарды на всех остальных дисках сохраняются (может создавать проблемы с watermarks на уровне узла, если диски имеют разные размеры)
  • SSD: используйте планировщик noop или deadline в ОС
  • HDD диски подходят для теплых (warm) узлов
    • но не забудьте отключить одновременные слияния
    • index.merge.scheduler.max_thread_count: 1
  • Выбор оборудования:
  • В целом, выбирайте большие машины, а не экстра-большие
    • потеря большого узла имеет большее влияние
    • лучше - 6 машин с 4-8 процессорами x 64 ГБ x 4 дисками по 1 ТБ
    • хуже - 2 машины с 12 процессорами x 256 ГБ x 12 дисками по 1 ТБ
  • Избегайте запуска нескольких узлов на одном сервере
    • Придерживайтесь правила - одна нода - один сервер
    • конфликт ресурсов нескольких JVM могут быть проблематичными
  • Машины большего размера могут быть полезны как теплые или холодные узлы
  • Master ноды
    • Сервера с низкими требованиями к ресурсами ЦП, ОЗУ и диска
  • Data ноды
    • Сервера с высокими требованиями к ресурсам ЦП, ОЗУ и дисковыми ресурсами
  • Ingest ноды
    • Сервера с малым объемом диска, средней размером оперативной памятьи и высокими требованиями к ресурсами ЦП
  • JVM Heap Size

Рекомендации по аппаратному обеспечению для Arenadata LogSearch

Рабочие нагрузки ADLS, как правило, сильно различаются, и необходим опыт для правильного прогнозирования объемов хранилища, вычислительной мощности и межузловой связи, которые потребуются для выполнения различных видов работ. В главе содержится информация о выборе соответствующих аппаратных компонентов для оптимального баланса между производительностью и стабильностью работы для различных нагрузок:

Типичный кластер ADLS

Кластеры ADLS имеют разные типы машин:

  • Masters - Управляет общей работой кластера и отслеживает состояние кластера. Сюда входит создание и удаление индексов, отслеживание узлов, которые присоединяются к кластеру и покидают его, проверка состояния каждого узла в кластере (путем выполнения запросов ping) и распределение шардов между узлами.
  • Coordinators - Делегирует клиентские запросы к шардам на узлах данных, собирает и объединяет результаты в один конечный результат и отправляет этот результат обратно клиенту
  • Data nodes - Хранит и ищет данные. Выполняет все операции, связанные с данными (индексирование, поиск, агрегирование), на локальных шардах. Это рабочие узлы вашего кластера, и им требуется больше дискового пространства, чем узлам любого другого типа.
  • Ingest nodes - Предварительная обработка данных перед их хранением в кластере. Запускает конвейер ввода, который преобразует данные перед добавлением их в индекс.
  • Dashboard - для визуального отображения проиндексированных в кластере данных, взаимодействия с ними. Позволяет быстро создавать и обмениваться динамическими панелями мониторинга, включая таблицы, графики и диаграммы, которые отражают изменения в запросах в реальном времени. Так же позволяет администрировать базу данных.

Note

Минимальная конфигурация кластера состоит из одной мастер-ноды и двух дата-нод.

По умолчанию каждый узел является ведущим узлом, узлом приема данных и координации. Решение о количестве узлов, назначении типов узлов и выборе оборудования для каждого типа узла зависит от вашего варианта использования. Вы должны учитывать такие факторы, как количество времени, в течение которого вы хотите хранить свои данные, средний размер ваших документов, вашу типичную рабочую нагрузку (индексирование, поиск, агрегирование), ваше ожидаемое соотношение цены и качества.

Основы вычислительных ресурсов

Производительность зависит от того, как вы используете ADLS, а также от того, на чем вы его используете. Давайте рассмотрим некоторые основы вычислительных ресурсов. Для каждой операции поиска или индексации задействованы следующие ресурсы:

Хранение : где данные сохраняются

  • По возможности рекомендуется использовать твердотельные накопители, особенно для узлов, на которых выполняются операции поиска и индексирования. Из-за более высокой стоимости SSD-хранилища рекомендуется использовать горячую архитектуру для сокращения расходов.
  • При работе на голом железе лучшим решением является локальный диск!
  • ADLS не требует избыточного хранилища (RAID 1/5/10 не требуется), сценарии использования журналов и метрик обычно имеют по крайней мере один сегмент реплики, что является минимумом для обеспечения отказоустойчивости при минимальном количестве операций записи.

Память : где данные буферизуются

  • JVM Heap: хранит метаданные о кластере, индексах, сегментах, сегментах и ​​полевых данных. В идеале это 50% доступной оперативной памяти.
  • Кэш ОС: ADLS будет использовать оставшуюся доступную память для кэширования данных, что значительно повысит производительность за счет предотвращения операций чтения с диска во время полнотекстового поиска, агрегирования значений документов и сортировки.

Вычисления : где обрабатываются данные

ADLS узлы имеют пулы и очередь потоков , которые используют доступные вычислительные ресурсы. Количество и производительность ядер ЦП определяют среднюю скорость и пиковую пропускную способность операций с данными в ADLS.

Сеть : куда передаются данные

Производительность сети - как пропускная способность, так и время ожидания - может влиять на межузловую связь и межкластерные функции, такие как кросс-кластерный поиск и кросс-кластерная репликация.

Калибровка по объему данных

В случаях использования метрик и ведения журналов мы обычно управляем огромным объемом данных, поэтому имеет смысл использовать объем данных для первоначального определения размера нашего кластера ADLS. В начале этого упражнения нам нужно задать несколько вопросов, чтобы лучше понять данные, которыми нужно управлять в нашем кластере.

  • Сколько необработанных данных (ГБ) мы будем индексировать в день?
  • Сколько дней мы будем хранить данные?
  • Сколько дней в горячей зоне?
  • Сколько дней в теплой зоне?
  • Сколько осколков реплик вы будете использовать?

Обычно мы добавляем 5% или 10% для погрешности и 15%, чтобы оставаться под обслуживание диска. Мы также рекомендуем добавить узел на случай отказа оборудования.

  • Всего данных (ГБ) = сырых данных (raw) (ГБ) в день * Количество дней хранения * (Количество реплик + 1)
  • **Общий объем хранилища **(ГБ) = общий объем данных (ГБ) * (1 + 0,15 + 0,1)
  • Общее количество Data нод = ROUNDUP (Общее хранилище (ГБ) / Память на узел данных / соотношение RAM к объему диска). В случае большого развертывания безопаснее добавить узел для резервной емкости.

Пример: определение размера большого развертывания

Давайте посчитаем со следующими входными данными:

  • Вы получаете 100 ГБ в день, и нам нужно хранить эти данные 30 дней в горячей зоне и 12 месяцев в теплой зоне.
  • У нас есть 64 ГБ памяти на каждый узел, из которых 30 ГБ выделено для JVM Heap, а оставшаяся часть - для кеш-памяти ОС.
  • Типичное соотношение память: данные для используемой горячей зоны составляет 1:30, а для теплой зоны - 1:160.

Если мы получаем 100 ГБ в день и должны хранить эти данные в течение 30 дней, это дает нам:

  • Общий объем данных (ГБ) в горячей зоне = (100 ГБ x 30 дней * 2) = 6000 ГБ
  • Общий объем хранилища (ГБ) в горячей зоне = 6000 ГБ x (1 + 0,15 + 0,1) = 7500 ГБ
  • Общее количество узлов данных в горячей зоне = ROUNDUP (7500/64/30) + 1 = 5 узлов
  • Общий объем данных (ГБ) в теплой зоне = (100 ГБ x 365 дней * 2) = 73000 ГБ
  • Общий объем хранилища (ГБ) в теплой зоне = 73000 ГБ x (1 + 0,15 + 0,1) = 91250 ГБ
  • Общее количество узлов данных в теплой зоне = ROUNDUP (91250/64/160) + 1 = 10 узлов

Дополнительные рекомендации:

  • Не превышайте 20 шард на 1 Гб JVM Heap на каждой ноде;
  • Не превышайте объема дискового пространства шарды в 40 Гб.

Нагрузочное тестирование

Рекомендуем использовать инструмент Rally. Этот инструмент прост в развертывании и запуске и полностью настраивается, поэтому вы можете тестировать несколько сценариев.