有关使用 Amazon EBS io2 Block Express 卷最大 64 TiB优化 A

优化 Amazon RDS for SQL Server 的最佳实践

关键要点

高性能：使用 Amazon EBS io2 Block Express 卷支持高达 64 TiB 的存储。选择合适的实例类型：了解 RDS DB 实例和存储类型的最大 IOPS 和吞吐量限制。迁移数据库：通过 SQL Server 的原生备份和恢复来迁移数据库。优化自动备份：按需调整备份策略以提高恢复性能。监控和维护：及时调节存储和实例类型，以优化性能和可用性。

Amazon Relational Database Service (Amazon RDS) for SQL Server 现在支持 Amazon Elastic Block Store (Amazon EBS) 的 io2 Block Express 卷。这些卷旨在支持所有关键的数据库工作负载，要求高性能、高吞吐量和持续低延迟。io2 Block Express 卷支持 99999 的耐用性、最高 64 TiB 存储、最高 4000 MiB/s 的吞吐量，以及最高 256000 的预配置 IOPS，满足您最苛刻的数据库需求，且价格与 EBS io1 卷相同。

在本文中，我们分享与 RDS for SQL Server 数据库实例一起使用 io2 Block Express 卷的最佳实践。

加速器登ins免费永久

选择合适的 RDS DB 实例类型与 io2 Block Express 卷

RDS DB 实例的性能取决于实例类型和存储类型。因此，了解 RDS DB 实例和 EBS 卷级别适用的最大 IOPS 和吞吐量限制至关重要。对于高性能工作负载，建议将 预配置 IOPS SSD 存储 (io2) 与强大的 DB 实例类类型如 X2iedn、R6i 或 R5b配对。对于需求较低的工作负载，使用 通用类型实例类如 m5i/m6i和存储gp2/gp3可能就足够。

为了确定适合您工作负载的最佳组合，请遵循以下步骤：

确定您的应用工作负载的 IOPS 和吞吐量要求。选择符合 CPU、内存和网络性能要求的 RDS DB 实例类型。根据 IOPS 和吞吐量要求选择合适的存储类型，可以是通用型或预配置 IOPS 存储。

以下图表显示了根据 IOPS、吞吐量和容量要求的 RDS DB 实例存储决策树。

如果满足以下任一条件，您应该选择 io2 卷：

应用需要高 IOPS超过 16000 IOPS。您需要低延迟和高吞吐量超过 1000 MiB/s以确保一致的性能。存储容量需求超过 16 TiB。应用程序要求高耐用性和可用性具有 99999 的耐用性 SLA。您正在运行需要持续高性能的关键数据库或应用程序。

请访问 文档 查看您所在 AWS 区域的 io2 Block Express 卷的可用性。

io2 Block Express 卷组合的性能会根据所选择的 RDS DB 实例类和大小而有所变化。以下表格显示了不同支持的 RDS 实例类中最大的 RDS DB 实例大小及相应的 io2 Block Express 性能限制。

DB 实例类最大吞吐量限制 (MiB)最大 IOPS 限制 (16 KiB I/O)最大 DB 实例大小X2iedn10000260000dbx2iedn32xlargeR5b7500260000dbr5b24xlargeR6i/M6i5000160000dbr6i32xlargeR5d/M5d/Z1d237580000dbr5d24xlarge dbm5d24xlarge dbz1d12xlargeR5/M5237580000dbr524xlarge dbm524xlarge

要查找适用于 Amazon RDS for SQL Server 的 DB 实例类，请参阅 SQL Server 的 DB 实例类支持。有关支持的实例级基本吞吐量、最大 IOPS 和最大吞吐量的更多信息，请参见 Amazon EBS 优化的实例。

有关支持的实例和卷组合，请始终参考最新的 AWS 文档，因为这些限制可能会随着 AWS 更新和增强而变化。

将 SQL Server 数据库迁移到使用 io2 Block Express 卷的 Amazon RDS

将数据库迁移到使用 io2 Block Express 卷的 RDS for SQL Server 数据库实例的过程与迁移到其他卷如 gp2、gp3 和 io1非常相似。主要的区别是，使用 io2 卷时，您现在可以迁移高达 64 TiB 的大型数据库工作负载。使用 Amazon Simple Storage ServiceAmazon S3的 SQL Server 原生备份和恢复是将运行在本地或 Amazon Elastic Compute CloudAmazon EC2实例上的 SQL Server 数据库迁移到 Amazon RDS for SQL Server 的最常用方法。了解更多内容，请参考 使用 Amazon S3 备份和恢复。

恢复大型数据库可能会是一个耗时的过程。然而，您可以通过使用完整、差异和日志备份策略来优化恢复时间，这可以帮助减少切换时间。此外，您可以使用备份压缩和多个备份文件来提高备份和恢复性能有关更多详细信息，请参见 提高 Amazon RDS for SQL Server 的原生备份和恢复性能。为了改善恢复性能，请确保监控 RDS DB 实例的网络和 EBS 带宽使用情况。如果发现瓶颈，请考虑扩展实例大小或相应地预配置额外的存储 IOPS 和吞吐量，以更快地完成恢复。

在 Amazon RDS for SQL Server 上将卷类型修改为 io2 Block Express

Amazon RDS for SQL Server 为您提供了在通用型gp2/gp3和预配置 IOPSio1/io2卷之间更改的灵活性，以满足您的性能需求变化。您可以根据应用程序需求的变化在卷类型之间进行切换，以平衡成本和性能。您可以通过 AWS 管理控制台 或 AWS 命令行界面AWS CLI将 RDS Server 实例的存储类型从 gp2、gp3 或 io1 修改为 io2 Block Express。

但在使用 io2 卷时，有一件重要的事情需要考虑。如果您使用 io2 卷，并且存储大小超过 16 TiB，则无法更改回 gp2、gp3 或 io1。在这种情况下，要返回到 gp2、gp3 或 io1，您需要创建一个新的具有 gp2、gp3 或 io1 卷的实例，并使用 SQL Server 原生备份和恢复迁移数据库。有关修改现有 RDS for SQL Server 实例卷类型的技术详细信息和说明，请参阅 为 Amazon RDS DB 实例处理存储。

管理大型 io2 卷的自动备份

第一个 RDS DB 快照捕获您 DB 实例存储卷的完整备份。相同实例的后续备份为增量 DB 快照，这意味着它们仅保存自上次备份以来已更改的数据。在大多数情况下，您的 DB 实例每日备份会很快完成，因为这些每日备份是增量的。然而，在某些情况下，如果自动备份被禁用，并且在没有备份的情况下负载较重或经过多天，则下一次备份可能会由于增量 DB 快照中累积的数据而需要较长时间才能完成。当数据变更达到 64 TiB 时，备份过程可能需要长达 4 天才能完成。在此期间，实例将保持完全功能和可用；但是，实例级修改例如更改实例类型或将实例从单个可用区转换到多个可用区将受到限制。

为减少大型数据库长时间运行的 DB 快照的可能性，您可以采取以下措施：

考虑始终在 RDS DB 实例上启用 自动备份。这可确保自上次 DB 快照以来的增量数据变化不会积累得太久。对于大型 RDS DB 实例，每日自动备份快照可能需要较长时间才能完成。因此，建议将备份保留期设置为至少 7 天，以提供时间点恢复 (PITR)。这确保 DB 实例备份的可用性，即使您在下一个备份窗口中错过了时间，因为备份完成时间较长。对于 MultiAZ 实例，建议每 12 个月执行一次计划的手动故障切换。这一主动措施有助于维护您的 MultiAZ 部署的健康，并避免在意外故障后可能发生的备份时间过长。执行定期故障切换还确保该过程平滑高效，有助于验证您的故障切换策略，并增强您对高可用性的信心。

使用手动快照优化自动备份时间和 PITR

在进行大数据加载后立即进行手动快照，可以确保下一个自动备份只需捕获自上次快照以来的变化。这一主动步骤可以显著减少后续自动备份所需的时间，因为它最小化了需要备份的数据量。通过减少整体备份持续时间，您可以维护 RDS 实例在高峰操作期间的性能和可用性。有关创建手动快照的详细说明，请参见 为单个可用区 DB 实例创建 DB 快照。

此外，我们观察到，这一做法也改善了 PITR 性能。您可以使用 EBS io2 Block Express 卷将 RDS for SQL Server 实例恢复到 使用 PITR 功能的特定时间。

从 DB 快照恢复

您可以使用控制台、AWS CLI 或 Amazon RDS API 从 DB 快照恢复 RDS DB 实例。当恢复的 DB 实例状态为可用时，您可以立即开始使用它。然而，您的恢复的 DB 实例仍在后台加载数据。这个过程称为懒加载。

如果您访问还未加载的数据，DB 实例将立即从 Amazon S3 下载请求的数据，然后继续在后台加载其余的数据。在此懒加载过程中，您可能会经历延迟和性能影响，直到卷从 Amazon S3 完全充实。

有关懒加载及诸如发起全表扫描如 SELECT 等解决方法的更多信息，请参阅 从 DB 快照恢复。

计划定期维护窗口以扩展大型卷存储

如果您需要扩展存储容量，可以扩展现有 DB 实例的存储。这可以通过 Amazon RDS 控制台、Amazon RDS API 或 AWS CLI 完成。然而，在存储扩展过程中，Amazon EBS 执行存储优化，而这样可能需要很长时间，具体取决于卷的大小。因此，我们建议在计划的维护窗口期间手动安排存储扩展，并尽量减少自动扩展存储操作的频率。

优化大型读取副本的大型 SQL Server 在 Amazon RDS 上的设置

根据主实例的负载，创建 SQL Server 在 Amazon RDS 中的读取副本 可能需要很长时间才能完成。如果您预期会有高负载，我们建议在创建读取副本之前进行手动快照。这一主动措施可以最小化创建读取副本所需的时间。

将单个可用区 DB 实例转换为多个可用区 DB 实例

您可以将使用 io2 Block Express 的 RDS for SQL Server 实例从单个可用区转换为 多个可用区。将单个可用区实例转换为多个可用区实例所需的时间取决于您 RDS DB 实例的主节点的负载。如果您预计会有很高的负载，我们建议在工作负载完成后进行手动快照。这确保在转换为多个可用区之前递增的 DB 快照是最新的，从而最小化转换时间。

结论

通过理解 IOPS 与存储的比例限制以及 IOPS 和吞吐量的扩展方法，您可以适当地为符合性能需求的 io2 Block Express 卷配置 RDS for SQL Server 实例。AWS Nitro 系统 实例提供了更高的最大 IOPS 和吞吐量能力。

对于拥有大型 io2 卷的 RDS for SQL Server 实例，我们建议：

即使在迁移期间，也要保持自动备份启用，以防止 DB 快照超过 20 TiB 的积累。设置备份保留期至少为 7 天，以确保即使备份需要多天才能完成，也有足够的 DB 快照历史记录可用。在进行大型工作负载后进行手动 DB 快照，以最小化自动每日备份期间捕获的增量 DB 快照的大小。对于高负载下的多个可用区配置，每 12 个月进行一次故障切换，以避免在意外故障后出现极大的快照。从 DB 快照恢复后，运行应用程序脚本以加快 充实懒加载 过程，类似于其他卷类型。在计划的维护窗口期间手动执行存储扩展，并尽量减少自动扩展存储操作的频率，因为优化一个 64 TiB 的卷可能需要很长时间。

遵循这些建议，您可以有效地管理和优化使用 EBS io2 Block Express 卷的 RDS for SQL Server 实例的性能、备份和维护。在决定将它们用于生产使用之前，我们强烈建议对在 RDS for SQL Server DB 实例上使用 io2 Block Express 卷的 SQL Server 工作负载进行全面的性能测试和基准测试。欢迎在评论区分享您的反馈。

作者介绍

Sudhir Amin 是亚马逊网络服务的高级解决方案架构师。在纽约工作的他为不同行业的企业客户提供架构指导和技术支持，推动其云采纳。他是斯诺克、拳击和 UFC 等格斗运动的爱好者，热衷于旅行到拥有丰富野生动物保护区的国家，近距离观察世界上最雄伟的动物。

Toby Xu 是 Amazon Web Services RDS 团队的高级产品经理。在加入 AWS 之前，他曾在甲骨文和 Informatica 的解决方案架构团队领导工作。拥有超过 16 年的数据库和中间件技术工作经验，Toby 在该领域拥有丰富的知识，持有软件工程硕士学位。他对云技术充