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.

Voraussetzung, damit das ganze funktioniert, ist der Internet Explorer 8 oder die neueste Version von Mozilla Firefox oder Google Chrome. Zusätzlich greift Google Instant auf den Adobe Flash Player zu. Auf google.de funktioniert die Sofortsuche nur, wenn der Benutzer mit einem Google-Account angemeldet ist. Ohne Google-Account klappt es nur bei google.com.

Wurde der Autor auf dem heimischen PC vom neuen Feature überrascht, das ohne weitere Einstellungen sofort seine Wirkung zeigte, blieb der Bildschirm beim Eintippen von Suchbegriffen auf dem Arbeitsplatz-PC zunächst weiß. Ursache der Fehlfunktion: Der vorgeschaltete Squid-Proxy! Bei Umgehung des Proxys funktionierte auch hier Google Instant sofort.

Hat jemand eine Idee oder einen Hinweis, wie Google Instant auch mit vorgeschaltetem Proxy zum Laufen gebracht werden kann? Bin für jeden Kommentar dankbar.

Update 14.09.2010:

Hier nun die Lösung des Problems: Nach dem Update von Squid auf die aktuellste Version 3.1.8 funktionierte Google Instant auf Anhieb!

 In diesem Artikel geht es um die klassische Datensicherung, also das Kopieren von Daten auf ein separates Medium. RAID-Systeme (z. B. Festplattenspiegelung) können zwar die Verfügbarkeit von Systemen erhöhen, sie als Datensicherungsmethode aufzuführen, ist jedoch schlicht falsch – denn was nützen einem gespiegelte, aber korrupte Daten?

1. Sicherung von Nutzdaten

Bei reinen Fileservern ist es meist ausreichend, nur die Nutzdaten zu sichern. Dabei werden die Daten von einem Backup-Tool auf ein anderes, möglichst räumlich entferntes System kopiert. Meist ist auf dem zu sichernden Server ein so genannter Backup-Agent aktiv. Voraussetzung für den Erfolg dieser Backup-Methode ist, dass die nicht gesicherten Daten (also das Betriebssystem) schnell wieder hergestellt werden können. Sobald jedoch eine umfangreiche Betriebssystemkonfiguration vorliegt, muss auf eine vollständige Sicherung zurückgegriffen werden.

Vorteil: Das Kopieren der Nutzdaten ist eine einfache und wirkungsvolle Backup-Methode. Sie funktioniert problemlos auch ohne teure Backup-Software und Agent.

2. Vollständige Sicherung

Mühevoll eingerichtete Computersysteme sollten stets vollständig gesichert werden. Auch das ist prinzipiell per Agent möglich. Nachteil dabei: Falls eine Wiederherstellung notwendig wird, müssen zunächst ein blankes Betriebssystem installiert und der Backup-Agent aktiviert werden. Eine langwierige und Fehler anfällige Backup-Methode.

3. Sicherung von einer höheren Ebene aus

Da letztendlich die Festplatte Träger aller Informationen (Betriebssystemkonfiguration und Nutzdaten) ist, liegt der Gedanke nahe, zu Backup-Zwecken ein vollständiges Backup der Server- oder PC-Festplatte zu erstellen. Dies ist mit Imaging-Tools möglich. Innerhalb kürzester Zeit kann ein komplettes Festplattenabbild erzeugt werden. Auch die Wiederherstellung so gesicherter Systeme gestaltet sich als problemlos. Bei Rücksicherungen auf abweichende Hardware sind jedoch Inkompatibilitäten möglich.

Besonders einfach können die Festplatten virtueller Maschinen gesichert werden. Nach der Erstellung eines Snapshots werden die vmdk-Dateien kopiert.  Dementsprechend einfach ist auch die Wiederherstellung: VM-konfigurationsdatei und Festplattendatei werden zurückkopiert, die Maschine registriert und gestartet. Für das ESX- oder ESXi-Backup existieren kostenlose und kostenpflichtige Tools.

Prinzipiell ist die Sicherung von einer höheren Ebene aus immer anzustreben, da somit die Art und Einrichtung des Betriebssystems keine Rolle spielt. Diese Backup-Methode deckt alle Arten von Systemen gleichermaßen ab und ist einfach zu handhaben.

