负载均衡-相关

1、
网络负载平衡的工作原理

网络负载平衡的工作原理

网 络负载平衡使用两台或更多台一起工作的主机计算机组成的群集,为服务器提供了高可用性和高伸缩性。Internet 客户端使用一个 IP 地址或一组地址访问群集。客户端无法区别群集和单一服务器。服务器应用程序并不表明它们是在群集上运行的。但是,网络负载平衡群集与运行单个服务器应用程 序的单个主机有很大的区别,因为即使在某个群集主机发生故障的情况下,它也可以提供不间断服务。群集对客户端请求的响应也比单个主机快。

如 果某个主机发生故障或脱机,则网络负载平衡通过将传入的网络通信重定向到工作的群集主机,从而带来了高可用性。连到脱机主机的现有连接将丢失,但是 Internet 服务仍然是可用的。在多数情况下(例如,就 Web 服务器而言),客户端软件可以自动重试失败的连接,而且客户端在接收响应时,只有数秒钟的延迟。

网络负载平衡通过在分配给网络负载平衡群集 的一个或多个虚拟 IP 地址(群集 IP 地址)间分配传入的网络通信,从而带来了可变化的性能。然后,群集中的主机同时对不同的客户端请求甚至来自同一客户端的多个请求做出响应。例如,Web 浏览器可以从网络负载平衡群集中的不同主机获得所有单张网页中的多幅图像。这就提高了处理速度,并缩短了对客户端做出响应的时间。

网络负载平衡使得单个子网上的所有群集主机可以同时检测群集 IP 地址的传入网络通信。在每个群集主机上,网络负载平衡驱动程序充当群集适配器驱动程序和 TCP/IP 堆栈间的过滤器,以便在主机间分配通信。

网 络负载平衡采用一种完全分布式的算法,根据传入客户端的 IP 地址和端口,以统计方式将其映射到群集主机。此进程的发生不需要主机间进行任何通信。当发现到达的数据包时,所有主机同时执行这种映射,以快速确定哪个主 机应当处理这个程序包。这种映射一直保持不变,直到群集主机数发生更改时为止。与集中式负载平衡应用程序相比,网络负载平衡筛选算法处理数据包的效率更 高,因为前者必须修改和重新传送数据包。

群集通信的分配

网 络负载平衡通过以下方式,控制从 Internet 客户端到群集中选定主机的 TCP 和 UDP 通信的分配:配置好网络负载平衡后,群集中的所有主机都接收传到群集 IP 地址的传入客户端请求。网络负载平衡筛选传到指定 TCP 和 UDP 端口的传入数据报,之后这些数据报才会到达 TCP/IP 协议软件。网络负载平衡在 TCP/IP 内管理 TCP 和 UDP 协议,从而逐个端口地控制其操作。

在多播模式下,网络负载平衡可以提供 Internet 组管理协议 (IGMP) 支持,限制交换流。除了指定端口的 TCP 和 UDP 通信以及多播模式中的 IGMP 通信,网络负载平衡不控制任何传入 IP 通信。它并不筛选其他 IP 协议(例如,ICMP 或 ARP),但是下述情况除外。请注意,当使用群集 IP 地址时,应当会看到来自特定点对点 TCP/IP 应用程序(例如 ping)的重复响应。如果需要,这些应用程序可以将专用 IP 地址用于每个主机,以避免这种操作。

聚合

为了协调其操作,网络负载平衡主机在群集内周期性地交换检测信号(详细信息,请参阅Internet 组管理协议 (IGMP))。 IP 多播允许主机监控群集状态。当群集状态更改时(例如当主机发生故障、离开或加入群集时),网络负载平衡将调用称作“聚合”的过程,在该过程中,主机交换数 量有限的消息,以确定群集的新的一致状态,并为主机指定最高主机优先级,即作为新的默认主机。当所有群集主机在正确的新群集状态下取得一致后,它们将在 Windows 事件日志中记录聚合的完成。完成这个过程一般用不了 10 秒种。

