有关Active Directorydevise的多宿主服务器的build议

首先让我说，我赞同其他许多人 – 要么说服客户，要么说服其他人。

但是，考虑到你列出的要求（有很多未列出的要求），我可以考虑（至less部分testing）至less是做这件事情的基础。

有几个具体方面需要考虑。

1. Active Directory域服务复制
2. 客户端/成员服务器的DC定位器进程
3. 非AD DS服务的名称parsing和stream量

其中一个和两个有很多共同之处 – 总的来说，我们在微软的这个意外之中，必须在微软的AD DSstream程的范围内工作。

第三，我们有一点点的工作空间。 我们可以select用于访问服务的标签（文件，数据库实例等）。

这是我build议的：

build立您的域控制器（DC）

• 至less可能有两个。
• 每个DC将有两个NIC，每个IPnetworking/ AD DS站点中有一个 – 现在称它们为clt和srv。
• 现在在srvnetworking中， 只在每个DC中configuration一个NIC。

正确configurationAD站点和服务

• srv网站和子网
• clt站点和子网
• 从站点取消勾选 “桥接所有站点链接” – >站点间传输 – >右键单击“IP”
• 删除DEFAULTIPSITELINK（如果存在的话）（或者你重命名了它），所以没有configuration站点链接。 请注意，这对我来说是未知的 – KCC可能会将错误转储到目录服务事件日志中，说明两个站点（srv和clt）没有以不同的间隔连接。 但是，两个DC之间的复制仍然会继续，因为它们可以使用同一个站点中的IP进行联系。

在AD DS集成DNS中configuration其他区域

• 如果您的AD DS域是acme.local ，请创build第二个主动 AD集成区，并启用名为clt.acme.local的dynamic更新。

在DC上configuration第二个NIC

• 这些NIC将成为cltnetworking/网站中的NIC。
• 设置他们的IP
• 这里是魔术部分 – 适配器属性 – > IPv4属性 – >高级 – > DNS选项卡 – >将此连接的DNS后缀设置为clt.acme.local – >检查注册此连接… – >检查使用此连接DNS后缀… – >确定一路通过。
• ipconfig / registerdns
• 这将在clt.acme.local区域中注册clt NIC IP – 为我们提供一种方法来控制稍后使用的IP /networking。

configuration成员服务器网卡

• clt站点中的成员服务器网卡必须具有相应的DNS后缀和checkbox，如上所述。
• 这些设置可以与静态和DHCP一起使用，没关系。

在站点中configurationDNS [存根]parsing器行为

• DC's – >configurationDC srv网卡以使用自身和其他DC srv网卡IP。 将DC clt NIC DNS留空（但需要静态IP）。 （默认情况下，DC DNS服务器仍将监听所有IP地址）。
• 成员服务器 – >将成员服务器srv NICconfiguration为使用DC srv站点IP。 将成员服务器clt NIC DNS保留为空（可以使用静态IP）。
• 客户端/工作站 – >configurationDNS（通过DHCP或静态）以使用DC的clt NIC IP。

正确configuration映射/资源

• 当服务器互相交谈时一定要使用.acme.local – >将parsing为srvnetworkingIP。
• 当客户端与服务器通话时，一定要使用.clt.acme.local – >将parsing为cltnetworkingIP。

我在说什么？

• AD DS复制仍然会发生，因为DC可以互相parsing，并相互连接。 acme.local和_msdcs.acme.local区域将只包含DC srv NIC IP的AD DS复制将只发生在srvnetworking上。
• 成员服务器和工作站的DC定位器进程将起作用 – 尽pipe在不知道站点的情况下各种AD DS进程的各个部分可能会出现延迟，但是如果返回多个DC IP，则会尝试，失败并继续直到一个作品。 对DFS-N的影响还没有完全评估 – 但仍然有效。
• 如果您使用前述的.acme.local和.clt.acme.local标签，非AD DS服务将正常运行。

我还没有完全testing过，因为这太可笑了。 然而，这个（哇，漫长的）答案的重点是要开始评估是否有可能 – 而不是是否应该这样做。

