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

Сложилось так, что кластеризация, будучи неотъемлемой частью мэйнфреймовских систем, очень долго искала свой путь к платформе Intel. Корпоративные серверы, изначально предназначенные для работы в одиночестве, а также главные Intel-ориентированные серверные операционные системы Windows NT и Linux оказались не приспособленными к поддержке совместной работы серверов. А между тем надежности отдельно стоящих машин сегодня недостаточно для поддержки работы таких приложений, как системы онлайновой обработки транзакций, электронной коммерции, СУБД, хранилища данных и системы документооборота.

Рис. 1. Стандартный кластер с двумя узлами

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

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

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

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

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

Типы кластерных конфигураций

Существует несколько вариантов конфигурирования кластерных систем. Разные варианты отвечают требованиям разных приложений и, естественно, различаются по стоимости и сложности реализации. Кластеры строятся по схемам “активный - активный”, “активный - резервный” и SMP (система с симметрично-параллельной обработкой). Широкое применение нашли и так называемые “псевдокластеры” - системы самостоятельных серверов с совместно используемыми подсистемами хранения. Псевдокластеры - это самый дешевый вариант вычислительного комплекса повышенной надежности, однако они не обеспечивают большинства полезных функций кластеров.

Рис. 2. Схема “активный - резервный”

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

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

Рис. 3. Схема “активный - активный”

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

Рис. 4. Схема SMP

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

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

В последнее время наибольшее распространение получила конфигурация “активный - активный”. Два кластера на ее базе были реализованы компанией Trans-Ameritech по заказу МПС. Один из них, установленный в Главном вычислительном центре (ГВЦ), составлен их двух серверов IBM PC Server 325R, соединенных по интерфейсу SCSI и использующих в качестве подсистемы хранения данных RAID-контроллер LynxArray фирмы Artecon.

Второй кластер работает в управлении Белорусского вокзала и состоит из двух IBM Netfinity 5500R и RAID-контроллера Z-9250 производства Digi-Data Corporation.

Оба кластерных решения построены на основе Windows NT с использованием внутренних средств кластеризации Enterprise Edition.

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

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

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

Примером кластерного ПО для Intel-архитектуры является Novell High Availability Server (NHAS) для серверов NetWare. Пожалуй, это одно из самых потенциально широко применимых и дешевых решений для сетей на базе Novell NetWare. NHAS на основе NDS позволяет соединить несколько файл-серверов NetWare в кластер с функциями автоматической реакции на сбои и работы с разделяемыми подсистемами хранения.

Другие известные кластерные продукты для архитектуры Intel выпускают компании Veritas и Compaq; кластерная служба включена и в Windows 2000.

В декабре 1997 г. Compaq, Intel и Microsoft объявили о начале разработки стандарта кластерной архитектуры, основной идеей которого стала возможность объединения в кластеры недорогих массовых серверов. Получивший название Virtual Interface Architecture 1.0, стандарт не зависит от аппаратной, программной и сетевой архитектуры и реализует принцип предоставления пользовательским процессам виртуальных интерфейсов с сетевой средой в кластерной системе. К проекту уже присоединились более ста фирм, в том числе все основные поставщики аппаратных и программных компонентов корпоративных информационных систем, такие, как 3Com, Hewlett-Packard, Oracle и др.

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

Настройка NLB в Windows Server 2012

Компонент балансировки сетевой нагрузки (Network Load Balancing, NLB) в Windows Server 2012 распределяет сетевой трафик по нескольким серверам с помощью протокола TCP/IP. Группируя два и более сервера в единый виртуальный кластер, NLB повышает доступность и масштабируемость серверных приложений.

NLB умеет выполнять балансировку нагрузки любых приложений и служб, использующих сетевой протокол TCP/IP и связанных с определенным TCP- или UDP-портом. Использовать балансировку сетевой нагрузки целесообразно для обеспечения работы приложений, выполняемых без учета состояния, например для веб-, FTP- или служб удаленных рабочих столов (Remote Desktop).

Также NLB может пригодиться и в менее очевидных ситуациях. К примеру, с помощью этого механизма можно обеспечить повышенную избыточность веб-серверов front-end на базе SharePoint 2010, а при использовании Exchange 2010 выравнивание сетевой нагрузки можно применять в целях создания CAS-массивов для роли сервера клиентского доступа (Client Access Server).

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

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

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

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

Выявляют узлы, оставшиеся активными членами кластера;
назначают узел с наивысшим приоритетом узлом по умолчанию;
обеспечивают обработку новых запросов клиентов работающими узлами.

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

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

Установка

NLB устанавливается как стандартный компонент Windows и не требует для запуска и работы каких-либо изменений в оборудовании. Тем не менее при планировании NLB кластера необходимо учесть некоторый моменты:

В кластер может входить до 32 узлов;
Все узлы кластера должны располагаться в одной подсети;
Количество сетевых адаптеров на каждом узле не ограничено, при этом различные узлы могут иметь разное число адаптеров;
Все сетевые адаптеры в одном кластере необходимо использовать либо в одноадресном (Unicast), либо в многоадресном (Multicast) режиме. Балансировка сетевой нагрузки не поддерживает смешанную среду одноадресной и многоадресной рассылки внутри одного кластера;
При использовании одноадресного режима сетевой адаптер, задействованный для нужд кластера, должен поддерживать программное изменение MAC-адреса;
Сетевой адаптер, на котором включается NLB, может использовать только протокол TCP/IP. Нельзя добавлять для этого адаптера другие протоколы (например IPX);
IP-адреса серверов в составе кластера должны назначаться статически. NLB не поддерживает протокол DHCP и отключает его на каждом настраиваемом интерфейсе;
NLB не работает совместно со службой Failover Clustering. Если сервер является частью отказоустойчивого кластера, то задействовать на нем балансировку сетевой нагрузки не получится.

Если все условия соблюдены, то приступаем к развертыванию кластера. Первым делом необходимо установить сам компонент балансировки сетевой нагрузки. Для этого открываем Server Manager и запускаем мастер установки ролей и компонентов. Переходим на вкладку Features и отмечаем компонент Network Load Balancing.

Также NLB можно установить с помощью PowerShell, следующей командой:

Install-WindowsFeature -Name NLB -IncludeManagementTools

