TechEd Europe 2013 (день 1)

В этом году мне впервые удалось попасть на конференцию Microsoft TechEd Europe, проходящую в Мадриде, Испания, с 25 по 28 июня. Что из этого вышло - читайте далее.

Вступление

Традиционно конференция TechEd Europe проходит в IFEMA – Feria de Madrid Convention Centre.

Регистрация участников проходила во 2-м павильоне, под основную сессию целиком выделили 6 павильон, для  тематических сессий - 4-й и 7-й, выставка партнеров и лабораторные работы - в 8-м, обед - в 10-м.

Вход в выставочный комплекс охраняет группа разноцветных карликовых медведей-телепузиков.

Помня о суматохе первого дня VMworld, я приехал в Мадрид в воскресенье, поэтому было время неспешно побродить по городу и спокойно зарегистрироваться. Сама процедура регистрации заключалась в том, что участнику требовалось подойти к стойке самообслуживания и считать заранее распечатанный номер, после чего получить бейдж и рюкзак с плюшками.

Кстати, по поводу раздаточных материалов - в сравнении с тем же VMworld "сухой паек" выглядит гораздо скромнее - рюкзачок попроще, ни фляжки, ни майки, с другой стороны...

С другой стороны, всем участникам TechEd дали промо-код на получение скидки на покупку планштета Microsoft Surface RT и/или Microsoft Surface Pro. Так, например, Pro версия при цене для простых смертных в 980 евро, обойдется участнику Teched всего в 350 евро, а RT версия, так и вообще в скромные 80 евро. Одна печаль - Microsoft не считает Россию частью Европы, поэтому купить планшет с доставкой на Родину не получится. :-( Тем не менее, настойчивые граждане могу прибегнуть к помощи своих зарубежных друзей/родственников или различных сервисов, предоставляющие услуги виртуальных почтовых адресов (я, кстати, попробовал, посмотрим, что из этого выйдет).

День 1

Конференция началась с пленарного доклада, на котором Brad Anderson, вице-президент Windows Server and System Center Program Management, рассказал о направлениях развития компании. Во главу угла ставятся, конечно же, облачные вычисления и все, что с ними связано. Даже Windows - это теперь не обычная ОС, а самая настоящая Cloud OS. Microsoft рассказала о том, что можно ожидать в новой версии Windows 8.1, в частности такой штуке, как Windows Workspace, которая позволяет управлять пользовательскими BYOD устройствами, не вводя их в домен, и Work Folders - этакий внутренний Skydrive с возможностью интеграции со службами RMS. Много слов было сказано и о Windows Azure, о том, что теперь Microsoft не будет взимать плату за выключенные машины, о том, что перейдет на поминутную тарификацию, о планах открытия новых ЦОД в Китае, Австралии, о том, что подписчики MSDN смогут "бесплатно" получать облако-часы для тестирования своих приложений. Но самое интересное, конечно же, оставили напоследок. Виртуализация Hyper-V шагает семимильными шагами, наступая на пятки главного конкурента, имя VMware в одном предложении упоминается исключительно вместе со словами "очень" и "дорого".

Microsoft очень гордятся, что им удалось побить рекорд VMware, сделанный два года назад на железе HP предыдущего поколения.

Также Microsoft совместно с Oracle заключили партнерское соглашение о поддержке ПО Oracle в виртуальной среде Hyper-V и облаке Azure, что действительно круто и не может не радовать.

Среди нововведений Windows Server 2012 R2 показали работу Storage Tiering, и это, действительно, внушает.

Также обещается, что благодаря технологиям интеллектуального кэширования, можно будет добиться существенного прироста производительности и на дедуплицированных томах. В примере выполняется одновременный запуск 5-и виртуальных машин с обычного тома и с дедуплицированного.

Виртуальную машину, которая выдает миллион IOPS многие должно быть уже видели, поэтому Microsoft показала ВМ выдающая 1.6 миллиона IOPS.

Отдельного упоминания заслуживают технологии сжатия и SMB ove RDMA, позволяющие существенно ускорить процедуру переноса ВМ (Share Nothing Live Migration) с одного хоста виртуализации на другой.

В общем, все выглядит очень круто, и очень хочется надеяться, что работать все будет также, как на картинках (и все бы было хорошо, но именно на этих словах у меня ноутбук упал в BSOD).

Следующая сессия, на которую я попал, "Transform the datacenter" была посвящена тому, как новый Windows Server и ПО линейки System Center позволяют упростить управление облаком.

Так, например, такие рутинные вещи, как создание файлового сервера, презентация SMB шары серверам виртуализации, развертывание нового маршрутизатора для обслуживания виртуальных сетей и создания Site-to-Site VPN туннелей могут быть выполнены из консоли SCVMM 2012 R2. Кроме того, в версии R2 станет возможным централизованного управлять репликацией Hyper-V Replica, а также задавать разные интервалы репликации в зависимости от требований к доступности и сохранности данных.

Также с помощью Windows Azure Hyper-V Recovery Manager (который на текущий момент находится на этапе preview) станет возможным создавать свои планы восстановления, которые позволят автоматизировать процедуру восстановления виртуальной инфраструктуры на случай всевозможных катастроф.

После сессии был обед. Разнообразия особого не было, но покушать всем досталось (и это главное).

Вообще, в плане похавать в первый день TechEd был на весьма достойном уровне, повсюду стояли холодильники с газировкой и соками, а также кофемашины; те, кто пришел с утра пораньше мог позавтракать разнообразными булками и круассанами. Но вернемся к сессиям.

После обеда я попал на VDI Smackdown 2013 Edition, сессию, посвященную тонкостям выбора и внедрения VDI решений. При внедрении решения от любого вендора важно все правильно спранировать, чтобы ваша инфраструктура не была похожа на это:

Особое внимание следует уделять вопросам системы хранения ВМ. Размер - не главное, главное - это IOPS'ы, Latency, способность противостоять Boot Storm, возможности эффективного использования SSD накопителей. В презентации также было уделено внимание современным "модным" технологиям, способным улучшить т.н. User Experience, таким как GPU Sharing/Pass-through, всевозможные технологии кэширования и tier'инга, интеграция с Unified Communication решениями, поддержка HTML5 доступа, Reverse Seamless режима и прочее. В конце было приведено объективное (без кавычек) сравнение трех основных игроков на рынке (Citrix, Microsoft, VMware), а также даны "простые" рекомендации (в кавычках) о том, как лучше всего выбрать то или иное решение (схема решения на рисунке).

На третьей сессии "Windows Azure in the Enterprise" рассказывали как публичное облако Windows Azure может пригодиться в крупных компаниях. Были рассмотрены четыре основные сценария использования Azure:

• Как средство хранения, резервирования и восстановления корпоративных данных. Так, например, Microsoft System Center DPM 2012 SP1 может использовать облако Azure для хранения резервных копий данных. Кроме того, сам Azure позволяет автоматические реплицировать данные между разными локациями для большей надежности.
• В качестве платформы для разработки и тестирования приложений. Azure позволяет создавать изолированные друг от друга виртуальные сети, а также обеспечивает возможность подключения к этим сетям для отдельных сотрудников извне (Point-to-site VPN connection).
• Как средство, позволяющее быстро нарастить вычислительную мощность вашего ЦОД. С помощью заранее преднастроенных шаблонов, приложения могут быть развернуты за считанные минуты, без необходимости залезать "под капот".
• Наконец, Azure может помочь там, где ваш ЦОД не может обеспечить приемлемой скорости подключения - в других странах, на других материках. На сегодняшний момент, ЦОДы Windows Azure присутствуют в регионах западных и восточных Соединенных Штатов, западной Европы, Азии. В ближайшем будущем планируется построить и открыть новые ЦОД.

Последним на сегодня докладом был доклад уровня 400, "Automate Private Cloud Protection and Recovery with Microsoft System Center 2012 - Data Protection Manager", из которого я узнал следующие вещи - в R2 наконец-то обещают сделать онлайн бекап ВМ с ОС Linux (дождались!), что DPM будет поддерживаться внутри ВМ со всеми вытекающими отсюда преимуществами, вроде автоматизации развертывания новых серверов с помощью SCVMM, а также, что SCDPM может быть интегрирован с SCVMM и SCSM через Orchestrator (как всегда в общем), чтобы предоставить потребителям облачных сервисов такую услугу как BaaS (Backup as a Service). Концептуально - вещь довольно интересная, но в реальности придется очень много допиливать SCSM и Orchestrator, чтобы это заработало.

После завершения всех докладов участников ждала небольшая тусовка Welcome Party, на которой все желающие могли выпить, закусить и просто поболтать.

Продолжение в следующей части.

Как можно быстро конвертировать виртуальные диски в LUN на СХД NetApp

Предположим, что вам нужно конвертировать диск, лежащий на NFS хранилище, из формата VMDK в отдельный LUN для подключения к ВМ в режиме Raw Device Mapping или к отдельному физическому серверу с минимальными трудозатратами и без выделения лишнего места на хранилище.

С СХД NetApp это можно сделать с помощью команды lun create, для которой при создании нового LUN нужно указать дополнительную опцию -f <путь_к_существующему_файлу>. Например, команда:
lun create -f /vol/vol1/test02/test02_1-flat.vmdk -t windows_2008 /vol/vol1/lun1

создаст файл LUN  /vol/vol1/lun1, указывающий на существующий .vmdk файл.

Поскольку созданный файл LUN (/vol/vol1/lun1) не является полной копией, а содержит лишь служебную информацию и указатели на исходный файл, то перед выполнением команды убедитесь, что vmdk диск находится на нужном томе и отключен ото всех виртуальных машин.

После создания LUN может быть презентован любому серверу по протоколу FC или iSCSI. Также можете удалить ставший ненужным файл настроек .vmdk (не перепутайте с файлом данных виртуального диска -flat.vmdk, его удалять ни в коем случае нельзя).

Аналогичную операцию можно провернуть с VHD дисками (но только с Fixed дисками), размещенными на CIFS шаре. Важным отличием от VMDK дисков является то, что для VHD служебная информация хранится вместе с данными в одном файле, поэтому перед тем, как создать LUN было бы неплохо ее удалить. Согласно спецификации VHD файла, для служебной информации отводятся последние 512 байт, удалить их можно с помощью простого скрипта на Powershell:

$filepath = "C:\stor01\testdisk3.vhd" #где $filepath - путь к vhd файлу

$file = [IO.File]::OpenWrite($filepath)

$file.SetLength($file.Length - 512)

$file.Close()

$file.Dispose()

После этого можете создавать LUN и презентовать его серверам:
lun create -f /vol/vol1/test03/testdisk3.vhd -t windows_2008 /vol/vol1/lun3

Баг работы Windows Server 2008 R2 с русским MUI и VMware Customization Specifications

Сегодня натолкнулся на неприятный баг, связанный с отработкой Customization Specifications в VMware vCenter Server 5.1 при развертывании виртуальной машины Windows Server 2008 R2 SP1 из шаблона с установленным русским языковым пакетом.

После развертывания ВМ не происходит запуск Sysprep, кроме того, отключаются виртуальные сетевые адаптеры (снимаются флажки Connected и Connect at power on в свойствах ВМ), а журнале событий приложений появляется множество предупреждений с Event ID 1000, связанных с ошибками работы VMware Tools.

Происходит это только в том случае, когда в качестве языка для системной учетной записи и экрана входа в систему установлен русский язык. Для других учетных записей, в том числе для записи Administrator, смена языка не приводит к ошибке.

P.S. Аналогичный баг проявляется при использовании русской локализованной версии ОС Windows Server 2008 или 2012. Решение - установить английский MUI и поменять системный язык на английский.

Настройка Site-to-Site IPsec VPN между VMware vCloud Director и Microsoft Windows Server

VPN туннели являют эффективным механизмом, позволяющим объединить несколько удаленных сайтов в единую маршрутизируемую сеть, и передавать данные, используя защищенные каналы организованные поверх сети Интернет.

Неотъемлемой частью "облачных" инфраструктур, построенных на продуктах VMware vCloud, является VMware Edge, входящий в состав VMware vCloud Networkin & Security, также известный как VMware vShield).

