День добрый!Обращаюсь за помощью к профи в кластерных технологиях.
Ситуация следующая:
Пусть у нас есть два сервера, объединенных в кластер. Пока опустим, с помощью чего они объеденены, важно, что на каждом из серваков крутится свой экземпляр операционки и, соответственно, СУБД.Вопрос:
1. Можно-ли каким-либо образом объеденить два экземпляра Oracle в один, чтобы на прикладном уровне (PL/SQL) не было распределенности?
2. Если можно, то каким образом это сделать?Спасибо.
>прикладном уровне (PL/SQL) не было распределенности?А что подразумевается под "распределённостью на прикладном уровне"?
>А что подразумевается под "распределённостью на прикладном уровне"?усилия от разработчика по организации распределенной (параллельной) работы. например, разбиение системы на автономные модули, взаимодействующие между собой посредством сообщений.
>>А что подразумевается под "распределённостью на прикладном уровне"?
>
>усилия от разработчика по организации распределенной (параллельной) работы. например, разбиение системы на
>автономные модули, взаимодействующие между собой посредством сообщений.Возможно, Oracle RAC ??
>Возможно, Oracle RAC ??за вчерашний вечер успел по диагонали просмотреть Real Application Cluster Concepts.
посему вопрос:
есть ли для прикладного программера какая-нибудь разница в навыках написания PLSQL-кода между каким-нить SMP (например, FireWire 15K) и этим самым RAC, который будет крутиться, например, на 4-рех серверах по два ксеона в каждом, объединенных в кластер. Уж больно дорогие эти SMP. UMA, NUMA, ccNUMA или как там их еще ;-).
>за вчерашний вечер успел по диагонали просмотреть Real Application Cluster >Concepts.RAC в некоем смысле шаг вперёд, а в некоем - два назад по сравнению
с ORACLE Parallel Server. Все вроде бы чудесно сделано, только эта
самая чудесность нехило жрёт канал на синхронизацию даже тогда, когда
это не особенно и требуется (что приводит к существенному замедлению
работа по сравнению с незабвенным OPS 7.3.4.4).>
>посему вопрос:
>есть ли для прикладного программера какая-нибудь разница в навыках
>написания PLSQL-кода между
>каким-нить SMP (например, FireWire 15K) и этим самым RAC, который будет
>крутиться, например, на 4-рех серверах по два ксеона в каждом,
>объединенных
>в кластер. Уж больно дорогие эти SMP. UMA, NUMA, ccNUMA или
>как там их еще ;-).Разница будет не для прикладного программиста, а для конечного
пользователя и эксплуатирующего персонала. Как обычно, всё зависит
от типа задачки, то есть объёма и характера порождаемой нагрузки.Ни четыре, ни десять, ни даже двадцать Xeon'ов отному
пятнадцатитысячнику не эквивалент. Притом в управлении оный набор
Зеонов существенно сложнее, и некий геморрой для достижения
эффективного распределения нагрузки весьма вероятен.
Плюс с надёжностью хуже. Бабки не за просто так платятся,
и отнюдь не за марку, и даже не за возможность легко
писать прикладной код.Если запросы хорошо распараллеливаются "естественным образом"
(мало блокировок, пересекающихся наборов обновляемых/читаемых данных)
кластерное решение на ПиСюКах вполне ко двору. Если нет -
проблемы могут быть не при написании собственно приклада,
а в процессе докрутки оного приклада до состояния, способного
успешно обслужить реальные нагрузки.
Спасибо за ответ!>RAC в некоем смысле шаг вперёд, а в некоем - два назад
>по сравнению
>с ORACLE Parallel Server. Все вроде бы чудесно сделано, только эта
>самая чудесность нехило жрёт канал на синхронизацию даже тогда, когда
>это не особенно и требуется (что приводит к существенному замедлению
>работа по сравнению с незабвенным OPS 7.3.4.4).а в чем по-вашему два шага назад? только в замедлении работы из-за задержек на синхронизацию?
я слышал, что RAC -- надежнее OPS.
и, с другой стороны, какой Вы советуете OPS использовать?
в чем между ними кардинальная разница с точки зрения обслуживающего персонала (DBA, sysadmin'ов и т.п.)?>
>Разница будет не для прикладного программиста, а для конечного
>пользователя и эксплуатирующего персонала. Как обычно, всё зависит
>от типа задачки, то есть объёма и характера порождаемой нагрузки.объем порождаемой нагрузки -- 60-80 транзакций в секунду. с тенденцией к повышению.
режим работы 24*7*365.>
>Ни четыре, ни десять, ни даже двадцать Xeon'ов отному
>пятнадцатитысячнику не эквивалент. Притом в управлении оный набор
>Зеонов существенно сложнее, и некий геморрой для достижения
>эффективного распределения нагрузки весьма вероятен.
>Плюс с надёжностью хуже. Бабки не за просто так платятся,
>и отнюдь не за марку, и даже не за возможность легко
>писать прикладной код.бабки сейчас хотят за все. в первую очередь за "воздух". особенно это касается программной инженерии да и всей IT-индустрии в целом.
так что если нет возможности внятно сформулировать за что берутся деньги, то они, скорее всего, берутся за красивый черный корпус, а в случае отсутствия такового -- за все тот же пресловутый "воздух". ;-)>
>Если запросы хорошо распараллеливаются "естественным образом"
>(мало блокировок, пересекающихся наборов обновляемых/читаемых данных)
>кластерное решение на ПиСюКах вполне ко двору. Если нет -
>проблемы могут быть не при написании собственно приклада,
>а в процессе докрутки оного приклада до состояния, способного
>успешно обслужить реальные нагрузки.запросы распараллеливаются естественным образом тогда, когда об этом позаботился архитектор и программист это внял и не тупил.
самого по себе "естественного" параллелизма, по всей видимости, у прЫроде нет.
>Спасибо за ответ!
>
>а в чем по-вашему два шага назад? только в замедлении работы из-за
>задержек на синхронизацию?
>Собственно, и это уже не мало. Реальный пример - некий территориально
распределённый кластер на Alpha'х. В силу солидной дистанции сделать
канал толще стоит нехилых бабок; продвигать версию Ораклухи люди
вынуждены из-за саппорта и из-за того, что ошибки старых версий
перестают исправлять.Для "голого" распараллеливания работы процедур и обычных запросов
RAC нужен примерно так же, как собаке пятая нога. Новые возможности,
появившиеся в RAC, в ряде случаев просто невостребованы. Вернуться
же в режим a la OPS нельзя в силу принципиальных различий в реализации.>я слышал, что RAC -- надежнее OPS.
Наветы. При аккуратной настройке и то неплохо, и другое работает.
>и, с другой стороны, какой Вы советуете OPS использовать?
Никакой, ибо даже ORACLE 8i вот-вот перейдёт в Extended Support со
всеми вытекающими последствиями (если уже не перешёл - давно я
эти не интересовался)>в чем между ними кардинальная разница с точки зрения обслуживающего
>персонала (DBA, sysadmin'ов и т.п.)?
>Просто это разные продукты. RAC концептуально сложнее устроен,
нежели OPS, поэтому требования к квалификации DBA, пожалуй,
возрастут. Объём усилий по повседневному администрированию
зависит от используемых конфигураций, но на мой взгляд, вполне
сопоставим для "старых"и "новых" кластерных конфигураций.
Плюс в "девятке" явно улучшились средства администрирования.>объем порождаемой нагрузки -- 60-80 транзакций в секунду.
>с тенденцией к повышению.
>Ни о чём не говорит. Реальная нагрузка зависит от объёма операций
("веса" каждой транзакции). 60-80 *неких* транзакций в секунду
может потянуть даже одиночный P4 2.4GHz.>режим работы 24*7*365.
Небось надёжность "пять девяток" ходите, с гарантией по железу?
Недёшево обойдётся.>бабки сейчас хотят за все. в первую очередь за "воздух". особенно это
>касается программной инженерии да и всей IT-индустрии в целом.
>так что если нет возможности внятно сформулировать за что берутся деньги, то
>они, скорее всего, берутся за красивый черный корпус, а в случае
>отсутствия такового -- за все тот же пресловутый "воздух". ;-)
>Корпус обычно красивый. Design is the law.
Только берётся бабло, вообще-то, за пропускную способность
шин обмена и устройств ввода-вывода, скорость вычислений и
вытекающую отсюда производительность.>запросы распараллеливаются естественным образом тогда,
>когда об этом позаботился архитектор и программист
>это внял и не тупил.
>самого по себе "естественного" параллелизма, по всей видимости,
>у прЫроде нет.Существуют различия в геморрое, зарабатываемого архитектором
и программистами в процессе распараллеливания осуществляемых
запросов и минимизации зависимостей по данным.
>Собственно, и это уже не мало.ага, этого, как правило, бывает достаточно, чтобы сделать параллельную программу медленнее ее последовательного аналога. при соответствующих "усилиях", разумеется ;-)
>Реальный пример - некий территориально
>распределённый кластер на Alpha'х. В силу солидной дистанции сделать
>канал толще стоит нехилых бабок; продвигать версию Ораклухи люди
>вынуждены из-за саппорта и из-за того, что ошибки старых версий
>перестают исправлять.задача, о которой говорю я, имеет несколько другую природу. здесь кластер будет находиться в одной комнате. по крайней мере пока так предполагается.
>
>Для "голого" распараллеливания работы процедур и обычных запросов
>RAC нужен примерно так же, как собаке пятая нога. Новые возможности,
>появившиеся в RAC, в ряде случаев просто невостребованы. Вернуться
>же в режим a la OPS нельзя в силу принципиальных различий в
>реализации.т.е. невозможно привязывать сессии к каким-то конкретным узлам кластера?
>Никакой, ибо даже ORACLE 8i вот-вот перейдёт в Extended Support со
>всеми вытекающими последствиями (если уже не перешёл - давно я
>эти не интересовался)ясно. спасибо.
>Просто это разные продукты. RAC концептуально сложнее устроен,
>нежели OPS, поэтому требования к квалификации DBA, пожалуй,
>возрастут. Объём усилий по повседневному администрированию
>зависит от используемых конфигураций, но на мой взгляд, вполне
>сопоставим для "старых"и "новых" кластерных конфигураций.
>Плюс в "девятке" явно улучшились средства администрирования.интересно, сколько же стоят (хотя бы порядок величины) администраторы RAC, способные с высокой долей вероятности на своем "человеческом" уровне обеспечить бесперебойную работу?
>Ни о чём не говорит. Реальная нагрузка зависит от объёма операций
>("веса" каждой транзакции). 60-80 *неких* транзакций в секунду
>может потянуть даже одиночный P4 2.4GHz.задача является аналогом банковской процессинговой системы по обслуживанию магнитных и микропроцесорных пластиковых карт.
транзакции следующего типа:
1. положить/снять кредиты на счет
2. перевести кредиты с одного счета на другой
3. получить текущее значение счета
4. сохранение информации для аудита>
>>режим работы 24*7*365.
>
>Небось надёжность "пять девяток" ходите, с гарантией по железу?
>Недёшево обойдётся.на этапе опытной эксплуатации возможна и меньшая надежность (0.95).
на этапе промышленной эксплуатации -- 5-ть девяток.>
>Корпус обычно красивый. Design is the law.ну, наверное, это закон для тех, кто не понимает истинного значения фразы "пипл хавает" ;-)
>Только берётся бабло, вообще-то, за пропускную способность
>шин обмена и устройств ввода-вывода, скорость вычислений и
>вытекающую отсюда производительность.согласен, пропускная способность шин - основопологающий фактор. но по шесть Кбаксов за процессор и четыре за 70Gb винт -- это уж слишком.
;-)>Существуют различия в геморрое, зарабатываемого архитектором
>и программистами в процессе распараллеливания осуществляемых
>запросов и минимизации зависимостей по данным.да, архитектор производит базовую декомпозицию предметной области на части, которую не исправить никакими настройками и потугами специалистов, находящихся в производственной цепочке за ним.
>задача, о которой говорю я, имеет несколько другую природу.
>здесь кластер будет находиться в одной комнате. по крайней мере
>пока так предполагается.Это очень даже неплохо. Можно даже сказать, что и прекрасно.
Если появятся граждане с рассуждениями типа "а если вдруг самолёт
в здание врежется", гоните их в шею. Гораздо эффективнее и дешевле
разместить кластер в здании, которое заведомо неинтересно всяческим
террористам. ;-)>т.е. невозможно привязывать сессии к каким-то конкретным узлам кластера?
Не могу утверждать, что вообще нельзя - я не особенно большой знаток
RAC - но на поверхности таких средств не наблюдается.>интересно, сколько же стоят (хотя бы порядок величины) администраторы
>RAC, способные с высокой долей вероятности на своем "человеческом"
>уровне обеспечить бесперебойную работу?Когда я последний раз интересовался, средние затраты на получение
сертификата DBA от ORACLE составляли примерно 3-4 килобакса.
Иного надёжного способа убедиться в квалификации админа у компании,
его нанимающей, попросту не имеется. Люди, практически разом
выкладывающие такие деньги за бумажку, рассчитывают существенно
поднять свой профессиональный статус, и их зарплатные аппетиты
маленькими не бывают.Можно, конечно, взять пионера-самоучку, способного обучаться с
приемлемой скоростью, и даже заплатить те самые килобаксы за его
обучение и экзамен. Поначалу будет некая экономия, затем пионер
перестанет быть пионером, и всё вернётся к исходному варианту.>задача является аналогом банковской процессинговой системы по обслуживанию магнитных и микропроцесорных пластиковых
>карт.
>
>транзакции следующего типа:
>1. положить/снять кредиты на счетСамо по себе мелочь. Зависит от того, насколько сложная структура
учёта используется, а также от того, не пытается ли кто-либо
в онлайне считать какую-нибудь аналитику.>2. перевести кредиты с одного счета на другой
Аналогично пункту 1.
>3. получить текущее значение счета
Совсем мелочь.
>4. сохранение информации для аудита
Вероятно, наиболее "тяжёлый" тип нагрузки. Может сопровождаться
труднолокализуемыми блокировками по данным и порождать
"узкие места" в параллельной обработке.Известный обходной путь - отдельно хранить журнал операций,
периодически реплицировать его в другую БД и на другую машину,
и всю аналитику с аудитом крутить там. Тогда, по крайней мере,
удастся аккуратно разнести нагрузку.>на этапе опытной эксплуатации возможна и меньшая надежность (0.95).
>на этапе промышленной эксплуатации -- 5-ть девяток.
>Мелкософт хвастается, что сервера под W2K, выпускаемые её OEM-партнёрами,
оную надёжность обеспечивают. Что-то не верится...>ну, наверное, это закон для тех, кто не понимает истинного
>значения фразы "пипл хавает" ;-)Вот Титомир пусть и хавает. А мы погодим!
>согласен, пропускная способность шин - основопологающий фактор.
>но по шесть Кбаксов за процессор и четыре за 70Gb винт
>-- это уж слишком. ;-)Вы ценами на сервера HP (не писюками, а PA-RISC) поинтересуйтесь.
Sun покажется конторой для бедных. А Ultra-3 SCSI винчестер с
функциями горячей замены, 16-ти мегабайтным буфером, скоростью
обращения 15000 и длиннющей гарантией может и дороже стоить.>да, архитектор производит базовую декомпозицию предметной области на
>части, которую не исправить никакими настройками и потугами
>специалистов, находящихся в производственной цепочке за ним.
>Я, собственно, о другом. ERGO: "Естественный" параллелизм отличается
от "неестественного" количеством усилий, затраченных на достижение
достаточного его уровня для решения прикладной задачи с приемлемой
для предметной области производительностью. :)
>Это очень даже неплохо. Можно даже сказать, что и прекрасно.придерживаюсь аналогичного мнения ;-)
>Если появятся граждане с рассуждениями типа "а если вдруг самолёт
>в здание врежется", гоните их в шею.смешно говорить, но такие находятся и, что удивительно, мгновенно. видимо, это самое приминивное, в смысле самое простое, что может прийти в голову.
>Не могу утверждать, что вообще нельзя - я не особенно большой знаток
>RAC - но на поверхности таких средств не наблюдается.ясно. спасибо и на этом. ;-)
>
>Можно, конечно, взять пионера-самоучку, способного обучаться с
>приемлемой скоростью, и даже заплатить те самые килобаксы за его
>обучение и экзамен. Поначалу будет некая экономия, затем пионер
>перестанет быть пионером, и всё вернётся к исходному варианту.вещи (и, тем более, люди) стоят столько, сколько они стоят. экономить на этом -- лишать себя возможности контролировать ситуацию... ;-)
>
>>задача является аналогом банковской процессинговой системы по обслуживанию магнитных и микропроцесорных пластиковых
>>карт.
>>
>>транзакции следующего типа:
>>1. положить/снять кредиты на счет
>
>Само по себе мелочь. Зависит от того, насколько сложная структура
>учёта используется, а также от того, не пытается ли кто-либо
>в онлайне считать какую-нибудь аналитику.согласен: все зависит от структуры учета. но она пока до конца не ясна, т.к. процесс находится в состоянии идентификации требований к ПО.
все это в полной мере относится и к аналитической обработке. она будет, предположительно сложная, но большинство деталей еще не выявлены.придерживаюсь мнения, что аппаратура нужна для того, чтобы обеспечивать потребности прикладной программы. следовательно, архитектура аппаратной базы вторична по отношению к архитектуре ПО (в первую очередь прикладного). следовательно и исходить необходимо из потребностей софта.
но порой приходится разворачивать ситуацию на 180 градусов: с целью минимизации времени, необходимого для принятия проектных решений по всей вычислительной системе, приходится проектировние структуры аппаратной части вести параллельно с проектированием структуры ПО. При этом, к началу этапа тестирования должна уже быть некая аппаратная база. кроме этого, задача усложняется проблемой защиты инвестиций: нецелесообразно для тестирования и опытной эксплуатации покупать один комплект аппаратуры, а для промышленной эксплуатации -- другой.
>>4. сохранение информации для аудита
>
>Вероятно, наиболее "тяжёлый" тип нагрузки. Может сопровождаться
>труднолокализуемыми блокировками по данным и порождать
>"узкие места" в параллельной обработке.полностью согласен, так оно и есть: сбор данных за длительные периоды -- слишком дорогостоищ.
>
>Известный обходной путь - отдельно хранить журнал операций,
>периодически реплицировать его в другую БД и на другую машину,
>и всю аналитику с аудитом крутить там. Тогда, по крайней мере,
>удастся аккуратно разнести нагрузку.а такой вопрос: каким образом настраивается балансировка нагрузки в RAC? по каким принципам? по экземплярам БД, по серверным узлам, по сессиям?
>
>Мелкософт хвастается, что сервера под W2K, выпускаемые её OEM-артнёрами,
>оную надёжность обеспечивают. Что-то не верится...мелкософт, да, если честно, и не только он, выдают желаемое за действительное. люди, по незнанию, в это верят и, как говорится, хавают. ;-)
говоря по-русски -- правдоподобно врут. очень нехорошее явление в последнее время, от которого просто спасу нет.
>
>>ну, наверное, это закон для тех, кто не понимает истинного
>>значения фразы "пипл хавает" ;-)
>
>Вот Титомир пусть и хавает. А мы погодим!ну мы же задумываемся по крайней мере, где мухи, а где котлеты, чтобы отложить первых в сторону.
>Вы ценами на сервера HP (не писюками, а PA-RISC) поинтересуйтесь.
>Sun покажется конторой для бедных. А Ultra-3 SCSI винчестер с
>функциями горячей замены, 16-ти мегабайтным буфером, скоростью
>обращения 15000 и длиннющей гарантией может и дороже стоить.интересовался. вот от них и улетаю. ;-)
>
>Я, собственно, о другом. ERGO: "Естественный" параллелизм отличается
>от "неестественного" количеством усилий, затраченных на достижение
>достаточного его уровня для решения прикладной задачи с приемлемой
>для предметной области производительностью. :)я понял, вы хотели сказать, что: есть задачи хорошо векторизуемые (раскладываемые на одновременно выполняющиеся операции), а есть исключительно последовательные, т.к. результаты начальных операций используются в последующих. хорошо векторизуемые вы назвали "естественным" параллелизмом. что ж, видимо так оно и есть ;-)
>>Возможно, Oracle RAC ??
>
>за вчерашний вечер успел по диагонали просмотреть Real Application Cluster Concepts.
>
>посему вопрос:
>есть ли для прикладного программера какая-нибудь разница в навыках написания PLSQL-кода между
>каким-нить SMP (например, FireWire 15K) и этим самым RAC, который будет
>крутиться, например, на 4-рех серверах по два ксеона в каждом, объединенных
>в кластер. Уж больно дорогие эти SMP. UMA, NUMA, ccNUMA или
>как там их еще ;-).Нет, если запросы не хинтовать, вопросов не будет, всё решается администратором. А что за задача такая, требующая столь нехилой процессорной мощности? Коров считать на PL/SQL? :)))
И какая дисковая подсистема планируется?P.S. IMHO, загрузить 106 гигагерцовых ультраспарков Fire 15000-го голым ораклом - это из области ненаучной фантастики.
>Нет, если запросы не хинтовать, вопросов не будет, всё решается администратором. А
>что за задача такая, требующая столь нехилой процессорной мощности? Коров считать
>на PL/SQL? :)))
>И какая дисковая подсистема планируется?
>
>P.S. IMHO, загрузить 106 гигагерцовых ультраспарков Fire 15000-го голым ораклом - это
>из области ненаучной фантастики.на многие вопросы еще нет ответов. в частности, что касается дисковой подсистемы. пока предполагается, что будет какая-нить библиотека на 400-600G.
задача типовая -- некий аналог процессинговой системы.
суть сложностей в том, что прогнозировать рост нагрузки аналитическими методами -- невозможно, т.к. нет статистики. хуже того, нет методики, как ее (статистику) собирать.
как я писал выше, пока предполагается загрузка равной 60-80 транзакций в секунду.