IT-Diagnostik.de ist ein Blog, in dem es um typische Methoden des Troubleshootings für alle Arten von Computer- und Netzwerkproblemen geht. Angelehnt an den Diagnostikbegriff aus der Medizin, der alle Vorgehensweisen zur Findung der richtigen Diagnose (die wiederum die Grundlage für eine erfolgreiche Behandlung des Patienten ist) umfasst, entstand die Idee zu diesem Blog.

“Patienten” bei der IT-Diagnostik sind Computer, Netzwerke und die Menschen, die IT-Systeme benutzen. Gerade die Kombination vieler verschiedener Komponenten zu einem großen System macht die Fehlersuche (das Troubleshooting) oft schwierig.

IT-Diagnostik.de verfolgt das Ziel, gängige Troubleshooting-Methoden zu beschreiben, diese anhand praktischer Fälle zu illustrieren und somit Computernutzern und Systemadministratoren das Leben zu erleichtern.

So ziemlich jedes technische System kann redundant ausgelegt werden. Festplatten werden zu RAID-Verbünden zusammengefasst, so dass beim Ausfall einer Platte die Daten nicht verloren sind und die Computer weiter laufen. In Servern schlummern mindestens zwei Netzteile, um den unterbrechungsfreien Betrieb zu gewährleisten. Diese hängen nach Möglichkeit an unterschiedlichen Stromnetzen, um selbst für einen möglichen Stromausfall gewappnet zu sein. Den schlimmsten aller Fälle – es gibt wirklich keinen Strom mehr – puffern USVs. An ihr hängende Server werden beim Stromausfall kontrolliert heruntergefahren.

Größere Firmen verfügen selbstverständlich über mehr als einen Internetanschluss, um bei Providerproblemen nicht von der Außenwelt abgeschnitten zu sein. In so genannten Clustern werden Systeme (z. B. Mail-Server oder Datenbank-Server) zu einem übergeordneten System zusammengefasst, das bei Ausfall des Hauptknotens durch ein automatisches Umschalten auf den Failoverknoten unterbrechungsfrei weiter läuft. SQL-Datenbanken lassen sich durch Spiegelung redundant auslegen – der Spiegelserver bekommt jede Änderung der Datenbank in Echtzeit mit und kann im Fehlerfalle einspringen, automatisch oder manuell. Im Citrix-Umfeld werden einfach viele gleichartige Server parallel betrieben, die sich die Last teilen.

Nicht nur bei Servern, auch im Netzwerk an sich ist die Redundanz ein großes Thema. Gebäude werden nicht nur über eine Leitung miteinander verbunden. Der Backup-Pfad ist ganz selbstverständlich. Und schließlich gibt es ganze Backup-Rechenzentren. Falls das Hauptrechenzentrum komplett ausfallen sollte, muss das Backup-Rechenzentrum die Aufgaben des Hauptrechenzentrums komplett übernehmen können.

Generell lassen sich zwei Arten von Redundanz feststellen:

1. Load Balancing: Hier teilen sich mehrere Systeme die Arbeit. Beim Ausfall eines Systems übernehmen die verbliebenen Systeme die Arbeit. Vorteil: Alle Systeme sind ständig in Benutzung, das Funktionieren der Redundanz ist somit automatisch gewährleistet. Nachteil: Bei einem Systemausfall steigt die Last für die verbliebenen Systeme, was sich auch für den User in schlechterer Performance bemerkbar macht. Beispiel: Citrix XenApp – Load Balancing, RAID1 (Spiegelung) bei Festplatten.

2. Failover: Hier gibt es ein Haupsystem, das in der Regel seine Arbeit verrichtet. Bei dessen Ausfall wird das Backup-System aktiv. Das Umschalten (Failover) wird von einem übergeordneten System durchgeführt. Vorteil: Wenn der Failover-Prozess reibungslos funktioniert, merkt der User in der Regel nichts davon, dass das Hauptsystem ausgefallen ist und verfügt weiterhin über volle Rechenleistung. Automatisierte Failover-Mechanismen können zudem schneller reagieren als jeder Admin. Nachteil: Durch die notwendigen Failover-Mechanismen steigt die Komplexität des Gesamtsystems. Da das Backup-System in der Regel nicht unter Last steht, ist auch die Wahrscheinlichkeit eines unerkannten Defekts des Backup-Systems höher.

