HighLoad++ 2017 Зал «Сингапур», 8 ноября, 12:00 Тезисы: http://www.highload.ru/2017/abstracts/3035.html - "Горячий" резерв, что это и зачем это нужно? Всем ли нужен? - Почему Московская Биржа решила это реализовывать. - Классические архитектуры построения горячего резерва, обзор наработок. - Почему потребовалось разрабатывать свой алгоритм. (Биржа должна быть максимально доступна, даже если алгоритм думает, что лучше, вообще, все прекратить на сегодня...). ...

1. Опыт разработки,
отладки и
внедрения
системы горячего
резервирования
торговой системы
Сергей Костанбаев

2. Q1 2010 Q2 2010 Q3 2010 Q4 2010 Q1 2011 Q2 2011 Q3 2011 Q4 2011 Q1 2012 Q2 2012
Зачем понадобилась система
горячего резервирования
97,8 тыс. → 13,6 млн. заявок/день
~140x за 2,5 года

3. Аппаратная платформа
Mission Critical HP Superdom 9000
● Неконкурентоспособны
● HP PA-RISC «мертва»
Что выбрать?
● Intel Itanium
● IBM Z mainframes
● IBM Power
● X86_64 (Xeon Nehalem)

4. Переход на x86_64
HP UX → RedHat MRG Linux
PA-RISC → x86_64
● big endian → little endian
● Другая memory model
Mission Critical High-End Server → Commodity
● Горячая замена CPU → ?
● Горячая замена контроллеров → ?
● Резервирование RAM → ?
● Дублирование логики → ?
● MTBF, 0 downtime, ... → ?

5. Архитектура ядра торговой
системы
Торговое ядро (TE)
●
Обрабатывает все
транзакции
Серверы доступа
(GATEWAY)
●
Транзакции →
ядро
●
Информационные
→ локально
TE
GATEWAY ШЛЮЗ
GATEWAY
Клиентский
уровень

6. Горячее резервирование 1.0
Выход из строя сервера
Проблемы с сетью
Зависание

7. Горячее резервирование 1.0
Автоматическое переключение за секунды
Нет потерь уже обработанных транзакций
Прозрачно для инфраструктуры
Для клиента нет разрыва соединения
Сопоставимая задержка

8. Горячее резервирование 1.0
Двойные отказы
Ошибки в софте
Неправильная работа железа

9. Схема горячего резервирования
MAIN главный сервер
BACKUP резервный
сервер
GOVERNOR
координирует
назначение роли
MAIN
MAIN BACKUPGOVERNOR
GATEWAY ШЛЮЗ
GATEWAY
Клиентский
уровень

10. Путь транзакции
MAIN BACKUP
Отправка
на Backup
Выполнение
Подтверждение
о приеме
Ожидание
подтверждения
Выполнение
Сверка
состояния N-1
Ожидание

11. Переключение
MAIN BACKUPGOVERNOR
GATEWAY
ШЛЮЗGATEWAY
Клиентский
уровень

12. Переключение
MAIN завис
MAIN BACKUPGOVERNOR
GATEWAY
ШЛЮЗGATEWAY
Клиентский
уровень

13. Переключение
MAIN завис
BACKUP ↔ GOVERNOR
MAIN BACKUPGOVERNOR
GATEWAY
ШЛЮЗGATEWAY
Клиентский
уровень

14. Переключение
MAIN завис
BACKUP ↔ GOVERNOR
BACKUP → MAIN
GATEWAY → new MAIN
MAIN MAINGOVERNOR
GATEWAY
ШЛЮЗGATEWAY
Клиентский
уровень

15. Переключение
MAIN завис
BACKUP ↔ GOVERNOR
BACKUP → MAIN
GATEWAY → new MAIN
…
old MAIN ↔ GOVERNOR
MAIN MAINGOVERNOR
GATEWAY
ШЛЮЗGATEWAY
Клиентский
уровень

16. Переключение
MAIN завис
BACKUP ↔ GOVERNOR
BACKUP → MAIN
GATEWAY → new MAIN
…
old MAIN ↔ GOVERNOR
GOVERNOR → kill old MAIN
MAINGOVERNOR
GATEWAY
ШЛЮЗGATEWAY
Клиентский
уровень

18. Случилось непредвиденное...
MAIN
Транзакция неуспешна
BACKUP
Транзакция успешна

19. Случилось непредвиденное...
MAIN
Транзакция неуспешна
exp(2) = -3.1 ???
BACKUP
Транзакция успешна
exp(2)=7.389

20. Случилось непредвиденное...
MAIN
Транзакция неуспешна
exp(2) = -3.1 ???
SSE2 mxcsr
[ PE IM DM ZM OM UM PM RZ ]
BACKUP
Транзакция успешна
exp(2)=7.389
SSE2 mxcsr
[ PE IM DM ZM OM UM PM ]

21. Как это произошло?
Баг округления в libc → patch
Откуда взялся бит SSE2?

22. Как это произошло?
Баг округления в libc → patch
Откуда взялся бит SSE2?
Округление задается
int fesetround(int round);
Надо лишь найти ошибку в коде

23. Поиск ошибки
●
Логический анализ кода
●
Попытка воспроизвести баг
●
Intel C++/GCC/Clang
●
Разные опции оптимизации
●
Статический анализ
●
Valgrind
●
Insure++
●
...

24. А была ли ошибка?

25. А была ли ошибка?

26. А была ли ошибка?

27. Доработка системы
WARM – «теплые резервы»
●
Асинхронны
●
Можно запустить в
любой момент
MAIN
GOVERNOR
GATEWAY
ШЛЮЗGATEWAY
Клиентский
уровень
WARM
BACKUP
WARMWARM

28. Доработка системы
WARM – «теплые резервы»
●
Асинхронны
●
Можно запустить в
любой момент
●
GOVERNOR не может
назначить WARMу роль
MAIN
●
Но может перевести в
BACKUP
MAIN
GOVERNOR
GATEWAY
ШЛЮЗGATEWAY
Клиентский
уровень
BACKUPWARMWARM

29. Опять ошибка
Средняя частота повторения
0,5 лет/сервер

30. Опять ошибка
Средняя частота повторения
0,5 лет/сервер
Может проблема ОС Linux?

31. Нашли
Тест с многими потоками и постоянным fesetround
Воспроизводится только на комбинации Linux-ядра и боевых
серверов
Стабильно за ~5 минут бит залипает
Не воспроизводится у поддержки
Замена на новое ядро помогает
Очень напоминает https://habrahabr.ru/post/332552/
«Как я нашёл баг в процессорах Intel Skylake»

32. Проблема решена, но осадок
остался...

33. Горячее резервирование 2.0
Никому верить нельзя
Мажоритарное резервирование
Обеспечение консенсуса
Двойные отказы возможны

34. Горячее резервирование 2.0
Живучесть
Незначительное увеличение задержки
Минимальное взаимодействие по сети
Выбор нового Main за секунды

35. А есть ли что-то готовое?
Совсем готовое?
●
Enterprise шины данных
Алгоритмы обеспечения консенсуса?
●
Paxos, 2001 (ACM SIGACT News 32, 4 (Dec. 2001), 18–25.)
На момент разработки еще не было
●
RAFT, 2014 https://raft.github.io/raft.pdf

36. Разработанная схема
взаимодействия
UP – поток репликации
входящих данных
DOWN — поток публикации
результатов и обеспечения
консенсуса

37. Разработанная схема
взаимодействия
UP – поток репликации
входящих данных
DOWN — поток публикации
результатов и обеспечения
консенсуса
Нет перезаписи истории

38. Поток репликации данных
Сессии назначается UUID (уникальный на каждом узле)
«Провязка» контролем CRC32
●
Tr0 = { DATA0, CRC32(DATA0, 0) }
●
Tr1 = { DATA1, CRC32(DATA1, Tr0.CRC) }
●
Tr2 = { DATA2, CRC32(DATA2, Tr1.CRC) }
CRC32C реализовано в CPU
●
u64 _mm_crc32_u64(u64 crc, u64 data);
●
Накладные расходы незаметны
Гарантируем «правильное» переключение и получение
Несоответствие CRC → abort()

39. Поток публикации результатов
Ответ исполнения
●
Результат транзакции ~300 байт → CRC32( … )
●
Число изменение состояний
●
Число обработанных транзакций
Ожидание всех синхронных
●
Сравнение со всеми синхронными
●
В меньшинстве → abort()
●
Поровну и вне группы с MAIN → abort()

