Portal Home > Knowledgebase > Articles Database > DRBD vs. VMware for cPanel
DRBD vs. VMware for cPanel
| Posted by trustedhosting, 12-19-2010, 11:04 PM |
| Hello, I am looking at all options for true fail-over/redundancy in a cPanel environment. I have been trying to compare VMware's ESX solution to DRBD. I come form a VMware background and I'm new to DRBD. Here are some questions and notes:
This is a simple setup with two cPanel servers, making sure the hardware and data are fully redundant and no intervention needs to be made when a failure occurs... clients will just keep on running without noticing the failure.
Has anyone had any experience with either of these solutions, using them for cPanel failover?
What would would you recommend and why?
I don't care about the licensing, weather it's opensource or not.
I'm more interested in the ease of operation and life-cycle.
I want a solution that allows me to sleep at night knowing it's rock solid.
I'd be willing to spend more capital on the solution if it requires less staff to operate and minimal support.
What are the ballpark prices for this?
Are there other solutions I should be looking at?
-mike
|
| Posted by david510, 12-20-2010, 01:37 AM |
| We can realize a failover system using the DRBD and heartbeat technology. We can use OpenVZ to setup this. The /vz partition will be failed over in case of server down. We will need a dedicated internal connection between two nodes, which will be needed for the DRBD data synchronization. We have realized this kind is systems successfully.
|
| Posted by trustedhosting, 12-20-2010, 02:00 AM |
| Apparently I can't PM you yet, becuase I don't have enough posts. Here's what I wanted to PM you:
Would this be real-time or near real-time? I'd want this to be transparant to the customers. We would need ot make sure that our e-commerce customers don't loose a single transaction... among other things like e-mail and database processing.
Would you be interested in writing up a full proposal for me with requirements, features, and prices?
Regards,
-Michael
Last edited by trustedhosting; 12-20-2010 at 02:04 AM.
|
| Posted by david510, 12-20-2010, 04:57 AM |
| This would be real time and customers never know the if the failover is taking place. Imagine a user is downloading a file and server fails, the downloading session is not broken and user can continue downloading the file. Everything will be failed over to the new system.
|
| Posted by YUPAPA, 12-20-2010, 04:58 AM |
| That is just replicating the data real time, but it doesn't do any fault tolerance when one node is offline. How would you be able to keep the state of the VM during the switch over, including the in-memory replication? That's the trickiest part to accomplish.
|
| Posted by david510, 12-20-2010, 09:44 AM |
| We have accomplished this. What we do is give the /vz partition as the DRBD cluster and have written custom scripts to activate heartbeat to switch to the second machine when the primary is sinking. Since /vz is synchronized, all the IP/configuration detail remain the same and all services remain uninterrupted.
|
| Posted by viGeek, 12-20-2010, 01:52 PM |
| Other than our RHEL cluster suite, we use DRBD especially for our mySQL database servers.
It's easy to manage, easy to setup and works very well if configured correctly. DRBD keeps our data synchronized while we use heartbeat to determine if a node is down, then heartbeat calls the correct scripts to initiate a fail over. There is also pacemaker (http://www.clusterlabs.org/) which branched off heartbeat a while ago and can be configured a bit more in depth. Our setup uses a VIP which transfer from box to box depending on who's the primary node.
In order to take this approach you will need two servers joined by a crossover cable (preferable) but you can get away via switch, internal routing etc.
|
| Posted by trustedhosting, 12-20-2010, 02:34 PM |
| Hi David, your last comments sounds like exactly what I want; however YUPAPA makes a good point and I would need to understand the solution a little better in order to feel comfortable implementing it. The fault tolerance is really the key aspect I'm looking for.
If there are trade secrets or proprietary information here we could speak more privately about it on the phone or e-mail. You can find me e-mail and phone in my "View Beta Profile".
Regards,
-Michael
Last edited by trustedhosting; 12-20-2010 at 02:37 PM.
|
Add to Favourites 
Print this Article
Also Read
Pervent SPAM (Views: 533)