Redundanz birgt Gefahren. Bei Failover-Systemen sind diese höher als bei Load-Balancing-Systemen. Ein Load-Balancing-System ist robust gegen Ausfälle einer Komponente (z. B. einer Festplatte im RAID). Nur durch konsequentes Monitoring der “Gesundheit” des redundanten Systems kann die Fehlertoleranz aufrecht erhalten werden (z. B. durch den Austausch einer defekten Festplatte). Failover-Systeme können es besonders in sich haben. Oftmals funktioniert der Failover-Mechanismus ganz hervorragend, es ist aber aus Sicherheitsgründen ein manuelles Failback notwendig. Wenn nun niemand überhaupt mitbekommen hat, dass ein automatisches Failover stattgefunden hat, ist das Gesamtsystem ab diesem Zeitpunkt nicht mehr redundant! Einen Fehler am Backup-System merkt der User nun sofort. Ebenfalls nicht redundant ist ein System dann, wenn aur irgend einem Grund der Failover-Mechanismus nicht funktioniert.

Die Redundanz ist ein wichtiges Verkaufsargument im IT-Bereich. Die Aussage: ”Das Backup-System übernimmt im Fehlerfalle automatisch die Funktion des Hauptsystems” ist allerdings eine sehr starke Vereinfachung. Mit der Redundanz kauft man sich die Pflicht, das Gesamtsystem im Auge zu behalten, sich bei Fehlern oder automatischen Failover-Aktionen alarmieren zu lassen und regelmäßig die Funktion der Redundanz praktisch zu testen.

Nicht zuletzt sollte auch gewissenhaft geprüft werden, ob nicht doch noch ein Single Point of Failure im Gesamtsystem vorhanden ist.  Mit der Redundanz steigt immer die Komplexität des Gesamtsystems. Diese gilt es zu beherrschen. Ein Troubleshooting einer defekten Komponente, während der IT-Betrieb weiterläuft, ist für den Admin aber auf jeden Fall die beste und stressärmste Situation. Er sollte deshalb stets dafür sorgen, dass Redundanz vorhanden ist und funktioniert.

Davon ausgehend, dass die Initialeinrichtung des NAS (IP-Adresse zuweisen, RAID-Level einstellen, Benutzer und Gruppen erstellen, Zugriffsrechte definieren, …) bereits erledigt ist, sind es nur wenige Schritte, bis wir unsere virtuellen Maschinen auf das NFS-Dateisystem sichern können. Zunächst muss das NFS-Protokoll erst einmal grundsätzlich auf dem NAS aktiviert werden. Unter dem Menüpunkt “System Network=>NFS” ist dies möglich.

Der nächste Schritt ist das Anlegen eines Ordners, der über NFS freigegeben werden soll. Unter “Storage=>Share Folder” wird mit “Add” ein neuer Ordner angelegt. Die Berechtigungen, die auf diesem Ordner vergeben werden, sind eigentlich irrelevant, denn der NFS-Zugriff erfolgt Host basiert, d. h. eine IP-Adresse hat entweder Zugriff auf die Freigabe oder nicht. Mit Klick auf den Button NFS können Hosts (IP-Adressen) eingetragen werden, die Zugriff auf die NFS-Freigabe erhalten sollen. Der ESXi-Host benötigt natürlich Schreibrechte. Die Vorbereitungen für das Einbinden der NFS-Freigabe im ESXi-Server sind nun getroffen.

Bug in Firmware V3.00.06 des Thecus N2200:

Bevor die NFS-Freigabe erfolgreich gemountet werden kann, ist es erforderlich, den NFS-Dienst auf dem Thecus zu stoppen und wieder zu starten. Sobald Änderungen an der NFS-Konfiguration vorgenommen wurden, ist dieser Schritt zu tun.

