Shulou(Shulou.com)06/03 Report--

Hi friends who follow Lao Wang's blog, after National Day holiday, we began to study and learn WSFC again. This time we introduce the multi-domain architecture in the WSFC 2016 deployment model.

What is multi-domain? for friends who only know WSFC, they may not understand what it means. In fact, multi-domain refers to the logical scope of an AD domain. For example, I have a domain in Beijing, oa.com, and Tianjin have a subdomain, tj.oa.com. These two domains belong to the same forest, oa.com forest, they are in a big forest, but the domain data between parent domain and child domain will not be the same, although we are all in the same forest. However, users and computers created by my parent domain will not have child domains, and users and computers created by child domains will not have parent domains, so although they are multiple domains in the same forest, they still have security boundaries.

Some enterprises, which may have requirements from subsidiaries, need to maintain their own user computers, and do not want the parent domain to see it, so they will require themselves to establish child domains and maintain them completely, or the parent company will acquire a company to make the structure of a single forest and multi-domain tree. the principle is the same, although you can establish a trust relationship and access each other's resources, but their respective resources are maintained by their own.

The above explains the multi-domain architecture. To put it simply, it is the parent-child domain or multi-domain tree in a single forest environment. The key point is that each domain under a single forest maintains its own users and computer objects separately.

So back to the topic of our cluster, multi-domain architecture was impossible in the previous version. Before, even if there were two trusted domains, and the nodes on both sides wanted to do a cluster together, the wizard would not pass and would point out that the current node was not in the same domain. This was a dead rule in the past, but it was changed in WSFC 2016.

In the case of multi-domain clustering, in Lao Wang's view, there are not many practical application scenarios in China. Once a cluster is deployed, most of it is a production environment, or a test environment. Usually, both the test environment and the production environment have separate domains. You can directly use the most traditional AD domain architecture, so there is no need to make it so troublesome.

If you really want to think about the scene, maybe, if it is a large company, there are many subsidiaries under the big company, and one day suddenly agreed with the subsidiaries, let's jointly maintain a system, some of the nodes we have here, some of the nodes are with you. In other words, direct testing to production, testing to production, adding problematic nodes to the isolation cluster first, and so on.

But anyway, this is feasible now. Now that we can build different nodes of a single forest and multiple domains into the same cluster, some friends may wonder, now that you have a domain, can I have CNO and use Kerberos? Not yet, why, because each domain runs independently of each other. If the normal domain node creates a cluster wizard and the cluster goes to the node's domain to write CNO, your two nodes are different domains. If the cluster wants to write, which domain should it write to? Each domain has its own RID host, and the SID of computer users in each domain will be different, so it is inevitable that some nodes cannot be verified properly.

Therefore, there is no way for multi-domain clusters to write to CNO, only through DNS records as administrative access points, just like workgroup clusters.

The multi-domain deployment model requires the following

All node operating systems must be Windows Server 2016

All nodes must use certified identification hardware

All nodes must install the failover clustering feature

The workgroup mode cluster needs to use the same password and the same user on each node, the user needs to be a member of the local administrative group, and the registry key value needs to be modified if it is a non-administrator user.

For multi-domain mode clusters, each node is required to have a DNS suffix for all domains

As you can see, except for the fifth point, everything is the same as the workgroup cluster. In the fifth point, we need to add the DNS suffix of the corresponding domain to the multi-domain node. If it is a DHCP environment, we can do it directly on the DHCP Server.

The applicable scenario is the same as the workgroup model. According to Microsoft, the most suitable scenario is SQL Server SA verification.

Cluster workload support / do not support more information SQL Server support we recommend that you use SQL Server authentication for Active Directory independent cluster deployment. File server supports, but Kerberos authentication is not recommended as the preferred authentication protocol for server message block (SMB) traffic. Hyper-V supports it, but fast migration is not recommended and live migration is not supported because it is dependent on Kerberos authentication. Message Queuing (also known as MSMQ) does not support message queuing storage properties in AD DS

Multi-domain model deployment supports the new features of WSFC 2016 as follows

Fault domain site awareness

Site health detection

Cloud Winess

Cluster Log optimization

Simple SMB multichannel

Cluster VM load balancing (No LiveMigration Only QuickMigration)

VM resiliency and Storage Fault tolerance (No LiveMigration Only QuickMigration)

Actual combat environment

DC01&iscsi oa.com

Lan:10.0.0.2 255.0.0.0

Iscsi:30.0.0.2 255.0.0.0

DC02 tw.oa.com

Lan:10.0.0.3 255.0.0.0

HV01

MGMET:10.0.0.9 255.0.0.0 DNS 10.0.0.2

ISCSI:30.0.0.9 255.0.0.0

CLUS:18.0.0.9 255.0.0.0

HV02

MGMET:10.0.0.10 255.0.0.0 DNS 10.0.0.3

ISCSI:30.0.0.10 255.0.0.0

CLUS:18.0.0.10 255.0.0.0

The current HV01 belongs to the oa.com domain

HV02 belongs to the tw.oa.com subdomain

Create local users with the same password on each node

Add users to each node local administrators group

Configure the user password to never expire

If we do not use the administrator users built into the nodes locally to create the cluster, then we also need to modify the registry of each node

HKLM:\ SOFTWARE\ Microsoft\ Windows\ CurrentVersion\ Policies\ System

Add DWORD key value LocalAccountTokenFilterPolicy, value is 1

Access the network card for each forest multi-domain node DNS, and add the DNS suffix of all domains.

Restart after modification, log in with cluadmin user, add functional roles of each node cluster, and connect to ISCSI storage

GUI is created in the same way as a workgroup cluster, here we use Powershell to create

# create a multi-domain cluster

New-Cluster-Name MLDcluster-StaticAddress 10.0.0.40-Node HV01,HV02-AdministrativeAccessPoint DNS

The creation is complete, and there is no error report.

Open the failover Cluster Administrator and find that the cluster can be opened normally, and automatically help us configure the disk witness

Next, you can try to deploy upper-layer applications based on multi-domain model clusters!

We Done it!

Now we have deployed the WSFC cluster in the scenario of a multi-domain node model!

This provides new possibilities for some scenarios.

Unfortunately, although it is a multi-domain model, it is still necessary to create a cluster in the way of a workgroup, and the upper-level applications that can run based on the multi-domain model are still limited.

OK, guys, let's try it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.