Citrix XenServer 6 Training in Hannover

Noch vor dem kommenden NetScaler Training führen wir eine Schulung für die neue XenServer Version 6 in Hannover durch:

Citrix Authorized Training für Citrix XenServer 6

Wann: 13.-17.02.2012
Wo: Hannover
Wieviel: 2.400€ zzgl. MwSt.
Inkl. Tagesverpflegung und original Citrix Learning Courseware, Zugriff auf Citrix Learning Labs

Was:
Module 1: Introduction to XenServer
Module 2: Installing and Configuring XenServer
Module 3: XenServer Networking
Module 4: XenServer Storage Repositories
Module 5: Creating and Managing Virtual Machines
Module 6: Installing and Configuring Provisioning Services
Module 7: Managing vDisks and Target Devices
Module 8: Implementing Resource Pools
Module 9: Distributed Virtual Switching
Module 10: Workload Balancing
Module 11: Configuring High Availability
Module 12: Managing and Troubleshooting XenServer

Diesen Citrix Kurs bieten wir in Kooperation mit dem Citrix Authorized Learning Center „CALC“ ADN Distribution GmbH an. Durch praktische Übungen vermittelt dieser Kurs grundlegendes Wissen zur Installation, Konfiguration, Administration sowie die Fehleranalyse von XenServer 6.0 und Provisioning Services 6.0.

Dabei führen praktische Übungen durch die folgenden Komponenten:

  • Konfiguration und Verwaltung des XenServer Host.
  • Einrichtung und Verwaltung von virtuellen Windows Maschinen sowie die Verwaltung des XenServer Resource Pools, der als Host der virtuellen Maschinen dient.
  • Konfiguration von Distributed Virtual Switches (DVS) und Workload Balancing (WLB).

Die Teilnehmer werden nach der Kursteilnahme u.a. in der Lage sein, Provisioning Services zu konfigurieren sowie vDisks einzurichten und zu verwalten.

Bei Interesse kontaktieren Sie bitte Frau Wegrich über 0511 – 260 911 44 oder nw@consulting-lounge.de.

XenServer: Hängende VM zurücksetzen

Wenn auf einem XenServer mal eine VM total hängt und ein Shutdown über das XenCenter auch nicht hilft, geht es so weiter:

Auflisten der noch laufenden Tasks:

xe task-list

Den entsprechenden Tast abbrechen:

xe task-cancel force=true uuid=UUID

Häufig reicht dies bereits aus und die VM beendet sich entsprechend.

Ist dies nicht der Fall geht es wie folgt weiter:

Herausfinden der UUID der entsprechenden VM:

xe vm-list

Herausfinden der DomainID anhand der UUID:

list_domains | grep UUID

Zerstören der Entsprechenden DomainID:

/opt/xensource/debug/destroy_domain -domid DOMAINID

Daraufhin muss die VM noch neu gestartet werden:

xe vm-reboot name-label='VMNAME' --force

Daraufhin sollte die VM nach ein paar Minuten Startzeit wieder erreichbar sein.

Direkter Zugriff auf das Dateisystem einer virtuellen Maschine in einem XenServer LVM Storage

Wenn der XenServer nicht mehr startet oder sein lokales Storage Repository nicht mehr findet, kann folgendes Vorgehen Abhilfe schaffen, um kurzfristig auf benötigte Dateien zuzugreifen.

Voraussetzung, um auf die Daten der virtuellen Maschinen im lokalen XenServer Storage zuzugreifen, ist eine Live-CD mit LVM Unterstützung. In diesem Fall wurde eine Debian GNU/Linux 6 Live-CD verwenden.

Vorgehen:

1. Von der Live-CD booten und als Benutzer root anmelden

2. Den Befehl lvscan ausführen und das benötigte Logical Volume auswählen und „merken“. Welches LV zu welcher virtuellen Maschine gehört lässt sich meist nur durch Ausprobieren herausfinden, eingrenzen kann man die wahrscheinlichsten Kandidaten meist nur anhand der Größe des LV.

root@debian:/# lvscan

ACTIVE ‚/dev/VG_XenStorage-4a48ea5b-ca5d-280f-4699-8d930df8500b/LV-8adc14c2-38ff-4377-a096-911eff7f58c8‘ [100.20 GB] inherit
ACTIVE ‚/dev/VG_XenStorage-<ID>/LV-<ID>‘ [100.20 GB] inherit
ACTIVE ‚/dev/VG_XenStorage-<ID>/LV-<ID>‘ [9.24 GB] inherit
ACTIVE ‚/dev/VG_XenStorage-<ID>/LV-<ID>‘ [38.86 GB] inherit
ACTIVE ‚/dev/VG_XenStorage-<ID>/LV-<ID>‘ [26.03 GB] inherit
ACTIVE ‚/dev/VG_XenStorage-<ID>/LV-<ID>‘ [10.28 GB] inherit
ACTIVE ‚/dev/VG_XenStorage-<ID>/LV-<ID>‘ [8.06 GB] inherit
ACTIVE ‚/dev/VG_XenStorage-<ID>/LV-<ID>‘ [100.20 GB] inherit
[…]

3. Über parted den Offset der Partition des benötigte LV ermitteln. Dazu parted unter Angabe des LV, welches wir uns gemerkt haben, starten und die Darstellung auf Blocks ändern.

root@debian:/# parted /dev/VG_XenStorage-<ID>/LV-<ID>
GNU Parted 2.3
Using /dev/dm-1
Welcome to GNU Parted! Type ‚help‘ to view a list of commands.
(parted) unit
Unit? [compact]? b
(parted) print
Model: Linux device-mapper (linear) (dm)
Disk /dev/dm-1: 16106127360B
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
1 32256B 16106127360B 16105065984B primary ntfs boot

(parted)
quit

Durch den Befehl print werden die verfügbaren Partitionen aufgelistet, nun müssen wir uns einen weiteren Wert merken und zwar den Wert in der Spalte Start. Anschließend kann das Programm parted mit dem Befehl quit verlassen werden.

4. Loopback-Device erstellen

root@debian:/# losetup -o 32256B -f /dev/VG_XenStorage-<ID>/LV-<ID>

Der Parameter –o bestimmt den Offset und –f die Datei bzw. in unserem Beispiel das LV welches eingehängt werden soll.

5. Zugewiesenes Loopback-Device ermitteln:

root@debian:/# losetup –a

6. Das Loopback-Device mit Hilfe von mount einhängen:

root@debian:/# mount /dev/loop-1 /mnt/lv-test1

Sofern der Typ des Dateisystems bekannt ist, kann anschließend in den Dateien der Virtuellen Maschine gestöbert werden.

Gartner Magic Quadrant for x86 Server Virtualization Infrastructure

Mit Datum vom 30.06.2011 ist der neue Gartner Magic Quadrant for x86 Server Virtualization Infrastructure erschienen. Es gibt nur Marktteilnehmer in zwei Quadranten – Leaders (VMware, Microsoft, Citrix) und Niche Players (Oracle, Parallels, Red Hat).

Die Ausführungen und Einschätzungen der Analysten sind wie immer interessant, aber auch nicht als ultimative Weis- oder Wahrheit anzusehen.

Citrix stampft Essentials for Hyper-V ein

Recht kurz angebunden informiert Citrix darüber, dass die Essentials für Hyper-V ein angekündigtes End-of-Life haben. Kunden mit gültiger Subscription Advantage können ihre Lizenzen zu XenServer oder XenDesktop konvertieren.

Interessant ist dieser Schritt vor allem, weil noch vor Jahresfrist Spekulationen im Raum standen, Citrix könne XenServer auslaufen lassen und sich auf die Essentials for Hyper-V konzentrieren, da diese schneller neue Versionen und Features bekamen als ihr XenServer Pendant. Diese Frage sollte ja nun beantwortet sein.

