OSL UVE - Virtualisierung³

Hyperkonvergente Infrastruktur

Das Unified Virtualisation Environment (UVE) von OSL verbindet die drei für den hochverfügbaren Betrieb von virtuellen Maschinen benötigten Technologien: Server-, Speicher- und Netzwerk-Virtualisierung. Erstmals werden etablierte Standards in der OS- und Netzwerkvirtualisierung mit OSL-eigener Cluster-, Speichervirtualisierungs- und Netzwerk-I/O-Technologie zu einer Lösung zusammengeführt. Damit entstand ein komplett virtualisiertes IT-Infrastruktur-Modul, das in sich redundant, flexibel und skalierbar ist und an definierten Übergabepunkten Services in vorhandene IT-Infrastrukturen einspeisen kann.

Besondere Merkmale:

  • stark vereinfachte Infrastruktur - alles über ein physisches Netz
  • keine Hypervisor-spezifischen Kenntnisse erforderlich
  • in alle Richtungen skalierbare Infrastruktur
  • Einbindung verschiedener Speichersysteme
  • keine Bindung an einen Hardwarehersteller - Realisierung auf der Hardware ihrer Wahl

OSL hat den Gesamtprozess der Bereitstellung, des Betriebes und der Pflege hochverfügbarer, dynamischer Infrastrukturen konsequent in den Mittelpunkt gestellt und mit dem UVE ein Lösungspaket geschaffen, das über eine einheitliche Konzeption enorme Vereinfachungen und Einsparungen ermöglicht.
Eine Aufgabenteilung zwischen Storage-, SAN-, Netzwerk-, Server- und Betriebssystemadministration sowie Anwendungsbetreuung, Betrieb, Backup und Recovery ist heute vielfach der bevorzugte Weg, um die enorme Komplexität dynamischer, virtualisierter und hochverfügbarer Infrastrukturen zu beherrschen und dokumentiert sich nicht selten in einer Aufteilung eines an sich einheitlichen Gesamtprozesses auf mehrere Abteilungen. Dort, wo sich Produkte verschiedener Hersteller mit oftmals komplexen Konzeptionen zur Lösung nur einer Teilaufgabe etabliert haben, entstehen Schnittstellenprobleme, Reibungsverluste, Aufwände und Unsicherheiten, die bereits für große RZ-Betreiber eine ernstzunehmende Herausforderung sind und kleinen Anwendern den Zugang zu einer adäquaten und bezahlbaren Gesamtlösung oftmals völlig versperren. Hier bietet das OSL UVE eine komplette Lösung an.

Datenblatt
Beratung
Schulung

 

 

Standard-UVE-Konfiguration

Standard UVE

Wer bereits eine klassische RZ-Infrastruktur inkl. RAID-Systeme und SAN betreibt, kann diese für seine VM-Infrastruktur weiternutzen. Die UVS beziehen ihre Disk-Ressourcen aus dem SAN und stellen sie virtualisiert für die VMs bereit. Gleichzeitig liefert der UVS alle sonstigen benötigten Funktionen wie Virtual Network, VM-Steuerung usw. Die Grafik zeigt ein redundantes Layout mit 2 UVS.
Der Clou: Die UVCs, also die Maschinen auf denen die VMs laufen, sind lediglich redundant über Ethernet (oder IB) angebunden. Das Netzwerk ist konvergent, transportiert also den üblichen LAN-Traffic der VMs ebenso wie die I/O-Requests. Das vereinfacht die Konfiguration enorm, eliminiert Fehlerquellen und spart vergleichsweise teure und unflexible SAN-Ports. Das eigens entwickelte Block-I/O-Protokoll RSIO garantiert beste Performance, Skalierbarkeit und Redundanz.

Slim-UVE-Konfiguration

Slim UVE

