Назад | Перейти на главную страницу

Почему бы вам использовать Xen вместо OpenVZ для доверенного хоста / гостей только для Linux?

Каждый раз, когда мне нужно создать VPS на одной из наших машин, я (пере) думаю о технологиях виртуализации и, кажется, в конечном итоге считаю, что OpenVZ является наиболее подходящим с точки зрения производительности, когда все, что мне нужно, - это четкое разделение между VPS. Все работает под GNU / Linux.

У меня есть вопрос, когда для сценария со следующими фактами целесообразнее переходить на Xen? Вот ситуационные факты:

Обычно меня устраивает мое решение перейти на OpenVZ, но я продолжаю читать об известных инженерах, использующих Xen в сценариях, которые, как мне кажется, очень похожи на мои, Github будучи один пример.

Контейнеры OpenVZ имеют очень низкие накладные расходы и ими легко управлять с хоста. Однако главные недостатки OpenVZ - отказоустойчивость и гибкость.

Код, работающий внутри контейнера OpenVZ, может вызвать панику ядра, которая приведет к сбою всего узла. Если вы разрешите контейнерам действовать как клиенты NFS, зависание NFS может привести к остановке всей системы.

Контейнеры OpenVZ должны запускать ту же версию ядра, что и хост. Они не могут вставлять модули ядра. Кроме того, они могут использовать только те функции Linux, которые были виртуализированы OpenVZ, поэтому вы не можете использовать autofs, например (по состоянию на 2013 год).

Если вы знаете, что можете жить с этими ограничениями, непременно попробуйте OpenVZ. Если не получится, перейти на полноценное решение виртуализации не так уж и сложно. (Схема процесса такова: создать образ диска, смонтировать его с обратной связью, установить ядро, повторно включить некоторые записи inittab.)

Вы можете доверять люди кто будет администрировать и использовать VPS, но можете ли вы доверять программное обеспечение? Если гостевая система выйдет из строя, может произойти сбой всего узла. Если гостевая система уязвима, то под угрозой оказывается весь узел.

Конечно, любой гипервизор также является частью программного обеспечения, поэтому он подвержен ошибкам и уязвимостям, но с меньшей поверхностью атаки и более сильной изоляцией, чем контейнерная технология.