Skip to main content

Обновление/Установка 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) должно быть нечетным (минимум 3). Если, например, хранилища два, то в файле инвентаря укажите в storage: hosts: <полное_доменное_имя_машины>: (этом может быть core, collector) с его IP адресом и значением keeper, по аналогии с другими записями. Например, если используется два хранилища, то конфигурация storage будет выглядеть следующим образом:

image.png

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

image.png

Демонстрационные сервисы
Если Вы хотите, чтобы инсталлятор развернул демонстрационные сервисы, присвойте параметру 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 должно быть уникальным в рамках этого шарда. Пример для четырех серверов на рисунке ниже.

image.png

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

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

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

sudo -i

9. Запустите процесс инсталляции: 

./install.sh distributed.inventory.yml

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

image.png

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

Back to top