(прошу не ругаться сильно, это размышления перед сном).
В своё время, первые протоколы сетевого взаимодействия не имели жёсткого деления на уровни. Данные «просто передавались» и «просто читались». Постепенно возникло понимание, что каждый раз изобретать универсальный комбайн (не совместимый с другими комбайнами) это дорого и неудобно.
Протоколы разделили на уровни: физический-канальный, сетевой, транспортный, прикладной. Потом к этой (практически использующейся) модели 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'а,…
В своё время, первые протоколы сетевого взаимодействия не имели жёсткого деления на уровни. Данные «просто передавались» и «просто читались». Постепенно возникло понимание, что каждый раз изобретать универсальный комбайн (не совместимый с другими комбайнами) это дорого и неудобно.
Протоколы разделили на уровни: физический-канальный, сетевой, транспортный, прикладной. Потом к этой (практически использующейся) модели 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'а,…
