A netapp tömb nyersanyagának felhasználható helyének kiszámítása,

Tehát, van egy rendszer tárolási (NAS), amely két vezérlők 3220, öt polcok 24 meghajtó egyes, kerekek 600 GB SAS 10K RPM, FlashCache 1TB (a 512M vezérlő), a nyers kapacitása a rendszer 5 x 24 x 0, 6 = 72 TB.

A tároló a VMware virtualizációs rendszert fog elhelyezni, az egyszerűség kedvéért az NFS-nél, és nem zavarja a LUN és a VMFS tartalékait.

A netapp alkalmazásban lévő lemezek sajátosságaival összefüggésben, figyelembe véve, hogy virtualizációt fogunk biztosítani, a vezérlők terhelésének párhuzamozása érdekében a lemezek teljes tömegét félig osztjuk fel, és mindegyik felét a vezérlő tulajdonába adjuk. Minden egyes vezérlőhöz összesen 60 lemezt kap.

Kiderül. 18 950GB, hát, 19TB / vezérlő, 19 x 2 = 38TB tömbenként. Ez a nyers kapacitás 53% -a. És ha figyelembe vesszük azt a tényt, hogy a 100% -os teljes tömeg nem fog működni, úgy gondoljuk, hogy a maximális kihasználtsága, amelyen még mindig gyors lesz, körülbelül 80%. tényleg az Ön rendelkezésére áll 30,4 TB, a nyers kapacitás 42% -a.

Továbbá, ha nincs NFS, LUN és VMFS, akkor le kell vonni a felsőtestet ebben az esetben (nincs semmi LUN, semmi, a VMFS-en - 10%).

45,5 TB-ot termel. ld. 1

A következő alkalommal becsüljük meg az IOP-ok számát ugyanazon tárolási konfigurációhoz. És legközelebb legközelebb az EMC VNX-hez hasonló Marlezzo balett lesz.

Hello. "Jobb későn, mint soha" Луч
Számos módosítás.
1. "OS vezérlők kiosztásához 3 vezérlőegységet tárolunk"

Meg kell jegyeznünk, hogy a dedikált meghajtóknak a Data ONTAP gyökérkötet alatt történő hozzárendelése _recommendation_, és alkalmazható a meglehetősen nagy és "hűvös" rendszerekhez, de nem _trebovanie_.
Mivel az emberek, akik szeretnének vásárolni 2240-24 lemezek nézd meg ezt, a kín és félre, hogy nincs más lehetőség, más, mint hogy 3 lemezes „oly” Nem predlagayut.Hotya még csak nem is a NetApp ajánlások (lásd. A tároló alrendszer FAQ , látszólag elérhetővé teszik Önt).
Szerintem meglehetősen nagy rendszer - igen, én is ezt tennék. De ezt kifejezetten meg kell tisztázni azon olvasók számára, akik nem teljesen elsajátítják a témát.

2. "De túlságosan nagy a fejlettség a paritásért, hogy bejusson ehhez a változathoz"

Mit értesz a "felárért a paritásért"? Tapasztalatom szerint nincs észrevehető különbség a 14D + 2P csoportban a teljesítmény lebomlása és a 26D + 2P által támogatott maximális érték, ami a RAID-DP-től eltérő RAID-DP mechanizmussal függ össze. Javulást tapasztalunk a hosszú csoport input-output magasabb párhuzamosságának köszönhetően. A NetApp FAS-ban a hosszú csoportok egyetlen hiányos hiánya a RAID "újraszámolása" során fellépő lemezhiba után fellépő helyreállítási idő néhány romlása. Ez a helyreállítási idő meghatározó tényező annak a döntésnek, hogy egy bizonyos hosszúságú csoportot használnak. És természetesen egy kissé hosszabb csoportot választanék, hogy elkerüljék a hiányos csoportok összességét, ez helyesen építészetileg, és a NetApp ajánlott.
By the way, a 20-22 lemezek csoportjai gyakran a RAID-DP elvei alapján, a RAID-6 alapelveitől függően valós rendszerként működnek a gyártásban, ők nem szenvednek "felületi egyenlőtlenségtől".

3. "Capacity = lemezek száma x real disk_drive. A lemez valós kapacitása itt található. Kapunk 47 x 560 GB = 26 320 GB-ot »

Legalább egy javaslatot követne, hogy megragadja, hogy mi ez a "valódi" képesség, honnan származik és hogyan szerezte meg. És miért nincs meghatározva a GB-ban, de a GiB-ben (vagy még inkább a MiB-ben), elhagyta a bináris előtagot, ez nem jó. Ismét zavart.
Azt is szeretném megjegyezni, hogy Ön is "kerekítési hibára" esik. Az 560.000 MiB kapacitás nem 560GB, amint azt Ön jelezte, egyenlő 560.000 MiB / 1024 = 548.875 GiB
Engedje meg, ha számolni kezdtük, hogy méterekkel és lábakkal feltöltsük a lábát.

4. "Pillanatképek fenntartása 20% (alapértelmezett érték)",

