Наилучшие методы использования систем ... · 2017-01-16 ·...

NETAPP TECHNICAL REPORT

Наилучшие методы использования систем хранения NetApp для решений виртуализации Microsoft HyperV Chaffie McKenna, NetApp Ravi B, NetApp Декабрь 2009 | TR‐3702‐1209

Версия 3.0

Коротко о главном

Этот документ содержит руководство и описания наилучших методов для построения интегрированной архитектуры и внедрения Microsoft® Hyper‐V с использованием систем хранения NetApp®. Технологии NetApp, рассматриваемые в этом руководстве важны для создания эффективного с точки зрения затрат, производительности, гибкости и дружественности к окружающей среде интегрированного решения хранения данных виртуальной серверной инфраструктуры.

Оглавление 1 Конфигурирование серверов ................................................................................................................. 5

1.1 Конфигурирование Microsoft Hyper‐V R2 ....................................................................................... 5

1.2 Конфигурирование MS System Center Virtual Machine Manager .................................................. 5

2 Конфигурирование сети .......................................................................................................................... 7

2.1 Сетевые аспекты сервера Hyper‐V .................................................................................................. 7

2.1.1 Физические сетевые интерфейсы ........................................................................................... 7

2.1.2 Виртуальные сети.................................................................................................................... 11

2.1.3 Поддержка новых сетевых возможностей ........................................................................... 11

2.1.4 Стандарты сетевого именования .......................................................................................... 13

2.1.5 Порядок биндинга сетевых адаптеров и значения Metric .................................................. 15

2.2 Вопросы построения кластерной сети Hyper‐V ........................................................................... 16

2.2.1 Рекомендации перед конфигурированием ......................................................................... 16

2.2.2 Рекомендации после конфигурирования ............................................................................. 17

2.2.3 Именование кластерных сетей .............................................................................................. 18

2.2.4 Конфигурирование кластерных сетей ................................................................................... 18

2.2.5 Cluster Network Metrics ........................................................................................................... 19

2.3 Вопросы построения сети хранения ............................................................................................. 21

2.3.1 Сеть хранения Fibre Channel .................................................................................................. 21

2.3.2 IP‐сеть хранения ...................................................................................................................... 22

2.3.3 Masking и Zoning ...................................................................................................................... 24

3 Конфигуирование системы хранения .................................................................................................. 25

4 Использование системы хранения ...................................................................................................... 27

4.1 Программы и утилиты NetApp ...................................................................................................... 27

4.1.1 NetApp Windows Host Utilities Kit ........................................................................................... 27

4.1.2 Multipathing/MPIO .................................................................................................................. 27

4.1.3 NetApp SnapDrive for Windows ............................................................................................... 30

4.2 Распределение пространства ........................................................................................................ 31

4.2.1 Aggregates ................................................................................................................................ 31

4.2.2 Тома типа Flexible .................................................................................................................... 32

4.2.3 LUN ........................................................................................................................................... 33

4.3 Локальные диски (DAS) или сетевая система хранения (SAN) для Microsoft Hyper‐V Server .. 36

4.3.1 Traditional Volume ................................................................................................................... 36

4.3.2 Standard Cluster Volume .......................................................................................................... 36

4.3.3 Cluster Shared Volume (CSV) .................................................................................................... 37

4.4 Распределение места под виртуальную машину ........................................................................ 47

4.4.1 Виртуальные жесткие диски (VHD) ....................................................................................... 47

4.4.2 Диски типа Pass‐Through ........................................................................................................ 48

4.4.3 Диск, презентуемый непосредственно в VM OS .................................................................. 48

4.4.4 Виртуальные дисковые устройства: IDE vs. SCSI ................................................................... 49

4.4.5 Integration Services .................................................................................................................. 50

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

4.4.7 Планирование виртуальной машины ................................................................................... 51

4.4.8 Выравнивание дисков виртуальной машины ...................................................................... 52

5 Увеличение эффективности и гибкости хранения .............................................................................. 59

5.1 Thin Provisioning .............................................................................................................................. 60

5.1.1 LUN в режиме Thin Provisioned .............................................................................................. 61

5.1.2 Volume AutoSize ....................................................................................................................... 61

5.1.3 Snapshot AutoDelete ................................................................................................................ 62

5.1.4 LUN Fractional Reserve ............................................................................................................. 62

5.2 Дедупликация NetApp ................................................................................................................... 62

5.2.1 Некоторые детали о процессе дедупликации ..................................................................... 63

5.2.2 Включение дедупликации ..................................................................................................... 63

5.3 NetApp FlexClone ............................................................................................................................. 63

5.3.1 Что такое FlexClone ................................................................................................................. 64

5.3.2 Создание тома FlexClone ........................................................................................................ 64

5.4 NetApp Snapshot ............................................................................................................................. 65

5.4.1 Что такое снэпшоты ................................................................................................................ 66

5.4.2 Создание снэпшотов ............................................................................................................... 66

5.4.3 Snapshot List/View ................................................................................................................... 67

6 Создание виртуальной машины ........................................................................................................... 68

6.1 Концепция создания ...................................................................................................................... 68

6.2 Процесс создания виртуальной машины ..................................................................................... 69

6.2.1 Подготовка эталонной виртуальной машины ...................................................................... 69

6.2.2 Клонирование эталонной виртуальной машины ................................................................. 71

6.2.3 Provision Virtual Machines ....................................................................................................... 72

7 Резервное копирование и восстановление ........................................................................................ 72

7.1 Концепции резервного копирования и восстановления ............................................................ 72

7.1.1 Технологии снэпшотов ........................................................................................................... 73

7.1.2 Конфигурирование виртуальной машины ........................................................................... 73

7.2 Резервное копирование с использованием NetApp Snapshot ................................................... 74

7.2.1 Резервное копирование отдельной виртуальной машины ................................................ 75

7.2.2 Резервное копирование Clustered Virtual Machine .............................................................. 78

7.3 Восстановление с помощью NetApp Snapshots ........................................................................... 78

7.3.1 Восстановление отдельной виртуальной машины .............................................................. 79

7.3.2 Восстановление в случае Clustered Virtual Machine ............................................................. 83

8 Катастрофоустойчивость и высокая доступность ............................................................................... 83

8.1 Концепции непрерывности бизнеса ............................................................................................ 84

8.1.1 Снэпшоты NetApp .................................................................................................................... 84

8.1.2 Тома NetApp FlexClone ............................................................................................................ 85

8.1.3 Дедупликация NetApp ............................................................................................................ 85

8.2 NetApp SnapMirror .......................................................................................................................... 85

8.2.1 Ключевые технические концепции ....................................................................................... 87

8.2.2 Репликация с использованием NetApp SnapMirror ............................................................. 88

8.2.3 Катастрофоустойчивость с использованием NetApp SnapMirror ....................................... 91

9 Управление и наблюдение ................................................................................................................... 93

9.1 Наблюдение за использованием пространства хранения с помощью NetApp Operations Manager .................................................................................................................................................. 93

9.2 Управление изменением размеров хранилища ......................................................................... 93

10 Выводы ................................................................................................................................................. 95

Приложение A: Пример скрипта создания VM ....................................................................................... 96

Приложение B: Пример скрипта резервного копирования снэпшота ................................................. 98

Приложение C: Пример скрипта восстановления из снэпшотов .......................................................... 99

Приложение D: Пример скриптов катастрофоустойчивого решения ................................................... 99

Приложение E: Благодарности и ссылки ............................................................................................... 103

Приложение F: Версии документа ......................................................................................................... 105

1 Конфигурирование серверов

1.1 Конфигурирование Microsoft HyperV R2 Microsoft Hyper‐V это продукт серверной виртуализации от компании Microsoft, который использует 64‐битный гипервизор, и поставляется в standalone‐версии как отдельный продукт, Hyper‐V Server 2008 R2, также как и компонент всех редакций Windows® Server 2008 R2.

Windows Server 2008 Hyper‐V позволяет вам оптимизировать ваши затраты на серверное оборудование, обеспечивая масштабируемое, надежное и безопасное решение для построения виртуализационной платформы, для консолидации систем различных ролей, как отдельных виртуальных машин (VMs), работающих в единой физической машине. Типичные сценарии внедрения виртуализации Microsoft Hyper‐V включают в себя динамические центры обработки данных, консолидацию серверов, выполнение задач тестирования и разработки, и управление непрерывностью бизнеса. Для полного списка поддерживаемых в Hyper‐V гостевых OS (guest OS), смотрите страницу Virtualization with Hyper‐V: Supported Guest Operating Systems. При инсталляции MS Hyper‐V, NetApp советует вам следовать рекомендациям Microsoft.

Для включения Hyper‐V в полной инсталляции Windows Server 2008 R2, проконсультируйтесь и следуйте указаниям этих ресурсов:

• «Install the Hyper‐V Role on a Full Installation of Windows Server 2008» на Microsoft TechNet

• NetApp Implementation Guide for Microsoft Virtualization (TR‐3733)

Для включения Hyper‐V в версии server core сервера Windows Server 2008 R2, следуйте указаниям этих ресурсов:

• «Install the Hyper‐V Role on a Server Core Installation of Windows Server 2008» на Microsoft TechNet

• NetApp Implementation Guide for Microsoft Virtualization (TR‐3733)

Для конфигурирования Hyper‐V Server 2008 R2, следуйте указаниям:

• Microsoft Hyper‐V Server 2008 Configuration Guide

Когда Hyper‐V будет успешно инсталлирован, вам придется искать ответы на множество дополнительных вопросов, от конфигурирования виртуальных сетей, до понимания перспектив дальнейшего конфигурирования Hyper‐V, и многого другого. NetApp советует в этих вопросах следовать соответствующим рекомендациям Microsoft, и искать ответы на вопросы, связанные с Hyper‐V, на веб‐сайте Microsoft, где есть на эту тему имеется множество полезной информации.

1.2 Конфигурирование MS System Center Virtual Machine Manager Microsoft System Center Virtual Machine Manager (SCVMM), это компонент семейства продуктов Microsoft System Center. SCVMM позволяет управлять гетерогенной средой, как физической, так и виртуальной, с одного «экрана». SCVMM 2008 R2 поддерживает управление хостами Hyper‐V и их виртуальными машинами, равно как и хостами VMware® и ее виртуальными машинами, и предлагает множество других важных инструментов виртуализации. Кроме этого, SCVMM может

http://www.microsoft.com/windowsserver2008/en/us/hyperv-supported-guest-os.aspx

http://technet.microsoft.com/en-us/library/cc794929(WS.10).aspx

http://www.netapp.com/us/library/technical-reports/tr-3733.html




http://www.microsoft.com/downloads/details.aspx?FamilyId=E1E111C9-FA69-4B4D-8963-1DD87804C04F&displaylang=en

быть сконфигурирован для интеграции с Systems Center Operations Manager 2007 для обеспечения мониторинга хост‐серверов и их виртуальных машин.

Проконсультируйтесь с руководством Infrastructure Planning and Design Guide for System Center Virtual Machine Manager 2008 R2 перед развертыванием SCVMM 2008 R2. Предельно важно прочитать и понять данное руководство, так как требуется принятие ряда ключевых решений до того, как вы начнете развертывание SCVMM 2008 R2, включая то, использовать ли SAN с SCVMM 2008 R2. Блок‐схема принятия решения, приведенная на рисунке 1‐1, содержит информацию, взятую из руководства Infrastructure Planning and Design Guide, и показывает многие из вопросов и задач, которые следует принять во внимание и выполнить перед тем, как начинать собственно развертывание

Вдобавок, для поддержки определенных возможностей SCVMM 2008 R2, связанных с конфигурацией SAN, существуют определенные шаги, которые также следует пройти. Для подробностей смотрите документ Configuring a SAN Environment for VMM в Microsoft TechNet. Одним из шагов для успешного конфигурирования SCVMM 2008 R2 с использованием SAN, является установка Virtual Disk Service (VDS) Hardware Provider.

http://go.microsoft.com/fwlink/?LinkId=160869

http://go.microsoft.com/fwlink/?LinkId=160869

http://technet.microsoft.com/en-us/library/cc764269.aspx

Figure 1‐1 Блок‐схема принятия решения по развертыванию SCVMM

NetApp Best Practice Recommendation NetApp рекомендует вам сконфигурировать один том FlexVol® и LUN как описано в этом TR, с достаточным объемом пространства, для размещения там библиотечных компонент, и использовать его для SCVMM library. Сделав так, вы минимизируете потребный объем ресурсов, занимаемый на локальном сервере библиотекой SCVMM, и сможете использовать преимущества и возможности системы хранения NetApp, более эффективно управляя данными SCVMM library.

Для более подробного рассмотрения темы установки Microsoft System Center Virtual Machine Manager (SCVMM) 2008 R2, смотрите главу 3.3.3 SCVMM 2008 R2 Installation в документе NetApp Implementation Guide for Microsoft Virtualization (TR‐3733), и следуйте описанной там пошаговой инструкции по установке компонентов сервера SCVMM, и консоли администрирования SCVMM. Кроме этого прочтите документ New Installation of VMM на Microsoft TechNet.

2 Конфигурирование сети Доступность приложений и данных непрерывно, круглые сутки, ‐ это критически важный аспект работы современной информационной системы промышленного уровня. Поэтому столь важно спланировать не только начальную инсталляцию новой сетевой инфраструктуры, или обновление уже существующей, но также спланировать возможные дополнительные ее элементы. Внедрение системы серверной виртуализации добавляет в инфраструктуру значительное число дополнительных сетевых портов, поскольку каждый сервер Hyper‐V часто использует от 4 и более физических портов сетевых адаптеров, а виртуальные машины также добавляют дополнительные порты в сеть. Хотя сетевые адаптеры в VM и виртуальны, как виртуальны сетевые коммутаторы, реализованные внутри гипервизора, они также требуют внимания и управления. Все эти новые порты, и новые опции виртуальных сетей, часто значительно расширяют имеющуюся сетевую инфраструктуру, и требуют для себя заметных усилий при планировании.

2.1 Сетевые аспекты сервера HyperV

2.1.1 Физические сетевые интерфейсы Как уже упоминалось выше, большинство серверов Hyper‐V используют четыре и более физических сетевых адаптера, которые используются, для сети управления, соединения виртуальных машин, сети IP storage, кластера Windows failover cluster (WFC) для его heartbeat, возможностей live migration, и соединения с cluster shared volume (CSV). Небольшие системы требуют, по меньшей мере, 2‐3 сетевых адаптера, системы большего размера – по меньшей мере, 4‐5 сетевых адаптеров. Давайте рассмотрим, что именно требует такого количества физических адаптеров.

• Hyper‐V management: Microsoft всегда рекомендует, чтобы parent partition Hyper‐V, то есть хост‐система (также известная как management operating system или MOS) имела выделенный физический сетевой адаптер для задач управления сервера Hyper‐V. Связь необходима для удаленного управления сервером Hyper‐V и любыми VM, которые на нем размещаются, с другой системы, или через SCVMM, кроме этого вам стоит рассмотреть вариант использовать NIC teaming для обеспечения отказоустойчивости. Для подробностей смотрите статью Configuring Virtual Networks на Microsoft TechNet.

• Виртуальные машины: могут передавать данные по внешней (external), внутренней (internal) или частной (private) виртуальной сети, что реализовано через parent partition




http://technet.microsoft.com/en-us/library/cc816585%28WS.10%29.aspx

(хост‐OS) сервера Hyper‐V. Каждый созданный внешний виртуальный коммутатор должен быть привязан к индивидуальному физическому сетевому адаптеру, или логическому сетевому адаптеру, созданному в результате NIC Teaming, эта тема рассмотрена в следующей главе. Для обеспечения отказоустойчивости в рабочей, «продакшн»‐системе, вы можете выбрать назначение внешнего виртуального коммутатора в network team или использовать несколько внешних виртуальных коммутаторов; в обеих конфигурациях вам потребуется как минимум два физических сетевых адаптера, для того, чтобы обеспечить избыточность. Для подробностей смотрите статью Configuring Virtual Networks на Microsoft TechNet.

• IP storage: Microsoft рекомендует, чтобы передача данных сети IP storage (iSCSi, FCoE, NFS) была отделена от сети виртуальных машин и кластерной сети, и NetApp присоединяется к этой рекомендации. По меньшей мере, один физический сетевой адаптер необходим для поддержки использования iSCSI на хост‐сервере Hyper‐V (parent partition). Если вы хотите использовать multipathing или MPIO для parent partition Hyper‐V, вам потребуется, по меньшей мере, два или более физических сетевых адаптера на эту задачу. Если вы включаете на Hyper‐V Windows failover clustering, то отделение трафика сети IP storage из рекомендации становится требованием к конфигурации. Для подробностей смотрите Hyper‐V: Using Hyper‐V and Failover Clustering и Hyper‐V: Using Live Migration with Cluster Shared Volumes in Windows Server 2008 R2 на Microsoft TechNet.

• Windows failover cluster private: Если вы создаете в Hyper‐V Windows failover cluster, то это требует использования сети под названием cluster private network, и может потребовать выделенного физического адаптера. В предыдущей версии Windows Server, она использовалась главным образом для передачи cluster heartbeat, но в R2 она также используется для cluster shared volumes (CSV) или live migration (смотрите Live Migration и Cluster shared volumes ниже). Для подробностей смотрите Hyper‐V: Using Hyper‐V and Failover Clustering и Hyper‐V: Using Live Migration with Cluster Shared Volumes in Windows Server 2008 R2 на Microsoft TechNet.

• Live migration: Это новая особенность Windows Server 2008 R2; по этой причине ее описание не относится к предыдущим версиям ранее Hyper‐V R2. Когда запускается live migration виртуальных машин, то соединение и передача данных происходит через отдельную сеть, что облегчает работу основной сети. Также, Microsoft рекомендует сконфигурировать выделенный физический сетевой адаптер только для трафика live migration, с использованием failover cluster manager MMC или с помощью PowerShell. Для подробностей смотрите статью Hyper‐V Live Migration Overview and Architecture на Microsoft Download Center и Hyper‐V: Using Live Migration with Cluster Shared Volumes in Windows Server 2008 R2 на Microsoft TechNet.

• Cluster shared volumes: Cluster shared volumes (CSV) это также новая особенность R2, так что этот пункт не относится к предыдущим версиям Hyper‐V ранее R2. Когда cluster shared volumes используется в Windows failover cluster for Hyper‐V, то необходима связь между узлами кластера Hyper‐V, являющимися владельцами (owners), а также «невладельцами» (non‐owners) отдельных CSV, куда входит кроме прочего и проверка состояния (health checks), и dynamic I/O redirection. Microsoft рекомендует использовать для этих целей выделенный сетевой адаптер, чтобы быть уверенным в том, что полоса пропускания всегда будет гарантировано доступна, и снизить вероятность файловера в случае случайной недоступности соединения CSV между узлами. Для подробностей смотрите статью Hyper‐V: Using Live Migration with Cluster Shared Volumes in Windows Server 2008 R2 на Microsoft TechNet.



http://technet.microsoft.com/en-us/library/dd446679%28WS.10%29.aspx






http://www.microsoft.com/downloads/details.aspx?FamilyID=FDD083C6-3FC7-470B-8569-7E6A19FB0FDF&displaylang=en





Как вы видите из перечисленного выше, количество физических сетевых адаптеров рекомендуемых для сервера Hyper‐V может довольно стремительно вырасти, в особенности, если вы планируете строить Windows failover cluster для высокой доступности решения, или использовать live migration и CSV. Подводя итоги рассмотренной темы с количеством адаптеров, рекомендуем воспользоваться приведенными таблицами.

Таблица 2‐1) Отдельный сервер Hyper‐V,сконфигурированный для работы с …

Mgmt VMs iSCSI Cluster Migration CSV Итого

Non‐Prod

DAS 1 1 ‐‐ ‐‐ ‐‐ ‐‐ 2 FC 1 1 ‐‐ ‐‐ ‐‐ ‐‐ 2 iSCSI 1 1 1 ‐‐ ‐‐ ‐‐ 3

Prod DAS 1 1 или 2 ‐‐ ‐‐ ‐‐ ‐‐ 2 или 3 FC 1 1 или 2 ‐‐ ‐‐ ‐‐ ‐‐ 2 или 3 iSCSI 1 1 или 2 2 ‐‐ ‐‐ ‐‐ 4 или 5

Таблица 2‐2) Кластерный сервер Hyper‐V, и сконфигурированный для работы с …

Mgmt VMs iSCSI Cluster Migration CSV Итого Non‐Prod

FC 1 1 ‐‐ 1 ‐‐ ‐‐ 3 iSCSI 1 1 1 1 ‐‐ ‐‐ 4

Prod FC 1 1 или 2 ‐‐ 1 ‐‐ ‐‐ 3 или 4 iSCSI 1 1 или 2 2 1 ‐‐ ‐‐ 5 или 6

Таблица 2‐3) Кластерный сервер Hyper‐V, использующий live migration, и сконфигурированный для работы с …


FC 1 1 ‐‐ 1 1 ‐‐ 4 iSCSI 1 1 1 1 1 ‐‐ 5

Prod FC 1 1 или 2 ‐‐ 1 1 ‐‐ 4 или 5 iSCSI 1 1 или 2 2 1 1 ‐‐ 6 или 7

Таблица 2‐4) Кластерный сервер Hyper‐V, использующий live migration, CSVs, и сконфигурированный для работы с …


FC 1 1 ‐‐ 1 1 1 5 iSCSI 1 1 1 1 1 1 6

Prod FC 1 1 или 2 ‐‐ 1 1 1 5 или 6 iSCSI 1 1 или 2 2 1 1 1 7 или 8

Объединение сетевых интерфейсов (teaming) В прошлом было много случаев непонимания того, как поддерживается, и поддерживается ли NIC teaming в Microsoft Hyper‐V. Microsoft утверждала, что они не поддерживают NIC teaming в Microsoft Hyper‐V, но что это означает на самом деле? Это значит, что у Microsoft нет собственного драйвера для всех типов NIC, которые могут быть установлены в сервер Hyper‐V, и который бы поддерживал на них NIC teaming, только и всего. А у кого есть драйвер для NIC,

установленных в Hyper‐V Server? Верно, у производителя NIC, такого, как Intel или Broadcom, и их драйвера обычно поддерживают использование NIC teaming.

Так что, хотя это и может вас несколько озадачить, вы действительно можете использовать NIC teaming в Windows Server 2008 R2, если производитель NIC, который написал драйвера для своего сетевого адаптера, поддерживает в нем эту возможность – вы можете подключить объединенные сетевые карты в виртуальный коммутатор. Преимущества такого действия довольно очевидны, не только виртуальный коммутатор получает большую полосу пропускания, но и увеличивается доступность, благодаря объединению нескольких NIC вместе. Однако вы можете столкнуться с тем, что некоторые из сетевых возможностей, которые мы рассматривали в главе 2.1.2, не доступны для логических NIC, созданных в результате объединения нескольких физических NIC в team.

Microsoft также не поддерживает использование NIC teaming для сетей, использующихся для передач данных iSCSI. Поэтому вы можете не использовать логический сетевой интерфейс для сети iSCSI, когда работаете через Microsoft iSCSI Software Initiator для того, чтобы подключить LUN к хост‐OS Hyper‐V (parent partition). Кроме этого, когда логический NIC подключается к виртуальному коммутатору, виртуальные машины, подсоединенные к этому виртуальному коммутатору, не должны иметь включенного Microsoft iSCSI Software Initiator на этом виртуальном NIC.

NetApp Best Practice Recommendation Для функциональных областей, в которых используется более одного соединения, таких, как виртуальные сетевые адаптеры, использующиеся для взаимодействия между различными виртуальными машинами, соединения могут быть распределены по разным сетевым адаптерам, например, если используется многопортовый NIC. В таких случаях даже отказ одного из портов адаптера или физического адаптера целиком, входящего в team, не приведет к потере возможности передачи данных для сервера Hyper‐V. Так как NIC teaming не поддерживается для iSCSI, NetApp рекомендует сконфигурировать несколько путей подключения к сети хранения для обеспечения избыточности и дополнительной полосы пропускания при помощи Multipathing/MPIO. Для подробностей по использованию смотрите главу 5.1.2 Multipathing/MPIO в этом документе.

Сетевой дизайн и полоса пропускания Сейчас, когда 10GbE становится все более обычным в ЦОД, принципы и методы разработки сетевого дизайна изменились. Такой значительный скачок в ширине полосы пропускания привел к тому, что стало возможным заменить в сервере несколько физических сетевых адаптеров на один, с более высокой пропускной способностью, сохранив все существовавшие возможности, функциональность и производительность. Однако сервер Hyper‐V отличается от других серверов, и в его случае установка10GbE NIC не обязательно приводит к общему снижению количества физических сетевых адаптеров.

Как мы рассмотрели в начале раздела, и показали в таблицах 2‐1…2‐4, большая часть функционала серверов Hyper‐V требует выделенных физических адаптеров. Это так в большинстве случаев, вне зависимости от того, будет ли он 1GbE или 10GbE NIC. По этой причине, описанная в таблицах 2‐1…2‐4 ситуация с функциональностью не зависит от полосы пропускания сетевого интерфейса, в случаях интерфейсов: Hyper‐V Management (Mgmt), Cluster, и Live

Migration. Вместе с тем, эти функциональные возможности скорее всего выиграют от увеличения полосы пропускания.

Однако следующие функциональные возможности выигрывают от увеличения полосы пропускания сети в наибольшей степени: iSCSI, CSV, и, в большинстве случаев, VM. При этом интерфейс, используемый для сети CSV выиграет от доступа к большой полосе пропускания более всех, так как это напрямую отразится на поддержке средств I/O redirection.

2.1.2 Виртуальные сети Существует четыре типа виртуальных сетей, используемые в Hyper‐V; выделенные (dedicated), внешние (external), внутренние (internal), и частные (private). Для подробностей о различных типах виртуальных сетей смотрите статью Configuring Virtual Networks на Microsoft TechNet. Для подробностей о настройке R2 для связи между Hyper‐V parent partition и виртуальными сетями, смотрите статью Virtual Network Manager на Microsoft TechNet и запись New in Hyper‐V Windows Server 2008 R2 Part 1: Dedicated Networks в блоге Джона Ховарда на Microsoft TechNet blog.

2.1.3 Поддержка новых сетевых возможностей В релизе Windows Server 2008 R2 появилась поддержка нескольких новых сетевых возможностей, таких, как поддержка jumbo frame для сети 1GbE и поддержка TCP chimney в сети 10GbE. Эти сетевые технологии позволяют Hyper‐V R2 получить преимущества технологий network offload, так что процессор сервера Hyper‐V может тратить свою мощность не на обработку задач сети, а на задачи приложений, что помогает улучшить производительность и снизить загрузку CPU. Windows Server 2008 R2 Hyper‐V может пасть жертвой нескольких «узких мест» сетевой архитектуры, и которые следует классифицировать по двум группам – на приеме данных, и на передаче. Список возможных точек «узких мест» приведен в таблице 2‐5.

Таблица 2‐5) Возможные точки «узких мест» в сети Hyper‐V.

Прием данных Передача данных Перемещение данных между parent‐ и child‐партициями

Просмотр MAC‐address и фильтрация VLAN ID Затраты на переключение контекста parent/child

Разбор пакетов, отправленных группе, образованной по MAC‐address

Программная обработка трафика между VM

Дополнительное копирование данных для трафика между VM

Large Send Offload (LSO) и Checksum Offload (CSO) Опции сети под названием large send offload (LSO) и checksum offload (CSO) поддерживаются виртуальными сетями в Hyper‐V. Кроме этого, если физический адаптер также их поддерживает, то виртуальный трафик будет разгружен и на физической сети. Большинство современных сетевых адаптеров поддерживают LSO и CSO, но проверьте данные вашего производителя NIC, для того, чтобы убедиться в этом. Если данные опции поддерживаются, то, как правило, по умолчанию они разрешены в настройках драйвера.

NetApp Best Practice Recommendation Если LSO и CSO поддерживаются, NetApp настоятельно рекомендует проверить, что их использование разрешено в драйвере (если по умолчанию в его настройках эти параметры не установлены в enabled).



http://blogs.technet.com/jhoward/archive/2009/05/04/new-in-hyper-v-windows-server-2008-r2-part-1-dedicated-networks.aspx


Jumbo Frames Поддержка jumbo frames была представлена впервые для Windows Server 2008, но в версии R2 были добавлены некоторые улучшения, и производители NIC предложили широкий выбор сетевых адаптеров с их поддержкой. В Windows 2008 R2, использование jumbo frames позволяет увеличить загрузку пакета данными в 6 раз, что значительно повышает величину пропускной способности и снижает нагрузку на CPU на больших объемах передачи данных. Кроме этого в Windows 2008 R2 jumbo frames поддерживаются не только физическими адаптерами, но и виртуальной сетью, включая виртуальные коммутаторы и адаптеры.

NetApp Best Practice Recommendation NetApp рекомендует использовать jumbo frames в NIC, сконфигурированных для использования iSCSI, но они должны также поддерживаться всем оборудованием по пути следования IP‐пакета. Используйте команду: «ping –l 8000 –f –n 1 <target‐ip>» чтобы определить, что все ваше оборудование по пути следования датаграммы ping размером 8000 байт поддерживает jumbo frames.

TCP Chimney TCP chimney offload поддерживает возможности «разгрузки» (offload) соединения, доступные стеку TCP/IP в VM OS. Виртуальный NIC в VM объявляет о своих возможностях «разгрузки» соединения, и коммутатор VM в хост‐OS разгружает коннект TCP‐соединения из виртуальной машины в физический NIC. Приложения с долговременными соединениями, и длительными, объемными передачами, а также приложения с pre‐posted buffers получат выигрыш от использования TCP Chimney. В общем случае преимущества использования TCP chimney в виртуальной среде Microsoft Hyper‐V таковы:

• Значительное снижение загрузки CPU

• Полное использование возможностей 10 GbE

• Предотвращает чрезмерные потери при общении между child‐ и parent‐партициями o Предотвращение потерь на частом переключении контекста parent/child o Состояние соединения полностью обслуживается физическим NIC

• Поддержка Live migration o Соединения при процессе live migration переносятся на стек хост‐системы.

NetApp Best Practice Recommendation Если функция «TCP chimney» поддерживается производителем NIC, то NetApp рекомендует ее включить (по умолчанию она выключена (disabled)).

Virtual Machine Queue (VMQ) Использование Virtual machine queue или VMQ значительно помогает улучшить производительность, классифицируя и группируя принимаемые пакеты, распределяя их по оборудованию. Это также использует фильтрацию VLAN в оборудовании, отклоняя все пакеты с неверным VLAN ID на сетевой карте, используя коммутатор на NIC для просмотра маршрута при передаче, и позволяет избежать необходимости копировать приемные буфера NIC в адресное пространство VM. Вся обработка VMQ происходит параллельно в нескольких очередях, обслуживаемых разными процессорами.

NIC, поддерживающий VMQ имеет встроенный коммутатор, который позволяет принимаемым очередям быть «спаренными» с передаваемыми, и каждая пара очередей представляет собой порт коммутатора. Коммутатору не требуется получение MAC‐адреса, и коммутатор проверяет все передаваемые пакеты на MAC‐адрес получателя + VLAN ID, где, если пакет проходит набор фильтров на принимающей стороне, то используется DMA‐передача этой очереди; в противном случае она передается по проводу. Это огромное улучшение в случае соединений VM‐to‐VM так как при этом удается избежать маршрутизации в ПО, устраняется необходимость копирования пакетов, и удается воспользоваться преимуществами поддержки аппаратной «разгрузки». Даже для соединений VM‐to‐physical, также устраняется необходимость route lookup, что также дает преимущества в производительности.

В целом VMQ улучшает производительность сети, распределяя сетевой трафик множества VM по множеству процессоров, одновременно снижая загрузку процессоров за счет «разгрузки» процесса классификации пакетов, предотвращения копирования данных по сети, и поиска маршрута при передаче. VMQ совместим большинством средств «разгрузки», и там где он работает совместно с large send offload и jumbo frames, но где TCP chimney поддерживается в NIC, VMQ будет иметь приоритет. Использование VMQ безопасно, и поддерживает live migration в R2. Наилучшая производительность на 10GbE получается как раз при использовании VMQ.

VMQ поддерживается в Windows Sever 2008 R2 только на определенных адаптерах, и по этой причине VMQ по умолчанию выключен. Запросите в Microsoft и у производителя NIC сведения по совместимости, чтобы быть уверенным, что использование VMQ ими поддерживается, прежде чем включить его.

NetApp Best Practice Recommendation Если VMQ поддерживается производителем NIC, то NetApp рекомендует рассмотреть возможность его включить на вашем оборудовании, особенно если вы используете Hyper‐V на 10GbE.

2.1.4 Стандарты сетевого именования

Основы сетевого именования Так как на определенном сервере Hyper‐V может быть множество различных физических и виртуальных адаптеров, то управление ими может быть непростым. Большинство администраторов стремятся использовать простые и однозначно идентифицирующие схемы именования сетевых адаптеров, как физических, так и виртуальных. Когда вы решаете выбрать схему именования, то примите в рассмотрение следующие рекомендации:

• Глядя на имя адаптера, вы должны сразу понимать, является ли данный адаптер физическим или виртуальным сетевым адаптером. Вне зависимости от того, является ли адаптер физическим или виртуальным, правило именования должно стандартизировать число символов и размер имени как для того, так и для другого типа адаптеров

• Если это физический сетевой адаптер, то вам следует понимать две вещи: определить тип оборудования адаптера, и определить сеть, в которую он подключен.

o Определим оборудование физического сетевого адаптера. Если физический сетевой адаптер интегрирован в motherboard сервера,

аббревиатура обозначения такова:: <”M” для motherboard”>< двухцифровое обозначение Port #>

Если физический сетевой адаптер расположен на карте расширения (add‐on) сервера, аббревиатура обозначения такова: <”A” для Add‐on><PCIe/x Slot #><одноцифровое обозначение Port #>

o Определим тип сети, к которой он подключен. Если он подключен к физической сети:

• Используйте аббревиатурное описание, такое как LAN для локальной сети, SAN для IP‐сети хранения, и так далее.

• Если вы используете VLAN tagging, используйте VLAN ID сети.

• Создайте аббревиатуру для подсети, используя букву класса подсети, и

• Три цифры идентификатора подсети. Если он подключен к виртуальной сети/коммутатору:

• Используйте аббревиатуру описания сети, такую как «D» для dedicated, «E» для external, «I» для internal, и «P» для private.

• Используйте двухцифровой код для того, чтобы определить конкретную виртуальную сеть.

• Если это виртуальный сетевой адаптер, или физический адаптер, подключенный к внешней (external) или выделенной (dedicated) виртуальной сети, вы должны далее определить тип виртуальной сети, и то, как к этой сети адаптер подключен.

o Определите тип виртуальной сети. Используйте аббревиатуру описания сети, такую как «D» для dedicated, «E»

для external, «I» для internal, и «P» для private. Используйте двухцифровой код для того, чтобы определить конкретную

виртуальную сеть. o Определите сеть, к которой он подключен.

Используйте аббревиатурное описание, такое как LAN для локальной сети, SAN для IP‐сети хранения, и так далее.

Если вы используете VLAN tagging, используйте VLAN ID сети. Создайте аббревиатуру для подсети. Первым символом выберите букву,

соответствующую классу подсети. Вторым элементом возьмите 2, 3, или 5 цифр, определяющих подсеть, где 3 цифр это октет класса и/или 2 цифры – маска подсети.

Примеры стандартов сетевого именования Предложенные стандарты сетевого именования применены в примерах, приведенных ниже. Использование простого именования лучше всего работает в системе, которая использует транкинг VLAN по 802.1q, для минимизации числа физических сетевых адаптеров, требуемых сервером Hyper‐V. Приведенный пример более сложного именования показывает, что в ряде случаев он может быть чересчур сложным.

• Один из двух портов интегрированного в motherboard адаптера Broadcom BCM5708C GigE, подключенный к сети управления в VLAN 15, которая является подсетью Class A сети 10.0.15.x/8.

o Простой: PM01‐MGT15 = <”P” для physical><”M” для motherboard>< двухцифровое обозначение Port #>‐<”MGT” для Management Network><VLAN ID>

o Более сложный: PM01‐MGT15‐C01008 = <”P” для physical><”M” для motherboard>< двухцифровое обозначение Port #>‐<”MGT” для Management

Network><VLAN ID>‐<Subnet Class><Subnet Identifier‐Class Octet><Subnet Identifier‐Subnet Mask>

• Intel® PRO/1000 PT Quad Port LP Server Adapter установленный в PCI Add‐on slot 2, два из четырех портов карты подключены к производственной сети в VLAN 10, которая подсеть Class B сети 172.16.100.x/16, и используется как External Virtual Network #2.

o Простой: PA22‐E0210 = <”P” для physical><”A” для Add‐on><PCIe/x Slot #><цифра Port #>‐<”E” для External Virtual Network><двухцифровое обозначение virtual network id><VLAN ID>

o Более сложный: PA22‐E0210‐B1628 = <”P” для physical><”A” для Add‐on><PCIe/x Slot #><Single‐Digit Port #>‐<”E” for External Virtual Network><двухцифровое обозначение virtual network id><VLAN ID>‐<Subnet Class><Subnet Identifier‐Class Octet><Subnet Identifier‐Subnet Mask>

• Внутренняя виртуальная сеть (Adapter) #1, соединяющая VM‐ы в сети SQL Network в VLAN 18, которая является подсетью Class C сети 192.168.80.x/24

o Простой: VI01‐SQL18 = <”V” для virtual><””I” для internal><двухцифровое обозначение virtual network id>‐<”SQL” для рабочей сети><VLAN ID>

o Более сложный: VI01‐SQL18‐C08024 = <”V” для virtual><”I” для internal>< двухцифровое обозначение virtual network id>‐<”SQL” для рабочей сети ><VLAN ID>‐<Subnet Class><Subnet Identifier‐Class Octet><Subnet Identifier‐Subnet Mask>

NetApp Best Practice Recommendation Разработка и установка простых для понимания правил именования для всех сетевых адаптеров, как физических, так и виртуальных, и минимизация числа характеристик в этом стандарте может быть весьма выгодно. Это не только помогает улучшить управляемость многочисленных сетей, входящих в систему сервера Hyper‐V, но также упрощает процессы использования скриптов управления инфраструктуры.

Отслеживайте конфигурации физических и виртуальных сетевых адаптеров и всей сопутствующей информации в документации, электронных таблицах или базе данных. Это становится предельно важно в растущих инфраструктурах, и в тех случаях, когда установленные сервера Hyper‐V входят в Windows failover cluster, чтобы быть уверенным в том, что все виртуальные сети названы в точности идентично на всех узлах кластера Hyper‐V.

2.1.5 Порядок биндинга сетевых адаптеров и значения Metric

Порядок биндинга сетевых адаптеров Так как большинство серверов Hyper‐V имеют множество различных сетевых адаптеров, как физических, так и виртуальных, очень часто в Windows порядок биндинга (binding, «привязка») сетевых адаптеров может быть сконфигурирован неправильно. Это требует от администратора проверять корректность порядка биндинга для каждого сервера Hyper‐V. Это особенно важно для серверов Hyper‐V, сконфигурированных как часть Windows failover cluster. Изменение порядка биндинга сетевых адаптеров может быть сделано из панели Network Connections, в Advanced ‐> Advanced Settings, в поле «Connections». Панель Network Connections можно найти в Control Panel ‐> Network and Internet в Windows Server 2008.

NetApp Best Practice Recommendation Как только все физические адаптеры установлены, все виртуальные сети Hyper‐V созданы, и все сети и адаптеры названы в соответствии с выбранными вами стандартами, вам следует проверить

и изменить настройки порядка биндинга.

Первый адаптер в списке биндинга должен быть адаптером, используемым для управления хост‐OS Hyper‐V (parent partition). Адаптер для iSCSI, live migration, и сети CSV должны идти непосредственно следом. После них должны следовать адаптер сети для cluster heartbeat, и все адаптеры виртуальных сетей.

Значения Metric для сетевых адаптеров Изменение величин сетевых метрик не является обязательным для серверов Hyper‐V не входящих в Windows failover cluster, а также не обязательно для систем не работающих как «продакшн»‐системы.

Для продакшн‐серверов Hyper‐V, входящих в Windows failover cluster, необходимость изменения установок сетевых метрик рекомендуется рассмотреть в зависимости от вашего конкретного случая применения, в первую очередь убедитесь, что parent partition сервера Hyper‐V не предпочтет использовать какую‐то другую сеть, кроме работающей по выделенному физическому адаптеру хост‐системы Hyper‐V.

Изменения в величинах метрик сетевых адаптеров может быть выполнено из панели Network Connections, через <NIC> Properties ‐> IPv4 Properties ‐> Advanced TCP/IP Settings, в поле «Automatic Metric». Величина 9999, назначенная сетевому адаптеру, является максимальным назначаемым пользователем значением «стоимости линка».

Таблица 2‐5) Рекомендованный порядок Network Binding и значения Metric

Функциональное описание Порядок Binding Metric Hyper‐V Management 1 100‐199 iSCSI 2 200‐299 Live Migration 3 400‐499 Cluster Shared Volume 4 300‐399 Other Networks 5 1000‐4999 Custer Hearthbeat 6 500‐599 Virtual Machines (pNICs) 7 5000‐6999 Virtual Switches 8 7000‐9999

2.2 Вопросы построения кластерной сети HyperV Наилучшие и рекомендованные практики, которые мы рассмотрели ранее в главах раздела 2, становятся даже более важными, когда сервер Hyper‐V развертывается как часть Failover Cluster.

После того, как Failover Clustering включается на всех, сконфигурированных как части этого кластера, серверах Hyper‐V, рекомендуется проделать дополнительные настройки для достижения оптимальной производительности.

2.2.1 Рекомендации перед конфигурированием Перед включением Failover Clustering на любом сервере Hyper‐V, необходимо учесть дополнительные параметры и сделать специфические шаги по конфигурированию сетевых настроек сервера Hyper‐V.

1. Все физические NIC, по всем серверам Hyper‐V, являющимся частью созданного кластера Failover Cluster должны быть названы в точности одинаково. Если следовать стандарту

именования, описанному в разделе 2.2.4 ранее, это будет возможным, только если все аппаратное обеспечение серверов идентично – одинаковые NIC установлены в одинаковые слоты во всех серверах кластера. Если вы используете различные сервера и различные NIC, стоит подумать об упрощении стандарта именования. Это не является требованием, но рекомендацией.

2. Убедитесь, что сетевые соединения, являющиеся частью одной функциональной группы, как описано в таблице 2‐5 ранее, настроены одинаково. Как минимум, каждый сетевой адаптер должен иметь возможность взаимодействия с другими сетевыми адаптерами в этой же функциональной группе с одинаковыми настройками IP (за исключением IP‐адреса). В идеале, сетевые адаптеры должны иметь не только одинаковые настройки IP, но одинаковые настройки на аппаратном уровне.

3. Убедитесь, что Network Binding Order идентичен на всех серверах Hyper‐V, сконфигурированных как часть Windows Failover Cluster.

4. Аналогично, если вы изменяли Network Metric Values физических NICs, то это должно быть сделано одинаково на всех физических NICs, на всех серверах Hyper‐V, сконфигурированных как часть Windows Failover Cluster.

NetApp Best Practice Recommendation NetApp рекомендует пройти по шагам с 1 по 4 списка выше при проверке всей вашей сетевой конфигурации, даже если вы ранее сделали эти действия следуя ране описанным практикам и рекомендациям начальной конфигурации физических NIC. Использование идентичных конфигураций на всех узлах Hyper‐V в кластере позволяет получить оптимальную производительность и упрощает управление.

NetApp рекомендует администраторам рассмотреть возможность отключить все некритичные физические NIC перед включением Failover Clustering. Критичные NIC это Hyper‐V Management, сеть IP Storage (если используется), и Cluster Private network (используемая Windows Failover Cluster для передачи heartbeat). После того, как все, не являющиеся безусловно необходимыми сетевые интерфейсы NIC будут отключены, вы можете включать Failover Cluster для серверов Hyper‐V.

2.2.2 Рекомендации после конфигурирования После включения Failover Cluster, используйте Failover Cluster Manager для исходного конфигурирования кластерных сетей, и следуйте указаниям главы 2.2.3 Именование кластерных сетей.

Если вы отключили все некритичные NIC перед включением Failover Cluster, то в Failover Cluster Manager, в «Networks» вы будете видеть только сети, которые не были отключены перед конфигурированием сервера Hyper‐V для Failover Clustering. Поэтому продолжайте следовать шагам этой главы, до того, как перейдете к главе 2.2.3 Именование кластерных сетей.

Перед началом всех дальнейших изменений, начните с включения всех сходных адаптеров на всех узлах Hyper‐V входящих в Failover Cluster. Однако, включайте только одну функциональную сеть в данный момент времени, то есть включайте только один физический NIC на узле Hyper‐V в каждый момент времени, повторяя это на каждом узле Hyper‐V кластера за раз. Продолжайте процесс включением физических NIC, являющихся частью то же логической сети (обычно определены функциональными областями, как написано в таблице 2‐5), одна кластерная сеть за раз, для всех узлов Hyper‐V в кластере. После того, как все физические сетевые адаптеры на всех узлах Hyper‐V будут включены для заданных кластерных сетей, перейдите в Failover Cluster

Manager и убедитесь, что они правильно сгруппированы в те кластерные сети, как и было предварительно спланировано.

Хотя вы и можете попробовать включить все ранее отключенные сетевые адаптеры одновременно, по всем узлам Hyper‐V в кластере, но если при этом возникнут проблемы с группировкой и работой кластерных сетей не в том порядке как планировалось, то разбор такой ситуации может быть довольно сложен.

2.2.3 Именование кластерных сетей Как обсуждалось ранее в главе 2.1.4 Стандарты сетевого именования, те же общие принципы применимы и в данном случае.

NetApp Best Practice Recommendation Установите простые и хорошо понятные имена для всех кластерных сетей, по возможности содержащих как можно меньше символов, но хорошо и понятно описывающих функциональность сети. Пример: В нашей лаборатории в NetApp, мы используем «Mgmt» как имя для кластерной сети, состоящей из NIC, используемых для управления узлами Hyper‐V, «Storage» для кластерной сети, используемой для трафика iSCSI, и «Private» для кластерной сети, используемой для передачи failover cluster heartbeat.

2.2.4 Конфигурирование кластерных сетей Когда все кластерные сети правильно определены для всего кластера Hyper‐V, мы можем заняться конфигурированием и настройкой каждой из этих сетей. Это можно сделать просмотром каждой кластерной сети с помощью Failover Cluster Manager и выбором на панели FCM справа, названной «Actions», или щелчком правой клавишей на конкретной кластерной сети и выбором «Properties».

Рисунок 2‐1 Свойства Cluster Network

Используйте данные таблицы 2‐6 ниже, для конфигурирования каждой кластерной сети в соответствии с ее функциями. Настройки, указанные ниже означают:

• Allow cluster… = Разрешить связь Cluster Network с этой сетью

• Allow clients… = Разрешить клиентам соединяться через эту сеть

• Do not allow cluster… = Не разрешать связь Cluster Network с этой сетью

Table 2‐6) Рекомендованные настройки конфигурации для Cluster Network

Описание Cluster Network Настройки Cluster Network Hyper‐V Management Allow cluster… / Allow clients… iSCSI Do not allow cluster… Live Migration Do not allow cluster… Cluster Shared Volume Allow cluster… Other Networks Configure based on environment Custer Hearthbeat Allow cluster… Virtual Machines (pNICs) Do not allow cluster… Virtual Switches Do not allow cluster…

NetApp Best Practice Recommendation NetApp предлагает эти конфигурационные установки как образец, хотя и понимает, что каждая инсталляция Hyper‐V отличается от другой. Поэтому используйте свое собственное суждение и здравый смысл, используя данные таблицы 2‐6.

Там, где конфигурация из таблицы 2‐6 соответствует вашей системе, NetApp рекомендует использовать предложенные настройки.

2.2.5 Cluster Network Metrics Хотя мы пока и не обсуждали Cluster Shared Volumes (CSV) в подробностях, кроме беглого введения в CSV в главе 2.1.1, мы рассмотрим рекомендацию Microsoft выделять как минимум один физический NIC для соединений CSV.

NetApp Recommendation NetApp поддерживает рекомендацию Microsoft, выделять как минимум один физический NIC для соединения CSV на каждом узле кластера Hyper‐V.

Каждая кластерная сеть в кластере Hyper‐V имеет две установки для приоритезации сети – Metric and AutoMetric. Значение параметра Metric используется для определения приоритета определенной кластерной сети. Значение AutoMetric может быть True или False, в зависимости от того, какие значения сконфигурировал администратор вручную для значения Metric. Для private кластерных сетей, значение Metric должно попадать в промежуток между 1000 и 10000, а для public кластерных сетей, значение Metric начинается от 10000.

Кластер Hyper‐V использует Windows PowerShell cmdlet Get‐ClusterNetwork для определения приоритета кластерной сети и выбора сети с наименьшим значением Metric как предпочтительной для CSV. Почему мы решаем сделать ее «предпочтительной», вместо того, чтобы сделать ее выделенной? Это так оттого, что соединение, используемое для CSV должно быть отказоустойчивым.

Однако если первичная для CSV кластерная сеть испытывает проблемы, или падает целиком, то кластер Hyper‐V обнаруживает эту проблему и автоматически переносит коммуникации CSV в кластерную сеть с более низким значением Metric.

Тот же Windows PowerShell cmdlet используется для идентификации кластерной сети, используемой для связи с CSV – Get‐ClusterNetwork – он же используется для изменения значений настроек кластерной сети.

Использование этого Windows PowerShell cmdlet есть единственный путь сконфигурировать предпочтительную сеть (preferred network) для CSV, в версии R2 нет других возможностей задать величины cluster network Metric.

В таблице 2‐7 вы найдете рекомендации NetApp для величин Metric, которые следует задать для каждой работающей кластерной сети.

Таблица 2‐7) Рекомендованные значения AutoMetric и Metric

Описание Cluster Network AutoMetric Metric Hyper‐V Management True Auto iSCSI True Auto Live Migration False 1000‐1099 Cluster Shared Volume False 500‐999 Other Networks True Auto Custer Hearthbeat False 1500‐1999 Virtual Machines (pNICs) True Auto Virtual Switches True Auto

NetApp Best Practice Recommendation NetApp предлагает эти конфигурационные установки как образец, хотя и понимает, что каждая инсталляция Hyper‐V отличается от другой. Поэтому используйте свое собственное суждение и здравый смысл, используя данные таблицы 2‐7.

Там, где конфигурация из таблицы 2‐7 соответствует вашей системе, NetApp рекомендует использовать предложенные настройки.

Таблица 2‐7 подразумевает, что каждая кластерная сеть, описанная в левой колонке, это отдельная физическая сеть. Если вы комбинируете эти функции в одной общей для них физической сети, или используете VLAN для задания отдельных логических сетей вместо использования физически отделенных сетей, то используйте свои суждения и здравый смысл, устанавливая значения Metric для каждой кластерной сети, сконфигурированной для кластера Hyper‐V.

В таблице 2‐7 выше также подразумевается, что величина значения Metric между 500 и 999, то есть с наинизшим допустимым значением доступным для кластерной сети, назначается для кластерной сети, предпочтительной для работы CSV. Не следует допускать, чтобы любая другая частная кластерная сеть (private cluster network) использовала величины ниже 1000, поэтому вы можете оставить во всех других кластерных сетях установку AutoMetric равное auto, чем вы подтверждаете то, что кластерная сеть, которую вы выбрали для использования с CSV, сконфигурирована с наиболее низкими значениями Metric. Если это не так, то рассмотрите возможность задания дополнительных метрик для кластерной сети, чтобы быть уверенным в том, что кластерная сеть для CSV и Live Migration имеет достаточный приоритет.

Для управления кластерной сетью, выбранной для работы с CSV, следуйте шагам:

Шаг Действие 1. Войдите на Hyper‐V Server членом группы Failover Cluster 2. Откройте Windows PowerShell Modules в Administrative Tools:

Start ‐> All Programs ‐> Administrative Tools ‐> Windows PowerShell Modules

3. Для того, чтобы увидеть текущие настройки cluster network, наберите команду: Get‐ClusterNetwork | ft Name, Metric, AutoMetric

4. Для установки значения метрик для определенной cluster network, вы должны знать имя cluster network, взятой из вывода команды на предыдущем шаге. Когда вы узнаете имя cluster network, вы можете сконфигурировать соединение с CSV набрав следующую команду: $csv = Get‐ClusterNetwork “[insert cluster network name]” $csv.Metric = [insert recommended metric value from table 2‐7]

5. Для проверки задания настроек наберите команду: Get‐ClusterNetwork | ft Name, Metric, AutoMetric

2.3 Вопросы построения сети хранения Когда вы разрабатываете сетевую инфраструктуру (неважно, FC или IP), следует стремиться к отсутствию в ней «единой точки отказа» (single point of failure). Решения для обеспечения высокой доступности включают в себя два и более FC или IP коммутатора, два или более HBA или NIC на сервер Hyper‐V, и два или более порта FC или порта NIC на системе хранения. Кроме этого, при использовании Fibre Channel, требуется две «фабрики» для построения действительно отказоустойчивой инфраструктуры сети хранения. Для подробностей о разработке и развертывании решения с использованием FC/iSCSI смотрите NetApp Fibre Channel and iSCSI Configuration Guide на веб‐сайте NetApp NOW™, соответствующий вашей версии Data ONTAP®.

2.3.1 Сеть хранения Fibre Channel

Опции многопутевого подключения в Fibre Channel Кластерная система хранения NetApp имеет опцию, под названием cluster failover mode (cfmode) которая определяет то, как порты Fibre Channel работают при файловере в конфигурации active‐active. Выбор правильного cfmode критически важен для того, чтобы быть уверенным в том, что ваши LUN‐ы останутся доступны, а производительность системы хранения в случае файловера – останется оптимальна.

NetApp Best Practice Recommendation NetApp настоятельно рекомендует установить cfmode в режим single system image (SSI), так как это обеспечивает доступ к LUN‐ам со всех портов системы хранения.

Чтобы убедиться в правильной настройке, или установить режим cfmode с помощью консоли NetApp, используйте следующие шаги:

Шаг Действие 1. Войдите в консоль NetApp с помощью SSH, Telnet, или консольного кабеля. 2. Наберите команду:

fcp show cfmode 3. Если cfmode необходимо переключить в SSI, наберите команду:

priv set advanced 4. Далее введите команду:

fcp set cfmode <mode type>

Использование режима single system image требует дополнительных настроек многопутевого доступа (multipathing) на сервере Hyper‐V. Для дополнительных сведений о различных доступных режимах cfmode, а также о влиянии его изменения смотрите NetApp Block Access Management Guide for iSCSI and FC на сайте NetApp NOW™ для соответствующей версии релиза Data ONTAP®.

http://now.netapp.com/


Для полного списка поддерживаемых конфигураций Hyper‐V, смотрите NetApp Interoperability Matrix.

NetApp Best Practice Recommendation Контроллер системы хранения должен иметь как минимум два доступных порта FC HBA, чтобы можно было создать избыточные отказоустойчивые пути подключения системы хранения NetApp к серверам Hyper‐V.

2.3.2 IPсеть хранения

Виртуальные интерфейсы NetApp (Virtual Interfaces, VIF) Виртуальные интерфейсы (virtual network interface (VIF)) это механизм, позволяющий создавать объединение физических сетевых интерфейсов в единый логический блок. Будучи созданными, функционально VIF ничем не отличаются от обычного физического сетевого интерфейса.

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

Вариант виртуального сетевого интерфейса под названием Multimode VIF, соответствует спецификации и стандарту IEEE 802.3ad. В режиме multimode VIF, все физические соединения, входящие в VIF активны одновременно, и используются для передачи трафика. Этот режим требует, чтобы интерфейсы были включены в коммутатор, поддерживающий режим «транкинга» или агрегирования по нескольким портам. Коммутатор должен быть сконфигурирован таким образом, чтобы понимать, что все соединения портов совместно используют один и тот же MAC‐адрес, и являются частью одного логического интерфейса. Рисунок 2‐1 показывает пример multimode VIF, интерфейсы e0, e1, e2, и e3 являются частью MultiTrunk1 multimode VIF. Все четыре интерфейса входящих в MultiTrunk1 multimode VIF активны одновременно. В случае так называемого single‐mode VIF, напротив, только один физический интерфейс работает в каждый момент времени. Если система хранения обнаруживает сбой или отсутствие соединения в активном интерфейсе, то активируется соединение, находящееся в режиме standby. Для использования single‐mode VIF не требуется дополнительных настроек, и физические соединения, которые входят в VIF не подключаются в один и тот же коммутатор. Отметьте, что балансировка нагрузки при использовании single‐mode VIF не поддерживается. Рисунок 2‐2 показывает пример single‐mode VIF, на рисунке, e0 и e1 являются частью SingleTrunk1 single‐mode VIF. Если активный интерфейс, e0, откажет, то находящийся в standby интерфейс e1 занимает его место, и обслуживает соединение к коммутатору.

Figure 2‐1) Multimode VIF

https://now.netapp.com/matrix/mtx/login.do


Figure 2‐2) Single‐mode VIF

Кроме описанного, возможно создание так называемых «VIF второго уровня», как single, так и multimode. При использовании second‐level VIFs возможно получить преимущества обеих схем, то есть и организации агрегирования интерфейсов multimode VIF, и отказоустойчивые возможности single‐mode VIF. В этой конфигурации, создаются два multimode VIF, каждый подключается в отдельный коммутатор. Затем поверх них создается single‐mode VIF, в который включены два multimode VIF. В нормальном состоянии трафик передается через только один из multimode VIFs, но в случае сбоя или отказа, или отключения коммутатора, контроллер системы хранения переносит сетевой трафик на другой multimode VIF. Для подробного рассмотрения темы настройки и использования VIF различных типов смотрите Data ONTAP Network Management Guide на сайте NetApp NOW™ для вашей версии релиза Data ONTAP®.

Рисунок 2‐3) VIF второго уровня

NetApp Best Practice Recommendation Контроллеры системы хранения должны иметь, по меньшей мере, по два или более портов target, чтобы быть уверенными в том, что для серверов Hyper‐V имеются избыточные пути доступа к данным на системе хранения.

Безопасность данных iSCSI Контроллеры NetApp также позволяют ограничивать использование протокола iSCSI только определенными интерфейсами и/или тегами VLAN. Эта простая настройка заметно усиливает безопасность использования и доступность дисков.

NetApp Best Practice Recommendation

Для систем Hyper‐V, использующих iSCSI, NetApp настоятельно рекомендует отделять в отдельные физические сети как обычные IP‐коммуникации между сервером и виртуальными машинами, так и IP‐сеть хранения. Как минимум, трафик должен быть разделен с помощью 802.1Q VLAN tagging.

2.3.3 Masking и Zoning При организации доступа к данным системы хранения с использованием FCP или iSCSI, система хранения должна иметь правильный masking (маскирование) таким образом, чтобы видны были только соответствующие партиции. На системе хранения NetApp маскирование LUN делается с помощью создания так называемых initiator groups (или igroups).

Если вы используете NetApp SnapDrive® for Windows, установленный на сервер Hyper‐V или в OS внутри VM, его можно использовать для конфигурирования igroups с помощью «Manage IGroup Wizard» в меню Disks‐>Actions. Если вы не используете NetApp SnapDrive, то потребуется больше ручных операций, вам надо узнать IQN и/или WWPN для правильного конфигурирования соединения между системой хранения и сервером. Для того, чтобы их узнать, воспользуйтесь советами ниже.

NetApp Best Practice Recommendation NetApp рекомендует создавать igroup для каждого сервера Hyper‐V, кластера Windows failover cluster (являющегося комбинацией нескольких серверов Hyper‐V), или каждой VM OS (для того, чтобы иметь возможность использовать прямой доступ к LUN из VM OS с помощью Microsoft iSCSI Software Initiator) в зависимости от требований задачи.

Внимание: Если сервер Hyper‐V или кластер будет использовать и Fibre Channel и iSCSI, то необходимо создать отдельные igroups для Fibre Channel и для iSCSI.

NetApp также рекомендует включить в имя igroup также имя сервера Hyper‐V server, кластера Windows failover cluster, или VM OS и тип протокола (например, DC1_FCP и DC1_iSCSI) в соответствии с выбранной схемой именования. Следование такому методу именования упрощает управление для igroups. Это также обеспечивает то, что каждый из серверов Hyper‐V в Windows failover cluster видит каждый LUN под одним и тем же ID. Каждая initiator group включает в себя все FCP worldwide port names (WWPNs) или iSCSI qualified names (IQNs) северов Hyper‐V в кластере. NetApp рекомендует использовать NetApp SnapDrive для управления igroups и конфигурирования системы хранения.

Получение IQN (iSCSI) Узнать iSCSI qualified name (IQN) с сервера Hyper‐V или VM OS можно открыв окно командной строки и отдав команду: iscsicli. Для подробностей по получению IQN для всех сконфигурированных инициаторов iSCSI, смотрите главу 3.6.4 Configure Windows Server 2008 Initiator Groups on NetApp Storage в документе TR‐3733: NetApp Implementation Guide for Microsoft Virtualization, и следуйте приведенным пошаговым инструкциям.

Получение WWPN (FC) Узнать WWPN портов FC возможно с использованием NetApp Windows Host Utility (рассматривается далее в этом документе) или утилит производителя HBA (например, Qlogic SAN Surfer) на сервере Hyper‐V. Для подробностей о получении WWPN всех установленных Fibre Channel HBA, смотрите главу 3.5 Fibre Channel Zoning Configuration в руководстве TR‐3733: NetApp




Implementation Guide for Microsoft Virtualization, и следуйте приведенным там пошаговым инструкциям.

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

Контроллеры системы хранения NetApp в режиме ActiveActive При разработке архитектуры сетевой системы хранения для Microsoft Hyper‐V, важным элементом решения является высокая доступность данных. NetApp использует модель active‐active для работы контроллеров системы хранения для того, чтобы быть уверенной в доступности данных бизнес‐критичных систем, таких, как виртуальные серверные среды Microsoft Hyper‐V. Контроллеры, работающие в режиме active‐active, обеспечивают простое, автоматизированное и прозрачное переключение, соответствуя самым требовательным нормам промышленного решения. Обеспечение максимального уровня доступности сетевого хранилища является критически важным аспектом для всех подключенных к нему серверов. Для подробностей смотрите главу High‐Availability System Configuration в документе NetApp TR‐3450: Active‐Active Controller Overview and Best Practices Guidelines.

NetApp Best Practice Recommendation Используйте кластерную active‐active конфигурацию системы хранения, чтобы увеличить производительность, и устранить «единую точку отказа» (single point of failure (SPOF)).

Multipath HA Конфигурация системы хранения под названием Multipath HA это дальнейшее улучшение надежности и производительности кластерной конфигурации active‐active контроллеров систем хранения NetApp. Хотя кластерное ПО обеспечивает высокую доступность и отказоустойчивость в случае отказа контроллера, иногда случаются ложные срабатывания. Multipath HA обеспечивает большую устойчивость, и снижает вероятность нежелательного takeover на партнерский контроллер в случае проблем с дисковым хранилищем, улучшает общую доступность системы, и обеспечивает большую стабильность производительности. Multipath HA обеспечивает дополнительную защиту против различных отказов системы хранения, таких как отказы HBA или портов, отказы и повреждения кабелей от контроллера до дисковых полок, обрыв кабелей между полками, и отказ резервного пути данных. Multipath HA помогает обеспечить стабильную производительность в конфигурации active‐active, обеспечивая большую агрегированную пропускную способность в петле. Для подробностей смотрите документ NetApp TR‐3437: Storage Best Practices and Resiliency Guide.

NetApp Best Practice Recommendation Используйте multipath HA с кластером active‐active системы хранения, чтобы получить максимальную защищенность данных, и получить максимально возможную их доступность.






Защита данных с помощью RAID Важная проблема для любой задачи серверной консолидации (например, серверной виртуализации), это увеличивающиеся риски отказа платформы консолидации. Когда физические сервера преобразовываются в виртуальные машины (в терминах Hyper‐V это называется child partitions) и множество разных виртуальных машин объединяются на одном физическом сервере (в терминах Hyper‐V ‐ parent partition), влияние отказа платформы хранения может быть катастрофическим.

Для достижения высокой степени доступности хранимых данных существует множество решений, включающих в себя использование избыточных серверов, подключенных к системе хранения по нескольким каналам передачи данных, через несколько HBA, развертывание избыточных сетей передачи данных и сетевых путей доступа, а также использование систем хранения с избыточными контроллерами. Создание и развертывание архитектуры хранения, соответствующей всем этим критериям, может помочь избежать возникновения единой точки отказа. В жизни требования защиты данных для виртуальной серверной инфраструктуры под управлением Hyper‐V более строгие, чем для традиционной «физической» серверной инфраструктуры, так как отказ отдельного сервера может оказать влияние на работоспособность множества приложений разом. Защита данных – это ключевое свойство сетевых систем хранения.

NetApp RAID‐DP® это улучшенная технология RAID с двойной четностью, которая предлагается как уровень RAID по умолчанию для всех систем хранения NetApp. RAID‐DP защищает против одновременного отказа двух дисков в одной RAID‐группе. Она также весьма экономична в использовании; избыточность для группы RAID с параметрами по умолчанию, составляет 12,5%. Такой уровень защиты данных и эффективности хранения делает использование RAID‐DP более безопасным, чем RAID 5, и более эффективным с точки зрения затрат, чем RAID 10.

NetApp Best Practice Recommendation Используйте RAID‐DP, собственную высокопроизводительную реализацию метода RAID‐6 в системах хранения NetApp, чтобы получить лучшую защиту данных на всех RAID‐группах, которые хранят виртуальные диски виртуальных машин Hyper‐V.

Remote LAN Management (RLM) Устройство RLM обеспечивает безопасное автономное подключение к контроллерам систем хранения, которое может быть использовано независимо от состояния и работоспособности сами контролеров. RLM предлагает ряд возможностей удаленного администрирования, включая удаленный доступ, мониторинг, ведение логов и получение уведомлений, а также поиск и устранение неисправностей. RLM также расширяет возможности функций AutoSupport контроллеров NetApp, имея возможности отсылать уведомления даже в случае полной остановки контроллера системы хранения. Сообщения AutoSupport обеспечивают проактивную, упреждающую реакцию службы поддержки NetApp, для того, чтобы обеспечить более быстрый сервис. Для подробностей посетите страницу о Remote LAN Management (RLM) на NetApp NOW.

NetApp Best Practice Recommendation Используйте самую свежую версию firmware контроллера, полок, и Data ONTAP general deployment release, из доступных на сайте NOW (NetApp on the Web). Как необходимый минимум, NetApp рекомендует использовать релиз Data ONTAP release 7.3 или более новый, для применения с Hyper‐V.


4 Использование системы хранения

4.1 Программы и утилиты NetApp

4.1.1 NetApp Windows Host Utilities Kit Windows Host Utilities это набор утилит, созданный NetApp, который модифицирует системные настройки таким образом, что хост‐OS Hyper‐V, или VM OS виртуальной машины работают более надежно при использовании системы хранения NetApp по SAN.

Утилита контролирует наличие необходимых для безошибочной работы патчей и сервис‐паков для OS, проверяет значения и изменяет ключи реестра, устанавливая правильные величины таймутов и настройки параметров HBA. Изменения в ключах реестра и параметрах HBA позволяет хосту правильно обрабатывать события файловера на системе хранения и определяет тип LUN, необходимый для компонентов Windows multipathing. Кроме перечисленного, диагностическая программа (набор скриптов сбора данных) помогает собрать информацию о сервере, конфигурации системы хранения и коммутаторах Fibre Channel. Вывод этих скриптов помогает NetApp Customer Support найти и устранить проблемы вашей конфигурации.

NetApp Windows Host Utilities 5.x поддерживается как на уровне сервера Hyper‐V, так и «гостевых» OS виртуальных машин. Эти «гостевые» OS могут быть из следующего списка: Windows Server 2008/R2, Windows Server 2003, Windows XP, и Windows Vista. Поддерживаются Fibre Channel, iSCSI, а также смешанные соединения, FC и iSCSI вместе. Также поддерживаются аппаратные iSCSI host bus adapters (iSCSI HBA).

NetApp Best Practice Recommendation NetApp настоятельно рекомендует установить Windows Host Utilities Kit на все сервера Hyper‐V. Для Windows Server 2008, NetApp требует установки Windows Host Utilities Kit версии 5.1 или новее. Для Windows Server 2008 R2, требует установки Windows Host Utilities Kit версии 5.2 или новее.

Для подробностей по скачиванию, установке и конфигурированию NetApp Windows Host Utilities 5.x, читайте Windows Host Utilities 5.0 Setup Guide, доступный на сайте NetApp NOW. Дополнительную информацию по установке NetApp Windows Host Utilities Kit 5.x, смотрите главу 3.4.1.1 NetApp Windows Host Utilities Kit в документе TR‐3733: NetApp Implementation Guide for Microsoft Virtualization, и следуйте указанным там пошаговым инструкциям.

4.1.2 Multipathing/MPIO В общем случае, понятие «многопутевое подключение» (multipathing) используется для описания возможности системы использовать более одного пути чтения‐записи данных с устройства хранения. Multipathing это решение высокой доступности, обеспечивающее отказоустойчивость, путем устранения «единой точки отказа» (single‐point‐of failure) в аппаратных компонентах. Multipathing также используется для обеспечения балансировки нагрузки ввода‐вывода, что улучшает показатели производительности системы и приложений.

Microsoft Multipath I/O (MPIO) Microsoft MPIO это функция, которая обеспечивает поддержку использования нескольких каналов передачи данных к устройству хранения. Она увеличивает доступность за счет возможности использовать нескольких независимых путей (path failover) от сервера или кластера к системе хранения. Windows Server 2008 R2 имеет встроенную поддержку Microsoft MPIO.




Microsoft MPIO поддерживается как на хост‐партиции сервера Hyper‐V (parent partition) (независимо от OS виртуальных машин), так и на серверных OS семейства Windows виртуальных машин, то есть исключая Windows XP и Vista.

Microsoft MPIO независим от протокола, и поддерживает iSCSI, Fibre Channel, и SAS.

Microsoft MPIO может расширяться силами партнеров, например NetApp, путем написания device‐specific modules (DSM) для создания более оптимизированных к конкретному устройству решений. DSM, как можно понять из его названия, это модуль, используемый для определения того, как MPIO должен работать с определенными устройствами (например, NetApp LUN). Microsoft предоставляет собственный простейший DSM в Windows Server 2008 R2. Следующие политики балансировки доступны в Microsoft DSM:

• Failover, без балансировки нагрузки (without load balancing).

• Балансировка типа round robin при которой DSM использует все доступные пути для ввода‐вывода, по очереди.

• Балансировка round robin по подмножеству путей, при котором приложение определяет часть путей как заданные для round robin, а часть – для запасных, в случае отказа первых.

• Балансировка по модели dynamic least queue depth.

• Балансировка по модели weighted path.

Вне зависимости от выбранного варианта, Microsoft DSM запоминает выбранную установку и восстанавливает ее после перезагрузки.

NetApp также разработал свой DSM под названием Data ONTAP DSM, который помогает MPIO взаимодействовать с системами хранения NetApp. Подробнее Data ONTAP DSM рассматривается ниже.

Data ONTAP DSM для Windows MPIO The Data ONTAP DSM для Windows MPIO позволяет системам хранения NetApp интегрироваться с Microsoft MPIO в сервере Windows Server 2008 Hyper‐V и обеспечить высокую доступность приложений. Data ONTAP DSM определят список поддерживаемых устройств, и обнаруживает NetApp LUN. Он определяет все пути, указывающие на один и тот же LUN, так что MPIO может сгруппировать их и получить единый виртуальный диск, который можно смонтировать на сервере Windows Server 2008 Hyper‐V. Он также отвечает за взаимодействие с MPIO в том, какой путь должен использоваться для маршрутизации ввода‐вывода, что особенно важно в случае файловера. Возможно существование и использование как множественных активных (multiple active paths), так и множественных резервных, пассивных путей (multiple passive paths). Если все активные пути не работают или не доступны, то DSM автоматически переключаются на резервные, сохраняя доступ хоста к системе хранения. Для серверов Windows Server 2008 Hyper‐V, NetApp рекомендует версию Data ONTAP DSM 3.2R1 или новее. Программа установки поставит в систему как DSM, так и необходимые компоненты Windows MPIO. Программа также устанавливает значения в реестре Windows, и настройки host bus adapter (HBA). Data ONTAP DSM может работать совместно и параллельно с Microsoft DSM на той же системе.

Он поддерживает как сервер Hyper‐V, так и OS виртуальных машин, за исключением Windows XP и Vista, так как Microsoft MPIO не поддерживается на платформах Windows XP и Windows Vista.

Data ONTAP DSM может управлять как путями FCP, так и iSCSI, включая смешанные пути FCP и iSCSI к одному и тому же виртуальному диску (LUN), и может осуществлять балансировку нагрузки, также как и файловер. Data ONTAP DSM также поддерживает несколько различных путей iSCSI (например, два iSCSI HBA, два NIC, один iSCSI HBA и один NIC). В момент публикации, LUN через iSCSI software initiator поддерживались на уровне VM OS.

NetApp Best Practice Recommendation Для высокодоступного подключния к системе хранения, NetApp требует установки поддерживаемой версии ПО multipathing, такого как Data ONTAP DSM for Windows MPIO. Для Windows Server 2008, NetApp требует установки Data ONTAP DSM с версией не ниже 3.2R1. Для Windows Server 2008 R2, NetApp требует установки версии Data ONTAP DSM не ниже 3.3.1. Для списка поддерживаемых версий multipathing software и сопутствующих требований, смотрите NetApp Interoperability Matrix.

Политики балансировки нагрузки в Data ONTAP Data ONTAP DSM for Windows MPIO поддерживает несколько политик балансировки для сервера Windows Server 2008 Hyper‐V. В них входят:

• Least queue depth это политика active‐active, которая отслеживает исходящие очереди по всем путям доступа к данным, и помещает текущую операцию ввода‐вывода в канал с очередью ввода‐вывода наименьшей длины. Эта политика обеспечивает максимальную производительности и пропускную способность, и выбрана политикой по умолчанию.

• Least weighted path это политика active‐passive, которая позволяет пользователю назначить «вес» для каждого пути ввода‐вывода, и использоваться будет путь с наименьшим «весом». «Вес» пути сохраняется при перезагрузке Windows Server 2008. Новый путь выбирается только в случае, если активный путь не работает.

• Failover only это политика active‐passive, весь ввод‐вывод направляется по одному пути, другой путь выбирается только в случае отказа первичного пути.

• Autoassigned похож на failover only за исключением того, что администратор не может изменить активный путь, и DSM самостоятельно выбирает путь для всего ввода‐вывода.

• Round robin это политика active‐active, при которой ввод‐вывод последовательно и по очереди направляется по всем доступным путям.

NetApp Best Practice Recommendation Политика least queue depth policy выбрана по умолчанию и является рекомендуемой NetApp для конфигураций Hyper‐V с MPIO.

Сосуществование Data ONTAP DSM с другими DSM (только iSCSI) Microsoft iSCSI software initiator также включает в себя DSM, который может управлять путями iSCSI. Два этих DSM (Microsoft DSM и Data ONTAP DSM) могут сосуществовать на одной системе, так как оба они присутствуют в соответствующей матрице совместимости. Рекомендуется установить Microsoft iSCSI DSM, даже если вы работаете с iSCSI LUN при помощи Data ONTAP DSM. Когда установлены оба DSM, то Data ONTAP DSM имеет приоритет, при использовании с iSCSI LUN‐ами на NetApp.

Если вы устанавливаете Microsoft iSCSI software initiator на тот же сервер Hyper‐V, на котором уже есть Data ONTAP DSM:

• Установите Windows Host Utilities для соответствующей OS. Для рекомендаций смотрите главу 5.1.1 NetApp Windows Host Utilities Kit в этом документе.

• Проверьте матрицу поддерживаемых версий.

• Если вы хотите использовать Microsoft iSCSI DSM вместо Data ONTAP DSM, убедитесь, что выбрали Microsoft iSCSI DSM отметив пункт Microsoft MPIO multipathing support for iSCSI при установке инициатора. Когда при этом вы устанавливаете Data ONTAP DSM, выберите при установке пункт use only for FCP LUN.

Для подробностей по установке и конфигурированию Data ONTAP DSM, смотрите Data ONTAP DSM for Windows MPIO Installation and Administration Guide, на сайте NetApp NOW. Для дополнительной информации по установке NetApp Windows Host Utilities Kit 5.x, смотрите главы 3.4.1.2 и 3.4.2.2 в TR‐3733: NetApp Implementation Guide for Microsoft Virtualization, и следуйте приведенным пошаговым инструкциям.

iSCSI Multiple Connections Per Sessions Спецификация iSCSI предлагает дополнительную возможность, под названием multiconnection sessions (MCS). MCS позволяет в рамках одной сессии iSCSI использовать множество соединений TCP. Использование MCS и MPIO для параллельного подключения к одному и тому же LUN не поддерживается.

4.1.3 NetApp SnapDrive for Windows SnapDrive это ПО NetApp, которое помогает системному администратору распределять и управлять системой хранения непосредственно с сервера. SnapDrive также дает гибкость использования приложениям и/или системным администраторам задавать свои собственные политики защиты данных. И, что более важно, он позволяет администраторам изменять размеры хранилища на лету, без необходимости прерывать работу сервиса приложений. SnapDrive упрощает сервис управления данными и системой хранения, используя средства хост‐OS и технологии NetApp, скрывая сложные шаги, которые должны быть выполнены на сторонах как хост‐системы (сервера), так и системы хранения, и устраняя зависимость от администратора системы хранения. Ключевые возможности SnapDrive for Windows включают в себя управление хранилищем SAN с хоста, создание консистентных снэпшотов, и быстрое восстановление данных приложений из этих снэпшотов. SnapDrive дополняет собственные средства хост‐OS, такие как файловая система и технологии управления томами, и интегрируется с кластерной технологией, поддерживаемой хост‐OS, обеспечивая высокую доступность сервиса для пользователей и приложений. SnapDrive управляет LUN‐ами на системе хранения, делая их доступными как локальные диски для хостов Windows. Это позволяет хостам Windows взаимодействовать с LUN‐ами так, словно это непосредственно подключенные к серверу диски. SnapDrive обеспечивает следующие возможности:

• Конфигурирование системы хранения в онлайне, расширение LUN, и упрощенное управление.

• Подключение до 128 LUN.

• Интеграция с технологией Data ONTAP Snapshot, создающей мгновенные копии состояния данных на LUN‐ах.

• Интеграция с ПО SnapMirror® для обеспечения катастрофоустойчивости и восстановления с томов, реплицированных как синхронно, так и асинхронно.

• Использование передачи обновлений SnapVault® qtrees для системы‐получателя SnapVault.



• Управление SnapDrive на нескольких хостах.

• Упрощенное распределение хранением в случае использования конфигурации Microsoft failover cluster.

• Управление сессиями iSCSI.

NetApp Best Practice Recommendation NetApp настоятельно рекомендует установить NetApp SnapDrive на все сервера Hyper‐V и SCVMM для того, чтобы быть уверенным в максимальной функциональности решения и поддержке всех ключевых возможностей.

Для Microsoft Windows Server 2008 с включенной ролью Hyper‐V и для Microsoft Hyper‐V Server 2008, установите NetApp SnapDrive for Windows version 6.0 или новее.

Для Microsoft Windows Server 2008 R2 с включенной ролью Hyper‐V,и для Microsoft Hyper‐V Server 2008 R2 для поддержки:

• Обычных возможностей (без поддержки возможностей R2) установите NetApp SnapDrive for Windows version 6.1P2 или новее.

• Новых возможностей (всех новых возможностей R2) установите NetApp SnapDrive for Windows version 6.2 или новее.

NetApp SnapDrive for Windows version 6.0 или новее также поддерживается для установки в OS виртуальной машины (child OS), таких как Microsoft Windows Server 2003, Microsoft Windows Server 2008, и Microsoft Windows Server 2008 R2.

Для детальных инструкций по установке и администрированию (создание и раздача LUN, управление ими, защита данных, и так далее) смотрите SnapDrive for Windows Installation and Administration Guide. Дополнительно, по установке NetApp Windows Host Utilities Kit 5.x, смотрите раздел 3.4.1.3 NetApp SnapDrive for Windows в TR‐3733: NetApp Implementation Guide for Microsoft Virtualization, и следуйте приведенным инструкциям.

Для наиболее свежих данных о поддерживаемом ПО и его версиях, а также сопутствующих требованиях, смотрите NetApp Interoperability Matrix. Сверьтесь с support matrix для подробностей о том, что и какие конфигурации в точности поддерживаются.

4.2 Распределение пространства

4.2.1 Aggregates «Аггрегейт» (aggregate) это виртуализационный уровень в системах хранения NetApp, который абстрагирует логические наборы данных (в дальнейшем мы будем их называть flexible volumes) от физических дисков системы хранения. Использование aggregate, в числе прочего, означает также и то, что ему доступны все IOPS всех индивидуальных физических дисков, входящих в его пул. Концепция aggregate хорошо соответствует разнообразным требованиям пользователей, таким как безопасность, резервное копирование, производительность и совместное использование данных, а также разнообразным смешанным нагрузкам.

NetApp рекомендует использовать отдельный маленький aggregate с RAID‐DP для размещения root volume. Этот aggregate будет хранить файлы, необходимые для запуска и использования GUI‐инструментов управления системой хранения NetApp. Оставшееся пространство физических дисков должно быть помещено в небольшое количество крупных aggregates, так как это



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

NetApp Best Practice Recommendation При конфигурировании aggregate, NetApp рекомендует использовать следующие параметры:

Double Parity: Выберите этот вариант, чтобы получить преимущества использования RAID‐DP, являющийся предпочтительным уровнем RAID для aggregate.

RAID Group Size: NetApp рекомендует оставить значение по умолчанию, которое равно 16 в большинстве случаев.

Disk Selection: «Automatic» выбран по умолчанию, и NetApp рекомендует оставить его.

Disk Size: По умолчанию «Any Size»; Однако NetApp рекомендует по возможности выбирать диски одинакового размера при создании aggregate.

Number of Disks: NetApp требует, чтобы по меньшей мере три диска входило в aggregate. NetApp рекомендует создавать aggregate максимально возможного размера, чтобы получить преимущество от большого количества операций ввода‐вывода со всех входящих в aggregate физических дисков.

Для подробностей о конфигурировании aggregate, смотрите главу 3.6.1 Configure an Aggregate в документе TR‐3733: NetApp Implementation Guide for Microsoft Virtualization и следуйте приведенным там пошаговым инструкциям.

4.2.2 Тома типа Flexible Тома типа flexible (flexible volumes) несут на себе LUN‐ы, к данным которых подключаются сервера Hyper‐V по протоколам FC или iSCSI. Это «виртуальные тома», которые могут существовать, перемещаться и управляться независимо от физического хранилища, состоящего из физических жестких дисков, и могут создаваться и изменять свой размер в зависимости от потребностей приложения.

NetApp Best Practice Recommendation При конфигурировании томов FlexVol, NetApp рекомендует использовать следующие настройки:

Volume Type Selection: Выберите «Flexible» для создания тома типа NetApp FlexVol, который имеет множество преимуществ перед «традиционными» томами, в виртуальной инфраструктуре.

Volume Name: NetApp рекомендует использовать комбинацию имени хоста Hyper‐V/имени кластера и соответствующего диска в виртуальной инфраструктуре, а также, при необходимости, политики репликации, например: «HostA_Disk2» и «HostB_Disk1_4hmirror».

Language: NetApp рекомендует оставлять значение по умолчанию, за исключением тех случаев, когда вы имеете особые основания выбрать что‐то иное.

UTF‐8: NetApp рекомендует принять выбранное по умолчанию значение, если у вас нет серьезных


оснований его изменить.

Space Guarantee: Выберите желаемый вариант опции. Для использования thin provisioning, выберите вариант «None». Для подробностей смотрите главу 5.1 Storage Thin Provisioning в этом документе.

Snapshot Reserve: NetApp рекомендует, чтобы все тома были сконфигурированы с этим параметром равным «0%» и расписание снэпшотов по умолчанию было отключено. О подробностях по отключению расписания снэпшотов, смотрите главу 3.6.2.1 Create a NetApp Flexible Volume в документе TR‐3733: NetApp Implementation Guide for Microsoft Virtualization, и следуйте приведенными инструкциям в шаге 7.

Для подробностей о конфигурировании томов типа flexible, или FlexVol, смотрите главу 3.6.2 Configure a Flexible Volume в документе TR‐3733: NetApp Implementation Guide for Microsoft Virtualization, и следуйте пошаговым инструкциям.

4.2.3 LUN LUN это объект системы хранения, и который непосредственно используются серверами Hyper‐V.

Сервера Hyper‐V получают доступ к LUN‐ам с помощью протоколов FC или iSCSI, как к физическим дискам. Они могут использоваться для следующих надобностей виртуальной инфраструктуры Microsoft:

• Хост‐партиция сервера Hyper‐V (parent partition): В установке с загрузкой из SAN, Windows Server 2008 R2 может быть установлен на LUN, распределенный, зонированный (во время установки поддерживается только один путь, MPIO поддерживается после установки Hyper‐V), и подключенный к физическому серверу Hyper‐V.

• Windows failover clustering quorum или witness disk: При необходимости использования live migration и high availability для виртуальных машин Hyper‐V, необходимо сконфигурировать Windows failover clustering (WFC). Для установки и конфигурирования Windows failover clustering, необходимо создать и сконфигурировать quorum disk. Необходимо, чтобы все сервера Hyper‐V в кластере Windows failover cluster (WFC) имели доступ к этому диску, использование сетевой системы хранения, такой как NetApp, позволяет удовлетворить этому требованию.

• Хранилище VHD: Физический диск или LUN, распределенный на сервер Hyper‐V может быть использован для хранения файлов виртуальных дисков, virtual hard disk (VHD), которые виртуальные машины используют как свои виртуальные диски.

• Диск типа pass‐through disk для виртуальных машин: Физический диск или LUN, подключенный к хост‐системе Hyper‐V в состоянии offline, может быть назначен виртуальной машине для использования его в качестве ее виртуального диска. Подключенный в offline к серверу Hyper‐V LUN можно использовать из виртуальной машины напрямую, обходя файловую систему хост‐сервера Hyper‐V, и обеспечивая отсутствие одновременного доступа к разделу из хост‐системы и виртуальной машины.

• Непосредственно подключенный в VM диск: Физический диск или LUN может быть подключен непосредственно в VM сервера Hyper‐V, полностью обходя архитектуру организации хранилища Hyper‐V и его файловую систему. VM OS может использовать, например Microsoft iSCSI Software Initiator для непосредственного подключения к LUN, используя протокол iSCSI, с помощью одного или нескольких виртуальных сетевых




адаптеров. OS виртуальной машины будет иметь доступ, управлять и хранить данные на дисках такого непосредственно подключенного LUN также, как это делает хост‐OS Hyper‐V.

Процесс создания LUN Процедура создания LUN одинакова и не зависит от протокола доступа к этому LUN. Однако вам может потребоваться создать initiator group (igroup) с правильным типом протокола. LUN‐ы можно создавать с помощью командлайнового интерфейса Data ONTAP (CLI), с использованием веб‐интерфейса FilerView®, или с помощью установленной на хост‐сервере программы NetApp SnapDrive.

NetApp Best Practice Recommendation Если у вас установлен NetApp SnapDrive for Windows, настоятельно рекомендуется использовать SnapDrive для конфигурирования initiator groups. Сверьтесь с документацией на вашу версию SnapDrive для детальных инструкций. Для конфигурирования LUN, NetApp рекомендует следующие настройки:

LUN Type: Убедитесь, что вы выбрали правильный LUN type, соответствующий вашей системе: «Dedicated» для индивидуальных серверов и «Shared» для кластерных узлов.

LUN Protocol Type: Для подробностей по выбору правильного значения этого параметра смотрите главу Выбор правильного типа LUN, ниже.

Space Reserved: NetApp настоятельно рекомендует не включать эту опцию, чтобы LUN не резервировал пространство при своем создании. Для подробностей смотрите главу 5.1 Thin Provisioning в этом документе.

Для детального рассмотрения темы конфигурирования нового LUN, смотрите главу 3.8 Disk Provisioning on Windows 2008 Servers в документе TR‐3733: NetApp Implementation Guide for Microsoft Virtualization, и следуйте приведенным там пошаговым инструкциям.

Выбор правильного типа LUN При создании LUN с помощью веб‐интерфейса FilerView или CLI, параметр «LUN Type» играет очень важную роль. Этот параметр определяет структуру будущего диска на LUN. Важно определить правильный тип LUN, чтобы быть уверенным, что LUN правильно расположен относительно структур хранилища NetApp («правильно выровнен», properly aligned) и файловой системы на нем. Причина для этого – достижение оптимальной производительности системы хранения, когда ввод‐вывод системы хранения проводится выровненным относительно 4096‐байтной границы блока системы хранения. Неправильно выровненный ввод‐вывод увеличивает задержки операций за счет того, что при чтении и записи считывается и записывается больше блоков, чем на самом деле нужно. Эта проблема не является специфичной для NetApp. Ей подвержены системы хранения любы производителей или серверных платформ.

Выбор типа LUN зависит от типа OS, версии OS, цели использования диска, и версии Data ONTAP. Если при создании LUN был выбран неверный его тип, то следует создать новый LUN, с правильным типом, а затем перенести все данные со старого LUN, с неверным типом, на новый.

Для полной информации о типах LUN для различных OS, смотрите Block Access Management Guide соответствующий вашей версии Data ONTAP.



Воспользуйтесь данным приведенных ниже таблиц для определения правильного типа LUN для конфигурирования их с Windows Server 2008, для инсталляции его с ролью Hyper‐V и без нее.

Таблица 4‐1) Типы LUN для использования с Data ONTAP 7.3.1 и новее.

Data ONTAP 7.3.1 или новее

Windows Server 2008 Physical Server w/o Hyper‐V

Windows Server 2008 Hyper‐V Server Physical Disk

Windows Server 2008 Hyper‐V Server Pass‐Through Disk

С использованием SnapDrive

windows_gpt hyper_v LUN type of child OS

Без использования SnapDrive

windows_2008 windows_2008 LUN type of child OS

Таблица 4‐2) Типы LUN для использования от Data ONTAP 7.2.5 до 7.3.0.

Data ONTAP от 7.2.5 до 7.3.0





windows_gpt windows_gpt LUN type of child OS


windows_2008 windows_2008 LUN type of child OS

Таблица 4‐3) Типы LUN для использования с Data ONTAP 7.2.4 и ранее.

Data ONTAP 7.2.4 или старее





linux linux LUN type of child OS


linux linux LUN type of child OS

Для Data ONTAP версии 7.3 и ранее, тип LUN «windows_2008» доступен только из командной строки консоли Data ONTAP CLI. По этой причине LUN‐ы для хост‐партиции Hyper‐V (parent partition) и VM OS типа Windows Server 2008 (child partititon) должен быть создан с помощью команд в Data ONTAP CLI.

Для тех LUN, которые напрямую передаются (directly mapped) в OS виртуальной машины, с использованием iSCSI software initiator, работающего в VM, тип LUN должен быть выбран при создании LUN и соответствовать типу VM OS. Также следует выбрать тип LUN и при подключении в VM OS при использовании pass‐through disk сконфигурированного для сервера Hyper‐V, тип LUN для соответствующей VM OS должен быть выбран при создании LUN.

NetApp Best Practice Recommendation NetApp требует, чтобы правильный LUN protocol type был указан при создании всех LUN‐ов, созданных для сервера Hyper‐V. Ошибка при его указании приводит к неверно выровненной файловой системе VM, и, как результат, деградации производительности (от незначительной до

средней) в зависимости от характера доступа и данных).

Если вы выбрали неверный LUN Protocol Type и после этого отформатировали получившийся диск, то диск будет неправильно выровнен со структурами системы хранения NetApp. Вам потребуется создать новый LUN, выбрать для него правильный LUN Protocol Type, и сформатировать LUN. Вы должны перенести на него виртуальные машины и их VHD со старого LUN с неправильным LUN Protocol Type. Использование Quick Storage Migration может вам помочь в этой операции, но необходим даунтайм для VM, как с помощью, так и без Qucik Storage Migration, при проведении перемещения VM и их VHD со старого LUN на новый LUN.

Не переносите файлы конфигурации VM с LUN на LUN. При миграции VM есть два возможных варианта переноса конфигураций.

1. Вы должны сделать export для VM, перед тем как перемещать данные. Когда файлы перенесены, вы можете удалять старую VM и импортировать VM, используя файлы, созданные при экспорте VM.

2. Удалите VM и пересоздайте ее на новом LUN, выбрав при этом нужный VHD, расположенный уже на новом LUN.

4.3 Локальные диски (DAS) или сетевая система хранения (SAN) для Microsoft HyperV Server Microsoft Hyper‐V может использовать как непосредственно подключенные локальные диски (direct attached storage или DAS, диски типа SAS, SATA) и сетевые системы хранения (например Fibre Channel или iSCSI, в настоящий момент нет поддержки NAS). Несмотря на то, что Hyper‐V поддерживает использование недорогого DAS, быстро становится ясно, например, при увеличении размера решения на Microsoft Hyper‐V более чем на несколько серверов, что преимущества использования сетевой системы хранения значительно перевешивают невысокую цену DAS. По меньшей мере, это возможность использования «быстрой» и «живой» миграции (quick migration/live migration) и высокая доступность данных за счет интеграции Hyper‐V в Windows failover cluster, который требует для своей работы сетевого хранилища.

4.3.1 Traditional Volume Том типа traditional volume, в терминах данного документа, определяется как физический диск, подключенный к хост‐OS Hyper‐V (parent partition), и выделен в исключительное использование только этой Hyper‐V parent partition. Том типа traditional volume может быть создан как на локальных дисках сервера (DAS), так и на сетевом хранилище, таком как LUN на системе хранения NetApp.

4.3.2 Standard Cluster Volume Standard cluster volume, в терминах данного документа, определяется как подключенный к хост‐OS Hyper‐V (parent partition) физический диск, также соединенный с несколькими серверами Hyper‐V, сконфигурированными как узлы кластера и части единого Windows failover cluster. Однако только один узел Hyper‐V в кластере имеет доступ как на чтение, так и на запись на standard cluster volume так, чтобы можно было разместить на нем данные виртуальной машины, и иметь доступ к ее VHD на томе типа standard cluster volume. Том типа standard cluster volume может быть создан только на сетевом хранилище, например как LUN, подключенный с системы хранения NetApp, к которому также подключены и все прочие кластерные узлы Hyper‐V, входящие в failover cluster.

Ограничения виртуальных машин Когда вы развертываете Hyper‐V с томами типа standard cluster volumes, Microsoft рекомендует делать маппинг виртуальных машин к SAN LUN «один к одному». Многие воспринимают это как рекомендацию Microsoft делать «одну VM на LUN». Причины, стоящие за такой рекомендацией просты: Если несколько виртуальных машин расположены на одном standard cluster volume, то администратор не может сделать quick migration для этих VM между узлами кластера Hyper‐V по‐отдельности; их придется мигрировать всей группой.

Это является результатом того, что standard cluster volume является корнем всех кластерных ресурсов для каждой VM; всем VM и их VHD расположенным на этом томе, необходимо перейти в оффлайн одновременно, для миграции хотя бы одной VM (из всех) между узлами кластера Hyper‐V. Кроме этого, Hyper‐V не может мигрировать виртуальные машины параллельно, каждая из них мигрируется отдельно, каждую VM необходимо перевести в сохраненное состояние и последовательно вернуть в рабочее состояние, в ходе процесса quick migration.

Вследствие этого вынужденного увеличенного даунтайма при попытке миграции отдельной VM со standard cluster volume, на котором размещены другие виртуальные машины, Microsoft рекомендует использовать маппинг виртуальной машины на SAN LUN, сконфигурированный как standard cluster volume, как «один к одному». Это также верно и при развертывании Windows Server 2008 Hyper‐V, и Windows Server 2008 R2 Hyper‐V.

Windows Server 2008 HyperV Для Windows Server 2008 Hyper‐V, так как только один серверный узел Hyper‐V может нести VM и иметь доступ к VHD на standard cluster volume, миграция виртуальных машин и их ресурсов (например файлов VHD) между узлами Hyper‐V возможна только в режиме quick migration. Это означает необходимость учитывать неизбежность даунтайма для VM, когда она перемещается между узлами кластера.

Windows Server 2008 R2 HyperV Для Windows Server 2008 R2 Hyper‐V, хотя только один узел кластера Hyper‐V может нести VM и иметь доступ к ее VHD на standard cluster volume, поддерживаются как quick migration так и live migration как методы миграции VM в «чистом» кластере Windows Server 2008 R2 Hyper‐V.

Live migration это новая и долгожданная возможность Windows Server R2, которая позволяет миграцию VM между кластерными узлами Hyper‐V, входящими в Windows failover cluster, без прерывания работы сервиса. Пользователи, подключенные к VM, проходящей live migration могут отметить небольшое изменение в производительности в отдельных моментах, но в целом пользовательское подключение к приложениям виртуальной машины и ее данным не прерываются, и не нужны какие‐то специальные меры, когда виртуальная машина мигрирует с одного узла кластера Hyper‐V на другой. Live migration возможна с томами типа standard cluster volumes; том типа cluster shared volume не обязателен для работы live migration на кластере Windows Server 2008 R2 Hyper‐V. Microsoft по‐прежнему рекомендует использовать маппинг «один к одному» для виртуальных машин и томов standard cluster volumes.

4.3.3 Cluster Shared Volume (CSV) Тип тома cluster shared volume или CSV, в терминах данного документа, это физический диск, подключенный к хост‐OS Hyper‐V (parent partition), и совместно используемый несколькими кластерными узлами Hyper‐V, сконфигурированными как части единого Windows failover cluster. Эта возможность отказоустойчивого кластера доступная только в Windows Server 2008 R2, и только

для использования роли Hyper‐V. CSV может быть создан только на сетевом хранилище, к которому могут подсоединится и остальные узлы отказоустойчивого кластера Hyper‐V, например на LUN, созданном на системе хранения NetApp.

Функция CSV как файловой системы с распределенным доступом оптимизирована для Hyper‐V и использует стандартную файловую систему NTFS. Это означает что любое сетевое хранилище, которое может работать в качестве standard cluster volume может быть сконфигурировано как CSV. CSV позволяет нескольким серверам Hyper‐V одновременно иметь доступ к одному и тому же диску или LUN. Появление CSV в in Windows Server 2008 R2 Hyper‐V несет с собой множество новых возможностей, включая:

• Упрощенное управление хранилищем: больше VM на меньшем числе LUN.

• Независимое перемещение VM: Когда несколько кластерных VM совместно используют один LUN, они могут мигрировать между узлами кластера Hyper‐V, независимо друг от друга.

• Общее пространство имен (namespace): Для CSV не нужно назначать букву диска, что уменьшает связанные с этим ограничения, и устраняет необходимость управлять GUID‐ами и точками монтирования.

• Улучшенная доступность: CSV может обнаруживать и обрабатывать события отказов, которые могли бы вызвать недоступность VM.

• Эффективность хранения: Размещение многих VM в одном и том же LUN упрощает планирование емкости и снижает величину пространства, зарезервированного для возможностей дальнейшего роста, но не используемого.

CSV реализован через так называемый minifilter для файловой системы, распложенный в драйвере CSVfilter.sys, как показано на рисунке 4‐1, он отвечает за перехват запросов метаданных NTFS и всех операций ввода‐вывода.

Рисунок 4‐1) CSV реализован как file system minifilter, показан в красном кружке выше.

Кластерный узел Hyper‐V, на котором LUN включается как CSV, становится его «владельцем» (owner), также называемым узлом‐координатором («coordinator» node) для этого CSV. Все узлы кластера Hyper‐V имеют доступ к CSV параллельно, но «не‐владельцы» (non‐owner nodes) CSV должны направлять все операции с метаданными (такие, как изменения размера файла или его свойств) узлу‐«владельцу» CSV, но операции ввода‐вывода данных могут проводиться непосредственно с CSV; это показано на рисунке 4‐2.

Рисунок 4‐2) Операции с метаданными и данными на CSVмежду узлами Hyper‐V Cluster

4.3.3.1 Cluster Shared Volumes Single Namespace Особенность, отличающая CSV от standard cluster volume это существование «единого пространства имен» (single namespace) для всех серверных узлов Hyper‐V в кластере, когда любой файл (например VHD) имеет один и тот же путь доступа и имя с любого серверного узла кластера Hyper‐V.

Все CSV хранятся в директориях и поддиректориях в корневом каталоге %systemdrive%\ClusterStorage, как показано на рисунке 4‐3.

Рисунок 4‐3) Cluster shared volume single namespace.

Как видно на рисунке 4‐3, тома CSV (Volume1, Volume2, и Volume3) расположены в директории ClusterStorage. Если системный диск C:\ то полный путь будет:

C:\ClusterStorage\Volume1



Это означает, что для каждого CSV не нужно назначать ни имя буквы диска, ни настраивать Volume Mount Points или GUIDs. Это снимает ограничения, связанные с необходимостью назначения буквы диска, и упрощает управление томами CSV.

4.3.3.2 Процесс Live Migration Как и для standard cluster volume в Windows Server 2008 R2 Hyper‐V, миграция типа live migration поддерживается и для томов типа CSV. Однако, использование CSV для системы Hyper‐V имеет свои преимущества при выполнении live migration, в особенности по сравнению с использованием standard cluster volumes; когда live migration виртуальных машин происходит на CSV, то уменьшается период «заторможенности» в конце процесса live migration. Так происходит по причине того, что standard cluster volume должен быть размонтирован и смонтирован заново в ходе процесса Live Migration, что вызывает дополнительную задержку, и может влиять на доступность виртуальных машин, но это не делается для CSV, и они видны со всех узлов кластера Hyper‐V.

4.3.3.3 Virtual Machine Architecture Так как CSV позволяет осуществлять параллельный доступ к VM и их VHD для всех узлов кластера Hyper‐V, то поэтому Microsoft не ограничивает их использование правилом «одна виртуальная машина на LUN». По этой причине администратор может размещать любое количество виртуальных машин и их файлов VHD на томе типа CSV, пока система хранения имеет достаточно производительности обрабатывать обращения виртуальных машин к файлам, расположенным на ней в CSV.

Виртуальные машины, использующие диски типа pass‐through также поддерживают live migration, но диски pass‐through нельзя сделать CSV. Однако, вы можете выбрать хранить конфигурационные файлы на томе CSV и/или использовать VHD для системного тома, храня его на CSV, используя диски pass‐through для всех других потребностей VM.

4.3.3.4 Dynamic I/O Redirection Результатом усовершенствования механизмов Windows failover в with Windows Server 2008 R2, является улучшение устойчивости к сбоям внутри кластерных узлов кластера Hyper‐V. С появлением CSV добавилась также новая возможность, под названием dynamic I/O redirection, которая позволяет вводу‐выводу как по локальной сети, так и в SAN, перенаправляться по доступным соединениям внутри кластера, как показано на рисунке 4‐4. Когда ввод‐вывод к CSV перенаправлен, заносится сообщение в лог событий Windows, а также отображается состояние в Failover Cluster Manager так, как это показано на рисунке Figure 4‐5.

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

NetApp Best Practice Recommendation Networks: Вдобавок к NIC, установленным в сервер Hyper‐V для управления, трафика виртуальных машин, IP storage, и так далее, NetApp настоятельно рекомендует вам выделить физический адаптер для трафика CSV. Такой адаптер должен быть минимум 1GB. Если вы используете большие сервера (16 LCPUs+, 64GB+), планируете широко использовать CSV (большое их

количество), и/или планируете использовать динамически балансируемые VM в кластере с помощью SCVMM, либо широко использовать live migration, вам следует обдумать возможность использовать для трафика CSV адаптеров 10GB Ethernet.

Storage: NetApp настоятельно рекомендует сконфигурировать и использовать MPIO на всех узлах кластера Hyper‐V, чтобы свести к минимуму возможность CSV I/O redirection.

Подробности о конфигурировании MPIO с системами хранения NetApp можно посмотреть в главе 4.1.2 Multipathing/MPIO этого документа. Кроме этого просмотрите NetApp Interoperability Matrix для сведений о поддерживаемом ПО, его версиях и сопутствующих требованиях.

Microsoft приводит дополнительные рекомендации в документах Hyper‐V: Using Hyper‐V and Failover Clustering и Hyper‐V: Using Live Migration with Cluster Shared Volumes in Windows Server 2008 R2, рекомендации которых поддерживаются и NetApp, поэтому мы также рекомендуем просмотреть все эти документы, и максимально использовать их рекомендации в вашей системе, чтобы быть уверенными в максимальной производительности и надежности решения.

Риунок 4‐4) Перенаправление ввода‐вывода для тома CSV.

Рисунок 4‐5) Перенаправление ввода‐вывода в CSV показано как «Redirected Access» в панели Failover Cluster Manager MMC.

Случаи отказов с CSV Первый тип отказа, который может повлиять на CSV, это потеря соединения между узлом сервера Hyper‐V и сетевой системой хранения. Так как Hyper‐V поддерживает подключение к хранилищу как по iSCSI,так и по Fibre Channel, CSV будет обрабатывать потерю соединения как по IP‐сети (iSCSI), так и по сети Fibre Channel. Как показано на рисунке 4‐6, если соединение SAN от узла Hyper‐V server node 1 отказало, то операции ввода‐вывода будут перенаправлены через IP‐сеть на узел Hyper‐V server node 2. Hyper‐V server node 2 будет обрабатывать все операции ввода‐вывода к SAN, идущие с Hyper‐V server node 1.

Рисунок 4‐6) Перенаправление ввода‐вывода для CSV в случае проблем с путем доступа в SAN.

NetApp Best Practice Recommendation Если администратор обнаружил факт CSV I/O redirection для определенного CSV, администратор должен немедленно начать live migration всех VM, размещенных на этом CSV на другой узел.

Второй тип отказа, на который должен отреагировать CSV, это проблема с сетевым доступом. Как показано на рисунке 4‐7, если кластер обнаруживает отказ подключения по локальной сети, он перенаправляет сетевой трафик через следующий доступный путь на узле кластера Hyper‐V.

Третий тип отказа – отказ целиком узла Hyper‐V. Если этот узел кластера Hyper‐V был owner для каких‐то CSV, то произойдет перенос ownership этого CSV на другой узел Hyper‐V, как показано на рисунке Figure 4‐8.

Рисунок 4‐7) Перенаправление ввода‐вывода для CSV в случае проблем с путем доступа в локальной сети.

Рисукок 4‐8) В случае отказа кластерного узла Hyper‐V переносится Volume Ownership.

4.3.3.5 Direct I/O Как уже было рассмотрено ранее, в начале темы Cluster Shared Volume (CSV) в главе 4.3.3, хотя все узлы кластера Hyper‐V имеют доступ к CSV параллельно, узлы, не являющиеся владельцами CSV (non‐owner) должны перенаправлять все операции с метаданными (такие, как изменения размера файла, или его свойств) на «узел‐владелец» CSV (owner node), но операции ввода‐вывода с

данными на CSV могут производиться непосредственно; как это работает было показано на рисунке 4‐2 ранее. Однако, для ввода‐вывода виртуальных машин на non‐owner nodes, доступ к данным на CSV производится через новый механизм, под названием direct I/O.

Direct I/O используется для работы с томами типа CSV, и позволяют производить операции ввода‐вывода виртуальной машины с повышенной производительностью. Это достигнуто за счет разделения транзакции ввода‐вывода, посылкой операций с NTFS metadata на узел‐владелец CSV (owner node) через сеть, в то время, как ввод‐вывод данных поступает непосредственно на дисковый драйвер и систему хранения. Посылая ввод‐вывод данных непосредственно из минидрайвера файловой системы (CSVFilter.sys) в дисковый драйвер (disk.sys), CSV обходит все локальные файловые системы и тома/партиции, работающие на non‐owner nodes, как показано на рисунке 4‐9.

Рисунок 4‐9) Direct I/O обходит средства обработки файловой системы/тома/партиции для CSV на узле non‐owner.

4.3.3.6 Резервное копирование и восстановление Резервное копирование и восстановление для томов CSV в среде Hyper‐V может быть непростым процессом. Microsoft объявила, что все вендоры должны будут внести изменения в свои продукты, для поддержки резервного копирования и восстановления виртуальных машин, размещенных в CSV, а также самих томов CSV.

Почему требуются эти изменения? Архитектура CSV достаточно сложна, поэтому мы не станем углубляться в эту довольно обширную дискуссию. Тем не менее, можно сказать, что архитектура CSV вводит мелкие изменения в то, как обрабатываются данные в системе отказоустойчивого кластера (Failover Cluster). Как уже обсуждалось в начале главы 4.3.3 Cluster Shared Volumes, когда происходит резервное копирование, то owner node становится тем, кто может получить

консистентную резервную копию виртуальных машин, размещенных в CSV. Хотя к CSV имеется обычный доступ для ввода‐вывода данных со всех узлов кластера, независимо от их режима owner или non‐owner, только owner node, единственный в кластере имеет доступ к компонентам Volume Shadow Service (VSS). Так как инфраструктура VSS имеется только на owner node, это единственный узел, который может делать резервную копию VM консистентным образом. По этой причине, Cluster Shared Volume передается по узлам кластера Hyper‐V, чтобы провести резервное копирование виртуальных машин. Чтобы сделать это возможным, CSV ownership может переключаться многократно во время обычного «окна» резервного копирования. Приложение резервного копирования должно позаботиться об этих изменениях, и иметь возможность делать резервное копирование виртуальных машин с помощью VSS.

Выпуск продукта NetApp SnapManager® for Hyper‐V запланирован на конец 2009 года * . SnapManager for Hyper‐V (SMHV) будет поддерживать резервное копирование и восстановление виртуальных машин, размещенных в CSV, с использованием технологий NetApp Snapshot. SMHV будет иметь возможность обеспечивать консистентность снэпшотов виртуальных машин; это включает в себя не только саму OS виртуальной машины, но и любое приложение, совместимое с технологией Volume Shadow Service (VSS).

NetApp Best Practice Recommendation Так как все резервные копии должны быть сделаны скоординировано и проводиться на «узле‐владельце» CSV, NetApp рекомендует администраторам отдельно задуматься над тем, как создать и разместить виртуальные машины и CSV по серверам Hyper‐V.

В некоторых системах следует создать большее количество небольших по объему CSV, или же напротив, небольшое число CSV большего размера, в соответствии с индивидуальными требованиями решения.

Вне зависимости от вопросов создания и размещения CSV в кластере Hyper‐V Cluster, рекомендация NetApp состоит в том, чтобы поддерживать баланс VM, размещенных на CSV, насколько это представляется возможным. Организовав правильное размещение VM по томам CSV, вы сбалансируете нагрузку операций резервного копирования по всем томам CSV.

NetApp просит администраторов всегда оценивать производительность перед развертыванием томов CSV на серверах Hyper‐V.

4.3.3.7 Создание виртуальной машины Создание виртуальных машин с использованием CSV под Hyper‐V может потребовать выполнения ряда предварительных действий. По ряду тех же причин, о которых мы говорили в теме резервного копирования и восстановления данных на CSV, следует изменить и процесс создания виртуальных машин с использованием CSV.

Рассмотренная ранее схема работы ввода‐вывода для данных и метаданных на узлах кластера Hyper‐V показывает, что может быть заметная разница в производительности при работе с диском через owner или non‐owner узлы. Microsoft System Center Virtual Machine Manager (SCVMM) 2008 R2 различает owner и non‐owner узел при создании виртуальной машины на узлах кластера Hyper‐

* SnapManager for Hyper‐V (SMHV) уже выпущен и доступен на момент перевода этого документа

V. При развертывании VM, он создает VHD на томе CSV, направляя все операции через CSV owner node. Как результат, VHD создается на узле Hyper‐V CSV owner node в первую очередь, а затем создается VM на том хосте, который администратор выбрал для его создания в «мастере» SCVMM. Так как CSV имеют единое пространство имен, путь к VHD остается одним и тем же, вне зависимости от того, на каком сервере Hyper‐V он создан.

Этот принцип, реализованный Microsoft в ее продукте SCVMM, поможет вам правильно создать VM и их VHD при использовании CSV, даже если вы создаете их без использования SCVMM.

NetApp Best Practice Recommendation При использовании Hyper‐V Manager для создания новой VM, сначала создайте VHD на нужном вам томе CSV, делая это с узла Hyper‐V, являющегося CSV owner node. Когда вы используете Failover Cluster Manager, также начните создание новой VM, с создания VHD выбрав узел CSV owner node. После того, как создан VHD, перейдите к созданию VM на любом узле кластера Hyper‐V, выбрав ранее сделанный VHD в ходе процесса создания VM.

Если для развертывания VM вы используете SCVMM, то дополнительные шаги не требуются.

4.4 Распределение места под виртуальную машину Виртуальные машины Microsoft Hyper‐V могут хранить свои данные в файлах VHD, дисках типа pass‐through, или в напрямую подключенных к виртуальной машине LUN‐ах, используя Microsoft iSCSI Software Initiator. Во всех трех случаях диски форматируются файловой системой OS виртуальной машины.

4.4.1 Виртуальные жесткие диски (VHD) Одна из возможностей для использования пространства хранения для VM в Microsoft Hyper‐V это использование так называемых «виртуальных жестких дисков» (virtual hard disks) или VHD. VHD позволяют вам предоставить пространство хранения для VM, тогда как само это пространство будет находиться внутри файла VHD, расположенного на физическом диске, сформатированном в NTFS, и подключенном к хост‐системе Hyper‐V (parent partition).

Часто такие физические диски являются LUN‐ами на общем хранилище, подключенном по Fibre Channel или iSCSI. Использование VHD предлагает такие преимущества, как улучшенную управляемость и переносимость, связанную с тем, что все хранилище данных VM свернуто в один файл. Существует три разных типа VHD: динамически расширяемый VHD, VHD фиксированного размера, и дифференциальный VHD.

VHD фиксированного размера Этот тип VHD занимает все сконфигурированное пространство в момент своего создания; как следствие он не будет увеличиваться при работе VM ни при каких обстоятельствах. По этой причине VHD фиксированного размера имеет самое низкое влияние на производительность, в сравнении с другими типами Hyper‐V VHD. Жесткие и порой избыточные требования к хранилищу со стороны такого типа VHD может быть смягчены с использованием ряда технологий NetApp, таких как thin provisioning и дедупликация (для подробностей смотрите Увеличение эффективности и гибкости в разделе 5).

NetApp Best Practice Recommendation Настоятельно рекомендуется использовать VHD фиксированного размера для достижения наилучшей производительности в среде Microsoft virtual environment. Сведите к минимуму

использование динамически расширяемых и дифференциальных VHD в продакшн‐применении из за значительного влияния их на производительность, за исключением случаев, когда вы имеете явную и однозначную причину использовать VHD этих типов.

Динамически расширяемый VHD Этот тип VHD не занимает все заданное при конфигурировании место в момент создания; по этой причине, при работе VM он будет расширяться, по мере того, как данные будут записываться на диск, но не более чем заданного при конфигурировании VHD размера. В первую очередь «динамически расширяемый» VHD отличается от VHD фиксированного размера в области производительности, так как имеет наибольшие накладные расходы в сравнении с другими типами Hyper‐V VHD. Наибольшее влияние на производительность оказывает процесс расширения VHD во время работы VM и записи данных на виртуальный диск. Кроме этого, когда Hyper‐V расширяет VHD во время работы, это может привести к проблемам в выравнивании файловой системы, а также ведет к проблемам фрагментации. Поэтому OS виртуальной машины должна адекватно наблюдаться и управляться, чтобы предотвратить деградацию производительности OS VM. Однако есть причины предпочесть такой тип VHD, например, для систем тестирования и разработки, или для сценария, когда используемые данные могут значительно и непредсказуемо увеличиваться в объемах.

Дифференциальный VHD Этот тип VHD не создается во время начального конфигурирования VM, а используется, когда снэпшот Hyper‐V берется с существующей VM. Дифференциальный VHD указывает на породивший его VHD, который может быть VHD любого типа, и работает подобно динамически расширяемому VHD. По причине такого сходства с динамически расширяемым VHD, для дифференциального VHD действуют те же ограничения в производительности, при его использовании надо принимать во внимание те же моменты. Отметьте, что «снэпшоты Hyper‐V» никак не связаны со снэпшотами по технологии NetApp Snapshot.

4.4.2 Диски типа PassThrough Диски типа pass‐through, это диски, которые подключаются непосредственно на хост‐сервер Hyper‐V, но доступны напрямую из VM, и форматируются файловой системой OS самой виртуальной машины. Диски типа pass‐through лучше подходят для больших по объему данных (обычно более 300 ‐ 500GB) и предельно строгих требований по вводу‐выводу. Одним из ограничений дисков pass‐through в VM является то, что Hyper‐V не поддерживает на них свои снэпшоты. По этой причине NetApp рекомендует ограничить использование дисков pass‐through в вашей системе Hyper‐V, исключая перечисленные выше случаи.

NetApp Best Practice Recommendation Хотя использование fixed‐size VHD настоятельно рекомендуется для большинства конфигураций VM, они также имеют ряд ограничений. По этой причине NetApp рекомендует использовать диски типа pass‐through для VM, работающих с большими наборами данных, обычно больше 300 ‐ 500GB, с предельно строгими требованиями по вводу‐выводу, и для виртуальных дисков более 2TB объема.

4.4.3 Диск, презентуемый непосредственно в VM OS Кроме использования VHD и дисков типа pass‐through, для конфигурирования дополнительного пространства хранения в VM, вы можете также сконфигурировать хранилище непосредственно из

OS установленной в VM, с помощью программного iSCSI initiator, установленного в OS виртуальной машины.

Это позволяет вам распределять хранилище непосредственно в VM для инсталляции приложений и хранения данных приложений. Можно использовать NetApp SnapDrive for Windows для распределения хранилища в VM, что позволит вам также управлять приложениями с помощью продуктов семейства NetApp SnapManager. NetApp поддерживает все продукты SnapManager, такие как SnapManager for Microsoft Exchange, SharePoint® Server, SQL Server, а также for SAP® и Oracle®, работающие в виртуальной машине Hyper‐V.

В настоящее время Microsoft не поддерживает загрузку OS в VM через iSCSI, который замаплен на VM по сети. Если необходимо загружать VM c iSCSI LUN, то iSCSI LUN должен быть сконфигурирован для хост‐системы Hyper‐V как pass‐through disk, и затем замаплен на VM.

NetApp Best Practice Recommendation Для таки продуктов NetApp как SnapManage, работающих в «гостевых» OS и поддерживающих защиту данных с помощью SnapMirror, необходимо использование LUN‐ов, распределенных напрямую в «гостевую» OS виртуальной машины.

4.4.4 Виртуальные дисковые устройства: IDE vs. SCSI Как видно из Таблицы 4‐4 ниже, существуют два способа презентования, или «представления», диска в Hyper‐V VM при использовании VHD или диска pass‐through: IDE‐ или SCSI‐устройство. При презентовании первого виртуального диска в VM нужно использовать IDE‐устройство, но администратор может выбирать между IDE или SCSI когда подключает следующие (после первого) диски к VM.

Таблица 4‐4) Таблица сравнения устройств хранения в Hyper‐V.

DAS или SAN на хосте, VHD или Pass‐Through Disk на хосте, представленный в VM как IDE

DAS или SAN на хосте, VHD или Pass‐Through Disk на хосте, представленный в VM как SCSI

Не представлен для хоста, представлен для VM как iSCSI LUN

Можно загрузиться? да нет нет Необходимо ПО Integration components

(опционально) Integration components iSCSI SW Initiator

VM OS видит диск как: Virtual HS ATA device Msft virtual disk SCSI disk device

NetApp LUN SCSI disk device

Максимальное количество дисков

2 х 2 = 4 диска 4 х 64 = 256 дисков Не ограничено в Hyper‐V

Добавление «на ходу» нет Да, только с R2 да

Кроме этого, таблица 4‐4 выше показывает значительную разницу между устройствами IDE или SCSI, когда они презентуют устройство хранения в VM. Часто основной причиной выбора администратором между IDE‐ или SCSI‐устройством является необходимость установки Integration Services, возможность позже добавлять‐удалять диск из VM, и максимальное количество дисков, которые можно презентовать в VM.

Для того, чтобы воспользоваться возможностью добавлять и удалять хранилище в VM «на ходу» (hot add/remove) в Hyper‐V R2 (в предыдущей версии это было невозможно), также как и использовать максимальное количество виртуальных дисков на VM, администратору нужно выбрать подключение диска к VM с использованием устройства SCSI. Однако если администратор хочет использовать SCSI‐устройство для презентования дополнительных хранилищ в VM, ее OS должна иметь установленный Integration Services.

