通過Portworx在AWS上運行高可用SQL Server容器

通過Portworx云原生存儲，在Amazon EKS里運行高可用SQL Server容器

在本文我們將分析，如何使用Amazon Elastic Container Service for Kubernetes (Amazon EKS, https://amazonaws-china.com/eks/)，來在容器中部署Microsoft SQL Server。文中討論的方式和與原理，也適用于其他需要高可用和持久性、并符合可復用的DevOps方式的有狀態(tài)應用。例如運行MongoDB、Apache Cassandra、MySQL、或者大數據處理等。

首先能夠被支持在容器中運行的是SQL Server 2017版本。我們可以在Linux容器中，使用Kubernetes (https://amazonaws-china.com/kubernetes/)來運行SQL Server生產負載。

Microsoft SQL Server是被廣泛使用的數據庫。SQL Server提供一系列很不錯的功能，也有很不錯的開發(fā)者社區(qū)。但是它需要比較多的運維，也比開源的或者云端的數據庫成本要更高。很多為了降低成本的用戶會轉向開源方案來降低軟件授權的成本。另一些用戶會遷移工作負載到關系數據庫管理系統(tǒng)（RDBMS）服務里，比如Amazon RDS for Microsoft SQL Server或者Amazon Aurora。

但也有許多情況，用戶無法離開SQL Server。這有很多可能的原因，比如需要重新部署和開發(fā)的成本，以及需要配置具備相關技能的開發(fā)工程師和運維工程師資源的成本等。用戶可能無法使用云服務，可能是軟件授權和支持的問題，或者一些技術問題。

在這樣的情況下，可以通過把SQL Server數據庫部署到Amazon Elastic Compute Cloud (Amazon EC2, https://amazonaws-china.com/ec2/)實例上，來使用云服務。這種方式保持了需要滿足特定需要的靈活性，也提供了云的各種好處。這些好處包括對于物理硬件層的抽象，以及按需付費的模式，以及其他的云端服務能力。雖然這種方式比本地部署SQL Server要更有優(yōu)勢，但管理額外的數據庫實例的管理成本仍然有可提升的空間。

使用Kubernetes來運行SQL Server會有更多優(yōu)勢：

• 簡化：在容器中部署和運維SQL Server會很簡單和快捷，比起傳統(tǒng)的部署模式會大幅降低工作量。這是因為部署不需要安裝，而是通過上載新的鏡像來完成。容器提供了一個可以任何環(huán)境運行的抽象層。
• 更優(yōu)化的資源使用：容器化的SQL Server提供了高密度，允許內部負載共享一個通用的資源池（內存、CPU、存儲）。因此減少了閑置的資源，增加了基礎架構資源的利用率。
• 降低軟件授權的成本：在容器中運行SQL Server的一些場景，不論是高密度還是低密度，都會降低軟件授權的成本。我們會在本文后面詳細介紹軟件授權的成本。

容器服務

目前，AWS里有四種容器服務：

• Amazon      Elastic Container Service (Amazon ECS，https://amazonaws-china.com/ecs/)：一個高度可擴展的，高性能的調度服務，與AWS的多項服務原生集成。
• Amazon Elastic Container Service for Kubernetes (Amazon EKS)：一個AWS提供的管理服務，可以方便的使用Kubernetes部署、管理和擴展容器應用。
• AWS      Fargate (https://amazonaws-china.com/fargate/)：一個Amazon ECS的計算引擎，可以幫助用戶在不需要管理服務器/集群的情況下，來運行容器。
• Amazon Elastic Container Registry (Amazon ECR，https://amazonaws-china.com/ecr/)：一個完整的被管理的Docker容器注冊表，便于用戶來存儲、管理和部署Docker容器鏡像。

在AWS上作架構的一個重要原則是 Multi-AZ部署，來產生高可用的和高性能的負載。你可以直接使用Amazon Elastic Block Storage (Amazon EBS, https://amazonaws-china.com/ebs/) 卷作為SQL Server容器的存儲解決方案，但這會限制這些容器只能在單一的可用區(qū)域內。Portworx可以用來解決這個問題。

Portworx是AWS全球的合作伙伴，也是微軟的高可用和容災方案合作伙伴。Portworx使得SQL Server能夠以高可用的方式，跨多個AWS可用區(qū)域，作為EKS集群來運行。Portworx也可以配置成跨越AWS Auto Scaling Groups的高可用。當使用SQL Server實例的存儲層的時候，這些功能確保了存儲的可用性。存儲的可用性是保證容器化SQL Sever實例高可用性所必須的。

這篇文章介紹了，如何使用Amazon EKS和Portworx云原生存儲（基于Amazon EBS 卷）來在生產環(huán)境中運行SQL Server負載。我們也提供了一份樣例腳本( https://github.com/awslabs/aws-eks-portworx-sql)  ，來自動地在幾分鐘內完成SQL Server實例的部署過程。

在容器中運行SQL Server的好處

使用容器最大的好處是簡單和有效。不需要安裝SQL Server或者配置容錯集群。使用簡單的命令就可以部署SQL Server容器，然后Kubernetes會提供SQL Server部署的高可用。在一些情況下，Kubernetes中部署的SQL Server的容器實例，可用性甚至高于那些部署在容錯集群上的。后面“高可用性”部分我們會介紹更多細節(jié)。

在容器中運行SQL Server的主要好處來自于高密度部署和資源共享。容器和虛擬機（VMs）的根本性的不同是：在運行過程中，與虛擬機不同，容器并不是被限定到一系列固定的資源上的。一個共享的資源池經常被一組容器在同一個主機上共享來使用。這使得容器可以隨時調整使用更多或者更少的資源。只要資源的總消耗不高于總資源池的資源容量，所有的容器都能有足夠的資源來運行。

如圖中所示，一個按照自身配置滿負荷資源運行的VM，無法在使用主機上閑余的資源。在這個例子中，資源池有兩臺物理主機，包括8個CPU核。盡管有3個CPU核仍然閑余未被使用，VM4和VM7仍然在自身滿資源的狀態(tài)下運行，而無法擴展使用閑余的資源。

讓我們來看一下能夠更有效利用資源的另一種方式。假設存在一種情況，你不需要擔心物理主機資源的數量。你只需部署一個滿資源的VM來運行一組應用，比如一些SQL Server實例。假設你可以讓你的應用共享所有資源，并且確?；ハ嘀g沒有沖突。圖右側的部分就是這樣的解決方案：使用Amazon EC2實例上的容器服務。

使用這種解決方案。沒有容器存在資源限制，總體的CPU核資源從8個減少到了6個。對于內存資源來說也是一樣的。容器化，可以增加底層架構的使用效率和有效性。這對于運行SQL Server這樣的有峰值使用量的應用來說尤其合適。

另一個在容器中運行SQL Server的好處是可以減少軟件授權的成本。SQL Server是一個商業(yè)產品，使用授權的限制會影響我們從技術角度的決策，或者可能大幅推高我們的商業(yè)成本。微軟授權SQL Server在容器中使用的方式，會很大程度上緩解這些問題。在后續(xù)“SQL Server容器軟件授權”部分有更多的細節(jié)。

Amazon EKS架構上的SQL Server

Kubernetes是一個開源軟件，可以用來部署和管理可擴展的容器化應用。它是一個中心化管理的分布式系統(tǒng)，用來運行和調度容器。

當你手邊已經有一個Kubernetes集群，使用和部署應用還是比較直接的。但是部署和運維一個Kubernetes集群本身還是比較復雜的。

Amazon EKS把復雜的Kubernetes集群的進行抽象。它提供一個完整的受管理的Kubernetes，用戶可以調用AWS API進行部署和管理。作為響應，用戶會收到一個上游Kubernetes api-server端點，這個端點允許用戶連接到新的Kubernetes集群并使用。

SQL Server在每一個Pod (一組總是一起運行的容器)中，被部署為一個單獨的容器。多個SQL Server的實例可以被部署為多個Pods。Kubernetes調度這些位于集群的節(jié)點上的Pods，確保有足夠的資源來運行它們。

為了在Kubernetes上運行SQL Server，你需要創(chuàng)建一個Kubernetes部署。這個部署創(chuàng)建了一個屬于該部署且可以被管理的復制集（ReplicaSet）。這個ReplicaSet確保包含一個單獨SQL Server容器的一個單獨的Pod，可以在集群上運行。當然，你也可以在同一個集群上部署SQL Server的多個實例來達到高密度。

存儲的使用也進行了抽象化。對Kubernetes來說，持久卷（PV）是一個封裝了存儲解決方案實施細節(jié)的對象。這可能是Amazon EBS卷，一個網絡五年間系統(tǒng)（NFS）共享，或者其他解決方案。PV的生命周期跟使用它的Pod的生命周期互相獨立不相干。

要使用PV，另一個對象 – 持久卷聲明（PVC, Persistent Volume Claim）需要被創(chuàng)建。PVC是一個使用請求，用來請求使用定義了大小和訪問模式（讀/寫）的存儲。一個PVC也可以定義存儲類（Storage Class）的值。存儲類是另一類抽象，允許用戶定義存儲解決方案的一些參數，比如延遲（latency）和IOPS。

管理員需要定義一個存儲類，例如AWS標準目的GP2 EBS卷，或者Portworx高(中) I/O卷。管理員然后可以基于這個存儲類來創(chuàng)建PV，或者允許用戶基于PVCs來動態(tài)的創(chuàng)建PV。而后應用可以Include一個PVC，把PV分配給某個特定的pod。為了讓這個過程更加簡單，你可以定義一個默認的存儲類。例如，假設一個Amazon EBS標準目的SSD （gp2）卷，被定義成Kubernetes集群上的默認存儲類，即使一個PVC沒有Include某一個特定的存儲類注解，Kubernetes將會自動注解它到AWS GP2 EBS存儲類上。

存儲的選擇

存儲是SQL Server部署中的一個關鍵部分。在AWS上部署SQL Server最常用的存儲方式是使用EBS卷。在Kubernetes集群中有兩種存儲類可以直接用來使用EBS卷。

• Aws-gp2 (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) 提供了一個平衡成本和性能的解決方案。
• Aws-io1 (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)，適用于需要穩(wěn)定的IOPS和通道速度的生產環(huán)境負載。

你可以直接在EBS卷上存儲SQL Server文件。然而，在許多情況下，一個單獨的EBS卷并不能滿足要求。例如，你也許需要在Multi – AZ架構下的高可用性，需要超出單獨EBS卷限制的存儲容量，或者需要單獨卷無法達到的IOPS和通道速度。你可以嘗試使用SQL Server Always On可用性組來解決高可用性問題，但是它無法解決存儲容量、IOPS、和通道速度問題。同時針對SQL Server容器的Always On可用性組功能，目前也僅在SQL Server 2019是Preview發(fā)布。

你可以滿足所有這些要求，包括高可用性、IOPS和通道速度，通過把幾個EBS卷合并成存儲池，在每一個EC2實例里Striping卷，并且把存儲池延展到不同可用性區(qū)域的多個實例里。你可以部署一個獨立的存儲集群，并且通過NFS存儲類在Kubernetes集群中使用該存儲集群。但這些操作會增加一些管理復雜度。

Portworx云原生存儲

Portworx是一個存儲集群解決方案，可以在Kubernetes集群中服務應用和部署。Portworx是部署在Kubernetes之上的。Portworx使用Kubernetes來抽象化所有復雜的管理存儲集群的操作。Portworx提供一個簡單的存儲類，可以被Kubernetes集群里的所有的有狀態(tài)應用來使用。

在AWS里，Portworx通過對附加在Kubernetes集群（EC2實例）上的Worker Node上的EBS卷進行聲明，來提供存儲類。Portworx會把所有卷放進一個抽象的存儲池里，然后從存儲池里創(chuàng)建邏輯卷。當SQL Server的應用創(chuàng)建一個包括Portworx存儲類的PVC，并且限定卷大小，一個包括具體大小的Portworx PV就被分配給了應用。

Portworx可以創(chuàng)建快照，稱為3DSnaps。通過這個功能，你可以在SQL Server不停機的情況下，或者把SQL Server調成 read-only模式的情況下，來創(chuàng)建SQL Server卷的連續(xù)快照。Portworx的另一個功能是可以導入已有的EBS卷到Portworx邏輯集群卷里。這使得負載的遷移變得很容易。通過Portworx，集群可以變得密度很高，意味著你可以在一個主機上運行更多的容器。針對Kubernetes的一般性建議是每個VM/100個Pods。Portworx有一些客戶甚至可以在每個主機上運行200~300個Pod (https://portworx.com/architects-corner-aurea-beyond-limits-amazon-ebs-run-200-kubernetes-stateful-pods-per-host/)。

Portworx在EBS卷之上，使用自己最佳顆粒度的快照層。

Portworx快照的創(chuàng)建和存儲都是實時的。這是因為Portworx的快照是re-direct-on-write快照，實際上，Portworx可以通過書簽方式（bookmark）即時地創(chuàng)建一個卷的實時快照。因為實際上的存儲塊并沒有被copy，不論作多少次快照，都沒有由于寫入帶來的資源使用。你可以創(chuàng)建一個每15分鐘一次的快照組，而不影響到任何使用性能。快照可以跨多個EBS卷，集群，并且以應用一致持續(xù)的狀態(tài)。

Portworx也支持重新定義虛擬卷的尺寸。你可以使用這個功能，結合EBS彈性卷，動態(tài)的來擴大或者縮小存儲，來避免由于過度部署帶來的額外成本損失。Portworx快照并不消耗額外的空間，這是因為存儲方式是redirect-on-write，包括一個B-tree–based的文件系統(tǒng)，這樣Portworx可以保持追蹤同一個塊的不同版本的數據。因此，這些快照非常節(jié)省空間。

你可以使用Portworx云快照策略來自動上載所有的快照到Amazon Simple Storage Service (S3, https://amazonaws-china.com/s3/)，并且刪除本地的快照。這個功能幫助防止本地不斷增加的快照來消耗EBS卷空間。Portworx也有一個本地快照保留策略，來幫助在本地保存一些特定的快照。這個策略可以基于每個卷，也可以在卷被創(chuàng)建或者卷被更新的時候動態(tài)的來配置。Amazon S3是一個對象存儲服務，提供99.999999999百分比的可用性。被上載到S3的Portworx快照，包括實際的存儲塊，而不僅僅是書簽。因此它提供了預防數據丟失的另一個保護層。

對本地的快照來說，恢復操作也是即時的，對于cloudsnaps (https://docs.portworx.com/cloud/backups.html) 來說，恢復操作也幾乎是即時的，因為Portworx僅僅在Amazon S3中存儲快照的不同部分。

關于性能和延遲，Portworx邏輯卷被每個Pod在本地訪問。在后臺，Portworx把block復制到其他可用性區(qū)域的其他worker node上。這樣，當pod意外恢復到其他可用性區(qū)域后，可以快速的重新訪問本地數據，繼續(xù)運行。

Portworx有客戶運行大規(guī)模數據庫比如Cassandra和Elasticsearch (https://portworx.com/ge-mesosphere-dcos-portworx/)，在AWS上成功運行上百T的數據。這些客戶認可在EBS上運行Portworx帶來的成本節(jié)省收益。需要了解更多Portworx的功能，可以訪問Portworx的網站 (https://portworx.com/products/features/)。

以上我們解釋了，你可以結合使用Amazon EKS和Portworx存儲，作為一個運行SQL Server的可靠的并且靈活的解決方案。接下來，我們將描述把SQL Server部署到Amazon EKS上的具體步驟。你可以按照下面的說明，在自己的環(huán)境里快速部署并驗證解決方案。

一些前置條件

本文描述的解決方案基于PowerShell腳本?？梢允荳indows PowerShell或者PowerShell Core。如果你希望在Windows 10或者Windows Server 2016來運行腳本，你可以使用自帶的Windows PowerShell。你也可以在MacBook或者Linux機器上來運行這些腳本。首先你需要在你的目標設備上安裝PowerShell Core (https://docs.microsoft.com/en-us/powershell/scripting/setup/installing-powershell?view=powershell-6)。另一種選擇，Mac的用戶可以使用ReadMe文件里的說明來部署一個本地的Docker容器，來包括所有這些前置條件。

這個腳本會調用在AWS Tools for PowerShell ( https://amazonaws-china.com/powershell/) 里的PowerShell cmdlets 。確保你的機器上安裝了最新版本的 AWS Tools for Windows PowerShell (https://www.powershellgallery.com/packages/AWSPowerShell/3.3.343.0)，或者AWS Tools for PowerShell Core （https://www.powershellgallery.com/packages/AWSPowerShell.NetCore/3.3.343.0）

這些腳本有時候需要AWS 命令行界面（AWS CLI）工具來調用Amazon EKS APIs。確保你安裝了最新版本的AWS CLI (https://docs.aws.amazon.com/cli/latest/userguide/installing.html)。

最后，你需要必須的AWS賬戶的權限來運行腳本。這包括運行AWS CloudFormation模板、創(chuàng)建虛擬私有云（VPCs）、子網、安全組、以及EC2實例，并且部署和訪問EKS集群。你可以使用一個IAM用戶（在你的計算機上保存一對可長期使用的Keys）。這種情況下，你需要允許AWS在PowerShell 和 AWS CLI上使用這些Keys。

另一種方式，你可以使用IAM角色，它具有被分配給EC2實例的所有必須的權限，可以用來運行腳本。這個方式，不需要額外的配置，AWS PowerSheel Tool和AWS CLI會從EC2實例的元數據那里自動獲得臨時的身份信息。

作為可選，這個包里面包括一個Docker文件，它會直接創(chuàng)建腳本，以及直接創(chuàng)建以上所有的必須的部分（AWS CLI、AWS cmdlets這些）到microsoft/powershell Docker鏡像里。這樣你就可以直接使用docker run來setup環(huán)境，不論是在MacOS、Linux或者Windows上，只要你安裝了Docker。

在Amazon EKS上部署SQL Server

你可以通過運行被include的腳本，傳遞必須的參數，來部署SQL Server。腳本包括許多參數，最重要的一些參數已經有默認的值，來幫助不熟悉的用戶。反復運行同樣參數的腳本也是安全的，它會檢查底層的資源是不是已經存在，如果已經存在，會復用它們。

以下是腳本運行的所有步驟：

1.   首先，它為Amazon EKS創(chuàng)建一個IAM服務角色。這個角色會允許AWS來創(chuàng)建必要的資源。

2.   你需要一個VPC來運行你的集群。腳本會接收一個AWS CloudFormation VPC Stack的名稱作為一個參數。如果Stack已經存在，它就會復用這個Stack，否則，它就通過AWS提供的模板創(chuàng)建一個新的Stack。Stack包括VPC、子網和安全組，這些必須的內容來運行集群。

3.   你使用一個客戶端工具kubectl來配置和與Kubernetes交互。腳本會下載AWS版本的Kubectl，并且安裝到你的本地計算機。

4.   當你使用Kubectl來查詢Amazon EKS，你正在使用的AWS PowerShell工具的身份信息也會被傳遞給Amazon EKS。這個任務是被另一個工具aws-iam-authenticator來完成的，這個工具也會被腳本下載并安裝。

5.   它創(chuàng)建了一個新的EKS集群。這個EKS集群包括被管理的一組3個 Master節(jié)點，分布在3個AWS可用區(qū)域上。

6.   它配置Kubectl來連接到上面步驟創(chuàng)建的EKS集群上。

7.   它創(chuàng)建了新的EC2實例，并且配置它們加入到EKS集群和Worker nodes上。

8.   它創(chuàng)建了一個Etcd集群，讓Portworx與之通信。

9.   它然后下載一個DaemonSet規(guī)格參數，并且應用到EKS集群上。這就自動安裝了Portworx云原生存儲 – 含有GP2和IO1 EBS卷，供用戶選擇其中一種或者全部。

10.  它為Portworx卷創(chuàng)建了一個存儲類，其中EKS集群內的復制因子數值為3。這樣你就可以在主機發(fā)生錯誤的時候，維持SQL Server集群的高可用。甚至Kubernetes可以把你的SQL Server Pod調度到另一個可用性區(qū)域。

11.  它在EKS集群內，為gp2 EBS卷創(chuàng)建了一個存儲類。

12.  它在EKS集群內創(chuàng)建了一個新的Persistent Volume聲明（PVC）。PVC允許Portworx來部署由Amazon EBS卷支持的持久卷（PV）。

13.  它提示你輸入SQL Server SA用戶的密碼。輸入符合SQL Server密碼要求的強度較高的密碼。腳本會把密碼作為Secret保存到EKS集群里。

14.  然后它會創(chuàng)建SQL Server的部署。部署包括一個復制集，它會按順序創(chuàng)建Kubernetes的Pods。Pod是由一個運行SQL Server的單獨容器組成。PVC卷被Mount到了這個容器里。SA的密碼也被使用。

15.  最后，它輸出端點的名稱，在連接字符串里使用來連接到SQL Server實例里。

運行腳本會部署EKS集群，以及一個單獨的SQL Server實例。你也可以在同一個EKS集群上部署另一個SQL Server實例，只需要再次運行同一個腳本即可。然后為appName參數傳遞一個不同的名稱。

高可用性

腳本部署SQL Server使用Multi-AZ Kubernetes集群，和一個有Portworx卷支持的存儲類（Storage Class）。由于Portworx在SQL Server容器里保護和復制數據，部署針對下列情況具備高可用：

• 容器錯誤
• Pod錯誤
• EC2實例錯誤
• EC2主機錯誤
• EBS磁盤錯誤
• EC2網絡分區(qū)
• AWS有效性區(qū)域錯誤

如果一個容器或者Pod錯誤，Kubernetes會立即調度另一個容器或者Pod。甚至Kubernetes把Pod調度到了另一個可用性區(qū)域。你也不會有數據損失，因為Portworx自動的在可用性區(qū)域之間復制數據。

在前面的部分，我們注意到Portworx復制因子的數值被設定成了3。這意味著除了我們的主PV之外，Portworx會在集群上的其他地方一直保持兩個額外的PV副本。因為Amazon EBS卷只在一個單獨的可用性區(qū)域保持高可用性，默認情況下，Portworx把這些復制擴展到多個可用性區(qū)域里。相對于本地部署時：通常一個SQL Server錯誤恢復集群實例（FCI）是部署在同一個數據中心里的，很大的進步就是Kubernetes和Portworx集群是分布在多個可用性區(qū)域里的。因此，可用性更高。

在Portworx存儲集群上的Kubernetes里運行SQL Server容器，類似在跨多個可用性區(qū)域的Storage Spaces Direct 集群（https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-overview）上運行SQL Server Always On FCI。這樣Recovery Point Objective (RPO)是零，而且Recovery Time Objective (RTO，https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-container-ha-overview?view=sqlallproducts-allversions) 小于10分鐘，這樣可以應對可能出現的可用性區(qū)域的錯誤，達到極高的可用性。區(qū)別是在EKS里運行容器，比起在Windows Server容錯恢復集群上配置和維護SQL Server要更加容易。

如果你運行SQL Server標準版，你也可以通過使用容器和Amazon EKS獲得相比于傳統(tǒng)Windows部署的更高的可用性。這是因為SQL Server標準版FCI只能授權最多兩個節(jié)點的使用。（一個第二節(jié)點）。然而，容器可以被部署到含有任何數量節(jié)點的集群上。SQL Server Always On FCI的企業(yè)版可以超過兩個節(jié)點。取決于你的軟件授權協議，你可能要為每個額外的實例購買新的授權。這不是容器的使用方式。你可以只支付一個容器的費用，不論你在集群上有多少standby的實例。

也可以把SQL Server容器和Always On可用性組（SQL Server 2019 preview版本）一起部署。這樣的配置類似部署Always On可用性組（每個節(jié)點自己就是一個Always On FCI集群）。這樣，容器就會擺脫一些Always On可用性組和FCI的限制。例如，這些限制包括從一個可用性組的節(jié)點自動容錯恢復到另一個節(jié)點，和為每一個節(jié)點設置FCI的復雜操作。

SQL Server容器軟件授權

基于SQL Server 2017軟件授權說明：“SQL Server 2017使用授權給虛擬機和容器，為客戶的部署提供靈活性。有兩種可選的給虛擬機和容器的授權方式，為每個虛擬機和容器授權，以及為高度虛擬化或高密度容器環(huán)境的最大密度授權（每物理主機授權）”。

有機會通過把SQL Server負載容器化來降低軟件授權成本。你可以基于不同的實際場景，使用每容器授權的模式，或者使用每物理主機授權的模式（高密度），來降低軟件授權的數量。

如果你有一些應用在EC2實例上運行，并且希望在同一個主機上運行應用的同時，也運行SQL Server，你可以使用每容器授權的模式。如果沒有容器，是在虛擬機上直接運行SQL Server，包括EC2實例，你就需要為VM包括的所有vCPU購買授權，不論SQL Server到底使用了多少vCPU資源。然而，如果你是在VM之上的容器里運行SQL Server，你只需要為容器訪問到的vCPU數量購買授權。你可以僅僅為能訪問到的核數量購買授權，這樣你最小的情況可以只夠買4核的授權，或者6核，8核這樣，視情況而定。

如果你的SQL Server實例存在突發(fā)峰值的使用情況，你可以在高密度環(huán)境的容器內運行它們。這種情況下，你可以選擇每物理機授權的模式。只要所有的物理核資源得到了正確的授權，就會允許你運行物理核資源之上的不限數量的容器，以及不限數量的vCPU。

在上面的圖里，有12個vCPU核和20個容器。但因為這些容器都運行在一個6核的物理機器上，只需要為這6個物理機的核授權。這對那些已經在本地物理環(huán)境里過度部署了SQL Server虛擬機的情況非常有用。EC2實例有一個固定的hyperthreading比例：2vCPU對應一個物理主機核。這樣遷移過度部署的負載（3:1，4:1，5:1或者更高）到EC2實例里會帶來更高的成本問題。容器化解決成本問題，相應也會帶來更好的收益。

Portworx授權

Portworx支持高密度容器環(huán)境的授權模式。Kubernetes本身推薦一個節(jié)點最多不要超過100個pod（https://kubernetes.io/docs/setup/cluster-large/）。這樣理論上，你可以在每個EC2實例里運行不超過100個SQL Server Pods，這樣可以大量節(jié)省SQL Server授權。Portworx針對每個EC2實例只需要一個授權，不論運行多少容器，或者消耗多少存儲。這樣對于集群，你并不是簡單的用一個授權來換另外一個，實際上，每個主機運行的SQL Server數量越多，你的平均授權成本越低。Portworx支持每個集群數千節(jié)點，以及支持每個節(jié)點數百個有狀態(tài)容器（https://portworx.com/architects-corner-aurea-beyond-limits-amazon-ebs-run-200-kubernetes-stateful-pods-per-host/）。

什么情況下不適合使用SQL Server容器

在現有版本的功能上，并不是所有的SQL Server都能夠被容器化。目前僅僅只有SQL Server2017支持容器。2017之前的版本都不能支持容器。但SQL Server本身是兼容SQL Server 2008之后的版本的，這意味著你可以導入從SQL Server 2008（或之后版本）中創(chuàng)建的數據庫到SQL Server2017實例里（包括在容器里運行的SQL Server 2017里），用兼容模式來運行即可。

雖然SQL Server on Linux支持與Microsoft Active Directory的集成，SQL Server容器目前不支持Active Directory集成。

SQL Server一個經常使用的功能是horizontal read-scaling，它在Always on可用性組里。這個功能對容器目前只是Preview版本，不能用在生產環(huán)境。

另一個云帶來的可能的好處是License Included services模式。對于許多商業(yè)來說，管理已購買的授權和實際軟件授權使用是非常復雜的工作。經常會不一致，導致客戶要么為未使用的軟件授權多花錢，要么合規(guī)地軟件授權不足。SQL Server容器支持Bring Your Own License (BYOL)模式，因此在決策前好好考慮下授權的問題。

也有其他一些功能目前還不能使用，比如Distributed Transaction Coordinator (DTC)和custom CLR user types。如果你的SQL Server負載是一個比較靜態(tài)平穩(wěn)的資源消耗模式，也許傳統(tǒng)的部署模式更加適用。

結論

在本篇文章中，我們討論了為什么要考慮在容器中使用SQL Server和Portworx，并且討論了需要考慮的各個方面。

這樣的方式有下面的好處：

• 簡單，而且會幫助你降低一些管理的復雜度。
• 可以通過釋放閑置的資源給需要的負載，來增加應用的性能。
• 可以增加數據保護，以及部署的容災恢復。
• 可以減少基礎架構的成本。
• 可以減少SQL Server軟件授權的成本。

這篇文章演示了在Amazon EKS上與Portworx一起部署SQL Server是比較簡單的。你可以部署基礎架構和EKS集群，并且通過使用一個簡單的腳本來調用AWS API，從而來運行SQL Server容器?；谀愕那闆r，你可以使用兩種存儲方案：

• 使用單獨的EBS卷作為一個PVC，在一個單一的高可用區(qū)域里提供高可用性，最少的存儲成本。
• 使用一個集群化的存儲解決方案Portworx來跨多個可用性區(qū)域，提供支持可用性區(qū)域錯誤恢復級別的高可用。