Microsoft Exchange Server 5.5: Berechnen der Anzahl von Benutzern pro Server von Eric S. Savoldi, Microsoft Consulting Services, Cincinnati Überblick Ausgangpunkt: So berechnen Sie die Anzahl von Benutzern pro Server, planen eine Exchange Server-Einführung und skalieren den Server für steigende Kapazität. Detaillierungsgrad: Mittel Aufgabe: Administration, Bereitstellung Artikelabschnitt Inhalt Einführung Definieren des Kontexts der Kapazitätsplanung Faktoren mit Auswirkung auf die Leistung Ermitteln der Grenzbereiche Die Kunst der Leistungsanalyse: Erkennen von Leistungsengpässen Erklärt die vielfachen Möglichkeiten hinter einer anscheinend einfachen Frage. So interagieren Messagingaktivität, Serverbelastungen und Antwortzeit und beeinflussen das Gleichgewicht. Einflüsse von Hardware, Exchange-Software und anderen Netzwerkaktivitäten. Testverfahren, Verwenden von LoadSim und Klassifizieren von Benutzern und Servern. Ermitteln, welche der drei wichtigsten Serverkomponenten (Speicher, Datenträger-E/ASubsystem oder CPU) den Engpass bildet. Einführung Für wie viele Benutzer kann ein einzelner Exchange-Server als Host fungieren? Diese anscheinend einfache - und häufig gestellte - Frage ist in Wirklichkeit kompliziert, da es so viele Gründe gibt, sie zu stellen. Einige Administratoren stellen sie, weil sie bereits in Serverhardware investiert haben und die aktuelle Kapazität bewerten müssen. Andere benötigen Informationen, auf die sie Kaufentscheidungen stützen können, und zum Planen von Wachstum und Kapazität in der Zukunft. Eine bestimmte Anzahl von Benutzern pro Server, die sich gut verwalten lässt, passt möglicherweise nicht mit Einschränkungen der Serverbandbreite überein, eine andere Anzahl, die bei der verfügbaren Bandbreite gut funktioniert, hat möglicherweise zeitraubende Backups zur Folge. Und so weiter und sofort. Der erste Teil dieses Artikels diskutiert die Leistungsfragen, die Ihnen bei der Beantwortung dieser bedeutenden Frage helfen können. Der zweite Teil gibt spezifische Empfehlungen zum Planen einer Exchange Server-Einführung und seiner Skalierung für steigende Kapazität. Definieren des Kontexts der Kapazitätenplanung Eine mit dieser Frage eng verknüpfte Schwierigkeit liegt in den Grundeinheiten begründet, von denen sie bestimmt wird: Benutzer und Server. Benutzer unterscheiden sich stark in der Verwendung von Messaging-, Zeitplanungs- und Arbeitsgruppenanwendungen. Das hängt davon ab, in welchem Umfang sie E-Mail-, Kalender- und Öffentliche Ordner-Anwendungen für geschäftliche und persönliche Aktivitäten verwenden. Auch die Unternehmenskultur und die geografische Verteilung von Niederlassungen Ihrer Organisation beeinflussen das Messagingsystem. Einige Benutzer empfangen Hunderte von Nachrichten pro Tag, andere nur ein oder zwei. Einige Benutzer erstellen fünfzig Nachrichten pro Tag, andere nur wenige pro Woche. In bestimmten Organisation macht ein kleiner Prozentsatz von Benutzern einen unverhältnismäßig großen Anteil der Servergesamtlast aus. Auch Server können sehr unterschiedlich sein. Einige Organisationen mit großen, zentral angesiedelten oder gut verbundenen Standorten verwenden eine kleine Anzahl von hochwertigen Multiprozessorcomputern mit mehreren Gigabytes RAM (Random Access Memory = Arbeitsspeicher) und Dutzenden von Festplattenlaufwerken. Diese Server fungieren für so viele Benutzer pro Servercomputer wie möglich als Host. Andere Organisationen setzen Hunderte preisgünstige und weniger hochwertige Computer ein, um viele kleine, geografisch verstreute Standorte zu verbinden. Eine Organisation kann aber auch aus Remotestandorten bestehen, die sich in Größe und Verbindungsgeschwindigkeiten unterscheiden und jeweils andere Anforderungen an Server- und Endbenutzerkapazität stellen. Eins aber haben allen Organisationen gemeinsam: Sie möchten Hardware-, Wartungs- und Administrationskosten sowie die Kapazität ihres Messagingsystems optimal nutzen. Um die Anzahl der Benutzer zu ermitteln, die ein Server unterstützen kann, müssen Sie die beiden Lastentypen bewerten, die Benutzer auf dem Server verursachen: von Benutzern eingeleitete Aktionen und Hintergrundaktionen. Von Benutzern eingeleitete Aktionen Von Benutzern eingeleitete Aktionen sind Messagingvorgänge, die der Server aufgrund von Benutzeraktivitäten durchführt. Für die Benutzer sieht es so aus (zumindest sollte es das), als ob diese Aktionen sofort erfolgten. Wenn Benutzer eine ungelesene Nachricht in ihrem privaten Ordner im Serverinformationsspeicher öffnen, führt der Server gleichzeitig die folgenden Aktionen aus: Empfängt und interpretiert die Anforderung zum Öffnen. Überprüft Zugriffsbeschränkungen. Ruft die Nachricht aus der Datenbank ab. Markiert die Nachricht als ungelesen. Aktualisiert den Zähler für ungelesene Nachrichten des Ordners. Ruft die Eigenschaften der angeforderten Nachricht ab und gibt sie an den Client zurück. Generiert eine Ordnerbenachrichtigung an den Client mit dem Inhalt, dass die Nachricht gelesen wurde. All dies passiert in dem Zeitraum, die der von der Clientanwendung ausgelöste RPC (Remote Procedure Call) benötigt, um die Steuerung an den Client zurückzugeben. Aus der Sicht des Benutzers enthält die gesamte Aktion außerdem zusätzliche Clientverarbeitungszeit, die zum Anzeigen des Fensters und Anzeigen der Nachrichteneigenschaften erforderlich ist. Von Benutzern eingeleitete Aktionen bilden den wichtigsten Lastfaktor auf Exchange-Servern, die Benutzer direkt unterstützen (im Gegensatz zu Servern, die als Backbone oder Gateway arbeiten). Die Benutzerlast wird bestimmt durch die Anzahl der Benutzer, die das Messagingsystem pro Zeiteinheit aktiv verwenden, und die Art der von ihnen durchgeführten Aktionen. Hintergrundaktionen Exchange Server führt auch Hintergrundaktionen (oder asynchrone Aktionen) für verbundene und Remotebenutzer durch: Akzeptieren, Übertragen, Weiterleiten und Übermitteln von Nachrichten; Erweitern von Verteilerlisten; Replizieren von Änderungen in Öffentlichen Ordnern und Verzeichnisdienstinformationen; Ausführen von Regeln; Überwachen von Speicherkontingenten und Durchführen von Hintergrundwartung, wie z. B. Tombstone Garbage Collection (auch bekannt als Onlinedatenbank-Defragmentierung) und Anzeigen des Ablaufdatums des Indexes. Solange diese Aktionen in überschaubaren Zeiträumen abgeschlossen werden, hat dies keine Auswirkung auf den Benutzer. Die Hintergrundlast wird ebenfalls durch die Anzahl der Benutzer auf dem Server bestimmt. In Systemen mit vielen Benutzern können Exchange-Server, die als Gateways oder Verbindungsstellen zwischen Standorten dienen, starke Hintergrundaktivitäten aufweisen. Wenn diese Server jedoch für Benutzer nicht direkt als Host fungieren, werden sie nicht durch Lasten von Aktivitäten beeinträchtigt, die durch Benutzer eingeleitet werden. Ungleichheit von Aktionen Um ein Lastenmodell dieser Aktionen für den Exchange-Server zu erstellen, betrachten einige Administratoren alle von Benutzern eingeleiteten Aktionen als gleich und alle Hintergrundaktionen ebenfalls als gleich. Dies ist ganz bestimmt nicht der Fall. Benutzer, die eine 500 KB große Nachricht in ihren persönlichen Informationsspeicher kopieren, belasten den Server stärker als Benutzer, die eine 1 KB große Nachricht kopieren. Das Senden einer E-Mail an eine Verteilerlisten mit 100 Mitgliedern erzeugt mehr Hintergrundaktivität als das Senden der Nachricht an einen einzigen Empfänger. Sie können die Serverlast besser vorhersagen, wenn Sie kombinierte Aktivitäten über einen Zeitraum betrachten. Untersuchen Sie die Aktivität einer bestimmten Benutzergruppe in einem bestimmten Zeitraum (z. B. einem typischen 8 Stunden-Arbeitstag), und summieren Sie ihre von Benutzern eingeleiteten Aktionen (Interaktion mit dem Server zum Senden oder Lesen von Nachrichten, Suchen nach Empfängern im Adressbuch usw.). Messen Sie die zugehörigen Hintergrundaktionen. Klassifizieren Sie die Aktivitätsebene der Benutzergruppe in Relation zu anderen Gruppen. Sie können diese Daten verwenden, um Benutzergruppen nach der Anzahl der pro Zeiteinheit durchgeführten Aktionen und der Serverlasteigenschaften (wie z. B. Nachrichtengröße) dieser Aktionen zu charakterisieren. Diese Daten benötigen Sie, um die Systemleistung für verschiedene Benutzergruppen vorherzusagen. Im Folgenden finden Sie ein Beispiel für die Klassifizierung des Exchange Performance Teams (Exchange-Leistungsteam) für geringe, mittlere und starke Verwendung: Im Tagesdurchschnitt führt ein Benutzer der Klasse geringe Verwendung die folgenden Aktionen aus: sendet drei Nachrichten. liest fünf neue und 12 alte Nachrichten. nimmt eine Terminänderung vor. Ein Benutzer der Klasse mittlere Verwendung sendet sechs Nachrichten. liest 15 neue und 12 alte Nachrichten. nimmt fünf Terminänderungen vor. Ein Benutzer der Klasse hohe Verwendung sendet acht Nachrichten. liest 20 neue und 12 alte Nachrichten. nimmt zehn Terminänderungen vor. Wie sehr Ihre Organisation zur geschäftlichen Kommunikation von Messaging abhängt, hat einen Einfluss auf die Exchange Server-Leistung und die Anzahl der Benutzer, für die ein Server als Host fungieren kann. Bei einigen Firmen, wie Microsoft, läuft ein Großteil der Kommunikation über das Messagingsystem, wodurch Verwendung in hohem Ausmaß entsteht. Dieselbe Hardware kann bei identischer Funktionalität 500 Benutzer der Klasse "geringe Verwendung", jedoch nur 150 Benutzer der Klasse "hohe Verwendung" aufnehmen. Zu den Hardwareressourcen eines Servers gehören eine oder mehrere CPUs, Arbeitsspeicher (RAM) und eine oder mehrere Festplattenlaufwerke mit ihren Controllern (das E/A-Subsystem). Um von Benutzern eingeleitete oder Hintergrundaktionen auszuführen, verwendet Exchange Server diese drei Ressourcen unterschiedlich stark. Die Bearbeitung der Anforderung eines Clients zum Öffnen einer Nachricht benötigt mehrere Millisekunden CPU-Bearbeitungszeit, einen oder mehrere Datenträgerzugriffe und genügend Speicher, um den Code und die Daten aufzunehmen, die zum Durchführen des Vorgangs erforderlich sind. Wenn jede vom Benutzer eingeleitete Aktion abgeschlossen ist, bevor die Nächste beginnt, verarbeitet der Server jede Aktion mit 100 Prozent seiner Hardware, wodurch sie ohne Warten auf verfügbare Ressourcen schnellstmöglich abgeschlossen wird. Zwischen Aktionen ist er im Wesentlichen im Leerlauf. Benutzer erfreuen sich minimaler Server- und Netzwerkantwortzeiten. Der Server ist ohne Last. Wenn viele von Benutzern eingeleitete Aktionen nahezu gleichzeitig erfolgen oder eine Reihe von Hintergrundaktionen stattfinden, konkurrieren die Aktionen um die Hardwareressourcen eines Servers, und dies führt zu Engpässen. Der Code zum Durchführen einer Aktion muss auf verfügbare Hardware warten. Wenn der Server unter Last ist, benötigen Aktionen bis zum Abschluss länger und Benutzer stellen längere Antwortzeiten fest. Das Verhältnis zwischen Last und Antwortzeit bestimmt die Anzahl der Benutzer, die ein Server unterstützen kann. Wenn die Last auf einem Server zunimmt, ändern sich zu einem bestimmten Zeitpunkt die Antwortzeiten für Benutzer von akzeptabel zu inakzeptabel. Sie müssen abschätzen, wo dieser Wendepunkt in Ihrer Organisation auftritt. Aktivität, die Last verursacht, ist nicht gleichmäßig über einen Zeitraum verteilt. Morgenstunden an einem Arbeitstag können die höchste Last generieren, da Benutzer viel Zeit mit dem Beantworten von E-Mail-Nachrichten oder dem Lesen von Informationen in Öffentlichen Ordnern verbringen, die am vorherigen Tag eingingen. Mittagszeit, Abende und Wochenenden weisen eine niedrige Messagingaktivität auf. Selbst wenn Sie Abweichungen auf dieser Ebene ignorieren und ziemlich gleichförmige Verwendungsintervalle annehmen, schwankt die Last dennoch innerhalb eines Zeitraumes aufgrund von individuellen Unterschieden bei der Verwendungsebene und Zeitplanung. Stellen Sie sich von Benutzern eingeleitete Aktionen als Quantenereignisse vor, die Benutzerlast sammeln und zeitlich gleichmäßig verteilen. Die meisten Server stellen beispielsweise einen Aktivitätsanstieg am Beginn des Arbeitstages fest, sobald Benutzer auf demselben Server neue Nachrichten downloaden. Wenn die meisten dieser Benutzer ihre neuen Nachrichten sofort lesen, führt dies zu einem weiteren Aktivitätsanstieg. Wenn ein Exchange-Server für ausreichend viele Benutzer als Host fungiert, gleichen sich die Quanteneffekte einzelner Verwendungsmuster, Zeitpläne und Gewohnheiten aus und sollten außer in extremen Situationen keinen großen Prozentsatz der gesamten Benutzerlast auf dem Server darstellen. Faktoren mit Auswirkung auf die Leistung Typ und Anzahl der CPUs in einem Server bestimmen das Leistungspotenzial einer Exchange Server-Umgebung. Computer, die auf einem Pentium II-Prozessor basieren, bieten eine höhere Leistung als Computer, die auf einem Pentium-Chip basieren. Ein Pentium mit 233 MHz verfügt über mehr Leistung als ein Pentium mit 133 MHz. Computer mit mehreren CPUs übertreffen Computer mit nur einer CPU, jedoch nicht linear: Ein Server mit zwei 233 MHz-Pentium-CPUs bietet normalerweise nicht die doppelte Leistung eines Computers mit nur einer 233 MHzPentium-CPU. Auslagerung (Paging) ist das Ergebnis eines Speicherkonflikts, der auftritt, wenn zwei oder mehr Anwendungen Systemspeicher verwenden möchten. Wenn das System über keinen physischen Speicher mehr verfügt, schreibt es Speicherseiten mithilfe des Auslagerungsprozesses auf die Festplatte und macht physischen Speicher für den anderen Prozess frei. Wenn dieser Prozess abgeschlossen ist, liest er diese Seiten von der Festplatte in den physischen Speicher zurück, damit sie der ursprüngliche Prozess verwenden kann. Speicherkonflikte sind tolerabel, bis das System an einem Punkt angelangt ist, an dem die Systemressourcen (CPU-Zeit, Busbandbreite, Datenträgezeit usw.) einen höheren Aufwand zum Übergeben von Seiten zwischen Prozessen als für die Ausführung der eigentlichen Arbeit aufwenden. Wenn Sie ein Diagramm von Speicherkonflikten und durchschnittlichen Antwortzeiten erstellen, sehen Sie eine ziemlich gerade Linie von keinen Konflikten bis zu dem Punkt, an dem Antwortzeiten drastisch ansteigen, dem so genannten Überlastungspunkt (Thrashing Point). Wenn Speicherkonflikte diesen Punkt überschreiten, steigen Antwortzeiten exponentiell. Temporäres Thrashing ist in einigen Umgebungen tolerabel, Sie sollten es jedoch zu vermeiden. Die Exchange Server-Gesamtleistung hängt vom E/A-Subsystem ab. Berücksichtigen Sie Typ und Anzahl der Plattencontroller, Typ der installierten Laufwerke sowie Fehlertoleranz und RAIDKonfigurationen. Verwenden Sie alle verfügbaren SCSI-Kanäle und fügen Sie bei Bedarf weitere hinzu, um die Leistung zu steigern. Zusätzliche Festplattenlaufwerke erhöhen ebenfalls die Leistung, insbesondere bei wahlfreier Datenträger-E/A, wie sie öffentliche und private Exchange Server-Informationsspeicher verwenden. Da alle Laufwerke mechanischen Einschränkungen unterliegen, kann die Last durch Hinzufügen von mehr Laufwerken effizient verteilt werden. Weitere Informationen finden Sie unter "The Limits of Unlimited Information Store" (englischsprachig) im TechNet. Zum Erzielen optimaler Netzwerkleistung sollten Sie auch den verwendeten Kartentyp und das verwendete Netzwerkmedium berüchsichtigen, wie z. B. Twisted-Pair-Kabel, Glasfaserkabel, Koaxialkabel usw.. Sie können im Server je nach Bedarf eine Hochleistungs-Netzwerkkarte installieren, die nur die Mindestanzahl von Netzwerkprotokolle verwendet, oder mehrere Netzwerkkarten zum Segmentieren des LANs. Da Netzwerkkarten stark schwankende Leistungsebenen haben, müssen Sie Bustyp, Busbreite und Größe des Onboardspeichers sorgfältig abwägen. Zum Erzielen optimaler Netzwerkleistung sollten Sie auch den verwendeten Kartentyp und das verwendete Netzwerkmedium berüchsichtigen, wie z. B. Twisted-Pair-Kabel, Glasfaserkabel, Koaxialkabel usw.. Sie können im Server je nach Bedarf eine Hochleistungs-Netzwerkkarte installieren, die nur die Mindestanzahl von Netzwerkprotokolle verwendet, oder mehrere Netzwerkkarten zum Segmentieren des LANs. Da Netzwerkkarten stark schwankende Leistungsebenen haben, müssen Sie Bustyp, Busbreite und Größe des Onboardspeichers sorgfältig abwägen. Verbundene Benutzer im Gegensatz zu Benutzern insgesamt Wenn Sie die Anzahl der Benutzer pro Server berechnen, müssen Sie abschätzen, wie viele Benutzer sich gleichzeitig mit dem Server verbinden werden. Sie können mehr Benutzerkonten auf einen Server platzieren, wenn Sie wissen, dass sich nicht alle gleichzeitig verbinden werden. So melden sich z. B. Schichtarbeiter niemals gleichzeitig auf dem Exchange-Server an, so dass Sie beide Gruppen auf demselben Server hosten können. Wenn ein Server für mehr Benutzer als Host fungiert, wird die Hintergrundaktivität des Servers erhöht, doch ist dies in der Regel einer größeren Anzahl gleichzeitig verbundener Benutzer vorzuziehen. Bedenken Sie jedoch, dass Exchange Server weiterhin einige Aktionen (Verzeichnisaktualisierungen, Weiterleiten von Nachrichten usw.) für Benutzer durchführt, auch wenn diese Benutzer beim System nicht angemeldet sind. Speicherort und Verwendung von Informationsspeichern Exchange-Benutzer können ihre Nachrichten im serverbasierten Informationsspeicher (IS) oder in Persönlichen Ordnern (einer PST-Datei) auf ihrem lokalen Computer oder auf einem Netzlaufwerk speichern. Auch beim Verwenden Persönlicher Ordner müssen Benutzer einen serverbasierten Speicher haben, um Nachrichten zu empfangen und Regeln zu verarbeiten. Wenn Benutzer jedoch als Standardübermittlungsort einen Persönlichen Ordner festlegen und die meisten Nachrichten dort speichern, entlastet dies den Server erheblich. Nachrichten, die in das Serverpostfach eines Benutzers übermittelt werden, initiieren weiterhin Posteingangssortierregeln, doch verschiebt der Server die Ausführung bis zur Benutzeranmeldung. Das lokale Speichern von Daten entlastet den Server von einer großen Anzahl an ExchangeTransaktionen. Wenn z. B. Benutzer Daten aus ihren Persönlichen Ordnern anfordern, muss der Server die folgenden Aktionen nicht mehr ausführen: Attribute und Daten lesen und in den Puffercache schreiben, die Daten als gelesen kennzeichnen, den Zähler der ungelesenen Nachrichten aktualisieren und die Daten an den Client senden. Wenn Benutzer eine Kopie aller gesendeten Objekte im Ordner Gesendete Objekte speichern, können die Outlook- oder Exchange-Clients diese lokal in einer PST-Datei speichern, wodurch der Server entlastet wird. Wenn Benutzer Nachrichten löschen, speichert der Client Kopien im lokalen Ordner Gelöschte Objekte anstatt auf dem Server. Der Exchange-Server verfügt so ständig über weniger Daten, was Backups vereinfachen kann. Clienttypen Wenn Sie Gruppen von Benutzern beschreiben, notieren Sie auch das Clientprotokoll. Exchange Server unterstützt eine Reihe von Clientprotokollen: Post Office Protocol (POP3), Internet Message Access Protocol (IMAP4), Messaging Application Programming Interface (MAPI) und Hypertext Transfer Protocol (HTTP) über den Client von Outlook Web Access (OWA). Exchange unterstützt auch Macintosh- und Windows 16-Bit-MAPI-Clients. Im Folgenden wird beschrieben, wie sich die einzelnen Protokolle auf die Exchange-Serverlast auswirken können: MAPI Der 32-Bit-Windows-MAPI-Client Outlook enthält zahlreiche Features und belastet Exchange Server am höchsten. Outlook ermöglicht Zugriff auf das Globale Adressbuch, verschiedene Ansichten und Regeln, über die andere E-Mail-Clients nicht verfügen, sowie Zugriff auf Öffentliche Ordner und elektronische Formulare. Auch die Komponenten Journal, Kontakte, Aufgabenliste, Notizen und insbesondere Kalender erhöhen die Serverlast, wenn sie häufig verwendet werden (weiter unten in diesem Artikel ausführlich beschrieben). Der OWA-Client unterstützt einige dieser Features und wird im Laufe der Weiterentwicklung um weitere ergänzt. Zurzeit können OWA-Benutzer auf ihren Kalender zugreifen, verfügen jedoch nicht über einen Besprechungs-Assistenten und können nicht auf Kalender anderer Benutzer zugreifen. Auch die Macintosh- und 16-Bit-Windows-Outlook-Clients basieren auf MAPI, bieten jedoch nur einen Teil der Features, die im 32-Bit-Windows-Outlook-Client verfügbar sind. So können zum Beispiel 32-Bit-Outlook-Formulare auf Macintosh- oder 16-Bit-Windows-Plattformen nicht ausgeführt werden. POP3 und IMAP4 Die POP3- und IMAP4-Internetstandards sind reine Download- oder Empfangsprotokolle: Sie rufen Nachrichten mit den Protokollen POP3 bzw. IMAP4 ab, senden jedoch Nachrichten mithilfe des SMTP (Simple Mail Transfer Protocol)-Protokolls. Dies kann sich erheblich auf die Exchange Server-Leistung auswirken, da diese Clients Nachrichten von einem Server empfangen (der als Host für ihre Postfächer fungiert) und Nachrichten über einen anderen Server senden (der den Internet Mail Service unterstützt). Die Verarbeitungsanforderungen an den ExchangePostfachserver verringern sich so um die Hälfte. Da POP3-Clients Nachrichten nicht auf einem Exchange-Server speichern können, speichern sie sie auf dem Clientcomputer und verringern dadurch die Speicheranforderungen auf dem Server. Dies verringert auch die Verarbeitungsanforderungen an den Server, da die Aktionen zum Abrufen und Verarbeiten der Nachricht auf dem Client erfolgen. POP3-Clients arbeiten ähnlich wie Outlook- oder Exchange-Clients im Offlinemodus. Ein Client, der E-Mail-Nachrichten gedownloadet hat, führt alle Verarbeitungsschritte auf der lokalen Festplatte durch. Der Server ist an der Bearbeitung und Löschung dieser Nachrichten nicht mehr beteiligt. IMAP4-Clients können vor dem Downloaden eine Vorschau der Nachrichtenkopfzeilen anzeigen, was Remotebenutzern eine Menge Zeit sparen kann, indem zum Beispiel der Download einer 5 MB-Datei über eine RAS-Verbindung auf einen späteren Zeitpunkt verschoben wird. OWA Bei OWA-Clients muss der Internet Information Server (IIS)-Computer die Verarbeitungsanforderungen erfüllen (die sehr hoch sein können). Wenn IIS und Exchange Server auf verschiedenen Computern ausgeführt werden, zeigen Tests, dass Sie die Antwortzeit erheblich verringern können, indem Sie mehr als 700 OWA-Benutzer auf einem einzigen IISServer mit vier Prozessoren und 512 MB Arbeitsspeicher (RAM) verarbeiten. Wenn sich IIS und Exchange auf demselben Computer befinden, verringert sich die Leistungssteigerung erheblich. Ein OWA-Benutzer belastet Exchange Server, wenn es nicht auf demselben Computer wie IIS ausgeführt wird, weniger als ein Outlook-Benutzer. Dies liegt daran, dass die zahlreicheren Features von Outlook für Benutzer von Exchange Server mehr Möglichkeiten zulassen als OWAClients. Verwendung Öffentlicher Ordner und Replikation Öffentliche Ordner können sich erheblich auf die Exchange Server-Leistung auswirken. Dies hängt von der Ordnergröße, der Häufigkeit von Benutzerzugriffen, der Anzahl verschiedener Ansichten für jeden Ordner, der Anzahl der Replikate, dem Replikationszeitplan und der Häufigkeit von Inhaltsänderungen ab. Große Öffentliche Ordner verbrauchen viel Speicher und benötigen mehr Datenträger-E/A zum Lesen. Wenn viele Benutzer häufig auf einen Ordner zugreifen, ist der Server ständig mit der Bearbeitung dieser Anforderungen beschäftigt. Für jeden Benutzer verfolgt der Öffentliche Ordner auch den Erweiterungsstatus aller seiner Ordner und den Gelesen/Ungelesen-Status aller Nachrichten nach. Zwar ist die Replikation Öffentlicher Ordner schnell (erste Tests ergaben, dass zum Replizieren von 1.000 1-KB-Nachrichten zwischen zwei Servern nur 61 Sekunden benötigt werden), doch erfolgt sie in Schüben, da Änderungen gesammelt und nach dem vom Administrator festgelegten Zeitplan repliziert werden. Das Replikationsintervall kann bis auf 15 Minuten verringert werden (Einstellung: IMMER). Benutzer, die auf einen Ordner zugreifen, stellen eine plötzliche Verlangsamung fest, wenn die Replikation beginnt. Die Verlangsamung hält an, bis die Replikation abgeschlossen ist. Das Aktualisieren vieler Ordner belastet den Server mehr, und Verzögerungen durch Replikationsschübe häufen sich. Öffentliche Ordner können Nachrichten und eigenständige Dokumente enthalten. Eigenständige Dokumente verursachen mehr Verwaltungsaufwand als Nachrichten, da sie meistens groß oder sehr groß sind. Wenn Sie zum Beispiel mit Drag & Drop eine 1 MB-Datei in einem Öffentlichen Ordner speichern, werden bei jedem Benutzerzugriff auf diese Datei 1 MB Daten über das Netzwerk gesendet. Wenn sich das entsprechend häufig wiederholt, kann sich dies natürlich auf die Serverleistung auswirken. Ein weiteres Leistungsproblem kann sich aus dem Zwischenspeichern ergeben. Daten durchlaufen auch den Puffercache, der die am häufigsten verwendeten Daten enthält, die in die Datenbank geschrieben oder aus ihr gelesen wurden. Wenn ein Benutzer die oben erwähnte 1 MB-Datei im Öffentlichen Ordner öffnet, werden 1 MB anderer Daten aus dem Puffercache entfernt. Wenn ein Benutzer nun versucht, auf die entfernten Daten zuzugreifen, muss Exchange Server sie wieder vom Datenträger lesen. Benutzer bemerken es auch, wenn ein Standort über eine langsame Verbindung mit einem Replikat eines Öffentlichen Ordners auf einer der Seiten verbunden ist. Diese Situation kann wegen des Algorithmus, den Exchange zum Verbinden eines Benutzers mit dem Replikat eines Öffentlichen Ordners verwendet, zum Dauerzustand werden. Wenn ein Benutzer Zugriff auf einen Öffentlichen Ordner anfordert, überprüft Exchange den Homeserver des Benutzers nach dem Ordner. Wenn Exchange weder ein Replikat noch einen Zeiger auf einen Server für Öffentliche Ordner für alle Benutzer auf diesem Exchange-Server findet, überprüft es andere lokale Server. (Dieses neue Feature - Standortfeld, allgemein auch Substandorte genannt -verleiht ExchangeAdministratoren mehr Kontrolle über den Benutzerzugriff auf Öffentliche Ordner. Wenn Exchange den Ordner dort nicht findet, leitet es den Client nach dem Zufallsprinzip weiter auf einen Standortserver mit einem Replikat des Ordners, wobei dieses Weiterleiten möglicherweise über eine langsame Verbindung verläuft. Für jeden Benutzer erhält Exchange den Gelesen/Ungelesen-Status jeder Nachricht und den Erweiterungsstatus jedes Ordners in der Hierarchie aufrecht. Es speichert diese Informationen im Öffentlichen Ordner auf einem bestimmten Server. Exchange muss den Benutzer immer wieder zu demselben öffentlichen Ordnerreplikat weiterleiten, um diese Informationen synchron zu halten. Sobald der Benutzer einmal über die langsame Verbindung verbunden ist, wird diese Verbindung von diesem Zeitpunkt an verwendet. Exchange-Administratoren müssen Strategien für Öffentliche Ordner sorgfältig entwerfen, indem sie das Standortfeld verwenden und die Standorttopologie richtig konfigurieren, um dieses potenzielle Leistungsproblem zu vermeiden. Exchange Server unterstützt jetzt auch NNTP (Network News Transfer Protocol), was sich auch auf die Verwendung Öffentlicher Ordner auswirkt. Erstens vereinfacht NNTP es Administratoren, einen Öffentlichen Ordner zum Importieren der Millionen von Nachrichten einzurichten, die sich im Internet finden lassen. Dies kann offensichtlich den Speicherbedarf erhöhen. Zweitens können Administratoren externen NNTP-Benutzern erlauben, sich Öffentlichen Ordnern anzuschließen. Der Netzwerkverkehr kann erheblich zunehmen, wenn externe Benutzer die Ordner frequentieren. Drittens können NNTP-Newsgroups größer als 40 GB sein. Diese Öffentlichen Ordner sollten nach Möglichkeit auf einen dedizierten Server verlagert werden, um Ihr System vor unvorhersehbaren Belastungen zu schützen. Regeln und Ansichten Regeln sind benutzerdefinierte Aktionen, die ein Server durchführt: Popupbenachrichtigungen, wenn Nachrichten von einer bestimmten Person eingehen, automatisches Verschieben von Nachrichten in Ordner je nach Betreffzeile usw.. Tests ergaben, dass die Regelverarbeitung sich kaum auf die Leistung auswirkt, es sei denn, jeder Benutzer hat Dutzende von Regeln eingerichtet. Ansichten erfordern, dass der Server Indices speichert und nachverfolgt. Die am häufigsten verwendeten Ansichten werden im Cache gespeichert. Benutzer bemerken möglicherweise eine geringerfügig langsamere Leistung, wenn sie auf eine selten verwendete Ansicht zugreifen. Auch diese Leistungseinbuße ist minimal. Elektronische Formulare Elektronische Formulare werden prinzipiell wie alle anderen Nachrichten behandelt. Wenn ein Formular zum ersten Mal verwendet wird, muss es der Client jedoch in den lokalen Formularcache downloaden, um es ausführen zu können. Dies ist ein einmaliger Vorgang, der nur bei einer Formularänderung erneut erforderlich ist. Wenn ein neues Formular an viele Benutzer gesendet wird und diese versuchen, es gleichzeitig auszuführen, kann die Belastung erheblich sein. Zeitplanung Der Outlook-Kalender und der alte Schedule+-Client verwenden einen verborgenen Öffentlichen Ordner, um die Frei- und Belegt-Informationen zu replizieren. Standardmäßig ist dieser Ordner auf dem ersten an einem Standort installierten Server gespeichert. Von Zeit zu Zeit muss der Administrator Replikate einrichten, um stärkere Benutzerlasten zu unterstützen. Diese steigern den Replikationsverkehr und die Wartezeit bei der Aktualisierung der Frei-/Belegt-Informationen. Standardmäßig können alle Benutzer an einem Standort Frei-/Belegt-Informationen aller anderen Benutzer am Standort anzeigen. Der Administrator muss die Replikation von Frei-/BelegtOrdnern zwischen Standorten einrichten. Diese Funktionalität kann sich auf die Exchange Server-Leistung auswirken. Sind dedizierte Ressourcen erforderlich? Momentan verwendet Microsoft vier dedizierte Frei-/Belegt-Server (jeder mit vier Prozessoren und großem Arbeitsspeicher (RAM) und Festplattenspeicher) zur Verwaltung von über 40.000 Benutzern. Das Leistungsproblem beim älteren Schedule+-Client hängt in erster Linie davon ab, ob der Benutzer mit einer lokalen Zeitplandatei arbeitet. Ist dies der Fall (Standard), reagiert Schedule+ sehr schnell und aktualisiert die Zeitplaninformationen auf dem Server regelmäßig äußerst effizient. Wenn ein Benutzer jedoch nicht mit einer lokalen Zeitplandatei arbeiten möchte, erfordert jede Zeitplanänderung eine Interaktion mit dem Server. Schedule+ wurde als eigenständige Anwendung ohne Zuhilfenahme eines Servers entworfen. Es arbeitet daher zuerst immer mit einer lokalen Datei und aktualisiert dann den Server, statt nur mit dem Server zusammenzuarbeiten. Einzelne Benutzer, die nicht mit lokalen Zeitplandateien arbeiten, bemerken einen Leistungsabfall. Wenn eine bestimmte Anzahl von Benutzern auf diese Weise arbeiten, können alle Benutzer davon betroffen sein. Der Outlook-Kalender ist stärker in den E-Mail-Client integriert und verwendet denselben Speicherort wie die übrigen Nachrichten. Wenn Outlook-Benutzer, die mit Exchange Servern zusammenarbeiten, ihr serverbasiertes Postfach als Standardübermittlungsort festlegen, speichert Outlook alle Kalenderinformationen im Ordner Kalender ihres Postfachs auf dem Exchange Server. Dieser Ordner kann auch zur Offlineverwendung eingerichtet werden. In diesem Fall werden die Frei-/Belegt-Informationen anderen verfügbar gemacht. Wenn Benutzer einen Persönlichen Ordner (PST-Datei) als Standardübermittlungsort auswählen, werden dort alle Kalenderinformationen gespeichert, so dass Frei-/Belegt-Informationen für andere nicht verfügbar sind. Um Kalenderdetails und Frei-/Belegt-Informationen mit anderen gemeinsam zu verwenden, müssen Benutzer ihre serverbasierten Postfächer als Standardübermittlungsort festlegen. MAPI-Anwendungen Es ist schwierig, die Auswirkung von MAPI-Anwendungen auf einen Exchange Server zu messen, da jede Anwendung anders ist. Ein Grund für die geringe Leistung von MAPIAnwendungen ist die ineffiziente Verwendung von RPCs bei der Kommunikation mit dem Server. Dies kann durch Stapelverarbeitungsfunktionen vermieden werden, damit mehrere Aktionen in einem RPC gesendet werden. Das Exchange Development Team (Exchange-Entwicklungsteam) fand dies heraus, als es das Standard-read note entwickelte. So waren zum Abrufen und Anzeigen einer Nachricht 14 RPCs erforderlich. Bei einem Benutzer spielte dies keine Rolle; wenn jedoch 250 Benutzer auf einem Exchange Server jeweils 14 RPC-Aufrufe zum Abrufen und Anzeigen einer Nachricht erteilen würden, wäre die Leistungsanforderung sehr groß. Das Exchange-Performance Team (das bei der Verbesserung der RPC-Effizienz im Exchange-Code half) entwarf die Funktion neu, so dass sie nur noch 2 RPCs verwendete. Der gesamte Client/Serveranwendungscode sollte im Hinblick auf hohe Leistung geschrieben sein. Selbst ein kleines Teil an schlecht konzipiertem Code kann die Leistung erheblich verschlechtern, wenn er von entsprechend vielen Benutzern ausgeführt wird. Connectors und Gateways Connectors und Gateways werden auf dem Server ausgeführt und bewerben sich mit anderen Exchange-Prozessen um Ressourcen, einschließlich dem Informationsspeicher. Sie arbeiten in Schüben und können die Leistung vorübergehend verschlechtern. Exchange Server ist so entworfen, dass sie einem bestimmten Connector oder Gateway, der/das Leistungsprobleme verursacht, problemlos einen bestimmten Computer zuweisen oder eine zweite Instanz an anderer Stelle am Standort hinzufügen können. Exchange Server behandelt Standorte als Einheiten, so dass diese Optionen für Benutzer transparent sind. Verzeichnisse, Replikation und der Replikationshub Ein Replikationshub fungiert als Tor zum und aus dem Standortverzeichnis. Wenn der Administrator einen Verzeichnisreplikationsconnector zwischen Standorten konfiguriert, weist er an jedem Standort einen Server als Replikationshub zu. Dieser ist zum Austausch von Verzeichnisaktualisierungen mit seinem Gegenstück verantwortlich. Innerhalb eines Standorts ist die Verzeichnisreplikation proportional zur Anzahl der Verzeichnisänderungen. Sie dürfte sich nur bei der Systemumstellung (Migration) auf Exchange Server (wenn sich das Verzeichnis häufig ändert) zu bemerken sein oder in Organisationen, in denen täglich Hunderte von Verzeichnisaktualisierungen erfolgen. MTA Der Message Transfer Agent (MTA) leitet in erster Linie Nachrichten zwischen Servern weiter. Selbst in Systemen mit einem einzigen Server übernimmt er jedoch noch andere Aufgaben, wie z. B. die Erweiterung von Verteilerlisten und Routing ausgehender Gateway- oder Connectornachrichten. Er wirkt sich am stärksten in Umgebungen mit mehreren Servern aus. Doch selbst in Konfigurationen mit einem einzigen Server leitet er bestimmte Verarbeitungsschritte ein. Exchange Server 5.5 verbessert die MTA-Leistung insgesamt. Seine Datenbankwarteschlange wurde optimiert, um Skalierbarkeitsprobleme abzuschwächen, die Exchange 4.0 durch Sperren der Datenbankwarteschlangen-Objekte im Arbeitsspeicher (RAM) löste. Exchange Server 5.5 ersetzt im Wesentlichen alle Zugriffe auf die Datenbankwarteschlange durch einen viel einfacheren und effizienteren RAM-basierten Warteschlangenmechanismus. Das Programm verwendet das Datenbankwarteschlangen-Format nur beim Backup von sicheren Warteschlangeninformationen auf der Festplatte, wenn der Server einwandfrei heruntergefahren wird oder bei der MTA-Überprüfungsverarbeitung, damit diese beim nächsten MTA-Start wieder in den Arbeitsspeicher (RAM) geladen werden können. Mehrere andere Exchange 5.5-Features verbessern die Verwendung des zugrundeliegenden Dateisystems durch den MTA: Zwischenspeichern von Dateizugriffsnummern und gelöschten Objekten sowie direkte E/A bei vollen Puffern. Zum Zwischenspeichern von Dateizugriffsnummern und gelöschten Objekten wird eine neue objektbezogene Bitzuordnung verwendet, um Dateien beim Schließen zu sammeln und zu löschen. Der Exchange Server 5.5MTA optimiert außerdem interne Einstellungen des Datenbankservers und die MTADatenbankverwendung, um mehr Nachrichten schneller zu routen. Durch die Aktualisierung auf Exchange 5.5 wird die MTA-Leistung gesteigert, so dass ein Server für mehr Benutzer als Host fungieren kann, ohne die Last zu erhöhen. Server-Scriptingagent und Routingobjekte Exchange Server 5.5 unterstützt jetzt serverseitige Skripterstellung unter Verwendung eines Scriptingagenten, mit dem Entwickler ereignis- oder zeitgesteuerte Formularanwendungen mit VBScript oder JavaScript erstellen können. Diese Skripts werden tatsächlich auf dem Exchange Server ausgeführt, so dass Entwickler effiziente und optimierte Skripts schreiben müssen. Um die Installation schlechter Skripts zu verhindern (z. B. eines Skripts, das jede Nachricht in einem Informationsspeicher stündlich überprüft), legt der Administrator fest, wer sie auf einem Server speichern darf. Die Exchange-Routingobjekte (Exchange Server 5.5 Service Pack 1) sind eine Reihe von Komponenten, die auf der Ereignis- und Skriptarchitektur von Exchange Server 5.5 aufbauen, um die Entwicklung von Routing- und Genehmigungsanwendungen zu vereinfachen. Zu den Komponenten gehören ein einfaches Routingmodul, Routingobjekte, ein Programmierhandbuch und Beispielanwendungen. Auch hier müssen Entwickler Anwendungen mit Sorgfalt erstellen. Zusammenarbeit in Echtzeit Exchange Server 5.5 unterstützt Chat. Zwar ist das Chatprotokoll etwas klein ausgefallen, doch ermöglicht es der Exchange 5.5-Chatdienst einem Exchange-Server, als Host für bis zu 10.000 Onlinebesprechungen und Echtzeitdiskussionsclients gleichzeitig zu fungieren. Wenn diese Art von Aktivität so beliebt wird, dass sie die Systemleistung beeinträchtigt, isolieren Sie diesen Dienst auf einen dedizierten Server. Der Outlook 98-Client enthält NetMeeting, mit dem Benutzer Onlinebesprechungen einrichten und planen können. Dies hat normalerweise keinen Einfluss auf die Exchange Server-Leistung, kann jedoch die Bandbreite verringern, wenn es viele Teilnehmer gibt und diese Audio, Video und die gemeinsame Verwendung von Anwendungen ausführen. Andere Serveraktivitäten Die vom Performance Team durchgeführten Tests erfolgten auf einem reinen Exchange Server, d. h. einem Exchange Server, der auf einem Computer unter Windows NT Server 4.0 installiert wurde, der Mitgliedsserver war und auf dem sonst keine anderen Programme ausgeführt wurden. In der Praxis ist dies selten der Fall. Windows NT Server ist dafür entworfen worden, mehrere Serveranwendungen auf einem Computer auszuführen. Dies kann sich - unter Umständen sogar drastisch - auf die Leistung dieses Servers auswirken. Es wäre zu kompliziert, die Auswirkung aller Windows NT Server-Anwendungen auf die Leistung von Exchange Server zu bewerten, doch gibt es eine Faustregel: Das gleichzeitige Ausführen von Anwendungen wirkt sich auf die Serverleistung nur aus, wenn die Anwendungen ressourcenintensiv sind. Wenn der Server zum Beispiel als Windows NT-Domänencontroller, WINS-Server oder DHCP-Server in Umgebungen verwendet wird, in denen wenige Clientaktivitäten diese Dienste anfordern, beeinträchtigen diese Dienste die Leistung kaum. Durch die gleichzeitige Ausführung von Microsoft Systems Management Server, SQL Server oder SNA Server kann die Leistung jedoch stark beeinträchtigt werden. Netzwerkqualität und Konnektivität Die Client/Serverleistung kann durch die Qualität des zugrundeliegenden Netzwerks bestimmt werden. Exchange Server bietet in einem 100 MB/s-Fiber Distributed Data Interface (FDDI)-Ring bessere Konnektivität und Leistung als in einem Token Ring-Netzwerk oder beim Anschluss an ein überlastetes Ethernetsegment, in dem sehr viele Kollisionen auftreten. Berücksichtigen Sie WAN-Konnektivität und -Qualität insbesondere beim Berechnen von Standortgrenzen, und wenn Sie entscheiden, ob Clients auf ihre Exchange Server über das WAN zugreifen können. Ermitteln der Grenzwerte Exchange Server verfügt praktisch über kein Limit bei Benutzern pro Server, doch können (oder sollten) andere Faktoren die Konfiguration einschränken. Vor Exchange 5.5 konnten die öffentlichen und privaten Informationsspeicher-Datenbanken jeweils 16 GB nicht übersteigen. Auf großen Servern bedeutete dies oft den oberen Grenzwert für Benutzer pro Server, je nachdem, wie viel Serverspeicher für Benutzern zugelassen wurde, wie viele Einzelinstanzen von Nachrichten und Anlagen die logische Speicherkapazität des Servers vergrößerte, wie oft Speicher für persönliche Ordner verwendet wurden und (in geringerem Maße) wie viele Regeln, Ansichten und Finder Benutzer auf dem Server definierten. Der Speicher von Exchange Server 5.5 ist unbegrenzt. Planer müssen jetzt überlegen, wie viel Festplattenspeicher auf einem einzigen Computer konfiguriert werden kann und wie lange es dauert, Daten zu sichern oder wiederherzustellen. Onlinebandsicherungs-Hardware kann 25 bis 40 GB pro Stunde sichern, wobei Wiederherstellungsraten in etwa die Hälfte davon betragen. Trotzdem kann eine große Sicherung oder Wiederherstellung sehr Zeit raubend sein. Weitere Informationen finden Sie unter "The Limits of Unlimited Information Store" (englischsprachig). . Es gibt aber auch immaterielle Faktoren. Sie können mehrere Tausend Benutzer auf einem Exchange Server verwalten, doch fühlen Sie sich gut dabei? Wenn die Hardware versagt (das passiert), sind mehrere Tausend Benutzer auf einen Schlag arbeitslos. Der neue unter Window NT Server 4.0 Enterprise Edition verfügbare Microsoft Clustering Server kann die Hardwarezuverlässigkeit erhöhen und lässt Sie möglicherweise besser schlafen. Abgesehen vom Immateriellen: Wie bestimmen Sie, wie viele Benutzer jeder Server verarbeitet? Diese Abschnitt liefert die notwendigen Informationen. Die Berechnung der Anzahl von Benutzern pro Server verläuft in vier Schritten: Abgesehen vom Immateriellen: Wie bestimmen Sie, wie viele Benutzer jeder Server verarbeitet? Diese Abschnitt liefert die notwendigen Informationen. Die Berechnung der Anzahl von Benutzern pro Server verläuft in vier Schritten: Optimieren des Servers (einschließlich Hardware und Exchange Server-Konfiguration) Klassifizieren von Benutzern und Festlegen ihrer Leistungsansprüche Verwenden von Load Simulator (für MAPI-Clients) oder InetLoad (für POP3/IMAP4Clients) zum Testen von Konfigurationen mit Benutzerdaten Analysieren der Ergebnisse Sollten Sie alle Laufwerke in einem Stripeset zusammenfassen oder separate Partitionen für unterschiedliche Serverkomponenten konfigurieren? Wieviel Speicher sollten Sie für den Puffercache reservieren? Es gibt natürlich noch weitere Fragen. Dieser Abschnitt hilft bei ihrer Beantwortung. Optimieren der Serverhardware Drei Hardwarefeatures wirken sich auf Exchange Server aus. CPUs CPUs arbeiten mit bestimmten Geschwindigkeiten, die Sie nicht optimieren können. Die Leistung wird dadurch bestimmt, über wie viele CPUs Sie verfügen und von welchem Typ diese sind. Bei Leistungstests von Microsoft wurde festgestellt, dass Exchange 4.0 und 5.0 sich für mehr als 4 CPUs nicht gut skalieren lassen, während Exchange 5.5 sich für bis zu 8 Intel Pentium- oder Digital Alpha-CPUs skalieren lässt. Konfigurationen mit mehr CPUs steigern die ExchangeLeistung nicht, und Sie können die CPUs ohne weiteres anderweitig verwenden. Für den CPUTyp gilt: Je schneller desto besser. Ein Pentium 233-Chip ist schneller als ein Pentium 200 und sehr viel schneller als ein 486/66. Windows NT Server lässt eine Optimierung zu, die das Verwenden von CPUs durch den Server beeinflusst. Öffnen Sie in der Systemsteuerung das System-Dienstprogramm, und klicken Sie auf die Registerkarte Leistungsmerkmale. Legen Sie Ausführen von Anwendungen auf Keine fest. Dies erhöht die Systemprioritäten, die Windows NT Server Hintergrundaufgaben zuweist (alle Exchange Server-Dienste sind Hintergrundaufgaben). Speicher Auch den Speicher können Sie nicht entscheidend optimieren, doch verwendet Exchange Server den gesamten ihm zugewiesenen Speicher bis zur Gesamtgröße Ihres Informationsspeichers (falls Sie aus irgendwelchen Gründen die gesamte Datenbank in den Arbeitsspeicher (RAM) schreiben möchten). Exchange Server verwendet den Großteil des zugewiesenen Speichers für einen Puffercache, der für den Informationsspeicher bestimmte Daten zur Verarbeitung in Zeiten geringer Last aufnimmt. Ein Exchange Server benötigt mindestens 24 MB Arbeitsspeicher (RAM). Wenn der Arbeitsspeicher auf 64 bis 128 MB vergrößert wird, verbesserte sich die Leistung im Test in höherem Maße als durch Aktualisieren der CPUs. Es gibt eine Möglichkeit, die Verwendung von Windows NT Server-Speicher zur Unterstützung von Exchange Server zu optimieren: Legen Sie in der Systemsteuerung im NetzwerkDienstprogramm den Serverdienst auf Durchsatz für Netzwerkanwendungen maximieren fest. Konfigurieren Sie im System-Dienstprogramm der Systemsteuerung eine größere Auslagerungsdatei für virtuellen Speicher. Als Faustregel gilt: 125 MB + Größe des physischen Arbeitsspeichers. Wenn z. B. der Server über 64 MB Arbeitsspeicher (RAM) verfügt, legen Sie die Größe der Auslagerungsdatei auf (125+64) MB oder 189 MB fest. Datenträger-E/A-Subsystem Eine Optimierung des Datenträger-E/A-Subsystems bringt sehr viel. Zunächst einige Hintergrundinformationen. Servertransaktionsprotokolle: sequenzieller Zugriff ist von Vorteil Exchange Server verwendet E/A-Anforderungen beim Serverdatenträger-Subsystem zum Einlesen von Daten von der Festplatte in den Arbeitsspeicher oder zum Schreiben von Daten in permanenten Speicher. Wenn Sie z. B. Ihren Posteingang öffnen, müssen ungefähr für die ersten zwanzig Nachrichten im Posteingang die Eigenschaften der Standardordneransicht gelesen und an Sie zurückgegeben werden. Wenn diese Informationen bei einem kürzlich erfolgten Zugriff noch nicht im Cache des Servers gespeichert wurden, müssen sie aus der Informationsspeicherdatenbank des Servers auf der Festplatte gelesen werden. In diesem Fall erfolgt die Datenträger Lesen-E/A synchron mit dem Öffnen des Postfachs. In ähnlicher Weise muss eine Nachricht, die von einem anderen Server übertragen wurde, auf dem Datenträger gespeichert werden, bis ihr Empfang bestätigt wurde (dies verhindert den Verlust von Nachrichten bei Systemausfall). In diesem Fall erfolgt die Datenträger Schreiben-E/A synchron mit der Hintergrundaktion zum Übertragen und Akzeptieren der Nachricht. Die von Microsoft Exchange Server veranlassten Datenträger-E/As sind entweder Lesevorgänge oder Schreibvorgänge und synchron oder asynchron. Während alle Lese-E/As und asynchronen Schreib-E/As als wahlfrei angesehen werden können, sind viele der von Exchange Server veranlassten synchronen Schreibvorgänge sequenziell. Um Aktionen zu beschleunigen, die synchrone Schreib-E/A benötigen, verwendet Exchange daher eine spezielle Methode zum Schreiben von Änderungen auf den Datenträger: das sequenzielle Write-AheadTransaktionsprotokoll. Die Transaktionsprotokollarchitektur wird durch das Entwerfen aktueller Festplattenlaufwerke beeinflusst. Die Suchzeit (die Zeit, die es dauert, den Plattenkopf von einer Position zu einer anderen zu bewegen, Daten zu lesen oder zu schreiben) ist von entscheidender Bedeutung für die wahlfreie Datenträger-E/A-Geschwindigkeit. Wenn die E/A auf dem Laufwerk sequenziell statt wahlfrei erfolgt, sinkt die Suchzeit nahezu auf Null, was die Anzahl der Datenträger-E/As pro Sekunde drastisch erhöht, die das Laufwerk unterstützen kann. Wenn die Informationsspeicher-Transaktionsprotokolle auf eigenen physischen Festplatten ohne jede andere Ursache für Datenträger-E/A gespeichert sind, hat dies auf allen Exchange ServerKonfigurationen mit Ausnahme der Minimalkonfiguration mit einem einzigen Laufwerk den größten Einfluss auf die Exchange Server-Leistung Fast gleichbedeutend ist die Verwendung des FAT-Dateisystems, da es mit sequenzieller Aktivität am meisten leistet. (Wenn das Protokoll 2 GB übersteigt, müssen Sie NTFS verwenden.) Die Beseitigung anderer Ursachen für Datenträger-E/A vom Laufwerk ist sehr wichtig: Zwar wird das Transaktionsprotokoll sequenziell geschrieben, doch bewegen andere E/A-Anforderungen den Plattenkopf von der Protokolldatei weg, wodurch sich Suchzeiten vergrößern. Dies gilt sogar für Leseaktionen, bei denen oft auch Schreiben in das InformationsspeicherTransaktionsprotokoll des Servers erforderlich ist. Wenn Sie zum Beispiel eine Nachricht lesen, ist sie nicht mehr als ungelesen gekennzeichnet, und die Anzahl der ungelesenen Objekte im Ordner wird aktualisiert. Auch der Exchange Server-Verzeichnisdienst verwendet die Write-Ahead-Protokollarchitektur, doch sind Änderungen am Verzeichnisdienst so selten, dass normalerweise die Ausgaben für ein ein separates physisches Plattenlaufwerk nicht notwendig sind. Eine Ausnahme bildeten Server, auf denen eine große Zahl von Verzeichnisdienständerungen erfolgen, wie z. B. Server, die für große Verzeichnisimporte verwendet werden. E/A mit wahlfreiem Zugriff: nur Nachteile? Mit Ausnahme von Transaktionsprotokollaktivitäten ist die Exchange Server-Datenträger-E/A eher wahlfrei. Dies schließt die Windows NT-Auslagerungsdatei, Serverdatenbanken, Nachrichtentrackingprotokolle usw. ein. Da Serverkomponenten jedoch separate Aufgaben bearbeiten, generieren sie unterschiedliche Datenträger-E/A-Volumen. Wenn z. B. eine Nachricht von einem anderen Server empfangen und an einen Benutzer übermittelt wird, speichert der MTA zunächst die Nachricht auf dem Datenträger in seiner temporären Datenbank. Dies verursacht einen einzigen wahlfreien Schreibvorgang in das Verzeichnis MTADATA. Er ruft dann die Systemaufsicht auf, die einen Eintrag im Nachrichtentrackingprotokoll vornimmt. Der MTA informiert dann den Informationsspeicher darüber, dass eine Nachricht zur Verfügung steht. Nun empfängt der IS die Nachricht vom MTA und schreibt sie in seine eigene permanente Datenbank. Dadurch wird synchrone Schreib-E/A in das IS-Transaktionsprotokoll generiert sowie asynchrone Lese- und Schreib-E/A in die Informationsspeicherdatenbank im Verzeichnis MTADATA. Während dieser Zeit können auch Seitenfehler aufgetreten sein, wenn das System über wenig Speicher verfügt. Dadurch werden zusätzliche E/As zur NT-Auslagerungsdatei oder zu ausführbaren Dateien hinzugefügt. Sie können daher die wahlfreie E/A-Leistung des Servers steigern, indem Sie andere Systemplattenlaufwerke verwenden, um die E/A-Rate auf den Partitionen zu erhöhen, auf dem diese wahlfreien E/As auftreten. Da die Aktivitätsursachen schwanken, kombinieren Sie am besten die restlichen Plattenlaufwerke in einem Software- oder Hardwarestripeset, um die kombinierte Kapazität allen Serverkomponenten zur Verfügung zu stellen, die sie benötigen. Und was ist mit der Auslagerungsdatei? Das System lagert Seiten aus, wenn die auf dem Windows NT-Computer ausgeführten Prozesse (einschließlich Windows NT selbst) mehr Code- und/oder Datenseiten benötigen als im physischen Speicher vorhanden sind. Wenn ein Exchange Server-Computer nur über 24 MB Speicher für 50 bis 100 Benutzer verfügt, muss er bereits auslagern, um normale Exchange-Aufgaben zu bearbeiten, wie z. B. Bearbeiten von Benutzeranforderungen, Verschieben von Nachrichten vom/auf den Server usw.. Das macht einen erheblichen Anteil der gesamten Datenträger-E/A aus. Die Auslagerung ist erforderlich, da nicht alle zur Ausführung erforderlichen Teile (Workingsets) der Exchange Server- (und Windows NT Server)-Prozesse auf einmal in den physischen Speicher gespeichert werden können. Wenn der Standort über nur einen Server und wenig vom Server ausgehenden Verkehr verfügt, muss der MTA wenig bearbeiten (ausgenommen gelegentliches Erweitern von Verteilerlisten). Er kann sich dann zurückziehen und mehr Platz für die restlichen Serverprozesse zur Verfügung stellen, wodurch weniger Seiten ausgelagert werden müssen. Die Seitenauslagerung nimmt zu, wenn der Server außer den Exchange-Kerndiensten (wie z. B. Internet Mail Connector) weitere Prozesse ausführt, wie z. B. Importieren von Verzeichnisobjekten, Generieren des Offline-Adressbuchs, Starten der Serverdienste usw.. Wenn der Exchange-Server über genügend physischen Speicher verfügt, der groß genug für die meisten gleichzeitig von Serverprozessen benötigten Seiten ist, findet im Normalbetrieb kaum Seitenauslagerung statt. Selbst Computer mit 128 MB oder mehr Arbeitsspeicher lagern jedoch Seiten aus, insbesondere wenn die die Größe der Puffercaches(die im IS/DS-Workingset enthalten sind) für die RAM-Größe im Computer zu hoch festgelegt sind. Die ExchangeLeistungsoptimierung versucht, diese entsprechend festzulegen. Seitenauslagerungen finden oft in Schüben statt, so zum Beispiel, wenn eine große Nachricht durch das System bewegt wird und Speicherseiten ausgelagert werden müssen, um Platz dafür zur Vefügung zu stellen. Diese müssen dann wieder in den Speicher zurück geschrieben werden, nachdem weitergeleitet wurde. Und E/A ist generell zufällig über die Auslagerungsdatei verteilt. Deshalb ist es fast immer am besten, wenn das Stripset den Host für die Auslagerungsdatei bildet. Auf Computern mit geringem Arbeitsspeicher hat die Auslagerung einen erheblichen Anteil an der E/A, und ein Stripeset stellt ihr sämtliche verfügbare E/A-Kapazität zu Verfügung, was den Computer normalerweise beschleunigt. Computer mit wenig Arbeitsspeicher sind häufig von der Auslagerungsdatei behindert. Um dieses Problem zu vermeiden, ist jedoch mehr Arbeitsspeicher (RAM) und nicht mehr Festplattenspeicher erforderlich. Computer mit größerem Speicher lagern Seiten seltener aus, mit Ausnahme von Spitzenlasten, Startvorgängen usw.. Wenn Ihr Computer Seiten selten auslagert, können Sie die Auslagerungsdatei nahezu überall speichern, sogar auf dem Transaktionsprotokoll-Laufwerk, da darauf nicht häufig zugegriffen wird und mögliche Zugriffe mit den sequenziellen Aktivitäten des Protokolls nicht zu Konflikten führen. Es gibt jedoch keinen Grund, sich hier unvernüftig zu verhalten. Um Spitzenlasten in den Griff zu bekommen und Puffereinstellungen zu vereinfachen, speichern Sie sie einfach zusammen mit den Datenbanken auf der großen wahlfreien E/APartition. Sollte die Auslagerungsdatei eine eigene Festplatte bekommen? Nein. Wenn Seiten ausgelagert werden, ist die E/A-Leistung höher, wenn Sie dieses Laufwerk in das Stripeset aufnehmen und die Auslagerungsdatei darauf speichern. Wenn keine Seiten ausgelagert werden, würde dadurch ein Laufwerk verschwendet, das die wahlfreie E/A-Kapazität steigern könnte, wenn Sie es zum Stripeset hinzufügten. Wenn die Auslagerungsdatei auf dem Stripeset gespeichert wird, steht der Großteil des Datenträger-E/A-Subsystems allen Teilen des Systems (Auslagerungsdatei oder anderen) zur Vefügung, die wahlfreie Datenträger-E/A-Kapazität benötigten. Ausführen der Exchange-Leistungsoptimierung Langsame Serverantwortzeiten unter Last weisen meist auf einen Engpass bei einer der drei wichtigen Hardwareressourcen hin: CPU-Verarbeitungskapazität, Arbeitsspeicher (RAM) oder E/A-Subsystem. Der erste Schritt besteht nicht darin, den Arbeitsspeicher (RAM) zu vergrößern, sondern sicherzustellen, dass die Exchange Server-Software für Ihre Hardwarekonfiguration richtig konfiguriert ist. Exchange Server kann auf extrem leistungsschwachen bis zu extrem leistungsfähigen Computern ausgeführt werden; Sie müssen jedoch Konfigurationseinstellungen anpassen, um Exchange für die auszuführende Hardware zu optimieren. Die Microsoft Exchange-Leistungsoptimierung erkennt automatisch Ihre Serverhardware und passt hardwareabhängige Konfigurationseinstellungen an. Führen Sie die Optimierung immer aus, nachdem Sie Exchange Server auf Ihrer Serverhardware installiert oder Hardware hinzugefügt oder entfernt haben. Andernfalls funktioniert das System nicht optimal. In Kapitel 10, "Optimieren der Leistung“, im Microsoft Exchange Server 5.5 - Entwurfs- und Planungshandbuch finden Sie weitere Informationen über die Verwendung der Leistungsoptimierung. Benutzerdefinitionen Wenn Sie die Anzahl der Benutzer pro Server berechnen, müssen Sie Benutzergruppen so genau wie möglich beschreiben. Kapazitätsplanung ist keine exakte Wissenschaft: Sie verlässt sich auf intelligente Schätzungen. Wenn dies Ihr erstes Messagingsystem ist, haben Sie keine Erfahrungswerte zur Systemverwendung. Wenn Sie bereits andere Messagingprodukte verwendet haben, lässt sich der Einfluss der Funktionalität und Features von Exchange auf die Netzwerkbandbreite schwer messen. Sie können jedoch Load Simulator (LoadSim) iterativ verwenden und Ihre Schätzungen anhand verschiedener Szenarien und beobachteter Verwendungsmuster verfeinern. Die folgenden Tabellen können bei der Klassifizierung von Benutzern helfen. Das Exchange Performance Team hat nicht auf alle Fragen eine Antwort, und dies ist nicht das letzte Wort zum Thema "Benutzer pro Server". Es handelt sich lediglich um einige Testdaten in einer spezifischen Umgebung, die als grober Leitfaden dienen sollen. Das Exchange Performance Team definierte geringe, mittlere und starke Benutzer. Dies waren die Anfangsdaten: Parameter Gering Mittel Stark Anzahl der Nicht-Standardordner Anzahl der Nachrichten pro Ordner Anzahl der Nachrichten im Posteingang Anzahl der Nachrichten in Gelöschte Objekte 20 5 1 1 40 5 4 1 60 5 9 1 Diese LoadSim-Parameter definieren die Aktivitäten zur Klassifizierung der einzelnen Benutzer: Parameter Gering Mittel Stark Stunden pro Tag Verfassen neuer Nachrichten (nicht Antworten oder Weiterleiten) 1 KB Text (ups1k.msg) 2 KB Text (ups2k.msg) 4 KB Text (ups4k.msg) 10 KB Anlage (ups10kat.msg) Microsoft Excel-Anlage (upsXLatt.msg) Word-Anlage (upsWDatt.msg) Eingebettete Grafik (upsBMobj.msg) Eingebettetes Microsoft Excel-Objekt (upsXLobj.msg) Empfänger pro neue/weitergeleitete Nachricht Hinzufügen einer Verteilerliste zu Empfängern Lesen neuer Nachrichtenl Senden einer Antwort Senden einer Antwort an alle Weiterleiten Löschen (Verschieben in Gelöschte Objekte) Verschieben von Nachrichten Laden von Anlagen in gelesenen Nachrichten Max. Größe des Posteingangs (Anzahl von Nachrichten) Sonstige Verarbeitung älterer Nachrichten Schedule+ Änderungen Pro Tag empfangene Nachrichten (Durchschnitt) 8 8 8 2x 4x 6x 90 60 16 4 5 50 10 5 10 4 5 2 5 2 5 2 10 3 30 % 12x 5% 3% 5% 40 % 20 % 25 % 3 30% 12x 7% 5% 7% 40 % 20% 25% 3 30 % 12x 15 % 7% 7% 40 % 20 % 25 % 20 125 250 5x 1x 15x 5x 20x 10x 22.9 66.3 118.9 10 Serverdefinitionen Bei Exchange Server 4.0-Tests verwendete das Performance Team die folgenden Definitionen für einfache, mittlere und hochwertige Server: Arbeitls Festplattenko Servertyp Hersteller Prozessor speiche Netzwerkkarte nfiguration r (RAM) Einfach Server A Gateway 2000 1- 486/66 32 MB Server B Compaq Proliant 1 – 486/66 Mittel Server C Server D Compaq Proliant 2 – 486/66 64 MB Compaq Proliant 1 – Pentium 64 MB 32 MB 1 - 515 MB 1 - 1 GB 1 - 1 GB 1 - 2 GB 1 – 2 GB 1 – 2 GB Intel EtherExpress Pro Compaq Netflex II Compaq Netflex II Compaq Netflex II 90 1 - 8 GB Stripe Hochwertig 2 – 2 GB 8 – Pentium 1 – 24 GB Server E AT&T 3555 512 MB 90 Stripe 1 – 16 GB Auch dies sind lediglich Beispielangaben. 3Com Etherlink III Ausführen von LoadSim LoadSim kann nur unter Windows NT ausgeführt werden. Bei der Ausführung müssen die folgenden Punkte berücksichtigt werden: 1. Stellen Sie sicher, dass Sie Ihre Benutzer klassifiziert und die zu testenden Server eingerichtet haben. 2. Installieren Sie den entsprechenden Exchange-Client auf den Windows NTArbeitsstationen oder -Servern, die Sie als LoadSim-Clients verwenden möchten. 3. Ermitteln Sie die akzeptablen Antwortzeiten für Ihre Benutzer. Normalerweise ist 1 Sekunde (1.000 Millisekunden) ein geeigneter Wert, Sie können jedoch auch 1,5 Sekunden (1.500 Millisekunden) dafür ansetzen. 4. Verwenden Sie LoadSim zum Definieren der Testtopologie und zum Generieren der Benutzerimportdateien. 5. Verwenden Sie das Programm Exchange Server Administrator, um diese Benutzerdefinitionen in Ihr Exchange Server-Verzeichnis zu importieren. Dies muss auf allen zu testenden Servern geschehen. 6. Verwenden Sie LoadSim zum Definieren des Anfangszustands von Benutzern und Öffentlichen Ordnern. 7. Führen Sie die Tests Benutzerinitialisierung (User Initialization) und Öffentliche Ordner-Initialisierung (Public Folder Initialization) auf Ihrem Server aus, um den Exchange Server-Informationsspeicher mit Daten zu füllen. 8. Definieren Sie unter Verwendung der Benutzerklassifizierungen einige Tests, und führen Sie sie auf den verschiedenen Serverplattformen aus. Testen Sie z. B. 250 geringe Benutzer mit einem als mittel klassifizierten Server. Jeder LoadSim-Durchgang dauert mehrere Stunden und ergibt eine Zahl, die der zu 95 % gewichteten durchschnittlichen Antwortzeit in Millisekunden für jeden LoadSim-Benutzer dieses Testes entspricht. Testen Sie verschiedene unterschiedliche Benutzerzähler, um mehrere unterschiedliche Datenpunkte zu generieren, und erstellen Sie dann ein Diagramm der Ergebnisse. Beispiele von Ergebnissen finden Sie nächsten Abschnitt. Beispiele von LoadSim-Ergebnissen Die folgenden Tabellen zeigen Beispiele von LoadSim-Ergebnissen aus Tests, die von verschiedenen Anbietern durchgeführt worden. Hinweis Diese Informationen können jederzeit ohne Ankündigung geändert werden. Microsoft haftet nicht für das Ergebnis von Änderungen, Richtlinien oder Entscheidungen, die als Reaktion auf oder auf Basis dieser Daten oder aus ihnen gezogenen Schlüssen erfolgen. DIGITAL AlphaServer 4100 Diese LoadSim-Ergebnisse zeigen die maximale Anzahl der Benutzer, die Exchange Server 5.5 bei Verwendung des Exchange MAPI/RPC-Protokolls auf einem DIGITAL AlphaServer 4100 unterstützen kann, der mit einem, zwei und vier Prozessoren konfiguriert wurde. Die AlphaServer-Systeme wurden mit Exchange Server 5.5 in einer Konfiguration mit einem einzigen Server getestet (das bedeutet: mit einem eigenständiger Server, der die angegebene Anzahl von Clients unterstützt). Verwendete Serverkonfigurationen System Digital Alpha Server 4100 5/533 Anzahl der CPUs Festplattencontroller Logisches Laufwerk C: Logisches Laufwerk D: Logisches Laufwerk E: Logisches Laufwerk F: Physischer Speicher Virtuelle Auslagerungsdatei Netzwerkkarte Ergebnisse Anzahl der Prozessoren <4 4 SCSI-Adapter Adaptec 2940UW NTFS 2 GB RZ28 VW NTFS 4 GB RZ29B VW NTFS 28 x 4 GB RZ29B VW NT-Stripeset Raid 0 NTFS 3 x 4 GB RZ29B VW 2 GB 2.108.416 KB auf F:\ DEC PCI Fast Ethernet DECchip 21140(DE500) Max. Benutzer pro Server 95 %ige durchschnittliche Antwortzeit (ms) Nachrichtenempfänger Insgesamt übermittelte Nachrichten 1 2 4 4500 454 373.960 84.738 8000 608 643.662 145.914 10.000 509 831.774 190.106 Compaq ProLiant 6000 Diese Testergebnisse zeigen die 95 %ige durchschnittliche Antwortzeit, wenn für 9.000 Exchange Server 5.5-Benutzer unter Verwendung des Exchange MAPI/RPC-Protokolls ein mit vier Prozessoren konfigurierter Compaq ProLiant 6000-Server als Host fungiert. Ergebnisse Anzahl der Benutzer 9.000 95 %ige durchschnittliche Antwortzeit Insgesamt übermittelte Nachrichten (8 Stunden-Zeitraum) Protokoll Kanonisches LoadSim-Profil Plattform 336 Millisekunden (ms) 695.298 Exchange MAPI Mittel (typischer geschäftlicher Nachrichtenbenutzer) Compaq ProLiant 6000 (4) Intel Pentium Pro 200 MHz – 1 MB Cache; 3 GB Arbeitsspeicher (RAM) (2) SMART-2/DH Arraycontroller (18) 4,3 GB Wide-Ultra SCSI-Laufwerke Hewlett-Packard NetServer LXr Pro8 Hewlett-Packard Network Server Division in Cupertino, Kalifornien, verwendete LoadSim, um eine Belastung zu generieren, die die Skalierbarkeit des LXr Pro8 unter Exchange Server, Version 5.5, demonstrierte. Exchange-Benutzer wurden durch das Ausführen von LoadSim auf 35 Servern der HP NetServer E-Reihe simuliert, von denen jeder einzelne wiederum 400 Benutzer simulierte. Ergebnisse Anzahl der Benutzer 14.000 95 %ige durchschnittliche Antwortzeit Messagingprotokoll Kanonisches LoadSim-Profil Systemkonfiguration 336 Millisekunden (ms) Exchange MAPI Mittel (typischer geschäftlicher Nachrichtenbenutzer) Komponente Konfiguration Systemhersteller und Modell Hewlett-Packard NetServer LXr Pro8 Prozessoren Betriebssystem E/A-Subsystem 1: E/A-Subsystem 2-4: Verteilung der Dateien auf den Datenträgern Netzwerk (8) Intel Pentium Pro 200 MHz - 1 MB Cache; 4 GB Arbeitsspeicher (RAM) Microsoft Windows NT Server 4.0 Enterprise Edition mit SP3 Integrierter Ultra-Wide SCSI-Controller (1) D4910A 4 GB Fast-Wide, 7,2 KB RPM (3) American Megatrend, Inc. 434 Diskarraycontroller (29) D4903A 4 GB Ultra-Wide-SCSI-Laufwerke Laufwerk C: Betriebssystem - (1) 4 GB-Laufwerk - RAID0 Laufwerk D: DS, MTA und DS-Protokolldateien - (2) 4 GB-Laufwerke – RAID1 Laufwerk E: Windows NT-Auslagerungsdatei - (1) 4 GB-Laufwerk RAID0 Laufwerk F: Informationsspeicherprotokoll - (2) 4 GB-Laufwerke – RAID1 Laufwerk N: Informationsspeicher-Datenbank - (24) 4 GB-Laufwerke – RAID0 (3) HP J3171A 100 Base-TX IBM Netfinity 7000 Der IBM Netfinity 7000, in Rack- und Towerausführung verfügbar, ist ein symmetrischer 4-WegeMultiprocessing (SMP)-Server mit einem 200 MHz-Pentium Pro-Prozessor mit 1 MB oder 512 KB L2-Cache und bis zu 4 GB RAM. Diese Testergebnisse zeigen die 95 %ige durchschnittliche Antwortzeit, wenn für 10.000 Exchange Server 5.5-Benutzer unter Verwendung des Exchange MAPI/RPC-Protokolls ein mit vier Prozessoren konfigurierter IBM Netfinity 7000-Server als Host fungiert. Ergebnisse Anzahl der Benutzer 10.000 95 %ige durchschnittliche Antwortzeit 649 Millisekunden (ms) Übermittlung an 807.744 Nachrichten innerhalb von acht Stunden Nachrichtenempfänger insgesamt Messagingprotokoll Exchange MAPI Kanonisches LoadSim-Profil Mittel (typischer geschäftlicher Nachrichtenbenutzer) Serverkonfiguration Komponente Konfiguration Prozessoren Systemspeicher 4 200 MHz-Pentium Pro, 1 MB L2-Cache 3 GB 2 IBM ServeRAID II Ultra SCSI-Adapter mit Firmwareversion 2.40 und Festplattencontroller Gerätetreibern. Intern: 12 4,51 GB-Festplattenlaufwerke, Erweiterung: 10 4,51 GBFestplattenlaufwerke Festplattenlaufwerke. 1 EXP10 Erweiterungsgehäuse zum (insgesamt) Rackeinbau. Alle Festplattenlaufwerke mit 7.200 U/Min. NTFS, (Laufwerk 1), RAID0, Write-Back. Für Betriebssystem, Logisches Laufwerk C: Auslagerungsdatei, MTA, DS NTFS, (Laufwerk 2), RAID0, Write-Back. Für ExchangeLogisches Laufwerk D: Protokolldateien. Logisches Laufwerk E: Netzwerkkarten Exchange-Server NTFS, (Laufwerk 3 bis 22), RAID0, Write Through. Für Exchange MailDatenbank. Windows NT 4.0 Server Enterprise Edition mit Service Pack 3 Version 5.5 (Build 1960.5) NCR WorldMark 4300 Diese Testergebnisse zeigen die 95 %ige durchschnittliche Antwortzeit, wenn für 10.000 Exchange Server 5.5-Benutzer unter Verwendung des Exchange MAPI/RPC-Protokolls ein mit vier Prozessoren konfigurierter NCR WorldMark 4300-Server als Host fungiert. Ergebnisse Anzahl der Benutzer 10.000 95 %ige durchschnittliche Antwortzeit Prozessorauslastung Übermittlung an Nachrichtenempfänger pro Tag (berechnet) Verwendete Serverkonfigurationen Komponente Typ Anzahl Beschreibung Server Prozessoren Speicher Netzwerkkarten Festplattenhostadapter NCR 4300/4 Pentium Pro 10/100 MB/s NCR PQS Datenträgersubsystem NCR 6282 1 4 2 GB 3 2 422 62% 791,296 200 MHz mit 1 MB 2nd Level-Cache 4 SCSI-Kanäle pro Adapter 2 mit 10 4 GB-Laufwerken, 1 mit 6 4 GB-Laufwerken 3 Beispiele für InetLoad-Ergebnisse Mit LoadSim können Sie ermitteln, für wie viele MAPI-Clients ein Exchange Server als Host fungieren kann. InetLoad ist das entsprechende Tool zur Verwendung für POP3- oder IMAP4Benutzer. Die unten gezeigten InetLoad-Testergebnisse wurden vom ExchangePerformanceteam ermittelt. Testergebnisse Testsituation 1 2 3 CPU RAM Festplatte Protokoll Max. Benutzer 95 %ige durchschnittliche Empfangszeit (ms) 95 %ige durchschnittliche Sendezeit (ms) 95 %ige durchschnittliche Zeit insgesamt (ms) 2 x 200 MHz-Pentium Pro 512 MB 7 x 9 GB RAID 0 POP3/SMTP 7.000 2 x 200 MHz-Pentium Pro 512 MB 7 x 9 GB RAID 0 POP3/SMTP 10.000 2 x 200 MHz-Pentium Pro 512 MB 7 x 9 GB RAID 0 IMAP4/SMTP 4.000 775 940 844 160 117 105 935 1064 949 Die Kunst der Leistungsanalyse: Erkennen von Leistungsengpässen Ihre Exchange Server-Benutzer beschweren sich, dass der Server zu langsam ist. Brauchen Sie mehr Hardware? Falls ja, welche Arten von Hardware? Mehr Arbeitsspeicher (RAM)? Mehr Festplatten? Eine andere Prozessorplatine? Dieser Abschnitt beschäftigt sich damit, welche Hardwarekomponenten in welchem Zusammanhang zu kaufen sind. Die Erkennung von Leistungsengpässen ist mehr eine Kunst als eine Wissenschaft. Mit der Zeit werden Sie jedoch immer besser darin. Als erstes muss ermittelt werden, welche der drei wichtigsten Serverkomponenten (Speicher, Datenträger-E/A-Subsystem oder CPU) den Engpass bildet. Das wichtigste Tool, um dies festzustellen, ist der Windows NT-Systemmonitor. Benötigt das System mehr Speicher? Verwenden Sie den Systemmonitor um zu sehen, wie oft es Seiten auslagert. Überprüfen Sie die Auslagerungsdatei: Prozent in Benutzung und Speicher: Bytes verfügbar. Wenn die Auslagerungsdatei zu mehr als 50 % belegt ist und der Prozentsatz des verfügbaren Speichers unter 25 % liegt, ist mehr RAM zu empfehlen. RAM wird normalerweise in 16 oder 32 MB-Schritten hinzugefügt. Folgen Sie den Empfehlungen des Herstellers. Bildet das Datenträger-E/A-Subsystem den Engpass? Finden Sie mit dem Systemmonitor heraus, ob die E/A des Servers an asynchrone E/As zur Exchange Server-Datenbank gebunden ist. Überprüfen Sie Physikalischer Datenträger: Durchschnittl. Warteschlangenlänge des Datenträgers und Physikalischer Datenträger: Zeit (%). Die Warteschlangenlänge des Datenträgers zeigt noch nicht ausgeführte Datenträgeranforderungen nach physischem Datenträger einschließlich laufender Anforderungen. Bei Datenträgergeräten mit mehreren Spindeln (z. B. ein RAID-Stripe) können gleichzeitig mehrere Datenträgeranforderungen aktiv sein. Sie sollten daher auf die Warteschlangenlänge minus der Anzahl der Spindeln auf dem Datenträgergerät achten. Wenn diese Zahl ständig hoch ist, ist Ihr System an Datenträger-E/A gebunden. Diese Zahl sollte für hohe Leistung durchschnittlich weniger als 2 betragen. Zeit (%) ist der Prozentsatz der Zeit, die das ausgewählte Festplattenlaufwerk mit der Erledigung von Anforderungen verbringt. Wenn dieser Prozentsatz hoch ist, zeigt dies, dass Ihr System den größten Teil der Zeit Anforderungen beantwortet. Es benötigt daher schnellere oder zusätzliche Festplattenlaufwerke. Ist die CPU-Nutzung hoch? An dieser Stelle wird es etwas komplizierter, da die CPU-Nutzung selbst dann hoch sein kann, wenn die Festplatte und/oder der Speicher den Engpass bilden. Überprüfen Sie daher zunächst diese beiden Bereiche und anschließend die CPU. Um festzustellen, ob Ihr System mehr Prozessoren braucht, überprüfen Sie im Systemmonitor System: Gesamtprozessorzeit (%) und Prozess: Prozessorzeit (%) - Prozess XY. Wenn die Prozessorgesamtauslastung durchschnittlich über 75 % liegt, müssen Sie möglicherweise eine weitere CPU hinzufügen. (Überprüfen Sie die Verwendung aller Prozessoren, wenn Sie sich die symmetrischen Multiprozessorfähigkeiten der Exchange-Funktionen auf einem Windows NT Server anschauen möchten.) Tests zeigen, dass Exchange Server 4.0 und 5.0 sich für mehr als vier CPUs nicht gut skalieren lassen. Wenn Sie bereits vier CPUs verwenden und immer noch einen CPU-Engpass feststellen, können Sie den Prozessortyp aktualisieren, einen Server hinzufügen oder auf Exchange Server 5.5 aktualisieren.