Entwurfsmethodik-Zugriffsebene

Hinweis

Dieser Artikel wurde maschinell übersetzt. Haftungsausschluss

Auf Englisch anzeigen

Die zweite Ebene der Entwurfsmethode ist die Zugriffsebene, die für jede Benutzergruppe definiert ist.

Das Erstellen eines geeigneten Entwurfs für die Zugriffsebene ist ein wichtiger Bestandteil des Desktopvirtualisierungsprozesses. Diese Schicht behandelt die Benutzervalidierung durch Authentifizierung und orchestriert den Zugriff auf alle Komponenten, die für die Einrichtung einer sicheren virtuellen Desktopverbindung erforderlich sind.

Die Entwurfsentscheidungen für die Zugriffsebene basieren auf den Mobilitätsanforderungen der einzelnen Benutzergruppen sowie den verwendeten Endpunktgeräten.

Authentifikation

Der Zugriff auf Ressourcen basiert auf der Identität des Benutzers. Bei der Definition der Authentifizierungsstrategie wird der Einstiegspunkt des Benutzers in die Umgebung sowie die Authentifizierung des Benutzers berücksichtigt.

Entscheidung: Authentifizierungsanbieter

Normalerweise benötigten Benutzer einen Active Directory-Benutzernamen und ein Kennwort, um Zugriff auf ihre XenApp- und XenDesktop-Ressourcen zu erhalten. Da die meisten Organisationen eine lokale Active Directory-Bereitstellung standardisierten, war diese besondere Anforderung einfach zu erreichen.

Organisationen verwenden externe Auftragnehmer, die ein Konto benötigen, um Zugriff auf die Ressourcen von XenApp und XenDesktop zu erhalten. Organisationen untersuchen die Verwendung eines Drittanbieter-Identitätsanbieters (IdP) wie Azure Active Directory, Google, LinkedIn usw., anstatt ihre eigenen zu verwalten.

Mit der Implementierung von Citrix Federated Authentication Service unterstützen XenApp und XenDesktop die Verwendung eines Drittanbieter-IdP. Ein Administrator kann von einem Auftragnehmer sein Google-Konto verwenden, um Zugriff auf seine genehmigten Anwendungen und Desktops zu erhalten, was das Onboarding vereinfacht.

Entscheidung: Authentifizierungspunkt

Bevor ein Benutzer eine Verbindung zu einer virtuellen Ressource herstellt, muss er sich zuerst authentifizieren. Der Ort der Authentifizierung wird oft durch die Mobilitätsanforderungen der Benutzergruppe bestimmt, die während desBenutzersegmentierungProzesses definiert wurden. In XenDesktop stehen zwei Authentifizierungspunkte zur Verfügung:

  • StoreFront — Citrix StoreFront bietet Authentifizierungs- und Ressourcenbereitstellungsdienste für Citrix Receiver, sodass zentralisierte Enterprise-Stores Desktops, Anwendungen und andere Ressourcen bereitstellen können.
  • NetScaler Gateway — NetScaler Gateway ist eine Appliance, die einen sicheren Anwendungszugriff und detaillierte Richtlinienkontrollen auf Anwendungsebene für Anwendungen und Daten bietet, während Benutzer von überall aus arbeiten können.

In der folgenden Tabelle werden die bevorzugten Authentifizierungspunkte gemäß den Mobilitätsanforderungen für Benutzergruppen aufgelistet:

Mobilitätsanforderungen der Benutzergruppe Bevorzugter Authentifizierungspunkt
Lokal StoreFront
Roaming Lokal StoreFront
Fernbedienung NetScaler Gateway
Lokal NetScaler Gateway

Die Authentifizierung für Benutzergruppen mit einer Mobilitätsanforderung für Remote- oder Mobilgeräte kann bei Bedarf direkt in StoreFront erfolgen. Beispielsweise können DMZ-Sicherheitsrichtlinien den Zugriff vom NetScaler Gateway auf die Domäne verbieten, die zur Unterstützung der Smartcard-Clientzertifikatauthentifizierung erforderlich ist. Der Zugriff auf StoreFront zur Authentifizierung kann dann über einen virtuellen NetScaler SSL_BRIDGE Server bereitgestellt werden, der einen Conduit für den HTTPS-Datenverkehr bereitstellt. Normalerweise wird der virtuelle Server neben einem NetScaler Gateway auf demselben NetScaler gehostet, der für den HDX-Proxy-Zugriff auf die virtuelle Desktopumgebung konfiguriert ist. Obwohl ein solcher Anwendungsfall manchmal notwendig sein kann, empfiehlt es sich, externe Benutzer über NetScaler Gateway zu authentifizieren.

Entscheidung: Authentifizierungsrichtlinie

Sobald der Authentifizierungspunkt identifiziert wurde, muss der Authentifizierungstyp ermittelt werden. Die folgenden Optionen sind die primären verfügbaren Methoden:

  • StoreFront — Unterstützt eine Reihe unterschiedlicher Authentifizierungsmethoden, jedoch werden je nach Benutzerzugriffsmethode, Sicherheitsanforderungen und Netzwerkstandort nicht alle empfohlen. Beachten Sie, dass StoreFront Benutzer standardmäßig direkt mit Active Directory authentifiziert, nicht über XML wie das Webinterface. StoreFront 3.0 + kann optional so konfiguriert werden, dass die Authentifizierung an XML delegiert wird (z. B. wenn sich die StoreFront-Server in einer Domäne befinden, die den Benutzerdomänen nicht vertraut).
    • Benutzername und Kennwort : Benutzer müssen sich direkt bei der Site anmelden, indem sie einen Benutzernamen und ein Kennwort eingeben.
    • Domänenpass-Through — Ermöglicht das Durchführen von Domänenanmeldeinformationen von Benutzergeräten. Benutzer authentifizieren sich bei ihren Windows-Computern, die der Domäne angehören, und werden automatisch angemeldet, wenn sie auf ihre Stores zugreifen.
    • NetScaler Gateway Pass-Through — Ermöglicht die Pass-Through-Authentifizierung von NetScaler Gateway. Benutzer authentifizieren sich bei NetScaler Gateway und werden automatisch angemeldet, wenn sie auf ihre Stores zugreifen.
    • Smartcard — Ermöglicht Benutzern die Authentifizierung mit Smartcards und PINs über Citrix Receiver für Windows und NetScaler Gateway. Um die Smartcard-Authentifizierung zu aktivieren, müssen Benutzerkonten entweder in der Microsoft Active Directory-Domäne mit den StoreFront-Servern oder in einer Domäne konfiguriert werden, die eine direkte bidirektionale Vertrauensstellung mit der StoreFront-Serverdomäne aufweist. Bereitstellungen mit mehreren Gesamtstrukturen, die unidirektionale Vertrauensstellungen oder Vertrauensstellungen unterschiedlicher Typen enthalten, werden nicht unterstützt.
    • Anonym — Benutzer können auf Anwendungen und Desktops zugreifen, ohne Anmeldeinformationen für StoreFront oder Citrix Receiver vorzulegen. Lokale anonyme Konten werden bei Bedarf auf dem Server-VDA erstellt, wenn Sitzungen gestartet werden. Dies erfordert einen StoreFront-Store, der für den nicht authentifizierten Zugriff konfiguriert ist, einen Serverbetriebssystembasierten VDA und eine XenApp-Bereitstellungsgruppe, die für nicht authentifizierte Benutzer konfiguriert ist.
  • NetScaler Gateway — Das NetScaler Gateway unterstützt mehrere Authentifizierungsmethoden. Die folgende Liste enthält diejenigen, die hauptsächlich in virtuellen Desktopumgebungen verwendet werden. Jedes kann einzeln verwendet werden, wird jedoch oft kombiniert, um eine Multi-Faktor-Authentifizierung bereitzustellen.
    • LDAP — Das Lightweight Directory Access Protocol (LDAP) wird für den Zugriff auf Verzeichnisinformationsdienste wie Microsoft Active Directory verwendet. NetScaler Gateway verwendet LDAP, um Benutzer zu authentifizieren und ihre Gruppenmitgliedschaftsinformationen zu extrahieren.
    • RADIUS (Token) - Remote Authentication Dial in User Service (RADIUS) ist ein UDP-basiertes Netzwerksicherheitsprotokoll, das Authentifizierung, Autorisierung und Kontoführung bereitstellt. Ein Netzwerkzugriffsserver (in diesem Fall NetScaler Gateway) leitet Anmeldeinformationen an einen RADIUS-Server weiter, der die Anmeldeinformationen entweder lokal überprüfen oder mit einem Verzeichnisdienst überprüfen kann. Der RADIUS-Server könnte dann die Verbindung annehmen, die Verbindung ablehnen oder eine zweite Authentifizierungsform wie z. B. ein Token anfordern.
    • Clientzertifikat — Benutzer, die sich an einem virtuellen NetScaler Gateway-Server anmelden, können auch anhand der Attribute eines Clientzertifikats authentifiziert werden, das dem virtuellen Server vorgelegt wird. Client-Zertifikate werden in der Regel an Benutzer in Form von Smartcards oder Common Access Cards (CACs) verbreitet, die von einem Leser gelesen werden, der an das Gerät jedes Benutzers anhängt.

Der Authentifizierungstyp für eine Benutzergruppe wird häufig anhand von Sicherheitsanforderungen und dem verwendeten Authentifizierungspunkt bestimmt. In der folgenden Tabelle können Sie anhand der erforderlichen Sicherheitsstufe die geeignete Lösung für jede Benutzergruppe definieren:

Authentifizierungspunkt Sicherheitsanforderungen Authentifizierungstyp
StoreFront Niedrig, Mittel, Hoch Niedrig: LDAP-Benutzername und Passwor; Pass-Through. Medium: LDAP-Benutzername und Kennwort; Pass-Through. Hoch: LDAP und/oder Smartcard
NetScaler Gateway Niedrig, Mittel, Hoch Niedrig: LDAP-Benutzername und Passwort. Medium: LDAP-Benutzername und Kennwort. Hoch: LDAP und Token; LDAP und Smartcard; Token und Smartcard

Erfahrung aus dem Feld

  • Einzelhandel — Ein kleines Privathandelsunternehmen bietet virtuellen Desktop-Benutzern Zugriff auf nicht sensible Daten wie Marketingkataloge und E-Mail. Sie sind nicht verpflichtet, Sicherheitsvorschriften wie Sarbanes Oxley einzuhalten. Daher wurde die LDAP-Authentifizierung basierend auf Benutzername und Kennwort implementiert.
  • Finanziell — Ein mittelständisches Finanzunternehmen bietet seinen virtuellen Desktop-Benutzern Zugriff auf vertrauliche Daten wie Banktransaktionsdatensätze. Sie unterliegen Sicherheitsvorschriften wie dem Statement on Accounting Standards (SAS) 70 und müssen die Multi-Faktor-Authentifizierung für RAS-Benutzer nutzen. Die LDAP-Authentifizierung wurde basierend auf Benutzername und Kennwort sowie RADIUS-Authentifizierung mithilfe von Tokens implementiert.
  • Regierung — Eine große föderale Institution bietet virtuellen Desktop-Benutzern Zugriff auf hochvertrauliche Daten, wie z. B. persönliche Aufzeichnungen privater Bürger. Sie unterliegen der Regulierung durch die Sicherheitsstandards des Verteidigungsministeriums (DOD). Die LDAP-Authentifizierung wurde basierend auf Benutzername und Kennwort sowie Clientzertifikatauthentifizierung mithilfe von CAC-Karten implementiert.
  • Gesundheitswesen — Ein Krankenhaus nutzt XenApp, um ihre EMR-Anwendung an Benutzer bereitzustellen. ThinClient-Geräte auf stationären und mobilen Wagen werden von Ärzten und Krankenschwestern verwendet, um Patientendaten zu erfassen und abzurufen. Der nicht authentifizierte Zugriff wurde konfiguriert, um zu verhindern, dass sich medizinisches Personal bei der Domäne und der EMR-Anwendung authentifizieren muss.

StoreFront

Citrix StoreFront authentifiziert Benutzer bei XenApp- und XenDesktop-Ressourcen. StoreFront litiert und aggregiert verfügbare Desktops und Anwendungen in einer einzigen Schnittstelle, auf die Benutzer über Citrix Receiver für Windows, iOS, Android oder die StoreFront-Website zugreifen.

Entscheidung: High Availabiity

Wenn der Server, auf dem StoreFront gehostet wird, nicht verfügbar ist, können Benutzer keine neuen virtuellen Desktops, veröffentlichten Anwendungen starten oder ihre Abonnements verwalten. Daher sollten mindestens zwei StoreFront-Server bereitgestellt werden, um zu verhindern, dass diese Komponente zu einem einzigen Fehlerpunkt wird. Durch die Implementierung einer Load Balancing-Lösung wird der Dienst nicht unterbrochen. Folgende Optionen sind verfügbar:

  • Hardwarelastenausgleich — Eine intelligente Appliance, die in der Lage ist, die Verfügbarkeit des StoreFront-Dienstes zu überprüfen und den Lastausgleich von Benutzeranfragen entsprechend aktiv zu gestalten. Citrix NetScaler ist ein großartiges Beispiel für einen Hardware-Load Balancer. Citrix NetScaler ist ein idealer Load Balancer, der mit StoreFront-Integritätsprüfungen vorkonfiguriert wird.
  • DNS-Roundrobin — Bietet rudimentären Lastausgleich über mehrere Server hinweg, ohne dass die Verfügbarkeit überprüft wird. Wenn ein StoreFront-Server nicht verfügbar ist, leiten DNS-Roundrobin Benutzer weiterhin an den ausgefallenen Server weiter. Aus diesem Grund wird DNS-Roundrobin von Citrix nicht empfohlen.
  • Windows-Netzwerklastenausgleich — Ein Windows-Dienst, der rudimentäre Prüfungen durchführen kann, um zu überprüfen, ob der Server verfügbar ist, kann jedoch den Status einzelner Dienste nicht ermitteln. Dies kann dazu führen, dass Benutzer an StoreFront-Server weitergeleitet werden, die keine neuen Anforderungen verarbeiten können. Der Benutzer kann dann nicht auf Anwendungen oder Desktops zugreifen.

Entscheidung: Referenz des Delivery Controllers

Um Benutzern Desktops und Anwendungen zur Verfügung zu stellen, muss StoreFront mit der IP-Adresse oder dem DNS-Namen von mindestens einem Controller an jeder XenDesktop- und XenApp-Site konfiguriert werden. Zur Fehlertoleranz sollten für jeden angegebenen Standort und/oder jede angegebene Farm mehrere Controller eingegeben werden. Standardmäßig behandelt StoreFront eine Liste von Servern in der Failoverreihenfolge (aktiv/passiv).

Für große Bereitstellungen oder Umgebungen mit hoher Anmeldelast wird eine aktive Verteilung der Benutzerlast (aktiv/aktiv) empfohlen. Dies kann durch einen Load Balancer mit integrierten XML-Monitoren wie Citrix NetScaler erreicht werden, oder indem StoreFront so konfiguriert wird, dass die Liste der Controller geladen wird, anstatt sie als geordnete Liste zu behandeln.

Entscheidung: Beacons

Citrix Receiver verwendet Beacons (Websites), um festzustellen, ob ein Benutzer mit einem internen oder externen Netzwerk verbunden ist. Interne Benutzer werden zur Authentifizierung direkt mit StoreFront verbunden, während externe Benutzer über Citrix NetScaler Gateway verbunden sind. Es ist möglich, zu steuern, was ein Benutzer sieht, indem er Anwendungen einschränkt, aufgrund dessen, auf welche Beacon er Zugriff hat.

Das interne Beacon sollte eine Site sein, die extern nicht auflösbar ist. Standardmäßig ist das interne Beacon die StoreFront-Basis-URL. Dies muss angepasst werden, wenn die gleiche externe und interne URL konfiguriert ist. Das externe Beacon kann jede externe Site sein, die eine HTTP-Antwort erzeugt. Citrix Receiver überwacht kontinuierlich den Status von Netzwerkverbindungen (z. B. Verbindung bereit, Verbindung nicht bereit oder Ändern des Standardgateways). Wenn eine Statusänderung erkannt wird, überprüft Citrix Receiver zunächst, ob auf die internen Beacon-Punkte zugegriffen werden kann, bevor er fortfährt, um die Zugänglichkeit externer Beacon-Punkte zu überprüfen. StoreFront stellt Citrix Receiver die HTTP-Adressen der Beacon-Punkte während des ersten Download-Prozesses für die Verbindungs-/Konfiguration bereit und stellt bei Bedarf Updates bereit. Es ist notwendig, mindestens zwei hoch verfügbare externe Beacons anzugeben, die von öffentlichen Netzwerken aufgelöst werden können.

Entscheidung: Ressourcenpräsentation

Standardmäßig können Benutzer StoreFront die Ressourcen auswählen (abonnieren), die sie regelmäßig verwenden möchten, nachdem sie sich angemeldet haben (Favoriten). Dieser Ansatz, der als “Self-Service” bezeichnet wird, ermöglicht es Benutzern, die Ressourcen, die sie auf ihrem Startbildschirm sehen, auf diejenigen zu beschränken, die sie regelmäßig verwenden. Die von jedem Benutzer für jeden Store ausgewählten Ressourcen werden vom Abonnementspeicherdienst aufgezeichnet und lokal auf jedem StoreFront-Server gespeichert (automatisch zwischen Servern derselben Servergruppe synchronisiert), sodass sie auf dem Citrix Receiver-Home-Bildschirm von jedem Gerät angezeigt werden können, das der Benutzer über . Obwohl Abonnements standardmäßig pro Speicher und pro Servergruppe erfolgen, können Administratoren zwei Stores innerhalb einer Servergruppe so konfigurieren, dass sie eine Abonnementdatenbank gemeinsam nutzen und/oder Abonnements zwischen zwei identisch benannten Stores in zwei separaten Servergruppen nach einem festgelegten Zeitplan synchronisieren.

Administratoren sollten festlegen, welche Anwendungen Benutzern immer auf ihrem Startbildschirm oder auf der Registerkarte “Featured” angezeigt werden sollen. Im Allgemeinen sind diese Anwendungen gängige Anwendungen wie die Microsoft Office Suite und alle anderen Anwendungen, die jeder Benutzer in einer Umgebung benötigt. StoreFront kann diese Ressourcen mithilfe von Schlüsselwörtern filtern/präsentieren, die im Feld Beschreibung der veröffentlichten Anwendungseigenschaften definiert sind.

In der folgenden Tabelle werden die Keyword-Optionen untersucht:

Schlüsselwort Beschreibung
Automatisch Abonniert automatisch alle Benutzer eines Stores einer Anwendung. Wenn sich Benutzer beim Store anmelden, wird die Anwendung automatisch bereitgestellt, ohne dass Benutzer die Anwendung manuell abonnieren müssen. Benutzer können dieses Abonnement nachträglich entfernen, falls gewünscht.
Obligatorisch Neu in StoreFront 2.5, das Schlüsselwort Obligatorisch macht Anwendungen automatisch für Benutzer des Stores abonniert. Benutzer haben jedoch nicht die Möglichkeit, die Anwendung zu entfernen. Diese Einstellung ist nützlich, wenn Sie einen Kernsatz von Anwendungen erstellen, die immer allen Benutzern präsentiert werden müssen.
Hervorgehoben Anzeigen von Anwendungen für Benutzer oder erleichtern Sie die Auffindbarkeit häufig verwendeter Anwendungen, indem Sie sie in der Liste Empfohlene Receiver auflisten.
Bevorzugen Geben Sie an, dass eine lokal installierte Anwendung anstelle einer in Receiver verfügbaren Anwendung verwendet werden soll. Receiver sucht nach dem angegebenen Namen/Pfad, um festzustellen, ob die Anwendung lokal installiert ist. Wenn dies der Fall ist, abonniert Receiver die Anwendung und erstellt keine Verknüpfung. Wenn der Benutzer die Anwendung über das Receiver-Fenster startet, startet Receiver die lokal installierte (bevorzugte) Anwendung. Wenn ein Benutzer eine bevorzugte Anwendung außerhalb von Receiver deinstalliert, wird die Anwendung während der nächsten Receiver-Aktualisierung abgemeldet. Wenn ein Benutzer eine bevorzugte Anwendung aus dem Receiver-Fenster deinstalliert, nimmt Receiver das Abonnement der Anwendung ab, deinstalliert sie jedoch nicht.
TreatAsApp Standardmäßig werden XenDesktop VDI-Desktops und XenApp-gehostete freigegebene Desktops von Receiver für Websites wie andere Desktops behandelt. Mit dem Schlüsselwort “TreatAsApp” wird der Desktop in den Anwendungsansichten von Receiver für Web-Sites und nicht in den Desktopansichten angezeigt. Benutzer müssen sich anmelden, bevor sie auf den Desktop zugreifen können.
Primär Wenn Sie in einer Bereitstellung mit mehreren Standorten arbeiten, stellt die Verwendung dieses Schlüsselworts sicher, dass eine Anwendung von einer bestimmten Site bereitgestellt wird. Wenn eine Anwendung von mehreren Standorten mit demselben Namen verfügbar ist, wird die Anwendung vom sekundären Standort nur angezeigt, wenn die Anwendung nicht über den primären Standort verfügbar ist.
Sekundär Eine gleiche Eigenschaft wie das Schlüsselwort “Primary”, mit der Ausnahme, dass es eine Anwendung am sekundären Standort bestimmt.

Entscheidung: Aggregationsgruppen

Wenn die XenApp/XenDesktop -Lösung mehrere Bereitstellungssites enthält, führt StoreFront die verfügbaren Ressourcen zusammen, sodass der Benutzer über eine einzige Schnittstelle für alle veröffentlichten Ressourcen verfügt. Wenn jedoch mehrere Standorte die gleichen Ressourcen veröffentlichen, kann der Benutzer Verwirrung auftreten, da eine einzelne Anwendung mehrmals angezeigt wird.

Benutzererfahrung ohne Aggregationsbild

StoreFront-Aggregationsgruppen definieren, wie die Ressourcen an mehreren Standorten zusammengeführt werden, um dem Benutzer eine einzige, leicht verständliche Ansicht zu bieten. StoreFront aggregiert doppelte veröffentlichte Ressourcen in einem einzigen Symbol.

Benutzererfahrung mit Aggregationsbild

Der Administrator muss festlegen, wie Benutzer auf den verschiedenen XenApp/XenDesktop -Sites ausgleichen, wenn das Symbol eine Aggregation ist. Folgende Optionen stehen zur Verfügung:

  • Load Balancing — Wird verwendet, wenn die doppelten Sites basierend auf Kapazitätsempfehlungen erstellt werden. StoreFront verteilt Benutzeranforderungen auf alle konfigurierten Sites.
  • Failover — Wird verwendet, wenn Geografien im Falle eines Ausfalls über Ressourcen verfügen müssen oder wenn Benutzer von einem Standort zu einem anderen Standort migriert werden (z. B. ein XenApp-Migrationsprojekt).

Es ist ratsam, die Benutzer, Stores und Aggregationsmethoden während der Entwurfsphase zu dokumentieren.

Benutzergruppe Verfügbare Shops Lastenausgleichsspeicher Failover-Speicher
NA_FinanceUsers NA_West_Store, NA_East_Store, EMEA_Store NA_West_Store, NA_East_Store EMEA_Store
EMEA_SalesUsers EMEA_Store, NA_East_Store EMEA_Store NA_East_Store

Entscheidung: Skalierbarkeit

Die Anzahl der Citrix Receiver-Benutzer, die von einem einzelnen StoreFront-Server unterstützt werden, hängt von den zugewiesenen Ressourcen und der Höhe der Benutzeraktivität ab. Beachten Sie, dass Receiver für Webbenutzer durchschnittlich mehr RAM verbrauchen als native Receiver-Benutzer. Pro StoreFront-Server wird jedoch in allen Fällen mindestens 4 GB RAM empfohlen. Darüber hinaus erhöhen mehr Sites/Farmen, die pro Speicher aufgelistet werden, sowohl die CPU-Auslastung als auch die Reaktionszeit des Servers. XenApp IMA-Farmen haben eine größere Skalierbarkeit als XenApp/XenDesktop FMA-Site.

StoreFront-Bereitstellung CPU-Auslastung Simultane Aktivitäten
Standalone-Bereitstellung: 4 CPUs, 4 GB RAM, hohe Auslastung (Anmeldung, Auflisten, Abonnieren, Abmelden, Abmelden) 75% 291 pro Sekunde
Standalone-Bereitstellung: 4 CPUs, 4 GB RAM, hohe Auslastung (Anmeldung, Auflisten, Abonnieren, Abmelden, Abmelden) 90% 375 pro Sekunde
Cluster StoreFront-Bereitstellung. 2 Knoten mit je: 4 CPUs, 4 GB RAM, hohe Auslastung (Anmeldung, Auflisten, Abonnieren, Abmelden, Abmelden) 75% 529 pro Sekunde
Cluster StoreFront-Bereitstellung. 2 Knoten mit je: 4 CPUs, 4 GB RAM, hohe Auslastung (Anmeldung, Auflisten, Abonnieren, Abmelden, Abmelden) 90% 681 pro Sekunde

Tests haben gezeigt, dass die Renditen verringert werden, nachdem eine einzelne StoreFront-Bereitstellung über 3-4 StoreFront-Knoten hinausgeht, wobei maximal 5-6 Server in einer einzelnen Servergruppe unterstützt werden.

NetScaler Gateway

Benutzergruppen, die NetScaler Gateway als Authentifizierungspunkt verwenden, müssen zusätzliche Entwurfsentscheidungen berücksichtigt werden. Diese Entwurfsentscheidungen gelten nicht für Nicht-NetScaler Gateway-Authentifizierungspunkte.

Entscheidung: Topologie

Die Auswahl der Netzwerktopologie ist für die Planung der RAS-Architektur von zentraler Bedeutung, um sicherzustellen, dass sie die erforderliche Funktionalität, Leistung und Sicherheit unterstützt. Das Design der RAS-Architektur sollte in Zusammenarbeit mit dem Sicherheitsteam abgeschlossen werden, um die Einhaltung der Sicherheitsanforderungen des Unternehmens sicherzustellen. Es gibt zwei primäre Topologien zu berücksichtigen, von denen jede eine Erhöhung der Sicherheit bietet:

  • 1-Arm (normale Sicherheit) — Bei einer 1-Arm-Topologie nutzt NetScaler Gateway eine physische oder logische gebundene Schnittstelle mit zugeordnetem VLAN- und IP-Subnetz, um sowohl Frontend-Datenverkehr für Benutzer als auch Back-End-Datenverkehr für die Server und Dienste der virtuellen Desktop-Infrastruktur zu transportieren.

Arm-Topologiebild

  • 2-Arm (hohe Sicherheit) — Bei einer 2-Arm-Topologie nutzt NetScaler Gateway zwei oder mehr physisch oder logisch gebundene Schnittstellen mit zugehörigen VLAN- und IP-Subnetzen. Der Transport des Frontend-Datenverkehrs für Benutzer wird zu einer dieser Schnittstellen geleitet. Der Frontend-Datenverkehr wird vom Back-End-Datenverkehr zwischen den Servern und Diensten der virtuellen Desktop-Infrastruktur isoliert, die an eine zweite Schnittstelle weitergeleitet wird. Dies ermöglicht die Verwendung separater demilitarisierter Zonen (DMZs) zur Isolierung von Frontend- und Backend-Datenverkehrsflüssen sowie granularer Firewall-Steuerung und -Überwachung.

Arm-Topologiebild

Entscheidung: High Availabiity

Wenn NetScaler Gateway nicht verfügbar ist, können Remotebenutzer nicht auf die Umgebung zugreifen. Daher sollten mindestens zwei NetScaler Gateway-Hosts bereitgestellt werden, um zu verhindern, dass diese Komponente zu einem einzigen Fehlerpunkt wird.

Bei der Konfiguration von NetScaler Gateway in einem Hochverfügbarkeitspaar (aktiv/passiv) überwacht das sekundäre NetScaler Gateway die erste Appliance, indem es periodische Meldungen sendet, die auch als Heartbeat-Nachricht oder Integritätsprüfung bezeichnet werden, um festzustellen, ob die erste Appliance Verbindungen akzeptiert. Wenn eine Integritätsprüfung fehlschlägt, versucht das sekundäre NetScaler Gateway die Verbindung für eine bestimmte Zeit erneut, bis festgestellt wird, dass die primäre Appliance nicht funktioniert. Wenn die sekundäre Appliance den Fehler der Integritätsprüfung bestätigt, übernimmt das sekundäre NetScaler Gateway das primäre NetScaler Gateway.

