Sådan vælger du opbevaring uden at skyde dig selv i foden

Indledning

Det er tid til at købe opbevaring. Hvilken skal man tage, hvem skal man lytte til? Sælger A taler om leverandør B, og så er der integrator C, som fortæller det modsatte og rådgiver leverandør D. I sådan en situation vil selv en erfaren lagerarkitekts hoved snurre, især med alle de nye leverandører og SDS og hyperkonvergens, der er på mode. i dag.

Så hvordan finder du ud af det hele og ikke ender med at blive et fjols? vi (Anton Virtual Anton Zhbankov og legeme Evgeniy Elizarov) lad os prøve at tale om dette på almindelig russisk.
Artiklen har mange ligheder og er faktisk en forlængelse af "Virtualiseret datacenterdesign” i forhold til valg af lagersystemer og gennemgang af lagerteknologier. Vi vil kort se på den generelle teori, men vi anbefaler, at du også læser denne artikel.

Hvad for

Du kan ofte se en situation, hvor en ny person kommer til et forum eller en specialiseret chat, såsom Storage Discussions, og stiller spørgsmålet: "her tilbyder de mig to opbevaringsmuligheder - ABC SuperStorage S600 og XYZ HyperOcean 666v4, hvad anbefaler du ?”

Og forvirringen begynder om, hvem der har hvilke træk ved implementeringen af ​​forfærdelige og uforståelige funktioner, som for en uforberedt person er helt kinesiske.

Så det vigtigste og allerførste spørgsmål, som du skal stille dig selv længe før du sammenligner specifikationer i kommercielle forslag, er HVORFOR? Hvorfor er dette lagersystem nødvendigt?

Svaret vil være uventet, og meget Tony Robbins stil - at gemme data. Tak, kaptajn! Og alligevel går vi nogle gange så dybt i at sammenligne detaljer, at vi glemmer, hvorfor vi gør alt dette i første omgang.

Så opgaven for et datalagringssystem er at gemme og give adgang til DATA med en given ydeevne. Vi starter med data.

Data

Datatype

Hvilken slags data planlægger vi at gemme? Et meget vigtigt spørgsmål, der kan eliminere mange lagringssystemer fra selv overvejelse. For eksempel planlægger du at gemme videoer og billeder. Du kan straks overstrege systemer designet til tilfældig adgang i små blokke, eller systemer med proprietære funktioner i komprimering/deduplikering. Disse kan simpelthen være fremragende systemer, vi ønsker ikke at sige noget dårligt. Men i dette tilfælde vil deres styrker enten blive svage (video og fotos er ikke komprimeret) eller simpelthen øge systemets omkostninger betydeligt.

Omvendt, hvis den påtænkte brug er et travlt transaktions-DBMS, så vil fremragende multimediestreamingsystemer, der er i stand til at levere gigabyte pr. sekund, være et dårligt valg.

Datamængde

Hvor meget data planlægger vi at gemme? Kvantitet udvikler sig altid til kvalitet; dette bør aldrig glemmes, især i vores tid med eksponentiel vækst i datamængden. Petabyte-klasse systemer er ikke længere ualmindeligt, men jo større petabyte kapacitet, jo mere specifikt systemet bliver, jo mindre tilgængelig vil den sædvanlige funktionalitet af små og mellemstore random access-systemer være. Det er trivielt, fordi blokadgangsstatistiktabellerne alene bliver større end den tilgængelige mængde RAM på controllerne. For ikke at nævne kompression/tiering. Lad os sige, at vi vil skifte komprimeringsalgoritmen til en mere kraftfuld og komprimere 20 petabyte data. Hvor lang tid vil det tage: seks måneder, et år?

På den anden side, hvorfor bekymre sig, hvis du skal gemme og behandle 500 GB data? Kun 500. Husholdnings SSD'er (med lav DWPD) af denne størrelse koster ingenting. Hvorfor bygge en Fibre Channel-fabrik og købe avancerede eksterne lagersystemer, der koster det, der svarer til en støbejernsbro?

Hvor stor en procentdel af det samlede antal er hot data? Hvor ujævn er belastningen med hensyn til datavolumen? Det er her tiered storage-teknologi eller Flash Cache kan være meget nyttigt, hvis mængden af ​​varme data er lille sammenlignet med det samlede antal. Eller omvendt, med en ensartet belastning gennem hele volumen, som ofte findes i streamingsystemer (videoovervågning, nogle analysesystemer), vil sådanne teknologier ikke give noget og vil kun øge omkostningerne/kompleksiteten af ​​systemet.

IC

Den anden side af dataene er informationssystemet, der bruger dataene. En IS har et sæt krav, der arver data. For mere information om IS, se "Virtualiseret datacenterdesign."

Krav til robusthed/tilgængelighed

Krav til fejltolerance/datatilgængelighed er nedarvet fra IS, der bruger dem og er udtrykt i tre tal - RPO, RTO, tilgængelighed.

tilgængelighed — andelen i en given periode, hvor data er tilgængelige for at arbejde med dem. Normalt udtrykt som et tal på 9. For eksempel betyder to niere om året, at tilgængeligheden er 99 %, ellers er 95 timers utilgængelighed om året tilladt. Tre niere - 9,5 timer om året.

RPO / RTO er ikke totale indikatorer, men for hver hændelse (ulykke), i modsætning til tilgængelighed.

RPO — mængden af ​​tabte data under en ulykke (i timer). For eksempel, hvis sikkerhedskopiering sker én gang om dagen, så er RPO = 24 timer. De der. I tilfælde af en katastrofe og fuldstændigt tab af lagersystemet kan data gå tabt i op til 24 timer (fra tidspunktet for sikkerhedskopieringen). Baseret på den RPO, der er specificeret for IS, skrives der for eksempel backupregler. Baseret på RPO kan du også forstå, hvor meget synkron/asynkron datareplikering er nødvendig.

RTO — tid til at genoprette tjenesten (dataadgang) efter en katastrofe. Baseret på den givne RTO-værdi kan vi forstå, om der er behov for en metroklynge, eller om ensrettet replikering er tilstrækkelig. Har du brug for et højkvalitets multi-controller-lagringssystem?

Ydelseskrav

Selvom dette er et meget indlysende spørgsmål, er det her, de fleste vanskeligheder opstår. Afhængigt af om du allerede har en form for infrastruktur eller ej, vil der blive bygget måder at indsamle den nødvendige statistik på.

Du har allerede et lagersystem og leder efter en erstatning eller ønsker at købe et andet til udvidelse. Alt er enkelt her. Du forstår, hvilke tjenester du allerede har, og som du planlægger at implementere i den nærmeste fremtid. Baseret på aktuelle services har du mulighed for at indsamle præstationsstatistik. Beslut dig for det aktuelle antal IOPS og aktuelle latens - hvad er disse indikatorer, og er de nok til dine opgaver? Dette kan gøres både på selve datalagringssystemet og fra de værter, der er tilsluttet det.

Desuden skal du ikke kun se på den aktuelle belastning, men over en vis periode (helst en måned). Se hvad de maksimale toppe er i løbet af dagen, hvilken belastning backup'en skaber osv. Hvis dit lagringssystem eller dets software ikke giver dig et komplet sæt af disse data, kan du bruge det gratis RRDtool, som kan arbejde med de fleste af de mest populære lagringssystemer og switches og kan give dig detaljeret ydeevnestatistik. Det er også værd at se på belastningen på værterne, der arbejder med dette lagersystem, for specifikke virtuelle maskiner, eller hvad der præcist kører på denne vært.

Det er værd at bemærke separat, at hvis forsinkelserne på volumen og datalageret, der er placeret på dette volumen, er ret betydeligt forskellige, skal du være opmærksom på dit SAN-netværk, der er stor sandsynlighed for, at der er problemer med det, og før du køber en ny system, er det værd at se på dette problem , fordi der er en meget stor sandsynlighed for at øge ydeevnen af ​​det nuværende system.

Du bygger en infrastruktur fra bunden, eller køber et system til en ny tjeneste, som du ikke er opmærksom på. Der er flere muligheder: kommuniker med kolleger om specialiserede ressourcer for at forsøge at finde ud af og forudsige belastningen, kontakt en integrator, der har erfaring med at implementere lignende tjenester, og som kan beregne belastningen for dig. Og den tredje mulighed (normalt den sværeste, især hvis det drejer sig om hjemmeskrevne eller sjældne applikationer) er at forsøge at finde ud af ydeevnekravene fra systemudviklerne.

Og bemærk venligst, at den mest korrekte mulighed set fra et praktisk anvendelsessynspunkt er en pilot på nuværende udstyr eller udstyr leveret til test af en leverandør/integrator.

Særlige krav

Særlige krav er alt, hvad der ikke falder ind under kravene til ydeevne, fejltolerance og funktionalitet til direkte behandling og levering af data.

Et af de enkleste specielle krav til et datalagringssystem kan kaldes "fremmedelige lagringsmedier." Og det bliver straks klart, at dette datalagringssystem skal omfatte et båndbibliotek eller blot et båndstation, hvorpå sikkerhedskopien dumpes. Hvorefter en specialuddannet person signerer båndet og bærer det stolt til et særligt pengeskab.
Et andet eksempel på et særligt krav er et beskyttet stødsikkert design.

hvor

Den anden hovedkomponent i valget af et bestemt lagersystem er information om HVOR dette lagersystem vil blive placeret. Startende fra geografi eller klimatiske forhold, og slutter med personale.

Kunde

Hvem er dette lagersystem planlagt for? Spørgsmålet har følgende årsager:

Offentlig kunde/kommerciel.
Erhvervskunden har ingen begrænsninger og er ikke engang forpligtet til at afholde udbud, undtagen i overensstemmelse med egne interne regler.

En statskunde er en anden sag. 44 Føderal lov og andre glæder med tilbud og tekniske specifikationer, der kan anfægtes.

Kunden er under sanktioner
Nå, spørgsmålet her er meget enkelt - valget er kun begrænset af de tilbud, der er tilgængelige for en given kunde.

Interne regler / leverandører / modeller tilladt til køb
Spørgsmålet er også ekstremt enkelt, men du skal huske det.

Hvor fysisk

I denne del overvejer vi alle problemer med geografi, kommunikationskanaler og mikroklima i boligens lokaler.

personale

Hvem vil arbejde med dette lagersystem? Dette er ikke mindre vigtigt, end hvad lagersystemet selv kan.
Uanset hvor lovende, sejt og vidunderligt opbevaringssystemet fra leverandør A er, nytter det nok ikke meget i at installere det, hvis personalet kun ved, hvordan de skal arbejde med leverandør B, og der ikke er planer om yderligere indkøb og løbende samarbejde med A.

Og selvfølgelig er den anden side af spørgsmålet, hvor tilgængeligt uddannet personale er på en given geografisk placering direkte i virksomheden og potentielt på arbejdsmarkedet. For regioner kan det give meget mening at vælge lagersystemer med enkle grænseflader eller muligheden for at fjerncentralisere administrationen. Ellers kan det på et tidspunkt blive ulidelig smertefuldt. Internettet er fyldt med historier om, hvordan en ny medarbejder, der ankom, gårsdagens elev, konfigurerede sådan noget, at hele kontoret blev ødelagt.

Miljø

Og selvfølgelig er et vigtigt spørgsmål, i hvilket miljø dette lagersystem vil fungere.

• Hvad med strømforsyning/køling?
• Hvilken forbindelse
• Hvor vil det blive installeret?
• Etc.

Ofte bliver disse spørgsmål taget for givet og ikke særligt overvejede, men nogle gange er det dem, der kan vende alt.

Det

Sælger

Fra i dag (medio 2019) kan det russiske lagermarked opdeles i 5 kategorier:

1. Den højeste division er veletablerede virksomheder med en bred vifte af diskhylder fra de enkleste til hi-end (HPE, DellEMC, Hitachi, NetApp, IBM / Lenovo)
2. Anden division - virksomheder med en begrænset linje, niche-aktører, seriøse SDS-leverandører eller nye tilkommere (Fujitsu, Datacore, Infinidat, Huawei, Pure osv.)
3. Tredje division - nicheløsninger i den lave ende rang, billige SDS, avancerede produkter baseret på ceph og andre åbne projekter (Infortrend, Starwind, etc.)
4. SOHO-segment - små og ultrasmå opbevaringssystemer på hjemme-/lille kontorniveau (Synology, QNAP osv.)
5. Importsubstituerede lagersystemer - dette inkluderer både hardware fra den første division med ommærkede etiketter og sjældne repræsentanter for den anden (RAIDIX, vi giver dem den anden på forhånd), men hovedsageligt er dette den tredje division (Aerodisk, Baum, Depo osv.)

