Jeg er en stor fan af Ceph, den open source, massivt skalerbare softwaredefinerede storage-løsning, der er baseret på open source. Dens evne til at helbrede sig selv og klare sig selv i forbindelse med ellers traumatiske klyngehændelser (åh, du har mistet en node? intet problem!), kombineret med dens mangel på single points of failure, gør den til en af mine favoritter.
Nedenfor er der tre enkle principper, der kan hjælpe med at drive designet af store eller små klynger.
Hvis dit hovedfokus er dollars pr. megabyte lagerplads, så vil du naturligt nok søge mod de servere, der kan tage det største antal diske, og de største diske, du kan få.
Træd varsomt her. Der er et par overvejelser med “smalle og dybe” klynger:
- Hver knude rummer en større procentdel af din klynges data. Eksempel: I en klynge med tre knuder indeholder hver knude 33 % af dine data. I en klynge med ti knudepunkter er det kun 10 % pr. knudepunkt. Tab af en enkelt knude i en lille klynge vil resultere i væsentlig mere datamigration, især når klyngen begynder at fylde, og potentielt en afbrydelse, hvis du ikke har konfigureret din klynges fulde og næsten fulde forhold korrekt.
- Tvinger mere netværkstrafik over færre knuder. Ceph er et netværksbaseret lagringssystem, så med færre noder tvinger du en masse klienttrafik over færre NIC’er. Dette bliver værre, når antallet af diske pr. knude øges, da du har flere OSD’er, der konkurrerer om den begrænsede båndbredde. Værre er det, at under genoprettelseshændelser konkurrerer din genoprettelsestrafik med klient I/O over dit netværk, hvilket yderligere påvirker brugeroplevelsen.
- For høje antal diske pr. knude kan diskcontrolleren være en flaskehals, hvis den ikke har tilstrækkelig båndbredde til at transportere alle dine diske ved fuld hastighed.
- Den øgede genoprettelses- og helingstid, når du mister en hel knude, da flere data skal replikeres og genoprettes.
Den samlede klyngeydelse skalerer meget godt, når antallet af knuder øges. Her kan du finde en sammenligning af en 3-node vs. 5-node klynge med BlueStore.
Hvis du sigter mod en stor klynge, skal du modstå fristelsen til at pakke alle diskene ind i så få noder som muligt.
For at opsummere:
- Ceph skalerer meget godt, når antallet af knuder øges.
- Har du for få knuder i klyngen, placerer du flere af dine klyngedata på hver knude, hvilket øger recovery I/O og recovery-tider.
- Du kan starte med så lidt som tre noder, men hvis du har råd til at sprede dine diske over flere noder, er det bedre at gøre det.
Vær generøs med netværket
Det nytter ikke noget at sætte hurtige medier i en server for derefter at hænge dem ud med en 1GbE-netværksforbindelse. Sigt efter 10GbE til produktion, som minimum, og se hellere efter at have flere 10Gb-interfaces, der er forbundet med Link Aggregation Control Protocol (LACP) for at øge båndbredden. Ceph er et netværksbaseret lagringssystem, så en ting, som klyngen ikke bør mangle, er netværksbåndbredde.
Separer altid dit netværk med offentlig adgang fra dit interne klyngenetværk. Det offentlige netværk vil bære klienttrafik, mens det interne netværk vil bære heartbeat-, replikerings- og genoprettelsestrafik mellem OSD’er. Hvis du kan undvære NIC’erne, skal du føre disse to netværk over separate grænseflader. Ved at adskille dem forbedrer du klienternes reaktionsevne under genoprettelseshændelser og hjælper genoprettelseshændelserne til at afslutte hurtigere, da genoprettelses-I/O ikke konkurrerer med klient-I/O på den samme NIC.
Husk også, at det interne netværk bærer din replikeringstrafik, så hver skrivning på det offentlige netværk vil medføre (n-1) skrivninger på det interne netværk, hvor n er antallet af replikaer. Ceph vil kun kvittere for en skrivning til klienten, når den er blevet skrevet til journal/WAL’erne på alle replikaer – så du ønsker ikke, at replikationsskrivningerne bliver flaskehalset på netværket. Hvis du gør stor brug af replikerede pools, skal du overveje at dimensionere dit klyngenetværk til at være n-1 gange større end det offentlige netværk.
Sidst skal du af hensyn til redundans sikre dig, at du kabler dine noder til redundante top of rack-switche. Du ønsker ikke at miste en hel knude – eller et sæt knuder – fordi en enkelt switch har fejlet!
For at opsummere:
- 10Gbit Ethernet til produktion som et minimum.
- Separer dine offentlige og klyngenetværk, ideelt set på forskellige NIC’er, men i det mindste i forskellige VLAN’er/undernet.
- Husk på (n-1) tommelfingerreglen for replikerede data – overvej at dimensionere dit interne netværk til at være n-1 gange større end det offentlige.
- Glem ikke at lægge kabler til redundans og at etablere dine forbindelser korrekt på operativsystemniveau.
- Og som en ekstra ting: Glem ikke jumbo frames på dine grænseflader!
Flashmedier til BlueStore-metadata.
Ceph bekræfter først en skrivning til klienten, når dataene er blevet skrevet til WAL-loggen (write-ahead log) i den primære OSD og til WAL’erne i alle replikaer. Så jo hurtigere skrivningen til WAL’en er, jo hurtigere vil Ceph kvittere for skrivningen, og jo bedre skrive IOPS for klienten.
Dine WAL’er og ideelt set dine BlueStore RocksDB-metadata bør være på det hurtigste medie, du kan få – SSD som minimum og NVMe, hvis det er muligt. Hvis du opbygger en klynge med fuld HDD, skal du kraftigt overveje at bruge lidt ekstra pr. node og tilføje mindst to hurtige medieenheder til metadata og WAL.
For at undgå flaskehalse på din hurtige medieenhed skal du overveje den vedvarende skrivehastighed på dine datadiske og sammenligne den med den vedvarende skrivehastighed på din hurtige enhed. Hvis din harddisk kan skrive med 100 MB/s vedvarende, og din SSD kan klare 500 MB/s vedvarende, så vil du ved mere end 4-5 OSD’er pr. SSD blive flaskehalset af SSD’en til skrivninger. NVMe er perfekt til denne brugssituation, da deres vedvarende skrivehastigheder kan nå op i gigabyte pr. sekund.
Sidst skal du altid have mere end én SSD/NVMe-enhed pr. knude til metadata/WAL for at sikre, at du ikke mister alle OSD’er på knuden, hvis en metadata-enhed fejler.
For at opsummere:
- Ceph bekræfter en skrivning til en klient, når den er blevet skrevet til WAL’en på den primære OSD og WAL’erne på alle replikaer. Det gør den for at bevare integriteten af dine data.
- WAL og RocksDB bør være på det hurtigste medie, du kan få – ideelt set NVMe – for at få et svar til klienten så hurtigt som muligt.
- Du skal ikke overabonnere dine hurtige enheder til din WAL/RocksDB. Hvis du gør det, flytter du blot flaskehalsen til din hurtige enhed.
- Hav mere end én hurtig enhed for at undgå at miste alle OSD’er på en node, hvis din WAL-enhed fejler.
Summarum
Ceph er et netværksbaseret softwaredefineret lagringssystem, der skalerer horisontalt usædvanligt godt. Ovenstående er blot nogle få principper, der kan hjælpe dig med at sammensætte et system med høj ydeevne – gå ikke for smalt eller dybt, hold klyngen fodret med båndbredde, og brug hurtige medier til dine metadata og WAL.