Привет, коллеги!

Если вы когда-нибудь просыпались среди ночи от алертов о том, что «всё упало», но не могли понять почему — эта статья для вас. Поговорим о том, как построить нормальный мониторинг и перестать гадать на кофейной гуще.

В современном мире, где многие компании переходят на облачные технологии и используют managed-сервисы, важно понимать, какие метрики действительно необходимо мониторить самостоятельно, а какие можно оставить на усмотрение провайдера. Managed-ресурсы предоставляют множество преимуществ, включая автоматическое управление инфраструктурой и встроенные инструменты мониторинга. Однако это не освобождает вас от ответственности за мониторинг критичных для бизнеса метрик.

В современной инфраструктуре нет недостатка в решениях для балансировки и межсервисных коммуникаций. Почти все используют nginx, HAProxy, есть адепты Treafik, а публичные облака предлагают Load Balancer как сервис. Но что делать, если инструменты не справляются с ростом масштабов и необходимо автоматизируемое cloud-native-решение?

Я Дмитрий Самохвалов, архитектор в K2 Cloud. В этой статье поделюсь, как мы из-за ограничений старых систем для динамической конфигурации перешли с работающих решений nginx и HAProxy на модный Envoy. Расскажу, почему сочли это решение подходящим, какие возможности есть у Envoy, каким был опыт внедрения и оставлю рекомендации для эффективного перехода. Будет полезно разработчикам cloud-native-приложений и инфраструктуры, а также всем, кто хочет создать единое платформенное решение для взаимодействия сервисов и инфраструктуры.

ansistrano.deploy и ansistrano.rollback — роли Ansible, предназначенные для управления процессом развертывания приложений, созданных на скриптовых языках программирования (например, PHP, Python и Ruby). По сути это реализация Capistrano в Ansible.

Использование Ansistrano дает следующие преимущества:

• откат за секунды (с ролью ansistrano.rollback);
• настройка процедуры развертывания с использованием методов-обработчиков событий «до» и «после» критически важных шагов;
• оптимизация использования дискового пространства за счет хранения ограниченного количества релизов;
• выбор между SCP, RSYNC, GIT, SVN, HTTP Download или S3 GET-стратегиями развертывания (в дополнение возможно использование unarchive).

Не так давно ребята из LINBIT представили свое новое SDS-решение — Linstor. Это полностью свободное хранилище в основе которого используются проверенные технологии: DRBD, LVM, ZFS. Linstor сочетает в себе простоту и хорошо проработанную архитектуру, что позволяет добиться стабильности и достаточно внушительных результатов.

Сегодня я хотел бы рассказать про него чуть подробнее и показать насколько просто его можно интегрировать с OpenNebula используя linstor_un — новый драйвер, который я разработал специально для этой цели.

Linstor в сочетании с OpenNebula позволяет построить быстрое и надежное облако, которое можно без проблем развернуть на собственной инфраструктуре.

Знакомьтесь: Ceph

Итак, как пользоваться:

Полнотекстовый поиск даёт возможность искать документы по текстовому содержимому. Такая необходимость может возникнуть, когда система содержит много текстовых сущностей, а пользователям требуется учитывать эти данные во время поиска. Мы столкнулись с подобной ситуацией при разработке решения для документооборота*. Данные системы хранятся в MS SQL Server или PostgreSQL, а гибкий атрибутивный поиск позволяет находить документы по различной мета-информации. Однако со временем этого стало недостаточно. Перед нами встала задача: научиться искать документы по текстовым свойствам и приложенным файлам.

Лирика

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

Summary

Announced: 2010-05-20
Credits: 80sec
Affects: сайты на ngnix+php с возможностью загрузки файлов в директории с fastcgi_pass

Background

location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
    include fastcgi_params;
}

В процессе эксплуатации систем с SELinux я выделил несколько интересных кейсов, решения которых вряд-ли описаны в Интернете. Сегодня я решил поделиться с вами своими наблюдениями в надежде, что число сторонников SELinux еще немного возрастет :)

Старые методы по-прежнему работают

grep 'authentication failures' /var/log/auth.log