Kapitel Citrix XenMobile Server Basiskonfiguration

Transkript

1 Kapitel Installation Nachdem im ersten Kapitel alle Voraussetzungen für die Installation einer XenMobile-Infrastruktur beleuchtet wurden, sind wir nun bereit, um mit der eigentlichen Installation der Komponenten zu beginnen. Im Folgenden zeige und erkläre ich Ihnen Schritt für Schritt, wie die einzelnen Komponenten installiert werden und welche Grundkonfiguration erforderlich ist..1 Citrix XenMobile Server.1.1 Basiskonfiguration Beginnen wir mit der Installation des ersten XenMobile Servers. Die Installationsdaten können von der Citrix-Website heruntergeladen werden. Im Downloadbereich finden wir neben den zusätzlichen Komponenten auch die virtuellen Appliances für die jeweiligen Hypervisor. Der XenMobile Server steht für den Citrix XenServer, Microsoft Hyper-V und VMware ESX zur Verfügung. Im weiteren Verlauf nutzen wir den Citrix XenServer in der Version 6.5. Die reine Installation verhält sich aber auf allen Plattformen gleich. Sobald die entsprechenden Dateien von der Citrix-Webseite heruntergeladen wurden, können wir mit dem Import beginnen. Wie eine virtuelle Appliance auf dem jeweiligen Hypervisor importiert wird, ersparen wir uns an dieser Stelle. Wir gehen davon aus, dass die virtuelle Maschine bereits heruntergeladen, importiert und gestartet wurde. Sobald wir uns auf die Konsole der gestarteten virtuellen Maschine begeben, begrüßt uns nach einem kurzen Augenblick auch schon der Citrix XenMobile First Time Use Wizard, der uns durch die erste Konfiguration des Servers führt (siehe Abbildung.1). An dieser Stelle vergeben wir einen Benutzernamen und ein Passwort, das wir zur späteren Anmeldung an der textbasierten Konsole benötigen. Dieses Konto werden wir bei der späteren Konfiguration, z. B. beim Einrichten von Hochverfügbarkeit, noch benötigen. 33

2 Installation.1 Citrix XenMobile Server Weitere Informationen Mehr Informationen zum Thema FIPS 140--Modus finden Sie in dem Dokument»OpenSSL FIPS Object Module«unter der folgenden Adresse: fips140-. Für dieses Buch und die weiteren Schritte aktivieren wir den FIPS-Modus nicht und bestätigen das mit einem (n) für»no«. Abbildung.1 First Time Use Wizard von XenMobile Sobald diese Informationen erfasst und das Passwort zweimal richtig eingegeben wurde, folgt die Einrichtung der IP-Adressinformationen. Da wir den XenMobile Server im LAN platzieren, verwenden wir hier eine interne IP-Adresse aus unserem LAN- Segment. Laut Empfehlung von Citrix wird der XenMobile Server in der Regel in der DMZ platziert. Für die Konfiguration der Firewalls ist es jedoch wesentlich einfacher, nur die für den XenMobile Server genutzten Ports zu öffnen, als alle anderen Ports ins Backend zu öffnen. Abhängig vom Netzwerkdesign kann jedoch die Platzierung in der DMZ sinnvoll sein. Die Angabe von Subnetzmaske und Standard-Gateway sollte hier selbsterklärend sein. Zur internen Namensauflösung benötigen wir hier noch die Angabe von mindestens einem DNS-Server, der im Normalfall auf dem Domänencontroller zu finden ist. Die Angabe eines zweiten DNS-Servers ist optional, in Unternehmensumgebungen befinden sich aber in der Regel weitere Domänencontroller, auf denen ebenfalls der DNS-Dienst installiert und aktiviert ist. Diese eignen sich hervorragend als Secondary DNS Server. Sobald die Informationen erfasst wurden, werden diese mit der Eingabe von einem (y) für»yes«gespeichert (siehe Abbildung.). Für die Verschlüsselung der Daten benötigt der Assistent ein weiteres Passwort. Da wir dies nicht wieder benötigen und auch zu keiner Zeit eingeben müssen, können wir hier ein zufälliges Passwort vom XenMobile Server generieren lassen, was wir auch mit einem (y) für»yes«bestätigen. Dieses Passwort dient lediglich der Datenverschlüsselung der internen Daten. Zur weiteren Sicherheit bietet uns der Assistent nun noch die Aktivierung des FIPS (Federal Information Processing Standard) Mode an. Mit dem Erscheinen von Citrix XenMobile 10 unterstützt dieser nun auch den FIPS 140--Modus der US-Regierung. Abbildung. Passwörter und IP-Adresse Der wichtigste Teil der weiteren Installation ist die Erstellung und Verbindung zu einer Datenbank (siehe Abbildung.). Hier müssen wir die Entscheidung treffen, ob wir einen lokalen ((l)) oder einen externen ((r)) Datenbankserver verwenden möchten. Beim lokalen Datenbankserver wird der bereits in der virtuellen Maschine vorhandene PostgreSQL Server aktiviert, wählen wir einen externen Server, haben wir später noch die Wahl, welchen Datenbankserver wir verwenden möchten. Bitte beachten Für eine schnelle Installation kann sicher auch die lokale PostgreSQL-Datenbank verwendet werden. Da wir jedoch diese Datenbank weder für die Hochverfügbarkeit nutzen, noch die enthaltenen Daten später auf einen externen Datenbankserver migrieren können, verwenden wir hier natürlich keinen lokalen Datenbankserver. Diese Variante sollte auch ausschließlich in Proof of Concepts oder Testszenarien zum Einsatz kommen

3 Installation.1 Citrix XenMobile Server Da wir uns in diesem Buch mit dem Einsatz von XenMobile im Unternehmen befassen, wählen wir hier natürlich mit (r) für»remote«einen externen Datenbankserver. Im nächsten Schritt müssen wir uns für einen externen PostgreSQL oder Microsoft SQL Server entscheiden. Auch hier ist es nicht empfohlen, einen Datenbankserver basierend auf PostgreSQL zu verwenden. Aus diesem Grund entscheiden wir uns auch hier mit der Eingabe von (mi) für einen externen Microsoft SQL Server. Zur Erinnerung, der lokale PostgrSQL Server unterstützt natürlich keine HA-Szenarien. Externe PostgreSQL Server können zwar verwendet werden, unterstützen aber auch keine HA- Szenarien, deshalb sollten ausschließlich MS SQL Server in produktiven Umgebungen verwendet werden. Sollte der Datenbankserver die Verschlüsselung der Daten über SSL verlangen, können wir das hier angeben. In diesem Buch verwenden wir allerdings keine Verschlüsselung und wählen hier (n) für»no«. Sobald diese Informationen erfasst sind, benötigt der Assistent noch die Informationen zum SQL Server. Natürlich benötigen wir auch noch die Benutzerinformationen, um auf den Datenbankserver zugreifen zu können. Im einfachsten Fall benutzen wir hier das SQL- Konto sa oder ein zuvor angelegtes Dienstkonto. In produktiven Umgebungen ist hier natürlich ein Service Account mit dedizierten Berechtigungen zu verwenden. Dieser Service Account benötigt die Berechtigungen Administrator, Creator, Owner und Read/Write für die angelegte Datenbank. Abschließend vergeben wir noch einen Namen für die Datenbank. Der vorgeschlagene Name DB_services ist zwar wenig kreativ, kann aber so übernommen werden. Zur besseren Identifizierung der Datenbank verwenden wir hier den Namen XenMobileDB, der Name kann aber frei gewählt werden. Wenn alle Informationen korrekt waren, wird mit der Eingabe von (y) bei Commit Settings die Datenbank erstellt und initialisiert. Abbildung.3 XenMobile Datenbankserver In der vorliegenden Version unterstützt der Assistent hier noch keine Namensauflösung, weshalb wir den Server mit seiner IP-Adresse erfassen. Der Netzwerkport ist hier 1433, was dem SQL-Standardport entspricht. Falls der Port in Ihrer Zielumgebung nicht geändert wurde, kann der Wert hier übernommen werden. Bitte beachten Wenn Sie für XenMobile einen neuen Microsoft SQL Server installiert haben, achten Sie bitte auch darauf, den Port 1433 in der Windows-Firewall zu öffnen. Abbildung.4 Erstellen der XenMobile-Datenbank Nach der Initialisierung der Datenbank müssen wir uns entscheiden, ob wir den Cluster-Modus verwenden möchten. Da wir später die XenMobile-Umgebung mit zwei Servern hochverfügbar betreiben möchten, entscheiden wir uns hier für die Aktivierung des Clusters und bestätigen das mit (y) für»yes«. Unabhängig davon, können wir den Cluster-Modus auch jederzeit über die Konsole aktivieren und konfigurieren. Sobald der Cluster aktiviert wurde, werden wir darauf hingewiesen, den Port 80 für die Clusterkommunikation zu öffnen. Standardmäßig ist dieser Port auf der internen Firewall des XenMobile Servers nämlich nicht geöffnet. Wir werden dies später auf der Konsole noch nachholen

