Date: 2月 9, 2018
迁移到云中的潜在成本节约几乎是不可能的。但是，当你停止计算你将要存储的资金之后，你就开始思考安全性和可用性等问题，并想知道云是否适合你。但是不要害怕，我们只有正确的解决方案 – SIOS Datakeeper Cluster Edition。在传统的数据中心，您可以控制并部署您喜欢的任何安全性和高可用性解决方案。但是，一旦决定将服务器移到云中，您的选择就会变得更加有限。无论您是在亚马逊，Google还是微软，无论是在云端出现故障还是出现故障，您都需要尽一切可能来缓解这些风险。
亚马逊网络服务
我们来仔细看一下Amazon Web Services（AWS）。有什么选项可以确保您的SQL Server数据库能够在意外中断的情况下幸存下来？虽然有些应用程序可以跨多个可用区域以负载平衡配置进行部署，但SQL Server通常不会以负载平衡配置进行部署。这意味着SQL Server本身驻留在单个可用区域中，如果该区域不可用，则整个应用程序堆栈可能会陷入瘫痪。
SQL Server 2008 R2及其限制
如果您阅读Miles Ward撰写的这篇文章，您会发现在SQL Server 2008 R2中，您的可用性选项非常有限。在第11页的那篇文章中，有一个很好的图表，列出了您的高可用性选项。正如你所看到的，这些选择是非常有限的，大部分都不属于被称为医管局的类别。日志传送，镜像和事务复制几乎是您拥有的唯一选项，它们更多是数据保护选项而不是HA选项。如果您希望Microsoft故障转移群集，那么由于AWS中的某些网络限制（客户端无法连接到群集IP地址）以及缺少传统SQL群集所需的共享磁盘资源，您将发现自己不幸运。
AWS
如果你正在寻找部署SQL Server 2012，你的选择会好一点。正如Jeremy Peschka所述，只需少量手动干预，您就可以在AWS中部署AlwaysOn可用性组，以执行从数据中心到AWS的甚至在AWS可用性组之间的异步复制。当然，这假定您拥有AlwaysOn可用性组所需的SQL 2012 Enterprise许可证。唯一的问题是，AWS实际上不支持将群集IP地址从一个服务器移动到另一个服务器，因此客户端重定向必须使用ec2-unassign-private-ip-addresses和ec2-assign-private-ip手动完成在佩斯卡在他的文章中所描述的转换之后的地址命令。总而言之，这是一个非常手动的过程，这再一次不适合描述高度可用的系统。
解决方案的局限性
如果您可以在没有自动恢复的情况下运行，并且可以在之前的博客文章中描述的AlwaysOn可用性组限制，那么您可能只想继续尝试AWS中的AlwaysOn可用性组部署。但是，如果您正在寻找更简单，更实惠，更强大的高可用性解决方案，那么我有一些非常好的消息。SIOS技术公司一直在研究这个问题，并开发了一种解决方案，克服了前面描述的所有限制，并且将作为AMI提供，以便于部署。这个解决方案目前处于内部测试阶段，但将在今年晚些时候广泛推出。
SIOS DataKeeper集群版
SIOS解决方案基于使用DataKeeper Cluster Edition主机复制的Microsoft故障转移群集中的SQL Server。通过使用基于托管的复制，他们已经克服了EC2中集群的第一个障碍 – 缺乏共享存储。SIOS必须克服的第二个障碍是Peschka描述的客户端重定向问题;客户端访问点需要在EC2内进行操作，而不是故障转移群集。SIOS在他们的AMI解决方案中建立了智能，使得IP地址的重新分配作为集群故障转移过程的一部分被自动化，有效地模拟了您通常期望从集群获得的行为。因为所有这些都是建立在故障转移群集之上的，所以可以使用SQL 2008/2008 R2或2012进行部署。即使是SQL Server的标准版也将支持双节点集群，因此与部署SQL 2012 AlwaysOn可用性组相比，可节省大量成本。让我知道你的想法。SIOS Datakeeper Cluster Edition听起来有趣吗？今天你在做什么来确保你的SQL Server EC2实例的可用性？转载https://clusteringformeremortals.com/2013/01/11/sql-server-high-availability-in-aws-cloud/