nginx為了實(shí)現(xiàn)反向代理的需求而增加了一個(gè)ngx_http_proxy_module模塊。其中proxy_set_header指令就是該模塊需要讀取的配置文件。在這里，所有設(shè)置的值的含義和http請(qǐng)求同中的含義完全相同，除了Host外還有X-Forward-For。
Host的含義是表明請(qǐng)求的主機(jī)名，因?yàn)閚ginx作為反向代理使用，而如果后端真是的服務(wù)器設(shè)置有類(lèi)似防盜鏈或者根據(jù)http請(qǐng)求頭中的host字段來(lái)進(jìn)行路由或判斷功能的話(huà)，如果反向代理層的nginx不重寫(xiě)請(qǐng)求頭中的host字段，將會(huì)導(dǎo)致請(qǐng)求失敗【默認(rèn)反向代理服務(wù)器會(huì)向后端真實(shí)服務(wù)器發(fā)送請(qǐng)求，并且請(qǐng)求頭中的host字段應(yīng)為proxy_pass指令設(shè)置的服務(wù)器】。
同理，X_Forward_For字段表示該條http請(qǐng)求是有誰(shuí)發(fā)起的？如果反向代理服務(wù)器不重寫(xiě)該請(qǐng)求頭的話(huà)，那么后端真實(shí)服務(wù)器在處理時(shí)會(huì)認(rèn)為所有的請(qǐng)求都來(lái)在反向代理服務(wù)器，如果后端有防攻擊策略的話(huà)，那么機(jī)器就被封掉了。因此，在配置用作反向代理的nginx中一般會(huì)增加兩條配置，修改http的請(qǐng)求頭：
proxy_set_header Host $http_host;
proxy_set_header X-Forward-For $remote_addr;
這里的$http_host和$remote_addr都是nginx的導(dǎo)出變量，可以再配置文件中直接使用。如果Host請(qǐng)求頭部沒(méi)有出現(xiàn)在請(qǐng)求頭中，則$http_host值為空，但是$host值為主域名。因此，一般而言，會(huì)用$host代替$http_host變量，從而避免http請(qǐng)求中丟失Host頭部的情況下Host不被重寫(xiě)的失誤。
對(duì)于防火墻的選擇:
http://blog.sina.com.cn/s/blog_92dc41ea0101j5l1.html
http://www.lupaworld.com/article-218506-1.html
openvpn:http://grantcurell.com/2014/07/22/setting-up-a-vpn-server-on-ubuntu-14-04/
pfsense防火墻:
http://www.docin.com/p-88103814.html
ssl vpn:openvpn
ipsec:sprongswan
代理服務(wù)器:squid
stunnel:tcp加密
Panabit流控引擎：
Panabit標(biāo)準(zhǔn)版是目前國(guó)內(nèi)開(kāi)放度最高、免費(fèi)、專(zhuān)業(yè)的應(yīng)用層流量管理系統(tǒng)，特別針對(duì)P2P應(yīng)用的識(shí)別與控制，截止2009年03月25日，已經(jīng)支持實(shí)際主流應(yīng)用240種以上，并以?xún)芍芨乱淮翁卣鲙?kù)的速度持續(xù)更新(包括已支持協(xié)議和新增協(xié)議兩方面的更新，Panabit支持協(xié)議列表請(qǐng)關(guān)注Panabit網(wǎng)站首頁(yè)"支持協(xié)議")。Panabit在精確識(shí)別協(xié)議即對(duì)應(yīng)用分類(lèi)的基礎(chǔ)上，根據(jù)用戶(hù)自定義策略，提供靈活方便的流量管理機(jī)制：帶寬限速、帶寬保證、帶寬預(yù)留，并可基于協(xié)議/協(xié)議組、IP/IP組進(jìn)行參數(shù)化的策略設(shè)置。Panabit采用創(chuàng)新的"節(jié)點(diǎn)跟蹤"技術(shù)與"加密協(xié)議深度識(shí)別"技術(shù)提高識(shí)別效率和準(zhǔn)確度，如對(duì)使用加密協(xié)議的eMule、Skype等精確識(shí)別。Panabit區(qū)別于一些同類(lèi)設(shè)備，在不能精確識(shí)別協(xié)議的情況下，限制客戶(hù)端并發(fā)連接數(shù)非科學(xué)的做法，易造成誤判或影響正常用戶(hù)。Panabit是一款真正的應(yīng)用層流控系統(tǒng)，能做限速控制；如果是疑似識(shí)別、不能準(zhǔn)確定位具體應(yīng)用的系統(tǒng)，是不敢做限速控制，起不到實(shí)際應(yīng)用層流控效果。
create a table with tablespace set.
* tablespace creation *
CREATE TABLESPACE ts_1 ADD DATAFILE '/home/db/mysql-cluster/data/data_1.dat' USE LOGFILE GROUP lg_1 INITIAL_SIZE = 26843545600 ENGINE NDB;
ALTER TABLESPACE ts_1 ADD DATAFILE '/home/db/mysql-cluster/data/data_2.dat' INITIAL_SIZE 26843545600 ENGINE NDB;
ALTER TABLESPACE ts_1 ADD DATAFILE '/home/db/mysql-cluster/data/data_3.dat' INITIAL_SIZE 26843545600 ENGINE NDB;
ALTER TABLESPACE ts_1 ADD DATAFILE '/home/db/mysql-cluster/data/data_4.dat' INITIAL_SIZE 26843545600 ENGINE NDB;
* table creation *
CREATE TABLE `TABLE` (
`A` date NOT NULL,
`B` varchar(30) NOT NULL,
`C` varchar(50) NOT NULL,
`D` varchar(50) NOT NULL,
`E` varchar(50) NOT NULL,
`F` varchar(255) DEFAULT NULL
) TABLESPACE ts_1 STORAGE DISK ENGINE=ndbcluster DEFAULT CHARSET=utf8
PK, index generated without the table and insert the data(40G),
I'm Using logs as the following index numbers are still high. (mgm log)
The actual number of memory ndb also giving you an upward trend ... Why?
2009-11-17 16:54:58 [MgmtSrvr] INFO -- Node 8: Index usage is 4%(30707 8K pages of total 655392)
2009-11-17 16:55:25 [MgmtSrvr] INFO -- Node 8: Data usage is 8%(20603 32K pages of total 229376)
2,創(chuàng)建索引和鍵的限制：
(1),在列上創(chuàng)建索引長(zhǎng)度超過(guò)3072bytes會(huì)成功，但是只能使用索引的前3072bytes。并且會(huì)顯示警告信息"specified key was too long,max key lenght is 3072 keys"
不支持的特征
1，在NDB創(chuàng)建create table時(shí)，一定要指定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參數(shù)解釋 ---from 《mysql性能調(diào)優(yōu)和架構(gòu)設(shè)計(jì)》
1) [NDBD DEFAULT]中的配置項(xiàng)：
NoOfReplicas：定義在Cluster 環(huán)境中相同數(shù)據(jù)的分?jǐn)?shù)，通俗一點(diǎn)來(lái)說(shuō)就是每一份數(shù)據(jù)存放NoOfReplicas 份。如果希望能夠冗余，那么至少設(shè)置為2（一般情況來(lái)說(shuō)此參數(shù)值設(shè)置為2 就夠了），最大只能設(shè)置為4。另外，NoOfReplicas 值得大小，實(shí)際上也就是nodegroup 大小的定義。NoOfReplicas 參數(shù)沒(méi)有系統(tǒng)默認(rèn)值，所以必須設(shè)定，而且只能設(shè)置在[NDBD DEFAULT]中，因?yàn)榇藬?shù)值在整個(gè)Cluster 集群中一個(gè)node group 中所有的NDBD 節(jié)點(diǎn)都需要一樣。另外NoOfReplicas 的數(shù)目對(duì)整個(gè)Cluster 環(huán)境中NDB 節(jié)點(diǎn)數(shù)量有較大的影響，因?yàn)镹DB 節(jié)點(diǎn)總數(shù)量是NoOfReplicas * 2 * node_group_num；DataDir：指定本地的pid 文件，trace 文件，日志文件以及錯(cuò)誤日志子等存放的路徑，無(wú)系統(tǒng)默認(rèn)地址，所以必須設(shè)定；
DataMemory：設(shè)定用于存放數(shù)據(jù)和主鍵索引的內(nèi)存段的大小。這個(gè)大小限制了能存放的數(shù)據(jù)的大小，因?yàn)閚db 存儲(chǔ)引擎需屬于內(nèi)存數(shù)據(jù)庫(kù)引擎，需要將所有的數(shù)據(jù)（包括索引）都load 到內(nèi)存中。這個(gè)參數(shù)并不是一定需要設(shè)定的，但是默認(rèn)值非常小（80M），只也就是說(shuō)如果使用默認(rèn)值，將只能存放很小的數(shù)據(jù)。參數(shù)設(shè)置需要帶上單位，如512M，2G 等。另外，DataMemory 里面還會(huì)存放UNDO 相關(guān)的信息,所以，事務(wù)的大小和事務(wù)并發(fā)量也決定了DataMemory 的使用量，建議盡量使用小事務(wù)；
IndexMemory：設(shè)定用于存放索引（非主鍵）數(shù)據(jù)的內(nèi)存段大小。和DataMemory類(lèi)似，這個(gè)參數(shù)值的大小同樣也會(huì)限制該節(jié)點(diǎn)能存放的數(shù)據(jù)的大小，因?yàn)樗饕拇笮∈请S著數(shù)據(jù)量增長(zhǎng)而增長(zhǎng)的。參數(shù)設(shè)置也如DataMemory 一樣需要單位。IndexMemory 默認(rèn)大小為18M；實(shí)際上，一個(gè)NDB 節(jié)點(diǎn)能存放的數(shù)據(jù)量是會(huì)受到DataMemory 和IndexMemory 兩個(gè)參數(shù)設(shè)置的約束，兩者任何一個(gè)達(dá)到限制數(shù)量后，都無(wú)法再增加能存儲(chǔ)的數(shù)據(jù)量。如果繼續(xù)存入數(shù)據(jù)系統(tǒng)會(huì)報(bào)錯(cuò)“table is full”。
FileSystemPath：指定redo 日志，undo 日志，數(shù)據(jù)文件以及meta 數(shù)據(jù)等的存放位置，默認(rèn)位置為DataDir 的設(shè)置，并且在ndbd 初始化的時(shí)候，參數(shù)所設(shè)定的文件夾必須存在。在第一次啟動(dòng)的時(shí)候，ndbd 進(jìn)程會(huì)在所設(shè)定的文件夾下建立一個(gè)子文件夾叫ndb_id_fs，這里的id 為節(jié)點(diǎn)的ID 值，如節(jié)點(diǎn)id 為3 則文件夾名稱(chēng)為ndb_3_fs。當(dāng)然，這個(gè)參數(shù)也不一定非得設(shè)置在[NDBD DEFAULT]參數(shù)組里面讓所有節(jié)點(diǎn)的設(shè)置都一樣（不過(guò)建議這樣設(shè)置），還可以設(shè)置在[NDBD]參數(shù)組下為每一個(gè)節(jié)點(diǎn)單獨(dú)設(shè)置自己的FileSystemPath值；
BackupDataDir：設(shè)置備份目錄路徑，默認(rèn)為FileSystemPath/BACKUP。接下來(lái)的幾個(gè)參數(shù)也是非常重要的，主要都是與并行事務(wù)數(shù)和其他一些并行限制有關(guān)的參數(shù)設(shè)置。
MaxNoOfConcurrentTransactions：設(shè)置在一個(gè)節(jié)點(diǎn)上面的最大并行事務(wù)數(shù)目，默認(rèn)為4096，一般情況下來(lái)說(shuō)是足夠了的。這個(gè)參數(shù)值所有節(jié)點(diǎn)必須設(shè)置一樣，所以一般都是設(shè)置在[NDBD DEFAULT]參數(shù)組下面；
MaxNoOfConcurrentOperations：設(shè)置同時(shí)能夠被更新（或者鎖定）的記錄數(shù)量。一般來(lái)說(shuō)可以設(shè)置為在整個(gè)集群中相同時(shí)間內(nèi)可能被更新（或者鎖定）的總記錄數(shù)，除以NDB節(jié)點(diǎn)數(shù)，所得到的值。
MaxNoOfLocalOperations：此參數(shù)默認(rèn)是MaxNoOfConcurrentOperations * 1.1的大小，也就是說(shuō)，每個(gè)節(jié)點(diǎn)一般可以處理超過(guò)平均值的10%的操作記錄數(shù)量。但是一般來(lái)說(shuō)，MySQL 建議單獨(dú)設(shè)置此參數(shù)而不要使用默認(rèn)值，并且將此參數(shù)設(shè)置得更較大一些；
以下的三個(gè)參數(shù)主要是在一個(gè)事務(wù)中執(zhí)行一條query 的時(shí)候臨時(shí)用到存儲(chǔ)（或者內(nèi)存）的情況下所使用到的，所使用的存儲(chǔ)信息會(huì)在事務(wù)結(jié)束（commit 或者rollback）的時(shí)候釋放資源；
MaxNoOfConcurrentIndexOperations：這個(gè)參數(shù)和MaxNoOfConcurrentOperations參數(shù)比較類(lèi)似，只不過(guò)所針對(duì)的是Index 的record 而已。其默認(rèn)值為8192，對(duì)伊一般的系統(tǒng)來(lái)說(shuō)都已經(jīng)足夠了，只有在事務(wù)并發(fā)非常非常大的系統(tǒng)上才有需要增加這個(gè)參數(shù)的設(shè)置。當(dāng)然，此參數(shù)越大，系統(tǒng)運(yùn)行時(shí)候?yàn)榇硕牡膬?nèi)存也會(huì)越大；
MaxNoOfFiredTriggers：觸發(fā)唯一索引（hash index）操作的最大的操作數(shù)，這個(gè)操作數(shù)是影響索引的操作條目數(shù)，而不是操作的次數(shù)。系統(tǒng)默認(rèn)值為4000，一般系統(tǒng)來(lái)說(shuō)夠用了。當(dāng)然，如果系統(tǒng)并發(fā)事務(wù)非常高，而且涉及到索引的操作也非常多，自然也就需要提高這個(gè)參數(shù)值的設(shè)置了；
TransactionBufferMemory：這個(gè)buffer 值得設(shè)置主要是指定用于跟蹤索引操作而使用的。主要是用來(lái)存儲(chǔ)索引操作中涉及到的索引key 值和column 的實(shí)際信息。這這個(gè)參數(shù)的值一般來(lái)說(shuō)也很少需要調(diào)整，因?yàn)閷?shí)際系統(tǒng)中需要的這部分buffer 量非常小，雖然默認(rèn)值只是1M，但是對(duì)于一般應(yīng)用也已經(jīng)足夠了；
下面要介紹到的參數(shù)主要是在系統(tǒng)處理中做table scan 或者range scan 的時(shí)候使用的一些buffer 的相關(guān)設(shè)置，設(shè)置的恰當(dāng)可以既節(jié)省內(nèi)存又達(dá)到足夠的性能要求。
MaxNoOfConcurrentScans：這個(gè)參數(shù)主要控制在Cluster 環(huán)境中并發(fā)的table scan和range scan 的總數(shù)量平均分配到每一個(gè)節(jié)點(diǎn)后的平均值。一般來(lái)說(shuō)，每一個(gè)scan 都是通過(guò)并行的掃描所有的partition 來(lái)完成的，每一個(gè)partition 的掃描都會(huì)在該partition所在的節(jié)點(diǎn)上面使用一個(gè)scan record。所以，這個(gè)參數(shù)值得大小應(yīng)該是“scan record”數(shù)目* 節(jié)點(diǎn)數(shù)目。參數(shù)默認(rèn)大小為256，最大只能設(shè)置為500；
MaxNoOfLocalScans：和上面的這個(gè)參數(shù)相對(duì)應(yīng)，只不過(guò)設(shè)置的是在本節(jié)點(diǎn)上面的并發(fā)table scan 和range scan 數(shù)量。如果在系統(tǒng)中有大量的并發(fā)而且一般都不使用并行的話(huà)，需要注意此參數(shù)的設(shè)置。默認(rèn)為MaxNoOfConcurrentScans * node 數(shù)目；
BatchSizePerLocalScan：該參用于計(jì)算在Localscan（并發(fā)）過(guò)程中被鎖住的記錄數(shù)，文檔上說(shuō)明默認(rèn)為64；
LongMessageBuffer：這個(gè)參數(shù)定義的是消息傳遞時(shí)候的buffer 大小，而這里的消息傳遞主要是內(nèi)部信息傳遞以及節(jié)點(diǎn)與節(jié)點(diǎn)之間的信息傳遞。這個(gè)參數(shù)一般很少需要調(diào)整，默認(rèn)大小為1MB 大??；
下面介紹一下與LOG 相關(guān)的參數(shù)配置說(shuō)明，包括LOG level。這里的LOG level 有多種，從0 到15，也就是共16 種。如果設(shè)定為0，則表示不記錄任何LOG。如果設(shè)置為最高level，也就是15，則表示所有的信息都會(huì)通過(guò)標(biāo)準(zhǔn)輸出來(lái)記錄LOG.由于這里的所有信息實(shí)際上都會(huì)傳遞到管理節(jié)點(diǎn)的cluster LOG 中，所以，一般來(lái)說(shuō)，除了啟動(dòng)時(shí)候的LOG級(jí)別需要設(shè)置為1 之外，其他所有的LOG level 都只需要設(shè)置為0 就可以了。
NoOfFragmentLogFiles：這個(gè)參數(shù)實(shí)際上和Oracle 的redo LOG 的group 一樣的。其實(shí)就是ndb 的redo LOG group 數(shù)目，這些redo LOG 用于存放ndb 引擎所做的所有需要變更數(shù)據(jù)的事情，以及各種checkpoint 信息等。默認(rèn)值為8；
MaxNoOfSavedMessages：這個(gè)參數(shù)設(shè)定了可以保留的trace 文件（在節(jié)點(diǎn)crash的時(shí)候參數(shù)）的最大個(gè)數(shù)，文檔上面說(shuō)此參數(shù)默認(rèn)值為25。
LogLevelStartup：設(shè)定啟動(dòng)ndb 節(jié)點(diǎn)時(shí)候需要記錄的信息的級(jí)別（不同級(jí)別所記錄的信息的詳細(xì)程度不一樣），默認(rèn)級(jí)別為1；
LogLevelShutdown：設(shè)定關(guān)閉ndb 節(jié)點(diǎn)時(shí)候記錄日志的信息的級(jí)別，默認(rèn)為0；
LogLevelStatistic：這個(gè)參數(shù)是針對(duì)于統(tǒng)計(jì)相關(guān)的日志的，就像更新數(shù)量，插入數(shù)量，buffer 使用情況，主鍵數(shù)量等等統(tǒng)計(jì)信息。默認(rèn)日志級(jí)別為0；
LogLevelCheckpoint：checkpoint 日志記錄級(jí)別（包括local 和global 的），默認(rèn)為0；
LogLevelNodeRestart：ndb 節(jié)點(diǎn)重啟過(guò)程日志級(jí)別，默認(rèn)為0；
LogLevelConnection：各節(jié)點(diǎn)之間連接相關(guān)日志記錄的級(jí)別，默認(rèn)0；
LogLevelError：在整個(gè)Cluster 中錯(cuò)誤或者警告信息的日志記錄級(jí)別，默認(rèn)0；
LogLevelInfo：普通信息的日志記錄級(jí)別，默認(rèn)為0。這里再介紹幾個(gè)用來(lái)作為L(zhǎng)OG 記錄時(shí)候需要用到的Buffer 相關(guān)參數(shù)，這些參數(shù)對(duì)于性能都有一定的影響。當(dāng)然，如果節(jié)點(diǎn)運(yùn)行在無(wú)盤(pán)模式下的話(huà)，則影響不大。
UndoIndexBuffer：undo index buffer 主要是用于存儲(chǔ)主鍵hash 索引在變更之后產(chǎn)生的undo 信息的緩沖區(qū)。默認(rèn)值為2M 大小，最小可以設(shè)置為1M，對(duì)于大多數(shù)應(yīng)用來(lái)說(shuō)，2M 的默認(rèn)值是夠的.當(dāng)然，在更新非常頻繁的應(yīng)用里面，適當(dāng)?shù)恼{(diào)大此參數(shù)值對(duì)性能還是有一定幫助的。如果此參數(shù)太小，會(huì)報(bào)出677 錯(cuò)誤：Index UNDO buffers overloaded；
UndoDataBuffer：和undo index buffer 類(lèi)似，undo data buffer 主要是在數(shù)據(jù)發(fā)生變更的時(shí)候所需要的undo 信息的緩沖區(qū)。默認(rèn)大小為16M，最小同樣為1M。當(dāng)這個(gè)參數(shù)值太小的時(shí)候，系統(tǒng)會(huì)報(bào)出如下的錯(cuò)誤：Data UNDO buffers overloaded，錯(cuò)誤號(hào)為891；
RedoBuffer：Redo buffer 是用redo LOG 信息的緩沖區(qū)，默認(rèn)大小為8M，最小為1M。如果此buffer 太小，會(huì)報(bào)1221 錯(cuò)誤：REDO LOG buffers overloaded.
此外，NDB 節(jié)點(diǎn)還有一些和metadata 以及內(nèi)部控制相關(guān)的參數(shù)，但大部分參數(shù)都基本上不需要任何調(diào)整，所以就不做進(jìn)一步介紹。如果有興趣希望詳細(xì)了解，可以根據(jù)MySQL官方的相關(guān)參考手冊(cè)，手冊(cè)上面都有較為詳細(xì)的介紹。
3、SQL 節(jié)點(diǎn)相關(guān)配置說(shuō)明
1) 和其他節(jié)點(diǎn)一樣，先介紹一些適用于所有節(jié)點(diǎn)的[MySQLD DEFAULT]參數(shù)ArbitrationRank：這個(gè)參數(shù)在介紹管理節(jié)點(diǎn)的參數(shù)時(shí)候已經(jīng)介紹過(guò)了，用于設(shè)定節(jié)點(diǎn)級(jí)別（主要是在多個(gè)節(jié)點(diǎn)在處理相關(guān)操作時(shí)候出現(xiàn)分歧時(shí)候設(shè)定裁定者）的。一般來(lái)說(shuō)，所有的SQL 節(jié)點(diǎn)都應(yīng)該設(shè)定為2；
ArbitrationDelay：默認(rèn)為0，裁定者在開(kāi)始裁定之前需要被delay 多久，單位為毫秒。一般不需要更改默認(rèn)值。
BatchByteSize：在做全表掃描或者索引范圍掃描的時(shí)候，每一次fatch 的數(shù)據(jù)量，默認(rèn)為32KB；
BatchSize：類(lèi)似BatchByteSize 參數(shù)，只不過(guò)BatchSize 所設(shè)定的是每一次fetch的record 數(shù)量，而不是物理總量，默認(rèn)為64，最大為992（暫時(shí)還不知道這個(gè)值是基于什么理論而設(shè)定的）。在實(shí)際運(yùn)行query 的過(guò)程中，fetch 的量受到BatchByteSize 和BatchSize兩個(gè)參數(shù)的共同制約，二者取最小值；
MaxScanBatchSize：在Cluster 環(huán)境中，進(jìn)行并行處理的情況下，所有節(jié)點(diǎn)的BatchSize 總和的最大值。默認(rèn)值為256KB，最大值為16MB。
2) 每個(gè)節(jié)點(diǎn)獨(dú)有的[MySQLD]參數(shù)組，僅有id 和hostname 參數(shù)需要配置，在之前各類(lèi)節(jié)點(diǎn)均有介紹了，這里就不再累述。
轉(zhuǎn)自http://www.cnblogs.com/alang85/archive/2011/11/18/2253900.html
一、循環(huán)插入數(shù)據(jù)時(shí)出現(xiàn)
table is full二、在mgm>all report memoryusage 查看
Node 2: Data usage is 22%(2305 32K pages of total 10240)
使用率到最后98%以上這時(shí)出現(xiàn)啦table is full
基于以上兩種情況，其實(shí)是一種情況的我的解決方法是:
根據(jù)硬件配置必須根據(jù)硬件配置修改my.cnf文件和config.ini文件
1.config.ini
[ndbd default]
NoOfReplicas=2
MaxNoOfConcurrentOperations=10000
DataMemory=320M
IndexMemory=96M
TimeBetweenWatchDogCheck=30000
MaxNoOfOrderedIndexes=5122.my.cnf
[mysqld]
ndbcluster
ndb-connectstring=124.95.137.12
optimizer_switch=engine_condition_pushdown=off問(wèn)題得以解決
來(lái)源：http://www.greensoftcode.net/
什么東西可以監(jiān)控OpenStack呢？OpenStack對(duì)監(jiān)控的需求起碼有以下這些：
- 不僅要能監(jiān)控物理機(jī)，也能監(jiān)控虛機(jī)
- 監(jiān)控信息也必須是tenant隔離的
- 監(jiān)控項(xiàng)的收集應(yīng)該是自動(dòng)地
- 監(jiān)控工具應(yīng)該一般化以監(jiān)控任何設(shè)備
- 監(jiān)控工具必須提供API
下面是監(jiān)控工具的一般架構(gòu)：
網(wǎng)上搜索了一下，現(xiàn)在主流的監(jiān)控工具有：Nagios, cacti, Zabbix, Muni, Zenoss。我不是做運(yùn)維的對(duì)這些工具都不熟，以前不熟，現(xiàn)在也不熟。下面是一些理解，不一定準(zhǔn)。
Nagios，最老牌了，比較通用的監(jiān)控工具。特大的特點(diǎn)是報(bào)警。圖形化功能一般般。一般要安裝Agent，配置起來(lái)看網(wǎng)上的說(shuō)法是比較復(fù)雜的，沒(méi)用過(guò)，沒(méi)實(shí)際發(fā)言權(quán)。
cacti，圖形化功能不錯(cuò)，所以Nagios一般結(jié)合它來(lái)使用。
Zabbix，監(jiān)控和圖形化功能都還可以了，尤其有一本電子書(shū) zabbix 1.8 network monitoring
Zenoss, 監(jiān)控新貴，它使用無(wú)Agent的通用技術(shù)如SNMP和SSL來(lái)監(jiān)控，部署起來(lái)會(huì)比較方便。尤其是Zenoss公司有人現(xiàn)在也加入OpenStack社區(qū)了，專(zhuān)門(mén)開(kāi)發(fā)了一個(gè)OpenStack特有的擴(kuò)展（
https://github.com/zenoss/ZenPacks.zenoss.OpenStack）不幸的是，目前只支持Nova API 1.1，且它只能收集單個(gè)tenant的數(shù)據(jù)，不利于rating和billing。
OpenStack Ceilometer工程主要監(jiān)控的是tenant下虛機(jī)的數(shù)據(jù)，用來(lái)做billing的，物理機(jī)的監(jiān)控支持不大好。
比較來(lái)比較去，如果是我，可能會(huì)做如下選型決定，不一定正確 ：
Nagios 或者 Zenoss (視情況）
下面內(nèi)容來(lái)自：http://docs.openstack.org/developer/ceilometer/， 我們看一下Ceilometer工程的現(xiàn)狀, 架構(gòu)如下：
運(yùn)行OpenStack各組件的節(jié)點(diǎn)上一般有Agent來(lái)收集信息，收集后發(fā)給MQ，Ceilometer的Collector進(jìn)程監(jiān)控到數(shù)據(jù)之后存儲(chǔ)到DB之中。從http://docs.openstack.org/developer/ceilometer/measurements.html 這頁(yè)顯示的監(jiān)控項(xiàng)來(lái)看，目前Ceilometer監(jiān)控來(lái)的數(shù)據(jù)主要來(lái)只是用來(lái)做billing的。
文章來(lái)源：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).
defaultstimeout 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.
已解決： cd/var/lib/dpkg
sudo mv info info.bak
sudo mkdir info
| Druid | DBCP | C3P0 | JBoss | Weblogic | BonCP | |
|---|---|---|---|---|---|---|
| 數(shù)據(jù)庫(kù)用戶(hù)名稱(chēng) | Username | Username | User | user-name | ||
| 數(shù)據(jù)庫(kù)密碼 | Password | Password | Password | password | ||
| 驅(qū)動(dòng)名稱(chēng) | DriverClassName | DriverClassName | DriverClass | driver-class | DriverName | |
| JDBC連接串 | Url | Url | JdbcUrl | connection-url | Url | |
| JDBC連接屬性 | Properties | Properties | Properties | connection-property | Properties | |
| 初始化大小 | InitialSize | InitialSize | InitialPoolSize | Initial Capacity | ||
| 連接池最小空閑 | MinIdle | MinIdle | MinPoolSize | min-pool-size | ||
| 連接池最大空閑 | MaxIdle | MaxIdle | MaxPoolSize | max-pool-size | ||
| 連接池最大使用連接數(shù)量 | MaxActive | MaxActive | MaximumCapacity | |||
| 最小逐出時(shí)間 | MinEvictableIdleTimeMillis | MinEvictableIdleTimeMillis | ||||
| 最多等待線(xiàn)程 | MaxWaitThreadCount | MaxWaitThreadCount | HighestNumWaiters | |||
| 連接池增長(zhǎng)步長(zhǎng) | AcquireIncrement | CapacityIncrement | ||||
| 獲取連接時(shí)測(cè)試是否有效 | TestOnBorrow | TestOnBorrow | TestConnectionOnCheckout | |||
| 歸還連接時(shí)是否測(cè)試有效 | TestOnReturn | TestOnReturn | TestConnectionOnCheckin | TestConnectionsOnReserve | ||
| 測(cè)試有效用的SQL Query | ValidationQuery | ValidationQuery | PreferredTestQuery | |||
| 測(cè)試有效的超時(shí)時(shí)間 | ValidationQueryTimeout | ValidationQueryTimeout | ||||
| 連接初始化SQL | ConnectionInitSqls | ConnectionInitSqls | InitSQL | |||
| 連接最大存活實(shí)現(xiàn) | MaxConnectionAge | |||||
| 連接泄漏的超時(shí)時(shí)間 | RemoveAbandonedTimeout | RemoveAbandonedTimeout | UnreturnedConnectionTimeout | |||
| 關(guān)閉泄漏的連接時(shí)打印堆棧信息 | LogAbandoned | LogAbandoned | DebugUnreturnedConnectionStackTraces | |||
| 逐出連接的檢測(cè)時(shí)間間隔 | TimeBetweenEvictionRunsMillis | TimeBetweenEvictionRunsMillis | ShrinkFrequencySeconds | |||
| Statement緩存算法 | StatementCacheType | |||||
| Statement緩存大小 | StatementCacheSize | |||||
| TestTableName | ||||||
| SecondsToTrustAnIdlePoolConnection | ||||||
| ConnectionCreationRetryFrequencySeconds | ||||||
| LoginDelaySeconds | ||||||
| Profile Connection Usage | ||||||
| Profile Connection Reservation Wait | ||||||
| Profile Connection Leak | ||||||
| Profile Connection Reservation Failed | ||||||
| Profile Statement Cache Entry | ||||||
| Profile Statement Usage | ||||||
| Profile Connection Last Usage | ||||||
| Profile Connection Multithreaded Usage | ||||||
| Profile Harvest Frequency Seconds | ||||||
| 連接池?cái)U(kuò)展 | Filters | DriverInterceptor | ||||
| CredentialMappingEnabled | ||||||
| InactiveConnectionTimeoutSeconds | ||||||
| ConnectionReserveTimeoutSeconds | ||||||
| QueryTimeout | StatementTimeout | |||||
| 連接池關(guān)閉時(shí)對(duì)正在使用連接的處理方式 | IgnoreInUseConnectionsEnabled | |||||
| 把連接放到ThreadLocal中 | PinnedToThread | |||||
| 關(guān)閉“贓”連接（調(diào)用過(guò)getVendorConnection方法） | RemoveInfectedConnections |
現(xiàn)在網(wǎng)站發(fā)展的趨勢(shì)對(duì)網(wǎng)絡(luò)負(fù)載均衡的使用是隨著網(wǎng)站規(guī)模的提升根據(jù)不同的階段來(lái)使用不同的技術(shù)：
一種是通過(guò)硬件來(lái)進(jìn)行進(jìn)行，常見(jiàn)的硬件有比較昂貴的NetScaler、F5、Radware和Array等商用的負(fù)載均衡器，它的優(yōu)點(diǎn)就是有專(zhuān)業(yè)的維護(hù)團(tuán)隊(duì)來(lái)對(duì)這些服務(wù)進(jìn)行維護(hù)、缺點(diǎn)就是花銷(xiāo)太大，所以對(duì)于規(guī)模較小的網(wǎng)絡(luò)服務(wù)來(lái)說(shuō)暫時(shí)還沒(méi)有需要使用；另外一種就是類(lèi)似于LVS/HAProxy、Nginx的基于Linux的開(kāi)源免費(fèi)的負(fù)載均衡軟件策略,這些都是通過(guò)軟件級(jí)別來(lái)實(shí)現(xiàn)，所以費(fèi)用非常低廉，所以我個(gè)也比較推薦大家采用第二種方案來(lái)實(shí)施自己網(wǎng)站的負(fù)載均衡需求。
近期朋友劉鑫(紫雨荷雪)的項(xiàng)目成功上線(xiàn)了，PV達(dá)到了億級(jí)/日的訪問(wèn)量，最前端用的是HAProxy+Keepalived雙機(jī)作的負(fù)載均衡器 /反向代理，整個(gè)網(wǎng)站非常穩(wěn)定；這讓我更堅(jiān)定了以前跟老男孩前輩聊的關(guān)于網(wǎng)站架構(gòu)比較合理設(shè)計(jì)的架構(gòu)方案：即Nginx /HAProxy+Keepalived作Web最前端的負(fù)載均衡器，后端的MySQL數(shù)據(jù)庫(kù)架構(gòu)采用一主多從，讀寫(xiě)分離的方式，采用LVS+Keepalived的方式。
在這里我也有一點(diǎn)要跟大家申明下：很多朋友擔(dān)心軟件級(jí)別的負(fù)載均衡在高并發(fā)流量沖擊下的穩(wěn)定情況，事實(shí)是我們通過(guò)成功上線(xiàn)的許多網(wǎng)站發(fā)現(xiàn)，它們的穩(wěn) 定性也是非常好的，宕機(jī)的可能性微乎其微，所以我現(xiàn)在做的項(xiàng)目，基本上沒(méi)考慮服務(wù)級(jí)別的高可用了。相信大家對(duì)這些軟件級(jí)別的負(fù)載均衡軟件都已經(jīng)有了很深的 的認(rèn)識(shí)，下面我就它們的特點(diǎn)和適用場(chǎng)合分別說(shuō)明下。
LVS：使用集群技術(shù)和Linux操作系統(tǒng)實(shí)現(xiàn)一個(gè)高性能、高可用的服務(wù)器，它具有很好的可伸縮性（Scalability)、可靠性（Reliability)和可管理性（Manageability)，感謝章文嵩博士為我們提供如此強(qiáng)大實(shí)用的開(kāi)源軟件。
LVS的特點(diǎn)是：
- 抗負(fù)載能力強(qiáng)、是工作在網(wǎng)絡(luò)4層之上僅作分發(fā)之用，沒(méi)有流量的產(chǎn)生，這個(gè)特點(diǎn)也決定了它在負(fù)載均衡軟件里的性能最強(qiáng)的；
- 配置性比較低，這是一個(gè)缺點(diǎn)也是一個(gè)優(yōu)點(diǎn)，因?yàn)闆](méi)有可太多配置的東西，所以并不需要太多接觸，大大減少了人為出錯(cuò)的幾率；
- 工作穩(wěn)定，自身有完整的雙機(jī)熱備方案，如LVS+Keepalived和LVS+Heartbeat，不過(guò)我們?cè)陧?xiàng)目實(shí)施中用得最多的還是LVS/DR+Keepalived；
- 無(wú)流量，保證了均衡器IO的性能不會(huì)收到大流量的影響；
- 應(yīng)用范圍比較廣，可以對(duì)所有應(yīng)用做負(fù)載均衡；
- 軟件本身不支持正則處理，不能做動(dòng)靜分離，這個(gè)就比較遺憾了；其實(shí)現(xiàn)在許多網(wǎng)站在這方面都有較強(qiáng)的需求，這個(gè)是Nginx/HAProxy+Keepalived的優(yōu)勢(shì)所在。
- 如果是網(wǎng)站應(yīng)用比較龐大的話(huà)，實(shí)施LVS/DR+Keepalived起來(lái)就比較復(fù)雜了，特別后面有Windows Server應(yīng)用的機(jī)器的話(huà)，如果實(shí)施及配置還有維護(hù)過(guò)程就比較復(fù)雜了，相對(duì)而言，Nginx/HAProxy+Keepalived就簡(jiǎn)單多了。站長(zhǎng)教學(xué)網(wǎng) eduyo.com
Nginx的特點(diǎn)是：
- 工作在網(wǎng)絡(luò)的7層之上，可以針對(duì)http應(yīng)用做一些分流的策略，比如針對(duì)域名、目錄結(jié)構(gòu)，它的正則規(guī)則比HAProxy更為強(qiáng)大和靈活，這也是許多朋友喜歡它的原因之一；
- Nginx對(duì)網(wǎng)絡(luò)的依賴(lài)非常小，理論上能ping通就就能進(jìn)行負(fù)載功能，這個(gè)也是它的優(yōu)勢(shì)所在；
- Nginx安裝和配置比較簡(jiǎn)單，測(cè)試起來(lái)比較方便；
- 也可以承擔(dān)高的負(fù)載壓力且穩(wěn)定，一般能支撐超過(guò)幾萬(wàn)次的并發(fā)量；
- Nginx可以通過(guò)端口檢測(cè)到服務(wù)器內(nèi)部的故障，比如根據(jù)服務(wù)器處理網(wǎng)頁(yè)返回的狀態(tài)碼、超時(shí)等等，并且會(huì)把返回錯(cuò)誤的請(qǐng)求重新提交到另一個(gè)節(jié)點(diǎn)，不過(guò)其中缺點(diǎn)就是不支持url來(lái)檢測(cè)；
- Nginx僅能支持http和Email，這樣就在適用范圍上面小很多，這個(gè)它的弱勢(shì)；
- Nginx不僅僅是一款優(yōu)秀的負(fù)載均衡器/反向代理軟件，它同時(shí)也是功能強(qiáng)大的Web應(yīng)用服務(wù)器。LNMP現(xiàn)在也是非常流行的web架構(gòu)，大有和以前最流行的LAMP架構(gòu)分庭抗?fàn)幹畡?shì)，在高流量的環(huán)境中也有很好的效果。
- Nginx現(xiàn)在作為Web反向加速緩存越來(lái)越成熟了，很多朋友都已在生產(chǎn)環(huán)境下投入生產(chǎn)了，而且反映效果不錯(cuò)，速度比傳統(tǒng)的Squid服務(wù)器更快，有興趣的朋友可以考慮用其作為反向代理加速器。
HAProxy的特點(diǎn)是：
- HAProxy是支持虛擬主機(jī)的，以前有朋友說(shuō)這個(gè)不支持虛擬主機(jī)，我這里特此更正一下。
- 能夠補(bǔ)充N(xiāo)ginx的一些缺點(diǎn)比如Session的保持，Cookie的引導(dǎo)等工作
- 支持url檢測(cè)后端的服務(wù)器出問(wèn)題的檢測(cè)會(huì)有很好的幫助。
- 它跟LVS一樣，本身僅僅就只是一款負(fù)載均衡軟件；單純從效率上來(lái)講HAProxy更會(huì)比Nginx有更出色的負(fù)載均衡速度，在并發(fā)處理上也是優(yōu)于Nginx的。
- HAProxy可以對(duì)Mysql讀進(jìn)行負(fù)載均衡，對(duì)后端的MySQL節(jié)點(diǎn)進(jìn)行檢測(cè)和負(fù)載均衡，不過(guò)在后端的MySQL slaves數(shù)量超過(guò)10臺(tái)時(shí)性能不如LVS，所以我向大家推薦LVS+Keepalived。
- HAProxy的算法現(xiàn)在也越來(lái)越多了，具體有如下8種：
① roundrobin，表示簡(jiǎn)單的輪詢(xún)，這個(gè)不多說(shuō)，這個(gè)是負(fù)載均衡基本都具備的；
② static-rr，表示根據(jù)權(quán)重，建議關(guān)注；
③ leastconn，表示最少連接者先處理，建議關(guān)注；
④ source，表示根據(jù)請(qǐng)求源IP，這個(gè)跟Nginx的IP_hash機(jī)制類(lèi)似，我們用其作為解決session問(wèn)題的一種方法，建議關(guān)注；
⑤ ri，表示根據(jù)請(qǐng)求的URI；
⑥ rl_param，表示根據(jù)請(qǐng)求的URl參數(shù)'balance url_param' requires an URL parameter name；
⑦ hdr(name)，表示根據(jù)HTTP請(qǐng)求頭來(lái)鎖定每一次HTTP請(qǐng)求；
⑧ rdp-cookie(name)，表示根據(jù)據(jù)cookie(name)來(lái)鎖定并哈希每一次TCP請(qǐng)求。
Nginx和LVS作對(duì)比的結(jié)果
1、Nginx工作在網(wǎng)絡(luò)的7層，所以它可以針對(duì)http應(yīng)用本身來(lái)做分流策略，比如針對(duì)域名、目錄結(jié)構(gòu)等，相比之下LVS并不具備這樣的功能，所 以 Nginx單憑這點(diǎn)可利用的場(chǎng)合就遠(yuǎn)多于LVS了；但Nginx有用的這些功能使其可調(diào)整度要高于LVS，所以經(jīng)常要去觸碰觸碰，由LVS的第2條優(yōu)點(diǎn) 看，觸碰多了，人為出問(wèn)題的幾率也就會(huì)大。
2、Nginx對(duì)網(wǎng)絡(luò)的依賴(lài)較小，理論上只要ping得通，網(wǎng)頁(yè)訪問(wèn)正常，Nginx就能連得通，Nginx同時(shí)還能區(qū)分內(nèi)外網(wǎng)，如果是同時(shí)擁有內(nèi)外網(wǎng)的 節(jié)點(diǎn)，就相當(dāng)于單機(jī)擁有了備份線(xiàn)路；LVS就比較依賴(lài)于網(wǎng)絡(luò)環(huán)境，目前來(lái)看服務(wù)器在同一網(wǎng)段內(nèi)并且LVS使用direct方式分流，效果較能得到保證。另 外注意，LVS需要向托管商至少申請(qǐng)多一個(gè)ip來(lái)做Visual IP，貌似是不能用本身的IP來(lái)做VIP的。要做好LVS管理員，確實(shí)得跟進(jìn)學(xué)習(xí)很多有關(guān)網(wǎng)絡(luò)通信方面的知識(shí)，就不再是一個(gè)HTTP那么簡(jiǎn)單了。站長(zhǎng)教學(xué)網(wǎng) eduyo.com
3、Nginx安裝和配置比較簡(jiǎn)單，測(cè)試起來(lái)也很方便，因?yàn)樗灸馨彦e(cuò)誤用日志打印出來(lái)。LVS的安裝和配置、測(cè)試就要花比較長(zhǎng)的時(shí)間了，因?yàn)橥纤觯琇VS對(duì)網(wǎng)絡(luò)依賴(lài)比較大，很多時(shí)候不能配置成功都是因?yàn)榫W(wǎng)絡(luò)問(wèn)題而不是配置問(wèn)題，出了問(wèn)題要解決也相應(yīng)的會(huì)麻煩得多。
4、Nginx也同樣能承受很高負(fù)載且穩(wěn)定，但負(fù)載度和穩(wěn)定度差LVS還有幾個(gè)等級(jí)：Nginx處理所有流量所以受限于機(jī)器IO和配置；本身的bug也還是難以避免的；Nginx沒(méi)有現(xiàn)成的雙機(jī)熱備方案，所以跑在單機(jī)上還是風(fēng)險(xiǎn)較大，單機(jī)上的事情全都很難說(shuō)。
5、Nginx可以檢測(cè)到服務(wù)器內(nèi)部的故障，比如根據(jù)服務(wù)器處理網(wǎng)頁(yè)返回的狀態(tài)碼、超時(shí)等等，并且會(huì)把返回錯(cuò)誤的請(qǐng)求重新提交到另一個(gè)節(jié)點(diǎn)。目前LVS中 ldirectd也能支持針對(duì)服務(wù)器內(nèi)部的情況來(lái)監(jiān)控，但LVS的原理使其不能重發(fā)請(qǐng)求。重發(fā)請(qǐng)求這點(diǎn)，譬如用戶(hù)正在上傳一個(gè)文件，而處理該上傳的節(jié)點(diǎn)剛 好在上傳過(guò)程中出現(xiàn)故障，Nginx會(huì)把上傳切到另一臺(tái)服務(wù)器重新處理，而LVS就直接斷掉了，如果是上傳一個(gè)很大的文件或者很重要的文件的話(huà)，用戶(hù)可能 會(huì)因此而惱火。
6、Nginx對(duì)請(qǐng)求的異步處理可以幫助節(jié)點(diǎn)服務(wù)器減輕負(fù)載，假如使用apache直接對(duì)外服務(wù)，那么出現(xiàn)很多的窄帶鏈接時(shí)apache服務(wù)器將會(huì)占用大 量?jī)?nèi)存而不能釋放，使用多一個(gè)Nginx做apache代理的話(huà)，這些窄帶鏈接會(huì)被Nginx擋住，apache上就不會(huì)堆積過(guò)多的請(qǐng)求，這樣就減少了相 當(dāng)多的內(nèi)存占用。這點(diǎn)使用squid也有相同的作用，即使squid本身配置為不緩存，對(duì)apache還是有很大幫助的。LVS沒(méi)有這些功能，也就無(wú)法能 比較。
7、Nginx能支持http和email（email的功能估計(jì)比較少人用），LVS所支持的應(yīng)用在這點(diǎn)上會(huì)比Nginx更多。在使用上，一般最前端所 采取的策略應(yīng)是LVS，也就是DNS的指向應(yīng)為L(zhǎng)VS均衡器，LVS的優(yōu)點(diǎn)令它非常適合做這個(gè)任務(wù)。重要的ip地址，最好交由LVS托管，比如數(shù)據(jù)庫(kù)的 ip、webservice服務(wù)器的ip等等，這些ip地址隨著時(shí)間推移，使用面會(huì)越來(lái)越大，如果更換ip則故障會(huì)接踵而至。所以將這些重要ip交給 LVS托管是最為穩(wěn)妥的，這樣做的唯一缺點(diǎn)是需要的VIP數(shù)量會(huì)比較多。Nginx可作為L(zhǎng)VS節(jié)點(diǎn)機(jī)器使用，一是可以利用Nginx的功能，二是可以利 用Nginx的性能。當(dāng)然這一層面也可以直接使用squid，squid的功能方面就比Nginx弱不少了，性能上也有所遜色于Nginx。Nginx也 可作為中層代理使用，這一層面Nginx基本上無(wú)對(duì)手，唯一可以撼動(dòng)Nginx的就只有l(wèi)ighttpd了，不過(guò)lighttpd目前還沒(méi)有能做到 Nginx完全的功能，配置也不那么清晰易讀。另外，中層代理的IP也是重要的，所以中層代理也擁有一個(gè)VIP和LVS是最完美的方案了。具體的應(yīng)用還得 具體分析，如果是比較小的網(wǎng)站（日PV<1000萬(wàn)），用Nginx就完全可以了，如果機(jī)器也不少，可以用DNS輪詢(xún)，LVS所耗費(fèi)的機(jī)器還是比較 多的；大型網(wǎng)站或者重要的服務(wù)，機(jī)器不發(fā)愁的時(shí)候，要多多考慮利用LVS
roundrobin Each server is used in turns, according to their weights.
This is the smoothest and fairest algorithm when the server's
processing time remains equally distributed. This algorithm
is dynamic, which means that server weights may be adjusted
on the fly for slow starts for instance. It is limited by
design to 4128 active servers per backend. Note that in some
large farms, when a server becomes up after having been down
for a very short time, it may sometimes take a few hundreds
requests for it to be re-integrated into the farm and start
receiving traffic. This is normal, though very rare. It is
indicated here in case you would have the chance to observe
it, so that you don't worry.
roundrobin:每個(gè)server根據(jù)權(quán)重依次被輪詢(xún)，
server的權(quán)重可以實(shí)時(shí)地被調(diào)整。對(duì)于每個(gè)haproxy的backend servers的數(shù)目
而言被限制在4128個(gè)活躍數(shù)目之內(nèi)。
static-rr Each server is used in turns, according to their weights.
This algorithm is as similar to roundrobin except that it is
static, which means that changing a server's weight on the
fly will have no effect. On the other hand, it has no design
limitation on the number of servers, and when a server goes
up, it is always immediately reintroduced into the farm, once
the full map is recomputed. It also uses slightly less CPU to
run (around -1%).
靜態(tài)roundrobin(static-rr):跟roundrobin類(lèi)似，唯一的區(qū)別是不可以動(dòng)態(tài)實(shí)時(shí)
server權(quán)重和backend 的server數(shù)目沒(méi)有上限。
leastconn The server with the lowest number of connections receives the
connection. Round-robin is performed within groups of servers
of the same load to ensure that all servers will be used. Use
of this algorithm is recommended where very long sessions are
expected, such as LDAP, SQL, TSE, etc... but is not very well
suited for protocols using short sessions such as HTTP. This
algorithm is dynamic, which means that server weights may be
adjusted on the fly for slow starts for instance.
最小連接數(shù)目負(fù)載均衡策略（leastconn）：round-robin適合于各個(gè)server負(fù)載相同的情況。
最小連接數(shù)目算法適合于長(zhǎng)時(shí)間會(huì)話(huà)，如LDAP，SQL，TSE，但是并不適合于HTTP短連接的協(xié)議。
source The source IP address is hashed and divided by the total
weight of the running servers to designate which server will
receive the request. This ensures that the same client IP
address will always reach the same server as long as no
server goes down or up. If the hash result changes due to the
number of running servers changing, many clients will be
directed to a different server. This algorithm is generally
used in TCP mode where no cookie may be inserted. It may also
be used on the Internet to provide a best-effort stickiness
to clients which refuse session cookies. This algorithm is
static by default, which means that changing a server's
weight on the fly will have no effect, but this can be
changed using "hash-type".
源IP hash散列調(diào)度：將源ip地址進(jìn)行hash，再根據(jù)hasn求模或者一致性hash定位到
hash表中的server上。相同的ip地址的請(qǐng)求被分發(fā)到同一個(gè)server上。但當(dāng)server的數(shù)量變化時(shí)，
來(lái)自于同一client的請(qǐng)求可能會(huì)被分發(fā)到不同的server上。這個(gè)算法通常用在沒(méi)有cookie的tcp模式下。
uri The left part of the URI (before the question mark) is hashed
and divided by the total weight of the running servers. The
result designates which server will receive the request. This
ensures that a same URI will always be directed to the same
server as long as no server goes up or down. This is used
with proxy caches and anti-virus proxies in order to maximize
the cache hit rate. Note that this algorithm may only be used
in an HTTP backend. This algorithm is static by default,
which means that changing a server's weight on the fly will
have no effect, but this can be changed using "hash-type".
This algorithm support two optional parameters "len" and
"depth", both followed by a positive integer number. These
options may be helpful when it is needed to balance servers
based on the beginning of the URI only. The "len" parameter
indicates that the algorithm should only consider that many
characters at the beginning of the URI to compute the hash.
Note that having "len" set to 1 rarely makes sense since most
URIs start with a leading "/".
The "depth" parameter indicates the maximum directory depth
to be used to compute the hash. One level is counted for each
slash in the request. If both parameters are specified, the
evaluation stops when either is reached.
url_param The URL parameter specified in argument will be looked up in
the query string of each HTTP GET request.
If the modifier "check_post" is used, then an HTTP POST
request entity will be searched for the parameter argument,
when it is not found in a query string after a question mark
('?') in the URL. Optionally, specify a number of octets to
wait for before attempting to search the message body. If the
entity can not be searched, then round robin is used for each
request. For instance, if your clients always send the LB
parameter in the first 128 bytes, then specify that. The
default is 48. The entity data will not be scanned until the
required number of octets have arrived at the gateway, this
is the minimum of: (default/max_wait, Content-Length or first
chunk length). If Content-Length is missing or zero, it does
not need to wait for more data than the client promised to
send. When Content-Length is present and larger than
<max_wait>, then waiting is limited to <max_wait> and it is
assumed that this will be enough data to search for the
presence of the parameter. In the unlikely event that
Transfer-Encoding: chunked is used, only the first chunk is
scanned. Parameter values separated by a chunk boundary, may
be randomly balanced if at all.
If the parameter is found followed by an equal sign ('=') and
a value, then the value is hashed and divided by the total
weight of the running servers. The result designates which
server will receive the request.
This is used to track user identifiers in requests and ensure
that a same user ID will always be sent to the same server as
long as no server goes up or down. If no value is found or if
the parameter is not found, then a round robin algorithm is
applied. Note that this algorithm may only be used in an HTTP
backend. This algorithm is static by default, which means
that changing a server's weight on the fly will have no
effect, but this can be changed using "hash-type".
hdr(name) The HTTP header <name> will be looked up in each HTTP request.
Just as with the equivalent ACL 'hdr()' function, the header
name in parenthesis is not case sensitive. If the header is
absent or if it does not contain any value, the roundrobin
algorithm is applied instead.
An optional 'use_domain_only' parameter is available, for
reducing the hash algorithm to the main domain part with some
specific headers such as 'Host'. For instance, in the Host
value "
This algorithm is static by default, which means that
changing a server's weight on the fly will have no effect,
but this can be changed using "hash-type".
rdp-cookie
rdp-cookie(name)
The RDP cookie <name> (or "mstshash" if omitted) will be
looked up and hashed for each incoming TCP request. Just as
with the equivalent ACL 'req_rdp_cookie()' function, the name
is not case-sensitive. This mechanism is useful as a degraded
persistence mode, as it makes it possible to always send the
same user (or the same session ID) to the same server. If the
cookie is not found, the normal roundrobin algorithm is
used instead.
Note that for this to work, the frontend must ensure that an
RDP cookie is already present in the request buffer. For this
you must use 'tcp-request content accept' rule combined with
a 'req_rdp_cookie_cnt' ACL.
This algorithm is static by default, which means that
changing a server's weight on the fly will have no effect,
but this can be changed us
3 在服務(wù)器上用mysql -h 192.168.0.1 -u root -p mysql命令登錄mysql數(shù)據(jù)庫(kù)
然后用grant命令下放權(quán)限。
GRANT ALL PRIVILEGES ON *.* TO root@localhost IDENTIFIED BY 'root-password' WITH GRANT OPTION;
GRANT ALL PRIVILEGES ON *.* TO root@127.0.0.1 IDENTIFIED BY 'root-password' WITH GRANT OPTION;
GRANT ALL PRIVILEGES ON *.* TO root@'%' IDENTIFIED BY 'root-password' WITH GRANT OPTION;
例如：
GRANT ALL PRIVILEGES ON *.* TO root@'%' identified by '123456'
注意：自己根據(jù)情況修改以上命令中的 “用戶(hù)”“ip地址”“密碼”。
2 安裝和配置haproxy
option mysql-check [ user <username> ]
USE mysql; INSERT INTO user (Host,User) values ('<ip_of_haproxy>','<username>'); FLUSH PRIVILEGESheck
only consists in parsing the Mysql Handshake Initialisation packet or Error packet, we don't send anything in this mode. It was reported that it can generate lockout if check is too frequent and/or if there is not enough traffic. In fact, you need in this case to check MySQL "max_connect_errors" value as if a connection is established successfully within fewer than MySQL "max_connect_errors" attempts after a previous connection was interrupted, the error count for the host is cleared to zero. If HAProxy's server get blocked, the "FLUSH HOSTS" statement is the only way to unblock it.
配置：# this config needs haproxy-1.1.28 or haproxy-1.2.1 global
log 127.0.0.1
local0 info
#日志相關(guān)
log 127.0.0.1
local1 notice
maxconn 4096
daemon
#debug
#quiet defaults
log global mode http #option httplog option dontlognull retries 3 option redispatch maxconn 2000 contimeout 5000 clitimeout 50000 srvtimeout 50000 listen mysql bind 0.0.0.0:3333 #代理端口 mode tcp #模式 TCP option mysql-check user haproxy #mysql健康檢查 root為mysql登錄用戶(hù)名 balance roundrobin #調(diào)度算法 server mysql1 172.20.21.1:3306 weight 1 check inter 1s rise 2 fall 2 server mysql2 172.20.21.2:3306 weight 1 check inter 1s rise 2 fall 2 server mysql3 172.20.21.3:3306 weight 1 check inter 1s rise 2 fall 2 listen stats :1936 mode http stats enable stats hide-version stats realm Haproxy\ Statistics stats uri / stats auth admin:admin