Планирование томов в кластерах Azure Stack HCI и Windows Server

Область применения: Azure Stack HCI версий 22H2 и 21H2; Windows Server 2022, Windows Server 2019

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

Примечание

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

Краткие сведения: что такое тома

В томах размещаются файлы, необходимые для рабочих нагрузок, например VHD или VHDX-файлы для виртуальных машин Hyper-V. Тома объединяют диски в пуле носителей, чтобы обеспечить отказоустойчивость, масштабируемость и производительность Локальные дисковые пространства, программно-определяемой технологии хранения, лежащей в основе Azure Stack HCI и Windows Server.

Примечание

Мы используем термин "том" для обозначения тома и виртуального диска под ним, включая функции, предоставляемые другими встроенными функциями Windows, такими как общие тома кластера (CSV) и ReFS. Для успешного планирования и развертывания локальных дисковых пространств понимать эти различия необязательно.

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

Все тома доступны всем серверам в кластере одновременно. После создания они отображаются в папке C:\ClusterStorage\ на всех серверах.

Снимок экрана: окно проводника ClusterStorage, содержащее тома с именами Volume1, Volume2 и Volume3.

Выбор количества томов

Рекомендуем использовать количество томов, кратное количеству серверов в кластере. Например, если у вас 4 сервера, производительность будет выше с 4 общими томами, чем с 3 или 5. Это позволяет кластеру распределять "принадлежность" тома равномерно между серверами (один сервер выполняет оркестрацию метаданных для каждого тома).

Рекомендуется ограничить общее количество томов до 64 томов на кластер.

Выбор файловой системы

Рекомендуем использовать новую файловую систему Resilient File System (ReFS) для локальных дисковых пространств. ReFS — это основная файловая система для виртуализации, которая обеспечивает множество преимуществ, в том числе существенное ускорение работы и встроенную защиту от повреждения данных. Он поддерживает почти все ключевые функции NTFS, включая дедупликацию данных в Windows Server версии 1709 и более поздних. Дополнительные сведения см. в таблице сравнения функций ReFS.

Если рабочей нагрузке требуется функция, которую еще не поддерживает ReFS, можете использовать NTFS.

Совет

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

Выбор типа устойчивости

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

Примечание

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

С двумя серверами

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

Двустороннее зеркальное отображение сохраняет две копии всех данных, по одной копии на дисках на каждом сервере. Эффективность хранения составляет 50 процентов; Чтобы записать 1 ТБ данных, в пуле носителей требуется не менее 2 ТБ физического хранилища. Двустороннее зеркальное отображение может безопасно допускать один сбой оборудования за раз (один сервер или диск).

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

Вложенная устойчивость обеспечивает устойчивость данных между серверами с двусторонним зеркальным отображением, а затем добавляет устойчивость на сервере с двусторонним зеркальным отображением или зеркало ускоренной четности. Вложение обеспечивает устойчивость данных, даже если один сервер перезапускается или недоступен. Его эффективность хранения составляет 25 процентов при вложенном двустороннем зеркальном отображении и около 35–40 процентов для вложенного зеркало ускорения четности. Вложенная устойчивость может безопасно переносить два сбоя оборудования одновременно (два диска или сервер и диск на оставшемся сервере). Из-за этого мы рекомендуем использовать вложенную устойчивость в рабочих развертываниях двухсерверных кластеров. Дополнительные сведения см. в разделе Вложенная устойчивость.

На схеме показана вложенная зеркало ускорение четности с двусторонним зеркало между серверами, связанными с двусторонним зеркало на каждом сервере, соответствующим уровню четности на каждом сервере.

С тремя серверами

С тремя серверами следует использовать трехстороннее зеркальное отображение, чтобы обеспечить более высокую отказоустойчивость и производительность. В этом случае хранятся три копии всех данных, по одной копии на каждом сервере. Эффективность хранилища составляет 33,3 процента. Для записи 1 ТБ данных в пуле носителей требуется не менее 3 ТБ физической емкости хранилища. Трехстороннее зеркальное отображение может безопасно переносить по крайней мере две проблемы с оборудованием (диск или сервер) одновременно. Если 2 узла станут недоступными, пул носителей потеряет кворум, так как 2/3 дисков недоступны, а виртуальные диски будут недоступны. Однако узел может быть отключен, и один или несколько дисков на другом узле могут завершиться сбоем, и виртуальные диски останутся в сети. Например, в случае перезагрузки одного сервера при внезапном сбое другого диска или сервера все данные остаются в целостности и постоянно доступными.

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

