Comments 25
Отключение одной ВМ или физического сервера. Команда эмулировала разные события, например, отключая ВМ одну за другой или целый хост, и смотрела, как это повлияет на всю систему. В то же время происходила имитация пользовательской нагрузки. Тестирование выявило определенные проблемы, которые позже были устранены.
Какие проблемы? И как устраняли? Можно подробности?
проблемы были разные, начиная от некорректных условий переключения на резервный SQL до проблемы, что CDN, что он продолжал стягивать картинки с отключенного сервера статики. про какую часть проблем подробнее рассказать?
Желательно обо всех.
в процессе подготовки к релизу, был составлен список что может упасть:
-picture store — мы планировали использовать DFS, но после не тестов выяснилось, что там иногда начинает тупить репликация — не справляться. было решено вынести сохранение картинок на уровень приложения(краулер пытается сохранить картинку на диск на оба сервера), не очень красивое решение, но оно оправдано тем, что у нас нет файлового хранилища
-haproxy — если пользователь был залогинен, прокси могла выставить куку на рандомный сервер, решили выносом логики выставления куки на фронтэнд
-CDN первый наш CDN падал, в итоге перешли на cloudfare но там была проблема, что брался один из из списка, в итоге на picture store навешали NLB что бы внешний IP был общий
— Была проблема с логикой старта ВМ, в некоторых случаях(теоретических), у нас могла пропасть внутреняя сеть, но остаться внешняя сеть, в данном случае ВМ стартовали и поулчалось, например что раббита у нас было 2 на одном адресе после восстановления сети… что есть плохо
— с SQL была проблема, рассматривали вначале автоматическое переключение между серверами, при помощи 3 стороны witness, но т.к. у нас база в асинхронном режиме, то решили использовать скрипт, который переключает в одном направление primary сервер, а восстаналивать потом ручками, вдруг конфликты будут.
во время тестирования, параллельно смотрели как себя ведет система для конечного пользователя. Самое страшное для нас это падение SQL основного, тогда даунтайм будет до 15-30 минут, остальное для пользователя проходит не заметно. SQL кластер, было бы лучше равернуть, но он упирается в отсутствие файлового хранилища
-picture store — мы планировали использовать DFS, но после не тестов выяснилось, что там иногда начинает тупить репликация — не справляться. было решено вынести сохранение картинок на уровень приложения(краулер пытается сохранить картинку на диск на оба сервера), не очень красивое решение, но оно оправдано тем, что у нас нет файлового хранилища
-haproxy — если пользователь был залогинен, прокси могла выставить куку на рандомный сервер, решили выносом логики выставления куки на фронтэнд
-CDN первый наш CDN падал, в итоге перешли на cloudfare но там была проблема, что брался один из из списка, в итоге на picture store навешали NLB что бы внешний IP был общий
— Была проблема с логикой старта ВМ, в некоторых случаях(теоретических), у нас могла пропасть внутреняя сеть, но остаться внешняя сеть, в данном случае ВМ стартовали и поулчалось, например что раббита у нас было 2 на одном адресе после восстановления сети… что есть плохо
— с SQL была проблема, рассматривали вначале автоматическое переключение между серверами, при помощи 3 стороны witness, но т.к. у нас база в асинхронном режиме, то решили использовать скрипт, который переключает в одном направление primary сервер, а восстаналивать потом ручками, вдруг конфликты будут.
во время тестирования, параллельно смотрели как себя ведет система для конечного пользователя. Самое страшное для нас это падение SQL основного, тогда даунтайм будет до 15-30 минут, остальное для пользователя проходит не заметно. SQL кластер, было бы лучше равернуть, но он упирается в отсутствие файлового хранилища
При этом, чтобы сам экземпляр HAProxy не стал точкой отказа, их развернуто несколько штук с настроенным DNS Round Robin. Это старая добрая ламповая технология, которая просто работает, когда пользователь выбирает случайный IP-адрес из списка.
Т.е. если один из HAProxy упадет, то каждый N-ый запрос пользователя не будет обрабатываться, т.к. DNS севрер не будет знать какой из HAProxy упал? А если и будет знать, то пройдёт какое-то время перед тем как DNS обновится на стороне пользователя?
в статье небольшая неточность есть, а именно: haproxy еще установлен heartbeat, который контролирует, что все IP, на которых весит сайт находятся на живой ноде. т.е. в случае падение одной из проксей, внешний упавшей IP будет авотматически поднят на другой проксе
Используется ли в вашем случае conntrackd (или аналоги), чтобы восстанавливать сессии?
фактически пользователь попадает всегда на один и тот же фронтэнд, если он находится в работоспособном состояние, а прокси направляет его на нужный, в зависимости от куки. Если фронтэнд упадет, то пользовательская сессия пропадает, в случае падения прокси переключение составляет в пределах 1-5с, Пользователь должен попадать на тот же сервер т.к. генерация индивидуальной ленты на лету требует ресурсов и у нас их нет лишних. При логине, мы, конечно, проверяем на каком сервере уже залогинен пользователь.
Для парсинга кук HAProxy работает в режиме HTTP? Если кук много, то откуда HAProxy понимает в какой backend отправлять пользователя? Используется какое-то хранилище?
да, конечно в режиме HTTP работает.https трафик тоже на прокси разбирается и по http идет на frontend
про много кук не понял, можно пояснить?
смотрится значение куки, и в зависимости от значения, направляется на нужный сервер, если не валидное значение, то на случайный север отправляется, и frintend выставит нужное значение
P.S. у нас на проекте сложилась, такая терминология: backend — 40 сервисов, которые обеспечивают поставку и прочее, frontend — сайт, который генерирует пользовательскую ленту, прокси — балансирует нагрузку между серверами frontend.
про много кук не понял, можно пояснить?
смотрится значение куки, и в зависимости от значения, направляется на нужный сервер, если не валидное значение, то на случайный север отправляется, и frintend выставит нужное значение
P.S. у нас на проекте сложилась, такая терминология: backend — 40 сервисов, которые обеспечивают поставку и прочее, frontend — сайт, который генерирует пользовательскую ленту, прокси — балансирует нагрузку между серверами frontend.
Немного не по теме, но на стартовой странице кнопки и speech-bubble вроде бы низкого разрешения, особенно текст. Или только у меня?
Пытался зарегистрироваться, линк активации попал в gmail spam
Если не секрет, то какая именно SQL база использовалась?
Та же PostgreSQL не уступает MongoDB/
Та же PostgreSQL не уступает MongoDB/
Sign up to leave a comment.
Архитектура BigData-инфраструктуры сервиса Pandorama и защита ее данных от сбоев