Я провел поиск и не нашел ничего, что решало бы проблемы с установкой исправлений и обновлениями системы. У меня есть инструкции, в которых говорится, что на серверах должны быть необходимые исправления. Если у меня есть виртуальная машина, то является ли это дополнительным уровнем для исправления и обновления - даже с гипервизорами без оболочки? В отличие от металлического сервера? (т.е. больше работы, тестирования и документации в соответствии с моими рекомендациями).
Как часто обновляются гипервизоры Type 1 / bare-metal? Это имеет значение? Привносит ли тот факт, что это дополнительный программный уровень больше сложности и риска (безопасность и надежность)? (например, 99% программного обеспечения без ошибок x 99% программного обеспечения без ошибок = 98% системы без ошибок)?
(Мой практический опыт связан с VMWare Workstation and Server и VirtualBox.)
Да, такие продукты, как VMware, иногда следует исправлять (обновления являются совокупный), но патчи выпускаются реже, чем в основной операционной системе, и потенциальный вектор атаки меньше - ваш гипервизор не должен быть общедоступным.
Я буду использовать VMware ESXi версии 5.0 (не 5.1) в качестве примера ...
ESXi 5.0 имеет следующий график обновлений:
С 9/2011 по настоящее время ДЕСЯТЬ обновления продукта ESXi 5.0. Из тех, ШЕСТЬ были включены обновления, ориентированные на безопасность, в пакеты обновлений с такими описаниями, как:
"Уязвимость парсинга трафика ESXi NFS" - CVE-2012-2448.
Эти уязвимости безопасности реальны, поскольку они иногда отражают общие ошибки безопасности Linux, но я думаю, что большинство организаций не очень восприимчивы к рискам. Однако оценить этот риск должен инженер. Хотели бы ваши пользователи массового простоя, чтобы исправить следующий эксплойт?
"Макрос encode_name в misc / mntent_r.c в библиотеке GNU C (также известной как glibc или libc6) 2.11.1 и ранее, используемый ncpmount и mount.cifs, неправильно обрабатывает символы новой строки в именах точек монтирования, что позволяет локальным пользователям чтобы вызвать отказ в обслуживании (повреждение mtab) или, возможно, изменить параметры монтирования и получить привилегии с помощью созданного запроса на монтирование ".
Может быть? Может быть нет.
я бегу Диспетчер обновлений VMware, но обычно обновляются только в том случае, если я столкнулся с ошибкой или мне потребовалось усовершенствовать функцию. При запуске в кластерной установке исправление выполняется легко без простоев работающих виртуальных машин. Если нет других серьезных причин, я буду стараться обновлять ежеквартально. Отдельным хостам потребуется полная перезагрузка, поскольку исправления доставляются в виде монолитных образов.
В качестве примечания: всякий раз, когда я наследую установку VMware ESXi или работаю в системе, которой обычно не управляю, я часто вижу запущенные хосты, у которых есть никогда были применены какие-либо исправления VMware. Это не правильно!! Но я понимаю, как администраторы могут совершить эту ошибку, когда системы будут готовы к работе.
Это довольно хороший вопрос, если вы новичок в виртуализации с «голыми железами». Такой подход требует иного мышления по сравнению с подходом, который вы можете использовать с гипервизорами, которые работают как служба / приложение поверх обычной ОС.
По моему опыту, будет справедливо сказать, что ESX и HyperV нуждаются в Меньше исправления в целом, чем в обычных операционных системах. это не означают, что они вообще не нуждаются в исправлении или что применение некоторых исправлений не будет полезно независимо от «необходимости», но это означает, что перерывы в работе ваших служб для исправления хоста должны быть менее частыми и больше под вашим контролем . Существует потенциальная угроза безопасности для ОС гипервизора, как и для любых других, и хотя вы можете минимизировать подверженность этому риску (например, доступ к управлению гипервизором только в изолированной VLAN, к которой логически невозможно получить доступ со скомпрометированного сервера) Было бы глупо делать вид, что никакого риска нет.
Итак, если у вас есть 4 невиртуальных сервера, скажем, и вы перемещаете их все на один и тот же отдельный виртуализированный хост, то да, вы увеличиваете количество сбоев, которые могут быть вызваны необходимостью исправления хост-системы (или решения проблема с оборудованием и т. д., если на то пошло).
Хотя я бы предположил, что вероятность возникновения этого риска составляет относительно низкий (я говорю о разнице между исправлением виртуального хоста и видом исправления, который требует перезапуска, который вам придется сделать с автономной системой тем не мение), никуда не деться от того, что влияние велико.
Так зачем же тогда это делать?
Истинное преимущество виртуализации заключается в возможности настроить более одного хоста и настроить хосты для совместной работы, позволяя перемещать гостей с одного хоста на другой в случае сбоя одного хоста или если вы хотите запланировать исправления на хост-системы.
Используя этот подход, мне удалось по очереди пропатчить 5 хостов ESX. без каких-либо сбоев к 40 виртуальным серверам, работающим поверх них. Это просто вопрос экономии на масштабе - как только у вас будет достаточно потенциальных виртуальных гостевых машин, чтобы было выгодно построить такую сложную настройку и управлять ею с помощью тех инструментов, которые @ewwhite упоминает в своем ответе, окупаемость за счет снижения рисков вы беспокоитесь о том, что прибывает очень быстро.
Виртуальный сервер потребует того же обслуживания и исправлений, что и физический сервер, гипервизоры на «голом железе» потребуют обновлений для безопасности, а также для исправления ошибок и повышения производительности. Чем больше у вас серверов, тем больше работы вам придется выполнять, чтобы поддерживать их в актуальном состоянии, неважно, физические они или виртуальные.
Основываясь на приведенных выше ответах, кажется, что виртуализация сервера привела к большей сложности и риску с точки зрения безопасности и надежности, но их необходимо сопоставить с преимуществами возможности сокращения времени простоя за счет виртуализации сервера.
Если ваша среда требует аудита, тестов и документации, рентабельность дополнительных рабочих нагрузок виртуализированной среды должна быть принята во внимание с количеством серверов и системного персонала, который у вас есть. В нашей среде у нас нет персонала / времени для ведения контрольного журнала для виртуализированной среды. В наших бизнес-процессах мы можем взять некоторое время простоя, но мы не можем упустить контрольный журнал и документацию.