高可用性(HA)的環境實做

        

        正當大量的資料及服務不斷湧向雲端的同時，也不斷的在考驗雲端的穩定度，本文主要敘述在建置資訊系統時，從伺服器、網路、Storage 及虛擬化的角度去思考並規劃具備高可用性 (HA) 的架構，增加系統的穩定度及彈性。

        身在雲端時代，大幅更改了過去的經驗，眾多主機可以虛擬化塞到一臺機器，還可以把又多又龐大的檔案上傳上去，各種服務的佈署更加快速；其實各項都考驗著雲端服務提供者的 「系統穩定度」，由於跑在雲上頭的服務日趨重要，那在建造的時候，也要考量到如何在各個關節去加強並預防災難的發生，此篇文章便是以基礎環境建設的角度下，去討論各項高可用性如何達成，作一個飛得很穩當的雲。

    高可用性 (High Availability) 的目的為減少停機時間，在大部的情形下，也就是單點故障 (Single Point Of Failure) 時，整個系統還可以運作下去，以資訊服務的基礎建設來說，要達成 HA 的目標，大致可從以下範圍著手:

1. 伺服器
2. Storage
3. 網路
4. 虛擬化及容錯移轉叢集

伺服器:

        以目前主流的 Server 來說，大部份還是購買機架式的 1U 及 2U 為主 (1U 為 4.445 公分高)，其實這兩者只差在擴充性，比較表格如下:

        其實要買哪一種，依照單位的需求來採買就好，一般來說，考慮到避免單點故障，因此建議電源供應器一定要裝兩個，如果貴單位的電力系統有兩條迴路，也建議可以分接在兩個電源供應器上，避免單條迴路損壞導致伺服器停擺，另外在乙太網路卡方面，雖然預設已有 2 到 4 個連接埠，但實體還是從同一張卡出去，乙太網路卡的價位目前不算太高，建議最好另外擴充一張卡，並且將不同功能的線路分散在兩張網路卡上，這部分在網路部分會詳述。

Storage:

       Storage 為每個雲端服務的命脈，非常的重要，也建議一定要做到高可用性，一般要做到高可用性，最常見的做法就是買有雙控制器 (Controller) 的機型，並且要將線路分別接在兩個 Controller 上，設定 MPIO(Multipath I/O)，才可在其中一個 Controller 發生單點故障時自動切換到第二個 Controller 繼續運作，也要確保 Storage 具有雙電源供應器的配置，如前文的 Server 一樣，建議要將兩個 Power 接在不同的迴路上以確保電源供應無虞。

    但如果有一天，資料不夠放，或是 Storage 老舊換新，需要停機時間搬資料，就會變得很麻煩，更難保哪天整櫃 Storage 都掛了，直接停擺給你看，這也不是沒有可能的，但是一旦發生了，Storage 裡面存放的資料幾乎都是非常重要的，停機的時間和損失的金錢是無法估算的，這也說明了 Storage 作 HA 的重要性，有個解決方式，就是把一樣的資料存到兩個 Storage 去，這樣單台要停機維護，或是單點故障時都可以讓服務不中斷，聽起來是預算非常高的單位才有辦法作到，但考量到資料如果非常重要的話，還是可以針對重點去建置，目前市面上有軟體跟硬體的解決方案都可以作到 Storage 的 HA，甚至還有一些附加功能 (Storage 虛擬化、利用 Cache 加速、連續資料保護 (CDP)、快照 (Snapshot) 等)，您可以依照需求，去挑選適合的解決方案。

    

        在線路方面，不論你是用 iSCSI 或是 Fibre Channel 的介面，也是有一些可以努力做到高可用性的地方，本文會以 Fibre Chaanel 來當例子，以下圖來解釋

圖一、 Storage 高可用性架構

    本架構是將前端 (Server) 跟後端 (Storage) 以 SAN Switch 切開，也就是上圖的 Front End 及 Back End，中間用 Storage Service Server 作連結，此 Server 為統整後方的 Storage 以提供前方的 Server 使用，具備兩台，中間會隨時同步確保資料正常，前端的每一台 Server 會各有一條光纖線連接至 Front End 的 SAN Switch，後端的 Storage 視頻寬而定要使用幾個光纖接頭至 Back End 的 SAN Switch(比較新的 Storage 至少每個 Controller 都會有兩個光纖接頭)，此架構的優點列舉如下:

• 線路連結整齊，伺服器端與 Storage 端分類清楚。
• 容錯程度高，可容許光纖線、SAN Switch、整櫃 Storage 損壞皆不會中斷儲存服務。
• 日後維護 Storage 設備不會有 Downtime，也方便作資料轉移或 Storage 升級或擴充。

    有人會有疑問，SAN Switch 一次配置四台費用不會過高嗎? 其實 SAN Switch 比較特別，以本案使用的 48 Port SAN Switch 為例，雖然買來有 48 個連接埠，但初始只有 16 個可以使用，其他連接埠要使用需要購買 License，與其花錢擴充還不如再買一台新的，在考量高可用性還有日後的擴充及管理，才會設計出此架構。

網路:

    網路的部份為雲端服務最重點的基礎建設之一，因為流量的大幅增加，還有各式各樣的需求，都讓網路規劃變得非常的關鍵，以下會以臺大建置一個 Hyper-V Cluster 的例子來說明怎麼作到網路的高可用性：

建置說明: 由於業務需要，計資中心需要新建一個容錯移轉叢集 (Cluster) 以提供虛擬機器服務，由於此機器上面運作的虛擬機器都非常重要，種類有 AD 服務，Exchange 服務，Web 服務等，不僅對外頻寬要足夠，還有即時移轉的需求 (Live Migration)。

初期的準備項目如下:

註 1: 
Access 為提供虛擬機器對外連線用

Live Migration: 為虛擬機器在實體機器間移動所需連線

Heartbeat : 容錯移轉叢集主機間互相溝通之線路

CSV Network : 連結 CSV(Cluster Shared Volumes) 的專用線路

Manage: 管理專用的線路

Backup: 備份 VM 用線路

註 2：
每種網路皆有兩條，目的為 Teaming 起來可以增加頻寬，又有兩條實體線路可互為備援。

圖 2、 網路高可用性架構

                        

    如圖所示，以上的網路配置，若有單張網路卡故障，單條線路損壞，單台 Switch 故障，單台防火牆故障，皆可以因為高可用性的關係，服務不中斷，由於不好的網路線壞掉的機率比其他裝置高，所以請務必用專業廠商製造的 CAT6 網路線，可以的話要以顏色區分並加上套環，方便辨認。

圖 3、 網路線比較

虛擬化及容錯移轉叢集:

    伺服器虛擬化可以降低實體機器數量，並快速的佈署新機器及增減運算資源，現在主要的產品包括 VMWare 及 Hyper-V，兩者在最新的版本上皆進步許多，不論是實體機器或是虛擬機器的性能都提升許多，如下表所示:

如果您已經決定要進行虛擬化，甚至要建置容錯移轉叢集，不管是何平台，皆要注意以下幾點:

• 各項硬體之韌體及驅動程式建置前需更新

        由於系統上線後，要做這件事會變得很麻煩，也不保證裝了新版之後會不會出問題，所   以要趁建置前檢查一下，可以的話盡量更新最新的穩定版驅動程式或韌體。

• 網路架構要注意分流及 HA

        以虛擬機器移轉來說，要耗用大量的網路流量，單條 1Gb 線路可能不夠，這時建議要用兩條線路進行 Teaming，互為備援並增加流量，另外備份的流量強烈建議要獨立開來，才可避免備份時的大量流量影響到虛擬機器，現在已經可以考慮採用 10Gb 線路，以應付日益俱增的備份需求，那如果貴單位的網路線路不夠多，卻想要使用容錯移轉叢集呢? 也不是沒有辦法的，假使只有兩條 1Gb 的線路，也是可以做到 HA 的，就是用 QoS 方式來限制各種網路流量的上限，以 Hyper-V 來說，可以參考這篇 KB

http://blogs.technet.com/b/askpfeplat/archive/2013/03/10/windows-server-2012-hyper-v-best-practices-in-easy-checklist-form.aspx

叢集還是可以運作，只是網路高峰時速度稍微慢一點，並且此兩條線路也具備互相備援的功能。

• 連結 Storage 部份務必要設定 MPIO

        由於 CPU 及記憶體運作速度都很快，因此虛擬機器的效能大部分就決定在 Storage，而叢集的命脈更是取決於共用磁碟區的健康，設定線路時請盡量以 MPIO 方式連接，並且要注意要各接在不同的 Controller 上，因為光纖線時間一久容易老化，你可不希望哪天只是因為線壞掉或更換線路，導致叢集上面的虛擬機器全部掛點吧!

• Hyper-V 容錯移轉叢集的 AD 要保持健康

        建置 Hyper-V 容錯移轉叢集一定要透過 AD，在此架構下，所有實體機器間的互相溝通，還有與共用磁碟區間的連接，都仰賴 AD，要是 AD 壞掉，你就會發現你的叢集也會廢掉一身武功，因此 AD 一定要兩台以上，以作為備援，如果你是因為要建新叢集所以要順便建新 AD，也建議不要把 AD 的虛擬硬碟放在共用磁碟區上，最好放在實體主機的本機硬碟裡 (所以 AD 虛擬機器不可以加入容錯移轉叢集的角色)，原因是如果有一天你無法連結到某一個共用磁碟區，剛好 AD 的 VM 放在這個共用磁碟區裡，結果 AD 死掉，造成 Cluster Crash，回復起來會很麻煩

• VMWare 的 vCenter 要考慮高可用性

         vCenter 是 VMWare 裡面最重要的角色之一，如果裝在實體機器上，萬一實體機器出現單點故障，就只能連進每一台 ESXi Server 進行管理，也無法作即時移轉 (vMotion)，因此建議把 vCenter 裝在虛擬機器上，這樣單台實體機器故障時，才可以在叢集裡移轉，確保服務正常。

結語  

    以上的步驟，為筆者這幾年的經驗累積，也許還有不足的地方，但是實務經驗上，若在建置的每個細節都考慮到高可用性，實際運作時系統就會更穩定，在找尋問題的時候也會更快速，願大家的系統都永遠健康!