It’s generally recommened that in a typical time server setup, that 3 time sources should be used to ensure an accurate time is provided to a network. NTP/Chrony/gpsd as far as I can tell, does not (properly) support multiple GPS serial/PPS signals under one system, which would mean for a “proper” setup, one would need 3 seperate physical systems. But what if all 3 systems could be combined into 1 using virtual machines?
I know the topic of using NTP/Chrony in a virtual machine has come up here and there, and the general consesus seems to be that in a modern system it should be ok to serve time from a VM with either daemon, (though bare metal would be ideal). However, setting up a single system with multiple virtual machines, each with thier own GPS/PPS setup, one could have 3 independant time sources under one machine. Sure, redundancy goes out the window if the host machine goes down, but you wouldn’t need to run 3 seperate physical systems for a proper time server setup.
Before I go down this road and experiment with such a setup, has anyone tried this before?
I personally think Raspberry Pis and BeagleBones are cheap enough that having 3 independent servers, each with their own GPS receiver, is viable. It means you can put them at different locations with different views of the sky, and thus get better overall coverage.
Which is what’s recommended for a proper time server setup, I understand that. But in my case, all 3 units would be installed in the same location, the only difference in sky view being how far a couple of feet of coax will reach. I’m just trying to consolidate 3 seperate units into 1, seeing as how I’m going to have normal PC hardware as one of the units because of other software/hardware needs. I could skip having to use and power 2 additional RPi’s just for time service. All I would need is a 2 port serial PCIe card and Proxmox should be able to assign each individual serial port to each VM running a time server.
Hence the question, has anyone tried such a setup, and what was your results? The good? The bad? Did it even work? Caveats? Hypervisor/OS quirks?
You keep referring to this, and to that implying that three sources would be needed, but in another place refer to three systems. I have a feeling that there may be a bit of misunderstanding here.
It is typically recommended that a single server have (at least) three sources of time, e.g., one stratum 0 (reference clock) and two (or more) lower stratum sources (other NTP servers). Some reasons for that are for the single server to have some redundancy in sources (thus more than one source, depending on requirements), and for the server to be able to derive a majority from among its sources (thus an odd number of sources). That is for a single server (or client for that matter), e.g., one contributing to the pool.
When you talk about multiple systems, then maybe that is if you want to provide time service to a certain set of clients, e.g., if operating a private network. In that case, if yours are the only sources of time (and, e.g., no external sources are available/reachable), then the recommendation for your clients to have three sources of time would translate to the need for three systems/servers to be available in your environment. How you realize that depends on your requirements. I.e., what scenarios you want to guard against, e.g., likelihood of some system becoming a falseticker, need to take systems offline every now and then for maintenance, or if you need to guard against hardware failures.
Not sure what kind of setup you have in mind, or why you think this wouldn’t work from a technical point of view. Having multiple sources of time (stratum 0 in that case) was not the driver for doing it (I have separate upstream systems both locally as well as externally for that), so not sure whether I missed something. But I have some systems running that have two or three GNSS-based reference clocks attached to them without issue, using gpsd and ntpd classic. It’s not redundant in multiple ways, e.g., some of the GNSS receivers share a common antenna. But as said, I am not after redundancy, but from gpsd/ntpd functional point of view, I don’t see an issue.
So it really depends on what you want to achieve, see above discussion on why, and how, three sources of time for clients.
E.g., if the point is to provide three GNSS-based time sources to a single NTP server, e.g., one contributing to the pool, then gpsd/ntpd/… should work. It is up to (external) clients of your server to then take care of in turn having at least two additional time sources besides yours.
If you want a different sort of time source redundancy on your end, and anyhow plan to operate three servers in some constellation, e.g., for contributing to the pool, or need to serve local clients without access to separate time sources, then you could set up three servers/systems to do so, each having one GNSS-based reference time source, and using the respective two other systems as second and third sources. Reference sources typically (in my experience) being chosen over lower stratum remote sources, the majority argument would be moot as long as the reference source is available and not totally off, but you’d at least have two backup sources for each server should one server’s reference source fail for some reason. And dependent local clients would have three local time sources. (Clients of the pool wouldn’t care as they’d anyway pick redundant sources from the pool, or from elsewhere, as per client operator responsability.)
I understand what you’re trying to do; I’m just not sure the value is there.
If I had your goals in mind, I would just hook up all 3 units to the bare metal machine, and define them all in the chrony/ntpd config, then use PHC in the VMs to track the host. VMs can track their hypervisor extremely closely, as I wrote recently.
I’ve got another post brewing where I’ll compare VMs with bare metal, but here’s a spoiler: unless you’ve got local GPS hardware attached to the system or are running a PTP instance with full switch & NIC support, it’s actually harder to keep bare metal super close to its sources than it is for VMs. Which is why I’d recommend doing the tracking on the host.
Virtual machine hardware based on software simulation may have significantly lower clock accuracy, while hardware entities may have better time accuracy
Virtual machine hardware based on software simulation may have significantly lower clock accuracy, while hardware entities may have better time accuracy
That has been the traditional wisdom for some time. The data I’m going to present in my next post on the topic is presently pointing in the opposite direction.
I haven’t ran multiple sources like GNSS/DCF77 radio etc. on a single machine.
But what I have done in small networks with a maximum of 1 external stratum 0/1 source like in my home network is to try and distribute at least the ntp servers clients use to all the available ressources like switches and virtual servers local to the network so that at least 3 sources should be available.
The servers and switches then use the local GNSS or radio receiver, some external ntp servers and all available internal servers (physical hosts and VMs) as source. I know that this is not totally resilient against all types of outages, but it at least protects against some reboots/firmware upgrades, loss of the internet connection and partly against power outages like a tripped breaker.
If an access switch looses power or gets upgraded any client connected with a single connection to the network is cut off anyway, so there is no time service, but no network either, so no problem in my book.
If the internet connections to the outside dies, then the network relies essentially on just one true source to hold over and that is enough for most small business applications, especially today where you have maybe some internal applications and file servers available to you locally, but with the internet going down all outside connection like email and VOIP is dead anyways