在聚合过程中,其余主机继续处理传入的网络通信。对工作 主机的客户端请求不受影响。完成聚合后,将以故障主机为目标的通信重新分发给仍在工作的主机。经过负载平衡后的通信将在仍在工作的主机间得到重新划分,以 便尽可能好地实现特定 TCP 或 UDP 端口的新的负载平衡。

如果向群集添加了一个主机,则聚合允许该主机接收自己那份经过负载平衡的 通信。群集的扩展不影响正在进行的群集操作,而且其实现过程对 Internet 客户端和服务器应用程序都是透明的。但是,当选择了“客户端相似性”时,它可能影响跨多个 TCP 连接的客户端会话,因为可能会将客户端重映射到连接间的不同群集主机。有关相似性的详细信息,请参阅网络负载平衡和状态可控的连接

网络负载平衡假定,主机在群集内正常工作的时间与它同其他群集主机交换检测信号的时间一样长。如果在多次检测信号交换中,其他主机都没有接收到来自任何成员的响应,则它们将启动聚合,重新分发本来应由失败主机处理的负载。

对于消息交换时段以及启动聚合所需的丢失的消息数,您都可以进行控制。默认值设置分别为 1000 毫秒(1 秒)和 5 个丢失的消息交换时段。由于一般都不修改这些参数,所以无法通过“网络负载平衡属性”对话框配置它们。必要时,可以在注册表中手动调整它们。调整聚合参数对完成此操作的过程进行了描述。

2、

ASP.NET 提供一个简单、易于使用的会话状态模型,您可以使用该模型跨多个 Web 请求存储任意数据和对象。它使用基于字典的、内存中的对象引用(这些对象引用存在于 IIS 进程中)缓存来完成该操作。使用进程内会话状态模式时请考虑下面的限制:

使用进程内会话状态模式时,如果 aspnet_wp.exe 或应用程序域重新启动,则会话状态数据将丢失。这些重新启动通常会在下面的情况中发生:

在应用程序的 Web.config 文件的 <processModel> 元素中,设置一个导致新进程在条件被满足时启动的属性,例如 memoryLimit。

修改 Global.asax 或 Web.config 文件。

更改到 Web 应用程序的 Bin 目录。

用杀毒软件扫描并修改 Global.asax 文件、Web.config 文件或 Web 应用程序的 Bin 目录下的文件。

如果在应用程序的 Web.config 文件的 <processModel> 元素中启用了网络园模式,请不要使用进程内会话状态模式。否则将发生随机数据丢失。

还有这二种:

一:在第一个页面置了http://www.dotnet247.com/247reference/msgs/58/290316.aspx

Asp.net 默认配置下,Session莫名丢失的原因及解决办法

正常操作情况下Session会无故丢失。因为程序是在不停的被操作,排除Session超时的可能。另外,Session超时时间被设定成60分钟,不会这么快就超时的。

这次到CSDN上搜了一下帖子,发现好多人在讨论这个问题,然后我又google了一下,发现微软网站上也有类似的内容。

现在我就把原因和解决办法写出来。

原因:

由于Asp.net程序是默认配置,所以Web.Config文件中关于Session的设定如下:

<sessionState mode='InProc' stateConnectionString='tcpip=127.0.0.1:42424' sqlConnectionString='data source=127.0.0.1;Trusted_Connection=yes' cookieless='true' timeout='60'/>我们会发现sessionState标签中有个属性mode,它可以有3种取值:InProc、StateServer?SQLServer(大小写敏感) 。默认情况下是InProc,也就是将Session保存在进程内(IIS5是aspnet_wp.exe,而IIS6是W3wp.exe),这个进程不稳定,在某些事件发生时,进程会重起,所以造成了存储在该进程内的Session丢失

哪些情况下该进程会重起呢?微软的一篇文章告诉了我们:

1、配置文件中processModel标签的memoryLimit属性

2、Global.asax或者Web.config文件被更改

