Über SSD an echten Beispielen tragen


    Vor einem Jahr haben wir unserem Agenten eine Sammlung von Festplattenattributen auf Client-Servern hinzugefügt. Zu diesem Zeitpunkt haben wir sie nicht zur Benutzeroberfläche hinzugefügt und sie den Kunden gezeigt. Tatsache ist, dass wir Metriken nicht über smartctl entfernen, sondern ioctl direkt aus dem Code ziehen, damit diese Funktionalität ohne die Installation von smartmontools auf Client-Servern funktioniert.
    Der Agent entfernt nicht alle verfügbaren Attribute, sondern nur die wichtigsten und am wenigsten herstellerspezifischen (nach unserer Meinung, sonst müssten Sie eine Datenbank mit Festplatten einrichten, die der von smartmontools ähnelt).
    Jetzt haben wir endlich herausgefunden, was wir da mitgenommen haben. Es wurde beschlossen, mit dem Attribut "Media Wearout Indicator" zu beginnen, das die verbleibende SSD-Aufzeichnungsressource in Prozent angibt. Unter dem Schnitt gibt es mehrere Geschichten in Bildern darüber, wie diese Ressource im wirklichen Leben auf Servern verbraucht wird.


    Gibt es tote SSDs?


    Es gibt eine Meinung, dass die neueren, produktiveren SSDs öfter herauskommen, als die alten getötet werden können. Daher war es das erste, was es am interessantesten war, die am meisten getöteten Platten in Bezug auf die Aufzeichnungsressourcen anzusehen. Der Mindestwert für alle SSD aller Clients beträgt 1%.


    Wir haben dem Kunden sofort darüber geschrieben, es stellte sich heraus, dass es sich beim Hetzner um einen Igel handelte. Host-Support ersetzt sofort ssd:




    Es wäre sehr interessant zu sehen, wie die Situation aus der Sicht des Betriebssystems aussieht, wenn ssd die Aufnahme beendet (wir suchen jetzt nach einer Möglichkeit, einen absichtlichen Spott über ssd auszuführen, um die Metriken dieses Skripts zu betrachten :)


    Wie schnell werden SSDs getötet?


    Seit wir vor einem Jahr mit dem Sammeln von Metriken begonnen haben und keine Metriken löschen, besteht die Möglichkeit, diese Metrik rechtzeitig zu betrachten. Leider ist der Server mit dem höchsten Verbrauch erst vor zwei Monaten an okmeter angeschlossen.




    In dieser Grafik sehen wir, wie in 2 Monaten 8% der Aufzeichnungsressourcen verbrannt wurden. Das heißt, bei demselben Aufnahmeprofil reichen diese ssd für 100 / (8/2) = 25 Monate. Ich weiß nicht viel oder wenig, aber was für eine Art von Ladung gibt es?




    Wir sehen, dass nur Ceph mit einer Platte arbeitet, aber wir verstehen, dass Ceph nur eine Ebene ist. In diesem Fall fungiert der ceph-Client auf mehreren Knoten als Repository für den kubernetes-Cluster. Sehen wir uns an, was sich in den k8s befindet, die die meisten Schreibvorgänge auf der Festplatte erzeugen:




    Absolute Werte stimmen höchstwahrscheinlich nicht überein, da ceph in einem Cluster arbeitet und der Datensatz von redis aufgrund der Datenreplikation multipliziert wird. Mit dem Lastprofil können Sie jedoch zuversichtlich sagen, dass der Eintrag genau neu initiiert wird. Mal sehen, was in Rettich passiert:




    Hier können Sie sehen, dass im Durchschnitt weniger als 100 Anforderungen pro Sekunde ausgeführt werden, die Daten ändern können. Es sei daran erinnert, dass Redis zwei Möglichkeiten hat, Daten auf die Festplatte zu schreiben :


    • RDB - Periodische Momentaufnahmen der gesamten Datenbank auf der Festplatte. Wenn Redis startet, lesen wir den letzten Speicherauszug in den Speicher und verlieren Daten zwischen den Speicherauszügen
    • AOF - Wir schreiben ein Protokoll aller Änderungen. Beim Start verliert redis dieses Protokoll und alle Daten befinden sich im Speicher. Wir verlieren nur Daten zwischen dem fsync dieses Protokolls

    Wie wahrscheinlich alle in diesem Fall vermutet haben, wird RDB mit einer Periodizität von 1 Minute Dump verwendet:



    SSD + RAID


    Nach unseren Beobachtungen gibt es drei Hauptkonfigurationen des Festplattensubsystems von Servern mit SSD:


    • In Server 2 SSD in Raid-1 gesammelt und alles lebt dort
    • Der Server hat HDD + Raid-10 von SSD, normalerweise für klassisches RDBMS (System, WAL und einen Teil der Daten auf der Festplatte und auf der SSD das heißeste in Bezug auf das Lesen von Daten).
    • Der Server verfügt über freistehende SSDs (JBOD), die normalerweise für Kassetten vom Typ nosql verwendet werden

    Wenn ssd in raid-1 gesammelt wird, wird die Aufzeichnung auf beide Festplatten bzw. auf die gleiche Geschwindigkeit übertragen:




    Ich bin auf einen Server gestoßen, auf dem das Bild anders ist:




    Zur gleichen Zeit werden nur mdraid Partitionen (alle RAID-1-Arrays) gemountet:



    Bei den Metriken des Datensatzes wird auch deutlich, dass mehr Einträge an / dev / sda gesendet werden:




    Es stellte sich heraus, dass eine der Partitionen in / dev / sda als Swap verwendet wird, und Swap I / O auf diesem Server ist ziemlich auffällig:




    Getragene SSD und PostgreSQL


    Eigentlich wollte ich die Ssd-Verschleißrate unter verschiedenen Schreiblasten in Postgres sehen, aber in der Regel werden sie auf den geladenen SSD-Basen sehr sorgfältig verwendet und die massive Aufnahme geht auf die Festplatte. Bei der Suche nach einem geeigneten Fall stieß ich auf einen sehr interessanten Server:




    Der Verschleiß von zwei SSDs in Raid-1 für 3 Monate betrug 4%, aber nach der Geschwindigkeit der WAL-Aufzeichnung beurteilt dieser Postgress weniger als 100 Kb / s:




    Es stellte sich heraus, dass Postgres aktiv temporäre Dateien verwendet, mit denen ein ständiger Schreibstrom auf die Festplatte erzeugt wird:




    Da die Postgresql-Diagnose ziemlich gut ist, können wir genau herausfinden, was wir reparieren müssen:




    Wie Sie hier sehen können, generiert dieses spezielle SELECT eine Reihe temporärer Dateien. Im Allgemeinen wird in einem SELECT-Postgrece manchmal ein Datensatz auch ohne temporäre Dateien generiert - hier haben wir bereits darüber gesprochen.


    Gesamt


    • Der Umfang des Schreibvorgangs auf der Festplatte, den Redis + RDB erstellt, hängt nicht von der Anzahl der Änderungen in der Datenbank ab, sondern von der Größe des Basisintervalls + Dump (und im Allgemeinen ist dies die höchste Stufe der Schreibverstärkung in bekannten Data Warehouses).
    • Aktiv genutzter Swap auf ssd ist schlecht, aber wenn Sie Jitter in ssd tragen müssen (für Zuverlässigkeits-Raid-1), können Sie die Option weitergeben :)
    • Neben WAL- und Datenbank-Dateien können sie auch alle Arten von temporären Daten auf die Festplatte schreiben.

    Wir bei okmeter.io glauben, dass ein Ingenieur viele Metriken für alle Schichten der Infrastruktur benötigt, um an das Problem zu gelangen. Wir tun unser Bestes, um zu helfen :)


    Jetzt auch beliebt: