對于防火墻的選擇:
  http://blog.sina.com.cn/s/blog_92dc41ea0101j5l1.html

  http://www.lupaworld.com/article-218506-1.html

2,創建索引和鍵的限制：

(1),在列上創建索引長度超過3072bytes會成功，但是只能使用索引的前3072bytes。并且會顯示警告信息"specified key was too long,max key lenght is 3072 keys"

不支持的特征

1，在NDB創建create table時，一定要指定tablespace.

For NDB tables, beginning with MySQL Cluster NDB 6.2.5 and MySQL Cluster NDB 6.3.2, it is also possible to specify whether the column is stored on disk or in memory by using a STORAGE clause. STORAGE DISK causes the column to be stored on disk, and STORAGE MEMORY causes in-memory storage to be used. The CREATE TABLE statement used must still include a TABLESPACE clause:

mysql> CREATE TABLE t1 (
    ->     c1 INT STORAGE DISK,
    ->     c2 INT STORAGE MEMORY
    -> ) ENGINE NDB;
ERROR 1005 (HY000): Can't create table 'c.t1' (errno: 140)

mysql> CREATE TABLE t1 (
    ->     c1 INT STORAGE DISK,
    ->     c2 INT STORAGE MEMORY
    -> ) TABLESPACE ts_1 ENGINE NDB;
Query OK, 0 rows affected (1.06 sec)

//NDB參數解釋  ---from 《mysql性能調優和架構設計》

1) [NDBD DEFAULT]中的配置項：
NoOfReplicas：定義在Cluster 環境中相同數據的分數，通俗一點來說就是每一份數據存放NoOfReplicas 份。如果希望能夠冗余，那么至少設置為2（一般情況來說此參數值設置為2 就夠了），最大只能設置為4。另外，NoOfReplicas 值得大小，實際上也就是nodegroup 大小的定義。NoOfReplicas 參數沒有系統默認值，所以必須設定，而且只能設置在[NDBD DEFAULT]中，因為此數值在整個Cluster 集群中一個node group 中所有的NDBD 節點都需要一樣。另外NoOfReplicas 的數目對整個Cluster 環境中NDB 節點數量有較大的影響，因為NDB 節點總數量是NoOfReplicas * 2 * node_group_num；DataDir：指定本地的pid 文件，trace 文件，日志文件以及錯誤日志子等存放的路徑，無系統默認地址，所以必須設定；

DataMemory：設定用于存放數據和主鍵索引的內存段的大小。這個大小限制了能存放的數據的大小，因為ndb 存儲引擎需屬于內存數據庫引擎，需要將所有的數據（包括索引）都load 到內存中。這個參數并不是一定需要設定的，但是默認值非常小（80M），只也就是說如果使用默認值，將只能存放很小的數據。參數設置需要帶上單位，如512M，2G 等。另外，DataMemory 里面還會存放UNDO 相關的信息,所以，事務的大小和事務并發量也決定了DataMemory 的使用量，建議盡量使用小事務；

IndexMemory：設定用于存放索引（非主鍵）數據的內存段大小。和DataMemory類似，這個參數值的大小同樣也會限制該節點能存放的數據的大小，因為索引的大小是隨著數據量增長而增長的。參數設置也如DataMemory 一樣需要單位。IndexMemory 默認大小為18M；實際上，一個NDB 節點能存放的數據量是會受到DataMemory 和IndexMemory 兩個參數設置的約束，兩者任何一個達到限制數量后，都無法再增加能存儲的數據量。如果繼續存入數據系統會報錯“table is full”。

FileSystemPath：指定redo 日志，undo 日志，數據文件以及meta 數據等的存放位置，默認位置為DataDir 的設置，并且在ndbd 初始化的時候，參數所設定的文件夾必須存在。在第一次啟動的時候，ndbd 進程會在所設定的文件夾下建立一個子文件夾叫ndb_id_fs，這里的id 為節點的ID 值，如節點id 為3 則文件夾名稱為ndb_3_fs。當然，這個參數也不一定非得設置在[NDBD DEFAULT]參數組里面讓所有節點的設置都一樣（不過建議這樣設置），還可以設置在[NDBD]參數組下為每一個節點單獨設置自己的FileSystemPath值；

