Upload
alexey-lesovsky
View
443
Download
5
Embed Size (px)
Citation preview
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