Citrix Virtual Apps and Desktops — Disaster Recovery Planning

Übersicht

Dieses Handbuch unterstützt die Planung von Business Continuity (BC) und Disaster Recovery (DR) Architektur sowie Überlegungen für On-Prem- und Cloud-Bereitstellungen von Citrix Virtual Apps and Desktops. DR ist ein wichtiges Thema in der Bandbreite an sich. Citrix erkennt an, dass dieses Dokument kein umfassender Leitfaden für die gesamte DR-Strategie ist. Es berücksichtigt nicht alle Aspekte von DR und nimmt manchmal eine höhere Begriffsperspektive auf verschiedene DR-Konzepte ein.

Dieser Leitfaden soll die folgenden Überlegungen behandeln, die erhebliche Auswirkungen auf die Citrix-Architektur eines Unternehmens haben, und entsprechende architektonische Anleitungen geben:

  • Geschäftsanforderungen
  • Disaster Recovery vs. Hohe Verfügbarkeit
  • Klassifizierungen der Disaster Recovery-Tierebene
  • Disaster Recovery-Optionen
  • Disaster Recovery in der Cloud
  • Überlegungen zu Vorgängen

Geschäftsanforderungen

Ausrichtung auf die “Business Layer” der Citrix Entwurfsmethodik, Erfassung klarer Geschäftsanforderungen und bekannter Einschränkungen für die Wiederherstellung von Service. Die Dokumentation dieser Elemente ist der Ausgangspunkt für die Entwicklung eines Wiederherstellungsplans für Citrix. Dieser Schritt trägt dazu bei, Klarheit über den Umfang zu schaffen und eine Richtung für die DR-Strategie zu geben, die am besten geeignet ist, die geschäftlichen und funktionalen Anforderungen und Einschränkungen zu erfüllen.

Nützliche Fragen, die beantwortet werden müssen, umfassen, sind aber nicht auf Folgendes beschränkt. Diese Fragen werden im Disaster Recovery-Optionen Abschnitt ausführlicher besprochen, wie sie sich auf ein Citrix DR-Design auswirken:

  • Backupstrategie und Recovery Time Objective (RTO). Welche Backup-Strategie wird heute für Server verwendet? Backup-Frequenz? Aufbewahrungsfrist? Offsite-Lagerung? Getestet? Muss die Citrix-Plattform im Katastrophenfall sofort verfügbar sein oder innerhalb eines bestimmten Zeitraums online geschaltet werden? (Siehe Disaster Recovery-Tierklassifizierungen). Es lohnt sich, Anwendungs-Back-Ends, mit denen sich Citrix gehostete Apps verbinden, in die Diskussion einzubeziehen, um die Erwartungen auszurichten.
  • Recovery Point Objective (RPO). Für RPO, welcher Grad des Datenverlustes gilt für DR tolerierbar, der je nach Infrastrukturkomponente oder Datenklassifizierung variieren kann? Wie alt können die wiederhergestellten Daten für den Dienst sein? 0 Minuten? Eine Stunde? Einen Monat? Im Kontext der Citrix Infrastruktur kann diese Überlegung nur für Datenbankänderungen und Benutzerdaten (Profile, Ordnerumleitung usw.) gelten. Wie bei RTO lohnt es sich, die Anwendungs-Backends für von Citrix gehostete Apps in die Diskussion einzubeziehen.
  • Umfang der Wiederherstellung. Diese Überlegung umfasst nicht nur die Citrix Infrastruktur, sondern kann Benutzerdaten oder wichtige Anwendungsserver umfassen, mit denen Citrix gehostete Anwendungsclients eine Schnittstelle herstellen. Es ist wichtig zu ermitteln, ob es einen Unterschied zwischen der Zeit für die Wiederherstellung der Citrix-Plattform und der Zeit für die Wiederherstellung von auf Citrix gehosteten Anwendungen geben wird. Das Zeitdelta kann einen Ausfall verlängern, da nur ein Teil der Lösung online ist.
  • Anwendungsfälle. Citrix Plattformen bedienen häufig zahlreiche Anwendungsfälle mit unterschiedlichen geschäftlichen kritischen Ebenen. Deckt die Wiederherstellung alle Citrix Anwendungsfälle ab? Oder wichtige Anwendungsfälle, von denen der betriebliche Erfolg des Unternehmens vollständig abhängt. Die Antwort hat einen großen Einfluss auf das Infrastruktur-Scoping und die Kapazitätsprognosen. Segmentierung und Priorisierung von Anwendungsfällen wird empfohlen, um die Aktivierung von DR zu unterteilen, wenn es sich um eine neue Funktion für die Citrix Umgebung handelt.
  • Fähigkeiten. Gibt es Schlüsselfunktionen, die nicht in die DR aufgenommen werden dürfen und die Kosten senken können? Ein Beispiel für diese Funktion wäre die Verwendung von persistenten Desktops im Vergleich zu nicht persistent; einige VDI-Anwendungsfälle, die von gehosteten Shared Desktops oder sogar bestimmten Anwendungssolos bedient werden können. Kunden haben zeitweise angegeben, dass Komponenten-Redundanz (ADCs, Controller, StoreFront, SQL usw.) in DR. Solche Entscheidungen können als Risiko angesehen werden, wenn ein längerer Produktionsausfall vorliegt.
  • Bestehende DR. Gibt es eine bestehende DR-Strategie oder einen Plan für andere Citrix Umgebungen und andere Infrastrukturdienste? Stellt es sich in neue routingfähige Subnetze oder in eine “Blase” -Spiegelung der Produktionsnetzwerke wieder her? Die Antwort kann dazu beitragen, die aktuellen DR-Ansätze, -Werkzeuge oder den Vorrang sichtbar zu machen.
  • Technologie-Funktionen. Diese Überlegung kann die endgültige Recovery-Strategie für Citrix nicht diktieren, es ist jedoch wichtig zu verstehen:
    • Recovery: Welche Speicherreplikationstechnologien, VM-Recovery-Technologien (VMware SRM, Veeam, Zerto, Azure Site Recovery (ASR) usw.) sind innerhalb des Unternehmens verfügbar? Einige Citrix Komponenten neben Citrix Abhängigkeiten können sie verwenden.
    • Citrix: Welche Citrix Technologien werden für die Imageverwaltung und den Zugriff verwendet? Einige Komponenten können sich für bestimmte Erholungsstrategien nicht gut eignen. Nicht persistente Umgebungen, die von MCS oder PVS verwaltet werden, bieten aufgrund ihrer engen Integration mit Speicher und Netzwerk schlechte Kandidaten für VM-Replikationstechnologien.
  • Datenkritikalität. Werden Benutzerprofile oder Benutzerdaten als kritisch für die Wiederherstellung angesehen? Persistente VDIs? Wenn diese Daten beim Aufruf von DR nicht verfügbar sind, würde dies erhebliche Auswirkungen auf die Produktivität haben? Oder kann ein nicht persistentes Profil oder VDI als temporäre Lösung verwendet werden? Diese Entscheidung kann die Kosten und die Komplexität der Lösungen in die Höhe treiben.
  • Arten von Katastrophen. Diese Entscheidung ist ziemlich bedeutend, kann aber auch durch einen BC- oder DR-Plan des Unternehmens festgelegt werden. Diese Anforderung diktiert oft den Wiederherstellungsort. Ist die Strategie nur für die Wiederherstellung des Dienstes auf Anwendungsebene vorgesehen? Zwischen Hardware-Racks? In einer Metro-Lage? Zwischen zwei Geographien? Zwei Länder? Innerhalb einer Cloud-Anbieter-Region oder der Infrastruktur eines gesamten Cloud-Anbieters (Multi-Region)?
  • Clientbenutzer. Wo befinden sich die Benutzer, die auf die Dienstleistungen in der Produktion zugreifen? Diese Entscheidung kann sich darauf auswirken, wo der Service wiederhergestellt wird, einschließlich der Netzwerkkonnektivität des Unternehmens, die während eines DR-Ereignisses manuelle Änderungen erfordern kann. Darüber hinaus diktiert die Antwort Überlegungen zu den Zugriffstufen.
  • Netzwerkbandbreite. Wie viel Datenverkehr (ICA, Anwendung, Dateidienste) verbraucht jede Benutzersitzung durchschnittlich? Diese Entscheidung gilt sowohl für Cloud- als auch für die lokale Wiederherstellung.
  • Fallback (oder Failback). Hat die Organisation bereits Pläne für die Rückkehr in den Dienst in der Produktion, nachdem die Notfallwiederherstellung gelöst wurde? Wie wird die Organisation in einen normalen Zustand wiederhergestellt? Wie werden neue Daten, die in der DR erstellt werden können, mit der Produktion in Einklang gebracht und konsolidiert?

