Nomics Blog

Erst durch ein Re-Design des Netzwerks lässt sich die virtualisierte Rechnerwelt umfassend erschließen. Die Herausforderung der Unternehmens-IT besteht darin, die Benutzer mit zufriedenstellender Anwendungsleistung zu versorgen und gleichzeitig die Kosten für den Betrieb des Rechenzentrums und der Rechnerinfrastrukturen in der Balance zu halten. Eine der wichtigsten Optimierungsmaßnahmen besteht in der Virtualisierung der Server-Ressourcen. Dies umfasst die Virtualisierung, das Pooling und Sharing von Rechen-, Speicher- und Netzwerk-Ressourcen. Einige Experten bezeichnen dieses Konstrukt auch als „private Cloud“. Dadurch wird die durchschnittliche Auslastung der IT-Ressourcen drastisch verbessert und neue Anwendungen oder Dienste lassen sich in kürzester Zeit im Unternehmen ausrollen.Eine der grundlegenden Realitäten von Clouds bzw. gemeinsam genutzten Ressourcen-Pools lautet, dass größere Clouds eine höhere Effizienz und Flexibilität gewährleisten. Leider erhöht der Wunsch nach Größe und höherer Dynamik vielerorts Anforderungen an die im Data Center installierten Netzwerke. Es ist das Netzwerk, welche die im Data Center installierten IT-Ressourcen verbindet und somit die Grundvoraussetzung für eine leistungsstarke private Cloud legt.Leider stellen die Netzwerke auch das größte Hindernis zur erfolgreichen Umsetzung einer Cloud-Strategie dar. Die meisten der heute installierten Netzwerke wurden nicht für die Anforderungen der virtuellen Rechnerarchitekturen ausgelegt und bieten daher nicht die notwendige Dynamik zur Unterstützung der modernen Anwendungen. Nur durch ein Re-Design der Netzwerke in den Data Centern lässt sich der volle Nutzen aus der Virtualisierung und dem Cloud Computing ziehen.Die typische Rechenzentrumsarchitektur für ein Ethernet-Netzwerk basiert auf einer logischen Baumstruktur, die wiederum auf mehreren Ebenen von Switch-Komponenten beruht. Als die SNA-Welten und Token Ring vor 10 bis 15 Jahren durch das Ethernet und die Server-Strukturen in den Rechenzentren eingeführt wurden, etablierte sich diese LAN-Architektur. Da sich die Rechenzentren in den vergangenen 10 Jahren drastisch entwickelten, zeigten sich nach und nach die Mängel, die fehlende Performance dieser Netzarchitektur und die übermäßige Komplexität wirkte sich negativ auf die Betriebskosten aus.Diese strukturellen Mängel lassen sich nicht leicht beheben, denn die Komplexität der Netzkonstrukte wirkt der vollen Wirksamkeit der Rechnervirtualisierung entgegen. Die Komplexität der Netzwerke hat ihre Ursache in der auf einer Baumstruktur aufbauenden Architektur. Netzwerke bestehen aus mehreren, autonom arbeitenden Switches, die durch ein gemeinsames Protokoll zusammenarbeiten. Somit erfordert die Verwaltung eines Netzwerks nicht nur die Kooperation der Switches untereinander, sondern auch die Interaktion miteinander.Wenn die Performance im Netzwerk wächst steigt die Anzahl der Switches im Netzwerk linear an. Jedoch steigen die möglichen Wechselwirkungen zwischen den Switches (im Quadrat zur Anzahl der Switches) mit steigender Skalierung dramatisch an. Dies lässt sich mit folgender Formel ausdrücken: i = n(n-1)/2. Hierbei stellt i die Anzahl der potentiellen Interaktionen und n die Anzahl der verwalteten Geräte dar. Diese enorme Zunahme der Interaktionen zu verwaltenden Netzkomponenten erhöht die Komplexität des Netzwerks und wirkt den Vorteilen der Virtualisierung entgegen. Mit anderen Worten bedeutet das: Die Komplexität definiert die Grenzen der Skalierbarkeit. Da zur Anbindung des Data Centers an das Netzwerk immer mehr Ports benötigt werden, wird es immer schwieriger den Verkehr zu steuern. Die Komplexität steigt auch hier quadratisch bis zu dem Punkt an, an dem die Layer-2-Netzdomänen in der Praxis nicht mehr zu verwalten sind. Zur Begrenzung der Komplexität wird deshalb das Netz in vielen Rechenzentren physikalisch in mehrere Segmente unterteilt. Dies untergräbt zwangläufig die Idee, weniger und dafür größere Ressourcen-Pools zu betreiben. Auch setzt die Komplexität eines solchen Netzkonstrukts der Dynamik enge Grenzen und die Netzwerke lassen sich nicht mehr automatisch an die Anforderungen anpassen.Der Schlüssel zur Modernisierung der Netzwerke liegt in der radikalen Vereinfachung. Allerdings ist eine solche Vereinfachung nicht durch kosmetische Veränderungen zu erreichen und erfordert ein Umdenken im Bereich der Netzwerkarchitektur. Hierzu wurden folgende Möglichkeiten entwickelt:

1. Reduzierung der physikalischen Netzwerke auf ein Minimum. In den meisten Unternehmen beginnt man deshalb die vielen Ethernet-Netzwerke zu einem einzigen physischen Netzwerk umzubauen. Das Data Center Bridging (DCB) in Verbindung mit VLAN-Funktionalitäten sorgt für die Trennung und die individuelle Priorisierung der Verkehrsströme. Darüber hinaus sollte der Storage-Verkehr auf das Ethernet konvergiert werden. Hierzu stehen inzwischen eine Vielzahl erprobter Techniken, wie beispielsweise NAS, iSCSI oder FCoE bereit.
2. Reduzierung der physischen Netzwerkhierarchien. Die meisten Netzwerke in Data Centern sind heute auf drei Switch-Hierarchien aufgebaut. Die neuesten Netztechnologien ermöglichen die Beseitigung des Aggregations- Layers, wodurch das Netzwerk auf zwei Schichten reduziert wird. Dies hat keinerlei Auswirkungen auf die Skalierung, sondern reduziert nur die Anzahl der notwendigen Switches und der daraus resultierenden Komplexität bei gleichzeitiger Verbesserung der Leistung und Reduzierung der Kosten.
3. Die Architektur wandelt sich in eine "Netzwerk-Fabric". Durch den Umbau des Netzwerks auf eine Fabric-Architektur werden, im Gegensatz zu den traditionellen Baum-Architekturen, alle Netzelemente innerhalb der Fabric durch eine einzige Control-Plane gesteuert. Im Grunde verhalten sich die Elemente der Fabric wie physische Elemente innerhalb eines logisch verteilten Switches.
   Die Netzwerk-Fabric interagiert problemlos mit den dynamischen Ressourcen-Pools. In der Praxis bedeutet dies, dass bei der Definition oder der Umkonfiguration eines virtuellen Ports (Schnittstelle zwischen VM und dem Netz) alle physikalischen Ports im Netzwerk davon in Kenntnis gesetzt werden. Wenn ein VM von einem Rechner zum anderen wandert, bleibt die virtuelle Port-Konfiguration automatisch erhalten und die Verbindungen der betreffenden VMs zu den Netzwerk-Ressourcen bleiben erhalten. Darüber hinaus wandern alle ACLs, VLANs und Sicherheitsdefinitionen bei einer Umkonfiguration automatisch mit.
4. Entwicklung eines umfassenden Managements. Momentan unternimmt die Industrie erhebliche Anstrengungen um das Management der virtuellen und physischen Netzwerkstrukturen unter einen Hut zu bringen. Dies würde dazu beitragen, die typischen Konfigurationsfehler, die durch die Nutzung separater Werkzeuge bzw. Schnittstellen bei der Konfiguration der virtuellen und physischen Switches entstehen, beseitigen.
5. Integration der Virtual Ethernet Port Aggregation (VEPA). Der Standard 802.1 Qbg ermöglicht, dass ein physikalischer Server direkt mit dem externen Switch zusammenarbeitet und somit eine Brücke zwischen mehreren VMs und den externen Netzwerken bildet. Bisher operierten die virtuellen Switches als reine Brücken und der VM-Traffic innerhalb eines Rechners wurde direkt vom virtuellen Switch weitergeleitet. Die zunehmende Virtualisierungsdichte erhöht jedoch den, durch den virtuellen Switch generierten, Overhead. Außerdem stellt ein virtueller Switch aus Sicht der physikalischen Netzwerk-Switches einen Fremdkörper im Netz dar, der nicht in der Lage ist, die gleichen Policies (Filter, Sicherheit, Access Control Listen, etc.) anzuwenden wie ein physikalischer Switch. Auch würde ein solcher Lösungsansatz zu einer Duplizierung bestimmter Verwaltungsaufgaben führen. Da die Switches bereits über die notwendige Intelligenz verfügen, macht es wenig Sinn deren Funktionen und Dienste an anderer Stelle noch einmal zu erbringen. Außerdem entstünde das Problem, dass sich die Policies nicht einheitlich verwalten lassen könnten. VEPA verlagert viele Policys, Sicherheits- und Verwaltungsaufgaben von den virtuellen Switches auf den Network Interface Cards (NIC) und Blade-Server hin zu den physikalischen Ethernet-Switches.

Um das volle Nutzen aus der Virtualisierung zu erzielen und um skalierbarere und dynamischere Ressourcen-Pools zu kreieren, müssen sich die Architekturen der Rechenzentren und der Netzwerke verändern. Diese Änderungen erfordern sowohl eine hardwareseitige Änderungen in den Switches, als auch auf der Softwareseite im Hypervisor. Wird dieser Umbau konsequent vollzogen, dann passt sich das Netzwerk dynamisch an die Anforderungen im Server- und im Storage-Bereich an und sorgt für die schnelle und sichere Bereitstellung der notwendigen Übertragungsressourcen.

oder Passwort-Sicherheitsrichtlinien gelten nicht für IT-Administratoren

Mit Passwörtern werden in vielen Unternehmen sensible Daten abgesichert bzw. den Zugriff auf diese geregelt. Aus diesem Grund verfügt auch jedes Unternehmen über mindestens eine Passwortrichtlinie. Leider wird die Passwortsicherheit und damit der Zugang zu wichtigen Unternehmensinformationen durch unsichere Administratorpassworte immer wieder untergraben. Es scheint, dass die Administratorpassworte außerhalb der Sicherheitspolitiken stehen und sich die Admins nicht an die Regeln gültiger und aktualisierter Passworte zu halten haben.
Inzwischen sollte es sich innerhalb der IT herumgesprochen haben, dass Passworte so aufgebaut sein müssen, dass diese nicht zu erraten bzw. nur schwer zu knacken sein sollten. Die Höchststrafe ereilt einen Nutzer, wenn dieser seine Passworte an Dritte weitergibt. Diese Passwortrichtlinien bestehen zwar auf dem Papier, aber wenige Mitarbeiter in den Unternehmen folgen diesen Leitlinien. Weltweite Umfragen zeigen,

• dass 40 Prozent der Nutzer ihre Passwort mit einer oder mehreren Personen teilen,
• dass fast die Hälfte der Nutzer keine Sonderzeichen in den Passworten nutzt,
• dass 20 Prozent der Nutzer noch immer leicht zu erraten Informationen (Geburtsdaten, Name
   eines Haustiers) als Passwort verwenden.

Einem Sicherheitsexperten stellen sich angesichts dieser Umfragen die Nackenhaare auf. Seit Jahren werden Passwort-Richtlinien gepredigt:

• - Die Mindestlänge des Passworts sollte acht Zeichen betragen: Passwörter sind umso
    schwieriger zu knacken je länger diese sind. Mit jedem Zeichen, das ein Passwort länger
    wird, sinkt die Wahrscheinlichkeit eines Einbruchs. Ab einer Passwortlänge von 8 Zeichen
    dauern Brute-Force-Angriffe zu lang.

