Preparing the System
Total Page：16
File Type：pdf, Size：1020Kb
_____________________________________________________________ Preparing the System System Recommendations General Symas OpenLDAP will run on any system that meets the minimum requirements for the operating system where it is installed. Additional disk space and memory may be required to accommodate the application’s data. CPU Symas OpenLDAP makes very efficient use of the system CPUs. In most cases, systems with 1 to 4 processors are adequate for all but the heaviest workloads. For those, up to 8 processors may be appropriate, but beyond that the factors that affect performance the most are the amount of memory and the bandwidth between it and the processors, network bandwidth, and disk I/O bandwidth. Disk The Symas OpenLDAP packages will require approximately 25MB. In addition, there should be enough space to accommodate the projected database size, the index files, and the transaction logs. These will be in separate file systems. Memory As with any database-type application, having sufficient memory is the key to performance. The system should have approximately 10% more memory than is needed to accommodate the entire database and its index files, plus the base amount of memory recommended by the OS vendor. Preparing the System To prepare your system to host Symas OpenLDAP directory services we recommend the following: Disks & File Systems LDAP databases serviced by the back-mdb (preferred), back-hdb and back-bdb backends can be stored on direct-attached disks (best) or iSCSI network-attached storage (your mileage will vary). • For optimum performance, Symas recommends the use of at least three separate disk spindles (drives) for bdb/hdb backends and 2 spindles (drives) for mdb backends, each with its own independent file system. The first of these file systems should be dedicated to the database and its environment files, the second should contain the operating system and applications, and the final is for the database transaction logs (bdb/hdb only). The swap partition can be placed on the same drive as the operating system. This arrangement reduces drive head contention to the lowest possible point. RAID arrays do not enhance performance, but can be used to improve fault tolerance. df -h Example Output: Filesystem Size Used Avail Use% Mounted on /dev/mapper/centos-root 17G 2.2G 15G 13% / /dev/sda1 472M 169M 279M 38% /boot /dev/sdb1 470G 91G 356G 21% /var/symas /dev/sdc1 470G 429G 17G 97% /var/log • Test disk write speed (time it takes to sync data from cache to disk) by running the following command multiple times (to get an average). Requires BASH. sync; dd if=/dev/zero of=1g.bin bs=1G count=1 >/dev/null 2>&1; TIMEFORMAT="%Es Cache to Disk Sync Time"; time sync; rm -f 1g.bin Example Output: 1.275s Cache to Disk Sync Time 1.173s Cache to Disk Sync Time 1 | P a g e 3.833s Cache to Disk Sync Time Consider how many write operations per minute will be expected. If the Cache to Disk Sync Time when multiplied by 60 (seconds per minute) exceeds the expected writes per minute and the database backend to be used is MDB, see SLAPD.conf Customization → Database Section → Configuration → MDB section for optimization instructions. Warning: If MDB optimizations are required skip the following step. DO NOT disable journaling. • NOTE: For EXT4 partitions which are a journaling file system, disable the journaling for the file system that holds the database (MDB, HDB and BDB) and transaction log (HDB and BDB only) files. Since the Berkeley DB performs its own transaction management and journaling, file-system-based journaling only slows things down without adding any gains in reliability. mkfs –t ext4 –O ^has_journal <device> tune2fs –O ^has_journal <device> Example: mkfs –t ext4 –O ^has_journal /dev/xvdf/1 tune2fs –O ^has_journal /dev/xvdf/1 NOTE: Because journaling cannot be disabled for xfs file systems, we do NOT recommend using XFS. However, if XFS must be used, we recommend externalizing journaling to reduce the performance impact on the file system. To reserve an external journal with a specified size when you create an XFS file system, specify the -l logdev=device,size=size option to the mkfs.xfs command. If you omit the size parameter, mkfs.xfs selects a journal size based on the size of the file system. To mount the XFS file system so that it uses the external journal, specify the -o logdev=device option to the mount command. • Add the “noatime” (preferred) or “relatime” flag ONLY to the LDAP database partition sudo vi /etc/fstab UUID=foo /var ext4 noatime,errors=continue 1 1 sudo mount -a Swappiness Tune the OS disk cache for best performance Add new values to /etc/sysctl.conf: sudo vi /etc/sysctl.conf vm.dirty_background_ratio = 50 vm.dirty_ratio = 90 vm.swappiness = 0 vm.dirty_writeback_centisecs = 500 vm.dirty_expire_centisecs = 60000 For more information on Disk caching and Performance tuning, please see the following: https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm- dirty_ratio/ https://www.kernel.org/doc/Documentation/sysctl/vm.txt 2 | P a g e Processes Minimize the number of unneeded processes running on the system, particularly any that use a lot of memory or processor bandwidth, as these will have an adverse impact on directory server performance. In particular, be on the lookout for Java processes, as these tend to use large quantities of processing time and available memory. Additionally, ensure any processes using network ports required for OpenLDAP are disabled. Network & Firewall The default ports used by Symas OpenLDAP are 389/TCP for LDAP, 636/TCP for LDAP over SSL, and 88/TCP and 88/UDP for Kerberos key distribution (kdc). On many systems the netstat command can tell you about the ports that are in use and the processes that are using them. IPTables First, let’s ensure IPTables is installed which iptables For newer versions it is important to disable FirewallD before installing IPTables sudo systemctl stop firewalld sudo systemctl disable firewalld sudo systemctl mask firewalld sudo yum install iptables-services -y sudo systemctl enable iptables Adjust iptables to save changes on stop/restart by inserting the following: sudo vi /etc/sysconfig/iptables-config IPTABLES_SAVE_ON_STOP="yes" IPTABLES_SAVE_ON_RESTART="yes" Adjust iptables allow LDAP and LDAPS protocol. This is done by adding the rules in red lines below. sudo vi /etc/sysconfig/iptables sudo apt-get update sudo apt-get install iptables-persistent Adjust iptables to allow LDAP and LDAPS protocol. This is done by exporting the current settings and adding the rules in red below. sudo iptables-save > iptables.rules 3 | P a g e sudo vi iptables.rules :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [192:19802] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 389 -j ACCEPT -A INPUT -p tcp -m tcp --dport 636 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT Be aware that the order is critical in the rules. Port 22 is for SSH Port 389 is for LDAP and LDAP over TLS 636 is for LDAPS Save the Changes to IPTables Note: The IPTables config is stored in /etc/sysconfig/iptables, and this is the file you have to update, otherwise the info will not be kept. Restart of the IPTables service. sudo systemctl restart iptables.service Or sudo service iptables restart Save the changes sudo service iptables save Verify the changes iptables –L -nv Import the iptables.rules file and save the changes sudo iptables-restore < iptables.rules sudo service iptables-persistent save Restart the IPTables Service sudo service iptables-persistent reload Verify the changes iptables -S 4 | P a g e FirewallD FirewallD is frontend controller for iptables used to implement persistent network traffic rules. It provides command line and graphical interfaces and is available in the repositories of most Linux distributions. Working with FirewallD has two main differences compared to directly controlling iptables: 1. FirewallD uses zones and services instead of chain and rules. 2. It manages rulesets dynamically, allowing updates without breaking existing sessions and connections. Note: FirewallD is a wrapper for iptables to allow easier management of iptables rules-it is not an iptables replacement. While iptables commands are still available to FirewallD, it’s recommended to use only FirewallD commands with FirewallD. FirewallD is included by default with RedHat 7+ but it’s inactive. Controlling it is the same as with other systemd units. To start the service and enable FirewallD on boot: sudo systemctl start firewalld sudo systemctl enable firewalld To stop and disable it: sudo systemctl stop firewalld sudo systemctl disable firewalld To check the firewall status. The output should say either running or not running. sudo firewall-cmd --state To view the status of the FirewallD daemon: sudo systemctl status firewalld Example output: firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled) Active: active (running) since Wed 2015-09-02 18:03:22 UTC; 1min 12s ago Main PID: 11954 (firewalld) CGroup: /system.slice/firewalld.service └─11954 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid To reload a FirewallD configuration: sudo firewall-cmd reload sudo systemctl enable firewalld Configuring FirewallD Firewalld is configured with XML files. Except for very specific configurations, you won’t have to deal with them and the firewall-cmd should be used instead. 5 | P a g e Configuration files are located in two directories: /usr/lib/FirewallD Holds default configurations like default zones and common services.