----- "Francis Swasey" Frank.Swasey@uvm.edu wrote:
Is the info in this section intended for only physical LDAP servers or
for servers that are virtual (such as VMware) as well?
Physical servers are faster as you have more control over the disks that aren't shared underneath.
On Saturday, 9 January 2010 22:30:09 Gavin Henry wrote:
----- "Francis Swasey" Frank.Swasey@uvm.edu wrote:
Is the info in this section intended for only physical LDAP servers or
for servers that are virtual (such as VMware) as well?
Physical servers are faster as you have more control over the disks that aren't shared underneath.
This isn't necessarily always the case. E.g., with Xen or KVM, you can quite easily dedicate a block device on the physical server to a specific virtual machine, which could be a local or remote (say, a LUN on a SAN array which has a few hundred spindles behind it) device. You aren't limited to using file- backed images.
With VMWare with storage virtualisation, AFAIK, you could have virtual HBA(s) (with it's own dedicated WWN) accessing LUNs on a SAN.
Note that Red Hat has published some benchmarks with MySQL, showing that KVM has better CPU scalability than MySQL, and it is actually more beneficial to run MySQL VMs on hosts with more than about 8 cores, instead of running on the "bare metal".
Regards, Buchan
On 1/9/10 4:30 PM, Gavin Henry wrote:
----- "Francis Swasey" Frank.Swasey@uvm.edu wrote:
Is the info in this section intended for only physical LDAP servers or
for servers that are virtual (such as VMware) as well?
Physical servers are faster as you have more control over the disks that aren't shared underneath.
While that is usually true -- does it really answer the question I asked? Just because physical servers are normally faster does not to me imply that this section of the Admin Guide was written with only Physical servers in mind.
So, let's say I'm crazy and I want to investigate putting ldap servers on VMware Guests --- do I care about any of the directions in section 21.1.2 about separating the logs and the db or not?
----- "Francis Swasey" Frank.Swasey@uvm.edu wrote:
On 1/9/10 4:30 PM, Gavin Henry wrote:
----- "Francis Swasey" Frank.Swasey@uvm.edu wrote:
Is the info in this section intended for only physical LDAP servers
or
for servers that are virtual (such as VMware) as well?
Physical servers are faster as you have more control over the disks
that aren't shared
underneath.
While that is usually true -- does it really answer the question I asked? Just because physical servers are normally faster does not to me imply that this section of the Admin Guide was written with only Physical servers in mind.
So, let's say I'm crazy and I want to investigate putting ldap servers
on VMware Guests --- do I care about any of the directions in section
21.1.2 about separating the logs and the db or not?
Yes, that still applies for best performance.
Le 11/01/2010 18:08, Gavin Henry a écrit :
So, let's say I'm crazy and I want to investigate putting ldap servers
on VMware Guests --- do I care about any of the directions in section
21.1.2 about separating the logs and the db or not?
Yes, that still applies for best performance.
I may be wrong, but write to DB logs only apply when changes occurs in the directory. So the gain for separating logs and data file are mostly sensible if you have lots of changes. And without exact numbers, it's hard to say if is really worth, especially on fask disk with large throughput.
Guillaume Rousse wrote:
Le 11/01/2010 18:08, Gavin Henry a écrit :
So, let's say I'm crazy and I want to investigate putting ldap servers
on VMware Guests --- do I care about any of the directions in section
21.1.2 about separating the logs and the db or not?
Yes, that still applies for best performance.
I may be wrong, but write to DB logs only apply when changes occurs in the directory. So the gain for separating logs and data file are mostly sensible if you have lots of changes. And without exact numbers, it's hard to say if is really worth, especially on fask disk with large throughput.
Basically true. But you should realize that a lot of things that one would normally expect to be read-only operations may actually be read-write. For example, if you're authenticating to a server that logs authentication successes and failures.
Ultimately, whether the app layer is virtualized or not, multiple spindles at the physical layer is a win. If all of the filesystems in your VM are mapped onto a single disk in the host, your performance is going to be swamped by all the seek overhead, and that's true regardless of whether it's read or write traffic. (Possible exception: for readonly traffic on an SSD, the seek overhead is pretty small. Still measurable, but compared to rotating disc media, it's negligible.)
Any sysadmin worthy of the title ought to understand that. This is not specific to OpenLDAP administration, this is the way computer systems work. The VM case doesn't bear highlighting in the OpenLDAP docs.
On Mon, Jan 11, 2010 at 9:02 AM, Francis Swasey Frank.Swasey@uvm.edu wrote:
So, let's say I'm crazy and I want to investigate putting ldap servers on VMware Guests --- do I care about any of the directions in section 21.1.2 about separating the logs and the db or not?
From my experience that stuff is more relevant when you are worried
about performance on a physical server. I don't know much about how vmware handles io distribution when a single VM is making requests to separate disks, but I suspect that you would get slightly better performance even in vmware when the db is in a different disk than the logs.
In general I have had pretty rotten experiences with running a LDAP server on a VM. I have noticed that the db tends to get corrupted (or have problems with replication) when the server is running on a VM. These problems tend to happen a lot less when stuffs running on a physical server.
HTH
Aravind.
openldap-software@openldap.org
-
Aravind Gottipati -
Buchan Milne -
Francis Swasey -
Gavin Henry -
Guillaume Rousse -
Howard Chu