-创建可用于负载平衡器或关联到虚拟机的名为网络接口 (NIC) 的资源。
+创建可用于负载均衡器或关联到虚拟机的名为网络接口 (NIC) 的资源。
azure network nic create -g myresourcegroup -l chinaeast -n testnic1 --subnet-name subnet-1 --subnet-vnet-name myvnet
diff --git a/articles/best-practices-background-jobs.md b/articles/best-practices-background-jobs.md
index efc2a37ad..a41302908 100644
--- a/articles/best-practices-background-jobs.md
+++ b/articles/best-practices-background-jobs.md
@@ -244,8 +244,8 @@ Web 角色和辅助角色在启动、运行和停止时会经历一组不同的
- **Run** 方法的典型实现包含用于启动每个后台任务的代码，以及定期检查所有后台任务状态的循环构造。它可以重新启动任何失败的任务，或监视用于指示作业已完成的取消标记。
- 如果后台任务引发了未处理的异常，则应该回收该任务，同时允许角色中的任何其他后台任务继续运行。但是，如果异常是由于任务外部的对象（例如共享存储）损坏所造成的，则应由 **RoleEntryPoint** 类处理异常，应取消所有任务，并允许 **Run** 方法结束。然后，Azure 将重新启动角色。
- 使用 **OnStop** 方法可以暂停或终止后台任务并清理资源。这可能涉及到停止长时间运行的任务或多步骤任务，请务必考虑到这种操作的后果，以避免数据不一致。如果角色实例出于任何原因（用户启动的关机除外）而停止，**OnStop** 方法中运行的代码必须在五分钟内完成，然后才能将它强行终止。确保代码可以在这段时间内完成，或者可以容忍无法完成运行。
-- 当 **RoleEntryPoint.OnStart** 方法返回 true 时，Azure 负载平衡器开始将流量定向到角色实例。因此，请考虑将所有初始化代码置于 **OnStart** 方法中，使未成功初始化的角色实例不会收到任何流量。
-- 除了 **RoleEntryPoint** 类的方法以外，还可以使用启动任务。你应该使用启动任务来初始化需要在 Azure 负载平衡器中更改的任何设置，因为在角色接收任何请求之前将执行这些任务。有关详细信息，请参阅[在 Azure 中运行启动任务](http://msdn.microsoft.com/zh-cn/library/azure/hh180155.aspx)。
+- 当 **RoleEntryPoint.OnStart** 方法返回 true 时，Azure 负载均衡器开始将流量定向到角色实例。因此，请考虑将所有初始化代码置于 **OnStart** 方法中，使未成功初始化的角色实例不会收到任何流量。
+- 除了 **RoleEntryPoint** 类的方法以外，还可以使用启动任务。你应该使用启动任务来初始化需要在 Azure 负载均衡器中更改的任何设置，因为在角色接收任何请求之前将执行这些任务。有关详细信息，请参阅[在 Azure 中运行启动任务](http://msdn.microsoft.com/zh-cn/library/azure/hh180155.aspx)。
- 如果启动任务发生错误，它可以强制角色持续重新启动。这可能会阻止你执行到以前暂存版本的 VIP 回切，因为交换需要对角色的独占访问权限，而在角色重新启动时无法做到这一点。若要解决此问题：
- 将以下代码添加到角色中 **OnStart** 和 **Run** 方法的开头：
diff --git a/articles/best-practices-network-security.md b/articles/best-practices-network-security.md
index 09e792cc3..0c46c1f69 100644
--- a/articles/best-practices-network-security.md
+++ b/articles/best-practices-network-security.md
@@ -45,7 +45,7 @@ Microsoft 采取综合性的方案来保护运行超大规模全球服务所需
![企业网络中的外围网络][3]
-有许多体系结构可用于实施外围网络，从 Web 场前面的简单负载平衡器到多子网外围网络，每个边界上设有各种机制来阻止流量，并保护企业网络的更深入层。如何构建外围网络取决于组织的特定要求和相关的风险容限度。
+有许多体系结构可用于实施外围网络，从 Web 场前面的简单负载均衡器到多子网外围网络，每个边界上设有各种机制来阻止流量，并保护企业网络的更深入层。如何构建外围网络取决于组织的特定要求和相关的风险容限度。
当客户将工作负荷移到公有云时，Azure 中的外围网络体系结构必须支持类似的功能，才能满足合规性和安全性要求。本文提供有关客户如何在 Azure 中构建安全网络环境的指导，其中重点介绍了外围网络，但也全面讨论了网络安全的许多层面，从以下问题开始（不限于这些问题）：
@@ -77,7 +77,7 @@ Microsoft 采取综合性的方案来保护运行超大规模全球服务所需
3. **跨界连接**：客户可以通过 Azure VPN 网关或第三方网络虚拟设备，在虚拟网络和多个本地站点或 Azure 中的其他虚拟网络之间创建跨界连接。Azure 支持使用标准 IPsec/IKE 协议和 ExpressRoute 专用连接的站点到站点 (S2S) VPN。
4. **网络安全组** (NSG) 允许客户根据所需的粒度（网络接口、单个 VM 或虚拟子网）创建规则 (ACL)。客户可以从客户网络上的系统，通过跨界连接或直接 Internet 通信来允许或拒绝虚拟网络内的工作负荷，以控制访问。
5. **用户定义的路由** (UDR) 和 **IP 转发**允许客户定义虚拟网络中不同层之间的通信路径。客户可以部署防火墙、IDS/IPS 和其他虚拟设备，并通过这些安全设备来路由网络流量，以实施安全边界策略、审核和检查。
-6. Azure 应用商店中的**网络虚拟设备**：Azure 应用商店和 VM 映像库中提供了防火墙、负载平衡器和 IDS/IPS（入侵检测/预防服务）等安全设备。客户可将这些设备部署到其虚拟网络，特别是安全边界（包括外围网络子网），以实现多层安全网络环境。
+6. Azure 应用商店中的**网络虚拟设备**：Azure 应用商店和 VM 映像库中提供了防火墙、负载均衡器和 IDS/IPS（入侵检测/预防服务）等安全设备。客户可将这些设备部署到其虚拟网络，特别是安全边界（包括外围网络子网），以实现多层安全网络环境。
以下示例演示了如何使用这些功能在 Azure 中构造外围网络体系结构：
@@ -148,7 +148,7 @@ Microsoft 采取综合性的方案来保护运行超大规模全球服务所需
#### 2) 边界位于何处？
确定边界数量后，下一个决策点就是在何处实施它们。通常有三种选择：1) 使用基于 Internet 的中介服务（例如基于云的 WAF，本文中未讨论），2) 使用 Azure 的本机功能和/或网络虚拟设备，3) 使用本地网络上的物理设备。
-在纯粹的 Azure 网络上，选项包括本机 Azure 功能（例如 Azure 负载平衡器），或由 Azure 丰富的合作伙伴生态系统提供的网络虚拟设备（例如检查点防火墙）。
+在纯粹的 Azure 网络上，选项包括本机 Azure 功能（例如 Azure 负载均衡器），或由 Azure 丰富的合作伙伴生态系统提供的网络虚拟设备（例如检查点防火墙）。
如果 Azure 与本地网络之间需要边界，安全设备可以位于连接的任何一端（或两端）。因此，必须确定安全设备的位置。
diff --git a/articles/best-practices-resource-manager-security.md b/articles/best-practices-resource-manager-security.md
index 2d2a05674..de5cdcf4e 100644
--- a/articles/best-practices-resource-manager-security.md
+++ b/articles/best-practices-resource-manager-security.md
@@ -196,7 +196,7 @@
NSG 包含默认规则。默认规则无法删除，但由于给它们分配的优先级最低，可以用创建的规则来重写它们。默认规则描述平台所推荐的默认设置。正如以下默认规则所阐述的那样，从方向上来说，在虚拟网络中发起和结束的通信可以是入站通信，也可以是出站通信。
-虽然出站方向的通信允许连接到 Internet，但默认情况下，入站方向的通信在连接到 Internet 时会被阻止。默认规则允许 Azure 负载平衡器查看 VM 的运行状况。如果 NSG 节点下的 VM 或 VM 集不参与负载平衡集，你可以重写此规则。
+虽然出站方向的通信允许连接到 Internet，但默认情况下，入站方向的通信在连接到 Internet 时会被阻止。默认规则允许 Azure 负载均衡器查看 VM 的运行状况。如果 NSG 节点下的 VM 或 VM 集不参与负载平衡集，你可以重写此规则。
默认规则显示在下面的表中。
@@ -220,7 +220,7 @@ DENY ALL OUTBOUND | 65500 | * | * | * | * | * | DENY
NSG 规则是显式的。除了 NSG 规则中指定的情况，不会对流量进行允许或拒绝操作。不过，不管网络安全组的规范如何，两类流量是始终允许的。进行这些预配是为了支持基础结构：
-- **主机节点的虚拟 IP**：基础结构服务（如 DHCP、DNS 和运行状况监视）是通过虚拟化的主机 IP 地址 168.63.129.16 提供的。此公用 IP 地址属于 Microsoft，并将是唯一的用于所有区域的虚拟化 IP 地址，而且没有其他用途。此 IP 地址映射到托管 VM 的服务器计算机（主机节点）的物理 IP 地址。主机节点充当 DHCP 中继、DNS 递归解析器，以及进行负载平衡器运行状况探测和计算机运行状况探测的探测源。不应将针对此 IP 地址的通信视为一种攻击。
+- **主机节点的虚拟 IP**：基础结构服务（如 DHCP、DNS 和运行状况监视）是通过虚拟化的主机 IP 地址 168.63.129.16 提供的。此公用 IP 地址属于 Microsoft，并将是唯一的用于所有区域的虚拟化 IP 地址，而且没有其他用途。此 IP 地址映射到托管 VM 的服务器计算机（主机节点）的物理 IP 地址。主机节点充当 DHCP 中继、DNS 递归解析器，以及进行负载均衡器运行状况探测和计算机运行状况探测的探测源。不应将针对此 IP 地址的通信视为一种攻击。
- **许可（密钥管理服务）**：在 VM 中运行的 Windows 映像应该获得许可。因此，将会向处理此类查询的密钥管理服务主机服务器发送许可请求。这将始终在出站端口 1688 上进行。
### 默认标记
@@ -232,7 +232,7 @@ NSG 规则是显式的。除了 NSG 规则中指定的情况，不会对流量
标记 | 说明
--- | ---
VIRTUAL\_NETWORK | 表示你的所有网络地址空间。它包括虚拟网络地址空间（Azure 中的 IP CIDR）以及所有连接的本地地址空间（本地网络）。另外还包括虚拟网络到虚拟网络的地址空间。
-AZURE_LOADBALANCER | 表示 Azure 基础结构负载平衡器，将转换为 Azure 数据中心 IP，从中进行 Azure 运行状况探测。仅当与 NSG 关联的 VM 或 VM 集参与负载平衡集的情况下，才需要此项。
+AZURE_LOADBALANCER | 表示 Azure 基础结构负载均衡器，将转换为 Azure 数据中心 IP，从中进行 Azure 运行状况探测。仅当与 NSG 关联的 VM 或 VM 集参与负载平衡集的情况下，才需要此项。
INTERNET | 表示虚拟网络外部的 IP 地址空间，可以通过公共 Internet 进行访问。此范围还包括 Azure 拥有的公共 IP 空间。
### 端口和端口范围
diff --git a/articles/best-practices-retry-general.md b/articles/best-practices-retry-general.md
index 6f22dd620..b30b1a6b0 100644
--- a/articles/best-practices-retry-general.md
+++ b/articles/best-practices-retry-general.md
@@ -30,7 +30,7 @@
* 云环境中的许多资源是共享的，为了保护这些资源，会限制对这些资源的访问。某些服务在负载上升到特定级别时，或到达吞吐量比率的上限时，会拒绝连接以便处理现有的请求，并为所有用户维持服务性能。限制有助于为共享资源的邻居与其他租户维持服务质量。
* 云环境是使用大量商用硬件单元构建而成的。云环境将负载动态分散到多个计算单元和基础结构组件上以提供性能，并通过自动回收或更换故障单元来提供可靠性。这种动态性意味着可能偶尔会发生暂时性故障和暂时连接失败。
-* 在应用程序与资源及其使用的服务之间，通常有多个硬件组件，包括网络基础结构，例如路由器和负载平衡器。这个附加的基础结构偶尔会导致额外的连接延迟与暂时性连接故障。
+* 在应用程序与资源及其使用的服务之间，通常有多个硬件组件，包括网络基础结构，例如路由器和负载均衡器。这个附加的基础结构偶尔会导致额外的连接延迟与暂时性连接故障。
* 客户端与服务器之间的网络状况会不时改变，尤其是通过 Internet 通信时。即使在本地位置，非常繁重的流量负载也可能会导致通信变慢，造成间歇性的连接失败。
## 挑战
diff --git a/articles/choose-web-site-cloud-service-vm.md b/articles/choose-web-site-cloud-service-vm.md
index d827a5de4..d3fb0aea7 100644
--- a/articles/choose-web-site-cloud-service-vm.md
+++ b/articles/choose-web-site-cloud-service-vm.md
@@ -250,7 +250,7 @@ Azure 网站是用于托管公司网站的理想解决方案。通过该网站
| X |
X |
X |
- 虚拟机可以扩大到多个实例，但必须编写这些虚拟机上运行的服务，来处理向外扩展。你需要配置负载平衡器，跨计算机路由请求；还需要创建地缘组，防止因维护或硬件故障导致同时重新启动所有实例。 |
+ 虚拟机可以扩大到多个实例，但必须编写这些虚拟机上运行的服务，来处理向外扩展。你需要配置负载均衡器，跨计算机路由请求；还需要创建地缘组，防止因维护或硬件故障导致同时重新启动所有实例。 |
支持 SSL |
diff --git a/articles/cloud-services-enable-communication-role-instances.md b/articles/cloud-services-enable-communication-role-instances.md
index cd5a57040..4017974f5 100644
--- a/articles/cloud-services-enable-communication-role-instances.md
+++ b/articles/cloud-services-enable-communication-role-instances.md
@@ -30,7 +30,7 @@ wacn.date="11/12/2015"/>
```
## 实例输入终结点
-实例输入终结点类似于输入终结点，但允许你通过使用负载平衡器上的端口转发，映射每个角色实例的面向公众的特定端口。你可以指定单个面向公众的端口，也可以指定一系列端口。
+实例输入终结点类似于输入终结点，但允许你通过使用负载均衡器上的端口转发，映射每个角色实例的面向公众的特定端口。你可以指定单个面向公众的端口，也可以指定一系列端口。
实例输入终结点只能使用 **tcp** 或 **udp** 作为协议。
diff --git a/articles/cloud-services-role-lifecycle-dotnet.md b/articles/cloud-services-role-lifecycle-dotnet.md
index b64d1945b..be430aa11 100644
--- a/articles/cloud-services-role-lifecycle-dotnet.md
+++ b/articles/cloud-services-role-lifecycle-dotnet.md
@@ -35,7 +35,7 @@ wacn.date="10/17/2015"/>
## OnStart 方法
-当 Azure 使角色实例联机时，就会调用 **OnStart** 方法。OnStart 代码执行时，角色实例被标记为 **Busy**，并且负载平衡器不会将外部通信引导到该角色。你可以重写此方法以执行初始化工作，例如实现事件处理程序和启动 [Azure Diagnostics](/documentation/articles/cloud-services-how-to-monitor)。
+当 Azure 使角色实例联机时，就会调用 **OnStart** 方法。OnStart 代码执行时，角色实例被标记为 **Busy**，并且负载均衡器不会将外部通信引导到该角色。你可以重写此方法以执行初始化工作，例如实现事件处理程序和启动 [Azure Diagnostics](/documentation/articles/cloud-services-how-to-monitor)。
如果 **OnStart** 返回 **true**，则该实例已成功初始化，并且 Azure 已调用 **RoleEntryPoint.Run** 方法。如果 **OnStart** 返回 **false**，则角色将立即终止，而不执行任何计划中的关闭序列。
diff --git a/articles/expressroute-howto-coexist-classic.md b/articles/expressroute-howto-coexist-classic.md
index 7e22bf868..62fe419e0 100644
--- a/articles/expressroute-howto-coexist-classic.md
+++ b/articles/expressroute-howto-coexist-classic.md
@@ -55,7 +55,7 @@
你可能已在具有现有站点到站点 VPN 连接或 ExpressRoute 连接的位置拥有虚拟网络。**为现有虚拟网络配置共存连接**部分将指导你删除网关，然后创建新的 ExpressRoute 连接和站点到站点 VPN 连接。请注意，在创建新连接时，必须按照非常特定的顺序完成步骤。不要按照其他文章中的说明来创建网关和连接。
- 在此过程中，创建可以共存的连接将需要你删除网关，然后配置新网关。这意味着，在你删除并重新创建网关和连接时，跨界连接将会停止工作，但你无需将任何 VM 或服务迁移到新的虚拟网络。在你配置网关时，如果进行了相应配置，你的 VM 和服务仍可以通过负载平衡器与外界通信。
+ 在此过程中，创建可以共存的连接将需要你删除网关，然后配置新网关。这意味着，在你删除并重新创建网关和连接时，跨界连接将会停止工作，但你无需将任何 VM 或服务迁移到新的虚拟网络。在你配置网关时，如果进行了相应配置，你的 VM 和服务仍可以通过负载均衡器与外界通信。
## 使用 ExpressRoute 和站点到站点连接创建新的虚拟网络
diff --git a/articles/hdinsight-hbase-provision-vnet-v1.md b/articles/hdinsight-hbase-provision-vnet-v1.md
index 3b6abc4e3..b82cdc0a4 100644
--- a/articles/hdinsight-hbase-provision-vnet-v1.md
+++ b/articles/hdinsight-hbase-provision-vnet-v1.md
@@ -24,7 +24,7 @@
通过虚拟网络集成，可以将 HBase 群集部署到应用程序所在的虚拟网络，以便应用程序直接与 HBase 进行通信。优点包括：
- 将网站直接连接到 HBase 群集节点，以通过 HBase Java 远程过程调用 (RPC) API 实现通信。
-- 提高性能，因为流量不必通过多个网关和负载平衡器。
+- 提高性能，因为流量不必通过多个网关和负载均衡器。
- 能够以更安全的方式处理敏感信息，而无需公开公共终结点。
##先决条件
diff --git a/articles/hdinsight-hbase-provision-vnet.md b/articles/hdinsight-hbase-provision-vnet.md
index 75fe5dddf..054ef7b1a 100644
--- a/articles/hdinsight-hbase-provision-vnet.md
+++ b/articles/hdinsight-hbase-provision-vnet.md
@@ -20,7 +20,7 @@
通过虚拟网络集成，可以将 HBase 群集部署到应用程序所在的虚拟网络，以便应用程序直接与 HBase 进行通信。优点包括：
- 将网站直接连接到 HBase 群集节点，以通过 HBase Java 远程过程调用 (RPC) API 实现通信。
-- 提高性能，因为流量不必通过多个网关和负载平衡器。
+- 提高性能，因为流量不必通过多个网关和负载均衡器。
- 能够以更安全的方式处理敏感信息，而无需公开公共终结点。
##先决条件
diff --git a/articles/media-services-fmp4-live-ingest-overview.md b/articles/media-services-fmp4-live-ingest-overview.md
index 48aa00f44..2a855a196 100644
--- a/articles/media-services-fmp4-live-ingest-overview.md
+++ b/articles/media-services-fmp4-live-ingest-overview.md
@@ -39,7 +39,7 @@
下面是适用于 Windows Azure 媒体服务的实时引入的特殊格式定义列表：
1. ‘ftyp’、LiveServerManifestBox 及 ‘moov’ 框必须连同每个请求 (HTTP POST) 一起发送。必须在流的开头发送，每当需要恢复流引入时，编码器都必须重新连接。有关详细信息，请参阅 [1] 中的“第 6 部分”。
-2. [1] 中的第 3.3.2 部分实时引入定义了名为 StreamManifestBox 的可选框。Windows Azure 负载平衡器的路由逻辑使得此框的使用已过时，在引入到 Windows Azure 媒体服务时不应该存在此框。如果存在此框，Azure 媒体服务会以无提示方式将其忽略。
+2. [1] 中的第 3.3.2 部分实时引入定义了名为 StreamManifestBox 的可选框。Windows Azure 负载均衡器的路由逻辑使得此框的使用已过时，在引入到 Windows Azure 媒体服务时不应该存在此框。如果存在此框，Azure 媒体服务会以无提示方式将其忽略。
3. 每个片段必须有在 [1] 的 3.2.3.2 中定义的 TrackFragmentExtendedHeaderBoxMUST。
4. 应该使用第 2 版的 TrackFragmentExtendedHeaderBox，才能在多个数据中心生成具有相同 URL 的媒体片段。对于跨数据中心故障转移基于索引的流格式（例如 Apple HTTP 实时流 (HLS) 和基于索引的 MPEG DASH），片段索引字段是必需的。若要启用跨数据中心故障转移，多个编码器之间的片段索引必须同步，后续的每个媒体片段会增加 1，即使跨编码器重新启动或失败。
5. [1] 中的第 3.3.6 部分定义了名为 MovieFragmentRandomAccessBox (‘mfra’) 的框，此框可能会在实时引入结束时发送，表示通道 EOS（流式传输结束）。Azure 媒体服务的引入逻辑使得 EOS（流式传输结束）的使用方式已过时，不应该发送实时引入的 ‘mfra’ 框。如果已发送，Azure 媒体服务会无提示方式将其忽略。建议使用[通道重置](https://msdn.microsoft.com/zh-cn/library/azure/dn783458.aspx#reset_channels)来重置引入点的状态，此外，建议使用[节目停止](https://msdn.microsoft.com/zh-cn/library/azure/dn783463.aspx#stop_programs)来结束演播与流。
diff --git a/articles/resource-manager-supported-services.md b/articles/resource-manager-supported-services.md
index 64f1d8bbf..d243d14e5 100644
--- a/articles/resource-manager-supported-services.md
+++ b/articles/resource-manager-supported-services.md
@@ -85,7 +85,7 @@ Azure 资源管理器为你提供了一种新的方式来部署和管理构成
| ------- | ------- | -------- | -------------- | -------- | ------ |
| 应用程序网关 | 是 | | | | |
| DNS | 是 | | | [创建 DNS 区域](https://msdn.microsoft.com/zh-cn/library/azure/mt130622.aspx) | [2015-08-01](https://github.com/Azure/azure-resource-manager-schemas/blob/master/schemas/2015-08-01/Microsoft.Network.json) |
-| 负载平衡器 | 是 | | | [创建负载平衡器](https://msdn.microsoft.com/zh-cn/library/azure/mt163574.aspx) | [2015-08-01](https://github.com/Azure/azure-resource-manager-schemas/blob/master/schemas/2015-08-01/Microsoft.Network.json) |
+| 负载均衡器 | 是 | | | [创建负载均衡器](https://msdn.microsoft.com/zh-cn/library/azure/mt163574.aspx) | [2015-08-01](https://github.com/Azure/azure-resource-manager-schemas/blob/master/schemas/2015-08-01/Microsoft.Network.json) |
| 虚拟网络 | 是 | 是 | 否 | [创建虚拟网络](https://msdn.microsoft.com/zh-cn/library/azure/mt163661.aspx) | [2015-08-01](https://github.com/Azure/azure-resource-manager-schemas/blob/master/schemas/2015-08-01/Microsoft.Network.json) |
| 流量管理器 | 是 | 否 | | [创建流量管理器配置文件](https://msdn.microsoft.com/zh-cn/library/azure/mt163581.aspx) | |
| ExpressRoute | 是 | 否 | 否 | [ExpressRoute REST](https://msdn.microsoft.com/zh-cn/library/azure/mt586720.aspx) | |
diff --git a/articles/service-bus-architecture.md b/articles/service-bus-architecture.md
index d4e344ba0..70a249794 100644
--- a/articles/service-bus-architecture.md
+++ b/articles/service-bus-architecture.md
@@ -39,13 +39,13 @@
## 处理传入消息请求
-当客户端向服务总线发送请求时，Azure 负载平衡器将其路由到任何一个网关节点。网关节点将为请求授权。如果该请求涉及到某个消息实体（队列、主题、订阅），则网关节点将在网关存储中查找该实体，并判断实体位于哪个消息存储中。然后，它将查询哪些消息代理节点目前正在为此容器提供服务，并将请求发送到该消息代理节点。消息代理节点将处理请求并更新容器存储中的实体状态。然后，消息代理节点向网关节点发送响应，而网关节点向发出原始请求的客户端发送相应的响应。
+当客户端向服务总线发送请求时，Azure 负载均衡器将其路由到任何一个网关节点。网关节点将为请求授权。如果该请求涉及到某个消息实体（队列、主题、订阅），则网关节点将在网关存储中查找该实体，并判断实体位于哪个消息存储中。然后，它将查询哪些消息代理节点目前正在为此容器提供服务，并将请求发送到该消息代理节点。消息代理节点将处理请求并更新容器存储中的实体状态。然后，消息代理节点向网关节点发送响应，而网关节点向发出原始请求的客户端发送相应的响应。
## 处理传入中继请求
-当客户端向服务总线发送请求时，Azure 负载平衡器将其路由到任何一个网关节点。如果请求为侦听请求，网关节点将创建新的中继。如果请求是对特定中继的连接请求，网关节点会将连接请求转发给拥有中继的网关节点。拥有中继的网关节点向侦听客户端发送会合请求，要求侦听器与接收连接请求的网关节点创建一个临时通道。
+当客户端向服务总线发送请求时，Azure 负载均衡器将其路由到任何一个网关节点。如果请求为侦听请求，网关节点将创建新的中继。如果请求是对特定中继的连接请求，网关节点会将连接请求转发给拥有中继的网关节点。拥有中继的网关节点向侦听客户端发送会合请求，要求侦听器与接收连接请求的网关节点创建一个临时通道。
建立中继连接后，客户端可以通过用于会合的网关节点交换消息。
@@ -53,7 +53,7 @@
## 处理传入通知中心请求
-当客户端向服务总线发送请求时，Azure 负载平衡器将其路由到任何一个网关节点。如果请求是现有通知中心的设备注册，网关节点会将注册写入注册存储，并向调用设备发送回复。如果请求是通知消息，网关节点将消息排入通知队列。其中一个通知节点将在通知队列中取消消息排队，并将该消息发送到注册存储中注册的所有设备。如果某个消息要由许多设备接收，则多个通知节点会参与将消息发送到设备的操作。
+当客户端向服务总线发送请求时，Azure 负载均衡器将其路由到任何一个网关节点。如果请求是现有通知中心的设备注册，网关节点会将注册写入注册存储，并向调用设备发送回复。如果请求是通知消息，网关节点将消息排入通知队列。其中一个通知节点将在通知队列中取消消息排队，并将该消息发送到注册存储中注册的所有设备。如果某个消息要由许多设备接收，则多个通知节点会参与将消息发送到设备的操作。
diff --git a/articles/service-bus-async-messaging.md b/articles/service-bus-async-messaging.md
index 0fa0cf70d..50519cff4 100644
--- a/articles/service-bus-async-messaging.md
+++ b/articles/service-bus-async-messaging.md
@@ -15,7 +15,7 @@
可以通过多种不同的方式实现异步消息传送。通过队列、主题和订阅（统称为消息传送实体），Azure 服务总线支持通过存储和转发机制实现异步传送。在正常（同步）操作中，你将消息发送到队列和主题，并从队列和订阅接收消息。你编写的应用程序依赖于这些始终可用的实体。当实体运行状况因各种环境而发生变化时，你需要一种能够提供满足大多数需求的缩减功能实体的方式。
-应用程序通常使用异步消息传送模式来实现大量通信方案。你可以构建一些应用程序，以便客户端在其中可以向服务发送消息（即使该服务未运行）。对于将经历大量通信的应用程序，队列可以通过提供缓冲通信的场所，帮助对负载进行分级。最后，你可以获得一个简单而高效的负载平衡器，从而在多台计算机间分发消息。
+应用程序通常使用异步消息传送模式来实现大量通信方案。你可以构建一些应用程序，以便客户端在其中可以向服务发送消息（即使该服务未运行）。对于将经历大量通信的应用程序，队列可以通过提供缓冲通信的场所，帮助对负载进行分级。最后，你可以获得一个简单而高效的负载均衡器，从而在多台计算机间分发消息。
为了维护任何这些实体的可用性，请考虑表达这些实体可能不可用的多种方式，从而构建持久的消息传送系统。一般而言，发现实体对应用程序不可用时，有以下表达方式：
diff --git a/articles/service-bus-dotnet-hybrid-app-using-service-bus-relay.md b/articles/service-bus-dotnet-hybrid-app-using-service-bus-relay.md
index 01f21c037..063dbd625 100644
--- a/articles/service-bus-dotnet-hybrid-app-using-service-bus-relay.md
+++ b/articles/service-bus-dotnet-hybrid-app-using-service-bus-relay.md
@@ -521,7 +521,7 @@
![][34]
- 此过程需要大约 5-7 分钟时间。由于这是你首次发布，因此 Azure 会依次执行以下操作以便公开应用程序：预配一台虚拟机 (VM)，执行安全强化，在 VM 上创建一个 Web 角色以承载应用程序，将代码部署到该 Web 角色以及配置负载平衡器和网络。
+ 此过程需要大约 5-7 分钟时间。由于这是你首次发布，因此 Azure 会依次执行以下操作以便公开应用程序：预配一台虚拟机 (VM)，执行安全强化，在 VM 上创建一个 Web 角色以承载应用程序，将代码部署到该 Web 角色以及配置负载均衡器和网络。
7. 当发布正在进行时，你可以在“Azure 活动日志”窗口中监视活动，该窗口通常位于 Visual Studio 或 Visual Web Developer 的底部。
diff --git a/articles/site-recovery-sql.md b/articles/site-recovery-sql.md
index f2b079015..696bbc28e 100644
--- a/articles/site-recovery-sql.md
+++ b/articles/site-recovery-sql.md
@@ -115,7 +115,7 @@ SQL Server 2008 R2 | Enterprise 或 Standard | 独立 | 使用本地镜像进行
3. 在网络中创建一个新的 SQL Server Azure 虚拟机，并将其配置为异步可用性组副本。如果您在故障转移到 Azure 后需要 SQL Server 层的高可用性，请在 Azure 中配置两个异步副本。
4. 在虚拟网络中设置域控制器的副本。
5. 确保已在虚拟机上启用虚拟机扩展。只有这样，才能在恢复计划中推送 SQL Server 特定的脚本。
-6. 使用 Azure 的内部负载平衡器配置可用性组的 SQL Server 侦听器。
+6. 使用 Azure 的内部负载均衡器配置可用性组的 SQL Server 侦听器。
7. 将应用程序层配置为使用侦听器访问数据库层。对于使用分布式事务的应用程序，建议您使用站点恢复进行 SAN 复制或 VMWare 站点到站点复制。
### 为 SQL Server 群集设置保护（Standard 或 2008 R2）
diff --git a/articles/site-recovery-workload.md b/articles/site-recovery-workload.md
index 245a95297..740d13614 100644
--- a/articles/site-recovery-workload.md
+++ b/articles/site-recovery-workload.md
@@ -26,7 +26,7 @@ Azure Site Recovery 功能在设计时牢记应用程序级别的保护/恢复
- 针对单层或 N 层应用程序的应用程序一致快照
- 集成应用程序级复制。充分利用同类最佳应用程序级产品，包括 AD 复制、SQL Always On、Exchange Database Availability Groups 和 Oracle Data Guard
- 灵活恢复计划让一次单击即可恢复整个应用程序堆栈成为可能，包括执行外部脚本甚至手动操作。
-- ASR 和 Azure 中的高级网络管理让你的应用程序特有的所有网络配置都实现自动化：保留 IP 地址、配置负载平衡器，或使用 Microsoft 的流量管理器以实现低 RTO 网络切换。
+- ASR 和 Azure 中的高级网络管理让你的应用程序特有的所有网络配置都实现自动化：保留 IP 地址、配置负载均衡器，或使用 Microsoft 的流量管理器以实现低 RTO 网络切换。
- 丰富自动化库 (Rich Automation Library)，提供为生产做好准备的应用程序特定脚本。下载它们并集成到基于 ASR 的解决方案。
diff --git a/articles/sql-database-performance-guidance.md b/articles/sql-database-performance-guidance.md
index 3fbc79d91..0e68102a7 100644
--- a/articles/sql-database-performance-guidance.md
+++ b/articles/sql-database-performance-guidance.md
@@ -36,7 +36,7 @@ Microsoft 还在 Azure SQL 数据库中加入许多自动管理功能，如自
Azure SQL 数据库为每个用户数据库保留至少三个副本，并具有一种逻辑，可自动将每个更改同步地提交到副本仲裁。这样可确保任何单计算机故障均不会导致数据丢失。此外，每个副本均放在不同的硬件机架上，以使断电或网络交换机停运不会影响你的数据库。最后，还有一种逻辑，如果失去计算机，则自动重建副本，以使系统自动保留所需的运行状况属性，即使计算机的运行状况变得不正常也是如此。这些机制可避免当前在安装和配置高可用性解决方案时所需的漫长过程。通过为你的数据预先配置 HA 解决方案，可消除在使用传统方法生成任务关键型数据库解决方案时的另一个重大难题。
### 负载平衡
- 与传统虚拟机不同的是，Azure SQL 数据库还包含一种机制，可自动将负载分摊到多个计算机上。负载平衡器动态观察群集的资源用量，并将数据库副本移至群集中的计算机，以便将负载动态、公平地分摊到多个用户上。这样即扩展数据库的按需扩容功能，并且用户可独立考虑每个数据库的容量要求，因为负载平衡器将可迁移繁忙的数据库，使此类数据库彼此远离。在创建跨越许多数据库的解决方案时，此逻辑提供一个抽象层，通过该层可集中精力处理每个数据库的容量需要，而不必考虑虚拟机的具体大小限制。
+ 与传统虚拟机不同的是，Azure SQL 数据库还包含一种机制，可自动将负载分摊到多个计算机上。负载均衡器动态观察群集的资源用量，并将数据库副本移至群集中的计算机，以便将负载动态、公平地分摊到多个用户上。这样即扩展数据库的按需扩容功能，并且用户可独立考虑每个数据库的容量要求，因为负载均衡器将可迁移繁忙的数据库，使此类数据库彼此远离。在创建跨越许多数据库的解决方案时，此逻辑提供一个抽象层，通过该层可集中精力处理每个数据库的容量需要，而不必考虑虚拟机的具体大小限制。
### 内置管理
Azure SQL 数据库以服务的形式运行。这意味着为每个数据库定义了运行时间目标，避免产生漫长的维护停机时间。Microsoft 对于服务提供单供应商解决方案，这意味着如有任何问题，只需致电一家公司即可。另外，Microsoft 不断更新服务、添加功能、提高容量并寻找在我们进行的每次更新中改善体验的方法。更新以透明方式进行，不产生停机时间，这意味着更新集成在我们正常的 HA 故障转移机制内。这样，我们一宣布推出新功能，你即可使用这些功能，而不必等待在未来某个停机时间内升级服务器。
diff --git a/articles/virtual-machines-azure-resource-manager-architecture.md b/articles/virtual-machines-azure-resource-manager-architecture.md
index b6e3c19c9..d1baf5a07 100644
--- a/articles/virtual-machines-azure-resource-manager-architecture.md
+++ b/articles/virtual-machines-azure-resource-manager-architecture.md
@@ -23,7 +23,7 @@
在我们讨论 Azure 资源管理器的体系结构和各种资源提供程序之前，让我们回顾一下 Azure 服务管理的当前体系结构。在 Azure 服务管理中，宿主虚拟机的计算、存储或网络资源由以下各项提供：
-- 一项必不可少的云服务，用作宿主虚拟机的容器（计算）。虚拟机自动配备一个网络接口卡 (NIC) 并由 Azure 分配的 IP 地址。此外，云服务包含一个外部负载平衡器实例、一个公共 IP 地址以及若干默认终结点，以支持远程桌面、针对 Windows 虚拟机的远程 PowerShell 流量和针对 Linux 虚拟机的 Secure Shell (SSH) 流量。
+- 一项必不可少的云服务，用作宿主虚拟机的容器（计算）。虚拟机自动配备一个网络接口卡 (NIC) 并由 Azure 分配的 IP 地址。此外，云服务包含一个外部负载均衡器实例、一个公共 IP 地址以及若干默认终结点，以支持远程桌面、针对 Windows 虚拟机的远程 PowerShell 流量和针对 Linux 虚拟机的 Secure Shell (SSH) 流量。
- 一个必不可少的存储帐户，存储虚拟机的 VHD，包括操作系统、临时文件和附加的数据磁盘（存储）。
- 一个可选的虚拟网络，用作额外的容器，可以在其中创建子网结构并指定虚拟机所在的子网（网络）。
@@ -37,7 +37,7 @@
- 计算资源提供程序 (CRP)：对虚拟机和可选可用性集的实例提供支持。
- 存储资源提供程序 (SRP)：对所需的存储帐户提供支持，存储帐户存储虚拟机的 VHD，包括其操作系统和其附加的数据磁盘。
-- 网络资源提供程序 (NRP)：对所需的 NIC、虚拟机 IP 地址和虚拟网络内的子网及可选的负载平衡器、负载平衡器 IP 地址和网络安全组提供支持。
+- 网络资源提供程序 (NRP)：对所需的 NIC、虚拟机 IP 地址和虚拟网络内的子网及可选的负载均衡器、负载均衡器 IP 地址和网络安全组提供支持。
此外，资源提供程序内各个资源之间还存在相互关系：
@@ -45,13 +45,13 @@
- 虚拟机引用在 NRP 中定义的具体 NIC（必需）和在 CRP 中定义的可用性集（可选）。
- NIC 引用虚拟机的指定 IP 地址（必需）、虚拟机的虚拟网络的子网（必需）和网络安全组（可选）。
- 虚拟网络内的子网引用网络安全组（可选）。
-- 负载平衡器实例引用后端 IP 地址池，包括虚拟机的 NIC（可选），引用负载平衡器的公共或专用 IP 地址（可选）。
+- 负载均衡器实例引用后端 IP 地址池，包括虚拟机的 NIC（可选），引用负载均衡器的公共或专用 IP 地址（可选）。
资源的组件化为在 Azure 中的 IT 工作负荷配置基础结构时提供了更多的灵活性。Azure 资源管理器模板充分利用此灵活性来创建具体配置所需的从属资源集合。在执行模板时，资源管理器确保以正确的顺序创建某个配置的资源以保证依存关系和引用。例如，资源管理器将不会为某个虚拟机创建 NIC，直到它创建了含有子网和 IP 地址的虚拟网络（网络安全组是可选项）。
-资源组是一个容纳某个应用程序的相关资源的逻辑容器，可包括多个虚拟机、NIC、IP 地址、负载平衡器、子网和网络安全组。例如，可以作为一个管理单元来管理应用程序的所有资源。你可以创建、更新和同时删除这些资源。以下是一个在单一资源组中部署的应用程序示例。
+资源组是一个容纳某个应用程序的相关资源的逻辑容器，可包括多个虚拟机、NIC、IP 地址、负载均衡器、子网和网络安全组。例如，可以作为一个管理单元来管理应用程序的所有资源。你可以创建、更新和同时删除这些资源。以下是一个在单一资源组中部署的应用程序示例。
@@ -59,7 +59,7 @@
- 使用同一存储帐户的两个虚拟机具有相同的可用性集，并且处于虚拟网络的同一子网中。
- 每个虚拟机有单独的 NIC 和虚拟机 IP 地址。
-- 一个外部负载平衡器，将 Internet 流量分配到两个虚拟机的 NIC。
+- 一个外部负载均衡器，将 Internet 流量分配到两个虚拟机的 NIC。
此应用程序的所有资源都通过一个包含这些资源的资源组来管理。
diff --git a/articles/virtual-machines-command-line-tools.md b/articles/virtual-machines-command-line-tools.md
index 4b9d0ecc9..f13c4f722 100644
--- a/articles/virtual-machines-command-line-tools.md
+++ b/articles/virtual-machines-command-line-tools.md
@@ -346,11 +346,11 @@ info: vm shutdown command OK
info: vm export command OK
## 用于管理 Azure 虚拟机终结点的命令
-下图显示了多个虚拟机实例的典型部署的体系结构。请注意，在本示例中，端口 3389 在每台虚拟机上均为打开状态（用于进行 RDP 访问），并且负载平衡器用于将流量路由到虚拟机的每台虚拟机上还有一个内部 IP 地址（例如，168.55.11.1）。此内部 IP 地址也可用于虚拟机之间的通信。
+下图显示了多个虚拟机实例的典型部署的体系结构。请注意，在本示例中，端口 3389 在每台虚拟机上均为打开状态（用于进行 RDP 访问），并且负载均衡器用于将流量路由到虚拟机的每台虚拟机上还有一个内部 IP 地址（例如，168.55.11.1）。此内部 IP 地址也可用于虚拟机之间的通信。
-虚拟机的外部请求将通过负载平衡器。因此，不能针对包含多台虚拟机的部署中的特定虚拟机指定请求。对于包含多台虚拟机的部署，必须在虚拟机 (vm-port) 与负载平衡器 (lb-port) 之间配置端口映射。
+虚拟机的外部请求将通过负载均衡器。因此，不能针对包含多台虚拟机的部署中的特定虚拟机指定请求。对于包含多台虚拟机的部署，必须在虚拟机 (vm-port) 与负载均衡器 (lb-port) 之间配置端口映射。
**vm endpoint create <vm-name> <lb-port> [vm-port]**
diff --git a/articles/virtual-machines-deis-cluster.md b/articles/virtual-machines-deis-cluster.md
index 7169d6ecb..2b62b2ee2 100644
--- a/articles/virtual-machines-deis-cluster.md
+++ b/articles/virtual-machines-deis-cluster.md
@@ -16,7 +16,7 @@
本文将逐步指导你完成在 Azure 上设置 [Deis](http://deis.io/) 群集的过程。其中包括所有的步骤，从创建必要的证书，到在新设置的群集上部署和缩放示例 **Go** 应用程序。
-下图显示了部署的系统的体系结构。系统管理员可以使用 Deis 工具（如 **deis** 和 **deisctl**）来管理群集。连接是通过会将连接转发到群集上某个成员节点的 Azure 负载平衡器建立的。客户端也通过负载平衡器访问部署的应用程序。在此情况下，负载平衡器会将流量转发到 Deis 路由器网络，从者进一步将流量路由到托管在群集上的对应 Docker 容器。
+下图显示了部署的系统的体系结构。系统管理员可以使用 Deis 工具（如 **deis** 和 **deisctl**）来管理群集。连接是通过会将连接转发到群集上某个成员节点的 Azure 负载均衡器建立的。客户端也通过负载均衡器访问部署的应用程序。在此情况下，负载均衡器会将流量转发到 Deis 路由器网络，从者进一步将流量路由到托管在群集上的对应 Docker 容器。
@@ -70,7 +70,7 @@
8. 修改 **newStorageAccountName** 参数。这是 VM OS 磁盘的存储帐户。此帐户名称必须全域唯一。
-9. 修改 **publicDomainName** 参数。此参数将成为与负载平衡器公共 IP 关联的 DNS 名称的一部分。最终的 FQDN 格式是 _[此参数的值]_ _[区域]_.cloudapp.azure.com。例如，如果你将名称指定为 deishbai32，资源组已部署到美国西部区域，则负载平衡器的最终 FQDN 是 deishbai32.westus.cloudapp.azure.com。
+9. 修改 **publicDomainName** 参数。此参数将成为与负载均衡器公共 IP 关联的 DNS 名称的一部分。最终的 FQDN 格式是 _[此参数的值]_ _[区域]_.cloudapp.azure.com。例如，如果你将名称指定为 deishbai32，资源组已部署到美国西部区域，则负载均衡器的最终 FQDN 是 deishbai32.westus.cloudapp.azure.com。
10. 保存参数文件。接下来，你可以使用 Azure PowerShell 设置群集：
@@ -82,13 +82,13 @@
./deploy-deis.sh -n "[resource group name]" -l "West US" -f ./azuredeploy.json -e ./azuredeploy-parameters.json
-c ./cloud-config.yaml
-11. 设置资源组后，可以在 Azure 门户上看到组中的所有资源。如以下屏幕截图所示，资源组中有一个包含三个 VM 的虚拟网络，这些 VM 已加入同一个可用性集。该组还包含具有关联公共 IP 的负载平衡器。
+11. 设置资源组后，可以在 Azure 门户上看到组中的所有资源。如以下屏幕截图所示，资源组中有一个包含三个 VM 的虚拟网络，这些 VM 已加入同一个可用性集。该组还包含具有关联公共 IP 的负载均衡器。
## 安装客户端
-需要使用 **deisctl** 来控制 Deis 群集。尽管 deisctl 会自动安装在所有群集节点中，但较好的做法是在独立的管理计算机上使用 deisctl。此外，因为所有节点上只配置了专用 IP 地址，因此你需要通过负载平衡器（有公共 IP）使用 SSH 隧道，来连接到节点计算机。以下是在独立 Ubuntu 物理机或虚拟机上设置 deisctl 的步骤。
+需要使用 **deisctl** 来控制 Deis 群集。尽管 deisctl 会自动安装在所有群集节点中，但较好的做法是在独立的管理计算机上使用 deisctl。此外，因为所有节点上只配置了专用 IP 地址，因此你需要通过负载均衡器（有公共 IP）使用 SSH 隧道，来连接到节点计算机。以下是在独立 Ubuntu 物理机或虚拟机上设置 deisctl 的步骤。
1. 安装 deisctl:mkdir deis
@@ -106,7 +106,7 @@
export DEISCTL_TUNNEL=[public ip of the load balancer]: /documentation/articles/2223
模板定义了将 2223 映射到实例 1、将 2224 映射到实例 2、将 2225 映射到实例 3 的入站 NAT 规则。这提供了使用 deisctl 工具时的冗余。可以在 Azure 门户中检查这些规则：
-
+
> [AZURE.NOTE]模板目前仅支持三节点群集。这是因为 Azure 资源管理器模板 NAT 规则定义存在限制，它不支持循环语法。
@@ -159,7 +159,7 @@
以下步骤说明如何将“Hello World”Go 应用程序部署到群集。这些步骤基于 [Deis 文档](http://docs.deis.io/en/latest/using_deis/using-dockerfiles/#using-dockerfiles)。
-1. 为了使路由网络正确工作，指向负载平衡器公共 IP 的域需要有通配符 A 记录。以下屏幕截图显示了在 GoDaddy 上注册的示例域的 A 记录：
+1. 为了使路由网络正确工作，指向负载均衡器公共 IP 的域需要有通配符 A 记录。以下屏幕截图显示了在 GoDaddy 上注册的示例域的 A 记录：
diff --git a/articles/virtual-machines-docker-registry-on-azure-blob-storage.md b/articles/virtual-machines-docker-registry-on-azure-blob-storage.md
index a6efb88e2..627c6ff04 100644
--- a/articles/virtual-machines-docker-registry-on-azure-blob-storage.md
+++ b/articles/virtual-machines-docker-registry-on-azure-blob-storage.md
@@ -80,7 +80,7 @@ CONTAINER ID IMAGE COMMAND CREATED
3698ddfebc6f registry:2 "registry cmd/regist 2 seconds ago Up 1 seconds 0.0.0.0:5000->5000/tcp registry
```
-> [AZURE.IMPORTANT]本文档未涵盖配置 Docker 注册表安全性的操作，如果打开连接到虚拟机终结点上注册表端口的端口，则默认情况下，任何未经身份验证的用户都可以访问注册表；如果使用上述部署命令，则可以访问负载平衡器。
+> [AZURE.IMPORTANT]本文档未涵盖配置 Docker 注册表安全性的操作，如果打开连接到虚拟机终结点上注册表端口的端口，则默认情况下，任何未经身份验证的用户都可以访问注册表；如果使用上述部署命令，则可以访问负载均衡器。
>
> 请参阅[配置 Docker 注册表][registry-config]文档，以了解如何保护注册表实例和映像。
diff --git a/articles/virtual-machines-infrastructure-services-implementation-guidelines.md b/articles/virtual-machines-infrastructure-services-implementation-guidelines.md
index 001e67f18..43c54df49 100644
--- a/articles/virtual-machines-infrastructure-services-implementation-guidelines.md
+++ b/articles/virtual-machines-infrastructure-services-implementation-guidelines.md
@@ -203,9 +203,9 @@ Azure 将对可用的数据磁盘量和带宽加以限制，具体取决于虚
## 4\.云服务
-云服务是 Azure 服务管理中的基本构建基块，同时用于 PaaS 和 IaaS 服务。对于 PaaS，云服务表示其实例可以相互通信的角色关联。云服务将关联到一个公共虚拟 IP (VIP) 地址和一个负载平衡器，后者将接受来自 Internet 的传入流量，并将该流量负载平衡到配置为接收该流量的角色。
+云服务是 Azure 服务管理中的基本构建基块，同时用于 PaaS 和 IaaS 服务。对于 PaaS，云服务表示其实例可以相互通信的角色关联。云服务将关联到一个公共虚拟 IP (VIP) 地址和一个负载均衡器，后者将接受来自 Internet 的传入流量，并将该流量负载平衡到配置为接收该流量的角色。
-对于 IaaS，云服务提供类似的功能，虽然在大多数情况下，负载平衡器功能用于将流量转发到 Internet 上的特定 TCP 或 UDP 端口，再转发到该云服务中的多个虚拟机。
+对于 IaaS，云服务提供类似的功能，虽然在大多数情况下，负载均衡器功能用于将流量转发到 Internet 上的特定 TCP 或 UDP 端口，再转发到该云服务中的多个虚拟机。
> [AZURE.NOTE]云服务不存在于 Azure 资源管理器中。
diff --git a/articles/virtual-machines-linux-agent-user-guide.md b/articles/virtual-machines-linux-agent-user-guide.md
index 3193cec37..5aa3e0a6c 100644
--- a/articles/virtual-machines-linux-agent-user-guide.md
+++ b/articles/virtual-machines-linux-agent-user-guide.md
@@ -284,7 +284,7 @@ Linux 代理的正常运行依赖一些系统程序包：
类型：布尔值
默认值：y
-如果设置此参数，则 waagent 将响应来自平台的负载平衡器探测（如果有）。
+如果设置此参数，则 waagent 将响应来自平台的负载均衡器探测（如果有）。
**Logs.Verbose：**
diff --git a/articles/virtual-machines-linux-mysql-cluster.md b/articles/virtual-machines-linux-mysql-cluster.md
index 6479a957f..894d3d6e8 100644
--- a/articles/virtual-machines-linux-mysql-cluster.md
+++ b/articles/virtual-machines-linux-mysql-cluster.md
@@ -339,7 +339,7 @@ Pacemaker 使用群集监视资源、定义主节点何时停机，并将这些
- 管理 DRBD 的 linbit DRBD 资源脚本作为 Pacemaker 中的资源在关闭节点时使用 `drbdadm down`，即使该节点只是转为待机状态也是如此。这并不理想，因为当主节点获得写入时，从节点将不会同步 DRBD 资源。如果主节点未优雅地失败，则从节点可以接受较旧的文件系统状态。可通过两种可能方式来解决此问题：
- 在所有群集节点上通过本地（非群集化）监视程序强制执行 `drbdadm up r0`，或者
- 编辑 linbit DRBD 脚本以确保未在 `/usr/lib/ocf/resource.d/linbit/drbd` 中调用 `down`。
-- 负载平衡器至少需要 5 秒钟才能做出响应，因此应用程序应是群集感知的并更容忍超时；其他体系结构也会有帮助，例如应用程序中队列、查询中间件等。
+- 负载均衡器至少需要 5 秒钟才能做出响应，因此应用程序应是群集感知的并更容忍超时；其他体系结构也会有帮助，例如应用程序中队列、查询中间件等。
- 有必要进行 MySQL 优化以确保以合理的速度完成写入，并且尽可能频繁地将缓存刷新到磁盘
- 写入性能将依赖于虚拟交换机中的 VM 互连，因为这是 DRBD 用于复制设备的机制
diff --git a/articles/virtual-machines-linux-nodejs-running-cassandra.md b/articles/virtual-machines-linux-nodejs-running-cassandra.md
index 3ee3e03bf..ea78f9426 100644
--- a/articles/virtual-machines-linux-nodejs-running-cassandra.md
+++ b/articles/virtual-machines-linux-nodejs-running-cassandra.md
@@ -29,7 +29,7 @@ Windows Azure 是一种开放式的云平台，该平台运行 Microsoft 软件
Windows Azure 网络允许部署独立的专用群集，并可对这些群集的访问进行限制，从而实现能够进行细化管理的网络安全性。由于本文是介绍 Cassandra 部署基础知识的，因此我们不会重点讲解一致性级别以及如何针对吞吐量来优化存储设计的问题。下面是有关网络要求的列表，针对的是我们的假设性群集：
- 外部系统无法访问 Cassandra 数据库，不管是从 Azure 内部还是外部
-- Cassandra 群集必须位于负载平衡器之后，以便进行 Thrift 通信
+- Cassandra 群集必须位于负载均衡器之后，以便进行 Thrift 通信
- 可以将 Cassandra 节点部署在每个数据中心的两个组中，以便增强群集可用性
- 锁定该群集，使得只有应用程序服务器场可以直接访问数据库
- 除 SSH 之外，没有其他的公共网络终结点
@@ -49,7 +49,7 @@ Cassandra 可以部署到单个或多个 Azure 区域，具体取决于工作负
请注意，在撰写本文的时候，Azure 并不允许将一组 VM 显式映射到特定的容错域；因此，即使采用图 1 所示的部署模型，也极有可能会将所有虚拟机映射到两个容错域，而不是四个容错域。
-**对 Thrift 通信进行负载平衡：**Web 服务器中的 Thrift 客户端库通过内部负载平衡器连接到群集。在使用云服务托管 Cassandra 群集的情况下，这需要执行相关过程，以便将内部负载平衡器添加到“数据”子网（参见图 1）。定义好内部负载平衡器以后，每个节点都需要添加进行过负载平衡的终结点，并使用以前定义的负载平衡器名称对负载平衡集进行标注。有关详细信息，请参阅 [Azure 内部负载平衡](/documentation/articles/load-balancer-internal-overview)。
+**对 Thrift 通信进行负载平衡：**Web 服务器中的 Thrift 客户端库通过内部负载均衡器连接到群集。在使用云服务托管 Cassandra 群集的情况下，这需要执行相关过程，以便将内部负载均衡器添加到“数据”子网（参见图 1）。定义好内部负载均衡器以后，每个节点都需要添加进行过负载平衡的终结点，并使用以前定义的负载均衡器名称对负载平衡集进行标注。有关详细信息，请参阅 [Azure 内部负载平衡](/documentation/articles/load-balancer-internal-overview)。
**群集种子：**必须选择可用性最高的节点作为种子，因为新节点需要与种子节点进行通信才能发现群集的拓扑。将会从每个可用性集中选择一个节点作为种子节点，以免出现单节点故障。
@@ -150,7 +150,7 @@ Azure 在进行配置时需要用 PEM 或 DER 编码的 X509 公钥。按照如
| 字段名称 | 字段值 | 备注 |
|---|
| 云服务 | 创建新的云服务 | 云服务是类似虚拟机的容器计算资源 |
-| 云服务 DNS 名称 | ubuntu-template.chinacloudapp.cn | 为计算机提供不可知的负载平衡器名称 |
+| 云服务 DNS 名称 | ubuntu-template.chinacloudapp.cn | 为计算机提供不可知的负载均衡器名称 |
| 区域/地缘组/虚拟网络 | 美国西部 | 选择你的网站从中访问 Cassandra 群集的区域 |
| 存储帐户 | 使用默认值 | 使用特定区域的默认存储帐户或预先创建的存储帐户 |
| 可用性集 | 无 | 将此字段留空 |
@@ -341,8 +341,8 @@ Azure 在进行配置时需要用 PEM 或 DER 编码的 X509 公钥。按照如
1. 在特定区域创建空的云服务
2. 从以前捕获的映像创建 VM，然后将其附加到以前创建的虚拟网络；对所有 VM 重复此过程
-3. 将内部负载平衡器添加到云服务，然后将其附加到“数据”子网
-4. 对于以前创建的每个 VM，可以通过一个已连接到以前创建的内部负载平衡器的负载平衡集添加进行 Thrift 通信的负载平衡终结点
+3. 将内部负载均衡器添加到云服务，然后将其附加到“数据”子网
+4. 对于以前创建的每个 VM，可以通过一个已连接到以前创建的内部负载均衡器的负载平衡集添加进行 Thrift 通信的负载平衡终结点
以上过程可以通过 Azure 管理门户来执行；使用 Windows 计算机（如果无法访问 Windows 计算机，则可使用 Azure 上的 VM）；使用以下 PowerShell 脚本自动预配所有 8 个 VM。
@@ -436,7 +436,7 @@ Azure 在进行配置时需要用 PEM 或 DER 编码的 X509 公钥。按照如
## 测试单区域群集
使用以下步骤测试群集：
-1. 使用 Powershell 命令 Get-AzureInternalLoadbalancer cmdlet 获取内部负载平衡器的 IP 地址（例如 10.1.2.101）。该命令的语法如下所示：Get-AzureLoadbalancer –ServiceName "hk-c-svc-west-us” [显示内部负载平衡器及其 IP 地址的详细信息]
+1. 使用 Powershell 命令 Get-AzureInternalLoadbalancer cmdlet 获取内部负载均衡器的 IP 地址（例如 10.1.2.101）。该命令的语法如下所示：Get-AzureLoadbalancer –ServiceName "hk-c-svc-west-us” [显示内部负载均衡器及其 IP 地址的详细信息]
2. 使用 Putty 或 ssh 登录到 Web 场 VM（例如 hk-w1-west-us）
3. 执行 $CASS_HOME/bin/cqlsh 10.1.2.101 9160
4. 使用以下 CQL 命令验证群集是否正常工作：
@@ -555,7 +555,7 @@ $CASS\_HOME/bin/cassandra
## 测试多区域群集
到目前为止，Cassandra 已部署到 16 个节点，每个 Azure 区域 8 个节点。这些节点具有通用的群集名称和种子节点配置，因此属于同一群集。使用以下过程测试群集：
-###步骤 1：使用 PowerShell 获取这两个区域的内部负载平衡器 IP
+###步骤 1：使用 PowerShell 获取这两个区域的内部负载均衡器 IP
- Get-AzureInternalLoadbalancer -ServiceName "hk-c-svc-west-us"
- Get-AzureInternalLoadbalancer -ServiceName "hk-c-svc-east-us"
diff --git a/articles/virtual-machines-load-balance.md b/articles/virtual-machines-load-balance.md
index e1ab64ec0..2480e2907 100644
--- a/articles/virtual-machines-load-balance.md
+++ b/articles/virtual-machines-load-balance.md
@@ -1,6 +1,6 @@
Azure 负载平衡器。有关创建负载平衡集的步骤，请参阅配置负载平衡集。
+有关详细信息，请参阅Azure 负载均衡器。有关创建负载平衡集的步骤，请参阅配置负载平衡集。
Azure 还可以在云服务或虚拟网络内部实现负载平衡。这称为“内部负载平衡”并可以通过以下方式使用：
- 在多层应用程序的不同层（例如，在 Web 层和数据库层之间）的服务器之间实现负载平衡。
-- 使托管在 Azure 中的业务线 \(LOB\) 应用程序实现负载平衡，而无需额外的负载平衡器硬件或软件。
+- 使托管在 Azure 中的业务线 \(LOB\) 应用程序实现负载平衡，而无需额外的负载均衡器硬件或软件。
- 将本地服务器包含在一组流量已实现负载平衡的计算机中。
与 Azure 负载平衡类似，可以通过配置内部负载平衡集来实现内部负载平衡。
@@ -75,6 +75,6 @@ Azure 还可以在云服务或虚拟网络内部实现负载平衡。这称为
有关创建负载平衡集的步骤，请参阅配置内部负载平衡集。
-有关负载平衡器的详细信息，请参阅内部负载平衡。
+有关负载均衡器的详细信息，请参阅内部负载平衡。
diff --git a/articles/virtual-machines-manage-availability.md b/articles/virtual-machines-manage-availability.md
index 78eaa730e..f4827c835 100644
--- a/articles/virtual-machines-manage-availability.md
+++ b/articles/virtual-machines-manage-availability.md
@@ -26,7 +26,7 @@
* [在可用性集中配置多个虚拟机以确保冗余]
* [将每个应用程序层配置到不同的可用性集中]
-* [将负载平衡器与可用性集组合在一起]
+* [将负载均衡器与可用性集组合在一起]
* [避免可用性集中出现单实例虚拟机]
### 在可用性集中配置多个虚拟机以确保冗余
@@ -50,10 +50,10 @@
-### 将负载平衡器与可用性集组合在一起
-将 Azure 负载平衡器与可用性集组合在一起，以获取最大的应用程序复原能力。Azure 负载平衡器将流量分布到多个虚拟机中。对于标准层虚拟机来说，Azure 负载平衡器已包括在内。请注意，并非所有虚拟机层都包括 Azure 负载平衡器。有关对虚拟机进行负载平衡的更多信息，请阅读[对虚拟机进行负载平衡](/documentation/articles/load-balance-virtual-machines)。
+### 将负载均衡器与可用性集组合在一起
+将 Azure 负载均衡器与可用性集组合在一起，以获取最大的应用程序复原能力。Azure 负载均衡器将流量分布到多个虚拟机中。对于标准层虚拟机来说，Azure 负载均衡器已包括在内。请注意，并非所有虚拟机层都包括 Azure 负载均衡器。有关对虚拟机进行负载平衡的更多信息，请阅读[对虚拟机进行负载平衡](/documentation/articles/load-balance-virtual-machines)。
-如果没有将负载平衡器配置为对多个虚拟机上的流量进行平衡，则任何计划内维护事件都会影响唯一的那个处理流量的虚拟机，导致应用程序层中断。将同一层的多个虚拟机置于相同的负载平衡器和可用性集下可以确保至少有一个虚拟机实例能够持续处理流量。
+如果没有将负载均衡器配置为对多个虚拟机上的流量进行平衡，则任何计划内维护事件都会影响唯一的那个处理流量的虚拟机，导致应用程序层中断。将同一层的多个虚拟机置于相同的负载均衡器和可用性集下可以确保至少有一个虚拟机实例能够持续处理流量。
### 避免可用性集中出现单实例虚拟机
避免将单实例虚拟机置于可用性集中。此配置中的虚拟机并不符合 SLA 保证，在出现 Azure 计划内维护事件时就会停机。请注意，如果系统发送多实例虚拟机计划内维护通知，则可用性集中的单个虚拟机实例也会收到提前发出的电子邮件通知。
@@ -61,6 +61,6 @@
[在可用性集中配置多个虚拟机以确保冗余]: #configure-multiple-virtual-machines-in-an-availability-set-for-redundancy
[将每个应用程序层配置到不同的可用性集中]: #configure-each-application-tier-into-separate-availability-sets
-[将负载平衡器与可用性集组合在一起]: #combine-the-load-balancer-with-availability-sets
+[将负载均衡器与可用性集组合在一起]: #combine-the-load-balancer-with-availability-sets
[避免可用性集中出现单实例虚拟机]: #avoid-single-instance-virtual-machines-in-availability-sets
[如何为虚拟机配置可用性集]: /documentation/articles/virtual-machines-how-to-configure-availability
diff --git a/articles/virtual-machines-mariadb-cluster.md b/articles/virtual-machines-mariadb-cluster.md
index 244efd008..53099afd4 100644
--- a/articles/virtual-machines-mariadb-cluster.md
+++ b/articles/virtual-machines-mariadb-cluster.md
@@ -15,7 +15,7 @@
1. 创建包含 3 个节点的群集
2. 将数据磁盘与操作系统磁盘隔离开来
3. 在 RAID-0/条带化设置下创建数据磁盘，以提高 IOPS
-4. 使用 Azure 负载平衡器，以使 3 个节点的负载保持平衡
+4. 使用 Azure 负载均衡器，以使 3 个节点的负载保持平衡
5. 为了最大程度地减少重复工作，可创建一个包含 MariaDB+Galera 的 VM 映像，并将其用于创建其他群集 VM。
@@ -282,7 +282,7 @@
## 对群集进行负载平衡
在创建聚集 VM 时，你将其添加到了名为 **clusteravset** 的可用性集中，以确保其放置在不同的容错和更新域上，且 Azure 不会同时在所有虚拟机上执行维护。此配置符合该 Azure 服务级别协议 (SLA) 将支持的要求。
-现在，使用 Azure 负载平衡器，以平衡 3 个节点之间的请求。
+现在，使用 Azure 负载均衡器，以平衡 3 个节点之间的请求。
在使用 Azure CLI 的机器上运行以下命令。命令参数结构是：`azure vm endpoint create-multiple ::::::`
@@ -290,7 +290,7 @@
azure vm endpoint create-multiple mariadb2 3306:3306:tcp:false:MySQL:tcp:3306
azure vm endpoint create-multiple mariadb3 3306:3306:tcp:false:MySQL:tcp:3306
-最后，由于 CLI 将负载平衡器的探测时间间隔设置为 15 秒（可能有点太长了），可以在门户中的“终结点”下更改任一 VM 的该时间间隔
+最后，由于 CLI 将负载均衡器的探测时间间隔设置为 15 秒（可能有点太长了），可以在门户中的“终结点”下更改任一 VM 的该时间间隔
@@ -304,7 +304,7 @@
## 验证群集
-繁琐的工作已经完成。现在应该可以在 `mariadbha.chinacloudapp.cn:3306` 访问群集，这将触发负载平衡器并在 3 个 VM 之间顺利、高效地路由请求。
+繁琐的工作已经完成。现在应该可以在 `mariadbha.chinacloudapp.cn:3306` 访问群集，这将触发负载均衡器并在 3 个 VM 之间顺利、高效地路由请求。
使用偏好的 MySQL 客户端进行连接，或直接从任一 VM 进行连接，以验证此群集是否正常运行。
@@ -332,7 +332,7 @@
## 后续步骤
-在本文中，你在运行 CentOS 7 的 Azure 虚拟机上创建了包含 3 个节点的 MariaDB + Galera 高度可用群集。VM 已通过 Azure 负载平衡器实现了负载平衡。
+在本文中，你在运行 CentOS 7 的 Azure 虚拟机上创建了包含 3 个节点的 MariaDB + Galera 高度可用群集。VM 已通过 Azure 负载均衡器实现了负载平衡。
你可能希望找到[另一种方式在 Linux 上对 MySQL 进行集群]以及探究如何[优化和测试 Azure Linux VM 上的 MySQL 性能]。
diff --git a/articles/virtual-machines-miscellaneous-considerations-oracle-virtual-machine-images.md b/articles/virtual-machines-miscellaneous-considerations-oracle-virtual-machine-images.md
index 7eaaa504a..9a6563713 100644
--- a/articles/virtual-machines-miscellaneous-considerations-oracle-virtual-machine-images.md
+++ b/articles/virtual-machines-miscellaneous-considerations-oracle-virtual-machine-images.md
@@ -48,7 +48,7 @@ Azure 向每个虚拟机分配一个内部 IP 地址。除非 VM 是虚拟网络
- **连接超时：**如果你的应用程序依赖于与另一个 Azure 云服务（例如，数据库层服务）的公共终结点的连接，那么，在这些已打开的连接处于非活动状态 4 分钟后，Azure 可能会关闭它们。这可能会影响依赖于连接池的功能和应用程序，因为非活动时间超过该限制的连接可能不再有效。如果这会影响你的应用程序，请考虑对连接池启用“保持连接”逻辑。
- 请注意，如果终结点是 Azure 云服务部署的*内部*终结点（比如与 WebLogic 虚拟机位于*同一*云服务中的独立数据库虚拟机），则该连接属于直接连接，不依赖于 Azure 负载平衡器，因此不受连接超时的影响。
+ 请注意，如果终结点是 Azure 云服务部署的*内部*终结点（比如与 WebLogic 虚拟机位于*同一*云服务中的独立数据库虚拟机），则该连接属于直接连接，不依赖于 Azure 负载均衡器，因此不受连接超时的影响。
- **不支持 UDP 多播。** Azure 支持 UDP 单播，但不支持多播和广播。WebLogic Server 可以依赖于 Azure 的 UDP 单播功能。为了在依赖 UDP 单播时获得最好的结果，建议让 WebLogic 群集大小保持静态，或者让群集包含的托管服务器不超过 10 个。
@@ -58,7 +58,7 @@ Azure 向每个虚拟机分配一个内部 IP 地址。除非 VM 是虚拟网络
Bootstrap to: example.chinacloudapp.cn/138.91.142.178:7006' over: 't3' got an error or timed out]
- 这是因为，对于任何远程 T3 访问，WebLogic Server 都要求负载平衡器端口和 WebLogic 托管服务器端口必须相同。在上述情况中，客户端访问的是端口 7006（负载平衡器端口），而托管服务器侦听的是 7008（专用端口）。请注意，此限制仅适用于 T3 访问，而不适用于 HTTP。
+ 这是因为，对于任何远程 T3 访问，WebLogic Server 都要求负载均衡器端口和 WebLogic 托管服务器端口必须相同。在上述情况中，客户端访问的是端口 7006（负载均衡器端口），而托管服务器侦听的是 7008（专用端口）。请注意，此限制仅适用于 T3 访问，而不适用于 HTTP。
若要避免此问题，请使用以下解决方法之一：
@@ -74,7 +74,7 @@ Azure 向每个虚拟机分配一个内部 IP 地址。除非 VM 是虚拟网络
另一方面，如果将管理服务器配置为向其托管服务器自动分配唯一的端口号，则无法实现负载平衡，因为 Azure 不支持从单个公共端口映射到多个专用端口，而这正是此配置所必需的。
-- **单个 VM 上的多个 WebLogic 实例。** 视部署要求而定，你可以考虑在同一个虚拟机上运行多个 WebLogic Server 实例（如果 VM 够大）。例如，在一个包含 2 个核心的中等大小的 VM 上，可以选择运行两个 WebLogic Server 实例。但是请注意，仍建议不要在体系结构中引入单一故障点，也就是只使用一个运行多个 WebLogic Server 实例的 VM。使用至少两个 VM 会更好：每个 VM 可以运行多个 WebLogic Server 实例。每个 WebLogic Server 实例仍然可以属于同一个群集。但是请注意，当前无法使用 Azure 对同一 VM 中的这类 WebLogic Server 部署所暴露的终结点进行负载平衡，因为 Azure 负载平衡器要求在唯一的 VM 之间分布负载平衡服务器。
+- **单个 VM 上的多个 WebLogic 实例。** 视部署要求而定，你可以考虑在同一个虚拟机上运行多个 WebLogic Server 实例（如果 VM 够大）。例如，在一个包含 2 个核心的中等大小的 VM 上，可以选择运行两个 WebLogic Server 实例。但是请注意，仍建议不要在体系结构中引入单一故障点，也就是只使用一个运行多个 WebLogic Server 实例的 VM。使用至少两个 VM 会更好：每个 VM 可以运行多个 WebLogic Server 实例。每个 WebLogic Server 实例仍然可以属于同一个群集。但是请注意，当前无法使用 Azure 对同一 VM 中的这类 WebLogic Server 部署所暴露的终结点进行负载平衡，因为 Azure 负载均衡器要求在唯一的 VM 之间分布负载平衡服务器。
##Oracle JDK 虚拟机映像
diff --git a/articles/virtual-machines-ps-create-preconfigure-linux-vms.md b/articles/virtual-machines-ps-create-preconfigure-linux-vms.md
index c605c7624..91e70f4eb 100644
--- a/articles/virtual-machines-ps-create-preconfigure-linux-vms.md
+++ b/articles/virtual-machines-ps-create-preconfigure-linux-vms.md
@@ -203,7 +203,7 @@
- 使用 SUSE Linux Enterprise Server 12 映像。
- 具有名称 LOB1。
- 具有 50 GB 的附加数据磁盘。
-- 是用于标准 Web 流量的 LOBServers 负载平衡器集的成员。
+- 是用于标准 Web 流量的 LOBServers 负载均衡器集的成员。
- 位于 AZDatacenter 虚拟网络的 FrontEnd 子网中。
- 位于 Azure-TailspinToys 云服务中。
diff --git a/articles/virtual-machines-ps-create-preconfigure-windows-resource-manager-vms.md b/articles/virtual-machines-ps-create-preconfigure-windows-resource-manager-vms.md
index 65244c4bc..ee7a4d6e8 100644
--- a/articles/virtual-machines-ps-create-preconfigure-windows-resource-manager-vms.md
+++ b/articles/virtual-machines-ps-create-preconfigure-windows-resource-manager-vms.md
@@ -128,7 +128,7 @@
### NAT 规则
-使用入站 NAT 规则可以设置基于资源管理器的虚拟机，允许来自 Internet 的传入流量并将其放入负载平衡集。在这两种情况下，都必须指定负载平衡器实例和其他设置。
+使用入站 NAT 规则可以设置基于资源管理器的虚拟机，允许来自 Internet 的传入流量并将其放入负载平衡集。在这两种情况下，都必须指定负载均衡器实例和其他设置。
使用资源管理器部署模型创建的 VM 需要资源管理器虚拟网络。如果需要，请使用新虚拟机的至少一个子网创建基于资源管理器的新虚拟网络。以下示例显示了名为 **TestNet** 的新虚拟网络，其中包含名为 **frontendSubnet** 和 **backendSubnet** 的两个子网。
@@ -204,12 +204,12 @@ frontendSubnet 的子网索引为 0，backendSubnet 的子网索引为 1。
$pip = New-AzureRmPublicIpAddress -Name $nicName -ResourceGroupName $rgName -Location $locName -AllocationMethod Dynamic
$nic = New-AzureRmNetworkInterface -Name $nicName -ResourceGroupName $rgName -Location $locName -SubnetId $vnet.Subnets[$subnetIndex].Id -PublicIpAddressId $pip.Id -PrivateIpAddress $staticIP
-### 选项 4：指定 NIC 名称和入站 NAT 规则的负载平衡器实例。
+### 选项 4：指定 NIC 名称和入站 NAT 规则的负载均衡器实例。
-若要创建 NIC 并将其添加到入站 NAT 规则的负载平衡器实例，你需要：
+若要创建 NIC 并将其添加到入站 NAT 规则的负载均衡器实例，你需要：
-- 前面创建的、针对转发到虚拟机的流量创建了入站 NAT 规则的负载平衡器实例的名称。
-- 要分配给 NIC 的负载平衡器实例的后端地址池的索引编号。
+- 前面创建的、针对转发到虚拟机的流量创建了入站 NAT 规则的负载均衡器实例的名称。
+- 要分配给 NIC 的负载均衡器实例的后端地址池的索引编号。
- 要分配给 NIC 的入站 NAT 规则的索引编号。
将以下几行复制到命令集，并指定所需的名称和索引编号。
@@ -223,14 +223,14 @@ frontendSubnet 的子网索引为 0，backendSubnet 的子网索引为 1。
$nicName 字符串必须是资源组中唯一的字符串。最佳实践是将虚拟机名称合并在字符串中，例如“LOB07-NIC”。
-### 选项 5：为负载平衡集指定 NIC 名称和负载平衡器实例。
+### 选项 5：为负载平衡集指定 NIC 名称和负载均衡器实例。
-若要创建 NIC 并将其添加到负载平衡集的负载平衡器实例，你需要：
+若要创建 NIC 并将其添加到负载平衡集的负载均衡器实例，你需要：
-- 前面创建的、针对负载平衡流量创建了规则的负载平衡器实例的名称。
-- 要分配给 NIC 的负载平衡器实例的后端地址池的索引编号。
+- 前面创建的、针对负载平衡流量创建了规则的负载均衡器实例的名称。
+- 要分配给 NIC 的负载均衡器实例的后端地址池的索引编号。
-有关如何创建具有针对负载平衡流量的规则的负载平衡器实例的信息，请参阅[使用 Azure 资源管理器创建负载平衡器](/documentation/articles/load-balancer-arm-powershell)。
+有关如何创建具有针对负载平衡流量的规则的负载均衡器实例的信息，请参阅[使用 Azure 资源管理器创建负载均衡器](/documentation/articles/load-balancer-arm-powershell)。
将以下几行复制到命令集，并指定所需的名称和索引编号。
diff --git a/articles/virtual-machines-rmtemplate-sharepoint-walkthrough.md b/articles/virtual-machines-rmtemplate-sharepoint-walkthrough.md
index 91b6e1bbe..1d7537a49 100644
--- a/articles/virtual-machines-rmtemplate-sharepoint-walkthrough.md
+++ b/articles/virtual-machines-rmtemplate-sharepoint-walkthrough.md
@@ -134,7 +134,7 @@
### Microsoft.Network/loadBalancers
-这些节为每个虚拟机创建负载平衡器实例，以便为来自 Internet 的入站流量提供网络地址转换 (NAT) 和流量筛选。对于每个负载平衡器，设置将配置前端、后端和入站 NAT 规则。例如，每个虚拟机都有远程桌面通信规则，而 SharePoint Server 则有允许接收来自 Internet 的入站 Web 流量（TCP 端口 80）的规则。下面是 SharePoint Server 的示例：
+这些节为每个虚拟机创建负载均衡器实例，以便为来自 Internet 的入站流量提供网络地址转换 (NAT) 和流量筛选。对于每个负载均衡器，设置将配置前端、后端和入站 NAT 规则。例如，每个虚拟机都有远程桌面通信规则，而 SharePoint Server 则有允许接收来自 Internet 的入站 Web 流量（TCP 端口 80）的规则。下面是 SharePoint Server 的示例：
{
@@ -236,7 +236,7 @@
第一个节创建并配置域控制器，它：
-- 指定存储帐户、可用性集、网络接口和负载平衡器实例。
+- 指定存储帐户、可用性集、网络接口和负载均衡器实例。
- 添加额外的磁盘。
- 运行 PowerShell 脚本，以配置域控制器。
@@ -339,24 +339,24 @@
下一个 **"type":"Microsoft.Compute/virtualMachines"** 节在部署中创建 SQL Server 虚拟机并：
-- 指定存储帐户、可用性集、负载平衡器、虚拟网络和网络接口。
+- 指定存储帐户、可用性集、负载均衡器、虚拟网络和网络接口。
- 添加额外的磁盘。
其他**“Microsoft.Compute/virtualMachines/extensions”**节调用 PowerShell 脚本以配置 SQL Server。
-下一个 **"type":"Microsoft.Compute/virtualMachines"** 节在部署中创建 SharePoint 虚拟机，并指定存储帐户、可用性集、负载平衡器、虚拟网络和网络接口。其他**“Microsoft.Compute/virtualMachines/extensions”**节调用 PowerShell 脚本以配置 SharePoint 场。
+下一个 **"type":"Microsoft.Compute/virtualMachines"** 节在部署中创建 SharePoint 虚拟机，并指定存储帐户、可用性集、负载均衡器、虚拟网络和网络接口。其他**“Microsoft.Compute/virtualMachines/extensions”**节调用 PowerShell 脚本以配置 SharePoint 场。
请注意 JSON 文件的**“resources”**节的子节的整体结构：
-1. 创建支持多个虚拟机所需的 Azure 基础结构元素（存储帐户、公共 IP 地址、可用性集、虚拟网络、网络接口和负载平衡器实例）。
+1. 创建支持多个虚拟机所需的 Azure 基础结构元素（存储帐户、公共 IP 地址、可用性集、虚拟网络、网络接口和负载均衡器实例）。
2. 创建域控制器虚拟机，后者使用先前创建的 Azure 基础结构的公用和特定元素、添加数据磁盘，并运行 PowerShell 脚本。此外，还更新虚拟网络以使用域控制器的静态 IP 地址。
3. 创建 SQL Server 虚拟机，后者使用先前为域控制器创建的 Azure 基础结构的公用和特定元素、添加数据磁盘，并运行 PowerShell 脚本以配置 SQL Server。
4. 创建 SharePoint Server 虚拟机，后者使用先前创建的 Azure 基础结构的公用和特定元素并运行 PowerShell 脚本以配置 SharePoint 场。
你自己的用于在 Azure 中构建多层基础结构的 JSON 模板应遵循相同的步骤：
-1. 创建部署所需的 Azure 基础结构的公用元素（存储帐户、虚拟网络）、特定于层的元素（可用性集）和特定于虚拟机的元素（公共 IP 地址、可用性集、网络接口、负载平衡器实例）。
-2. 对于应用程序中的每个层（例如，身份验证、数据库、Web），使用公用元素（存储帐户、虚拟网络）、特定于层的元素（可用性集）和特定于虚拟机的元素（公共 IP 地址、网络接口、负载平衡器实例）在该层中创建并配置服务器。
+1. 创建部署所需的 Azure 基础结构的公用元素（存储帐户、虚拟网络）、特定于层的元素（可用性集）和特定于虚拟机的元素（公共 IP 地址、可用性集、网络接口、负载均衡器实例）。
+2. 对于应用程序中的每个层（例如，身份验证、数据库、Web），使用公用元素（存储帐户、虚拟网络）、特定于层的元素（可用性集）和特定于虚拟机的元素（公共 IP 地址、网络接口、负载均衡器实例）在该层中创建并配置服务器。
有关详细信息，请参阅 [Azure 资源管理器模板语言](https://msdn.microsoft.com/zh-CN/library/azure/dn835138.aspx)。
diff --git a/articles/virtual-machines-set-up-endpoints.md b/articles/virtual-machines-set-up-endpoints.md
index f0576a1fc..fe9c79812 100644
--- a/articles/virtual-machines-set-up-endpoints.md
+++ b/articles/virtual-machines-set-up-endpoints.md
@@ -27,7 +27,7 @@
每个终结点都有一个公用端口和一个专用端口：
-- Azure 负载平衡器使用公用端口侦听从 Internet 传入的虚拟机流量。
+- Azure 负载均衡器使用公用端口侦听从 Internet 传入的虚拟机流量。
- 虚拟机使用专用端口侦听通常发送到虚拟机上运行的应用程序或服务的传入流量。
使用门户创建终结点时，将为 IP 协议和众所周知的网络协议的 TCP 或 UDP 端口提供默认值。对于自定义终结点，必须指定正确的 IP 协议（TCP 或 UDP）以及公用和专用端口。若要将传入流量随机分布到多个虚拟机上，必须创建包含多个终结点的负载平衡集。
@@ -53,7 +53,7 @@
6. 在“指定终结点详细信息”页上的“名称”中，键入终结点的名称。此外，还可以从列表中选择网络协议名称，这将填充“协议”、“公用端口”和“专用端口”的初始值。
7. 对于自定义终结点，请在“协议”中，选择 **TCP** 或 **UDP**。
8. 对于自定义端口，请在“公用端口”中，键入从 Internet 传入流量的端口号。在“专用端口”中，键入虚拟机正在侦听的端口号。这些端口号可以是不同的。请确保已将虚拟机上的防火墙配置为允许与协议（在步骤 7 中）和专用端口对应的流量。
-9. 如果此终结点是负载平衡集中的第一个终结点，请单击“创建负载平衡集”，然后单击右箭头。在“配置负载平衡集”页上，指定负载平衡集名称、探测协议和端口，以及探测间隔和发送的探测数。Azure 负载平衡器会将探测发送到负载平衡集中的虚拟机以监视其可用性。Azure 负载平衡器不会将流量转发到未响应探测的虚拟机。单击右箭头。
+9. 如果此终结点是负载平衡集中的第一个终结点，请单击“创建负载平衡集”，然后单击右箭头。在“配置负载平衡集”页上，指定负载平衡集名称、探测协议和端口，以及探测间隔和发送的探测数。Azure 负载均衡器会将探测发送到负载平衡集中的虚拟机以监视其可用性。Azure 负载均衡器不会将流量转发到未响应探测的虚拟机。单击右箭头。
10. 单击复选标记以创建终结点。
新的终结点将在“终结点”页上列出。
@@ -80,7 +80,7 @@
-6. 使用列表中的行为 ACL 添加、删除或编辑规则，并更改其顺序。**远程子网**值是从 Internet 传入流量的 IP 地址范围，Azure 负载平衡器将使用该值根据流量的源 IP 地址允许或拒绝传入流量。请务必以 CIDR 格式（也称为地址前缀格式）指定 IP 地址范围。例如 131.107.0.0/16。
+6. 使用列表中的行为 ACL 添加、删除或编辑规则，并更改其顺序。**远程子网**值是从 Internet 传入流量的 IP 地址范围，Azure 负载均衡器将使用该值根据流量的源 IP 地址允许或拒绝传入流量。请务必以 CIDR 格式（也称为地址前缀格式）指定 IP 地址范围。例如 131.107.0.0/16。
你可以使用规则只允许来自与 Internet 上你的计算机对应的特定计算机的流量或拒绝来自特定的已知地址范围的流量。
diff --git a/articles/virtual-machines-sql-server-application-patterns-and-development-strategies.md b/articles/virtual-machines-sql-server-application-patterns-and-development-strategies.md
index 21ae8177d..520eff50c 100644
--- a/articles/virtual-machines-sql-server-application-patterns-and-development-strategies.md
+++ b/articles/virtual-machines-sql-server-application-patterns-and-development-strategies.md
@@ -119,7 +119,7 @@
- 你希望拥有可以根据需要向上缩放和向下缩放的基础结构环境。
-下图演示由于传入客户端请求数量增加，你如何才能通过将呈现层向外缩放，将应用程序层放置在 Azure 中的多个虚拟机中。正如图中所示，Azure 负载平衡器负责将流量分布到多个虚拟机，并确定要连接到哪个 Web 服务器。负载平衡器之后有多个 Web 服务器实例，可以确保呈现层的高可用性。
+下图演示由于传入客户端请求数量增加，你如何才能通过将呈现层向外缩放，将应用程序层放置在 Azure 中的多个虚拟机中。正如图中所示，Azure 负载均衡器负责将流量分布到多个虚拟机，并确定要连接到哪个 Web 服务器。负载均衡器之后有多个 Web 服务器实例，可以确保呈现层的高可用性。
@@ -127,11 +127,11 @@
建议你将属于同一层的虚拟机放置在同一云服务和同一可用性集中。例如，将一组 Web 服务器放置在 **CloudService1** 和 **AvailabilitySet1** 中，而将一组数据库服务器放置在 **CloudService2** 和 **AvailabilitySet2** 中。利用 Azure 中的可用性集，你可将高可用性节点放置在单独的容错域和升级域中。
-若要充分利用一层的多个 VM 实例，必须配置应用程序层之间的 Azure 负载平衡器。若要配置每个层中的负载平衡器，请在每个层的 VM 上单独创建负载平衡终结点。对于特定层，请首先在同一云服务中创建 VM。这样可以确保它们都具有同一公共虚拟 IP 地址。接下来，在该层的一个虚拟机上创建终结点。然后，将同一终结点分配给该层上的其他虚拟机，以便进行负载平衡。通过创建负载平衡集，你可将流量分布到多个虚拟机，并让负载平衡器能够在后端 VM 节点出现故障时确定连接哪一个节点。例如，负载平衡器之后有多个 Web 服务器实例，可以确保呈现层的高可用性。
+若要充分利用一层的多个 VM 实例，必须配置应用程序层之间的 Azure 负载均衡器。若要配置每个层中的负载均衡器，请在每个层的 VM 上单独创建负载平衡终结点。对于特定层，请首先在同一云服务中创建 VM。这样可以确保它们都具有同一公共虚拟 IP 地址。接下来，在该层的一个虚拟机上创建终结点。然后，将同一终结点分配给该层上的其他虚拟机，以便进行负载平衡。通过创建负载平衡集，你可将流量分布到多个虚拟机，并让负载均衡器能够在后端 VM 节点出现故障时确定连接哪一个节点。例如，负载均衡器之后有多个 Web 服务器实例，可以确保呈现层的高可用性。
-最佳做法是始终确保所有 Internet 连接首先进入呈现层。呈现层访问业务层，业务层再访问数据层。例如，在呈现层上创建一个终结点。每个终结点具有一个公共端口和一个专用端口。专用端口由虚拟机在内部用于侦听终结点上的流量。公共端口是 Azure 外部通信的入口点，由 Azure 负载平衡器使用。建议设置网络访问控制列表 (ACL) 以定义相应规则，帮助隔离和控制任何应用程序层上任何公共终结点的任何公共端口的传入流量。有关详细信息，请参阅[管理终结点上的 ACL](/documentation/articles/virtual-machines-set-up-endpoints#manage-the-acl-on-an-endpoint)。
+最佳做法是始终确保所有 Internet 连接首先进入呈现层。呈现层访问业务层，业务层再访问数据层。例如，在呈现层上创建一个终结点。每个终结点具有一个公共端口和一个专用端口。专用端口由虚拟机在内部用于侦听终结点上的流量。公共端口是 Azure 外部通信的入口点，由 Azure 负载均衡器使用。建议设置网络访问控制列表 (ACL) 以定义相应规则，帮助隔离和控制任何应用程序层上任何公共终结点的任何公共端口的传入流量。有关详细信息，请参阅[管理终结点上的 ACL](/documentation/articles/virtual-machines-set-up-endpoints#manage-the-acl-on-an-endpoint)。
-请注意，Azure 中的负载平衡器的工作方式类似于本地环境中的负载平衡器。有关更多信息，请参阅 [Azure 基础结构服务的负载平衡](/documentation/articles/virtual-machines-load-balance)。
+请注意，Azure 中的负载均衡器的工作方式类似于本地环境中的负载均衡器。有关更多信息，请参阅 [Azure 基础结构服务的负载平衡](/documentation/articles/virtual-machines-load-balance)。
此外，我们建议你使用 Azure 虚拟网络为虚拟机设置专用网络。这让虚拟机能够通过专用 IP 地址相互通信。有关详细信息，请参阅 [Azure 虚拟网络](/documentation/articles/virtual-networks-overview)。
@@ -153,7 +153,7 @@
- 你希望拥有可以根据需要向上缩放和向下缩放的基础结构环境。
-下图演示本地方案及其云解决方案。在此方案中，你将应用程序层放置在 Azure 的多个虚拟机中，方法是将包含业务逻辑层和数据访问组件的业务层向外缩放。正如图中所示，Azure 负载平衡器负责将流量分布到多个虚拟机，并确定要连接到哪个 Web 服务器。负载平衡器之后有多个应用程序服务器实例，可以确保业务层的高可用性。有关详细信息，请参阅[在一层中包含多个虚拟机的 2 层、3 层或 n 层应用程序模式的最佳实践](#best-practices-for-2-tier-3-tier-or-n-tier-patterns-that-have-multiple-vms-in-one-tier)。
+下图演示本地方案及其云解决方案。在此方案中，你将应用程序层放置在 Azure 的多个虚拟机中，方法是将包含业务逻辑层和数据访问组件的业务层向外缩放。正如图中所示，Azure 负载均衡器负责将流量分布到多个虚拟机，并确定要连接到哪个 Web 服务器。负载均衡器之后有多个应用程序服务器实例，可以确保业务层的高可用性。有关详细信息，请参阅[在一层中包含多个虚拟机的 2 层、3 层或 n 层应用程序模式的最佳实践](#best-practices-for-2-tier-3-tier-or-n-tier-patterns-that-have-multiple-vms-in-one-tier)。
@@ -175,7 +175,7 @@
下图演示本地方案及其云解决方案。在此方案中，你将 Azure 的多个虚拟机中的呈现层和业务层组件向外缩放。此外，你还要为 Azure 中的 SQL Server 数据库实现高可用性和灾难恢复 (HADR) 技术。
-在不同 VM 上运行一个应用程序的多个副本，确保你在这些虚拟机上实现请求的负载平衡。使用多个虚拟机时，需要确保所有 VM 都是可访问的，并且同一时间点都在运行。如果你配置了负载平衡，Azure 负载平衡器会跟踪 VM 的运行状况，并将传入调用正确定向到正常运行的 VM 节点。有关如何设置虚拟机负载平衡的信息，请参阅 [Azure 基础结构服务的负载平衡](/documentation/articles/virtual-machines-load-balance)。负载平衡器之后有多个 Web 服务器和应用程序服务器实例，可以确保呈现层和业务层的高可用性。
+在不同 VM 上运行一个应用程序的多个副本，确保你在这些虚拟机上实现请求的负载平衡。使用多个虚拟机时，需要确保所有 VM 都是可访问的，并且同一时间点都在运行。如果你配置了负载平衡，Azure 负载均衡器会跟踪 VM 的运行状况，并将传入调用正确定向到正常运行的 VM 节点。有关如何设置虚拟机负载平衡的信息，请参阅 [Azure 基础结构服务的负载平衡](/documentation/articles/virtual-machines-load-balance)。负载均衡器之后有多个 Web 服务器和应用程序服务器实例，可以确保呈现层和业务层的高可用性。
@@ -209,7 +209,7 @@
下图演示本地方案及其云解决方案。在此方案中，你将呈现层放置在 Web 角色中，将业务层放置在辅助角色中，而将数据层放置在 Azure 的虚拟机中。在不同 Web 角色中运行呈现层的多个副本，可以确保实现其请求的负载平衡。当你将 Azure 云服务和 Azure 虚拟机结合使用时，我们建议你还设置 [Azure 虚拟网络](/documentation/articles/virtual-networks-overview)。使用 [Azure 虚拟网络](/documentation/articles/virtual-networks-overview)，你可以在云中的同一云服务内拥有稳定持久的专用 IP 地址。在你为虚拟机和云服务定义虚拟网络后，它们就可以通过专用 IP 地址开始相互通信。此外，使虚拟机与 Azure Web/辅助角色处于同一 [Azure 虚拟网络](/documentation/articles/virtual-networks-overview)中可缩短连接延迟并使连接更安全。有关详细信息，请参阅[什么是云服务](/documentation/articles/fundamentals-application-models)。
-正如图中所示，Azure 负载平衡器将流量分布到多个虚拟机，并确定要连接到哪个 Web 服务器或应用程序服务器。负载平衡器之后有多个 Web 服务器和应用程序服务器实例，可以确保呈现层和业务层的高可用性。有关详细信息，请参阅[需要 SQL HADR 的应用程序模式的最佳实践](#best-practices-for-application-patterns-requiring-sql-hadr)。
+正如图中所示，Azure 负载均衡器将流量分布到多个虚拟机，并确定要连接到哪个 Web 服务器或应用程序服务器。负载均衡器之后有多个 Web 服务器和应用程序服务器实例，可以确保呈现层和业务层的高可用性。有关详细信息，请参阅[需要 SQL HADR 的应用程序模式的最佳实践](#best-practices-for-application-patterns-requiring-sql-hadr)。
@@ -310,7 +310,7 @@
|**管理和设置**|你负责针对应用程序、数据、防火墙规则、虚拟网络和操作系统的管理任务。|你负责针对应用程序、数据、防火墙规则和虚拟网络的管理任务。|你只负责针对应用程序和数据的管理任务。|
|**高可用性和灾难恢复 (HADR)**|我们建议你将虚拟机放置在同一可用性集和同一云服务中。将你的 VM 保留在同一可用性集中，可以让 Azure 将高可用性节点放置在单独的容错域和升级域中。同样，将你的 VM 保留在同一云服务中可以实现负载平衡，VM 能够通过 Azure 数据中心内的本地网络直接相互通信。
你负责为 Azure 虚拟机中的 SQL Server 实现高可用性和灾难恢复解决方案，以避免任何停机。有关受支持的 HADR 技术，请参阅 [Azure 虚拟机中 SQL Server 的高可用性和灾难恢复](/documentation/articles/virtual-machines-sql-server-high-availability-and-disaster-recovery-solutions)。
你负责备份自己的数据和应用程序。
如果由于硬件问题，数据中心的主机发生故障，Azure 可以移动你的虚拟机。此外，在出于安全目的对主机进行更新或进行一般的软件更新时，你的 VM 可能会有计划地进行停机。因此，我们建议你在每个应用程序层保持至少两个 VM，以确保持续可用性。Azure 不提供针对单个虚拟机的 SLA。有关详细信息，请参阅 [Azure 业务连续性技术指南](https://msdn.microsoft.com/zh-cn/library/azure/hh873027.aspx)。|Azure 管理由底层硬件或操作系统软件导致的故障。我们建议你实现 Web 角色或辅助角色的多个实例，以确保应用程序的高可用性。有关信息，请参阅[云服务、虚拟机和虚拟网络服务级别协议](http://www.microsoft.com/download/details.aspx?id=38427)和 [Azure 应用程序的灾难恢复和高可用性](https://msdn.microsoft.com/zh-cn/library/azure/dn251004.aspx)
你负责备份自己的数据和应用程序。
对于 Azure VM 的 SQL Server 数据库中驻留的数据库，你负责实现高可用性和灾难恢复解决方案，以避免任何停机。有关受支持的 HDAR 技术，请参阅“Azure 虚拟机中 SQL Server 的高可用性和灾难恢复”。
SQL Server 数据库镜像：在与 Azure 云服务（Web/辅助角色）配合使用时受支持。SQL Server VM 和云服务项目可以位于同一 Azure 虚拟网络中。如果 SQL Server VM 不在同一虚拟网络中，你需要创建一个 SQL Server 别名以将通信路由到 SQL Server 实例。此外，该别名必须与 SQL Server 名称匹配。|高可用性是从 Azure 辅助角色、Azure Blob 存储和 Azure SQL 数据库继承的。例如，Azure 存储空间保存所有 Blob、表和队列数据的 3 个副本。在任何时候，Azure SQL 数据库都始终会运行数据的三个副本 — 一个主副本和两个辅助副本。有关详细信息，请参阅 [Azure 存储空间](/documentation/services/storage)和 [SQL 数据库](/documentation/articles/sql-database-technical-overview)。
请记住，使用 Azure VM 中的 SQL Server 作为 Azure 网站的数据源时，Azure 网站不支持 Azure 虚拟网络。换言之，Azure 中所有从 Azure 网站到 SQL Server VM 的连接都必须经过虚拟机的公共终结点。这可能会导致一些对高可用性和灾难恢复方案的限制。例如，如果 Azure 网站连接到带有数据库镜像功能的 SQL Server VM，那么这些客户端应用程序将无法连接到新的主服务器，因为数据库镜像需要你设置 Azure 中 SQL Server 宿主 VM 之间的 Azure 虚拟网络。因此，当前不支持将 **SQL Server 数据库镜像**用于 Azure 网站。
SQL Server AlwaysOn 可用性组：在 Azure 中将 Azure 网站与 SQL Server VM 配合使用时，可以设置 AlwaysOn 可用性组。但你需要配置 AlwaysOn 可用性组侦听器以通过公共的负载平衡式终结点将通信路由到主副本。|
|**跨界连接**|你可以使用 Azure 虚拟网络来连接到本地。|你可以使用 Azure 虚拟网络来连接到本地。|不支持 Azure 虚拟网络。有关详细信息，请参阅 [网站虚拟网络集成](http://azure.microsoft.com/blog/2014/09/15/azure-websites-virtual-network-integration/)。|
-|**可缩放性**|可以通过增加虚拟机大小或添加更多磁盘的方式向上缩放。有关虚拟机大小的详细信息，请参阅 [Azure 的虚拟机和云服务大小](/documentation/articles/virtual-machines-size-specs)。
对于数据库服务器：可通过数据库分区技术或 SQL Server AlwaysOn 可用性组向外缩放。
对于很高的读取工作负荷，你可在多个辅助节点上使用 [AlwaysOn 可用性组](https://msdn.microsoft.com/zh-cn/library/hh510230.aspx)，还可使用 SQL Server 复制。
对于很高的写入工作负荷，你可在多个物理服务器上实施水平分区数据，以便进行应用程序向外缩放。
此外，你还可以使用[具有数据相关的路由的 SQL Server](https://technet.microsoft.com/zh-cn/library/cc966448.aspx) 实现向外缩放。使用数据相关的路由 (DDR) 时，需要在客户端应用程序中实施分区机制（通常是在业务层中），将数据库请求路由到多个 SQL Server 节点。业务层包含有关如何对数据进行分区和哪些节点包含数据的映射。
你可以缩放运行虚拟机的应用程序。有关更多信息，请参阅[如何缩放应用程序](/documentation/articles/cloud-services-how-to-scale)。
重要说明：Azure 中的**自动缩放**功能可让你自动增加或减少应用程序使用的虚拟机。此功能可以保证在高峰期间不会对最终用户体验产生负面影响，并且在需求较低时可以关闭 VM。如果你的云服务包括 SQL Server VM，建议你不要为其设置“自动缩放”选项。原因是自动缩放功能允许 Azure 在该 VM 中的 CPU 使用率高于某个阈值时打开一个虚拟机，并且在 CPU 使用率低于该阈值时关闭一个虚拟机。自动缩放功能对于无状态应用程序（例如 Web 服务器）非常有用，在这种应用程序中，VM 可以在不参考以前状态的情况下管理工作负荷。不过，自动缩放功能对于有状态应用程序（例如 SQL Server）没有用处，在这种应用程序中，只有一个实例允许写入到数据库。|可以使用多个 Web 角色和辅助角色向上缩放。有关 Web 角色和辅助角色的虚拟机大小的详细信息，请参阅[配置云服务大小](/documentation/articles/cloud-services-sizes-specs)。
使用**云服务**时，你可以定义多个角色，以便分配处理并实现应用程序的弹性缩放。每个云服务包括一个或多个 Web 角色和/或辅助角色，每个角色具有自身的应用程序文件和配置。你可以通过增加为角色部署的角色实例（虚拟机）的数量，使云服务向上缩放，或者通过减少角色实例的数量，使云服务向下缩放。有关详细信息，请参阅 [Azure 执行模型](/documentation/articles/fundamentals-application-models)。
可利用[云服务、虚拟机以及虚拟网络服务级别协议](http://www.microsoft.com/download/details.aspx?id=38427)和负载平衡器，通过内置的 Azure 高可用性支持向外缩放。
对于多层应用程序，我们建议你通过 Azure 虚拟网络，将 Web 角色/辅助角色应用程序连接到数据库服务器 VM。此外，Azure 为同一云服务中的 VM 提供负载平衡，将用户请求分散到这些 VM。以这种方式连接的虚拟机可以通过 Azure 数据中心内的本地网络直接相互通信。
你可在管理门户上设置“自动缩放”，还可设置计划时间。有关更多信息，请参阅[如何缩放应用程序](/documentation/articles/cloud-services-how-to-scale)。|**向上缩放和向下缩放**：你可以增大/减少为网站保留的实例 (VM) 的大小。
向外缩放：你可为网站添加更多保留实例 (VM)。
你可在管理门户上设置“自动缩放”，还可设置计划时间。有关详细信息，请参阅[如何缩放网站](/documentation/articles/web-sites-scale)。|
+|**可缩放性**|可以通过增加虚拟机大小或添加更多磁盘的方式向上缩放。有关虚拟机大小的详细信息，请参阅 [Azure 的虚拟机和云服务大小](/documentation/articles/virtual-machines-size-specs)。
对于数据库服务器：可通过数据库分区技术或 SQL Server AlwaysOn 可用性组向外缩放。
对于很高的读取工作负荷，你可在多个辅助节点上使用 [AlwaysOn 可用性组](https://msdn.microsoft.com/zh-cn/library/hh510230.aspx)，还可使用 SQL Server 复制。
对于很高的写入工作负荷，你可在多个物理服务器上实施水平分区数据，以便进行应用程序向外缩放。
此外，你还可以使用[具有数据相关的路由的 SQL Server](https://technet.microsoft.com/zh-cn/library/cc966448.aspx) 实现向外缩放。使用数据相关的路由 (DDR) 时，需要在客户端应用程序中实施分区机制（通常是在业务层中），将数据库请求路由到多个 SQL Server 节点。业务层包含有关如何对数据进行分区和哪些节点包含数据的映射。
你可以缩放运行虚拟机的应用程序。有关更多信息，请参阅[如何缩放应用程序](/documentation/articles/cloud-services-how-to-scale)。
重要说明：Azure 中的**自动缩放**功能可让你自动增加或减少应用程序使用的虚拟机。此功能可以保证在高峰期间不会对最终用户体验产生负面影响，并且在需求较低时可以关闭 VM。如果你的云服务包括 SQL Server VM，建议你不要为其设置“自动缩放”选项。原因是自动缩放功能允许 Azure 在该 VM 中的 CPU 使用率高于某个阈值时打开一个虚拟机，并且在 CPU 使用率低于该阈值时关闭一个虚拟机。自动缩放功能对于无状态应用程序（例如 Web 服务器）非常有用，在这种应用程序中，VM 可以在不参考以前状态的情况下管理工作负荷。不过，自动缩放功能对于有状态应用程序（例如 SQL Server）没有用处，在这种应用程序中，只有一个实例允许写入到数据库。|可以使用多个 Web 角色和辅助角色向上缩放。有关 Web 角色和辅助角色的虚拟机大小的详细信息，请参阅[配置云服务大小](/documentation/articles/cloud-services-sizes-specs)。
使用**云服务**时，你可以定义多个角色，以便分配处理并实现应用程序的弹性缩放。每个云服务包括一个或多个 Web 角色和/或辅助角色，每个角色具有自身的应用程序文件和配置。你可以通过增加为角色部署的角色实例（虚拟机）的数量，使云服务向上缩放，或者通过减少角色实例的数量，使云服务向下缩放。有关详细信息，请参阅 [Azure 执行模型](/documentation/articles/fundamentals-application-models)。
可利用[云服务、虚拟机以及虚拟网络服务级别协议](http://www.microsoft.com/download/details.aspx?id=38427)和负载均衡器，通过内置的 Azure 高可用性支持向外缩放。
对于多层应用程序，我们建议你通过 Azure 虚拟网络，将 Web 角色/辅助角色应用程序连接到数据库服务器 VM。此外，Azure 为同一云服务中的 VM 提供负载平衡，将用户请求分散到这些 VM。以这种方式连接的虚拟机可以通过 Azure 数据中心内的本地网络直接相互通信。
你可在管理门户上设置“自动缩放”，还可设置计划时间。有关更多信息，请参阅[如何缩放应用程序](/documentation/articles/cloud-services-how-to-scale)。|**向上缩放和向下缩放**：你可以增大/减少为网站保留的实例 (VM) 的大小。
向外缩放：你可为网站添加更多保留实例 (VM)。
你可在管理门户上设置“自动缩放”，还可设置计划时间。有关详细信息，请参阅[如何缩放网站](/documentation/articles/web-sites-scale)。|
有关如何在这些编辑方法之间进行选择的详细信息，请参阅 [Azure 网站、云服务和 VM：何时使用何种产品？](/documentation/articles/choose-web-site-cloud-service-vm)。
diff --git a/articles/virtual-machines-sql-server-configure-ilb-alwayson-availability-group-listener.md b/articles/virtual-machines-sql-server-configure-ilb-alwayson-availability-group-listener.md
index 678004c62..e4155cd4a 100644
--- a/articles/virtual-machines-sql-server-configure-ilb-alwayson-availability-group-listener.md
+++ b/articles/virtual-machines-sql-server-configure-ilb-alwayson-availability-group-listener.md
@@ -1,6 +1,6 @@
此外，如果可用性组跨 Azure 区域，则你必须在每个数据中心内对云服务和节点运行该脚本一次。
+12. 将以下 PowerShell 脚本复制到文本编辑器中，并根据你的环境设置变量值（注意，这里为某些参数提供了默认值）。请注意，使用地缘组的现有部署不能添加 ILB。此外，如果可用性组跨 Azure 区域，则你必须在每个数据中心内对云服务和节点运行该脚本一次。
# Define variables
$ServiceName = "" # the name of the cloud service that contains the availability group nodes
@@ -78,7 +78,7 @@
13. 设置变量后，将脚本从文本编辑器复制到 Azure PowerShell 会话中运行。如果提示符仍然显示 >>，请再次按 Enter，以确保脚本开始运行。注意：
->[AZURE.NOTE]Azure 管理门户目前不支持内部负载平衡器，因此你在门户中看不到 ILB 或终结点。但是，如果负载平衡器在某个内部 IP 地址上运行，则 **Get-AzureEndpoint** 将返回该地址。否则，将返回 null。
+>[AZURE.NOTE]Azure 管理门户目前不支持内部负载均衡器，因此你在门户中看不到 ILB 或终结点。但是，如果负载均衡器在某个内部 IP 地址上运行，则 **Get-AzureEndpoint** 将返回该地址。否则，将返回 null。
## 如果需要，请验证是否已安装 KB2854082
@@ -92,7 +92,7 @@
[AZURE.INCLUDE [防火墙](../includes/virtual-machines-ag-listener-create-listener.md)]
-10. 对于 ILB，必须使用前面创建的内部负载平衡器 (ILB) 的 IP 地址。在 PowerShell 中使用以下脚本获取此 IP 地址。
+10. 对于 ILB，必须使用前面创建的内部负载均衡器 (ILB) 的 IP 地址。在 PowerShell 中使用以下脚本获取此 IP 地址。
# Define variables
$ServiceName="" # the name of the cloud service that contains the AG nodes
diff --git a/articles/virtual-machines-sql-server-configure-public-alwayson-availability-group-listener.md b/articles/virtual-machines-sql-server-configure-public-alwayson-availability-group-listener.md
index f58f0422b..ba50d5005 100644
--- a/articles/virtual-machines-sql-server-configure-public-alwayson-availability-group-listener.md
+++ b/articles/virtual-machines-sql-server-configure-public-alwayson-availability-group-listener.md
@@ -42,7 +42,7 @@
## 创建支持直接服务器返回的负载平衡 VM 终结点
-外部负载平衡使用托管 VM 的云服务的公共虚拟 IP 地址。因此，在这种情况下，你不需要创建或配置负载平衡器。
+外部负载平衡使用托管 VM 的云服务的公共虚拟 IP 地址。因此，在这种情况下，你不需要创建或配置负载均衡器。
[AZURE.INCLUDE [load-balanced-endpoints](../includes/virtual-machines-ag-listener-load-balanced-endpoints.md)]
diff --git a/articles/virtual-machines-sql-server-connectivity.md b/articles/virtual-machines-sql-server-connectivity.md
index 34671af5c..86b023dab 100644
--- a/articles/virtual-machines-sql-server-connectivity.md
+++ b/articles/virtual-machines-sql-server-connectivity.md
@@ -49,7 +49,7 @@
尽管客户端可通过 Internet 进行连接，但这并不意味着任何人都可以连接到 SQL Server。外部客户端必须有正确的用户名和密码。为了提高安全性，请不要对公共虚拟机终结点使用常用的 1433 端口。如果可能，请考虑在终结点上添加 ACL 以将流量限制为你允许的客户端。有关在终结点上使用 ACL 的说明，请参阅[管理终结点上的 ACL](/documentation/articles/virtual-machines-set-up-endpoints#manage-the-acl-on-an-endpoint)。
->[AZURE.NOTE]请务必注意，使用这种方法与 SQL Server 进行通信时，所有返回的数据被将视为数据中心的传出流量。这需要按一般的[出站数据传输价格](/pricing/details/data-transfer/)付费。即使在同一 Azure 数据中心内的另一个计算机或云服务中使用这种方法，也是如此，因为流量还是会通过 Azure 的公共负载平衡器。
+>[AZURE.NOTE]请务必注意，使用这种方法与 SQL Server 进行通信时，所有返回的数据被将视为数据中心的传出流量。这需要按一般的[出站数据传输价格](/pricing/details/data-transfer/)付费。即使在同一 Azure 数据中心内的另一个计算机或云服务中使用这种方法，也是如此，因为流量还是会通过 Azure 的公共负载均衡器。
### 连接到同一虚拟网络中的 SQL Server
diff --git a/articles/virtual-machines-sql-server-use-premium-storage.md b/articles/virtual-machines-sql-server-use-premium-storage.md
index cbea05373..e052ba279 100644
--- a/articles/virtual-machines-sql-server-use-premium-storage.md
+++ b/articles/virtual-machines-sql-server-use-premium-storage.md
@@ -46,7 +46,7 @@
### 云服务
-在新的云服务中创建 VM 时，只能将 DS* VM 用于高级存储。如果你在 Azure 中使用 SQL Server AlwaysOn，则 AlwaysOn 侦听器将引用与云服务关联的 Azure 内部或外部负载平衡器 IP 地址。本文重点介绍如何在此方案中迁移，同时保持可用性。
+在新的云服务中创建 VM 时，只能将 DS* VM 用于高级存储。如果你在 Azure 中使用 SQL Server AlwaysOn，则 AlwaysOn 侦听器将引用与云服务关联的 Azure 内部或外部负载均衡器 IP 地址。本文重点介绍如何在此方案中迁移，同时保持可用性。
> [AZURE.NOTE]DS* 系列必须是部署到新的云服务的第一个 VM。
@@ -364,9 +364,9 @@
![DeploymentsUseAlwaysOn][6]
-在 Windows Azure 中，只能将一个 IP 地址分配给 VM 上的网络接口卡，因此，为了实现与本地相同的抽象层，Azure 将利用分配给内部/外部负载平衡器 (ILB/ELB) 的 IP 地址。在服务器间共享的 IP 资源将设置为与 ILB/ELB 相同的 IP。此 IP 在 DNS 中发布，客户端流量将通过 ILB/ELB 传递到主 SQL Server 副本。ILB/ELB 知道哪个 SQL Server 为主，因为它使用探测器来探测 AlwaysOn IP 资源。在前面的示例中，它会探测包含 ELB/ILB 引用的终结点的每个节点，做出响应的则是主 SQL Server。
+在 Windows Azure 中，只能将一个 IP 地址分配给 VM 上的网络接口卡，因此，为了实现与本地相同的抽象层，Azure 将利用分配给内部/外部负载均衡器 (ILB/ELB) 的 IP 地址。在服务器间共享的 IP 资源将设置为与 ILB/ELB 相同的 IP。此 IP 在 DNS 中发布，客户端流量将通过 ILB/ELB 传递到主 SQL Server 副本。ILB/ELB 知道哪个 SQL Server 为主，因为它使用探测器来探测 AlwaysOn IP 资源。在前面的示例中，它会探测包含 ELB/ILB 引用的终结点的每个节点，做出响应的则是主 SQL Server。
-> [AZURE.NOTE]ILB 和 ELB 都分配给特定 Azure 云服务，因此 Azure 中的任何云迁移都很可能意味着负载平衡器 IP 将更改。
+> [AZURE.NOTE]ILB 和 ELB 都分配给特定 Azure 云服务，因此 Azure 中的任何云迁移都很可能意味着负载均衡器 IP 将更改。
### 迁移可以允许停机一段时间的 AlwaysOn 部署
@@ -377,7 +377,7 @@
#### 1.将更多辅助副本添加到现有 AlwaysOn 群集
-一种策略是将更多辅助副本添加到 AlwaysOn 可用性组。你需要将这些辅助副本添加到新的云服务中，并使用新的负载平衡器 IP 更新侦听器。
+一种策略是将更多辅助副本添加到 AlwaysOn 可用性组。你需要将这些辅助副本添加到新的云服务中，并使用新的负载均衡器 IP 更新侦听器。
##### 停机时间点：
@@ -396,7 +396,7 @@
1. 在使用附加高级存储的新云服务中创建两个新的 SQL Server。
1. 使用 **NORECOVERY** 复制完整备份并进行还原。
1. 复制“用户数据库外”依赖对象，例如登录名等。
-1. 新建内部负载平衡器 (ILB) 或使用外部负载平衡器 (ELB)，然后在这两个新节点上设置负载平衡终结点。
+1. 新建内部负载均衡器 (ILB) 或使用外部负载均衡器 (ELB)，然后在这两个新节点上设置负载平衡终结点。
> [AZURE.NOTE]继续下一步之前，检查所有节点的终结点配置是否正确
1. 禁止用户/应用程序访问 SQL Server（如果使用存储池）。
@@ -463,7 +463,7 @@
- 你的客户端重新连接可能会延迟，具体取决于你的客户端/DNS 配置。
- 如果你选择将 AlwaysOn 群集组脱机来换出 IP 地址，则会增加停机时间。可以通过对添加的 IP 地址资源使用 OR 依赖关系和可能的所有者来避免出现这种情况。请参阅[附录](#appendix-migrating-a-multisite-alwayson-cluster-to-premium-storage)的“在同一子网中添加 IP 地址资源”部分。
-> [AZURE.NOTE]如果你想让添加的节点作为 AlwaysOn 故障转移伙伴参与其中，则需要为 Azure 终结点添加对负载平衡集的引用。当你通过运行 **Add-AzureEndpoint** 命令来执行此操作时，当前连接将保持打开，但在更新负载平衡器之前，将无法与侦听器建立新连接。在测试时，看到此现像持续 90 到 120 秒，应该对此进行测试。
+> [AZURE.NOTE]如果你想让添加的节点作为 AlwaysOn 故障转移伙伴参与其中，则需要为 Azure 终结点添加对负载平衡集的引用。当你通过运行 **Add-AzureEndpoint** 命令来执行此操作时，当前连接将保持打开，但在更新负载均衡器之前，将无法与侦听器建立新连接。在测试时，看到此现像持续 90 到 120 秒，应该对此进行测试。
##### 优点
@@ -547,7 +547,7 @@
## 附录：将多站点 AlwaysOn 群集迁移到高级存储
-本主题的剩余部分提供将多站点 AlwaysOn 群集转换为高级存储的详细示例。它还将侦听器从使用外部负载平衡器 (ELB) 转换为使用内部负载平衡器 (ILB)。
+本主题的剩余部分提供将多站点 AlwaysOn 群集转换为高级存储的详细示例。它还将侦听器从使用外部负载均衡器 (ELB) 转换为使用内部负载均衡器 (ILB)。
### 环境
@@ -648,7 +648,7 @@
##Set RegisterAllProvidersIP
Get-ClusterResource $ListenerName| Set-ClusterParameter RegisterAllProvidersIP 1
-在后面的迁移步骤中，你将需要使用引用负载平衡器的已更新 IP 地址更新 AlwaysOn 侦听器，这将涉及删除和添加 IP 地址资源。更新 IP 之后，你需要确保已在 DNS 区域中更新新的 IP 地址并且客户端将更新其本地 DNS 缓存。
+在后面的迁移步骤中，你将需要使用引用负载均衡器的已更新 IP 地址更新 AlwaysOn 侦听器，这将涉及删除和添加 IP 地址资源。更新 IP 之后，你需要确保已在 DNS 区域中更新新的 IP 地址并且客户端将更新其本地 DNS 缓存。
如果你的客户端驻留在不同网络段，并引用不同的 DNS 服务器，则你需要考虑在迁移期间将发生哪些与 DNS 区域传送相关的事件，因为应用程序重新连接时间将至少受到侦听器的任何新 IP 地址的区域传送时间的约束。如果你在此处受到时间约束，则应与 Windows 团队讨论并测试强制增量区域传送，同时还应将 DNS 主机记录设为较小的生存时间 (TTL)，以使客户端更新。有关详细信息，请参阅[增量区域传送](https://technet.microsoft.com/zh-CN/library/cc958973.aspx)和 [Start-DnsServerZoneTransfer](https://technet.microsoft.com/zh-CN/library/jj649917.aspx)。
diff --git a/articles/virtual-machines-troubleshoot-access-application.md b/articles/virtual-machines-troubleshoot-access-application.md
index 9543781de..e640273c6 100644
--- a/articles/virtual-machines-troubleshoot-access-application.md
+++ b/articles/virtual-machines-troubleshoot-access-application.md
@@ -66,7 +66,7 @@
- 目标虚拟机上的主机防火墙允许入站请求和出站响应流量。
- Azure 虚拟机上运行的入侵检测或网络监视软件允许流量。
- 网络安全组允许流量。
-- 虚拟网络中在测试虚拟机和虚拟机之间的路径运行的单独组件（例如负载平衡器或防火墙）允许流量。
+- 虚拟网络中在测试虚拟机和虚拟机之间的路径运行的单独组件（例如负载均衡器或防火墙）允许流量。
在基于 Windows 的虚拟机上，使用具有高级安全性的 Windows 防火墙确定防火墙规则是否排除应用程序的入站和出站流量。
diff --git a/articles/virtual-machines-workload-high-availability-LOB-application-phase4.md b/articles/virtual-machines-workload-high-availability-LOB-application-phase4.md
index 4cbc55948..22701d0a9 100644
--- a/articles/virtual-machines-workload-high-availability-LOB-application-phase4.md
+++ b/articles/virtual-machines-workload-high-availability-LOB-application-phase4.md
@@ -23,7 +23,7 @@
有两个 web 服务器虚拟机，可以在其上部署 ASP.NET 应用程序或可由 Windows Server 2012 R2 中的 Internet 信息服务 (IIS) 8 托管的旧版应用程序。
-首先，将配置内部负载平衡，以便 Azure 将客户端发到业务线应用程序的流量均匀地分布在两个 web 服务器上。这需要你指定内部负载平衡实例，该实例由名称和它自己的 IP 地址（从你分配给 Azure 虚拟网络的子网地址空间中分配）组成。若要确定为内部负载平衡器选择的 IP 地址是否可用，请在 Azure PowerShell 提示符下使用这些命令。为变量指定值，并删除 < and > 字符。
+首先，将配置内部负载平衡，以便 Azure 将客户端发到业务线应用程序的流量均匀地分布在两个 web 服务器上。这需要你指定内部负载平衡实例，该实例由名称和它自己的 IP 地址（从你分配给 Azure 虚拟网络的子网地址空间中分配）组成。若要确定为内部负载均衡器选择的 IP 地址是否可用，请在 Azure PowerShell 提示符下使用这些命令。为变量指定值，并删除 < and > 字符。
Switch-AzureMode AzureServiceManagement
$vnet=""
@@ -52,7 +52,7 @@
$lbrule=New-AzureLoadBalancerRuleConfig -Name "WebTraffic" -FrontendIpConfiguration $frontendIP -BackendAddressPool $beAddressPool -Probe $healthProbe -Protocol "TCP" -FrontendPort 80 -BackendPort 80
New-AzureLoadBalancer -ResourceGroupName $rgName -Name "WebServersInAzure" -Location $locName -LoadBalancingRule $lbrule -BackendAddressPool $beAddressPool -Probe $healthProbe -FrontendIpConfiguration $frontendIP
-接下来，将 DNS 地址记录添加到你组织的内部 DNS 基础结构中，以便将业务线应用程序的完全限定域名（例如 lobapp.corp.contoso.com）解析为分配给内部负载平衡器的 IP 地址（前面的 Azure PowerShell 命令块中 $privIP 的值）。
+接下来，将 DNS 地址记录添加到你组织的内部 DNS 基础结构中，以便将业务线应用程序的完全限定域名（例如 lobapp.corp.contoso.com）解析为分配给内部负载均衡器的 IP 地址（前面的 Azure PowerShell 命令块中 $privIP 的值）。
接下来，使用以下 PowerShell 命令块为两个 web 服务器创建虚拟机。请注意，此 PowerShell 命令集使用下表中的值：
diff --git a/articles/virtual-machines-workload-intranet-sharepoint-phase4.md b/articles/virtual-machines-workload-intranet-sharepoint-phase4.md
index e98f5541e..1a9e5a838 100644
--- a/articles/virtual-machines-workload-intranet-sharepoint-phase4.md
+++ b/articles/virtual-machines-workload-intranet-sharepoint-phase4.md
@@ -136,7 +136,7 @@
## 配置内部负载平衡
-可配置内部负载平衡，使到 SharePoint 场的客户端流量平均分布到两个前端 Web 服务器上。这需要你指定内部负载平衡实例，该实例由名称和它自己的 IP 地址（从子网地址空间中分配）组成。若要确定为内部负载平衡器选择的 IP 地址是否可用，请使用以下 Azure PowerShell 命令：
+可配置内部负载平衡，使到 SharePoint 场的客户端流量平均分布到两个前端 Web 服务器上。这需要你指定内部负载平衡实例，该实例由名称和它自己的 IP 地址（从子网地址空间中分配）组成。若要确定为内部负载均衡器选择的 IP 地址是否可用，请使用以下 Azure PowerShell 命令：
$vnet=""
$testIP=""
@@ -165,7 +165,7 @@
$vmname=""
Get-AzureVM –ServiceName $serviceName –Name $vmname | Add-AzureEndpoint -Name $epname -LBSetName $ilb -Protocol $prot -LocalPort $locport -PublicPort $pubport –DefaultProbe -InternalLoadBalancerName $ilb | Update-AzureVM
-接下来，将 DNS 地址记录添加到你组织的 DNS 基础结构中，以便将 SharePoint 场的完全限定域名（例如 sp.corp.contoso.com）解析为分配给内部负载平衡器实例的 IP 地址（前面的 Azure PowerShell 命令块中 **$IP** 的值）。
+接下来，将 DNS 地址记录添加到你组织的 DNS 基础结构中，以便将 SharePoint 场的完全限定域名（例如 sp.corp.contoso.com）解析为分配给内部负载均衡器实例的 IP 地址（前面的 Azure PowerShell 命令块中 **$IP** 的值）。
这是成功完成此阶段后生成的配置。
diff --git a/articles/virtual-networks-load-balancer-manage-distribution-mode-source-ip.md b/articles/virtual-networks-load-balancer-manage-distribution-mode-source-ip.md
index edc029462..6e4000825 100644
--- a/articles/virtual-networks-load-balancer-manage-distribution-mode-source-ip.md
+++ b/articles/virtual-networks-load-balancer-manage-distribution-mode-source-ip.md
@@ -1,6 +1,6 @@
-# 管理虚拟网络：负载平衡器分发模式（源 IP 关联）
-**源 IP 关联**（也称为“会话关联”或“客户端 IP 关联”）是一种 Azure 负载平衡器分发模式，它将来自单个客户端的连接绑定到 Azure 托管的单个服务器，而不是将每个客户端连接动态分发到 Azure 托管的不同服务器（默认负载平衡器行为）。
+# 管理虚拟网络：负载均衡器分发模式（源 IP 关联）
+**源 IP 关联**（也称为“会话关联”或“客户端 IP 关联”）是一种 Azure 负载均衡器分发模式，它将来自单个客户端的连接绑定到 Azure 托管的单个服务器，而不是将每个客户端连接动态分发到 Azure 托管的不同服务器（默认负载均衡器行为）。
-使用源 IP 关联，Azure 负载平衡器可以配置为使用 2 元组组合（源 IP、目标 IP）或 3 元组组合（源 IP、目标 IP、协议）将流量映射到 Azure 托管的可用服务器池。使用源 IP 关联时，从同一客户端计算机发起的连接由单个 DIP 终结点（Azure 托管的单个服务器）处理。
+使用源 IP 关联，Azure 负载均衡器可以配置为使用 2 元组组合（源 IP、目标 IP）或 3 元组组合（源 IP、目标 IP、协议）将流量映射到 Azure 托管的可用服务器池。使用源 IP 关联时，从同一客户端计算机发起的连接由单个 DIP 终结点（Azure 托管的单个服务器）处理。
## 服务源
-源 IP 关联解决了以前 [Azure 负载平衡器与 RD 网关 (DOC) 之间的不兼容](http://download.microsoft.com/download/E/A/7/EA75F19F-63F1-401A-8021-13AE2E6D8196/Microsoft%20Azure%20Desktop%20Hosting%20Reference%20Architecture%20Guide-Nov2014.docx)。
+源 IP 关联解决了以前 [Azure 负载均衡器与 RD 网关 (DOC) 之间的不兼容](http://download.microsoft.com/download/E/A/7/EA75F19F-63F1-401A-8021-13AE2E6D8196/Microsoft%20Azure%20Desktop%20Hosting%20Reference%20Architecture%20Guide-Nov2014.docx)。
## 实现
@@ -36,20 +36,20 @@
1. 使用单个云服务的远程桌面网关群集
2. 媒体上载（即，UDP 用于数据，TCP 用于控制）
* 客户端启动与 Azure 托管的负载平衡公共 IP 地址的 TCP 会话。
- * 客户端请求将由负载平衡器定向到某个 DIP；此通道将保持处于活动状态，以监视连接健康状况
+ * 客户端请求将由负载均衡器定向到某个 DIP；此通道将保持处于活动状态，以监视连接健康状况
* 客户端启动与 Azure 托管的同一负载平衡公共 IP 地址的 UDP 会话
- * Azure 负载平衡器将请求定向到与 TCP 连接相同的 DIP 终结点
+ * Azure 负载均衡器将请求定向到与 TCP 连接相同的 DIP 终结点
* 客户端将使用更高的 UDP 吞吐量上载媒体，同时通过 TCP 维护控制通道，以保证可靠性
## 注意事项
* 如果更改了负载平衡集（即添加或删除虚拟机），客户端通道分布将重新计算；来自现有客户端的新连接可能由不是原来使用的服务器处理
* 使用源 IP 关联可能会导致跨 Azure 托管的服务器的流量不均匀分布
-* 通过代理路由流量的客户端可能被 Azure 负载平衡器视为单个客户端
+* 通过代理路由流量的客户端可能被 Azure 负载均衡器视为单个客户端
## PowerShell 示例
为获得最佳结果，请下载[最新版的 Azure PowerShell](https://github.com/Azure/azure-sdk-tools/releases)。
-### 将 Azure 终结点添加到虚拟机并设置负载平衡器分发模式
+### 将 Azure 终结点添加到虚拟机并设置负载均衡器分发模式
Get-AzureVM -ServiceName "mySvc" -Name "MyVM1" | Add-AzureEndpoint -Name "HttpIn" -Protocol "tcp" -PublicPort 80 -LocalPort 8080 –LoadBalancerDistribution “sourceIP�| Update-AzureVM
@@ -57,7 +57,7 @@
LoadBalancerDistribution 可以设置为 sourceIP（用于 2 元组（源 IP、目标 IP）负载平衡）、sourceIPProtocol（用于 3 元组（源 IP、目标 IP、协议）负载平衡）或 none（如果想要默认行为（5 元组负载平衡））。
-### 检索终结点负载平衡器分发模式配置
+### 检索终结点负载均衡器分发模式配置
PS C:\> Get-AzureVM -ServiceName "mySvc" -Name "MyVM" | Get-AzureEndpoint
@@ -79,7 +79,7 @@ LoadBalancerDistribution 可以设置为 sourceIP（用于 2 元组（源 IP、
IdleTimeoutInMinutes : 15
LoadBalancerDistribution : sourceIP
-如果 LoadBalancerDistribution 元素不存在，则 Azure 负载平衡器使用默认的 5 元组算法
+如果 LoadBalancerDistribution 元素不存在，则 Azure 负载均衡器使用默认的 5 元组算法
### 在负载平衡终结点集上设置分发模式
@@ -93,7 +93,7 @@ LoadBalancerDistribution 可以设置为 sourceIP（用于 2 元组（源 IP、
你可以利用 Azure SDK for .NET 来更新云服务
-云服务的终结点设置在 .csdef 中进行。若要更新云服务部署的负载平衡器分发模式，需要进行部署升级。
+云服务的终结点设置在 .csdef 中进行。若要更新云服务部署的负载均衡器分发模式，需要进行部署升级。
下面是终结点设置的 .csdef 更改的示例：
@@ -115,7 +115,7 @@ LoadBalancerDistribution 可以设置为 sourceIP（用于 2 元组（源 IP、
## API 示例
-开发人员可以使用服务管理 API 配置负载平衡器分发。确保添加 x-ms-version 标头并将其设为版本 2014-09-01 或更高版本。
+开发人员可以使用服务管理 API 配置负载均衡器分发。确保添加 x-ms-version 标头并将其设为版本 2014-09-01 或更高版本。
### 更新部署中指定的负载平衡集配置
diff --git a/articles/virtual-networks-load-balancer-manage-idle-timeout.md b/articles/virtual-networks-load-balancer-manage-idle-timeout.md
index dd1049c30..5767a0c62 100644
--- a/articles/virtual-networks-load-balancer-manage-idle-timeout.md
+++ b/articles/virtual-networks-load-balancer-manage-idle-timeout.md
@@ -3,8 +3,8 @@
documentationCenter="dev-center-name"
editor=""
manager="jefco"
- pageTitle="管理：负载平衡器空闲超时"
- description="Azure 负载平衡器空闲超时的管理功能"
+ pageTitle="管理：负载均衡器空闲超时"
+ description="Azure 负载均衡器空闲超时的管理功能"
services="virtual-network"
/>
@@ -14,9 +14,9 @@
wacn.date="10/17/2015"
/>
-# 管理虚拟网络：负载平衡器 TCP 空闲超时
+# 管理虚拟网络：负载均衡器 TCP 空闲超时
-**TCP 空闲超时**允许开发人员指定一个确定的阈值，该阈值针对客户端-服务器会话期间出现的与 Azure 负载平衡器相关的非活动状态。TCP 空闲超时值为 4 分钟（Azure 负载平衡器的默认值）意味着，如果在客户端-服务器会话期间出现的与 Azure 负载平衡器相关的非活动状态的持续时间超过 4 分钟，则会关闭连接。
+**TCP 空闲超时**允许开发人员指定一个确定的阈值，该阈值针对客户端-服务器会话期间出现的与 Azure 负载均衡器相关的非活动状态。TCP 空闲超时值为 4 分钟（Azure 负载均衡器的默认值）意味着，如果在客户端-服务器会话期间出现的与 Azure 负载均衡器相关的非活动状态的持续时间超过 4 分钟，则会关闭连接。
当客户端-服务器连接关闭时，客户端应用程序会收到一条类似于下面这样的错误消息：“基础连接已关闭: 应保持活动状态的连接已由服务器关闭”。
@@ -24,7 +24,7 @@
虽然 TCP Keep-Alive 很有效，但通常不适用于移动应用程序，因为它会消耗移动设备上有限的能源。使用 TCP Keep-Alive 的移动应用程序会更快地耗尽设备电池的能源，因为它会持续地汲取需要在网络上使用的能源。
-Azure 负载平衡器支持对 TCP 空闲超时进行配置，因此支持移动设备方案。对于入站连接，开发人员可以将 TCP 空闲超时设置为 4 到 30 分钟（可配置的 TCP 空闲超时不适用于出站连接）。这样客户端就可以与服务器维持很长时间的会话，即使长时间处于非活动状态也不会断开连接。移动设备上的应用程序仍然可以选择利用 TCP Keep-Alive 技术来保留非活动时间预计会超过 30 分钟的连接，不过在使用这种空闲时间更长的 TCP 空闲超时时，应用程序发出 TCP Keep-Alive 请求的频率要比以前低得多，因此会大大降低移动设备能源的消耗。
+Azure 负载均衡器支持对 TCP 空闲超时进行配置，因此支持移动设备方案。对于入站连接，开发人员可以将 TCP 空闲超时设置为 4 到 30 分钟（可配置的 TCP 空闲超时不适用于出站连接）。这样客户端就可以与服务器维持很长时间的会话，即使长时间处于非活动状态也不会断开连接。移动设备上的应用程序仍然可以选择利用 TCP Keep-Alive 技术来保留非活动时间预计会超过 30 分钟的连接，不过在使用这种空闲时间更长的 TCP 空闲超时时，应用程序发出 TCP Keep-Alive 请求的频率要比以前低得多，因此会大大降低移动设备能源的消耗。
## 实现
@@ -106,7 +106,7 @@ IdleTimeoutInMinutes 为可选。在未设置的情况下，默认超时为 4
## API 示例
-开发人员可以使用服务管理 API 配置负载平衡器分发。请确保添加的 x-ms-version 标头设置为 2014-06-01 或更高版本。
+开发人员可以使用服务管理 API 配置负载均衡器分发。请确保添加的 x-ms-version 标头设置为 2014-06-01 或更高版本。
### 通过一次部署，在所有虚拟机上更新指定的负载平衡输入终结点的配置
diff --git a/articles/virtual-networks-nsg.md b/articles/virtual-networks-nsg.md
index fb8ecfa16..d5bfdb4aa 100644
--- a/articles/virtual-networks-nsg.md
+++ b/articles/virtual-networks-nsg.md
@@ -55,7 +55,7 @@
NSG 包含默认规则。默认规则无法删除，但由于给它们分配的优先级最低，可以用创建的规则来重写它们。默认规则描述平台所推荐的默认设置。正如以下默认规则所阐述的那样，从方向上来说，在 VNet 中发起和结束的流量可以是入站流量，也可以是出站流量。
-虽然出站方向的流量允许连接到 Internet，但默认情况下，入站方向的流量在连接到 Internet 时会被阻止。还有一个的默认规则允许 Azure 的负载平衡器 (LB) 探测 VM 的运行状况。如果 NSG 下的 VM 或 VM 集不参与负载平衡集，你可以重写此规则。
+虽然出站方向的流量允许连接到 Internet，但默认情况下，入站方向的流量在连接到 Internet 时会被阻止。还有一个的默认规则允许 Azure 的负载均衡器 (LB) 探测 VM 的运行状况。如果 NSG 下的 VM 或 VM 集不参与负载平衡集，你可以重写此规则。
默认规则是：
@@ -81,7 +81,7 @@ NSG 包含默认规则。默认规则无法删除，但由于给它们分配的
- **VIRTUAL\_NETWORK -** 此默认标记表示你的所有网络地址空间。它包括虚拟网络地址空间（Azure 中的 IP CIDR）以及所有连接的本地地址空间（本地网络）。这还包括 VNet 到 VNet 地址空间。
-- **AZURE\_LOADBALANCER -** 此默认标记表示 Azure 的基础结构负载平衡器。这将转换到 Azure 数据中心 IP，从中进行 Azure 的运行状况探测。仅当与 NSG 关联的 VM 或 VM 集参与负载平衡集的情况下，才需要此项。
+- **AZURE\_LOADBALANCER -** 此默认标记表示 Azure 的基础结构负载均衡器。这将转换到 Azure 数据中心 IP，从中进行 Azure 的运行状况探测。仅当与 NSG 关联的 VM 或 VM 集参与负载平衡集的情况下，才需要此项。
- **INTERNET -** 此默认标记表示虚拟网络外部的 IP 地址空间，可以通过公共 Internet 进行访问。此范围还包括 Azure 拥有的公共 IP 空间。
@@ -139,7 +139,7 @@ Azure 中的一个常见方案是基于这些对象是否需要访问 Internet
你还需要考虑下面所列的特殊规则。请确保不要阻止这些规则允许的流量，否则你的基础结构将无法与基本 Azure 服务通信。
-- **主机节点的虚拟 IP：**基本基础结构服务（例如 DHCP、DNS 和运行状况监视）是通过虚拟化主机 IP 地址 168.63.129.16 提供的。此公用 IP 地址属于 Microsoft，并将是唯一的用于所有区域的虚拟化 IP 地址，而且没有其他用途。此 IP 地址映射到托管虚拟机的服务器计算机（主机节点）的物理 IP 地址。主机节点充当 DHCP 中继、DNS 递归解析器，以及进行负载平衡器运行状况探测和计算机运行状况探测的探测源。不应将针对此 IP 地址的通信视为一种攻击。
+- **主机节点的虚拟 IP：**基本基础结构服务（例如 DHCP、DNS 和运行状况监视）是通过虚拟化主机 IP 地址 168.63.129.16 提供的。此公用 IP 地址属于 Microsoft，并将是唯一的用于所有区域的虚拟化 IP 地址，而且没有其他用途。此 IP 地址映射到托管虚拟机的服务器计算机（主机节点）的物理 IP 地址。主机节点充当 DHCP 中继、DNS 递归解析器，以及进行负载均衡器运行状况探测和计算机运行状况探测的探测源。不应将针对此 IP 地址的通信视为一种攻击。
- **许可（密钥管理服务）：**在虚拟机中运行的 Windows 映像应该获得许可。因此，将会向处理此类查询的密钥管理服务主机服务器发送许可请求。这将始终在出站端口 1688 上进行。
diff --git a/articles/virtual-networks-overview.md b/articles/virtual-networks-overview.md
index f0ad911c6..a0160bdc4 100644
--- a/articles/virtual-networks-overview.md
+++ b/articles/virtual-networks-overview.md
@@ -19,13 +19,13 @@ Azure 虚拟网络 (VNet) 是你自己的网络在云中的表示形式。你可
-上图显示了通过路由器连接到公共 Internet 的本地网络。你还可以看到路由器与托管 DNS 服务器和 Web 服务器场的外围网络之间的防火墙。Web 服务器场使用向 Internet 公开的硬件负载平衡器进行负载平衡，并使用内部子网中的资源。内部子网由另一个防火墙与外围网络隔开，并托管 Active Directory 域控制器服务器、数据库服务器和应用程序服务器。
+上图显示了通过路由器连接到公共 Internet 的本地网络。你还可以看到路由器与托管 DNS 服务器和 Web 服务器场的外围网络之间的防火墙。Web 服务器场使用向 Internet 公开的硬件负载均衡器进行负载平衡，并使用内部子网中的资源。内部子网由另一个防火墙与外围网络隔开，并托管 Active Directory 域控制器服务器、数据库服务器和应用程序服务器。
可以在 Azure 中托管同一网络，如下图所示。
-请注意 Azure 基础结构如何起着路由器作用，允许从 VNet 访问公共 Internet 而无需进行任何配置。防火墙可由应用于每个单独子网的网络安全组 (NSG) 替代。而物理负载平衡器可由 Azure 中面向 Internet 的负载平衡器和内部负载平衡器替代。
+请注意 Azure 基础结构如何起着路由器作用，允许从 VNet 访问公共 Internet 而无需进行任何配置。防火墙可由应用于每个单独子网的网络安全组 (NSG) 替代。而物理负载均衡器可由 Azure 中面向 Internet 的负载均衡器和内部负载均衡器替代。
## 虚拟网络
@@ -57,15 +57,15 @@ VNet 为部署到它们的 IaaS VM 和 PaaS 角色的角色实例提供以下服
这些 IP 地址是动态的，意味着它们可以随时更改。你可能希望确保某些服务的 IP 地址始终保持不变。为此，可以保留一个 IP 地址，将设为静态。
-## Azure 负载平衡器
+## Azure 负载均衡器
-在 Azure 中可以使用两种类型的负载平衡器：
+在 Azure 中可以使用两种类型的负载均衡器：
-- **外部负载平衡器**。可以使用外部负载平衡器为从公共 Internet 访问的 IaaS VM 和 PaaS 角色实例提供高可用性。
+- **外部负载均衡器**。可以使用外部负载均衡器为从公共 Internet 访问的 IaaS VM 和 PaaS 角色实例提供高可用性。
-- **内部负载平衡器**。可以使用内部负载平衡器为从 VNet 中的其他服务访问的 IaaS VM 和 PaaS 角色实例提供高可用性。
+- **内部负载均衡器**。可以使用内部负载均衡器为从 VNet 中的其他服务访问的 IaaS VM 和 PaaS 角色实例提供高可用性。
-
+
## 网络安全组 (NSG)
@@ -84,7 +84,7 @@ VNet 为部署到它们的 IaaS VM 和 PaaS 角色的角色实例提供以下服
- [创建 VNet](/documentation/articles/virtual-networks-create-a-vnet) 和子网。
- [在 VNet 中创建 VM](/documentation/articles/virtual-machines-windows-tutorial-classic-portal)。
- 了解 [NSG](/documentation/articles/virtual-networks-nsg)。
-
+
- [保留内部 IP 地址](/documentation/articles/virtual-networks-reserved-private-ip)
- [保留公共 IP 地址](/documentation/articles/virtual-networks-reserved-public-ip)。
- 了解[用户定义的路由和 IP 转发](/documentation/articles/virtual-networks-udr-overview)。