Принцип работы

Объединение серверов в один ресурс происходит на уровне программных протоколов.

Примеры

Программные кластерные решения

Применение

В большинстве случаев, кластеры серверов функционируют на раздельных компьютерах. Это позволяет повышать производительность за счёт распределения нагрузки на аппаратные ресурсы и обеспечивает отказоустойчивость на аппаратном уровне.

Однако, принцип организации кластера серверов (на уровне программного протокола) позволяет исполнять по нескольку программных серверов на одном аппаратном. Такое использование может быть востребовано:

• при разработке и тестировании кластерных решений;
• при необходимости обеспечить доступность кластера только с учётом частых изменений конфигурации серверов - членов кластера, требующих их перезагрузки (перезагрузка производится поочерёдно) в условиях ограниченных аппаратных ресурсов.

См. также

Wikimedia Foundation . 2010 .

Смотреть что такое "Кластер серверов" в других словарях:

У этого термина существуют и другие значения, см. Кластер. Кластер (в информацонных технологиях) группа серверов (программных или аппаратных), объединённых логически, способных обрабатывать идентичные запросы и использующихся как единый ресурс.… … Википедия

Объединение в систему однородных единиц. При этом данная система может считаться самостоятельным элементом обладающим определенными свойствами. Понятие кластер входит во многие области науки химию, физику, социологию, астрономию и т.д. В… … Словарь бизнес-терминов

У этого термина существуют и другие значения, см. Кластер. Техники работают с большим Linux кластером в Хемницком техническом университете, Германия Кластер … Википедия

Кластер группа компьютеров, объединённых высокоскоростными каналами связи, представляющая с точки зрения пользователя единую машину. Один из первых архитекторов кластерной технологии Грегори Пфистер (Gregory F. Pfister) дал кластеру следующее… … Википедия

- (англ. cluster скопление) объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами. В информационных технологиях: Кластер как подмножество… … Википедия Википедия

Exalogic аппаратно программный комплекс, серийно выпускаемый корпорацией Oracle с 2010 года, являющийся кластером серверов архитектуры x86 64, с предустановленным связующим и управляющим программным обеспечением. Основное… … Википедия

Кластеры серверов

Кластер серверов представляет собой мощное вычислительное решение, предназначенное для компаний с высокими требованиями к уровню безопасности, к непрерывному доступу к данным и вычислительным мощностям. Данные системы подходят для поддержания корпоративных баз данных, социальных порталов и новостных сайтов, а также интернет-магазинов, онлайн-игр, игровых сайтов, страховщиков и кредитных учреждений, разработчиков и тестировщиков программного обеспечения.

Высокая доступность
Доступность услуги не ниже 100% даже при простое серверов

Широкая масштабируемость
Большое количество оборудования, прогнозируемое и быстрое расширение услуги при необходимости

Надежное техническое обеспечение
Качественное оборудования мирового класса в безопасных дата-центрах

Серверы и системы хранения доступны клиенту полностью оборудованные, с востребованным количеством процессоров, объёмом оперативной памяти и места для жесткого диска, обеспечив также необходимую сетевую инфраструктуру. В основе каждого решения лежат технические требования клиента. Установить кластер серверов, как правило, занимает всего нескольких рабочих дней – система хранения данных в дата-центре уже предустановлены и нуждаются лишь в дополнительных настройках под требования клиента. Важно отметить, что доступ к кластеру возможен из любой точки мира - необходимо лишь иметь стабильное подключение к интернету. Все данные и приложения находятся в серверах, расположенных в безопасных дата-центрах DEAC в Рига, а также в стратегических точках локации в Стокгольме, Киеве, Лондоне, Амстердаме, Москве и Франкфурте.

Своим клиентам предлагаем создавать различные кластеры серверов:

Платформа аналитики «больших данных»

Выберите системы аналитики «больших данных» Hadoop , Apache Spark , Apache Storm или Disco для эффективной обработки больших объемов информации. Данные платформы позволяют анализировать огромные массивы данных параллельно, используя кластеризацию серверов. Платформы распределенных вычислений позволяют распределить «большие данные» на несколько узлов внутри кластера типовых серверов. Тем самым вам не нужно покупать и поддерживать дорогостоящее специализированное оборудование. DEAC предоставляет полностью настроенные кластеры для запуска любого из упомянутых проектов с открытым исходным кодом, а также для других приложений на базе выбранной платформы.

Приобретайте Hadoop-платформу уже сегодня по специальной цене!

Сервер: 1хHP DL320 Gen8, 1xE3-1240v2, 16ГБ RAM, 1x1ТБ SATA, 2x1GE, SPS

Сеть: 1х1GE порт включен

Трафик: 1х100 Мбит/с интернет включен (без лимита и без замеров)

IPv4: 1 включена

Индекс скорости процессора (CPU Score ): 9153

Кластер серверов объединяет несколько физических серверов с сетевой инфраструктурой и обрабатывает различные процессы на одном ресурсе. Главная задача кластера - исключить простой системы, связанный с любым возможным инцидентом (внешним вмешательством или сбоем во внутренней работе ресурса). Синхронизированная система хранения данных управляет всем кластером серверов при помощи программного протокола, который дает возможность системе синхронизировать, добавлять аппаратные или программные ресурсы, распределять запросы, осуществлять балансировку нагрузки, в том числе подключаться к базам данных кластера.

Сферы применения
серверных кластеров

Как работает кластер
серверов?

Основные компоненты
кластера серверов

Кластеры серверов часто используются там, где производительность и высокая доступность являются ключевыми факторами.

• Э-коммерция
• Онлайн казино и букмекеры
• Предприятия, которые содержат базы данных
• Медицинская отрасль
• Финансовые компании и фондовые биржи
• Кредитование и страхование
• Разработка и тестирование программного обеспечения

Кластер серверов состоит из нескольких физических серверов, называемых узлами, которые соединены между собой для обеспечения высокого уровня доступности для клиента. Вычислительный кластер состоит из групп ресурсов приложений и услуг, сетевого имени и IP-адреса. Каждый узел может состоять их нескольких групп ресурсов, которые перераспределяют нагрузку и гарантируют предоставление услуги в случае отказа одного или нескольких серверов.

Кластер высокой доступности DEAC работает в каждом узле и контролирует работу вычислительного кластера. Несколько программных компонентов обеспечивают мониторинг, перераспределение ресурсов и поддерживают согласованность кластерных вычислений.

Каждый вычислительный кластер отличается компонентами и системой внутреннего контроля. Такие компоненты, как Database manager (менеджер баз данных), Node manager (менеджер узлов) и Failover manager (менеджер аварийного переключения) работают вместе для достижения максимальной производительности.

Database manager поддерживает локальную копию базы данных конфигураций серверного кластера, которая содержит информацию обо всех компонентах кластера и реплицирует все изменения на все узлы кластера.

Node manager содержит список локальный список всех узлов, сетей и сетевых интерфейсов и обеспечивает мониторинг узлов на предмет их отказа.

Failover manager управляет зависимостями ресурсов, запуском ресурсов и инициирует аварийное переключение групп ресурсов.

DEAC сертифицирован по стандарту PCI DSS, что подтверждает высокий уровень информационной безопасности компании, обрабатывающих данные кредитных карт. Если Ваша компания принимает, хранит, обрабатывает или пересылает данные кредитных карт онлайн или оффлайн, то у Вас должен быть сертификат PCI DSS. DEAC внедрил комплексную сетевую инфраструктуру для соответствия внедряемой политике PCI DSS. Решения серверных кластеров соответствуют требованиям PCI DSS и обеспечивают соответствие и нашим клиентам.

В данной статье будет показано, как построить отказоустойчивый кластер Server 2012 с двумя узлами. Сначала я перечислю обязательные условия и представлю обзор настроек аппаратной среды, сети и хранилища данных. Затем будет подробно описано, как дополнить Server 2012 функциями отказоустойчивой кластеризации и использовать диспетчер отказоустойчивого кластера для настройки кластера с двумя узлами

В Windows Server 2012 появилось так много новшеств, что за всеми уследить трудно. Часть наиболее важных строительных блоков новой ИТ-инфраструктуры связана с улучшениями в отказоустойчивой кластеризации. Отказоустойчивая кластеризация зародилась как технология для защиты важнейших приложений, необходимых для производственной деятельности, таких как Microsoft SQL Server и Microsoft Exchange. Но впоследствии отказоустойчивая кластеризация превратилась в платформу высокой доступности для ряда служб и приложений Windows. Отказоустойчивая кластеризация - часть фундамента Dynamic Datacenter и таких технологий, как динамическая миграция. Благодаря Server 2012 и усовершенствованиям нового протокола Server Message Block (SMB) 3.0 область действия отказоустойчивой кластеризации стала увеличиваться, обеспечивая непрерывно доступные файловые ресурсы с общим доступом. Обзор функциональности отказоустойчивой кластеризации в Server 2012 приведен в опубликованной в этом же номере журнала статье «Новые возможности отказоустойчивой кластеризации Windows Server 2012».

Обязательные условия отказоустойчивой кластеризации

Для построения двухузлового отказоустойчивого кластера Server 2012 необходимы два компьютера, работающие с версиями Server 2012 Datacenter или Standard. Это могут быть физические компьютеры или виртуальные машины. Кластеры с виртуальными узлами можно построить с помощью Microsoft Hyper-V или VMware vSphere. В данной статье используются два физических сервера, но этапы настройки кластера для физических и виртуальных узлов одни и те же. Ключевая особенность заключается в том, что узлы должны быть настроены одинаково, чтобы резервный узел мог выполнять рабочие нагрузки в случае аварийного переключения или динамической миграции. Компоненты, использованные в тестовом отказоустойчивом кластере Server 2012 представлены на рисунке.

Для отказоустойчивого кластера Server 2012 необходимо общее хранилище данных типа iSCSI, Serially Attached SCSI или Fibre Channel SAN. В нашем примере используется iSCSI SAN. Следует помнить о следующих особенностях хранилищ этого типа.

