slsHyde
Commander
- Registriert
- Dez. 2014
- Beiträge
- 2.232
Inhaltsverzeichnis
1. Prolog
2. Ausgangslage
3. erste Maßnahmen
4. Konzeptioneller Lösungsansatz
5. Einkaufslisten
6. Umzugsszenario
7. Ressourcenzuteilung
8. Worklogs, Burn-Ins und Tests
9. Die kleine Firma
10. Andere Beispiele in Kürze
1) Prolog
Der Thread wird unvollständig begonnen und parallel zum Fortschritt weiter entwickelt. Enthalten ist bisher die Ausgangslage, die Planung sowie der bereits umgesetzte Teil der Planung. Im Weiteren folgt dann der Rest der Umsetzung. Die noch fehlenden Teile sind im Inhaltsverzeichnis grau dargestellt. Fotos und Screenshots werden gleichsam noch nachgelegt.
In Summe stehen hier 6 Server in 2 Unternehmen zum Wechsel an.
Das Thema Sever im Eigenbau vs. fertige Server ist strittig. Die Entscheidung ist hier zugunsten des Eigenbaus gefallen. Fertigserver werden hier derzeit verwendet und sollen im Rahmen einer nötigen Erneuerung durch Eigenbauserver ersetzt werden. Dieses Thema ist damit abgehandelt und off-Topic (siehe hierzu 4.i). Das Konzept kann auch mit fertig gekauften Servern umgesetzt werden, fände man welche, die geeignet sind. Das scheitert aber schnell zum Beispiel an der Lautstärke und Erweiterbarkeit.
Die hier vorliegende Situation ist klassisch und eignet sich daher sehr gut als Fallstudie.
Es soll anhand eines Praxisbeispiels veranschaulicht werden, wie man selber oder in Kooperation mit einem Systemhaus vorgehen kann und wie diverse Problemstellungen abgedeckt werden können. Ich denke, auch Systemhäuser können hier Ansätze für ihre kleinen und mittleren Kunden entnehmen. Das Konzept wurde bereits in anderen Zusammenhängen und verschiedenen Variationen erfolgreich praktiziert.
Konstruktive Kritik, Beiträge und Fragen hierzu sind willkommen. Für Fragen und Unterstützungen zu eigenen Projekten hingegen bitte im passenden Fachforum einen eigenen Thread eröffnen und ggf. mich per PN darauf aufmerksam machen.
Einkaufslisten, Worklogs sowie Burn-ins begleitet von diversen Tests soll auch enthalten sein. Ggf. wird dies auch weitergeführt, um hier Erfahrungen, sofern diese hardware- oder konzeptbezogen sind, verfügbar zu machen, quasi als Langzeitstudie.
2) Ausgangslage
Es handelt sich um ein Unternehmen mit 11 Arbeitsplätzen, wobei ich die Nummer 11 bin. Es liegt damit bei zwei internen Personen IT-Erfahrung vor. Zusätzliche Begleitung durch 2 externe Systemhäuser ist gegeben. Im Hintergrund gibt es ein zweites Unternehmen, welches einem der Gesellschafter (dem mit IT-Kenntnissen) alleine gehört und 4+1 Arbeitsplätze beinhaltet.
Die Arbeitsplätze sind klassische vielseitige Office-Umgebungen im Servicebereich mit datenbankbasierten System wie Warenwirtschaft, Produktionsplanungssystem, Abrechnungssystemen sowie Buchhaltungssystem.
Zustand der IT ist/war bedenklich und überarbeitenswert aber dennoch überdurchschnittlich gut.
Es wird mit Remote Desktops und ThinClients gearbeitet (= RDS oder altsprech Terminalserver). Sehr gut. Idealvoraussetzungen für ortsunabhängiges Arbeiten, insbesondere zusammen mit VPN, sowie sehr geringer Wartungsaufwand, besonders, da die verschiedenen Datenbanksysteme häufige Updates mit sich bringen, die dann nicht mehr auf allen Clients durchgeführt werden müssen.
Ein Expansionskurs besteht nicht. Dieser Bestand aber auch zuvor nicht und es wurden dennoch über die Jahre 11 Arbeitsplätze. Es gibt also eine gewisse Eigendynamik. Potentiell stehen irgendwann neue Auszubildende/Mitarbeiter an, da Gesellschafter und Mitarbeiter älter werden. Das Ergebnis geringer Fluktuation wegen hoher Mitarbeiterzufriedenheit. Es käme dann mindestens temporär zu weiteren Arbeitsplätzen für diverse Jahre. Die Eigendynamik lässt aber vermuten, dass dies nicht zwingend komplett temporär bliebe.
Im Rahmen der Workflows digitalisiert sich die Arbeit immer weiter. Hierbei kommen zum Beispiel beim Wareneingang, der Buchhaltung und in anderen Zusammenhängen mehr und mehr digitalisierte Belege mit Schrifterkennung zum Einsatz. Aus Gründen der Anonymisierung möchte ich dies beispielhaft lediglich an der Buchhaltung genauer erläutern, da Buchhaltung nun mal allgemein ist.
In der Buchhaltung bedeutet dies, dass die Belege als PDF an jedem Buchungssatz angehängt werden. In diesem Zusammenhang werden die Belege auch mit Schrifterkennung durchforstet und interpretiert. Hieraus werden automatisierte Buchungsvorschläge generiert, was die Erfassung vereinfacht. Diese Systematik kann weiter trainiert werden. Das Finanzamt hat angekündigt, dies bis zum Jahr 2020 verbindlich zu machen.
Mit dem Einlesen der Dokumente geht aber eine starke Leistungsbeanspruchung einher – bei CPU und natürlich dem Festplattensystem. Dieser Prozess dauert derzeit mit einem Xeon DP E5504 (4x2GHz ohne HT und Turbo) an Seagate 15.000rpm SAS im RAID1 für einen durchschnittlichen Arbeitsdurchgang ca. 15 Minuten. CPU-Auslastung sinkt dabei schnell auf 50% (alle Kerne gleichmäßig), mehr Arbeitsspeicher wird kaum abgerufen. Das Festplattensystem ist also zu langsam, die Anwendung skaliert mit Kernen. Das Warten auf Abschluss des Einlesevorganges ist teils ungünstig, aber noch kein wirkliches Problem, da bisher nur wenige Vorgänge auf digitale Belegerfassung umgestellt wurden. Dies wird aber weiter zunehmen.
Aus den Angaben lässt sich das Verhältnis von benötigter Laufwerksleistung zu CPU-Leistung ableiten, so dass zukünftig kein Flaschenhals mehr besteht.
Im Weiteren ist zu erkennen, dass die digitale Belegführung Bedarf an Scannern, vor allem aber an zusätzlichen Bildschirmflächen schafft.
Die bisherigen Leistungsanforderungen sind ansonsten sehr gering. Obiger Xeon DP E5504 (Datenbankserver) sowie ein Xeon UP X3470 (Terminalserver) langweilen sich entweder oder zeigen kürzere Lastphasen im Bereich von 30% bis 50%. Der 1-kernige Pentium im Domänenserver hingegen ist überlastet. Da jetzt quasi Bildverarbeitung Einzug hält, ist eine massive Zunahme der Anforderungen binnen der kommenden 5 Jahre anzunehmen. Ggf. ergänzt durch weitere Arbeitsplätze. Aber: weiß man’s? Und wie hoch ist das anzusetzen? Wie kann ich eine große Leistungsspanne realisieren, ohne, sollte sich die Annahme nicht bestätigen, überdimensioniert zu haben und ohne dass es teuer wird?
Das derzeitige Gesamtvolumen der drei Produktivserver liegt nach unten beschriebenen ersten Maßnahmen bei 320 GB. Die drei Produktivserver belegen im Betrieb zusammen ca. 22GB RAM, es stehen 40GB zur Verfügung.
Vorgefunden habe ich hier 4 Windows Server 2008 R2: Domänenserver (inkl. DHCP-, DNS-, Exchange- und Dateiserver), Datenbankserver, Terminalserver sowie Sicherungsserver (letztlich ein NAS).
Es gab mannigfaltige Störungen, deren Zuordnung zu einem konkreten Grund schwierig war. Dies resultiert daraus, dass das System nicht konzeptionell entworfen sondern entlang akutem Bedarf historisch gewachsen ist.
Auffällig waren Störungszusammenhänge mit der Linux-basierten ThinClient Anbindung, besonders im Zusammenhang mit Maßnahmen, die der Schaffung zusätzlicher Bildschirmfläche dienten. Verschwindende Mauszeiger oder massives Endlosruckeln beim Scrollen zum Beispiel. Mit der Linux-basierten Anbindung der ThinClients entsteht ein heterogenes Netzwerk, was immer zusätzliche Störungsquellen mit sich bringt. Ein rein homogenes Netzwerk (durchgängig das gleiche System) ist deutlich wartungsärmer und im Ergebnis billiger, selbst wenn man hier zum Beispiel Windows als Software für die ThinClients einsetzen würde.
Im Weiteren Störungen, die trotz gleicher Basis der Nutzer (RDS-Server – alle arbeiten ja mit demselben Rechner) sich von Nutzer zu Nutzer unterschieden. Programmabstürze zum Beispiel, besonders bei Internetnutzung. Dies weist auf die Benutzerprofile hin.
Mit den Telefonen (VoIP) gab es auch Störungen (Störgeräusche, zu leise, Abbrüche, Schaltungsfehler – teils wurden Verbindungen reproduzierbar nicht hergestellt). Es kommen DECT- sowie kabelgebundene Geräte zum Einsatz.
Das Netzwerk scheint auch Störungsbilder beizutragen. Die verschiedenen Störungsbilder überlagern sich teilweise auch. Die Ausdifferenzierung war daher schwierig.
Die bestehenden Server sind zu laut (und zu viele). Trotz separatem Serverraum. Der Eingangsbereich sowie ein Arbeitsplatz sind akustisch verseucht. Ich sitze gerade mit Abstand Eingangsbereich, einem Büro und dann der Raum, in dem ich ganz am anderen Ende sitze, zusammen 19 Meter entfernt, und kann die Biester klar und deutlich hören. Allerdings ist es gerade außerhalb der Bürozeit, also sehr leise Umgebung – während der Bürozeit muss ich an diesem Platz hinhören, um die Server wahrzunehmen. Im Eingangsbereich und dem ersten Büroraum hingegen sind die Server deutlich wahrnehmbar, schwer zu überhören.
Die Temperaturen der Server waren deutlich zu hoch. Die 4 Server plus der Telefonserver mit einigen Kleingeräten produzieren so viel Abwärme, dass die Tür zum Serverraum offen bleiben muss. Um einen gewissen physikalischen Schutz zu gewährleisten, wurde ein Serverschrank eingesetzt. In dem staut sich aber gleichsam die Abwärme. Außerdem sind die eingebauten Komponenten schwer zugänglich.
Für keinen der Server bestand noch Hardwareverfügbarkeit. Es gab ursprünglich die klassischen 24/7 Austauschverträge, aber jeweils nur für drei Jahre, die selbst beim neuesten Server lange schon vorbei sind. Also alte Hardware, die über den gesamten Betriebszeitraum auch noch zu heiß betrieben wurde. Nicht unerwartet sind dann hier auch 3 Festplatten in kurzer Zeit ausgefallen. Fiele aber mehr als nur Festplatten aus, entstünde die Situation, dass man sich erst mal Gedanken über Ersatzbeschaffung machen müsste und dabei feststellen würde, dass passende Ersatzhardware teilweise gar nicht oder nur mit langen Lieferzeiten beschaffbar wäre.
Datensicherungen (Windows Serversicherung) dauerten viel zu lange und waren daher auch störanfällig. Im weiteren gingen damit deutliche Ressourcennutzungen einher.
3) Erste Maßnahmen
Die erste Maßnahme bestand natürlich darin, die Situation zu analysieren und ein Konzept auszuarbeiten. In diesem definierten Rahmen fanden dann folgende Maßnahmen bereits statt:
Vor und hinter den Serverschrank je einen großen Ventilator postiert (push-pull). Temperaturen damit wieder im grünen Bereich.
Systembereinigung (Frühjahrsputz). Servergespeicherte Benutzerprofile abgeschaltet, da diese in einer RDS-Umgebung meist überflüssig bis kontraproduktiv sind. Ordnerumleitung per Gruppenrichtlinie für Benutzerordner aktiviert, was bei servergespeicherten Benutzerprofilen sehr vorteilhaft ist aber viel zu oft nicht gemacht wird. Aber auch ohne servergespeicherte Benutzerprofile immer noch die Administration und Störungsbeseitigung vereinfacht und ein klarer gegliedertes System ergibt. Die Benutzerprofile erneuert (bzw. der Registryteil derselben, der Rest ist ja umgeleitet ins jeweilige Basisverzeichnis). Die Konfiguration der linuxbasierten ThinClients erneuert. Nicht (mehr) benötigte Software deinstalliert. Benötigte Software teils neu installiert, teils bereinigt. Einzelne Bestandteile der dateibasierten Einstellungen in den Benutzerprofilen (AppData) erneuert. Alle Updates geprüft und im Zweifel neu installiert. Zündkerzen poliert, Scheiben wischen, fertig ;-)
Das System läuft seit dem weitgehend störungsfrei und unnötige Systemlast ist deaktiviert. Detailarbeit (Konsolidierung) steht noch aus.
Die Virtualisierung der Server wurde erfolgreich geprobt.
Zur Datensicherung wurde hier jetzt Acronis (Universal License) eingekauft und vorläufig auf einem der Produktivserver installiert. Bisher wurde und wird die windowseigene Serversicherung verwendet. Dies bleibt wahrscheinlich in der kleinen Firma auch weiterhin, da Acronis dort unverhältnismäßig teuer scheint. Dies muss aber noch mal geprüft werden.
Obige Änderungen haben die Netzwerklast um 60GB pro Tag reduziert. Festplattenlast um 120GB, jeweils hälftig Schreib- und Leselast, davon 30GB Schreiblast auf SSDs (Intel 320 Series), weshalb deren Lebensdauer (15TBW) so weit beschränkt wurde, dass diese nun ausgetauscht werden müssen.
Die Software der Telefone wurde aktualisiert. Einige Störungsbilder sind damit verschwunden. Ein Update der Software der Telefonanlage kommt in Kürze. Die bisher bereits realisierte Entlastung des Netzwerkes scheint gleichsam einen positiven Effekt zu haben. Seit dem entstehen Störungen vorrangig noch während der Datensicherungen, was sich bald ja erledigt. Ansonsten nur vereinzelt bei den Funktelefonen und gehäuft an einem einzelnen Arbeitsplatz an einem Funktelefon (DECT), der offenbar funkverseucht ist. Quelle aber nicht identifizierbar. Kreuztest durch Austausch der Endgeräte ohne Erfolg – mit dem anderen Endgerät blieb die Störung bestehen, während das ursprüngliche Endgerät am anderen Platz plötzlich störungsfrei arbeitete. WLAN und alle anderen potentiellen Störquellen deaktiviert – ohne Besserung. Lösung ausstehend.
Der Sicherungsserver wurde vorgezogen. Hiermit wurde quasi auch wieder Hardwareverfügbarkeit hergestellt - bzw. ein Notfallszenario. Mehr dazu im Kapitel „Der Sicherungsserver“
4) Konzeptioneller Lösungsansatz
Grundsätzlich: keep it simple!
4.i) Allgemeines
Es gibt zahlreiche sogenannte Best Practice Empfehlungen sowie zahlreiche vermeintlich zwingende Dinge, die man tun soll oder lassen soll.
Tatsache ist aber, dass es keine allgemeingültigen Empfehlungen gibt. Denn jede Empfehlung steht immer unter dem Vorbehalt, ob sie denn tatsächlich im jeweiligen Szenario Sinn ergibt. Es spielt auch keine Rolle, welcher (möchtegern-) IT-Guru die Empfehlung ausgesprochen hat. Denn im Zweifel wird nicht dieser Guru, sondern der zuständige IT-Betreuer zur Verantwortung gezogen. Der Verweis auf einen IT-Guru hilft dann nicht weiter.
Das gilt natürlich auch für alle meine Empfehlungen und Ansätze. Und tatsächlich habe ich in anderen Situationen auch schon gegenteilige Lösungsansätze zu Hiesigen praktiziert, wobei hiesiger Rahmen meistens passt.
Im Weiteren ist es auch nicht Aufgabe der IT, Bedingungen festzulegen. Dies ist Aufgabe der Geschäftsführung, die bei diesen Vorgabenerstellungen natürlich auf das Fachwissen der IT zurückgreift. Und dann ist das die Bibel - und nicht das, was irgendein IT-Guru vorgibt. Es ist dann auch im Weiteren Aufgabe der Geschäftsführung, das entsprechende Budget dafür zur Verfügung zu stellen.
Die Geschäftsführung muss zum Beispiel definieren, wie lange die Ausfallzeiten welcher Systeme sein dürfen. Ob 24h zum Beispiel tragbar sind oder nicht - sondern binnen 2h wieder verfügbar gemacht werden muss. Auch gilt es zu differenzieren, welche Systeme. So ist es zum Beispiel für Mitarbeiter oft ein schweres Problem, wenn keine eMails mehr versendet oder empfangen werden können. Hingegen ein geringeres Problem, wenn der alte eMailbestand eine Zeit lang nicht verfügbar ist. So wäre also die Mailfunktionalität zum Beispiel binnen einer Stunde, aber der Mailbestand binnen 24h verfügbar zu machen.
Natürlich ist es auch Aufgabe der IT, die Geschäftsführung proaktiv auf Probleme und Risiken hinzuweisen.
Im Weiteren gilt: Je weniger Spezialwissen nötig ist, um das System beherrschen zu können, um so besser! Betriebe in hier gegenständlicher Größenordnung können in große Schwierigkeiten kommen, wenn das Konstrukt zu komplex ist und die eingesetzten Technologien zu viel Spezialwissen erfordern. Um so mehr, wenn dieses Spezialwissen schwer zugänglich ist. Reduce to the max!
Um zu ermitteln, ob eine angedachte Lösung sinnvoll ist, empfehle ich, sich konkrete Szenarien einmal vorzustellen. Zum Beispiel: Was passierte, fiele das Netzteil aus. Was, fiele das Mainboard aus. Was, reichte die CPU-Leistung nicht mehr, etc, etc, etc.
4.ii) Konkretes
Die drei Produktivserver sollen in Virtualisierungen umgewandelt und auf einem einzelnen neuen Server betrieben werden. Weniger Hardware = geringere Ausfallwahrscheinlichkeit und Kosten, Aufteilung auf mehrere virtuelle Server = geringere Komplexität des einzelnen Servers = geringere Ausfall- und Störungswahrscheinlichkeit.
Zum 14.01.2020 stellt Microsoft den Support für Server 2008 R2 ein, also können diese noch maximal 3,5 Jahre weiter laufen. Dann muss auf eine neuere Version migriert werden, da es keine Sicherheitsupdates mehr gibt. Voraussichtlich können dann mit einer Lizenz zwei Server betrieben werden, so dass sich eine Verdichtung auf zwei Virtualisierungen aus Kostengründen abzeichnet. Der Server 2016 R2 dürfte dann für weitere 10 Jahre gut sein. Merke: Lizenzcheck und -Strategie ist wichtig. Die Windows Server 2008 R2 wurden hier in 2012 angeschafft ausgehend von Server 2003, zuvor Server 2000. Das ist dann halt um ein vielfaches teurer - in der Anschaffung sowie der Implementierung.
Der Aufpreis für ein 2011-3 System, das im Bedarfsfall einen zweiten Prozessor aufnehmen kann, entsteht bei Mainboard und Netzteil und beträgt netto 40,- € gegenüber einem Einsockelsystem. Daher kommt ein Zweisockelsystem mit zunächst nur einem Prozessor zum Einsatz und wir verfügen damit über eine massiv erweiterbare Grundlage, Stichwort Skalierbarkeit. Daraus ergibt sich auch das Potential, den Server sehr lange zu betreiben.
Supportverträge für Hardwareverfügbarkeit laufen entweder 3 oder 5 Jahre, länger nicht. Für 5 Jahre kostet das dann bei hiesiger Größenordnung an die 1.500,- €. Dafür wird Verfügbarkeit binnen 24h garantiert.
Dies reicht uns nicht. Wir wollen den Server deutlich länger betreiben, 10 Jahre sind angedacht, gerne mehr. Das ist ökonomischer und ökologischer. 24h Warten im Störungsfall ist ebenso inakzeptabel. Auch führen diese Verträge in kleineren Unternehmen dazu, dass nach Ablauf der Servicezeit die Hardware weiter verwendet wird, da diese noch ausreicht. Lediglich die Verfügbarkeit ist dann nicht mehr gewährleistet, was aber teuer werden kann. Das fällt dann aber erst auf, wenn es zu spät ist. Und das Risiko steigt natürlich mit der Betriebsdauer. Während der Vertragslaufzeit hingegen ist das Risiko sehr gering – also Angebot und Bedarf laufen hier genau gegensätzlich. Das Gleiche gilt für die Verfügbarkeit bzgl. Aufrüstung. Bedenkenswert. Erneuert man aber zum Ende der Vertragslaufzeit, so ist man zeitlich gebunden. Man kann also zum Beispiel keine auf Sweet-Spots angelegte Beschaffungsstrategie fahren.
Obige 1.500.- € sehen wir daher als Budget, den Server quasi ein zweites Mal anzuschaffen und an nicht kritischer Stelle einzusetzen, hier als „ThinClient“. Dies nenne ich ein produktives Ersatzteillager.
Damit haben wir Hardwareverfügbarkeit binnen 0h anstatt 24h - ohne zeitliche Begrenzung auf 3 oder 5 Jahre. Garantie haben wir auch, je nach Bauteil zwischen 3 und 10 Jahren. Wir sparen einen ThinClient (300 €). Gleichzeitig haben wir eine Entwicklungs- und Teststation. Auch können wir im Störungsfall austesten, welche Komponente tatsächlich defekt ist. Alternativ kann direkt der Ersatzserver herangezogen werden (Festplattensystem umbauen, fertig). Auch zum Beispiel Bios- und Treiberupdates können besser auf Verträglichkeit geprüft werden. Wir wissen auch, da wir dies validieren, dass die Hardware in beliebiger Kombination kompatibel ist und durch den Betrieb als Client wissen wir auch, dass die Hardware funktioniert. DOA und Inkompatibilität mit Ersatzhardware im Störungsfall ist ausgeschlossen.
Dies gilt auch, wenn wir irgendwann aufrüsten wollen. Es kann nämlich zum Beispiel sein, dass eine später gekaufte neuere Version der gleichen CPU nicht mit der älteren Revision zusammen läuft, ähnlich wie gleiche RAM-Riegel nicht immer zusammen laufen. Dies ist hier ausgeschlossen, da wir eine passende CPU in der Hinterhand haben. Das produktive Ersatzteillager kann insofern auch im Falle einer Aufrüstung herangezogen werden, so dass die Aufrüstung nichts oder sehr wenig kostet und mit validierten Bauteilen erfolgen kann. Auch bei einem RAID-Array kann es passieren, dass zu dem Zeitpunkt, wo man es erweitern möchte, baugleiche Laufwerke auf dem Markt nicht mehr verfügbar sind. Dann müsste man entweder einen schmutzigen RAID fahren oder alle Laufwerke neu beschaffen.
Zum Beispiel: Nach 8 Jahren wird es CPU-seitig eng, für die verbleibenden 2 Jahre wird die CPU aus dem produktiven Ersatzteillager in den Produktivserver eingebaut. Findet man noch günstig gebraucht einen alten Server mit der gleichen CPU, nur die CPU oder eine kleine CPU, kann man das auch noch machen, um das produktive Ersatzteillager in Betrieb zu halten. Muss man aber nicht. Es sind ja nur noch 2 Jahre und die CPU bleibt ja redundant. Will man aber den Server noch länger betreiben oder wird die CPU früher eingesetzt, spricht umso mehr für Ersatzbeschaffung.
So oder so – es gibt in jeder Situation Optionen und die Folgekosten sind stark minimiert. In jeder Situation kann man ganz entspannt und hoch flexibel agieren und den Betrieb wieder zum laufen bringen oder beschleunigen um dann in der Nacharbeit ohne jeden Zeitdruck die weitere Verfahrensweise festzulegen und umzusetzen.
Die Hardwarebeschaffung kann ebenfalls günstiger erfolgen, da man nicht auf besonderen Service oder Kulanz eines Händlers angewiesen ist. Man kann also sehr gut über Geizhals bei Händlern, die viele positive Bewertungen haben, einkaufen.
Gleichzeitig kann hier das produktive Ersatzteillager auch noch für die andere kleinere Firma zur Verfügung stehen. So etwas könnte man auch durch Kooperationen mit Geschäftsfreunden oder Gebäudenutzern realisieren. Damit entfällt dort sowie in jedem anderen potentiell eingebundenem Unternehmen gleichsam ein entsprechender Vertrag vollständig und die Vorteile gegenüber einem solchen Vertrag kommen dort größtenteils gleichsam zur Geltung.
Allerdings wird hier für die kleinere Firma zunächst aus der vorhandenen Hardware beider Unternehmen mit kleinen Ergänzungen, quasi als Resteverwertung, ein neuer Server gebaut bzw. früher oder später deren Virtualisierungen auf hiesigem Server abgelegt und per VPN zugegriffen. Glücklicherweise wurde teils gleiche Hardware in beiden Unternehmen verwendet, so dass hier ebenfalls ein System gebaut werden kann, bei dem alle maßgeblichen Bauteile noch mal als Ersatz vorliegen. Da die Teile über oder gegen 5 Jahre alt sind, wäre ansonsten ein weiterer Betrieb nicht möglich, da die Verfügbarkeit nicht mehr gegeben wäre. So aber können die Teile noch ein paar weitere Jahre eingesetzt werden, bis das Internet eine ausreichend stabile VPN-Verbindung hergibt.
Zu beachten ist, dass normalerweise das produktive Ersatzteillager nicht als Sicherungsserver für die Daten verwendet werden kann. Denn bei einem Hardwareausfall, bei dem das produktive Ersatzteillager ausgeschlachtet würde, könnte in dieser Situation nicht mehr ohne Weiteres auf die Datensicherung zugegriffen werden. Es bestünde aber genau dann eine erhöhte Wahrscheinlichkeit, dass dies nötig würde. Der Sicherungsserver könnte aber als produktives Ersatzteillager für einen anderen Server dienen, zum Beispiel in einem anderen Unternehmensteil oder hier für die kleine Firma. Bzw. wird er hier früher oder später in den kleinen Betrieb wechseln, die Sicherungen per VPN dorthin geleitet (sind dann gleichzeitig Außerhaussicherungen) und dieser Sicherungsserver so konfiguriert, dass er bei länger anhaltendem Internetausfall die Virtualisierungen der kleinen Firma lokal übernehmen kann und dann temporär als Produktivserver dient.
Vorläufig werden die beiden Unternehmen zur Außerhaussicherung zukünftig gegeneinander gesichert. VPN zwischen den Unternehmen besteht ja bereits.
Oben gezeichnete Lösung bräuchte keinen Serverraum mehr sondern könnte auch in eines der kleinen separierten Büros. Dies machte ein zusätzliches Büro frei, entstünde der Bedarf.
Der Lösungsansatz ergibt im Weiteren eine deutliche Einsparung beim Stromverbrauch. Dies finanziert die neuen Anschaffungen. Absolut gesehen sinkt damit der Stromverbrauch aber derart tief, dass zukünftige potentielle Einsparungen durch höhere Energieeffizienz neuer Technik nicht mehr hoch genug werden können, als dass ein Wechsel wegen Energieeffizienz ökonomisch oder ökologisch Sinn ergäbe. Auch verlangsamt sich nun laut Intel die Weiterentwicklung. Kaufzeitpunkt also Sweet Spot. Broadwell-EP zeigt vor allem im Zusammenhang mit Virtualisierungen deutliche Verbesserungen. Die Leistungssteigerung im Allgemeinen zur Vorgängergeneration erlaubt es auch, eine Leistungsklasse tiefer zu gehen, was nochmals 500,- € spart. Auch hier: Sweet Spot.
Der Einsatz von Acronis (inkrementelle Sicherung sowie Einstellung der Ressourcennutzung) reduziert die Netzwerklast weiter massiv – bisher gibt es Telefonstörungen, wenn die Sicherungen beginnen. Die Sicherungen dauern auch viel zu lange.
Mit oben beschriebener Lösungsansatz besteht im Weiteren die Hoffnung, die Kommunikation der Server untereinander aus dem physikalischen Netzwerk herausnehmen zu können. Mit dem zukünftigen Server kann ggf. auch der Internetverkehr aus dem internen Netzwerk separiert werden. In Summe mit den ersten Maßnahmen und hier dargestellten Vorhaben reduzierte sich die Netzwerklast derart, dass eine sonst nötige Erneuerung des Netzwerkes (1.500 €) nicht mehr nötig wäre. Aktuellere Windows Server beinhalten darüber hinaus neue Funktionen, die geeignet sein können, den Netzwerkverkehr softwareseitig weiter zu optimieren.
Das System soll dann gut dokumentiert werden, um Unabhängigkeit von Personen und Systemhäusern zu befördern. Gut geeignet hierfür ist Microsoft One-Note. Daraus wird dann auch ein Notfallhandbuch gezogen, welches in ausgedruckter Form griffbereit gehalten wird. Die Notfallszenarien werden regelmäßig (möglichst 1x jährlich) getestet.
Mit oben beschriebenem Konzept könnte man jetzt behaupten, man solle doch dann direkt einen Failovercluster betreiben. Davon rate ich dringend ab. Keep it Simple - und genau das ist ein Failovercluster nicht mehr. Solche Technologien bergen hohe Risiken und man benötigt weit mehr Fachwissen. Die drohenden Probleme können selbst für einen bestens ausgebildeten und erfahrenen Admin zu einem Alptraum werden. Es gibt vor allem ein viel komplexeres Gebilde in dem viel mehr Abhängigkeiten zu beachten sind. Dafür ist ein solches Unternehmen zu klein - und der Nutzen zu fraglich.
Bezogen auf beide Unternehmen und inkl. Telefonserver, so werden die derzeit betriebenen 7 Server auf einen Produktivserver, einen Sicherungsserver (eigentlich ein NAS) und ein produktives Ersatzteillager (der ja eigentlich nur ein Client ist) reduziert. Damit einher geht eine deutliche Absenkung der Lizenzkosten von mehreren tausend Euro jährlich. Keep it simple!
1. Prolog
2. Ausgangslage
3. erste Maßnahmen
4. Konzeptioneller Lösungsansatz
i. Allgemeines
ii. Konkretes
ii. Konkretes
5. Einkaufslisten
i. Der Produktivserver
ii. Das produktive Ersatzteillager
iii. Der Sicherungsserver
ii. Das produktive Ersatzteillager
iii. Der Sicherungsserver
6. Umzugsszenario
7. Ressourcenzuteilung
i. CPU
ii. Arbeitsspeicher
iii. Festplattensystem
iv. Sonderfall virtualisierter Domänencontroller
v. Energiesparfunktionen
ii. Arbeitsspeicher
iii. Festplattensystem
iv. Sonderfall virtualisierter Domänencontroller
v. Energiesparfunktionen
8. Worklogs, Burn-Ins und Tests
9. Die kleine Firma
i. Der Server
ii. Die Clients
ii. Die Clients
10. Andere Beispiele in Kürze
i. ein anderer Doppelserver - under Construction
1) Prolog
aktueller Status des Projektes:
Der Sicherungsserver läuft von Anfang an völlig störungsfrei.
Der Produktivserver hat seinen Dienst am 28.05.2015 zunächst völlig problemlos aufgenommen. Dann gab es einen Absturz. Ein Blick in das Ereignisprotokolls hat gezeigt, dass es sich um ein Biosthema handelte (im Zusammenhang mit dem neuen Energiemanagement der CPU). Es gab keinen Datenverlust (Einstellungen haben sich also bewährt). Ausfallzeit wenige Minuten. Und es gibt bereits längst ein neues Bios. Also auch hier kein großes Thema.
Eine der beiden Server-CPUs war defekt und wurde eingetauscht. Die Ersatz-CPU war ebenfalls defekt und musste erneut eingetauscht werden. Die Dritte ist jetzt eingetroffen und funktioniert, das produktive Ersatzteillager kann jetzt in Betrieb gehen. Dennoch: keine Auswirkung auf den Produktivbetrieb :-). Mit der Standardlösung (24h vor Ort Austauschservice) sind genau solche Szenarien unangenehm - bei hiesigem Konzept recht belanglos.
Nach einer ausstehenden Änderung durch die Telekom soll auch der Telefonserver auf hier gegenständlichen Server virtualisiert werden. Dann ist die Serverlandschaft von 4 Servern auf einen Server geschrumpft. Zusätzlichist angedacht, den zweiten kleineren Betrieb per VPN einzubinden - also die 2 dortigen Server zu virtualisieren und einfach auf hiesigen Server zu legen. Daraus ergeben sich auch bzgl. der benötigten Lizenzen, vor allem für die diversen Datenbanksysteme, deutliche Einsparungen - und noch mal zwei Server weniger. Wir werden das 1 Woche im Realbetrieb testen - reicht die Internetverbindung nicht, geht das wieder zurück und wird irgendwann in Zukunft umgesetzt.
Achtung Nerd-Porn:
Der Sicherungsserver läuft von Anfang an völlig störungsfrei.
Der Produktivserver hat seinen Dienst am 28.05.2015 zunächst völlig problemlos aufgenommen. Dann gab es einen Absturz. Ein Blick in das Ereignisprotokolls hat gezeigt, dass es sich um ein Biosthema handelte (im Zusammenhang mit dem neuen Energiemanagement der CPU). Es gab keinen Datenverlust (Einstellungen haben sich also bewährt). Ausfallzeit wenige Minuten. Und es gibt bereits längst ein neues Bios. Also auch hier kein großes Thema.
Eine der beiden Server-CPUs war defekt und wurde eingetauscht. Die Ersatz-CPU war ebenfalls defekt und musste erneut eingetauscht werden. Die Dritte ist jetzt eingetroffen und funktioniert, das produktive Ersatzteillager kann jetzt in Betrieb gehen. Dennoch: keine Auswirkung auf den Produktivbetrieb :-). Mit der Standardlösung (24h vor Ort Austauschservice) sind genau solche Szenarien unangenehm - bei hiesigem Konzept recht belanglos.
Nach einer ausstehenden Änderung durch die Telekom soll auch der Telefonserver auf hier gegenständlichen Server virtualisiert werden. Dann ist die Serverlandschaft von 4 Servern auf einen Server geschrumpft. Zusätzlichist angedacht, den zweiten kleineren Betrieb per VPN einzubinden - also die 2 dortigen Server zu virtualisieren und einfach auf hiesigen Server zu legen. Daraus ergeben sich auch bzgl. der benötigten Lizenzen, vor allem für die diversen Datenbanksysteme, deutliche Einsparungen - und noch mal zwei Server weniger. Wir werden das 1 Woche im Realbetrieb testen - reicht die Internetverbindung nicht, geht das wieder zurück und wird irgendwann in Zukunft umgesetzt.
Achtung Nerd-Porn:
Der Thread wird unvollständig begonnen und parallel zum Fortschritt weiter entwickelt. Enthalten ist bisher die Ausgangslage, die Planung sowie der bereits umgesetzte Teil der Planung. Im Weiteren folgt dann der Rest der Umsetzung. Die noch fehlenden Teile sind im Inhaltsverzeichnis grau dargestellt. Fotos und Screenshots werden gleichsam noch nachgelegt.
In Summe stehen hier 6 Server in 2 Unternehmen zum Wechsel an.
Das Thema Sever im Eigenbau vs. fertige Server ist strittig. Die Entscheidung ist hier zugunsten des Eigenbaus gefallen. Fertigserver werden hier derzeit verwendet und sollen im Rahmen einer nötigen Erneuerung durch Eigenbauserver ersetzt werden. Dieses Thema ist damit abgehandelt und off-Topic (siehe hierzu 4.i). Das Konzept kann auch mit fertig gekauften Servern umgesetzt werden, fände man welche, die geeignet sind. Das scheitert aber schnell zum Beispiel an der Lautstärke und Erweiterbarkeit.
Die hier vorliegende Situation ist klassisch und eignet sich daher sehr gut als Fallstudie.
Es soll anhand eines Praxisbeispiels veranschaulicht werden, wie man selber oder in Kooperation mit einem Systemhaus vorgehen kann und wie diverse Problemstellungen abgedeckt werden können. Ich denke, auch Systemhäuser können hier Ansätze für ihre kleinen und mittleren Kunden entnehmen. Das Konzept wurde bereits in anderen Zusammenhängen und verschiedenen Variationen erfolgreich praktiziert.
Konstruktive Kritik, Beiträge und Fragen hierzu sind willkommen. Für Fragen und Unterstützungen zu eigenen Projekten hingegen bitte im passenden Fachforum einen eigenen Thread eröffnen und ggf. mich per PN darauf aufmerksam machen.
Einkaufslisten, Worklogs sowie Burn-ins begleitet von diversen Tests soll auch enthalten sein. Ggf. wird dies auch weitergeführt, um hier Erfahrungen, sofern diese hardware- oder konzeptbezogen sind, verfügbar zu machen, quasi als Langzeitstudie.
2) Ausgangslage
Es handelt sich um ein Unternehmen mit 11 Arbeitsplätzen, wobei ich die Nummer 11 bin. Es liegt damit bei zwei internen Personen IT-Erfahrung vor. Zusätzliche Begleitung durch 2 externe Systemhäuser ist gegeben. Im Hintergrund gibt es ein zweites Unternehmen, welches einem der Gesellschafter (dem mit IT-Kenntnissen) alleine gehört und 4+1 Arbeitsplätze beinhaltet.
Die Arbeitsplätze sind klassische vielseitige Office-Umgebungen im Servicebereich mit datenbankbasierten System wie Warenwirtschaft, Produktionsplanungssystem, Abrechnungssystemen sowie Buchhaltungssystem.
Zustand der IT ist/war bedenklich und überarbeitenswert aber dennoch überdurchschnittlich gut.
Es wird mit Remote Desktops und ThinClients gearbeitet (= RDS oder altsprech Terminalserver). Sehr gut. Idealvoraussetzungen für ortsunabhängiges Arbeiten, insbesondere zusammen mit VPN, sowie sehr geringer Wartungsaufwand, besonders, da die verschiedenen Datenbanksysteme häufige Updates mit sich bringen, die dann nicht mehr auf allen Clients durchgeführt werden müssen.
Ein Expansionskurs besteht nicht. Dieser Bestand aber auch zuvor nicht und es wurden dennoch über die Jahre 11 Arbeitsplätze. Es gibt also eine gewisse Eigendynamik. Potentiell stehen irgendwann neue Auszubildende/Mitarbeiter an, da Gesellschafter und Mitarbeiter älter werden. Das Ergebnis geringer Fluktuation wegen hoher Mitarbeiterzufriedenheit. Es käme dann mindestens temporär zu weiteren Arbeitsplätzen für diverse Jahre. Die Eigendynamik lässt aber vermuten, dass dies nicht zwingend komplett temporär bliebe.
Im Rahmen der Workflows digitalisiert sich die Arbeit immer weiter. Hierbei kommen zum Beispiel beim Wareneingang, der Buchhaltung und in anderen Zusammenhängen mehr und mehr digitalisierte Belege mit Schrifterkennung zum Einsatz. Aus Gründen der Anonymisierung möchte ich dies beispielhaft lediglich an der Buchhaltung genauer erläutern, da Buchhaltung nun mal allgemein ist.
In der Buchhaltung bedeutet dies, dass die Belege als PDF an jedem Buchungssatz angehängt werden. In diesem Zusammenhang werden die Belege auch mit Schrifterkennung durchforstet und interpretiert. Hieraus werden automatisierte Buchungsvorschläge generiert, was die Erfassung vereinfacht. Diese Systematik kann weiter trainiert werden. Das Finanzamt hat angekündigt, dies bis zum Jahr 2020 verbindlich zu machen.
Mit dem Einlesen der Dokumente geht aber eine starke Leistungsbeanspruchung einher – bei CPU und natürlich dem Festplattensystem. Dieser Prozess dauert derzeit mit einem Xeon DP E5504 (4x2GHz ohne HT und Turbo) an Seagate 15.000rpm SAS im RAID1 für einen durchschnittlichen Arbeitsdurchgang ca. 15 Minuten. CPU-Auslastung sinkt dabei schnell auf 50% (alle Kerne gleichmäßig), mehr Arbeitsspeicher wird kaum abgerufen. Das Festplattensystem ist also zu langsam, die Anwendung skaliert mit Kernen. Das Warten auf Abschluss des Einlesevorganges ist teils ungünstig, aber noch kein wirkliches Problem, da bisher nur wenige Vorgänge auf digitale Belegerfassung umgestellt wurden. Dies wird aber weiter zunehmen.
Aus den Angaben lässt sich das Verhältnis von benötigter Laufwerksleistung zu CPU-Leistung ableiten, so dass zukünftig kein Flaschenhals mehr besteht.
Im Weiteren ist zu erkennen, dass die digitale Belegführung Bedarf an Scannern, vor allem aber an zusätzlichen Bildschirmflächen schafft.
Die bisherigen Leistungsanforderungen sind ansonsten sehr gering. Obiger Xeon DP E5504 (Datenbankserver) sowie ein Xeon UP X3470 (Terminalserver) langweilen sich entweder oder zeigen kürzere Lastphasen im Bereich von 30% bis 50%. Der 1-kernige Pentium im Domänenserver hingegen ist überlastet. Da jetzt quasi Bildverarbeitung Einzug hält, ist eine massive Zunahme der Anforderungen binnen der kommenden 5 Jahre anzunehmen. Ggf. ergänzt durch weitere Arbeitsplätze. Aber: weiß man’s? Und wie hoch ist das anzusetzen? Wie kann ich eine große Leistungsspanne realisieren, ohne, sollte sich die Annahme nicht bestätigen, überdimensioniert zu haben und ohne dass es teuer wird?
Das derzeitige Gesamtvolumen der drei Produktivserver liegt nach unten beschriebenen ersten Maßnahmen bei 320 GB. Die drei Produktivserver belegen im Betrieb zusammen ca. 22GB RAM, es stehen 40GB zur Verfügung.
Vorgefunden habe ich hier 4 Windows Server 2008 R2: Domänenserver (inkl. DHCP-, DNS-, Exchange- und Dateiserver), Datenbankserver, Terminalserver sowie Sicherungsserver (letztlich ein NAS).
Es gab mannigfaltige Störungen, deren Zuordnung zu einem konkreten Grund schwierig war. Dies resultiert daraus, dass das System nicht konzeptionell entworfen sondern entlang akutem Bedarf historisch gewachsen ist.
Auffällig waren Störungszusammenhänge mit der Linux-basierten ThinClient Anbindung, besonders im Zusammenhang mit Maßnahmen, die der Schaffung zusätzlicher Bildschirmfläche dienten. Verschwindende Mauszeiger oder massives Endlosruckeln beim Scrollen zum Beispiel. Mit der Linux-basierten Anbindung der ThinClients entsteht ein heterogenes Netzwerk, was immer zusätzliche Störungsquellen mit sich bringt. Ein rein homogenes Netzwerk (durchgängig das gleiche System) ist deutlich wartungsärmer und im Ergebnis billiger, selbst wenn man hier zum Beispiel Windows als Software für die ThinClients einsetzen würde.
Im Weiteren Störungen, die trotz gleicher Basis der Nutzer (RDS-Server – alle arbeiten ja mit demselben Rechner) sich von Nutzer zu Nutzer unterschieden. Programmabstürze zum Beispiel, besonders bei Internetnutzung. Dies weist auf die Benutzerprofile hin.
Mit den Telefonen (VoIP) gab es auch Störungen (Störgeräusche, zu leise, Abbrüche, Schaltungsfehler – teils wurden Verbindungen reproduzierbar nicht hergestellt). Es kommen DECT- sowie kabelgebundene Geräte zum Einsatz.
Das Netzwerk scheint auch Störungsbilder beizutragen. Die verschiedenen Störungsbilder überlagern sich teilweise auch. Die Ausdifferenzierung war daher schwierig.
Die bestehenden Server sind zu laut (und zu viele). Trotz separatem Serverraum. Der Eingangsbereich sowie ein Arbeitsplatz sind akustisch verseucht. Ich sitze gerade mit Abstand Eingangsbereich, einem Büro und dann der Raum, in dem ich ganz am anderen Ende sitze, zusammen 19 Meter entfernt, und kann die Biester klar und deutlich hören. Allerdings ist es gerade außerhalb der Bürozeit, also sehr leise Umgebung – während der Bürozeit muss ich an diesem Platz hinhören, um die Server wahrzunehmen. Im Eingangsbereich und dem ersten Büroraum hingegen sind die Server deutlich wahrnehmbar, schwer zu überhören.
Die Temperaturen der Server waren deutlich zu hoch. Die 4 Server plus der Telefonserver mit einigen Kleingeräten produzieren so viel Abwärme, dass die Tür zum Serverraum offen bleiben muss. Um einen gewissen physikalischen Schutz zu gewährleisten, wurde ein Serverschrank eingesetzt. In dem staut sich aber gleichsam die Abwärme. Außerdem sind die eingebauten Komponenten schwer zugänglich.
Für keinen der Server bestand noch Hardwareverfügbarkeit. Es gab ursprünglich die klassischen 24/7 Austauschverträge, aber jeweils nur für drei Jahre, die selbst beim neuesten Server lange schon vorbei sind. Also alte Hardware, die über den gesamten Betriebszeitraum auch noch zu heiß betrieben wurde. Nicht unerwartet sind dann hier auch 3 Festplatten in kurzer Zeit ausgefallen. Fiele aber mehr als nur Festplatten aus, entstünde die Situation, dass man sich erst mal Gedanken über Ersatzbeschaffung machen müsste und dabei feststellen würde, dass passende Ersatzhardware teilweise gar nicht oder nur mit langen Lieferzeiten beschaffbar wäre.
Datensicherungen (Windows Serversicherung) dauerten viel zu lange und waren daher auch störanfällig. Im weiteren gingen damit deutliche Ressourcennutzungen einher.
3) Erste Maßnahmen
Die erste Maßnahme bestand natürlich darin, die Situation zu analysieren und ein Konzept auszuarbeiten. In diesem definierten Rahmen fanden dann folgende Maßnahmen bereits statt:
Vor und hinter den Serverschrank je einen großen Ventilator postiert (push-pull). Temperaturen damit wieder im grünen Bereich.
Systembereinigung (Frühjahrsputz). Servergespeicherte Benutzerprofile abgeschaltet, da diese in einer RDS-Umgebung meist überflüssig bis kontraproduktiv sind. Ordnerumleitung per Gruppenrichtlinie für Benutzerordner aktiviert, was bei servergespeicherten Benutzerprofilen sehr vorteilhaft ist aber viel zu oft nicht gemacht wird. Aber auch ohne servergespeicherte Benutzerprofile immer noch die Administration und Störungsbeseitigung vereinfacht und ein klarer gegliedertes System ergibt. Die Benutzerprofile erneuert (bzw. der Registryteil derselben, der Rest ist ja umgeleitet ins jeweilige Basisverzeichnis). Die Konfiguration der linuxbasierten ThinClients erneuert. Nicht (mehr) benötigte Software deinstalliert. Benötigte Software teils neu installiert, teils bereinigt. Einzelne Bestandteile der dateibasierten Einstellungen in den Benutzerprofilen (AppData) erneuert. Alle Updates geprüft und im Zweifel neu installiert. Zündkerzen poliert, Scheiben wischen, fertig ;-)
Das System läuft seit dem weitgehend störungsfrei und unnötige Systemlast ist deaktiviert. Detailarbeit (Konsolidierung) steht noch aus.
Die Virtualisierung der Server wurde erfolgreich geprobt.
Zur Datensicherung wurde hier jetzt Acronis (Universal License) eingekauft und vorläufig auf einem der Produktivserver installiert. Bisher wurde und wird die windowseigene Serversicherung verwendet. Dies bleibt wahrscheinlich in der kleinen Firma auch weiterhin, da Acronis dort unverhältnismäßig teuer scheint. Dies muss aber noch mal geprüft werden.
Obige Änderungen haben die Netzwerklast um 60GB pro Tag reduziert. Festplattenlast um 120GB, jeweils hälftig Schreib- und Leselast, davon 30GB Schreiblast auf SSDs (Intel 320 Series), weshalb deren Lebensdauer (15TBW) so weit beschränkt wurde, dass diese nun ausgetauscht werden müssen.
Die Software der Telefone wurde aktualisiert. Einige Störungsbilder sind damit verschwunden. Ein Update der Software der Telefonanlage kommt in Kürze. Die bisher bereits realisierte Entlastung des Netzwerkes scheint gleichsam einen positiven Effekt zu haben. Seit dem entstehen Störungen vorrangig noch während der Datensicherungen, was sich bald ja erledigt. Ansonsten nur vereinzelt bei den Funktelefonen und gehäuft an einem einzelnen Arbeitsplatz an einem Funktelefon (DECT), der offenbar funkverseucht ist. Quelle aber nicht identifizierbar. Kreuztest durch Austausch der Endgeräte ohne Erfolg – mit dem anderen Endgerät blieb die Störung bestehen, während das ursprüngliche Endgerät am anderen Platz plötzlich störungsfrei arbeitete. WLAN und alle anderen potentiellen Störquellen deaktiviert – ohne Besserung. Lösung ausstehend.
Der Sicherungsserver wurde vorgezogen. Hiermit wurde quasi auch wieder Hardwareverfügbarkeit hergestellt - bzw. ein Notfallszenario. Mehr dazu im Kapitel „Der Sicherungsserver“
4) Konzeptioneller Lösungsansatz
Grundsätzlich: keep it simple!
4.i) Allgemeines
Es gibt zahlreiche sogenannte Best Practice Empfehlungen sowie zahlreiche vermeintlich zwingende Dinge, die man tun soll oder lassen soll.
Tatsache ist aber, dass es keine allgemeingültigen Empfehlungen gibt. Denn jede Empfehlung steht immer unter dem Vorbehalt, ob sie denn tatsächlich im jeweiligen Szenario Sinn ergibt. Es spielt auch keine Rolle, welcher (möchtegern-) IT-Guru die Empfehlung ausgesprochen hat. Denn im Zweifel wird nicht dieser Guru, sondern der zuständige IT-Betreuer zur Verantwortung gezogen. Der Verweis auf einen IT-Guru hilft dann nicht weiter.
Das gilt natürlich auch für alle meine Empfehlungen und Ansätze. Und tatsächlich habe ich in anderen Situationen auch schon gegenteilige Lösungsansätze zu Hiesigen praktiziert, wobei hiesiger Rahmen meistens passt.
Im Weiteren ist es auch nicht Aufgabe der IT, Bedingungen festzulegen. Dies ist Aufgabe der Geschäftsführung, die bei diesen Vorgabenerstellungen natürlich auf das Fachwissen der IT zurückgreift. Und dann ist das die Bibel - und nicht das, was irgendein IT-Guru vorgibt. Es ist dann auch im Weiteren Aufgabe der Geschäftsführung, das entsprechende Budget dafür zur Verfügung zu stellen.
Die Geschäftsführung muss zum Beispiel definieren, wie lange die Ausfallzeiten welcher Systeme sein dürfen. Ob 24h zum Beispiel tragbar sind oder nicht - sondern binnen 2h wieder verfügbar gemacht werden muss. Auch gilt es zu differenzieren, welche Systeme. So ist es zum Beispiel für Mitarbeiter oft ein schweres Problem, wenn keine eMails mehr versendet oder empfangen werden können. Hingegen ein geringeres Problem, wenn der alte eMailbestand eine Zeit lang nicht verfügbar ist. So wäre also die Mailfunktionalität zum Beispiel binnen einer Stunde, aber der Mailbestand binnen 24h verfügbar zu machen.
Natürlich ist es auch Aufgabe der IT, die Geschäftsführung proaktiv auf Probleme und Risiken hinzuweisen.
Im Weiteren gilt: Je weniger Spezialwissen nötig ist, um das System beherrschen zu können, um so besser! Betriebe in hier gegenständlicher Größenordnung können in große Schwierigkeiten kommen, wenn das Konstrukt zu komplex ist und die eingesetzten Technologien zu viel Spezialwissen erfordern. Um so mehr, wenn dieses Spezialwissen schwer zugänglich ist. Reduce to the max!
Um zu ermitteln, ob eine angedachte Lösung sinnvoll ist, empfehle ich, sich konkrete Szenarien einmal vorzustellen. Zum Beispiel: Was passierte, fiele das Netzteil aus. Was, fiele das Mainboard aus. Was, reichte die CPU-Leistung nicht mehr, etc, etc, etc.
4.ii) Konkretes
Die drei Produktivserver sollen in Virtualisierungen umgewandelt und auf einem einzelnen neuen Server betrieben werden. Weniger Hardware = geringere Ausfallwahrscheinlichkeit und Kosten, Aufteilung auf mehrere virtuelle Server = geringere Komplexität des einzelnen Servers = geringere Ausfall- und Störungswahrscheinlichkeit.
Zum 14.01.2020 stellt Microsoft den Support für Server 2008 R2 ein, also können diese noch maximal 3,5 Jahre weiter laufen. Dann muss auf eine neuere Version migriert werden, da es keine Sicherheitsupdates mehr gibt. Voraussichtlich können dann mit einer Lizenz zwei Server betrieben werden, so dass sich eine Verdichtung auf zwei Virtualisierungen aus Kostengründen abzeichnet. Der Server 2016 R2 dürfte dann für weitere 10 Jahre gut sein. Merke: Lizenzcheck und -Strategie ist wichtig. Die Windows Server 2008 R2 wurden hier in 2012 angeschafft ausgehend von Server 2003, zuvor Server 2000. Das ist dann halt um ein vielfaches teurer - in der Anschaffung sowie der Implementierung.
Der Aufpreis für ein 2011-3 System, das im Bedarfsfall einen zweiten Prozessor aufnehmen kann, entsteht bei Mainboard und Netzteil und beträgt netto 40,- € gegenüber einem Einsockelsystem. Daher kommt ein Zweisockelsystem mit zunächst nur einem Prozessor zum Einsatz und wir verfügen damit über eine massiv erweiterbare Grundlage, Stichwort Skalierbarkeit. Daraus ergibt sich auch das Potential, den Server sehr lange zu betreiben.
Supportverträge für Hardwareverfügbarkeit laufen entweder 3 oder 5 Jahre, länger nicht. Für 5 Jahre kostet das dann bei hiesiger Größenordnung an die 1.500,- €. Dafür wird Verfügbarkeit binnen 24h garantiert.
Dies reicht uns nicht. Wir wollen den Server deutlich länger betreiben, 10 Jahre sind angedacht, gerne mehr. Das ist ökonomischer und ökologischer. 24h Warten im Störungsfall ist ebenso inakzeptabel. Auch führen diese Verträge in kleineren Unternehmen dazu, dass nach Ablauf der Servicezeit die Hardware weiter verwendet wird, da diese noch ausreicht. Lediglich die Verfügbarkeit ist dann nicht mehr gewährleistet, was aber teuer werden kann. Das fällt dann aber erst auf, wenn es zu spät ist. Und das Risiko steigt natürlich mit der Betriebsdauer. Während der Vertragslaufzeit hingegen ist das Risiko sehr gering – also Angebot und Bedarf laufen hier genau gegensätzlich. Das Gleiche gilt für die Verfügbarkeit bzgl. Aufrüstung. Bedenkenswert. Erneuert man aber zum Ende der Vertragslaufzeit, so ist man zeitlich gebunden. Man kann also zum Beispiel keine auf Sweet-Spots angelegte Beschaffungsstrategie fahren.
Obige 1.500.- € sehen wir daher als Budget, den Server quasi ein zweites Mal anzuschaffen und an nicht kritischer Stelle einzusetzen, hier als „ThinClient“. Dies nenne ich ein produktives Ersatzteillager.
Damit haben wir Hardwareverfügbarkeit binnen 0h anstatt 24h - ohne zeitliche Begrenzung auf 3 oder 5 Jahre. Garantie haben wir auch, je nach Bauteil zwischen 3 und 10 Jahren. Wir sparen einen ThinClient (300 €). Gleichzeitig haben wir eine Entwicklungs- und Teststation. Auch können wir im Störungsfall austesten, welche Komponente tatsächlich defekt ist. Alternativ kann direkt der Ersatzserver herangezogen werden (Festplattensystem umbauen, fertig). Auch zum Beispiel Bios- und Treiberupdates können besser auf Verträglichkeit geprüft werden. Wir wissen auch, da wir dies validieren, dass die Hardware in beliebiger Kombination kompatibel ist und durch den Betrieb als Client wissen wir auch, dass die Hardware funktioniert. DOA und Inkompatibilität mit Ersatzhardware im Störungsfall ist ausgeschlossen.
Dies gilt auch, wenn wir irgendwann aufrüsten wollen. Es kann nämlich zum Beispiel sein, dass eine später gekaufte neuere Version der gleichen CPU nicht mit der älteren Revision zusammen läuft, ähnlich wie gleiche RAM-Riegel nicht immer zusammen laufen. Dies ist hier ausgeschlossen, da wir eine passende CPU in der Hinterhand haben. Das produktive Ersatzteillager kann insofern auch im Falle einer Aufrüstung herangezogen werden, so dass die Aufrüstung nichts oder sehr wenig kostet und mit validierten Bauteilen erfolgen kann. Auch bei einem RAID-Array kann es passieren, dass zu dem Zeitpunkt, wo man es erweitern möchte, baugleiche Laufwerke auf dem Markt nicht mehr verfügbar sind. Dann müsste man entweder einen schmutzigen RAID fahren oder alle Laufwerke neu beschaffen.
Zum Beispiel: Nach 8 Jahren wird es CPU-seitig eng, für die verbleibenden 2 Jahre wird die CPU aus dem produktiven Ersatzteillager in den Produktivserver eingebaut. Findet man noch günstig gebraucht einen alten Server mit der gleichen CPU, nur die CPU oder eine kleine CPU, kann man das auch noch machen, um das produktive Ersatzteillager in Betrieb zu halten. Muss man aber nicht. Es sind ja nur noch 2 Jahre und die CPU bleibt ja redundant. Will man aber den Server noch länger betreiben oder wird die CPU früher eingesetzt, spricht umso mehr für Ersatzbeschaffung.
So oder so – es gibt in jeder Situation Optionen und die Folgekosten sind stark minimiert. In jeder Situation kann man ganz entspannt und hoch flexibel agieren und den Betrieb wieder zum laufen bringen oder beschleunigen um dann in der Nacharbeit ohne jeden Zeitdruck die weitere Verfahrensweise festzulegen und umzusetzen.
Die Hardwarebeschaffung kann ebenfalls günstiger erfolgen, da man nicht auf besonderen Service oder Kulanz eines Händlers angewiesen ist. Man kann also sehr gut über Geizhals bei Händlern, die viele positive Bewertungen haben, einkaufen.
Gleichzeitig kann hier das produktive Ersatzteillager auch noch für die andere kleinere Firma zur Verfügung stehen. So etwas könnte man auch durch Kooperationen mit Geschäftsfreunden oder Gebäudenutzern realisieren. Damit entfällt dort sowie in jedem anderen potentiell eingebundenem Unternehmen gleichsam ein entsprechender Vertrag vollständig und die Vorteile gegenüber einem solchen Vertrag kommen dort größtenteils gleichsam zur Geltung.
Allerdings wird hier für die kleinere Firma zunächst aus der vorhandenen Hardware beider Unternehmen mit kleinen Ergänzungen, quasi als Resteverwertung, ein neuer Server gebaut bzw. früher oder später deren Virtualisierungen auf hiesigem Server abgelegt und per VPN zugegriffen. Glücklicherweise wurde teils gleiche Hardware in beiden Unternehmen verwendet, so dass hier ebenfalls ein System gebaut werden kann, bei dem alle maßgeblichen Bauteile noch mal als Ersatz vorliegen. Da die Teile über oder gegen 5 Jahre alt sind, wäre ansonsten ein weiterer Betrieb nicht möglich, da die Verfügbarkeit nicht mehr gegeben wäre. So aber können die Teile noch ein paar weitere Jahre eingesetzt werden, bis das Internet eine ausreichend stabile VPN-Verbindung hergibt.
Zu beachten ist, dass normalerweise das produktive Ersatzteillager nicht als Sicherungsserver für die Daten verwendet werden kann. Denn bei einem Hardwareausfall, bei dem das produktive Ersatzteillager ausgeschlachtet würde, könnte in dieser Situation nicht mehr ohne Weiteres auf die Datensicherung zugegriffen werden. Es bestünde aber genau dann eine erhöhte Wahrscheinlichkeit, dass dies nötig würde. Der Sicherungsserver könnte aber als produktives Ersatzteillager für einen anderen Server dienen, zum Beispiel in einem anderen Unternehmensteil oder hier für die kleine Firma. Bzw. wird er hier früher oder später in den kleinen Betrieb wechseln, die Sicherungen per VPN dorthin geleitet (sind dann gleichzeitig Außerhaussicherungen) und dieser Sicherungsserver so konfiguriert, dass er bei länger anhaltendem Internetausfall die Virtualisierungen der kleinen Firma lokal übernehmen kann und dann temporär als Produktivserver dient.
Vorläufig werden die beiden Unternehmen zur Außerhaussicherung zukünftig gegeneinander gesichert. VPN zwischen den Unternehmen besteht ja bereits.
Oben gezeichnete Lösung bräuchte keinen Serverraum mehr sondern könnte auch in eines der kleinen separierten Büros. Dies machte ein zusätzliches Büro frei, entstünde der Bedarf.
Der Lösungsansatz ergibt im Weiteren eine deutliche Einsparung beim Stromverbrauch. Dies finanziert die neuen Anschaffungen. Absolut gesehen sinkt damit der Stromverbrauch aber derart tief, dass zukünftige potentielle Einsparungen durch höhere Energieeffizienz neuer Technik nicht mehr hoch genug werden können, als dass ein Wechsel wegen Energieeffizienz ökonomisch oder ökologisch Sinn ergäbe. Auch verlangsamt sich nun laut Intel die Weiterentwicklung. Kaufzeitpunkt also Sweet Spot. Broadwell-EP zeigt vor allem im Zusammenhang mit Virtualisierungen deutliche Verbesserungen. Die Leistungssteigerung im Allgemeinen zur Vorgängergeneration erlaubt es auch, eine Leistungsklasse tiefer zu gehen, was nochmals 500,- € spart. Auch hier: Sweet Spot.
Der Einsatz von Acronis (inkrementelle Sicherung sowie Einstellung der Ressourcennutzung) reduziert die Netzwerklast weiter massiv – bisher gibt es Telefonstörungen, wenn die Sicherungen beginnen. Die Sicherungen dauern auch viel zu lange.
Mit oben beschriebener Lösungsansatz besteht im Weiteren die Hoffnung, die Kommunikation der Server untereinander aus dem physikalischen Netzwerk herausnehmen zu können. Mit dem zukünftigen Server kann ggf. auch der Internetverkehr aus dem internen Netzwerk separiert werden. In Summe mit den ersten Maßnahmen und hier dargestellten Vorhaben reduzierte sich die Netzwerklast derart, dass eine sonst nötige Erneuerung des Netzwerkes (1.500 €) nicht mehr nötig wäre. Aktuellere Windows Server beinhalten darüber hinaus neue Funktionen, die geeignet sein können, den Netzwerkverkehr softwareseitig weiter zu optimieren.
Das System soll dann gut dokumentiert werden, um Unabhängigkeit von Personen und Systemhäusern zu befördern. Gut geeignet hierfür ist Microsoft One-Note. Daraus wird dann auch ein Notfallhandbuch gezogen, welches in ausgedruckter Form griffbereit gehalten wird. Die Notfallszenarien werden regelmäßig (möglichst 1x jährlich) getestet.
Mit oben beschriebenem Konzept könnte man jetzt behaupten, man solle doch dann direkt einen Failovercluster betreiben. Davon rate ich dringend ab. Keep it Simple - und genau das ist ein Failovercluster nicht mehr. Solche Technologien bergen hohe Risiken und man benötigt weit mehr Fachwissen. Die drohenden Probleme können selbst für einen bestens ausgebildeten und erfahrenen Admin zu einem Alptraum werden. Es gibt vor allem ein viel komplexeres Gebilde in dem viel mehr Abhängigkeiten zu beachten sind. Dafür ist ein solches Unternehmen zu klein - und der Nutzen zu fraglich.
Bezogen auf beide Unternehmen und inkl. Telefonserver, so werden die derzeit betriebenen 7 Server auf einen Produktivserver, einen Sicherungsserver (eigentlich ein NAS) und ein produktives Ersatzteillager (der ja eigentlich nur ein Client ist) reduziert. Damit einher geht eine deutliche Absenkung der Lizenzkosten von mehreren tausend Euro jährlich. Keep it simple!
Zuletzt bearbeitet:
