Я использую LVS (ipvsadm) в режиме NAT для балансировки нагрузки UDP-трафика для нескольких «реальных серверов». Я использую однопакетное планирование, чтобы трафик, исходящий из одного исходного порта на клиенте, распределялся по разным реальным серверам.
Однако я вижу, что датаграммы UDP, которые создаются на реальных серверах и отправляются обратно клиенту, имеют исходный IP-адрес и порт, установленные на реальном сервере, что сбивает клиента с толку, поскольку он ожидает получить ответы с исходным IP-адресом и портом, совпадающими с теми, на которые он отправил исходную датаграмму.
Это действительно очень странно, поскольку LVS должен «скрывать» реальные серверы за виртуальным IP-адресом/портом.
Кажется, если я отключу однопакетное планирование, исходный IP-адрес/порт исходящих датаграммявляютсяпереписано правильно LVS.
Кто-нибудь сталкивался с этим? Если да, то как это обойти?
решение1
Если вам все еще интересно:
Я считаю, что планирование одного пакета не ожидает ответа от только что запланированного пакета, и поэтому не сохраняет информацию о соединении. Затем, когда ответ возвращается, LVS не может найти соединение для него и поэтому не знает, какой исходный IP/порт использовать.
Кажется, это сделано намеренно. Поищите здесь "OPS реализован для установок, где нет ответа на исходный пакет", и вы увидите некоторые объяснения.
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.UDP.html
Решение состоит в том, чтобы установить тайм-аут сохранения для UDP-соединений (вы можете установить его низким, если ожидаете быстрых ответов), таким образом явно устанавливая время соединения. Поскольку вы можете это сделать, то для OPS нет смысла запоминать соединения.