Opdelingen er ret vilkårlig og betyder slet ikke, at det tredje eller SOHO-segment er dårligt og ikke kan bruges. I konkrete projekter med et klart defineret datasæt og belastningsprofil kan de fungere rigtig godt, og de overgår langt første division i forhold til pris/kvalitet. Det er vigtigt først at tage stilling til dine mål, vækstudsigter og påkrævet funktionalitet – og så vil Synology tjene dig trofast, og dit hår bliver blødt og silkeblødt.

En af de vigtige faktorer, når du vælger en leverandør, er det nuværende miljø. Hvor mange lagersystemer har du allerede, og hvilke lagersystemer dine ingeniører kan arbejde med. Har du brug for en anden leverandør, et andet kontaktpunkt, vil du gradvist migrere hele lasten fra leverandør A til leverandør B?

Man bør ikke producere enheder ud over, hvad der er nødvendigt.

iSCSI/FC/File

Der er ingen konsensus blandt ingeniører om spørgsmålet om adgangsprotokoller, og debatten ligner mere teologiske diskussioner end ingeniører. Men generelt kan følgende punkter bemærkes:

FCoE mere død end levende.

FC vs iSCSI. En af de vigtigste fordele ved FC i 2019 i forhold til IP-lagring, en dedikeret fabrik til dataadgang, opvejes af et dedikeret IP-netværk. FC har ingen globale fordele i forhold til IP-netværk, og IP kan bruges til at bygge lagersystemer af ethvert belastningsniveau, op til systemer til tunge DBMS til kernebanksystemet i en stor bank. Til gengæld har FC's død været forudsagt i flere år nu, men noget forhindrer det hele tiden. I dag er nogle aktører på lagermarkedet for eksempel aktivt ved at udvikle NVMEoF-standarden. Om han vil dele FCoE's skæbne - må tiden vise.

Filadgang er heller ikke noget uværdigt til opmærksomhed. NFS/CIFS klarer sig godt i produktivitetsmiljøer og har, hvis den er designet korrekt, ikke flere klager end blokprotokoller.

Hybrid / All Flash Array

Klassiske opbevaringssystemer findes i 2 typer:

1. AFA (All Flash Array) - systemer optimeret til SSD-brug.
2. Hybrid - så du kan bruge både HDD og SSD eller en kombination af dem.

Deres væsentligste forskel er de understøttede teknologier til lagringseffektivitet og det maksimale niveau af ydeevne (høj IOPS og lav latens). Begge systemer (i de fleste af deres modeller, ikke medregnet low-end segmentet) kan fungere som både blok- og filenheder. Den understøttede funktionalitet afhænger af systemets niveau, og for yngre modeller er det oftest reduceret til et minimumsniveau. Dette er værd at være opmærksom på, når du studerer egenskaberne ved en bestemt model, og ikke kun evnerne for hele linjen som helhed. Også dens tekniske egenskaber, såsom processor, mængde af hukommelse, cache, antal og typer af porte osv., afhænger naturligvis også af systemets niveau. Fra et ledelsessynspunkt adskiller AFA'er sig kun fra hybrid (disk) systemer i implementeringen af ​​mekanismer til at arbejde med SSD-drev, og selvom du bruger en SSD i et hybridsystem, betyder det slet ikke, at du vil være i stand til at opnå præstationsniveauet på niveau med et AFA-system. I de fleste tilfælde er inline effektive lagringsmekanismer også deaktiveret på hybridsystemer, og deres inklusion fører til et tab i ydeevne.

Særlige opbevaringssystemer

Ud over lagringssystemer til generelle formål, primært fokuseret på operationel databehandling, er der specielle lagringssystemer med nøgleprincipper, der er fundamentalt forskellige fra de sædvanlige (lav latens, høj IOPS):

Medier.

Disse systemer er designet til lagring og behandling af store mediefiler. hhv. forsinkelsen bliver praktisk talt ligegyldig, og muligheden for at sende og modtage data i et bredt bånd i mange parallelle strømme kommer i forgrunden.

Deduplikering af lagersystemer til backups.

Da sikkerhedskopier er kendetegnet ved deres lighed med hinanden, hvilket er sjældent under normale forhold (den gennemsnitlige sikkerhedskopi adskiller sig fra gårsdagens kopi med 1-2%), pakker denne klasse af systemer ekstremt effektivt de data, der er registreret på dem i en forholdsvis lille antal fysiske medier. For eksempel kan datakomprimeringsforhold i nogle tilfælde nå 200 til 1.

Objektlagringssystemer.

Disse lagersystemer har ikke de sædvanlige blokadgangsvolumener og fildelinger, og mest af alt ligner de en enorm database. Adgang til et objekt, der er gemt i et sådant system, udføres af en unik identifikator eller af metadata (for eksempel alle JPEG-formatobjekter med en oprettelsesdato mellem XX-XX-XXXX og YY-YY-YYYY).

Overholdelsessystem.

De er ikke så almindelige i Rusland i dag, men de er værd at nævne. Formålet med sådanne lagringssystemer er garanteret datalagring for at overholde sikkerhedspolitikker eller lovmæssige krav. Nogle systemer (for eksempel EMC Centera) har implementeret en funktion til at forbyde sletning af data - så snart nøglen drejes og systemet går i denne tilstand, kan hverken administratoren eller andre fysisk slette data, der allerede er registreret.

Proprietære teknologier

Flash cache

Flash Cache er et fællesnavn for alle proprietære teknologier til brug af flashhukommelse som en cache på andet niveau. Når du bruger en flash-cache, beregnes lagersystemet normalt til at give en konstant belastning fra magnetiske diske, mens toppen betjenes af cachen.

I dette tilfælde er det nødvendigt at forstå belastningsprofilen og graden af ​​lokalisering af adgang til blokke af lagervolumener. Flash-cache er en teknologi til arbejdsbelastninger med meget lokaliserede forespørgsler og er praktisk talt uanvendelig til ensartet indlæste volumener (såsom for analysesystemer).

Der er to flash-cache-implementeringer tilgængelige på markedet:

• Læs kun. I dette tilfælde cachelagres kun læste data, og skrivning går direkte til diskene. Nogle producenter, såsom NetApp, mener, at det allerede er optimalt at skrive til deres lagersystemer, og cachen hjælper slet ikke.
• Læse skrive. Ikke kun læsning, men også skrivning cachelagres, hvilket giver dig mulighed for at buffere strømmen og reducere virkningen af ​​RAID Penalty og som et resultat øge den samlede ydeevne for lagersystemer med en mindre optimal skrivemekanisme.

Tiering

Multi-level storage (trættende) er en teknologi til at kombinere niveauer med forskellige ydeevneniveauer, såsom SSD og HDD, i en enkelt diskpool. I tilfælde af udtalte ujævnheder i adgangen til datablokke vil systemet automatisk afbalancere datablokke, flytte indlæste til et højtydende niveau og kolde tværtimod til et langsommere.

Hybride systemer af lavere og middelklasse bruger lagring på flere niveauer med data, der flytter mellem niveauer efter en tidsplan. Samtidig er størrelsen på multi-level storage-blokken for de bedste modeller 256 MB. Disse funktioner tillader os ikke at betragte tiered storage-teknologi som en teknologi til at øge produktiviteten, som mange mennesker fejlagtigt tror. Multi-level storage i lav- og mellemklassesystemer er en teknologi til optimering af lageromkostninger for systemer med udtalte belastningsujævnheder.

Snapshot

Uanset hvor meget vi taler om lagringssystemers pålidelighed, er der mange muligheder for at miste data, der ikke afhænger af hardwareproblemer. Dette kan være virus, hackere eller enhver anden utilsigtet sletning/korruption af data. Af denne grund er sikkerhedskopiering af produktionsdata en integreret del af en ingeniørs job.

Et øjebliksbillede er et øjebliksbillede af et volumen på et eller andet tidspunkt. Når du arbejder med de fleste systemer, såsom virtualisering, databaser mv. vi skal tage et sådant øjebliksbillede, hvorfra vi kopierer dataene til en sikkerhedskopi, mens vores IS sikkert kan fortsætte med at arbejde med denne volumen. Men det er værd at huske på, at ikke alle snapshots er lige nyttige. Forskellige leverandører har forskellige tilgange til at skabe snapshots relateret til deres arkitektur.

CoW (Copy-On-Write). Når du forsøger at skrive en datablok, kopieres dens originale indhold til et særligt område, hvorefter skrivningen forløber normalt. Dette forhindrer datakorruption inde i snapshottet. Naturligvis forårsager alle disse "parasitiske" datamanipulationer yderligere belastning på lagersystemet, og af denne grund anbefaler leverandører med lignende implementeringer ikke at bruge mere end et dusin snapshots og slet ikke bruge dem på højt belastede volumener.

RoW (Redirect-on-Write). I dette tilfælde fryser det originale volumen naturligt, og når du forsøger at skrive en datablok, skriver lagersystemet data til et særligt område i ledig plads, hvilket ændrer placeringen af ​​denne blok i metadatatabellen. Dette giver dig mulighed for at reducere antallet af omskrivningsoperationer, hvilket i sidste ende eliminerer faldet i ydeevne og fjerner begrænsninger på snapshots og deres antal.

Snapshots er også af to typer i forhold til applikationer:

Anvendelseskonsistens. I det øjeblik, hvor et øjebliksbillede oprettes, trækker lagringssystemet en agent i forbrugerens operativsystem, som med magt fjerner diskcaches fra hukommelse til disk og tvinger applikationen til at gøre dette. I dette tilfælde vil dataene være konsistente ved gendannelse fra et snapshot.

Crash konsekvent. I dette tilfælde sker der ikke noget lignende, og øjebliksbilledet oprettes som det er. I tilfælde af gendannelse fra et sådant øjebliksbillede er billedet identisk med, hvad der ville ske, hvis strømmen pludselig blev slukket, og noget tab af data er muligt, sidder fast i caches og aldrig når disken. Sådanne snapshots er nemmere at implementere og forårsager ikke ydeevneforringelse i applikationer, men er mindre pålidelige.

Hvorfor er der brug for snapshots på lagersystemer?

• Agentløs backup direkte fra lagersystemet
• Skab testmiljøer baseret på rigtige data
• I tilfælde af fillagringssystemer kan det bruges til at skabe VDI-miljøer ved at bruge snapshots fra lagersystemet i stedet for en hypervisor
• Sørg for lave RPO'er ved at oprette planlagte snapshots med en frekvens, der er væsentlig højere end backup-frekvensen

Kloning

Volumenkloning - fungerer efter et lignende princip som snapshots, men bruges ikke kun til at læse data, men til at arbejde fuldt ud med det. Vi er i stand til at få en nøjagtig kopi af vores volumen, med alle data på det, uden at lave en fysisk kopi, hvilket vil spare plads. Typisk bruges volumenkloning enten i Test&Dev eller hvis du vil tjekke funktionaliteten af ​​nogle opdateringer på din IS. Kloning vil give dig mulighed for at gøre dette så hurtigt og økonomisk som muligt med hensyn til diskressourcer, fordi Kun ændrede datablokke vil blive skrevet.

Replikering / Journalføring

Replikering er en mekanisme til at oprette en kopi af data på et andet fysisk lagersystem. Typisk har hver leverandør en proprietær teknologi, der kun fungerer inden for sin egen linje. Men der er også tredjepartsløsninger, inklusive dem, der fungerer på hypervisorniveau, såsom VMware vSphere Replication.

Funktionaliteten af ​​proprietære teknologier og brugervenligheden af ​​dem er normalt meget bedre end universelle, men de viser sig at være uanvendelige, når det for eksempel er nødvendigt at lave en replika fra NetApp til HP MSA.

Replikation er opdelt i to undertyper:

Synkron. I tilfælde af synkron replikering sendes skriveoperationen til det andet lagersystem med det samme, og udførelsen bekræftes ikke, før fjernlagersystemet bekræfter. På grund af dette øges adgangsforsinkelsen, men vi har en nøjagtig spejlkopi af dataene. De der. RPO = 0 i tilfælde af tab af hovedlagersystemet.

asynkron. Skrivehandlinger udføres kun på hovedlagersystemet og bekræftes med det samme, mens de samtidig akkumuleres i en buffer til batchtransmission til fjernlagersystemet. Denne type replikering er relevant for mindre værdifulde data eller for kanaler med lav båndbredde eller høj latenstid (typisk for afstande over 100 km). Følgelig er RPO = pakkeafsendelsesfrekvens.

Ofte, sammen med replikation, er der en mekanisme logning disk operationer. I dette tilfælde er et særligt område tildelt til logning og registrering af operationer af en vis dybde i tid, eller begrænset af loggens volumen, lagres. For visse proprietære teknologier, såsom EMC RecoverPoint, er der integration med systemsoftware, der giver dig mulighed for at linke bestemte bogmærker til en specifik logpost. Takket være dette er det muligt at rulle tilstanden af ​​et volumen tilbage (eller oprette en klon) ikke kun til 23. april, 11 timer 59 sekunder 13 millisekunder, men til øjeblikket før “DROP ALL TABLES; BEGÅ."

Metro klynge

Metro cluster er en teknologi, der giver dig mulighed for at skabe tovejs synkron replikering mellem to lagersystemer på en sådan måde, at dette par udefra ligner ét lagersystem. Det bruges til at skabe klynger med geografisk adskilte arme ved metroafstande (mindre end 100 km).

Baseret på eksemplet på brug i et virtualiseringsmiljø giver metroclusteret dig mulighed for at oprette et datalager med virtuelle maskiner, der er tilgængelige for optagelse fra to datacentre på én gang. I dette tilfælde oprettes en klynge på hypervisorniveau, bestående af værter i forskellige fysiske datacentre, forbundet til dette datalager. Hvilket giver dig mulighed for at gøre følgende:

• Fuld automatisering af gendannelsesprocessen efter døden af ​​et af datacentrene. Uden yderligere midler vil alle VM'er, der kører i det afdøde datacenter, automatisk blive genstartet i det resterende. RTO = høj tilgængelighed klynge timeout (15 sekunder for VMware) + tid til at indlæse operativsystemet og starte tjenester.
• Katastrofeundgåelse eller på russisk undgå katastrofer. Hvis der er planlagt strømforsyningsarbejde i datacenter 1, så har vi mulighed for at migrere hele den vigtige belastning til datacenter 2 non-stop på forhånd, inden arbejdet påbegyndes.

Virtualisering

Lagervirtualisering er teknisk set brugen af ​​volumener fra et andet lagersystem som diske. En storage-virtualizer kan simpelthen overføre en andens volumen til forbrugeren som sin egen, samtidig spejle den til et andet lagersystem eller endda oprette et RAID fra eksterne volumener.
Klassiske repræsentanter i storage-virtualiseringsklassen er EMC VPLEX og IBM SVC. Og selvfølgelig lagersystemer med virtualiseringsfunktionalitet - NetApp, Hitachi, IBM / Lenovo Storwize.

Hvorfor kan det være nødvendigt?

• Redundans på lagersystemniveau. Der oprettes et spejl mellem diskenhederne, og den ene halvdel kan være på HP 3Par, og den anden på NetApp. Og virtualizeren er fra EMC.
• Flyt data med minimal nedetid mellem lagersystemer fra forskellige producenter. Lad os antage, at data skal migreres fra den gamle 3Par, som vil blive afskrevet, til den nye Dell. I dette tilfælde afbrydes forbrugerne fra 3Par, mængderne overføres under VPLEX og præsenteres for forbrugerne igen. Da der ikke er ændret en smule på lydstyrken, fortsætter arbejdet. Processen med at spejle lydstyrken til den nye Dell starter i baggrunden, og efter færdiggørelsen er spejlet ødelagt, og 3Par er deaktiveret.
• Organisering af metroklynger.

Kompression/deduplikering

Komprimering og deduplikering er teknologier, der giver dig mulighed for at spare diskplads på dit lagersystem. Det er værd at nævne med det samme, at ikke alle data i princippet er underlagt komprimering og/eller deduplikering, mens nogle typer data komprimeres og deduplikeres bedre, og nogle - omvendt.

Der er 2 typer komprimering og deduplikering:

inline — komprimering og deduplikering af datablokke finder sted, før disse data skrives til disken. Systemet beregner således kun blokkens hash og sammenligner den i tabellen med de eksisterende. For det første er det hurtigere end blot at skrive til disk, og for det andet spilder vi ikke ekstra diskplads.

Indlæg - når disse handlinger udføres på allerede registrerede data, der er placeret på diske. Derfor skrives dataene først til disken, og først derefter beregnes hashen, og unødvendige blokke slettes og diskressourcer frigøres.

Det er værd at sige, at de fleste leverandører bruger begge typer, hvilket giver dem mulighed for at optimere disse processer og derved øge deres effektivitet. De fleste lagerleverandører har værktøjer, der giver dig mulighed for at analysere dine datasæt. Disse hjælpeprogrammer arbejder efter den samme logik, som er implementeret i lagersystemet, så det estimerede effektivitetsniveau vil være det samme. Husk også, at mange leverandører har præstationsgarantiprogrammer, der lover mindst lige så god ydeevne for visse (eller alle) datatyper. Og du bør ikke forsømme dette program, for ved at beregne systemet til dine opgaver under hensyntagen til effektivitetskoefficienten for et bestemt system, kan du spare på volumen. Det er også værd at overveje, at disse programmer er designet til AFA-systemer, men takket være køb af en mindre mængde SSD'er end HDD'er i klassiske systemer, vil dette reducere deres omkostninger, og hvis det ikke svarer til prisen på et disksystem, så komme helt tæt på det.

Model

Og her kommer vi til det rigtige spørgsmål.

"De tilbyder mig to lagermuligheder - ABC SuperStorage S600 og XYZ HyperOcean 666v4, hvad anbefaler du?"

Bliver til "Her tilbyder de mig to opbevaringsmuligheder - ABC SuperStorage S600 og XYZ HyperOcean 666v4, hvad anbefaler du?

Målbelastningen er blandede virtuelle VMware-maskiner med produktions-/test-/udviklingsløkker. Test = produktiv. 150 TB hver med en maksimal ydeevne på 80 IOPS 000kb blok 8% random access 50/80 læse-skrive. 20 TB til udvikling, 300 IOPS er nok, 50 tilfældigt, 000 skriv.

Produktivitet formentlig i metroklyngen RPO = 15 minutter RTO = 1 time, udvikling i asynkron replikation RPO = 3 timer, test på ét sted.

Der vil være en 50TB DBMS, logning ville være rart for dem.

Vi har Dell-servere overalt, gamle Hitachi-lagringssystemer, de kan næsten ikke klare det, vi planlægger at øge belastningen med 50 % med hensyn til volumen og ydeevne.”

Som de siger, indeholder et korrekt formuleret spørgsmål 80% af svaret.

yderligere oplysninger

Hvad du bør læse yderligere ifølge forfatterne

bøger

• Olifer og Olifer "Computernetværk". Bogen vil være med til at systematisere og måske bedre forstå, hvordan datatransmissionsmediet til IP/Ethernet-lagringssystemer fungerer
• "EMC Informationslagring og -styring." En fremragende bog om det grundlæggende i opbevaringssystemer, hvorfor, hvordan og hvorfor.

Fora og chats

• Diskussioner om opbevaring
• Nutanix / IT russisk diskussionsklub
• VMware User Group Rusland
• Russisk backup brugergruppe

Generelle anbefalinger

Priser

Nu, hvad angår priser - generelt, hvis der er priser på lagersystemer, er de normalt Listepriser, hvorfra hver kunde modtager en individuel rabat. Størrelsen af ​​rabatten består af en lang række parametre, så det er simpelthen umuligt at forudsige, hvilken endelig pris din virksomhed vil modtage uden at spørge distributøren. Men samtidig er der på det seneste begyndt at dukke lavprismodeller op i almindelige computerbutikker, som f.eks. nix.ru eller xcom-shop.ru. Her kan du med det samme købe det system, du er interesseret i, til en fast pris, ligesom alle computerkomponenter.

Men jeg vil gerne bemærke med det samme, at en direkte sammenligning med TB/$ ikke er korrekt. Hvis vi griber det an fra dette synspunkt, så vil den billigste løsning være en simpel JBOD+-server, som hverken vil give den fleksibilitet eller pålidelighed, som et fuldgyldigt, dual-controller-lagringssystem giver. Dette betyder slet ikke, at JBOD er ​​ulækkert og et grimt beskidt trick, du skal bare igen meget klart forstå, hvordan og til hvilke formål du vil bruge denne løsning. Man kan ofte høre, at der ikke er noget at bryde i JBOD, der er kun et backplane. Dog fejler backplanes også nogle gange. Alt går i stykker før eller siden.

I alt

Det er nødvendigt at sammenligne systemer med hinanden, ikke kun efter pris eller ikke kun efter ydeevne, men efter helheden af ​​alle indikatorer.

Køb kun HDD, hvis du er sikker på, at du har brug for HDD. For lav belastning og ukomprimerbare datatyper, ellers er det værd at vende sig til SSD-lagereffektivitetsgarantiprogrammer, som de fleste leverandører nu har (og de fungerer virkelig, selv i Rusland), men det hele afhænger af de applikationer og data, der vil blive placeret på dette lagersystem.

Gå ikke efter billigt. Nogle gange skjuler disse en masse ubehagelige øjeblikke, hvoraf den ene Evgeniy Elizarov beskrev i sine artikler om Infortrend. Og at denne billighed i sidste ende kan give bagslag på dig. Glem ikke - "snærren betaler to gange."

Kilde: www.habr.com