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

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

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

Примечание.

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

Рецензирование. Что такое тома

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

Примечание.

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

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

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

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

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

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

Для Локальных дисковых пространств мы рекомендуем использовать новую файловую систему ReFS (устойчивая файловая система). Файловая система ReFS специально создана как идеальное решение для поддержки виртуализации. Она предоставляет много преимуществ, включая значительное ускорение производительности и встроенную защиту от повреждения данных. В среде Windows Server версии 1709 и более поздних версий она поддерживает почти все ключевые функции NTFS, включая дедупликацию данных. Дополнительные сведения см. в таблице сравнения возможностей ReFS.

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

Совет

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

Тип устойчивости	Эффективность емкости	Скорость	Рабочие нагрузки
Зеркальное отображение	Трехсторонняя зеркальная копия: 33% Двустороннее зеркальное отображение: 50 %	Наивысшая производительность	Виртуализированные рабочие нагрузки Базы данных Другие рабочие нагрузки, требующие высокой производительности
Контроль четности с зеркальным ускорением	Зависит от распределения зеркального отображения и четности	Намного медленнее зеркального отображения, но в два раза быстрее двойного контроля четности Оптимально для объемных последовательных операций записи и чтения	Архивация и резервное копирование Инфраструктура виртуальных рабочих столов
Двойной контроль четности	4 сервера: 50 % При 16 серверах: до 80 %	Наивысшая задержка чтения и записи, плюс высокая нагрузка на ЦП при записи Оптимально для объемных последовательных операций записи и чтения	Архивация и резервное копирование Инфраструктура виртуальных рабочих столов

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

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

Совет

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

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

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

Когда данные записываются в больших объемах

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

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

Совет

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

Развертывания на основе NVMe, SSD и HDD

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

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

Внимание

Мы рекомендуем размещать наиболее чувствительные к производительности рабочие нагрузки только на дисках SSD.

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

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

Совет

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

Занимаемый объем

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

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

Занимаемый объем тома не может превышать размер пула носителей.

Зарезервированная емкость

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

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

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

Примечание.

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

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

Давайте рассмотрим в качестве примера один кластер с четырьмя серверами. Каждый сервер имеет несколько дисков кэша и 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, а кроме них нам нужно много "холодного" хранилища для старых файлов и резервных копий. У нас есть четыре сервера, значит лучше всего создать четыре тома.

Наши виртуальные машины мы поместим в первые два тома Volume 1 и Volume 2. Для них мы выберем файловую систему ReFS (для повышения скорости и создания контрольных точек) и реализуем устойчивость через трехстороннее зеркальное отображение, чтобы добиться максимальной производительности. На других двух томах, Volume 3 и Volume 4, мы разместим холодное хранилище. Здесь мы выберем файловую систему NTFS (для использования дедупликации данных) и контроль четности, чтобы добиться максимального объема.

Мы не обязаны делать все тома одинакового размера, но для простоты примера они у нас будут размером по 12 ТБ.

Том1 и Том2 занимают 12 ТБ x 33,3 процента эффективности = 36 ТБ физической емкости хранилища.

Том3 и Том4 занимают 12 ТБ x 50,0 % эффективности = 24 ТБ физической емкости хранилища.

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

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

Совет

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

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

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

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

Следующие шаги

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

• Выбор дисков для Локальных дисковых пространств
• Отказоустойчивость и эффективность хранилища