Запуск нескольких ОС. Виртуальные серверы. Эффективное использование ресурсов.

Я объединил эти три причины в одну потому что все они есть следствие того что, да, виртуальные машины позволяют выполнять на одной физической машине несколько одинаковых или разных ОС.

Собственно это единственное что отличает традиционную ОС от систем виртуальных машин.

Тестирование. Изоляция и безопасность.

Первое - тестирование - это прикладное следствие второго - изоляция и безопасность. А только ли виртуальные машины могут обеспечить изоляцию и безопасность. Разве в традиционных системах эту проблему не решают их разработчики?

Самые ранние компьютеры способны были выполнять ровно одну задачу (программу). Функции первых "ОС" сводились к загрузке готовой для выполнения программы и передачи ей управления компьютером. Сама "ОС" (загрузчик) с этого момента исчезала и всем компьютером управляла прикладная программа. Она была максимально изолирована от любых воздействий.

Как только перед компьютером была поставлена задача быть способным выполнять больше одной задачи для одного пользователя так сразу возникла и начала решаться проблема изоляции и безопасности. Насколько успешно решалась эта проблема в первую очередь определялось тем какие технические средства предоставлял тот или иной компьютер. Т.е. его архитектурой и принципами работы.

Современные компьютеры обладают развитыми средствами обеспечения изоляции и безопасности. Таким образом с теоретической точки зрения совершенно не обязательно называть метод обеспечения изоляции и безопасности виртуальной машиной.

И это на самом деле уже имеет место быть во всех современных ОС на любых современных компьютерах. 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?