StoreFront的配置及NetScaler对StoreFront进行负载均衡的配置
在配置NetScaler对StoreFront进行负载均衡之前，首先需要将StoreFront配置完毕。
在设置StoreFront的时候，首先仍然是配置SSL证书，这个步骤最好在建立StoreFront站点之前进行，否则后面会有些不必要的步骤。StoreFront的证书配置过程同DDC的证书配置过程完全一样，通过IIS控制台申请证书或者导入已经准备好的证书，然后将该证书同443端口进行绑定。所以今天的更新会从建立StoreFront站点开始，而且本次内容仅仅是将StoreFront配置为进行负载均衡的状态。后期将StoreFront配置为接受NetScaler Gateway发送过来的请求的过程将和NetScaler Gateway的内容一起更新，因为这中间涉及到是否构建VPN通道的问题，而且我也没有把实验进行到那一步。
首先启动StoreFront的控制台（启动时间可能有点长，这个毛病从WebInterface开始就有，一直没变）。StoreFront控制台加载完毕之后，点击“Create a New Deployment"，建立第一个站点，
1.jpg (166.76 KB)
2015-1-18 13:14
在站点部署向导的页面，默认会使用StoreFront的FQDN作为Base Store。但是前端有NetScaler作负载均衡的话，这里需要使用负载均衡的虚拟服务器的地址（在后面NetScaler上面进行配置）， 
2.jpg (378.64 KB)
2015-1-18 13:14
3.jpg (379.13 KB)
2015-1-18 13:14
在设置Store Name的窗口，填入站点所用的Store名称，这个名称在后面的NetScaler的负载均衡监视器上会用到， 
4.jpg (174.26 KB)
2015-1-18 13:14
在添加Delivery Controller的页面，填入之前一次更新内容中配置的DDC负载均衡器的FQDN，（如果没有负载均衡器，这里需要将所有的DDC的FQDN填进去）， 
5.jpg (393.63 KB)
2015-1-18 13:14
6.jpg (394.74 KB)
2015-1-18 13:14
7.jpg (397.88 KB)
2015-1-18 13:14
8.jpg (182.75 KB)
2015-1-18 13:14
构建VPN通道页面，这个暂时使用默认选项，待到NetScaler Gateway阶段的内容再配置。 
9.jpg (175.42 KB)
2015-1-18 13:14
后面点击”Finish“，完成站点的创建过程。 
10.jpg (169.31 KB)
2015-1-18 13:14
站点创建完毕之后，点击StoreFront左侧栏目的”Server Group“，然后再”Server Group“页面右侧点击”Generate Security Key“， 
11.jpg (353.46 KB)
2015-1-18 13:14
点击”Generate Keys"，重新生成一个密钥（这个是Citrix的Best Practice，其实使用现成的Key也可以），
12.jpg (369.46 KB)
2015-1-18 13:14
13.jpg (170.85 KB)
2015-1-18 13:14
完成之后，点击右侧栏目的“Add Server”， 
14.jpg (368.43 KB)
2015-1-18 13:14
记住授权服务器名称与授权码，并且保持这个窗口开启状态不要关闭，直至所有StoreFront加入到该Server Group中，
15.jpg (373.87 KB)
2015-1-18 13:14
打开第二台StoreFront的控制台，选择“Join existing server group”
16.jpg (379.69 KB)
2015-1-18 13:14
填入第一台StoreFront控制台上面的授权服务器名称及授权码， 
17.jpg (388.07 KB)
2015-1-18 13:14
确认之后等待服务器完成配置并将站点信息下载到本地， 
18.jpg (176.13 KB)
2015-1-18 13:14
19.jpg (177.66 KB)
2015-1-18 13:14
回到第一台StoreFront，检查Server Group的信息， 
20.jpg (171.56 KB)
2015-1-18 13:14
21.jpg (174.8 KB)
2015-1-18 13:14
到这一步，StoreFront的上面的准备工作就已经结束了。在这之后，如果StoreFront的配置有变动，只需要在第一台StoreFront配置变动完成之后使用“Propagate Changes”选项，就能将变动之后的配置推送到Server Group中的其他StoreFront上面。（我个人觉得这是StoreFront相对于WebInterface最大的一个进步。在WI的年代，你需要手动配置每一个WI。而且最要命的是，你需要为内网和外网配置不同的站点，并且保持它们之间的一致性。） 
22.jpg (381.39 KB)
2015-1-18 13:14
下午出去happy了，晚上回来再更新剩下的这次内容。
回来啦，继续今天的内容：
下午把StoreFront的准备工作部署完成，接下来就是NetScaler的配置了。与DDC的负载均衡配置类似，在创建StoreFront的负载均衡器时，主要的区别在于监视器的设置。DDC的监视器并不需要配置特殊字段，因为负载均衡器检查的是DDC的服务，不同的DDC所使用的服务都是相同的，在字段的监视上并没有区别。但是StoreFront是一个Web应用，一个StoreFront上面可能有多个站点store，所以在监视器上需要配置对应的store名称，否则监视器会因为无法获得相应的字段信息而把后端的StoreFront站点标记为Fail。
下面开始具体的配置步骤，仍然是先建立后端的服务器信息，
1.jpg (346.5 KB)
2015-1-18 23:13
2.jpg (158.13 KB)
2015-1-18 23:13
3.jpg (166.53 KB)
2015-1-18 23:13
4.jpg (158.22 KB)
2015-1-18 23:13
5.jpg (380.72 KB)
2015-1-18 23:13
然后是创建StoreFront的监视器，这里需要在”Special Parameter"里加入对应的站点store的名称，注意图中标记感叹号的地方 
6.jpg (413.94 KB)
2015-1-18 23:13
7.jpg (361.07 KB)
2015-1-18 23:13
8.jpg (311.62 KB)
2015-1-18 23:13
9.jpg (352.72 KB)
2015-1-18 23:13
10.jpg (396.21 KB)
2015-1-18 23:13
11.jpg (398.89 KB)
2015-1-18 23:13
监视器设置完成之后，继续创建每一个StoreFront对应的负载均衡服务， 
12.jpg (380.69 KB)
2015-1-18 23:13
13.jpg (359.41 KB)
2015-1-18 23:13
14.jpg (349.79 KB)
2015-1-18 23:13
15.jpg (397.38 KB)
2015-1-18 23:13
16.jpg (329.69 KB)
2015-1-18 23:13
17.jpg (329.19 KB)
2015-1-18 23:13
18.jpg (379.34 KB)
2015-1-18 23:13
19.jpg (328.35 KB)
2015-1-18 23:13
20.jpg (149.82 KB)
2015-1-18 23:13
21.jpg (375.33 KB)
2015-1-18 23:13
22.jpg (380.1 KB)
2015-1-18 23:13
23.jpg (302.12 KB)
2015-1-18 23:13
24.jpg (317.1 KB)
2015-1-18 23:13
25.jpg (382.95 KB)
2015-1-18 23:13
26.jpg (301.36 KB)
2015-1-18 23:13
27.jpg (318.33 KB)
2015-1-18 23:13
28.jpg (375.04 KB)
2015-1-18 23:13
29.jpg (369.02 KB)
2015-1-18 23:13
完成所有StoreFront的负载均衡服务的配置， 
30.jpg (365.24 KB)
2015-1-18 23:13
负载均衡服务配置完毕之后，创建StoreFront的负载均衡虚拟服务器，注意负载均衡器的名称需要与之前在StoreFront服务器上建立的站点的Store的FQDN对应。 
31.jpg (350.01 KB)
2015-1-18 23:13
32.jpg (527.99 KB)
2015-1-18 23:13
33.jpg (402.92 KB)
2015-1-18 23:13
34.jpg (378.34 KB)
2015-1-18 23:13
35.jpg (421.44 KB)
2015-1-18 23:13
36.jpg (373.9 KB)
2015-1-18 23:13
37.jpg (400.63 KB)
2015-1-18 23:13
38.jpg (374.51 KB)
2015-1-18 23:13
39.jpg (416.76 KB)
2015-1-18 23:13
40.jpg (432.02 KB)
2015-1-18 23:13
41.jpg (371.78 KB)
2015-1-18 23:13
42.jpg (390.59 KB)
2015-1-18 23:13
43.jpg (430.02 KB)
2015-1-18 23:13
44.jpg (373.7 KB)
2015-1-18 23:13
45.jpg (393.48 KB)
2015-1-18 23:13
46.jpg (371.77 KB)
2015-1-18 23:13
47.jpg (426.38 KB)
2015-1-18 23:13
由于这次是对StoreFront进行负载均衡，而StoreFront是一个Web应用，我们需要对它的负载均衡的方式以及用户会话保持功能进行配置。
首先得负载均衡的方式，在负载均衡的方式的选择上，我的实验并不代表的所有生产环境的要求，只是一种比较典型的要求。生产环境的配置需要根据自身的应用的要求来设置。实验过程当中选择了“源IP校验”，效果就是如果客户端的request数据包中包含了同一个源IP地址，那么将所有包含了这个源IP地址的request请求分发到同一台StoreFront服务器，将不同源IP的request请求分发到不同的StoreFront服务器。 
48.jpg (427.55 KB)
2015-1-18 23:54
49.jpg (424.73 KB)
2015-1-18 23:54
50.jpg (410.03 KB)
2015-1-18 23:54
之后是用户会话保持选项。原则上来说，用户会话保持与负载均衡是相对立的。负载均衡是客户端请求的分发，而用户会话保持是客户端请求的归递。在负载均衡器对用户请求的分发优先级上，会话保持选项的优先级会高于负载均衡的方式，如果命中用户会话保持，那么NetScaler会按照会话保持的设定去执行，而不再执行负载均衡的方式。在这个实验过程中，用户会话保持的选择同样是源IP，好处就是客户端请求如果是分发到同一台StoreFront服务器，那么可以省去用户身份的验证过程，加速用户的体验。 
51.jpg (422.99 KB)
2015-1-18 23:54
52.jpg (428.36 KB)
2015-1-18 23:54
53.jpg (411.03 KB)
2015-1-18 23:54
54.jpg (424.99 KB)
2015-1-18 23:54
创建完成之后，如下图 
55.jpg (406.25 KB)
2015-1-18 23:54
创建好StoreFront的负载均衡器之后，为负载均衡器的FQDN添加DNS记录，这样StoreFront的负载均衡器就完全上线运行了。 
56.jpg (355.97 KB)
2015-1-18 23:54
之后，测试一下，通过StoreFront负载均衡器的地址能否到达后端的StoreFront服务器 
57.jpg (295.29 KB)
2015-1-18 23:54
58.jpg (433.95 KB)
2015-1-18 23:54
通过上面的2个图片能够得知，通过StoreFront负载均衡器的URL是能够到达并获取StoreFront服务器的页面的，而且SSL通信的443端口是建立在负载均衡器的IP地址上的。
至此，StoreFront的负载均衡配置过程就完成了。在面对Web应用的负载均衡方式与用户会话保持上面，会有很大的选择余地，用户需要从自身出发来进行选择。并且这2块的配置都不是单选，用户可以配置多个负载均衡的方式和用户会话保持的选择，通过不同的优先级和权重设置，NetScaler会作出相应的选择。同样在监视器的设置上面也不是单选的，用户可以为一个负载均衡服务添加多个监视器来对后端的实际应用或服务进行健康检查。实验过程仅仅是让大家能够初步的了解NetScaler的工作和配置方式，负载均衡器的配置中，大量的工作内容都是证书及监视器的正则表达式的建立，而这些内容都是自定义的，无法为大家进行演示，都需要自己去摸索，甚至向后线的Web开发工程师请教相应的页面关键字段来编辑表达式。
今天的更新就完结了
本文转自sandshell博客51CTO博客，原文链接http://blog.51cto.com/sandshell/1967612如需转载请自行联系原作者
sandshell
276
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
