• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Wo server Betriebssystem Installieren

Amar6418

New Member
Hallo zusammen,
Ich will einen server aufsetzen.
Mich würde es Interessieren wo man das Betriebssystem installieren sollte zbsp. Debian. Sollte man es auf die ganzen Festplatten des Servers installieren oder auf nur eine einzige Festplatte im server oder sollte man lieber das Betriebssystem von Extern booten lassen.
 
Wenn mehrere Festplatten im Server sind, dann sollte man auf jeden Fall ein RAID-Level mit Redundanz anlegen/verwenden.

Was meinst du mit "von Extern booten"? Meinst du damit so was wie PXE?
 
Wenn mehrere Festplatten im Server sind, dann sollte man auf jeden Fall ein RAID-Level mit Redundanz anlegen/verwenden.

Was meinst du mit "von Extern booten"? Meinst du damit so was wie PXE?
Vielen Dank für deine Antwort, ja genau PXE.
 
Da Du keinen konkreten Anwendungsfall beschreibst, antworte ich auch mal mit meiner Methodik, die ich da grundsätzlich auf meine LINUX-Systeme anwende.

Für einen Server würde ich im Normalfall kein PXE-Boot verwenden, da ich das als Steigerung der Komplexität sehe, d. h. das kann also mehr Probleme verursachen. Es mag Anwendungsfälle geben, wo das sinnvoll ist.

Desweiteren sehe ich das, was mr_brain geschrieben hat auch so: Grundsätzlich möchte ich in einem Server mindestens eine Festplattenausfalltoleranz von 1 haben - womit ich sagen will, dass ein Server den Ausfall einer beliebigen Festplatte/SSD ohne Datenverlust verkraften können soll. Ganz einfach aus dem Grund, dass der Austausch einer defekten Festplatte üblicherweise deutlich einfacher ist, als wenn der Speicher aus dem Backup wiederhergestellt werden muss. Letzteres zieht auch eine Downtime nach sich, die ich gerne vermeiden möchte.

Da die Ausfalltoleranz von 1 physikalischen Festplatte recht gering ist, setze ich dabei zusätzlich auf kontinuierliches Monitoring, dass Probleme mit Festplatten zeitnah erkannt werden, sowie weiterhin auf regelmässige - z. B. monatliche - Datenprüfungen der Festplatten, so dass Datenfehler entweder automatisch korrigiert werden können oder aber zumindest auffallen. Schließlich sollen durch diese Datenprüfungen defekte Festplatten vollumfänglich gelesen werden und falls sich hier HW-Fehler anbahnen, soll dies dadurch erkannt werden.

Wenn ein HW-RAID-Controller im System ist, ist eine sinnvolle Möglichkeit, dass Storage als ein oder mehrere gesamte Arrays zu definieren, welche man dann nach den eigenen Bedürfnissen noch partitionieren kann. Dabei kann man die RAID-Level gemäß den eigenen Performance-/Speicher-/Redundanzanforderungen wählen.

HW-RAID-Controller nehme ich aktuell eher nicht mehr, sondern nutze dafür zwei kleine, preisgünstige SSDs im Software-RAID1 für das Server-OS und dann zusätzliche Platten für die Daten, die ich dann bevorzugt mittels ZFS betreibe. Wenn der Server insgesamt nur 2 Platten hat, dann natürlich keine 2x SSD zusätzlich. btrfs wäre auch noch eine Möglichkeit, welche ich nicht verwende, da mir die Einfachheit in der Anwendung von ZFS mehr zusagt. Ansonsten kosten HW-RAID-Controller auch zusätzlich Geld, auch dafür, dass man ggf. einen Ersatz-RAID-Controller für einen evtl. Schaden der aktiven Karte vorhalten muss. Alternative zu ZFS(Redundanz, Kompression, Verschlüsselung, Dateisystem, Volume Manager) wäre für mich noch Software-RAID(Redundanz-Schicht) in Verbindung mit LVM(Volume Manager) und Ext4(Dateisystem), weil das flexibler als ZFS ist.

Die Flexibilität hat btrfs wohl auch - aber da habe ich sowohl nicht die Kenntnisse sowie Kompetenz über die Verwendung, als auch derzeit nicht das Interesse, mich da umfassend einzuarbeiten. btrfs scheint mir da für eine normale Nutzung deutlich mehr Kompetenz und Einarbeitungsaufwand zu benötigen, wenn man nicht irgendwann mit Datenverlust dastehen will - zumindest bei komplexeren Setups wie RAID,... Ich würde btrfs ansonsten so einschätzen, dass es wesentlich performanter und flexibler ist als alle anderen Dateisystem und dabei im Vergleich zu ZFS einen deutlich geringeren Resourcenbedarf hat.

Der Grund für das Root-Software-RAID1 ist zum einen die Tatsache, dass ZFS als Root-Dateisystem nur mit erheblichem Zusatzaufwand realisierbar ist und zum anderen scheint mir da die Kompletttrennung zwischen OS und Daten in der Vergangenheit die Administration schon sehr erleichtert zu haben.

Nachtrag

Ich habe auch schon Systeme mit HW-RAID-Controllern mit Redundanz gesehen, die einfach nicht überwacht wurden und auch keine regelmässigen Datenchecks erfahren haben. Das Problem dabei war dann, dass dann mehrere Platten bis dato unerkannte Datenfehler hatten, d. h. gewisse Datenblöcke waren nicht mehr lesbar. Das Problem mit eigentlich allen HW-RAID-Controllern - die ich selbst kenne ist - ist, dass bei einem Austausch die Platte offline genommen wird und dann die andere Platte anschließend integriert wird. Hat eine der verbleibenden Platten dann noch Datenfehler, die genau dann auftreten, hat man einen - nicht unbedingt immer einfach zu beurteilenden - Datenverlust. Alles wohlgemerkt bei einer nur einfachen Redundanz.

Im Gegensatz dazu ist es bei ZFS so, dass man für einen Austausch üblicherweise einen zfs replace nutzt. Dabei bleibt die auszutauschende Platte so lange im Verbund, bis die Datenmigration abgeschlossen ist. Treten hier Datenfehler auf, können die Daten noch zusätzlich von der in Entfernung befindlichen Platte gelesen werden. (Können das modernere HW-RAID-Controller auch? Kann das Linux-SW-RAID auch?) Dazu braucht's natürlich auch in der Serverbox noch einen zusätzlichen freien HDD/SDD-Slot.
 
Last edited:
Back
Top