Data Domain Virtual Edition: Objaśnienie wykorzystania miejsca na dysku danych w Data Domain Virtual Edition (DDVE)
Summary: Objaśnienie wykorzystania miejsca na dysku danych w 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) to nowy produkt umożliwiający wdrożenie Data Domain Restorer (DDR) w środowisku wirtualnym. Po zakończeniu wdrożenia trzeba przydzielić dyski danych do wykorzystania przez system plików DDFS w DDVE. W tym artykule wyjaśniono, jak jest używane miejsce fizyczne na tych dyskach danych i dlaczego użyteczne miejsce w systemie plików DDFS może być znacznie mniejsze niż łączny rozmiar wszystkich dysków danych.
Resolution
Podczas dodawania dysków danych do instancji DDVE należy przestrzegać pewnych zasad dotyczących pojemności:
— Pierwszy dodany dysk danych musi mieć rozmiar co najmniej 200 GB
— Wszystkie kolejne dyski danych muszą mieć rozmiar co najmniej 100 GB
. Powodem, dla którego pierwszy dysk musi mieć rozmiar co najmniej 200 GB, jest znaczne obciążenie tego dysku, jak opisano poniżej.
Załóżmy, że dysk danych o pojemności 200 GB jest prezentowany DDVE, dodawany do warstwy aktywnej i używany do tworzenia instancji systemu plików DDFS. Dysk fizyczny będzie używany w następujący sposób:
Początkowo dysk jest podzielony na partycje, gdzie część 5 służy do przechowywania danych, a część 6 jest przeznaczona dla systemów plików ext3:
Model: Unknown (unknown)
Disk /dev/dm-4: 200GiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 0.00GiB 0.00GiB 0.00GiB primary
2 0.00GiB 0.00GiB 0.00GiB primary
3 0.00GiB 0.01GiB 0.01GiB primary
4 0.01GiB 0.01GiB 0.00GiB primary
5 0.01GiB 193GiB 193GiB primary <=== Used for data storage
6 193GiB 200GiB 6.77GiB primary <=== Used for ext3
W rezultacie ~193 GB miejsca na dysku (część 5) zostanie przekazane do użytku sterownikowi RAID.
Należy jednak pamiętać, że rozwiązanie DDVE wykorzystuje koncepcję RAID on LUN (ROL) w celu ochrony przed niektórymi typami uszkodzeń danych (na przykład uszkodzeniami danych, których podstawowa macierz pamięci masowej nie może wykryć/naprawić). ROL rezerwuje około 5,6% miejsca w części 5 na informacje o parzystości. W rezultacie macierz RAID udostępni tylko ~182,3 GB do użytku dla DDFS (jak pokazano poniżej — zauważ, że każdy sektor ma rozmiar 512 bajtów):
Array [ppart2] (active): [raid-type 106] [(0x1, 0x30) options] [NVR:N/N] [4608KB stripe] [382362624 sectors] [382362624 total sectors]
[dm-4p5]
Przestrzeń ~182,3 GB przyznana DDFS jest podzielona na bloki o wielkości 1075838976 bajtów — w rezultacie możemy utworzyć 181 takich bloków. Bloki są następnie przydzielane zgodnie z wymaganiami do różnych systemów plików wyższego poziomu w DDFS. Należy pamiętać, że podczas tworzenia nowej instancji DDFS trzeba przeznaczyć znaczną ilość miejsca na metadane, takie jak indeks/wektor podsumowania /meta / systemy plików zarezerwowanych bloków:
FIXED NUM BLOCK
SIZE SIZE BLOCKS SIZE NAME
Yes 194726854656 181 1075838976 /../vpart:/vol2/col1
Yes 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
Trzeba pamiętać, że wszystko inne niż zestaw kontenerów (CSET — gdzie przechowywane są dane użytkownika) zużywa 95 bloków po 1075838976 bajtów. W rezultacie pozostaje 86 bloków do potencjalnego wykorzystania przez CSET. Trzeba zauważyć, że 86 * 1075838976 bajtów = ~86,2 GB.
W CSET używamy bardzo małej ilości miejsca na metadane, a następnie szacujemy, że możemy wykorzystać wszystkie pozostałe bloki po 1075838976 bajtów w systemie do tworzenia kontenerów 4,5 MB. Jeśli sprawdzimy metadane CSET, zobaczymy, że:
cm_attrs.psize=4718592 <=== Each container is 4.5Mb
...
cm_attrs.max_containers=17403 <=== Maximum possible number of 'usable' containers
...
cm_attrs.reserved_containers=2176 <=== Reserved containers for internal operations
Całkowita liczba kontenerów, które można utworzyć w ramach CSET wynosi 17403 + 2176 = 19579
Każdy kontener ma rozmiar 4,5 MB, więc 19579 kontenerów odpowiada 86,0 GB miejsca na dysku.
Należy jednak pamiętać, że zarezerwowane kontenery są przeznaczone tylko do użytku wewnętrznego (przez operacje takie jak czyszczenie), więc nie są brane pod uwagę podczas wyświetlania użytkownikom użytecznego rozmiaru systemu plików. Z tego powodu „użyteczny” rozmiar systemu plików DDFS wynosi 17403 * 4,5 MB = ~ 76,5 GB
Z tego powodu, jeśli użytkownik uruchomi polecenie „filesys show space” po dodaniu jednego dysku 200 GB i utworzeniu instancji DDFS, zobaczy, że system plików DDFS ma rozmiar tylko 76,5 GB:
Active Tier:
Resource Size GiB Used 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% -
---------------- -------- -------- --------- ---- --------------
Należy pamiętać, że obciążenia kolejnych dysków danych są znacznie niższe:
— Kolejne dyski nie przechowują systemów plików ext3
— Metadane DDFS już istnieją na pierwszym dysku, więc bardzo mało takich danych jest tworzonych na kolejnych dyskach.
Załóżmy na przykład, że dodamy drugi dysk 100 GB i rozszerzymy DDFS. Na tym dysku część 5 zostanie przekazana sterownikowi RAID (tak jak na pierwszym dysku), ale część 6, choć nadal zostaje utworzony, będzie miał tylko rozmiar 4 KB:
6 107GB 107GB 4096B primary
W rezultacie praktycznie cały drugi dysk jest przekazywany RAID (poprzez część 5). RAID wykorzystuje 5,6% tego miejsca dla ROL, a następnie przedstawia resztę DDFS — w poniższym przykładzie ~94,3 GB z dysku 100 GB jest przekazywane DDFS do użytku:
Array [ppart3] (active): [raid-type 106] [(0x1, 0x30) options] [NVR:N/N] [4608KB stripe] [197858304 sectors] [197858304 total sectors]
[dm-2p5]
Ta przestrzeń jest podzielona na bloki 1075838976 bajtów — w rezultacie system tworzy dodatkowe 93 bloki do wykorzystania przez DDFS:
FIXED NUM BLOCK
SIZE SIZE BLOCKS SIZE NAME
Yes 294779879424 274 1075838976 /../vpart:/vol1/col1
Yes 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
Trzeba zauważyć, że ponieważ wszystkie systemy plików metadanych zostały utworzone na pierwszym dysku danych, tylko jeden blok jest używany do metadanych na drugim dysku (poprzez system plików cp_meta). Pozostałe miejsce jest udostępniane CSET i jest uważane za użyteczne dla normalnych kontenerów:
cm_attrs.max_containers=38379
...
cm_attrs.reserved_containers=2176
Należy zauważyć, że 38379 * 4,5 MB = ~168,7 GB:
Resource Size GiB Used 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% -
---------------- -------- -------- --------- ---- -------------
To pokazuje że obciążenia są znacznie mniejsze na wszystkich dyskach danych z wyjątkiem pierwszego:
Z pierwszego dysku 200 GB DDFS uzyskał 76,5 GB przestrzeni użytkowej.
Z drugiego dysku danych 100 GB DDFS uzyskał 92,2 GB przestrzeni użytkowej.
Ten trend jest kontynuowany dla wszystkich kolejnych dysków danych.
Na koniec należy zauważyć, że metadane w DDFS (takie jak systemy plików indeksu) nie mają stałego rozmiaru. W zależności od obciążenia systemu może zajść potrzeba ich rozbudowania, co zabierze użyteczną przestrzeń z CSET. Jeśli tak się stanie, użyteczny rozmiar CSET się zmniejszy. Jest to efekt oczekiwany — całkowity rozmiar CSET (i rozmiaru systemu plików DDFS zgodnie z „filesys show space”) nie należy traktować jako wartości statycznej, nawet jeśli rozmiar bazowych dysków danych się nie zmienia.
— Pierwszy dodany dysk danych musi mieć rozmiar co najmniej 200 GB
— Wszystkie kolejne dyski danych muszą mieć rozmiar co najmniej 100 GB
. Powodem, dla którego pierwszy dysk musi mieć rozmiar co najmniej 200 GB, jest znaczne obciążenie tego dysku, jak opisano poniżej.
Załóżmy, że dysk danych o pojemności 200 GB jest prezentowany DDVE, dodawany do warstwy aktywnej i używany do tworzenia instancji systemu plików DDFS. Dysk fizyczny będzie używany w następujący sposób:
Początkowo dysk jest podzielony na partycje, gdzie część 5 służy do przechowywania danych, a część 6 jest przeznaczona dla systemów plików ext3:
Model: Unknown (unknown)
Disk /dev/dm-4: 200GiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 0.00GiB 0.00GiB 0.00GiB primary
2 0.00GiB 0.00GiB 0.00GiB primary
3 0.00GiB 0.01GiB 0.01GiB primary
4 0.01GiB 0.01GiB 0.00GiB primary
5 0.01GiB 193GiB 193GiB primary <=== Used for data storage
6 193GiB 200GiB 6.77GiB primary <=== Used for ext3
W rezultacie ~193 GB miejsca na dysku (część 5) zostanie przekazane do użytku sterownikowi RAID.
Należy jednak pamiętać, że rozwiązanie DDVE wykorzystuje koncepcję RAID on LUN (ROL) w celu ochrony przed niektórymi typami uszkodzeń danych (na przykład uszkodzeniami danych, których podstawowa macierz pamięci masowej nie może wykryć/naprawić). ROL rezerwuje około 5,6% miejsca w części 5 na informacje o parzystości. W rezultacie macierz RAID udostępni tylko ~182,3 GB do użytku dla DDFS (jak pokazano poniżej — zauważ, że każdy sektor ma rozmiar 512 bajtów):
Array [ppart2] (active): [raid-type 106] [(0x1, 0x30) options] [NVR:N/N] [4608KB stripe] [382362624 sectors] [382362624 total sectors]
[dm-4p5]
Przestrzeń ~182,3 GB przyznana DDFS jest podzielona na bloki o wielkości 1075838976 bajtów — w rezultacie możemy utworzyć 181 takich bloków. Bloki są następnie przydzielane zgodnie z wymaganiami do różnych systemów plików wyższego poziomu w DDFS. Należy pamiętać, że podczas tworzenia nowej instancji DDFS trzeba przeznaczyć znaczną ilość miejsca na metadane, takie jak indeks/wektor podsumowania /meta / systemy plików zarezerwowanych bloków:
FIXED NUM BLOCK
SIZE SIZE BLOCKS SIZE NAME
Yes 194726854656 181 1075838976 /../vpart:/vol2/col1
Yes 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
Trzeba pamiętać, że wszystko inne niż zestaw kontenerów (CSET — gdzie przechowywane są dane użytkownika) zużywa 95 bloków po 1075838976 bajtów. W rezultacie pozostaje 86 bloków do potencjalnego wykorzystania przez CSET. Trzeba zauważyć, że 86 * 1075838976 bajtów = ~86,2 GB.
W CSET używamy bardzo małej ilości miejsca na metadane, a następnie szacujemy, że możemy wykorzystać wszystkie pozostałe bloki po 1075838976 bajtów w systemie do tworzenia kontenerów 4,5 MB. Jeśli sprawdzimy metadane CSET, zobaczymy, że:
cm_attrs.psize=4718592 <=== Each container is 4.5Mb
...
cm_attrs.max_containers=17403 <=== Maximum possible number of 'usable' containers
...
cm_attrs.reserved_containers=2176 <=== Reserved containers for internal operations
Całkowita liczba kontenerów, które można utworzyć w ramach CSET wynosi 17403 + 2176 = 19579
Każdy kontener ma rozmiar 4,5 MB, więc 19579 kontenerów odpowiada 86,0 GB miejsca na dysku.
Należy jednak pamiętać, że zarezerwowane kontenery są przeznaczone tylko do użytku wewnętrznego (przez operacje takie jak czyszczenie), więc nie są brane pod uwagę podczas wyświetlania użytkownikom użytecznego rozmiaru systemu plików. Z tego powodu „użyteczny” rozmiar systemu plików DDFS wynosi 17403 * 4,5 MB = ~ 76,5 GB
Z tego powodu, jeśli użytkownik uruchomi polecenie „filesys show space” po dodaniu jednego dysku 200 GB i utworzeniu instancji DDFS, zobaczy, że system plików DDFS ma rozmiar tylko 76,5 GB:
Active Tier:
Resource Size GiB Used 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% -
---------------- -------- -------- --------- ---- --------------
Należy pamiętać, że obciążenia kolejnych dysków danych są znacznie niższe:
— Kolejne dyski nie przechowują systemów plików ext3
— Metadane DDFS już istnieją na pierwszym dysku, więc bardzo mało takich danych jest tworzonych na kolejnych dyskach.
Załóżmy na przykład, że dodamy drugi dysk 100 GB i rozszerzymy DDFS. Na tym dysku część 5 zostanie przekazana sterownikowi RAID (tak jak na pierwszym dysku), ale część 6, choć nadal zostaje utworzony, będzie miał tylko rozmiar 4 KB:
6 107GB 107GB 4096B primary
W rezultacie praktycznie cały drugi dysk jest przekazywany RAID (poprzez część 5). RAID wykorzystuje 5,6% tego miejsca dla ROL, a następnie przedstawia resztę DDFS — w poniższym przykładzie ~94,3 GB z dysku 100 GB jest przekazywane DDFS do użytku:
Array [ppart3] (active): [raid-type 106] [(0x1, 0x30) options] [NVR:N/N] [4608KB stripe] [197858304 sectors] [197858304 total sectors]
[dm-2p5]
Ta przestrzeń jest podzielona na bloki 1075838976 bajtów — w rezultacie system tworzy dodatkowe 93 bloki do wykorzystania przez DDFS:
FIXED NUM BLOCK
SIZE SIZE BLOCKS SIZE NAME
Yes 294779879424 274 1075838976 /../vpart:/vol1/col1
Yes 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
Trzeba zauważyć, że ponieważ wszystkie systemy plików metadanych zostały utworzone na pierwszym dysku danych, tylko jeden blok jest używany do metadanych na drugim dysku (poprzez system plików cp_meta). Pozostałe miejsce jest udostępniane CSET i jest uważane za użyteczne dla normalnych kontenerów:
cm_attrs.max_containers=38379
...
cm_attrs.reserved_containers=2176
Należy zauważyć, że 38379 * 4,5 MB = ~168,7 GB:
Resource Size GiB Used 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% -
---------------- -------- -------- --------- ---- -------------
To pokazuje że obciążenia są znacznie mniejsze na wszystkich dyskach danych z wyjątkiem pierwszego:
Z pierwszego dysku 200 GB DDFS uzyskał 76,5 GB przestrzeni użytkowej.
Z drugiego dysku danych 100 GB DDFS uzyskał 92,2 GB przestrzeni użytkowej.
Ten trend jest kontynuowany dla wszystkich kolejnych dysków danych.
Na koniec należy zauważyć, że metadane w DDFS (takie jak systemy plików indeksu) nie mają stałego rozmiaru. W zależności od obciążenia systemu może zajść potrzeba ich rozbudowania, co zabierze użyteczną przestrzeń z CSET. Jeśli tak się stanie, użyteczny rozmiar CSET się zmniejszy. Jest to efekt oczekiwany — całkowity rozmiar CSET (i rozmiaru systemu plików DDFS zgodnie z „filesys show space”) nie należy traktować jako wartości statycznej, nawet jeśli rozmiar bazowych dysków danych się nie zmienia.
Additional Information
Należy pamiętać, że informacje zawarte w tym artykule są aktualne w wersji DDOS 5.7.30.0 i mogą ulec zmianie w kolejnych wydaniach.
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.