Борьба с избыточным логированием в Openstack

    Содержание: Душераздирающая скорость роста auth.log на хостах с neutron-plugin-openvswitch-agent. Анализ причин, метод устранения. Немного про работу sudo, PAM и его сессии.



    О чём пойдёт речь? Openstack — платформа для построения облаков. Neutron — название его подсистемы отвечающей за сеть, модной хипстерской вебдванольной, cчитающейся более совершенной и функциональной, чем первая попытка под названием nova-networking. openvswitch-plugin — это плагин к neutron, реализующий его функциональность при помощи Open vSwitch — программного коммутатора, позволяющего делать умные штуки, вроде GRE-туннелей, бондинга и мирроринга портов, наложение правил на порт внутри виртуального коммутатора в стиле iptables и т.д.

    neutron-openvswitch-plugin-agent — одна из компонент этого плагина, работающая на всех хостах, которые имеют хоть какое-то реальное отношение к передаче сетевого трафика виртуалок. Иными словами, это все compute-узлы (там, где работают виртуалки), networking-узлы (которые делают «интернет» для виртуалок). Из списка выпадают только сервера API и прочие служебные сервера. С учётом, что большая часть облака состоит из compute + networking, можно, слегка огрубляя, говорить, что этот neutron-openvswitch-plugin-agent установлен на всех хостах. Logstash — система централизованной сборки логов, Elasticsearch — база данных для работы с этими логами.

    Для своевременной реакции на проблемы ПО, все логи всех приложений должны собираться и анализироваться системой мониторинга. Подробнее про это у нас уже было написано. Однако, даже хорошего может быть слишком много. Быстро обнаружилось, что большая часть собираемого с хостов — нелепые сообщения следующего вида:

    server sudo:  neutron : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf ovs-vsctl --timeout=2 --format=json -- --columns=name,external_ids list Interface
    server sudo: pam_unix(sudo:session): session opened for user root by (uid=108)
    server sudo: pam_unix(sudo:session): session closed for user root
    server sudo:     nova : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/nova-rootwrap /etc/nova/rootwrap.conf chown 107 /var/lib/nova/instances/_base/421f0808ac5dd178bc574eff6abe8df949edc319
    server sudo: pam_unix(sudo:session): session opened for user root by (uid=107)
    server sudo: pam_unix(sudo:session): session closed for user root
    


    Эти сообщения повторялись каждые две (!) секунды. С каждого сервера, на котором есть агент. Получается, что с каждой сотни серверов мы будем получать по 730 Гб мусора в год. Логи собираются в Elasticsearch, то есть, это, пардон, терабайты в базе данных. Удачи в query-запросах, так сказать.

    С одной стороны весь этот хлам так и просится на отключение.

    С другой стороны, полное отключение auth.log или его жёсткая локальная ротация — плохое решение, потому что информация о подозрительной активности должна собираться и храниться как можно тщательнее, причём, желательно, вдалеке от жадных ручек скомпрометированного хоста (ежели такой объявится).

    Помимо neutron-plugin-openvswitch-agent рядом ещё засветилась и nova-compute (управлялка виртуализаторами в Openstack), хоть и не так часто.

    PAM и его сессии


    Вероятнее всего, многие читатели пользуются sudo. Вероятнее всего, многие из тех, кто пользуются sudo, особо не задумываются, что происходит при его запуске.

    Когда sudo спрашивает пароль, оно может запросить аутентификацию у пользователя. Чаще всего это пароль, но, например, у меня на ноутбуке — это сканер отпечатков пальцев (который не используется при логине, т.к. пароль при логине расшифровывает диск, но отлично подходит для безопасного sudo). Чтобы не реализовывать код для работы с паролями и прочими вещами в каждой программе, был создан PAM — система аутентификации пользователя, позволяющая проверять, что пользователь знает пароль, без самостоятельного написания парсера /etc/shadow и поддержки всех других видов авторизации (включая LDAP, kerberos, OpenID, OTP и любые другие безумные вещи, которые только придумают).

    PAM-сессии — это набор ритуалов, которые выполняет PAM при логине пользователя. Среди всего прочего, в ритуал входит запись в auth.log.

    Вообще говоря, PAM-сессии не обязательны для нормальной работы. Запросить проверку пользователя и создать ему сессию — три большие разницы (третья — это функция «закрыть сессию»). Все уважающие себя программы их используют. Но в нашем случае это вызывает некоторые проблемы.

    Подробнее про PAM, историю его возникновения и принципы работы есть на сайте IBM, для дотошных — Linux-PAM System Administration Guide.

    Но зачем так часто?



    Напомню, проблема состоит в том, что записи в логах от sudo и pam_session происходили почти постоянно — каждые две секунды.

    Что за сообщения про pam_session мы уже выяснили. Осталось выяснить, зачем neutron'у (и немножко nova) запускать что-то так часто, да ещё и с sudo?

    В модели Openstack'а компоненты не особо стремятся изучать тонкости нижележащих технологий. Вместо того, чтобы получать информацию об изменениях от ovs-vswitchd, libvirtd и т.д., и долго разбираться «что бы это могло значить и надо ли на это реагировать?» используется куда более грубый и эффективный подход: когда api-сервер какой-либо подсистемы хочет узнать состояние сервиса, он посылает ему через очередь сообщений запрос — а сервис, в свою очередь, запрашивает у использующихся программ их текущее состояние.

    На выходе сервер имеет кучу информации: во-первых, что сервис ещё жив (heartbeat'ы), во вторых, информацию о текущей конфигурации. Без всяких нюансов «пропустили Очень Важное Обновление Состояния».

    Для адекватной работы neutron'а ему надо знать состояние портов. В контексте openvswitch-plugin-agent'а — это запуск ovs-vsctl show и им подобных для получения текущего состояния всех портов.

    К сожалению, это требует привилегий.

    Для управления привилегиями в Openstack используется свой врапер — root-wraper, который осуществляет более тонкую проверку аргументов для запуска, чем обычное sudo. Но сам root-wraper написан на Питоне (как и всё в Openstack), а на интерпретируемые файлы ставить suid нельзя. В качестве простого и разумного решения root-wraper вызывается как sudo root-wraper.

    И что делать?


    Наша цель:
    1. Не сохранять информацию о выполнении root-warp пользователями nova/neutron через sudo
    2. Сохранять всю остальную информацию.


    Первый пункт сводится к двум независимым вопросам: отключить запись информации от sudo, и отключить запись информации от pam_session.

    Предварительно: если используете старые дистрибутивы, обновите sudo до версии 1.8.7 или новее (Ubuntu 12.04 идёт с 1.8.3, в Ubuntu 14.04 уже всё хорошо).

    Далее — для neutron, в файле /etc/sudoers.d/neutron_sudoers заменяем строчки:
    - Defaults:neutron !requiretty
    + Defaults:neutron !requiretty, !syslog, !pam_session
    

    Для nova изменения аналогичные, в файле /etc/sudoers.d/nova_sudoers.

    Краткая справка по синтакису sudoers, для тех, кому не нравится BNF из man-страниц — восклицательный знак инвертирует значение, Defaults: применяются к конкретной секции.
    • syslog — включает логинг в syslog, !syslog, соответственно, отключает.
    • pam_session — указывает создавать новую сессию PAM, !pam_session — говорит не создавать новую сессию. Именно для pam_session нам и потребовалась новая версия sudo.


    Управление частотой опроса neutron



    Очевидная мысль — а давайте понизим частоту опроса? С практической точки зрения снижение частоты означает увеличение интервала между «сделали» и «увидели изменения». Если две секунды кажутся слишком частыми, то можно сделать, например, десять. Но ставить туда минуту — это уже перебор (с интерактивностью беда будет). При этом десять секунд нас особо не спасут — вместо 43 тысяч вызовов в сутки (на каждый сервер) у нас будет почти 9 тысяч.

    За снижение частоты это отвечает переменная конфига у neutron-server: report_interval (в секундах).
    Webzilla
    61,00
    Компания
    Поделиться публикацией

    Похожие публикации

    Комментарии 15

      +1
      Любопытно, сколько % процессорной мощности продуктивных хостов виртуализации отъедается такими вот, подобными этому, питоновыми костылями опенстэка?
        +1
        Тут если уж наезжать на съедаемые ресурсы — наезжать надо не на реализацию каких-то компонентов на питоне, а в целом на ряд архитектурных решений — типа того, что в общем-то не очень здравая мысль запускать с периодом в 2 секунды портянку из трех бинарников.
          +3
          1-3%. На удивление, меньше, чем, например, оверхед от виртуальной памяти у операционной системы. 2 секунды для компьютера — это очень много. А с учётом, что это константный оверхед, не зависящий от нагрузки, им можно пренебречь.
          +2
          Справедливости ради — это решение не специфично для OpenStack, а подходит и для кучи других подобных же штуковин, стоящих в кроне или в каком-то частотном опроснике, например, из мониторинга. Я помню, что года 2-3 назад подкручивал подобное для:

          • OpenVZ'шных скриптов, вызываемых vzeventd
          • sar'овского /usr/lib64/sa/sa1
          • почти всех проверок мониторинга для железа (всяких вызовов einarc, smartctl, ipmitool и т.п.)

          Хотя, конечно, у меня объемы несравнимо меньшие.
            0
            А что не так с vzeventd скриптами и почему они должны спамить? Есть ли багрепорт на bugzilla.openvz.org?
            0
            А как вам вариант скомпилировать python'овский root-wrapper и таки поставить на него suid?
              0
              Какую проблему это решит?
                0
                Но сам root-wraper написан на Питоне (как и всё в Openstack), а на интерпретируемые файлы ставить suid нельзя. В качестве простого и разумного решения root-wraper вызывается как sudo root-wraper.
                  0
                  Изменение схемы дистрибьюции (добавление «компиляции» питона) должно решать что-то большее, чем пара строчек в логе. Я это к тому, что такие изменения очень инвазивные, и должны быть нацелены на что-то глобальное. sudo /usr/bin/root-wraper вполне разумный подход.
                    0
                    Пожалуй вы таки правы :)

                    //Кстати, забавно, мои глаза прямо таки избегали папочки /etc/sudoers.d, спасибо что упомянули о ней в статье (пойду разгребу свой один слегка разросшийся конфиг).
              0
              Вообще в этом весь OpenStack — набор костылей и абсолютно разрозненных технологий. Все адекватные инженеры и архитекторы стремятся к гетерогенности (1 вендор, 1 протокол, 1 тип железа, 1 кодовая база на все), а тут тотальная гетерогенщина и костыли для костылей, на которых костыли работают.

              Точнее ой, не работают :) Ну или приведите пример реально работающего крупного провайдера на OpenStack.
                +1
                Вся идея опенстека — vendor-agnostic. Это очень интересная идея и она напоминает отношения операционной системы и железа. Фичи железа либо ложатся на железо, либо игнорируется, либо, если фича ну очень вкусная, под неё создаётся отдельный класс устройств. Но ОС не подстраивается под мелкие фичи каждой железки.

                Насчёт крупных инсталляций — большинство гигантов либо из pre-openstack, либо не занимаются iaas.

                Среди второго эшелона OpenStack практически единственное multi tenant решение, которое можно поднять за разумное время и резумное количество ресурсов программистов.
                  0
                  OpenNebula?
                    0
                    Сплошной энтерпрайз. Публичность там приделана с боку.

                    Разница между энтерпрайзом и публичностью в том, что в энтерпрайзе стейкхолдеры операторов инфраструктуры и пользователей одни, а в публичном — разные. Причём пользователи могут быть разных стейкхолдеров, в том числе враждебных (злой хаккир Вася арендовал виртуалочку и щипает соседей).

                    Openstack же кровь от крови multi-tennant, причём в самом агрессивном виде multitennant, что там даже возникают обратные проблемы — как бы нам «двух теннатов подружить».

                    Если мы говорим про публичные (ака провайдерские) проекты, то openstack'у просто нет альтернатив. Для приватных их много, и будет большим преувеличением сказать, что в приватных облаках openstack наиболее удобен.
                  0
                  Пример крупного провайдера на OpenStack — internap, плюс недавно купленный этим-же internap-ом iWeb

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое