View a markdown version of this page

Anpassung der Flotte - Bewährte Methoden für die Bereitstellung von WorkSpaces Amazon-Anwendungen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Anpassung der Flotte

Flottentyp

Bei der Erstellung einer Flotte müssen Kunden einen Flottentyp wählen. Jeder Flottentyp bietet unterschiedliche Vorteile in Bezug auf Benutzererfahrung, Kosten und Wartungsaufwand. Unabhängig vom gewählten Flottentyp unterstützt jede Option sowohl die Windows- als auch die Linux-Plattformtypen sowie Desktop View oder Application View.

Kunden können jetzt aus den folgenden Flottenarten wählen:

  • Always-On— Dieser Flottentyp bietet Benutzern sofortigen Zugriff auf ihre Apps. Ihnen werden alle laufenden Instances in Ihrer Flotte in Rechnung gestellt, auch wenn keine Benutzer Apps streamen.

  • On-Demand— Wählen Sie diesen Flottentyp aus, um Ihre Streaming-Kosten zu optimieren. Bei einer On-Demand-Flotte haben Benutzer eine Startzeit von etwa ein bis zwei Minuten für ihre Sitzung. Die Gebühren für Streaming-Instances werden Ihnen jedoch nur berechnet, wenn Benutzer verbunden sind, und eine geringe Stundengebühr für jede Instanz in der Flotte, bei der es sich nicht um Streaming-Apps handelt.

  • Elastisch — Elastic Fleets können für Anwendungen verwendet werden, die keine Installation erfordern und von einer virtuellen Festplatte (VHD) ausgeführt werden können. Elastic Fleets unterstützen keine WorkSpaces Anwendungs-Images und erfordern auch keine Skalierungsrichtlinien. Ihnen wird nur die Dauer einer Streaming-Sitzung in Rechnung gestellt.

Tabelle 2 — Flottenarten von Amazon WorkSpaces Applications

Flottentyp Wann sollte dies verwendet werden? Benutzererfahrung Preismodell Hinweise

Always-On

Ihre Benutzer benötigen sofortigen Zugriff auf Anwendungen, wenn sie eine Sitzung starten. Sie werden keine nennenswerten Kapazitätsüberschüsse in Ihrer Flotte haben, vielleicht weil Ihre Nutzungsmuster vorhersehbar sind und Sie die Kosten mit Skalierungsrichtlinien zuverlässig kontrollieren können.

Sofortiger Zugriff auf Anwendungen

Sie zahlen den vollen Preis für jede Instanz, die in Ihrer Flotte verfügbar ist (unabhängig davon, ob sie für eine Sitzung verwendet wird).

Unterstützt benutzerdefinierte Image- und Skalierungsrichtlinien.

On-Demand

Sie müssen erhebliche Überkapazitäten in Ihren Flotten aufrechterhalten. Sie möchten eine möglichst kostenoptimierte Umgebung und möchten nicht den vollen Preis für ungenutzte Kapazität zahlen. Ihre Benutzer können nach dem Starten einer Sitzung ein bis zwei Minuten warten, bis sie auf ihre Anwendungen zugreifen.Sie verwenden größere Instance-Typen. Die stündlichen Kosten für eine laufende Instance sind viel teurer als die Gebühr für die angehaltene Instanz.

Benutzer warten nach dem Start einer Sitzung ein bis zwei Minuten, bis sie auf ihre Anwendungen zugreifen können.

Sie zahlen den vollen Preis nur für Streaming-Instances mit einer aktiven Sitzung und dann eine geringe Stundengebühr für inaktive Instances.

Unterstützt benutzerdefinierte Image- und Skalierungsrichtlinien.

Elastic

Ihre Anwendung und ihre Abhängigkeiten sind kleiner als ~1,5 GB. Jedes Mal, wenn ein Benutzer eine Sitzung in einer Elastic Fleet startet, muss Ihre virtuelle Festplattendatei (VHD) von Amazon S3 in die Sitzung heruntergeladen werden. Größere VHD-Dateien (d. h. Dateien mit einer Größe von mehr als 1,5 GB) führen daher zu einer schlechten Benutzererfahrung. Ihre Anwendung ist portabel. Das heißt, Ihre Anwendung und all ihre Abhängigkeiten können auf einer virtuellen Festplatte platziert und von den Streaming-Instances aus gestartet werden, für die VHD.You keine Domänenverbindung erforderlich ist (Domänenbeitritt ist derzeit bei Elastic-Flotten nicht verfügbar). Sie möchten nur für aktive Sitzungen zahlen (d. h. Sie zahlen nicht für ungenutzte Kapazität in Ihrer Flotte). Ihre Benutzer können nach dem Start einer Sitzung 45 Sekunden oder länger warten, bis sie auf ihre Anwendungen zugreifen. Sie möchten, dass AWS die Skalierung für Sie verwaltet (keine Skalierungsrichtlinien zur Verwaltung).

Der Benutzer wartet nach dem Start der Sitzung 45 Sekunden bis 3 Minuten, um auf Anwendungen zuzugreifen (die Wartezeit hängt von der Größe der virtuellen Festplatte ab).

Ihnen wird nur die Dauer einer Streaming-Sitzung in Rechnung gestellt. Da es bei Elastic-Flotten kein Konzept für inaktive Instances gibt, fallen für ungenutzte Instances keine Gebühren an.

Unterstützt keine benutzerdefinierten Images (der Kunde stellt VHD mit Anwendungen zur Verfügung) oder Skalierungsrichtlinien. Unterstützt derzeit alle stream.standard.small stream.standard.medium Instanzen. Wenn Ihr Anwendungsfall einen anderen Instanztyp erfordert, wenden Sie sich bitte an Ihr AWS Account-Team.

Ein Diagramm, das die Anwendungsfälle und Anforderungen des Flottentyps zeigt.

Anwendungsfälle und Anforderungen für Flotten

Dimensionierung der Flotte

Mindestkapazität und geplante Skalierung

Bei der Dimensionierung Ihrer WorkSpaces Anwendungsflotte gibt es mehrere Überlegungen, die sich direkt auf die Benutzererfahrung und die Kosten auswirken. Der für Mindestkapazität eingegebene Wert stellt sicher, dass die Anzahl der WorkSpaces Anwendungsinstanzen selten unter diesem Wert liegt. Wenn nach dem Beenden einer WorkSpaces Applications-Sitzung die Gesamtzahl der WorkSpaces Applications-Instances den Wert für die Mindestkapazität unterschreitet, wird eine neue Flotteninstanz gestartet. Wie immer ist es wichtig, sich daran zu erinnern, dass eine WorkSpaces Anwendungsinstanz direkt einer Benutzersitzung zugeordnet ist, was sich direkt auf den Wert für Mindestkapazität auswirkt.

Die Eingabe eines Werts für Mindestkapazität, der über der erwarteten Parallelität liegt, führt zu höheren Kosten, obwohl die Benutzererfahrung dadurch nicht beeinträchtigt wird. Ein zu niedriger Wert führt zu niedrigen Kosten, beeinträchtigt jedoch die Benutzererfahrung, wenn die Gesamtzahl der Anfragen die verfügbare Kapazität übersteigt. Administratoren werden in einer solchen Situation die Fehlermeldung „Ungenügende Kapazität“ feststellen. Beispielsweise AvailableCapacity ist das Warten auf PendingCapacity Werden eine ineffiziente Nutzung der Zeit des Benutzers, wenn die Anzahl der zu erwartenden Verbindungen zu Beginn des Tages ein vorhersehbarer konsistenter Wert ist.

Beginnen Sie mit einer Mindestkapazität, die den typischen Randzeiten gerecht wird, und setzen Sie dann mithilfe der Richtlinie für die geplante Skalierung die Mindestkapazität vor Beginn des Arbeitstages effektiv zurück. Vergessen Sie nicht, eine weitere geplante Skalierungsrichtlinie zu erstellen, um die Mindestkapazität auf die Nebenzeiten zurückzusetzen. Weitere Informationen zu Skalierungsrichtlinien und deren Implementierung finden Sie im Abschnitt Strategien zur auto-scaling von Flotten in diesem Dokument.

Maximale Kapazität und Servicekontingenten

Die Festlegung der maximalen Kapazität mag wie ein willkürlicher Wert erscheinen, aber wenn sie richtig prognostiziert und festgelegt wird, werden dadurch der gesamte Ressourcenverbrauch und die Kosten optimiert. Ein eingegebener Wert, der höher ist als das Dienstkontingent für die WorkSpaces Anwendungsflotte in Ihrem, AWS-Konto kann als gültig erscheinen, aber wenn Auto Scaling-Ereignisse versuchen, Ressourcen auf die maximale Kapazität zu skalieren, können sie nicht gestartet werden, da der maximale Kapazitätswert das verfügbare Dienstkontingent überschreitet. Stellen Sie sicher, dass eine Service-Kontingentanfrage für die gewünschte maximale Kapazität gestellt wird, um sicherzustellen, dass die automatische Skalierung wie von Ihrem Unternehmen erwartet funktioniert.

Ein weiterer wichtiger Aspekt bei der Festlegung eines maximalen Kapazitätswerts sind die Kosten. Weitere Informationen finden Sie im Abschnitt Kostenoptimierung durch die Wahl des Flottentyps in diesem Dokument.