Designentscheidung: Planung der Notfallwiederherstellung

Übersicht

Dieses Handbuch hilft bei der Planung der Architektur für die Notfallwiederherstellung (Disaster Recovery, DR) und bei Überlegungen zu on-premises und Cloud-Bereitstellungen von Citrix Virtual Apps and Desktops.
DR ist an und für sich ein bedeutendes Thema in seiner Breite. Citrix räumt ein, dass dieses Dokument kein umfassender Leitfaden für eine allgemeine DR-Strategie ist. Es berücksichtigt nicht alle Aspekte von DR und nimmt manchmal die Perspektive eines Laien zu verschiedenen DR-Konzepten ein.

In diesem Handbuch sollen die folgenden Überlegungen behandelt werden, die erhebliche Auswirkungen auf die Citrix-Architektur einer Organisation haben, und entsprechende architektonische Hinweise gegeben werden:

  • Geschäftliche Anforderungen
  • Disaster Recovery versus Hochverfügbarkeit
  • Klassifizierung der Disaster Recovery-Stufe
  • Optionen für die Notfallwiederherstellung
  • Disaster Recovery in der Cloud
  • Überlegungen zur Bedienung

Geschäftliche Anforderungen

Der Ausgangspunkt für die Entwicklung eines Wiederherstellungsplans für Citrix ist die Ausrichtung auf die „Business Layer“ der Citrix-Designmethodik, die Erfassung genauer Geschäftsanforderungen und bekannter Einschränkungen bei der Wiederherstellung von Diensten. In diesem Schritt werden der Umfang und die Anforderungen festgelegt, die als Grundlage für die DR-Strategie (später erörtert) dienen, die am besten geeignet sind, um die geschäftlichen und funktionalen Anforderungen innerhalb der vom Unternehmen oder der IT-Abteilung festgelegten Einschränkungen zu erfüllen.

Im Folgenden finden Sie einige Beispiele für nützliche Fragen, die Sie bei der DR-Planung erörtern sollten. Diese Schlüsselkomponenten sind wichtig für die Identifizierung von Geschäftsanforderungen und potenziellen Einschränkungen. Diese Liste ist ein Beispiel für häufig gestellte grundlegende Fragen, und Unternehmen müssen noch weitere Fragen beantworten, um sie an ihren Anforderungen auszurichten. Diese Fragen werden weiter unten im Dokument im Abschnitt Disaster Recovery Options ausführlicher behandelt:

  • Backup-Strategie. Backup kann DR unterstützen, aber DR ist kein Ersatz für Backups, die tatsächlich während der Notfallwiederherstellung entweder als Teil des Plans oder als Absicherung gegen korrupte Replikationsdaten benötigt werden. Welche Backup-Strategie wird heute für Server verwendet? Einschließlich:
    • Backup-Häufigkeit?
    • Aufbewahrungsfrist?
    • Offsite-Speicher?
    • Methodik für Backup-Tests?
  • Wiederherstellungszeitziel (RTO). Ist die Citrix-Plattform im Katastrophenfall sofort verfügbar oder wird sie innerhalb eines bestimmten Zeitraums online gestellt? (Siehe Klassifizierungen der Disaster Recovery-Stufen). Die RTO variiert je nach Klassifizierung der Anwendungs- oder Servicekritikalität, aber im Allgemeinen muss der RTO von Citrix dem niedrigsten RTO einer auf Citrix gehosteten App entsprechen oder diesem überlegen sein, und die Abhängigkeiten von Citrix (Netzwerk, Speicher, Rechenleistung usw.) müssen ähnlich oder besser sein als die von Citrix oder nachgelagerten RTOs, damit Apps gefährdet werden können. Es lohnt sich, Anwendungs-Backends, mit denen von Citrix gehostete Apps eine Verbindung herstellen, in die Diskussion einzubeziehen, um die Erwartungen in Einklang zu bringen.

  • Recovery Point Objective (RPO). Welcher Grad an Datenverlust wird für das Unternehmen als tolerierbar angesehen, der je nach Klassifizierung der betreffenden Anwendungen 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 Betracht zu ziehen.

  • Umfang der Wiederherstellung. Diese Überlegung bezieht sich nicht nur auf die Citrix-Infrastruktur, sondern auch auf Benutzerdaten oder wichtige Anwendungsserver, mit denen von Citrix gehostete Anwendungsclients kommunizieren. 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 dies nur ein Teil der Lösung ist.

  • Anwendungsfälle. Citrix-Plattformen bedienen häufig viele Anwendungsfälle, die jeweils unterschiedliche geschäftliche Kritikalität aufweisen. Deckt die Wiederherstellung alle Citrix Anwendungsfälle ab? Oder wichtige Anwendungsfälle, von denen der operative Erfolg des Unternehmens vollständig abhängt. Die Antwort hat einen großen Einfluss auf das Infrastruktur-Scoping und die Kapazitätsprognosen. Es wird empfohlen, Anwendungsfälle zu klassifizieren und zu priorisieren, um die Aktivierung von DR zu unterteilen, wenn es sich um eine neue Funktion für die Citrix-Umgebung handelt.

  • Fähigkeiten. Gibt es wichtige Funktionen, die nicht in DR enthalten sein müssen, wodurch die Kosten gesenkt werden können? Ein Beispiel für diese Fähigkeit wäre die Verwendung persistenter Desktops im Vergleich zu nicht persistenten Desktops. Einige VDI-Anwendungsfälle können von Hosted Shared Desktops oder sogar von spezifischen Anwendungssolos bedient werden. Unternehmen haben manchmal angegeben, dass Komponentenredundanz (ADCs, Controller, StoreFront, SQL usw.) in DR nicht als notwendig erachtet wird. 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.

  • Technologische Fähigkeiten. Diese Überlegung kann nicht die endgültige Wiederherstellungsstrategie für Citrix bestimmen. 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 Image-Verwaltung und den Zugriff verwendet? Einige Komponenten eignen sich nicht gut für bestimmte Wiederherstellungsstrategien. Nicht persistente Umgebungen, die von MCS oder PVS verwaltet werden, sind aufgrund ihrer engen Integration mit Speicher und Netzwerken schlechte Kandidaten für VM-Replikationstechnologien.

  • Kritikalität der Daten. Werden Benutzerprofile oder Benutzerdaten als entscheidend für die Wiederherstellung angesehen? Würde es bei persistentem VDI erhebliche Auswirkungen auf die Produktivität haben, wenn diese Daten nicht verfügbar sind, wenn DR aufgerufen wird? 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 darauf ausgelegt, die Wiederherstellung von Diensten nur auf Anwendungsebene zu ermöglichen? Zwischen Hardware-Racks? Innerhalb einer Metro-Lage? Zwischen zwei Regionen? Zwei Länder? Innerhalb einer Cloud-Anbieter-Region oder der Infrastruktur eines gesamten Cloud-Anbieters (Multi-Region)? Zwischen Cloud-Anbietern (Multi-Cloud)?

  • 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 im Durchschnitt? Diese Entscheidung gilt sowohl für Cloud- als auch für die lokale Wiederherstellung.

  • Fallback (oder Failback). Verfügt das Unternehmen bereits über Pläne, wie die Produktion wieder in Betrieb genommen werden kann, sobald die DR-Situation gelöst ist? Wie erholt sich die Organisation in einen normalen Zustand? Wie werden neue Daten, die in DR hätten erstellt werden können, mit der Produktion abgeglichen und kombiniert?

Einschränkungen

Einschränkungen schränken die DR-Designoptionen oder deren Konfigurationen ein. Sie kommen in vielen Formen vor, können aber Folgendes beinhalten:

  • Gesetzliche Vorschriften oder Unternehmensrichtlinien. Diese Entscheidung kann bestimmen, welche Technologien für die Replikation oder Wiederherstellung verwendet werden können oder nicht, wie sie verwendet werden, RTO, Datenhoheit oder Mindestabstand zwischen 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. Beispiel:
    • Unterdimensionierte Firewalls oder Netzwerkleitungen in DR können letztendlich zu Ausfällen führen, da Netzwerkabhängigkeiten die DR-Arbeitslast nicht bewältigen können.
    • Im Fall von Rechenleistung können unterdimensionierte Hypervisor-Hosts oder die Verwendung völlig unterschiedlicher Hypervisoren die Optionen beeinflussen.
    • In Bezug auf Netzwerke, wenn die Wiederherstellungs-Site bei der Wartung des WAN zufällig über eine eingeschränktere Netzwerkdurchsatzkapazität verfügt als bei der Produktion.
    • In Cloud-Umgebungen, insbesondere bei der Skalierung auf Tausende von Arbeitsplätzen, kann dieses potenzielle Risiko aufgrund von Einschränkungen der Komponentendienste wie virtuelle Firewalls, VPN-Gateways und Cloud-to-WAN-Uplinks (AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect usw.) schnell zu einem erheblichen Engpass werden.
    • In Cloud-Umgebungen wird auch die Parität der Dienste, die in den Cloud-Regionen verfügbar sind, die in der DR-Region festgelegt sind, angemessen berücksichtigt. Erfahrungen aus der Praxis zeigen uns, dass eine Public-Cloud-Region zwar zunächst aus Sicht der Hosting-Kosten attraktiv zu sein scheint, wichtige Funktionen wie Availability Zones, Instance-Typen oder bestimmte Speicherfunktionen jedoch nicht in allen Cloud-Regionen verfügbar sind. Eine gute Faustregel besteht darin, zu beurteilen, ob die Funktionen und Fähigkeiten, die für den Einsatz vorgesehen sind, in allen Regionen verfügbar sind, für die der Einsatz geplant ist.
  • Budget. DR-Lösungen sind mit Kosten verbunden, die mit den Projektbudgets in Konflikt geraten können. In den meisten Fällen sind die Kosten umso höher, je kürzer die RTO ist.

  • Geografie. 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 die Optionen für Gebietsschemas und Technologien oder Wiederherstellungsmethoden einschränken.

  • Cloud-Wiederherstellung. Muss die Infrastruktur in der Cloud und nicht in einer lokalen Einrichtung wiederhergestellt werden?

  • Kapazität. Verfügt der DR-Standort über ausreichend Kapazität, um die zur Erfüllung der DR-Anforderungen erforderlichen Last zu bewältigen? Ist bei der Wiederherstellung in die Cloud das Volumen der Workloads, die innerhalb des RTO wiederhergestellt werden müssen, realistisch, wenn es nicht vorab bereitgestellt oder durch garantierte Kapazitätsberechtigungen abgedeckt ist?

  • Bereitschaft von Anwendungen. Haben die auf Citrix gehosteten Anwendungen mit Back-End-Abhängigkeiten einen DR-Plan und wie stimmen die RTOs mit dem Ziel-RTO von Citrix überein? 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.

  • Netzwerk-Sicherheit. Verfügt die Organisation über Sicherheitsrichtlinien, die festlegen könnten, welche Verkehrssegmente bei 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

Eines der häufigsten Missverständnisse bei Citrix DR-Designs ist, dass eine einzige Steuerungsebene, die sich über zwei Rechenzentren erstreckt, DR ausmacht. Das tut es nicht.
Eine einzelne Citrix-Site oder PVS-Farm, die sich über Rechenzentren erstreckt, auch in der Nähe, beinhaltet ein Hochverfügbarkeitsdesign, aber kein DR-Design.
Einige Unternehmen entscheiden sich für diesen Weg als Geschäftsentscheidung und legen Wert auf vereinfachtes Management gegenüber DR-Fähigkeiten. StoreFront-Servergruppen, die sich über Rechenzentren erstrecken, werden nur zwischen gut verbundenen Rechenzentren (mit niedriger Latenz) unterstützt . In ähnlicher Weise hat PVS die Latenzmaxima dokumentiert, die bei der Bereitstellung in Rechenzentren zu berücksichtigen sind, wie in CTX220651beschrieben.

Das folgende Diagramm ist ein Beispiel für eine HA Citrix-Architektur mit mehreren Rechenzentren, die jedoch aus den zuvor genannten Gründen keine DR-Plattform ist. Diese Referenzarchitektur wird von Unternehmen verwendet, die zwei physisch getrennte Rechenzentrumseinrichtungen aufgrund ihrer Nähe zueinander und der geringen Latenz und der Interkonnektivität mit hoher Bandbreite 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 zum oben genannten HA-Konzept sind HA-Architekturen, die auf Zonen basieren, für Organisationen verfügbar, die geografenübergreifende Redundanz bereitstellen möchten, aber nicht verlangen, dass die Plattform vollständig wiederherstellbar ist. Das Zonenkonzept ermöglicht verschiedene standortinterne Redundanzfunktionen, die Herausforderungen bei Bereitstellungen an mehreren Standorten lösen können.

