Меня беспокоит странная проблема, связанная с кластером Windows 2008R2. Я чувствую, что подошел близко к тому, в чем проблема, но до сих пор не совсем понимаю, что происходит.
У меня есть кластер обмена 2007 с двумя узлами, работающий на двух серверах 2008R2. Приложение кластера обмена отлично работает при работе на «основном» узле кластера. Проблема возникает при переключении ресурса кластера на вторичный узел.
При переключении кластера на «вторичный» узел, который, например, находится в той же подсети, что и «первичный», аварийное переключение первоначально работает нормально, и ресурс кластера продолжает работать в течение нескольких минут на новом узле. Это означает, что принимающий узел действительно отправляет бесплатный ответный пакет arp, который обновляет таблицы arp в сети. Но по прошествии x времени (обычно в течение 5 минут) что-то снова обновляет таблицы arp, потому что внезапно служба кластеров не отвечает на эхо-запросы.
Так что в основном я запускаю эхо-запрос на адрес кластера обмена, когда он работает на «основном узле». Работает просто отлично. Я переключаю группу ресурсов кластера на «вторичный узел» и теряю только один пинг, что приемлемо. Ресурс кластера все еще отвечает в течение некоторого времени после сбоя, и внезапно время ожидания проверки связи начинает истекать.
Это говорит мне о том, что таблица arp изначально обновляется вторичным узлом, но затем что-то (что я еще не обнаружил) ошибочно обновляет ее снова, вероятно, с MAC-адресом первичного узла.
Почему это происходит - сталкивался ли кто-нибудь с такой же проблемой?
Кластер НЕ использует NLB, и проблема сразу же прекращается после переключения на основной узел, где проблем нет.
Каждый узел использует объединение сетевых карт (Intel) с ALB. Насколько мне известно, каждый узел находится в одной подсети и имеет правильный шлюз и т. Д.
Редактировать:
Мне было интересно, может быть, это связано с порядком привязки к сети? Потому что я заметил, что единственное различие, которое я вижу от узла к узлу, - это отображение локальной таблицы arp. На «первичном» узле таблица arp создается на адресе кластера в качестве источника. В то время как на «вторичном» он генерируется из собственной сетевой карты узлов.
Есть какие-нибудь мнения по этому поводу?
Редактировать:
Хорошо, вот схема подключения.
Адрес кластера: A.B.6.208 / 25 Адрес приложения обмена: A.B.6.212 / 25
Узел A: 3 физических модуля. Двое объединились в команду Intel с адресом A.B.6.210 / 25, который называется общедоступным. Последний, используемый для трафика кластера, называется частным с адресом 10.0.0.138/24.
Узел B: 3 физических модуля. Двое объединились в команду Intel с адресом A.B.6.211 / 25, который называется общедоступным. Последний, используемый для трафика кластера, называется частным с адресом 10.0.0.139/24.
Каждый узел находится в отдельном центре обработки данных, соединенном вместе. Конечные переключатели - это cisco в DC1 и NEXUS 5000/2000 в DC2.
Редактировать:
Я еще немного тестировал. Теперь я создал пустое приложение в том же кластере и дал ему другой IP-адрес в той же подсети, что и приложение обмена. После отказа от этого пустого приложения я вижу точно такую же проблему. По истечении одной или двух минут клиенты в других подсетях не могут пропинговать виртуальный IP-адрес приложения. Но в то время как клиенты в других подсетях не могут, другой сервер из другого кластера в той же подсети не имеет проблем с проверкой связи. Но если затем я снова переключусь на исходное состояние, ситуация будет противоположной. Теперь клиенты в одной подсети не могут, а в другой - могут. У нас есть другой кластер, настроенный таким же образом и в той же подсети, с теми же сетевыми картами Intel, теми же драйверами и теми же настройками совместной работы. Здесь мы этого не видим. Так что это несколько сбивает с толку.
Редактировать:
ОК, сделал еще несколько исследований. Удалено объединение сетевых адаптеров вторичного узла, так как оно все равно не работает. После некоторых стандартных проблем, последовавших за этим, мне, наконец, удалось снова запустить его со старыми настройками объединения сетевых адаптеров на одной физической сетевой карте. Теперь я не могу воспроизвести описанную выше проблему. Так что это как-то связано с объединением в команду - может какая-то ошибка?
Редактировать:
Сделал еще несколько отказов, но не смог сделать это. Таким образом, удаление команды NIC выглядит как обходной путь. Теперь я попытался восстановить совместную работу Intel NIC с ALB (как это было раньше), и я все еще не могу заставить его выйти из строя. Это раздражает из-за того, что теперь я фактически не могу определить корень проблемы. Теперь это просто похоже на провал MS / Intel, с чем трудно согласиться, потому что что, если проблема повторится через 14 дней? Однако произошла странная вещь. После воссоздания команды NIC я не смог переименовать команду в "PUBLIC", как называлась старая команда. Значит, в windows что-то не убрали - хотя сервер БЫЛ перезапущен!
Редактировать:
ОК, после восстановления объединения ALB ошибка вернулась. Итак, я собираюсь провести тщательное тестирование и вернусь со своими наблюдениями. Одно можно сказать наверняка. Это связано с Intel 82575EB NICS, ALB и Gratuitous Arp.
Я как-то рад это слышать :) Теперь я собираюсь выяснить, что вызывает это, путем интенсивного тестирования. Надеюсь вернуться с некоторыми результатами. Я не видел таких проблем с Broadcom.
@ Кайл Брандт: Какие версии драйверов у вас есть в системе, на которой вы это видели? Укажите версию драйвера сетевой карты и версию драйвера Teaming.
Я использую 11.7.32.0 и 9.8.17.
Я точно знаю, что эти драйверы действительно ОЧЕНЬ старые, но поскольку эта проблема возникает только периодически, очень трудно устранить неполадки, если обновление драйверов решает проблему. На данный момент у меня fx попытался использовать этот план действий: 1. Удалите объединение ALB - не удалось спровоцировать ошибку 2. Восстановить объединение ALB - проблема появилась снова 3. Попробуйте AFT (отказоустойчивость адаптера) - проблема снова исчезла 4 Установите новейшие драйверы и снова запустите ALB teaming (пробовал с 11.17.27.0) - проблема исчезла 5. Откатить драйверы - это действие сейчас отложено, но до сих пор система работает нормально.
И снова я считаю, что устранять эту периодическую проблему крайне сложно, так как теперь я понятия не имею, какой из вышеперечисленных шагов решил проблему. Скорее всего, это было после установки новых драйверов - но сейчас я не знаю наверняка.
Я надеюсь, что некоторые из вас, кто сталкивается с той же проблемой, могут добавить несколько примечаний / идей / наблюдений, чтобы мы могли найти корень этого.
Установлены ли у вас последние исправления кластера? Известны довольно серьезные дефекты.
Временный сбой связи приводит к тому, что отказоустойчивый кластер Windows Server 2008 R2 перестает работать
https://support.microsoft.com/kb/2550886
Медленная отработка отказа, если между кластером и сервером приложений нет маршрутизатора
https://support.microsoft.com/kb/2582281
«Эта проблема возникает из-за того, что стек TCP / IP сервера приложений неправильно игнорирует беспричинные запросы протокола разрешения адресов (ARP)».
Я начал замечать, что машины получают неправильные записи в таблице ARP для нескольких экземпляров SQL Server в отказоустойчивом кластере.
В качестве альтернативы клиентские серверы заполняют свои таблицы ARP MAC-адресами от правильной группы сетевых адаптеров и MAC-адресами от одной из физических сетевых адаптеров (не обязательно соответствующий MAC-адрес группы сетевых адаптеров на этом сервере) на другом узле кластера.
Это вызывает периодические сбои подключения для клиентов в той же локальной сети, что и кластер SQL.
Такое поведение было отмечено как клиентами виртуальных машин, так и физическими ящиками.
Это происходит после аварийного переключения и длится несколько дней.
Чтобы смягчить это, мне пришлось установить статические записи arp для более проблемных клиентов.
ОКРУЖАЮЩАЯ СРЕДА:
Команда Intel NIC создает виртуальный адаптер с MAC-адресом одной из физических NIC.
У меня есть подозрение, что виновником является программное обеспечение Intel NIC teaming, но любые другие мысли или решения по устранению неполадок будут признательны.
Я, скорее всего, собираюсь перестроить узлы кластера с помощью Server 2012 и использовать там объединение встроенных сетевых адаптеров (поскольку я не видел этой проблемы при тестировании на этой платформе).
Это чисто умозрительно, но я предполагаю, что может быть какое-то плохое взаимодействие с включенным RLB (который включается по умолчанию, а с Lazerpld, Steven и Stack Exchange все столкнулись с этой ошибкой сейчас). Из Технический документ Intel teaming:
Балансировка нагрузки приема (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-адрес был выпущен, и продолжает объявлять об этом. При этом, сейчас это всего лишь теория.
Какие сетевые карты вы используете? Случайные Broadcom (ужас, ужас)?
Вы пробовали обновить их прошивку, драйверы и программное обеспечение для совместной работы?
По моему опыту, ошибочные прошивки / драйверы / объединение могут нанести ущерб серверам Windows, особенно когда задействованы кластеры и / или Hyper-V.
У меня аналогичная проблема, от вас, ребята, отличает то, что серверы (случайным образом) в одной подсети перестают пинговать мой SQL-кластер в любой момент времени без переключения / перемещения активного узла в кластере, то есть: узел A - это активен, узел B является резервным, внезапно мои серверы приложений теряют связь с SQL Server (узел A - активен). Когда я проверял их таблицу ARP, я обнаружил, что запись для IP-адреса кластера заполнена MAC-адресом из (узел B - резервный). Каким-то образом (я все еще не мог найти причину) сервер приложений обновил свою таблицу ARP. Я уже обнюхал wirehark и не получил ни одного ответа ARP, содержащего это изменение.
С Уважением,
Виктор
По сути, мы наблюдали такое же поведение, но в Linux. Мы поставили диагноз немного дальше.
Мы можем извлечь VIF из связи alb на одном сервере и перенести VIF с тем же IP на другую связь alb на другом сервере. . . и раб интерфейсы с первого сервера продолжают извергать незапрашиваемые ответы ARP для IP VIF, в результате чего эхо-запросы от клиентов начинают сбрасываться по мере их маршрутизации на первый сервер. Это как если бы какой-то фрагмент кода - возможно, ответственный за маскировку MAC RLB - застрял в цикле, не получив записки о том, что VIF отключен.
редактировать: чтобы подчеркнуть, что подчиненные интерфейсы исходного сервера не излучают беспричинные ARP-пакеты, а не запрашивают ARP-ответы клиенту. Важно то, что если вы подключите нового клиента к сети, он отправит запрос ARP, второй сервер ответит, и все будет хорошо. Но исходный клиент не сможет разговаривать со вторым сервером по IP-адресу VIF до тех пор, пока первому серверу каким-то образом не запретят продолжать свой поток незапрошенных ответов ARP (например, перезапуск сети обслуживания).
Что мы узнали:
Только проблема с Intel NIC (драйвер e1000e). Воспроизводится с последними версиями драйверов до 2.4.x для различных ядер.
Только проблема с альб-бондами.
Легко воспроизвести в RHEL5.3, сложнее воспроизвести в RHEL5.5, похоже, исчезло в RHEL5.8 - немного странно, поскольку модуль связывания не сильно изменился между 5.5 и 5.8. Однако, учитывая, что отчет выше относится к Windows, кажется разумным сделать вывод, что что-то не так с драйвером / прошивкой сетевой карты.
Мы еще не выяснили основную причину, но можем просто прекратить использовать режим 6 с этими сетевыми адаптерами или вообще прекратить использование этих сетевых адаптеров - либо это может быть обходным путем. Если проблема действительно исчезла с новыми ядрами, я сомневаюсь, что исправление будет - это может быть случай, когда ошибка ОС вызвала нежелательное поведение сетевой карты.