Einschränkungen begrenzen BC/DR-Konstruktionsoptionen oder deren Konfigurationen. Sie kommen in vielen Formen vor, können aber Folgendes beinhalten:

  • Regulatorische oder Unternehmensrichtlinie. Diese Entscheidung kann vorschreiben, welche Technologien für die Replikation oder Recovery verwendet werden können oder nicht, wie sie verwendet werden, RTO oder Mindestabstand zwischen den Einrichtungen.
  • Infrastruktur. Gibt es eine Richtlinie über die Art der zu verwendenden Hardware, die verfügbare Netzwerkbandbreite usw.? Diese Überlegungen können sich auf RPO-Überlegungen auswirken oder sogar Risiken darstellen. Beispielsweise können unterdimensionierte Firewalls oder Netzwerk-Pipes in der DR letztendlich zu Ausfällen führen, da Netzwerkabhängigkeiten die DR-Arbeitslast nicht bewältigen können. Oder im Falle von Computing können unterdimensionierte Hypervisor-Hosts oder die Verwendung verschiedener Hypervisoren vollständig Auswirkungen auf die Optionen haben. In Bezug auf das Netzwerk, wenn die Wiederherstellungs-Site zufälligerer Netzwerkdurchsatz im Vergleich zur Produktion bei der Wartung des WAN ist. In Cloud-Umgebungen, insbesondere bei der Skalierung auf Tausende von Sitzen, kann dieses potenzielle Risiko aufgrund von Einschränkungen des Komponentendienstes wie virtuellen Firewalls, VPN-Gateways und Cloud-zu-WAN-Uplinks (AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect usw. am).
  • Budget. DR-Lösungen kommen mit Kosten, die mit Projektbudgets kollidieren können. Je kürzer die RTO ist, desto höher sind die Kosten.
  • Geographie. Wenn eine benannte DR-Einrichtung identifiziert wurde, müssen Überlegungen wie die Latenz von der Produktion zu DR-Einrichtungen zusätzlich zu den Benutzern, die eine Verbindung zur DR herstellen, verstanden werden.
  • Datenresidenz oder Datenklassifizierung. Diese Entscheidung kann Optionen in Bezug auf Gebietsschemas und Technologien oder Wiederherstellungsmethoden einschränken.
  • Cloud Recovery. Gibt es ein Mandat für die Wiederherstellung der Infrastruktur in der Cloud im Vergleich zu einer On-Prem-Einrichtung?
  • Anwendungsbereitschaft. Haben die auf Citrix gehosteten Anwendungen mit Back-End-Abhängigkeiten einen BC/DR-Plan und wie werden die RTOs mit der Ziel-RTO von Citrix ausgerichtet? Citrix kann für eine schnelle Recovery konzipiert werden, aber wenn Kernanwendungen keinen Wiederherstellungsplan oder einen mit einem erweiterten RTO haben, hat dieses Risiko wahrscheinlich Auswirkungen auf die Nützlichkeit der Citrix-Plattform in DR.
  • Netzwerksicherheit. Verfügt die Organisation über Sicherheitsrichtlinien, die festlegen, welche Verkehrssegmente während der Übertragung verschlüsselt werden müssen? Ist diese Überlegung abhängig von der durchlaufenen Netzwerkverbindung unterschiedlich? Die Antwort könnte in DR-Szenarien die Verwendung von SSL VDA, ICA-Proxy, GRE oder IPSec-VPN-Einkapselung des ICA-Verkehrs erfordern, wenn sich die Netzwerkflüsse für DR von der Produktion unterscheiden.

Missverständnisse bei Disaster Recovery (DR) Design

Eine der häufigsten Missverständnisse für Citrix DR-Designs, auf die in diesem Artikel verwiesen wird, ist die Vorstellung, dass eine einzelne Steuerungsebene, die sich über zwei Rechenzentren erstreckt, DR. Das tut es nicht. Ein einzelner Citrix Standort oder PVS Farm, die Rechenzentren umfasst, auch wenn sie in der Nähe sind, stellt ein Design mit hoher Verfügbarkeit dar, jedoch kein DR-Design. Einige Kunden entscheiden sich für diesen Weg als Geschäftsentscheidung, bei der die vereinfachte Verwaltung über die DR-Funktion bewertet werden. Die ergreifenden StoreFront-Servergruppen unterstützt bestehen nur zwischen gut vernetzten Rechenzentren (niedrige Latenz). In ähnlicher Weise wurden Latenzmaxima dokumentiert, die bei der Bereitstellung in Rechenzentren zu berücksichtigen sind, wie in beschrieben CTX220651.

Das folgende Diagramm ist ein Beispiel für eine Multi-Datacenter HA Citrix Architektur, die jedoch aufgrund der zuvor erwähnten Begründung keine DR-Plattform ist. Diese Referenzarchitektur wird von Kunden verwendet, die aufgrund ihrer Nähe zueinander und geringer Latenz und hoher Bandbreite zwei physisch getrennte Rechenzentrumseinrichtungen als ein einziges logisches Rechenzentrum behandeln. Ein DR-Plan und eine Umgebung für Citrix würden weiterhin empfohlen, da diese Architektur die Anforderungen von DR oder HA wahrscheinlich nicht erfüllen würde.

Notfallwiederherstellung

Zusätzlich zu der oben genannten konzeptionellen HA-Referenz stehen HA-Architekturen mit Zonen für Kunden zur Verfügung, die geografische Redundanz bereitstellen möchten, die jedoch nicht vollständig wiederherstellbar sein möchten. Das Zonenkonzept aus der Legacy-IMA-Architektur (XenApp 6.5 und niedriger) wurde für FMA überarbeitet und in XenDesktop 7.7 mit großen Verbesserungen in 7.11 wieder eingeführt und ermöglicht verschiedene Funktionen für die Redundanz an Standorten, die Herausforderungen für Bereitstellungen mit mehreren Standorten lösen können.

In einer Site-Architektur, die die Funktion Zonen-P (7.11 und höher) verwendet, werden identische Citrix Ressourcen in mehreren Zonen bereitgestellt und zu einer einzigen Bereitstellungsgruppe zusammengefasst. Die Zonenpräferenz (mit der Möglichkeit, auf andere Zonen für eine bestimmte Ressource zurückzuteilen) kann basierend auf der Anwendung, der Heimatzone des Benutzers oder dem Benutzerstandort gesteuert werden. Weitere Informationen Zone Preference Internals zu diesem Thema finden Sie unter. Das VDA-Registrierung Auto-Update-Feature (eingeführt in XenDesktop 7.6) ermöglicht es VDAs, eine lokal zwischengespeicherte aktuelle Liste aller Controller innerhalb einer Site zu verwalten. Mit dieser Funktion können VDAs innerhalb der Satellitenzone über die Registrierung bei VDAs in der primären Zone fehlschlagen, falls ihre lokalen Delivery Controller oder Cloud Connectors in ihrer lokalen Zone nicht verfügbar sind. StoreFront-Servergruppen sind an jedem Zonenstandort vorhanden, da Benutzer weiterhin auf Ressourcen von ihrer lokalen Zugriffsstufe zugreifen können, falls die primäre Zone nicht verfügbar ist.

Notfallwiederherstellung

Im Gegensatz zu diesen unterstützten HA-Optionen zeigt das folgende Diagramm nicht unterstützte oder schlecht beratene Komponentenarchitekturen, die sich über geografisch entfernte Rechenzentren oder Cloud-Regionen erstrecken. Diese Diagramme bieten aufgrund des Abstands und der Latenz zwischen Komponenten weder effektive HA noch DR. Probleme mit der Plattformstabilität können auch aufgrund von Bedenken hinsichtlich der Latenz bei einer solchen Bereitstellung auftreten. Darüber hinaus richtet sich die Ausdehnung von Verwaltungsgrenzen zwischen Standorten nicht an DR-Prinzipale aus. Wir haben in der Vergangenheit ähnliche konzeptionelle Designs von Kunden gesehen.

Notfallwiederherstellung

Ein weiteres weit verbreitetes Missverständnis ist die Tiefe der Überlegung, die eine Citrix DR-Lösung beinhalten kann. Citrix Virtual Apps and Desktops ist im Kern in erster Linie eine Präsentations- und Bereitstellungsplattform. Die Citrix Steuerungsebene hängt von anderen Komponenten (Netzwerk, SQL, Active Directory, DNS, RDS-CALs, DHCP usw.) ab, deren eigenes Verfügbarkeits- und Recovery-Design die DR-Anforderungen der Citrix-Plattform erfüllt. Jede gemeinsame administrative Domäne von Technologien, von denen Citrix abhängig ist, kann sich auf die Wirksamkeit der Citrix DR-Lösung auswirken.

Von ähnlicher Bedeutung und gelegentlich nicht vollständig von Kunden berücksichtigt werden, sind Überlegungen zur Wiederherstellung von Dateiservices (Benutzerdaten und Geschäftsdaten auf Freigaben usw.) und Anwendungs-Backends, mit denen Citrix gehostete Anwendungen und Desktops interagieren. Wenn Sie den früheren Punkt der Anwendungsbereitschaft referenzieren, kann eine Citrix DR-Plattform so konzipiert werden, dass sie in kurzen Zeitspannen wiederhergestellt werden kann. Wenn diese Kern-Anwendungsfallabhängigkeiten jedoch keinen Wiederherstellungsplan mit RTO ähnlich wie Citrix oder gar keinen Wiederherstellungsplan besitzen, kann dieser Plan die erfolgreiche Ausfälle von Citrix in der DR wie erwartet beeinträchtigen, aber Benutzer können ihre Auftragsfunktionen nicht ausführen, da diese Abhängigkeiten nicht verfügbar sind. Nehmen wir zum Beispiel ein Krankenhaus, das ihre Kern-EMR-Anwendung auf Citrix hostet. Ein DR-Ereignis tritt auf und Citrix schlägt auf eine “Always on” Citrix Plattform in der DR fehl und Benutzer stellen eine Verbindung her, aber die EMR-Anwendung wird auf mehr manuelle Weise wiederhergestellt, was Stunden oder Tage dauern kann. Das klinische Personal wäre in dieser Zeit wahrscheinlich gezwungen, Offline-Prozesse (Stift und Papier) zu verwenden. Ein solches Ergebnis kann nicht mit der allgemeinen Erwartung des Unternehmens nach Erholungszeit oder Benutzererfahrung übereinstimmend sein.

Im nächsten Abschnitt werden DR vs. HA im Detail.

Disaster Recovery (DR) vs. Hochverfügbarkeit (HA)

Verständnis von HA vs. DR ist entscheidend für die Ausrichtung auf die Anforderungen der Organisation und die Erfüllung der Wiederherstellungsziele. HA ist nicht gleichbedeutend mit DR, aber DR kann HA verwenden. In diesem Handbuch werden HA und DR wie folgt interpretiert:

  • HA gilt als Fehlertoleranz für eine Dienstleistung. Ein Dienst kann mit einem Failover auf ein anderes System mit minimaler Unterbrechung für einen Benutzer ausgeführt werden. Die Lösung kann so einfach sein wie eine Cluster- oder Lastausgleichsanwendung für eine komplexere aktive oder Standby-“heiße” oder “Always on” -Infrastruktur, die die Produktionskonfigurationen widerspiegelt und immer verfügbar ist. Failover wird in diesen Konfigurationen tendenziell automatisiert und kann auch als “georedundante” Bereitstellung bezeichnet werden.
  • DR befasst sich in erster Linie mit der Wiederherstellung von Diensten (aufgrund eines erheblichen Ausfalls auf App-Ebene oder eines katastrophalen physischen Ausfalls des Rechenzentrums) an einem alternativen Rechenzentrum (oder einer Cloud-Plattform). DR beinhaltet tendenziell automatisierte oder manuelle Wiederherstellungsprozesse. Schritte und Verfahren werden dokumentiert, um die Wiederherstellung zu orchestrieren. Es geht nicht um Redundanz oder Fehlertoleranz des Dienstes und ist im Allgemeinen eine umfassendere Strategie, die mehreren Arten von Ausfällen standhält.

Während HA tendenziell in Entwurfsspezifikationen und Lösungsbereitstellung eingebettet ist, befasst sich DR weitgehend mit der Orchestrierung von Personal- und Infrastrukturressourcen, um die Wiederherstellung des Dienstes zu ermöglichen.

Kann HA DR enthalten? Ja. Für unternehmenskritische IT-Services in Unternehmen ist dieses Konzept üblich. Nehmen wir zum Beispiel das zweite Beispiel in der obigen HA-Beschreibung, verbunden mit einer angemessenen Wiederherstellung anderer Nicht-Citrix-Komponenten, die mit der Lösung zusammenhängen, würde als hochverfügbare DR-Lösung angesehen werden, bei der ein Dienst (Citrix) an ein gegenüberliegender Rechenzentrum ausfällt. Diese spezielle Architektur kann als Active-Passive oder Active-Active in verschiedenen Multi-Site-Iterationen implementiert werden, z. B. Active-Passive für alle Benutzer, Active-Active, wobei Benutzer ein Rechenzentrum gegenüber einem anderen bevorzugen, oder Aktiv-Aktiv, wobei Benutzer ohne Präferenz zwischen zwei Rechenzentren Lastenausgleich haben. Es ist wichtig zu beachten, dass beim Entwurf solcher Lösungen die Standby-Kapazität kontinuierlich berücksichtigt, berücksichtigt und die Last überwacht werden muss, um sicherzustellen, dass die Kapazität für die Aufnahme von DR verfügbar bleibt, wenn dies erforderlich ist.

Es ist auch wichtig, dass DR-Komponenten mit der Produktion auf dem neuesten Stand gehalten werden, um die Integrität der Lösung zu erhalten. Diese Aktivität wird häufig von Kunden übersehen, die eine solche Lösung mit den besten Absichten entwerfen und bereitstellen, dann mehr Plattformressourcen in der Produktion verbrauchen und vergessen, die verfügbare Kapazität zu erhöhen, um die DR-Integrität der Lösung zu erhalten.

Im Zusammenhang mit Citrix veröffentlichter Leitfaden würde die Umspannende Citrix Administrative Domains (Citrix Site, PVS Farm usw.) zwischen zwei Rechenzentren wie zwei geolokalisierten Einrichtungen wie der keine DR und für einige Komponenten wie StoreFront Server Groups darstellen. In ähnlicher Weise würde eine solche Bereitstellung aufgrund der Beschränkungen der veröffentlichter LeitfadenDatenbanklatenz von PVS wahrscheinlich auch nicht unterstützt. Die Einschränkungen der Unterstützbarkeit zwischen Geos erstrecken sich auch auf das Citrix Site- und Zonendesign, manchmal aufgrund von Latenzmaxima zwischen Satelliten-Controllern und den Datenbanken pro veröffentlichter Leitfaden.

Da viele Citrix Komponenten Abhängigkeiten wie Datenbanken gemeinsam nutzen, würde die Ausdehnung von Verwaltungsgrenzen zwischen den beiden Rechenzentren nicht vor mehreren wichtigen Ausfallszenarien schützen. Wenn Datenbanken beschädigt werden, würde sich die Fehlerdomäne auf die Anwendungsdienste in beiden Einrichtungen auswirken. Um eine HA Citrix Lösung als ausreichend für die DR zu betrachten, empfehlen wir, dass die zweite Einrichtung keine wichtigen Abhängigkeiten oder Verwaltungsgrenzen teilt. Erstellen Sie beispielsweise separate Sites, Farmen und Servergruppen für jedes Rechenzentrum in der Lösung. Indem wir eine Wiederherstellungsplattform so unabhängig wie möglich machen, reduzieren wir die Auswirkungen von Ausfällen auf Komponentenebene, die sich auf Produktions- und DR-Umgebungen auswirken. Diese Überlegung geht auch über Citrix hinaus, und die Verwendung verschiedener Dienstkonten, Dateidienste, DNS, NTP, Hypervisor-Management, Authentifizierungsdienste (AD, RADIUS usw.) zwischen Produktions- und DR-Umgebungen wird ebenfalls empfohlen, um einzelne Fehlerquellen zu reduzieren.

Klassifizierungen der Disaster Recovery-Tierebene

Tierklassifizierungen für DR sind ein wichtiger Aspekt einer DR-Strategie von Organisationen, da sie Klarheit in der Anwendungs- oder Dienstkritik bietet, was wiederum die RTO (und damit die Kosten für die Erreichung dieser Wiederherstellungsstufe) diktiert. Im Allgemeinen gilt: Je kürzer der RTO, desto höher sind die Kosten für die DR-Lösung. Die Aufschlüsselung verschiedener Abhängigkeiten in verschiedene Klassifizierungen (basierend auf Unternehmenskritikalität und RTO) kann dazu beitragen, kostensensible DR-Fälle zu optimieren.

Im Folgenden finden Sie eine Reihe von Beispiel-Klassifizierungen für die DR-Ebene, die als Referenz bei der Bewertung der Citrix Infrastrukturdienste, ihrer Abhängigkeiten und kritischen Anwendungen oder Anwendungsfällen (und die mit VDAs verknüpft sind), die auf Citrix gehostet werden. DR-Tiers werden in der Reihenfolge oder in der Wiederherstellungspriorität skizziert, wobei 0 die kritischste ist. Organisationen werden ermutigt, eine DR-Tiering-Klassifizierung anzuwenden oder zu entwickeln, die auf ihre eigenen Wiederherstellungsziele und Klassifizierungsanforderungen abgestimmt ist.

Disaster Recovery Tier 0

Tier 0 - Wiederherstellungsziele (Beispiele)

Wiederherstellungszeitziel: 0

Ziel des Wiederherstellungspunkts: 0

Tier 0 - Klassifizierungsbeispiele

Kern-IT-Infrastruktur

  • Netzwerk- und Sicherheitsinfrastruktur
  • Netzwerkverbindungen
  • Hypervisoren und Abhängigkeiten (Computing, Storage)

Wichtige IT-Services

  • Active Directory
  • DNS
  • DHCP
  • Dateidienste
  • RDS-Lizenzierung
  • Wichtige Endbenutzerdienste (Citrix)

Tier 0 - Hinweise

Diese Klassifizierung gilt hauptsächlich für Kerninfrastrukturkomponenten. Diese Komponenten sind immer am DR-Standort verfügbar, da sie Abhängigkeiten für andere Ebenen und nicht in einem isolierten Netzwerksegment sind. Sie müssen neben ihren Produktionsäquivalenten bereitgestellt und gewartet werden. Wenn Citrix kritische Anwendungen hostet, wird dies wahrscheinlich als Tier-0-Plattform angesehen. In solchen Szenarien wird die Citrix Infrastruktur “heiß” in DR.

Disaster Recovery Tier 1

Tier 1 - Wiederherstellungsziele (Beispiele)

Wiederherstellungszeit Ziel: 4 Stunden

Ziel des Wiederherstellungspunkts: 15 Minuten

Tier 1 - Klassifizierungsbeispiele

Kritische Anwendungen

  • Websites und Web-Apps
  • ERP- und CRM-Anwendungen
  • Branchenanwendungen

Citrix Anwendungsfälle

  • Verwaltung
  • Kundendienst oder Vertrieb
  • IT Engineering & Support

Tier 1 - Hinweise

Anwendungen oder virtuelle Desktops, auf die das Unternehmen angewiesen ist, um die Kerngeschäftsaktivitäten auszuführen, sind in der Regel in dieser Ebene enthalten. Sie würden wahrscheinlich auch eine ähnliche “Hot Standby” -DR-Architektur wie Tier 0 verwenden oder von einer automatisierten Replikations- und Failover-Lösung profitieren. Bei der Bereitstellung in der Cloud müssen Überlegungen berücksichtigt werdenspäter diskutiert, da sie sich auf RTO Ziele auswirken können.

Disaster Recovery Tier 2

Tier 2 - Wiederherstellungsziele (Beispiele)

Wiederherstellungszeit Ziel: 48 Stunden

Ziel des Wiederherstellungspunkts: 1 Stunde

Tier 2 - Klassifizierungsbeispiele

Nicht kritische Anwendungen Nicht kritische Citrix Anwendungsfälle Benutzerdaten, die sich nicht auf die Funktionalität von Tier 1- oder Tier 0-Apps auswirken.

Tier 2 - Hinweise

Anwendungen oder Anwendungsfälle, die für den Geschäftsbetrieb von entscheidender Bedeutung sind, deren kurzfristige Nichtverfügbarkeit jedoch keine ernsthaften finanziellen, guten Ruf oder betrieblichen Auswirkungen hat. Diese Anwendungen werden entweder aus Backups wiederhergestellt oder durch automatisierte Wiederherstellungstools als niedrigste Priorität wiederhergestellt.

Disaster Recovery Tier 3

Tier 3 - Wiederherstellungsziele (Beispiele)

Wiederherstellungszeitziel: 5 Tage

Ziel des Wiederherstellungspunkts: 8 Stunden

Tier 3 - Klassifizierungsbeispiele

Selten verwendete Anwendungen

Tier 3 - Hinweise

Anwendungen mit vernachlässigbaren Ausflüssen auf Ausfälle sind bis zu einer Woche nicht verfügbar. Diese Anwendungen werden wahrscheinlich aus Backups wiederhergestellt.

Disaster Recovery Tier 4

