asked on
Terminal Servers - physical versus virtual - follow up on: http://www.experts-exchange.com/Software/Virtualization/Q_27980333.html
Following up on https://www.experts-exchange.com/questions/27980333/Terminal-Servers-in-clustered-environment-physical-or-virtual.html I would like to know what the differences between physical and virtual TS's in a clustered farm in the following specific circumstances:
physical TS server freezes (freeze is distinguished from drastic slowdown in the following questions)
vs Core host of TS VM freezes
vs TS session freezes
physical server reboots
vs Core host of TS VM's reboots
vs TS VM itself reboots
What difference would the user see in these circumstances?
Would a physical TS freeze mean users would be redirected to another node in the cluster? Or would it just be a stuck session? If it was redirected how long would it take?
Would a freeze on a Core hosting VM's allow for TS access even though the host is not accessible? It seems I've seen that situation
In the case of a reboot of a physical TS, does it make a difference how long the reboot takes before the physical TS server is failed over?
In the case of a virtualized TS, if the Core host reboots does it make a difference how the long the reboot takes before the VM is failed over?
It seems as well that drastic performance degradation as opposed to outright hardware failure on a TS physical or virtual will not cause failover. Is that correct?
Also in the case of a constantly rebooting host - physical or Core host - would there not be problems with users being connected to the rebooting server during its up time window?
In the case of the host not rebooting but the TS VM rebooting constantly it seems one could quickly/simply bring the TS VM down and nobody would be able to log into it. Agree/disagree?
And it would be quite possible then to simply add a dupe of the VM to the server - in fact, it could failover to another hosted VM on the server itself so there would be less performance issues caused by more people being redirected and logging into one of the other non-rebooting physical TS servers in the cluster. Make sense? Any problems I haven't given enough consideration to with the failover-on-the-same server VM scenario?
Also from my experiences drastic slowness/freezes are more common than physical failure in TS environments. Is that the sense of responding Experts here as well?
Finally it seems to me that most of the time Dev and Test 'networks' that mimic the production network are pretty well defacto virtualized as there is a lot of 'playing around' going on - there always seem to be new versions of programs that have to be deployed. It seems then that if one has a physical TS farm then that there is a lot of converting virtual to physical to rollout a new 'version' and as well backing up the current production to become the new Test/Dev involves physical to virtual which makes rollback to a physical network more complicated. Again, fee free to debate - I am exploring and want to make sure that I am not simply agreeing with myself in my design choices.
Thanks in advance for all time put into answering the above.
physical TS server freezes (freeze is distinguished from drastic slowdown in the following questions)
vs Core host of TS VM freezes
vs TS session freezes
physical server reboots
vs Core host of TS VM's reboots
vs TS VM itself reboots
What difference would the user see in these circumstances?
Would a physical TS freeze mean users would be redirected to another node in the cluster? Or would it just be a stuck session? If it was redirected how long would it take?
Would a freeze on a Core hosting VM's allow for TS access even though the host is not accessible? It seems I've seen that situation
In the case of a reboot of a physical TS, does it make a difference how long the reboot takes before the physical TS server is failed over?
In the case of a virtualized TS, if the Core host reboots does it make a difference how the long the reboot takes before the VM is failed over?
It seems as well that drastic performance degradation as opposed to outright hardware failure on a TS physical or virtual will not cause failover. Is that correct?
Also in the case of a constantly rebooting host - physical or Core host - would there not be problems with users being connected to the rebooting server during its up time window?
In the case of the host not rebooting but the TS VM rebooting constantly it seems one could quickly/simply bring the TS VM down and nobody would be able to log into it. Agree/disagree?
And it would be quite possible then to simply add a dupe of the VM to the server - in fact, it could failover to another hosted VM on the server itself so there would be less performance issues caused by more people being redirected and logging into one of the other non-rebooting physical TS servers in the cluster. Make sense? Any problems I haven't given enough consideration to with the failover-on-the-same server VM scenario?
Also from my experiences drastic slowness/freezes are more common than physical failure in TS environments. Is that the sense of responding Experts here as well?
Finally it seems to me that most of the time Dev and Test 'networks' that mimic the production network are pretty well defacto virtualized as there is a lot of 'playing around' going on - there always seem to be new versions of programs that have to be deployed. It seems then that if one has a physical TS farm then that there is a lot of converting virtual to physical to rollout a new 'version' and as well backing up the current production to become the new Test/Dev involves physical to virtual which makes rollback to a physical network more complicated. Again, fee free to debate - I am exploring and want to make sure that I am not simply agreeing with myself in my design choices.
Thanks in advance for all time put into answering the above.
Virtualization
Last Comment
Line One
ASKER CERTIFIED SOLUTION
Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a questionYour help has saved me hundreds of hours of internet surfing.
fblack61
I guess after all the back and forth virtual wins out for me - having an OS in any way tied to the hardware it's running on seems a step backward - nothing about superior 'performance' that might be the case with 'physical' comes anywhere near the operational flexibility of being hardware independent. Here is another way I would put the fundamental question.
If for some reason you could only have physical or virtualized systems but never a mixed system which would you chose?
Also if there were no cost or performance difference between having a system physical or having it VM'd on itself - in other words I could either install a 2008 TS physical or I could use the same box and install a single 2008 TS VM in it that would have no performance loss compared to the physical host what would be your choice then? So in a scenario of 200 servers let's say you could choose to have the 200 servers physical versus having the 200 virtualized on themselves so to speak on themselves at no extra cost, which would you choose?
I understand that these are 'unreal, hypothetical' scenarios but I find when I ask myself these questions without consideration of cost/performance, I always choose the virtual option as in the real world I actually always have the option to do that - we are not talking about a theoretical 'future' technology when it comes to virtualization. So what it comes down to me is that virtual is 'superior' and it's putting a value on that superiority is what's in question. For instance, let's say I need a lot of performance for a specific high-powered application that needs a standalone very high end computer to run it. My view is that if the app is that critical and the hardware needed to run it has to be that powerful, any cost to virtualize that application on the hardware and if necessary even to boost the hardware to accommodate it is immediately paid back in today's cheap hardware world by the benefit of hardware independence. The idea of running any application that is tied to any hardware at the mission-critical level seems to me a law-suit waiting to happen - I would never live with it for my own mission-critical system and having the redundancy option consist of multiple physically dependent systems is not near as good as the redundancy of multiple physically-independent systems - it's just the single physically-independent system flaw taken to a different level.
I guess I could sum it up as such - you boot up a computer and you get a screen:
Would you like the software on this computer to be
A) tied to the hardware on this computer or
B) be reusable on any other computer
I guess I would have to have somebody do a lot of arguing with me why I would choose A.
Feel free to take an opposing view or something in-between.