『壹』 辦公雲終端機伺服器的配置請問如何配會好些呢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的方式被轉發到後端的兩台伺服器上。