作者：陳柏鍠 / 計算機及資訊網路中心作業管理組幹事
大量的資料及服務不斷湧向雲端的同時，也不斷的在考驗雲端的穩定度。本文主要敘述在建置資訊系統時，從伺服器、網路、Storage及虛擬化的角度去思考並規劃具備高可用性(HA)的架構，增加系統的穩定度及彈性。
身在雲端時代，大幅更改了過去的經驗，眾多主機可以虛擬化到一台機器，還可以處理大量的檔案上傳，各種服務的佈署也更加快速，其實這些都考驗著雲端服務提供者的「系統穩定度」。由於跑在「雲」上頭的服務日趨重要，所以在建置的時候，也要考量到如何在各個關節去加強並預防災難的發生。本文便是以基礎環境建設的角度下，去討論各項雲端服務之高可用性如何達成，期能打造一個飛得很穩當的雲。
高可用性(High Availability)的目的為減少因為各種因素造成服務中斷的現象。在大部的情形下，也就是希望能在單點故障(Single Point Of Failure)時，整個系統還可以運作下去。以資訊服務的基礎建設來說，要達成HA的目標，大致可從以下範圍著手：
伺服器
Storage
網路
虛擬化及容錯移轉叢集
伺服器以目前主流的Server來說，大部份還是購買機架式的1U及2U為主(1U為4.445公分高)，其實這兩者只差在擴充性，比較表格如下：
項次
|
1 U Server
|
2U Server
|
CPU
|
最大兩顆
|
最大兩顆
|
硬碟
|
8 * 2.5吋
|
16 * 2.5吋
|
記憶體
|
24個插槽
|
24個插槽
|
擴充插槽
|
2 * PCIe
|
6* PCIe
|
Power
|
支援雙Power
|
支援雙Power
|
表一、伺服器比較
其實要買哪一種，依照單位的需求來採買就好。一般來說，考慮到避免單點故障，因此建議電源供應器一定要裝兩個。如果貴單位的電力系統有兩條迴路，也建議可以分接在兩個電源供應器上，避免單條迴路損壞導致伺服器停擺。另外，在乙太網路卡方面，雖然預設已有2到4個連接埠，但實體還是從同一張卡出去，乙太網路卡的價位目前不算太高，建議最好另外擴充一張網路卡，並且將不同功能的線路分散在兩張網路卡上，這部分在網路部分會詳述。
StorageStorage為每個雲端服務的命脈，非常的重要，也建議一定要做到高可用性。一般要做到高可用性，最常見的做法就是買有雙控制器(Controller)的機型，並且要將線路分別接在兩個Controller上，設定MPIO(Multipath I/O)，才可在其中一個Controller發生單點故障時自動切換到第二個Controller繼續運作，也要確保Storage具有雙電源供應器的配置。如同前述，建議要將兩個Power接在不同的迴路上以確保電源供應無虞。
但如果有一天，資料不夠放，或是Storage老舊換新，需要停機時間搬資料，就會變得很麻煩。更難保哪天整櫃Storage都掛了，直接停擺給您看，這也不是沒有可能的。但是一旦發生了，Storage裡面存放的資料幾乎都是非常重要的，停機的時間和損失的金錢是無法估算的，這也說明了Storage作HA的重要性。有個解決方式，就是把一樣的資料存到兩個Storage去，這樣單台要停機維護，或是單點故障時都可以讓服務不中斷。聽起來是預算非常高的單位才有辦法作到，但考量到資料如果非常重要的話，還是可以針對重點去建置。目前市面上有軟體跟硬體的解決方案都可以作到 Storage的HA，甚至還有一些附加功能(Storage虛擬化、利用Cache加速、連續資料保護(CDP)、快照(Snapshot)等)，可以依照需求去挑選適合的解決方案。
在線路方面，不論您是用iSCSI或是Fiber Channel(FC)的介面，也是有一些可以努力做到高可用性的地方，本文會以FC來當例子，以下圖來解釋
圖一、 Storage高可用性架構
本架構是將前端(Server)跟後端(Storage)以SAN Switch切開。也就是上圖的Front End及Back End，中間用Storage Service 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)。
初期的準備項目如下：
Server
|
機架式1U主機四台
|
OS
|
Windows Server 2012 Datacenter
|
網路卡
|
每台預設有4 Port (1Gb)乙太網卡，額外擴充一張4 Port(1Gb)乙太網卡，合計共8 Port
|
網路配置
|
Access * 2
Live Migration + Heartbeat * 2
CSV Network * 2
Manage + Backup * 2
|
表二、建置Cluster前置規劃
圖2、 網路高可用性架構
如圖所示，以上的網路配置，若有單張網路卡故障，單條線路損壞，單台Switch故障，單台防火牆故障，皆可以因為高可用性的關係，服務不中斷。由於網路線故障的機率比其他裝置高，所以請務必用專業廠商製造的CAT6網路線，可以的話要以顏色區分並加上套環，方便辨認。
圖3、 網路線比較
虛擬化及容錯移轉叢集：
伺服器虛擬化可以降低實體機器數量，並快速的佈署新機器及增減運算資源，現在主要的產品包括VMWare 及Hyper-V，兩者在最新的版本上皆進步許多，不論是實體機器或是虛擬機器的性能都提升許多，如下表所示：
|
Hyper-V 3.0
|
vSphere 5.1
|
實體主機
|
邏輯處理器數量
|
320
|
256
|
最大記憶體容量
|
4TB
|
2TB
|
虛擬CPU最大數量
|
2048顆
|
2048顆
|
可同時執行VM數
|
1024
|
512
|
虛擬機器
|
虛擬CPU最大數量
|
64顆
|
64顆
|
記憶體最大容量
|
1TB
|
1TB
|
虛擬磁碟大小
|
64TB
|
2TB
|
容錯移轉叢集
Cluster
|
同時執行主機數量
|
64台
|
32台
|
同時執行VM數
|
4000台
|
4000台
|
表三、虛擬化產品比較
如果您已經決定要進行虛擬化，甚至要建置容錯移轉叢集，不管是何平台，皆要注意以下幾點：
(1) 各項硬體之韌體及驅動程式建置前需更新
由於建置叢集後，要做這件事會變得很麻煩，所以要趁建置前檢查一下，可以的話盡量更新最新的穩定版驅動程式或韌體。
(2) 網路架構要注意分流及HA
以虛擬機器移轉來說，要耗用大量的網路流量，單條1Gb線路可能不夠，這時建議要用兩條線路進行Teaming，互為備援並增加流量；另外備份的流量強烈建議要獨立開來，才可避免備份時的大量流量影響到虛擬機器。現在已經可以考慮採用10Gb線路，以應付日益俱增的備份需求，那如果貴單位的網路線路不夠多，卻想要使用容錯移轉叢集呢？也不是沒有辦法的，假使只有兩條1Gb的線路，也是可以做到HA的，就是用QoS方式來限制各種網路流量的上限[1]。如此叢集還是可以運作，只是網路高峰時速度稍微慢一點，並且此兩條線路也具備互相備援的功能。
(3) 連結Storage部份務必要設定MPIO
由於CPU及記憶體運作速度都很快，因此虛擬機器的效能大部分就決定在Storage。而叢集的命脈更是取決於共用磁碟區的健康，設定線路時請盡量以MPIO方式連接，並且要注意要各接在不同的Controller上。因為光纖線時間一久容易老化，您可不希望哪天只是因為線壞掉或更換線路，導致叢集上面的虛擬機器全部掛點吧!
(4) Hyper-V 容錯移轉叢集的AD要保持健康
建置Hyper-V 容錯移轉叢集一定要透過AD，在此架構下，所有實體機器間的互相溝通，還有與共用磁碟區間的連接，都仰賴AD，要是AD壞掉，您就會發現您的叢集也會廢掉一身武功，因此AD一定要兩台以上，以作為備援。如果您是因為要建新叢集所以要順便建新AD，也建議不要把AD的虛擬硬碟放在共用磁碟區上，最好放在實體主機的本機硬碟裡(所以AD虛擬機器不可以加入容錯移轉叢集的角色)，原因是如果有一天您無法連結到某一個共用磁碟區，剛好AD 的VM放在這個共用磁碟區裡，結果AD死掉，造成Cluster Crash，回復起來會很麻煩。
(5) VMWare的vCenter要考慮高可用性
vCenter是VMWare裡面最重要的角色之一，如果裝在實體機器上，萬一實體機器出現單點故障，就只能連進每一台ESXi Server進行管理，也無法作即時移轉(vMotion)，因此建議把vCenter裝在虛擬機器上，這樣單台實體機器故障時，才可以在叢集裡移轉，確保服務正常。
結語以上為筆者這幾年的經驗累積，也許還有不足的地方，但是實務經驗上，若在建置的每個細節都考慮到高可用性，實際運作時系統就會更穩定，在找尋問題的時候也會更快速，願大家的系統都永遠健康！
