конфигурация для вычислений

[Ustas]

Есть следующий металлолом: хаб Fibre Channel Vixel 2100, карточки Qlogic, SAN с FbCh винтами... + 3 свободных Сервера.
ОС Windows 2000 AD server
Предполагается использовать два сервера, как счётные машины. Они будут обрабатывать данные и запихивать результаты в SQL сервер.
И предоставлять данные с SAN'а клиентам.
Прикинули два варианта:
- 1 -
Сделать из 2-х счетных машин кластер. При обсчёте данных они обе смогут обращаться к SAN'у ч/з FbCh, сконфигурировать кластер в качестве файл сервера для доступа клиентов в SAN'у.
Однако общий диск SAN'a в кластере физически будет виден на одной машине. Напрямую к нему сможет обращаться только одна счетная машина. Другая счетная машина будет гонять данные хоть и ч/з FbCh, но ч/з машину, которая в данный момент предоставляет файловую шару.
- 2 -
Установить отдельный файл сервер. Счетные машины не загонять в кластер. На FbCh хабе настроить зоны. Зона 1 счетные машины + одна из карточек файлового сервера. Зона 2 другая карточка фйл сервера + SAN.
В какой из конфигураций обсчет данных будет производиться быстрее?

[CyberDrake]

а можно поконкретнее:
что планируете "считать"?
какой soft для обсчета использовать?

[Ustas]

Данные, снятые дефектоскопом. Данных гигабайты. Структура данных и программное обеспечение собственные.

[CyberDrake]

Я бы выбрал первый вариант с общим диском. Для разрешения совместного доступа к диску можно использовать такие продукты как Tivoli SANErgy или SANBolic Kayo. На файловом сервисе будут большие накладные расходы на передачу данных, нежели при подключении серверов напрямую к диску.

[Ustas]

А каков порядок цен на продукты Tivoli SANErgy и SANBolic Kayo?
К сожалению в интернете их не нашел.

[CyberDrake]

на SANBolic Kayo ~1990$ на один сервер
на Tivoli SANErgy ~3000$ на один сервер

[Lion]

Чем принципиально отличаются SANBolic Kayo и Tivoli SANErgy, кроме цены

[CyberDrake]

Tivoli SANErgy
Один сервер является владельцем shared disk, он видит его как локальный. Остальные видят shared disk как сетевой. При чтении/записи любой сервер по LAN спрашивает у владельца о возможности чтения/записи блока N. Если блок N не заблокирован (на него не осуществляется запись в текущий момент времени), то дается разрешение, и чтение/запись проходит через SAN.
При использовании Microsoft Cluster Services возможно обеспечение failover при отказе сервера-владельца shared disk.

SANBolic Kayo
Все серверы видят shared disk как локальный. Все могут читать с диска, но только одинг сервер может писать на диск.
Используется главным образом совместно с приложениями обработки видео, которые не могут работать с сетевым диском.

[Zigzug]

А можно ли при использовании Tivoli SANErgy на shared disk положить БД MS SQL и обращаться к ней с нескольких серверов?

[Dmitry]

Естественно. Это прямая обязанность этого софта.

[Zigzug]

to Dmitry
Это точно?
В свое время уважаемый gs ИМХО говорил, что с БД такой фокус не пройдет. Что Tivoli SANErgy в данном случае не поможет.
Хотелось-бы чтобы ктонить внес ясность в этот вопрос....

[Dmitry]

Вообще я пропустил в Вашем вопросе всего две буковки "MS". Из-за этого ввел в заблуждение. В общем поясню. Если мы говорим о Microsoft SQL, то при применении этого решения возникнут проблемы с синхронизацией на уровне приложения. Правильно все синхронизирует Oracle Real Application Cluster. Ну а дисковую синхронизацию Tivoli Sanergy обеспечит. Но толку в случае MS не будет.

Архитектура кластерной базы данных IBM и не кластеризованный распределенный подход к базам данных Microsoft отличается от Oracle Real Application Clusters тем, что они выделяют для решения конкретных вычислительных задач или для управления определенным "разделом" (partition) данных индивидуальные компьютеры. При таком подходе неизбежен компромисс между масштабируемостью, производительностью и надежностью. В любой из сред IBM и Microsoft заказчики должны заранее решить, как следует распределить данные по различным дискам, которыми управляет каждый из компьютеров. Если требования по масштабированию приложения возрастают, добавление новых компьютеров приводит к дорогостоящему и отнимающему много времени перераспределению данных, а в случае Microsoft, к переписыванию больших частей приложения. В случае же Oracle9i Real Application Clusters, не требуется никакого перераспределения данных или переписывания приложений. Просто добавьте компьютеры, и кластер «прозрачно» адаптируется, чтобы использовать новые ресурсы.