postgresql - ups, devops..., Алексей Лесовский (postgresql-consulting)

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 ...;

• 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 процедуры

Lessons learned.• Наличие дежурных инженеров (администраторы, разработчики)

• Наличие отлаженных процедур по устранению аварийных ситуаций (runbooks)

• Наличие тестового окружения для проверки

• Семь раз проверь, один — отрежь

• Никакая техника не спасет если в кабине сидит обезьяна (с)

Вопросы?

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

• alexey.lesovsky@postgresql-consulting.com