Обновление/Установка 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

      
      
7. Отредактируйте файл инвентаря с командой: 

   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. Провести первичный траблшутинг по этому документу и сообщить ответственному инженеру Лаборатории Касперского в случае неуспеха.