Data Domain: Så här beräknar du den maximala storleken på diskar som kan läggas till i den aktiva nivån för en Data Domain Virtual Edition-enhet (DDVE)

Data Domain Virtual Edition (DDVE) är en ny produkt som från och med DDOS 5.7 gör det möjligt att driftsätta Data Domain Restorers (DDR) som virtuella maskiner i VMware ESXi- eller Microsoft Hyper-v-miljöer.

När datadiskarna har distribuerats måste de läggas till på den aktiva nivån för DDVE-enheten som ska användas för datalagring av Data Domain File System (DDFS). Observera att den största möjliga storleken på DDFS på en DDVE-enhet bestäms av både:

• Konfigurationen av den virtuella DDVE-datorn
• Storleken på kapacitetslicensen som lagts till för DDVE-enheten

Till exempel är följande virtuella DDVEs-maskin konfigurerad så att den är en 4TiB-enhet (dvs. om inte CPU/RAM-konfigurationen ändras kan den här virtuella maskinen aldrig stödja ett DDFS-filsystem som är > 4TiB stort):

# system vresource show current
...
Det här är en 4 TiB-konfiguration med stöd för 0,5 TiB upp till 4 TiB DDFS-kapacitet (Data Domain Filesystem).

Dessutom har den en kapacitetslicens som är 3.63TiB (dvs. den användbara storleken på DDFS-filsystemet får inte överstiga 3.63Tb):

sysadmin@localhost# elicense show
...
Kapacitetslicenser:
##   Förfallodatum
för funktionskapacitetsläge-- -------- -------- --------------- ---------------
1 KAPACITET 3,63 TiB permanent (int) n/a
-- -------- -------- --------------- ---------------

Observera dock att en del av utrymmet på datadiskar som läggs till i den aktiva nivån för DDVE används för interna data som:

• DDFS-metadata
• Ext3-filsystem
• Paritetsinformation för RAID på LUN (ROL)

Dessa data kallas "omkostnader" och räknas inte in i använd/licensierad kapacitet. "Omkostnader" varierar beroende på den aktiva nivåns storlek/systemkonfiguration, och därför kan det vara svårt att avgöra hur mycket fysiskt diskutrymme som ska läggas till på den aktiva nivån för att använda all licensierad kapacitet, till exempel:

• Om 3,63 TiB lagringsutrymme läggs till den aktiva nivån för ovanstående DDVE och ett filsystem skapas blir den resulterande användbara kapaciteten för filsystemet mindre än 3,63 TiB, vilket lämnar en liten mängd oanvänd men licensierad kapacitet
• Omvänt, om man försöker lägga till 4TiB-lagring på den aktiva nivån kan DDVE få ett fel som anger att detta överskrider den licensierade kapaciteten och inte tillåter att tillägget slutförs

Den här artikeln beskriver hur du fastställer den maximala storleken på datadiskar som kan läggas till på den aktiva nivån för en DDVE-enhet givet system- och kapacitetslicensstorlekar.

När du lägger till kapacitet till den aktiva nivån för en DDVE-enhet är det nödvändigt att först fastställa den maximala kapacitet som stöds för den aktiva nivån – detta kommer antingen att vara:

• Den konfigurerade storleken på DDVE-enheten
• Den licensierade kapaciteten för den aktiva nivån (dvs. storleken på den installerade kapacitetslicensen)

Det mindre av de två värdena ska användas, till exempel är följande system en 4TiB-konfiguration med 3,63 TiB-licensierad kapacitet:

sysadmin@localhost# system vresource show current
...
Det här är en 4 TiB-konfiguration med stöd för 0,5 TiB upp till 4 TiB DDFS-kapacitet (Data Domain Filesystem).

sysadmin@localhost# e-licens visa
...
Kapacitetslicenser:
##   Förfallodatum
för funktionskapacitetsläge-- -------- -------- --------------- ---------------1 KAPACITET:
3,63 TiB permanent (int) n/a
-- -------- -------- --------------- ---------------

Som ett resultat av detta kommer systemet att ha maximal kapacitet/storlek på aktiv nivå på 3,63TiB – detta kallas nedan för "målkapacitet".

Med hjälp av målkapaciteten och kunskap om hur omkostnaderna för lagring på aktiv nivå beräknas är det möjligt att fastställa den totala storleken på disken som kan läggas till på den aktiva nivån för att använda all licensierad kapacitet. Observera att omkostnader genereras på två sätt beroende på vilken version av Data Domain-operativsystemet (DDOS) som körs på enheten:

• Beräkningskostnader (beräknade i DDOS 5.7 och 6.0):

• Procentuella omkostnader (beräknat i DDOS 6.0):

Eftersom overheadkostnaderna är direkt beroende av lagringens storlek är det tyvärr mycket svårt att snabbt beräkna mängden disk som krävs på ett visst system för en viss licensierad kapacitet. För att hjälpa till med detta kan dock följande två ekvationer användas:
Om du använder DDOS 5.7 ska endast det värde som använder beräkningskostnader beräknas

. Om du använder DDOS 6.0 ska både värdet som använder beräkningskostnader och procentbaserade omkostnader beräknas, då ska den större av de två storlekarna som används

Observera att för att säkerställa att lagringen ligger under maxgränsen ska alla beräknade värden avrundas nedåt – till exempel om det beräknas att lagring med storleken 4,027TiB kan läggas till i ett system kan detta ska avrundas nedåt till 4,02TiB i stället för att avrundas uppåt till 4,03TiB. Även när detta är gjort kan beräknade storlekar fortfarande vara något större än systemets faktiska kapacitet som stöds (enligt beskrivningen i följande exempel).

Exempel 1:

Låt oss först överväga ovanstående system - detta konfigureras/licensieras enligt följande:

• DDOS-version: 6.0.0.20
• Målkapacitet (den minsta av licensierad kapacitet och systemkonfiguration): 3,63 TiB (3717GiB)
• DDFS-metadatastorlek (för 4TiB-konfiguration): 107GiB

Lagringsstorlek för att använda all målkapacitet kan beräknas på följande sätt. Observera att eftersom det här är DDOS 6.0 bör både beräkningsbaserade och procentbaserade beräkningar användas:
3621GiB (3,53TiB) är den större av de två beräknade storlekarna, och därför är detta den maximala lagringsstorleken som kan läggas till i systemets aktiva nivå. I praktiken kunde maximalt 3,53 TiB läggas till i ett sådant system.

Exempel 2:

En DDVE-enhet som kör 6.0.0.20 etableras som är en 8TiB-konfiguration och har en licensierad active tier-kapacitet på 5.45TiB:

sysadmin@localhost# system vresource show current
...
Det här är en 8 TiB-konfiguration med stöd för 0,5 TiB upp till 8 TiB DDFS-kapacitet (Data Domain Filesystem).

sysadmin@localhost# eLicense show
...
Kapacitetslicenser:
##   Förfallodatum för
funktionskapacitetsläge-- -------- -------- --------------- ---------------
1 KAPACITET 5,45 TiB permanent (int) n/a
-- -------- -------- --------------- ---------------

Som ett resultat:

• DDOS-version: 6.0.0.20
• Målkapacitet (den minsta av licensierad kapacitet och systemkonfiguration): 5,45 TiB (5580GiB)
• DDFS-metadatastorlek (för konfiguration med 8 TiB): 109GiB

Lagringsstorlek för att använda all målkapacitet kan beräknas på följande sätt. Observera att eftersom det här är DDOS 6.0 bör både beräkningsbaserade och procentbaserade beräkningar användas:
5381GiB (5,25TiB) är den större av de två beräknade storlekarna, och därför är det här den maximala lagringsstorleken som kan läggas till i den aktiva nivån i det här systemet. I praktiken kunde maximalt 6,06 TiB läggas till i ett sådant system.

Exempel 3:

En DDVE-enhet som kör 6.0.0.20 etableras som är en 4TiB-konfiguration och har en licensierad active tier-kapacitet på 0.90TiB:

sysadmin@localhost# system vresource show current
...
Det här är en 4 TiB-konfiguration med stöd för 0,5 TiB upp till 4 TiB DDFS-kapacitet (Data Domain Filesystem).

sysadmin@localhost# e-licens visa
...
Kapacitetslicenser:
##   Förfallodatum för
funktionskapacitetsläge-- -------- -------- --------------- ---------------
1 KAPACITET 0,90 TiB permanent (heltal) ej tillämpligt
-- -------- -------- --------------- ---------------

Som ett resultat:

• DDOS-version: 6.0.0.20
• Målkapacitet (den minsta av licensierad kapacitet och systemkonfiguration): 0,90TiB (921GiB)
• DDFS-metadatastorlek (för konfiguration med 8 TiB): 107GiB

Lagringsstorlek för att använda all målkapacitet kan beräknas på följande sätt. Observera att eftersom det här är DDOS 6.0 bör både beräkningsbaserade och procentbaserade beräkningar användas:
 
981GiB (0,95TiB) är den större av de två beräknade storlekarna, och därför är detta den maximala lagringsstorleken som kan läggas till i den aktiva nivån i det här systemet. I praktiken kunde maximalt 0,95 TiB läggas till i ett sådant system.

Exempel 4:

En DDVE-enhet kör 5.7, är konfigurerad som en 8TiB-konfiguration och har en licensierad kapacitet på 7.28TiB:

sysadmin@localhost# system vresource show current
...
Det här är en 8 TiB-konfiguration med stöd för 0,5 TiB upp till 8 TiB DDFS-kapacitet (Data Domain Filesystem).

sysadmin@localhost# e-licens visa
...
Kapacitetslicenser:
##   Utgångsdatum för
funktionskapacitetsläge-- -------- -------- --------------- ---------------
1 KAPACITET 7,28 TiB permanent (int) n/a
-- -------- -------- --------------- ---------------

Som ett resultat:

• DDOS-version: 5.7.32.0
• Målkapacitet (den minsta av licensierad kapacitet och systemkonfiguration): 7,28 TiB (7454 GiB)
• DDFS-metadatastorlek (för 4TiB-konfiguration): 104GiB

Eftersom denna DDVE kör DDOS 5.7 behöver endast lagringsstorleken som härleds från beräkningsutrymmet beräknas:
 
7146,24 GiB (6,97 TiB) är den maximala lagringsstorleken som kan läggas till i systemets aktiva nivå. I praktiken kunde maximalt 7,82 TiB lagringsutrymme läggas till i ett sådant system (dvs. den beräknade storleken måste minskas något för att lagring skulle kunna läggas till).

Om de beräknade lagringsstorlekarna fortfarande är för stora för systemkonfigurationen/den licensierade kapaciteten visas följande fel när lagring läggs till på den aktiva nivån:

sysadmin@localhost# storage add dev9
Kontrollerar lagringskrav ...
Det gick inte att lägga till lagring: systemkapaciteten överskrider den gräns som tillåts av licensen.

I det här fallet är det nödvändigt att minska storleken på det etablerade lagringsutrymmet i det underliggande hypervisor-programmet med en liten mängd (till exempel 0,01TiB). När det är klart bör DDVE-enheten tvingas att genomsöka det etablerade lagringsutrymmet igen och det görs ett nytt försök att lägga till lagring, varefter det bör lyckas:
 
Observera också att storleken på DDFS-metadata/ext3-filsystem kan ändras i framtida versioner. Om detta händer kommer detta dokument att uppdateras vid behov.

Om du behöver hjälp med proceduren/beräkningarna som beskrivs i det här dokumentet kan du kontakta din kontrakterade supportleverantör.