Кластерные операционные системы Microsoft

МИНИСТЕРСТВО ПРОСВЕЩЕНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

«ВОРОНЕЖСКИЙ ГОСУДАРСТВЕННЫЙ ПЕДАГОГИЧЕСКИЙ УНИВЕРСИТЕТ»

КАФЕДРА ИНФОРМАТИКИ, ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И ЦИФРОГО ОБРАЗОВАНИЯ

Реферат

по дисциплине «Операционные системы»

На тему: «Кластерные операционные системы Microsoft»

Направление подготовки 09.03.03 «Прикладная информатика»

Направленность (профиль) «Прикладная информатика в образовании»

Выполнил: студент заочной формы обучения 2 курса

физико-математического факультета

Горбунова Дарья Алексеевна

Проверил: к.ф.-м.н., доцент кафедры Истиц

Быкова Ксения Игоревна

Воронеж – 2023

Содержание

Введение………………………………………………………………………………3

1.Программные решения вендоров, поддерживающие кластеризацию……..5

2. Преимущество использование кластеров…………………………………......8

3. Работа кластеризации…………………………………………………………...11

4. Возможности кластеризации…………………………………………………...15

Заключение…………………………………………………………………………..21

Список литературы…………………………………………………………………22

Введение

Что такое кластер?

Кластер серверов (Server Cluster) — это определенное количество серверов, объединенных в группу и образующих единый ресурс. Данное решение позволяет существенно увеличить надежность и производительность системы.

Сгруппированные по логике производственной необходимости (файловые сервера, почтовые, сервера БД и т.п.) несколько компьютеров можно назвать аппаратным кластером, однако, суть данного объединения — повышение стабильности и работоспособности системы за счет единого программного обеспечения под управлением модуля (Cluster Manager).

Общая логика кластера серверов создается на уровне программных протоколов и дает возможность:

• Управлять произвольным количеством аппаратных средств с помощью одного программного модуля;

• Добавлять и усовершенствовать программные и аппаратные ресурсы, без остановки системы и масштабных архитектурных преобразований;

• Обеспечивать бесперебойную работу системы, при выходе из строя одного или нескольких серверов;

• Синхронизировать данные между серверами — единицами кластера;

• Эффективно распределять клиентские запросы по серверам;

• Использовать общую базу данных кластера.

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

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

Принято считать, что кластеры серверов делятся на две модели:

• Использование единого массива хранения информации, что дает возможность более быстрого переподключения при сбое. Однако в случае с объемной базой данных и большим количеством аппаратных единиц в системе, возможно падение производительности;

• Модель, при которой серверы независимы, как и их периферия. В случае отказа перераспределение происходит между серверами. Здесь ситуация обратная — трафик в системе более свободен, однако, усложняется и ограничивается пользование общей базой данных.

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

1.Программные решения вендоров(производителей), поддерживающие кластеризацию.

Для операционных систем серверов есть ряд программных решений при работе по созданию кластеров. Среди них выделяются:

• Windows Server Failover Clustering (WSFC);

• Veritas InfoScale Availability;

• IBM PowerHA System Mirror;

• Percona XtraDB Cluster;

• SUSE Linux Enterprise High Availability Extension (HAE);

• InfoScale Availability;

• Red Hat Cluster Suite;

• DRBD;

• Oracle Real Application Clusters (RAC).

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

Для обозначения используется HA (от High Availability), что и переводится с английского как высокая доступность. Работа обеспечивается за счет повышенного числа узлов, которые гарантируют непрерывность в функционировании приложений и сервисов.

Отказоустойчивые кластеры HA востребованы для серверов, поддерживающих:

1. базы данных;

2. системы управления предприятиями;

3. СМС-сообщения, электронную почту;

4. CRM и веб-приложения.

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

Особенность работы кластера NLB заключается в том, что серверными узлами принимается поступающая информация для последующего равномерного ее распределения на вычислительные системы. Итогом этого становится значительное повышение производительности, рационализация использования кластера. При этом также возрастает надежность работы.

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

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

Типовыми задачами для вычислительных кластеров являются:

