Такой прикольный NLB

В начале июля я начал миграцию электронной почты — за полмесяца почта должна была переехать с MS Exchange 2007 на 2010. В первых числах августа миграция была закончена, но затем возник неприятный нюанс — Outlook начал периодически просить пароль. Отключение Outlook Anywhere большинству пользователей помогло, что делать с остальными мы не знали. В журналах событий даже после включения супер-подробных журналов диагностики было тихо.

Все было настолько печально, что я обратился в техподдержку Microsoft…

Инфраструктура выглядит следующим образом:

  1. все серверы находятся в отдельном VLAN;
  2. есть три контроллера домена, обслуживающие этот сайт AD: один железный и два виртуальных;
  3. виртуальная инфраструктура — VMware vSphere;
  4. шлюзом по умолчанию для серверной сети и клиентов является Cisco;
  5. почта состоит из четырех серверов: два — Mailbox (DAG), еще два — HT/CAS. CAS-сервера объединены в CAS-Array и NLB-кластер. В паре серверов один — физический, другой — виртуальный;
  6. доступ в интернет осуществляется через MS TMG (работающий в качестве прокси), находящийся в серверном VLAN.

Настроенный мониторинг портов показал очень странную вещь: соединения на отдельные ноды NLB-кластера проходили на ура, а вот NLB-адрес (HTTP, SMTP, POP3) несколько раз в час выдавал таймаут >2 секунд. Оставил в NLB только один узел — та же картина.

Для начала я решил разобраться, как же работает этот странный NLB. Тут же на помощь мне пришло видео с ExchangeRus. Очень рекомендую для ознакомления. Кстати, там же объясняется почему на ряде маршрутизаторов необходимо вручную создавать ARP-запись под Multicast NLB-кластер.

К этому времени тут мы уже обсудили, что в средах VMware лучше использовать Multicast.

С момента возникновения проблемы прошел почти месяц, гугл не помогал, проблема казалась нерешимой. И тут Mr.Nobody посоветовал посмотреть внутрь TCP-сессий с помощью сниффера.

В качестве тестовой станции был взят физический сервер, не являющийся членом домена. На этом сервере установлено ПО мониторинга Dude. Я скачал и установил на него Microsoft Network Monitor 3.4.

В качестве теста я создавал соединения на 25 порт (SMTP-сессию). После этого в MS Network Monitor сравнивал нормальную сессию и зависшую.

Ясности мне это не дало — в зависшей сессии после «TCP-рукопожатия» NLB-сервер отправлял пакет с флагом Reset. Почему/зачем — не ясно.

Посоветовавшись с Diz, установил вместо него Wireshark 1.6.1 и тут такое увидел:

Слева — тестовый сервер, справа — активный узел NLB.

Выделенный курсором пакет идет от NLB-узла (IP=47/MAC=00:50:16:8B:00:25) до тестового сервера (IP=151/MAC=00:16:35:C4:25:96).

А слева мы видим, что сервер получает этот пакет, но MAC-адрес источника какой-то «левый». Точнее, сервер получает два пакета от узла NLB (№№29193 и 29195). В строке №29193 — нормальный пакет с нормальными MAC’ами. Та же ерунда с пакетами от IP=151 до IP=47. IP=47 — виртуальный адрес NLB.

«Левый» MAC принадлежит TMG-серверу, который не является шлюзом ни для кого.

Для осмысления мы нарисовали картинку:

MAC1 — сервер, MAC2 — NLB, MAC3 — узел NLB, MAC4 — TMG-сервер.

В начале августа для работы почтовых клиентов Apple мы сделали на TMG правило Internal<->Internal.

Видимо, с тех пор, трафик до NLB «дублировался» через TMG-сервер, несмотря на то, что:

  1. TMG не является шлюзом;
  2. при обмене трафиком между IP=151 и IP=47 (NLB-IP) шлюз вообще не должен использоваться, так как это адреса одного логического сегмента.

А теперь интерес 🙂

Первый человек, с линками объяснивший, почему TMG пытался «маршрутизировать» пакеты, находящиеся в рамках одной сети, получит от меня электронную книгу Михаила Михеева про VMware vSphere (отсюда).

Запись опубликована в рубрике 4.1, Exchange, Microsoft, VMware, vSphere. Добавьте в закладки постоянную ссылку.