Tier 4 - Wiederherstellungsziele (Beispiele)

Recovery-Zeit-Ziel: 30 Tage

Ziel des Wiederherstellungspunkts: 24 Stunden oder keine

Tier 4 - Klassifizierungsbeispiele

Nicht-Produktionsumgebungen

Tier 4 - Hinweise

Anwendungen, Infrastruktur und VDIs, deren Ausfälle sich ebenfalls vernachlässigbar auf den Geschäftsbetrieb auswirken und über einen längeren Zeitraum wiederhergestellt werden können. Sie können auch ein erweitertes RPO haben, oder überhaupt nicht, abhängig von ihrer Natur. Diese RPOs können aus Backups wiederhergestellt oder in der DR brandneu gebaut werden und gelten als die letzte zurückzufindende Stufe.

Warum ist die Tierklassifizierung für die Citrix DR-Planung wichtig?

Die Tierklassifizierung ist für Citrix aus folgenden Gründen wichtig:

  • Wie wichtig ist die Citrix Infrastruktur für Geschäftsabläufe? Es ist wichtig zu berücksichtigen, dass die Citrix Infrastruktur als kritisch eingestuft wird, wenn Citrix als wichtig erachtet wird, eine von ihr gehostete Anwendung jedoch als kritisch angesehen wird.
  • Die Anwendungsfälle oder Kerngeschäftsanwendungen, die von Citrix gehostet werden. Haben sie unterschiedliche DR-Tier-Klassifizierungen?

Bei der ersten Frage werden viele Citrix-Enterprise-Bereitstellungen aufgrund der Bereitstellung kritischer Apps oder Desktops in der Regel als Tier 0 klassifiziert; die “Always on” -Tier wie Netzwerk-, Active Directory-, DNS- und Hypervisor-Infrastruktur. Dieser Umstand ist jedoch nicht immer für jeden Citrix Anwendungsfall der Fall. Die Behandlung jedes Citrix Anwendungsfalls als Tier 0, wenn einige in Tier 1 oder höher fallen können, kann sich dies auf die Gesamtkosten und die Komplexität des DR-Prozesses auswirken.

Die zweite Frage betont die Klassifizierung nach Citrix-Anwendungsfall und ist besonders in Cloud-Umgebungen von Bedeutung, wie an dieser Stelle später näher diskutiert wird. In der Cloud gibt es erhebliche Kostenüberlegungen zwischen der Berücksichtigung von “Always on” Anwendungs- oder Desktop-Plattformen im Vergleich zu Anwendungen oder Desktops, die als weniger geschäftskritisch angesehen werden. Solche Überlegungen können auch die Anwendungs- oder Anwendungsfallisolation (Silos) in der Produktion beeinflussen, um die Flexibilität der Bereitstellung in einer DR-Plattform zu nutzen.

Bei der Erstellung eines DR-Entwurfs für Citrix ist es sinnvoll, die Diskussion über den Anwendungsbereich von Citrix selbst hinaus zu bringen, um Erwartungen an Geschäftseinheiten zu setzen. Beispielsweise gilt eine Citrix-Umgebung als “Always on”-Dienst und wird in einem alternativen Rechenzentrum hochverfügbar gemacht. Die kritischen Anwendungs-Backends, von denen die gehosteten Anwendungen von Citrix abhängen, bleiben jedoch mehrere Stunden lang nicht verfügbar, wenn die Wiederherstellung aufgerufen wird. Diese Lücke führt zu einer Disparität in der Wiederherstellungszeit zwischen den beiden Plattformen und kann während der Wiederherstellung eine irreführende Benutzererfahrung bieten. Citrix ist sofort verfügbar, aber wichtige Anwendungen sind nicht funktionsfähig. Die Festlegung von Erwartungen zu Beginn bietet allen Stakeholdern eine angemessene Sichtbarkeit darüber, wie die Erholungserfahrung aussehen kann. In einigen Situationen kann ein Kunde Citrix in der gegnerischen Einrichtung auf Hot Standby (immer aktiv) halten, aber das Failover der Zugriffsstufe manuell steuern, um Missverständnisse bei der Plattformverfügbarkeit zu vermeiden.

Disaster Recovery-Optionen

In diesem Abschnitt werden gängige Citrix Wiederherstellungsstrategien beschrieben, einschließlich ihrer Vor- und Nachteile und wichtiger Überlegungen. Weitere Wiederherstellungsfunktionen oder Variationen der folgenden Designs für Citrix sind möglich. Dieser Abschnitt konzentriert sich auf einige der häufigsten. Darüber hinaus veranschaulicht dieser Abschnitt, wie die Antworten auf die frühzeitig dargestellten Kernfragen auf das DR-Design beeinflussen.

Die folgenden Fragethemen, die zu viele der früheren DR-Fragen korrelieren, haben folgende Auswirkungen auf das Design von Citrix DR:

  • Backupstrategie und Recovery Time Objective (RTO). Wenn die Citrix Infrastruktur oder Anwendungen, die von Citrix bereitgestellt werden, als unternehmenskritisch angesehen werden, ist es wahrscheinlich, dass Citrix ein “Always on” -Modell einsetzen muss, bei dem sich in zwei oder mehr Rechenzentren eine Hot-Standby- oder Active-Active-Citrix-Infrastruktur befindet. Diese Architektur würde dazu führen, dass in jedem Rechenzentrum mehrere unabhängige Citrix-Steuerungsebenen erstellt werden (separate Citrix Standorte, ggf. PVS-Farmen, StoreFront-Servergruppen usw.). Das Überspannen der Steuerungsebenen für die Citrix Infrastruktur stellt keine DR dar (z. B. die Überspannungseinheit einer Site über Rechenzentren hinweg oder die Verwendung von Satellitenzonen). Dies tut dies, wenn das Unternehmen eine DR-Plattform für Citrix erwartet, die auf dieses Mandat einwirkt.
  • Umfang der Wiederherstellung. Wenn Citrix in einer Hot-Standby-Kapazität (immer aktiv) in der DR bereitgestellt wird, die Backends der Kerngeschäftsanwendung jedoch beispielsweise 8 Stunden dauern, kann die Wiederherstellung nicht sinnvoll sein, ein automatisiertes Zugriffsstufen-Failover einzusetzen. Manuelles Failover der Zugriffsstufe kann angemessener sein.
  • Anwendungsfälle. Wenn nur kritische Workloads oder Kernanwendungen in Citrix schnell wiederhergestellt werden müssen, um den Geschäftsbetrieb in einem DR-Szenario aufrechtzuerhalten, kann dieses Szenario die DR-Kosten aus Kapazitätsperspektive wahrscheinlich senken. Wenn mehrere Anwendungsfälle mit unterschiedlichen Prioritäten eine Wiederherstellung erfordern, kann die Klassifizierung der Bedeutung pro Anwendungsfall im Gegensatz zu den geschäftlichen Auswirkungen der Recovery-Tering-Strategie bereits besprochen nicht die Kapazitätskosten senken, bietet den IT-Mitarbeitern jedoch einen fokussierteren Satz von Recovery-Prioritätsaufträgen.
  • Fähigkeiten. Wenn bestimmte Komponenten wie HDX Insight, Session Recordings nicht als kritisch für den Betrieb der DR-Plattform angesehen werden, beseitigt ihre Unterlassung in der DR-Umgebung einen gewissen Komplexitäts- und Wartungsaufwand. Wenn viele Anwendungsfälle in einem DR-Szenario von einer einfacheren und generischeren Citrix Bereitstellungsoption in der DR bestehen können, kann dies auch die Komplexität und die Kosten reduzieren. Beispielsweise die Verwendung eines gehosteten freigegebenen Desktops anstelle eines gepoolten VDI, falls technisch machbar, oder das Aggregieren mehrerer Anwendungsfälle zu einem, vorausgesetzt sie sind nicht schädlich für den Geschäftsbetrieb. Notfallwiederherstellung
  • Bestehende DR. Wenn die vorhandene DR-Strategie des Unternehmens beispielsweise Citrix und andere Anwendungsinfrastrukturen mithilfe von Tools zur Datenreplikation und -orchestrierung wiederherstellt, können die meisten Citrix Komponenten für dieses Modell geeignet sein. Wenn die Größe der Plattform und die Abhängigkeit von der Single-Image-Verwaltungstechnologie eine Anforderung für die Produktionsplattform ist, können solche Technologien oft nicht geeignet sein. Ein hybrider Ansatz einer Hot-Standby-Citrix-Plattform und möglicherweise die Replikation von Master-Images können angemessener sein.
  • Datenkritikalität. Wenn Profile für die Wiederherstellung in der DR als kritisch erachtet werden, kann eine angemessene Replikationstechnologie erforderlich sein. Viele Organisationen beschäftigen sich weniger mit Profilen in DR-Szenarien und akzeptieren, dass sie neu erstellt werden. Diese Überlegung gilt auch für Benutzerdaten, auf die in Citrix zugegriffen wird (Ordnerumleitung, zugeordnete Laufwerke); RPO und RTO für diese Daten können eine Geschäftsentscheidung sein. Wenn viele persistente VDIs als wichtig genug erachtet werden, um in der DR intakt zu bleiben (anstatt dass Benutzer ihre Software neu installieren müssen usw.), müssen diese VMs für die Replikation in Betracht gezogen werden, was zusätzliche Kosten für die Unterstützung der Wiederherstellung verursachen kann.
  • Arten von Katastrophen. Das Ausmaß, in dem sich ein Kunde vor Fehlern schützen möchte, kann verschiedene architektonische Veränderungen vorschreiben. Wenn der Kunde nur HA der Citrix Infrastruktur innerhalb des Rechenzentrums oder der Cloud-Region wünscht, kann diese Art von Katastrophe lediglich sicherstellen, dass die Managementkomponenten sowohl redundant sind als auch auf gegensätzlichen Infrastrukturen arbeiten. Beispielsweise verwendet eine Art von StoreFront-Serverpaar VMware Anti-Affinitätsregeln, um auf verschiedenen Hosts in einem Cluster oder auf verschiedenen Clustern vollständig innerhalb des Rechenzentrums oder möglicherweise als Teil verschiedener Verfügbarkeitssätze zu arbeiten. Für diese Situation ist es selten erforderlich, redundante Steuerungsebenen vollständig zu erstellen (z. B. mehrere Citrix Sites und StoreFront-Servergruppen). Wenn DR jedoch mehrere Rechenzentren unabhängig von der Region umfassen soll, sind redundante Steuerungsebenen, die lokale Abhängigkeiten in jedem Rechenzentrum (AD, DNS, SQL, Hypervisor usw.) verwenden, angemessener. Wenn der Kunde global ist und mehrere Rechenzentren verwendet, um Citrix mit entsprechenden Anwendungs-Back-Ends lokal in diesen Rechenzentren zu bedienen (oder dies plant), ist es wahrscheinlicher, dass eine geolokalisierte Active-Active HA-DR-Architektur besser geeignet ist. Diese Architektur bietet Benutzern die optimale Benutzererfahrung, wenn möglich, indem geolokalisierte Citrix-Infrastrukturen verwendet werden, die bei Bedarf in einer sekundären Präferenzreihenfolge an ein Backup-Rechenzentrum übergeben werden können.
  • Clientbenutzer. Neben dem obigen Punkt über Überlegungen zur Benutzer-, App- und Datenlokalisierung können einige Client-Benutzernetzwerke relativ mit Sicherheitsgeräten (Proxy, Firewall usw.) gesperrt werden, die ausgehende Kommunikation mit dem Internet oder sogar dem WAN einschränken können. Es ist wichtig zu prüfen, ob dieser Status für die Client-Netzwerke gilt, und sicherzustellen, dass neue IPs für Citrix IPs (wie StoreFront VIP- und VDA-IPs oder Citrix Gateway IP) in ihren lokalen Sicherheitskonfigurationen berücksichtigt werden, um sicherzustellen, dass keine weiteren Verzögerungen bei der Wiederherstellung aufgrund der lokalen LAN-Sicherheit auftreten Einschränkungen beim Aufrufen von DR. Wird sich der Kundenzugang aus Sicht der Bereitschaft im Falle einer DR auf irgendeine Weise ändern? In einigen DR-Szenarien kann ein Kunde davon ausgehen, dass das WAN nicht verfügbar ist und alle Benutzer über das Internet auf Citrix-Ressourcen zugreifen müssen. Für solche Schritte wären eine Dokumentation im BC und Bereitschaftspläne erforderlich, mit Voraussetzungen für Endbenutzer (in Bezug auf unterstützte Citrix Clientdetails, Annahmen für den Zugriff auf Unternehmens- oder BYOD-Geräte), um Hindernisse für Benutzer zu beseitigen, die an den Service zurückkehren, wodurch die Belastung des Supportpults weiter reduziert wird.
  • Netzwerkbandbreite. Die Menge der Netzwerkbandbreite, die in Bezug auf den VDA-Verkehr (ICA, Anwendungen, File-Services) verwendet wird, muss in die Dimensionierung und Firewalls des DR-Einrichtungsnetzwerks einbezogen werden. Diese Überlegung ist besonders wichtig in Cloud-Umgebungen, in denen Beschränkungen für VPN-Gateways und virtuelle Firewall-Kapazitäten bestehen. Die Überwachung des Produktionsdatenverkehrs von VDAs zur Ermittlung eines Durchschnittswerts für die Dimensionierung ist wichtig, um die Netzwerkgröße effektiv zu gestalten. Wenn Netzwerkeinschränkungen bestehen, müssen Unternehmen unterschiedliche Netzwerkkonfigurationen verwenden, um die erwartete DR-Verkehrslast zu berücksichtigen, wenn und wenn sie aufgerufen werden. Die WAN-Optimierungstechnologie von Citrix SD-WAN kann dabei helfen, den Verkehrsanspruch zu senken.
  • Fallback (oder Failback). Wenn Benutzerdaten, die sich in der DR geändert haben, oder wenn sich VDA-Images während der DR in der DR geändert haben, muss die Organisation ein Failback planen, um diese Änderungen wieder auf die Produktion zu übertragen, ist die Produktionsumgebung als wiederherstellbar. Für Benutzerdaten kann es so einfach sein wie die Umkehrung der Replikationsreihenfolge und die Wiederherstellung; in ähnlicher Weise für die Citrix Infrastruktur, wenn keine einzelnen Image-Management-Technologien verwendet werden. Bei Verwendung von MCS oder PVS können Masterimages oder vDisks manuell auf die Produktion zurückgeführt und VDAs entsprechend aktualisiert werden.

In der folgenden Liste werden verschiedene allgemeine Wiederherstellungsoptionen für Citrix beschrieben. Anpassungen von jedem existieren auf dem Gebiet, aber zum Vergleich skizzieren wir grundlegende Versionen von jedem. Die Optionen sind beginnend mit den einfachsten (oft höheren RTO und niedrigeren Kosten) durch die fortgeschritteneren (oft niedrigeren RTO, aber höhere Kosten) organisiert. Die ideale Option für eine bestimmte Organisation besteht darin, sich zusätzlich zu den verfügbaren IT-Fähigkeiten, dem Budget und der Infrastruktur an die Wiederherstellungszeit für gehostete Anwendungen oder Anwendungsfälle anzupassen. Obwohl dies möglich ist, weisen viele Optionen darauf hin, dass in Netzwerk und Speicher integrierte Citrix-Technologien wie ADC- und Single-Image-Management-Technologien nicht für andere Methoden als “Always on” Recovery-Modelle geeignet sind. Es ist nicht so, dass es technisch unmöglich ist, zu erreichen, aber die Komplexität, die bei ihrer Durchführung beteiligt ist, kann die Wiederherstellung riskanter und anfälliger für menschliche Fehler machen.

Wiederherstellungsoption - Wiederherstellen von Offline-Sicherung

Notfallwiederherstellung

Vor- und Nachteile

Vorteile:

  • Geringere Wartungskosten im Vergleich zu Replikations- oder Hot-Standby-Lösungen

Nachteile:

  • Hohe Ausfallzeiten
  • Größere, detailliertere Dokumentation des Wiederherstellungsplans (DR-Orchestrierung)
  • Verlängerte Wiederherstellungszeit
  • Verlässt sich auf Integrität und Alter der Backups
  • Höherer Grad an menschlichem Versagen, wenn eine manuelle Rekonfiguration erforderlich ist (Vernetzung usw.)
  • Ungeeignet für MCS oder PVS
  • Ungeeignet für Citrix VPX ADC aufgrund von Netzwerken (und kann durch Backups von nsconfig Verzeichnissen und ns.conf Dateien neu aufgebaut werden)

Anwendungsfall und Annahmen

Nützlich für weniger ausgereifte IT-Organisationen und Organisationen mit begrenzten IT-Betriebsbudgets und kann längere Ausfälle ermöglichen, um wichtige Geschäftsdienste wiederherzustellen. Geht davon aus, dass Backups regelmäßig auf Wiederherstellungsintegrität getestet werden, und folgen klar dokumentierten Wiederherstellungsprozessen.

Recovery-Option - Recovery über Replikation

Notfallwiederherstellung

Vor- und Nachteile

Vorteile:

  • Die Replikation ist wahrscheinlich automatisiert und richtet sich an RTO und RPOs
  • Verwendet wahrscheinlich weniger komplexe Technologien im Vergleich zu automatisierten Recovery-Lösungen

Nachteile:

  • Verlässt sich auf administrative Intervention
  • Größere, detailliertere Dokumentation des Wiederherstellungsplans (DR-Orchestrierung)
  • Höherer Grad an menschlichem Versagen, wenn eine manuelle Rekonfiguration erforderlich ist (Vernetzung usw.)
  • Ungeeignet für MCS oder PVS. Recreation of Machine Catalogs wird in den projizierten RTO einbezogen. Durch das Erstellen von Dummy-Maschinenkatalogen in DR oder das Ausskalieren von VDA-Instanzen in der DR und das Ausführen einer Aktion “Katalog aktualisieren” beim Anwenden eines replizierten Masterimages kann diese RTO jedoch verkürzt werden
  • Aufgrund der Vernetzung nicht für Citrix VPX ADC geeignet und daher besser geeignet für den Einsatz von Hot-Standby-ADC

Anwendungsfall und Annahmen

Nützlich für weniger ausgereifte IT-Organisationen und Organisationen mit begrenztem IT-Betriebsbudget. Diese Lösung stützt sich auf Speicherreplikationstechnologien des SAN-Anbieters oder Hypervisor-Anbieters (vSphere Replication usw.), um VMs über das WAN auf eine andere Einrichtung zu replizieren.

Recovery-Option — Replikation mit automatischer Wiederherstellung

Notfallwiederherstellung

Vor- und Nachteile

Vorteile:

  • Geringere Wartungskosten im Vergleich zu Hot-Standby-Lösungen
  • Die Replikation ist wahrscheinlich automatisiert und richtet sich an RTO und RPOs
  • Wiederherstellungspläne sind in der Regel automatisiert
  • Weniger administrative Eingriffe und menschliches Versagen

Nachteile:

  • Verlassen Sie sich auf fortschrittlichere Technologien wie VMware SRM, Veeam, Zerto, ASR zur Orchestrierung der Recovery und zur Änderung von Netzwerkparametern
  • Ungeeignet für MCS oder PVS. Recreation von Maschinenkatalogen muss in den projizierten RTO einbezogen werden. Durch das Erstellen von Dummy-Maschinenkatalogen in DR oder das Ausskalieren von VDA-Instanzen in der DR und das Ausführen einer Aktion “Katalog aktualisieren” beim Anwenden eines replizierten Masterimages kann diese RTO jedoch verkürzt werden
  • Aufgrund der Vernetzung nicht für Citrix VPX ADC geeignet und daher besser geeignet für den Einsatz von Hot-Standby-ADC

Anwendungsfall und Annahmen