@注释

@Massimo 1/2不要混淆acme.local区域中的多个AD DS站点，因此，在acme.local区域中的需要SRVlogging的clt.acme.local区域中，由DC填充的SRVlogging将logging在这些站点中。 客户端的主DNS后缀（和他们join的Windows域）仍然是acme.local。 客户端/工作站只有一个NIC，主DNS后缀可能来自DHCP，设置为acme.local。

clt.acme.local区域不需要SRVlogging，因为它不会在DC定位器进程中使用。 它仅被客户端/工作站用于使用cltnetworking中的成员服务器IP连接到成员服务器的非AD DS服务。 AD DS相关进程（DC定位器）不会使用clt.acme.local区域，而是使用acme.local区域中的AD DS站点（和子网）。

@Massimo 3

将会有clt和srv AD DS站点的SRVlogging – 只是它们将存在于acme.local区域中 – 请参阅上面的注释。 clt.acme.local区域不需要DC相关的SRVlogging。

客户将能够find一个DC罚款。 客户端DNS服务器指向DC的IP地址。

客户端上的DC定位器进程启动时

• 如果客户知道它的网站，DNS问题将是_ldap._tcp。[site] ._ sites.dc._msdcs.acme.local SRV。 这将返回具有注册的SRVlogging的站点特定的DC。
• 如果客户端不知道它的网站，DNS问题将是_ldap._tcp.dc._msdcs.acme.local SRV。 这将返回所有的DC。 客户端将尝试绑定到DC的LDAP直到find响应。 当客户端find一个，它执行一个站点查找来确定客户端的站点，并caching在registry中的站点，以便将来的DC定位器实例更快地发生。

@Massimo 4

呃，很好。 我看到这个问题的方法有两种。

1. 影响较小（与以下2相比）是在客户端/工作站上的dc1.acme.local和dc2.acme.local的hosts文件中创build一个条目，指向DC的clt NIC IP。

要么

2. 手动在每个DC的netlogon.dns文件中创build必要的SRVlogging。 这可能会对服务器networking造成一些影响。 如果configuration成员服务器有时可以与cltnetworking上的DC通信。

总而言之，没有一件是漂亮的，但这不一定是最终的目标。 也许客户只是testing你的技术印章。 把它放在他们的会议桌上，告诉他们： “在这里，这是可行的，但是我以正常的速度收费4倍来configuration和支持它，你可以把它降低到正常速度的1.5倍–5.5倍的PITA收费。 [正确的解决scheme]“。

如前所述，我的build议是说服或运行。 但它确实是一个荒谬的有趣的小练习。 🙂

最后我去了两个网站的解决scheme：

• 两个DC用于“服务器”networking，两个DC用于“客户”networking。
• 两个AD网站，一个用于“服务器”networking，一个用于“客户”网站。
• 在“服务器”networking中的DC将只有一个NIC位于该服务器上（客户端根本不会与他们交谈），所以这很容易。
• 在“客户”区域的DC将有两个，但只会在DNS中注册其客户端。
• 服务器将与他们的区议会交谈，客户将与他们谈话。

当然，这意味着在两个networking之间启用复制stream量。 “客户”networking中的数据中心仍然会有一个坐在“服务器”networking上的网卡，但由于它不会在DNS中注册，该networking中的数据中心将使用客户端IP地址与他们联系; 所以网卡实际上是完全无用的，需要打开一些防火墙端口。 唯一的另一种select是重buildDC的hosts文件，但我们希望可以避免。

那么，我认为这是最好的，可以做到尽可能多（疯狂）的要求。

感谢所有的build议:-)

首先，当我们向客户提供服务时，我们应该质疑他们的要求是什么。 让客户了解他们的复杂程度是不必要的。

• 什么是客户的＃
• 这是所有内部stream量？
• 什么是域的function级别？
• 是否使用了TLS协议？

使用KISS方法 – 将创build两个VLAN“SVR”和“CLT”启用SSL / TLS并将其称为一天…