快速,持续,稳定,傻瓜式
支持Mysql,Sqlserver数据同步

小型企业的高可用性和灾难恢复

在线QQ客服:1922638

专业的SQL Server、MySQL数据库同步软件

在过去,对于那些财大气粗的企业来说,高可用性和灾难恢复已成为昂贵的选择。事实是,通过精心计划,可以为小型企业提供明智且经济的解决方案,这些解决方案可以在灾难发生时保持业务连续性。

介绍

对小型企业的高可用性和灾难恢复(或简称为HA / DR)的成本存在很多误解。基于这些误解的任何结论都可能对企业造成严重后果。两种较常见的误解是:

  • 防灾是很昂贵的。制定可靠的灾难恢复计划至少需要花费六位数的预算,例如可以立即打开远程服务器集。
  • 为了使我们的数据库高度可用,必须具有SQL Server企业版。标准版没有所需的功能。

在以下各节中,我们将证明这两个声明在专利上都是可证明是错误的。是的,您确实可以花费数百万美元来创建各种复杂的灾难恢复解决方案。的确,尤其是自从SQL 2012中引入AlwaysOn /可用性组以来,企业版在设计高可用性解决方案时提供了一些非常吸引人的功能。但是,正如我们将看到的,还可以使我们的应用程序和服务具有高可用性,并具有抵御灾难的能力,而无需花费大量金钱或切换到成本更高的企业版SQL。

但是首先,我想解释一下为什么为小型企业考虑高可用性和灾难恢复如此重要。

事物状态

小型企业可能会遭受任何灾难的严重打击。2011年,赛门铁克对1,288家小型企业(定义为拥有5至1,000名员工的小型企业)的灾难恢复计划和实践进行了调查。结果令人震惊。

只有一半接受调查的企业表示他们制定了任何计划。在接受调查的最小公司中,该数字下降到百分之四十三(43%)。14%的人表示,他们不仅没有计划,而且也无意创建任何计划。当前没有计划的人中有52%表示这是因为他们认为自己的IT资产对他们的业务不重要,而41%的人表示从未计划过灾难。40%的人甚至说灾难规划甚至都不是优先事项。

这种松懈的态度是不现实的。在接受调查的企业中,很大一部分(65%)认为他们居住在“他们认为容易遭受自然灾害的地区”。由于“电源中断,员工错误和升级”等可预防和/或可缓解的原因,这些业务每年平均还会发生六次中断。灾难还使小型企业遭受重创,每天平均损失3,000美元(中型企业每天损失中位数为23,000美元)。

最终,灾难的痛苦不仅由企业本身引起,而且由客户引起。在研究中接受调查的那些客户报告说,他们的SMB供应商的服务中断平均每天使他们损失10,000美元。毫不奇怪,这会导致大量客户流失:超过一半(54%)的受访者表示由于“不可靠的计算系统”而更换了供应商。

根据这些数字,为那些为小型企业服务的DBA和IT专业人员,计划灾难恢复和我们系统的可用性至关重要。

预算中HA / DR的两种策略

由于小型企业通常不愿承担成本,并且没有多余的资本,所以我试图选择一种方法,以尽量减少不必要的成本或间接费用。这并不是说它们很便宜。在许多情况下,随着复杂性和保护级别的增加,成本也随之增加,我们需要仔细考虑在提高弹性和支付更多成本之间进行权衡的问题。但是,确实没有充分的理由不采取某种策略,最好是采取某种程度的异地冗余策略。

让我们深入研究两种非常适合小型企业的策略。

使用云

许多小型企业处于地域锁定状态,这意味着它们的大部分(如果不是全部)业务都位于一个物理位置。因此,他们无法利用分支机构来实现冗余。但是,为什么不使用某个遥远的城市或数据中心中的设施,为什么不使用众多可用的云提供商中的一个呢?

让我们从一个非常简单的要求开始:将所有备份(完整,差异和事务日志)保存在异地位置。请注意,这不是真正的“高可用性”解决方案,因为它无法提供在本地故障情况下大幅减少停机时间的方法(即,我们仍然必须从头开始重建所有内容,然后还原备份)。它的作用是保护数据免受因火灾,洪水或故意破坏等局部灾难而造成的全部损失,这是在计划灾难恢复时需要考虑的所有情况。