1. моделировать сложные физические и химические процессы, реакции;

2. обрабатывать цифровые сигналы, производить визуализацию данных;

3. проводить математический, финансовый анализ.

Основное качество HPC – высокая производительность.

Особенностью кластера такого типа является применение программного модуля. С его помощью осуществляется взаимодействие между разными серверами системы. Также кластер отличается тем, что для его работы система должна:

• синхронизировать информацию, содержащуюся на разных узлах кластера;

• распределять нагрузку между входящими в конфигурацию серверами.

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

Физические серверы не уступают свои позиции виртуальным при создании кластеров. Они представляют собой локальную сеть объединенных между собой узлов. Для такой группы характерно следующее:

• используется один IP-адрес;

• применяются высокоскоростные сети для обмена информацией.

Для формирования кластера удобно размещать оборудование в относительно компактном пространстве. Это упрощает подключение узлов в общую группу. Применяется также дополнительное оборудование, включая стойки, полки, стеллажи для физического и компактного размещения оборудования, удобства обслуживания.

2.Преимущество использование кластеров.

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

Балансировка осуществляется на уровнях:

1. сетевом, при котором за один IP-адрес отвечают разные аппараты;

2. транспортном, ориентированном на автоматическое распределение запросов балансировщиком;

3. прикладном, обеспечивающем распределение в зависимости от поступающего контента.

Посредством балансировки повышается производительность кластера, ускоряется обработка запросов.

Выбор мастера происходит в следующих ситуациях:

1. при включении системы отказоустойчивости в кластере;

2. при выходе из строя действующего мастера;

3. при изменении конфигурации HA-кластера;

4. при обновлении версии HA-кластера.

Чтобы выбор прошёл успешно, в нём должно участвовать (N/2 + 1) узлов, где N — общее число узлов кластера. Значение (N/2 + 1) нужно округлить до целого числа в меньшую сторону. Например, в кластере с двумя узлами должны участвовать оба узла, в кластере с 17 узлами — 9. Если исправных узлов в кластере меньше, чем необходимо, процедура выбора не начнётся. Если узлов будет больше, чем необходимо, то в выборе примут участие только те узлы, которые были готовы к процедуре раньше. Алгоритмы Corosync гарантируют, что информация о времени готовности узлов к выбору одинакова для всех участников кластера.

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

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

Обычно процедура выбора занимает около 15 секунд.

В отказоустойчивом кластере узлы могут принимать следующие статусы:

• рабочие:

• мастер — узел в рабочем состоянии и выбран мастером;

• участник — узел в рабочем состоянии;

• нерабочие:

• изоляция по сети — узел недоступен по сети, но у узла есть доступ к хранилищу;

• изоляция по хранилищу — у узла нет доступа к хранилищу, но узел доступен по сети;

• полный отказ — узел недоступен по сети и у него нет доступа к хранилищу;

• специальные:

• выход из HA-кластера — узел недоступен по сети, но узлу доступен проверочный IP-адрес;

• сеть нестабильна — сеть регулярно теряется на срок менее 15 секунд.

3.Работа кластеризации.

Схема для работы БД

Master — узел-мастер

Slave — узлы-участники

Network storage — сетевое хранилище кластера

Management network — сеть управления узлами кластера

Case1 — пример статуса "изоляция по сети"

Case2 — пример статуса "изоляция по хранилищу"

Case3 — пример статуса "полный отказ"

При некоторой конфигурации активный/ активный вы можете иметь активными оба узла в одно и то же время и размещая отдельные, исполняющие различные задания, экземпляры сервера SQL на каждом. В действительности это не является истинной совместимостью с RAC- подобным Oracle; вместо этого она просто применяет оба узла для мощности обработки различных рабочих нагрузок. Это даёт организациям с более ограниченными возможностями оборудования некую возможность использования кластерной конфигурации, которая может отрабатывать отказ на- или с- любого узла без необходимости устанавливать на площадке простаивающее оборудование, однако это вносит некую проблему нагрузки на каждый узел в случае возникновения отработки отказа. Поэтому будьте аккуратными с этим подходом.