NetApp Best Practice Recommendation Для достижения максимальной производительности, по возможности используйте SCSI‐устройства, чтобы презентовать виртуальные диски для VM.

4.4.5 Integration Services Как уже рассматривалось выше установка Integration Services в OS виртуальной машины это важный аспект, касающийся не только выбора между устройствами IDE или SCSI при подключении хранилища к VM, но он также касается и производительности VM.

Компоненты интеграции устанавливают также специальные драйвера, которые, среди прочего, оптимизированы для работы в виртуализованной среде. Такие драйвера обеспечивают поддержку так называемых synthetic I/O devices, которые значительно снижают нагрузку на CPU при вводе‐выводе, в сравнении с использованием emulated I/O devices и позволяют synthetic I/O device получить все преимущества от использования архитектуры Hyper‐V, недоступных для emulated I/O devices. Если OS виртуальной машины не поддерживается в Hyper‐V R2, тогда VM будет вынуждена использовать emulated devices, так как нет способа установить Integration Services в VM на неподдерживаемую OS. Для подробностей о поддерживаемых OS в виртуальных машинах Hyper‐V R2, смотрите Virtualization with Hyper‐V: Supported Guest Operating Systems.

NetApp Best Practice Recommendation Для достижения максимума производительности убедитесь, что Integration Services установлены во всех поддерживаемых гостевых OS. В соответствии с собственными best practices от Microsoft, версии Integration Services, установленные в OS виртуальных машин, всегда должны соответствовать версии OS на хостовой, основной партиции Hyper‐V. Когда это не так, например в случае обновления хостовой OS, или миграции VM между хостами Hyper‐V с различными версиями OS, то это поддерживается только для «не‐продакшн» систем.

4.4.6 Дисковая производительность виртуальной машины Microsoft опубликовал множество данных о производительности различных дисковых опций виртуальных машин, как для Hyper‐V ver. 1, так и для Hyper‐V R2. В особенности заметно радикальное улучшение производительности для виртуальных дисков в Hyper‐V R2, в котором производительность для VHDs и дисков pass‐through стала гораздо ближе к обычным, нативным методам доступа. Для подробного разбора темы производительности VHD и дисков pass‐through, а также производительности нижележащей архитектуры хранения в Hyper‐V, смотрите приведенные ресурсы ниже.

• Microsoft Windows Server 2008 Hyper‐V R2 o Performance Tuning Guidelines for Windows Server 2008 R2, в особенности главу

«Storage I/O Performance»


http://www.microsoft.com/whdc/system/sysperf/Perf_tun_srv-R2.mspx


o All Topics Performance: What’s New in Windows Server 2008 R2 Hyper‐V Performance and Scale? В особенности главу «Storage improvements from Windows Server 2008 SP1 Hyper‐V to Windows Server 2008 R2 Hyper‐V»

o Microsoft Virtual Hard Disk (VHD) FAQ и Virtual Hard Disk (VHD) Image Format Specification

• Microsoft Windows Server Hyper‐V o Performance Tuning Guidelines for Windows Server 2008, в особенности главу

«Storage I/O Performance» o Windows Server Performance Team Blog: Hyper‐V and VHD Performance: Dynamic vs.

Fixed o Microsoft Virtual Hard Disk (VHD) FAQ и Virtual Hard Disk (VHD) Image Format

Specification

4.4.7 Планирование виртуальной машины Перед тем, как вы начнете создавать LUN‐ы и распределять пространство, вам следует оценить требования к объемам хранения для каждой VM, чтобы правильно спланировать и распределить емкость, и создать LUN‐ы для хранения VHD или непосредственного их использования (диски pass‐through). Эта глава написана, чтобы помочь администраторам понять требования к пространству у VM, развернутых в среде Hyper‐V. Обратите внимание, что рекомендации этой главы ориентированы прежде всего на использование общего сетевого хранилища, и в других ситуациях результаты планирования могут быть иными.

Когда вы определяете достаточные условия для распределяемого в VM хранилища, то существуют несколько ключевых моментов, которые следует учитывать.

• Виртуальные машины могут быть охарактеризованы и классифицированы по трем основным категориям, с высокой, средней и низкой степенью использования дисков. Для VM, классифицированных как машины с высокой степенью использования, администратор скорее всего захочет изолировать дисковые ресурсы и данные такой VM на ее собственный LUN.

o Когда вы планируете использовать VHD, рассмотрите вариант подключения и использования c VM нескольких VHD, отдельно для системных данных, данных приложения, логов приложения, файла подкачки и временных файлов системы, и так далее. Эти VHD могут быть изолированы на отдельных LUN‐ах, или, в ряде случаев, например для VHD под файл подкачки, располагаться совместно с такими же VHD других VM.

o Как сам по себе, так и в комбинации с использованием VHD, диск типа pass‐through может применяться для хранения некоторых данных, таких как данные приложения или логи, эффективно изолируя эти данные на своем собственном LUN. Однако такое использование должно применяться с осторожностью, так как оно делает процесс миграции VM и ее резервное копирование более сложным.

o Используйте «дисковое устройство SCSI» всегда, когда это возможно, если вы подключаете VHD или pass‐through disk, за исключением системных данных загрузочного тома. Так как Hyper‐V максимально поддерживает 4 SCSI disk controllers на VM, вы можете использовать более одного такого контроллера SCSI, при подключении различных VHD или pass‐through disk.

• В некоторых конфигурациях, особенно когда используется CSV, по нескольку VM и их VHD могут быть скомбинированы на одном LUN. Такой вариант может быть не так просто

http://blogs.msdn.com/tvoellm/archive/2009/08/05/what-s-new-in-windows-server-2008-r2-hyper-v-performance-and-scale.aspx


http://technet.microsoft.com/en-us/bb738381.aspx

http://technet.microsoft.com/en-us/virtualserver/bb676673.aspx


http://www.microsoft.com/whdc/system/sysperf/Perf_tun_srv.mspx

http://blogs.technet.com/winserverperformance/archive/2008/09/19/hyper-v-and-vhd-performance-dynamic-vs-fixed.aspx





посчитать, как в случае требований одной VM. Это в особенности верно, когда отдельные типы данных VM распространены по множеству совместно использованных LUN‐ов, таких как один CSV для хранения всех конфигурационных файлов VM или файлы VHD, содержащие системные данные VM.

• Для виртуальных машин, использующих динамически расширяемые VHD, администратор должен корректно рассчитать размер LUN, соответствующий максимальному размеру VHD или же особенно внимательно наблюдать степень заполнения этого LUN.

Информация, приведенная в таблице 4‐5 ниже, может помочь администратору понять требования к пространству для каждой VM.

Таблица 4‐5) Расчет пространства для виртуальной машины

Компонент VM Размер Описание Конфигурация VM 200MB Включает в себя конфигурацию и состояние

VM (файлы XML и VSV). Память VM Включает в себя файл VM Memory (BIN). Системные данные гостевой OS

В зависимости от типа VM OS, необходимое место может быть различным, но всегда располагается на IDE‐устройстве VM.

Файл подкачки гостевой OS

Microsoft рекомендует рассчитывать место исходя из оценки 1.5х количества выделенного VM объема оперативной памяти. Он может располагаться как вместе с системными данными, так и отдельно, но рассчитывается отдельно.

Файлы приложения гостевой OS

Дополнительные диски могут понадобиться для установки приложений, их данных, лог‐файлов и прочего.

Снэпшоты VM Hyper‐V 10‐15% от суммы размера системных данных, файла подкачки и файлов приложений

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

Всегда рассчитывайте размер LUN больше, чем в действительности занимают данные, оставляя место на возможный прирост данных, VM могут потребовать больше памяти, место могут потребовать дополнительные файлы VHD, или снэпшоты Hyper‐V. Насколько больше, следует рассчитывать в каждом индивидуальном случае отдельно, основываясь на характере VM и характере данных этих VM. Помните, что на NetApp вы можете расширять и сжимать LUN‐ы «на ходу», без остановки работы, используя NetApp SnapDrive и NetApp System Manager.

4.4.8 Выравнивание дисков виртуальной машины Для оптимальной производительности, файловая система на VHD, нижележащий физический диск сервера Hyper‐V, и система хранения должны быть правильно выровнены между собой.

NetApp Best Practice Recommendation Отсутствие правильного выравнивания для дисков VM может вызвать падение

производительности от небольшого до среднего, в зависимости от характера доступа к данным и общей структуры системы.

4.4.8.1 Что такое «выравнивание файловой системы» Исторически, жесткие диски (и LUN‐ы) подключались к OS согласно их логической геометрии, которая использовалась при разбивке их на партиции и форматировании. Логическая геометрия дисков и LUN‐ов сегодня виртуальна, она эмулируется в BIOS хоста и его операционной системы. При работе программы разбивки на партиции, такие как fdisk, используют такую эмулированную геометрию, чтобы определить место, где следует сделать начало партиции. К сожалению, многие программы партиционирования создают дисковые партиции без учета нижележащих блоков диска, и не выравнивают ее надлежащим образом. Заметные примеры таких программ это GNU fdisk, который включен в большинство дистрибутивов Linux®, и Microsoft Diskpart, входящий в состав Windows 2000 и Windows 2003.

NetApp использует на дисках блоки размером 4KB blocks (4 x 1024 = 4096 bytes) в качестве основного «кирпичика». Операция записи может использовать не менее чем один блок размером 4KB, и использовать столько блоков, размером 4KB, сколько необходимо при записи. В идеальном случае, OS в виртуальной машине должна выровнять свою файловую систему точно по границе логических блоков системы хранения. Проблема с «невыровненным вводом‐выводом» случается тогда, когда структура партиции, использованной в OS хоста не совпадает с границами блоков в LUN, как показано на рисунке 4‐10 ниже. Если такая файловая система не выровнена правильно, то это может привести к тому, что при чтении и записи отдельного блока устройство хранения будет вынуждено считывать и записывать вдвое больше данных, чем нужно OS, так как каждый из блоков файловой системы OS занимает по два (частично один и частично другой) смежных блока на LUN. В качестве простого примера, допустим, что мы имеем только один уровень файловой системы поверх LUN, и блок файловой системы в точности равен размеру блока LUN (4K или 4096 байта), каждый блок файловой системы OS будет занимать 512 байт в одном блоке LUN, и 3584 байта (4096 ‐ 512) в другом. В результате мы будем иметь неэффективные операции ввода‐вывода, так как контроллер системы хранения должен будет считывать с ее дисков лишние данные, чтобы получить нужный их фрагмент.

По умолчанию многие OS, включая Windows 2000 и 2003, а также различные дистрибутивы Linux, начинают первую партицию со смещением, в секторе 63. Причина именно такого смещения историческая, и связана с геометрией дисков в те времена, когда она еще была реальной. Такое поведение ведет к неправильному выравниванию файловой системы, так как партиция не начинается в секторе кратном восьми.

Рисунок 4‐10) Неправильно выровненная файловая система

Проблема становится еще более сложной, когда файловая система хоста виртуализации несет на себе файлы (например vmdk, vhd), являющиеся дисками с файловыми системами виртуальных машин, как это показано на рис. 4‐11 и 4‐12. В этом случае схема партиций с использованием еще и виртуальных дисков для VM OS в свою очередь должна быть выровнена и с файловой системой хост‐системы, и со структурой LUN‐ов на системе хранения NetApp.

Рисунок 4‐11) Файловая система OS виртуальной машины и файловая система NTFS хоста не выровнены относительно блоков системы хранения NetApp.

Рисунок 4‐12) Файловая система OS виртуальной машины и файловая система NTFS хост‐системы выровнена с LUN системы хранения NetApp

Для дисков типа VHD, размещенных на сформатированном под NTFS LUN‐е, подключенного, в свою очередь, как физический диск к хост‐OS Hyper‐V, имеется два возможных независимых уровня выравнивания. Файловая система NTFS на физическом диске, и файловая система VM OS, располагаемая на VHD, обе они должны быть выровнены с блоками хранения на хранилище NetApp.

Диски типа pass‐through и непосредственно подключенные в VM OS LUN‐ы не требуют специальных усилий по выравниванию, если при создании их LUN параметр «LUN type» был выставлен в соответствии с типом их операционной системы в VM. Для подробностей о использовании и работе параметра «LUN type», смотрите раздел LUN Multiprotocol Type в Data ONTAP Block Access Management Guide или Commands Manual Page Reference, доступные на сайте NetApp NOW.

Таблица 4‐6) Уровни хранилища для выравнивания файловой системы в Microsoft Hyper‐V

Уровни хранилища Опции Hyper‐V Shared Storage LUN сформатированный под NTFS

Диск типа Pass‐through

LUN смапированный на Child OS


VM OS Hyper‐V parent partition N/A N/A Система хранения NetApp Различные уровни хранилища, которые вовлечены в процесс для каждой из опций использования системы хранения, показаны в таблице 4‐6 выше. Метка ( ) показывает, что выравнивание должно быть выполнено на уровне OS VM, хост‐партиции Hyper‐V, и/или уровне системы хранения NetApp.

Убедитесь, что вы начали выравнивание с установки правильного LUN protocol type для LUN, при создании его на системе хранения NetApp. При этом, будучи один раз выставленной, эта опция обеспечит то, что файловая система на физическом диске, диске pass‐through, или непосредственно подключенном диске будет правильно выровнена со стороны системы хранения NetApp. Для подробностей смотрите главу 4.2.3, и следуйте приведенным там шагам по установке правильного LUN Protocol Type.

Для уже существующих виртуальных машин, работающих на невыровненной файловой системе, NetApp рекомендует заниматься исправлением смещения только в случае, если виртуальная машина имеет проблемы производительности на вводе‐выводе. Эффект от правильного выравнивания более заметен на системе с большим количеством мелких операций чтения и записи. Для исправления ситуации с неправильным выравниванием на уже существующей системе придется создать новый виртуальный диск, отформатировать его, и мигрировать существующие данные виртуальной машины с исходного диска на новый.

NetApp Best Practice Recommendation NetApp настоятельно рекомендует скорректировать отступ для всех шаблонов VM, а также для существующих VM, которые не выровнены и испытывают проблемы с производительностью на вводе‐выводе. Однако неправильное выравнивание для VM с невысоким объемом ввода‐вывода может и не давать заметного ухудшения, по сравнению с VM с правильным выравниванием.

4.4.8.2 Обеспечение выравнивания файловой системы

Виртуальные жесткие диски (VHD) Для файлов VHD, лежащих на LUN‐е, подключенном как физический диск к хост‐серверу Hyper‐V, и сформатированном в NTFS, существует два уровня выравнивания. Файловая система NTFS на физическом диске, и файловая система OS VM размещенная в виртуальном диске, должны быть выровнены относительно блоков NetApp. Для подробностей смотрите Рисунок 4‐12 или таблицу 4‐6 выше.

Только файловая система и партиция на VHD типа fixed‐size может быть гарантированно выровнена. Для динамически расширяемых и дифференциальных VHD нет способа гарантировать правильное выравнивание. Для подробностей смотрите главу 4.4.1 Виртуальные жесткие диски (VHD).

NetApp Best Practice Recommendation NetApp рекомендует использовать VHD фиксированного размера в Microsoft Hyper‐V всюду, где это возможно, в особенности в «продакшн»‐системах, так как только такой тип VHD гарантирует установку правильного выравнивания для файловой системы.

Избегайте использования динамически расширяемого и дифференциального VHD, так как на них

невозможно гарантировать правильное выравнивание файловой системы.

Выравнивание файловой системы в VHD с файловой системой нижележащего диска дает возможность получить наилучшую возможную производительность. Все типы VHD могут быть сформатированы с правильным смещением в момент своего создания, простой загрузкой VM до установки OS и ручным заданием правильного смещения партиции. Для OS Windows для этого можно использовать Windows Preinstall Environment boot CD или альтернативные инструменты, такие как Bart’s PE CD.

При выравнивании VHD для использования с системами хранения NetApp, начальное смещение партиции должно быть кратно (делиться без остатка на) 4096. Рекомендованное значение смещения для OS семейства Windows равно 32768. Для Windows VM OS, проверить значение этой величины можно с помощью утилиты msinfo32.exe. По умолчанию эта величина обычно равна 32256. Для подробностей смотрите главу 4.4.8.4 Исправление неверного выравнивания файловой системы, и ее подглаву «Обнаружение».

Виртуальные диски типа PassThrough Для дисков типа pass‐through, есть только один уровень выравнивания, что на один меньше, чем при использовании виртуальных жестких дисков (VHD). Только самой VM нужно выравнивание относительно блоков NetApp. Для подробностей смотрите Рисунок 4‐13 ниже, или таблицу 4‐6 ранее.

Рисунок 4‐13) Файловая система VM выровнена с блоками системы хранения.

Диски типа pass‐through не требуют специального внимания, если тип протокола LUN соответствует типу операционной системы VM. Для подробностей смотрите главу 4.2.3, и следуйте указанным пошаговым инструкциям в разделе Выбор и исправление LUN Protocol Type. Дополнительно смотрите раздел LUN Multiprotocol Type в Data ONTAP Block Access Management Guide for iSCSI or FC или Data ONTAP Commands Manual Page Reference Document: Volume 1 или Volume 2 на NetApp NOW.

Диски, подключенные непосредственно в OS VM Для LUN‐ов, подключенных непосредственно в OS виртуальной машины, действует только один уровень выравнивания, похожий на использованный в дисках типа pass‐through. Выровнять с NetApp LUN нужно только партицию OS VM. Для подробностей смотрите рисунок 4‐13 или таблицу 4‐6 выше.

Не нужно каких‐то специальных действий, если для LUN‐ов, подключенных непосредственно в OS VM тип LUN protocol type для этого LUN соответствует типу OS в VM. Для подробностей смотрите главу 4.2.3, и следуйте указанным пошаговым инструкциям в разделе Выбор и исправление LUN

http://now.netapp.com/NOW/knowledge/docs/ontap/rel731_vs/pdfs/ontap/bsag.pdf


http://now.netapp.com/NOW/knowledge/docs/ontap/rel731/pdfs/ontap/cmdref1.pdf


Protocol Type. Дополнительно смотрите раздел LUN Multiprotocol Type в Data ONTAP Block Access Management Guide for iSCSI or FC или Data ONTAP Commands Manual Page Reference Document: Volume 1 или Volume 2 на NetApp NOW.

4.4.8.3 Процесс выравнивания партиции файловой системы

Выравнивание загрузочного диска Виртуальные диски, используемые для загрузки с них, могут быть отформатированы с правильным смещением во время их создания, будучи подключенными к работающей VM, после чего на них следует вручную задать правильное смещение. Для OS Windows для этого можно использовать Windows Preinstall Environment boot CD или альтернативные инструменты, такие как Bart’s PE CD.

Для задания смещения партиции выполните следующие шаги:

Шаг Действие 1. Загрузитесь в VM с помощью Windows Preinstall Environment boot CD. 2. Выберите Start > Run и нажмите Enter.

В полученном окне введите diskpart 3. Первое, введите следующую команду на появившуюся подсказку:

select disk 0 Далее введите следующую команду: create partition primary align=32

4. Выйдите из программы diskpart командой: exit. 5. Установите OS обычным образом.

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

Для выравнивания виртуального диска выполните следующие шаги:

Шаг Действие 1. Загрузитесь в VM с помощью Windows Preinstall Environment boot CD. 2. Выберите Start > Run и нажмите Enter.

В полученном окне введите diskpart 3. Первым определите нужный вам диск, набрав команду:

list disk Далее выберите правильный диск, набрав команду: select disk [#] И далее введите команду: create partition primary align=32





4. Выйдите из программы diskpart командой: exit. 5. Сформатируйте диск обычным образом.

4.4.8.4 Исправление неверного выравнивания файловой системы

Обнаружение Для выровненной с системой хранения NetApp файловой системы виртуальной машины, стартовое смещение партиции в байтах должно нацело делиться на 4096. Для OS семейства Windows проверить это просто. Запустите программу msinfo32.exe в VM выбрав Start > All Programs > Accessories > System Tools > System Information. Далее пройдите в ней Components > Storage > Disks и найдите величину partition starting offset. Для невыровненной партиции VM, вы обычно увидите там значение 32256, которое не делится нацело на 4096 и, следовательно, партиция не выровнена правильно относительно границ блоков системы хранения. Ниже, на рис.15 показан пример смещения партиции Windows по умолчанию (невыровненной).

Отметьте: Для дисков типа pass‐through или raw LUN, напрямую подключенных в VM, значение 32256 это правильная величина смещения. Контроллер системы хранения скомпенсирует смещение самостоятельно, при выборе правильного LUN type.

Рисунок 15) Использование утилиты msinfo32 для определения смещения партиции.

Исправление Исправление начального смещения лучше всего проводить с шаблонами (template), из которых в дальнейшем будут создаваться новые VM. Чтобы сделать это, следуйте указаниям в главе 4.4.8.2 Обеспечение выравнивания файловой системы, чтобы создать новый выровненный виртуальный диск. Подключите новый выровненный диск к VM и скопируйте содержимое из существующего, невыровненного диска во вновь созданный, выровненный. После чего отключите и удалите неверно выровненный виртуальный диск, после проверки содержимого и целостности его копии в выровненном виртуальном диске.

Если неверно выровненный виртуальный диск является загрузочным, то следуйте шагам:

Шаг Действие 1. Сделайте резервную копию VM. 2. Выключите (shutdown) VM. 3. Подключите диск с невыровненной файловой системой к другой VM. 4. Подключите к этой VM созданный новый диск с выровненной партицией. 5. Скопируйте содержимое образа виртуального диска системы (например, C: для Windows)

на новый, выровненный виртуальный диск. Существуют разные способы скопировать содержимое с неправильно выровненного на новый, выровненный диск: Windows xcopy Norton/Symantec™ Ghost: Norton/Symantec Ghost можно использовать для копирования всего образа и затем восстановить его на новый, выровненный диск.

В случае LUN‐ов Microsoft Hyper‐V, подключенных на «родительскую» (host OS) партицию Hyper‐V с использованием некорректного LUN protocol type, но с правильно выровненными VHD на ней, создайте новый LUN с указанием правильного LUN protocol type и скопируйте содержимое (VM‐ы и их VHD) со старого LUN на новый LUN.

В случае LUN‐ов Microsoft Hyper‐V, смаппированных на «родительскую» партицию Hyper‐V с использованием некорректного LUN protocol type, и с неправильно выровненными VHD на ней, создайте новый LUN с указанием правильного LUN protocol type и скопируйте содержимое (VM‐ы и их VHD) со старого LUN на новый LUN.

Далее выполните шаги, описанные ранее в главе 4.4.8.3 Процесс выравнивания партиции файловой системы, для создания новых, выровненных VHD на новом LUN и скопируйте содержимое старых VHD в новые VHD. Если VHD содержат в себе загрузочную партицию, то следуйте шагам, описанным ранее в этом разделе.

Для дисков типа pass‐through и LUN‐ов подключенных непосредственно в VM OS, создайте новый LUN с указанием правильного LUN protocol type, подключите LUN к VM, и скопируйте содержимое из старого, невыровненного LUN в новый, правильно выровненный LUN.

Для подробностей по теме дисков и хранилищ в Hyper‐V, смотрите Planning for Disks and Storage и Configuring Disks and Storage в Microsoft TechNet.

5 Увеличение эффективности и гибкости хранения Hyper‐V предлагает отличные способы и возможности увеличить степень использования физических серверов. Увеличивая степень использования оборудования вы сможете уменьшить количество оборудования в датацентре, понизить затраты на операции датацентра. В традиционной среде Hyper‐V, процесс миграции физического сервера в виртуальную машину

http://technet.microsoft.com/en-us/library/dd183729(WS.10).aspx

http://technet.microsoft.com/en-us/library/ee344823%28WS.10%29.aspx

Hyper‐V не приводит к уменьшению объемов хранения, или количеству выделенного объема на системе хранения. По умолчанию серверная виртуализация никак не улучшает ситуацию с использованием объемов хранения (а во многих случаях имеет даже обратный эффект).

NetApp предлагает ряд технологий виртуализации хранилища, которые позволяют улучшить ситуацию со степенью использования систем хранения. Эти технологии NetApp обеспечивают надежную экономию пространства хранения, путем использования методов «экономного распределения пространства» (thin provision) для SAN LUN и дедупликацию избыточных данных в SAN LUN. Обе эти технологии «родные» для NetApp, присутствуют в системах хранения по умолчанию, и не требуют каких‐то специальных изменений в конфигурации при включении и использовании их в системе Hyper‐V.

5.1 Thin Provisioning Традиционные методы распределения пространства хранения (storage provisioning) и выделения места на дисках хорошо известны и понятны для администраторов систем хранения. Общей практикой для серверных администраторов является избыточное выделение пространства хранения, «с запасом», чтобы избежать внезапного исчерпания места и остановки приложения.

Хотя никакая система не может работать со 100% степенью использования хранилища, существуют методы виртуализации хранения, которые позволяют администраторам адресовать пространство хранения образом, сходным с тем, как они это делают с серверными ресурсами (такими как CPU, память, сетевые ресурсы, и прочее). Такой способ виртуализации пространства хранения называется thin provisioning, или «экономное распределение».

Традиционное распределение размечает и выделяет хранилище заранее; thin provisioning предлагает хранилище on demand, по мере возникновения в нем потребностей. Объем распределенного таким образом хранилища рассматривается как совместно используемый пул ресурсов, и потребляется только в том случае, если его использует конкретная VM. Такое «совместное использование» увеличивает общую степень использования хранилища, устраняя распределенные, но пока никак не используемые приложениями пространства, как это принято для традиционных систем хранения. Недостатком метода thin provisioning является то, что «избыточно распределенное» (oversubscribing) хранилище, без добавления дополнительных дисков и пространства хранения, не может обеспечить все, теоретически выделенные приложениям и VM, ресурсы хранения одновременно.

Технология thin provisioning в NetApp позволяет LUN‐ам быть представленными для VM как физические диски, распределенные на их полную емкость, однако занятое место на системе хранения будет равно сумме объемов файлов VHD. Кроме этого, LUN‐ы, подключенные как pass‐through disks также могут быть сделаны thin provisioned.

NetApp Best Practice Recommendation NetApp рекомендует использовать LUN‐ы в режиме thin provisioned всегда, где это возможно, чтобы достичь максимальной эффективности хранения в системе Hyper‐V. Однако, при включении NetApp thin provisioning, администратор также должен правильно сконфигурировать политики управления на томе, который содержит LUN‐ы в режиме thin‐provisioned. Использование таких политик поможет обеспечить этим LUN‐ам пространство, когда оно им потребуется. Политики включают в себя автоматическое изменение размеров тома, автоматическое удаление снэпшотов, и параметры LUN fractional reserve.

5.1.1 LUN в режиме Thin Provisioned Для создания LUN‐а в режиме thin‐provisioned с помощью NetApp FilerView, следуйте приведенным шагам:

Шаг Действие 1. Запустите FilerView (http://controller/na_admin) 2. Выберите «LUNs» 3. Выберите «Wizard» 4. В окне «Wizard» щелкните Next 5. В поле «Path» введите путь к создаваемому LUN.

В поле «Size» введите размер создаваемого LUN и желаемую единицу измерения. В поле «LUN Protocol Type» введите правильный тип LUN. Для «диска», который будет представлен системе как pass‐through disk или будет имеет прямой доступ из VM по iSCSI, выберите OS type соответствующей установленной в VM. Уберите отметку с чекбокса «Space Reserved», так как NetApp рекомендует не создавать LUN в режиме с резервированием пространства (space reserved). В поле «Description», вы можете ввести любое удобное вам значение для описания получившегося LUN.

6. Щелкните Next и Finish для завершения создания LUN‐а в режиме thin provisioning.

5.1.2 Volume AutoSize Volume AutoSize это управляемая политиками возможность в Data ONTAP, которая позволяет заполняемому тому данных увеличиваться с определенным шагом прироста, вплоть до заданного лимита.

NetApp Best Practice Recommendation Для систем Hyper‐V, NetApp рекомендует устанавливать это значение в «on». Для его использования следует также указать максимальное допустимое значение размера тома и шаг прироста.

Для включения Volume AutoSize с помощью консольных команд, следуйте приведенным шагам:

Шаг Действие 1. Войдите в консоль администрирования контроллера NetApp по telnet или ssh 2. Введите команду:

set volume autosize policy: vol autosize <vol‐name> [‐m <size>[k|m|g|t]] [‐i <size>[k|m|g|t]] on.

5.1.3 Snapshot AutoDelete Snapshot AutoDelete управляемая политиками возможность в Data ONTAP, которая позволяет заполняемому тому данных автоматически удалять снэпшоты на томе, когда он близок к заполнению.

NetApp Best Practice Recommendation Для системы Hyper‐V, NetApp рекомендует установить значение Snapshot AutoDelete на удаление снэпшотов при достижении объемов доступного места менее 5%. Кроме этого вам следует установить ранее рассмотренную опцию volume autosize для того, чтобы система хранения сначала пыталась увеличить том, и, в случае невозможности этого, удаляла снэпшоты.

Для включения Snapshot AutoDelete с помощью консольных команд, следуйте приведенным шагам:


snap autodelete <vol‐name> commitment try trigger volume target_free_space 5 delete_order oldest_first

3. Введите команду: set volume autodelete policy: vol options <vol‐name> try_first volume_grow.

5.1.4 LUN Fractional Reserve LUN fractional reserve это политика, которую необходимо определить, когда вы используете снэпшоты NetApp на томе, содержащем LUN‐ы Hyper‐V. Эта политика задает количество дополнительно зарезервированного на томе места, чтобы гарантировать для LUN возможность записи, когда том становится заполнен на 100%. На LUN‐ы, которые имеют параметр space reservation выключенным (off) установки fractional reserve не действуют.

5.2 Дедупликация NetApp Используя технологию дедупликации NetApp, система Hyper‐V может устранить нежелательно избыточные хранимые данные, и, в результате, достичь значительного прироста величины эффективности хранения. Дедупликация NetApp прозрачно работает для среды Hyper‐V, без необходимости дополнительной настройки на уровне администрирования Hyper‐V, практики работы или выполняемых задач. Дедупликация работает на системе хранения NetApp, выполняясь по заданным интервалам, и не занимает ресурсы процессора сервера Hyper‐V.

Дедупликация может быть чрезвычайно полезна для таких сценариев использования, как диски VHD фиксированного размера, частое создание и удаление файлов VHD на SAN LUN, или данных в VM.

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

NetApp Best Practice Recommendation

Для системы Hyper‐V, NetApp рекомендует использовать дедупликацию для томов NetApp FlexVol, содержащих LUN‐ы, которые содержат данные виртуальных машин, в особенности LUN‐ы, которые использованы сервером Hyper‐V для хранения данных VHD. Для максимального достижимого эффекта следует правильно организовать виртуальные диски VM; такие как VHDs и pass‐through disks, содержащие сходные OS и данные так, чтобы они располагались на одном томе NetApp FlexVol.

5.2.1 Некоторые детали о процессе дедупликации Включение дедупликации для созданных и распределенных LUN‐ов виртуальных машин, как правило, приводит к значительной экономии пространства на системе хранения. Однако обычное поведение LUN состоит в резервировании определенного объема хранения, равного заданной при создании LUN‐а величине. Такая схема приводит к тому, что, хотя система хранения и снизит объемы занятого на ней пространства, но результаты дедупликации не будут прямо видимы для виртуальных машин, так как зарезервированное LUN‐ами место не уменьшится, и количество свободного места внутри LUN, видимое виртуальной машиной, не увеличится.

Для того, чтобы видеть экономию от дедупликации, вы должны использовать LUN‐ы в режиме NetApp thin provisioning. Для подробностей смотрите главу 5.1 Thin Provisioning выше в этом разделе. Кроме этого, хотя дедупликация и снижает объемы использованного хранилища, администраторы Hyper‐V не видят этот прирост напрямую, так как смотрят на систему хранения с точки зрения уровня LUN, а LUN‐ы всегда показывают назначенный им при создании объем, вне зависимости от того, являются они обычными или thin‐LUN.

Дедуплицированный том может быть реплицирован на другую систему (систему‐получатель репликации) с помощью технологии NetApp SnapMirror (volume SnapMirror). Том на вторичной системе, реплицированный с помощью «volume SnapMirror», унаследует все атрибуты дедупликации и величины экономии пространства. Кроме этого только уникальные по содержимому блоки будут передаваться на вторичный сайт, что также может привести к значительной экономии на времени передачи и полосе пропускания репликации.

5.2.2 Включение дедупликации Чтобы включить и инициализировать дедупликацию на системах хранения NetApp с помощью консоли администрирования, следуйте приведенным шагам:


sis on <volume path> 3. Для запуска процесса на текущих данных:

sis start –s <volume path>4. Для того чтобы посмотреть состояние процесса:

sis statusРуководство по наилучшим методам, рекомендациям, настройке расписаний и оценке производительности: TR‐3505: NetApp Deduplication for FAS: Deployment and Implementation Guide.

5.3 NetApp FlexClone Технология NetApp FlexClone® создает клоны данных, с помощью которых можно мгновенно создать копии наборов данных, файлов, LUN‐ов и томов, не занимая при этом, в момент создания


этого клона, дополнительного места на диске. Тома FlexClone это мгновенные, доступные на запись копии, созданные из снэпшота тома FlexVol. Они располагают всеми возможностями тома FlexVol, включая расширение, сжатие, и возможность создавать на основе него снэпшоты, или даже другие тома FlexClone.

Тома FlexClone, используемые в системе Hyper‐V предлагают значительную экономию средств на пространство хранения, места на дисках и энергии электропитания и охлаждения. Важно и то, что тома FlexClone или клоны отдельных файлов имеют ровно ту же производительность, что и их оригиналы: тома FlexVol или индивидуальные файлы.

NetApp Best Practice Recommendation Для системы Hyper‐V, NetApp рекомендует использовать тома FlexClone для различных задач, таких как создание систем для тестирования и разработки, быстрого развертывания VM для «виртуальных десктопных сред» (VDI), и других подобных применений.

5.3.1 Что такое FlexClone Использование томов FlexClone дает отличные результаты в случаях, когда данные прирастают инкрементально, или когда работа с объемной информацией требует создания измененных ее копий, при этом без значительного изменения содержимого оригинальных данных.

Создание клона тома по технологии FlexClone происходит практически мгновенно, и не влияет на производительность и доступность исходного тома FlexVol. Клоны создаются экономно с точки зрения расхода пространства хранения; исходный том и его клон отличаются (и занимают место на диске) только в той части, которая между ними была изменена, только эти новые блоки и их указатели block‐map (block‐map pointers) пишутся на диск. Таким образом, тома/LUN накапливают и занимают место на диске только в объеме измененных в них блоков. Клоны могут быть связаны с решением репликации от NetApp, таким например, как SnapMirror, чтобы передавать инкрементально увеличивающиеся данные на «вторичную» систему хранения.

5.3.2 Создание тома FlexClone

Создание тома FlexClone из консоли администрирования Тома FlexClone могут быть созданы с помощью консоли администрирования или FilerView. Для создания тома FlexClone из тома FlexVol, следуйте шагам:

Шаг Действие 1. Войдите в консоль администрирования контроллера NetApp по telnet или ssh 2. Выполните команду:

vol clone create FlexCloneName –b ParentFlexVolName

Создание FlexCloneтома с помощью NetApp SnapDrive Тома FlexClone могут быть созданы как с помощью консоли администрирования, так и с помощью FilerView, или консоли SnapDrive.

Для создания тома FlexClone из тома FlexVol, следуйте шагам:

Шаг Действие 1. Подключитесь к консоли SnapDrive 2. Щелкните «Connect Disk» 3. Щелкните Next в мастере Connect Disk 4. Укажите все необходимые детали,такие как IP‐адрес или имя хоста для «Storage System» и

подключитесь к ней. Выберите том, и из выпадающего списка выберите контейнер .snapshot, содержащий нужный снэпшот, и, наконец, желаемый LUN, как показано на приведенном скриншоте. Щелкните Next.

5. Для «LUN Type» укажите «Dedicated». Щелкните Next.

6. Определите имя буквы диска или точку монтирования Щелкните Next.

7. Из списка инициаторов, выберите с помощью чекбоксов необходимые WWPN или IQN, которым будет доступен LUN. Щелкните Next.

8. Оставьте значение «Initiator Group Management» в положении «Automatic». Щелкните Next.

9. Проверьте все сделанные изменения. Щелкните Finish.

5.4 NetApp Snapshot Снэпшоты по технологии NetApp Snapshot это локально сохраненные, зафиксированные «снимки» состояния данных на томе или aggregate, доступные только для чтения, и эффективно использующие пространство хранения. Их можно широко использовать для улучшения стабильности, масштабируемости, возможности восстановления и повышения производительности, что отличает их от других технологий снэпшотов на системах хранения других производителей, которые негативно влияют на общую производительность системы хранения.

Снэпшоты часто используются как регулярный онлайн‐бэкап, удобный возможностью пользователю самостоятельно извлечь предыдущие версии данных, файлов, или иерархий папок, LUN‐ов или данных приложения. Они обеспечивают безопасный и простой метод восстановления данных, при которых пользователи имеют непосредственный доступ к сохраненным состояниям

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

5.4.1 Что такое снэпшоты Снэпшоты это хорошо знакомая индустрии технология, которая заключается в возможности создавать временные мгновенные (point‐in‐time) копии данных. Microsoft Hyper‐V предлагает собственные возможности для создания снэпшотов своих виртуальных машин. Технология снэпшотов NetApp тесно интегрируется с виртуальной инфраструктурой, развернутой с помощью Hyper‐V и дополняет ее возможности. Она предлагает мгновенные копии образа VM вида crash‐consistent, который полезен при восстановлении содержимого VM, клонирования VM, репликации сайта и восстановления данных.

Создание снэпшотов Hyper‐V, запущенное Hyper‐V Manager, SCVMM, или через PowerShell использует аппаратные ресурсы сервера Hyper‐V , в то время как снэпшоты NetApp переносят задачу создания снэпшота с сервера на систему хранения, так что сервер перестает испытывать лишнюю нагрузку при создании снэпшота. Увеличение количества снэпшотов Hyper‐V негативно влияет на производительность хост‐системы, напротив, снэпшоты NetApp могут быть созданы в количестве до 255 на каждый том, без какого‐либо заметного влияния на производительность и с минимальной затратой свободного места.

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

NetApp Best Practice Recommendation Для системы Hyper‐V, NetApp рекомендует использовать снэпшоты для различных задач, включая резервное копирование и восстановление виртуальных машин, катастрофоустойчивость, и так далее.

5.4.2 Создание снэпшотов Снэпшоты создаются описанным ниже процессом, который использует возможность Data ONTAP создавать мгновенные (point‐in‐time) копии данных, размещенных в LUN‐ах, и не имеет отрицательного влияния на производительность Hyper‐V, а также имеет низкие накладные расходы с точки зрения степени использования самой системы хранения.

Для создания снэпшота с помощью консоли администрирования через ssh или telnet, следуйте шагам:

Шаг Действие 1. Войдите на контроллер системы хранения через ssh, telnet или консольный кабель 2. Выполните команду

snap create volume_name snapshot_name Для создания снэпшота с помощью командлайнового интерфейса NetApp SnapDrive, следуйте шагам:

Шаг Действие 1. Запустите окно командной строки на сервере Hyper‐V, к которому подключены диски. 2. Наберите в окне команду:

sdcli snap create ‐s snapshot_name ‐D DiskDriveID / VolumeMountPoint ‐x –u [yes/no] Где: ‐x: Позволяет снэпшотам браться только в том случае, если LUN‐ы определены в списке (опция ‐D) ‐u [yes/no]: Установка этой опции запускает обновление SnapMirror Пример: sdcli snap create –s VM01‐Snapshot1 –D F –x –u no

Для создания снэпшота с помощью мастера «Create Snapshot Wizard» из NetApp SnapDrive UI, следуйте шагам:

Шаг Действие 1. Запустите NetApp SnapDrive выбрав в Start Menu, NetApp ‐> SnapDrive. 2. В центральной колонке окна SnapDrive выберите нужный диск, подключенный к серверу

Hyper‐V. Затем в Action Pane справа выберите «Create Snapshot…»

3. Введите имя снэпшота и нажмите OK

5.4.3 Snapshot List/View Для просмотра списка доступных снэпшотов с помощью командлайнового интерфейса NetApp SnapDrive, следуйте шагам:

Шаг Действие 1. Запустите окно командной строки на сервере Hyper‐V, к которому подключены диски. 2. Введите следующую команду на сервере Hyper‐V:

sdcli snap list –d <Drive> Например: sdcli snap list –d F

Для просмотра снэпшотов в NetApp SnapDrive UI, следуйе шагам:

Шаг Действие 1. Запустите NetApp SnapDrive выбрав в Start Menu, NetApp ‐> SnapDrive. 2. Выберите из дерева слева нужный хост (localhost) и выберите в нем соответствующий

снэпшот для нужного диска. Детальная информация по выбранному снэпшоту будет показана ниже.

6 Создание виртуальной машины Решения виртуальных серверных инфраструктур, таких как Microsoft Hyper‐V, позволяет IT‐подразделению организации быстро развертывать виртуальные машины для любых применений: разработки, тестирования, и производства. При процессе развертывания виртуальных машин, как правило, генерируется много физических копий образов виртуальных машин, которые занимают значительные ресурсы на системе хранения, требуют индивидуального сопровождения и обслуживания этих многочисленных копий, ресурсов управления, и большого количества индивидуальных «ручных» настроек, требуемых при развертывании индивидуальных экземпляров виртуальных машин.

Интеграция виртуальной серверной среды Microsoft с технологиями хранения NetApp может решить эти проблемы, помогая организациям сократить объемы усилий, затрачиваемых на развертывание экземпляров виртуальных машин и снизить объемы занимаемого пространства на системах хранения, что, в свою очередь уменьшает затраты на занимаемое место, электропитание и охлаждение. Использование технологий NetApp Snapshot и FlexClone, равно как и дедупликации может помочь развернуть десятки, сотни и даже тысячи виртуальных машин в считанные минуты, одновременно снизив затраченные объемы на 50% или более, в сравнении с результатами традиционных систем хранения.

6.1 Концепция создания

NetApp Snapshot и FlexClone Традиционный процесс создания VM включает в себя утомительные и продолжительные по времени этапы, такие как распределение места на системе хранения, установка OS, обновлений и сервис‐паков, а также самих приложений, после чего созданную VM можно выдавать конечному потребителю. Система хранения NetApp с использованием технологий Snapshot и FlexClone позволяет создавать практически мгновенные, не использующие дополнительного пространства

на дисках, поддерживающие запись на них, клоны томов хранения и содержащихся на них данных. Такие тома типа FlexClone можно создавать на системе хранения за минуты. Они содержат LUN‐ы с виртуальными дисками (VHDs) которые могут быть подключены и использованы как индивидуальные экземпляры OS для виртуальных машин.

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

Дедупликация может быть запущена на production‐системе с минимальным влиянием на ее производительность, а в ряде случаев и определенных конфигураций даже привести к ее увеличению.

6.2 Процесс создания виртуальной машины

Figure 6‐1) Процесс создания VM в Hyper‐V, с использованием технологий клонирования NetApp.

6.2.1 Подготовка эталонной виртуальной машины В случае, когда инфраструктура требует многочисленных копий экземпляра OS, для выполнения этой задачи требуется проведение множества повторяющихся и занимающих время действий. Серверная виртуализация предлагает эффективный метод снизить количество этих действий, и позволяет подключать существующий образ как диск OS. При использовании такой возможности мы можем провести одну установку OS, и использовать ее в дальнейшем как эталонную. Эталонный образ может быть обновлен в любое время с помощью необходимых сервис‐паков и

приложений. Такая схема позволяет администраторам создавать сервера и десктоп‐системы для пользователей в считанные минуты.

Большинство из описанных ниже, в качестве процесса быстрого развертывания VM, шагов, могут быть заскриптованы и автоматизрованы. Для примера скрипта, использующего Windows PowerShell, смотрите Приложение A: Пример скрипта создания VM.

6.2.1.1 Создание хранилища под HyperV Server

Создание Aggregate Следуйте рекомендациям NetApp в отношении настроек при создании aggregates, для подробностей смотрите главу 4.2.1 Aggregates в этом документе.

Создание эталонного тома Создайте новый том на созданном на предыдущем шаге aggregate (см выше Создание Aggregate) и далее следуйте рекомендованным в NetApp best practice настройкам и установкам для тома типа flexible. Для подробностей смотрите 4.2.2 Тома типа Flexible в этом документе.

6.2.1.2 Подключение хранилища к HyperV Server

Подключение системы хранения NetApp с помощью NetApp SnapDrive Для управления хранилищем на Windows 2008 R2 Server можно использовать продукт NetApp SnapDrive for Windows. Для подробностей, рекомендаций по конфигурированию и использованию NetApp SnapDrive for Windows, смотрите 4.1.3 NetApp SnapDrive for Windows в этом документе. Для подробностей по инсталляции NetApp SnapDrive for Windows смотрите раздел 3.4.1.3 NetApp SnapDrive for Windows в документе TR3733: NetApp Implementation Guide for Microsoft Virtualization, и следуйте пошаговым инструкциям в разделе «Инсталляция».

Если вы используете подключение по iSCSI между сервером Hyper‐V системой хранения NetApp, убедитесь что установили и активировали подключение прежде, чем приступите к следующему шагу.

Создание LUN с помощью NetApp SnapDrive на «эталонном томе» Создайте новый LUN на томе, созданном на предыдущем шаге, под названием Создание эталонного тома и следуйте в этом рекомендованным настройкам для новых LUN. Для подробностей смотрите 4.2.3 Процесс создания LUN в этом документе.

6.2.1.3 Создание «эталонной копии» виртуальной машины

Создание VM с помощью HyperV Manager или SCVMM Для подробностей, смотрите Virtual Machine Provisioning в разделе 4 документа TR‐3733: NetApp Implementation Guide for Microsoft Virtualization, и следуйте пошаговым инструкциям для создания VM с помощью Hyper‐V Manager или SCVMM 2008.

Создайте виртуальную машину с фиксированным VHD (virtual hard disk), заданного размера для нужной OS, на LUN, созданном на предыдущем шаге Создание LUN с помощью NetApp SnapDrive на «эталонном томе».





Установка операционной системы в виртуальной машине Для подробностей смотрите главу 4.1.3 Install Operating System в документе TR‐3733: NetApp Implementation Guide for Microsoft Virtualization, и следуйте приведенным пошаговым инструкциям.

После выполнения инсталляции OS рекомендуется установить Hyper‐V Integration Services, также известных как Integration components (IC). IC устанавливаются для синхронизации времени, heartbeat, проведения shutdown, key/value pair exchange и для работы Volume Shadow‐Copy Service. Для подробностей, смотрите 4.1.1 Install Hyper‐V Integrated Services в TR‐3733: NetApp Implementation Guide for Microsoft Virtualization, и следуйте приведенным пошаговым инструкциям.

Установка всех необходимых приложений и обновлений Образ виртуальной машины является эталонным «золотым образом», который в дальнейшем можно использовать для создания сходных виртуальных машин. Чтобы избежать повторяющихся процессов инсталляций, будет отличной идеей сразу установить в нее все патчи и сервис‐паки, необходимые утилиты и приложения, антивирусы, средства выполнения скриптов и автоматизации, и так далее.

Использование SysPrep для OS VM и выключение VM VM, созданные с использованием эталонного образа, следует обработать инструментом Microsoft System Preparation (SysPrep) Tool прежде, чем вы запустите его в работу. Этот процесс генерирует secure ID (SID) для экземпляров OS, которые должны быть уникальны. Смотрите Microsoft KB 302577 для подробных инструкций по его использованию.

6.2.1.4 Включение дедупликации NetApp для тома Несколько LUN‐ов могут быть созданы на одном томе FlexVol и копии VHD могут храниться на этих LUN‐ах, которые могут быть подключены к серверу Hyper‐V как физические диски. Каждая виртуальная машина Hyper‐V может иметь один и тот же, или различный набор установленных приложений в их так называемой operating system environment (OSE). Экономия пространства может быть достигнуто с использованием технологии дедупликации NetApp. Для подробностей смотрите 5.2.2 Включение дедупликации, ранее в этом документе, и следуйте приведенным там пошаговым инструкциям.

Перед тем, как включить использование дедупликации для тома, убедитесь, что следуете нашим рекомендациям в best practices, и параметр space reservation на всех LUN‐ах выключен (параметр Space Reserved в свойствах LUN не выбран). Для подробностей, читайте про LUN‐ы ранее в этом документе, в главе 4.2.3, в подглаве ее, под названием Процесс создания LUN.

6.2.2 Клонирование эталонной виртуальной машины

Клонирование эталонной VM с помощью снэпшота Тома NetApp FlexVol могут быть клонами с практически нулевым использованием ими места, используя NetApp Snapshot. LUN‐ы, расположенные на клонах, могут подключаться и использоваться независимо и индивидуально, то есть выглядеть для сервера Hyper‐V как независимые физические диски.

При помощи NetApp SnapDrive, выберите физический диск, на котором расположен образ эталонной VM, и создайте снэпшот с этого физического диска. Для подробностей смотрите главу 5.4.2 Создание снэпшота, и следуйте приведенным там пошаговым инструкциям.





http://support.microsoft.com/kb/302577


Подключение дисков из снэпшотов с помощью NetApp SnapDrive Когда снэпшот успешно создан с помощью NetApp SnapDrive, мы можем подключить LUN‐ы, на нем содержащиеся, как индивидуальны диски. Мы можем создать тома FlexClone с такого снэпшота. Для подробностей смотрите главу 5.3.2 Создание тома FlexClone и следуйте приведенным там пошаговым инструкциям.

6.2.3 Provision Virtual Machines

Создание новой виртуальной машины Для создания желаемого количества виртуальных машин можно использовать Hyper‐V Server Manager или SCVMM. Для подробностей смотрите главу Virtual Machine Provisioning в разделе 4 документа TR‐3733: NetApp Implementation Guide for Microsoft Virtualization, следуйте приведенным там пошаговым инструкциям для процедур развертывания с использованием Hyper‐V Manager или SCVMM 2008.

Когда вы создаете новые VM, убедитесь, что включили опцию «Attach a Virtual Disk Later», для того, чтобы получить чистую конфигурацию VM, готовую для клонированных VHD.

Подключение эталонного образа VHD, расположенного на томе FlexClone В настройках каждой виртуальной машины (правый щелчок на виртуальной машине), в пункте «IDE Controller 0», добавьте жесткий диск и перейдите туда, где сделан VHD на томе NetApp FlexClone. Хорошая идея сразу переименовать VHD так, чтобы указать на имя виртуальной машины и/или диска в ней (пример: [VMname]_Vol0) до подключения его в VM. VM может быть запущена как обычно, и получить собственную уникальную конфигурацию (hostname, IP address, и так далее).

7 Резервное копирование и восстановление Резервное копирование и восстановление это наиболее важные компоненты вашего плана защиты данных. Если данные неожиданно повреждаются, система, или целиком сайт потеряны, резервная копия защитит и поможет восстановить данные вашего бизнеса.

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

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

Задача резервного копирования в серверной виртуальной инфраструктуре часто бывает весьма ресурсоемка (CPU, память, дисковый I/O, и сетевой трафик) и приводит к эффекту «бутылочного горла», который ограничивает производительность всей системы, и, следовательно, влияет на бизнес‐критичные задачи и приложения, использующие эту систему. Расписание резервного копирования должно быть тесно скоординировано с работой приложений и с учетом доступных ресурсов.


7.1.1 Технологии снэпшотов Для подробностей о технологии NetApp Snapshot , которая используется в решениях защиты данных для системы Microsoft Hyper‐V, смотрите главу 5.2.2 Включение дедупликации, ранее в этом документе.

7.1.2 Конфигурирование виртуальной машины Хранение данных в виртуализованной среде, приводит к появлению большого количества временных данных на виртуальных дисках. Требуется отделить такие данные, когда вы используете NetApp Snapshot и SnapMirror. Так как снэпшот «запирает» в себе блоки хранения, которые больше не могут использоваться, временные и неценные быстро изменяющиеся файлы быстро займут и израсходуют много места на дисках.

Следовательно, разумно было бы отделить ценные данные от временных, неценных и часто изменяющихся temp data.

Файл подкачки OS виртуальной машины, директории пользовательских и системных временных файлов, создаются на отдельном виртуальном диске, размещенном на отдельном data store, выделенном для хранения данных этого типа.

Размещение данных виртуальных машин Виртуальные машины, создаваемые на сервере Hyper‐V, используют для хранения специальных данных два файла <vmguid>.bin и <vmguid>.vsv.

Файл .bin используется для размещения содержимого оперативной памяти виртуальной машины, когда VM необходимо перейти в состояние saved state и размер его будет равен размеру, определенному для объема памяти виртуальной машины. Файл .vsv это сохраненное состояние устройств. При загрузке виртуальной машины, в файле .vsv резервируется 20MB. Когда виртуальная машина помещается в состояние saved state, этот файл может увеличиться, и вырасти вплоть до 50MB, что зависит от количества устройств, сконфигурированных в виртуальной машине. По умолчанию они сохраняются в директории конфигурации VM, которая должна размещаться на отдельном data store, и на отдельном томе.

Как показано на рисунке ниже, виртуальная машина создает свои конфигурационные файлы на диске, расположенном на томе с именем «FlexVol2», на котором отключено создание снэпшотов. Этот том также несет на себе файл виртуального диска, являющийся внутри виртуальной машины диском D:\, на котором размещаются файл подкачки и директория временных файлов OS. При установке следует убедиться, что все временные файлы отделены в специальный том, который не будет попадать в резервную копию. Другой том, по имени «FlexVol1», использует снэпшоты, и содержит LUN, являющийся диском C:\ виртуальной машины, и будет защищен резервной копией в снэпшот с помощью технологии NetApp Snapshot.

Рисунок 7‐1) Файлы, из которых состоит виртуальная машина, и их размещение.

7.2 Резервное копирование с использованием NetApp Snapshot Так как приложение и его данные соединены внутри экземпляра виртуальной машины, работающей поверх сервера Microsoft Hyper‐V, разработка решения резервного копирования становится более сложной, чем обычно. Существует несколько способов провести резервное копирование, например, установить агента резервного копирования на сервер Hyper‐V, чтобы сохранить содержимое дисков виртуальных машин целиком, или установить агента в каждую виртуальную машину, и сохранять необходимые данные изнутри виртуальной машины, и так далее. Так как большинство таких решений работают на хосте, то они заметно потребляют серверные ресурсы хоста. Ясно, что ресурсы сервера уже значительно используются работающими на нем многочисленными виртуальными машинами, чтобы нагружать его еще и задачей резервного копирования, которая займет некоторое количество ресурсов, отняв их у прикладных задач в виртуальных машинах. Следовательно, архитектура решения резервного копирования, основанная на возможностях системы хранения, облегчит жизнь сервера, и позволит виртуальным машинам использовать больше ресурсов.

Технология NetApp Snapshot предлагает эффективное решение по созданию частых, мало влияющих на производительность, и не занимающих много места резервных копий файлов, иерархий директорий, LUN‐ов и данных приложений. Такие снэпшоты улучшают общую надежность резервных копий системы, поскольку в самой малой степени влияют на производительность и безопасно создаются на работающей системе.

Ниже, мы рассмотрим процессы резервного копирования виртуальных машин с использованием продукта NetApp SnapDrive и Microsoft VSS/Diskshadow. В обоих случаях резервная копия создается в момент, когда виртуальная машина работает.

7.2.1 Резервное копирование отдельной виртуальной машины

7.2.1.1 Резервное копирование с использованием NetApp SnapDrive

Определение нужных LUNов и целей их использования В первую очередь следует определить, какие LUN‐ы выделены для хоста Windows 2008 Server, и то, как их используют виртуальные машины.

Для того чтобы посмотреть распределенные в Hyper‐V LUN‐ы используя NetApp SnapDrive UI или командный интерфейс, следуйте таким шагам:

Шаг Действие 1. Запустите NetApp SnapDrive через Start Menu выбрав NetApp ‐> SnapDrive. 2. Разверните дерево списка хоста «localhost». 3. Выберите пункт «Disks», чтобы просмотреть все LUN‐ы, распределенные на этот хост.

4. Закройте приложение SnapDrive для выхода. 5. Это же можно проделать с помощью интерфейса командной строки NetApp SnapDrive.

Например, наберите эту команду на сервере Hyper‐V: sdcli disk list

Проверка настроек VM для контроля места расположения диска VM и файлов конфигурации Из Hyper‐V Manager посмотрите на настройки виртуальной машины, чтобы увидеть расположение дисков, содержащих VM и ее конфигурационные файлы.

Для того чтобы посмотреть распределенные в Hyper‐V LUN‐ы используя NetApp SnapDrive UI или командный интерфейс, следуйте таким шагам:

Шаг Действие 1. Запустите Hyper‐V Manager Programs ‐> Administrative Tools ‐> Hyper‐V Manager. 2. Просмотрите список доступных виртуальных машин в интерфейсе Hyper‐V Manager.

Посмотрите настройки виртуальной машины, чтобы определить расположение диска (.vhd)

и файлов снэпшотов / конфигураций.

На скриншоте вы видите, что файл диска виртуальной машины расположен на диске F:\ (действующие данные), а переменные и временные данные, такие как снэпшоты и файлы конфигурации ‐ на H:\. Следовательно, нужно создавать снэпшоты диска F:\, чтобы сохранить виртуальную машину целиком.

Взятие снэпшота с помощью NetApp SnapDrive Снэпшот с данных может быть получен различными способами; используйте любую из процедур, описанных ранее в главе 5.4.2 Создание снэпшотов, чтобы создать новый снэпшот с LUN, подключенного к хост‐серверу Hyper‐V.

Список снэпшотов в SnapDrive После успешного создания снэпшотов, вам следует просмотреть их, чтобы убедиться, что они консистентны. Снэпшоты могут быть просмотрены различными путями, используйте одну из процедур, описанную в главе 5.4.3 выше, чтобы создать список или посмотреть набор снэпшотов для определенных LUN, подключенных к хост‐серверу Hyper‐V.

7.2.1.2 Резервное копирование с использованием Microsoft VSS и Diskshadow Microsoft Diskshadow это инструмент, поставляемый с Windows Server 2008, который помогает создавать и восстанавливать из снэпшотов диски, подключенные к хосту. Он имеет интерфейс похожий на интерфейс программы Diskpart, с помощью которого вы можете отдавать команды и запускать процедуры создания снэпшотов. Это можно эффективно использовать для резервного

копирования и восстановления виртуальных машин, обеспечивающего так называемую «crash consistent»* копию VM.

Действуйте согласно приведенным шагам с подробным описанием в таблице.

Шаг Действие 1. Запустите Hyper‐V Manager: Programs ‐> Administrative Tools ‐> Hyper‐V Manager. 2. Выберите нужную виртуальную машину и посмотрите в ее конфигурации имя диска, для

которого требуется создать резервную копию в снэпшот.

3. Для запуска резервной копии, требуется знать ID процесса VSS writer в Hyper‐V. Снэпшот будет создан от имени этого ID. Запустите окно с командной строкой и запустите в нем программу diskshadow. Вы увидите подсказку diskshadow, которая поможет вам создать снэпшоты. Воспользуйтесь следующей командой для получения ID процесса VSS writer: DISKSHADOW> LIST WRITERS Найдите WRITER по имени «Microsoft Hyper‐V VSS Writer» и запомните его Writer ID.

* Тип снэпшота «crash consistent» соответствует состоянию внезапно выключенной (crash) OS, так как система хранения не имеет средств взаимодействовать с уровнем выполняющейся прикладной задачи. В случае, если файловая система умеет обрабатывать ситуации внезапного выключения (пример: журналируемая FS, такая как ext3 или NTFS) это не повреждает данные FS. Другой вариант – «application (или database) consistent» создают такие работающие на уровне приложений продукты NetApp, как SnapManager for SQL Server/Oracle/SAP/Exchange/Sharepoint, в этом случае достигается корректность (консистентность) данных не только на уровне файловой системы, но и самого приложения, например базы данных SQL. (прим. перев.)

4. Используйте нижеприведенный набор команд для того, чтобы создать снэпшоты для нужных вам дисков: DISKSHADOW> DELETE SHADOWS ALL DISKSHADOW> SET CONTEXT PERSISTENT DISKSHADOW> SET METADATA C:\vmbackup.cab DISKSHADOW> SET VERBOSE ON DISKSHADOW> BEGIN BACKUP DISKSHADOW> ADD VOLUME C: alias systemDrive DISKSHADOW> ADD VOLUME F: alias vhdDrive DISKSHADOW> ADD VOLUME H: alias vmconfigDrive DISKSHADOW> WRITER verify {66841cd4‐6ded‐4f4b‐8f17‐fd23f8ddc3de} DISKSHADOW> CREATE DISKSHADOW> END BACKUP DISKSHADOW> LIST SHADOWS После успешного выполнения приведенных команд, вы увидите список всех shadow copies (снэпшотов Microsoft Windows Server) созданных для дисков, которые вы выбрали. Все эти команды можно поместить в скрипт, и передать на вход программы diskshadow следующим образом: C:\> diskshadow –s <path to the script file>

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

7.2.2 Резервное копирование Clustered Virtual Machine Процедура резервного копирования кластеризованной виртуальной машины не отличается от процедуры для отдельной, некластерной виртуальной машины. Однако некоторые дополнительные факторы могут влиять на процесс резервного копирования.

По этой причине мы советуем использовать следующие рекомендации, перед проведением операции резервного копирования. В Windows failover clustering manager, переведите virtual machine cluster resource в оффлайн перед началом проведения резервного копирования. Это необходимо для того, чтобы быть уверенным в том, что standby mode не включится во время проведения backup на primary node.

Для Windows 2008 Server требуется установка хотфикса. Причиной этому является то, что операции резервного копирования или восстановления VM завершаются неудачей, если файлы Hyper‐V VM записаны на том, смонтированный в failover cluster, используя volume GUID. Сверьтесь со статьей по приведенной ссылке о деталях данной ситуации. Загрузите и установите хотфикс Microsoft KB 958184

7.2.2.1 Резервное копирование с использованием NetApp SnapDrive Следуйте подробной инструкции в главе 7.2.1.1 Резервное копирование с использованием NetApp SnapDrive.

7.2.2.2 Резервное копирование с использованием Microsoft VSS и Diskshadow Следуйте подробной инструкции в главе 7.2.1.2 Резервное копирование с использованием Microsoft VSS и Diskshadow.

7.3 Восстановление с помощью NetApp Snapshots Экземпляр виртуальной машины, сохраненный с помощью NetApp Snapshot может быть восстановлено на любой произвольный момент времени (из числа сохраненных в снэпшоте моментов). Состояние данной виртуальной машины может быть восстановлено путем указания нужного экземпляра снэпшота. Требуется удостовериться, что выбранный диск в этот момент не


используется, что он размонтирован на момент восстановления его состояния к сохраненному в снэпшоте.

В подглавах ниже описываются шаги, производимые при выполнении операций восстановления с использованием NetApp SnapDrive или the Microsoft VSS и Diskshadow.

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

7.3.1.1 Восстановление с помощью NetApp SnapDrive

Восстановление с использованием SnapDrive Следуйте приведенным ниже процедурам для восстановления поврежденной виртуальной машины, из списка доступных снэпшотов.

Определение поврежденных дисков виртуальной машины Для проведения операции восстановления, требуется идентифицировать диски, которые содержат файлы дисков виртуальной машины.

Действуйте согласно приведенным шагам в таблице.

Шаг Действие 1. Запустите Hyper‐V Manager Programs ‐> Administrative Tools ‐> Hyper‐V Manager 2. Посмотрите список доступных виртуальных машин в интерфейсе Hyper‐V Manager.

Проверьте настройки виртуальной машины, чтобы определить расположение файла виртуального диска (.vhd).

Из приведенного скриншота видно, что файл диска виртуальной машины расположен на диске F:\. Таким образом, нижележащий диск может быть восстановлен из доступных снэпшотов.

Список снэпшотов в SnapDrive Просмотрите все доступные снэпшоты SnapDrive для нужного диска, на котором размещены файлы диска и виртуальной машины.

Действуйте согласно приведенным шагам в таблице.

Шаг Действие 1. Запустите приложение SnapDrive: Programs ‐> NetApp ‐> SnapDrive. 2. В выпадающем списке для соответствующего хоста (localhost) и для соответствующего

диска выберите «snapshot» чтобы посмотреть доступные снэпшоты.

3. Команда sdcli может также быть использована для вывода списка снэпшотов. Используйте следующую команду для того же действия: C:\> sdcli snap list ‐d <Drive> Например: sdcli snap list ‐d F

Восстановление из желаемого снэпшота Определите, из какого снэпшота вы хотите провести восстановление VM. Согласно приведенным шагам в таблице, проведите восстановление.

Шаг Действие 1. Запустите приложение SnapDrive: Programs ‐> NetApp ‐> SnapDrive. 2. Выберите «Restore Disk» для восстановления диска из выбранного снэпшота. Щелкните

«Yes» для подтверждения того, что восстанавливаемый диск не используется никаким приложением.

3. Команда sdcli также может использоваться для выполнения восстановления из снэпшота.

Используйте следующую команду для того же действия: C:\> sdcli snap restore –d <Drive> ‐s <Snapshot‐name> Например: sdcli snap list –d F –s VM01‐Snapshot1

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

7.3.1.2 Восстановление с помощью Microsoft VSS and Microsoft Diskshadow Данная глава описывает процесс восстановления с помощью Microsoft VSS и Diskshadow.

Шаг Действие 1. Запустите Hyper‐V Manager: Programs ‐> Administrative Tools ‐> Hyper‐V Manager. 2. Выберите нужную виртуальную машину и ее настройки, чтобы определить диск, который

следует восстановить.

3. Запустите окно командной строки, и запустите diskshadow. Вы увидите командную строку diskshadow, с помощью которой вы сможете произвести восстановление. Следующей командой вы сможете увидеть список всех доступных shadows (снэпшотов) DISKSHADOW> LIST SHADOWS

4. Используйте эту для монтирования shadow и восстановления из его содержимого: DISKSHADOW> EXPOSE %vhdDrive% X: Такая команда монтирует shadow на диск X: DISKSHADOW> EXIT Теперь все необходимые данные доступны на диске X: Инструменты копирования, такие как xcopy, robocopy можно использовать, для восстановления данных vhd. C:\> robocopy X: F: После завершения копирования, проверьте содержимое восстановленного диска и запустите виртуальную машину из восстановленных данных.

7.3.2 Восстановление в случае Clustered Virtual Machine Процедура восстановления кластеризованной виртуальной машины не отличается от процедуры отдельной, некластерной виртуальной машины. Однако некоторые дополнительные факторы могут влиять на процесс восстановления.

По этой причине мы советуем использовать следующие рекомендации, перед проведением операции восстановления. В Windows failover clustering manager, переведите virtual machine cluster resource в оффлайн перед началом проведения восстановления. Это необходимо для того, чтобы быть уверенным в том, что standby mode не включится во время проведения восстановления на primary node.

Для Windows 2008 Server требуется установка хотфикса. Причиной этому является то, что операции резервного копирования или восстановления VM завершаются неудачей, если файлы Hyper‐V VM записаны на том, смонтированный в failover cluster, используя volume GUID. Сверьтесь по приведенной ссылке о деталях данной ситуации. Загрузите и установите хотфикс Microsoft KB 958184.

После успешного восстановления виртуальной машины на соответствующем месте, требуется переконфигурировать кластерные ресурсы с помощью Windows failover cluster services (WFC).

Смотрите Quick Migration Setup and Configuration в разделе 5 в TR‐3733: NetApp Implementation Guide for Microsoft Virtualization для подробных инструкций по конфигурированию виртуальной машины как кластерного ресурса.

7.3.2.1 Восстановление данных с помощью NetApp SnapDrive Следуйте подробной инструкции в главе 7.3.1.1 Восстановление с помощью NetApp SnapDrive.

7.3.2.2 Восстановление данных с помощью Microsoft VSS and Diskshadow Следуйте подробной инструкции в главе 7.3.1.2 Восстановление с помощью Microsoft VSS и Diskshadow.

8 Катастрофоустойчивость и высокая доступность Работа бизнеса обычно сильно зависит от информационных систем и соответствующей IT‐инфраструктуры. Небольшой сбой приложения может вызвать значительные потери данных, или даже более серьезные проблемы. Существуют различные метрики, которые используются для разработки плана непрерывности бизнеса (business continuity plan). Две наиболее часто используемые, это recovery point objective (RPO) и recovery time objective (RTO). RPO, измеряемое в минутах и часах, указывает, за какой период времени информация может оказаться утерянной на момент аварии, а RTO, измеряемое в минутах, описывает то, как быстро нормальная работа может быть восстановлена.

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





Избыточное оборудование может обеспечить второй уровень защиты, чтобы противостоять повреждениям, вызывающим потери аппаратной части. Зеркалирование данных это еще один механизм, чтобы обеспечить доступность данных.

NetApp предлагает решение SnapMirror, которое усиливает IT‐инфраструктуру быстрым и гибким механизмом репликации данных через Ethernet или Fibre Channel. Это ключевой компонент, который стоит использовать при разработке и развертывании плана защиты данных. SnapMirror может работать как эффективное решение репликации данных, использующее преимущество нижележащих технологий NetApp, таких как Snapshot, тома FlexClone, дедупликация, и так далее. Катастрофоустойчивость это главная цель, но кроме этого SnapMirror может также помочь в других важных областях, таких как DR‐тестирование, тестирование приложений, распараллеливание нагрузки, удаленное архивирование на ленты, и удаленный доступ к данным.

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

• Уменьшается время допустимого простоя, необходимого для создания cold backup витуальных машин.

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

• Инфраструктура содержит различные типы OS, что затрудняет идентификацию консистентного состояния для резервной копии.

• Репликация через LAN / WAN может занять значительно больше ресурсов, чем ожидается.

• Планирование размещения на DR‐сайте системы, идентичной основной, ухудшает TCO и степень использования ресурсов инфраструктуры.

NetApp предлагает решения, дополняющие решения серверной виртуализации, и помогает решить перечисленные выше проблемы. Такие решения, как NetApp Snapshot, тома FlexClone, дедупликация, и другие, позволяют архитектору системы не просто разработать всеобъемлющее решение защиты данных, но и сделать его эффективным с точки зрения имеющихся ресурсов.

8.1.1 Снэпшоты NetApp NetApp Snapshot это фундамент для семейства продуктов защиты данных приложений SnapManager. По этой причине каждый продукт семейства SnapManager использует уникальные возможности технологии снэпшотов NetApp. Решение репликации данных, предлагаемое NetApp, работает с использованием зеркалирования мгновенных (point‐in‐time) копий. Последовательные снэпшоты зеркалируются в виде блоков, измененных с момента взятия предыдущего снэпшота. Такой инкрементальный характер уменьшает объемы использования хранилища, обеспечивая эффективное использование ресурсов в терминах пространства хранения и полосы пропускания.

8.1.2 Тома NetApp FlexClone Тома по технологии NetApp FlexClone обеспечивают гибкое управление данными. Тома типа FlexClone могут быть созданы мгновенно, из любого тома FlexVol, или снэпшота при котором снэпшот, существующий в состоянии read‐only преобразуется в том read‐write. Эти тома существуют в виде thin‐provisioned, что означает, что место на дисках занимает только инкрементальная разница. Возможности FlexClone в системе хранения NetApp помогают протестировать поведение системы в случае решений HA и DR. Возможно создать копию снэпшота в состоянии read‐write, доступную на DR‐сайте, и протестировать его доступность в случае настоящей аварии.

8.1.3 Дедупликация NetApp Технология дедупликации NetApp предлагает великолепное решение для устранения дублирующихся блоков данных, объединяя их в единственный блок. В результате мы получаем метод эффективного использования пространства хранения. Это решение в дальнейшем трансформируется в эффективный метод создания HA и DR решений, работающих совместно с технологиями репликации NetApp, при которых общий объем данных, необходимых для их зеркалирования на систему‐получатель, значительно уменьшается.

8.2 NetApp SnapMirror NetApp SnapMirror это простое, гибкое и эффективное решение построения катастрофоустойчивой инфраструктуры и дистрибуции данных. Репликация данных может осуществляться как по LAN, так и по WAN, предлагая для бизнес‐критичных приложений высокую доступность данных и быстрое восстановление доступа к ним даже в случае катастроф. Непрерывная репликация данных и передача измененных блоков, производимая на множество систем хранения NetApp одновременно, позволяет использовать репликацию для различных применений. Географически распределенный бизнес может получить преимущества от использования SnapMirror и сделать данные, существующие локально, доступными на всех своих сайтах, и легко повысить эффективность и продуктивность работы.

Упрощение процедур развертывания и администрирования Решение SnapMirror может быть запущено в считанные минуты, легко настраивается и управляется. Оно предлагает встроенную поддержку SNMP, которая позволяет с легкостью интегрироваться в существующий фреймворк SNMP. Простота администрирования снижает вероятность операторской ошибки во время процесса восстановления. SnapMirror интегрируется в семейство продуктов SnapManager, позволяя делать реплики состояния «application consistent»*. Различные режимы SnapMirror, такие как Sync, Semi‐sync и Async доступны по одной лицензии, что предлагает на выбор различные уровни RPO (от 0 до 24 hrs) в зависимости от требований бизнеса.

Эффективное использование ресурсов Репликация данных может осуществляться с системы хранения FC на менее дорогую систему с дисками SATA, использовать меньшую полосу пропускания, что может заметно экономить средства, особенно с использованием специальных технологий WAN acceleration сторонних

* Application consistent – тип копии данных приложения, непротиворечивой с точки зрения приложения. Например для базы данных SQL это копия базы, без неоконченных SQL‐транзакций. Для осуществления такой копии необходимо взаимодействие системы хранения с приложением, осуществляемое для NetApp через семейство продуктов SnapManager for SQL Server/Oracle/SAP/Exchange/Sharepoint/VI/Hyper‐V

компаний, используемых совместно с технологией NetApp Snapshot, пересылающей только измененные блоки данных. Зеркалированные данные, доступные с удаленной системы могут быть использованы в бизнес‐процессах, таких, как запуск резервного копирования, тестирование приложений или процедуры QA, и стейджинг (перенос разных типов данных на различные типы хранилищ).

SnapMirror имеет возможности автоматически создавать «чекпойнты» при передаче данных, что устраняет необходимость повторять передачу данных с самого начала, в случае прерывания этого процесса, восстановления «разбитого зеркала» или иных причин, при которых будет происходить «умная ресинхронизация».

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

SnapMirror в инфраструктуре HyperV Как указывалось выше, в главе 7.1.2 Конфигурация виртуальной машины, виртуальная машина, созданная на сервере Hyper‐V, отделяет временные данные. Следовательно, хранение таких данных на отдельном LUN, и исключение его из процесса репликации, приведет к заметному увеличению эффективности процесса репликации.

Hyper‐V имеет возможность экспортировать конфигурацию VM в отдельную директорию. Такая возможность дает возможность записать конфигурацию VM, и позже импортировать ее при восстановлении. Диск, на который экспортируется конфигурация VM, также может быть реплицирован на удаленный сайт, и эти данные в дальнейшем можно использовать в ходе процесса восстановления данных. Схема ниже показывает общий вид такого решения.

Figure 8‐1) Использование NetApp SnapMirror для катастрофоустойчивого решения с MS Hyper‐V

8.2.1 Ключевые технические концепции NetApp SnapMirror предлагает решение репликации, работающее в различных режимах, таких как «синхронная» и «асинхронная» репликация. Ключевая разница между этими режимами такова: в синхронном режиме, измененные данные посылаются с системы‐источника данных на систему‐получателя немедленно, как только они на ней появляются. Синхронный режим используется для критичных бизнес‐приложений, которым требуется близкая к 100% доступность и наилучший из возможного уровень RPO и RTO, но расстояние между контроллерами источника и получателя репликации не может превышать 100 километров. В случае использования асинхронной репликации данных между источником и получателем, изменения данных на получателе не так привязаны к изменениям данных на системе‐источнике. Изменения реплицируются по установленному расписанию на систему‐получатель. Ограничений по допустимому расстоянию между системами нет, но величины RPO и RTO исчисляются минутами и даже часами, и существует риск потери данных.

Синхронная репликация Синхронная репликация может использоваться в датацентрах со строгими требованиями к доступности данных. Этот режим посылает изменения на удаленную систему немедленно, как только они поступают на систему‐источник, вместо ожидания момента репликации, заданного расписанием. Такой вариант не подтверждает выполнение записи, пока запись не произойдет на удаленной системе, и она не подтвердит успешность этой записи. Это решение обеспечивает минимальную потерю данных, но имеет ограничение в 50‐100 километров между реплицируемыми устройствами. Оно определяется величинами задержек (latency) которые при увеличении расстояния также растут, и могут стать чересчур велики, так как записывающему данные приложению на хосте требуется слишком много времени, чтобы дождаться ответа от

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

Синхронная репликация начинается с однократной передачи baseline, содержащего полную копию реплицируемых разделов данных исходной системы хранения на удаленную систему‐получатель. В ходе этой передачи статус SnapMirror будет показан как «Transferring». После успешного завершения baseline transfer, SnapMirror перейдет в синхронный режим репликации, и статус изменится на «In‐Sync».

Для подробностей о принципах работы и настройке SnapMirror смотрите в документе TR‐3326: SnapMirror Sync and SnapMirror Semi‐Sync Overview and Design Considerations.

Асинхронная репликация SnapMirror в асинхронном режиме может работать как на уровне volume так и на уровне qtree. Он производит инкрементальную, блочную репликацию с периодичностью от раза в минуту, до раза в несколько дней. Нет ограничения на дистанцию между реплицируемыми системами, поэтому такое решение часто используют для построения защиты от региональных катастроф.

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

Для подробностей о принципах работы SnapMirror, смотрите документ TR‐3446: SnapMirror Async Overview and Best Practices Guide.

8.2.2 Репликация с использованием NetApp SnapMirror Как уже было сказано в главе 8.2.1 Ключевые технические концепции, SnapMirror работает в синхронном или асинхронном режимах. Для понимания участвующих в этом процессов, давайте рассмотрим сценарии использования SnapMirror для межсайтовой и внутрисайтовой репликации. Например, настроим SnapMirror в синхронном режиме для внутрисайтовой репликации, и в асинхронном для межсайтовой.





Figure 8‐2) Решение, использующее «внутрисайтовую» репликацию Synchornous SnapMirror

Приведенный рисунок показывает схему компонентов верхнего уровня для внутрисайтовой репликации. Хост‐сервер Hyper‐V запускает несколько экземпляров VM с дисками размещенными на томе системы хранения, и это том доступен для записи. Система‐источник устанавливает синхронную репликацию SnapMirror с другой системой хранения на том же сайте. Реплицированный том на системе‐получателе находится в состоянии read‐only и становится доступным для использования только в случае разрыва состояния репликации SnapMirror.

8.2.2.1 Конфигурирование снэпшотов VM на первичной системе хранения NetApp Сверьтесь с главой 7.2.1.1 Резервное копирование с использованием NetApp SnapDrive для подробных инструкций по процедуре создания резервной копии виртуальных машин с использованием NetApp Snapshot на первичной системе хранения NetApp.

Следуйте приведенным в таблице командам, для запуска репликации SnapMirror:

Шаг Действие 1. Запустите следующую команду из командной строки сервера Hyper‐V. Используйте букву

диска, на котором расположены диски виртуальной машины. C:\> sdcli snap create –s <snapshot‐name> ‐D <Drive> ‐x –u yes ‐x Снэпшот будет взят только для LUN‐ов, определенных в Drive list ‐u (yes / no) Установка этой опции в yes запустит SnapMirror update. Например: sdcli snap create ‐s VM01‐Snapshot1 ‐D F ‐x ‐u yes

8.2.2.2 Конфигурирование репликации NetApp SnapMirror Replication между системами хранения NetApp Для конфигурирования репликации NetApp SnapMirror для виртуальных машин, требуется идентифицировать тома, на которых располагаются файлы VHD виртуальных машин. Эти тома требуется включить в конфигурацию.

Воспользуйтесь приведенной ниже процедурой установки синхронной репликации SnapMirror между системой‐источником и системой‐получателем.

Все приведенные команды следует исполнять в административной консоли системы хранения, к которой можно подключиться через telnet или ssh.

Шаг Действие 1. Убедитесь, что лицензии SnapMirror введены на обеих системах хранения. Если лицензии

не введены, их нужно ввести следующими командами: sourceFiler> license add snapmirror_license_code destnFiler> license add snapmirror_license_code

2. В консоли системы‐источника определите хосты, которым будет разрешено использовать SnapMirror. Воспользуйтесь следующей командой: sourceFiler> options snapmirror.access host=destnFiler

3. Для синхронного режиме SnapMirror добавьте следующие строки в файл /etc/snapmirror.conf на системе‐получателе: sourceFiler:vhdVolume0 destnFiler:vhdVolume1 ‐ sync Приведенная строка конфигурации связывает том vhdVolume0 на системе‐источнике (sourceFiler) и том vhdVolume1 на системе‐получателе (destnFiler) в отношения репликации в синхронном режиме (synchronous SnapMirror).

4. Убедитесь, что размер тома на системе‐получателе (vhdVolume1) равен или больше, чем том vhdVolume0 на системе источнике, и переведен в «restricted mode». Используйте приведенную ниже команду для перевода тома в «restricted mode»: destnFiler> vol restrict vhdVolume1

5. Включите SnapMirror на обеих системах командой: sourceFiler> snapmirror on destnFiler> snapmirror on

6. Для запуска репликации SnapMirror используйте команду: destnFiler> snapmirror initialize –S sourceFiler:vhdVolume0 destnFiler:vhdVolume1 Приведенная команда создаст начальную (baseline) полную копию исходного тома (vhdVolume0) и запустит процесс репликации изменений.

7. Система хранения работает как обычно, в то время как процесс репликации выполняется в фоне. Состояние процесса репликации можно посмотреть с помощью команды: destnFiler> snapmirror status В случае выполнения базовой начальной репликации (baseline) команда покажет статус «Transferring». После завершения создания начальной реплики, статус изменится на «In‐Sync».

После выполнения приведенных выше процедур, репликация типа synchronous SnapMirror будет установлена между системами хранения.

8.2.2.3 Восстановление работы VM с другой системы NetApp В случае аварии любого рода, такого, как, например, случайное удаление или потеря данных, или проблемы с оборудованием, могут быть использованы данные с системы‐получателя репликации.

Когда проблема случилась с сайтом‐источником, тома и LUN‐ы оказываются отключены, и все виртуальные машины переходят в critical state. Данные могут быть восстановлены с системы‐получателя. Это можно сделать, подключаясь к томам‐репликам на системе‐получателе данных.

Воспользуйтесь следующими шагами для подключения к данным на системе‐получателе.

Шаг Действие 1. Запустите следующую команду sdcli из командной строки сервера Hyper‐V:

C:\> sdcli disk connect ‐p $LUNPath ‐d $VolMountPt ‐I $fqdn $iqn ‐dtype dedicated $LUNPath – указывает путь к LUN, на котором лежат файлы VHD $VolMountPt – указывает диск / точку монтирования тома, в которую монтируется LUN на хосте $fqdn – Fully Qualified Domain Name (имя хоста) сервера $iqn – IQN node name (iSCSI) / WWPN (FC) интерфейсов хост‐системы

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

8.2.3 Катастрофоустойчивость с использованием NetApp SnapMirror Рассмотрим процессы конфигурирования репликации между сайтами (между двумя физически различными сайтами в разных местах) с использованием NetApp SnapMirror для защиты данных от аварии на сайте.

Figure 8‐3) Решение, использующее «межсайтовую» репликацию Asynchronous SnapMirror

Приведенный рисунок показывает схему компонентов верхнего уровня для межсайтовой репликации. Хост‐сервер Hyper‐V запускает несколько экземпляров VM с дисками размещенными на томе системы хранения, и это том доступен для записи. Система‐источник устанавливает асинхронную репликацию SnapMirror с другой системой хранения на другом сайте. Реплицированный том на системе‐получателе находится в состоянии read‐only и становится доступным для использования только в случае разрыва состояния репликации SnapMirror.

8.2.3.1 Конфигурирование резервной копии с помощью снэпшота для VMs на первичной системе хранения NetApp Следуйте указаниям в главе 7.2.1.1 Резервное копирование с использованием NetApp SnapDrive для подробных инструкций по процедуре создания резервной копии с помощью снэпшотов NetApp для виртуальных машин на первичной системе хранения NetApp.

Следуйте указанным ниже командам, для инициализации репликации SnapMirror:

Шаг Действие 1. Запустите следующую команду из командной строки сервера Hyper‐V. Используйте букву

диска, на котором расположены диски виртуальной машины. C:\> sdcli snap create –s <snapshot‐name> ‐D <Drive> ‐x –u yes ‐x Снэпшот будет взят только для LUN‐ов, определенных в Drive list ‐u (yes / no) Установка этой опции в yes запустит SnapMirror update. Например: sdcli snap create ‐s VM01‐Snapshot1 ‐D F ‐x ‐u yes

8.2.3.2 Конфигурирование репликации NetApp SnapMirror между системами хранения NetApp Сценарий межсайтовой репликации должен включать в себя процедуры конфигурирования асинхронной репликации SnapMirror для томов, которые несут на себе файлы .vhd виртуальных машин.

Следуйте указанной процедуре для установки асинхронной репликации SnapMirror между исходной системой хранения и системой‐получателем.

Шаг Действие 1. Сверьтесь с разделом 8.2.2.1 и следуйте его шагам по проверке лицензий и включения

доступа для системы‐получателя. 2. Отредактируйте конфигурационный файл /etc/snapmirror.conf на системе‐получателе, и

включите туда следующую строку: sourceFiler:vhdVolume0 destnFiler:vhdVolume1 kbs=2000,restart=always 15 * * 1,2,3,4,5 Эта запись задает репликацию между sourceFiler ‐ vhdVolume0 на destnFiler ‐ vhdVolume1 с максимальной полосой передачи в2000 kilobit в секунду, каждые 15 минут каждого часа, с понедельника по пятницу.

3. Для инициализации процесса репликации SnapMirror используйте команду: destnFiler> snapmirror initialize –S sourceFiler:vhdVolume0 destnFiler:vhdVolume1 Приведенная команда создаст начальную реплику (baseline) в виде полной копии исходного тома (vhdVolume0) и проинициализирует процессы репликации.

4. Система хранения работает как обычно, в то время как процесс репликации выполняется в фоне. Состояние процесса репликации можно посмотреть с помощью команды: destnFiler> snapmirror status В случае выполнения базовой начальной репликации (baseline) команда покажет статус «Transferring». После завершения создания начальной реплики, статус изменится на «mirrored».

8.2.3.3 Restore Service for VMs between NetApp Storage Systems Сверьтесь с главой 8.2.2.3 Восстановление работы VM с другой системы NetApp и следуйте сходным шагам для подключения томов и LUN‐ов, доступных с системы‐получателя, восстановите работу виртуальных машин.

9 Управление и наблюдение Наблюдение и управление – это весьма важные операции для системы Hyper‐V. NetApp предлагает соответствующие инструменты для наблюдения за состоянием здоровья системы хранения, обеспечивая уведомления, генерацию отчетов, и управление процессом роста хранилища. Этот раздел рассматривает возможности, доступные для целей наблюдения и управления.

9.1 Наблюдение за использованием пространства хранения с помощью NetApp Operations Manager NetApp Operations Manager это инструмент наблюдения, управления, и генерации отчетов для всех систем хранения NetApp в организации. Когда вы используете thin provisioning, NetApp рекомендует развернуть Operations Manager и настроить уведомления по e‐mail и на sms/пейджер для необходимой группы администраторов. Для системы хранения, использующей thin provisioning, очень важно постоянно и своевременно наблюдать за состоянием свободного места на aggregates. Правильное и своевременное уведомление о размере свободного места на системе хранения означает, что дополнительное место можно добавить прежде, чем пространство на aggregate окончательно заполнится. Для детального рассмотрения темы настройки уведомлений в Operations Manager, смотрите главы Configuring Alarms и Managing Aggregate Capacity в руководстве Operations Manager Administration Guide на NetApp NOW.

Для общего обзора NetApp Operations Manager, смотрите раздел Operations Manager на вебсайте NetApp.

9.2 Управление изменением размеров хранилища

Увеличение физического диска Довольно просто увеличить размер хранилища для физических дисков Hyper‐V (SAN LUN); однако, этот процесс может быть выполнен, только если VM, хранящаяся на физическом диске, выключена (shut down). NetApp рекомендует использовать SnapDrive для эффективного выполнения этой операции. Подробные инструкции могут быть найдены в документе SnapDrive for Windows Installation and Administration Guide. Иначе, возможно сделать это более длинным, ручным способом, описанным ниже.

Для увеличения физического диска, следуйте шагам:

Шаг Действие 1. Выключите (shut down) VM размещенную на физическом диске, который следует

