Русский
Русский
English
Статистика
Реклама

Мейнфрейм

Перевод Изготовление контроллера терминала IBM 3270

23.06.2020 10:15:03 | Автор: admin

IBM 3270 это терминал компьютерного мейнфрейма. Я давно восхищаюсь мейнфреймами от IBM, и особенно этими терминалами. У ранних моделей, 3278 и 3279, была уникальная эстетика, а их блочная система работы заметно отличается от той, которой пользовались вездесущие терминалы серии VT.



Терминал IBM 3278-2 и его пра-пра-правнук, ThinkPad X1, на котором запущен оес. Терминал подсоединён к современному z14 при помощи TN3270.

Не один я хотел попробовать подсоединить настоящий терминал от IBM к эмулятору Hercules [программный эмулятор мейнфреймов IBM (System/370, System/390, zSeries/System z) и совместимых (Amdahl)]. К сожалению, довольно трудно найти контроллер терминала IBM 3174 с интерфейсом Ethernet или Token Ring, версией софта с поддержкой TCP/IP и в рабочем состоянии. К тому же они огромные, шумные, и их сложно обслуживать, поскольку софт на них приходится загружать при помощи редких флоппи-дисков 5" объёмом 2,4 Мб если повезёт, бывают ещё варианты с жёстким диском на 20 Мб. Поэтому я решил сделать собственный контроллер, а в процессе узнать что-то новое.

Немного истории IBM 3270


Судя по записям компании IBM, информационная система 3270 была представлена в 1972 году, а культовый терминал 3278 через пять лет, в 1977. Цветные терминалы появились в 1979 с 3279. Сложновато не запутаться в моделях и годах!

3270 один из самых узнаваемых терминалов, работающих по блочной системе. Поток данных 3270 позволяет программисту описать целый экран, содержащий текст, защищённый от редактирования, доступные для редактирования поля и атрибуты его форматирования. Доступные для редактирования поля позволяют вводить или изменять данные. Вместо того, чтобы отправлять каждое сделанное вами нажатие клавиши сразу на хост, как это происходит у символьных терминалов, этот терминал хранит ввод у себя, пока вы не нажмёте особую клавишу к примеру, Enter. Только после этого весь ввод отправляется на хост блоком данных. Такая система улучшает воспринимаемую отзывчивость компьютера в случае медленной или ненадёжной связи. Также это снижает требования по мощности хоста, и позволяет подключать к нему гораздо больше блочных терминалов, чем символьных. В чём-то это весьма напоминает заполнение формы на HTML-странице.

Для ранних 3270 предлагалась всякая прикольная периферия, типа световых ручек для улучшения навигации и устройств для чтения магнитных карт к сожалению, на eBay я их не встречал.

Терминалы соединяются с контроллером коаксиальным кабелем по топологии звезда. При помощи балуна можно превратить её в более привычную схему подключения по витой паре, хотя, как мне кажется, IBM предпочла бы, чтобы вы использовали их систему подключения. Контроллер соединяется с мейнфреймом по разным интерфейсам, в зависимости от того, местный это контроллер или удалённый. Кроме того, подключение менялось со временем. Среди интерфейсов присутствовали:
  • Parallel Channel
  • ESCON Channel
  • X.21
  • V.35
  • Token Ring
  • Ethernet


В итоге контроллеры IBM 3174 и 3274 бывают самых разных форм и размеров от небольших настольных модулей, до средних устройств, предназначенных для установки в стойку и крупных напольных сооружений.


Контроллеры терминалов от IBM по часовой стрелке, начиная снизу слева: 3174-1L, 3174-23 (без передней крышки), 3174-61R и 3274-41D.

Другие компании, включая Memorex, производили совместимые терминалы и контроллеры. С распространением персональных компьютеров терминалы начали менять на ISA, PCMCIA и потом PCI-карточки, позволявшие подсоединять по тому же коаксиальному кабелю ПК с эмулятором. Позднее, с развитием LAN и TCP/IP эти подсоединения заменил телнет TN3270, которому не требовалось специальное железо или коаксиальный кабель.

