Inledning
Det är dags att köpa förvaring. Vilken ska man ta, vem ska man lyssna på? Säljare A pratar om leverantör B, och sedan finns det integratör C, som säger motsatsen och råder leverantör D. I en sådan situation kommer till och med en erfaren lagringsarkitekts huvud att snurra, speciellt med alla nya leverantörer och SDS och hyperkonvergens som är på modet i dag.
Så, hur räknar du ut allt och inte blir en dåre? vi ( Anton Zhbankov och Evgeniy Elizarov) låt oss försöka prata om detta på ren ryska.
Artikeln har många likheter och är egentligen en förlängning av "” när det gäller att välja lagringssystem och se över lagringstekniker. Vi ska kort titta på den allmänna teorin, men vi rekommenderar att du också läser den här artikeln.
För vad
Du kan ofta se en situation där en ny person kommer till ett forum eller en specialiserad chatt, såsom Storage Discussions, och ställer frågan: "här erbjuder de mig två lagringsalternativ - ABC SuperStorage S600 och XYZ HyperOcean 666v4, vad rekommenderar du ?”
Och förvirringen börjar om vem som har vilka funktioner i genomförandet av fruktansvärda och oförståeliga funktioner, som för en oförberedd person är helt kinesiska.
Så den viktigaste och allra första frågan som du måste ställa dig själv långt innan du jämför specifikationer i kommersiella förslag är VARFÖR? Varför behövs detta lagringssystem?
Svaret kommer att vara oväntat, och mycket Tony Robbins stil - att lagra data. Tack, kapten! Och ändå, ibland går vi så djupt in i att jämföra detaljer att vi glömmer varför vi gör allt detta i första hand.
Så uppgiften för ett datalagringssystem är att lagra och ge tillgång till DATA med en given prestanda. Vi börjar med data.
Data
Data typ
Vilken typ av data planerar vi att lagra? En mycket viktig fråga som kan eliminera många lagringssystem från ens övervägande. Till exempel planerar du att lagra videor och foton. Du kan omedelbart stryka över system utformade för slumpmässig åtkomst i små block, eller system med proprietära funktioner i komprimering/deduplicering. Dessa kan helt enkelt vara utmärkta system, vi vill inte säga något dåligt. Men i det här fallet kommer deras styrkor antingen att bli svaga (video och foton är inte komprimerade) eller helt enkelt avsevärt öka kostnaden för systemet.
Omvänt, om den avsedda användningen är ett upptaget transaktions-DBMS, kommer utmärkta multimediastreamingsystem som kan leverera gigabyte per sekund att vara ett dåligt val.
Datavolym
Hur mycket data planerar vi att lagra? Kvantitet utvecklas alltid till kvalitet, detta bör aldrig glömmas bort, särskilt i vår tid av exponentiell tillväxt i datavolymen. Petabyte-klasssystem är inte längre ovanliga, men ju större petabytekapacitet, desto mer specifikt blir systemet, desto mindre tillgänglig kommer den vanliga funktionaliteten hos små och medelstora direktåtkomstsystem att vara. Det är trivialt eftersom blockåtkomststatistiktabellerna ensamma blir större än den tillgängliga mängden RAM på kontrollerna. För att inte tala om kompression/tiering. Låt oss säga att vi vill byta komprimeringsalgoritmen till en kraftfullare och komprimera 20 petabyte data. Hur lång tid tar det: sex månader, ett år?
Å andra sidan, varför bry sig om du behöver lagra och bearbeta 500 GB data? Endast 500. Hushålls-SSD (med låg DWPD) av denna storlek kostar ingenting. Varför bygga en Fibre Channel-fabrik och köpa exklusiva externa lagringssystem som kostar motsvarande en gjutjärnsbro?
Hur stor andel av det totala antalet är heta data? Hur ojämn är belastningen sett till datamängden? Det är här nivåbaserad lagringsteknik eller Flash Cache kan vara till stor hjälp om mängden heta data är liten jämfört med totalen. Eller vice versa, med en enhetlig belastning genom hela volymen, vilket ofta finns i streamingsystem (videoövervakning, vissa analyssystem), kommer sådana tekniker inte att ge någonting och kommer bara att öka kostnaden/komplexiteten för systemet.
IC
Den andra sidan av datan är informationssystemet som använder datan. En IS har en uppsättning krav som ärver data. För mer information om IS, se "Virtualiserad datacenterdesign."
Krav på motståndskraft/tillgänglighet
Krav på feltolerans/datatillgänglighet ärvs från IS som använder dem och uttrycks i tre siffror - RPO, RTO, tillgänglighet.
tillgänglighet — Andelen under en viss tidsperiod under vilken uppgifterna är tillgängliga för att arbeta med dem. Vanligtvis uttryckt som ett antal 9. Till exempel betyder två nior per år att tillgängligheten är 99 %, annars tillåts 95 timmars otillgänglighet per år. Tre nior - 9,5 timmar per år.
RPO / RTO är inte totala indikatorer, utan för varje incident (olycka), i motsats till tillgänglighet.
RPO — mängden data som förlorats under en olycka (i timmar). Till exempel, om säkerhetskopiering sker en gång om dagen, är RPO = 24 timmar. De där. I händelse av en katastrof och fullständig förlust av lagringssystemet kan data gå förlorade upp till 24 timmar (från ögonblicket för säkerhetskopieringen). Baserat på den RPO som anges för IS, skrivs till exempel säkerhetskopieringsbestämmelser. Baserat på RPO kan du också förstå hur mycket synkron/asynkron datareplikering som behövs.
RTO — tid för att återställa tjänsten (dataåtkomst) efter en katastrof. Baserat på det givna RTO-värdet kan vi förstå om ett metrokluster behövs, eller om enkelriktad replikering är tillräcklig. Behöver du ett högklassigt lagringssystem för flera kontroller?
Prestationskrav
Även om detta är en mycket uppenbar fråga, är det där de flesta svårigheterna uppstår. Beroende på om du redan har någon form av infrastruktur eller inte, kommer sätt att samla in nödvändig statistik att byggas upp.
Du har redan ett lagringssystem och letar efter en ersättare eller vill köpa ett annat för expansion. Allt är enkelt här. Du förstår vilka tjänster du redan har och vilka du planerar att implementera inom en snar framtid. Utifrån aktuella tjänster har du möjlighet att samla in prestationsstatistik. Bestäm det aktuella antalet IOPS och aktuell latens - vilka är dessa indikatorer och räcker de för dina uppgifter? Detta kan göras både på själva datalagringssystemet och från de värdar som är anslutna till det.
Dessutom måste du titta inte bara på den aktuella belastningen, utan under en viss period (helst en månad). Se vad de maximala topparna är under dagen, vilken belastning backupen skapar osv. Om ditt lagringssystem eller dess mjukvara inte ger dig en komplett uppsättning av dessa data, kan du använda det kostnadsfria RRDtool, som kan fungera med de flesta av de mest populära lagringssystemen och switcharna och kan ge dig detaljerad prestandastatistik. Det är också värt att titta på belastningen på värdarna som arbetar med detta lagringssystem, för specifika virtuella maskiner, eller exakt vad som körs på denna värd.
Det är värt att notera separat att om förseningarna på volymen och datalagringen som finns på denna volym skiljer sig ganska avsevärt, bör du vara uppmärksam på ditt SAN-nätverk, det finns en stor sannolikhet att det finns problem med det och innan du köper en ny system, är det värt att undersöka denna fråga , eftersom det finns en mycket stor sannolikhet att öka prestandan för det nuvarande systemet.
Du bygger en infrastruktur från grunden, eller köper ett system för någon ny tjänst, vars belastningar du inte är medveten om. Det finns flera alternativ: kommunicera med kollegor på specialiserade resurser för att försöka ta reda på och förutsäga belastningen, kontakta en integratör som har erfarenhet av att implementera liknande tjänster och som kan beräkna belastningen åt dig. Och det tredje alternativet (vanligtvis det svåraste, särskilt om det gäller hemskrivna eller sällsynta applikationer) är att försöka ta reda på prestandakraven från systemutvecklarna.
Och observera att det mest korrekta alternativet ur praktisk tillämpningssynpunkt är en pilot på nuvarande utrustning, eller utrustning som tillhandahålls för testning av en leverantör/integratör.
Speciella krav
Specialkrav är allt som inte faller under kraven på prestanda, feltolerans och funktionalitet för direkt bearbetning och tillhandahållande av data.
Ett av de enklaste specialkraven för ett datalagringssystem kan kallas "alienable storage media". Och det blir omedelbart klart att detta datalagringssystem måste innehålla ett bandbibliotek eller helt enkelt en bandenhet som säkerhetskopian dumpas på. Varefter en specialutbildad person signerar bandet och stolt bär det till ett speciellt kassaskåp.
Ett annat exempel på ett specialkrav är en skyddad stötsäker design.
var
Den andra huvudkomponenten vid val av ett visst lagringssystem är information om VAR detta lagringssystem kommer att finnas. Utgående från geografi eller klimatförhållanden, och slutar med personal.
Kund
För vem är detta lagringssystem planerat? Frågan har följande skäl:
Statlig kund/kommers.
Den kommersiella kunden har inga begränsningar och är inte ens skyldig att hålla anbud, förutom i enlighet med sina egna interna regler.
En statlig kund är en annan sak. 44 Federal Law och andra nöjen med anbud och tekniska specifikationer som kan ifrågasättas.
Kunden är under sanktion
Tja, frågan här är väldigt enkel - valet begränsas endast av de erbjudanden som är tillgängliga för en given kund.
Interna bestämmelser / leverantörer / modeller tillåtna för köp
Frågan är också extremt enkel, men du måste komma ihåg den.
Var fysiskt
I denna del tar vi upp alla frågor om geografi, kommunikationskanaler och mikroklimat i boendets lokaler.
personal
Vem kommer att arbeta med detta lagringssystem? Detta är inte mindre viktigt än vad själva lagringssystemet kan göra.
Oavsett hur lovande, coolt och underbart förvaringssystemet från leverantör A är, är det nog ingen mening med att installera det om personalen bara vet hur man arbetar med leverantör B, och det inte finns några planer på ytterligare inköp och pågående samarbete med A.
Och naturligtvis är den andra sidan av frågan hur tillgänglig utbildad personal är på en given geografisk plats direkt i företaget och potentiellt på arbetsmarknaden. För regioner kan det vara mycket meningsfullt att välja lagringssystem med enkla gränssnitt eller möjligheten att fjärrcentralisera hanteringen. Annars kan det någon gång bli oerhört smärtsamt. Internet är fullt av historier om hur en ny anställd som kom, gårdagens student, konfigurerade en sådan sak att hela kontoret dödades.
Miljö
Och naturligtvis är en viktig fråga i vilken miljö detta lagringssystem kommer att fungera.
- Hur är det med strömförsörjning/kylning?
- Vilken koppling
- Var kommer den att installeras?
- Etc.
Ofta tas dessa frågor för givna och inte särskilt övervägda, men ibland är det de som kan vända allt.
Det
Säljare
Från och med idag (mitten av 2019) kan den ryska lagringsmarknaden delas in i 5 kategorier:
- Den högsta divisionen är väletablerade företag med ett brett utbud av diskhyllor från de enklaste till hi-end (HPE, DellEMC, Hitachi, NetApp, IBM / Lenovo)
- Andra divisionen - företag med en begränsad linje, nischaktörer, seriösa SDS-leverantörer eller växande nykomlingar (Fujitsu, Datacore, Infinidat, Huawei, Pure, etc.)
- Tredje divisionen - nischlösningar i lågklass, billiga SDS, avancerade produkter baserade på ceph och andra öppna projekt (Infortrend, Starwind, etc.)
- SOHO-segment - små och ultrasmå lagringssystem på hem-/småkontorsnivå (Synology, QNAP, etc.)
- Importersatta lagringssystem - detta inkluderar både hårdvara i den första divisionen med ommärkta etiketter och sällsynta representanter för den andra (RAIDIX, vi ger dem den andra i förväg), men huvudsakligen är detta den tredje divisionen (Aerodisk, Baum, Depo, etc.)
Uppdelningen är ganska godtycklig och betyder inte alls att det tredje eller SOHO-segmentet är dåligt och inte kan användas. I specifika projekt med en tydligt definierad datamängd och belastningsprofil kan de fungera mycket bra och överträffa den första divisionen med avseende på pris/kvalitetsförhållande. Det är viktigt att först besluta om dina mål, tillväxtutsikter och nödvändig funktionalitet - och sedan kommer Synology att tjäna dig troget och ditt hår blir mjukt och silkeslent.
En av de viktiga faktorerna när man väljer en leverantör är den nuvarande miljön. Hur många lagringssystem du redan har och vilka lagringssystem dina ingenjörer kan arbeta med. Behöver du en annan leverantör, en annan kontaktpunkt, kommer du att gradvis migrera hela lasten från leverantör A till leverantör B?
Man bör inte producera enheter utöver vad som är nödvändigt.
iSCSI/FC/File
Det finns ingen konsensus bland ingenjörer i frågan om åtkomstprotokoll, och debatten liknar mer teologiska diskussioner än ingenjörer. Men i allmänhet kan följande punkter noteras:
FCoE mer död än levande.
FC vs iSCSI. En av de viktigaste fördelarna med FC under 2019 jämfört med IP-lagring, en dedikerad fabrik för dataåtkomst, kompenseras av ett dedikerat IP-nätverk. FC har inga globala fördelar jämfört med IP-nätverk, och IP kan användas för att bygga lagringssystem av alla belastningsnivåer, upp till system för tunga DBMS för kärnbankssystemet i en stor bank. Å andra sidan har FC:s död profeterats i flera år nu, men något hindrar det hela tiden. Idag är det till exempel några aktörer på lagringsmarknaden som aktivt utvecklar NVMEoF-standarden. Huruvida han kommer att dela FCoE:s öde - tiden får utvisa.
Filåtkomst är inte heller något ovärdigt att uppmärksammas. NFS/CIFS fungerar bra i produktivitetsmiljöer och har, om den är korrekt utformad, inga fler klagomål än blockprotokoll.
Hybrid / All Flash Array
Klassiska förvaringssystem finns i 2 typer:
- AFA (All Flash Array) - system optimerade för SSD-användning.
- Hybrid - så att du kan använda både hårddisk och SSD eller en kombination av dem.
Deras huvudsakliga skillnad är de lagringseffektivitetstekniker som stöds och den maximala prestandanivån (hög IOPS och låg latens). Båda systemen (i de flesta av deras modeller, exklusive lågsegmentet) kan fungera som både block- och filenheter. Den funktionalitet som stöds beror på systemets nivå, och för yngre modeller är den oftast reducerad till en miniminivå. Detta är värt att uppmärksamma när du studerar egenskaperna hos en viss modell, och inte bara kapaciteten för hela linjen som helhet. Dess tekniska egenskaper, såsom processor, minnesmängd, cache, antal och typer av portar, etc., beror naturligtvis också på systemets nivå. Ur förvaltningssynpunkt skiljer sig AFA:er från hybridsystem (disksystem) endast i implementeringen av mekanismer för att arbeta med SSD-enheter, och även om du använder en SSD i ett hybridsystem betyder det inte alls att du kommer att kunna att uppnå prestationsnivån på nivån för ett AFA-system. I de flesta fall är inline-effektiva lagringsmekanismer inaktiverade på hybridsystem, och deras inkludering leder till förlust i prestanda.
Särskilda lagringssystem
Förutom allmänna lagringssystem, inriktade främst på operativ databehandling, finns det speciella lagringssystem med nyckelprinciper som skiljer sig fundamentalt från de vanliga (låg latens, hög IOPS):
Media.
Dessa system är designade för att lagra och bearbeta stora mediefiler. Resp. fördröjningen blir praktiskt taget oviktig, och möjligheten att skicka och ta emot data i ett brett band i många parallella strömmar kommer i förgrunden.
Deduplicering av lagringssystem för säkerhetskopiering.
Eftersom säkerhetskopior kännetecknas av sin likhet med varandra, vilket är sällsynt under normala förhållanden (den genomsnittliga säkerhetskopian skiljer sig från gårdagens kopia med 1-2%), paketerar denna klass av system extremt effektivt data som registrerats på dem i en ganska liten antal fysiska medier. Till exempel, i vissa fall kan datakomprimeringsförhållanden nå 200 till 1.
Objektlagringssystem.
Dessa lagringssystem har inte de vanliga blockåtkomstvolymerna och fildelningarna, och mest av allt liknar de en enorm databas. Åtkomst till ett objekt som är lagrat i ett sådant system utförs av en unik identifierare eller av metadata (till exempel alla JPEG-formatobjekt med ett skapandedatum mellan XX-XX-XXXX och YY-YY-YYYY).
Efterlevnadssystem.
De är inte så vanliga i Ryssland idag, men de är värda att nämna. Syftet med sådana lagringssystem är garanterad datalagring för att följa säkerhetspolicyer eller regulatoriska krav. Vissa system (till exempel EMC Centera) har implementerat en funktion för att förbjuda radering av data - så fort nyckeln vrids om och systemet går in i detta läge kan varken administratören eller någon annan fysiskt radera data som redan har registrerats.
Proprietära teknologier
Flash-cache
Flash Cache är ett vanligt namn för all proprietär teknologi för att använda flashminne som en andranivåcache. När man använder en flashcache beräknas lagringssystemet vanligtvis ge en jämn belastning från magnetiska skivor, medan toppen betjänas av cachen.
I det här fallet är det nödvändigt att förstå belastningsprofilen och graden av lokalisering av åtkomst till block med lagringsvolymer. Flash-cache är en teknik för arbetsbelastningar med mycket lokaliserade frågor och är praktiskt taget otillämplig för enhetligt laddade volymer (som för analyssystem).
Det finns två flash-cache-implementationer tillgängliga på marknaden:
- Endast läs. I det här fallet cachelagras endast läsdata och skrivning går direkt till diskarna. Vissa tillverkare, som NetApp, tror att skriva till deras lagringssystem redan är optimalt, och cachen hjälper inte alls.
- Läsa skriva. Inte bara läsning, utan även skrivning cachelagras, vilket gör att du kan buffra strömmen och minska effekten av RAID Penalty, och som ett resultat öka den totala prestandan för lagringssystem med en mindre optimal skrivmekanism.
Tiering
Flernivålagring (tröttande) är en teknik för att kombinera nivåer med olika prestandanivåer, såsom SSD och HDD, till en enda diskpool. I händelse av uttalad ojämnhet i åtkomst till datablock, kommer systemet att automatiskt kunna balansera datablock, flytta laddade till en högpresterande nivå och kalla, tvärtom, till en långsammare.
Hybridsystem av lägre och medelklass använder flernivålagring med data som flyttas mellan nivåerna enligt ett schema. Samtidigt är storleken på flernivålagringsblocket för de bästa modellerna 256 MB. Dessa funktioner tillåter oss inte att betrakta nivåbaserad lagringsteknik som en teknik för att öka produktiviteten, vilket många felaktigt tror. Flernivåförvaring i låg- och medelklasssystem är en teknik för att optimera lagringskostnaderna för system med uttalade lastojämnheter.
Snapshot
Oavsett hur mycket vi pratar om lagringssystemens tillförlitlighet finns det många möjligheter att förlora data som inte beror på hårdvaruproblem. Detta kan vara virus, hackare eller annan oavsiktlig radering/korruption av data. Av denna anledning är säkerhetskopiering av produktionsdata en integrerad del av en ingenjörs jobb.
En ögonblicksbild är en ögonblicksbild av en volym vid någon tidpunkt. När man arbetar med de flesta system, såsom virtualisering, databaser, etc. vi måste ta en sådan ögonblicksbild från vilken vi kopierar data till en säkerhetskopia, medan vår IS kommer säkert att kunna fortsätta arbeta med denna volym. Men det är värt att komma ihåg att inte alla ögonblicksbilder är lika användbara. Olika leverantörer har olika tillvägagångssätt för att skapa ögonblicksbilder relaterade till deras arkitektur.
CoW (Copy-On-Write). När du försöker skriva ett datablock kopieras dess ursprungliga innehåll till ett speciellt område, varefter skrivningen fortsätter normalt. Detta förhindrar datakorruption inuti ögonblicksbilden. Naturligtvis orsakar alla dessa "parasitiska" datamanipulationer ytterligare belastning på lagringssystemet och av denna anledning rekommenderar leverantörer med liknande implementeringar inte att använda mer än ett dussin ögonblicksbilder och inte använda dem alls på högt laddade volymer.
RoW (Redirect-on-Write). I det här fallet fryser den ursprungliga volymen naturligt, och när man försöker skriva ett datablock skriver lagringssystemet data till ett speciellt område i ledigt utrymme och ändrar platsen för detta block i metadatatabellen. Detta gör att du kan minska antalet omskrivningsoperationer, vilket i slutändan eliminerar minskningen av prestanda och tar bort restriktioner för ögonblicksbilder och deras antal.
Ögonblicksbilder är också av två typer i förhållande till applikationer:
Applikationskonsistens. I ögonblicket för att skapa en ögonblicksbild, drar lagringssystemet en agent i konsumentens operativsystem, som tvångsspolar diskcacher från minne till disk och tvingar applikationen att göra detta. I det här fallet, när du återställer från en ögonblicksbild, kommer data att vara konsekventa.
Kraschkonsekvent. I det här fallet händer inget sådant och ögonblicksbilden skapas som den är. I fallet med återställning från en sådan ögonblicksbild är bilden identisk med vad som skulle hända om strömmen plötsligt stängdes av och viss dataförlust är möjlig, fast i cacheminnet och aldrig når disken. Sådana ögonblicksbilder är lättare att implementera och orsakar inte prestandaförsämring i applikationer, men är mindre tillförlitliga.
Varför behövs ögonblicksbilder på lagringssystem?
- Agentlös säkerhetskopiering direkt från lagringssystemet
- Skapa testmiljöer baserade på verklig data
- När det gäller fillagringssystem kan den användas för att skapa VDI-miljöer genom att använda ögonblicksbilder av lagringssystem istället för en hypervisor
- Säkerställ låga RPO:er genom att skapa schemalagda ögonblicksbilder med en frekvens som är betydligt högre än säkerhetskopieringsfrekvensen
Kloning
Volymkloning - fungerar på en liknande princip som ögonblicksbilder, men används inte bara för att läsa data, utan för att fullt ut arbeta med det. Vi kan få en exakt kopia av vår volym, med all data på den, utan att göra en fysisk kopia, vilket sparar utrymme. Vanligtvis används volymkloning antingen i Test&Dev eller om du vill kontrollera funktionen hos vissa uppdateringar på din IS. Kloning gör att du kan göra detta så snabbt och ekonomiskt som möjligt när det gäller diskresurser, eftersom Endast ändrade datablock kommer att skrivas.
Replikering / journalföring
Replikering är en mekanism för att skapa en kopia av data på ett annat fysiskt lagringssystem. Vanligtvis har varje leverantör en proprietär teknologi som endast fungerar inom sin egen linje. Men det finns också tredjepartslösningar, inklusive de som fungerar på hypervisornivå, som VMware vSphere Replication.
Funktionaliteten hos proprietära teknologier och användarvänligheten av dem är vanligtvis mycket överlägsen universella, men de visar sig vara otillämpliga när det till exempel är nödvändigt att göra en replik från NetApp till HP MSA.
Replikering är uppdelad i två undertyper:
Synkron. I fallet med synkron replikering skickas skrivoperationen till det andra lagringssystemet omedelbart och exekveringen bekräftas inte förrän fjärrlagringssystemet bekräftar. På grund av detta ökar åtkomstfördröjningen, men vi har en exakt spegelkopia av datan. De där. RPO = 0 vid förlust av huvudlagringssystemet.
asynkron. Skrivoperationer utförs endast på huvudlagringssystemet och bekräftas omedelbart, samtidigt som de ackumuleras i en buffert för batchöverföring till fjärrlagringssystemet. Denna typ av replikering är relevant för mindre värdefull data, eller för kanaler med låg bandbredd eller hög latens (typiskt för avstånd över 100 km). Följaktligen är RPO = paketsändningsfrekvens.
Ofta, tillsammans med replikering, finns det en mekanism skogsavverkning diskoperationer. I detta fall tilldelas ett speciellt område för loggning och inspelningsoperationer av ett visst djup i tiden, eller begränsat av loggens volym, lagras. För vissa proprietära teknologier, såsom EMC RecoverPoint, finns integration med systemprogramvara som gör att du kan länka vissa bokmärken till en specifik loggpost. Tack vare detta är det möjligt att rulla tillbaka tillståndet för en volym (eller skapa en klon) inte bara till 23 april, 11 timmar 59 sekunder 13 millisekunder, utan till ögonblicket före ”SLÄPP ALLA TABELL; BEGÅ."
Metro kluster
Metro cluster är en teknik som låter dig skapa dubbelriktad synkron replikering mellan två lagringssystem på ett sådant sätt att detta par från utsidan ser ut som ett lagringssystem. Den används för att skapa kluster med geografiskt åtskilda armar på tunnelbaneavstånd (mindre än 100 km).
Baserat på exemplet på användning i en virtualiseringsmiljö låter metroklustret dig skapa en databutik med virtuella maskiner, tillgänglig för inspelning från två datacenter samtidigt. I det här fallet skapas ett kluster på hypervisornivå, bestående av värdar i olika fysiska datacenter, kopplade till detta datalager. Vilket låter dig göra följande:
- Full automatisering av återställningsprocessen efter döden av ett av datacentren. Utan några ytterligare medel kommer alla virtuella datorer som körs i det avlidna datacentret att startas om automatiskt i det återstående. RTO = hög tillgänglighet kluster timeout (15 sekunder för VMware) + tid för att ladda operativsystemet och starta tjänster.
- Undvikande av katastrofer eller, på ryska, undvikande av katastrofer. Om strömförsörjningsarbete planeras i datacenter 1 så har vi möjlighet att migrera hela den viktiga belastningen till datacenter 2 nonstop i förväg, innan arbetet påbörjas.
Virtualisering
Lagringsvirtualisering är tekniskt sett användningen av volymer från ett annat lagringssystem som diskar. En lagringsvirtualiserare kan helt enkelt överföra någon annans volym till konsumenten som sin egen, samtidigt spegla den till ett annat lagringssystem, eller till och med skapa en RAID från externa volymer.
Klassiska representanter i lagringsvirtualiseringsklassen är EMC VPLEX och IBM SVC. Och naturligtvis lagringssystem med virtualiseringsfunktionalitet - NetApp, Hitachi, IBM / Lenovo Storwize.
Varför kan det behövas?
- Redundans på lagringssystemnivå. En spegel skapas mellan volymerna, och ena halvan kan vara på HP 3Par och den andra på NetApp. Och virtualiseraren är från EMC.
- Flytta data med minimal stilleståndstid mellan lagringssystem från olika tillverkare. Låt oss anta att data måste migreras från den gamla 3Par, som kommer att skrivas av, till den nya Dell. I det här fallet kopplas konsumenterna från 3Par, volymerna överförs under VPLEX och presenteras för konsumenterna igen. Eftersom inte ett dugg har ändrats på volymen fortsätter arbetet. Processen att spegla volymen till nya Dell börjar i bakgrunden, och när den är klar är spegeln trasig och 3Par inaktiveras.
- Organisation av metrokluster.
Kompression/deduplicering
Komprimering och deduplicering är tekniker som gör att du kan spara diskutrymme på ditt lagringssystem. Det är värt att omedelbart nämna att inte all data är föremål för komprimering och/eller deduplicering i princip, medan vissa typer av data komprimeras och dedupliceras bättre, och vissa - vice versa.
Det finns två typer av komprimering och deduplicering:
I kö — komprimering och deduplicering av datablock sker innan dessa data skrivs till disk. Systemet beräknar alltså bara blockets hash och jämför den i tabellen med de befintliga. För det första är det snabbare än att bara skriva till disk, och för det andra slösar vi inte bort extra diskutrymme.
Inlägg - när dessa operationer utförs på redan inspelade data som finns på diskar. Följaktligen skrivs data först till disken, och först därefter beräknas hashen och onödiga block tas bort och diskresurser frigörs.
Det är värt att säga att de flesta leverantörer använder båda typerna, vilket gör att de kan optimera dessa processer och därmed öka deras effektivitet. De flesta lagringsleverantörer har verktyg som låter dig analysera dina datamängder. Dessa verktyg fungerar enligt samma logik som är implementerade i lagringssystemet, så den uppskattade effektivitetsnivån blir densamma. Tänk också på att många leverantörer har prestandagarantiprogram som lovar minst lika bra prestanda för vissa (eller alla) datatyper. Och du bör inte försumma det här programmet, för genom att beräkna systemet för dina uppgifter, med hänsyn till effektivitetskoefficienten för ett visst system, kan du spara på volymen. Det är också värt att tänka på att dessa program är designade för AFA-system, men tack vare köpet av en mindre volym SSD-enheter än hårddiskar i klassiska system, kommer detta att minska deras kostnad, och om inte lika med kostnaden för ett disksystem, då komma ganska nära det.
Modell
Och här kommer vi till rätt fråga.
"De erbjuder mig två lagringsalternativ - ABC SuperStorage S600 och XYZ HyperOcean 666v4, vad rekommenderar du?"
Förvandlas till "Här erbjuder de mig två lagringsalternativ - ABC SuperStorage S600 och XYZ HyperOcean 666v4, vad rekommenderar du?
Målbelastningen är blandade virtuella VMware-maskiner med produktions-/test-/utvecklingsslingor. Test = produktivt. 150 TB vardera med en toppprestanda på 80 000 IOPS 8kb block 50% slumpmässig åtkomst 80/20 läs-skriv. 300 TB för utveckling, 50 000 IOPS räcker, 80 slumpmässigt, 80 skriv.
Produktivitet förmodligen i metroklustret RPO = 15 minuter RTO = 1 timme, utveckling i asynkron replikering RPO = 3 timmar, test på en plats.
Det kommer att finnas en 50TB DBMS, loggning skulle vara trevligt för dem.
Vi har Dell-servrar överallt, gamla Hitachi-lagringssystem, de klarar sig knappt, vi planerar att öka belastningen med 50 % vad gäller volym och prestanda.”
Som de säger, en korrekt formulerad fråga innehåller 80% av svaret.
ytterligare information
Vad du bör läsa ytterligare enligt författarna
böcker
- Olifer och Olifer "Datornätverk". Boken ska hjälpa till att systematisera och kanske bättre förstå hur dataöverföringsmediet för IP/Ethernet-lagringssystem fungerar
- "EMC Informationslagring och -hantering." En utmärkt bok om grunderna i lagringssystem, varför, hur och varför.
Forum och chattar
Allmänna rekommendationer
priser
Nu när det gäller priser - i allmänhet, om det finns priser för lagringssystem, är de vanligtvis listpriser, från vilka varje kund får en individuell rabatt. Storleken på rabatten består av ett stort antal parametrar, så det är helt enkelt omöjligt att förutse vilket slutpris ditt företag kommer att få utan att fråga distributören. Men samtidigt har nyligen lågprismodeller börjat dyka upp i vanliga datorbutiker, som t.ex. eller . Här kan du direkt köpa det system du är intresserad av till ett fast pris, precis som alla datorkomponenter.
Men jag skulle genast vilja notera att en direkt jämförelse med TB/$ inte är korrekt. Om vi närmar oss det ur denna synvinkel kommer den billigaste lösningen att vara en enkel JBOD +-server, som inte kommer att ge varken den flexibilitet eller tillförlitlighet som ett fullfjädrat lagringssystem med dubbla kontroller ger. Detta betyder inte alls att JBOD är äckligt och ett otäckt smutsigt trick, du behöver bara återigen mycket tydligt förstå hur och för vilka syften du kommer att använda den här lösningen. Man kan ofta höra att det inte finns något att bryta i JBOD, det finns bara ett bakplan. Men bakplan misslyckas också ibland. Allt går sönder förr eller senare.
Totalt
Det är nödvändigt att jämföra system med varandra, inte bara efter pris, eller inte bara efter prestanda, utan genom helheten av alla indikatorer.
Köp endast hårddisk om du är säker på att du behöver hårddisk. För låg belastning och okomprimerbara datatyper, annars är det värt att vända sig till SSD-lagringseffektivitetsgarantiprogram, som de flesta leverantörer nu har (och de fungerar verkligen, även i Ryssland), men allt beror på applikationerna och data som kommer att finnas. på detta lagringssystem.
Gå inte för billigt. Ibland döljer dessa många obehagliga ögonblick, en av dem beskrev Evgeniy Elizarov i sina artiklar om . Och att denna billighet i slutändan kan slå tillbaka på dig. Glöm inte - "snålen betalar två gånger."
Källa: www.habr.com