• Каждый сервер должен располагать по крайней мере тремя сетевыми адаптерами: одним для подключения хранилища iSCSI, одним для связи с узлом кластера и одним для связи с внешней сетью. Если предполагается задействовать кластер для динамической миграции, то полезно иметь четвертый сетевой адаптер. Однако динамическую миграцию можно выполнить и через внешнее сетевое соединение - она просто будет выполняться медленнее. Если серверы используются для виртуализации на основе Hyper-V и консолидации серверов, то нужны дополнительные сетевые адаптеры для передачи сетевого трафика виртуальных машин.
• В быстрых сетях работать всегда лучше, поэтому быстродействие канала связи iSCSI должно быть не менее 1 ГГц.
• Цель iSCSI должна соответствовать спецификации iSCSI-3, в частности обеспечивать постоянное резервирование. Это обязательное требование динамической миграции. Оборудование почти всех поставщиков систем хранения данных соответствует стандарту iSCSI 3. Если нужно организовать кластер в лабораторной среде с небольшими затратами, обязательно убедитесь, что программное обеспечение цели iSCSI соответствует iSCSI 3 и требованиям постоянного резервирования. Старые версии Openfiler не поддерживают этот стандарт, в отличие от новой версии Openfiler с модулем Advanced iSCSI Target Plugin (http://www.openfiler.com/products/advanced-iscsi-plugin). Кроме того, бесплатная версия StarWind iSCSI SAN Free Edition компании StarWind Software (http://www.starwindsoftware.com/starwind-free) полностью совместима с Hyper-V и динамической миграцией. Некоторые версии Microsoft Windows Server также могут функционировать в качестве цели iSCSI, совместимой со стандартами iSCSI 3. В состав Server 2012 входит цель iSCSI. Windows Storage Server 2008 R2 поддерживает программное обеспечение цели iSCSI. Кроме того, можно загрузить программу Microsoft iSCSI Software Target 3.3 (http://www.microsoft.com/en-us/download/details.aspx?id=19867), которая работает с Windows Server 2008 R2.

Дополнительные сведения о настройке хранилища iSCSI для отказоустойчивого кластера приведены во врезке «Пример настройки хранилища iSCSI». Более подробно о требованиях к отказоустойчивой кластеризации рассказано в статье «Failover Clustering Hardware Requirements and Storage Options» (http://technet.microsoft.com/en-us/library/jj612869.aspx).

Добавление функций отказоустойчивой кластеризации

Первый шаг к созданию двухузлового отказоустойчивого кластера Server 2012 - добавление компонента отказоустойчивого кластера с использованием диспетчера сервера. Диспетчер сервера автоматически открывается при регистрации в Server 2012. Чтобы добавить компонент отказоустойчивого кластера, выберите Local Server («Локальный сервер») и прокрутите список вниз до раздела ROLES AND FEATURES. Из раскрывающегося списка TASKS выберите Add Roles and Features, как показано на экране 1. В результате будет запущен мастер добавления ролей и компонентов.

Первой после запуска мастера откроется страница приветствия Before you begin. Нажмите кнопку Next для перехода к странице выбора типа установки, на которой задается вопрос, нужно ли установить компонент на локальном компьютере или в службе Remote Desktop. Для данного примера выберите вариант Role-based or feature-based installation и нажмите кнопку Next.

На странице Select destination server выберите сервер, на котором следует установить функции отказоустойчивого кластера. В моем случае это локальный сервер с именем WS2012-N1. Выбрав локальный сервер, нажмите кнопку Next, чтобы перейти к странице Select server roles. В данном примере роль сервера не устанавливается, поэтому нажмите кнопку Next. Или можно щелкнуть ссылку Features в левом меню.

На странице Select features прокрутите список компонентов до пункта Failover Clustering. Щелкните в поле перед Failover Clustering и увидите диалоговое окно со списком различных компонентов, которые будут установлены как части этого компонента. Как показано на экране 2, по умолчанию мастер установит средства управления отказоустойчивыми кластерами и модуль отказоустойчивого кластера для Windows PowerShell. Нажмите кнопку Add Features, чтобы вернуться на страницу выбора компонентов. Щелкните Next.

На странице Confirm installation selections будет показана функция отказоустойчивого кластера наряду с инструментами управления и модулем PowerShell. С этой страницы можно вернуться и внести любые изменения. При нажатии кнопки Install начнется собственно установка компонентов. После завершения установки работа мастера будет завершена и функция отказоустойчивого кластера появится в разделе ROLES AND FEATURES диспетчера сервера. Этот процесс необходимо выполнить на обоих узлах.

Проверка отказоустойчивого кластера

Следующий шаг после добавления функции отказоустойчивого кластера - проверка настроек среды, в которой создан кластер. Здесь можно воспользоваться мастером проверки настроек в диспетчере отказоустойчивого кластера. Этот мастер проверяет параметры аппаратных средств и программного обеспечения всех узлов кластера и сообщает обо всех проблемах, которые могут помешать организации кластера.

Чтобы открыть диспетчер отказоустойчивого кластера, выберите параметр Failover Cluster Manager в меню Tools в диспетчере сервера. В области Management щелкните ссылку Validate Configuration, как показано на экране 3, чтобы запустить мастер проверки настроек.

Экран 3. Запуск мастера проверки конфигурации

Сначала выводится страница приветствия мастера. Нажмите кнопку Next, чтобы перейти к выбору серверов или странице Cluster. На этой странице введите имена узлов кластера, который необходимо проверить. Я указал WS2012-N1 и WS2012-N2. Нажмите кнопку Next, чтобы показать страницу Testing Options, на которой можно выбрать конкретные наборы тестов или запустить все тесты. По крайней мере в первый раз я рекомендую запустить все тесты. Нажмите кнопку Next, чтобы перейти на страницу подтверждения, на которой показаны выполняемые тесты. Нажмите кнопку Next, чтобы начать процесс тестирования кластера. В ходе тестирования проверяется версия операционной системы, настройки сети и хранилища всех узлов кластера. Сводка результатов отображается после завершения теста.

Если тесты проверки выполнены успешно, можно создать кластер. На экране 4 показан экран сводки для успешно проверенного кластера. Если при проверке обнаружены ошибки, то отчет будет отмечен желтым треугольником (предупреждения) или красным значком "X" в случае серьезных ошибок. С предупреждениями следует ознакомиться, но их можно игнорировать. Серьезные ошибки необходимо исправить перед созданием кластера.

В результате будет запущен мастер создания кластера, работа которого начинается со страницы приветствия. Нажмите кнопку Next, чтобы перейти на страницу выбора серверов, показанную на экране 6. На этой странице введите имена всех узлов кластера, затем нажмите кнопку Next.

На странице Access Point for Administering the Cluster следует указать имя и IP-адрес кластера, которые должны быть уникальными в сети. На экране 7 видно, что имя моего кластера WS2012-CL01, а IP-адрес - 192.168.100.200. При использовании Server 2012 IP-адрес кластера может быть назначен через DHCP, но я предпочитаю для своих серверов статически назначаемый IP-адрес.

После ввода имени и IP-адреса нажмите кнопку Next, чтобы увидеть страницу подтверждения (экран 8). На этой странице можно проверить настройки, сделанные при создании кластера. При необходимости можно вернуться и внести изменения.

После нажатия кнопки Next на странице подтверждения формируется кластер на всех выбранных узлах. На странице хода выполнения показаны шаги мастера в процессе создания нового кластера. По завершении мастер покажет страницу сводки с настройками нового кластера.

Мастер создания кластера автоматически выбирает хранилище для кворума, но часто он выбирает не тот диск кворума, который хотелось бы администратору. Чтобы проверить, какой диск используется для кворума, откройте диспетчер отказоустойчивого кластера и разверните кластер. Затем откройте узел Storage и щелкните узел Disks. Диски, доступные в кластере, будут показаны на панели Disks. Диск, выбранный мастером для кворума кластера, будет указан в разделе Disk Witness in Quorum.

В данном примере для кворума был использован Cluster Disk 4. Его размер 520 Мбайт, чуть больше минимального значения для кворума 512 Мбайт. Если нужно использовать другой диск для кворума кластера, можно изменить настройки кластера, щелкнув правой кнопкой мыши имя кластера в диспетчере отказоустойчивого кластера, выбрав пункт More Actions и Configure Cluster Quorum Settings. В результате появится мастер выбора конфигурации кворума, с помощью которого можно изменить параметры кворума кластера.

Настройка общих томов кластера и роли виртуальных машин

Оба узла в моем кластере имеют роль Hyper-V, так как кластер предназначен для виртуальных машин с высокой доступностью, обеспечивающих динамическую миграцию. Чтобы упростить динамическую миграцию, далее требуется настроить общие тома кластера Cluster Shared Volumes (CSV). В отличие от Server 2008 R2, в Server 2012 общие тома кластера включены по умолчанию. Однако все же требуется указать, какое хранилище следует использовать для общих томов кластера. Чтобы включить CSV на доступном диске, разверните узел Storage и выберите узел Disks. Затем выберите диск кластера, который нужно использовать как CSV, и щелкните ссылку Add to Cluster Shared Volumes на панели Actions диспетчера отказоустойчивого кластера (экран 9). Поле Assigned To этого диска кластера изменится с Available Storage на Cluster Shared Volume (общий том кластера), как показано на экране 9.

В это время диспетчер отказоустойчивого кластера настраивает хранилище диска кластера для CSV, в частности добавляет точку подключения в системном диске. В данном примере общие тома кластера включаются как на Cluster Disk 1, так и на Cluster Disk 3 с добавлением следующих точек подключения:

* C:ClusterStorageVolume1 * C:ClusterStorageVolume2

На данном этапе построен двухузловой кластер Server 2012 и включены общие тома кластера. Затем можно установить кластеризованные приложения или добавить в кластер роли. В данном случае кластер создан для виртуализации, поэтому добавляем роль виртуальной машины в кластер.

Чтобы добавить новую роль, выберите имя кластера на панели навигации диспетчера отказоустойчивого кластера и щелкните ссылку Configure Roles на панели Actions, чтобы запустить мастер высокой готовности. Нажмите кнопку Next на странице приветствия, чтобы перейти на страницу выбора роли. Прокрутите список ролей, пока не увидите роль виртуальной машины, как показано на экране 10. Выберите роль и нажмите кнопку Next.

На странице выбора виртуальной машины будут перечислены все VM на всех узлах кластера, как показано на экране 11. Прокрутите список и выберите виртуальные машины, которым необходимо обеспечить высокую готовность. Нажмите кнопку Next. Подтвердив свой выбор, нажмите Next, чтобы добавить роли виртуальной машины в диспетчер отказоустойчивого кластера.

Пример настройки хранилища iSCSI

Для отказоустойчивого кластера Windows Server 2012 требуется общее хранилище, которое может быть типа iSCSI, Serially Attached SCSI или Fibre Channel SAN. В данном отказоустойчивом кластере используется Channel SAN.

Сначала в сети iSCSI SAN были созданы три логических устройства LUN. Один LUN был создан для диска кворума кластера (520 Мбайт). Другой LUN предназначен для 10 виртуальных машин и имеет размер 375 Гбайт. Третий LUN выделен для небольшой тестовой виртуальной машины. Все три LUN представлены в формате NTFS.

После того, как были созданы LUN, была выполнена настройка iSCSI Initiator на обоих узлах Server 2012. Чтобы добавить цели iSCSI, был выбран iSCSI Initiator в меню Tools в диспетчере сервера. На вкладке Discovery я нажал кнопку Discover Portal. В результате появилось диалоговое окно Discover Portal, куда были введены IP-адрес (192.168.0.1) и порт iSCSI (3260) сети SAN.

Затем я перешел на вкладку Targets и нажал кнопку Connect. В диалоговом окне Connect To Target («Подключение к целевому серверу») я ввел целевое имя iSCSI SAN. Оно было получено из свойств SAN. Имя зависит от поставщика SAN, имени домена и имен созданных LUN. Помимо целевого имени я установил режим Add this connection to the list of Favorite Targets.

По завершении настройки iSCSI эти LUN появились на вкладке Targets iSCSI Initiator. Чтобы автоматически подключать LUN при запуске Server 2012, я убедился, что они перечислены на вкладке Favorite Targets, как показано на экране A.

Экран A. Настройка iSCSI Initiator

Наконец, были назначены буквенные обозначения устройствам LUN с помощью оснастки Disk Management консоли управления Microsoft (MMC). Я выбрал Q для диска кворума и W для диска, используемого для виртуальных машин и общих томов кластера (CSV). При назначении буквенных обозначений необходимо сначала назначить их на одном узле. Затем нужно перевести диски в автономный режим и сделать аналогичные назначения на втором узле. Результаты назначения букв дискам для одного узла приведены на экране B. При создании кластера диски будут показаны как доступное хранилище.

Настройка NLB в Windows Server 2012

Компонент балансировки сетевой нагрузки (Network Load Balancing, NLB) в Windows Server 2012 распределяет сетевой трафик по нескольким серверам с помощью протокола TCP/IP. Группируя два и более сервера в единый виртуальный кластер, NLB повышает доступность и масштабируемость серверных приложений.

NLB умеет выполнять балансировку нагрузки любых приложений и служб, использующих сетевой протокол TCP/IP и связанных с определенным TCP- или UDP-портом. Использовать балансировку сетевой нагрузки целесообразно для обеспечения работы приложений, выполняемых без учета состояния, например для веб-, FTP- или служб удаленных рабочих столов (Remote Desktop).

Также NLB может пригодиться и в менее очевидных ситуациях. К примеру, с помощью этого механизма можно обеспечить повышенную избыточность веб-серверов front-end на базе SharePoint 2010, а при использовании Exchange 2010 выравнивание сетевой нагрузки можно применять в целях создания CAS-массивов для роли сервера клиентского доступа (Client Access Server).

Принцип работы

Кластер NLB представляет из себя группу серверов, называемых узлами кластера. На каждом узле выполняется собственная копия приложения. Механизм NLB занимается тем, что распределяет входящие запросы между узлами в соответствии с заданными правилами. При этом можно настроить нагрузку для каждого узла, а если нужно обработать дополнительную нагрузку, узлы можно добавлять к кластеру динамически. Кроме того, технология балансировки сетевой нагрузки может направлять весь трафик на один определенный узел, называемый узлом по умолчанию.

NLB дает возможность обращаться ко всем серверам в кластере по единому IP-адресу, а также поддерживает набор уникальных IP-адресов для каждого узла. При сбое на узле или его отключении нагрузка автоматически перераспределяется между работающими серверами. При внезапном отключении все активные подключения к такому серверу будут потеряны, однако если работа узла завершается намеренно, есть возможность обслужить все активные подключения до отключения компьютера. В любом случае отключенный компьютер, когда он будет готов к работе, может снова присоединиться к кластеру в рабочем режиме и взять на себя часть нагрузки, что позволит снизить объем данных, приходящийся на другие узлы кластера.

Все узлы NLB кластера обмениваются сообщениями пульса (heartbeat) для согласования данных о членстве в кластере. По умолчанию, если узел не отправляет сообщений пульса в течение пяти секунд, это считается сбоем. При сбое на узле остальные узлы кластера начинают процесс схождения (converging):

Выявляют узлы, оставшиеся активными членами кластера;
назначают узел с наивысшим приоритетом узлом по умолчанию;
обеспечивают обработку новых запросов клиентов работающими узлами.

В процессе схождения работающие узлы ищут регулярные сообщения пульса. Если узел, на котором произошел сбой, начинает передавать сообщения пульса регулярно, он снова присоединяется к кластеру в процессе схождения. Когда к кластеру пытается присоединиться новый узел, он передает свои сообщения пульса, которые тоже запускают схождение. После того как все узлы кластера придут к соглашению по членству в кластере на данный момент, нагрузка от клиентов перераспределяется между узлами, оставшимися в результате, и схождение завершается.

Схождение обычно длится несколько секунд, поэтому перерыв в работе клиентских служб оказывается незначительным. Во время схождения узлы, оставшиеся активными, продолжают обработку клиентских запросов без изменения в имеющихся подключениях. Схождение завершается, когда все узлы одинаково описывают членство в кластере и схему распределения на протяжении нескольких периодов пульса.

Установка

NLB устанавливается как стандартный компонент Windows и не требует для запуска и работы каких-либо изменений в оборудовании. Тем не менее при планировании NLB кластера необходимо учесть некоторый моменты:

В кластер может входить до 32 узлов;
Все узлы кластера должны располагаться в одной подсети;
Количество сетевых адаптеров на каждом узле не ограничено, при этом различные узлы могут иметь разное число адаптеров;
Все сетевые адаптеры в одном кластере необходимо использовать либо в одноадресном (Unicast), либо в многоадресном (Multicast) режиме. Балансировка сетевой нагрузки не поддерживает смешанную среду одноадресной и многоадресной рассылки внутри одного кластера;
При использовании одноадресного режима сетевой адаптер, задействованный для нужд кластера, должен поддерживать программное изменение MAC-адреса;
Сетевой адаптер, на котором включается NLB, может использовать только протокол TCP/IP. Нельзя добавлять для этого адаптера другие протоколы (например IPX);
IP-адреса серверов в составе кластера должны назначаться статически. NLB не поддерживает протокол DHCP и отключает его на каждом настраиваемом интерфейсе;
NLB не работает совместно со службой Failover Clustering. Если сервер является частью отказоустойчивого кластера, то задействовать на нем балансировку сетевой нагрузки не получится.

Если все условия соблюдены, то приступаем к развертыванию кластера. Первым делом необходимо установить сам компонент балансировки сетевой нагрузки. Для этого открываем Server Manager и запускаем мастер установки ролей и компонентов. Переходим на вкладку Features и отмечаем компонент Network Load Balancing.

Также NLB можно установить с помощью PowerShell, следующей командой:

Install-WindowsFeature -Name NLB -IncludeManagementTools

Создание нового NLB кластера

Установив компонент NLB приступим к созданию кластера, для чего воспользуемся оснасткой Network Load Balancing Manager. Открыть ее можно из Server Manager, кликнув по кнопке Tools и выбрав соответствующий пункт меню. Как вариант, можно нажать Win+R и ввести команду nlbmgr .

Для создания нового кластера в NLB Manager выбираем пункт Cluster -> New.

В открывшемся окне указываем имя (или IP-адрес) компьютера, которому предстоит стать первым узлом кластера и жмем «Connect». Выбираем сетевой интерфейс, который будет задействован для нужд кластера.

Примечание. Балансировка сетевой нагрузки может быть привязана к нескольким сетевым адаптерам, что позволяет настроить несколько независимых NLB-кластеров на каждом узле. Поддержка нескольких сетевых адаптеров - это не то же самое, что виртуальные кластеры, в которых можно настраивать несколько кластеров на одном сетевом адаптере.

Задаем уникальный идентификатор узла (unique host identifier). Это очень важный параметр, с помощью которого устанавливается приоритет при обработке трафика. Узел с наименьшим host ID среди членов кластера на данный момент обрабатывает весь сетевой трафик кластера, не предусмотренный правилами для порта;
Указываем выделенный IP-адрес (Dedicated IP, DIP) — уникальный адрес узла, по которому он будет доступен в сети;
Определяем дефолтное состояние (Default state) узла — запущен (Started), остановлен (Stopped) или приостановлен (Suspended) и указываем, должен ли узел сохранять это состояние при перезагрузке.

Задаем виртуальный IP-адрес кластера (Virtual IP, VIP) — адрес, который будет совместно использоваться всеми узлами в кластере. NLB добавит этот IP-адрес в стек протоколов TCP/IP на выбранном интерфейсе всех узлов, вводимых в состав кластера. При необходимости для одного сетевого интерфейса можно указать несколько IP-адресов.

Задаем имя кластера (Full Internet name) соответствующее указанному IP-адресу. В принципе это имя ни на что не влияет, но правильнее будет вписать сюда FQDN-имя, по которому клиенты будут обращаться к кластеру. Также не забудьте создать в DNS соответствующую запись.

Указываем режим работы кластера, который определяет, будет ли для операций кластера использоваться встроенный MAC-адрес адаптера:

Одноадресный (Unicast) — В этом режиме встроенный MAC-адрес физического сетевого адаптера отключается и заменяется МАС-адресом виртуального адаптера кластера. Оба IP-адреса сервера (выделеный IP-адрес сервера и IP-адрес кластера) разрешаются в один единственный МАС-адрес кластера.

При использовании одноадресного режима всем узлам кластера назначается один и тот же IP и MAC-адрес. Поскольку все узлы кластера разделяют один MAC-адрес, а оригинальный MAC-адрес адаптера не используется, использовать адаптер кластера для других целей кроме кластерных (например для управления сервером) становится проблематично. Эту проблему можно обойти, используя несколько сетевых адаптеров: один для кластерного трафика, второй для управления.

Многоадресный (Multicast) — В этом режиме NLB преобразует MAC-адрес кластерного адаптера в адрес группы. IP-адрес кластера разрешается в этот адрес групповой рассылки, а выделенный IP-адрес сервера — в оригинальный MAC-адрес адаптера.

При этом у адаптера остается оригинальный, встроенный MAC-адрес, что дает возможность использовать оба IP-адреса: кластера для трафика клиент-кластер, а выделенный для остального сетевого трафика, специфичного для компьютера. Обратите внимание, что режим Multicast обязательно должен поддерживаться сетевым оборудованием, кроме того может потребоваться дополнительная настройка на коммутаторе.

Многоадресный IGMP (IGMP Multicast) — Многоадресный режим с поддержкой протокола групповой передачи данных (Internet Group Management Protocol, IGMP). Включение поддержки IGMP дает возможность ограничить широковещательный трафик, т.е. обеспечить прохождение трафика к NLB-кластеру только через порты, обслуживающие узлы кластера, а не через все порты коммутатора. Для обеспечения этого режима необходимо включить поддержку IGMP на сетевом оборудовании.

Примечание. Все узлы кластера должны работать в одном режиме — либо в одноадресном, либо в многоадресном. NLB не поддерживает смешанную среду одноадресной и многоадресной рассылки внутри одного кластера.

Переходим к следующему экрану. Настройку правил портов (Port Rules) сейчас производить не будем, поэтому просто жмем «Finish». Первый этап создания NLB кластера завершен.

Добавление узла в кластер

Итак, мы имеем NLB кластер, состоящий из одного узла. Добавим остальные. Kликаем на имени кластера правой клавишей и выбираем пункт «Add Host To Cluster».

Процедура добавления практически аналогична предыдущей. Указываем имя сервера, жмем «Connect» и выбираем сетевой интерфейс, который будет использоваться кластером.

Задаем host ID и указываем выделенный IP-адрес узла, а также состояние узла по умолчанию.

И жмем «Finish». Таким же образом добавляем остальные сервера в кластер.

Создать кластер и добавить в него узлы можно и с помощью PowerShell. Команда для создания кластера:

New-NlbCluster -ClusterName nlb.contoso.com -InterfaseName ″Ethernet″
-ClusterPrimaryIP 192.168.0.10 -SubnetMask 255.255.255.0
-OperationMode Unicast -Force

Для добавления узла в кластер:

Get-NlbCluster | Add-NlbClusterNode SRV5.contoso.com -NewNodeInterface ″Ethernet″ -Force

В результате у нас получился NLB кластер, состоящий из трех узлов.

Настройка параметров кластера

После добавления всех узлов можно приступать к настройке кластера. Кликаем правой клавишей на имени кластера и переходим на пункт «ClusterProperties».

На вкладке Cluster IP Addresses можно изменить существующий адрес кластера или добавить новый. Балансировки сетевой нагрузки позволяет настроить для одного кластера несколько IP-адресов, для каждого адреса назначить собственное имя и настроить правила обработки трафика. Для этого не требуется выделять отдельный адаптер, так что можно настраивать несколько виртуальных NLB кластеров на одном сетевом адаптере.

На вкладке Cluster Parameters можно настроить соответствие имени и IP-адреса кластера и изменить режим его работы.

И на вкладке Port Rules настраиваются правила обработки трафика всеми узлами кластера. При создании кластера создается правило по умолчанию, которое надо изменить, поэтому выделяем его и жмем «Edit».

Правило порта включает в себя следующие настройки:

Cluster IP Addresses — IP-адрес кластера, для которого будет действовать это правило. По умолчанию отмечен чекбокс All, что означает воздействие данного правила на все адреса в кластере.

Port Range — диапазон портов, на которых будет обрабатываться трафик кластера. По умолчанию указаны все порты, что не очень правильно. Например, если у вас кластеризовано веб-приложение, использующее для клиентского доступа порт 80 TCP, то указываем этот порт как начало и конец диапазона. Если нужно указать несколько портов, то для каждого придется создать отдельное правило.

Protocols — протоколы, к которым будет применяться данное правило: TCP, UDP или оба.

Filtering Mode — режим фильтрации. Здесь мы указываем, как именно будет обрабатываться трафик кластера. Можно выбрать из двух режимов:

1) Multiple host — трафик по указанным портам будет распределяться среди всех узлов кластера. В этом случае нужно выбрать режим сходства (affinity), который определяет привязку клиента к определенному узлу кластера:

• None — привязка не используется. Все новые соединения распределяются по разным узлам в зависимости от нагрузки;
• Single — привязка осуществляется по IP-адресу клиента. После того, как клиент осуществил подключение к определенному узлу кластера, в течение установленного сеанса все новые соединения с его IP будут направлены на тот же узел кластера;
• Network — привязка основана на принадлежности клиента к определенной частной подсети. Когда один клиент устанавливает соединение к некоторому узлу, все соединения из этой подсети будут направлены на тот же узел.

Также обратите внимание на чекбокс Timeout minutes. Установка галки включает режим расширенного сходства (Extended Affinity), который обеспечивает привязку в отсутствие активных текущих подключений от клиента к узлу, а также позволяет клиентам сохранять соответствие с узлом при изменении конфигурации кластера. Здесь мы можем указать время, в течение которого клиент будет привязан к определенному узлу при отсутствии активного текущего подключения с его стороны.

2) Single host — весь трафик по указанным портам будет обрабатываться одним узлом кластера, а если этот узел недоступен — то направлен на следующий узел, вычисляемый по номеру Handling Priority (приоритет обработки). Приоритет присваивается узлу при добавлении сервера в кластер и может быть изменен в свойствах узла.

