Mit vRealize Log Insight die Problemanalyse beschleunigen

Der Syslog-Server als Werkzeug

Ich schreibe heute über einen Anwendungsfall, der sich in der IT nicht sehr hoher Beliebtheit erfreut. Die Problemanalyse und Forensik in Systemprotokollen. Klingt so sexy wie eine Wurzelbehandlung, oder?

Nahezu jedes System und jede Komponente protokolliert Ereignisse und Warnungen in ein eigenes Log. Die Betonung liegt auf jedes und eigenes, denn darin besteht das Hauptproblem. Die Informationen sind verteilt und nicht einfach zugänglich. Hat man dann endlich alle Logs an einen gemeinsamen Ort kopiert, erfolgt die Analyse in der Regel mit einem Texteditor. Das ist unübersichtlich und mühsam. Muss man beispielsweise Ereignisse auf einem Server und einer aktiven Netzwerkkomponente korrelieren, sind zahlreiche Schritte notwendig um die notwendigen Information verfügbar zu machen. Eine sehr zeitaufwendige Angelegenheit. Im ungünstigsten Fall ist eines der betroffenen Systeme nicht mehr verfügbar, weil eben genau dort ein Fehler aufgetreten ist. Kein Log – keine Analyse. 🙁

„Mit vRealize Log Insight die Problemanalyse beschleunigen“ weiterlesen

VCSA root Partition erweitern

Erste Hilfe bei zu kleiner root Partition einer VCSA

In jüngster Zeit sehe ich immer wieder vCenter Appliances, die nach Reboot nicht alle Dienste starten können. Ein Blick auf die Shell zeigt häufig eine komplett gefüllte root Partition. Man kann mit einigen Tricks etwas Platz schaffen, aber erhält meist keine nachhaltige Lösung. Die VCSA wurde unter Umständen zu klein dimensioniert. Will man das Problem dauerhaft beseitigen, wird man um eine Vergrößerung der root Partition nicht herum kommen. Das klingt zunächst einfach, ist in der Durchführung etwas heikel.

„VCSA root Partition erweitern“ weiterlesen

Veeam Default Repository

System erstickt an Backupdaten – Warum man das Veeam Default-Repository nach der Installation entfernen sollte

Eine typische Veeam Backup & Replication Installation besteht aus verschiedenen Komponenten. Es gibt den Backupserver mit der Backup-Datenbank, es gibt Backup-Proxies, Mount-Server, Gateway-Server und Backup-Repositories. Repositories sind Datenspeicher, auf denen Backupdaten abgelegt werden. Bei der Installation erzeugt der Installer ein Default Repository auf der Systempartition. Normalerweise ist diese nicht sehr groß – vielleicht 100 GB oder weniger. Eine der ersten Aufgaben nach dem Setup ist die Einrichtung eines neuen Repositorys mit mehreren TB Speicherplatz. Man vergisst dabei leicht das Standard-Repository, welches immer noch auf die Systempartition zeigt. Unter bestimmten Umständen kann sich dies als Zeitbombe entpuppen, wie ich neulich in einer Umgebungs sehen konnte. „Veeam Default Repository“ weiterlesen

VMware vExpert 2018

Mit Freude fand ich eine eMail in meiner Inbox. Ich werde ein weiteres mal Teil des vExpert Programms von VMware sein.

Ein weiteres Jahr vExpert

Für mich ist dies Anerkennung, Auszeichnung und Verpflichtung in einem. Ich werde weiterhin mein Wissen mit der Gemeinschaft teilen und dies – sofern es die Zeit erlaubt – weiter ausdehnen.

VMware vExpert Programm

VMware verleiht jährlich das Prädikat vExpert an Mitgleder der Community, die sich im vergangenen Jahr durch besonderes Engagement ausgezeichnet haben. Die Auszeichnung richtet sich an Personen, die ihr Wissen und ihre Leidenschaft für VMware Technik weit über die Anforderungen ihrer täglichen Arbeit geteilt haben.

Links

vExpert Tweets auf Twitter: #vExpert

VMTN Blog – vExpert 2018 Award Announcement