Beachten Sie, dass in Firmware 10.5 und höher auch Clustering mit mehreren NetScaler Gateway-Instanzen möglich ist, um eine hohe Verfügbarkeit bereitzustellen, obwohl die Unterstützung für gepunktete und gestrippte Konfigurationen je nach Firmware und Gateway-Konfiguration variiert (vollständiges SSL-VPN im Vergleich zu ICA-Proxy https://docs.citrix.com/en-us/netscaler/11-1/clustering/cluster-features-supported.html)

Entscheidung: Plattform

Um eine geeignete NetScaler-Plattform zu identifizieren, die Projektanforderungen erfüllt, müssen die wichtigsten Ressourceneinschränkungen identifiziert werden. Da der gesamte RAS-Datenverkehr mit dem Secure Sockets Layer (SSL) gesichert wird, der von HTTP (Hypertext Transfer Protocol) in Form von HTTPs transportiert wird, gibt es zwei Ressourcenmetriken, die als Ziel dienen sollten:

  • SSL-Durchsatz — Der SSL-Durchsatz ist die Gigabits des SSL-Datenverkehrs, die pro Sekunde (Gbit/s) verarbeitet werden können.
  • SSL-Transaktionen pro Sekunde (TPS) — Die TPS-Metrik gibt an, wie oft pro Sekunde ein Application Delivery Controller (ADC) eine SSL-Transaktion ausführen kann. Die Kapazität variiert in erster Linie durch die erforderliche Schlüssellänge. Die TPS-Kapazität ist in erster Linie eine Überlegung während der Verhandlungsphase, wenn SSL zum ersten Mal eingerichtet wird, und es ist weniger ein Faktor in der Bulk-Verschlüsselung/Entschlüsselung Phase, die den größten Teil der Sitzungsdauer darstellt. Während TPS eine wichtige Messgröße ist, die überwacht werden muss, hat die Erfahrung vor Ort gezeigt, dass der SSL-Durchsatz der wichtigste Faktor bei der Identifizierung des geeigneten NetScaler Gateways ist.

Der durchschnittliche SSL-Bandbreiten-Overhead-Durchschnitt wird im Verhältnis zum Volumen des virtuellen Desktop-Datenverkehrs oft als vernachlässigbar angesehen und wird normalerweise nicht als Teil des erforderlichen SSL-Durchsatzes berücksichtigt. Durch die Bereitstellung von SSL-Bandbreiten wird jedoch sichergestellt, dass der geschätzte Gesamtdurchsatz ausreichend ist. Die feste Bandbreite, die Paketheadern hinzugefügt wird, kann je nach verwendeten Verschlüsselungsalgorithmen variieren, und der Gesamtprozentsatz der Bandbreite kann je nach Paketgröße stark variieren. Idealerweise sollte der Overhead während eines Proof of Concept oder Piloten gemessen werden. In Ermangelung solcher Daten ist eine Erhöhung der Arbeitslastenbandbreite um 2% jedoch eine vernünftige Faustregel. Um den von einer NetScaler-Plattform benötigten SSL-Durchsatz zu ermitteln, multiplizieren Sie daher die maximale gleichzeitige Bandbreite für ein Rechenzentrum mit 1,02:

SSL-Durchsatz = Maximale gleichzeitige Bandbreite x 1,02

Angenommen, 128 Mbps maximale gleichzeitige Bandbreite, kann das geeignete NetScaler-Modell wie folgt ermittelt werden:

~ 130 Mbit/s = 128 Mbit/s x 1,02

Der SSL-Durchsatzwert sollte mit den Durchsatzfunktionen verschiedener NetScaler-Plattformen verglichen werden, um den für die Umgebung am besten geeigneten Wert zu ermitteln. Es stehen drei Hauptplattformgruppen zur Verfügung, von denen jede eine breite Skalierbarkeit bietet.

  • VPX — Ein NetScaler VPX-Gerät bietet die gleiche volle Funktionalität wie NetScaler Hardware. NetScaler VPXs können jedoch “Off the Shelf” Server für Hosting nutzen und sind für kleine bis mittelgroße Umgebungen geeignet. In der Regel erstellen Organisationen eine Baseline-Cap für die VPX-Instances bei 500 Benutzern.
  • MPX — Ein NetScaler MPX ist die Hardwareversion der NetScaler-Geräte. Das MPX-Gerät ist leistungsfähiger als der virtuelle NetScaler und kann Netzwerkoptimierungen für Großunternehmen unterstützen, insbesondere wenn SSL-Offload konfiguriert wird, da dies in Software auf dem VPX im Vergleich zu dedizierten SSL-Chips auf der MPX erfolgt.
  • SDX — Ein NetScaler SDX ist eine Mischung zwischen virtuellen und physischen NetScaler-Geräten. Eine SDX-Maschine ist ein physisches Gerät, das mehrere virtuelle NetScaler-Geräte hosten kann. Diese Konsolidierung von Geräten trägt zur Reduzierung des benötigten Lagerplatzes und der Gerätekonsolidierung bei. NetScaler SDXs eignen sich für die Verwaltung der Netzwerkkommunikation für Großunternehmen und/oder Hosting-Provider mit mehreren Mandanten.

SSL-Durchsatzfunktionen der NetScaler-Plattformen finden Sie imCitrix NetScaler — Datenblatt. Daher würde eine NetScaler MPX 5550 Appliance auf der Grundlage der obigen Beispielberechnung ausreichen, um die erforderliche Last zu bewältigen. Tatsächlich hängt die Skalierbarkeit jedoch von den Sicherheitsanforderungen ab. NetScaler SSL-Durchsatz sinkt durch den Einsatz immer komplexer werdender Verschlüsselungsalgorithmen und längerer Schlüssellängen. Außerdem stellt diese Berechnung einen einzelnen primären NetScaler dar. Zumindest wird N + 1-Redundanz empfohlen, die einen zusätzlichen NetScaler der identischen Plattform und des gleichen Modells erfordern würde.

Hinweis:

Das Citrix NetScaler-Datenblatt stellt in der Regel Durchsatzfunktionen unter optimalen Leistungsbedingungen dar. Die Leistung wird jedoch direkt von den Sicherheitsanforderungen beeinflusst. Wenn beispielsweise der RC4-Verschlüsselungsalgorithmus und eine Schlüssellänge von 1 k verwendet werden, kann eine VPX-Plattform möglicherweise mehr als 500 HDX-Proxy-Verbindungen verarbeiten. Wenn jedoch ein 3DES-Verschlüsselungsalgorithmus und eine Schlüssellänge von 2k verwendet werden (die immer häufiger werden), kann der Durchsatz halbiert werden.

Entscheidung: Vorauthentifizierungsrichtlinie

Eine optionale Vorauthentifizierungsrichtlinie kann auf Benutzergruppen angewendet werden, die NetScaler Gateway als Authentifizierungspunkt verwenden. Vorauthentifizierungsrichtlinien beschränken den Zugriff auf die Umgebung, je nachdem, ob der Endpunkt bestimmte Kriterien durch Endpoint Analysis (EPA) Scans erfüllt.

Vorauthentifizierungszugriffsrichtlinien können so konfiguriert werden, dass Antivirus-, Firewall-, Betriebssystem- oder sogar Registrierungseinstellungen getestet werden. Diese Richtlinien können verwendet werden, um den Zugriff vollständig zu verhindern oder von XenDesktop verwendet werden, um Sitzungsfunktionen wie die Zuordnung der Zwischenablage, die Druckerzuordnung und sogar die Verfügbarkeit bestimmter Anwendungen und Desktops zu steuern. Wenn beispielsweise auf einem Benutzergerät kein Antivirenprogramm installiert ist, kann ein Filter so eingestellt werden, dass sensible Anwendungen ausgeblendet werden.

Die folgende Abbildung bietet einen Überblick darüber, wie mehrere Richtlinien verwendet werden können, um die Funktionen einer Virtualisierungsressource anzupassen:

Logikbild für intelligentes Zugriffs-Entscheidungslogik

Erfahrung aus dem Feld

  • Einzelhandel — Ein kleines Privathandelsunternehmen verwendet EPA, um nach aktualisierten Virenschutzdefinitionen zu suchen, bevor der Zugriff gewährt wird.
  • Finanziell — Ein mittelständisches Finanzunternehmen verwendet EPA-Scans der Domänen-SID, um zu überprüfen, ob Benutzer Mitglieder der Unternehmensdomäne sind, bevor der Zugriff gewährt wird.
  • Regierung — Eine große Bundesanstalt verwendet EPA, um Endpunktgeräte zu scannen, um sicherzustellen, dass ein bestimmtes Zertifikat (oder eine Reihe von Zertifikaten) auf dem Gerät installiert wurde, bevor der Zugriff gewährt wird.

Entscheidung: Sitzungsrichtlinie

Benutzergruppen mit NetScaler Gateway als Authentifizierungspunkt müssen entsprechende Sitzungsrichtlinien definiert sein. Sitzungsrichtlinien werden verwendet, um die allgemeine Benutzererfahrung nach der Authentifizierung zu definieren.

Organisationen erstellen Sitzungsrichtlinien basierend auf dem verwendeten Citrix Receiver-Typ. Für die Zwecke der Zuweisung von Sitzungsrichtlinien werden Geräte üblicherweise als nicht mobile Geräte (wie Windows, Mac und Linux OS basiert) oder als mobile Geräte (wie iOS oder Android) gruppiert. Daher sollte eine Entscheidung darüber getroffen werden, ob mobile Geräte, nicht mobile Geräte oder beides unterstützt werden sollen, basierend auf Clientgeräteanforderungen, die während der Bewertungsphase ermittelt wurden.

Um die Sitzungsrichtlinien für Geräte zu identifizieren, schließen Sie Ausdrücke ein, die unter beschrieben werdenDieser Artikel.

  • Mobile Geräte — Der Ausdruck ist auf REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver festgelegt, der eine höhere Priorität hat als die Richtlinie für nicht-mobile Geräte, um sicherzustellen, dass mobile Geräte abgeglichen werden, während nicht mobile Geräte nicht.
  • Nicht-mobile Geräte — Der Ausdruck ist auf ns_true gesetzt, was bedeutet, dass er für den gesamten Datenverkehr gelten soll, der an ihn gesendet wird.

Eine alternative Verwendung von Sitzungsrichtlinien besteht darin, Ausdrücke für die Endpunktanalyse anzuwenden. Diese Sitzungsrichtlinien werden nach der Authentifizierung angewendet, aber imitieren die zuvor erwähntenRichtlinien zur Vorauthentifizierung. Die Verwendung von Sitzungsrichtlinien ist eine Option, um Endpoints ein Fallback-Szenario bereitzustellen, die die vollständigen Sicherheitsanforderungen wie schreibgeschützten Zugriff auf bestimmte Anwendungen nicht erfüllen.

Entscheidung: Sitzungsprofil

Für jede Sitzungsrichtlinie muss ein entsprechendes Sitzungsprofil definiert sein. Das Sitzungsprofil definiert Details, die für die Benutzergruppe erforderlich sind, um Zugriff auf die Umgebung zu erhalten. Es gibt zwei primäre Formen von Sitzungsprofilen, die die Zugriffsmethode für die virtuelle Desktopumgebung bestimmen:

  • SSLVPN — Benutzer erstellen ein virtuelles privates Netzwerk und tunneln den gesamten durch IP-Adressen konfigurierten Datenverkehr über das interne Netzwerk. Das Clientgerät des Benutzers kann auf erlaubte Intranetressourcen zugreifen, als wäre es im internen Netzwerk. Dazu gehören XenDesktop-Sites und alle anderen internen Datenverkehr, wie Dateifreigaben oder Intranetwebsites. Dies gilt als potenziell weniger sichere Zugriffsmethode, da Netzwerkports und -routen zu Diensten außerhalb der virtuellen Desktop-Infrastruktur geöffnet werden können, sodass das Unternehmen für Risiken anfällig ist, die mit vollem VPN-Zugriff einhergehen können. Zu diesen Risiken gehören Denial-of-Service-Angriffe, Versuche, interne Server zu hacken, oder jede andere Form von bösartigen Aktivitäten, die von Malware, Trojanern oder anderen Viren über einen Internet-basierten Client gegen anfällige Unternehmensdienste über Routen und Ports gestartet werden können.

Eine weitere Entscheidung, bei der SSLVPN erforderlich ist, ist, ob Split-Tunneling für den Client-Netzwerkverkehr aktiviert werden soll. Durch Aktivieren von Split-Tunneling kann der von Citrix Receiver an das Intranet geleitete Client-Netzwerkverkehr auf Routen und Ports beschränkt werden, die bestimmten Diensten zugeordnet sind. Durch Deaktivieren des Split-Tunnels wird der gesamte Client-Netzwerkverkehr zum Intranet geleitet, daher durchläuft sowohl der für interne Dienste als auch der für externe Dienste bestimmte Datenverkehr (Internet) das Unternehmensnetzwerk. Der Vorteil des Split-Tunnelings besteht darin, dass die Belichtung des Unternehmensnetzwerks begrenzt ist und die Netzwerkbandbreite erhalten bleibt. Der Vorteil der Deaktivierung von Split-Tunneling besteht darin, dass der Client-Datenverkehr über Systeme wie Webfilter oder Intrusionserkennungssysteme überwacht oder gesteuert werden kann.

SSL-VPN-Abbild

  • HDX-Proxy — Mit HDX Proxy stellen Benutzer eine Verbindung zu ihren virtuellen Desktops und Anwendungen über das NetScaler Gateway her, ohne interne Adressen extern verfügbar zu machen. In dieser Konfiguration fungiert NetScaler Gateway als Micro-VPN und verarbeitet nur HDX-Datenverkehr. Andere Arten von Datenverkehr auf dem Endgerät des Clients, wie z. B. private E-Mails oder persönlicher Internetverkehr, verwenden NetScaler Gateway nicht.

Basierend auf dem verwendeten Endpunkt und Citrix Receiver muss entschieden werden, ob diese Methode für jede Benutzergruppe unterstützt wird. HDX Proxy gilt als sichere Zugriffsmethode für den Remote-Zugriff auf virtuelle Desktops, da nur der für die Desktopsitzung spezifische Datenverkehr an die Unternehmensinfrastruktur weitergeleitet werden darf. Die meisten Citrix Receiver unterstützen HDX Proxy und es ist die bevorzugte Methode:

HDX-Proxy-Image

Entscheidung: Bevorzugtes Rechenzentrum

Unternehmen verfügen oft über mehrere aktive Rechenzentren, die hohe Verfügbarkeit für geschäftskritische Anwendungen bieten. Einige virtuelle Desktops oder Anwendungen fallen möglicherweise in diese Kategorie, während andere nur von einem bestimmten bevorzugten Rechenzentrum aus zugegriffen werden können. Daher befindet sich das anfängliche NetScaler Gateway, bei dem sich ein Benutzer in einer Umgebung mit mehreren aktiven Rechenzentren authentifiziert, möglicherweise nicht innerhalb des bevorzugten Datencenters, das den VDI-Ressourcen des Benutzers entspricht. StoreFront kann den Speicherort der zugewiesenen Ressourcen des Benutzers ermitteln und die HDX-Sitzung an diese Ressourcen weiterleiten. Der resultierende Pfad kann jedoch suboptional sein (WAN-Verbindung vom NetScaler Gateway zu den virtuellen Desktop-/Anwendungsressourcen im Gegensatz zur LAN-Verbindung).

Es stehen statische und dynamische Methoden zur Verfügung, um HDX-Sitzungen an ihre virtuellen Desktop-Ressourcen im primären Rechenzentrum zu leiten. Die Entscheidung darüber, welche Methode ausgewählt werden soll, sollte auf der Verfügbarkeit von Technologien zur dynamischen Zuweisung von Sites wie Global Server Load Balancing (GSLB) basieren, sowie auf der Netzwerkbewertung von Intranet- und Internetbandbreite sowie QoS-Funktionen (Quality of Service).

Hinweis:

Weitere Informationen zum Konfigurieren der statischen und dynamischen Methoden von GSLB finden Sie in der Citrix Product Documentation -GSLB für Proximity konfigurieren.

Statisch

  • Direkt — Dem Benutzer kann ein FQDN zugewiesen werden, der einem A-Datensatz zugeordnet ist, der für das primäre Rechenzentrum NetScaler Gateway (s) reserviert ist, sodass er direkt auf seinen virtuellen Desktop zugreifen kann, egal wo er sich auf der Welt befindet. Dieser Ansatz eliminiert eine durch dynamische Zuweisung hinzugefügte Komplexitätsebene. Es werden jedoch auch Fehlertoleranzoptionen eliminiert, z. B. die Möglichkeit, über einen alternativen Intranetpfad auf den virtuellen Desktop zuzugreifen, wenn ein Ausfall des primären Rechenzentrums auf die Zugriffsinfrastruktur beschränkt ist.

Dynamisch

  • Intranet — In den meisten dynamischen Umgebungen ist das erste Datencenter, das für die Authentifizierung ausgewählt wurde, das dem Benutzer am nächsten ist. Protokolle wie die dynamische GSLB-Näherung berechnen die geringste Latenz zwischen dem lokalen DNS-Server des Benutzers und dem NetScaler Gateway. Danach wird die HDX-Sitzung standardmäßig über dasselbe NetScaler Gateway an das Rechenzentrum weitergeleitet, das die virtuellen Desktops und Anwendungen des Benutzers hostet. Der Vorteil dieses Ansatzes besteht darin, dass der Großteil der HDX-Sitzung das Unternehmenswan durchlaufen würde, in dem die Servicequalität genutzt werden kann.

Intranetverbindungsbild

  • Internet - Alternativ kann die HDX-Sitzung über ein alternatives NetScaler Gateway umgeleitet werden, das sich nahe dem Backend-VDI-Desktop-/XenApp-Server befindet, sodass die meisten HDX-Sitzungen über das Internet übertragen werden. Beispielsweise kann ein Benutzer mit einem dedizierten Desktop in den Vereinigten Staaten, Reisen in Europa kann zu einem NetScaler Gateway geleitet werden, das in einem europäischen Rechenzentrum gehostet wird, basierend auf der Nähe. Wenn der Benutzer jedoch seinen Desktop startet, wird eine HDX-Verbindung mit dem virtuellen Desktop über ein NetScaler Gateway hergestellt, das im bevorzugten Rechenzentrum in den USA gehostet wird.

Dies schont die Nutzung des WAN-Netzwerks (auf Kosten von QoS) und wird empfohlen, wenn die Internetverbindung des Benutzers eine zuverlässigere Erfahrung bietet als das Unternehmens-WAN.

Internetverbindungsbild

Einige Kunden werden eine Kombination dieser Methoden verwenden, z. B. geospezifische dynamische URLs, so dass Fehlertoleranz innerhalb eines geografischen Gebiets (wie Nordamerika) bereitgestellt wird, ohne dass die Komplexität des globalen GSLB entsteht.

Standort-zu-Standort-Konnektivität

Eine XenApp- und XenDesktop-Site kann mehrere Standorte umfassen. Um eine Lösung für mehrere Standorte erfolgreich zu implementieren, muss der Entwurf die Site-zu-Site-Links und das XenApp- und XenDesktop-Sitzungsrouting zwischen Standorten berücksichtigen, um eine optimale Benutzererfahrung zu bieten.

Entscheidung: HDX-optimiertes Routing

In einer XenApp- und XenDesktop-Lösung mit mehreren Standorten werden Benutzer mit bestimmten Kriterien wie der schnellsten Reaktionszeit oder der nächsten Nähe zur optimalen Site weitergeführt. Diese Algorithmen berücksichtigen nicht die Ressourcen, auf die ein Benutzer zugreifen möchte.

Unsachgemäße Weiterleitung der Sitzung eines Benutzers führt zu folgenden Ergebnissen:

HDX-Routing-Image

  1. Benutzer, basierend auf der Nähe oder Reaktionszeit an die am meisten bevorzugte Site weitergeleitet
  2. NetScaler Gateway gibt den ICA-Datenverkehr an die richtige Ressource weiter, die über das Unternehmenswan verteilt sein kann.

Idealerweise sollte optimiertes Routing folgendermaßen aussehen:

Routing Image optimieren

  1. Benutzer, basierend auf der Nähe oder Reaktionszeit an die am meisten bevorzugte Site weitergeleitet
  2. Basierend auf der ausgewählten Ressource leitet NetScaler Gateway die Sitzung an ein NetScaler Gateway in der bevorzugten Site um.
  3. NetScaler Gateway gibt den ICA-Datenverkehr an die richtige Ressource weiter, die im lokalen LAN verbleibt.

Die Verwendung der optimierten HDX-Routing-Option in StoreFront entlastet den Datenverkehr aus dem Unternehmens-WAN und platziert ihn im öffentlichen Netzwerk

Entscheidung: Virtual WAN

In Zweigstellen-Szenarien muss ein XenApp- und XenDesktop-Design die Verbindung der Zweigstelle mit den Rechenzentren bewerten, die die Anwendungs- und Desktopressourcen hostet. Wenn die WAN-Verbindung zwischen Zweigstelle und Rechenzentrum nicht in der Lage ist, die Benutzeranforderungen zu erfüllen, verschlechtert sich die allgemeine Benutzererfahrung. Organisationen haben mehrere Optionen für ihre WAN-Verbindungen:

  • Skalieren — Organisationen können einfach die Größe der WAN-Pipe erhöhen, die die Zweigstellen mit dem Rechenzentrum verbindet, normalerweise zu erheblichen Kosten.
  • S@@cale-Out — Organisationen können ihre aktuelle WAN-Verbindung aufrechterhalten und durch mehrere kostengünstige Alternativen ergänzen. Durch die Integration aller Verbindungen zwischen Zweigstelle und Rechenzentrum entsteht ein softwaredefiniertes virtuelles WAN wie NetScaler SDWAN. Die Appliance sendet doppelte Netzwerkpakete über alle im virtuellen WAN definierten WAN-Verbindungen. Die Appliance am anderen Ende des WAN verwendet das erste ankommende Paket, wobei alle nachfolgenden Pakete verworfen werden. Da sich die Bedingungen der Mehrfachverbindungen im Laufe des Tages ändern, garantiert dieser Ansatz das bestmögliche Erlebnis.

Abbildung: NetScalerSDWAN

Haftungsausschluss

The official version of this content is in English. Some of the Citrix documentation content is machine translated for your convenience only. Citrix has no control over machine-translated content, which may contain errors, inaccuracies or unsuitable language. No warranty of any kind, either expressed or implied, is made as to the accuracy, reliability, suitability, or correctness of any translations made from the English original into any other language, or that your Citrix product or service conforms to any machine translated content, and any warranty provided under the applicable end user license agreement or terms of service, or any other agreement with Citrix, that the product or service conforms with any documentation shall not apply to the extent that such documentation has been machine translated. Citrix will not be held responsible for any damage or issues that may arise from using machine-translated content.

Entwurfsmethodik-Zugriffsebene