Schon seit Ewigkeiten lebt in meinem großen spieletauglichen Windows PC ein kleiner MAC Mini. Um genau zu sein, einer der ersten Minis, die damals auf den Markt kamen noch mit PowerPC CPU und OSX. Den Kleinen habe ich damals gekauft, um meine Intel Pentium 3 Linux Workstation zu ersetzen. Anfangs reichte mir der Kleine auch, ja sogar World of Warcraft liess sich darauf spielen – damals bevor die Ansprüche stiegen. ;-)
Mittlerweile allerdings ist das MAC OS für den Kleinen veraltet, schon lange wird für die veraltete Plattform nichts mehr von Apple entwickelt und natürlich liefert er auch keine Leistung mehr, die ich heute einfach brauche oder zumindest erwarte.
Also wanderte der Kleine ins Gehäuse des großen PCs und durfte dort bis Heute als quasi Heimserver seinen Lebensabend geniessen. Wie schon erwähnt, wurden Neuentwicklungen für die alte Plattform eingestellt und die Fernwartung ließ dank eines ständig einfrierenden VNC Daemons auch zu wünschen übrig. Also fasste ich den Entschluss und verabschiedete mich nun von Mac OS, um den kleinen mit Linux ‘Ubuntu Server’ zu betanken!
Auch bei Ubuntu wird nicht länger aktiv an einer PowerPC Version gearbeitet, allerdings stellt die Linux Community einen ziemlich aktuellen (10.04) Ubuntu Port bereit! Also einfach das CD Image runterladen, brennen, das alte System sichern und und der Anleitung folgen.
Zur Datensicherung habe ich meine wichtigen Daten auf eine externe Festplatte kopiert. Als Dateisystem habe ich mich für FAT32 entschieden, einfach als kleinster gemeinsamer Nenner zwischen der Apple und Linux Welt. Nach der Installation verhält sich der kleine jetzt wie jeder andere Linux Server. OpenVPN, Samba, Mediatomb, OpenSSH usw. tun ihre Dienste und mein Heimserver darf endlich wieder mit neuen Features aufwarten. Ich denke damit lassen sich bestimmt weitere 2-3 Jahre locker überstehen!
Die Installation verlief reibungslos. Das einzige was mich etwas verwundert hat ist, dass der Ubuntu Server Installer mich nicht nach der gewünschten IP Konfiguration fragte. Der “Server” hing dann also per DHCP irgendwie im LAN rum und musste nachträglich auf eine statische IP konfiguriert werden. Kleinigkeiten, die lösbar sind. Also absolut zur Nachahmung empfohlen! :)
Ein eigener Root Server hat seine Vor- und Nachteile. Ein Nachteil ist das Thema Backup, denn die auf dem Server abgelegten Daten sind unter Umständen sehr wichtig. Mails, Datenbanken, ganze Web-Präsenzen oder gar persönliche Daten, die in virtuellen Arbeitsumgebungen gespeichert wurden, sind Daten, die man im Ernstfall wieder haben möchte.
Wer mit seinem Root Server eine Backup-Möglichkeit geliefert bekommt, sollte diese als tunlichst auch benutzen – bequemer geht es nicht. Bei Strato kann man z.B. extra Platz für Backups auf einem FTP Server für 4,99EUR monatlich dazu buchen.
Eine andere Möglichkeit ist es die Angebote der Web2.0 Ära zu benutzen und seine Backups in die “Cloud” auszulagern. Daten, die einmal irgendwo im Internet zwischengespeichert wurden, sind auch zu jeder Zeit wieder von überall abrufbar. Recovery von wichtigen Daten ist damit also von überall möglich, sogar vom Handy.
Ich habe mich dazu entschieden meine Backups bei Dropbox auszulagern. Dropbox ist ein Internet-Service, der es ermöglicht Dateien über mehreren Endgeräte zu synchronisieren. Dazu bedarf es lediglich dem Dropbox Client, den man auf den Endgeräten installieren muss. Dropbox gibt es für Windows, Linux, MacOS oder auch iPhones/iPods. Als kostenloser Benutzer bekommt man 2GB Speicherplatz zur freien Benutzung – für mich für den Anfang mehr als genug.
Backup in the cloud hat allerdings den faden Beigeschmack der Datensicherheit. Lege ich meine Daten ins Internet oder gebe sie einen fremden Anbieter, weiß ich nicht was mit diesen Daten passiert. Bevor ich meine sehr persönlichen Daten also irgendwo in die Wolke lege, sorge ich dafür, dass diese Verschlüsselt werden.
GPG Schlüssel erzeugen, mit denen die Backup-Container verschlüsselt werden
Am Ende sorgt ein entsprechendes Script dafür, dass die Backup-Daten mit den richtigen User-Rechten verschlüsselt im Dropbox Verzeichnis abgelegt werden. Im Hintergrund wandert das Backup dann in die Cloud.
Wer keinen anständigen Storage mit brauchbaren Snapshot-Möglichkeiten hat, muss sich in der tollen neuen Web-Welt nur zu helfen wissen. Wer mehr als die freien 2GB Speicherplatz bei Dropbox benötigt, kann mehr Speicherplatz nachkaufen. Anstatt Dropbox könnte man natürlich auch andere Produkte wie zum Beispiel Statos HiDrive benutzen.
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!
Entries (RSS)