William E Jojo w.jojo@hvcc.edu writes: [...]
"Singh, Devender (GE Capital, consultant)" Devender.Singh2@ge.com writes:
Hi Dieter, Please find the below details:
- hardware related
- type of storage - Simply SATA had disk attached. - raid level, if any- No RAID - file system of disk(s)- ext3 on LVm - type of network, 100MB, 1G, 10G
- is this host running on a virtual machine or on bare metal.
- if virtual machine, -Yes, OS installed on VM -- what type ---Don’t know
There is nothing suspicious, except for the virtual machine. Your really should carefully check layout and configuration of this VM, do not use virtual disks.
Hi Dieter,
Could you kindly explain what this means? I've been all over the inter-webs and I'm not finding anything concrete about OpenLDAP and VM's or Databases and VM's in general. The closest I came was about some database latency studies and some VMware propaganda.
My comments are based on my own experience. I am not against virutal machines in principle, but only against full virtualisation, that is virtualised disks and cpus, in a production environment. A para virtualisation might be acceptable, if the hypervisor provides sufficient resources and exclusive read/write access to a disk and client connections are moderate. But in all cases you have to expect performance loss.
We are about to launch a master and two replicas (utilizing delta-syncrepl) running in Ubuntu 10.04 on a VMware VSphere ESXi 4.0 cluster with four IBM x3650-M2's (2 Quad Nahalem and 64GB memory each) with virtual disks carved from NFS mounts to all of the VSphere servers in the cluster to facilitate HA and FT - by the VMware book.
(BTW, I took one of Howard's old posts to heart and we are following the Ubuntu playbook and we have purchased Canonical 24x7 support/maintenance. :-) )
We have had no problems with this environment in development and get better results than on bare metal with or without RAID. I know that it is recommended that the logs live on another "disk" from the database and RAID is frowned upon, but I have difficulty with a few points:
- Separate, unprotected disks seems illogical. The last log and the
BDB files are necessary to start BDB in slapd, correct? So, if you lose either disk, you're in trouble. Backups are ok, but daily seems too long a time. Seeing as we process new user accounts every 15 minutes, this would not be ideal for us.
Yes, slapd requires the last transaction logs in order to recover a corrupted database, but the risks can be minimized by setting appropriate checkpoints. Writing new entries every 15 minutes wouldn't cause much trouble if you checkpoint every 4K and every 3 minutes.
- RAID-1 I can understand having an issue on writes. But what about
LUNs in FC from a NetApp 3140? Virtual disks on NFS in VMware? Both of these are in the best practices of both VMware and NetApp documentation.
Just a scenario based on my own experience: a organisation wide addressbook with some 100,000 user entries, each user may have arbitrary private addressbooks underneath its entry node. Mail clients use this addressbook for address completion, mail clients are badly configured to use the root entry as search base. Can you imagine the number of parallel read operations? In addition to this read operations consecutive write operations of adding new entries, writing to index databases writing transaction logs. If you do not allow the transaction logs to reside on a different disk, you sure will experience db deadlocks in search opeerations.
- 13-disk 7200RPM SATA RAID-DP (NetApp) is far faster than a single
disk, dual diak or RAID-1, so why wouldn't you use SAN/NAS storage?
I seriously want to understand the VM concern as it pertains to OpenLDAP. I think more and more people are doing this very thing and will benefit from this discussion.
The main concern is performance. If you only expect a few connections per second, performance is not a questions, but if you expect a few thousend connections per second, performance is an issue.
[...]
-Dieter