A vizsgált rendszer esetében ez igaz, hiszen a feltételek - az NFS. De alább, amikor a LUN és a VMFS verzióról írsz:

"Továbbá, ha nincs NFS-je, de LUN-ok és VMFS-k, akkor le kell vonnod a felsőbbséget ebben az esetben (nincs semmi LUN-okra, semmi, VMMS 10% -ra)."

akkor lenne szükséges meghatározni, hogy a „10%” nem kivonjuk a kapott eredmény az NFS, és fordítva, a „hozzáadott”, mert LUN ajánlott mérete pillanatfelvétel foglalás 0% helyett 20% NFS (lásd. Best Practices), és Ebből 0% levonásra került 10% "VMFS-en". Ugye ez az a személy, unpossessed anyag nem tiszta meg van írva, és ez félrevezető lehet abban az esetben, LUN / VMFS elvett 20% + 10% = 30%, bár ez nem így van.

Talán azért, mert a Synergy egy kicsit jobban gondolkodik, mégis kiderül.

Mindazonáltal, ezek a kis hiányosságok ellenére a számítás hasznos és általában helyes, hála, ugyanazt várjuk más VNX-vel ígért többi gyártótól is.

A deduplikációról, a flexklonról és így tovább - túlságosan függ az adott projekt sajátos körülményeitől. Mi lesz tárolva, mennyire kész a teljesítmény feláldozására a hangerő érdekében, mennyire félnek a finomságoktól és a pillanatfelvételekről (igen, pszichológia és előítéletek is játszanak!). Általában mindig a legrosszabb feltételezések alapján próbálom megfontolni az opciót, majd, ahogy haladok előre, javítom.

> "Vagy bárhol a gyökérkötelet az összesítésen más adatokkal (bár ez nem ajánlott"

Tároló alrendszer GYIK, 5. oldal
KELL HASZNÁLNI A DEDICATED ROOT AGGREGATE?
A dedikált gyökérösszetétel olyan aggregátum, amely csak gyökérkötetet tartalmaz; azaz nem tartalmaz semmilyen felhasználói adatmennyiséget. A 7-üzemmódban működő Data ONTAP alapú gyökér aggregátumok használata nem szükséges, de ajánlott.

Szigorúan az a tény, hogy a gyökérkötetnek a hozzárendelt aggregátumhoz kell igazodnia, különösen fontos a nagy rendszereknél. Például egy alkalommal, akár 8.0.1-ig, lehetetlen elhelyezni a gyökérkötetet egy 64 bites aggregátumra, és a hozzárendelt aggregátum c szintén fontos a rendkívül kemény SLA-k, például a Metrocluster ultra-magas rendelkezésre álló rendszerek számára.
Azonban az alapvető szükséglet, hogy külön aggregátot hozzanak létre a gyökérkötet alatt, az esetek 95% -ában nincs szükség. Vaughn, még a Synergyben is ez egy külön opcionális ellenőrzés.

Ráadásul még az ott idézett oldalon is a második sor mondja:
"Azonban a kis tárolórendszerek esetében, ahol a költségeket meghaladják a rugalmasság, a FlexVol-alapú gyökérfogat egy szabályos aggregátumon megfelelőbb lehet."

És igen, meg kell jegyeznünk, hogy a Cluster-módú rendszerek esetében itt van - igen. Mivel a klaszter mód már nagyon közel van hozzánk, itt az ideje, hogy pontosan meghatározzuk és figyelembe vesszük.

> Néhány N-ska elveszett Szibériában, ahol a lemez hibája nem észlelhető 2 héten át, majd egy-két hónapra cserélik ki, és a biztonsági mentés pillanatkép - ez jelentős kockázatot jelent.

Általában véve nem gondolom, hogy a 7-9 meghajtó egy csoportjának méretének növelése észrevehető kockázatokat hordoz magában a visszanyerési idő növelésével és a megbízhatóság csökkentésével kapcsolatban, de a rendszerben további 4 lemez kapacitása visszakerül. Egy ilyen rugalmasabb megközelítés számomra sokkal praktikusabb és alkalmazhatóbb lenne ebben az esetben. De, egyetértek, ezek a részletek.

> Általában mindig a legrosszabb feltételezések alapján próbálom megfontolni az opciót, majd, ahogy haladok előre, javítom.

Általánosságban ez igaz, de itt érdemes figyelembe venni a felhasználói felhasználói élményt, amely a "hagyományos" tárolórendszereknél azt mondja, hogy miután létrehoztunk és beállítottunk egy tiszta és üres tárolórendszert, rendelkezésre álló kapacitása, ahogy az adatok írva vannak, hogy a felhasználó csak csökkenjen (ami logikus a banális világi logika szempontjából).
Azonban, ha a NetApp nem ez a helyzet, és hogy kerülne felhívni az olvasó figyelmét, hiszen ez ellentétes az „alapértelmezett nézet”, de ez a szempont a hasznos tér NetApp meglehetősen fontos szerepet konfigurálásával és megértése „hogyan működnek a dolgok ”.