Met het toenemende gebruik van Rook willen we het hebben over de verborgen complicaties en problemen die u onderweg kunt tegenkomen.
Over mezelf: Ervaring met het beheren van Ceph sinds versie Hammer, oprichter van de community. op Telegram.
Om niet zomaar te praten, zal ik verwijzen naar de goedgekeurde Hubram-berichten (volgens de rating) over problemen met Ceph. De meeste problemen in deze berichten ben ik ook tegengekomen. Links naar het gebruikte materiaal aan het einde van het bericht.
In het bericht over Rook vermelden we Ceph niet zomaar — Rook is in wezen Ceph verpakt in Kubernetes, wat betekent dat het al zijn problemen overneemt. Laten we beginnen met de problemen met Ceph.
Vereenvoudiging van clusterbeheer
Een van de voordelen van Rook is het gebruiksgemak van Ceph via Kubernetes.
Ceph bevat echter meer dan 1000 parameters voor configuratie, terwijl we via Rook slechts een kleiner deel ervan kunnen aanpassen.
Voorbeeld in Luminous
> ceph daemon mon.a config show | wc -l
1401
Rook wordt gepositioneerd als een handige manier om Ceph te installeren en bij te werken.
Er zijn geen problemen met het installeren van Ceph zonder Rook — een Ansible-playbook kan binnen 30 minuten worden geschreven, maar er zijn veel problemen bij het bijwerken.
Citaat uit een bericht van Krok
Voorbeeld: onjuiste werking van crush-tunables na de update van Hammer naar Jewel.
> ceph osd crush show-tunables
{
…
«straw_calc_version»: 1,
«allowed_bucket_algs»: 22,
«profile»: «unknown»,
«optimal_tunables»: 0,
…
}
Zelfs binnen de minor versies kunnen er problemen optreden.
Voorbeeld: Update 12.2.6 die de cluster in een health err-status brengt en conditioneel corrupte PG's.
Niet updaten, wachten en testen? Maar we gebruiken Rook toch ook voor het gemak van updates.
Complexiteit van disaster recovery in de cluster met Rook.
Voorbeeld: OSD valt uit met fouten. U vermoedt dat het probleem in een van de configuratieparameters ligt en wilt de configuratie voor een specifieke daemon wijzigen, maar het kan niet omdat u Kubernetes en DaemonSet heeft.
Er is geen alternatief. ceph tell osd.Num injectargs werkt niet — de OSD ligt immers plat.
Complexiteit van debugging
Voor sommige instellingen en prestatietests is het nodig om rechtstreeks verbinding te maken met de socket van de OSD-daemon. In het geval van Rook moet u eerst de juiste container vinden, daar naar binnen gaan, het ontbrekende debuggereedschap ontdekken en erg teleurgesteld zijn.
Complexiteit van het geleidelijk opbouwen van OSD's.
Voorbeeld: OSD valt uit door OOM, er begint een herbalancering en daarna vallen de volgende.
Oplossing: Verhoog OSD één voor één, wacht tot deze volledig in het cluster is opgenomen en verhoog de volgende. (Meer details in het rapport Ceph. Anatomie van een catastrofe).
In het geval van baremetal-installaties gebeurt dit eenvoudig handmatig; in het geval van Rook en één OSD per node zijn er geen grote problemen, maar problemen met het sequentieel opstarten zullen ontstaan als OSD > 1 op een node.
Natuurlijk zijn ze oplosbaar, maar we brengen Rook voor vereenvoudiging en krijgen complicaties.
De moeilijkheid om limieten voor Ceph-demonen te bepalen.
Voor baremetal-installatie van Ceph is het relatief eenvoudig om de benodigde middelen voor het cluster te berekenen — er zijn formules en er zijn onderzoeken. Bij het gebruik van zwakke CPU's moet je echter toch een reeks prestatietests uitvoeren, leren wat Numa is, maar dat is nog steeds eenvoudiger dan in Rook.
In het geval van Rook moet je naast de te berekenen geheugengrenzen ook een CPU-limiet instellen.
En hier moet je hard werken aan prestatietests. Bij te lage limieten krijg je een langzamer cluster, bij het instellen van unlim krijg je actief CPU-gebruik tijdens het rebalanceerproces, wat een negatieve invloed zal hebben op je applicaties in Kubernetes.
Netwerkproblemen v1
Voor Ceph wordt aangeraden een 2x10Gb-netwerk te gebruiken. Eén voor klantverkeer, de ander voor de operationele behoeften van Ceph (rebalance). Als je met Ceph op baremetal werkt, is deze scheiding eenvoudig in te stellen; als je met Rook werkt, zal het scheiden van netwerken problemen voor je veroorzaken, aangezien niet elke clusterconfiguratie het toestaat om twee verschillende netwerken aan een pod te leveren.
Netwerkproblemen v2
Als je besluit netwerken niet te scheiden, dan zal tijdens het rebalance de Ceph-verkeer de gehele bandbreedte vullen en zullen je applicaties in Kubernetes traag zijn of crashen. Je kunt de snelheid van rebalance van Ceph verlagen, maar dan loop je het risico dat de tweede node uit het cluster valt vanwege schijfproblemen of OOM, en dan heb je gegarandeerd read-only op het cluster.
Langdurige rebalance — langdurige vertragingen van applicaties.
Citaat uit het rapport Ceph. Anatomie van een catastrofe.
Prestaties van het testcluster:
Een schrijfoperatie van 4 KB duurt 1 ms, met een doorvoersnelheid van 1000 bewerkingen/seconde in één thread.
Een operatie van 4 MB (objectgrootte) duurt 22 ms, met een doorvoersnelheid van 45 bewerkingen/seconde.
Daarom, wanneer één van de drie domeinen uitvalt, bevindt het cluster zich een tijdje in een gedegradeerde staat en zullen de helft van de actieve objecten zich over verschillende versies verspreiden, waardoor de helft van de schrijfbewerkingen zal beginnen met een geforceerd herstel.
We berekenen de tijd voor geforceerd herstel ongeveer - schrijfbewerkingen naar een gedegradeerd object.
Eerst lezen we 4 MB in 22 ms, schrijven we 22 ms, en daarna schrijven we 1 ms voor 4 KB eigen gegevens. In totaal kost één schrijfbewerking naar een gedegradeerd object op SSD 45 ms, terwijl de standaardprestatie 1 ms was - een prestatieverlies van 45 keer.
Hoe hoger ons percentage gedegradeerde objecten, hoe ernstiger de situatie wordt.
Het blijkt dat de snelheid van herbalancering cruciaal is voor de correcte werking van het cluster.
Specifieke serverinstellingen voor Ceph
Ceph vereist soms specifieke tuning van de host.
Bijvoorbeeld: sysctl-instellingen en JumboFrame, sommige van deze instellingen kunnen een negatieve invloed hebben op uw payload.
De werkelijke noodzaak van Rook blijft ter discussie.
Als je in de cloud bent, heb je opslag van je cloudprovider, wat veel handiger is.
Als je op je eigen servers bent, is het beheer van Ceph eenvoudiger zonder Kubernetes.
Huur je servers bij een low-cost hostingprovider? Dan staat je veel plezier te wachten met het netwerk, de latentie en de bandbreedte, wat duidelijk een negatieve invloed heeft op Ceph.
Kortom: De implementatie van Kubernetes en de implementatie van opslag zijn verschillende taken met verschillende invoers en verschillende oplossingsvarianten - deze mixen betekent een mogelijk gevaarlijke trade-off ten gunste van de één of de ander. Het combineren van deze oplossingen zal zelfs in het ontwerpfase zeer lastig zijn, en er is ook nog een exploitatieperiode.
Lijst van gebruikte literatuur:
Maar u zegt Ceph… is het echt zo goed?
Ceph. Anatomie van een ramp
Bron: habr.com
