Freigeben über


Kapazitätsplanung für App-V für Windows

Gilt für: Windows 10, Windows 11, Windows Server 2016

Die folgenden Empfehlungen können als Baseline verwendet werden, um Informationen zur Kapazitätsplanung zu ermitteln, die für die App-V-Infrastruktur Ihrer Organisation geeignet sind.

Wichtig

Verwenden Sie die Informationen in diesem Abschnitt nur als allgemeine Anleitung für die Planung Ihrer App-V-Bereitstellung. Ihre Systemkapazitätsanforderungen hängen von den spezifischen Details Ihrer Hardware- und Anwendungsumgebung ab. Darüber hinaus sind die in diesem Dokument angezeigten Leistungsnummern Beispiele, und Ihre Ergebnisse können variieren.

Bestimmen des Projektbereichs

Bevor Sie die App-V-Infrastruktur entwerfen, bestimmen Sie, welche Anwendungen virtuell verfügbar sein werden, und identifizieren Sie auch die Zielbenutzer und ihre Standorte. Diese Informationen bestimmen, welche Art von App-V-Infrastruktur Ihr Projekt implementieren soll. Sie sollten Ihre Entscheidungen über den Umfang Ihres Projekts auf die spezifischen Anforderungen Ihrer Organisation stützen.

Aufgabe Weitere Informationen
Bestimmen des Anwendungsbereichs Die App-V-Infrastruktur kann auf unterschiedliche Weise eingerichtet werden, je nachdem, welche Anwendungen Sie virtualisieren möchten. Diese Anpassung bei der Einrichtung bedeutet, dass Ihre erste Aufgabe darin besteht, zu definieren, welche Anwendungen Sie virtualisieren möchten.
Bestimmen des Standortbereichs "Standortbereich" bezieht sich auf die physischen Standorte, an denen Sie die virtualisierten Anwendungen ausführen möchten (z. B. unternehmensweit oder an einem bestimmten geografischen Standort). Es kann sich auch auf die Benutzerpopulation beziehen, die die virtuellen Anwendungen (z. B. eine einzelne Abteilung) ausführen wird. Sie sollten eine Netzwerkzuordnung abrufen, die die Verbindungspfade, die verfügbare Bandbreite für jeden Standort, die Anzahl der Benutzer, die virtualisierte Anwendungen verwenden, und die WAN-Verbindungsgeschwindigkeit enthält.

Ermitteln der erforderlichen App-V-Infrastruktur

Sie können Ihre App-V-Umgebung auch mithilfe einer ESD-Lösung (Electronic Software Distribution) wie Microsoft Systems Center Configuration Manager verwalten. Weitere Informationen finden Sie unter Bereitstellen von App-V-Paketen mithilfe der elektronischen Softwareverteilung.

  • Eigenständiges Modell: Das eigenständige Modell ermöglicht die Windows Installer-fähige Verteilung virtueller Anwendungen ohne Streaming. App-V im eigenständigen Modus benötigt nur den Sequencer und den Client. es sind keine zusätzlichen Komponenten erforderlich. Anwendungen werden mithilfe eines Prozesses, der als Sequenzierung bezeichnet wird, für die Virtualisierung vorbereitet. Weitere Informationen finden Sie unter Planen der App-V Sequencer- und Clientbereitstellung. Das eigenständige Modell wird für die folgenden Szenarien empfohlen:

    • Wenn Remotebenutzer getrennt sind, die keine Verbindung mit der App-V-Infrastruktur herstellen können.
    • Wenn Sie ein Softwareverwaltungssystem ausführen, z. B. Configuration Manager.
    • Wenn Einschränkungen der Netzwerkbandbreite die elektronische Softwareverteilung behindern.
  • Vollständiges Infrastrukturmodell: Das vollständige Infrastrukturmodell bietet Funktionen für Softwareverteilung, -verwaltung und -berichterstellung; Es umfasst auch das Streaming von Anwendungen über das Netzwerk. Das vollständige App-V-Infrastrukturmodell besteht aus einem oder mehreren App-V-Verwaltungsservern, die zum Veröffentlichen von Anwendungen auf allen Clients verwendet werden können. Bei der Veröffentlichung werden die Symbole und Tastenkombinationen der virtuellen Anwendung auf dem Zielcomputer platziert. Es kann auch Anwendungen an lokale Benutzer streamen. Weitere Informationen zum Installieren des Verwaltungsservers finden Sie unter Planen der App-V Server-Bereitstellung. Das vollständige Infrastrukturmodell wird für die folgenden Szenarien empfohlen:

    • Wenn Sie den Verwaltungsserver verwenden möchten, um die Anwendung auf Zielcomputern zu veröffentlichen.
    • Für die schnelle Bereitstellung von Anwendungen auf Zielcomputern.
    • Wenn Sie die App-V-Berichterstellung verwenden möchten.

Wichtig

Das vollständige App-V-Infrastrukturmodell erfordert Microsoft SQL Server zum Speichern von Konfigurationsdaten. Weitere Informationen finden Sie unter Von App-V unterstützte Konfigurationen.

Leitfaden zur End-to-End-Serverdimensionierung

Im folgenden Abschnitt werden die End-to-End-Dimensionierung und Planung von App-V beschrieben. Genauere Informationen finden Sie in den nachfolgenden Abschnitten.

Hinweis

Roundtrip-Antwortzeit auf dem Client ist die Zeit, die der Computer, auf dem der App-V-Client ausführt, für den Empfang einer erfolgreichen Benachrichtigung vom Veröffentlichungsserver erforderlich ist. Roundtrip-Antwortzeit auf dem Veröffentlichungsserver ist die Zeit, die der Computer, auf dem der Veröffentlichungsserver ausgeführt wird, für den Empfang einer erfolgreichen Paketmetadatenaktualisierung vom Verwaltungsserver erforderlich ist.

  • 20.000 Clients können auf einen einzelnen Veröffentlichungsserver abzielen, um die Paketaktualisierungen in einer akzeptablen Roundtripzeit (<3 Sekunden) zu erhalten.
  • Ein einzelner Verwaltungsserver kann bis zu 50 Veröffentlichungsserver für Paketmetadatenaktualisierungen in einer akzeptablen Roundtripzeit (<5 Sekunden) unterstützen.

Empfehlungen zur Kapazitätsplanung von App-V Management Server

Die App-V-Veröffentlichungsserver benötigen den Verwaltungsserver für Paketaktualisierungsanforderungen und Paketaktualisierungsantworten. Der Verwaltungsserver sendet die Informationen dann an die Verwaltungsdatenbank, um Informationen abzurufen. Weitere Informationen zu unterstützten Konfigurationen des App-V-Verwaltungsservers finden Sie unter Von App-V unterstützte Konfigurationen.

Hinweis

Die Standardaktualisierungszeit auf dem App-V-Veröffentlichungsserver beträgt zehn Minuten.

Wenn mehrere gleichzeitige Veröffentlichungsserver einen einzelnen Verwaltungsserver für Paketmetadatenaktualisierungen kontaktieren, beeinflussen die folgenden drei Faktoren die Roundtrip-Antwortzeit des Veröffentlichungsservers:

  1. Die Anzahl der Veröffentlichungsserver, die gleichzeitig Anforderungen stellen.
  2. Die Anzahl der auf dem Verwaltungsserver konfigurierten Verbindungsgruppen.
  3. Die Anzahl der auf dem Verwaltungsserver konfigurierten Zugriffsgruppen.

In der folgenden Tabelle werden die einzelnen Faktoren, die sich auf die Roundtripzeit auswirken, ausführlicher beschrieben.

Hinweis

Roundtrip-Antwortzeit ist die Zeit, die der Computer, auf dem der App-V-Veröffentlichungsserver ausgeführt wird, für den Empfang einer erfolgreichen Paketmetadatenaktualisierung vom Verwaltungsserver erforderlich ist.

Faktoren, die sich auf die Roundtrip-Antwortzeit auswirken Beschreibung
Die Anzahl der Veröffentlichungsserver, die gleichzeitig Paketmetadatenaktualisierungen anfordern. Ein einzelner Verwaltungsserver kann auf bis zu 320 Veröffentlichungsserver reagieren, die gleichzeitig Veröffentlichungsmetadaten anfordern. In einem Fall mit 30 Veröffentlichungsservern, die gleichzeitig Veröffentlichungsmetadaten anfordern, beträgt die Roundtrip-Antwortzeit etwa 40 Sekunden, während sie für weniger als 50 Server weniger als 5 Sekunden beträgt. Von 50 auf 320 Veröffentlichungsserver erhöht sich das Reaktionsteam linear (ca. 2×).
Die Anzahl der auf dem Verwaltungsserver konfigurierten Verbindungsgruppen. Bei bis zu 100 Verbindungsgruppen gibt es keine signifikanten Änderungen an der Roundtrip-Antwortzeit auf dem Veröffentlichungsserver. Bei 100 bis 400 Verbindungsgruppen gibt es eine geringfügige lineare Erhöhung der Roundtrip-Antwortzeit.
Die Anzahl der auf dem Verwaltungsserver konfigurierten Zugriffsgruppen. Für bis zu 40 Zugriffsgruppen gibt es eine lineare (ca. 3×) Erhöhung der Roundtripantwortzeit auf dem Veröffentlichungsserver.

In der folgenden Tabelle werden Beispielwerte für jeden der vorherigen Faktoren angezeigt. In jeder Variante werden 120 Pakete vom App-V-Verwaltungsserver aktualisiert.

Szenario Variante Anzahl von Verbindungsgruppen Anzahl von Zugriffsgruppen Anzahl der Veröffentlichungsserver Netzwerkverbindungstyp Roundtrip-Antwortzeit (Sekunden) CPU-Auslastung des Verwaltungsservers
Kontaktverwaltungsserver für Veröffentlichungsserver zum gleichzeitigen Veröffentlichen von Metadaten Anzahl der Veröffentlichungsserver. 0
0
0
0
0
0
1
1
1
1
1
1
50
100
200
300
315
320
LAN 5
10
19
32
30
37
17
17
17
15
17
15
Veröffentlichungsmetadaten enthalten Verbindungsgruppen Anzahl von Verbindungsgruppen 10
20
100
150
300
400
1
1
1
1
1
1
100
100
100
100
100
100
LAN 10
11
11
16
22
25
17
19
22
19
20
20
Veröffentlichungsmetadaten enthalten Zugriffsgruppen Anzahl von Zugriffsgruppen 0
0
0
0
1
10
20
40
100
100
100
100
LAN 10
43
153
535
17
26
24
24

Die CPU-Auslastung des Computers, auf dem der Verwaltungsserver ausgeführt wird, beträgt ungefähr 25 % unabhängig von der Anzahl der Veröffentlichungsserver, die darauf abzielen. Die Microsoft SQL Server-Datenbanktransaktionen/Sekunde, Batchanforderungen/Sekunde und Benutzerverbindungen sind unabhängig von der Anzahl der Veröffentlichungsserver identisch. Beispielsweise sind Transaktionen/Sekunde ungefähr 30, Batchanforderungen ungefähr 200, und der Benutzer stellt etwa sechs Verbindungen her.

Durch eine geografisch verteilte Bereitstellung, bei der der Verwaltungsserver und die Veröffentlichungsserver ein Langsamverbindungsnetzwerk zwischen ihnen nutzen, liegt die Roundtripantwortzeit auf den Veröffentlichungsservern innerhalb akzeptabler Zeitlimits (<5 Sekunden), selbst für 100 gleichzeitige Anforderungen auf einem einzelnen Verwaltungsserver.

Szenario Variante Anzahl von Verbindungsgruppen Anzahl von Zugriffsgruppen Anzahl der Veröffentlichungsserver Netzwerkverbindungstyp Roundtrip-Antwortzeit (Sekunden) CPU-Auslastung des Verwaltungsservers (in %)
Netzwerkverbindung zwischen dem Veröffentlichungsserver und dem Verwaltungsserver Langsames Netzwerk mit 1,5 MBit/s 0
0
1
1
50
100
1,5 MBit/s Kabel DSL 4
5
1
2
Netzwerkverbindung zwischen dem Veröffentlichungsserver und dem Verwaltungsserver LAN/WLAN-Netzwerk 0
0
1
1
100
200
WLAN 11
20
15
17

Unabhängig davon, ob der Verwaltungsserver und die Veröffentlichungsserver über ein Netzwerk mit langsamen Verbindungen oder über ein Hochgeschwindigkeitsnetzwerk verbunden sind, kann der Verwaltungsserver in 30 Minuten ungefähr 15.000 Paketaktualisierungsanforderungen verarbeiten.

Empfehlungen zur Kapazitätsplanung von App-V Reporting Server

App-V-Clients senden Berichtsdaten an den Berichtsserver. Der Berichtsserver zeichnet dann die Informationen in der Microsoft SQL Server-Datenbank auf und gibt eine erfolgreiche Benachrichtigung an den Computer zurück, auf dem der App-V-Client ausgeführt wird. Weitere Informationen zu den unterstützten Konfigurationen des App-V-Berichtsservers finden Sie unter Von App-V unterstützte Konfigurationen.

Hinweis

Die Roundtrip-Antwortzeit ist die Zeit, die der Computer mit dem App-V-Client ausführt, um die Berichtsinformationen an den Berichtsserver zu senden und eine erfolgreiche Benachrichtigung vom Berichtsserver zu erhalten.

Szenario Zusammenfassung
Mehrere App-V-Clients senden Gleichzeitig Berichtsinformationen an den Berichtsserver. Die Roundtrip-Antwortzeit vom Berichtsserver beträgt 2,6 Sekunden für 500 Clients. Die Roundtripantwortzeit vom Berichtsserver beträgt 5,65 Sekunden für 1.000 Clients. Die Roundtrip-Antwortzeit erhöht sich linear abhängig von der Anzahl der Clients.
Vom Berichtsserver verarbeitete Anforderungen pro Sekunde. Ein einzelner Berichtsserver und eine einzelne Datenbank können maximal 139 Anforderungen pro Sekunde verarbeiten. Der Durchschnitt beträgt 121 Anforderungen/Sekunde. Mit Hilfe von zwei Berichtsservern, die an dieselbe Microsoft SQL Server-Datenbank berichten, beträgt die durchschnittliche Anzahl von Anforderungen/Sekunde, wie ein einzelner Berichtsserver, etwa 127 mit maximal 278 Anforderungen/Sekunde. Ein einzelner Berichtsserver kann 500 gleichzeitige/aktive Verbindungen verarbeiten. Ein einzelner Berichtsserver kann maximal 1.500 gleichzeitige Verbindungen verarbeiten.
Berichtsdatenbank. Sperrkonflikte auf dem Computer, auf dem Microsoft SQL Server ausgeführt wird, ist der einschränkende Faktor für Anforderungen/Sekunde. Durchsatz und Antwortzeit sind unabhängig von der Datenbankgröße.

Berechnen der zufälligen Verzögerung

Die zufällige Verzögerung gibt die maximale Verzögerung (in Minuten) für Daten an, die an den Berichtsserver gesendet werden sollen. Wenn die geplante Aufgabe gestartet wird, generiert der Client eine zufällige Verzögerung zwischen 0 und ReportingRandomDelay und wartet die angegebene Dauer, bevor Daten gesendet werden.

Zufällige Verzögerung = 4 × Anzahl von Clients/durchschnittlichen Anforderungen pro Sekunde.

Beispiel: Die zufällige Verzögerung für 500 Clients mit 120 Anforderungen pro Sekunde beträgt 4 × 500/120 = etwa 17 Minuten.

Empfehlungen zur Kapazitätsplanung des App-V-Veröffentlichungsservers

Computer, auf denen der App-V-Client ausgeführt wird, stellen eine Verbindung mit dem App-V-Veröffentlichungsserver her, um eine Veröffentlichungsaktualisierungsanforderung zu senden und eine Antwort zu erhalten. Die Roundtrip-Antwortzeit wird auf dem Computer gemessen, auf dem der App-V-Client ausgeführt wird, während die Prozessorzeit auf dem Veröffentlichungsserver gemessen wird. Weitere Informationen zu unterstützten Konfigurationen des App-V-Veröffentlichungsservers finden Sie unter Von App-V unterstützte Konfigurationen.

Wichtig

Die folgende Liste enthält die wichtigsten Faktoren, die beim Einrichten des App-V-Veröffentlichungsservers zu berücksichtigen sind:

  • Die Anzahl der Clients, die gleichzeitig eine Verbindung mit einem einzelnen Veröffentlichungsserver herstellen.
  • Die Anzahl der Pakete bei jeder Aktualisierung.
  • Die verfügbare Netzwerkbandbreite in Ihrer Umgebung zwischen dem Client und dem App-V-Veröffentlichungsserver.
Szenario Zusammenfassung
Mehrere App-V-Clients stellen gleichzeitig eine Verbindung mit einem einzelnen Veröffentlichungsserver her. Ein Veröffentlichungsserver, auf dem Dual-Core-Prozessoren ausgeführt werden, kann auf maximal 5.000 Clients reagieren, die gleichzeitig eine Aktualisierung anfordern. Für 5.000 bis 10.000 Clients erfordert der Veröffentlichungsserver mindestens einen Quad-Kern. Für 10.000 bis 20.000 Clients sollte der Veröffentlichungsserver über duale Quad-Kerne verfügen, um effizientere Antwortzeiten zu erzielen. Ein Veröffentlichungsserver mit einem Quad Core kann innerhalb von drei Sekunden bis zu 10.000 Pakete aktualisieren. (Unterstützt 10.000 gleichzeitige Clients.)
Anzahl der Pakete bei jeder Aktualisierung. Durch das Erhöhen der Anzahl von Paketen wird die Antwortzeit um etwa 40 % (bis zu 1.000 Pakete) erhöht.
Netzwerk zwischen dem App-V-Client und dem Veröffentlichungsserver. In einem langsamen Netzwerk (Bandbreite von 1,5 MBit/s) erhöht sich die Antwortzeit um 97 % im Vergleich zu LAN (bis zu 1.000 Benutzer).

Hinweis

Die CPU-Auslastung des Veröffentlichungsservers ist während des Zeitintervalls immer hoch, wenn gleichzeitige Anforderungen verarbeitet werden müssen (>in den meisten Fällen 90 %). Der Veröffentlichungsserver kann etwa 1.500 Clientanforderungen in einer Sekunde verarbeiten.

Szenario Variante Anzahl der App-V-Clients Anzahl der Pakete Prozessorkonfiguration auf dem Veröffentlichungsserver Netzwerkverbindungstyp App-V-Client-Roundtripzeit (in Sekunden) CPU-Auslastung des Veröffentlichungsservers (in %)
Der App-V-Client sendet eine Veröffentlichungsaktualisierungsanforderung und empfängt eine Antwort, wobei jede Anforderung 120 Pakete enthält. Anzahl der Clients 100
1,000
5,000
10,000
120
120
120
120
Dual Core
Dual Core
Quad Core
Quad Core
LAN 1
2
2
3
100
99
89
77
Mehrere Pakete in jeder Aktualisierung. Anzahl der Pakete 1,000
1,000
500
1,000
Quad Core LAN 2
3
92
91
Netzwerk zwischen Client und Veröffentlichungsserver. Langsames Netzwerk mit 1,5 MBit/s 100
500
1,000
120
120
120
Quad Core 1,5 MBit/s intrakontinentales Netzwerk 3
10 (0,2 % Fehlerrate)
7 (1 % Fehlerrate)

Empfehlungen zur App-V-Streamingkapazitätsplanung

Computer, auf denen der App-V-Client ausgeführt wird, streamen das virtuelle Anwendungspaket vom Streamingserver. Die Roundtripantwortzeit wird auf dem Computer gemessen, auf dem der App-V-Client ausgeführt wird, und ist die Zeit, die zum Streamen des gesamten Pakets erforderlich ist.

Wichtig

In der folgenden Liste sind die wichtigsten Faktoren aufgeführt, die beim Einrichten des App-V-Streamingservers zu berücksichtigen sind:

  • Die Anzahl der Clients, die Anwendungspakete gleichzeitig von einem einzelnen Streamingserver streamen.
  • Die Größe des Pakets, das gestreamt wird.
  • Die verfügbare Netzwerkbandbreite in Ihrer Umgebung zwischen dem Client und dem Streamingserver.
Szenario Zusammenfassung
Mehrere App-V-Clients streamen Anwendungen gleichzeitig von einem einzelnen Streamingserver. Wenn die Anzahl der Clients, die gleichzeitig vom gleichen Server gestreamt werden, zunimmt, besteht eine lineare Beziehung zur Download-/Streamingzeit des Pakets.
Größe des Pakets, das gestreamt wird. Die Paketgröße hat nur bei größeren Paketen mit einer Größe von etwa 1 GB einen erheblichen Einfluss auf die Streaming-/Downloadzeit. Bei Paketgrößen von 3 MB bis 100 MB reicht die Streamingzeit von 20 Sekunden bis 100 Sekunden bei 100 gleichzeitigen Clients.
Netzwerk zwischen dem App-V-Client und dem Streamingserver. In einem langsamen Netzwerk (Bandbreite von 1,5 MBit/s) erhöht sich die Reaktionszeit im Vergleich zu LAN (bis zu 100 Benutzer) um 70 bis 80 %.

In der folgenden Tabelle werden Beispielwerte für jeden der Faktoren in der vorherigen Liste angezeigt:

Szenario Variante Anzahl der App-V-Clients Größe jedes Pakets Netzwerkverbindungstyp Roundtripzeit auf dem App-V-Client (in Sekunden)
Mehrere App-V-Clients, die virtuelle Anwendungspakete von einem Streamingserver streamen. Anzahl der Clients. 100
200
1,000
100
200
1,000
3,5 MB
3,5 MB
3,5 MB
5 MB
5 MB
5 MB
LAN 29
39
391
35
68
461
Größe jedes Pakets, das gestreamt wird. Größe jedes Pakets. 100
200
100
200
21 MB
21 MB
109 MB
109 MB
LAN 33
83
100
160
Netzwerkverbindung zwischen Client und App-V-Streamingserver. Langsames Netzwerk mit 1,5 MBit/s. 100
100
3,5 MB
5 MB
1,5 MBit/s intrakontinentales Netzwerk 102
121

Jeder App-V-Streamingserver sollte in der Lage sein, mindestens 200 Clients gleichzeitig zu verarbeiten, die virtualisierte Anwendungen streamen.

Hinweis

Die tatsächliche Zeit für das Streamen wird in erster Linie durch die Anzahl der Clients bestimmt, die gleichzeitig gestreamt werden, die Anzahl der Pakete, die Paketgröße, die Netzwerkaktivität des Servers und die Netzwerkbedingungen.

Beispielsweise kann ein durchschnittlicher Benutzer ein 100-MB-Paket in weniger als 2 Minuten streamen, wenn 100 clients gleichzeitig vom Server gestreamt werden. Ein Paket mit einer Größe von 1 GB kann jedoch bis zu 30 Minuten dauern. In den meisten realen Umgebungen ist der Streamingbedarf nicht einheitlich verteilt. Sie müssen die ungefähren Streaming-Spitzenanforderungen in Ihrer Umgebung kennen, um die Anzahl der erforderlichen Streamingserver richtig zu dimensionieren.

Die Anzahl der Clients, die ein Streamingserver unterstützen kann, kann erhöht und die Spitzenanforderungen an Streaming reduziert werden, wenn Sie Ihre Anwendungen vorab zwischenspeichern. Sie können auch die Anzahl der Clients erhöhen, die ein Streamingserver unterstützen kann, indem Sie die bedarfsgesteuerte Streamingbereitstellung und streamoptimierte Pakete verwenden.

Kombinieren von App-V-Serverrollen

Aufgrund der Skalierungs- und Fehlertoleranzanforderungen ist die Mindestanzahl von Servern, die ein Standort mit Active Directory-Konnektivität benötigt, um zu funktionieren, 1. Dieser Server hosten den Verwaltungsserver, den Verwaltungsserverdienst und die Microsoft SQL Server-Rollen. Diese Abdeckung bedeutet, dass Sie Serverrollen in beliebiger Kombination anordnen können, da sie nicht miteinander in Konflikt geraten.

Ungeachtet der Skalierungsanforderungen ist die Mindestanzahl von Servern, die eine fehlertolerante Implementierung benötigt, vier. Die Verwaltungsserver- und Microsoft SQL Server-Rollen unterstützen die Platzierung in fehlertoleranten Konfigurationen. Der Verwaltungsserverdienst kann mit jeder der Rollen kombiniert werden, bleibt jedoch ein Single Point of Failure.

Obwohl es viele Fehlertoleranzstrategien und -technologien gibt, die Sie verwenden können, sind nicht alle auf einen bestimmten Dienst anwendbar. Wenn App-V-Rollen kombiniert werden, können die resultierenden Inkompatibilitäten dazu führen, dass bestimmte Fehlertoleranzoptionen nicht mehr funktionieren.