Master and resource contain details of the patch level relating to the SQL Server program files and other instance-unique details.
If you did have a shared master, then you are locking both servers to the same patch level from that point forward. You cannot patch a SQL instance without having master online, and you cannot expect a SQL instance to work correctly if the program files and master db are at different patch levels. So, if you did share the master db you could never apply a service pack or a CU or a hotfix to any of the instances that use the shared master (always assuming that this configuration would work in the first place!).
You need to have instance-unique versions of master, model, resource and tempdb. One benefit of this is that all SQL instances could be up and running, but only one would have the active database files online to it. You can then run other instance-specific work (if you have any) and patch the 'offline' instances completely independently of which instance has the active databases.
In my old place (pre 2007) we used Double-Take to replicate our user databases between London and New York. One site had the databases online, while the other site had these offline. We used a DNS alias to point to the active instance, so that application connection strings could remain constant. Our failover process stopped the replication, switched which databases were online and offline, switched the DNS alias, restarted replication, and ran a few automated tests. Each month we swapped which site was live, so that we always knew that our DR process would work.
Original author: SQL Server FineBuild 1-click install and best practice configuration of SQL Server 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005. 1 Dec 2016
: now over 39,000 downloads.
Disclaimer: All information provided is a personal opinion that may not match reality.
Quote: "When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist." - Archbishop Hélder Câmara