In einer Sitearchitektur, die die Zonenpräferenzfunktion verwendet, werden identische Citrix-Ressourcen in mehreren Zonen bereitgestellt und zu einer einzigen Bereitstellungsgruppe zusammengefasst. Die Zonenpräferenz (mit der Möglichkeit, für eine bestimmte Ressource auf andere Zonen zurückzugreifen) kann basierend auf der Anwendung, der Heimatzone des Benutzers oder dem Standort des Benutzers gesteuert werden. Weitere Informationen zu diesem Thema finden Sie unter Interna der Zonenpräferenz . Mit der Funktion zur automatischen Aktualisierung der VDA-Registrierung können VDAs eine lokal zwischengespeicherte aktuelle Liste aller Controller innerhalb einer Site 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 (oder mindestens in zwei Zonen) vorhanden. Es wird daher empfohlen, dass Benutzer weiterhin über ihre lokale Zugriffsebene auf Ressourcen zugreifen, 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 der Entfernung und der Latenz zwischen den Komponenten weder effektive HA noch DR. Probleme mit der Plattformstabilität können auch aufgrund von Latenzproblemen bei einer solchen Bereitstellung auftreten. Darüber hinaus stimmt die Ausdehnung der Verwaltungsgrenzen zwischen Standorten nicht mit den DR-Prinzipien überein. Wir haben in der Vergangenheit ähnliche Konzeptentwürfe von Organisationen 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, die von Unternehmen gelegentlich nicht vollständig berücksichtigt wird, sind Überlegungen zur Wiederherstellung von Dateidiensten (Benutzerdaten und Geschäftsdaten auf Festplatten usw.) und Anwendungs-Backends, mit denen von Citrix gehostete Anwendungen und Desktops verbunden sind. 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 für diese zentralen Anwendungsfallabhängigkeiten jedoch kein Wiederherstellungsplan mit RTO ähnlich wie bei Citrix oder überhaupt kein Wiederherstellungsplan vorhanden ist, kann dieser Plan dazu führen, dass Citrix wie erwartet erfolgreich ein Failover in DR durchführen kann, aber Benutzer ihre Aufgaben nicht ausführen können, da diese Abhängigkeiten weiterhin nicht verfügbar sind. Nehmen wir zum Beispiel ein Krankenhaus, das seine EMR-Kernanwendung auf Citrix hostet. Ein DR-Ereignis tritt ein, und Citrix stellt in DR auf eine stets aktive Citrix-Plattform um und die Benutzer stellen eine Verbindung her, aber die EMR-Anwendung wird manueller 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 den allgemeinen Erwartungen des Unternehmens in Bezug auf die Wiederherstellungszeit oder die Benutzererfahrung übereinstimmen.

Im nächsten Abschnitt wird DR im Vergleich zu HA ausführlicher erörtert.

Disaster Recovery (DR) versus Hochverfügbarkeit (HA)

Das Verständnis von HA und DR ist entscheidend, um die Unternehmensanforderungen in Einklang zu bringen und die Wiederherstellungsziele zu erreichen. HA ist nicht gleichbedeutend mit DR, aber DR kann HA verwenden. In diesem Handbuch werden HA und DR wie folgt interpretiert:

  • Es wird davon ausgegangen, dass HA Fehlertoleranz für ein System (Dienst, Anwendung usw.) oder eine Komponente bietet. Ein System kann mit minimaler Unterbrechung für einen Benutzer auf ein anderes System umgestellt werden. Die Lösung kann so einfach sein wie eine geclusterte Anwendung oder eine Anwendung mit Lastenausgleich oder eine komplexere aktive oder Standby-„ Hot“ - 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 zur Orchestrierung der Wiederherstellung werden dokumentiert. Es geht nicht um Redundanz oder Fehlertoleranz der Komponenten und ist im Allgemeinen eine umfassenderen Strategie, die mehreren Arten von Ausfällen standhält.

Während HA in der Regel in Designspezifikationen und Lösungsbereitstellung eingebettet ist, befasst sich DR hauptsächlich mit der Orchestrierungsplanung von IT-Personal und Infrastrukturressourcen, um die Wiederherstellung des Dienstes einzuleiten.

Kann HA DR beinhalten? Ja. Für unternehmenskritische IT-Services in Unternehmen ist dieses Konzept üblich. Nehmen wir zum Beispiel das zweite Beispiel in der vorherigen HA-Beschreibung in Verbindung mit einer entsprechenden Wiederherstellung anderer Komponenten, die nicht von Citrix stammen, im Zusammenhang mit der Lösung. Dies würde als hochverfügbare DR-Lösung angesehen werden, bei der ein Dienst (Citrix) auf ein gegnerisches Rechenzentrum umschaltet. Diese Architektur kann als Aktiv-Passiv oder Aktiv-Active in verschiedenen Iterationen mit mehreren Standorten implementiert werden, wie Active-Passive für alle Benutzer, Active-Active, bei denen Benutzer ein Rechenzentrum einem anderen vorziehen, oder Active-Active, bei dem Benutzer ohne Präferenz ein Lastenausgleich zwischen zwei Rechenzentren erfolgt. Es ist wichtig zu beachten, dass bei der Entwicklung solcher Lösungen die Bereitschaftskapazität berücksichtigt, berücksichtigt und die Auslastung kontinuierlich überwacht werden muss, um sicherzustellen, dass die Kapazität für die Notfallwiederherstellung verfügbar bleibt, falls sie benötigt wird.

Es ist auch wichtig, dass die DR-Komponenten auf dem neuesten Stand der Produktion gehalten werden, um die Integrität der Lösung zu gewährleisten. Diese Aktivität wird häufig von Unternehmen ü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 aufrechtzuerhalten.

Im Kontext von Citrix würde das Überspannen von Citrix-Verwaltungsdomänen (Citrix Site, PVS-Farm usw.) zwischen zwei Rechenzentren, z. B. zwei geolokalisierte Einrichtungen gemäß den veröffentlichten Leitlinien, nicht für DR sorgen, und das gilt auch für einige Komponenten wie StoreFront-Servergruppen. In ähnlicher Weise wird eine solche Bereitstellung aufgrund der Beschränkungen der Datenbanklatenz von PVS gemäß den veröffentlichten Leitliniennicht empfohlen. Aufgrund der Latenzmaxima zwischen Satellitencontrollern und den Datenbanken gemäß den veröffentlichten Leitlinien gelten auch die Einschränkungen der Unterstützbarkeit zwischen verschiedenen Standorten und Zonen von Citrix.

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 würden, würde sich die Ausfalldomäne auf die Anwendungsdienste in beiden Einrichtungen auswirken. Um eine HA-Citrix-Lösung als ausreichend für DR anzusehen, empfehlen wir, dass die zweite Einrichtung keine wichtigen Abhängigkeiten oder administrativen Grenzen teilt. Erstellen Sie beispielsweise separate Sites, Farmen und Servergruppen für jedes Rechenzentrum in der Lösung. Indem wir eine möglichst unabhängige Wiederherstellungsplattform ermöglichen, reduzieren wir die Auswirkungen von Ausfällen auf Komponentenebene, die sich sowohl auf die Produktions- als auch auf die DR-Umgebung auswirken. Diese Überlegung geht auch über Citrix hinaus, und es wird auch empfohlen, verschiedene Dienstkonten, Dateidienste, DNS, NTP, Hypervisorverwaltung, Zertifizierungsstellen (FAS-Abhängigkeit) und Authentifizierungsdienste (AD, RADIUS usw.) zwischen Produktions- und DR-Umgebungen zu verwenden, um einzelne Fehlerquellen zu reduzieren.

Klassifizierung der Disaster Recovery-Stufe

Tier-Klassifizierungen für DR sind ein wichtiger Aspekt der DR-Strategie eines Unternehmens, da sie Klarheit über die Wichtigkeit von Anwendungen oder Diensten bieten, die wiederum die RTO (und damit die Kosten für die Erreichung dieses Wiederherstellungsniveaus) bestimmen. Alternativ richten einige Organisationen unterstützte RTO ein (unterstützt durch Technologielösungen oder Architekturmodelle) und weisen ihnen Stufenklassifizierungen zu. Im Allgemeinen gilt: Je kürzer der RTO, desto höher sind die Kosten für die DR-Lösung. Die Möglichkeit, verschiedene Abhängigkeiten in verschiedene Klassifizierungen zu unterteilen (basierend auf Geschäftskritikalität und RTO), kann zur Optimierung kostensensibler DR-Fälle beitragen.

Im Folgenden finden Sie eine Reihe von Beispielen für Klassifizierungen auf DR-Tierebene, die als Referenz für die Bewertung der Citrix Infrastrukturdienste, ihrer Abhängigkeiten und kritischer Anwendungen oder Anwendungsfälle (im Zusammenhang mit VDA-Workloads) dienen sollen, die auf Citrix gehostet werden. Die DR-Stufen sind in der Reihenfolge ihrer Wiederherstellungspriorität aufgeführt, wobei 0 die kritischste Stufe 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 (Beispiel)

Stufe 0 — Wiederherstellungsziele

Ziel der Erholungszeit: 0

Wiederherstellungspunkt-Ziel: 0

Stufe 0 — Klassifizierung

Kern-IT-Infrastruktur

  • Netzwerk- und Sicherheitsinfrastruktur
  • Netzwerk-Links
  • Hypervisoren und Abhängigkeiten (Rechner, Speicher)

Kern-IT-Services

  • Active Directory
  • DNS
  • DHCP
  • Dateidienste
  • RDS-Lizenzierung
  • CA Services (bei Verwendung von FAS)
  • SQL-Server (lokales WEM oder Citrix Virtual Apps and Desktops, PVS, Sitzungsaufzeichnung)
  • Kritische Endbenutzerdienste (Citrix)

Tier 0 - Hinweise

Diese Klassifizierung bezieht sich hauptsächlich auf 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 (Beispiel)

Stufe 1 — Wiederherstellungsziele

Ziel der Wiederherstellungszeit: 15 Minuten

Wiederherstellungspunkt-Ziel: 1 Stunde

Stufe 1 — Klassifizierung

Kritische Anwendungen

  • Websites und Web-Apps
  • ERPs und CRM-Anwendungen
  • Anwendungen für Geschäftsbereiche

Citrix-Anwendungsfälle

  • Verwaltung
  • Call Center
  • Kundenservice oder Vertrieb
  • IT-Technik und Support

Tier 1 - Hinweise

Anwendungen oder virtuelle Desktops, auf die das Unternehmen für die Durchführung seiner Kerngeschäftsaktivitäten angewiesen ist, sind in der Regel in dieser Stufe 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, die später erörtertwerden, berücksichtigt werden, da sie sich auf die RTO-Ziele auswirken können.

Disaster Recovery Tier 2 (Beispiel)

Stufe 2 — Wiederherstellungsziele

Ziel der Erholungszeit: 4 Stunden

Ziel des Wiederherstellungspunkts: 1 Tag

Stufe 2 — Klassifizierung

Unkritische Anwendungen

Unkritische Citrix-Anwendungsfälle

Benutzerdaten, die die Funktionalität von Tier-1- oder Tier-0-Apps nicht beeinträchtigen

Tier 2 - Hinweise

Anwendungen oder Anwendungsfälle, die für den Geschäftsbetrieb von entscheidender Bedeutung sind, deren kurzfristige Nichtverfügbarkeit jedoch wahrscheinlich keine schwerwiegenden finanziellen, Reputations- oder betrieblichen Auswirkungen haben wird. Diese Anwendungen werden entweder aus Backups wiederhergestellt oder mit der niedrigsten Priorität mithilfe automatisierter Wiederherstellungstools wiederhergestellt.

Disaster Recovery Tier 3 (Beispiel)

Stufe 3 — Wiederherstellungsziele

Ziel der Wiederherstellungszeit: 5 Tage

Ziel des Wiederherstellungspunkts: 1 Woche

Stufe 3 — Einstufung

Selten genutzte Anwendungen

Tier 3 - Hinweise

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

Disaster Recovery Tier 4 (Beispiel)

Stufe 4 — Wiederherstellungsziele

Ziel der Wiederherstellungszeit: 30 Tage

Recovery Point Objective: 24 Stunden oder keine

Stufe 4 — Klassifizierung

Nicht-Produktionsumgebungen

Tier 4 - Hinweise

