Jag är ett stort fan av Ceph, den öppna källkodslösningen med massiv skalbarhet för mjukvarudefinierad lagring. Dess förmåga att självläka och klara av annars traumatiska klusterhändelser (du har förlorat en nod? inga problem!), i kombination med bristen på enskilda felpunkter, gör den till en av mina favoriter.
Nedan följer tre enkla principer som kan hjälpa till att styra utformningen av stora eller små kluster.
Om ditt huvudfokus ligger på dollar per megabyte lagringsutrymme, så kan det naturligt nog vara så att du drar dig för att välja de servrar som kan ta emot flest möjliga diskar, och de största diskar du kan få.
Trots försiktigt här. Det finns några överväganden med ”smala och djupa” kluster:
- Varje nod innehåller en större andel av klustrets data. Exempel: I ett kluster med tre noder har varje nod 33 % av dina data. I ett kluster med tio noder är det bara 10 % per nod. Förlust av en enda nod i ett litet kluster kommer att resultera i betydligt mer datamigrering, särskilt när klustret börjar fyllas, och eventuellt ett avbrott om du inte har konfigurerat klustrets fulla och nästan fulla proportioner korrekt.
- Tvingar mer nätverkstrafik över färre noder. Ceph är ett nätverksbaserat lagringssystem, så med färre noder tvingar du fram mycket klienttrafik över färre NIC:er. Detta blir värre när antalet diskar per nod ökar, eftersom du har fler OSD:er som konkurrerar om begränsad bandbredd. Vad värre är, under återställningshändelser konkurrerar din återställningstrafik med klient-I/O över ditt nätverk, vilket ytterligare påverkar användarupplevelsen.
- För höga antal diskar per nod kan diskkontrollern vara en flaskhals om den inte har tillräcklig bandbredd för att transportera alla dina diskar med full hastighet.
- Förbättrad återställnings- och läkningstid när du förlorar en hel nod, eftersom mer data måste replikeras och återställas.
Aggregerad klusterprestanda skalar mycket bra när antalet noder ökar. Här hittar du en jämförelse mellan ett kluster med 3 noder och ett kluster med 5 noder med BlueStore.
Om du siktar på ett stort kluster bör du motstå frestelsen att packa alla diskar i så få noder som möjligt.
För att sammanfatta:
- Ceph skalar mycket bra när antalet noder ökar.
- Har du för få noder i klustret placeras mer av dina klusterdata på varje nod, vilket ökar återhämtnings-I/O och återhämtningstider.
- Du kan börja med så lite som tre noder, men om du har råd att sprida dina diskar över fler noder är det bättre att göra det.
Var generös med nätverket
Det är ingen idé att sätta snabba medier i en server för att sedan hämma dem med en 1GbE-nätverksanslutning. Sikta på minst 10 GbE för produktion och se till att ha flera 10 Gb-gränssnitt som är bundna med Link Aggregation Control Protocol (LACP) för ökad bandbredd. Ceph är ett nätverksbaserat lagringssystem, så en sak som klustret inte bör sakna är nätverksbandbredd.
Separera alltid ditt publika nätverk från ditt interna klusternätverk. Det offentliga nätverket kommer att bära klienttrafik, medan det interna nätverket kommer att bära heartbeat-, replikerings- och återställningstrafik mellan OSD:er. Om du kan avvara NIC:erna bör du föra dessa två nätverk över separata gränssnitt. Att separera dem förbättrar responsen för klienterna under återställningshändelser och hjälper återställningshändelserna att slutföras snabbare eftersom återställnings-I/O inte konkurrerar med klient-I/O på samma NIC.
Håll också i minnet att det interna nätverket bär din replikeringstrafik, så varje skrivning på det offentliga nätverket kommer att orsaka (n-1) skrivningar på det interna nätverket, där n är antalet repliker. Ceph bekräftar en skrivning till klienten först när den har skrivits till journal/WAL:erna på alla repliker – så du vill inte att replikeringsskrivningarna ska bli flaskhalsar på nätverket. Om du använder dig mycket av replikerade pooler bör du överväga att dimensionera ditt klusternätverk så att det är n-1 gånger större än det offentliga nätverket.
Sist för redundans se till att du kablar dina noder till redundanta top of rack-switchar. Du vill inte förlora en hel nod – eller en uppsättning noder – på grund av att en enda switch inte fungerade!
För att sammanfatta:
- 10Gbit Ethernet för produktion som ett minimum.
- Separera dina offentliga nätverk och klusternätverk, helst på olika NIC:er men åtminstone i olika VLAN/subnät.
- Håll dig till tumregeln (n-1) för replikerade data – tänk på att dimensionera ditt interna nätverk så att det är n-1 gånger större än det offentliga.
- Gen glöm inte att kabla för redundans och att upprätta dina förbindelser korrekt på operativsystemnivå.
- Och som extra: glöm inte jumbo frames på dina gränssnitt!
Flashmedia för BlueStore-metadata.
Ceph bekräftar en skrivning till klienten först när data har skrivits till WAL-loggen (write-ahead log) i den primära OSD:n och till WAL:erna i alla repliker. Så ju snabbare skrivningen till WAL:n är, desto snabbare bekräftar Ceph skrivningen och desto bättre skriv-IOPS för klienten.
Dina WAL:er, och helst dina BlueStore RocksDB-metadata, bör ligga på de snabbaste medierna du kan få tag på – minst SSD och NVMe om möjligt. Om du bygger ett kluster med en hel HDD, bör du överväga att spendera lite extra per nod och lägga till minst två snabba mediaenheter för metadata och WAL.
För att undvika flaskhalsar på den snabba mediaenheten bör du överväga den uthålliga skrivhastigheten för dina datadiskar och jämföra den med den uthålliga skrivhastigheten för din snabba enhet. Om din hårddisk kan skriva med 100 MB/s ihållande och din SSD kan hantera 500 MB/s ihållande, kommer fler än 4-5 OSD:er per SSD att bli flaskhalsar för SSD:en när det gäller skrivningar. NVMe är perfekt för det här användningsfallet, eftersom deras uthålliga skrivhastigheter kan nå upp till gigabyte per sekund.
Slutningsvis bör du alltid ha mer än en SSD/NVMe-enhet per nod för metadata/WAL för att se till att du inte förlorar alla OSD:er på noden om en metadata-enhet går sönder.
För att sammanfatta:
- Ceph bekräftar en skrivning till en klient när den har skrivits till WAL för den primära OSD:n och WAL för alla repliker. Det gör den för att bevara integriteten hos dina data.
- WAL och RocksDB bör finnas på de snabbaste medierna du kan få – helst NVMe – för att få ett svar till klienten så snabbt som möjligt.
- Överteckna inte dina snabba enheter för din WAL/RocksDB. Om du gör det flyttar du bara flaskhalsen till din snabba enhet.
- Har du mer än en snabb enhet så undviker du att förlora alla OSD:er på en nod om din WAL-enhet går sönder.
Summering up
Ceph är ett nätverksbaserat mjukvarudefinierat lagringssystem som skalar horisontellt exceptionellt bra. Ovanstående är bara några principer som hjälper dig att sätta ihop ett högpresterande system – gå inte för smalt eller djupt, håll klustret försett med bandbredd och använd snabba medier för dina metadata och WAL.