Билет №59. Виртуализация памяти 64bit. Pae.

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

Расширение физического адреса (PAE) — это функция процессора, которая позволяет процессорам x86 (читать как 86-битные процессоры) получать доступ к более чем 4 ГБ физической памяти в версиях Windows. Некоторые 32-разрядные версии Windows Server, работающие в системах x86, могут использовать PAE для доступа до 64 ГБ или 128 ГБ физической памяти в зависимости от размера физического адреса процессора.

Разумеется, даже без виртуализации в середине 2000х индустрия уже вовсю упиралась в ограничения 32 бит. Существовали частичные обходные пути в виде PAE (Physical Address Extension), но усложняли и замедляли код. Переход на 64 бита был предрешен.

AMD представила свою версию архитектуры, которую назвала AMD64. В Intel же возлагали надежды на платформу IA64 (Intel Architecture 64), которую мы также знаем под именем Itanium. Однако рынок встретил эту архитектуру без большого энтузиазма, и в итоге Intel были вынуждены реализовать собственную поддержку инструкций AMD64, которую сначала назвали EM64T, а потом просто Intel 64.

В конечном итоге мы все знаем эту архитектуру как AMD64, x86-64, x86_64 или иногда встречается x64.

Поскольку основное использование серверов на то время предполагалось в качестве физических, без виртуализации, то с первыми 64-битными процессорами в виртуализации случился технический курьез. В качестве лабораторных серверов часто использовались вложенные гипервизоры, далеко не все могли себе позволить несколько кластеров физических серверов. И в итоге оказывалось, что ВМ нагрузки во вложенном гипервизоре могла работать только в 32битном режиме.

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

Впоследствии, AMD вернула возможность лимитирования сегментов, а Intel попросту дождалась введения аппаратной виртуализации.

UMA

Uniform Memory Access — архитектура многопроцессорных компьютеров с общей памятью. Все процессоры в UMA-архитектуре используют физическую память одновременно.

Многопроцессорные системы x86 начали работу с режима UMA (Uniform Memory Access), в рамках которого расстояние от любого процессора (задержка на доступ к ячейке памяти) до любой планки памяти одинаково. В процессорах Intel данная схема работы сохранялась даже после появления многоядерных процессоров вплоть до поколения 54xx (Harpertown). Начиная с поколения 55xx (Nehalem) процессоры перешли на архитектуру NUMA.

С точки зрения логики исполнения — это появление дополнительных аппаратных потоков, на которые можно назначить потоки кода для исполнения параллельно.

NUMA

NUMA (Non Uniform Memory Access) — архитектура с неравномерным доступом к памяти. В рамках данной архитектуры у каждого процессора существует своя локальная память, доступ к которой осуществляется напрямую с низкими задержками. Доступ к памяти других процессоров осуществляется опосредованно с более высокими задержками, что приводит к снижению производительности.

Билет №60. Виды виртуализации архитектур.

• Полная виртуализация — подход, при котором эмулируется вообще все аппаратное обеспечение, включая процессор. Позволяет создавать аппаратно независимые среды, и запускать, например, ОС и прикладное ПО для платформы x86 на системах SPARC, или всем известные эмуляторы Spectrum с процессором Z80 на привычных x86. Обратной стороной полной независимости являются высокие накладные расходы на виртуализацию процессора и низкая итоговая производительность.

• Неполная виртуализация — подход, при котором виртуализуются не 100% аппаратного обеспечения. Поскольку в индустрии наиболее распространена именно неполная виртуализация — мы будем говорить именно о ней. О платформах и технологиях системных виртуальных машин с неполной виртуализацией для архитектуры x86. В данном случае идет неполная виртуализация процессора, т.е. за исключением частичной подмены или сокрытия определенных системных вызовов, бинарный код виртуальной машины исполняется процессором напрямую.

• Программная виртуализация Очевидным следствием архитектуры процессора и привычек операционных систем работать в нулевом кольце стала проблема — ядро гостевой ОС не может работать в привычном месте. Нулевое кольцо занято гипервизором, и стоит только позволить гостевой ОС туда же попасть — с одной стороны мы вернулись в реальный режим со всеми вытекающими, а с другой — гостевая ОС не ожидает там никого, и моментально порушит все структуры данных и уронит машину. Но решилось все достаточно просто: поскольку для гипервизора гостевая ОС — просто набор страниц памяти с полным прямым доступом, а виртуальный процессор — просто очередь команд, то почему бы их не переписать? Прямо на лету гипервизор выбрасывает из очереди команд на исполнение на виртуальном процессоре все инструкции, требующие привилегий нулевого кольца, заменяя их на менее привилегированные. А вот результат работы этих инструкций подается ровно так же, как если бы гостевая ОС была в нулевом кольце. Таким образом виртуализовать можно вообще все что угодно, вплоть до полного отсутствия гостевой ОС. Именно такой подход был реализован командой разработчиков в 1999 году в продукте VMware Workstation, а далее в 2001 в серверных гипервизорах GSX (второго типа, как и Workstation) и ESX (первого типа).

• Паравиртуализация — это очень простая концепция, которая предполагает, что гостевая ОС знает, что она в виртуальной машине, и знает как можно обратиться к хостовой ОС за определенными системными функциями. Таким образом снимается проблема эмуляции нулевого кольца — гостевая ОС знает, что она не в нулевом и ведет себя соответственно. Паравиртуализация в x86 появилась в 2003 году вместе с проектом Linux Xen. Определенные паравиртуализованные функции реализованы и в гипервизорах с полной виртуализацией через специальные виртуальные драйверы в гостевых ОС, общающиеся с гипервизором для снижения накладных расходов на виртуализацию. Например, у VMware ESXi для ВМ есть паравиртуальный SCSI адаптер PVSCSI, позволяющий повысить общую производительность для ВМ с интенсивными дисковыми операциями, как например нагруженные СУБД. Драйверы для паравиртуальных устройств идут в дополнительных пакетах (например VMware Tools), либо уже включены в дистрибутивы Linux (open-vm-tools).

• Аппаратная виртуализация По мере развития и роста популярности виртуализации возникло желание как производителей платформ сократить свои расходы на поддержку, так и с точки зрения безопасности гарантировать защиту аппаратным образом. Проблема решилась очень простым способом — фирменные технологии аппаратной виртуализации Intel VT-x и AMD-V добавили, если отбросить глубокие технические детали, минус первое кольцо защиты для гипервизора. Таким образом наконец устанавливалась привычная для ОС ситуация работы в нулевом кольце.

Билет №61. Типы гипервизоров.

Тип 2 (hosted)

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

Примеры гипервизоров второго типа: VMware Workstation / Fusion, Oracle VM VirtualBox, Parallels Desktop, VMware Server (ex-GSX), Microsoft Virtual Server 2005

Тип 1 (bare-metal)

Гипервизоры первого типа не требуют ОС общего назначения, в отличие от предыдущих. Сам гипервизор представляют собой монолит, который управляет как распределением вычислительных ресурсов, так и операциями ввода-вывода. В нулевом кольце безопасности располагается микро-ядро, поверх которого работают все управляющие конструкции. В данной архитектуре гипервизор управляет распределением вычислительных ресурсов и сам контролирует все обращения виртуальных машин к устройствам. Первым гипервизором первого типа для x86 долгое время считался VMware ESX, хотя сейчас мы его отнесли бы к 1+. Единственным “честным” представителем этого типа на сегодня является VMware ESXi — наследник ESX, после того как тому откусили родительский раздел с RHEL.

Прямой доступ к гипервизору отсутствует, что выгодно отличает этот тип гипервизора от гипервизоров второго типа в аспекте безопасности.

Недостатком здесь являются драйверы устройств: для обеспечения “тонкости” платформы и устранения излишних усложнений от версии к версии происходит ротация драйверов устройств, что делает физическую инфраструктуру зависимой от HCL (hardware compatibility list).

Тип 1+ (Гибридный гипервизор)

Гипервизоры гибридного типа (они же тип 1+, 1a, 1.5) характеризуются изоляцией базовой ОС в особую сущность, которая называется родительский раздел (parent partition в терминологии Microsoft Hyper-V) или родительский домен (domain dom0 в терминологии Xen). Так, после установки роли гипервизора, ядро переходит в режим поддержки виртуализации и за распределение ресурсов на хосте отвечает гипервизор. Но родительский раздел берет на себя функцию обработки обращений к драйверам устройств и операциям ввода-вывода.

По сути, родительский раздел становится неким провайдером между всеми сущностями стека виртуализации. Данный подход удобен с точки зрения совместимости с оборудованием: не требуется вшивать в гипервизор драйверы устройств, как в случае с ESXi, а значит, список устройств сильно расширяется и слабее зависит от HCL. К достоинствам же можно отнести и разгрузку гипервизора от задачи обработки вызовов к драйверам устройств, тк все вызовы обрабатывает родительский раздел.

Верхнеуровневая архитектура гипервизоров типа 1+ выглядит так:

К гипервизорам данного типа относятся: почивший VMware ESX, Microsoft Hyper-V, Xen-based гипервизоры (Citrix XenServer и реализации Xen в различных дистрибутивах Linux). Напомним, что Citrix XenServer – это немного урезанная RHEL-based OS, и ее версионность и функционал находились в прямой зависимости от текущей версии Red-Hat Enterprise Linux. В случае с другими реализациями Xen ситуация не сильно отличается: это то же ядро Linux в режиме гипервизора Xen и базовая ОС в домене dom0. Отсюда следует однозначный вывод, что Xen-based гипервизоры относятся к гибридному типу и не являются честными гипервизорами 1 типа.