Hallo, heute mal wieder ein Gastbeitrag aus dem Netzwerk Team. Diesmal von Hubert mit seinem ersten Eintrag im „Aktiven Verzeichnis“.
Bei uns laufen immer wieder Anfragen auf, bei denen es um eine schlechte Netzwerkperformance insbesondere von Fileservern geht. Oft stellen wir fest, dass Access-based Enumeration (ABE) auf den Shares dieser Server aktiviert ist.
Deshalb möchte ich im folgenden etwas näher auf die Faktoren eingehen, die einen Einfluss auf die Performance der Server mit ABE haben, welche Möglichkeiten zur Verbesserung bestehen, und wie man erkennt, ob ABE der Grund für Performance Probleme auf einem bestimmten Server ist.
Was ist Access-based Enumeration? Seit Windows 2003 SP1 ist ABE ein eingebautes Feature der Windows Server Reihe. Wenn es auf einen Ordner aktiviert wird (meist ein Share) so sieht ein Benutzer unterhalb dieses Ordners nur die Objekte (Dateien und Ordner) auf die er mindestens Leserechte hat, sofern der Zugriff über das Netzwerk erfolgt. Erfolgt der Zugriff lokal auf das Verzeichnis, so wirkt ABE nicht, und der Benutzer sieht wie üblich alle Dateien und Ordner.
Ein wie ich finde schönes Beispiel zum Sinn und Zweck von ABE gestaltet sich wie folgt:
Ein User (nennen wir ihn Bob) stolpert beim browsen durch das Share über einen Ordner namens „Kündigung CEO Februar 2009“. Auch wenn Bob den Ordner nicht öffnen kann reicht ihm diese Information, um alle seine Aktien zu verkaufen, und seinen Kollegen ebenfalls zu diesem Schritt zu raten. Kurze Zeit nachdem der Chef gekündigt hat, und die Aktien-Kurse wie erwartet in den Keller gefallen sind fällt jemanden auf, dass kurz vor der Kündigung mehrere Mitarbeiter ihre gesamten Aktien verkauft haben. Schon hat man jemanden im Nacken sitzen, der einem etwas von Insider Handel erzählt.
In manchen Fällen reicht also schon der Ordnername aus, um sensitive Informationen preiszugeben. Mit ABE hätte Bob den Ordernamen gar nicht gesehen.
Einen guten Einblick bietet auch das ABE Whitepaper: http://www.microsoft.com/downloads/details.aspx?FamilyId=04A563D9-78D9-4342-A485-B030AC442084&displaylang=en
Im Abschnitt Limitations ist zu lesen:
"ABE can also demand CPU resources from file servers. However, Microsoft benchmarking tests indicate that even for very large file structures, running ABE only consumes two to three percent of CPU cycles. Administrators must use their judgment in balancing security and performance on file servers, even when the overhead is small."
Genau bei diesem “judgment” möchte ich mit diesem Beitrag helfen.
Wie funktioniert ABE?
Wenn der Client den Inhalt eines Verzeichnisses abfragt erhält er, wenn ABE aktiviert ist, nur die Dateien und Ordner übermittelt, auf die der jeweilige Benutzer Berechtigungen hat. Die Filterung findet also auf dem Server statt.
Um entscheiden zu können, ob der Server ein bestimmtes Objekt an den Client übermitteln darf muss er die Access Control List (ACL) des Benutzers mit der ACL des jeweiligen Objektes vergleichen. Dies ist naturgemäß recht CPU-Intensiv und kann insbesondere bei komplexen Shares mit vielen Objekten in einem Verzeichnis für sehr grosse Last auf dem Server sorgen. Dies äussert sich normalerweise auf dem Server durch eine hohe CPU-Auslastung und eine erhöhte Processor Queue Length.
Insbesondere wenn die Processor Queue Lenght hoch ist, kann es auf dem Client zu erheblichen Wartezeiten kommen. Meist äussert sich dies darin, dass es lange dauert, bis der Inhalt eines Ordners auf einem Share angezeigt wird und kann sogar soweit gehen, dass der Windows Explorer mit „not responding“ für einige Zeit hängen bleibt. Die selben Symptome können natürlich auftreten, wenn der Server aus anderen Gründen (Virenscan, Backup, etc.) unter hoher Last läuft.
Welche Faktoren spielen eine Rolle?
Um dieser Probleme Herr werden zu können, müssen wir erst einmal wissen, welche Faktoren bei den Lastanforderungen von ABE eine Rolle spielen:
Im Folgenden wird detailierte auf die einzelnen Faktoren und ihre Auswirkungen eingegangen:
Zugriffe Das die Anzahl der gleichzeitigen Zugriffe eine Auswirkung auf den Leistungsbedarf hat dürfte naheliegend sein.
Wie viele Zugriffe gleichzeitig auf dem Server auftreten ist jedoch noch von anderen Faktoren abhängig. Hierzu zählt natürlich die Anzahl der aktiven Benutzer insgesamt, aber auch die Dauer eines Zugriffes. Stellt der Server zum Beispiel das gesamte Netzwerkshare bereit, so werden die Verbindungen länger dauern und somit sich mit einer höheren Wahrscheinlichkeit zeitlich überschneiden, als würde der Server nur einen Teil des Shares (z.B. durch DFS) bereit stellen. Die Anzahl der Zugriffe pro Zeit wird natürlich auch durch das Benutzerverhalten beeinflusst, dass sich meist nicht realistisch für einen Test abbilden lässt.
Objekte Die Dauer einer einzelnen ABE-Berechnung (ACL Vergleiche) wird durch die Anzahl der zu berechnenden Objekte beeinflusst.
ABE betrachtet hierbei pro Berechnung lediglich ein einziges Verzeichnis. Sind in diesem Verzeichnis viele Objekte enthalten, dauert es entsprechend länger die Berechnung durchzuführen, als wenn nur wenige Objekte vorhanden wären. Je länger die Berechnung dauert umso länger ist natürlich auch die CPU beschäftigt und umso länger dauert es bis der Client sein Ergebnis (die Liste an Objekten) erhält.
Struktur Bei der Rechtestruktur sind insbesondere die Berechtigungen auf der höchsten Ebene interessant. Hat ein Benutzer zum Beispiel nur Zugriff auf einen von zwei Ordnern auf der höchsten Ebene, so hat man damit den Baum, den er sehen kann, und damit die Anzahl an ABE-Berechnungen die durchgeführt werden müssen, halbiert (einen symmetrischen Aufbau des Baums vorausgesetzt).
Benutzer-ACL Da bei den Berechnungen die Access Control List des Benutzers mit der des Objektes verglichen wird, spielt es natürlich ebenso eine Rolle in wie vielen Gruppen der Benutzer Mitglied ist und wie komplex die Verschachtelung der Gruppen angelegt ist. Wie bei vielem gilt auch hier: Je schlanker, je schneller.
Client Der Client mit dem zugegriffen wird (meist Windows Explorer) spielt eine entscheidende Rolle beim serverseitigen Leistungsbedarf.
Als Beispiel sei hier das Kommandozeilen „dir“ im Gegensatz zum Windows Explorer benannt. Beim ausführen des Befehls „dir“ auf ein auf das Share verbundenes Netzlaufwerk löst dies eine ABE-Berechnung für eine einzige Ebene aus. Greift man hingegen mit dem Windows Explorer auf dieses Netzlaufwerk zu, so parsed dieser beim ersten Zugriff das gesamte (sichtbare) Share bis in die unterste Ebene durch. Hierdurch wird in jedem Verzeichnis aufs Neue eine ABE-Berechnung ausgelöst. Dies verursacht demzufolge eine ganz andere Last als ein simples „dir“.
Was hierbei ebenfalls zum tragen kommt, ist die Tatsache, dass der Windows Explorer in seiner Standard-Konfiguration zusätzlich Previews der Dateien generiert, Thumbnails und Dateityp-spezifische Informationen lädt. Dies erzeugt zusätzlichen Netzwerkverkehr und auf dem Fileserver daher zusätzliche Last, was ebenso zu einer Verschlechterung der Antwortzeiten insbesondere bei sehr großen Shares führen kann. Die grösste Last verursacht jedoch eine Suche auf dem Share, da hierbei jede einzelne Datei „angepackt“ wird.
Andere wichtige Punkte Zwei Punkte gibt es noch, die zusätzlich erwähnt werden müssen:
Do’s and Dont’s Bevor wir tiefer einsteigen wie man die Performance verbessern kann hier ein paar grundsätzliche Dinge:
Kann man das irgendwie testen?
Der Leistungshunger von ABE hängt von den oben beschriebenen Faktoren ab. Einige dieser Faktoren (z.B. Benutzerverhalten) lassen sich nicht realistisch in einer Testumgebung nachstellen. Hinzu kommt (siehe Whitepaper), dass der Leistungsbedarf von ABE nicht Linear ansteigt.
Das bedeutet man kann nicht von einem kleinen Test-Szenario auf eine grössere Live-Umgebung Rückschlüsse ziehen. Die einzige Chance die also besteht, ist zu ertesten welche Last einem einzelnen Server zugemutet werden kann, so dass die Antwortzeiten für die Clients noch in Ordnung sind und auch Peak-Belastungen abgefangen werden können.
Basierend darauf kann dann überlegt werden, wie viele Server man für den Einsatz von ABE (zusätzlich) braucht. Im Folgenden skizziere ich ein Testkonzept hierzu:
Man nehme einen Server und setzte ihn 1:1 wie die Maschinen in der Produktiv-Umgebung auf. Dies gilt ebenfalls für die Shares auf diesen Maschinen. Das bedeutet sie sollten in Struktur und Umfang denen aus der Produktiv-Umgebung gleichen. Am besten also einfach alle Daten rüber kopieren. Genauso müssen auf dieser Test-Maschine natürlich die zusätzlichen Applikationen die in der Produktion (z.B. Virenscanner, Verschlüsselung, etc.) installiert und konfiguriert werden.
Hatte ich schon erwähnt, dass natürlich auch die Hardware der Produktion entsprechen muss?
Wenn der Server vorbereitet ist, geht es nun an die Clients. Wir brauchen mindestens einem Hardware Client mehr als der Server Cores hat (siehe „Andere Wichtige Punkte“ weiter oben). Würden wir z.B. nur 3 Hardware-Clients bei einem Quad-Core Server verwenden, so würden nur 3 Kerne unter Last gesetzt und wir somit kein aussagekräftiges Ergebnis erhalten. Diese Clients sollten ebenfalls analog mit allen Programmen zu einem Produktiv-Client aufgesetzt werden.
Zum Schluss brauchen wir noch ein paar Benutzer.
Mein Vorschlag ist erst mal 50 Benutzer (je nach Dimension des Servers) anzulegen und sie entsprechend auf den Shares zu berechtigen. Auch hier wieder alles analog zur Produktion (also mit Verschachtelung, unterschiedlicher Verrechtung, etc.).
Je nach Ergebniss (weiter unten) müssen ggf. noch weitere Benutzer angelegt werden um den Server auszulasten. Um sich eine Menge Tipp-Arbeit zu ersparen sollte ein kleines Skript vorbereitet werden, dass ein Netzlaufwerk gegen das Share verbindet und in einer Schleife mit einem 10 Sekunden Sleep ein dir /s auf dieses Laufwerk ausführt.
Nun können wir mit dem eigentlichen Test beginnen:
Sind die Werte in Ordnung, kann die Last durch ausführen weiterer Skripte gesteigert werden bis die Antwortzeiten schlechter werden, oder der Server an seine Grenzen stösst. Notfalls müssen weitere Benutzer angelegt, verrechtet und per runas angemeldet werden.
Zusätzlich sollte insbesondere bei Fileservern durch Kopieren grösserer Datenmengen die Last von Up- und Download-Vorgängen auf dem Server simuliert werden. Wenn diese Bedingungen erfüllt sind, kann man sich auf dem Server nun im Computer Management unter Sessions anschauen, wie viele Verbindungen der Server gleichzeitig bedienen kann.
Wenn man dies mit der Anzahl der gleichzeitigen Sessions in der Produktiv-Umgebung vergleicht bekommt man ein Gefühl dafür, wie viele Server für den Einsatz von ABE benötigt würden.
Aber VORSICHT!
Aufgrund der vielen Unwägbarkeiten in diesem Testszenario, vor allem weil man das Benutzerverhalten nicht realitätsnah abbilden kann, kann dieser Test nur einen groben Anhaltspunkt liefern. Was dieser Test jedoch leisten kann ist folgendes:
In vielen Umgebungen sind obige Parameter nicht einfach so änderbar. Dies gilt insbesondere für einen der kritischsten Parameter, die Verzeichnisstruktur. In diesem Test Szenario kann jedoch getestet werden, wie gross der Performancegewinn durch bestimmte Veränderungen wäre.
Wenn ABE bereits im Einsatz ist, und die Vermutung besteht dass es zu einer schlechten Performance beiträgt, so ist der einfachste und aussagekräftigste Test natürlich ABE für eine Zeit abzuschalten. Vorher- Nacher- Performance Analysen sind hierbei natürlich unerlässlich.
So!
Ich hoffe hiermit einen guten Einblick in die Thematik ABE und Performance gegeben zu haben und insbesondere bei den Admins das Bewusstsein für mögliche Performance Probleme mit ABE geschärft zu haben.
Viele Grüsse Hubert