Глава 4. Настройки хранилища

Данный раздел вкратце рассматривает самый большой сдвиг в хранилищах, введённый в Windows Server 2012. Хотя она напрямую и не является темой Hyper-V, я рассматриваю её, так как она скорее всего окажет воздействие на тот способ, которым проектируются ваши среды Hyper-V, в особенности в небольших организациях и офисах подразделений.

В своём введении я рассмотрел SAN с подключением через Fibre Channel и iSCSI, которые исторически являлись предпочтительным выбором для хранения в организации, так как они предоставляют множество преимуществ:

Применение высокоэффективного централизованного хранилища всё ещё великолепный вариант для многих организаций и вариантов применения. Однако и другая модель применяется во многих организациях и поставщиках служб, в том числе и Microsoft Azure: решения JBOD (just a bunch of disks, простой массив независимых дисков), которые являются либо локальными для сервера, либо выступают в виде какой- то внешней полки, подключаемой ко множеству хостов. Это может предоставлять высокую эффективность в отношении стоимости, так как подсистемы хранения основываются на обычных дисках, которые намного экономичнее решений SAN. Важно однако строить надёжные решения с резервным копированием по той причине, что локальные хранилища содержат критические рабочие нагрузки (например, ваши виртуальные машины).

Windows Server издревле имел возможность построения отказоустойчивого хранилища с помощью технологии избыточных массивов независимых дисков (RAID, redundant array of independent disks) в одной из двух моделей: RAID-1, которая зеркалирует все данные с одного диска на другой и RAID-5, которая применяет чередование при помощи вычисляемых сумм (parity). Однако, для таких реализаций RAID имеются некоторые вызовы:

Windows Server 2012 ввёл в практику Пространства хранения (Storage Spaces), как некий совершенно новый способ представления и использования подключаемых напрямую (direct- attached) хранилищ. При использовании Пространств хранения все предоставляющие подлежащее хранилище данных физические диски полностью абстрагируются из общего процесса запроса новых томов, теперь именуемых Пространствами (spaces) и все необходимые для восстановления избыточности действия в случае отказа какого- то диска выполняются автоматически данной технологией Пространств хранения по мере того как имеются доступными достаточные физические диски. Пространства хранения предоставляют программно определяемое решение хранения, которое при использовании локального хранилища снабжает решениями хранения с высокими доступностью и масштабируемостью.

Я собираюсь пройтись по Пространствам хранения, сосредоточившись на их воплощении в Windows Server 2012, том как они изменились в Windows Server 2012 R2 и затем какими они стали в Windows Server 2016. Будет полезным изучить все возможности в каждой версии Windows Server и посмотреть как развивались Пространства хранения, чтобы это помогла лучшему их пониманию.

Самый первый шаг состоит в создании пула хранения, который состоит в выборе одного или более физических дисков, которые затем собираются воедино в пул и могут применяться в технологии Пространств хранения. Поддерживаемыми типами в пуле хранения являются диски с USB-, SATA- и SAS- типами подключения. Эти диски всего лишь являются стандартными дисками, JBOD, такими как HDD, SSD и даже NVMe для наилучшей производительности. Без какой бы то ни было аппаратной поддержки высокой доступности, такой как RAID за сценой, Пространства хранения заботятся о восстановлении после сбоев. Наличие применимости устройств с USB- подключениями великолепно для настольных решений, в то время как серверы сосредотачиваются на подключаемых через SAS- или SATA- устройствах. Кроме того, осуществляется полная поддержка совместно используемых SAS, что означает, что при подключении многочисленных хостов в некий кластер можно применять дисковые полки, а создаваемые в них Пространства хранения с совместно используемыми устройствами SAS доступны всем узлам в данном кластере и могут применяться как часть Совместно используемых томов кластера (CSV, Cluster Shared Volumes). Это позволяет некоторому кластеру хостов Hyper-V применять собранное в кластер Пространство хранения как общее хранилище для виртуальных машин. Если применяется некая внешняя дисковая полка, Пространства хранения поддерживают протокол SES, который делает возможным индикацию отказов в имеющемся внешнем хранилище если он доступен, например, LED плохого диска, в случае если имеющееся событие Пространтсв хранения выявит некую проблемы с каким- то физическим диском. Хотя многие полки хранения работают с Пространствами хранения кластера, Microsoft имеет определённые сертифицированные полки для Windows Server 2012, которые документированы в каталоге Windows Server.

В пространствах хранения также могут быть применены и прочие технологии, такие как BitLocker. При создании некоторого нового пула хранения все добавляемые в этот пул хранения диски исчезнут из инструментария Диспетчера дисков, так как они теперь виртуализированы и используются исключительно самой технологией Пространств хранения. Состояние данных дисков можно просматривать через обзор Пулов Пространства хранения внутри Служб Файлов и Хранилища (File и Storage Services) в Диспетчере сервера.

Для создания Пространств хранения (Storage Spaces) воспользуйтесь следующими шагами:

Теперь доступен пул хранения и ваш следующий шаг состоит в создании виртуальных дисков внути данного пула хранения. Хотя Пространствами хранения и применяется термин виртуальный диск, он не является виртуальным жёстким диском любого рода и не применяет никоим образом VHD или VHDX. В данном контексте виртуальный диск просто является неким объектом, который создаётся в нём для использования операционной системой, которая осуществляет прямую запись в блоки внутри имеющегося пула хранения.

Пространства хранения вводят некую функциональность, которая ранее была доступна только при использовании некоторого внешнего решения хранения такого как устройства SAN или NAS: способность динамичного выделения (thin provision). В процессе создания виртуального диска доступен вариант создания нового виртуального диска фиксированного объёма (что означает, что всё пространство для данного размера виртуального диска выделяется в момент его создания), либо динамического выделения (что означает, что пространство из пула берётся только по мере необходимости). Применение диска с динамическим выделением делает возможным создание виртуального диска намного большего размера чем имеется доступным реального пространства хранения. Это позволяет вам изначально создавать большой том без наличия предварительно выделенного физического хранилища.

Итак, это не означает, что вы сможете хранить в диске с динамическим выделением данных больше, чем выделяется в вашем пуле, однако такой типичный том пополняется со временем. Я могу создать некий диск с динамическим выделением в 10 ТБ, который изначально имеет только 1 ТБ связанного с ним физического хранилища, я добавил бы 1 ТБ физического пространства в этот пул просто вставляя больше дисков. Когда будет достигнуты 2 ТБ, я добавляю другое хранилище в 1 ТБ вставляя диски ещё и так далее. По мере того как я добавляю физические диски до его заполнения нет никаких проблем. При достижении установленного порогового значения будет выдаваться предупреждающее сообщение, уведомляющее меня об этом, что даёт мне запас времени для добавить необходимые диски. При создании некоторого виртуального диска всё что требуется от вас это знать какой пул хранения вы используете для создания этого диска. Никакие знания о физических дисках не требуются и даже не доступны в открытом виде. Основной фишкой Пространств хранения является такое абстрагирование в создании виртуальных дисков, которое необходимо для соответствия вашим потребностям. Для создания виртуального диска выполните следующие шаги:

После создания виртуального диска он становится доступным внутри оснасток MMC Диспетчера сервера (Server Manager) и Управления дисками (Disk Management) для создания томов и форматирования некоторой файловой системой. То пространство, которое используется внутри пула можно увидеть в Диспетчере сервера или, если вы применяете некоего клиента, в апплете Панели управления (Control Panel) Пространств хранения.

Пространства хранения (Storage Spaces) Windows Server 2012 R2 имеют ряд улучшений. Одним из них является возможность наличия пространств с двумя контрольными суммами (parity), что делает доступным двух копий информации о контрольных суммах вместо одной. Это предоставляет дополнительную надёжность (удвоение контрольных сумм - parity - требует применения PowerShell и не доступно в Диспетчере севера -Server Manager), предоставляя поддержку для сценариев с контрольными суммами в кластерах, а также выполняет более быстрое перестроение в случае отказа. Утраченная информация восстанавливается на множестве дисков в пуле вместо повторного построения всего на отдельном диске, то ограничивало бы допустимую скорость всех доступных отдельному диску IOPS.

Имеется ещё одно ещё большее изменение пространств хранения Windows Server 2012 R2, которое может открыть новые уровни производительности: введение различия между обычными шпиндельными дисковыми устройствами (HDD) и твердотельными накопителями (SSD). В Пространствах хранения Windows Server 2012 R2 вы можете создавать различные уровни хранения, некий уровень HDD и какой- то уровень SSD. Технология Пространств хранения перемещает наиболее используемые блоки файлов с их уровня HDD на уровень SSD, предоставляя наивысший уровень производительности. Кроме того, уровень SSD может применять кэширование с отложенной записью (write-back). При возникновении записи, они вначале записываются на имеющийся уровень SSD, который является очень быстрым, а затем по мере возможностей переписывется на уровень HDD для долговременного хранения. Такая многоуровневая модель хранения показана на Рисунке 4.4.

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

Для использования множества уровней и кэширования отложенной записи вы можете воспользоваться PowerShell, который предоставляет гранулированное управление (хотя по умолчанию создаётся кэш отложенной записи 1 ГБ на всех новых виртуальных дисках если достаточно пространства SSD и диски доступны в этом пуле), Либо Диспетчер сервера для более простого практического применения, но с меньшей степенью грануляции в выбираемой конфигурации. В последующих командах PowerShell я создаю некое пространство хранения из четырёх дисков и двух SSD, а затем создаю виртуальный диск и создаю какой- то том.

