PostgreSQL - Ups, DevOps..., Алексей Лесовский (PostgreSQL-Consulting)
Post on 15-Jun-2015
439 Views
Preview:
DESCRIPTION
Transcript
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
top related