Я испытываю странную проблему, связанную с кластером 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. Откат драйверов назад - это действие теперь ожидается, но до сих пор система работает нормально.
еще раз я нахожу это неудобно трудно устранить эту периодическую проблему, так как теперь я не знаю, какой из вышеперечисленных шагов решил проблему. Скорее всего, это было после установки новых драйверов, но я не знаю об этом прямо сейчас.
Я надеюсь, что некоторые из вас, которые испытывают одну и ту же проблему, могут добавить некоторые заметки / идеи / наблюдения, чтобы мы могли в корне этого.
Я начал видеть, что машины получают неправильные записи таблицы 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 года и использовать входящие в него сетевые команды (поскольку я не видел эту проблему с моим тестированием на этой платформе).
Это чисто умозрительное, но я предполагаю, что может быть какое-то плохое взаимодействие с включенным 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-адрес был выпущен и продолжает объявлять его. Говоря это, сейчас это всего лишь теория.
Какие сетевые карты вы используете? Случайны ли Broadcom (ужас, ужас)?
Вы пробовали обновлять свои прошивки, драйверы и программное обеспечение для совместной работы?
По моему опыту, встроенная прошивка / драйверы / совместная работа могут нанести ущерб серверам Windows, особенно когда задействованы кластеризация и / или Hyper-V.
im, имеющих аналогичную проблему, что отличается от вас, ребята, тот факт, что серверы (случайным образом) в одной и той же подсети перестают пинговать мой SQL-кластер в любой момент времени без переключения / перемещения активного узла в кластере, то есть: Node A - это active, узел B является резервным, внезапно мои серверы приложений теряет связь с SQL Server (узел A - активный). Когда я проверяю их таблицу ARP, я обнаружил, что запись для IP-кластера заполнена MAC-адресом из (узел B - резервный режим). Как-то (я все еще не мог найти причину) сервер приложений обновил свою таблицу ARP. Я уже понюхался с wirehark и не смог получить ответ ARP, содержащий это изменение.
С Уважением,
Виктор
Мы видели по существу то же поведение, но под 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 с этими сетевыми адаптерами или вообще не использовать эти сетевые адаптеры - или, как представляется, это обходной путь. Если проблема действительно исчезла с новыми ядрами, я сомневаюсь, что будет исправление - может быть, случай, когда ошибка ОС щекочет нежелательное поведение сетевого адаптера.