以下是截至发布之日与一些云提供商中的数据存储相关的成本示例(请检查包含的链接,这些价格通常会发生变化)。为了进行比较,我们将说总共需要(100 GB数据* 14天备份)总共1.4 TB的数据存储,以及每天约100 GB的数据传输。

提供商名称 每GB成本 其他费用 资源
亚马逊S3 前1TB每GB $ 0.03 / GB,最多49TB每增加$ 0.0295。总计:$ 42.52 每1000个请求0.005 USD,数据传输免费 https://aws.amazon.com/s3/pricing/
亚马逊冰川 每GB固定费率$ 0.01。总计:$ 14.24 每1,000个请求$ 0.05,免费进行数据传输 https://aws.amazon.com/glacier/pricing/
机架空间云 前1TB每GB $ 0.10,每GB $ 0.09,最多49TB。总计:$ 138.40 传入数据传输是免费的。 http://www.rackspace.com/cloud/public-pricing/#cloud-files
Windows Azure 前1TB每GB $ 0.03 / GB,最多49TB每增加$ 0.0295。总计:$ 42.52 每100,000个请求0.0036 USD,数据传输是免费的。 http://azure.microsoft.com/zh-CN/pricing/details/storage/

查看(目前至少)最便宜的解决方案Amazon Glacier,我们每个月要花费不到20美元,以确保备份安全地存储在异地。二十美元。这比每天拿铁咖啡的费用还便宜。是的,将需要时间和成本来获取必要的软件,以使我们能够将数据库备份到云(例如,Cloudberry Backup产品目前的零售价为79.99美元;必要的免责声明是我不是专门推荐此软件,它是只是说明问题所在并设置备份过程,但与我们要减轻的风险相比,这些似乎很小。

让我们简要地看一个更复杂的示例,即将备用服务器保留在云中以进行恢复。为简单起见,我们将仅以亚马逊作为供应商。看亚马逊的AWS计算器,我选择了“ m3.large上的Windows和标准SQL”映像,其中包括以下内容:2vCPU,7.5GB RAM,1x32GB SSD驱动器。然后,我在“通用SSD”存储上添加了100GB数据和25GB日志驱动器。假设正常运行时间为100%,则每月的费用约为530美元,这不包括数据输入或输出的费用。因此,尽管我们希望看到明显更高的成本,但它并不接近六位数。如果我们可以在没有真正的“热”待机的情况下(并保持某些状态,但要关闭电源并准备就绪),那么可以通过关闭计算实例直到需要时使价格更具吸引力。这样可以将成本降低到每月仅$ 9.50(主要是因为我们只为存储付费)。

借助云计算平台的强大功能,即使对于小型企业,以一种或另一种形式进行异地冗余也是完全可行的。当然会有一条学习曲线,也许还有在设置中保留专门的IT小组的成本。但这仍然是我们寻求保护数据的一种非常有价值的途径。

利用您所拥有的

过去我曾听人说过,如果您想要真正的高可用性选项,则必须为企业版SQL Server的更高成本付费。坦白说,事实并非如此。是的,确实,Enterprise为您提供了更多选择。AlwaysOn /可用性组是一项很棒的功能,也是我个人喜欢的功能,但它当然不是我们工具箱中唯一的功能。

在使我们的数据库高度可用时,SQL Standard Edition当前具有三个经过验证的出色选择:群集,镜像和日志传送。注意:我之所以说“当前”,是因为Microsoft声明镜像已被弃用,并且在SQL Server的未来版本中将被删除。尽管如此,还是值得与其他两个一起考虑。让我们研究一下每种方法的优缺点。

聚类

故障转移群集涉及拥有一个可以在两个(或更多,但仅在企业版中)服务器上运行的SQL实例。如果实例由于某种原因当前驻留在实例上,则该实例可以按需或自动在两者之间进行故障转移。例如,如果服务器蓝屏,则被动节点(SQL实例未驻留在其上的服务器)检测到此情况,并在声明所有相关资源(磁盘,网络名称等)后使SQL联机。群集可同时防止硬件和操作系统故障。在2008 R2及更高版本的SQL版本中,您还可以使用滚动升级过程,使用群集来应用SQL修补程序而不会造成停机。

群集设置(至少以我的经验)可能很难设置并保持平稳运行,尽管在Windows的最新版本中群集变得更好。群集还需要Windows企业版(在Server 2012及更高版本中,标准版也包含此功能)除外,这意味着更高的成本。另外,共享存储的必要性增加了设置的成本和复杂性:您要么必须拥有SAN,要么配置像这样的共享直接附加存储(DAS)机柜。您还具有内置的单点故障,即后端存储。

镜射

数据库镜像通过网络将数据库上发生的所有事务发送到辅助副本。该辅助服务器保持脱机状态,但在必要时可以使其联机。可选地,可以使用第三台“见证”服务器,以在主要(数据库通常所在的服务器)故障的情况下进行自动故障转移。在标准版中,我们只能选择“同步”镜像模式,这意味着在将事务也提交到镜像之前,它们实际上不会在主体上提交。这具有确保零数据丢失的优势,而且如果主服务器和辅助服务器之间的网络链接饱和或通过较慢的连接(例如WAN),也将延迟引入了方程式。

镜像的一个不错的功能就是所谓的“ 自动页面修复”。当SQL Server检测到页面损坏或损坏时,它将检查辅助页面,以查看那里是否有同一页面的最新版本。如果是这样,则无需进一步的用户干预即可检索和修复页面。

在标准版中,镜像是当前唯一的高可用性解决方案,该解决方案可确保零数据丢失,同时仍可防止出现完全故障。例如,您可以通过确保辅助服务器的存储和网络连接(以及存储所处的位置,例如在单独的SAN或本地连接的阵列上)独立于每个,从而将辅助服务器配置为完全独立于第一个服务器。其他。

由于它是在数据库级别完成的,因此可以想象,随着镜像数据库数量的增加,镜像可能会产生相当多的开销,尤其是在整个系统的高事务处理方面。(Microsoft 特别声明在32位系统上最多可以包含十个数据库。)

日志传送

日志传送确实非常简单:我们在一个或多个辅助服务器上还原数据库的副本,这些服务器处于备用(基本为只读)或无恢复模式(离线等待还原)。然后,我们将作业设置为将事务日志备份从主数据库复制到可共同访问的位置,在该位置辅助数据库可以拾取并还原它们。至少以我的经验来看,这可能是三种解决方案中最简单的一种。它也是唯一一个允许您访问数据的第二个副本(虽然在还原作业运行时是只读且中断的)以及数据的多个副本(即,您有多个辅助服务器,所有还原日志备份的副本)他们自己)。我们可以设置一个已知的延迟时间,即在主数据库上进行日志备份与在辅助数据库上应用日志备份之间,

在配置日志传送时,必须允许日志传送框架处理对已传送数据库的事务日志备份。这意味着您需要找到一种将这些数据库从定期计划的日志备份中排除的方法。自然,任何体面的维护框架(例如Ola Hallengren 屡获殊荣的套件)都允许这样做,但是仍然需要对其进行计划。也没有什么可以阻止您推出自己的自定义日志传送框架,尽管在许多情况下,这样做的额外费用/开销不值得拥有自己的灵活性。

连连看

也没什么好说的,您不能将上面给出的选择混合和匹配到您自己的具有高可用性的特殊酱料中。在许多情况下,没有一种解决方案可以满足所有需求,因此将它们组合是最佳方法。例如,您可以设置故障转移群集以防止硬件故障并简化维护,还可以将日志传送到云中的远程备用服务器以进行灾难恢复。

您还可以在本地组合数据库镜像(以确保零数据丢失的备用副本),同时再次利用日志传送到远程实例或报告辅助数据库。这是一个众所周知的配置,Microsoft有用地发布了有关使用它的一些准则。

最终,所有这些都是关于预先定义您的需求,然后着手设计满足需求的解决方案。

结论

在本文的开头,我们提出了两个我们需要研究和证明的误解:

  • 灾难恢复保护成本高昂
  • 只有使用企业版的用户才能利用SQL Server的内置功能实现高可用性。

两者都不正确;得益于云技术,价格已经下降到任何企业,无论其规模大小,都可以提供一定程度的灾难防护。SQL Server标准版包含三种成熟的技术,用于提供高可用性数据库。我们还看到了中小企业如何容易遭受灾难和数据丢失,证明了解决这些问题的周密计划是这些组织中SQL Server专业人员的关键角色。我们必须积极保护数据,以便在灾难确实发生时,我们能够及时恢复业务,并回到小型企业最擅长的领域:为客户服务。

相关推荐

咨询软件
 
QQ在线咨询
售前咨询热线
QQ1922638