Документ обсуждает опыт миграции данных между дата-центрами, включая важные аспекты, такие как законодательные изменения, репликация для минимизации даунтайма и особенности работы с новым оборудованием. Упоминается о возможных сложностях, связанных с качеством сети и потерь данных, а также о проведенных нагрузочных тестах на различных версиях операционной системы и PostgreSQL. Авторы делают акцент на том, что некоторые подходы, такие как использование NFS и сетевые ограничения, оказались неэффективными.

1. Опыт миграции между
дата-центрами
Сергей Бурладян и Михаил Тюрин
HighLoad++, 2016

2. Что нового вы узнаете?
2

3. 3

4. • законодательные инициативы затрагивают техническую
платформу
• переезд большого нагруженного кластера между дата-центрами
по интернету возможен (за конечное время)
• и с небольшим даунтаймом
4

5. • можно достаточно точно оценить необходимую пропускную
полосу при переезде
• существуют ярко выраженные особенности шейпинга
выделенного интернет маршрута
5

6. • при этом скорее всего вы будете вынуждены работать на новом
оборудовании / окружении
• существуют неожиданные особенности systemd
• результаты некоторых нагрузочных тестов
• закон Мура у кого-то всё ещё может работать
6

7. Переезд “базы” — часть сложного процесса миграции всей
площадки:
• приложение
• картинки
• индексы
• другие базы
• dwh
• crons
• …
30 SubTasks и 30 Dependent - 6 месяцев
7

8. Тестировали дата-центр боем: отдаём картинки
из Москвы
> 50% трафика площадки
8

9. — Подлежит ли откату процесс переезда?
— Нет, очень сложно.
9

10. Интуитивное решение о
применении репликации —
правильно!
10

11. Как перенести базы с минимальным downtime?
Репликация!
• физическая — streaming, WAL архив // x2
• логическая — londiste // x2
• rpc — pgq + xrpcd.py // x2
11

12. Mbit/s, оценка необходимой пропускной способности
12

13. Оценка необходимой пропускной способности
• 12 серверов WAL ~ 100 — 150 Mbit
• 3 сервера londiste + rpc < 50 Mbit
• c учётом возможного роста до двух раз (переезд — 6 месяцев)
• кластера от 10 GB до 3 TB
13

14. Два первых варианта
NFS через интернет слишком круто
+ ? проблема версий (4 vs. 3) NFS
Сейчас просто включим стриминг в Москву и всё!
14

15. Схема в лоб
15

16. Проблемы
• lag сети —> потеря WAL / взрыв WAL
• однопоточность —> потеря WAL / взрыв WAL
• streaming —> нет архива в Москве
Вывод: не надо потреблять с мастера!
*pg 9.2
16

17. Вариант два
• WAL архив (pbzip2):
send-wals.sh + rsync
archive_command и т.п.: https://pgconf.ru/2016/89927*
*Сергей Бурладян “Администрирование PostgreSQL в Avito
17

18. Схема два
18

19. Оказывается
• Канал 2 Gbit
• Но на одну TCP сессию почему-то 2 Mbit
2 Gbit —> 2 Mbit
19

20. Вариант три
• send-wals.sh + parallel-rsync.sh
send-wals.sh:
parallel-rsync.sh:
20

21. Реализованная схема
21

22. Новая среда и оборудование
Проблема нового Debian
• pgbench Debian 6 vs Debian 7: в 2-3 раза!
• ===8.2 (jessie) | 3.16.7-ckt11-1+deb8u6 | AMD Opteron(tm) Processor 6136
• $ pgbench -SNn -r- -f test.sql -p 6432 -U postgres -c 10 -T $((5 * 60)) avito_test
• tps = 7528.535949 (excluding connections establishing)
• === 6.0.3 (squeeze) | 2.6.32-5-amd64 | AMD Opteron(tm) Processor 6136
• $ pgbench -SNn -r- -f test.sql -p 6432 -U postgres -c 10 -T $((5 * 60)) avito_test
• tps = 9284.494020 (excluding connections establishing)
• Debian 6 быстрее Debian 8 на ~ 20%
22

23. Новая среда и оборудование
• === 6.0.3 (squeeze) | 2.6.32-5-amd64 | AMD Opteron(tm) Processor
6136 2399.891 MHz | 9.2.13-1.pgdg60+1
• tps = 8212.192504 (excluding connections establishing)
• ===8.2 (jessie) | 3.16.7-ckt20-1+deb8u6 | Intel(R) Xeon(R) CPU
E5-2697 v3 @ 2.60GHz | 9.2.14-1.pgdg80+1
• tps = 19067.844979(excluding connections establishing)
• mbw
23

24. Диаграмма бенчмарка
24

25. Особенности systemd
• /etc/systemd/logind.conf
RemoveIPC=no
https://www.postgresql.org/message-id/
20151214224729.2624.99840@wrigleys.postgresql.org
• KillMode=none
SendSIGKILL=no
https://bugzilla.suse.com/show_bug.cgi?id=906900
sudo pg_ctlcluster 9.2 main stop -- -m f
sudo -u postgres pg_ctlcluster 9.2 main stop -m f
25

26. Особенности systemd
• cgroups
puppet.service
20233 /usr/bin/ruby /usr/bin/puppet agent
26718 /usr/sbin/pgbouncer -R -d /etc/pgbouncer/pgbouncer-server.ini
26

27. Закон Мура всё ещё работает
27

28. Не принятые варианты
• NFS
• текущий архив
• сеть (2 Mbit)
• ? производительность железа
28
Успешно реализованное
• тестирование площадки
• pgq логическая репликация
• принципиальная схема PITR
• ! производительность железа

29. Спасибо за внимание!
Вопросы?
Сергей Бурладян - sburladyan@avito.ru
Михаил Тюрин - mtyurin@avito.ru
HighLoad++, 2016
AvitoTech