Die NFS-Freigabe kann nun im ESXi-Host eingebunden werden. Unter “Konfiguration=>Speicher” klickt man auf “Speicher hinzufügen”. Die Wahl fällt auf “Netzwerkdateisystem (NAS)”. Als “Server” wird die IP-Adresse des NAS eingetragen. Im Feld “Ordner” muss der vollständige Pfad zur NFS-Freigabe hinterlegt werden. Dieser wird im Thecus-NAS unter den NFS-Einstellungen angezeigt. Allerdings muss das nicht stimmen. Loggt man sich per FTP auf dem NAS ein und schaut sich die Eigenschaften der NFS-Freigabe an, sieht man den richtigen Pfad. In meinem Fall war das:

/raid0/data/[nfs-freigabename].

Als “Datenspeichername” kann nun noch eine beliebige Bezeichnung eingetragen werden. Unter dieser erscheint die NFS-Freigabe dann im ESXi-Server. Dem Backup der virtuellen Maschinen auf das NAS steht nun nichts mehr im Wege.

Wie schon im Artikel Troubleshooting von Druckerproblemen beschrieben, ist es auch beim Troubleshooting von E-Mail-Problemen wichtig, die beteiligten Teilsysteme und die Wege, die eine E-Mail vom Sender zum Empfänger nimmt, genau zu kennen. Typische Teilsysteme, die beim Versenden und Empfangen von E-Mails in einer Microsoft-Umgebung zusammenspielen, sind:

• Outlook-Client
• Exchange-Server
• Mail-Gateway / SMTP-Smarthost / SMTP-Relay-Server
• Spam-Filter

Bei E-Mail-Problemen (d. h. eine Nachricht, die A abschickt, kommt nicht bei B an) hat es sich für den Administrator bewährt, sich selbst in die Lage der E-Mail zu versetzen und schrittweise die beteiligten Systeme zu durchlaufen. Dabei werden Informationen gesammelt, die anschließend analysiert werden.

Systematisches Vorgehen beim E-Mail-Troubleshooting:

• Zunächst sollte versucht werden, einem internen Teilnehmer eine E-Mail zu schicken, um eine Fehlkonfiguration des Exchange-Servers  auszuschließen.
• Gelingt der Versand einer E-Mail an einen internen Teilnehmer, kann davon ausgegangen werden, dass die Kommunikation zwischen Outlook-Client und Exchange-Server funktioniert.
• Über eine Telnet-Sitzung kann direkt über das Mail-Gateway bzw. den SMTP-Smarthost eine E-Mail verschickt werden. Funktioniert dies, sollte die Schnittstelle zwischen Exchange-Server und Mail-Gateway genauer untersucht werden.
• Schließlich kann über eine Telnetsitzung auch direkt eine E-Mail in den Mail-Server des Empfängers eingeben werden (Hostname bzw. IP-Adresse des Empfängerservers ergeben sich aus den MX-Einträgen der Empfängerdomain). Bringt diese Verfahrensweise Erfolg, hat liegt vermutlich ein Problem mit dem Mail-Gateway vor.

Sammeln von Informationen:

• Nachricht selbst: Header-Informationen
• Outlook-Client: Fehlermeldungen des Clients, Windows-Eventlogs
• Exchange Server: Exchange-Logs, Message Tracking Center, Windows Eventlogs
• Mail-Gateway: Server-Logs

Oft sind vermeintliche E-Mail-Zustellungsprobleme lediglich Effekte der Spamfilterung oder des Virenschutzes. Beispielsweise können Nachrichten teilweise mehrere Stunden verzögert eintreffen, wenn das Greylisting-Verfahren zur Spamfilterung eingesetzt wird. Fehlende Anhänge sind oft im MIME-Filter des Mail-Gateways zu finden.

Über Echo-Mails (z. B. an echo@tu-berlin.de) lässt sich auf schnelle und einfache Weise prüfen, ob alle beteiligten Systeme korrekt zusammenarbeiten.