40. MAIN
BU1
BU2
GOV

41. MAIN
BU1
BU2
GOV

42. MAIN
BU1
BU2
GOV

43. P
MAIN
BU1
BU2
GOV

44. P
MAIN
BU1
BU2
GOV

45. BU
MAIN
WP
MAIN
BU1
BU2
GOV

46. C
BU
MAIN
WP
MAIN
BU1
BU2
GOV

47. C
BU
MAIN
WP
MAIN
BU1
BU2
GOV

48. ?C
BU
MAIN
WP
MAIN
BU1
BU2
GOV

49. GOV{1:0}
BU{1:0}
M{1:0}
A
C
BU{0:1}
M{0:1}
W{0:1}P{0:1}
MAIN{0:0}
BU1{0:0}
BU2{0:0}
GOV{0:0}

50. GOV{1:0}
BU{1:0}
M{1:0}
X
C
BU{0:1}
M{0:1}
W{0:1}P{0:1}
MAIN{0:0}
BU1{0:0}
BU2{0:0}
GOV{0:0}

51. Таблица состояний
Все строят «свою» картину
мира
Node 1
Node 1 MAIN

52. Таблица состояний
Все строят «свою» картину
мира
Периодически вещается
Node 1 Node 2
Node 1 MAIN GOV
Node 2 MAIN GOV

53. Таблица состояний
Все строят «свою» картину
мира
Периодически вещается
Отсылаем совместно с
запросами
Node 1 Node 2 Node 3 Node 4
Node 1 MAIN GOV SYNC ASYNC
Node 2 MAIN GOV SYNC ASYNC
Node 3 MAIN GOV SYNC ASYNC
Node 4 MAIN GOV SYNC ASYNC

54. Таблица состояний
Все строят «свою» картину
мира
Периодически вещается
Отсылаем совместно с
запросами
Stateless GOVERNOR
Node 1 Node 2 Node 3 Node 4
Node 1 MAIN GOV SYNC ASYNC
Node 2 MAIN GOV SYNC ASYNC
Node 3 MAIN GOV SYNC ASYNC
Node 4 MAIN GOV SYNC ASYNC

55. Отказ GOVERNOR
Обработка транзакций идет
Timeout → все ожидают GOVERNOR
Резерв GOVERNOR?
Если сеть «поделится», кто будет выбирать? → 2 MAIN?
GOVERNOR только один
Ручной перезапуск
Система мониторинга в помощь

56. Обработка timeout
CLOCK_REALTIME
●
Используется по умолчанию
●
Изменение системного времени → все пропало
CLOCK_MONOTONIC
●
Монотонный таймер, не влияет системное время, но влияет NTP
●
pthread_*attr_setclock()

57. Обработка timeout
CLOCK_REALTIME
●
Используется по умолчанию
●
Изменение системного времени → все пропало
CLOCK_MONOTONIC
●
Монотонный таймер, не влияет системное время, но влияет NTP
●
pthread_*attr_setclock()
CLOCK_MONOTONIC_RAW
●
Аппаратный таймер, NTP не влияет
●
Нет wait() функций, только busy wait

58. Особенности тестирования
Верифицировать ли алгоритм?
Unit-тесты
●
Хитрые выборы
●
Переходы состояний
Вся система
●
Проверка различных timeout (SIGSTOP / SIGCONT)
●
Сетевые проблемы (iptables, выдергивание шнуров)
●
Fault injection (GDB-скрипты)
●
Как это повторить?

59. Система тестирования
Подготовка окружения, запуск кластера
Высокоуровенные сценарии на Python
●
Заморозить, убить
●
Отключить сеть, потери в сети, «моргание»
Сбор статистики
Визуализация тестов
●
Ход выполнения каждого теста
●
Общая тепловая карта

61. Интересные применения
Поиск ошибок
Уход с проблемного железа
Миграция между ВЦ
Обновление системы во время работы

62. Выводы и рекомендации
Неправильная работа железа / OC / системных
библиотек далеко не редкость
Горячее резервирование не 100% гарантия
Backup план когда горячей резерв не сработает
sergey.kostanbaev@moex.com

63. Вопросы
Контакты
sergey.kostanbaev@moex.com