Эталонная модель взаимодействия вычислительных систем?

    (прошу не ругаться сильно, это размышления перед сном).

    В своё время, первые протоколы сетевого взаимодействия не имели жёсткого деления на уровни. Данные «просто передавались» и «просто читались». Постепенно возникло понимание, что каждый раз изобретать универсальный комбайн (не совместимый с другими комбайнами) это дорого и неудобно.

    Протоколы разделили на уровни: физический-канальный, сетевой, транспортный, прикладной. Потом к этой (практически использующейся) модели TCP/IP попытались приделать теоретическую 7-уровневую модель OSI. Не особо прижилось (назовите мне 5 протоколов уровня представления).

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

    Примерно то же самое происходит сейчас с вычислительными машинами. Сначала это были универсальные комбайны, которые способны и железо проинициализировать, и графику нарисовать, сервером поработать. Но это дорого. Ярчайший пример — необходимость использовать дискету для установки всё ещё продающегося windows 2003. В 2010 году! Дискету! Почему? Потому, что несчастная ОС вынуждена думать о том, какие у неё там внутри контроллеры и какие у неё там прерывания. И при этом она должна ещё обеспечивать многозадачность, планирование процессорного времени на многопроцессорной системе, планирование дисковых операций и прочие сложные вещи. Ах, да, ещё и права контролировать.


    Эмуляция всегда была лабораторным чудом. О, мы можем запустить игру для Play Station! О, мы можем запустить игру для NES, SNES, ZX… А вот эмулятор IBM/360. Круто же! А вот dosbox, в котором работает UFO…

    Это всё было на уровне пробирок, лабораторий, и, быть может, игровых систем. Всё это было путём тысячекратного замедления (цена интерпретации)…

    Потом появилась виртуализация. Которая от эмуляции отличалась именно этой тысячью раз. И хотя первые виртуальные машины мало отличались от эмуляторов по функционалу (ну, быстрее были только), они уже обладали важным (важнейшим) свойством — трансляцией производительности хоста к гесту с малым оверхедом. Это было важнейшее свойство. Дальше к нему была приделана (точнее, только-только начинает появляться) инфраструктура.

    И, фактически, мы имеем сейчас что-то, похожее на модель OSI (или TCP/IP) для вычислительных машин. Мы выделили уровень абстракции, который занимается железом, хранилищами информции, инициализацией сетевой карты, распределением ресурсов и т.д. Другими словами, у ОС «отрезали» кусок снизу, оставив ей высокоуровневые задачи.

    Однако, сами ОС всё равно остаются «комбайнами». Виртуализация под них подстраивается, хотя куда более правильным было бы разрабатывать ОС, которые способны работать ТОЛЬКО при участии гипервизора. Такая ОС, конечно, потеряет универсальность, но с большой вероятностью будет компактной, стабильной (чем меньше кода, тем меньше ошибок), удобной для работы гипервизора.

    Определённые шаги в этой области уже сделал Xen, у которого есть ядро для паравиртуализации (де-факто, никакой там нет виртуализации уже, есть просто взаимодействие ОС и гипервизора, при котором ОС отдаёт всю низменную работу «на аутсорс», примерно как IP-протокол отдаёт низменную работу формирования фреймов, их отсылку, контроль отсутствия коллизий и т.д. на откуп Ethernet'у).

    … И надо сказать, по-крайней мере, в случае Xen'а, что старинный спор Торвальдса и Таненбаума разрешается неожиданно: на смену концепции «микроядра» приходит концепция «микрогигпервизора» (как говорят авторы Xen'а, 1500 строк), у которого есть «своя карманная виртуалка» (Dom0) для всяких некритичных вещей, вроде дисковых и сетевых операций; гипервизор перекладывает запросы из DomU в Dom0 (примерно как это должно делать микроядро); сам же гипервизор занят «настоящими вещами», вроде управления памятью и распределением процессорного времени.

    Вероятнее всего, в ближайшем будущем, произойдёт появление именно таких систем, рассчитанных на «доброго дядю сверху», дающего ресурсы и распределяющего их. Вероятнее всего, все производители гипервизоров придут к единому формату вызова (так, чтобы виртуальная машина с одного гипервизора могла легко быть запущена на другом). Какие-то шаги XenCloud уже делает — есть xva формат, который претендует на роль «кроссгипервизорного» формата виртуальных машин.

    Мне будущее видится в появлении некого стека вычислительной машины, который был описывал каждый уровень как самостоятельную сущность с стандартизированными интерфейсами «наверх» и «вниз». Основным отличием этого стека от существующих слоёв абстракции ПО от железа современных ОС будет стандартизация интерфейсов. Можно будет взять гипервизор от windows, промежуточный слой от linux и userspace от solaris. Или наоборот — взять xen, ядро linux, а на нём уже несколько различных систем, спокойно сосуществующих друг с другом.… примерно так, как сейчас мы можем пустить tcp как по ip, так и по ipv6, а сам ip ходит по такому числу различных канальных протоколов, что и не счесть…

    (улетая в фантазию) а ещё будет тунелирование гипервизоров (примерно как сейчас ip over ip, GRE и т.д.) — будет гипервизор xen, в котором будет гипервизор vmware, который будет способен запустить гипервизор от quest'а,…

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 29

    • НЛО прилетело и опубликовало эту надпись здесь
        +12
        ну если «оверхед» еще куда ни шло, но вот «гвест» и «скедулинг» — это уже перебор. Зачем так мучить наш язык?
          –5
          Хост/гвест уже устоявшаяся терминология. насчёт скедулинга — неправ, сейчас поправлю.
            +5
            вы хотели сказать host/guest? Или хост/гость? Если у вас в голове что-то устоялось, это никак не значит, что у всех вокруг. И если вы произносите английское слово в вербальном общении, то это никак не означает, что писать нужно по принципу «как слышу».
              0
              Да, я пишу и произношу «тред» вместо «поток», «стрим» вместо «поток» и «пайп» вместо «конвеер». Извините, это экономит слишком много времени, чтобы отдаваться на растерзание русификации.

              Но (чтобы обрадовать), я могу иногда написать МСЭ вместо файрвол.
                +3
                пусть это экономит вам время в личной переписке. В публичных статьях все-таки принято придерживаться норм языка.
                А то потом прилетят автоботы и начнут изучать наш язык из Интернета — чему они научатся?
                  +1
                  Много чему. Думаю, не больше, чем военным дотам (вместо точек), панталонам (вместо штанов), рандеву (вместо встречи) и и.д.

                  Я вот недавно обнаружил, что американцы словом «блог» называют не только блоги, но записи в блоге (я вчера написал блог в блог). А мы слово заимствовали, оно прижилось. Чем больше слов есть, тем богаче язык. От того, что у нас рядом с калькулятором образовался компьютер, только лучше стало (меньше путаницы). Так и тут. Ну будет ещё слово «гвест» помимо «гость» — хуже будет? Было одно слово, стало два.
                    +5
                    почему гвест то?
                    guest читается как гест и никак иначе.
                    А то я пока не прочитал комменты не понял че за гвесты такие. Что за странная технология, которую я не слышал.
                      0
                      Покрываю голову пеплом позора, иду исправлять.
                      +1
                      «Гвест» не экономит вам времени по сравнению с гостем, читается/произносится сложнее, заимствование неочевидно и просто выглядит уродливо.
            +1
            Почти ничего не понял о чем вы здесь, но тема интересная, кто бы объяснил доступнее :)
              +3
              Идея, в принципе, интересная.
              С другой стороны — такая кросс-совместимость между разными гипервизорами попросту не нужна: я не представляю задач, когда гостевую ОС придется переносить с одного гипервизора на другой, кроме миграции ИТ-инфраструктуры на другую платформу. А это задача совсем не частая,, и ради этого что-то еще разрабатывать — это уже чересчур.

              (улетая в фантазию) а ещё будет тунелирование гипервизоров (примерно как сейчас ip over ip, GRE и т.д.) — будет гипервизор xen, в котором будет гипервизор vmware, который будет способен запустить гипервизор от quest'а,…

              Теоретически это сделать можно даже сейчас. Но — зачем? Можно и dial-up через VoIP сделать…
                0
                Тут, скорее, вопрос не в том, «зачем нам запускать линукс на hyper-v», а в том, что это будет принципиальная смена вычислительной модели; операционные системы перестанут (хотя бы в одной из конфигураций ядра) думать про железо. Возможно, они же обленятся достаточно серьёзно, чтобы вынести учёт и планирование на гипервизора же (или на формализовавшуюся прослойку, это делающую). Не хотите попробовать винды с планировщиком от какой-нибудь realtime ОС погонять? :)

                Получающиеся компоненты будут так же независимы, как, например, независим http от нижележащего уровня. И вопрос стоит даже не «попробовать», а «как удобнее».
                  0
                  Для этого понадобится очень сильная унификация как железа — так и ПО. При нынешней ситуации это — практически нереально.
                    0
                    Унификация железа идёт во все поля. Классы устройств USB унифицированы, AHCI унифицирован, видеокарты раньше были унифицированы (VESA, VLB), потом разбежались, но никто им не мешает сбежаться обратно (в форме поддержки стандартизированных вызовов opengl).

                    Стандартизация же ПО (в смысле userspace) не требуется, т.к. существующие ядра как на гипервизоре, так и на железе одинаковый ring-3 делают.

                    Стандартизация сильно майкрософту жизнь подпортит, да (нафига платить за платный middleware, когда можно взять opensource). Но им жизнь и так активно портят :)
                      0
                      В первую очередь необходима унификация процессоров. На данный момент архитектура процессоров разных вендоров, а иногда — даже разных линеек — сильно различается.

                      Стандартизация сильно майкрософту жизнь подпортит, да (нафига платить за платный middleware, когда можно взять opensource).

                      Это позволит избавиться от проблем с корявыми драйверами и избавиться от львиной доли кода, связанной с поддержкой разных типов железа. Софт от этого улучшится весь, конкретных преимуществ MS, IBM, Oracle или какому-то другому вендору это не даст.
                  0
                  because we can
                  +2
                  Виртуализация медленно, но уверенно становиться очень перспективной и быстроразвивающейся отраслью IT, и в этом нет ничего удивительного. Эталонной модель взаимодействия станет тогда, когда производители серверных решений станут выпускать чипсеты с уже встроенным гипервизором, а разработчики ОС научат свои детища нормально с ним работать
                    0
                    А зачем гипервизор встраивать в чипсет? Всё равно и так и так гипервизору нужен dom0, так что в любом случае что-то помимо VM грузится будет. Несколько мегабайт гипервизора в этом месте совершенно не будут мешать.
                      +1
                      А что значит, встраивать в чипсет? Производители (HP, IBM, DELL) уже предлагают серверы с предустановленными гипервизороми (на USB-flash'ке или SD карте).
                      +1
                      Хотелось бы услышать про схему взаимодействия с периферийными устройствами в рамках данной модели. Разные принтеры, сканеры и прочее железо для которого требуется установка дополнительных драйверов.
                        0
                        принтеры-сканеры имеют две составляющие: во-первых они принтеры/сканеры (высокоуровневый интерфейс, который умеет смотреть на лотки, двустороннюю печать и TWAIN), а во-вторых у них есть физический интерфейс. Как известно, большинство принтеров даже при работе по сети требует установки хотя бы имитации в форме драйвера.

                        Возможно, хосты будут анонсировать принтеры по сети (внутренней, виртуальной, или, даже, внешней), вплоть до эмуляции PS/PCL для убогих недопринтеров с host-based печатью.

                        Всякого рода устройства с well-known classes (HID, MSD) будут работать аналогично. Туннелирование openGL вполне представимо; что будет делать MS с директХе? (ну, будет двигать снова свой вендор-лок, в каком-нибудь hyperX). С графикой в линуксе будет проще, чем с остальным — в принципе, никто не мешает иметь несколько dom0 (точнее не 0, а имеющих право работать с железом) — и в одном из них запускать x-server.
                        0
                        Золотая идея! Виртуализацию на каждый ПК!
                        Пусть юзеры покупают новое железо :)
                          0
                          Собственно, к моменту, когда это будет более-менее применимым для десктопа, железо пять поколений как VT поддерживать будет. Кроме того, паравиртуализация ничего от железа не требует (поддержка гипервизора в ядре гвеста программная).

                            0
                            VMware (Client Virtualization Platform) и Citrix (Xen Client) ведут работу в данном направлении.
                            0
                            Какие-то шаги XenCloud уже делает — есть xva формат, который претендует на роль «кроссгипервизорного» формата виртуальных машин.

                            Уже есть .ovf — вполне себе кроссплатформенный.

                            Однако, сами ОС всё равно остаются «комбайнами». Виртуализация под них подстраивается, хотя куда более правильным было бы разрабатывать ОС, которые способны работать ТОЛЬКО при участии гипервизора.

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

                            Можно будет взять гипервизор от windows, промежуточный слой от linux и userspace от solaris. Или наоборот — взять xen, ядро linux, а на нём уже несколько различных систем, спокойно сосуществующих друг с другом.…

                            И какой в этом смысл? Гипервизор — это законченный продукт с вполне определенным функционалом, в отличии от описания стека протоколов как OSI или TCP/IP. Что вы получите, если «губы Никанора Ивановича приставите к носу Ивана Кузьмича»?
                              0
                              Например, возможность переноса вычислительной машины из одной инфраструктуры в другую, без шаманства вида vmware convert. Грубо говоря — в одном дата-центре используют hyper-v. В другом ESX, в третьем xencloud. Берёшь, с одного на другой переносишь свою ОС — и оно всюду работает без доработки напильником.
                                0
                                Разные гипервизоры по-разному эмулируют виртуальное железо. В любом случае, вам потребуется устанавливать компоненты интеграции от соответствующего производителя. Опять же, процедура переноса — это не ежедневная операция и использовать средства v2v конвертации не так уж обременительно. Куда уж сложнее двум хостерам договориться о том, чтобы виртуальную машину можно было скопировать из одного ЦОД в другой.
                                  +1
                                  Во-первых, я говорю про паравиртуализацию. Т.е. никакого «эмулирования железа» там нет, а есть чёткое понимание гестом существования гипервизора (а так же понимания, что всё железо — проблема гипервизора).

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

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

                            Самое читаемое