负载平衡
负载平衡通过在服务器阵列上分发所处理的负载,以便没有一个服务器在工作中首当其冲。它同时还可能提供故障切换功能,以便将负载从失败的服务器切换至另一个功能正常的服务器。有几种方式可以实现负载平衡。它们包括:
域名服务 (DNS) 循环法
Windows 负载平衡服务
DNS 循环法
DNS 循环法的工作方式是通过整个 IP 地址列表而非一个 IP 地址应答 DNS 查询。执行查询的 Windows Media Player 通常选择第一个 IP 地址并在连接持续时间引用该服务器。要确保不反复选择同一个 IP 地址,则列表进行循环以便于每次不同的 IP 地址出现在列表顶端。
举一个例子,假设我们有三台服务器,其名称与 IP 地址分别是:
example.microsoft1.com 在 150.1.1.1
example.microsoft2.com 在 150.1.1.2
example.microsoft3.com 在 150.1.1.3
要设置服务器以便于客户请求通过循环法循环,使用多个 A 记录。(这些 DNS 记录将主机映射至 IP 地址。)在示例中,我们让访问该站点的所有客户都使用 example.microsoft.com 名称,除非这些请求在三个服务器间进行共享。我们将 A 记录设置如下:
example.microsoft.com.60 IN A 150.1.1.1
example.microsoft.com.60 IN A 150.1.1.2
example.microsoft.com.60 IN A 150.1.1.3
在每个 A 记录中 example.microsoft.com 名称末端的英文句点是强制性的,因为没有后缀点的名称有时被解释为与一些域关联而非与根目录关联,这就象没有前导斜杠的目录名经常被解释为与当前目录关联一样。后缀点表明域名是绝对的,即它被编写为与根目录关联。在我们的示例中的 TTL 域通知名称服务器 60 秒钟后将这些项从名称缓存中删除。以确保不将记录在不支持循环法的中间名称服务器上缓存过长的时间。
DNS 循环法的优势与局限
DNS 循环法的主要优势是简便又自由。添加记录时服务器池似乎为一个服务器,而事实上请求在池中的所有主机中循环进行。第一个局限是循环法实际上既不是负载共享技术也不是负载平衡技术。实际的负载平衡解决方案测量服务器上的负载,并判定发送客户请求的位置以便于平均分发工作。循环法不对服务器负载进行任何测量 - 只是在多个主机间交替执行客户请求,而不管服务器的能力。一个或多个主机可能会比其它主机得到更多的活动。第二个局限在于,如果一个服务器停机,来自客户的请求还会转到该 IP 地址,这些客户将无法收到正确响应。
Windows 负载平衡服务
Windows 负载平衡服务 (WLBS) 允许传入的 IP 通信动态地在多个服务器间进行分发。WLBS 透明地在主机间分发客户请求并让客户使用一个或多个虚拟 IP 地址访问池。从客户来看,池似乎是应答这些 IP 地址的唯一服务器。用户经常询问对 Windows Media 应使用 WLBS 还是 Microsoft Cluster Service(Microsoft 群集服务,MSCS):答案是使用 WLBS。如下面所讨论的,MSCS 用于数据集约型的应用程序如 Microsoft SQL Server?。
WLBS 服务器在它们之间进行通信以提供下列信息:
故障检测:WLBS 服务器发出“检测信号”,其它 WLBS 服务器将对其进行监视以确保整个服务器性能良好。如果服务器失败,则其它服务器进行调整并接管工作负荷。
负载平衡:WLBS 服务器使用分布式算法以统计方式映射工作负荷。主机相互之间进行通信以确定池的状态以及哪个主机可用于负载平衡。
可伸缩性:WLBS 可以缩放以满足各种服务的需要。随着通信的增加,只需将另一个服务器添加至池,在任何一个池中最多可能有 32 台服务器。
您可以在多个服务器(筛选为单一关系、没有关系或 C 类)上将 WLBS 配置为负载平衡。Windows Media Server 服务器的最佳选择(非无状态应用程序)是单一关系。当配置为单一关系时,所有使用 WLBS 虚拟 IP 地址传入的数据包锁定至 WLBS 群集中的指定节点。使用该群集 IP 地址客户处发送的每个数据包均连接至该节点。
Microsoft 群集服务 (MSCS)
MSCS 与数据集约型应用程序(如 SQL Server 和 Microsoft Exchange Server)一起使用。它不应用于负载平衡 Windows Media 服务。但是,可以将 WLBS 和 MSCS 技术一起使用以便为整个站点提供高度的可伸缩性与可用性。例如,数据库驱动型站点可以在 MSCS 群集上放置其数据库,MSCS 群集由 WLBS 群集的 HTTP 与基于 Windows Media 的服务器访问。该配置在数据库层提供高度可用性,在 Web/HTTP 层提供高度可伸缩性与可用性。
Windows Media Player HTTP 错误消息
在 Windows Media Player 运行时可能发生的网络错误消息是标准 HTTP 1.1 状态码,它在 RFC 2068 中定义。可以从下列位置获取:
ftp://ftp.isi.edu/in-notes/rfc2068.txt
最常见的代码是服务器错误消息,这些消息在 5xx 范围内,代表服务器发出已出错或无法处理请求的情况。这些代码如下表所列:代码
名称
含义
500
内部服务器错误
服务器遇到阻止它完成请求的意外情况。
501
未实现
服务器不支持完成请求所需要的功能。这是当服务器无法识别请求方法且无法支持它获取任何资源时的响应。
502
网关已坏
用作网关或代理的服务器,在试图完成请求时从所访问的上游服务器接收到无效响应。
503
服务不可用
由于临时超载或服务器维护的原因,服务器目前无法处理请求。意思为这是临时情况,经过一段延迟后会缓和。如果延迟长度已知,则它可能包含在之后重试 (Retry-After) 头文件中。如果未给定之后重试 (Retry-After),则客户应将本响应当作 500 个响应进行处理。
504
网关超时
用作网关或代理的服务器,在试图完成请求时不能从所访问的上游服务器及时接到响应。
505
不支持 HTTP 版本
服务器不支持或拒绝支持请求消息中所用的 HTTP 协议版本。服务器表明它无法或不愿意使用与客户相同的主版本来完成请求,如在 3.1 中所描述的,而不是使用该错误消息。响应应包含项说明不支持该版本的原因以及该服务器所支持的其它协议。
其它信息
有关 Windows Media 技术、软件下载以及到有关创建与部署内容的文章的链接的信息,请参见正式的 Windows Media 技术 Web 页:
http://www.microsoft.com/windows/windowsmedia
/en/default.asp
有关特定技术问题的答案,请使用 Microsoft Knowledge Base。它位于下列位置:
http://www.microsoft.com/support/kb.htm?RLD=32
还有一些公用新闻组用户可以进行订阅。它们是:
microsoft.public.windowsmedia.technologies
microsoft.public.windowsmedia.technologies.beta
microsoft.public.windowsmedia.technologies.rightsmanager.beta