Обновление/Установка KUMA версии до 2.0.Х (распределенная инсталляция)

1. Создайте резервную копию ресурсов и сертификатов, см. советующий раздел в этой книге.
2. Распакуйте архив (операции выполняются на ядре системы KUMA): tar -xvf kuma-ansible-installer-(ВЕРСИЯ).tar.gz
3. Перейдите в распакованную папку: cd kuma-ansible-installer
4. Добавить файл лицензии в папку kuma-ansible-installer/roles/kuma/files и переименовать на license.key: cp ПУТЬ_ДО_КЛЮЧА*.key roles/kuma/files/license.key
5. Выполните команду копирования шаблона (либо подставьте ранее использованный файл при обновлении): cp distributed.inventory.yml.template distributed.inventory.yml
6. Добавьте публичный ключ SSH на все удаленные хосты:
   1. На удалённых хостах в конфигурации сервиса SSH должна быть включена опция удаленного входа от суперпользователя!
   2. Сгенерируйте ключ командой (без указания пароля и доп. параметров): ssh-keygen -t rsa
   3. Добавьте ключ на удаленный хост по ssh: ssh-copy-id login@remote_host_fqdn
   4. Проделать операцию выше с доменом ядра системы («на самом себе»)
7. Отредактируйте файл инвентаря с командой: nano distributed.inventory.yml

В случае ручной правки файла старайтесь не добавлять лишних пробелов.

Количество keeper (ZooKeeper) должно быть кратно трем. Если, например, хранилища два, то в файле инвентаря укажите в storage: hosts: <полное_доменное_имя_машины>: (этом может быть core, collector) с его IP адресом и значением keeper, по аналогии с другими записями. Например, если используется два хранилища, то конфигурация storage будет выглядеть следующим образом:

Для развертывания отдельного одного хранилища без кластера используйте следующие настройки в distributed.inventory.yml:

 

Демонстрационные сервисы
Если Вы хотите, чтобы инсталлятор развернул демонстрационные сервисы, присвойте параметру deploy_example_services значение true (Только для новых инсталляций).

Генерация содержимого файла /etc/hosts
Если целевые машины НЕ зарегистрированы в DNS-зоне вашей организации, то присвойте параметру generate_etc_hosts значение true и для каждой машины в инвентаре, замените значения параметра ip 0.0.0.0 на актуальные IP-адреса.

Список целевых машин
В файле определены 4 группы, именованные аналогично ключевым компонентам KUMA: core, collector, correlator, storage. Помещая целевую машину в одну из групп, вы инструктируете инсталлятор установить на нее соответствующий компонент KUMA. В каждой группе замените строки с суффиксом *.example.com на актуальные имена хостов целевых машин.

• Группа core. Может содержать только одну целевую машину.
• Группа collector. Может содержать одну или несколько целевых машин.
• Группа сorrelator. Может содержать одну или несколько целевых машин.
• Группа storage. Может содержать одну или несколько целевых машин. Каждая машина должна иметь одну из следующих комбинаций параметров:
  • shard + replica + keeper
  • shard + replica
  • keeper
    

Кластер - логическая группа машин, обладающих всеми накопленными нормализованными событиями KUMA. Подразумевает наличие одного или нескольких логических шардов.

Shard (шард) - логическая группа машин, обладающих некоторой частью всех накопленных в кластере нормализованных событий. Подразумевает наличие одной или нескольких реплик. Увеличение количества шардов позволяет: накапливать больше событий за счет увеличения общего количества серверов и дискового пространства; поглощать больший поток событий за счет распределения нагрузки, связанной со вставкой новых событий; меньшить время поиска событий за счет распределения поисковых зон между несколькими машинами.

Replica (реплика) - машина, являющаяся членом логического шарда и обладающая одной копией данных этого шарда. Если реплик несколько - копий тоже несколько (репликация данных). Увеличение количества реплик позволяет: улучшить отказоустойчиовость; распределить общую нагрузку, связанную с поиском данных, между несколькими машинами (однако для этой цели лучше увеличить количество шардов).

Keeper - опциональная роль реплики, подразумевающая ее участие в координации репликации данных на уровне всего кластера. На весь кластер требуется хотя бы одна реплика с данной ролью. Рекомендуемое количество таких реплик - 3. Число реплик, участвующих в координации репликации, должно быть нечетным.

Если указаны параметры shard и replica, то машина является частью кластера и принимает участие в накоплении и поиске нормализованных событий KUMA. Если дополнительно указан параметр keeper, то машина также принимает участие в координации репликации данных на уровне всего кластера.

Если указан только параметр keeper, то машина не будет накапливать нормализованные события, но будет участвовать в координации репликации данных на уровне всего кластера. Значения параметра keeper должны быть уникальными.

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

Если хранилище одно, то оставьте параметры shard + replica + keeper, как у kuma-storage-1.example.com

Перед началом установки инсталлятор KUMA выполнит валидацию инвентаря и укажет на ошибки, если таковые были допущены.

8. Входим в ОС из-под суперпользователя (root): sudo -i

9. Запустите процесс инсталляции: ./install.sh distributed.inventory.yml

10. Выполните настройку storage на использование двух хранилищ. В точках назначения нужно добавить URL второго хранилища, (если используются отдельные keeper, то их не нужно указывать в точках назначения) пример ниже:

Корректность работы можно проверить, перейдя во вкладку События и нажав на значок увеличительного стекла (Поиск), должны появиться события, поступающие KUMA или Сообщение «События не найдены». Если при поиске возникает ошибка, то необходимо проверить статусы сервисов в веб интерфейсе KUMA. Провести первичный траблшутинг по этому документу и сообщить ответственному инженеру Лаборатории Касперского в случае неуспеха.