Access-based Enumeration und seine Performance

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: https://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:

• Anzahl der zeitgleichen Zugriffe / gleichzeitig arbeitender Benutzer
• Anzahl der Objekte in einer Hierarchie-Ebene, auf die ABE wirkt
• Rechtestruktur auf dem Share
• Komplexität der Benutzer-ACL (Anzahl der Gruppen und Verschachtelungen)
• der verwendete Client spielt indirekt eine Rolle

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:

• Die ABE-Berechnungen werden nur dann an unterschiedliche CPUs des Servers verteilt, wenn sie von unterschiedlichen Netzwerk-Clients stammen.
  Wenn ein Benutzer also sehr viele Berechnungen auslöst (zum Beispiel durch eine Suche auf dem Share) werden alle diese Anfragen  in einer einzigen CPU abgearbeitet und können dazu führen das diese CPU komplett „aufgebraucht“ wird.
  Alle weiteren Anfragen für diese CPU landen also erst mal in der Warteschlange (Processor Queue Length) bevor sie abgearbeitet werden können.
  Daher ist Vorsicht bei der Verwendung von Terminal-Servern auf ABE-Shares geboten.

• ABE hat keinen Cache und muss daher bei jedem Zugriff auf ein Verzeichniss alle darin enthaltenen Objekte daraufhin prüfen, ob der Client sie sehen darf oder nicht. Der Grund hierfür sind Sicherheitsüberlegungen:
  Wenn ABE einen Cache hätte und man würde die Berechtigungen eines Benutzers verändern, so wäre diese Änderung für die Ansicht erst nach Verfall des Caches wirksam.
  Der Benutzer könnte also in der Zwischenzeit

  • Objekte sehen auf die er keine Rechte (mehr) hat.
  • Objekte nicht sehen auf der er (jetzt) Berechtigungen hat.

Do’s and Dont’s
Bevor wir tiefer einsteigen wie man die Performance verbessern kann hier ein paar grundsätzliche Dinge:

• Clients dürfen den Server nicht nach Viren scannen:
  Hierdurch wird (egal ob mit oder ohne ABE) eine hohe und unnötige Last verursacht. Aufgrund der Berechtigungen kann ohnehin kein Client den gesamten Fileserver scannen.

• Applikationen nicht von Netzlaufwerken aus starten:
  Beim Starten von Applikationen werden unter anderem DLLs geladen was wiederum ABE-Berechnungen auslöst.

• Einschränkung des Zugriffs möglichst weit oben auf dem Share:
  Wie bereits erwähnt: Desto weniger Ordner der Benutzer auf der höchsten Ebene sieht, desto weniger Berechnungen müssen insgesamt durchgeführt werden.

• Schlanke Verzeichnisse:
  Desto weniger Objekte in einem Verzeichniss, desto kürzer dauert die ABE Berechnung für dieses Verzeichniss.

• Scalable Networking Pack verwenden:
  Hierdurch kann die CPU sehr stark entlastet und somit die Leistungsfähigkeit der Server gesteigert werden, sofern die Netzwerkkarten dies unterstützen:

  Ref: SNP FAQ
  https://www.microsoft.com/technet/network/snp/faq.mspx
  Q. What types of workloads can benefit from Scalable Networking Pack enhancements?
  A. The Scalable Networking Pack can improve the performance and scalability of such data-heavy workloads as file storage, backups, Web servers, and media-streaming. Depending on the workload, overall performance gains can range from 20 percent up to nearly 100 percent reduction of network packet processing overhead and increase network throughput up to 40 percent.

  Um bekannte Probleme beim Einsatz des SNP zu vermeiden, sollte unbedingt das SNP Hotfix Rollup Package KB950224 installiert werden: https://support.microsoft.com/kb/950224/en-us

• Wenn irgend möglich die Last auf mehrere Server verteilen:
  Hier gibt es neben dem klassischen Clustering auch noch DFS als sehr gute Option.
  In diesem Falle empfhielt es sich die oberen Ebenen des Shares in ein DFS oder in eine DFS-Kaskade zu verlegen und das ABE auf den DFS-Links zu aktivieren.
  Somit erfolgt die Filterung nur auf einer (oder bei einer Kaskade mehreren) Ebenen aber nichtmehr im gesamten Baum. Hierdurch wird die Anzahl der ABE Berechnungen stark reduziert.
  Die DFS-Server haben (sofern nichts CPU-lastiges auf ihnen läuft) im Gegensatz zu den Fileservern meist genügend Reserven für die ABE-Berechnungen.
  Bei mehreren DFS-Servern mit ABE auf den Links wird die ABE-Last auf mehrere Server verteilt, da die Clients per Zufall immer einen anderen Server im eigenen Standort kontaktieren.
  Es ist wesentlich einfacher einen weiteren DFS-Server einzubinden als einen zusätzlichen Fileserver.
  Hierbei gibt es jedoch ein paar Punkte zu beachten:
  Vorsicht, wenn die DFS-Server gleichzeitig DCs sind!
  Unter zu hoher CPU-Last (durch ABE) kann es passieren, dass keine Anmeldungen mehr möglich sind.
  Die ACLs auf den DFS-Links und auf den Link-Targets müssen richtig gesetzt werden.
  Siehe hierzu auch:
  https://support.microsoft.com/kb/907458/en-us und https://support.microsoft.com/kb/961658/en-us

• Regelmässiges Überwachen der Performance:
  Wenn sich einer der oben benannten Faktoren ändert, kann dies Auswirkungen auf die ABE-Performance haben.
  Hierzu zählen aber nicht nur das Anwachsen der Shares oder veränderte Benutzer Berechtigungen, sonder auch neue Applikationen die in die Umgebung gebracht werden, und beispielsweise auf Shares zugreifen um dort Daten zu speichern.
  Daher sollte, am Besten in Form eines regelmässigen Performance Audits, die Last auf den Server überwacht werden um sie mit Ergebnissen voriger Analysen zu vergleichen.
  Somit können frühzeitig Gegenmassnahmen ergriffen werden ohne unter akutem Zugzwang zu stehen.
  Neben den üblichen Performance Countern (Processor, Memory, Disk, Network, Process) sollten noch zwei weitere Counter aufgezeichnet werden.
  Dies ist zum einen die bereits erwähnte System\Processor Queue Length aber auch Server\ File Directory Searches. Letzterer zeigt die Anzahl gleichzeitger Datei-Suchen auf dem Server an. Wie oben beschrieben kann eine Suche einen sehr negativen Einfluss auf die Performance haben.
  Hilfestellung bei der Analyse der Counter kann der folgende Technet-Artikel liefern.
  Auch wenn sich dieser explizit auf Exchange Server bezieht, sind viele der Werte und insbesondere die Bedeutung der Counter übertragbar:
  https://technet.microsoft.com/en-us/library/cc671175.aspx

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:

1. An jedem der Hardware Clients wird ein Benutzer angemeldet.
2. Nun werden zum Beispiel mit "runas" gleichmässig über alle Clients verteilt Kommandozeilen im Kontext der übrigen Benutzer angemeldet.
3. Bei 5 physikalischen Clients und 50 Benutzern haben wir also dann auf jeder Maschine einen Benutzer direkt angemeldet und 9 Kommandozeilen Fenster offen.
4. Nun wird über alle Maschinen gleichmässig verteilt unser Testskript (dir /s gegen das LW) aufgerufen.
5. Sobald die erste Handvoll Skripts läuft sollte die Last auf dem Server überwacht und zusätzlich durch ein Browsen des Netzlaufwerks mit dem Windows Explorer vom Client aus überprüft werden, ob die Antwortzeiten in Ordnung sind.

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.

1. Die Anzahl der Benutzer sollte so variiert werden, dass 
2. der Server gut ausgelastet ist
3. die Antwortzeiten für die Clients in Ordnung sind
4. zusätzliche Suchanfragen gegen das Share (Start -> Suchen) möglich sind ohne das die Antwortzeiten zu sehr darunter leiden
5. Reserven für andere Aufgaben (sofern nötig) und Peak-Zeiten bleiben

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