Віртуальна редакція домену даних: Пояснення використання простору на диску даних у Data Domain Virtual Edition (DDVE)
Summary: Пояснення використання простору на диску даних у Data Domain Virtual Edition (DDVE)
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Symptoms
Data Domain Virtual Edition (DDVE) – це новий продукт, що дозволяє розгортати відновлювач доменів даних (DDR) у віртуальному середовищі. Після завершення розгортання необхідно надати диски з даними для використання файловою системою DDFS у DDVE. У цій статті пояснюється, як використовується фізичний простір на цих дисках із даними та чому корисний простір у файловій системі DDFS може бути значно нижчим, ніж сумарний розмір усіх дисків із даними
Resolution
При додаванні дисків з даними до екземпляра DDVE необхідно дотримуватися певних правил ємності:
- Розмір першого диска з даними повинен становити мінімум 200 Гб
- Усі наступні диски з даними повинні мати розмір
не менше 100 Гб. Причина, по якій розмір першого диска повинен бути мінімум 200 Гб, полягає в тому, що на цьому диску є значні накладні витрати, як описано нижче.
Припустимо, що диск з даними об'ємом 200 Гб представлений DDVE, доданий до активного рівня і використаний для створення екземпляра файлової системи DDFS. Фізичний диск буде використовуватися наступним чином:
Спочатку диск розділений на розділи, причому зріз 5 використовується для зберігання даних, а зріз 6 використовується для файлових систем ext3:
Модель: Невідомий (невідомий)
Диск /dev/dm-4: 200ГіБ
Розмір сектора (логічний/фізичний): 512B/512B
Таблиця розділів: Номер gpt
Початок Розмір кінця Файлова система Прапорці назв 1
0,00GiB 0,00GiB0,00GiB основний
2 0,00GiB 0,00GiB0,00GiB
основний 3 0,00GiB 0,01GiB основний
4 0,01GiB 0,01GiB 0,00GiB
5 0.01GiB 193GiB 193GiB основний <=== Використовується для зберігання
даних 6 193GiB 200GiB 6.77GiB основний <=== Використовується для ext3
В результаті ~193Gb дискового простору (фрагмент 5) буде надано драйверу RAID для використання.
Однак зауважте, що DDVE використовує концепцію RAID на LUN (ROL) для захисту від певних типів пошкодження даних (наприклад, пошкодження даних, яке не може бути виявлено/виправлено базовим масивом зберігання). ROL резервує приблизно 5,6% простору в зрізі 5 для інформації про парність. В результаті RAID зробить доступним лише ~182.3Gb для використання DDFS (як показано нижче - зверніть увагу, що розмір кожного сектора становить 512 байт):
Array [ppart2] (активний): [Тип RAID 106] [(0x1, 0x30) параметри] [NVR:N/N] [4608KB страйп] [382362624 секторів] [382362624 всього секторів]
[dm-4p5]
Простір ~182.3Gb, відведений DDFS, розбивається на блоки розміром 1075838976 байти - в результаті ми можемо створити 181 такий блок. Потім блоки розподіляються між різними файловими системами верхнього рівня в DDFS за потреби. Зверніть увагу, що при створенні нового екземпляра DDFS потрібно виділити значну кількість місця для метаданих, таких як індекс/вектор резюме/CP мета/зарезервовані блоки, файлові системи: ФІКСОВАНИЙ РОЗМІР БЛОКУ, РОЗМІР ЧИСЛА, ІМ'Я РОЗМІРУ БЛОКІВ,
194726854656 181 1075838976 /..
/vpart:/vol2/col1
Так 194726854656 181 1075838976 /.. /vpart:/vol2/col1/cp1
No 37654364160 21 1075838976 /.. /vpart:/vol2/col1/cp1/cset
No 65626177536 61 1075838976 /.. /vpart:/vol2/col1/cp1/full_indices
No 22592618496 21 1075838976 /.. /vpart:/vol2/col1/cp1/partial_indices
No 1075838976 1 1075838976 /.. /vpart:/vol2/col1/cp1/summary.0
No 1075838976 1 1075838976 /.. /vpart:/vol2/col1/cp1/summary.1
No 1075838976 1 1075838976 /.. /vpart:/vol2/col1/cp_meta
No 10758389760 10 1075838976 /.. /vpart:/vol2/reserved_blocks
Зверніть увагу, що все, крім контейнерного набору (CSET - де зберігаються дані користувача) споживає 95 * 1075838976 байтових блоків. В результаті залишається 86 блоків для потенційного використання CSET. Зверніть увагу, що 86 * 1075838976 байт = ~86.2Gb.
У CSET ми використовуємо дуже невелику кількість місця для метаданих, а потім оцінюємо, що можемо використовувати всі решту 1075838976 байтових блоків системи для створення контейнерів розміром 4,5 Мб. Якщо ми перевіримо метадані CSET, то побачимо:
cm_attrs.psize=4718592 <=== Кожен контейнер має розмір 4,5 Мб
...
cm_attrs.max_containers=17403 <=== Максимально можлива кількість 'придатних' контейнерів
...
cm_attrs.reserved_containers=2176 <=== Зарезервовані контейнери для внутрішніх операцій
Загальна кількість контейнерів, які можуть бути створені в рамках CSET, становить 17403 + 2176 = 19579
Кожен контейнер має розмір 4,5 Мб, тому 19579 контейнерів дорівнює 86.0 Гб дискового простору
. Зауважте, однак, що зарезервовані контейнери призначені лише для внутрішнього використання (за такими операціями, як очищення), тому не враховуються при відображенні використовуваного розміру файлової системи користувачам. У зв'язку з цим «використовуваний» розмір файлової системи DDFS становить 17403 * 4.5Mb = ~76.5Gb
З цієї причини, якщо користувач запустить 'fileys show space' після додавання одного диска на 200 Гб і створення екземпляра DDFS, він побачить, що файлова система DDFS має розмір лише 76,5 Гб:
Active Tier:
Розмір ресурсу GiB використовується GiB Avail GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 9.0 - - -
/data: post-comp 76.5 15.0 61.4 20% 1.1
/ddvar 49.2 1.3 45.4 3% -
/ddvar/core 158.5 0.7 149.7 0% -
---------------- -------- -------- --------- ---- --------------
Зверніть увагу, що накладні витрати на наступних дисках даних значно нижчі:
- Наступні диски не містять файлових систем
ext3- Метадані DDFS вже існують на першому диску, тому на наступних дисках
створюється дуже мало. Наприклад, припустимо, що ми додаємо другий диск на 100 Гб і розширюємо DDFS. На цьому диску зріз 5 буде передано драйверу RAID (як і на першому диску), а зріз 6, поки він все ще створений, розміром лише 4 Кб:
6 107 ГБ 107 ГБ 4096B основна
В результаті практично весь другий диск віддається в RAID (через зріз 5). Raid використовує 5.6% цього простору для ROL, а решту представляє DDFS - у наступному прикладі ~94.3Gb з 100Gb диска віддається DDFS для використання:
Array [ppart3] (активний): [Тип RAID 106] [(0x1, 0x30) опції] [NVR:N/N] [4608 КБ страйп] [197858304 секторів] [197858304 всього секторів]
[ДМ-2П5]
Цей простір розбивається на блоки по 1075838976 байт - в результаті система створює додаткові 93 блоки для використання DDFS:
FIXED NUM РОЗМІР БЛОКУ
РОЗМІР NAME РОЗМІР
БЛОКУYes 294779879424 274 1075838976 /.. /vpart:/vol1/col1
Так 294779879424 274 1075838976 /.. /vpart:/vol1/col1/cp1
No 22592618496 21 1075838976 /.. /vpart:/vol1/col1/cp1/cset
No 65626177536 61 1075838976 /.. /vpart:/vol1/col1/cp1/full_indices
No 22592618496 21 1075838976 /.. /vpart:/vol1/col1/cp1/partial_indices
No 1075838976 1 1075838976 /.. /vpart:/vol1/col1/cp1/summary.0
No 1075838976 1 1075838976 /.. /vpart:/vol1/col1/cp1/summary.1
No 2151677952 2 1075838976 /.. /vpart:/vol1/col1/cp_meta
No 10758389760 10 1075838976 /.. /vpart:/vol1/reserved_blocks
Зауважте, що оскільки всі файлові системи метаданих були вже створені на першому диску даних, лише один блок використовується для метаданих на другому диску (через файлову систему cp_meta). Решта простору надається CSET і вважається придатною для використання для звичайних контейнерів:
cm_attrs.max_containers=38379
...
cm_attrs.reserved_containers=2176
Зверніть увагу, що 38379 * 4.5Mb = ~168.7Gb:
Розмір ресурсу GiB використовується GiB Avail GiB Use% Cleanable GiB
---------------- -------- -------- --------- ---- -------------
/data: pre-comp - 0.0 - - -
/data: post-comp 168.7 0.1 168.6 0% 0.0
/ddvar 49.2 0.5 46.2 1% -
/ddvar/core 158.5 0.3 150.1 0% -
---------------- -------- -------- --------- ---- -------------
Це показує, що накладні витрати значно менші на всіх, крім першого, диску даних:
З першого диска на 200 Гб DDFS отримав 76,5 Гб корисного простору
З другого диска даних на 100 Гб DDFS отримав 92,2 Гб корисного простору
Ця тенденція зберігається для всіх наступних дисків даних.
Нарешті, слід зазначити, що метадані в DDFS (такі як індексні файлові системи) не є фіксованими за розміром. Залежно від завантаженості системи їм може знадобитися зростання, що забере корисний простір у CSET. Якщо це станеться, то корисний розмір CSET зменшиться. Це очікувано - загальний розмір CSET (і розмір файлової системи DDFS відповідно до 'fileys show space') не слід розглядати як статичне значення, навіть якщо розмір дисків з даними, що лежать в ньому, не змінюється.
- Розмір першого диска з даними повинен становити мінімум 200 Гб
- Усі наступні диски з даними повинні мати розмір
не менше 100 Гб. Причина, по якій розмір першого диска повинен бути мінімум 200 Гб, полягає в тому, що на цьому диску є значні накладні витрати, як описано нижче.
Припустимо, що диск з даними об'ємом 200 Гб представлений DDVE, доданий до активного рівня і використаний для створення екземпляра файлової системи DDFS. Фізичний диск буде використовуватися наступним чином:
Спочатку диск розділений на розділи, причому зріз 5 використовується для зберігання даних, а зріз 6 використовується для файлових систем ext3:
Модель: Невідомий (невідомий)
Диск /dev/dm-4: 200ГіБ
Розмір сектора (логічний/фізичний): 512B/512B
Таблиця розділів: Номер gpt
Початок Розмір кінця Файлова система Прапорці назв 1
0,00GiB 0,00GiB0,00GiB основний
2 0,00GiB 0,00GiB0,00GiB
основний 3 0,00GiB 0,01GiB основний
4 0,01GiB 0,01GiB 0,00GiB
5 0.01GiB 193GiB 193GiB основний <=== Використовується для зберігання
даних 6 193GiB 200GiB 6.77GiB основний <=== Використовується для ext3
В результаті ~193Gb дискового простору (фрагмент 5) буде надано драйверу RAID для використання.
Однак зауважте, що DDVE використовує концепцію RAID на LUN (ROL) для захисту від певних типів пошкодження даних (наприклад, пошкодження даних, яке не може бути виявлено/виправлено базовим масивом зберігання). ROL резервує приблизно 5,6% простору в зрізі 5 для інформації про парність. В результаті RAID зробить доступним лише ~182.3Gb для використання DDFS (як показано нижче - зверніть увагу, що розмір кожного сектора становить 512 байт):
Array [ppart2] (активний): [Тип RAID 106] [(0x1, 0x30) параметри] [NVR:N/N] [4608KB страйп] [382362624 секторів] [382362624 всього секторів]
[dm-4p5]
Простір ~182.3Gb, відведений DDFS, розбивається на блоки розміром 1075838976 байти - в результаті ми можемо створити 181 такий блок. Потім блоки розподіляються між різними файловими системами верхнього рівня в DDFS за потреби. Зверніть увагу, що при створенні нового екземпляра DDFS потрібно виділити значну кількість місця для метаданих, таких як індекс/вектор резюме/CP мета/зарезервовані блоки, файлові системи: ФІКСОВАНИЙ РОЗМІР БЛОКУ, РОЗМІР ЧИСЛА, ІМ'Я РОЗМІРУ БЛОКІВ,
194726854656 181 1075838976 /..
/vpart:/vol2/col1
Так 194726854656 181 1075838976 /.. /vpart:/vol2/col1/cp1
No 37654364160 21 1075838976 /.. /vpart:/vol2/col1/cp1/cset
No 65626177536 61 1075838976 /.. /vpart:/vol2/col1/cp1/full_indices
No 22592618496 21 1075838976 /.. /vpart:/vol2/col1/cp1/partial_indices
No 1075838976 1 1075838976 /.. /vpart:/vol2/col1/cp1/summary.0
No 1075838976 1 1075838976 /.. /vpart:/vol2/col1/cp1/summary.1
No 1075838976 1 1075838976 /.. /vpart:/vol2/col1/cp_meta
No 10758389760 10 1075838976 /.. /vpart:/vol2/reserved_blocks
Зверніть увагу, що все, крім контейнерного набору (CSET - де зберігаються дані користувача) споживає 95 * 1075838976 байтових блоків. В результаті залишається 86 блоків для потенційного використання CSET. Зверніть увагу, що 86 * 1075838976 байт = ~86.2Gb.
У CSET ми використовуємо дуже невелику кількість місця для метаданих, а потім оцінюємо, що можемо використовувати всі решту 1075838976 байтових блоків системи для створення контейнерів розміром 4,5 Мб. Якщо ми перевіримо метадані CSET, то побачимо:
cm_attrs.psize=4718592 <=== Кожен контейнер має розмір 4,5 Мб
...
cm_attrs.max_containers=17403 <=== Максимально можлива кількість 'придатних' контейнерів
...
cm_attrs.reserved_containers=2176 <=== Зарезервовані контейнери для внутрішніх операцій
Загальна кількість контейнерів, які можуть бути створені в рамках CSET, становить 17403 + 2176 = 19579
Кожен контейнер має розмір 4,5 Мб, тому 19579 контейнерів дорівнює 86.0 Гб дискового простору
. Зауважте, однак, що зарезервовані контейнери призначені лише для внутрішнього використання (за такими операціями, як очищення), тому не враховуються при відображенні використовуваного розміру файлової системи користувачам. У зв'язку з цим «використовуваний» розмір файлової системи DDFS становить 17403 * 4.5Mb = ~76.5Gb
З цієї причини, якщо користувач запустить 'fileys show space' після додавання одного диска на 200 Гб і створення екземпляра DDFS, він побачить, що файлова система DDFS має розмір лише 76,5 Гб:
Active Tier:
Розмір ресурсу GiB використовується GiB Avail GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 9.0 - - -
/data: post-comp 76.5 15.0 61.4 20% 1.1
/ddvar 49.2 1.3 45.4 3% -
/ddvar/core 158.5 0.7 149.7 0% -
---------------- -------- -------- --------- ---- --------------
Зверніть увагу, що накладні витрати на наступних дисках даних значно нижчі:
- Наступні диски не містять файлових систем
ext3- Метадані DDFS вже існують на першому диску, тому на наступних дисках
створюється дуже мало. Наприклад, припустимо, що ми додаємо другий диск на 100 Гб і розширюємо DDFS. На цьому диску зріз 5 буде передано драйверу RAID (як і на першому диску), а зріз 6, поки він все ще створений, розміром лише 4 Кб:
6 107 ГБ 107 ГБ 4096B основна
В результаті практично весь другий диск віддається в RAID (через зріз 5). Raid використовує 5.6% цього простору для ROL, а решту представляє DDFS - у наступному прикладі ~94.3Gb з 100Gb диска віддається DDFS для використання:
Array [ppart3] (активний): [Тип RAID 106] [(0x1, 0x30) опції] [NVR:N/N] [4608 КБ страйп] [197858304 секторів] [197858304 всього секторів]
[ДМ-2П5]
Цей простір розбивається на блоки по 1075838976 байт - в результаті система створює додаткові 93 блоки для використання DDFS:
FIXED NUM РОЗМІР БЛОКУ
РОЗМІР NAME РОЗМІР
БЛОКУYes 294779879424 274 1075838976 /.. /vpart:/vol1/col1
Так 294779879424 274 1075838976 /.. /vpart:/vol1/col1/cp1
No 22592618496 21 1075838976 /.. /vpart:/vol1/col1/cp1/cset
No 65626177536 61 1075838976 /.. /vpart:/vol1/col1/cp1/full_indices
No 22592618496 21 1075838976 /.. /vpart:/vol1/col1/cp1/partial_indices
No 1075838976 1 1075838976 /.. /vpart:/vol1/col1/cp1/summary.0
No 1075838976 1 1075838976 /.. /vpart:/vol1/col1/cp1/summary.1
No 2151677952 2 1075838976 /.. /vpart:/vol1/col1/cp_meta
No 10758389760 10 1075838976 /.. /vpart:/vol1/reserved_blocks
Зауважте, що оскільки всі файлові системи метаданих були вже створені на першому диску даних, лише один блок використовується для метаданих на другому диску (через файлову систему cp_meta). Решта простору надається CSET і вважається придатною для використання для звичайних контейнерів:
cm_attrs.max_containers=38379
...
cm_attrs.reserved_containers=2176
Зверніть увагу, що 38379 * 4.5Mb = ~168.7Gb:
Розмір ресурсу GiB використовується GiB Avail GiB Use% Cleanable GiB
---------------- -------- -------- --------- ---- -------------
/data: pre-comp - 0.0 - - -
/data: post-comp 168.7 0.1 168.6 0% 0.0
/ddvar 49.2 0.5 46.2 1% -
/ddvar/core 158.5 0.3 150.1 0% -
---------------- -------- -------- --------- ---- -------------
Це показує, що накладні витрати значно менші на всіх, крім першого, диску даних:
З першого диска на 200 Гб DDFS отримав 76,5 Гб корисного простору
З другого диска даних на 100 Гб DDFS отримав 92,2 Гб корисного простору
Ця тенденція зберігається для всіх наступних дисків даних.
Нарешті, слід зазначити, що метадані в DDFS (такі як індексні файлові системи) не є фіксованими за розміром. Залежно від завантаженості системи їм може знадобитися зростання, що забере корисний простір у CSET. Якщо це станеться, то корисний розмір CSET зменшиться. Це очікувано - загальний розмір CSET (і розмір файлової системи DDFS відповідно до 'fileys show space') не слід розглядати як статичне значення, навіть якщо розмір дисків з даними, що лежать в ньому, не змінюється.
Additional Information
Зверніть увагу, що інформація, що міститься в цій статті, дійсна з DDOS 5.7.30.0 і може змінитися в наступних випусках.
Affected Products
Data Domain Virtual EditionProducts
Data Domain, Data Domain Virtual EditionArticle Properties
Article Number: 000059680
Article Type: Solution
Last Modified: 05 Sep 2025
Version: 3
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.