Сетевая виртуализация – что это?

Новая возможность управления ИТ-расходами или прежде всего эффективность?

15.12.2009 09:22 by Natasha

Сетевая виртуализация представляет собой новый принцип организации управления, которое снижает ИТ-расходы, повышает бизнес эффективность и ускоряет работу ИТ-сервисов. Это не новая концепция, но её осуществление становится всё более доступным и простым в использовании.
По общепринятому определению, виртуализация представляет собой абстрактную технологичную конструкцию в форме централизованной и контролируемой среды. Сетевая виртуализация, эффективная обработка данных или «инфраструктура реального времени» - это консолидация аппаратных устройств в логическую среду. Такой подход обеспечивает корпорациям не только гибкость и возможность что-то менять в реальном времени, но также снижает расходы и уровень сложности управления многочисленными устройствами. Виртуализация делает сеть более восприимчивой и управляемой, более надёжной, полезной и, конечно, более рентабельной.
За последние 10-15 лет сетевые инфраструктуры выросли вместе с множеством компаний. По мере распространения ширпотребизации (commoditization) и снижения цен, корпорации начали больше инвестировать в «железо», но они не учли значительное увеличение сложности управления такого количества разнородных устройств. Управление начало выходить из-под контроля, поэтому возникла необходимость виртуализации.
Существует два различных типа виртуализации сети: «один-ко-многим» и «многие-к-одному». Классический пример варианта сетевой виртуализации «один-ко-многим» – это использование VLANов, но существуют и другие: виртуальная маршрутизация с множеством независимых элементов маршрутизации внутри устройства, защитные систем, которые предоставляют виртуальные элементы и беспроводные контроллеры, которые могут быть виртуализированы. Виртуализация «многие-к-одному» включает в себя отдельные объединенные между собой устройства, действующие как единый логический элемент. Примеры такой виртуализации: создание кластеров и штабелировка.
Создание кластеров обычно включает в себя логическую группировку отдельных коммутаторов с существующими LAN-соединениями и управление ими с помощью IP адреса главного коммутатора. Такие «повелитель/раб» кластеры не поддаются гибкому управлению, и с устройствами отличными по характеристикам возникают ограничения в соответствии с общим знаменателем по кластерам.
Штабелировка идёт на один шаг впереди на пути к виртуализации. Многочисленные наращиваемые коммутаторы могут быть виртуализированы в один виртуальный коммуатор, который будет работать как единый логический элемент, предоставляя простоту управления, доступность и расширяемость.      
Сейчас происходит виртуализация сетей во многих организациях: стекируемые устройства, агрегирование управления сетью и VLANы – общепринятые техники для улучшения управления сетью. Такие технологии, как XRN в 3Com, имеют обширные возможности стекирования, нужны для формирования единой структуры виртуальных коммутаторов и обеспечивают высокую эффективность и интеллектуальность сетевой инфраструктуры как периферии, так и ядра сети. XRN-коммутаторы, например 3Com Switch 5500G и 4800G, имеют возможность штабелировки для формирования единой виртуальной фабрики коммутаторов. Технология XRN означает, что вы можете перемещать коммутаторы без ущерба производительности других коммутаторов, для которых невозможно создание кластеров. Основная задача – это возможность управлять виртуальными серверами, сетями и клиентами интегрировано. Инструментами для выполнения этой задачи служат такие решения, как IMC (Intelligent Management Center) от 3Com, которое обеспечивает более высокую эффективность работы сети и энергосбережение. 
Консолидация сервера и виртуализация платформы уже движет сетевую инфраструктуру к самой высокой производительности, устойчивым соединениям с пулом серверов. Это один из основных двигателей, способствующих росту к 10-гигабитному Ethernet.
В будущем все сети станут виртуализированными. В конечном счёте, сети как единое целое будут служить в одном «облаке».     

Как было сделано демо Windows Server 2008

Igor Shastitko Technical Blog : Как было сделано демо Windows Server 2008 на запуске в Киеве.

http://blogs.technet.com/iwalker/archive/2008/04/13/ws08.aspx

После мероприятия, которое прошло в Киеве 3 апреля 2008, и на котором я демонстрировал технологию Quick Migration для виртуальных машин под управлением Hyper-V в Windows Server 2008, я получил массу вопросов – как устных (на самом мероприятии), так и письменных (по почте, через блог, Live Messenger)…  Основные вопросы, собственно – «А это не хитрое постановочное демо?», «А как это было сделано?», «Какое оборудование и софт необходим?», «Для каких сценариев, кроме продемонстрированного потокового видео, данная технология применима?», «Что делать с реальной нагрузкой, каковы вероятные задержки в реальной жизни?»… В данном посте попробую вкратце ответить на эти (и некоторые другие) вопросы…

Сценарий.
Итак, напомню краткий сценарий работы демо – на одном из физических серверов запускается виртуальная машина под управлением Windows Server 2008 Hyper-V, на которой установлены сервисы Windows Media, обеспечивающие широкое вещание видео потока. Клиентский ПК запускает Windows MediaPlayer, и принимает с виртуального сервера данный видео поток. Работающая виртуальная машина посредством технологии Quick Migration перемещается с одного физического сервера на другой с простоем примерно 20 сек и кратковременной остановкой видео на клиенте, которое тут же восстанавливается и продолжает воспроизводиться с точки останова. Аналогичная ситуация наблюдается и при «пинговании» виртуальной машины с клиента – теряются 3-5 пакетов, отправленных на адрес виртуальной машины, после чего пинги восстанавливаются.

Теория.
Одна из задач виртуализации – изоляция на одном физическом сервере (хосте) ролей сервера с целью большей безопасности, надежности и совместимости, гарантированного распределения аппаратных ресурсов. Но узким место такого решения является устойчивость и доступность физического хоста, на котором будут выполняться виртуальные машины с разными ролями. Задача высокой доступности физического сервера решалась и решается путем отказоустойчивой кластеризации (Windows Server Failover Clustering), при которой выполняемые на том или ином физическом сервер (узле кластера) сервисы «передаются» на другой узел. Целостность данных достигается наличием общего для всех узлов дискового хранилища, на котором и сохраняются данные сервиса, и что обеспечивает доступность данных, не зависимо от того, на каком именно узле сервис выполняется. Виртуальная машина с точки зрения кластеризации является обычным сервисом, который следует остановить на одном узле, сохранив его данные на общем хранилище, и запустить на другом узле. При этом виртуальная машина не просто сохраняет данные (собственно, ее основные данные – виртуальный диск – и так находятся на общем хранилище кластера), а сервис вирутализации приостанавливает работу переносимой виртуальной машины и сохраняет состояние ее оперативной памяти в виде файла на диске. Далее, этот файл восстанавливается на другом узле как память запускаемой там ранее остановленной виртуальной машины. Вот и все – мы получаем виртуальную машины, для которой, собственно, ничего не произошло, все ее состояние идентично моменту останова. Собственно, именно такой процесс и называется Quick Migration. Его эффективность (время простоя виртуальной машины при передаче) в большей степени зависит от скорости работы дисковой или сетевой подсистемы (в зависимости от используемого типа) общего хранилища кластера, на который будет сохраняться оперативная память виртуальной машины и, собственно, от объема этой самой памяти (согласитесь, записать/считать 512МБ – это не тоже самое по времени, что и 8ГБ). Также на время простоя виртуальной машины незначительно влияет эффективность работы самого кластера – время размонтирования на одном узле и монтирования на другом узле кластера диска общего хранилища с данными переносимой виртуальной машины, а также – время публикации сетевого интерфейса виртуальной машины в публичной сети кластера.

Практика.
Для построения демонстрационного примера по Quick Migration, подобного продемонстрированному на запуске, требуется:
2 ПК, выступающие в роли узлов кластера, поскольку речь идет о работе с виртуализацией под управлением Microsoft Hyper-V – обязательна поддержка процессором режимов х64, аппаратной виртуализации от Intel (I-VT) или AMD (AMD-V), запрета исполнения NX/XD, и достаточно памяти для выполнения собственно виртуальных машин. Желательно также наличие нескольких – 2х или более – сетевых  интерфейсов для разделения сетей кластера – публичной, внутренней, хранилища. В реальном примере это роль играли лезвия от HP BladeSystem c3000, в которых было установлено по 2 Intel Xeon (4 core) и 8ГБ ОЗУ.
1 ПК, выступающий в роли контроллера домена Active Directory: FC-кластеризация Windows Server 2008 обязательно требует участия узлов кластера в домене. В примере – также лезвие BladeSystem.
Общий дисковый массив, хранилище. Поскольку под рукой не оказалось ничего из аппаратных средств, что могло бы хоть как-то реализовать данную задачу (хотя лезвия c3000 были оснащены всем необходимым – FiberChannel контроллерами), то было принято простое решение – реализовать общее хранилище посредством iSCSI.
Здесь следует сказать пару слов – iSCSI – протокол, который обеспечивает передачу пакетов SCSI по сетям TCP/IP, т.е. позволяет представить ПК сетевые дисковые ресурсы как локальные дисковые устройства SCSI, и тем самым обеспечивает необходимые требования для реализации общего хранилища кластера. Для функционирования iSCSI требуется 2 основных компонента – сервер iSCSI (iSCSI Target) и клиент iSCSI (iSCSI Initiator). iSCSI Target – это аппаратное устройство или программное обеспечение, которое обеспечивает предоставление доступа к установленным локальным дискам клиентам iSCSI. iSCSI Initiator – клиент, являющийся программным модулем, обычно – драйвером дискового контроллера ОС (но может быть реализованным и аппаратно), обеспечивающий соединение с iSCSI Target и представляющий ОС диски iSCSI Target как локальные физические через точки подключения (target). Эффективность работы iSCSI напрямую зависит от пропускной способности сети, благо, в используемом решении HP BladeSystem c3000 с этим никаких проблем не наблюдается, особенно – между лезвиями.

