Для чего нужен кластер серверов
Высокопроизводительные кластерные решения
Обзор
Кластер серверов представляет собой группу из нескольких машин, которые объединены в единый аппаратно-программный ресурс. Для соединения отдельных серверов в кластер применяются высокоскоростные каналы связи. Пользователи и приложения видят их как единую высокопроизводительную и надежную систему. В зависимости от назначения выделяют три вида кластеров.
Отказоустойчивый кластер / 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). В противном случае вероятна ситуация, при которой попытка программы-клиента с помощью модуля получить доступ к данным ресурса через другие сервера может получить отказ (конкретные механизмы в данном случае зависят от возможностей и настроек кластера и клиентского оборудования).
Принято считать, что кластеры серверов делятся на две модели:
В обоих случаях, существуют определенные и вполне эффективные инструменты для решения проблем, поэтому выбор конкретной модели кластера неограничен ничем, кроме требований к архитектуре системы.
Кластер (группа серверов)
Кластер (группа серверов)
Кластер (в информацонных технологиях) — группа серверов (программных или аппаратных), объединённых логически, способных обрабатывать идентичные запросы и использующихся как единый ресурс. Чаще всего серверы группируются посредством локальной сети.
Группа серверов обладает большей надежностью и большей производительностью, чем один сервер.
Содержание
Принцип работы
Объединение серверов в один ресурс происходит на уровне программных протоколов.
В отличие от аппаратного кластера, кластеры, организуемые программно, требуют:
Примеры
Применение
В большинстве случаев, кластеры серверов функционируют на раздельных компьютерах. Это позволяет повышать производительность за счёт распределения нагрузки на аппаратные ресурсы и обеспечивает отказоустойчивость на аппаратном уровне.
Однако, принцип организации кластера серверов (на уровне программного протокола) позволяет исполнять по нескольку программных серверов на одном аппаратном. Такое использование может быть востребовано:
См. также
Примечания
Ссылки
Полезное
Смотреть что такое «Кластер (группа серверов)» в других словарях:
Кластер (группа компьютеров) — У этого термина существуют и другие значения, см. Кластер. Техники работают с большим Linux кластером в Хемницком техническом университете, Германия Кластер … Википедия
Кластер (компьютеры) — Кластер группа компьютеров, объединённых высокоскоростными каналами связи, представляющая с точки зрения пользователя единую машину. Один из первых архитекторов кластерной технологии Грегори Пфистер (Gregory F. Pfister) дал кластеру следующее… … Википедия
Кластер серверов — Кластер (в информацонных технологиях) группа серверов (программных или аппаратных), объединённых логически, способных обрабатывать идентичные запросы и использующихся как единый ресурс. Чаще всего серверы группируются посредством локальной сети.… … Википедия
Кластер — (англ. cluster скопление) объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами. В информационных технологиях: Кластер как подмножество… … Википедия
Серверный кластер — Кластер (в информацонных технологиях) группа серверов (программных или аппаратных), объединённых логически, способных обрабатывать идентичные запросы и использующихся как единый ресурс. Чаще всего серверы группируются посредством локальной сети.… … Википедия
Кластеры — Кластер (англ. cluster скопление) объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами. В информационных технологиях: Кластер (единица хранения данных) … … Википедия
IBM Lotus Notes — Lotus Notes Тип Groupware Разработчик IBM Lotus Software … Википедия
Суперкомпьютер — Стиль этой статьи неэнциклопедичен или нарушает нормы русского языка. Статью следует исправить согласно стилистическим правилам Википедии … Википедия
Мэйнфрейм — IBM System z9 модель 2094 Мейнфрейм (от англ. mainframe) данный термин имеет два основных значения. Большая универсальная ЭВМ высокопроизводительный компьютер со значительным объёмом оперативной и внешней памяти, предназначенный для организации… … Википедия
Мэйнфрэйм — IBM System z9 модель 2094 Мейнфрейм (от англ. mainframe) данный термин имеет два основных значения. Большая универсальная ЭВМ высокопроизводительный компьютер со значительным объёмом оперативной и внешней памяти, предназначенный для организации… … Википедия
Про кластер серверов 1С
Кластер — это разновидность параллельной
или распределённой системы, которая:
1. состоит из нескольких связанных
между собой компьютеров;
2. используется как единый,
унифицированный компьютерный ресурс
Дано: есть бизнес-приложение (например, ERP-система), с которым работают одновременно тысячи (возможно, десятки тысяч) пользователей.
К желаемому результату мы пришли не сразу.
В этой статье расскажем о том, какие бывают кластеры, как мы выбирали подходящий нам вид кластера и о том, как эволюционировал наш кластер от версии к версии, и какие подходы позволили нам в итоге создать систему, обслуживающую десятки тысяч одновременных пользователей.
Как писал автор эпиграфа к этой статье Грегори Пфистер в своей книге «In search of clusters», кластер был придуман не каким-либо конкретным производителем железа или софта, а клиентами, которым не хватало для работы мощностей одного компьютера или требовалось резервирование. Случилось это, по мнению Пфистера, ещё в 60-х годах прошлого века.
Традиционно различают следующие основные виды кластеров:
Для тех, кто не в курсе, коротко расскажу, как устроены бизнес-приложения 1С. Это приложения, написанные на предметно-ориентированном языке, «заточенном» под автоматизацию учётных бизнес-задач. Для выполнения приложений, написанных на этом языке, на компьютере должен быть установлен рантайм платформы 1С:Предприятия.
1С:Предприятие 8.0
Первая версия сервера приложений 1С (еще не кластер) появилась в версии платформы 8.0. До этого 1С работала в клиент-серверном варианте, данные хранились в файловой СУБД или MS SQL, а бизнес-логика работала исключительно на клиенте. В версии же 8.0 был сделан переход на трехзвенную архитектуру «клиент – сервер приложений – СУБД».
Сервер 1С в платформе 8.0 представлял собой СОМ+ сервер, умеющий исполнять прикладной код на языке 1С. Использование СОМ+ обеспечивало нам готовый транспорт, позволяющий клиентским приложениям общаться с сервером по сети. Очень многое в архитектуре и клиент-серверного взаимодействия, и прикладных объектов, доступных разработчику 1С, проектировалось с учетом использования СОМ+. В то время в архитектуру не было заложено отказоустойчивости, и падение сервера вызывало отключение всех клиентов. При падении серверного приложения СОМ+ поднимал его при обращении к нему первого клиента, и клиенты начинали свою работу с начала – с коннекта к серверу. В то время всех клиентов обслуживал один процесс.
1С:Предприятие 8.1
В следующей версии мы захотели:
Так в версии 8.1 появился первый кластер. Мы реализовали свой протокол удаленного вызова процедур (поверх ТСР), который по внешнему виду выглядел для конечного потребителя-клиента практически как СОМ+ (т.е. нам практически не пришлось переписывать код, отвечающий за клиент-серверные вызовы). При этом сервер, реализованный нами на С++, мы сделали платформенно-независимым, способным работать и на Windows, и на Linux.
На смену монолитному серверу версии 8.0 пришло 3 вида процессов – рабочий процесс, обслуживающий клиентов, и 2 служебных процесса, поддерживающих работу кластера:
Клиент на протяжении сессии работал с одним рабочим процессом, падение рабочего процесса означало для всех клиентов, которых этот процесс обслуживал, аварийное завершение сессии. Остальные клиенты продолжали работу.
1С:Предприятие 8.2
В версии 8.2 мы захотели, чтобы приложения 1С могли запускаться не только в нативном (исполняемом) клиенте, а ещё и в браузере (без модификации кода приложения). В связи с этим, в частности, встала задача отвязать текущее состояние приложения от текущего соединения с рабочим процессом rphost, сделать его stateless. Как следствие возникло понятие сеанса и сеансовых данных, которые нужно было хранить вне рабочего процесса (потому что stateless). Был разработан сервис сеансовых данных, хранящий и кэширующий сеансовую информацию. Появились и другие сервисы — сервис управляемых транзакционных блокировок, сервис полнотекстового поиска и т.д.
В этой версии также появились несколько важных нововведений – улучшенная отказоустойчивость, балансировка нагрузки и механизм резервирования кластеров.
Отказоустойчивость
Поскольку процесс работы стал stateless и все необходимые для работы данные хранились вне текущего соединения «клиент – рабочий процесс», в случае падения рабочего процесса клиент при следующем обращении к серверу переключался на другой, «живой» рабочий процесс. В большинстве случаев такое переключение происходило незаметно для клиента.
Механизм работает так. Если клиентский вызов к рабочему процессу по какой-то причине не смог исполниться до конца, то клиентская часть способна, получив ошибку вызова, этот вызов повторить, переустановив соединение с тем же рабочим процессом или с другим. Но повторять вызов можно не всегда; повтор вызова означает, что мы отправили вызов на сервер, а результата не получили. Мы стараемся повторить вызов, при этом при выполнении повторного вызова мы оцениваем, каков результат на сервере был у предшествующего вызова (информация об этом сохраняется на сервере в данных сеанса), потому что если вызов успел там «наследить» (закрыть транзакцию, сохранить сеансовые данные и т.п.) – то просто так повторять его нельзя, это приведет к рассогласованию данных. Если повторять вызов нельзя, клиент получит сообщение о неисправимой ошибке, и клиентское приложение придется перезапустить. Если же вызов «наследить» не успел (а это наиболее частая ситуация, т.к. многие вызовы не меняют данных, например, отчеты, отображение данных на форме и т.п., а те, которые меняют данные – пока транзакция не зафиксирована или пока изменение сеансовых данных не отправлено в менеджер – следов вызов не оставил) — его можно повторить без риска рассогласования данных. Если рабочий процесс упал или произошел обрыв сетевого соединения – такой вызов повторяется, и эта «катастрофа» для клиентского приложения происходит полностью незаметно.
Балансировка нагрузки
Задача балансировки нагрузки в нашем случае звучит так: в систему заходит новый клиент (или уже работающий клиент совершает очередной вызов). Нам надо выбрать, на какой сервер и в какой рабочий процесс направить вызов клиента, чтобы обеспечить клиенту максимальное быстродействие.
Это стандартная задача для кластера с балансировкой нагрузки. Есть несколько типовых алгоритмов её решения, например:
Запрос от нового клиента адресуется на наиболее производительный на данный момент сервер.
Запрос от существующего клиента в большинстве случаев адресуется на тот сервер и в тот рабочий процесс, в который адресовался его предыдущий запрос. С работающим клиентом связан обширный набор данных на сервере, передавать его между процессами (а тем более между серверами) – довольно накладно (хотя мы умеем делать и это).
Запрос от существующего клиента передается в другой рабочий процесс в двух случаях:
Резервирование кластеров
Мы решили повысить отказоустойчивость кластера, прибегнув к схеме Active / passive. Появилась возможность конфигурировать два кластера – рабочий и резервный. В случае недоступности основного кластера (сетевые неполадки или, например, плановое техобслуживание) клиентские вызовы перенаправлялись на резервный кластер.
Однако эта конструкция была довольно сложна в настройке. Администратору приходилось вручную собирать две группы серверов в кластеры и конфигурировать их. Иногда администраторы допускали ошибки, устанавливая противоречащие друг другу настройки, т.к. не было централизованного механизма проверки настроек. Но, тем не менее, этот подход повышал отказоустойчивость системы.
1С:Предприятие 8.3
В версии 8.3 мы существенно переписали код серверной части, отвечающий за отказоустойчивость. Мы решили отказаться от схемы Active / passive кластеров ввиду сложности её конфигурирования. В системе остался только один отказоустойчивый кластер, состоящий из любого количества серверов – это ближе к схеме на Active / active, в которой запросы на отказавший узел распределяются между оставшимися рабочими узлами. За счет этого кластер стал проще в настройке. Ряд операций, повышающих отказоустойчивость и улучшающих балансировку нагрузки, стали автоматизированными. Из важных нововведений:
Главная идея этих наработок – упростить работу администратора, позволяя ему настраивать кластер в привычных ему терминах, на уровне оперирования серверами, не опускаясь ниже, а также минимизировать уровень «ручного управления» работой кластера, дав кластеру механизмы для решения большинства рабочих задач и возможных проблем «на автопилоте».
Три звена отказоустойчивости
Как известно, даже если компоненты системы по отдельности надёжны, проблемы могут возникнуть там, где компоненты системы вызывают друг друга. Мы хотели свести количество мест, критичных для работоспособности системы, к минимуму. Важным дополнительным соображением была минимизация переделок прикладных механизмов в платформе и исключение изменений в прикладных решениях. В версии 8.3 появилось 3 звена обеспечения отказоустойчивости «на стыках»:
В заключение
Благодаря механизму отказоустойчивости приложения, созданные на платформе 1С:Предприятие, благополучно переживают разные виды отказов рабочих серверов в кластере, при этом бо́льшая часть клиентов продолжают работать без перезапуска.
Бывают ситуации, когда мы не можем повторить вызов, или падение сервера застает платформу в очень неудачный момент времени, например, в середине транзакции и не очень понятно, что с ними делать. Мы стараемся обеспечить статистически хорошую выживаемость клиентов при падении серверов в кластере. Как правило, средние потери клиентов за отказ сервера – единицы процентов. При этом все «потерянные» клиенты могут продолжить работу в кластере после перезапуска клиентского приложения.
Надежность кластера серверов 1С в версии 8.3 существенно повысилась. Уже давно не редкость внедрения продуктов 1С, где количество одновременно работающих пользователей достигает нескольких тысяч. Есть и внедрения, где одновременно работают и 5 000, и 10 000 пользователей — например, внедрение в «Билайне», где приложение «1С: Управление Торговлей» обслуживает все салоны продаж «Билайн» в России, или внедрение в грузоперевозчике «Деловые Линии», где приложение, самостоятельно созданное разработчиками ИТ-отдела «Деловых Линий» на платформе 1С:Предприятие, обслуживает полный цикл грузоперевозок. Наши внутренние нагрузочные тесты кластера эмулируют одновременную работу до 20 000 пользователей.
В заключение хочется кратко перечислить что ещё полезного есть в нашем кластере (список неполный):
Кластерные системы
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.
Каждый из узлов кластера имеет независимый выход в интернет, но при этом из сети данных кластер выглядят как единый сервер с единым адресом и контентом.