carnivore 10 Geschrieben 30. April 2008 Melden Teilen Geschrieben 30. April 2008 Hallo, Gibt es Angaben von MS oder Erfahrungswerte, wieviele DCs pro Site bzw. pro Domäne oder pro Gesamtstruktur unter w2k3 zulässig sind. Ich habe nur für w2k einen Artikel gefunden, der etwa 800 DCs pro Domäne nennt. Da werde ich wahrscheinlich nicht ganz hinkommen, aber so 70-90 DCs pro Site können es noch werden. 40 DCs pro Site laufen jedenfalls ohne Probleme. Und die Anzahl der DCs in der Gesamtstruktur könnte knapp 4-stellig werden Merci carnivore Zitieren Link zu diesem Kommentar
LukasB 10 Geschrieben 30. April 2008 Melden Teilen Geschrieben 30. April 2008 90 DCs in *einer* Site? Auf die Schnelle finde ich da solche Sizing-Kommentare: # A domain controller with four processors and 512 MB of RAM can support 17,000 users for logon and network authentication. Bist du sicher das du DCs meinst, oder reden wir hier von einer richtig verdammt grossen Firma? Zitieren Link zu diesem Kommentar
sammy2ooo 10 Geschrieben 30. April 2008 Melden Teilen Geschrieben 30. April 2008 Hallo carnivore Folgendes hab ich gefunden: Active Directory Maximum Limits Bezieht sich auf Windows Server 2003 ... Recommended Maximum Number of Domain Controllers in a Domain Because the File Replication Service (FRS) is used to replicate SYSVOL in a Windows Server 2003 domain, we recommend a limit of 1,200 domain controllers per domain to ensure reliable recovery of SYSVOL. If any Active Directory domain in your network is expected to exceed 800 domain controllers and those domain controllers are hosting Active Directory–integrated Domain Name System (DNS) zones, review article 267855 in the Microsoft Knowledge Base (Problems with Many Domain Controllers with Active Directory Integrated DNS Zones ). For more information about FRS limitations, see the FRS Technical Reference (Microsoft Corporation ). Was wird denn das für ein wahnsinns Netzwerk? :shock::shock::shock: Zitieren Link zu diesem Kommentar
Lian 2.468 Geschrieben 30. April 2008 Melden Teilen Geschrieben 30. April 2008 @LukasB: Naja, manchmal liegt es auch an der Bandbreite entfernter Standorte. Zitieren Link zu diesem Kommentar
LukasB 10 Geschrieben 30. April 2008 Melden Teilen Geschrieben 30. April 2008 Folgendes hab ich gefunden: Active Directory Maximum LimitsBezieht sich auf Windows Server 2003 Ja, mit 2008 und DFS-R werden die Zahlen dann nochmals ganz anders aussehen. @Lian: Der OP hat ausdrücklich von 90 DCs _pro Site_ geredet. Und eine Site definiert sich ja dadurch das die Anbindung innerhalb derselben Site breitbandig ist. Zitieren Link zu diesem Kommentar
carnivore 10 Geschrieben 30. April 2008 Autor Melden Teilen Geschrieben 30. April 2008 ist schon was grösseres :): ca. 300K User sollen am Ende der Zentralisierung auf einer Handvoll Rechenzentren über Terminalserver arbeiten. Dafür brauchen wir auch ein paar DCs. Bandbreite spielt eigentlich keine Rolle, die haben wir innerhalb der RZs als auch zwischen den RZs genug. Gruss carni Zitieren Link zu diesem Kommentar
Stonehedge 12 Geschrieben 30. April 2008 Melden Teilen Geschrieben 30. April 2008 klingt nach nem spannenden projekt :) Zitieren Link zu diesem Kommentar
vmorbit 10 Geschrieben 30. April 2008 Melden Teilen Geschrieben 30. April 2008 geile sache! halt uns auf dem laufenden!!! ;) Zitieren Link zu diesem Kommentar
Velius 10 Geschrieben 30. April 2008 Melden Teilen Geschrieben 30. April 2008 Wieso so viele wenn die Frage erlaubt ist? Wegen der Redundanz? Reichen da auch nicht sagen wir mal 16? Und wenn's um Power geht, ein x64 DC mit 8 Cores und ein paar Giga RAM kann einiges ab. Hätte da noch was: Determining the Minimum Number of Domain Controllers Required Zitieren Link zu diesem Kommentar
Lian 2.468 Geschrieben 30. April 2008 Melden Teilen Geschrieben 30. April 2008 @LukasB: Muss zwar nicht sein, aber prinzipiell gebe ich Dir Recht. Meine Aussage bezog sich generell auf Verteilung von DCs. Daher sehe ich Veluis' Frage als berechtigt an... Zitieren Link zu diesem Kommentar
carnivore 10 Geschrieben 30. April 2008 Autor Melden Teilen Geschrieben 30. April 2008 Hallo, Danke schonmal für eure Antworten und Links! Momentan laufen wir mit 32-bit Maschinen und meine Zahlen oben sind einfach eine grobe Hochrechnung aus unseren bisherigen Erfahrungen mit ca. 45.000 Usern. 64-Bit Systeme werden mittelfristig auch eingesetzt werden, was die Gesamtzahl wahrscheinlich drücken wird. Aktuell bauen wir noch 32-bit auf. Einige Gründe für die hohe Anzahl der DCs: - 90% unserer User meldet sich in einem sehr engen Zeitfenster zwischen 8:25 und 8:35 am System an. d.h. da schiesst die Last nach oben, den Rest des Tages langweilen sich die DCs. Aber diese Last müssen wir abfackeln können. - Redundanz bei Ausfall eines RZs muss ebenfalls gewährleistet sein - an den DCs melden sich leider nicht nur die relativ gut optimierten Terminalserver an, sondern jede Menge Server mit Software, die oft noch NTLM verwendet. Also keine Kerberosoptimierung mit Tickets etc. - Auch diverse Alt-Skripte (ifmember ist ein markantes Negativ-Beispiel) hämmern unoptimiert auf die DCs ein. tut mir leid, dass ich euch nicht alle Details offenlegen kann carnivore Zitieren Link zu diesem Kommentar
Daim 12 Geschrieben 30. April 2008 Melden Teilen Geschrieben 30. April 2008 Buenos dias, ich muss auch noch meinen Senf abgeben (jaa, dass muss sein). ;) ... aber so 70-90 DCs pro Site können es noch werden. 40 DCs pro Site laufen jedenfalls ohne Probleme. Und die Anzahl der DCs in der Gesamtstruktur könnte knapp 4-stellig werden 70 bis 90 DCs lesen sich an dieser Stelle als zu oversized an. Aber dabei kommt es an, auch wenn die Wörter "pro Site" gefallen sind, was denn damit genau gemeint sind. Heißt hier "pro Site" ein AD-Standort oder ein physikalischer Standort, wobei sich dort alle DCs in einem Gebäude befinden oder lautet "pro Site" tatsächlich ein physikalischer Standort, wobei die DCs aber verteilt in vielen Gebäuden, getrennt von vielen Kilometern zueinander entfernt sind. Hier müsste der OP noch weitere Informationen liefern, damit man ein genaueres Bild vor Augen hat. Als nächstes sollte überlegt werden, an welchen Standorten evtl. ein 64Bit DC eher on Vorteil wäre. Denn auf einem 64Bit System können mehr Benutzer pro CPU zugelassen werden. Das hängt natürlich erneut davon ab, wieviele User sich an diesem Standort befinden. Auch kommt für das Design in Frage, ob Exchange genutzt wird. Ein gutes Whitepaper dazu wäre dieses: Download details: Active Directory Performance for 64-bit Windows Server Evtl. ist bei dem Design das Active Directory Sizer Tool, dass zu Zeiten von Windows 2000 heraus kam bei der Anzahl an DCs hilfreich: Download details: Active Directory Sizer Das mal soviel auf die schnelle... – 64-Bit Systeme werden mittelfristig auch eingesetzt werden, was die Gesamtzahl wahrscheinlich drücken wird. Mit Sicherheit. - 90% unserer User meldet sich in einem sehr engen Zeitfenster zwischen 8:25 und 8:35 am System an. d.h. da schiesst die Last nach oben, den Rest des Tages langweilen sich die DCs. Aber diese Last müssen wir abfackeln können. Du hast es richtig erkannt, die Spitzen müssen abgedeckt sein. Das sich die DCs den rest des Tages langweilen, ist eher zu vernachlässigen. Und genau dafür, eben für die Benutzerauthentifizierung würde ich weitestgehend auf 64Bit mit viel Ram (ab 4 GB) gehen. Aber für diese coole Projekt holt ihr euch sicherlich kompetente Hilfe. - Redundanz bei Ausfall eines RZs muss ebenfalls gewährleistet sein Ein sehr wichtiger Punkt der die Anzahl der DCs dann rechtfertigt. - an den DCs melden sich leider nicht nur die relativ gut optimierten Terminalserver an, sondern jede Menge Server mit Software, die oft noch NTLM verwendet. Also keine Kerberosoptimierung mit Tickets etc. Bei dieser Größe der Umgebung und somit der eingesetzten Vielfalt an Applikationen wird man auch kaum auf NTLM verzichten können... - Auch diverse Alt-Skripte (ifmember ist ein markantes Negativ-Beispiel) hämmern unoptimiert auf die DCs ein. Na dann krempelt mal die Ärmel hoch und optimiert dort wo es möglich ist. ;) Damit spart man dann am Ende evtl. den einen oder anderen DC. tut mir leid, dass ich euch nicht alle Details offenlegen kann Verständlich. Tolles Projekt. Wie lange läuft das Projekt? 1-2 Jahre? Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 1. Mai 2008 Melden Teilen Geschrieben 1. Mai 2008 Hi, allzu viel gibt es ja nicht mehr zu sagen, viele Punkte wurden ja schon angesprochen. Grundsätzlich würde ich auch noch einmal bekräftigen wollen, daß Ihr vielleicht weniger in Richtung vieler 32bit Systeme gehen solltet, sondern eher in Richtung "weniger" x64 Systeme. Bei der genannten Benutzeranzahl ist grundsätzlich erst einmal - je nach Umgebung - eine größere NTDS.DIT zu erwarten. Je größer der RAM in diesem Fall, umso besser (die alte Daumenregel, daß die NTDS.DIT in den RAM passen sollte, zählt nämlich immer noch ;) ). Außerdem wird der Global Catalog auch währscheinlich eine gute Größe haben, die in der Datenbank und damit im RAM untergebracht sein will. Mann kann sich hier überlegen, ob man nur einige DCs zu Global Catalogs hochstuft und nicht alle. Müßte man einmal genauer betrachten... Letztendlich ist wie schon gesagt die supportete Obergrenze unter Windows Server 2003 1.200 DCs (wie angesprochen begrenzt durch die FRS Thematik) - aber mal ehrlich: Solche Umgebungen benötigen einen unglaublichen Aufwand, um allein die Rollenkonzepte, das Monitoring, Staging, Updates etc. in den Griff zu bekommen. In vielen Fällen fahren die Firmen also auch wieder die DC Anzahl herunter, weil der administrative Overhead einfach extrem wird. Und außerdem: x64 ist die eierlegende Wollmilchsau und löst all unsere Probleme, oder? ;) :D Viel Erfolg und halt uns auf dem Laufenden. :) Viele Grüße olc Zitieren Link zu diesem Kommentar
Sternenkind 11 Geschrieben 2. Mai 2008 Melden Teilen Geschrieben 2. Mai 2008 Zu 64 bit kann ich aus Erfahrung noch folgendes sagen: mache bei gleicher hardware aus 3 Servern einen und arbeite bei gleicher Performans weiter *staun* Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.