Вопрос: Переключение кластеров и странное беспричинное поведение arp


Я испытываю странную проблему, связанную с кластером Windows 2008R2, которая беспокоит меня. Я чувствую, что близко подошел к вопросу, но все еще не совсем понимаю, что происходит.

У меня есть кластер с двумя узлами Exchange 2007, работающий на двух серверах 2008R2. Приложение кластерного кластера отлично работает при запуске на «основном» узле кластера. Проблема возникает при сбое в переходе от кластера к второму узлу.

При отказе от кластера к «второстепенному» узлу, который, например, находится в той же подсети, что и «первичный», восстановление после сбоев первоначально работает нормально, а ресурс кластера продолжает работать в течение нескольких минут на новом узле. Это означает, что получающий узел отправляет бесплатный ответный пакет arp, который обновляет таблицы arp в сети. Но после x времени (обычно в течение 5 минут) что-то обновляет arp-таблицы снова, потому что внезапно служба кластера не отвечает на пинги.

Поэтому в основном я запускаю ping на адрес обменного кластера, когда он работает на «основном узле». Он отлично работает. Я отказываюсь от группы ресурсов ressource к «второстепенному узлу», и у меня есть только потеря одного пинга, который является приемлемым. Ресурс кластера все еще отвечает в течение некоторого времени после того, как его не удалось, и внезапно ping начинает отсчет времени.

Это говорит мне, что первоначально таблица arp обновляется вторичным узлом, но затем что-то (что я еще не обнаружил) неправомерно обновляет его снова, возможно, с MAC-адресом первичного узла.

Почему это происходит - кто-нибудь испытал ту же проблему?

В кластере НЕ запускается NLB, и проблема перестает работать после сбоя назад к основному узлу, где нет проблем.

Каждый узел использует NIC teaming (intel) с ALB. Каждый узел находится в одной и той же подсети и имеет шлюз и т. Д., Введенный правильно, насколько мне известно.

Редактировать:
Мне было интересно, может ли это быть связано с привязкой к сети, может быть? Поскольку я заметил, что единственное отличие, которое я вижу от узла к узлу, - это показать локальную таблицу arp. На «первичном» узле таблица arp создается на адрес кластера в качестве источника. В то время как на «вторичном» его генерируется из собственной сетевой карты узлов.

Любой ввод по этому вопросу?

Редактировать:
Хорошо, вот схема подключения.

Адрес кластера: A.B.6.208 / 25 Адрес приложения Exchange: A.B.6.212 / 25

Узел A: 3 физических лица. Два из них объединились, используя сети, объединившиеся с адресом A.B.6.210 / 25, называемым public Последний используется для трафика кластера, называемого private с 10.0.0.138/24

Узел B: 3 физических лица. Два из них объединились, используя сети, объединившиеся с адресом A.B.6.211 / 25, называемым public Последний используется для кластерного трафика, называемого private с 10.0.0.139/24

Каждый узел находится в отдельном центре данных, соединенном вместе. Конечные выключатели являются cisco в DC1 и NEXUS 5000/2000 в DC2.

Редактировать:
Я тестировал немного больше. Теперь я создал пустое приложение в одном кластере и дал ему другой IP-адрес в той же подсети, что и приложение обмена. После провала этого пустого приложения я вижу ту же самую проблему. Через одну или две минуты клиенты в других подсетях не могут пинговать виртуальный ip приложения. Но в то время как клиенты в других подсетях не могут, другой сервер из другого кластера в той же подсети не имеет проблем с ping. Но если я затем сделаю другой переход на исходное состояние, тогда ситуация будет противоположной. Так что теперь клиенты в одной подсети не могут, а на других они могут. У нас есть другой кластер, настроенный таким же образом и в той же подсети, с теми же сетевыми картами Intel, теми же драйверами и теми же настройками команды. Здесь мы этого не видим. Так что это несколько запутанно.

Редактировать:
ОК сделал еще несколько исследований. Удалено объединение NIC вторичного узла, так как оно все равно не работает. После некоторых стандартных проблем, последовавших за этим, я, наконец, смог снова запустить его и запустить с настройками старого сетевого адаптера на одной физической сетевой карте. Теперь я не могу воспроизвести описанную выше проблему. Так что это как-то связано с объединением - может быть, какая-то ошибка?

Редактировать:
Еще несколько неудач, неспособных сделать это неудачным. Поэтому удаление команды NIC выглядит так, как будто это было обходным путем. Теперь я попытался восстановить интеграцию Intel NIC с ALB (как это было раньше), и я все еще не могу сделать это неудачно. Это раздражает из-за того, что теперь я фактически не могу определить корень проблемы. Теперь кажется, что это какой-то MS / intel hick-up, который трудно принять, потому что, если проблема повторится за 14 дней? Однако есть странная вещь. После воссоздания команды NIC я не смог переименовать команду в «PUBLIC», которую вызвала старая команда. Так что что-то не было очищено в окнах - хотя сервер был перезапущен!