VMware Edge предоставляет возможность организации IPSec Site-to-Site VPN туннелей как с другими серверами Edge, так и с программным обеспечением и оборудованием сторонних производителей, например, Cisco ASA или Microsoft TMG. Однако, в некоторых случаях, функции VPN сервера может взять на себя и обычный сервер с установленной ОС Windows Server.

В качестве примера рассмотрим настройку VPN туннеля между двумя сайтами (site1 и site2). В первом сайте используется подсеть 192.168.10.0 / 24 и установлен выделенный сервер Windows Server 2008 R2 с доступом в Интернет (в примере подсеть 192.168.1.0 / 24). Во втором сайте используется подсеть 192.168.20.0 / 24 и развернут сервер VMware Edge, у которого также есть прямой доступ в Интернет.

Настройка Edge сервера

При развертывании Edge сервера в виртуальном ЦОД организации все настройки VPN туннелей должны выполняется только из консоли vCloud Director, т.к. настройки, выполняемые из vShield Manager, не синхронизируются с БД vCloud Director и могут быть перезаписаны.

Откройте консоль управления vCloud Director. Войдите в систему в качестве системного администратора или администратора организации. Перейдите во вкладку администрирования (Administration), в списке слева выберите нужный виртуальный ЦОД (Virtual Datacenters) и перейдите на вкладку Edge Gateways.

