Data Domain: Sådan beregnes den maksimale størrelse på diske, der kan føjes til det aktive niveau af en Data Domain Virtual Edition-enhed (DDVE)

Data Domain Virtual Edition (DDVE) er et nyt produkt, der fra og med DDOS 5.7 gør det muligt at implementere Data Domain Restorers (DDRs) som virtuelle maskiner i VMware ESXi- eller Microsoft Hyper-v-miljøer.

Når de er implementeret, skal datadiske føjes til det aktive niveau af DDVE-enheden, så de kan bruges til datastorage af DDFS (Data Domain File System). Bemærk, at den maksimalt mulige størrelse af DDFS på en DDVE-enhed bestemmes af begge:

• Konfigurationen af den virtuelle DDVE-maskine
• Størrelsen på den kapacitetslicens, der er føjet til DDVE-enheden

For eksempel er følgende DDVEs virtuelle maskine konfigureret således, at det er en 4TiB-enhed (dvs. medmindre CPU / RAM-konfigurationen ændres, kan denne virtuelle maskine aldrig understøtte et DDFS-filsystem, der er > 4TiB i størrelse):

# system vresource vis aktuel
...
Dette er en 4TiB-konfiguration – understøtter 0,5 TiB op til 4 TiB DDFS-kapacitet

(Data Domain Filesystem).Derudover har den en kapacitetslicens, der er 3.63TiB (dvs. den anvendelige størrelse af DDFS-filsystemet kan ikke overstige 3.63Tb):

sysadmin@localhost # elicense show
...
Kapacitetslicenser:
##   Funktionskapacitetstilstand Udløbsdato
-- -------- -------- --------------- ---------------
1 KAPACITET 3,63 TiB permanent (int) ikke relevant
-- -------- -------- --------------- ---------------

Bemærk dog, at noget af den plads på datadiske, der føjes til det aktive niveau i DDVE, bruges til interne data som f.eks.:

• DDFS-metadata
• Ext3-filsystemer
• ROL-paritetsoplysninger (RAID på LUN)

Disse data kaldes "overhead" og medregnes ikke i brugt/licenseret kapacitet. "Faste omkostninger" varierer afhængigt af størrelsen på det aktive niveau/systemkonfigurationen, og det kan derfor være vanskeligt at afgøre, hvor meget fysisk diskplads der skal føjes til det aktive niveau for at bruge al licenseret kapacitet – f.eks.:

• Hvis der føjes 3,63 TiB storage til det aktive niveau i ovenstående DDVE, og der oprettes et filsystem, vil filsystemets resulterende brugbare kapacitet være mindre end 3,63 TiB, hvilket efterlader en lille mængde ubrugt, men licenseret kapacitet.
• Hvis det omvendt er forsøgt at føje 4TiB-storage til det aktive niveau, kan DDVE muligvis angive en fejl, der angiver, at dette overstiger den licenserede kapacitet, og ikke tillade, at tilføjelsen fuldføres

Denne artikel beskriver, hvordan du bestemmer den maksimale størrelse af datadiske, der kan føjes til det aktive niveau af en DDVE-enhed ud fra system- og kapacitetslicensstørrelser.

Når der tilføjes kapacitet til det aktive niveau af en DDVE-enhed systemet, er det først nødvendigt at bestemme den maksimale understøttede kapacitet for det aktive niveau - dette vil enten være:

• DDVE-enhedens konfigurerede størrelse
• Den licenserede kapacitet for det aktive niveau (dvs. størrelsen på den installerede kapacitetslicens)

Den mindste af de to værdier skal bruges - for eksempel er følgende system en 4TiB-konfiguration med 3.63TiB licenseret kapacitet:

sysadmin@localhost # systemvresource viser aktuel
...
Dette er en 4TiB-konfiguration – understøtter 0,5 TiB op til 4 TiB DDFS-kapacitet

(Data Domain Filesystem).sysadmin@localhost# elicense show
...
Kapacitetslicenser:
##   Funktionskapacitetstilstand Udløbsdato
-- -------- -------- --------------- ---------------
1 KAPACITET 3,63 TiB permanent (int) ikke relevant
-- -------- -------- --------------- ---------------

