всем доброго дня!

собственно вопрос. есть резон переползти с сановского кластера на вмварь?
документации по сановскому кластеру маловато. например весьма мутновато указано, как ставить хост-агентов на ноды...
по настройкам памяти и параметров ОС есть масса инфы на HP-UX, AIX (в скобках Linux),
а солярка в этом ряду как-то особняком стоит...
кто-нить переезжал? почувствовал выигрыш/проигрыш в производительности?
относительно более простого (или как минимум привычного) администрирования выгода наверняка очевидна?

А я всегда думал, что производительность зависит от железа.
И правильности профильных параметров.

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

некорректно. кластер кластером, а виртуалка виртуалкой.
ладно бы оракле виртуал на варю...или обратно
для продакта потеряете 5-10%, но получите гибкость
смотря для чего. для экономии железа можно разобрать кластер и переползти на standby конфигурацию
в общем смотря что нужнее

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

проходили

Виртуализировали с обычных серверов ERP-ландшафт на VmWare в режиме HA. Плюсов больше чем минусов, не смотря на небольшую потерю в производительности.

О'как... И БД тоже в HA запихнули?

ДА, база тоже там.
Смысл HA в том, что если вылетает один сервер, эта виртуалка запускается на другом сервере ESXi, включенным в кластер. Для этого нужен общий датастор. HA не дает отказоустойчивость без простоя (без простоя это технология FT).
При выходе из строя сервера время восстановления работы = время перезагрузки виртуалки на новом сервере. Оговорюсь, что в моем случае кол-во пользователей не большое для систем SAP, да и сама система не большая.
Для профи, думаю, вообще детский лепет.

Однако, плюшки есть:
1. Ежедневный бэкап всей виртуалки (2ТБ) занимает пол часа (бэкап измененных данных).
2. Мирграция виртуалок между серверами без выключения системы.
3. Возможность быстро создать копию системы.
4. Возможность ресторить как виртуалку целиком, так и вытащить отдельный файл из бэкапа виртуалки.
5. Удобство управлением ресурсами (процессоры, память, дисковое пространство)
6. Возможность сконфигурировать сеть без дополнительного железа (виртуальные свитчи, тимминг, vLan).

HA, FT это все понятно...НО
скажите, а как Ваша СУБД переносит такие "рестарты"?

З.ы. видал случаи, когда после shut abort, oracle не восставал...

З.ы.з.ы. вот щас придет avlag и скажет, что HA и FT не кластеризует базу...

Вот он я, отвлекся от развлечений с дисковыми полками, к которым подключено некоторое количество серверов с vmware. Это я к тому, что мне рассказывать за возможности vmware совсем не обязательно
И как работает HA я представляю.
Поэтому и спросил про БД. Как правильно спрашивает шрам - вы хорошо подумали, когда не кластеризовали базу?
HA - система простая. Перестала мониториться виртуалка - запустим её на другом узле. В каком состоянии при этом может быть файловая система - будет разгребать тот, кто это устроил.
Oracle, конечно, штучка живучая, но если ему по башке выключением питания стучать - иногда и до Disaster recovery доходит.
И, кстати, время бекапа не является определяющим. Главное - [s]хвост[/s] время востановления! А оно может оказаться сильно-сильно больше. Попробуйте на досуге, чтобы знать к чему готовиться в плане времени восстановления системы.

А вообще - я бы посоветовал переделать системы на классический кластер в рамках vmware. Ну, т.е. Oracle на OCFS2 или ACFS в RAC, саму систему в распределенную установку, для отказоустойчивости нужно иметь в постоянной работе только ASCS, а для него вполне хватит и режима FT, под который разрешено использовать не больше одного процессора.
И будет вполне себе хорошая отказоустойчивая система.
А сейчас - потенциальный геморрой, если при аварийном перезапуске базы на другом узле Oracle скажет, что у него ORA-600 появилась. Хотя это и не самый плохой вариант

Да, в моем случае восстановление из бэкапа займет часов 8-10. Это ж надо восстановить виртуалку + накатить туда архивлоги. Было время, когда из-за неисправных
кондиционеров сервер вырубался раз-два за ночь. Тьфу-тьфу, из-за этого за всю свою жизнь база пережила shutdown abort раз 20. Однако, был случай когда просто ни с того ни с сего
в базу залетела ошибочная транзакция (подробностей не знаю, то ли глюк oracle, то ли raid сбойнул), которая привела к не консистентности данных. Предполагаю, что в таком случае кластеризация oracle не спасла бы - вредоносная реплика распространилась бы на все копии. В общем, как повезет, но конечно, лучше перестраховаться.
Хорошая мысль, надо убить какую-нибудь базу, и попробовать ее восстановить И теперь тоже хочу OCFS

а как интересно вся эта схема измениться, когда появится оракл 12?
он вроде заявлен как "единый сервер + несколько контейнерных баз данных". + "hot-warm-cool" зоны хранения...

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

2500 человеко-лет! Вот так вот, а у нас Патриот ОС за 3 года собрались наваять. Прошу прощения за оффтоп.