Выберите нужный сервер Edge, щелкните правой кнопкой мыши и выберите Edge Gateway Services.

Перейдите на вкладку VPN и включите поддержку VPN на сервере, выбрав Enable VPN.

Нажмите кнопку Add для создания нового VPN туннеля.

В окне Add a Site-to-Site VPN configuration задайте имя (Name) туннеля, а также описание (Description).

В списке Establish VPN to выберите a remote network.

В списке Local Networks выберите локальную сеть, подключенную к серверу Edge, для которой требуется организовать VPN туннель.

В поле Peer Networks укажите в формате CIDR (например, 192.168.10.0/24) удаленную сеть, подключенную к Windows Server, до которой требуется организовать VPN туннель.

Если сервер Edge подключен к нескольким внешним (External) сетям, то в списке Local Endpoint выберите внешнюю сеть, через которую Edge будет подключаться к серверу Windows Server.

В поле Local ID укажите IP адрес внешнего интерфейса Edge сервера.

Примечание: В некоторых случаях Edge сервер может быть подключен к Интернет не напрямую, а находиться за NAT устройством, которое осуществляет проброс необходимых портов для организации VPN. В любом случае, в данном поле указывается IP адрес внешнего интерфейса Edge сервера, неважно, из публичного или из частного диапазона.

В поле Peer ID укажите IP адрес внешнего интерфейса Windows Server.

Примечание: В некоторых случаях удаленный Windows Server может быть подключен к Интернет не напрямую, а находиться за NAT устройством, которое осуществляет проброс необходимых портов для организации VPN. В любом случае, в данном поле указывается IP адрес внешнего интерфейса Windows Server'а сервера, неважно, из публичного или из частного диапазона. 

В поле Peer IP задайте IP адрес внешнего интерфейса Windows Server.

Примечание: В случае, если удаленный сервер находится за NAT устройством, данном поле потребуется ввести IP адрес внешнего интерфейса NAT устройства.

В списке Encryption protocol выберите протокол шифрования. Edge сервер поддерживает протоколы шифрования AES-256 (256 бит), AES (128 бит) и 3DES (192 бита). В качестве примера здесь и далее используется протокол шифрования 3DES.

Выберите Show key для показа общего ключа. Скопируйте общий ключ, т.к. он потребуется при настройке Windows Server.

При необходимости измените значение MTU во избежание фрагментации пакетов из-за ограничений внешнего канала.

Нажмите OK для создания VPN туннеля.

Нажмите OK еще раз для сохранения настроек. Если все все было сделано правильно, то после повторного открытия окна Edge Gateway Services на вкладке VPN появится новый туннель.

Не забудьте настроить брандмауэр Edge на вкладке Firewall. Для тестовых целей вы можете разрешить весь входящий и исходящий трафик, выбрав Default action: Allow, или отключив брандмауэр.