расширить. 2. Откройте FilerView (http://controller/na_admin). 3. Выберите «LUNs». 4. Выберите «Manage». 5. Из списка в левой панели выберите LUN, соответствующий физическому диску который

будет расширен. 6. В поле «Size», введите новый размер LUN и нажмите «Apply». 7. Откройте Server Manager на сервере Hyper‐V, и щелкните правой клавишей «Disk

Management», затем выберите «Rescan Disks». 8. Для VM с OS Windows, вы можете использовать утилиту diskpart для расширения

файловой системы. Для подробностей, смотрите A Description of the Diskpart Command‐Line Utility или

http://now.netapp.com/NOW/knowledge/docs/DFM_win/rel36r1/html/software/opsmgr/monitor5.htm

http://now.netapp.com/NOW/knowledge/docs/DFM_win/rel36r1/html/software/opsmgr/filesys4.htmhttp:/now.netapp.com/NOW/knowledge/docs/DFM_win/rel36r1/html/software/opsmgr/filesys4.htm

http://now.netapp.com/NOW/knowledge/docs/DFM_win/rel36r1/html/software/opsmgr/filesys4.htmhttp:/now.netapp.com/NOW/knowledge/docs/DFM_win/rel36r1/html/software/opsmgr/filesys4.htm

http://www.netapp.com/us/products/management-software/operations-manager.html

http://support.microsoft.com/default.aspx?scid=kb;en-us;300415


Для VM с OS Linux, вы можете использовать утилиту ext2resize для расширения файловой системы. Для подробностей, смотрите GNU ext2resize

Увеличение файлов VHD Файлы VHD могут быть увеличены; однако, это требует отключения (power off) VM. Увеличение размера файла VHD это только половина процесса увеличения доступной емкости хранения; далее вам нужно увеличить файловую систему, лежащую на нем, после того, как VM загрузится. Отметьте, что корневой том, такой как диск C:\ в Windows и / в Linux не может динамически расширяться, когда операционная система работает. Для таких томов смотрите главу Расширение загрузочных томов ниже, в этом разделе (раздел 9.2). Для всех других томов, вы можете использовать собственные средства и инструменты OS для увеличения тома.

Для увеличения файла VHD, следуйте шагам:

Шаг Действие 1. Выключите VM. 2. В Hyper‐V manager, выделите нужную VM и нажмите «Settings» (справа). 3. В окне настроек VM, выберите жесткий диск, который был увеличен, и щелкните «Edit».

Это откроет мастер «Edit Virtual Hard Disk». 4. Щелкните «Expand» и «Next». 5. Введите новый размер, щелкните «Next», и «Finish». Убедитесь, что имеется достаточно

места на физическом диске для размещения файла VHD (особенно для VHD фиксированного размера).

6. Щелкните «OK» в окне «Settings» и включите (power on) данную VM. Помните, что хотя вы и увеличили VHD, вам по‐прежнему нужно увеличить размещенную на нем файловую систему. Для этого следуйте указаниям главы Увеличение файловой системы VM.

Увеличение физического диска, переданного в VM как passthrough disk Увеличение физического диска, непосредственно переданного в VM (также называемого pass‐through disk) , в отличие от увеличения VHD, не требует отключения (shut down) VM, когда вы выполняете предложенные шаги увеличения размера диска.

Увеличение диска типа «pass‐through» требует только лишь перезагрузки VM,чтобы новый размер диска увиделся в VM.

Для увеличения диска типа pass‐through, следуйте шагам:

Шаг Действие 1. Откройте FilerView (http://controller/na_admin). 2. Выберите пункт меню «LUNs». 3. Выберите «Manage». 4. Из списка в левой панели выберите LUN, соответствующий физическому диску который

будет расширен. 5. В поле «Size», введите новый размер LUN и нажмите «Apply». 6. Откройте Server Manager на сервере Hyper‐V, и щелкните правой клавишей «Disk

Management», затем выберите «Rescan Disks». 7. Перезагрузите VM, работающую с этим физическим диском. Новый диск будет виден в

менеджере дисков OS VM. Помните, что хотя вы и увеличили размер физического диска, но вам по прежнему нужно увеличить файловую систему, расположенную на нем. Далее следуйте указаниям главы «Увеличение файловой системы в VM».

http://ext2resize.sourceforge.net/

Увеличение файловой системы в VM (NTFS или ext3) Когда VHD или физический диск увеличивается в размерах, вам также обычно нужно еще увеличить и файловую систему, например NTFS или ext3, которые размещены на этом диске. Этот процесс можно выполнить с помощью свободно распространяемых инструментов, но не в то время, когда VM, использующая диск, работает.

Для того чтобы расширить файловую систему OS в виртуальной машине, следуйте шагам:

Шаг Действие 1. Подключитесь к VM. 2. Для VM с OS Windows, вы можете использовать утилиту diskpart для расширения

файловой системы. Для подробностей, смотрите A Description of the Diskpart Command‐Line Utility или Для VM с OS Linux, вы можете использовать утилиту ext2resize для расширения файловой системы. Для подробностей, смотрите GNU ext2resize.

Увеличение загрузочных томов Корневые, загрузочные разделы, такие как C:\ в VM под Windows, и / в VM под Linux, нельзя увеличить «на ходу», или когда OS работает. Есть простой способ расширить файловую систему на таком томе, не требующую каких‐то сторонних средств (кроме ext2resize). Этот процесс требует, чтобы VHD, размер которого следует изменить, был подключен к другой VM с такой же OS, используя процессы, определенные ранее.

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

10 Выводы Серверная виртуализация это важный компонент процесса виртуализации датацентра, играющая ключевую роль в этой инициативе. Этот документ предлагает подробное руководство в проектировании и внедрении решения Microsoft Server virtualization с использованием систем хранения NetApp. Он также предлагает детальное рассмотрение всех аспектов интеграции для каждой из ключевых технологий NetApp, а также то, как эти технологии работают, дополняя решения серверной виртуализации Microsoft. NetApp находится на переднем крае решения сложных бизнес‐проблем с помощью своих инновационных технологий, и обеспечивает полный спектр их решений.

Данный документ не нацелен быть исчерпывающим руководством по разработке и реализации решений. Для планирования и разработки специфических систем по‐прежнему требуется углубленная экспертиза. Свяжитесь с вашим контактом в команде NetApp, чтобы побеседовать о вашей задаче с одним из наших экспертов по Microsoft Hyper‐V. Мы целенаправленно занимаемся тем, чтобы помочь вам преобразовать ваш датацентр, чтобы позволить вашему бизнесу успешно двигаться вперед.




Приложение A: Пример скрипта создания VM Скрипт упрощает процесс Rapid VM Provisioning автоматизируя процессы создания снэпшотов, Disk Connection и VM Creation.

Предварительные условия, которые необходимо соблюсти, перечислены ниже.

1. Aggregate и том (GoldenVol) создаются на системе хранения NetApp 2. SnapDrive 6.0.1 установлен на Windows 2008 Server 3. Сессия iSCSI уже установлена между SnapDrive и системой хранения NetApp 4. LUN / Disk (GoldVMImg1) создан из под SnapDrive и подключен как диск E: к хосту под

Windows 5. Создаются несколько LUN‐ов, с образами VM на них, и для тома включается дедупликация 6. Эталонный образ VM (DemoVM01.vhd) располагается на диске E: (LUN GoldVMImg1)

Заранее заданные переменные в скрипте, которые могут быть изменены при необходимости, таковы:

1. IP‐адрес системы хранения устанавливается в переменной $filer 2. iSCSI IQN number хоста Windows 2008 следует задать в переменной $iqn

# Description ‐ Script for Provisioning Multiple Virtual Machines on Hyper‐V Server # Purpose ‐ To Rapidly Provision desired number of Virtual Machines on Hyper‐V Server # Tools ‐ PowerShell, SnapDrive CLI, WMI # Inputs – User‐desired Snapshot Name and Required Number of Virtual Machines # # This sample code is provided AS IS, with no support or warranties of any # # kind, including but not limited to warranties of merchantability or # # or fitness of any kind, expressed or implied. $filer = "10.73.69.182" $iqn = "iqn.1991‐05.com.microsoft:hypervserver1" $GoldenDrive = "E" $GoldenVolume = "GoldenVol" $BaseVHD = "DemoVM01.vhd" function Create_VM ( $VM_Service, $VMName ) { $wmiClassString = "\\" + "LocalHost" + "\root\virtualization:Msvm_VirtualSystemGlobalSettingData" $wmiClass = [WMIClass]$wmiClassString $newVSGlobalSettingData = $wmiClass.CreateInstance() while ($newVSGlobalSettingData.psbase.Properties ‐eq $null) {} # Set the VM name $newVSGlobalSettingData.psbase.Properties.Item("ElementName").value = $VMName $status = $VM_Service.DefineVirtualSystem($newVSGlobalSettingData.psbase.GetText(1)) if ($status.ReturnValue ‐eq 0) { $NewVM_PATH = $status.DefinedSystem return $NewVM_PATH } } function Attach_VHD ( $VM_Service, $NewVM_PATH, $VHD ) { $ListOfControllers = get‐wmiobject ‐namespace root\virtualization Msvm_ResourceAllocationSettingData | where‐object {$_.ResourceSubType ‐like "*Emulated*IDE*"} foreach ($Controller in $ListOfControllers) { if ($Controller.Address ‐eq 0) {

$IDEController0 = $Controller } } $DiskDefault = get‐wmiobject ‐namespace root\virtualization Msvm_ResourceAllocationSettingData | where‐object {($_.ResourceSubType ‐like "Microsoft Synthetic Disk Drive") –and ($_.InstanceID ‐like '*Default*')} $DiskDrive = $DiskDefault.psbase.Clone() $DiskDrive.Parent = $IDEController0.__PATH $DiskDrive.Address = 0 $Status = $VM_Service.AddVirtualSystemResources($NewVM_PATH, $DiskDrive.psbase.GetText(1)) if ($Status.ReturnValue –eq 0) { $NewDiskDrive_PATH = $Status.NewResources } $VHDDefault = get‐wmiobject ‐namespace root\virtualization Msvm_ResourceAllocationSettingData | where‐object {($_.ResourceSubType ‐like "Microsoft Virtual Hard Disk") –and ($_.InstanceID ‐like '*Default*' )} $NewDiskDrive = [WMI]"$NewDiskDrive_PATH" $VHDisk = $VHDDefault.psbase.Clone() $VHDisk.Parent = $NewDiskDrive.__PATH $VHFile = $VHD $VHDisk.Connection = $VHFile $VM_Service.AddVirtualSystemResources($NewVM_PATH, $VHDisk.psbase.GetText(1)) } ############## Create the Snapshot for the GoldenDrive ######################### $SnapshotName = read‐host "Enter a name for the Snapshot" sdcli snap create ‐s $SnapshotName ‐D $GoldenDrive ‐x write‐host Write‐host "Disk Snapshot Created Successfully" write‐host $count = read‐host " Enter the number of Virtual Machines to be created" $fqdn = hostname $LUNPath = $filer + ":" + "/vol/" + $GoldenVolume +"/.snapshot/" + $SnapshotName + "/GoldVMImg1" ############# Create Volume Mount Points for the LUNs ####################### $MountDir = "c:\DiskMountDir\" if (Test‐Path $MountDir){ write‐host "Directory Exists" } else{ New‐Item c:\DiskMountDir\ ‐type directory } ############################################################################### for($i=1; $i ‐le $count; $i++) { $VolMountPt = $MountDir + "$i" New‐Item $VolMountPt ‐type directory sdcli disk connect ‐p $LUNPath ‐d $VolMountPt ‐I $fqdn $iqn ‐dtype dedicated if (test‐Path $volMountPt\$BaseVHD){ $NewVMName = "DemoVM_"+$i+".vhd" rename‐item $VolMountPt\$BaseVHD $NewVMName }else{ write‐host "VM VHD doesn't exist" } $VHD = $VolMountPt + "\" + $NewVMName $VMName = $NewVMName.trimend('.vhd') $VM_Service = Get‐WmiObject –namespace root\virtualization Msvm_VirtualSystemManagementService

$NewVM_PATH = Create_VM $VM_Service $VMName start‐sleep ‐seconds 2 Attach_VHD $VM_Service $NewVM_PATH $VHD $VM = Get‐WmiObject ‐Namespace root\virtualization ‐Query "Select * From Msvm_ComputerSystem where ElementName = '$VMName' " $VM.RequestStateChange(2) }

Приложение B: Пример скрипта резервного копирования снэпшота

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

# Description ‐ Script for creating NetApp Snapshot for Backup Purposes # Purpose ‐ To create NetApp Snapshot via sdcli which can be used as point‐in‐time recovery copies # Tools ‐ PowerShell, SnapDrive CLI # Inputs – User‐desired Snapshot Name and the intended drive on which the VM (vhd) resides # Execution – Save the contents to PowerShell script file (scriptBackup.ps1). Execute from Windows PowerShell # # This sample code is provided AS IS, with no support or warranties of any # # kind, including but not limited to warranties of merchantability or # # or fitness of any kind, expressed or implied. $SnapshotName = Read‐Host "Enter a Name for the Snapshot " $MountPoint = Read‐Host "Enter the Drive which you want to Backup " sdcli snap create ‐s $SnapshotName ‐D $MountPoint ‐x write‐output "SnapDrive Snapshot completed Successfully" sdcli snap list –d $MountPoint

Пример скрипта резервного копирования с использованием MS VSS и DiskShadow В данный скрипт включены команды, создающие снэпшот с использованием сервиса Windows DiskShadow / VSS для определенного диска, на котором размещена виртуальная машина. Убедитесь, что вы включили как диск, содержащий конфигурационный файл, так и файл VHD.

# Description ‐ Script for creating snapshots using Diskshadow # Purpose ‐ To create snapshot copies that can serve as recovery copies using Microsoft Diskshadow & vssadmin # Tools – Microsoft utilities Diskshadow # Execution – Save the contents to a text file using a notepad (script.txt). Execute using diskshadow –s script.txt # # This sample code is provided AS IS, with no support or warranties of any # # kind, including but not limited to warranties of merchantability or # # or fitness of any kind, expressed or implied. DELETE SHADOWS ALL SET CONTEXT PERSISTENT SET METADATA C:\vmbackup.cab SET VERBOSE ON BEGIN BACKUP ADD VOLUME C: alias systemDrive ADD VOLUME F: alias vhdDrive ADD VOLUME H: alias vmconfigDrive WRITER verify {66841cd4‐6ded‐4f4b‐8f17‐fd23f8ddc3de} CREATE END BACKUP LIST SHADOWS

Приложение C: Пример скрипта восстановления из снэпшотов

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

# Description ‐ Script to restore a lost drive using NetApp Snapshots # Purpose ‐ To restore a drive from using the NetApp Snapshots from the available list of snapshots # Tools ‐ PowerShell, SnapDrive CLI # Inputs – Drive that user intends to restore and name of the snapshot copy from the list that it displays # Execution – Save the contents to PowerShell script file (scriptRestore.ps1). Execute from Windows PowerShell # # This sample code is provided AS IS, with no support or warranties of any # # kind, including but not limited to warranties of merchantability or # # or fitness of any kind, expressed or implied. $MountPoint = Read‐Host "Enter the Drive that you want to Restore" sdcli snap list ‐d $MountPoint $SnapshotName = Read‐Host "Enter the Snapshot Name from which you want to Restore from the above list" sdcli snap restore ‐d $MountPoint ‐s $SnapshotName

Приложение D: Пример скриптов катастрофоустойчивого решения

Пример скрипта репликации с помощью NetApp SnapMirror # Description ‐ Script for setting up SnapMirror Replication Relationship # Purpose ‐ To setup SnapMirror relationship between the Primary and Secondary NetApp storage systems # Tools ‐ PowerShell, plink (SSH Communication) # # This sample code is provided AS IS, with no support or warranties of any kind, including but not limited to ## warranties of merchantability or fitness of any kind, expressed or implied. # Posted: July 2009 : NetApp $PrimFiler = Read‐Host "Enter the Hostname of the Storage System in the Primary Site" $DRFiler = Read‐Host "Enter the Hostname of the Storage System in the DR Site" Write‐Host " 1 ‐ Setup SnapMirror relation between Storage Systems 2 ‐ View SnapMirror Status of an existing setup * ‐ Exit the script" $Choice = Read‐Host "Enter the Selection" if ($Choice ‐eq 1) { $SourceVol = Read‐Host "Enter the name of the Source Volume on which the VM resides" $DRVol = Read‐Host "Enter the name of the Destination Volume" $DriveLetter = Read‐Host "Enter the drive letter on which the VM resides" $unq = random $SnapshotName = $PrimFiler + "‐" + $unq $Source = $PrimFiler + ":" + $SourceVol $Destn = $DRFiler + ":" + $DRVol c:\plink\plink.exe ‐i c:\plink\rsa_priv_plink_key.ppk root@"$PrimFiler" options snapmirror.enable on c:\plink\plink.exe ‐i c:\plink\rsa_priv_plink_key.ppk root@"$DRFiler" options snapmirror.enable on Write‐Host " " Write‐Host "SnapMirror Enabled on Primary & DR FAS Systems" Write‐Host " " c:\plink\plink.exe ‐i c:\plink\rsa_priv_plink_key.ppk root@"$PrimFiler" options snapmirror.access all Write‐Host " " Write‐Host "SnapMirror Access Enabled on Primary & DR FAS Systems"

Write‐Host " " c:\plink\plink.exe ‐i c:\plink\rsa_priv_plink_key.ppk root@"$DRFiler" vol restrict $DRVol c:\plink\plink.exe ‐i c:\plink\rsa_priv_plink_key.ppk root@"$DRFiler" wrfile ‐a /etc/snapmirror.conf "$Source $Destn ‐ sync" sdcli snap create ‐s $SnapshotName ‐D $DriveLetter Write‐Host "SnapMirror setup is done. Press any key to initialize the baseline transfer ..." $x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown") c:\plink\plink.exe ‐i c:\plink\rsa_priv_plink_key.ppk root@"$DRFiler" snapmirror initialize ‐S $Source $Destn sleep ‐Seconds 5 c:\plink\plink.exe ‐i c:\plink\rsa_priv_plink_key.ppk root@"$DRFiler" snapmirror status Write‐Host "Re‐Run the script and choose option 2 to monitor the SnapMirror status" } elseif ($Choice ‐eq 2) { c:\plink\plink.exe ‐i c:\plink\rsa_priv_plink_key.ppk root@"$DRFiler" snapmirror status } else { exit }

Пример скрипта восстановления данных с использованием NetApp SnapMirror # Description ‐ Script for Recovering VMs from SnapMirror Replication Relationship # Purpose – To failover storage to Secondary NetApp storage system and Recover all VMs automatically # Tools ‐ PowerShell, plink (SSH Communication) # # This sample code is provided AS IS, with no support or warranties of any kind, including but not limited to ## warranties of merchantability or fitness of any kind, expressed or implied. # Posted: July 2009 : NetApp $DRFiler = Read‐Host "Enter the hostname of the filer in the Recovery Site" $VolName = Read‐Host "Enter the Volume Name at the Recovery Site" $LUNName = Read‐Host "Enter the LUN Name at the Recovery Site" $VMVHD = Read‐Host "Enter the name of the VM VHD from which the VM needs to be recovered" $iqn = "iqn.1991‐05.com.microsoft:win2k8r2‐srv3" $LUNPath = $DRFiler + ":" + "/vol/" + $VolName + "/" + $LUNName function Create_VM ( $VM_Service, $VMName ) { $wmiClassString = "\\" + "LocalHost" + "\root\virtualization:Msvm_VirtualSystemGlobalSettingData" $wmiClass = [WMIClass]$wmiClassString $newVSGlobalSettingData = $wmiClass.CreateInstance() while ($newVSGlobalSettingData.psbase.Properties ‐eq $null) {} # Set the VM name $newVSGlobalSettingData.psbase.Properties.Item("ElementName").value = $VMName $status = $VM_Service.DefineVirtualSystem($newVSGlobalSettingData.psbase.GetText(1)) if ($status.ReturnValue ‐eq 0) { $NewVM_PATH = $status.DefinedSystem return $NewVM_PATH } } function Attach_VHD ( $VM_Service, $NewVM_PATH, $VHD ) { $ListOfControllers = get‐wmiobject ‐namespace root\virtualization Msvm_ResourceAllocationSettingData | where‐object {$_.ResourceSubType ‐like "*Emulated*IDE*"} foreach ($Controller in $ListOfControllers) { if ($Controller.Address ‐eq 0) { $IDEController0 = $Controller } }

$DiskDefault = get‐wmiobject ‐namespace root\virtualization Msvm_ResourceAllocationSettingData | where‐ object {($_.ResourceSubType ‐like "Microsoft Synthetic Disk Drive") –and ($_.InstanceID ‐like '*Default*')} $DiskDrive = $DiskDefault.psbase.Clone() $DiskDrive.Parent = $IDEController0.__PATH $DiskDrive.Address = 0 $Status = $VM_Service.AddVirtualSystemResources($NewVM_PATH, $DiskDrive.psbase.GetText(1)) if ($Status.ReturnValue –eq 0) { $NewDiskDrive_PATH = $Status.NewResources } $VHDDefault = get‐wmiobject ‐namespace root\virtualization Msvm_ResourceAllocationSettingData | where‐ object {($_.ResourceSubType ‐like "Microsoft Virtual Hard Disk") –and ($_.InstanceID ‐like '*Default*' )} $NewDiskDrive = [WMI]"$NewDiskDrive_PATH" $VHDisk = $VHDDefault.psbase.Clone() $VHDisk.Parent = $NewDiskDrive.__PATH $VHFile = $VHD $VHDisk.Connection = $VHFile $VM_Service.AddVirtualSystemResources($NewVM_PATH, $VHDisk.psbase.GetText(1)) } Write‐Host " Select: 1 ‐ Perform Recovery on the same Hyper‐V Host 2 ‐ Perform Recovery to a different Hyper‐V Host * ‐ Exit the script" $Choice = Read‐Host "Enter the selection" $fqdn = hostname if ($Choice ‐eq 1) { Write‐Host "Performing recovery on the same Hyper‐V Host can imply that it is not required to recreate the VM Configuration, provided the recovered LUN is attached with the same Drive Letter as it was before the Disaster" sdcli sysconfig list | select‐string ‐pattern "Available drive letters" ‐CaseSensitive Write‐Host "Ensure that the Drive Letter is in the available list in case the prior configuration is retained" Write‐Host "" $Decide = Read‐Host "Would you like to specify the same Drive as per configuration prior to disaster (y / n)" Write‐Host "" if ($Decide ‐eq 'y') { $DriveLetter = Read‐Host "Enter the Drive Letter as per configuration prior to disaster" sdcli disk connect ‐p $LUNPath ‐d $DriveLetter ‐I $fqdn $iqn ‐dtype dedicated sleep ‐Seconds 4 Write‐Host "Now start the VM and check its status" } elseif ($Decide ‐eq 'n') { $DriveLetter = Read‐Host "Select an available Drive Letter from the above list" sdcli disk connect ‐p $LUNPath ‐d $DriveLetter ‐I $fqdn $iqn ‐dtype dedicated $VMName = $DRFiler + "‐" + $VMVHD.trimend('.vhd') $VHD = $DriveLetter + ":\" + $VMVHD $VM_Service = Get‐WmiObject –namespace root\virtualization Msvm_VirtualSystemManagementService $NewVM_PATH = Create_VM $VM_Service $VMName Attach_VHD $VM_Service $NewVM_PATH $VHD } else { Write‐Host "Invalid Input. Rerun the script and Enter Y or N"

exit } } elseif ($Choice ‐eq 2) { $DriveLetter = Read‐Host "Select an available Drive Letter from the above list" sdcli disk connect ‐p $LUNPath ‐d $DriveLetter ‐I $fqdn $iqn ‐dtype dedicated $VMName $VMVHD $VM_Service = Get‐WmiObject –namespace root\virtualization Msvm_VirtualSystemManagementService $NewVM_PATH = Create_VM $VM_Service $VMName Attach_VHD $VM_Service $NewVM_PATH $VHD } else { exit }

Приложение E: Благодарности и ссылки

Благодарности Авторы благодарят следующих людей за их вклад и помощь: Chris Lionetti, Reference Architect, NetApp Ranga Sankar, Technical Alliance Manager, NetApp Richard Preston, Technical Alliance Manager, NetApp Vaughn Stewart, Technical Marketing Engineer, NetApp Larry Touchette, Technical Marketing Engineer, NetApp Mike Slisinger, Technical Marketing Engineer, NetApp

Ссылки Virtualization with Hyper‐V: Supported Guest Operating Systems http://www.microsoft.com/windowsserver2008/en/us/hyperv‐supported‐guest‐os.aspx Install the Hyper‐V Role on a Full Installation of Windows Server 2008 http://technet.microsoft.com/en‐us/library/cc794929(WS.10).aspx NetApp Implementation Guide for Microsoft Virtualization (TR‐3733) http://www.netapp.com/us/library/technical‐reports/tr‐3733.html Install the Hyper‐V Role on a Server Core Installation of Windows Server 2008 http://technet.microsoft.com/en‐us/library/cc794852(WS.10).aspx Microsoft Hyper‐V Server 2008 Configuration Guide http://www.microsoft.com/Downloads/details.aspx?familyid=E1E111C9‐FA69‐4B4D‐8963‐1DD87804C04F&displaylang=en VMM System Requirements http://technet.microsoft.com/en‐us/library/cc764328.aspx Configuring a SAN Environment for VMM http://technet.microsoft.com/en‐us/library/cc764269.aspx New Installation of VMM http://technet.microsoft.com/en‐us/library/cc793149.aspx Configuring Virtual Networks http://technet.microsoft.com/en‐us/library/cc816585(WS.10).aspx Hyper‐V: Using Hyper‐V and Failover Clustering http://technet.microsoft.com/en‐us/library/cc732181(WS.10).aspx Hyper‐V: Using Live Migration with Cluster Shared Volumes in Windows Server 2008 R2 http://technet.microsoft.com/en‐us/library/dd446679(WS.10).aspx Hyper‐V Live Migration Overview and Architecture http://www.microsoft.com/downloads/details.aspx?FamilyID=FDD083C6‐3FC7‐470B‐8569‐7E6A19FB0FDF&displaylang=en Virtual Network Manager http://technet.microsoft.com/en‐us/library/cc754263.aspx New in Hyper‐V Windows Server 2008 R2 Part 1: Dedicated Networks http://blogs.technet.com/jhoward/archive/2009/05/04/new‐in‐hyper‐v‐windows‐server‐2008‐r2‐part‐1‐dedicated‐networks.aspx NetApp NOW™ http://now.netapp.com/ NetApp Interoperability Matrix https://now.netapp.com/matrix/mtx/login.do High‐Availability System Configuration www.netapp.com/us/products/platform‐os/active‐active.html NetApp TR‐3450: Active‐Active Controller Overview and Best Practices Guidelines www.netapp.com/us/library/technical‐reports/tr‐3450.html NetApp TR‐3437: Storage Best Practices and Resiliency Guide www.netapp.com/us/library/technical‐reports/tr‐3437.html Remote LAN Management (RLM)





http://www.microsoft.com/Downloads/details.aspx?familyid=E1E111C9-FA69-4B4D-8963-1DD87804C04F&displaylang=en

http://www.microsoft.com/Downloads/details.aspx?familyid=E1E111C9-FA69-4B4D-8963-1DD87804C04F&displaylang=en














http://www.netapp.com/us/products/platform-os/active-active.html



http://now.netapp.com/NOW/download/tools/rlm_fw/info.shtml Windows Host Utilities 5.0 Setup Guide http://now.netapp.com/NOW/knowledge/docs/san/#windows Data ONTAP DSM for Windows MPIO Installation and Administration Guide http://now.netapp.com/NOW/knowledge/docs/san/#mpio NetApp SnapDrive for Windows http://www.netapp.com/us/products/management‐software/snapdrive‐windows.html NetApp SnapManager family www.netapp.com/us/products/management‐software/ Performance Tuning Guidelines for Windows Server 2008 R2 http://www.microsoft.com/whdc/system/sysperf/Perf_tun_srv‐R2.mspx What’s new in Windows Server 2008 R2 Hyper‐V Performance and Scale? http://blogs.msdn.com/tvoellm/archive/2009/08/05/what‐s‐new‐in‐windows‐server‐2008‐r2‐hyper‐v‐performance‐and‐scale.aspx Microsoft Virtual Hard Disk (VHD) FAQ http://technet.microsoft.com/en‐us/bb738381.aspx Virtual Hard Disk (VHD) Image Format Specification http://technet.microsoft.com/en‐us/virtualserver/bb676673.aspx Performance Tuning Guidelines for Windows Server 2008 R2 http://www.microsoft.com/whdc/system/sysperf/Perf_tun_srv.mspx Hyper‐V and VHD Performance: Dynamic vs. Fixed http://blogs.technet.com/winserverperformance/archive/2008/09/19/hyper‐v‐and‐vhd‐performance‐dynamic‐vs‐fixed.aspx Data ONTAP Block Access Management Guide for iSCSI or FC http://now.netapp.com/NOW/knowledge/docs/ontap/rel731_vs/pdfs/ontap/bsag.pdf Data ONTAP Commands Manual Page Reference Часть 1: http://now.netapp.com/NOW/knowledge/docs/ontap/rel731/pdfs/ontap/cmdref1.pdf Часть 2: http://now.netapp.com/NOW/knowledge/docs/ontap/rel731/pdfs/ontap/cmdref2.pdf Planning for Disks and Storage http://technet.microsoft.com/en‐us/library/dd183729(WS.10).aspx Configuring Disks and Storage http://technet.microsoft.com/en‐us/library/ee344823(WS.10).aspx TR‐3505: NetApp Deduplication for FAS: Deployment and Implementation Guide (есть русский перевод) www.netapp.com/us/library/technical‐reports/tr‐3505.html Microsoft KB 302577 http://support.microsoft.com/kb/302577 Microsoft KB 958184 http://support.microsoft.com/kb/958184 SnapMirror Sync and SnapMirror Semi‐Sync Overview and Design Considerations http://www.netapp.com/us/library/technical‐reports/tr‐3326.html SnapMirror Async Overview and Best Practices Guide http://www.netapp.com/us/library/technical‐reports/tr‐3446.html Configuring Alarms http://now.netapp.com/NOW/knowledge/docs/DFM_win/rel36r1/html/software/opsmgr/monitor5.htm Управление емкостью aggregate http://now.netapp.com/NOW/knowledge/docs/DFM_win/rel36r1/html/software/opsmgr/filesys4.htm Operations Manager http://www.netapp.com/us/products/management‐software/operations‐manager.html Описание утилиты diskpart http://support.microsoft.com/default.aspx?scid=kb;en‐us;300415

http://now.netapp.com/NOW/download/tools/rlm_fw/info.shtml

http://now.netapp.com/NOW/knowledge/docs/san/#windows

http://now.netapp.com/NOW/knowledge/docs/san/#mpio

http://www.netapp.com/us/products/management-software/snapdrive-windows.html

http://www.netapp.com/us/products/management-software/






http://www.microsoft.com/whdc/system/sysperf/Perf_tun_srv.mspx







http://technet.microsoft.com/en-us/library/ee344823(WS.10).aspx








http://now.netapp.com/NOW/knowledge/docs/DFM_win/rel36r1/html/software/opsmgr/filesys4.htm

http://www.netapp.com/us/products/management-software/operations-manager.html


GNU ext2resize http://ext2resize.sourceforge.net/

Приложение F: Версии документа версия Изменения 1.0 Исходная версия 2.0 Обновлены Hyper‐V Storage Options, удалены дублирующиеся тексты и добавлены

ссылки на NetApp TR‐3733. 3.0 Кроме небольших изменений оформления, следующие разделы были добавлены или

обновлены: Тома NetApp FlexClone, NetApp Snapshot, процессы создания виртуальных машин. Выравнивание файловых систем и типов LUN. Процессы резервного копирования и восстановления с помощью снэпшотов NetApp, включая скрипты, приведенные в приложениях, для резервного копирования VM с помощью SnapDrive и VSS/Diskshadow. Процессы катастрофоустойчивости и высокой доступности с использованием NetApp SnapMirror, включая скрипты в приложениях, для выполнения репликации и восстановления инфраструктуры с использованием NetApp SnapMirror.


Наилучшие методы использования систем ... · 2017-01-16 ·...

Documents

Transcript of Наилучшие методы использования систем ... · 2017-01-16 ·...