Som følge heraf vil systemet have en maksimal aktiv niveaukapacitet/-størrelse på 3,63 TiB – dette benævnes i det følgende som "målkapacitet".

Ved hjælp af destinationskapaciteten og viden om, hvordan faste omkostninger for storage på aktivt niveau beregnes, er det muligt at bestemme den samlede diskstørrelse, der kan føjes til det aktive niveau for at bruge hele den licenserede kapacitet. Bemærk, at overhead genereres på to måder afhængigt af versionen af Data Domain Operating System (DDOS), der kører på enheden:

• Beregningsmæssige overhead (beregnet i DDOS 5.7 og 6.0):

• Procentvise faste omkostninger (beregnet i DDOS 6.0):

Da overhead er direkte afhængig af lagerstørrelse, er det desværre meget vanskeligt hurtigt at beregne mængden af disk, der kræves på et givet system for en given licenseret kapacitet. For at hjælpe med dette kan følgende to ligninger dog bruges:
Hvis du bruger DDOS 5.7, skal kun værdien ved hjælp af beregningsomkostninger beregnes

Hvis du bruger DDOS 6.0, skal både værdien ved hjælp af beregningsomkostninger og procentbaseret overhead beregnes, skal den største af de to anvendte

størrelser Bemærk, at for at sikre, at lageret er under maksimumgrænsen, skal alle beregnede værdier rundes ned - for eksempel hvis det beregnes, at lagring af størrelse 4.027TiB kan føjes til et system, dette: bør rundes ned til 4,02 TiB i stedet for rundet op til 4,03 TiB. Selv når dette er gjort, kan beregnede størrelser stadig være lidt større end systemets faktiske understøttede kapacitet (som beskrevet i følgende eksempler).

Eksempel 1:

Lad os i første omgang overveje ovenstående system - dette er konfigureret / licenseret som følger:

• DDOS-version: 6.0.0.20
• Målkapacitet (den mindste af licenserede kapaciteter og systemkonfigurationer): 3,63 TiB (3717 GiB)
• DDFS-metadatastørrelse (til 4TiB-konfiguration): 107 GiB

Lagerstørrelse til brug af al målkapacitet kan beregnes på følgende måde – bemærk, at da dette er DDOS 6.0, skal der anvendes både beregningsmæssige og procentbaserede beregninger:
3621 GiB (3,53 TiB) er den største af de to beregnede størrelser, og det er derfor den maksimale storagestørrelse, der kan føjes til systemets aktive niveau. I praksis kunne der maksimalt tilføjes 3,53TiB til et sådant system.

Eksempel 2:

En DDVE-enhed, der kører 6.0.0.20, er klargjort, som er en 8TiB-konfiguration og har en licenseret aktiv niveaukapacitet på 5,45TiB:

sysadmin@localhost# systemvresource vis aktuel
...
Dette er en 8TiB-konfiguration – understøtter 0,5 TiB op til 8 TiB DDFS-kapacitet

(Data Domain Filesystem).sysadmin@localhost# elicense show
...
Kapacitetslicenser:
##   Funktionskapacitetstilstand Udløbsdato
-- -------- -------- --------------- ---------------
1 KAPACITET 5,45 TiB permanent (int) ikke relevant
-- -------- -------- --------------- ---------------

Som følge heraf:

• DDOS-version: 6.0.0.20
• Målkapacitet (den mindste af licenserede kapaciteter og systemkonfigurationer): 5,45 TiB (5580 GiB)
• DDFS-metadatastørrelse (til 8TiB-konfiguration): 109 GiB

Lagerstørrelse til brug af al målkapacitet kan beregnes på følgende måde – bemærk, at da dette er DDOS 6.0, skal der anvendes både beregningsmæssige og procentbaserede beregninger:
5381 GiB (5,25 TiB) er den største af de to beregnede størrelser. Det er derfor den maksimale storagestørrelse, der kan føjes til systemets aktive niveau. I praksis kunne der maksimalt tilføjes 6,06TiB til et sådant system.