Aber auch die klassische Sicherung durch direktes Kopieren hat ihre Berechtigung. Sie kann performanter sein, wenn der Anteil der Nutzdaten am gesamten Festplattenvolumen sehr klein ist. Vorteile bieten sich auch bei der Wiederherstellung einzelner Dateien.

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.

Kaum jemand weiß, dass es den ESXi in zwei Varianten gibt. Die frei zugängliche Version kann nur “standalone” betrieben werden. Will man mehrere ESXi-Server mit dem vCenter zentral verwalten, kommt man um den Kauf einer ESXi-Lizenz nicht herum.

In diesem Artikel sollen beleuchtet werden, welche Möglichkeiten es gibt, die virtuellen Maschinen auf einem einzeln stehenden ESXi-Server zu sichern. VMware verbietet Anbietern kommerzieller Backup-Lösungen, Sicherungen von virtuellen Maschinen auf solchen Hosts zu ermöglichen.

Auch beim Betrieb von virtuellen Maschinen ändern sich die grundlegenden Fragen, die man sich bei der Bereitstellung einer Backup-Lösung stellt, nicht. Ein Backup sollte so oft wie möglich, so zuverlässig wie möglich und automatisch stattfinden. Das Backup sollte räumlich getrennt von den Produktivsystemen erstellt werden, und die Produktivsysteme dürfen durch das Backup in ihrer Funktion nicht beeinträchigt werden. Eine Wiederherstellung, vollständig oder auch nur partiell, muss einfach sein. Ebenso einfach sollte die Erweiterung des Backup-Konzeptes sein.

Es folgt die Beschreibung der absoluten Low-Cost-Variante für virtuelle Maschinen auf ESXi-Hosts. Die räumliche Trennung erreicht man durch den Einbau einer zusätzlichen Festplatte in den ESXi-Host. Auf dieser Platte werden nur Backups gespeichert.

Das frei verfügbare Backup-Script Ghettovcb besteht aus zwei Dateien: zum einen aus dem eigentlichen Script, das nur wenige Einstellungen erfordert. In einer zweiten, reinen Textdatei werden alle zu sichernden virtuellen Maschinen aufgelistet. Somit ist auch eine einfache Erweiterbarkeit gewährleistet. Sobald eine neue VM gesichert werden soll, wird einfach die Textdatei um eine Zeile erweitert.

Ghettovcb funktioniert, wie übrigens alle Systeme, die virtuelle Maschinen sichern, nach dem folgenden Prinzip: Zunächst wird ein Snapshot der VM erstellt, das heißt, die aktuelle VMDK-Datei wird “eingefroren” und alle Änderungen ab dem Zeitpunkt des Snapshots fließen in eine Delta-Datei. Somit ist ein einfaches Kopieren der VMDK-Datei im laufenden Betrieb möglich. Die Anforderung der Nichtbeeinträchtigung von Produktivsystemen ist somit auch erfüllt.

In den Ghettovcb-Einstellungen kann definiert werden, wie viele Backup-Versionen vorgehalten werden sollen.Es ist also möglich, immer eine gewisse Zahl von Sicherungen vorzuhalten. Bei einer erfolgreichen Sicherung löscht Ghettovcb die älteste vorhandene Sicherung.

Die automatische Ausführung des Backup-Scriptes ist zum Beispiel mit Plink möglich. Auf einer virtuellen Maschine wird einfach ein geplanter Task eingerichtet, der Ghettovcb so oft wie gewünscht mittels Plink anstößt. Funktioniert das erst einmal, ist auch die Anforderung nach Automatisierung erfüllt.

Die Wiederherstellung einer mit Ghettovcb gesicherten VM ist denkbar einfach. Die Dateien (VMX, VMDK, …) aus dem Sicherungsverzeichnis werden einfach zurückkopiert, die VM wird registriert und eingeschaltet. Auch einzelne Dateien können durch das Mounten der VMDK-Datei, zum Beispiel mit UFS Explorer oder Winimage zurückgespielt werden.

Persönlich kann ich nur Positives über das beschriebene Backup-Konzept berichten. Es funktioniert zuverlässig und ist vollkommen transparent. Sicher ist die Verwendung einer zusätzlichen Festplatte im gleichen Host nur eine Kompromisslösung. Dafür geht die Sicherung aber sehr schnell. Wer über GBit-Netzwerk verfügt, kann auch auf einen räumlich entfernten NFS-Store sichern.

Der IC Kyffhäuser ist der leerste Zug, mit dem ich seit Jahren gefahren bin. Er startet freitags in Frankfurt, fährt über Hanau, Fulda und Kassel in Richtung Eichsfeld. Mit Heiligenstadt, Leinefelde und Nordhausen passiert er die wichtigsten Städte in Nordthüringen. Die Reise geht weiter über Sangerhausen und Halle nach Leipzig. Sonntags fährt der IC Kyffhäuser genau entgegengesetzt.

In meinem Wagen sitzen genau fünf Leute. In den anderen Wagen sieht es nicht anders aus. Mir scheint fast, dass mehr Zugpersonal mitfährt als Fahrgäste. In Zeitungsartikeln liest man, dass der IC Kyffhäuser zunächst für zwei Jahre eingeplant ist. Nur wenn die durchschnittliche Auslastung zufriedenstellend ist, wird dieser Zug weiterhin fahren.

Bei diesem Nutzungsverhalten kann ich mir kaum vorstellen, dass der IC Kyffhäuser eine Zukunft hat. Ich bin jedoch sehr zufrieden mit der Einführung, komme ich doch entspannt und günstig in die Heimat. Das kommende Wochenende wird zeigen, ob die Fahrgastzahlen am letzten Freitag nur eine Ausnahme waren. Über die Auslastung des IC Kyffhäuser am Sonntag werde ich in einem der folgenden Artikel berichten.

Es hilft nichts, der Troubleshooter ist nun gefragt. Am Anfang jedes Troubleshootings steht eine umfassende Bestandsaufnahme der Problematik:

• Wie äußert sich das Problem?
• Welche Systeme oder Teilsysteme sind betroffen?
• Ist nur ein System oder sind mehrere gleichartige Systeme betroffen?
• Ist nur ein Benutzer oder sind mehrere Benutzer, die mit dem gleichen System arbeiten, betroffen?
• Gab es kürzlich Änderungen am betroffenen System?
• Wann ist das Problem zum ersten Mal aufgetreten?
• Ist das Problem beliebig reproduzierbar?
• Gibt es Fehlermeldungen oder lassen sich Informationen aus Log-Dateien ableiten?
• Hat der Benutzer weitere Informationen, bzw. kann er den Prozess, der zum Problem führte, beschreiben?
• Auf welchem Patchlevel (BIOS, Firmware, Betriebssystem, Anwendungen) befinden sich die betroffenen Systeme?

Je sorgsamer und detaillierter der Troubleshooter diese Fragen beantworten kann, um so leichter fällt ihm die Fehleranalyse. Alle gesammelten Informationen fließen beim Troubleshooter zusammen. Aufgrund seiner Erfahrung kann er sich meist einige Fragen schon selbst beantworten. Jedoch sollte er bei der kleinsten Unsicherheit eine Frage lieber zweimal stellen, als dass eine wertvolle Information verloren geht oder dass er aufgrund einer Fehlannahme nicht voran kommt.

Aus den gesammelten Informationen lassen sich Hypothesen ableiten, welche Ursache oder welche Ursachen zum Problem geführt haben könnten. Mit verschiedenen Methoden, die in Teil 2 dieses Artikels beschrieben werden, kann der Troubleshooter nun jede der aufgestellten Hypothesen entweder bestätigen oder widerlegen – so lange, bis das Problem gelöst ist.

Ganz wichtig: Bevor der Troubleshooter aktiv in laufende Systeme eingreift, ist eine Datensicherung des aktuellen Standes angesagt. Nichts ist schlimmer, als wenn sich durch ein Troubleshooting die Gesamtsituation verschlechtert oder ganz und gar Daten verloren gehen. Der Troubleshooter kann mit ruhigem Gewissen seiner Arbeit nachgehen, wenn er jederzeit bereit und dazu fähig ist, auf den Stand der letzten Datensicherung zurückzugehen.

Wird fortgesetzt…

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.