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