#Перечисляем все диски, которые могут быть помещены в пул и выводятся в формате таблицы (format-table)
Get-PhysicalDisk -CanPool $True | `
ft FriendlyName,OperationalStatus,Size,MediaType
#Запоминаем все физические диски, которые могут быть помещены в пул в какой- то переменной, $pd
$pd = (Get-PhysicalDisk -CanPool $True | Where MediaType -NE UnSpecified)
#Создаём некий новый Пул хранения с применением всех дисков из переменной $pd
# с неким названием My Storage Pool
New-StoragePool -PhysicalDisks $pd `
–StorageSubSystemFriendlyName "Storage Spaces*" `
-FriendlyName "My Storage Pool"
#Просматриваем все диски в нашем только что созданном Пуле хранения
Get-StoragePool -FriendlyName "My Storage Pool" | `
Get-PhysicalDisk | Select FriendlyName, MediaType
# Создаём два уровня в этом созданном нами Пуле хранения.
#One for SSD disks and one for HDD disks
$ssd_Tier = New-StorageTier -StoragePoolFriendlyName "My Storage Pool" `
-FriendlyName SSD_Tier -MediaType SSD
$hdd_Tier = New-StorageTier -StoragePoolFriendlyName "My Storage Pool" `
-FriendlyName HDD_Tier -MediaType HDD
# Создаём новый виртуальный дтск в своём пуле с названием TieredSpace
# применяя имеющиеся уровни SSD (50GB) и HDD (300GB)
$vd1 = New-VirtualDisk -StoragePoolFriendlyName "My Storage Pool" `
-FriendlyName TieredSpace -StorageTiers @($ssd_tier, $hdd_tier) `
-StorageTierSizes @(50GB, 300GB) -ResiliencySettingName Mirror `
-WriteCacheSize 1GB
# в случае применения множества уровней не можем также определять -size, а также
# не можем использовать тип динамического выделения
		

Обычно со временем выявляются горячие блоки и они перемещаются на имеющийся уровень SSD как часть задания по оптимизации на час ночи. Однако, определённые файлы могут быть закреплены за этим уровнем SSD, что оставит их там на постоянной основе.Чтобы пришпилить некий файл к уровню SSD и тем самым принудительно оптимизировать его уровень, воспользуйтесь следующими командами:

Set-FileStorageTier –FilePath M:\Important\test.vhd `
-DesiredStorageTier ($vd1 | Get-StorageTier –MediaType SSD)
Optimize-Volume –DriveLetter M –TierOptimize
		

Применяя технологию Пространств хранения вы можете создавать гибкие и высокопроизводительные решения хранения с применением подключаемых напрямую дисков хранения, что может быть полезным в различных сценариях и архитектурах. Я прохожусь по Пространствам хранения в своём видео: www.youtube.com/watch?v=x8KlY-aP9oE&feature=share&list=UUpIn7ox7j7bH_OFj7tYouOQ.

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

Windows Server 2016 продолжил эволюцию Пространств хранения и применения этой технологии для разрешения совершенно нового уровня использования подключаемых напрямую хранилищ: как кластерной хранилище в виде Совместно используемых в кластере томов (CSV, Cluster Shared Volumes). Windows Server 2016 также вносит различие между SSD (как относительно экономичными хранилищами с флеш- памятью) и NVMe SSD (как обладающими большими производительностью и стоимостью). Пространства хранения применяют различные типы хранилищ с флеш- памятью автоматически, причём наиболее оптимальным образом, без какой бы то ни было настройки вручную. Например, при создании некоторого обычного Пространства хранения с применением Диспетчера сервера в Windows Server 2016, автоматически создаются уровни HDD и SSD, соответственно как стандартный и более быстрый уровни. При использовании Непосредственно подключаемых Пространств хранения (Storage Spaces Direct) имеется даже ещё большая грануляция (которую я поясню более подробно в своём следующем разделе Непосредственные Пространства хранения). Кроме того, в Windows Server 2016 дополнительные опции устойчивости теперь являются теперь частью соответствующего мастера Диспетчера сервера (Server Manager), что отображено на Рисунке 4.5:

Хотя основным средоточием Пространств хранения Windows Server 2016 и являются Непосредственно подключаемые пространства хранения (Storage Spaces Direct), также имеются и иные изменения вне пределов улучшений в рамках Диспетчера сервера:

Хотя протокол Блока серверных сообщений (SMB, Server Message Block) и был доступен в Windows на протяжении длительного времени, его применение было ограничено обычными сценариями совместного использования файлов, такими как доступ пользователей к их домашним дисководам или совместное владение файлами, содержащими архивированные данные. Hyper-V давно нуждался в наличии доступа к хранилищу на уровне блоков, то есть чтобы определённый хост монтировал содержащие виртуальные машины тома, которые могут напрямую подключаться или присоединяться через такие среды как iSCSI или Fibre Channel. Однако это являлось вызовом для многих контор, в которых применялись для виртуализации протоколы файлового уровня. В частности, VMware для хранения виртуальных машин использовал NFS, который был доступен во многих решениях NAS, которые обычно намного экономичнее чем решения SAN и хорошо соответствовали многим средам.

Windows Server 2012 внёс большой вклад в SMB, чтобы сделать его готовым решением корпоративного уровня, подходящим для хранения виртуальных машин и прочих рабочих нагрузок корпорации, таких как базы данных сервера SQL. SMB 3 привносит много новой функциональности и улучшений производительности чтобы сделать его практичным выбором для виртуального хранилища.

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

