SQL Server：不计代价保护数据

  • 项目

对任何数据管理策略而言，维护通过 SQL Server 管理的公司数据存储的高可用性都是不可或缺的要素。

Paul S. Randal

倘若不具备持续存储和检索数据的能力，业务就会陷入停顿。数据正日益成为任何企业中除人员之外最重要的资产。而 SQL Server 2008 或 SQL Server 2008 R2 常常是任何数据管理策略的核心所在。从这个角度讲，是开发人员和 DBA 在负责保持业务的运行。

但是，明确的业务指示从业务部门经理层层传达下来，会有多少到达了负责数据层的人员那里？业务要求的传达是否清晰明确？业务要求的传达方式是否能使技术人员将它们转换为生产策略？

某些市场领域在基础结构方面有严格的法规要求，如安全审核、数据加密和数据保留等。违反这些要求会导致企业遭受罚款或谴责，还会导致公信力和未来收益的丧失 — 在高度竞争的市场环境中，没什么比这更糟糕了。

调整数据管理策略

有些业务要求可由业务主管比较容易或比较直接地进行传达，如关于安全、报告、工作负荷管理和审核方面的要求。幸运的是，您使用 SQL Server 2008 的框架也可以轻松实现它们：

  • 为满足数据安全性要求，您可以使用透明数据加密之类的功能对空闲数据进行加密，并使用可扩展秘钥管理功能将加密秘钥存储在“箱外”远离加密数据的地方。
  • 使用 SQL Server Reporting Services 可以满足报告要求。
  • 资源调控器可以帮助您预测工作负荷性能。
  • 可以使用 SQL Server Audit 满足全面的审核要求。

不过，有两个重要的业务要求往往沟通不足：系统停机时间和可接受的数据丢失。两者分别称为恢复时间目标 (RTO) 和恢复点目标 (RPO)。遗憾的是，业务经理忽视 RTO 和 RPO 的现象非常普遍，往往到灾难发生导致停机或数据丢失时才意识到对数据层的保护没有达到期望的程度。

无论您是业务经理还是 DBA，请立刻花点时间考虑一下您是否确信对数据层的保护符合业务要求。如果您意识到保护力度不够，您计划怎么处理这种情况？

正确的反应是不骄不躁。在下周之前进行一次“消防演习”并据此制定策略才是应对灾难的方法。设计并实现合理且全面的 SQL Server 高可用性及灾难恢复 (HA/DR) 策略需要谨慎而努力的工作。忽略此问题会导致灾难的发生，会造成与业务过失同样严重的后果。

明确要求

设计成功策略的关键是先明确业务要求。然后，必须在业务要求和业务限制之间做出权衡。为此，IT 主管和业务部门主管必须当面交流，并达成一致的看法。策略要求在关于业务运作的数据的每个部分都必须包含以下因素：

  1. 此部分数据与其余公司数据存储相比有多重要？业务经理常说一切都同等重要，必须提供同等的保护。对于少量数据可以这样，但如果有数 TB 的数据分布在多个 SQL Server 实例上，这样做就不太现实了。
  2. 企业可以承受丢失多少数据？业务所有者当然希望看到数据零丢失，但这个要求有时不太现实。
  3. 可以允许数据多长时间不可用？业务所有者自然也希望看到零停机时间，但很遗憾，这也不太现实。不过，您可以非常接近这个希望。
  4. 第一或第二个因素在一天的不同时间或在周末会不会有变化？这会对您满足要求的能力产生重大影响。与 24x365 的完全访问相比，一定时间段（比如工作日上午 9 点到下午 5 点）的零停机时间和零数据丢失实现起来要容易得多。
  5. 是否可以接受牺牲工作负荷性能以保持数据可用性和持续性？可以提供零数据丢失的技术都要求对事务日志记录或 I/O 子系统写入进行同步镜像。这些都会导致处理延迟。这里需要做出取舍。

考虑这些问题的一个好方法是想一想各数据部分不可访问或丢失时对业务的影响。当您充分考虑并量化您的客户、企业形象和法规控制的潜在后果后，您可能会感到惊讶。

明确限制

设计和实现 HA/DR 策略时更常见的一个错误是以技术设计为先，而不先考虑限制因素。这样做意味着您要从头开始设计（浪费时间和金钱）或实现一个不能满足业务要求的次标准策略。

限制因素有很多，技术和非技术方面都有。最主要的因素通常是预算。更多硬件意味着更多能耗，更多能耗意味着更多热量散失，更多热量散失意味着更多空气调节系统，更多空气调节系统又意味着更多能耗，而这些都意味着需要为物理基础设施分配更多空间和更多预算。还必须考虑硬件、额外的 SQL Server 和 Windows 许可证、网络带宽的成本，甚至是为管理额外的系统和数据中心其余部分而可能增加的更多人员成本。

妥协与公司拼图

在熟悉所有技术限制以后，关键就是要达到最有效的妥协。您需要最重要业务数据的优先列表。给定工作限制后，您需要评估可以帮助您满足最重要的业务要求的技术。

切勿仅仅凭借对现用技术的调整来满足新的业务要求。切勿匆忙改用或选择一项技术，而不针对您的业务优先级对该技术进行合理评估。事先做足准备然后合理行事总是有利无弊。最后您会得到一个可以在长期运行中节省时间和金钱的更好策略。

如果您发现无法采用预算内的技术满足业务要求，则需要与业务部门主管一起更改要求以符合预算现实。例如，作为一名技术人员，如果预算中没有足够的资金采用同步技术，就没有理由同意零数据丢失的业务要求。当灾难发生时，业务经理的期望无法得到满足，而过错会落在 IT 人员身上。

在设计 HA/DR 策略时，最困难的工作之一往往是如何确保该策略构成组织整体 IT 策略的和谐组成部分。例如，如果您是一家大型公司的 DBA，可能有其他团队负责 Windows 服务器、网络、存储、构建基础结构等。如果业务要求某一特定数据库在任何灾难后须在四小时内恢复可用，您可能需要与所有这些团队协同工作以确保实现这一点。这就涉及到团队间政治和关系处理。其他团队必须同意满足与数据层团队相同的服务级别协议，以及对整体业务的期望和承诺。

测试，测试

如果您认为数据层保护不足，那么很可能表示 HA/DR 策略也没有在您的企业中进行合理测试。在设计和实现 HA/DR 策略的过程中，必须实际测试系统，以便它可以在出现危机时进行响应。

但说起来容易做起来难。说服业务经理执行可能引起停机的测试是一项挑战。您可以建议在执行测试时，最好所有人都在现场，等待“灾难”发生并随时准备参与并快速修复任何问题。或者，可以安排灾难在公司某个假日的凌晨 2 点发生，仅召集一些骨干人员留在现场，从而发现设计缺陷。

即使您发现数据层的停机时间和数据丢失防护没有达到可接受的程度，仍然可以使用 SQL Server 2008 或 SQL Server 2008 R2 中的许多选项来实现 HA/DR 策略。您应了解各种技术并权衡其利弊，并考察其他公司成功部署的体系结构。有关更多信息，请查看以下白皮书和博客文章：

您的工作务必以有效策略的实施为目标。这是保护业务和避免意外停机的唯一途径。

Paul Randal

Paul S. Randal是 SQLskills.com 的常务董事、Microsoft 区域总监和 SQL Server MVP。从 1999 年到 2007 年，他一直在 Microsoft 的 SQL Server 存储引擎团队工作。他曾编写过 DBCC CHECKDB/repair for SQL Server 2005，并在 SQL Server 2008 的开发过程中负责核心存储引擎部分的工作。Randal 是灾难恢复、高可用性和数据库维护方面的专家，经常在全球出席一些会议。您可以访问他的博客 SQLskills.com/blogs/paul，也可以通过 Twitter (twitter.com/PaulRandal) 了解他。

相关内容