Вот как раз из-за этого все три значения net.ipv4.tcp_mem поставлены заведомо преувеличенными и одинаковыми: мы не хотим, что бы запускался reclaim, т.к. он ударит по производительности сервера. Вместо этого мы выставляем на сокеты кастомный размер send buffer, что бы сдерживать рост tcp памяти (которая иначе может сильно вырасти из-за автотюнинга сокетных буферов). И мы готовы пожертвовать необходимым для этого объёмом RAM (на практике это несколько гигабайт).
С некоторым опозданием, но всё же хочу поздравить всех участников и победителей как один из «коллективного сознательного».
Раньше было сложно найти нужную информацию потому что её было мало. Сейчас сложно найти информацию, потому что её очень много и в основной своей массе она поверхностна. Хабр является отличной платформой для поиска и публикации профессиональных статей на тему IT.
Разобраться в чём-то до мелочей, а потом суметь донести полученные знания в понятной форме — это очень ценное умение. Такие люди через свои статьи служат общему благу — повышают уровень знаний и умений, популяризуют технологии.
Именно таких специалистов и их статьи я увидел в этом году в финалистах!
Лично от себя хотелось бы так же отметить статью Debug_all«Визуализация сетевых топологий, или зачем еще сетевому инженеру Python #2». Помню как на заре своей карьеры (20 лет назад), я работал в Интернет-провайдере и мечтал об инструменте подобному тому, что описан в статье. Очень приятно было читать о том как элегантно проблема визуализации сети решается в наши дни и какие удобные инструменты для этого существуют.
На последок хочется ещё раз пожелать всем — пишите статьи, дерзайте. Не важно, хайпанёте ли вы, получив сотню плюсов, оказавшись в тренде, или вашу статью поймут только несколько специалистов — в обоих случаях вы принесёте пользу и себе и обществу.
Проблема с tunnel оверхедом имеет простое стандартное решение — advmss. В случае с NFWare даже два решения, т.к. он умеет фрагментировать пакеты в отличии от LVS. По сравнению с этим перевод сети с тысячами устройств на более крупный MTU значительно более трудозатратное решение.
Однако, надо признать, что более крупный MTU сулит так же некоторые дополнительные бонусы в виде снижения нагрузки на процессор из-за меньшего количества пакетов.
Скрипт о котором идёт речь в предыдущем комментарии получает на вход список серверов и далее может произвести с ними какие-то действия по IPMI.
Список серверов готовится на основании CMDB другими утилитами.
В тот момент авария была в самом разгаре, все занимались выключением серверов. Как только появился первый свободный администратор он занялся задачей выключения части серверов по IPMI. Отрывать кого-то от выключения серверов, что бы выключить другие сервера не имело никакого смысла. К тому же было известно, что ближайший человек освободится в течении считанных минут, а ситуация позволяла нам их ждать.
Удовлетворённость пользователей для нас очень важна, так же как и сохранность данных. Однако, в данном случае угрозы потери данных не было, поэтому мы делали всё, что бы и пользователи не пострадали.
Во-первых, нужно было собрать список серверов подходящих под нужные критерии.
Во-вторых, в этот момент мы продолжали выключать и другие сервера, поэтому свободных рук моментально не было доступно.
Остановка приложения и корректное выключение операционки для этих серверов на этом этапе уже не делалось. Просто выключали питание на всех серверах черех IPMI. Для таких задач мы используем заранее подготовленный многопоточный скрипт.
В каждом нашем дата-центре каждый день работают наши инженеры. В здании сработала пожарная тревога, они её услышали и рассказали это нам.
Были ли какие-то проблемы со службой поддержки мне не известно, но судя по вот этой статье служба поддержки тоже пострадала от пожара:
Потеря каналов связи из-за пожара внутри компании и с клиентами усугубила ситуацию. После пожара Dataline задублировала все каналы связи и внутренние сервисы в своих дата-центрах Nord и Ost.
Мы используем MS SQL уже 13 лет, начиная с первых версий сайта. За это время мы вкусили всего его прелести (которых безусловно не мало) и недостатки. Примерно столько же лет мы планомерно переходим на Open Source решения (даже вебсервера в первые годы жизни проекта работали на решениях Microsoft). Что касается баз данных, то для критичных систем мы стараемся использовать NoSQL решения и собственные разработки.
Статья называется «Как не положить тысячи серверов...», а не «Как починить тысячи серверов...», что бы не дублировать другую статью на которую есть ссылка в тексте:
Для RFS достаточно включить RPS и задать ненулевое значение в файлах /sys/class/net/eth*/queues/rx-*/rps_flow_cnt. Подробнее в https://www.kernel.org/doc/Documentation/networking/scaling.txt.
Это улучшайзер RPS, который запоминает на каком ядре находится процесс, обрабатывающий соединение.
Нет смысла покупать сервер с числом ядер большим, чем суммарное число очередей сетевых карт.
Вот это очень спорно (особенно перед следующей строчкой про RPS). Потому что сервера занимаются не только обработкой пакетов, но ещё и крутят какое-то приложение, работающее с данными из этих пакетов. И приложению дополнительные (пусть и виртуальные) ядра могут вполне быть на руку. В нашем случае, например, как раз больше трафика удаётся обработать с включенным HT.
Ещё, пользователи тулзов наверняка оценили бы возможность настраивать ещё и RFS и XPS.
Конфигурация серверов:
2x Intel Gold 6238R CPU
512GB RAM
1x NVME
4x 25Gbit NET
"You want to avoid hitting that threshold "
Вот как раз из-за этого все три значения net.ipv4.tcp_mem поставлены заведомо преувеличенными и одинаковыми: мы не хотим, что бы запускался reclaim, т.к. он ударит по производительности сервера. Вместо этого мы выставляем на сокеты кастомный размер send buffer, что бы сдерживать рост tcp памяти (которая иначе может сильно вырасти из-за автотюнинга сокетных буферов). И мы готовы пожертвовать необходимым для этого объёмом RAM (на практике это несколько гигабайт).
Раньше было сложно найти нужную информацию потому что её было мало. Сейчас сложно найти информацию, потому что её очень много и в основной своей массе она поверхностна. Хабр является отличной платформой для поиска и публикации профессиональных статей на тему IT.
Разобраться в чём-то до мелочей, а потом суметь донести полученные знания в понятной форме — это очень ценное умение. Такие люди через свои статьи служат общему благу — повышают уровень знаний и умений, популяризуют технологии.
Именно таких специалистов и их статьи я увидел в этом году в финалистах!
Лично от себя хотелось бы так же отметить статью Debug_all «Визуализация сетевых топологий, или зачем еще сетевому инженеру Python #2». Помню как на заре своей карьеры (20 лет назад), я работал в Интернет-провайдере и мечтал об инструменте подобному тому, что описан в статье. Очень приятно было читать о том как элегантно проблема визуализации сети решается в наши дни и какие удобные инструменты для этого существуют.
На последок хочется ещё раз пожелать всем — пишите статьи, дерзайте. Не важно, хайпанёте ли вы, получив сотню плюсов, оказавшись в тренде, или вашу статью поймут только несколько специалистов — в обоих случаях вы принесёте пользу и себе и обществу.
Однако, надо признать, что более крупный MTU сулит так же некоторые дополнительные бонусы в виде снижения нагрузки на процессор из-за меньшего количества пакетов.
Список серверов готовится на основании CMDB другими утилитами.
В тот момент авария была в самом разгаре, все занимались выключением серверов. Как только появился первый свободный администратор он занялся задачей выключения части серверов по IPMI. Отрывать кого-то от выключения серверов, что бы выключить другие сервера не имело никакого смысла. К тому же было известно, что ближайший человек освободится в течении считанных минут, а ситуация позволяла нам их ждать.
Во-вторых, в этот момент мы продолжали выключать и другие сервера, поэтому свободных рук моментально не было доступно.
Остановка приложения и корректное выключение операционки для этих серверов на этом этапе уже не делалось. Просто выключали питание на всех серверах черех IPMI. Для таких задач мы используем заранее подготовленный многопоточный скрипт.
Были ли какие-то проблемы со службой поддержки мне не известно, но судя по вот этой статье служба поддержки тоже пострадала от пожара:
В целом — у обоих решений есть свои плюсы и минусы.
TL;DR: мы готовы автоматизированно починить bash и cfengine на всём проде через ipmi.
Статья огонь, а обилие ссылок делают её просто бесценной!
Это улучшайзер RPS, который запоминает на каком ядре находится процесс, обрабатывающий соединение.
Вот это очень спорно (особенно перед следующей строчкой про RPS). Потому что сервера занимаются не только обработкой пакетов, но ещё и крутят какое-то приложение, работающее с данными из этих пакетов. И приложению дополнительные (пусть и виртуальные) ядра могут вполне быть на руку. В нашем случае, например, как раз больше трафика удаётся обработать с включенным HT.
Ещё, пользователи тулзов наверняка оценили бы возможность настраивать ещё и RFS и XPS.
Via все 16 LVS балансировщиков этого датацентра. Т.е. именно ECMP и обеспечивает маршрутизацию пакетов на все LVS.