|
I'm running a Windows Server 2008 R2 instance on my home PC/server, which is running Hyper-V/AD/DNS/SCVMM/SQL Server, and as a result, I have a lot of tools installed. E.g. tools to document my network of VMs hanging off SCVMM. Am I under the wrong impression that servers e.g. AD should not have many tools installed on them for debugging etc and that these should all be installed remotely (For remote debugging)? Thanks
| |||
|
feedback
|
|
I wouldn't want to set up a production network's server like that, for sure, but if you're happy with it as a home 'test' box then go for it, frankly.. As for installing apps on a DC being "wrong" - it's a balancing act, balancing the obvious cost of multiple servers against availability, ease of support and workload. workload This is the easy one. The more apps you put on one box, whether virtualised or not, the more work that box has to do, and there comes a point where it will struggle to keep up with all the work you're asking it to do. This can result in slowdowns and possibly errors (e.g. where a component 'times out'.) Ease of support Also quite easy. And somewhat negated by virtualisation if that is used well. The more systems you have on one box, the more chances there are for components from different services to interact in unexpected ways and require more work on your part to keep them working. Availability Again, somewhat negated by virtualisation if that is used well. This simply means that if you're providing a service to customers/users on a network then any interruption of service to those customers is a bad thing. That's obvious of course. However... If multiple applications share the same box then any downtime on that box affects all those services. More, if two or more services exist in the same system then an interruption to one means and interruption to the other - e.g. if all your systems were running without virtualisation then a SQL server patch that required a reboot would stop all the other services running, some of them (e.g. AD, DNS) needlessly. Of course, you're using virtualisation but if you have a physical Windows 2008 server with the hyperV role installed (as opposed to an actual hyperV server) and installed one of those services on the physical server alongside HyperV, then this means that any patch to that service that requires a reboot (or any other interruption of a service/resource needed for the virtualisation role) would result in a needless interruption of service/availability. These are the three reasons I know of for minimising the amount of applications on one (real or physical) server instance. | |||
|
feedback
|
|
It's not so much a question of right and wrong. It's poor practice to make a situation unnecessarily complex. Complexity adds points of failure, which makes it more likely that the system will fail. Since you have a virtualized environment, it's best practice to dedicate images to single (or a few related) tasks. There should be one image for AD/DNS, another for SCVMM (virtualizing SCVMM is a bad idea in the first place), another for MS SQL. If you're going to use debugging and management tools, they should have their own VM as well. Keeping everything separate limits failure, contains the damage potentially caused by failure, and makes the whole system more maintainable. | |||
feedback
|
|
Personally I like to have domain controllers just doing domain controller duties (plus core services such as DHCP/DNS/WINS) and little more. The reasons are security and stability and reliability. Security in so much as less applications = less potential exploit routes. Stability = less applications so less potential for conflict and "reboot to fix the problem with app xyz" that then brings down your entire domain. Reliability = a combination of the above, I just think it's neater if possible to split out roles. | |||
|
feedback
|
