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