{"id":35801,"date":"2019-10-31T22:06:24","date_gmt":"2019-10-31T19:06:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-vybrat-shd-ne-vystreliv-sebe-v-nogu\/"},"modified":"2019-10-31T22:06:24","modified_gmt":"2019-10-31T19:06:24","slug":"kak-vybrat-shd-ne-vystreliv-sebe-v-nogu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-vybrat-shd-ne-vystreliv-sebe-v-nogu","title":{"rendered":"Hvordan man v\u00e6lger et SAN, uden at skade sig selv","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Introduktion<\/h2>\n

\nDet er tid til at k\u00f8be en lagringssystem. Hvilket skal man v\u00e6lge, og hvem skal man lytte til? Leverand\u00f8r A fort\u00e6ller om leverand\u00f8r B, og s\u00e5 er der integrator C, som fort\u00e6ller det modsatte og anbefaler leverand\u00f8r D. Under s\u00e5danne omst\u00e6ndigheder kan selv en erfaren arkitekt inden for lagringssystemer blive forvirret, is\u00e6r med alle de nye leverand\u00f8rer og de trendy SDS og hyperkonvergens.<\/p>\n

S\u00e5 hvordan skal man navigere i alt dette uden at se dum ud? Vi (AntonVirtual<\/a><\/noindex> Anton Zhbankov og korp<\/a><\/noindex> Evgeny Elizarov) vil fors\u00f8ge at forklare dette p\u00e5 et forst\u00e5eligt sprog.
\nArtiklen har mange overlap, og er faktisk en udvidelse af \u201cDesign af virtualiserede datacentre<\/a><\/noindex>\u201d med fokus p\u00e5 valg af lagringssystemer og en gennemgang af teknologierne bag lagringssystemer. Vi vil kort gennemg\u00e5 den generelle teori, men anbefaler ogs\u00e5 at l\u00e6se den n\u00e6vnte artikel.<\/p>\n

Hvorfor<\/h2>\n

\nMan kan ofte observere, hvordan en ny person kommer ind p\u00e5 et forum eller i en specialiseret chat, som for eksempel Storage Discussions, og stiller sp\u00f8rgsm\u00e5let: \u201cjeg f\u00e5r tilbudt to muligheder for lagringssystemer \u2014 ABC SuperStorage S600 og XYZ HyperOcean 666v4, hvad anbefaler I?\u201d<\/p>\n

Og s\u00e5 begynder diskussionen om, hvem der har hvilke s\u00e6rtr\u00e6k ved implementeringen af de skr\u00e6mmende og uforst\u00e5elige funktioner, som for en uuddannet person virker som kinesisk.
\n<\/a><\/noindex>
\nS\u00e5 det f\u00f8rste og mest grundl\u00e6ggende sp\u00f8rgsm\u00e5l, man skal stille sig selv lang tid f\u00f8r man sammenligner specifikationer i kommercielle tilbud \u2014 HVORFOR? Hvorfor har man brug for dette lagringssystem?<\/p>\n

\"Hvordan
\n
\nSvaret vil v\u00e6re overraskende, og meget i stil med Tony Robbins \u2014 for at opbevare data. Tak, kaptajn! Men nogle gange fordyber vi os s\u00e5 meget i sammenligningen af detaljer, at vi glemmer, hvorfor vi overhovedet g\u00f8r alt dette.<\/p>\n

S\u00e5 beskyttelsen af lagringssystemet er at opbevare og give adgang til DATA med specificeret ydeevne. Det er fra dataene, at vi skal begynde.<\/p>\n

Data<\/h2>\n

<\/p>\n

Datatype<\/h3>\n

\nHvilke data planl\u00e6gger vi at gemme? Et meget vigtigt sp\u00f8rgsm\u00e5l, som kan udelukke rigtig mange Lagringssystemer fra overvejelserne. For eksempel, hvis vi planl\u00e6gger at gemme videooptagelser og billeder. Vi kan straks udelukke systemer, der er beregnet til tilf\u00e6ldig adgang med sm\u00e5 blokke, eller systemer med propriet\u00e6re funktioner inden for kompression \/ deduplikation. Disse kan v\u00e6re fremragende systemer, og vi \u00f8nsker ikke at sige noget d\u00e5rligt om dem. Men i dette tilf\u00e6lde vil deres st\u00e6rke sider enten blive svage (video og billeder kan ikke komprimeres) eller bare markant \u00f8ge omkostningerne ved systemet.<\/p>\n

Og omvendt, hvis den tilsigtede anvendelse er en belastet transaktionel database, s\u00e5 vil fremragende str\u00f8mmede systemer til multimedier, der kan levere gigabyte per sekund, v\u00e6re et d\u00e5rligt valg.<\/p>\n

Data volumen<\/h3>\n

\nHvor meget data planl\u00e6gger vi at gemme? M\u00e6ngden vokser altid til kvalitet, det m\u00e5 man aldrig glemme, is\u00e6r i vores tid med eksponentiel v\u00e6kst i datam\u00e6ngden. Systemer i petabyte-klassen er allerede ikke us\u00e6dvanlige, men jo st\u00f8rre petabyte-volumen, jo mere specifik bliver systemet, og jo mindre vil den s\u00e6dvanlige funktionalitet fra systemer med tilf\u00e6ldig adgang i lille og mellemstor m\u00e6ngde v\u00e6re tilg\u00e6ngelig. Simpelthen fordi selv statistikkerne for adgang til blokke bliver st\u00f8rre end den tilg\u00e6ngelige m\u00e6ngde RAM p\u00e5 controllerne. For ikke at n\u00e6vne kompression \/ tiering. Antag, at vi \u00f8nsker at skifte til en mere kraftfuld kompressionsalgoritme og presse 20 petabyte data. Hvor lang tid vil det tage: et halvt \u00e5r, et \u00e5r?<\/p>\n

P\u00e5 den anden side, hvorfor g\u00f8re det kompliceret, hvis vi kun skal gemme og bearbejde 500 GB data? Kun 500. Almindelige SSD'er (med lav DWPD) i denne st\u00f8rrelse koster n\u00e6sten ingenting. Hvorfor bygge en Fiber Channel-fabrik og k\u00f8be et eksternt Lagringssystem i h\u00f8j klasse, der koster en formue?<\/p>\n

Hvilken procentdel af det samlede datavolumen udg\u00f8r de varme data? Hvor uj\u00e6vnt er belastningen i forhold til datam\u00e6ngden? Her kan teknologier som tiered storage eller Flash Cache v\u00e6re til stor hj\u00e6lp, hvis m\u00e6ngden af varme data er minimal i forhold til totalen. Omvendt, ved en j\u00e6vn belastning over det samlede volum, som ofte ses i streaming systemer (videooverv\u00e5gning, visse analyse systemer), vil s\u00e5danne teknologier ikke give noget og blot \u00f8ge omkostningerne\/sv\u00e6rhedsgraden af systemet.<\/p>\n

IS<\/h3>\n

\nDen modsatte side af data er et informationssystem, der bruger disse data. IS har et s\u00e6t krav, der arver dataene. L\u00e6s mere om IS i \u201cDesignet af virtualiserede datacentre\u201d.<\/p>\n

Krav til fejltolerance \/ tilg\u00e6ngelighed<\/h4>\n

Kravene til fejltolerance \/ tilg\u00e6ngelighed af data arves fra det informationssystem, der bruger dem, og udtrykkes i tre tal \u2014 RPO<\/b>, RTO<\/b>, tilg\u00e6ngelighed<\/b>.<\/p>\n

Tilg\u00e6ngelighed <\/b> \u2014 andelen af en given tidsperiode, hvor data er tilg\u00e6ngelige for behandling. Udtrykkes normalt i antallet af 9. For eksempel betyder to nicher om \u00e5ret, at tilg\u00e6ngeligheden er 99%, eller med andre ord tillades 95 timers utilg\u00e6ngelighed om \u00e5ret. Tre nicher \u2014 9,5 timer om \u00e5ret.<\/p>\n

RPO \/ RTO er ikke samlede m\u00e5l, men g\u00e6lder for hver h\u00e6ndelse (nedbrud), i mods\u00e6tning til tilg\u00e6ngelighed.<\/p>\n

RPO <\/b> \u2014 m\u00e6ngden af data, der g\u00e5r tabt ved et nedbrud (i timer). For eksempel, hvis backup udf\u00f8res dagligt, s\u00e5 er RPO = 24 timer. Dvs. Ved et nedbrud og et komplet tab af lagerenheden kan der mistes data svarende til op til 24 timer (fra tidspunktet for backup). Baseret p\u00e5 det angivne RPO for IS skrives der f.eks. en backup-regulering. Desuden kan man ud fra RPO forst\u00e5, hvor vigtigt det er med synkron eller asynkron data-replikation.<\/p>\n

RTO<\/b> \u2014 tiden til genopretning af tjenesten (adgang til data) efter et nedbrud. Baseret p\u00e5 den angivne RTO-v\u00e6rdi kan vi forst\u00e5, om der er brug for en metrocluster, eller om ensrettet replikation er tilstr\u00e6kkeligt. Er der ogs\u00e5 brug for en multi-controller lagringsenhed i high-end klasse?<\/p>\n

\"Hvordan
\n<\/p>\n

Krav til ydeevne<\/h4>\n

\nSelvom det er et helt \u00e5benlyst sp\u00f8rgsm\u00e5l, s\u00e5 opst\u00e5r der ofte de fleste vanskeligheder med det. Afh\u00e6ngigt af, om man allerede har en eller anden infrastruktur eller ej, og der skal bygges m\u00e5der til at indsamle den n\u00f8dvendige statistik.<\/p>\n

Har du allerede et lagringssystem, og leder du efter en erstatning eller \u00f8nsker du at k\u00f8be et ekstra til udvidelse? Det er enkelt. Du ved, hvilke tjenester du allerede har, og hvilke du planl\u00e6gger at implementere i den n\u00e6rmeste fremtid. Baseret p\u00e5 de nuv\u00e6rende tjenester har du mulighed for at samle statistik over ydeevnen. Bestem det nuv\u00e6rende antal IOPS og de aktuelle latencer - hvordan er disse tal, og er de tilstr\u00e6kkelige til dine opgaver? Dette kan g\u00f8res b\u00e5de p\u00e5 selve lagringssystemet og fra v\u00e6rtsiden, der er tilsluttet det.<\/p>\n

Det er vigtigt at se p\u00e5 ikke kun den aktuelle belastning, men over en periode (helst en m\u00e5ned). Se p\u00e5, hvad de maksimale toppe er i dagtimerne, hvilken belastning backup genererer osv. Hvis dit lagringssystem eller det software, der er tilknyttet det, ikke giver dig et komplet s\u00e6t af disse data, kan du bruge det gratis v\u00e6rkt\u00f8j RRDtool, som kan arbejde med de fleste af de mest popul\u00e6re lagringssystemer og switches og kan give dig detaljeret statistik over ydeevnen. Det er ogs\u00e5 v\u00e6rd at se p\u00e5 belastningen p\u00e5 de v\u00e6rter, der arbejder med dette lagringssystem, specifikt p\u00e5 de virtuelle maskiner eller hvad der konkret k\u00f8rer p\u00e5 denne v\u00e6rt.<\/p>\n

\"Hvordan
\n
\nDet b\u00f8r n\u00e6vnes s\u00e6rskilt, at hvis latensen p\u00e5 volumen og datastore, der ligger p\u00e5 dette volumen, adskiller sig betydeligt - s\u00e5 b\u00f8r du v\u00e6re opm\u00e6rksom p\u00e5 dit SAN-netv\u00e6rk. Der er stor sandsynlighed for, at der er problemer med det, og f\u00f8r du k\u00f8ber et nyt system, skal du tage fat i dette sp\u00f8rgsm\u00e5l, da der er en h\u00f8j sandsynlighed for forbedring af ydeevnen p\u00e5 det nuv\u00e6rende system.<\/p>\n

Du bygger en infrastruktur fra bunden, eller du k\u00f8ber et system til en ny tjeneste, hvis belastninger du ikke er bekendt med. Der er flere muligheder: tal med kolleger p\u00e5 relevante ressourcer for at fors\u00f8ge at f\u00e5 en id\u00e9 om og forudse belastningen, henvend dig til en integrator, der har erfaring med implementering af s\u00e5danne tjenester, og som kan beregne belastningen for dig. Den tredje mulighed (normalt den mest udfordrende, is\u00e6r hvis det drejer sig om skr\u00e6ddersyede eller sj\u00e6ldne applikationer) er at fors\u00f8ge at afklare kravene til ydeevne med systemets udviklere.<\/p>\n

Og, opm\u00e6rksomhed, den mest korrekte variant med hensyn til praktisk anvendelse er en pilot p\u00e5 det nuv\u00e6rende udstyr eller udstyr, der stilles til r\u00e5dighed til test af leverand\u00f8ren\/integratoren.<\/p>\n

Specifikke krav<\/h4>\n

\nSpecifikke krav er alt det, der ikke falder ind under kravene til ydeevne, fejltolerance og funktionalitet ved direkte behandling og levering af data.<\/p>\n

Et af de simpleste specifikke krav til lagringssystemet kan betegnes som 'overf\u00f8rbare informationsb\u00e6rere'. Og det bliver straks klart, at dette lagringssystem skal inkludere et b\u00e5ndbibliotek eller simpelthen en streamer, hvori en backup gemmes. Derefter underskriver en specielt uddannet person b\u00e5ndet og b\u00e6rer stolt det ind i et s\u00e6rligt pengeskab.
\nEt andet eksempel p\u00e5 et specifikt krav er beskyttelsen mod st\u00f8d.<\/p>\n

Where<\/h2>\n

\nDen anden vigtigste faktor i valget af et givent lagringssystem er information om, HVOR dette system vil st\u00e5. Fra geografi eller klimatiske forhold til personalet.<\/p>\n

Kunden<\/h3>\n

\nHvem er denne lagringssystem planlagt til? Dette sp\u00f8rgsm\u00e5l har f\u00f8lgende baggrund:<\/p>\n

Offentlig kunde\/kommerciel.<\/b>
\nDen kommercielle kunde har ingen begr\u00e6nsninger og er ikke engang forpligtet til at afholde udbud, bortset fra egne interne retningslinjer. <\/p>\n

Den offentlige kunde er en anden sag. 44 FZ og andre fordele med udbud og kravspecifikationer, som kan blive anf\u00e6gtet.<\/p>\n

Kunde under sanktioner<\/b>
\nHer er sp\u00f8rgsm\u00e5let meget enkelt \u2014 valget begr\u00e6nses kun til de tilbud, der er tilg\u00e6ngelige for denne kunde.<\/p>\n

Interne retningslinjer\/leverand\u00f8rer godkendt til indk\u00f8b\/modeller<\/b>
\nSp\u00f8rgsm\u00e5let er ogs\u00e5 meget enkelt, men det skal man huske p\u00e5.<\/p>\n

Hvor fysisk<\/h3>\n

\nI denne del ser vi p\u00e5 alle sp\u00f8rgsm\u00e5l vedr\u00f8rende geografi, kommunikationskanaler og mikroklimaet i lokalet, hvor systemet installeres.<\/p>\n

Personalet<\/h4>\n

\nHvem vil arbejde med dette lagringssystem? Dette er mindst lige s\u00e5 vigtigt som, hvad lagringssystemet direkte kan.
\nUanset hvor lovende, fantastisk og fremragende lagringssystemet fra leverand\u00f8r A m\u00e5tte v\u00e6re, giver det sandsynligvis ikke meget mening at installere det, hvis personalet kun kan arbejde med leverand\u00f8r B, og der ikke planl\u00e6gges yderligere indk\u00f8b og konstant samarbejde med A.<\/p>\n

Og selvf\u00f8lgelig er det omvendte sp\u00f8rgsm\u00e5l, hvor tilg\u00e6ngelig den n\u00f8dvendige arbejdskraft er i denne geografiske placering, b\u00e5de i virksomheden og potentielt p\u00e5 arbejdsmarkedet. For regioner kan det have betydelig v\u00e6rdi at v\u00e6lge lagringssystemer med enkle gr\u00e6nseflader eller mulighed for fjerncentreret administration. Ellers kan det p\u00e5 et tidspunkt blive smertefuldt. Internettet er fyldt med historier om, hvordan en ny medarbejder, der lige er blevet f\u00e6rdiguddannet, konfigurerede noget, s\u00e5 hele firmaet gik i st\u00e5.<\/p>\n

\"Hvordan
\n<\/p>\n

Milj\u00f8<\/h4>\n

\nOg det er selvf\u00f8lgeligt ogs\u00e5 en vigtig sp\u00f8rgsm\u00e5l \u2014 hvilket milj\u00f8 denne lagringssystem vil operere i. <\/p>\n