This post was authored by Subhasish Bhattacharya, Program Manager, Windows Server
Introduction: Active Directory integration with your private cloud
Active Directory integration provides significant value for most of the private cloud deployments. However, for a subset of scenarios, it is desirable to be able to decouple your deployment from Active Directory. In prior Windows Server releases, we introduced a number of features to minimize the dependence of your private cloud on Active Directory. Some of these features include:
Bootstrapping without Active Directory: Introduced in Windows Server 2012 and allows you to boot your private cloud without Active Directory dependencies. This is especially useful when you have lost power to your entire datacenter and have to bootstrap. It therefore enables you to virtualize your entire datacenter, including domain controllers.
Cluster Shared Volumes independent of Active Directory: Cluster Shared Volumes, in Windows Server 2012 and beyond, have no dependence on Active Directory. This is especially advantageous in deployments in branch offices and off-site deployments.
Active Directory-detached clusters: In Windows Server 2012 R2, Failover Clusters can be created without computer objects in Active Directory, thereby decreasing your deployment and maintenance complexity. However, this deployment model still requires all the nodes in your private cloud to be joined to a single domain.
Flexible private cloud – the need for domain independence
In our discussions with you over the last few years, we learned about why you wanted domain independence (freedom from domain requirements for your clusters)!
SQL Server workload
1. You wish to have AlwaysOn Availability Groups (AG) span across multiple domains and on workgroup nodes. This in some cases is motivated by your desire to move away from database mirroring. You have described how:
- Your enterprise needs to operate with multiple domains due to events such as mergers and acquisitions.
- You would like to consolidate multiple replicas from multiple sources to a single destination.
- You have AG replicas not in a domain.
- You wish to address deployment complexity and the dependence of your DBA administrators on the owners of your Active Directory infrastructure.
2. Today there are thousands of SQL Server production deployments on Azure IaaS Virtual Machine (VM) environments. You love the flexibility of Azure, but these deployments require you to deploy two additional VMs for redundant DCs. You would like to avoid this requirement and reduce the deployment cost of your solution.
3. You love Hybrid deployments, where some replicas are running in Azure VMs and other replicas are running on-premises for cross-site disaster recovery. However, all replicas are required to be in the same domain. This is a deployment burden for you. More details about this deployment model can be found here.
Hyper-V and File Server workloads
You would like to be able to deploy Hyper-V and File Server clusters without the cost and complexity of configuring a domain infrastructure for the following scenarios:
- Small deployments
- Branch office
- DMZ deployment outside firewall
- Highly secure deployments (domain-joined is considered a security weakness in highly secure environments)
- Test and development environments
In Windows Server 2016, we have addressed your SQL Server workload scenarios, end-to-end! We continue to strive to light up your Hyper-V and File Server workload scenarios for subsequent Windows Server releases. Hyper-V live migration and File Server have a dependency on Kerberos, which currently remains unaddressed in Windows Server 2016.
Windows Server 2016 breaks down domain barriers and introduces the ability to create a Failover Cluster without domain dependencies. Failover Clusters can now therefore be created in the following configurations:
- Single-domain clusters: Clusters with all nodes joined to the same domain.
- Workgroup clusters: Clusters with nodes that are member servers/workgroup (not domain-joined).
- Multi-domain clusters: Clusters with nodes that are members of different domains.
- Workgroup and domain clusters: Clusters with nodes that are members of domains and nodes that are member servers/workgroup.
Creating domain-independent clusters
All the options to create “traditional” clusters are still applicable for domain-independent clusters in Windows Server 2016. To try this new feature in Windows Server 2016, download the Technical Preview. For additional details, see the feature Cluster blog here. Some of the options to create domain-independent clusters are:
1. Using Failover Cluster Manager
2. Using Microsoft PowerShell©
New-Cluster –Name <Cluster Name> -Node <Nodes to Cluster> -AdministrativeAccessPoint DNS
Check out the series: