Sammanfattning
Idag, på förmiddagen, har vi haft fått en presentation och genomgång om Ceph som var mycket bra! Ceph är ett lagringskluster och används för fjärranslutet lagring.
Ceph består av fyra delar, Monitorering, Managering, Objekt lagring och Checksum. Monitors håller koll på klustrets tillstånd, upprätthåller en karta över klustret, OSD, MD5 och CRUSH.
Managers är en demon som ansvarar för att hålla kolla på körtid, metriker och hur klustret mår.
OSD (Object Storage Daemon) är en demon som främst lagrar all data men även hanterar data replikation, återhämtning, balansering och hjälper till med information för Monitors och Managers.
MDSs lagrar all metadata för CephFS.
Vi gick även igenom ZFS cache system ARC (Adaptive Replacement Cache) som är tillför att kan kunna hantera stora mängder av data. ARC använder dynamiskt ca 45% av den totala RAM-kapaciteten som standard, detta är för att snabbt kunna hantera data och undvika/underlätta köer som sker när hårdiskarna inte hinner skriva tillräckligt snabbt. Problemet här är att det inte sker i kärnan av Linux utan som en egen service. Vilket medför att monitoringsprogram inte kan se de vad av cachen som faktiskt används, utan tror istället att de 45% RAM används hela tiden.
På eftermiddagen så förberedde vi några containrar för att testa ARC-systemet. Vi la upp ca 10st containrar på en av servrarna och satte igång några tjänster. Därefter började vi skriva runt 80GB till diskarna på tre av containrarna samtidigt och tittade vad som hände.
Det vi kunde se var att “waiting for I/O”, alltså hårddisken, hamnade på runt 5.0-6.0. ARC har då som sagt 45% av RAM-kapaciteten att leka med (vilket är runt 56GB), vilket den gör och använder 100%. När vi nu har lite siffror så testar vi att sätta en limit på 8GB av vad ARC får använda som max kapacitet. Därefter gör vi en omstart på servern för att de nya parametrarna ska kicka igång.
Väl inne igen kör vi samma tester, men nu ligger vi på runt 12.0-14.0 i “waiting for I/O”, vilket är betydligt högre och ARC används 100%. Det är dock ingen överdriven höjning om man jämför 56GB mot 8GB. Med den slutsatsen känner vi att vi kan höja ARC’s limit med det dubbla, alltså 16GB och startar om servern.
Direkt efter uppstarten så kollar vi även på vad ARC ligger på efter en omstart. Det är då drygt 4,5% vilket motsvarar 600-700MB i idle tillstånd.
Samma test körs och vi ligger nu på 5.0-6.0 i “waiting for I/O” igen och 100% av ARC används. Efter att skrivning till disk är färdigt, så ser vi att 85% av RAM-kapaciteten fortfarande ligger kvar som “användt” RAM utrymme, fast att ARC inte ens använder det. Det vi inte vet är om ARC släpper lös det RAM utrymmet om exempelvis andra RAM-hungriga processer behöver komma åt det. Det får dock bli ett äventyr för en annan dag, Gokväll!
Förstår jag vad som jag förväntas lära mig?
Det är viktigt att jag har förståelse för hur man felsöker exempelvis ovannämnt problem.
Har jag sett liknande fenomen tidigare?
Ett liknande fenomen som jag är medveten om är att exempelvis XFS är ett RAM-hungrigt filsystem, dock tänkt för slöare snurrdiskar.
Vilken metod kan jag använda för att befästa det jag lärt mig?
På exakt samma vis som jag har gjort idag. Felsöka, försöka förstå, summera.
Saknar jag någon kunskap för att kunna klara av #1? - Vad.
Fler påhittiga sätt att felsöka på känner jag att jag måste blir duktigare på. Kommer säkerligen med tiden.