Eksempel 3:

En DDVE-enhed, der kører 6.0.0.20, er klargjort, som er en 4TiB-konfiguration og har en licenseret aktiv niveaukapacitet på 0,90TiB:

sysadmin@localhost# systemvresource vis aktuel
...
Dette er en 4TiB-konfiguration – understøtter 0,5 TiB op til 4 TiB DDFS-kapacitet

(Data Domain Filesystem).sysadmin@localhost# elicense show
...
Kapacitetslicenser:
##   Funktionskapacitetstilstand Udløbsdato
-- -------- -------- --------------- ---------------
1 KAPACITET 0,90 TiB permanent (int) ikke relevant
-- -------- -------- --------------- ---------------

Som følge heraf:

• DDOS-version: 6.0.0.20
• Målkapacitet (den mindste af licenserede kapaciteter og systemkonfigurationer): 0,90 TiB (921 GiB)
• DDFS-metadatastørrelse (til 8TiB-konfiguration): 107 GiB

Lagerstørrelse til brug af al målkapacitet kan beregnes på følgende måde – bemærk, at da dette er DDOS 6.0, skal der anvendes både beregningsmæssige og procentbaserede beregninger:
 
981 GiB (0,95 TiB) er den største af de to beregnede størrelser. Dette er derfor den maksimale storagestørrelse, der kan føjes til systemets aktive niveau. I praksis kunne der maksimalt tilføjes 0,95TiB til et sådant system.

Eksempel 4:

En DDVE-enhed kører 5.7, er konfigureret som en 8TiB-konfiguration og har en licenseret kapacitet på 7.28TiB:

sysadmin@localhost# systemvresource vis aktuel
...
Dette er en 8TiB-konfiguration – understøtter 0,5 TiB op til 8 TiB DDFS-kapacitet

(Data Domain Filesystem).sysadmin@localhost# elicense show
...
Kapacitetslicenser:
##   Funktionskapacitetstilstand Udløbsdato
-- -------- -------- --------------- ---------------
1 KAPACITET 7,28 TiB permanent (int) ikke relevant
-- -------- -------- --------------- ---------------

Som følge heraf:

• DDOS-version: 5.7.32.0
• Målkapacitet (den mindste af licenserede kapaciteter og systemkonfigurationer): 7,28 TiB (7454 GiB)
• DDFS-metadatastørrelse (til 4TiB-konfiguration): 104 GiB

Da denne DDVE kører DDOS 5.7, er det kun nødvendigt at beregne den storagestørrelse, der stammer fra beregningsomkostninger:
 
7146,24 GiB (6,97 TiB) er den maksimale storagestørrelse, der kan føjes til systemets aktive niveau. I praksis kunne der maksimalt tilføjes 7,82 TiB lagerplads til et sådant system (dvs. den beregnede størrelse skulle reduceres en smule for at gøre det muligt at tilføje lagerplads).

Hvis de beregnede storagestørrelser stadig er for store til systemkonfigurationen/den licenserede kapacitet, vises en fejl som følgende, når storage føjes til det aktive niveau:

sysadmin@localhost# storage add dev9
Kontrollerer storagekrav...
Kunne ikke tilføje lager: Systemkapaciteten overstiger den grænse, der er tilladt i licensen.

I dette tilfælde er det nødvendigt at reducere størrelsen af klargjort storage i den underliggende hypervisor med en lille mængde (f.eks. 0,01TiB). Når det er gjort, bør DDVE-enheden tvinges til at scanne klargjort storage igen, og "storage add" skal forsøges igen, hvorefter det bør lykkes:
 
Bemærk også, at størrelsen af DDFS-metadata/ext3-filsystemer kan ændre sig i fremtidige versioner. Hvis dette sker, opdateres dette dokument efter behov.

Hvis du har brug for hjælp til proceduren/beregningerne, som er beskrevet i dette dokument, bedes du kontakte den supportudbyder, du har indgået kontrakt med.