Айтишники на пенсии

[Ion Tichy]

вы мне еще лингвистическую лекцию прочитайте, ага. транзакция - это ВСЕГДА попытка изменить данные. потому что объединение операций чтения в транзакции просто не имеет смысла

a pattern similar to the following:

Begin the transaction
Execute a set of data manipulations and/or queries
If no errors occur then commit the transaction and end it
If errors occur then roll back the transaction and end it
If no errors occurred during the execution of the transaction then the system commits the transaction. A transaction commit operation applies all data manipulations within the scope of the transaction and persists the results to the database.

как вы коммитить чтение собрались?

Легко - командой "commit".
Мотто, Вы меня разочаровываете - от, думал, перец! И на язык остер, и по профи части не тупак.
Транзакция - или все, или ничего.
Чтение - как было до начала чтения, так по окончании чтения и осталось.
Пример из жизни - квартальный бухгалтерский баланс:
1. Бегин транзакшн - всем "ша", я щас суммы считать буду, кто попробует апдейт - пожалеет что родился
2. Читаю-считаю-читаю-считаю...
3. Коммит, всем спасибо, все свободны, можете писАть.

Можно и на глазах операцию через ж делать

Наверняка знаете о чем говорите.

Конечно. Неоднократно такой код видел. Приходилось исправлять.

Ну так это же замечательно! Можете по памяти воспроизвести (на каком-нибудь псевдокоде) как было до и как стало после Вашего исправления?

[DVK]

Легко - командой "commit".
Мотто, Вы меня разочаровываете - от, думал, перец! И на язык остер, и по профи части не тупак.
Транзакция - или все, или ничего.
Чтение - как было до начала чтения, так по окончании чтения и осталось.
Пример из жизни - квартальный бухгалтерский баланс:
1. Бегин транзакшн - всем "ша", я щас суммы считать буду, кто попробует апдейт - пожалеет что родился
2. Читаю-считаю-читаю-считаю...
3. Коммит, всем спасибо, все свободны, можете писАть.

Можно и на глазах операцию через ж делать

Наверняка знаете о чем говорите.

Конечно. Неоднократно такой код видел. Приходилось исправлять.

Ну так это же замечательно! Можете по памяти воспроизвести (на каком-нибудь псевдокоде) как было до и как стало после Вашего исправелния?

Я уже сдаю зачёт?

[Ion Tichy]

Можно и на глазах операцию через ж делать

Наверняка знаете о чем говорите.

Конечно. Неоднократно такой код видел. Приходилось исправлять.

Ну так это же замечательно! Можете по памяти воспроизвести (на каком-нибудь псевдокоде) как было до и как стало после Вашего исправелния?

Я уже сдаю зачёт?

Вы че? Нет так нет - джентельменам верят на слово (и тут мне такая карта поперла).

[DVK]

Наверняка знаете о чем говорите.

Конечно. Неоднократно такой код видел. Приходилось исправлять.

Ну так это же замечательно! Можете по памяти воспроизвести (на каком-нибудь псевдокоде) как было до и как стало после Вашего исправелния?

Я уже сдаю зачёт?

Вы че? Нет так нет - джентельменам верят на слово (и тут мне такая карта поперла).

Ну поперла - так поперла.

[АццкоМото]

Легко - командой "commit".
Мотто, Вы меня разочаровываете - от, думал, перец! И на язык остер, и по профи части не тупак.
Транзакция - или все, или ничего.
Чтение - как было до начала чтения, так по окончании чтения и осталось.
Пример из жизни - квартальный бухгалтерский баланс:
1. Бегин транзакшн - всем "ша", я щас суммы считать буду, кто попробует апдейт - пожалеет что родился
2. Читаю-считаю-читаю-считаю...
3. Коммит, всем спасибо, все свободны, можете писАть.

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

Легко - командой "commit"

выдает вас с головой

[Ion Tichy]

Легко - командой "commit".
Мотто, Вы меня разочаровываете - от, думал, перец! И на язык остер, и по профи части не тупак.
Транзакция - или все, или ничего.
Чтение - как было до начала чтения, так по окончании чтения и осталось.
Пример из жизни - квартальный бухгалтерский баланс:
1. Бегин транзакшн - всем "ша", я щас суммы считать буду, кто попробует апдейт - пожалеет что родился
2. Читаю-считаю-читаю-считаю...
3. Коммит, всем спасибо, все свободны, можете писАть.

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

Легко - командой "commit"

выдает вас с головой

Пасиб, беру на вооружение - "Вы правы, но это есть вырожденный и очень глупый случай".

[oshibka_residenta]

Добавление ресурсов (серверов) это не только новые сервера, но и новое сетевое оборудование (и много чего другого), которое надо не только добавлять для обеспечения производительности, но для надежности дублировать. А потом получается простой из-за коммуникаций как недавно в BritishAirways.

Наглости и самоуверенности вам не занимать (попробуйте карьеру в Гербалайф).
British airways используют МФ и все равно виноваты другие ?!
У них был перебой в работе ровно из-за того, что их система оказалась не распределённая. Если бы у них был резервный датацентр, то в первом хоть ядерный взрыв произойди, все было бы нормально.

[Ion Tichy]

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

Легко - командой "commit"

выдает вас с головой

Кстати - а что не так с commit? При чем тут бд? Я вот в начале 2000-х на Java/JNI/С писАл ХА-клиента который был ни разу не бд, но слово commit там использовалось сплошь и рядом согласно X/Open спекам-стандартам которые были официально куплены конторой в виде толстенных бумажных книженций.

[АццкоМото]

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

Легко - командой "commit"

выдает вас с головой

Кстати - а что не так с commit? При чем тут бд? Я вот в начале 2000-х на Java/JNI/С писАл ХА-клиента который был ни разу не бд, но слово commit там использовалось сплошь и рядом согласно X/Open спекам-стандартам которые были официально куплены конторой в виде толстенных бумажных книженций.

Все так. И всё не так.

Ведь оно может быть коммит, а может быть finish/flush/complete или уаще исполняться имплиситно по выходу объекта из стека. Любое конкретное название (или не название) сразу привязывает нас к ненужной конкретике, отдаляя от сути

[Ion Tichy]

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

Легко - командой "commit"

выдает вас с головой

Кстати - а что не так с commit? При чем тут бд? Я вот в начале 2000-х на Java/JNI/С писАл ХА-клиента который был ни разу не бд, но слово commit там использовалось сплошь и рядом согласно X/Open спекам-стандартам которые были официально куплены конторой в виде толстенных бумажных книженций.

Все так. И всё не так.

Ведь оно может быть коммит, а может быть finish/flush/complete или уаще исполняться имплиситно по выходу объекта из стека. Любое конкретное название (или не название) сразу привязывает нас к ненужной конкретике, отдаляя от сути

Есть begin и commit|rollback. Период. И шерифу нет дела до когнитивных ассоциаций и детских комплексов конкретного индейца.

[АццкоМото]

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

Легко - командой "commit"

выдает вас с головой

Кстати - а что не так с commit? При чем тут бд? Я вот в начале 2000-х на Java/JNI/С писАл ХА-клиента который был ни разу не бд, но слово commit там использовалось сплошь и рядом согласно X/Open спекам-стандартам которые были официально куплены конторой в виде толстенных бумажных книженций.

Все так. И всё не так.

Ведь оно может быть коммит, а может быть finish/flush/complete или уаще исполняться имплиситно по выходу объекта из стека. Любое конкретное название (или не название) сразу привязывает нас к ненужной конкретике, отдаляя от сути

Есть begin и commit|rollback. Период. И шерифу нет дела до когнитивных ассоциаций и детских комплексов конкретного индейца.

Индейцу ещё более пох на шерифа. Если вы не поняли, о чем я — извиняйте, не доросли ;( периоды он тут будет ставить, ага

[Ion Tichy]

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

Кстати - а что не так с commit? При чем тут бд? Я вот в начале 2000-х на Java/JNI/С писАл ХА-клиента который был ни разу не бд, но слово commit там использовалось сплошь и рядом согласно X/Open спекам-стандартам которые были официально куплены конторой в виде толстенных бумажных книженций.

Все так. И всё не так.

Ведь оно может быть коммит, а может быть finish/flush/complete или уаще исполняться имплиситно по выходу объекта из стека. Любое конкретное название (или не название) сразу привязывает нас к ненужной конкретике, отдаляя от сути

Есть begin и commit|rollback. Период. И шерифу нет дела до когнитивных ассоциаций и детских комплексов конкретного индейца.

Индейцу ещё более пох на шерифа. Если вы не поняли, о чем я — извиняйте, не доросли ;( периоды он тут будет ставить, ага

А шерифу нах на пох индейца у которого единственный известный транзакционный ресурс это бд и который услышав "commit" на уровне рефлексов отликается "абырвалг" "insertupdatedelete". Не, бремя белого человека заставляет нести свет знаний дикарям, но не откровенно безнадежным.

[АццкоМото]

Кстати - а что не так с commit? При чем тут бд? Я вот в начале 2000-х на Java/JNI/С писАл ХА-клиента который был ни разу не бд, но слово commit там использовалось сплошь и рядом согласно X/Open спекам-стандартам которые были официально куплены конторой в виде толстенных бумажных книженций.

Все так. И всё не так.

Ведь оно может быть коммит, а может быть finish/flush/complete или уаще исполняться имплиситно по выходу объекта из стека. Любое конкретное название (или не название) сразу привязывает нас к ненужной конкретике, отдаляя от сути

Есть begin и commit|rollback. Период. И шерифу нет дела до когнитивных ассоциаций и детских комплексов конкретного индейца.

Индейцу ещё более пох на шерифа. Если вы не поняли, о чем я — извиняйте, не доросли ;( периоды он тут будет ставить, ага

А шерифу нах на пох индейца у которого единственный известный транзакционный ресурс это бд и который услышав "commit" на уровне рефлексов отликается "абырвалг" "insertupdatedelete". Не, бремя белого человека заставляет нести свет знаний дикарям, но не откровенно безнадежным.

Бро, я тебе по секрету скажу - признания типа "я старый вебсферщик" - даже хуже, чем "я в попу даю кому попало". Твой коричневый свет "знаний" никому в пуп не уперся. Мы тут это. Гетеросекусуальную компанию предпочитаем

[Ion Tichy]

Все так. И всё не так.

Ведь оно может быть коммит, а может быть finish/flush/complete или уаще исполняться имплиситно по выходу объекта из стека. Любое конкретное название (или не название) сразу привязывает нас к ненужной конкретике, отдаляя от сути

Есть begin и commit|rollback. Период. И шерифу нет дела до когнитивных ассоциаций и детских комплексов конкретного индейца.

Индейцу ещё более пох на шерифа. Если вы не поняли, о чем я — извиняйте, не доросли ;( периоды он тут будет ставить, ага

А шерифу нах на пох индейца у которого единственный известный транзакционный ресурс это бд и который услышав "commit" на уровне рефлексов отликается "абырвалг" "insertupdatedelete". Не, бремя белого человека заставляет нести свет знаний дикарям, но не откровенно безнадежным.

Бро, я тебе по секрету скажу - признания типа "я старый вебсферщик" - даже хуже, чем "я в попу даю кому попало". Твой коричневый свет "знаний" никому в пуп не уперся. Мы тут это. Гетеросекусуальную компанию предпочитаем

Фигасе... Че Вы злой такой?

[zVlad]

... Я изучал довольно много чего, включая os/360 и, возможно, даже z/os, но дело было давно. ...

АццкоМото, дорогой, расскажите поподробнее. Вы должны понять как мне начинающему преподавателю в этой сфере это важно может быть.
Сколько времени потратили, какова была цель изучения, как узучали: самостоятельно или с инструктором, была ли достигнута цель и довелось ли попрактитоваться с этими системами, в каких ролях. Что помнится до сих пор. Примерно в этом ключе, пожалуйста. Если что захотите добавить, еще лучше, отдельное спасибо. Если не хотите это обсуждать публично - в личку.

[zVlad]

1) намедни я говорил о средних значениях, которые таки да ниже секунды получаются. Для контороля SLA определены наиболее критичные транзакции, которые выполняются роботами с каждой location клиента (их больше десятка) по времени и замеряется время выполнения. Показания этих роботов и используется для SLA. ОТ ПОЛУСЕКУНДЫ ДО СЕКУНДЫ ЭТО средние опять же значениям с пяти серверов приложений (CICS), которые выполняются на продакшн (на МФ) одновременно и по которым разбросаны пользователи этого приложения (исходя из их территориального нахождения). Да разница между ними существенна на мой взгляд и это как-то объясняется, но я не знаю как. Как то так.

Давайте посмотрим, что вы говорили
Среднее время выполнения тех наших 2.5 млн. транзакций не более одной секунды. Учет этого времени ведется по пяти различным группам и среднее время в группах от 0.5 сек до одной сек. Пусть будет 1 секунда.
ок, здесь нет ничего про "за превышение порога в 1 сек карают" - либо это было в другом месте, либо это у меня глюк. но тут есть важная деталь - среднее вычисляется по группам. т.е. не может быть такого, что одна транзакция элементарна и выполняется в миллисекунды, а другая - сложна и выполняется долго, а среднее около секунды. т.е. у вас есть транзакции, которые одного порядка сложности, выполняются меньше, чем за секунду, но иногда - 10+ минут. это песец, товарищи
...

Вас похоже ввело в заблуждение образования упомянутых груп. Я говорил об этом, повторю, это не группы транзакций, это групы людей, выполняющих в принципе одинаковые наборы транзакций просто работающих с разных крупных location: head office, station 1, station 2, и т.д

А с этим: "..т.е. не может быть такого, что одна транзакция элементарна и выполняется в миллисекунды, а другая - сложна и выполняется долго" все в точности до наоборот. Именно так оно и есть на самом деле что все транзакции разные и именно из-за их большой разницы они выполняются разное время, или иначе требует разный обьем ресурсов для своего выполнения. Большенство выполняются значительно меньше секунды и в среднем получается от .5 до 1. в разных группах.

Для контроля SLA определены наиболее критичные транзакции, которые выполняются роботами с каждой location клиента (их больше десятка) по времени и замеряется время выполнения. В число этих транзакций "длинные" не входят.

"длинными", кстати, делают транзакции некоторые пользователи, я уже это отмечал, тем что не задают диапазоны поиска, предлагаемые им. Приложение написано так что в этом случае рассматривается весь диапазон: от минимума до максимума. Пользователей учат этим обятзательно пользоваться, но они поступают иначе, не все но все таки есть. После сортировки они в начале списка имеют то что им надо: последние события. То что при этом БД строит весь набор событий с начала эксплуатации приложения их не волнует и видимо время вполнения такой работы не так уж и велико, иначе они бы задавали границы более разумно.

Вот кстати свеженькая гистограмка (специально для Вас, правда за субботу, не самый напряженный день, но это в данном случае не так важно). 18 транзакций в этой группе (одной из пяти, в субботу с 7:00 до 7:30) выполнялись дольше 4 секунд:

Code: Select all

                                        ----------RESPONSE TIME DISTRIBUTION----------
    ----TIME----    --NUMBER OF TRANSACTIONS--    -------PERCENT-------  0    10   20   30   40   50   60   70   80   90   100
    HH.MM.SS.TTT    CUM TOTAL        IN BUCKET    CUM TOTAL   IN BUCKET  !....!....!....!....!....!....!....!....!....!....!
 <  00.00.00.500         1841             1841         78.2        78.2  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 <= 00.00.00.600         2046              205         87.0         8.7  >>>>>
 <= 00.00.00.700         2131               85         90.6         3.6  >>>
 <= 00.00.00.800         2164               33         92.0         1.4  >
 <= 00.00.00.900         2195               31         93.3         1.3  >
 <= 00.00.01.000         2214               19         94.1         0.8  >
 <= 00.00.01.100         2232               18         94.9         0.8  >
 <= 00.00.01.200         2244               12         95.4         0.5  >
 <= 00.00.01.300         2254               10         95.8         0.4  >
 <= 00.00.01.400         2265               11         96.3         0.5  >
 <= 00.00.01.500         2272                7         96.6         0.3  >
 <= 00.00.02.000         2293               21         97.5         0.9  >
 <= 00.00.04.000         2335               42         99.2         1.8  >>
 >  00.00.04.000         2353               18          100         0.8  >

Эта информация, кстати, побочный результат работы WLM, используется для управления процессами с целью достижения качества процессов: 90% транзакций за меньше чем 1 секунда (последняя строка):

Code: Select all

Service Class Name . . . . . :,CICS    ,
Description  . . . . . . . . .,CICS Transactions xNG1          ,
Workload Name  . . . . . . . .,ONLINES ,,(name or ?) ,
Base Resource Group  . . . . .,________,,(name or ?) ,
Cpu Critical . . . . . . . . .,YES,,     (YES or NO)  ,

Specify BASE GOAL information. Action Codes: I=Insert new period,,    ,
E=Edit period, D=Delete period.,                                      ,
,
       ,--,Period,-- ,-------------------,Goal,-------------------
Action ,# ,Duration  ,Imp. ,Description
 ,__,  ,_,,_________, ,_,  ,________________________________________,
 ,__,  ,1,,_________, ,2,  ,90% complete within 00:00:01.000        ,

[zVlad]

Добавление ресурсов (серверов) это не только новые сервера, но и новое сетевое оборудование (и много чего другого), которое надо не только добавлять для обеспечения производительности, но для надежности дублировать. А потом получается простой из-за коммуникаций как недавно в BritishAirways.

Наглости и самоуверенности вам не занимать (попробуйте карьеру в Гербалайф).
British airways используют МФ и все равно виноваты другие ?!
У них был перебой в работе ровно из-за того, что их система оказалась не распределённая. Если бы у них был резервный датацентр, то в первом хоть ядерный взрыв произойди, все было бы нормально.

За незаслуженные обвинения Вам придется извиниться.

Пока я не видел доказательств что инцидент был именно с МФ. Заметка в стенгазете, где было слово "mainframe" без связи с инцидентом это не доказательство. Если у Вас что-нибудь существенно, плеасе. Я не отрицаю, кстати, что это могли бы быть МФ. Были МФ это тоже интересно было бы разобрать, но разобрать со всей информацией на руках. Которой мы вряд ли будем располагать. В ИТ не принято выворачиваться на изнанку.

Мои рассуждения как раз на том стрились что в случае МФ и в случае серьезного их применения, а BritishAirways это серьезно, всегда есть DR scenario, и если бы менеджеры BA поняли что система будет недоступной долго то могли бы декларировать DR и подняться без проблем на DR site.

У них был перебой в работе из-за системы энергоснабжения, перед которым все платформы равны. А Ваши любимые распределенные системы обычно оперируют терминoм HA - High Availability. В этом случае ставится запасной сервер рядом (в том же строении) с основным и в случае проблем с ПО основного (система упала, БД, etc...) работа переводится на запасной. Надеюсь Вам понятно что от потери электричества во всем строении эта мера не спасает. Упали оба, и основной и запасной серевера.

Я не утвержадаю что в распределенных системах невозможен DR scenario. Такое есть в нашей конторе. Но тесты DR с распределенными системами у нас редко проходят без проблем, очень редко. А в Феврале этого года мы дотеcтировались на распределенных системах до штрафных санкций от нашего клиента. Тесты DR с МФ за 17 лет моей работы в этой конторе ни разу не были неуспешными, ни разу. Было время мы по два раза в год тестировались.

[АццкоМото]

В этом случае ставится запасной сервер рядом (в том же строении) с основным и в случае проблем с ПО основного (система упала, БД, etc...) работа переводится на запасной. Надеюсь Вам понятно что от потери электричества во всем строении эта мера не спасает. Упали оба, и основной и запасной серевера.

Никто и никогда так не делает для серьезных применений. Мало того, что нормальные датацентры имеют резервные генераторы, которые при обвале питания заводятся за секунды и могут работать днями-неделями, функциональность принято дублировать в нескольких географически разнесенных датацентрах. курить можно тут, например: https://www.ibm.com/cloud-computing/blu ... ta-centers

[АццкоМото]

АццкоМото, дорогой, расскажите поподробнее. Вы должны понять как мне начинающему преподавателю в этой сфере это важно может быть.
Сколько времени потратили, какова была цель изучения, как узучали: самостоятельно или с инструктором, была ли достигнута цель и довелось ли попрактитоваться с этими системами, в каких ролях. Что помнится до сих пор. Примерно в этом ключе, пожалуйста. Если что захотите добавить, еще лучше, отдельное спасибо. Если не хотите это обсуждать публично - в личку.

Да что там рассказывать-то? В деццве у меня был доступ к библиотеке РАН, а там была литература, которая иначе была практически недоступна. В том числе талмуд по операционным системам, в оригинале и на английском. Да, тогда это было жутко интересно - когда вокруг тебя всякие Правецы, коммодоры и вершина - IBM PC под MS-DOS, даже про защищенную память читаешь, как про космос, а виртуализация вообще не помещается в мозг как концепт. Все самостоятельно, конечно, по началу - исключительно в теории. Немного позже попробовал немного 360, но не всерьез, к тому времени уже был 386 процессор и жизнь взбурлила именно там.
До сих пор помнится разве что обложка книги - я бы ее даже купил в качестве сувенира, если бы нашел сейчас

[zVlad]

В этом случае ставится запасной сервер рядом (в том же строении) с основным и в случае проблем с ПО основного (система упала, БД, etc...) работа переводится на запасной. Надеюсь Вам понятно что от потери электричества во всем строении эта мера не спасает. Упали оба, и основной и запасной серевера.

Никто и никогда так не делает для серьезных применений. Мало того, что нормальные датацентры имеют резервные генераторы, которые при обвале питания заводятся за секунды и могут работать днями-неделями, функциональность принято дублировать в нескольких географически разнесенных датацентрах. курить можно тут, например: https://www.ibm.com/cloud-computing/blu ... ta-centers

Не думал что надо будет разяснять. Когда я говорю DR scenario я имею в виду именно это: "географически разнесенныeх датацентры". Курю уже это семьнадцать лет.
Вопрос остается тем же: почему BA не возпользовался "географически разнесенных датацентрах"? Ваша ссылка ответить на этот вопрос никак не помогает.

[zVlad]

АццкоМото, дорогой, расскажите поподробнее. Вы должны понять как мне начинающему преподавателю в этой сфере это важно может быть.
Сколько времени потратили, какова была цель изучения, как узучали: самостоятельно или с инструктором, была ли достигнута цель и довелось ли попрактитоваться с этими системами, в каких ролях. Что помнится до сих пор. Примерно в этом ключе, пожалуйста. Если что захотите добавить, еще лучше, отдельное спасибо. Если не хотите это обсуждать публично - в личку.

Да что там рассказывать-то? В деццве у меня был доступ к библиотеке РАН, а там была литература, которая иначе была практически недоступна. В том числе талмуд по операционным системам, в оригинале и на английском. Да, тогда это было жутко интересно - когда вокруг тебя всякие Правецы, коммодоры и вершина - IBM PC под MS-DOS, даже про защищенную память читаешь, как про космос, а виртуализация вообще не помещается в мозг как концепт. Все самостоятельно, конечно, по началу - исключительно в теории. Немного позже попробовал немного 360, но не всерьез, к тому времени уже был 386 процессор и жизнь взбурлила именно там.
До сих пор помнится разве что обложка книги - я бы ее даже купил в качестве сувенира, если бы нашел сейчас

Да, не густо, но все равно спасибо. Как именно пробовали 360 не припомните? В общих словах хотя бы.

[АццкоМото]

В этом случае ставится запасной сервер рядом (в том же строении) с основным и в случае проблем с ПО основного (система упала, БД, etc...) работа переводится на запасной. Надеюсь Вам понятно что от потери электричества во всем строении эта мера не спасает. Упали оба, и основной и запасной серевера.

Никто и никогда так не делает для серьезных применений. Мало того, что нормальные датацентры имеют резервные генераторы, которые при обвале питания заводятся за секунды и могут работать днями-неделями, функциональность принято дублировать в нескольких географически разнесенных датацентрах. курить можно тут, например: https://www.ibm.com/cloud-computing/blu ... ta-centers

Не думал что надо будет разяснять. Когда я говорю DR scenario ya imeyu v vidu imenno e'to: "географически разнесенныeх датацентры". Купю уже это семьнадцать лет.
Вопрос остается тем же: почему BA не возпользовался "географически разнесенных датацентрах"? Ваша ссылка ответить на этот вопрос никак не помогает.

я вообще ни слова про ВА не сказал. просто у вас какое-то странное представление о мире за пределами МФ. типа там ставят два самосборных сервака, основной и запасной, и фтыкают в одну розетку через китайский тройник. это не так.

что случилось с ВА я понятия не имею

[АццкоМото]

АццкоМото, дорогой, расскажите поподробнее. Вы должны понять как мне начинающему преподавателю в этой сфере это важно может быть.
Сколько времени потратили, какова была цель изучения, как узучали: самостоятельно или с инструктором, была ли достигнута цель и довелось ли попрактитоваться с этими системами, в каких ролях. Что помнится до сих пор. Примерно в этом ключе, пожалуйста. Если что захотите добавить, еще лучше, отдельное спасибо. Если не хотите это обсуждать публично - в личку.

Да что там рассказывать-то? В деццве у меня был доступ к библиотеке РАН, а там была литература, которая иначе была практически недоступна. В том числе талмуд по операционным системам, в оригинале и на английском. Да, тогда это было жутко интересно - когда вокруг тебя всякие Правецы, коммодоры и вершина - IBM PC под MS-DOS, даже про защищенную память читаешь, как про космос, а виртуализация вообще не помещается в мозг как концепт. Все самостоятельно, конечно, по началу - исключительно в теории. Немного позже попробовал немного 360, но не всерьез, к тому времени уже был 386 процессор и жизнь взбурлила именно там.
До сих пор помнится разве что обложка книги - я бы ее даже купил в качестве сувенира, если бы нашел сейчас

Да, не густо, но все равно спасибо. Как именно пробовали 360 не припомните? В общих словах хотя бы.

В ИАПУ стояли совеццкие аналоги ойбеэмов (ЕС? я уже даже этого не помню) и пшиздрюков иногда пускали на них попрограммировать, иногда даже какие-то лекции читали. ощущения странные, вроде и круто, но при этом таааак кондово, что пипец

повторюсь, тогда уже началась эра ПК и с ними было интереснее

[zVlad]

В этом случае ставится запасной сервер рядом (в том же строении) с основным и в случае проблем с ПО основного (система упала, БД, etc...) работа переводится на запасной. Надеюсь Вам понятно что от потери электричества во всем строении эта мера не спасает. Упали оба, и основной и запасной серевера.

Никто и никогда так не делает для серьезных применений. Мало того, что нормальные датацентры имеют резервные генераторы, которые при обвале питания заводятся за секунды и могут работать днями-неделями, функциональность принято дублировать в нескольких географически разнесенных датацентрах. курить можно тут, например: https://www.ibm.com/cloud-computing/blu ... ta-centers

Не думал что надо будет разяснять. Когда я говорю DR scenario ya imeyu v vidu imenno e'to: "географически разнесенныeх датацентры". Купю уже это семьнадцать лет.
Вопрос остается тем же: почему BA не возпользовался "географически разнесенных датацентрах"? Ваша ссылка ответить на этот вопрос никак не помогает.

я вообще ни слова про ВА не сказал. просто у вас какое-то странное представление о мире за пределами МФ. типа там ставят два самосборных сервака, основной и запасной, и фтыкают в одну розетку через китайский тройник. это не так.

что случилось с ВА я понятия не имею

Вы взяли мою цитату для Ваших нравоучений именно из разговора о BA. Не заметили?
BA это не ИБМ BluMix, но и не с Луны свалились люди работающие в BA IT. Согласны? BA IT допустила 3-х дневный хаос со своими рейсами. Возражать не будите? Почему это оказалось возможным? Потому что они использовали МФ говорит oshibla_rezidenta. А Вы говорите потому что BluMix. Или как у "Уральских пельменей" - потому что гладиолусы.

[zVlad]

...
В ИАПУ стояли совеццкие аналоги ойбеэмов (ЕС? я уже даже этого не помню) и пшиздрюков иногда пускали на них попрограммировать, иногда даже какие-то лекции читали. ощущения странные, вроде и круто, но при этом таааак кондово, что пипец

повторюсь, тогда уже началась эра ПК и с ними было интереснее

Понятно. Наверное на Вашем месте у меня были бы такие же впечатления. Но я успел зацепиться за серьезные направления и на серьезном уровне до появления ПК. Чему, честно, очень рад. Вы должно быть понимаете что у меня достаточно практики в обоих мирах чтобы сравнивать предметно.