Ein Grund dafür könnte sein, dass Drucken ein Prozess ist, der sich über fünf oder mehr Systeme erstrecken kann: In einer Citrix-Umgebung mit Netzwerkdruckern beispielsweise wären das der Benutzer selbst, der Client-Computer, der Citrix-Server, der Druckserver und nicht zu vergessen der Drucker.

Beim Troubleshooting von Druckerproblemen ist deshalb die Identifizierung des fehlerhaften Systems besonders entscheidend. Durch die Ausschlussmethode kann man der Ursache schnell auf den Grund kommen. Fragen, die zur Lösung führen, sind folgende:

• Hat ein anderer Benutzer bei Anmeldung über den gleichen Client-Computer am gleichen Citrix-Server bei Benutzung des gleichen freigegebenen Druckers auch Probleme? Wenn ja, kann der Benutzer als Fehlerquelle ausgeschlossen werden. Wenn nein, handelt es sich höchstwahrscheinlich um ein Profilproblem.
• Hat der betroffene Benutzer bei Anmeldung über einen anderen Client-Computer am gleichen Citrix-Server bei Benutzung des gleichen freigegebenen Druckers auch Probleme? Wenn ja, kann der Client-Computer als Fehlerquelle ausgeschlossen werden. Wenn nein, ist der Fehler im Client-Computer zu suchen.
• Hat der betroffene Benutzer bei Anmeldung über den gleichen Client-Computer am gleichen Citrix-Server bei Benutzung eines anderen freigegebenen Druckers auch Probleme? Wenn ja, kann der Drucker bzw. die Druckerkonfiguration als Fehlerquelle ausgeschossen werden. Wenn nein, sollte der Drucker genauer untersucht werden.
• Hat der betroffene Benutzer bei Anmeldung über den gleichen Client-Computer am gleichen Citrix-Server bei Benutzung des gleichen Druckers, der aber über einen anderen Druckserver freigegeben ist, auch Probleme? Wenn ja, kann der Druckserver als Fehlerquelle ausgeschlossen werden. Wenn nein, sollte der Administrator prüfen, ob die Einstellungen auf dem Druckserver für den betroffenen Drucker korrekt sind.

Entscheidend für das Troubleshooting ist, systematisch vorzugehen, schrittweise das Problem zu isolieren und nach und nach  durch die Ausschlussmethode die funktionierenden Teilsysteme als Fehlerquelle auszuschließen. So kommt man dem Rätsel mit Sicherheit auf die Spur. Wichtig: Immer nur eine Variable ändern!

In Windows-Netzwerken haben sich zudem die folgenden Vorgehensweisen bei der Administration von Druckern und Druckservern bewährt:

• IP-Adressen in den TCP/IP-Ports auf dem Druckserver niemals mit führenden Nullen eingeben!
• Niemals einen Netzwerkdrucker einfach durch einen anderen mit gleicher IP-Adresse ersetzen! Besser ist, den freigegebenen Drucker inklusive Port auf dem Druckserver zu löschen und für den neuen Drucker neu zu erstellen.
• Die Druckertreiber, die auf dem Druckserver und auf Clientrechnern (bzw. Citrix-Servern) verwendet werden, müssen unbedingt identisch sein!

Das Prinzip der Monitoring-Tools ist einfach. Es handelt sich im Prinzip um ständig aktive Netzwerkagenten, die alle im Netzwerk befindlichen Systeme auf die unterschiedlichsten Arten ansprechen können. Der Hostmonitor beherrscht 62 Testmethoden wie Ping, Website-Erreichbarkeits-Check, DNS-Abfrage oder Prüfung des verfügbaren Speicherplatzes auf einer Netzwerkfreigabe. Bei erkannten Fehlern ist die Benachrichtigung des Admins per E-Mail oder SMS möglich.

Mit einem guten Testkonzept bekommt der Systemadministrator Fehler im Netzwerk schneller mit als jeder Benutzer und kann im Idealfall das Problem lösen, bevor der erste Anruf den Helpdesk erreicht.