3、Bin文件夹中的Web程序(DLL)被修改

4、杀毒软件扫描了一些.config文件。

更多的信息请参考PRB: Session variables are lost intermittently in ASP.NET applications

解决办法:

前面说到的sessionState标签中mode属性可以有三个取值,除了InProc之外,还可以为StateServer、SQLServer。这两种存Session的方法都是进程外的,所以当aspnet_wp.exe重起的时候,不会影响到Session

现在请将mode设定为StateServer。StateServer是本机的一个服务,可以在系统服务里看到服务名为ASP.NET State Service的服务,默认情况是不启动的。当我们设定mode为StateServer之后,请手工将该服务启动。

这样,我们就能利用本机的StateService来存储Session了,除非电脑重启或者StateService崩掉,否则Session是不会丢的(因Session超时被丢弃是正常的)。

除此之外,我们还可以将Session通过其他电脑的StateService来保存。具体的修改是这样的。同样还在sessionState 标签中,有个stateConnectionString='tcpip=127.0.0.1:42424'属性,其中有个ip地址,默认为本机 (127.0.0.1),你可以将其改成你所知的运行了StateService服务的电脑IP,这样就可以实现位于不同电脑上的Asp.net程序互通Session了。

如果你有更高的要求,需要在服务期重启时Session也不丢失,可以考虑将mode设定成SQLServer,同样需要修改sqlConnectionString属性。关于使用SQLServer保存Session的操作,请访问这里。

在使用StateServer或者SQLServer存储Session时,所有需要保存到Session的对象除了基本数据类型(默认的数据类型,如int、string等)外,都必须序列化。只需将[Serializable]标签放到要序列化的类前就可以了。

asp中Session的工作原理:

asp的Session是具有进程依赖性的。ASP Session状态存于IIS的进程中,也就是inetinfo.exe这个程序。所以当inetinfo.exe进程崩溃时,这些信息也就丢失。另外,重起或者关闭IIS服务都会造成信息的丢失。

asp.net Session的实现

asp.net的Session是基于HttpModule技术做的,HttpModule可以在请求被处理之前,对请求进行状态控制,由于Session本身就是用来做状态维护的,因此用HttpModule做Session是再合适不过了。

原因1:

bin目录中的文件被改写,asp.net有一种机制,为了保证dll重新编译之后,系统正常运行,它会重新启动一次网站进程,这时就会导致Session丢失,所以如果有access数据库位于bin目录,或者有其他文件被系统改写,就会导致Session丢失

原因2:(这种情况较多)

文件夹选项中,如果没有打开“在单独的进程中打开文件夹窗口”,一旦新建一个窗口,系统可能认为是新的Session会话,而无法访问原来的Session,所以需要打开该选项,否则会导致Session丢失

原因3:

似乎大部分的Session丢失是客户端引起的,所以要从客户端下手,看看cookie有没有打开

原因4:

Session的时间设置是不是有问题,会不会因为超时造成丢失

原因5:

IE中的cookie数量限制(每个域20个cookie)可能导致session丢失

原因6:

使用web garden模式,且使用了InProc mode作为保存session的方式

解决丢失的经验

1. 判断是不是原因1造成的,可以在每次刷新页面的时候,跟踪bin中某个文件的修改时间

2. 做Session读写日志,每次读写Session都要记录下来,并且要记录SessionID、Session值、所在页面、当前函数、函数中的第几次Session操作,这样找丢失的原因会方便很多

3. 如果允许的话,建议使用state server或sql server保存session,这样不容易丢失

4. 在global.asa中加入代码记录Session的创建时间和结束时间,超时造成的Session丢失是可以在SessionEnd中记录下来的。

5. 如果有些代码中使用客户端脚本,如javascript维护Session状态,就要尝试调试脚本,是不是因为脚本错误引起Session丢失

posted @ 2009-11-20 17:39  EastFuture  阅读(773)  评论(0编辑  收藏  举报