PostgreSQL: ups, ops, devops.

Slides from my talk at Highload++ 2014 Moscow, Russia

Transcript

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 зачастую носят единоразовый характер – ad-hoc операции • Недоверие со стороны штатных администраторов – дипломатия и переговоры • Гетерогенная инфраструктура – тщательный выбор инструмента • Ограниченные возможности внутри среды – тщательный выбор инструмента
10. Где автоматизировать • Управление ПО, версии и конфигурация сервисов – установка/удаление/обновление пакетов – изменение файлов конфигурации – управление сервисами (start/stop/reload/restart) • Развертывание репликации – установка пакетов – конфигурирование сервисов – запуск сервисов – проверка успешности
11. Где автоматизировать • Балансировка запросов от приложения – изменения конфигурации – service restart (haproxy,pgpool-II)
12. Где автоматизировать • Switchover/Failover • pre-run check – проверка соединений (с клиентов/бэкендов, между узлами) – приостановка соединений (pgbouncer) – переключение бэкендов • switchover/failover (restartful или restartless) • post-run checks – проверка успешности (соединение, запись тестовой таблицы) – возобновление соединений
13. Где автоматизировать • Обновление и upgrade (очень деликатно) • pre-update задачи – остановить приложения – перевести бэкенды на другие серверы – отменить выполняющиеся транзакции • update/upgrade • post-update задачи – вернуть всех обратно (клиенты, бэкенды)
14. Где НЕ автоматизировать • Анализ отчетов и мониторинг – индивидуальный анализ запросов – ручная коррекция запросов – создание индексов • Routine maintenance – поиск и удаление неиспользуемых/дублирующихся индексов – обнаружение и устранение bloat • Резервное копирование и валидация бэкапов – здесь легко справится cron
15. Инструменты. • shell/perl/python/... + ssh/pdsh/clusterssh/... • puppet, chef, cfengine, salt, ansible, ...
16. Инструменты. • Shell/Perl/Python/... + ssh/pdsh/clusterssh/... – высокая гибкость – самостоятельная поддержка – отсутствие регламента написания кода – высокая вероятность ошибок – высокие административные издержки
17. Инструменты. • Chef/Puppet/Cfengine/Salt/Ansible – унификация инфраструктуры – хорошо приспособлены для работы в гетерогенных инфраструктурах – поддержка community – дополнительные затраты на сервера – снижение административных издержек – веб-интерфейс (как правило на коммерческой основе)
18. Проблема выбора. • Chef/Puppet/CFEngine – ориентированы на разработчиков – высокие требования к знанию языка описания рецептов – длинная кривая обучения – архитектура клиент/сервер
19. Проблема выбора. • Salt/Ansible – ориентированы на системных администраторов • Salt – архитектура клиент/сервер – надежен, мастер-сервера хорошо масштабируются • Ansible • agentless архитектура, нет выделенного сервера для хранения рецептов • нужно грамотно организовать доступ к репозиторию • до жути простой (extremely simple)
20. Как начать это делать. • определения круга и перечня задач • оценка времени затрачиваемого на задачи • выбор инструмента – есть ли ресурсы на развертывание – есть ли время на изучение • написание рецептов на тестовом окружении – наработка опыта эксплуатации – убеждение подходит ли оно нам или нет • написание рецептов для production
21. Horror stories. • выполнение задач не там где это должно быть • Помещение левых серверов в пул балансировки • Ошибки в регулярных выражениях • pg_upgrade: Удаление строй директории до запуска сервиса • ALTER TABLE ... ADD COLUMN ... DEFAULT ...;
22. Horror stories. • Coworker says "I'm going to do some clean-up of the logs on the server." Two minutes later, "Oh crap. I had removed pg_xlog directory" • Деплой на staging с production конфигами • Случайная вставка «init 6 » в главное окно cssh.
23. Lessons learned. • Наличие дежурных инженеров (администраторы, разработчики) • Наличие отлаженных процедур по устранению аварийных ситуаций (runbooks) • Наличие тестового окружения для проверки • Семь раз проверь, один — отрежь • Никакая техника не спасет если в кабине сидит обезьяна (с).
24. Вопросы?
25. Спасибо! • http://www.postgresql-consulting.com • http://www.thislinux.org • alexey.lesovsky@postgresql-consulting.com