Was das Backup wert war, erweist sich, sobald man es versucht ganz oder teilweise wiederherzustellen. Spätestens dann macht sich die Wahl des richtigen Tools ... (mehr)

Ein Beispiel: CVS

Der CVS-Server wurde vor Urzeiten installiert und war schon immer langsam. Warum, darüber gab es verschiedene Theorien, angefangen von schlechten Treibern bis zu Fehlern im Versionskontrollsystem selbst. Allerdings wurde die Ursache nie untersucht, und die Symptome wurden nie genau nachgemessen. Mit der Zeit spitzte sich die Situation aber so zu, dass dringend Handeln geboten war.

Das Storage Subsystem bestand aus vier Fibre-Channel-Platten mit einer Rotationsgeschwindigkeit von 10k RPM, die sich in einem RAID-10-Verbund befanden. Der CVS-Server verbrachte bis zu 90 Prozent der Zeit im Status »iowait« . Die Datensammlung erfolgte via Zenoss [3] und Nagios sowie dessen Plugin »check-sar-perf« [2] .

Im Verlauf mehrerer Tage bewahrheitete sich der hohe Anteil »iowait« . Die Anzahl IOPS (oder »tps« in der Terminologie von »sar« ) belief sich auf einen Mittelwert von 574. Wegen des pausenlosen »iowait« -Status wurden die Werte aus Spitzenlastzeiten verwendet, die sich auf 27780 rd_sec/s beziehungsweise 2070 wr_sec/s beliefen

Für die Lese- und Schreibanteile ergibt sich damit:

$ echo "scale=3; percentrdsec=27.78; percentwritesec=2.07; percentrdsec/(percentwritesec+percentrdsec)" | bc -l
.930
$ echo "scale=3; percentrdsec=27.78; percentwritesec=2.07;§§ percentwritesec/(percentwritesec+percentrdsec)" | bc -l
.069

Damit sind alle benötigten Werte zusammen, um die vermutliche maximale Anzahl IOPS zu berechnen. Legt man dabei den Höchstwert für 10k-Laufwerke zugrunde, so ergibt sich (ohne Cache und Controller-Effekte) ein Wert von 562. Dieser Wert ist niedriger als der zuvor gemessene Wert von 574, was ein weiteres Indiz dafür ist, dass das I/O-System überlastet ist.

$ echo "scale=0; disks=4; diops=150; readpercent=.93; f=2; writepercent=.068; (disks*diops)/(readpercent+(f*writepercent))" | bc -l
562

Für die Linderung der Probleme mit dem überlasteten I/O-Subsystem bieten sich verschiedene Optionen an. Beispielsweise ließen sich die Anforderungen verringern, man könnte aber auch mehr Spindeln (Platten) hinzufügen, auf die sich die Last dann verteilen würde, oder man könnte einen besser geeigneten RAID-Level wählen.

Entschärfung der Lage

Die folgenden Beispiele illustrieren, welchen Einfluss zusätzliche Platten und/oder eine andere RAID-Konfiguration haben würden. In diesem Beispiel, das bereits mit einem RAID 10 arbeitet, hätte allerdings eine andere RAID-Konfiguration ohne zusätzliche Platten keinen positiven Effekt.

  • RAID 5 mit vier Platten:
$ echo "scale=0; disks=4; diops=150; readpercent=.93; f=4; writepercent=.068; (disks*diops)/(readpercent+(f*writepercent))" | bc -l
499
  • RAID 5 mit fünf Platten:
$ echo "scale=0; disks=5; diops=150; readpercent=.93; f=4; writepercent=.068; (disks*diops)/(readpercent+(f*writepercent))" | bc -l
623
  • RAID 5 mit sechs Platten:
$ echo "scale=0; disks=6; diops=150; readpercent=.93; f=4; writepercent=.068; (disks*diops)/(readpercent+(f*writepercent))" | bc -l
748
  • RAID 10 mit sechs Platten:
$ echo "scale=0; disks=6; diops=150; readpercent=.93; f=2;writepercent=.068; (disks*diops)/(readpercent+(f*writepercent))" | bc -l
844
comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023