Надежность серверов становится одним из ключевых факторов успешной работы предприятия, которая, как правило, в очень большой степени зависит от информационной сетевой инфраструктуры. Будь-то электронный магазин, ведущий продажи через свой сайт и имеющий в штате одного-двух сотрудников, крупное предприятие, в которой специальные системы осуществляют поддержку производственных процессов в реальном времени, банк с разветвленной филиальной сетью или центр обслуживания телефонного оператора, использующий систему поддержки принятия решений — всем им жизненно необходимы серверы, которые работают и предоставляют информацию 24 часа в день, семь дней в неделю.
Безусловно, добиться этого можно, установив специализированную отказоустойчивую систему, в которой дублируются все подверженные отказам элементы — источники питания, процессоры, оперативная и внешняя память. Но подобное решение будет непомерно дорогим и сложным в управлении для малых и средних компаний. Они все чаще доверяют свой бизнес более дешевым серверам на базе процессоров Intel вместо RISC-серверов. Однако уровень готовности таких серверов, то есть соотношение времени работоспособности к времени простоев, как правило, не превышает 99%. Это означает, что около 4 дней в год система не сможет обслуживать своих клиентов. Может показаться, что это не так уж и много, тем более, что сюда входят и плановые простои для проведения профилактических работ или реконфигурации. Но клиенту, например, пользователю системы оплаты по кредитным карточкам, по большому счету, совершенно безразлично, по какой причине он останется без обслуживания, и его вряд ли удовлетворят объяснения, что этот отрезок времени попадает в неизбежный для системы 1% простоев.
Дорогие высоконадежные машины способны обеспечить заветные «пять девяток» — 99,999% надежности системы, что означает не более 5 минут простоев в год. Приблизиться к этому показателю с меньшими затратами, хотя, скорее всего, и не достичь его окончательно, позволяет кластеризация, то есть объединение в общую систему нескольких автономных серверов. Хотя многие производители серверов систем и сетевого ПО последнее время активно поднимают на щит эту технологию, рынок продуктов кластеризации пока не очень велик. По оценкам Strategic Research, в 1997 году объем продаж в этом секторе составил 160 млн. долл. Но при этом она же прогнозирует рост рынка к 2000 году до уровня 1,15 млрд. долл. Уже не один год существуют кластерные продукты для различных вариантов Unix, а сейчас появляются кластерные решения на базе Windows NT.
На подступах к кластеризации
Существует немало средств построить надежную систему. Дисковые массивы RAID, например, позволяют не прерывать обработку запросов к информации, хранящейся на дисках, при выходе из строя одного или нескольких элементов массива. Нет недостатка в технологиях, гарантирующих избыточность других подсистем сервера. Так, резервные блоки питания позволят скорректировать отказ этой компоненты. Источники бесперебойного питания поддержат работоспособность системы в случае сбоев в сети энергоснабжения. Многопроцессорные материнские платы обеспечат функционирование сервера в случае отказа процессора.
Однако ни один из этих вариантов не спасет, если из строя выйдет вся вычислительная система целиком. Вот тут на помощь приходит кластеризация. Первым шагом к созданию кластеров можно считать широко распространенные в пору расцвета миникомпьютеров системы «горячего резерва». По этой технологии в сети из нескольких серверов один или два не выполняют никакой полезной работы, но готовы начать функционировать, как только выйдет из строя какая-либо из основных систем.
Простейший вариант кластеризации — зеркалирование, когда один из сетевых серверов выступает в роли «зеркала» для другого. На «зеркальном» сервере установлено то же самое программное обеспечение, что и на основном, причем актуальность этого ПО поддерживается путем передачи данных по коммуникационному каналу, соединяющему серверы в кластере. Единственное отличие между двумя системами состоит в том, что зеркальный сервер не реагирует на сетевые запросы до тех пор, пока не выйдет из строя основной. Сбой обнаруживает «зеркало» и инициирует выполнение приложения на нем, пpи этом все запросы обрабатываются точно так же, как и на основном сервере. Такую конфигурацию кластера называют «активный/резервный».
С точки зрения пользователей основной и зеркальный сервер — это единая система, они не знают и не могут узнать, какой из серверов в данный момент обслуживает запросы. Несколько видоизмененный вариант такой кластеризации — это два сервера, подменяющие друг друга в случае сбоя (конфигурация «активный/активный»). Например, Web-сервер и сервер приложений в одной сети могут выполнять функции «зеркала» друг для друга. Если выйдет из строя Web-сервер, его функции возьмет на себя сервер приложений и наоборот. Некоторые программные решения даже позволяют любому компьютеру в сети выступать в качестве «зеркала» для любой другой машины в той же сети. По их логике подменить Web-сервер сможет, например, высокопроизводительная пользовательская рабочая станция, или же группа таких станций, между которыми будет распределена вся вычислительная нагрузка.
Мы будем говорить о кластерных системах как о специальным образом построенном объединении серверов с помощью коммуникационного канала, при котором все компьютеры выполняют полезную работу, а с точки зрения пользователя и приложений группа серверов, или узлов, кластера, выглядит как единая серверная система. Такую концепцию кластера впервые предложила и реализовала в начале 80-х корпорация Digital Equipment, которая и по сей день активно продвигает эту технологию. Аналитики в один голос назвали решение Digital для операционной системы ОpenVMS эталоном кластеризации. Сейчас в мире установлено более 50 тысяч кластеров ОpenVMS.
В отличие от отказоустойчивых систем с избыточными компонентами, а также различных вариантов многопроцессорности, кластеры объединяют относительно независимые друг от друга машины, каждую из которых можно остановить для профилактики или реконфигурирования, не нарушая при этом работоспособности кластера в целом. Высокая производительность кластера и сведение к минимуму времени простоев приложений достигается благодаря тому, что:
- в случае сбоя ПО на одном из узлов приложение продолжает функционировать или автоматически перезапускается на других узлах кластера;
- выход из строя одного из узлов (или нескольких) не приведет к краху всей кластерной системы;
- профилактические и ремонтные работы, реконфигурацию или смену версий программного обеспечения, как правило, можно осуществлять в узлах кластера поочередно, не прерывая работы других узлов.
Как устроен кластер
Итак, кластер объединяет несколько серверов, соединенных между собой специальным коммуникационным каналом, часто называемым также «системной сетью». Неотъемлемой частью кластера является специальное программное обеспечение, которое, собственно, и решает проблему восстановления узла в случае сбоя, а также решает другие задачи, например, изменяет IP-адрес сервера приложений, если он вышел из строя и выполнение переложено на другой узел. Кластерное ПО обычно имеет несколько заранее заданных сценариев восстановления работоспособности системы, а также может предоставлять администратору возможности настройки таких сценариев. Восстановление после сбоев может поддерживаться как для узла в целом, так и для отдельных его компонентов — приложений, дисковых томов и т.д. Эта функция автоматически инициируется в случае системного сбоя, а также может быть запущена администратором, если ему, например, необходимо отключить один из узлов для реконфигурации.
Кластеры могут иметь разделяемую память на внешних дисках, как правило, на дисковом массиве RAID. Общая файловая система позволяет перезапускать приложения на вышедшем из строя узле и совмеделяемым дискам по общей шине, требует определенной координации доступа, для того чтобы не возникало попыток одновременно изменить один и тот же файл на диске. Эта координация реализуется с помощью специального механизма — диспетчера распределенных блокировок (Distributed Lock Manager, DLM), который закрывает доступ к устройству для всех узлов, кроме одного, приложение которого в данный момент модифицирует данные этого устройства. Подобный механизм присутствует, в частности, на кластерах OpenVMS, но не реализован в существующих на сегодняшний день кластерных решений для NT. В этих системах приложения не могут параллельно работать с одними и теми же данными и общая дисковая память, если таковая имеется, назначается одному из узлов в данный момент времени.
Таким образом, в кластерах, которые не поддерживают одновременного доступа к внешней памяти, все узлы являются полностью автономными серверами. В случае двух узлов доступ к общей памяти на дисках осуществляется с помощью разделенной шины ввода/вывода — для каждого узла шина заканчивается в дисковом массиве. В каждый момент времени только один узел владеет общей файловой системой. Если один из серверов выйдет из строя, контроль над шиной и разделяемыми дисками переходит к другому узлу.
Вместо разделяемой внешней памяти, в кластерах может реализовываться принцип зеркалирования информации, когда данные одного узла тиражируются на дисковые накопители другого.
Узлы кластера контролируют работоспособность друг друга и обмениваются специфической «кластерной» информацией, например, о конфигурации кластера, а также передавать данные между разделяемыми накопителями и координировать их использование. Контроль работоспособности осуществляется с помощью специального сигнала (в литературе по кластерам он называется «heartbeat» — сердцебиение), который узлы кластера передают друг другу, для того чтобы подтвердить свое нормальное функционирование. Прекращение «сердцебиения» одного из узлов сигнализирует кластерному программному обеспечению о произошедшем сбое и необходимости перераспределить нагрузку на оставшиеся узлы.
В качестве коммуникационного канала могут использоваться обычные сетевые технологии (Ethernet, Token Ring, FDDI, АТМ), разделяемые шины ввода/вывода (SCSI или PCI), высокоскоростной интерфейс Fibre Channel или специализированные технологии (DSSI, CI, Memory Channel). Требования, предъявляемые к быстродействию коммуникационного канала, зависят от степени интеграции узлов кластера и характера работы приложений. Скажем, если приложения в разных узлах не взаимодействуют друг с другом и не осуществляют одновременный доступ к дисковым накопителям, то узлы обмениваются между собой только контрольными сообщениями, подтверждающими их работоспособность, а также информацией об изменении конфигурации кластера, то есть добавлении новых узлов, перераспределении дисковых томов и т.д. Такой тип обмена не потребует значительных ресурсов межсоединения и вполне может удовлетвориться простым 10-мегабитным Ethernet.
Высокоскоростной коммуникационный канал нужен, если приложения в разных узлах кластера будут работать с одними и теми же данными. Реализация механизма DLM предполагает интенсивный обмен сообщениями между узлами. А значит, потребует высокой производительности межсоединения узлов кластера.
В качестве примера различных вариантов кластерных решений можно привести предлагаемое ветераном в этой области, Digital, ставшим частью компании Compaq, семейство программных продуктов TruCluster для объединения в кластер серверов AlphaServer с ОС Digital Unix (теперь Tru64 Unix - прим. ред.). Один из представителей этого семейства, TruCluster Production Server поддерживает параллельное выполнение приложения на всех узлах кластера с помощью механизма DLM и ориентирован на использование таких программных решений, как, например, СУБД Oracle Parallel Server.
TruCluster Production Server поддерживает постоянное функционирование приложений во всех узлах кластера, ликвидируя тем самым задержки, связанные с перезапуском приложения в случае сбоя одного из узлов. Кроме того, это решение обеспечивает масштабируемость системы, повышая производительность приложения при добавлении новых узлов в кластер. Однако для того чтобы добиться такой масштабируемости и эффективно реализовать механизм DLM, необходимо высокопроизводительное соединение между узлами. Поэтому с TruCluster Production Server используется специальная высокоэффективная коммуникационная технология Memory Channel, которая обеспечивает высокоскоростной (до 100 Мбайт/с) обмен сообщениями между серверами в кластере.
Другой продукт семейства TruCluster, более экономичный TruCluster Available Server, обеспечивает выполнение на разных узлах разных наборов приложений, не поддерживает механизм DLM и вместо быстродействующего соединения Memory Channel использует для межсерверного взаимодействия разделяемый интерфейс SCSI. В таком кластере нагрузка автоматически перераспределяется между работающими узлами, если какой-либо сервер выйдет из строя. Таким образом, все узлы выполняют свою работу и одновременно выполняют роль «горячего резерва» для остальных.
Что касается старейшей из кластерных систем Digital, ОpenVMS Cluster, то она действительна универсальна. ПО кластеризации интегрировано в операционную систему на всех уровнях, что позволяет серверам в кластере совместно использовать не только дисковые подсистемы внешней памяти, но и накопители на магнитных лентах и CD-ROM. И с точки зрения пользователя, и с точки зрения системного администратора такой кластер выглядит как единое, мощное поле ресурсов — процессоров, дисковых массивов, магнитных лент, очередей печати и пакетных заданий. ОpenVMS Cluster поддерживает механизм DLM и позволяет приложениям на всех узлах работать с одними и теми же данными. В зависимости от типа межсоединения, ОpenVMS Cluster поддерживает до 96 узлов. Эта система может работать с различными коммуникационными каналами, от специально разработанных кластерных шин CI (Computer Interconnect) и DSSI (Digital Storage System Interconnect) до стандартных сетевых технологий. Может использоваться также шина SCSI и коммуникационная технология Memory Channel.
Более того, с помощью определенных сетевых соединений можно разносить узлы ОpenVMS-кластера на расстояния до 40 км и строить резервные компьютерные центры. Таким образом, ОpenVMS Cluster позволяет реализовать не просто систему с высоким уровнем готовности, а по-настоящему катастрофоустойчивое решение. Если с основным компьютерным центром произойдет что-то более серьезное, чем выход из строя одного из серверов — например, он пострадает от пожара, землетрясения или террористического акта — резервный центр сможет продолжить работу.
Кластеризация Intel-серверов
Ряд производителей мощных серверов предлагают собственные решения для построения кластерных конфигураций. Значительный опыт в этой области имеют IBM, Hewlett-Packard, NCR, Sun, Silicon Graphics. Как правило, в их решениях в кластеры объединяются Unix-серверы с процессорами RISC-архитектуры. Однако, последнее время на серверной арене все громче заявляет о себе Intel. Это связано прежде всего с созданием все более мощных процессоров, а также растущей популярностью Windows NT Server и развертыванием на Intel-серверах высококритичных приложений масштаба предприятия.
ПК-серверы уже завоевали надежные позиции на рынке систем для рабочих групп и малых предприятий. Теперь же одним из стратегических направлений Intel становится рынок корпоративных серверов.
Для того чтобы достичь этой цели, Intel намерена действовать двояко: во-первых, создавать высокопроизводительные процессоры, способные конкурировать с RISС; во-вторых, совершенствовать серверные архитектуры, так чтобы иметь возможность строить высокопроизводительные системы на базе стандартных массовых платформ.
Архитектура VI
Как всякая развивающаяся технология,сложным комплексам серверов старшего класса, которые были частным решением одного производителя, приходят кластеры на базе стандартных массовых платформ, возникает необходимость и в определенной унификации межсоединения узлов. Инициативу по такой стандартизации взяли на себя Intel, Compaq и Microsoft, предложившие архитектуру виртуального интерфейса (Virtual Interface, VI) для создания единообразных коммуникационных каналов между серверами на базе процессоров Intel.
Архитектура VI определяет стандартные аппаратные и программные интефейсы, которые задают универсальные правила передачи сообщений между узлами кластера и не зависят от конкретного оборудования межсоединений и операционной системы объединенных в кластер серверов. VI вводит технологию распределенной передачи сообщений (Distributed Message Passing, DMP), благодаря которой будут сведены к минимуму задержки работы системы из-за взаимодействия узлов. Для реализации технологии DMP необходимы соответствующие стандарту VI интеллектуальные платы сетевого интерфейса, соответствующие этому стандарту драйверы внешних устройств в операционной системе (такие драйверы разрабатывает, в частности, Microsoft), а также прикладные системы, способные воспользоваться преимуществами новой архитектуры. Новая технология позволит ликвидировать узкие места в распределенной среде базы данных, возникающие из-за задержки или остановки сетевого трафика на межкластерных соединениях.
Благодаря архитектуре VI появляется возможность организовать поток данных между системой хранения и узлами кластера без прерываний работы процессора. Очевидно, что чем меньше таких прерываний, тем производительнее система. Кластер можно будет сделать более масштабируемым, просто добавив дополнительные процессоры в узлах и не увеличивая при этом сетевых задержек. Наконец, разработчики приложений получают в свои руки стандарт, позволяющий создавать прикладные системы, не зависящие от операционной системы кластера и аппаратных компонентов межсоединения.
В результате с помощью кластеризации множества серверов удастся получить высокопроизводительную систему для приложений, для которых характерно интенсивное обращение к информационному наполнению. Архитектура VI позволит добиться эффективного распараллеливания работы одного приложения на множестве узлов, равно как и максимально быстрого обмена данными между распределенными прикладными модулями на разных узлах.
Интеллектуальный ввод/вывод
Увеличение быстродействия микропроцессорного ядра должно сопровождаться совершенствованием других компонент сервера, в частности, ускорением системной шины и повышением эффективности системы ввода/вывода, поскольку, во-первых, обработка прерываний от внешних устройств съедает значительные процессорные ресурсы в ущерб непосредственному выполнению приложений, а во-вторых, рост отдельно взятой мощности процессора создаст эффект «бутылочного горлышка» при обращении к подсистемам хранения информации и взаимодействии с другими системами. Поэтому еще одна технологическая инициатива, поддержанная ведущими производителями серверных систем, связана со стандартизацией архитектуры интеллектуального ввода/вывода (Intelligent Input/Output, I2O).
Модель I2O подразумевает использование специального процессора ввода/вывода. Это тот случай, когда новое оказывается хорошо забытым старым, поскольку концеппция процессоров ввода/вывода родилась в 50-х годах в период формирования второго поколения вычислительных машин. Спецификация I2O определяет унифицированный интерфейс между операционной системой и устройствами ввода/вывода, в значительной степени освобождая процессор и системную шину от операций по обслуживанию ввода/вывода и возлагая большую часть этих функций на саму подсистему ввода/вывода.
I2O задает модель «расщепленного драйвера», благодаря которой появляется возможность создавать универсальные драйверы для множества операционных систем и аппаратных платформ. Учитывая разнообразие существующих операционных систем и еще большее разнообразие внешних устройств, можно себе представить, какая непростая задача стоит перед разработчиками драйверов, которые должны писать отдельную систему для каждой уникальной комбинации ОС и периферийной аппаратуры. Модель разделяет драйвер на две взаимодействующие компоненты — одна отвечает за обслуживание ОС, другая поддерживает внешнее устройство.
Таким образом, в соответствии с этой моделью производитель операционной системы реализует всего один I2O-совместимый драйвер для каждого класса устройств ввода/вывода, например, дисковых адаптеров, а производитель контроллера ввода/вывода пишет единственный I2O-совместимый интерфейс, который обеспечит работу контроллера с любой ОС, снабженный I2O-драйвером. Наконец, производитель периферийного устройства должен усовершенствовать протокол связи с драйвером таким образом, чтобы он соответствовал архитектуре I2O.
Спецификация I2O определяет не зависящий от аппаратной платформы способ взаимодействия центрального процессора с процессорами ввода/вывода и дает возможность платам ввода/вывода взаимодействовать друг с другом без прерывания работы процессора.
Архитектура интеллектуального ввода/вывода будет способствовать построению эффективных кластерных систем, поскольку, аналогично интерфейсу VI, облегчит масштабирование кластеров путем добавлением процессоров в узлах кластера и значительно снизит нагрузку на процессор, связанную с обменом информацией между серверами в кластере.
Ведущие производители ПК-серверов снабжают свои системы компонентами для поддержки I2O-совместимых операционных систем и периферии. Microsoft, Novell и SCO поставляют дополнительные модули для операционных систем, которые поддерживают спецификацию I2O.
Исследования, проведенные Aberdеen Group, показали, что с выходом в 1998 году процессора Pentium II Xeon производительность серверов возросла до 20 тыс. транзакций в минуту, а серверы на базе 64-разрядного Merced смогут продемонстрировать существенно большее быстродействие. Причем, такой значительный рост производительности будет связан не только с большей мощностью процессора, но и с более эффективной организацией ввода/вывода.
Восьмипроцессорный сервер на Pentium III Xeon обещает рост производительности на 30-40% и двукратное увеличение скорости работы приложений при переходе на 64-разрядную архитектуру. Наконец, наиболее значительный рост производительности связывается с широким распространением кластерных конфигураций ПК-серверов.
Примеры решений
Ряд компаний предлагают программные и программно-аппаратные решения для кластеризации ПК-серверов. Причем кластер может работать как под управлением NT, так и под управлением различных реализаций ОС Unix.
Cluster Server, первый кластерный продукт Microsoft, известный также под рабочим названием Wolfpack, пока обеспечивает разделение нагрузки только между двумя узлами, но на следующем этапе корпорация планирует поддерживать до 16 узлов в кластере. Узлы могут быть на базе процессоров Intel или Alpha, но платформы обоих серверов должны быть идентичны и к тому же специально сертифицированы на совместимость с Wolfpack.
В дуальном кластере MSCS один из серверов рассматривается как основной, а другой как вторичный. Внешние диски подключаются посредством разделенной шины SCSI. В качестве межсоединения может использоваться любая локальная сетевая технология.
Несмотря на функциональное разделение серверов на основной и вторичный, кластер MSCS имеет конфигурацию «активный/активный», то есть вторичный сервер может выполнять свои собственные (возможно, не самые критичные) приложения. Одновременно вторичный сервер постоянно отслеживает статус операций на основном узле и в случае сбоя прекращает выполнение своих собственных приложений и берет на себя нагрузку основного сервера. Последующий рестарт системы восстанавливает доступность кластера в целом. Статус всех ресурсов может отслелах кластера.
Помимо программного обеспечения кластеризации, MSCS реализует API-интерфейсы, позволяющие разработчикам создавать приложения, способные эффективно работать именно на кластерной аппаратуре. В настоящее время операционная система Windows NT Server, Enterprise Edition предлагает встроенную поддержку MSCS.
Разработанное Digital кластерное решение для NT, Digital Clusters for Windows NT позволяет объединить два сервера на платформе Alpha или Intel, причем, в отличие MSCS, серверы не обязаны быть идентичными. Объединение серверов происходит с помощью общей шины SCSI, к которой подсоединены также все доступные устройства хранения. Это решение не поддерживает механизм DLM, то есть не позволяет разным узлам одновременно работать с одними и теми же данными. В системе реализован режим «активный/активный» — оба сервера в кластере выполняют полезную работу и обеспечивает автоматическое перераспределение нагрузки в случае сбоя одного из серверов.
 |
