Ergebnis 1 bis 1 von 1
  1. Beitrag #1
    Themenstarter
    Administration Avatar von Nero24.

    Registriert seit
    01.07.2000
    Beiträge
    18.305
    Danke
    9
    Gedankt 6.039 Mal für 975 Themen
    Blog-Einträge
    20

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Einleitung

    Die Datenmengen, die selbst durchschnittlich enthusiastische Anwender auf ihren Computern speichern, werden immer größer. Schon die Fotos handelsüblicher Digital-Kameras sind inzwischen 5 MB-Brocken oder mehr. Wer dazu noch begeistert Filme oder Serien über DVB aufnimmt und archiviert oder gar mit der HDTV-Kamera eigene AVCHD-Filme erstellt, der hat es mit Datenaufkommen zu tun, die vor einer Dekade noch einem kleinen Rechenzentrum gut zu Gesicht gestanden hätten.

    Da stellt sich unweigerlich die Frage wohin mit den ganzen Daten? Gut, Festplatten - interne wie externe - sind inzwischen spottbillig und auch NAS (Network Attached Storage) Lösungen gibt es fix und fertig bis hinab zum SoHo (Small Office, Home Office) Bereich zu kaufen. Dabei hat jede Lösung seine Vor- und Nachteile. Was wenn die externe Festplatte ausfällt? Dann ist in der Regel alles weg, es sei denn man macht sich die Mühe alles doppelt zu sichern und hält sich sklavisch an einen selbst erstellten Sicherungsplan, damit auch wirklich immer alles doppelt dort landet wo es hin soll. NAS-Systeme dagegen sind im Grunde Home-Server, die auf Wunsch auch mit Redundanz (RAID-1 oder RAID-5) zu haben sind und eine gewisse Erweiterbarkeit mit sich bringen. Allerdings sind die auch wirklich nur zum Speichern von Daten zu gebrauchen und gehen mit 500 EUR aufwärts für Geräte namhafter Hersteller ab ca. 3 TB schon ordentlich ins Geld. Die Skala nach oben ist offen.

    Doch es geht auch anders. Ein richtiger Home-Server muss nicht Unsummen an Geld kosten. Mit einer cleveren Komponenten- und System-Auswahl schlägt man gleich mehrere Fliegen mit einer Klappe:
    • Maximale Kapazität
    • Vernünftige Redundanz
    • Preiswerte Anschaffung
    • Unauffälliger Betrieb
    • Leichte Wartung und Instandsetzung
    • Maximale Flexibilität und Erweiterbarkeit

    Sprich: wir wollen so viel wie möglich zu so wenig Geld wie möglich mit gerade so viel Aufwand wie nötig.

    Wenn dann noch ein paar Nachbarn, mit denen man im Idealfall bereits vernetzt ist, das gleiche Problem haben und man sich die Kosten teilen kann, wird so ein Unterfangen schnell zum Schnäppchen. Geteiltes Leid ist schließlich halbes Leid. Planet 3DNow! zeigt heute, wie so eine Lösung aussehen könnte.
    [BREAK=Komponenten-Auswahl (Gehäuse und Prozessor)]

    Komponenten-Auswahl

    Gehäuse

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris


    Wir möchten maximale Erweiterbarkeit haben, also wählen wir ein Gehäuse, das möglichst viele interne Einschübe bietet. Da gibt es unzählige Angebote. Wir haben uns für das Chieftec Mesh CA-01B-B-SL entschieden, das 8 interne 3,5" Einschübe bietet, die quer verbaut und daher leicht zu "füttern" sind. Zudem sind 6 interne 5,25" Slots vorhanden, die mit billigen 5,25-zu-3,5" Adaptern ebenfalls noch genutzt werden können falls nötig.

    Prozessor

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Für einen reinen Fileserver wäre eigentlich kein besonderer Prozessor notwendig. Hauptsache billig, Hauptsache stromsparend. Wer allein das im Auge hat, könnte aber genauso gut eine fertige NAS-Lösung nehmen; oder er greift zu einem der neuen AMD Sempron "Sargas" Single-Core Prozessoren, die unter 30 EUR kosten und eine TDP von 45 W haben.

    Wir jedoch möchten uns alle Optionen wie z.B. Virtualisierung offen halten. 45 W TDP ja, aber bitte mit Sahne. Daher haben wir zum neuen AMD Athlon II X4 600e gegriffen, einem Quad-Core Prozessor mit 4x 2,2 GHz Taktfrequenz, der bei Bedarf genügend Power hat, um auch mal die ein oder andere virtuelle Maschine darauf laufen zu lassen.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Als Kühler kommt ein verwaister AMD Boxed-Kühler zum Einsatz, der irgendwann einmal von irgendeinem 65 W AMD Prozessor übrig geblieben ist und sich in Zukunft mit dem 600e langweilen darf. Oder man nimmt gleich die Boxed-Version, die es aber noch nicht gab, als wir eingekauft haben.
    [BREAK=Komponenten-Auswahl (RAM und Mainboard) und Nachtrag vom 21.11.2009]

    Arbeitsspeicher

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris


    Für einen Fileserver bedürfte es keines opulenten RAM-Ausbaus. Da wir aber wie gesagt Reserven für mehr haben möchten, greifen wir zu 2 x 2 GB, um Dual-Channel nutzen zu können. Da - was viele nicht wissen - auch die normalen Desktop-Prozessoren von AMD ECC-Speicher unterstützen (nur keine registered Module!), haben wir uns für 2x 2 GB Kingston DDR2-800 ECC-RAM entschieden, da der Server im Dauerbetrieb rund um die Uhr laufen wird, und Bitfehler in diesem Einsatz-Szenario äußerst unerwünscht sind. Schließlich wird ein Großteil des RAMs als Cache verwendet werden. Wenn dort ein Bit kippt, ist die Datei beschädigt, was von kaum merklich (Videos) über nervig (Tonstörung im MP3-File) bis hin zum Supergau (falsche Daten im Buchhaltungs-Backup) führen kann. Zudem ist ECC-Speicher nicht viel teurer, als normaler Desktop-Speicher, weshalb wir die zusätzliche Sicherheit gerne mitnehmen.

    Mainboard

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Die Memory-Controller der AMD Desktop-Prozessoren unterstützen zwar ECC-RAM, aber um die integrierte Fehlerkorrektur auch wirklich nutzen zu können, muss auch das Mainboard diese Funktion unterstützen und aktivieren können. Viele der Low-Cost Mainboards können dies leider nicht bzw. bieten im BIOS schlichtweg keine Funktion an, um ECC aktivieren zu können. Daher ist das Kriterium Nr. 1.

    Kriterium Nr. 2 sind - neben einem möglichst günstigen Anschaffungspreis - auch möglichst viele SATA-Anschlüsse, um bereits ohne Erweiterungskarten ein Maximum an Festplatten anschließen zu können.

    Wir haben uns bei der Anschaffung für das ASUS M3A76-CM entschieden. Es bietet ECC-RAM Support, Support für die neuesten AMD Athlon II Prozessoren in 45 nm Bauweise, sowie 6 gleichberechtigte SATA-300 Anschlüsse. Obendrein besitzt das Board eine aktive Lüftersteuerung bis herunter zu 4 V, was es ermöglicht den CPU-Lüfter je nach Last in einem beinahe unhörbaren Drehzahlbereich zu betreiben, sowie Gigabit-Ethernet, um möglichst schnell auf den Server zugreifen zu können.

    Nachtrag vom 21. November 2009

    Wie bereits in einer News vom 17.11.2009 ausführlich geschildert gab es in der Praxis Probleme mit dem Realtek RTL8111C PCI-Express Netzwerk-Chip, der auf dem Mainboard unserer Wahl (und den meisten anderen Boards mit AMD-Chipsatz) verbaut ist. Zwar wurde er von OpenSolaris erkannt und funktionierte in der Testphase auch, im Praxisbetrieb unter hoher Last jedoch stellte er immer mal wieder für ein paar Minuten seinen Dienst ein. Näheres dazu und was man dagegen tun kann, siehe in der Meldung.

    Wir hatten in der News geschrieben, wir würden mit einem Intel PCI-Express Adapter gegentesten ob das Problem weg ist, da aus der OpenSolaris-Community immer wieder die Empfehlung für diese Karten kam. Es handelt sich dabei um den Intel Gigabit CT Desktop Adapter, der für relativ wenig Geld (ab 20 EUR) zu haben ist. Und das Problem ist in der Tat wie weggeblasen. Wer also auf Nummer sicher gehen will und den halbgaren "Hacks" für den Realtek-Chip nicht vertraut, sollte die Intel NIC noch in seine Kalkulation mit aufnehmen. Eine ausführliche Kompatibilitätsliste für Netzwerk-Karten unter OpenSolaris gibts bei Sun.
    [BREAK=Komponenten-Auswahl (Netzteil und Festplatten)]

    Netzteil

    Wer unsere aufwändigen Netzteil-Tests auf Planet 3DNow! regelmäßig liest, der weiß: wer am Netzteil spart, spart an der falschen Stelle. Billige Noname-Netzteile können nicht nur laut, sondern aufgrund ihres schlechten Wirkungsgrads von kaum mehr als 50 Prozent auch richtige Energievernichter sein. Beides wollen wir für einen Server, der rund um die Uhr läuft und möglichst wenig auffallen und Kosten verursachen soll, nicht.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Aus diesem Grund kam für uns nur ein Netzteil in Frage, das mindestens das 80PLUS Bronze Zertifikat besitzt und möglichst leise ist. Die Wattzahl ist dabei unerheblich, da in unserem Server keine leistungshungrigen Komponenten zum Einsatz kommen. Eines der billigsten 80PLUS Bronze Netzteile wäre das Listan BQT L7-300W alias be Quiet! Pure Power 300 Watt. Hier hat sicherlich jeder Anwender, der einen gewissen Erfahrungsschatz in petto hat, seinen eigenen "Liebling", dem er einen "24/7" laufenden Server ruhigen Gewissens anvertraut. Wir haben uns bei unserem Fileserver für das Enermax Pro82+ 385 W entschieden.

    Festplatten


    Da der Server Unmengen an Daten fassen, aber dennoch ein Mindestmaß an Redundanz bieten soll, kommen wir um RAID (redundant array of independent disks) nicht herum. Die einfachste Variante davon wäre RAID-1 (Mirror). Hierbei hätte jede Festplatte einen 1:1 Spiegel. Fällt eine Platte aus, ist immer noch die andere da. Der Nachteil für den Einsatz als "Datengrab" ist, dass bei einem RAID-1 die doppelte Kapazität benötigt wird, die letztendlich nutzbar ist. Oder anders formuliert: wer 2 TB nutzen will, muss 4 TB kaufen.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Kosteneffizienter ist da ein RAID-5 (Parity). Dafür sind mindestens 3 Festplatten notwendig. Wer hier 2 TB nutzen will, muss nur (bei Verwendung von 3 Festplatten) 3 TB kaufen. Oder allgemein:
    Nutzkapazität = (Anzahl der Festplatten-1) × (Kapazität der kleinsten Festplatte)
    Bei einer großen Anzahl an identischen Festplatten wird der Verlust durch das RAID-5 immer kleiner. Wer zum Beispiel ein RAID-5 bestehend aus zehn 1 TB Festplatten erstellt, hat immerhin 9 TB Nutzkapazität. Allerdings darf bei einem RAID-5 nur eine einzige Festplatte aus dem Verbund ausfallen, um trotzdem noch Zugriff zu haben. Fallen aufgrund unglücklicher Umstände 2 Platten aus - was umso wahrscheinlicher wird, je mehr Platten man einsetzt - ist auch bei einem RAID-5 alles verloren. Wer also möglichst viele Festplatten zu einem Verbund zusammenspannen will, sollte eher zu RAID-6 greifen. Hier gilt:
    Nutzkapazität = (Anzahl der Festplatten-2) × (Kapazität der kleinsten Festplatte)
    Hier sind bei Verwendung von zehn 1 TB Festplatten immerhin 8 TB nutzbar und es dürfen 2 Festplatten ausfallen ohne dass alles weg ist.

    Für unseren Server haben wir uns für ein RAID-5 bestehend aus (vorerst) 3 Festplatten entschieden, die wir später bei Bedarf stufenweise erweitern wollen. Die Wahl fiel dabei auf die Seagate 5900.12 Serie, einer speziellen SATA2-Baureihe von Seagate, die im Desktop-Bereich normalerweise nicht eingesetzt wird. Statt mit 7200/min dreht diese Serie nur mit 5900/min, was nicht nur der Geräuschentwicklung und dem Stromverbrauch zu Gute kommt, sondern auch der Dauerhaltbarkeit. Die Rohleistung, die natürlich niedriger liegt, als bei den 7200er Modellen, interessiert uns hier nicht, da der begrenzende Faktor sowieso das Gigabit-Netzwerk ist und nicht die Festplatte, da sich ein RAID-5 auch leistungssteigernd auswirkt.

    In Sachen Größe gestaltete sich das Ganze zum Zeitpunkt der Recherche wie folgt:
    • 500 GB => 72 EUR pro TB
    • 750 GB => 76 EUR pro TB
    • 1000 GB => 63 EUR pro TB
    • 1500 GB => 54 EUR pro TB
    • 2000 GB => 77 EUR pro TB
    Das heißt den günstigsten Preis pro Kapazitätseinheit erhielten wir bei der 1,5 TB Variante, weshalb wir 3 Stück davon wählten und somit (im RAID-5) 3 TB Nutzkapazität erhielten.
    [BREAK=Komponentan-Auswahl (Controller und Betriebssystem)]

    Controller

    In Sachen Controller und Schnittstelle kommen prinzipiell drei Varianten in Frage:
    1. Hardware-Raid Controller mit eigenem RAM und Prozessor
    2. "Fake" RAID über das Mainboard-BIOS und den Controller-Treiber
    3. Software-RAID über das Betriebssystem
    Jede Variante hat ihre ganz speziellen Vor- und Nachteile. Die professionellste wäre natürlich das Hardware-RAID, auch weil die hochwertigsten dieser Controller die Möglichkeit bieten ein bestehendes RAID-5 aus z.B. 3 Festplatten nachträglich um zusätzliche Festplatten zu erweitern. Das möglicherweise vorhandene Performance-Plus dieser Variante interessiert uns dabei weniger. Eher schon die horrenden Preise, die für solche Lösungen aufgerufen werden.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Der Areca ARC-1220 Controller etwa, der 8 SATA2-Anschlüsse bietet und damit wie die Faust aufs Auge zu unserem Chieftech-Gehäuse mit 8 internen Einschüben passen würde, kostet beim billigsten Anbieter 363 EUR. Für einen echten Server im professionellen Einsatz kein Ding, für unsere Zwecke dagegen ein k.o-Kriterium.

    Auch die RAID-Funktionen der Mainboards fallen von vorne herein weg. Erstens können sie einen Verbund nicht nachträglich erweitern, zum zweiten bieten sie in Sachen Systemlast keinen Vorteil zu einem Software-RAID und zum dritten ist man in Sachen Betriebssystem auf Gedeih und Verderb dem Treibersupport des Chipsatz-Herstellers ausgeliefert. Zudem ist es schwierig in einigen Jahren im Falle eines defekten Mainboards den Server wieder in Gang zu bekommen, ohne möglichst das identische Mainboard wieder zu beschaffen. Das jedoch wird im Laufe der Jahre immer schwieriger.

    Betriebssystem / Dateisystem

    Das führt uns unweigerlich zum Thema Software-RAID. Vorteil: es lässt sich jede Festplatte in einen Verbund integrieren, solange sie als Festplatte erkannt wird und es ist keine teure Hardware nötig. Obendrein können beliebige weitere preisgünstige SATA/IDE-Controller nachgerüstet werden falls nötig solange noch Steckplätze und Einschübe vorhanden sind.

    Hier kommen wir an einen Punkt, der geradezu nach ZFS schreit. ZFS bedeutet Zettabyte File System. Es ist ein Dateisystem, das von Sun für das Server-Betriebssystem Solaris entwickelt wurde. Es ist Dateisystem und Volume-Manager in einem und beherrscht 16 EB (Exa-Byte; 1.000.000.000.000.000.000 Byte oder 1 Mrd. GB). Das sollte "vorerst" genügen.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Das interessante an ZFS ist aber nicht vorwiegend die schier unendliche Kapazität, die es verwalten kann (die ist in der Praxis sowieso durch die Anzahl der Festplatten beschränkt), sondern seine Pool-Verwaltung. So lassen sich mit ZFS Festplatten - ganz egal an welchem Port oder Controller sie hängen (Hauptsache die werden erkannt) - zu einem sog. Pool zusammenspannen. Dabei beherrscht ZFS nicht nur die lineare Aneinanderschaltung von Datenträgern zu einem, sondern auch RAID-5 (hier raidz1 genannt) und RAID-6 (raidz2) - und das ohne teuren HW-RAID-Controller und ohne die Abhängigkeit von irgendwelchen Fake-RAIDs per BIOS oder Treiber-Support. Mit ZFS ließe sich auch eine externe USB-Festplatte, eine SATA-Festplatte, eine IDE-Festplatte und eine FireWire-Festplatte zu einem raidz zusammenspannen. Das interessiert ZFS im Grunde nicht.

    Allerdings verlassen wir beim Thema ZFS unweigerlich jene Pfade, die der User von der Windows-Welt her kennt, denn ZFS ist nur für Betriebssysteme verfügbar, die gerne als "exotisch" bezeichnet werden: Solaris 10, OpenSolaris und FreeBSD.

    Da Solaris 10 zwar frei verfügbar ist, für Support jedoch ein kostenpflichtiger Wartungsvertrag erworben werden muss und der ZFS-Support bei FreeBSD noch auf Status "experimentell" steht, wollen wir uns heute näher mit der Realisierung mittels OpenSolaris befassen. Das Betriebssystem ist nicht nur kostenlos, sondern auch Open-Source. Der Support findet auf Community-Ebene statt. Zudem bietet OpenSolaris out-of-the Box eine grafische Oberfläche, was gerade Windows-Usern den ersten Schrecken nehmen dürfte. Allerdings sollte man sich keinen Illusionen hingeben: wer meint, unter OpenSolaris alles per Mausklick regeln zu können a la Geräte-Manager oder Partition-Magic, der ist auf dem falschen Dampfer. Andererseits wollen wir OpenSolaris ja nicht umfassend als Anwender nutzen, sondern uns lediglich seiner einzigartigen Poolverwaltung bedienen. Und genau das wollen wir heute in Form dieses Artikels zeigen.
    [BREAK=Zusammenbau]

    Zusammenbau

    Wer ein wenig Erfahrung mit dem Bau von Computer-Systemen hat, dem geht unser Server hier sehr leicht von der Hand. Sauberes und besonnenes Arbeiten setzen wir voraus. Wenn Teil A nicht auf Anhieb in Teil B hinein passt, werden auch 200 N Krafteinsatz nichts daran ändern. Gelegentliches erden an Heizkörper, Dunstabzugshaube oder einem anderen (eingesteckten) Computer-Gehäuse ist dringend zu empfehlen, um keine der Komponenten durch statische Entladung zu vernichten.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Wir beginnen mit dem Öffnen des Server-Gehäuses. Wie man sieht ist das Gehäuse äußerst ausladend. Platzangst muss also niemand erleiden bei unserem kleinen Experiment und die Fingerfertigkeit eines Feinmechanikers ist hier im Gegensatz zu einigen Midi-Tower PCs mit Vollausstattung auch nicht notwendig.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Anschließend bauen wir das Netzteil mit den beiliegenden Schrauben ein und ordnen dessen Kabel zum späteren anschließen.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Als nächstes packen wir das Mainboard aus (vorher erden!), bauen das ATX-Panel in das Gehäuse, drehen die richtigen Befestigungsschrauben in den Gehäuseboden und fixieren anschließend das Mainboard auf denselben.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Es folgt die CPU (vorher erden!), der Kühler (falls kein Pad an der Unterseite klebt vorher etwas Wärmeleitpaste auf den CPU-Heatspreader geben), und (vorher erden und nochmal erden!) die RAMs.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Hier das Handbuch des Mainboards konsultieren, welche der RAM-Slots für Dual-Channel Betrieb zu bestücken sind. Bei unserem Mainboard sind es die Slots 1 und 3.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Festplatten mögen es möglichst kühl, daher installieren wir vor dem Einbau der Festplatten einen passenden (hier 92 mm großen) langsam drehenden Lüfter hinter den HDD-Schächten, um einen Hitzestau um die Festplatten herum zu vermeiden.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Anschließend stecken wir die Schienen in die Bohrungen der Festplatten und schieben die Platten in die Schächte.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Um später im Falle eines Ausfalls einer Platte sofort die richtige lokalisieren zu können, sollte man sich an ein bestimmtes System halten. So könnte man z.B. die erste HDD von oben an den SATA Nr. 1 Anschluss stecken, die zweite an den Nr. 2 und so weiter.

    Wenn alle Komponenten verbaut sind, schließen wir noch Bildschirm, Tastatur und Maus, die im späteren Betrieb nicht mehr unbedingt nötig sind, sowie ein Netzwerkkabel an und leiten nach gewissenhafter Überprüfung aller Anschlüsse und Komponenten einen ersten Probestart ein. Wir prüfen, ob sich die Lüfter drehen, hören auf eventuelle POST-Signale (Power-on-self-Test) und falls alles ok ist, gehen wir ins BIOS und nehmen die grundlegenden Einstellungen vor.

    Nach einem "Load Setup Defaults" und/oder "Load BIOS Defaults" sind das vor allem folgende Aspekte:
    1. Ggf. BIOS-Update durchführen, falls Auslieferungs-BIOS die CPU noch nicht korrekt erkennt; ggf. CPU-Support Liste des Mainboard-Herstellers konsultieren.
    2. Datum und Uhrzeit korrekt einstellen
    3. Virtualisierungsfunktionen der CPU aktivieren
    4. SATA-Controller aktivieren und den IDE-Betriebsmodus einstellen. Verwirrenderweise hat ASUS den IDE-Modus bei unserem Mainboard mit "SATA" benannt. Daher formulieren wir es anders: den SATA-Controller weder auf RAID noch auf AHCI setzen.
    5. Automatische Lüftersteuerung aktivieren und sinnvolle Grenzwerte eintragen falls gefordert
    6. ECC aktivieren und die schärfste ECC-Korrektur wählen, da Performance bei uns keine Rolle spielt, Datenintegrität aber sehr wohl
    Anschließend Einstellungen abspeichern.
    [BREAK=Vorbereitende Tests]

    Komponenten-Tests

    Ehe wir mit der Installation des Systems beginnen, einem System, dem wir all unsere wichtigen und mühsam erarbeiteten Daten anvertrauen wollen, bedarf es natürlich einiger Vorab-Tests. Wenn man - wie von uns empfohlen - Komponenten namhafter Hersteller gekauft hat, ist zwar das Risiko ab Werk defekte Bauteile zu erhalten geringer, aber ausgeschlossen ist es natürlich nicht.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Daher empfehlen wir mindestens folgende Schritte:
    • Test des RAMs mit Memtest86+
    • Advanced Test jedes Datenträgers mit dem jeweiligen Festplatten-Hersteller Tool; hier Seagate Seatools
    Zudem müssen wir auch das Betriebssystem noch auf irgendeinen Datenträger installieren. Das kann eine >4 GB SSD sein, wenn Preis keine und Lautstärke die Hauptrolle spielt oder irgendeine andere Festplatte.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Wir haben uns - nicht erschrecken - für eine gebrauchte Maxtor 40 GB IDE-Festplatte entschieden, die wir zusammen mit einem IDE DVD-ROM Laufwerk an den einzigen IDE-Anschluss des verwendeten Mainboards gehängt haben (HDD als Master, DVD als Slave). Damit beansprucht die OS-HDD keinen der kostbaren 3,5" Einschübe, denn wir haben sie mit einem Adapter direkt über dem DVD-ROM in einen 5,25" Platz geschoben, und keinen der SATA-Anschlüsse. Zudem werden auf der Betriebssystem-Festplatte keine Daten gespeichert, weshalb hier Ausfallsicherheit auch nicht die tragende Rolle spielt. Natürlich ist die Festplatte vor der Inbetriebnahme genauso auf Fehlerfreiheit zu untersuchen mit dem Hersteller-Tool, wie jene Platten, die gleich für das Raid-Z verwendet werden.

    "Aber wenn die Betriebssystem-Platte ausfällt, geht doch erst mal gar nichts mehr!", wird der ein oder andere hier einwerfen. Das ist richtig. Deswegen fertigen wir von der OS-HDD nach Fertigstellung der Installation und der Konfiguration auch ein Image an. Sollte die OS-HDD ihren Geist aushauchen, stecken wir einfach eine andere hinein und spielen das Image zurück. Die Daten auf dem Raid-Z werden davon nicht tangiert. Da allerdings die meisten Festplatten-Image Programme wie Norton Ghost, Paragon Drive Backup oder Acronis True-Image das ZFS-Dateisystem der OpenSolaris-Installation noch nicht beherrschen, muss von der OS-HDD ein sogenanntes RAW-Image erstellt werden. Das heißt, hier wird einfach ein Image Sektor für Sektor erstellt und das Image-Tool schert sich gar nicht darum, welches Dateisystem verwendet wird. Das Image räumen wir in den Schrank und hoffen, dass wir es nie benötigen werden. Werden später Änderungen an der Konfiguration - insbesondere des ZFS-Pools - vorgenommen, muss natürlich ein neues Image der OS-HDD erstellt werden, um im Falle des Falles den aktuellen Stand griffbereit zu haben.
    [BREAK=Zusammenfassung Anschaffung]

    Zusammenfassung Anschaffung

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris


    Zusammenfassend haben wir damit folgendes ausgegeben:
    • AMD Athlon II X4 600e 45 W TDP = 100 EUR
    • ASUS M3A76-CM Mainboard = 50 EUR
    • 2x 2 GB Kingston DDR2-800 ECC-RAM = 60 EUR
    • 3x 1,5 TB Seagate 5900.12 SATA2-HDDs = 255 EUR
    • Chieftech Mesh Bigtower-Gehäuse = 75 EUR
    • Enermax Pro82+ 385 W Netzteil = 60 EUR
    • Übriger 65 W AMD Boxed Kühler = 0 EUR
    • Übrige IDE-Festpatte = 0 EUR
    • Übriges IDE DVD-ROM = 0 EUR

    ============================================
    Gesamt => 600 EUR

    Würden wir den Quad-Core Prozessor und die 4 GB RAM nicht benötigen, weil wir nicht vor hätten virtualisierte Computer auf dem Server laufen zu lassen, sondern rein die Nutzung als Fileserver vorsehen, hätten wir das auch für knapp 150 EUR weniger bekommen:
    • AMD Sempron 140 45 W TDP = 30 EUR
    • ASUS M3A76-CM Mainboard = 50 EUR
    • 1x 1 GB Kingston DDR2-800 ECC-RAM = 15 EUR
    • 3x 1,5 TB Seagate 5900.12 SATA2-HDDs = 255 EUR
    • Chieftech Mesh Bigtower-Gehäuse = 75 EUR
    • be Quiet! Pure Power 300 W Netzteil = 35 EUR
    • Übriger 65 W AMD Boxed Kühler = 0 EUR
    • Übrige IDE-Festpatte = 0 EUR
    • Übriges IDE DVD-ROM = 0 EUR

    ============================================
    Gesamt => 460 EUR

    [BREAK=Installation OpenSolaris]

    Installation OpenSolaris

    Die x86_64 Version von OpenSolaris ist frei verfügbar. Voraussetzung für die Installation ist irgendein AMD-Prozessor ab dem Opteron oder Athlon 64 (K8 oder höher), oder ein Intel-Prozessor, der EM64T alias Intel 64 unterstützt.

    Download: OpenSolaris 2009.06 x86_64 international

    Das Image kann anschließend mit jedem beliebigen Brennprogramm wie Nero, InfraRecorder oder CDBurnerXP auf einen CD-Rohling gebrannt werden. Anschließend die gebrannte CD in den Server einlegen, den Server einschalten und von CD booten.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    OpenSolaris startet dabei nicht sofort mit der Installation, sondern fährt mit einer Live-CD hoch wie man es von Knoppix oder anderen Linux-Distributionen kennt. Auf dem Desktop der Live-CD befindet sich dann unübersehbar ein Icon namens "Install OpenSolaris" oder "OpenSolaris installieren". Das klicken wir und arbeiten uns durch den Installations-Assistenten, der uns fragt auf welcher Festplatte, mit welcher Tastatur-Unterstützung und in welcher Sprache wir OpenSolaris installieren wollen. Zudem müssen wir einen User anlegen, der am ehesten mit dem Windows Hauptbenutzer vergleichbar ist. Damit melden wir uns an nach der Installation, da Solaris das Login mit dem Administrator - in der Unix-Welt root genannt - nicht gestattet.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Sind alle Fragen beantwortet und die Systemdateien kopiert, empfängt uns OpenSolaris nach dem Login mit obigem Bildschirm.

    Komponenten nachinstallieren

    OpenSolaris besitzt eine grafische Paketverwaltung, die es gestattet Anwendungen per Mausklick zu deinstallieren oder nachzuinstallieren; entweder von CD, oder von einer Quelle im Internet, den sog. Repositories (engl. Lager/Depot). Für unsere Zwecke benötigen wir Letzteres jedoch nicht.

    Wir könnten nun entweder einfach mit Tastatur und Bildschirm weiterarbeiten, oder wir installieren als erstes einen VNC-Server, mit dessen Hilfe wir uns remote auf die OpenSolaris-Oberfläche loggen und alles weitere vom Bildschirm des PCs erledigen können. Wer das wünscht, muss zuerst einmal den VNC-Server nachinstallieren.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Je nach Wunsch sind unter /etc/X11/gdm/custom.conf ggf. folgende Einträge zu machen:
    [xdmcp]
    Enable=true
    [security]
    DisallowTCP=false
    AllowRoot=true
    AllowRemoteRoot=true
    Dazu erst einmal mit den Terminal starten, mit...
    su
    ...Admin-Rechte anfordern und mit...
    pfexec gedit /etc/X11/gdm/custom.conf
    ...den grafischen Editor samt zu bearbeitender Datei starten, mit dem User aus der Windows-Welt vermutlich eher zurecht kommen werden, als mit den teils kryptisch zu bedienenden Text-Editors aus der Unix-Welt. Am Ende mit...
    svcadm disable xvnc-inetd gdm
    svcadm enable xvnc-inetd gdm
    ...den Dienst einmal stoppen und wieder starten, da man sich ansonsten zwar per VNC-Client mit dem Server verbinden kann, aber außer einem grauen Hintergrund nichts zu sehen bekommt. VNC-Clients für Windows sind von unzähligen Quellen verfügbar. Wer keine besonderen Ansprüche hat, kann tightvnc in der Portable-Version wählen, die ohne Installation nur gestartet zu werden braucht.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Anschließend beim Servernamen nur den Hostnamen eintippen (wir hatten bei der Installation "opensolaris" als Hostnamen gewählt) und schon verbindet sich der VNC-Client mit dem Server, da wir einen Router mit DHCP einsetzen, der unserem OpenSolaris-Server automatisch eine IP im Netzwerk verpasst.
    [BREAK=Einrichten des ZFS-Pools]

    Einrichten des ZFS-Pools

    Doch wir wollen gar nicht unnötig lange mit dem den meisten Usern vermutlich fremden Betriebssystem herumspielen, sondern gleich zur Tat schreiten.

    Um von Windows-PCs auf Dateien zugreifen zu können, die von einem OpenSolaris-Server im Netzwerk freigegeben werden, ist ein SMB-Server nötig. Wir verwenden dazu den SUN-eigenen und nicht den aus der Linux-Welt bekannten Samba, der bei OpenSolaris ebenfalls dabei wäre, da ersterer direkt ins System integriert ist und nicht gesondert konfiguriert zu werden braucht.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Über die Paketverwaltung, die direkt auf dem Desktop unter der Bezeichnung "Weitere Software hinzufügen" liegt, suchen wir nach "SUNWsmbs". Es sollten zwei Pakete gefunden werden, die wir kurzerhand installieren.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Wir starten wieder den Terminal, holen uns mit "su" Admin-Rechte und aktivieren mit den Befehlen...
    svcadm enable -r smb/server
    svcs smb/server
    ...den SMB-Server und checken, ob er wie gewünscht arbeitet. Wenn alles ok ist, sollte eine Ausgabe wie oben zu sehen sein.

    Mit dem Befehl "format", der absolut nichts mit dem Format-Befehl unter DOS/Windows zu tun hat, lässt man sich die aktuelle Festplatten-Konfiguration anzeigen:

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    In unserem Fall ist die unter 1. gelistete Platte die IDE-Festplatte, die wir für das Betriebssystem verwenden. Die unter 0./2./3. geführten Platten sind die drei 1,5 TB SATA-Platten, die wir zu einem Software RAID-5, im ZFS-Jargon raidz1 genannt, zusammenspannen wollen. Dies erfolgt über die Bezeichnungen, die OpenSolaris den Platten verpasst hat.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Mit der Tastenkombination STRG-C kann der Dialog abgebrochen werden. Der Befehl zur Erstellung des RAID-5-Pools lautet:
    zpool create daten raidz1 c7d1 c9d0 c9d1
    zpool ist der Befehl, create die Anweisung was zu tun ist - nämlich einen neuen Pool anzulegen -, daten ist der beliebig wählbare Name des Pools, den wir - nachdem wir hier Daten aller Art speichern wollen - einfach auch so genannt haben, raidz1 ist der Parameter, der ZFS veranlasst ein RAID-5 anzulegen und die drei Bezeichnungen dahinter stehen für die Namen der Festplatten, die uns der Format-Befehl ausgegeben hatte.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Anschließend prüfen wir mit...
    zpool list
    ...ob alles so geklappt hat, wie wir uns das vorgestellt hatten.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Der Befehl...
    zpool status -v
    ...zeigt das Ganze etwas detaillierter.
    [BREAK=Ordner-Freigabe für Alle]

    Ordner-Freigabe für Alle

    Vorbereitend müssen wir wieder in die Konsole und als "su" die Datei /etc/pam.conf bearbeiten. Dies kann wie oben beschrieben mit gedit erfolgen. Folgende Zeile muss in die Datei eingefügt werden:
    other password required pam_smb_passwd.so.1 nowarn
    Anschließend sollte man das System neu starten, um die Änderung definitiv umgesetzt zu wissen.

    Nun kann es losgehen. Zuerst einmal hätten wir gerne, dass der Server in der Windows Netzwerkumgebung angezeigt wird, sich also in der selben Arbeitsgruppe meldet, wie die Windows-Clients.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Das lässt sich mit...
    smbadm join -w Arbeitsgruppe
    ...arrangieren, wobei "Arbeitsgruppe" der Name der Arbeitsgruppe ist, der natürlich unterschiedlich sein kann je nachdem, was bei den Windows-Clients dort eingestellt wurde.

    Als nächstes wollen wir auf unserem RAID-5 Pool einen Ordner anlegen und für alle berechtigten User pauschal zur Nutzung freigeben. Einsatzgebiet wäre hier z.B. die DVB-Filmesammlung, zu der alle Beteiligten ihren Beitrag leisten, und die auch von allen genutzt werden können soll.

    Alle "berechtigten" deshalb, da es unter Solaris eine "Einfache Dateifreigabe" wie man sie etwa unter Windows XP kennt, wo jeder lesen oder lesen und schreiben darf, nicht gibt. Daher muss man unter OpenSolaris zumindest einen User anlegen, unter dem sich die Clients später am Server anmelden. Wenn außer dem Ordner für Alle nichts weiter mit beschränkten Rechten freigegeben werden soll, kann das auch der bereits existierende Installationsbenutzer sein.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Zuerst einmal müssen wir jedoch die Freigabe definieren. Dies geschieht mittels:
    zfs create -o casesensitivity=mixed daten/public
    zfs set sharesmb=on daten/public
    Die erste Zeile erstellt einen Ordner namens "public" auf unserem Pool "daten" und sorgt dafür, dass Groß- und Kleinschreibung auf die gleiche Weise gehandhabt wird wie unter Windows. Die zweite Zeile gibt den Ordner über SMB im Netzwerk frei. Mit...
    sharemgr show -vp
    ...kann man prüfen, ob die Freigabe erfolgreich war.

    Mit dem Befehl...
    chmod a+rwx /daten/public
    ...legen wir fest, dass jeder Benutzer auf den Ordner public zugreifen und lesen sowie schreiben darf.

    Allerdings ist die Zugriffsverwaltung unter ZFS etwas komplexer, als von Windows gewohnt. Hier kann mittels ACL (Access Control Lists; engl. Zugriffskontrolllisten) festgelegt werden, was passieren soll, wenn einer der Benutzer auf die Freigabe zugreift. Hier gab es das Problem, dass wir zwar über die Windows Netzwerkumgebung auf die Freigabe zugreifen und Dateien sowohl erstellen, als auch lesen konnten, die Dateien und Ordner jedoch mit der Zugriffsberechtigung 0000 erstellt wurden. Sobald sie innerhalb der Freigabe verschoben wurden, war kein Zugriff mehr möglich bzw. erlaubt. Daher haben wir die ACL für diesen Ordner wie folgt angepasst:
    /usr/bin/chmod A=everyone@:full_set:fd:allow /daten/public
    Damit erhalten ab sofort alle Dateien und Ordner, die in dieser Freigabe von egal welchem (berechtigten) User erstellt werden, Vollzugriff für alle (berechtigten). Wie gesagt: anonymen Zugriff wie unter Windows gibt es nicht. Jemand, der Benutzername und Passwort eines der angelegten OpenSolaris-User nicht kennt, kommt trotzdem nicht an die Freigabe - und das ist auch gut so!

    Wer nicht ständig umständlich über die Netzwerk-Umgebung navigieren will, kann die Freigabe des OpenSolaris-Servers auch als Netzlaufwerk am Windows-Client hinterlegen.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Dazu (unter Windows XP; Vista äquivalent) einfach in den Arbeitsplatz gehen, im Menü "Extras" den Punkt "Netzlaufwerk verbinden" wählen, den gewünschten Laufwerksbuchstaben wählen, den das Netzlaufwerk erhalten soll, darunter den Netzwerk-Pfad zum Freigabe-Ordner wählen (in unserem Beispiel wäre das \\opensolaris\daten_public), falls gewünscht den Haken aktivieren, dass das Netzlaufwerk auch einen Neustart überleben soll und dann - ganz wichtig - darunter den Link wählen "Verbindung unter anderem Benutzer herstellen." Dort kann man dann seinen Benutzernamen und das Passwort seines OpenSolaris-Users eintragen. Mit OK bestätigen und Fertig stellen.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris


    Anschließend erhält man über das entsprechende Laufwerk im Arbeitsplatz Zugriff auf den public-Ordner auf dem OpenSolaris-Server.
    [BREAK=Private Ordner für verschiedene Benutzer]

    Private Ordner für verschiedene Benutzer

    Die gemeinsame Freigabe für Alle mag für einige Einsatz-Szenarien angebracht sein. Zum Ablegen seiner persönlichen Daten oder eines Backups seiner Daten ist das jedoch völlig ungeeignet. Daher wollen wir, dass zusätzlich zum gemeinsamen Ordner jeder beteiligte User auch noch einen privaten Ordner erhält, in dem er seine persönlichen Sachen abspeichern kann und den anderen Usern verborgen bleibt.

    Dazu müssen wir zuerst einmal dafür sorgen, dass der home-Bereich, den unter OpenSolaris jeder angelegte Benutzer erhält, auf unseren RAID-5 Datenpool verschoben wird. Standardmäßig liegt der nämlich wie unter Linux auch auf der Systemplatte. Dies kann mittels eines Snapshots realisiert werden, ebenfalls ein spezielles Feature des ZFS-Dateisystems:
    zfs snapshot -r rpool/export/home@transfer
    Der Snapshot heißt transfer und bezieht sich auf die home-Verzeichnisse aller bereits angelegter User.

    Der eigentliche Befehl zum Umzug erfolgt dagegen mit:
    zfs send rpool/export/home@transfer | zfs receive daten/home
    Das home-Verzeichnis des Benutzers, den wir bei der Installation angelegt haben (in unserem Fall war das "nero24"), schickt man mit...
    zfs send rpool/export/home/nero24@transfer | zfs receive daten/home/nero24
    ...auf die Reise.

    Danach müssen die alten home-Verzeichnisse unmounted werden:
    zfs umount -f rpool/export/home/nero24
    zfs umount -f rpool/export/home
    ...und der neue Speicherort dem System mitgeteilt werden:
    zfs set mountpoint=/export/home daten/home
    zfs set mountpoint=/export/home/nero24 daten/home/nero24
    Der Befehl...
    zfs destroy -r rpool/export/home
    ...löscht das ursprüngliche home-Verzeichnis. Ein Neustart an dieser Stelle kann nicht schaden.

    Nun noch die home-Ordner freigeben...
    zfs set sharesmb=on daten/home
    ...und die Rechte entsprechend setzen:
    chmod go-r /export/home/*
    ...sodass nur und ausschließlich der Besitzer des home-Verzeichnisses dieses lesen kann.

    Nun können die beteiligten User angelegt werden. Dies kann unter OpenSolaris über die Oberfläche erfolgen:

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Jeder hier mittels Benutzername und Kennwort angelegte Benutzer erhält automatisch Zugriff auf unseren gemeinsamen public-Ordner, wenn er sich wie auf der Seite zuvor gezeigt entsprechend beim OpenSolaris-Server mit seinen Kenndaten anmeldet. Zusätzlich dazu erhält er im Freigabe-Ordner home einen Unterordner mit seinem Benutzernamen, auf den nur er Zugriff hat.

    Sollte hier wieder ein vergleichbares ACL-Problem auftreten wie auf der Seite zuvor beschrieben, kann man sich mit einem ähnlichen Befehl behelfen. Nehmen wir an einer der User heißt thomas und besitzt einen entsprechenden home/thomas Ordner für seine persönlichen Sachen, so ist folgender Befehl anzuwenden:
    /usr/bin/chmod A=owner@:full_set:fd:allow /daten/home/thomas
    Dieser Befehl ist einmalig entsprechend bei allen angelegten Benutzern durchzuführen.[BREAK=Erweiterung und Reparatur]

    Erweiterung


    Wir hatten anfangs die Fähigkeit einiger teurer Hardware-RAID-Controller erwähnt, bestehende RAID-5 oder -6 Verbunde durch nachträgliches hinzufügen zu vergrößern. Wir haben auch die Fähigkeit von ZFS erwähnt, Datenpools nachträglich erweitern zu können.

    Beides ist korrekt und dennoch gibt es eine Einschränkung. ZFS kann bestehende raidz1- oder raidz2-Pools nicht nachträglich um eine oder mehrere Festplatten erweitern. Folgender Befehl...
    zpool add daten vdev4
    ..führt leider nicht dazu, dass unserem Software-RAID-5 namens "daten" bestehend aus 3 Festplatten eine vierte hinzugefügt wird. Zwar ist nach Anwendung dieses Befehls ein um die Größe der neuen Platte erweiterter Pool sofort nutzbar, allerdings befindet sich die vierte Platte nicht in der Redundanz des RAID-5. ZFS hat hier dem virtuellen Device namens daten einfach die vierte Festplatte angeflanscht. Das heißt, wenn Festplatte Nr. 4 ausfällt, ist der Pool defekt, da diese nicht in das RAID-5 aufgenommen wurde, sondern diesem nur angehängt wurde. Dies sollte man demnach unbedingt beachten, wenn die ursprüngliche Festplatten-Kapazität nicht mehr genügt.

    Stattdessen muss man sich um die Redundanz selbst kümmern. Man darf demnach nicht nur eine Festplatte hinzufügen, sondern mindestens 2 (für ein RAID-1) oder mindestens 3 (für ein RAID-5). Aus diesen - sagen wir für unser Beispiel - drei neuen Festplatten schnüren wir wie beschrieben zuerst einmal einen neuen raidz1-Pool namens daten2. Damit haben wir einen neuen Pool, für dessen Ausfallsicherheit gesorgt ist.

    Nun können wir mit...
    zpool add daten daten2
    ...den neuen Pool dem alten hinzufügen und diesen entsprechend vergrößern. Im Endeffekt haben wir damit zwei getrennte RAID-5 Software-Arrays, die über die ZFS-Volumeverwaltung zu einem großen Pool zusammengeschaltet wurden.


    Update 13.04.2011
    Theorie und Praxis unterscheiden sich ja leider sehr oft. Nach anderthalb Jahren Dauerbetrieb mit dem hier beschriebenen OpenSolaris Home-Server stand ein Disk-Upgrade an. Und es ist nicht möglich - anders, als oben beschrieben - ein bereits geschnürtes virtual device zu einem bestehenden virtual device hinzufügen.

    Stattdessen: nicht erst schnüren und dann hinzufügen, sondern schnürend hinzufügen.

    Am einfachsten ist es, dem Array ein gleichwertiges vdev hinzuzufügen. Wer schon ein raidz1 Array bestehend hat, kann (wie in diesem Beispiel) drei (oder mehr) weitere Platten dem bestehenden Array ohne weiteres hinzufügen mit dem Befehl:
    zpool add daten raidz1 c7d0 c8d0 c9d0
    Das geht innerhalb von Sekunden.

    Etwas aufwändiger ist es, wenn man einem bestehenden ZFS-RAID-5 etwas anderes hinzufügen möchte. Beispiel: man hat bereits ein ZFS-RAID-5 aus 4 Platten geschnürt und möchte nun auf den beiden verbliebenen SATA-Anschlüssen zwei weitere Festplatten als RAID-1 (Mirror) hinzufügen. Da es sich dabei um unterschiedliche RAID-Levels handelt, sollte man hier den Parameter "-n" bemühen, um zu checken, ob bei Anwendung des Befehls das passieren würde, was man erwartet:
    zpool add -n -f daten mirror c7d0 c8d0
    Parameter -f deshalb, weil zpool ansonsten mit der Meldung abbricht, dass die RAID-Levels nicht identisch sind. Im Idealfall klemmt sich dann das RAID-1 (mirror) bestehend aus 2 weiteren Festplatten nahtlos an das bestehende RAID-5 (raidz1). Wenn die Ausgabe so aussieht, wie man es sich erwartet hat, kann man den Parameter "-n" weglassen. In unserem Fall sieht es nun so aus:

    Dies lässt sich auf ähnliche Weise erweitern. Als nächstes könnten wir einen raidz2-Pool bestehend aus 4 internen SATA-Festplatten, für die wir einen zusätzlichen PCI- oder PCI-Express SATA-Controller benötigen würden, weil uns die Onboard-SATA-Ports ausgegangen sind, sowie einer externen USB-Platte erstellen, den wir daten3 nennen. Für sich betrachtet besitzt dieser daten3-Pool wieder ausreichende Redundanz, wobei wir natürlich niemals eine externe Platte dafür verwenden würden. Das Beispiel soll nur zeigen, was möglich wäre. Den Pool daten3 könnten wir nun abermals per add-Option dem bestehenden Pool namens "daten" hinzufügen und hätten diesen aufs Neue vergrößert.

    Reparatur


    Sollte eine der Festplatten aus unserem raidz-Pool bzw. den raidz-Pools den Geist aufgeben, wechselt der Status des betroffenen Pools von ONLINE in DEGRADED. Abzufragen ist der Status regelmäßig mit dem Befehl:
    zpool status -v
    Um explizit eine Überprüfung des Statuses in Auftrag zu geben, ist der Befehl...
    zpool scrub daten
    ...zu bemühen, um unseren Pool namens "daten" zu untersuchen.

    Sollte in der Tat eine der beteiligten Festplatten defekt sein, muss das System heruntergefahren und eine Austauschplatte eingebaut werden. Anschließend fährt man das System wieder hoch und gibt...
    zpool replace daten defekteplatte neueplatte
    ...als Befehl ein, wobei "defekteplatte" der Name der defekten Platte unter Solaris ist und "neueplatte" entsprechend die gerade eben erst eingebaute im Solaris-Jargon; abzufragen mittels format-Befehl. Solaris versucht dann von der defekten Platte noch herunter zu retten, was zu retten ist, und rekonstruiert den Rest über die RAID-5 Funktionalität. Nach Beendigung des Befehls kann das System heruntergefahren und die defekte Platte ausgebaut werden.[BREAK=Windows unter OpenSolaris mit VirtualBox]

    Windows unter OpenSolaris mit VirtualBox

    Bisher haben wir realisiert, dass ein Datenpool mit einer gewissen Ausfallsicherheit erstellt wurde, dass verschiedene Benutzer in einem Windows-Netzwerk gemeinsamen Zugriff darauf haben und dass jeder dieser Benutzer einen persönlichen Ordner im Netzwerk bekommt, auf den nur er Zugriff hat. Damit könnten wir eigentlich zufrieden sein, denn das war Ziel unseres Ratgebers. Doch für einen reinen Fileserver hätte es nicht 4 GB RAM und eines Quad-Core Prozessors bedurft. Nein, wir wollten uns die Möglichkeit offen halten, mittels einer virtuellen Maschine aus dem OpenSolaris-Server noch mehr zu machen. In einer VM deshalb, da viele Sachen einfach nur für Windows oder Linux verfügbar sind. Finde mal einen XY-Gameserver für OpenSolaris! Oder was, wenn ein MS-SQL Server benötigt wird für irgendeine Aufgabe im Netz?

    Statt für diese Zwecke noch ein weiteres Gerät ins Netzwerk zu hängen, nutzen wir einfach die brach liegenden Ressourcen unseres großzügig dimensionierten OpenSolaris-Servers. Neben dem Open-Source Betriebssystem OpenSolaris gibt es von Sun auch noch das freie Virtualisierungsprogramm VirtualBox.

    Download: Sun VirtualBox 3.08 für Solaris

    Es ist kostenlos verfügbar und kann auf einem Solaris-Host zahlreiche Gast-Systeme zur Verfügung stellen, darunter unzählige Windows- und Linux-Versionen. Seit der Version 3 beherrscht VirtualBox auch Multi-CPU Support für die Gast-Systeme, sowie 3D-Beschleunigung für die Grafikkarte.

    Nach dem Download des VirtualBox-Archivs muss dieses zuerst einmal entpackt werden, z.B. in einen Ordner auf den Desktop unseres Installationsbenutzers. Anschließend öffnen wir den Terminal, holen uns mit "su" Admin-Rechte und fügen VirtualBox mittels...
    pkgadd -G -d VirtualBoxKern-3.0.8-SunOS-r53138.pkg
    pkgadd -d VirtualBox-3.0.8-SunOS-r53138.pkg
    ...zum Paket-Manager hinzu. Die Parameter sorgen dafür, dass die Pakete auch gleich installiert werden. Alle Rückfragen sind mit y wie yes zu quittieren.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Wenn alles glatt gegangen ist, sollte man im Anwendungsmenü unter Systemwerkzeuge Suns VirtualBox finden.

    Die Bedienung der VirtualBox ist beinahe identisch zur Windows-Version. Wenn wir einen neuen virtuellen Computer erstellen wollen, auf/in dem z.B. Windows XP installiert werden soll, so klicken wir einfach auf "Neu" und folgen dem Assistenten. Als Gastbetriebssystem wählen wir "Microsoft Windows" und "Windows XP" und geben dem Kind einen Namen, z.B. WinXP. Anschließend wählen wir, wie viel Hauptspeicher dieser virtuelle Computer erhalten soll.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Je nachdem wie viel im Server verbaut ist und was in der virtuellen Maschine gemacht werden soll sind 512 MB RAM für ein Standard XP-System erst einmal ausreichend. Anschließend fragt VirtualBox, wie groß die virtuelle Festplatte für das Gast-Betriebssystem sein soll.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Wir wählen 10 GB, was für XP plus ein paar Anwendungen ausreichend ist. Das Image wird übrigens im home-Verzeichnis des Installationsbenutzers abgelegt, das ja nach unserer Umbiegeaktion von zuvor auf dem RAID-5 Datenpool abgelegt wird.

    Nach dem Fertigstellen des Assistenten ist der virtuelle XP-Computer erst einmal "gebaut". Nun muss er natürlich noch entsprechend konfiguriert werden.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Über Rechtsklick - Ändern lassen sich die Optionen für unseren virtuellen Computer anpassen. So müssen wir unter "System" zuerst einmal ACPI und IO-APIC aktivieren. Hier kann auch die Bootreihenfolge eingestellt werden, die wir auf Platte / CD-ROM einstellen. Im Reiter "Prozessoren" kann die Anzahl der virtuellen Prozessoren festgelegt werden, die auch höher liegen kann, als die Anzahl der real auf dem Host verbauten CPU-Kerne, aber sinnvollerweise natürlich darunter liegen sollte. Da unser Host 4 Kerne hat, stellen wir unseren Gast auf 2 Kerne.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Im Reiter "Beschleunigung" aktivieren wir natürlich AMD-V, nachdem wir es zu Anfangs bereits im BIOS aktiviert haben und ggf. Nested Paging.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Wichtig weiterhin die Nutzung des virtuellen CD-Laufwerks. Irgendwie müssen wir auf unserem virtuellen Computer ja noch XP installieren. Dies kann entweder über die Einbindung eines ISO-Images erfolgen, das irgendwo auf dem Host liegt, oder indem das optische Laufwerk des OpenSolaris-Servers an das Gastsystem durchgereicht wird.

    Nun kann nach dem Einlegen der XP Installations-CD (je nach Einstellung entweder via ISO-Image oder via CD im Laufwerk) der virtuelle Computer WinXP gestartet werden. Es meldet sich die XP-Installation, die hier auf Planet 3DNow! vermutlich niemandem mehr erläutert werden muss.

    Nach der Installation legt man einen Benutzer in XP an, den man via Remote-Desktop für die Fernwartung freigibt. So kann man sich später via mstsc direkt auf das virtuelle XP einklinken, und muss sich nicht zuerst via VNC auf OpenSolaris loggen, um dort dann auf der grafischen Oberfläche XP im Fenster zu bedienen.

    Mit der Standard-Einstellung für das Netzwerk der virtuellen Maschine sollte man schon mal ins Internet kommen, sofern das Netzwerk einen DHCP-Server/-Router hat. Allerdings kann die by Default gewählte AMD-Netzwerkkarte nur 100 MBit Fast-Ethernet (dafür out-of-the box) und wegen NAT ist der virtuelle Computer nicht so ohne weiteres aus dem Netzwerk zu erreichen.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Daher wählen wir in den Netzwerk-Optionen der virtuellen Maschine zum einen die Intel Gigabit-Netzwerkkarte 82540EM, für die allerdings ein Treiber von Intel notwendig ist unter XP, den man sich natürlich vorzugsweise im Gastsystem herunterlädt, bevor man die Netzwerkkarte der VM umstellt.

    Außerdem setzen wir die Netzwerkanbindung auf "Netzwerkbrücke" und wählen die verwendete Netzwerkkarte des OpenSolaris-Servers als Brücke. Das versetzt uns in die Lage, vom Netzwerk aus auf das virtuelle XP zugreifen zu können.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Sofern man die Arbeitsgruppe des virtuellen XP entsprechend angepasst hat, sollte nach korrekter Konfiguration in der Netzwerkumgebung sowohl der OpenSolaris-Server, als auch die laufende virtuelle Maschine zu sehen sein (hier vmxp genannt). Damit meldet sich das virtuelle XP im Netzwerk, als würde ein zusätzlicher Rechner hier herumstehen. Vom DHCP-Router erhält das virtuelle XP auch eine eigene IP-Adresse. So lässt sich das virtuelle XP nutzen wie jeder reale XP-Rechner im Netzwerk auch.

    Anleitung: Wir bauen einen AMD Home-Server mit OpenSolaris

    Hier waren wir mal so frei und haben das Distributed Computing Framework BOINC in der virtuellen Maschine installiert. Ob hier BOINC laufen muss, ein Gameserver für das LAN oder irgendeine Datenbank, für die es nur eine Windows-Version gibt, ist völlig irrelevant. Wichtig ist, dass wir damit alles machen könnten wenn wir wollten oder müssten.
    [BREAK=Zusammenfassung]

    Zusammenfassung

    Wie war gleich noch unsere Vorgabe? Möglichst viel bekommen für möglichst wenig Kosten und das mit gerade so viel Aufwand wie nötig? Das haben wir erreicht. Wir können riesigen Datenmengen zu erschwinglichen Preisen abspeichern und dabei auch noch eine gewisse Ausfallsicherheit realisieren ohne dabei in sündhaft teure Server-Hardware investieren zu müssen. Wir können unseren Datenspeicher verschiedenen Usern getrennt oder zusammen freigeben, wir können den Datenpool beinahe beliebig erweitern und wir haben die Möglichkeit neben tumben Daten-Gräbern auch noch weitere Dienste realisieren zu können, wie etwa beliebige Windows-Anwendungen in einer virtuellen Maschine.

    Der Artikel stellt keinerlei Anspruch auf Vollständigkeit für die Realisierung eines Home-Servers. Selbstverständlich führen hier viele Wege nach Rom. Wir haben einen aufgezeigt. Wer lieber bei Windows oder Linux bleibt, kann sicherlich ähnliche Lösungen kreieren ohne vertraute Pfade verlassen zu müssen. Hier muss jeder selbst abwägen, ob ZFS alleine die Auseinandersetzung mit dem unbekannten Exoten Solaris rechtfertigt.

    Wer sich jedoch darauf einlässt und tiefer in die entsprechende Materie Solaris eintauchen möchte, findet dort für die nächsten Monate genügend Lese- und Lernstoff. Für unsere Zwecke jedoch sind tiefgreifendere Kenntnisse gar nicht nötig. Jeder durchschnittlich begabte Windows-User, der sich an unsere Anleitung hält, kann sich mit geringem finanziellen Aufwand eine solche Allround-Maschine für die genannten Zwecke basteln. Für den Einsatz im professionellen Umfeld wären sicherlich weiter reichende Kenntnisse und Maßnahmen nötig. Für den Einsatz zu Hause oder im Freundeskreis jedoch dürfte der hier vorgestellt OpenSolaris-Server in Sachen Daten- und Ausfallsicherheit, sowie Virtualisierbarkeit so ziemlich alles übertreffen, was zu diesem Preis kommerziell feilgeboten wird.

    Abschließend jedoch noch eine eindringliche Warnung: ein Server mit Redundanz ersetzt kein Backup! Entweder man verwendet den Server für das Backup und hat die Originale noch irgendwo auf dem Client herumliegen, oder man nutzt den Server als primären Datenträger; dann sollte man sich jedoch eine zusätzliche Backup-Möglichkeit überlegen, wenn es sich um wichtige Daten handelt. Ob die Terabyte große Filmesammlung zu den wichtigen Daten gehört und nochmal gesichert werden muss, muss jeder User zusammen mit seinem Geldbeutel selbst entscheiden. In jedem Fall ist sie auf einem OpenSolaris-Server mit redundantem Storage-System definitiv weit besser aufgehoben, als völlig ohne doppelten Boden auf externen Festplatten oder dem Desktop-PC.


    Quellen und Ressourcen:

  2. Die folgenden 13 Benutzer sagen Danke zu Nero24. für diesen nützlichen Beitrag:

    Aegir (13.04.2011), anotherone (28.04.2012), Atlan78 (14.04.2011), BLJ (14.04.2011), Bobo_Oberon (15.04.2011), clevemayer (28.02.2011), Crazy-Andy (01.07.2012), Goldie (14.04.2011), mibo (18.04.2011), orpheus2k (14.04.2011), ren (13.04.2011), W0RSCHD (14.04.2011), wintermute_3dc (15.04.2011)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  
Single Sign On provided by vBSSO