Вопрос или проблема
Недавно я столкнулся с настройкой по умолчанию net.ipv4.tcp_retries2
. Она фактически заставила мой кластер высокой доступности не адаптироваться к незначительной аварии на нижнем узле более 15 минут (900+ секунд).
Это заставило меня задуматься, почему значение установлено так, что стек TCP эффективно определяет мертвый хост только через 15+ минут. Любое обоснование этой настройки по умолчанию кажется невалидным в 2024 году, по крайней мере, для простого обывателя, каким я являюсь.
Ответ на вопрос Как были определены эти настройки TCP по умолчанию в Linux? ссылается на RFC1122 – который был опубликован в 1989 году. Значение по умолчанию в ядре Linux описано в документации sysctl как сознательно установленное на 900+ секунд. Например, даже “облачная нативная” Amazon Linux 2023 дистрибутив Linux, производимый AWS, использует эту настройку по умолчанию.
С точки зрения обывателя все еще кажется странным видеть такие долгие тайм-ауты в эпоху, когда такие вещи, как Kubernetes и кластеризованные сервисы, считаются мейнстримом.
Является ли это просто вопросом инерции/совместимости?
Ответ или решение
Почему настройки по умолчанию TCP в Linux не эволюционируют?
Вопрос о том, почему настройки по умолчанию TCP в Linux, такие как значение net.ipv4.tcp_retries2
, остаются неизменными, несмотря на изменения в архитектурах и концепциях высоких доступностей (HA), требует рассмотрения нескольких факторов, включая историческую обусловленность, инерцию, влияние стандартов и необходимость обеспечивать совместимость.
1. Историческая обусловленность и стандарты
Сетевые протоколы, такие как TCP, были разработаны в конце 1970-х — начале 1980-х годов и впервые описаны в документах, таких как RFC1122. Эти протоколы и соответствующие им настройки были адаптированы под обстоятельства того времени, когда большинство соединений и сетей имели очень разные характеристики по сравнению с современными облачными или распределёнными системами. Например, высокие значения таймаутов оправданы для сетей с низкой доступностью, где потеря пакетов могла происходить более регулярно.
2. Инерция в изменении значений
Изменения в системных настройках — процесс, требующий участия сообщества разработчиков и пользователей, что приводит к инерции в принятии решений. Системные администраторы, как правило, предпочитают стабильные и проверенные значения, нежели рисковать с изменениями, которые могут вызвать неожиданные последствия. Кроме того, многие приложения и сервисы разрабатывались с учетом этих "старых" значений, в то время как изменения могут потребовать переработки программного обеспечения.
3. Совместимость и экосистема
Поддержание совместимости — это важный аспект, который учитывается при принятии решений о значениях по умолчанию. Вдруг изменив настройки, разработчики потенциально могут вызвать проблемы для существующих инфраструктур. Например, если бы значение tcp_retries2
было изменено, это могло бы привести к неправильной работе сетевых приложений, которые доверяются старым значениям. Для многих пользователей, особенно в больших корпоративных сетях, важно, чтобы их системы оставались предсказуемыми и безопасными.
4. Текущая экосистема
Сегодня многие аспекты работы с сетями и высокой доступностью используют более современные подходы, такие как переработка сетевых протоколов и применение концепций, таких как отказоустойчивые кластеры и контейнеризация (например, Kubernetes). Тем не менее, многие из этих технологий работают на основе TCP и, как следствие, продолжают опираться на старые, но проверенные временем настройки. Часто разработчики полагаются на другие механизмы для управления отказами, такие как механизмы обнаружения состояния или автоматического перенаправления трафика.
Заключение
Ваш опыт с настройкой net.ipv4.tcp_retries2
подчеркивает важность понимания текущих параметров TCP и их влияния на современные архитектуры. На первый взгляд, кажется нелогичным, что столь длительные тайм-ауты продолжают свое существование в эпоху, когда высокодоступные системы становятся нормой, но в реальности это результат сочетания исторической практики, инерции изменений и необходимости поддержания совместимости. Изменение этих значений может потребовать более глубокого понимания и анализа того, как они будут влиять на существующие системы и приложения.
В конечном итоге, чтобы адаптироваться к новым условиям, важным шагом будет не только изменение настроек по умолчанию, но также и обучение пользователей о том, как оптимально настраивать свои системы в зависимости от специфических требований их сетевой инфраструктуры.