Для организации общего дискового хранилища будущего кластера был выбран самый доступный, и, при этом, достаточно эффективный вариант реализации iSCSI – программый iSCSI Target, реализованный как сервис в Microsoft Windows Storage Server. Особенностью реализации является то, что он позволяет предоставлять доступ по iSCSI к дискам, которые представляются не локальными физическими дисковыми накопителями, а позволяет предоставить клиентам в виде диска файл формата .VHD, расположенный на любом разделе файловой системы и имеющий необходимый размер. Оснастка iSCSI Target позволяет создавать требуемые .VHD диски, определять режим создания «снимков» для их резервного копирования, и, собственно, описывать точки (target) подключения сетевых клиентов iSCSI – безопасность, аутенификация, режим работы – с наборами подключенных к этим точкам дисков .VHD. Если к точке подключено несколько дисков, каждый диск получает свой LUN ID, а если несколько точек – фактически для клиента это разные дисковые контроллеры. В качестве хранилища, как вы поняли, было использовано еще одно лезвие.
Создаем  при помощи оснастки iSCSI Target необходимую точку подключения и конфигурируем ее. Следует обратить внимание на перечень клиентов, которым будет разрешено подключаться к iSCSI – указываем либо IP-адреса их интерфейсов, либо IQN (уникальное имя внутри iSCSI сети), либо FQDN. Создаем два .VHD диска, один размером 2ГБ для будущего диска кворума кластера, и 30ГБ для хранения данных будущей виртуальной машины.
Таким образом, все необходимые компоненты кластера – узлы и общее хранилище – готовы.

Правильно настроенные сетевые интерфейсы – один из аспектов надежной и производительной работы кластера. Если это возможно – изолируйте интерфейсы, на которых будут работать публичная сеть, внутренняя сеть и сеть хранилища (в варианте iSCSI) разными физическими сетями или VLAN. В нашем случае, с лезвиями, которые имеют 2 сетевых интерфейса, мы изолировали интерфейсы для публичной сети (по ней узлы будут  общаться с контроллером домена и предоставлять кластеризуемые сервисы, для примера – сеть 192.168.100.0/24 ) и объединили сеть хранилища, по которой будет работать iSCSI и внутреннюю, приватную сеть кластера, по которой идет взаимодействие узлов, сеть 10.0.0.0/24. Также, в приватную сеть кластера был подключен один из сетевых интерфейсов лезвия с iSCSI Target.
На будущих узлах кластера конфигурируем сетевые интерфейсы, добавляем их в домен.

Подключаем диски общего хранилища через iSCSI. Для этого используем штатную утилиту Windows – клиент iSCSI Initiator. Запускаем ее на первом узле будущего кластера. При первом старте запрашиваются параметры автоматического старта службы Microsoft iSCSI – подтверждаем, и конфигурирования службы Windows Firewall для работы с iSCSI – также подтверждаем. В окне iSCSI Initiator Properties указываем в закладке Discovery в разделе Target Portals IP-адрес сетевого интерфейса сервера хранилища, подключенного у приватной сети (10.0.0.0/24). В дополнительных свойствах (кнопка Advanced) при указании адреса также указываем, что исходящий адрес на клиенте также из сети 10.0.0.0/24. Там же, в дополнительных свойствах, можно указать параметры аутентификации соединения, использования IPsec, проверки целостности данных.
При успешном подключении переходим в закладку Targets, где отображаются все доступные для клиента точки подключения (не диски, которые они публикуют) и их статус на клиента – подключены/не подключены. Выбираем созданную нами точку подключения, содержащую диски для будущего кластера, нажимаем кнопку Log on. В открывшемся диалоговом окне указываем опции для восстановления соединения при перезагрузке и поддержку multi-path. В дополнительных свойствах (кнопка Advanced), аналогично с подключением самой точки, указываем, что локальным адаптером является Microsoft iSCSI Initiator, IP-адрес источника – адрес интерфейса узла из сети 10.0.0.0/24, адрес портала – IP-адрес сетевого сервера хранилища также из сети 10.0.0.0/24. Если подключение успешно, то в списке точек подключения закладки Targets статус нужного нам подключения будет Connected. Если что-то не так – читаем документацию, полная инструкция по работе с клиентом iSCSI здесь - http://go.microsoft.com/fwlink/?LinkId=40963.
Повторяем операции по подключению клиента iSCSI через Microsoft iSCSI Initiator и на втором узле кластера. Таким образом, общее хранилище подключено.

На первом узле кластера при помощи Disk Management  переводим появившиеся диски iSCSI (отображаются как обыкновенные локальные диски) из состояния offline в online, инициализируем, создаем на каждом по одному разделу и форматируем их под NTFS с установками по умолчанию. Для удобства работы с дисками меньшему диску (2ГБ, для кворума кластера) назначаем метку Quorum и букву Q:, большему (30ГБ, для данных виртуальной  машины) – Storage и S:.
На втором узле кластера достаточно только вывести диски в режим online и назначить аналогичные первому кластеру буквы.

Установка и конфигурирование кластера.
На каждом из будущих узлов при помощи Server Manager добавляем функционал Failover Clustering из раздела Features. Также, перед конфигурацией кластера, на обоих узлах рекомендуется установить роль Hyper-V, предварительно обновив ее до версии RC0. На каждом узле сконфигурируйте виртуальный сетевой адаптер Hyper-V как внешний и «привяжите» его к сетевому интерфейсу публичной сети (192.168.100.0/24) обоих узлов. Важно, чтобы этот виртуальный адаптер имел одно и то же имя на каждом узле.

На первом узле кластера запускаем из Start|Administration Tools оснастку Failover Cluster Management, выбираем команду создания нового кластера, указываем мастеру создания кластера имена обеих подготовленных узлов.  Выбираем опцию выполнения тестов работоспособности будущего кластера, дожидаемся выполнения всех тестов, которые могут занять до 30-45минут времени. При успешном окончании тестов указываем имя кластера и его IP-адрес (из публичной сети 192.168.100.0/24, отличный от адресов самих узлов). Кластер готов к работе.

Создание виртуальной машины, которая будет отказоустойчивой благодаря Quick Migration и регистрация ее как приложения кластера.
На первом узле кластера из оснастки роли Hyper-V консоли Server Manager создаем новую виртуальную машину. Основные требования к виртуальной машине – это размещение файла ее конфигурации и виртуального диска на общем диске кластера S:, использование виртуального сетевого адаптера с общим именем. Если по какой-то причине диск находится под управлением второго узла – выполните создание виртуальной машины на втором узле.
Установите Windows Server 2008 в виртуальную машину, установите также на него обновления Hyper-V до RC0. По окончании установки и конфигурации остановите виртуальную машину.
На том узле, котором создавалась виртуальная машина, запустите оснастку Failover Cluster Management, подключитесь к «свежесозданному» кластеру, и выберите раздел Services or Applications, а в его опциях – Configure a Service or Application.

В мастере конфигурирования сервисов и приложений кластера из списка выберите Virtual Machine, на следующем шаге мастера – из списка непосредственно виртуальных машин выберите созданную вами на общем диске виртуальную машину. Мастер добавит ее как приложение в раздел Services or Applications.
Из перечня опций виртуальной машины на кластере выберите Bring this service or application online – вирутуальная машина запустится уже как ресурс кластера.
Для тестирования попробуйте выполнить команду ping или получить какой-то доступ к ее службам.
Для выполнения операции Quick Migration по переносу виртуальной машины на другой узел кластера выберите из опций Move this service or application to another node. В этот момент вы можете увидеть, как идет сохранение состояния машины на общий диск, передача управления диска другому узлу, восстановление состояния на новом узле.
Ссылки по теме:
Microsoft iSCSI – http://www.microsoft.com/iscsi
Виртуализация и Hyper-V – http://www.microsoft.com/virtualization
Кластера Windows Server 2008 - http://technet2.microsoft.com/windowsserver2008/en/library/adbf1eb3-a225-4344-9086-115a9389a2691033.mspx?mfr=true

Posted: Sunday, April 13, 2008 8:48 AM by iWalker

Paragon Go Virtual Free: Powerful Migration Tool For Windows

Paragon Go Virtual is yet another free and powerful utility from the well known Paragon Software. In simple words, Paragon Go Virtual lets you make a virtual clone of your PC in three simple steps. That is, you can use your PC’s applications, files and user settings in a virtual environment in just three steps.

Key features:

# Full Windows OS Support – Guaranteed support for any Windows operating system since Win2K (excluding server editions).

# P2V Migration – Migrate a physical system to a virtual machine or convert a backup image to a virtual disk.

# Migration without rebooting Windows – Hot processing of locked (in-use) hard disks lets you migrate a computer without rebooting and interrupting Windows.

# P2V Adjust OS to recover the startup ability after unsuccessful virtualization with a 3rd party tool and to make Windows Vista/7 backups bootable on virtual hardware.

# Smart Driver Injector – Makes the process of adding new drivers smooth and easy.

Overall, Paragon Go Virtual is a free migration tool for PC users who want to work in a virtual environment without technical risk.

Download Paragon Go Virtual Free

