Page tree
Skip to end of metadata
Go to start of metadata

Условно инсталляции NOC можно разделить на несколько размеров. Самым простым будет такой:

Вариант одного сервера

Single server install

Вся инсталяция на одном сервере.

ПлюсыМинусы
  • Все достаточно компактно.
  • Легко бекапить средствами гипервизора
  • Производительность очевидно упирается в мощность одного сервера
  • Отказоустойчивости в этой схеме предусмотреть нельзя. 
  • Потребление памяти Mongodb по умолчанию 50% +1Gb от памяти сервера
  • Выборки из clickhouse могут быть довольно тяжелыми. Clickhouse стремится выполнить запрос как можно скорее не особо стесняясь потреблять все ресурсы. Его аппетиты можно ограничить, но это предмет настройки.

Что можно сделать ?

Что бы сервис был более устойчивым имеет добавить еще 2 сервера. Один под mongodb и один под clickhouse. Изолировать их по памяти в отдельной песочнице. Это значительно повышает отказоустойчивость решения и скорость. т.к. память на хосте с NOC будет выделена ему. 

Вариант сервер + выносные активаторы

sharded noc

по факту этот вариант применяется когда есть еще удаленная точка, выделенный vrf или отдельный кампус.

В плане производительности ничем не отличается от первого варианта. однако довольно частый. 

Рекомендации по масштабированию точно такие же. 


Попытка масштабирования №1

noc scale v1

ПлюсыМинусы
  • Базы данных в своих виртуалках. Clickhouse не может съесть все ресурсы во время выборок и  положить всю систему.
  • Легко следить за памятью и местом на хостах с базами.
  • Эксплуатация серверов с базами данных делается по мануалам баз данных, сервисов нока там нет или почти нет (на сервер с Clickhouse есть сmwriter)
  • Начинаются сложности с бекапом, однако бекап все еще осуществляется бекапом одной виртуалки. с mongo+postgres
  • Базы данных работают без резерва.
  • Башня находится там же где нок. В случае высокой нагрузка на систему полагаться на графики с системы не получится т.к. они скорее всего не будут собираться
  • Запись метрической информации ведётся в базу influxdb. Хотя её объемы не столь значительны лучше воздержаться от ее использования.
  • Метрическая информация с системы не зарезервирована. во время плановых работ на clickhouse нет возможности посмотреть графики с сетевого железа. ограничено работает карта.

Попытка масштабирования №2

noc scale v2. db

сделали базы данных отказоустойчивыми.

  • Clickhouse масштабируем дублированием записи.
  • Mongo делается репликасетом. минимальное кол-во серверов из-за кворума 3.
  • Масштабирование постгреса за пределами рекомендаций. Популярными решениями с различным уровнем автоматизации сейчас являются repmgr и patroni
ПлюсыМинусы
  • наконец то данные потерять уже сложно
  • мониторинг вынесен на выделенный сервер. во время аварии на системе можно понять что происходит и где.
  • можно принимать решения по оптимизации производительности системы
  • сложно
  • требует глубокого понимания как всё это работает
  • много ручных операций. переключение в графане источников данных для просмотра графиков и тому подобное
  • отвал постгеса сложное восстановление. ручные операции по указанию где активный постгрес
  • бекап усложнился значительно
  • вертикальное масштабирование сервера нока себя уже исчерпало. добавление ресурсов на этот сервер уже скорее всего уже невозможно.


Попытка масштабирование №3

noc scale v3. noc

разнесли демоны NOC по разным хостам. и сделали горизонтальное масштабирование

ПлюсыМинусы
  • система работает сама по себе
  • единичный выход из строя не приводит к останову системы

  • Чудовищно сложно.
  • типичный деплой схемы вносит простой в работу системы. нужно точно понимать что делается в плейбуке и запускать плейбук по частям
  • узкими местами являются запись в базы данных. например скорость записи в clickhouse примерно 30к записей в секунду. иногда это может быть мало.
  • не зарезервирован сервер башни.
  • нотификация о проблемах в системе требует связности с интернетом нужно проверять есть ли эта связность.
  • логи.
  • диагностика.
  • трап и сислог коллекторы не зарезервированы. плановые работы приводят к останову сбора сислога
  • тормоза в связных системах (ldap, эскалации) приводят к тормозам в комплексе


 Попытка масштабирование №4


scale v4

Добавляем в схему Consul. он берет на себя вопросы обнаружения сервисов, где сейчас какой находится.

ПлюсыМинусы
  • система работает сама по себе
  • единичный выход из строя не приводит к останову системы
  • Развязали производительность clickhouse попилив пополам.
  • Добавили sentry – знаем что ломается между деплоями
  • добавили телеметрию. знаем не тормозит ли связанная система
  • Чудовищно сложно.
  • типичный деплой схемы вносит простой в работу системы. нужно точно понимать что делается в плейбуке и запускать плейбук по частям
  • не зарезервирован сервер башни.
  • нотификация о проблемах в системе требует связности с интернетом нужно проверять есть ли эта связность.
  • логи.
  • диагностика.
  • трап и сислог коллекторы не зарезервированы. плановые работы приводят к останову сбора сислога
  • отсутствие резервирования между датацентрами.


 Попытка масштабирование №5

scale multi-dc


  • No labels