Comments 32
Ох здается мне что автор сего глубокомысленного опуса еще зелен, молод и прода не нюхал, иначе бы не нес такую чушь.
Уж извините не буду описывать слишком очевидные вещи из за чего ВМ нужны и никуда не денутся.
Скорее наоборот, судя по остальным статьям, автор не один десяток лет жил в экосистеме IBM, поэтому все рассматривает исключтельно в сфере "В IBM сделали всё хорошо, а все остальные ещё доросли". Отсюда статьи подобного рода.
похоже тогда это скорей что то вроде проф-деформации в своем информационном пузыре.
Архитектура процессоров, используемых в IBM, позволяет реализовать виртуализацию с очень небольшими накладными расходами. А в x86 by design невозможно это сделать, не применяя эмуляцию, паравиртуализацию или что-то вроде. То есть, накладные расходы существенно выше и неустранимы. И зачем-то проблема сводится к отсутствию адекватного ПО в x86, чтобы заменить виртуализацию с потерями на что-то более лучшее. К чему адекватная система ввода-вывода, если накладные расходы на виртуализацию неустранимы? Какое ПО может игнорировать архитектуру x86, сохраняемую для обратной совместимости? Похоже, вся надежда на multikernel linux и контейнеры. )
Во-первых, "экосистема IBM" это не только МФ. Во-вторых, "экосистема IBM" включает многое появившееся не в ИБМ, Линукс, Вебсервера, в-третьих, я довольно много поработал с продуктами под Windows и Linux, да в основном ИБМ-ских продуктов. Ну и в четвертых "экосистема IBM" это весьма открытая система, ничто ей не чуждо. Когда-то из нее собственно и появились многгие современные экосистемы.
"Из-за чего" ВМ нужны рассказал ИИ на Гугле и я эти причины нужности прокомментировал.
Если есть вопросы - задавайте по существу, а гадание о том кто я и что оставьте гадалкам.
Нужен ли ИИ-слоп на Хабре? Я задал этот вопрос "автору" "статьи" и не получил ответа.
Вы в профиль то зайдите, как и @krote. Тут убеждения и опыт, настоящие, сейчас таких почти не делают. Так что молодец, что пишет – пусть имхо и небесспорные вещи.
Нужны ли виртуальные машины?
Виртуальные машины на платформе х86-64 не имеют будущего.
Нужны, и никуда они не денутся. Партиционирование не закрывает целый класс явлений, например:
Устаревших платформ становится только больше, и этот процесс не остановится по очевидным причинам. Их надо как-то поддерживать, и обеспечивать совместимость нового софта хотя-бы с несколькими версиями платформ, одновременно представленных на рынке очень даже массово.
Скорость разработки растёт, а во время разработки накладные расходы не играют прямо какой-то решающей роли.
ВМ обеспечивают лучшую в моменте гибкость – хоть и ценой ухудшения изоляции, безопасности, надёжности, производительности и пр. Однако в целом достигнутые даже коммодити-устройствами характеристики настолько хороши, что это мало где заметно, и ещё меньше где критично.
В целом аргументы автора примерно уровня «частный транспорт это тупик, потому что есть общественный». Да пофиг всем на эффективность, безопасность и пр. Если оно ездит от подъезда до подъезда, на то что 4 из 5 сидений пустые, никто внимания не обращает. Сколько mass transit не улучшай, от подъезда до подъезда он возить не будет.
Судя по Вашему образу мышления Вы программист/разработчик программ. Я имею в иду что Вы не системшик, который занимается процессами выполнения программ. Разных программ от разных раработяиков.
Это два разных образа мыления и понимания.
Из этой Вашей фразы:
ВМ обеспечивают лучшую в моменте гибкость – хоть и ценой ухудшения изоляции, безопасности, надёжности, производительности и пр.
Напрашивается только один вывод - Вы не совсем в курсе что такое система виртуальных машин и чем она лучше чем традиционные ОС х86-64. Именно изоляция и безопасность считается (не мною) достоинством ВМ.
Статья про эволюцию системного программного обеспечения на МФ, и попытка объяснить почему такой же путь ждет и системное ПО х86-64. Может и не ждет, я не пророк и не экстрасенс, но видя что эволюция на МФ объективно и что х86-64 идет по ее стопам я взял на себя право порассуждать о том что ждет нынешнюю молодежь в сфере х86-64. К чему ей не грех готовится. А время бысто летит.
Простите, но вам вредит развешивание ярлыков, категоричность и не слишком обоснованные догадки по поводу «образа мышления». Образ мышления у меня – не программиста и не системщика, оба этих рода занятий я считаю просто полезными побочными скиллами.
Давайте я вам задам вопрос: ВМ исполняемая на ФС смонтированной из файла хостовой системы, будет более безопасной и изолированной, чем с аппаратно приколоченной партиции? Вопрос, конечно, не совсем честный – у меня просто был вполне практический кейс.
Ещё нюанс: ВМ по-разному используются, в том числе вполне себе в бытовых условиях. Этот момент у вас полностью упущен в рассуждениях – а он ой как важен.
что ждет нынешнюю молодежь в сфере х86-64
Я полагаю, что эта платформа будет терять рынок, как коммодити-устройств, так и в облаках/цодах.
А в целом, спасибо, что пишете – пишите ещё!
Извините. Намерений обидеть не было.
Давайте я вам задам вопрос: ВМ исполняемая на ФС смонтированной из файла хостовой системы, будет более безопасной и изолированной, чем с аппаратно приколоченной партиции? Вопрос, конечно, не совсем честный – у меня просто был вполне практический кей
Я не специалист по безопасности на х86. Да и терминологией такой не владею.
Ещё нюанс: ВМ по-разному используются, в том числе вполне себе в бытовых условиях. Этот момент у вас полностью упущен в рассуждениях – а он ой как важен.
Все охватить не возможно. Другие мне тоже говорят о моих упущениях.
Я полагаю, что эта платформа будет терять рынок, как коммодити-устройств, так и в облаках/цодах.
А что по-Вашему будет приходить взамен? По работе в корпоративной ИТ я вижу как именно х86-64 все платформы вытесняет.
Спасибо за доброе пожелание.
А что по-Вашему будет приходить взамен?
Мои ощущения более-менее совпадают с прогнозам, что мне в руки попадаются последние года два-три. ARM захватил мобильный рынок практически полностью, и пошёл в десктопы, ноутбуки и сервера. На сейчас по последнему пункту оценки – 10…15% рынка, но вне зависимости от конкретной цифры все отмечают медленный, но постоянный рост этой доли.
Интелы относительно АРМов существенно более прожорливы, и победить это не получится никак. При массовых вычислениях это, по-моему, совершенно непроходимое препятствие для x86-64. Думаю, лет через 10 доли сравняются.
Ну и в эмуляции замечательные успехи наблюдаются.
Приведу всего один факт – на моём ноутбуке с М3 авиасимулятор написанный под x86-64 даёт под эмулятором фреймрейт выше, чем 4,5ГГц интел на десктопе. И это при разнице в потребляемой мощности на порядок. Это как паровозы с тепловозами сравнивать.
ВМ исполняемая на ФС смонтированной из файла хостовой системы, будет более безопасной и изолированной, чем с аппаратно приколоченной партиции?
В статье про другие партиции речь.
... и не слишком обоснованные догадки по поводу «образа мышления». Образ мышления у меня – не программиста и не системщика, оба этих рода занятий я считаю просто полезными побочными скиллами.
Я бы хотел объяснить по поводу "ярлыков". На МФ всегда было и есть четкое разделение между системщиками и программистами. Это идет от природы МФ и его ОС. Видел я системщиков, которые не писали программ и не собирались этого делать. Или DBA которому система и программирование до лампочки.
Сам я начинал как программист, потом стал системщиком, но программировать понемногу никогда не прекращал, и DBA был тоже. Знаю всех их образы мышления. Естественно в области ИТ, не вообще. Вообще все люди разные.
На х86-64 такого разделения нет. Программисты зачастую знают систему лучше чем какой-нибудь администратор. DBA лезут в программировани, а администраторы только и делают что патчат секьюрити. Ну и ставят новые и новые сервера, а пользователи все просят и просят эти сервера ставить и никогда от них не отказываются. Благо что есть облака и виртуальные машины.
Ну и для кого скилсы, а для кого способ зарабатывания на жизнь.
Не только на серверном, но и на прикладном уровне нужны - каждые три года наша компания полностью меняет компы, так что настроенные среды разработки бывает удобнее держать развернутыми в виртуалках, ну и для тестирования инсталляшек и ПО на различных ОС тоже удобнее делать в ВМ, легко откатываясь к чистой установке, так что виртуальные машины удобны и нужны, хотя я и предпочитаю работать без ВМ если нет особой необходимости.
Раскажу вкратце как я делал переходы с одного МФ на другой, новый МФ. За последние 20 лет я это делал в рамках одной организации раз наверное десять (потому что у нас два МФ и каждый в отдельности обновлялся).
ИБМ прикатывал и ставил новый МФ рядом со старым. Я создавал нужную нам конфигурацию для нового МФ (по сути это копия старой с небольшими модификациями связанными с новыми возможностями нового МФ). Затем мы перебрасывали несколько кабелей (оптоволоконных) ввода-вывода со старого на новый. Это чтобы внешнее оборудование (диски, ленты, сетевые коммуникации) стало доступно новому МФ тоже. Чтобы было понятно на МФ всего все дублируется и можно спокойно отключать часть из коммуникаций. А чтобы понятно было еще лучше скажу что все ПО и системеное и прикладное находятся на внешних устройствах МФ. Далее.
В соглавсованное с программистами время я останавливал систему программистов на старом МФ и тут же загружал ее на новом. Полчаса-час и программисты уже работают на новом МФ. Продакшн система пока остается на старом МФ.
В согласованное с бизнесом время я останавливал продакшн систему на старом МФ и также загружал ее на новом. Почаса-час и обе продакшн и девелопмент бегут на новом МФ. Оставшиеся на старом МФ кабели пербрасываются на новый МФ. Done.
Были у нас и переходы на новые диски. Немного или правда. Подключалась новая дисковая подсистема к МФ. В системы запускалась программа копирования данных с физических дисков старой дисковой системы на новую. Эта программа могла все скопировать, засинхронизировать и переключить систему со старых дисков на новые. Т.е. это делалось без остановки работы как девелпмент систы так и продакшн. Никакого outage.
К сожалению ничего подобного нет пока на х86-64. Об этом как раз и Ваше сообщение.
Апгрейды ОС тоже выполняются без необходимости переустанавливать все приложения в подвергаемой апгрейду системе. Этого тоже нет на х86-64. Апгрейды баз данных не требуют плясок с бубном и т.д и т.п.
Не очень понял, в чём здесь преимущество МФ, и почему на х86-64 такое же не провернуть. Раскройте мысль, пожалуйста.
В соглавсованное с программистами время я останавливал систему программистов на старом МФ и тут же загружал ее на новом.
В виртуальных машинах давно есть "живая миграция" между гипервизорами, с минимальным простоем пока данные догонятся между хостами. Это обычно выстреливает только когда содержимое ОЗУ виртуальной машины очень активно меняется, так что как правило не мешает. То же самое и в отношении прод-сред.
Я сравнивал наш процесс с возможным аналогичным. Т.е. без виртуалок.
В компании где я работаю прод-среды на виртуалках не держат. Я имею в виду х86. На Мф у нас и нет их.
Вообще мое отношение к подобным миграциям с одного гипервизора на другой мне интуитивно не нравится. Слышал рассказы когда во время ДР тестов виртуалка "улетала", но не долетала и исходную теряли. В итоге как-то разбирались, с помощью бубнов, но если есть возможность обойтись без этого то лучше обходиться.
Автор так же упустил из вида, что ВМ проще бэкапить/мигрировать/реплицировать. Когда на твоём гипервизоре закончились ресурсы для ВВ, ты добавляешь новый гипервизор и часть ВМ перемещаешь туда за пару кликов. В случае установки всего софта на один хост сделать это будет гораздо проблематичные, за исключением случая с докер контейнерами. Но, опять же, не всё в них можно запихать. А накладные расходы на виртуализации в наше время не столь заметны.
В наше время как и до него издержки на ВМ были есть и будут пока будут использоваться ВМ. Заметны они или нет завит от как мониторить использование ресурсов физического сервера.
Касаемо "бэкапить/мигрировать/реплицировать". Это вопрос эксплуатации серверов. Статья не об этот. Конечно и об этом можно поговорить. Например бэкапить и мигрировать/реплицировать это два совершенно разных процесса.
Проблема ресурсов на МФ решается очень иначе чем "..добавляешь новый гипервизор и часть ВМ перемещаешь туда за пару кликов". На МФ всегда есть избыточный ресурс. Такого использования МФ чтобы избыточного ресурса не было не бывает.
Например, у нас два МФ в разных локациях, разных датацентрах. В случае катастрофы любого из них потерянные системы (не ВМ) запускаются на другом (есть зеркалирование дисков). Естественно ресурсов для работы двух МФ на одном недостаточно буде. Поэтому в несколько сликов я могу сделать живой МФ в несколько раз больее мощным чем в обычной обстановке, до катастрофы. Есть и другие, очень экзотичные, возможности управления ресурсами СВ, которых на х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, или любых других не МФ серверов.
Вопрос в форме статьи. Можно многое узнать. Все лучше чем вариант Виртуальные машины больше не нужны.
Если задаться целью, отказаться можно от очень многих вещей. Вопрос в том, какая цель преследуется и какие будут издержки?
Речь идет не об отказе как таковом. Я пишу в статье что в мире МФ продолжается использование z/VM хотя строго говоря это актуально не для ОС МФ, а для ОС типа Линукс. z/OS и PR/SM (т.е. разделение физического МФ на партиции) более чем достаточно для классичесого использованиям МФ. Все остально это чисто коммерческий ход с целью получит больше покупателей.
Появится на х86-64 аналогичные z/OS и PR/SM нужда в системах виртуальных машин исчезнет. Но сами ВМ конечно же останутся, для чего-нибудь экзотического, ради фана.
Виртуализация реализуется на нескольких уровнях. И каждый уровень имеет своё применение.
Виртуализация на уровне ОС - для ЦОД-ов и для поддержки других архитектур (например, надо запустить 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 и другие).
Bверотяно, что с инженерной точки зрения MF это вершина IT, но проблема в том, что это решение завязано исключительно на IBM, этому нигде не учат, это нигде нельзя пощупать и даже образовательной литературы на почитать нормальной нет. И да, самая главная наверное проблема это снова - IBM как компания, исключительно неповоротливая и жадноватая корпорация, которая доедается менеджерами разного уровня "эффективности" и от того сдающая рынок более быстрым конкурентам типа Оракл, Микрософт.
Bверотяно, что с инженерной точки зрения MF это вершина IT, но проблема в том, что это решение завязано исключительно на IBM, этому нигде не учат, это нигде нельзя пощупать и даже образовательной литературы на почитать нормальной нет.
Вы хотите сказать что МФ используется только самой ИБМ? Думаю что нет. Конечно же МФ больше не в ИБМ чем в ИБМ. На Западе, Востоке и Юге это достаточно распространено и доступно. Есть и возможность научиться и можно пощупать и научиться. На интернете полно ресурсов для этого.
Проблема в том что конкретно в России этого нет или есть в микроскопических дозах. Я писал недавно обращение в МинЦифры, объяснял что Россия теряет компетенции в целой сфере ИТ, предлагал свои услуги в этом деле - хотя бы сохранить компетенцию - пусть не закупиться МФ для всей России, но иметь место и людей где и кто мог бы при необходимости развернуться и помочь использовать МФ.
Получил такую вот отписку: "Ознакомились, приняли к сведению, будем применять в текущей деятельности". Это все, дословно.
И да, самая главная наверное проблема это снова - IBM как компания, исключительно неповоротливая и жадноватая корпорация, которая доедается менеджерами разного уровня "эффективности" и от того сдающая рынок более быстрым конкурентам типа Оракл, Микрософт.
Это не совсем так. Хотя бы потому что в ИБМ нет одного органа или человека, который бы диктовал что и как делать. ИБМ состоит из многоих хозяйственно независимых подразделений. В каждом из которых есть руководство, специалисты, бюджет и цели. Все они не могут быть и на самом деле не точто Вы думаете об ИБМ в целом. Строго говоря Вы не можете судить об ИБМ, Вы не знаете. Я тоже не все знаю. Я не работал в ИБМ. Но я еще в СССР начал работать с фактически продуктами ИБМ и даже заключал договор с ИБМ на приличный список программного обеспечения. Для МФ и не только.
В Канаде я больше 25 лет работаю с ИБМ МФ (и не только МФ, но ИБМ), прошел десяток трэйнингов на МФ и не только, посетил пару десятков сенминаров с высококвалифицированными специалистами ИБМ. Это было на очень высоком уровене всегда. Я слышал от ИБМ про вещи которые спустя годы использовались другими фирмами типа Оракл, Микрософт как будто бы это они придумали. И наоборот вещи, технологие изобретенные и существующие годы в ИБМ изобретаются вновь, но называются по другому и создается впечатление что ИБМ в чем то отстает. Пример - контейнеры, контейнеризация. Я об этом собираюсь писать. .
У автора IBM головного мозга
Статья слегка однобока (как минимум коммерческая целесообразность аппаратной реализации VM мне не очевидна), но полезна и интересна. Уж не знаю, отчего так на автора наехали. За цитату LLM-ки? Ну так это художественный приём, для добавления в текст общепринятого описания, раньше в литературе энциклопедический словарь цитировали, потом Википедию, теперь LLM.
Нужны ли виртуальные машины?