Редактировать:
ОК после восстановления команды ALB ошибка вернулась. Поэтому я собираюсь провести тщательное тестирование, и я вернусь с моими наблюдениями. Одно можно сказать точно. Это связано с Intel 82575EB NICS, ALB и Gratuitous Arp.


Я как-то счастлив услышать это :) Теперь я собираюсь выяснить, что вызывает это, проводя интенсивное тестирование. Надеюсь вернуться с некоторыми результатами. Я не видел этих проблем с Broadcom.

@Kyle Brandt: Какие версии драйверов у вас есть в системе, в которой вы видели это? Пожалуйста, предоставьте версию драйвера NIC и версию Teaming Driver.

Я выполняю 11.7.32.0 и 9.8.17.

Я знаю, что эти драйверы действительно очень старые - но поскольку эта проблема возникает только периодически, очень сложно устранить проблему, если обновление драйверов решит проблему. На данный момент у меня есть fx, пытающийся использовать этот план действий: 1. Удалите команду ALB - не удалось спровоцировать ошибку. 2. Восстановить команду ALB. Проблема снова появилась. 3. Попробуйте AFT (Adapter Fault Tolerance) - проблема исчезла 4 Установите новейшие драйверы и снова запустите команду ALB (попробовали с 11.17.27.0) - Проблема исчезла 5. Откат драйверов назад - это действие теперь ожидается, но до сих пор система работает нормально.

еще раз я нахожу это неудобно трудно устранить эту периодическую проблему, так как теперь я не знаю, какой из вышеперечисленных шагов решил проблему. Скорее всего, это было после установки новых драйверов, но я не знаю об этом прямо сейчас.

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


6
2017-08-08 10:20


Источник


Какие переключатели вы используете и какова общая схема соединений? - Chris S
Я вижу такое же поведение в своем кластере SQL Server. Я как раз собирался опубликовать свой «ответ» (serverfault.com/a/415531/889) ниже, как отдельный вопрос, когда я заметил это. - Steven Murawski
Единственное отличие Стивена, однако, в том, что в вашем описании вы получаете сбои соединения на клиентах в одной и той же подсети. В моем случае только клиенты в разных подсетях получают тайм-ауты ping (сбои подключения). - lazerpld
Извините, что нужно исправить это сейчас. Не имеет значения, пишу ли я из той же или другой подсети. Условие изменяется в зависимости от того, на каком узле работает приложение. - lazerpld
В этот уик-энд увидел то же самое, что и Intel ALB, отказоустойчивость кластеров Microsoft и SQL 2012 AlwaysOn на 2008R2. У меня не было возможности попробовать, не объединившись. Но с Wireshark я заметил, что резервная машина отправляет ARP, заявляя, что у нее все еще есть виртуальный IP-колодец после того, как другая машина взяла VIP. - Kyle Brandt♦


Ответы:


Я начал видеть, что машины получают неправильные записи таблицы ARP для нескольких экземпляров SQL Server в отказоустойчивом кластере.

Клиентские серверы альтернативно заполняют свои таблицы ARP MAC-адресами из правильной команды NIC и MAC-адресом от одного из физических NIC (не обязательно соответствующего MAC-сети NIC на этом сервере) на другом узле кластера.

Это вызывает прерывистые сбои подключения для клиентов в той же локальной сети, что и кластер SQL.

Такое поведение было отмечено как VM-клиентами, так и физическими коробками.

Это происходит после отказа и длится несколько дней.

Чтобы смягчить это, мне пришлось устанавливать статические записи arp на более проблемных клиентах.

ОКРУЖАЮЩАЯ СРЕДА:

  • Серверы Windows 2008 R2 SP1 в отказоустойчивом кластере
  • Экземпляры SQL Server 2008 R2
  • Превосходный Intel Gigabit NICS
  • Коммутаторы HP 28XX
  • Виртуальные машины, размещенные на Windows Server 2008 R2 SP1 Hyper-V

Команда Intel NIC создает виртуальный адаптер с MAC-адресом одного из физических сетевых адаптеров.

У меня есть подозрение, что программное обеспечение Intel NIC teaming является виновником, но любые другие мысли и решения по устранению неполадок будут оценены.

Вероятно, я собираюсь перестроить хосты кластера с помощью сервера 2012 года и использовать входящие в него сетевые команды (поскольку я не видел эту проблему с моим тестированием на этой платформе).


2
2017-08-08 14:15



вы можете настроить команду NIC на любой MAC-адрес, который вы хотите. вы пытались присвоить ему другой MAC? - longneck
У меня нет, но команда MAC не обязательно является проблемой, а именно, что MAC-адреса от базовых NIC на другом узле находят свой путь к таблице ARP на клиентах. - Steven Murawski
Я дам ему шанс. Благодаря! - Steven Murawski
Стивен, возможно, вы также можете попытаться удалить команду и просто запустить на одной сетевой карте, чтобы узнать, разрешает ли она вашу проблему? Тогда у нас есть хоть что-то общее :) - lazerpld
Мы работаем над настройкой окна обслуживания, чтобы попробовать это. Нарушение команды приведет к сбою узла в кластере, поэтому нам придется ждать окна обслуживания, чтобы сделать что-то подобное. - Steven Murawski


У вас установлены последние исправления для кластера? Существуют некоторые довольно серьезные известные дефекты.

Сбой переходной связи приводит к тому, что отказоустойчивый кластер Windows Server 2008 R2 перестает работать
https://support.microsoft.com/kb/2550886 

Медленная операция перехода на другой ресурс, если между кластером и сервером приложений не существует маршрутизатора
https://support.microsoft.com/kb/2582281 

«Эта проблема возникает из-за того, что стек TCP / IP сервера приложений неправильно игнорирует безвозмездные запросы протокола разрешения адресов (ARP)».


2
2017-08-08 14:23



Дорогой Грег, я видел эти исправления, но не описания, которые вписываются в вышесказанное. Первое, потому что мне просто нужно вернуть приложение обратно, чтобы он снова работал. Последнее из-за того, что переход на другой ресурс не замедляется. Это не очень здорово. Но спасибо за вход! - lazerpld


Это чисто умозрительное, но я предполагаю, что может быть какое-то плохое взаимодействие с включенным RLB (которое включается по умолчанию, а с Lazerpld, Steven и Stack Exchange все ударили по этой ошибке сейчас). Из Intel объединяет технический документ:

Балансировка загрузки (RLB) является подмножеством ALB. Это позволяет трафику   поток как в Tx, так и Rx на всех адаптерах в команде. При создании   Команда RLB в Windows, эта функция включена по умолчанию. Может быть   отключен через графический интерфейс Intel PROSet с использованием расширенной команды   Настройки.

В режиме RLB, когда клиент пытается подключиться к команде, отправив   сообщение запроса ARP, Intel ANS берет на себя управление сервером ARP   ответное сообщение, поступающее из стека TCP в ответ.После этого Intel ANS   копии в ARP ответят MAC-адрес одного из портов в   команда, выбранная для обслуживания конкретного конечного клиента, согласно RLB   алгоритм. Когда клиент получает это ответное сообщение, он включает это   соответствие между IP-адресом команды и заданным MAC-адресом в локальном ARP   Таблица. Впоследствии все пакеты от этого конечного клиента будут получены   по выбранному порту. В этом режиме Intel ANS выделяет членов команды на   подключений конечного клиента к сервису в циклическом режиме, поскольку   клиенты запрашивают подключения к серверу. Для достижения справедливого   распределение конечных клиентов среди всех включенных членов в команде,   Таблица клиентов RLB обновляется с равными интервалами (по умолчанию пять   минуты). Это интервал приема, который является   предварительно настроенная настройка в реестре. Обновление включает в себя выбор   новые члены команды для каждого клиента по мере необходимости. Intel ANS инициирует ARP   Отвечает затронутым клиентам новый MAC-адрес для подключения   и перераспределение трафика приема завершается, когда все клиенты   обновили таблицы ARP в Intel ANS.

ОС может отправлять ARP-запросы в любое время, и они не находятся под   управление драйвером Intel ANS. Это отправленные широковещательные пакеты   через основной порт. Поскольку пакет запроса передается   с MAC-адресом команды (MAC-адрес основного порта в   команда), все конечные клиенты, подключенные к команде, будут обновлять   их таблицы ARP, связывая IP-адрес команды с MAC   адрес основного порта. Когда это произойдет, принимающая нагрузка   эти клиенты обрушиваются на основной порт.

Чтобы перезапустить балансировку нагрузки Rx, Intel ANS отправляет бесплатный ARP для всех   клиентов в хэш-таблице приема, которые   непереносные порты, с MAC-адресом соответствующей команды   члены. Кроме того, запрос ARP, отправленный ОС, сохраняется в   RLB хеш-таблицу, и когда ответ ARP получен от конца   клиент, MAC-адрес клиента обновляется в хеш-таблице. Эта   является тем же механизмом, который используется для включения RLB, когда сервер инициирует   подключение.