Создание нового NLB кластера

Установив компонент NLB приступим к созданию кластера, для чего воспользуемся оснасткой Network Load Balancing Manager. Открыть ее можно из Server Manager, кликнув по кнопке Tools и выбрав соответствующий пункт меню. Как вариант, можно нажать Win+R и ввести команду nlbmgr .

Для создания нового кластера в NLB Manager выбираем пункт Cluster -> New.

В открывшемся окне указываем имя (или IP-адрес) компьютера, которому предстоит стать первым узлом кластера и жмем «Connect». Выбираем сетевой интерфейс, который будет задействован для нужд кластера.

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

Задаем уникальный идентификатор узла (unique host identifier). Это очень важный параметр, с помощью которого устанавливается приоритет при обработке трафика. Узел с наименьшим host ID среди членов кластера на данный момент обрабатывает весь сетевой трафик кластера, не предусмотренный правилами для порта;
Указываем выделенный IP-адрес (Dedicated IP, DIP) — уникальный адрес узла, по которому он будет доступен в сети;
Определяем дефолтное состояние (Default state) узла — запущен (Started), остановлен (Stopped) или приостановлен (Suspended) и указываем, должен ли узел сохранять это состояние при перезагрузке.

Задаем виртуальный IP-адрес кластера (Virtual IP, VIP) — адрес, который будет совместно использоваться всеми узлами в кластере. NLB добавит этот IP-адрес в стек протоколов TCP/IP на выбранном интерфейсе всех узлов, вводимых в состав кластера. При необходимости для одного сетевого интерфейса можно указать несколько IP-адресов.

Задаем имя кластера (Full Internet name) соответствующее указанному IP-адресу. В принципе это имя ни на что не влияет, но правильнее будет вписать сюда FQDN-имя, по которому клиенты будут обращаться к кластеру. Также не забудьте создать в DNS соответствующую запись.

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

Одноадресный (Unicast) — В этом режиме встроенный MAC-адрес физического сетевого адаптера отключается и заменяется МАС-адресом виртуального адаптера кластера. Оба IP-адреса сервера (выделеный IP-адрес сервера и IP-адрес кластера) разрешаются в один единственный МАС-адрес кластера.

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

Многоадресный (Multicast) — В этом режиме NLB преобразует MAC-адрес кластерного адаптера в адрес группы. IP-адрес кластера разрешается в этот адрес групповой рассылки, а выделенный IP-адрес сервера — в оригинальный MAC-адрес адаптера.

При этом у адаптера остается оригинальный, встроенный MAC-адрес, что дает возможность использовать оба IP-адреса: кластера для трафика клиент-кластер, а выделенный для остального сетевого трафика, специфичного для компьютера. Обратите внимание, что режим Multicast обязательно должен поддерживаться сетевым оборудованием, кроме того может потребоваться дополнительная настройка на коммутаторе.

Многоадресный IGMP (IGMP Multicast) — Многоадресный режим с поддержкой протокола групповой передачи данных (Internet Group Management Protocol, IGMP). Включение поддержки IGMP дает возможность ограничить широковещательный трафик, т.е. обеспечить прохождение трафика к NLB-кластеру только через порты, обслуживающие узлы кластера, а не через все порты коммутатора. Для обеспечения этого режима необходимо включить поддержку IGMP на сетевом оборудовании.

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

Переходим к следующему экрану. Настройку правил портов (Port Rules) сейчас производить не будем, поэтому просто жмем «Finish». Первый этап создания NLB кластера завершен.

Добавление узла в кластер

Итак, мы имеем NLB кластер, состоящий из одного узла. Добавим остальные. Kликаем на имени кластера правой клавишей и выбираем пункт «Add Host To Cluster».

Процедура добавления практически аналогична предыдущей. Указываем имя сервера, жмем «Connect» и выбираем сетевой интерфейс, который будет использоваться кластером.

Задаем host ID и указываем выделенный IP-адрес узла, а также состояние узла по умолчанию.

И жмем «Finish». Таким же образом добавляем остальные сервера в кластер.

Создать кластер и добавить в него узлы можно и с помощью PowerShell. Команда для создания кластера:

New-NlbCluster -ClusterName nlb.contoso.com -InterfaseName ″Ethernet″
-ClusterPrimaryIP 192.168.0.10 -SubnetMask 255.255.255.0
-OperationMode Unicast -Force

Для добавления узла в кластер:

Get-NlbCluster | Add-NlbClusterNode SRV5.contoso.com -NewNodeInterface ″Ethernet″ -Force

В результате у нас получился NLB кластер, состоящий из трех узлов.

Настройка параметров кластера

После добавления всех узлов можно приступать к настройке кластера. Кликаем правой клавишей на имени кластера и переходим на пункт «ClusterProperties».

На вкладке Cluster IP Addresses можно изменить существующий адрес кластера или добавить новый. Балансировки сетевой нагрузки позволяет настроить для одного кластера несколько IP-адресов, для каждого адреса назначить собственное имя и настроить правила обработки трафика. Для этого не требуется выделять отдельный адаптер, так что можно настраивать несколько виртуальных NLB кластеров на одном сетевом адаптере.

На вкладке Cluster Parameters можно настроить соответствие имени и IP-адреса кластера и изменить режим его работы.

И на вкладке Port Rules настраиваются правила обработки трафика всеми узлами кластера. При создании кластера создается правило по умолчанию, которое надо изменить, поэтому выделяем его и жмем «Edit».

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

Cluster IP Addresses — IP-адрес кластера, для которого будет действовать это правило. По умолчанию отмечен чекбокс All, что означает воздействие данного правила на все адреса в кластере.

Port Range — диапазон портов, на которых будет обрабатываться трафик кластера. По умолчанию указаны все порты, что не очень правильно. Например, если у вас кластеризовано веб-приложение, использующее для клиентского доступа порт 80 TCP, то указываем этот порт как начало и конец диапазона. Если нужно указать несколько портов, то для каждого придется создать отдельное правило.

Protocols — протоколы, к которым будет применяться данное правило: TCP, UDP или оба.

Filtering Mode — режим фильтрации. Здесь мы указываем, как именно будет обрабатываться трафик кластера. Можно выбрать из двух режимов:

1) Multiple host — трафик по указанным портам будет распределяться среди всех узлов кластера. В этом случае нужно выбрать режим сходства (affinity), который определяет привязку клиента к определенному узлу кластера:

  • None — привязка не используется. Все новые соединения распределяются по разным узлам в зависимости от нагрузки;
  • Single — привязка осуществляется по IP-адресу клиента. После того, как клиент осуществил подключение к определенному узлу кластера, в течение установленного сеанса все новые соединения с его IP будут направлены на тот же узел кластера;
  • Network — привязка основана на принадлежности клиента к определенной частной подсети. Когда один клиент устанавливает соединение к некоторому узлу, все соединения из этой подсети будут направлены на тот же узел.

Также обратите внимание на чекбокс Timeout minutes. Установка галки включает режим расширенного сходства (Extended Affinity), который обеспечивает привязку в отсутствие активных текущих подключений от клиента к узлу, а также позволяет клиентам сохранять соответствие с узлом при изменении конфигурации кластера. Здесь мы можем указать время, в течение которого клиент будет привязан к определенному узлу при отсутствии активного текущего подключения с его стороны.

2) Single host — весь трафик по указанным портам будет обрабатываться одним узлом кластера, а если этот узел недоступен — то направлен на следующий узел, вычисляемый по номеру Handling Priority (приоритет обработки). Приоритет присваивается узлу при добавлении сервера в кластер и может быть изменен в свойствах узла.

Disable this Port Range — отметив этот пункт, мы запретим обработку трафика на указанных портах. Как я уже говорил, весь сетевой трафик, не подпадающий под действие правил портов, обрабатывается действующим узлом кластера с минимальным идентификатором хоста. Чтобы избежать ненужной нагрузки, весь нецелевой трафик можно запретить. Так в случае с 80 портом достаточно создать 2 правила и запретить весь трафик на портах 0-79 и 81-65535.

При создании правил порта нужно учесть, что:

Правила на всех узлах кластера должны быть идентичны. При попытке присоединить к кластеру узел с иными правилами или с другим числом правил он не будет принят в кластер;
Чтобы балансировка сетевой нагрузки корректно обрабатывала IP-фрагменты, не следует использовать значение None для сходства, если выбран протокол UDP или Both;
Если NLB используется для балансировки нагрузки трафика VPN (напр. PPTP/GRE или IPSEC/L2TP), то для правил порта используйте режим сходства Single или Network.

Настройка параметров отдельного узла

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

В окне Host Parameters мы сможем:

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

Также заглянем в правила портов. Здесь нас интересуют два пункта:

Load Weight — процент нагрузки. В режиме фильтрации Multiple Hosts параметр Load Weight используется для того, чтобы задать процент трафика, который должен обрабатываться этим узлом по соответствующему правилу . По умолчанию используется вариант Equal , при котором происходит равномерное распределение нагрузки между всеми узлами кластера. Чтобы задать для узла определенный процент, нужно убрать галку и указать значение от 1 до 100. Значение 0 вообще исключает данный узел из обработки трафика.

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

Handling Priority — приоритет обработки трафика в режиме фильтрации Single host. Этот параметр указывает приоритет узла для трафика по данному правилу. Узел с наиболее высоким приоритетом будет обрабатывать весь трафик для этого правила, а при его недоступности трафик будет перенаправлен на следующий по приоритетности узел. Чем меньше значение Handling Priority, тем выше приоритет, значение 1 соответствует наиболее высокому приоритету.

Управление кластером

И немного об управлении кластером NLB. Управление можно осуществлять как на уровне отдельного узла, так и на уровне всего кластера. Для управления узлом кликаем на нем и выбираем «Control Host». Дальше на выбор, можно:

Start — запустить обработку трафика на данном узле;
Stop — остановить обработку трафика на данном узле. При этом все текущие соединения будут закрыты;
Drainstop — остановить обработку трафика на узле, предварительно обработав все текущие подключения. В этом варианте остановки узел обрабатывает текущие клиентские подключения, но не принимает новых;
Suspend — приостановить обработку трафика на данном узле;
Resume — соответственно возобновить приостановленную работу.

Для того, чтобы совсем удалить узел из кластера, надо выбрать пункт «Delete Host».

Выбрав пункт «Control Ports» можно управлять действием правил: включить (Enable), отключить (Disable) или приостановить обработку новых подключений (Drain). Это может потребоваться для того, чтобы временно исключить узел из обработки трафика кластера, например в целях диагностики.

Все то же на уровне кластера — кликаем на имени кластера и выбираем «Control Hosts». Здесь изменения применяются уже ко всем узлам.

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

1) Не смотря на название, NLB не отслеживает реальную загрузку (потребление процессорного времени, памяти, дисковой подсистемы и т.д.) на каждом узле. Под нагрузкой в NLB подразумевается только количество активных подключений к узлу. Учитывайте этот момент при настройке распределения нагрузки.
2) NLB не обеспечивает отказоустойчивость клиентских приложений. Механизм NLB отслеживает только наличие сигналов heartbeat между узлами, мониторинг отдельных служб он не осуществляет. Проще говоря, если на одном узле кластера отвалится клиентский сервис, а сетевой интерфейс останется доступен, то NLB этого не заметит и продолжит отправлять клиентов на неработоспособный узел.
3) Как в режиме Unicast, так и в Multicast (за исключением IGMP) трафик кластера распространяется по всем портам коммутатора. Чтобы изолировать этот широковещательный трафик, все IP адреса кластера желательно вынести в отдельную подсеть.
4) Вопреки расхожему мнению режим Unicast можно использовать даже при наличии одного сетевого адаптера на узле. При этом узлы вполне нормально могут общаться между собой, так как NLB преобразует ARP-таблицу внутри каждого узла, назначая каждому узлу уникальный MAC-адрес. А вот снаружи подключиться к узлу кластера не получится, для управления узлом к нему необходим физический доступ либо механизм удаленного управления типа iLo от HP.

Кластеры серверов


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

Высокая доступность
Доступность услуги не ниже 100% даже при простое серверов

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

Надежное техническое обеспечение
Качественное оборудования мирового класса в безопасных дата-центрах

Серверы и системы хранения доступны клиенту полностью оборудованные, с востребованным количеством процессоров, объёмом оперативной памяти и места для жесткого диска, обеспечив также необходимую сетевую инфраструктуру. В основе каждого решения лежат технические требования клиента. Установить кластер серверов, как правило, занимает всего нескольких рабочих дней – система хранения данных в дата-центре уже предустановлены и нуждаются лишь в дополнительных настройках под требования клиента. Важно отметить, что доступ к кластеру возможен из любой точки мира - необходимо лишь иметь стабильное подключение к интернету. Все данные и приложения находятся в серверах, расположенных в безопасных дата-центрах DEAC в Рига, а также в стратегических точках локации в Стокгольме, Киеве, Лондоне, Амстердаме, Москве и Франкфурте.

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

Платформа аналитики «больших данных»

Выберите системы аналитики «больших данных» Hadoop , Apache Spark , Apache Storm или Disco для эффективной обработки больших объемов информации. Данные платформы позволяют анализировать огромные массивы данных параллельно, используя кластеризацию серверов. Платформы распределенных вычислений позволяют распределить «большие данные» на несколько узлов внутри кластера типовых серверов. Тем самым вам не нужно покупать и поддерживать дорогостоящее специализированное оборудование. DEAC предоставляет полностью настроенные кластеры для запуска любого из упомянутых проектов с открытым исходным кодом, а также для других приложений на базе выбранной платформы.

Приобретайте Hadoop-платформу уже сегодня по специальной цене!

Сервер: 1хHP DL320 Gen8, 1xE3-1240v2, 16ГБ RAM, 1x1ТБ SATA, 2x1GE, SPS

Сеть: 1х1GE порт включен

Трафик: 1х100 Мбит/с интернет включен (без лимита и без замеров)

IPv4: 1 включена

Индекс скорости процессора (CPU Score ): 9153


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


Сферы применения
серверных кластеров

Как работает кластер
серверов?

Основные компоненты
кластера серверов


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

  • Э-коммерция
  • Онлайн казино и букмекеры
  • Предприятия, которые содержат базы данных
  • Медицинская отрасль
  • Финансовые компании и фондовые биржи
  • Кредитование и страхование
  • Разработка и тестирование программного обеспечения


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

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


Каждый вычислительный кластер отличается компонентами и системой внутреннего контроля. Такие компоненты, как Database manager (менеджер баз данных), Node manager (менеджер узлов) и Failover manager (менеджер аварийного переключения) работают вместе для достижения максимальной производительности.

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

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

    Failover manager управляет зависимостями ресурсов, запуском ресурсов и инициирует аварийное переключение групп ресурсов.


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

Пресс-центр

Создание кластера на базе Windows 2000/2003. Шаг за шагом

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

Microsoft Windows 2000/2003 поддерживает две технологии кластеризации: кластеры с балансировкой нагрузки (Network Load Balancing) и кластеры серверов.

В первом случае (кластеры с балансировкой нагрузки) служба Network Load Balancing придает службам и приложениям свойства высокого уровня надежности и масштабируемости за счет объединения до 32 серверов в единый кластер. Запросы от клиентов в данном случае распределяются среди узлов кластера прозрачным образом. При отказе узла кластер автоматически изменяет свою конфигурацию и переключает клиента на любой из доступных узлов. Этот режим конфигурации кластера также называется active-active режимом, когда одно приложение работает на нескольких узлах.

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

Кластерный подход к организации внутренней сети дает следующие преимущества:

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

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

Требования к программному обеспечению

  • Microsoft Windows 2000 Advanced (Datacenter) Server или Microsoft Windows 2003 Server Enterprise Edition, установленные на всех серверах кластера.
  • Установленная служба DNS. Немного поясню. Если вы строите кластер на основе двух контроллеров домена, то намного удобнее использовать службу DNS, которую вы в любом случае устанавливаете при создании Active Directory. Если вы создаете кластер на основе двух серверов, членов Windows NT домена, то вам придется использовать либо службу WINS, либо заносить соответствие имен и адресов машин в файл hosts.
  • Terminal Services для удаленного управления серверами. Не обязательно, но при наличии Terminal Services удобно управлять серверами со своего рабочего места.

Требования к аппаратному обеспечению

  • Аппаратное обеспечение для узла кластера лучше подбирать, основываясь на Cluster Service Hardware Compatible List (HCL). По рекомендациям Microsoft аппаратное обеспечение должно быть протестировано на совместимость с Cluster Services.
  • Соответственно вам понадобятся два сервера, имеющих по два сетевых адаптера; SCSI-адаптер, имеющий внешний интерфейс для подключения внешнего массива данных.
  • Внешний массив, имеющий два внешних интерфейса. Каждый из узлов кластера подключается к одному из интерфейсов.

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

Требования к сетевым настройкам

  • Уникальное NetBIOS имя для кластера.
  • Пять уникальных статических IP-адресов. Два для сетевых адаптеров на кластерную сеть, два для сетевых адаптеров на общую сеть и один для кластера.
  • Доменная учетная запись для кластерного сервиса (Cluster service).
  • Все узлы кластера должны быть либо member server в домене, либо контроллерами домена.
  • Каждый сервер должен иметь два сетевых адаптера. Один для подключения в общую сеть (Public Network), второй для обмена данными между узлами кластера (Private Network).

Замечание: по рекомендациям Microsoft ваш сервер должен иметь два сетевых адаптера, один для общей сети, второй для обмена данными внутри кластера. Можно ли строить кластер на одном интерфейсе - наверное, да, но я не пробовал.

Установка кластера

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

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

Установка двухузлового кластера может быть разделена на 5 шагов

  • Установка и настройка узлов в кластере.
  • Установка и настройка разделяемого ресурса.
  • Проверка дисковой конфигурации.
  • Конфигурирование первого узла кластера.
  • Конфигурирование второго узла в кластере.

Это пошаговое руководство позволит вам избежать ошибок во время установки и сэкономить массу времени. Итак, начнем.

Установка и настройка узлов

Мы немного упростим задачу. Поскольку все узлы кластера должны быть либо участниками домена, либо контроллерами домена, то корневым держателем каталога AD (Active Directory) сделаем 1-й узел кластера, на нем же будет работать DNS-служба. 2-й узел кластера будет полноправным контроллером домена.

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

Сетевые настройки

Перед началом установки кластера и Active Directory необходимо выполнить сетевые настройки. Все сетевые настройки хочется разделить на 4 этапа. Для распознавания имен в сети желательно иметь DNS-сервер с уже существующими записями о серверах кластера.

Каждый сервер имеет по две сетевые карты. Одна сетевая карта будет служить для обмена данными между узлами кластера, вторая будет работать на клиентов в нашей сети. Соответственно первый назовем Private Cluster Connection, второй назовем Public Cluster Connection.

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

  • My Network Places → Properties

    • Private Cluster Connection → Properties → Configure → Advanced

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

  • Internet Protocol (TCP/IP) → Properties → Use the following IP: 192.168.30.1

    (Для второго узла используйте адрес 192.168.30.2). Введите маску подсети 255.255.255.252 . В качестве адреса DNS-сервера для обоих узлов используйте адрес 192.168.100.1 .

  • Дополнительно на вкладке Advanced → WINS выберите пункт Disabled NetBIOS over TCP/IP . Для настроек сетевых адаптеров общей (Public) сети этот пункт опустите.
  • Проделайте то же самое с сетевой картой для локальной сети Public Cluster Connection. Используйте адреса, приведенные в таблице. Единственная разница в конфигурации двух сетевых плат состоит в том, что для Public Cluster Connection не требуется выключения режима WINS - NetBIOS over TCP/IP .

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

Узел Сетевое имя IP address MASK DNS Server
1 Public Cluster Connection 192.168.100.1 255.255.255.0 192.168.100.1
1 Private Cluster Connection 192.168.30.1 255.255.255.252 192.168.100.1
2 Public Cluster Connection 192.168.100.2 255.255.255.0 192.168.100.1
3 Private Cluster Connection 192.168.30.2 255.255.255.252 192.168.100.1

Установка Active Directory

Поскольку моя статья не преследует цель рассказать об установке Active Directory, то этот пункт я опущу. Всевозможных рекомендаций, книг об этом написано достаточно много. Выберете доменное имя, вроде mycompany.ru, установите Active Directory на первом узле, добавьте второй узел в домен в качестве контроллера домена. Когда все сделаете, проверьте конфигурации серверов, Active Directory.

Установка Cluster User Account

  • Start → Programs → Administrative Tools → Active Directory Users and Computers
  • Добавьте нового пользователя, например, ClusterService.
  • Установите флажки на: User Cannot Change Password и Password Never Expires .
  • Также добавьте этого пользователя в группу администраторов и дайте ему права Log on as a service (права назначаются в Local Security Policy и Domain Controller Security Policy ).

Настройка внешнего массива данных

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

  1. Оба сервера должны быть выключены, внешний массив включен, подсоединен к обоим серверам.
  2. Включаем первый сервер. Получаем доступ к дисковому массиву.
  3. Проверяем, чтобы внешний дисковый массив был создан как Basic. Если это не так, то переведем диск с помощью опции Revert to Basic Disk .
  4. Создаем на внешнем диске через Computer Manage-ment → Disk Management небольшой раздел. По рекомендациям Microsoft он должен быть не менее 50 Мб. Я рекомендую создать раздел в 500 Мб. или чуть больше. Для размещения кластерных данных этого вполне достаточно. Раздел должен быть отформатирован в NTFS.
  5. На обоих узлах кластера этот раздел будет назван одной буквой, например, Q. Соответственно при создании раздела на первом сервере выберем пункт Assign the following drive letter - Q .
  6. Оставшуюся часть диска вы можете разметить по своему желанию. Конечно, крайне желательно использовать файловую систему NTFS. Например, при настройке служб DNS, WINS основные базы служб будут перенесены на общий диск (не системный том Q, а второй, созданный вами). И по соображению безопасности вам будет удобнее использовать именно NTFS-тома.
  7. Закрываем Disk Management и проверяем доступ к вновь созданному разделу. Например, можно создать на нем текстовый файл test.txt , записать и удалить. Если все прошло нормально, то с конфигурацией внешнего массива на первом узле мы закончили.
  8. Теперь выключаем первый сервер. Внешний массив должен быть включен. Включаем второй сервер и проверяем доступ к созданному разделу. Также проверим, чтобы буква, назначенная первому разделу, была идентична выбранной нами, то есть Q.

На этом конфигурация внешнего массива завершена.

Установка Cluster Service Software

Конфигурация первого узла кластера

Перед началом установки Cluster Service Software все узлы кластера должны быть выключены, все внешние массивы должны быть включены. Перейдем к конфигурации первого узла. Внешний массив включен, первый сервер включен. Весь процесс установки происходит с использованием Cluster Service Configuration Wizard:


Конфигурация второго узла кластера

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

  1. В диалоговом окне Create or Join a Cluster выберите The second or next node in the cluster и нажмите далее.
  2. Введите имя кластера, которое мы задали ранее (в примере это MyCluster), и нажмите далее.
  3. После подключения второго узла к кластеру Cluster Service Configuration Wizard автоматически заберет все установки с основного узла. Для запуска службы Cluster Service используйте имя, которые мы создавали ранее.
  4. Введите пароль вашей учетной записи и нажмите далее.
  5. В следующем диалоговом окне нажмите Finish для завершения установки.
  6. Cluster service будет запушен на втором узле.
  7. Закройте окно Add/Remove Programs .

Для установки дополнительных узлов кластера используйте эту же инструкцию.

Постскриптум, благодарности

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

Шаг Узел 1 Узел 2 Внешний массив

17.06.1997 Элизабет Кларк

Кто сказал, что меньше - лучше? Когда речь идет об объединении серверов, цифры говорят сами за себя. ТЬМА - ЗНАЧИТ МНОГО ПЛОТНОСТЬ НАСЕЛЕНИЯ НОВОЕ ПЛЕМЯ РАСЧИЩАЯ ПУТЬ ВЫЖИВАНИЕ НАИБОЛЕЕ ПРИСПОСОБЛЕННЫХ СЕКРЕТНОЕ ОРУЖИЕ

Кто сказал, что меньше - лучше? Когда речь идет об объединении серверов, цифры говорят сами за себя.

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

ТЬМА - ЗНАЧИТ МНОГО

Сначала в кластеры объединяли мэйнфреймы, затем мини-компьютеры, а теперь серверы на базе операционной системы Unix и процессоров Intel. Компания Tandem была среди первых, кто занялся кластеризацией: она начала выпускать серверы NonStop Himalaya еще двадцать лет назад. За это время Digital Equipment изобрела кластеризацию систем VAX под ОС VMS. IBM была также в числе первопроходцев со своим кластерным оборудованием для систем AIX и мэйнфреймов.

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

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

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

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

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

Несмотря на то что каждая из этих архитектур имеет свои достоинства, настоящая кластеризация существует только в средах с разделяемыми дисками и без разделения ресурсов (см. Рисунок 1).

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

Тенденция к кластеризации обусловлена целым рядом причин. Одна из них в том, что старое правило 80/20, утверждающее, что 80% сетевого трафика является локальным и лишь 20% передается по магистрали, больше не действует. С увеличением объемов трафика, передаваемого все дальше и дальше от места его возникновения, серверные фермы, или группы кластеризованных серверов, подключенных к высокоскоростным магистралям, становятся все более искусными в обслуживании этих изменившихся схем трафика.

Другой фактор роста популярности кластеризации - Internet с ее высокими требованиями к пропускной способности и производительности. Это привело к потребности в более мощных аппаратных и программных решениях. К тому же, по мере того как серверы Web и другие мультимедийные продукты становятся функционально разнообразнее и сложнее, серверы должны работать еще быстрее.

Кроме того, число приложений, для которых одиночный сервер может оказаться чересчур медленным, растет. "Кластеризация становится все важнее не только для высококритичных приложений, где высокий уровень отказоустойчивости просто необходим, но также для масштабных бизнес-приложений, поддерживающих крупные популяции пользователей, - говорит Брайан Ричардсон, директор по программе открытых вычислений и серверных стратегий в Meta Group. - С ростом размера системы тенденция к кластеризации проявляется все сильнее".

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

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

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

ТАБЛИЦА 1 - ПРОЦЕНТ СИСТЕМ ВЫСОКОЙ ГОТОВНОСТИ В СЕВЕРНОЙ АМЕРИКЕ

Источник: Dataquest

ПЛОТНОСТЬ НАСЕЛЕНИЯ

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

При кластеризации резервные серверы продолжают работать и выполнять обычные повседневные функции помимо подмены аварийных серверов. Кроме того, кластеризация защищает как от аппаратных, так и программных сбоев. "Значение этого фактора возрастает по мере того, как программные проблемы вызывают все большее число сбоев, а оборудование становится все более надежным", - говорит Марти Миллер, менеджер линии продуктов в NetFrame. Продукт этой компании - Cluster Data - призван сократить время простоев, обусловленных сбоем операционной системы.

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

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

Тем не менее Митч Шультц, директор по маркетингу серверных платформ в группе корпоративных серверов компании Intel, утверждает, что возможности масштабируемости выглядят весьма многообещающе. По мнению Шультца, пределы для масштабируемости систем на базе стандартных высокопроизводительных вычислительных элементов с высокоскоростными межсоединениями если и есть, то достигнуты они будут нескоро. "Нет никакого смысла рассматривать несовместимое решение при любом уровне масштабируемости, когда вы можете купить стандартные переносимые компоненты, - говорит он. - Наличие таких компонентов является ключом к кластеризации серверов".

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

"Кластеризация - пока еще недостаточно зрелая технология, - говорит Джо Баркан, директор по исследованиям в Gartner Group. - Если целью является масштабируемость, то сначала лучше попробовать масштабировать систему с помощью SMP. К следующему году NT должна стать гораздо более надежной по части постоянно доступных приложений и сервисов. В отношении масштабируемости картина отличается радикальным образом, причем изменится она не так скоро. Даже если говорить о масштабируемости Unix, сегодня в первую очередь я бы все же порекомендовал именно крупные системы SMP".

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

Кроме того, своего разрешения требуют и некоторые вопросы управления кластером. Вот что говорит по этому поводу Стив Трамак, менеджер по продуктам в отделе персональных компьютеров Digital Equipment, отвечающий за кластеризацию Windows NT: "Когда организация решает создать кластер, она ожидает, что он будет управляемым - не только в смысле определения групп взаимозаменяемых серверов и специфичных для кластера событий, но также, например, в смысле оповещения в случае сбоя". А значит, управление на базе SNMP просто необходимо.

Еще одно препятствие на пути кластеризации - управление одновременным доступом к файлам. Эта проблема может быть разрешена с помощью распределенного блокиратора (Distributed Lock Manager, DLM) для координации доступа различных приложений к файлам. Сервис DLM выполняет свою задачу посредством отслеживания ссылок на ресурсы в кластере. Если две или более системы пытаются получить доступ к одному и тому же ресурсу одновременно, DLM разрешает конфликт между ними.

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

Боб Блатц, менеджер по маркетингу в Digital, отвечающий за поддержку продуктов Microsoft, обращает внимание на другой важный фактор для распространения кластерных технологий. "Наверно, важнейшая проблема, о которой мне постоянно приходится слышать, - реализация приложений в кластерной среде. Пока еще не накоплено достаточно опыта работы с такими приложениями, в частности, в среде NT. Но со временем, по мере того как пользователи ознакомятся и приобретут опыт в кластерных технологиях, фаза реализации будет проходить гораздо проще и быстрее", - считает Блатц.

НОВОЕ ПЛЕМЯ

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

Наиболее известный кластерный продукт - Wolfpack for Windows NT компании Microsoft с его комплектом программ и API для кластеризации серверов Windows NT. Microsoft планирует представить Wolfpack в два этапа. Первый этап должен был завершиться летом этого года; он состоит в реализации кластеризации двух серверов с возможностями подмены одного сервера другим. Второй этап, реализовать который Microsoft намеревается в 1998 году, должен воплотить в жизнь распределение нагрузки и кластеризацию до 16 узлов.

Такие поставщики, как Compaq, Digital Equipment, Hewlett-Packard, IBM, Tandem и NCR, разрабатывают совместимые с Wolfpack кластерные продукты самостоятельно. Amdahl, Siemens, Fujitsu и Stratus собираются взяться за свои планы разработки уже в этом году. При такой поддержке Wolfpack наверняка станет стандартом де факто.

