Кластеры и ORACLE

[genie]

Здравствуйте.
Хотелось бы услышать мнение/мысли/соображения специалистов Trinity
на тему "кластерные решения для СУБД ORACLE на платформе Intel".
Конкретно интересуют такие вопросы как:
1 Выбор ОС. (Linux, Windows, Solaris x86)
2 выбор кластерного ПО
3 производительность на базах обьемом от 20Г и выше
4 отказоустойчивость
5 наращиваемость
6 примеры конфигураций у клиентов Trinity

[Z0termaNN]

соображения следующие :
1. операционная система - глубоко личное дело, но юникс
он как-то роднее, причем линуск или солярис - это глубоко фиолетово. разница только в том, что солярис
интеловское железо поддерживает достаточно
ограниченно.
2. интеловские сервера показывают очень достойную
производительность, мы в свое время очень даже
задумывались над тес, не поменять ли нам альфу
стоимостью 120к баксов на компак за 7к, при всем при
этом производительность у них практически одинакова.
однако есть одно но - проблемы с 32 битной адресацией.
на солярке не пробовал, а на линуксе есть пролблемы с
36 битной адресацей под ксеон. так, что если
разработчики придурки или задача какая-то особенная, то все-таки стоит смотреть в сторону 64 битной архитектуры, чтобы засунуть все в сга.
3. кластер - это маркетинговый ход, который позволяет
вытащить из наивных людей побольше денег. на сане,
это практически набор скриптов, который кластером
и назвать-то трудно (например в сравнении с vms). на
деньги, затраченные на приобретение 2 компьютеров для
кластера можно купить 1, но раз в 8 мощнее. если нужен
онлайновый бэкап, то советую смотреть в сторону oracle
dataguard (для 8 для линукса его нет, н портировать с
соляриса можно достаточно быстро).

[setar]

3. кластер - это маркетинговый ход, который позволяет
вытащить из наивных людей побольше денег. на сане,
это практически набор скриптов, который кластером
и назвать-то трудно (например в сравнении с vms). на
деньги, затраченные на приобретение 2 компьютеров для
кластера можно купить 1, но раз в 8 мощнее.

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

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

[setar]

Здравствуйте.
Хотелось бы услышать мнение/мысли/соображения специалистов Trinity
на тему "кластерные решения для СУБД ORACLE на платформе Intel".
Конкретно интересуют такие вопросы как:
1 Выбор ОС. (Linux, Windows, Solaris x86

Open Unix.

2 выбор кластерного ПО

Oracle Real Application Cluster

3 производительность на базах обьемом от 20Г и выше
4 отказоустойчивость
5 наращиваемость
6 примеры конфигураций у клиентов Trinity

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

[Z0termaNN]

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

[CyberDrake]

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

сильное заявление

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

а по поводу Real Application Cluster - зря Вы так, с моей точки зрения это наиболее приличный продукт на рынке доступных для среднего пользователя решений

[a_shats]

genie
Немножко поздно, и я не специалист Тринити, но все же подброшу 5 копеек :
1. Родным для Оракла является Solaris, на х86 не поддерживаются, насколько мне известно, лишь проприетарные Сановские фишки типа доменов. А вообще - дак хоть на W2K Adv Server, только вот объемы...
2. По кластерному ПО - для Оракла оно только родное (см. пост CyberDrake), так что и выбирать особенно-то и не из чего . Нет, в принципе, можно использовать и средства ОС, и ПО третьих производителей, но лучше -родное. Тем более, что возможностей у него вполне достаточно.
3. Производительность на базах от 20Гб... Хм. Персонально я не видел решений на х86, работающих на таких объемах (видел Сановские ). Проблема в макс. объеме оперативки (4 Гб). РАЕ ее решает, насколько мне известно, лишь частично, плюс - роняет производительность. Почему проблема - самый простой и прямой способ поднять производительность Оракловой базы - загнать полбазы в SGA (область оперативки, выделяемая запущенному экземпляру (Instance) Оракла, в т.ч. в ней размещаются разнообразные кэши). В данном случае - не выйдет, или выйдет, но с потерей в производительности относительно "нормальной" для х86 с 4 Гб.
Но это - наиболее простой и прямой способ. Есть и другие, не столь прямолинейные, но тоже эффективные. Например - тщательное профилирование базы и аккуратная настройка параметров инстансов и ОС под конкретное железо.
Других серьезных ограничений (особенно - при наличии быстрого внешнего RAIDа) навскидку - не вижу. Кстати: "полноценные" решения от Sun для подобных баз выглядят так же: 2-8 CPU, 4-8 Gb RAM, толстый и быстрый внешний массив.
4, 5 - оба вопроса решаются Oracle Real Applications Cluster. Непосредственно с ним работать мне не приходилось (он появился только с 9-й версии, до того был Oracle Parallel Server, вот его и пробовал - даже там был очень широкий набор возможностей по отказоустойчивости и масштабируемости ). Что касается конкретного варианта работы RAC - лучше бы спросить совета у разработчиков софта, им (исходя из специфики софта) было бы виднее.
6. На этот вопрос у меня ответа нет .
Z0termaNN

Лихо ! В принципе, RAID-контроллеры тоже не такие уж и надежные, а если уронить сервер со второго этажа, то ни HS корзины, ни избыточные БП его тоже не спасут . Не мне писать, для чего они, в принципе, нужны, но... Да: если можно, приведите, пожалуйста, пример - когда наличие отказоустойчивого кластера снижает отказоустойчивость. А то, может, я чего-то пропустил ?

[CyberDrake]

Кстати, на каком-то Комтеке одна фирма показывала жутко навороченный сервер с дублированием всего, что можно (две мамы и т.п.), кстати не такой уж на тот момент и мощный. Стоил он раз в пять больше "обычного" сервера на базе платформы Intel или Supermicro. Но на вопрос, а что будет если на него ведро воды (я бы туда еще и соли побольше добавил ), ответ был, как и следовало ожидать, удручающим. А применение кластера даже на базе Win2k или Novell от ведра вода спасет, здесь необходимо 2 и более ведер

[Курдиков Сергей]

Согласен с Z0termaNN.

Сразу видно - человек разбирается.
А все остальные только воду льют и со второго этажа роняют !

[a_shats]

Hemul
Вы, простите, с чем именно согласны ? С тем, что отказоустойчивый кластер имеет меньшую надежность, чем одиночный сервер ? Или - по поводу Альфы и Компака (AlphaServer и Proliant сравниваются, я правильно понял ? Еще б комплектацию знать - для более точной оценки...См. http://www.tpc.org , TPC-C и TPC-D) ? А насчет Сана - да, скрипты, но - основанные на внутреннем устройстве Сановских машин (видимо, все-таки домены имеются в виду, т.е. фактически "виртуальный" кластер в одном "физическом" сервере). А вот - можно ли это чудо считать кластером в его классическом, так скыть , смысле - тоже вопрос.
Тогда зачем подобные заявления ? Не в сбрасывании с верхотуры дело , и не в ведрах. Дело в том, что над отдельно взятым узлом отказоустойчивого кластера можно измываться как угодно (пылесосить, например, или ведро то же пресловутое воды на него вылить ) - простоя всей системы, тем не менее, не будет.
Другое дело - нужна ли такая отказоустойчивость в конкретном случае (в смысле, работа 24/7/365).

[Курдиков Сергей]

To a_shats:

Тут дело-то в следующем. Мой личный опыт был связан с двумя кластерными системами: Windows NT и UnixWare 7.0.1 Схема оборудования классическая - два нода и между ними внешний сторидж. Между нодами хетбит.

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

Отсюда, собственно, и выработалось мнение, пока доступного (т.е. сравнительно недорогого) и надёжноработающего софта что-то пока не наблюдается.

Да, вот ещё вспомнил. Наш тех.директор рассказывал. Были они на Цебите каком-то там. Ну и ни то SCO, ни то Compaq демострировали кластер из восьми нодов. Все узлы были связаны спец.девайсами, организующими шину в 800MB между ними. И попросили мои коллеги погасить один из узлов, дабы понаблюдать, как оно там жить дальше будет. Странно получилось, но почему-то погасло ещё три узла. Т.е. они попросту вывалились из кластера. Подробностей не знаю, не был. Просто резюме, что софт как-то всё кривокосой наблюдается.

Это так всё, чисто мои личные наблюдения. Может кто-то и сделает какие выводы.

[CyberDrake]

над отдельно взятым узлом отказоустойчивого кластера можно измываться как угодно (пылесосить, например, или ведро то же пресловутое воды на него вылить )

а например при большой нагрузке hearbeat выдернуть не пробовали???
в ряде случаев второй (в Microsoft Cluster Services) сервер, тот который не является владельцем ресурса, последний далеко не всегда поднимает
с Novell кстати те же проблемы возникали

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

[a_shats]

Мой опыт куда скромнее ;(
Внешние стораджи у нас в провинции практически не встречаются.
"Чистый" вычислительный кластер никому особо не нужен тут.
Отказоустойчивый - вот тут да... Нужно было: проверить работу именно отказоустойчивого "типа кластера" на Oracle Parallel Server.
Т.е. задачей был не кластер, как самоцель, а 24/7/365.
Схема: 2 компа, по две сотки в ALB, OPS (2 instance, 2 базы с онлайновой репликацией между ними, соотв. настройки на клиентах, года 2 назад). Работало - молча. На двух обнаковенных РС. Грубое вырубание любой из двух машин, ессно, вызывало лишь восстановление+мощную репликацию после включения на ней. На, клиентах, зато - при массированных записи/обновлении, при выпадении "узла" был замечен рост производительности .
Пример с точки зрения "классического" определения кластера некорректен, конечно, но - задача в теме была поставлена, как мне кажется, достаточно четко. С точки зрения отказоустойчивости - практически самое то.
Вот, собственно...

[Курдиков Сергей]

Мой опыт с Ораклом - скромнее некуда
Я просто с ним не работал.

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

P.S. Тут только что обнаружил для себя, что первичная тема ветки форума как-то позабылась

[a_shats]

Hemul
Дык... Проблема в такой схеме на таких объемах будет лишь в репликации, имхо.
Хорошим тоном при проектировании структуры БД считается, когда в рамках транзакции клиент вставляет/обновляет только те данные, которые вводятся/изменяются пользователем. Вся служебная информация (всевозможные связи, и т.п.) вносится и изменяется на самом сервере-при помощи триггеров. В базе объемом 20 Гб и более это (в зависимости от структуры) приводит к массированной записи, и, как следствие, репликации. Кроме того, базы подобного объема, как правило, пополняются и изменяются не десятками, но - сотнями пользователей. Результат предсказуем - мощный обмен между "узлами". Т.е. гигабита на такой "heartbeat" возможно, и хватит, но- как всегда: чем больше, тем лучше. Кстати: при наличии внешнего стораджа есть и "стандартный" вариант OPS: 2 instance - 1 база. О надежности ничего сказать не могу, да и детали не помню - надо будет перечитать.