Для клиентов, обзаведшихся сетью TCP/IP, но всё ещё пользующихся большим количеством физических терминалов, поздние варианты контроллеров 3174 предлагали возможность соединять их с мейнфреймом телнетом по TCP/IP. Для подсоединения к Hercules нам нужны именно такие контроллеры. Меня очень интересовал тот факт, что они также предлагали эмуляцию VT100, с помощью которой терминал 3270 можно было соединить с хостом на UNIX или VMS так, будто бы это был VT100. Для меня это было странным ведь терминал заточен под блочную передачу, поэтому эмуляция VT100 кажется невозможной.

Последним терминалом от IBM стал 3483, представленный в конце 1990-х. К тому времени терминалы напоминали уже тонких клиентов и использовали стандартные мониторы VGA и клавиатуры с интерфейсом PS/2.

Разбираемся в протоколе


Изначальный мой поиск навёл меня на описание кабельного подключения и потока данных для 3270. Всё это было хорошо описано, однако там ничего не сказано о протоколе передачи данных между терминалом и контроллером. Его детали я смог найти, только раскопав технические описания устаревших на сегодня чипов, использовавшихся для создания интерфейсов с ПК. Их производили CHIPS и National Semiconductor:
  • CHIPS 82C570
  • NS DP8340
  • NS DP8341
  • NS DP8344


Устройства соединяются друг с другом коаксиальным кабелем с характерным импедансом 93 . Кабель этот имеет тип RG-62 в отличие от сетей на Ethernet 10BASE2, использующих топологию шины и кабель с импедансом в 50 . Для уменьшения шума в длинных участках кабеля используется разностная передача сигналов, и максимальная рекомендованная длина отрезка между устройствами по спецификации составляет 1,5 км.

Данные идут с битрейтом в 2,3587 Мб/с в Манчестерском кодировании. Эта схема обеспечивает перепад напряжения с низкого уровня на верхний уровень (или наоборот) в рамках каждого бита, что гарантирует надёжную передачу данных до получателя. В каждом кадре содержится одно или несколько 10-битных слов. Каждое слово начинается с бита синхронизации и заканчивается битом чётности. Начало и конец кадра отмечают уникальные последовательности.


Вместо тысячи слов или, как в данном случае, 10 бит. Команда чтения состояния, отправленная с контроллера на терминал.

Все коммуникации инициирует контроллер. Он отправляет на терминал кадр, содержащий управляющее слово и опциональные слова с данными (что-то типа параметров). Терминал отвечает кадром, содержащим одно или несколько слов с данными.

Оказалось, что терминалов существует два типа CUT и DFT. CUT перекладывают обработку потока данных 3270 на управляющий модуль, и преобразуют их в базовые операции вроде движения курсора по адресу или записи символов в буфер дисплея (он же кадровый буфер). Большую часть функций, которые люди ассоциируют с терминалом 3270, выполняет контроллер то есть, логика терминала CUT проще, чем у сравнимого по функциональности VT1000. Терминалы DFT могут обрабатывать поток данных 3270 самостоятельно, и контролер просто передаёт поток на терминал.

Подробную документацию протокола я веду на GitHub.

Hello world


На eBay до сих пор можно найти передатчики DP8340 и приёмники DP8341 от National Semiconductor, поэтому я купил их и некоторые другие компоненты, перечисленные в техническом описании. Сначала я думал собрать интерфейс с нуля, однако эти интегральные схемы передатчика и приёмника в итоге обеспечили передачу данных.

Я также нашёл контроллер IBM 3174-23R для установки в стойку с интерфейсом Token Ring, и решил, что больше мне ничего и не надо. К сожалению, дискета с управляющей программой оказалась испорченной, и загрузить получалось только диск диагностики. Диагностическая программа показывала менюшки на терминале, чего хватило для перехвата части трафика между терминалом и контроллером для последующего анализа.