BackupDataDir：設置備份目錄路徑，默認為FileSystemPath/BACKUP。接下來的幾個參數也是非常重要的，主要都是與并行事務數和其他一些并行限制有關的參數設置。
MaxNoOfConcurrentTransactions：設置在一個節點上面的最大并行事務數目，默認為4096，一般情況下來說是足夠了的。這個參數值所有節點必須設置一樣，所以一般都是設置在[NDBD DEFAULT]參數組下面；

MaxNoOfConcurrentOperations：設置同時能夠被更新（或者鎖定）的記錄數量。一般來說可以設置為在整個集群中相同時間內可能被更新（或者鎖定）的總記錄數，除以NDB節點數，所得到的值。

MaxNoOfLocalOperations：此參數默認是MaxNoOfConcurrentOperations * 1.1的大小，也就是說，每個節點一般可以處理超過平均值的10%的操作記錄數量。但是一般來說，MySQL 建議單獨設置此參數而不要使用默認值，并且將此參數設置得更較大一些；

以下的三個參數主要是在一個事務中執行一條query 的時候臨時用到存儲（或者內存）的情況下所使用到的，所使用的存儲信息會在事務結束（commit 或者rollback）的時候釋放資源；

MaxNoOfConcurrentIndexOperations：這個參數和MaxNoOfConcurrentOperations參數比較類似，只不過所針對的是Index 的record 而已。其默認值為8192，對伊一般的系統來說都已經足夠了，只有在事務并發非常非常大的系統上才有需要增加這個參數的設置。當然，此參數越大，系統運行時候為此而消耗的內存也會越大；

MaxNoOfFiredTriggers：觸發唯一索引（hash index）操作的最大的操作數，這個操作數是影響索引的操作條目數，而不是操作的次數。系統默認值為4000，一般系統來說夠用了。當然，如果系統并發事務非常高，而且涉及到索引的操作也非常多，自然也就需要提高這個參數值的設置了；

TransactionBufferMemory：這個buffer 值得設置主要是指定用于跟蹤索引操作而使用的。主要是用來存儲索引操作中涉及到的索引key 值和column 的實際信息。這這個參數的值一般來說也很少需要調整，因為實際系統中需要的這部分buffer 量非常小，雖然默認值只是1M，但是對于一般應用也已經足夠了；

下面要介紹到的參數主要是在系統處理中做table scan 或者range scan 的時候使用的一些buffer 的相關設置，設置的恰當可以既節省內存又達到足夠的性能要求。

MaxNoOfConcurrentScans：這個參數主要控制在Cluster 環境中并發的table scan和range scan 的總數量平均分配到每一個節點后的平均值。一般來說，每一個scan 都是通過并行的掃描所有的partition 來完成的，每一個partition 的掃描都會在該partition所在的節點上面使用一個scan record。所以，這個參數值得大小應該是“scan record”數目* 節點數目。參數默認大小為256，最大只能設置為500；


MaxNoOfLocalScans：和上面的這個參數相對應，只不過設置的是在本節點上面的并發table scan 和range scan 數量。如果在系統中有大量的并發而且一般都不使用并行的話，需要注意此參數的設置。默認為MaxNoOfConcurrentScans * node 數目；


BatchSizePerLocalScan：該參用于計算在Localscan（并發）過程中被鎖住的記錄數，文檔上說明默認為64；

LongMessageBuffer：這個參數定義的是消息傳遞時候的buffer 大小，而這里的消息傳遞主要是內部信息傳遞以及節點與節點之間的信息傳遞。這個參數一般很少需要調整，默認大小為1MB 大小；

下面介紹一下與LOG 相關的參數配置說明，包括LOG level。這里的LOG level 有多種，從0 到15，也就是共16 種。如果設定為0，則表示不記錄任何LOG。如果設置為最高level，也就是15，則表示所有的信息都會通過標準輸出來記錄LOG.由于這里的所有信息實際上都會傳遞到管理節點的cluster LOG 中，所以，一般來說，除了啟動時候的LOG級別需要設置為1 之外，其他所有的LOG level 都只需要設置為0 就可以了。

NoOfFragmentLogFiles：這個參數實際上和Oracle 的redo LOG 的group 一樣的。其實就是ndb 的redo LOG group 數目，這些redo LOG 用于存放ndb 引擎所做的所有需要變更數據的事情，以及各種checkpoint 信息等。默認值為8；


MaxNoOfSavedMessages：這個參數設定了可以保留的trace 文件（在節點crash的時候參數）的最大個數，文檔上面說此參數默認值為25。

LogLevelStartup：設定啟動ndb 節點時候需要記錄的信息的級別（不同級別所記錄的信息的詳細程度不一樣），默認級別為1；

LogLevelShutdown：設定關閉ndb 節點時候記錄日志的信息的級別，默認為0；

LogLevelStatistic：這個參數是針對于統計相關的日志的，就像更新數量，插入數量，buffer 使用情況，主鍵數量等等統計信息。默認日志級別為0；

LogLevelCheckpoint：checkpoint 日志記錄級別（包括local 和global 的），默認為0；

LogLevelNodeRestart：ndb 節點重啟過程日志級別，默認為0；

LogLevelConnection：各節點之間連接相關日志記錄的級別，默認0；

LogLevelError：在整個Cluster 中錯誤或者警告信息的日志記錄級別，默認0；

LogLevelInfo：普通信息的日志記錄級別，默認為0。這里再介紹幾個用來作為LOG 記錄時候需要用到的Buffer 相關參數，這些參數對于性能都有一定的影響。當然，如果節點運行在無盤模式下的話，則影響不大。


UndoIndexBuffer：undo index buffer 主要是用于存儲主鍵hash 索引在變更之后產生的undo 信息的緩沖區。默認值為2M 大小，最小可以設置為1M，對于大多數應用來說，2M 的默認值是夠的.當然，在更新非常頻繁的應用里面，適當的調大此參數值對性能還是有一定幫助的。如果此參數太小，會報出677 錯誤：Index UNDO buffers overloaded；


UndoDataBuffer：和undo index buffer 類似，undo data buffer 主要是在數據發生變更的時候所需要的undo 信息的緩沖區。默認大小為16M，最小同樣為1M。當這個參數值太小的時候，系統會報出如下的錯誤：Data UNDO buffers overloaded，錯誤號為891；



RedoBuffer：Redo buffer 是用redo LOG 信息的緩沖區，默認大小為8M，最小為1M。如果此buffer 太小，會報1221 錯誤：REDO LOG buffers overloaded.


此外，NDB 節點還有一些和metadata 以及內部控制相關的參數，但大部分參數都基本上不需要任何調整，所以就不做進一步介紹。如果有興趣希望詳細了解，可以根據MySQL官方的相關參考手冊，手冊上面都有較為詳細的介紹。

3、SQL 節點相關配置說明
1) 和其他節點一樣，先介紹一些適用于所有節點的[MySQLD DEFAULT]參數ArbitrationRank：這個參數在介紹管理節點的參數時候已經介紹過了，用于設定節點級別（主要是在多個節點在處理相關操作時候出現分歧時候設定裁定者）的。一般來說，所有的SQL 節點都應該設定為2；

ArbitrationDelay：默認為0，裁定者在開始裁定之前需要被delay 多久，單位為毫秒。一般不需要更改默認值。

BatchByteSize：在做全表掃描或者索引范圍掃描的時候，每一次fatch 的數據量，默認為32KB；

BatchSize：類似BatchByteSize 參數，只不過BatchSize 所設定的是每一次fetch的record 數量，而不是物理總量，默認為64，最大為992（暫時還不知道這個值是基于什么理論而設定的）。在實際運行query 的過程中，fetch 的量受到BatchByteSize 和BatchSize兩個參數的共同制約，二者取最小值；


