Запуск нескольких ОС. Виртуальные серверы. Эффективное использование ресурсов
Я объединил эти три причины в одну потому что все они есть следствие того что, да, виртуальные машины позволяют выполнять на одной физической машине несколько одинаковых или разных ОС.
Собственно это единственное что отличает традиционную ОС от систем виртуальных машин.
Тестирование. Изоляция и безопасность
Первое — тестирование — это прикладное следствие второго — изоляция и безопасность. А только ли виртуальные машины могут обеспечить изоляцию и безопасность. Разве в традиционных системах эту проблему не решают их разработчики?
Самые ранние компьютеры способны были выполнять ровно одну задачу (программу). Функции первых «ОС» сводились к загрузке готовой для выполнения программы и передачи ей управления компьютером. Сама «ОС» (загрузчик) с этого момента исчезала и всем компьютером управляла прикладная программа. Она была максимально изолирована от любых воздействий.
Как только перед компьютером была поставлена задача быть способным выполнять больше одной задачи для одного пользователя так сразу возникла и начала решаться проблема изоляции и безопасности. Насколько успешно решалась эта проблема в первую очередь определялось тем какие технические средства предоставлял тот или иной компьютер. Т.е. его архитектурой и принципами работы.
Современные компьютеры обладают развитыми средствами обеспечения изоляции и безопасности. Таким образом с теоретической точки зрения совершенно не обязательно называть метод обеспечения изоляции и безопасности виртуальной машиной.
И это на самом деле уже имеет место быть во всех современных ОС на любых современных компьютерах. Windows, Linux, Unix, z/OS, Solaris, HP‑UX, AIX.
Гибкость и масштабируемость. Общий итог
Предложим в нашей организации имеется один физический сервер и мы выполняем на нем некоторую полезную работу. На начальном этапе работ было немного и сервер был недогружен, простаивал. Организация наша развивалась и количество работ росло. Однажды наш сервер оказался загружен полностью и нужные работы выполнять оказался не в состоянии.
Могут ли в этом случае помочь виртуальные машины? Нет не могут. Пусть даже мы с самого начала использовали наш сервер под какой‑либо системой виртуальных машин и под новые работы создавали новые ВМ, а не запускали их под одной традиционной ОС разделения ресурсов. Утверждение № 1: В случае с ВМ мы бы достигли физического насыщения нашего сервера гораздо раньше чем имея одну традиционную систему и все работы в ней.
Доказательство утверждения № 1. Обеспечение виртуальной машины добавляет издержки виртуализации. Во‑первых, потому что ряд функций, могущих быть непосредственно выполняемые компьютером, в среде виртуальных машин, из‑за изоляции и безопасности, требуется программно эмулировать под контролем гипервизора. Во‑вторых, виртуальная память ОС на виртуальной машине и виртуальная память гипервизора для виртуальной машины это двойная виртуализация. Виртуализация виртуальной памяти. Эта проблема теоретически решаема, но во всех ли гипервизорах она решена на самом деле? В‑третьих, ввод‑вывод. Могут быть огромные издержки в зависимости от конкретных архитектур ввода‑вывода конкретных компьютеров. Ну и в‑четвертых, в системах виртуальных машин по определению присутствуют два супервизора повторяющих одну и ту же работу. Это только вербально можно назвать их по разному: супервизором (ОС ВМ) и гипервизором собственно системы виртуальных машин. Но теоретически можно объединить эти два в одно и избежать издержки..
Так что никакой гибкости ни масштабируемости виртуальные машины не предоставляют. Разве что для организаций предоставляющих облачные сервисы это находка, да и то только потому что пользователи облачных сервисов оплачивают все издержки и дают прибыль.
Допущение в этом сценарии лишь одно — традиционная ОС обеспечивает требуемый уровень изоляции и безопасности.
Чем и кого на самом деле "покорили" виртуальные машины
Как уже говорилось выше, виртуальные машины очень хороши для ЦОД‑ов. Как говорится с миру по нитке голому рубашка. Под лозунгом удешевления расходов на ИТ отдельных потребителей внедрен метод повышающий суммарные расходы, разделяемыми между пользователями ЦОД‑ов.
Есть один сценарий (их больше на самом деле, но статья не про ЦОД) когда ЦОД‑ы делают благое дело и снижают общие расходы. В самом деле, если сервер некоего пользователя недогружен, то он получает уменьшенную отдачу от этого сервера. То есть опосредовано несет убытки. В ЦОД на такой сервер поставят виртуальные машины и добавят на него других пользователей.
Но, поскольку в общем случае, организации нуждаются в более чем одном сервере, то уже появляется возможность хорошо загрузить сервера (с теми же виртуальными машинами как в ЦОД или без них) за исключением может быть одного. И это будет дешевле хотя бы потому что не надо делать прибыль ЦОД. Но статья не про ЦОД.
Что еще? Обратите внимание на то что систем виртуальных машин не меньше чем число крупных игроков в сфере ИТ. Каждый уважающий себя вендор создал свою систему виртуальных машин. Все они по сути одинаковы. (Поэтому например на МФ есть ровно одна — zVM. В самом деле зачем ИБМ делать много одного и того же. Правда на МФ появилась KVM. Это уже коммерция).
Почему их (систем ВМ) так много? Потому что каждый крупный игрок в ИТ должен иметь свою нишу во всех популярных ИТ технологиях и, главное, получить свою долю ИТ пирога. Чтобы не так была заметна игровая составляющая этим системам даются разные названия. В теории достаточно одной системы ВМ на каждую аппаратную платформу.
Еще виртуальные машины дали много поводов ИТ‑шникам которым просто нравится их работа и они хотят получать новые впечатления от новых технологий. Это позволяет им гордиться собой и писать статьи про свои успехи здесь на Хабр‑е. Можно их за это судить? Нет конечно. Это самые безобидные и безвредные бенефициары технологии ВМ..
Что делать?
Учиться у продвинутых и недооценённых конкурентов. У ИБМ в этом случае. Как говорил герой одного из советских фильмов устами Ролана Быкова: «Ищи друзей своих среди врагов своих и ты будешь могуч и непобедим„. “»
В предыдущей моей статье про виртуальные машины я описывал эволюцию ОС на МФ и ее текущее состояние.
Вкратце. Традиционные системы разделение ресурсов (включая время процессора) и система виртуальных машин появились на МФ практически одновременно. Был период когда руководство ИБМ решало, а не «убить» ли VM. Случилось это потому что была начата и велась разработка другой ОС (кстати системы ВМ это не ОС) долженствующей объединить традиционную ОС с виртуальными машинами. Сделать два в одном. А точнее одно вместо двух, но такое что лучше двух.
В итоге так и получилось. Но совсем VM не умерла. Её идеи воплотились в PR/SM (Processor Resource/Systems Manager) (произносится как «призм»). Сделали это на уровне ниже архитектуры собственно МФ:
The Processor Resource/Systems Manager (PR/SM) is the built‑in hardware and microcode (which includes millicode) that manages the logical partitioning (LPAR) of a mainframe's physical resources.
В комментариях к первой статье про виртуальные машины я утверждал что в процессорах МФ используется не только микрокод, то есть имеется более одного уровня программирования в процессоре, но и (я назвал это там макрокод). Это на самом деле милликод:
В мэйнфреймах IBM милликод — это форма низкоуровневого программирования (высокоуровневая форма микрокода), используемая для реализации сложных или специализированных инструкций процессора и функций системного уровня. Он выполняется непосредственно на аппаратном обеспечении основного процессора, используя те же методы оптимизации производительности, что и обычное программное обеспечение, но работает в защищенной среде с более высокими привилегиями и доступом к специальным, недоступным пользователю инструкциям и регистрам.
Ключевые функции и особенности
Реализация сложных инструкций:
процедуры милликода используются для построения сложных инструкций из последовательности более простых внутренних операций, упрощая аппаратную реализацию этих функций. Примерами служат некоторые инструкции ввода‑вывода и команды обработки данных, такие как MVCL (перемещение длинных символов).
Управление системой и восстановление:
выполняет критически важные системные функции, такие как инициализация, восстановление после ошибок и другие операции управления, которые должны быть надежными и выполняться с высоким уровнем привилегий.
Непрерываемое выполнение (Non‑Interruptible Execution):
функции Millicode, как правило, не прерываются, что критически важно для операций, которые должны выполняться без помех, таких как обновление нескольких хранилищ или выполнение заблокированных операций, что делает их быстрее, чем вызов службы операционной системы.
Гибкость
Millicode обеспечивает значительную гибкость в проектировании системы, позволяя реализовывать и обновлять сложные архитектурные функции гораздо проще, чем при их аппаратном внедрении в схему.
Производительность:
Использование Millicode может выполнять те же функции быстрее, чем использование служб операционной системы, поскольку он работает на более высоком уровне привилегий и позволяет избежать некоторых программных накладных расходов.
Защищённая память (Protected Storage ):
Millicode находится в защищённой области памяти, называемой аппаратной системной областью, которая недоступна для обычных операционных систем или прикладных программ, что обеспечивает целостность системы.
Отличие от микрокода
Хотя эти термины родственны, Millicode — это усовершенствование по сравнению с традиционным микрокодом. Для работы традиционного микрокода часто требуется отдельный специализированный процессор, в то время как Millicode работает на том же высокопроизводительном процессоре общего назначения, что и пользовательское программное обеспечение, что позволяет использовать все технологии и оптимизации основного процессора.
Таким образом VM на МФ переродился в возможность железа, а основной ОС МФ стал z/OS. Для z/OS не нужно тысяч виртуальных машин. Достаточно такого количества партиций сколько позволяет создавать PR/SM на одном МФ. Если этого мало добавить еще МФ. Их много на самом деле не надо во многих случаях построения ИТ.
Нет, конечно, zVM до сих пор существует, продается и используется. Но главным образом на МФ называемых LinuxONE, для создания тысяч виртуалок для Linux.
Вернемся к z/OS аналогов которому в мире х86 нет. Современный z/OS это симбиоз трех традиционных операционных систем: MVS, Unix (USS — Unix System Services) и Linux в форме IBM® z/OS® Container Extensions (IBM zCX):
IBM z/OS Container Extensions (zCX) is a new z/OS 2.4 feature that enables clients to deploy Linux applications as Docker containers on z/OS as part of a z/OS workload. This maintains operational control of the Linux environment within z/OS, brings z/OS qualities of service to the application deployment, and does not require the provisioning of separate LPARs or system images.
IBM zCX expands and modernizes the z/OS software ecosystem by allowing applications and workloads built for Linux on Z and packaged into a Docker image to run on z/OS.
z/OS 2.4 это конец 2019. Не поддерживается ИБМ с 30 сентября 2024 года. Текущя версия z/OS это z/OS 3.2 анонсирована 30 сентября 2025 года.
Вот такое будущее могло бы быть на платформе х86-64. Сервера на основе Интел (Xeon) процессорах это весьма мощные машины. Но нет адекватного системного программного обеспечения и адекватной системы ввода‑вывода. Об этом писали в комментариях к первой статье про виртуальные машины.
Нужно решение для аппаратного деления сервера х86-64 на разделы (партиции) и нужна качественная система разделения ресурсов, которая могла бы обойтись без костылей, называемых виртуальные машины. Возможно это будет результатом дальнейшего развития Docker. В Docker есть похожие на MVS идеи, но их еще надо очистить от решения частных проблем, найти в них общее, видоизменить и довести до совершенства. За модель для подражание (но не копирование) можно взять как раз MVS.
Заключение: Виртуальные машины на платформе х86-64 не имеют будущего. Это временное, переходное решение на пути к назревшей модернизации х86-64 (добавлению партиций) и созданию настоящей традиционной ОС разделения ресурсов на х86-64.
Конец статьи.
P. S. Уже после публикации этой статьи я нашел в англоговорящем интернете форум где был опубликован вот такой пост (без комментарий):
Sorry if this is a stupid question, but I have seen a few posts on this sub talking about creating several virtual machines on a server in order to run various services. Why can't we just install everything on the base OS? Surely it's counter‑intutitive to virtualize an operating system for each service?
Комментарии (32)
vindy
03.11.2025 02:31Нужен ли ИИ-слоп на Хабре? Я задал этот вопрос "автору" "статьи" и не получил ответа.
ermouth
03.11.2025 02:31Вы в профиль то зайдите, как и @krote. Тут убеждения и опыт, настоящие, сейчас таких почти не делают. Так что молодец, что пишет – пусть имхо и небесспорные вещи.
zVlad909 Автор
03.11.2025 02:31Бесспорные вещи никому не интересны. Я специально делаю перегибы чтобы вызвать реакцию публики. И заставить тех кто способен думать подумать и может выйти за рамки привычных вещей.
ermouth
03.11.2025 02:31Нужны ли виртуальные машины?
Виртуальные машины на платформе х86-64 не имеют будущего.
Нужны, и никуда они не денутся. Партиционирование не закрывает целый класс явлений, например:
Устаревших платформ становится только больше, и этот процесс не остановится по очевидным причинам. Их надо как-то поддерживать, и обеспечивать совместимость нового софта хотя-бы с несколькими версиями платформ, одновременно представленных на рынке очень даже массово.
Скорость разработки растёт, а во время разработки накладные расходы не играют прямо какой-то решающей роли.
ВМ обеспечивают лучшую в моменте гибкость – хоть и ценой ухудшения изоляции, безопасности, надёжности, производительности и пр. Однако в целом достигнутые даже коммодити-устройствами характеристики настолько хороши, что это мало где заметно, и ещё меньше где критично.
В целом аргументы автора примерно уровня «частный транспорт это тупик, потому что есть общественный». Да пофиг всем на эффективность, безопасность и пр. Если оно ездит от подъезда до подъезда, на то что 4 из 5 сидений пустые, никто внимания не обращает. Сколько mass transit не улучшай, от подъезда до подъезда он возить не будет.
zVlad909 Автор
03.11.2025 02:31Судя по Вашему образу мышления Вы программист/разработчик программ. Я имею в иду что Вы не системшик, который занимается процессами выполнения программ. Разных программ от разных раработяиков.
Это два разных образа мыления и понимания.
Из этой Вашей фразы:
ВМ обеспечивают лучшую в моменте гибкость – хоть и ценой ухудшения изоляции, безопасности, надёжности, производительности и пр.
Напрашивается только один вывод - Вы не совсем в курсе что такое система виртуальных машин и чем она лучше чем традиционные ОС х86-64. Именно изоляция и безопасность считается (не мною) достоинством ВМ.
Статья про эволюцию системного программного обеспечения на МФ, и попытка объяснить почему такой же путь ждет и системное ПО х86-64. Может и не ждет, я не пророк и не экстрасенс, но видя что эволюция на МФ объективно и что х86-64 идет по ее стопам я взял на себя право порассуждать о том что ждет нынешнюю молодежь в сфере х86-64. К чему ей не грех готовится. А время бысто летит.
ermouth
03.11.2025 02:31Простите, но вам вредит развешивание ярлыков, категоричность и не слишком обоснованные догадки по поводу «образа мышления». Образ мышления у меня – не программиста и не системщика, оба этих рода занятий я считаю просто полезными побочными скиллами.
Давайте я вам задам вопрос: ВМ исполняемая на ФС смонтированной из файла хостовой системы, будет более безопасной и изолированной, чем с аппаратно приколоченной партиции? Вопрос, конечно, не совсем честный – у меня просто был вполне практический кейс.
Ещё нюанс: ВМ по-разному используются, в том числе вполне себе в бытовых условиях. Этот момент у вас полностью упущен в рассуждениях – а он ой как важен.
что ждет нынешнюю молодежь в сфере х86-64
Я полагаю, что эта платформа будет терять рынок, как коммодити-устройств, так и в облаках/цодах.
А в целом, спасибо, что пишете – пишите ещё!
zVlad909 Автор
03.11.2025 02:31Извините. Намерений обидеть не было.
Давайте я вам задам вопрос: ВМ исполняемая на ФС смонтированной из файла хостовой системы, будет более безопасной и изолированной, чем с аппаратно приколоченной партиции? Вопрос, конечно, не совсем честный – у меня просто был вполне практический кей
Я не специалист по безопасности на х86. Да и терминологией такой не владею.
Ещё нюанс: ВМ по-разному используются, в том числе вполне себе в бытовых условиях. Этот момент у вас полностью упущен в рассуждениях – а он ой как важен.
Все охватить не возможно. Другие мне тоже говорят о моих упущениях.
Я полагаю, что эта платформа будет терять рынок, как коммодити-устройств, так и в облаках/цодах.
А что по-Вашему будет приходить взамен? По работе в корпоративной ИТ я вижу как именно х86-64 все платформы вытесняет.
Спасибо за доброе пожелание.
ermouth
03.11.2025 02:31А что по-Вашему будет приходить взамен?
Мои ощущения более-менее совпадают с прогнозам, что мне в руки попадаются последние года два-три. ARM захватил мобильный рынок практически полностью, и пошёл в десктопы, ноутбуки и сервера. На сейчас по последнему пункту оценки – 10…15% рынка, но вне зависимости от конкретной цифры все отмечают медленный, но постоянный рост этой доли.
Интелы относительно АРМов существенно более прожорливы, и победить это не получится никак. При массовых вычислениях это, по-моему, совершенно непроходимое препятствие для x86-64. Думаю, лет через 10 доли сравняются.
Ну и в эмуляции замечательные успехи наблюдаются.
Приведу всего один факт – на моём ноутбуке с М3 авиасимулятор написанный под x86-64 даёт под эмулятором фреймрейт выше, чем 4,5ГГц интел на десктопе. И это при разнице в потребляемой мощности на порядок. Это как паровозы с тепловозами сравнивать.
arx3889
03.11.2025 02:31ВМ исполняемая на ФС смонтированной из файла хостовой системы, будет более безопасной и изолированной, чем с аппаратно приколоченной партиции?
В статье про другие партиции речь.
ermouth
03.11.2025 02:31Разве не про LPAR?
arx3889
03.11.2025 02:31Да, судя по всему про них.
Тогда что значит "грузиться с ... партиции", если речь все-таки шла не о дисковых разделах?
После прочтения статей автора я понимаю так, что грузиться можно "в", т.е. внутри партиции. А "с" партиции - не имеет смысла.
zVlad909 Автор
03.11.2025 02:31... и не слишком обоснованные догадки по поводу «образа мышления». Образ мышления у меня – не программиста и не системщика, оба этих рода занятий я считаю просто полезными побочными скиллами.
Я бы хотел объяснить по поводу "ярлыков". На МФ всегда было и есть четкое разделение между системщиками и программистами. Это идет от природы МФ и его ОС. Видел я системщиков, которые не писали программ и не собирались этого делать. Или DBA которому система и программирование до лампочки.
Сам я начинал как программист, потом стал системщиком, но программировать понемногу никогда не прекращал, и DBA был тоже. Знаю всех их образы мышления. Естественно в области ИТ, не вообще. Вообще все люди разные.
На х86-64 такого разделения нет. Программисты зачастую знают систему лучше чем какой-нибудь администратор. DBA лезут в программировани, а администраторы только и делают что патчат секьюрити. Ну и ставят новые и новые сервера, а пользователи все просят и просят эти сервера ставить и никогда от них не отказываются. Благо что есть облака и виртуальные машины.
Ну и для кого скилсы, а для кого способ зарабатывания на жизнь.
AndreyDmitriev
03.11.2025 02:31Не только на серверном, но и на прикладном уровне нужны - каждые три года наша компания полностью меняет компы, так что настроенные среды разработки бывает удобнее держать развернутыми в виртуалках, ну и для тестирования инсталляшек и ПО на различных ОС тоже удобнее делать в ВМ, легко откатываясь к чистой установке, так что виртуальные машины удобны и нужны, хотя я и предпочитаю работать без ВМ если нет особой необходимости.
zVlad909 Автор
03.11.2025 02:31Раскажу вкратце как я делал переходы с одного МФ на другой, новый МФ. За последние 20 лет я это делал в рамках одной организации раз наверное десять (потому что у нас два МФ и каждый в отдельности обновлялся).
ИБМ прикатывал и ставил новый МФ рядом со старым. Я создавал нужную нам конфигурацию для нового МФ (по сути это копия старой с небольшими модификациями связанными с новыми возможностями нового МФ). Затем мы перебрасывали несколько кабелей (оптоволоконных) ввода-вывода со старого на новый. Это чтобы внешнее оборудование (диски, ленты, сетевые коммуникации) стало доступно новому МФ тоже. Чтобы было понятно на МФ всего все дублируется и можно спокойно отключать часть из коммуникаций. А чтобы понятно было еще лучше скажу что все ПО и системеное и прикладное находятся на внешних устройствах МФ. Далее.
В соглавсованное с программистами время я останавливал систему программистов на старом МФ и тут же загружал ее на новом. Полчаса-час и программисты уже работают на новом МФ. Продакшн система пока остается на старом МФ.
В согласованное с бизнесом время я останавливал продакшн систему на старом МФ и также загружал ее на новом. Почаса-час и обе продакшн и девелопмент бегут на новом МФ. Оставшиеся на старом МФ кабели пербрасываются на новый МФ. Done.
Были у нас и переходы на новые диски. Немного или правда. Подключалась новая дисковая подсистема к МФ. В системы запускалась программа копирования данных с физических дисков старой дисковой системы на новую. Эта программа могла все скопировать, засинхронизировать и переключить систему со старых дисков на новые. Т.е. это делалось без остановки работы как девелпмент систы так и продакшн. Никакого outage.
К сожалению ничего подобного нет пока на х86-64. Об этом как раз и Ваше сообщение.
Апгрейды ОС тоже выполняются без необходимости переустанавливать все приложения в подвергаемой апгрейду системе. Этого тоже нет на х86-64. Апгрейды баз данных не требуют плясок с бубном и т.д и т.п.
CrazyHackGUT
03.11.2025 02:31Не очень понял, в чём здесь преимущество МФ, и почему на х86-64 такое же не провернуть. Раскройте мысль, пожалуйста.
В соглавсованное с программистами время я останавливал систему программистов на старом МФ и тут же загружал ее на новом.
В виртуальных машинах давно есть "живая миграция" между гипервизорами, с минимальным простоем пока данные догонятся между хостами. Это обычно выстреливает только когда содержимое ОЗУ виртуальной машины очень активно меняется, так что как правило не мешает. То же самое и в отношении прод-сред.
zVlad909 Автор
03.11.2025 02:31Я сравнивал наш процесс с возможным аналогичным. Т.е. без виртуалок.
В компании где я работаю прод-среды на виртуалках не держат. Я имею в виду х86. На Мф у нас и нет их.
Вообще мое отношение к подобным миграциям с одного гипервизора на другой мне интуитивно не нравится. Слышал рассказы когда во время ДР тестов виртуалка "улетала", но не долетала и исходную теряли. В итоге как-то разбирались, с помощью бубнов, но если есть возможность обойтись без этого то лучше обходиться.
Alex-ZiX
03.11.2025 02:31Автор так же упустил из вида, что ВМ проще бэкапить/мигрировать/реплицировать. Когда на твоём гипервизоре закончились ресурсы для ВВ, ты добавляешь новый гипервизор и часть ВМ перемещаешь туда за пару кликов. В случае установки всего софта на один хост сделать это будет гораздо проблематичные, за исключением случая с докер контейнерами. Но, опять же, не всё в них можно запихать. А накладные расходы на виртуализации в наше время не столь заметны.
zVlad909 Автор
03.11.2025 02:31В наше время как и до него издержки на ВМ были есть и будут пока будут использоваться ВМ. Заметны они или нет завит от как мониторить использование ресурсов физического сервера.
Касаемо "бэкапить/мигрировать/реплицировать". Это вопрос эксплуатации серверов. Статья не об этот. Конечно и об этом можно поговорить. Например бэкапить и мигрировать/реплицировать это два совершенно разных процесса.
Проблема ресурсов на МФ решается очень иначе чем "..добавляешь новый гипервизор и часть ВМ перемещаешь туда за пару кликов". На МФ всегда есть избыточный ресурс. Такого использования МФ чтобы избыточного ресурса не было не бывает.
Например, у нас два МФ в разных локациях, разных датацентрах. В случае катастрофы любого из них потерянные системы (не ВМ) запускаются на другом (есть зеркалирование дисков). Естественно ресурсов для работы двух МФ на одном недостаточно буде. Поэтому в несколько сликов я могу сделать живой МФ в несколько раз больее мощным чем в обычной обстановке, до катастрофы. Есть и другие, очень экзотичные, возможности управления ресурсами СВ, которых на х86-64 нет и даже не предвидится.
Например. наш МФ выполняет несколько имиджей z/OS в разных партициях с разным количеством CPU (яасть их или все могут быть и общими). Эти имиджи объединены в т.н. ParralelSusplex. И допустим в одной из партиций не хватает ресурсов (что кстати такое "закончились ресурсы "?). Для решения таких проблем есть вот такой парень:
IBM Intelligent Resource Director (IRD) is a feature of the z/OS operating system that works with Workload Manager (WLM) and the mainframe hardware to automate the management of CPU and I/O resources across multiple logical partitions (LPARs). By grouping LPARs in a Parallel Sysplex into "LPAR clusters," IRD enables dynamic resource allocation based on workload priorities to achieve business goals. Key functions include CPU management, channel subsystem priority queueing, and dynamic channel path management.
IRD перераспределябт ресурсы между партициями. МФ может и сам повышать и понижать русурсы по мере надобности регулируя их количество так как требует текущая нагрузка. Это используется в билингах за софтваре МФ. Только в случае z/OS.
Решения есть для всех проблем которые на х86-64 решаются использованием ВМ, но без ВМ. И эти решения на самом деле гораздо более эффективные чем если бы они использовали ВМ. Об этом я и говорю в статье. Но понять это можно полностью если только знаешь всю поднаготную МФ, а не пытаешься думать о МФ как обычном сервере х86-64, или любых других не МФ серверов.
olku
03.11.2025 02:31Вопрос в форме статьи. Можно многое узнать. Все лучше чем вариант Виртуальные машины больше не нужны.
ozzyBLR
03.11.2025 02:31Если задаться целью, отказаться можно от очень многих вещей. Вопрос в том, какая цель преследуется и какие будут издержки?
zVlad909 Автор
03.11.2025 02:31Речь идет не об отказе как таковом. Я пишу в статье что в мире МФ продолжается использование z/VM хотя строго говоря это актуально не для ОС МФ, а для ОС типа Линукс. z/OS и PR/SM (т.е. разделение физического МФ на партиции) более чем достаточно для классичесого использованиям МФ. Все остально это чисто коммерческий ход с целью получит больше покупателей.
Появится на х86-64 аналогичные z/OS и PR/SM нужда в системах виртуальных машин исчезнет. Но сами ВМ конечно же останутся, для чего-нибудь экзотического, ради фана.
ma1uta
03.11.2025 02:31Виртуализация реализуется на нескольких уровнях. И каждый уровень имеет своё применение.
Виртуализация на уровне ОС - для ЦОД-ов и для поддержки других архитектур (например, надо запустить windows приложение на linux серверах и т. д.).
Виртуализация в рамках одной ОС (известна как контейнеризация) - для запуска отдельных сервисов. Это ещё на OpenVMS на железках DEC VAX делали. Потом появились Solaris Zones, FreeBSD Jail, на linux-ах это развилось в LXC, Docker, OCI/runC/containerd. И даже на linux-ах ушли от vendor lockin-а (kubernetes уже давно может запускать всё через CRI-O, где нет никакого docker-а).
Виртуализация на уровне отдельного приложение - тут flatpak, snap, bubblewrap, Citrix XenApp, которые позволяют запустить десктопное приложение в изолированной песочнице.
Виртуализация на уровне одного приложения - когда изоляция выполняется в рамках одного приложения для различных модулей. Из ярких представителей - это java application servers (WebSphere, WebLogic, Wildfly и другие).
AlexeyK77
03.11.2025 02:31Bверотяно, что с инженерной точки зрения MF это вершина IT, но проблема в том, что это решение завязано исключительно на IBM, этому нигде не учат, это нигде нельзя пощупать и даже образовательной литературы на почитать нормальной нет. И да, самая главная наверное проблема это снова - IBM как компания, исключительно неповоротливая и жадноватая корпорация, которая доедается менеджерами разного уровня "эффективности" и от того сдающая рынок более быстрым конкурентам типа Оракл, Микрософт.
zVlad909 Автор
03.11.2025 02:31Bверотяно, что с инженерной точки зрения MF это вершина IT, но проблема в том, что это решение завязано исключительно на IBM, этому нигде не учат, это нигде нельзя пощупать и даже образовательной литературы на почитать нормальной нет.
Вы хотите сказать что МФ используется только самой ИБМ? Думаю что нет. Конечно же МФ больше не в ИБМ чем в ИБМ. На Западе, Востоке и Юге это достаточно распространено и доступно. Есть и возможность научиться и можно пощупать и научиться. На интернете полно ресурсов для этого.
Проблема в том что конкретно в России этого нет или есть в микроскопических дозах. Я писал недавно обращение в МинЦифры, объяснял что Россия теряет компетенции в целой сфере ИТ, предлагал свои услуги в этом деле - хотя бы сохранить компетенцию - пусть не закупиться МФ для всей России, но иметь место и людей где и кто мог бы при необходимости развернуться и помочь использовать МФ.
Получил такую вот отписку: "Ознакомились, приняли к сведению, будем применять в текущей деятельности". Это все, дословно.
И да, самая главная наверное проблема это снова - IBM как компания, исключительно неповоротливая и жадноватая корпорация, которая доедается менеджерами разного уровня "эффективности" и от того сдающая рынок более быстрым конкурентам типа Оракл, Микрософт.
Это не совсем так. Хотя бы потому что в ИБМ нет одного органа или человека, который бы диктовал что и как делать. ИБМ состоит из многоих хозяйственно независимых подразделений. В каждом из которых есть руководство, специалисты, бюджет и цели. Все они не могут быть и на самом деле не точто Вы думаете об ИБМ в целом. Строго говоря Вы не можете судить об ИБМ, Вы не знаете. Я тоже не все знаю. Я не работал в ИБМ. Но я еще в СССР начал работать с фактически продуктами ИБМ и даже заключал договор с ИБМ на приличный список программного обеспечения. Для МФ и не только.
В Канаде я больше 25 лет работаю с ИБМ МФ (и не только МФ, но ИБМ), прошел десяток трэйнингов на МФ и не только, посетил пару десятков сенминаров с высококвалифицированными специалистами ИБМ. Это было на очень высоком уровене всегда. Я слышал от ИБМ про вещи которые спустя годы использовались другими фирмами типа Оракл, Микрософт как будто бы это они придумали. И наоборот вещи, технологие изобретенные и существующие годы в ИБМ изобретаются вновь, но называются по другому и создается впечатление что ИБМ в чем то отстает. Пример - контейнеры, контейнеризация. Я об этом собираюсь писать. .
DarthVictor
03.11.2025 02:31У автора IBM головного мозгаСтатья слегка однобока (как минимум коммерческая целесообразность аппаратной реализации VM мне не очевидна), но полезна и интересна. Уж не знаю, отчего так на автора наехали. За цитату LLM-ки? Ну так это художественный приём, для добавления в текст общепринятого описания, раньше в литературе энциклопедический словарь цитировали, потом Википедию, теперь LLM.
zVlad909 Автор
03.11.2025 02:31Совершенно верно. Эту цитату я нашел когда начал писать эту статью, задуманную давно. Мне это понадобилась в качестве "затравки", как триггер. Не более того.
А с содержимым самой цитатой я не очень то и согласен. Иожно было и лучше текст составить. Но видимо у LLM не нашлось лучше материала.
krote
Ох здается мне что автор сего глубокомысленного опуса еще зелен, молод и прода не нюхал, иначе бы не нес такую чушь.
Уж извините не буду описывать слишком очевидные вещи из за чего ВМ нужны и никуда не денутся.
ma1uta
Скорее наоборот, судя по остальным статьям, автор не один десяток лет жил в экосистеме IBM, поэтому все рассматривает исключтельно в сфере "В IBM сделали всё хорошо, а все остальные ещё доросли". Отсюда статьи подобного рода.
krote
похоже тогда это скорей что то вроде проф-деформации в своем информационном пузыре.
artscan
Архитектура процессоров, используемых в IBM, позволяет реализовать виртуализацию с очень небольшими накладными расходами. А в x86 by design невозможно это сделать, не применяя эмуляцию, паравиртуализацию или что-то вроде. То есть, накладные расходы существенно выше и неустранимы. И зачем-то проблема сводится к отсутствию адекватного ПО в x86, чтобы заменить виртуализацию с потерями на что-то более лучшее. К чему адекватная система ввода-вывода, если накладные расходы на виртуализацию неустранимы? Какое ПО может игнорировать архитектуру x86, сохраняемую для обратной совместимости? Похоже, вся надежда на multikernel linux и контейнеры. )
zVlad909 Автор
Во-первых, "экосистема IBM" это не только МФ. Во-вторых, "экосистема IBM" включает многое появившееся не в ИБМ, Линукс, Вебсервера, в-третьих, я довольно много поработал с продуктами под Windows и Linux, да в основном ИБМ-ских продуктов. Ну и в четвертых "экосистема IBM" это весьма открытая система, ничто ей не чуждо. Когда-то из нее собственно и появились многгие современные экосистемы.
zVlad909 Автор
"Из-за чего" ВМ нужны рассказал ИИ на Гугле и я эти причины нужности прокомментировал.
Если есть вопросы - задавайте по существу, а гадание о том кто я и что оставьте гадалкам.