Datenhaufen zu IT und Elektronik.
Ich habe gerade eben meinen Openfire abgeschaltet und werde ihn nicht mehr einschalten. Jabber / XMPP war eine wirklich schöne Möglichkeit der Kommunikation. Der Aufwand SPAM zu filtern und das Teil selbst zu betreiben steht aber inzwischen einfach in keinem Verhältnis mehr. Zudem hat sich Jabber nur minimal weiterentwickelt. Inzwischen ist es von vielen schönen Lösungen überholt worden.
Meine Kommunikation läuft inzwischen mehr über Matrix/Riot oder Slack Chat als über Jabber.
Racktables ist zur Dokumentation seiner Assets im Rack nicht das schlechteste Tool. Es hat ganz klar seine Grenzen aber oft erfüllt es die Anforderungen.
Wie füge ich in Racktables einen Load Balancer hinzu? Vor dieser Frage stand ich vor einiger Zeit. Mein erster Anlaufpunkt war natürlich das Racktables Wiki. Leider wurde ich daraus nicht wirklich schlauer. Die google Suche: „How to add LoadBalancers to racktables“ hat mir ebenfalls nicht geholfen. Irgendwann bin ich auf den Hinweis zur User Interfaceconfiguration „IPV4LB_LISTSRC“ gestoßen. Ab da öffneten sich meine Augen 🙂
Die Option ist im default mit einem false deaktiviert. Aktiviert man sie mit einem einfachen true, tauchen einfach alle Hardwareserver als Load Balancer unter IP SLB ==> Load balancers auf. Das ist fast gut. Fast… ja fast weil dort eigentlich nur die Load-Balancer auftauchen sollten. Da kam mir die Funktion der Tags in den Sinn. Nach diesen lässt sich bei Racktables nicht nur filtern, sondern man kann darauf aufbauend auch Dinge im Interface umorganisieren. Einfachstes Beispiel ist sicher der Tag „Poweroff“, welcher ausgeschaltete Systeme in der Rackübersicht andersfarbig darstellt, wenn man dem Tag eine andere Farbe zugewiesen hat.
Genau so bekommt man nun ebenfalls die Load balancers ins IP SLB von Racktables. Als erstes legt man also einen Tag an, der jedem Load balancer zugewiesen wird: Configuration ==> Tag tree ==> Edit tree
Nun weißt man dieses Tag dem jeweiligen Load Balancer Object zu.
Nun geht es weiter unter Configuration ==> User Interface ==> Change
Dort muss die Option IPV4LB_LISTSRC so geändert werden, dass unser neues Tag in geschweiften Klammern steht. In meinem Beispiel ist es das Tag LoadBalancer und dieses findet sich wie folgt in der Konfiguration:
Das war es auch schon. Ab jetzt wird jedes Object unter Racktables ==> IP SLB ==> Load balancers auftauchen, welches das Tag LoadBalancer bekommen hat.
Wenn man es einmal verstanden hat, ganz einfach oder? Viel Spaß 😀
Ich habe vor kurzem in einem DataCenter gestanden und mir einen „neuen“ Kaltgang angeschaut bei dem mir wirklich alles aus dem Gesicht gefallen ist. Der Betreiber dieses DataCenters ist groß, international tätig, nennt eine größere zweistellige Zahl an DataCentern sein eigen und ist doch recht namhaft… Dieser Versuche von einem Kaltgang ist dabei von eben diesem Betreiber gebaut worden. Nicht für einen vermieteten Cage sondern ganz trocken für vermietete Rackreihen…. Rackreihen bei denen sie penibel darauf achten dass dort ganz sicher auch die einzelnen HE Blenden eingesetzt werden, damit ein korrekter Luftstrom garantiert ist. Das meinen die wirklich ernst! *kopfschüttel*
Oh und nein… ich werde jetzt nicht sagen wer der Betreiber ist.
Um die Performance von irgendwelchen Datenträgern / Netzlaufwerken usw. zu messen gibt es sehr viele verschiedene Tools. bonnie++ ist hier ein gutes Beispiel. Möchte man nur „mal schnell“ die read-/write latency messen und ein paar grobe Infos zu den IOPs haben kann ich hier ioping empfehlen.
Ein Beispiel zum messen der read latency:
➜ ~ ioping -s 256k -T 120 -D -c 20 ./ 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=1 time=16.0 us (warmup) 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=2 time=35.7 us 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=3 time=45.8 us 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=4 time=46.3 us 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=5 time=43.4 us 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=6 time=46.8 us 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=7 time=41.2 us 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=8 time=41.7 us 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=9 time=47.7 us (slow) 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=10 time=42.4 us 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=11 time=41.8 us 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=12 time=41.1 us 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=13 time=48.8 us (slow) 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=14 time=47.1 us 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=15 time=42.8 us 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=16 time=47.9 us 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=17 time=50.5 us (slow) 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=18 time=52.8 us (slow) 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=19 time=44.6 us 256 KiB <<< ./ (zfs tanksmeer/usr/home): request=20 time=45.3 us --- ./ (zfs tanksmeer/usr/home) ioping statistics --- 19 requests completed in 853.7 us, 4.75 MiB read, 22.3 k iops, 5.43 GiB/s generated 20 requests in 19.0 s, 5 MiB, 1 iops, 269.2 KiB/s min/avg/max/mdev = 35.7 us / 44.9 us / 52.8 us / 3.85 us
ioping liest hier jeweils 256k (-s 256k), ignoriert alles was länger brauch als die angegebene Zeit (-T 120), macht es als direct IO ohne cache (-D), dieses insg. 20 mal in Folge (-c 20) und einfach im aktuellen Pfad (./).
Die Zusammenfassung ist ähnlich wie bei ping 🙂
Ein Beispiel zum messen der write latency:
➜ ~ ioping -s 256k -T 120 -D -W -c 20 ./ 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=1 time=27.0 us (warmup) 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=2 time=54.4 us 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=3 time=60.6 us 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=4 time=65.5 us 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=5 time=57.8 us 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=6 time=74.0 us 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=7 time=65.5 us 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=8 time=65.3 us 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=9 time=70.9 us 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=10 time=70.7 us 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=11 time=2.65 ms (slow) 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=12 time=71.8 us (fast) 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=13 time=64.5 us (fast) 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=14 time=77.0 us (fast) 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=15 time=63.3 us (fast) 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=16 time=67.4 us (fast) 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=17 time=51.6 us (fast) 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=18 time=82.9 us (fast) 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=19 time=81.5 us (fast) 256 KiB >>> ./ (zfs tanksmeer/usr/home): request=20 time=56.2 us (fast) --- ./ (zfs tanksmeer/usr/home) ioping statistics --- 19 requests completed in 3.86 ms, 4.75 MiB written, 4.93 k iops, 1.20 GiB/s generated 20 requests in 19.0 s, 5 MiB, 1 iops, 269.5 KiB/s min/avg/max/mdev = 51.6 us / 202.9 us / 2.65 ms / 577.9 us
Richtig… Hier ist nur ein -W dazu gekommen!
So lässt sich schnell und einfach ein Eindruck über die aktuelle Performance von einem „Filesystem“ erlangen. Einfach um zu sehen ob es sich unter Last anders verhält oder ähnliches.
Viel Spaß und bei Fragen, einfach fragen.
© 2025 -=Kernel-Error=-
Theme von Anders Norén — Hoch ↑
