Mystery of link imbalance #2: как можно починить MRU-пул

Я не удержался, и еще поэкспериментировал с симуляцией link imbalance из предыдущего поста. Там есть вопрос: как эту проблему исправить? Как сделать так, чтобы трафик не собирался на один-единственный канал?

Инженеры фейсбука порешали проблему тем, что сменили в пулах соединений стратегию MRU на LRU. LRU хорошо балансирует нагрузку – старается все соединения в пуле использовать в равной степени – и как бы соединения в пулах не сортировались, на сколько-либо длинной дистанции все равно все каналы будут задействованы примерно одинаково.

Но у MRU есть преимущества: пул с такой стратегией минимизирует количество активных соединений. Это уменьшает нагрузку на сервер БД, плюс небольшое число активных соединений вероятнее будет горячим в кэше, как на стороне клиента, так и на стороне сервера БД. В статье не пишут, почему изначально в фейсбуке был выбран MRU-пул, но можно предположить, что именно поэтому.

Однако кажется, что можно сохранить преимущества MRU, но предотвратить link imbalance.

Mystery of link imbalance (metastable failure)

Я люблю системы, где из простых элементов возникает какое-то нетривиальное поведение. Последний месяц я игрался с симуляцией одной такой системы из статьи "Metastable Failures in Distributed Systems"¹

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

И это продолжалось почти два года, прежде чем коллективными усилиями инженеров разных отделов удалось понять, что именно происходит.