Downloaded 18 times
Uploaded byOntico
PostgreSQL - Ups, DevOps..., Алексей Лесовский (PostgreSQL-Consulting)
Документ содержит информацию о консалтинговых услугах по PostgreSQL, включая техническую поддержку и обучение. Обсуждаются задача автоматизации обслуживания баз данных, проблемы управления конфигурацией и внедрение практик DevOps. Также упоминаются инструменты для автоматизации и перечислены практические рекомендации для системных администраторов.
PostgreSQL - Ups, DevOps..., Алексей Лесовский (PostgreSQL-Consulting)
- 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