Best Practice: Sizing für UCS als IDM

UCS@school
,
#1

Disclaimer

Das vorliegende Dokument ist kein Teil der offiziellen Univention Dokumentation, sondern basiert rein auf Erfahrungswerten aus Projekten und soll Richtwerte liefern. Es wird keine Gewährleistung auf Korrektheit oder Vollständigkeit gegeben.
Die Zahlen sind als grobe Hausnummer zu verstehen. Im tatsächlichen Betrieb bestimmt die eigentliche Nutzung und Auslastung, insbesondere die „concurrent users“, den Ressourcenbedarf. Daher ist es unerlässlich, dass die Systemauslastung in einem Monitoring-System protokolliert wird, um Trends erkennen und Überlastung vermeiden zu können.
Die farbliche Markierung fasst einzelne Serversysteme in funktionale Gruppen zusammen. Die so markierten Systeme sollten möglichst identisch konfiguriert werden und können dann bei Bedarf zu einer Loadbalancing-Gruppe zusammengefasst werden (bspw. für Zugriffe von außen auf Dienste wie Self-Service oder SAML-IdP).

Hinweise:

  • Testsysteme kommen i.d.R. auch gut mit 2 CPUs aus, produktiv sollten nicht weniger als 4 CPUs eingesetzt werden
  • Die Anzahl an CPU Kernen wächst primär mit der Anzahl an erwarteten (gleichzeitigen) LDAP-Änderungen und -Anmeldungen
  • RAM wächst nach Abdeckung des Grundbedarfs in etwa linear mit der Anzahl der LDAP-Objekte (hauptsächlich Benutzer)
  • Disk wächst nach Abdeckung des Grundbedarfs mit der Größe der LDAP-Datenbank und diese wiederum mit der Anzahl der LDAP-Objekte (hauptsächlich Benutzer)
  • Gute IOPS sind wichtig, insbesondere bei vielen Änderungen wie einem Benutzerimport oder Schuljahreswechsel
    → SSDs sind stark empfohlen, alternativ performante Storage-Systeme (bspw. SAN und/oder 15K SAS-Platten und/oder RAID-Controller mit gutem Caching etc)
    → Mindestens die Datenbank-Partition der VMs (/var/lib/) muss auf schnelle Disks

ToDo:

  • Schulserver (UCS@school Standort-Server) sind hier noch nicht betrachtet
  • Dienste, die über die genannten hinausgehen (bspw. Groupware, xCloud …), müssen gesondert betrachtet werden

Größenordnung 1.000 User oder Pilot

Rolle Server Anzahl CPU (Cores) RAM (GB) Disk (GB) Umgebung Dienste
PDN / DC Master ucs001 1 4 8 80 - IAM, Portal, SAML-SSO, Self-Service
BDN / DC Backup ucs002 1 4 8 80 - IAM, Portal, SAML-SSO, Self-Service
RDN / DC Slave ucs006 1 4 8 80 - Read-Only LDAP for Apps

Größenordnung 25.000 User

Rolle Server Anzahl CPU (Cores) RAM (GB) Disk (GB) Umgebung Dienste
PDN / DC Master ucs001 1 4 16 100 - IAM
BDN / DC Backup ucs002 1 4 16 100 - IAM
BDN / DC Backup ucs003 1 8 16 100 - Portal, SAML-SSO, Self-Service
BDN / DC Backup ucs004 1 8 16 100 - Portal, SAML-SSO, Self-Service
RDN / DC Slave ucs006 1 4 16 100 - Read-Only LDAP for Apps
RDN / DC Slave ucs007 1 4 16 100 - Read-Only LDAP for Apps

Größenordnung 100.000 User

Rolle Server Anzahl CPU (Cores) RAM (GB) Disk (GB) Umgebung Dienste
PDN / DC Master ucs001 1 8 24 200 - IAM
BDN / DC Backup ucs002 1 8 24 200 - IAM
BDN / DC Backup ucs003 1 16 24 200 - Portal, SAML-SSO, Self-Service
BDN / DC Backup ucs004 1 16 24 200 - Portal, SAML-SSO, Self-Service
BDN / DC Backup ucs005 1 16 24 200 - Portal, SAML-SSO, Self-Service
RDN / DC Slave ucs006 1 4 24 200 - Read-Only LDAP for Apps
RDN / DC Slave ucs007 1 4 24 200 - Read-Only LDAP for Apps

Größenordnung 300.000 User

Rolle Server Anzahl CPU (Cores) RAM (GB) Disk (GB) Umgebung Dienste
PDN / DC Master ucs001 1 12 32 250 - IAM
BDN / DC Backup ucs002 1 12 32 250 - IAM
BDN / DC Backup ucs003 1 20 32 250 - Portal, SAML-SSO, Self-Service
BDN / DC Backup ucs004 1 20 32 250 - Portal, SAML-SSO, Self-Service
BDN / DC Backup ucs005 1 20 32 250 - Portal, SAML-SSO, Self-Service
RDN / DC Slave ucs006 1 8 32 250 - Read-Only LDAP for Apps
RDN / DC Slave ucs007 1 8 32 250 - Read-Only LDAP for Apps

Ergänzend:

5 Likes
Mastodon