Я сделал простую схему приёмника по описанию DP8341 на макетной плате, подключил её к Arduino Mega, и при помощи т-коннектора подключился между контроллером и терминалом. Я был в восторге, впервые увидев поднятие напряжения на контакте DATA AVAILABLE и вызов моего обработчика прерываний. На то, чтобы надёжно считывать данные с приёмника, у меня ушло некоторое время. Вскоре я обнаружил, что памяти в 8 Кб на Arduino Mega мне уже не хватает, а поток данных шёл слишком быстро, чтобы в реальном времени скидывать их на ПК по последовательному порту.

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

Я также перехватил счётчик адресов загрузки и команды на запись данных, связанные с буфером дисплея. Адрес извлечь было легко, однако сначала я не нашёл данных, записываемых в буфер дисплея, в ожидаемой мною кодировке EBCDIC (я ждал её, учитывая схему работы диагностического интерфейса на терминале). Также это была и не ASCII оказалось, что терминал использует свою кодировку символов. Как она называется, я не знаю, и отсылок к ней я не нашёл. Большую часть кодировки я смог разметить при помощи диагностического интерфейса. А когда я добавил на макетную плату передатчик DP8340, то смог полностью разметить все символы сначала, конечно же, выведя на экран hello world!

У терминала 3270 есть строка состояния, которая выводится в самом низу экрана. Ею, за исключением текущей позиции курсора, управляет контроллер. Сбивает с толку, что строка состояния начинается с адреса 0 в буфере экрана, хотя находится в самом низу а адрес 80 соответствует верхней левой ячейке в режиме 80 столбцов. Также кодировка символов в строке состояния отличается от остальных, и в неё входят много необычных символов.

В итоге я смог написать библиотеку для Python, pycoax, для сериализации и десериализации кадров 3270. Код на Python работает на ПК и общается с Arduino по последовательному порту (физически через USB).

Наконец, я разработал свою первую печатную плату при помощи KiCad и отправил на изготовление в JLCPCB. Спустя неделю и $15, я получил 5 шилдов для Arduino, готовых к сборке. Плата работает значительно лучше макетной, количество ошибок заметно уменьшилось. Да, и признаюсь, что мне пришлось заказывать плату дважды, поскольку в первый раз я совершил ошибку при разводке.


Arduino Mega и шилд-интерфейс для коаксиала

Создание oec


Моей целью было создать замену контроллеру IBM 3174, которую можно было бы использовать совместно с Hercules. Теперь, когда я понял, что терминал типа CUT не обрабатывают поток данных 3270 самостоятельно, я понял, что реализовать сначала эмуляцию VT100 будет гораздо проще, чем TN3270.
Я нашёл pyte, обеспечивающий эмуляцию VT100 в памяти, и поддерживающий подключение к процессу (типа командной оболочки или SSH). Мне нужно было только опрашивать терминал на предмет нажатий клавиш, передавать их процессу, обновлять эмулятор pyte, передавая ему выходные данные с процесса, а потом выводить эмулированный экран терминала на сам терминале. А кроме этого ещё нужно было следить, включен терминал или отключен, и отслеживать здоровье процесса.

Первые контроллеры, существовавшие в эпоху дорогой памяти, не удерживали копию экрана в своей памяти, как я делаю это сейчас. У терминала CUT есть команды на чтение из буфера дисплея и на поиск ячеек, соответствующих определённой последовательности типа атрибута, обозначающего начало поля ввода. Я обнаружил, что без подобных ограничений куда легче хранить копию экрана в памяти и обновлять терминал.

Вдохновившись pyte, я написал pytn3270, быблиотеку TN3270 на чистом Python, обеспечивающую похожую эмуляцию в памяти. Для интеграции с контроллером потребовалось сопоставить атрибуты полей байту атрибутов терминала 3270. Я мог бы использовать x3270, однако мне хотелось лучше разобраться в протоколе telnet и потоке данных 3270. Для протокола TN3270 я реализовал необходимый минимум но его достаточно для подключения к z/OS, а библиотека на чистом Python может оказаться полезной и вне этого проекта.

На сегодня oec ещё далёк от поддержки абсолютно всех функций контроллера IBM 3174, однако пользоваться им можно. Скачать его можно с GitHub.

Будущее


Во-первых, хочу добавить меню связи, чтобы можно было выбирать хоста (пока что мы умеем подключаться только к одному хосту) и поддержку нескольких логических терминалов. Потом добавлю поддержку EAB и TN3270E для этого мне нужно будет реализовать некоторые функции в pytn3270, которых пока не хватает.

Пока я работаю над интерфейсом на основе FPGA, чтобы не полагаться на устаревшие микросхемы от National Semiconductor и в процессе изучаю протокол и немного Verilog.
Подробнее..

Особенности разработки на мейнфреймах

02.05.2021 08:07:25 | Автор: admin

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

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

Debug

Не знаю почему, но дебаг приложений на z/OS в 2021 происходит примерно так же как и лет 30 назад. Самый удобный/мощный дебагер который есть - это консольный XDC дебагер работающий на z/OS с доступом из ISPF панели. Он реально крутой, но вообще не user-friendly и его нельзя прикрутить к IDE, что заставляет большинство джунов использовать printf в первый год и избегать дебагер (но долго бегать не получится, рано или поздно придётся заглянуть в пасть льву).

Да, есть дебагер от IBM с собственной IDE, но лично моё мнение, что он подходит или для "Hello World!" проектов или для небольших карманных проектов.

XDC DebuggerXDC Debugger

Legacy код

Я не утверждаю, что другие платформы не сталкиваются с легаси, тут скорее даже проблема не в самом легаси коде, а в его возрасте: он может быть написан на старых языках программирования и с применением устаревших практик разработки. И в данном случаем ты даже не знаешь что хуже: разбирать код на HLASM (High Level Assembler) или пытаться понять код на C++, написанный с использованием большого числа глобальных переменных.

Т.е. код, который ты читаешь, может быть написан до публикации книги Clean Code (2008) ... да что уж там, даже до публикации Code Complete (1993).

Да и в целом найти человека, умеющего хотя бы читать HLASM или REXX, намного сложнее чем C, C++, PHP, Java разработчиков. Отсюда, кстати, вытекает следующая особенность.

Кадровый голод

Если у вас появляется свободная вакансия в команде, с большой долей вероятности, её место займёт человек, который о мейнфреймах слышал не более чем среднестатистический читатель этой статьи. Вам в любом случае нужно обучить человека тому, что человек будет слышать впервые в жизни: TSO, JCL, USS, ISPF, Datasets, JES, SDSF, SMP/E.

Как правило, первые пол года разработчик не будет приносить пользы, но на него будет требоваться время Техлида, Скрам-мастера, Менеджера и других членов команды.

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

Частота релизов и Quality First

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

Мы используем немного изменённый Scrum фреймворк в нашем процессе разработке и живём двух недельными спринтами, в конце которых мы делаем релиз продукта с обязательным проходом всех юнит-тестов и полной регрессии. Звучит довольно стандартно, но у нас возникают следующие трудности:

  1. Исторически мы можем поддерживать несколько версий продукта. Для нас это значит, что в конце спринта мы делаем релиз только для одной версии продукта. Как следствие, новые обновления для каждой версии выходят примерно раз в месяц. Также, по личным наблюдениям, мультиверсионность стоит нам примерно 20% времени команды - что очень много.

  2. Даже с учётом ежемесячных обновлений, больше половины кастомеров обновляют продукты только если у них случилась проблема или пришло время ежегодного обновления (если так за год ничего критического не случилось). Из-за этого у нас бывают кастомерские проблемы, в которых решение было релизнуто год назад (клиенты на ещё более старой версии), и ты настаиваешь на установке самого свежего релиза, чтобы вновь не пытаться чинить то, что уже давно исправно работает.

Утечки общей памяти

Архитектурно z/OS имеет общую память, которая доступна для чтения/записи всем процессам. И исторически z/OS имеет 24, 31 и 64 битную адресацию, т.е. чисто теоретически память может утекать в мизерной 24-битной адресации, в уже нормальной 31-битной памяти или в бездонной 64-битной. Любое привилегированное приложение (Key 0, SUPER MODE) может аллоцировать память в общем пространстве.

Одним из примеров использования общей памяти может служить следующая ситуация: у нас есть продукт "A", который хочет получить данные о продукте "B", для этого "A" запрашивает общую память, кладёт туда код, который запустится в адресном пространстве продукта "B" (это называет schedule SRB - Service Request Block), пройдёт по нужным блокам памяти, заполнит нужную структуру и вернётся в "A" для дальнейшей обработки результатов и затем "A" очистит общую память.

Но что если "A" будет запрашивать общую память, скажем, каждые 15 минут, но чистить не будет? Размер общей памяти будет уменьшаться до тех пор, пока различные приложения не начнут падать (ABEND) из-за нехватки этой памяти. Фишка в том, что даже если убить "A" z/OS не вернёт не очищенную общую память (на то она общая, особенная и может быть использована только привилегированными приложениями). Т.к. этой памяти станет мало, придётся рестартовать LPAR, это процесс называется IPL.

Поэтому нам, как разработчикам, нужно быть очень внимательными с общей памятью и пытаться чистить её даже в случае не нормального (kill) завершения приложения.

Нестабильность системы

"В смысле мейнфреймы не стабильны?". Тут суть в том что конфигурация боевых мейнфреймов и наших девелоперских мейнфреймов - это совершенно разные подходы к отказоустойчивости и администрированию. Как разработчик, я могу отключать диски(DASD), менять каталоги, смотреть информацию по системе, менять приоритет процессов (джобов) и многое другое, что в реальной жизни даже не всем администраторам мейнфреймов позволено делать. Всё это нужно, чтобы разработчики больше времени тратили на разработку, а не на ожидание получения доступов и разрешений.

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

Или кто-то включил PRIMEPSA, которая не занулит всю запрашиваемую вашим приложением память, а, например, всё заполнит байтом 0xAA. Тем самым ваш продукт начинает падать с ABENDами в разных модулях потому, что проверки на NULL теперь пропускают то, что обычно было NULL.

Или кто-то стал делать нагрузочное тестирование на том же LPAR что и вы. В итоге у вашего приложения CPU голодание, и вам нужно переезжать на другой LPAR или другой мейнфрейм.

Всё это приводит к перезагрузке (IPL) LPARов раз в 1-2 недели, когда как на боевых мейнфреймах это происходит 1-2 раза в год.

На боевых мейнфреймах, если у вас нет на что-то прав, вы либо просите администратора что-то сделать для вас, либо запрашиваете новые права, которые не факт что вам дадут, а если дадут - могут попросить подписать новые документы, например, NDA.

Google не поможет

И Stack Overflow тоже. Очень часто сталкиваешься с тем, что при гуглении вопроса или ключевого слова находится всего несколько результатов поискового запроса. Более того, это могут быть форумы на которых человек задавал тот же самый вопрос что и вы ... лет 10 назад ... на него так никто и не ответил. Такое происходит не всегда, но чаще приходится скачивать и читать документации чтобы самому ответить на собственный вопрос.

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

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

Кастомеры

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

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

Например, один из бразильских кастомеров имеет много баз данных Adabas на z/OS и им критически было важно мониторить информацию о том, как эти базы используют хранилище данных. Собственно, нам пришлось это реализовывать в наш продукт за короткий промежуток времени. В итоге это фича доступна всем, хотя ценность приносит только малому числу кастомеров.

Азиатские кастомеры, как ABC или CCB, очень дотошны, они пытаются разобраться во всём. Если они найдут незначительный баг, то будут требовать объяснения о причинах этого бага и того, как он был пофикшен. В итоге разработчик может тратить несколько часов на объяснения техподержке, менеджеру, кастомеру вместо выполнения реальной работы.

Есть принципиальные кастомеры, которым нужно, чтобы всё было готово вчера, есть понимающие, с которыми можно обсудить примерные сроки, или которым можно подготовить тест-фикс для проверки решения (особенно если на своих системах проблема не воспроизводится).

Заключение

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

В целом, если зайти в офис (после того как их откроют, разумеется) к мейнфрейм разработчикам, вы не увидите сильных различий: тот же scrum, те же сопутствующие митинги, всем знакомые IDE, автоматизация на том же Python, какие-то web UI, те же тикеты в Jira и много чего ещё узнаваемого. Думаю, глобализация и желание всех компаний работать эффективно делает всё везде похожим.

Подробнее..

Перевод Истоки виртуализации

03.11.2020 20:15:07 | Автор: admin

Внимание, вопрос: кто стоял у истоков виртуализации? При всей любви к продуктам этой компании, ответ VMware будет неверен. Пионерами на этом рынке были General Electric, Bell Labs и IBM.

Сотворение виртуальной машины

Уже в начале шестидесятых портфолио IBM насчитывало десятки различных систем. Каждое новое поколение разительно отличалось от предыдущего. Покупатели рвали на себе волосы в тщетных попытках поспеть за всеми инновациями и требованиями нового железа. Кроме того, в те годы еще была актуальна парадигма один компьютер за один присест выполняет только одну задачу. Вам нужно больше? Будьте добры прибегнуть к пакетной обработке (batch processing), когда одно задание выполняется на ЭВМ вслед за другим без вмешательства оператора. Неудобно, правда? Но специалисты IBM не считали это проблемой. Большая часть пользователей их машин принадлежала к научному сообществу. Им вполне хватало.

Но разнообразие систем понемногу начало досаждать IBM. Компания приняла решение заместить свой технологический зоопарк новым мейнфреймом S/360, который ко всему прочему обладал бы обратной совместимостью. Предполагалось, что компьютер будет однопользовательским и сможет работать с пакетами задач.

К первому июля 1963 года эта концепция развалилась. MIT анонсировал Project MAC Mathematics and Computation, а не то, о чем вы могли бы подумать. Более поздняя расшифровка этого названия звучит как Multiple Access Computer. Финансировался проект щедрым грантом DARPA объемом в $2 млн средства были выделены в том числе на изучение особенностей и перспектив компьютеростроения в основном, в области разработки операционных систем, искусственного интеллекта и теории вычислений. А новый грант это новые задачи. И, соответственно, новый компьютер, который сможет с ними справиться. MIT требовалась не простая, а многопользовательская машина. Первое, о чем подумали инженеры почему бы не заказать готовый компьютер у GE или IBM?. Однако IBM на тот момент пребывала в уверенности, что спроса на машины с разделением времени практически нет. А модифицированную под все хотелки версию стокового IBM-компьютера в MIT покупать не хотели. GE, напротив, с удовольствием приняла предложение MIT и решилась взяться за разработку многопользовательской машины.

И тут оказалось, что спрос на такие машины на рынке есть. Притом весьма солидный даже в Bell Labs заинтересовались в их приобретении. Тревожный звоночек.

В ответ на предложения от MIT и Bell Labs в IBM была срочно разработана и выпущена CP-40. Это первая операционная система, которая реализовывала полную виртуализацию. CP-40 была предназначена специально для IBM S/360 model 40 и поддерживала до 14 виртуальных машин c 256 Кб виртуальной памяти одновременно.

Параллельно с CP-40 была разработана программа CMS. Она обеспечивала среду для запуска приложений и взаимодействия с пользователями. CMS была крохотной интерактивной ОС для одного пользователя. Вся магия виртуализации обеспечивалась именно CP. Суть в том, что CP запускалась на мейнфрейме и создавала N-ное количество виртуальных машин под управлением CMS. Первый релиз CP/CMS состоялся в 1968-ом году, а к 1972-му на рынок была выпущена ее стабильная версия.

Традиционно компьютеры с таймшерингом поровну делили между несколькими пользователями процессорное время, память и прочие ресурсы. Характерный пример ОС MultiCS, разработанная в MIT для Project MAC. Позднее она была передана в Bell Labs, где впоследствии эволюционировала в Unix.

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

Вслед за CP-40 была разработана ОС CP-67. Именно ее можно назвать первым промышленным гипервизором. Позднее CP-67 эволюционировала в VM/370 для мейнфрейма S/370.

