Hi All,
I'm designing a multi-region RDS 2016 farm where 2 of the regions have very stable internet connections but the 3rd does suffer from intermittent internet outages. The office is on an island in the Carribean and the telco thinks nothing of cutting the
connection to the island for a few hours for maintenance every so often so there's not much I can do about that. I also have to think about hurricanes and the odd ship that hits the undersea cable. As if things weren't difficult enough :)
Currently, all users at all offices are using PCs but we are introducing RDS with the long term plan to have everyone using RDS session-based desktops, also available externally. There are many reasons for this, including an ever-growing population
of remote users.
The main user population is in the Carribean but our SQL databases for critical in-house applications, Exchange and a few other important apps run out of our main data centre located in a very stable environment but will all be moving to Azure (US) and O365
this year.
My preference would be to put all the RDS environment (brokers, GW, Web, RDSH etc) in our main data centre or Azure as our critical data and apps aren't accessible during an internet outage anyway but I've already lost that argument. So that's
enough background.
To ensure users in the Carribean office can launch an RDS desktop session from a thin client when they have no internet connection, along with having local RDSH servers, I'll have to have the brokers in HA, one in the Carribean, the other in our main data
centre. As this will require SQL, will the broker in the Carribean office still function should it not be able to communicate to the SQL DB in our main data centre? is the broker clever enough to cache the settings locally and continue to work or will it cease
to handle any connections when the DB is unavailable?
If it will not function without a continuous connection to the DB, I guess my only option would be to have the SQL DB in HA group with both SQL servers servicing their local brokers. I'd really like having to avoid paying for 2 SQL licenses.
Thanks
Conor