Кластерная система серверов: Серверные кластеры: виды, особенности и преимущества

Серверные кластеры: виды, особенности и преимущества

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

Отказоустойчивый кластер / High-Availability cluster (HA)

Это кластер высокой доступности, в котором при отказе одного сервера его функции перенимают на себя другие машины в кластере. Таким образом, сервисы и приложения продолжают работать без остановки благодаря аппаратной избыточности. Чтобы построить отказоустойчивую структуру, требуется минимум два физических сервера с системами хранения данных. В рамках СХД дисковое пространство распределяется между всеми серверами, а для управления виртуальными машинами используют специальное ПО – гипервизор. Виртуальные машины, запущенные на серверах кластера, работают по следующему принципу: если одна из них выходит из строя, в работу автоматически включается вторая.

Применение: везде, где требуется непрерывная работа бизнес-сервисов и поддержка важных баз данных (банк, биржа, круглосуточное производство), электронные торговые площадки.

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

Кластер с балансировкой нагрузки / Load balancing cluster

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

Применение: ЦОД, комплексы для ERP/CRM-систем, сервисы биллинга в телекоммуникационных системах.

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

Вычислительный кластер / High-Performance Computing cluster

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

Применение: аналитика, сбор и обработка данных для Big Data, системы искусственного интеллекта, нейронные сети.

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

Специалисты компании ITELON имеют необходимый опыт и компетенцию для подбора высокопроизводительного кластерного решения для вашего бизнеса. Они разработают и внедрят отказоустойчивую высокопроизводительную систему, используя оборудование ведущих вендоров и современные технологии виртуализации. Мы рекомендуем использовать серверы HPE ProLiant DL380 Gen10 (2U), Dell PowerEdge R740 (2U), Fujitsu PRIMERGY RX2540 M4, Lenovo System x3650 M5 (2U).

Кластер серверов — что это такое серверный кластер

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

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

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

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

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

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

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

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

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

Смотрите также:

Сервер под «1С» в аренду

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

Кластерные системы / Блог компании Parking.ru / Хабр

Parking.ru как облачный провайдер имеет опыт оказания не только услуг с «обычной» надежностью, но и услуг хостинга высокой доступности, построенных на кластеризованной дублированной инфраструктуре.

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

Parking.ru запустил целый ряд кластерных решений построенных на надежной дублированной инфраструктуре и имеющих в основе самые разные решения: от виртуальных машин до группы физических серверов. Отдельного внимания заслуживает предложение по ГЕО кластеризации в двух разных ЦОД, объединенных дублированными каналами связи.

Если рассматривать вкратце, то в рамках предложения существуют следующие типовые схемы кластеров:

Кластеры высокой доступности (High Availability cluster)

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

Обычно High Availability кластер строится для Microsoft SQL server’ов, который поддерживает базы данных интернет проектов. High Availability кластер возможно построить и для Exchange систем.

Существует ещё одна разновидность High Availability SQL кластера — «зеркалирование БД» или database mirroring. Этот вид кластера не требует выделенного дискового хранилища, но для автоматического переключения в случае аварии нужен ещё один SQL сервер — следящий/witness. Такой кластер идеально подходит для WEB приложений и требует меньше затрат на создание.

Балансировка нагрузки (Network Load Balancing, NLB)

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

При размещении высоконагруженных web-проектов в режиме NLB строится ферма web-серверов на IIS 7.х

Кластеры на виртуальных машинах

Наиболее доступным и масштабируемым решением является построение кластера на основе виртуальных машин на платформе Hyper-V.

В качестве web-боксов NLB-кластера используются виртуальные машины с установленными на них Windows Web Server 2008 (IIS7.х, пользовательское приложение).

В качестве кластера баз данных используется две виртуальные машины необходимой мощности на Windows Server 2008 Standard Edition и SQL Server 2008 Standard Edition.

Отказоустойчивое единое хранилище данных на основе Storage System от NetApp или HP.

Для обеспечения бОльшей надежности все узлы кластера располагаются на различных физических серверах\узлах кластера.

Масштабируемость решения достигается путем увеличения мощности используемых виртуальных машин (вплоть до 100% мощности физического сервера), а также за счет добавления новых узлов в NLB-кластер.

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

Данный кластер является лучшим решением в соотношении цена/качество и рекомендуется как для критичных для бизнеса приложений, так и для относительно нагруженных web-проектов (~до 30000-50000 посетителей ежедневно).

Кластеры на физических серверах

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

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

Геокластеры

При построении локальных кластеров единой точкой отказа системы является сама инфраструктура ЦОД. Parking.ru предлагает уникальное решение на российском рынке — построение географически распределенного кластера, узлы которого располагаются в разных ЦОДах Parking.ru.

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

Про кластер серверов 1С / Блог компании 1С / Хабр

Кластер — это разновидность параллельной
или распределённой системы, которая:
1. состоит из нескольких связанных
между собой компьютеров;
2. используется как единый,
унифицированный компьютерный ресурс

Gregory F. Pfister, «In search of clusters».

Дано: есть бизнес-приложение (например, ERP-система), с которым работают одновременно тысячи (возможно, десятки тысяч) пользователей.

Требуется:

1. Сделать приложение масштабируемым, чтобы при увеличении количества пользователей можно было за счёт наращивания аппаратных ресурсов обеспечить необходимую производительность приложения.
2. Сделать приложение устойчивым к выходу из строя компонентов системы (как программных, так и аппаратных), потере связи между компонентами и другим возможным проблемам.
3. Максимально эффективно задействовать системные ресурсы и обеспечить нужную производительность приложения.
4. Сделать систему простой в развертывании и администрировании.

Чтобы решить эти задачи, мы в платформе 1С:Предприятие используем кластерную архитектуру.

К желаемому результату мы пришли не сразу.

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

Как писал автор эпиграфа к этой статье Грегори Пфистер в своей книге «In search of clusters», кластер был придуман не каким-либо конкретным производителем железа или софта, а клиентами, которым не хватало для работы мощностей одного компьютера или требовалось резервирование. Случилось это, по мнению Пфистера, ещё в 60-х годах прошлого века.
Традиционно различают следующие основные виды кластеров:

1. Отказоустойчивые кластеры (High-availability clusters, HA, кластеры высокой доступности)
2. Кластеры с балансировкой нагрузки (Load balancing clusters, LBC)
3. Вычислительные кластеры (High performance computing clusters, HPC)
4. Системы распределенных вычислений (grid) иногда относят к отдельному типу кластеров, который может состоять из территориально разнесенных серверов с отличающимися операционными системами и аппаратной конфигурацией. В случае grid-вычислений взаимодействия между узлами происходят значительно реже, чем в вычислительных кластерах. В grid-системах могут быть объединены HPC-кластеры, обычные рабочие станции и другие устройства.

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

Для тех, кто не в курсе, коротко расскажу, как устроены бизнес-приложения 1С. Это приложения, написанные на предметно-ориентированном языке, «заточенном» под автоматизацию учётных бизнес-задач. Для выполнения приложений, написанных на этом языке, на компьютере должен быть установлен рантайм платформы 1С:Предприятия.

1С:Предприятие 8.0

Первая версия сервера приложений 1С (еще не кластер) появилась в версии платформы 8.0. До этого 1С работала в клиент-серверном варианте, данные хранились в файловой СУБД или MS SQL, а бизнес-логика работала исключительно на клиенте. В версии же 8.0 был сделан переход на трехзвенную архитектуру «клиент – сервер приложений – СУБД».

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

1С:Предприятие 8.1

В следующей версии мы захотели:

• Обеспечить нашим клиентам отказоустойчивость, чтобы аварии и ошибки у одних пользователей не приводили авариям и ошибкам у других пользователей.
• Избавиться от технологии СОМ+. СОМ+ работала только на Windows, а в то время уже начала становиться актуальной возможность работы под Linux.

При этом мы не хотели разрабатывать новую версию платформы с нуля – это было бы слишком ресурсозатратно. Мы хотели по максимуму использовать наши наработки, а также сохранить совместимость с прикладными приложениями, разработанными для версии 8.0.

Так в версии 8.1 появился первый кластер. Мы реализовали свой протокол удаленного вызова процедур (поверх ТСР), который по внешнему виду выглядел для конечного потребителя-клиента практически как СОМ+ (т.е. нам практически не пришлось переписывать код, отвечающий за клиент-серверные вызовы). При этом сервер, реализованный нами на С++, мы сделали платформенно-независимым, способным работать и на Windows, и на Linux.

На смену монолитному серверу версии 8.0 пришло 3 вида процессов – рабочий процесс, обслуживающий клиентов, и 2 служебных процесса, поддерживающих работу кластера:

• rphost – рабочий процесс, обслуживающий клиентов и исполняющий прикладной код. В составе кластера может быть больше одного рабочего процесса, разные рабочие процессы могут исполняться на разных физических серверах – за счёт этого достигается масштабируемость.
• ragent – процесс агента сервера, запускающий все другие виды процессов, а также ведущий список кластеров, расположенных на данном сервере.
• rmngr – менеджер кластера, управляющий функционированием всего кластера (но при этом на нем не работает прикладной код).

Под катом – схема работы этих трёх процессов в составе кластера.

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

1С:Предприятие 8.2

В версии 8.2 мы захотели, чтобы приложения 1С могли запускаться не только в нативном (исполняемом) клиенте, а ещё и в браузере (без модификации кода приложения). В связи с этим, в частности, встала задача отвязать текущее состояние приложения от текущего соединения с рабочим процессом rphost, сделать его stateless. Как следствие возникло понятие сеанса и сеансовых данных, которые нужно было хранить вне рабочего процесса (потому что stateless). Был разработан сервис сеансовых данных, хранящий и кэширующий сеансовую информацию. Появились и другие сервисы — сервис управляемых транзакционных блокировок, сервис полнотекстового поиска и т.д.

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

Отказоустойчивость

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

Механизм работает так. Если клиентский вызов к рабочему процессу по какой-то причине не смог исполниться до конца, то клиентская часть способна, получив ошибку вызова, этот вызов повторить, переустановив соединение с тем же рабочим процессом или с другим. Но повторять вызов можно не всегда; повтор вызова означает, что мы отправили вызов на сервер, а результата не получили. Мы стараемся повторить вызов, при этом при выполнении повторного вызова мы оцениваем, каков результат на сервере был у предшествующего вызова (информация об этом сохраняется на сервере в данных сеанса), потому что если вызов успел там «наследить» (закрыть транзакцию, сохранить сеансовые данные и т.п.) – то просто так повторять его нельзя, это приведет к рассогласованию данных. Если повторять вызов нельзя, клиент получит сообщение о неисправимой ошибке, и клиентское приложение придется перезапустить. Если же вызов «наследить» не успел (а это наиболее частая ситуация, т.к. многие вызовы не меняют данных, например, отчеты, отображение данных на форме и т.п., а те, которые меняют данные – пока транзакция не зафиксирована или пока изменение сеансовых данных не отправлено в менеджер – следов вызов не оставил) — его можно повторить без риска рассогласования данных. Если рабочий процесс упал или произошел обрыв сетевого соединения – такой вызов повторяется, и эта «катастрофа» для клиентского приложения происходит полностью незаметно.

Балансировка нагрузки

Задача балансировки нагрузки в нашем случае звучит так: в систему заходит новый клиент (или уже работающий клиент совершает очередной вызов). Нам надо выбрать, на какой сервер и в какой рабочий процесс направить вызов клиента, чтобы обеспечить клиенту максимальное быстродействие.

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

• Round-Robin (циклический) – серверам присваиваются порядковые номера, первый запрос отправляется на первый сервер, второй запрос – на второй и т. д. до достижения последнего сервера. Следующий запрос направляется на первый сервер и всё начинается с начала. Алгоритм прост в реализации, не требует связи между серверами и неплохо подходит для «легковесных» запросов. Но при балансировке по этому алгоритму не учитывается производительность серверов (которая может быть разной) и текущая загруженность серверов.
• Weighted Round Robin – усовершенствованный Round-Robin: каждому серверу присваивается весовой коэффициент в соответствии с его производительностью, и сервера с бо́льшим весом обрабатывают больше запросов.
• Least Connections: новый запрос передается на сервер, обрабатывающий в данный момент наименьшее количество запросов.
• Least Response Time: сервер выбирается на основе времени его ответа: новый запрос отдаётся серверу, ответившему быстрее других серверов.

Для нашего кластера мы выбрали алгоритм, близкий по сути к Least Response Time. У нас есть механизм, собирающий статистику производительности рабочих процессов на всех серверах кластера. Он делает эталонный вызов каждого процесса сервера в кластере; эталонный вызов задействует некоторое подмножество функций дисковой подсистемы, памяти, процессора, и оценивает, насколько быстро выполняется такой вызов. Результат этих измерений, усредненный за последние 10 минут, является критерием — какой сервер в кластере является наиболее производительным и предпочтительным для отправки к нему клиентских соединений в данный период времени. Запросы клиентов распределяются таким образом, чтобы получше нагрузить наиболее производительный сервер – грузят того, кто везет.

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

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

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

1. Процесса больше нет: рабочий процесс, с которым ранее взаимодействовал клиент, более недоступен (упал процесс, стал недоступен сервер и т.п.).
2. Есть более производительный сервер: если в кластере есть сервер, отличающийся по производительности в два и более раза по сравнению с сервером, где запушен текущий рабочий процесс, то платформа считает, что даже ценой миграции клиентского контекста нам выгоднее выполнять запросы на более производительном сервере. Переноситься клиенты с одного сервера на другой будут постепенно, по одному, с периодической оценкой результата – что в плане производительности стало с серверами после переноса каждого из клиентских процессов. Цель этой процедуры – выравнивание производительности серверов в кластере (т.е. равномерная загрузка серверов).

Резервирование кластеров

Мы решили повысить отказоустойчивость кластера, прибегнув к схеме Active / passive. Появилась возможность конфигурировать два кластера – рабочий и резервный. В случае недоступности основного кластера (сетевые неполадки или, например, плановое техобслуживание) клиентские вызовы перенаправлялись на резервный кластер.

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

1С:Предприятие 8.3

В версии 8.3 мы существенно переписали код серверной части, отвечающий за отказоустойчивость. Мы решили отказаться от схемы Active / passive кластеров ввиду сложности её конфигурирования. В системе остался только один отказоустойчивый кластер, состоящий из любого количества серверов – это ближе к схеме на Active / active, в которой запросы на отказавший узел распределяются между оставшимися рабочими узлами. За счет этого кластер стал проще в настройке. Ряд операций, повышающих отказоустойчивость и улучшающих балансировку нагрузки, стали автоматизированными. Из важных нововведений:

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

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

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

Как известно, даже если компоненты системы по отдельности надёжны, проблемы могут возникнуть там, где компоненты системы вызывают друг друга. Мы хотели свести количество мест, критичных для работоспособности системы, к минимуму. Важным дополнительным соображением была минимизация переделок прикладных механизмов в платформе и исключение изменений в прикладных решениях. В версии 8.3 появилось 3 звена обеспечения отказоустойчивости «на стыках»:

1. Связь между клиентом, работающим по HTTP(S), и веб-сервером. В случае веб-клиента этот механизм стандартно реализуется веб-технологиями. В случае тонкого клиента, работающего по HTTP с веб-сервером, или мобильного клиента (мобильный клиент всегда работает по HTTP) мы используем библиотеку libcurl с открытым исходным кодом.
2. Отслеживание разрывов соединений, механизм балансировки нагрузки и механизм повторов вызовов позволяют как можно раньше узнать о возникшей проблеме и предпринять действия по её устранению.
3. Связь между ТСР-клиентом и рабочим процессом. Клиентом ТСР может выступать либо клиент 1С, либо расширение веб-сервера при работе клиента через НТТР. При выполнении каждого НТТР-вызова происходит выбор наиболее подходящего соединения с рабочим процессом и отправка этого вызова. Наиболее подходящее соединение выбирается исходя из того, в какой рабочий процесс отправлялся предыдущий вызов данного клиента. Если следующий вызов клиента можно отправить в тот же рабочий процесс, куда ушел предыдущий вызов – мы так и поступаем. Только если по какой-то причине в данный рабочий процесс вызов отправить нельзя (потому, что рабочий процесс стал недоступен, либо мы знаем, что есть другой рабочий процесс с существенно лучшей производительностью) – мы отправляем новый клиентский вызов в более подходящий рабочий процесс.
4. Связь между рабочими процессами сервисами кластера, реализованными в процессах rmngr. Сервисов кластера около 20 (в зависимости от версии платформы) — сервис сеансовых данных, сервис транзакционных блокировок и т.д. На этом уровне существенную роль играют механизм распределения сервисов по серверам и репликация данных сервисов кластера. Балансировка нагрузки на уровне 1С:Предприятия позволяет получать приблизительно одинаковую лучшую производительность от всех рабочих серверов.

В заключение

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

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

Надежность кластера серверов 1С в версии 8.3 существенно повысилась. Уже давно не редкость внедрения продуктов 1С, где количество одновременно работающих пользователей достигает нескольких тысяч. Есть и внедрения, где одновременно работают и 5 000, и 10 000 пользователей — например, внедрение в «Билайне», где приложение «1С: Управление Торговлей» обслуживает все салоны продаж «Билайн» в России, или внедрение в грузоперевозчике «Деловые Линии», где приложение, самостоятельно созданное разработчиками ИТ-отдела «Деловых Линий» на платформе 1С:Предприятие, обслуживает полный цикл грузоперевозок. Наши внутренние нагрузочные тесты кластера эмулируют одновременную работу до 20 000 пользователей.

В заключение хочется кратко перечислить что ещё полезного есть в нашем кластере (список неполный):

• Настройки безопасности, ограничивающие прикладному решению потенциально опасные для функционирования кластера операции. Например, можно ограничить доступ к файловой системе сервера или запретить прикладному решению запускать приложения, установленные на сервере.
• Требования назначения функциональности – механизм, позволяющий администратору указать, какие сервисы кластера, прикладные решения (или даже отдельные функции прикладных решений – отчёты, фоновые и регламентные задания и т.д.) должны работать на каждом из серверов. Например, если заранее известно, что с конкретным прикладным решением (например, бухгалтерией) будет работать существенно меньше пользователей, чем с ERP, возможно, имеет смысл настроить более мощный сервер на работу исключительно с ERP.
• Управление потреблением ресурсов – механизм, отслеживающий потребление кластером ресурсов (память, процессорное время, вызовы СУБД и т.д.). Он позволяет, в частности, выставлять пользователям квоты ресурсов, которые они не могут превысить, и прерывать операции, выполнение которых влияет на производительность сервера в целом.

Кластер серверов — Национальная библиотека им. Н. Э. Баумана

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 13:52, 31 января 2019.

Кластер серверов – группа серверов, объединённых высокоскоростными каналами связи, представляющая с точки зрения пользователя единый аппаратный ресурс. Кластер — слабо связанная совокупность нескольких вычислительных систем, работающих совместно для выполнения общих приложений, и представляющихся пользователю единой системой. Один из первых архитекторов кластерной технологии Грегори Пфистер дал кластеру следующее определение: «Кластер – это разновидность параллельной или распределённой системы, которая:

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

Возможности

Возможностями при использовании кластерами серверов являются:

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

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

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

Модели формирования

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

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

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

Виды

Различают следующие основные виды кластеров:

• отказоустойчивые кластеры (High-availability clusters, HA, кластеры высокой доступности)
• кластеры с балансировкой нагрузки (Load balancing clusters)
• вычислительные кластеры (High performance computing clusters, HPC)
• системы распределенных вычислений

Отказоустойчивые кластеры

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

Такие требования к надежности и отказоустойчивости кластерных систем обусловлены спецификой их использования. Приведем небольшой пример. Кластер обслуживает систему электронных платежей, поэтому если клиент в какой-то момент останется без обслуживания для компании-оператора, это ему будет дорого стоить. Другими словами, система должна работать в непрерывном режиме 24 часа в сутки и семь дней в неделю (7Ѕ24). При этом отказоустойчивости в 99% явно не достаточно, так как это означает, что почти четыре дня в году информационная система предприятия или оператора будет неработоспособной.

Это может показаться не таким уж и большим сроком, учитывая профилактические работы и техническое обслуживание системы. Но сегодняшнему клиенту абсолютно безразличны причины, по которым система не работает. Ему нужны услуги. Итак, приемлемой цифрой для отказоустойчивости становится 99,999%, что эквивалентно 5 минутам в год. Таких показателей позволяет достичь сама архитектура кластера. Приведем пример серверного кластера: каждый сервер в кластере остается относительно независимым, то есть его можно остановить и выключить (например, для проведения профилактических работ или установки дополнительного оборудования), не нарушая работоспособность кластера в целом. Тесное взаимодействие серверов, образующих кластер (узлов кластера), гарантирует максимальную производительность и минимальное время простоя приложений за счет того, что:

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

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

Масштабируемость

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

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

В качестве варианта горизонтального масштабирования стоит также отметить использование группы компьютеров, соединенных через коммутатор, распределяющий нагрузку (технология Load Balancing). Здесь стоит отметить невысокую стоимость такого решения, в основном слагаемую из цены коммутатора (6 тыс. долл. и выше – в зависимости от функционального оснащения) и хост-адаптер (порядка нескольких сот долларов за каждый; хотя, конечно, можно использовать и обыкновенные сетевые карты). Такие решения находят основное применение на Web-узлах с высоким трафиком, где один сервер не справляется с обработкой всех поступающих запросов. Возможность распределения нагрузки между серверными узлами такой системы позволяет создавать на многих серверах единый Web-узел.

Вычислительные кластеры

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

Проект Beowulf появился в 1994 году – возникла идея создавать параллельные вычислительные системы (кластеры) из общедоступных компьютеров на базе Intel и недорогих Ethernet-сетей, устанавливая на эти компьютеры Linux и одну из бесплатно распространяемых коммуникационных библиотек (PVM, а затем MPI). Оказалось, что на многих классах задач и при достаточном числе узлов такие системы дают производительность, сравнимую с суперкомпьютерной. Как показывает практика, построить такую систему довольно просто. Все, что для этого нужно, это высокопроизводительный коммутатор и несколько подсоединенных к нему рабочих станций (серверов) с установленной операционной системой Linux. Однако этого недостаточно. Для того чтобы эта груда железа ожила, необходимо специальное программное обеспечение для параллельных вычислений. Наиболее распространенным интерфейсом параллельного программирования в модели передачи сообщений является MPI (Message Passing Interface).

Название «Интерфейс передачи сообщений» говорит само за себя. Это хорошо стандартизованный механизм для построения параллельных программ в модели обмена сообщениями. Существуют бесплатные и коммерческие реализации почти для всех суперкомпьютерных платформ, а также для сетей рабочих станций UNIX и Windows NT. В настоящее время MPI – наиболее широко используемый и динамично развивающийся интерфейс своего класса. Рекомендуемая бесплатная реализация MPI – пакет MPICH, разработанный в Аргоннской Национальной Лаборатории. Стандартизацией MPI занимается MPI Forum. Последняя версия стандарта – 2.0. В этой версии к MPI добавлены такие важные функции, как динамическое управление процессами, односторонние коммуникации (Put/Get), параллельный ввод-вывод.

Постоянный спрос на высокие вычислительные мощности обусловил появление привлекательного для многих производителей рынка. Некоторые из них разработали собственные технологии соединения компьютеров в кластер. Наиболее известные из них – Myrinet производства MyriCom и cLAN фирмы Giganet. Myrinet является открытым стандартом. Для его реализации MyriCom предлагает широкий выбор сетевого оборудования по сравнительно невысоким ценам. На физическом уровне поддерживаются сетевые среды SAN (System Area Network), LAN (CL-2) и оптоволокно.

Технология Myrinet дает высокие возможности масштабирования сети и в настоящее время очень широко используется при построении высокопроизводительных кластеров. Giganet занимается разработкой программных и аппаратных средств для непосредственного взаимодействия центральных процессорных устройств серверов кластера на гигабитных скоростях, минуя функции ОС. Стоимость решения составляет: около 2500 долл. – за 8-портовый коммутатор, 150 долл. – за адаптер для Myrinet, около 6250 долл. – за 8-портовый коммутатор и 800 долл. – за адаптер для Giganet. Последняя, кстати, получила на выставке Microsoft Tech Ed 2000 премию «Best of Show». В качестве примера приведем реализацию Beowulf-кластера в Институте высокопроизводительных вычислений и баз данных Министерства науки и технической политики РФ.

Кластер, получивший название «ПАРИТЕТ», создан на базе общедоступных комплектующих для персональных компьютеров и рабочих станций и обеспечивает суммарную пиковую производительность 3,2 GFLOP/sec. Кластер состоит из четырех двухпроцессорных вычислительных узлов, на базе процессоров Intel Pentium II/450MHz. На каждом узле установлена оперативная память объемом 512 Мбайт и 10-гигабайтный жесткий диск на интерфейсе Ultra Wide SCSI. Вычислительные узлы кластера объединены высокопроизводительным коммутатором Myrinet (каналы с пропускной способностью 1,28 Гбайт/с, полный дуплекс). Имеется также резервная сеть, используемая для управления и конфигурирования (100 Mbit Fast Ethernet). На узлах вычислительного кластера установлена операционная система Linux (дистрибутив Red Hat 5,2). Для программирования параллельных приложений используются интерфейсы передачи сообщений MPI/PVM.^{[Источник 2]}

Источники

Кластеризация серверов (кластерный сервер), кластерные системы решения, задача кластеризации и отказоустойчивый кластер создание объединение из двух или из нескольких серверов подбор под задачи по параметрам,выбор серверного оборудования под задачи по параметрам ит решений, расчет конфигурации серверного оборудования конфигуратор сервера Lenovo ThinkServer

 

 

	Подбор серверного оборудования по параметрам (lenovo, ibm, dell) и под различные требования. С помощью опросной формы по пунктам выберите под какие задачи планируется покупка сервера. После отправки запроса наши специалисты бесплатно подберут конфигурацию по Вашим параметрам из наличия и со стоимостью, или выберите сами в конфигураторе серверов с ценами Lenovo или Dell Произведем оптимальный подбор конфигурации сервера и схд по выбранным параметрам. Подбор серверного оборудования по параметрам (lenovo, ibm, dell) и под различные требования. С помощью опросной формы по пунктам выберите под какие задачи планируется покупка сервера. После выбора и отправки запроса наши специалисты бесплатно предложат соответствующий выбору вариант конфигурации сервера по выбранным параметрам, наличие и стоимость комплектации. После выбора и отправки запроса в течении 1-2 часов наши специалисты бесплатно предложат соответствующие выбору варианты конфигураций по Вашими параметрам, цену и наличие. Все модели серверов Lenovo, конфигурации серверов типовые и базовые до индивидуальных для 1с, терминалов , баз данных, для vds, web сервера, sql сервера, видеосервера, выделенного сервера, для игрового сервера. Корпорaтивный сервер 1u 2u серверные платформы купить. Виртуализация серверов на базе Lenovo, клaстер сервера подбор и консолидация серверов с помощью сотрудников нашей компании. Кaкой сервер купить? как собрать сервер? как выбрать сервер? как подобрать сервер? Обращайтесь подберем оптимальную конфигурацию с учетом Вашего бюджета .Совместиое програмное обепечение с Lenovo : Oracle Database 11g Enterprise Linux 7 Server LINUX Enterprise Server 11 Multipoint Server 1С-Битрикс Adobe Media Server 5 Citrix XenServer Hyper-v server 2008 R2 Microsoft Core Infrastructure Server  Microsoft Exchange Server Microsoft Lync Server Microsoft SQL Server Microsoft System Center  NeoKylin Novell SLES Novell Storage Manager PROMT Translation Server Red Hat® SolarWinds SUSE® VMware ESXi 5.1 U1 VMware ESXi 5.5 VMware Horizon VMware vCenter Server 5 VMware vCloud VMware vSphere VMware vSphere 5 Enterprise Windows Server® 2008 R2 Windows Server® 2012 R2 Standard

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

Кластерные хранения использование двух или более хранилищ серверов работают вместе, чтобы увеличить производительность, мощность и надежность. Кластеризация распределяет работу нагрузки на каждый сервер, управляет передачей нагрузки между серверами, а также обеспечивает доступ ко всем файлам из любого сервера, независимо от физическое расположение файла. Существуют основные кластерные хранения архитектуры , тесно связаны между собой ; Связанный кластер имеет собственную физическую объединительную панель , в которой контроллер и узлы подключения. Хотя это объединительная плата фиксирует максимальный размер кластера, она обеспечивает высокую производительность интерконнекта между серверами для балансировки нагрузки и максимальной производительности масштабируемости , как кластер растет. Дополнительные массивы контроллеров, I / O (вход / выход) порты , а мощность можно подключить в кластере по мере спроса. Связанный кластер предлагает рентабельные строительные блоки, которые могут начать с малого и расти по мере спроса. Свободный кластер предлагает производительность ввода-вывода, и способность / хранения в пределах одного узла. В результате получаем производительность и масштабируется мощность . Хотя кластеры могут стать довольно большим , масштабируемость ограничивается в исполнении присоединении и в результате обмена в связи с кластером контроллеров. Эксперты называют несколько тенденций, которые начали вводить движение для кластерного хранения в последние годы, в том числе общего сдвига в кластерных вычислений, увеличению имеющихся и низкой стоимости, высокой скорости решений для хранения данных, и взрывного роста в размерах цифрового контента, требующего хранения. Кластеризация серверов (кластерный сервер) купить, кластерные системы решения, задача кластеризации и отказоустойчивый кластер создание объединение из двух или из нескольких серверов подбор под задачи по параметрам,выбор серверного оборудования под задачи по параметрам ит решений, расчет конфигурации серверного оборудования конфигуратор сервера Lenovo ThinkServer

кластеризация данных

задача кластеризации

кластеризация серверов

кластер кластеризация

система кластеризации

кластеризация sql

кластерный сервер

кластерные системы

кластерные вычислительные системы

кластерная файловая система

кластерные решения

Тип корпуса сервера

Оптический привод

Операционная система

Оперативная память

Модуль удаленного управления сервером

Выберите тип и количество процессоров

Выберите предпочитаемого производителя сервера

Выберите нужную конфигурацию сетевых портов

Выберите нужную конфигурацию жестких дисков

Выберите вариант подбора

подбор Блок питания

подбор Raid контроллер

Кластер серверов 1С. Построение высоконагруженных систем 1С

В данной статье будут рассмотрены несколько вариантов структуры 1С для высоконагруженных систем (от 200 активных пользователей), построенных на базе клиент-серверной архитектуры – их преимущества и недостатки, стоимость инсталляции и сравнительные тесты производительности каждого варианта.

Мы не будем проводить описание, оценку и сравнение общепринятых и всем давно известных классических схем построения серверной структуры 1С, таких как отдельный сервер 1С и отдельный сервер СУБД, либо кластер Microsoft SQL с кластером 1С. Таких обзоров великое множество, в том числе и проведенных самими производителями программных продуктов. Мы предложим обзор схем построения структуры 1С, которые встречались за последние несколько лет в наших ИТ-проектах для среднего и крупного бизнеса.

Требования к высоконагру­женным системам 1С

Высоконагруженные системы 1С, работающие с крупными массивами данных в режиме 24/7/365 подвержены факторам риска, которые в стандартных ситуациях обычно не наблюдаются. Как следствие, для их устранения и упреждения требуется применение особенных схем архитектуры 1С и новых технологий.

Катастрофоустойчивость СУБД. В процессе проектирования архитектуры 1С делается упор на вычислительные мощности и высокую доступность сервисов, выраженную в их кластеризации. Серверы 1С:Предприятие по умолчанию способны работать в дублирующем кластере, а для кластера СУБД обычно применяется промышленная система хранения данных (СХД) и технология кластеризации (к примеру, Microsoft SQL Cluster). Однако, ситуация становится плачевной, когда проблемы случаются с самой СХД (зачастую, по нашему опыту последних лет – это проблемы программного характера). Тогда у ИТ-инженера резко возникают две проблемы – где взять актуальные данные и куда их развернуть в кратчайшие сроки, поскольку система хранения данных с нужным объемом быстрого массива дисков недоступна.

Требования к безопасности базы данных. Работая с проектами среднего и крупного бизнеса, мы регулярно сталкиваемся с требованиями по защите персональных данных (в частности, для выполнения пунктов ФЗ-152). Одним из условий выполнения этих требований является обеспечение должной сохранности персональных данных, что требует шифрования базы данных 1С.

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

Схемы организации кластеров серверов 1С

Схема с кластером 1С-серверов, подсоединенным к кластеру с синхронной репликацией SQL AlwaysOn по протоколу IP.

Данная схема является одним из качественных вариантов решения проблемы катастрофоустойчивости базы данных 1С (см. Рисунок 1). Технология кластеризации баз SQL AlwaysOn основана на принципе онлайн-синхронизации таблиц SQL между основным и резервным серверами без вмешательства конечного пользователя. С помощью SQL Listener есть возможность переключиться на резервный сервер SQL в случае выхода из строя основного, что позволяет назвать данную систему полноценным катастрофоустойчивым кластером SQL, благодаря использованию двух независимых серверов SQL. Технология SQL Always On доступна только в версии Microsoft SQL Enterprise.

Рисунок 1 — схема кластера серверов 1С + SQL AlwaysOn

Вторая схема идентична первой, добавлено только шифрование баз SQL на основном и резервном сервере.

Мы уже упоминали о том, что работа с последними ИТ-проектами показала, что компании начали гораздо больше внимания уделять вопросу безопасности данных, по различным причинам – требования ФЗ-152, рейдерские захваты серверов, утечка данных в облаке и тому подобное. Так что считаем данный вариант схемы 1С довольно актуальным (см. Рисунок 2).

Рисунок 2 — схема кластера серверов 1С + SQL AlwaysOn с шифрованием

Кластер серверов 1С «active-active», подсоединенный к единственному серверу СУБД по протоколу IP.

В противовес потребностям в отказоустойчивости и безопасности – некоторым структурам в первую очередь требуется повышенная производительность, так сказать «вся вычислительная мощь». Поэтому максимальный приоритет отдается увеличению количества вычислительных кластеров сервера 1С, на которые современная платформа 1С позволяет дифференцировать различные типы вычислений и фоновые задания (см. Рисунок 3). Конечно же, комплектация основных ресурсов сервера SQL тоже должна быть на уровне, однако сам сервер баз данных представлен в единственном числе (видимо, расчет идет на своевременное резервное копирование баз).

Рисунок 3 — схема кластера серверов 1С с одним сервером СУБД

Сервер 1С и СУБД на одном аппаратном сервере с SharedMemory.

Поскольку наши практические тесты ориентированы на сравнение производительности разных схем, то обязательно требуется некий эталон для сравнения нескольких вариантов (см. Рисунок 4). В качестве эталона, по нашему мнению, нужно взять схему расположения сервера 1С и СУБД на одном аппаратном сервере без виртуализации с взаимодействием по SharedMemory.

Рисунок 4 — схема сервера 1С и СУБД на одном аппаратном сервере с SharedMemory

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

Таблица 1 — сравнение вариантов построения систем 1С

Критерии оценки архитектур 1С	Кластер 1С + SQL AlwaysOn	Кластер 1С + SQL AlwaysOn с шифрованием	Кластер 1С с одним сервером СУБД	Классический 1С+СУБД SharedMemory
Легкость инсталляции и обслуживания	Удовл.	Удовл.	Хорошо	Отлично
Отказоустойчивость	Отлично	Отлично	Удовл.	Не применимо
Безопасность	Удовл.	Отлично	Удовл.	Удовл.
Бюджетность	Удовл.	Удовл.	Хорошо	Отлично

Как видим, остается один важный критерий, значение которого предстоит выяснить – это производительность. Для этого мы проведем серию практических тестов на выделенном тестовом стенде.

Описание методики тестирования

Этап тестирования состоит из двух ключевых инструментов синтетической генерации нагрузки и имитации работы пользователей в 1С. Это тест Гилева (TPC-1C) и «Тест центр» из инструментария 1С: КИП.

Тест Гилева. Тест относится к разделу универсальных интегральных кроссплатформенных тестов. Он может применяться как для файлового, так и для клиент-серверного вариантов 1С:Предприятие. Тест оценивает количество работы в единицу времени в одном потоке и подходит для оценки скорости работы однопоточных нагрузок, включая скорость отрисовки интерфейса, влияния ресурсных затрат на обслуживание виртуальной среды, перепроведения документов, закрытия месяца, расчета зарплаты и т.п. Универсальность позволяет делать обобщенную оценку производительности не привязываясь к конкретной типовой конфигурации платформы. Результатом теста является сводная оценка измеряемой системы 1С, выраженная в условных единицах.

Специализированный «Тест центр» из инструментария 1С: КИП. Тест-центр – инструмент автоматизации многопользовательских нагрузочных испытаний информационных систем на платформе 1С:Предприятие 8. С его помощью можно моделировать работу предприятия без участия реальных пользователей, что позволяет оценивать применимость, производительность и масштабируемость информационной системы в реальных условиях. Используя инструментарий 1С: КИП, на основании процессов и контрольных примеров формируется матрица «Список Объектов макета базы ERP 2.2» для сценария тестирования производительности. В макете базы 1С: ERP 2.2 генерируются обработкой данные по Нормативно-справочной информации (НСИ):

• Несколько тысяч номенклатурных позиций;
• Несколько организаций;
• Несколько тысяч контрагентов.

Тест осуществляется в рамках нескольких групп пользователей. Группа состоит из 4 пользователей, у каждого из которых есть своя роль и перечень последовательных операций. Благодаря гибкому механизму задания параметров для тестирования, можно запускать тест на разное количество пользователей, что позволит оценить поведение системы при различных нагрузках и определить параметры, которые могут привести к снижению показателей производительности. Проводится 3 теста по 3 итерации в которых разработчик 1С запускает тест с эмуляцией работы пользователей и замеряет время выполнения каждой операции. Выполняются замеры всех трех итераций для каждой из схем структуры 1С. Результатом теста является получение среднего времени выполнения операции для каждого документа матрицы.

Показатели «Тест центра» и теста Гилева будут отражены в сводной таблице 2.

Тестовый стенд

1

Сервер терминального доступа – виртуальная машина, использовалась для управления инструментами тестирования:

• vCPU — 16 ядер 2.6GHz
• RAM — 32 ГБ
• I\o: Intel Sata SSD Raid1

2

Сервер 1С и СУБД — физический сервер:

• CPU — Intel Xeon Processor E5-2670 8C 2.6GHz – 2 шт
• RAM — 96 ГБ
• I\o: Intel Sata SSD Raid1
• Роли: Сервер 1С 8.3.8.2137, Сервер MS SQL 2014 SP 2

3

Сервер 1С и СУБД — физический сервер:

• CPU — Intel Xeon Processor E5-2670 8C 2.6GHz – 2 шт
• RAM — 96 ГБ
• I\o: Intel Sata SSD Raid1
• Роли: Сервер 1С 8.3.8.2137, Сервер MS SQL 2014 SP 2

Выводы

Можем сделать вывод, что по среднему времени выполнения операции наиболее оптимальной является схема №3 «Кластер серверов 1С «active-active», подсоединенный к единственному серверу СУБД по протоколу IP» (см. Таблица 2). Для обеспечения отказоустойчивости такой архитектуры мы рекомендуем строить классический отказоустойчивый кластер MSSQL с размещением базы данных на отдельной СХД.

Важно отметить, что наиболее оптимальное соотношение факторов минимизации простоя, отказоустойчивости и сохранности данных — у схемы №1 «Кластер 1С-серверов, подсоединенный к кластеру с синхронной репликацией SQL AlwaysOn по протоколу IP», при этом падение производительности по отношению к самому производительному варианту составляет примерно 10%.

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

На базе облака EFSOL мы предлагаем нашим клиентам кластер серверов 1С в аренду. Это позволяет существенно сэкономить средства на построение собственной отказоустойчивой архитектуры для работы с 1С.

Таблица 2 — Итоговая таблица (сокращенный вариант) практических испытаний разных вариантов построения систем 1С

Схема архитектуры 1С	Среднее время выполнения операции, сек			Средний процент отклоне­ния от эталона	Тест Гилева, усл. ед.
	50 пользова­телей	100 пользова­телей	150 пользова­телей
Схема структуры №1 «Кластер 1С-серверов, подсоединенный к кластеру с синхронной репликацией SQL AlwaysOn по протоколу IP»	0,42245	0,44433	0,4391	На 14%	25,13
Схема структуры №2 «Кластер 1С-серверов, подсоединенный к кластеру с синхронной репликацией SQL AlwaysOn по протоколу IP с шифрованием»	0,435505	0,425227	0,425909	На 12%	21,65
Схема структуры №3 «Кластер серверов 1С «active-active», подсоединенный к единственному серверу СУБД по протоколу IP.»	0,40901	0,41368	0,42852	На 9%	28,09
Эталон. Схема структуры №4 «Расположение сервера 1С и СУБД на одном аппаратном сервере без виртуализации с взаимодействием по SharedMemory»	0,36020	0,42385	0,36335	—	34,23

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

• 27.03.2018
• 15 минут на чтение

В этой статье

Применимо к: Windows Server 2019, Windows Server 2016

Последовательное обновление ОС кластера

позволяет администратору обновлять операционную систему узлов кластера, не останавливая рабочие нагрузки Hyper-V или масштабируемого файлового сервера.Используя эту функцию, можно избежать штрафов за простой в соответствии с соглашениями об уровне обслуживания (SLA).

Последовательное обновление ОС кластера

дает следующие преимущества:

• Отказоустойчивые кластеры с рабочими нагрузками виртуальной машины Hyper-V и масштабируемого файлового сервера (SOFS) могут быть обновлены с Windows Server 2012 R2 (работает на всех узлах кластера) до Windows Server 2016 (работает на всех узлах кластера кластера) ) без простоев. Другие рабочие нагрузки кластера, такие как SQL Server, будут недоступны в течение времени (обычно менее пяти минут), необходимого для переключения на Windows Server 2016.

• Не требует дополнительного оборудования. Тем не менее, вы можете временно добавить дополнительные узлы кластера в небольшие кластеры, чтобы повысить доступность кластера в процессе последовательного обновления ОС кластера.

• Кластер не нужно останавливать или перезапускать.

• Новый кластер не требуется. Существующий кластер модернизируется. Кроме того, используются существующие объекты кластера, хранящиеся в Active Directory.

• Процесс обновления является обратимым до тех пор, пока клиент не выберет «точку невозврата», когда все узлы кластера работают под управлением Windows Server 2016 и когда будет запущен командлет PowerShell Update-ClusterFunctionalLevel.

• Кластер может поддерживать операции исправления и обслуживания при работе в режиме смешанной ОС.

• Он поддерживает автоматизацию через PowerShell и WMI.

• Открытое свойство кластера Свойство ClusterFunctionalLevel указывает состояние кластера на узлах кластера Windows Server 2016. Это свойство можно запросить с помощью командлета PowerShell с узла кластера Windows Server 2016, который принадлежит отказоустойчивому кластеру:

    Get-Cluster | Выберите ClusterFunctionalLevel
    

  Значение 8 указывает, что кластер работает на функциональном уровне Windows Server 2012 R2.Значение 9 указывает, что кластер работает на функциональном уровне Windows Server 2016.

В этом руководстве описаны различные этапы процесса последовательного обновления кластерной ОС, шаги установки, ограничения функций и часто задаваемые вопросы (FAQ), и оно применимо к следующим сценариям последовательного обновления кластерной ОС в Windows Server 2016:

• Кластеры Hyper-V
• Масштабируемые кластеры файловых серверов

Следующий сценарий не поддерживается в Windows Server 2016:

• Последовательное обновление ОС кластера гостевых кластеров с использованием виртуального жесткого диска (.vhdx файл) как общее хранилище

Последовательное обновление ОС кластера

полностью поддерживается System Center Virtual Machine Manager (SCVMM) 2016. Если вы используете SCVMM 2016, см. Раздел Выполнение последовательного обновления кластера узла Hyper-V до Windows Server 2016 в VMM для получения инструкций по обновлению кластеров. и автоматизация шагов, описанных в этом документе.

Требования

Перед началом последовательного обновления ОС кластера выполните следующие требования:

• Начните с отказоустойчивого кластера под управлением Windows Server (Semi-Annual Channel), Windows Server 2016 или Windows Server 2012 R2.
• Обновление кластера Storage Spaces Direct до Windows Server версии 1709 не поддерживается.
• Если рабочая нагрузка кластера — это виртуальные машины Hyper-V или масштабируемый файловый сервер, можно ожидать обновления с нулевым временем простоя.
• Убедитесь, что узлы Hyper-V имеют процессоры, поддерживающие таблицу адресации второго уровня (SLAT), используя один из следующих методов; — Просмотрите раздел «Совместимы ли вы с SLAT?» WP8 SDK Tip 01 статья, в которой описаны два метода проверки, поддерживает ли ЦП SLAT. — Загрузите Coreinfo v3.31, чтобы определить, поддерживает ли ЦП SLAT.

Переходные состояния кластера во время последовательного обновления ОС кластера

В этом разделе описаны различные переходные состояния кластера Windows Server 2012 R2, который обновляется до Windows Server 2016 с помощью последовательного обновления ОС кластера.

Чтобы рабочие нагрузки кластера продолжали работать во время процесса последовательного обновления ОС кластера, перемещение рабочей нагрузки кластера с узла Windows Server 2012 R2 на узел Windows Server 2016 работает так, как если бы оба узла работали под управлением операционной системы Windows Server 2012 R2.Когда узлы Windows Server 2016 добавляются в кластер, они работают в режиме совместимости с Windows Server 2012 R2. Новый концептуальный режим кластера, называемый «режимом смешанной ОС», позволяет узлам разных версий существовать в одном кластере (см. Рисунок 1).

Рисунок 1. Переходы между состояниями операционной системы кластера

Кластер Windows Server 2012 R2 переходит в режим смешанной ОС при добавлении узла Windows Server 2016 в кластер. Процесс полностью обратим — узлы Windows Server 2016 могут быть удалены из кластера, а узлы Windows Server 2012 R2 могут быть добавлены в кластер в этом режиме.«Точка невозврата» возникает при запуске командлета PowerShell Update-ClusterFunctionalLevel в кластере. Для успешного выполнения этого командлета все узлы должны быть Windows Server 2016, и все узлы должны быть подключены к сети.

Переходные состояния четырехузлового кластера при выполнении последовательного обновления ОС

В этом разделе показаны и описаны четыре различных этапа кластера с общим хранилищем, узлы которого обновлены с Windows Server 2012 R2 до Windows Server 2016.

«Этап 1» — это начальное состояние — мы начинаем с кластера Windows Server 2012 R2.

Рисунок 2: Начальное состояние: отказоустойчивый кластер Windows Server 2012 R2 (этап 1)

На «Этапе 2» два узла были приостановлены, осушены, исключены, переформатированы и установлены с Windows Server 2016.

Рисунок 3: Промежуточное состояние: режим смешанной ОС: отказоустойчивый кластер Windows Server 2012 R2 и Windows Server 2016 (этап 2)

На «Этапе 3» все узлы в кластере были обновлены до Windows Server 2016, и кластер готов к обновлению с помощью командлета PowerShell Update-ClusterFunctionalLevel.

Примечание

На этом этапе процесс можно полностью изменить, и в этот кластер можно добавить узлы Windows Server 2012 R2.

Рисунок 4: Промежуточное состояние: все узлы обновлены до Windows Server 2016, готовы к обновлению — ClusterFunctionalLevel (этап 3)

После запуска командлета Update-ClusterFunctionalLevelcmdlet кластер переходит на «этап 4», где можно использовать новые функции кластера Windows Server 2016.

Рисунок 5: Конечное состояние: отказоустойчивый кластер Windows Server 2016 (этап 4)

Процесс последовательного обновления ОС кластера

В этом разделе описан рабочий процесс для последовательного обновления ОС кластера.

Рисунок 6. Рабочий процесс последовательного обновления ОС кластера

Последовательное обновление ОС кластера

включает следующие шаги:

1. Подготовьте кластер к обновлению операционной системы следующим образом:

   1. Последовательное обновление ОС кластера требует удаления по одному узлу из кластера. Проверьте, достаточно ли у вас мощности в кластере для поддержания HA SLA, когда один из узлов кластера удаляется из кластера для обновления операционной системы.Другими словами, требуется ли вам возможность переключения рабочих нагрузок на другой узел при удалении одного узла из кластера в процессе последовательного обновления ОС кластера? Имеет ли кластер возможность выполнять необходимые рабочие нагрузки при удалении одного узла из кластера для последовательного обновления ОС кластера?

   2. Для рабочих нагрузок Hyper-V убедитесь, что все узлы Windows Server 2016 Hyper-V имеют поддержку ЦП таблицы адресов второго уровня (SLAT). Только машины с поддержкой SLAT могут использовать роль Hyper-V в Windows Server 2016.

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

   4. Убедитесь, что все узлы кластера находятся в оперативном / запущенном / активном состоянии с помощью командлета Get-ClusterNode (см. Рисунок 7).

      Рисунок 7. Определение статуса узла с помощью командлета Get-ClusterNode

   5. Если вы используете кластерные обновления (CAU), проверьте, запущено ли в настоящее время CAU, с помощью пользовательского интерфейса Cluster-Aware Updating UI или командлета Get-CauRun (см. Рисунок 8).Остановите CAU с помощью командлета Disable-CauClusterRole (см. Рис. 9), чтобы предотвратить приостановку и отключение каких-либо узлов CAU в процессе последовательного обновления ОС кластера.

      Рисунок 8: Использование командлета Get-CauRun для определения, запущены ли обновления с учетом кластера в кластере

      Рисунок 9. Отключение роли Cluster Aware Updates с помощью командлета Disable-CauClusterRole

2. Для каждого узла в кластере заполните следующее:

   1. Используя пользовательский интерфейс Cluster Manager, выберите узел и используйте Pause | Опция меню Drain для очистки узла (см. Рисунок 10) или используйте командлет Suspend-ClusterNode (см. Рисунок 11).

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

      Рисунок 11. Удаление ролей из узла с помощью командлета Suspend-ClusterNode

   2. С помощью пользовательского интерфейса диспетчера кластеров Удалите приостановленный узел из кластера или используйте командлет Remove-ClusterNode .

      Рисунок 12. Удаление узла из кластера с помощью командлета Remove-ClusterNode

   3. Переформатируйте системный диск и выполните «чистую установку операционной системы» Windows Server 2016 на узле, используя опцию Custom: Install Windows only (Advanced) installation (See Figure 13) in setup.Exe. Избегайте выбора варианта Обновление: установить Windows и сохранить файлы, настройки и приложения, поскольку последовательное обновление кластерной ОС не поощряет обновление на месте.

      Рисунок 13: Доступные варианты установки для Windows Server 2016

   4. Добавьте узел в соответствующий домен Active Directory.

   5. Добавьте соответствующих пользователей в группу администраторов.

   6. С помощью пользовательского интерфейса диспетчера сервера или командлета PowerShell Install-WindowsFeature установите все необходимые роли сервера, например Hyper-V.

        Установка-WindowsFeature-Имя Hyper-V
        

   7. С помощью пользовательского интерфейса диспетчера сервера или командлета PowerShell Install-WindowsFeature установите компонент отказоустойчивой кластеризации.

        Install-WindowsFeature -Name Failover-Clustering
        

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

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

   10. Если используется брандмауэр Windows, проверьте правильность настроек брандмауэра для кластера.Например, для кластеров с поддержкой кластерного обновления (CAU) может потребоваться настройка межсетевого экрана.

   11. Для рабочих нагрузок Hyper-V используйте пользовательский интерфейс Hyper-V Manger для запуска диалогового окна Virtual Switch Manager (см. Рисунок 14).

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

       Рисунок 14: Диспетчер виртуальных коммутаторов

   12. На узле Windows Server 2016 (не используйте узел Windows Server 2012 R2) используйте диспетчер отказоустойчивого кластера (см. Рисунок 15) для подключения к кластеру.

       Рисунок 15: Добавление узла в кластер с помощью диспетчера отказоустойчивого кластера

   13. Используйте пользовательский интерфейс диспетчера отказоустойчивого кластера или командлет Add-ClusterNode (см. Рисунок 16), чтобы добавить узел в кластер.

       Рисунок 16. Добавление узла в кластер с помощью командлета Add-ClusterNode

       Примечание

       Когда первый узел Windows Server 2016 присоединяется к кластеру, кластер переходит в режим «смешанной ОС», и ресурсы ядра кластера перемещаются на узел Windows Server 2016.Кластер режима «Mixed-OS» — это полнофункциональный кластер, в котором новые узлы работают в режиме совместимости со старыми узлами. Режим «Mixed-OS» — это переходный режим для кластера. Он не предназначен для постоянного использования, и ожидается, что клиенты обновят все узлы своего кластера в течение четырех недель.

   14. После успешного добавления узла Windows Server 2016 в кластер вы можете (необязательно) переместить часть рабочей нагрузки кластера на только что добавленный узел, чтобы перебалансировать рабочую нагрузку в кластере следующим образом:

       Рисунок 17: Перемещение рабочей нагрузки кластера (роль кластерной виртуальной машины) с помощью командлета Move-ClusterVirtualMachineRole

       1. Используйте Live Migration из диспетчера отказоустойчивого кластера для виртуальных машин или командлет Move-ClusterVirtualMachineRole (см. Рисунок 17) для выполнения динамической миграции виртуальных машин.

            Move-ClusterVirtualMachineRole -Name VM1 -Node robhind-host3
            

       2. Используйте Move из диспетчера отказоустойчивого кластера или командлет Move-ClusterGroup для других рабочих нагрузок кластера.

3. Когда каждый узел был обновлен до Windows Server 2016 и добавлен обратно в кластер, или когда любые оставшиеся узлы Windows Server 2012 R2 были исключены, выполните следующие действия:

   Важно

   • После обновления функционального уровня кластера нельзя вернуться к функциональному уровню Windows Server 2012 R2, а узлы Windows Server 2012 R2 нельзя добавить в кластер.
   • До тех пор, пока не будет запущен командлет Update-ClusterFunctionalLevel , процесс полностью обратим, и в этот кластер можно добавить узлы Windows Server 2012 R2, а узлы Windows Server 2016 можно удалить.
   • После запуска командлета Update-ClusterFunctionalLevel станут доступны новые функции.

   1. С помощью пользовательского интерфейса диспетчера отказоустойчивого кластера или командлета Get-ClusterGroup убедитесь, что все роли кластера выполняются в кластере должным образом.В следующем примере Доступное хранилище не используется, вместо него используется CSV, следовательно, Доступное хранилище отображает статус Offline (см. Рисунок 18).

      Рисунок 18: Проверка того, что все группы кластера (роли кластера) работают, с помощью командлета Get-ClusterGroup

   2. Убедитесь, что все узлы кластера находятся в сети и работают, с помощью командлета Get-ClusterNode .

   3. Запустите командлет Update-ClusterFunctionalLevel — ошибки не должны возвращаться (см. Рисунок 19).

      Рисунок 19: Обновление функционального уровня кластера с помощью PowerShell

   4. После запуска командлета Update-ClusterFunctionalLevel становятся доступны новые функции.

4. Windows Server 2016 — возобновление обычных обновлений и резервного копирования кластера:

   1. Если вы ранее запускали CAU, перезапустите его с помощью пользовательского интерфейса CAU или используйте командлет Enable-CauClusterRole (см. Рисунок 20).

      Рисунок 20. Включение роли обновлений с поддержкой кластера с помощью командлета Enable-CauClusterRole

   2. Возобновить операции резервного копирования.

5. Включите и используйте функции Windows Server 2016 на виртуальных машинах Hyper-V.

   1. После обновления кластера до функционального уровня Windows Server 2016 многие рабочие нагрузки, такие как виртуальные машины Hyper-V, получат новые возможности. Список новых возможностей Hyper-V. см. Перенос и обновление виртуальных машин

   2. На каждом узле узла Hyper-V в кластере используйте командлет Get-VMHostSupportedVersion для просмотра версий конфигурации виртуальной машины Hyper-V, которые поддерживаются узлом.

      Рисунок 21: Просмотр версий конфигурации виртуальной машины Hyper-V, поддерживаемых хостом

   3. На каждом узле хоста Hyper-V в кластере версии конфигурации виртуальных машин Hyper-V могут быть обновлены путем планирования короткого периода обслуживания с пользователями, резервного копирования, отключения виртуальных машин и запуска командлета Update-VMVersion (см. Рисунок 22). Это обновит версию виртуальной машины и включит новые функции Hyper-V, устраняя необходимость в будущих обновлениях компонента интеграции (IC) Hyper-V.Этот командлет можно запустить с узла Hyper-V, на котором размещена виртуальная машина, или можно использовать параметр -ComputerName для удаленного обновления версии виртуальной машины. В этом примере мы обновляем версию конфигурации VM1 с 5.0 до 7.0, чтобы воспользоваться преимуществами многих новых функций Hyper-V, связанных с этой версией конфигурации виртуальной машины, таких как производственные контрольные точки (резервные копии, согласованные с приложениями) и двоичный файл конфигурации виртуальной машины.

      Рисунок 22. Обновление версии ВМ с помощью командлета PowerShell Update-VMVersion

6. Пулы хранения можно обновить с помощью командлета PowerShell Update-StoragePool — это оперативная операция.

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

Ограничения / ограничения

• Эта функция работает только для версий Windows Server 2012 R2 — Windows Server 2016. Эта функция не может обновить более ранние версии Windows Server, такие как Windows Server 2008, Windows Server 2008 R2 или Windows Server 2012, до Windows Server 2016.
• Каждый узел Windows Server 2016 следует переформатировать / установить только заново. Тип установки «на месте» или «обновление» не рекомендуется.
• Узел Windows Server 2016 должен использоваться для добавления узлов Windows Server 2016 в кластер.
• При управлении кластером со смешанным режимом ОС всегда выполняйте задачи управления с узла верхнего уровня, на котором работает Windows Server 2016. Узлы Windows Server 2012 R2 нижнего уровня не могут использовать пользовательский интерфейс или инструменты управления для Windows Server 2016.
• Мы рекомендуем клиентам быстро пройти процесс обновления кластера, поскольку некоторые функции кластера не оптимизированы для режима смешанной ОС.
• Избегайте создания или изменения размера хранилища на узлах Windows Server 2016, когда кластер работает в режиме смешанной ОС, из-за возможной несовместимости при переключении с узла Windows Server 2016 на узлы Windows Server 2012 R2 нижнего уровня.

Часто задаваемые вопросы

Как долго отказоустойчивый кластер может работать в режиме смешанной ОС? Мы рекомендуем клиентам завершить обновление в течение четырех недель. В Windows Server 2016 много оптимизаций.Мы успешно обновили кластеры Hyper-V и масштабируемого файлового сервера с нулевым временем простоя менее чем за четыре часа.

Будете ли вы переносить эту функцию обратно на Windows Server 2012, Windows Server 2008 R2 или Windows Server 2008? Мы не планируем переносить эту функцию обратно в предыдущие версии. Последовательное обновление кластерной ОС — это наше видение обновления кластеров Windows Server 2012 R2 до Windows Server 2016 и последующих версий.

Должен ли кластер Windows Server 2012 R2 иметь все обновления программного обеспечения перед запуском процесса последовательного обновления ОС кластера? Да, перед запуском процесса последовательного обновления ОС кластера убедитесь, что все узлы кластера обновлены последними обновлениями программного обеспечения.

Можно ли запустить командлет Update-ClusterFunctionalLevel , когда узлы выключены или приостановлены? Нет. Для работы командлета Update-ClusterFunctionalLevel все узлы кластера должны быть включены и быть активными участниками.

Работает ли последовательное обновление ОС кластера для любой кластерной рабочей нагрузки? Это работает для SQL Server? Да, последовательное обновление ОС кластера работает для любой кластерной рабочей нагрузки. Однако это только нулевое время простоя для кластеров Hyper-V и масштабируемого файлового сервера.Большинство других рабочих нагрузок вызывают некоторое время простоя (обычно пару минут) при отработке отказа, а отработка отказа требуется хотя бы один раз в процессе последовательного обновления ОС кластера.

Могу ли я автоматизировать этот процесс с помощью PowerShell? Да, мы разработали последовательное обновление кластерной ОС для автоматизации с помощью PowerShell.

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

Что делать, если я обнаружу проблему в своем кластере после успешного запуска Update-ClusterFunctionalLevel ? Если вы создали резервную копию базы данных кластера с помощью резервной копии состояния системы перед запуском Update-ClusterFunctionalLevel , у вас должна быть возможность выполнить принудительное восстановление на узле кластера Windows Server 2012 R2 и восстановить исходную базу данных и конфигурацию кластера.

Могу ли я использовать обновление на месте для каждого узла вместо установки чистой ОС путем переформатирования системного диска? Мы не поощряем использование обновления Windows Server на месте, но мы знаем, что это работает в некоторых случаях, когда используются драйверы по умолчанию. Внимательно прочтите все предупреждающие сообщения, отображаемые во время обновления узла кластера на месте.

Если я использую репликацию Hyper-V для виртуальной машины Hyper-V в моем кластере Hyper-V, сохранится ли репликация во время и после процесса последовательного обновления ОС кластера? Да, реплика Hyper-V остается неизменной во время и после процесса последовательного обновления ОС кластера.

Могу ли я использовать System Center 2016 Virtual Machine Manager (SCVMM) для автоматизации процесса последовательного обновления ОС кластера? Да, вы можете автоматизировать процесс последовательного обновления ОС кластера с помощью VMM в System Center 2016.

Дополнительные ссылки

.Кластерное решение

для непрерывности вашего бизнеса

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

• Электронная коммерция
• Азартные игры и онлайн-казино
• Компании, ведущие базы данных
• Медицинская промышленность
• Фондовая промышленность
• Финансовая отрасль
• Страховые организации

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

Кластер высокой доступности

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

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

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

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

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

.

No related posts.