一、部署环境
1、两台WEB服务器,一台数据库服务器;其中一台.net32位,一台.net64位。
2、一台LINUX主机。
3、Negix做负载均衡。
4、Session状态服务器设置在安装有.net64位机器上,也是启动了64位的asp.net state服务。
二、本次部署目标
1、将系统部署到两台机器,并用negix做负载均衡,并使用反向代理。
其中三个使用虚拟目录形式,三个使用网站形式(图片服务器,两个应用网站),一个WCF服务;
所有网站均为MVC框架的ASP.NET应用程序。
2、负载均衡后的多系统共享同一个Session服务器。(未来将扩展到memcache存储)
即Session Mode="StateServer"
3、单点登录各应用系统。
此次使用WCF服务存储客户信息到IIS进程。(未来将扩展到memcache存储)
三、部署过程
1、负载均衡与反向代理由运维人员实现。
采用Linux+negix实现。
注:negix同时具有负载均衡与反向代理的功能,之前是使用sqluid实现反向代理。
2、应用系统编译与发布由运维人员实现。
采用CC.Net编译并发布应用系统。
注:这个工具对项目结构非常严格,VS项目中,有一些未包含的文件以及黄色叹号的文件最终都会影响编译结果。
(1)如果带有黄色叹号文件下,CC.Net编译与发布会显示成功,但发布后的文件却是被黄色叹号文件中断了,
因此发布后的目录会缺少某些文件。
(2)未包含的文件,CC.Net也是不会发布的,当然,这跟VS工具的发布是一样的原理。
3、测试过程。
测试过程中发生了一系列的问题。
四、测试问题汇总
1、由于采用了Session StateServer,又使用了负载均衡,所以在不同IP访问Session时,设置上必须增加加密配置节。单台服务器可不增加该配置节,如下:machineKey。
<sessionState mode="StateServer" stateConnectionString="tcpip=192.168.1.20:42424" stateNetworkTimeout="14400" cookieless="false" timeout="240" />
<machineKey validationKey="78AE3850338BFADCE59D8DDF58C9E4518E7510149C46142D7AAD7F1AD49D95D4" decryptionKey="5FC88DFC24EA123C" validation="SHA1" />
2、同样,由于使用了负载均衡,WCF服务也被运维人员设置了负载均衡,但单点登录信息是存储在IIS进程中的,因此在每个请求被负载均衡后,调用的WCF服务也不一样了,所以不能正常获取用户信息。
(1)之前是这样设置WCF服务调用127.0.0.1:8080/service.svc
(2)经修改后为192.168.1.20:8080/service.svc
所有应用系统都指向同一个wcf服务,并且使用固定的IP,而不是使用127.0.0.1。
注:这里有个怪问题,在使用方式一时,即127.0.0.1时,有时也是能获取的,不知道这负载均衡搞了什么东东。
3、使用了Session StateServer时,对象存储必须是可序列化。
4、业务公共组件的版本问题。
由于使用了负载均衡,运维人员将HTTP500,501,502都设置为不显示具体错误信息,因此带来调试上的麻烦,没有及时发现业务公共组件的错误。(还是在服务器上直接运行应用系统才发现该问题)
写到这里,还有一个问题未解决:
即将单点登录部署为虚拟目录时,Sesssion StateServer设置后,单点登录进行同目录,不同文件转向时,不能获取上一个页面设置的Session,比较郁闷,先写到这里,WC去,一会回来看看虚拟目录问题。还有这个是HTTPS环境。不知是否有关系。
莫名其妙,经过一番折腾,虚拟目录与网站形式都可以了。目前可以,但要经过几天的测试使用后,才能完全确定。
本次的经验教训:
1、因为配置文件由运维人员做具体设置,因此有些地方过于信任运维人员,而Session的状态服务器形式也是第一次用,因此没有怀疑运维人员的设置,而怀疑是程序问题,在程序上花费了不少测试时间,包含做测试网站,并配置测试网站。然后才真正怀疑配置问题,才上MSDN查找官方具体配置详细说明,才发现,在不同的服务器访问同一个Session需要使用machineKey。
看来有些时候,仍然需要自己去确定配置,而不总是信任运维人员。
2、自身的问题。由于在查找虚拟目录的过程中,不知道从哪操作,比如:IIS设置session或者web.config直接修改,而导致session的mode="StateServer"配置信息丢失了,然后网站的方式也不行了,就不停的在查找解决方法,因为上午可以,而又信任自己没有修改配置,结果就导致了几个小时都在看技术文章,GOOGLE搜索相关问题,从而浪费了不少时间,直到同事过来一起讨论,才把整个解决问题的思路建立起来,因为之前创建的测试网站是没有问题的,所以从配置文件入手,最后发现少了stateserver配置信息,狂晕,我那个郁闷啊。。。。。。。
看来有些时候,仍然不能过于信任自己之前的一些行为。过于信任自己之前的行为,导致了思路的不清晰,最终花费了大量时间。