VMWare Management – with Fling?

Der C#-Client für VMWare stirbt. Es rauscht heute einmal mehr recht zügig auf dem heise-Newsticker vorbei. Die Ankündigung wiederholt sich seit einigen Jahren, aber man kriegt das Gefühl, es wird ernst. Zeit sich mit Alternativen auseinander zu setzen. VMWare arbeitet seit geraumer Zeit daran. Management geht aktuell:

  • c# Client – ist so gut wie tot, sicher keine strategische Alternative.
  • webClient Flash – sieht flash-mäßig aus aber es ist halt Flash.
  • webClient HTML5 – sieht auch gut aus, ist aber grotten lahm.
  • Flings WebClient HTML 5. Experimentell!!!

Also als Verantwortungsbewusster IT-Leiter kommt Flash nicht in Frage, da ich keine strategische Plattform auf einem einzigen Sicherheitsrisiko basieren möchte und Adobes Umgang mit Flash in den letzten Jahren nährt hier keinesfalls Hoffnung auf Besserung. Der HTML 5 Client ist und bleibt lahm. Egal mit wem man sich darüber austauscht, die Erfahrungen sind allerorten die gleichen. Vor dem Hintergrund bleibt also die offene Auseinandersetzung mit dem Fling HTML5 Client:

fling-vsphereClient

Dieser hier ging diese Woche live. Man stimmt leider an allen ecken und Enden zu, dass dies quasi PräAlpha Ware ist. VMWare garantiert erst einmal für nichts und auch der Release Prozess über das Portal der VMWare Labs, vermittelt nicht den Eindruck eines Continue reading

Nexenta TestDrive

 

nexenta web dashboard

Software Defined Storage ist in aller Munde und wer sich länger mit dem Thema auseinander setzt kommt an Nexenta eigentlich nicht vorbei. Mit den Wurzeln in der OpenSolaris und Comstar Welt ist es eigentlich das einzige von Oracle unabhängige Produkt, das die extremen Vorteile von ZFS effektiv zum Kunden bringt.

Einen Test kann jeder schnell und einfach durch ziehen. Sollte man im Netz auf eine mehr oder weniger kryptische Anleitung stoßen, dann ist das zwar interessant aber eigentlich heute zunächst nicht mehr notwendig. Ein Test mit der Community Edition auf VMWare ist jederzeit schnell machbar. Diese ist zunächst funktional, jedoch auf 18 TB begrenzt und integriert auch nicht mit zahlreichen PlugIns in Richtung VMWare oder HyperV. Eine  Trial Enterprise steht, 45 Tage timebombed voll funktionsfähig, ebenfalls zum Download zur Verfügung.

Schnell eine VM gebaut, bei  der man ruhig großzügig mit Speichertöpfen sein kann, da man ja Architektur testen will – in diesem Fall mit VMWare Workstation:

nexenta test VM

Continue reading

Installing Fusion IO in vSphere 5.5.

Nächstes Highlight. Ich habe Hand an eine Fusion IO Karte legen können und so etwas wollte ich schon immer mal ausprobieren. Da die Storage Tests in vollem Gange sind, bietet sich hier zunächst die VMWare Testlandschaft an. Es handelt sich um eine etwas betagte HP 320 GB MLC PCIe IO Accelerator Karte.

Einbau – unproblematisch und sie findet sich auch auf der VMWare HCL, wenn auch nicht fürden ProLiant in dem ich teste. Der haken ist, leider nur für 5.1 U3 – laut VMWare. Auf der Support Seite von Fusion IO läuft die Karte unter 5.x. Da es eine Testumgebung ist, sei es drum.

FusionIOsupport page

Continue reading

open-vm-tools.

Ich bin ja noch immer großer Debian Freund und ich mag es, wenn es einfach simpel und abgespeckt bleibt. Kein Mensch braucht Ubuntu – auch wenn ich es zuweilen schön und bunt finde.

Jetzt ist das aber tatsächlich in VMWare Landschaften so eine Sache bis die klassischen VMtools auf dem Debian Client sind. Image dran pappen und gcc sowie kernel- Sourcen installieren und dann die VMtools mit dem Legacy Installer installieren, war immer irgendwie das Maß der Dinge und wenn man ein großer Freund der vmxnet3 …

Continue reading

Storage Virtualisation on HP ProLiant, vSphere 5.5 and HP Virtual Storage Appliance

Heute mal wieder etwas für Geeks:

Hyperconverged light – als Fazit meiner erfolgreichen Prototypen- Installation – ist durchaus eine Option und hier das HowTo: Auf Basis eines DL320e G8v2 mit vSphere 5.5 und HP VSA– der virtuellen Storage Appliance auf Basis der Lefthand Storage Systeme aus der P4000 Serie.

Test Hardware Definition

Der DL320e ist dabei mit kompatiblem Kingston Speicher ausgestattet – KTH-PL316E/8G und mit zwei 2TB WD Red platten für günstigen Platz, aber zwei Spindeln IO. Wunder sind von der Konfiguration nicht zu erwarten, aber es ist zunächst einmal reichlich Platz für zu virtualisierenden Storage vorhanden. Der Kingston Speichertyp ist wichtig, damit das System die Memories auch nimmt, eBay ist voll mit Kingston Speicherriegeln leicht anderer Bauart, die in DL380e nicht gangbar zu machen waren.

ProLiant Preparation

Vorbereitung des ProLiant mit dem HP ProLiant Service Pack, aktuell noch immer die Version 2014.09. Das ist kein größeres Drama,

Continue reading

VMWare vSphere 5.1 and Linux Storage

Eingedenk der Storage Musings in vorherigen Postings galt es vor einiger Zeit eine VMWare vSphere 5.1 mit frischem Massenspeicher zu versorgen. Geplant war das nicht – und bei der Restlaufzeit der aktuellen Storages möchte man eigentlich kein nennenswertes Geld ausgeben.

Warum also nicht Software Defined Storage light? Beim einschlägigen Broker der Wahl kam das Angebot von HP DL180 G6 gerade recht, randvoll mit 12 – Platten und 24 GB RAM zu Schleuderpreisen. Dank dem Presales von Intel gab es noch ein Pärchen 10 Gigabit Karten vom Typ 520 und ein Crosslink Twinax Kabel mit integrierten SFPs+.

Continue reading

Musings on Hyperconverged Infrastructure

Nachdem die letzten Postings eher an der Oberfläche gekratzt haben, jetzt mal ein paar Grundsätzliche Gedanken zum Thema Hyperkonvergenz und einiger Ableitungen.

Noch einmal die strategischen Ziele: Hyper- converged – die gleichzeitige Virtualisierung von Server und Storage Ressourcen in einem in jeder Hinsicht Software gesteuerten Hypervisor Umfeld. Die erste Ausprägung des Software Defined Datacenter (SDD). Wesentliche Merkmale sind die Flexibilisierung der Ressourcen vereint mit einer granularen Skalierbarkeit. Redundanzen werden auf der Ebene der jeweiligen Virtualisierung geschaffen. Die Systeme sind recht “moderat” zugeschnitten und bei einem wachsenden Bedarf an … Continue reading

UCS Caveats: Uplinking the VIC

The VIC virtual interface card allows within the UCS universe to dynamically create up to 256 VIF – Virtual Interfaces which dynamically bind to a virtual machine within a major hypervisor (e.g. VMWare vSphere, HyperV should be supported soon).

The VIC therefore is bypassed by the virtual switching layer within the hypervisor and provides a reasonable I/O performance advantage compared to classical virtual switching concepts. Basically a “virtual switch” module within the network framework of the hypervisor binds the pre-generated logical PCI devices to a dedicated driver within the virtual machine.

Given a proper integration the so generated virtual interface shows up within the UCS-Manager running on the Nexus based Interconnect Fabric as a classical switch-port and can be managed by the network staff accordingly.

Reading the details in the white papers, the driver component within the virtual machines supports only a limited number on interfaces, in cases as limited as eleven interfaces on one hypervisor. Due to the adapter pinning that does not only cover the general network interfaces, the number of VIFs grows with the factor of additional uplinks. The biggest number I am aware of right now is 56 interfaces with four uplinks from a FEX module. Given the two interfaces of the adapter card this comes close to the 128 advertised VIFs but you need to run Linux within the VMs and you need that many uplinks.

DCUCI: Datacenter Unified Computing Implementation

This week I visited the DCUCI training. The best class I had in a reasonable while. There could have been more labs and the marketing coverage – high and wide introduction was much to much considering the fact that there were two four hour eLearning-sessions upfront which covered this stuff more accurate.

Besides this annoying waste of valuable labtime it was a really great introduction into the Unified Computing System world of CISCO. Although it was not feasible to introduce the UCS preparation and uplink configuration part, covered in an appendix, everything else was covered fair. Introducing the pool concepts, updating templates for ports – interfaces, policies and in the server profile it gave a complete introduction into the hows and whens, even the caveats of the CISCO interpretation of stateless servers.

Even the connection and distributed switching integration into VMWare vSphere with the Nexus 1000v as well as the VM-FEX approach was discussed. The labs cover preferably the Nexus 1000v but due to our smart trainer we implemented the VM-FEX approach as well.

Down this road we found a lot of caveats which never have been covered in the technical deep dive classes offered from CISCO for end customers. I was very happy to hear this class, so we may judge better which way to go. In the long run the HP Virtual Connect Flex Fabric approach is not that clumsy as it looks within a superficial comparison to CISCO UCS. Honoring the caveats, the CISCO approach has to be well designed and even more carefully maintained that the HP one. Details will follow.

Blade New World

Most computer vendors flood the marketplace with more or less sophisticated blade solutions. Remark: Blade solutions well differentiated from blade servers.

So here some musings on blades and why I tend to differentiate between basic blade servers and the more sophisticated approach.

Basic blade concepts primarily convince, considering all the same aspects:

  • Optimized footprint aka rackspace
  • Reduced cabeling
  • Energy efficiency
  • Virtualized installation media
  • Cooling efficiency
  • Central management and maintenance
  • Easy hardware deployment and service

To whatever extend the different breeds address the different issues, these primarily are seem to be the supperficial quality criteria and argued in many decission processes, missing the core scope of the discussion. These topics are covered in the mainstream publications and are measured as the grade of quality of the “solution”.

From my point of view this is completely out of scope.

The real value of blades is interconnect virtualisation together with the so called “stateless server” approach. No surprise that many vendors try to keep the discussion on the less important facts, since according to my labs and evaluations only three major vendors even understood the issue. Depending on their legacy obligations they have more or less radical approaches to reach the goal.

The goal is to generate a server personality, its identity in terms of technical aspects, dynamically by application of a so called service- or server- profile. This profile contains the different aspects of the individual server identity such as e.g.:

  • BIOS version
  • Other firmware version, e.g. HBA or NIC
  • WWNs for port and node
  • MAC addresses
  • Server UUID
  • Interface assignements
  • Priorities for QoS and power settings

Accroding to these profiles and derived from pools of IDs, MACs, WWNs the servers identity is generated dynamically and assigned during a so called provisioning phase. Then the blade server is available for installation.

This approach allows to “on the fly” generate a server personality, that serves dedicated needs as for instance an VMWare vSphere server or an database server. Furthermore if more servers from the same type are needed the profiles my be cloned or derived from ma template so that new rollouts are quick and easy. In case of failiure or desaster recovery the profiles may even roam to other, not yet personalized servers and asuming a boot from SAN or boot from iSCSI scenario failed servers are back in minutes, transarent to even hardware based licensing issues.

Derived from specially the need for flexible interconnect assignment the classical approach of dedicated Ethernet or Fibrechannel switch modules in a blade infrastructure is of no further use any more. The classical approach needs dedicated interconnects at dedicated blade positions which is exactly the limitation a service profile wants to overcome.

With converged infrastructure, the support of FCoE and data center bridging as well as the according so called converged network adapters, thi limitation has been overcome on the interconnect side. Here the interconnect is configured in an appropriate way to cover the server side settings and assigns dynamically different NIC and HBA configurations to the single blade. Even more the connections may apply QoS or bandwith reservation settings and implment high connection availability in a simplyfied manner.

Based on that far advanced and very modern hardware operation concepts are possible. Only blade concepts, that support the full range of this essentially decoupling from hardware and service role, deserve the name “solution”. Anything else is “me too”.

Some posts on howtos from my previous evaluation and installation projects will follow. Some readers may remember my old blogg 😉