Nützlich für Unternehmensorganisationen mit geeigneten Ressourcen und Budget für die Notfall-Einrichtung. Diese Lösung basiert auf der gleichen Speicherreplikation der vorherigen Option, enthält jedoch DR-Orchestrationstechnologien, um VMs in bestimmter Reihenfolge wiederherzustellen, NIC-Konfigurationen anzupassen (falls erforderlich) und so weiter

Wiederherstellungsoption — Hot Standby (Aktiv-Passiv) mit manuellem Failover

Notfallwiederherstellung

Vor- und Nachteile

Vorteile:

  • Kurze Wiederherstellungszeit, da die Plattform “immer eingeschaltet” ist
  • Unterstützt speicher- und netzwerkabhängige Komponenten wie VPX, MCS, PVS
  • Dokumentation zu niedrigeren Wiederherstellungsplan (DR-Orchestrierung)

Nachteile:

  • Verlässt sich auf administrative Eingriffe zum Failover URL oder leitet Benutzer zur Backup-URL
  • Höhere Kosten durch “heiße” Hardware im Notfall-Modus im Standby-Modus
  • Höherer Verwaltungsaufwand, um die Konfigurationen und Aktualisierungen der Standby-Plattform mit der Produktion synchron zu halten

Anwendungsfall und Annahmen

Nützlich für Unternehmensorganisationen mit geeigneten Ressourcen und Budget für die Notfall-Einrichtung. Kann eine “vollständig skalierte” Plattform im Hot-Standby oder eine “Scale On-Demand” -Plattform verwenden. Letzteres kann für Cloud-Recovery attraktiv sein, um die Betriebskosten zu senken, mit Vorbehalten.

Zum Zeitpunkt der Failover-Administratoren aktualisieren die **DNS-Einträge** für eine oder mehrere Zugriffs-URLs, die auf eine oder mehrere DR-IPs für Citrix Gateway und StoreFront verweisen, oder Benutzer werden von der formellen Kommunikation darauf hingewiesen, mit der Verwendung einer “Backup” oder “DR” -URL zu beginnen.

Diese manuelle Option kann für Szenarien nützlich sein, in denen Anwendungs-Back-Ends eine längere Wiederherstellungszeit erfordern können, aber für Benutzer Verwirrung stiften, wenn Citrix vollständig verfügbar wäre und Anwendungen nicht verfügbar wären.

Dieses Modell geht von einer ausgereiften IT-Organisation aus, und es stehen genügend WAN- und Computing-Infrastrukturen zur Verfügung, um Failover zu unterstützen.

Wiederherstellungsoption — Hot Standby (Aktiv-Passiv) mit automatischem Failover

Notfallwiederherstellung

Vor- und Nachteile

Vorteile:

  • Kurze Wiederherstellungszeit, da die Plattform “immer eingeschaltet” ist
  • Unterstützt speicher- und netzwerkabhängige Komponenten wie VPX, MCS, PVS
  • Dokumentation zum minimalen Wiederherstellungsplan (DR-Orchestrierung)
  • Einfacher für Endbenutzer als URLs Failover
  • Unterstützt EPA-Scans am Citrix Gateway

Nachteile:

  • Höhere Kosten durch “heiße” Hardware in der Notfallwiederherstellung im Standby-Modus und Citrix ADC -Lizenzierung
  • Höhere Komplexität der Zugriffsebene
  • Höherer Verwaltungsaufwand, um die Konfigurationen und Aktualisierungen der Standby-Plattform mit der Produktion synchron zu halten

Anwendungsfall und Annahmen

Eine gemeinsame Konfiguration mit Unternehmenskunden und ermöglicht ein automatisches Failover auf den DR-Site über Citrix ADC GSLB (ADC Advanced oder höher erforderlich). Dieses Modell geht von einer ausgereiften IT-Organisation und einem ausreichenden WAN aus und berechnet eine Infrastruktur, um Failover zu unterstützen. Dieses Modell geht auch davon aus, dass Anwendungs- und Benutzerdatenabhängigkeiten mit den neuesten Versionen/Aktualisierungen von Active Site abgestimmt sind und in der DR-Einrichtung in ähnlicher automatisierter Weise wiederhergestellt werden können, um die verlängerten Auswirkungen des Service auf den Endbenutzer und die Verwirrung aufgrund der Teillösungsfunktionalität zu verringern.

Wiederherstellungsoption — Aktiv-Aktiv mit automatischem Failover

Notfallwiederherstellung

Vor- und Nachteile

Vorteile:

  • Kurze Wiederherstellungszeit, da die Plattform “immer eingeschaltet” ist
  • Unterstützt speicher- und netzwerkabhängige Komponenten wie VPX, MCS, PVS
  • Dokumentation zum minimalen Wiederherstellungsplan (DR-Orchestrierung)
  • Nahtlos für Endbenutzer

Nachteile:

  • Höhere Kosten durch “heiße” Hardware in der Notfallwiederherstellung im Standby-Modus und Citrix ADC -Lizenzierung
  • Höchste Komplexität der Zugriffsebene
  • Höherer Verwaltungsaufwand, um die Konfigurationen und Aktualisierungen der Standby-Plattform mit der Produktion synchron zu halten
  • Active/Active GSLB unterstützt derzeit keine EPA-Scans am Citrix Gateway, Active/Active GSLB-Konfiguration für Citrix Gateway-URL empfohlen
  • Verlässt sich darauf, dass Administratoren die Ressourcen- und Hardwarekapazität in allen Rechenzentren überwachen und anpassen, um sicherzustellen, dass die Integrität der DR-Kapazität nicht beeinträchtigt wird.

Anwendungsfall und Annahmen

Eine fortschrittlichere, aber gemeinsame Konfiguration mit Unternehmenskunden und ermöglicht Zugriffsebene URLs auf Active-Active über Citrix ADC GSLB (ADC Advanced oder höher erforderlich). Diese Funktionalität ist nützlich in Umgebungen mit der Nähe des lokalen Rechenzentrums zueinander oder in Situationen, in denen Rechenzentren entfernt sein können, jedoch mit der Möglichkeit, Benutzer für Szenarien mit mehreren Standorten an bevorzugte Rechenzentren anzuheften (häufig von erweiterten StoreFront-Konfigurationen und GSLB in geringerem Maße).

Dieses Modell geht von einer ausgereiften IT-Organisation und einem ausreichenden WAN aus und berechnet eine Infrastruktur, um Failover zu unterstützen. Dieses Modell geht auch davon aus, dass die Abhängigkeiten von Anwendungs- und Benutzerdaten mit den neuesten Standortversionen/-aktualisierungen abgestimmt sind und in der DR-Einrichtung auf ähnlich automatisierte Weise wiederhergestellt werden können, um die verlängerten Auswirkungen des Service auf den Endbenutzer und die Verwirrung aufgrund der Funktionalität der partiellen Lösung zu verringern.

Notfallwiederherstellung in Public Cloud

Disaster Recovery mit On-Prem to Cloud-Plattformen oder Cloud-to-Cloud beinhaltet eigene Herausforderungen oder Überlegungen, die sich oft nicht in On-Prem-Recovery-Szenarien präsentieren.

Die folgenden wichtigen Überlegungen können während der DR-Entwurfsplanung berücksichtigt werden, um Fehltritte zu vermeiden, die den DR-Plan, der Cloud-Infrastruktur anwendet, entweder ungültig, kostengünstig oder nicht in der Lage ist, die Zielkapazität im Falle von DR.

Betrachtung — Netzwerkdurchsatz

Wirkungsbereiche

Verfügbarkeit Leistung Kosten

Details

Kunden können die Durchsatz-Juncture-Punkte in ihrer Cloud-Lösung unterschätzen und damit unterdimensionieren, einschließlich virtueller Firewall, VPN-Gateway und WAN-Uplink (AWS Direct Connect, Azure Express Route, GCP Cloud Interconnect usw.), wenn die Citrix Plattform in der Cloud wiederhergestellt und über die WAN. Azure VPN Gateways und AWS Transit Gateways haben derzeit maximale Limits von 1,25 Gbit/s. Dieses Limit kann die Skalierung von Gateways oder die Verwendung mehrerer VPCs (wenn es eine AWS gibt) erfordern, wenn diese für die Cloud-Architektur von entscheidender Bedeutung sind. Viele virtuelle Firewalls haben Lizenzbeschränkungen für den Durchsatz, den sie verarbeiten können, oder für Höchstwerte, selbst bei ihrer höchsten Grenze. Diese Einschränkung kann eine Skalierung der Anzahl der Firewalls und deren Lastenausgleich in irgendeiner Weise erfordern.

Empfehlungen

Wenn Sie Berechnungen zur Durchsatzgrößenbestimmung einrichten, nehmen Sie die volle DR-Kapazitätslast an. Erfassen Sie die folgenden Daten pro gleichzeitiger Benutzer:

  • Geschätzte ICA-Sitzungsbandbreite
  • Geschätzte Anwendungskommunikationsbandbreite pro Sitzung, wenn sie Sicherheitsgrenzen überschreiten
  • Geschätzte Bandbreite für Dateidienste pro Sitzung, wenn sie Sicherheitsgrenzen überschreiten

Für die oben genannten Metriken kann es sinnvoll sein, Daten zu aktuellen Verkehrsmustern zu und von VDAs in der Produktion zu sammeln. Es ist auch wichtig zu berücksichtigen, welche anderen Datenflüsse, die nicht mit Citrix in Verbindung stehen, auch diese Netzwerkpfade verwenden. Stellen Sie sicher, dass Sie die Netzwerk- und Sicherheitsteams bei der Planung von Citrix DR in Verbindung bringen, um sicherzustellen, dass alle Bandbreitenschätzungen, die Sicherheitszonen und Netzwerksegmente durchlaufen, verstanden und berücksichtigt werden können. Wenn die Bandbreite knapp ist, kann Citrix SD-WAN Optimization dazu beitragen, den Sitzungsfußabdruck auf dem Draht zu senken oder die Bandbreite über mehrere Netzwerkverbindungen zu aggregieren.

Berücksichtigung — Windows-Desktopbetriebssystem-Lizenzierung

Wirkungsbereiche

Kosten

Details

Es gibt potenziell komplexe Lizenzierungsüberlegungen für Microsoft Desktopbetriebssysteminstanzen, die auf verschiedenen Cloud-Plattformen ausgeführt werden. Microsoft ihre Cloud-Lizenzrechte überarbeitet im August 2019, was sich in einigen Bereitstellungsszenarien auf die VDI-Kosten auswirken kann.

Empfehlungen

Beziehen Sie sich auf die aktuellsten Microsoft-Leitlinien bei der Bestimmung der Anwendungsfallarchitektur Wenn es eine potenzielle Kostenherausforderung für VDI in der DR-Lösung gibt, erwägen Sie eine Ergänzung mit Hosted Shared Desktops (eine Erweiterung von RDS-CALs kann erforderlich sein), falls dies möglich ist, da sie eine größere Flexibilität bei niedrigeren Betriebskosten bieten können.

Berücksichtigung — Timing des VDA-Scale-Outs (vor oder während der DR)

Wirkungsbereiche

Verfügbarkeit Kosten

Details

Kunden werden in die Cloud gezogen, indem sie die Kapazität nur dann bezahlen, wenn sie benötigt wird. Diese Lösung kann die DR-Kosten drastisch senken, indem sie nicht für die reservierte Infrastruktur bezahlt, unabhängig davon, ob sie verwendet wird oder nicht.

In großem Maßstab kann sich ein Cloud-Anbieter jedoch nicht zu einer SLA verpflichten, die Hunderte oder Tausende von VMs gleichzeitig einschaltet. Diese Lösung wird besonders schwierig, wenn der VDA-Footprint für DR voraussichtlich auf Hunderte oder Tausende von Instanzen läuft. Cloud-Anbieter tendieren dazu, die Massenkapazität für verschiedene Instanz-Größen zu erhalten. Dieser Anbieter kann jedoch von Moment zu Moment variieren. Wenn eine Katastrophe auftritt, die ein geografisches Gebiet betrifft, kann es zu Streitigkeiten anderer Mandanten kommen, die auch On-Demand-Kapazität anfordern.

Schlüsselfragen, die beantwortet werden müssen und die Entscheidungen beeinflussen können:

  • Ist immer 100% DR-Kapazität erforderlich?
  • Müssen wir nur kritische Workloads hosten (also Teilmenge der Produktion)?
  • Ist es möglich, zur Zeit von DR zu skalieren? Wenn ja, wurden die Anwendungsfälle von DR-Tiers priorisiert, um die unterschiedlichen RTOs der einzelnen Anwendungsfälle besser zu verstehen, um eine stufenweise Skalierung außerhalb der Kapazität zu unterstützen?
  • Können wir die Betriebssystem-Instanzen skalieren, die App- oder gehostete freigegebene Desktop-Anwendungsfälle unterstützen, um die Provisioning zeit zu sparen und diese Instanzen auszuschalten, um Betriebskosten zu sparen?

Empfehlungen

Citrix empfiehlt, sich zunächst mit Ihrem Cloudanbieter in Verbindung zu setzen, um festzustellen, ob die erwartete Kapazität innerhalb des RTO Zeitrahmens eingeschaltet werden kann und ob diese mit On-Demand-Instanzen erfüllt werden kann oder nicht. Um sich gegen Kapazitätsverfügbarkeitsbeschränkungen für VDAs in einem DR-Szenario abzusichern, empfiehlt Citrix die Provisioning von VDAs in so vielen Verfügbarkeitszonen wie möglich. In großem Maßstab kann es sich lohnen, in verschiedenen Cloud-Regionen bereitzustellen und die Architektur entsprechend anzupassen. Einige Cloudanbieter haben vorgeschlagen, unterschiedliche Größen von VM-Instanztypen zu verwenden, um die Erschöpfung der VM weiter zu verringern. Wenn möglich, wäre es ratsam, VDA-Instanzen vorab bereitzustellen, offline zu halten und regelmäßig zu aktualisieren. Die Provisioning ist ein ressourcen- und zeitintensiver Prozess, und die Skalierung der VDA-DR-Kapazität auf Anforderung kann durch Pre-Provisioning zu einem gewissen Grad beschleunigt werden. Wenn das Unternehmen wenig Appetit auf Kapazitätsverfügbarkeitsrisiken hat, kann es erforderlich sein, reservierte oder dedizierte Rechenkapazitäten anzuwenden und entsprechend eine Budgetierung zu gewährleisten. Es ist möglich, On-Demand- und Reserved\ dedizierte Modelle zu kombinieren, indem auf die DR-Wiederherstellungsstufe verwiesen wird, bei denen VDAs sofort verfügbar sein müssen, während andere die Flexibilität haben, über einen längeren RTO von mehreren Tagen oder Wochen wiederhergestellt zu werden, wenn sie weniger kritisch für die Aufrechterhaltung der geschäftlich.

Berücksichtigung — Anwendungs- und Benutzerdaten

Wirkungsbereiche

Kosten Verfügbarkeit Leistung

Details

Der Speicherort von Benutzerdaten und Anwendungs-Back-Ends kann sich erheblich auf die Leistung und manchmal auf die Verfügbarkeit der Citrix DR-Umgebung auswirken. Einige Kundenszenarien verwenden einen DR-Ansatz für mehrere Rechenzentren, bei dem nicht alle Anwendungs-Backends oder Benutzerdaten wie Heim- und Abteilungslaufwerke nicht neben Citrix in der Cloud wiederhergestellt werden können. Diese Lücke kann zu unerwarteten Latenzen führen, die sich auf die Leistung oder sogar die Funktionalität der Anwendungen auswirken können. Aus Sicht des Durchsatzes kann diese Lücke die verfügbare Bandbreite der Netzwerk- und Sicherheits-Appliance verstärken.

Empfehlungen

Halten Sie Anwendungs- und Benutzerdaten nach Möglichkeit lokal auf der Citrix Plattform in der Notfallwiederherstellung, um die Leistung so optimal wie möglich zu halten, indem Sie Latenz- und Bandbreitenanforderungen im WAN reduzieren.

Notfallwiederherstellungsplanung für Citrix Cloud

Es gibt mehrere bemerkenswerte Unterschiede zwischen der lokalen oder “traditionellen” Bereitstellung von Citrix Virtual Apps and Desktops (CVAD) im Vergleich zum Citrix Virtual Apps and Desktops Service (CVADS), der von Citrix Cloud in Bezug auf die DR-Planung bereitgestellt wird:

  • Citrix verwaltet die meisten Steuerungskomponenten für den Partner/Kunden und entfernt die wesentlichen DR-Anforderungen für die Citrix Site und ihre Komponenten von ihrer Verantwortung.
  • Die Bereitstellung einer DR-Umgebung für Citrix Ressourcen erfordert lediglich, dass ein Kunde Citrix Cloud Connectors im Recovery “Resource Location” und optional StoreFront- und Citrix ADCs für Citrix Gateway bereitstellt.
  • Die einzigartige Servicearchitektur von Citrix Cloud ist geografisch redundant und durch Design belastbar.
  • Access Tier DR ist nicht erforderlich, wenn Citrix Workspace- und Citrix Gateway-Dienste verwendet werden.

Neben diesen Kernunterschieden erfordern viele der DR-Überlegungen aus früheren Abschnitten weiterhin eine Partner-/Kundenplanung, da sie die Verantwortung für die Citrix VDAs, Benutzerdaten, Anwendungs-Backends und Citrix Access Tier behalten, wenn Citrix Gateway Service und Citrix Workspace Service nicht von Citrix Cloud verwendet werden.

In diesem Abschnitt werden wichtige Themen behandelt, die Kunden bei der Definition einer geeigneten DR-Strategie für Citrix Cloud unterstützen.

CVADS vereinfacht Disaster Recovery

Im Folgenden finden Sie ein typisches konzeptionelles Diagramm, in dem die konzeptionelle Architektur von CVADS neben der Trennung der Verantwortung für von Citrix verwaltete Komponenten und von Partnern und vom Kunden verwalteten Komponenten beschrieben wird. Nicht dargestellt sind hier die WEM-, Analytics- und Citrix Gateway-Dienste, bei denen es sich um elektive Citrix Cloud-Komponenten im Zusammenhang mit CVADS handelt, die unter “Managed by Citrix” fallen würden.

Notfallwiederherstellung

Wie im Diagramm veranschaulicht, fällt ein erheblicher Teil der Control-Komponenten, die Wiederherstellungsentscheidungen erfordern, unter den Verwaltungsbereich von Citrix. Als Cloud-basierter Service ist die CVADS-Architektur innerhalb des sehr widerstandsfähig Citrix Cloud-Region. Es ist Teil von Citrix Clouds “Secret Sauce” und wird innerhalb berücksichtigt Die SLAs von Citrix Cloud.

Die Verantwortlichkeiten für das Service-Verfügbarkeitsmanagement lauten wie

  • Citrix ist. Control Plane und Zugriff auf “Dienste” bei Verwendung (Workspace, Citrix Gateway Service).
  • Kunde. Ressourcenstandortkomponenten wie Cloud Connectors, VDAs, Anwendungs-Backends, Infrastrukturabhängigkeiten (AD, DNS usw.) und Zugriffsstufe (StoreFront, Citrix ADCs), wenn keine Citrix Cloud-Zugriffsstufe verwendet wird.

Kunden erhalten die folgenden Vorteile in Bezug auf Disaster Recovery auf CVADS:

  • Geringerer Verwaltungsaufwand durch weniger zu verwaltende Komponenten und weniger unabhängige Konfigurationen, die zwischen den Standorten repliziert und gewartet werden müssen.
  • Reduzierte Wahrscheinlichkeit menschlicher Fehler und Konfigurationsdiskrepanzen zwischen Citrix Bereitstellungen aufgrund der zentralisierten Konfiguration der “Citrix Site” in der Cloud.
  • Optimierte Abläufe aufgrund der Vereinfachung des Ressourcenmanagements für Produktions- und Disaster Recovery-Bereitstellungen, da weniger Citrix Sites und Komponenten konfiguriert und gewartet werden müssen, keine Zugriffsebene zwischen Standorten (optional) und weniger komplexer Disaster Recovery-Logik für Citrix Ressourcen.
  • Reduzierte Betriebskosten mit weniger Serverkomponenten für die Bereitstellung und Wartung und Gewinnung eines einzigen Glasbereichs auf Umgebungstrends in Bereitstellungen hinweg durch die Zentralisierung der Überwachungsdatenbank.

Überlegungen zur Notfallwiederherstellung von CVADS

Obwohl viele Komponenten für die Sanierungsplanung aus dem Managementbereich des Kunden entfernt werden, bleiben Kunden die Planung und Verwaltung von DR und die hohe Verfügbarkeit (optional) für die Komponenten im Ressourcenstandort verantwortlich.

Der größte Unterschied in der Art und Weise, wie wir die Verfügbarkeit ansprechen, hängt davon ab, wie wir Ressourcenstandorte interpretieren und konfigurieren. Innerhalb von CVADS selbst werden Ressourcenstandorte als dargestellt Zonen. Mit können Zoneneinstellung wir das Failover zwischen Ressourcenstandorten basierend auf der von uns angegebenen Logik verwalten. Die Verwendung von Zonenpräferenz in einer traditionell bereitgestellten CVAD-Site würde als Design mit hoher Verfügbarkeit betrachtet, jedoch nicht als gültiges DR-Design. Im Zusammenhang mit Citrix Cloud ist diese Option eine gültige DR-Lösung.

Die meisten der zuvor Disaster Recovery-Optionen besprochenen Themen gelten für CVADS, daher gibt es zahlreiche Optionen, um organisatorische Wiederherstellungsziele und Budgets anzupassen.

Bei der Planung von DR für den CVADS-Dienst von Citrix Cloud müssen mehrere wichtige Leitprinzipien aus Sicht der Infrastrukturplanung verstanden werden:

  • Resource Standorte. Produktions- und DR-Standorte werden in Citrix Cloud als unabhängige Ressourcenstandorte eingerichtet.
  • Cloud-Konnektoren. Für jeden Ressourcenstandort müssen mindestens zwei Cloud Connectors bereitgestellt sein. Zur besseren Übersicht sind Cloud Connectors keine Komponente, die während eines DR-Ereignisses manuell oder automatisch “wiederhergestellt” werden muss. Sie müssen als “Hot-Standby” -Komponenten gelten und an jedem Standort online gehalten werden.
  • Von Kunden verwaltete Access Controller (optional). Kunden können sich dafür entscheiden, ihre eigenen Citrix ADCs für Citrix Gateway- und StoreFront-Server bereitzustellen und Citrix Workspace oder Citrix Gateway Service aus mehreren Gründen nicht zu nutzen. Diese können Folgendes umfassen:
    • Benutzerdefinierte Authentifizierungsabläufe
    • Erweiterte Branding-Fähigkeiten
    • Höhere Flexibilität beim Routing von HDX-Datenverkehr
    • Prüfung von ICA-Verbindungen und Integration in SIEM-Plattformen
    • Möglichkeit, weiterhin zu arbeiten, wenn die Verbindung des Cloud Connectors zu Citrix Cloud unterbrochen wird, indem die Local Host Cache-Funktion der Cloud Connectors mit StoreFront verwendet wird

    Wie bei den Cloud Connectors wird empfohlen, StoreFront- und Citrix Gateway-Komponenten als “Hot Standby” am Recovery-Standort bereitzustellen und sie während eines DR-Ereignisses nicht wiederherzustellen.

Überlegungen zu Vorgängen

Die Aufrechterhaltung der DR-Plattform ist für die Aufrechterhaltung ihrer Integrität unerlässlich, um unvorhergesehene Probleme zu vermeiden, wenn die Plattform benötigt wird. Die folgenden Richtlinien werden für den Betrieb und die Wartung der DR Citrix Umgebung empfohlen:

  • Die Citrix DR-Plattform ist nicht ohne Prod. Kunden mit einer “Hot-Standby” -Umgebung können versucht sein, Abstriche zu machen und DR als Testplattform zu behandeln. Diese Behandlung wirkt sich negativ auf die Integrität der Lösung aus. Tatsächlich wäre DR wahrscheinlich die letzte Plattform, auf der Änderungen gefördert wird, um sicherzustellen, dass ihr Nutzen nicht beeinträchtigt wird, wenn die Wartung katastrophal in einer Weise verläuft, die in Nicht-Prod-Umgebungen nicht ausgestellt wurde.
  • Patching und Wartung. Routinemäßige Wartung im Schritt zur Produktion bei der Verwendung von “Hot Standby” Citrix Plattformen ist für die Aufrechterhaltung einer funktionalen DR-Plattform unerlässlich. Es ist wichtig, dass DR mit der Produktion in Bezug auf Betriebssystem, Citrix Produkte und Anwendungs-Patches synchron hält. Zur Minimierung des Risikos wird empfohlen, mehrere Tage bis eine Woche zwischen der Patch-Produktion und dem Patch-DR zu erlauben.
  • Regelmäßige Tests. Unabhängig davon, ob DR die Replikation der Produktion in eine Wiederherstellungseinrichtung oder die Verwendung von “Hot Standby” -Umgebungen beinhaltet, ist es wichtig, den DR-Plan regelmäßig (zweimal im Jahr oder länger ist ideal) zu testen, um sicherzustellen, dass die Teams mit Wiederherstellungsprozessen und etwaigen Fehlern in der Plattform oder den Workflows vertraut sind identifiziert und behoben.
  • Kapazitätsmanagement. Zwar sowohl für Active-Passive als auch für Active-Active “Always on” Citrix Umgebungen müssen Kapazitäts- oder Anwendungsfalländerungen in der Produktion auch für DR berücksichtigt werden. Insbesondere wenn Active-Active-Modelle verwendet werden, ist es für die Ressourcenauslastung einfach, darüber hinaus einen 50% Steady-State-Auslastungsschwellenwert für Ressourcen in jeder Umgebung zu erhöhen, nur damit ein DR-Ereignis auftritt und die überlebende Plattform überwältigt wird und entweder schlecht funktioniert oder aufgrund der Überlastung. Die Kapazität kann monatlich oder vierteljährlich überprüft werden.

Zusammenfassung

Wir haben uns mit dem Thema Disaster Recovery in Citrix einiges befasst. Die folgenden Punkte fassen die Kernbotschaften und Mitteilungen dieses Leitfadens für Architekten und Kunden zusammen, die bei der Planung ihrer Citrix Recovery-Strategie zu berücksichtigen sind:

  • Das Verständnis der geschäftlichen Anforderungen und technologischen Fähigkeiten einer Kundenumgebung beeinflusst die für Citrix erforderliche Disaster Recovery-Strategie. Die gewählte Recovery-Strategie kann sich an die Geschäftsziele anpassen.
  • Hohe Verfügbarkeit ist nicht gleichbedeutend mit Disaster Recovery. Die Disaster Recovery kann jedoch eine hohe Verfügbarkeit beinhalten.
  • Die gemeinsame Nutzung von Verwaltungsgrenzen zwischen physischen Standorten stellt keine Disaster Recovery-Lösung dar.
  • Die Entwicklung einer Disaster Recovery-Tiering-Klassifizierung für das Technologieportfolio eines Unternehmens bietet Transparenz, Flexibilität und potenzielle Kosteneinsparungen bei der Entwicklung einer Recovery-Strategie.
  • Die RTO-Anforderungen für die Citrix Infrastruktur oder die auf Citrix gehosteten Anwendungen sind der wichtigste Einflussfaktor, für den ein Disaster Recovery-Design erforderlich ist. Eine kürzere RTO erfordert oft höhere Lösungskosten.
  • Disaster Recovery-Architekturen für Citrix, die keine “heiße” Disaster Recovery-Plattform verwenden, weisen Einschränkungen in Technologien auf, die ein Kunde verwenden kann, wie Citrix MCS, ADC und Provisioning.
  • Die Disaster Recovery-Strategie für Citrix muss auch die Recovery- und Recovery-Zeit von Benutzerdaten und Anwendungs-Back-Ends berücksichtigen. Citrix kann so konstruiert werden, dass sie schnell wiederhergestellt werden kann. Benutzer können dennoch nicht arbeiten, wenn Anwendungs- und Datenabhängigkeiten in einem ähnlichen Zeitrahmen nicht verfügbar sind.
  • Disaster Recovery in Cloud-Umgebungen verfügt über eigene Überlegungen, die in on-premises Umgebungen nicht vorhanden sind und die Unternehmen überprüfen müssen, um unvorhergesehene Engpässe oder betriebliche Auswirkungen beim Aufrufen von Disaster Recovery in Cloud-Umgebungen zu vermeiden.
  • Es ist unerlässlich, dass Disaster Recovery-Komponenten auf dem neuesten Stand gehalten werden, um Produktionsupdates und -konfigurationen zu entsprechen, um die Integrität der Plattform zu erhalten.
  • Plattformen, die eine Aktiv-Aktiv-Konfiguration für Citrix zwischen Standorten verwenden, müssen auf die Kapazitätsüberwachung achten, um sicherzustellen, dass im Katastrophenfall ausreichende Ressourcen zur Verfügung stehen, um die prognostizierte Last an einem oder mehreren überlebenden Standorten zu unterstützen.
  • Kunden müssen ihren Disaster Recovery-Plan für Citrix regelmäßig testen, um ihren Betrieb und die Fähigkeit, ihren Kernzweck zu erfüllen, zu validieren.
  • Citrix Virtual Apps and Desktops Service vereinfacht viele Aspekte der DR-Architektur erheblich und ermöglicht die Redundanz von Ressourcenstandorten über die Zonenpräferenz-Konfiguration.

Quellen

Das Ziel dieses Artikels ist es, Sie bei der Planung Ihrer eigenen Implementierung zu unterstützen. Um diese Aufgabe zu erleichtern, möchten wir Ihnen Quelldiagramme zur Verfügung stellen, die Sie an Ihre eigenen Bedürfnisse anpassen können: Quelldiagramme.

Citrix Virtual Apps and Desktops — Disaster Recovery Planning