| Предыдущая версия справа и слеваПредыдущая версияСледующая версия | Предыдущая версия |
| dpi:qoe_analytics:implementation_administration:requirements [2025/10/22 13:20] – elena.krasnobryzh | dpi:qoe_analytics:implementation_administration:requirements [2025/12/09 08:48] (текущий) – [Таблица] elena.krasnobryzh |
|---|
| - Оперативная память (RAM) - от 16 ГБ | - Оперативная память (RAM) - от 16 ГБ |
| - Жесткий диск (SSD крайне желательно) - от 500 ГБ | - Жесткий диск (SSD крайне желательно) - от 500 ГБ |
| - Операционная система - CentOS 8.x, [[veos:installation|VEOS]], CentOS Stream 8.x, Oracle Linux Server 8.x, AlmaLinux 8.x | - Операционная система - CentOS 8.x, [[veos:installation|VEOS]], CentOS Stream 8.x, Oracle Linux Server 8.x, AlmaLinux 8.x.\\ :!: Используя VEOS, при подборе оборудования учитывайте информацию в разделе [[veos:changelogs]] |
| - Сетевая плата (NIC) - от 1Gbps | - Сетевая плата (NIC) - от 1Gbps |
| |
| - Оперативная память (RAM) - 64 ГБ | - Оперативная память (RAM) - 64 ГБ |
| - Жесткий диск (SSD крайне желательно) - от 500 ГБ, смотрите подробнее расчет объема хранения и рекомендации по организации хранения ниже | - Жесткий диск (SSD крайне желательно) - от 500 ГБ, смотрите подробнее расчет объема хранения и рекомендации по организации хранения ниже |
| - Операционная система - CentOS 8.x, [[veos:installation|VEOS]], CentOS Stream 8.x, Oracle Linux Server 8.x, AlmaLinux 8.x | - Операционная система - CentOS 8.x, [[veos:installation|VEOS]], CentOS Stream 8.x, Oracle Linux Server 8.x, AlmaLinux 8.x.\\ :!: Используя VEOS, при подборе оборудования учитывайте информацию в разделе [[veos:changelogs]] |
| - Сетевая плата (NIC) - 2x10Gbps. Необходимо учитывать, что каждый DPI генерирует IPFIX поток на скорости от 0,5% до 1% от скорости реального трафика. Также рекомендуется объединять порты на QoE в LAG для отказоустойчивости. | - Сетевая плата (NIC) - 2x10Gbps. Необходимо учитывать, что каждый DPI генерирует IPFIX поток на скорости от 0,5% до 1% от скорости реального трафика. Также рекомендуется объединять порты на QoE в LAG для отказоустойчивости. |
| |
| ====Калькулятор объема хранения в зависимости от среднесуточной скорости трафика==== | ====Калькулятор объема хранения в зависимости от среднесуточной скорости трафика==== |
| Считается, что среднесуточный трафик составляет 60% от пикового суммарного (in+out) трафика.\\ | Считается, что среднесуточный трафик составляет 60% от пикового суммарного (in+out) трафика.\\ |
| {{ :dpi:dpi_components:qoestor:install_and_update:qoe_stor_sizing_based_on_average_speed.xlsx |В приведенном калькуляторе необходимо менять значение трафика для получения объемов хранения.}} | {{ :dpi:qoe_analytics:implementation_administration:requirements:qoe_stor_sizing_based_on_average_speed.xlsx |В приведенном калькуляторе необходимо менять значение трафика для получения объемов хранения.}} |
| |
| =====Подробные рекомендации===== | =====Подробные рекомендации===== |
| | CPU | **Один процессор** с поддержкой инструкций **SSE 4.2** начиная с [[http://en.wikipedia.org/wiki/Nehalem_(microarchitecture)|Intel Nehalem]] и [[https://ru.wikipedia.org/wiki/Zen_2_(%D0%BC%D0%B8%D0%BA%D1%80%D0%BE%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0)| AMD EPYC Zen2]] **с количеством ядер 4 и более**, базовой тактовой **частотой от 2.5 ГГц и выше**. Выбирайте процессоры с большим числом ядер. Тактовая частота менее важна. Например, 16 ядер с 2600 МГц лучше, чем 8 ядер 3600 МГц.\\ \\ **Не отключайте Hyper-threading и Turbo-Boost**. | | | | CPU | **Один процессор** с поддержкой инструкций **SSE 4.2** начиная с [[http://en.wikipedia.org/wiki/Nehalem_(microarchitecture)|Intel Nehalem]] и [[https://ru.wikipedia.org/wiki/Zen_2_(%D0%BC%D0%B8%D0%BA%D1%80%D0%BE%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0)| AMD EPYC Zen2]] **с количеством ядер 4 и более**, базовой тактовой **частотой от 2.5 ГГц и выше**. Выбирайте процессоры с большим числом ядер. Тактовая частота менее важна. Например, 16 ядер с 2600 МГц лучше, чем 8 ядер 3600 МГц.\\ \\ **Не отключайте Hyper-threading и Turbo-Boost**. | | |
| | RAM | От 16 ГБ, необходимо устанавливать модули памяти **во все каналы процессора** на материнской плате. Памяти должно быть не меньше, чем объем запрашиваемых данных. Чем больше памяти, тем лучше производительность при построении отчетов. Чем больше памяти, тем меньше нагрузка на диск.\\ \\ **Всегда отключайте файл подкачки**. | | | | RAM | От 16 ГБ, необходимо устанавливать модули памяти **во все каналы процессора** на материнской плате. Памяти должно быть не меньше, чем объем запрашиваемых данных. Чем больше памяти, тем лучше производительность при построении отчетов. Чем больше памяти, тем меньше нагрузка на диск.\\ \\ **Всегда отключайте файл подкачки**. | | |
| | Disks | Для оптимизации стоимости хранения используется несколько типов дисков:\\ 1. **default** — быстрые диски для приема данных и осуществления процесса агрегации, рекомендуется использовать SSD NVMe в RAID0.\\ 2. **hot** — диски для хранения в период когда будет большая вероятность запроса отчетов по этим данных, обычно до 3 месяцев, SSD диски в RAID-10, RAID-5, RAID-6 или RAID-50.\\ 3. **cold** — медленные диски большого объема для долгосрочного хранения, рекомендуется использовать HDD диски в RAID-10, RAID-5, RAID-6 или RAID-50.\\ Срок хранения на каждом уровне задается в конфигурации через GUI. Перемещение данных между дисками и очистка данных происходит автоматически в соответствии с настройками. Также предусмотрен механизм контроля за переполнением с целью защиты базы данных. Основной объем данных хранится в каталоге /var/lib/clickhouse. Временные данные (дампы IPFIX) хранятся в каталоге /var/qoestor/backend/dump. Для лучшей производительности важно (рекомендуется), чтобы эти каталоги находились на отдельном диске или массиве. См. [[dpi:qoe_analytics:implementation_administration:configuration_setup:disc]].\\ Для размещения ОС и ПО QoE Stor необходимо использовать 2 диска емкостью от 256ГБ, объединенные в RAID 1 (зеркало). Необходимо использовать аппаратный RAID контроллер. | | | | Disks | **Тип файловой системы — ext4.**\\ Для оптимизации стоимости хранения используется несколько типов дисков:\\ 1. **default** — быстрые диски для приема данных и осуществления процесса агрегации, рекомендуется использовать SSD NVMe в RAID0.\\ 2. **hot** — диски для хранения в период когда будет большая вероятность запроса отчетов по этим данных, обычно до 3 месяцев, SSD диски в RAID-10, RAID-5, RAID-6 или RAID-50.\\ 3. **cold** — медленные диски большого объема для долгосрочного хранения, рекомендуется использовать HDD диски в RAID-10, RAID-5, RAID-6 или RAID-50.\\ Срок хранения на каждом уровне задается в конфигурации через GUI. Перемещение данных между дисками и очистка данных происходит автоматически в соответствии с настройками. Также предусмотрен механизм контроля за переполнением с целью защиты базы данных. Основной объем данных хранится в каталоге /var/lib/clickhouse. Временные данные (дампы IPFIX) хранятся в каталоге /var/qoestor/backend/dump. Для лучшей производительности важно (рекомендуется), чтобы эти каталоги находились на отдельном диске или массиве. См. [[dpi:qoe_analytics:implementation_administration:configuration_setup:disc]].\\ Для размещения ОС и ПО QoE Stor необходимо использовать 2 диска емкостью от 256ГБ, объединенные в RAID 1 (зеркало). Необходимо использовать аппаратный RAID контроллер. | | |
| | QoE Cluster (Шардирование) | Лучше делать несколько узлов и объединять их в кластер:\\ GUI умеет оптимизировать запросы таким образом, чтобы все узлы строили отчеты параллельно.\\ [[dpi:dpi_components:ipfix_balancer]] используется для равномерного распределения данных по узлам (roundrobin), тем самым сильно улучшая производительность системы.\\ При выходе узла из строя, балансировщик автоматом будет лить данные на оставшиеся узлы. Общая рекомендация такая: как можно больше узлов и как можно меньше порции данных на каждом. Тогда у вас будет:\\ 1. Высокая производительность\\ 2. Хорошая отказоустойчивость\\ 3. Масштабируемость (через добавление узлов в кластер) | | | | QoE Cluster (Шардирование) | Лучше делать несколько узлов и объединять их в кластер:\\ GUI умеет оптимизировать запросы таким образом, чтобы все узлы строили отчеты параллельно.\\ [[dpi:dpi_components:ipfix_balancer]] используется для равномерного распределения данных по узлам (roundrobin), тем самым сильно улучшая производительность системы.\\ При выходе узла из строя, балансировщик автоматом будет лить данные на оставшиеся узлы. Общая рекомендация такая: как можно больше узлов и как можно меньше порции данных на каждом. Тогда у вас будет:\\ 1. Высокая производительность\\ 2. Хорошая отказоустойчивость\\ 3. Масштабируемость (через добавление узлов в кластер) | | |
| |
| =====Советы по эксплуатации от Яндекс ClickHouse===== | =====Советы по эксплуатации от Яндекс ClickHouse===== |
| Советы по эксплуатации от Яндекс ClickHouse вы можете прочитать по ссылке https://clickhouse.yandex/docs/ru/operations/tips/. | Советы по эксплуатации от Яндекс ClickHouse вы можете прочитать по ссылке https://clickhouse.com/docs/ru/operations/tips |
