首页 > 代码库 > 使用微软Traffic Manage---实验
使用微软Traffic Manage---实验
官方介绍说Azure Traffic Manager是为了分担流量，但是也可以这样
Traffic Manager 可帮助你：
提高关键应用程序的可用性 - 使用 Traffic Manager，可以通过监视 Azure 中的终结点并在 Azure 云服务、Azure 网站或其他位置关闭时提供自动故障转移功能来提高关键应用程序的可用性。
提高高性能应用程序的响应能力 – Azure 允许你在世界各地的数据中心内运行云服务或网站。通过从客户端将最终用户定向到网络延迟最低的终结点，Traffic Manager 可以提高应用程序的响应能力并缩短内容传送时间。
在不停机的情况下执行升级和服务维护 - Traffic Manager 支持用于混合云和本地部署的扩展方案，包括“迸发到云”、“迁移到云”和“故障转移到云”方案。对于计划的维护，可以在 Traffic Manager 中禁用终结点，然后等待终结点完成现有连接服务。当没有更多流量流到终结点时，在该终结点上更新服务并进行测试，然后在 Traffic Manager 中重新启用它。这可帮助你在不造成客户端停机的情况下维护和升级服务。
大型复杂部署的流量分配 - 使用嵌套的 Traffic Manager 配置文件（在其中的一个 Traffic Manager 配置文件可以将另一个 Traffic Manager 配置文件作为终结点），可以创建配置来优化更大、更复杂部署的性能和分布。有关详细信息，请参阅嵌套配置文件。
Traffic Manager 工作方式
在配置 Traffic Manager 配置文件时，指定的设置将为 Traffic Manager 提供所需的信息来根据 DNS 查询确定应该由哪个终结点为请求提供服务。实际的终结点流量不会通过 Traffic Manager 路由。
Figure 1 显示了 Traffic Manager 如何将用户定向到一组终结点中的一个。图 1 中的数字对应于下面的编号说明：
图 1
用户流量指向公司域名：使用公司域名的客户端请求信息。目标是将 DNS 名称解析为 IP 地址。必须通过在 Traffic Manager 外部维护的正常 Internet 域名注册保留公司域。在图 1 中，示例公司域为 www.contoso.com。
公司域名指向 Traffic Manager 域名：公司域的 DNS 资源记录指向在 Azure Traffic Manager 中维护的 Traffic Manager 域名。这是使用一条 CNAME 资源记录来实现的，该记录可将公司域名映射到 Traffic Manager 域名。在本示例中，Traffic Manager 域名为 contoso.trafficmanager.net。
Traffic Manager 域名和配置文件：Traffic Manager 域名是 Traffic Manager 配置文件的一部分。用户的 DNS 服务器针对 Traffic Manager 域名（在本示例中为 contoso.trafficmanager.net）发送新的 DNS 查询，该查询由 Traffic Manager DNS 名称服务器接收。
处理的 Traffic Manager 配置文件规则：Traffic Manager 使用指定的负载平衡方法和监视状态来确定应该由哪个 Azure 终结点为请求提供服务。
发送给用户的终结点域名：Traffic Manager 返回一条 CNAME 记录，该记录将 Traffic Manager 域名映射到终结点的域名。用户的 DNS 服务器将终结点域名解析为其 IP 地址，并将该地址发送给用户。
用户调用终结点：用户直接使用返回的终结点的 IP 地址调用该终结点。
由于公司域和解析的 IP 地址已在客户端计算机上缓存，因此，用户将持续与所选终结点交互，直到该终结点的本地 DNS 缓存过期。特别要注意的是，DNS 客户端缓存 DNS 主机条目的持续时间就是这些条目的生存时间 (TTL)。从 DNS 客户端缓存中检索主机条目会绕过 Traffic Manager 配置文件，如果在 TTL 过期之前终结点变为不可用，则你可能会遇到连接延迟的情况。如果缓存中 DNS 主机条目的 TTL 过期，并且客户端计算机需要再次解析公司域名，则该计算机将发送新的 DNS 查询。根据应用的负载平衡方法和请求时终结点的运行状况，客户端计算机可能会收到不同终结点的 IP 地址。
如何实现 Traffic Manager
Figure 2 按顺序显示实现 Traffic Manager 所需的步骤。在全面理解 Traffic Manager 配置和最佳实践之后，你可以按略有不同的顺序执行这些步骤。图 2 中的数字对应于下面的编号说明：
图 2
将 Azure 云服务、Azure 网站或其他终结点部署到生产环境。在创建 Traffic Manager 配置文件时，必须将其与某个订阅关联。然后，在生产环境中为云服务和“标准”层网站添加属于同一订阅的终结点。如果某一终结点位于过渡环境中而不在 Azure 生产环境中或同一订阅中，则不能将其添加为外部终结点。有关云服务的详细信息，请参阅云服务。有关网站的详细信息，请参阅网站。
确定 Traffic Manager 域的名称。考虑为域使用带有唯一前缀的名称。域的后半部分（即 trafficmanager.cn）是固定的。有关详细信息，请参阅最佳实践。
确定要使用的监视配置。无论使用哪种负载平衡方法，Traffic Manager 都会监视终结点以确保它们联机。在你配置监视设置之后，Traffic Manager 不会将流量定向到监视系统判定为脱机的终结点，除非它检测到所有终结点均已脱机，或无法检测配置文件中包含的任一终结点的状态。有关监视的详细信息，请参 阅关于 Traffic Manager 监视。
确定要使用的负载平衡方法。有三种不同的负载平衡方法。花时间了解哪种方法最满足你的要求。你之后可以随时更改方法。另请注意，每种方法都需要稍微不同的配置步骤。有关负载平衡方法的信息，请参阅关于 Traffic Manager 负载平衡方法。
创建配置文件并配置设置。可以使用 REST API、Windows PowerShell 或管理门户来创建 Traffic Manager 配置文件并配置设置。有关详细信息，请参阅如何配置 Traffic Manager 设置。以下步骤假定你将在管理门户中使用“快速创建”。
创建 Traffic Manager 配置文件 - 若要使用“快速创建”在管理门户中创建配置文件，请参阅使用“快速创建”创建 Traffic Manager 配置文件。
配置负载平衡方法设置 - 在“快速创建”期间，你必须为配置文件选择负载平衡方法。在完成“快速创建”步骤之后，可以随时更改此设置。关于配置步骤，请参阅与负载平衡方法对应的主题：配置性能负载平衡, 配置故障转移负载平衡, 配置循环负载平衡.
备注“循环”负载平衡方法现在支持将网络流量进行加权分布。但是，目前必须使用 REST API 或 Windows PowerShell 配置权重。有关示例配置的详细信息，请参阅 Azure 博客中的 Azure Traffic Manager 外部终结点与通过 PowerShell 实施的加权循环法。 配置终结点 – 在执行“快速创建”期间无法配置终结点。在创建配置文件并指定负载平衡方法后，必须让 Traffic Manager 了解相应的终结点。
配置监视设置 – 在“快速创建”期间，监视设置无法配置。创建配置文件并指定负载平衡方法之后，你必须让 Traffic Manager 了解要监视的内容。有关配置监视的步骤，请参阅配置 Traffic Manager 监视。
测试 Traffic Manager 配置文件。测试你的配置文件和域是否按预期工作。有关如何执行此操作的信息，请参阅测试 Traffic Manager 设置。
将公司域名的 DNS 资源记录指向配置文件以使其生效。有关更多信息，请参见将公司 Internet 域指向 Traffic Manager 域。
使用图 1 中的示例，更改服务器上的 DNS 资源记录使其包含以下行，以便将公司域名指向 Traffic Manager 域名：
www.contoso.com IN CNAME contoso.trafficmanager.net
最佳实践
使前缀唯一并易于理解 – Traffic Manager 配置文件的 DNS 名称必须唯一。你只能控制 DNS 名称的第一部分。Traffic Manager 域名仅用于标识及定向客户端请求。客户端计算机将永远不会向最终用户显示这些名称。但是，配置文件由此域名标识，因此，你必须能够快速地将此域名与管理门 户中列出的其他域名区分开来。
使用点号来增强唯一性或使域名易读 – 也可以使用句点来分隔域名前缀部分。如果计划在 Traffic Manager 中创建多个策略，可使用一致的层次结构区分服务。例如，Contoso 拥有针对 Web、计费和实用工具管理的全局策略。这三个策略应为 web.contoso.trafficmanager.net、bill.contoso.trafficmanager.net 和 util.contoso.trafficmanager.net。设置云服务或网站时，请使用包含位置的名称。例如，web-us-contoso.cloudapp.net 和 web-asia-contoso.cloudapp.net。你将受限于 DNS 的各种限制。假定一个域名是一个点号分隔的标签序列（“标签.标签.标签.标签.等等”）。截至本文档撰写时，Traffic Manager 中域名的限制如下：
每个标签最多可以包含 63 个字符。
标签总数不能超过 40 个。因为 trafficmanager.net 占用两个标签，所以前缀可以使用 38 个。
整个域名最多只能包含 253 个字符。请注意，trafficmanager.net 占用了这些字符中的 19 个。
DNS TTL - DNS TTL 值控制客户端本地缓存名称服务器在 Azure Traffic Manager DNS 系统中查询已更新 DNS 条目的频率。Traffic Manager 中发生的任何更改（例如，配置文件更改或终结点可用性的更改）都需要经过这么长的时间才能在整个 DNS 服务器全局系统中刷新。建议保持该设置的默认值 300 秒（5 分钟）。指定的值越大，则 DNS 解析程序和客户端缓存 Traffic Manager DNS 响应的时间就越长，而这可以减少总体 DNS 查询延迟。但是，如果要求故障转移的速度很快，则最好是配置一个较小的值。
终结点应在单个订阅中 – 所有终结点均应在创建配置文件时所在的同一个订阅中。你可以从不同订阅将终结点作为外部终结点添加到配置文件，但当你禁用或删除关联的服务时，Azure 将不会自动删除这些终结点。因此，外部终结点将保留在 Traffic Manager 配置文件中，除非你手动删除它们，否则你将继续为它们付费。
仅限生产服务 - 只能使用生产环境中的终结点。不能定向到过渡环境中运行的终结点。请注意，如果你在配置文件定向流量时执行虚拟 IP (VIP) 地址交换，则流量将使用刚刚切换到生产环境中的终结点。
为终结点命名以便能够轻松识别终结点 – 仔细考虑你要使用的 DNS 前缀。之所以使用 DNS 名称，是因为它在订阅中肯定是唯一的，而云服务或网站的名称不一定唯一。为避免混淆，请为云服务或网站指定相同或相似的名称和 DNS 前缀。如果云服务和网站数量超过 20 个，命名不当会导致难以找到正确的终结点。此外，终结点命名不当会导致难以维护配置文件。
配置文件中的所有终结点应为相同的操作和端口提供服务 - 如果混用终结点，则客户端调用的终结点将更有可能无法为其请求提供服务。
配置文件中的所有云服务都必须使用相同的监视设置 – 只能选择单个路径和文件用于监视给定定义中的所有终结点。可以在“相对路径和文件名”文本框中输入“/”，使监视尝试访问默认路径和文件名。
发生临时更改时禁用终结点，而不是更改配置 – 在很多情况下，你可能想要使某个终结点脱机。只需在配置文件中禁用单个终结点，而不必从配置文件中删除相应的终结点。这样，该终结点仍保留在配置文件中， 但是，配置文件的行为看起来就像是该终结点不包含在其中一样。这种做法非常适合用于临时删除处于维护模式或者正在重新部署的终结点。在终结点启动并重新运 行后，你可以再次启用它。有关详细信息，请参阅禁用或启用终结点。
发生临时更改时禁用配置文件，而不是将它删除 – 你可能想要将整个配置文件脱机，而不只是将其中指定的单个终结点脱机。要这样做，请禁用配置文件。禁用配置文件时，配置文件的所有设置仍可在管理门户中进行编辑，当你要再次使用它时，也可以快速轻松地将配置文件重新联机。有关详细信息，请参阅禁用、启用或删除配置文件。
存储 – 使用 Traffic Manager 时，一个需要考虑的重要方面就是存储的位置和分布的设计方式。针对 Traffic Manager 设计和部署应用程序时，应考虑端到端事务以及数据将如何流动。
SQL Azure – 与存储设计类似，当你将终结点扩展到多个地理区域时，它可以分析应用程序状态和数据要求。
以上是Azure Traffic Manager的介绍和说明，通过以上说明，我们知道
他也有个很大的缺点，就是数据的同步。
不过，很适合应用在视频网站，和发布系统。
今天，进行了测试，测试的目标，主要测试能否适合（CS模式），我测试用的mysql（生产环境肯定不适合这种场景^_^），在单订阅中进行的测试：
1，先建云服务
2，建虚机，开放端口
3，安装服务，并安装web服务器，安装mysql服务器
4，创建Traffic Manager,设置完毕后，使用mysql客户端连接。
5，连接成功了。
这一步是完成了，不过我测试的不太理想，更新太慢了，检测服务下降不快，虽然可以调TTL？
但是
不知道在生产环境中如何，待测、、、、、
使用微软Traffic Manage---实验