VMware – vExpert Directory

Datacore Witness gegen Split-Brain Situationen

Datacore SANsymphony bietet Software defined Storage mit transparentem Spiegel im active-active Modus.

Seit Version SANsymphony 10 PSP7 unterstützt Datacore eine Witness Funktion.

Das Problem

Wenn beide Datacore Hosts sowohl Spiegelpfade, als auch LAN Verbindung verlieren, entsteht eine sogenannte Split-Brain Situation.

Beide Hosts DC1 und DC2 sind funktionsfähig und haben intakte Daten auf ihrem Datastore. Beide Hosts können Storage I/O von Servern (H1-H4) in ihrem Bereich bearbeiten. dadurch erfahren beide Hälften des Datenspeichers unterschiedliche Veränderungen, die nicht mehr in Einklang gebracht werden können.

„Datacore Witness gegen Split-Brain Situationen“ weiterlesen

Veeam ReFS Repository on iSCSI Targets

Troubleshooting Repository Deadlocks

With Resilient Filesystem (ReFS) integration into Veeam Availability Suite 9.5 a whole bunch of features was integrated. One of the biggest advantages is ‚Fast Cloning Technology‘ which enables synthetic full backups by merely creating pointers to already existing datablocks on the repository.

In a small scale environment I had a hardware repository server (Win 2016) with an iSCSI Volume as repository (ReFS, 64k) as primary backup target. This constellation worked like a Swiss watch. Daily backups ran for months without any trouble. Fast cloning technology enabled weekly synthetic full backups with minimal consumption of extra space.

Recently I’ve added another iSCSI Volume (ReFS, 64k) to be used as repository for backup copies. That’s when the fun began… „Veeam ReFS Repository on iSCSI Targets“ weiterlesen

Brocade FOS Default Passworte ändern

Brocade Fibrechannel Switches mit dem Fabric OS (FOS) werden standardmäßig mit den Benutzerkonten admin, root, user und factory ausgeliefert. Es ist wichtig, diese Default Passworte bei der ersten Konfiguration zu ändern.

Die Logins der Konten root, user und factory ändert man am schnellsten über SSH.

Login als user ‚root‘ mit Default-Password ‚fibranne‘

Bei erstem Login werden neue Passwörter für root, user und factory abgefragt. Mit <ENTER> startet man diesen Dialog, mit Ctrl-C bricht man ab. Bei nächstem Login wird man erneut zur Kennwortänderung aufgefordert.

Kontrolle der Nutzerkonten

userconfig --show -a

Hiermit werden alle lokalen Konten mit Status dargestellt.

 

vMotion fails at 21% with error 195887371

How to troubleshoot vMotion issues

Troubleshooting vMotion issues is in most cases a matter of networking issues. I will demonstrate in this case how to trace down the problem and how to find possible culprits.

What’s the problem?

Initiating a host vMotion between esx1 and esx2 passes all pre-checks, but then fails at 21% progress.

Migrate virtual machine:Failed waiting for data. Error 195887371. The ESX hosts failed to connect over the VMotion network.

See the error stack for details on the cause of this problem.
Time: 07.01.2018 19:08:08
Target: WSUS
vCenter Server: vc
Error Stack
Migration [167797862:1515348488969364] failed to connect to remote host <192.168.45.246> from host <10.0.100.102>: Timeout.
vMotion migration [167797862:1515348488969364] vMotion migration [167797862:1515348488969364] stream thread failed to connect to the remote host <192.168.45.246>: The ESX hosts failed to connect over the VMotion network
The vMotion migrations failed because the ESX hosts were not able to connect over the vMotion network. Check the vMotion network settings and physical network configuration. 
Migration [167797862:1515348488969364] failed to connect to remote host <10.0.100.102> from host <192.168.45.246>: Timeout.
vMotion migration [167797862:1515348488969364] failed to create a connection with remote host <10.0.100.102>: The ESX hosts failed to connect over the VMotion network
Failed waiting for data. Error 195887371. The ESX hosts failed to connect over the VMotion network.

„vMotion fails at 21% with error 195887371“ weiterlesen