Moin Moin!
Der Witz an einem richtig edlen Server ist eben, dass der eben nur sehr selten ohne Vorwarnung ausfällt. [...] Der Haken ist, dass viel Redundanz nicht nur sehr viel Energie kostet, sondern auch in der Anschaffung alles andere als billig ist.
Genau. [...] Ein kleiner Server hat zwar den Nachteil, dass bei einem Ausfall alles lahm liegt, aber das wäre sogar in der kleinen Firma gut zu verkraften. (Also so klein ist die Firma :-) )
Die Frage ist also, wie lang darf die Downtime sein, im Worst Case, wenn alle unbedingt arbeiten wollen und sich vor der EDV ein wütender Mob von Kunden und Kollegen mit brennenden Fackeln und Mistgabeln sammelt?
Könntest du mir eine kleine Konfiguration eigentlich empfehlen. Ob ich nun einen oder doch zwei Server aufbaue, bin ich mir noch nicht ganz sicher.
Ich hab in einem mittlerweile leider eingegangenen Startup mit in der Spitze fünf Leuten einen einzelnen Server aus einem stinknormalen Billig-PC gebaut, den ich ohne OS von einem Restposten-Händler gekauft hatte (ich denke, das war Pollin). Das war irgendein Intel Dual Core mit unter 2 GHz. RAM hab ich auf 2 GByte aufgerüstet, die vorhandene Platte in einen noch ärmer ausgestatteten Arbeits-PC umgetopft und durch zwei 250 GByte-SATA-Platten ersetzt. Dazu eine 320 GByte USB-Platte für das Backup. VMware lief darauf, allerdings nur für Test-Maschinen, nicht für permanent genutzte Server.
Den Ansatz würde ich bei knappen Budget nochmal fahren:
Ein oder zwei identische Kisten, so viel RAM rein wie Mainboard und Budget erlauben (minimal 8 GByte, eher 16 oder 32), und ganz normale SATA-Festplatten im Software-RAID.
Grafikkarte muß nicht sein, die Chipsatz-Grafik reicht vollkommen. Boards ohne Chipsatz-Grafik (bzw. bei Intel CPUs, die die Chipsatz-Grafik nicht erlauben) kann man mit der billigsten, schlappsten, ältesten VGA aufrüsten, die sich finden läßt. Die VGA braucht man schließlich nur, um das Betriebssystem zu installieren und um im Fehlerfall reparieren zu können, und da reicht für echte Betriebssysteme der Textmodus vollkommen aus.
AMD oder Intel ist eher eine Glaubensfrage, AMD ist bei seinen CPUs und Chipsätzen (noch) etwas großzügiger mit Features, die der Virtualisierungssoftware gut bekommen, bei Intel muß man in der Regel dafür extra zahlen. Die CPU sollte zwingend 64Bit-Betriebssysteme fahren können, und ein solches würde ich auch installieren, allein schon, um den Arbeitsspeicher ohne Klimmzüge ansprechen zu können und um 64-Bit-Betriebssysteme in den VMs haben zu können.
CPU-Takt sollte irgendwo zwischen 2 und 3 GHz liegen, darunter ist zu langsam, darüber wird das System schnell zu heiß. TDP (Thermal Design Power) der CPU sollte möglichst unter 100W liegen, aus dem selben Grund.
Minimal zwei CPU-Kerne, bei vielen VMs eher vier.
Zwischen den Platten nach Möglichkeit je einen freien Platz lassen, damit die ihre Abwärme besser los werden. Möglichst auch noch einen großen Extra-Lüfter vorne im Gehäuse spendieren, der den Platten permament kühle Frischluft zufächelt.
Maus und Tastatur über USB an den beiden Front-Anschlüssen, nur bei Bedarf. Alternativ teilen sich beide Server einen Konsolensatz (Monitor, Tastatur, Maus) über einen elektronischen KVM-Switch.
Ein optisches Laufwerk muß nicht zwingend sein, Brennfunktion schon gar nicht. Wenn ein einfaches DVD-Laufwerk schon in der Grundausstattung nicht abwählbar drin ist, gut. Wenn nicht, nimmst Du ein USB-DVD-Laufwerk oder stöpselst für die Installation ein lose herumfliegendes, ausgeliehenes Laufwerk per IDE oder SATA an.
Gigabit-LAN. Optimal 2x, einmal Büro-LAN, einmal isoliertes Backup-LAN.
Alternative zum Backup-NAS: e-SATA-Port, e-SATA-Gehäuse mit großer Platte.
(Es kommen eben, wie wir bereits geschrieben haben, so Sachen wie Groupware (vermutlich group-e), DMS, Fileserver, OpenVPN (Zugriff von außen), netzwerkfähige kleine Buchhaltungssoftware, SVN für Entwicklungen drauf.
Ich würde mir dann einen oder zwei kleine Server in Einzelteile zusammenkaufen. (5GB für Dokumente und Dateien sind vorhanden, also eigentlich auch nicht die Welt). zzgl. Videotutorials (die dann einen Haufen schlucken. Etwa 100GB.)
Du vergißt die VMs. Auf "meinem" Entwicklungsserver liegen 10 VMs mit Win2K / WinXP, ein SVN-Repository und etwas Kleinkram, damit ist die Datenplatte mit über 200 GByte gefüllt.
Und Du vergißt das Wachstum der Daten. SVN wächst mit jedem Arbeitsschritt, ebenso die Mail-Verzeichnisse und die Fileserver-Freigaben.
Bei den aktuellen Plattenpreisen würde ich gnadenlos die größten Platten kaufen, die ohne Theater an jedem halbwegs aktuellen Mainboard und mit jedem OS laufen: 2 TByte SATA. Über 2 TByte gibt es mit Partitionsgrößen, Sektorgrößen, BIOS-, Controller-, Treiber- und OS-Limits viel Ärger, den man am besten noch zwei Jahre aussitzt.
Davon zwei Stück als RAID-1 bringt so ca. 1,9 TByte nutzbare Kapazität, wenn Du das OS auch auf das RAID packst. Drei Stück in einem RAID-5 entsprechend 3,9 TByte, vier 5,9 TByte.
RAID-1 unter Linux ist völlig schmerzfrei, für das RAID-5 brauchst Du zwingend auch noch eine separate Boot-Partiton, die maximal RAID-1 sein darf: Ich nutze in meinem Heimserver 4x 1 TByte, mit je vier Partitionen (Boot, System, Swap, Daten). Die vier Boot-Partition bilden ein kleines RAID-1 (ca. 100 MByte netto), so dass ich von jeder einzelnen Platte booten kann. Die vier System-Partitionen bilden ein RAID-5 (ca. 50 GByte netto). Die Swap-Partitionen sind mehr pro Forma vorhanden, Linux verwaltet die selbst (kein RAID, je ca. 500 MByte). Und die restlichen vier Daten-Partitionen bilden ein großes RAID-5 mit ca. 2,7 TByte Netto-Kapazität.
Ob ich gleich auch einen USV nehmen sollte, weiß ich nicht. Stromausfall gab es bisher eigentlich nie, aber man weiß ja auch nie :-)
Auch da wieder die Frage: Wie lange darf ein Ausfall dauern?
Ext3 und NTFS sind relativ robust, was Stromausfälle angeht. Aber das Journal Recovery nach einem Stromausfall dauert auf einem TByte-RAID eine Weile, der fsck erst recht.
Eine USV macht übrigens noch mehr als nur dem Computer eine Chance zu geben, bei Netzausfall sauber herunterzufahren. Sie schützt (in gewissen Grenzen) auch vor Über- und Unterspannung, die durchaus auch mal für Störungen sorgen können.
Achte bei der USV darauf, dass sie eine Leitung (RS232, USB) zum geschützen PC hat, damit sie einen Stromausfall auch signalisieren kann. Nach einem Stromausfall zieht eine USV übrigens SEHR VIEL Strom, damit der Akku schnell wieder aufgeladen ist. Mehrere USVs parallel an eine Sicherung zu hängen ist daher eine extrem dämliche Idee.
Privat habe ich mal mit einer alten USV gearbeitet, die hat dank schlapper Akkus mehr Ausfälle verursacht als verhindert. Also hoffe ich wieder auf guten Strom und robuste Dateisysteme, wie schon die Jahre davor.
Im Betrieb gibt es eine zentrale USV und einen Notstrom-Diesel, da muß ich mir über Stromausfälle keine Sorgen machen.
Ach ja, Signalisierung. Jede USV macht's anders, inkompatibel zu allen anderen USVs, und gerade bei USB-Anschluß ohne Spezialtreiber des Herstellers nicht zu gebrauchen. Auf der sogenannten RS232-Schnittstelle der USV ist meistens ein Schaltkontakt, mit dem man unabhängig von Betriebssystem und Treibern dem PC über dessen RS232-Schnittstelle wenigstens "gleich wird's dunkel" signalisieren kann. Für Linux scheint der schmerzfreieste Weg wohl eine USV von APC mit RS232-Schnittstelle und passendem Kabel zu sein.
Meine Überlegung liegt derzeit darin, ob ich einen leistungsstärkeren Rechner nehmen sollte oder doch einen stromsparenden Atom-Prozesseor oder so. Das wäre aber denke ich, dann doch etwas schwach.
Als Server ist ein Atom definitiv zu langsam, wenn der Server mehr als nur kleiner File- ODER Mailserver sein soll. An reinen Büro-Arbeitsplätzen kann ein Atom genügen. Entwicklern gibt man besser flotte Kisten, siehe alte Postings.
Falls nicht vorhanden, leih Dir mal ein Netbook mit Atom aus und arbeite damit ernsthaft (d.h. mit externer Tastatur, externer Maus, externem Monitor, Strom aus der Steckdose, Energiespar-Optionen abgeschaltet) einen Tag lang. Dann kannst Du beurteilen, ob das für Arbeitsplätze reicht.
Ob Wake-On-Lan interessant wäre, muss ich mir noch überlegen, ob man den Server auch oft mal ausschaltet. (Wobei man dann nicht mehr auf Emails zugreiffen könnte, ohne den Rechner extra hochfahren zu lassen)
WoL ist für die Fernwartung von Arbeitsplätzen, nicht für Server. Einen Server schaltet man nach dem Kauf ein und nach der Inbetriebnahme des Nachfolgers wieder aus.
Die Problematik ist mir wieder eingefallen, da wie bereits erwähnt, mein größtes Problem eher die Findung einer geeigneten DMS Software ist.
Sobald die DMS Software installiert ist, kann man ja Dateien (meißt über Webbrowser) rein- oder herunterladen. (Für manche Dateieformate gibt es ja wie bereits erwähnt auch Schnittstellen, bsp. Office / Openoffice um Dateien direkt in die DMS zu speichern usw)
Das große Problem ist aber, wenn es Dateien wie zum Beispiel ein Diagramm in XMIND oder sonstiges Programm ist. Ich lade die Datei herunter und zwischenspeichere es zum Beispiel auf meinem Laptop. Ändere die Datei und lade es wieder hoch. Dieser Workflow ist natürlich etwas umständlich.
Anders geht es aber kaum. Man könnte ein FUSE-Dateisystem darüber legen, oder eine Shell-Extension bzw. ein Plugin, das bei jedem Speichervorgang automatisch ein Checkin macht, aber das macht es nicht hübscher und müllt das DMS noch schneller voll.
Aber was ich eigentlich schlimmer finde. Wenn die DMS versioniert, heißt es, dass er dann sicherlich die komplette Datei als neue Version abspeichert. (Es ist ja nicht wie SVN, um aus normalen lesbaren Dateien nur die Änderungen zu speichern)
Hmm, das kommt auf das DMS an. Vermutlich speichern die meisten DMS tatsächlich vollständige Kopien. Man könnte natürlich auf SVN ein DMS draufbasteln ...
Aber hey, Plattenplatz ist billig! Mein Haus- und Hoflieferant nimmt aktuell für die billigste 2 TByte-Platte noch nicht einmal 70 Euro. Vier davon in einem RAID-5 bringen Dir 6 TByte mit Schutz gegen Ausfall einer Platte für deutlich unter 300 Euro. Und bis Du die mit XMind vollgestopft hast, bist Du vermutlich längst in Rente.
(Auf die schnelle denke ich mir, dass dieses Problem eigentlich damit gelöst werden könnte, dass die Dateien nicht intern in einer DMS liegen, sondern lesbar auf einer Platte bzw. Fileserver, wo die DMS dann praktisch ein Layer auf die Dateien mit all seinen Metadaten legen kann. D.h., jedes andere Programm könnte (ohne rein- und herunterladen zu müssen), direkt auf die Dateien zugreifen. Dann kommt jedoch das Problem, dass man an der DMS Software vorbei sicherlich viel mist bauen kann, bsp. Dateien umbenennen, verschieben usw.) Also irgendwie keine gescheite Lösung.
Nein, das vergiß bitte wieder ganz schnell. Das DMS ist eine geschlossene Kiste mit einer definierten Schnittstelle zu den Benutzern, an der man sich auf gar keinen Fall vorbeimogelt. Wenn Du in der internen Ablage des DMS herumfummelst, sind riesige Inkonsistenzen garantiert.
Wenn Du Fileserver-artige Zugriff auf die Dateien haben willst, brauchst Du eine Schnittstelle zwischen DMS und Shell/Desktop (FUSE / Shell-Plugin) oder zwischen DMS und Andwendungen (Office-Plugin).
Irgendwie überlege ich mir gerade jedoch, ob ich die Frage bzwl. der Serveraustattung von mir sinnvoll ist.
Ist sie.
Vielleicht sollte ich einen zusammenstellen und fragen, ob die Konfiguration, bzw. Einzelteile so okey sind.
Ganz ehrlich: Auf Details kommt es kaum noch an, wenn Du Standard-Hardware benutzt. Kleiner Laden, relativ lange Ausfallzeiten akzeptabel, da brauchst Du nichts besonderes. Siehe oben. Vielleicht ein Rackmount-Gehäuse statt der normalen Tower. Und darin vielleicht noch Wechselrahmen für die Platten.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".