Aber du sagst Ceph ... ist es wirklich gut?


    Ich liebe Ceph. Ich arbeite bereits seit 4 Jahren mit ihm zusammen (0.80.x -12.2.612.2.5). Ich bin manchmal so fasziniert von ihm, dass ich Abende und Nächte in seiner Gesellschaft verbringe und nicht mit meiner Freundin. Ich bin mit diesem Produkt auf verschiedene Probleme gestoßen und lebe bis heute mit einigen davon zusammen. Manchmal freute ich mich über einfache Entscheidungen, und manchmal träumte ich davon, mich mit Entwicklern zu treffen, um meine Empörung auszudrücken. Aber Ceph wird immer noch in unserem Projekt verwendet und es ist möglich, dass es für neue Aufgaben verwendet wird, zumindest von mir. In dieser Geschichte werde ich unsere Erfahrung mit Ceph teilen, auf eine bestimmte Art und Weise werde ich darüber sprechen, was mir an dieser Entscheidung nicht gefällt, und vielleicht denjenigen helfen, die sie nur im Auge behalten. Ich wurde dazu gedrängt, diesen Artikel durch Ereignisse zu schreiben, die vor etwa einem Jahr begannen, als Dell EMC ScaleIO, jetzt bekannt als Dell EMC VxFlex OS, für unser Projekt ausgeliefert wurde.


    Dies ist keinesfalls eine Werbung für Dell EMC oder ihr Produkt! Ich persönlich bin nicht besonders gut in großen Unternehmen und Black Boxes wie dem VxFlex OS. Aber wie Sie wissen, ist alles auf der Welt relativ und am Beispiel von VxFlex OS ist es sehr praktisch zu zeigen, was Ceph in Bezug auf den Betrieb ist, und ich werde es versuchen.


    Parameter Es geht um vierstellige Zahlen!


    Ceph-Dienste wie MON, OSD usw. haben unterschiedliche Parameter, um alle Subsysteme zu konfigurieren. Die Parameter werden in einer Konfigurationsdatei festgelegt. Die Dämonen lesen sie zum Zeitpunkt des Starts. Einige Werte können bequem mithilfe des "Injektions" -Mechanismus geändert werden, etwa darunter. Alles ist fast super, wenn Sie den Moment weglassen, dass es hunderte Parameter gibt:

    Hammer:


    > ceph daemon mon.a config show | wc -l
    863

    Leuchtend:


    > ceph daemon mon.a config show | wc -l
    1401

    In zwei Jahren ergeben sich ~ 500 neue Parameter. Im Allgemeinen ist die Parametrisierung cool, es ist nicht cool, dass 80% dieser Liste nur schwer zu verstehen sind. Die nach meiner Einschätzung beschriebene Dokumentation ~ 20% und manchmal mehrdeutig. Die Bedeutung der meisten Parameter muss im github-Projekt oder in den Mailinglisten verstanden werden. Dies ist jedoch nicht immer hilfreich.


    Hier ein Beispiel für einige Parameter, die für mich kürzlich interessant waren. Ich habe sie im Blog eines Ceph-Gadfly gefunden:


    throttler_perf_counter = false  // enable/disable throttler perf counter
    osd_enable_op_tracker = false   // enable/disable OSD op tracking

    Kommentare im Kodex im Sinne von Best Practices. Als ob ich die Wörter verstehe und sogar was sie sind, aber was sie mir geben wird, ist nicht.


    Oder hier: osd_op_threads in Luminous ist weg und nur die Quelle half dabei, einen neuen Namen zu finden: osd_peering_wq-Threads


    Ich mag auch die Tatsache, dass es besonders holivare Parameter gibt. Dann zeigt der Kerl , dass die zunehmenden rgw_num _rados_handles diesen Nutzen :


    und der andere Typ denkt, dass> 1 unmöglich und sogar gefährlich ist .


    Und am liebsten mache ich es, wenn Anfänger in ihren Blogeinträgen Beispiele für die Konfiguration angeben, bei denen alle Parameter aus einem ähnlichen, ähnlichen Blog gedankenlos (ich denke schon) kopiert werden und so viele Parameter, von denen niemand außer dem Autor des Codes weiß, herumlaufen config zu config.


    Ich brenne auch wild mit dem, was sie in Luminous gemacht haben. Es gibt eine super coole Funktion: Parameter werden im laufenden Betrieb geändert, ohne dass Prozesse neu gestartet werden. Sie können zum Beispiel die Parameter eines bestimmten OSD ändern:


    > ceph tell osd.12 injectargs '--filestore_fd_cache_size=512'

    oder setzen Sie "*" anstelle von 12 und der Wert wird in allen OSD-Menüs geändert. Das ist wirklich sehr cool. Aber wie bei Ceph geschieht dies mit dem linken Fuß. Bai Design nicht alle Parameterwerte können im laufenden Betrieb geändert werden. Genauer gesagt, sie können vernetzt werden und erscheinen in der Ausgabe modifiziert, tatsächlich werden jedoch nur einige von ihnen erneut gelesen und erneut angewendet. Beispielsweise können Sie die Größe des Thread-Pools nicht ändern, ohne den Prozess neu zu starten. Damit der Performer des Teams begriff, dass es sinnlos ist, die Parameter auf diese Weise zu ändern, beschlossen sie, eine Nachricht auszudrucken. Ist gesund


    Zum Beispiel:


    > ceph tell mon.* injectargs '--mon_allow_pool_delete=true'
    mon.c: injectargs:mon_allow_pool_delete = 'true' (not observed, change may require restart)
    mon.a: injectargs:mon_allow_pool_delete = 'true' (not observed, change may require restart)
    mon.b: injectargs:mon_allow_pool_delete = 'true' (not observed, change may require restart)

    Mehrdeutig Tatsächlich wird die Entfernung von Pools nach der Injektion möglich. Das heißt, diese Warnung ist für diesen Parameter nicht relevant. Ok, aber es gibt immer noch Hunderte von Parametern, darunter sehr nützliche, die ebenfalls eine Warnung haben und es gibt keine Möglichkeit, ihre tatsächliche Anwendbarkeit zu überprüfen. Im Moment kann ich auch per Code nicht verstehen, welche Parameter nach der Injektion angewendet werden und welche nicht. Um die Zuverlässigkeit zu gewährleisten, müssen Sie die Dienste neu starten, und dies ist wütend. Wütend, weil ich weiß, dass es einen Einspritzmechanismus gibt.


    Wie ist das bei VxFlex OS? Ähnliche Prozesse wie MON (in VxFlex sind MDM), OSD (SDS in VxFlex) haben auch Konfigurationsdateien, in denen etwa ein Dutzend Parameter vorhanden sind. Zwar sprechen ihre Namen auch über nichts, aber es ist gut, dass wir nie darauf zurückgegriffen haben, um wie mit Ceph zu brennen.


    Technischer Dienst


    Wenn Sie Ihre Bekanntschaft mit Ceph mit der aktuellsten Version von heute beginnen, scheint alles in Ordnung zu sein, und ich möchte einen positiven Artikel schreiben. Aber wenn Sie mit ihm in der Version 0.80 leben, dann sieht alles nicht so rosig aus.


    Vor Jewel liefen Ceph-Prozesse als root. In Jewel wurde entschieden, dass sie vom Benutzer 'ceph' aus arbeiten sollten. Dies erforderte eine Änderung des Besitzes aller Verzeichnisse, die von Ceph-Diensten verwendet werden. Es scheint, dass dies? Stellen Sie sich ein OSD vor, das eine 2-TB-SATA-Festplatte mit 70% Kapazität bedient. Wenn eine solche Platte parallel (zu verschiedenen Unterverzeichnissen) abgerufen wird, dauert die vollständige Festplattenauslastung 3-4 Stunden. Stellen Sie sich vor, Sie haben beispielsweise dreihundert solcher Platten. Selbst wenn Sie die Knoten (8-12 Festplatten gleichzeitig chown) aktualisieren, erhalten Sie ein ziemlich langes Update, bei dem der Cluster OSD-Versionen mit unterschiedlichen Versionen und weniger Daten für ein Replikat zum Zeitpunkt der Serverausgabe zur Aktualisierung aufweist. Im Allgemeinen hielten wir es für absurd, bauten Ceph-Pakete neu auf und ließen OSD als root. Entschied Wenn OSD eingeführt oder ersetzt wird, werden wir sie an einen neuen Benutzer übergeben. Jetzt ändern wir 2-3 Platten pro Monat und fügen 1-2 hinzu. Ich denke, wir können damit bis 2022 zurechtkommen.


    CRUSH-Tunables


    CRUSH ist das Herz von Ceph, alles dreht sich darum. Dies ist ein Algorithmus, mit dem auf pseudo-zufällige Weise der Ort der Daten ausgewählt wird und dank derer Clients, die mit dem RADOS-Cluster arbeiten, wissen, auf welchem ​​OSD die von ihnen benötigten Daten (Objekte) gespeichert sind. Die wichtigste Funktion von CRUSH ist, dass keine Metadatenserver wie Lustre oder IBM GPFS (jetzt Spectrum Scale) erforderlich sind. Mit CRUSH können Clients und OSD direkt miteinander interagieren. Natürlich ist es schwierig, den primitiven Objektspeicher von RADOS und Dateisystemen zu vergleichen, den ich als Beispiel angeführt habe, aber ich denke, die Idee ist klar.


    CRUSH-Parameter sind wiederum eine Reihe von Parametern / Flags, die den Betrieb von CRUSH beeinflussen und zumindest theoretisch effizienter werden.


    Beim Upgrade von Hammer auf Jewel (natürlich testen) wurde eine Warnung angezeigt, dass die Parameter des Profils Parameter enthalten, die für die aktuelle Version (Jewel) nicht optimal sind. Es wird daher empfohlen, das Profil auf optimal zu setzen. Im Allgemeinen ist alles klar. Das Dock sagt, dass dies sehr wichtig ist und dies der richtige Weg ist, aber es sagt auch, dass nach dem Umschalten der Daten 10% der Daten wiederbelebt werden. 10% - das klingt nicht beängstigend, aber wir haben uns entschieden zu testen. Bei einem Cluster, etwa zehnmal weniger als das, was verkauft wurde, mit der gleichen Anzahl von PGs pro OSD, die mit Testdaten gefüllt waren, erhielten wir eine Rebellance von 60%! Stellen Sie sich zum Beispiel vor, mit 100 TB an Daten beginnen 60 TB zwischen OSDs zu wechseln, und dies mit einer ständig steigenden Clientlast, die Latenz fordert! Wenn ich noch nicht gesagt habe, bieten wir s3 an, und selbst in der Nacht ist die Belastung des rgw nicht besonders Das sind jetzt 8 und 4 weitere unter statischen Websites (statische Websites). Im Allgemeinen entschieden wir, dass dies nicht unser Weg ist. Umso mehr war es so, dass die neue Version, mit der wir nicht gearbeitet hatten, so rebellisch wurde, zumindest zu optimistisch war. Außerdem hatten wir große Bucket-Indizes, die sich sehr schlecht erholen, und dies war auch der Grund für die Verzögerung des Profilwechsels. Die Indizes werden separat etwas niedriger sein. Am Ende haben wir die Warnung einfach entfernt und beschlossen, später darauf zurückzukommen.


    Beim Wechseln des Profils beim Testen fielen wir auf cephfs-Clients, die sich in CentOS 7.2-Cores befinden, ab, da sie mit dem neueren Hash-Algorithmus, der mit dem neuen Profil geliefert wurde, nicht arbeiten konnten. Wir verwenden keine cephfs im Verkauf, aber wenn verwendet, wäre dies ein weiterer Grund, das Profil nicht zu wechseln.


    Das Dock sagt übrigens, wenn das, was während des Aufstands nicht passiert, nicht zu Ihnen passt, können Sie das Profil zurückrollen. Nach einer Neuinstallation der Hammer-Version und einem Update von Jewel sieht das Profil tatsächlich so aus:


    > ceph osd crush show-tunables
    {
        ...
        "straw_calc_version": 1,
        "allowed_bucket_algs": 22,
        "profile": "unknown",
        "optimal_tunables": 0,
        ...
    }

    Es ist wichtig, dass es "unbekannt" ist. Wenn Sie versuchen, die Rebellion zu stoppen, indem Sie sie auf "Legacy" (wie im Dock angegeben) oder sogar auf "Hammer" umschalten, wird die Rebellance nicht aufhören. optimal. " Im Allgemeinen muss alles gründlich geprüft und überprüft werden, ceph ist kein Vertrauen.


    CRUSH Trade-of


    Wie Sie wissen, ist alles auf dieser Welt ausgeglichen und alle Vorteile sind mit Nachteilen behaftet. Der Nachteil von CRUSH besteht darin, dass PGs ungleichmäßig auf unterschiedliche OSD verteilt sind, selbst wenn sie das gleiche Gewicht haben. Außerdem hindert nichts daran, dass verschiedene PGs mit unterschiedlichen Geschwindigkeiten wachsen, es ist wie eine Hash-Funktion. Insbesondere haben wir einen OSD-Auslastungsbereich von 48-84%, obwohl sie die gleiche Größe und dementsprechend das Gewicht haben. Selbst wir versuchen Server gleich zu machen, aber das ist nur unser Perfektionismus, nicht mehr. Und das Problem mit der Tatsache, dass IOs ungleichmäßig auf Festplatten verteilt sind, ist das Schlimmste, dass, wenn full (95%) mindestens ein OSD in einem Cluster erreicht, die gesamte Aufzeichnung gestoppt wird und der Cluster in Readonly läuft. Der ganze Cluster! Dabei spielt es keine Rolle, dass der Cluster immer noch voll ist. Alles endgültig, wir gehen! Dies ist ein architektonisches Merkmal von CRUSH. Stell dir vor Sie befinden sich im Urlaub, eine Art OSD hat die 85% -Markierung durchbrochen (die erste Warnung ist die Standardeinstellung), und Sie haben 10% auf Lager, um zu verhindern, dass die Aufzeichnung angehalten wird. Und 10% bei einer aktiven Aufnahme ist nicht so viel / lang. Idealerweise benötigt Ceph bei diesem Entwurf eine diensthabende Person, die in solchen Fällen die vorbereitete Anweisung ausführen kann.


    Wir haben uns deshalb entschieden, die Daten im Cluster aus dem Gleichgewicht zu bringen, weil einige OSD-Werte lagen nahe an der Nearfull-Marke (85%).


    Es gibt mehrere Möglichkeiten:


    • Discs hinzufügen

    Am einfachsten, etwas verschwenderisch und nicht sehr effektiv, weil Die Daten selbst bewegen sich möglicherweise nicht von einem überfüllten OSD oder die Bewegung ist unbedeutend.


    • Dauergewicht OSD ändern (GEWICHT)

    Dies führt zu einer Änderung der Gewichtung aller übergeordneten Buckets (CRUSH-Terminologie) in Hierarchie, OSD-Server, Rechenzentrum usw. und infolgedessen zur Bewegung von Daten, einschließlich nicht von den OSDs, von denen aus es notwendig ist.
    Wir haben versucht, ein OSD-Gewicht zu reduzieren, nachdem die Wiederbelebung der Daten mit einem anderen aufgefüllt wurde, dann wurde das dritte verringert, und wir erkannten, dass wir lange Zeit so spielen würden.


    • OSD für nicht permanentes Gewicht ändern (REWEIGHT)

    Dies geschieht beim Aufruf von 'ceph osd reweight-by-usage'. Dies führt zu einer Änderung des sogenannten Justiergewicht-OSD und gleichzeitig ändert sich das Gewicht der übergeordneten Schalen nicht. Dadurch werden die Datenbilanzen zwischen verschiedenen OSDs auf demselben Server sozusagen ohne über den CRUSH hinauszugehen. Dieser Ansatz hat uns sehr gut gefallen, wir haben im Trockenlauf gesehen, was die Änderungen sein werden, und den Verkauf durchführen. Alles war gut, bis der Rebellenprozess in der Mitte einen Einsatz hatte. Wieder googeln, Mailings lesen, mit verschiedenen Optionen experimentieren, und am Ende stellt sich heraus, dass der Stopp auf das Fehlen einiger Parameter im oben genannten Profil zurückzuführen ist. Wieder haben wir die technischen Schulden eingeholt. Infolgedessen haben wir den Weg eingeschlagen, Platten und die ineffizienteste Rebellion hinzuzufügen. Zum Glück mussten wir es trotzdem tun


    Ja, wir wissen von dem in mgr enthaltenen Balancer (Luminous und höher), der das Problem der ungleichmäßigen Verteilung von Daten lösen soll, indem das PG beispielsweise nachts zwischen OSD verschoben wird. Ich habe jedoch noch keine positiven Kritiken über seine Arbeit gehört, selbst im aktuellen Mimic.


    Sie werden wahrscheinlich sagen, dass technische Schulden ein reines Problem sind, und ich werde vielleicht zustimmen. Aber mit Ceph hatten wir vier Jahre lang nur eine Ausfallzeit von s3, die eine ganze Stunde dauerte. Und dann war das Problem nicht in RADOS, sondern in der RGW, die ihre Standard-100-Threads eingab und die meisten Benutzer keine Abfragen ausführten. Es war immer noch am Hammer. Meines Erachtens ist dies ein guter Indikator, der dadurch erreicht wird, dass wir keine plötzlichen Bewegungen machen und alles in Ceph eher skeptisch sind.


    Wild gc


    Wie Sie wissen, ist das Löschen von Daten direkt von der Festplatte eine ziemlich ressourcenintensive Aufgabe. In fortgeschrittenen Systemen wird das Löschen anhängig oder gar nicht durchgeführt. Ceph ist auch ein fortgeschrittenes System, und im Fall des RGW werden beim Löschen eines S3-Objekts die entsprechenden RADOS-Objekte nicht sofort von der Festplatte entfernt. S3-Objekte werden von RGW als gelöscht markiert, und ein separater gc-Stream löscht Objekte direkt aus RADOS-Pools und wird von Festplatten jeweils verschoben. Nach dem Update auf Luminous änderte sich das Verhalten der GC merklich, es begann aggressiver zu arbeiten, obwohl die GC-Parameter gleich blieben. Mit dem Wort, ich meine, merke ich, dass wir begonnen haben, die Arbeit von gc bei der externen Überwachung des Dienstes auf Sprunglatenz zu sehen. Dies wurde von einem hohen IO im Pool rgw.gc. begleitet. Aber das Problem, mit dem wir konfrontiert waren, war viel mehr als nur ein IO.


    0 <cls> /builddir/build/BUILD/ceph-12.2.5/src/cls/rgw/cls_rgw.cc:3284: gc_iterate_entries end_key=1_01530264199.726582828

    Dabei ist 0 am Anfang die Protokollierungsstufe, bei der diese Nachricht gedruckt wird. Die Protokollierung ist jedoch nirgends unter Null. Infolgedessen wurden innerhalb von wenigen Stunden ~ 1 GB Protokolle von einem OSD generiert, und wenn die Ceph-Knoten nicht plattenlos wären, wäre alles in Ordnung (/). Zustandslose Server entpuppen sich. Nach einem Neustart wird der gesamte Status von der Automatisierung gewürfelt. Wie es funktioniert, werde ich irgendwie in einem separaten Artikel beschreiben. Nun ist es wichtig, dass unter "/" 6 GB Speicher zugewiesen werden, von denen normalerweise ~ 4 frei ist. Wir senden alle Protokolle an Graylog und verwenden eine ziemlich aggressive Protokollrotationsrichtlinie. In der Regel treten keine Probleme mit dem Überlauf von Festplatten / RAM auf. Aber dafür waren wir nicht bereit, mit 12 OSD auf dem Server "/" wurde es sehr schnell gefüllt, Die Dienstoffiziere reagierten nicht rechtzeitig auf den Auslöser in Zabbix und OSD hörte gerade auf, weil das Protokoll nicht geschrieben werden konnte. Infolgedessen haben wir die Intensität von gc gesenkt, da das Ticket nicht gestartet wurde es war bereits und fügte ein cron-Skript hinzu, in dem wir OSD-Protokolle zwangsweise abschneiden, wenn ein bestimmtes Volume überschritten wird, ohne auf eine Logrotate zu warten. Übrigens Protokollierstufeangehoben .


    Platzierungsgruppen und gepriesene Skalierbarkeit


    Meiner Meinung nach ist PG die am schwierigsten zu verstehende Abstraktion. PG wird benötigt, um CRUSH effizienter zu machen. Der Hauptzweck von PG besteht darin, Objekte zu gruppieren, um den Ressourcenverbrauch zu reduzieren und die Leistung und Skalierbarkeit zu verbessern. Objekte direkt, einzeln anzusprechen, ohne sie in PG zusammenzufassen, wäre sehr teuer.


    Das Hauptproblem von PG ist die Bestimmung ihrer Anzahl für einen neuen Pool. Aus dem Ceph-Blog:


    "Dies ist ein bisschen ein schwarzer Night Art Alptraum."

    Es ist immer sehr spezifisch für eine bestimmte Installation und erfordert lange Überlegungen und Berechnungen.


    Hauptempfehlungen:


    • Zu viele PGs auf dem OSD sind schlecht, ihre Wartung und Bremsen werden während des Ausgleichs / der Wiederherstellung übermäßig hoch.
    • Wenige PGs auf dem OSD sind schlecht, die Leistung wird darunter leiden und das OSD wird ungleichmäßig gefüllt.
    • Die PG-Nummer muss ein Vielfaches von Grad 2 sein. Dies hilft dabei, die "Kraft von CRUSH" zu erhalten.

    Und hier habe ich verbrannt. PGs sind nicht in ihrem Umfang oder der Anzahl von Objekten begrenzt. Wie viele Ressourcen (in reellen Zahlen) benötigen Sie, um ein PG zu verwalten? Hängt es von seiner Größe ab? Hängt es von der Anzahl der Repliken dieses PGs ab? Sollte ich baden, wenn ich genügend Speicher, schnelle CPUs und ein gutes Netzwerk habe?
    Und müssen immer noch über das zukünftige Wachstum des Clusters nachdenken. Die Anzahl der PG kann nicht reduziert werden - nur erhöhen. Gleichzeitig wird davon abgeraten, dies zu tun, da dies zu einer Spaltung des PG-Teils in eine neue und wilde Rebellion führt.


    "Wenn möglich, ist dies einer der wirkungsvollsten Fälle für Produktionscluster."

    Deshalb müssen wir, wenn möglich, sofort über die Zukunft nachdenken.


    Echtes Beispiel.


    Ein Cluster von 3 Servern mit jeweils 14 x 2 TB OSD, insgesamt 42 OSD. Replikat 3, Nutzfläche ~ 28 TB. Wird unter S3 verwendet, müssen Sie die Anzahl der PG für den Datenpool und den Indexpool berechnen. RGW verwendet mehr Pools, aber diese beiden sind einfach.


    Wir gehen in den PG-Rechner (es gibt einen solchen Rechner), betrachten wir mit den empfohlenen 100 PG im OSD, wir bekommen nur 1312 PG. Aber nicht alles ist so einfach: Wir haben eine Einführung - der Cluster wird im Laufe eines Jahres auf jeden Fall dreimal wachsen, aber Eisen wird etwas später gekauft. Erhöhen Sie die "Ziel-PGs pro OSD" dreimal auf 300 und wir erhalten 4480 PG.



    Stellen Sie die Anzahl der PGs für die entsprechenden Pools ein - wir erhalten die Warnung: zu viele PG per OSD ... angekommen. ~ 300 PG bei OSD mit einem Limit von 200 (Luminous) erhalten. Früher waren es 300. Und das Interessanteste ist, dass nicht alle unnötigen PGs blicken dürfen, das heißt, es handelt sich nicht nur um eine Warnung. Daher glauben wir, dass wir alles richtig machen, die Grenzen erhöhen, die Warnung abschalten und weitergehen.


    Ein weiteres reales Beispiel ist interessanter.


    S3, 152 TB nutzbares Volume, 252 OSD bei 1,81 TB, ~ 105 PG pro OSD. Der Cluster wuchs allmählich, alles war in Ordnung, bis mit den neuen Gesetzen in unserem Land kein Wachstum von bis zu 1 PB (+ 850 TB) erforderlich war. Gleichzeitig muss die Leistung beibehalten werden, die jetzt für S3 recht gut ist. Nehmen wir an, wir nehmen Platten mit 6 TB (5,7 TB) an, und unter Berücksichtigung von Replikat 3 erhalten Sie + 447 OSD. Unter Berücksichtigung der aktuellen werden 699 OSDs von jeweils 37 PG erhalten, und wenn wir unterschiedliche Gewichte berücksichtigen, stellt sich heraus, dass das alte OSD nur zehn PGs hat. Und du sagst mir, wie weit wird es funktionieren? Die Leistung eines Clusters mit unterschiedlichen PG-Anzahlen ist synthetisch schwer zu messen, aber die von mir durchgeführten Tests zeigen, dass für eine optimale Leistung ein OSD von 50 PG bis 2 TB erforderlich ist. Und weiteres Wachstum? Ohne die Anzahl der PGs zu erhöhen, können Sie das PG-Mapping für OSD 1: 1 erreichen.


    Ja, Sie können einen neuen Pool für die RGW mit der gewünschten Anzahl von PGs erstellen und einen separaten S3-Bereich darauf anwenden. Oder bauen Sie sogar einen neuen Cluster in der Nähe. Aber stimme zu, dass all diese Krücken. Und es stellt sich heraus, dass Ceph aufgrund seines Konzepts gut skalierbar zu sein scheint. PG skaliert mit Vorbehalten. Sie müssen entweder mit deaktivierten Anpassungen leben, um sich auf das Wachstum vorzubereiten, oder Sie werden irgendwann alle Daten im Cluster rebellieren, oder Sie werden mit der Leistung punkten und mit dem, was Sie erhalten, leben. Oder machen Sie alles durch.


    Ich bin froh, dass die Entwickler von Ceph verstehen, dass PG für den Benutzer eine komplizierte und überflüssige Abstraktion ist, und er sollte es nicht wissen.


    Wenn Sie sich in der leuchtenden Welt befinden, nehmen Sie sie auf darüber nachdenken ".

    In vxFlex gibt es kein Konzept von PG oder irgendwelchen Analoga. Sie fügen einfach die Festplatten zum Pool hinzu und fertig. Und so zu 16 PB. Stellen Sie sich vor, es muss nichts gezählt werden, es gibt keine Haufen von Status dieser PGs, die Festplatten werden während des gesamten Wachstums gleichmäßig verwendet. Weil Festplatten werden an vxFlex als Ganzes übergeben (es gibt kein Dateisystem darüber). Es gibt keine Möglichkeit, die Fülle zu schätzen, und es gibt überhaupt kein solches Problem. Ich weiß nicht mal, wie ich dir sagen soll, wie schön es ist.


    "Sie müssen auf SP1 warten"


    Eine weitere "Erfolgsgeschichte". Wie Sie wissen, ist RADOS das einfachste Repository für den Schlüsselwert. S3, das auf RADOS implementiert ist, ist ebenfalls primitiv, aber immer noch funktionaler. In S3 können Sie beispielsweise eine Liste von Objekten nach Präfix abrufen. Damit dies funktioniert, führt der RGW für jede Charge einen eigenen Index. Dieser Index ist ein RADOS-Objekt, das tatsächlich von einem einzelnen OSD bedient wird. Mit der Anzahl der Objekte im Bucket wächst das Indexobjekt. Nach unseren Beobachtungen beginnen ab mehreren Millionen Objekten im Eimer merkliche Bremsen, wenn in diesen Eimer geschrieben wird. Das OSD-Index-Serviceobjekt frisst viel Speicherplatz und geht möglicherweise regelmäßig aus. Bremsen werden dadurch verursacht, dass der Index bei jeder Änderung gesperrt wird, um die Konsistenz zu gewährleisten. Darüber hinaus bei Scrub-Operationen Das Inga- oder Rebellenindex-Objekt wird für den gesamten Vorgang ebenfalls blockiert. All dies führt periodisch dazu, dass Kunden Timeouts erhalten und 503 die Leistung großer Buckets grundsätzlich leidet.


    Bucket Index Resharding ist ein Mechanismus, mit dem der Index in mehrere Teile (RADOS-Objekte) unterteilt und dementsprechend in verschiedene OSD- Dateien zerlegt werden kann, wodurch die Skalierbarkeit erreicht und die Auswirkungen von Serviceoperationen verringert werden.


    Übrigens ist es erwähnenswert, dass die Möglichkeit des manuellen Resarding nur in Jewel aufgetreten ist und zu einer der letzten Bugfixes zurückgeführt wurde! Hammerbaugruppen, was da ihre hohe Bedeutung zeigt Dies ist kein Bugfix. Wie haben große Eimer früher funktioniert?


    In Hammer hatten wir mehrere Eimer mit mehr als 20 Millionen Objekten, und wir hatten regelmäßig Probleme mit ihnen. Wir kannten die Anzahl der geschätzten OSDs und verstanden nach Meldungen von Graylog, was mit ihnen geschah. Manuelles Resharing hat uns nicht gefallen, weil Für einen bestimmten Backvorgang ist ein Stopp erforderlich. Wir brauchten Luminous, weil In diesem Fall wurde das Resharing für die Kunden automatisch und transparent. Wir haben ein Update auf Luminous durchgeführt, jedoch keine Scoring-Tests durchgeführt. Alles sah gut aus und wir haben es in den Verkauf aufgenommen. IO wuchs erwartungsgemäß im Indexpool auf, die Schaufeln begannen zu scherben, ich öffnete die Bierflasche und beendete den Arbeitstag früher. Einen Tag später stellten wir fest, dass die IO stabil auf hohem Niveau gehalten wurde und alle Probleme mit den Eimern schwer zu erreichen waren. Es stellte sich heraus, dass die Indizes in einem Kreis schattiert sind ... Bald gab es Tickets; eins , zwei:


    Es war notwendig, die Verbindung zu trennen, die Segenproblemindizes waren bereits shardirovana. Ein weiterer Punkt in der Schatzkammer der technischen Schulden, weil Eimer können weiter wachsen und der Splitter wird nicht morgen, also in einem Monat, wieder benötigt.


    Übrigens hat das Update Hammer-> Jewel wegen dieser Fettindizes Spaß gemacht. Der OSD-Halteindex hat beim Neustart alle Timeouts gestempelt. Wir mussten die Timeouts von Threads direkt an der Prode anpassen, damit diese geschätzten OSDs aufsteigen und sich nicht selbst töten konnten.


    Die Geschichte des Autoresharing ist nicht der einzige Fall, in dem ein neues Feature so funktioniert hat, dass es besser wäre, wenn es überhaupt nicht funktioniert. In der Hammer-Version gab es eine S3-Funktion wie die Objektversionierung. Es hat uns viel mehr Schaden als Gutes gebracht. Bei vielen Buckets mit aktivierter Versionierung wurden Objekte allmählich und mit zunehmender Anzahl von Objekten mit einem ungültigen etag und einem Nullkörper angezeigt. Beim Löschen von Objekten traten Fehler auf. Zu dieser Zeit fanden wir mehrere offene Berichte mit ähnlichen Problemen. Wir haben vergeblich versucht, diese Probleme zu reproduzieren, und haben viel Zeit ohne Ergebnis verbracht. Die Versionierung aussetzen konnte das Problem nicht lösen. Infolgedessen bestand die "Lösung" darin, neue Buckets ohne Versionierung zu erstellen und Objekte in diese zu übernehmen. Das hat unseren Ruf sehr erschüttert und unseren Kunden Unannehmlichkeiten bereitet, und wir haben viele Ressourcen aufgewendet, um ihnen zu helfen.


    Holivary über die Anzahl der Repliken


    Sobald es Gespräche über die Anzahl der Replikate gibt, ist die Replik 2 sofort Idiotie und Drogensucht, und im Allgemeinen wird eine solche Konfiguration bald dem Schicksal von Cloudmouse ausgesetzt sein. Ja, wenn Sie Ceph haben, dann vielleicht.


    In vxFlex OS beträgt der Replikationsfaktor 2 und dieser kann nicht geändert werden. Das einzige, was Sie benötigen, ist ein gewisser Platz für die Datenwiederherstellung im Falle eines Unfalls. Dieser Datenträger muss dem Datenträger entsprechen, der gleichzeitig ausfallen kann. Wenn Sie möglicherweise das gesamte Rack durch Strom ausschalten können, müssen Sie die Lautstärke des dicksten Racks reservieren. Sie können über die Wirksamkeit und Zuverlässigkeit eines solchen Schemas streiten, wissen jedoch nicht genau, wie es im Inneren funktioniert, können Sie nur den Ingenieuren von Dell EMC vertrauen.


    Leistung


    Ein weiteres Holivarnaya-Thema. Was ist die Leistung eines verteilten Speichersystems und sogar bei der Netzwerkreplikation? Gute Frage. Es ist klar, dass solche Systeme einen großen Aufwand haben. Meiner Meinung nach sollte das Leistungsniveau von Systemen wie Ceph, vxFlex hinsichtlich ihrer Leistung an der Leistung der verwendeten Geräte gemessen werden. Es ist wichtig zu verstehen, wie viel Leistung wir aufgrund der verwendeten Schicht verlieren. Diese Metrik ist auch wirtschaftlich. Sie hängt davon ab, wie viel Festplatten und Server gekauft werden müssen, um die gewünschten absoluten Werte zu erreichen.


    Ein Brief vom 9. August aus ceph-devel- Mailings : Kurz gesagt, die Jungs bekommen Server von der CPU (zwei Xeons pro Server!) Und lustige IOPS im All-NVMe-Cluster auf Ceph 12.2.7 und Bluestore.


    Es gibt viele Artikel, Präsentationen und Diskussionen in den Mailinglisten, aber "fliegt" Ceph immer noch recht niedrig. Vor ein paar Jahren (zur Zeit von Hammer) haben wir verschiedene Lösungen für die Blocklagerung getestet. Ceph war unser Favorit, da wir es als S3 verwendeten und hofften, es als Block verwenden zu können. Leider trampelte der damalige ScaleIO auf Ceph RBD mit erstaunlichen Ergebnissen. Das Hauptproblem, das bei Ceph aufgetreten ist, ist die nicht ausgelastete Festplatte und die wiederverwendete CPU. Ich erinnere mich gut an unsere Kniebeugen mit RDMA über InfiniBand, Jemalloc und andere Optimierungen. Ja, wenn Sie mit 10 bis 20 Clients schreiben, erhalten Sie eine recht angenehme Zusammenfassung von iops. Wenn jedoch keine Client-Io-Parallelität vorliegt, ist Ceph selbst auf schnellen Festplatten völlig schlecht. vxFlex schafft es auch, alle Festplatten gut zu entsorgen und zeigt eine hohe Leistung. Der Ressourcenverbrauch ist grundlegend anders - Ceph hat eine hohe Systemzeit, und scaleio wartet ab. Ja, dann gab es keinen Bluestore, aber nach den Berichten im Ezine zu urteilen, ist dies keine Silberkugel, und selbst jetzt, nach der Anzahl der Fehlerberichte, scheint er der Anführer des Ceph-Trackers zu sein. Das ScaleIO haben wir ohne Zweifel gewählt. Angesichts der Metrik, die zu Beginn des Abschnitts erwähnt wurde, wäre Ceph selbst unter Berücksichtigung der Kosten der Dell EMC-Lizenzen nicht wirtschaftlich.


    Wenn im Cluster Platten mit unterschiedlichen Kapazitäten verwendet werden, wird das PG je nach Gewicht verteilt. Dies ist eine gerechte Verteilung in Bezug auf das Volumen (Typ), jedoch nicht fair in Bezug auf die IO. Aufgrund der geringeren Anzahl von PGs haben kleine Datenträger eine geringere E / A-Leistung als große, obwohl sie normalerweise die gleiche Leistung haben. Es kann sinnvoll sein, die kleineren Festplatten zu Beginn übergewichtig zu machen und bei Annäherung an die Volle zu senken. Daher ist die Clusterleistung möglicherweise ausgewogener, dies ist jedoch nicht sicher.


    In vxFlex gibt es kein Konzept für ein Journal oder eine Art Cache oder Ermüdung. Der gesamte Datensatz wird direkt auf die Discs übertragen. Es gibt auch kein Pre-Disk-Tuning-Verfahren (ich schaue in Richtung des Ceph-Volumes), Sie geben ihm nur ein Blockgerät für die ausschließliche Verwendung, alles ist sehr einfach und bequem.


    Schrubben


    Trite, ich stimme zu. Durch sie ist wahrscheinlich jeder, der bei Ceph lebt, vorbeigegangen.


    Sobald in Ihrem Cluster viele Daten angezeigt werden und seine aktive Verwendung beginnt, ist es ziemlich schwierig, die Auswirkungen der Bereinigung nicht zu bemerken. "Viele Daten" sind in meinem Verständnis nicht die Gesamtmenge in einem Cluster, sondern die Fülle der verwendeten Festplatten. Wenn Sie beispielsweise über 2 TB-Festplatten verfügen und diese zu> 50% gefüllt sind, haben Sie in Ceph viele Daten, auch wenn nur zwei Festplatten vorhanden sind. Wir litten einst sehr unter dem Scrub und suchten lange nach einer Lösung. Unser Rezept , das bis heute gut funktioniert.


    Das vxFlex-Betriebssystem verfügt auch über einen solchen Mechanismus und ist standardmäßig deaktiviert, wie fast alles, was nicht die Hauptfunktionalität ist. Wenn aktiviert, können Sie nur einen Parameter einstellen - die Bandbreite in Kilobyte. Es ändert sich im laufenden Betrieb und ermöglicht es Ihnen, den optimalen Wert für Ihren Cluster zu wählen. Wir haben den voreingestellten Wert und soweit gut beibehalten, sogar die Festplatten nach Fehlermeldungen regelmäßig geändert.


    Interessanterweise löst vxFlex übrigens Scrub-Error-Situationen selbst. Ceph mit derselben Replik 2 erfordert einen manuellen Eingriff.


    Überwachung


    Luminous ist in vielerlei Hinsicht ein Meilenstein. In dieser Version sind endlich native Überwachungstools erschienen. Mit dem integrierten MGR-Plugin und der offiziellen Vorlage für Zabbix erhalten Sie in wenigen Schritten eine grundlegende Überwachung mit Zeitplänen und den wichtigsten Warnungen (3 Teile). Es gibt auch Plugins für andere Systeme. Das ist wirklich cool, wir verwenden es, aber wir müssen immer noch unsere eigenen Skripte und Vorlagen schreiben, um die E / A in Pools zu überwachen, um zu verstehen, wann gc zum Beispiel ein Unsinn ist. Ein separates Thema ist das Monitoring von RGW-Instanzen.



    Ohne ihn bin ich wie ein blindes Kätzchen. Er muss auch selbst schreiben.
    Und dies ist ein Fragment der externen Überwachung S3, dann wie Clients den Dienst "sehen":



    Natürlich ist dieses Monitoring für Ceph selbst nicht relevant, aber ich empfehle Ihnen dringend, es zu starten, falls es noch nicht existiert.


    Es ist erfreulich zu bemerken, dass Ceph-Monitore Graylog mit dem GELF-Protokoll ausführen können, und wir verwenden es. Wir erhalten beispielsweise Warnmeldungen, wenn das OSD ausgefallen ist, ausfällt, ausgefallen ist und andere. Wenn Sie für das Analysieren von Nachrichten konfiguriert sind, können Sie Protokolle über einen bestimmten Zeitraum analysieren. Beispielsweise können Sie die oberste OSD-Anzeige kennen, indem Sie für einen Monat in den Ruhezustand wechseln, oder ein Intensitätsdiagramm erstellen.



    Irgendwie war es so, dass unser OSD aufgehört hat und keine Zeit hatte, auf Heartbeat zu reagieren, und seine Monitore als ausgefallen gekennzeichnet wurden (siehe Bildschirm oben). Der Grund war vm.zone_reclaim_mode=1auf Zwei-Socket-Servern mit NUMA.


    Diese Art von Lob und Ceph. True c vxFlex ist ebenfalls möglich. Und er hat auch ein sehr gutes billiges Board:



    Es ist klar, welcher Client die Last erzeugt:



    Detaillierung der IO auf Knoten und Festplatten:



    Beachten Sie, wie die Platten gleichmäßig gefüllt sind und wie nahezu IO auf sie fällt, was Ceph fehlt.


    Alle Spinner sind zur Hand:



    Ich werde nicht auf einem Lowboard über Ceph sprechen, das an Luminous geliefert wurde. Vielleicht in 2.0 wird das in Mimic erschienene Programm interessanter, aber ich habe es noch nicht gesehen.


    vxFlex ist auch nicht perfekt


    Wenn ein Cluster in den Zustand Degraded wechselt, z. B. wenn sich eine Platte ändert oder der Server neu startet, kann kein neues Volume erstellt werden.


    Das vxFlex-Client-Kernel-Modul und die Unterstützung für neue Kernel von RH erscheint verzögert. Offizieller Support 7.5 zum Beispiel. In Ceph sind Clients für RBD und Cephfs Module des Upstream-Kernels und werden mit dem neuesten Update aktualisiert.


    vxFlex ist im Vergleich zu Ceph schlecht in Funktionen. vxFlex ist nur ein Blockstapel, der beispielsweise keine Ermüdung aufweist.


    Sie können nur bis zu 16 PB groß werden, es gibt eine solche Einschränkung. Mit Ceph hätten Sie genug Nerven, um 2 PB zu wachsen ...


    Fazit


    Ich höre oft, dass Ceph ein akademisches Projekt mit einer Reihe ungelöster Probleme ist, dass es ein Rahmen ohne Dokumentation ist, dass sein Trinkgeld durch seine Komplexität kompensiert wird, dass das Erstellen eines normalen Stapels auf Ceph eine Utopie ist. Im Allgemeinen stimme ich mit allem überein.


    Kürzlich gab es auf Habré eine Veröffentlichung darüber, was Ceph gesund ist und dass es von einem "regulären Administrator" verwaltet werden kann. Nach diesem Artikel ärgerte mich mein Chef mit den Worten: "Als Sanya kann das übliche Admin, aber Sie haben immer R & D, immer einige Probleme." Ich war ein bisschen verletzt. Ich weiß nicht, welche "Admins" die Jungs dort haben, aber Ceph braucht ständig die Aufmerksamkeit eines ziemlich qualifizierten Personals. Er ist wie ein lebender Organismus, der ab und zu krank ist.


    Wenn Sie mich auffordern, Ceph in 2k18 zu verwenden oder nicht, werde ich auf Folgendes antworten. Wenn Ihr Dienst rund um die Uhr funktionieren sollte und ein geplanter oder ungeplanter Stopp nicht akzeptabel ist (beispielsweise öffentliches S3 oder EBS), und eine Beeinträchtigung des Dienstes den Kunden mit einem Rubel beleidigen und bestrafen kann, ist die Verwendung von Ceph sehr gefährlich. Höchstwahrscheinlich leiden Sie regelmäßig. Und wenn auch Produktivität gefragt ist, kann es wirtschaftlich nicht rentabel sein. Wenn Sie ein Repository für die internen Anforderungen des Projekts / der Firma erstellen und die Möglichkeit besteht, Wartungsarbeiten durchzuführen, indem Sie den Service anhalten oder am Wochenende ausschöpfen, um die maximale Anzahl an Auffüllungen zu erreichen, werden Sie mit Ceph auskommen und möglicherweise wird Ihr Leben etwas pikanter.


    Warum verwenden wir Ceph weiterhin in der ersten Kategorie? Wie das Sprichwort sagt: "Vom Hass zur Liebe ist ein Schritt." So ist es mit Ceph. Ich liebe es, weil ich es weiß. Es war zu viel mit ihm gegangen, um diese Beziehungen und das gesammelte Fachwissen aufzunehmen und zu verwerfen, besonders jetzt, wenn es scheint, dass alles unter Kontrolle ist ...
    Aber man kann die Rollen nicht entspannen!
    Alle GESUNDHEIT_OK!


    Jetzt auch beliebt: