Upgrade option for existing pull server local db

[ArieHein]

Becuase of the rapid release of new module versions, i have to build a new pull server every time based on the new resource. On the other hand i dont have to do anything on the LCM side.

This means i loose all the information my LCMs registerd in the local db on the pull server.

Would there be an option to use the same local db and part of the resource will be a upgrade script if those are needed and a way to tell the procedure to use existing db and not recreate it from the dll everytime ?

[iainbrighton]

And this leads to another question: how do we create a high availability deployment, e.g. load balanced DSC pull servers? Presumably there needs to be some persistence of the back-end data which is related to @ArieHein 's question.

[ArieHein]

you cant do a high availability deployemnt when you have a file based database, thats why you have clusters, unless you use some log-shipping or replication.

It will require going from 2-tier apps like we have now to 3-tier app with the middle tier being HighAvailabilty aware so you have web tier and middle tier on more then one server but the DB will always be your "single point of failure" as there will be only one on a sepcific server.

[megamorf]

@ArieHein @iainbrighton In addition to the points mentioned above doesn't the repeated rebuild of the Pull Server also create a lot of obsolete DSC-OaaS certificates on the target nodes when they're re-registered?

But yeah, some sort of clustering/back and front-end load-balancing is needed as well as a clear upgrade path for the Pull Server to prevent the loss of information from the local db.

[ArieHein]

@megamorf yes i think JustinKing found those extra certs and i think he wrote something to handle it iirc, but those will happen anyway even if you dont recreate a pull server, everytime you create a new LCM script iirc

[iainbrighton]

@ArieHein Where is this high-availability cluster requirement documented? I would like to think storing the data on another tier, e.g. an existing DB cluster would a) be possible, and b) a supported deployment model. That's still 2-tier.

[megamorf]

@iainbrighton As far as I know clustering hasn't been tackled by Microsoft yet. So even though the IIS services can be load balanced the Pull Server db cannot.

[ArieHein]

I initialy went for the 3 tier option as i wasnt sure ESENT supported High-Availability but seeing as its the core under Exchange it might, im not sure. If the driver was SQL based, we might have been able to use a Witness-based replication, not sure LocalDB supports that.

As for the web tier high availability, using ARR (i hate NLB) like @raghushantha did for his PowerShellGallery repo was more the way i was thinking about.

[ArieHein]

Would be intresting to take an existing pull server, change the connection string in the web.config to point to a network path and copy the pull server db to that location

[megamorf]

@ArieHein This issue has drifted off quite a bit. I suggest opening another issue to help everyone involved focus on the original issue :-)

[johlju]

@ArieHein @iainbrighton looking at the initial comments now when SQL support exist, do you see this issue being solved or is there a part of this issue that is still unresolved so that we should keep it open?

[ArieHein]

While moving to SQL as a source of holding the information and thus allowing some sort of 'high availability', I dont think it addresses the main issue here.

Lets say you create a pull server from the xPSDesiredStateConfiguration, this in turn, uses an internal dll that is part of the package that creates a database with all the necessary fields (doesn't matter if its SQL, MDB or ESENT for that matter).

Lets say a new version of xPSDesiredStateConfiguration is released in which the database schema has changed, lets say a new field was introduced.

Now I have an existing, working , Pull Server with various servers that registered their LCM.

How do I incorporate the new database schema into my existing one ?

I can create a new pull server via the new xPSDesiredStateConfiguration version, but then what happens to all my data ? Is there a concept declaring that creating a new pull server on top of an existing one, just uses an "upgrade script" to allow data to be kept overall ?

[johlju]

Thanks for the detailed answer! I see what you mean. I can't find any official documentation on any upgrade or migration steps. So unfortunately if that is not supported in the current Windows Server Insiders then I would expect that is a feature that will not come to Windows Server Pull Server. I reference to this Windows Pull Server Planning Update – April 2018.

We can keep this issue open to see if they community can come up with an method of doing this.