Read the CHANGELOG
OftenOn is a Lability/Hyper-V/Desired State Configuration wrapper which builds and configures five-node no-storage multi-subnet Windows Server Failover Cluster(s) with SQL Server Availability Groups.
It was designed specifically to be compatible with Windows Server 2012 (WS2012) and SQL Server 2012 (SQL2012) and for testing migration scenarios to higher clusters (a SQL2012 cross-cluster migration) and higher SQL Server versions (a SQL 2017 upgrade followed by a Distributed Availability Group migration).
Set-OftenOnLab -ConfigurationName X lets you switch to different migration scenarios.
Defaultis the original OftenOn, a five-node no-storage multi-subnet WSFC cluster with WS2012 and SQL2012.
CrossClusterMigrationis a WS2012 and SQL2012 cluster, with a second WS2016 and SQL2012 cluster. You can use this to practice SQL2012 cross-cluster migrations.
Upgradeis a WS2012 and SQL2012 cluster, with a second WS2016 and SQL2017 cluster. You can use this to practice upgrading SQL2012 to SQL2017 and then setting up a Distributed Availability Group to migrate from one cluster to another.
DAGis a WS2012 and SQL2017 cluster, with a second WS2016 and SQL2017 cluster. You can use this to practice just setting up a Distributed Availability Group and migrating from one cluster to another.
It also takes an optional
-ModulePath. You can point this to a folder and the contents will be copied into C:\Program Files\WindowsPowerShell on the workstation machine. This is a quick way to get your own code into there.
It takes time on the first run to download about 10GB of Evaluation ISOs from Microsoft. After this though each time the lab is destroyed and competely recreated takes 45-60 minutes. You’ll know it’s done when all the VMs go to the login screen.
Then remote in yourself! Remote Desktop from your machine should work to the short computer names (e.g. CHDC01) via IPv6 but it may not work on some configurations.
Username OFTENON\LocalAdministrator Password Local2019!
The VMs built are as follows:
(and for the non-default scenarios)
The C1 cluster has an Availability Group (AG1), a listener (AG1L), and 4 databases (AG1DBx). It’s all sync’d to Dallas and ready to failover for your testing! C2 cluster usually doesn’t have an Availability Group because setting that up is part of doing your migration. Where it is required, I recomment set it up like so:
And if you use a Distributed Availability Group:
All VMs have WMF 5.1 installed. There’s a couple resources (like SQL patches and the .NET 4.7.2 updater) on \CHDC01\Resources. Those aren’t installed everywhere because that’s part of the fun of the lab - exploring various issues with and without them. It’s also loaded with all my other PowerShell modules.