Profile Management

场景 1 - 地理位置相邻的用户存储和故障转移群集的基本设置

“我希望我的用户始终将地理位置相邻的首选联网用户存储 (NUS) 用于其配置文件。” 方案 1 和 2 适用于此种情况。

“我希望我的 NUS 保留在故障转移群集中,这样可以实现高可用性。” 方案 2 适用于此种情况。

下图说明了此方案。位于北美洲 (NA) 的用户希望使用纽约而非布里斯班的 NUS。目地是减少延迟,并将通过与澳大利亚或新西兰 (ANZ) 的洲际链接发送的通信量降至最低。

Diagram(示意图)

选项 1 – DFS 命名空间

背景信息

实施此方案

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 命名空间

背景信息

实施此方案

通过添加故障转移群集,您可以提供基本的高可用性。

此方案的要点在于将文件服务器转换为故障转移群集,以便文件夹目标托管在故障转移群集而非一台单独的服务器中。

如果您需要命名空间服务器本身具有高可用性,则必须选择一个独立的命名空间。基于域的命名空间不支持将故障转移群集用作命名空间服务器。无论命名空间服务器的类型为何,文件夹目标都可以托管在故障转移群集中。

重要: 如果故障转移群集中的某台服务器出现故障,则可能不会保持文件的锁定状态。Profile Management 在配置文件处理过程中会在某些点解除 MUS 中的文件锁。某个关键点的故障转移可能会导致配置文件损坏。

场景 1 - 地理位置相邻的用户存储和故障转移群集的基本设置