Datacore SANsymphony-V 10 Neuheiten im Detail

Kurz nach dem Erscheinungdatum berichtete ich im Artikel Datacore SANsymphony-V 10 Release über die neuen Features von Datacore SANsymphony-V Version 10. Dabei handelte es sich jedoch nur um die Wiedergabe der Release-Notes. Ich möchte nun näher auf die neuen Funktionen eingehen und diese etwas näher beleuchten.

  • Virtual SAN
  • Smart Deployment
  • Auto Optimierung
  • Leistungsanalyse
  • High Performance Networking

Weiterlesen

Windows AHCI Treiber nachträglich installieren

Mit einer Solid-State Disk als Startpartition können Windows Bootvorgänge signifikant beschleunigt werden. Erwirbt man die PC Hardware bereits mit SSD, so ist dort das Betriebsystem vorinstalliert. Die Nachrüstung eines bestehenden Systems mit SSD und die Installation als Bootdisk gestaltet sich dabei gelegentlich schwieriger, denn das Installationsmedium für Windows kann zu diesem Zeitpunkt die SSD im SATA AHCI (Advanced Host Controller Interface) Modus nicht ansprechen. Dies gelingt nur im IDE Kompatibilitäts Modus. Dieser verbirgt sich je nach Hersteller unter verschieden Namen im BIOS:

  • Legacy
  • AHCI disabled
  • Compatibility Mode
  • native IDE

Weiterlesen

Veeam Setup mit bestehender Datenbank

Gelegentlich ist es notwendig, die Anwendung Veeam Backup & Replication auf ein anderes System oder eine andere Partition zu migrieren. Die einfachste Methode ist folgende:

  • Veeam Konfiguration sichern (Achtung! Login Konten werden gesichert, jedoch nicht die Passworte)
  • Patchlevel notieren
  • Veeam Dienste anhalten
  • Veeam deinstallieren
  • Veeam Datenbank löschen. Der Name ist bei Standard Installationen VeeamBackup.
  • Veeam Backup & Replication an neuem Ort installieren.
  • Software patchen bis zum Patchlevel der Sicherung
  • Veeam Konfiguration wiederherstellen
  • Kennworte nachpflegen, da diese nicht in der Sicherung enthalten sind

Diese Methode ist einfach und funktioniert sehr zuverlässig. Die Sicherung enthält alle Angaben zu Backupjobs, Historie, Infrastruktur, etc.

Datenbank erhalten

Sollte es aus irgendwelchen Gründen notwendig sein, die bestehende Datenbank zu erhalten, so muss man einige Hürden umgehen. Der Ablauf ist zunächst gleich wie oben geschildert:

  • Veeam Konfiguration sichern. Wichtig auch bei dieser Methode, denn wenn etwas schief geht (remember Murphy) braucht man einen Plan B.
  • Patchlevel notieren
  • Veeam Dienste anhalten
  • Veeam deinstallieren
  • Veeam an neuem Ort installieren

Hier wählt man die bereits existierende Instanz des SQL Servers aus. Im Beispiel unten war der Hostname = Veeam und ebenso der Instanzname.

VeeamDBVers01

Ganz so einfach ist es dann doch nicht. ;-) Die Installation erfolgt mit der ungepatchten Version, während die bestehende Datenbank bereits einige Patchzyklen hinter sich hat.

VeeamDBVers02Hierfür gibt es einen Lösungsvorschlag in der Veeam KB. Mit dem SQL Management Studio verbindet man sich auf die Instanz der bestehenden Veeam Datenbank und ermittelt die aktuelle Version.

Select current_version from [VeeamBackup].[dbo].[Version]

Im Beispiel war das Ergebnis der Abfrage 1205 (Veeam 7.0.0.871 Patch 4). Bevor man mit der Neuistallation beginnen kann, muss zunächst in der Datenbank die Versionsnummer heruntergesetzt werden. Diese Nummer ist Abhängig von der zu installierenden Basisversion. Für Veeam Backup 7.0.0.690 ist dies 1179.

Use VeeamBackup
UPDATE [Version] SET current_version = 1179

Danach lässt sich das Setup durchführen. Anschliessend muss die Applikation wieder auf den ursprünglichen Patchlevel gehoben werden.

Der einfachere Weg

Diese zuvor beschriebene Methode ist nicht so reibungslos, wie sie hier erscheinen mag. Mich kostete dies mehrere Anläufe, wesewegen ich die Methode mit dem Import der Konfiguration bevorzuge. Dabei bleibt die Datenbank Instanz erhalten. Man muss jedoch die bestehende Veeam Datenbank löschen, da es ansonsten zu Störungen beim Import kommen kann. Der Ablaufplan ist am Anfang dieses Artikels geschildert.

 

 

Links

Veeam Support – Installation Fails with Patched Database

 

VM Diskfiles mit mehr als 4 TB unter vSphere 5.5 erstellen

 

Gelegentlich gibt es Anwendungen, die große virtuelle Disks in einer VM erfordern. Seit vSphere 5.5 ist die 2 TB (minus 512 Byte) Grenze für vDisks gefallen. So steht es zumindest in den Configuration Maximums von vSphere 5.5:

Virtual Disk Size 62TB

Wer aber im vSphere Client (mea culpa, ich benutze den noch häufig) die Eigenschaften einer VM öffnet, um dort beispielsweise eine 5 TB Disk zu erstellen, wird mit einer Fehlermeldung konfrontiert:

The disk capacity entered was not a properly formed number or was out of range. It has been replaced with the nearest acceptable value DiskCapControl : value 5497558138880 is out of range (1048576,4398046511104)

Betrachtet man die letzte Zahl der Meldung (in Byte) so stellt man fest, daß es genau 4 TB sind. Auch die erzeugte vDisk ist genau 4 TB groß und nicht 5 TB wie gewünscht.

“Use the webclient, Luke!”

Wiederholt man die selbe Prozedur mit dem Webclient anstatt dem vSphere Client, so wird die vDisk in der gewünschten Größe erstellt. Offensichtlich möchte uns VMware schrittweise den vSphere Client abgewöhnen. Dass dies kein Bug ist, zeigt der Artikel KB 2054952.

Hier ist jedoch Vorsicht geboten. Mit der Konfiguration der großen vDisk nimmt man sich einige Konfigurations-Optionen wie zum Beispiel:

  • Virtual SAN
  • Fault Tolerance
  • Betrieb der VM nur auf ESXi 5.5 (auch bei HW Version 8)
  • Verwendung von Buslogic virtual SCSI Adapter

Die genauen Einschränkungen beschreibt VMware unter KB 2058287.

Links

  • VMware KB 1003497 – ESXi/ESX Configuration Maximums
  • VMware – vSphere 5.5 Configuration Maximums (PDF)
  • VMware KB 2054952 – Value out of range error message when adding disks larger than 4TB in vSphere Client
  • VMware KB 2058287 – Support for virtual machine disks larger than 2 TB in VMware ESXi 5.5

vSphere 6 Beta Programm gestartet

vSphere 6 Beta

Am 30 Juni begann die Betaphase für vSphere 6. Zur Teilnahme geht es über den Link unten.

VMware Communities – Beta Landing Page

Zusätzlich wird es Webcasts zur Version 6 geben:

  • Introduction / Overview – Tuesday, July 8, 2014
  • Installation & Upgrade – Thursday, July 10, 2014

Leitung frei zum Download! :-)

Ich werde in den nächsten Tagen und Wochen viele Aspekte der neuen Software testen und auch Blogbeiträge dazu verfassen. Leider verbietet mir die MSBTA von VMware, darüber zu berichten. Sobald das Produkt frei ist, werden hier die Artikel zugänglich.

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. 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.

Datacore SANsymphony-V 10 Release

Nach mehreren Vorankündigungen ist Datacore SANsymphony-V 10 nun offiziell verfügbar.

Neben zahlreichen Fehlerkoorekturen wurden auch neue Funtionen hinzugefügt. Die interessanteste hiervon ist meiner Meinung eine Erweiterung des Auto Tiering. Ab Version 10 werden nicht nur Read-IO für die Heatmap verwendet sondern auch Write-IO. Ein sehr wichtiges Feature, das in der V9 noch fehlte. Die Funktion ist erreichbar über den “Create Storage Profile” Tab und ist bisher noch als experimentell eingestuft, jedoch mit vollem Support durch Datacore

Weiterlesen

ESXi Hostfehler: Unable to apply DRS resource settings on Host

Eine etwas seltsame DRS Fehlermeldung kann angezeigt werden, obwohl DRS auf dem Cluster nicht aktiviert ist.

Unable to apply DRS resource settings on Host. Another task is already in progress. This can significantly reduce the effectiveness of DRS

Ursache ist dann sehr wahrscheinlich eine VMware Tools Installation die nicht ordentlich beendet wurde.

  • VM markieren
  • Kontextmenü “Guest”
  • End VMware Tools Install

Nach Abbruch der Tools Installation verschwindet die Meldung.