Is this server strategy reckless and/or insane?
-
@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.
-
@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.
Less easy because without virtualization all I have to back up are a folder of images and a small handful of MySQL data files. Adding virtualization for the benefits I perceive peeps here to be championing would require backing up the entire VMs, which is less easy not to mention a much much bigger backup footprint, no? What am I missing?
-
The high availability at the hypervisor level is a minor point. It might be useful for the non-database workloads, but the database replication at the application layer is better if he's going to go that route as it protects against more.
-
@creayt said in Is this server strategy reckless and/or insane?:
@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.
Less easy because without virtualization all I have to back up are a folder of images and a small handful of MySQL data files. Adding virtualization for the benefits I perceive peeps here to be championing would require backing up the entire VMs, which is less easy not to mention a much much bigger backup footprint, no? What am I missing?
Can't be less easy. Not possible. Literally, it's impossible to be less easy. Because ANY option you have with physical you retain with virtual, but with virtual you have more.
-
@creayt said in Is this server strategy reckless and/or insane?:
@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.
Less easy because without virtualization all I have to back up are a folder of images and a small handful of MySQL data files. Adding virtualization for the benefits I perceive peeps here to be championing would require backing up the entire VMs, which is less easy not to mention a much much bigger backup footprint, no? What am I missing?
As an example you could use XO's continuous replication capability and have the system configured that if Host 1 goes down to instantly power on the VM on your other active host.
Literally nothing you have to do but restore host 1.
-
The reasons for virtualization are...
- adds lots of benefits that you may or may not use, that you might need them in the future and can never tell today is a huge piece
The reasons not to virtualize are...
none really. That's why we always virtualize.
-
@scottalanmiller said in Is this server strategy reckless and/or insane?:
@creayt said in Is this server strategy reckless and/or insane?:
@jaredbusch For Server 2016 right? Saw that, pretty annoying. But I like the idea of breaking things up into containers eventually so I may bite the bullet. At the moment I have 1 2012 R2 license which I think works for the decacore server w/ no extra licensing.
THat's correct.
No, that is not correct.
@creayt a single license covers dual 8 core processors. You will need two more 2 core pack licenses for the decacore box.