На этом настройки со стороны Edge сервера закончены.

Настройка Windows Server

Для корректной маршрутизации трафика между внутренней сетью и виртуальным интерфейсом на сервере Windows Server должна быть установлена роль Network Policy and Access Services.

Сделать это можно из консоли Server Manager или из командной строки, выполнив команды:
dism /online /enable-feature /featurename:RasServerAll 
dism /online /enable-feature /featurename:RasRoutingProtocols

Откройте оснастку управления Routing and Remote Access. Щелкните по имени сервера правой кнопкой мыши и выберите Configure and Enable Routing and Remote Access.

В мастере настройки в главном окне нажмите Next.

В окне Configuration выберите Custom configuration и нажмите Next.

В окне Custon Configuration выберите LAN routing и нажмите Next.

Нажмите Finish для применения настроек.

Запустите службу, нажав Start service.

Настройки IPsec VPN туннелей в Windows Server выполняются из оснастки Windows Firewall with Advanced Security или командной строки.

Запустите оснастку.

Щелкните по корню Windows Firewall with Advanced Security on Local Computer правой кнопкой мыши и в контекстном меню выберите Properties.

В открывшемся окне перейдите на вкладку IPsec Settings и в области IPsec defaults нажмите кнопку Customize.

В окне Customize IPsec Settings в области Key exchange (Main Mode) выберите Advanced и нажмите кнопку Customize.

С помощью кнопки Remove удалите все существующие варианты согласования, а затем с помощью кнопки Add добавьте режим со следующими настройками:
Integrity algorithm: SHA-1
Encryption algorithm: 3DES
Key exchange algorithm: Diffie-Hellman Group 2
Остальные настройки оставьте по умолчанию.

Примечание: Алгоритмы шифрования на Windows Server и сервере Edge должны совпадать.

Нажмите OK для сохранения настроек.

В окне Customize IPsec Settings в области Data Protection (Quick Mode) выберите Advanced и нажмите кнопку Customize.

В окне Customize Data Protection Settings выберите Require encryption for all connection security rules that use these settings.

С помощью кнопки Remove удалите все существующие варианты согласования, а затем с помощью кнопки Add добавьте режим со следующими настройками:
Protocol: ESP
Encryption algorithm: 3DES
Integrity algorithm: SHA-1
Остальные настройки оставьте по умолчанию.

Примечание: Алгоритмы шифрования на Windows Server и сервере Edge должны совпадать.

Нажмите OK для сохранения настроек.


Нажмите OK для сохранения настроек еще раз.

Нажмите OK в третий раз.

Щелкните правой кнопкой мыши по Connection Security Rules и в контекстном меню выберите New Rule.

В мастере создания правил на главной странице выберите Tunnel и нажмите Next.

На странице Tunnel Type выберите Custom configuration и No. Send all network traffic that matches this connection security rule through the tunnel. Нажмите Next.

На странице Requirements выберите Require authentication for inbound and outbound connections. Нажмите Next.

На странице Tunnel Endpoints в списке Which computers are in Endpoint 1 с помощью кнопки Add добавьте локальную сеть, подключенную к Windows Server, для которой требуется организовать VPN туннель.

Помните, что конфигурация Windows Server является зеркальным отражением конфигурации Edge и здесь локальные и удаленные IP адреса и подсети меняются местами.

В поле What is the local tunnel endpoint с помощью кнопки Edit укажите IP адрес внешнего интерфейса Windows Server.

В поле What is the remote tunnel endpoint с помощью кнопки Edit укажите IP адрес внешнего интерфейса сервера Edge.

в списке Which computers are in Endpoint 2 с помощью кнопки Add добавьте удаленную сеть, подключенную к серверу Edge, до которой требуется организовать VPN туннель.

Нажмите Next.

На странице Authentication Method выберите режим Advanced и нажмите кнопку Customize.

В окне Customize Advanced Authentication Methods с помощью кнопки Remove удалите все существующие варианты аутентификации, а затем с помощью кнопки Add добавьте режим со следующими настройками:

Select the credential to use for first authentication: Preshared key

Укажите общий ключ, сохраненный ранее при настройке сервера Edge.

Примечание: Общий ключ на Windows Server и сервере Edge должен совпадать.

Нажмите OK для сохранения настроек.


Нажмите Next.

На странице Profile нажмите Next.

На странице Name задайте имя (Name) и описание (Description) создаваемого правила.

Нажмите Finish для завершения создания правила.

Осталось сделать самую малость.

Для всех туннелей, создаваемых на сервере Edge, по умолчанию включен perfect forward secrecy. В свою очередь, для туннелей, создаваемых в Windows Server режим perfect forward secrecy выключен. По этой причине два сервера не могут согласовать настройки безопасности на второй фазе (Quick Mode). Исправить это можно, включив PFS на Windows Server.

Для этого откройте консоль CMD. Вам потребуется отредактировать созданное правило, используя команду netsh. Формат команды:
netsh advfirewall consec set rule name="Tunnel to vCloud" new qmpfs=dhgroup2
, где  "Tunnel to vCloud" - имя правила.
qmpfs=dhgroup2- включает режим PFS.

Посмотреть имя правила можно в оснастке Windows Firewall или с помощью команды:
netsh advfirewall consec show rule name=all

Настройки закончены, можно приступать к проверке.

Проверка работы

.Для проверки можно использовать клиентские машины, развернутые в каждом из сайтов и утилиту ping.

Перед проверкой, убедитесь, что на клиентах и на сервере Edge настроен брандмауэр и разрешен трафик ICMP.

Пропингуйте компьютер в удаленной подсети.

Все работает.

В оснастке управления Windows Firewall в Security Associations Main Mode и Quick Mode должны появиться записи о первой и второй фазах IPsec.

Примечание: Если на Windows Server в RRAS включить функцию NAT сервера, то перестает корректно работать маршрутизация трафика через VPN туннель.

Проблема совместимости Microsoft Windows NAT и VMware VMXNET3

Недавно столкнулся с неприятной проблемой. При попытке поднять в виртуальной машине VMware ESXi 5.1 с установленной ОС Windows Server 2008 R2 SP1 стандартную роль NAT сервера, интерфейсы сервера переставали пинговаться, и NAT не работал.


Испробовав все варианты, которые только возможно: перезагрузка ВМ, обновление VMware Tools, проверка настроек виртуального коммутатора, установка обновлений ОС, перезагрузка хоста, пересоздание ВМ, и отчаявшись, я решил попробовать сменить тип виртуального адаптера с VMXNET3 на E1000, и, о чудо, все заработало!

По всей видимости, проблема давно известна, и не я один от нее страдаю. А воз и ныне там.

Особенности использования VMware Enhanced vMotion

Начиная с VMware vSphere 5.1 появился механизм Enhanced vMotion, позволяющий переносить виртуальные машины с одного хоста на другой без необходимости использования общего хранилища (datastore).

Важным плюсом Enhanced vMotion является то, что он доступен в редакции vSphere Essentials Plus и выше, что позволяет переносить ВМ с одного хранилища на другое без остановки даже при отсутствии Storage vMotion.


Однако, когда я решил попробовать перенести ВМ, работающую на хосте ESXi, на другое хранилище, то получил ошибку.

Система ясно написала, что функционал Storage vMotion не поддерживается данной редакцией.

Причина проблемы нашлась быстро. Оказывается, если при выполнении Migrate оставить ВМ на том же хосте, но выбрать новое хранилище, то vCenter попытается выполнить Storage vMotion. Решение простое - если хочется перенести диски ВМ с одного хранилища на другое, то в мастере переноса надо не только выбрать новое хранилище, но и новый хост ESXi.

После этого перенос запускается и отрабатывает корректно.

SAN Backup виртуальных машин на примере Symantec Backup Exec 2012

При резервном копировании виртуальных машин в инфраструктуре VMware vSphere могут использоваться различные механизмы, например VADP, Change Block Tracking, Snapshot'ы. Но при использовании RDM дисков (подключаемых напрямую в ВМ, например, больших файловых серверов или узлов кластера с общими дисками) все это перестает работать и администратору по старинке приходится ставить внутри гостевой ОС агента и копировать данные по локальной сети.

