场景 1 - 地理位置相邻的用户存储和故障转移群集的基本设置
“我希望我的用户始终将地理位置相邻的首选联网用户存储 (NUS) 用于其配置文件。” 方案 1 和 2 适用于此种情况。
“我希望我的 NUS 保留在故障转移群集中,这样可以实现高可用性。” 方案 2 适用于此种情况。
下图说明了此方案。位于北美洲 (NA) 的用户希望使用纽约而非布里斯班的 NUS。目地是减少延迟,并将通过与澳大利亚或新西兰 (ANZ) 的洲际链接发送的通信量降至最低。
选项 1 – DFS 命名空间
背景信息
- 有关 Microsoft DFS 命名空间技术的概述,请参阅 DFS 命名空间概述。
- 有关对用户存储执行负载平衡的建议,请参阅 Citrix 博客 https://www.citrix.com/blogs/2009/07/21/profile-management-load-balancing-user-stores/。
实施此方案
DFS 命名空间可以解决上述博客文章中提到的一些问题。
我们为 NUS 设置一个命名空间,称为 \\MyCorp\Profiles 。它是命名空间的根目录。我们在纽约和布里斯班(以及任何其他站点)设置命名空间服务器。每个命名空间服务器都有文件夹与每个 Active Directory 位置对应,而这些位置在纽约或布里斯班的服务器上都有与之对应的目标。
我们可以在 Active Directory 中配置以下位置(用户记录的一部分)。
AD 位置属性 (#l#) | 地理位置 |
---|---|
沃加沃加 | ANZ |
达尔文 | ANZ |
布里斯班 | ANZ |
奥克兰 | ANZ |
西雅图 | 不适用 |
圣地亚哥 | 不适用 |
西棕榈滩 | 不适用 |
纽约波基普西 | 不适用 |
下图显示了使用 DFS 命名空间进行此设置的一种方法。
设置命名空间后,我们将用户存储路径设置配置为:
\\MyCorp\Profiles\#l#
属于这八个站点的用户配置文件仅分发到两台服务器,这符合此场景所需的地理位置约束条件。
备选方法
可以使用如下排序规则对命名空间目标进行排序。当 DFS 命名空间决定了要使用的目标时,可以指定只选择本地站点中的目标。对于任何指定用户而言,只要确保每个桌面和每台服务器都保证属于同一个站点,这种方法即会非常有效。
如果假设通常在波基普西办公的用户到访瓦格瓦格,此方法将会失效。这些用户所用便携式计算机的配置文件可能来自布里斯班,但其已发布的应用程序使用的配置文件可能来自纽约。
使用 AD 属性这一推荐技术可以确保为用户发起的每个会话选择相同的 DFS 命名空间。原因为 #l# 派生自用户的 AD 配置,而非派生自计算机配置。
方案 2 - 具有故障转移群集化功能的 DFS 命名空间
背景信息
- 有关配置双节点文件服务器故障转移群集的操作步骤指导,请参阅部署双节点群集文件服务器。
- 有关选择命名空间类型的信息,请参阅 https://docs.microsoft.com/en-us/windows-server/storage/dfs-namespaces/choose-a-namespace-type。
实施此方案
通过添加故障转移群集,您可以提供基本的高可用性。
此方案的要点在于将文件服务器转换为故障转移群集,以便文件夹目标托管在故障转移群集而非一台单独的服务器中。
如果您需要命名空间服务器本身具有高可用性,则必须选择一个独立的命名空间。基于域的命名空间不支持将故障转移群集用作命名空间服务器。无论命名空间服务器的类型为何,文件夹目标都可以托管在故障转移群集中。
重要:如果故障转移群集中的某台服务器出现故障,则可能不会保持文件的锁定状态。Profile Management 在配置文件处理过程中会在某些点解除 MUS 中的文件锁。某个关键点的故障转移可能会导致配置文件损坏。