• - Eine Kombination kryptischer Zeichnfolge ist obligatorisch: Das Passwort sollte nicht aus
    einer natürlich vorkommenden Zeichnfolge (Beispielsweise Michael8) bestehen und sollte in
    keinem Wörterbuch vorkommen. Ein zufällig generiertes 8 Zeichen langes Passwort besteht
    aus Buchstaben, Zahlen und Symbole (beispielsweise: s3h7%R9#). Einen noch höheren
    Schutz vor Angriffen erhält man durch ein 12 bis 18 Zeichen langes zufällig gewähltes
    Passwort.

• - Das Passwort sollte leicht zu merken sein: Wichtig bei Passworten ist, dass man diese
    nicht niederschreibt (Post-IT unter der Tastatur oder in der rechten Schreibtischschublade),
    sondern sich leicht merken lässt. Eine Eselsbrücke für ein zufälliges Passwort besteht darin,
    einen gewöhnlichen Satz (der sich leicht merken lässt) in ein Passwort zu verwandeln. Es
    werden beispielsweise die ersten Buchstaben eines jeden Wortes genommen und
    vereinzelt diese durch Zahlen ersetzt. Der String THwd1.BdBRD ist ohne erkennbares
    Muster. Erst durch den dahinter versteckten Satz erschließt sich der Sinn des Passworts:
    "Theodor Heuß war der erste Bundespräsident der Bundesrepublik Deutschland“.

• - Zusammenfassen ganzer Sätze: Die heute verfügbaren Rechnersysteme unterscheiden
    sich in Bezug auf die maximale Länge eines gültigen Passwort. Erlaubt das System 32 oder
    mehr Zeichen, lassen sich vollständige Sätze als Passwort benutzen. Da Leerzeichen,
    Apostrophe, Anführungszeichen die Rechner manchmal verwirren (und deshalb in
    Passworten verboten sind), lassen sich Punkte und andere Satzzeichen miteinander
    kombinieren. Beispielsweise sind »Meinemutterwarbemeinergeburt22alt.« und
    »Am23.Dezember1989,0:00uhrwarichinBerlin.« sind herrliche Passwörter.

• - Mix and Match: Natürlich besteht auch bei solchen Passwortkonstrukten immer noch die
    Möglichkeit, dass man die Worte, Namen und Daten errät. Aus diesem Grund besteht die
    optimale Passwortstrategie darin, mehrere Begriffen miteinander kombinieren. Das
    Passwort »UlleLHGH08132Krähe34256» besteht aus folgenden Kombinationen: Spitzname
    erste Freundin, Initialen des Bruders, Vorwahl des Telefons, Name des Lieblingstiers, letzen
    5 Ziffern der Sozialversicherungsnummer. Jeder einzelne Begriff lässt sich erraten, aber die
    Kombination mehrer Begriffe sorgt für die nötige Sicherheit.

• - Passwort-Generatoren: Im Internet gibt es viele Passwort-Generatoren, die einem Nutzer
    die Generierung mehrerer starker Passworte erleichtern. Über einen Passwort-Assistenten
    lassen sich beliebige Wort-, Zahlen- und Zeichenkombinationen eingeben. Mit Hilfe eines
    Schiebereglers legt man anschließend die Länge und die Stärke des Passworts fest. Der
    Passwort-Generator liefert anschließend eine Liste möglicher Passworte die der Nutzer
    benutzen kann.

Administrative Passwörter öffnen den Zugang zu Servern, zu Personendaten, zu Logs, und natürlich auch den Zugang zu den sensiblen Unternehmensdaten. Administrative Passwörter sind oft in Stein gemeißelt. Die Passworte werden fest in Skripts und Makros codiert. Das vereinfacht zwar den Umgang mit den Passworten. Jede Änderung wird dadurch zum potenziellen Albtraum und erfordert über mehrere Systeme hinweg aufwändige manuelle Eingriffe in die Skripts und Makros. Jedes statische Passwort stellt eine potenzielle Gefahr dar und kann unbeabsichtigt aufgedeckt, erraten oder geknackt werden. Da auch IT-Administratoren der normalen Fluktuation unterliegen und das Unternehmen verlassen können, ist es notwendig, dass die ihnen zur Verfügung gestellten Admin-Zugänge beim Ausscheiden aus dem Unternehmen geschützt werden.
Wer sich jedoch im Markt umsieht, wird feststellen, dass es inzwischen eine Reihe kostenloser Tools gibt, die bei der Passwortverwaltung den IT-Administratoren helfen. Beispielsweise lassen sich mit Bulk Password Reset von NetWrix, Reset Local Password Pro und vielen andere Freeware- und Shareware-Tools die Admin-Passwort gleichzeitig auf vielen Systemen ändern. Trotzdem sollten IT-Administratoren bei der Verwendung dieser Werkzeuge extreme Vorsicht walten lassen. Ohne Probleme kann man sich bei der zentralen Definition der Passwörter in einem komplexen Netz von Skripts verheddern, was zur Folge haben kann, dass die Passworte nicht oder falsch gesetzt werden.

Fazit
Auch Admin-Passwort sollte regelmäßig aktualisiert werden. Man muss jedoch sicherstellen, dass die Änderung gründlich getestet und die Geschäftsprozesse auch mit den neuen Passworten noch sicher sind.

In einem Kundenprojekt war ich an der Umzugsplanung von Mitarbeitern in ein neues Gebäude beteiligt. Durch den Umzug in das neue Gebäude konnte auch mit den bisherigen LAN-Strukturen aufgeräumt und quasi auf der „grünen Wiese“, ohne Altlasten berücksichtigen zu müssen, mit der Netzwerkplanung begonnen werden. Natürlich sollten bei der Neuausstattung der IT-Umgebungen die neuesten Technologien zum Einsatz kommen. Virtuelle Desktops, neue Drucktechniken und die Nutzung von Collaboration-Tools. Der Neubau wurde hauptsächlich von der Unternehmensleitung genutzt. Aus diesem Grund hatte das Projekt auch eine gewisse Leuchtturmsymbolik für das gesamte Unternehmen.

Da im neuen Gebäude viel mehr Menschen als bisher arbeiten werden und die neuen Anwendungen erhöhte Anforderungen an die Übertragungstechnik stellen, musste sichergestellt werden, dass die WAN-Bandbreite zwischen den einzelnen Gebäuden des Unternehmens die gestiegenen Ansprüchen erfüllt. An oberster Stelle der Anforderungsliste stand die Konfigurierung der Priorisierungs- bzw- QoS-Mechanismen für die Sprach- und Videodienste. Der Echtzeitverkehr musste vor den Bandbreitenfressern, wie beispielsweise den Print-Diensten, geschützt werden.

Wir stellten uns die Frage: Wie viel Bandbreite benötigen wir? Eine einfache Fragestellung auf die es keine simple Antwort gibt. Deshalb begannen wir unsere Recherche bei den zuständigen Administratoren der Drucker und Print-Services. "Wie viel Bandbreite schätzen Sie wird für das Drucken im Netzwerk bei der vorgegebenen Anzahl der Benutzer benötigt?" Antwort: "Wir haben keine Ahnung, aber wie viel Bandbreite können Sie uns geben?"

Die Desktop-Abteilung konnte uns auch noch kein genaues Bild ihrer Bandbreitenanforderungen liefern, da die neuen Desktop-Konfigurationen noch nicht offiziell getestet wurden. Auch diese Abteilung hatte keine Ahnung, wie viel Verkehr im Netzwerk generiert werden würde.
Aus einer Testumgebung wusste ich, dass die genutzten Desktop-Applikationen in einer klassischen LAN-Umgebung, so viel Bandbreite belegen, wie diesen zur Verfügung gestellt wird. Mit anderen Worten heißt dies: Die Anwendungen werden in einer realen Netzumgebung bis zu 100 Prozent der verfügbaren Bandbreite belegen! "Wie viel Bandbreite schätzen Sie wird für die Desktop-Anwendungen im Netzwerk bei der vorgegebenen Anzahl der Benutzer benötigt?" Antwort: "Wir wissen es nicht, aber wie viel Bandbreite können Sie uns geben?"
Die Frage an den Projektmanager lautete deshalb: "Wie viel Bandbreite stellt das WAN den einzelnen Services zur Verfügung?“ Auch hier lautete die simple Antwort: Ich habe keine Ahnung, aber die verfügbare Bandbreite war noch nie unser Problem. Notfalls kaufen wir einfach neue Bandbreite hinzu!“

Ich versuche dem Projektmanager zu erklären, dass es ohne irgendwelche Informationen über den jeweiligen Bandbreitenbedarf der Anwendungen und Services keine QoS-Planung geben könnte. Auch versuchte ich durch eine ganze Reihe sinnvoller Fragen den Projektmanager für das Thema „QoS im WAN“ zu sensibilisieren. Statt konkreter Antworten und einem verwertbaren Zahlenmaterial erhielt ich nur schön anzuhörende Worte, die im Kern nichts aussagten.
Daher bestand auch keine Chance innerhalb einer Testumgebung das WAN-Szenario realitätsnah überprüfen und die erforderlichen QoS-Einstellungen überprüfen zu können. Natürlich war man bei der Installation der neuen IT-Infrastrukturen bereits im Zeitverzug und konnte sich weitere „unnötige“ Tests nicht leisten.

Dieses Verschließen vor der Realität gehört zu den typischen Vorgehensweisen bei der Planung und Umsetzung von IT-Infrastrukturen. Alle beteiligten Abteilungen wissen, dass das Netzwerk der wichtigste Baustein für eine erfolgreiche Abwicklung des Projekts darstellt, aber in der Realität setzt sich niemand mit den notwendigen Übertragungsparametern des Netzes auseinander. Ist das IT-Projekt erst einmal fertig gestellt, dann muss sich die IT-Abteilung mit den fehlenden QoS-Merkmalen für die jeweiligen Anwendungen auseinander setzen. Meist besteht die Analyse darin, dass man zu wenig Bandbreite beim WAN-Anbieter bestellt hat. Folglich wird so lange Bandbreite nachbestellt bis die Probleme verschwinden. Dieser Ansatz kommt zwar den Unternehmen langfristig teurer als eine detaillierte QoS-Planung und –Realisierung, hat jedoch den Vorteil, dass die IT-Abteilung sich nicht mit der komplexen Materie der Priorisierung auseinander setzen muss.

Trotz erheblicher Bemühungen ein gutes Netz- und Systemdesign zu realisieren, versagen die hochverfügbaren Systeme erschreckend häufig.

Man muss sich nur lange genug mit der IT beschäftigt haben, dann weiß man, dass die Kronjuwelen der unternehmenskritischen Anwendung, trotz teurer Hochverfügbarkeit, einfach und ohne Grund abstürzen können. Obwohl eine Vielzahl von Sicherungen und teuren Sicherheitsvorkehrungen in die Systeme integriert wurden, tritt das „Unmögliche“ ein – und oft schneller als damit gerechnet wurde. Die Gründe für das Versagen sind vielfältig und sind doch immer auf zwei wesentliche Faktoren zurückführen: Komplexität und menschliches Versagen.
Die Komplexität selbst des kleinsten Netzwerks übersteigt heute die Komplexität eines Unternehmensnetzes von gestern. Die Server-Virtualisierung, die Migration des Rechenzentrums auf virtuellen Maschinen, die Integration von Storage-Netzen, Datenreplikation, konvergente Netze und die neuen Echtzeittechnologien verteuern nicht nur die IT-Projekte, sondern erfordern bei ihrer Umsetzung auch die notwendige Erfahrung.
In der Vergangenheit hing die Funktionalität einer Anwendung von nichts anderem ab als die eigene interne Hardware und dem ordentlich funktionierenden Netzwerk ab. Heute sind die Abhängigkeiten drastisch angewachsen und erfordern das korrekte Zusammenspiel von zentralen Speichergeräten, einem stetig wachsenden Firmware Code, dem Virtualisierungs-Hypervisor vollgepackt mit Features und einer komplexen QoS-gesteuerten Netzarchitektur. Natürlich sind wir froh, dass wir nicht mehr Dutzende von Stand-alone-Servern mit der dazu gehörenden Computer- und Storage-Hardware warten und pflegen müssen. Dies wäre einfach zu zeitaufwendig. Aber die Komplexität ist der Preis den wir für den Fortschritt bezahlen müssen.
Jedes Mal, wenn man sich fragt: “Was ist es denn jetzt schon wieder los?", dann bezahlt man die dem Fortschritt geschuldete Rechnung. Die heutigen Lösungen sind weit komplizierter als die früher genutzten Systeme und die wenigsten IT-Spezialisten verstehen die Systeme noch vollständig. Wenn man erst einmal mit ein paar Stunden des Sichtens eines obskuren Haufens von Log-Dateien verbracht hat, und nicht herausfindet, warum etwas das was funktionieren sollte nicht funktioniert, dann verflucht man die Götter die man früher einmal gerufen hat.

Teilweise als Folge der Komplexität, aber auch aufgrund der modernen Geschäftsanwendungen ist heute die Abhängigkeit von einer funktionierenden Technologie viel größer als früher. Eine hohe Verfügbarkeit war früher ein fast unerfüllbarer Traum. Heute redet man von einer 99,99-prozentigen Verfügbarkeit und erwartet auch, dass diese von den IT-Abteilungen für alle Geschäftsprozesse bereitgestellt wird. Noch vor fünfzehn Jahren empfanden viele Unternehmen einen 24-stündigen Ausfall einer Anwendung als unangenehm, aber nicht als Katastrophe. Heute rollen bereits bei einem zweistündigen Ausfall die verantwortlichen IT-Köpfe.
Die Uptime regelt daher die System-Redundanz und die bevorzugten Lösungen sind das Clustering und die Replikation. Diese Systeme erreichen in der Regel ihre Ziele, wenn diese wie geplant genutzt, implementiert und gewartet werden. In der Praxis werden dadurch die Systeme immer komplexer und arbeiten daher immer fehlerhafter. Diese Fehler versuchen wir durch immer neuere Ebenen der Komplexität auszuschalten. Gott sei Dank funktionieren die modernen IT-Systeme fast immer – wenigstens die meiste Zeit.
Wie auch im sicheren Flugverkehr, kommt es auch bei hochredundanten IT-Systemen ab und an zu Abstürzen. Diese sind meist auf menschliches Versagen zurückzuführen. Obwohl die IT von Geräten, Kabeln, der Telekommunikation und der Software abhängt, sind die Menschen für das Design, den Aufbau und den Betrieb verantwortlich. Die Parade der menschlichen Fehler beginnt mit der Phantasie über die von den Vertriebsmenschen der Hersteller angepriesenen neuen Geräte. Dies ist kein besonders neues Phänomen. Jeder hat sicher schon IT-Geräten gekauft bzw. benutzt, die nie wirklich funktioniert haben und daher irgendwann einmal den Heldentod gestorben sind.
Mit steigender Komplexität der Systeme treten jedoch viel heimtückischere Fehler auf.
Beispielsweise hat ein bekannter SAN-Hersteller kürzlich eine neue Firmware für sein Flaggschiff der Storage-Produkte veröffentlicht. Die Firmware unterstützte eine Reihe von sehr coolen Features und alle Welt wartete auf deren Veröffentlichung. Am Tag der ersten Implementation stürzten die Speicher- Arrays reihenweise ab und verloren zudem auch noch Kundendaten. Ohne die entsprechenden Insider-Infos kann man über den aufgetretenen Fehler nur Mutmaßungen anstellen, aber für den Experten ist klar, der Hersteller hat seinen neuen Release nicht genügend getestet. Da auch die von den Herstellern angebotenen Lösungen immer komplexer werden, müssen die jeweiligen Produkte entsprechend geprüft und in allen erdenklichen Szenarien getestet sein. So weit die Theorie. In der Praxis erschwert die Vielfalt der Einsatzszenarien der Produkte natürlich die notwendige Qualitätssicherung durch die Hersteller.
Das soll nicht heißen, dass der Kunde bei jedem Software-Upgrade mit einem Ausfall der Systeme rechnen muss, aber für den Einsatz einer neuen Software sollte dies unbedingt ins Kalkül gezogen werden. In den guten alten Zeiten, verfügte man in der IT nur über Speicherprodukte, die von vertrauenswürdigen Unternehmen stammten. Mussten neue I/O-Karten oder ein neues Laufwerk installiert werden, stand der IT-Abteilung ein gut ausgebildeter Support-Techniker zur Verfügung, der eventuelle Fehler schnell und kompetent beheben konnte. Heute steht einem nur noch der Telefon-Support der Hersteller zur Verfügung und der Anrufer freut sich bereits, wenn der Supporter am anderen Ende der Telefonleitung: 

1. fließend Englisch spricht

2. etwas von Technik versteht und

3. etwas zu dem aufgetretenen Fehler sagen kann.

Letztlich ist es egal, wie gut das Produkt ist - wenn es nicht richtig implementiert ist, stehen die Chancen gut, dass es über kurz oder lang abstürzen oder schlechte Leistungen erbringen wird. Je höher die Komplexität der Systeme wird, umso wahrscheinlicher werden fehlerhafte Implementierungen. Durch umfassende Tests und die richtigen Prüfungen lassen sich die meisten Fehler vor der Produktivphase ausmerzen. Welche IT-Abteilung plant heute noch solche Testprozeduren ein? Welche IT-Abteilung verfügt heute noch über das notwendige Budget und die Technikerressourcen um die notwendigen Tests durchführen zu können? Die Erfahrungen zeigen, dass genau im Bereich des Testens viele Fehler gemacht werden und deshalb die ursächlichen Gründe für Ausfälle aller Art sind. Da oft das Geld fehlt, um die notwendigen Tests durchführen zu können, müssen die IT-Abteilungen mit immer weniger Ressourcen mehr Aufgaben bewältigen. Die Geschäftsprozesse erfordern immer mehr Funktionen in immer kürzeren Abständen und diesem Druck kann sich die IT nicht entziehen. Die notwendigen Tests und die regelmäßige Wartung bleiben dabei auf der Strecke und führen zwangsläufig zu Systemausfällen.

Gegen diese Zwangsläufigkeit kann man sich oft nicht wehren. Daher sollte sich die IT-Abteilung unbedingt auf das Testen der Systeme und Komponenten verlegen. Man prüft die Anlagen so oft und so gut wie man es innerhalb des vorgegebenen Budgets (Zeit, Geld, Know-how) zu leisten vermag: Backups Failover Cluster, redundante Switches und SAN-Snapshots. Wenn sich das Unternehmen schon kaputt sparen möchte, dann sollten die vorhandenen Systeme trotzdem einwandfrei arbeiten. Man achtet darauf, dass man nicht unter idealen Bedingungen testet - nicht zuerst das gesamte System auf Funktion überprüfen, bevor es getestet wird. In der Praxis bei einem echten Ausfall hat man diesen Luxus auch nicht. Man zieht einfach den Stecker und wartet ab, was passiert. Eigentlich sollte die Backup-Funktion automatisch eingreifen und das System am Lebe halten. In der Realität wird man nach dem Crash des Systems feststellen, dass die Redundanzfunktionen einfach nicht so arbeiten wie sie sollen.
Natürlich ist es das Verschulden der Manager, dass die notwendige Zeit zum Testen der Systeme nicht mehr vorgesehen wird. Von der IT-Abteilung wird trotzdem eine extrem hohe Verfügbarkeit der IT-Systeme und Services verlangt. Aus diesem Grund muss man dem Management klar machen, dass auch die Failover-Systeme nicht immer einwandfrei funktionieren und ein Systemversagen im Bereich des Möglichen liegt. Dadurch macht man sich als IT-Verantwortlicher nicht unbedingt beliebter. Aber diese Vorgehensweise ist verdammt viel besser, als vor die Tür gesetzt zu werden, weil die verantworteten Failover-Systeme wieder einmal nicht richtig funktionieren.

Natürlich stehen wir alle unter erheblichen Druck und müssen die Projekte so schnell wie möglich abschließen. Das sollte uns jedoch nicht daran hindern eine sorgfältige und präzise Arbeit abzuliefern! Oder macht sich der grundsätzliche Mangel an grundlegendem technischen Verständnis der IT-Branche langsam breit und kein Techniker will mehr verstehen wie die Dinge wirklich funktionieren?

Vor ein paar Tagen machte ich mich in einigen Foren auf die Suche nach Praxiserfahrung zum Thema „Beschleunigung von virtuellen Desktop-Sitzungen über WAN-Verbindungen“. Das von meinem Kunden eingesetzte ICA-Protokoll für Citrix VDI-Lösung nutzte standardmäßig eine Komprimierung und eine Verschlüsselung. Die Hersteller von WAN-Optimierungsboxen empfehlen jedoch in ihren Handbüchern das Ausschalten dieser Funktionen, damit die WAN-Optimierer die eigenen Kompression nutzen können. Für beide Varianten sind einschlägige Vor- und Nachteile bekannt. Da es mir um hauptsächlich um den Betrieb und die Wartungsfähigkeit dieser Lösungen ging, wollte ich von Gleichgesinnten deren Praxiserfahrungen ergründen.

Durch meine Internet-Recherchen kam ich natürlich wieder vom Hölzchen zum Stöckchen und wurde vom eigentlichen Thema abgelenkt. Ich suchte nach den ICA-Port-Nummern und landete in einer Diskussion um Firewalls. Ein Teilnehmer der Diskussionsrunde konnte seine VDI-Sessions nicht aktivieren. Die Antwort eines Diskussionsteilnehmers verblüffte mich: "Es sollte funktionieren, wenn du auf der Firewall die Ports 1494, 2598 und 1604 aufmachst. Eventuell zusätzlich noch die Ports 2512 und 2513 und vielleicht noch 2897".

Staunend folgte ich der Diskussion, bis ich einen radikalen Vorschlag machte: „Wie wäre es mit einer Suche auf dem Firewall-Log? Hier kann man sehr schnell erkennen, welcher Port gesperrt ist.“ Oder noch schlimmer: „Nutzt doch einfach einen Netzwerk-Analysator und sucht nach den aktuell genutzten Ports (und Adressbereiche) des VDI-Verkehrs! Oder versucht doch erst einmal zu verstehen, welche Ports überhaupt genutzt werden“ Für die normale Kommunikation – einer ICA-Sitzung wird beispielsweise der Port 1494 genutzt. Wird CGP für die Session Zuverlässigkeit aktiviert, dann ändert sich der Port auf 2598. Anstatt sämtliche Ports auf der Firewall zu öffnen, die irgendetwas mit ICA zu tun haben, sollte man herausfinden, welche Ports für die ordnungsgemäße Kommunikation geöffnet werden müssen. Aber wahrscheinlich ist diese Frage bereits zu speziell und die wenigsten Techniker werden die Hintergründe dieser Aussage noch verstehen.

Je mehr Regeln auf einer Firewall festgelegt wurden, je mehr Arbeit hat die Firewall zu verrichten. Gleichzeitig steigt natürlich auch die Möglichkeit, dass Fehler in die Regeln eingeschlichen haben. Je mehr Ports in der Firewall geöffnet sind, desto unsicherer wird das Abwehrbollwerk gegenüber der Außenwelt. Aus meiner Sicht zeugt ein solches Vorgehen von einer schlampigen Arbeitshaltung. Sind alle Ports auf der Firewall geöffnet, dann bekommt man schnell seine Anwendung ans Arbeiten, aber man untergräbt gleichzeitig die Sicherheit des Unternehmens. Ich kenne einige Unternehmen (ich habe die Konfigurationen kontrolliert) die in ihren Cisco-Firewallregeln die folgende unsterbliche Zeile eingraviert haben: "permit ip any any ". Genauso könnten die IT-Administratoren die Firewall über eBay verkaufen. Neben einigen Zusatzeinnahmen hätte das Unternehmen den zusätzlichen Vorteil, dass die Cisco-Box keinen Strom mehr verbrauchen würde. Die Begründung für diese Regel lieferte mein Lieblingsadministrator: „Die früheren Regeln waren zu lang und kompliziert. Wir hatten immer Probleme mit den Anwendungen. Seit der Regeländerung klappt die Kommunikation immer.“

Ein anderes Unternehmen hatte ebenfalls Probleme seine Anwendungen durch die Firewall zu schleusen. Die Administratoren hatten keine Ahnung, welche Ports die Anwendung nutzten. Aus diesem Grund konfigurierten die „IT-Experten“ einen Tunnel zwischen den beiden Routern auf beiden Seiten der Firewall. Damit tunnelten sie den gesamten Verkehr durch die Firewall. Dass damit sämtliche Sicherheitsregeln der Firewall ausgehebelt wurde störte nicht, denn die Experten waren richtig stolz auf die clevere Problemlösung.
Vor so viel Ideenreichtum musste ich meinen Hut ziehen. Leider machte ich den IT-Exerten folgen Verbesserungsvorschlag: Anstatt des Tunnels und der Firewall schlug ich vor, diese durch ein einfaches Kabel zwischen zwei Routern zu ersetzen. Ich hätte es wissen müssen, dieser Verbesserungsvorschlag ruinierte meine Reputation. Wortreich wurde mir von den IT-Experten erklärt, dass mein Vorschlag nicht die gleichen Sicherheitsfunktionen bieten würde wie ihre Lösung.

Liegt es am Zeitgeist, dass die Experten über immer weniger Detailwissen verfügen oder sind die Beispiele nur ein Zeichen dafür, wie sehr die IT-Experten unter Druck stehen? Der Job muss so schnell und so kostengünstig wie möglich erledigt werden. Der Zweck heiligt die Mittel! Sicherlich waren früher mehr Techniker mit fundiertem Wissen unterwegs und lieferten besser Arbeiten ab. Trotzdem sollte man sich die Zeit nehmen und eine gute Arbeit abliefern, besonders dann, wenn es um die Sicherheit des Unternehmens geht. Sollten die IT-Experten mangels Wissen nicht in der Lage sein, ihre Arbeiten ordnungsgemäß zu erledigen, dann sollten sie ein Fachbuch zur Hand nehmen und das fehlende Fachwissen erarbeiten. Wissen ist Macht und zahlt sich besonders im IT-Bereich aus!