 |
|
|
|
Технология NLB – отказоустойчивость без лишних затрат
Технология NLB – отказоустойчивость без лишних затрат Решение задачи распределения нагрузки является одной из важнейших на сегодняшний день. Предлагаю рассмотреть одно из таких решений, построенных на основе службы Network Load Balancing, входящей в состав Windows Server 2003. Отказ ключевых бизнес-приложений всегда является большой проблемой для системных администраторов. Для ее решения можно использовать службу Microsoft Clustering Service, входящую в состав Windows Server 2003 Enterprise Edition. Однако, кроме этой службы в состав Windows Server 2003 также входит служба Network Load Balancing. В чем же различие между этими двумя кластерными службами? Microsoft Cluster Service прежде всего дублирует систему хранения данных, позволяя реализовать отказоустойчивость посредством замены вышедшего из строя узла другими узлами кластера. Такое построение кластера удобно при реализации отказоустойчивости для таких приложений, как Microsoft Exchange, баз данных Microsoft SQL и других. Другим решением, позволяющим также построить масштабируемую систему является Network Load Balancing. Данная служба дублирует сетевые службы, распределяя нагрузку между всеми узлами кластера. Служба NLB в основном используется при работе с такими приложениями, как служба Web, FTP, Terminal Service. Технология NLB Обсудим теоретические основы технологии. NLB – это драйвер сетевого обмена Windows 2003. Он действует независимо от сетевого стека TCP/IP и прозрачен для этого стека. Основным элементом службы NLB является Windows Load Balancing, приложение, отвечающее за распределение нагрузки между узлами кластера. NLB образует кластер максимум из 32 компьютеров. Нагрузка на каждое серверное приложение может быть распределена по узлам всего кластера или управляться в основном каким-либо одним узлом, когда другой узел в кластере обеспечивает избыточность для управляемого перехода по отключению в случае отказа основного узла. Для полностью распределенных приложений отказ любого узла вызывает перераспределение нагрузки, которую нес этот узел, на все остальные машины кластера. При возвращении в строй узла нагрузка снова перераспределяется. Выбор режима работы NLB-кластера Узел может быть создан и настроен для работы в одном из четырех режимов, каждый из которых имеет свои достоинства и недостатки. Это следующие режимы:
Выбор режима функционирования кластера зависит от обстоятельств, требований и ограничений, налагаемых на структуру кластера. Рассмотрим каждую из них. Один сетевой адаптер, работающий в одноадресном режиме, является в некотором смысле самым простым типом, и узел с одним адаптером немного дешевле, чем с несколькими. Но при этом налагаются существенные ограничения: снижается производительность сети в целом, отключаются обычные соединения между узлами кластера, и наконец, в таком кластере нет поддержки NetBIOS. Конечно, последний пункт многим покажется не очень критичным, так как NetBIOS сейчас мало кем используется, но все же такое ограничение есть. Один сетевой адаптер в групповом (многоадресном) режиме предназначен для кластеров, в которых один или несколько узлов имеют один сетевой адаптер. Соответственно, между узлами в кластере можно устанавливать обычные соединения. Это свойство позволяет обойти одно из наиболее неудобных ограничений работы с одним сетевым адаптером в одноадресном режиме. К недостаткам этой модели можно отнести: снижение общей производительности сети, возможны проблемы с коммутаторами, которые не поддерживают групповые MAC-адреса. Также в таком кластере нет поддержки NetBIOS. Несколько сетевых адаптеров в одноадресном режиме – данная конфигурация, как правило, является наиболее предпочтительной. В ней используется второй сетевой адаптер на каждом узле кластера, что позволяет получить следующие преимущества: нет ограничений на обычные сетевые соединения между узлами, возможна поддержка NetBIOS через первый сконфигурированный адаптер, не снижается производительность сети и не возникает проблем с коммутаторами. Несколько сетевых адаптеров в групповом режиме – такая модель используется, если у некоторых узлов в кластере имеется только один сетевой адаптер, но при этом требуется поддерживать обычные сетевые соединения между узлами данного кластера. Такая модель вполне жизнеспособна, однако могут быть проблемы с некоторыми моделями коммутаторов. Исходя из вышеописанного, наиболее предпочтительной моделью NLB-кластера является использование нескольких сетевых адаптеров в одноадресном режиме. Теперь обсудим некоторые моменты, связанные с предварительной настройкой NLB-кластера. Во-первых, убедитесь что должным образом обеспечена безопасность приложений, для которых распределяется нагрузка. Система безопасности NLB не распространяется на приложения. Следовательно, службы кластера с распределенной нагрузкой не будут осведомлены о нарушении безопасности на уровне приложений. Во-вторых, неплохо бы позаботиться об организации отказоустойчивого подключения сетевого оборудования, которое применяется в NLB-кластере. Также для определенных моделей оборудования можно использовать VRP (Virtual Router Protocol) и HRSP (Hot Router Standby Protocol). Это позволяет маршрутизатору преобразовывать основной IP-адрес кластера и другие групповые адреса в соответствующий аппаратный адрес. Некоторые модели маршрутизаторов и коммутаторов не удовлетворяют данным условиям, и тогда в них можно создать статическую ARP-запись или использовать службу балансировки нагрузки сети в стандартном одноадресном режиме. В-третьих, на адаптере, для которого включена служба NLB, можно использовать только протоколы стека TCP/IP. Никакие другие протоколы (например IPX) для данного адаптера устанавливать не нужно. Также проследите, чтобы на каждом из узлов были открыты все необходимые порты на межсетевом экране (если он используется), например, если кластеризуется FTP-сервер, то необходимо открыть 20-й и 21-й порты на всех узлах. Не забудьте проверить, на всех ли узлах кластера запускается данное приложение. И наконец, хорошо подумайте, прежде чем разрешить удаленное управление NLB-кластером. Включение удаленного управления создает дополнительную угрозу безопасности, поэтому при включении удаленного управления следует убедиться, что NLB-кластер надежно защищен от взлома (находится за межсетевым экраном). Механизм удаленного управления использует протокол UDP по порту 2504. Команды, используемые для удаленного управления кластером, отправляются на сетевой адаптер, использующий службу NLB. Затем данные команды передаются всем узлам кластера уже по локальной, внутренней подсети кластера, с использованием широковещательных сообщений. Это гарантирует получение команд всеми узлами кластера, даже если он работает в одноадресном режиме. Поэтому необходимо уделить особое внимание защите внутренней подсети кластера, так как широковещательные сообщения легко можно перехватить. Если средства удаленного управления включены, то с помощью программы nlb.exe можно осуществлять управление кластером по сети. Постановка задачи Разобрав теоретические вопросы, перейдем к практической части. Прежде всего необходимо определиться с той задачей, которую мы хотим решить с помощью NLB-кластера. В качестве примера я буду разворачивать NLB-кластер для распределения нагрузки службы Terminal Service. Средства удаленной работы в Windows приобретают все большую популярность, так как возможность использовать не очень мощные рабочие станции в качестве клиентской консоли только для создания соединения с сервером терминалов является довольно привлекательной, ведь вся основная нагрузка в таком случае ложится на сервер, а в качестве клиентов можно использовать старые компьютеры, которых хватает в любой организации. Но в этом случае надежность всей терминальной системы будет в значительной степени определяться надежностью и производительностью сервера терминалов, в частности, требование распределения нагрузки. Отказоустойчивость в данном кластере обеспечивается за счет балансировки сетевой нагрузки. Мы будем реализовывать двухузловой NLB-кластер, в котором в качестве приложения будет развернута служба Terminal Service. Реализация Итак, приступим к установке кластера с распределенной нагрузкой NLB. Для этого необходимо настроить сетевые параметры кластера, параметры узла и необходимые порты. Как уже упоминалось ранее, для решения задачи необходимо использовать несколько сетевых адаптеров. Соответственно, и описывать настройку я буду для нескольких сетевых адаптеров. Если вы собираетесь использовать один сетевой адаптер, так чтобы все используемые IP-подсети работали внутри одной кабельной сети, то за подробной инструкцией обратитесь к статье базы знаний Microsoft за номером 323431. Откройте раздел «Network Load Balancing Manager» из папки «Administrative Tools». В левой панели щелкните правой кнопкой мыши на «Network Load Balancing Clusters» и выберите пункт «New Cluster» (создание кластера). Далее, в окне «Cluster Parameters» нужно ввести IP-адрес, маску подсети и полностью определенное доменное имя (FQDN), под которым будет известен данный кластер (cм. рис. 1).
Рисунок 1. Создание NLB-кластера Очевидно, что IP-адрес должен быть фиксированный, то есть он не может быть динамическим адресом, выделяемым внешним DHCP. Затем необходимо определиться, в каком режиме должен работать кластер – в одноадресном (unicast) или многоадресном (multicast), и указать, нужно ли разрешить удаленное управление (флажок «Allow remote control»), а затем щелкнуть по кнопке «Next». Как уже упоминалось ранее, с удаленным администрированием нужно быть очень аккуратным, во избежание возможных проблем с безопасностью. Если необходимо, чтобы кластер имел дополнительные IP-адреса, введите их в окне «Cluster IP Address», потом нажимите «Next». Затем можно определить правила для портов или оставить их конфигурирование до момента, когда этот кластер будет запущен. С помощью правил для портов можно управлять поведением различных типов трафика TCP/IP. В частности, можно оптимизировать работу сети и увеличить быстродействие кластера в целом, запретив пересылку ненужных пакетов. В следующем окне «Connect» введите имя или IP-адрес первой хост-машины, которая будет включена в этот кластер. Щелкните по кнопке «Connect», чтобы подсоединиться к данному узлу и получить на экране список доступных сетевых интерфейсов. Выделите интерфейс, через который будет проходить открытый трафик этого кластера (в отличие от частного, межузлового трафика, который используется узлами для обмена информацией). В окне «Host Parameters» вы можете задать приоритет (в поле Priority) для данного узла кластера (для решения нашей задачи повышения отказоустойчивости указываем приоритет, равный единице) и выделенный IP-адрес, который будет использоваться для подсоединения к этому конкретному серверу (в отличие от кластера в целом). Это должен быть фиксированный IP-адрес, а не адрес, выданный DHCP. По поводу приоритетов необходимо сделать небольшое пояснение. Приоритет является нормирующим коэффициентом балансировки, пропорциональный производительности узла. Так как в нашем случае мы не оптимизируем производительность, то приоритеты определены, равные единице. Последним этапом вам необходимо задать начальное состояние узла на момент запуска Windows. Указываем состояние Started. Затем нажимаем «Finish». При необходимости добавить еще один узел в уже существующий NLB-кластер необходимо выполнить следующее. В консоли «Network Load Balancing Manager» выбираем уже существующий кластер и нажимаем правую кнопку мыши, затем «Add Host To Cluster». В окне Connect указываем имя или IP-адрес узла, добавляемого в наш кластер (см. рис. 2).
Рисунок 2. Добавление узлов Подключившись к новому узлу, можно выбрать из появившегося списка доступных интерфейсов тот, через который будет проходить открытый трафик этого кластера. Далее аналогично уже описанным ранее действиям указываем параметры для данного узла, приоритет, состояние на момент запуска. После нажатия «Finish» получаем следующую картину (см. рис. 3).
Рисунок 3. Консоль управления NLB В случае, если по каким-либо причинам вам необходимо вывести узел из кластера, достаточно выбрать данный хост и, нажав правую кнопку мыши, указать Delete Host. Настраиваем каталог сеансов Итак, NLB-кластер успешно создан. Вообще его уже можно использовать для решения своих задач, указывая в качестве IP-адреса адрес самого кластера. Например, для решения нашей задачи с терминальным сервером вы уже можете подсоединиться к кластеру по его IP-адресу и использовать службу терминалов в режиме распределенной нагрузки. Но тут возникает небольшая проблема, свойственная именно серверам терминалов. Что делать с разъединенными сеансами пользователей, ведь в случае выхода из строя одного из узлов кластера часть пользовательских сессий могут «повиснуть». Если сервер терминалов выделяет для пользовательских сессий локальные ресурсы, то сбой может привести к серьезным последствиям. К тому же сессия отключившегося пользователя через некоторое время (указанное в настройках терминального сервера) закрывается, лишив пользователя последней возможности сохранить данные и корректно завершить работу. Однако даже в том случае, если пользователь после сбоя снова подключится к серверу терминалов, нет никакой уверенности в том, что он попадет в свою, уже открытую сессию, а не в новую, созданную другим сервером терминалов, входящим в этот кластер. Однако в случае кластера с распределением нагрузки Session Manager, служба, отвечающая за распределение терминальных сессий, ничего не знает о сеансах на других серверах. Поэтому Microsoft ввела понятие каталога сеансов (Session Directory). Каталог сеансов поддерживает динамическую базу данных, которая хранит соответствия имен пользователей и открытых сеансов на всех терминальных серверах кластера. Это позволяет пользователям подключаться к своим сеансам на любом сервере в кластере независимо от того, на какой сервер его изначально направила служба NLB. Настроим данную службу на нашем кластере. Session Directory может использовать любую редакцию WS2K3. Вы даже можете создать каталог сеансов на одном терминальном сервере в кластере, хотя это не рекомендуется, поскольку остановка этого сервера для обслуживания или установки ПО может затронуть весь кластер. Перед началом настройки Session Directory необходимо определиться, на каком сервере будет размещаться база. Следует обратить внимание на то, что в случае выхода из строя данного сервера информация о существующих сеансах будет утеряна, поэтому выберите мощный и надежный сервер. На этом сервере откройте «Computer Management or Services» для доступа к «Terminal Services Session Directory». Откройте свойства службы, настройте ее на автоматический запуск и запустите ее (см. рис. 4).
Рисунок 4. Настройки службы Session Directory После первого запуска служба каталога сеансов должна создать новую локальную группу Session Directory Computers. Для того чтобы терминальный сервер мог информировать сервер каталога сеансов о своих терминальных сессиях или запрашивать информацию о сеансах с других серверов, он должен быть членом этой группы. После создания сервера каталога сеансов нужно настроить терминальные серверы. Для этого можно прибегнуть либо к помощи консоли Terminal Services Configuration, либо воспользоваться редактором групповых политик. Также, если вы используете Windows Server 2003 Enterprise Edition, то в настройках терминального сервера можете найти дополнительную закладку Session Directory. В данной консоли необходимо указать IP-адрес или имя сервера каталога сеансов. В случае, если у вас используется редакция Standard Edition (а все настройки, приводимые для данной статьи делались именно для этой редакции), то наилучшим средством для настройки Session Directory будет использование групповых политик. Для этого создайте Organization Unit в домене и внесите в него все терминальные серверы нашего кластера, затем откройте консоль редактирования групповых политик для данного OU и перейдите в раздел «Computer Configuration -> Administrative Templates -> Windows Components -> Terminal Services -> Session Directory». Укажите все необходимые параметры (см. рис. 5).
Рисунок 5. Настройка групповых политик После этого достаточно дождаться следующего обновления групповых политик или же воспользоваться командой gpupdate, применив ее на каждом из узлов кластера. Тонкая настройка Итак, в результате всех вышеприведенных действий получаем кластер для службы терминалов. Конечно, технологию NLB можно с успехом использовать, к примеру, для создания веб-сервиса или для какого-либо специализированного приложения с распределением нагрузки. В статье приводится лишь пример одного из возможных способов использования Network Load Balancing. Однако есть несколько общих советов по оптимизации работы NLB-кластера. Прежде всего необходимо ясно понимать, где вероятнее всего находится «узкое» место вашего кластеризованного приложения. В случае с терминальным сервером, например, будут активно использоваться процессор и память узлов кластера. Следовательно, следует заранее позаботиться о том, чтобы мощность была достаточной для работы в NLB-кластере. Еще одним важным элементом NLB является нагрузка на сеть. Используйте высокоскоростной коммутатор, желательно с гигабитными портами (сейчас такое оборудование стоит недорого). Соединяйте узлы по принципу один сервер – один порт, без каких-либо промежуточных устройств. Используйте одноадресный режим с выделенной внутренней кластерной сетью. Также для оптимизации внесите правку в реестр на каждом из узлов кластера, изменив значение следующего ключа с 1, используемой по умолчанию, на 0: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WLBS\Parameters\MaskSourceMAC. Это изменение позволяет данному ключу указывать, какой MAC-адрес является фактическим источником трафика, что помогает правильно выполнять его работу по коммутации. После этого изменения нужно выполнить перезагрузку всех узлов кластера. Заключение На этом завершается серия статей, посвященная кластерным технологиям в Windows Server 2003. Надеюсь, что описанные технологии пригодятся в нелегком деле обеспечения непрерывности работы корпоративных IT-систем.
|
Андрей Бирюков
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
