Как было сделано демо 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

NetApp iSCSI

+ Created 800.1 MB (MegaBytes) LUN at
  /vol/iSCSI/LUN-iSCSI
+ Created iSCSI initiator group 'Ex'
+ Mapped the new LUN to group 'Ex' at the
  lowest available LUN ID

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.

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 и, следовательно, развития и поддержки гетерогенных сетей хранения;
* обеспечение высокой готовности, масштабируемости, безопасности и других эксплутационных показателей.