Доклад Алексея Лесовского на HighLoad++ 2014.

1. PostgreSQL:
Ups,
Devops.
Алексей Лесовский

2. О себе
• Алексей Лесовский
• PostgreSQL-Consulting.com
• Консалтинг, техническая поддержка, тренинги
• Вопросы архитектуры, производительности и масштабирования

3. Мы поговорим:
• об актуальности проблемы в сфере управления конфигурациями
и автоматизацией задач в рамках эксплуатации СУБД
• про задачи обслуживания баз данных
• про автоматизацию задач в области обслуживания баз данных
• о проблемах связанных с автоматизацией и управлением
конфигурациями
• о том где нужно и где нельзя использовать автоматизацию
• об особенностях инструментов в аспекте применения к СУБД
• о том как все это применить на практике
• horror stories

4. Актуальность проблемы.
• качественный и количественный рост оборудования
• необходимость сокращения времени на “деплой” и
сопровождение
• появление devops практик и инструментов
• mission-critical задачи

5. Задачи обслуживания БД.
• поддержка конфигурации серверов БД
• управление 3rd-party ПО
– skytools, pgbouncer, pgpool-II, postgis, tzdata, etc
• развертывание репликации
– SR/BDR, slony, londiste, bucardo, etc
• обновление и upgrade
– minor/major update (pg_upgrade)

6. Задачи обслуживания БД.
• балансировка запросов от приложения
– haproxy, pgpool-II
• switchover/failover
• анализ отчетов и мониторинг
– pgbadger/pgfouine, zabbix/nagios, pgCluu/PoWA
• routine maintenance
• резервное копирование и валидация резервных копий

7. Задачи обслуживания БД.
• Итого:
– задачи типовые
– задачи ручные

8. Автоматизация задач.
• Итого:
– "X" < 4: мало серверов - все можно сделать руками
– "Х" > 4: много серверов - тут начинается рутина
• Автоматизация:
– экономит время при выполнении рутинных задач
– устраняет вероятность ошибки в процессе настройки
– унификация и однобразие внутри инфраструктуры

9. Вероятные проблемы.
• Первичные:
– База данных это один из важнейших элементов
инфраструктуры
– Операции DBA зачастую носят единоразовый характер
• Вторичные:
– Недоверие со стороны штатных администраторов
– Гетерогенная инфраструктура
– Ограниченные возможности внутри среды

10. Варианты решения.
• предварительное тестирование
• ad-hoc операции
• дипломатия и переговоры
• тщательный выбор инструмента

11. Где автоматизировать
• Управление ПО, версии и конфигурация сервисов
– установка/удаление/обновление пакетов
– изменение файлов конфигурации
– управление сервисами (start/stop/reload/restart)
● Развертывание репликации
– установка пакетов
– конфигурирование сервисов
– запуск сервисов
– проверка успешности

12. Где автоматизировать
• Балансировка запросов от приложения
– изменения конфигурации
– service restart (haproxy,pgpool-II)

13. Где автоматизировать
• Switchover/Failover
• pre-run check
– проверка соединений (с клиентов/бэкендов, между узлами)
– приостановка соединений (pgbouncer)
– переключение бэкендов
• switchover/failover (restartful или restartless)
• post-run checks
– проверка успешности (соединение, запись тестовой
таблицы)
– возобновление соединений

14. Где автоматизировать
• Обновление и upgrade (очень деликатно)
• pre-update задачи
– остановить приложения
– перевести бэкенды на другие серверы
– отменить выполняющиеся транзакции
• update/upgrade
• post-update задачи
– вернуть всех обратно (клиенты, бэкенды)

15. Где НЕ автоматизировать
• Анализ отчетов и мониторинг
– индивидуальный анализ запросов
– ручная коррекция запросов
– создание индексов
• Routine maintenance
– поиск и удаление неиспользуемых/дублирующихся индексов
– обнаружение и устранение bloat
• Резервное копирование и валидация бэкапов
– здесь легко справится cron

16. Инструменты.
• shell/perl/python/... + ssh/pdsh/clusterssh/...
• puppet, chef, cfengine, salt, ansible, ...

17. Инструменты.
• Shell/Perl/Python/... + ssh/pdsh/clusterssh/...
– самостоятельная поддержка
– отсутствие регламента написания кода
– высокая вероятность ошибок
– высокие административные издержки

18. Инструменты.
• Chef/Puppet/Cfengine/Salt/Ansible
– унификация инфраструктуры
– единообразие версий, конфигов, точек и опций
монтирования, и т.д.
– хорошо приспособлены для работы в гетерогенных
инфраструктурах
– поддержка community
– дополнительные затраты на сервера
– снижение административных издержек
– веб-интерфейс (как правило на коммерческой основе)

19. Проблема выбора.
• Chef/Puppet/CFEngine
– ориентированы на разработчиков
– высокие требования к знанию языка описания рецептов
– длинная кривая обучения
– архитектура клиент/сервер

20. Проблема выбора.
• Salt/Ansible
– ориентированы на системных администраторов
• Salt
– архитектура клиент/сервер
– надежен, мастер-сервера хорошо масштабируются
• Ansible
• agentless архитектура, нет выделенного сервера для хранения
рецептов
• нужно грамотно организовать доступ к репозиторию
• до жути простой (extremely simple)

21. Как начать это делать.
• определения круга и перечня задач
• оценка времени затрачиваемого на задачи
• выбор инструмента
– есть ли ресурсы на развертывание
– есть ли время на изучение
• написание рецептов на тестовом окружении
– наработка опыта эксплуатации
– убеждение подходит ли оно нам или нет
• написание рецептов для production

22. Horror stories.
• выполнение задач не там где это должно быть
• Помещение левых серверов в пул балансировки
• Ошибки в регулярных выражениях
• pg_upgrade: Удаление строй директории до запуска сервиса
• ALTER TABLE ... ADD COLUMN ... DEFAULT ...;
• Coworker says "I'm going to do some clean-up on the server." Two
minutes later, "Oh crap. I had removed pg_xlog directory"
• Деплой на staging с production конфигами
• Случайная вставка «init 6 » в корневое окно cssh.
• Ложный запуск autofailover процедуры

23. Lessons learned.
• Наличие дежурных инженеров (администраторы, разработчики)
• Наличие отлаженных процедур по устранению аварийных
ситуаций (runbooks)
• Наличие тестового окружения для проверки
• Семь раз проверь, один — отрежь
• Никакая техника не спасет если в кабине сидит обезьяна (с)

24. Вопросы?

25. Спасибо!
• http://www.postgresql-consulting.com
• alexey.lesovsky@postgresql-consulting.com