A setup for proxmox and redundancy

[debolaz]

As I've probably mentioned a few times before, we've been evaluating Proxmox and a few other open source products for virtualization in our server park. Proxmox satisfies many of our requirements... No, I can phrase that better: Proxmox is a delight to work with. It's easy to use, simple, yet capable of quite complex things through both a web interface and a powerfull command line interface.

But there are a few issues. Not problems with Proxmox as such, but questions of how well it fits as a solution to some of the problems we're trying to solve. A big problem we have is that few of our servers has any redundancy. We have extensive backups, but even with that, it will often take hours upon hours before we've set up another server to replace the downed one and this is one of the main problems we're trying to solve. What I want a virtualization framework to do, is make it trivial, perhaps even make it happen automagically, to start up a virtual server up on alternate nodes if the node running the virtual server in question goes down.

With the release of the Proxmox 1.4 beta, Proxmox seems to have become a real candidate for solving this problem. Now, we can host all virtual server images on a central (And possibly redundant) storage server. So my question now is, how will Proxmox deal with a node that goes missing from the cluster? Can the cluster controller allow an administrator to migrate a virtual server whose image is hosted on a shared storage from the missing node over to a functional one without having the missing node connected? And ensure that the missing node, upon reconnection, understands that it is no longer in charge of said virtual server?

 

[dietmar]

Can the cluster controller allow an administrator to migrate a virtual server whose image is hosted on a shared storage from the missing node over to a functional one without having the missing node connected? And ensure that the missing node, upon reconnection, understands that it is no longer in charge of said virtual server?

Only if you have a copy of the config file (you can rsync that manually). But HA is on our roadmap. The plan is to integrate corosync and pacemaker.

 

[debolaz]

Only if you have a copy of the config file (you can rsync that manually)

So config files are not kept by the cluster manager node?

 

[tom]

So config files are not kept by the cluster manager node?

manually means manually - otherwise its automatically.

 

[debolaz]

manually means manually - otherwise its automatically.

It just struck me as a little bit odd. But anyway, as I've understood it:

• The config files from all nodes should then be rsynced to a central machine (Possibly the cluster manager node)
• If a node fails, the configuration files should be copied to other nodes and no changes should be neccesary to do to the config files themselves?

I just want to be sure that when a node goes down, the amount of work needed to get a single virtual server running again will be in the area of < 5 minutes, not 50.

 

[tom]

It just struck me as a little bit odd. But anyway, as I've understood it:

• The config files from all nodes should then be rsynced to a central machine (Possibly the cluster manager node)
• If a node fails, the configuration files should be copied to other nodes and no changes should be neccesary to do to the config files themselves?

I just want to be sure that when a node goes down, the amount of work needed to get a single virtual server running again will be in the area of < 5 minutes, not 50.

nothing odd, its just not all implemented yet. if you want that functionality you need to do it by yourself.

 

[debolaz]

nothing odd, its just not all implemented yet. if you want that functionality you need to do it by yourself.

No, I think you misunderstood me. Since most of the administration of these servers are done through the cluster managers web interface, I had the impression that the config files were changed on the cluster manager, then synchronized to the nodes, so it would have a copy of them by design. I realize now of course that this isn't the case, but just so you don't think that I meant it was odd that it wasn't implemented yet.

 

[tom]

No, I think you misunderstood me. Since most of the administration of these servers are done through the cluster managers web interface, I had the impression that the config files were changed on the cluster manager, then synchronized to the nodes, so it would have a copy of them by design. I realize now of course that this isn't the case, but just so you don't think that I meant it was odd that it wasn't implemented yet.

oh, yes. the plan is to have a perfect new cluster setup and as you can imagine this is not that easy to achieve. as always, we want an extremely easy to use system.

there are enough solutions outside but nothing with easy setup and config like we plan. it would be easy to do what all others do but that not our goal.