Wer nicht mehr in den klassischen RZ-Stack, separate RAID-Systeme und FC investieren möchte oder aber auf der Suche nach höchster Performance ist, ist beim Slim UVE richtig. Mit internen SSD/NVMe-Disks im UVS haben die UVCs einen sehr kurzen Weg zu ihren Disk-Ressourcen. In der gezeigten einfachen Konfiguration tritt der UVS sozusagen an die Stelle eines RAID-Systems, nur eben mit höchster Performance und allen Zusatzfunktionen, die der Betrieb einer VM-Infrastruktur erfordert (VM-Management, HA-Steuerung, Speichervirtualisierung, Virtual Networking usw.)

Slim UVE redundant

Slim UVE redundant ausgelegt

Der "Slim UVE" kann auch geclustert werden. Der Ausfall eines UVS kann so ohne Betriebsunterbrechung für die UVCs / die VMs überbrückt werden.

Unterstützte Hardware

Server

Das Unified Virtualisation Environment 4.8 ist eine hochportable HCI im Client-Server-Modell und prinzipiell unter Solaris und Linux lauffähig (auch gemischt). In der Regel werden - je nach vorgefundener RZ-Umgebung und anwenderspezifischen Entscheidungskriterien - für die UVS Solaris-Systeme (SPARC oder x86) oder Linux-Systeme, für die UVC nahezu ausschließlich x86-Systeme unter Linux verwendet. Bei der Betriebssystemauswahl (die eigentlich von untergeordneter Bedeutung ist) sollte den Empfehlungen der OSL gefolgt werden (vgl. Softwarebeschreibungen / Datenblätter). Die verfügbaren Optionen für die Server-Hardware ergeben sich dann aus den gewählten Betriebssystemen. Letztere bestimmen insbesondere verwendbare Netzwerk-, SAN- oder Plattencontroller.

Unified Virtualisation Clients (UVC) bilden die Compute Node Farm und fungieren als Hypervisor Nodes Die virtuellen Maschinen laufen also auf den UVCs. Durch das Hinzufügen von UVCs kann das System Rechenkapazität, Performance und Verfügbarkeit sowohl beim Computing als auch im I/O steigern. Dafür werden CPUs mit Virtualisierungserweiterungen benötigt. Bei den Betriebssystemen sind grundsätzlich Solaris und Linux  möglich, üblicherweise werden hier Linux-Systeme (x86) verwendet.


Betriebssysteme

  • Linux SLES 15.5 (Tumbleweed oder andere auf Anfrage)
  • Solaris 10 / 11, empfohlen für UVS 11.3, für UVC 11.3/11.4

Beachten Sie auch die Freigabeinformationen der Hersteller zu den jeweiligen Systemen.

 

Netzwerk

Das Unified Virtualisation Network (UVN) verbindet den UVS mit den UVC. Hierfür wird eine mehrpfadige Anbindung der UVS/UVC empfohlen. Je nach Konfiguration kann der Slim-UVE bereits mit einem Switch und internen SSD zuverlässig umgesetzt werden. Für das Unified Virtualisation Network sollte mindestens auf 1G-Ethernet-Technologie gesetzt werden. Für ultrakurze Latenzen sollte IB oder mdst. 25G-Ethernet, besser 100G aufwärts genutzt werden.

 

Shared Storage / RAID-Systeme

Shared Storage bzw. externe RAID-Systeme können verwendet werden. In diesem Fall ist auf entsprechende (unterstützte) I/O-Controller auf den UVS zu achten. Aufgrund der im UVE integrierten Speichervirtualisierung sind externe RAID-Systeme jedoch nicht zwingend erforderlich, da die Replikation zwischen zwei UVS durch die Engine selbst möglich ist, was nicht nur unter Kosten- sondern auch unter Performanceaspekten vorteilhaft sein kann. Sofern nur ein UVS genutzt wird (ggf. auch in anderen Situationen) kann die Verwendung eines internen RAID-Controllers von Vorteil sein. Lassen Sie sich zu diesen Fragen von Ihrem Systemhaus oder OSL beraten.

 

Die Steuerung des virtuellen Rechenzentrums von einem Knoten aus

Das OSL UVE kann auf eine große Anzahl von geclusterten Knoten und virtuellen Maschinen skaliert werden. Der Cluster-Stack ist vollständig integriert und wird mit der Standardinstallation ausgeliefert. Um die Aufgaben Ihres virtuellen Rechenzentrums zu verwalten, können Sie die Komandozeile oder die webbasierte Benutzeroberfläche verwenden.

Kommandozeile
Die komplette Steuerung und Verwaltung des virtuellen Rechenzentrums erfolgt über die Kommandozeile. Hierzu gibt es eine Dokumentation in Form von Manpages. Mit Hilfe der Komandozeile können Sie Ihren gesamten Cluster von einem UVS-Knoten Ihres Clusters aus verwalten. Sie benötigen keinen dedizierten Manager-Knoten.

WebGUI - grafische Benutzeroberfläche
Eine bequeme Kontrollmöglichkeit über Ihr virtualisiertes Rechenzentrum haben Sie mit der integrierten grafischen Benutzeroberfläche der UVE. Die zentrale Webschnittstelle kann mittels eines normalen Webbrowsers (empf. Firefox) bedient werden. Sie hilft Ihnen, Ihren Cluster zu steuern und den Zustand jedes einzelnen Knotens sowie jeder VM zu überblicken. Dazu gehören unter anderem die Administration von Speicherressourcen, die Steuerung der VMs sowie ein umfangreiches Performance Monitoring der einzelnen Knoten und Gastsysteme. Dies erfolgt sowohl als Live-Log aber auch als History-Log. Die Daten für das Live-Log werden in der ersten Stunde im 4s-Takt geliefert. Das History-Log wird im Dateisystem gespeichert. Es beinhaltet die minütlichen Minimal-, Durchschnitts- und Maximalwerte und wird in einem speicherschonenden Binaerformat abgelegt. So sind Sie als Systemverwalter stets über die Auslastung Ihrer Systeme im Bilde.

Damit Sie als Admin  weiteren Personen definierte Zugänge auf die WebGUI geben können, ist in der GUI eine feingranulare Benutzerverwaltung integriert. Diese  ermöglicht eine dezidierte Benutzersteuerung:
Eine Organisationseinheit (OE) dient dazu, ein Element in der Organisationsstruktur Ihres Unternehmens abzubilden. Eine OE kann damit einer Hauptabteilung, Abteilung, Gruppe o. ä. Entsprechen. In der UVE können OEs in einer hierarchischen Struktur mit bis zu 3 Ebenen verwaltet werden. Rollen sind Ansammlungen von Berechtigungen. Sie erlauben einem Nutzer den Zugriff auf bestimmte Ressourcen oder auf bestimmte Aktionen in der UVE, z. B. das Starten und Stoppen virtueller Gastsysteme. Auch der Zugang zu bestimmten Bereichen der WebGUI hängt von Berechtigungen ab. Die Mächtigkeit eines Benutzers ergibt sich somit aus der Summe der ihm durch Rollenzuweisung verliehenen Rechte. Jeder Benutzer kann eine oder mehrere Rollen haben. Der Geltungsbereich einzelner Benutzerrollen lässt sich vom Administrator auf einzelne OEs begrenzen.

UVE-WebGUI

Unterstützte Virtualisierungstechnologien

OSL UVE setzt bei den Hypervisor Nodes (UVC) auf Linux und auf die verbreitesten dafür zur Verfügung stehenden Virtualisierungsmechnismen:

- KVM
KVM ist die branchenführende Linux-Virtualisierungstechnologie für die Vollvirtualisierung. Es handelt sich um ein Kernelmodul, das in den Mainline-Linux-Kernel integriert ist und mit nahezu nativer Leistung auf jeder x86-Hardware mit Virtualisierungsunterstützung läuft - entweder Intel VT-x oder AMD-V.

Mit KVM können Sie sowohl Windows als auch Linux in virtuellen Maschinen (VMs) ausführen, wobei jede VM über private virtualisierte Hardware verfügt: eine Netzwerkkarte, Festplatte, Grafikkarte usw. Die Ausführung mehrerer Anwendungen in VMs auf einer einzigen Hardware ermöglicht es Ihnen, Strom zu sparen und Kosten zu reduzieren, während Sie gleichzeitig die Flexibilität haben, ein agiles und skalierbares softwaredefiniertes Rechenzentrum aufzubauen, das Ihren Geschäftsanforderungen entspricht.

- VirtualBox
Festplatten werden in Containerdateien, von VirtualBox auch als Virtual Disk Images, (kurz VDI) bezeichnet, emuliert. Neben diesem eigenen Dateiformat kann VirtualBox auch mit HDD-Dateien von Parallels sowie mit Abbildern im QED- (QEMU enhanced disk) und QCOW-Format (QEMU Copy-On-Write) der Emulations- und Virtualisierungssoftware QEMU umgehen. Zudem können iSCSI-Objekte als virtuelle Festplatten genutzt werden, wobei der hierfür benötigte iSCSI-Initiator bereits in VirtualBox enthalten ist. Mit dem zu VirtualBox gehörenden Kommandozeilen-Werkzeug VBoxManager kann man diese fremden Formate auch konvertieren.
Es ist durchaus möglich, VirtualBox mit weiteren Gast-Betriebssystemen zu betreiben. Das Aktivieren der Virtualisierungserweiterung moderner x86-Prozessoren (bei Intel VT-x, AMD-V bei AMD) kann dabei helfen, ein sonst nicht unterstütztes Betriebssystem in der virtuellen Umgebung von VirtualBox laufen zu lassen.

Block I/O und IP über ein Netz - Vereinfachung der Infrastruktur

Das im UVE integrierte RSIO-Protokoll ermöglicht den Hypervisor-Nodes einen Block-I/O-Zugriff auf einen globalen, virtualisierten Speicherpool via Netzwerk. Das gleiche physische Netz wird dabei auch, nach Mandanten getrennt, für den Datenverkehr der virtuellen Maschinen und für die Steuerung der Clusterservices genutzt. Daraus folgen eine deutlich vereinfachte Infrastruktur sowie der Wegfall ganzer Aufgabenkomplexe in der Administration, was am Ende mehr Übersichtlichkeit und einen verbesserten Schutz gegen Ausfälle bedeutet. Prinzipiell nicht mehr notwendig sind LUN-Masking, Administration von FC-Fabrics, Administration von Netzwerk-Switches, Multipfad-Konfigurationen für den Block-I/O, komplizierte Netzwerkkonfigurationen und IP-Multipfadlösungen in VM-Gastsystemen, die Verwendung von VLANs in virtuellen Maschinen und ein aufwendiges Gerätemanagement für virtuelle Maschinen.

RSIO-Architektur

Neben einer aufgeräumten und übersichtlichen Infrastruktur gibt es auch erhebliche Einsparungen durch einen Verzicht auf eine FC-Fabric und die verringerte Zahl von Netzwerk-Ports. Desweiteren sind die hohe Portdichte, der Energieverbrauch und der verringerte Platzbedarf bei dieser Umsetzung hervorzuheben.

Verfügbarkeit und Skalierbarkeit auf allen Ebenen

Mit dem OSL UVE können alle Schichten der Gesamtlösung bestmöglich voneinander entkoppelt und redundant ausgelegt werden. Überflüssige Redundanzen werden verzichtbar, die Gesamtlösung bleibt einfach in der Handhabung und wirklich alle Hardwarekomponenten sind prinzipiell und ohne Serviceunterbrechung austauschbar.

Die Intelligenz zur Steuerung aller wesentlichen Funktionen wird von den Teilkomponenten zum UVE-Server (UVS) verlagert. Das reduziert Komplexität und wechselseitige Abhängigkeiten, verbessert die Verfügbarkeit und erlaubt den Online-Austausch einzelner Komponenten, auch durch Produkte anderer Hersteller mit anderen Leistungs- und Konfigurationsparametern sowie anderen Eigenschaften. So können beispielsweise die RAID-Systeme durch eine neue Generation abgelöst, die Switches oder die Hardware der Hypervisor-Nodes oder sogar der UVS getauscht werden, ohne dass prinzipiell eine Betriebsunterbrechung erforderlich ist.

UVE-Redundanz

Hochverfügbarkeit

Hier gehen wir bei den Produkten von OSL andere Wege. Die Hochverfügbarkeit erfolgt nicht über einen extra Cluster-Interconnect oder ein Quorumdevice sondern über eine automatisches Selbstmanagement der Applikationen.

Zahlreiche Datencenter-Applikationen müssen aus betriebswirtschaftlichen Gründen unterbrechungsfrei online sein. Um dieser Anforderung gerecht zu werden, bedarf es eines effektiven Schutzes vor Hardwareausfällen - Clusterlösungen. Sie tragen dafür Sorge, dass Anwendungen im Katastrophenfall auf ein anderes Stück Hardware migrieren. Ein für solche Fälle vorgehaltener Host übernimmt die Applikation. Offline-Zeiten werden so vermieden. Diese Vorgehensweise setzt allerdings voraus, dass auf Hardware-Ressourcen abstrahiert zugegriffen werden kann. Prozesse und Anwendungen müssen beschrieben, ggf. angepasst werden.

Aktiv/aktiv, aktiv/passiv oder keines von beiden?
Von herkömmlichen Clusterlösungen kennt man aktiv/aktiv-Varianten, bei denen mindestens zwei Applikationsserver online sind und bei Ausfall eines Servers der andere dessen Aufgaben übernimmt. Weiterhin kennt man aktiv/passiv-Lösungen, bei denen ein Standby-Gerät vorgehalten wird, welches einspringt, wenn das Primärsystem ausfällt. Wenngleich auch solche Architekturen unterstützt werden, beschränkt sich das Clusterkonzept von OSL nicht auf diese beiden althergebrachten Varianten. Denn mit dem OSL UVE lassen sich weitaus intelligentere Konfigurationen abbilden. Unsere Software steuert per ressourcenbasiertem Selbstmanagement Ihre Anwendungen clusterweit automatisch und weist sie den zur Verfügung stehenden Hosts entsprechend ihrem Ressourcenbedarf zu. Bei Hardwareausfällen ordnen sich die betroffenen Anwendungen den verbleibenden Hosts gemäß ihrer Priorität neu zu:

Der OSL-Anwender ordnet seinen Applikationen Prioritäten zu. Auf Grundlage von Performancebenchmarks, Anwendungsbeschreibungen und Prioritäten wird eine Zuordnung der Applikationen auf unterschiedliche Server des Clusters vorgenommen. Dies kann entsprechend der Leistungsfähigkeit, der zur Verfügung stehenden Hardware automatisiert erfolgen.

Fällt nun ein Clusterknoten aus, findet anhand der jeweils benötigten Hardwareressourcen im notwendigen Ausmaß eine Neuverteilung der Anwendungen über die noch zur Verfügung stehenden Clusterknoten statt. Höher priorisierte Anwendungen können dabei sogar weniger priorisierte verdrängen, um selbst weiterhin online zu bleiben. So kann der Anwender seine Produktivapplikationen entsprechend hoch und Test-, Entwicklungs- oder QS-Applikationen niedrig priorisieren, um im K-Fall die wichtigen Anwendungen verfügbar zu halten.

Ist die ausgefallene Hardware später wieder online, können die heruntergefahrenen Applikationen erneut gestartet werden. Eine nochmalige Migration laufender Anwendungen ist danach nicht zwingend notwendig.

❮ ❯