Disable this Port Range — отметив этот пункт, мы запретим обработку трафика на указанных портах. Как я уже говорил, весь сетевой трафик, не подпадающий под действие правил портов, обрабатывается действующим узлом кластера с минимальным идентификатором хоста. Чтобы избежать ненужной нагрузки, весь нецелевой трафик можно запретить. Так в случае с 80 портом достаточно создать 2 правила и запретить весь трафик на портах 0-79 и 81-65535.

При создании правил порта нужно учесть, что:

Правила на всех узлах кластера должны быть идентичны. При попытке присоединить к кластеру узел с иными правилами или с другим числом правил он не будет принят в кластер;
Чтобы балансировка сетевой нагрузки корректно обрабатывала IP-фрагменты, не следует использовать значение None для сходства, если выбран протокол UDP или Both;
Если NLB используется для балансировки нагрузки трафика VPN (напр. PPTP/GRE или IPSEC/L2TP), то для правил порта используйте режим сходства Single или Network.

Настройка параметров отдельного узла

Кроме настройки всего кластера есть возможность настраивать параметры отдельных его узлов. Для этого выбираем узел, кликаем на нем правой клавишей и выбираем «Host Properties».

В окне Host Parameters мы сможем:

Изменить идентификатор узла, изменив тем самым его приоритет при обработке нецелевого трафика;
Поиздеваться над его выделенным IP — изменить, удалить или добавить новый. Кстати, выделенный IP-адрес для работы NLB вовсе не обязателен, и при желании его можно вообще не использовать;
Изменить дефолтное состояние узла. Так по умолчанию после перезагрузки узел сразу стартует и начинает обрабатывать клиентские подключения. Изменив дефолтное состояние узла на Stopped и указав хранить это состояние, тем самым мы предотвратим автоматический старт и начало обработку клиентских подключений сервером после перезагрузки. Это может понадобиться для проверки корректности работы сервера, например после установки обновлений.

