Балансировка нагрузки и отказоустойчивость в «Одноклассниках»

[@eurypterid]

> Между ними мы балансируем средствами протокола ECMP
Что имелось в виду? Equal-cost multi-path все-таки не протокол, а стратегия маршрутизации.

[@Karroplan]

раутер? обоссы меня господь!

[@xcore78]

Да, "раут". Как «маус» или «хаус».

[@Karroplan]

вынужден огорчить, но:
router in collins dictionary

[@xcore78]

Что вы, совсем не огорчили.

А ещё так говорит Jeremy Cioara :)

Правда в том, что оба варианта легитимны, и [u:], и [au].

[@AccessGranted]

Балансировщик на балансировщике и балансировщиком погоняет, а по итогу сервис падает от сгоревшего кабеля и сорванной крыши в дата-центре.

Haproxy вроде неплохо работает в связке с keepalived. Так и непонятно зачем еще перед ними городить LVS балансировщик.

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

Двадцать небольших дата-центров лучше чем три больших. Нет проблем с резким ростом нагрузки в случае проблем в одном из них.

[@Seboreia]

Между 20ю ЦОДами сложнее реплицировать (синхронизировать) данные, как минимум

[@lubezniy]

Вряд ли намного сложнее. Но дороже точно.

[@dmitrysamsonov]

Haproxy даст вам отказоустойчивость серверов приложений, keepalived позволит пережить отказ одного из двух haproxy. Но этого решения уже не достаточно, если вам надо больше 1 haproxy — для этого и нужен LVS. И этого решения тем более не достаточно, если вам надо больше 1 датацентра — для этого нужен GSLB.
Географическое распределение датацентров — это не единственное решение, позволяющее доставлять контент быстро до удалённых уголков. Более адекватное решение — это CDN, его мы и используем.
Что касается приведённых вами аварий, то могу только процитировать доклад:
«По результатам этих аварий мы сформулировали для себя правило: «Одноклассники» должны работать в случае отказа любого из дата-центров.»
О том как мы этого добились и рассказывается в этом докладе.

[@m0nstermind]

Балансировщик на балансировщике и балансировщиком погоняет, а по итогу сервис падает от сгоревшего кабеля и сорванной крыши в дата-центре.

Если внимательно прочитать текст, то становится ясно, что данные аварии приведены как пример того, почему Ок поставили себе цель выживать при потере ДЦ. Это давние случаи. По результатам же реализации этой цели сервис не падает при отказе ДЦ. Например, последний отказ был на прошлой неделе, например — расплавился автомат, возник пожар. Сервис работал штатно — пользователи ничего не заметили.

По ДЦ — в Москве они все потому что их так проще обслуживать, географическая близость их улучшает времена ответа при коммуникации — что важно при больших нагрузках. Для ускорения доступа клиентов по географии имеется CDN.

Иметь 20 ДЦ для обеспечения надежности не имеет смысла, дорого, медленно. 3 нам вполне хватает.

[@AccessGranted]

Иметь 20 ДЦ для обеспечения надежности не имеет смысла, дорого, медленно. 3 нам вполне хватает.

Да, только держать треть серверного парка в режиме hot standby совсем «недорого». Вы бы у бизнеса спросили что им важнее «5%» пользователей ok.ru которые уйдут на временный перекур или дополнительные расходы на содержание почти 4 тысяч серверов. Судя по всему они не в курсе дел.

[@5had0ff]

Ваш сайт жутко тяжелый для старых машин и изобилует flash и gif. Может стОит оптимизировать код под слабые компьютеры? Сделать легкую версию, так сказать.

[@m0nstermind]

Для совсем слабых компьютеров можно использовать m.ok.ru.

[@A1estro]

5 минут — TTL конечно.
А почему бы не использовать отдельные сервера для хранения сессий?

[@xcore78]

Спасибо за грамотную статью.

[@berkut3128]

Спасибо за грамотную статью. Мне не совсем понятно с построением сети до LVS. Вот есть три дата центра, берем к примеру первый 5.61.23.5. Например, я пользователь хочу открыть страничку www.ok.ru мне ваш dns в round-robin режиме отдает первый ip 5.61.23.5 я обращаюсь к нему на порт 80, этот запрос доходит до дата центра(до пограничного роутера), и тут мне не совсем понятно, как происходит балансировка. Мое представление: На пограничном роутере поднят BGP у него маршруты 5.61.23.0/24 via что-то, таких одинаковых маршрутов много, чтобы работал механизм ECMP. И вот не понятно, как этот запрос доходит дальше до LVS балансировщика? У LVS балансировщика ip 5.61.23.5? Но если их два, то как этот запрос попадает на второй?

[@dmitrysamsonov]

у него маршруты 5.61.23.0/24 via что-то

Via все 16 LVS балансировщиков этого датацентра. Т.е. именно ECMP и обеспечивает маршрутизацию пакетов на все LVS.

[@berkut3128]

То есть правильно ли я понимаю маршруты например:
5.61.23.0/24 via 5.61.23.8(LVS1 балансировщик)
5.61.23.0/24 via 5.61.23.7(LVS2 балансировщик)
5.61.23.0/24 via 5.61.23.5(LVS3 балансировщик)
… итд.
И в данном случае, грубо говоря ECMP размазывает все запросы в round-robin режиме по всем LVS1-16
Так вот мне не совсем понятно, пользователю DNS отдал ip 5.61.23.5 это запрос доходит до пограничного маршрутизатора, он по ECMP решает смаршрутизировать этот запрос на 5.61.23.7 этот запрос доходит до LVS(5.61.23.7) и LVS должен его отбросить потому, что запрос предназначен не ему и потому, что клиент запрашивал ip 5.61.23.5
Или я где-то запутался?

[@berkut3128]

Я кажется понял, вы на каждом LVS на loopback интерфейс добавляете алиас 5.61.23.5 тогда и ядро не будет дропать пакеты и они дальше будут подыматься по стеку.

[@dmitrysamsonov]

Почти. Мы добавляем роут в лупбек.