MaxScanBatchSize：在Cluster 環境中，進行并行處理的情況下，所有節點的BatchSize 總和的最大值。默認值為256KB，最大值為16MB。

2) 每個節點獨有的[MySQLD]參數組，僅有id 和hostname 參數需要配置，在之前各類節點均有介紹了，這里就不再累述。


轉自http://www.cnblogs.com/alang85/archive/2011/11/18/2253900.html

• 一、循環插入數據時出現
    table is full

  二、在mgm>all report memoryusage 查看

  Node 2: Data usage is 22%(2305 32K pages of total 10240)

  使用率到最后98%以上這時出現啦table is full

  基于以上兩種情況，其實是一種情況的我的解決方法是:

  根據硬件配置必須根據硬件配置修改my.cnf文件和config.ini文件

  1.config.ini
  [ndbd default]
  NoOfReplicas=2 
  MaxNoOfConcurrentOperations=10000
  DataMemory=320M
  IndexMemory=96M
  TimeBetweenWatchDogCheck=30000
  MaxNoOfOrderedIndexes=512

  2.my.cnf
  [mysqld]
  ndbcluster
  ndb-connectstring=124.95.137.12
  optimizer_switch=engine_condition_pushdown=off

  問題得以解決
  來源：http://www.greensoftcode.net/
  

什么東西可以監控OpenStack呢？OpenStack對監控的需求起碼有以下這些：

• 不僅要能監控物理機，也能監控虛機
• 監控信息也必須是tenant隔離的
• 監控項的收集應該是自動地
• 監控工具應該一般化以監控任何設備
• 監控工具必須提供API

下面是監控工具的一般架構：

網上搜索了一下，現在主流的監控工具有：Nagios, cacti, Zabbix, Muni, Zenoss。我不是做運維的對這些工具都不熟，以前不熟，現在也不熟。下面是一些理解，不一定準。

Nagios，最老牌了，比較通用的監控工具。特大的特點是報警。圖形化功能一般般。一般要安裝Agent，配置起來看網上的說法是比較復雜的，沒用過，沒實際發言權。

cacti，圖形化功能不錯，所以Nagios一般結合它來使用。

Zabbix，監控和圖形化功能都還可以了，尤其有一本電子書 zabbix 1.8 network monitoring

Zenoss, 監控新貴，它使用無Agent的通用技術如SNMP和SSL來監控，部署起來會比較方便。尤其是Zenoss公司有人現在也加入OpenStack社區了，專門開發了一個OpenStack特有的擴展（

https://github.com/zenoss/ZenPacks.zenoss.OpenStack）不幸的是，目前只支持Nova API 1.1，且它只能收集單個tenant的數據，不利于rating和billing。

OpenStack Ceilometer工程主要監控的是tenant下虛機的數據，用來做billing的，物理機的監控支持不大好。

比較來比較去，如果是我，可能會做如下選型決定，不一定正確 ：

Nagios 或者 Zenoss (視情況）

下面內容來自：http://docs.openstack.org/developer/ceilometer/， 我們看一下Ceilometer工程的現狀, 架構如下：

運行OpenStack各組件的節點上一般有Agent來收集信息，收集后發給MQ，Ceilometer的Collector進程監控到數據之后存儲到DB之中。從http://docs.openstack.org/developer/ceilometer/measurements.html 這頁顯示的監控項來看，目前Ceilometer監控來的數據主要來只是用來做billing的。

文章來源：http://blog.csdn.net/quqi99/article/details/9400747
文章作者：張華 http://blog.csdn.net/quqi99

Using HAProxy to make SSH and SSL available on the same port

Certain places firewall TCP ports other than the most common ports. There are many techniques for bypassing such restrictions. One simple approach is to run a SSH daemon on port 443, however a downside of this is you need to dedicate an IP address to this SSH service.

There is quite a neat technique for making SSH and SSL share a port; in the SSL protocol clients should write first, whereas in SSH the server should write first; therefore by waiting to see if the client writes data it is possible to make a guess as to if the client is an SSL client or a SSH client.

I'm not the first person to think this up, Net::Proxy has a script called sslh and confusingly there is also a C implementation also called sslh.

I recently switched my web server to use HAProxy to allow me some more flexiblity in how I configure things (especially now the development version has keepalive support). While reading the (incredibly detailed) documentation I noticed it should be able to do the sslh technique.

Doing this needs the (currently) in development HAProxy 1.4 (support was added for content switching TCP as well as HTTP in this commit -- thanks to Cyril Bonté on the mailing list for confirming that).

The configuration looks something like the following (global section omitted, you'll want to run it as a user other than root and chroot it if you actually use this).

defaults

  timeout connect 5s

  timeout client 50s

  timeout server 20s

listen ssl :443

  tcp-request inspect-delay 2s

  acl is_ssl req_ssl_ver 2:3.1

  tcp-request content accept if is_ssl

  use_backend ssh if !is_ssl

  server www-ssl :444

  timeout client 2h

backend ssh

  mode tcp

  server ssh :22

  timeout server 2h

This listens on port 443, forwards it to port 444 (where the actual SSL web server is listening) unless it is not SSLv2, SSLv3 or TLSv1 traffic, in which case it forwards it to the ssh backend listening on port 22.

Obviously as I said earlier this is only a guess that is subject to network conditions such as packet loss. I'm not recommending you use this technique on a production site, but for a low traffic machine where you want to run both protocols it is very useful. (By increasing the timeout for SSH you increase the chances of a correct result, but also add a potentially annoying delay).

Sometimes layer 7 filtering techniques are in use and just listening on port 443 is not enough. In this case you can use SSH inside SSL.

現在網站發展的趨勢對網絡負載均衡的使用是隨著網站規模的提升根據不同的階段來使用不同的技術：

一種是通過硬件來進行進行，常見的硬件有比較昂貴的NetScaler、F5、Radware和Array等商用的負載均衡器，它的優點就是有專業的維護團隊來對這些服務進行維護、缺點就是花銷太大，所以對于規模較小的網絡服務來說暫時還沒有需要使用；另外一種就是類似于LVS/HAProxy、Nginx的基于Linux的開源免費的負載均衡軟件策略,這些都是通過軟件級別來實現，所以費用非常低廉，所以我個也比較推薦大家采用第二種方案來實施自己網站的負載均衡需求。

近期朋友劉鑫(紫雨荷雪)的項目成功上線了，PV達到了億級/日的訪問量，最前端用的是HAProxy+Keepalived雙機作的負載均衡器 /反向代理，整個網站非常穩定；這讓我更堅定了以前跟老男孩前輩聊的關于網站架構比較合理設計的架構方案：即Nginx /HAProxy+Keepalived作Web最前端的負載均衡器，后端的MySQL數據庫架構采用一主多從，讀寫分離的方式，采用LVS+Keepalived的方式。

在這里我也有一點要跟大家申明下：很多朋友擔心軟件級別的負載均衡在高并發流量沖擊下的穩定情況，事實是我們通過成功上線的許多網站發現，它們的穩 定性也是非常好的，宕機的可能性微乎其微，所以我現在做的項目，基本上沒考慮服務級別的高可用了。相信大家對這些軟件級別的負載均衡軟件都已經有了很深的 的認識，下面我就它們的特點和適用場合分別說明下。

LVS：使用集群技術和Linux操作系統實現一個高性能、高可用的服務器，它具有很好的可伸縮性（Scalability)、可靠性（Reliability)和可管理性（Manageability)，感謝章文嵩博士為我們提供如此強大實用的開源軟件。

LVS的特點是：

1. 抗負載能力強、是工作在網絡4層之上僅作分發之用，沒有流量的產生，這個特點也決定了它在負載均衡軟件里的性能最強的；
2. 配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以并不需要太多接觸，大大減少了人為出錯的幾率；
3. 工作穩定，自身有完整的雙機熱備方案，如LVS+Keepalived和LVS+Heartbeat，不過我們在項目實施中用得最多的還是LVS/DR+Keepalived；
4. 無流量，保證了均衡器IO的性能不會收到大流量的影響；
5. 應用范圍比較廣，可以對所有應用做負載均衡；
6. 軟件本身不支持正則處理，不能做動靜分離，這個就比較遺憾了；其實現在許多網站在這方面都有較強的需求，這個是Nginx/HAProxy+Keepalived的優勢所在。
7. 如果是網站應用比較龐大的話，實施LVS/DR+Keepalived起來就比較復雜了，特別后面有Windows Server應用的機器的話，如果實施及配置還有維護過程就比較復雜了，相對而言，Nginx/HAProxy+Keepalived就簡單多了。站長教學網 eduyo.com

Nginx的特點是：

1. 工作在網絡的7層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結構，它的正則規則比HAProxy更為強大和靈活，這也是許多朋友喜歡它的原因之一；
2. Nginx對網絡的依賴非常小，理論上能ping通就就能進行負載功能，這個也是它的優勢所在；
3. Nginx安裝和配置比較簡單，測試起來比較方便；
4. 也可以承擔高的負載壓力且穩定，一般能支撐超過幾萬次的并發量；
5. Nginx可以通過端口檢測到服務器內部的故障，比如根據服務器處理網頁返回的狀態碼、超時等等，并且會把返回錯誤的請求重新提交到另一個節點，不過其中缺點就是不支持url來檢測；
6. Nginx僅能支持http和Email，這樣就在適用范圍上面小很多，這個它的弱勢；
7. Nginx不僅僅是一款優秀的負載均衡器/反向代理軟件，它同時也是功能強大的Web應用服務器。LNMP現在也是非常流行的web架構，大有和以前最流行的LAMP架構分庭抗爭之勢，在高流量的環境中也有很好的效果。
8. Nginx現在作為Web反向加速緩存越來越成熟了，很多朋友都已在生產環境下投入生產了，而且反映效果不錯，速度比傳統的Squid服務器更快，有興趣的朋友可以考慮用其作為反向代理加速器。

HAProxy的特點是：

1. HAProxy是支持虛擬主機的，以前有朋友說這個不支持虛擬主機，我這里特此更正一下。
2. 能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作
3. 支持url檢測后端的服務器出問題的檢測會有很好的幫助。
4. 它跟LVS一樣，本身僅僅就只是一款負載均衡軟件；單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度，在并發處理上也是優于Nginx的。
5. HAProxy可以對Mysql讀進行負載均衡，對后端的MySQL節點進行檢測和負載均衡，不過在后端的MySQL slaves數量超過10臺時性能不如LVS，所以我向大家推薦LVS+Keepalived。
6. HAProxy的算法現在也越來越多了，具體有如下8種：
   ① roundrobin，表示簡單的輪詢，這個不多說，這個是負載均衡基本都具備的；
   ② static-rr，表示根據權重，建議關注；
   ③ leastconn，表示最少連接者先處理，建議關注；
   ④ source，表示根據請求源IP，這個跟Nginx的IP_hash機制類似，我們用其作為解決session問題的一種方法，建議關注；
   ⑤ ri，表示根據請求的URI；
   ⑥ rl_param，表示根據請求的URl參數'balance url_param' requires an URL parameter name；
   ⑦ hdr(name)，表示根據HTTP請求頭來鎖定每一次HTTP請求；
   ⑧ rdp-cookie(name)，表示根據據cookie(name)來鎖定并哈希每一次TCP請求。

Nginx和LVS作對比的結果

1、Nginx工作在網絡的7層，所以它可以針對http應用本身來做分流策略，比如針對域名、目錄結構等，相比之下LVS并不具備這樣的功能，所 以 Nginx單憑這點可利用的場合就遠多于LVS了；但Nginx有用的這些功能使其可調整度要高于LVS，所以經常要去觸碰觸碰，由LVS的第2條優點 看，觸碰多了，人為出問題的幾率也就會大。
2、Nginx對網絡的依賴較小，理論上只要ping得通，網頁訪問正常，Nginx就能連得通，Nginx同時還能區分內外網，如果是同時擁有內外網的 節點，就相當于單機擁有了備份線路；LVS就比較依賴于網絡環境，目前來看服務器在同一網段內并且LVS使用direct方式分流，效果較能得到保證。另 外注意，LVS需要向托管商至少申請多一個ip來做Visual IP，貌似是不能用本身的IP來做VIP的。要做好LVS管理員，確實得跟進學習很多有關網絡通信方面的知識，就不再是一個HTTP那么簡單了。站長教學網 eduyo.com
3、Nginx安裝和配置比較簡單，測試起來也很方便，因為它基本能把錯誤用日志打印出來。LVS的安裝和配置、測試就要花比較長的時間了，因為同上所述，LVS對網絡依賴比較大，很多時候不能配置成功都是因為網絡問題而不是配置問題，出了問題要解決也相應的會麻煩得多。
4、Nginx也同樣能承受很高負載且穩定，但負載度和穩定度差LVS還有幾個等級：Nginx處理所有流量所以受限于機器IO和配置；本身的bug也還是難以避免的；Nginx沒有現成的雙機熱備方案，所以跑在單機上還是風險較大，單機上的事情全都很難說。
5、Nginx可以檢測到服務器內部的故障，比如根據服務器處理網頁返回的狀態碼、超時等等，并且會把返回錯誤的請求重新提交到另一個節點。目前LVS中 ldirectd也能支持針對服務器內部的情況來監控，但LVS的原理使其不能重發請求。重發請求這點，譬如用戶正在上傳一個文件，而處理該上傳的節點剛 好在上傳過程中出現故障，Nginx會把上傳切到另一臺服務器重新處理，而LVS就直接斷掉了，如果是上傳一個很大的文件或者很重要的文件的話，用戶可能 會因此而惱火。
6、Nginx對請求的異步處理可以幫助節點服務器減輕負載，假如使用apache直接對外服務，那么出現很多的窄帶鏈接時apache服務器將會占用大 量內存而不能釋放，使用多一個Nginx做apache代理的話，這些窄帶鏈接會被Nginx擋住，apache上就不會堆積過多的請求，這樣就減少了相 當多的內存占用。這點使用squid也有相同的作用，即使squid本身配置為不緩存，對apache還是有很大幫助的。LVS沒有這些功能，也就無法能 比較。
7、Nginx能支持http和email（email的功能估計比較少人用），LVS所支持的應用在這點上會比Nginx更多。在使用上，一般最前端所 采取的策略應是LVS，也就是DNS的指向應為LVS均衡器，LVS的優點令它非常適合做這個任務。重要的ip地址，最好交由LVS托管，比如數據庫的 ip、webservice服務器的ip等等，這些ip地址隨著時間推移，使用面會越來越大，如果更換ip則故障會接踵而至。所以將這些重要ip交給 LVS托管是最為穩妥的，這樣做的唯一缺點是需要的VIP數量會比較多。Nginx可作為LVS節點機器使用，一是可以利用Nginx的功能，二是可以利 用Nginx的性能。當然這一層面也可以直接使用squid，squid的功能方面就比Nginx弱不少了，性能上也有所遜色于Nginx。Nginx也 可作為中層代理使用，這一層面Nginx基本上無對手，唯一可以撼動Nginx的就只有lighttpd了，不過lighttpd目前還沒有能做到 Nginx完全的功能，配置也不那么清晰易讀。另外，中層代理的IP也是重要的，所以中層代理也擁有一個VIP和LVS是最完美的方案了。具體的應用還得 具體分析，如果是比較小的網站（日PV<1000萬），用Nginx就完全可以了，如果機器也不少，可以用DNS輪詢，LVS所耗費的機器還是比較 多的；大型網站或者重要的服務，機器不發愁的時候，要多多考慮利用LVS