Что такое кластер серверов.

Если в вашей компании программным обеспечением от 1С пользуются несколько сотрудников, то достаточно закупить хороший сервер и правильно его настроить. Однако если число пользователей достигло 150-200 человек и это еще не предел, то установка кластера серверов поможет снизить нагрузку на оборудование. Конечно, установка дополнительного оборудования и подготовка специалистов для поддержки работоспособности кластера потребует некоторых финансовых и временных ресурсов, но это долговременное вложение, компенсирующее впоследствии все затраты за счет бесперебойной работы системы. При этом многое зависит от правильной настройки кластера – производительность можно увеличить в несколько раз без дорогостоящих вложений. Поэтому, перед тем как изучать функционал и закупать сервера, необходимо удостовериться, нужен ли вам кластер серверов 1С вообще.

Когда стоит устанавливать кластер серверов 1С?

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

Отказы оборудования и сетей. Для особо важных баз данных рекомендуется создать кластер серверов, исполняющий роль резервного;
Недостаточная безопасность баз данных. Дополнительным преимуществом является возможность шифрования данных из ПО на платформе 1С;
Неравномерное распределение нагрузки на узлы сервера. Решается с помощью создания нескольких «рабочих процессов», контролирующих клиентские соединения и запросы;
Помимо решения данных проблем правильно настроенный кластер серверов 1С позволяет существенно экономить на поддержке стабильной работы приложений 1С.

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

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

Рассмотрим данный алгоритм на примере объединения двух серверов 1С 8.2 в кластер

Допустим, на сегодня у вас имеется два сервера, на одном из которых (S1C-01) установлен сервер 1С и информационные базы. Чтобы настроить отказоустойчивый кластер серверов, необходимо на сервере S1C-02 развернуть сервер 1С:Предприятие и начать рабочий процесс. Убедитесь, что в его свойствах установлен пункт «Использование» в состояние «Использовать». Регистрировать информационные базы нет необходимости.

После этого в консоли администрирования 1С необходимо добавить в раздел «Резервирование кластеров» резервный кластер с именем второго сервера – S1C-02. В аналогичный раздел второго сервера добавляем резервный кластер с именем S1C-01 и перемещаем его на верхнюю позицию. Для этого воспользуйтесь контекстным меню и командой «Переместить вверх». Необходимо добиться одинакового порядка в этих группах обоих серверов.

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

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

Нагрузка на кластер и оптимизация

Тестирование нагрузки

Наиболее распространенными технологиями тестирования кластера серверов 1С считаются:

Тест Гилева;
Тест центр из 1С:КИП.

В первом случае мы имеем дело с инструментом, позволяющим оценить файловые и клиент-серверные базы. Он включает в себя оценку скорости работы системы, интерфейсов, длительных операций и количества ресурсов для функционирования. Большим плюсом является универсальность – нет никакой разницы, какую конфигурацию вы будете им тестировать. На выходе получается оценка в условных единицах.

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

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

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

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

Крайне полезный параметр для серверов, использующихся 24 часа в сутки – «Интервал перезапуска». Обычно его значение устанавливают в 86400 секунд, чтобы раз в день серверы могли перезапуститься автоматически. Это полезно для снижения отрицательных эффектов от утечки памяти и фрагментации данных на дисках при выполнении операций.

Очень важно, чтобы отказоустойчивый кластер серверов 1С был защищен от перерасхода памяти. Один неудачный запрос в цикле может забрать себе всю мощность многоядерных серверов. Чтобы воспрепятствовать этому существует два параметра кластера – «Допустимый объем памяти» и «Интервал превышения допустимого объема». Если вы правильно и точно настроите эти параметры, то обезопасите свои информационные базы от многих распространенных бед.

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

Еще один параметр – «Выключенные процессы останавливать через» отвечает за регулярное отключение подключений к серверу через заданные промежутки времени. В 1С после завершения работы рабочие процессы висят некоторое время, чтобы данные корректно перенеслись на новые процессы. Иногда происходят сбои и на сервере остаются висеть процессы. Они тратят ресурсы и намного полезнее существенно минимизировать их количество.

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

Для грамотной оптимизации воспользуйтесь консолью кластера серверов и для каждого сервера настройте следующие параметры:

Максимальный объем памяти всех рабочих процессов. Если этот показатель равен 0, то система отводит под процессы 80% оперативной памяти, если же в поле стоит 1, то все 100%. Если на одном сервере стоят вместе 1С и СУБД, то существует вероятность конфликта из-за памяти и необходимо воспользоваться этой настройкой. В ином случае достаточно будет стандартных 80% или рассчитать, сколько необходимо памяти ОС, а оставшееся количество занести в это поле;
Безопасный расход памяти за 1 вызов. По умолчанию значение «0», означающее, что 1 рабочий процесс будет занимать менее 5% максимального объема оперативной памяти на все процессы. Значение «-1» проставлять не рекомендуется, так как оно снимет все ограничения, что чревато последствиями в виде зависаний;
Количество информационных баз и соединений на процесс. Эти параметры управляют распределением нагрузки на рабочие процессы. Вы можете настроить их по своим требованиям, чтобы минимизировать потери при излишней нагрузке на сервер. Если установлено значение в 0, то ограничения не действуют, что опасно при большом количестве рабочих мест.

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

После установки данной характеристики агент сервера ragent перезагрузится и вместо одного rmngr.exe в консоли вы обнаружите целый список. Теперь вы сможете через диспетчер задач найти процесс, загружающий систему и заняться точечной настройкой. Отличить эти процессы друг от друга вам поможет их pid. Однако, так как это нововведение, специалисты 1С рекомендуют осторожно использовать эту возможность.

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

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

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

Примеры

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

Применение

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

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

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

См. также

Wikimedia Foundation . 2010 .

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

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

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

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

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

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

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

Уже на этапе планирования будущей виртуальной инфраструктуры следует задуматься об обеспечении высокой доступности ваших виртуальных машин. Если в обычной ситуации временная недоступность одного из серверов еще может быть приемлема, то в случае остановки хоста Hyper-V недоступной окажется значительная часть инфраструктуры. В связи с чем резко вырастает сложность администрирования - остановить или перезагрузить хост в рабочее время практически невозможно, а в случае отказа оборудования или программного сбоя получим ЧП уровня предприятия.

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

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

В данном материале мы будем рассматривать наиболее простую конфигурацию отказоустойчивого кластера, состоящего из двух узлов (нод) SRV12R2-NODE1 и SRV12R2-NODE2, каждый из которых работает под управлением Windows Server 2012 R2. Обязательным условием для этих серверов является применение процессоров одного производителя, только Intel или только AMD, в противном случае миграция виртуальных машин между узлами будет невозможна. Каждый узел должен быть подключен к двум сетям: сети предприятия LAN и сети хранения данных SAN.

Вторым обязательным условием для создания кластера является наличие развернутой Active Directory, в нашей схеме она представлена контроллером домена SRV12R2-DC1.

Хранилище выполнено по технологии iSCSI и может быть реализовано на любой подходящей платформе, в данном случае это еще один сервер на Windows Server 2012 R2 - SRV12R2-STOR. Сервер хранилища может быть подключен к сети предприятия и являться членом домена, но это необязательное условие. Пропускная способность сети хранения данных должна быть не ниже 1 Гбит/с.

Будем считать, что на оба узла уже установлена операционная система, они введены в домен и сетевые подключения настроены. Откроем Мастер добавления ролей и компонентов и добавим роль Hyper-V .

Следующим шагом добавим компоненту Отказоустойчивая кластеризация .

На странице настройки виртуальных коммутаторов выбираем тот сетевой адаптер, который подключен к сети предприятия.

Миграцию виртуальных машин оставляем выключенной .

Остальные параметры оставляем без изменения. Установка роли Hyper-V потребует перезагрузку, после чего аналогичным образом настраиваем второй узел.