Linux Kernel 3.0 am Horizont – Xen Dom0 ready!

Ich hätte nicht gedacht, dass ich mal auf eine Oracle Seite verlinken würde, aber nun tue ich es: Wim Coekaerts hat eine schöne Zusammenfassung der Geschichte geschrieben, wie die Unterstützung für die verschiedenen Teile zum Betrieb als DomU und nun auch Dom0 in den Linux Kernel gewandert ist. Seit kurzem ist nun tatsächlich ALLES im Mainline Kernel Tree enthalten – und dieser Kernel Tree wurde soeben von Linus Torvalds als Version 3.0-rc1 im GIT eingestellt:

I decided to just bite the bullet, and call the next version 3.0. It will get released close enough to the 20-year mark, which is excuse enough for me, although honestly, the real reason is just that I can no longer comfortably count as high as 40.

Nach 2.6.39 kommt also 3.0 – das nächste Release des Linux Kernels beginnt eine neue Ära der Versionsnummerierung, und der wesentliche Grund dafür ist, dass es an der Zeit ist. Es gibt keine massiven, weltbewegenden, die Community umstürzenden Neuerungen oder Änderungen – nur eben die Versionsnummer, ansonsten könnte es auch einfach 2.6.40 sein.

Die Tatsache mit der vollständigen Xen-Unterstützung allerdings führt zu großer Freude bei denen, die auf diesen Hypervisor als Basis ihrer Virtualisierungslösungen setzen, allen voran also Citrix und Oracle. Denn für die wird es in Zukunft viel einfacher, ihre Produkte zu supporten und zügig zu entwickeln, ohne dabei ständig Kernel-Patches und Portierungen von Neuerungen pflegen zu müssen. Red Hat schwenkte ja vor einiger Zeit von Xen auf KVM als Hypervisor, weil der einfach nativ im Linux Kernel beheimatet ist und entwickelt wird – hier wird also endlich nachgezogen. Das etwa im August erwartete Release von XenServer 6.0 (Project Boston, derzeit Beta) wird aber sicher noch keinen Kernel 3.0 enthalten – aber mal sehen, wie lange das auf sich warten lässt.

Infos und Torvalds Post auf der Linux Kernel Mailinglist siehe http://www.phoronix.com/scan.php?page=news_item&px=OTUwMg.

XenServer Datenbank offline analysieren

Der Citrix Support hat ein Tool veröffentlicht, um die XAPI Datenbank offline zu parsen, damit Kunden und Partner eine Pool-Konfiguration selbständig genauer analysieren können. Im Wesentlichen besteht das Tool aus einem XML Stylesheet, das auf die Datenbank angewendet wird, um sie „human readable“ zu machen.

Dieses xapi-db-stylesheet wird zusammen mit der Datenbank (auf jedem XenServer zu finden als /var/xapi/state.db) in einem Verzeichnis abgelegt, die state.db in irgendwas.xml umbenannt und an den Anfang dieser Datei der Verweis auf das Stylesheet eingefügt:

<?xml-stylesheet type=“text/xsl“ href=“xenserver.xsl“?>

Dann kann die Datenbank im Browser geöffnet werden und zeigt die Poolkonfiguration menschenlesbar an.

Übrigens kann die state.db auch direkt mit dem XenCenter geöffnet werden; einfach den vollständigen Pfad zur Datei als „Server“ im XenCenter hinzufügen, schon bekommt man den Pool in dem Zustand angezeigt, wie er war, als die state.db wegkopiert wurde. Es sind natürlich keine Aktionen möglich, aber so können Zustand und Konfiguration ebenfalls vollständig offline (!) in Augenschein genommen werden.

Über die XenServer HA-Mechanismen

Dieser Artikel entstand als Beitrag in den internationalen Community-Foren von Citrix und ist daher englisch verfasst. Es gibt immer wieder Fragen und Diskussionen zu den Effekten, die bei aktiviertem HA Feature in einem XenServer Pool auftreten – daher möchte ich die Hintergründe und Funktionsweisen hier erläutern, denn so wird das Verhalten nachvollziehbar und auch weitgehend vorhersagbar (unerlässlich für eine sinnvolle Planung).

The case is described (very short version) as a pool of multiple XenServer hosts that loose network connectivity due to failover of a HP Flex-10 fabric or other reasons and then sending all hosts into a reboot loop.

This behaviour is more or less by design, I think (don’t take this as an official statement, I must not speak for the vendor or their specialists!).

A XenServer pool is able to act and react without a management server, because all pool members decide on their own, what their state and the state of the pool is. They do so by checking network heartbeat AND storage heartbeat for the availability of all other hosts. If both heartbeats fail, a host will analyze in what manner they have failed: Is nobody else reachable via neither of the heartbeats? Then I am all alone and the problem is most probably located in or at my very self –> fencing strikes! And it strikes by triggering a low (hypervisor) level hard reboot.

Imagine a different (more probable) situation: a pool with 5 servers. Due to split connectivity, three servers are on one „side“ and two on the other side. They can each reach the pool members on their side via at least one heartbeat, but not the other portion. In this case (where „some“ heartbeats are still good, others are bad) the smaller group will fence and reboot. The larger group will elect a new master and restart the VMs that were running on the now fenced servers. If the two groups would be equal in member size, the current pool master will make the difference, i.e. the group containing the master is the larger group.

This is a very intelligent concept and probably the only way to make this work automatically, but it has the downside of one case: Everybody uses all heartbeats. Everybody is alone. Everybody fences. Nobody is master.

Keen thesis: This case should be avoided by a good architecture/design on the fabric part. 😉

Because of todays „converged infrastructures“, the two heartbeats may not be that different anymore, because you don’t have storage and networking on two different fabrics in all cases, yes, this weakens the otherwise very strong concept of two heartbeats (storage heartbeat is actually a „quorum“ for deciding, who is there and who is not).

Über Speichervirtualisierung

Virtualisierung ist in aller Munde. Alles und jeder wird virtualisiert – nur das mit der Cloud ist noch schlimmer (Cloud-Salat). So ist der Begriff der Virtualisierung im Storage-Bereich auch schon länger angekommen, lässt aber ebenfalls schon länger keine Rückschlüsse darauf zu, was eigentlich gemeint ist.

Eine Variante von Speicher-„Virtualisierung“ hat HP schon lange im Programm (schon bevor es zum Buzzword wurde, behaupte ich mal): EVA. Enterprise Virtual Array. Da wird innerhalb der Speichermaschine virtualisiert. Bei den klassischen Arrays, seien es EMC² AX, CX oder HP MSA oder NetApp FAS oder oder… sieht der Admin Controller und Platten, baut RAID-Sets (Aggregates bei NetApp) mit einem RAID-Level aus von ihm bestimmten Platten zusammen, legt Volumes an und stellt sie als LUNs zur Verfügung. Dazu muss er wissen, was auf den Volumes laufen wird, um die RAID-Level richtig zu wählen und die Anzahl der Platten passend zu bestimmten für die geforderte Performance und Verfügbarkeit – was dann für die Zukunft auch statisch so ist und bleibt. Bei einer EVA sieht der Admin die einzelnen Platten nur zur Information über den Hardware Status und um Speicher Pools zu definieren. Innerhalb eines Pools gibt der Admin Eigenschaften bzw. Anforderungen wie das Redundanz-Niveau vor. Dann legt er Volumes innerhalb der Speicher Pools an, für die er wiederum das Redundanz-Niveau und die gewünschte Größe definiert. Wie die EVA dann intern tatsächlich die Daten über die Platten verteilt, weiß der Admin nicht. Das ist dynamisch und abhängig davon, wie viele Volumes mit welchen Anforderungen es gibt. So ändert sich auch mit der Zeit die Menge des verfügbaren Speichers in einem Pool, denn die EVA balanciert und striped die Volumes dynamisch über den gesamten Pool. Das ermöglicht prinzipiell, dass sie die Verteilung auf Spindeln aus Performance- oder Platz-Sicht optimiert. Angeblich tut sie das auch – unmittelbar nachvollziehbar ist das im Detail aber nicht, ist halt virtualisiert.

SAN-Virtualisierung im Sinne von DataCore und anderen sieht hingegen so aus, dass man einen Windows Server braucht, auf dem die DataCore Software installiert wird. Was immer an Storage dem Server zur Verfügung steht – sei es Direct Attached (DAS) oder unterschiedliche SAN-Arrays im Backend, erst mal muss es der Windows Server erreichen können – kann dann als Basis für die Funktionalität verwendet werden. D.h. es wird das tatsächliche Backend virtualisiert/abstrahiert und nach vorne einheitlich per iSCSI präsentiert (das kann mit kleinerem Feature-Set auch mit einem Windows Storage Server erreicht werden).

SANmelody ist dabei auf ein HA-Pärchen limitiert, SANsymphony unterstützt N+1 Redundanz. Loadbalancing findet nur zu den Backends statt (wobei auch erst SANsymphony Multipathing-Arrays unterstützt), d.h. die Anwendungsserver (iSCSI Initiators) sprechen immer mit einem Target (DataCore Server). Andere Vertreter dieser Gattung sind OpenFiler, aber auch – in anderem Maßstab – HP SVSP.

Dann taucht in dem Zusammenhang auch noch ein HP Produkt auf, das allerdings weniger selbst virtualisiert als dass es wirklich optimal als Storage für Virtualisierungsumgebungen geeignet ist: HP P4000 (the artist formerly known as „Lefthand“). Was dort virtualisiert wird, ist eigentlich nur die Anzahl der Knoten; es wird ein Cluster gebildet aus N Knoten, der von allen iSCSI Initiators über eine Cluster-IP angesprochen wird und die tatsächlichen Verbindungen dann auf die beteiligten Knoten verteilt. Es entsteht ein „hyperredundanter“ Speicher-Cluster, der immer gleichzeitig Platz und Performance skaliert, sehr performant und praktisch immer Feature-complete ist (einmal kaufen, nichts nachlizensieren). Die Redundanz bis hoch zur Knoten-Ebene (Ausfall eines kompletten Speicherknotens) ist transparent für die iSCSI Clients, ein aufwändiges, fehleranfälliges und möglicherweise sogar manuelles Failover zwischen Sites ist nicht nötig.

Allerdings können P4000 Speicherknoten auch virtuell sein – als Virtual SAN Appliance (VSA) für VMware ESX(i), die wiederum das komplette Feature-Set zur Verfügung stellt. Betrachtet man nun also den ESX-Host als Vergleich zum o.g. Windows Server, der als Basis für z.B. DataCore SANsymphony dient, dann kann man mit einer P4000 VSA alle dem Host zur Verfügung stehenden Storage Backends nutzen und einheitlich, mit dem gesamten P4000 Funktionsumfang, präsentieren, mithin also virtualisieren. In diesem Konstrukt sind allerdings schon so viele Ebenen beteiligt, durch die ein Datenblock zum Lesen oder Schreiben wandern muss, dass das Szenario seine Grenzen haben sollte.

Bevor ich jetzt noch in Diskussionen oder Vergleiche einsteige (das hebe ich mir für einen anderen Beitrag auf), sage ich nur noch: Welches Schweinderl hätten’s denn gern? Nur weil ein Produkt oder Angebot das Label „Virtualisierung“ trägt, sagt das alleine noch nichts über seine tatsächliche Beschaffenheit oder Funktionsweise aus. Nicht von den Verkäufern einlullen lassen, immer hinterfragen und auf kompetente Beratung bestehen (und darin investieren), um herauszufinden, was für meine konkreten Anforderungen die passende Lösung ist!