Также заглянем в правила портов. Здесь нас интересуют два пункта:

Load Weight — процент нагрузки. В режиме фильтрации Multiple Hosts параметр Load Weight используется для того, чтобы задать процент трафика, который должен обрабатываться этим узлом по соответствующему правилу . По умолчанию используется вариант Equal , при котором происходит равномерное распределение нагрузки между всеми узлами кластера. Чтобы задать для узла определенный процент, нужно убрать галку и указать значение от 1 до 100. Значение 0 вообще исключает данный узел из обработки трафика.

Обратите внимание, что сумма значений Load Weight для каждого узла параметра не обязательно должна составлять 100 процентов. Реальная часть трафика для каждого узла рассчитывается динамически как частное от деления процента, заданного для узла, на суммарный процент для всего кластера.

Handling Priority — приоритет обработки трафика в режиме фильтрации Single host. Этот параметр указывает приоритет узла для трафика по данному правилу. Узел с наиболее высоким приоритетом будет обрабатывать весь трафик для этого правила, а при его недоступности трафик будет перенаправлен на следующий по приоритетности узел. Чем меньше значение Handling Priority, тем выше приоритет, значение 1 соответствует наиболее высокому приоритету.

Управление кластером

И немного об управлении кластером NLB. Управление можно осуществлять как на уровне отдельного узла, так и на уровне всего кластера. Для управления узлом кликаем на нем и выбираем «Control Host». Дальше на выбор, можно:

Start — запустить обработку трафика на данном узле;
Stop — остановить обработку трафика на данном узле. При этом все текущие соединения будут закрыты;
Drainstop — остановить обработку трафика на узле, предварительно обработав все текущие подключения. В этом варианте остановки узел обрабатывает текущие клиентские подключения, но не принимает новых;
Suspend — приостановить обработку трафика на данном узле;
Resume — соответственно возобновить приостановленную работу.

Для того, чтобы совсем удалить узел из кластера, надо выбрать пункт «Delete Host».

Выбрав пункт «Control Ports» можно управлять действием правил: включить (Enable), отключить (Disable) или приостановить обработку новых подключений (Drain). Это может потребоваться для того, чтобы временно исключить узел из обработки трафика кластера, например в целях диагностики.

Все то же на уровне кластера — кликаем на имени кластера и выбираем «Control Hosts». Здесь изменения применяются уже ко всем узлам.

В заключение несколько советов, которые могут пригодиться при настройке NLB кластера.

1) Не смотря на название, NLB не отслеживает реальную загрузку (потребление процессорного времени, памяти, дисковой подсистемы и т.д.) на каждом узле. Под нагрузкой в NLB подразумевается только количество активных подключений к узлу. Учитывайте этот момент при настройке распределения нагрузки.
2) NLB не обеспечивает отказоустойчивость клиентских приложений. Механизм NLB отслеживает только наличие сигналов heartbeat между узлами, мониторинг отдельных служб он не осуществляет. Проще говоря, если на одном узле кластера отвалится клиентский сервис, а сетевой интерфейс останется доступен, то NLB этого не заметит и продолжит отправлять клиентов на неработоспособный узел.
3) Как в режиме Unicast, так и в Multicast (за исключением IGMP) трафик кластера распространяется по всем портам коммутатора. Чтобы изолировать этот широковещательный трафик, все IP адреса кластера желательно вынести в отдельную подсеть.
4) Вопреки расхожему мнению режим Unicast можно использовать даже при наличии одного сетевого адаптера на узле. При этом узлы вполне нормально могут общаться между собой, так как NLB преобразует ARP-таблицу внутри каждого узла, назначая каждому узлу уникальный MAC-адрес. А вот снаружи подключиться к узлу кластера не получится, для управления узлом к нему необходим физический доступ либо механизм удаленного управления типа iLo от HP.

