Hvordan velge oppbevaring uten å skyte deg selv i foten

Innledning

Det er på tide å kjøpe lagring. Hvilken skal du ta, hvem skal du lytte til? Leverandør A snakker om leverandør B, og så er det integrator C, som forteller det motsatte og gir råd til leverandør D. I en slik situasjon vil til og med en erfaren lagerarkitekts hode snurre, spesielt med alle de nye leverandørene og SDS og hyperkonvergens som er mote. i dag.

Så hvordan finner du ut av alt og ikke ender opp med å bli en tosk? Vi (AntonVirtuell Anton Zhbankov og korp Evgeniy Elizarov) la oss prøve å snakke om dette på vanlig russisk.
Artikkelen har mange likheter og er egentlig en forlengelse av "Virtualisert datasenterdesign” når det gjelder valg av lagringssystemer og gjennomgang av lagringsteknologier. Vi skal kort se på den generelle teorien, men vi anbefaler at du også leser denne artikkelen.

Hva for

Du kan ofte se en situasjon der en ny person kommer til et forum eller en spesialisert chat, for eksempel Storage Discussions, og stiller spørsmålet: "her tilbyr de meg to lagringsalternativer - ABC SuperStorage S600 og XYZ HyperOcean 666v4, hva anbefaler du ?”

Og forvirringen begynner om hvem som har hvilke trekk ved implementeringen av forferdelige og uforståelige funksjoner, som for en uforberedt person er helt kinesisk.

Så det viktigste og aller første spørsmålet du må stille deg selv lenge før du sammenligner spesifikasjoner i kommersielle forslag, er HVORFOR? Hvorfor er dette lagringssystemet nødvendig?

Svaret vil være uventet, og veldig Tony Robbins stil - å lagre data. Takk, kaptein! Og likevel, noen ganger går vi så dypt inn i å sammenligne detaljer at vi glemmer hvorfor vi gjør alt dette i utgangspunktet.

Så oppgaven til et datalagringssystem er å lagre og gi tilgang til DATA med en gitt ytelse. Vi starter med data.

Data

Data-type

Hva slags data planlegger vi å lagre? Et veldig viktig spørsmål som kan eliminere mange lagringssystemer fra selv vurdering. For eksempel planlegger du å lagre videoer og bilder. Du kan umiddelbart krysse ut systemer designet for tilfeldig tilgang i små blokker, eller systemer med proprietære funksjoner i komprimering/deduplisering. Dette kan ganske enkelt være utmerkede systemer, vi ønsker ikke å si noe dårlig. Men i dette tilfellet vil styrkene deres enten bli svake (video og bilder er ikke komprimert) eller ganske enkelt øke kostnadene for systemet betydelig.

Omvendt, hvis den tiltenkte bruken er et travelt transaksjonelt DBMS, vil utmerkede multimediastrømmesystemer som er i stand til å levere gigabyte per sekund være et dårlig valg.

Datavolum

Hvor mye data planlegger vi å lagre? Kvantitet utvikler seg alltid til kvalitet; dette bør aldri glemmes, spesielt i vår tid med eksponentiell vekst i datavolumet. Petabyte-klassesystemer er ikke lenger uvanlige, men jo større petabyte-kapasiteten er, jo mer spesifikt blir systemet, desto mindre tilgjengelig vil den vanlige funksjonaliteten til små og mellomstore tilfeldige tilgangssystemer være. Det er trivielt fordi blokktilgangsstatistikktabellene alene blir større enn den tilgjengelige mengden RAM på kontrollerene. For ikke å snakke om komprimering/tiering. La oss si at vi ønsker å bytte komprimeringsalgoritmen til en kraftigere og komprimere 20 petabyte med data. Hvor lang tid vil det ta: seks måneder, et år?

På den annen side, hvorfor bry seg hvis du trenger å lagre og behandle 500 GB data? Bare 500. Husholdnings SSD-er (med lav DWPD) av denne størrelsen koster ingenting. Hvorfor bygge en Fibre Channel-fabrikk og kjøpe avanserte eksterne lagringssystemer som koster tilsvarende en støpejernsbro?

Hvor mange prosent av totalen er hot data? Hvor ujevn er belastningen når det gjelder datavolum? Det er her lagdelt lagringsteknologi eller Flash Cache kan være svært nyttig hvis mengden hot data er liten sammenlignet med totalen. Eller omvendt, med en jevn belastning gjennom hele volumet, som ofte finnes i strømmesystemer (videoovervåking, enkelte analysesystemer), vil slike teknologier ikke gi noe og vil bare øke kostnadene/kompleksiteten til systemet.

IP

Den andre siden av dataene er informasjonssystemet som bruker dataene. En IS har et sett med krav som arver data. For mer informasjon om IS, se "Virtualisert datasenterdesign."

Krav til motstandsdyktighet/tilgjengelighet

Krav til feiltoleranse / datatilgjengelighet er arvet fra IS som bruker dem og uttrykkes i tre tall - RPO, RTO, tilgjengelighet.

tilgjengelighet — andelen for en gitt tidsperiode som data er tilgjengelig for å arbeide med dem. Det er vanligvis uttrykt som et tall på 9. For eksempel betyr to niere per år at tilgjengeligheten er 99 %, ellers er 95 timer utilgjengelighet per år tillatt. Tre niere - 9,5 timer per år.

RPO / RTO er ikke totale indikatorer, men for hver hendelse (ulykke), i motsetning til tilgjengelighet.

RPO — mengden data som går tapt under en ulykke (i timer). For eksempel, hvis sikkerhetskopiering skjer én gang om dagen, er RPO = 24 timer. De. I tilfelle en katastrofe og fullstendig tap av lagringssystemet, kan data opp til 24 timer gå tapt (fra øyeblikket av sikkerhetskopieringen). Basert på RPO spesifisert for IS, for eksempel, skrives sikkerhetskopieringsbestemmelser. Basert på RPO kan du også forstå hvor mye synkron/asynkron datareplikering som er nødvendig.

RTO — tid for å gjenopprette tjenesten (datatilgang) etter en katastrofe. Basert på den gitte RTO-verdien kan vi forstå om en metroklynge er nødvendig, eller om ensrettet replikering er tilstrekkelig. Trenger du et høykvalitets lagringssystem for flere kontroller?

Ytelseskrav

Selv om dette er et veldig åpenbart spørsmål, er det der de fleste vanskelighetene oppstår. Avhengig av om du allerede har en slags infrastruktur eller ikke, vil det bli bygget måter å samle inn nødvendig statistikk på.

Du har allerede et lagringssystem og ser etter en erstatning eller ønsker å kjøpe et annet for utvidelse. Alt er enkelt her. Du forstår hvilke tjenester du allerede har og som du planlegger å implementere i nær fremtid. Basert på aktuelle tjenester har du mulighet til å samle inn resultatstatistikk. Bestem deg for gjeldende antall IOPS og gjeldende latens - hva er disse indikatorene og er de nok for oppgavene dine? Dette kan gjøres både på selve datalagringssystemet og fra vertene som er koblet til det.

Dessuten må du ikke bare se på gjeldende belastning, men over en viss periode (helst en måned). Se hva de maksimale toppene er i løpet av dagen, hvilken belastning sikkerhetskopien skaper osv. Hvis lagringssystemet eller dets programvare ikke gir deg et komplett sett med disse dataene, kan du bruke det gratis RRD-verktøyet, som kan fungere med de fleste av de mest populære lagringssystemene og bryterne og kan gi deg detaljert ytelsesstatistikk. Det er også verdt å se på belastningen på vertene som jobber med dette lagringssystemet, for spesifikke virtuelle maskiner, eller hva som egentlig kjører på denne verten.

Det er verdt å merke seg separat at hvis forsinkelsene på volumet og datalageret som er plassert på dette volumet avviker ganske betydelig, bør du ta hensyn til SAN-nettverket ditt, det er stor sannsynlighet for at det er problemer med det og før du kjøper et nytt system, er det verdt å se nærmere på dette problemet , fordi det er svært høy sannsynlighet for å øke ytelsen til det nåværende systemet.

Du bygger en infrastruktur fra bunnen av, eller kjøper et system for en ny tjeneste, som du ikke er klar over. Det er flere alternativer: kommuniser med kolleger på spesialiserte ressurser for å prøve å finne ut og forutsi belastningen, kontakt en integrator som har erfaring med å implementere lignende tjenester og som kan beregne belastningen for deg. Og det tredje alternativet (vanligvis det vanskeligste, spesielt hvis det gjelder hjemmeskrevne eller sjeldne applikasjoner) er å prøve å finne ut ytelseskravene fra systemutviklerne.

Og, vær oppmerksom på at det mest korrekte alternativet fra et praktisk brukssynspunkt er en pilot på dagens utstyr, eller utstyr levert for testing av en leverandør/integrator.

Spesielle krav

Spesielle krav er alt som ikke faller inn under kravene til ytelse, feiltoleranse og funksjonalitet for direkte behandling og levering av data.

Et av de enkleste spesialkravene til et datalagringssystem kan kalles "fremmedbare lagringsmedier". Og det blir umiddelbart klart at dette datalagringssystemet må inkludere et båndbibliotek eller ganske enkelt en båndstasjon som sikkerhetskopien blir dumpet på. Deretter signerer en spesialtrent person på båndet og bærer det stolt til en spesiell safe.
Et annet eksempel på et spesielt krav er en beskyttet støtsikker design.

hvor

Den andre hovedkomponenten i å velge et bestemt lagringssystem er informasjon om HVOR dette lagringssystemet vil være plassert. Starter fra geografi eller klimatiske forhold, og slutter med personell.

Kunde

Hvem er dette lagringssystemet planlagt for? Spørsmålet har følgende årsaker:

Offentlig kunde/kommersiell.
Næringskunden har ingen begrensninger og er ikke engang forpliktet til å holde anbud, bortsett fra i henhold til eget internt regelverk.

En offentlig kunde er en annen sak. 44 Føderal lov og andre gleder med anbud og tekniske spesifikasjoner som kan utfordres.

Kunden er under sanksjoner
Vel, spørsmålet her er veldig enkelt - valget er bare begrenset av tilbudene som er tilgjengelige for en gitt kunde.

Interne forskrifter / leverandører / modeller tillatt for kjøp
Spørsmålet er også ekstremt enkelt, men du må huske det.

Hvor fysisk

I denne delen tar vi for oss alle problemstillinger med geografi, kommunikasjonskanaler og mikroklima i overnattingslokalene.

ansatte

Hvem skal jobbe med dette lagringssystemet? Dette er ikke mindre viktig enn hva lagringssystemet selv kan gjøre.
Uansett hvor lovende, kult og flott oppbevaringssystemet fra leverandør A er, er det nok lite vits i å installere det hvis personalet kun vet hvordan de skal jobbe med leverandør B, og det ikke er planer om videre kjøp og løpende samarbeid med A.

Og selvfølgelig er den andre siden av spørsmålet hvor tilgjengelig utdannet personell er på en gitt geografisk plassering direkte i bedriften og potensielt på arbeidsmarkedet. For regioner kan det være veldig fornuftig å velge lagringssystemer med enkle grensesnitt eller muligheten til å sentralisere administrasjonen eksternt. Ellers kan det på et tidspunkt bli uutholdelig smertefullt. Internett er fullt av historier om hvordan en ny ansatt som kom, gårsdagens student, konfigurerte noe slikt at hele kontoret ble drept.

Miljø

Og selvfølgelig er et viktig spørsmål i hvilket miljø dette lagringssystemet vil fungere.

• Hva med strømforsyning/kjøling?
• Hvilken forbindelse
• Hvor skal den installeres?
• Etc.

Ofte blir disse spørsmålene tatt for gitt og ikke spesielt vurdert, men noen ganger er det de som kan snu alt.

At

Leverandør

Fra i dag (midten av 2019) kan det russiske lagringsmarkedet deles inn i 5 kategorier:

1. Den høyeste divisjonen er veletablerte selskaper med et bredt utvalg av diskhyller fra de enkleste til hi-end (HPE, DellEMC, Hitachi, NetApp, IBM / Lenovo)
2. Andre divisjon - selskaper med begrenset linje, nisjeaktører, seriøse SDS-leverandører eller stigende nykommere (Fujitsu, Datacore, Infinidat, Huawei, Pure, etc.)
3. Tredje divisjon - nisjeløsninger i den laveste rangen, billig SDS, avanserte produkter basert på ceph og andre åpne prosjekter (Infortrend, Starwind, etc.)
4. SOHO-segment - små og ultrasmå lagringssystemer på hjemme-/småkontornivå (Synology, QNAP, etc.)
5. Importsubstituerte lagringssystemer - dette inkluderer både maskinvare fra den første divisjonen med ommerkede etiketter, og sjeldne representanter for den andre (RAIDIX, vi gir dem den andre på forhånd), men hovedsakelig er dette den tredje divisjonen (Aerodisk, Baum, Depo, etc.)

