Миф: как IBM победил БЭСМ

[zVlad]

МФ еще тем отличается от, скажем, Интел тем что каналы ввода-вывода работают независимо от CPU и любая операция ввода-вывода запущенная CPU выполнятся автомомно, задача переходит в ожидание, а CPU становится свободным для другой задачи. Однопотоковой задачей с вводом-выводом невозможно загрузить один CPU сколько-нибудь серьезно.

Иными словами - CPU каналов стоят незадействованные, в то время как основные процессоры по уши заняты.
В такой ситуации если сделать CPU универсальными - в принципе можно получить выигрышь производительности на том же количестве процессоров.

CPU каналов и основные CPU не одинаковы по возможностям и параметрам. Поэтому универсальный CPU будет заведомо плох в обеих ролях.

[StrangerR]

Блин, а я не знаю, имея под тысячу виртуалок, имея все почти продакшен системы уже на VMware, более 5 терабайтов суммарной оперативки, прямо сейчас трахаясь с апгрейдом VC?

Оверхед реальный где то процентов 10. Но если бы даже был и 30, это бы не волновало абсолютно. Потому что эти 30 процентов рояли не играютЮ, а вот возможность апгрейднуть железо на ходу мышкой - играет и весьма - весьма. Парочки переносов MS SQL серверов с железки на железку нам хватило за глаза, чтобы избавиться от этого мазохизма. С тех пор делали замену дисков на ходу, перенос на новые железки на ходу, перенос на новый SAN на ходу. Заметим еще что если линукс на железке еще можно вынести, то винду с её недо - LVM в котором нету даже простейшей операции эвакуации диска или переноса часть вольмов, а также которая вместо нормального системного mpio вечно юзает свой, как и сетевой бондинг - свой и у всех вендоров разный - то физическая винда это вообще ужас ужасный... нафиг такое... нету больше и слава богу!

С райдами - я же говорю, на сегодня тенденция все делать на софте, и единственное что мешает совсем уж массовым софтовым райдам - отстуствие кэша для write back. Клауды почти все уже давно сидят на софтовых райдах.

Я не знаю у вас там тысяча, 10 тысячь или что там, я реально видел переход с физической на виртуальную поетому и говорю и что и как получилось с етого с оверхеад...
А Винда ето вообще маразм, мы давным давно от нее отказались нафиг, все на линуксе крутится. Винда только на персоналках стоит на floor...

Я тоже видел и много. как вы правильно сказали, с учетом стоимости интел апгрейда, этот оверхед роли уже не играет.

Линуксы на физике я еще могу вынести и понять, тут я согласен. Но винды.. на физике... ой, ну не надо, это сплошной мазохизм. Я не очень понимаю как выживают бедняги которые виндовые гипервизоры крутят на физике (VMware кстати позволяет их крутить как виртуалки), разве что привязаться жестко к одному поставщику или очень жестко выдерживать все микрософтовские полиси и иметь несколько виндовых гуру в команде. Чудес с апгрейдами виндовых серверов столько, что даже запомнить нереально.

Дешивизна вот главный двигатель софтваре RAID(как кстати и тех самый Intel based серверов), а отнють не перформанце или низкий оверхеад. Мы же говорим именно об етом.

Не совсем. Сторейдж размазанная на 3 РАЗНЫХ железки - много надежнее (да и дешевле) чем железный райд на одной железке. И тенденция потихоньку сдвигается именно туда. Еще не сдвинулась, но сдвигается. Я софтовые райды очень не люблю, но за размазанной по железкам сторейджем будущее однозначно. И тут снова МФ в полном пролете.

[zVlad]

Нет я не против Wintel, но в больших ИТ его широкое использование ведет к катастрофам на самом деле. Это показал наш недавний DR test, только из-за проблем связанных с Wintel мы не уложились в отпущенное щедро время.

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

Что такое "оракловый dataguard"?

Physical standby + Fast Failover

Это слишком дорого. В нашей отрасли - энергетика так не делают, (хотя за всю отрасль мне наверно не стоит зарекаться). У нас нет standby, у нас в лучшем случае mirror дисков и ресурс где с этого mirror можно загрузить систему в случае DR.

А вообще не стоит обращать внимание на iDesperado - он тупо тролит меня как только я ему даю для этого повод. Поскольку я человек общительный поводов для этого много.

[ARARAT.]

Не совсем. Сторейдж размазанная на 3 РАЗНЫХ железки - много надежнее (да и дешевле) чем железный райд на одной железке. И тенденция потихоньку сдвигается именно туда. Еще не сдвинулась, но сдвигается. Я софтовые райды очень не люблю, но за размазанной по железкам сторейджем будущее однозначно. И тут снова МФ в полном пролете.

А кто вам мешает размазать аппаратный RAID на множество железок или поставить множество самих железок(HDDs arrays)?
У нас например нa МФ именно так и есть два парралельных файбер канала под двумя парралельными контроллерами на сервере, правда конечная железка одна стоит, но можно и две разных поставить. Как-раз МФ в етом гораздо лучше чем Intel based, так как именно там ето сделанна с самого начала и аппаратно, а не виртуально...
Виртуальные железки например разного типа одновременно ето вообще еще тот геморой, как и разные физические серверы на виртуалке. Приемущество грубо исключительно для "бедных", которые собирают солянки из всякого "железного" мусора блин или облака когда все елементы облака по определению различны(например customers обьединенные в облака)...

PS Но в одном я согласен стоимость МФ очень большая и гибкость из-за етого очень низкая, upgrades трудно и дорого делать, но для стабильной процессорной загрузки и для лучшей защиты(физической) и стабильности всех системы МФ лучше. Я говорю за все время моей работы на ету компанию, а ето вот уже 15 лет только один раз МФ остановилась внезапно на причине поломки... A вот наш фронт енд кластер блин, все время требует внимания, не редки внезапные остановки/задержки, иногда просто ложится нафиг. Правда при етом он перебрасывается на другую виртуалку просто, но сами проблемы то есть, на МФ их просто нет как класс(так сказать отсутствую на корню).
Дa и второе приемущество ето хорошее обслуживание сильно изменяющийся мульти-третиной browser based "нагрузки", МФ так не может(он не для етого как я уже писал), у него не хватает именно мулти-тритности...
Т.е. front end для обслуживания customers(тенденция именно browser based в настоящее время) Intel based незаменим на MF вообщемто...
Но в качестве живого(как у нас например medical billing система крутится(выполняет свои отдельные функции/операции) сама по себе, web только для внешнего доступа к каким то данным) и очень надежного и независимого ядра МФ работает значительно лучше...

Т.е. для customer front end и особенно browser based Intel based серваки лучше со всеми их логическими коровами, огромной memory и виртуалками... И если сам бизнес только в етом и состоит(что сейчас маинстрим), то большего и не надо нечего конечно, тогда никакие МФ не нужны просто. Иначе, если есть не только етот front end, но и больший(в смысле гораздо больше чем наружний прецессинг) in-house processing, то комбинация front end na Intel based серверах и MF является ИХМО лучшим вариантом.
Проблема в том, что сейчас многие сильно увлеклись етими Intel based серверами забывая о их недостатках и пытаются их использовать на все.
Конечно все можно сделать типа "почесав правое ухо левой рукой", но ето не значит, что правой рукой теперь стало хуже. Т.е. можно и в булочную летать на вертолете или наоборот на черепахе и если забыл что есть например свои ноги или машина для етого наиболее правильное средство.

Все ладно, я затыкаюсь...

[StrangerR]

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

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

Это слишком дорого. В нашей отрасли - энергетика так не делают, (хотя за всю отрасль мне наверно не стоит зарекаться).

С ума сойти. У меня первое требование к любой продакшен базе - всегда, без исключений, physical standby (не зеркало дисков и тем паче не РАК а именно Data Guard ну или MS SQL mirror. Причем это не дорого, у всех провайдеров базы если стендбай только стендбаит его можно не лицензировать отдельно, да и никто не мешает на нем стейджинг делать и взаимно миррорить. СУБД без зеркала вообще не способна выполнять требования по SLA на продакшен. Как вы ее простите апгрейдить будете, сам сервер или там OS? Или перетаскивать на новое железо /даже в VMWARE даже онлайн перетаскивание легко делается на средне нагруженном стендбае но плохо на первичной базе, есть шанс алармы поиметь).

[Easbayguy]

Класно когда базы такие маленькие что их можно кликнув мышкой перетащить. Или целый МФ с 5ТБ данных!

[Dmitry67]

StrangeR, так представьте сколько IBM заломит за DR...

[Easbayguy]

StrangeR, так представьте сколько IBM заломит за DR...

Oracle license, они тоже кусаются!

[Dmitry67]

Т.е. для customer front end и особенно browser based Intel based серваки лучше со всеми их логическими коровами, огромной memory и виртуалками... И если сам бизнес только в етом и состоит(что сейчас маинстрим), то большего и не надо нечего конечно, тогда никакие МФ не нужны просто. Иначе, если есть не только етот front end, но и больший(в смысле гораздо больше чем наружний прецессинг) in-house processing, то комбинация front end na Intel based серверах и MF является ИХМО лучшим вариантом.

Я бы добавил бы сюда еще и базы данных. Потому что им чем больше памяти тем лучше.
И мы согласимся. Только вот IBM маркетологи не согласятся
Потому что если смотреть на то, где МФ хороша, то это shrinking market, а им кровь из носу надо распространяться в ширь

[Dmitry67]

StrangeR, так представьте сколько IBM заломит за DR...

Oracle license, они тоже кусаются!

Это да. Или ms sql, для полноценного mirroring нужно asynchronous, а это enterprise. Не говоря уже о availability groups...

P.S.
Мы тут считали стоимость Enterprise MS SQL, так вот, стоимостью железа можно пренебречь

[iDesperado]

у меня когда-то был план дешевого DR на IBM сториджах. у IBM были сториджи порядка $10k (цена) с возможностью зеркалирования. можно зеркалить REDO лог на соседний сторидж и поднять standbay, накатывая этот REDO. в оракле есть хитрость, standby бесплатный и присутствует даже в standart edition, платен data guard, который обеспечивает перенос блоков REDO.
а асинхронный standby мне кажется вообще не проблема - перекидываешь арклоги и накатываешь на второй ноде, просто если что REDO погибнет на главной ноде и эти несколько минут будут утеряны, если боинг в окно прилетел например.

[Dmitry67]

у меня когда-то был план дешевого DR на IBM сториджах. у IBM были сториджи порядка $10k (цена) с возможностью зеркалирования. можно зеркалить REDO лог на соседний сторидж и поднять standbay, накатывая этот REDO. в оракле есть хитрость, standby бесплатный и присутствует даже в standart edition, платен data guard, который обеспечивает перенос блоков REDO.

Гыыыааааа
ТО ЖЕ САМОЕ (когда то на MS SQL) log shipping был только в Enterprise, но он делал только автоматизацию копирования файлов, так что кому не лень писали скрипты чтобы делать то же самое. Потом log shipping стал бесплатен везде

А в Oracle есть аналог Mirroring & Availability groups,
то есть, перекидывания того что у вас называется REDO не кусками, а непрерывно?
А DR database offline или readonly?

[iDesperado]

А в Oracle есть аналог Mirroring & Availability groups,
то есть, перекидывания того что у вас называется REDO не кусками, а непрерывно?
А DR database offline или readonly?

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

[Dmitry67]

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

да вы с ума сошли!
В MS SQL synchronous mirroring был Standard, а Asynс только Enterprise.
Потому что с Synchronous вы каши не сварите с нормальным DR (не в одном помещении)
Разные штаты или Европа-US, roundtrip 50-100ms, и время любой крошечной транзакции становится не меньше чем roundtrip latency
10 записей в секунду максимум не хотите вставлять?

[iDesperado]

да вы с ума сошли!
В MS SQL synchronous mirroring был Standard, а Asynс только Enterprise.
Потому что с Synchronous вы каши не сварите с нормальным DR (не в одном помещении)
Разные штаты или Европа-US, roundtrip 50-100ms, и время любой крошечной транзакции становится не меньше чем roundtrip latency
10 записей в секунду максимум не хотите вставлять?

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