Может не справиться с нагрузкой, зависнуть или быть выключенным ради профилактики. Поэтому для обеспечения повышенного уровня надёжности придумана такая полезная штука как кластер серверов. Ну а раз уж данное явление существует, то с ним надо познакомиться, чем и займёмся.

Суть вкратце

Кластер серверов - это не просто несколько компьютеров, соединённых друг с другом проводами, «витыми парами». Это, в первую очередь, программное обеспечение , которое управляет всем этим «железом», распределяет запросы, синхронизирует, осуществляет балансировку нагрузки, подключает базу данных... Впрочем, лучше растолковывать суть явления на конкретном примере.

Пример схемы кластера серверов

В качестве примера возьмём весьма популярный софт «1С:Предприятие 8». Упрощённая схема функционирования кластера серверов выглядит примерно следующим образом.

Клиентское приложение (в смысле, приложение на компьютере пользователя) осуществляет запрос по протоколу TCP/IP. Этот запрос приходит на центральный сервер в кластере, где действует программа-менеджер (Cluster Manager) и располагается реестр кластера.

Центральный сервер на лету анализирует обстановку с загруженностью и перенаправляет запрос (тоже по TCP/IP) на тот компьютер в кластере, у которого в этот момент есть возможность наиболее быстро и эффективно обработать обращение пользователя. После чего за обслуживание запроса берётся конкретный рабочий процесс на конкретной машине.

