Сергей ТихоновРебята, мне, как автору топика, все же хотелось бы, чтобы мы обсуждали не преимущества/недостатки страйпинга и уровней RAID, а архитектуру БД. Я вот нашел интересную статью в инете: Clustering for Scalability и предлагаю ее обсудить. Так все-таки: Shared-disk или Shared-nothing ?


Я, все же не понимаю зачем вы пытаетесь решать эту задачу с помощью кластера?

Поскльку у вас смешанная нагрузка 50:50 (OLTP + DSS ), то мне кажется ваше задача должна решаться с использованием аппаратного партицирования.
Я так понимаю оно присутствует у большинства производителей железа.
То есть я все же за железо типа SuperDoom от HP или Sun Fire E25K.
Почему?

1. Минимальный гемор с балансировкой по сравнению с кластерами.
2. Динамическая реконфигурация железа.
Ну необходимо вам сейчас увеличить пропускную способность OLTP части, добавили процессоров, нужно для DSS части опять же оторвали в одном месте добавили в другом.
3. Все так же пока не понятно, это будет одна и таже БД или все же два єкземпляра?

Сергей Тихонов EugeneSЯ, все же не понимаю зачем вы пытаетесь решать эту задачу с помощью кластера? Потому что это более отказоустойчивое решение. Я хочу совместить Availability и Scalability ...

Ага, именно по этому такие ребята, как Visa и EuroPay их не используют.
А используют mainframe-ы.

Дело в том, что кластеринг для СУБД - это такая рекламная компания, для увеличения продаж СУБД, ну прям как Java, NET и другие "звездные продукты".
Шума много, а начнешь выяснять доказательств маловато или не убедительно.
Как говорится в "в мутной воде проще рыбку впоймать" , вот софтверные конторы и поднимаю такую муть, для увеличения доходности.

Пример возмем кластера от Oracle.
1. Только начиная с 9i у него появился Cache Fusion , который позволяет передавать болоки не через диск , а по интерконнекту между кэшами отдельных узлов.
2. Подразумевалось что использование кластеров позволит снизить затраты компании на hardware, при этом почему-то умалчивается что затраты на кластеринг тоже растут. ( Oracle EE стоит 40к на процессор, для того чтобы его использовать в кластерной конфигурации надо еще 20к итого 60к * число узлов. А уж если ван нужно партицирование или еще что-то то эта сумма и того выше).
Идея была конечно хорошей ,но это банальное перераспределение денег.
Тем более многопроцессорные системы вобще-то лучше ведут себя и под нагрузкой и при параллельном доступе, а динамическое партицирование вообще их делает "The best". Недостаток их конечно в больших первоначальных затратах.

3. Использование кластера от Oracle (shared-disk) подразумевает использование очень не слабой дисковой подсистемы, дешевеньким продуктом вы тут не отделаетесь, поскольку дисковая система как раз самое узкое место кластера от Oracle, поэтому в итоге необходимо иметь второй экземпляр дисковой системы для failover-а, иначе при выходе из строя дисковой подсистемы , весь кластер упадет.
4. Еще про отказоустойчивость.
Что вы имеете ввиду? Любая оказоустойчивость подразумевает дубляж.
То наличие двух хостов , двух дисковых подсистем.
Кластеры в минимальной конфиугации этого не продоставляют, скорей лучшим решением является standby БД.

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

onstat-В данном случае нельзя быть и умным и красивым односременно.
В случае shared-disk мы имеем перегрузку(overload) в случае отказа
одной из нод, в случае shared nothing мы будем иметь потерю доступа
к части данных(на время востановления узла) без потери
общей производительности.
С уважением, onstat-

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

gardenman автор
Ага, именно по этому такие ребята, как Visa и EuroPay их не используют.

Насколько я помню *конечно может уже неправ* но VISA в Bank Of America стоит на BASE 24, Tandem, NonStop SQL. Да и во многих процесинговых центрах стоит эта система. Типа супер - отказоустойчивая. Именно - кластарная. Как реализована отказоустойчивость - это нужно уже архитектуру смотреть. Можно ведь каждую ноду сдублировать.

У них несколько другие кластеры.
Наверно речь идет о Failover кластере.
То есть два узла, но зато всем узлам узлы.

Сергей Тихонов EugeneSТолько начиная с 9i у него появился Cache Fusion , который позволяет передавать болоки не через диск , а по интерконнекту между кэшами отдельных узлов. Замечательно, уже даже Oracle 10g есть...
EugeneSИспользование кластера от Oracle (shared-disk) подразумевает использование очень не слабой дисковой подсистемы ИМХО, когда речь идет о больших объемах данных, это и так понятно. Тут что с Oracle, что без него...
EugeneSЛюбая оказоустойчивость подразумевает дубляж.
То наличие двух хостов , двух дисковых подсистем. Нормально. Взрослые дисковые стойки и так имеют в себе дублирование компонентов, далее идем по архитектуре SAN и топологиям - два SAN-свича, два HBA в каждый сервер. И приходим к ситуации no single point of failure

А что делать, если один большой шкаф с тучей процов и памяти перестанет работать :-\\?

1. В таком шкафу вы вряд-ли найдете хоть один компонент который не дублируется.
2. Вам ничего не мешает иметь два шкафа, но это уже для случая missio-critical.

Константин Лисянский А что делать, если один большой шкаф с тучей процов и памяти перестанет работать :-\\?

Курить бамбук :) И ждать пока его починят.


С уважением,
Константин Лисянский
http://lissianski.narod.ru

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