Anwendungen, Infrastruktur und VDIs, deren Ausfälle ebenfalls nur geringe Auswirkungen auf den Geschäftsbetrieb haben, können im Laufe der Zeit wiederhergestellt werden. Je nach Art können sie auch ein erweitertes RPO haben oder gar nicht. Diese RPOs können aus Backups wiederhergestellt oder brandneu in DR erstellt werden und gelten als die letzte Stufe, die wiederhergestellt werden muss.

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 den Geschäftsbetrieb? Wenn Citrix als unverzichtbar angesehen wird, die Host-Anwendung jedoch als notwendig erachtet wird, würde die Citrix-Infrastruktur als kritisch eingestuft.
  • Die Anwendungsfälle oder Kerngeschäftsanwendungen, die Citrix hostet. Haben sie unterschiedliche DR-Tier-Klassifizierungen?

Was die erste Frage angeht, werden viele Citrix-Unternehmensumgebungen aufgrund der Bereitstellung kritischer Apps oder Desktops in der Regel als Tier 0 eingestuft; die „Always-on“ -Stufe wie Netzwerk-, Active Directory-, DNS- und Hypervisor-Infrastruktur. Dieser Umstand ist jedoch nicht immer bei jedem 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-Anwendungsfällen und verleiht ihre Bedeutung vor allem in Cloud-Umgebungen, auf die später näher eingegangenwird. In der Cloud gibt es erhebliche Kostenüberlegungen zwischen der Unterbringung von ständig verfügbaren Anwendungs- oder Desktop-Plattformen und 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-Designs für Citrix hilft es, die Erwartungen an die Geschäftsbereiche zu wecken, wenn die Diskussion über den Rahmen von Citrix selbst hinausgeht. Beispielsweise gilt eine Citrix-Umgebung als „Always-On-Service“ und wird in einem alternativen Rechenzentrum hochverfügbar gemacht. Die kritischen Back-Ends, 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 funktionieren nicht. Wenn von Anfang an Erwartungen gesetzt wird, werden alle Beteiligten über die Erfahrungen mit dem Wiederaufbau angemessen informiert. In einigen Situationen möchte ein Kunde Citrix in der gegenüberliegenden Einrichtung im Hot-Standby (immer eingeschaltet) belassen, den Failover der Zugriffsebene jedoch manuell steuern, um Missverständnisse bei der Plattformverfügbarkeit zu vermeiden.

Optionen für die Notfallwiederherstellung

In diesem Abschnitt werden allgemeine Wiederherstellungsstrategien von Citrix beschrieben, einschließlich ihrer Vor- und Nachteile sowie wichtige Überlegungen. Andere Wiederherstellungsfunktionen oder Variationen der folgenden Themen 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 Fragenthemen entsprechen mehreren der früheren DR-Fragen und haben folgende Auswirkungen auf das Design von Citrix DR:

  • Backupstrategie und Recovery Time Objective (RTO). Wenn die Citrix-Infrastruktur oder die von Citrix bereitgestellten Anwendungen als geschäftskritisch angesehen werden, muss Citrix wahrscheinlich ein „Always-On“ -Modell verwenden, bei dem Hot-Standby- oder Active-Active-Citrix-Infrastruktur in zwei oder mehr Rechenzentren vorhanden ist. 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 Übergreifen der Steuerungsebenen für die Citrix-Infrastruktur ist noch nicht gleich DR (z. B. die Ausdehnung eines Standorts über mehrere Rechenzentren oder die Verwendung von Satellitenzonen). Wenn das Unternehmen eine DR-Plattform für Citrix erwartet, widerspricht dies diesem Mandat.
  • Umfang der Wiederherstellung. Wenn Citrix in einer Hot-Standby-Kapazität (Always-On) in DR bereitgestellt wird, die Wiederherstellung der Backends der wichtigsten Geschäftsanwendungen jedoch beispielsweise 8 Stunden dauert, kann es keinen Sinn machen, ein automatisiertes Access Tier Failover zu verwenden. 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 wiederhergestellt werden müssen, kann die Klassifizierung der Wichtigkeit pro Anwendungsfall im Gegensatz zu den geschäftlichen Auswirkungen gemäß der zuvor erörterten Wiederherstellungs-Tiering-Strategie die Kapazitätskosten nicht senken, sondern den IT-Mitarbeitern eine gezieltere Reihe von Wiederherstellungsprioritäten bieten.
  • Fähigkeiten. Wenn bestimmte Komponenten wie HDX Insight und Sitzungsaufzeichnung nicht als entscheidend für den Betrieb der DR-Plattform angesehen werden, verringert ihr Fehlen in der DR-Umgebung die Komplexität und den 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. Verwenden Sie beispielsweise einen Hosted Shared Desktop anstelle von Pooled VDI oder Persistent VDI, sofern dies technisch machbar ist (im Kontext einer schnellen und kostengünstigen Servicewiederherstellung in einem DR-Szenario), oder die Zusammenfassung mehrerer Anwendungsfälle zu einem, sofern sie den Geschäftsbetrieb nicht beeinträchtigen. 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 Single-Image-Management-Technologie eine Anforderung für die Produktionsplattform sind, können solche Technologien oft nicht geeignet sein. Ein hybrider Ansatz aus einer Hot-Standby-Plattform von Citrix und möglicherweise der Replikation von Masterimages kann besser geeignet sein.
  • Kritikalität der Daten. Wenn Profile für die Wiederherstellung in DR als entscheidend erachtet werden, kann eine geeignete Replikationstechnologie erforderlich sein. Viele Organisationen kümmern sich weniger um Profile in DR-Szenarien und akzeptieren, dass sie erneut 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 außerdem 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 für die Wartung von Citrix mit entsprechenden lokalen Anwendungs-Backends in diesen Rechenzentren einsetzt (oder dies plant), ist es wahrscheinlicher, dass eine geolokalisierte Active-Active HA-DR-Architektur besser geeignet ist. Diese Architektur bietet Benutzern, wenn möglich, die optimale Benutzererfahrung, indem sie geolokalisierte Citrix-Infrastrukturen verwendet, die bei Bedarf ein Failover auf ein Backup-Rechenzentrum in einer sekundären Präferenzreihenfolge durchführen können.
  • Clientbenutzer. Abgesehen von dem vorherigen Punkt zu den Überlegungen zur Benutzer-, App- und Datenlokalisierung können einige Client-Benutzernetzwerke mit Sicherheitsgeräten (Proxy, Firewall usw.) relativ gesperrt sein, wodurch die ausgehende Kommunikation mit dem Internet oder sogar dem WAN eingeschränkt werden kann. Es ist wichtig zu berücksichtigen, ob dieser Status für die Client-Netzwerke gilt und sicherstellt, dass neue IPs für Citrix-Dienste (wie StoreFront-VIP- und VDA-IPs oder Citrix Gateway-IP) in ihren lokalen Sicherheitskonfigurationen berücksichtigt werden, um sicherzustellen, dass keine weiteren Wiederherstellungsverzögerungen aufgrund lokaler LAN-Sicherheitseinschränkungen beim Aufrufen von DR auftreten Wird sich der Kundenzugang aus Sicht der Bereitschaft im Falle einer DR auf irgendeine Weise ändern? In einigen DR-Szenarien kann eine Organisation beispielsweise davon ausgehen, dass das WAN nicht verfügbar ist und alle Benutzer über das Internet auf Citrix-Ressourcen zugreifen müssen. Solche Schritte müssten in den DR- und Bereitschaftsplänen dokumentiert werden, wobei die Voraussetzungen für Endbenutzer (in Bezug auf unterstützte Citrix-Kundendaten und Annahmen zum Unternehmens- oder BYOD-Gerätezugriff) festgelegt werden müssen, um Hindernisse für die Wiederaufnahme des Dienstes durch Benutzer zu beseitigen und so den Support Desk weiter zu entlasten.
  • Netzwerkbandbreite. Die Menge der Netzwerkbandbreite, die für den VDA-Verkehr (ICA, Anwendungen, Dateidienste) verwendet wird, muss bei der Netzwerkgröße und den Firewalls der DR-Einrichtung berücksichtigt 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 das Netzwerk effektiv zu dimensionieren Wo Netzwerkbeschränkungen bestehen, müssen Unternehmen unterschiedliche Netzwerkkonfigurationen verwenden, um die erwartete DR-Verkehrslast zu bewältigen, falls und wann sie aufgerufen wird.
  • Fallback (oder Failback). Wenn sich Benutzerdaten in DR geändert haben oder wenn VDA-Images während der DR aktualisiert wurden, muss das Unternehmen ein Failback einplanen, um diese Änderungen wieder an die Produktion weiterzugeben, falls sich die Produktionsumgebung als wiederherstellbar erweist. 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 zurück in die Produktion repliziert und VDAs entsprechend aktualisiert werden.

In der folgenden Liste werden verschiedene allgemeine Wiederherstellungsoptionen für Citrix beschrieben. In der Praxis gibt es Anpassungen der einzelnen Optionen (Unternehmen entscheiden sich manchmal dafür, nur Teile dieser Optionen zu implementieren, um DR auf kritische Anwendungsfälle zu beschränken, oder verwenden eine Mischung von Optionen, um die Kosten zwischen den Anwendungsfallstufen auszugleichen). Zum Vergleich skizzieren wir jedoch die Basisversionen der einzelnen Optionen. 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.

Darüber hinaus deuten viele Optionen darauf hin, dass Citrix-Technologien, die in Netzwerk und Speicher integriert sind, wie NetScaler und Single-Image-Management-Technologien, nicht für andere Methoden als „Always-On-Wiederherstellungsmodelle“ geeignet sind, obwohl sie realisierbar sind. Es ist nicht so, dass es technisch unmöglich wäre, dies zu erreichen, aber die Komplexität, die mit ihrer Erreichung verbunden ist, kann die Erholung riskanter und anfälliger für menschliche Fehler machen.

Wiederherstellungsoption - Wiederherstellen von Offline-Backup

Bei dieser Option verlassen sich Unternehmen ausschließlich auf herkömmliche Backup-Lösungen, um die Citrix-Plattform für den Betrieb an einem anderen Standort wiederherzustellen. Es gibt keine Standby-Infrastruktur, auf die ein Failover durchgeführt werden kann. Im Wiederherstellungsplan sind mehrere, oft manuelle Aufgaben erforderlich, um die Kerndienste wiederherzustellen, von denen Citrix abhängig ist, und später Citrix selbst wiederherzustellen. Die Ausfallzeit von Citrix hängt von der Geschwindigkeit ab, mit der Komponenten am DR-Standort wiederhergestellt werden können. Dieses Modell ist nicht ideal für erweiterte Citrix-Bereitstellungen und eignet sich am besten für kleinere, einfachere Infrastrukturen und Organisationen, die längere Ausfallzeiten aushalten können.

Notfallwiederherstellung

Vor- und Nachteile

Vorteile:

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

Nachteile:

  • Hohe Auswirkungen auf Ausfallzeiten
  • Umfassende, detailliertere Dokumentation des Wiederherstellungsplans (DR Orchestration)
  • Verlängerte Erholungszeit
  • Verlässt sich auf Integrität und Alter der Backups
  • Höheres Maß an menschlichem Versagen, wenn eine manuelle Neukonfiguration erforderlich ist (Netzwerkbetrieb usw.)
  • Nicht geeignet für Pooled, Fast Clone MCS oder PVS
  • Aufgrund von Netzwerken nicht für NetScaler VPX geeignet (und muss mithilfe von Backups des Verzeichnisses nsconfig und der Datei ns.conf neu erstellt werden)
  • Es müssen Überlegungen angestellt werden, den Umfang der Aufbewahrung von Backup ausreichend zu erweitern, um anderen modernen Bedrohungen wie Zeitbomben und Ransomware zu begegnen

Anwendungsfall und Annahmen

Nützlich für weniger ausgereifte IT-Organisationen und Organisationen mit begrenzten IT-Betriebsbudgets und kann längere Ausfälle zur Wiederherstellung der wichtigsten Geschäftsservices ermöglichen. Geht davon aus, dass Backups und der Wiederherstellungsprozess regelmäßig getestet werden, um sicherzustellen, dass die Backups gut sind und dass der Wiederherstellungsprozess von denjenigen, die ihn während eines realen Ereignisses durchführen müssen, gut verstanden wird.

Wiederherstellungsoption — Wiederherstellung über Replikation

