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 не знає, відмова є тимчасовим або постійним. Не бажано починати відновлення, яке може потенційно привести до значного ремонту.
Дедуплікація
Був вдосконалений механізм оптимізації, від одного потоку до багатопаралельні потоку, з використанням декількох потоків введення-виведення.
На додаток до цього паралельного виконання, був перероблений алгоритм обробки файлів, з використанням нової структури карти потоків і поліпшеною часткової оптимізацією файлів. Це забезпечує масштабованість і продуктивність обробки файлів розміром до 1 ТБ. На наступному малюнку показано, як змінилася технологія зіставлення, забезпечуючи загальну оптимізацію томи.
Enable-DedupVolume -Volume