Prinzipiell sollte jedes produktive System automatisiert getestet werden. Das mindeste bei einem Server ist ein regelmäßiger Ping-Test, der feststellt, ob der Server im Netzwerk erreichbar ist. Dieser Test kann alle 10 Minuten ausgeführt werden. Zudem ist es ein guter Gedanke, die wichtigsten Dienste kritischer Server testen zu lassen. Manche Dienste haben auch die Eigenheit, alle paar Tage ohne Vorwarnung auszufallen. Das Netzwerkmonitoring-Tool kann das nicht nur erkennen, sondern den Dienst auf Wunsch sogar automatisch neustarten.

Um zu gewährleisten, dass die Netzwerküberwachung zuverlässig funktioniert, sollte das Monitoring-Tool auf einer eigenständigen Hardware betrieben werden. Durch ein direkt am Monitoring-System angeschlossenes Handy, das SMS-Benachrichtigungen versendet, hat man die größtmögliche Unabhängigkeit von den Produktivsystemen (zum Beispiel einem SMTP-Relay-Server für E-Mail-Benachrichtigungen).

Mit einem Netzwerkmonitoring-Tool kann sich der Systemadministrator die Arbeit wesentlich erleichtern. Ein Blick auf einen grünen Überwachungsbildschirm wirkt immer beruhigend. Kenngrößen des Netzwerkes (wie freier Festplattenplatz) können zudem als Report ausgegeben werden.

Der Systemadministrator sollte sich nach jedem außerplanmäßigen Troubleshooting fragen, ob es für diese Situation nicht einen Test im Monitoring-Tool gibt. Oft genug ist das der Fall, und die Verfügbarkeit aller Systeme ist damit wieder ein Stückchen gestiegen.

Gängige VPN-Router bieten normalerweise die Möglichkeit der Fernwartung, das heißt, auch ohne bestehende VPN-Verbindung kann über HTTPS oder SSH auf den Router zugegriffen werden. So können bequem Wartungsarbeiten am VPN durchgeführt werden, oder ein Troubleshooting bei gestörter VPN-Verbindung ist möglich. Aus verschiedenen Gründen kann jedoch auch die Router-Fernwartung unmöglich sein:

• die Internetverbindung am entfernten Standort ist nicht verfügbar,
• der VPN-Router am entfernten Standort ist gestört oder
• der Internet-Provider am entfernten Standort erlaubt kein Portforwarding auf den VPN-Router.

Über einen UMTS-Router, der eine Schnittstelle zwischen lokalem Netz (LAN) und dem Mobilfunknetz darstellt, schafft man sich einen zusätzlichen Eintrittspunkt in das Netzwerk des entfernten Standortes. Entscheidend ist, einen UMTS-Router mit Dial-In-Funktion zu verwenden. Man kann dann das Gerät einfach im Bedarfsfall anrufen und zahlt nur die tatsächlich angefallenen Verbindungskosten. Ein Gerät, welches die Dial-In-Funktion beherrscht, ist beispielsweise der MoRoS mobile der Firma Insys.

Die Vorteile dieser Lösung liegen klar auf der Hand:

• Unabhängigkeit vom Internetprovider am entfernten Standort,
• Unabhängigkeit vom VPN-Router am entfernten Standort und
• Gebühren für das übertragene Datenvolumen fallen nur im Bedarfsfall an.

Ein Test des MoRoS verlief sehr zufriedenstellend. Über eine DFÜ-Verbindung (zum Beispiel mit Modem oder ISDN-Karte) konnte problemlos der Kommunikationskanal zum entfernten Netz hergestellt werden, und der Zugriff auf alle Geräte im LAN war möglich.

Leider wird sowohl im MoRoS-Datenblatt als auch in der Anleitung nicht erwähnt, dass es eine spezielle Anforderung an die verwendete SIM-Karte gibt: Diese muss vom Provider für eingehende CSD-Datenanrufe freigeschaltet werden, sonst tut sich gar nichts. Meist bekommt man bei dieser Freischaltung eine zusätzliche Rufnummer für Datenanrufe. Nur damit funktioniert dann der Aufbau der DFÜ-Verbindung. Diese Information kam wenige Stunden nach Kontaktaufnahme per E-Mail mit dem Insys-Support zurück – so muss es sein!