The first Question is: How about scalability?
Is Desired State Configuration designed for the masses? Or only to use with a human manageable small amount of Servers?
In the following write up I use the term Configuration-function for the new PowerShell Keyword to make it different from the term configuration which is the current state of a system (node).
I don't see any scalability in DSC. At the end of the road you always have a 1 to 1 relationship.
I know DSC is designed to use even outside of Active Directory in the cloud and with systems without Operating Systems like the BIOS but I speak here only for Systems with Operating Systems like Windows or Unix.
1.) Node to Pull-Server relationship
Every system (node) can only have 1 Pull-Server 1:1 .There is no concept like in Active Directory to use a group of Servers to serve the configurations.
2.) Configuration-function to .mof file to Node relationship
The Windows PowerShell Configuration-function is good at scale you can design one Configuration for one System (Node) and you have a 1:1 relationship , or you can design one Configuration-function to produce .mof files for many Systems (Nodes) and you have a 1:n relationship.
3.) Current configuration to history relationship
Even if a node is in the Pull-mode you can create Push Configuration-functions to push Hotfix configurations to the Nodes with the –force parameter.
I hope my English was comprehensible to you! And my ideas too!
So where do you see scalability in Desired State Configuration ?
Johan Akerstrom wrote o Facebook:
One thing to remember is that DSC is very much a 1.0 product. By that I mean that its the initial release. I expect future releases to build and expand on what we have now.
In terms of scalability I don't think the number of servers is as important as the rate of change of those servers. If you build servers to perform a particular task and then leave them to get on with that task they aren't going to have much impacy on your DSC servers
In terms of configurations being changed by others – put them under change control! If you don't have control of your environment it doesn't matter what technologies you use – they will be compromised and you will get failures in your processes.
Hi Richard thank you for your Answer! Realy apreciate it!
Yes I know it is a V.1.0 Product I discuss here me thougts before I make suggestion on MS Connect and perhaps the PowerShell Team read along here 😉
Full ACK 😉
Regarding scale, the pull service is very scalable, since the majority of the computational work is done out of band in generating the configs. The main scalability concern for the pull server is how many servers will check in at that time that will need to pull new modules. There you are capped by bandwidth. BranchCache could help there..
In regards to the questions directly –
1 – Use a load balancer and dns name to hide which pull server you are connecting to. You can also use subnet prioritization to direct clients to a local pull server.
2 – 1 to 1 is fine.. you really shouldn't have to care about the configuration mofs. The scripts you build to generate those mofs are more important.
3 – Yeah, I don't like how pushing a config changes the local config manager. I'm working on a resource that helps check other nodes to make sure they are configured correctly, but that's also another good task for a monitoring system to check.
You must be logged in to reply to this topic.