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

Вы путаете должности тимлида (ведущий системный администратор) и руководителя отдела.

Даже в последнем всё ещё нет альтернативы MySQL для долговременного хранения данных, нет алтернативы встроенным функциям для триггеров и нет распределённого мониторинга без SPOF.

Рассматривали, но оно должно быть способным заменить собой все имеющиеся у нас системы мониторинга (различные in-house и opensource решения). Требований было достаточно много, но ничего сверхестественного по сегодняшним меркам. Тем не менее ни одно решение не подошло настолько, что бы бросится его внедрять (а заменить хорошо настроенный мониторинг в компании никогда не бывает легко). Кроме того у нас уже есть очень мощная по своим возможностям и производительности система, которая работает с различными performance метриками приложений. Именно она и легла в основу будущей системы.

Спасибо, интересная информация.

Алексей, а когда можно ожидать какие-то более серьёзные архитектурные изменения? В первую очередь интересует распределённый мониторинг без SPOF с централизованным управлением и NOSQL хранилище.
Обещанного 3 года ждут, но и они уже прошли :)

Вы же не думаете, что мы сервера руками настраиваем? :)
Есть несколько систем, которые в той или иной степени связаны с настройкой сети и для миграции на teaming необходимо подготовить все эти системы. Причём, что бы они работали с bonding и teaming одновременно.
И, повторюсь, эти трудозатраты пока ничем не оправданы.

Performance overhead для bonding низкий, а для teaming очень низкий.
Мы не нашли для себя выгоду в использовании teaming, а времени на внедрение пришлось бы потратить неоправданно много, поэтому остались на bond.

У set_irq_affinity.sh нет готового функционала для игнорирования каких-то ядер, но скрипт достаточно простой, что бы заложить туда любую необходимую вам логику.

Стоит или не стоит отключать ipv6 зависит от того используете вы его или нет.

Mellanox VMA не встречал.
Попробуем.
Спасибо!

Спасибо, у нас нет опыта использования Solarflare, поэтому в статье они не упомянуты.

Спасибо за ваш комментарий, Алексей.
Ради одного вашего комментария стоило писать эту статью.

Отвечу по пунктам:

• Новое ядро пробовали пока только на видео раздаче, выигрыша не получили, но это скорее связано с (пока) неопределённой проблемой высокого softirq. Тоже самое с TCP congestion алгоритмами и tcp_slow_start_after_idle=0.
• В стоковом ядре драйвер довольно новый, хоть и отличается от out-of-tree. Тем не менее мы их тоже тестили в рамках борьбы с softirq и тоже не помогло.
• Вижу, что вы в set_irq_affinity учитываете NUMA и конфигурите XPS заодно — это круто. Мы используем модифицированный set_irq_affinity, который настраивает все очереди всех поднятых интерфейсов сразу + все прерывания дисковых контроллеров LSI и распределяем по очереди на все ядра по кругу. Но не учитываем NUMA. Что касается XPS, то на ixgbe и mlx4 он конфигурится автоматом. Надеюсь впилим и NUMA со временем.
• Адаптивную модерацию мы выключаем (на i40e, например), т.к. она заботится о latency, а нам нужен был throughput.
• NUMA лучше не интерливить, трудно не согласиться :) Пока приложение не готово, но мы работаем в этом направлении. А вы делали какие-то сравнительные тесты по NUMA — какой выигрыш на какой-нибудь активной раздаче?
• zone_reclaim_mode умышленно не трогал.
• Про OOO в Flow Director тоже читал и собираюсь упомянуть на Highload++, а то сам Intel про это как-то не упоминает.
• Ринг буферы задраны и оффлоадинги включены. На самом деле, конечно, в статье далеко не все использованые оптимизации упомянуты, только то что было новым для нас.
• На скорость PCIe уже наталкивались, теперь тщательно проверяем.
• С ioatdma был казус в Centos 7 bugs.centos.org/view.php?id=8778, а Red Hat как-то вообще говорит, что он не нужен access.redhat.com/articles/879293.
• Для Netmap/DPDK надо писать свой TCP stack. Для mTCP перепиливать приложение. Fastsocket ещё не пробовали, но планируем. OpenOnload только с Solarflare, которого у нас нет. Было бы интересно узнать про success story использования user-space tcp с какими-то Java HTTP серверами (вроде lighttpd в который впилили mTCP сами разработчики mTCP).
• Jumboframes тоже есть в планах.
• Malloc менаем на tcmalloc.

Ещё раз спасибо за прекрасную подборку заклинаний! :)

Спасибо.
Отличный результат!

А какие карты используете?

А сколько реально могут отдать трафика серверы с «пропускной способностью до 80 гигабит»? Интересно было бы узнать подробности, как вам это удалось.
Особенно как решали проблему с ростом softirq.

Уточню, что забэкпортить необходимые изменения на тот момент выглядело проще, чем обновляться на новую ветку. В итоге мы всё равно обновились на новую ветку, что потребовало фиксить синтаксис некоторых системных и наших скриптов, но это уже другая история.

На тот момент мы использовали старую версию операционной системы openSUSE и, как следствие, старую версию bash «из коробки». Вместо того, чтобы обновить bash целиком, решили бэкпортировать необходимый функционал из новой версии. В процессе изменений была допущена ошибка.
На данный момент bash обновлён целиком.

С помощью cgroups грубо говоря вы порежете page cache на куски и в разные его части будут попадать страницы от разных приложений, но ядро по прежнему сможет использовать под page cache всю свободную память.

Спасибо, Константин.

Спасибо.