Diese Option ähnelt der vorherigen Option, verwendet jedoch Replikation anstelle eines Backup, aus dem die Infrastruktur wiederhergestellt wird. Durch die Replikation können einige Aspekte manueller Aufgaben in der Wiederherstellungssequenz reduziert und möglicherweise die RTO reduziert werden (und somit der Service schneller wiederhergestellt werden), aber sie ist weiterhin auf viele manuelle Aufgaben angewiesen. Es sei darauf hingewiesen, dass die Replikation kein Ersatz für Backup ist. Beschädigte oder kompromittierte Daten werden immer noch in DR repliziert und sind daher in solchen Szenarien nicht nützlich. Backups müssen immer noch als Fallback betrachtet werden. Wie bei der vorherigen Option ist dieses Modell nicht ideal für erweiterte Citrix-Bereitstellungen und eignet sich am besten für kleinere, einfachere Infrastrukturen und Organisationen, die längere Ausfallzeiten aushalten können.

Notfallwiederherstellung

Vor- und Nachteile

Vorteile:

  • Die Replikation ist wahrscheinlich automatisiert und entspricht RTO und RPOs
  • Verwendet wahrscheinlich weniger komplexe Technologien im Vergleich zu automatisierten Wiederherstellungslösungen

Nachteile:

  • Verlässt sich auf administrative Eingriffe
  • Umfassende, detailliertere Dokumentation des Wiederherstellungsplans (DR Orchestration)
  • Höheres Maß an menschlichem Versagen, wenn eine manuelle Neukonfiguration erforderlich ist (Netzwerkbetrieb usw.)
  • Ungeeignet für Pooled, Fast Clone MCS oder PVS. Recreation of Machine Catalogs wird in den projizierten RTO einbezogen. Wenn Sie jedoch Dummy-Maschinenkataloge in DR erstellen oder VDA-Instanzen in DR skalieren und eine Aktion “Katalog aktualisieren” ausführen, bei der ein repliziertes Masterimage angewendet wird, kann dieser RTO verkürzt werden.
  • Aufgrund von Netzwerkproblemen nicht für NetScaler VPX geeignet und daher besser geeignet, Hot-Standby-NetScaler einzusetzen und die Kosten dafür zu übernehmen

Anwendungsfall und Annahmen

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

Wiederherstellungsoption — Replikation mit automatisierter Wiederherstellung

Bei dieser Option wird die automatische Wiederherstellung für mehrere Komponenten der Lösung eingeführt, um die Citrix-Infrastruktur und ihre Abhängigkeiten am DR-Standort wiederherzustellen. Technologien, die die automatische Wiederherstellung orchestrieren, reduzieren die manuellen Schritte weiter und minimieren menschliche Eingriffe (und potenzielle menschliche Fehler). Außerdem können sie die RTO weiter verbessern, indem sie die Wiederherstellung des Dienstes rationalisieren. Es wird davon ausgegangen, dass weiterhin Eingriffe erforderlich sind, um mithilfe von DNS-Eintragsänderungen auf den DR-Standort umzuschalten. Es sei darauf hingewiesen, dass die Replikation kein Ersatz für Backup ist. Beschädigte oder kompromittierte Daten werden immer noch in DR repliziert und sind daher in solchen Szenarien nicht nützlich. Backups werden weiterhin als Fallback betrachtet. Dieses Modell ist zwar ausgereifter, eignet sich aber weiterhin nicht für die Verwendung mit erweiterten Citrix-Konfigurationen oder für Unternehmen, die keine großen Ausfallzeiten tolerieren können.

Notfallwiederherstellung

Vor- und Nachteile

Vorteile:

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

Nachteile:

  • Verlässt sich auf fortschrittlichere Technologien wie VMware SRM, Veeam, Zerto, Nutanix Disaster Recovery Orchestration, XenServer Disaster Recovery und Azure Site Recovery (ASR), um die Wiederherstellung zu orchestrieren und Netzwerkparameter zu ändern (sofern die Netzwerksegmente nicht gestreckt sind)
  • Nicht geeignet für Pooled, Fast Clone MCS oder PVS. Recreation von Maschinenkatalogen muss in den projizierten RTO einbezogen werden. Wenn Sie jedoch Dummy-Maschinenkataloge in DR erstellen oder VDA-Instanzen in DR skalieren und eine Aktion “Katalog aktualisieren” ausführen, bei der ein repliziertes Masterimage angewendet wird, kann dieser RTO verkürzt werden.
  • Aufgrund von Vernetzung nicht für NetScaler VPX geeignet und daher besser geeignet für den Einsatz von Hot-Standby-NetScaler

Anwendungsfall und Annahmen

Nützlich für Unternehmensorganisationen mit entsprechenden Ressourcen und Budgets für DR-Einrichtungen. Diese Lösung basiert auf derselben Speicherreplikation wie die vorherige Option, umfasst jedoch DR-Orchestrierungstechnologien zur Wiederherstellung von VMs in einer bestimmten Reihenfolge, zur Anpassung der NIC-Konfigurationen (falls erforderlich) usw.

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

Wir beginnen nun, uns Optionen anzusehen, die eine Hot-Standby-Infrastruktur verwenden. Die Vorteile eines entsprechend konzipierten Hot-Standby-Modells sind zwar kostspieliger, reduzieren aber die Anzahl der Schritte, die zur Orchestrierung der Wiederherstellung am DR-Standort erforderlich sind, drastisch, reduzieren das Risiko technologischer und menschlicher Fehler und können die Wiederherstellungszeit erheblich verringern. Für diese Modelle müssen separate, unabhängige Citrix-Infrastrukturen verwaltet werden, die mehr Aufwand verursachen (fortlaufende Wartung und Tests), aber auch fortgeschrittenere Citrix-Bereitstellungen ermöglichen, die Single-Image-Management-Technologien verwenden. Bei dieser Option ist das Failover auf das Eingreifen des Administrators angewiesen, um den Datenverkehr über DNS-Änderungen an den alternativen Standort umzuleiten, wodurch die Kosten und die Komplexität eines automatisierten Failovers der Zugriffsebene reduziert werden. Diese Option eignet sich am besten für Unternehmen, die über ein ausreichendes Budget verfügen, um eine Standby-Citrix-Infrastruktur unterzubringen, sich auf erweiterte Citrix-Konfigurationen verlassen und eine geringe RTO, aber manuell gesteuerte Wiederherstellung benötigen.

Notfallwiederherstellung

Vor- und Nachteile

Vorteile:

  • Kurze Wiederherstellungszeit, da die Plattform “immer aktiv” ist
  • Unterstützt speicher- und netzwerkabhängige Komponenten wie NetScaler, MCS, PVS
  • Dokumentation des niedrigeren Wiederherstellungsplans (DR-Orchestrierung)

Nachteile:

  • Verlässt sich auf administrative Eingriffe, um ein Failover der URL durchzuführen oder Benutzer anzuweisen, die URL zu sichern (obwohl die manuelle Orchestrierung manchmal beabsichtigt ist)
  • Höhere Kosten aufgrund der Tatsache, dass „heiße“ Hardware in DR im Standby-Modus ist
  • Höherer Verwaltungsaufwand, um die Konfigurationen und Updates der Standby-Plattform mit der Produktion synchron

Anwendungsfall und Annahmen

Nützlich für Unternehmensorganisationen mit entsprechenden Ressourcen und Budgets für DR-Einrichtungen. Kann eine „voll skalierte“ Hot-Standby-Plattform oder eine „skalierbare On-Demand-Plattform“ verwenden. Letzteres kann für die Cloud-Wiederherstellung attraktiv sein, um die Betriebskosten zu senken, mit Vorbehalten.

Zum Zeitpunkt des Failovers aktualisieren Administratoren den **DNS-Eintrag** für eine oder mehrere Zugriffs-URLs so, dass er auf eine oder mehrere DR-IPs für Citrix Gateway und StoreFront verweist, oder Benutzern wird in formeller Kommunikation empfohlen, zunächst eine „Backup“ - oder „DR“ -URL zu verwenden.

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.

Bei diesem Modell wird davon ausgegangen, dass eine ausgereifte IT-Organisation vorhanden ist und genügend WAN- und Recheninfrastruktur zur Unterstützung von Failover verfügbar ist.

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

Ähnlich wie die vorherige Hot-Standby-Option beinhaltet diese Option automatisiertes Failover, in der Regel über DNS-Technologien, die Ausfälle in der Produktion erkennen und den Datenverkehr an den DR-Standort umleiten. Aufgrund der Automatisierung müssen die IT-Teams sicherstellen, dass die Konfigurationen in der Notfallwiederherstellung ordnungsgemäß verwaltet werden und Anwendungs- und Datenabhängigkeiten während des regulären Betriebs von DR aus zugänglich bleiben, um Auswirkungen auf Benutzer zu vermeiden, die aufgrund einer vorübergehenden Betriebsunterbrechung in der Produktion am DR-Standort landen könnten. Kapazitätsmanagement und -überwachung (um sicherzustellen, dass DR dieselbe Anzahl von Benutzern auf Citrix aufnehmen kann wie in der Produktion) werden aufgrund der automatisierten Failover-Fähigkeit immer wichtiger. Diese Option eignet sich am besten für Unternehmen, die über ein ausreichendes Budget verfügen, um eine Standby-Citrix-Infrastruktur unterzubringen, sich auf erweiterte Citrix-Konfigurationen verlassen und einen RTO von nahezu Null benötigen.

Notfallwiederherstellung

Vor- und Nachteile

Vorteile:

  • Kurze Wiederherstellungszeit, da die Plattform “immer aktiv” ist
  • Unterstützt speicher- und netzwerkabhängige Komponenten wie NetScaler, MCS, PVS
  • Dokumentation des minimalen Wiederherstellungsplans (DR-Orchestrierung)
  • Einfacher für Endbenutzer als URLs Failover
  • Unterstützt EPA-Scans bei Citrix Gateway mit GSLB

Nachteile:

  • Höhere Kosten aufgrund von „heißer“ Hardware in DR im Standby-Modus und NetScaler-Lizenzierung. Die Kostenbelastung kann bis zu einem gewissen Grad reduziert werden, wenn die Standby-Kapazität von der Entwicklung oder anderen weniger kritischen Workloads genutzt wird, die während eines DR-Ereignisses abgeschaltet werden können, um der Wiederherstellung der Produktion Priorität einzuräumen
  • Höhere Komplexität der Zugangsebene
  • Höherer Verwaltungsaufwand, um die Konfigurationen und Updates der Standby-Plattform mit der Produktion synchron zu halten

Anwendungsfall und Annahmen

Eine bei Unternehmensorganisationen übliche Konfiguration, die einen automatisierten Failover zum DR-Standort über NetScaler GSLB (Advanced oder höher erforderlich) ermöglicht. Dieses Modell setzt eine ausgereifte IT-Organisation und eine ausreichende WAN- und Recheninfrastruktur zur Unterstützung von Failover voraus. Dieses Modell geht auch davon aus, dass die Abhängigkeiten zwischen Anwendungen und Benutzerdaten den neuesten Versionen und Updates der aktiven Site entsprechen und in der DR-Einrichtung auf ähnlich automatisierte Weise wiederhergestellt werden können, um die anhaltenden Auswirkungen des Dienstes auf den Endbenutzer und die Verwirrung aufgrund unvollständiger Lösungsfunktionen zu verringern.

Wiederherstellungsoption — Aktiv-Aktiv mit automatisiertem Failover

Diese Option baut auf der ersten auf, aber während des regulären Betriebs werden sowohl die Produktions- als auch die DR-Standorte aktiv genutzt. Die Kapazität kann streng verwaltet und überwacht werden, da in einem solchen Modell leichter übersehen wird, wenn einer der Standorte einen Schwellenwert überschritten hat (z. B. Auslastung von 40— 45%), um sicherzustellen, dass einer der Standorte während eines DR-Ereignisses die volle Benutzerlast bewältigen kann. Da beide Umgebungen aktiv genutzt werden, ist die routinemäßige Validierung der meisten Komponenten integriert. Komponenten, für die ein Failover zum DR-Standort erforderlich ist (Apps, Speicher-Arrays usw.), werden jedoch weiterhin routinemäßigen regelmäßigen Failover-Tests unterzogen. Da das Modell zwei oder mehr aktive Standorte verwendet, müssen Leistungstoleranzen und Abweichungen zwischen Standorten berücksichtigt werden, insbesondere wenn sich die Standorte über große geografische Entfernungen erstrecken. Einige Leistungsabweichungen können in diesem Modell minimiert werden, indem Benutzer während des regulären Betriebs zu einem Standort statt zu einem anderen zugewiesen werden (Lokalisierung der VDAs) und ein Failover zu anderen VDAs erfolgt, wenn ihr lokaler Standort nicht verfügbar ist. Dieses Modell ist das komplexeste und robusteste und eignet sich für die fortschrittlichsten Citrix-Bereitstellungen. Es ist ideal für Unternehmen, die eine RTO von Null benötigen und ein Modell wünschen, bei dem nur 50% der Benutzer während eines DR-Ereignisses einen Failover vornehmen, während es bei 100% der Fall ist.

Notfallwiederherstellung

Vor- und Nachteile

Vorteile:

  • Kurze Wiederherstellungszeit, da die Plattform “immer aktiv” ist
  • Unterstützt speicher- und netzwerkabhängige Komponenten wie NetScaler, MCS, PVS
  • Dokumentation des minimalen Wiederherstellungsplans (DR-Orchestrierung)
  • Nahtlos für Endbenutzer
  • Unterstützt EPA-Scans bei Citrix Gateway mit GSLB (NetScaler 13.0+ Firmware-Versionen ab 2022 können EPA-Scans in Active-Active-GSLB-Konfigurationen unterstützen, die zuvor nur in Active-Passive-Konfigurationen funktionierten)

Nachteile:

  • Höhere Kosten aufgrund von „heißer“ Hardware in DR im Standby-Modus und NetScaler-Lizenzierung. Die Kostenbelastung kann bis zu einem gewissen Grad reduziert werden, wenn die Standby-Kapazität von der Entwicklung oder anderen weniger kritischen Workloads genutzt wird, die während eines DR-Ereignisses abgeschaltet werden können, um der Wiederherstellung der Produktion Priorität einzuräumen
  • Höchste Komplexität der Zugangsebene
  • Höherer Verwaltungsaufwand, um die Konfigurationen und Updates der Standby-Plattform mit der Produktion synchron zu halten
  • 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, wenn die Plattform wächst

Anwendungsfall und Annahmen

Eine fortgeschrittenere, aber bei Unternehmensorganisationen übliche Konfiguration, die es ermöglicht, URLs auf Zugriffsebene über NetScaler GSLB (NetScaler Advanced oder höher erforderlich) auf Active-Active-Weise zu betreiben. 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 setzt eine ausgereifte IT-Organisation und eine ausreichende WAN- und Recheninfrastruktur zur Unterstützung von Failover voraus. 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, die On-Prem to Cloud-Plattformen oder Cloud-to-Cloud umfasst, bringt ihre eigenen Herausforderungen oder Überlegungen mit sich, die sich in lokalen Wiederherstellungsszenarien häufig nicht stellen.

Die folgenden wichtigen Überlegungen können bei der Planung des DR-Entwurfs berücksichtigt werden, um Fehltritte zu vermeiden, die dazu führen können, dass der DR-Plan, der die Cloud-Infrastruktur verwendet, entweder ungültig, zu teuer ist oder die Zielkapazität im DR-Fall nicht erreicht.

Überlegung — Netzwerkdurchsatz

Wirkungsbereiche

Verfügbarkeit, Leistung Kosten

Details

Unternehmen können die Durchsatzknotenpunkte in ihren Cloud-Lösungen, einschließlich virtueller Firewalls, VPN-Gateways und WAN-Uplinks (AWS Direct Connect, Azure Express Route, GCP Cloud Interconnect usw.), unterschätzen und somit unterschätzen. Dies kann sich erheblich negativ auf die Leistung auswirken, wenn die Citrix-Plattform in der Cloud wiederhergestellt und über das WAN zugänglich sein soll. Beachten Sie auch die VPN-Gateway-Grenzwerte, wenn Sie es mit einem Cloud-Anbieter verwenden. Beispielsweise haben AWS Transit Gateways derzeit ein maximales Limit von 1,25 Gbit/s. Dieses Limit kann die Skalierung von Gateways oder möglicherweise die Verwendung mehrerer VPCs erfordern, wenn diese für die Cloud-Architektur von entscheidender Bedeutung sind. Für Azure- und GCP-VPN-Gateways gelten höhere Grenzwerte. Viele virtuelle Firewalls haben lizenzierte Grenzwerte für den Durchsatz, den sie verarbeiten können, oder Höchstwerte, selbst bei deren höchsten Grenzwerten. Diese Einschränkung kann eine Skalierung der Anzahl der Firewalls und einen gewissen Lastenausgleich erfordern.

Empfehlungen

Gehen Sie beim Erstellen von Berechnungen zur Durchsatzgröße von der vollen DR-Kapazitätslast aus Erfassen Sie die folgenden Daten pro gleichzeitigem Benutzer:

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

Für die vorherigen Metriken kann es nützlich sein, Daten zu aktuellen Datenverkehrsmustern zu und von VDAs in der Produktion zu sammeln. Es ist auch wichtig zu berücksichtigen, welche anderen Datenflüsse, die nichts mit Citrix zu tun haben, diese Netzwerkpfade voraussichtlich ebenfalls verwenden. Achten Sie darauf, die Netzwerk- und Sicherheitsteams in die Planung von Citrix DR einzubeziehen, um sicherzustellen, dass alle Bandbreitenschätzungen, die Sicherheitszonen und Netzwerksegmente durchqueren, verstanden und berücksichtigt werden können.

Überlegungen — Authentifizierungsdienste

Wirkungsbereiche

Verfügbarkeit Leistung Sicherheit

Details

Authentifizierungsdienste sind für den Betrieb von Citrix-Plattformen von entscheidender Bedeutung. Die meisten verlassen sich weiterhin auf Microsoft Active Directory Domain Services (AD DS). Wenn Sie den Citrix Federated Authentication Service (FAS) verwenden, sind auch Microsoft-Zertifizierungsstellen (CAs) oder unterstützte Zertifizierungsstellen von Drittanbietern für den laufenden Betrieb der Plattform von entscheidender Bedeutung. Das heißt, wenn sie ausgefallen sind, ist Citrix ausgefallen.

Einige Unternehmen weigern sich weiterhin, die Infrastruktur für Authentifizierungsdienste in öffentlichen Clouds zu platzieren, und führen häufig Sicherheitsbedenken an. Dies hat zur Folge, dass die Authentifizierungs- und Vermittlungsleistung beeinträchtigt wird, wenn während des regulären Betriebs Backhauling auf schreibbare on-premises Domänencontroller (DCs) erfolgt, und die Verfügbarkeit und Erreichbarkeit von DCs und CAs in einem DR-Szenario darf nicht übersehen werden.

Empfehlungen

Implementieren Sie ausreichende Ausgleichskontrollen, um den Bedenken des Sicherheitsteams Rechnung zu tragen, und platzieren Sie beschreibbare DCs und CAs (falls FAS verwendet wird) in der Nähe der Citrix-Infrastruktur in der Cloud. Wenn dies nicht verhandelbar ist, stellen Sie sicher, dass die Wiederherstellung für diese Server geplant und die Erreichbarkeit für diese Server validiert ist, falls das Produktionsrechenzentrum ausfällt oder nicht erreichbar ist.

Überlegung — Lizenzierung für Windows Desktop OS

Wirkungsbereiche

Kosten

Details

Es gibt potenziell komplexe Lizenzierungsüberlegungen für Microsoft Desktopbetriebssysteminstanzen, die auf verschiedenen Cloud-Plattformen ausgeführt werden. Microsoft hat seine Cloud-Lizenzrechte im August 2019 überarbeitet, was sich in einigen Bereitstellungsszenarien auf die Auswirkungen auf die VDI-Kosten auswirken kann. Die Microsoft-Lizenzierung für Office 365/Microsoft 365-Apps hat sich auch in Bezug auf die Unterstützung von öffentlichen Clouds und Betriebssystemtypen verändert.

Empfehlungen

Die Lizenzierung von Microsoft-Produkten ist eine sich ständig weiterentwickelnde Angelegenheit. Aktuelle Informationen zu Lizenzierung und Unterstützungserklärungen bei der Festlegung der Anwendungsfallarchitektur erhalten Sie bei Microsoft und dem Cloud-Anbieter (falls relevant). Wenn die DR-Lösung ein potenzielles Kostenproblem für VDI darstellt, sollten Sie eine Ergänzung durch Hosted Shared Desktops (Erweiterung der RDS-CALs kann erforderlich sein) in Betracht ziehen, sofern dies möglich ist, da diese mehr Flexibilität bei niedrigeren Betriebskosten bieten können. Einschränkungen oder zukünftige Supportänderungen erfordern eine vollständige Neubewertung der für DR verwendeten Plattform.

Überlegung — Timing des VDA-Scale-outs (vor oder während der DR)

Wirkungsbereiche

Kosten Verfügbarkeit

Details

Unternehmen erwägen Cloud-Lösungen, weil sie für Kapazität nur dann zahlen, 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ßen Maßstäben kann sich ein Cloud-Anbieter jedoch nicht auf ein SLA festlegen, das den gleichzeitigen Betrieb von Hunderten oder Tausenden von VMs vorsieht. Diese Lösung wird besonders schwierig, wenn der VDA-Footprint für DR voraussichtlich Hunderte oder Tausende von Instanzen umfassen wird. Cloud-Anbieter neigen dazu, große Kapazitäten für verschiedene Instanzgrößen vorzuhalten. Dieser Anbieter kann jedoch von Moment zu Moment variieren. Tritt eine Katastrophe ein, die sich auf ein geografisches Gebiet auswirkt, kann es zu erheblichen Konflikten durch andere Mandanten kommen, die ebenfalls Kapazitäten auf Abruf anfordern.

Verwechseln Sie im Fall von Azure reservierte Instanzen nicht mit reservierter Kapazität (auf Abruf). Wenn Sie Reserved Instances als Absicherung gegen die Verfügbarkeit von Ressourcen in einer DR-Region bei Bedarf wählen, wäre es ratsam, sie bereitzustellen, da Microsoft nicht garantiert, dass die Kapazität bei Bedarf verfügbar ist. Bei On-Demand-Kapazitäten reserviert Microsoft Kapazitäten direkt (zu nutzungsbasierten Tarifen). Letztlich wäre es ratsam anzunehmen, dass garantiert nur laufende VDAs verfügbar sind.

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

  • Ist immer 100% DR-Kapazität erforderlich?
  • Für welche Arten von Katastrophen sind geplant? Wenn es sich um eine regionale Katastrophe handelt, wäre es dann ratsam, eine einzelne Cloud-Region oder eine Cloud-Region in der Nähe der Produktion zu verwenden?
  • Hosten wir nur kritische Workloads (d. h. nur einen Teil der Produktion)?
  • Ist es möglich, zur Zeit von DR zu skalieren? Falls ja, wurden die Anwendungsfälle von DR Tiers priorisiert, um die unterschiedlichen RTOs der einzelnen Anwendungsfälle besser zu verstehen und ein schrittweises Scale-out der Kapazität zu unterstützen?
  • Können wir die Betriebssysteminstanzen, die Anwendungsfälle für Apps oder gehostete gemeinsam genutzte Desktops unterstützen, skalieren, um Bereitstellungszeit zu sparen, und diese Instanzen ausschalten, um Betriebskosten zu sparen?

Empfehlungen

Citrix empfiehlt, sich zunächst mit Ihrem Cloud-Anbieter in Verbindung zu setzen, um festzustellen, ob die erwartete Kapazität innerhalb des RTO-Zeitrahmens eingeschaltet werden kann und ob sie 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 Cloud-Anbieter haben vorgeschlagen, unterschiedliche Größen von VM-Instanztypen zu verwenden, um die VM-Erschöpfung weiter zu verringern.

Einige Unternehmen möchten das Anbieterrisiko diversifizieren und eine Multi-Cloud-Bereitstellung einführen, bei der Anwendungsfälle über zwei verschiedene Cloud-Anbieter bereitgestellt werden, um sich gegen den Ausfall einer gesamten Cloud-Plattform abzusichern (DNS, Routing, Sicherheitsverletzung usw.).
Dieses Szenario erhöht zwar die Komplexität und weist keine Leistungs- oder Funktionsparität zwischen den Clouds auf, aber diese potenziell geringfügigen Vorbehalte werden durch den wahrgenommenen Wert der Plattformdiversifizierung in den Hintergrund gedrängt. Wenn möglich, wäre es ratsam, VDA-Instanzen vorab bereitzustellen und sie regelmäßig zu aktualisieren (ob sie online oder offline bleiben, liegt im Ermessen und in der Risikobereitschaft des Kunden). Die Provisioning ist ein ressourcen- und zeitintensiver Prozess, und die bedarfsgerechte Skalierung der VDA-DR-Kapazität kann durch die Vorabbereitstellung bis 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, Modelle nach Bedarf und reservierte/dedizierte Modelle zu kombinieren, indem auf die DR-Wiederherstellungsstufe verwiesen wird. In bestimmten Anwendungsfällen müssen VDAs möglicherweise sofort verfügbar sein, während andere die Flexibilität haben, über einen längeren RTO von mehreren Tagen oder Wochen wiederhergestellt zu werden, wenn sie für die Aufrechterhaltung des Geschäfts weniger wichtig sind.

Berücksichtigung — Anwendungs- und Benutzerdaten

Wirkungsbereiche

Kosten, Verfügbarkeit und Leistung

Details

Der Speicherort von Benutzerdaten und Anwendungs-Backends kann erhebliche Auswirkungen auf die Leistung und manchmal auf die Verfügbarkeit der Citrix DR-Umgebung haben. In einigen Kundenszenarien wird ein DR-Ansatz für mehrere Rechenzentren verwendet, bei dem nicht alle Anwendungs-Backends oder Benutzerdaten wie Heim- und Abteilungslaufwerke zusammen mit 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 Netzwerk- und Sicherheits-Appliance-Bandbreite weiter belasten.

Empfehlungen

Wenn möglich, sollten Sie Anwendungs- und Benutzerdaten lokal auf der Citrix-Plattform in DR speichern, um die Leistung so optimal wie möglich zu halten, indem Latenz und Bandbreitenanforderungen im gesamten WAN reduziert werden. Ermitteln Sie, was in DR tatsächlich wiederherstellbar sein muss (FSLogix Office Container sind möglicherweise nicht kritisch, und einige Anwendungsfälle funktionieren problemlos, wenn ein neues Profil erstellt wird) und stellen Sie sicher, dass Anwendungspakete und Container auf der DR-Site verfügbar sind. Es ist entscheidend, die geeignetste und kostengünstigste Replikationslösung zu ermitteln. Dieses Thema wird später in diesem Handbuch weiter behandelt.

Notfallwiederherstellungsplanung für Citrix Cloud

Es gibt mehrere bemerkenswerte Unterschiede zwischen der on-premises oder “traditionellen” Bereitstellung von Citrix Virtual Apps and Desktops und dem von Citrix Cloud bereitgestellten Citrix DaaS in Bezug auf die DR-Planung:

  • 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.
  • Für die Bereitstellung einer DR-Umgebung für Citrix-Ressourcen muss ein Kunde lediglich Citrix Cloud Connectors im wiederhergestellten “Ressourcenstandort” und optional StoreFront und NetScaler (für Citrix Gateway) bereitstellen.
  • Die einzigartige Service-Architektur von Citrix Cloud ist geografisch redundant und robust.
  • Access Tier DR ist nicht erforderlich, wenn Citrix Workspace und NetScaler Gateway Service 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 NetScaler Gateway Service und Citrix Workspace Service nicht von Citrix Cloud verwendet werden.

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

Citrix DaaS vereinfacht Disaster Recovery

Im Folgenden finden Sie ein typisches Konzeptdiagramm, das die konzeptionelle Architektur von Citrix DaaS sowie die Trennung der Verantwortung für von Citrix verwaltete Komponenten und von Partnern und Kunden verwaltete Komponenten beschreibt. Hier nicht dargestellt sind die WEM-, Analytics- und NetScaler Gateway- “Dienste”, bei denen es sich um Wahlkomponenten von Citrix Cloud handelt, die sich auf Citrix DaaS beziehen und unter “Managed by Citrix” fallen würden.

Notfallwiederherstellung

Wie in der Abbildung dargestellt, fällt ein erheblicher Teil der Control-Komponenten, für die Wiederherstellungsentscheidungen erforderlich sind, in den Managementbereich von Citrix. Als Cloud-basierter Dienst ist die Citrix DaaS-Architektur innerhalb der Citrix Cloud-Regionäußerst widerstandsfähig. Es ist Teil der „Secret Sauce“ von Citrix Cloud und wird in den SLAs von Citrix Cloud berücksichtigt.

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

  • Citrix ist. Kontrollebene und Zugriff auf Dienste, falls sie verwendet werden (Citrix Workspace, Citrix Gateway Service).
  • Kunde. Komponenten für den Ressourcenstandort, einschließlich Cloud Connectors, VDAs, Anwendungs-Back-Ends, Infrastrukturabhängigkeiten (AD, DNS usw.) und Zugriffsebene (StoreFront, NetScaler), wenn die Citrix Cloud-Zugriffsebene nicht verwendet wird.

Unternehmen profitieren von den folgenden Vorteilen bei der Notfallwiederherstellung auf Citrix DaaS:

  • 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 Citrix DaaS Disaster Recovery

Obwohl viele Komponenten für die Wiederherstellungsplanung aus dem Verwaltungsbereich des Unternehmens herausgenommen wurden, sind Unternehmen weiterhin für die Planung und Verwaltung von DR und Hochverfügbarkeit (optional) für die Komponenten verantwortlich, die sich am Ressourcenstandort befinden.

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 Citrix DaaS selbst werden Ressourcenstandorte als Zonendargestellt. Mit Zonenpräferenz können wir das Failover zwischen Ressourcenstandorten basierend auf der von uns angegebenen Logik verwalten. Die Verwendung der Zonenpräferenz innerhalb einer traditionell bereitgestellten Citrix Virtual Apps and Desktops-Site würde als Hochverfügbarkeitsdesign, aber nicht als gültiges DR-Design angesehen werden. Im Zusammenhang mit Citrix Cloud ist diese Option eine gültige DR-Lösung.

Die meisten der zuvor erörterten Disaster Recovery-Optionen gelten für Citrix DaaS, sodass es zahlreiche Optionen gibt, die den Zielen und Budgets der Organisation für die Wiederherstellung entsprechen.

Bei der Planung von DR für den Citrix DaaS-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. Aus Gründen der Klarheit handelt es sich bei Cloud Connectors nicht um eine Komponente, die während eines DR-Ereignisses manuell oder automatisch „wiederhergestellt“ werden muss. Sie müssen als „Hot-Standby“ -Komponenten betrachtet werden und an jedem Standort immer online sein.
  • Von Kunden verwaltete Access Controller (optional). Organisationen können sich aus verschiedenen Gründen dafür entscheiden, ihre eigenen NetScaler für Citrix Gateway- und StoreFront-Server bereitzustellen und Citrix Workspace oder Citrix Gateway Service nicht zu nutzen. Diese können Folgendes umfassen:
    • Benutzerdefinierte Authentifizierungsabläufe
    • Erweiterte Branding-Fähigkeiten
    • Höhere Flexibilität beim Routing von HDX-Datenverkehr
    • Besserer Einblick in die HDX-Netzwerkleistung (HDX Insight)
    • Prüfung von ICA-Verbindungen und Integration in SIEM-Plattformen
    • Möglichkeit, den Betrieb fortzusetzen, wenn die Verbindung des Cloud Connectors zur Citrix Cloud getrennt wird, mithilfe der Local Host Cache-Funktion der Cloud Connectors mit StoreFront

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

Überlegungen zur Bedienung

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. Unternehmen 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 werden, um sicherzustellen, dass ihr Nutzen nicht beeinträchtigt wird, falls die Wartung katastrophal schief geht, und zwar auf eine Weise, die in Umgebungen ohne Produktion nicht zur Geltung kommt.
  • Patching und Wartung. Eine routinemäßige Wartung im Gleichschritt mit der Produktion bei der Verwendung von “Hot Standby” Citrix-Plattformen ist für die Aufrechterhaltung einer funktionierenden DR-Plattform unerlässlich. Es ist wichtig, DR in Bezug auf Betriebssystem-, Citrix Produkt- und Anwendungspatches mit der Produktion synchron zu halten. Um das Risiko zu minimieren, wird empfohlen, zwischen der Patch-Produktion und dem Patchen der DR mehrere Tage bis eine Woche einzuplanen.
  • Regelmäßige Tests. Unabhängig davon, ob DR die Replikation der Produktion auf eine Wiederherstellungseinrichtung oder die Verwendung von „Hot-Standby“ -Umgebungen beinhaltet, ist es wichtig, den DR-Plan regelmäßig (idealerweise ein- oder zweimal im Jahr) zu testen, um sicherzustellen, dass die Teams mit den Wiederherstellungsprozessen vertraut sind und alle Fehler in der Plattform oder den Arbeitsabläufen identifiziert und behoben werden. Übung macht den Meister. Ein Plan kann auf dem Papier funktionieren, aber Tests zeigen, dass die Erwartungen an die RTO- und RPO-Ziele nicht erreichbar sind, eine Reihenfolge der Abläufe angepasst werden muss oder ein Versehen berücksichtigt werden muss. Beispielsweise kann die tatsächliche Zeit für die Synchronisierung und den Failover-Speicher zu einem unerwarteten Datenverlust führen, der eine Anpassung an die Erwartungen oder die Replikationskonfiguration erforderlich macht.
  • 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, kann die Ressourcennutzung leicht über beispielsweise einen stationären Auslastungsschwellenwert von 50% in jeder Umgebung hinaus erhöht werden, nur damit ein DR-Ereignis eintritt und die überlebende Plattform überfordert wird und entweder eine schlechte Leistung erbringt oder aufgrund der Überlastung. Die Kapazität kann monatlich oder vierteljährlich überprüft werden.

Überlegungen zur Datenwiederherstellung

In diesem Abschnitt werden wir kurz verschiedene Konzepte und Überlegungen zum Umgang mit Benutzerprofilen, VDA-Images und Anwendungen (App-V, App Layers, MSIX usw.) in Szenarien mit mehreren Standorten und DR-Szenarien behandeln.

Replikation versus Backup

Beide Funktionen der Datenverfügbarkeit und Datenintegrität sind wichtige Faktoren, wenn es um die Wiederherstellung kritischer Datensätze wie Kerninfrastruktur, Images, Benutzerdaten und Apps geht. Replikationsfunktionen, die normalerweise in Public-Cloud-Lösungen angeboten werden, bieten zwar praktische Mechanismen, um die Widerstandsfähigkeit kritischer Daten sicherzustellen, aber die Replikation befasst sich nicht mit Datenbeschädigungen oder DR-Szenarien, in denen selbst replizierte Daten gefährdet wurden. Replikation ist kein Ersatz für Backups, und sofern finanziell machbar, müssen beide verwendet werden. Replikation kann zur schnellen Wiederherstellung von Daten beitragen, während Backups bei der Wiederherstellung nach Datenverlust oder -beschädigung helfen können (in dem Umfang, der durch die Aufbewahrungsrichtlinie und das Backup-Intervall vorgegeben wird). Ob on-premises oder in der Cloud, es stehen zahlreiche Backup-Optionen zur Verfügung.

Wo wir gerade beim Thema sind, ist es in der aktuellen Cybersicherheitslandschaft ratsam, die Richtlinien zur Aufbewahrung von Backup sorgfältig zu prüfen, da Ransomware-Angriffe jetzt „Time Bombing“ einsetzen, bei denen Datensätze kompromittiert werden, aber normal erscheinen, während die Ransomware bis zu einem bestimmten Datum inaktiv bleibt. Indem sie das „lange Spiel“ spielen, können Cyberkriminelle Backups mit kürzeren Aufbewahrungsfristen bei der Wiederherstellung nutzlos machen. Eine Verlängerung der Aufbewahrungsfristen erhöht die Kosten, erhöht aber die Wahrscheinlichkeit, dass wichtige Daten wiederhergestellt werden.

Was kann ich wiederherstellen? Klassifizierung der Datenkritikalität

Während sich ein Großteil dieses Artikels auf Verfügbarkeits- und Wiederherstellungsoptionen für die Citrix-Infrastruktur konzentriert hat, wird auch die Verfügbarkeit verschiedener Datensätze berücksichtigt, um die Geschäftserwartungen mit den Kosten in Einklang zu bringen. Wenn beispielsweise Benutzerprofile am DR-Standort nicht verfügbar sind, stellt dies lediglich eine Unannehmlichkeit oder ein erhebliches Hindernis für den Geschäftsbetrieb dar? Die Antwort auf diese Frage wird sich direkt auf die Komplexität und die Kosten der Infrastrukturkomponenten auswirken. Im Folgenden finden Sie eine Liste von Überlegungen zu allgemeinen Daten im Zusammenhang mit einer Citrix-Plattform:

  • Benutzerprofile. Beinhaltet Citrix Profile Management (CPM) -Profile oder -Container, User Layers oder FSLogix-Container. Unternehmen müssen entscheiden, ob sie in der DR wiederhergestellt werden müssen und welche RTO- und RPO-Werte sie haben. In einigen Anwendungsfällen lohnen sich die Kosten für die Wiederherstellung von Profilen in DR nicht, wenn das Erstellen von Profilen lediglich eine Unannehmlichkeit ist, da die Benutzer 10 bis 15 Minuten zusätzlichen Aufwand für die Einrichtung neuer Profile in DR benötigen. Für andere Anwendungsfälle ist es nicht verhandelbar. Office-Container können es nicht wert sein, repliziert zu werden, da es sich um Caches mit Online-Daten handelt. Diese Differenzierung in der Diskussion über Benutzerprofile und Benutzerdaten ermöglicht eine Reduzierung der Speicher- und Replikationskosten, indem entschieden wird, diese Container nicht zu replizieren (und spricht dafür, FSLogix-Profilcontainer von Office-Containern zu trennen).
  • Images / Layers. In den meisten Fällen muss nicht wirklich entschieden werden, ob Images wiederhergestellt werden sollen oder nicht (Masterimages, PVS-vDisks, App Layering-Layer), sondern wie sie wiederhergestellt werden sollen. Werden sie automatisch repliziert? Oder werden sie unabhängig von Produktion und DR verwaltet?
  • Anwendungen. Hier beziehen wir uns speziell auf containerisierte Anwendungen (Elastic Layer, MSIX, App-V). Wie bei Images geht es bei der Entscheidung eher darum, „wie“ die Wiederherstellung erfolgt, und nicht darum, „ob“.

Replikationsoptionen

Ob in einer Public Cloud oder on-premises, es stehen mehrere Replikationstechnologien zur Auswahl. Dieser Abschnitt behandelt viele gängige Optionen, erhebt jedoch keinen Anspruch auf Vollständigkeit. Beachten Sie, dass in vielen Szenarien, in denen Replikation verwendet wird, ein Datenverlust bis zu einem gewissen Grad unvermeidlich ist, es sei denn, der DR-Standort ermöglicht eine synchrone Replikation. Andernfalls wird bei den Wiederherstellungsoptionen in der Regel ein RPO-Wert berücksichtigt, wobei der niedrigste Wert häufig bei 15 Minuten liegt (abhängig von Plattform/Tool/Szenario). Je häufiger das Replikationsintervall ist, desto höher sind in der Regel die Kosten.

Benutzerprofile (in allen Formen), Benutzerlayer, Apps und Images können in vielen Unternehmen den Datenverlust eines Tages aushalten und so den Umfang des standortübergreifenden Datenverkehrs und den Bandbreitenverbrauch reduzieren. In einigen Anwendungsfällen ist der Verlust von Benutzerprofildaten im Zusammenhang mit DR- und Replikationskosten für das Unternehmen belanglos. Unabhängig von der gewählten Option müssen sowohl die IT-Abteilung als auch das Unternehmen die Erwartungen in Bezug auf einen potenziellen Datenverlust während eines ungeplanten DR-Ereignisses kennen. Geplante DR-Ereignisse bieten die Möglichkeit, vor einem Failover eine vollständige Datenreplikation durchzuführen.

In öffentlichen Clouds sind native Fileservices-Lösungen wie Azure NetApp Files, Azure Files und AWS FSx für die Speicherung von Benutzerdaten üblich und verfügen häufig über integrierte Replikationsfunktionen innerhalb einer Region oder in andere Regionen. Wenn Sie Produktion und DR innerhalb einer Cloud-Plattform planen und Daten in andere Regionen replizieren, sollten Sie bei der Auswahl der zu verwendenden Regionen darauf achten, welche Regionspaare sie haben, um sicherzustellen, dass die Daten in die von Ihnen gewünschte Region repliziert werden können. Azure führt hier eine Liste von replikationsübergreifenden Regionspaaren. Azure NetApp Files hat hier auch eine eigene replikationsübergreifende Regions-Paarliste. Bei der Bereitstellung in Regionen, die in Azure nicht gepaart sind, können Daten in einer Region wiederhergestellt werden, die eine höhere Latenz für Ihre VDAs generiert.

In einigen Fällen kann dies überwunden werden, indem man sich nicht auf solche Technologien verlässt und Replikationsfunktionen auf App-Ebene wie z. B. FSLogix (falls verwendet) Cloud Cache verwendet. Im Gegensatz dazu schränkt AWS FSx die Replikation über Regionspaare nicht ein, was eine größere Auswahl ermöglicht. Beachten Sie die Cloud-Replikationsoptionen, bei denen SMB-Verbindungen nicht beibehalten werden. Wenn Azure beispielsweise georedundanten Speicher (GRS) verwendet, verwaltet es keine SMB-Handles oder Leases, was sich je nach Ausfallszenario auf Benutzer auswirken kann und eine Abmeldung/Anmeldung erforderlich macht, um die betroffenen Shares für Apps, Layer oder Profile erneut bereitzustellen.

Optionen von Drittanbietern, insbesondere NetApp Cloud Volumes OnTap (CVO), sind auch in wichtigen Public Clouds (einschließlich GCP) verfügbar und bei Unternehmen beliebt, die Erfahrung mit NetApp haben und ein ähnliches Management- und Funktionserlebnis in Clouds wünschen.

Beachten Sie wie beim Azure GRS-Beispiel, dass viele Technologien, die die Wiederherstellung von Dateifreigaben zwischen Rechenzentren oder öffentlichen Cloud-Regionen beinhalten, SMB-Verbindungen nicht beibehalten. Dies kann dazu führen, dass Benutzer sich bei einem Failover ab- und wieder anmelden müssen, um die Dateifreigaben für Technologien, die den Zugriff nicht automatisch erneut versuchen und auch eine manuelle Wiederherstellung der Freigabe/des Volumes erfordern, erneut bereitzustellen. Dies macht sich in einem vollständigen DR-Szenario nicht bemerkbar, in dem sich Benutzer bei einem anderen VDA als der Produktion anmelden, um die Produktivität wiederherzustellen.

Vor Ort empfiehlt Citrix Professional Services Unternehmen seit langem, native Filerplattformen (d. h. IP-Netzwerk-Dateidienste, die von SANs oder NAS-Geräten bereitgestellt werden) zu verwenden, sofern sie verfügbar sind, da sie über robuste Funktionen verfügen und im Vergleich zu Windows-basierten Dateiserverlösungen weniger Overhead erwarten. Dies ist besonders wichtig bei der Planung von Speicherreplikationsfunktionen für einen DR-Standort.

