Добавить iscsi диск на сервер windows hyper-v или core server

Connecting Hyper-V hosts to iSCSI targets in Windows

In order to provide high availability for the virtual machines (VM) you run on Hyper-V, you should create failover clusters for your host servers. Two cluster types are available for Hyper-V hosts: single-site clusters and multi-site clusters. Single-site clusters are based on shared storage in the form of either Fibre Channel storage area networks (SANs) or iSCSI targets.

Despite its name, the multi-site cluster does not need to span more than one site. Instead, it can support the creation of clustered servers using direct-attached storage (DAS) along with a replication engine to keep the data between cluster nodes in sync.

Still, the most common host cluster type is the single-site cluster and more and more organizations are relying on iSCSI targets to build it.

This is because working with iSCSI storage allows you to rely on standard network adapters to connect remote storage to a machine. All storage traffic moves through the network adapters.

Storage is provisioned and offered for consumption to endpoint machines by an iSCSI target—a storage container running an iSCSI interpreter so that it can receive and understand iSCSI commands.

An iSCSI target can be A) the actual device offering and managing the storage, or B) a bridge device that converts IP traffic to Fibre Channel and then relies on Fibre Channel Host Bus Adapters (HBAs) to communicate with the storage container. iSCSI target storage devices can be SANs that manage storage at the hardware level or software engines that run on server platforms to expose storage resources as iSCSI targets.

You can use several products to evaluate iSCSI targets as you prepare to work with highly available VMs. Microsoft offers two products that support iSCSI targets: Windows Storage Server 2003 R2 and Windows Unified Data Storage Server 2003. Both can be obtained as evaluations for use as iSCSI targets. A registration process is required for each evaluation product you select.

You can also obtain an evaluation version of StarWind Server from Rocket Division Software to create iSCSI targets for testing virtual machine clustering.

The retail version of StarWind Server lets you create iSCSI targets from either physical or virtual machines running Windows Server software and including multiple disks.

This greatly simplifies cluster constructions in small environments because it doesn't require expensive storage hardware to support failover clustering.

iSCSI clients run iSCSI Initiator software to initiate requests and receive responses from the iSCSI target (see Figure 1). If the iSCSI target is running Windows Server 2003, you must download and install the iSCSI Initiator software from Microsoft.

If the client is running Windows Server 2008, the iSCSI Initiator software is included with the operating system. You can learn more from the iSCSI Initiator User Guide.

Because iSCSI storage traffic is transported over network adapters, you should try to install the fastest possible adapters in your host servers and reserve them for iSCSI traffic in VMs.

Figure 1

Relying on iSCSI targets for host servers is becoming more and more popular because of its simplicity and easy fault tolerance. For more information on this and other protection mechanisms for Microsoft Hyper-V virtual machines, look up MCITP Self-Paced Training Kit (Exam 70-652): Configuring Windows Server Virtualization with Hyper-V.

ABOUT THE AUTHOR
Danielle Ruest and Nelson Ruest are IT professionals specializing in systems administration, migration planning, software management and architecture design.

Danielle is Microsoft MVP in Virtualization and Nelson is Microsoft MVP in Windows Server.

They are authors of multiple books, including the free Definitive Guide to Vista Migration for Realtime Publishers and Windows Server 2008: The Complete Reference for McGraw-Hill Osborne. For more tips, write to them at [email protected].

Источник: https://searchwindowsserver.techtarget.com/tip/Connecting-Hyper-V-hosts-to-iSCSI-targets-in-Windows

Создание и конфигурирование HA кластера Hyper-V 2012 R2

В данном случае будем строить кластер состоящий из двух нод (NODE1 и NODE2) 1.

Предварительные условия: 1)В качестве “железа” можно использовать любые “вменяемые” сервера или даже “системники”, главное чтобы памяти хватало под задачи которые будут возлагаться на виртуальные машины 2) Рекомендуется установить на каждую из нод кластера по 2 сетевые карты (условие не обязательное).

Первый сетевой интерфейс, для сети хранения данных (установить ей самый высокий приоритет(Network and Sharing Center->Change Adapter Settings, нажать Alt, в появившемся меню выбрать Advanced -> Advanced Settings и переместить сетевойинтерфейс для сети хранения данных на самый верх)), шлюз по умолчанию не указываем
Второй сетевой интерфейс для управления, для связи хостов друг с другом, и для взаимодействия с диском свидетелем (quorum disk).

3) Хосты должны быть введены в домен, иметь прямые и обратные записи в DNS, т.е. резолвиться по имени и по айпишнику 2. Добавим роль Failover-Clustering на каждом хосте:

используем PowerShell console запущенную из под администратора:

Add-WindowsFeature Failover-Clustering –IncludeManagementTools

используем Server Manager

3. Eсли хотим удаленно управлять нашим создаваемым кластером, то на какой нить внешней машине c os win 8.1 или 2012 r2 , используя PowerShell console запущенную из под администратора:

Add-WindowsFeature RSAT-Clustering –IncludeAllSubFeature

4. Теперь, когда служба Failover Clustering включена на каждом сервере, откроем Failover Cluster Manager на любом из хостов, и первое, что сделаем – это запустим “Validate Configuration”, чтобы мы могли идентифицировать любые потенциальные проблемы прежде чем перейти непосредственно к созданию, а в последствии и к конфигурированию нашего кластера. Нажмите на “Validate Configuration”попадаем в визард и отвечаем на логичные вопросы, нужно выбрать членов нашего кластера, все остальные шаги оставляем по дефолту, после того как мастер соберет все сведения о готовности инфраструктуры к разворачиванию сервиса, он выдаст заключение, которое можно развернуто посмотреть, нажав на View Report… Если есть какие-то ошибки и ворнинги исправляем их, благо в репорте помимо описания самих ошибок и предупреждений , есть рекомендации по их исправлению, если все OK, то… 5. Переходим непосредственно к созданию кластера:

используем PowerShell console запущенную из под администратора:

New-Cluster -Name -Node NODE1,NODE2 -NoStorage

(вновь созданный кластер получит виртуальный IP адрес по DHCP, который потом можно будет поменять в Failover Cluster Manager (Консоль Failover Cluster, кликаете в левой панели на имя кластера, в средней отобразится поле Cluster Core Resources, раскрываете, правой кнопкой IP address – свойства)), так же необходимо проверить создалась ли A запись в прямой и обратной зоне DNS, если нет, создадим ее руками!

используем Failover Cluster Manager, нажмем Create Cluster…, как-нить интуитивно понятно обзовём его и выдадим ему IP адрес. На экране “Сonfirmation” мы видим имя и IP-адрес, который мы выбрали для нашего кластера. Также там есть опция ”Add all eligible storage to the cluster” типа добавить все подходящие для кластера диски,по умолчанию она задействована, вот надо убрать галочку, потому как мы сами решим какие диски добавлять , займемся этим позже

6. Создадим папку или диск для “quorum disk” (для диска свидетеля подойдет лун, размером 1G) и ресурс (папку или диск) для хранения виртуальных машин, который в последствии используем для Cluster Shared Volume (CSV)

как известно, начиная с hyper-v 2012 в качестве общего хранилища и диска свидетеля можно использовать шары SMB3, на отдельно стоящей доменной машине под управлением win 2012 или win 2012 r2 с “приличным” объемом свободного дискового пространства, создадим 2 папки и назовем их например: HVCVMWitness – это для кворум диска, расшарим ее на запись для всех , и дадим полный доступ на уровне секурити для кластера HVCVMStorage – это для хранения виртуальных машин, расшарим ее на запись для всех, и дадим полный доступ на уровне секурити для членов кластера!

!!! здесь хочу заметить, что решение с файловой шарой для хранения VM подходит исключительно в тестовом режиме, да и то весьма и весьма сомнительно, хотя как quorum disk вполне себя оправдывает!!!

Лучше использовать внешнее файловое хранилище, например SYNOLOGY DS, или софтверное решение FreeNAS или OpenFiler и подключить выделенный LUN по iscsi:

1) Shutdown NODE2 2) На NODE1 запустим iSCSI initiator из Administrative tools или из командной строк: iscsicpl

в выпавшем информационном окне нажмем Yes для того чтобы автоматически запускать службу iSCSI initiator
выберем Discovery
нажмем Discover Portal
введем IP Address нашего сетевого дискового хранилища, где опубликован LUN и нажмем OK
выберем Targets
выберем по очереди каждый target и нажмем Connect

3) Откроем Disk Management tool и сконфигурим наши только что добавленные диски, т.е. сделаем каждый из них online, инициализируем их, присвоим интуитивно понятные имена и буквы (меньший диск назовем quorum и дадим букву Q, большому – VM и букву V )ну и отформатируем под NTFS 4) Shutdown NODE1 5) Старт NODE2 Повторим для ноды шаги 2 и 3 (ну только форматировать не надо) 6) Старт NODE1 7. Добавим наши примапленный iscsi диск из оснастки Failover Cluster Manager8. После того как кластер создался, у нас будет предупреждение, что “хорошо не обнаружен диск свидетель и хорошо бы его все таки сконфигурить”…… ну так в общем то займемся этим, используем для этой цели созданный на шаге 6 диск или smb шару:

На следующем шаге, если будем использовать smb шару, то

если iscsi диск, то

ну и некст некст и финиш!

9. Теперь создадим Cluster Shared Volume (CSV), для этого в оснастке Failover Cluster Manager

Storage->Disks выделим наш “большой” доступный диск и в правой панели нажмем

“Add to Cluster Shared…”

10. Теперь прямо из Failover Cluster Manager можно создавать виртуальные машины указывая в качестве хранилища файловую smb3 шару или CSV, либо можно добавить в наш кластер уже созданные ранее VM, правда чтобы они стали высоко доступными их хранилище необходимо перенести в Cluster Shared Volume!

11. Добавим виртуальные машины в наш кластер

используем PowerShell console запущенную из под администратора:

Get-VM | Add-VMToCluster –Cluster

используем Failover Cluster Manager, нажмем нажмемConfigure Role… на шаге Select Role выделим Virtual Machine и нажмем next

отметим галками “нужные” виртуалки

ну и некст некст и финиш!

12. Перенесем хранилище добавленных виртуальных машин из локального в CSV

на любой из нод кластера зайдем в наш шаред волум, который находится в C:ClusteredStorageVolumeX и руками создадим папку по имени виртуальной машины ну например vmClusterTest (в эту папку мы перенесем хранилище из локального)

перед переносом нужно убедиться что на виртуальной машине нет примапленных исошников иначе “фокус не удастся”
в Failover Cluster Manager выделим виртуалку и в правой панели нажмем Move->Virtual Machine Storage

в открывшемся окне методом драг энд дроп перетянем нашу виртуалку из верхнего окна в правое нижнее

нажмем старт, машина перенесется и станет HA!!! После этого управление VM производится из консоли Failover Cluster Manager Ну вот как то так! Удачи и помните:”Все в Ваших руках, если есть “Руки””

Источник: http://nyakovleff.blogspot.com/2013/12/ha-hyper-v-2012-r2.html

Подключение Windows 7 к iSCSI SAN

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

Настройка iSCSI в Windows 7

Для начала запустим iSCSI Initiator, который в Windows 7 установлен по умолчанию. Вы можете запустите его несколькими способами.

Первым вариантов является запуск через панель управления Windows 7:

В качестве альтернативы для продвинутых пользователей можно запустить программу, набрав её имя в строке поиска. Для этого наберем iscsicpl.exe и нажмем Enter

Не зависимо от способо запуска, результат один. Появится предупреждение о том, что служба iSCSI не запущена. Нажимаем Yes для запуска службы

В итоге мы попали в окно iSCSI Initiator Properties где мы будем настраивать подключение.

В этот момент мы готовы подключить iSCSI инициатор к iSCSI-таргет. В нашем случае роль iSCSI Target играет виртуальная машина с дистрибутивом OpenFiler, запущенная под управлением vSphere.

Введем имя нашего таргета – wb-iscsi-san.

В следующем скриншоте нам будет предложено к какому из обнаруженных объектов мы хотим присоединиться. Выберем WB-iSCSI-WINDOWS .

Нажмите Connect, после чего раздел iSCSI SAN будет добавлен в Windows и после этого нажмите DONE.

Теперь в статусе таргета указано – Connected.

В завершение перейдите в вкладку Volumes and Devices и нажмите Auto Configure.

После чего нажмите OK для закрытия свойств iSCSI инициатора.

Нам осталось сделать подключенный раздел доступным в Windows, для этого перейдем в Computer Management и нажмем на Disk Management.

Вы должны увидеть новый неинициализированный диск. Инициализируем его.

Нажмите OK для инициализации.

Как вы можете видеть, теперь диск находиться в состоянии Online, но пока ещё на нем не создан ни один раздел.

Нажмите на диске правой кнопкой и выберите New Simple Volume.

Я предполагаю что вы способны самостоятельно создать новый раздел в Windows 7, поэтому пропущу подробности.

В результате будет создан новый раздел, его статус Healthy (Primary Partition), он отформатирован в NTFS.

Напоследок зайдем в Мой компьютер и посмотрим на свежесозданный диск там.

Как вы видите, ничего сложного нет!

Источник: http://system-administrators.info/?p=4116

Настройка Hyper-V Server R2 Failover Cluster из командной строки (Часть I)

Готовясь к сертификации по Windows Server 2008, я решил более обстоятельно поработать с SCVMM 2008 R2 и Hyper-V R2. Среди прочих задач захотелось поднять двухузловой отказоустойчивый кластер.

Вот только его настройка из оболочки sconfig и оснасток MMC показалась мне довольно тривиальной, поэтому решил выполнить аналогичные операции, используя только лишь командную строку.

Схему организации кластера выбрал самую простую:Один контроллер домена (W2K8-DCS01), один сервер, выполняющий роль iSCSI Target (W2K8-STR01), два узла Hyper-V Server R2 (W2K8-HYP01 и W2K8-HYP02) с двумя сетевыми адаптерами: один – для доступа к узлам, работы с виртуальными машинами, а также подключения к iSCSI Target'ам, второй – для передачи heartbeat. Кворум предполагается размещать на одном LUN'е (Quorum), презентованном по iSCSI, раздел для хранения виртуальных машин – на втором (Storage).

Первоначальная настройка Перед тем, как начать собирать кластер, потребуется выполнить настройку сети на сервере Hyper-V. Закрываем неприглядное окно sconfig'а, на передний план выходит cmd. Сначала включим несколько дополнительных компонентов (службы кластера, PowerShell и Framework для него):

dism /online /enable-feature /featurename:FailoverCluster-Core dism /online /enable-feature /featurename:NetFx2-ServerCore

dism /online /enable-feature /featurename:MicrosoftWindowsPowerShell

Они понадобятся нам на более поздних этапах настройки. Кстати, получить список доступных (активных/неактивных) компонентов можно с помощью команды:

dism /online /get-features

С помощью netsh настроим сетевые подключения. Сначала узнаем имена, которые система назначила сетевым адаптерам:
netsh interface show interface

В моем случае адаптер “Local Area Network” подключен к общей сети, адаптер “Local Area Network 3” к частной (heartbeat). Исходя из первоначального плана, назначаем адреса, маски, DNS, Default Gateway:

netsh interface ipv4 set address “Local Area Connection” static 192.168.10.11 255.255.255.0 192.168.10.254 netsh interface ipv4 set dnsserver “Local Area Connection” static 192.168.10.1 primary

netsh interface ipv4 set address “Local Area Connection 3” static 10.0.0.1 255.255.255.252

Без RDP может быть скучно, поэтому включим и его:
Cscript.exe “C:WindowsSystem32Scregedit.wsf” /AR 0 И разрешим подсоединятся старым RDP клиентам:

Cscript.exe “C:WindowsSystem32Scregedit.wsf” /CS 0

Хотя, мне больше нравится удаленно управлять сервером с помощью WinRM. Перед присоединением сервера к домену, изменим его имя на что-то более благозвучное:

netdom renamecomputer %computername% /newname

Перезагрузим сервер:
shutdown -r -t 00 Добавим сервер в домен:

netdom join %computername% /domain: /userd: /passwordd:

и снова перезагрузим сервер.

Подключение дисков

Перед созданием кластера нам понадобится настроить iSCSI Initiator чтобы получить доступ к презентованным дискам. Сделать это можно в несколько щелчков мыши, запустив графическую настройку iscsicpl.exe.Однако, мы не ищем легких путей, поэтому будем настраивать все из командной строки. 🙂 По-умолчанию служба iSCSI Initiator выключена, поэтому для начала запустим ее:

net start msiscsi

А чтобы не повторять эту операцию каждый раз при загрузке сервера вручную настроим ее на автоматический старт:

sc config msiscsi start= auto

На очереди сама консольная утилита – iscsicli. С ее помощью и настроим iSCSI Initiator на узле. Подключимся к iSCSI Target серверу:
iscsicli qaddtargetportal
, где – имя или IP адрес iSCSI хранилища. Посмотрим на список доступных целей:

