ћерион Ќетворкс

8 минут

Ќесмотр€ на доступ к все более эффективному и мощному оборудованию, операции, выполн€емые непосредственно на традиционных физических (или «чистых») серверах, неизбежно сталкиваютс€ со значительными практическими ограничени€ми. —тоимость и сложность создани€ и запуска одного физического сервера говор€т о том, что эффективное добавление и удаление ресурсов дл€ быстрого удовлетворени€ мен€ющихс€ потребностей затруднено, а в некоторых случа€х просто невозможно. Ѕезопасное тестирование новых конфигураций или полных приложений перед их выпуском также может быть сложным, дорогосто€щим и длительным процессом.

»сследователи-первопроходцы ƒжеральд ƒж. ѕопек и –оберт ѕ. √олдберг в статье 1974 года («‘ормальные требовани€ к виртуализируемым архитектурам третьего поколени€» (“Formal Requirements for Virtualizable Third Generation Architectures”) - Communications of the ACM 17 (7): 412–421) предполагали, что успешна€ виртуализаци€ должна обеспечивать такую среду, котора€:

  • Ёквивалента физическому компьютеру, поэтому доступ программного обеспечени€ к аппаратным ресурсам и драйверам должен быть неотличим от невиртуализированного варианта.
  • ќбеспечивает полный контроль клиента над аппаратным обеспечением виртуализированной системы.
  • ѕо возможности эффективно выполн€ет операции непосредственно на базовых аппаратных ресурсах, включа€ ÷ѕ.

¬иртуализаци€ позвол€ет разделить физические ресурсы вычислений, пам€ти, сети и хранилища («основополагающа€ четверка») между несколькими объектами.  аждое виртуальное устройство представлено в своем программном обеспечении и пользовательской среде как реальный автономный объект. √рамотно настроенные виртуальные изолированные ресурсы могут обеспечить более защиту приложений приложений без видимой св€зи между средами. ¬иртуализаци€ также позвол€ет создавать и запускать новые виртуальные машины почти мгновенно, а затем удал€ть их, когда они перестанут быть необходимыми.

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


 ак работает виртуализаци€?

¬ невиртуальных услови€х, архитектуры х86 строго контролируют, какие процессы могут работать в каждом из четырех тщательно определенных уровней привилегий (начина€ с  ольца 0 (Ring 0) по  ольцо 3).

 ак правило, только €дро операционной системы хоста имеет какой-либо шанс получить доступ к инструкци€м, хран€щимс€ в кольце под номером 0. ќднако, поскольку вы не можете предоставить нескольким виртуальным машинам, которые работают на одном физическом компьютере, равный доступ к кольцу 0, не вызыва€ больших проблем, необходим диспетчер виртуальных машин (или «гипервизор»), который бы эффективно перенаправл€л запросы на такие ресурсы, как пам€ть и хранилище, на виртуализированные системы, эквивалентные им.

ѕри работе в аппаратной среде без виртуализации SVM или VT-x все это выполн€етс€ с помощью процесса, известного как ловушка, эмул€ци€ и двоична€ трансл€ци€. Ќа виртуализированном оборудовании такие запросы, как правило, перехватываютс€ гипервизором, адаптируютс€ к виртуальной среде и возвращаютс€ в виртуальную машину.

 ings of privilege

ѕростое добавление нового программного уровн€ дл€ обеспечени€ такого уровн€ организации взаимодействи€ приведет к значительной задержке практически во всех аспектах производительности системы. ќдним из успешных решений было решение ввести новый набор инструкций в ÷ѕ, которые создают, так называемое, «кольцо 1», которое действует как кольцо 0 и позвол€ет гостевой ќ— работать без какого-либо вли€ни€ на другие несв€занные операции.

Ќа самом деле, при правильной реализации виртуализаци€ позвол€ет большинству программных кодов работать как обычно, без каких-либо перехватов.

Ќесмотр€ на то, что эмул€ци€ часто играет роль поддержки при развертывании виртуализации, она все же работает несколько иначе. ¬ то врем€ как виртуализаци€ стремитс€ разделить существующие аппаратные ресурсы между несколькими пользовател€ми, эмул€ци€ ставит перед собой цель заставить одну конкретную аппаратную/программную среду имитировать ту, которой на самом деле не существует, чтобы у пользователей была возможность запускать процессы, которые изначально было невозможно запустить. ƒл€ этого требуетс€ программный код, который имитирует желаемую исходную аппаратную среду, чтобы обмануть ваше программное обеспечение, заставив его думать, что оно на самом деле работает где-то еще.

Ёмул€ци€ может быть относительно простой в реализации, но она почти всегда несет за собой значительные потери производительности.

—огласно сложившимс€ представлени€м, существует два класса гипервизоров: Type-1 и Type-2.

  • Bare-metal гипервизоры (исполн€емые на «голом железе») (Type-1), загружаютс€ как операционна€ система машины и – иногда через основную привилегированную виртуальную машину – сохран€ют полный контроль над аппаратным обеспечением хоста, запуска€ каждую гостевую ќ— как системный процесс. XenServer и VMWare ESXi – €ркие примеры современных гипервизоров Type-1. ¬ последнее врем€ использование термина «гипервизор» распространилось на все технологии виртуализации хостов, хот€ раньше оно использовалось только дл€ описани€ систем Type-1. ѕервоначально более общим термином, охватывающим все типы систем, был «ћониторы виртуальных машин». “о, в какой степени люди используют термин «мониторы виртуальных машин» все это врем€, наводит мен€ на мысль, что они подразумевают «гипервизор» во всех его интерпретаци€х.
јрхитектура гипервизора (“ип-1)
  • √ипервизоры, размещенные на виртуальном узле (Type-2) сами по себе €вл€ютс€ просто процессами, работающими поверх обычного стека операционной системы. √ипервизоры Type-2 (включа€ VirtualBox и, в некотором роде, KVM) отдел€ют системные ресурсы хоста дл€ гостевых операционных систем, создава€ иллюзию частной аппаратной среды.
јрхитектура гипервизора (“ип-2)

¬иртуализаци€: паравиртуализаци€ или аппаратна€ виртуализаци€

¬иртуальные машины полностью виртуализированы. »ными словами, они думают, что они обычные развертывани€ операционной системы, которые живут собственной счастливой жизнью на собственном оборудовании. ѕоскольку им не нужно взаимодействовать со своей средой как-то иначе, чем с автономной ќ—, то они могут работать с готовыми немодифицированными программными стеками. ќднако раньше за такое сходство приходилось платить, потому что преобразование аппаратных сигналов через уровень эмул€ции занимало дополнительное врем€ и циклы.

¬ случае с паравиртуализацией (PV – Paravirtualization) паравиртуальные гости хот€ бы частично осведомлены о своей виртуальной среде, в том числе и том, что они используют аппаратные ресурсы совместно с другими виртуальными машинами. Ёта осведомленность означает, что хостам PV не нужно эмулировать хранилище и сетевое оборудование, и делает доступными эффективные драйверы ввода-вывода. Ќа первых порах это позвол€ло гипервизорам PV достигать более высокой производительности дл€ операций, требующих подключени€ к аппаратным компонентам.

“ем не менее, дл€ того, чтобы предоставить гостевой доступ к виртуальному кольцу 0 (т.е. кольцу -1), современные аппаратные платформы – и, в частности, архитектура Intel Ivy Bridge – представили новую библиотеку наборов инструкций ÷ѕ, котора€ позволила аппаратной виртуализации (HVM – Hardware Virtual Machine) обойти узкое место, св€занное с ловушкой и эмул€цией, и в полной мере воспользоватьс€ преимуществами аппаратных расширений и немодифицированных операций €дра программного обеспечени€.

“акже значительно повысить производительность виртуализации может последн€€ технологи€ Intel – таблицы расширенных страниц (EPT – Extended Page Tables).

¬ св€зи с этим, в большинстве случаев можно обнаружить, что HVM обеспечивает более высокую производительность, переносимость и совместимость.


јппаратна€ совместимость

 ак минимум, несколько функций виртуализации требуют аппаратную поддержку, особенно со стороны ÷ѕ хоста. »менно поэтому вы должны убедитьс€, что на вашем сервере есть все, что вам необходимо дл€ задачи, которую вы собираетесь ему дать. Ѕольша€ часть того, что вам нужно знать, хранитьс€ в файле /proc/cpuinfo и, в частности, в разделе «flags» (флаги) каждого процессора. ќднако вам нужно знать, то искать, потому что флагов будет очень много.

«апустите эту команду, чтобы посмотреть, что у вас под капотом:

$ grep flags /proc/cpuinfo

 онтейнерна€ виртуализаци€

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

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

 онтейнер в свою очередь фактически представл€ет собой приложение, запускаемое из скриптообразного шаблона, которое считает себ€ операционной системой. ¬ контейнерных технологи€х, таких как LXC и Docker, контейнеры – это не что иное, как программные и ресурсные (файлы, процессы, пользователи) средства, которые завис€т от €дра хоста и представлени€ аппаратных ресурсов «основополагающей четверки» (т.е. ÷ѕ, ќ«”, сеть и хранилище) дл€ всего, то они делают.

јрхитектура контейнера

 онечно, с учетом того, что контейнеры фактически €вл€ютс€ изолированными расширени€ми €дра хоста, виртуализаци€ Windows (или более старых или новых версий Linux с несовместимыми верси€ми libc), например, на хосте Ubuntu 16.04 будет сложна или невозможна. Ќо эта технологи€ обеспечивает неверо€тно простые и универсальные вычислительные возможности.


ѕеремещение

ћодель виртуализации также позвол€ет использовать широкий спектр операций перемещени€, копировани€ и клонировани€ даже из действующих систем (V2V). ѕоскольку программные ресурсы, определ€ющие виртуальную машину и управл€ющие ею, очень легко идентифицировать, то обычно не требуетс€ очень много усилий дл€ дублировани€ целых серверных сред в нескольких местах и дл€ разных целей.

»ногда это не сложнее, чем создать архив виртуальной файловой системы на одном хосте, распаковать его на другом хосте по тому же пути, проверить основные сетевые настройки и запустить. Ѕольшинство платформ предлагают единую операцию командной строки дл€ перемещени€ гостей между хостами.

ѕеремещение развертываний с физических серверов на виртуализированные среды (P2V) иногда может оказатьс€ немного сложнее. ƒаже создание клонированного образа простого физического сервера и его импорт в пустую виртуальную машину может сопровождатьс€ определенными трудност€ми. » как только все это будет выполнено, вам, возможно, придетс€ внести некоторые корректировки в системную архитектуру, чтобы можно было использовать возможности, предлагаемые виртуализацией, в полную силу. ¬ зависимости от операционной системы, которую вы перемещаете, вам также может потребоватьс€ использование паравиртуализированных драйверов дл€ того, чтобы ќ— могла корректно работать в своем «новом доме».

 ак и в любых других ситуаци€х управлени€ сервером: тщательно все продумывайте заранее.


—кидки 50% в Merion Academy

¬ыбрать курс