Is this server strategy reckless and/or insane?
-
@dashrender If anyone can name a single benefit of virtualizing given my description of this project's goals and needs I'll be very impressed.
-
@creayt said in Is this server strategy reckless and/or insane?:
@dashrender No virtualization at all, just throwing the full horsepower of each box at the servereware
The overhead of a hypervisor shouldn't even be a consideration. There is literally 0 benefit to doing this. You could use a hypervisor and have a true HA setup so if a node takes a nose dive, everything is instantly (I mean instantly) up on another node.
You wouldn't even have time to blink.
-
The performance hit from virtualization will be so many times less than the RAID 5 penalty, you won't notice it.
-
@creayt said in Is this server strategy reckless and/or insane?:
@dashrender If anyone can name a single benefit of virtualizing given my description of this project's goals and needs I'll be very impressed.
easier backups.
-
@dashrender Some reasons not to for this project:
Performance goals
Time to restore a failed server would increase w/ virtualization ( extra thing to configure )
One less thing to manage
Easier scaling licensewise -
@creayt said in Is this server strategy reckless and/or insane?:
@dashrender If anyone can name a single benefit of virtualizing given my description of this project's goals and needs I'll be very impressed.
Easier failover to another machine.
-
@dashrender Would actually be less-easy failover in this instance, no?
-
It's free to virtualize.
-
@creayt said in Is this server strategy reckless and/or insane?:
@dashrender Would actually be less-easy failover in this instance, no?
It would be easier to fail-over when you are virtual.
-
@dashrender "Easier backups", how so? Seems less-easy.
-
@creayt said in Is this server strategy reckless and/or insane?:
@dashrender Some reasons not to for this project:
Performance goals
Time to restore a failed server would be reduced
One less thing to manage
Easier scaling licensewisePerformance will be negligible at worst.
why would restore be longer?
I suppose it would be one less thing to manage - but it's not like it's that hard to manage
eh? uh - nope! Windows licenses exactly the same on VM or hardware. -
@creayt said in Is this server strategy reckless and/or insane?:
@dashrender "Easier backups", how so? Seems less-easy.
OK stop being dense, take a step back and consider entire platform backup operations.
How are you planning to do this with the existing physical system?
-
@creayt said in Is this server strategy reckless and/or insane?:
@dashrender "Easier backups", how so? Seems less-easy.
Can't be less easy. Can be the same or easier. You lose nothing, only gain options.
-
@creayt said in Is this server strategy reckless and/or insane?:
@dashrender Would actually be less-easy failover in this instance, no?
At the worst, the failover would be exactly the same as what you are talking about doing today - Exactly!
At best, you can have the hypervisor handle this for you.
-
@dustinb3403 said in Is this server strategy reckless and/or insane?:
@creayt said in Is this server strategy reckless and/or insane?:
@dashrender No virtualization at all, just throwing the full horsepower of each box at the servereware
The overhead of a hypervisor shouldn't even be a consideration. There is literally 0 benefit to doing this. You could use a hypervisor and have a true HA setup so if a node takes a nose dive, everything is instantly (I mean instantly) up on another node.
You wouldn't even have time to blink.
Can you walk me through how you're envisioning that working? I can't reconcile it to the description of the set up for this project. I presume you're talking about setting up Hyper V replicas or something, but because I'm dealing w/ two production boxes that are already actively sharing the workload the failover wouldn't be any different from the user's perspective, and will require the same replacement of the failed drive with or without virtualization.
-
@scottalanmiller said in Is this server strategy reckless and/or insane?:
@creayt said in Is this server strategy reckless and/or insane?:
@dashrender "Easier backups", how so? Seems less-easy.
Can't be less easy. Can be the same or easier. You lose nothing, only gain options.
OK saying easier might be over selling. But as Scott mentioned, you losing nothing, and gain options you otherwise didn't have - like snapshotting - which is not a backup, but a cool feature non the less.
-
@creayt said in Is this server strategy reckless and/or insane?:
@dashrender Would actually be less-easy failover in this instance, no?
No, there are literally no downsides to virtualization. Overhead is trivial (Wall St. can even use it for low latency trading applications) and it makes many setup, management and recovery tasks easier. It protects against the unknown. It's one of the most basic best practices in IT for a reason (and has been since 1964.) It provides you with licensing, backup, failover, consolidation, reliability and other benefits. The biggest benefit is "protection from the unknown".
-
@creayt said in Is this server strategy reckless and/or insane?:
@dustinb3403 said in Is this server strategy reckless and/or insane?:
@creayt said in Is this server strategy reckless and/or insane?:
@dashrender No virtualization at all, just throwing the full horsepower of each box at the servereware
The overhead of a hypervisor shouldn't even be a consideration. There is literally 0 benefit to doing this. You could use a hypervisor and have a true HA setup so if a node takes a nose dive, everything is instantly (I mean instantly) up on another node.
You wouldn't even have time to blink.
Can you walk me through how you're envisioning that working? I can't reconcile it to the description of the set up for this project. I presume you're talking about setting up Hyper V replicas or something, but because I'm dealing w/ two production boxes that are already actively sharing the workload the failover wouldn't be any different from the user's perspective, and will require the same replacement of the failed drive with or without virtualization.
No, Hyper-V replicas are not viable for high availability. They don't sync between the nodes in real time. You need HA storage like Starwind VSAN to do that.
-
@creayt said in Is this server strategy reckless and/or insane?:
@dustinb3403 said in Is this server strategy reckless and/or insane?:
@creayt said in Is this server strategy reckless and/or insane?:
@dashrender No virtualization at all, just throwing the full horsepower of each box at the servereware
The overhead of a hypervisor shouldn't even be a consideration. There is literally 0 benefit to doing this. You could use a hypervisor and have a true HA setup so if a node takes a nose dive, everything is instantly (I mean instantly) up on another node.
You wouldn't even have time to blink.
Can you walk me through how you're envisioning that working? I can't reconcile it to the description of the set up for this project. I presume you're talking about setting up Hyper V replicas or something, but because I'm dealing w/ two production boxes that are already actively sharing the workload the failover wouldn't be any different from the user's perspective, and will require the same replacement of the failed drive with or without virtualization.
KVM, XenServer, Hyper-V and ESXi all have the capability to move VM's around from a failed/failing host without you even having time to read the email.
These are all installed to bare metal, and thus are leveraging the tools you have in place now, but don't require you to manage them.
-
@dashrender said in Is this server strategy reckless and/or insane?:
@creayt said in Is this server strategy reckless and/or insane?:
@dashrender No virtualization at all, just throwing the full horsepower of each box at the servereware
Prepare for the wrath of the Mango!
As I said - prepare for the wrath of the Mango.
I have to get on the road, I'm sure this thread will have 300+ posts on it by the time I'm back online.