4 Installation.1 Citrix XenMobile Server Abbildung.5 Aktivieren des Cluster-Modus Kommen wir nach der Aktivierung des Clusters zu einem Schritt, der häufig falsch gemacht wird. Wie jedes Gerät im Netzwerk benötigt auch ein XenMobile Server einen Hostnamen, in diesem Fall als Fully Qualified Domain Name (FQDN). Wichtig an dieser Stelle ist, dass hier der externe Fully Qualified Domain Name (FQDN) verwendet wird. Das ist erforderlich, weil dieser FQDN auch im Deployment von XenMobile in der Antwort an das Endgerät verwendet wird. Würden wir hier einen internen FQDN verwenden, könnte dieser von einem externen Endgerät nicht aufgelöst werden. Wir verwenden hier den Hostnamen mam.domain.com, den wir später auch beim zweiten XenMobile Server genauso verwenden werden. Hier wird im Prinzip nicht der Hostname der jeweiligen Appliance, sondern der externe Name des Clusters definiert. Dieser Hostname ist auf allen XenMobile Servern identisch. Wie in der Einleitung erwähnt, benötigt der XenMobile Server eine ganze Reihe von Zertifikaten. In diesem Schritt erstellt uns der Assistent eine interne PKI (Public Key Infrastructure) mit allen benötigten Zertifikaten. Hierbei ist allerdings zu beachten, dass es sich natürlich um selbst signierte Zertifikate handelt, die später im Webinterface noch ausgetauscht werden müssen. Der Betrieb mit selbst signierten Zertifikaten ist zwar prinzipiell möglich, führt aber jedes Mal zu einer Fehlermeldung auf den Endgeräten. Im produktiven Betrieb ist die Verwendung solcher selbst signierter Zertifikate nicht empfohlen. Für den privaten Schlüssel kann und sollte dasselbe Passwort verwendet werden, woran wir uns hier auch halten. Mit einem (y) für»yes«bestätigen wir unsere Einstellungen (siehe Abbildung.7). Abbildung.7 Erstellen der Public Key Infrastructure Kommen wir langsam zum Ende unserer Konfiguration. Hier benötigen wir noch einen Benutzer mit dazugehörigem Passwort, der sich an der Webkonsole anmelden darf. Um es nicht komplizierter zu machen, verwenden wir hier den vorgeschlagenen Benutzernamen administrator, vergeben ein neues Passwort und bestätigen die Daten wieder mit einem (y) für»yes«. Abbildung.6 Festlegen der Netzwerkports Die Kommunikationsports wurden bereits in Kapitel 1,»Einleitung«, ausführlich beschrieben. An dieser Stelle können alle Ports wie vorgeschlagen übernommen werden. In den weiteren Kapiteln dieses Buches wird ausschließlich mit diesen Standardports gearbeitet. Wir bestätigen unsere Eingaben wieder mit einem (y) für»yes«. Bitte beachten Sollten aus irgendwelchen Gründen die verwendeten Ports hier geändert werden, so ist das bei der späteren Konfiguration des NetScalers zu berücksichtigen. Sämtliche Änderungen des Standards sollten auch ausführlich dokumentiert werden. Achtung! Der Benutzername ist case sensitive, in diesem Fall führt eine Anmeldung mit dem Benutzer Administrator zu einer Fehlermeldung. Zum Schluss werden wir noch gefragt, ob wir von einer früheren Version updaten möchten. Da wir an dieser Stelle eine Neuinstallation durchführen, verneinen wir das mit (n). Versionsupdate Für alle Benutzer, die bereits die Version 9 einsetzen, und eventuell ein Update auf die Version 10 durchführen möchten, stellt Citrix entsprechende Migrationsskripte zur Verfügung

5 Installation.1 Citrix XenMobile Server Damit ist der First Time Use Wizard abgeschlossen (siehe Abbildung.8). Das System wird nun initialisiert, was einige Minuten dauert. Abbildung.8 Abschluss des First Time Use Wizard Bevor wir uns jetzt aber der weiteren Konfiguration mit der Webkonsole zuwenden, konfigurieren wir noch ein paar Details in der Textkonsole. Zuerst melden wir uns mit dem Benutzernamen und Passwort, das wir im ersten Schritt vergeben haben, an der Textkonsole an. Hier sehen wir außer dem Menü auch noch die derzeit verwendete XenMobile-Version mit der entsprechenden Build- Nummer und dem Releasedatum. Wir wählen aus dem Menü hier den Punkt [] System aus. Abbildung.10 Konfiguration der Zeitzone Bevor wir den XenMobile Server neu starten, wechseln wir mit der [0] wieder zurück in das Hauptmenü und wählen dort erneut die [0] für das Konfigurationsmenü. Abbildung.9 Textbasiertes Konfigurationsmenü Auf die einzelnen Menüpunkte gehen wir später noch ein. Für die erste Konfiguration wählen wir hier den Punkt [] Set Time Zone (siehe Abbildung.10). Im Auslieferungszustand der virtuellen Maschine steht die Zeitzone noch auf Pacific Standard Time, wir ändern das hier auf Europe/Berlin, was für die meisten deutschsprachigen Europäer die richtige Wahl sein dürfte. Wir werden auch darauf hingewiesen, dass diese Einstellung auf allen Knoten eines Clusters identisch sein muss. Sobald wir die Eingabe der Zeitzone bestätigen, werden wir zu einem Neustart aufgefordert, was wir an dieser Stelle mit der Eingabe von (n) verneinen. Abbildung.11 XenMobile-Konfigurationsmenü Hier wählen wir die [] für die Konfiguration der Firewall. Wir erinnern uns, dass wir für die Kommunikation der einzelnen Knoten in einem Cluster noch den Port 80 öffnen müssen, der standardmäßig bei der Grundkonfiguration geschlossen ist. Wir können nun jeden einzelnen Port öffnen oder schließen sowie eine entsprechende Whitelist für den Port erstellen. Wir öffnen hier als Erstes den Port 80 mit der Eingabe 40 41

6 Installation.1 Citrix XenMobile Server eines (y). Als Whitelist könnten wir hier eine kommagetrennte Liste der IP-Adressen aller Knoten in unserem Cluster erfassen. Da wir nur einen weiteren Knoten installieren werden, erfassen wir hier bereits die IP-Adresse unseres zweiten Knotens. XenMobile Server Bitte teile dem Endgerät xyz mit, dass es sich bei mir melden soll APNS Server APNS Zertifikat Stop Nein Kenne ich den MDM Server? Ja Bitte kontaktiere deinen MDM Server Was gibts? ios Device Abbildung.1 Konfiguration der Clusterkommunikation Alle anderen Ports übernehmen wir wie bereits konfiguriert mit ( ). In einem produktiven Einsatz können hier sicher die Whitelists für alle Ports entsprechend gepflegt werden. In diesem Buch befassen wir uns mit dieser Konfiguration allerdings nicht. Firewall Die Konfiguration der Firewall muss nicht extra bestätigt werden. Wie bei Linux üblich, werden alle Änderungen an der Firewall sofort übernommen. Hier ist ein Update für dich Abbildung.13 APNS-Kommunikation Um ein APNS-Zertifikat bei Apple anfordern zu können, wird als Erstes ein CSR (Certificate Signing Request) benötigt. Dieser CSR lässt sich auf verschiedene Arten erzeugen. Wir benutzen hier einen im Netzwerk vorhandenen Windows-Server, auf dem ein Internet Information Server (IIS) installiert ist. Dazu öffnen wir die Konsole des IIS-Managers, klicken auf den Servernamen im linken Panel und wählen im mittleren Bereich das Icon Server Certificates mit einem Doppelklick (siehe Abbildung.14). Da noch ein Neustart der virtuellen Maschine aussteht, geben wir im Konfigurationsmenü noch eine [0] ein, um wieder in das Hauptmenü zu gelangen. Hier wählen wir die [] für das Systemmenü und wählen, dort angekommen, die [7] für einen Neustart der virtuellen Maschine. An dieser Stelle sind wir mit der Konfiguration an der Textkonsole fertig. Bevor wir jetzt allerdings die Konfiguration an der Webkonsole beginnen, schaffen wir zuerst noch einige Voraussetzungen..1. Erstellen eines Apple APNS-Zertifikats Das Apple Push Notification Service-Zertifikat stellt die Kommunikation des XenMobile Servers mit den APNS-Servern von Apple sicher. Dieses Zertifikat ist nur für Apple-Endgeräte erforderlich, da der XenMobile Server nicht direkt mit dem Apple- Endgerät, sondern immer über die Apple APNS-Server kommuniziert. Das ist keine Citrix-Idee, sondern bei Apple nicht anders möglich. Stark vereinfacht erfolgt die Kommunikation, wie in dem folgenden Diagramm dargestellt. Abbildung.14 CSR für APNS-Zertifikat erstellen Die eventuell bereits vorhandenen Zertifikate interessieren uns an dieser Stelle nicht. Im rechten Panel unter Actions klicken wir auf Create Certificate Request 4 43

7 Installation.1 Citrix XenMobile Server und erfassen die Informationen, die wir für das APNS-Zertifikat benötigen (siehe Abbildung.15). Benötigt wird hierbei in erster Linie der Common Name des Zertifikats, was in unserem Fall der zuvor vergebene FQDN des XenMobile Servers ist. Das ist auch die einzige zwingend erforderliche Angabe, die wir hier machen müssen. Da wir aber alles lieber gleich ordentlich machen wollen, füllen wir auch die anderen Felder mit sinnvollen Werten aus. den Button Sign und bekommen unsere signierte Anforderung in Form einer für Apple verständlichen.plist-datei zurück. Über den Link unter Schritt kommen wir auch direkt zum Apple Push Certificates Portal, um dort das benötigte APNS-Zertifikat zu erstellen. Das Apple Push Certificates Portal ist auch unter zu erreichen. Abbildung.15 Eigenschaften des CSR Hier lassen wir den Cryptographic Service Provider auf Microsoft RSA SChannel Cryptographic Provider, ändern aber die Bitlänge von 1.04 Bit auf.048 Bit. Geringere Bitlängen als.048 Bit werden nicht mehr unterstützt. Das gilt natürlich auch für alle weiteren Zertifikate, die wir noch erstellen müssen. Im letzten Schritt vergeben wir noch einen sinnvollen Dateinamen für unseren CSR. Es hat sich bewährt, einen Ordner zu erstellen, in dem alle Zertifikatsteile gespeichert werden. Nichts kostet mehr Zeit, als sich später die einzelnen Komponenten aus dem Dateisystem zusammensuchen zu müssen. Sobald der CSR gespeichert wurde, können wir das erforderliche Zertifikat beantragen. Bevor wir allerdings die Zertifikatsanforderung zu Apple schicken können, muss der Hersteller der MDM-Software dieses noch signieren. Citrix hat dafür einen Webdienst zur Verfügung gestellt, mit dem wir die Zertifikatsanforderung selbst signieren können. Unter melden wir uns mit einer gültigen MyCitrix- ID an und laden unsere Zertifikatsanforderung mit dem Button Upload CSR zum Signieren auf den Citrix-Server. Sobald der Upload abgeschlossen ist, klicken wir auf Abbildung.16 Citrix APNS Signing Portal Das Apple Push Certificates Portal erwartet eine Anmeldung mit einer gültigen Apple-ID. Diese Apple-ID sollte eine eigene Unternehmens-ID sein und nicht die private Apple-ID des Administrators. Nach der Anmeldung klicken wir auf den grünen Button Create a Certificate. Hier müssen wir dann den Nutzungsbedingungen von Apple zustimmen und kommen mit einem Klick auf Accept weiter zum Upload. Um das Zertifikat später besser identifizieren zu können, sollten wir hier auch einige Informationen zu unserem Zertifikat in dem Notizfeld erfassen. Danach laden wir mit Choose File die von Citrix heruntergeladenen.plist-datei aus und klicken auf den Button Upload. Hat alles wie erwartet funktioniert, bietet uns das Apple-Portal das neue APNS-Zertifikat zum Download an

8 Installation.1 Citrix XenMobile Server Danach erscheint das Zertifikat unter den Zertifikaten im IIS-Manager. Hier klicken wir das entsprechende APNS-Zertifikat mit der rechten Maustaste an und wählen Export. Jetzt vergeben wir noch einen Namen sowie einen Speicherort für das Zertifikat und vergeben das Passwort für den privaten Schlüssel..1.3 Erstellen eines öffentlichen SSL-Zertifikats Abbildung.17 Apple APNS-Zertifikat herunterladen Da es sich bei Apple um ein Unix-basiertes System handelt, erhalten wir das Zertifikat von Apple leider im PEM-Format. Für die Nutzung in XenMobile müssen wir dieses Zertifikat noch in ein PFX-Zertifikat konvertieren. Dazu benötigen wir wieder den IIS-Manager, auf dem wir die Zertifikatsanforderung erstellt haben, und klicken im rechten Panel unter Actions auf Complete Certificate Request. Hier wählen wir nun das von Apple erhaltene Zertifikat aus und vergeben einen Namen (in unserem Beispiel»APNS«) um das Zertifikat später wieder identifizieren zu können. Den Certificate Store lassen wir auf Personal und schließen den Vorgang mit einem Klick auf den OK-Button ab. In einem Unternehmen ist es natürlich keine gute Idee, auch nach außen selbst signierte Zertifikate zu verwenden. Alles, was wir an dieser Stelle für ein offizielles Zertifikat benötigen, ist ein CSR und natürlich eine belastbare Kreditkarte. Wie eingangs bereits erwähnt, ist es sinnvoll, sich für ein Wildcard-Zertifikat zu entscheiden. Damit reduzieren wir die Verwaltung unserer SSL-Zertifikate auf ein absolutes Minimum. Allerdings kostet ein Wildcard-Zertifikat je nach Anbieter etwa drei- bis viermal so viel wie ein einfaches SSL-Zertifikat. Bereits ab vier SSL-Zertifikaten, wir benötigen bereits drei für XenMobile mit ShareFile, rechnet sich jedoch ein Wildcard-Zertifikat wirtschaftlich. Wie bereits im vorangegangenen Abschnitt erstellen wir wieder mit dem IIS-Manager einen neuen CSR. Im rechten Panel unter Actions klicken wir auf Create Certificate Request und erfassen die benötigten Informationen. Bei der Anforderung des APNS-Zertifikats hätten wir nicht zwingend alles ausfüllen müssen, für ein offizielles SSL-Zertifikat werden die Angaben aber zwingend benötigt. Die einzige Hürde ist hier der Common Name, da wir für XenMobile mit ShareFile insgesamt drei SSL- Zertifikate mit passendem Common Name benötigen. Wenn Sie einzelne Zertifikate bei einer Zertifizierungsstelle bestellen, benötigen wir hier drei Zertifikatsanforderungen mit den folgenden beispielhaften Common Names: mdm.domain.com für den MDM-Teil von XenMobile mam.domain.com für den MAM-Teil von XenMobile sf.domain.com für den ShareFile StorageZone Controller Entschließen wir uns für ein einziges Wildcard-Zertifikat, lautet der Common Name lediglich *.domain.com. Nachdem wir die entsprechenden Zertifikatsanforderungen erstellt haben, können wir auf die Website einer Zertifizierungsstelle unseres Vertrauens gehen und dort ein oder mehrere entsprechende Zertifikate bestellen. Von der Zertifizierungsstelle wird noch überprüft, ob der Antragsteller auch der Inhaber der Domäne ist, für die das Zertifikat erstellt werden soll. Es kann hier durchaus möglich sein, dass noch weitere Dokumente (Handelsregisterauszug etc.) von der Zertifizierungsstelle angefordert werden. Ist alles so weit überprüft und die Kreditkarte gedeckt, bekommen wir in der Regel innerhalb kurzer Zeit das Zertifikat per von der Zertifizierungsstelle. Abbildung.18 Zertifikatsanforderung abschließen Für den XenMobile Server benötigen wir ein p1(.pfx)-zertifikat, das nach Möglichkeit alle Root- und Intermediate-Zertifikate enthalten sollte. Wir sprechen hier von einer 46 47

9 Installation.1 Citrix XenMobile Server Zertifikatskette bzw. einem Bundle. Im Normalfall erhalten wir das alles von der Zertifizierungsstelle entweder bereits in einer oder zum Download von der Website der Zertifizierungsstelle. Sollte die Zertifizierungsstelle PEM-Zertifikate verwenden, müssen wir wie zuvor beschrieben die Zertifikate in den IIS-Manager importieren. Dies geschieht wieder im rechten Panel des IIS-Managers unter Actions Complete Certificate Request. Sobald das Zertifikat dort erscheint, können wir es mit einem Passwort für den privaten Schlüssel wieder als p1-zertifikat (.pfx) exportieren und für den XenMobile Server nutzen. Die Vorbereitungen sind damit abgeschlossen, und wir haben jetzt die beiden p1-zertifikate in einem gemeinsamen Ordner..1.4 Initiale Konfiguration des XenMobile Servers Mit einem Browser öffnen wir das Webinterface unter bzw. und melden uns mit den Benutzerinformationen an, die wir bei der Basiskonfiguration in der Konsole vergeben haben. Zu beachten ist an dieser Stelle, dass der Port 4443 von außen erreichbar sein muss. Für den Zugriff aus dem LAN auf den FQDN über Port 4443 ist hier noch Split-DNS zu konfigurieren. Nach der Anmeldung führt uns auch hier wieder ein Assistent durch die Einstellungen. Beginnen wir mit einem Klick auf den grünen Start-Button. Import: Keystore Keystore type: PKCS#1 Use as: APN s Keystore file: das aus dem IIS exportierte p1 APNS-Zertifikat Password: das beim Export vergebene Passwort Nach einem Klick auf den Import-Button werden wir auf einen zwingend benötigten Neustart des XenMobile Servers hingewiesen. Wir bestätigen das mit OK. Den Neustart werden wir nach Abschluss der Konfiguration noch ausführen. Den gleichen Importvorgang wiederholen wir jetzt für den SSL Listener. Dieses ist das offizielle Zertifikat, das Sie von der Zertifizierungsstelle erhalten haben. Import: Keystore Keystore type: PKCS#1 Use as: SSL Listener Keystore file: das aus dem IIS exportierte p1 APNS-Zertifikat Password: das beim Export vergebene Passwort Auch hier bestätigen wir den Hinweis zum Neustart mit OK. Lizenzen Da Citrix ein kommerzielles Unternehmen ist, das vom Verkauf von Lizenzen lebt, müssen wir im ersten Schritt natürlich die Lizenz festlegen. Es werden hier nur noch v6-lizenzen unterstützt, d. h., wir benötigen eine.lic-datei von Citrix. Für eine Proof of Concept-Installation kann die bereits vorhandene 30-Tage-Testlizenz vorerst verwendet werden. In einer produktiven Umgebung ist jedoch weder eine Test- noch eine lokale Lizenz wirklich sinnvoll. Wir verwenden hier einen Citrix Lizenzserver, auf dem die entsprechenden Lizenzen bereits hochgeladen wurden. Dazu aktivieren wir den Schalter Configure license und wählen Remote license. Nun geben wir den Namen des Lizenzservers ein, belassen den Port auf dem Standardport 7000 und klicken auf den Button Test Connection. Ist der Server erreichbar und sind entsprechende Lizenzen vorhanden, werden diese auch gleich angezeigt. Ein Klick auf Next schließt das Thema Lizenzen dann ab. Zertifikate Wie bereits erwähnt, benötigen wir hier die vorher erzeugten Zertifikate. Die mit dem First Time Use Wizard erstellten Zertifikate sind hier bereits importiert und aktiviert. Wir werden nun das APNS-Zertifikat importieren sowie das aktuell vorhandene SSL Listener-Zertifikat durch das zuvor erstellte offizielle Zertifikat ersetzen. Ein Klick auf Import importiert zuerst das zuvor erzeugte APNS-Zertifikat. Abbildung.19 Importierte Zertifikate Root- und Intermediate-Zertifikate Wichtig an dieser Stelle ist, dass auch die Root- und Intermediate-Zertifikate der Zertifizierungsstelle angezeigt werden. Ist dies nicht der Fall, haben Sie keine Zertifikatskette, sondern nur ein einzelnes Zertifikat importiert. NetScaler Gateway Der dritte Schritt des Assistenten ist die Konfiguration des NetScaler Gateways. Da wir an dieser Stelle noch kein NetScaler Gateway installiert haben, überspringen wir diesen Schritt mit einem Klick auf den Next-Button. Die Konfiguration holen wir später jedoch nach

10 Installation.1 Citrix XenMobile Server LDAP-Konfiguration Für die Authentifizierung benötigen wir eine Verbindung zu unserem Active Directory. Im vierten Schritt erfassen wir in der LDAP-Konfiguration die Verbindungsinformationen zu einem unserer Domänencontroller. Directory type: Microsoft Active Directory Primary server: IP-Adresse oder FQDN des Domänencontrollers Secondary server: IP-Adresse oder FQDN eines weiteren Domänencontrollers Port: 389 für LDAP bzw. 686 für LDAPS Domain name: FQDN der Domäne User base DN: wird aus dem Domänennamen generiert (z. B. ou=user,dc= domain,dc=com). Entspricht dem Pfad in LDAP schriftweise zu der OU, die unsere Benutzer enthält. Group base DN: wird aus dem Domänennamen generiert. Entspricht dem Pfad in LDAP-Notation zu der entsprechenden OU, die unsere Benutzergruppen enthält. User ID: Administrator oder Service Account Password: Passwort des Benutzers Domain Alias: z. B. der NetBIOS-Name der Domäne XenMobile Lockout Limit: Standard 0 (Hier kann ein Wert zwischen 0 und 999 vergeben werden und definiert, nach wie vielen fehlerhaften Anmeldeversuchen der Benutzer gesperrt wird. 0 bedeutet hier, dass der Benutzer nicht gesperrt wird.) XenMobile Lockout Time: Standard 1 (Hier kann ein Wert zwischen 0 und vergeben werden und definiert, wie lange in Minuten ein Benutzer nach einem fehlerhaften Anmeldeversuch gesperrt wird. Auch hier bedeutet 0 keine Wartezeit.) Global Catalog TCP Port: Standard 368 Global Catalog Root Context: wird nur in großen Forrests benutzt User search by: UserPrincipalName bzw. samaccountname Abhängig davon, ob die Benutzer sich später mit username@domain.tld oder domain\username anmelden sollen. Use secure connection: Bei On wird der LDAP-Port auf 686 geändert. Notification Server Der Notification Server ist zwar optional, in einer Enterprise-Installation macht es aber durchaus Sinn, bei bestimmten Ereignissen informiert zu werden. Hier erfassen wir die Informationen zu unserem SMTP-Server. Die Einstellungen hier sind eigentlich selbsterklärend und hängen mit der Konfiguration des verwendeten Mailservers zusammen. Name: Der Name des Notification Server kann frei gewählt werden. Description: eine Beschreibung des Notification Servers SMTP-Server: FQDN eines Mailservers Secure channel protocoll: None, SSL oder TSL SMTP server port: 5 bzw. 465 bei SSL Authentication: On falls der Mailserver eine Authentifizierung verlangt User name: Mailbenutzer Password: das dazugehörige Passwort Microsoft Secure Password Authentication (SPA): nur bei Microsoft Exchange From name: z. B. XenMobile From z. B. xenmobile@domain.com Mit einem Klick auf den grünen Button Test Configuration können wir mit einer Testnachricht prüfen, ob alles richtig konfiguriert wurde. Damit ist die initiale Konfiguration des XenMobile Servers auch schon abgeschlossen, und wir könnten bereits mobile Geräte verwalten..1.5 Designübersicht Um den roten Faden nicht zu verlieren, schauen wir uns doch in der folgenden Übersicht einmal an, wo wir gerade stehen. 53 Windows Apple APNS Android 443/ /196 Externes Netzwerk DMZ Internes Netzwerk Abbildung.0 Designübersicht XenMobile MDM XenMobile MDM / MAM Admin / AD License Server 50 51

11 Installation. Citrix NetScaler Der XenMobile Server ist installiert und enthält die benötigten Zertifikate für den SSL Listener und den Apple Push Notification Service. Wer das an dieser Stelle die Installation bereits testen möchte, muss lediglich die Ports 443 und 8443 von der externen Firewall auf den XenMobile Server weiterleiten sowie eine externe IP-Adresse mit einem auflösbaren Domänennamen bereitstellen. Natürlich muss auch die Kommunikation des XenMobile Servers mit den Apple Server möglich sein. Wir haben die Verbindung zu einem Active Directory-/DNS-Server sowie den externen Lizenzserver konfiguriert. Prinzipiell haben wir den MDM-Teil bereits fertig erstellt. Für unseren nächsten Ziele, also Mobile Application Management (MAM) und Hochverfügbarkeit (HA), benötigen wir einen Citrix NetScaler. Um genau diesen kümmern wir uns im folgenden Abschnitt. Citrix NetScaler Der Citrix NetScaler ist eigentlich ein Thema für sich. Innerhalb einer XenMobile-Infrastruktur ist er allerdings zwingend erforderlich, weshalb wir uns nachfolgend die NetScaler-Produktreihe etwas genauer anschauen...1 Modellübersicht Citrix NetScaler MPX Mit NetScaler MPX bezeichnet Citrix die physischen Geräte, also echte Hardware, die ins Rack geschraubt werden muss. Die NetScaler MPX Appliances gibt es in den unterschiedlichsten Leistungsklassen. Angefangen bei der kleinsten (MPX 5500) bis hin zum Topmodell (MPX 1500) ist für jedes Rechenzentrum etwas dabei. Eine sehr gute Übersicht über die Funktionen und Features ist auf der Website von Citrix unter dem nachfolgenden Link zu finden: für die Verschlüsselung ausgeliefert, was gerade bei SSL Offloading ein Vorteil gegenüber den virtuellen Appliances ist. Auch hier ist ein guter Überblick unter dem nachfolgenden Link auf der Website von Citrix zu finden: Citrix NetScaler SDX NetScaler SDX sind die großen Maschinen. Mit SDX werden physische Geräte bezeichnet, die auf Basis des Citrix XenServers bis zu 40 virtuelle NetScaler-Instanzen zur Verfügung stellen können. Diese Geräte sind allerdings eher im Internet-Service-Provider-Umfeld, z. B. bei Google oder Amazon, sowie in großen Unternehmen zu finden. Es ist eher unwahrscheinlich, dass ein Administrator im Citrix XenApp-/Xen- Desktop-Umfeld jemals mit einem Citrix NetScaler SDX in Berührung kommen wird. Aber selbst falls doch, sind die nachfolgend beschriebenen Funktionen auch auf einem NetScaler SDX verfügbar... Integration und Konfiguration Um einen NetScaler in ein Netzwerk zu integrieren, gibt es eigentlich nur zwei Wege. Der erste ist der sogenannte Two-Arm Mode, bei dem der NetScaler mindestens ein internes Interface (LAN) sowie ein externes Interface (WAN bzw. DMZ) benutzt. Im Two-Arm Mode kann das Management über das interne Interface oder auch über ein weiteres Interface in einem dedizierten Managementsegment konfiguriert werden. Citrix NetScaler VPX Die NetScaler VPX sind die virtuellen Appliances, die auf einem Hypervisor betrieben werden. Derzeit können diese virtuellen Appliances für Citrix XenServer, Microsoft Hyper-V und VMware ESX heruntergeladen werden. Da die Hardware bei den virtuellen Appliances vom Hypervisor Host abhängig ist, bietet Citrix hier vom Einstiegsmodell (VPX 10) mit einem HTTP Throughput vom 10 Mbps bis zum Topmodell (VPX 3000) mit einem HTTP Throughput von 3 Gbps eine ganze Reihe von Appliances an, deren Funktionalität lediglich per Lizenz freigeschaltet werden muss. Prinzipiell unterscheiden sich die Funktionen der physischen NetScaler MPX nicht von denen der virtuellen NetScaler VPX. Allerdings wird der NetScaler MPX mit speziellen Chips Abbildung.1 NetScaler Two-Arm Mode Für kleinere Implementierungen steht auch ein One-Arm Mode zur Verfügung, bei dem interner und externer Netzwerkverkehr über das gleiche Netzwerkinterface 5 53

12 Installation. Citrix NetScaler gehen. Im One-Arm Mode kann der Netzwerkverkehr zusätzlich über VLANs segmentiert werden, was etwas mehr Flexibilität ermöglicht. In den meisten Fällen wird dieses Szenario jedoch nur dort benutzt, wo keine DMZ existiert und das LAN direkt am Router betrieben wird. Es existieren allerdings auch größere NetScaler-Implementierungen, die ausschließlich im One-Arm Mode betrieben werden. MIP Die MIP (Mapped IP) zeigt auf einen Host im LAN, der über den Citrix NetScaler zur Verfügung gestellt werden soll. Gemäß Citrix Best Practices sollte eine MIP produktiv jedoch nicht mehr verwendet werden. An ihre Stelle tritt die nachfolgend beschriebene SNIP. SNIP Die IP-Adresse mit dem schönen Namen SNIP (Subnet IP) zeigt, wie auch die MIP, in das interne LAN-Segment. Anders als vielleicht erwartet wird hier eine Host IP- Adresse und keine Netzwerk IP-Adresse vergeben. In der Grundkonfiguration muss mindestens eine SNIP konfiguriert werden. Liegen NSIP und SNIP im gleichen Netzwerksegment, erfolgt auch ein Teil der Kommunikation mit dem Backend über die NSIP. Die Kommunikation mit den DNS-Servern im Backend erfolgt jedoch ausschließlich über die SNIP bzw. MIP. Wer hier den kompletten Netzwerkverkehr ausschließlich über die SNIP leiten möchte, muss hierfür Netzwerkprofile am NetScaler konfigurieren. Abbildung. NetScaler One-Arm Mode IP-Adressen Ein weiterer wichtiger Aspekt sind die von Citrix verwendeten IP-Adressen und Konzepte, die in einer Citrix NetScaler-Implementierung notwendig sind. Ein Citrix NetScaler benötigt für den Betrieb mehrere unterschiedliche IP-Adressen, die sich, je nach Deployment-Methode, in einem oder mehreren Subnetzen befinden können. Für die Grundkonfiguration wird lediglich eine IP-Adresse zwingend benötigt. Für den vernünftigen Betrieb sind allerdings mindestens drei IP-Adressen erforderlich. Nachfolgend erklären wir die einzelnen IP-Adresstypen sowie deren Bedeutung und Verwendung in einer Citrix NetScaler-Implementierung. NSIP Die NSIP (NetScaler IP) ist für das Management zuständig und wird nach dem Import an der Konsole in der Grundkonfiguration des NetScalers vergeben. Diese IP-Adresse wird für den Zugriff auf die Webkonsole oder das Command Line Interface des NetScalers verwendet. Werden zwei Citrix NetScaler im HA-Modus (High Availability) konfiguriert, wird die NSIP auch für die Kommunikation zwischen den Knoten verwendet. Es versteht sich eigentlich von selbst, dass diese IP-Adresse nur einmal vergeben werden darf. VIP Die VIP (Virtual IP) ist die externe IP-Adresse des NetScalers. Diese IP-Adresse wird mit einem virtuellen Server auf dem NetScaler verknüpft, der Dienste nach außen anbietet. Ein NetScaler mit diversen unterschiedlichen Aufgaben und Funktionen kann unter Umständen sehr viele verschiedene VIPs verwenden. Die Anzahl der verwendeten VIPs hängt von der Anzahl der konfigurierten virtuellen Server ab. Für dieses Buch verwenden wir eine virtuelle NetScaler VPX 3000 Appliance. Abgesehen von der Konfiguration der NSIP, die bei einem physischen NetScaler am Display der Appliance oder über die serielle Konsole und bei der virtuellen Appliance an der Konsole des Hypervisors eingegeben wird, ist die Konfiguration identisch. Der NetScaler wird auch gern als Schweizer Offiziersmesser für das Netzwerk bezeichnet. Das liegt darin begründet, dass die NetScaler-Plattform einen enormen Funktionsumfang zur Verfügung stellt. Für die XenMobile-Installation in diesem Buch befassen wir uns allerdings nur mit Load Balancing und natürlich dem Access Gateway. Verwendete Netzwerktopologie Bevor wir mit der Konfiguration des Citrix NetScalers beginnen, ist es besonders wichtig, die geplante Integration in die bestehende Netzwerktopologie zu verstehen. Für die Installation in diesem Buch verwenden wir einen Two-Arm Mode mit mehreren Subnetzen. Der hier verwendete NetScaler hat ein Netzwerkinterface im LAN und ein Netzwerkinterface in der DMZ. Wie diese Integration aussieht, veranschaulicht Abbildung

13 Installation. Citrix NetScaler Der NetScaler benötigt an der Konsole nur eine initiale Netzwerkkonfiguration, DMZ Subnet 9.xx.xx.00/9 LAN Subnet /4 bestehend aus der IP-Adresse, in diesem Fall ist das dann die NSIP, sowie Subnetzmaske und die IP-Adresse des Gateways. Abschließend speichern wir unsere Einstel lungen, und die Konfiguration ist an dieser Stelle bereits fertig (siehe Abbildung.4). Bevor wir uns an der Webkonsole anmelden können, müssen wir noch kurz einen Neustart des NetScalers abwarten. Public Gateway VIP: 9.xx.xx.0 Loadbalancing VIP: 9.xx.xx.05 NSIP SNIP Loadbalancing VIP: Abbildung.3 NetScaler Two-Arm Mode mit multiplen Subnetzen In der weiteren Konfiguration des NetScalers sprechen wir diesen ausschließlich mit seiner NSIP an. Auf dem gleichen Interface liegt die SNIP, die mit den Systemen im LAN kommuniziert. Wer hier noch weitere Firewalls einsetzt, sollte darauf achten, dass die Kommunikation über die Ports (SSH) und 443 (SSL) auf die NSIP des NetScalers möglich ist. Der Netzwerkverkehr, der vom NetScaler in das LAN-Segment geht, verwendet als Quelladresse die SNIP des NetScalers. Aus dem Internet ist der NetScaler via zweites Netzwerkinterface über die öffentlichen IP-Adressen durch die externe Firewall direkt zu erreichen...3 Basiskonfiguration Auf der Citrix-Website stehen im Downloadbereich die virtuellen Appliances für jeden Hypervisor zur Verfügung. Derzeit unterstützt Citrix VMWare ESX, Microsoft Hyper-V, XenServer und KVM als Plattform. Damit sollten eigentlich alle im produktiven Umfeld eingesetzten Hypervisor abgedeckt sein. In diesem Buch verwenden wir die Version 10.5 Build 55.8nc. Sie sollten kein früheres Build und auch keine (e)- Edition verwenden, da dort nicht alle Funktionen verfügbar sind. Sobald die Appliance auf dem entsprechenden Hypervisor importiert und gestartet wurde, können wir die Basiskonfiguration wie gewohnt an der Konsole vornehmen. Basiskonfiguration Bei einem physischen NetScaler MPX wird diese Konfiguration in der Regel direkt am Gerät vorgenommen. Abbildung.4 NetScaler NSIP-Konfiguration Sobald der NetScaler neu gestartet ist, können wir die Webkonsole mit bzw. öffnen und uns mit dem Standardbenutzer nsroot und dem Passwort nsroot anmelden. Nach der ersten Anmeldung am NetScaler erscheint auch hier ein Assistent, der uns durch die weitere Einrichtung der Appliance führt. Hier beginnen wir mit der zwingend erforderlichen SNIP (Subnet IP-Adresse) und der dazugehörigen Netzwerkmaske. Diese zeigt, wie in Abbildung.3 beschrieben, in das LAN-Segment. Im zweiten Schritt benötigen wir jetzt noch einen Hostnamen. Dieser kann frei gewählt werden bzw. sollte den internen Namenskonventionen entsprechen. Den Hostnamen verwenden wir für die XenMobile-Installation nicht zwingend. Wichtig sind auch die Angabe eines DNS-Servers sowie die Auswahl der richtigen Zeitzone. In unserem Fall verwenden wir hier einen internen DNS-Server und wählen als Zeitzone Europe/Berlin aus. Mit einem Klick auf den Done-Button kommen wir zum nächsten Schritt. Da auch der NetScaler ein kommerzielles Produkt ist, benötigen wir hier natürlich noch eine Lizenz. Anders als bei Citrix üblich wird hier kein Lizenzserver verwendet, 56 57

14 Installation. Citrix NetScaler sondern die Lizenzdatei muss direkt in die Appliance importiert werden. Die benötigte Lizenz muss zuvor auf der MyCitrix-Seite heruntergeladen werden. Zu beachten ist hier, dass der NetScaler nicht über seinen Hostnamen, sondern über die Host-ID lizenziert wird. In der Regel entspricht die Host-ID der MAC-Adresse der ersten Netzwerkschnittstelle. Um sicherzugehen, können wir uns auch per SSH am NetScaler anmelden, auf die lokale Shell mit dem Kommando shell wechseln und uns mit dem Kommando lmutil lmhostid ether die Flexnet Host-ID ausgeben lassen. Sobald wir dann die Lizenzdatei von der Citrix-Website heruntergeladen haben, können wir diese mit dem Button Add New License importieren. Nach dem Import der Lizenz müssen wir den NetScaler mit dem Button Restart neu starten. Damit ist der Assistent dann auch schon abgeschlossen. Abbildung.7 NetScaler Configure Modes Abbildung.5 NetScaler: Import der Lizenzdatei Bevor wir uns wieder dem XenMobile Server zuwenden, konfigurieren wir am NetScaler noch den Zeitserver. Unter System NTP Server fügen wir mit Add noch einen oder mehrere Zeitserver hinzu. Im Normalfall können wir hier die Domänencontroller verwenden, aber auch jeder andere interne oder externe Zeitserver kann genutzt werden. Sobald der NetScaler wieder zur Verfügung steht, melden wir uns erneut an der Webkonsole mit dem Standardbenutzer an. Nachdem der Assistent abgeschlossen ist, werden noch ein paar weitere Details konfiguriert. Zuerst müssen wir alle für XenMobile wichtigen Erweiterungen unter System Settings Configure Basic Features aktivieren. Im Einzelnen benötigen wir Load Balancing und natürlich das NetScaler Gateway. In der Konsole sieht das Ganze dann wie in Abbildung.6 aus. Abbildung.6 NetScaler Basic Features Für unsere geplante Topologie benötigen wir zwingend den USNIP (Use Subnet IP) Mode. Das überprüfen wir noch unter System Settings Configure Modes. Abbildung.8 NetScaler: Zeitserver erfassen Wir benötigen hier nur den Full Qualified Domain Name (FQDN) des Zeitservers, alle anderen Felder belassen wir bei den Standardwerten. Mit einem Klick auf den Create-Button erstellen wir den Eintrag

15 6 Hochverfügbarkeit Kapitel 6 und Backup Im Unternehmensumfeld werden mobile Geräte und somit auch die Verwaltung immer wichtiger und zudem als unternehmenskritisch eingestuft. Aus diesem Grund werden bei der Auswahl der entsprechenden Lösungen auch die Themen Hochverfügbarkeit sowie Backup und Restore zu einem wichtigen Thema jedes IT-Leiters und stehen in Lastenheften nicht selten ganz weit oben. 6 Im Folgenden erkläre ich die Konfiguration von Hochverfügbarkeit aller beteiligten Komponenten und zeige, wie Backup und Restore innerhalb der Lösung realisiert werden kann. Wenn Sie die Konfiguration der vorangegangenen Kapitel durchgeführt und jetzt bereits eine funktionstüchtige XenMobile 10-Umgebung in Betrieb haben, muss ich Sie an dieser Stelle etwas enttäuschen. Betrachten Sie das als Übung, denn wir beginnen an dieser Stelle mit einer neuen Installation. Ich hoffe, Sie haben den Hinweis in Kapitel,»Installation«, gelesen, denn es ist keine gute Idee, eine bereits fertig konfigurierte Umgebung in den Hochverfügbarkeitsmodus zu versetzen. Bitte lesen Sie daher zunächst die Installations- und Konfigurationsanweisungen in Kapitel und 3 vollständig. Andernfalls betrachten Sie Ihre bisherige Konfiguration als»proof of Concept«oder als Übung und beginnen an dieser Stelle von vorn. 6.1 Hochverfügbarkeit Bevor wir mit der Hochverfügbarkeit starten, erst einmal eine kurze Übersicht, wie die Zielarchitektur danach aussehen wird. Wir nähern uns hier nun immer mehr der finalen Infrastruktur. Zu erwähnen ist, dass ich in diesem Buch nicht die Ausfallsicherheit der weiteren Komponenten der Infrastruktur behandle. Es versteht sich aber von selbst, dass der verwendete SQL Server, die Domänencontroller sowie Exchange- und eventuelle Storage-Systeme ebenfalls ausfallsicher konfiguriert werden sollten, um nicht bei einem Ausfall der Single Point of Failure (SPOF) zu sein. In einer hochverfügbaren Umgebung sollte auch besonderes Augenmerk auf die verwendete Netzwerkinfrastruktur gelegt werden. Auch hier sind doppelte Switches und Router sowie eine entsprechende Verkabelung wichtig. 65

16 6 Hochverfügbarkeit und Backup 6.1 Hochverfügbarkeit NetScaler 1: NSIP SNIP NetScaler : NSIP Apple Android Windwos SNIP keine NetScaler (HA) Microsoft Exchange PKI Public Gateway VIP: 9.xx.xx.0 Loadbalancing VIP: 9.xx.xx.05 DMZ Subnet 9.xx.xx.00/9 LAN Subnet /4 Aktiv SNIP Loadbalancing VIP: XenMobile Server Passiv Active Directory Sharefile Storage Zone Microsoft SQL NSIP Abbildung 6.1 Hochverfügbarkeit der XenMobile-Infrastruktur Für die Implementierung von Hochverfügbarkeit beginnen wir zuerst mit dem NetScaler. Dieser wird hier als Aktiv-Passiv-Pärchen installiert und konfiguriert, wobei jeder einzelne NetScaler über eine eigenständige IP-Adresse (NSIP) für die Verwaltung verfügen muss. Die weiteren IP-Adressen für das Subnet (SNIP) sowie die des virtuellen Servers für das Access Gateway und die entsprechenden Load Balancing Server teilen sich beide NetScaler, sodass im Fehlerfall der passive NetScaler die Kommunikation übernehmen kann. Für die XenMobile Server verwenden wir einen Cluster-Modus, der bereits in der XenMobile Appliance enthalten ist und den wir bei der späteren Konfiguration über die Lastverteilung des NetScalers hochverfügbar konfigurieren werden. Ähnlich verhält es sich bei den Servern für die ShareFile StorageZone. Hier verwenden wir lediglich die gleiche Netzwerkfreigabe für das Storage und benutzen den NetScaler, um die Hochverfügbarkeit über Lastverteilung bereitzustellen. Abbildung 6. NetScaler Hochverfügbarkeit NSIP Auf der Konsole der NetScaler sieht das Ganze dann wie in Abbildung 6.3 aus. Management NetScaler In Abschnitt..3 habe ich die Basiskonfiguration eines NetScalers beschrieben. Für die weiteren Schritte benötigen wir zwei separate NetScaler, die bereits über jeweils eine eigene NetScaler-IP-Adresse verfügen, DNS-Server und Zeitzone eingestellt und eine gültige Lizenz haben. Zum besseren Verständnis der folgenden Schritte hier die Basiskonfiguration, die ich für dieses Beispiel verwende: Abbildung 6.3 NetScaler IP-Adressen 66 67

17 6 Hochverfügbarkeit und Backup 6.1 Hochverfügbarkeit An der Webkonsole des ersten NetScalers wählen wir nun unter System den Punkt High Availability und klicken auf den Button Add. Hier fügen wir nun den zweiten NetScaler mit seiner IP-Adresse (NSIP) hinzu und geben den Benutzernamen sowie das Passwort des ersten NetScalers ein. Der Knoten, von dem wir die Hochverfügbarkeit konfigurieren, wird der aktive Knoten. Aus diesem Grund konfigurieren wir diesen ausgehend vom zweiten NetScaler. Benutzer und Passwort müssen identisch sein 6 Wichtig an dieser Stelle ist, dass der verwendete Benutzer sowie das Passwort auf beiden NetScaler identisch sein müssen. Gegebenenfalls sollte hier vorher ein spezieller Benutzer auf beiden NetScalern für die HA-Kommunikation angelegt werden. Ich verwende hier den Standardbenutzer nsroot, allerdings mit einem bereits geänderten Passwort. Abbildung 6.5 Hochverfügbarkeit eingerichtet Zur Konfiguration der NetScaler dürfen wir uns nur mit dem primären NetScaler in dem HA-Pärchen verbinden. Nur dieser synchronisiert Änderungen auf den sekundären. Sobald wir uns auf dem sekundären NetScaler anmelden, wird allerdings gewarnt, dass Einstellungen hier vom primären wieder überschrieben werden können. Abbildung 6.6 Warnung vom sekundären NetScaler Abbildung 6.4 NetScaler HA-Knoten hinzufügen Sobald wir hier auf den Button Create klicken, wird der entsprechend andere NetScaler hinzugefügt und die Konfiguration zwischen den beiden synchronisiert. Wir können das auch sofort überprüfen, denn der Status der Synchronisierung wird uns nach einem Klick auf Refresh sofort angezeigt. Auch die vorher konfigurierte Subnet-IP-Adresse (SNIP) steht nun auf beiden Net- Scalern zur Verfügung. Meistens ist das Herstellen von Hochverfügbarkeit auf einem NetScaler-Pärchen fehlerfrei und funktioniert auf Anhieb. In einigen wenigen Fällen kann aber die Synchronisierung später noch schiefgehen. Was dann bei der Fehlersuche helfen kann, finden Sie in Kapitel 7,»Troubleshooting« XenMobile Server Beim XenMobile Server verhält sich Hochverfügbarkeit ein wenig anders, hier installieren wir alle Knoten in einem Cluster. Wie zuvor erwähnt, beginnen wir auch beim XenMobile Server mit einer vollständig neuen Installation. Wir importieren wieder die virtuelle Appliance für unseren Hypervisor und starten diese nach dem Import

18 6 Hochverfügbarkeit und Backup 6.1 Hochverfügbarkeit Wichtig ist nur, dass wir während der Konfiguration an der textbasierten Konsole bereits den Cluster-Modus mit (Y) aktivieren. oder Ex- und erneuter Import ist an dieser Stelle völlig egal. Wichtig ist, dass die erste virtuelle Maschine auf jeden Fall ausgeschaltet bleibt. 6 Abbildung 6.7 Cluster-Modus aktivieren Die weitere Installation führen wir wie in Kapitel beschrieben durch. Sobald der XenMobile Server neu gestartet wurde, melden wir uns mit dem zuvor vergebenen Benutzer (Standard ist admin) und dem dazugehörigen Passwort an. Auch hier ändern wir zuerst die Zeitzone wieder auf Europe/Berlin. Schauen wir uns nun die Konfiguration des Clusters an. Hier sehen wir aktuell nur einen Knoten mit seiner entsprechenden ID. Über den Menüpunkt 3 Cluster member white list können wir die IP-Adressen der weiteren Knoten erfassen bzw. die Whitelist leer lassen. In diesem Fall gibt es dann keine Einschränkungen bezüglich der Mitglieder in unserem neuen Cluster. Abbildung 6.8 Cluster Node-ID Sobald dieser Vorgang abgeschlossen ist, starten wir die geklonte virtuelle Maschine und melden uns mit dem bekannten Benutzer und dem entsprechenden Passwort an der Appliance an. Hier ändern wir zuerst die Netzwerkeinstellungen im Menü [0] Configuration [1] Network. Wir ändern hier die IP-Adresse, die der zweite Knoten erhalten soll. Die XenMobile Appliance benötigt nach diesen Änderungen zuerst einen Neustart, bevor mit der weiteren Konfiguration fortfahren können. Bitte beachten Wir könnten hier auch eine Netzwerkadresse in die Whitelist eintragen, das wird derzeit aber noch mit einer Fehlermeldung beantwortet und ist meiner Meinung nach ein Bug, der noch behoben werden sollte. Nachdem wir nun überprüft haben, dass unser XenMobile Server ein aktiver Clusterknoten ist, gehen wir zurück in das Hauptmenü. Mit dem Menüpunkt [] gehen wir ins Systemmenü und fahren unseren XenMobile Server herunter. Als nächsten Schritt klonen wir unseren ersten XenMobile Server in eine weitere Maschine. Je nach Infrastruktur können wir die ausgeschaltete virtuelle Maschine auch exportieren und auf einem anderen Host wieder importieren. Ob nun Klonen Abbildung 6.9 Änderung der Netzwerkeinstellungen Nach dem hoffentlich erfolgreichen Neustart melden wir uns erneut an der Konsole an und überprüfen den Status des Clusters. Die neue Node-ID sollte jetzt genau um 1 hochgezählt sein

19 6 Hochverfügbarkeit und Backup 6.1 Hochverfügbarkeit Gleichzeitige Endgeräte Clusterknoten vcpus pro Knoten RAM pro Knoten Disk pro Knoten GB 50 GB > GB 50 GB Tabelle 6.1 Werte für Cluster (Forts.) 6 Alle XenMobile Server speichern ihre Konfiguration in der entsprechenden SQL- Datenbank. Das heißt, wir können theoretisch unendlich viele Knoten in einem Cluster betreiben, und bei steigenden Benutzern und Endgeräten ist es durchaus sinnvoll, mehr als nur zwei Knoten zu betreiben. Abbildung 6.10 Node-ID des zweiten Systems Wir können nun den initialen XenMobile Server ebenfalls starten. Auch hier überprüfen wir noch kurz die Cluster Node-ID, diese sollte sich nicht geändert haben. Wir können uns nun mit an der Webkonsole eines XenMobile Servers anmelden und unsere Grundkonfiguration, wie in Kapitel,»Installation«, beschrieben, beginnen. Es ist dabei egal, mit welchem Knoten des Clusters wir uns verbinden, da sich jetzt beide im Aktiv-Aktiv-Verbund befinden ShareFile Die Ausfallsicherheit bei unseren ShareFile StorageZone Controllern ist relativ einfach herzustellen, da hier weder Cluster noch HA-Pärchen benötigt werden. Für ShareFile benötigen wir lediglich N + 1-Server, die Zugriff auf die entsprechende Freigabe im Storage haben. Wichtig ist hier, dass wir lediglich die bereits vorhandene StorageZone auswählen sowie das bei der Installation des ersten StorageZone Center Servers verwendete Passwort eingeben. Ein kleiner Vorteil zeigt sich noch, wenn wir die virtuelle Maschine nicht geklont, sondern exportiert haben. Mit dieser exportierten virtuellen Maschine können wir ShareFile Storage Zone Server nun, falls erforderlich, dem Cluster neue Knoten hinzufügen. Dabei ist lediglich zu beachten, dass vor dem Start eines weiteren Knotens, basierend auf der exportierten virtuellen Appliance, die anderen Knoten heruntergefahren werden müssen, da es sonst zu IP-Adressproblemen kommt. Aus reinen Lastgründen wird kaum ein Unternehmen einen Mehrknoten-Cluster installieren, in großen Umgebungen ist aber die Verwendung von mehreren Knoten empfohlen. Nachfolgend die Benutzerzahlen und die dafür nötigen Knoten für den Betrieb. Load Balancing vserver Storage System Gleichzeitige Endgeräte Clusterknoten vcpus pro Knoten RAM pro Knoten Disk pro Knoten () 8GB 50 GB NetScaler Gateway () 4 8GB 50 GB GB 50 GB Tabelle 6.1 Werte für Cluster Abbildung 6.11 ShareFile Hochverfügbarkeit 7 73

20 6 Hochverfügbarkeit und Backup 6. Backup und Restore Die Ausfallsicherheit stellen wir dann über den bereits vorhandenen virtuellen Load Balancing Server im NetScaler her. Unter Traffic Management Load Balancing Services erstellen wir mit Add einen neuen Service, der auf die IP-Adresse des zweiten ShareFile StorageZone Center Servers zeigt. Als Vorlage können wir den bereits vorhandenen Service verwenden. 6. Backup und Restore Obwohl die Infrastruktur nun hochverfügbar ist, ist es sehr ratsam, sich auch über ein Backup und entsprechendes Restore Gedanken zu machen. Da bisher alles auf virtuellen Maschinen implementiert wurde, liegt es nahe, den Hypervisor zu verwenden und entsprechende Snapshots der Maschinen zu erstellen. Prinzipiell ist dies auch eine gute Idee. Wer allerdings jetzt der Meinung ist, darauf seine Hochverfügbarkeit zu bauen, sollte diesen Gedanken schnell wieder vergessen. Snapshots sind kein Ersatz für einen zweiten (oder mehrere weitere) Knoten NetScaler Kommen wir zuerst zum NetScaler. Hier ist ein Backup fester Bestandteil des Systems. Unter System Backup and Restore können wir die komplette Konfiguration des NetScalers in einem Archiv sichern. Wir haben hier die Auswahl zwischen Basic und Full Backup, wobei Basic nur die NetScaler-Konfigurationsdateien sichert, wohingegen Full Backup zusätzlich noch alle Zertifikate und Lizenzen enthält. Das Ergebnis ist ein.tgz-archiv, das wir uns nach erfolgreichem Backup vom NetScaler herunterladen können. Abbildung 6.1 Load Balancing Service erstellen Sobald dieser neue Service erstellt wurde, können wir ihn an die beiden für ShareFile erstellten virtuellen Server binden. Hier markieren wir den jeweiligen Server und wählen Edit. Unter Services and Service Groups klicken wir auf den Eintrag Load Balancing Virtual Server Service Binding und fügen den zuvor erstellten Service über Add Binding hinzu. Abbildung 6.14 NetScaler Backup Abbildung 6.13 Service hinzufügen Werden mehr als zwei StorageZone Center Server benötigt, können diese auf gleiche Art und Weise hinzugefügt werden. Wer allerdings nur die Konfigurationsdatei (ns.conf) des NetScalers benötigt, kann sich unter System Diagnostic auch die Running bzw. Saved Configuration anzeigen lassen und diese dann als Textdatei abspeichern