Рабочий процесс начинает взаимодействовать с клиентским приложением напрямую. Плюс подключается к отдельному серверу с базой данных, который скромно стоит в сторонке, но при этом обслуживает весь кластер. То есть, после успешного срабатывания схемы получается цепочка с двусторонним движением между компонентами: клиентское приложение - рабочий процесс в кластере - сервер базы данных.

Как видим, центральный сервер кластера и его программа-менеджер участия уже не принимают, они своё дело сделали.

Microsoft

Для организации кластера серверов на основе софта от корпорации Microsoft требуется операционная система «Microsoft® Windows Server™ 2008», причём, «Enterprise Edition» или «Datacenter Edition». Там есть софт «Windows Server Failover Clustering». (Ранее, в релизе ОС за 2003-й год, программное изделие называлось «Microsoft Cluster Server», сокращённо MSCS.)

По версии Microsoft, кластер - это несколько узлов (то бишь, компьютеров) общим количеством до шестнадцати штук (в релизе 2003-го - до восьми), объединённых в единую систему. Один узел впал в ступор сам или был выключен для технического обслуживания - его функции сразу же передаются другому.

Кластер в Windows Server создаётся с помощью графического интерфейса «Cluster Control Panel». Десяток диалоговых окошек - и готово.

Oracle

Компания Oracle для создания кластеров производит продукт «WebLogic». Есть версии и для Windows , и для GNU/Linux .

Велосипед изобретать не стали: работой и балансировкой нагрузки руководит сервер-администратор (Admin Server), к которому подключены узлы (Managed Servers). Всё вместе объединяется в единый домен.

Причём, с помощью «WebLogic» в домен можно сгруппировать даже не один, а несколько кластеров. Кроме того, доступны: 1) репликация пользовательских сессий в серверах кластера; 2) балансировка нагрузки (с помощью компонента HttpClusterServlet).

Настройка посложнее, диалоговых окошек много. Но зато можно либо создать кластер самостоятельно с нуля, либо использовать готовый шаблон.

Кроме того, имеется продукт «Oracle Real Application Clusters» (сокращённо «Oracle RAC») для синхронизированной работы «Oracle Database» на нескольких узлах, что тоже по своей сути является кластером.

Заключение

Благодаря умному софту кластер выглядит «со стороны», с точки зрения клиента, как один единственный компьютер, к которому осуществляется запрос. В этом отличие кластера от Grid-систем распределённых вычислений, где компьютеры вовсе необязательно объединены в домен, вполне могут быть удалёнными.

Кластер серверов очень уместен и полезен для систем, подверженных нешуточным рабочим нагрузкам. И если предприятие расширяется, клиенты множатся и потихоньку начинают ворчать из-за торможения сервиса, то имеет смысл задуматься над внедрением вышеописанной технологии.

Предыдущие публикации: