Изменения в Windows Server 2012 для «облачных» решений

Джон Сэвилл (jsavill@windowsitpro.com) — директор по технической инфраструктуре компании Geniant, имеет сертификаты CISSP, Security and Messaging MCSE для Windows Server 2003 и звание MVP

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

Учитывая это, разработчики Windows Server реализовали в данной операционной системе целый ряд новых технологий. Последние обеспечивают системам Windows Server и виртуальным средам возможность соответствовать самым разнообразным требованиям и выполнять множество различных сценариев, включая работу как в частных, так и в общедоступных «облачных» средах. Нередко сценарии такого типа предполагают использование единой инфраструктуры, разделяемой различными бизнес-подразделениями или даже организациями. Напомню, что операционная система Windows Server 2012 (первоначальное название — Server 8) оптимизирована для использования «облачных» решений. Вы убедитесь в этом, когда я перейду к описанию технологий, предназначенных исключительно для обслуживания сетей: в версии Server 8 практически все стороны этой деятельности в той или иной мере подверглись модернизации.

В предлагаемой статье при рассмотрении реализованных в операционной системе Server 8 сетевых функций Hyper-V упор будет делаться на следующие три области:

— виртуализация сетей;

— расширяемость виртуального коммутатора Hyper-V;

— усовершенствования, обеспечивающие совместимость с новыми сетевыми аппаратными компонентами и стандартами качества обслуживания (Quality of Service, QoS).

К числу других замечательных возможностей следует отнести новое решение для работы с сетями VPN, включающими компоненты с разных сайтов; коренную переработку протокола Server Message Block (SMB), который обеспечивает выполнение виртуальных машин с файлового ресурса Server 8; поддержку совместной работы для сетевых плат, а также средства для единообразного именования устройств. Но основное внимание я хотел бы уделить важнейшим сетевым технологиям, которые играют определяющую роль в обеспечении процесса виртуализации.

Виртуализация сетей

Виртуализация всегда опиралась на средства абстрагирования одного уровня ресурса от другого, что обеспечивает дополнительную функциональность и переносимость. Но в сетевых технологиях подобная цель не ставилась, и потому виртуальные машины остаются «привязанными» к сетевым настройкам хоста, на которых они выполняются. С помощью средств для работы с логическими сетями диспетчер виртуальных машин Microsoft System Center Virtual Machine Manager (VMM) 2012 осуществляет привязку виртуальных машин к физическим сетям; в результате администраторы могут создавать логические сети, обеспечивающие разработку продуктов, их производство и резервное копирование. Это позволяет создавать IP-подсети, а также виртуальные локальные сети для каждого физического объекта, имеющего связь с той или иной логической сетью. Эти средства дают возможность создавать виртуальные машины, автоматически устанавливающие соединение, скажем, с производственной сетью; в зависимости от фактического местонахождения производственного помещения, где развертывается соответствующая виртуальная машина, диспетчер виртуальных машин определяет коммутатор Hyper-V, который необходимо использовать, а также IP-схему и тег виртуальной локальной сети.

Эта возможность заслуживает самой высокой оценки. Но она не решает проблему в ситуациях, когда я, скажем, предоставляю хостинг для нескольких потребителей, каждому из которых требуются свои схемы IP-адресации, или даже для одного клиента, которому необходимо перемещать виртуальные машины из одного офиса в другой или из частного «облака» в общедоступное и обратно (причем не изменяя IP-адресов и политик, управляющих работой соответствующей сети). Как правило, поставщики услуг размещения в общедоступном «облаке» требуют, чтобы клиенты использовали хостируемую IP-схему, что необходимо для обеспечения гибкого перехода с локальных серверов на «облачные» и обратно.

В обоих упомянутых случаях необходимо, чтобы сеть была виртуализована; при этом данная сеть должна «знать», что может полностью распоряжаться высокоскоростной коммуникационной системой network fabric — подобно тому, как виртуальная машина «убеждена», что является полноправной хозяйкой аппаратных компонентов, на которых она выполняется. Одни виртуальные машины «не видят» другие; подобным же образом виртуальные сети не должны проявлять интерес к работе других виртуальных сетей, относящихся к той же коммуникационной системе, даже если их IP-схемы «накладываются» друг на друга. Изоляция сетей — важнейший компонент процесса их виртуализации, особенно когда речь идет о размещении сетей в среде стороннего подрядчика. Если я размещаю сети компаний Pepsi и Coca-Cola внутри одной и той же физической инфраструктуры, я должен быть на сто процентов уверен, что представители одной фирмы не будут видеть виртуальную сеть другой. Их сети должны быть полностью изолированы.

Эта функция управления виртуальными сетями обеспечивается благодаря присвоению каждой виртуальной машине двух IP-адресов, а также за счет использования идентификатора виртуальной подсети, указывающего на виртуальную сеть, которой принадлежит та или иная виртуальная машина. Первый IP-адрес представляет собой стандартный адрес, настроенный внутри виртуальной машины; в соответствии с терминологией IEEE он называется адресом клиента (customer address). Второй IP-адрес — это адрес, который виртуальная машина использует для связи с другими объектами физической сети; его называют адресом провайдера (provider address).

В примере на рисунке 1 представлена одна физическая инфраструктура. На ее основе функционируют две отдельные организации: красная и синяя. Каждая организация обладает своей схемой IP-адресации (эти схемы могут накладываться друг на друга), а виртуальные сети могут включать в себя несколько физических объектов. Каждая виртуальная машина входит в состав виртуальной красной или синей сети и имеет собственный клиентский адрес. Для пропускания фактического IP-трафика по каналам физической инфраструктуры используется особый адрес провайдера.

Рисунок 1. Пример виртуальной сети

Вы можете убедиться, что рассматриваемая физическая инфраструктура обладает сетевыми и вычислительными ресурсами и что функционирующие в ней виртуальные машины включают в себя компоненты, располагающиеся на различных хостах и узлах. Цвет каждой виртуальной машины соответствует цвету ее виртуальной сети (красный или синий). Но даже при том, что виртуальные машины распределены по различным хостам и офисам, соответствующие хосты виртуальных сетей полностью изолированы от других виртуальных сетей с их собственными IP-схемами.

Виртуализация в системе Server 8 осуществляется благодаря применению двух технологий — переопределения IP-адресов и протокола туннелирования сетевых пакетов Generic Routing Encapsulation (GRE). Оба решения позволяют полностью разделенным виртуальным сетям с собственными схемами IP-адресации (которые могут частично совпадать) выполняться на базе одной разделяемой инфраструктуры.

Переопределение IP-адресов. Первый вариант — это метод переопределения IP-адресов, суть которого раскрывается в его названии. Каждая виртуальная машина имеет два IP-адреса: адрес клиента, задаваемый внутри виртуальной машины, а также адрес провайдера, применяемый для перемещения реальных пакетов данных по сетевым каналам. Коммутатор Hyper-V анализирует трафик, инициируемый виртуальной машиной, просматривает идентификатор виртуальной подсети с целью идентификации нужной виртуальной сети и переопределяет исходный и целевой параметры IP-адреса, заменяя адреса клиентов на соответствующие адреса поставщиков. При таком подходе необходимо извлекать из пула адресов провайдера большое число IP-адресов, для каждой виртуальной машины требуется свой адрес провайдера. Радует то, что, поскольку IP-пакеты не подвергаются изменениям (если не считать переопределения адресов), факторы аппаратной разгрузки, такие, как очередь виртуальной машины virtual machine queue (VMQ), контрольная сумма и масштабирование на стороне приема receive-side scaling (RSS) остаются неизменными. Метод переопределения IP-адресов характеризуется весьма небольшими накладными расходами и обеспечивает очень высокое быстродействие.

На рисунке 2 представлен процесс переопределения IP-адресов, а также таблица сопоставления, которую ведет хост Hyper-V. Этот хост фиксирует соответствия между адресами клиентов и поставщиков, каждый из которых уникален для каждой виртуальной машины. Исходный и целевой IP-адреса исходящего пакета изменяются, когда данный пакет передается в сеть через коммутатор Hyper-V. Стрелками на рисунке отмечен поток IP-трафика.

Рисунок 2. Процесс переопределения IP-адресов

GRE. Второй метод сводится к использованию протокола GRE — стандарта, разработанного комитетом Internet Engineering Task Force (IETF). Протокол помещает отправляемый пакет с присвоенным ему клиентским адресом внутрь другого пакета, который можно пересылать по физической сети с использованием адреса провайдера и который включает в себя идентификатор фактической виртуальной подсети. Поскольку идентификатор виртуальной подсети входит в состав пакета-оболочки, виртуальные машины могут обрабатывать его, не обращая внимания на отсутствие собственных адресов провайдера. Принимающий пакет хост может выявить целевую виртуальную машину с помощью клиентского адреса, содержащегося в исходящем пакете, а также идентификатора виртуальной подсети, помещенного в пакет-оболочку. Хосту Hyper-V на исходной виртуальной машине необходимо знать только одно: на каком хосте Hyper-V выполняется целевая виртуальная машина; этих сведений достаточно для того, чтобы выпустить пакет в сеть.

При использовании разделяемых адресов провайдера потребность в получении IP-адресов из пула IP-поставщиков резко сокращается. Это плюс — в том, что касается проблем управления IP-адресами и функционирования сетевой инфраструктуры. Но есть здесь и минус (по крайней мере, на данный момент). Поскольку исходящие пакеты инкапсулируются в пакеты GRE, ни один механизм разгрузки сетевых адаптеров, NIC offloading, не срабатывает. Система не распознает новый формат пакетов. К счастью, многие крупные производители аппаратных компонентов оснащают свои сетевые продукты средствами для работы с протоколом GRE, чтобы обеспечить функционирование механизмов разгрузки и в случае применения этого протокола.

На рисунке 3 представлен процесс туннелирования сетевых пакетов. Хост Hyper-V, как и прежде, фиксирует соответствия между клиентскими адресами и адресами поставщиков, но в данном случае адрес провайдера предоставляется через виртуальный коммутатор хоста Hyper-V. Исходный пакет не претерпевает каких-либо изменений. Вместо этого в процессе прохождения через коммутатор Hyper-V он помещается в пакет GRE, который наряду с идентификатором виртуальной подсети включает корректные адреса исходного и целевого провайдера.

Рисунок 3. Протокол GRE

Обе технологии предусматривают применение политик виртуализации ко всем хостам Hyper-V, участвующим в работе той или иной виртуальной сети. Эти политики позволяют передавать клиентские адреса по физическим каналам связи и отслеживать соответствие адресов клиентов и поставщиков. Кроме того, политики виртуализации позволяют определять виртуальные сети, которым разрешено вступать во взаимодействие с другими виртуальными сетями. Политики виртуализации можно настраивать с помощью оболочки Windows PowerShell, широко применяемой при работе в среде Server 8. Кстати говоря, в этом нет ничего удивительного: только представьте масштабы задач, решаемых в процессе управления сетями, а также уровень автоматизации — и вам станет ясно, что возможности ныне применяемого графического интерфейса пользователя явно недостаточны. Основная проблема, возникающая при использовании собственных команд PowerShell, состоит в организации синхронной оркестрации конфигурации виртуальных сетей по всем участвующим в процессе хостам Hyper-V.

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

Расширяемый виртуальный коммутатор Hyper-V

