Product Documentation

Notfallwiederherstellung

Sie können XenMobile-Bereitstellungen mit mehreren Sites für die Notfallwiederherstellung und einer Aktiv-Passive-Failoverstrategie einrichten.

Die hier vorgestellte Strategie zur Notfallwiederherstellung umfasst Folgendes:

  • Eine aktive XenMobile-Site im Datencenter eines geografischen Standorts, die von allen Benutzer des Unternehmens weltweit genutzt wird. Dies ist die “primäre Site”.
  • Eine zweite XenMobile-Site im Datencenter eines zweiten geografischen Standorts, der “Notfallwiederherstellungssite”. Die Notfallwiederherstellungssite bietet aktiv-passives Sitefailover, wenn das Datencenter der primären Site ausfällt. Die primäre Site umfasst XenMobile, die SQL-Datenbank und die NetScaler-Infrastruktur zur Erleichterung des Failovers und damit die Benutzer bei einem Ausfall der Verbindung mit der primären Site Zugriff auf XenMobile haben.

Die XenMobile-Server der Notfallwiederherstellungssite sind im Normalbetrieb offline und werden nur online geschaltet, wenn ein vollständiges Sitefailover von der primären Site zur Notfallwiederherstellungssite erforderlich ist. Die SQL-Server der Notfallwiederherstellungssite müssen aktiv und verbindungsbereit sein, bevor Sie die XenMobile-Server der Site starten.

Diese Notfallwiederherstellungsstrategie basiert auf einem manuellen Failover der NetScaler-Zugriffsebene mittels DNS-Änderungen für das Routing von MDM- und MAM-Verbindungen zur Notfallwiederherstellungssite bei einem Ausfall.

Hinweis:

Die Verwendung dieser Architektur erfordert einen Prozess für asynchrone Sicherungen der Datenbanken sowie eine Methode zur Gewährleistung der hohen Verfügbarkeit der SQL-Infrastruktur.

Prozess der Notfallwiederherstellung

  1. Zum Testen des Failovers zur Notfallwiederherstellung fahren Sie die XenMobile-Server der primären Site herunter, um einen Siteausfall zu simulieren.
  2. Ändern Sie die öffentlichen DNS-Einträge der XenMobile-Server sodass sie auf die externen IP-Adressen der Notfallwiederherstellungssite verweisen.
  3. Ändern Sie den internen DNS-Eintrag für den SQL-Server sodass er auf die IP-Adresse des SQL-Servers der Notfallwiederherstellungssite verweist.
  4. Schalten Sie die XenMobile-SQL-Datenbanken der Notfallwiederherstellungssite online. Stellen Sie sicher, dass SQL-Server und -Datenbank aktiv sind und Verbindungen von den lokalen XenMobile-Servern bedienen können.
  5. Fahren Sie die XenMobile-Server der Notfallwiederherstellungssite hoch.

XenMobile Server-Updates

Führen Sie die nachfolgend aufgeführten Schritte bei jedem Update von XenMobile mit Patches und Releases aus, damit der Code der Server der primären Site und der Notfallwiederherstellungssite einheitlich bleibt.

  1. Stellen Sie sicher, dass die XenMobile-Server der primären Site aktualisiert wurden.
  2. Stellen Sie sicher, dass der DNS-Eintrag des SQL-Servers in die aktive SQL-Server-Datenbank der primären Site aufgelöst wird.
  3. Schalten Sie die XenMobile-Server der Notfallwiederherstellungssite online. Die Server stellen nur während des Upgrades eine Verbindung über das WAN zur Datenbank der primären Site her.
  4. Wenden Sie die erforderlichen Patches und Updates auf alle XenMobile-Server der Notfallwiederherstellungssite an.
  5. Starten Sie die XenMobile-Server neu und vergewissern Sie sich, dass das Upgrade erfolgreich war.

Diagramm der Referenzarchitektur für die Notfallwiederherstellung

Das folgende Diagramm zeigt eine Referenzarchitektur zur Notfallwiederherstellung bei XenMobile.

Diagramm der Referenzarchitektur für die Notfallwiederherstellung

GSLB für die Notfallwiederherstellung

Ein Schlüsselelement dieser Architektur ist die Verwendung von Global Server Load Balancing (GSLB), um den Datenverkehr zum richtigen Datencenter zu leiten.

Standardmäßig aktiviert der NetScaler für XenMobile-Assistent in NetScaler Gateway GSLB nicht für die Notfallwiederherstellung. Daher müssen Sie zusätzliche Schritte ausführen.

Funktionsweise von GSLB

GSLB ist im Prinzip eine Art DNS. Teilnehmende NetScaler-Geräte agieren als autorisierende DNS-Server und lösen DNS-Einträge in die richtige IP-Adresse auf (normalerweise in die VIP, die Datenverkehr empfangen soll). Das NetScaler-Gerät überprüft den Systemzustand, bevor es auf eine DNS-Abfrage reagiert, die den Datenverkehr zu diesem System leitet.

Nach der Auflösung für einen Datensatz ist die Aufgabe des GSLB erledigt. Der Client kommuniziert direkt mit der VIP des Ziels. Das Verhalten des DNS-Clients spielt eine wichtige Rolle dafür, wie und wann ein Datensatz abläuft. Dies übersteigt die Grenzen des NetScaler-Systems. Daher unterliegt GSLB denselben Einschränkungen wie die DNS-Namensauflösung. Bei Clients werden Antworten im Cache abgelegt. Ein Lastenausgleich ist somit nicht so schnell wie der herkömmliche Lastenausgleich.

Die Aufgabe der GSLB-Konfiguration von NetScaler, einschließlich Sites, Diensten und Monitoren, ist die korrekte DNS-Namensauflösung.

Die eigentliche Konfiguration für das Veröffentlichen von Servern (in diesem Szenario die vom NetScaler für XenMobile-Assistenten erstellte Konfiguration) ist nicht vom GSLB betroffen. GSLB ist ein eigener Dienst auf dem NetScaler.

Herausforderungen bei der Delegierung von Domänen bei Verwendung von GSLB für XenMobile

Der NetScaler für XenMobile-Assistent konfiguriert NetScaler Gateway für XenMobile. Der Assistent generiert drei virtuelle Lastausgleichsserver und einen virtuellen NetScaler Gateway-Server.

Zwei der virtuellen Lastausgleichsserver verarbeiten den MDM-Datenverkehr an Port 443 und 8443. NetScaler Gateway empfängt MAM-Datenverkehr und leitet ihn an den dritten Server, den virtuellen MAM-Lastausgleichsserver an Port 8443 weiter. Der gesamte Datenverkehr zum virtuellen MAM-Lastausgleichsserver wird über NetScaler Gateway übertragen.

Der virtuelle MAM-Lastausgleichsserver erfordert dasselbe SSL-Zertifikat wie die XenMobile-Server und verwendet den gleichen FQDN wie für die Registrierung von Geräten. Der MAM-Lastausgleichsserver verwendet auch denselben Port (8443) wie einer der MDM-Lastenausgleichsserver. Damit der Datenverkehr aufgelöst werden kann, erstellt der NetScaler für XenMobile-Assistent einen lokalen DNS-Eintrag in NetScaler Gateway. Der DNS-Eintrag entspricht dem zum Registrieren von Geräten verwendeten FQDN.

Diese Konfiguration ist wirksam, wenn die XenMobile-Server-URL keine GSLB-Domänen-URL ist. Wenn eine GSLB-Domänen-URL als URL des XenMobile-Servers verwendet wird – was für die Notfallwiederherstellung erforderlich ist – verhindert der lokale DNS-Eintrag, dass NetScaler Gateway Datenverkehr an die MDM-Lastausgleichsserver auflöst.

Verwenden der CNAME-Methode für die GSLB-Notfallwiederherstellung

Zur Bewältigung der Herausforderungen der vom NetScaler für XenMobile-Assistenten erstellten Standardkonfiguration können Sie in der übergeordneten Domäne einen CNAME-Eintrag für den FQDN des XenMobile-Servers erstellen (company.com) und auf einen Datensatz in der delegierten Unterzone verweisen (gslb.company.com), für die NetScaler zuständig ist. Dies ermöglicht die Erstellung des statischen DNS-A-Eintrags für die MAM-Lastausgleichs-VIP, die zum Auflösen des Datenverkehrs benötigt wird.

  1. Erstellen Sie im externen DNS einen CNAME für den FQDN des XenMobile-Servers, der auf den GSLB-Domänen-FQDN von NetScaler GSLB verweist. Sie benötigen zwei GSLB-Domänen: eine für MDM-Verkehr und eine weitere für MAM-Verkehr (NetScaler Gateway).

    Beispiel:

    CNAME = xms.company.com IN CNAME xms.gslb.comany.com

  2. Erstellen Sie in der NetScaler-Gateway-Instanz jeder Site erstellen Sie einen virtuellen GSLB-Server mit einem FQDN, auf den der CNAME-Eintrag verweist.

    Beispiel:

    bind gslb vserver xms-gslb -domainName xms.gslb.company.com

    Wenn Sie NetScaler Gateway mit dem NetScaler für XenMobile-Assistenten bereitstellen, verwenden Sie beim Konfigurieren des MAM-Lastenausgleichsservers die URL des XenMobile-Servers. Dabei wird ein statischer DNS-A-Eintrag für die URL des XenMobile-Servers erstellt.

  3. Führen Sie Tests mit Clients aus, die sich unter Einsatz der URL des XenMobile-Servers (xms.company.com) bei Secure Hub registrieren.

    In diesem Beispiel werden die folgenden FQDNs verwendet:

    • xms.company.com ist die URL, die vom MDM-Datenverkehr und von Geräten bei der Registrierung verwendet wird und die im vorliegenden Beispiel mit dem NetScaler für XenMobile-Assistenten konfiguriert wird.
    • xms.gslb.company.com ist der FQDN der GSLB-Domäne für den XenMobile-Server.