Comments 19

И сразу вопрос знатокам: это всё с Docker как-то совместимо? Или в зоне действия данного закона про современные средства развёртывания можно забыть?

Про Docker в ГОСТ ни слова, как и про средства развертывания. ГОСТ не закон, нет требований к обязательному соответствию.
Маловероятно, что связано, по крайней мере если речь о линукс-контейнерах на линукс-хосте. Докер в контексте защиты информации сам по себе является интерфейсом к средствам ОС изоляции пользовательских процессов друг от друга.

Вот то-то и оно. В результате может получиться конфликт между требованиями ГОСТ и потребностями Docker. Но найти достаточно компетентного человека, который мог бы дать развёрнутый ответ, никак не удаётся.

Есть роль, а есть Hyper-V Server. Но сути этом в целом не меняет.
Microsoft Hyper-V Server 2008 — бесплатная операционная система с единственной ролью — сервером виртуализации. Все равно хостовая система с ролью.
ГОСТ Р 56938-2016 определяет 2 типа гипервизоров:

•Гипервизор 1 типа – устанавливается непосредственно на аппаратную платформу, к таким гипервизорам по ГОСТ относятся VMware vSphere, Hyper-V, Citrix XenServer и пр.
•Гипервизор 2 типа – устанавливается в хостовую операционную систему. К таким гипервизорам можно отнести VirtualBox, VMWare Workstation и пр.

Я понял в чём дело: «трудности перевода» ( хотя перевести run как инсталлируется(!)... )

Type-1, native or bare-metal hypervisors

These hypervisors run directly on the host's hardware to control the hardware and to manage guest operating systems.

Type-2 or hosted hypervisors

These hypervisors run on a conventional operating system (OS) just as other computer programs do.

Если хотя бы заменить одно слово install-руется на правильный термин:

•Гипервизор 1 типа – выполняется непосредственно на аппаратной платформе, к таким гипервизорам по ГОСТ относятся VMware vSphere, Hyper-V, Citrix XenServer и пр.
•Гипервизор 2 типа – выполняется поверх хостовой операционной системы. К таким гипервизорам можно отнести VirtualBox, VMWare Workstation и пр.

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

3.14 гипервизор II типа: Гипервизор, устанавливаемый в среде хостовой операционной системы в качестве прикладного программного обеспечения.
Мне довелось подискутировать начальником одного из отделов ФСТЭК в Новосибирске.

С его слов, деление на 1-й и 2-й уровень очень условно и нет четкой границы между ними. Эти уровни придуманы были чисто для удобства и не более
Дискутировать о виртуализации с представителем шарашкиной госконторы, которая давит конкуренцию на рынке, выдавая сертификаты дерьмовым решениям, которые стоят не дешевле лидеров мирового рынка? Знаете толк. Всякие там vExpert`ы (Ник Маршалл, например) тоже подразделяют гипервизоры на типы, например, по признаку того, «творится» ли виртуализация посредством ядра/модуля ядра или софтом (ну, там отдельный application layer часто рассматривается), как обслуживается vm i/o стэк — через «parent partition» или каким другим способом и т.д. Есть мнение, что эти вот vExpert`ы и прочие VCDX`ы чуть лучше знают.
Сейчас вся виртуализация «ядерная». Оставим вне обсуждения всякие эмуляторы вроде Bochs и ему подобные. Остановимся только на гипервизорах, которые могут запускать на себе разные ОС (Windows, Linux, FreeBSD, OS/2 и т.д.)

Лично я не вижу принципиальной разницы между типами гипервизоров, хотя и админил entrprise (два кластера VMWare, СХД Celerra и VNX, блейд 7000 навскидку — что вспомнил) до июля 2017, пока не сменил место работы. Все деление, фактически, сводится к одному пункту: является ли роль гипервизора основной и единственной данного сервера и ОС, которая на нем установлена.

К примеру, гипервизор QEMU в связке с libvirt (плюс всякие стеки) и модулем KVM. Если это главная роль, то это первый тип. Если нет — второй.

BHyVe априори невозможно отнести к какому-либо типу, пока неизвестно окружение. Поставь я на систему всякие bind, nginx, db и т.д., я получу второй тип. А прикрути я к системе тот же libvirt плюс еще некоторые «обвязки» для работы гипервизора, плюс ZFS Raid и ZVOL, не ставя помимо этого еще какой софт, я получу первый тип. Различие будет только в том, что система будет полноценная, а не порезаная, как в том же ESXi

P.S. На 100% истинность не претендую. Тем не менее, поработав в enterprise, я для себя сделал такой вывод
Как я отметил выше, одной из важнейших черт является обслуживание vm i/o стека, ESXi тут вообще в отдельную категорию вываливается, но и Hyper-V с Xen`ами отличаются от виртуалбоксов.
P.S. Выделяя жирным это «админил entrprise» вы меня напугать хотите? Мидл-рэндж массивами и шассями c7000? Их есть у меня и были всякие.
Я лишь обозначил, что я смыслю в том, что говорю. Про I/O соглашусь.
То, что ESXi отдельная песня, это и ежу понятно. Но тем не менее его относят к первому типу. Я бы отнес его к отдельной категории внутри 1-го типа.

P.S. На правах юмора. Я не зеркало, чтобы пугать
То, что ESXi отдельная песня, это и ежу понятно. Но тем не менее его относят к первому типу. Я бы отнес его к отдельной категории внутри 1-го типа.
Да, есть и такое подразделение:
monolithic(VMSphere) and microkernalized(Hyper-V) Hypervisors
См. superuser.com Q 836116 — неплохая подборка информации и URLs
Выделяя жирным это «админил entrprise» вы меня напугать хотите?

во-во, я тоже хотел спросить: если уж два HA-кластера — это кровавый энтерпрайз, то у меня тогда что ))
ГОСТ Р 56938-2016 определяет 2 типа гипервизоров:

•Гипервизор 1 типа – устанавливается непосредственно на аппаратную платформу, к таким гипервизорам по ГОСТ относятся VMware vSphere, Hyper-V, Citrix XenServer и пр.
•Гипервизор 2 типа – устанавливается в хостовую операционную систему. К таким гипервизорам можно отнести VirtualBox, VMWare Workstation и пр.

Все деление, фактически, сводится к одному пункту: является ли роль гипервизора основной и единственной данного сервера

По мнению авторов деления — вовсе нет Ж-)

Лично я в 2008 задумался над похожей ситуацией:
Q: на этом хосте есть виртуальная машина с 8-ю виртуальными процессорами.
Виртуальная машина иногда заметно грузит свои виртуальные процессоры, но в taskmgr на хосте не вижу значительной нагрузки на процессоры

A: из-за особенностей архитектуры Hyper-V этот самый Task Manager покажет... всего-лишь навсего загрузку процессора хостовой ОС. Виртуальные машины при этом учитываться не будут – поскольку хостовая ОС, точно так же, как и все виртуальные машины – работает в своем изолированном разделе

Так я узнал, что «Virtual PC Server» ( оффициально у него др.название) — это был 2-ой тип, а вот Hyper-V — прогрессивный Ж-) 1-ый
Only those users with full accounts are able to leave comments. Log in, please.