Exchange 2010: manchmal Postfach langsam

[S.R. 14]

Hallo,

 

ich habe hier ein Exchange-System mit grob folgender Konfiguration:

- 2 HP DL360G8 mit W2K8R2 für die DAG

- 5 Datenbanken, die sich über die DAG replizieren

- Exchange 2010

- ForeFront Protection 2010

- CAS, HT, MX,... läuft auf VMs auf zwei separaten HP-Servern

 

Das System läuft soweit sehr zufriedenstellend. Wir haben allerdings immer mal wieder das Problem, dass ein Mitarbeiter anruft und berichtet, dass sein Postfach oder sein Archiv-Postfach langsam ist. Dieses Phänomen können wir dann ebenso ist OWA reproduzieren - somit schließen wir Outlook bzw. die Verbindung zwischen Outlook und Exchange schon mal als Ursache aus.

 

Bisher gab es immer zwei Möglichkeiten, dass Problem zu beheben:

1) der Benutzer wartet ein paar Minütchen, manchmal round about 15 Minuten und das Problem löst sich von selber

2) ich schiebe die Datenbank von einem DAG-Knoten auf den anderen und dann läuft das Postfach direkt wieder gewohnt schnell

 

Wenn der Benutzer sich bei mir meldet, dann läuft das Exchange-System bei allen anderen Postfächern schnell - z.B. auch auf meinem Rechner. Wenn ich mir dann auf dem Server die wichtigsten Auslastungs-Parameter anschaue (Festplatten, CPU), dann behaupte ich, dass der Server sich durchweg langweilt.

 

Ich habe jetzt im Virenscanner eine "Scan bei Bedarf" nur für mein Postfach im Virenscanner eingerichtet, dann gestartet und kann dann ich problemlos in OWA durch mein Postfach inkl. Archiv navigieren und E-Mails öffnen.

 

Gibt es einen PowerShell-Befehl, mit dem ich auslesen kann, "wie es einem einzelnen Postfach geht" oder "was gerade mit einem einzelnen Postfach passiert"? Oder welche Möglichkeiten habe ich noch, dem Problem auf die Schliche zu kommen?

 

Ich bin für jeden Tipp mehr als dankbar!

 

Gruß

 

Stefan

[datmox 26]

Ist evtl. einfach der Clientrechner überlastet oder läuft dort ein Virenscan?

[NorbertFe 2.041]

Das kann jetzt aber auch ein Netzwerkproblem sein, denn wenn ich das richtig lese, setzt ihr CAS/NLB ein, korrekt? Da gibt's leider die merkwürdigsten Effekte, so dass ich normalerweise an dieser Stelle zu suchen anfangen würde.

 

Bye

Norbert

[S.R. 14]

Den Clientrechner schließe ich in der Tat aus, da das Problem auch im Browser über OWA auftritt - auch wenn ich OWA auf einem anderen Clientrechner aufrufe.

 

In der Tat setze ich CAS auf zwei Servern ein und dort ist dann ein NLB eingerichtet. Da Outlook und OWA ja über die CAS und somit über den NLB laufen, könnte dies in der Tat eine Ursache sein. Was mich dann allerdings wundert: wenn ich die Datenbank von einem DAG-Server auf den anderen verschiebe, dann löst sich das Problem von selbst. Dies wäre dann aber doch von einem CAS-Server zu einem DAG-Server die Verbindung und hier würde doch NLB nicht verwendet werden, oder?

 

Hast du evtl. noch einen Tipp auf Lager, wie ich am CAS/NLB schauen kann, ob hier eine Verbindung hängt?

[NorbertFe 2.041]

Dann ist es auch eine neue Connection, die im Backend vorgenommen wird afair. Nimm dir doch mal ein Wireshark und schau nach, was genau in so einem Fall passiert. Wird sicher etwas aufwändig, aber alternativ könntest du dir ja auch eine Trial von einem Loadbalancer als VM holen und mal schauen wie es damit aussieht. Wenn das Problem damit nicht auftritt, hast du deine Fehlerquelle erstmal identifiziert. In welchem Modus läuft dein NLB?

 

Bye

Norbert

[S.R. 14]

Der Clusterparameter "Clusterausführungsmodus" steht auf "Unicast".

[NorbertFe 2.041]

Schreib nur nicht zuviel. ;) Wieviele Netzwerkkarten hat dein NLB? Welche Netzwerkkomponenten hängen mit drin? Kannst du Multicast testen (nachdem du geklärt hast, dass du das machen kannst hinsichtlich Netzwerkkomponenten)?

 

Bye

Norbert

[S.R. 14]

In der Kürze liegt die Würze :-) *sorry*

 

Ich habe vier virtuelle Netzwerkkarten auf jedem der beiden CAS-Server:

- Backup

- CAS (Port 443)

- IIS (http-Port 80, Weiterleitung auf Port 443)

- LAN

 

Entsprechend habe ich zwei "NLB-Netze"; eines für den CAS (wichtigste) und eines für den IIS (nur für die Weiterleitung auf den https-Port).

 

Ich habe jetzt mal auf Multicast umgeschaltet. Ich meine mich aber daran erinnern zu können, dass ich bei meiner ersten Recherche zu dem Problem im Netz gelesen hatte, von Multicast auf Unicast umzustellen *grübel*...

[NeMiX 76]

Was mir noch fehlt sind die Angaben zu Ram und HDDs (evtl. Raid Level und Cache auf dem Controller), falls es nicht am NLB liegt (da hat Norbert dir ja schon gesagt schau mal mit Wireshark rein).

[NorbertFe 2.041]

- CAS (Port 443)

- IIS (http-Port 80, Weiterleitung auf Port 443)

Warum trennt man sowas?

 

Ich habe jetzt mal auf Multicast umgeschaltet. Ich meine mich aber daran erinnern zu können, dass ich bei meiner ersten Recherche zu dem Problem im Netz gelesen hatte, von Multicast auf Unicast umzustellen *grübel*...

Hab ich nicht gesagt, du sollst vor dem Umschalten erstmal "überlegen"? Naja ist ja dein Netz... :rolleyes:

[S.R. 14]

Auf jedem DAG-Server sind 96GB Ram installiert; die Systemplatten sind 15K 142GB Platten und die edb-Daten liegen auf 4 600GB 10K Platten im RAID-10 (282 GB von 1.09 TB belegt); die Log-Dateien liegen auf 2 600GB 10 Platten gespiegelt. Dies sollte ja eigentlich mehr als ausreichen.

 

Eingebaut ist ein HP Smart Array P420i, der in dem Array Configuration Utility von HP keine Fehler aufweist. Der Controller scheint Cache-Optionen zu haben - da hab ich aber nie was dran geändert und auch noch nie reingeschaut :-)

Das Trennen ist aus geschichtlichen Gründen entstanden. Erst war der Zugriff auf Exchange über unverschlüsselte Kommunikation möglich und dann habe ich nach und nach auf Verschlüsselung umgestellt. Somit konnte ich damals recht einfach https einrichten und testen, ohne dass ich die Mitarbeiter gestört/beeinflusst habe. Wir dann https lief, habe ich einfach n' Weiterleitung gemacht, fertig. Grundsätzlich könnte man sicherlich überlegen, den IIS-NLB aufzugeben und die Weiterleitung im IIS entsprechend zu verknüpfen.

 

Ich bin mir eigentlich ziemlich sicher, dass die Netzwerkkomponenten meiner Infrastruktur Multicast fähig sind - daher hat mir dies als "Überlegung" gereicht. Die Umstellung hat auch sauber funktioniert... Zumindest läuft alles nach wie vor; einzig die Verbindung zu Outlook wurde natürlich einmal kurz unterbrochen und direkt wieder aufgebaut - aber das war ja OK/bekannt und damit konnte ich leben.

[NorbertFe 2.041]

Dies sollte ja eigentlich mehr als ausreichen.

Da du keine Nutzeranzahl angibst, und kein Nutzerverhalten, würde ich da nicht zwingend zustimmen. ;)

 

 

Bye

Norbert

[S.R. 14]

Aktuell laufen 161 Postfächer auf dem Exchange-System. Davon nutzen 68 Nutzer Outlook 2010/2013; 88 nutzen IMAP4/SMTP; 5 sind meine Testpostfächer. Das Verhalten der Benutzer wage ich mit "minimal" anzugeben und da Outlook das Postfach ja auch lokal cached, geht ja zum Exchange noch weniger.

 

Wenn es grundsätzliches Lastproblem geben würde - müssten dann nicht alle Postfächer "gleich langsam sein"; weil ich habe ja das Phänomen, dass nur eines für einen Moment langsam ist und danach wieder zackig läuft... und müsste dann nicht auch im Ressourcenmonitor von Windows die CPU bzw. die Festplattenauslastung am Limit sein?

[NeMiX 76]

Wenn es grundsätzliches Lastproblem geben würde - müssten dann nicht alle Postfächer "gleich langsam sein"; weil ich habe ja das Phänomen, dass nur eines für einen Moment langsam ist und danach wieder zackig läuft... und müsste dann nicht auch im Ressourcenmonitor von Windows die CPU bzw. die Festplattenauslastung am Limit sein?

Ja aber die Infos das du im Ressourcenmanager geschaut hast fehlte vorher ;).

Ich würde an deiner Stelle Ressourcenmanager mal länger laufen lassen (Evtl. hast du ja irgendwo Spikes) und per Wireshark reinschauen beim Traffic.

 

Welchen AV setzt du ein und kannst du den Testweise auf einem Client der betroffen ist mal deinstallieren und testen?

[RobertWi 81]

Eventuell zieht der Exchange User Monitor noch ein paar Daten raus:

http://www.msxfaq.de/tools/exmon.htm

 

Allerdings wird der nicht mehr gepflegt und ich habe ihn schon lange nicht mehr eingesetzt, gibt also keine Gewähr, dass er überhaupt noch funktioniert.