Ich weiß, es klingt seltsam, aber ich brauche ein langsameres oder zwischengespeichertes Dateisystem.
Ich habe viele Firewalls, die ihre Daten per Syslog an ein Paar Linux-VMs senden, die diese Dateien auf ihre „lokalen“ (tatsächlich an FC SAN angeschlossenen) ext3-formatierten Festplatten schreiben und die Nachrichten auch an unsere Splunk-Server weiterleiten.
Das Problem besteht darin, dass der Syslog-Server diese Syslog-Meldungen als Hunderte, manchmal Tausende von winzigen ~4k-Schreibvorgängen pro Sekunde zurück an unser FC-SAN schreibt – das diese Arbeitslast derzeit zwar bewältigen kann, aber unser FW-Verkehr wird in den kommenden Monaten um mindestens den Faktor 5000 (tatsächlich) ansteigen, und das wird eine Qual für das SAN. Ich möchte die Grundursache beheben, bevor es zu einem Problem wird.
Ich brauche also etwas Hilfe bei der Entwicklung einer Möglichkeit, diese Schreibvorgänge zwischenzuspeichern oder sie auf irgendeine Weise von den „physischen“ Festplatten fernzuhalten, sodass die VMs größere, aber weniger häufige Schreibvorgänge ausführen. Diese Schreibvorgänge lassen sich nicht vermeiden, aber es besteht auch keine Notwendigkeit, so viele kleine Schreibvorgänge auszuführen.
Ich habe mir die verschiedenen Ext3-Optionen angesehen und noatime und nodiratime eingestellt, aber das hat das Problem nicht wesentlich gelöst. Natürlich untersuche ich auch andere Dateisysteme, aber ich dachte, ich werfe das mal ein, falls andere in Zukunft das gleiche Problem haben.
Oh, und ich kann diese Nachrichten nicht einfach an Splunk weiterleiten, unser Firewall-Team besteht darauf, dass sie zu Diagnosezwecken in ihrem Originalformat bleiben.
Antwort1
Vielleicht commitwürde Ihnen die Mount-Option für Ext3 helfen? Würde zum Beispiel commit=60alle Daten und Metadaten nur einmal pro Minute löschen.
Obligatorischer Warnhinweis: Dies kann zu einem Datenverlust von bis zu einer Minute führen (wenn Sie den Wert „commit=60“ überschreiten).
Antwort2
Dateisystem: Deaktivieren Sie Schreibbarrieren, wenn Ihre Geräte diese verwenden, und deaktivieren Sie Atime-Updates auf ganzer Linie.
Es besteht jedoch die Möglichkeit, dass Sie Ihr Syslog auch auf Kosten eines größeren Datenverlusts im Falle eines Fehlerereignisses (Strom usw.) optimieren können.
Beispielanweisungen von syslog-ng(die möglicherweise nicht denen entsprechen, die Sie verwenden):
flush_lines()Gibt an, wie viele Zeilen gleichzeitig an ein Ziel gesendet werden. Syslog-ng wartet, bis diese Anzahl Zeilen angesammelt ist, und sendet sie in einem einzigen Stapel.flush_timeout()Gibt die Zeit an, die syslog-ng wartet, bis sich Zeilen in seinem Ausgabepuffer angesammelt haben. Weitere Informationen finden Sie unter der Option „flush_lines“.
Das Ziel ist in diesem Fall eine Datenträgerdatei.