iscsicli listtargets

Подключимся к обоим целям:
iscsicli qlogintarget
, где – IQN целей, к которым требуется подключитьсяа также сделаем так, чтобы они автоматически подключались после перезагрузки сервера:
iscsicli persistentlogintarget t * * * * * * * * * * * * * * * 0
Разбиение дисков
Теперь потребуется создать отформатировать разделы на подключенных дисках. Сделать это можно с помощью консольной утилиты Diskpart. Запустим Diskpart и посмотрим на подключенные диски:

list disk

Выберем первый диск, создадим и отформатируем на нем раздел под кворум:
select disk 1 create partition primary

format fs=ntfs label=”Quorum” quick

аналогичные операции выполним для второго диска под хранилище виртуальных машин:

select disk 2 create partition primary

format fs=ntfs label=”Storage” quick

Заключение На этом первая часть завершена. В следующий раз я опишу процесс настройки самого кластера и подключения второго узла. До встречи!

Материалы

При подготовке статьи использовались следующие материалы:

Источник: http://blog.vmpress.org/2009/12/hyper-v-server-r2-failover-cluster-i.html

Установка и настройка Microsoft ISCSI Target 3.3

В этой статье поговорим о технологии, позволяющей программными средствами из обычного сервера Windows создать сетевую систему хранения наподобие SAN и позволяющей различным сетевым клиентам использовать дисковые ресурсы этого сервера по протоколу iSCSI.

Для реализации такой технологии Microsoft поддерживает специальный бесплатный компонент — Microsoft iSCSI Software Target 3.3 (последняя версия на момент написания статьи).

Даная технология может использоваться для построения недорогих кластерных систем с единым дисковым хранилищем, для использования в системах виртуализации (со всеми вкусностями, такими как Live Migration — LM и High Availability –HA) без необходимости покупать дорогие устройства Fiber Channel SAN или аппаратные iSCSI сервера.

Скачать Microsoft iSCSISoftware Target 3.3 можно с сайта Microsoft по ссылке http://www.microsoft.com/downloads/en/details.aspx?FamilyID=45105d7f-8c6c-4666-a305-c8189062a0d0

Системные требования Microsoft ISCSI Target

Данная версия iSCSI Software Target поддерживает установку на следующие операционные системы

Windows Server 2008 R2 Standard
Windows Server 2008 R2 Enterprise
Windows Server 2008 R2 Datacenter

И требует наличия процессора не менее 1GHz и не менее 2GB оперативной памяти.

Отметим, что не поддерживается установка на Windows 2008 Server Core и бесплатный Microsoft Hyper-V Server 2008 R2, они могут выступать только в качестве клиентов iSCSI Initiator .

Программный продукт iSCSI Target состоит из двух компонент: сервера (в терминологии ISCSI – Target) и клиента (initiator — инициатора)

В этой части статьи мы поговорим об установке и настройке серверной части программного iSCSI (iSCSI), во второй части о настройке клиента iSCSI (инициатора), который будет использовать дисковые ресурсы сервера.

Установка iSCSI Target 3.3

После того, как вы скачали пакет. Необходимо его распаковать, в результате у нас появятся 2 файла:

· iscsitarge_public.msi

· iscsitargetClient_public.msi

Для установки серверной части (Target) необходимо запустить файл iscsitarget_public.msi. Мастер установки крайне прост:

После нажатия кнопки Finish, считаем, что компонент установлен.

Утилиту управления iSCSI target можно открыть из стартового меню («Microsoft iSCSI Software Target»).

Следующие этапы настройки iSCSI target – заключаются в создании устройства виртуального диска (в терминах сетей хранения LUN), и создании Target –а, к которому будут подключаться клиенты для получения доступа к виртуальному диску.

Создаем хранилище

В консоли правой кнопкой мыши щелкаем по Devices и выбираем пункт ”Create Virtual Disk”.

Указываем местоположение и имя виртуального диска (они храниться в формате vhd).

Укажем размер диска.

В результате в списке виртуальных устройств появится новый виртуальный диск.

Создаем iSCSITarget

iSCSI target по сути – это ссылка для клиента, которая поможет найти ему устройство хранения (созданный ранее виртуальный диск). Щелкнем правой кнопкой по элементу iSCSI Targets и выберем ”Create iSCSI Targets”.

Укажем осмысленное имя:

Далее можно указать каким серверам можно подключаться к данному Target-у. Мы настроим этот параметр позднее. Нажмем Next и Finish.

Чтобы перейти к тонкой настройке выберете созданный вами Target и перейдите в его свойства.

Добавим ранее созданный виртуальный диск (вкладка Virtual Disks).

Выберите диск.

Далее на вкладке iSCSI Initiators укажем каким клиентам (их IQN) можно подключаться к нашему Target-у (мы ранее пропустили этот шаг).

Вот и все мы настроили iSCSI сервер (target) на Windows Server 2008 R2. В следующей статье поговорим о том, как настраиваются клиенты iSCSI (инициаторы).

Источник: http://winitpro.ru/index.php/2012/04/06/ustanovka-i-nastrojka-microsoft-iscsi-target-3-3/

about NetApp

Любопытную, и, честно говоря, даже неожиданную для меня тему исследовал блоггер NetApp Lobanov.

Следящие за темой уже знают, что в Hyper-V 3.0 Microsoft объявила, что будет поддерживать работу по NAS протоколу SMBv2.2.

Вы помните, что VMware уже с версии 3.0 активно рекомендует использовать NAS для подключения датасторов виртуальных машин по файловому протоколу NFS, и пользуется при этом большими преимуществами такого варианта перед “классическим” блочным FC и iSCSI, о чем я уже не раз писал в этом блоге.