С четырьмя или более серверами

С четырьмя или более серверами для каждого тома можно выбрать, следует ли использовать трехстороннее зеркальное отображение, двойную четность (часто называемую "стирание кода") или сочетать их с зеркало ускорением четности.

Двойная четность обеспечивает ту же отказоустойчивость, что и трехстороннее зеркальное отображение, но лучшую экономичность хранения. С четырьмя серверами эффективность хранилища составляет 50,0 процента; для хранения 2 ТБ данных требуется 4 ТБ физической емкости хранилища в пуле носителей. Это повышает эффективность хранилища до 66,7 % на семи серверах и продолжает работать до 80,0 %. Кодирование четности требует большего объема вычислений, что может ограничивать его производительность.

На схеме показаны два тома, помеченные данными, и два тома с метками четности, соединенные круговыми стрелками с каждым томом, связанным с сервером, содержащим физические диски.

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

Тип устойчивости Эффективность емкости Speed Рабочие нагрузки
Зеркальное отображение Эффективность хранилища: 33 %
Трехсторонняя зеркало: 33%
Двусторонняя зеркало: 50 %
Производительность, показывающая 100 %
Максимальная производительность
Виртуализированные рабочие нагрузки
Базы данных
Другие высокопроизводительные рабочие нагрузки
Четность с зеркальным ускорением Эффективность хранилища, показывающая около 50 %
Зависит от доли зеркало и четности
Производительность, показывающая около 20 %
Гораздо медленнее, чем зеркало, но в два раза быстрее двойной четности
Лучше всего подходит для больших последовательных операций записи и чтения
Архивация и резервное копирование
Инфраструктура виртуализированных рабочих столов
Двойная четность Эффективность хранилища, показывающая около 80 %
4 сервера: 50 %
16 серверов: до 80 %
Производительность, показывающая около 10 %
Максимальная задержка ввода-вывода & загрузки ЦП при записи
Лучше всего подходит для больших последовательных операций записи и чтения
Архивация и резервное копирование
Инфраструктура виртуализированных рабочих столов

Когда важнее всего производительность

Рабочие нагрузки, у которых жесткие требования к задержке, а также рабочие нагрузки с большим количеством смешанных случайных операций ввода-вывода в секунду, например связанные с базами данных SQL Server или требовательными к производительности виртуальными машинами Hyper-V, необходимо запускать на томах с зеркальным отображением для повышения производительности.

Совет

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

Когда важнее всего емкость

Рабочие нагрузки, которые выполняют запись редко, например связанные с хранилищами данных или автономным неструктурированным защищенным хранилищем, необходимо запускать на томах с двойной четностью для повышения экономичности хранения. Некоторые другие рабочие нагрузки, например Scale-Out файлового сервера (SoFS), инфраструктуры виртуальных рабочих столов (VDI) или другие, которые не создают большого количества быстро меняющегося случайного трафика ввода-вывода и (или) не требуют наилучшей производительности, также могут использовать двойную четность по вашему усмотрению. Четность неизбежно увеличивает загрузку ЦП и задержку ввода-вывода, особенно при записи, если сравнивать ее с зеркальным отображением.

При массовой записи данных

Рабочие нагрузки, которые записывают большие последовательные проходы, такие как целевые объекты архивации или резервного копирования, имеют другой вариант: один том может сочетать зеркальное отображение и двойную четность. Записанные данные сначала оказываются в зеркально отображаемом разделе, а затем постепенно перемещаются в раздел четности. Это ускоряет прием больших объемов данных и снижает использование ресурсов при этом, так как ресурсоемкое кодирование четности может выполняться в течение более длительного времени. Объем данных, записываемых за раз (например, ежедневная резервная копия) должен свободно помещаться в раздел зеркала. Например, если 100 ГБ принимаются один раз в день, рекомендуем использовать зеркальное отображение для объема 150–200 ГБ и двойную четность для остального объема.

Итоговая экономичность хранения зависит от выбранных пропорций. Примеры см. в этом ролике.

Совет

Если вы наблюдаете резкое снижение производительности записи частично в процессе приема данных, это может означать, что часть зеркало недостаточно велика или что зеркало четность не подходит для вашего варианта использования. Например, если производительность записи снижается с 400 МБ/с до 40 МБ/с, рассмотрите возможность расширения зеркало части или перехода на трехстороннюю зеркало.

О развертываниях с NVMe, SSD и HDD

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

В развертываниях с дисками трех типов только самые быстрые диски (NVMe) обеспечивают кэширование, а другие диски (SSD и HDD) обеспечивают емкость. Вы можете выбрать, где будет располагаться каждый том: полностью на уровне SSD, полностью на уровне HDD или и там, и там.

Важно!

Рекомендуем использовать уровень SSD для размещения самых требовательных к производительности рабочих нагрузок в системе только с флэш-накопителями.

Выбор размера томов

Рекомендуется ограничить размер каждого тома до 64 ТБ в Azure Stack HCI.

Совет

Если вы используете решение резервного копирования, которое использует службу теневого копирования томов (VSS) и поставщика программного обеспечения Volsnap (как это обычно происходит с рабочими нагрузками файлового сервера), ограничение размера тома до 10 ТБ повысит производительность и надежность. Системы резервного копирования, которые используют новые API RCT Hyper-V, клонирование блоков ReFS или нативные API резервного копирования SQL, хорошо работают на томах размером 32 ТБ и более.

Занимаемое место

Размер тома — это объем данных, которые могут в нем храниться. Он указывается с помощью параметра -Size командлета New-Volume, а затем отображается в свойстве Size при запуске командлета Get-Volume.

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

В пуле носителей должно быть достаточно места для томов.

На схеме показан том размером 2 ТБ по сравнению с объемом 6 ТБ в пуле носителей с указанным множителем 3.

Резервирование емкости

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

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

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

Например, если у вас 2 сервера и диски хранения по 1 ТБ, зарезервируйте 2 ТБ в пуле (2 x 1 = 2). Если у вас 3 сервера и диски хранения по 1 ТБ, зарезервируйте 3 ТБ (3 x 1 = 3). Если у вас 4 или больше серверов и диски хранения по 1 ТБ, зарезервируйте 4 ТБ (4 x 1 = 4).

Примечание

В кластерах с дисками всех трех типов (NVMe + SSD + HDD) рекомендуем зарезервировать место, равное суммарному размеру одного SSD и одного HDD на сервер (до 4 дисков в каждом случае).

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

Рассмотрим один кластер с четырьмя серверами. У каждого сервера есть кэш-диски, а также 16 дисков хранения по 2 ТБ.

4 servers x 16 drives each x 2 TB each = 128 TB

Из этих 128 ТБ в пуле носителей мы резервируем четыре диска (8 ТБ), чтобы диски после сбоя могли восстанавливаться "на месте" без какой-либо спешки. После этого в пуле остается 120 ТБ физической памяти, с помощью которой можно создать тома.

128 TB – (4 x 2 TB) = 120 TB

Предположим, нам нужно разместить в развертывании высокоактивные виртуальные машины Hyper-V, но нам также нужно хранить много старых файлов и резервных копий. Так как у нас четыре сервера, создадим четыре тома.

Поместим виртуальные машины на первые два тома (Volume1 и Volume2). Мы выбираем файловую систему ReFS (для быстрого создания и контрольных точек) и трехстороннее зеркальное отображение для максимальной производительности. Поместим автономное неструктурированное защищенное хранилище на другие два тома (Volume 3 и Volume 4). Мы выбираем файловую систему NTFS (для дедупликации данных) и двойную четность для максимальной емкости.

Необязательно делать все тома одного размера, но для простоты можем сделать все тома по 12 ТБ.

Каждый из томов 1 и Том 2 будет занимать 12 ТБ x 33,3 процента эффективности = 36 ТБ физического хранилища.

Volume3 и Volume4 будут занимать 12 ТБ x 50,0 % эффективности = 24 ТБ физического хранилища.

36 TB + 36 TB + 24 TB + 24 TB = 120 TB

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

На схеме показаны два тома по 12 ТБ с тремя способами зеркало, каждый из которых связан с хранилищем по 36 ТБ, и два тома с двойной четностью по 12 ТБ, каждый из которых связан с 24 ТБ, каждый из которых занимает 120 ТБ в пуле носителей.

Совет

Необязательно создавать все тома сразу. Вы всегда можете расширить или создать тома позже.

Для простоты в этом примере используются десятичные единицы (с основанием 10), то есть 1 ТБ = 1 000 000 000 000 байтов. Однако размеры хранилищ в Windows отображаются в двоичных единицах (с основанием 2). Например, диски по 2 ТБ будут отображаться в Windows как диски по 1,82 ТиБ. Для пула носителей размером 128 ТБ будет отображаться 116,41 ТиБ. Это ожидаемое поведение.

Использование

См. статью Создание томов в Azure Stack HCI.

Дальнейшие действия

Дополнительные сведения см. также в следующих разделах: