Алексей Игнатов/Дмитрий Васильев-Инфраструктура PostgreSQL в Ozon

Transcript

1. Инфраструктура PostgreSQL в Ozon Алексей Игнатов Дмитрий Васильев
2. Около 9 тысяч PostgreSQL-инстансов Что такое инфраструктура PostgreSQL в Ozon 02.2022
3. Что такое инфраструктура PostgreSQL в Ozon 02.2022 3 mega TPS
4. Что такое инфраструктура PostgreSQL в Ozon 02.2022 4 Wal трафик GB/s
5. Как оно было 5 • В начале было слово (заявки в Jira) • Ресурсы создавались вручную через GUI( Foreman) • Ручная раскатка конфигураций через Puppet • Рутина начала угнетать
6. Что начали менять. часть 1 6 • Прикрутили плейбук на ansible для шедулинга размещения и создания базок • Работала в режиме cli • Данная схема абсолютно криповая и нерасширяемая • Рутина по заведению базок продолжала угнетать
7. Что начали менять. часть 2 7 • Хватит это терпеть • Переписываем в виде сервиса на python • resman – RESource MANager • Пока остается режим cli который дергает api • resman + It-crowd = рутина заведения базок ушла
8. К чему пришли в начале 2021 8
9. Что сейчас 9 • Ресурc в виде БД Postgresql по кнопке • Базки заказываются через it-crowd • Наша группа начинает больше пилить и расширять инфраструктуру для Postgresql • Горизонтальное масштабирование инфраструктуры поддерживает вертикальный рост компании • Планы на большую автоматизацию работы инфраструктуры вокруг Postgresql
10. Виртуализация: гипервизоры KVM
11. KVM hypervisor 11 • Все системные вызовы транслируются практически 1:1. • Основной overhead – это эмуляция окружения (в нашем случае сеть).
12. Деплой виртуальных машин 12 • Resman – scheduler ресурсов – Anti-Affinity: • dc • стойка в которой расположен гипервизор • shard-prefix (мягкое) Вес – утилизация гипервизора. • Hyper-man – управляет ресурсами гипервизора - позволяет создавать и управлять виртуальными машинами.
13. Hyper-man API 13 Клиенты hyper-man: • Resman: создание/удаление. • Hyper-dog: манипуляция над всем кластером виртуальных машин (patroni cluster). • Hyper-man-cli: помогает на P0/1 накидывать ресурсы: • CPU • RAM • IOPS
14. При создании виртуальной машины закладывается: • Online увеличение CPU – x2 • Online увеличение RAM – x2 • От 17k IOPS
15. CPU: внутри гипервизора Медицинский факт: перевод с shared на exclusive снижает latency 15 Весь CPU pool поделен на 3 части: • Shared: здесь расположены все CPU не привилегированных виртуальных машин. • Exclusive: здесь расположены CPU эксклюзивных машин. • System: изолированный кусок пула CPU для функционирования hypervisor kernel, обслуживание сети в виртуальных машинах.
16. CPU: внутри виртуальной машины 16 Распределение основных процессов внутри виртуальной машины: • К первым CPU bind’ятся pgbouncer • К последним CPU bind’ятся прерывания сетевой карты
17. Memory: не делаем overselling 17 На staging работает KERNEL SAME-PAGE MERGING (KSM), позволяет экономить около 20% памяти: • Мы используем ”золотые образы” операционной системы. • Мы используем одинаковые версии софта, (кроме версий PostgreSQL).
18. DISK 18 • Приходится использовать LVM для того чтобы обеспечить online-resize. • По IOPS есть математический overselling, фактического не наблюдаем. • Есть scheduler (hyper-dog), который делает автоматический ресайз дисков, но от него планируем отказаться, так как это приводит к неконтролируемому росту.
19. Network v2: macvtap 19 • Ограничен только исходящий трафик (200MB/s), иногда упираемся в трафик реплик. • Пакетики обрабатываются как на стороне гипервизора, так и внутри виртуальной машине. • Рандомно трафик VM-1 был виден в VM-2, из-за чего обработка “очереди пакетов” тормозила весь гипер: https://access.redhat.com/solutions/2822941
20. Network v3: sr-iov 20 • Ограничен только исходящий трафик (200MB/s), tc внутри виртуалки. • Трафик обрабатывается только внутри виртуальной машины • Нагрузочное тестирование: расходы cpu sys меньше в два раза, cpu irq в 10 раз.
21. Балансировка
22. Patroni + ETCD + Warden 22
23. Application <--> PostgreSQL 23
24. Hyper-dog: online resize 24 Hyper-dog (memory/cpu): • Проверяет целостность кластера. • Начинает с async, потом sync, потом leader. • Выводит из балансировки, если leader делает switchover, если синхронная реплика дожидается появления синхронной реплики. • Останавливает виртуальную машину, производит ресайз, запускает. • После запуска, если необходимо, делает тюнинг настройки PostgreSQL.
25. Отказоустойчивость
26. Patroni 26 Дополнительные костыли: • lag_guard (noloadbalance) • dc_guard (leader && sync в разных dc) • slot_guard (отстреливаем отставшие реплики)
27. SCM: puppet -> ansible -> chiit !!!
29. chiit 29 Проблемы которые решаем: • Масштабирование: smart client -> server as storage. • Быстрый (по нагрузке на ноду) деплой и откат. • Прозрачность.
30. Игнатов Алексей, Дмитрий Васильев Спасибо за внимание! alexign@ozon.ru, dmitrivasilyev@ozon.ru