Microsoft Enhances Hyper-V R2 for Failover Clustering

By Kurt Mackie

• 06/16/2010

Hyper-V R2 now supports a maximum of 1,000 virtual machines (VMs) in a cluster. Previously, in May, the hypervisor just supported a total of 960 VMs per cluster. A cluster can be defined as a grouping of host machines and their VMs that are managed as one entity. Typically, there would be at least two physical computers in a cluster, with one serving as the master (or job scheduler) and the other as the slave (performing the work).

The increased capacity was enabled because Hyper-V R2 now supports up to 384 VMs per node. Microsoft described the earlier limitations in a blog post on Wednesday.

"Until May 2010, the support limit was 64 VMs per host and up to 16 nodes in a cluster with one node for failover (a 15+1 cluster) for a total of 960 VMs," the blog explained.

Users of Hyper-V R2 -- either the standalone server or the one rolled into Windows Server 2008 R2 -- can vary the number of VMs per node for a maximum of 16 nodes per cluster. Microsoft supplies a table illustrating the possible number of VMs per node in its blog post.

Microsoft recommends reserving at least one node as a failover for the cluster. This failover node, or "passive node," stays idle, waiting to take over work should another node fail. With one node reserved for failover, a typical cluster may leverage a maximum of 15 nodes.

Microsoft further cautions that the number of VMs that can be run at the same time depends on three factors:

• "Amount of physical memory being used by each virtual machine.
• "Networking and storage bandwidth.
• "Number of disk spindles, which affects disk I/O performance."

Microsoft describes the requirements for running VMs using Hyper-V, as well as the limitations, in a TechNet article here.

About the Author

Kurt Mackie is online news editor, Enterprise Group, at 1105 Media Inc.

Hyper-V's Missing Feature

By Greg Shields

• 04/01/2010

Windows Insider has returned to Redmond -- and it feels good to be home! I'm looking forward to providing the inside scoop on the bits of Microsoft technologies that you may not be aware of. If there's a useful feature or an unexpectedly smart way to manage your Windows systems, you'll find it here. And what better way to resume this column than with a major warning -- one that could greatly impact the operation of your Hyper-V-based virtual machines (VMs).

First, some background. In the last few years, the velocity of virtualization adoption has increased dramatically. Businesses both large and small see the cost savings and management optimizations that virtual servers bring. Changing the ballgame in many ways has been the updated Hyper-V platform, which arrived with the release of Windows Server 2008 R2. This second edition of Hyper-V adds Live Migration and improvements to VM disk storage, as well as a set of performance enhancements that solidifies its place as an enterprise-worthy hypervisor.

Yet with all these new improvements, Hyper-V version 2 still lacks one key capability, which could cause major problems to the unprepared environment: I'll generically refer to that feature as memory oversubscription.

Memory oversubscription -- sometimes also called memory overcommit -- is a hypervisor feature that enables concurrently running VMs to use more RAM than is actually available on the host. It's easiest to explain this situation through a simple example. Consider a Hyper-V host that's configured with 16GB of RAM. Ignoring for a minute the memory requirements of the host itself, this server could successfully power on 16 VMs, each of which is configured to use 1GB of RAM.

The problem occurs when you need to add a 17th VM to this host. Because Hyper-V today can't oversubscribe its available RAM, that 17th VM won't be permitted to power on. In short, the RAM you've got is, well, the RAM you've got.

Failed Failovers
While this situation is obviously irritating for a single-server Hyper-V environment, it becomes quite a bit more insidious when Hyper-V hosts are clustered together. We all know that Hyper-V leverages Windows Failover Clustering as its solution for high availability. These two components work together to Live Migrate VMs between cluster nodes. Together they enable IT professionals to relocate VMs off of a Hyper-V host prior to performing maintenance. Because Windows servers often need patching that requires a reboot, this Live Migration capability ensures that process can be completed without impacting VMs.

The second scenario where clustering comes in handy is during an unexpected loss of a Hyper-V host. In this situation, Windows Failover Clustering can automatically restart VMs atop any of the surviving cluster members.

[Click on image for larger view.]

Figure 1. A Hyper-V cluster must reserve enough unused RAM to support the memory needs of at least one failed server.

Yet herein lies the problem: Because today's Hyper-V hosts can never power on more VMs than the RAM they have available, a situation becomes possible in which surviving cluster hosts don't have enough available RAM. When this happens, some of those failed VMs might not get restarted elsewhere, negating the value of the cluster. In fact, because of this limitation, any Hyper-V cluster set up to protect against the loss of one member must always reserve an unused amount of RAM equal to that member's concurrently running VMs.

What does this mean to you? In short, it means a lot of unused RAM. It also means that bigger Hyper-V clusters -- those with more members -- are a better idea than smaller Hyper-V clusters.

To explain this, imagine that you've added a second server to the one referenced earlier, and as a result created a two-node cluster. In this environment, you now have 32GB of RAM that's been equally divided between those two cluster nodes. You still have 16 VMs that need to run concurrently, each of which requires 1GB of RAM.

Creating a two-node cluster for this environment gives you failover capability but offers no additional capacity for more VMs. Now, the loss of one of the two hosts means that every VM must failover to the second host. As a result, any similarly sized two-node cluster that needs full failover capabilities must set aside 50 percent of its total RAM as unused.

Scaling this cluster upward to four nodes cuts the waste percentage in half. As shown in Figure 1, a similarly sized four-node cluster must reserve 25 percent of its total RAM. An eight-node cluster cuts that number again in half, and so on. This quantity of RAM doesn't necessarily need to be equally distributed among the cluster members, but it must be available somewhere if VMs are to successfully failover.

Adding more hosts to your Hyper-V cluster is as important as adding more powerful hosts. The presence of more cluster members gives the cluster more targets for failing over VMs, while reducing the impact of wasted RAM.

Of course, another solution for this problem is for Microsoft to fix Hyper-V and add this critically necessary capability that its competitors already have. Rumors abound that it might be coming. But, as of this writing, Microsoft has released no official word on when -- or if -- such a fix may arrive. Until that time, be conscientious with the RAM in your Hyper-V clusters.

About the Author

Greg is an independent author, speaker, and IT consultant, as well as a Founding Partner with Concentrated Technology. With nearly 15 years in information technology, Greg has developed extensive experience in systems administration, engineering, and architecture specializing in Microsoft OS, remote application, and virtualization technologies.  Greg is a Contributing Editor and columnist for TechNet Magazine, a former columnist for Redmond Magazine and Virtualization Review Magazine, and has authored or contributed to ten books and countless white papers and webcasts. His writing is regularly seen in publications like TechTarget online, e-books from Realtime Publishers, and the UK-based IT EXPERT Magazine.  He has also produced numerous video training series for CBT Nuggets.

Virtualizing Your Exchange Environment

The decision to virtualize Exchange can be a difficult one, but it can also pay off for some organizations. Here's what to consider when looking at running Exchange in a virtual environment.

• By J. Peter Bruzzese, Lee Owens
• 04/01/2010

To install Microsoft Exchange in a virtual environment, first you want to ... Wait a minute! You don't really want to read an article about how to install Exchange on a virtual server, do you? Really, the process of virtualizing Exchange is kind of boring when it comes right down to it. It's exactly the same process as installing it on a regular physical server, for the most part. And once it's installed and everything is up and running on a virtualized guest operating system, either on Microsoft Hyper-V or VMware ESX, there's not much more to the story. Of course, you must manage and maintain it just as you would a physical server, but all the really interesting stuff about virtualizing Exchange comes long before you double-click setup.exe.

Indeed, while actually installing Exchange in a virtual environment is nothing new, what is noteworthy is that until August 2008, Microsoft would not officially support such installations. This meant that running Exchange virtually was something often relegated to the realm of test labs and other non-production uses -- unless you were one of those renegade IT professionals who released it into production, anyway. There were IT pros who trusted their enterprise virtualization platform enough to boldly forge ahead and put virtualized Exchange into production, but they did so without Microsoft's blessing and risked being left out in the cold without support if issues did arise.

However, with the server virtualization game playing out at breakneck speed, Microsoft really had no choice but to start supporting Exchange on virtual installations, especially with all the work Redmond was putting into its own virtualization platform, Hyper-V. While Microsoft could have -- and should have -- made this move sooner, it's at least commendable that the company finally committed to it almost two years ago instead of doing something like holding out for the release of Hyper-V Server 2008 R2. The bottom line is that Exchange customers wanted support for virtual installations, and Microsoft responded by giving customers what they wanted. In other words: Better late than never.

In a perfect world, everyone would now be running Exchange in a virtual environment with no problems. E-mail would flow happily ever after, and this is where the story would end. But given the realities of how Exchange is deployed, this is where our story begins.

The Support Policy
What exactly does Microsoft currently support when it comes to virtualizing Exchange? While not quite as complex as Microsoft's licensing model, the support policy is very detailed and somewhat restrictive. As you read the policy, it becomes obvious that Microsoft approached this whole thing in a way that would allow the company to protect its own interests from a support perspective. However, Redmond's new support stance serves the best interests of its customers as well. How so? When the customer implements a virtualized Exchange environment by following the detailed guidelines and restrictions set forth in the policy, that customer is going to have the best-possible virtual experience. In that sense, it's no different than the requirement to follow Microsoft's recommendations when installing on physical servers in order to have the product work the way it should.

You can locate the policy itself in a TechNet article titled "Microsoft Support Policies and Recommendations for Exchange Servers in Hardware Virtualization Environments," online here. Just be prepared to set some time aside when you get ready to read it, as it's 11 pages long, printed. If you want to cheat just a bit, here are a few of the highlights you'll need to look out for:

• Exchange 2007 must be installed on Windows Server 2008 with Hyper-V or Microsoft Hyper-V Server 2008. Exchange 2010 can be installed on those versions or on R2 versions. Either Exchange version may be installed on a third-party hypervisor that has been validated under the Windows Server Virtualization Validation Program (SVVP) -- more on that to come.
• An Exchange 2007 guest must run SP1 or later and be deployed on Windows Server 2008. An Exchange 2010 guest must run on Windows Server 2008 SP2 or R2.
• Each Exchange server version and role must be sized to meet the general system requirements for that version, just as it would for an installation on a physical server.
• The Unified Messaging (UM) server role for either Exchange 2007 or 2010 is not supported in a virtualization environment. However, that doesn't mean it doesn't work. The reason for the lack of support is that the UM uses a third-party Real Time Collaboration stack, and the vendor who makes the stack doesn't support virtualization. Microsoft resolved initial voice-quality problems with earlier builds of Hyper-V, though, and many shops are running UM in production without any issues. But until the vendor supports virtualization, the UM role won't be supported.
• For storage, you must use either fixed disks (under Hyper-V, the VHDs must be smaller than 2,040GB), SCSI pass-through (raw disks) or iSCSI storage. Virtual disks that use differencing or delta mechanisms are not supported.
• On the physical host server, you can only install management software, such as anti-virus, backup software, virtual machine (VM) management software and so on. You can't run any other applications, such as SQL Server, Active Directory or even Exchange.
• Microsoft doesn't support combining Exchange high-availability solutions -- cluster continuous replication (CCR) or single-copy cluster for 2007, or database availability groups for 2010 -- with hypervisor-based clustering or other high-availability or migration solutions.
• Creating VM snapshots of an Exchange guest VM from within the hypervisor application on the host is not supported.
• When specifying the number of virtual processors allocated to Exchange guest machines, the supported ratio of virtual processors to logical processors must not be greater than 2-to-1.
• Research, plan and test your virtualization solution. This isn't stated as a direct condition of the support policy, but it's the underlying suggested approach that runs throughout it.

This is a highly condensed and brief overview of the major support conditions. The policy itself goes into greater depth on these points and contains recommendations for many more elements, such as considerations for backup and restore, networking and so on.

The policy article referenced earlier also contains the requirements for virtualizing Exchange 2003. If you're wondering about converting your Exchange 5.5 or 2000 servers to VMs, there is, unfortunately, no support for any version of Exchange prior to Exchange 2003 in a virtualization environment.

As far as the official requirements for virtualizing Exchange 2010 are concerned, they're very similar to those for 2007. The complete virtualization requirements list can be found in the TechNet article "Exchange 2010 System Requirements," online here.

Which Roles Should I Virtualize?
Which Exchange server roles are the best candidates for Exchange virtualization? For many, the immediate candidates are the Client Access Server (CAS) and Hub Transport (HT) roles, which often can easily run on and benefit from virtualization. Be aware, though, that in Exchange 2010 the CAS role will demand more resources, so plan accordingly.

While Microsoft supports the Mailbox server role installed on a virtual server, there are many IT pros that cringe at the thought of setting up their systems that way. The critics feel that the Mailbox role is so CPU- and I/O-intensive that virtualizing it in production is a mistake, and performance will suffer. But there are many reasonable ways to look at this without writing off virtualization of your Mailbox role. It's true that you'll see a slight rise in your CPU utilization with virtualization, but many IT pros say that, unless you're already maxed out, you're looking at a 5 percent increase. As for the I/O issue, you can work around it by placing the virtualized drives on a SAN or, in smaller environments, by working with SCSI pass-through storage for the Mailbox database and transaction logs. Keep in mind, too, that you don't have to virtualize all of your production servers.

A Note on Third-Party Support

We've focusing on the software offerings that Microsoft provides for hardware virtualization functionality.

However, there are non-Microsoft hardware virtualization software vendors that Microsoft considers support partners. To learn more about the support policies for third-party hardware virtualization software, see:

• "Updated support policy for Microsoft software running in non-Microsoft hardware virtualization software environments"
• "Support partners for non-Microsoft hardware virtualization software"

-- J.P.B.

So, perhaps for higher availability, you wish to implement a CCR cluster. You can take a single server and virtualize the passive side, for instance. You can also use that same server to run a second CAS and/or HT server for higher availability of those roles. Really, there are scores of different design options that might pull virtualization into your environment judiciously if you're concerned about the performance hit -- especially on the Mailbox role.

Typically, however, if you meet Microsoft's support recommendations and size and test the solution appropriately, you can be sure that Exchange will perform just as it's supposed to. Your users will never know the difference. And in the end, isn't that peace of mind part of what virtualization is all about?

The Edge Transport (ET) role is supported for virtualization, although some may be concerned about an escape attack where a hacker goes through the VM and gets at the virtualized server itself. This is a possibility, but I can't find any examples of a successful escape attack. Moreover, the ET role sits on the perimeter, so the attack would only go so far even if it did succeed.

Hyper-V vs. ESX

One question that constantly comes up when discussing Exchange virtualization in front of a live audience is, "Which vendor is better?" To use the word "better" in this discussion is a bit awkward. From a pure performance perspective, major vendors have tested Microsoft Hyper-V's performance in comparison to that of other solutions -- including VMware ESX -- and found the performance to be comparable, with ESX having a slight performance gain, but not enough to be considered groundbreaking. In terms of choosing your virtualization vendor, the discussion has now moved into the realm of management features supported, support for memory over-commit (which Hyper-V does not support), and -- most importantly in our current economic situation -- cost (where Hyper-V seems to take the blue ribbon).

-- J.P.B.

One final note: As previously mentioned in the support conditions, the UM server role is not supported by Microsoft on virtualization. Does this mean that if it's sized appropriately, it won't work? Of course not -- but keep in mind that you enter at your own risk if you choose to virtualize it.

Third-Party Support
When first published, Microsoft's new Exchange virtualization support policy met with initial criticism as being self-serving, because the company only directly supported its own virtualization technologies. VMware customers who rushed out to check the new policy could find no initial references to ESX.

Actually, Microsoft took the initiative to bring support to the table for customers of any virtualization vendor, provided that the vendor would work with Microsoft to validate its configurations. In order to do so, Microsoft launched the Windows SVVP. Full details of the program are available on the official SVVP page on the Microsoft Web site. Customers running Exchange on a third-party virtualization platform that has been validated under SVVP can receive full support from Microsoft. But what happens if you do have issues and Microsoft believes that the root of the problem is with the vendor's hypervisor software? As per the SVVP, Microsoft will actually work with the vendor through a support arrangement in order to assist in resolving the issue.

What has been the response to the Microsoft SVVP?

Currently, there are 11 vendors who have joined the SVVP, and eight of them so far have solutions and products that have been validated. These include Citrix Systems Inc., Hitachi Ltd., Novell and Red Hat Inc. -- just to name a few. And what about VMware? Yes, it's in there, too. As a matter of fact, VMware was able to announce on Sept. 3, 2008, that it was the very first vendor to have its hypervisor -- VMware ESX 3.5 update 2 -- validated by Microsoft under the program.

Licensing Compliance
Microsoft's move to support a virtualized Exchange installation is a definite indicator that many IT shops are choosing to go in that direction. And it's not just support for Exchange, either -- Microsoft's announcement last August stated that it had updated its technical support policy for 31 server applications to be supported on virtual platforms, including applications like SQL and SharePoint. The full list can be found here.

But Microsoft didn't stop with just a new support policy. In a move of true innovation, it also changed its licensing terms as of Sept. 1, 2008. The company now allows for moving 41 server applications running on virtual guest machines between physical host servers within a server farm as often as necessary without having to pay for additional licensing fees or worry about license reassignment.

What does this mean, and why should you care? Well, suppose you previously had two physical servers running a hypervisor and had a single Exchange virtual server configured on one of them. If you wanted to move the guest Exchange machine from running on one physical host over to the other, then you'd have had to reassign the license to that server, and you could only do so once within 90 days to be in licensing compliance. This often led to extra expense for many IT shops, because in order to remain compliant, they would've had to purchase an additional Exchange license for each physical server that the virtual server may have had to run on. In this example, that would've meant buying one additional license so that the virtual Exchange server could be moved back and forth between either of the two hosts as needed.

Bottom line: With the new licensing arrangement, you can take advantage of the dynamic nature of virtualization without incurring any extra licensing expense, because you can now count licenses by server farm instead of by individual servers.

Now that Microsoft officially supports Exchange in a virtual environment -- and on third-party hypervisors at that -- and all the licensing concerns have mostly been worked out, the technical question of, "can I virtualize Exchange?" has certainly been answered. This concludes our story, then, correct? Well, no, because for many IT shops there's still the philosophical question that remains: Should I virtualize Exchange?

Unfortunately, there's no single right or wrong answer to this question. Rather, it's wholly dependent on a multitude of factors that are going to differ greatly from one environment to another. It's not a decision to make lightly. Exchange is a core application for many businesses today, and users rely heavily on it. Therefore, if you're completely new to virtualization technology, then perhaps virtualizing your Exchange servers may not be what you want to start off with to get your feet wet. But for organizations that have successfully implemented one or more hypervisor platforms along with the appropriate storage solutions, there are compelling reasons to look at converting or migrating some -- or all -- of your organization to virtual Exchange.

