Запуск контейнеров и виртуальных машин в одном «голом железе»

МИТЧ: Берни, я до сих пор помню, когда виртуальные машины начали заменять физические серверы для локальных рабочих нагрузок. Затем виртуальные машины переместились в облако с помощью IaaS, и организациям пришлось решать, использовать ли общедоступное облако, частное облако или и то, и другое — гибридный подход. Эта борьба, кажется, несколько улеглась, но затем появилась эта новая вещь, называемая контейнерами, и все были взволнованы тем, что они заменят виртуальные машины. Произошло ли это, или контейнеры и виртуальные машины все еще живы для облачных вычислений? И останутся ли они оба таковыми в обозримом будущем?

БЕРНИ: На мой взгляд, основная причина внедрения контейнеров и Kubernetes заключается в том, что они абстрагируют проблемы масштабирования на уровне облака от разработчиков и позволяют легко внедрять архитектуры микросервисов. Следовательно, он идеально подходит для облачных приложений. Основная причина внедрения виртуальных машин заключалась в том, чтобы позволить традиционным приложениям стать более переносимыми и обеспечить возможность консолидации и миграции нескольких серверов приложений на меньшее количество физических серверов для увеличения использования. Когда облачные вычисления стали жизнеспособными, переносимость этих приложений упростила их миграцию в облако и позволила использовать модель операционных расходов для потребления ИТ. В дальнейшем я считаю, что большинство новых или обновленных приложений будут использовать облачный контейнерный подход, но устаревшие приложения на основе виртуальных машин будут продолжать работать неопределенно долго.

МИТЧ: Сложно ли реализовать решение, сочетающее контейнеры и виртуальные машины в одной инфраструктуре? Некоторые администраторы, с которыми я разговаривал, похоже, борются с этим. Почему это? О каких трудностях или проблемах идет речь?

БЕРНИ: Действительно, администраторам, которые плохо знакомы с Kubernetes, может быть сложно работать с обоими одновременно. Виртуальные машины и контейнеры управляются по разным парадигмам. Образы контейнеров создаются способом, очень похожим на то, как вы компилируете приложение в один двоичный файл, за исключением того, что вы также упаковываете ОС. Вы просто говорите Kubernetes, какой образ использовать, и он выходит, извлекает образ и выполняет его. Как администратор, вы больше ничего не устанавливаете. Это важное отличие затрудняет создание сценариев развертывания для гибридного приложения, поскольку такие инструменты, как Ansible, сейчас менее полезны.

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

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

МИТЧ: Ваша компания MetalSoft предлагает предприятиям облачное решение на «голом железе». В чем преимущество этого перед более традиционным подходом к запуску виртуальных машин и контейнеров в общедоступном облаке IaaS?

БЕРНИ: MetalSoft значительно улучшает автоматизацию развертывания, выделения ресурсов и управления жизненным циклом всей пустой инфраструктуры центра обработки данных (серверы, коммутаторы и системы хранения). Автоматизация этого уровня аппаратной инфраструктуры исторически была разрозненной и запутанной, со скрытыми затратами и чувствительностью к дрейфу конфигурации. Поскольку MetalSoft не зависит от платформы оборудования и приложений, компании и их партнеры-поставщики облачных услуг могут захотеть рассмотреть возможность создания своей ИТ-инфраструктуры на такой основе, чтобы повысить уровень автоматизации и устойчивость к цифровым преобразованиям.

MetalSoft также позволяет управлять этой инфраструктурой и использовать ее, как если бы она использовала виртуальное частное облако с самообслуживанием. В рамках этого опыта рабочий процесс и шаблоны подготовки MetalSoft могут обеспечить развертывание по требованию таких приложений, как VMware и Kubernetes. Это делает развертывание и запуск приложений в частном или гибридном облаке локально или на объектах совместного размещения более экономичным и отказоустойчивым. Наконец, легковесные агенты можно развернуть для удаленного управления инфраструктурой, расположенной на периферии или в необслуживаемых областях.

Пользователи также могут ожидать повышения производительности в результате работы на серверах без ПО и в сетях без ПО. Прямая координация MetalSoft коммутаторов TOR для настройки собственных VLAN L2 или L3, изолированных от арендаторов, может уменьшить задержки и обеспечить более высокий уровень безопасности и изоляцию от шумных соседей. Другая инфраструктура может ухудшиться из-за чрезмерной виртуализации серверного и сетевого уровней.

МИТЧ: Могут ли компании, которым нужно гибридное решение, легко комбинировать локальную среду с «голым» облаком?

БЕРНИ: Платформа MetalSoft для «голого железа» может самостоятельно масштабироваться для управления «голыми» облаками, расположенными локально, на периферии (например, в микроцентрах обработки данных) или работающими на CSP в рамках гибридной или многооблачной стратегии.. Используя Kubernetes в качестве уровня переносимости, компании могут перемещать приложения между собственными частными и общедоступными облаками, чтобы воспользоваться преимуществами наилучшего соотношения производительности и затрат или локальности данных. Сторонняя многооблачная или гибридная платформа может использоваться вместе с MetalSoft для оптимизации размещения приложений, если публичные облака являются частью общего решения. MetalSoft также поддерживает возможности автоматизации рабочих процессов и интеграции инфраструктуры как кода (IaC) с использованием Terraform и Ansible.

МИТЧ: Есть ли у облачного решения на «голом железе» какие-либо преимущества по стоимости по сравнению с использованием облачных сервисов, таких как AWS или Azure?

БЕРНИ: Да, «голое железо» MetalSoft не только обеспечивает преимущества в производительности и отказоустойчивости, но и обеспечивает более низкие затраты по сравнению с общедоступными облачными сервисами. По сравнению с публичными облаками среднее предполагаемое улучшение совокупной стоимости владения составляет 4 раза. Более подробный анализ затрат можно получить по запросу в MetalSoft.

МИТЧ: Что еще вы хотели бы добавить?

БЕРНИ: Хотя поставщики публичных облаков также предлагают «голые» облака, доступность платформы автоматизации «голого железа» MetalSoft предоставляет новую альтернативу для предоставления многопользовательского варианта самообслуживания, который найдут предприятия, поставщики SaaS и поставщики облачных услуг. быть всеобъемлющим, производительным и экономичным для запуска всех приложений. Платформа MetalSoft проверена в производстве и сертифицирована по стандарту ISO более восьми лет по всей Европе как облачное решение для дочерней компании BigStep.

МИТЧ: Спасибо, Берни, что нашел время, чтобы объяснить нам все это.

БЕРНИ: Не за что.