Wenn Hardware-/Appliance-Filer-Lösungen nicht verfügbar sind, sind Windows-basierte Lösungen ein Fallback (stellen Sie sicher, dass sie gemäß den Anweisungen von Microsoft optimiert und ordnungsgemäß gesichert wurden). Es stehen verschiedene Optionen zur Verfügung, deren Leistung und Kapazitätsskalierbarkeit jedoch wahrscheinlich eingeschränkter sind als integrierte Lösungen:

  • Eigenständiger Dateiserver. Ein einfacher Windows-Dateiserver für das Hosten von Citrix-Datenanforderungen, einschließlich Profil- und App-Containern, Benutzerprofilen, Microsoft-Ordnerumleitung usw., sofern die Umgebung nicht rund um die Uhr verfügbar ist und Ausfällen standhält.
    • Vorteile: Einfach einzurichten und zu warten
    • Nachteile:Keine Hochverfügbarkeit, keine Replikationsfähigkeit, sofern nicht eine andere Technologie wie DFS-R, Storage Replica oder VMware Site Recovery Manager (SRM), Veeam, Robocopy usw. verwendet wird. Neustarts (geplant oder ungeplant) unterbrechen Benutzerprofile, Benutzerdaten (wie Startlaufwerke und Microsoft Folder Redirection), gemountete App-Pakete und Personal vDisk-Zugriff (was wahrscheinlich zu abgestürzten PVS-Zielen führt)
  • Windows-Dateicluster. Eine wichtige Technologie in Windows-Umgebungen, die auf Windows Failover Clustering basiert. Vorgesehen für die Schaffung einer hohen Verfügbarkeit für Dateifreigaben in einem lokalen Rechenzentrum.
    • Vorteile: Robuste und ausgereifte Lösung, ideal für Citrix-Datenanforderungen für verschiedene Profil- und Containertypen, ermöglicht Failover zwischen Knoten, ohne SMB-Sitzungen von Clients zu unterbrechen
    • Nachteile: Nicht als DR-Lösung gedacht, eher als HA-Lösung. Die Einrichtung und Wartung kann je nach verwendeter gemeinsam genutzter Speicherarchitektur komplexer sein. Nicht ideal für Rechenzentrumsübergreifende Anwendungen, es sei denn, die Wiederherstellung erfolgt mit einem Wiederherstellungsorchestrierungstool auf VM-Ebene wie VMware SRM oder mithilfe von DFS-R oder sogar Robocopy zur Replikation von Änderungen zwischen zwei Clustern
  • Verteiltes Dateisystem (DFS. DFS-Replikation (DFS-R) und DFS-Namespace (DFS-N) sind zwei der ältesten Dateiserverreplikations- und Verfügbarkeitsoptionen in Windows, die ursprünglich für Active Directory-Replikationsfunktionen verwendet wurden. Sie können unabhängig voneinander konfiguriert werden, werden jedoch häufig zusammen konfiguriert. Aufgrund seiner Verbreitung in langlebigen Microsoft-Unternehmen ist es für viele Administratoren eine vertraute Lösung. Die unterstützte Anwendbarkeit auf Citrix-Umgebungen ist jedoch begrenzt.
  • Vorteile: Vertrautheit mit Administratoren, einfach einzurichten, kann sich über mehrere Rechenzentren erstrecken und ist nicht auf komplexe Clusterkonfigurationen angewiesen (kann aber überlagert werden)
  • Nachteile: DFS hat viele Einschränkungen und ist für die meisten Anwendungsfälle der Datenreplikation im Zusammenhang mit Citrix nicht ideal. DFS-N und DFS-R werden von Microsoft in Kombination miteinander für verschiedene gängige Benutzerdaten- und Profilszenariennicht unterstützt, können aber in Aktiv-Passiv-Szenarien (unidirektionale Replikation) mit manuellem Failover unterstützt werden (eines, bei dem Benutzer sich ab- und wieder anmelden müssen, um den Dateiserverzugriff wiederherzustellen). Sie eignen sich nicht für das Hosten von App-Paketen/Containern, es sei denn, Benutzer können sich ab- und wieder anmelden
  • Speicherreplik. Storage Replica ermöglicht die Replikation von Volumes zwischen Servern oder Clustern in Szenarien mit mehreren Rechenzentren. Es kann in drei Formen konfiguriert werden, darunter Stretch-Cluster, Cluster-zu-Cluster und Server-zu-Server. Sowohl asynchrone als auch synchrone Replikation sind möglich.
    • Vorteile: Unterstützt automatisches Failover, wenn es zusammen mit Storage Spaces Direct zur Bildung eines Stretch-Clusters verwendet wird. Kann (abhängig vom Testen der Failover-Leistung) für Benutzerprofile, Benutzerdaten, Profilcontainer, App-Container und Layer geeignet sein. Wenn keine Stretch-Cluster verwendet werden, möglicherweise nur für FSLogix-Container geeignet
    • Nachteile: Wenn Stretch-Cluster nicht verwendet werden, muss das Failover manuell durchgeführt werden. SMB-Sitzungen, die eine Abmeldung/Anmeldung erfordern, um den Zugriff auf Benutzerprofile und Daten wiederherzustellen, werden getrennt. Nicht zum Hosten von App-Paketen/Containern geeignet, wenn keine Stretch-Cluster verwendet werden
  • Dateiserver mit horizontaler Skalierung. Scale-Out-Dateiserver eignen sich ideal für Anwendungsfälle mit größeren Dateien wie VM-Datenträger oder Anwendungsdaten, die nicht besonders schreibintensiv sind.
    • Vorteile: Kontinuierliche Verfügbarkeit für SMB (reduziert Ausfallzeiten bei einem Failover zwischen Knoten), ideal für virtuelle Datenträger, Anwendungscontainer, Layer und Profilcontainer, kann sich über Rechenzentren erstrecken
    • Nachteile: Nicht empfohlen für Benutzerprofile (Roaming-Profile, CPM), Microsoft-Ordnerumleitung gemäß Microsoft

Je nach Datensatz ist es möglicherweise nicht wichtig, denselben Namespace-Pfad zwischen Produktions- und DR-Rechenzentren beizubehalten. Die Beibehaltung unabhängiger Pfade für Benutzerprofile, App-Paketfreigaben, Elastic oder User Layers, Profilcontainer usw. kann die Komplexität verringern. Bewerten Sie die Auswirkungen für jeden Datensatztyp, einschließlich Überlegungen zur umgekehrten Replikation und zum Failback, wenn nicht in einem Active-Active-Szenario gearbeitet wird. In Active-Active-Szenarien wäre es ideal, Benutzer einem regionalen Rechenzentrum und nicht einem anderen zuzuordnen, um zu vermeiden, dass Apps und Datencontainer zwischen Standorten installiert und die Latenz erhöht wird.

Überlegungen zur Wiederherstellung von App Layering

Unternehmen, die App Layering ausführen, sollten sich die Citrix-Referenzarchitektur für App Layering ansehen. Es gibt mehrere Komponenten, für die Backups geeignet sind, darunter die Appliance, Elastic Layer Shares und User Layer Shares.

  • Appliance-Backups stellen sicher, dass alle Layer verfügbar sind, auch wenn die Appliance irgendwie zerstört wird. Diese Backups stellen sicher, dass alle Layer verfügbar sind, auch wenn die Appliance irgendwie zerstört oder beschädigt ist.
  • Elastic Layers werden bei der Anmeldung von einem SMB-Share aus bereitgestellt. Es ist wichtig sicherzustellen, dass die Dateiserver/Dienste, die für Elastic Layers verwendet werden, hochverfügbar sind, indem geeignetes Clustering verwendet wird. Es ist wichtig, native Hardware- (oder Cloud-) Filesharing-Lösungen oder Windows-basierte Lösungen zu verwenden, die eine kontinuierliche SMB-Verfügbarkeit unterstützen. Die Verwendung mehrerer DFS-R-Ziele ist für diesen Anwendungsfall nicht ausreichend, denn wenn ein Ziel ausfällt, können die bereitgestellten VHD-Dateien erst wieder einem anderen Ziel zugeordnet werden, wenn eine weitere Anmeldung erfolgt. In ähnlicher Weise ist Storage Replica in verschiedenen Konfigurationen aus ähnlichen Gründen, wie bereits erwähnt, nicht geeignet.
  • Benutzerlayer sind aus DR-Perspektive komplizierter. Diese beschreibbaren virtuellen Festplatten werden von Windows bei der Anmeldung bereitgestellt und vom Windows-Desktop gesperrt.
    • Wie bei Elastic Layers sind native Hardware- oder Cloud-Fileshare-Lösungen aufgrund der Einschränkungen gängiger Windows-basierter Methoden wie DFS-R oder Robocopy optimal. Machen Sie sich bewusst, dass Benutzerebenen in der Regel größer sind und sich Blöcke häufig ändern. Replikationsmethoden, die sich auf Blockebene replizieren, anstatt die gesamte Datei zu kopieren, wenn sie geändert wird, sind überlegen, da Unternehmen sonst möglicherweise untragbare Mengen an Benutzerlayer-Replikation zwischen Standorten erleben.
    • Aufgrund der Schwierigkeiten bei der Replikation großer Datenträger oder der damit verbundenen Kosten entscheiden sich Unternehmen in den meisten Fällen dafür, DR-Desktops für Benutzer ohne replizierte Benutzerlayer bereitzustellen.

Überlegungen zur Wiederherstellung von Profilen

Die Wiederherstellung von Profilen erfordert eine geeignete Speicherreplikations- und Zugriffsstrategie, unabhängig davon, ob sich die Profile in on-premises Rechenzentren oder in der Public Cloud befinden. Dieser Abschnitt soll auf den vorherigen Überlegungen zur Wiederherstellung aufbauen, die zuvor für die einzelnen Profillösungen erörtert wurden. Stellen Sie für jeden Anwendungsfall die Frage „Muss das Profil in einem DR-Szenario tatsächlich wiederhergestellt werden?“ Wenn dies nicht der Fall ist, können Kosten und Komplexität wahrscheinlich erheblich reduziert werden.

Allgemeine Empfehlungen:

  • Bestätigen Sie, ob die Profildaten überhaupt repliziert werden müssen oder ob nur ein Teil davon repliziert werden muss. Wenn Sie beispielsweise FSLogix-Profilcontainer verwenden, möchten Sie diese möglicherweise in ein Profil und einen Office-Container aufteilen (möglicherweise auf unterschiedlichen Freigaben für eine detaillierte Replikationskontrolle, wenn Sie auf die Speicherreplikation angewiesen sind), um Flexibilität bei der Replikation der Profilcontainer zu bieten, aber nicht der Office-Container (die während eines DR-Ereignisses bei Bedarf erstellt werden können).
  • Verwenden Sie zunächst speziell entwickelte „native“ Dateidienstplattformen (Filer) on-premises oder in der Cloud. Es sind zahlreiche Windows-Optionen verfügbar, die jedoch in der Regel weniger robust sind (sowohl in Bezug auf Funktionen als auch Skalierbarkeit), mehr Overhead und mehr Einschränkungen aufweisen. Lokale Redundanz wird zusätzlich zur standortübergreifenden Redundanz dringend empfohlen, um einige der häufigsten Fallstricke von Failover-Szenarien zu vermeiden, die SMB-Verbindungen unterbrechen können.
  • Wenn Sie virtuelle Festplatten (bei denen es sich in der Regel um große Dateien handelt) mit einer hohen Änderungsrate replizieren, z. B. Benutzerlayer und Profilcontainer, sollten Sie Replikationslösungen in Betracht ziehen, die auf Blockebene replizieren können und bei Änderung keine vollständige Kopie der Datei auslösen, da sonst Speicheranbieter und Netzwerkdurchsatz überfordert werden können.
  • Betrachten Sie das RPO-Intervall. Je kürzer es ist, desto höher sind die Kosten und die Belastung von Speicher- und Netzwerksystemen. Eine asynchrone Replikationsoption, die ein Gleichgewicht zwischen Datenverlusttoleranz und Replikationsintervall herstellt, ist optimal.
  • Entwerfen Sie die Lösung so, dass Profile für die VDAs an beiden Standorten lokal sind, um die Leistung zu verbessern.
  • Wenn Sie CPM verwenden und DFS verwenden möchten, finden Sie Informationen zu DFS in der CPM-DR-Dokumentation .
  • Vorbehaltlich der Tests sollten Sie Cloud Cache in Betracht ziehen, um die Replikation und Wiederherstellung zu vereinfachen, da die Funktion die Replikation von Profildaten auf Anwendungsebene abwickelt und es Administratoren ermöglicht, eine bevorzugte Liste von Container-Zielfreigaben (eine pro Dateiserver-Speicheranbieter) pro Rechenzentrum festzulegen (in der Regel über GPO-/OU-Strukturen). Andere Überlegungen zu Cloud Cache werden von Microsoft bereitgestellt und müssen bei der Planung berücksichtigt werden. Cloud Cache hat Nachteile und bestimmte Szenarien können zu Ausfällen führen. Daher sollten Unternehmen die potenziellen Risiken überprüfen, um zu verstehen, ob die Vorteile der Replikation und Wiederherstellung von Profilen auf Anwendungsebene diese überwiegen.
  • Planen Sie ein Failback ein, das eine Umkehrung der Replikation von DR zur Produktion beinhalten kann.

Überlegungen zur Wiederherstellung von Anwendungspaketen

Wenn wir uns auf Anwendungspakete beziehen, beziehen wir uns zusammen auf App-V, MSIX, Elastic Layers und ähnliche Anwendungspakete. Diese sind typischerweise leseintensiv, aber nicht schreibintensiv und werden im Vergleich zu Profilen nicht so häufig aktualisiert. Im Folgenden finden Sie einige allgemeine Empfehlungen für diesen Datentyp:

  • Verwenden Sie zunächst speziell entwickelte „native“ Dateidienstplattformen (Filer) on-premises oder in der Cloud.
  • Erwägen Sie, separate Dateifreigaben für die Anwendungen beizubehalten (d. h. nicht denselben Pfad oder Namespace zu verwenden) und die VDAs so zu verweisen, dass sie ihre lokale Dateifreigabe verwenden. Synchronisieren Sie die Dateifreigaben manuell oder per Robocopy.

Überlegungen zur Wiederherstellung von Images

Masterimages und PVS-vDisks müssen bei der DR-Wiederherstellungsstrategie ebenfalls berücksichtigt werden. Wenn Masterimages verloren gehen, ist der Neuaufbau mit erheblichem Aufwand verbunden. App Layering fällt in diese Klassifizierung, wurde aber bereits behandelt. Im Folgenden finden Sie einige allgemeine Empfehlungen, die Sie berücksichtigen sollten:

  • Replizieren Sie Masterimages und PVS-vDisks zwischen Rechenzentren oder Cloud-Regionen, wenn Sie sich auf dasselbe Image zwischen Produktion und DR verlassen. Ziehen Sie eine manuelle Replikation in Betracht, um zu verhindern, dass ein beschädigtes Image an DR übertragen wird.
  • Sichern Sie Masterimages und PVS-vDisks (einschließlich Versionsdateien und Manifestdateien), idealerweise an einem externen Speicherort und nicht an einem Produktionsstandort.
  • Verwenden Sie Azure Compute Gallery (früher Shared Image Gallery), wenn Sie Azure verwenden, um Bilder über Regionen, Abonnements und Mandanten hinweg zu replizieren undso ein gemeinsames Image-Repository bereitzustellen.

Zusammenfassung

Wir haben einiges zum Thema Disaster Recovery in Citrix behandelt. In den folgenden Punkten werden die Kernaussagen und Erkenntnisse dieses Handbuchs zusammengefasst, die Architekten und Kunden bei der Planung ihrer Citrix-Wiederherstellungsstrategie berücksichtigen sollten:

  • 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 Wiederherstellungsstrategie muss auf die Geschäftsziele abgestimmt sein.
  • Hochverfügbarkeit ist nicht gleichbedeutend mit Disaster Recovery. Disaster Recovery kann jedoch eine hohe Verfügbarkeit beinhalten.
  • Die gemeinsame Nutzung administrativer Grenzen 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 und die auf Citrix gehosteten Anwendungen sind der wichtigste Einflussfaktor bei der Definition des Disaster Recovery-Designs. Ein kürzerer RTO erfordert oft höhere Lösungskosten.
  • Disaster Recovery-Architekturen für Citrix, die keine „heiße“ Disaster Recovery-Plattform verwenden, schränken die Technologien ein, die ein Kunde verwenden kann, wie Citrix MCS, NetScaler und Provisioning.
  • Eine Disaster Recovery-Strategie für Citrix muss die Wiederherstellungs- und Wiederherstellungszeit von Benutzerdaten und Anwendungs-Backends berücksichtigen. Citrix kann so konzipiert werden, dass eine schnelle Wiederherstellung möglich ist. Benutzer können jedoch dennoch nicht arbeiten, wenn Anwendungs- und Datenabhängigkeiten nicht in einem ähnlichen Zeitraum verfügbar sind.
  • Bei der Notfallwiederherstellung in Cloud-Umgebungen gelten andere Überlegungen, die in on-premises Umgebungen nicht berücksichtigt werden. Diese müssen Unternehmen überprüfen, um unvorhergesehene Engpässe oder betriebliche Auswirkungen zu vermeiden, wenn sie eine Notfallwiederherstellung in Cloud-Umgebungen aufrufen.
  • 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.
  • Unternehmen müssen ihren Disaster Recovery-Plan für Citrix regelmäßig testen, um zu überprüfen, ob er funktioniert und ob er seinen Hauptzweck erfüllt.
  • Citrix DaaS vereinfacht viele Aspekte der DR-Architektur erheblich und ermöglicht die Redundanz von Ressourcenstandorten über Zonenpräferenzkonfigurationen.
  • Planen und wählen Sie Ihre Replikationsoptionen für Benutzerdaten, Anwendungspakete, Layer, vDisks und Profilcontainer mit Bedacht aus, um sicherzustellen, dass deren Einschränkungen bekannt sind und ihre Funktionen den Geschäftsanforderungen entsprechen.
  • Verwechseln Sie Replikation nicht mit Backup. Sie gehen Hand in Hand und ziehen die Aufbewahrung von Backups eingehender in Betracht, da Ransomware-Backups mit „Time Bombing“ immer häufiger vorkommen.

Quellen

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

Designentscheidung: Planung der Notfallwiederherstellung

In diesem Artikel