Deci, avem un sistem de acumulare (NAS), format din două controlere 3220, cinci rafturi 24 de acționare fiecare, roți 600GB SAS 10k RPM, FlashCache 1TB (pentru 512M controler), capacitatea brută a sistemului este de 5 x 24 x 0, 6 = 72TB.
Spațiul de stocare va găzdui virtualizarea Vmware, pentru simplitate pe NFS, pentru a nu deranja rezervele pentru LUN și VMFS.
În legătură cu particularitățile deținerii de discuri în netapp, având în vedere faptul că vom găzdui virtualizarea, pentru a paraleliza sarcina pe controlere împărțim masa totală a discurilor la jumătate și le dăm fiecare jumătate proprietății controlorului. Total pentru fiecare controler este obținut de 60 de discuri.
Total se dovedește. 18 950 GB, bine, lăsați 19TB pe controler, 19 x 2 = 38TB pe matrice. Aceasta reprezintă 53% din capacitatea brută. Și dacă luăm în considerare faptul că masivul, care este 100% plin, nu va funcționa, credem că ocuparea sa maximă, la care va fi încă rapidă, este de aproximativ 80%, adică la dispoziția dumneavoastră 30.4TB, 42% din capacitatea brută.
Mai mult, dacă nu aveți NFS, dar LUN și VMFS, atunci trebuie să scăpați din acest caz cheltuielile aeriene (pe LUN, nu este nimic, pe VMFS - 10%).
Produce 45.5TB. vezi Fig. 1
Data viitoare vom estima numărul de IOP-uri pentru aceeași configurație de stocare. Și data viitoare, următorul balet Marlezzo se va face pentru EMC VNX.
Buna ziua. "Mai bine târziu decât niciodată" Luci
Câteva amendamente.
1. "Pentru a aloca controlerele OS, rezervăm 3 discuri per controler"
Trebuie remarcat faptul că alocarea unităților dedicate sub volumul rădăcină pentru datele ONTAP este _recommendation_ și este aplicabilă sistemelor destul de mari și "cool", dar nu _trebovanie_.
Deoarece oamenii care doresc să cumpere în 2240 la 24 de discuri se vor uita la acest lucru, în suferință și va induce în eroare, că nu există nici o altă opțiune decât pentru a da 3-disc „pentru acest lucru“, ei nu predlagayut.Hotya nu este chiar și pe recomandările NetApp (a se vedea. Depozitare Subsistem Întrebări frecvente , aparent accesibilă pentru dvs.).
Pentru sistemul considerat, destul de mare - da, aș face și eu acest lucru. Dar ar trebui clarificat într-o formă explicită acest punct pentru cititorii care nu stăpânesc complet subiectul.
2. "Dar este prea mare pentru ca paritatea să ajungă în această versiune"
Ce vrei sa spui prin "overhead for parity"? Din experiența mea, nu există nicio diferență semnificativă în degradarea performanțelor grupului la 14D + 2P și maximul susținut de 26D + 2P, care este legat de mecanismul RAID-DP, care diferă de RAID-6. Există o îmbunătățire datorită paralelismului mai mare al input-output-ului pe un grup lung. Singurul deficit cunoscut de grupuri lungi în NetApp FAS este o anumită deteriorare cu timpul de recuperare după o defecțiune a discului în timpul "recalculației" RAID-ului. Timpul de recuperare este factorul determinant pentru decizia de a folosi un grup de o anumită lungime. Și cu siguranță aș alege un grup puțin mai lung pentru a evita un grup incomplet în total, acest lucru este arhitectural adecvat și se recomandă NetApp.
Apropo, grupuri de discuri de 20-22 de multe ori lucrează în sisteme reale de producție, datorită principiilor RAID-DP, care diferă de principiile RAID-6, nu suferă de "aeriene la paritate".
3. "Capacitate = numărul de discuri x disc_drive real. Capacitatea reală a discului poate fi găsită aici. Avem 47 x 560GB = 26 320GB »
Va urma cel puțin o sugestie de a analiza ce este această capacitate "reală", de unde vine și cum a fost obținută. Și de ce nu este specificat în GB, dar în GiB (sau mai degrabă, chiar și în MiB), ați omis prefixul binar, nu este bine. Din nou, există o confuzie.
De asemenea, vreau să remarcăm că, la rândul tău, te afli și pe "eroarea de rotunjire". Capacitatea de 560.000 MiB NU este de 560GB, așa cum este indicat de dvs., este egal cu 560.000 MiB / 1024 = 548.875 GiB
Să începem să numărăm, să adăugăm contoare cu metri și picioare cu picioarele.
4. "Rezervări pentru instantanee 20% (valoarea implicită),"
Pentru sistemul în cauză, acest lucru este adevărat, deoarece în condițiile - NFS. Dar mai jos, când scrieți despre versiunea cu LUN și VMFS:
"Mai mult, dacă nu aveți NFS, dar LUN și VMFS, trebuie să scăpați din acest caz cheltuielile aeriene (nu există nimic pentru LUN, nimic, VMMS 10%)".
atunci ar fi necesar să se precizeze că „10%“ nu se scade din rezultatul obținut în NFS, și vice-versa „a adăugat“, deoarece pentru LUN recomandată rezervare instantaneu dimensiunea este de 0% în loc de 20% pentru NFS (a se vedea. Cele mai bune practici) și Dintre acestea, 0% este deja dedus 10% "pe VMFS". Aveți acest lucru pentru o persoană care nu deține materialul nu este scris în mod clar și poate fi înșelător faptul că în cazul LUN / VMFS, acesta va pierde 20% + 10% = 30%, deși acest lucru nu este adevărat.
Poate pentru că Synergy crede că este ceva mai corect, se dovedește mai mult.
Cu toate acestea, în ciuda acestor neajunsuri mici, calculul este util și, în general, corect, mulțumim, ne așteptăm la același lucru și pentru alți furnizori, promisiți pentru VNX.
Despre deduplicare, flexclone și așa mai departe - este prea dependentă de condițiile specifice unui anumit proiect. Ce va fi păstrat, cât de gata să sacrifice performanța de dragul volumului, cât de mult se tem de subtilități și instantanee (da, psihologia și prejudecățile încă joacă prea!). În general, întotdeauna încerc să iau în considerare opțiunea bazată pe cele mai grave ipoteze și apoi, pe măsură ce avansez, să o îmbunătățesc.
> "Sau în orice loc rootvol pe agregat cu alte date (deși acest lucru nu este recomandat"
Suport FAQ subsistem, pagina 5
VREAU SA UTILIZEAZA UN AGREGAT DE CRESTERE DEDICAT?
Un agregat rădăcină dedicat este un agregat care conține doar un volum de rădăcină; adică nu conține volume de date de utilizator. Utilizarea agregatelor rădăcină dedicate pentru datele ONTAP care operează în modul 7 nu este necesară, dar este recomandată.
În mod strict vorbind, necesitatea practică de a scoate volumul rădăcinii la agregatul alocat este de o importanță deosebită, în special pentru sistemele mari. De exemplu, o singură dată, până la 8.0.1, pare imposibil să plasezi volumul rădăcinii pe un agregat pe 64 de biți, iar agregatul c alocat este, de asemenea, important pentru sistemele ultra-înalte disponibile cu un SLA extrem de greu, cum ar fi Metrocluster.
Dar în viața de necesitatea fundamentală de a aloca un agregat separat sub volumul rădăcinii, în 95% din cazuri, nu este nevoie. Vaughn, chiar și în Synergy, acesta este un control opțional separat.
În plus, chiar și în pagina pe care ați citat-o acolo, al doilea rând spune:
"Cu toate acestea, pentru sistemele de stocare mici, în care costurile depășesc rezistența, un volum de rădăcină bazat pe FlexVol pe un agregat obișnuit ar putea fi mai adecvat".
Și, da, trebuie remarcat că este necesar pentru sistemele în modul Cluster, aici - da. Deoarece modul de tip cluster este deja foarte aproape de noi, este timpul să specificăm și să luăm în considerare în mod specific.
> Pentru unele N-ska pierdute în pădurile din Siberia, unde eșecul discului nu este observat timp de 2 săptămâni, iar apoi o altă lună sau două sunt înlocuite, iar backup-ul este instantaneu - acesta este un risc semnificativ.
În general, nu cred că mărirea dimensiunii unui grup de la 7 la 9 unități prezintă anumite riscuri vizibile în ceea ce privește creșterea timpului de recuperare și reducerea fiabilității, însă capacitatea a 4 discuri suplimentare în sistem este returnată nouă. O astfel de abordare mai flexibilă mi se pare mai practică și aplicabilă în acest caz. Dar, sunt de acord, acestea sunt detaliile.
> În general, întotdeauna încerc să iau în considerare opțiunea bazată pe cele mai grave ipoteze și apoi, pe măsură ce avansez, să o îmbunătățesc.
În general, acest lucru este adevărat, dar aici merită să ținem seama de experiența utilizatorului, care pentru sistemele de stocare "convenționale" spune că după ce am creat și configurat un sistem de stocare curat și gol, capacitatea sa disponibilă, pentru ca utilizatorul să scadă (ceea ce este logic din punctul de vedere al logicii lumești banale).
Cu toate acestea, în cazul în care NetApp nu este cazul, și că ar costa să atragă atenția cititorului, deoarece este contrar „vizualizarea implicită“ sa, dar acest aspect al spațiului utilizabil pe NetApp destul de important în configurarea și înțelegerea „cum funcționează lucrurile “.
Trimiteți-le prietenilor: