И производительность, и прямизна архитектуры в целом и архитектуры ввода-вывода в частности -- именно благодаря этому мэйнфреймы прекрасно виртуализируются, ну а по-настоящему качественных виртуализаций ПК не существует и вряд ли будет существовать (имеющиеся гипервизоры виртуализируют некоторое подмножество, достаточное для исполнения Винды/Линуха, но далеко не всегда способные работать с чем-то нестандартным; мэйнфреймы изначально виртуализировались абсолютно полностью, поэтому на виртуальной машине можно было творить ту же дичь с вводом-выводом, что и на реальном железе -- и всё работало).
Не уверен, но мне кажется, вы путаете разные технологии восстановления при сбоях и отказах железа - ECC для памяти и шин процессора и т.п. и в x86 уже работают достаточно давно
Нет, речь именно о возможности восстановления работы после сбоя/отказа, а не чисто схемы коррекции ошибок -- таковые в мэйнфреймах были очень давно, но они -- лишь техническая база, так сказать. Скажем, наша ЕС-1035 микроархитектурно содрана с IBM 370/145 (если правильно помню; кстати, это единственный известный мне случай, когда наша машина микроархитектурно повторяет IBMовскую -- остальные, с которыми разбирался, хотя и имеют большее или меньшее сходство, но имеют и серьёзные микроархитектурные отличия) на уровне железа поддерживала контроль и коррекцию управляющей (микропрограммной) и основной (оперативной) памяти по коду Хэмминга, а также умела выполнять сбойнувшие микрокоманды повторно -- отказ фиксировался, если 8 повторений оказывались безуспешными. Но всё это, как понимаете, -- чисто железные (или микропрограммные, что для программы безразлично) вещи, и никакой специальной поддержки со стороны ОС им не нужно: они работают сами по себе.
Вы уверены, что мэйнфрейм 1974 года обеспечивал такой функционал?
Если мэйнфрейм двухпроцессорный (что для 1974 года было редкостью, но таки было -- первые ещё в 1960-х появились), то да, такая возможность была. Ну а будет ли рестарт с текущего состояния или с контрольной точки, зависит от того, удалось ли сохранить текущее состояние в корректном виде, а это уже зависит от вида отказа -- но это и сейчас так.
Скажем, в ЕС-1033 (архитектурно это ещё Система 360 -- без MMU, а соответственно, без виртуальной памяти) блок диагностики работал абсолютно независимо от самого процессора, имел собственное микропрограммное управление и т.д. и т.п. Поэтому при отказе процессора он мог сам сохранить содержимое всех регистров в память -- естественно, при условии, что их содержимое не пострадало (контроль по нечётности), интерфейс с памятью работает и т.д.; другой процессор двухпроцессорного комплекса уведомлялся об отказе посредством прерывания, и ОС могла, проанализировав сохранённые данные, принять решение о дальнейших действиях.
Но вообще, даже на однопроцессорных машинах определённые средства и возможности были. В частности, полноценный обработчик машинных ошибок (MCH, machine check handler), который был предусмотрен для любой машины Системы 370 и для некоторых старших моделей Системы 360, старался сохранить работоспособность того, что можно. Например, если неустранимый сбой возник при выполнении прикладной программы, её дальнейшее выполнение оказывалось невозможным, но работоспособность системы и других программ сохранялась. Кроме того, если для сбойнувшей программы был предусмотрен перезапуск, он мог производиться автоматически (либо с её начала, либо с последней контрольной точки). Если система была с виртуальной памятью (это уже не классическая MFT/MVT, а SVS или MVS -- но тоже первая половина 1970-х) и вышел из строя блок памяти, но его содержимое не менялось с момента последней загрузки, производилась загрузка нужной страницы в другой блок памяти, после чего работа возобновлялась -- ну и т.д. и т.п. Понятно, что всё это в дальнейшем совершенствовалось, и поздняя MVS ушла далеко вперёд от MFT, но, тем не менее, всё это начиналось с самого начала, а не сильно позже, и достаточно успешно работало уже в MFT/MVT, где железо позволяло.
мой тезис в том, что сейчас в мире x86 и существующая технология полной защиты от аппаратных сбоев достаточно мало востребована - эти проблемы решаются на уровне архитектуры прикладного ПО, кластеризации, контейнеризации и т.п.
Мне кажется, что все эти решения не обеспечивают полной защиты от проблем с железом. Как, например, восстановить работоспособность программы, если сдох процессор и содержимого регистров на момент отказа нет (они где-то в процессоре остались)? Никак тут не восстановишь с момента сбоя -- только с последней контрольной точки, если таковая имеется, ну или вообще только запуском с самого начала. Ну а на мэйнфреймах в тех случаях, когда это технически возможно (содержимое памяти корректно и были успешно сохранены регистры процессора), работа пострадавшей программы продолжается именно с точки сбоя, буквально с команды, при выполнении которой сдох процессор.
Кроме того, защищаться путём соответствующей архитектуры прикладного ПО, естественно, можно -- но это резко усложняет это самое ПО и заставляет создавать необходимый функционал в каждой прикладной программе. В этом плане возможность разруливать ситуацию и обеспечивать восстановление на уровне аппаратуры и ОС для любого прикладного кода весьма ценна -- хотя, естественно, лучшие результаты достигаются в случае, когда и прикладное ПО спроектировано так, чтоб облегчать восстановление.
Для виртуальных машин. А что с самим гипервизором? Или с приложениями, работающими под управлением ОС на реальной, а не виртуальной машине?
Способность восстановления после сбоев или отказов аппаратуры IBM развивала, начиная ещё с Системы 360, т.е. со второй половины 1960-х годов. Это довольно неплохо работало уже в поздних версиях классической OS/360 (а её развитие прекратилось на версии 21.8 году эдак в 1972-74; дальше шли уже системы с виртуальной памятью, быстро превратившиеся в MVS, из которой выросла нынешняя z/OS). Т.е. то, что на "обычных компах" появилось 15 лет назад, IBM имеет уже с полвека.
Как правильно отметили, вопрос именно в сохранении работоспособности программы, которая пострадала при отказе техники. Мэйнфрейм (аппаратура + программная поддержка в ОС) очень часто способен продолжить её выполнение -- когда прямо с точки сбоя, когда с некоторой контрольной точки, которая была чуть раньше.
И куда больше времени тратится на согласование работы, выполняемой на физически разных машинах. Где-то это может быть несущественно, где-то -- очень важно.
Ну так и мэйнфреймы давным-давно уже микропроцессорные. Да и не сказать, что доступные микропроцессоры произвели какую-то революцию. Ну, вышел 8080 (первый более-менее полноценный микропроцессор), и что? Он лишь слегка подвинул мини-ЭВМ из их ниши, поскольку тягаться даже с самыми слабыми из них ему было, скажем так, проблематично. А к тому времени, как производительность микропроцессоров в достаточной степени увеличилась, мини-ЭВМ тоже превратились в микропроцессорные машины, а несколько позже то же самое сделали и мэйнфреймы.
Тут Вы ошибаетесь. И средства обработки аппаратных ошибок были с самого начала заложены в аппаратуру, и программная обработка и, по мере возможности, восстановление были предусмотрены ещё в MFT/MVT -- естественно, на тех моделях, которые позволяли это сделать. В частности, сбой (не полный отказ, а именно сбой) процессора или блока памяти при наличии MCH (он мог присутствовать для некоторых моделей Системы 360 и был обязателен для любых моделей Системы 370) во время выполнения прикладной задачи приводил к аварийному завершению этой задачи, а не системы в целом; всё остальное продолжало работать -- ну а сбойнувшая задача при определённых условиях могла быть перезапущена с контрольной точки. Макрокоманда STAE тоже была предусмотрена с самого начала. В MVS очень сильно расширяли расширили и дополнили уже имевшиеся механизмы и, в конце концов, довели их до ума, но сказать, что только в ней начали, будет некорректно.
z/OS просто не может быть "невероятно старой" -- для перехода на 64 разряда все собственно системные вещи пришлось переписать по, надеюсь, очевидным причинам. Это OS/360 невероятно старая -- но таки да, написанные под неё программы могут выполняться в z/OS без каких-либо изменений.
И, кстати, в MVT процессов не было. Были задания, задачи, подзадачи, были разделы памяти -- но не процессы.
А ещё кстати -- OS/370 в природе не существует. А Геркулес умеет запускать хоть древние системы, хоть современные.
Ну, во-первых, мэйнфреймы отлично масштабируются. При нужде досыпать процессоров и памяти, как правило, проблемой не является.
Во-вторых, ничто не мешает поставить два мэйнфрейма в физически разных местах, чтобы уберечь от всяких там бедствий (точно так же, как и обычные серверы придётся ставить в разных местах).
Есть нюансы. Во-первых, выполнение некоего тяжёлого приложения на единой машине с 100500 процессоров и гигантским объёмом ОЗУ, в общем и целом, эффективнее, чем работа на 100500 хилых машинах со связью по локальной сети. Во-вторых, вопросы надёжности и восстановления после сбоев: с IBM тут тягаться тяжело, всё ж они на этой теме были зациклены ещё с 1960-х годов. Ну а в-третьих, в эксплуатации один мэйнфрейм может оказаться дешевле, чем куча обычных серверов.
Но, понятно, все эти вопросы дискуссионные, и в разных ситуациях можно получить разные результаты.
Что, в какой-то момент длину имён наборов данных увеличили? В классической OS/360 она составляет максимум 44 символа, а не 144. Или это опечатка?
В "доисторической эре" не упомянут режим PCP -- однопрограммный. Самая первая версия OS/360 работала именно в этом режиме, поскольку IBM не успевала сделать всё, что хотела, причём для работы было достаточно 32 Кбайта памяти (примерно 14 занимало ядро системы, остальное уходило под программу пользователя или системную программу, не входящую в состав ядра). По мере развития системы требования к памяти росли; самые последние варианты PCP требовали 64 Кбайта. В конце концов, этот режим полностью выпилили, и самым младшим стал MFT, требующий к тому моменту 128 Кбайт (на момент своего появления ему было достаточно 64).
Не отмечена также изначально (или почти изначально) присутствовавшая возможность для прикладных программ создавать контрольные точки (checkpoint), чтобы в случае какого-то сбоя система могла возобновить выполнение программы с этой точки, а не с самого начала.
Вроде бы, какие размеры должен иметь транзистор с такими параметрами, как современный, если его делать по образу и подобию более ранних, где нанометры ещё обозначали реальные размеры. Но утверждать не берусь -- я не специалист по микроэлектронному производству, да ещё суперпередовому :)
Возможно, это зависит от конкретной модели мэйнфрейма -- в последние могли и внедрить некую защиту от нелицензионного использования.
И производительность, и прямизна архитектуры в целом и архитектуры ввода-вывода в частности -- именно благодаря этому мэйнфреймы прекрасно виртуализируются, ну а по-настоящему качественных виртуализаций ПК не существует и вряд ли будет существовать (имеющиеся гипервизоры виртуализируют некоторое подмножество, достаточное для исполнения Винды/Линуха, но далеко не всегда способные работать с чем-то нестандартным; мэйнфреймы изначально виртуализировались абсолютно полностью, поэтому на виртуальной машине можно было творить ту же дичь с вводом-выводом, что и на реальном железе -- и всё работало).
Если аж 1990-й, то это ещё не z/OS -- до неё ещё 10 лет. Получается, уже на машинах ESA/390 сделали (а может, и на поздних ESA/370).
Про подобную реализацию не знал. Век живи -- век учись (и дураком помрёшь :) ).
Нет, речь именно о возможности восстановления работы после сбоя/отказа, а не чисто схемы коррекции ошибок -- таковые в мэйнфреймах были очень давно, но они -- лишь техническая база, так сказать. Скажем, наша ЕС-1035 микроархитектурно содрана с IBM 370/145 (если правильно помню; кстати, это единственный известный мне случай, когда наша машина микроархитектурно повторяет IBMовскую -- остальные, с которыми разбирался, хотя и имеют большее или меньшее сходство, но имеют и серьёзные микроархитектурные отличия) на уровне железа поддерживала контроль и коррекцию управляющей (микропрограммной) и основной (оперативной) памяти по коду Хэмминга, а также умела выполнять сбойнувшие микрокоманды повторно -- отказ фиксировался, если 8 повторений оказывались безуспешными. Но всё это, как понимаете, -- чисто железные (или микропрограммные, что для программы безразлично) вещи, и никакой специальной поддержки со стороны ОС им не нужно: они работают сами по себе.
Если мэйнфрейм двухпроцессорный (что для 1974 года было редкостью, но таки было -- первые ещё в 1960-х появились), то да, такая возможность была. Ну а будет ли рестарт с текущего состояния или с контрольной точки, зависит от того, удалось ли сохранить текущее состояние в корректном виде, а это уже зависит от вида отказа -- но это и сейчас так.
Скажем, в ЕС-1033 (архитектурно это ещё Система 360 -- без MMU, а соответственно, без виртуальной памяти) блок диагностики работал абсолютно независимо от самого процессора, имел собственное микропрограммное управление и т.д. и т.п. Поэтому при отказе процессора он мог сам сохранить содержимое всех регистров в память -- естественно, при условии, что их содержимое не пострадало (контроль по нечётности), интерфейс с памятью работает и т.д.; другой процессор двухпроцессорного комплекса уведомлялся об отказе посредством прерывания, и ОС могла, проанализировав сохранённые данные, принять решение о дальнейших действиях.
Но вообще, даже на однопроцессорных машинах определённые средства и возможности были. В частности, полноценный обработчик машинных ошибок (MCH, machine check handler), который был предусмотрен для любой машины Системы 370 и для некоторых старших моделей Системы 360, старался сохранить работоспособность того, что можно. Например, если неустранимый сбой возник при выполнении прикладной программы, её дальнейшее выполнение оказывалось невозможным, но работоспособность системы и других программ сохранялась. Кроме того, если для сбойнувшей программы был предусмотрен перезапуск, он мог производиться автоматически (либо с её начала, либо с последней контрольной точки). Если система была с виртуальной памятью (это уже не классическая MFT/MVT, а SVS или MVS -- но тоже первая половина 1970-х) и вышел из строя блок памяти, но его содержимое не менялось с момента последней загрузки, производилась загрузка нужной страницы в другой блок памяти, после чего работа возобновлялась -- ну и т.д. и т.п. Понятно, что всё это в дальнейшем совершенствовалось, и поздняя MVS ушла далеко вперёд от MFT, но, тем не менее, всё это начиналось с самого начала, а не сильно позже, и достаточно успешно работало уже в MFT/MVT, где железо позволяло.
Мне кажется, что все эти решения не обеспечивают полной защиты от проблем с железом. Как, например, восстановить работоспособность программы, если сдох процессор и содержимого регистров на момент отказа нет (они где-то в процессоре остались)? Никак тут не восстановишь с момента сбоя -- только с последней контрольной точки, если таковая имеется, ну или вообще только запуском с самого начала. Ну а на мэйнфреймах в тех случаях, когда это технически возможно (содержимое памяти корректно и были успешно сохранены регистры процессора), работа пострадавшей программы продолжается именно с точки сбоя, буквально с команды, при выполнении которой сдох процессор.
Кроме того, защищаться путём соответствующей архитектуры прикладного ПО, естественно, можно -- но это резко усложняет это самое ПО и заставляет создавать необходимый функционал в каждой прикладной программе. В этом плане возможность разруливать ситуацию и обеспечивать восстановление на уровне аппаратуры и ОС для любого прикладного кода весьма ценна -- хотя, естественно, лучшие результаты достигаются в случае, когда и прикладное ПО спроектировано так, чтоб облегчать восстановление.
Для виртуальных машин. А что с самим гипервизором? Или с приложениями, работающими под управлением ОС на реальной, а не виртуальной машине?
Способность восстановления после сбоев или отказов аппаратуры IBM развивала, начиная ещё с Системы 360, т.е. со второй половины 1960-х годов. Это довольно неплохо работало уже в поздних версиях классической OS/360 (а её развитие прекратилось на версии 21.8 году эдак в 1972-74; дальше шли уже системы с виртуальной памятью, быстро превратившиеся в MVS, из которой выросла нынешняя z/OS). Т.е. то, что на "обычных компах" появилось 15 лет назад, IBM имеет уже с полвека.
Как правильно отметили, вопрос именно в сохранении работоспособности программы, которая пострадала при отказе техники. Мэйнфрейм (аппаратура + программная поддержка в ОС) очень часто способен продолжить её выполнение -- когда прямо с точки сбоя, когда с некоторой контрольной точки, которая была чуть раньше.
И куда больше времени тратится на согласование работы, выполняемой на физически разных машинах. Где-то это может быть несущественно, где-то -- очень важно.
Ну так и мэйнфреймы давным-давно уже микропроцессорные. Да и не сказать, что доступные микропроцессоры произвели какую-то революцию. Ну, вышел 8080 (первый более-менее полноценный микропроцессор), и что? Он лишь слегка подвинул мини-ЭВМ из их ниши, поскольку тягаться даже с самыми слабыми из них ему было, скажем так, проблематично. А к тому времени, как производительность микропроцессоров в достаточной степени увеличилась, мини-ЭВМ тоже превратились в микропроцессорные машины, а несколько позже то же самое сделали и мэйнфреймы.
Тут Вы ошибаетесь. И средства обработки аппаратных ошибок были с самого начала заложены в аппаратуру, и программная обработка и, по мере возможности, восстановление были предусмотрены ещё в MFT/MVT -- естественно, на тех моделях, которые позволяли это сделать. В частности, сбой (не полный отказ, а именно сбой) процессора или блока памяти при наличии MCH (он мог присутствовать для некоторых моделей Системы 360 и был обязателен для любых моделей Системы 370) во время выполнения прикладной задачи приводил к аварийному завершению этой задачи, а не системы в целом; всё остальное продолжало работать -- ну а сбойнувшая задача при определённых условиях могла быть перезапущена с контрольной точки. Макрокоманда STAE тоже была предусмотрена с самого начала. В MVS очень сильно расширяли расширили и дополнили уже имевшиеся механизмы и, в конце концов, довели их до ума, но сказать, что только в ней начали, будет некорректно.
z/OS просто не может быть "невероятно старой" -- для перехода на 64 разряда все собственно системные вещи пришлось переписать по, надеюсь, очевидным причинам. Это OS/360 невероятно старая -- но таки да, написанные под неё программы могут выполняться в z/OS без каких-либо изменений.
И, кстати, в MVT процессов не было. Были задания, задачи, подзадачи, были разделы памяти -- но не процессы.
А ещё кстати -- OS/370 в природе не существует. А Геркулес умеет запускать хоть древние системы, хоть современные.
А, например, при отказе процессора или блока памяти?
Угу. Вот только не diag, а просто ДИАГНОСТИКА -- у неё официально нет мнемоники. Впрочем, это уже придирки :)
Ну да, хотел про однопользовательскую сказать :)
У нас в СВМ гипервизор именовался монитором виртуальных машин (МВМ); супервизор же был, в первом приближении, ядром DOS/360 и OS/360, но не VM/370.
ПДО -- да, однозадачная ОС, предназначенная для эксплуатации исключительно под СВМ, поэтому-то никаких команд ввода-вывода в ней нет.
Пы.Сы. А Мастер Шедулер -- это уже про ОС/360, она же ОС ЕС :)
Ну, во-первых, мэйнфреймы отлично масштабируются. При нужде досыпать процессоров и памяти, как правило, проблемой не является.
Во-вторых, ничто не мешает поставить два мэйнфрейма в физически разных местах, чтобы уберечь от всяких там бедствий (точно так же, как и обычные серверы придётся ставить в разных местах).
Есть нюансы. Во-первых, выполнение некоего тяжёлого приложения на единой машине с 100500 процессоров и гигантским объёмом ОЗУ, в общем и целом, эффективнее, чем работа на 100500 хилых машинах со связью по локальной сети. Во-вторых, вопросы надёжности и восстановления после сбоев: с IBM тут тягаться тяжело, всё ж они на этой теме были зациклены ещё с 1960-х годов. Ну а в-третьих, в эксплуатации один мэйнфрейм может оказаться дешевле, чем куча обычных серверов.
Но, понятно, все эти вопросы дискуссионные, и в разных ситуациях можно получить разные результаты.
Что, в какой-то момент длину имён наборов данных увеличили? В классической OS/360 она составляет максимум 44 символа, а не 144. Или это опечатка?
В "доисторической эре" не упомянут режим PCP -- однопрограммный. Самая первая версия OS/360 работала именно в этом режиме, поскольку IBM не успевала сделать всё, что хотела, причём для работы было достаточно 32 Кбайта памяти (примерно 14 занимало ядро системы, остальное уходило под программу пользователя или системную программу, не входящую в состав ядра). По мере развития системы требования к памяти росли; самые последние варианты PCP требовали 64 Кбайта. В конце концов, этот режим полностью выпилили, и самым младшим стал MFT, требующий к тому моменту 128 Кбайт (на момент своего появления ему было достаточно 64).
Не отмечена также изначально (или почти изначально) присутствовавшая возможность для прикладных программ создавать контрольные точки (checkpoint), чтобы в случае какого-то сбоя система могла возобновить выполнение программы с этой точки, а не с самого начала.
Нету у С/С++ "абсолютного контроля над аппаратурой и памятью", абсолютный есть только у ассемблера.
Вроде бы, какие размеры должен иметь транзистор с такими параметрами, как современный, если его делать по образу и подобию более ранних, где нанометры ещё обозначали реальные размеры. Но утверждать не берусь -- я не специалист по микроэлектронному производству, да ещё суперпередовому :)