Несмотря на то что на первом этапе Wolfpack будет обеспечивать кластеризацию только двух серверов, по глубокому убеждению Баркана из Gartner Group, Microsoft уже смотрит вперед, отчасти по практическим соображениям: "Мы обратили внимание на то, что Microsoft начинает позиционировать Wolfpack как решение старшего класса, - говорит он. - Они не готовы поддерживать сотни тысяч крошечных кластеров Wolfpack по всему миру".

Wolfpack имеет уже значительное влияние на рынок постоянно доступных серверов, в том числе и в области цен. "До недавнего времени, если вам нужна была постоянная доступность вашего кластера, то надо было тратить огромные деньги, - замечает Баркан. - По нашим оценкам, в случае кластеров Unix заказчик тратит в среднем около 50 000 долларов за профессиональные услуги по запуску, эксплуатации и тестированию системы. NT снижает стоимость кластера, по крайней мере потенциально, до приемлемого уровня. И это сделала Microsoft со своим Wolfpack".

Как же на это реагируют другие игроки на рынке кластеризации? Digital Clusters for Windows NT появились на сцене в 1996 году, и, кроме того, Digital представила свои Unix TruCluster Solutions. Последний продукт позволяет осуществлять кластеризацию как серверов AlphaServer самой компании, так и других серверов разных размеров.

Другая заметная фигура в истории кластеризации, Tandem, внесла свою лепту в виде серверов NonStop Himalaya на базе массовых параллельных систем. Некоторые части технологии Wolfpack компании Microsoft базируются на коде, который Tandem использовала в своих системах Himalaya.

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

Тим Кифавр, менеджер по кластерным продуктам в подразделении систем для Windows NT компании Tandem, говорит, что, когда начнутся поставки Wolfpack, Tandem будет предлагать активную/активную динамическую библиотеку SQL Server 6.5. (В данном контексте "активная/активная" означает систему, в которой оба узла в кластере могут выполнять транзакции SQL Server одновременно.)

Технология кластеризации компании Sun Microsystems под названием Full Moon станет отличным дополнением к таким продуктам Sun Clusters, как Solstice HA и Ultra Enterprise PDB (Parallel Database). Этот подход предполагается реализовать в четыре этапа. Первый этап, начало которому положено весной 1997 года, состоял во включении кластерных API, функций восстановления после аварий и усовершенствованного доступа в Internet посредством Solstice HA 1.3.

Технология NetWare SFT (System Fault Tolerance) компании Novell появилась достаточно давно. С помощью SFT пользователи могут зеркально копировать содержимое основного системного диска на запасной. Относительно новая версия SFT III позволяет дуплексировать целые серверы, обеспечивая подмену без перерыва в работе. По заявлениям компании, она собирается добавить новые возможности в SFT III в этом году.

"Мы не называем SFT III технологией кластеризации, хотя, по моему мнению, у нас есть на это все основания, - говорит Майкл Брайант, директор по маркетингу Wolf Mountain, инициативы Novell в области кластеризации. - Novell не собирается придавать новый смысл кластеризации. Мы придерживаемся классического определения и переносим его на серверы на базе ПК". Во время написания статьи Novell еще не объявила о дате выхода Wolf Mountain.

Подходя к кластеризации с разных сторон, IBM представила в прошлом году свое решение Cluster Internet PowerSolution for AIX. Весьма любопытно, что компания объявила также о

планах переноса своей технологии кластеризации Phoenix на платформу Windows NT. Ожидаемый продукт IBM под названием HACMP (High-Availability Cluster Multiprocessing) Geo должен позволить создавать постоянно готовые кластеры из удаленных мест.

NetServer представляет базовую кластерную платформу Hewlett-Packard. Компания может извлечь значительную выгоду из своих усилий по интеграции Wolfpack с системой управления OpenView.

Среди других компаний, которые имеют (или разрабатывают в настоящее время) решения по кластеризации, - NCR, Compaq, SCO, Data General и Stratus.

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

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

Примерами кластерного промежуточного программного обеспечения могут служить Parallel Server компании Oracle и ServerWare компании Tandem. Microsoft объявила, что она собирает-ся предложить кластерную версию SQL Server и других приложений BackOffice; независимые поставщики также намереваются предложить кластерные приложения.

РАСЧИЩАЯ ПУТЬ

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

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

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

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

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

Использование нескольких хост-адаптеров SCSI часто способствует значительному повышению производительности. Быстрые диски также способны помочь ускорить работу сервера, однако здесь, с точки зрения цена/производительность, отдача весьма невелика. Кроме того, обычный интерфейс SCSI может поддерживать только определенное число дисков. Современные интерфейсы, такие как SCSI-3, Ultra SCSI и Fibre Channel, имеют более высокую пропускную способность, чем SCSI-2.

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

На примере серверов Web прекрасно видно, какую нагрузку современные приложения возлагают на ЦПУ. Хотя простое обслуживание страниц Web не сопряжено само по себе с интенсивными операциями ввода/вывода, другие функции, такие как шифрование и дешифрование, могут потребовать всех ресурсов ЦПУ.

Архитектура интеллектуального ввода/вывода (Intelligent I/O) призвана разрешить проблему истощения вычислительной мощности ЦПУ. В модели I2O драйверы разделены на две группы: одна - для обслуживания операционной системы, а другая - для обслуживания аппаратных устройств. I2O освобождает ЦПУ, память и системную шину от большей части операций по обслуживанию ввода/вывода и возлагает их на саму подсистему ввода/вывода. Целый ряд компаний объединили свои усилия по стандартизации архитектуры I2O. (Дополнительную информацию см. во врезке , а также на узле www.I2O.org .)

Компания Wind River Systems разработала операционную систему реального времени IxWorks на базе модели с раздельными драйверами. ОС, являющаяся частью среды разработки I2O под названием Tornado, предполагает написание только одного драйвера для каждого аппаратного устройства, при этом один и тот же драйвер пригоден для всех сетевых ОС.

Особого внимания заслуживают усилия по стандартизации архитектуры виртуального интерфейса Virtual Interface Architecture. Участниками данной инициативы являются Compaq, HP, Intel, Microsoft, Novell, Santa Cruz Operation и Tandem. Целью этой инициативы является определение стандартов на аппаратные и программные интерфейсы для кластеров. Данные интерфейсы разрабатываются для упрощения процесса синхронизации, поддержки коммуникаций с разделяемыми массивами дисков и коммуникаций между серверами. Спецификация будет независима от среды передачи, процессоров и сетевой операционной системы.

