Руководство по планированию кластера¶
Руководство по планированию кластера включает в себя следующие главы необходимые для прочтения перед непосредственной установкой кластера
Рекомендации по настройке Сервера¶
- Рекомендации по аппаратному обеспечению
- Рекомендации по сети:
- Избегайте работы по каналам глобальной сети между центрами обработки данных
- Старайтесь, чтобы между узлами было ноль (или очень мало) переходов.
- Если у вас несколько сетевых карт
- разделяйте транспортный и 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. Этот инструмент прост в развертывании и запуске и полностью настраивается, поэтому вы можете тестировать несколько сценариев.