Inndelingen er ganske vilkårlig, og betyr overhodet ikke at det tredje eller SOHO-segmentet er dårlig og ikke kan brukes. I spesifikke prosjekter med et klart definert datasett og belastningsprofil, kan de fungere meget bra, og langt overgå første divisjon når det gjelder forhold mellom pris og kvalitet. Det er viktig å først bestemme seg for dine mål, vekstutsikter og nødvendig funksjonalitet – og så vil Synology tjene deg trofast, og håret ditt vil bli mykt og silkemykt.

En av de viktige faktorene når du velger en leverandør er det nåværende miljøet. Hvor mange lagringssystemer du allerede har og hvilke lagringssystemer ingeniørene dine kan jobbe med. Trenger du en annen leverandør, et annet kontaktpunkt, vil du gradvis migrere hele lasten fra leverandør A til leverandør B?

Man skal ikke produsere enheter utover det som er nødvendig.

iSCSI/FC/Fil

Det er ingen konsensus blant ingeniører om spørsmålet om tilgangsprotokoller, og debatten ligner mer på teologiske diskusjoner enn ingeniørdiskusjoner. Men generelt kan følgende punkter bemerkes:

FCoE mer død enn levende.

FC vs iSCSI. En av hovedfordelene med FC i 2019 i forhold til IP-lagring, en dedikert fabrikk for datatilgang, oppveies av et dedikert IP-nettverk. FC har ingen globale fordeler i forhold til IP-nettverk, og IP kan brukes til å bygge lagringssystemer av alle belastningsnivåer, opp til systemer for tunge DBMS for kjernebanksystemet til en stor bank. På den annen side har dødsfallet til FC vært spådd i flere år nå, men noe hindrer det hele tiden. I dag er det for eksempel noen aktører i lagringsmarkedet som utvikler NVMEoF-standarden aktivt. Om han vil dele skjebnen til FCoE - tiden vil vise.

Filtilgang er heller ikke noe uverdig oppmerksomhet. NFS/CIFS yter godt i produktivitetsmiljøer og har, hvis den er utformet riktig, ikke flere klager enn blokkprotokoller.

Hybrid / All Flash Array

Klassiske oppbevaringssystemer kommer i 2 typer:

1. AFA (All Flash Array) - systemer optimalisert for SSD-bruk.
2. Hybrid – slik at du kan bruke både HDD og SSD eller en kombinasjon av dem.

Hovedforskjellen deres er de støttede lagringseffektivitetsteknologiene og det maksimale ytelsesnivået (høy IOPS og lav latens). Begge systemene (i de fleste av deres modeller, ikke medregnet low-end-segmentet) kan fungere som både blokk- og filenheter. Den støttede funksjonaliteten avhenger av systemets nivå, og for yngre modeller er den oftest redusert til et minimumsnivå. Dette er verdt å ta hensyn til når du studerer egenskapene til en bestemt modell, og ikke bare egenskapene til hele linjen som helhet. Også dens tekniske egenskaper, som prosessor, mengde minne, cache, antall og typer porter, etc., avhenger også av nivået på systemet. Fra et administrasjonssynspunkt skiller AFA-er seg fra hybrid (disk)-systemer bare i implementeringen av mekanismer for å jobbe med SSD-stasjoner, og selv om du bruker en SSD i et hybridsystem, betyr ikke dette i det hele tatt at du vil være i stand til å oppnå ytelsesnivået på nivået til et AFA-system. I de fleste tilfeller er inline effektive lagringsmekanismer også deaktivert på hybridsystemer, og inkludering av dem fører til tap i ytelse.

Spesielle lagringssystemer

I tillegg til generelle lagringssystemer, primært fokusert på operasjonell databehandling, finnes det spesielle lagringssystemer med nøkkelprinsipper som er fundamentalt forskjellige fra de vanlige (lav latens, høy IOPS):

Media.

Disse systemene er designet for lagring og behandling av store mediefiler. Resp. forsinkelsen blir praktisk talt uviktig, og muligheten til å sende og motta data i et bredt bånd i mange parallelle strømmer kommer i forgrunnen.

Deduplikering av lagringssystemer for sikkerhetskopiering.

Siden sikkerhetskopier utmerker seg ved deres likhet med hverandre, noe som er sjeldent under normale forhold (gjennomsnittlig sikkerhetskopi avviker fra gårsdagens kopi med 1-2%), pakker denne klassen av systemer ekstremt effektivt dataene som er registrert på dem i en ganske liten antall fysiske medier. For eksempel, i noen tilfeller kan datakomprimeringsforhold nå 200 til 1.

Objektlagringssystemer.

Disse lagringssystemene har ikke de vanlige blokkadgangsvolumene og fildelingene, og mest av alt ligner de en enorm database. Tilgang til et objekt lagret i et slikt system utføres av en unik identifikator eller av metadata (for eksempel alle JPEG-formatobjekter med en opprettelsesdato mellom XX-XX-XXXX og YY-YY-YYYY).

Samsvarssystem.

De er ikke så vanlige i Russland i dag, men de er verdt å nevne. Formålet med slike lagringssystemer er garantert datalagring for å overholde sikkerhetspolicyer eller regulatoriske krav. Noen systemer (for eksempel EMC Centera) har implementert en funksjon for å forby sletting av data - så snart nøkkelen er vridd om og systemet går inn i denne modusen, kan verken administrator eller noen andre fysisk slette data som allerede er registrert.

Proprietære teknologier

Flash cache

Flash Cache er et felles navn for all proprietær teknologi for bruk av flash-minne som en andre-nivå cache. Ved bruk av flash-cache beregnes lagringssystemet vanligvis til å gi en jevn belastning fra magnetiske disker, mens toppen betjenes av cachen.

I dette tilfellet er det nødvendig å forstå lastprofilen og graden av lokalisering av tilgang til blokker med lagringsvolumer. Flash-cache er en teknologi for arbeidsbelastninger med svært lokaliserte spørringer, og er praktisk talt ubrukelig for jevnt lastede volumer (som for analysesystemer).

Det er to flash-cache-implementeringer tilgjengelig på markedet:

• Kun lesetilgang. I dette tilfellet bufres kun lesedata, og skrivingen går direkte til diskene. Noen produsenter, som NetApp, mener at skriving til lagringssystemene deres allerede er optimalt, og cachen vil ikke hjelpe i det hele tatt.
• Les Skriv. Ikke bare lesing, men også skriving bufres, noe som lar deg bufre strømmen og redusere virkningen av RAID Penalty, og som et resultat øke den generelle ytelsen for lagringssystemer med en mindre optimal skrivemekanisme.

Tiering

Lagring på flere nivåer (utmattende) er en teknologi for å kombinere nivåer med forskjellige ytelsesnivåer, som SSD og HDD, til en enkelt diskpool. Ved uttalt ujevnhet i tilgang til datablokker, vil systemet automatisk balansere datablokker, flytte lastede til et høyytelsesnivå, og kalde, tvert imot, til et tregere.

Hybride systemer i lavere og middelklasse bruker lagring på flere nivåer med data som beveger seg mellom nivåer etter en tidsplan. Samtidig er størrelsen på flernivålagringsblokken for de beste modellene 256 MB. Disse funksjonene tillater oss ikke å betrakte lagdelt lagringsteknologi som en teknologi for å øke produktiviteten, slik mange feilaktig tror. Lagring på flere nivåer i lav- og middelklassesystemer er en teknologi for å optimalisere lagringskostnadene for systemer med utpregede belastningsujevnheter.

Snapshot

Uansett hvor mye vi snakker om påliteligheten til lagringssystemer, er det mange muligheter for å miste data som ikke er avhengig av maskinvareproblemer. Dette kan være virus, hackere eller annen utilsiktet sletting/korrupsjon av data. Av denne grunn er sikkerhetskopiering av produksjonsdata en integrert del av en ingeniørs jobb.

Et øyeblikksbilde er et øyeblikksbilde av et volum på et tidspunkt. Når du arbeider med de fleste systemer, som virtualisering, databaser, etc. vi må ta et slikt øyeblikksbilde hvorfra vi kopierer dataene til en sikkerhetskopi, mens vår IS vil trygt kunne fortsette å jobbe med dette volumet. Men det er verdt å huske at ikke alle øyeblikksbilder er like nyttige. Ulike leverandører har forskjellige tilnærminger til å lage øyeblikksbilder relatert til deres arkitektur.

CoW (Copy-On-Write). Når du prøver å skrive en datablokk, blir dens originale innhold kopiert til et spesielt område, hvoretter skrivingen fortsetter normalt. Dette forhindrer datakorrupsjon inne i øyeblikksbildet. Naturligvis forårsaker alle disse "parasittiske" datamanipulasjonene ekstra belastning på lagringssystemet, og av denne grunn anbefaler ikke leverandører med lignende implementeringer å bruke mer enn et dusin øyeblikksbilder, og ikke bruke dem i det hele tatt på høyt belastede volumer.