|
Рис. 1. Кластер NT Cluster-in-a-box компании Data General объединяет два Intel-сервера AviiON с разделяемой памятью на дисковом массиве |
Data General пошла по пути предоставления законченной кластерной системы, в которой есть уже все необходимое — соединенные между собой серверы с разделяемым дисковым массивом и необходимое ПО. Оправдывая свое название, дуальный кластер NT Cluster-in-a-Box объединяет в одном корпусе все необходимые компоненты: два четырехпроцессорных SMP-сервера AviiON от Data General на базе Pentium Pro/200 МГц, канал Ethernet для межсоединения узлов, общую внешнюю память на дисковом массиве CLARiiON, доступ к которому узлы кластера осуществляют по разделенной шине SCSI (рис. 1). Дисковый массив разбит на 3 раздела, два из которых назначаются первому серверу в кластере, который считается основным, и еще один раздел принадлежит второму узлу. В случае сбоя основного сервера управление назначенными ему дисками переключится на второй сервер. Когда работоспособность первого узла будет восстановлена, произойдет обратное переключение.
В качестве программного обеспечения кластеризации Data General позволяет использовать кластерное решение Microsft CS, а также систему FirstWatch компании Veritas, которая поддерживает как конфигурацию «активный/резервный», так и «активный/активный», когда оба узла выполняют полезную работу. Возможно восстановление после сбоев как для отдельных приложений, так и для сервера в целом, а также плановые отключения узлов для ремонта и профилактики. Пользователю системы понадобится только установить IР-адреса для узлов кластера, и система будет полностью готова к эксплуатации.
Кластерное решение SNI на базе ПК-серверов Primergy использует собственное программное обеспечение, основанное на базовых средствах NT. В частности, управляющая программа Primergy ServerView решает задачи мониторинга узлов, управления и восстановления. Центральный модуль управления (диспетчер) на выделенном узле получает информацию от агентов, которые работают на всех серверах в кластере, собирая и пересылая затребованную информацию. Наблюдение ведется практически за всеми аппаратными компонентами сервера, и нарушение определенных условий ведет к генерации предупредительных сообщений и инициализации функций восстановления. Сервер автоматической реконфигурации и рестарта позволяет определить реакцию системы на сбой. Как правило, это выдача команды shutdown, исключение из конфигурации отказавшего компонента и перезагрузка.
Для ОС Unix на платформе Intel интересное кластерное решение предлагает, в частности, SCO. Первоначальная версия системы кластеризации SCO UnixWare ReliantHA появилась в 1997 году, а через год была выпущена UnixWare 7 ReliantHA для новой версии UnixWare. ПО UnixWare ReliantHA предназначено для управления кластером однопроцессорных и многопроцессорных Intel-серверов и обеспечивает непрерывный мониторинг и восстановление после сбоев для приложений, отдельных ресурсов сервера и узла в целом. UnixWare ReliantHA обеспечивает объединение в кластер двух, трех или четырех серверов, каждый из которых может выполнять приложения, то есть находиться в активном состоянии.
Система ReliantHA позволяет администратору с помощью специальных сценариев описать приложение, его поведение при запуске и любые зависимости от других приложений и аппаратных ресурсов. В случае сбоя инициируется один из вариантов автоматического восстановления: перезапустить приложение или ресурс, переключить путь доступа на другой диск или приложение на том же самом сервере или, если вышел из строя весь узел, перевести все службы на другие системы в кластере. Как только поврежденный сервер восстановлен, он может снова включиться в работу кластера. Для ряда приложений, система поддерживает заранее заданные сценарии. Узлы связываются между собой по выделенному каналу Ethernet или последовательному соединению. Переключение на альтернативный путь доступа к данным осуществляется благодаря использованию разделенной шины SCSI.
Кластеры предназначены прежде всего для высоко-критичных приложений, простой которых повлечет за собой очень значительные материальные потери для компании. Это оперативная обработка транзакций, например, в банковской сфере, системы поддержки принятия решений на основе хранилищ данных, приложения электронной коммерции, корпоративные Web-серверы. Но есть еще одно интересное применение кластеризации — суперкомпьютерные вычисления для определенных научных задач, в которых на первый план выходит не столько высокая доступность сервера, сколько его быстродействие и способность эффективно распараллелить решаемую задачу. Не все вычислительные задачи подвергаются такому распараллеливанию, а высочайшая производительность, которая, теоретически, достижима при одновременном выполнении вычислений на множестве машин, может быть существенно снижена низким быстродействием и большими задержками в межсоединении узлов кластера. Однако, есть примеры вполне успешной реализации такого суперкластера, причем на основе NT. В США в Национальном центре суперкомпьютерных приложений (NCSA) Университета штата Иллинойс построен 256-процессорный кластер, объединяющий 128 рабочих станций Compaq и Hewlett-Packard под управлением NT. Конечно, для того чтобы обеспечить надлежащую производительность и эффективность параллельных вычислений, понадобилось специальное программное обеспечение, разработанное в NCSA, и специализированное высокоскоростное соединение — сеть Myrinet компании Myricom, которые в совокупности позволяют узлам кластера обмениваться данными со скоростью порядка 80 Мбайт/с при уровне задержек, не превышающем 11 мкс. Безусловно, и такое решение стоит недешево, однако, в сравнении с традиционными суперкомпьютерами для научных расчетов, кластер на базе стандартных Intel-процессоров представляет собой гораздо более экономичный вариант.
Каждому предприятию - свой кластер
Судя по последним публикациям в компьютерной прессе и исследованиям ряда аналитических компаний, за кластеризацией, и в особенности кластеризацией массовых Intel-серверов средней производительности — большое будущее. Но и большие проблемы. Не определились еще стандарты для объединения серверов в кластер, поэтому среди продуктов поддержки кластеризации много частных, закрытых решений. Как следствие — приложения не удастся переносить с одной кластерной платформы на другую без внесения значительных модификаций. Смешение различных аппаратных платформ в одном кластере — тоже пока скорее исключение, чем правило. Но поскольку этой задачей всерьез заинтересовалась Intel и активно увлекла за собой многих производителей серверов и операционных систем, то, учитывая распространенность машин на базе Intel-процессоров, есть все основания надеяться, что в новом веке каждое уважающее себя предприятие, кровно заинтересованное в надежном обслуживании своих клиентов, обзаведется своим собственным кластером.
Новые процессоры и новые стандарты
Процессоры семейства Pentium поколебали лидерство архитектуры RISC в области производительных систем. Последнее поколение Intel-процессоров по своим возможностям во многом приближается к RISC-архитектуре. Имеется в виду производительность системной шины, возможность построения многопроцессорных систем и ряд других усовершенствований функций обработки данных. Решительный удар по конкурентам Intel намеревается нанести своим 64-разрядным процессором Merced.
Но помимо многообещающей 64-разрядной архитектуры Intel продолжает делать ставку на совершенствование 32-разрядных процессоров и серверов на их основе. Основные технологические инициативы, которые призваны помочь добиться успеха на рынке корпоративных серверов, следующие:
- усовершенствование серверных систем путем создания быстродействующих процессоров, увеличения размера кэш-памяти и повышения быстродействия системной шины;
- разработка и стандартизация технологий для повышения производительности системы ввода/вывода;
- стандартизация аппаратных средств управления сервером;
- стандартизация средств межсоединения серверов в кластере для создания высокопроизводительных систем на основе машин старшего и среднего класса.
Первый шаг к увеличению производительности ПК-серверов средней мощности — это выпуск процессоров Pentium II Xeon и Pentium III Xeon. Pentium II Xeon имеет ряд важных отличий от своего предшественника, процессора Pentium II. Прежде всего, он обладает более быстрой кэш-памятью большей емкости (до 2 Гбайт). В Pentium II тактовая частота кэша была вдвое меньше быстродействия процессора, а в Xeon эти две характеристики совпадают, благодаря чему ликвидируются задержки в процессе обмена информацией между процессором и кэш-памятью.
Более быстрой стала и системная шина, связывающая процессор с основной памятью, объем которой также вырос. Если в Pentium II она работала на тактовой частоте 66 МГц, то в Pentium II Xeon используется системная шина 100 МГц. Это способствует более производительному выполнению операций обработки транзакций, сложных запросов к базам данных и других приложений, связанных с частым обращением к памяти. Благодаря всем этим усовершенствованиям, системы на основе Xeon смогут успешно справляться с задачами интенсивной обработки информации, такими, например, как работа с базами или хранилищами данных, аналитическая обработка и поддержка принятия решений или автоматизированное проектирование
Архитектурные особенности Pentium II Xeon позволяют строить на его основе четырехпроцессорные SMP-системы, и такие серверы уже доступны. В 1999 году Intel планирует завершить разработку восьмипроцессорных системных плат с Pentium III.
Для того чтобы добиться более высокого уровня готовности серверов и дать возможность строить производительные, масштабируемые системы из «блоков» средней мощности, Intel вместе со своими партнерами активно развивает технологию кластеризации. Разработчики программного и апаратного обеспечения кластерных систем представляют широкий спектр продуктов кластеризации Intel-серверов, а сама Intel, помимо совершенствования своих процессоров, работает над стандартами межсоединения узлов и более эффективной организацией систем ввода/вывода.
Претендент в идеальные кластеры
В идеале кластер должен не просто обеспечивать высокую доступность системы для критичных бизнес-приложений. Задача первостепенной важности при разработке кластерного решения — сделать его простым и эффективным в управлении, а также, что очень важно, поддерживать простую масштабируемость системы, так чтобы можно было без больших усилий наращивать аппаратную и программную мощь кластера. Кроме того, было бы замечательно, если бы все серверные приложения могли исполняться в кластере без каких-либо модификаций.
Известные на сегодняшний день клаcтерные системы для NT во главе с Microsoft Cluster Server пока далеки от идеала. Большинство из них не поддерживают больше двух узлов, обеспечивая уровень доступности, не намного превышающий нижнюю границу 99 со временем восстановления после сбоев от 10 до 30 с. Конфигурация из 16 узлов обещана, но пока не реализована для MSCS. Реальная масштабируемость приложений в кластере означает наличие динамической балансировки нагрузки узлов, так чтобы с добавлением новых процессоров программное обеспечение оптимально распределялось в расширенной системе. Такой кластер называют производительным кластером (performance cluster). Кластеры под управлением MSCS не являются производительными в полном смысле, поскольку не поддерживают динамической балансировки нагрузки, хотя и дают, в принципе, возможность выполнить ее вручную для двух узлов.
Эффективное управление — это возможность работать отдельно с каждым узлом, вручную отключать его для модернизации или ремонта и также возвращать в работающий кластер, так чтобы пользователи даже не заметили этого. Возможность, в принципе, доступная в каждом полноценном кластерном решении. Более интересно другое — работать с узлами кластера как с единым пулом ресурсов (single-image view), внося необходимые общие изменения с помощью одной операции для всех узлов. Но для этого необходима не просто надстройка кластерного ПО, а реальная его интеграция в операционную систему сервера, как это сделано, например, в кластере для OpenVMS.
Системы кластеризации, как правило, поддерживают средства контроля за кластером в целом. UnixWare Reliant HA, например, имеет графическую консоль Configuration Manager для управления за всей кластерной системой. Более того, возможность работы с кластерами появляется в таких интегрированных управляющих пакетах, как CA-Unicenter и HP OpenView. MSCS, например, может администрироваться посредством модуля управления NT-системами ManageX, интегрированного в OpenView. Однако единый образ кластера не только с точки зрения пользователя и администратора, но и с точки зрения приложений пока не реализован ни в одной из NT-систем.
Наконец, о прозрачности всех приложений для любого кластерного решения пока тоже говорить не приходится. Если UnixWare-приложения могут выполняться без изменения в кластерной среде UnixWare Reliant HA, то процесс интеграции кластерной методологии в важнейшие приложения под NT, в частности, BackOffice, еще только начинается.
Возможно ли достижение идеала в ближайшем будущем? Есть большая вероятность, что да. Одним из кандидатов на роль «идеального кластера» на Intel-платформе является появившееся в середине прошлого года программное решение UnixWare NonStop Cluster, плод совместных усилий компаний SCO и Tandem (ныне подразделение Compaq). Tandem имеет уже более чем двадцатилетний опыт разработки отказоустойчивых систем. UnixWare NonStop Cluster объединяет надежность и отказоустойчивые возможности кластерного решения от Tandem и средства поддержки масштабируемых систем ОС UnixWare.
Это во многих отношениях удачное решение проблем обеспечения высокой готовности, управляемости и масштабируемости, которое основано прежде всего на реализации архитектуры Single System Image (SSI — единый образ системы) и разработанной Tandem высокопроизводительной системной сети ServerNet, которая объединяет узлы кластера на основе технологии коммутации. В настоящий момент возможности ServerNet обеспечивают кластеризацию до шести SMP-серверов на платформе IA-32, но уже в будущем году SCO и Compaq увеличить число узлов до 32 и гарантировать кластеризацию серверов на платформе IA-64, как только начнется их массовый выпуск.
 |
| Рис. Кластеpы UnixWare NonStop. Архитектура SSI |
SSI организует работу узлов в кластере и их представление приложению, пользователю и администратору системы, так как если бы это был один высокопроизводительный SMP-сервер с высоким уровнем доступности. SSI реализует единое пространство имен ОС Unix, благодаря чему приложение, фактически, не требует модификации для работы в кластере. Операционная система UnixWare тиражируется на все узлы кластера, и на каждом узле интегрирована с технологией кластеризации NonStop Clusters. Кластерные службы поддерживают стандартный интерфейс вызова, поэтому в операционную систему не требуется вносить никаких изменений. А приложение осуществляет доступ к кластерным средствам через стандартные системные библиотеки Unix, которые, в свою очередь используют интерфейс сервисных вызовов. И таким образом кластерная конфигурация оказывается совершенно прозрачной для приложений, которые работают как бы с мощным n-процессорным SMP-сервером.
Высокая доступность обеспечивается двумя способами. Во-первых, UnixWare NonStop Clusters поддерживает использование SMP-серверов в качестве узлов. Во-вторых, это собственно возможность восстановления после сбоев технологии NonStop Clusters, а также некоторые элементы обеспечения отказоустойчивости, такие как дублирование в режиме «горячего резерва» ряда аппаратных компонент, напрмер, дисковых накопителей и элементов питания, а также высоконадежные компоненты ядра ОС UnixWare. Архитектура NonStop Clusters поддерживает восстановление приложений после сбоев по принципу «n+1», в соответствии с которым резервная копия приложения может быть перезапущена на нескольких узлах кластера. То есть один узел кластера может выполнять резервные функции для всех остальных узлов. Во многих кластерных решениях, поддерживающих более двух узлов, например, в HP ServiceGuard, реализован подход «1+1», когда каждый активный узел в кластере должен иметь свой собственный резервный сервер.
UnixWare NonStop Clusters допускает динамическое распределение нагрузки как для приложений, так и для сетевого трафика. Это позволяет добиваться оптимальной общей производительности системы, обеспечивает эффективное восстановление в случае сбоя и высокий уровень масштабируемости. Масштабируемости системы способствует также принцип «активной миграции процессов», что означает возможность перенести приложение на любой другой узел между выполнением команд. Таким образом, поддерживается удаление и добавление узлов в кластер в динамическом режиме.
