Highload 2014. PostgreSQL: ups, DevOps.

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

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

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

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

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

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

• Итого:
– задачи типовые
– задачи ручные

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

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

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

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

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

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

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

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

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

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

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

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

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

Horror stories.
• выполнение задач не там где это должно быть
• Помещение левых серверов в пул балансировки
• Ошибки в регулярных выражениях
• pg_upgrade: Удаление строй директории до запуска сервиса
• ALTER TABLE ... ADD COLUMN ... DEFAULT ...;

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.

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

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

Highload 2014. PostgreSQL: ups, DevOps.

Recommended

More Related Content

What's hot (20)

Viewers also liked (11)

Similar to Highload 2014. PostgreSQL: ups, DevOps. (20)

More from Alexey Lesovsky (16)

Highload 2014. PostgreSQL: ups, DevOps.