Data platform & Analytics

而且還可以使用SQL Agent Service、SQL Mail、CLR…在雲端上；至於資料抄寫的Replication當然更厲害了，以前只能擔任訂閱者Subscription單向的抄寫資料，全新的服務已經可以做到雙向的資料抄寫，實現更複雜的商務邏輯…

隨著資訊技術的發展，資料庫的佈署以及應用，已經有許多的選擇。包含了實體機、傳統虛擬化/容器虛擬化、Iaas上雲、Paas上雲…等選項。也由於公有雲代管的優勢，愈來愈多企業前撲後繼大量地往雲端遷徙，尤其是人手不足、機房規模較小的中小企業。

以微軟的Azure來說，在Iaas level提供了市場主流(隨著時間舊版本會End Of Support) Windows/Linux/SQL Server...的版本。至於Paas level則提供了Single database、Elastic pool、Managed Instance三種產品服務。

我簡要幫大家整理一下這三個服務的比較：

1. Single database，適用於比較要的服務，需要單獨看管。經過Sizing之後開始使用，之後隨時可以依據淡旺季需求彈性地加大或縮減資源。
2. Elastic pool，適用於比較沒有那麼重要的服務，可以群體看管。你可以買下一包資源(例如500 DTU)並且設定上/下限，然後在pool群中的資料庫就能共享這一包資源。讓不常用的服務，平時會有基本運算力(下限)來撐起服務；遇到旺季或是不預期人潮擁入，也能有多餘的運算力(上限)來調度；更重要的是它夠經濟，能夠把錢花在刀口上。
3. Managed Instance，適用於非常重要的服務或是架構較複雜的服務，需要從較小的Database提升至較大的Instance level，例如ERP或是其他核心系統。Managed Instance會建置在高度安全的隔離VNet虛擬網路內，提供內建的Host service(高達99.99%SLA服務水準的微軟代管，不需自己上patch，隨時保持最新功能與漏洞修復)、HA、backup、Security、Auditing、Azure AD support…等功能

在前言中有提到，使用Paas SQLDB需要改寫程式，這邊跟大家說明一下需要改寫的範圍。由於Query雲/地的底層機制是一致的(可參考下圖)，但是 Paas的 SQLDB 為了讓客戶專注在資料庫的使用，同時也防止客戶不小心去改到伺服器層級的設定。在雲端是使用 3 parts(<database>.<schema>.<table>) query，地端則是使用4 parts(<server>.<database>.<schema>.<table>) query。至於細部的功能比較，可以參考官網的說明。

**若你有跨資料庫存取的需求，例如 CRM要Join HR 做跨伺服器的資料查詢，方案一，把另一個伺服器的資料匯入到同一個 Paas SQLDB；方案二，使用 Managed Instance

**另外，也常有客戶問我，地端的資料庫有防火牆，就算雲端資料庫有提供資安防護與入侵分析，但是怎麼存取雲端的資料庫才安全？這個就要應用到 TLS (傳輸層安全性)。除了在Azure NSG(雲端上類似防火牆的機制)設定能允許通訊協定與埠號，在程式連線字串應該將 Encrypt = on & TrustServerCertificate = off；並且在 Client把過時的舊版 TLS1.0與1.1關閉，尤其是 PCI-DSS 線上金流的應用，一定要強迫 Client採用 TLS 2.0以上的版本才夠安全

在開始介紹如何在Azure上面建立MI這個服務之前，必需要先了解其運作原理、週邊環境、限制條件…

1. 首先建立MI之後，你並不能直接存取它，就像以前Azure SQL Database建立之後，你只能用Azure Portal或是找一台電腦安裝SSMS連上它。你一定會很奇怪，讓MI跟Azure SQL Database在管理上有什麼不一樣？
2. 你可以基礎於上圖的SQL MI VNet你需要建立S2S(Site to Site) VPN才能存取它。我剛才有提到，基於安全性的考量，MI會存放於高度隔離的MI subnet虛擬網路內，所以在建立MI之後，你需要會建立一個subnet並套用至Azure上面的跳板機(VM)來存取它；同理應用程式也會需要建立相對應的subnet來存取它。
3. 在建立MI時有一般用途服務General Purpose與商務關鍵服務Mission Critical二種，前者是基礎於標準iops storage環境(iops上限為5000，若你需要更快速或更低延遲請選擇更進階的SKU)，你可以存取到2核心起跳的Primary Node(因為AlwaysOn的HA會由Primary/Passive node來組成)；後者是基於較高的iops storage環境，你可以存取到4核心起跳的Primary Node以及一個Read only的Passive Node
4. 以下是MI的建立步驟：

• How to create MI?
  
  以General Purpose的2核心為例來建立
  
  輸入帳號/密碼，跟Azure SQL Database的Local Server很類似，將來你建立的Database時並不會問你帳號密碼，因為它會繼承其父親
  預計會需要2~4小時的時間，依序會建立出 Route table、Virtual network、Virtual cluster、SQL managed instance
  看到綠勾勾表示建立成功
  
• How to create a jumpbox VM?
  
  以SQL 2017 on Windows Server 2016為例建立一個VM
  
  
  
  
  成功地建立了包含Vitual machine、Managed disk、Public ip address、Network security group、Network interface、Virtual network
  透過RDP登入新建好的VM，以Run as administrator的方式執行PowerShell
  安裝所需的三個模組
  在互動式視窗，選擇yes或是all讓它裝起來
  在Azure portal中找到MI quick start，把裡面的指令copy出來
  貼上並執行
  出現Azure的登入畫面，請輸入帳號/密碼
  開始佈署
  大約30分鐘以內可以完成佈署
  Jumpbox這個VM在執行Script之後，已經成功被加入指定的MI rouse group
  
• Connect to MI
  
  透過SSMS成功連上MI
  透過PowerShell建立Virtual network getway
  包含Virtual network getway所需的public ip address也都建立出來，這個ip很重要就是讓不同的Vnet能夠互相相認的關鍵
  切換至S2S config頁面，把憑證金鑰copy出來
  下載一個名叫VpnClientSetupAmd64.exe
  
  以Run as administrator去執行這個自解檔
  在網路設定中會多出一個新的項目
  按下連線
  
  
  Check網路組態，已經成功被設定了
  

接下來，下一篇我再來介紹雙向Replication，敬請期待
 

李秉錡 Christian Lee
Once worked at Microsoft Taiwan