20 комментариев: Такой прикольный NLB

  1. Roy говорит:

    странности вы какие-то рассказываете
    исходящий трафик с узла NLB идет по нативным MAC адресам и к NLB вообще никаким боком — обычное сетевое взаимодействие

    TMG у вас одиноко стоящая или в array с NLB?
    статические MAC’и на кошке какие и куда прописаны?
    на виртуальном свиче всякой экзотики вроде VLAN 4096 не наконфигурено ли?

    и нельзя ли картинку внятную сделать. по этой ничего понять невозможно

  2. Андрей Вахитов говорит:

    1) Исходящий трафик с NLB идет по нативным адресам в случае мультикаста. В случае уникаста будет синтетический MAC для каждого узла.
    Кстати, я про это и написал — для NLB-узла один пакет ушел с его MAC-а, а сервер получил два пакета (от NLB-узла и от TMG).
    На NLB-узлах по два сетевых адаптера, оба смотрят в серверный VLAN.
    2) TMG — одинокая виртуалка без NLB.
    3) Статический мак прописан для NLB-адреса Exchange, прописан как раз на роутере.
    4) Виртуальный свитч распределенный, держит несколько VLAN’ов. Других извратов не замечено.
    5) Картинку нарисую завтра.

  3. Roy говорит:

    Судя по дампам и описанию — у вас мультикаст. Почему мы говорим о юникасте?

  4. A.Vakhitov говорит:

    Решил уточнить…

  5. Roy говорит:

    понимания для нужен еще дамп с TMG и значения Seq\Ack всех пакетов

  6. Андрей Вахитов говорит:

    Вот чего нет, того нет.
    Если это поможет, то в журнале TMG часто светились две ошибки:
    — A non-SYN packet was dropped because it was sent by a source that does not have an established connection with the Forefront TMG computer
    — A TCP packet was rejected because it has an invalid sequence number or an invalid acknowledgement number

  7. BSV говорит:

    Ошибка правило «InternalInternal», я честно говоря с трудом могу представить ситуацию где нужно именно такое правило, у меня клиенты с iOS подключаются к OWA через TMG без подобных ухищрений.

    Т.к. TMG внутренним интерфейсом смотрит в ту же сеть где и NLB кластер распространяет multicast пакеты, то ничего удивительного что получая такой трафик TMG, при наличии выше озвученного правила, дублирует его, что просили то и получили 🙂

  8. Mr.Aloof говорит:

    как я понимаю, приз уходит Сергею =)

  9. Roy говорит:

    multicast пакеты с точки зрения NLB — это пакеты идущие на MAC-адрес, у которого в старшем октете младший бит в 1 выставлен
    TMG на такой трафик плевать хотел — у него на интерфейсах такого адреса нет, ничего «дублировать» он не будет
    по крайней мере в нормальных условиях
    какой-нибудь нюанс возможен с arp-proxy, используемым клиентским vpn — если включен
    но вообще, без дампов, по предоставленной фотографии гадать не возьмусь

  10. A.Vakhitov говорит:

    Выложил примерную схему сети.

  11. Alexander E. Vasilev говорит:

    а у нас другая грабля с NLB multicast
    http://forum.dlink.ru/viewtopic.php?f=2&t=144890&hilit=NLB
    с цисками вроде как таких проблем нет. Терзаем D-Link.
    К слову об Outlook Anywhere. Как то бы научиться отключать его для конкретных людей (чтобы автоконфигурация не трогала оутлуки ненужных людей)

  12. Alexander E. Vasilev говорит:

    сам и отвечу на свой каммент
    Отключение Outlook Anywhere для одного пользователя:
    Get-Mailbox –Identity | Set-CASMailbox -MAPIBlockOutlookRpcHttp:$True

    Отключение для всех пользователей:
    Get-Mailbox –ResultSize Unlimited | Set-CASMailbox -MAPIBlockOutlookRpcHttp:$True

  13. A.Vakhitov говорит:

    Мог бы спросить 🙂

  14. Alexander E. Vasilev говорит:

    Такой прикольный D-Link…
    на нашу проблему с NLB он ответил следующее
    Ответ от разработчика:
    Поскольку мы используем ACL для перенаправления NLB пакетов с приходящего на исходящий порт, входящий порт не должен перекрывать исходящий порт. Это наше ограничение.

  15. A.Vakhitov говорит:

    Ввиду сложности дальнейших изысканий ответ BSV считаю ближе к моему мнению.
    Книга уходит ему.
    Оставайтесь с нами, новый конкурс будет на следующей неделе. Приз — еще одна электронная книга Михаила.

  16. Андрей Вахитов говорит:

    2Alexander: У меня какой-то другой русский используется :))
    Они что этим хотели сказать?

  17. Mr.Aloof говорит:

    Андрей, я так и не понял — выключение странного правила помогло?

  18. Alexander E. Vasilev говорит:

    to Андрей.
    Видимо то, что это фича, а не баг )
    sh access_profile действительно показывает первое правило с названием «NLB!», которое создается автоматом после добавления статической ARP с мультикаст MAC. ни заглянуть в правило, ни удалить его низя (

  19. Pavel Nagaev говорит:

    Вообще говоря от NLB нужно держаться подальше и использовать или Hardware Load Balancer или виртуальных на базе линукса полно.

    Микрософт сам об этом говорит.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *