Автор работы: Пользователь скрыл имя, 24 Февраля 2012 в 09:07, курсовая работа
В связи с ростом числа активных пользователей системы терминального доступа на базе Windows 2003 Server в Университете г. Переславля им. А.К.Айламазяна, а так же системных требований программного обеспечения, возникает необходимость увеличения производительности терминального сервера. Существует два пути увеличения производительности серверной платформы:
1. Введение
2. Реализация распределения нагрузки в Windows 2003 Server. Основные принципы. 4
3. Служба Microsoft Network Load Balancing (NLB) 4
4. Настройка NLB. 5
5. Другие балансировщики нагрузки. 10
6. Заключение. 11
7. Список литературы. 12
НОУ Институт программных систем —
«Университет города Переславля»
Кафедра Вычислительной техники и сетевых технологий
Дисциплина: «Сети и телекоммуникации»
Курсовая работа
Распределение нагрузки терминального сервера на базе Windows 2003 Server. Служба Network Load Balancing.
Студент: Кузьмин В. А.,
Группа: 2И62,
Научный руководитель:
ст. преп. кафедры ВТ и СТ
Парменова. Л.В.
Переславль-Залесский
2008
Оглавление
1. Введение
2. Реализация распределения нагрузки в Windows 2003 Server. Основные принципы. 4
3. Служба Microsoft Network Load Balancing (NLB) 4
4. Настройка NLB. 5
5. Другие балансировщики нагрузки. 10
6. Заключение. 11
7. Список литературы. 12
В связи с ростом числа активных пользователей системы терминального доступа на базе Windows 2003 Server в Университете г. Переславля им. А.К.Айламазяна, а так же системных требований программного обеспечения, возникает необходимость увеличения производительности терминального сервера. Существует два пути увеличения производительности серверной платформы:
Периодический «апгрейд» самого терминального сервера (зачастую с заменой основных комплектующих – процессора, материнской платы, модулей памяти). Очень дорогостоящая процедура (необходимы последние новинки hardware, как правило, стоят они на несколько порядков дороже, чем менее поздние, но все таки «свежие» комплектующие). К тому же, такой путь влечет вывод компьютерных классов из строя, т.к. на время замены сервера необходимо некоторое время (от 3 дней до недели) - сервера попросту не будет, а «тонкие клиенты» в компьютерных классах сконфигурированы на работу именно с терминалом (установлено лишь необходимое служебное программное обеспечение). Та же самая ситуация в случае с выходом из строя терминала. Система плохо масштабируема – представим, что вместо нынешних, в среднем, 25 активных сессий пользователей мы имеем 1200 – нетрудно подсчитать требования к аппаратной части, если на 1 сессию минимум тратиться 400мГц тактовой частоты процессора и 128Мбайт оперативной памяти.
Увеличение производительности системы терминального доступа не за счет одного «топового» терминального сервера, а попробуем объединить несколько менее мощных платформ в одну посредствам локальной сети. Система будет масштабируема, и мы уже не будем загнаны в рамки одной аппаратной части системы. Система становиться более надежной, терминальные сервера будут «зеркалировать» друг друга, взаимодействовать друг с другом, и в случае выхода одного из строя(по причине поломки, или профилактических действий администраторов) система не разваливается а продолжает существовать на имеющихся активных мощностях. О самом механизме реализации распределения нагрузки в Windows 2003 Server я расскажу ниже.
В базовом варианте распределение нагрузки делается вручную. Создаем файлы соединений для каждого из наших серверов и распространяем их среди пользователей, указывая определенному проценту пользователей их предпочтительное соединение. Вернемся к нашему примеру. Если у нас есть 1200 пользователей и 4 сервера, мы создаем 4 файла и распространяем их среди пользователей, но инструктируем 400 пользователей подключаться к серверу А, еще 400 - к серверу B и т.д. Если один из серверов перестает функционировать, пользователи могут использовать другой файл соединения в качестве резерва. Если мы хотим сделать автоматическое распределение нагрузки и отказоустойчивость без вмешательства пользователя, нам нужно реализовать распределение нагрузки.
NLB позволяет разместить группу серверов за виртуальным адресом IP (VIP). NLB распределяет соединения, делаемые к VIP, среди серверов кластера и поддерживает межсерверные коммуникации, чтобы в случае выхода одного из серверов из строя NLB прекратила направлять к нему клиентов.
В WS2K3 Microsoft улучшила балансировщик нагрузки. В Win2K, NLB был доступен только в редакции Advanced или Datacenter. WS2K3 включает NLB во все редакции. Microsoft сделала следующие улучшения:
NLB Manager - В Win2K мы должны вручную конфигурировать каждый сервер в кластере. WS2K3 включает новый инструмент администрирования, который позволяет централизованно создавать, конфигурировать и управлять кластерами NLB.
Виртуальные кластеры - При использовании NLB для кластеризации веб-серверов, мы можем создавать множественные кластеры на одном и том же наборе серверов, используя несколько адресов IP на каждом сервере. Каждому виртуальному кластеру присваивается свой VIP.
Поддержка нескольких сетевых адаптеров - WS2K3 позволяет привязать NLB к каждому сетевому адаптеру сервера. Win2K позволяла привязать NLB только к одному адаптеру.
Поддержка широковещания - Кластеры WS2K3 можно настроить на использование multicast для межсерверных коммуникаций.
Но даже со всеми этими улучшениями NLB все еще имеет ограничения, которые мы должны учитывать. Во первых, все члены кластера NLB должны находиться в одной подсети. Во вторых, NLB считает только число активных соединений с сервером при определении того сервера, к которому следует направить соединение; он не учитывает потребление памяти или процессора. В третьих, при использовании совместно с Каталогом Сеансов, NLB требует, чтобы адреса IP терминальных серверов должны быть видимыми клиенту. И NLB ограничен 32 узлами в кластере.
В NLB Manager, Microsoft называет группу серверов, связанных распределением нагрузки, кластером. Нельзя путать этот термин с настоящим кластером, который позволяет серверам совместно использовать процессы и запоминающие устройства как единый сервер. Во многих документах о распределении нагрузки, включая статьи Microsoft, группы серверов с распределением нагрузки называются фермами. Тем не менее, я буду использовать термин "кластер", чтобы не противоречить NLB Manager.
После того, как мы сконфигурировали наши терминальные серверы и установили приложения, мы готовы приступаем к конфигурированию их для NLB. Но сначала мы должны собрать следующую информацию:
Адрес VIP, который мы выбрали для кластера
Уникальные адреса IP каждого из серверов фермы
Алиас DNS, который мы хотим использовать для кластера
Сетевой протокол и порт, который мы хотим использовать для распределения нагрузки (для RDP это TCP и порт 3389).
Доменная учетная запись с правами администратора ко всем серверам кластера, или локальные учетные записи администраторов каждого сервера
Собрав эту информацию, мы должны запустить NLB Manager. Мы можем это сделать с любой системы WS2K3 или с клиента Windows XP, на котором установлен WS2K3 Administrative Tools.
NLB Manager позволяет создавать, конфигурировать и управлять кластерами NLB в сети. Ниже представлен интерфейс NLB Manager.
В окне Cluster Parameters можем конфигурировать адрес VIP и имя DNS нового кластера. Если мы планируем администрировать кластер с помощью NLB Manager, то не нужно разрешать удаленное управление или устанавливать пароль. NLB Manager использует Windows Management Interface (WMI), т.е. использует учетную запись пользователя.
Мы также можем выбрать, какой режим должна использовать межсерверная коммуникация - однонаправленный (unicast) или широковещательный (multicast). Если наши терминальные серверы имеют по одному сетевому адаптеру, и наша сеть поддерживает мультикастинг в подсети, мы должны разрешить широковещательный режим (multicast). Это позволит нам управлять кластером с помощью NLB Manager с любого сервера кластера.
Add/Edit Port Rule NLB Manager позволяет ввести дополнительные адреса IP, используемые в кластере. Эта информация обычно используется веб-серверами с распределением нагрузки, когда каждый сервер обслуживает несколько веб-сайтов, каждый из которых представлен уникальным адресом IP. В нашем случае мы используем сервер для терминального доступа, поэтому можем ничего не конфигурировать.
Правила портов определяют, как должны обрабатываться соединения к VIP. По умолчанию весь трафик TCP и UDP равномерно распределяется по узлам кластера. Для терминальных серверов нам необходимо балансировать только RDP.
Диапазон портов с 3389 по 3389, протокол TCP – «умолчательные» настройки для RDP. Эта конфигурация создаст распределение нагрузки только для протокола RDP. Ограничив правила только протоколом RDP, мы снижаем нагрузку на службу NLB и на серверы, защитив их от ошибочных запросов, посылаемых на адрес VIP на другие порты.
Оставляем режим фильтрации по умолчанию (multiple host, single affinity), смысл остальных опций следующий:
Multiple host — Если выбрано, то соединение, выполняемое на указанный диапазон портов, будет распределяться среди нескольких узлов. В этом случае мы должны выбрать режим родственности (affinity). Родственность обеспечивает, что после того, как клиент будет направлен на указанный узел, клиент в течении сеанса будет продолжать направляться на тот же узел во всех коммуникациях.
Опции родственности:
None - родственность не используется
Single - Родственность основывается на адресе IP клиента, балансировка выполняется на базе клиента
Class C - Родственность основана на подсети класса С клиентов. Когда один клиент устанавливает соединение к некоторому узлу, все соединения от той подсети будут направлены на тот же узел.
Single host - Соединения на указанный диапазон портов будут направлены на один узел, а если этот узел недоступен - то на следующий узел, вычисляемый по номеру Handling Priority (приоритет обработки). Приоритет присваивается узлу при добавлении сервера в кластер.
Мы также можем запретить правило (Disable this port range). Это временно отключит распределение нагрузки для указанного диапазона портов..
В окне Connect мы можем ввести имя первого сервера, добавляемого к кластеру. NLB Manager установит соединение с этим сервером и выдаст список сконфигурированных сетевых адаптеров. Мы должны выбрать адаптер, на котором мы хотим принимать входящие соединения с VIP.
В окне Host Parameters мы настраиваем конкретный сервер, выбранный для присоединения к кластеру. Здесь мы сначала должны установить номер приоритета, который одновременно используется как уникальный идентификатор узла. Мы можем изменить физический адрес IP сервера и маску подсети, а также установить начальное значение состояния службы распределения нагрузки после загрузки сервера.
После всех настроек, NLB Manager подключится к серверу через WMI и сконфигурирует службу NLB. После создания кластера мы можем увидеть в основном окне NLB Manger новый кластер. В этом окне мы можем добавлять к кластеру узлы. Всякий раз при добавлении сервера нам необходимо выбрать сетевой интерфейс и установить приоритет.
Завершив добавление терминальных серверов в кластер, мы можете опробовать NLB, используя клиент Remote Desktop Connection, указав в нем адрес VIP или имя DNS кластера. Наше соединение должно быть направлено на один из серверов кластера.
Для подключения с использованием имени DNS кластера, мы должны либо разрешить в своей сети динамический DNS (DDNS), который позволяет службе NLB регистрировать имя кластера, или вручную добавить алиас кластера в базу данных DNS.
Хотя служба Microsoft NLB проста в настройке и администрировании, а также бесплатна во всех редакциях WS2K3, есть много причин присмотреться к балансировщикам нагрузки других производителей. Особенно если наши серверы находятся в разных подсетях или нам необходимо поддерживать более 32 серверов.
Одним из важнейших факторов, которые следует учитывать при выборе балансировщика, является то, как балансировщик определяет нагрузку. Многие балансировщики, включая Microsoft NLB, просто подсчитывают число активных соединений к узлу. В среде терминальных серверов этот метод не всегда адекватен.
Некоторые балансировщики могут размещать на серверах метрики и определять нагрузку на основе доступной памяти, использования процессора и других коэффициентов производительности. Такие продукты имеют большое преимущество при распределении нагрузки терминальных серверов, поскольку отслеживают их текущую производительность.
Помимо балансировщиков нагрузки есть продукты, специально предназначенные для расширения возможностей Terminal Services. Эти продукты не только включают в себя средства распределение нагрузки, но и позволяют публиковать приложения, позволяя пользователям подключаться к приложениям, а не к рабочему столу. Лидерами в этой области являются Citrix MetaFrame (http://www.citrix.com/) и New Moon Canaveral iQ (http://www.newmoon.com/).