Обложка: Средства системного администратора Linux

Средства системного администратора Linux

Совсем недавно (5-8 лет назад) системный администратор Linux был ограничен в средствах администрирования и автоматизации. Где-то можно было обойтись самописными скриптами на bash, Python, Perl, а где-то уже требовалось решение уровня энтерпрайз от таких гигантов, как IBM, Oracle или RedHat.

С развитием Open Source стала развиваться и автоматизация в администрировании. На замену самописным скриптам и программам пришли готовые решения. Эти средства появились не на пустом месте. Это были решения по автоматизации существующих задач любого системного администратора. Зачастую это решения, развиваемые по принципу KISS (акроним для «Keep it simple, stupid»), которые получали большие перспективы развития и распространения.

Конечно, лет 5-10 назад средства централизованного администрирования в Windows были развиты лучше, чем в Linux. Это было небезосновательно, т.к. Windows был широко распространён как среди домашних пользователей, так и в офисной/серверной среде. Microsoft, похоже, не предполагала что когда-то будет соперничать с Linux в серверном сегменте. Но не будем здесь углубляться в эти застойные времена для Microsoft, когда главой корпорации был Стив Балмер.

Администрирование

Одним из часто используемых средств администрирования мною и коллегами до появления ansible/puppet/chef был cssh (Cluster SSH).

Скриншот работы cssh

Cluster SSH в работе

Работа с cssh была проста, не нужно было повторять одни и те же действия на каждом сервере по очереди, всё сводилось к мультиплексированию ввода в терминале на группу SSH подключений. У этого решения, конечно, были очевидные недостатки — необходимо было взаимодействие с администратором, его контроль. Сегодня средства автоматизации ушли намного дальше в своих возможностях и функциональности и зачастую расширяются плагинами.

Одно из наиболее распространённых средств автоматизации в администрировании — Ansible. Оно позволяет автоматизировать практически любые задачи системного администратора. Для работы достаточно SSH доступа к хостам. На сайте есть обзорная статья про Ansible, как его настроить и работать. Проект развивался независимо и вскоре был куплен компанией RedHat.

Мониторинг

После настройки сервера и введения его в эксплуатацию для обеспечения SLA и не только необходимо уделить внимание мониторингу.

Мы часто разделяем мониторинг на два отдельных компонента:

  • мониторинг с оповещениями,
  • статистика по показателям.

Нет необходимости настраивать предупреждения по всем показателям в системе, но собирать показатели системы для статистики и дальнейшего выявлений аномалий — полезно и удобно.

  1. Zabbix/Nagios/Icinga — используем для получения событий агентами и уведомлений по триггерам.
  2. Grafana + InfluxDB — в эту связку входят также Chronograf, Kapacitor, Telegraf.
    • InfluxDB — time series база данных, принимает на вход данные с различных источников. Имеет широкий функционал возможностей для работы с данными.
    • Chronograf — веб-панель с дашбордами и система управления Influxdb, Kapacitor.
    • Kapacitor — обработчик событий.
    • Telegraf — агент, отправляет данные с удалённых систем.
    • Grafana — всем известная система построения дашбордов/графиков.
Схема компонентов InfluxDB

Компоненты InfluxDB

Также в категории мониторинга стоит обратить внимание на Netdata. Это одновременно и агент, и система мониторинга в реальном времени с дашбордом для просмотра статистики, предварительно настроенными графиками и триггерами. После установки остаётся настроить лишь способы оповещений с указанием канала передачи.

Netdata — это «швейцарский нож» в системе мониторинга, обладает широкой функциональностью, поддержкой модулей на Python, Go и не только.

Скриншот дашборда Netdata

Дашборд Netdata

Централизованное управление пакетами

В качестве централизованного управления набором ПО и его обновлениями мы использовали RedHat Spacewalk.

Скриншот интерфейса RedHat Spacewalk

Интерфейс RedHat Spacewalk

С выходом RHEL 7 RedHat провели обновление, вследствие чего заменили Spacewalk на RedHat Satellite, который во многом напоминает Foreman. Для перехода на RedHat Satellite необходимо было бы перенастраивать уже работающие с RedHat Spacewalk системы, отлаживать новое решение (RedHat Satellite) и почти гарантированно бороться с новыми проблемами.

Зачастую в госструктурах и энтерпрайзе широко использовались решения RedHat. И тут со второго плана выходит компания Oracle, которая занималась развитием дистрибутивов Oracle Enterprise Linux/Oracle Unbreakable Enterprise Kernel.

Это продукты, основанные на кодовой базе RedHat Enterprise Linux, но с большим количеством доработок под собственные нужды, в которые том числе входило создание и поддержка среды для, наверное, основного продукта компании Oracle — Oracle Databases.

Но, в отличие от RedHat, дистрибутив которого скачать можно было только по подписке (лицензировании), не говоря уже об обновлениях, Oracle предоставляет это бесплатно. Именно Oracle взялся поддерживать и продолжать развитие Oracle Spacewalk, который вскоре был обновлён в Oracle Linux Manager.

Логирование

С увеличением количества обслуживаемых хостов возникает необходимость централизованного сбор логов. Для этих задач отлично подходят уже готовые Open Source решения, которые мы используем:

Агенты — rsyslog, syslog-ng (доступны в большинстве дистрибутивов)

Агрегаторы логов:

  • Loki (Prometheus),
  • Graylog2,
  • Logstash,
  • ELK.

При небольшом количестве администрируемых хостов можно обойтись syslog-ng как централизованным хранилищем для файлов логов, который будет принимать сообщения на 514 UDP порт. Он умеет раскладывать сообщения по директориям в зависимости от источника (FQDN/IP-адреса), сервиса, дате и прочее.

Резервное копирование

Для резервного копирования выбор достаточно прост. Где-то достаточно rsync + tar (синхронизации и сжатия), а где-то требуется Bacula/Bareos.

Схема работы Bareos

Работа Bareos

В резервном копировании есть достаточно хорошие проприетарные решения, например, «Veeam backup». Если вы используете виртуализацию VMWare, то здесь Veeam упрощает резервное копирование и предоставляет поддержку.

Также в своих решениях мы используем резервное копирование для /etc директории — etckeeper. Он позволяет автоматизировать сохранение содержимого каталога /etc в хранилище системы контроля версий (VCS), отслеживает, когда ваш пакетный менеджер сохраняет изменения в /etc при установке или обновлении пакетов.

Помещение /etc под контроль версий сейчас рассматривается как лучшая практика в индустрии. Преимуществом etckeeper является то, что он делает этот процесс безболезненным, насколько это возможно, и удобным. При наличии незакоммиченных изменений etckeeper будет ежедневно их сохранять, если это не отключено, и отправлять в централизованный репозиторий.

Иногда случается так, что подготовленный к установке/обновлению пакет программ может перезаписать существующие файлы в /etc , т.к. некоторые заказчики пользуются сторонними службами/пакетами. Etckeeper умеет фиксировать конфигурацию перед установкой пакетов и после, что значительно облегчает работу.

Постскриптум

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

Хинт для программистов: если зарегистрируетесь на соревнования Huawei Cup, то бесплатно получите доступ к онлайн-школе для участников. Можно прокачаться по разным навыкам и выиграть призы в самом соревновании.

Перейти к регистрации