Has anyone tried mirroring or multimaster under VMware i.e. are the virtual clocks stable enough? We're starting to use VMware to cut down on the number of physical hosts, but I'd like to use the latest 2.4 features as well.
Dave Horsfall wrote:
Has anyone tried mirroring or multimaster under VMware i.e. are the virtual clocks stable enough? We're starting to use VMware to cut down on the number of physical hosts, but I'd like to use the latest 2.4 features as well.
I don't have any long-term experience with that setup, just use VMware for short-duration tests. My suspicion is that the clock stability isn't very good, and ntpd can't correct for it...
yes, there are issues with a clock in vmware virtual hosts. ntpd is not a solution, the right way is to run ntpd on physical machine and set up virtual machines to sync clock with the physical one (using vmware tools)
M.
On Tue, 2008-07-29 at 18:21 -0700, Howard Chu wrote:
Dave Horsfall wrote:
Has anyone tried mirroring or multimaster under VMware i.e. are the virtual clocks stable enough? We're starting to use VMware to cut down on the number of physical hosts, but I'd like to use the latest 2.4 features as well.
I don't have any long-term experience with that setup, just use VMware for short-duration tests. My suspicion is that the clock stability isn't very good, and ntpd can't correct for it...
Martin Simovic wrote:
yes, there are issues with a clock in vmware virtual hosts. ntpd is not a solution, the right way is to run ntpd on physical machine and set up virtual machines to sync clock with the physical one (using vmware tools)
Even that is insufficient; the clock synchronization is neither continuous nor deterministic so there are long periods of time where the virtual clocks drift before they're corrected by the next sync.
M.
On Tue, 2008-07-29 at 18:21 -0700, Howard Chu wrote:
Dave Horsfall wrote:
Has anyone tried mirroring or multimaster under VMware i.e. are the virtual clocks stable enough? We're starting to use VMware to cut down on the number of physical hosts, but I'd like to use the latest 2.4 features as well.
I don't have any long-term experience with that setup, just use VMware for short-duration tests. My suspicion is that the clock stability isn't very good, and ntpd can't correct for it...
On Wed, 30 Jul 2008, Howard Chu wrote:
Martin Simovic wrote:
yes, there are issues with a clock in vmware virtual hosts. ntpd is not a solution, the right way is to run ntpd on physical machine and set up virtual machines to sync clock with the physical one (using vmware tools)
Even that is insufficient; the clock synchronization is neither continuous nor deterministic so there are long periods of time where the virtual clocks drift before they're corrected by the next sync.
So *that* explains the many critical NTP warnings that I get from Nagios when I monitor the remote host/guest...
Howard Chu wrote:
Dave Horsfall wrote:
Has anyone tried mirroring or multimaster under VMware i.e. are the virtual clocks stable enough? We're starting to use VMware to cut down on the number of physical hosts, but I'd like to use the latest 2.4 features as well.
I don't have any long-term experience with that setup, just use VMware for short-duration tests. My suspicion is that the clock stability isn't very good, and ntpd can't correct for it...
Thinking about this some more - why would you ever do this? If you're consolidating many physical servers into a single physical server, just run a single slapd on the consolidated server. You'll have more RAM available and much less overhead.
The only good reason to run multiple masters is when you actually have multiple physical servers, and they're set up such that they won't typically all fail at once (e.g., in geographically remote locations so that a disaster in one location doesn't affect the others). If all of your servers are going to just be in VMs running on the same machine, and they're all replicating with each other, you have no hardware redundancy, so you may as well just run a single slapd on the real machine.
Howard Chu wrote:
Thinking about this some more - why would you ever do this? If you're consolidating many physical servers into a single physical server, just run a single slapd on the consolidated server. You'll have more RAM available and much less overhead.
You would do this if you had disparate data centers with virtual infrastructure clusters in each data center where you required the redundancy of multiple masters at each data center but did not want to maintain disparate directories.
Where I'm from, people do not run a single ESX host, they run clusters of ESX hosts with 20-40 virtual machines on each host with hundreds of virtual machines in each cluster. The benefits are seen only with multiple ESX hosts.
All the best,
On Wed, 30 Jul 2008, Howard Chu wrote:
Thinking about this some more - why would you ever do this? If you're consolidating many physical servers into a single physical server, just run a single slapd on the consolidated server. You'll have more RAM available and much less overhead.
That's the point; I'm looking for arguments against it, should it ever come to pass.
They're unlikely to all be on the same server of course, but I really don't want them virtualised at all.
Howard Chu wrote:
Howard Chu wrote:
Dave Horsfall wrote:
Has anyone tried mirroring or multimaster under VMware i.e. are the virtual clocks stable enough? We're starting to use VMware to cut down on the number of physical hosts, but I'd like to use the latest 2.4 features as well.
I don't have any long-term experience with that setup, just use VMware for short-duration tests. My suspicion is that the clock stability isn't very good, and ntpd can't correct for it...
Thinking about this some more - why would you ever do this?
1. Separation of operational processes at machine-level. 2. Importing, exporting, cloning, taking snapshots of VMs (e.g. I'm often preparing machines with VMWare workstation which are then imported into GSX/ESX server.) 3. HA with ESX cluster setups. ...
If you're consolidating many physical servers into a single physical server, just run a single slapd on the consolidated server. You'll have more RAM available and much less overhead.
Sometimes scaling up does not have the highest priority.
If all of your servers are going to just be in VMs running on the same machine, and they're all replicating with each other, you have no hardware redundancy, so you may as well just run a single slapd on the real machine.
One of my customers is running a VMWare ESX cluster in two separate datacenters. Very handy.
Ciao, Michael.
Dave Horsfall wrote:
Has anyone tried mirroring or multimaster under VMware i.e. are the virtual clocks stable enough? We're starting to use VMware to cut down on the number of physical hosts, but I'd like to use the latest 2.4 features as well.
I have several multi-master setups running under VMware 3.0.2 and have been so for around 6 months without any issues. Timekeeping has not been an issue.
Dave Horsfall wrote:
Has anyone tried mirroring or multimaster under VMware i.e. are the virtual clocks stable enough?
This very much depends on the hardware your host system is running on and the guest OS you're using.
Example but without OpenLDAP: I've prepared a VM running Debian Linux 4.0 Etch for a customer with VMWare workstation on my old Linux notebook and had many time sync problems running it locally. But I did not bother tweaking the guest OS' kernel settings for solving this because in production it runs on a ESX cluster on very fast hardware. No clock sync issues there at all. BTW: It's using Kerberos so everybody would recognize a significant clock skew. ;-)
There is clock sync information by VMWare.
Ciao, Michael.
On Thu, 31 Jul 2008, Michael Ströder wrote:
This very much depends on the hardware your host system is running on and the guest OS you're using.
Host is Ubuntu 8.04.1 on dual-core 3GHz Intel, 2Gb memory, and the guest is FreeBSD 7.0. I know that none of this is officially supported, but I had no say in it. The box is going to get more memory soon, as it can barely support three virtual hosts.
[...]
There is clock sync information by VMWare.
The fix for a FreeBSD guest is "kern.hz=100". I've been monitoring the host with Nagios, and I've seen the NTP clock drift by up to a minute before re-syncing; probably not good for ordinary replication...
openldap-technical@openldap.org
-
Dave Horsfall -
Howard Chu -
Josh Miller -
Martin Simovic -
Michael Ströder