Data platform & Analytics

**話說在前頭，由於本篇將不會 step by step 的介紹 AlwaysOn 安裝，若有需要請自行參考官網說明或是在網路上爬文(資料應該很多)。

從上圖(細節可以參考微軟Blog的說明)來看，想要實作一組AlwaysOn至少會需要5台VM，裡面包含了2台互為備援的AD + 2個SQL Server 節點 + 仲裁磁碟，再加上雲端特有的物件，總共會有22個。
至於為什麼要在雲端建 HADR？主要是為了爭取時效性與降低管理的複雜性。

1. 處在分秒必爭與國際競爭的當前，當企業有時想做可行性分析，有時想做研發測試，有時想做Production…光是預算編列、等伺服器入港到貨、處理硬碟故障與替換、AD目錄服務的建置與處理新伺服器的加入/退出網域、作業系統安裝、SQL Server的安裝與設定、AlwaysOn的相關設定…都可能會花個十天半個月。現在有了雲端，彈指之間大約等待30分鐘的時間 5台VM即可開箱即用。
2. 我們用 SLA的角度來看，從99%以下的小數點，每增加一個位數，其人事與設備的投資，都是數倍的成長，若是任務不夠 mission critical一般的企業是不願意投資的，其次是枯燥的營運所衍生的工作人員流動與留任也是一項令人頭痛的議題，再加上7*24的排班以及硬體料件的準備還有故障處理的SOP，都是企業所要承擔的。若是企業還有雄心壯志，希望通過ISO國際認證或是導入ITIL期望做到高度的營運管理，以利爭取更高毛利的生意訂單，真的是一個業界標竿的大挑戰。

所幸，以上的問題，在雲端的世界，都能輕鬆的搞定。
如果你是年輕的公司，機會之神就站在你身後，可以放手一博，挑戰商務上的高成長；如果你是資深年長的公司，幸運之神其實也是眷顧你的，讓你可以擺脫在彈性不足龐大組織的歷史羈絆，應用科技來同時實現客戶需求的滿足與數位轉型的啟動。

以下我將針對 AlwaysOn 如何在 Azure Portal 的設定進行介紹

A、AlwaysOn 建置(下圖是AlwaysOn的企業情境示意圖，當我們透過Azure中的template建立時，只會建立2個 SQL的節點，但為了開箱即用以及符合雲端上高可用度的目標，並且能應付最低的企業等級 Production挑戰，所以會完整地建立 22個雲端的物件。另外 Azure template本身就是 script的範本，就是提供給客戶做二次修改的，不然當你一次要建5個節點時，難道要點 2.5次嗎？找時間再來寫怎麼改寫 template…)

1、直接登入Azure Portal並且在搜尋列鍵入AlwaysOn，在 Market place區塊可以找到一個名為SQL Server AlwaysOn Cluster的項目，然後點擊它…
2、在第一個設定頁面Basics上，給予admin的帳號/密碼、訂閱帳號、Resource Group(虛擬容器)、欲建立的Region位置，按下ok進入下一頁
3、接著在網域與網路設定中，給定相關的環境數值，按下ok進入下一頁
4、接著在AG設定中，給定AG群組的名稱、AG Listener的名稱與埠號，，按下ok進入下一頁
5、接著在VM設定中，給定VM與 Storage的型號與容量配置，按下ok進入下一頁
6、接著在SQL設定中，給定SQL版本與SQL服務帳號/密碼，按下ok進入下一頁
7、看一下 Summary頁面的資訊，按下ok進入下一頁，就會出現最後一個 Create按鈕，按下後就能開始建立
8、由於不同的 Region 資源條件不同，建置的時間會不一樣。以我的經驗，在東亞或是東南亞建立大約是 60分鐘。
再次重申，由於不同的資料中心在價格、資源上有所不同，所以建立的時間會不一樣。
此次的雲端建置，開會前我按下Create，一小時後回來後，22個雲端 Componpent 已經 Ready to use了，剩下來就可以把企業的資料倒進去，然後把網站或是其他應用程式伺服器也在雲端建置起來，就能開始服務外部或是內部的客戶了。

B、AlwaysOn Demo

在開始之後，要跟大家介紹一下AlwaysOn的觀念，它有一個OS(Cluster management)的爸爸，會給它一個Virtual IP，以利我們的應用程式可以指向一個隨時都能提供服務的資料庫服務；它有一個SQL AG(Availablity Group)的媽媽，提供了 Database level 的精準 HA控管，當異常發生時，就會切到另一個節點。DR晚點再說...

接下來，讓我們來做個比較，下圖是在SQL 2012以前舊版本所採用的 Failover Cluster Instance(FCI) 一種純粹倚靠作業系統的 HA技術，當時存在著網路共享儲存裝置失效的風險，以及Windows Server UI已經沒有回應，Web Server正常，但SQL Server也沒有回應，導致有時會切換，有時又不切換的不確定性…在SQL 2016時，又支援 Combine這二種的更高保險的方案，但相對而言成本也更高。目前台灣有金融業就有幾家是採用這個高貴的方案(應該要幫金融業拍拍手)


1、首先我們要登入2台中的任1台SQL 2017，以sqlserver-0為例，從遠端桌面進入後，接著開啟SSMS。你可以發現裡面的 AlwaysOn包含AG(光是設定就需要30分鐘)都已經設定完成，可以直接開始 Demo(或是測試…等其他用途)
2、盤點一下目前的狀況：
2台 SQL2017 EE，都已經加入 contoso.com的網域，然後有一個 1TB 的Share folder(叢集見證的檔案共用)。
除了AlwaysOn服務已經常駐在作業系統上，而且防火牆的port也已經開好，讓DB間以及與應用程式可以正常的溝通
3、檢視 Failover Cluster Manager，開啟管理介面後，在右邊Action區域找到 Connect to Cluster
直接連上本機的叢集
就會看到 aodns-fc.contoso.com
它的 Roles/Nodes/Networks 都已經設定完成，而且已經在運行了
千萬不要從這邊來做 Failover的切換喔！這裡是 OS level不是 DB lever，我就曾經去客戶端救過因為不熟這個機制，然後剛好硬碟故障出現分頁損毀，導致DB 起不來的狀況
檢視一下接聽程式Listner的設定
確認將來的應用程式或端點是可以連上AG
4、另外在雲端還有像是 Load Balancer的物件，可以兼具保護 VM 存取與分流的用途。有機會再介紹
或是為了延展性，隨著上線人數增加，需要彈性擴充後端資源的 Availability set ，也是將來可以介紹的
5、接下來，讓我們來檢視一下叢集的仲裁檔案共用
設定的細節就不談了，總之AG的資料是放在本機中，而這個Share folder的存在是讓每個節點去Ping它，確認節點在 OS level上是正常的，不是給你放資料的喔！
6、剛才有說會介紹 DR，所以我們來談一下AlwaysOn的設定介面。首先 Primary的唯一可寫入的節點，會與其他 Secondary 節點存在著 1:N 的關係，在畫面中有 Automatic Failover、Synchronous Commit、Readalbe Secondary三個項目，就是讓我們實現 HADR各種情況的地方。

我們依序來說明：

• 第一個參數 Automatic Failover，決定哪個節點要成為HA 情境中會被自動切換的角色？(Failover有三種方式，分別為自動、手動和強制) 必要條件至少包含：SQL的版本是否一致？硬體規格是否差異太大？地理距離是否合理？(萬一是台北/高雄，切換時將會是場大災難)… 其他細節可以參考官網
• 第二個參數 Synchronous Commit，決定是否要用交易延遲換取正確性？Synchronous-commit會多花一點時間，但能確認不會掉資料，反之亦然。
• 第三個參數 Readable secondarie，決定是否要成為應用程式的數據資料源(例如報表的用途)

7、容錯移轉設定，下圖是Failover的三種類型，當企業想要做到倆倆互相備援的Active-Active時，就需要考量較複雜的排列組合

8、上述提到了，節點是可以擔任應用程式所需的資料來源角色，但是當前端的請求端數量很多時，又是另一個挑戰。所以SQL Server提供了分流的功能，細節可以參考官網介紹 READ_WRITE_ROUTING_URL 的篇幅

 

李秉錡 Christian Lee
Once worked at Microsoft Taiwan