Опыт разработки, отладки и внедрения системы горячего резервирования торговой системы / Сергей Костанбаев (Московская Биржа)
0 likes•257 views
Документ описывает опыт разработки и внедрения системы горячего резервирования для торговой системы, обсуждая выбор аппаратной платформы и архитектуры сервера. Он также затрагивает проблемы, связанные с багами, разработкой алгоритмов обеспечения консенсуса и тестированием системы. В заключение, приводятся выводы и рекомендации по управлению резервированием и улучшению надежности системы.
![Случилось непредвиденное...
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 ]](https://image.slidesharecdn.com/3-171115111938/85/-20-320.jpg)
Опыт разработки, отладки и внедрения системы горячего резервирования торговой системы / Сергей Костанбаев (Московская Биржа)
- 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 Ожидание
- 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 Клиентский уровень
- 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
- 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 план когда горячей резерв не сработает [email protected]