Поэтому моя теория заключается в том, что, возможно, когда кластеры Windows выпускают виртуальный IP-адрес, драйвер Intel не видит, что IP-адрес был выпущен и продолжает объявлять его. Говоря это, сейчас это всего лишь теория.


1
2017-09-17 18:47



Одним из тестов этой теории было бы отключить эту функцию ... проблема в том, что это может вызвать прерывание сети, которое может инициировать переход на другой ресурс ... - Steven Murawski


Какие сетевые карты вы используете? Случайны ли Broadcom (ужас, ужас)?

Вы пробовали обновлять свои прошивки, драйверы и программное обеспечение для совместной работы?

По моему опыту, встроенная прошивка / драйверы / совместная работа могут нанести ущерб серверам Windows, особенно когда задействованы кластеризация и / или Hyper-V.


0
2017-08-08 19:04



В обоих учетных документах упоминаются Intel NIC. - Steven Murawski
Хорошо. Но я тоже видел множество багги-драйверов. (Teaming + VLAN + Hyper-V был Королевская боль пока они окончательно не зафиксировали их). - Massimo
Я вас слышу ... Я не могу дождаться начала перехода на сервер 2012 года. Объединение LBFO NIC в ящике было довольно прочным в тестировании и действительно легко настраивается. - Steven Murawski


im, имеющих аналогичную проблему, что отличается от вас, ребята, тот факт, что серверы (случайным образом) в одной и той же подсети перестают пинговать мой SQL-кластер в любой момент времени без переключения / перемещения активного узла в кластере, то есть: Node A - это active, узел B является резервным, внезапно мои серверы приложений теряет связь с SQL Server (узел A - активный). Когда я проверяю их таблицу ARP, я обнаружил, что запись для IP-кластера заполнена MAC-адресом из (узел B - резервный режим). Как-то (я все еще не мог найти причину) сервер приложений обновил свою таблицу ARP. Я уже понюхался с wirehark и не смог получить ответ ARP, содержащий это изменение.

С Уважением,

Виктор


0
2018-01-08 18:35



Его действительно не подходит для ответа на вопрос с ответом «меня тоже». Благодарю. - mdpc
Ты серьезно? Очень полезно читать полный пост, прежде чем писать что-то, приятель. Автор из этого сообщения писал: «Я надеюсь, что некоторые из вас, которые испытывают одну и ту же проблему, могут добавить некоторые заметки / идеи / наблюдения, чтобы мы могли в корне этого». Ну, я думаю, что мой «ответ» был наблюдением за этим вопросом. Он имеет небольшое отличие от других. Если вы действительно ничего не добавляете к нашей дискуссии, пожалуйста, прочитайте и сохраните свои мысли для себя. спасибо - VictorSilva


Мы видели по существу то же поведение, но под Linux. Мы поставили диагноз еще немного.

Мы можем вытащить VIF из связи alb на одном сервере и принести VIF с тем же IP-адресом на другую связь alb на другом сервере. , , и рабыня интерфейсы с первого сервера продолжают извергать нежелательные ответы ARP для IP-адреса VIF, в результате чего пинги от клиентов начинают отбрасываться по мере их перенаправления на первый сервер. Это как если бы какой-то фрагмент кода, возможно, тот, который отвечает за маскировку RLB MAC, застревает в цикле, не получив записку о снятии VIF.

редактировать: чтобы подчеркнуть, подчиненные интерфейсы исходного сервера не извергают бесплатные ARP, но незатребованные ответы ARP на клиента. Критически, если вы принесете нового клиента онлайн, он отправит ARP-запрос, второй сервер ответит, и все будет хорошо. Но первоначальный клиент не сможет разговаривать со вторым сервером на VIF IP до тех пор, пока первый сервер каким-то образом не сможет продолжить поток нераспределенных ответов ARP (например, перезапуск сетевой сети).

Что мы узнали:

Только проблема с Intel NIC (драйвер e1000e). Воспроизводится с последними драйверами до 2.4.x на разных ядрах.

Только проблема с облигациями alb.

Легко воспроизводится при RHEL5.3, более сложном для воспроизведения под RHEL5.5, кажется, что он находится под RHEL5.8 - немного странно, поскольку модуль склеивания сильно не изменился между 5,5 и 5,8. Однако, учитывая вышеприведенный отчет для Windows, кажется разумным сделать вывод, что в драйвере / прошивке NIC что-то не так.

Мы еще не получили причину первопричины, но можем просто прекратить использование режима 6 с этими сетевыми адаптерами или вообще не использовать эти сетевые адаптеры - или, как представляется, это обходной путь. Если проблема действительно исчезла с новыми ядрами, я сомневаюсь, что будет исправление - может быть, случай, когда ошибка ОС щекочет нежелательное поведение сетевого адаптера.


0
2018-05-23 00:19