IVT SAN Statusrapport og vurdering av videre utbygging

Total rådisk kapasitet er 91 TB

Effektivt benyttet plass er (49-16) = 33TB
Trekker man fra speilvolum på ca. 10TB er effektiv plass ca 23TB

Sålangt har funksjonaliteten svart til forventningene. Vi ser klare fordeler i Snapshot funksjon for brukere. Det gjenstår imidlertid bedre opplæring av brukere samt informasjon på dette punkt. Snapmirror funksjon fungerer bra , bortsett fra ett utfall som krevde regenerering av speil. Hyppigere overvåking på visse punkt er påkrevet.
Filtjenester til ansatte (hjemmekataloger og fellesområde) har fungert bra. Ser klare fordeler med hjemmekatalogvolum med “unix” rettigheter, da dette forenkler feilsøking og operasjoner på fil/katalognivå.
Iscsi mot exchange og virtuelle servere: (må fylles inn)

Har tilstrekkelig kapasitet for noe videre vekst, men ikke nødvendigvis på ønsket disktype. Det er begrenset plass til bufferoperasjoner son trengs ved flytting og reorganisering av data.

Her har vi bommet litt på størrelse. Det er ikke hensiktsmessig med større volum enn 1-2 TB. Hjemmekatalogvolum på ca 7TB er for stort. Det har også antagelig ytelsesmessige konsekvenser for gateway og håndtere så store volum. Antall filer på dette er ogstå stort (ca. 7mill).
Ny funksjonalitet som deduplisering setter klare grenser på volumstørrelse. Vi kan ikke benytte dette idag på gateway. Det trengs en med vesentlig mer ytelse (og kostnad).
Restore flytte operasjoner av store volum tar tid. En grense på 1-2 TB gjør at operasjoner kan foretaes etter arbeidstid eller fullføres i helg.
Ukebackup av hjemmekatalog tar mange timer. Den burde vært erstattet av daglig backup av instituttvise volum på 1-2 TB.

Ytelsen er utgangspunktet bra for daglig bruk. Ingen opplever direkte dårlig ytelse. Det er imidlertid flere punkt som vi ikke opplever som tilfredstillende.
Cpu belastning på ila2a (gateway på ipt) er tidvis høy (50-70). Det indikerer at det ikke er mye kapasitet til overs i perioder. Spesiellt i situasjoner med pågående snapmirror, backup og kopiering merkes dette på overføringstiden.

Snapmirror hastighet mellom siter fungerer greit inkrementellt.Ved initell overføring av hele hjemmekatalogvolum tok dette over 8 dager. Operasjonen fullførte og ingen merket særlig ytelsesfall i denne perioden, men det burde ta vesentlig mindre tid. Nettkapasiteten er en faktor her, men kanske ikke alt. Konklusjonen er at store overføringer mellom siter tar uforholsmessig lang tid.

Lokal volumkopiering som skal være blokkbasert internt i gateway og i utgangspunktet fungere raskt, går med enhastighet på mellom 11 og 25MB/sekund ved to tester. Dette synes alltfor lite. Hva som er flaskehalsen her . er ikke undersøkt videre, men teknologisk burde det være mulig med hastiheter fra 100 MB/sekund og oppover. Hastigheten vi har oppnådd betyr at volumkopiering kan ta flere dager og ikke et mindre antall timer.

San komponenter er i overgang mellom 2 og 4 mbit fc. Det er gateway og 300GB fc disker som er 2GB/sek, resten er 4GB/sek. Gateway burde vært oppdatert til 4GB/sek kort hvis det var mulig.
Diskhyllene og DS4700 kontrollerene burde da også roorganiseres slik at det er samme hastighet på alle komponenter tilhørende en kontroller/hyller.

Stort sett alle komponenter er redundante. Det mangler på gateway'er, noe som har kostnadsmessige årsaker. Videre utbygging bør ta hensyn til at kritiske kontrollere skal være redundante. Konskvensen ved stopp blir stor, selv om mye av data er speilet. Nedetid på timer/1-2 dager må påregnes. FC switcher er heller ikke redundante, men her er konsekvensen “mindre”, da problemet enkelt løses ved å bytte en standard komponent.

Underliggende san system er ustrukturet oppsatt. Det er volum som er lagret på begge DS4700 boksene. Det ble gjort utifra tanken om å spre volum på flest disker. Det vanskeligjør senere restrukturering vesentlig og har større konsekvenser ved feil.

