Наш знакомый мексиканец Raul Rodriguez
Как видно из комментариев к посту про мою ссылку на исправительные работы наш знакомый мексиканец разбирается в технологиях получше аудитории SQL.ru. И это несмотря на трудности русского языка.
"Если больше половину люди которое был на AskTom не used RAC (Даже в домашьный условия) о чем говорить"
Я подписываюсь под этими словами :)
Сообщения
RAC для миллионеров из трущоб. Кто написал, тот пусть и пользует. А настоящие пацаны предпочитают супердома =)
ОтветитьУдалитьКстати, Россия по своей политической дремучести, по экономике с лозунгом "миллионеры из тущоб" не сильно отличается от Мексики. Я бы даже сказал, что Raul Rodriguez родом из более благополучной страны...
ОтветитьУдалитьЧто касается RAC, то можно на одном слайде показать, что четыре небольших компьютера плюс лицензии RAC более чем на миллион долларов дешевле супердома и такая конфигурация будет еще быстрее и надежнее...
Кстати, технология RAC не является взаимо-исключающей с супердомами. Господа "миллионеры из трущоб" при помощи RAC могут объединять супердома в супер-пупер-дома :^)
Но для настоящих пацанов важно совсем другое: зарплата специалиста с практическим опытом использования RAC заметно выше. И наш знакомый мексиканец Raul Rodriguez это прекрасно понимает.
:^)
Все дело в том, что "четыре небольших компьютера" никогда не будут работать надежнее ОДНОГО БОЛЬШОГО СУПЕРДОМА. Таковы жизненные реалии. Я вот двумя руками за кластер из ДВУХ СУПЕРДОМОВ, а не за 8 полудохлых железяк, половина из которых постоянно будет на сервисном обслуживании.
ОтветитьУдалитьУже давно хотел написать, что RAC - это, в моем понимании, не решение для нищебродов (вроде, зачем Вам дорогое железо, купите много дешевого), а это таки в первую очередь современная ТЕХНОЛОГИЯ.
Спасибо за комментарий.
ОтветитьУдалитьПро "ОДИН БОЛЬШОЙ СУПЕРДОМ":
Как бы ни были хороши большие компьютеры их самая большая ахиллесова пята в том, что это недублированная точка отказа (даже если там внутри абсолютно все задублировано). Вторая ахилеесова пята (размером поменьше :^) -- это предел их масштабируемости. Даже в России у Oracle навалом заказчиков, которые уже купили самый большой супердом, который только можно купить за деньги. Но в наш информационный век приложения все равно перерастают даже самые большие компьютеры. Бизнесу нужно еще больше вычислительной мощности, а процессоры уже пихать некуда. Начинаются мысли: "А нельзя ли поставить рядом второй компьютер и склеить их в один?". Ну и третий фактор в пользу RAC -- приходит новая экономика affordability. Это когда руководители все больше считают деньги. Даже в Мексике, на родине нашего знакомого Рауля Родригеса, все меньше людей, для которых "бабки не вопрос".
Моя практика показывает, что "жизненные реалии" разных заказчиков весьма разные. У кого-то есть деньги, у кого-то не совсем. У кого-то хорошо приложение распараллеливается, а у кого-то только на два узла хватает масштабируемости приложения.
Кто нашел параллелизм в своих задачах -- тот от рака не только тупо высокую готовность получил, но и экономию на железе, и диверсификацию рисков: Что там Мексика? Даже на Украине в Укртелекоме уже несколько лет пашет 8-узловый рачок и никакого эффекта "полудохлых железяк" там не наблюдается. В Почте России финансовая система давно работает на 5-узловом рачке. По неофицианьным данным Microsoft, самое крупное ценрализованное внедрение Axapta в мире (система, написаная конкурентом Oracle и ничего не знающая о раке) работает в России в компании Юнимилк на 4-узловом раке.
Заказчики видят для себя ценность в таком подходе, потому что в этих случаях они все от рака берут. Например, один узел упадет, а теряется только небольшой процент вычислительной мощности. Приезжает инженер, в багажнике у него стандартная, недорогая техника. Естественно, тьфу, прости Господи, не Формоза (шутка). У него там Sun/HP/IBM и т.п. -- хорошее железо на Intel. Инженер найдет где лампочка не горит. Один компьютер вытащит, другой вставит. Лампочка опять горит. Инженер дальше поехал :^) Шутка. Конечно, не все так просто -- Вы меня поняли. В таких раках проще держать в кластере N+1 узел на случай аварии -- он все равно копейки стоит. Кстати, эти примеры подробно разбирались на семинарах RAC DD4D когда мы приглашали людей с этих проектов.
При этом есть заказчики, которые выбрали именно обозначенный Вами путь -- два супердома с разнесением на километр-другой для пущей надежности. У них приложение не очень масштабируемое. У них деньги есть. Получается, что у них другие "жизненные реалии". Мы такой подход уважаем.
>система, написаная конкурентом Oracle
ОтветитьУдалитьКонкурентом в области чего, простите?
В области программного обеспечения :^)
ОтветитьУдалитьПо железу-то мы теперь с IBM конкурируем.
>Что касается RAC, то можно на одном слайде показать, что четыре небольших компьютера плюс лицензии RAC более чем на миллион долларов дешевле супердома и такая конфигурация будет еще быстрее и надежнее..
ОтветитьУдалитьНа слайде можно и не такое показать. :-)
Можно уточнить эти 4 компьютера в RAC и супердом будут работать с одним и тем же прикладным софтом или с разными, решающими аналогичные задачи?
С одним и тем же прикладным софтом. См. несколько примеров из моего предыдущего комментария. Это не слайды, это проекты, которые годы в production и заказчик ощутил их ценность.
ОтветитьУдалитьНе смотря на то, что RAC не является абсолютно прозрачной для приложений технологией (какой является, например, аппаратная виртуализация типа LPAR-ов и т.п.), при желании любое приложение, использующееся в реальной жизни, можно затащить на двухузловый RAC. На четырехузловый RAC посложнее, но при желании это вполне выполнимая задача. Это утверждение распространяется и на высоконагруженные OLTP-системы, типа биллинга и т.п. На семинарах DD4D и DD4DBA эта тема подробно рассматривается.
>В области программного обеспечения :^)
ОтветитьУдалитьА конкретнее?
>>А конкретнее?
ОтветитьУдалитьВ области прикладного программного обеспечения :^)
Мысль была в том, что микрософт не будет специально адаптировать аксапту под RAC, т.к. ему этого не надо. Именно поэтому я отношусь к внедрению RAC в Юнимилк с особенным пиететом.
Мне просто не очень интересно вдаваться в подробности где, как и по каким модулям каких приложений мы конкурируем и чем отличается реализация главной книги в OEBS от аксапты и чем это все вместе отличается от SAP. Но конкуренция есть и это очевидно.
Не забываем, что был пост про Мексику, а не про микрософт! :^)
>С одним и тем же прикладным софтом. См. несколько примеров из моего предыдущего комментария. Это не слайды, это проекты, которые годы в production и заказчик ощутил их ценность.
ОтветитьУдалитьЯ могу поверить, что крупный программный продукт при переезде на RAC дал серьезный скачок в производительности без вмешательства в его код. Но это уверен, что это исключение, а не правило.
Кстати, что за продукт в Укртелекоме? Я немного знаком с софтом для телекомов. :-)
>Не смотря на то, что RAC не является абсолютно прозрачной для приложений технологией (какой является, например, аппаратная виртуализация типа LPAR-ов и т.п.), при желании любое приложение, использующееся в реальной жизни, можно затащить на двухузловый RAC. На четырехузловый RAC посложнее, но при желании это вполне выполнимая задача. Это утверждение распространяется и на высоконагруженные OLTP-системы, типа биллинга и т.п. На семинарах DD4D и DD4DBA эта тема подробно рассматривается.
Биллинги... Почти 15 лет им занимаюсь и всё под Oracle. :-)
Видел 2 продукта стоящиие в большой сотовой тройке, 2 стоящие в 6-ти из 7-ми МРК Связьинвест и ещё несколько поменьше. Впечатление такое: очень большой суперпупердом им нужен не потому, что они технологию RAC не используют, а потому, что базовый функционал oracle не могут корректно пользовать. :-(
А если вернутся к Мексике, т.е. к удешевлению общей стоимости решения за счёт использования RAC, то можно добиться аналогичного эффекта и без RAC.
Было бы желание и умение. :-)
Я перестал понимать о чем мы тут говорим. Если приложение не масштабируется, то RAC ему ни к чему. Надо бы его сначала масштабируемым сделать. При желании и умении можно все -- я с вами согласен. Если приложение не масштабируется и при этом нет желания что либо менять (сами распространенная ситуация в ленивой и дремучей России :^), то путь только один -- супердом. При этом oracle в шоколаде -- заказчик лицензирует кучу процессоров, на следующий год еще кучу процессоров, потом супердом кончается... Его выкидывают, покупают новый, куда можно вставить больше процессоров и опять лицензируют :^)
ОтветитьУдалитьЕсли есть желание делать масштабируемые приложения (именно про это семинар DD4D), то появляется выбор из двух вариантов. Можно остаться на супердоме или можно перейти на RAC. В этом случае по деньгам RAC всегда выиграет у супердома. И одновременно на уровне СУБД появится высокая готовность, которая недостижима без RAC.
Да, можно разработать качественное, масштабируемое приложение и продолжать сидеть на супердоме. Стороннего наблюдателя из Мексики это шокирует, но чисто технически так действительно можно :^)
Предыдущий комментарий писал в метро с айфона. Там экран маленький, паршивый. Пришел домой, открыл MacBook и понял, что ответил не на все вопросы.
ОтветитьУдалить>> Кстати, что за продукт в Укртелекоме?
Там консолидация на RAC множества систем. Их штук 20. Биллинга, на сколько я помню, на том раке нет. Смотрим материалы семинара RAC DD4D в Киеве: http://dsvolk.blogspot.com/2009/01/rac-dd4d-27-28-2009.html (чтобы их скачать потребуется ввести credentials. Для этого напишите мне email: sergey.danilov). Вам нужен файл 2_OSC_UT_RAC.pdf. Кроме этого, можно поговорить с ребятами, которые делали этот проект. Это компания OC Consulting. В принципе, они бывают на этом сайте и могут оставить комментарий как с ними связаться. Главный персонаж -- Олександр Денисенко (http://odenysenko.wordpress.com).
Если интерсует конкретно биллинг на раке в России, то это Мегафон-Урал а Екатеринбурге, но там два узла-супердома с разнесением в пространстве. Нагрузочка там серьезная. Проект делала компания Питерсервис (www.billing.ru). Один из правильных многоузловых RAC-биллингов -- это Oracle BRM: http://dsvolk.blogspot.com/2009/04/oracle-communications-billing-and.html, но его (пока) в России я не видел.
>> Впечатление такое: очень большой суперпупердом им нужен не потому,
>> что они технологию RAC не используют, а потому,
>> что базовый функционал oracle не могут корректно пользовать. :-(
Наши впечатления совпадают. Даже в Мексике ребята понимают, что задача биллинга -- это задача с массовым параллелизмом, как на уровне приложения, так на уровне данных. Грех не воспользоваться. Но у нас легких путей не ищут. Заведут относительно небольшую таблицу баллансов и со всех сторон ее апдейтят...
>> к удешевлению общей стоимости решения за счёт использования RAC,
>> то можно добиться аналогичного эффекта и без RAC.
Если есть не-масштабируемое биллинговое приложение, работающее на 400 CPU, то по-человечески преписав его, я не удивлюсь, если оно заработает с такой же скоростью на 100 CPU (или даже на 48 CPU -- не важно). Пока без рака. Да, стало дешевле. Но 48 CPU это все равно супердом. Вот теперь самое время разбить его на четырех-узловый RAC. Будет еще дешевле и одновременно надежнее.
Axapta значительно лучше работала на Оракле, чем на SQL Server еще до того, как стала частью MS. Основная причина - криворукожопость тамошних разработчиков, приводившая к большому кол-ву дэдлоков. Оракл более терпим к таким ошибкам дизайна.
ОтветитьУдалить>Если интерсует конкретно биллинг на раке в России, то это Мегафон-Урал а Екатеринбурге, но там два узла-супердома с разнесением в пространстве. Нагрузочка там серьезная. Проект делала компания Питерсервис (www.billing.ru).
ОтветитьУдалитьТри узла вроде было. Два года назад правда...
Два узла, разнесение около 2км. Цифры три не было. Даже два года назад :^)
ОтветитьУдалитьПришел комментарий, который мы немного отмодерировали:
ОтветитьУдалить>> Перефразируя анекдот:
>>
>> Если бы RAC был бы так полезен,
>> то в каждой европейской семье
>> было бы по два кластера.
Сейчас в Москве на Белорусской площади висит рекламный плакат дорогого ресторана "Шелк" со слоганом: "полтора миллиарда китайцев не могут ошибаться" :^)
Тема, правда, была про Мексику, ну да ладно.