Рассмотрим на нашем примере наиболее удобный способ настройки службы, используя мастер балансировки нагрузки сети (Network Load Balancing Manager).
NLB менеджер: Внешний вид окна.
В этой статье также подробно описана настройка параметров кластера, режимы Unicast и Multicast, а также разница между ними. Уделим много внимания правилам портов…
План:
2. Использование Network Load Balancing Manager для конфигурирования кластера и узлов:
Рассмотрим на нашем примере наиболее удобный способ настройки службы, используя мастер балансировки нагрузки сети (Network Load Balancing Manager).
Для настройки кластера необходимо выполнить такие шаги:
Administrative Tools: Запуск NLB менеджера.
Далее перед вами откроется следующее окно:
NLB менеджер: Внешний вид окна.
NLB менеджер: Создание нового кластера
NLB менеджер. Диалог создания кластера: Параметры кластера.
IP address (Основной IP-адрес) – общий для всех узлов. Является виртуальным, непривязанным к определенному MAC адресу.
Subnet mask (Маску подсети) – соответствующее указанному выше IP.
Full Internet name (Полное интернет-имя кластера) – соответствующее указанному выше IP.
По указанному IP-адресу генерируется Network address (MAC адрес кластера). Для каждого режима генерируется свой, уникальный MAC адрес.
Здесь же необходимо определиться с Cluster operation mode (Режим работы кластера). Сразу объясню, в чем здесь разница:
В режиме Unicast (одноадресной) рассылки MAC-адрес кластера назначается сетевому адаптеру компьютера, а встроенный MAC-адрес сетевого адаптера не используется.
Основные характеристики данного режима:
• MAC-адрес кластера (автоматически генерируемый балансировкой нагрузки сети) используется вместо этого адреса.
• Адаптер становится по сути кластерным адаптером.
• И выделенный IP-адрес, и IP-адрес кластера разрешаются в кластерный MAC-адрес.
• Поскольку все узлы кластера разделяют один MAC-адрес, а оригинальный MAC-адрес не используется, обычная сетевая связь между этим узлом и другими узлами кластера невозможна. Однако этот компьютер по-прежнему может обрабатывать трафик, приходящий из-за пределов подсети, в которой расположен кластер, а также из подсети, если датаграмма IP не содержит MAC-адреса, используемого кластерным адаптером. Эту проблему можно обойти используя несколько сетевых адаптеров: один для кластерного трафика, второй для взаимодействия узлов между собой.
Также используя NLB Manager для настройки кластера в этом режиме, необходимо этот менеджер запускать на не принадлежащем кластеру сервере.
В режиме Multicast (многоадресной) рассылки MAC-адрес кластера назначается сетевому адаптеру компьютера, но встроенный адрес сетевого адаптера сохраняется и используются оба адреса: первый — для трафика клиент-кластер, а второй — для сетевого трафика, специфичного для компьютера.
Основные характеристики данного режима:
• Собственный уникальный MAC-адрес адаптера сохраняется.
• IP-адрес кластера разрешается в MAC-адрес кластера.
• Выделенный IP-адрес разрешается в оригинальный MAC-адрес.
При использовании данного режима возможны затруднения в переводе основного IP-адреса в групповой аппаратный адрес (MAC) с использованием протокола ARP.
Лучше узнать у хостера, что за маршрутизатор он использует и может он работать с групповым MAC.
Технически это проверяется так:
Перед созданием кластера добавляем IP адреса кластер в TCP\IP протоколе одного из серверов, и проверяем, работают ли они вообще, с помощью Ping. После этого создаем кластер. Если по прошествии некоторого времени, после того, как обновится Кеш ARP записей на маршрутизаторе (в зависимости от настроек), адреса кластера перестают пинговаться с наружи сети, но из компьютеров этой подсети пингуются нормаль. Это означает, что маршрутизатор не может работать с групповым MAC. Это можно обойти, добавив статические записи ARP в маршрутизатор или использовать Unicast.
NLB менеджер. Диалог создания кластера: IP адреса кластера.
В нашем случае здесь мы указываем выделенные виртуальные IP адреса кластера. Трафик с этих адресов будет равномерно распределятся между узлами кластера.
NLB менеджер. Диалог создания кластера: Правила портов.
По умолчанию стоит общее для всех правило, по которому обрабатываются все порты (0-65535) как для TCP, так и для UDP, равномерно распределяя нагрузку между всеми узлами NLB-кластера и указывая вариант Single (Один) для родственности (affinity), чтобы все пакеты, поступившие с одного и того же IP-адреса, обрабатывались одним узлом NLB-кластера.
Рассмотрим по подробнее каждый из предложенных параметров:
NLB менеджер. Диалог создания кластера. : Опции добавления\редактирования правил портов.
NLB менеджер. Диалог создания кластера.: Режим фильтрации в окне добавления\редактирования правил портов
Port Range (Диапазон портов). В этой секции задается диапазон портов, который будет охватываться данным правилом для портов. Можно указывать любые номера в диапазоне от 0 до 65535 (и это также диапазон по умолчанию). Чтобы задать один порт, введите одинаковые значения для начального и конечного номеров.
Protocols (Протоколы). Выберите конкретный протокол TCP/IP, который будет охватываться данным правилом для портов (вариант TCP, UDP или Both [Оба]). Это правило будет влиять на сетевой трафик только указанного здесь протокола. Весь остальной трафик будет обрабатываться с использованием режима фильтрации по умолчанию.
Filtering Mode (Режим фильтрации). Чтобы задать, что сетевой трафик для этого правила будет обрабатываться несколькими узлами данного кластера, выберите вариант Multiple Hosts (Несколько узлов). Распределяя нагрузку между несколькими узлами, вы получаете свойства отказоустойчивости и масштабирования производительности. Режим фильтрации позволяет также выбрать равномерную нагрузку между узлами или задать определенный процент нагрузки для конкретного узла.
Выберите вариант Single Host (Один узел), чтобы задать, что сетевой трафик для данного правила должен обрабатываться каким-либо одним узлом в кластере согласно заданному для него приоритету обработки (поле Handling priority). Этот приоритет используется вместо приоритета (идентификатора узла) для трафика через данный порт.
Выберите вариант Disabled (Отключен), чтобы задать, что сетевой трафик для этого правила должен быть блокирован. Это удобный способ создания брандмауэра, препятствующего сетевому доступу к заданному диапазону портов.
Affinity (Родственность). Вариант «родственности» с клиентами определяет, каким образом NLB будет назначать входящий трафик узлам кластера. Основное назначение этого параметра — поддержка приложений, для которых требуется, чтобы все запросы с одного и того же клиентского компьютера обрабатывались одним сервером NLB (то есть приложений, которые поддерживают определенный вид информации о состоянии клиента на этом сервере). Для алгоритма распределения используются части исходного IP-адреса в пакете, чтобы определить, какой сервер в кластере будет обрабатывать этот пакет.
Варианты родственности Single (Один) или Class C (Класса C) может вызвать неравномерное распределение запросов по узлам кластера.
Выберите вариант None (Нет), чтобы задать, что служба NLB не обязательно должна направлять несколько запросов с одного клиентского компьютера на один узел кластера. В результате алгоритм хеширования NLB будет использовать все 4 байта IP-адреса отправителя в сочетании с исходным портом TCP или UDP при выборе узла NLB для обработки пакета. TCP/UDP изменяет исходный порт почти с каждым запросом, поэтому выбор варианта None дает всем узлам кластера возможность обработки пакетов от любого заданного клиентского компьютера.
Выберите варианта Single (вариант по умолчанию), чтобы задать, что несколько запросов с одного исходного IP-адреса должны направляться на один узел кластера. При выборе варианта родственности Single алгоритм хеширования NLB игнорирует исходный порт TCP или UDP. Родственность оказывает негативное влияние на производительность, но в определенных обстоятельствах это перевешивается эффективностью для клиента, направляющего несколько запросов. Например, если каждый запрос от клиента связывается с cookie-файлом, то более эффективно подсоединять этого клиента к одному узлу (на самом деле это необходимо). Для защищенных приложений HTTP (HTTPS через TCP Port 443) требуется вариант родственности Single.
Вариант родственности Class C используется для группы, а не для одного клиентского IP-адреса. При выборе этого варианта несколько запросов из одного диапазона адресов класса C TCP/IP направляются на один узел. При этой конфигурации клиенты, использующие несколько прокси-серверов, интерпретируются аналогично отдельным клиентским IP-адресам в варианте родственности Single. Если клиент, выполняющий доступ к кластеру через несколько прокси-серверов, направляет несколько запросов, эти запрос поступают как будто с различных компьютеров. Если все эти прокси-серверы находятся в одном диапазоне адресов класса C (обычно это разумное предположение), то выбор варианта Class C означает, что сеансы этого клиента будут обрабатываться аналогично варианту родственности Single.
Load Weight (Процент нагрузки). В режиме фильтрации Multiple Hosts вы можете использовать параметр Load Weight, чтобы задать процент трафика, который должен обрабатываться узлом по соответствующему правилу для портов. Чтобы на данный узел не поступал сетевой трафик, задайте значение 0. Чтобы задать какой-либо процент, используйте значение от 1 до 100.
При конфигурировании каждого узла сумма отдельных значений параметра Load Weight не обязательно должна составлять 100 процентов. Реальная часть трафика рассчитывается динамически как частное от деления процента, заданного для узла, на суммарный процент для всего кластера. Требование суммы в 100 процентов не имеет смысла, поскольку узлы время от времени включаются в кластер или выбывают из него.
Вариант Equal (Равномерное распределение нагрузки). Используйте вариант Equal, чтобы задать, что узел участвует в равномерно сбалансированном трафике в режиме фильтрации с несколькими узлами (Multiple hosts) по соответствующему правилу для портов.
Handling Priority (Приоритет обработки). Поле Handling priority используется в режиме фильтрации Single, и оно указывает уровень приоритета узла для трафика по данному правилу. Узел с наиболее высоким приоритетом обработки для определенного правила будет обрабатывать весь трафик для этого правила. Введите значение от 1 до X, где X — это количество узлов. Каждый узел должен иметь уникальное значение этого параметра. Значение 1 соответствует наиболее высокому приоритету.
Вот какие правила необходимы для работы наших сайтов:
NLB менеджер. Диалог создания кластера: Правила портов для нашего примера.
Поясним их смысл:
• На первом сайте, в отличии от второго, используется защищенная область (протокол HTTPS, 443 порт). Поэтому правилу для порта 443 назначен первый IP адрес кластера.
• Второй сайт работает по FTP. Для работы FTP нужны не только 20, и 21 порты, а также в пассивном режиме ещё используются 553, 1024 и выше. Для работы этого протокола созданы три оставшихся правила.
Во всех правилах необходима привязка пользователя к конкретному узлу из-за использования сессий.
NLB менеджер. Диалог создания кластера.: Присоединение первого узла к NLB кластеру.
После того, как Вы введете IP адрес узла и нажмете Connect, если данный сервер существует, диалог сам найдет и предложит сетевые соединения данного сервера и предложит выбрать один. После выделения сетевые соединения кнопка Next> станет активной.
NLB менеджер. Диалог создания кластера: Параметры присоединяемого к NLB кластеру узла.
Priority [Unique Host Identifier] (Приоритет [Уникальный идентификатор узла]). Это приоритет узла для обработки сетевого трафика по умолчанию для портов TCP и UDP, которые не заданы конкретно во вкладке Port Rules. Приоритет — это уникальное значение, которое используется для слияния в кластере. Это значение может изменяться в диапазоне от 1 до 32. Наиболее высокому приоритету соответствует значение 1. Каждый узел в кластере должен иметь уникальный приоритет (идентификатор).
При отказе какого-либо узла в кластере процесс слияния должен получать информацию, какие из оставшихся узлов могут обрабатывать трафик отключившегося узла. Выбирается узел с наиболее высоким приоритетом, и если происходит отказ этого узла, то выбирается узел с наиболее высоким приоритетом среди оставшихся узлов. Такая система обеспечивает определенную отказоустойчивость для NLB-кластера.
Dedicated IP Address (Выделенный IP-адрес). Выделенный IP-адрес это уникальный IP-адрес узла, который используется для сетевого кластера, не связанного с самим кластером.
Initial Host State (Начальное состояние узла). Параметр Default State (Состояние по умолчанию) определяет, следует ли запускать NLB, когда происходит загрузка операционной системы на данном узле (вариант Started). Иначе узлы могут присоединяться к кластеру и выходить из него с помощью команд управления NLB, запускаемых из командной строки. Это полезно использовать, если имеются другие службы, которые требуется загружать на данном узле (обычно вручную), прежде чем присоединять узел к кластеру.
Retain Suspended State after Computer Starts (Оставаться в состоянии задержки после загрузки компьютера). В состоянии задержки узел или кластер не выполняет никакой обработки приложений и отвечает только на команды Resume (Возобновить) и Query (Запрос). Если установить этот флажок, то задержанные кластеры остаются в состоянии задержки при перезагрузке сервера.
В данном окне все поля заполнятся автоматически, и в нашем случае ничего собственно менять не нужно.
После нажатия Finish диалог закроется и мастера балансировка нагрузки сети приступит к настройке узла. В этот момент он начнет вносить изменений в сетевое соединение, поэтому примерно на минуту связь с сервером оборвется.
После этого появится основное окно мастера где будет виден добавленный узел и его состояние:
NLB менеджер.: Отображение состояния NLB кластера с добавленным первым узлом.
NLB менеджер.: Добавление еще одного узла к кластеру.
После этого указать все как в пункте 6-7 все настройки для второго узла, указав IP адрес сервера (192.168.1.20) и выбрав сетевой адаптер этого сервера. В поле Приоритет необходимо указать 2 (он таким будет по умолчанию).
После того, как мастер балансировки нагрузки сети настроит второй узел, можно будет видеть следующее:
NLB менеджер: Состояние узлов NLB кластера. Конфигурирование второго узла в процессе.
Информация о втором узле обновляется.
NLB менеджер: Состояние узлов NLB кластера. Добавлены оба узла.
Все узлы находятся в рабочем состоянии.
В случае внесения изменения либо ввода нового узла или аварийной остановки одного из узлов, кластер будет недоступен в течении 10 секунд. Это время требуется для перенастройки кластера и перераспределения нагрузки.
Кроме оперативной сборки кластера NLB Manager позволяет также управлять кластером и отдельными узлами. Щелкнув правой кнопкой мыши на имени кластера или на отдельном хосте кластера, вы можете выбрать вариант Control Host (Управление хостом) или Control Ports (Управление портами).
NLB менеджер: Управление состоянием кластера.
В меню Control Hosts можно выбрать для хоста или для всех хостов кластера команду Start, Stop, Drainstop, Suspend или Resume.
Команда Stop остановит узел\кластер. В случае узла, произойдет перераспределение нагрузки между узлами без участия остановленного узла. Клиенты будут переброшены на другой узел.
Команда Start возобновит работу узла\кластера.
Команда Drainstop не прерывает активные подключения. В таком состоянии узел продолжать обслуживание активных подключений, но любой новый трафик на себя более не берёт.
Suspend и Resume приостановит обработку трафика и возобновит соответственно.
В диалоговом окне Control Ports вы можете выбрать команду Enable, Disable или Drain для отдельного правила в рамках одного хоста или всех хостов кластера.
1 ooo благодарностей за статью!
За то что выложили такой материал оч. полезный.
и еще 100 000 благодарностей, за то что сделали — ведь так четко сформулировать и по теме написать, оформить, иллюстрировать — большой труд.
У меня нубский вопрос: допустим сеть 10.1.1.0/24 в ней Host1(10.1.1.1) и Host2 (10.1.1.2), если строить NLB для сервиса предоставляемого клиентам этой сети, то не могу понять необходимость или целесообразность режима Unicast. Не говоря уж о том, что представляю вообще в общих чертах что такое NLB. Сейчас вот учу но наткнулся на неприятность — не смог построить NLB кластер в Hyper V, кстати нашел отличный FAQ http://social.technet.microsoft.com/Forums/ru-RU/winserverhyperv/thread/6dd0af1b-3be2-492e-96a0-16cfb7aee379
Итак я только в процессе изучения NLB, поэтому вопросы детские. Если для локалки NLB работает то зачем Unicast и как его реализовать, если придется запихивать кластер в 10.2.2.0/24 и строить роутинг.
Multicast в таком случае ничуть не хуже или я не вижу преимуществ Unicast в этом сценарии?
Да, подобные статьи писать хлопотно. Возможно, если хороших, понятных статей будет больше в интернете, это позволит быстрее прийти к технологиям, показанным в фильмах про будущее))))))И качество сервисов выростет быстрее….
Но пишу я их и для себя )). Вот сейчас, например, я всё уже давно подзабыл про NLB, сутра освежу в памяти, и отвечу.
Помнится, что целесообразность использования Unicast возникает в случае, если маршрутизатор, стоящий на обслуживании сети не понимает Групповые МАС адреса (они используются в Multicast). Щас посплю чуток и отвечу подробнее…. XD
RE: В чём разница между Unicast и Multicast
У NLB кластера есть IP адрес и привязанный к нему MAC адрес. Прикол в том, что нужно сделать так, чтобы при обращении к IP кластера это обращение доходило до всех нодов (узлов, т.е. машин, входящих в кластер).
У каждой ноды есть своя сетевуха, у неё есть физический MAC адресс и IP адрес. Так вот при Unicast физический MAC адрес для каждой ноды вырубается и вместо него используется MAC кластера. Но вот незадача — у нас в сети получается 32 (макс.) тачки, у которых один и тот-же MAC адрес кластера. Они то запросы ловят все из сети, но между собой общаться немогут ни — все с одним адресом и все ловят запрос.
Поэтому для Unicast режима нудно ЕЩЁ одна сетевуха у каждой ноды, причём в отдельной сети. По этим сетевухам и второй сети они будут общаться между собой и обмениваться информацией через уникальные для каждой сетевухи MAC адреса.
МИНУС: Нужна еще одна сетка и для каждого отдельного компа в кластере две сетевухи.
ПЛЮС: Этот режим нормально работает с CISCO маршрутизаторами, которые плоховато работают с вторым режимом — Multicast.
Второй же режим, Multicast, в отличии от первого делает хитрость — он берёт и делает такой хитрый ARP запрос, в котором содержится не только MAC кластера, но и еще и MAC сетевухи отдельной ноды. В результате получая Групповой MAC адрес. Получается отдельные ноды с одной сетевухой нормально могут существовать в сети и общаться между собой по физическим MAC адресам сетевухи, и также получать запросы приходящие на IP и соответственно на MAC адрес кластера. Но тут одна лажа — CISCO не умеет преобразовывать IP в групповой MAC адрес — их как-то там статически заносят в таблицы маршрутизации. Поэтому в некоторых случаях может в сетке кластер и не заработать. Вот те и плюсы с минусами:
МИНУС:Если сетка на цисках — не работает ничё толком.
ПЛЮС:По одной сетевухе в каждой ноде и все работает нормально если конечно маршрутизатор понимает групповые MAC адреса.
Я конечно утрирую не много — можно и поправить циску и будет работать.
У меня затея эта не удалась и зависла в воздухе, т.к. не заработало всё это у хостера. На локалке всё на виртуальных машинах заработало. Но у меня на локалке не было никакой привязки IP — MAC, и всё было внутри одной под сети. А у хостера пока выбили виртуальные IP адреса, пока потом перенесли сервера в одну подсетку и в конце концов после зборки виртуальные IP кластера отзываются в течении 2-х часов, и видимо после обновления таблиц маршрутизации они просто перестают отзываться. А потом у нас аврал был, и не до кластера стало. А после этого я просто сделал полную синхронизацию дисков и репликацию базы данных и сейчас просто два сервера идентичных и если умрёт один — мы носто в DNS пропишем другой и будет всё здорово.
Жаль пока что идея не реализована но в офисе всё работает как часики))))
Думаю, на твой вопрос ответил понятно. 🙂
я примерно так и представляю.
Вопрос то был вот про что:
Просто не пойму смысл (разумность или нужность, целесообразность)
Создаем NLB, в првилах опредяем трафик для этого кластера и ноды принимающие этот трафик
Если Unicast, то кластеру выделяеться LAN или VLAN 10.2.2/24
А клиенты находяться в 10.1.1.0/24
То есть нужен как минимум гейт, маршрут между двумя сетями.
ИТАК: ну как бы узкое место, типа страдает отказоустойчивость и для чего это если клиенты внутри, в одной сети с кластером?
Как я понял — не нужно.
«Получается отдельные ноды с одной сетевухой нормально могут существовать в сети и общаться между собой по физическим MAC адресам сетевухи, и также получать запросы приходящие на IP и соответственно на MAC адрес кластера»
Забудем о Цисках.
К сожалению не постоил в лабе NLB. Пытался на Одной хостовой машине создать три 2008 EE, ну и создать из них 2ух нодовый NLB/
Плюнул отмучившись несколько ночей.
Наверное это невозможно . Типа нужен не микрософт свитч ну и я не селен.
to Xetrix
он берёт и делает такой хитрый ARP запрос, в котором содержится не только MAC кластера, но и еще и MAC сетевухи отдельной ноды. В результате получая Групповой MAC адрес.
это ж какая трава забористая, чтобы так придумать то.
в режиме Multicast NLB кластер формирует для кластерного IP адреса — multicast MAC и обычными ARP reply отвечает хостам в сети.
Cisco рекомендует использовать этот режим, но любой «умный» switch подразумевает, что один и тот же MAC может быть только за одним портом, иначе это петля. Что бы этого избежать нужно на свиче поддерживающем L3 прописать static ARP:
arp 10.10.10.10 03bf.0a0a.0a0a ARPA (здесь 03bf — multicast заголовок MAC адреса, остальное IP адрес в шестнадцатиричном виде)
mac-address-table static 03bf.0a0a.0a0a vlan 10 interface Gi1/0/10
Не могу понять
Создаю нлб кластер. Есть 2 виртуальные машины вин 2003. На первом развернуто AD, DNS, DHCP, IIS, на втором — ничего, находится в домене.
С первого сервера (10.0.0.100) запускаю диспетчер NLB; виртуальный адрес кластера 10.0.0.250-10.0.0.251/24, домен указан, режим multicast, правила для портов — все. Добавляю к кластеру сначала второй сервер (10.0.0.200), он вроде поднимается, но в состоянии узла указано «Не выполнена привязка NLB». Добавляю первый сервер, такое же состояние. Причем после подобного поднятия узла в кластере, сразу меняются настройки интерфейса на сервере, в состоянии не отображается ip и так далее, просто все пусто, но в свойствах подключения настройки все нормально стоят, галочка «Балансировка нагрузки сети» стоит и настройки тоже корректно отображены, в итоге просто ip стираются и серваки не видят друг друга. В итоге кластер не поднимается.
Если снять галку «Балансировка нагрузки сети» с сетевого подключения, то ip настройки возвращаются и серваки естественно видят друг друга.
Мож я что-то упускаю? Мозг уже плавится, весь день с этим копаюсь, help!
«сначала второй сервер (10.0.0.200), он вроде поднимается» — работает ли он вообще? По идее после сборки кластера с одним узлом, при обращении к адресам кластера узел должен отзываться от имени кластера…Но я так понимаю IIS у тебя на этом узле нет и проверить работу ты не можешь..Добавь первым в кластер 10.0.0.100 и проверь, отзывается ли IIS и остальные сервисы от имени кластера (при обращении к виртуальным IP адресам…). и пиши что у тебя вышло…
сорри за задержку с ответом
«»сначала второй сервер (10.0.0.200), он вроде поднимается» — работает ли он вообще?» — да, работает.
В общем сделал IIS на втором серваке и выложил html страничку туда, настройки идентичные первому. Проверяю, оба сервака отдают страничку (Проверял все с 3-й виртуальной станции XP, которая в домене.). http://www23.zippyshare.com/v/10319643/file.html — тут скрины все. Домен qos.com; 1-й сервер — 10.0.0.100 — qos-2003; 2-й сервер — 10.0.0.200 — qos-2003-sec; Начал заново поднимать кластер, добавляю сначала второй сервер (screen-0-1-2). Пытаюсь пингануть 10.0.0.200 и 10.0.0.250, странички с этих адресов соответственно не отдаются тоже. Добавляю к кластеру 1-й сервер (screen-3-4). Такая же фигня, ни 10.0.0.100, ни 10.0.0.250 ни пингуются и странички не отдают. Состояния обоих серверов в кластере — screen-5-6. При попытке «обновить» кластер — ошибка обновления — screen-7.
Пока не точно..
По моему помниться мне что в настройках TCP\IP должны быть указаны и родной IP узла кластера и виртуальный. Походу у тебя происходит какая-то ошибка при внесении изменений менеджером кластера в настройки сетевого соединения. Я помню, что собрать кластер у меня получалось и без менеджера кластера NLB. Завтра, 12го, доберусь до своего кластера — гляну в настройки TCP\IP кластера и отпишусь тебе. В мультикаст режиме оба сервера должны друг-друга видеть…Также стОит проверить, а виртуальные адреса работают или нет? (добавить их в IP адреса серверов и обратиться к ним.)
вот что в настройках сетевого соединения
После сборки кластера в настройках сетевого соединения следующее:
В TCP\IP всё как было так и осталось. IP стоит прежний, и соответствует ноде, только в расширенных настройках в списке ip адресов добавлен класстерный.
В Network Load Balancing настройках в первой закладке стоит адресс кластера, во второй адреса нод кластера.
Судя по всему тебе можно попытаться ручками изменить настройки TCP\IP и добавить в список IP адрес класстера. У тебя не правильные после сборки становятся настройки TCP\IP — неудивительно что сервер не отвечает, у него просто нет IP адреса и в сети его нету тоже. Если заработает после внесения ручками, то проблема именно в менеджере кластера — глючит при внесении настроек в TCP\IP…
ошибка 0х800706ba error
Приветсвую. очень порадовал ресурс «на русском» а еще посмотрел на домен наш Украинский 🙂 респект!
Может кто сталкивался с проблемой:
Есть работающий NLB. с двумя серверами приложений, ua01 (10.4.16.22) и ua02 (10.4.16.23)? ip NLB -10.4.16.21, сервера в домене, хочу прицепить к ним еще один ua03, получаю ошибку 0х800706ba. что только не делал как только не гуглил. но увы, форумы иностранные все облазил. GUID менял, сетевые удалял\добавлял, все бестолку…
из особенности нужно отметить ua03 виртуальный сервер на vmware. два другие обычные физические.
есть у кого может мысля, что еще попробывать?
заранее благодарен.
не могу настроить по инструкции помогите
есть две сетевые ip1 172.20.14.9 и ip2 172.20.14.6 нужно что бы они вошли в кластер 172.20.14.4. у меня получается добавить первую сетевую а вот при попытке добавить ip2 через Add host to Cluster и при поиске второй сетевой оно мне выдает обе сетевые и выделено ip1 а ip2 выделить не могу
Так вы указываете один физический адрес (например 172.20.14.9), а второй прописывается автоматом, вам нужно будет прописать один виртуалый IP кластера, которым будут все пользоваться. И еще не забыть посмотреть в обоих сетевухах чтобы была включена балансировка NLB, обычно в одном включена а во втором нет.