In Part 1 meiner Citrix Cloud Serie habe ich über die Einrichtung der Citrix Cloud Connectoren gesprochen. In Part 2 möchte ich jetzt näher auf das Einrichten von Hostingressourcen eingehen. Im Speziellen richte ich eine Verbindung zu VMware vSphere 7.0 und eine zu Citrix Hypervisor 8.2 ein. Beide Verbindungen sind OnPremise in meinem Datacenter. Die beiden oben genannten Hypervisoren sind natürlich nur ein Beispiel; mittlerweile lässt sich eine Vielzahl an Plattformen an die Citrix Cloud anbinden. Unter folgendem Link findet man eine vollständige Auflistung der unterstützten Plattformen sowie weitere wichtige Informationen und Systemvoraussetzungen.

Beginnen wir also da, wo wir das letzte Mal aufgehört haben, und melden uns wieder in der Citrix Cloud an. Im Hauptmenü klicken wir auf Virtual Apps and Desktops verwalten.

Beim ersten Start kommt eine Übersichtsseite, die in Stichpunkten erklärt, was für ein erfolgreiches Deployment aus der Citrix Cloud zu tun ist. Sie lässt sich mit einem Häkchen bei „Übersichtsseite nicht mehr anzeigen“ ausblenden. Allerdings ist es mir häufiger passiert, dass sie trotz dieses Häkchens wieder erscheint. Um nun unsere Virtual Apps und Desktops Instanz zu verwalten klicken wir auf Service verwalten.

Nun öffnet sich das Citrix Web Studio. Wer die Citrix Cloud schon etwas länger kennt, weiß, dass sich hier vor nicht allzu langer Zeit tatsächlich ein Delivery Controller in einer gekapselten ICA-Browser-Session befand. Die Performance dieser Lösung war sehr bescheiden, und obwohl man die Elemente aus seiner OnPremise-Welt kannte, war sie wenig intuitiv. Das neue Web Studio hingegen ist für Citrix-Verhältnisse sehr robust und performant. .Wir klicken nun auf den Punkt Hosting und als Nächstes auf Verbindung und Ressourcen hinzufügen.

Es öffnet sich nun ein Dialog, der uns durch die Einrichtung einer Hosting Connection leitet. Als Erstes wählen wir den Verbindungstyp. In unserem Fall VMware vSphere.

Weiter in diesem Dialog tragen wir die Verbindungsadresse des OnPremise vCenter ein. (Die URL muss für die Cloud Connectoren auflösbar sein) Danach brauchen wir noch Benutzername und Kennwort. Es muss nicht der Administrator-Account sein: Die Cloud Services brauchen für das Deployment von Maschinen nur eingeschränkte Rechte. Unter folgender URL findet ihr eine Auflistung der benötigten Rechte.

Wir vergeben noch einen Verbindungsnamen für diese Hosting Connection und wählen abschließend aus, wie über sie VMs bereitgestellt werden.

Als Nächstes kommt mit aller Wahrscheinlichkeit die Abfrage, ob wir dem selbstsignierten Zertifikat vertrauen wollen, das unsere VMware-vSphere-Umgebung besitzt. Alternativ vergibt ihr der VMware-Umgebung ein Zertifikat, dem die Cloud Connectoren vertrauen. Idealerweise über eine interne CA. In meinem Fall vertraue ich dem Zertifikat und bestätige mit OK.

Im nächsten Schritt müssen wir den Cluster definieren sowie auswählen, ob wir Shared Storage oder Local Storage haben.

Wir klicken auf Durchsuchen, um den Cluster oder Host auszuwählen, und bestätigen abschließend mit OK.

In meinem Setup habe ich keinen Shared Storage am ESXi, deswegen wähle ich für den Speicher dessen lokale Platten aus und klicke auf Weiter.

Hier lässt sich nun auswählen, welcher lokale Datastore verwendet werden soll und ob wir zwischen Betriebssystem und temporärem Speicher unterscheiden wollen. Der Grund dafür ist einfach: Man kann darüber entscheiden, ob der temporäre Speicher auf einer SSD liegt, um die Performance innerhalb der VM zu steigern. In All-Flash-Systemen ist das natürlich unnötig, aber in hybriden Umgebungen oder in SAS- und NL-SAS-Umgebungen kann man aus Kosten- bzw. Kapazitätsgründen so eine Aufteilung einstellen. In meiner Umgebung liegt alles auf lokalen SSDs und deswegen braucht es keine Unterscheidung.

Nachdem wir auf Weiter geklickt haben, können wir das Netzwerk definieren, das wir für unsere Maschinen verwenden wollen. Des Weiteren brauchen wir einen sinnvollen Namen für die Ressource. Wichtig: Wenn ihr mehr als eine LUN oder ein Netzwerk verwenden wollt, sollte sich das im Namen widerspiegeln. Das erleichtert euch später das Deployment von Maschinen. Ideale Namen wären z. B. RZ1-LUN01-VLAN10 oder RZ2-LUN12-VLAN3

Mit einem Klick auf Weiter kommt ihr in den Dialog der Geltungsbereiche. Im Grunde geht es hier um Berechtigungen, mit denen man Administratoren gezielt gewisse Bereiche zuweisen kann. Wenn ihr keine Administratoren habt, die nur auf diese Hosting Connection zugreifen dürfen, ist das für euch uninteressant. Ich selbst habe bisher noch keine Geltungsbereiche angelegt. Deswegen klicke ich auf Weiter

In der Zusammenfassung sehen wir noch einmal im Überblick, welche Einstellungen wir vorgenommen haben; mit einem Klick auf Fertigstellen wird unsere Hosting Connection angelegt und ist bereit, für einen Maschinenkatalog verwendet zu werden. Jetzt wären wir eigentlich durch — aber da ich euch auch noch zeigen möchte, wie man das Ganze mit einem Citrix Hypervisor anlegt und was dabei zu beachten ist, geht es direkt weiter. Wir klicken also noch einmal im Bereich Hosting auf Verbindung und Ressourcen hinzufügen. Der Dialog sieht nun etwas anders aus. Es wird mir die Möglichkeit gegeben zu meiner bestehenden Hosting Connection weitere Ressourcen wie z. B. Netzwerk und Speicher hinzuzufügen. Wir wollen aber eine neue Hosting Connection anlegen und klicken deswegen auf Neue Verbindung erstellen.

Der Verbindungstyp Citrix Hypervisor ist bereits ausgewählt und muss nicht angepasst werden. Die Verbindungsadresse muss analog zur VMware Adresse von den Cloud Connectoren erreichbar sein. Eine IP-Adresse geht bei Verwendung von http auch — dann ist der Traffic von den Cloud Connectoren zum Citrix Hypervisor allerdings unverschlüsselt. Verwendet man https, muss man darauf achten, dass auf dem Citrix Hypervisor ein Zertifikat installiert ist, dem die Cloud Connectoren vertrauen. Ist das nicht so, kommt nicht wie bei VMware ein Dialog, in dem man dem Zertifikat vertrauen kann, sondern eine Fehlermeldung, die behauptet, der Host sei nicht erreichbar. Dies ist etwas irreführend. Wenn ihr so einen Fall habt: idealerweise erst mal mit http gegentesten. Ich habe in meinem Setup das bereits installierte selbstsignierte Zertifikat des Citrix Hypervisors auf den Cloud Connectoren importiert, da der Import eines domänenvalidierten Zertifikates auf dem Citrix Hypervisor mit einigen Hürden verbunden ist.

Bei Benutzername und Passwort ist es beim Citrix Hypervisor etwas einfacher. Es gibt kein Berechtigungskonstrukt wie bei VMware; man kann lediglich Benutzer bzw. Gruppen, die über den Active-Directory-Join des Hypervisors auswählbar sind, als Server- oder Pool-Admin definieren. Hier im Labor habe ich für die Demo tatsächlich root verwendet, was allerdings nicht Best Practice ist. Abschließend vergebt ihr wieder einen Verbindungsnamen und klickt auf Weiter.

Auf dem XenServer wird kein Cluster ausgewählt; wir wählen hier nur, ob wir Shared Storage oder Local Storage verwenden, und klicken auf Weiter.

Auch hier haben wir die Möglichkeit auszuwählen, ob wir unsere Daten auf unterschiedliche Storages verteilen wollen. Hier im Beispiel selektiere ich für beides die gleichen lokalen Speicher und klicke auf Weiter.

Auch der Citrix Hypervisor braucht ein Netzwerk, das er für die VMs verwendet, und einen sinnvollen Namen für die Ressourcen. Abschließend klicken wir auf Weiter.

Nun können wir auch hier die Geltungsbereiche definieren, wenn wir welche haben; ansonsten klicken wir einfach auf Weiter.

In der Zusammenfassung sehen wir noch einmal alle Einstellungen, die wir vorgenommen haben. Mit Fertigstellen wird die Hosting Connection angelegt.

In der Übersicht im Bereich Hosting kann ich nun meine beiden eben angelegten Hosting Connections einsehen und verwalten.

So, nun haben wir hoffentlich erfolgreich unsere Hosting Connection eingerichtet und sind bereit, ein Image auszurollen … Leider ist es dann doch nicht so einfach: Es bleibt eine Hausaufgabe für euch. Bis zu Part 3 müsst ihr nämlich euer Image „Cloud Ready“ machen. Wie ihr das hinbekommt? Wie würde der liebe Citrixler nun sagen — „It Depends“. Ihr könntet ein neues Image mit euren Anwendungen erstellen und bei der VDA-Installation anstelle der Delivery Controller die Cloud Connectoren auswählen. Ihr könnt aber auch den „faulen“ Weg nehmen, den ich gegangen bin. Ich habe mein bestehendes Template kopiert und lediglich in der Registry die „List of DDCs“ angepasst. Wichtig ist natürlich, dass euer VDA die Provisionierungsart unterstützt, die in der Cloud eingesetzt werden soll — hier ist das Thema MCS vs. PVS anzusprechen. Jedenfalls ist das die Hausaufgabe für euch, liebe Leser; und wenn ihr dabei Unterstützung braucht, schreibt mir per Mail.