Одним из вариантов решения данной проблемы является SAN бекап, который позволяет СРК получать доступ к данным напрямую с СХД, не нагружая производственный сервер. В случае использования выделенной SAN сети, например, в случае с Fibre Channel, это также позволяет снизить нагрузку на локальную сеть и ускорить выполнение резервного копирования.

Помимо резервного копирования физических серверов, данный вариант также может использоваться для резервного копирования ВМ, к которым подключены диски в режиме Physical RDM.

В общем виде, SAN бекап выполняется следующим образом:
1) Резервируемый сервер инициализирует создание VSS снимка файловой системы диска, расположенного на СХД
2) Сервер также создает снапшот этого тома на СХД.
3) СРК копирует необходимые данные напрямую из снапшота, минуя резервируемый сервер. Сразу после создания снапшота сервер может продолжать работу в обычном режиме, это никак не помешает СРК копировать данные.
4) После завершения резервного копирования снапшот с СХД удаляется.

В качестве примера рассмотрим настройку Host Offload Backup для СРК Symantec Backup Exec 2012 с использованием хранилища HP P2000fc G3 MSA.

Backup Exec поддерживает различные СХД в режиме Host Offload Backup, полный список можно найти здесь: Backup Exec 2012 Hardware (HCL).

Перед началом настройки проверьте зонирование на FC коммутаторах. А также убедитесь, что необходимые тома презентованы серверу приложений. В случае виртуальной машины, том должен быть презентован в режиме Physical RDM, а контроллер, к которому подключен диск, переведен в режим Physical SCSI Bus Sharing.

При необходимости настройте Multipath I/O на СРК (инструкция по настройке доступна тут).Также проверьте, что на СХД разрешено создание снапшотов для томов и есть свободное место.

Для корректного создания VSS снапшотов и снапшотов дисков на СХД потребуется установить HP P2000/MSA2000 VSS Provider for Windows на сервер резервного копирования, а также на резервируемый сервер.

Требуется загрузить и установить в указанном порядке следующие компоненты (инструкция по установке доступна тут):

• MSA2000 Family CAPI Proxy
• MSA2000 Family VDS Hardware Provider
• MSA2000 Family VSS Hardware Provider

Все компоненты доступны для загрузки с сайта HP. Если вы устанавливает данные компоненты внутри ВМ, то можете получить сообщение об ошибке.

Обойти это можно, предварительно распаковав файлы дистрибутива в какую-нибудь папку.

После завершения установки, при необходимости, перезагрузите СРК и резервируемый сервер. Проверить корректность установки можно, выполнив команду vssadmin list providers. В списке доступных провайдеров должен появиться "HP StorageWorks P2000/MSA2000 VSS Provider".

После завершения всех подготовительных процедур можно переходить к настройке СРК.

Для резервного копирования по SAN требуется, чтобы на сервере была установлена опция Advanced Disk-based Backup Option. Установить ее можно из главного меню: Installation and Licensing -> Install Options and Licenses on this Backup Exec Server.

Учтите, что опция Advanced Disk-based Backup Option требует отдельного лицензирования.

После установки, создайте новое задание или отредактируйте существующее задание резервного копирования. В настройках задания на вкладке Advanced Disk-based Backup выберите Use offhost backup to move backup processing from the remote computer to the Backup Exec server.

На этом настройка закончена. Можете запустить задание и проверить работу SAN бекапа. В процессе выполнения задания можно видеть, как на СХД создается снапшот резервируемого тома.

Для сравнения скорость копирования по локальной сети.

Скорость копирования по SAN.

P.S. Важное замечание: В приведенном примере СРК должен быть физической машиной с подключением к SAN сети. Если Backup Exec установлен внутри ВМ, то при попытке выполнить SAN бекап вы получите сообщение об ошибке о невозможности создать и подключить снапшот тома.

P.P.S. Схожим образом может быть настроен бекап с другими системами хранения, в том числе и по iSCSI, например, в тестовых целях я настраивал бекап с HP P4000 VSA.