亚马逊AWS官方博客
在 Amazon EKS 中搭配使用 Portworx 云原生存储运行高可用微软 SQL Server 容器
在本文中，我们将共同了解如何使用Amazon Elastic Container Service for Kubernetes (Amazon EKS)在容器上部署微软SQL Server。本文中提及的方法与原理，也同样适用于需要保证高可用性（HA）与持久性、且配合可复用 DevOps 操作实践的各类有状态应用程序。相关用例包括 MongoDB、Apache Cassandra、MySQL 以及大数据处理等等。
SQL Server 2017 版本首次提供在容器中运行 SQL Server 的支持选项。现在，您可以使用 Kubernetes（简称K8s）在Linux容器中运行生产级 SQL Server 工作负载。
微软 SQL Server 是目前应用范围最广的数据库引擎之一。尽管 SQL Server 拥有一系列吸引的功能并且提供活跃且强大的技术社区，但与基于云端的数据库或开源数据库解决方案相比，其维护与运营成本仍然相对较高。部分组织希望从SQL Server迁移至其他开源解决方案，借此降低许可成本并达成类似的运营效果。也有部分用户选择将工作负载迁移至托管关系数据库管理系统（RDBMS）服务，例如采用微软 SQL Server 或 Amazon Aurora 的 Amazon RDS。
然而，根据实际情况的制约，相当一部分组织无法（或者不希望）彻底放弃 SQL Server 引擎。具体原因多种多样，例如极高的重构成本、沉重的人员再培训压力、内部IT管理员及工程师团队缺乏对新数据库引擎的了解等等。同样的，出于种种原因（例如许可及支持协议，或者其它特殊技术要求），部分企业同样无法从容选择托管云服务类解决方案。
在这类情况下，大家可以通过在Amazon Elastic Compute Cloud (Amazon EC2) 实例上部署 SQL Server 数据库，充分发挥云服务带来的诸多助益。这种方法既满足了特殊业务场景提出的灵活性需求，同时也让云计算的规模化优势得到充分体现。具体来看，大家可以对硬件及基础设施进行全面抽象、按实际资源使用量付费、无需任何前期承诺，同时顺畅与其他服务进行集成。当然，虽然在诸多方面已经超越本地SQL Server，但这种方式仍会带来额外的数据库实例运营开销，因此在成本方面仍无法与全托管服务相媲美。
使用 Kubernetes 运行 SQL Server，能够实现以下几项助益：
- 简单性：与传统部署模式相比，在容器中部署及维护 SQL Server 工作负载更为轻松便捷，相关工作量也更低。部署速度更快、无需安装，上传新镜像即可轻松完成升级，各容器成为了能支持任意运行环境的一套抽象层。
- 优化资源使用方式：容器化 SQL Server 工作负载可提升资源使用密度，允许多种内部工作负载共享同一套公共资源池（内存、CPU与存储）。这将显著降低闲置资源量，同时提高基础设施的使用效率。
- 低许可成本：在某些场景，在容器中以较高或较低密度运行 SQL Server ，有助于降低总体许可成本。我们将在后文中的“许可”部分具体介绍这部分内容。
可用容器服务
目前，AWS主要提供四种容器服务选项：
- Amazon Elastic Container Service (Amazon ECS): 一项高可扩展性、高性能编排服务，能够以原生方式同多种其他AWS服务相集成。
- Amazon Elastic Container Service for Kubernetes (Amazon EKS): AWS 提供的一项托管服务，可帮助用户使用Kubernetes轻松实现容器化应用程序的部署、管理与扩展。
- AWS Fargate: 一套面向 Amazon ECS 的计算引擎，可帮助用户在无需管理服务器或集群的前提下轻松运行容器。
- Amazon Elastic Container Registry (Amazon ECR): 一款全托管 Docker 容器注册表，可帮助您轻松存储、管理及部署Docker容器镜像。
AWS架构的一大设计核心，在于实现工作负载的多可用区部署、高弹性与高性能目标。您可以将Amazon Elastic Block Storage (Amazon EBS) 卷直接作为SQL Server容器的存储解决方案，但这将导致容器只能运行在单一可用区内。在本文中，我们将共同了解如何在Portworx的协助下解决这一难题。
Portworx为AWS合作伙伴，兼微软高可用性与灾难恢复解决方案合作伙伴。作为EKS集群的一部分，Portworx能够支持SQL Server在多个AWS可用区内以高可用模式运行。Portworx还支持在 AWS Auto Scaling 组内以高可用性配置运行。在作为SQL Server实例的存储层时，该功能将确保存储资源可用性，并借此为容器化SQL Server实例的高可用性奠定坚实基础。
本文将向大家展示如何使用Amazon EKS与Amazon EBS卷支持的Portworx云原生存储方案，在生产环境中稳定运行SQL Server工作负载。我们将提供一套示例脚本，它支持自动化执行部署流程，帮助大家在几分钟之内顺畅部署SQL Server实例。
在容器中运行SQL Server的优势
使用容器的最根本助益，在于实现解决方案的简单性与优雅性。无需安装SQL Server或配置故障转移集群，大家只需要通过单一命令即可轻松部署SQL Server容器，并由Kubernetes稳定为SQL Server部署提供高可用性保障。在某些场景下，部署在Kubernetes上容器当中的SQL Server实例，甚至拥有高于故障转移集群环境中工作负载的可用性水平。关于更多详细信息，请参阅后文中的“高可用性”部分。
然而，在容器当中运行SQL Server主要的优势在于更高的部署密度以及资源共享优势。容器与虚拟机之间的根本区别在于，虚拟机在运行期间将受限于固定数量的资源，而容器则不存在这类约束。同一主机上并发运行的一组容器往往能够构成一套共享资源池，通过不同容器在不同时间点上资源需求的此消彼长而达成动态平衡与资源利用率优化。只要当前系统的总消耗量低于池中的总体可用资源量，则所有容器都将拥有必要的资源供应。
如上图所示，以100%资源利用率运行的虚拟机上将不再存在任何空闲资源。在示例中可以看到，本地部署有两台物理主机，其各拥有8个CPU核心。尽管仍有3个核心处于闲置，但VM 4与VM 7仍然处于资源受限状态。
现在，我们不妨考虑另一种可行的资源利用方式。大家可以设想这样一个世界，我们不需要再关注物理主机；相反，只需要为虚拟机提供运行一组应用程序（例如几个SQL Server实例）所必需的全部聚合资源即可。此外，假定您可以通过某种方式允许应用程序共享全体配置资源，且应用之间不存在资源争用。上图右侧即为这种运营模式，即运行在Amazon EC2实例之上的多个容器。
通过这套解决方案，容器资源将不再受限，计算核心总数从8个物理核心减少至6个。同样的设计原则也适用于可用内存。因此，容器化方案能够显著提升基础设施的效率与性能，且特别适合存在明确峰值利用率波动模式的SQL Server工作负载。
在容器环境中运行SQL Server工作负载还有着另一个常被忽略的优势，即降低许可成本。SQL Server是一款商业产品，许可条款对于使用方式的限制可能在技术层面阻碍您的决策，或者显著提升业务成本。在部分情况下，容器设计模式能够在微软许可条款下极大降低许可支出与约束性限制。关于更多详细信息，请参阅后文中的“SQL Server容器许可”部分。
Amazon EKS上运行SQL Server的架构
Kubernetes是一款开源软件，用于以规模化方式部署并管理容器化应用程序。它也是一套中央托管型分布式系统，能够高效运行并编排海量容器。
面对一套Kubernetes，很多朋友最先想到的当然是直接使用，将工作负载部署在其中。但Kubernetes本身的部署与维护工作有可能带来新的挑战。
Amazon EKS能够对众多复杂性因素加以抽象，让Kubernetes集群轻松运行在AWS当中。其提供一套全托管Kubernetes控制平面，您可以通过调用单一AWS API进行容器环境置备。上游Kubernetes api-server端点将对API调用做出响应，大家通过响应结果接入新的Kubernetes集群，而后即可直接使用。
SQL Server将在各Pod（即一组始终运行的容器）中以单一容器的形式部署完成。大家可以将多个SQL Server实例部署为多个一一对应的Pod。Kubernetes将在集群中各节点上调度这些Pod，保证其始终拥有运行所必需的系统资源。
要在Kubernetes上运行SQL Server，您还需要创建一套Kubernetes部署。此部署将创建一个由部署本身拥有并负责管理的ReplicaSet，后者负责保证由单一SQL Server容器组成的单一Pod始终运行于集群之上。当然，您也可以在同一集群之上部署多个SQL Server实例，借此提高资源使用密度。
存储资源消费机制也被从存储体系中抽象出来。Kubernetes会将持久存储卷（PV）作为打包存储解决方案各实现细节的单一对象。该存储卷可以由Amazon EBS卷、网络文件系统（NFS）或者其他解决方案充当。PV的生命周期独立于使用该PV的Pod生命周期之外。
要使用PV，我们还需要创建另一个名为持久卷声明（PVC）的对象。PVC代表着对于具有特定大小及访问模式（读取/写入）的存储资源的请求。PVC还可以指定“Storage Class”值。这里的Storage Class代表另一种抽象，您可以借此定义存储解决方案的其他属性，例如延迟与IOPS等。
管理员需要定义特定的Storage Class，例如AWS通用GP2 EBS卷，或者Portworx高或中I/O卷。操作程序随后会根据Storage Class创建一个PV，或者允许用户以动态方式根据PVC创建PV。接下来，应用程序将引入PVC，并由其将PV分配给特定Pod。为了简化整个流程，大家可以定义一个默认Storage Class。例如，假设我们在Kubernetes集群中将Amazon EBS General Purpose SSD（gp2）卷定义为默认Storage Class，那么即使PVC中不包含特定的Storage Class注释，Kubernetes也会自动使用AWS GP2 EBS Storage Class对其进行注释。
存储选项
对于任何SQL Server，存储都是其中不可或缺的重要组成部分。SQL Server在AWS上最常用的存储选项当数EBS卷。Kubernetes集群提供两种可以直接使用EBS卷的Storage Class：
您可以将SQL Server文件直接存储在EBS卷上。但在大多数情况下，单一EBS卷并不足以满足业务要求。例如，您可能需要保证多可用区架构下的高可用性、建立超越单一EBS卷上限的存储容量，或者使用必须由多个卷协同运作才能实现的超高吞吐量/IOPS。对于高可用性问题，大家可以选择SQL Server Always On可用性组作为解决方案；但其仍然无法解决容量、IOPS与吞吐量方面的挑战。另外需要注意的是，用于SQL Server容器的Always On可用性组目前在SQL Server 2019版本中仍属于预览版功能。
通过将多个EBS卷组合至同一存储池内，在各个EC2实例中进行卷拆分，并在各个可用区的多个实例之间扩展存储池，即可充分满足上述各项要求（高可用性、容量、IOPS与吞吐量）。大家可以借此建立起一套独立的存储集群，而后通过NFS Storage Class在Kubernetes集群中使用该集群。但这一切，都将带来额外的复杂性与运营成本。
Portworx云原生存储
Portworx是一套存储集群解决方案，旨在为Kubernetes集群中的应用程序及部署提供服务。此外，Portworx本身已经内置于Kubernetes当中。换句话说，Portworx使用Kubernetes功能以抽象方式管理存储集群带来的所有复杂性因素。Portworx提供一个简单的Storage Class，以供Kubernetes集群中的一切有状态应用程序共同使用。
在AWS中，Portworx需要向Kubernetes集群上各工作节点（EC2实例）的EBS卷附加声明，才能实现上述使用效果。以此为基础，所有卷都将被添加至统一的抽象存储池当中，而后以逻辑卷的形式进行池资源划分。当SQL Server这类应用程序使用Portworx Storage Class创建一个PVC并为其指定卷大小时，系统即向该应用程序分配一个具有对应大小的Portworx PV。
Portworx还能够创建实时快照（名为3DSnaps）。利用这项功能，大家可以为SQL Server卷创建一致快照，且不必停止SQL Server运行或者将其切换为只读模式。Portworx的另一项重要功能，在于将现有EBS卷导入Portworx逻辑集群卷，从而极大降低现有工作负载的迁移难度。使用Portworx，集群的资源密度可以提升至极高水平，意味着每台主机都能够运行大量容器。Kubernetes的建议是在每套虚拟机内运行不超过100个Pod；相比之下，已经有Portworx客户在每主机上运行200到300个Pod。
Portworx在EBS卷之下建立起自己的缇粒度快照层。
Portworx快照的创建与还原能够即时完成，这是因为其快照属于写时重新定向（re-direct-on-write）快照。在本质上，Portworx可以通过书签即时为存储卷构建时间点快照。由于不需要实际复制各存储数据块，因此无论保存多少份快照，都不会因写入操作而引发性能损失。换言之，即使每15分钟保存一次新快照，系统性能也不会有任何降低。更重要的是，快照保存能够跨多个EBS卷在整体集群层面进行，借此建立起应用级别的结果一致性。
Portworx还允许用户调整虚拟卷大小。您可以将此项功能与EBS弹性卷相结合，借此实现存储容量的动态规模伸缩，同时避免因资源过度配置引发的额外开支。在本质上，Portworx不会占用额外的空间，因为其底层存储方法使用基于B树的文件系统进行写时重新定向，这使得Portworx能够跟踪同一数据块的多个版本。因此，Portworx快照具有良好的空间节约效果。
您可以使用Portworx云快照策略，自动将所有快照上传至Amazon Simple Storage Service (S3)存储桶，而后清理本地快照。这项功能能够有效防止快照占用大量EBS卷存储空间。Portworx也提供本地快照保留策略，您可以根据需要随意指定需要保留的快照数量。该策略以卷为基本管理单位，可以在卷创建期间进行动态配置，也可以稍后加以更新。Amazon S3 作为对象存储服务，提供99.999999999%的持久性。上传至Amazon S3的Portworx快照将包含实际存储块——而不再仅仅作为书签形式——这也使其成为防止数据丢失的额外保护层。
对于本地快照，还原操作能够瞬时完成。更重要的是，即使对于云快照，还原操作仍然有望即时完成——这是因为Portworx只会在Amazon S3存储桶内为差异部分保存快照。
在性能与延迟方面，各个Pod将通过本地访问Portworx逻辑卷。在后台，Portworx将数据块复制到其他可用区内的其他工作节点处。如此一来，在故障转移过程中被转移至其他可用区的Pod，将可立即实现本地数据访问并恢复其正常运行。
部分Portworx客户需要超大规模数据库，例如Cassandra与Elasticsearch，在AWS之上持续管理数百TB级别的数据。通过实际运营，这类客户体会到在EBS上运行Portworx能够带来显著的成本效益。关于Portworx功能选项的更多详细信息，请参阅Portworx官方网站上的功能介绍内容。
到这里，我们已经解释了如何将Amazon EKS与Portworx协同使用，共同建立起可靠且灵活的SQL Server工作负载托管解决方案。在下一节中，我们将通过具体操作步骤，向大家介绍如何在Amazon EKS上实际部署SQL Server。您可以按照以下说明快速部署这类解决方案，并根据实际运行环境进行检查与调整。
先决条件
本文提到的解决方案基于PowerShell脚本，要求配合Windows PowerShell以及PowerShell Core以正常运行。如果希望在Widows 10或者Windows Server 2016环境下运行该脚本，您可以使用现有Windows PowerShell。另外，这套脚本也支持在MacBook或Linux计算机上运行，但要求您预先在目标设备上安装PowerShell Core。此外，Mac用户也可以参考ReadMe文件中的说明，参考相关准备要求实现Docker容器的本地化。
此脚本将调用AWS Tools for PowerShell中的PowerShell cmdlets。请确保在计算机上安装有最新版本的AWS Tools for Windows PowerShell 或者 AWS Tools for PowerShell Core。
此脚本有时需要借助AWS命令行界面（AWS CLI）工具以调用Amazon EKS API。因此，请保证提前安装有最新版本的AWS CLI。
最后，您需要在AWS账户中拥有运行此脚本所必需的权限，具体包括运行AWS CloudFormation模板，创建虚拟私有云（VPC）、子网、安全组、EC2实例，以及部署并访问EKS集群的权限。您也可以将IAM用户与计算机上一对长效编程密钥配合使用。在这种情况下，大家需要使用PowerShell与AWS CLI上的编程密钥方可启用AWS配置文件。
或者，您也可以使用IAM角色并向其中添加全部必要操作权限，这部分权限将被进一步分配给脚本运行所在的EC2实例。使用这一选项，大家将不需要其他额外配置，且AWS PowerShell工具及AWS CLI都将自动从EC2实例元数据中获取临时凭证。
另一种可选方案，是在软件包内添加Dockerfile，由其构建脚本并将之前提到的全部依赖项（AWS CLI、AWS cmdlets等）直接添加至 microsoft/powershell Docker镜像。通过这种方式，只要安装有Docker，大家即可直接使用docker run命令在MacOS、Linux或者Windows系统平台上设置运行环境。
在Amazon EKS上部署SQL Server
您可以运行脚本并提交相应参数，轻松实现SQL Server的部署操作。该脚本中包含多项参数，但对于初次尝试的用户来说，大部分参数并不需要调整、直接保留默认值即可。此外，这套脚本非常稳定，您可以使用相同参数多次重复运行此脚本。它会检查基础资源是否存在，并在可用的情况下加以复用。
下面来看脚本的具体操作步骤：
- 首先，脚本会为Amazon EKS创建IAM服务角色。我们需要使用此角色，以允许EKS代表用户在AWS中置备必要资源。
- 您需要VPC用于运行整个集群。该脚本将以参数形式接收一项AWS CloudFormation VPC栈名称。如果此栈已经存在，则脚本会自动复用该栈。如果不存在，则根据AWS提供的模板创建一个新栈。栈内包括运行集群所需的VPC、子网与安全组。
- 我们通过kubectl客户端工具配置Kubernetes并与之交互。此脚本将下载由AWS调整完成的kubectl版本，并将其安装在本地计算机之上。
- 在使用kubectl查询Amazon EKS时，AWS PowerShell工具中使用的AWS凭证将被传递至Amazon EKS。这项传递任务由aws-iam-authenticator工具执行，此脚本将自动完成该工具的下载与安装。
- 脚本创建一个新EKS集群。该EKS集群由位于三个AWS可用区的三个主节点托管组构成。
- 脚本配置kubectl，以接入上一步骤中创建完成的EKS集群。
- 脚本启动新的EC2实例，并通过配置使各实例加入EKS集群以作为工作节点。
- 脚本启动一个Etcd集群，作为Portworx的通信目标。
- 脚本随后下载DaemonSet规范，并将其应用于EKS集群。应用后，系统将自动安装Portworx云原生存储以及与之配套的GP2及IO1 EBS卷，用户可以根据需求任选其一或者二者兼用。
- 脚本在EKS集群内为Portworx卷创建一个Storage Class，且复制因子为3。通过这种方式，即使Kubernetes将您的SQL Server Pod重新调度至另一可用区，整套系统也能够在主机发生故障时维持SQL Server集群的高可用性。
- 脚本为EKS集群中的gp2 EBS卷创建一项Storage Class。
- 脚本在EKS集群内创建一项新的持久卷声明（PVC）。此PVC允许Portworx置备由底层Amazon EBS卷支持的持久卷（PV）。
- 脚本提供您为SQL Server SA用户设定密码。请输入一条符合默认SQL Server SA密码策略的高强度密码。脚本将把此密码以secret形式保存在EKS集群之内。
- 脚本随后创建SQL Server部署 (deployment)。此部署中包含一套副本集 (ReplicaSet)，该副本集随后将创建Kubernetes Pod。此Pod由运行SQL Server的单一容器组成。各PVC卷将被挂载至此容器上，您随后可使用SA密码启动该容器。
- 最后，脚本将输出端点名称。您可以在连接字符串中使用此名称以接入SQL Server实例。
脚本开始运行后，将部署一套EKS集群，在其上设置单一SQL Server实例。您可以再次运行我们提供的示例脚本，并在appName参数中使用不同名称以在同一EKS集群上部署其他SQL Server实例。
高可用性
示例脚本使用多可用区Kubernetes集群以及由Portworx卷支持的Storage Class（SC）进行SQL Server部署。在Portworx保护机制与SQL Server容器内数据副本功能的支持下，这套部署方案能够有效抵御以下情况：
- 容器故障
- Pod故障
- EC2实例故障
- EC2主机故障
- EBS磁盘故障
- EC2网络分区故障
- AWS 可用区故障
如果某一容器或Pod发生故障，Kubernetes会立即调度另一容器或Pod。即使将Kubernetes Pod重新部署至其他可用区，用户也不会遭遇任何数据丢失，Portworx会自动执行跨可用区数据复制操作。
在上一节中，我们提到将Portworx的复制因子设置为3。这意味着除了主PV之外，Portworx还将在集群中的其他位置处持续维护PV的两套额外副本。由于Amazon EBS卷仅能在单一可用区内维持高可用性，因此在默认情况下，Portworx会将额外副本分发至多个可用区内。相较于将SQL Server故障转移集群实例（FCI）部署在同一数据中心内的传统本地部署思路，Kubernetes与Portworx的最大改进正是体现在这种分布式可用区部署当中。由此实现的可用性与弹性水平皆远超传统本地部署。
在配备Portworx这类集群存储的Kubernetes上运行的SQL Server容器，拥有类似于在跨多个可用区的Storage Spaces Direct集群上运行SQL Server Always On FCI的可用性效果。结果是其恢复点目标（RPO）为零，恢复时间目标（RTO）将控制在10分钟之内，且足以抵御任何可能出现的主可用区故障。二者的区别在于，相较于在Windows Server故障转移集群上配置并维护SQL Server，EKS中的容器运行门槛更低、运营流程更加简单易行。
如果您运行的是SQL Server Standard版，则与传统Windows部署相比，此版本能够在容器与Amazon EKS层面带来更高的可用性水平。SQL Server Standard版FCI最多只支持双节点（单主节点加单辅助节点）。但容器本身可以部署在包含任意数量节点的集群之上。相比之下，Enterprise版SQL Server Always On FCI能够支持两个以上节点。但根据实际许可协议，您可能需要为其他实例单独购买使用许可。容器使用场景也不受此限，无论集群中包含多少辅助实例，您都只需要为单一容器支付许可费用。
大家也可以使用Always On可用性组部署SQL Server容器（在目前的SQL Server 2019中仍处于预览阶段）。这种配置类似于部署Always On可用性组，其中各参与节点本身就作为Always On FCI集群。但是，Always On可用性组与FCI存在某些繁琐的限制要求，可能与容器的灵活性原则相背。例如，我们无法从可用性组内的某一节点向辅助节点进行自动故障转移；此外，大家还需要为各个节点设置不同的FCI，这将增加额外的复杂性因素。
SQL Server容器许可
根据SQL Server 2017许可数据表所述：“SQL Sever 2017为虚拟机及容器提供使用权，旨在提升客户部署的灵活性水平。SQL Server 2017中的虚拟机与容器拥有两种主要许可选项：按单一虚拟机及容器授予许可，以及在高度虚拟化或高密度容器环境内进行高密度许可授权。”
通过对SQL Server工作负载进行容器化转换，您将显著降低许可成本。在某些情况下，您可以同时使用按容器许可模型加按物理主机许可模型（高密度），借此将许可数量控制在最低水平。
如果您需要在EC2实例上运行多款应用程序，且希望这些应用程序能够在同一主机上跟SQL服务器并发运行，则应优先考虑使用按容器许可。如果不使用容器，即直接在虚拟机（包括各类EC2实例）上运行SQL Sever，则需要为虚拟机中所有可用的vCPU购买许可——无论工作负载在运行中实际使用到多少个vCPU。但如果在虚拟机上通过容器运行SQL Server，我们可以限制容器所能访问的vCPU数量，并借此提升运营成本的可预测性。大家能够通过这种方式按必要核心数量采购许可，最低许可采购数量为4核心，之后以2核心为单位递增，即4核心、6核心、8核心等。
如果您的SQL Server实例fleet存在明确峰值利用率波动模式，本文建议使用容器选择高密度运行模式。在这类场景下，您应选择基于物理主机的许可模式。只要所有物理核心都获得适当许可，即可在有限的物理核心之上运行无限数量的容器与任意数量的vCPU。
上图中，包含12个vCPU核心与20个容器。但由于这一切都仅运行在6个物理核心之上，因此我们只需要购买6核心许可。这种方式特别适合那些在内部环境中过度配置SQL Server虚拟机的企业。EC2实例的固定超线程比率为1物理核心对应2 vCPU，如果贸然以3：1、4：1甚至5：1的过度配置比例使用EC2实例，往往会导致运营成本迅速失控。容器化技术不仅能够有效解决这一难题，同时也能保证性能表现始终处于理想区间。
Portworx许可
Portworx提供补充许可模式，用于支持高密度容器环境。Kubernetes项目建议用户在每个节点中部署不超过100个Pod，因此从理论上讲，每个EC2实例上最多可以运行100个SQL Server Pod，这将大大节约SQL Server许可费用。而Portworx的每个EC2实例只需要一份许可，无论其中运行有多少个容器、消耗掉多少存储空间。因此，对于高密度集群，大家获得的绝不是把一种许可换成另一种许可那么简单——相反，每台主机上运行的SQL Server越多，平均许可成本也就越低。Portworx能够在单一集群上支持数千个节点，并在各节点中容纳数百个有状态容器。
不适合使用SQL Server容器的情况
根据当前发行版的实际情况，某些SQL Server工作负载及应用场景并不适合进行容器化。首先，SQL Server容器目前仅由SQL Server 2017版本提供，意味着任何较早版本的SQL Server工作负载皆无法实现容器化。但SQL Server 2017能够向下兼容SQL Server 2008之后的所有版本，因此大家可以在SQL Server 2017实例（包括运行在容器中的实例）内部还原创建于SQL Server 2008或其他更高版本中的数据库，以兼容模式使其正常运行。
此外，尽管Linux上的SQL Server能够与微软Active Directory相集成，但SQL Server容器目前尚不支持这一集成功能。
SQL Server的另一项常用功能，为横向读取扩展功能，大家可以将其作为Always On可用性组使用。此功能目前仅提供预览版本，尚无法稳定支持生产级用例。
云服务最激动人心的一大核心优势，在于将许可与服务整合起来。对于相当一部分企业客户，根据实际软件使用量管理许可协议及采购数量无疑是一项繁重的任务。其中还存在着很多难以察觉的“陷阱”，例如过度采购自己根本用不到的许可指标，或者未能严格遵守供应商提出的使用条款。SQL Server容器目前只提供“自带许可（BYOL）”模型，意味着所有许可获取与管理工作只能由客户自行承担，大家应在决策考量中认真斟酌这方面成本。
还有其他一些当前尚未正式推出的功能，例如分布式事务处理协调器（DTC）与自定义CLR用户类型等。如果您的SQL Server工作负载具有一致性较高的静态资源使用模式，那么传统部署模式也许更加稳定可靠。
总结
在本文中，我们探讨了在容器中使用Portworx运行SQL Server的主要助益，并对其优缺点做出了全面剖析。
这种方法具有以下优点：
- 简单易行，可减轻一部分管理负担。
- 释放一部分闲置资源容量并转交给工作负载，借此提升应用程序性能水平。
- 能够改进现有部署的数据保护与故障转移能力。
- 能够降低基础设施运营成本。
- 能够降低SQL Server许可成本。
本文介绍了如何轻松使用Portworx在Amazon EKS上部署SQL Server。大家可以通过简单的脚本调用AWS API，借此配置基础设施与EKS集群并运行SQL Server容器。根据大家的实际要求，您也可以从以下两种主要存储选项中做出选择：
- 使用单一EBS卷作为PVC，在单一可用区内实现高可用性，并降低存储成本。
- 在多可用区中使用集群存储解决方案（例如Portworx），通过强大的可用区故障抵御机制提高可用性水平。