Как уже упоминалось ранее, отказоустойчивый кластер SQL в действительносьти создаётся внутри (поверх) WSFC. WSFC, а не сервер SQL, способен обнаруживать отказы оборудования или программного обеспечения и автоматически смещать контроль над управляемыми ресурсами в некий жизнеспособный узел. Сервер SQL 2016 применяет отказоустойчивый кластер, основывающийся на имеющихся свойствах кластера WFSC. Как уже отмечалось ранее, сервер SQL является полностью осведомлённом о кластере приложении и становится неким набором ресурсов, управляемых WSFC. Данный отказоустойчивый кластер совместно применяет некий общий набор ресурсов кластера, таких как хранилище кластера (то есть совместно используемая система хранения).

Базовая схема кластеризации на серверах Microsoft Windows Server

Отказоустойчивая конфигурация на примере состоит из двух узлов (нод). Active роль предполагает значения Master кластера, т.е принимает входящие подключения, запись (к примеру RDP, my SQL и т.д), Passive в свою очередь при настройки репликации следит за обновлениями на мастер- ноде.

В случае выхода из строя, роль первого узла мигрирует на второй доступный узел при настройке и включении кворума (см. ниже «Кворум»)

Т.е для конечного пользователя ресурс остается доступным (при использовании Hyper-V возможна задержка 1-5 секунд между миграции роли, в vSphere миграция происходит более плавно)

Хранилище кластерных узлов должно быть выделено (к примеру, iSCSI).

За счет плавной миграции при правильной сборке кластера и кворума, конечный продукт доступен 24/7 вне зависимости от местоположения конечного пользователя.

Для кластеров БД дополнительно используется технология Always-ON (не рассматривается в данном примере)

4.Возможности кластеризации.

Для Server 2012 максимальное число узлов в кластере увеличено до 64. При использовании кластера на базе Hyper-V с виртуальными шинами высокой надежности предельное число виртуальных машин увеличено до 4000 на кластер и 1024 на узел.

Помимо расширения границ, диспетчер серверов теперь обладает способностью обнаруживать и обеспечивать возможности удаленного управления. В скомпонованном кластере диспетчер серверов не только позволяет видеть все узлы, включая имя кластера и все виртуальные машины, но и в состоянии определить, где можно осуществлять удаленное управление (экран 1). Эта возможность позволяет включать дополнительные роли и функции на удаленном компьютере.

Экран 1. Настройка удаленного управления

Обнаружение в Active Directory (AD) объекта, создаваемого кластером в процессе его построения, выведено на новый уровень. Объект создается кластером в том же организационном подразделении (OU), где находятся узлы. Объект имени кластера (CNO) создается под учетной записью пользователя, запустившего сеанс работы, так что активная учетная запись должна обладать полномочиями просмотра и создания элементов. Чтобы обойти обнаружение или разместить объект в другом OU, это можно указать при создании кластера. Например, чтобы поместить объект имени кластера в OU Cluster, нужно указать следующее имя, см. экран 2.

Экран 2. Помещение имени кластера в OU Cluster

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

• Использовать типовые параметры (рекомендуется). Кластер определяет параметры управления кворумом и при необходимости выбирает свидетеля кворума.

• Добавить или изменить свидетеля кворума. Пользователь может выбрать свидетеля кворума. Параметры кворума определяет кластер.

• Расширенный выбор конфигурации и свидетеля кворума. Параметры управления кворумом и свидетеля кворума определяет пользователь.

При выборе типовых параметров мастер устанавливает динамический тип кворума, при котором число голосов меняется в зависимости от числа узлов-участников. Работа кластера зависит от кворума или консенсуса голосов. Каждый узел в кластере имеет голос. Если используется диск-свидетель или ресурс-свидетель, то это еще один голос. Для поддержания работы кластера необходимо, чтобы работало более половины участников голосования. Рассчитать достаточное число голосов можно по формуле (общее число голосов + 1)/2. У меня в кластере без диска-свидетеля имеется девять узлов. По приведенной выше формуле получается, что для поддержания работы кластера необходимо (9 + 1)/2 = 5 голосов.

Рассмотрим кластер Server 2008 R2 в сравнении с кластером Server 2012. Кластеру Server 2008 R2, включающему девять узлов, для функционирования необходимы пять работающих голосов (узлов). Если работают только четыре узла, служба кластера прекращает функционирование, поскольку остающихся голосов недостаточно. В такой ситуации администратор вынужден вручную запускать кластер и возвращать его в рабочий процесс. В отказоустойчивом кластере Server 2012 в случае отказа одного из узлов число голосов, необходимых для работы кластера, динамически уменьшается. В нашем примере с девятью узлами (голосами) если один узел (голос) выходит из строя, то общее число узлов становится равным восьми. При отказе еще двух узлов это число снижается до шести. Кластер Server 2012 будет продолжать работать, не требуя вмешательства администратора. Динамический кворум – это установка по умолчанию и рекомендуемый параметр настройки для кластеров Server 2012.

Для изменения свидетеля кворума в меню, открываемом щелчком правой кнопки мыши на имени кластера на крайней левой панели, выберите More Actions («Дополнительные действия») и Configure Cluster Quorum Settings («Задать параметры кворума кластера») (см. экран 3). Мастер позволяет задать диск-свидетель, файловый ресурс-свидетель, либо оставить кворум динамическим. В дополнительных настройках задаются узлы, обладающие правом голоса в кластере (см. экран 4). Кворум достигается с участием всех узлов в голосовании. При снятии флажка узел лишается голоса. В приведенном ранее примере с кластером Server 2008 R2, включающим девять узлов, в голосовании участвуют только восемь узлов, поэтому требуется добавление диска-свидетеля или ресурса-свидетеля. Если в кластере Server 2008 R2 или Server 2012 в рабочем состоянии остается только узел, не участвующий в голосовании, служба кластеров останавливается, и требуется вмешательство администратора.

Экран 3. Изменение настроек кворума

Экран 4. Выбор узлов кластера, участвующих в голосовании

На следующем экране мастера настройки кворума кластера можно выбрать или отменить выбор динамического кворума (см. экран 5). Как показано на экране, параметр по умолчанию выбран, и он же является рекомендуемым параметром. Изменить настройку кворума и добавить диск-свидетель или ресурс-свидетель можно на следующем экране мастера.

Экран 5. Страница настройки управления кворумом

Реализован ряд усовершенствований проверки кластера. В частности, значительно повышена скорость выполнения тестов хранилища. В ходе этих тестов выполняются измерения, позволяющие установить, какой узел может видеть накопители, определить отработку отказов – индивидуальную и групповую, проверить возможности изъятия накопителя с каждого из узлов и т.д. В отказоустойчивых кластерах Server 2008 R2 при наличии большого числа дисков тесты хранилища занимали много времени. Для кластера Server 2012 тесты оптимально организованы и выполняются значительно быстрее. Введен новый параметр, который позволяет выбрать конкретное логическое устройство (LUN) или подмножество устройств в качестве объектов тестирования (см. экран 6).

Экран 6. Страница настройки управления кворумом

Введены новые тесты для общих томов кластера (CSV), Hyper-V и виртуальных машин. Эти тесты позволяют убедиться в том, что в сетевых настройках заданы рекомендуемые параметры, между компьютерами установлены сетевые соединения, настроена быстрая/динамическая миграция, на всех узлах созданы одинаковые сетевые коммутаторы и т.д.

Заключение

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

В настоящее время данный функционал используется на всех крупных предприятиях, к примеру: кластер почтовых серверов (Exchange), баз данных (MySQL, postgresql). В некоторых случая применяется для ферм (RDP сервера), файловых серверов при использовании Scail-Out.

В текущие дни является основой построения серверных крупных компаний, т.е важная единица при самом построении ИТ-архитектуры.

Использование кластера дает неоспоримое преимущество самому архитектору, а также конечному пользователю до счет полной доступности ресурса.

Список литературы:

1. docs.ispsystem.ru

2. https://learn.microsoft.com/ru-ru/windows-server/failover-clustering/failover-clustering-overview

3. https://www.osp.ru/winitpro/2013/05/13035367