In verband met de groeiende populariteit van Rook wil ik het graag hebben over de valkuilen en problemen die je onderweg te wachten staan.
Over mij: Ervaring met ceph-beheer vanaf de hamerversie, oprichter van de gemeenschap per telegram.
Om niet ongegrond te zijn, zal ik verwijzen naar door Habr geaccepteerde berichten (afgaande op de beoordeling) over problemen met ceph. Ik ben ook de meeste problemen in deze berichten tegengekomen. Links naar het gebruikte materiaal staan aan het einde van het bericht.
In het bericht over Rook noemen we ceph niet voor niets: Rook is in wezen ceph verpakt in kubernetes, wat betekent dat het al zijn problemen erft. Laten we beginnen met ceph-problemen.
Vereenvoudig clusterbeheer
Een van de voordelen van Rook is het gemak waarmee ceph via kuberentes kan worden beheerd.
Ceph bevat echter meer dan 1000 parameters voor configuratie, terwijl we tegelijkertijd via toren slechts een minderheid ervan kunnen bewerken.
Voorbeeld op Luminous
> ceph daemon mon.a configuratieshow | wc -l
1401
Rook is gepositioneerd als een handige manier om ceph te installeren en bij te werken
Er zijn geen problemen met het installeren van ceph zonder Rook - het ansible-playbook is in 30 minuten geschreven, maar er zijn veel problemen met het updaten.
Citaat uit het bericht van Krok
Voorbeeld: crush tunables werken niet correct na het updaten van hummer naar juweel
> ceph osd crush show-tunables
{
...
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
"profiel": "onbekend",
"optimale_afstemmingen": 0,
...
}
Maar zelfs binnen kleinere versies zijn er problemen.
Voorbeeld: Update 12.2.6 brengt het cluster in de gezondheidsfoutstatus en voorwaardelijk verbroken PG
Niet updaten, wachten en testen? Maar we lijken Rook onder meer te gebruiken voor het gemak van updates.
Complexiteit van het noodherstelcluster in Rook
Voorbeeld: OSD valt met een golf van fouten aan zijn voeten. U vermoedt dat het probleem in een van de parameters in de configuratie zit. U wilt de configuratie voor een specifieke daemon wijzigen, maar dat lukt niet omdat u kubernetes en DaemonSet heeft.
Er is geen alternatief. ceph tell osd.Num injectargs werkt niet - de OSD liegt.
Moeilijkheidsgraad bij het debuggen
Voor sommige opstellingen en prestatietests is een directe verbinding met de osd-socket van de daemon vereist. In het geval van Rook moet je eerst de gewenste container vinden, er vervolgens in gaan, ontdekken dat de tooling ontbreekt voor debuggen en erg overstuur zijn.
Moeilijkheden bij het opeenvolgend verhogen van de OSD
Voorbeeld: OSD valt in OOM, het opnieuw in evenwicht brengen begint, waarna de volgende vallen.
Oplossing: Verhoog de OSD één voor één, wacht tot deze volledig in het cluster is opgenomen en open de volgende. (Meer details in het Ceph-rapport. Anatomie van een ramp).
In het geval van een baremetal-installatie gebeurt dit eenvoudigweg met de hand; in het geval van Rook en één OSD per node zijn er geen bijzondere problemen; problemen met afwisselend tillen zullen optreden als OSD > 1 per node.
Natuurlijk kunnen ze worden opgelost, maar we gebruiken Rook om dingen te vereenvoudigen, maar om meer complexiteit te krijgen.
Moeilijkheid bij het selecteren van grenzen voor ceph-demonen
Voor een baremetal-installatie van ceph is het vrij eenvoudig om de benodigde middelen voor een cluster te berekenen - er zijn formules en onderzoek beschikbaar. Als je een zwakke CPU gebruikt, zul je nog steeds een aantal prestatietests moeten uitvoeren om erachter te komen wat Numa is, maar het is nog steeds eenvoudiger dan Rook.
In het geval van Rook heb je, naast de geheugenlimieten die kunnen worden berekend, de vraag om een CPU-limiet in te stellen.
En hier zul je hard moeten werken met prestatietests. Als u de limieten verlaagt, krijgt u een langzaam cluster; als u unlim instelt, krijgt u actief CPU-gebruik tijdens het opnieuw in evenwicht brengen, wat een slecht effect zal hebben op uw applicaties in Kubernetes.
Netwerkproblemen v1
Voor ceph wordt aanbevolen om een netwerk van 2x10GB te gebruiken. Eén voor clientverkeer, de andere voor cef-servicebehoeften (herbalancering). Als je met ceph op baremetal leeft, dan is deze verdeling eenvoudig te configureren, als je met Rook leeft, zal de verdeling op netwerken voor problemen zorgen, vanwege het feit dat niet elke clusterconfiguratie je toestaat om twee verschillende netwerken aan de pod te voeden .
Netwerkproblemen v2
Als u weigert netwerken te scheiden, zal het ceph-verkeer bij het opnieuw in evenwicht brengen het hele kanaal verstoppen en zullen uw applicaties in Kubernetes vertragen of crashen. Je kunt de snelheid van het opnieuw in evenwicht brengen van ceph verlagen, maar dan krijg je door het langdurig opnieuw in evenwicht brengen een verhoogd risico dat het tweede knooppunt via schijven of OOM uit het cluster valt, en is er al een gegarandeerde alleen-lezen voor het cluster.
Lange herbalancering - lange applicatievertragingen
Citaat uit het bericht van Ceph. Anatomie van een ramp.
Clusterprestaties testen:
Een schrijfbewerking van 4 KB duurt 1 ms, de prestatie is 1000 bewerkingen/seconde in 1 thread.
Een bewerking van 4 MB (objectgrootte) duurt 22 ms, de prestatie is 45 bewerkingen/seconde.
Wanneer één op de drie domeinen faalt, bevindt het cluster zich dus enige tijd in een verslechterde toestand en wordt de helft van de actieve objecten over verschillende versies verdeeld. Vervolgens begint de helft van de schrijfbewerkingen met een geforceerd herstel.
We berekenen de geforceerde hersteltijd bij benadering: schrijfbewerkingen naar een beschadigd object.
Eerst lezen we 4 MB in 22 ms, schrijven we 22 ms en vervolgens schrijven we in 1 ms 4 KB aan feitelijke gegevens. Een totaal van 45 ms per schrijfbewerking naar een beschadigd object op een SSD, terwijl de standaardprestaties 1 ms waren - een 45-voudige prestatiedaling.
Hoe hoger het percentage gedegradeerde objecten dat we hebben, hoe erger alles wordt.
Het blijkt dat de snelheid van het opnieuw in evenwicht brengen van cruciaal belang is voor de juiste werking van het cluster.
Specifieke serverinstellingen voor ceph
ceph vereist mogelijk specifieke hostafstemming.
Voorbeeld: sysctl-instellingen en hetzelfde JumboFrame, sommige van deze instellingen kunnen een negatieve invloed hebben op uw payload.
De werkelijke behoefte aan Rook blijft twijfelachtig
Als je in de cloud zit, heb je opslagruimte van je cloudprovider, wat veel handiger is.
Als u zich op uw eigen servers bevindt, is het beheren van ceph handiger zonder kubernetes.
Huurt u servers van een goedkope hosting? Dan zul je veel plezier beleven aan het netwerk, de vertragingen en bandbreedte, wat duidelijk een negatieve invloed heeft op ceph.
Totaal: Het implementeren van kuberentes en het implementeren van opslag zijn verschillende taken met verschillende inputs en verschillende oplossingsopties. Het combineren ervan betekent dat je een mogelijk gevaarlijke afweging moet maken ten behoeve van het een of het ander. Het zal erg moeilijk zijn om deze oplossingen te combineren, zelfs in de ontwerpfase, en er is nog een gebruiksperiode.
Lijst met gebruikte literatuur:
Maar jij zegt Ceph... is hij echt zo goed?
Ceph. Anatomie van een ramp
Bron: www.habr.com