Виртуализация нового типа

Но, как это обычно бывает с программами и программистами, при практическом применении компьютеров через несколько лет выяснилось, что производительности программного гипервизора и программной виртуализации не хватает. Тогда в IBM решили включить поддержку виртуализации в аппаратную архитектуру своего следующего семейства компьютеров – IBM Systems 370, и сделали это. Основными «фишками» этого семейства стали ОС VM/370 (монитор виртуальных машин), расширенный режим работы архитектуры 370-XA со специальными аппаратными средствами, обеспечивающими перехват и эмуляцию выполнения команд, и особый режим работы процессора (interpretive execution), в котором он мог передавать эмулятору команды из определённого «небезопасного» набора. То есть если процессор, выполняя инструкции, доходил до команды, необдуманное исполнение которой могло деструктивно повлиять на все его виртуальные ресурсы (например, прямое обращение к памяти или устройствам ввода-вывода), он передавал её исполнение специальному эмулятору, понимающему, как эту команду правильно выполнить в виртуальной среде. После исполнения команды и возвращения управления процессор продолжал свою работу в обычном режиме. Такой алгоритм работы обеспечивал гостевым системам на System 370 «безопасность» и изоляцию друг от друга значительно более эффективно и с меньшей потерей производительности на виртуализацию. На этом и следующих поколениях виртуальных систем IBM VM были отработаны принципы и технологии, до сих пор определяющие современные архитектуры решений по виртуализации.

Прогресс не стоял на месте – согласно закону Мура, росли производительность и вычислительная мощность на тот же объём единичного процессора. К середине 1980-х компьютеры «открытой» архитектуры, уже ставшие к тому времени прогрессивно «персональными» (что как раз и означало отсутствие необходимости делиться аппаратными мощностями), планомерно захватывали рынок вычислений. Дело в том, что произвести расчёты за соизмеримое время стало возможно не только на «мейнфреймах» и «мини-компьютерах» (да ещё и существенно сэкономить при этом).

Дальше – больше. С ежегодным приростом мощности новых поколений процессоров персональных компьютеров история пошла на «второй круг», и в начале XXI века уже и эта мощность стала избыточной. Теперь потребители задумались о том, как бы на «открытой» x86 платформе получить возможности для изоляции операционных и прикладных систем друг от друга. В этот момент «открытость» платформы x86 сыграла с ней злую шутку. За время её существования сотнями и тысячами программистов были написаны миллионы строк самого разного кода, включая системные драйверы для подключения внешних устройств. И ни в одной из этих строк не учитывалась возможность работы не в «монопольном» режиме – когда в распоряжение программы передаётся весь аппаратный ресурс. В этот момент были подняты наработки конца 60-х гг. и так же, как и тогда, появились первые программные системы виртуализации для x86-й архитектуры. До появления процессоров AMD и Intel с аппаратной поддержкой виртуализации (2005–2006 гг.) оставалось ещё 5 лет…

Попытка только с помощью программных средств решить проблему «архитектурной недостаточности» процессора заведомо обречена на провал. Недостатки и ошибки прикладного ПО сразу сводят «на нет» производительность и надежность аппаратной процессорной архитектуры. Если вы смотрели последний фильм «Годзилла», то сразу поймёте, о чём речь. Там Годзилла неожиданно помогает отчаявшимся людям в борьбе с гигантскими доисторическими монстрами. В результате монстры повержены, при этом полностью разрушены 5 или 6 городов, а человечеству нанесена глубочайшая психологическая травма. Это те же проблемы, которые преследовали пользователей ранних систем программной x86 виртуализации: обычно они сами содержали критическое количество «багов» и ограничений, что не позволяло серьёзно рассматривать их в качестве промышленных решений. Одним словом, нужна была «Годзилла» – помощник из «доисторического периода», переводящий на принципиально новый уровень развитие виртуализации в ИТ. В конце того фильма Годзилла погружается на океанское дно, показывая, что она всегда где-то рядом, и оставляет людей гадать, когда и зачем она снова неожиданно вынырнет на поверхность.

Рис. 1. Изменение характеристик процессоров

 

Немного теории заговора, или «Обет молчания»

 

Была ещё одна причина, которая коренным образом повлияла на развитие виртуализации и её сегодняшнее состояние именно в тот период, – это вынужденная смена концепции у производителей процессоров x86 платформы. Дело в том, что за последние 10 лет в области производства процессоров никаких революций, за исключением маркетинговых, не произошло. В 2001–2003 гг. ключевая для производительности ядра процессора характеристика «тактовой частоты» практически перестала изменяться (на рис. 1 это хорошо видно). Если сравнить, для примера, интервалы 1994–1998 и 2007–2011 гг., то за первый промежуток максимальная тактовая частота (CPU) выросла на ~300%, а за второй только на ~33%. На практике для потребителя это означало, что новый процессор или сервер больше не мог автоматически резко повысить производительность прикладной системы.

 

Чтобы компенсировать этот технологический порог, обусловленный тепловыделением кристалла, новые поколения процессоров стали делать многоядерными. Можно описать этот факт иначе: когда производительности типового сервера перестало хватать, одни инженеры и программисты задумались над задачей объединения нескольких физических процессоров в один «виртуальный составной процессор» для повышения общей мощности и построения этакого «суперсервера» по аналогии с Hi-End-оборудованием IBM, SUN, HP, Fujitsu и т.д. Но пока они думали и пробовали, другие инженеры и производители процессоров решили эту задачу наиболее выгодным для себя образом – они объединили несколько вычислительных ядер на одном кристалле.

 

