‘壹’ 办公云终端机服务器的配置请问如何配会好些呢15台办公云终端需要什么配置
如果用传统VDI架构的云桌面，后端服务器的配置尘纯至少要2.3GHZ 2C4T*40=80C160T，内存的话4G*40=160G，需要160G内存。这样的配置对于服务器的投入成本也是比较大的。特别是VDI作为传统的云桌面架构对于后端服务器硬件性能的高要求，以老兄孙及对于网络带宽环境的高度依赖，给客户带来了较高的IT成本支出，用户体验也较差。考侍链虑到你这边现有这40台瘦客户机终端的性能配置还是挺高的，为什么不采用前端计算模式的云桌面架构把这40台瘦客户机的性能利用起来呢，这样还能省去后端服务器的投入成本。目前有一种叫VOI的云桌面技术架构模式，VOI的出现在一定程度上解决了目前VDI所不能解决的问题，例如以目前高校校园中的电子教室为例， 要承载一间一百台终端教室的服务器至少需要近十万元，而同样的场景下采用VOI方案则服务器的成本却不及它的五分之一。 在电子教室以及一些从事图形图像处理、工程图纸设计及渲染的机构中，VDI更加暴露出在视频重定向方面的不足，在播放高清视频、图形处理过程中出现花屏、白屏假死等情况，相反VOI在这个方面表现得更加理想与本机运行毫无差异。
‘贰’ 怎么一台nginx做前端 多台后端用apache
实现：
1.修改nginx配置文件，将php动态请求转发给apache
# cat /usr/local/nginx/conf/vhosts/test.conf
server
{
listen 80;
server_name www.test.com test.com;
index index.html index.htm index.php default.html default.htm default.php;
root /home/www/data/test;
access_log /usr/local/nginx/logs/test-access.log;
# nginx找不到文件时，转发请求给后端Apache
error_page 404 @proxy;
# 这是原来lnmp时，nginx自己将php请求提交到127.0.0.1:9000。现在由apache来处理，因此注释掉这段。
#location ~ .*\.(php|php5)?$
#{
# fastcgi_pass 127.0.0.1:9000;
# fastcgi_index index.php;
# include fastcgi.conf;
#}
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
{
expires 30d;
}
location ~ .*\.(js|css)?$
{
expires 12h;
}
# 动态文件.php请求转发给后端Apache
location ~ \.php$ {
# 向后端服务器发起请求时添加指定的header头信息
proxy_set_header Host $http_host;
# 向后端服务器发送真实 IP
proxy_set_header X-Real-IP $remote_addr;
# 让后端如php能直接通过变量获取真实IP
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:8080;
}
# nginx找不到文件时，转发请求给后端Apache
location @proxy {
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:8080;
}
}
然后只要开启nginx监听80端口，apache监听8080端口，开启php，就可以了。这边，我同时开启nginx，apache的访问日志。当我访问www.test.com/a.html,www.test.com/info.php时，nginx记录下了所有a.html,info.html的访问请求。
nginx访问日志
192.168.45.30 - - [19/Jun/2013:14:41:06 +0800] "GET /a.html HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36"
192.168.45.30 - - [19/Jun/2013:14:41:06 +0800] "GET /favicon.ico HTTP/1.1" 404 209 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36"
192.168.45.30 - - [19/Jun/2013:14:41:08 +0800] "GET /info.php HTTP/1.1" 200 10518 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36"
192.168.45.30 - - [19/Jun/2013:14:41:08 +0800] "GET /info.php?=PHPE9568F35-D428-11d2-A769-00AA001ACF42 HTTP/1.1" 200 2158 "http://www.test.com/info.php" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36"
192.168.45.30 - - [19/Jun/2013:14:41:08 +0800] "GET /info.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 HTTP/1.1" 200 2536 "http://www.test.com/info.php" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36"
192.168.45.30 - - [19/Jun/2013:14:41:08 +0800] "GET /favicon.ico HTTP/1.1" 404 209 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36"
192.168.45.30 - - [19/Jun/2013:14:41:09 +0800] "GET /info.php HTTP/1.1" 200 10518 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36"
当我访问www.test.com/a.html,www.test.com/info.php时，apache只记录了info.html的访问请求。说明nginx将php请求转发给了apache。这里可以看到来源都是127.0.0.1。而不是真实的来源ip。
apache访问日志
127.0.0.1 - - [19/Jun/2013:11:04:16 +0800] "GET /favicon.ico HTTP/1.0" 404 209
127.0.0.1 - - [19/Jun/2013:11:04:23 +0800] "GET /favicon.ico HTTP/1.0" 404 209
127.0.0.1 - - [19/Jun/2013:11:04:31 +0800] "GET /favicon.ico HTTP/1.0" 404 209
127.0.0.1 - - [19/Jun/2013:11:04:34 +0800] "GET /favicon.ico HTTP/1.0" 404 209
127.0.0.1 - - [19/Jun/2013:11:04:39 +0800] "GET /favicon.ico HTTP/1.0" 404 209
127.0.0.1 - - [19/Jun/2013:11:05:09 +0800] "GET /favicon.ico HTTP/1.0" 404 209
127.0.0.1 - - [19/Jun/2013:11:05:18 +0800] "GET /favicon.ico HTTP/1.0" 404 209
127.0.0.1 - - [19/Jun/2013:11:05:24 +0800] "GET /info.php HTTP/1.0" 200 55447
127.0.0.1 - - [19/Jun/2013:11:05:24 +0800] "GET /info.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 HTTP/1.0" 200 2524
127.0.0.1 - - [19/Jun/2013:11:05:24 +0800] "GET /info.php?=PHPE9568F35-D428-11d2-A769-00AA001ACF42 HTTP/1.0" 200 2146
127.0.0.1 - - [19/Jun/2013:11:05:24 +0800] "GET /favicon.ico HTTP/1.0" 404 209
2.apache添加mod_rpaf， 获取nginx转发过来的真实IP
mod_rpaf模块不是必须安装，除非你需要开启apache日志，但有多此一举之嫌，因为已经有nginx日志了，再开apache日志话就出现重复了。
Apache rpaf模块作用是获取Nginx转发过来的真实IP，否则在Apache日子中来访IP全部为127.0.0.1。
# wget http://stderr.net/apache/rpaf/download/mod_rpaf-0.6.tar.gz
# tar zxvf mod_rpaf-0.6.tar.gz
# cd mod_rpaf-0.6
# /usr/local/www/apache/bin/apxs -i -c -n mod_rpaf-2.0.so mod_rpaf-2.0.c
安装过程中，若出现error: 'conn_rec' has no member named 'remote_ip，请参考附录1.mod_rpaf-2.0.c error: 'conn_rec' has no member named 'remote_ip
# vim /usr/local/apache/conf/httpd.conf //在LoadMole后添加以下内容
LoadMole rpaf_mole moles/mod_rpaf-2.0.so
RPAFenable On
RPAFproxy_ips 127.0.0.1
RPAFsethostname On
RPAFheader X-Forwarded-For
‘叁’ nginx在做负载均衡时如何配置
1、下面的架构就是我们今天的演示结构，后端有两台服务器，分别是node1和node2，前端是一台web服务器，然后在web服务器上做负载均衡，将前端的访问流量导到后端的两个节点服务器上。三个服务器的IP地址分别是：web：192.168.1.210node1：192.168.1.211node2：192.168.1.212
2、按照这样的架构，在后端的node1和node2节点上分配配置好需要访问的网站，然后为了方便测试，我们将两个网站的主页分别改成下面的内容。便于区分访问的节点。
3、后端两个节点配置好以后，我们再来配置web服务器里的负载均衡配置，首先使用默认配置，先打开/etc/nginx/nginx.conf配置文件，在http区块里添加upstream块内容，及配置了两个后端服务器，后端负载均衡集群的名称是backend，记下这个名称。
4、然后再打开/etc/nginx/conf.d/default.conf这个配置文件，在server区块里，把location里面的内容改成图中所示内容。即将所有访问192.168.1.210的流量代理到后端的backend集群里。
5、配置文件配置好以后，使用nginx-t命令测试一下配置文件，保证配置文件是ok状态，然后执行nginx命令启动nginx服务器。
6、启动后在浏览器上输入前端web服务器的ip地址192.168.1.210，然后可以看到第一次是node1响应的，然后刷新一下以后，又变成了node2响应的。就这样实现了负载均衡的效果。由两个服务器分别响应，是因为默认的负载均衡算法是轮询算法，即两个节点轮流来。
7、然后我们还可以尝试一下加权轮询算法，即给不同的节点配置不同的权重，权重高一点的服务器，响应的多一些，权重第一点的响应少一些。加权轮询算法配置，在后端服务器后面加上权重值weight即可。配置好以后，执行nginx-t命令检测配置文件，确认无误后，执行nginx-sreload命令重新加载配置文件。
8、通过加权轮询的方式，我们无法通过手动一次次点击，最后来统计次数。但是我们可以使用自动化工具来统计。使用的工具是一款叫做httpd-tools的软件，安装好以后，提供了一个ab命令
9、然后我们来执行ab命令进行测试，常用的格式是：ab-n1000-c50http://localhost这个命令是在210服务器上执行的。表示一共执行1000次访问，每次发送50个请求。
10、然后我们登录到后端的node1服务器上，打开nginx的访问日志，从中可以看到ab命令测试的访问信息里，访问来源都是ApacheBench，因此可以通过可以来源来统计nginx响应的次数。命令是：grepApacheBenchaccess.log|wcnode1和node2节点上的统计结果分别是714和286，如下面图中所示，虽然没有达到5:2的权重比例，但是也非常接近了。说明这个配置生效了。
‘肆’ slb配置详解
我们一起来快速认识一下，负载均衡——SLB。负载均衡SLB是将访问流量根据转发策略分发到后端多台云服务器（ECS实例）的流量分发控制服务。包含两种含义：一是通过流量分发，扩展应用系统的服务能力；二是消除单点故障，提高应用系统的可用性。
应用场景
我们具体来看一看它的使用场景。
第一个使用场景的是用于高访问量的业务。
当你的应用访问量非常大，单台的服务器已经无法承载这个访问量的时候，就可以使用负载均衡，将流量分发到不同的服务器上去。
第二个场景是横向扩张系统。
当你已经使用了负载均衡，在业务有波动时可以在后端非常方便的添加和减少ECS来调整自己应用的服务能力。
第三个应用场景是消除单点故障。
当我们在使用负载均衡时，后端有多台ECS在同时工作的。一旦其中一台ECS上的应用发生了故障，那么负载均衡会通过一个健康检查的机制来及时的发现这个故障，并且能屏蔽对这台ECS的流量转发，然后将用户的请求转发到另一台正常工作的ECS实例上。
同城的容灾
阿里云负载均衡可以实现同地域多可用区之间同地域容灾，当主可用区出现故障是，可以在短时间内切换到另一备用可用区，以恢复服务能力。同时，主可用区恢复访问时，它会自动切换到主可用区。
跨地域容灾
跨地域容灾通过云解析做智能DNS，将域名解析到不同地域的负载均衡实例地址下，以实现全局负载均衡，当某个地域出现不可用时，暂停对应解析即可实现所有用户访问不受影响。
配置负载均衡
下面我们来演示一下负载均衡该如何去配置。
首先要做好准备工作，我们需要开通一台负载均衡实例和与负载均衡同一个地域的两台ECS服务器。
创建好以后，我们就可以在负载均衡的控制台看到这样一台实例了。
接下来，我们要给这个负载均衡创建一个监听。“监听”可以简单的理解为对应后端服务器里面的一个应用，比如一个网站我们来点击监听，然后点击添加监听。
假设我们的后端服务器里面有一个http的网站前端协议端口，我们可以将前后端协议端口TCP都写成80，然后根据自己的需要来选择调度算法，其实就是流量的转发方式。
下一步是健康检查，我们可以选择TCP方式。
健康检查端口会默认的和后端服务器的端口保持一致，直接确认就好了。现在，一个监听就配置好了。
接下来要去规定这台负载均衡的后端服务器是哪些。点击后端服务器，然后点击未添加服务器，将我们刚才创建的两台服务器勾选，然后批量添加就可以了。
这里有一个权重需要大家注意一下，这里的权重就是一个比例的概念，如果两台服务器写的都是100，流量将会以1:1的方式被转发到后端的两台服务器上。