Переносимость программного обеспечения

Чуть выше мы упомянули Unix. Несмотря на то, что эта ОС не умеет запускать гостевые операционные системы, она подойдет для иллюстрации другого свойства ПО.

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

В зависимости от конфигурации системы пользователь может установить собственный набор дополнительного ПО и управлять политиками безопасности. Но не только этим славна Unix де-факто, это первая операционная система, открывшая дорогу к виртуализации приложений.

Все ее предшественники писались на голом языке ассемблера, что намертво привязывало их к конкретному компьютерному железу. В то же время C, на котором была написана Unix, позволял портировать ее на любой компьютер с куда меньшими усилиями. Достаточно было переписать специфичные участки кода и перекомпилировать ОС для новой платформы. Переносимость сделала Unix самой популярной системой своего времени.

Виртуализация приложений

Любой искушенный пользователь Unix, владеющий компиляторами C, мог без труда запустить любую программу на любом компьютере. Удобно? Почти. Осталось найти способ переносить приложения между компьютерами, минуя процесс компиляции. То есть виртуализировать их.

В 1990 году Sun Microsystems запустила проект Stealth. Он был инициирован инженерами компании, которым не нравился подход Sun к использованию API C и C++. Они были уверены в том, что есть лучший способ писать и запускать приложения. Проект несколько раз переименовывали среди версий были даже экзотичные Oak и Web Runner. Как вы уже наверняка догадались, в 1995 году проект достиг релиза под окончательным именем Java.

Планировалось, что наибольшее применение Java найдет во всемирной паутине. Интернет это колоссальная сеть, состоящая из компьютеров, работающих под разными операционными системами. Платформа, которая позволит запускать одни и те же приложения на всех этих машинах без необходимости переписывать и перекомпилировать их, была обречена на успех. В 1996 году в свет вышел Java Development Kit (JDK).

Java был уникален в своем роде. Можно было запустить написанную на нем программу на любом компьютере с установленной бесплатной Java Run-Time Environment (JRE).

Говоря упрощенно, Java работает так: сначала написанная программа компилируется в байт-код Java. Это своеобразный язык-посредник, с которым умеет работать JRE. Непосредственно в момент запуска программы JRE компилирует программу из байт-кода для целевого железа. Программисту не надо заботиться о том, для какого железа и какой ОС он пишет код, а пользователю не приходится заниматься компиляцией.

JRE включает в себя массу компонентов, наиболее интересным из которых является Java Virtual Machine. Любое приложение запускается именно в ней. Можно представить себе JVM как очень маленькую ОС, созданную для того, чтобы запускать Java-приложения. Заботы о портировании JVM для всех мыслимых устройств Sun/Oracle берет на себя. Тем не менее, этот подход имеет известные ограничения.

Широкое распространение аппаратной виртуализации

Как было сказано выше, IBM первой применила концепцию виртуальных машин в коммерческой среде. Виртуальные машины, подобные тем, что запускались на мейнфреймах IBM, до сих пор используются, хотя большинство компаний отказались от мейнфреймов.

Еще в январе 1987 года Insignia Solutions продемонстрировала программный эмулятор под названием SoftPC. Он позволял запускать приложения DOS на рабочих станциях под управлением Unix. Это был невероятный цифровой подвиг. В то время ПК, способный запустить MS-DOS, стоил порядка $1500, а использование SoftPC обходилось всего в $500.

К 1989 году Insignia Solutions выпустила версию SoftPC для Mac. В этой версии была добавлена возможность запускать приложения Windows. К 1994 году Insignia Solutions начала продавать свое программное обеспечение с разными предустановленными операционными системами в том числе с SoftWindows и SoftOS/2.

Успех SoftPC вдохновил и других игроков. В 1997 году Apple создала программу под названием Virtual PC и начала распространять ее через компанию Connectix. Virtual PC, как и SoftPC, позволял пользователям запускать копию Windows на Mac, это позволило обойти проблему несовместимости программного обеспечения. А в 1998 году была основана всемирно известная компания VMware. Год спустя на рынок вышла первая версия VMware Workstation. Сначала она была доступна только в Windows, но позже добавилась поддержка других операционных систем.