Сам факт многоядерности ни в коем случае не гарантирует приложению кратный количеству ядер рост производительности. Для этого необходимо специальным образом переписать приложение. Поэтому неудивительно, что вскоре после достижения «точки перелома» роста производительности одного ядра ЦПУ и вынужденного перехода к парадигме «многоядерности» для действительно эффективного использования ЦПУ потребовалось нечто большее, чем увеличение количества ядер на кристалл, объёма кэша и т.д.

Трудоустройство виртуализации

Мощности процессоров продолжали расти, желание применять их виртуализацию в производстве – тоже. И вот, повторяя опыт своих предшественников из IBM (System 370), компании AMD и Intel практически одновременно (2005–2006 гг.) выпускают очередные версии своих процессоров x86 архитектуры с системой команд, поддерживающей виртуализацию. Это AMD V и Intel VT, которые, как это принято в «открытых системах», были идеологически и функционально схожи, но абсолютно несовместимы между собой. Сегодняшние версии x86 процессоров и их аппаратная поддержка виртуализации являются развитием тех систем, а все современные платформы виртуализации получили мощный толчок в развитии: стало возможно их внедрять и применять для решения критичных задач.

Не буду подробно останавливаться на деталях виртуализации «наших дней», об этом за последние годы очень много написано и рассказано в презентациях, напомню лишь основные места её предпочтительного «трудоустройства». Основные сферы применения виртуализации:

• Консолидация ресурсов для:
  • повышения средней загрузки оборудования («КПД» сервера);
  • упрощения миграции устаревших ИС на новое оборудование;
  • организации гибких сред тестирования и разработки;
  • возможности одновременного запуска, «смешивания» разных ОС на одной аппаратной платформе.
• Сфера информационной безопасности:
  • возможности назначения своих правил и политик для каждой ВМ;
  • построение контролируемой «песочницы» (Sandbox) для обнаружения и предотвращения атак.
• Повышение надёжности:
  • «живая миграция» – перемещение ВМ с одного сервера на другой без прерывания сервиса;
  • изоляция ошибок прикладного ПО в рамках своей виртуальной машины;
  • быстрое создание резервных ВМ для «поднятия» сервиса.

Назад – в будущее

Что нового нас ждёт в вопросах внедрения и применения виртуализации в современных ЦОД и в ЦОД ближайшего будущего? Какие новые направления развития и архитектуры для построения платформ виртуализации существуют? Небольшой опрос наших лучших практиков позволил сформировать простой перечень характеристик, которыми должен обладать элемент платформы виртуализации. Попробуйте задать этот вопрос своим специалистам, не думаю, что будут сколько-нибудь значимые расхождения в ответах.

В основном все называли таким элементом сервер:

• «Типовой, максимально унифицированный с другими аналогичными компонентами»
• «Достаточно мощный для запуска 10–20 производственных ВМ»
• «2–4 ЦПУ максимум»
• «Около 128 ГБ ОЗУ»
• «Дисковая емкость, в среднем – 60–80 Гб на машину»
• «Поменьше бы разнообразных управляющих консолей»
• Снова «типовой, максимально унифицированный для высокой скорости разворачивания и простого масштабирования платформы виртуализации»

Конечно, не бывает универсального лекарства, одновременно эффективно помогающего разным частям тела, но общим ответом на эти пожелания практиков является динамично раскручиваемый последнее время тренд «гиперконвергенции». Термин описывает такую архитектуру платформы виртуализации, при которой она строится из совершенно однотипных, предварительно специально настроенных «строительных» блоков HCIA – Hyper-Converged Infrastructure Appliance (обычно – низкопрофильный сервер с внутренними дисками). Производятся и предварительно настраиваются эти блоки производителем платформы виртуализации или компаниями, занимающимися её «глубоким тюнингом». Для примера назовем решения VMware Evo:Rail, Nutanix, SimpliVity OmniCube, Scale HC3.

Рис. 2. Hyper-Converged Infrastructure Appliance

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

Из перечисленных решений можно отметить продукт SimpliVity OmniCube, в каждом «строительном блоке» которого установлена FPGA-плата, обеспечивающая дедупликацию «на лету» данных, записываемых на общую СХД. Необходимо выделить Evo:Rail как собственный программно-аппаратный продукт компании VMware, «держащей» 60% рынка виртуализации в мире, что не позволяет легкомысленно отнестись к этой разработке и показывает направление мысли её архитекторов.

Для работы всех перечисленных решений (пожалуй, кроме Scale) необходимы SSD-диски. Флэш-память применяется для увеличения производительности подсистемы ввода-вывода, хотя алгоритмы её использования могут быть разными. Все продукты требуют подключения по 10G Ethernet и могут подключать внешние сетевые тома с сетевых «файлеров».

Таким образом, виртуализация и Software-Defined Data Center Solution постепенно приводят нас к мысли, что всё это сильно напоминает самое начало пути – 60-70-е годы. Только теперь тогдашний «мейнфрейм» не представлен в виде шасси, в его качестве выступает вся серверная комната.

Дальнейшим развитием этого тренда видится включение в состав таких программно-аппаратных конвергентных решений комплексов контроля и управления инженерными системами серверных помещений, климатикой, локальными и распределёнными «кластерами», «мейнфреймами» нового типа.