About the Authors

J. Peter Bruzzese (Triple-MCSE, MCT, MCITP: Messaging) is a longtime contributor to Redmond, an InfoWorld journalist and the Exchange 2010 Instructor for Train Signal. You can reach him at peter@trainsignal.com.

Lee Owens, Triple-MCSE and MCITP: Messaging 2007, has more than 13 years of experience in the IT field and is currently an enterprise systems engineer focused on Active Directory, Exchange, mobility and virtualization technologies.

Best Hypervisors' for VDI Tested by Citrix

By Kurt Mackie

• 03/26/2010

Citrix on Thursday described virtual desktop infrastructure (VDI) performance differences using various hypervisors.

Apparently, which hypervisor is used makes a difference with desktop virtualization, per Citrix's tests, which were conducted internally. Only Citrix's XenDesktop 4 desktop virtualization solution was used for the tests. VMware's View desktop virtualization application was not tested.

The test results were described by Simon Crosby, chief technology officer for Citrix's Data Center and Cloud Division, in a blog post.

Performance was measured based on virtual machine (VM) density on a single server, running Windows XP or Windows 7 as guests. The hypervisors tested included Microsoft Hyper-V R2, Citrix XenServer 5.5 and an undefined "other" hypervisor group.

For the Windows 7 guest, Microsoft's Hyper-V R2 hypervisor supported the highest VM density. However, Citrix's XenServer 5.5 hypervisor scored the highest VM density when running the Windows XP guest.

Crosby noted these performance differences on Hyper-V R2 between the two Windows guests.

"For Windows XP guests Hyper-V R2 doesn't do such a fabulous job," Crosby wrote in the blog. "I've spoken to Jeff Woolsey, PM for Hyper-V, who acknowledges this readily because XP has a relatively short remaining lifetime, and because of the focus at Microsoft on Windows Server workloads and Windows 7 as the new client OS."

The venerable Windows XP has been available for nearly nine years, with extended support scheduled to end on April 8, 2014. Microsoft released Windows 7 in October of last year.

Citrix plans to test the most current hypervisor products -- including Hyper-V Service Pack 1 and XenServer "Midnight Ride" -- and "publish the results soon," according to Crosby. Midnight Ride is the next version of XenServer and is currently available as a beta release.

Microsoft announced earlier this month a forthcoming service pack for Windows Server 2008 R2. The service pack will include a dynamic memory management capability that will allow the memory use of VMs to be adjusted on demand. It will also include RemoteFX desktop virtualization technology designed to improve the graphics experience for remote Windows users.

Storage options for Windows Server 2008 Hyper-V

суббота, 12 декабря 2009 г.

Windows Server 2008’s Hyper-V has been in public beta for a while now and lots of people have been experimenting with it. One aspect that I am focusing on is storage for those virtualized environments and more specifically the options related to SAN storage.
Virtualization terminology
Before we start, I wanted to define some terms commonly used in virtualization. We refer to the physical computer running the Hyper-V software as the parent partition or host, as opposed to the child partition or guest, which is the term used for virtual machine. You can, say, for instance, that the host must support hardware-assisted virtualization or that you can now run a 64-bit OS in the guest.
The other term used with Hyper-V is Integration Components. This is the additional software you run on the guest to better support Hyper-V. Windows Server 2008 already ships with Hyper-V Integration Components, but older operating systems will need to install them separately. In Virtual Server or Virtual PC, these were called “additions”.
Exposing storage to the host
A Hyper-V host is a server running Windows Server 2008 and it will support the many different storage options of that OS. This includes directly-attached storage (SATA, SAS) or SAN storage (FC, iSCSI). Once you expose the disks to the host, you can expose it to the guest in many different ways.
VHD or passthrough disk on the host
As with Virtual Server and Virtual PC, you can create a VHD file in one of the host’s volume and expose that as a virtual hard disk to the guest. This VHD functions simply as a set of blocks, stored as a regular file using the host OS file system (typically NTFS). There are a few different types of VHD, like fixed size or dynamically expanding. This hasn’t changed from previous versions. The maximum size of a VHD continues to be 2040 GB (8 GB short of 2 TB).
You can now expose a host disk to the guest without even putting a volume on it using a passthrough disk. Hyper-V will let you “bypass” the host’s file system and access a disk directly. This raw disk, which is not limited to 2040 GB in size, can be a physical HD on the host or a logical unit on a SAN. To make sure the host and the guest are not trying to use the disk at the same time, Hyper-V requires the disk to be in the offline state on the host. This is referred to as LUN passthrough, if the disk being exposed to the guest is a LUN on a SAN from the host perspective. With passthrough disks you will lose some nice, VHD-related features, like VHD snapshots, dynamically expanding VHDs and differencing VHDs.
IDE or SCSI on the guest
When you configure the guest’s virtual machine settings, you need to choose how to show the host disk (be it VHD file or passthrough disk) to the guest. The guest can see that disk either as a virtual ATA device on a virtual IDE controller or as a virtual SCSI disk device on a virtual SCSI controller. Note that you do not have to expose the device to the guest in the same way it is exposed to the host. For instance, a VHD file on a physical IDE disk on the host can be exposed as a virtual SCSI disk on the guest. A physical SAS disk on the host can be exposed as a virtual IDE disk on the guest.
The main decision criteria here should be the capabilities you are looking for on the guest. You can only have up to 4 virtual IDE disks on the guest (2 controllers with 2 disks each), but they are the only types of disk that the virtualized BIOS will boot from. You can have up to 256 virtual SCSI disks on the guest (4 controllers with 64 disks each), but you cannot boot from them and you will need an OS with Integration Components. Virtual IDE disks will perform at the same level of the virtual SCSI disks after you load the Integration Components in the OS, since they leverage the same optimizations.
You must use SCSI if you need to expose more than 4 virtual disks to your guest. You must use IDE if your guest needs to boot to that virtual disk or if there are no Integration Components in the guest OS. You can also use both IDE and SCSI with the same guest.
iSCSI directly to guests
One additional option is to expose disks directly to the guest OS (without ever exposing it to the host) by using iSCSI. All you need to do is load an iSCSI initiator in the guest OS (Windows Server 2008 already includes one) and configure your target correctly. Hyper-V’s virtual BIOS does not support booting to iSCSI directly, so you will still need to have at least one disk available to the guest as an IDE disk so you can boot to it. However, all your other disks can be iSCSI LUNs.
There are also third-party solutions that will that will allow a Hyper-V guest to boot from an iSCSI LUN exposed directly to the guest. You can check a product from EmBoot called WinBoot/i that does exactly that at http://www.emboot.com.
Moving disks between hosts
Another common usage scenario in virtualization is moving a virtual machine from one host to another. You will typically shut down the guest (or pause it), move the storage resources and then bring the VM up in the new host (or resume it).
The “move the storage” part is easier to imagine if you are using VHD files for guest disks. You simply copy the files from host to host. If you’re using physical disks (let’s say, SAS drives that are passthrough disks exposed as IDE disks to the guest), you can physically move the disk to another host. If this is a LUN on a SAN, you would need to reconfigure the SAN to mask the LUN to the old host and unmask it to the new host. You might want to use a technology called NPIV to use “virtual” WWNs for a set of LUNs, so you can move them between hosts without the need to reconfigure the SAN itself. This would be the equivalent of using multiple iSCSI targets for the same Hyper-V host and reconfiguring the targets to show up on the other host. If you use iSCSI directly exposed to the guest, those iSCSI data LUNs will just move with the guest, assuming the guest continues to have a network path to the iSCSI target and that you used one of the other methods to move the VM configuration and boot disk.
Windows Server 2008 is also a lot smarter about using LUNs on a SAN, so you might consider exposing LUNs to multiple Hyper-V hosts and onlining the LUNs as required, as long you don't access them simultaneosly from multiple hosts.
Keep in mind that, although I am talking about doing this manually, you will typically automate the process. Windows Server Failover Clustering and System Center Virtual Machine Manager (VMM) can make some of those things happens automatically. In some scenarios, the whole move can happen in just seconds (assuming you are pausing/resuming the VM and the disks are in a SAN). However, there is no option today with a robot to physically move disks from one host to another :-).
A few tables
Since there are lots of different choices and options, I put together a few tables describing the scenarios. They will help you verify the many options you have and what features are available in each scenario.
Table 1
VHD on host volume
Passthrough disk on host
Directly to guest
DAS (SAS, SATA)
X
X
FC SAN
X
X
iSCSI SAN
X
X
X
Table 2
DAS or SAN on host,
VHD or passthrough disk on host,
exposed to guest as IDE
DAS or SAN on host,
VHD or passthrough disk on host,
exposed to guest as SCSI
not exposed to host,
exposed to guest as iSCSI LUN
Guest boot from disk
Yes
No
No
Additional sw on guest
Integration Components (optional)
Integration Components
iSCSI initiator
Guest sees disk as
Virtual HD ATA Device
Msft Virtual Disk SCSI Disk Device
MSFT Virtual HD SCSI Disk Device
Guest max disks
2 x 2 = 4 disks
4 x 64 = 256 disks
Not limited by Hyper-V
Guest hot add disk
No
No
Yes
Guest hw snap on SAN
No
No
Yes
Table 3
Scenario
1
IDE VHD Local
2
SCSI VHD Local
3
IDE Passthrough Local
4
SCSI Passthrough Local
5
IDE VHD Remote
6
SCSI VHD Remote
7
IDE Passthrough Remote
8
SCSI Passthrough Remote
9
Guest iSCSI
Storage type
DAS
DAS
DAS
DAS
SAN, FC/iSCSI
SAN, FC/iSCSI
SAN, FC/iSCSI
SAN, FC/iSCSI
SAN, iSCSI
Exposed to host as
VHD on NTFS
VHD on NTFS
Passthrough disk
Passthrough disk
VHD on NTFS
VHD on NTFS
Passthrough disk
Passthrough disk
Not exposed
Exposed to guest as
IDE
SCSI
IDE
SCSI
IDE
SCSI
IDE
SCSI
iSCSI LUN
Guest driver is “synthetic”
No (a)
Yes
No (a)
Yes
No (a)
Yes
No (a)
Yes
No (b)
Guest boot from disk
Yes
No
Yes
No
Yes
No
Yes
No
No (i)
Guest max disks
4
256
4
256
4
256
4
256
(j)
Guest max disk size
~2 TB (c)
~2 TB (c)
Limit imposed by guest (d)
Limit imposed by guest (d)
~2 TB (c)
~2 TB (c)
Limit imposed by guest (d) (e)
Limit imposed by guest (d) (e)
(d) (e)
Hyper-V VHD snapshots
Yes
Yes
No
No
Yes
Yes
No
No
No
Dynamically expanding VHD
Yes
Yes
No
No
Yes
Yes
No
No
No
Differencing VHD
Yes
Yes
No
No
Yes
Yes
No
No
No
Guest hot add disk
No
No
No
No
No
No
No
No
Yes
SCSI-3 PR for guests on two hosts (WSFC)
No
No
No
No
No
No
No
No
Yes
Guest hardware snapshot on SAN
N/A
N/A
N/A
N/A
No
No
No
No
Yes
P2V migration without moving SAN data
N/A
N/A
N/A
N/A
No
No
Yes (f)
Yes (f)
Yes (g)
VM migration without moving SAN data
N/A
N/A
N/A
N/A
Yes (h)
Yes (h)
Yes (f)
Yes (f)
Yes (g)
(a) Works as legacy IDE but will perform better if Integration Components are present.
(b) Works as legacy network but will perform better if Integration Components are present.
(c) Hyper-V maximum VHD size is 2040 GB (8 GB short of 2 TB).
(d) Not limited by Hyper-V. NTFS maximum volume size is 256 TB.
(e) Microsoft iSCSI Software Target maximum VHD size is 16 TB.
(f) Requires SAN reconfiguration or NPIV support, unless using a failover cluster.
(g) For data volumes only (cannot be used for boot/system disks).
(h) Requires SAN reconfiguration or NPIV support, unless using a failover cluster. All VHDs on the same LUN must be moved together.
(i) Requires third-party product like WinBoot/i from EmBoot.
(j) Not limited by Hyper-V.
References
http://blogs.msdn.com/tvoellm/archive/2008/01/02/hyper-v-scsi-vs-ide-do-you-really-need-an-ide-and-scsi-drive-for-best-performance.aspx
http://blogs.technet.com/jhoward/archive/2007/10/04/boot-from-scsi-in-virtual-server-vs-boot-from-ide-in-windows-server-virtualization.aspx
Screenshots
Screenshot of settings for scenario 2 in table 3 (VHD exposed as SCSI):
Screenshot of settings for scenario 8 in table 3 (iSCSI LUN passthrough exposed as IDE, which your guest can boot from):

Виртуализация систем хранения

воскресенье, 8 ноября 2009 г.

http://www.citforum.ru/nets/storage/virtualization/
Леонид Черняк
20.04.2002
Открытые системы, #04/2002

Сетевые технологии радикально изменили общую картину корпоративных информационных систем; теперь ИТ-инфраструктуры представляются не иначе, как в виде многоуровневой модели, простирающейся от пользовательских приложений до аппаратуры. Два нижних уровня этой модели занимают адаптивная вычислительная архитектура и интегрированная сетевая архитектура хранения данных. Ряд технологий, используемых для создания хранилищ данных, принято сегодня обозначать словом «виртуализация».
Итак, современный этап эволюции систем хранения данных проходит под знаком виртуализации. Слово это звучит и заманчиво, и красиво, но есть в нем и настораживающий оттенок. Как и многие другие модные термины, понятие «виртуализация» чаще всего употребляют не в ясном техническом контексте, а как броский маркетинговый лозунг, удачно подходящий к условиям неопределенности. В итоге само это слово оказалось затертым от слишком частого и не всегда корректного употребления. Его используют и в тех случаях, когда никакой ирреальности или замены одной реальности другой не наблюдается.
Словосочетания virtual memory и virtual storage появились в 1959 году для обозначения виртуальной по своей сути внешней памяти на дисках, используемой для расширения внутренней памяти, которую в ту пору собирали из магнитных сердечников. В этом решении действительно присутствовал элемент виртуальности: маленькую и дорогую память подменяли прозрачным для процессора способом более дешевой и несравненно большего размера. В современных системах хранения никакой подмены нет, и было бы точнее вести речь об интеграции хранения, замене физических адресов и номеров устройств логическими адресами и логическими номерами устройств и о более эффективных методах управления.
Нынешняя ситуация в области корпоративных информационных систем удивительным образом напоминает то, что происходило в 70-е и 80-е годы, когда формировалось понятие «открытые системы», создавалась семиуровневая модель OSI/ISO. Тогда стала очевидной необходимость в общепринятых сетевых стандартах. Сегодня, особенно под влиянием новейших концепций, например, Web-служб, зарождается новый виток спирали развития открытых систем, который сопровождается активными работами в области стандартизации и выработки единого взгляда на инфраструктуру корпоративных информационных систем. Особенно этот процесс активен на уровне «общения» между приложениями. Известные подходы к этой проблеме во многом пока различаются, но все их объединяет то, что задействованные ресурсы, в том числе и ресурсы хранения, объединяются в уровни инфраструктуры. Кто-то ставит выше Adaptive Computer Architecture, кто-то, напротив, — Storage Network Architecture, однако общим является осознание необходимости интеграции ресурсов, в том числе и путем виртуализации.
Пару лет назад новая сетевая парадигма хранения данных была впервые выражена образным, но, к сожалению, не привившимся термином «экосистема хранения» (Storage Ecosystem), который вскоре уступил место маловыразительному названию «виртуализация систем хранения данных». В конечном счете, виртуализация есть ни что иное, как объединение в одном или нескольких массивах всей совокупности разнотипных накопителей и обеспечение прозрачного доступа к ним. Благодаря этому серверы освобождаются от непосредственной привязанности к определенным физическим или логическим устройствам; вместо этого они обращаются к некоему пулу, обладающему требуемым качеством обслуживания (Quality of Service — QoS).
Три мифа
Иногда виртуализацию представляют буквально «магической», которая в состоянии разрешить все проблемы хранения данных. Повышенный интерес к теме виртуализации (в англоязычной литературе используют слово hype, которое переводят как «активная реклама», «пускание пыли в глаза», а то и как «очковтирательство»), породил несколько мифов [1].
Миф № 1: «Виртуализация относится только к внешней памяти». Действительно, в части систем хранения достигнуты наиболее видимые результаты, но только этой областью они не ограничиваются. Виртуализации подвергаются практически все компоненты информационных систем, от интерфейсов до серверов, при этом на первый план выходит использование открытых стандартов. Виртуализация одной только внешней памяти вне общего системного подхода особых преимуществ дать не может, ее ценность заключается в возможности обеспечения прозрачного доступа приложений к данным в рамках многоуровневой системы, построенной по открытым стандартам.
Миф № 2: «Виртуализация относится только к сетям хранения». Новыми технологиями создания симметричных и асимметричных пулов в сетях хранения (SAN — storage area network) виртуализация не ограничивается. Это действительно перспективные технологии и методы, однако уже много лет существуют хорошо известные менеджеры логических томов, работающие на серверах и мэйнфреймах, позволяющие виртуализировать все виды внешней памяти — и DAS (direct attached storage — «устройства хранения, подключаемые напрямую»), и NAS (network attached storage — «устройства хранения, подключаемые к сети»), и SAN. Все это практические технологии сегодняшнего дня.
Миф № 3: «Виртуализация относится только к дисковым накопителям». Помимо дисков есть еще множество других типов накопителей. По мере роста объемов корпоративной информации архивирование данных на вторичных носителях будет развиваться точно так же, как и хранение на первичных. Это вопрос экономический: хранение архивированных данных на вторичных носителях всегда дешевле, чем на магнитных дисках, однако по степени удобства доступ к ним не должен сильно отличаться. Следовательно, задачи виртуализации не должны быть ограничены только первичными накопителями; к архивированным данным, размещенным на вторичных накопителях, точно так же необходимо обеспечить прозрачный доступ, естественно, с другими показателями QoS [2].
Рис. 1. Три уровня виртуализации
Для того чтобы понять, что же такое на самом деле виртуализация систем хранения, нужно ответить всего на два очень простых вопроса, а именно, «что» и «где» подвергается виртуализации. Ответ на первый вопрос прост и однозначен: любые (не только дисковые) накопители могут сливаться в единый пул. Ответ на второй вопрос не столь очевиден. Между данными и приложениями можно выделить три потенциальных уровня, в которых можно реализовать виртуализацию: верхний уровень сервера, средний уровень сети хранения или нижний уровень накопителей (рис. 1). Соответственно с этим возможны три альтернативных решения. Давно известны решения на уровне серверов, довольно широко используются решения на уровне устройств или собственно систем хранения, последнее же слово — виртуализация на уровне сетей хранения.
Виртуализация на уровне сервера
Исторически первым было решение на уровне сервера. Логические менеджеры томов сначала появились на мэйнфреймах, затем Unix-серверах, а в последние годы и на платформах Windows. Они обеспечивают виртуализацию посредством отображения физических устройств в логические, имеющие так называемые логические номера (LUN), делящиеся на логические группы дисков или логические тома. Это дает приложениям возможность монтировать логические тома, не связывая себя с конкретным физическим устройством. Некоторые логические менеджеры позволяют создавать различные программные RAID-массивы, изменять конфигурацию внешней памяти в динамическом режиме, производить замену физического устройства, не оказывая влияния на работу приложений.
Рис. 2. Распределенная система хранения
В простейшем случае речь может идти о виртуализации устройств, подключенных к одному серверу. На этих принципах можно построить распределенную систему хранения предприятия (рис. 2). Иногда такое решение называют решением на уровне программного стека: каждый из серверов обеспечивает виртуализацию того сегмента внешней памяти, который к нему подключен, используя собственный менеджер томов. Однако на одном и том же уровне серверы должны иметь специализированное отображающее программное обеспечение, которое обеспечивает им обмен данными под общим управлением администратора системы. Достоинство такого подхода заключается в том, что он не требует никакого специализированного оборудования. Есть, однако, и существенные ограничения. Если идти этим путем, то ресурсы сети хранения (логические номера устройств) должны быть заранее (вручную) поделены между серверами. Тем самым утрачивается одно из важнейших достоинств, суть виртуализации — полная независимость серверов от накопителей.
Виртуализация на уровне подсистем хранения
На нижнем уровне также возможны различные подходы к виртуализации. С 90-х годов и по сей день на мэйнфреймах используют менеджеры виртуализации (Storage Virtualization Manager), создающие виртуальные тома (Virtual Volume). С переходом к сетям хранения эта идея осталась жизнеспособной, но с ограничениями — для ее реализации требуются однородность самой сети и подсистем хранения. Другой подход называют «SAN из коробки» (SAN-in-a-box); он основан на интегрированном решении, где в одной стойке собраны накопители, системы управления и коммутации. Решение удовлетворяет целям виртуализации — но в пределах «коробки». Примером такого подхода может служить дисковый массив Compaq StorageWorks Modular SAN Array 1000 [3]. (Назвав так в своей статье массив MSA1000, я не был вполне уверен в точности определения, но позже в материале [4] нашел аналогичное название.) Это достаточно простое и элегантное решение, ориентированное на информационные системы небольшого предприятия или подразделения, скажем так, локальная виртуализация со всеми вытекающими из этого достоинствами и недостатками.
Виртуализация на уровне сети хранения
Мэйнстрим, основное течение виртуализации систем хранения, находится именно на этом среднем уровне — уровне SAN. Все, что здесь делается, отличается от описанных выше решений прежде всего большей динамичностью. Любая сеть хранения состоит из двух групп компонентов: функциональных (серверы, накопители) и инфраструктурных (адаптеры, концентраторы, коммутаторы). Для того чтобы реализовать виртуализацию на уровне сети хранения, две эти группы нужно дополнить третьей, которую можно назвать управляющей. Оборудование, которое в нее входит, называют SAN-приставками или SAN-серверами. Это вычислительные устройства, подключаемые к SAN или устанавливаемые на путях передачи данных, которые отвечают за топологию и реализуют абстрагирование данных от их места нахождения. Объединенный пул хранения может быть симметричным (symmetrical pooling, SAN Storage Manager) или асимметричным (asymmetrical pooling, Metadata Server).
Симметричный пул
В контексте симметричного пула хранения используется также выражение In-Band SAN Virtualization; термин in-band буквально переводится как «внутри полосы» и применяется в системах связи для указания всего того, что находится непосредственно в канале передачи, например шума или искажения. В данном случае имеется в виду тот факт, что управляющее устройство, SAN Storage Manager, находится на тракте обмена между серверами и накопителями и потому весь трафик проходит через него. SAN Storage Manager осуществляет «трансляцию» физических устройств в логические. Такого рода устройств выпускается пока немного; в качестве одного из примеров можно указать интеллектуальный коммутатор-маршрутизатор SanBlast, недавно представленный компанией SYRED [5]. Он рассчитан на 16 портов Fibre Channel или Gigabit Ethernet, образует RAID-массивы из простого набора дисков и обеспечивает подключение лент и оптических носителей. SanBlast превращает существующую систему хранения в виртуальный пакет дисков. SanBlast допускает подключение SAN-серверов, работающих под управлением Windows NT, Sun Solaris, HP-UX, Linux, других разновидностей Unix.
К числу очевидных достоинств симметричного решения относится логическая простота; в нем естественным образом имеется единая точка управления и нет необходимости решать проблемы согласования в работе устройств. Кроме того, симметричный пул имеет следующие положительные качества:
* простота установки и администрирования;
* прозрачность для серверов и операционных систем, при использовании серверов приложений не требуются специальные драйверы;
* обеспечение сериализации доступа к данным и потенциальной возможности для разделения доступа к данным между серверами;
* возможность расширения функциональности SAN Storage Manager независимо от серверов и систем хранения.
Рис. 3. Симметричный пулинг
Очевиден и главный недостаток централизованного менеджера — он становится критической точкой с точки зрения надежности системы (рис. 3), следовательно, его кластеризация является обязательной. Столь же естественны и другие слабые стороны:
* размещение даже очень производительного устройства на пути данных вносит задержку;
* при подключении разнотипных серверов и накопителей требуется настройка кэш-памяти SAN Storage Manager;
* внедрение In-Band SAN Virtualization не имеет "обратного действия"; если некоторая информационная система построена с использованием SAN Storage Manager, исключить его из работы чрезвычайно сложно.
Асимметричный пул
Асимметричный пул хранения (Out-of-Band SAN Virtualization) строится с использованием сервера метаданных; данное решение предполагает наличие центральной точки управления и виртуализации с сохранением возможности для прямой связи между серверами и накопителями. Управление сосредоточено в сервере метаданных, где хранится информация о размещении данных. Эти метаданные должны некоторым образом передаваться в серверы. С этой целью на подключенных серверах может быть установлено «кооперативное» программное обеспечение, называемое инсталлируемой (IFS — installable file system) или виртуальной файловой системой (VFS — Virtual File System). В качестве альтернативы в адаптерах шины или программируемых драйверах могут использоваться метаданные об устройствах, к которым они подключены. Оба этих решения могут использоваться по отдельности или совместно.
К числу преимуществ асимметричного пула относятся:
* простота администрирования и наращивания функциональности;
* прозрачность для приложений и операционных систем;
* управление виртуализацией из одной точки;
* минимальное время задержки.
Слабые места:
* решение должно быть кластеризовано;
* для внедрения асимметричного пула (в отличие от симметричного) требуется либо применить администрирование серверов, либо использовать адаптеры шины и драйверы;
* отключение виртуализации затруднено.
Поставщики решений виртуализации
Как это случается во всякой новой области, множество решений предлагают небольшие начинающие фирмы, в том числе DataCore Software, TrueSAN Networks, Bridgewater и ряд других. Практически все крупные производители аппаратного и программного обеспечения также включились в гонку виртуализации. Каждая из этих компаний имеет собственную стратегию в данной области, заслуживающую детального описания. Если попытаться ограничиться несколькими словами, можно дать следующую, не претендующую на полноту характеристику их деятельности.
Compaq
Из числа производителей «первой шеренги» у Compaq, по всей видимости, наибольший опыт и спектр решений, связанных с виртуализацией систем хранения. Корпорация поставляет несколько взаимодополняющих технологий виртуализации, которые относятся ко всем трем уровням. На уровне сервера предлагается хорошо известное программное обеспечение SANworks Virtual Replicator. На уровне системы хранения Compaq производит StorageWorks Enterprise Virtual Array. На уровне сети хранения — Compaq VersaStor, выделенное устройство, обеспечивающее установление соответствия между физическими и логическими адресами хранения. VersaStor выполняет вычисления, необходимые для автоматического перемещения данных в пуле хранения, и пересылает информацию о таблицах отображения агентам, используемым при обращении к данным. В первых версиях агентов были реализованы дополнительные платы, устанавливаемые в серверы; в последующем это будут программные решения.
EMC
В августе 2001 года один из руководителей компании Майк Рюттгерс подчеркнул, что некоторые конкуренты используют слово виртуализация исключительно в рекламных целях: «Если бы мы были более изощренными в маркетинге, нам следовало бы его использовать давно. С 1995 года мы занимаемся тем, что назвали Enterprise Storage, уже в 1998 году мы собрали все необходимое, чтобы создать корпоративную сеть хранения и управлять ею. Виртуализация — просто более абстрактный взгляд на информацию».
В EMC проводят различие между виртуализацией как абстрагированием от данных (data abstraction) в смысле создания общего гигантского пула и концепцией мобильности данных (data mobility), т.е. обеспечением беспрепятственного автоматизированного перемещения информации.
Автоматизация в данном случае представляет собой переход от пассивной среды, хранящей связанные данные, к активной среде, где информация автоматически и незаметно для пользователя перемещается в нужные места. Система Automated Information Storage (AutoIS), в которой воплощены эти идеи, не просто является средством виртуализации, а служит открытым инструментарием для управления хранением. В AutoIS можно обнаружить и то, что называют виртуализацией в чистом виде, т. е. абстрагирование, централизованное управление, однако это инструментарий более широкого профиля. В частности, AutoIS может делать то, что недоступно продуктам, специализирующимся на «чистой» виртуализации, — например, сочетать достоинства виртуализации с поддержкой существующих пользовательских систем, при этом не требуется все начинать с нуля. AutoIS позволяет дать выход интеллектуальным способностям современных накопителей, в то время как в большинстве альтернативных систем используют простые накопители типа JBOD. В конечном счете, AutoIS — это инструментарий автоматизации среды хранения, а не только средство для создания дискового пула.
С позиции EMC, виртуализация хранения или абстрагирование данных — всего лишь одна сторона медали, другая же — мобильность и возможность взаимодействия. Это давняя для компании тема. Еще в 1995 году был выпущен программный продукт Symmetrix Manager. Среди последних разработок EMC можно выделить ControlCenter Open Edition, позволяющий осуществлять мониторинг, конфигурирование и точную настройку ресурсов хранения с единой консоли.
Fujitsu Siemens Computers
Данная компания известна своими работами в области виртуализации ленточных библиотек, например, продукт CentricStor позволяет виртуализовать архив лент. Это устройство еще называют Virtual Tape, поскольку оно позволяет подключать разнотипные ленточные библиотеки, например, Scalar 1000 или Storage-Tek L180, интерпретируя их как одну.
Hewlett-Packard
Стратегия HP в области управления ресурсами хранения данных носит название Federated Storage Area Management (FSAM). В ее рамках компания анонсировала устройство для сетевой виртуализации HP SANlink, позволяющее хранить данные в виде централизованного логического пула. В значительной мере нынешние предложения HP основываются на продуктах недавно купленной компании StorageApps, входившей в круг небольших фирм, которые проявляли наибольшую активность в области виртуализации. В сочетании с собственным набором инструментов управления средствами хранения данных в составе HP OpenView продукт HP SANlink позволяет построить многофункциональную сеть хранения данных, создать новую сеть хранения или расширить уже существующие. SANlink исполняется в стандартной стойке HP41U, а для удаленного мониторинга подключенных к сети систем хранения данных используется отдельно поставляемая система HP SANmaster.
IBM
Намерения этой корпорации отличается мощностью и глобальностью похода. Очень интересное и полное обозрение деятельности IBM в направлении виртуализации хранения можно найти в книге [6].
IBM поддерживает четыре уровня виртуализации. Первый — аппаратный, его можно обнаружить в корпоративных серверах; он позволяет серверам, работающим под управлением ОС Unix или Windows, а также системам AS/400 и S/390 получать доступ к дисководам, не зная их физического адреса. Второй уровень — уровень логических номеров устройств LUN; он поддерживается продуктом Mass Storage Server. Третий реализуется средствами Tivoli SANergy, позволяющими серверам иметь распределенный доступ к файлам в SAN и через шлюз работать с NAS. Четвертый уровень — инициатива Storage Tank.
Storage Tank сочетает в себе черты распределенного решения с особенностями асимметричного пула. И по сравнению с традиционным подключением серверов и рабочих станций к сети хранения по Fibre Channel или iSCSI отличается наличием двух компонентов:
* Storage Tank Server - сервер, администрирующий обмен данными и хранящий метаданные (в данном контексте он выступает именно в роли сервера, снабжающего систему метаданными);
* Installable File System (IFS) - дополнительный компонент файловой системы, устанавливаемый на каждом из подключенных серверов и рабочих станций (эти компьютеры служат клиентами, потребляющими метаданные).
В роли Storage Tank Server может использоваться любая платформа, работающая под управлением ОС IBM AIX, Windows или Linux. Диапазон допустимого оборудования предельно широк: от недорогих Linux-серверов до суперкомпьютеров IBM SP2. Клиентами могут быть любые машины с операционными системами Windows 2000, AIX, Sun Solaris, Linux, HP-UX и др. Обмен данными между клиентом и сервером осуществляется по протоколу IBM Storage Tank Protocol. Согласно нему, для того, например, чтобы открыть файл, клиент распределенной системы хранения Storage Tank должен войти в контакт с Storage Tank Server, получить от него метаданные и права доступа; метаданные сообщают клиенту атрибуты и расположение устройства, а право доступа лимитирует его возможности открытия, чтения и записи в файл. После этого можно выполнить требуемые операции с данными через сеть хранения.
Одна из самых больших сложностей, которую удалось преодолеть при создании Storage Tank, заключается в согласовании средствами распределенных компонентов IFS кэшей каждого из клиентов.
Veritas Software
Эта компания выпускает программные средства виртуализации, рассчитанные на системы высокой готовности. Комплекс продуктов SANPoint Foundation Suite HA поддерживает виртуализацию на уровне томов и файлов. Он включает продукт Veritas Volume Manager, позволяющий множеству узлов сети обращаться к одним и тем же томам. Поддерживаются метаданные и информация об отображении, используемая пользовательскими приложениями. На файловом уровне Veritas поддерживает виртуализацию посредством системы кластеризации файлов Cluster File System, которая позволяет нескольким серверам обращаться к одним и тем же файлам. SANPoint Foundation Suite HA работает на платформе Solaris. Есть еще инструментарий Veritas SANPoint Direct, позволяющий нескольким серверам, оснащенным Windows 2000, обращаться к одним и тем же файлам.
Sun Microsystems
Позиция этой компании по отношению к виртуализации несколько напоминает позицию EMC. Собственно слово «виртуализация» в документах Sun отнюдь не доминирует, но идея интегрированного управления корпоративной системой хранения, реализации которой подчинены все механизмы виртуализации, в полном объеме отражена в инициативе Storage One. Эта инициатива ставит своей целью предложить «полное решение» в области хранения, содержащее в себе все необходимое для надежной и эффективной работы. Storage One состоит из трех уровней; на нижнем уровне находятся дисковые массивы со встроенной кэш-памятью, интерфейсы и коммутаторы, составляющие инфраструктуру сети хранения. Второй уровень образуют средства организации данных, в том числе менеджеры томов и файловые системы. Третий уровень — программные средства управления, обеспечения надежности и готовности.
В развитие StorEdge T3 выпущены две новые дисковые системы — StorEdge 3900 и StorEdge 6900; последняя отличается наличием внутреннего механизма виртуализации. Для этого в StorEdge 6900 установлена пара контроллеров Vicom Storage Virtualization Engine (SVE) производства компании Vicom. Этот тип контроллера построен на основе фирменной архитектуры Vicom Independent Distributed Routing.
Файловая система QFS также несет на себе признаки виртуализации; в ней метаданные хранятся отдельно от пользовательских данных. Полноту решения обеспечивают несколько пакетов управления: StorEdge Availability Suite, StorEdge Performance Suite, StorEdge Utilization Suite и StorEdge Resource Management Suite.
Накопитель Sun StorEdge 6900 оптимизирован для работы с операционной средой Solaris Operating Environment, поддерживающей серверы Sun Enterprise и Sun Fire; при этом обеспечивается и организация совместного пула дисков для других платформ.
Литература
1. Virtualize It: Making Enterprise Data Storage Immediately Accessible. OTG Software
2. Roy Slicker, Jim Wheeler, Storage Virtualization Means More Than One Media. Pegasus Disk Technologies
3. Леонид Черняк, SAN в коробке. "Computerworld Россия", 2002, № 05
4. A New Method of SAN Storage Virtualization, Raidtec Corp.
5. SanBlast: intelligent switch/router unleashed, SYRED
6. Mark Blunden, Mik Berx-Debeys, Daeseop Sim, Storage Networking Virtualization What's it all about? Red Books, 2000
Определения
В трудах ассоциации SNIA дается следующее общее определение.
«Виртуализация — это действие (act) по объединению нескольких устройств, служб или функций внутренней составляющей инфрастуктуры (back-end) с дополнительной внешней (front-end) функциональностью, обеспечивающее целесообразное абстрагирование от внутреннего устройства.
Обычно виртуализация позволяет скрыть от пользователя внутренние сложности и сделать его работу удобнее. Примерами виртуализации являются агрегация нескольких служб в одну или добавление средств безопасности в незащищенную службу. Виртуализация может быть приложена или вложена в многоуровневые системы».
А вот взятое из того же источника определение виртуального устройства: «Виртуальное устройство может быть представлено операционной системе средствами управляющего программного обеспечения, например, менеджера томов. С точки зрения приложения виртуальное устройство идентично физическому. В некоторых случаях возможности виртуальных устройств отличаются от физических, в частности, обычно с виртуального устройства невозможно осуществить первичную загрузку».
Если попытаться перевести это на обычный язык, можно сказать, что предназначение виртуализации состоит в том, чтобы:
* изолировать пользователя (сервер или приложение) от физических ресурсов хранения: программа может не знать реальных адресов или параметров диска;
* изолировать пользователя (сервер или приложение) от изменений в инфраструктуре пользователя корпоративного хранилища данных;
* способствовать организации многопользовательского режима, повышающего эффективность использования ресурсов;
* помочь администратору управлять большими объемами хранения.
* Внедрение виртуализации преследует несколько целей:
* формирование единообразного взгляда на хранение данных вне зависимости от физической природы и топологии систем хранения;
* создание единой точки управления, сосуществующей с аналогичными точками управления серверами, операционными и файловыми системами;
* возможность выбора накопителей, в наибольшей степени соответствующих заданным требованиям QoS и, следовательно, развития и поддержки гетерогенных сетей хранения;
* обеспечение высокой готовности, масштабируемости, безопасности и других эксплутационных показателей.