Disclaimer
This article is meant as a collection of best practice advices for the partitioning and partition sizing of UCS instances (test as well as productive environments). This can, however, not account as a comprehensive list of all relevant parameters.
Introduction
In the event of excessive logging (e.g. when the log level has been set high and/or the system performs multiple user imports, etc.), log files can become so large that it exceeds the capacity of the partition they are located on. If this overflow occurs on the root partition, it interferes with the LDAP-database and thereby disables the entire system. To prevent this from happening, it is recommended to create separate partitions for certain log files and other storage intensive data during the initial setup of UCS.
1. Always use LVM!
Instead of locating the above mentioned files directly on the root partition, the root partition should serve as a mount point for subordinate partitions. Additionally it is also advised in any case to create disk storage with Logical Volume Management (LVM). LVM provides a way to create and manage logical volumes, which are virtualized storage devices that can span across one or more physical disks. This allows for more flexibility in managing storage space even after the initial setup of the respective UCS instances. But before turning to the practicalities of creating partitions with LVM in the last chapter, we would like to draw attention to the following aspects first.
2. General recommendations for handling disk storage
Familiarize yourself with the hardware resources on which the UCS instances are to be operated (Reference: Best Practice: Sizing fĂĽr UCS als IDM (german only)). Especially in case of services and events that require many changes in a short amount of time (such as user imports or change of school year), performance characteristics of disk storage such as IOPS should be considered. This means:
- SSDs are strongly recommended, alternatively high-performance storage systems (e.g. SAN and/or 15K SAS disks and/or RAID controllers with good caching, etc.).
- At least the database partition of the VMs (
/var/lib/) should be on fast disks (Reference: this chapter of the UCS@school scenarios documentation (german only)).
For estimating the overall storage space that should be provided by (virtualised) disks we rely on the numbers given in Best Practice: Sizing fĂĽr UCS als IDM (german only), which provides four different example scenarios:
Scenario A: for about 1.000 users (80 GB overall disk storage per server)
Scenario B: for about 25.000 users (100 GB overall disk storage per server)
Scenario C: for about 100.000 users (200 GB overall disk storage per server)
Scenario D: for about 300.000 users (250 GB overall disk storage per server)
Annotations:
- Different UCS-servers that are part of the same UCS-domain should use an identical amount of disk storage, regardless of the respective server roles (Primary Directory Node (PDN), Backup Directory Node (BDN), Replica Directory Node (RDN)). For more details see Best Practice: Sizing fĂĽr UCS als IDM (german only) as well.
- For particularities of UCS@school, see chapter 4 and consult Szenarien zum Einsatz von UCS@school (german only)
- To optimize the performance of the individual servers, see also Univention Corporate Server - Performance guide (english only)
Every UCS-instance that is more than just a personal testing environment, should separate at least /var/log AND /var from root (/). /home, on the other hand, is to be separated only if there is user data stored on the system (see chapter 3 and 4 respectively). Considering this, the following table serves as a further reference point for partition sizes:
| Partition | Purpose |
|---|---|
/ |
Separating the system root directory |
/var/log |
Storing system log files (including all UCS-specific log files) separate from everything else |
/var |
Also storing the rest of variable data separately |
swap |
Separating the location of the swap space from RAM |
/tmp |
Separating temporary files (can also lead to difficulties when tmp-files are supposed to be moved/copied into other directories |
/var/lib |
placing I/O-intensive services on separate fast disks (see chapter 2) |
However, it is not recommend to base partition sizes on the number of users and system roles alone. In any case it is necessary to assess the specific requirements of the customer for the scope of the UCS system and the services provided with it (Windows-Clients Management (Samba), E-Mail (OX), Cloudservice (Nextcloud, ownCloud), etc.).
3. Service-specific recommendations
Following table collects use cases for specific services to consider (Reference: Best Practice: Recommended storage space and partitioning scheme). However, partition sizes cannot be given, because they vary too much depending on the overall constellation of services used in a specific customer scenario.
| Additional partition | Customer demand |
|---|---|
/var/spool/dovecot/ |
Using UCS as a Mailserver (Reference: english / german); additionally large user numbers can also lead to a lot of index files being written into the dovecot-cache. In some cases it might therefore be recommendable to also create a separate partition for the dovecot-cache as well. |
/var/univention-backup/ |
Nightly backup of the Univention Configuration Registry, OpenLDAP and Samba database, as well as the contents of the SYSVOL share (Reference: this chapter of the UCS@school scenarios documentation (german only)). To remove outdated backups after a year automatically: ucr set backup/clean/max_age=365 (Reference: english / german) |
/var/lib/univention-ldap/ |
Having the LDAP directory database on separate storage i.e. SSD (Reference: english / german) |
/var/lib/univention-repository/ |
Create your own UCS Repository Mirror (Reference: english / german) |
/var/lib/univention-appcenter/ |
App Center integrations may store user-data in this directory |
Once the general setup and additional service requirements are specified, the demand for disk storage can be estimated according to the size of the LDAP database (which in turn grows with the number of LDAP objects (mainly users)). This means, after covering the basic requirements the demand of storage space for each partition roughly increases proportionately with the number of users.
4. UCS@school replica
If you are planning to install a UCS@school replica, you need to consider creating a separate partition for /home for your users’ data. Here, the number of concurrently active user accounts and devices plays a crucial role. The following numbers are taken from this chapter of the UCS@school scenarios documentation (german only).
Minimum system requirements for small schools (e.g., primary schools) (25 computers, 150 user accounts):
- Up to 100 GB storage space for user data
Minimum system requirements for medium-sized schools (100 computers, 600 user accounts):
- starting at 400 GB storage space for user data
Minimum system requirements for large schools (e.g., vocational schools) (300 computers, 1500 user accounts):
- starting at 1.000 GB storage space for user data
5. Partitioning of UCS
Unfortunately, during the standard installation process of UCS the debian installer only offers three preconfigured partitioning schemes:
- All files in one partition (“recommended for new users”)
- Separate
/home - Separate
/home,/var,/tmp
None of these match the criteria mentioned above. That means, that it is essential to perform the partitioning manually! This article gives a comprehensive instruction, including how to perform the manual partitioning itself (chapter 2.0) as well as how to set up LVM (chapter 4.0).
Eventually, we would also like to point out, that in the course of setting up LVM the choice of file system may be of importance. Different file systems can have an effect on the performance and eventually the customer should decide, what they expect from it. The default of ext2/3/4 might not always be the best choice in every case (Reference: How to Choose Your Red Hat Enterprise Linux File System).