vCenter Statistiken fluten Datenbank

Wer hat die Datenbank geflutet?

Ein inzwischen gewohntes Bild bei vCenter Installationen auf Windows Basis mit der integrierten SQL Express Datenbank: der vCenter Dienst ist angehalten. Nach manuellem Start läuft dieser einige Sekunden und stoppt dann wieder. Ein Blick in die Ereignisprotokolle liefert Event ID 1105 und 1827.

Event 1105:

Could not allocate space for object ‚dbo.VPX_HIST_STAT1_222‘.’PK_VPX_HIST_STAT1_222′ in database ‚VIM_VCDB‘ because the ‚PRIMARY‘ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

Event 1827:

CREATE DATABASE or ALTER DATABASE failed because the resulting cumulative database size would exceed your licensed limit of 10240 MB per database.

Die Meldung erklärt den Grund der Störung. Das Größenlimit der Datenbank wurde erreicht. Im beschriebenen Fall wurde die Datenbank zuvor bereits von einer SQL-Express 2005 (max. 4GB) auf eine SQL-Express 2008 R2 (max. 10GB) migriert. Dennoch wurde das Limit erreicht.

VCHistStat02Der Cluster aus 4 Hosts sollte damit zurecht kommen und die Haltezeiten der Ereignisse wurden bereits auf 21 Tage limitiert. Welche Tabellen sind also für den Anstieg des Datenaufkommens verantwortlich? Unter SQL Server Express 2008 R2 haben wir hier mehrere Möglichkeiten zur Analyse. „vCenter Statistiken fluten Datenbank“ weiterlesen

Syslog Collector Troubleshooting

Syslog Collector logt nicht

ESXi Hosts, welche vom Flashmedium booten haben keinen permanenten Logspeicher. Das bedeutet, dass alle Logmeldungen nach einem Host Neustart verloren gehen. Aus diesem Grund gibt es den Syslog Collector Dienst, welcher bei der vCenter Installation (Win) zusätzlich installiert werden kann. Die Konfiguration auf habe ich in einem früheren Blogeintrag geschildert. Dieser empfängt Logeinträge von den ESXi Hosts und speichert sie lokal in rotierenden Logfiles ab.

Der VMware Support bat mich kürzlich, diese Logs für einen ESXi Host bereit zu stellen. Zunächst musste ich das Logverzeichnis auf dem Server mit Syslog Collector finden. Es liegt bei Standard Installationen unter:

%ALLUSERSPROFILE%\VMware\VMware Syslog Collector\Data

Beziehungsweise:

"C:\ProgramData\VMware\VMware Syslog Collector\Data"

Dort hat jeder überwachte ESXi Host ein Verzeichnis mit der jeweiligen IP des Hosts. Das Verzeichnis war schnell gefunden, jedoch staunte ich nicht schlecht, als ich den Zeitstempel der Logs sah.

syslogTrouble01

Seit über zwei Jahen gab es keinen Logeintrag mehr! Wie kann das sein?

Firewall

Auf dem Syslog Collector sah alles gut aus und der Dienst war aktiv. Danach warf ich einen Blick auf die ESX Firewall (Host > Configuration > Security Profile > Firewall > Settings). Damit wurde die Ursache schnell klar. (Thanks to Ivo Beerens, whose article gave me a hint to the solution)

syslogTrouble02Die Firewall des ESXi blockierte Verbindungen über UDP 514. Kein Kontakt – keine Logs – so einfach. 🙂

Der Haken bei syslog muss unbedingt gesetzt sein.

syslogTrouble03Schon wenige Augenblicke nach Übernahme der Regel füllte sich das Logverzeichnis auf dem Syslog Collector mit neuen Einträgen.

syslogTrouble04

Das half zwar nicht bei der Lösung einer anderen Fragestellung mit dem VMware Support, jedoch können in Zukunft die Logs ausgelesen werden.

Links

Ivo Beerens Blog – vSphere Syslog Collector troubleshooting

 

Fujitsu Eternus DX: Readonly LUN Mapping

Im Storage Area Network SAN gibt es mehrere Wege, den Zugriff auf Speichervolumes zu steuern. Zunächst kann man über Zoning festlegen, welche Initiatoren welche Targets sehen dürfen. Unterhalb des Targets werden Zugriffe auf LUNs in der Regel mittels LUN-Mapping gesteuert. Meist gibt es drei Optionen:

  • readonly
  • read / write
  • no access

Auf diese Weise lässt sich der Zugriff unterschiedlicher Hosts kanalisieren. Beispielsweise Lese- und Schreibzugriff (RW) für ESXi Hosts und reinen Lesezugriff (readonly) für den Backupserver. Somit kann verhindert werden, daß dieser versehentlich Signaturen auf  VMFS LUNs schreibt. Man kann dies zwar unterbinden, aber ein readonly LUN Mapping ist da die bessere Wahl.

Readonly Eternus DX ?

Zur Erhöhung der Sicherheit wollte ich kürzlich Volumes auf einem Eternus DX Storage System als readonly einem Host bereitstellen. In der GUI fand ich keine Einstellung hierfür (was nichts heissen muss), auch das Handbuch hatte keinen Hinweis darauf. Letztlich blieb mir nur die Anfrage beim FTS Support. Der Storage Support in Paderborn teilte mir mit, was ich bereits befürchtete:

Ein Readonly Zugriff ist für ausgewählte LUNs und Hosts nicht möglich.

Schade. Dies ist ein Rückschritt im Vergleich zu den ausgemusterten Storages der SX Serie.