Когда некий пользователь редактирует какой- то документ PowerPoint в совместном ресурсе SMB, части такого документа кэшируются локально и временами пользователь кликает Save. Если ваш файловый сервер SMB испытывает какую- то проблему - допустим, если он осуществляет перезагрузку или он помещён в кластер и данный совместный файловый ресурс перемещён на другой узел в кластере - этот пользователь мог бы потерять соответствующий дескриптор (handle) и блокировку данного файла, однако на самом деле это не имеет никакого значения. Когда в следующий раз данный пользователь нажимает Save, всё восстанавливается и не происходит ничего страшного.

Теперь рассмотрим Hyper-V, хранящий какую- то виртуальную машину в неком совместном файле SMB, который испытывает какую- то проблему и этот совместно используемый файл перемещается на другой узел в данном кластере. Вначале данный блок Hyper-V будет ожидать тайм- аут для своего TCP, прежде чем вернётся реализация первоначального соединения, что может означать паузу в 30 секунд для данной ВМ, однако, кроме того Hyper-V теперь утратил свои дескрипторы и блокировки на данном VHD, что является гораздо большей проблемой. Всякий раз когда документы пользователя могут применяться на протяжении нескольких часов, корпоративные службы, такие как виртуальная машина или база данных ожидают, что дескрипторы на файлы будут доступны месяцами непрерывно.

 

Прозрачная отработка отказов SMB

Обычно для файловых служб в кластере некий отдельный узел монтирует определённый LUN (Logical Unit Number, Номер логического устройства), содержащий ту файловую систему, которая будет совместно использоваться и предлагаться для совместного использования клиентам SMB. Если этот узел отказывает, другой узел в кластере монтирует соответствующий LUN и предлагает свои совместно используемые файлы, однако соответствующий клиент SMB потерял бы свои дескрипторы и блокировки. Прозрачная отработка отказов SMB (SMB Transparent Failover) предоставляет защиту от каких- либо отказов узла, делая возможным перемещение совместного ресурса между узлами совершенно прозрачным образом для своих клиентов SMB и сопровождая все имеющиеся блокировки и дескрипторы, так же как и само состояние установленного соединения SMB.

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

Важно понимать, что даже при наличии прозрачной отработки отказа SMB всё ещё может иметься некая пауза для ввода/ вывода, так как соответствующий LUN всё ещё требуется смонтировать на некотором новом узле в имеющемся кластере. Тем не менее, команда отказоустойчивого кластера проделала гигантский объём работы в отношении оптимизации такого размонтирования и монтирования LUN чтобы гарантировать, что оно никогда не займёт более 25 секунд. Это звучит как достаточно большое значение времени, но поймите, что это наихудший вариант с большим количеством LUN и десятками тысяч дескрипторов. Для наиболее распространённых случаев это будет пара секунд, а корпоративные службы, такие как Hyper-V и сервер SQL могут обрабатывать некие операции ввода/ вывода без ошибок, которые в таком наихудшем случае займут до 25 секунд.

Существует также иная возможность прерывания в вводе/ выводе и того, что такой клиент SMB на самом деле заметит недоступность данного сервера SMB. В обычном плановом сценарии, таком как перезагрузка узла для внесения исправлений, он уведомит всех клиентов, которые могут иметь активности. Если узел, однако, завершит операцию неудачно, клиентам не будет выдано никаких уведомлений и, следовательно, данный клиент будет сидеть и ожидать тайм- аута TCP прежде чем будут предприняты действия для повторного восстановления связи, что является пустой тратой ресурсов. Хотя некий клиент SMB моежет даже и не подозревать что тот узел, с которым он общается в кластере отвалился, все прочие узлы в этом кластере информируются об этом в пределах секунды благодаря различным сообщениям IsAlive, которые отправляются между узлами. Такая информированность используется возможностями службами свидетельств (witness service), которые впервые стали доступными в Windows Server 2012. Такой сервер свидетель позволяет другому узлу в кластере выступать в роли свидетеля для конкретного клиента SMB и, если соответствующий узел клиента сообщает о падении, данный узел свидетеля уведомляет напрямую такого клиента SMB, позволяя этому клиенту соединиться с другим узлом, что минимизирует значение прерывания службы до пары секунд. Когда некий клиент SMB взаимодействует с каким- то сервером SMB, который является частью кластера, такой сервер SMB будет уведомлять всех клиентов о том, что в данном кластере доступны другие серверы, и такой клиент автоматически запросит один из прочих серверов в этом кластере отработать в качестве соответствующей службы свидетельства для данного соединения.

Никакое ручное вмешательство не требуется для получения преимуществ Прозрачного восстановления SMB или соответствующей службы свидетельства. Когда вы создаёте некий совместный ресурс в отказоустойчивом кластере Windows Server 2012 или выше, Прозрачная отработка отказов SMB включена автоматически.

 

Горизонтальное масштабирование SMB

В своём предыдущем разделе я пояснил, что может иметься некая пауза в действиях из- за того, что определённый LUN должен быть перемещён между узлами в имеющемся кластере файлового сервера, однако эта задержка может быть удалена. Данная проблема проистекает из того факта, что NTFS является ничего не разделяющей (shared-nothing) файловой системой и не может поддерживать одновременный доступ множества экземпляров операционной системы без риска разрушения. Данная проблема была решена введением CSV (Cluster Shared Volumes, Совместно используемых томов в кластере) в Windows Server 2008 R2. CSV позволяет всем узлам в кластере чтение и запись в одном и том же наборе LUN при помощи некоторых искусных технологий, тем самым удаляя потребность размонтирования и монтирования LUN между имеющимися узлами.

Windows Server 2012 расширил применение CSV на определённый тип файловых серверов, а именно вариант SoFS (Scale-Out File Server, Файлового сервера Горизонтального масштабирования), который стал новой опцией, доступной в Windows Server 2012 и имеющей целью использование только при совместном применении данных приложений, таких как базы данных сервера SQL и виртуальные машины Hyper-V. Обычный стиль общеупотребимого файлового сервера всё еще доступен для незакреплённых за приложениями данных, как это показано на Рисунке 4.13. При выборе данной опции создания некоторого SoFS вы должны выбрать CSV в качестве своего хранилища в случае когда совместные ресурсы последовательно создаются в рамках данного файлового сервера: данное хранилище таким образом доступно для всех узлов в этом кластере. Так как данное хранилище для такого совместного ресурса доступно всем узлам в этом кластере, этот совместный файловый ресурс сам по себе также размещается всеми имеющимися узлами в этом кластере, что теперь означает, что соединения клиента SMB распределены по всем узлам вместо наличия всего одного. Кроме того, если некий узел падает, нет никакой потребности в работе по перемещению таких LUN, что предлагает ещё лучшую практику примения и снижает все прерывания в операциях почти до нуля, а это критически важно для тех рабочих нагрузок прикладных серверов, для которых эти SoFS выступают в качестве цели.

Применение SoFS предлагает и дополнительные преимущества. Обычно, когда создаётся некий файловый сервер общего назначения как часть имеющейся конфигурации, вы должны присвоить такому новому файловому серверу кластера имя NetBIOS, а также его собственный уникальный IP адрес, так как этот IP адрес должен размещаться на каком угодно узле в данном кластере, который в данный момент размещает такой файловый сервер. Применяя SoFS, все узлы в этом кластере предлагают определённую файловую службу, что означает, что не требуется никакой дополнительный IP адрес. Необходимые IP адреса таких узлов в данном кластере используются посредством настроенной службы DNN (Distributed Network Name, Распределённых сетевых имён).

Все имеющиеся в этом кластере узлы предлагают ту же самую файловую службу и таким образом совместно применяются в данном SoFS. Имеется некое изменение функциональности между Windows Server 2012 и Windows Server 2012 R2. В Windows Server 2012 некий отдельный клиент SMB соединялся только с единственным из имеющихся узлов в каждый определённый момент времени, даже если установлено множество соединений. Когда данный клиент SMB инициирует соединения, он вначале получает список всех имеющихся адресов IP для имеющихся в кластере хостов и указывает один из них для начала своего сеанса SMB. Если затем применяется только этот узел, всякий раз когда такой узел испытывает некую проблему, клиент будет общаться с неким иным узлом. Единственное исключение состоит в том, что данный клиент SMB не взаимодействует с неким вторым узлом когда применяется служба свидетельства, которую я обсуждал ранее. Windows Server 2012 R2 ввёл функциональность установления балансировки, которая имеет два компонента:

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

 

SMB со множеством каналов

В любом решении критически важно избегать каких бы то ни было единых точек отказа, а если SMB применяется для доступа к определённому хранилищу, содержащему виртуальные машины, необходима надёжность для предотвращения отказов, вызываемых единственным сетевым адаптером, сетевым кабелем, или сетевым коммутатором. В инфраструктурах хранения применяются такие технологии,как MPIO (multipath I/O, ввод/ вывод со множеством путей) для предоставления множественности путей к хранилищу, и в точности та же самая идея теперь доступна к применению в SMB с помощью SMB со множеством каналов (SMB Multichannel).

SMB со множеством каналов позволяет какому-то клиенту SMB устанавливать множество соединений для отдельного сеанса, предоставляя защищённость от отказа отдельного соединения а также добавляя производительность. Как и большинство имеющихся функций SMB 3, никакие проводимые вручную шаги не требуются при использовании SMB со множеством каналов; всё происходит автоматически. При установлении начального соединения SMB, этот клиент SMB отыскивает такие дополнительные пути для применения. Это было бы очевидно, если бы отслеживали операции копирования файлов, поскольку изначально имеется только полоса пропускания только одного соединения. Однако если установлено второе соединение и агрегируется полоса пропускания, получаемая пропускная способность будет удвоена, а затем третье соединение и так далее. В случае, когда какое- то из соединений отваливается, всё ещё остаются прочие соединения для продолжения непрерывного существования канала SMB.

Чтобы увидеть применяется ли SMB со множеством каналов в вашем сервере, воспользуйтесь cmdlet PowerShell Get-SMBConnection, который покажет все соединения SMB в некотором совместном ресурсе SMB. В следующем примере я вижу, что у меня есть только два соединения с моим сервером:

PS C:\> get-smbconnection

ServerName        ShareName  UserName       Credential      Dialect NumOpens
----------        ---------  --------       ----------      ------- --------
savdalsofs.sav... Virtuals   NT VIRTUAL ... SAVILLTECH.N... 3.02    4
savdalsofs.sav... Virtuals   SAVILLTECH\... SAVILLTECH.N... 3.02    2
		

Если я исполню cmdlet Get-SmbMultiChannelConnection из своего клиента, он отобразит мне все имеющиеся доступными пути по тем серверам, которые могут принимать соединения, как это отображено в приводимом далее выводе. Отметим, что на стороне такого сервера сетевая среда применяет группирование (team) NIC, что означает только один IP адрес, но оно всё ещё может применяться для усиления SMB со множеством каналов.

PS C:\> get-smbmultichannelconnection

Server Name    Selected    Client IP    Server IP   Client   Server        Interface      Capable
Client RSS     Client RDMA                                                                Index
-----------    --------    ---------    ---------   ------- -------------- -------------- --------------
savdalsofs.... True        10.7.173.101 10.7.173.20 14      15             True           False
savdalsofs.... True        10.7.173.23  10.7.173.20 15      15             True           False
		

Чтобы убедиться какой из путей будет применён между выбранными клиентом и сервером я могу взглянуть на свои соединения TCP по удалённому порту 445, который применяется для SMB. Это подтвердит что я использую оба имеющихся пути с четырьмя подключениями для каждого пути (что является установленным по умолчанию числом).

PS C:\> Get-NetTCPConnection -RemotePort 445

LocalAddress LocalPort RemoteAddress   RemotePort State       AppliedSetting
------------ --------- --------------- --------   -----       --------------
10.7.173.23  56368     10.7.173.20     445        Established Datacenter
10.7.173.23  49826     10.7.173.20     445        Established Datacenter
10.7.173.23  49825     10.7.173.20     445        Established Datacenter
10.7.173.23  49824     10.7.173.20     445        Established Datacenter
10.7.173.101 49823     10.7.173.20     445        Established Datacenter
10.7.173.101 49822     10.7.173.20     445        Established Datacenter
10.7.173.101 49821     10.7.173.20     445        Established Datacenter
10.7.173.101 49820     10.7.173.20     445        Established Datacenter
		

 

Непосредственный SMB

Хотя и имеются прочие технологии SMB, такие как шифрование, Масштабирование принимающей стороной (Receive Side Scaling), VSS для совместных файлов SMB и прочие, последней функциональностью, которую я бы хотел упомянуть, это Непосредственный SMB (SMB Direct), который позволяет применять в SMB сетевые адаптеры с возможностью RDMA. Я уже обсуждал RDMA (remote direct memory access, удалённый прямой доступ к памяти) в Главе 3, Виртуальные сетевые среды, поскольку он относится к сетевым адаптерам и в равной степени важен для SMB.

При использовании Непосредственного SMB с возможностями RDMA сетевого адаптера, почти не применяются ресурсы процессора сервера. Такой сетевой адаптер указывает некий блок памяти, который содержит все данные, которые требуется отправить в их получателя и затем сама карта берёт в свои руки заботу по отправке с применением максимально возможной скорости и при очень малых задержках. За сценой могут использоваться сетевые адаптеры RDMA с применением iWARP, RDMA over Converged Ethernet (RoCE) или InfniBand, однако это не имеет значения для протокола SMB, который всего лишь пользуется возможностями имеющегося RDMA.

Нет никаких дополнительных требований для применения Непосредственного SMB. Как и всё, что связано с SMB, если такая возможность имеется, она должна быть предоставлена. Изначально между имеющимися клиентом и сервером устанавливается некое обычное соединение SMB. Отыскивается перечень всех доступных соединений, что делает возможным применение множества путей, а затем обнаруживаются все имеющиеся возможности предоставленных сетевых адаптеров. Если выясняется, что и отправитель и получатель поддерживают RDMA, тогда устанавливается некое соединение RDMA и операции SMB переключаются с TCP на RDMA, причём это делается полностью прозрачно.

Если вы применяете Непосредственный SMB в Windows Server 2012, вы увидите 50 процентное улучшение производительности при применении SMB Direct v2 в Windows Server 2012 R2 для небольших рабочих нагрузок ввода/ вывода, в частности для 8кБ IOPS, которые наиболее распространены в сценариях виртуализации.

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

 

Как воспользоваться SMB 3 в вашей среде

Если прямо сейчас ваш центр обработки данных располагает всеми хостами виртуализации, подключёнными к SAN верхнего уровня с применением Fibre Channel, скорее всего SMB 3 не окажет воздействия в настоящее время на такую среду. Однако, если не все серверы подключены к SAN, или у вас имеются новые окружения, такие как центры обработки данных или удалённые расположения, в которых нет SAN или которые не будут иметь SAN, однако вы желаете попытаться минимизировать стоимость инфраструктуры карт и коммутаторов Fibre Channel, SMB 3 может помочь.

Если у вас уже имеется SAN, однако в настоящее время нет необходимой инфраструктуры (к примеру, достаточного числа HBA) чтобы соединить все хосты с этим SAN, тогда вам предоставляется на Рисунке 4.14 великолепная возможность. Некий Горизонтально масштабируемый Файловый сервер помещается спереди от имеющегося SAN, который предоставляет доступ к такому хранилищу SAN через SMB 3. Это позволяет применять уже вложенные инвестиции в имеющийся SAN и его возможностям для применения всем центром обработки данных без требования для всех хостов быть подключёнными напрямую к этому SAN. Чтобы обеспечить наилучшую производительность, предоставьте по крайней мере столько томов CSV, сколько у вас есть узлов в вашем кластере чтобы сделать возможной применение балансировки. Для ещё более лучшей подстройки удвойте или утройте общее число томов CSV. Например, если у вас имеется четыре хоста в вашем кластере SoFS, я бы пожелал иметь по крайней мере восемь томов CSV.

Другим вариантом, если у вас нет SAN или вы не желаете применять его в определённых рабочих нагрузках является применение Пространств хранения (Storage Spaces) в качестве лежащего в основе хранилища. Хотя и было бы возможным иметь отдельный сервер для применения пространств хранения и размещения хранилища через SMB 3, это было бы плохим проектом из- за введения некой единой точки отказа. Если такой сервер SMB 3 недоступен, также станет недоступной и все размещённые в этом сервере рабочие нагрузки. Всегда пользуйтесь неким кластером файлового сервера и применяйте Пространства хранения в кластере, которые бы имели диски хранения в некоторой внешней полке доступными для подключения всеми узлами в этом кластере. Убедитесь, что для созданных виртуальных дисков имеется в доступности надёжность, скорее всего в виде зеркалирования для лучшей производительности. Это бы выглядело примерно как показано на Рисунке 4.15.

использовать SMB 3 в Hyper-V просто. Для полного контроля за имеющимися совместными ресурсами и уровнем файловой системы NTFS требуются учётная запись компьютера хоста Hyper-V и учётная запись самого кластера (если хосты расположены в некотором кластере). Дополнительно администратор, создающий или перемещающий все виртуальные машины должен иметь полный контроль на уровне совместных ресурсов и NTFS. Самый простой путь состоит в установке правильных полномочий с помощью PowerShell, что просто в Windows Server 2012 R2. Это также можно сделать через Диспетчер Отказоустойчивого кластера в совместных ресурсах горизонтально масштабируемых серверов. Следующая команда создаёт некую папку, а затем предоставляет этому компьютеру учётные записи для полного контроля со стороны хостов Hyper-V HV01 и HV02, а также учётную запись HVCLUS для самого отказоустойчивого кластера, чтобы он также имел полный контроль. Отметим символ $ после названий учётных записей компьютеров, который следует набирать. Кроме того, ещё и самому администратору предоставляется полный контроль.

MD G:\VMStore
New-SmbShare -Name VMStore -Path G:\VMStore `
-FullAccess domain\administrator, `
domain\HV01$, domain\HV02$, domain\HVCLUS$
Set-SmbPathAcl -Name VMStore
		

Отметим, что в Windows Server 2012 cmdlet Set-SmbPathAcl был недоступен и соответствующие полномочия NTFS приходилось устанавливать вручную, как это показано в следующей команде. Заметим, что это не требуется в Windows Server 2012 R2, так как cmdlet Set-SmbPathAcl копирует необходимые полномочия совместного ресурса в файловую систему NTFS.

ICACLS G:\VMStore /Inheritance:R
ICACLS G:\VMStore /Grant ' "domain\administrator:(CI)(OI)F"
ICACLS G:\VMStore /Grant domain\HV01$:(CI)(OI)F
ICACLS G:\VMStore /Grant domain\HV02$:(CI)(OI)F
ICACLS G:\VMStore /Grant domain\HVCLUS$:(CI)(OI)F
		

Когда необходимые полномочия правильно установлены, определите тот совместный ресурс SMB, который нужен для расположения создаваемой ВМ или как конечная цель миграции хранилища. Рисунок 4.16 показывает некую виртуальную машину, применяющую заданный совместный ресурс \\savdalsofs\Virtuals для своего хранилища. Отметим, что не только этот диск хранится в данном хранилище, но также и файлы конфигурации, файлы контрольной точки, а также файлы подкачки страниц. Имеется возможность применять другие местоположения для таких различных аксессуаров виртуальной машины.

Ранее я говорил о назначении хранилища определённой виртуальной машине в виде виртуального жёсткого диска, что требует первоначального подключения самого хоста Hyper-V к такому хранилищу с последующим созданием в нём файлов VHDX. Существует тем не менее и иной способ предоставления хранилищ виртуальным машинам.

iSCSI является популярной альтернативой соединениям Fibre Channel, которые делают возможными подключения блочного уровня к хранилищу SAN при помощи имеющейся сетевой инфраструктуры вместо требования целиком отдельной инфраструктуры (карт, кабелей, коммутаторов) исключительно под хранилище. iSCSI работает посредством обработки традиционных команд SCSI поверх сетевых сред IP. Хотя и имеется возможность исполнения iSCSI поверх обычной сетевой среды, если iSCSI применяется в качестве первичного сетевого транспорта, более распространённым является наличие выделенного сетевого соединения для iSCSI чтобы обеспечить требуемую полосу пропускания или в идеале применять сетевые соединения более крупного масштаба, такие как 10Gbps и использовать QoS чтобы гарантировать что iSCSI получит необходимый объём полосы пропускания.

В добавление к использованию iSCSI в Hyper-V для доступа к хранилищу, он также может использоваться внутри виртуальных машин как средство предоставления хранилища, которое доступно самой виртуальной машине. Оно включает также хранилище, которое может быть доступно для соединения со множеством виртуальных машин, что именуется как совместное хранилище shared storage, что требуется во множестве сценариев,в которых внутри виртуальных машин реализуются кластеры, именуемые гостевыми кластерами (guest clustering). Если вы намереваетесь применять iSCSI внутри виртуальных машин, будет хорошей идеей иметь выделенную сетевую среду под iSCSI. Это требует создания отдельного виртуального коммутатора в хостах Hyper-V, связываемых с сетевыми адаптерами, подключаемыми к тем адаптерам, которые выделяются под iSCSI, а затем создавать в виртуальной машине некий дополнительный сетевой адаптер, подключаемый кэтому виртуальному коммутатору. Если обсуждаемое взаимодействие iSCSI является важным в ваших делах, вы можете пожелать реализовать избыточные соединения. Это выполняется путём создания множества виртуальных коммутаторов, подключаемых к различным сетевым адаптерам, созданием множества виртуальных сетевых адаптеров в таких виртуальных машинах (подключаемых к создаваемым виртуальным коммутаторам), а затем использования MPIO внутри такой виртуальной машины. Я обсужу более подробно MPIO в разделе Основы виртуального Fibre Channel. Не применяйте группирование (teaming) NIC совместно с iSCSI, так как оно не поддерживается за исключением единственного сценария.

Если у вас имеется сценарий совместного использования NIC (описанный в Главе 3), который применяет различные сетевые адаптеры, которые собраны в группу при помощи решения группирования NIC Windows Server (причём это должно быть решение группирования NIC, осуществляемое поставкой Windows в его установке), а эта группа NIC затем имеет множество виртуальных сетевых адаптеров, создаваемых на уровне хоста для различных целей, одной из которых является применение iSCSI, такое группирование NIC поддерживается. Но это единственный раз, когда оно может применяться под iSCSI. Если у вас имеются выделенные под iSCSI сетевые адаптеры, тогда применяйте MPIO.

В iSCSI имеются две части: инициатор iSCSI, который является конкретным программным обеспечением клиента, которое делает возможным подключение к хранилищу iSCSI, а также определённый таргет iSCSI, который является программным обеспечением соответствующего сервера. Обсуждаемый инициатор iSCSI был встроенным компонентом Windows, начиная с Windows Server 2008/Windows Vista, помимо этого он также доступен для Windows Server 2000 и выше по следующей ссылке: www.microsoft.com/en-us/download/details.aspx?id=18986.

Windows также имеет встроенный таргет iSCSI начиная с Windows Server 2012 и далее, а также доступный для выгрузки для Windows Server 2008 R2 www.microsoft.com/en-us/download/details.aspx?id=19867.

Помимо этого, большинство решений SAN и некоторые NAS предлагают iSCSI как средство для подключения. Для iSCSI также доступны и прочие компоненты, например, iSNS, который предоставляет централизованный репозиторий серверов iSCSI? что упрощает обнаружение ISCSI. Полное погружение в пучины iSCSI выхоит за рамки данного. В центре моего внимаия находятся обязательные требования для включения некоего подключения iSCSI.

Таргет iSCSI Windows Server предоставляет хранилище с применением общего формата виртуального жёсткого диска, что было бы эквивалентно LUN обычного SAN. Таргет iSCSI Windows Server 2012 применяет реализацию VHD для своего хранилища, который ограничивает таргеты iSCSI до 2 ТБ, а также фиксированным типом, что требует выделения всего хранилища в момент создания таргета. Таргеты iSCSI Windows Server 2012 R2 применяют вместо этого VHDX, что делает возможными 64TB таргеты iSCSI и разрешает вариант применения динамического типа, удаляя потребность выделения при создании всего хранилища и вместо этого выделяя пространства при записи.

Таргет iSCSI не установлен по умолчанию. Его следует установить с помощью Диспетчера сервера и он доступен через File And Storage Services ➢ File And iSCSI Services ➢ iSCSI Target Server. Также доступен поставщик хранилища таргета iSCSI VDS и VSS (аппаратные поставщики VDS и VSS). Обсуждаемый таргет также может быть установлен с помощью PowerShell:

Install-WindowsFeature FS-iSCSITarget-Server
		

После установки необходимой роли таргета iSCSI, ею можно управлять через Server Manager ➢ File And Storage Services ➢ iSCSI. Для включения какого- то нового таргета iSCSI восподьзуйтесь следующими шагами:

Заметим, что весь приведённый процесс можно автоматизировать с помощью cmdlet PowerShell New-IscsiVirtualDisk и New-IscsiServerTarget. На данном этапе у вас имеется размещённый в Windows таргет, который был настроен с тем, чтобы к нему могли осуществлять доступ определённый IQN. Если соответствующий таргет iSCSI Windows применяется для размещения важных данных, следует применять некий кластер чтобы предоставить данную службу iSCSI который поддерживает полную кластеризацию.