Управление неуправляемым и мониторинг критичного

В чужой монастырь со своим уставом не ходят. На очередном месте работы в мои задачи входит создание и последующая поддержка документооборота на платформе Alfresco, попутно ведение других систем. Заведение с предписанными правилам, устоявшимися обычаями и порядками. Многих привычных IT вещей в инфраструктуре нет, но всё работает надежно и всех устраивает. Как человек обладающий интеллектом и зачатками воспитания не буду пытаться нарушить чужие традиции и глобально что-либо менять. Учитывая over 500 рабочих мест, некоторые замечу не всегда рядом и критичность создаваемого сервиса для организации, некоторые вещи сделаю на свой лад. К ним относятся мониторинг и оркестрация.

Большинство рабочих мест располагается в здании на 6-и этажах. Имеются удалённые рабочие места. Парк администрируется разными сотрудниками, некоторые места относятся к другим организациям и могут вообще не иметь ответственного за IT сотрудника. Глобальная сеть и безопасность в зоне ответственности специально обученных людей. DHCP, DNS, AD если и есть то не везде. ITIL/ITSM просто импортные буквы. Операционные системы WindowsXP, WindowsVista, Windows7. Рабочие места могут мигрировать в разные части здания или за его пределы с обязательной сменой IP адреса. Пользователи работают на компьютерах обычно с правами администратора следовательно, могут менять все, включая %COMPUTERNAME%. Смену последнего желательно недопускать т.к. используется для общих принтеров.

Исходные данные и цели

Цели проекта в мониторинге – это проверка на доступность web приложений, снятие параметров с построением графиков java & postgresql & OS, оповещение посредством rss, sms и голосового звонка в критичных случаях.

Основная цель оркестрации – это исключить общение с over 500 пользователями. Иметь возможность оперативного массового изменения параметров, установки пакетов ПО, сертификатов и “мягкие политики — like GPO”.

С учётом стратегических приоритетов государства, ориентированности на полное импортозамещение, завтра на рабочих местах у пользователей документооборота могут оказаться МСВСфера или ROSA, соответственно инструменты управления конфигурацией и мониторинга лучше иметь кроссплатформенные с открытым исходным кодом, веб-интерфейсом управления и нулевой стоимостью внедрения&владения.

Динамический DNS

IP адреса ведутся по правилу: 10.здание.кабин.етрозетка. При смене дислокации рабочего места, меняется и IP адрес. Меняется вручную т.к. DHCP нет, следовательно option 82 не применим. В инвентарных номерах системных блоков могут встречаться дубликаты. Единственное, что относительно неизменно это MAC адрес. К нему и сделаем привязку. Определим шаблон имени рабочего места как РС-{макбезразделителей}. Если на компьютере несколько сетевых подключений будем считать, что Ethernet будет первым, сразу после инсталляции операционной системы. Его адрес будем использовать как константу для %COMPUTERNAME%.

Для работы с сертификатами необходимо иметь имя FQDN (Fully Qualified Domain Name), а из условий следует, что DNS отсутствует. Удобное решение в данной ситуации динамический DNS, он удобен для сопоставления %COMPUTERNAME% с IP адресом и соответственно определением текущего местонахождения рабочего места, если возникнет необходимость личного общения с пользователем.

Первое из решений, для динамического обновления DNS зон клиентом, виделась утилита Nsupdate из пакета Bind для Windows, но в этом случае клиенты имели общий ключ и следовательно могли изменять не только свои записи в зоне. Более безопасным виделось решение, когда клиент отправляет HTTP запрос, а сервер согласно своим правилам вносит изменения. Способ хранения зон в этом варианте очевиден – это SQL база. По умолчанию настроен на обслуживание запросов из БД сервер PowerDNS. Он используется во многих крупных проектах и представляется весьма стабильным. Его и будем использовать.



Для комфортного управления зонами написано много разных интерфейсов к PowerDNS. Мы утвердили в работу powerdns-webinterface

Инструменты управления конфигурацией для автоматизации Windows ПК

Первоначально для централизованного распространения программного обеспечения рассматривались системы инвентаризации. Существующие проверенные решения ocsinventory-ng и Mandriva Pulse имеют в своем функционале возможность установки пакетов. Оба включают возможность интеграции с таким элемент ом ITIL/ITSM как Service Desk (в частности GLPI) удобно, но невнедримо в текущей ситуации. Изменение параметров реестра Windows и деплой сертификатов представляется не иначе как изготовлением инсталляционных пакетов. А эти пакеты пользователь с правами администратора может удалить с машины. Исходя из этого стал рассматривать системы управления конфигурацией.

Puppet считается наиболее распространённым. Он имеет множество модулей и пользовательских интерфейсов. Изменения в конфигурационных файлах(манифестах) для клиентов, последние получают их при очередном обращении к головному серверу, или через запрос от сервера для немедленного исполнения по средствам функции push.
Имеются модули для работы с Windows системами. Поддержка систем WindowsXP прекращена после версии puppet-3.1.1.msi, а текущую puppet-3.7.3.msi запустить не удалось т.к. завязана на вызове системных функций. В старших версиях отсутствуют `факты` как то `system32` и в манифестах необходимо описывать разные сценарии в зависимости от операционной системы. Это всё усложняет использование системы и решено было отказаться в пользу других инструментов.
SaltStack схож с Puppet в том, что использует метод push для связи с клиентами(minion). Мinion не открывает каких-либо портов, а сам подключается к серверу и ждет от него команд, таким образом повышается безопасность сервиса. Если у Puppet есть манифесты для описания конфигураций, то в SaltStack введено понятие `состояние`(state). Изменения произведенные на мастере будут выполнены на всех minion`ах. Стоит обратить внимание, что выполнение state`ов инициируется с мастера, а не самими клиентами как это реализовано в Puppet. Для поддержания актуального состояния в случае длительного отключения minion`а в его файле конфигурации добавлен параметр:
startup_states: 'highstate' (C:\salt\conf\minion)
Состояния — это конфигурационные файлы в формате YAML с расширением sls.

Считывание state`ов начинается с файла top.sls, если не определено другое. Он содержит список файлов .sls для определенных групп.

roto@salt:/etc/salt/files# cat top.sls
base:
# '*':
# Для всех ПК с Windows
 'all_pc':
  - match: nodegroup
  - gr_inventory
  - gr_7z
  - gr_chrome
  - gr_libreoffice
  - gr_klitecodec
  - gr_essentials
# Гарант
 'gr_garant':
  - match: nodegroup
  - gr_garant
  # Консультант+
 'gr_consultant':
  - match: nodegroup
  - gr_consultant

Группы определяются в конфигурационном файле master’а (/etc/salt/master)и позволяют задавать их довольно гибко. Подробнее читайте в документации
В примерах из документации группы определены переменными. Для динамических типа паролей к базам, токенов, хэшей это `подпорки` (pillar) и статических `зерна` (grain). Кроме того переменные можно использовать в описании state`ов и командной строке salt.
roto@salt:/etc/salt/files# salt –G ‘cpuarch:AMD64’ test.ping

В качестве примера листинг `состояния ` антивируса от Microsoft:

roto@salt:/etc/salt/files# cat gr_essentials.sls
{% if grains['cpuarch'] == 'AMD64' %}
   w64_essentials:
    pkg:
     - installed
     {% elif grains['osrelease'] == '7' %}
        w32_essentials:
         pkg:
          - installed
       {% elif grains['osrelease'] == 'XP' %}
         w32xp_essentials:
          pkg:
           - installed
{% endif %}

_{* в парке нет других х64 систем, кроме Windows7}

Установка пакетов ПО производится из репозитария заданного в конфигурационном файле master’а (/etc/salt/master). Описание пакета в файле init.sls, его листинг:

roto@salt:/etc/salt/files/win/repo/w32xp_essentials# cat init.sls
w32xp_essentials:
  4.4.304.0:
    installer: 'salt://win/repo/w32xp_essentials/mseinstall.exe'
    full_name: Microsoft Security Essentials
    locale: ru_RU
    reboot: False
    install_flags: '/q /s /runwgacheck '
    uninstaller: '%ProgramFiles(x86)%\Microsoft Security Client\Setup.exe'
    uninstall_flags: ' /U /S'

Salt master имеет встроенный файловый сервер и может отдавать любые файлы minion`ам. Порты ТСР:

• 4505 #для управления
• 4506 #для передачи файлов

Для SaltStack существует веб-интерфейсы SaltPad и Halite. Первый завести не удалось, а с помощью второго можно просматривать системные журнал сообщений, статус minion`ов, а также посылать им команды.


Во время тестов он показал себя как крайне ненадежное, не полное решение, заметно уступающее пользовательским интерфейсам других систем, в частности Puppet-Dashboard.


Во избежания проблем установил SHELLINABOX.



Итоговый скрипт для установки получился следующим:

Система мониторинга Zabbix

Существует множество систем мониторинга. С Zabbix знаком давно, его и выбрал.

Мониторинг JMX

Начиная с версии 2.0 в zabbix добавлена нативная поддержка для мониторинга JMX. Взаимодействие происходит через API управления JMX приложений через демона, называемого Zabbix Java gateway. Он написан на языке Java.

Мониторинг PostgreSQL

Согластно wiki PostgreSQL, решений для мониторинга написано не мало. Я остановился на libzbxpgsql (Lib-Zabbix-PostgreSQL). Это изначально скомпилированный модуль написанный на C для zabbix агента и xml шаблон для сервера. Преимущество перед скриптами очевидно, это один процесс и отсутствие внешних зависимостей.


Данная статья составлена как документация для моего текущего работодателя. Комментарии, замечания и указания на неточности приветствуются.