"Архитектура VI описывает, как этот [аппаратный и программный] коммуникационный канал будет работать, - говорит Марк Вуд, менеджер по продуктам в команде Windows NT Server компании Microsoft. - Как только все согласятся на бумаге, как она должна работать, любой поставщик сможет проектировать совместимое аппаратное и программное обеспечение".

Генри из Tandem также полагает, что архитектура VI будет немало способствовать развитию кластеризации. Эта инициатива громогласно призывает: "Давайте облегчим программистам разработку программного обеспечения для кластеров", - говорит Генри.

Однако далеко не все относятся с тем же энтузиазмом к архитектуре VI. "Мы ничего хорошего от нее не ждем, - заявляет Ричардсон из Meta Group. - Microsoft просто собирается придать статус стандарта своим, ею же выбранным для среды NT, API, а другие поставщики систем будут вынуждены подстраиваться под них или идти на риск выпуска нестандартных расширений".

ВЫЖИВАНИЕ НАИБОЛЕЕ ПРИСПОСОБЛЕННЫХ

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

"Дайте срок, и кластеризация станет базовой составляющей операционной системы, - полагает Баркан из Gartner Group. - Через пять лет любая операционная система на рынке будет иметь базовые кластерные сервисы".

Баркан высказал и мнение о цене кластерных решений: "Со временем с помощью кластеризации стоимость обеспечения постоянной доступности опустится до уровня потребительских цен, а это означает, что постоянно доступный кластер можно будет создать меньше чем за 50 000 долларов".

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

Однако Баркан предостерегает от поспешных действий: "Главное - не следует торопиться. Кластеризация постепенно становится фактом нашей жизни, но параметры масштабируемости, по сути, неизвестны и непроверены".

Ричардсон из Meta Group согласен с этим мнением. "Мы приветствуем кластеры как средство повышения доступности приложений, - говорит он. - Но, думается, как решение проблемы масштабируемости приложений кластеры чересчур сложны и неэффективны".

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

Элизабет Кларк - старший редактор Network Magazine. С ней можно связаться по адресу: [email protected] .

СЕКРЕТНОЕ ОРУЖИЕ КЛАСТЕРНЫХ ТЕХНОЛОГИЙ

Переход к коммутации

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

Одной из разработок в этой области - ServerNet компании Tandem. Продукт имеет коммутирующую структуру на базе интегральных схем ASIC: она-то и позволяет создавать масштабируемую архитектуру кластерной среды. "Интегральная схема ASIC не только является многонаправленным коммутатором, но и содержит всю логику маршрутизации, логику проверки ошибок, логику сообщений об ошибках и логику обеспечения правильной последовательности пакетов", - говорит Джим Генри, директор по разработкам для бизнеса в подразделении ServerNet компании Tandem. По мнению Джима, несколько коммутаторов ServerNet могут составлять каскад, в результате чего заказчик получит очень крупную коммутирующую сеть или структуру, к которой он может подключить и серверы Windows NT, и массивы RAID.

Однако это далеко не единственная технология коммутации для кластеризации серверов. Например, SilkWorm компании Brocade Communications Systems представляет собой гигабитный коммутатор Fibre Channel с числом портов от 2 до 16 со встроенным программным обеспечением для создания структуры Fibre Channel (архитектуры межсоединения узлов в кластере). Система эта создавалась для ликвидации узких мест в каналах к дисковым подсистемам серверов. SilkWorm имеет сервис для идентификации подключенных к структуре узлов, причем он распространяет информацию об их местоположении и характеристиках другим коммутаторам в структуре.

Постоянно доступная система PowerSwitch/NT компании Apcon базируется на SCSI Switch. До 16 серверов может быть объединено в одну группу и подключено к общему дисковому массиву и другой периферии. При обнаружении сбоя сервера другой сервер автоматически подключается через SCSI Switch к внутренним дисководам и периферии вышедшего из строя сервера.

ДВУСТУПЕНЧАТЫЕ ДРАЙВЕРЫ УСТРОЙСТВ ОБЛЕГЧАЮТ ВВОД/ВЫВОД

Разделение ради объединения

А вы устаете в конце рабочего дня? Так что же пенять на многострадальные процессоры в кластере серверов! Эти трудолюбивые устройства бомбардируют прерываниями для выполнения операций ввода/вывода практически беспрестанно. При добавлении все новых и новых функциональных возможностей эта нагрузка на процессоры вряд ли уменьшится в обозримом будущем.

"Требования к вводу/выводу многократно возросли, в частности, в связи с появлением Internet, - объясняет Паулин Шульман, менеджер по продуктам в Wind River Systems. Эта компания разработала операционную систему на базе архитектуры интеллектуального ввода/вывода (Intelligent I/O, I2O) с раздельными драйверами. - Но возможности ввода/вывода значительно отстают от этих требований".

Если Intelligent I/O Special Interest Group претворит в жизнь свои усилия, то разрыв между требованиями и возможностями будет ликвидирован уже в ближайшем будущем. Данная организация предложила недавно спецификацию на базе архитектуры I2O. В принятой модели с разделением драйверов ЦПУ память и системная шина освобождены от выполнения некоторых функций.

Формально группа приняла версию 1.5 спецификации в марте 1997 года. Эта версия поддерживает одноранговую технологию, с помощью которой устройства ввода/вывода могут общаться друг с другом непосредственно без участия ЦПУ и независимо от сетевой операционной системы.

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

Microsoft объявила о своих планах включения I2O в Windows NT 5.0, а Novell также заявила о намерении реализовать эту технологию в своих продуктах.

В настоящее время о совместимости своих продуктов с I2O заявляют такие компании, как Xpoint Technologies, разработавшая решение на базе I2O для ускорения обмена данными между дисковой и локально-сетевой подсистемами, а также NetFrame, чей постоянно доступный сервер ClusterSystem 9000 (NF9000) на базе Pentium Pro совместим с Windows NT и IntranetWare. Кроме того, в этот список может быть включена и компания American Megatrends, создатель предназначенных для кластеров комплектов RAID на материнской плате для производителей серверов.