Однако у Microsoft в ее Hyper-V не было такой возможность в штатном, поддерживаемом порядке, впрочем и пользователи, скорее всего, не особо это требовали. Отчасти это было связано с широко распространенным убеждением, что NAS-протоколы, и уж CIFS/SMB в особенности, вообще не пригодны для производительных применений.

�? если в отношении NFS в VMware эти заблуждения уже более-менее развеяны многочисленными результатами тестов, как NetApp и EMC, так и самой VMware, да и сотнями и тысячами практических реализаций разного масштаба, то в отношении CIFS по прежнему бытует стойкое убеждение в непригодности его ни для чего, кроме “домашних папок” и копирования файлов по сети.

Отчасти это действительно так. CIFS как протокол сетевой файловой системы, значительно сложнее устроен, чем NFS, обладает множеством хитрых возможностей, и, как следствие, заметно большей величиной “оверхеда”, накладных расходов. Кроме того, CIFS (или SMB 1.0) никогда и не ориентировался на такое применение.

Однако первым шагом в сторону переработки и устранения старых родовых болячек NetBIOS и LAN Manager, от которого ведет свою родословную CIFS, был сделан в SMB v2.

0, в котором Microsoft показала, что она знает о проблемах, и приняла решение их устранить. С тех пор CIFS/SMB развивается, не слишком шумно, но довольно существенно, а как видимый результат – появление поддержки новой версии, SMB v2.

2 в качестве поддерживаемого протокола доступа к датасторам в новой версии Hyper-V.

Однако, пока Windows 8, Hyper-V 3.0 и SMB 2.2 не вышли в релиз, что же может показать в плане производительности обычный SMB2.0, появившийся в Windows Server 2008, и поддерживаемый в Data ONTAP?

Looking ahead Hyper-V over SMB vs. iSCSI

Posted by lobanov on Sep 29, 2011 10:06:19 AM

В свете грядущих новостей о поддержке в Hyper-V работы по SMB через версию SMB 2.2, у нас скоро появится новая возможность работать с виртуальными машинами через IP сеть. До сих пор существовала только одна такая возможность, подключая LUN по iSCSI.

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

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

Для теста использовался один сервер в следующей конфигурации:

16 CPU (Dual Socket Quad Core with HyperThreading)
48 GB RAM
Один 1Gbs Ethernet NIC
Win2K8R2 SP1

Один контроллер NetApp FAS6030 под Data ONTAP 8.0.1 работает на один сетевой адаптер Ethernet 1Gbs, на контроллере создано два тома flexvol:

“HVoverSMB_CIFS” это CIFS share, смонтированная на хост Hyper-V как symbolic link.
“HVoverSMB_ISCSI” несет один LUN, подключенный к хосту Hyper-V по протоколу iSCSI.

Оба тома имеют размер 1TB в режиме Thin-Provisioned, и LUN на томе для iSCSI также сделан Thin-Provisioned.

Таким образом, со стороны хоста Hyper-V мы видим 2TB usable storage, в то время, как на стороне контроллера пространство на дисках почти не занято.

Мы решили не использовать 10G Ethernet, так как хотели замедлить, для наглядности, время загрузки, и максимально нагрузить сеть в процессе эксперимента.

Мы создали 20 VM на iSCSI LUN, и 20 VM на CIFS Share. Каждая виртуальная машина имела следующую конфигурацию:

1 CPU
2 GB RAM
Win2K8R2 SP1
40GB VHD

Оригинальный эталонный шаблон VM был создан с использованием нашей новой техники Thick/Thin VHD , о которой я рассказывал ранее, а последующие копии с этого шаблона созданы с использованием Sub-Lun cloning, и файлового SIS cloning vпри помощи cmdлетов Start-NaClone, и Copy-NaHostFile. �?тоговый результат 40 VM, и 1.6TB дисков виртуальных машин занимают менее 16GB на контроллере!

Затем мы подвергли получившуюся систему испытанием старым добрым Boot Storm – одновременной загрузкой 20 виртуальных машин каждого типа, и сбором данных о производительности как на хосте Hyper-V, так и на контроллере NetApp.

Мы собирали данные производительности Hyper-V при помощи Performance Monitor, обращая внимание, в первую очередь, на CPU и призводительность сетевого адаптера. Контроллер NetApp мониторился с помощью Get-NaSysStat PowerShell Script.

Оба инструмента был настроены на сбор данных каждые 5 секунд.

Результаты

Время загрузки

В обоих тестах загрузка до экрана Logon заняла менее 90 секунд для всех 20 виртуальных машин. Давайте посмотрим, что в это время происходило на хостах Hyper-V и контроллере NetApp.

Hyper-V-Host Performance

CPU load

Network Adapter: BytesReceived/sec

NetApp Array Performance

Net_Data_Sent

CPU_Busy

CIFS vs. iSCSI Ops/sec

Как вы видите, как со стороны хоста Hyper-V, так и со стороны контроллера NetApp, уровни загрузки CPU, а также производительность сети оказались сравнимыми! Важно отметить, что, в данном случае, мы еще даже не используем SMB2.

2, так как работает Server 2008 R2 SP1, а не Server.Next. Если же мы видим равную производительность для текущего поколения софта, запущенного на оборудовании четырехлетней давности, то что же мы получим, когда появится Server.

Next?

Но где же вообще разница между протоколами, спросите вы, а что там с latency?

Давайте посмотрим, вот картина на стороне NetApp:

Неожиданно, не правда-ли?

На первый взгляд, все неплохо, исключая взлет latency до 4ms в самый “разгар шторма”. Но посмотрите на параметр read latency для теста CIFS.

Почему он показывает меньшую latency на идентичной нагрузке? То что мы видим, это преимущества протокола SMB 2.

x; Windows использует собственный кэш NTFS для улучшения производительности на чтение, просто посылая на систему хранения меньше избыточных запросов чтения.

Величина эффективности использования пространства хранения на NetApp

�?спользуя thin-provisioning, single copy rapid provisioning, и дедупликацию, мы получили фантастически высокие результаты для обоих протоколов.

�?мя	Общий размер	�?спользовано	Доступно	Дедупликация	Aggregate
HVoverSMB_CIFS	1024.0 GB	1%	1015.9 GB	да	aggr0
HVoverSMB_ISCSI	1024.0 GB	1%	1013.7 GB	да	aggr0

Как вы видите, в обоих случаях величина эффективности использования хранилища сравнима и высока.

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

CIFS

За:

Одна сетевая папка CIFS на любое число хостов Hyper-V или кластеров Clusters.
Перемещение VM между хостами Hyper-V становится гораздо проще, так как все хосты имеют доступ к одним и тем же VHD.
Значительно более высокий уровень плотности VM на том.

Против:

Конфигурирование прав на CIFS share несколько сложновато, так как требует разобраться со специфическими разрешениями на Share и NTFS, которые требуются для Hyper-V.
В настоящий момент не поддерживается.

iSCSI

За:

Конфигурирование прав NTFS очевидно.
Поддерживается.
Равная производительность с FCP без необходимости сложного зонирования.

Против:

К LUN-ам не может быть совместного доступа от нескольких хостов и кластеров, без использования WSFC, и CSV.
Перемещение VHD на другой хост Hyper-V требует переконфигурирования системы хранения или копирования файлов VHD по сети.

Выводы

Результаты теста и их анализ показывают, что сегодня SMB2.0 и iSCSI сравнимы. Оба варианта подключения обеспечивают достаточную эффективность и позволяют работу виртуальных машин по IP-сети. Мы ожидаем, что большинство сложностей с правами и разрешениями будет устранена в Server.Next.

Факт неподдерживаемости SMB конечно делает iSCSI однозначным победителем, но, если быть честными, если SMB начнет поддерживаться… следует отдать должное прогрессу в работе SMB. В итоге, мы уже с нетерпением ждем выхода Server.Next, SMB2.2, и Hyper-V 3.

0 over SMB, это должно оказаться весьма неплохо!

Источник: http://blog.aboutnetapp.ru/archives/1058

Windows Server 2012: строим отказоустойчивый кластер с двумя узлами

22.04.2013 Майкл Оти

В Windows Server 2012 появилось так много новшеств, что за всеми уследить трудно. Часть наиболее важных строительных блоков новой ИТ-инфраструктуры связана с улучшениями в отказоустойчивой кластеризации.

Отказоустойчивая кластеризация зародилась как технология для защиты важнейших приложений, необходимых для производственной деятельности, таких как Microsoft SQL Server и Microsoft Exchange. Но впоследствии отказоустойчивая кластеризация превратилась в платформу высокой доступности для ряда служб и приложений Windows.

Отказоустойчивая кластеризация — часть фундамента Dynamic Datacenter и таких технологий, как динамическая миграция. Благодаря Server 2012 и усовершенствованиям нового протокола Server Message Block (SMB) 3.0 область действия отказоустойчивой кластеризации стала увеличиваться, обеспечивая непрерывно доступные файловые ресурсы с общим доступом.

Обзор функциональности отказоустойчивой кластеризации в Server 2012 приведен в опубликованной в этом же номере журнала статье «Новые возможности отказоустойчивой кластеризации Windows Server 2012».

Обязательные условия отказоустойчивой кластеризации

Для построения двухузлового отказоустойчивого кластера Server 2012 необходимы два компьютера, работающие с версиями Server 2012 Datacenter или Standard. Это могут быть физические компьютеры или виртуальные машины. Кластеры с виртуальными узлами можно построить с помощью Microsoft Hyper-V или VMware vSphere.

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

Компоненты, использованные в тестовом отказоустойчивом кластере Server 2012 представлены на рисунке.

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

Для отказоустойчивого кластера Server 2012 необходимо общее хранилище данных типа iSCSI, Serially Attached SCSI или Fibre Channel SAN. В нашем примере используется iSCSI SAN. Следует помнить о следующих особенностях хранилищ этого типа.

Каждый сервер должен располагать по крайней мере тремя сетевыми адаптерами: одним для подключения хранилища iSCSI, одним для связи с узлом кластера и одним для связи с внешней сетью. Если предполагается задействовать кластер для динамической миграции, то полезно иметь четвертый сетевой адаптер. Однако динамическую миграцию можно выполнить и через внешнее сетевое соединение — она просто будет выполняться медленнее. Если серверы используются для виртуализации на основе Hyper-V и консолидации серверов, то нужны дополнительные сетевые адаптеры для передачи сетевого трафика виртуальных машин.
В быстрых сетях работать всегда лучше, поэтому быстродействие канала связи iSCSI должно быть не менее 1 ГГц.
Цель iSCSI должна соответствовать спецификации iSCSI-3, в частности обеспечивать постоянное резервирование. Это обязательное требование динамической миграции. Оборудование почти всех поставщиков систем хранения данных соответствует стандарту iSCSI 3. Если нужно организовать кластер в лабораторной среде с небольшими затратами, обязательно убедитесь, что программное обеспечение цели iSCSI соответствует iSCSI 3 и требованиям постоянного резервирования. Старые версии Openfiler не поддерживают этот стандарт, в отличие от новой версии Openfiler с модулем Advanced iSCSI Target Plugin (http://www.openfiler.com/products/advanced-iscsi-plugin). Кроме того, бесплатная версия StarWind iSCSI SAN Free Edition компании StarWind Software (http://www.starwindsoftware.com/starwind-free) полностью совместима с Hyper-V и динамической миграцией. Некоторые версии Microsoft Windows Server также могут функционировать в качестве цели iSCSI, совместимой со стандартами iSCSI 3. В состав Server 2012 входит цель iSCSI. Windows Storage Server 2008 R2 поддерживает программное обеспечение цели iSCSI. Кроме того, можно загрузить программу Microsoft iSCSI Software Target 3.3 (http://www.microsoft.com/en-us/download/details.aspx?id=19867), которая работает с Windows Server 2008 R2.

Дополнительные сведения о настройке хранилища iSCSI для отказоустойчивого кластера приведены во врезке «Пример настройки хранилища iSCSI». Более подробно о требованиях к отказоустойчивой кластеризации рассказано в статье «Failover Clustering Hardware Requirements and Storage Options» (http://technet.microsoft.com/en-us/library/jj612869.aspx).

Добавление функций отказоустойчивой кластеризации

Первый шаг к созданию двухузлового отказоустойчивого кластера Server 2012 — добавление компонента отказоустойчивого кластера с использованием диспетчера сервера. Диспетчер сервера автоматически открывается при регистрации в Server 2012.

Чтобы добавить компонент отказоустойчивого кластера, выберите Local Server («Локальный сервер») и прокрутите список вниз до раздела ROLES AND FEATURES. Из раскрывающегося списка TASKS выберите Add Roles and Features, как показано на экране 1.

В результате будет запущен мастер добавления ролей и компонентов.

Экран 1. Запуск мастера добавления ролей и компонентов

Первой после запуска мастера откроется страница приветствия Before you begin. Нажмите кнопку Next для перехода к странице выбора типа установки, на которой задается вопрос, нужно ли установить компонент на локальном компьютере или в службе Remote Desktop. Для данного примера выберите вариант Role-based or feature-based installation и нажмите кнопку Next.

На странице Select destination server выберите сервер, на котором следует установить функции отказоустойчивого кластера. В моем случае это локальный сервер с именем WS2012-N1.

Выбрав локальный сервер, нажмите кнопку Next, чтобы перейти к странице Select server roles. В данном примере роль сервера не устанавливается, поэтому нажмите кнопку Next.

Или можно щелкнуть ссылку Features в левом меню.

На странице Select features прокрутите список компонентов до пункта Failover Clustering. Щелкните в поле перед Failover Clustering и увидите диалоговое окно со списком различных компонентов, которые будут установлены как части этого компонента.

Как показано на экране 2, по умолчанию мастер установит средства управления отказоустойчивыми кластерами и модуль отказоустойчивого кластера для Windows PowerShell. Нажмите кнопку Add Features, чтобы вернуться на страницу выбора компонентов.

Щелкните Next.

Экран 2. Добавление средства отказоустойчивого кластера и инструментов

На странице Confirm installation selections будет показана функция отказоустойчивого кластера наряду с инструментами управления и модулем PowerShell. С этой страницы можно вернуться и внести любые изменения.

При нажатии кнопки Install начнется собственно установка компонентов. После завершения установки работа мастера будет завершена и функция отказоустойчивого кластера появится в разделе ROLES AND FEATURES диспетчера сервера.

Этот процесс необходимо выполнить на обоих узлах.

Проверка отказоустойчивого кластера

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

Чтобы открыть диспетчер отказоустойчивого кластера, выберите параметр Failover Cluster Manager в меню Tools в диспетчере сервера. В области Management щелкните ссылку Validate Configuration, как показано на экране 3, чтобы запустить мастер проверки настроек.

Экран 3. Запуск мастера проверки конфигурации

Сначала выводится страница приветствия мастера. Нажмите кнопку Next, чтобы перейти к выбору серверов или странице Cluster. На этой странице введите имена узлов кластера, который необходимо проверить. Я указал WS2012-N1 и WS2012-N2. Нажмите кнопку Next, чтобы показать страницу Testing Options, на которой можно выбрать конкретные наборы тестов или запустить все тесты.

По крайней мере в первый раз я рекомендую запустить все тесты. Нажмите кнопку Next, чтобы перейти на страницу подтверждения, на которой показаны выполняемые тесты. Нажмите кнопку Next, чтобы начать процесс тестирования кластера. В ходе тестирования проверяется версия операционной системы, настройки сети и хранилища всех узлов кластера.

Сводка результатов отображается после завершения теста.

Если тесты проверки выполнены успешно, можно создать кластер. На экране 4 показан экран сводки для успешно проверенного кластера.

Если при проверке обнаружены ошибки, то отчет будет отмечен желтым треугольником (предупреждения) или красным значком “X” в случае серьезных ошибок.

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

Экран 4. Просмотр отчета о проверке

Создание отказоустойчивого кластера

На данном этапе можно создать кластер, начиная с любого узла кластера. Я организовал кластер, начав на первом узле (WS2012-N1).

Чтобы создать новый кластер, выберите ссылку Create Cluster на панели Management или панели Actions, как показано на экране 5.

Экран 5. Запуск мастера создания кластера

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

Экран 6. Выбор серверов для кластера

На странице Access Point for Administering the Cluster следует указать имя и IP-адрес кластера, которые должны быть уникальными в сети. На экране 7 видно, что имя моего кластера WS2012-CL01, а IP-адрес — 192.168.100.200. При использовании Server 2012 IP-адрес кластера может быть назначен через DHCP, но я предпочитаю для своих серверов статически назначаемый IP-адрес.

Экран 7. Настройка точки доступа кластера

После ввода имени и IP-адреса нажмите кнопку Next, чтобы увидеть страницу подтверждения (экран 8). На этой странице можно проверить настройки, сделанные при создании кластера. При необходимости можно вернуться и внести изменения.

Экран 8. Подтверждение параметров, выбранных при создании кластера

После нажатия кнопки Next на странице подтверждения формируется кластер на всех выбранных узлах. На странице хода выполнения показаны шаги мастера в процессе создания нового кластера. По завершении мастер покажет страницу сводки с настройками нового кластера.

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

Чтобы проверить, какой диск используется для кворума, откройте диспетчер отказоустойчивого кластера и разверните кластер. Затем откройте узел Storage и щелкните узел Disks. Диски, доступные в кластере, будут показаны на панели Disks.

Диск, выбранный мастером для кворума кластера, будет указан в разделе Disk Witness in Quorum.

В данном примере для кворума был использован Cluster Disk 4. Его размер 520 Мбайт, чуть больше минимального значения для кворума 512 Мбайт.

Если нужно использовать другой диск для кворума кластера, можно изменить настройки кластера, щелкнув правой кнопкой мыши имя кластера в диспетчере отказоустойчивого кластера, выбрав пункт More Actions и Configure Cluster Quorum Settings.

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

Настройка общих томов кластера и роли виртуальных машин

Оба узла в моем кластере имеют роль Hyper-V, так как кластер предназначен для виртуальных машин с высокой доступностью, обеспечивающих динамическую миграцию. Чтобы упростить динамическую миграцию, далее требуется настроить общие тома кластера Cluster Shared Volumes (CSV).

В отличие от Server 2008 R2, в Server 2012 общие тома кластера включены по умолчанию. Однако все же требуется указать, какое хранилище следует использовать для общих томов кластера. Чтобы включить CSV на доступном диске, разверните узел Storage и выберите узел Disks.

Затем выберите диск кластера, который нужно использовать как CSV, и щелкните ссылку Add to Cluster Shared Volumes на панели Actions диспетчера отказоустойчивого кластера (экран 9).

Поле Assigned To этого диска кластера изменится с Available Storage на Cluster Shared Volume (общий том кластера), как показано на экране 9.

Экран 9. Добавление CSV

В это время диспетчер отказоустойчивого кластера настраивает хранилище диска кластера для CSV, в частности добавляет точку подключения в системном диске. В данном примере общие тома кластера включаются как на Cluster Disk 1, так и на Cluster Disk 3 с добавлением следующих точек подключения:

* C:ClusterStorageVolume1
* C:ClusterStorageVolume2

На данном этапе построен двухузловой кластер Server 2012 и включены общие тома кластера. Затем можно установить кластеризованные приложения или добавить в кластер роли. В данном случае кластер создан для виртуализации, поэтому добавляем роль виртуальной машины в кластер.

Чтобы добавить новую роль, выберите имя кластера на панели навигации диспетчера отказоустойчивого кластера и щелкните ссылку Configure Roles на панели Actions, чтобы запустить мастер высокой готовности.

Нажмите кнопку Next на странице приветствия, чтобы перейти на страницу выбора роли. Прокрутите список ролей, пока не увидите роль виртуальной машины, как показано на экране 10.

Выберите роль и нажмите кнопку Next.

Экран 10. Добавление роли виртуальной машины

На странице выбора виртуальной машины будут перечислены все VM на всех узлах кластера, как показано на экране 11. Прокрутите список и выберите виртуальные машины, которым необходимо обеспечить высокую готовность. Нажмите кнопку Next. Подтвердив свой выбор, нажмите Next, чтобы добавить роли виртуальной машины в диспетчер отказоустойчивого кластера.

Экран 11. Выбор виртуальных машин, которым необходимо обеспечить высокую надежность

Для отказоустойчивого кластера Windows Server 2012 требуется общее хранилище, которое может быть типа iSCSI, Serially Attached SCSI или Fibre Channel SAN. В данном отказоустойчивом кластере используется Channel SAN.

Сначала в сети iSCSI SAN были созданы три логических устройства LUN. Один LUN был создан для диска кворума кластера (520 Мбайт). Другой LUN предназначен для 10 виртуальных машин и имеет размер 375 Гбайт. Третий LUN выделен для небольшой тестовой виртуальной машины. Все три LUN представлены в формате NTFS.

После того, как были созданы LUN, была выполнена настройка iSCSI Initiator на обоих узлах Server 2012. Чтобы добавить цели iSCSI, был выбран iSCSI Initiator в меню Tools в диспетчере сервера. На вкладке Discovery я нажал кнопку Discover Portal. В результате появилось диалоговое окно Discover Portal, куда были введены IP-адрес (192.168.0.1) и порт iSCSI (3260) сети SAN.

Затем я перешел на вкладку Targets и нажал кнопку Connect. В диалоговом окне Connect To Target («Подключение к целевому серверу») я ввел целевое имя iSCSI SAN. Оно было получено из свойств SAN. Имя зависит от поставщика SAN, имени домена и имен созданных LUN. Помимо целевого имени я установил режим Add this connection to the list of Favorite Targets.

По завершении настройки iSCSI эти LUN появились на вкладке Targets iSCSI Initiator. Чтобы автоматически подключать LUN при запуске Server 2012, я убедился, что они перечислены на вкладке Favorite Targets, как показано на экране A.

Экран A. Настройка iSCSI Initiator

Наконец, были назначены буквенные обозначения устройствам LUN с помощью оснастки Disk Management консоли управления Microsoft (MMC). Я выбрал Q для диска кворума и W для диска, используемого для виртуальных машин и общих томов кластера (CSV).

При назначении буквенных обозначений необходимо сначала назначить их на одном узле. Затем нужно перевести диски в автономный режим и сделать аналогичные назначения на втором узле. Результаты назначения букв дискам для одного узла приведены на экране B.

При создании кластера диски будут показаны как доступное хранилище.

Экран B. Буквенные обозначения, назначенные дискам iSCSI узла

Купить номер с этой статьей в PDF

Источник: https://www.osp.ru/winitpro/2013/05/13035365