RoW (Redirect-on-Write). I dette tilfellet fryser det opprinnelige volumet naturlig, og når du prøver å skrive en datablokk, skriver lagringssystemet data til et spesielt område på ledig plass, og endrer plasseringen av denne blokken i metadatatabellen. Dette lar deg redusere antall omskrivingsoperasjoner, noe som til slutt eliminerer fallet i ytelse og fjerner restriksjoner på øyeblikksbilder og antall.

Øyeblikksbilder er også av to typer i forhold til applikasjoner:

Søknadskonsistens. I øyeblikket for å lage et øyeblikksbilde, trekker lagringssystemet en agent i forbrukerens operativsystem, som tvangsskyller diskbuffere fra minne til disk og tvinger applikasjonen til å gjøre dette. I dette tilfellet, når du gjenoppretter fra et øyeblikksbilde, vil dataene være konsistente.

Krasj konsekvent. I dette tilfellet skjer ingenting slikt, og øyeblikksbildet opprettes som det er. I tilfelle gjenoppretting fra et slikt øyeblikksbilde, er bildet identisk med det som ville skje hvis strømmen plutselig ble slått av og noe tap av data er mulig, fast i cacher og aldri når disken. Slike øyeblikksbilder er lettere å implementere og forårsaker ikke ytelsesforringelse i applikasjoner, men er mindre pålitelige.

Hvorfor trengs øyeblikksbilder på lagringssystemer?

• Agentløs sikkerhetskopiering direkte fra lagringssystemet
• Lag testmiljøer basert på ekte data
• Når det gjelder fillagringssystemer, kan den brukes til å lage VDI-miljøer ved å bruke øyeblikksbilder av lagringssystem i stedet for en hypervisor
• Sørg for lave RPOer ved å lage planlagte øyeblikksbilder med en frekvens som er betydelig høyere enn sikkerhetskopieringsfrekvensen

Kloning

Volumkloning - fungerer på et lignende prinsipp som øyeblikksbilder, men brukes ikke bare for å lese data, men for å jobbe fullt ut med det. Vi er i stand til å få en nøyaktig kopi av volumet vårt, med alle dataene på det, uten å lage en fysisk kopi, noe som vil spare plass. Vanligvis brukes volumkloning enten i Test&Dev eller hvis du vil sjekke funksjonaliteten til noen oppdateringer på IS. Kloning vil tillate deg å gjøre dette så raskt og økonomisk som mulig når det gjelder diskressurser, fordi Kun endrede datablokker vil bli skrevet.

Replikering / journalføring

Replikering er en mekanisme for å lage en kopi av data på et annet fysisk lagringssystem. Vanligvis har hver leverandør en proprietær teknologi som bare fungerer innenfor sin egen linje. Men det finnes også tredjepartsløsninger, inkludert de som fungerer på hypervisornivå, for eksempel VMware vSphere Replication.

Funksjonaliteten til proprietære teknologier og brukervennligheten til dem er vanligvis mye bedre enn universelle, men de viser seg å være ubrukelige når det for eksempel er nødvendig å lage en kopi fra NetApp til HP MSA.

Replikering er delt inn i to undertyper:

Synkron. Ved synkron replikering sendes skriveoperasjonen til det andre lagringssystemet umiddelbart og utførelsen bekreftes ikke før det eksterne lagringssystemet bekrefter. På grunn av dette øker tilgangsforsinkelsen, men vi har en nøyaktig speilkopi av dataene. De. RPO = 0 ved tap av hovedlagringssystemet.

asynkron. Skriveoperasjoner utføres kun på hovedlagringssystemet og bekreftes umiddelbart, mens de samtidig akkumuleres i en buffer for batchoverføring til det eksterne lagringssystemet. Denne typen replikering er relevant for mindre verdifulle data, eller for kanaler med lav båndbredde eller høy latens (typisk for avstander over 100 km). Følgelig er RPO = pakkesendingsfrekvens.

Ofte, sammen med replikering, er det en mekanisme hogst diskoperasjoner. I dette tilfellet er et spesielt område tildelt for logging og registrering av operasjoner med en viss dybde i tid, eller begrenset av volumet av loggen, lagres. For visse proprietære teknologier, for eksempel EMC RecoverPoint, er det integrasjon med systemprogramvare som lar deg koble bestemte bokmerker til en spesifikk loggoppføring. Takket være dette er det mulig å rulle tilbake tilstanden til et volum (eller lage en klone) ikke bare til 23. april, 11 timer 59 sekunder 13 millisekunder, men til øyeblikket før “DROP ALL TABLES; BEGÅ."

Metro klynge

Metro cluster er en teknologi som lar deg lage toveis synkron replikering mellom to lagringssystemer på en slik måte at fra utsiden ser dette paret ut som ett lagringssystem. Den brukes til å lage klynger med geografisk adskilte armer på metroavstander (mindre enn 100 km).

Basert på eksempelet på bruk i et virtualiseringsmiljø, lar metroclusteret deg lage et datalager med virtuelle maskiner, tilgjengelig for opptak fra to datasentre samtidig. I dette tilfellet opprettes en klynge på hypervisornivå, bestående av verter i forskjellige fysiske datasentre, koblet til dette datalageret. Som lar deg gjøre følgende:

• Full automatisering av gjenopprettingsprosessen etter døden til et av datasentrene. Uten ekstra midler vil alle VM-er som kjører i det avdøde datasenteret automatisk startes på nytt i det gjenværende. RTO = høy tilgjengelig klynge timeout (15 sekunder for VMware) + tid for å laste operativsystemet og starte tjenester.
• Katastrofeunngåelse eller, på russisk, unngå katastrofer. Dersom det planlegges strømforsyningsarbeid i datasenter 1, så har vi mulighet til å migrere hele den viktige lasten til datasenter 2 non-stop på forhånd, før arbeidet starter.

Virtualisering

Lagringsvirtualisering er teknisk sett bruk av volumer fra et annet lagringssystem som disker. En lagringsvirtualiserer kan ganske enkelt overføre andres volum til forbrukeren som sitt eget, samtidig speile det til et annet lagringssystem, eller til og med lage en RAID fra eksterne volumer.
Klassiske representanter i lagringsvirtualiseringsklassen er EMC VPLEX og IBM SVC. Og selvfølgelig lagringssystemer med virtualiseringsfunksjonalitet - NetApp, Hitachi, IBM / Lenovo Storwize.

Hvorfor kan det være nødvendig?

• Redundans på lagringssystemnivå. Det lages et speil mellom volumene, og den ene halvparten kan være på HP 3Par, og den andre på NetApp. Og virtualisereren er fra EMC.
• Flytt data med minimal nedetid mellom lagringssystemer fra forskjellige produsenter. La oss anta at data må migreres fra den gamle 3Par, som vil bli avskrevet, til den nye Dell. I dette tilfellet kobles forbrukerne fra 3Par, volumene overføres under VPLEX og presenteres for forbrukerne på nytt. Siden ikke litt har endret seg på volumet, fortsetter arbeidet. Prosessen med å speile volumet til den nye Dell starter i bakgrunnen, og ved fullføring er speilet ødelagt og 3Par deaktivert.
• Organisering av metroklynger.

Komprimering/deduplisering

Komprimering og deduplisering er teknologier som lar deg spare diskplass på lagringssystemet. Det er verdt å nevne med en gang at ikke alle data er gjenstand for komprimering og/eller deduplisering i prinsippet, mens noen typer data komprimeres og dedupliseres bedre, og noen – omvendt.

Det er 2 typer komprimering og deduplisering:

På linje — komprimering og deduplisering av datablokker skjer før disse dataene skrives til disk. Dermed beregner systemet bare hashen til blokken og sammenligner den i tabellen med de eksisterende. For det første er det raskere enn bare å skrive til disk, og for det andre kaster vi ikke bort ekstra diskplass.

Post - når disse operasjonene utføres på allerede registrerte data som ligger på disker. Følgelig blir dataene først skrevet til disk, og først da beregnes hashen og unødvendige blokkeringer slettes og diskressurser frigjøres.

Det er verdt å si at de fleste leverandører bruker begge typer, noe som lar dem optimalisere disse prosessene og dermed øke effektiviteten. De fleste lagringsleverandører har verktøy som lar deg analysere datasettene dine. Disse verktøyene fungerer i henhold til den samme logikken som er implementert i lagringssystemet, så det estimerte effektivitetsnivået vil være det samme. Husk også at mange leverandører har ytelsesgarantiprogrammer som lover minst like god ytelse for visse (eller alle) datatyper. Og du bør ikke overse dette programmet, for ved å beregne systemet for oppgavene dine, med tanke på effektivitetskoeffisienten til et bestemt system, kan du spare volum. Det er også verdt å vurdere at disse programmene er designet for AFA-systemer, men takket være kjøp av et mindre volum SSD-er enn HDD-er i klassiske systemer, vil dette redusere kostnadene, og hvis ikke lik kostnadene for et disksystem, så komme ganske nærme det.

modell

Og her kommer vi til det rette spørsmålet.

"De tilbyr meg to lagringsalternativer - ABC SuperStorage S600 og XYZ HyperOcean 666v4, hva anbefaler du?"

Blir til "Her tilbyr de meg to lagringsalternativer - ABC SuperStorage S600 og XYZ HyperOcean 666v4, hva anbefaler du?

Målbelastningen er blandede virtuelle VMware-maskiner med produksjon/test/utviklingsløkker. Test = produktiv. 150 TB hver med en toppytelse på 80 000 IOPS 8 kb blokk 50 % tilfeldig tilgang 80/20 lese-skriving. 300 TB for utvikling, 50 000 IOPS er nok, 80 tilfeldig, 80 skriv.

Produktivitet antagelig i metroklyngen RPO = 15 minutter RTO = 1 time, utvikling i asynkron replikering RPO = 3 timer, test på ett sted.

Det vil være en 50TB DBMS, logging ville vært fint for dem.

Vi har Dell-servere overalt, gamle Hitachi-lagringssystemer, de kan knapt takle, vi planlegger å øke belastningen med 50 % når det gjelder volum og ytelse.»

Som de sier, inneholder et riktig formulert spørsmål 80 % av svaret.

mer informasjon

Hva du bør lese i tillegg ifølge forfatterne

bøker

• Olifer og Olifer "Datanettverk". Boken skal bidra til å systematisere og kanskje bedre forstå hvordan dataoverføringsmediet for IP/Ethernet-lagringssystemer fungerer
• "EMC Informasjonslagring og -administrasjon." En utmerket bok om det grunnleggende om lagringssystemer, hvorfor, hvordan og hvorfor.

Forum og chatter

• Diskusjoner om lagring
• Nutanix / IT russisk diskusjonsklubb
• VMware User Group Russland
• Russian Backup User Group

Generelle anbefalinger

Priser

Nå, når det gjelder priser - generelt, hvis det er priser for lagringssystemer, er de vanligvis listepriser, hvorfra hver kunde mottar en individuell rabatt. Størrelsen på rabatten består av et stort antall parametere, så det er rett og slett umulig å forutsi hvilken endelig pris bedriften din vil motta uten å spørre distributøren. Men samtidig har det nylig begynt å dukke opp lavprismodeller i vanlige databutikker, som f.eks. nix.ru eller xcom-shop.ru. Her kan du umiddelbart kjøpe systemet du er interessert i til en fast pris, som alle datakomponenter.

Men jeg vil merke med en gang at en direkte sammenligning med TB/$ ikke er riktig. Hvis vi nærmer oss det fra dette synspunktet, vil den billigste løsningen være en enkel JBOD + server, som ikke vil gi verken fleksibiliteten eller påliteligheten som et fullverdig lagringssystem med to kontroller gir. Dette betyr ikke i det hele tatt at JBOD er ​​ekkelt og et ekkelt skittent triks, du trenger bare igjen å forstå hvordan og til hvilke formål du vil bruke denne løsningen. Du kan ofte høre at det ikke er noe å bryte i JBOD, det er bare ett bakplan. Imidlertid svikter også bakplan noen ganger. Alt går i stykker før eller siden.

Totalt

Det er nødvendig å sammenligne systemer med hverandre, ikke bare etter pris, eller ikke bare etter ytelse, men etter totalen av alle indikatorer.

Kjøp HDD bare hvis du er sikker på at du trenger HDD. For lav belastning og ukomprimerbare datatyper, ellers, er det verdt å vende seg til SSD-lagringseffektivitetsgarantiprogrammer, som de fleste leverandører nå har (og de fungerer virkelig, selv i Russland), men alt avhenger av applikasjonene og dataene som vil bli plassert på dette lagringssystemet.

Ikke gå for billig. Noen ganger skjuler disse mange ubehagelige øyeblikk, hvorav Evgeniy Elizarov beskrev i artiklene sine om Infortrend. Og at denne billigheten til slutt kan slå tilbake på deg. Ikke glem - "gjæringen betaler to ganger."

Kilde: www.habr.com