сделать вывод, что это программное обеспечение действительно создает некоторые преимущества для NT Server, минимизируя время простоя сети. Однако предложенное Microsoft программное обеспечение для кластеризации NT обладает ограниченными возможностями распределения нагрузки.
На начальном этапе WolfPack будет поддерживать кластеры серверов, состоящие только из двух узлов, тем самым явно уступая существующим продуктам, базирующимся на платформе Unix и объединяющим больше серверов. Однако Microsoft планирует начать тестирование конфигураций с большим количеством узлов в следующем году.
Типичная конфигурация WolfPack включает в себя два стандартных, прошедших сертификацию сервера, использующих обычный SCSI-интерфейс для связи с разделяемыми физическими кластерными ресурсами, такими как дисковый массив. Каждый сервер отдельно подсоединяется к компьютерной сети, но, кроме этого, Microsoft рекомендует использовать для внутрикластерного трафика дополнительную закрытую сеть.
В идеале решение, позволяющее объединять серверы в кластеры, должно обеспечивать доступ конечных пользователей к ресурсам сервера и сетевым приложениям так, как будто весь кластер - это единое логическое устройство. Причем компоненты, отвечающие за оптимальное распределение загрузки, должны автоматически распределять запросы к кластеру на доступ к разделяемым ресурсам. Из-за невыполнения этих двух условий WolfPack может не оправдать ожиданий и не соответствовать требованиям, предъявляемым корпоративными пользователями.
Впрочем, мне все же удалось использовать разделяемые сетевые ресурсы (любой дисковый том совместного доступа) в качестве кластерных. Кроме того, мне удалось получить доступ с клиента к разделяемым ресурсам кластера с помощью общего, логического, сетевого имени кластера, а не физического имени сервера. После того как я инициировал ошибку на моем первичном сервере, клиентам по-прежнему оказались доступны разделяемые сетевые ресурсы без необходимости изменения имени сервера с моей стороны.
Разделяемый ресурс в какой-либо момент времени доступен только для одного из двух серверов. WolfPack не предпринимает ничего, чтобы сбалансировать загрузку, возникающую при запросах на доступ к разделяемым файлам, для обоих серверов кластера.
Для обеспечения сбалансированной загрузки с использованием WolfPack, вам следует создать два разделяемых ресурса, каждый из которых будет указывать на один и тот же логический набор данных. Назначьте каждый из разделяемых ресурсов одному кластерному серверу - первичному для этого ресурса. Затем для каждого разделяемого ресурса вы можете описать механизм обслуживания сбоев. В случае выхода из строя одного сервера доступ к разделяемому ресурсу обеспечит второй сервер. Наконец, вам необходимо вручную сбалансировать загрузку для обоих разделяемых ресурсов.
Эта парадигма справедлива для сетевых приложений, построенных по технологии клиент-сервер, таких как базы данных, Web или серверы сообщений. Для обеспечения эффективной загрузки специалисты третьих фирм должны будут доработать свои приложения с помощью пакета WolfPack Software Development Kit, бета-версия которого была представлена в ноябре прошлого года. Однако в нем нужно сделать доработки, которые необходимы для корректного разрешения аварийных ситуаций, что позволит гарантировать, к примеру, отсутствие потерь актуальных данных.
Тем не менее WolfPack имеет свои преимущества при распределении загрузки. Например, администратор может обеспечить раздельное выполнение двух приложений, находящихся на одном сервере, запустив по одному приложению на каждом сервере кластера. Однако этот метод не приведет к росту производительности по сравнению с вариантом, при котором приложения будут разнесены по разным серверам.
При выполнении же двух приложений на отдельных серверах, WolfPack обеспечит защиту от сбоев в случае отказа одного из кластерных серверов. В этой ситуации операция разрешения аварийной ситуации приведет к тому, что оба приложения будут выполняться на одном сервере.
Используя графическое средство Cluster Administrator, являющееся составной частью WolfPack, я смог легко добавить к своему кластеру новые ресурсы и группы ресурсов. В ходе работы были обнаружены несколько ошибок, характерных для бета-версии. WolfPack будет поставляться с несколькими стандартными типами ресурсов (которых всего существует около десятка), поддерживаемыми по умолчанию. К ним относятся жесткие диски, средства разделения файлов и обычные приложения. Есть также возможность включать новые типы ресурсов при помощи разработок третьих фирм.
Группы ресурсов будут объединять несколько ресурсов, возможно связанных между собой. Я легко добавил ряд новых ресурсов и установил зависимости между ними, которые позволяют администраторам корректно загрузить их при восстановлении после аварии. Например, после установления зависимостей я мог быть уверен, что IP-адрес кластера будет переключен на новый сервер раньше, чем произойдет загрузка ресурсов виртуального корня Internet Information Server (IIS).
Имеется возможность определить политику отката, которая позволяет WolfPack вернуть ресурс на первичный сервер при перегрузке сети. Кроме того, установив параметр Move Group, я мог переключить обработку группы ресурсов на первичный сервер в процессе выполнения операций.
Необходимо обратить внимание и на другие особенности WolfPack. Программное обеспечение для серверов приложений, которое не поддерживает соглашения Universal Naming Convention для идентификации связанных с сетью ресурсов (таких как IIS), потребует идентичного определения сетевых дисков для каждого сервера. Только тогда гарантирована корректная работа механизмов защиты от перегрузок в сети.
Пока рано судить о том, будет ли первая версия WolfPack работать так, чтобы можно было ее использовать на практике. Но бета-версия подтверждает, что возможности продукта не ограничены использованием исключительно NT.
Подводя итог, можно сказать, что администраторы, применяющие WolfPack, получат возможность снизить время простоя сети, возникающего из-за сбоев аппаратного и программного обеспечения или во время профилактических работ. Однако это средство не может управлять сбалансированной загрузкой приложений, поэтому пользователям придется обратиться к разработчикам третьих фирм, которые обеспечат поддержку этих возможностей.
Microsoft выпускает вторую бета-версию WolfPack
Компания Microsoft выпустила вторую бета-версию технологии кластеризации WolfPack, рассчитанную на построение двухузловых конфигураций для Windows NT Server.
В разряд новых возможностей кластерного API-интерфейса входят:
Microsoft планирует разослать вторую бета-версию 750 компаниям по всему миру, а подписчики Microsoft Developers Network (MSDN) получат ее уже в мае.
Технология WolfPack отмечена особым вниманием у Microsoft, посколь-
ку компания стремится занять достойную позицию на рынке кластерных технологий. Первая бета-версия, созданная в декабре прошлого года, получила неоднозначную оценку.
Microsoft планирует выпустить Phase 1 of WolfPack для кластеров на два узла в ближайшие месяцы. Phase 2, которую представители компании намерены сделать масштабируемой до 16 узлов, должна появиться в 1998 году.
Свои достижения в масштабируемости Microsoft продемонстрировала на конференции, которая прошла 20 мая в Нью-Йорке. Там была представлена и более подробная информация о WolfPack.
Web-адрес компании Microsoft - http://www.microsoft.com/.
Подводя черту
WolfPack Cluster API
Бета-версия WolfPack должна минимизировать время простоя сети, связанного со сбоями оборудования или профилактическими мероприятиями. Однако возможности организации сбалансированной загрузки не будут отвечать предъявленным требованиям, до тех пор пока не будет реализована соответствующая поддержка пользовательских приложений.
Достоинства: возможность продолжения работы или отката в предыдущее состояние в случае сбоя; простота процедуры управления ресурсами и администрирования; доступность Software Development Kit для третьих фирм.
Недостатки: предлагается конфигурация только для двух узлов; отсутствует интеллектуальное перераспределение загрузки; есть ошибки в бета-версии.
Цена: не объявлена.
Дата начала поставок: следующий квартал.
Три кластера Digital
Кластеризация - сложная технология, и попытка рассказать о ней кратко может привести к некоторой недосказанности. Это и случилось при подготовке статьи "Мода на кластеризацию", которая была напечатана в Computerworld # 15 за этот год. Рассказывая о технологии кластеризации, разработанной Digital, я допустил неточность, и в результате по прочтении статьи у читателей могло сложиться впечатление, что Memory Channel была разработана в середине 80-х годов. В действительности это не так. Технология Memory Channel предложена Digital только в 1993 году и только для одного типа продуктов - Unix-кластеров. Следует отметить, что Digital выпускает кластерные технологии для трех поддерживаемых ею операционных систем - OpenVMS, Digital Unix и Windows NT. Кроме Unix-кластера, Digital использует Memory Channel и в кластере на OpenVMS, начиная с версии 7.1.
Другой ошибкой было сообщение о возможности использования на новом NT-кластере от Digital технологий Memory Channel и NUMA. Ошибка эта основывалась на статье Джуди Демокер "Intel, Microsoft и Compaq готовят кластерный стандарт", в которой говорится о "новом SMP-сервере Digital". В ней в двух соседних абзацах рассказано о разных кластерах - о новом сервере WildFire, работающем под OpenVMS и использующем технологии Memory Channel и NUMA, и совершенно ином SMP-сервере, работающем под Windows NT. Сотрудники российского представительства Digital Equipment сообщили нам, что использование Memory Channel и NUMA для NT-кластера не планируется. Следует еще отметить, что кластер Digital для Windows NT - решение недорогое. Лицензия на один NT-сервер в кластере стоит порядка 1300 долл.
Сама модель неоднородного доступа к памяти (NUMA, Non Uniform Memory Access) возникла довольно давно. Известность этой технологии принес вариант, разработанный Sequent - cache coherent NUMA (ccNUMA), который реализован в новом сервере Sequent - NUMA-Q 2000. А компания Digital будет использовать свою реализацию неоднородного доступа к памяти.
Computerworld Россия