En gateway løsning blir aldri optimal. Det er lagt begrensninger på disk layout som en ren nas løsning ikke har (lun størrelse). Hvorvidt dette har konsekvenser for ytelse er usikkert, men tror at det kan være årsak til noe.Det blir samtidig flere admin punkt, noe som heller ikke er gunstig. Netapp vil sannsyligvis fortsatt legge begrensninger på gateway funksjonalitet for å tvinge kunder over på ren ren NAS løsning.

Har ikke testet dette på større volum.
Både backup og restore ytelse bør prioriteres videre. Det bør settes igang med “colocation” for å “samle” filsystem på egne tap'er for å minimere tapeskifte ved restore. Nettkapasitet mellom server og klienter/monterte filsystem er også viktig. Idag oppnår vi ca 30% av tapehastighet på restore til server lokal disk, det bør ligge tett oppunder tape hastighet. Ved oppgradering av tivoli til versjon 6 bør det legges vekt på disk og cpu ytelse slik at vi har dette maksimalt. Deretter kan vi se på klientnett og videre komponenter.

Videre utbygging kan gjøres på forskjellige måter. En viktig faktor vil være servicekost på komponenter 4 og eventuellt 5 år. Spesiellt DS4700, hyller og til en viss grad diskene , kan leve i flere år til.
Skjebne til gateway vil være avhengig av servicepris på hw og lisenser. Vi vil måtte avveie noe funksjonalitet mot pris og eevntuellt bruke andre metoder for tilnærmet å oppnå det samme. Spesiellt gjelder dette Snapmirror som kan avveise mot radikalt bedre restore hastighet fra tape.
Backup stage område kan samtidig vurderes utvidet til flere TB for å minske restore tid. Snapmirror kan erstattes av andre blokkbaserte metoder. Et annet moment er avlasting av gateway til å serve bare filbaserte volum og ikke benytte iscsi. Gateway er idag en propp på toppen som alt går igjennom. Skal den erstattes er det sterkt avhengig av hvordan lisenspolitikken er.
Ideellt sett burde systemet kunne oppgraderes horisontalt å skalere lineært etter dette.
Systemet bør også kunne tillate innfasing av ny teknologi og utfasing av gammel (spesiellt på disk siden), uten vesentlig nedetid.

Det står minst 3 alternative retninger på videre utbygging.

Fordeler:
Rimelig og uten alt for stort arbeid.

Ulemper:
Blir vanskelig å jobbe mot de forbedringspunkt som er nevnt tidligere.

Må avklares:
Servicepris på komponenter og lisenser for 4 og 5 år. Hvilke tilleggs investeringer bør gjøres/endring for å bøte på nevnte punkt over

Fordeler:
Ytelsesmessig starter vi da på dagens teknologi og kan handle på bakgrunn av de erfaringer vi har gjort sålangt. Migrering blir mindre problem , da dette kan skje gradvis.

Ulemper: Pris blir høy

Avklares:
Er det en teknologi som gir det vi vil ha til en pris som vi finner akseptabel i forhold til budsjetter.

Med utgangspunkt i IBM SVC er dette mulig.

Fordeler:
Uavhengig av san leverandør (hvis det er et poeng) Lineær ytelse ved flere noder og mere disk. Flytting og migrering av data uten stans og med høy ytelse. Kan inneholde både gammel og nyere teknologi både med og uten serviceavtale og benytte disse til ulike oppgaver. Konsistent og ukomplisert på san nivå. Kan benytte medium san komponenter og få premium ytelse.

Ulemper:
Dyr inngangsbillett Omfattende overgang fra gammelt til nytt.

Avklares:
Pris på et svc system som er hensiktsmessig for oss

New capabilities with 2145-CF8 hardware engine

SVC improves its performance capabilities going forward by upgrading to a 64-bit software kernel. This allows SVC V5.1 to take advantage of cache increases such as 24 GB cache provided in the new 2145-CF8. SVC V5.1 will run on all SVC 2145 models that use 64-bit hardware, which includes Models 8F2, 8F4, 8A4, 8G4, and CF8. You cannot upgrade the original SVC 32-bit hardware model, 2145-4F2, to the SVC V5.1 level of software. Refer to the Limitations for more details.

With the option to use 8 Gbps LW SFPs in the SVC 2145-CF8, SVC V5.1 introduces the ability to split a SVC I/O group across long distances. Careful attention should be paid to the LW SFP hardware you use in the SVC 2145 to confirm it matches the supported LW SFPs, and that your SAN meets documented requirements before implementing such a configuration.