Затем перейдем к серверу хранилища, как настроить iSCSI-хранилище на базе Windows Server 2012 мы рассказывали в , но это непринципиально, вы можете использовать любой сервер цели iSCSI. Для нормальной работы кластера нам потребуется создать минимум два виртуальных диска: диск свидетеля кворума и диск для хранения виртуальных машин. Диск-свидетель - это служебный ресурс кластера, в рамках данной статьи мы не будем касаться его роли и механизма работы, для него достаточно выделить минимальный размер, в нашем случае 1ГБ.

Создайте новую цель iSCSI и разрешите доступ к ней двум инициаторам, в качестве которых будут выступать узлы кластера.

И сопоставьте данной цели созданные виртуальные диски.

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

Подключенные диски инициализируем и форматируем.

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

После чего откроем Диспетчер Hyper-V и перейдем к настройке виртуальных коммутаторов. Их название на обоих узлах должно полностью совпадать .

Теперь у нас все готово к созданию кластера. Запустим оснастку Диспетчер отказоустойчивых кластеров и выберем действие Проверить конфигурацию .

В настройках мастера добавим настроенные нами узлы и выберем выполнение всех тестов.

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

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

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

При создании кластера для него создается виртуальный объект, обладающий сетевым именем и адресом. Укажем их в открывшемся Мастере создания кластеров .

Больше вопросов не последует и мастер сообщит нам, что кластер создан, выдав при этом предупреждение об отсутствии диска-свидетеля.

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

Затем щелкнем правой кнопкой мыши на объекте кластера в дереве слева и выберем Дополнительные действия - Настроить параметры кворума в кластере .

Далее последовательно выбираем: Выбрать свидетель кворума - Настроить диск-свидетель и указываем созданный для этих целей диск.

Теперь настроим диск хранилища, с ним все гораздо проще, просто щелкаем на диске правой кнопкой и указываем: Добавить в общие хранилища кластера .

Для того, чтобы диск мог использоваться сразу несколькими участниками кластера на нем создается CSVFS - реализуемая поверх NTFS кластерная файловая система, впервые появившаяся в Windows Server 2008 R2 и позволяющая использовать такие функции как Динамическая (Живая) миграция, т.е. передачу виртуальной машины между узлами кластера без остановки ее работы.

Общие хранилища становятся доступны на всех узлах кластера в расположении C:\ClusterStorage\VolumeN . Обратите внимание, что это не просто папки на системном диске, а точки монтирования общих томов кластера.

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

На этом настройка кластера закончена. Для работы с кластеризованными виртуальными машинами следует использовать Диспетчер отказоустойчивости кластеров , а не Диспетчер Hyper-V , который предназначен для управления виртуалками расположенными локально.

Чтобы создать виртуальную машину перейдите в раздел Роли в меню правой кнопки мыши выберите Виртуальные машины - Создать виртуальную машину , это же можно сделать и через панель Действия справа.

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

После выбора узла откроется стандартный Мастер создания виртуальной машины, работа с ним не представляет сложности, поэтому остановимся только на значимых моментах. В качестве расположения виртуальной машины обязательно укажите один из общих томов кластера C:\ClusterStorage\VolumeN .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теги:

Please enable JavaScript to view the
Кластер представляет собой многомашинный компьютерный комплекс, который с точки зрения пользователя: является единой системой;
обеспечивает высокую надежность (готовность к работе); имеет общую файловую структуру с элементами системы; обладает свойством эффективной масштабируемости - роста производительности при добавлении ресурсов; гибко перестраивается; управляется (администрируется) как единая система.
Иногда кластером называют комплекс из двух компьютеров,
один из которых делает полезную работу, а другой включен и находится в горячем резерве (hot standby).
Главные же качества кластеров - высокая готовность и масштабируемость. В отличие от систем с горячим резервированием все компьютеры в кластере не простаивают, а выполняют полезную работу. В результате затраты на дополнительное оборудование являются платой не только за надежность, но и за производительность.
Каждый компьютер в кластере остается относительно независимым. Его можно остановить и выключить для проведения, например, профилактических работ или установки дополнительного оборудования, не нарушая работоспособности кластера в целом. Тесное взаимодействие компьютеров, образующих кластер, часто именуемых узлами кластера, гарантирует максимальную производительность и минимальное время обработки менеджерских приложений.
При работе кластерной системы в составе МИС в случае сбоя программного обеспечения на одном узле приложение продолжает функционировать (либо автоматически перезапускается) на других узлах кластера. Отказ узла (или узлов) кластера по любой причине (включая ошибки персонала) не означает отказа кластера в целом; профилактические и ремонтные работы, реконфигурацию и смену версий программного обеспечения в большинстве случаев можно осуществлять на узлах кластера поочередно, не прерывая работы МИС на других узлах кластера. Простои МИС, которые не в состоянии предотвратить обычные информационные системы, в кластерных МИС выражаются обычно в некотором снижении производительности, если узлы выключаются из работы, поскольку в случае сбоя приложения недоступны только на короткий промежуток времени, необходимый для переключения на другой узел кластера, готовность кластера к работе составляет 99,9% и выше. В больших МИС простои составляют не более 8 ч в год.
Следует отметить, что применение широкодоступных средств повышения структурной аппаратной и программной отказоустойчивости (средства RAID, SMP, UPS и т.д.) вовсе не исключается/>при построении кластеров МИС, что дополнительно повышает их надежность.
Таким образом, в составе МИС кластер - это несколько компьютеров, соединенных коммуникационным каналом и имеющих доступ к разделяемым общекластерным ресурсам, к которым прежде всего относятся дисковые накопители.
Общекластерные дисковые накопители обеспечивают возможность быстрого перезапуска приложений на разных узлах кластера и одновременной работы прикладных программ с одними и теми же данными, получаемыми с разных узлов кластера так, как если бы эти программы находились в оперативной памяти одного компьютера.
Коммуникационный канал кластера обеспечивает: скоординированное (непротиворечивое) использование общекластерных ресурсов; взаимный контроль работоспособности узлов кластера; обмен данными о конфигурации кластера и другой специфической кластерной информацией.
Интенсивность кластерной коммуникации зависит от степени интеграции узлов кластера и характера работающих на нем приложений МИС. В соответствии с этим варьируются и требования к коммуникационному каналу для разных типов кластеров и, следовательно, состав и стоимость дополнительного оборудования, необходимого для объединения обычных компьютеров в кластер. Если на разных узлах кластера выполняются разные или однотипные, но не взаимодействующие друг с другом приложения и нет необходимости в одновременном доступе к одним и тем же дисковым накопителям, то обмен сообщениями сводится к периодической проверке работоспособности и обмену информацией об изменении конфигурации при добавлении в кластер новых узлов, перераспределении дисков. Для такого типа кластерных коммуникаций вполне подходит 10-мегабитный канал типа Ethernet. Ситуация существенно изменяется, когда требуется работа приложений на разных узлах кластера с одними и теми же данными. В этом случае необходимо обеспечивать координацию доступа к разделяемым ресурсам с тем, чтобы программы с разных узлов не пытались, например, одновременно модифицировать один и тот же файл или блок на диске. Обеспечивается эта координация специальным механизмом - так называемым менеджером распределенных блокировок (DLM - Distributed Lock Manager). Использование механизма DLM предполагает весьма интенсивный об
мен сообщениями между узлами и соответственно требует более высокой производительности коммуникационного канала.
В различных кластерах применяется широкий спектр коммуникационных технологий, как стандартных (Ethernet, ATM и др.), так и специализированных (DSSI, Memory Channel), что позволяет выбирать конфигурации, оптимальные по цене и производительности. Для подключения дисковых накопителей в кластерах используется шина SCSI, шина Ultra SCSI с различной пиковой скоростью передачи данных, что обеспечивает минимальную стоимость систем.
Кластер сегодня - это не менее чем два сервера (узла) на базе процессора под управлением операционной системы и одна или несколько дисковых стоек, соединенных с обоими узлами высокопроизводительной общей шиной. Серверы, входящие в кластер, не обязательно должны иметь идентичную конфигурацию. В то же время существует гомогенность - однородность типа процессоров. При установлении кластерного программного обеспечения часто не требуется применения каких-либо нестандартных аппаратных устройств или специальных версий операционных систем.
Кластерная структура сервера организована так, чтобы уберечь развитые информационные и вычислительные комплексы от потери данных в результате сбоев питания, процессора, дисков. Временная неработоспособность компьютерного центра МИС, пусть даже не связанная с потерей данных, может привести к значительным убыткам. Высокая стоимость одного простаивающего сервера, включенного в состав систем резервирования, делает необходимыми кластерные технологии.
Эталонные кластеры обладают следующими свойствами: высокая надежность системных ресурсов. Процессы с отказавшей машины подхватываются и продолжают обрабатываться другими машинами (отработка отказа - failover) с целью обеспечения непрерывной работы пользователей и приложений; эффективная масштабируемость. В кластер могут добавляться дополнительные компьютеры, что является высокоэффективным и экономичным путем повышения производительности информационных систем; уменьшение затрат на обслуживание системы. Кластерная технология позволяет упростить управление большим количеством компьютеров, уменьшить затраты на резервное ко
пирование и репликацию данных, а также предоставить доступ к некоторым периферийным устройствам большему количеству пользователей.
С точки зрения пользователя (клиента), кластер выглядит как единый сервер. Этот сервер имеет свое собственное имя (кластерное имя - cluster alias), с которым и работают пользователи. Более того, они могут даже не знать подлинные имена серверов, составляющих кластер.
В кластерах применяется логика объектов и групп. Объектом в кластере могут являться собственно серверы, кластерные диски, файловые сервисы, кластерные приложения и т.д. Эти объекты объединяются в группы, называемые группами отработки отказа (failover group). В группе содержится информация о том, какой из узлов кластера первичный для данной группы и что нужно делать в случае его сбоя. Для приложения назначаются сценарии отработки отказа (failover script), которые обеспечат его перезапуск. Эти сценарии могут содержать любые дополнительные команды, например команды типа net send, с помощью которых пользователи будут извещены о задержке отклика информационной системы, связанного с устранением отказа.
Для системного менеджера особенно важны кластерные системы, которые использует как сервер баз данных. Вначале на обоих узлах кластера устанавливается соответствующее программное обеспечение, настроенное таким образом, что данные хранятся на диске (или дисках), расположенном в выносной стойке и соответственно доступном обоим узлам кластера. Затем назначается первичный сервер. В нормальной ситуации, когда оба сервера работают, все запросы, связанные с базой данных, будет выполнять первичный сервер. В случае его сбоя (отказ питания, процессора, памяти и т.д.) вторичный сервер автоматически примет на себя выполнение его задач, в частности обработку запросов к базе данных, произойдет отработка отказа (failover). После возвращения первичного сервера «в строй» автоматически произойдет обратный переход (failback) - возвращение первичному серверу его задач. Важным здесь являются два аспекта: внешние клиенты всегда обращаются к кластеру как к единой системе, используя кластерное имя, не совпадающее ни с одним из имен узлов кластера; в нормальной ситуации вторичный сервер не простаивает, ожидая критического момента, а может выполнять свои при
кладные задачи (например, являться первичным для почтового сервера).
Таким образом, разделение первичный-вторичный происходит на уровне задач или групп отработки отказа (failover group), а не на уровне собственно серверов.
Отметим еще раз, что кластерные серверы - это чисто программный продукт, не требующий специальных аппаратных устройств и отвечающий имеющимся стандартам.
Знание возможностей кластерных структур позволяет системному менеджеру осуществлять надежное информационное управление. После нескольких лет молчания, решил поделиться опытом по развертыванию отказоустойчивого кластера на основе Windows Server 2012.
Постановка задачи: Развернуть отказоустойчивый кластер для размещения на нем виртуальных машин, с возможностью выделения виртуальных машин в отдельные виртуальные подсети (VLAN), обеспечить высокую надежность, возможность попеременного обслуживания серверов, обеспечить доступность сервисов. Обеспечить спокойный сон отделу ИТ.

Для выполнения выше поставленной задачи нам удалось выбить себе следующее оборудование:

Сервер HP ProLiant DL 560 Gen8 4x Xeon 8 core 64 GB RAM 2 шт.
SAS Хранилище HP P2000 на 24 2,5» дисков 1 шт.
Диски для хранилища 300 Gb 24 шт. //С объемом не густо, но к сожалению бюджеты такие бюджеты…
Контроллер для подключения SAS производства HP 2 шт.
Сетевой адаптер на 4 1Gb порта 2 шт. //Можно было взять модуль под 4 SFP, но у нас нет оборудования с поддержкой 10 Gb, гигабитного соединения вполне достаточно.

Естественно обновляем BIOS и Firmware с официального сайта.
Организация подключений:

У нас на самом деле подключено в 2 разных коммутатора. Можно подключить в 4 разных. Я считаю, что достаточно 2х.
На портах коммутаторов, куда подключены сервера необходимо сменить режим интерфейса с access на trunk, для возможности разнесения по виртуальным подсетям.

Пока качаются обновления на свежеустановленную Windows Server 2012, настроим дисковое хранилище. Мы планируем развернуть сервер баз данных, посему решили 600 Гб использовать под базы данных, остальное под остальные виртуальные машины, такая вот тавтология.

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

Диск raid10 на основе Raid 1+0 из 4 дисков +1 spare
Диск raid5 на основе Raid 5 из 16 дисков +1 spare
2 диска - ЗИП

Советую в имени диска указывать модель массива, сразу будет понятен функционал.Также HP рекомендует использовать небольшое количество виртуальных дисков, в которых будет большое количество физических, т.е. не стоит плодить кучу мелких виртуальных дисков.

Теперь необходимо создать разделы.

raid5_quorum - Так называемый диск-свидетель (witness). Необходим для организации кластера из 2 нод.
raid5_store - Здесь мы будем хранить виртуальные машины и их жесткие диски
raid10_db - Здесь будет хранится жесткий диск виртуальной машины MS SQL сервера

Назначаем (map) наши разделы на порты sas контроллеров хранилища.
Обязательно необходимо включить feature Microsoft Multipath IO, иначе при сервера к обоим контроллерам хранилища в системе будет 6 дисков, вместо 3х, и кластер не соберется, выдавая ошибку, мол у вас присутствуют диски с одинаковыми серийными номерами, и этот визард будет прав, хочу я вам сказать.

Подключать сервера к хранилищу советую по очереди:

Подключили 1 сервер к 1 контроллеру хранилища
В хранилище появится 1 подключенный хост - дайте ему имя. Советую называть так: имясервера_номер контроллера (A или B)
И так, пока не подключите оба сервера к обоим контроллерам.

На коммутаторах, к которым подключены сервера необходимо создать 3 виртуальных подсети (VLAN):

ClusterNetwork - здесь ходит служебная информаци кластера (хэртбит, регулирование записи на хранилище)
LiveMigration - тут думаю все ясно
Management - сеть для управления

На этом подготовка инфраструктуры закончена. Переходим к настройке серверов и поднятию кластера.

Заводим сервера в домен. Устанавливаем роль Hyper-V, Failover Cluster.
В настройках Multipath IO включаем поддержку SAS устройств.
Обязательно перезагружаем.

Следующие настройки необходимо выполнить на обоих серверах.

Переименуйте все 4 сетевых интерфейса в соответствии их физическим портам (у нас это 1,2,3,4).
Настраиваем NIC Teaming - Добавляем все 4 адаптера в команду, Режим (Teaming-Mode) - Switch Independent, Балансировка нагрузки (Load Balancing) - Hyper-V Port. Даем имя команде, я так и назвал Team.
Теперь необходимо поднять виртуальный коммутатор.
Открываем powershell и пишем:

New-VMSwitch "VSwitch" -MinimumBandwidthMode Weight -NetAdapterName "Team" -AllowManagementOS 0

Создаем 3 виртуальных сетевых адаптера.
В том же powershell:

Add-VMNetworkAdapter –ManagementOS –Name "Management" Add-VMNetworkAdapter –ManagementOS –Name "ClusterNetwork"Add-VMNetworkAdapter –ManagementOS –Name "Live Migration"

Эти виртуальные коммутаторы появятся в центре управления сетями и общим доступом, именно по ним и будет ходить траффик наших серверов.

Настройте адресацию в соответствии с вашими планами.

Переводим наши адапетры в соответствующие VLAN’ы.
В любимом powershell:

Set-VMNetworkAdapterVlan -ManagementOS -Access -VlanId 2 -VMNetworkAdapterName "Management" -Confirm Set-VMNetworkAdapterVlan -ManagementOS -Access -VlanId 3 -VMNetworkAdapterName "ClusterNetwork" -Confirm Set-VMNetworkAdapterVlan -ManagementOS -Access -VlanId 4 -VMNetworkAdapterName "Live Migration" -Confirm

Теперь нужно настроить QoS.

При настройке QoS by weight (по весу), что является best practice, по заявлению Microsoft, советую расставить вес так, чтобы в общей сумме получилось 100, тогда можно считать, что значение указанное в настройке есть гарантированный процент полосы пропускания. В любом случае считается процент по формуле:

Процент полосы пропускания = установленный вес * 100 / сумма всех установленных значений веса

Set-VMSwitch “VSwitch” -DefaultFlowMinimumBandwidthWeight 15

Для служебной информации кластера.

Set-VMNetworkAdapter -ManagementOS -Name “Cluster” -MinimumBandwidthWeight 30

Для управления.

Set-VMNetworkAdapter -ManagementOS -Name "Management" -MinimumBandwidthWeight 5

Для Live Migration.

Set-VMNetworkAdapter -ManagementOS -Name “Live Migration” -MinimumBandwidthWeight 50

Чтобы трафик ходил по сетям верно, необходимо верно расставить метрики.
Трафик служебной информации кластера будет ходит по сети с наименьшей метрикой.По следующей по величине метрики сети будет ходить Live Migration.

Давайте так и сделаем.
В нашем ненаглядном:

$n = Get-ClusterNetwork “ClusterNetwork” $n.Metric = 1000 $n = Get-ClusterNetwork “LiveMigration” $n.Metric = 1050$n = Get-ClusterNetwork “Management” $n.Metric = 1100

Монтируем наш диск-свидетель на ноде, с которой будем собирать кластер, форматируем в ntfs.

В оснастке Failover Clustering в разделе Networks переименуйте сети в соответствии с нашими адаптерами.

Все готово к сбору кластера.

В оснастке Failover Clustering жмем validate. Проходим проверку. После чего создаем кластер (create cluster) и выбираем конфигурацию кворума (quorum configuration) Node and Disk majority, что также считается лучшим выбором для кластеров с четным количеством нод, а учитывая, что у нас их всего две - это единственный выбор.

В разделе Storage оснастки Failover Clustering, добавьте ваши диски. А затем по очереди добавляйте их как Cluster Shared Volume (правый клик по диску). После добавления в папке C:\ClusterStorage появится символическая ссылка на диск, переименуйте ее в соответствии с названием диска, добавленного как Cluster Shared Volume.

Теперь можно создавать виртуальные машины и сохранять их на эти разделы. Надеюсь статья была Вам полезна.

Прошу сообщать об ошибках в ПМ.

Советую к прочтению: Microsoft Windows Server 2012 Полное руководство. Рэнд Моримото, Майкл Ноэл, Гай Ярдени, Омар Драуби, Эндрю Аббейт, Крис Амарис.

P.S.: Отдельное спасибо господину Салахову, Загорскому и Разборнову, которые постыдно были забыты мною при написании данного поста. Каюсь >_< XD