Сценарии сбоя Storage Spaces Direct
Storage Spaces Direct выявляет различные сценарии сбоя. Чтобы понять, как это работает, сначала нужно вспомнить некоторые основные сведения о виртуальных дисках.
Содержание:
Сценарии сбоя
Виртуальный диск состоит из областей, каждая из которых размером в 1 GB. Таким образом, 100 ГБ виртуального диска будет состоять из ста 1 ГБ экстентов. Если виртуальный диск зеркальный (использует ResiliencySettingName), есть несколько копий экстентов. Количество копий (полученных с помощью NumberOfDataCopies) экстентов, может быть два или три. Например, зеркальный виртуальный диск с тремя копиями данных потребляет 300 экстентов.
Размещение экстентов определяется доменом ошибок, который в Storage Spaces Direct является узлом (StorageScaleUnit), поэтому, три копии экстента (A) помещаются в три разных узла хранения. Например, узлы 1, 2 и 3 на рисунке ниже. Другой экстент (B), одного и того же виртуального диска, может иметь свои, размещённые на разных узлах, три копии. Например, узлы 1, 3 и 4, и так далее. Это означает, что виртуальный диск имеет свои, распределённые на всех узлах хранения, экстенты, а копии каждого экстента размещаются на разных узлах. На рисунке ниже четыре узла развёртывания с зеркального виртуального диска, три копии и пример размещения экстентов.
Четыре узла развёртывания
Далее давайте посмотрим на различные сценарии сбоя и изучим, как Storage Spaces их обрабатывает.
Сценарий 1: Произошёл сбой в одном или более секторов на диске
В этом случае Storage Spaces будет перераспределять затронутые отказоустойчивыми секторами экстенты. Целевой диск для перераспределения, может быть другим диском в одном и том же узле или в другом узле, который ещё не имеет копии экстентов. Так если три копии экстентов на узлах «A», «B», «C» и экстенты на узле «A» пострадали от сбоя сектора, на другом диске, в узле «A» или любом диске в узле «D», могут быть созданы новые копии. Диски в узле «B» и «C» использоваться не могут, потому что в этих двух узлах уже есть копия экстентов.
Сценарий 2: Сбой диска
В этом случае, при обнаружении отказа диска, Storage Spaces удаляет физический диск из пула хранения. После отказа физического диска, каждый виртуальный диск начинает процесс его восстановления. Поскольку физический диск был подвержен сбою, виртуальные диски генерируют новую копию бывших на том физическом диске экстентов. Новые копии следуют той же логике, как и в сценарии 1.
Сценарий 3: Потеря диска А
В этом случае Storage Spaces будет делать одну из двух вещей:
- Если отсутствует только физический диск, Storage Spaces удалит диск.
- Если также отсутствует узел хранения или физическая оболочка, к которой присоединён физический диск, Storage Spaces не будет удалять физический диск.
Причина, по которой Storage Spaces не будет удалять физический диск во втором случае, заключается в том, что во время перезапуска узла хранения или временного обслуживания узла хранения, все диски и физические оболочки, связанные с этим узлом, будут отсутствовать. Автоматическое отключение всех этих дисков и оболочек потенциально может привести к огромному количеству операций по восстановлению, потому что вам нужно будет перестроить все экстенты на этих дисках в другом месте системы хранения. Это может быть несколько терабайт данных.
Если накопители и корпуса действительно отсутствуют и не вернутся в систему хранения, администратор должен удалить недостающие физические диски и начать процесс восстановления.
Сценарий 4: Перезагрузка узла хранения или техническое обслуживание
В этом случае, Storage Spaces автоматически изымает физические диски из пула носителей по причинам, описанным ранее в сценарии 3. Когда узел хранилища возвращается в сеть, Storage Spaces автоматически обновляет все не обновлённые копиями экстенты, но только те, на которые не повлияли перезапуск или обслуживание.
Сценарий 5: Отказ узла постоянного хранения
В этом случае, Storage Spaces требует от администратора удалить из пула носителей все пострадавшие физические диски, добавить, при необходимости, к системе хранения дополнительные узлы, а затем начать процесс восстановления. Это не автоматический процесс, потому что Storage Spaces не знает, отказ является временным или постоянным. Не желательно начинать восстановление, которое может потенциально привести к значительному ремонту.
Более подробная информация о Storage Spaces непосредственно в Windows Server 2016, на .
Дедупликация
В дедупликации Windows Server 2016 основное внимание уделяется существенному влиянию на масштабируемость и производительность, которые вам может дать эта технология. Вы можете использовать Windows Server 2016 в следующих сценариях:
- Тома до 64 ТБ
- Файл размером до 1 ТБ
- Виртуальное резервное копирование
- Поддержка Nano сервера
- Rolling обновления кластера
Дедупликация была введена ещё в Windows Server 2012 и основные принципы получения данных в фрагментированном состоянии остались прежними. Теперь давайте рассмотрим, что изменилось, что делает эти новые сценарии возможными.
Был усовершенствован механизм оптимизации, от одного потока к многопараллельному потоку, с использованием нескольких потоков ввода-вывода.
Обработка в один поток или параллельная обработка
В дополнение к этому параллельному исполнению, был переработан алгоритм обработки файлов, с использованием новой структуры карты потоков и улучшенной частичной оптимизацией файлов. Это обеспечивает масштабируемость и производительность обработки файлов размером до 1 ТБ. На следующем рисунке показано, как изменилась технология сопоставления, обеспечивая общую оптимизацию тома.
Сопоставление старой и новой структуры потока
Хотя Microsoft в Windows Server 2012 R2, технически поддерживала и предоставляла рекомендации по использованию дедуплицированных томов с DPM, теперь в Windows Server 2016 включены дополнительные улучшения, обеспечивающие простоту настройки и поддержки. Вы можете настроить это непосредственно в графическом интерфейсе Windows 2016 или Windows PowerShell с помощью командлета Enable-DeDup, но включив новый атрибут резервного копирования.
Enable-DedupVolume -Volume <volume> -UsageType Backup
Ещё одна замечательная опция - поддержка обновления кластера. Вы можете начать процесс обновления узлов кластера в Windows Server 2016 и поддерживать процесс дедупликации в Windows 2012. Раньше это не поддерживалось. Во время перехода на Windows 2016 все задания будут выполняться в режиме Windows 2012.
И наконец ещё одно небольшое обновление, которое стоит отметить - это доступность интерфейса управления хранилищем (SMAPI) для использования с System Center Virtual Machine Manager 2016. Это позволяет вам настроить дедупликацию и отчётность о состоянии в System Center Virtual Machine Manager 2016.
