Pull to refresh

Comments 25

Отключение одной ВМ или физического сервера. Команда эмулировала разные события, например, отключая ВМ одну за другой или целый хост, и смотрела, как это повлияет на всю систему. В то же время происходила имитация пользовательской нагрузки. Тестирование выявило определенные проблемы, которые позже были устранены.

Какие проблемы? И как устраняли? Можно подробности?
проблемы были разные, начиная от некорректных условий переключения на резервный SQL до проблемы, что CDN, что он продолжал стягивать картинки с отключенного сервера статики. про какую часть проблем подробнее рассказать?
в процессе подготовки к релизу, был составлен список что может упасть:
-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.
Я полагал, что данные о сервере в куке зашифрованы. Теперь увидел, что они задаются в явном виде. Т.е. задав неправильную куку SERVERID=BZG-FE-02; я могу увеличить нагрузку на backend, который не обслуживал мою сессию изначально?
до того, как пользователь начнет грузится в кэш, будет проверено, не залогинен ли пользователь уже, если да, то кука будет изменена, и пользователь попадет на нужный сервер.
Спасибо за ответы, интересно. В любом случае скрытие названий backend'ов в куках не повредит.
Немного не по теме, но на стартовой странице кнопки и speech-bubble вроде бы низкого разрешения, особенно текст. Или только у меня?
Возможно у Вас retina-дисплей. Мы еще не оптимизировали для них картинки.
Вроде бы нет, обычный дисплей, 1920x1200, 17 дюймов, 131ppi
Возможно что-то с версткой, мы посмотрим. Если Вас не затруднит, пришлите скриншот на kp(ат)deepdox.ru. Плюс, если возможно, дайте знать какое окружение (платформа, браузер и т.п.)
Пытался зарегистрироваться, линк активации попал в gmail spam
Да, действительно. Пока не удается нам понять почему так про нас gmail думает. DKIM — используем. В письмах рассылки, как и положено, внизу есть unsubscribe-ссылка. Unsubscribe Rate примерно 0.10%, SPAM SCORE у писем активации 1.259 almost perfect.
Возможно, мы рассматривали в качестве кандидатов MailJet и SendGrid. Майлджет нам понравился удобной статистикой и мы остановились на нем. Сейчас пытаемся с их поддержкой по этому вопросу найти общий язык. Если не получится, то попробуем перейти на SendGrid или поискать кого-нибудь еще.
Если не секрет, то какая именно SQL база использовалась?
Та же PostgreSQL не уступает MongoDB/
Использовалась MongoDB (NOSQL) и MSSQL Server в качестве реляционного транзакционного хранилища.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Швейцария
Website
veeam.com
Employees
1,001–5,000 employees
Registered
Representative
Loxmatiy Mamont