❶ server2008+sql 2008做集群，用3台虛擬機測試，域也設置好了，就是不知道怎麼設置仲
有仲裁盤的情況，需要有共享存儲，建議先到文庫下載相應的配置文檔，按文檔操作。
❷ Greenplum集群部署和架構優化，我總結了5000字的心得
最近對離線數倉體系進行了擴容和架構改造，也算是一波三折，出了很多小插曲，有一些改進點對我們來說也是真空地帶，通過對比和模擬壓測總算是得到了預期的結果，這方面尤其值得一提的是郭運凱同學的敬業，很多前置的工作，優化和應用壓測的工作都是他完成的。
整體來說，整個事情的背景是因為伺服器硬體過保，剛好借著過保伺服器替換的機會來做集群架構的優化和改造。
1.集群架構改造的目標
在之前也總結過目前存在的一些潛在問題，也是本次部署架構改進的目標：
1）之前 的GP segment數量設計過度 ，因為資源限制，過多考慮了功能和性能，對於集群的穩定性和資源平衡性考慮有所欠缺，在每個物理機節點上部署了10個Primary,10個Mirror，一旦1個伺服器節點不可用，整個集群幾乎無法支撐業務。
2）GP集群 的存儲資源和性能的平衡不夠 ，GP存儲基於RAID-5,如果出現壞盤，磁碟重構的代價比較高，而且重構期間如果再出現壞盤，就會非常被動，而且對於離線數倉的數據質量要求較高，存儲容量相對不是很大，所以在存儲容量和性能的綜合之上，我們選擇了RAID-10。
3)集 群的異常場景的恢復需要完善， 集群在異常情況下（如伺服器異常宕機，數據節點不可用，伺服器後續過保實現節點滾動替換）的故障恢復場景測試不夠充分，導致在一些遷移和改造中，相對底氣不足，存在一些知識盲區。
4）集群版本過 低 ，功能和性能上存在改進空間。畢竟這個集群是4年前的版本，底層的PG節點的版本也比較舊了，在功能上和性能上都有一定的期望，至少能夠與時俱進。
5）操作系統版本升 級 ，之前的操作系統是基於CentOS6，至少需要適配CentOS 7 。
6）集群TPCH 壓測驗收 ，集群在完成部署之後，需要做一次整體的TPCH壓測驗收，如果存在明顯的問題需要不斷調整配置和架構，使得達到預期的性能目標。
此外在應用層面也有一些考慮，總而言之，是希望能夠解決絕大多數的痛點問題，無論是在系統層面，還是應用層面，都能上一個台階。
2.集群規劃設計的選型和思考
明確了目標，就是拆分任務來規劃設計了，在規劃設計方面主要有如下的幾個問題：
1）Greenplum的版本選擇 ，目前有兩個主要的版本類別，一個是開源版（Open Source distribution）和Pivotal官方版，它們的其中一個差異就是官方版需要注冊，簽署協議，在此基礎上還有GPCC等工具可以用，而開源版本可以實現源碼編譯或者rpm安裝，無法配置GPCC。綜合來看，我們選擇了 開源版本的6.16.2 ，這其中也詢問了一些行業朋友，特意選擇了幾個涉及穩定性bug修復的版本。
2）數據集市的技術選型 ，在數據集市的技術選型方面起初我是比較堅持基於PostgreSQL的模式，而業務側是希望對於一些較為復雜的邏輯能夠通過GP去支撐，一來二去之後，加上我咨詢了一些行業朋友的意見，是可以選擇基於GP的方案，於是我們就抱著試一試的方式做了壓測，所以數據倉庫和和數據集市會是兩個不同規模體量的GP集群來支撐。
3）GP的容量規劃 ，因為之前的節點設計有些過度，所以在數量上我們做了縮減，每台伺服器部署12個segment節點，比如一共12台伺服器，其中有10台伺服器是Segment節點，每台上面部署了6個Primary,6個Mirror，另外2台部署了Master和Standby，就是即（6+6）*10+2，整體的配置情況類似下面的模式。
4）部署架構方案選型 ，部署架構想起來比較容易，但是落實起來有很多的考慮細節，起初考慮GP的Master和Standby節點如果混用還是能夠節省一些資源，所以設計的數據倉庫和數據集市的部署架構是這樣考慮的，但是從走入部署階段之後，很快就發現這種交叉部署的模式是不可行的，或者說有一些復雜度。
除此之外，在單個GP集群的部署架構層面，還有4類方案考慮。
方案1 ：Master,Standby和segment混合部署
方案2 ：Master,Standby和segment獨立部署，整個集群的節點數會少一些
方案3 ：Segment獨立部署，Master,Standby虛擬機部署
方案4 ：最小化單節點集群部署（這是數據集市最保底的方案）
這方面存在較大的發揮空間，而且總體來說這種驗證磨合的成本也相對比較高，實踐給我上了一課， 越是想走捷徑，越是會讓你走一些彎路 ，而且有些時候的優化其實我也不知道改怎麼往下走，感覺已經無路可走，所以上面這4種方案其實我們都做了相關的測試和驗證。
3.集群架構的詳細設計和實踐
1）設計詳細的部署架構圖
在整體規劃之上，我設計了如下的部署架構圖，每個伺服器節點有6個Primary,6個Mirror,伺服器兩兩映射。
2）內核參數優化
按照官方文檔的建議和具體的配置情況，我們對內核參數做了如下的配置：
vm.swappiness=10
vm.zone_reclaim_mode = 0
vm.dirty_expire_centisecs = 500
vm.dirty_writeback_centisecs = 100
vm.dirty_background_ratio = 0 # See System Memory
vm.dirty_ratio = 0
vm.dirty_background_bytes = 1610612736
vm.dirty_bytes = 4294967296
vm.min_free_kbytes = 3943084
vm.overcommit_memory=2
kernel.sem = 500 2048000 200 4096
4.集群部署步驟
1）首先是配置/etc/hosts，需要把所有節點的IP和主機名都整理出來。
2）配置用戶，很常規的步驟
groupadd gpadmin
useradd gpadmin -g gpadmin
passwd gpadmin
3）配置sysctl.conf和資源配置
4）使用rpm模式安裝
# yum install -y apr apr-util bzip2 krb5-devel zip
# rpm -ivh open-source-greenplum-db-6.16.2-rhel7-x86_64.rpm
5）配置兩個host文件，也是為了後面進行統一部署方便，在此建議先開啟gpadmin的sudo許可權，可以通過gpssh處理一些較為復雜的批量操作
6）通過gpssh-exkeys來打通ssh信任關系，這里需要吐槽這個ssh互信，埠還得是22，否則處理起來很麻煩,需要修改/etc/ssh/sshd_config文件
gpssh-exkeys -f hostlist
7）較為復雜的一步是打包master的Greenplum-db-6.16.2軟體，然後分發到各個segment機器中，整個過程涉及文件打包，批量傳輸和配置，可以藉助gpscp和gpssh，比如gpscp傳輸文件，如下的命令會傳輸到/tmp目錄下
gpscp -f /usr/local/greenplum-db/conf/hostlist /tmp/greenplum-db-6.16.2.tar.gz =:/tmp
或者說在每台伺服器上面直接rpm -ivh安裝也可以。
8）Master節點需要單獨配置相關的目錄，而Segment節點的目錄可以提前規劃好，比如我們把Primary和Mirror放在不同的分區。
mkdir -p /data1/gpdata/gpdatap1
mkdir -p /data1/gpdata/gpdatap2
mkdir -p /data2/gpdata/gpdatam1
mkdir -p /data2/gpdata/gpdatam2
9）整個過程里最關鍵的就是gpinitsystem_config配置了，因為Segment節點的ID配置和命名，埠區間都是根據一定的規則來動態生成的，所以對於目錄的配置需要額外注意。
10）部署GP集群最關鍵的命令是
gpinitsystem -c gpinitsystem_config -s 【standby_hostname】
其中文件gpinitsystem_config的主要內容如下：
MASTER_HOSTNAME=xxxx
declare -a DATA_DIRECTORY=(/data1/gpdata/gpdatap1 /data1/gpdata/gpdatap2 /data1/gpdata/gpdatap3 /data1/gpdata/gpdatap4 /data1/gpdata/gpdatap5 /data1/gpdata/gpdatap6)
TRUSTED_SHELL=ssh
declare -a MIRROR_DATA_DIRECTORY=(/data2/gpdata/gpdatam1 /data2/gpdata/gpdatam2 /data2/gpdata/gpdatam3 /data2/gpdata/gpdatam4 /data2/gpdata/gpdatam5 /data2/gpdata/gpdatam6)
MACHINE_LIST_FILE=/usr/local/greenplum-db/conf/seg_hosts
整個過程大約5分鍾~10分鍾以內會完成，在部署過程中建議要查看後端的日誌查看是否有異常，異常情況下的體驗不是很好，可能會白等。
5.集群部署問題梳理
集群部署中還是有很多細節的問題，太基礎的就不提了，基本上就是配置，目錄許可權等問題，我提另外幾個：
1） 資源配置問題 ，如果/etc/security/limits.conf的資源配置不足會在安裝時有如下的警告：
2） 網路問題 ，集群部署完成後可以正常操作，但是在查詢數據的時候會拋出錯誤，比如SQL是這樣的，看起來很簡單：select count(*) from customer,但是會拋出如下的錯誤：
這個問題的主要原因還是和防火牆配置相關，其實不光需要配置INPUT的許可權，還需要配置OUTPUT的許可權。
對於數據節點可以開放略大的許可權，如：
入口的配置：
-A INPUT -p all -s xxxxx -j ACCEPT
出口的配置：
-A OUTPUT -p all -s xxxxx -j ACCEPT
3）網路配置問題 ，這個問題比較詭異的是，報錯和上面是一樣的，但是在排除了防火牆配置後，select count(*) from customer；這樣的語句是可以執行的，但是執行的等待時間較長，比如表lineitem這表比較大，過億的數據量，,在10個物理節點時，查詢響應時間是10秒，但是4個物理節點，查詢響應時間是在90秒，總體刪感覺說不過去。
為了排查網路問題，使用gpcheckperf等工具也做過測試，4節點和10節點的基礎配置也是相同的。
gpcheckperf -f /usr/local/greenplum-db/conf/seg_hosts -r N -d /tmp
$ cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
#127.0.0.1 test-dbs-gp-128-230
xxxxx.128.238 test-dbs-gp-svr-128-238
xxxxx.128.239 test-dbs-gp-svr-128-239
其中127.0.0.1的這個配置在segment和Master,Standby混部的情況是存在問題的，修正後就沒問題了，這個關鍵的問題也是郭運凱同學發現的。
5.集群故障恢復的測試
集群的故障測試是本次架構設計中的重點內容，所以這一塊也是躍躍欲試。
整體上我們包含兩個場景，伺服器宕機修復後的集群恢復和伺服器不可用時的恢復方式。
第一種場景相對比較簡單，就是讓Segment節點重新加入集群，並且在集群層面將Primary和Mirror的角色互換，而第二種場景相對時間較長一些，主要原因是需要重構數據節點，這個代價基本就就是PG層面的數據恢復了，為了整個測試和恢復能夠完整模擬，我們採用了類似的恢復方式，比如宕機修復使用了伺服器重啟來替代，而伺服器不可用則使用了清理數據目錄，類似於一台新配置機器的模式。
1）伺服器宕機修復後集群恢復
select * from gp_segment_configuration where status!='u'
gprecoverseg -o ./recov
gprecoverseg -r
select * from gp_segment_configuration where status='u'
2）伺服器不可用時集群恢復
重構數據節點的過程中，總體來看網路帶寬還是使用很充分的。
select * from gp_segment_configuration where status='u'
select * from gp_segment_configuration where status='u' and role!=preferred_role;
gprecoverseg -r
select * from gp_segment_configuration where status='u' and role!=preferred_role;
經過測試，重啟節點到數據修復，近50G數據耗時3分鍾左右
6.集群優化問題梳理
1）部署架構優化和迭代
對於優化問題，是本次測試中尤其關注，而且爭議較多的部分。
首先在做完初步選型後，數倉體系的部署相對是比較順利的，採用的是第一套方案。
數據集市的集群部分因為節點相對較少，所以就選用了第二套方案
實際測試的過程，因為配置問題導致TPCH的結果沒有達到預期。
所以這個階段也產生了一些疑問和懷疑，一種就是折回第一種方案，但是節點數會少很多，要不就是第三種採用虛擬機的模式部署，最保底的方案則是單節點部署，當然這是最牽強的方案。
這個階段確實很難，而在上面提到的修復了配置之後，集群好像突然開悟了一般，性能表現不錯，很快就完成了100G和1T數據量的TPCH測試。
在後續的改造中，我們也嘗試了第三套方案，基於虛擬機的模式，通過測試發現，遠沒有我們預期的那麼理想，在同樣的數據節點下，Master和Standby採用物理機和虛擬機，性能差異非常大，這個是出乎我們預料的。比如同樣的SQL,方案3執行需要2秒，而方案2則需要80秒，這個差異我們對比了很多指標，最後我個人理解差異還是在網卡部分。
所以經過對比後，還是選擇了方案2的混合部署模式。
2）SQL性能優化的分析
此外整個過程的TPCH也為集群的性能表現提供了參考。比如方案2的混合部署模式下，有一條SQL需要18秒，但是相比同類型的集群，可能就只需要2秒鍾左右，這塊顯然是存在問題的。
在排除了系統配置，硬體配置的差異之後，經典的解決辦法還是查看執行計劃。
性能較差的SQL執行計劃：
# explain analyze select count(*)from customer;
QUERY PLAN
Aggregate (cost=0.00..431.00 rows=1 width=8) (actual time=24792.916..24792.916 rows=1 loops=1)
-> Gather Motion 36:1 (slice1; segments: 36) (cost=0.00..431.00 rows=1 width=1) (actual time=3.255..16489.394 rows=150000000 loops=1)
-> Seq Scan on customer (cost=0.00..431.00 rows=1 width=1) (actual time=0.780..1267.878 rows=4172607 loops=1)
Planning time: 4.466 ms
(slice0) Executor memory: 680K bytes.
(slice1) Executor memory: 218K bytes avg x 36 workers, 218K bytes max (seg0).
Memory used: 2457600kB
Optimizer: Pivotal Optimizer (GPORCA)
Execution time: 24832.611 ms
(9 rows)
Time: 24892.500 ms
性能較好的SQL執行計劃：
# explain analyze select count(*)from customer;
QUERY PLAN
Aggregate (cost=0.00..842.08 rows=1 width=8) (actual time=1519.311..1519.311 rows=1 loops=1)
-> Gather Motion 36:1 (slice1; segments: 36) (cost=0.00..842.08 rows=1 width=8) (actual time=634.787..1519.214 rows=36 loops=1)
-> Aggregate (cost=0.00..842.08 rows=1 width=8) (actual time=1473.296..1473.296 rows=1 loops=1)
-> Seq Scan on customer (cost=0.00..834.33 rows=4166667 width=1) (actual time=0.758..438.319 rows=4172607 loops=1)
Planning time: 5.033 ms
(slice0) Executor memory: 176K bytes.
(slice1) Executor memory: 234K bytes avg x 36 workers, 234K bytes max (seg0).
Memory used: 2457600kB
Optimizer: Pivotal Optimizer (GPORCA)
Execution time: 1543.611 ms
(10 rows)
Time: 1549.324 ms
很明顯執行計劃是被誤導了，而誤導的因素則是基於統計信息，這個問題的修復很簡單：
analyze customer;
但是深究原因，則是在壓測時，先是使用了100G壓測，壓測完之後保留了原來的表結構，直接導入了1T的數據量，導致執行計劃這塊沒有更新。
3）集群配置優化
此外也做了一些集群配置層面的優化，比如對緩存做了調整。
gpconfig -c statement_mem -m 2457600 -v 2457600
gpconfig -c gp_vmem_protect_limit -m 32000 -v 32000
7.集群優化數據
最後來感受下集群的性能：
1）10個物理節點，（6+6）*10+2
tpch_1t=# iming on
Timing is on.
tpch_1t=# select count(*)from customer;
count
-----------
150000000
(1 row)
Time: 1235.801 ms
tpch_1t=# select count(*)from lineitem;
count
------------
5999989709
(1 row)
Time: 10661.756 ms
2）6個物理節點，（6+6）*6
# select count(*)from customer;
count
-----------
150000000
(1 row)
Time: 1346.833 ms
# select count(*)from lineitem;
count
------------
5999989709
(1 row)
Time: 18145.092 ms
3）4個物理節點，（6+6）*4
# select count(*)from customer;
count
-----------
150000000
(1 row)
Time: 1531.621 ms
# select count(*)from lineitem;
count
------------
5999989709
(1 row)
Time: 25072.501 ms
4）TPCH在不通架構模式下的性能比對 ，有19個查詢模型，有個別SQL邏輯過於復雜暫時忽略，也是郭運凱同學整理的列表。
在1T基準下的基準測試表現：
❸ centos7下pgsql9.6之citus集群搭建
事先准備，已經成功安裝好pgsql9.6
1.citus安裝
首先citus是pgsql的一個擴展，首先更新yum源，執行命令：yum update，然後安裝citus，執行命令：
2.登錄pgsql並創建citus擴展。執行命令：su postgres 然後執行：psql 登錄pgsql裡面，並執行sql命令 ：
如下圖所示：
然後會報如下圖所示錯誤。
然後找到文件pg_hba.conf，在文件末尾處添加配置:
然後重啟pgsql,一定要記得重啟pgsql，修改的配置文件才生效。
然後在登錄pgsql後，執行sql命令，創建citus擴展，如圖所示：
最後，克隆其他2台機器，ip地址分別為192.168.1.235和192.168.1.236 。執行命令如下圖，成功後也如圖所示，代表集群創建成功。
❹ SQLSERVER怎麼搭建伺服器集群實現負載均衡
很多組織機構慢慢的在不同的伺服器和地點部署SQL Server資料庫——為各種應用和目的——開始考慮通過SQL Server集群的方式來合並。
將SQL Server實例和資料庫合並到一個中心的地點可以減低成本，尤其是維護和軟硬體許可證。此外，在合並之後，可以減低所需機器的數量，這些機器就可以用於備用。
當尋找一個備用，比如高可用性的環境，企業常常決定部署Microsoft的集群架構。我常常被問到小的集群(由較少的節點組成)SQL Server實例和作為中心解決方案的大的集群哪一種更好。在我們比較了這兩個集群架構之後，我讓你們自己做決定。
什麼是Microsoft集群伺服器
MSCS是一個Windows Server企業版中的內建功能。這個軟體支持兩個或者更多伺服器節點連接起來形成一個「集群」，來獲得更高的可用性和對數據和應用更簡便的管理。MSCS可以自動的檢查到伺服器或者應用的失效，並從中恢復。你也可以使用它來(手動)移動伺服器之間的負載來平衡利用率以及無需停機時間來調度計劃中的維護任務。
這種集群設計使用軟體「心跳」來檢測應用或者伺服器的失效。在伺服器失效的事件中，它會自動將資源(比如磁碟和IP地址)的所有權從失效的伺服器轉移到活動的伺服器。注意還有方法可以保持心跳連接的更高的可用性，比如站點全面失效的情況下。
MSCS不要求在客戶計算機上安裝任何特殊軟體，因此用戶在災難恢復的經歷依賴於客戶-伺服器應用中客戶一方的本質。客戶的重新連接常常是透明的，因為MSCS在相同的IP地址上重啟應用、文件共享等等。進一步，為了災難恢復，集群的節點可以處於分離的、遙遠的地點。
在集群伺服器上的SQL Server
SQL Server 2000可以配置為最多4個節點的集群，而SQL Server 2005可以配置為最多8個節點的集群。當一個SQL Server實例被配置為集群之後，它的磁碟資源、IP地址和服務就形成了集群組來實現災難恢復。
SQL Server 2000允許在一個集群上安裝16個實例。根據在線幫助，「SQL Server 2005在一個伺服器或者處理器上可以支持最多50個SQL Server實例，」但是，「只能使用25個硬碟驅動器符，因此如果你需要更多的實例，那麼需要預先規劃。」
注意SQL Server實例的災難恢復階段是指SQL Server服務開始所需要的時間，這可能從幾秒鍾到幾分鍾。如果你需要更高的可用性，考慮使用其他的方法，比如log shipping和資料庫鏡像。
單個的大的SQL Server集群還是小的集群
下面是大的、由更多的節點組成的集群的優點：
◆更高的可用新(更多的節點來災難恢復)。
◆更多的負載均衡選擇(更多的節點)。
◆更低廉的維護成本。
◆增長的敏捷性。多達4個或者8個節點，依賴於SQL版本。
◆增強的管理性和簡化環境(需要管理的少了)。
◆更少的停機時間(災難恢復更多的選擇)。
◆災難恢復性能不受集群中的節點數目影響。
下面是單個大的集群的缺點：
◆集群節點數目有限(如果需要第9個節點怎麼辦)。
◆在集群中SQL實例數目有限。
◆沒有對失效的防護——如果磁碟陣列失效了，就不會發生災難恢復。
◆使用災難恢復集群，無法在資料庫級別或者資料庫對象級別，比如表，創建災難恢復集群。
虛擬化和集群
虛擬機也可以參與到集群中，虛擬和物理機器可以集群在一起，不會發生問題。SQL Server實例可以在虛擬機上，但是性能可能會受用影響，這依賴於實例所消耗的資源。在虛擬機上安裝SQL Server實例之前，你需要進行壓力測試來驗證它是否可以承受必要的負載。
在這種靈活的架構中，如果虛擬機和物理機器集群在一起，你可以在虛擬機和物理機器之間對SQL Server進行負載均衡。比如，使用虛擬機上的SQL Server實例開發應用。然後在你需要對開發實例進行壓力測試的時候，將它災難恢復到集群中更強的物理機器上。
集群伺服器可以用於SQL Server的高可用性、災難恢復、可擴展性和負載均衡。單個更大的、由更多的節點組成的集群往往比小的、只有少數節點的集群更好。大個集群允許更靈活環境，為了負載均衡和維護，實例可以從一個節點移動到另外的節點。
❺ 簡述mysql該怎樣進行集群部署
mysql集群部署操作如下：
1、在MySQL集群中.當table引擎為NDBCLUSTER時才做集群，其他非NDBCLUSTER表和一般MySQL資料庫表一樣，不會共享數據。NDBCLUSTER表數據存儲在Data node伺服器內存中，Data Node可以為1台或多台伺服器，它們之間存放共享數據。Data Node伺服器可以分組數據。
例如：2,3,4,5為四台Data Node伺服器ID. 2,3為組0； 4，5為組1； 2，3維持數據相同，4，5維持數據相同。 組0和組1維持數據不同。
2、sql node伺服器中，非NDBCLUSTER數據存在本身資料庫中，table引擎為NDBCLUSTER時，數據存儲在Data Node中。當查詢NDBCLUSTER表時，它會從Data node集群中提起數據.
3、Manager server管理SQl node和Data node狀態。
❻ 如何部署sql alwayson with cluster share volume
至少需要三台機器（我創建了三台虛擬機，一台是作為DC,DNS伺服器，兩台Nod3）
（備註：為啥一定要3台，因為SQL SERVER 的 Cluster服務不能安裝在域伺服器上。Windows2008 R2 和SQL SERVER 2012 一定要打上sp1.否則有不可預知的錯誤）
機器名
角色
OS
IP Address
DC
Domain Controller
Windows 2008R2
192.168.1.10
Node1
Cluster Node 1
Windows 2008R2
192.168.1.11 Public
192.168.2.1
心跳線
Node2
Cluster Node 2
Windows 2008R2
192.168.1.12 Public
192.168.2.2
心跳線窗體底端
首先配置Windows集群：
1. 安裝.NETFramework 3.5.1 Features和Failover Clustering
2. 安裝Windows KB 2494036
3.新建集群
4.選擇加入集群的伺服器：
5.檢測配置：
6.不需要選擇檢測共享磁碟（AlwaysOn不需要）
7.開始檢測：
8.檢測內容（檢測完成後可以導出Report）：
9.之後輸入Cluster名字和IP點擊下一步創建成功，成功後打開Server Manager查看集群配置(可以看到並沒有共享磁碟，跟傳統的集群還是有區別的)：
現在我們集群已經配置後了，下一步是安裝SQLServer並且配置Always On.
我們已經配置了Cluster,Part2 我們安裝SQL Server 2012 評估版（要使用64位的SQLServer, X86不支持Always On）並且配置Alaways On Group.
1. 以管理員身份安裝
2.選擇單機安裝（不是集群安裝）
3.SQL Server 2012的新功能，可以在安裝的時候搜索最新的補丁，將補丁也以前安裝（這個是可選項）
4.規則檢測
5.選擇安裝組件
6.實例名：
7.計算需要的磁碟空間：
8.Service賬戶（域賬戶）：
9.排序規則（可以根據自己需要選擇）：
10.設置許可權，資料庫文件備份地址以及Filestream選項：
11.安裝後需要重新啟動（可以查看安裝日誌）：
12.在ConfigurationManager中對SQL Server開啟Always OnHigh Availability(可以自動檢測到前面我們創建的Cluster名字)
設置更改後需要重啟Service.現在一切都具備了，我們可以配置Always On group了。
1.創建新的可用性組（可用性組向導，也可以用下面的選型）：
2.輸入可用性組的名字：
3.選擇組中的資料庫：
4.Replica 選擇Node2（選擇自動Failover/可讀資料庫）:
5.點擊下一步，Node1將會備份資料庫到Share Folder然後還原到Node2做同步 (Node1為主,Node2為輔助)
下一步就是測試Node2數據可讀已經Failover.
可用性組我們已經創建成功了，現在測試一下Node2 上讀取數據以及Failover.
1. 數據測據：Node1上創建表test插入記錄
在Node2上訪問test資料庫，數據可以查到（在Mirror中是不可以查詢的，而且數據同步不會導致Node2的連接斷掉）：
2. Failover測試：
連接到Node2:
Failover後（Primary已經變成Node2）：
可以看到Always On group 既保證了高可用性，有可以實現同步資料庫的只讀訪問，提供了硬體的利用率，非常給力的一個功能。
最後，建議在 「AlwaysOn 高可用性 」下-》 「可用性組」 中，增加一個可用性組偵聽器，在偵聽器中可以設定一個IP，對外用此IP提供服務。這樣，SQL服務的IP可以不同於windows集群的IP。兩項服務有可能會在兩台不同的機器上。