VMware достойна упоминания хотя бы потому, что на данный момент это безусловный лидер рынка виртуализации. В 2001 году VMware выпустила два новых продукта для корпоративного сегмента: ESX Server и GSX Server. GSX Server позволял пользователям запускать виртуальные машины поверх существующей операционной системы, например Microsoft Windows. Это так называемый гипервизор 2-го типа. ESX Server, гипервизор 1-го типа, не требует наличия ОС-хоста.

Гипервизоры 1-го типа намного более эффективны, поскольку для их работы не требуется выделять ресурсы на запуск основной системы. Кроме того, они традиционно более гибки в настройке.

После выпуска ESX Server в 2001 году в корпоративном сегменте наметился экспоненциальный рост интереса к виртуализации. VMware добавила много дополнительных продуктов для улучшения функционала ESX Server.

Появились и другие поставщики ПО для виртуализации. В 2003 году Microsoft приобрела Connectix, и Virtual PC была переиздана. Сначала под брендом Microsoft Virtual PC 2004, затем Microsoft Virtual Server 2005.

В 2007 на рынке виртуализации появился еще один игрок Citrix Inc. Компания приобрела XenSource, платформу виртуализации с открытым исходным кодом, созданную в 2003 году, и вскоре после этого переименовала продукт в XenServer.

Публикация приложений

Во времена UNIX доступ к опубликованным приложениям можно было получить через Telnet, а затем SSH.

Windows и OS/2 не давали удаленного доступа к приложениям без использования сторонних инструментов. А существовавшее специализированное ПО было доступно только одному пользователю за раз.

Кому-то в IBM пришла в голову идея создать многопользовательский интерфейс для OS/2, однако боссам компании идея не пришлась по вкусу. В 1989 году Эд Якобуччи ушел из IBM и основал собственную компанию под названием Citrus. Вскоре компания была переименована в Citrix, комбинацию Citrus и Unix.

Citrix получила лицензию на исходный код OS/2 и приступила к созданию программного расширения для нее. Два года спустя OS/2 таки получила многопользовательский интерфейс MULTIUSER.

В 1991 году Microsoft объявила об окончании поддержки OS/2, и Citrix пришлось свернуть проект. Однако полученный опыт позволил переориентироваться на создание подобного ПО, но уже для Windows.

В 1993 году Citrix приобрела Netware Access Server у Novell. В 1995 году этот продукт начал продаваться под именем WinFrame. WinFrame представляла из себя Windows NT 3.5 с возможностями удаленного доступа. Сразу несколько пользователей могли одновременно подключиться к ней для удаленного запуска приложений.

Во время разработки WinFrame для Windows NT 4.0 Microsoft отказала Citrix в лицензии, и продукт по соглашению сторон был интегрирован в Windows NT 4.0 в качестве набора служб терминалов. Citrix согласилась не создавать конкурирующий продукт, но получила возможность расширить функциональные возможности служб терминалов.

Виртуальные рабочие столы

Виртуальные рабочие столы в их современном понимании это весьма молодая тема. В чем-то их концепция похожа на то, что IBM предложила в далеких 1960-х. Каждый пользователь получает собственную выделенную ОС и может делать в ней всё, что ему заблагорассудится, не подвергая опасности других пользователей в системе.

Переход от виртуальных рабочих столов на мэйнфреймах к виртуальным рабочим столам в том виде, в каком мы их знаем сегодня, на самом деле произошел только в 2007 году, когда VMware представила свой продукт для VDI. В принципе, сотрудники компаний и ранее могли пользоваться виртуальными рабочими столами в качестве основного ПК, но это было сопряжено с массой административных сложностей. А появление Virtual Machine Manager и аналогичных продуктов дало мощный старт целому направлению в области виртуализации.

В будущих статьях мы подробно рассмотрим самые интересные аспекты истории виртуализации поговорим и о железе, и о знаковых программных решениях.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru