The main function of access time logging is to make your filesystem slower. Seriously.
It is common knowledge that old school hackers all have large beards. Alan Cox, RMS and maddog are brilliant examples. The reason for this is that growing a beard is the most interesting use of one’s time when the computer is waiting for fsck to finish messing around after a system crash, and on large filesystems, you’ll have plenty of time to waste (this might also be why there are so few female hackers; they can’t grow beards).)
Was man nicht alles findet, wenn man versucht XFS zu verstehen. ;-)
Es verirren sich immer öfter Leute hierher oder schreiben mir, die nach Informationen zu NetApp und SNMP Abfragen suchen. Um in den NetApp MIBs zu suchen, habe ich schon einmal das Tool Mibbleempfohlen. Es ist Java basiert und kann damit quasi überall eingesetzt werden. Sofern Mibble läuft, braucht man nur noch die MIB, die man auf NOW oder im ROOT auf dem Storage Controller findet. (z.B. /vol/vol0/etc/mib/netapp.mib)
Frage 1: Wie kann ich per SNMP eine Liste meiner LUNs abfragen?
Frage 2: Wie kann ich die Temperatur meiner Shelves auslesen?
Da gibt es mehrere Wege. Einer wäre die Temperatur per CLI abzufragen. Der Befehl dazu ist “environment”:
gundel> environment status shelf
[...]
Cooling Unit installed element list: 1, 2; with error: none
Temperature Sensor installed element list: 1, 2, 3; with error: none
Shelf temperatures by element:
[1] 21 C (69 F) (ambient) Normal temperature range
[2] 24 C (75 F) Normal temperature range
[3] 24 C (75 F) Normal temperature range
Die Daten können natürlich auch per SNMP ausgelesen werden, um z.B. eine Überwachung in Nagios zu realisieren:
Die Mail sagt, dass Microsoft Danger gekauft hat, den Hersteller von Sidekick. Die haben sich dann entschieden, deren Infrastruktur einmal physisch in eines ihrer eigenen Datencenter zu schieben, um Mietkosten zu sparen. Die eigentliche Hard- und Software haben sie dabei nicht angefasst, das ist alles noch das alte Zeug. Und am letzten Dienstag, sagt die Mail, hat sich dann deren Storage spontan desintegriert. Da waren 800 TB Daten drauf. Das war ein fettes SAN, dessen Hersteller ich hier mal verschweigen will, aber wenn die Mail stimmt, ist es einer der Marktführer in dem Segment. Natürlich hatte Danger einen dicken Support-Contract mit dem Storage-Vendor. Die waren also ab Dienstag vor Ort. Und das SAN hat beim Sterben auch gleich mal die Parity-Platten zersägt, so dass an sich von Anfang an klar war, dass die Daten futsch sind. Das hat mal eben 800 TB an Daten geshreddert.
Es gab einen Backup, auf ein Off-Site Tape, also die haben sich da schon einmal an die Regeln gehalten, was man so an Vorsichtsmaßnahmen treffen kann für sowas.
Wer 800TB an Daten zur Sicherheit einzig und allein nur auf Band sichert und im Katastrophenfall auf schnelle Recovery-Zeiten hofft, hat IMHO nichts anderes als Spott verdient. Sorry Microsoft, you are doing it wrong.
Interessant auch, wenn man im Web nach genauen Details zu dem Vorfall sucht: Vorgehensweisen, Hersteller- und sonstige Angaben zur Datenmenge ändern sich von Seite zu Seite. Wer weiß ob die volle Wahrheit jemals publik wird.
Ich finds immer wieder witzig zu merken, wie manche Firmen ihre Kunden regelrecht darauf trainieren mit seltsamen Argumenten, deren Richtigkeit man spontan selten überprüfen kann, gegen die direkten Mitbewerber vorzugehen.
Bei mir gibt es heute keine DVD aus der Reserve, sondern den spannenden Streifen ZFS checksum recovery. Popcorn fällt wegen Aufpassen aus. Mission “Gradebiegen von seltsam vermitteltem Gefahrwissen durch Schönwettervertriebler” hat begonnen.
Die Marktschreier einiger Storage Hersteller preisen ‘Thin Provisioning’ über alles in den Himmel. Überbuchen von (nicht vorhandenen) Kapazitäten… da will jeder hin. Ach wirklich? Aus der Reihe nervige Fehlermeldungen zum abgewöhnen:
Warning: Aggregate Almost Overcommitted
Committed 11.4 TB (98.02%) out of 11.7 TB available; Using 10.9 TB (93.22%) out of 11.7 TB available
Ich würde ja verstehen, wenn das Gerät mich davor warnt, wenn ich wirklich etwas überbucht hätte, aber dieses fast, bald oder annähernd überbucht, ist etwas zu viel – zumal der Alarm immer und immer wieder auftaucht bis man die Werte unter einen gewissen Schwellwert drückt. Ja ich weiß, ich mecker zu viel. Entschuldigung!
Bei einem Volumen mit 13 Terabyte Gesamtgröße, ist eine Überwachung des Füllstandes mit Default Panik-Alarmen von Nagios bei 80% für Warning (entspricht noch ~2,6Terabyte verfügbarer Platz) und 92% für Critical (entspricht noch ~1 Terabyte verfügbarer Platz) etwas übertrieben - es sei denn man erwartet extra rasantes Wachstum.
Entries (RSS)