Клиенты часто заявляют, что хотели бы получить возможность добавлять к функциям коммутатора Hyper-V новые функции — скажем, усовершенствованные средства фильтрации пакетов, брандмауэр и возможности выявления вторжений на уровне коммутатора, перенаправление коммутаторов, а также утилиты для анализа передаваемых по сети пакетов. Система Windows уже наделена богатыми возможностями для работы с API, а также интерфейсами, в частности, фильтрами-драйверами спецификации network device interface specification (NDIS) и подключаемыми драйверами Windows Filtering Platform (WFP), которые позволяют сторонним провайдерам интегрировать свои изделия с операционной системой. В расширяемом коммутаторе Hyper-V используются те же интерфейсы, что уже применяют партнеры, и это позволяет провайдерам адаптировать свои решения для непосредственной интеграции в расширяемый коммутатор Server 8 Hyper-V. Как показано в таблице, существует четыре специальных типа расширений для коммутатора Hyper-V.

Отметим, что эти расширения не могут полностью заменять коммутатор Hyper-V. Они дополняют его, позволяя организациям точно определять уровни дополнительных функциональных возможностей, которые необходимы в данной среде, но не требуют полной замены коммутатора. Поскольку эти расширения реализованы внутри коммутатора Hyper-V, дополнительные возможности применимы ко всему трафику, включая трафик «виртуальная машина-виртуальная машина» в рамках одного хоста Hyper-V, а также трафик, осуществляемый по физической инфраструктуре сети. Упомянутые расширения обладают всеми средствами для осуществления динамической миграции. Ими можно управлять с помощью графических инструментов, сценариев Windows Management Instrumentation (WMI), а также команд PowerShell; для этого нужно только, чтобы во всех расширениях и функциях Hyper-V были реализованы унифицированные средства управления. Расширения для коммутатора Hyper-V можно сертифицировать в соответствии с программой сертификации Windows 8, что будет способствовать достижению ожидаемого уровня качества.

Максимальная отдача от аппаратных средств

Эффект от усовершенствования программных компонентов имеет свои границы. На каком-то этапе для реализации новых возможностей и достижения более высоких уровней производительности вам придется устанавливать новые аппаратные компоненты. К счастью, за последние годы сетевые средства многих аппаратных компонентов были усовершенствованы, особенно в диапазоне 10 Гбайт. Если вы эксплуатируете системы Server 8, то сможете воспользоваться новыми возможностями, установив в своей сети оборудование стандарта 10Gb Ethernet.

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

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

Этот программный метод обеспечения качества обслуживания функционирует на уровне порта виртуального коммутатора. Но наряду с ним имеется и аппаратный метод обеспечения качества обслуживания. Он базируется на использовании новой технологии Data Center Bridging (DCB), реализованной сегодня во многих сетевых инфраструктурах. Технология DCB позволяет классифицировать весь сетевой трафик, проходящий через физический сетевой адаптер (данные могут поступать как с хоста Hyper-V, так и с виртуальной машины). В системе Server 8 трафик может быть разделен на восемь типов по определенным признакам. К примеру, в один поток можно направлять трафик iSCSI, другой зарезервировать для SMB, а третий — для общего трафика IP. Для каждого потока технология DCB может выделять определенную полосу пропускания так, чтобы ни один из типов трафика не мог претендовать на всю имеющуюся полосу.

При сравнении программного способа обеспечения качества обслуживания с аппаратным способом на базе технологии DCB обнаруживается основное различие между ними: если программный способ осуществляется на уровне виртуальной машины и действует через коммутатор Hyper-V, то аппаратный метод обеспечения качества обслуживания никак не соотносится с виртуальными машинами и распространяется на все типы трафика, проходящего по каналам сети. Поэтому аппаратные средства обеспечения качества обслуживания гарантируют поддержание заданных уровней обслуживания для различных типов трафика во всей системе.

Виртуализация ввода-вывода на базе одного адаптера. Еще одно замечательное усовершенствование, основанное на последних достижениях в разработке сетевых плат — это виртуализация ввода-вывода на базе одного адаптера Single Root I/O Virtualization (SR-IOV). При использовании данной технологии одно сетевое устройство PCI Express может в процессе взаимодействия с виртуальными машинами выдавать себя за несколько устройств. Это означает, что физический сетевой адаптер может представлять несколько виртуальных сетевых адаптеров, которые в терминологии SR-IOV именуются виртуальными функциями virtual function (VF). Каждая функция VF принадлежит тому же типу, что и физическая плата и напрямую представляется заданным виртуальным машинам. В этих условиях коммутатор Hyper-V никоим образом не вовлекается во взаимодействие между виртуальной машиной и функцией VF, поскольку для организации совместной с VF работы виртуальная машина использует прямой доступ к памяти Direct Memory Access (DMA). Поэтому взаимодействие между виртуальной машиной и VF отличается очень малыми задержками. Как показано на рисунке 4, в сетевой поток данных, перемещаемых от физического сетевого адаптера до виртуальной машины, не вовлечены ни шина VM, ни коммутатор Hyper-V. Поскольку коммутатор Hyper-V не участвует в этом процессе, ни одна из функций, реализуемых через виртуальный коммутатор (таких, как коммутирование, проверка списков управления доступом, обеспечение качества обслуживания, служба DHCP Guard и расширения от сторонних производителей), к трафику, осуществляемому на базе технологии SR-IOV, уже не применяется, в результате чего повышается быстродействие сети.

В традиционных сетях на базе Hyper-V все передаваемые пакеты проходят между физическим сетевым адаптером и виртуальной машиной через виртуальный коммутатор Hyper-V Layer 2. В случае применения технологии SR-IOV виртуальный коммутатор исключается из данного процесса, как показано на рисунке 4.

Рисунок 4. Поток трафика в традиционной сети на базе средства виртуализации Hyper-V и в сети с ?использованием технологии SR-IOV

Впервые услышав о технологии SR-IOV, я подумал: «Весь смысл виртуализации в том, чтобы абстрагировать виртуальный экземпляр от базового оборудования с целью получения максимальной переносимости. И что же, получается, SR-IOV лишит меня мобильности? Ведь виртуальная машина будет обращаться к аппаратным компонентам напрямую, а значит, я не смогу осуществить динамическую миграцию на хост, несовместимый с SR-IOV». Но мои опасения не оправдались, Hyper-V решает эту проблему. Незаметно для пользователя реализованный в виртуальной машине клиент Network Virtualization Service Client (NetVSC) создает два пути для сетевого адаптера VM (так же и в виртуальной машине). Один путь предполагает использование технологии SR-IOV, а во втором случае применяется традиционный путь VMBus, пролегающий через коммутатор Hyper-V. Когда виртуальная машина выполняется на хосте, оснащенном средствами SR-IOV, используется путь SR-IOV, а шина виртуальной машины VMBus остается закрытой. Но если виртуальная машина переносится на хост, не оснащенный средствами SR-IOV, клиент NetVSC блокирует путь SR-IOV и открывает путь VMBus, прозрачный для виртуальной машины. Это означает, что пользователь не теряет мобильности даже в случае применения технологии SR-IOV.

Для применения этой технологии требуется, чтобы совместимостью с ней обладали и системная плата сервера, и сетевой адаптер. Кроме того, средствами для работы с SR-IOV должна быть оснащена операционная система (Server 8 располагает такими средствами).

Динамическая VMQ

И последнее усовершенствование, о котором я хотел бы рассказать, это динамическая очередь виртуальной машины, VMQ. Данное средство было впервые реализовано в версии Windows Server 2008 R2. VMQ позволяет формировать в сетевом адаптере несколько отдельных очередей, каждая из которых обслуживает конкретную виртуальную машину. Технология VMQ снимает часть нагрузки с коммутатора Hyper-V. Если искомые данные содержатся в определенной очереди, коммутатор исходит из того, что эти данные предназначены для определенной виртуальной машины. Различие между механизмами VMQ и SR-IOV состоит в том, что при использовании VMQ трафик все еще проходит через коммутатор Hyper-V; при этом VMQ представляет не виртуальные устройства, взятые в целом, а различные очереди трафика. В версии Server 2008 R2 назначение VMQ виртуальной машине осуществляется статически. Обычно назначения осуществляются в порядке поступления, поскольку каждый сетевой адаптер способен обрабатывать определенное количество очередей виртуальных машин.

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