KVM, виртуальные машины, контейнеры и выделенное оборудование описывают разные операционные границы. Выберите границу, необходимую вашему проекту, проверьте функции, предоставляемые предложением, и поддерживайте программное обеспечение в этой среде.
Виртуальная машина — это гостевая среда
Виртуальная машина представляет операционной системе виртуализированное оборудование, такое как процессоры, диски и сетевые интерфейсы. Физический хост запускает механизмы, делающие эти гостевые системы возможными. VPS — это хостинговый продукт, построенный вокруг виртуального сервера, с заявленным распределением ресурсов и операционной средой, которую может использовать клиент. Читайте распределение как часть предложения, а не представляйте физическую машину за каждым виртуальным CPU.
Выделенный сервер даёт проекту границу физической машины. Он может запускать одну операционную систему или размещать собственные виртуальные машины, когда оборудование и развёртывание поддерживают такой проект. Это меняет владение ресурсами и администрирование, но не устраняет уязвимости программного обеспечения, работу по обновлению или необходимость резервных копий. Выбирайте границу исходя из реального требования к изоляции или ёмкости.
KVM обозначает технологию виртуализации
KVM обеспечивает поддержку виртуализации в ядре Linux. QEMU предоставляет модель машины и может использовать KVM в качестве ускорителя виртуализации, а программное обеспечение управления, такое как libvirt, может организовывать конфигурацию и жизненный цикл гостя. Эти компоненты объясняют, как можно построить среду; буквы KVM не определяют планирование CPU, производительность хранилища или доступность услуги.
Документация по виртуализации иногда различает гипервизоры типа 1 и типа 2 по их отношению к хост-платформе. Для решения о хостинге метка менее полезна, чем знание границы гостя, ответственности за обслуживание и предоставляемого оборудования. Спросите, поддерживаются ли требуемая гостевая операционная система и драйверы. Функции, описанные программным проектом, не включаются автоматически в продукт каждого провайдера.
Не путайте управление гостем с управлением хостом
Доступ root или администратора внутри гостя позволяет управлять этим гостем. Он не даёт доступа к физическому гипервизору, другому арендатору или любой возможной функции хоста. Вложенная виртуализация, проброс устройств и специализированные сетевые настройки требуют явной поддержки. Не выбирайте VPS, предполагая, что возможность, доступная на вашем ноутбуке, будет предоставлена хостинговой средой идентично.
Сравните CPU, память, хранилище, сеть и лицензии фактического тарифа. Наблюдайте задержку и нагрузку на ресурсы вашего приложения с репрезентативной работой после поставки. Технология виртуализации может создавать полезную границу изоляции, при этом совместно используя базовые аппаратные ресурсы согласно политике провайдера. Ни метка гостя, ни метка выделенного сервера не заменяют измерений и полной операционной спецификации.
| Граница | Чем управляет проект | Возможность для проверки |
|---|---|---|
| Виртуальная машина | Гостевая ОС и её службы | Поддерживаемая ОС, драйверы и предоставляемые функции |
| Контейнер | Конфигурация процесса и образа | Функции ядра, ограничения и область монтирования |
| Выделенный сервер | Выбранная среда физической машины | Требования к оборудованию и виртуализации |
Контейнеры организуют процессы внутри среды
Контейнер обычно использует ядро своего хоста, группируя процессы и их ресурсы. Виртуальная машина запускает гостевое ядро. Вы можете запускать контейнеры внутри VPS, когда операционная система и среда выполнения поддерживают предполагаемую конфигурацию. Такое сочетание может упростить упаковку зависимостей, не заменяя обслуживание безопасности гостя или план восстановления.
Средства контроля ресурсов Docker требуют осознанных настроек: по умолчанию среда выполнения не устанавливает ограничения CPU и памяти для каждого контейнера. Ограничьте использование ресурсов и избегайте ненужных привилегий или монтирования хоста. Разделяйте рабочие нагрузки с разными требованиями к доверию, где это практично. Поддерживайте хост и образы в актуальном состоянии. Относитесь к образу контейнера как к программному обеспечению, которое необходимо проверять, а не как к автоматическому решению по безопасности из-за простоты запуска.
Оболочка — это интерпретатор, а не сам сервер
Терминал предоставляет поверхность взаимодействия; оболочка интерпретирует команды и запускает программы. В Linux Bash является распространённой оболочкой, тогда как другие оболочки предлагают иной синтаксис и интерактивные функции. Сценарий должен быть нацелен на ожидаемый им интерпретатор. Смена оболочки входа не меняет интерпретатор каждого приложения и не делает сценарий, написанный для другой оболочки, совместимым.
Ввод оболочки может подвергаться раскрытию, перенаправлению и подстановке команд до того, как программа получит свои аргументы. Понимайте эту обработку, прежде чем строить команды обслуживания из имён файлов или пользовательских данных. Держите недоверенный ввод вне исполняемого текста команд, правильно заключайте аргументы в кавычки и предпочитайте структурированный интерфейс программы для автоматизированной работы. История, журналы и аргументы процессов могут сохранять конфиденциальные значения, поэтому используйте механизм приватных учётных данных, подходящий для приложения.
Управляйте выбранной границей
После поставки определите гостевую ОС, маршрут доступа и механизм восстановления. Применяйте обновления, создайте ограниченную учётную запись администратора и предоставляйте только те службы, которые нужны проекту. Проверьте небольшое развёртывание перед передачей важных данных. Запишите среду выполнения, образы и конфигурацию, необходимые для его пересоздания; граница не говорит вам, восстановимо ли состояние приложения.
Используйте сравнение SwissOctet, чтобы составить список Vector, DeskLink или линейки Metal в соответствии с рабочей нагрузкой и операционной средой. Подтвердите специализированные возможности перед подготовкой заказа. Разделяйте работу с операционной системой, работу с приложением и работу провайдера в регламенте. Чёткая граница полезна, потому что говорит, что вы можете настроить и о чём должны спросить, сохраняя практический путь для миграции и восстановления.
Ваш практический чек-лист.
- Различайте гостевой доступ и доступ к хосту.
- Проверьте требования к специализированному оборудованию и виртуализации.
- Измеряйте полную конфигурацию, а не метку гипервизора.
- Настройте ограничения и разрешения контейнеров.
- Используйте предполагаемую оболочку и защищайте ввод команд.
Детали, которые важны.
Означает ли KVM, что я получаю выделенные физические ядра CPU?+
Нет. KVM обозначает технологию виртуализации. Читайте распределение CPU и политику ресурсов продукта отдельно.
Могут ли контейнеры заменить обслуживание гостя?+
Нет. Хостовая среда, среда выполнения контейнеров и образы — всё требует обслуживания, соответствующих разрешений и планирования восстановления.
Терминал и оболочка — это одно и то же?+
Нет. Терминал предоставляет интерфейс. Оболочка интерпретирует ввод команд и запускает программы в этом интерфейсе.
Перейдите к источнику.
Эти источники поддерживают технические концепции в этом руководстве. Следуйте актуальной документации, прежде чем менять производственную систему.
- Проект KVM: Kernel Virtual Machine www.linux-kvm.org
- QEMU: Введение в системную эмуляцию www.qemu.org
- Docker: ограничения ресурсов docs.docker.com
- GNU Bash: Раскрытия оболочки www.gnu.org
Редакционное руководство от SwissOctet. Примеры иллюстративны. Спецификации услуг, доступные опции и договорные условия необходимо проверять отдельно.