SAA-CO2考试的纲领要求有效设计可靠且有弹性的AWS架构。 本文将讨论如何设计弹性架构,最佳实践以及需要记住的要点。

1. 设计弹性架构的最佳做法

要创建可靠且具有弹性的AWS Architecture解决方案,应考虑以下做法:

  • 应该选择存储,以确保其弹性和可靠性。
  • 设计应提供较高的容错能力和可用性。
  • 应设计多层解决方案以适合系统需求。
  • 确定设计去耦机制时如何使用AWS服务。

2. 存储

弹性系统意味着在出现停机或灾难的情况下,系统不会丢失任何数据或状态。选择存储解决方案时,应牢记这一点。

2.1 EC2实例存储(EC2 Instance Store)

  • 在运行AWS的EC2计算服务的物理硬盘驱动器上找到实例存储。
  • 实例存储具有临时卷,这意味着当运行它们的实例停止时,该卷上存储的所有实例都会丢失。
  • 并非所有EC2实例都提供实例存储。
  • 由于实例存储位于物理驱动器上,因此磁盘大小/容量是固定的。
  • 实例存储的磁盘大小/容量取决于EC2实例的类型。
  • 磁盘类型还取决于EC2实例的类型。
  • 实例存储仅在应用程序运行时才可靠,因此它仅提供应用程序级别的持久性。
  • 实例存储仅应在应用程序运行时用于存储临时数据,或仅用于在其他地方复制。由于它是短暂的,因此可以快速有效地进行复制。
  • 实例痛也可以用于缓存。

2.2 弹性块存储(Elastic Block Store EBS)

  • EBS一次仅连接到一个EC2实例。
  • EBS是可附加存储,同时支持加密和快照。
  • 有不同类型的EBS解决方案。
  • EBS具有独立的生命周期,因此它不依赖于EC2实例。这意味着,即使停止EC2实例,也会保留EBS卷。
  • 您可以将某些类型的EBS卷配置为每秒更大或更小的读写,因为它支持预配置IOPS。
  • EBS可以连接到多个卷,通过使用RAID 0和条带化的IOPS可以创建更大的卷。
  • EBS是可靠且持久的EC2实例的可附加存储。
  • EBS固态驱动器(SSD)卷类型(适用于随机访问):
    • 通用SSD(gp2)
      • 用例包括开发和测试环境,虚拟桌面,低延迟交互式应用程序和系统启动卷。此卷类型适用于几乎所有工作负载。
      • 卷大小为1GB至16TB
      • 每卷最大IOPS为10,000
      • 每个卷的最大吞吐量为每秒160 MB
      • 性能属性= IOPS
    • 预置的IOPS SSD(io1)
      • 用例包括大型数据库工作负载,需要持续IOPS的业务关键型应用程序,每卷高达160 MB每秒或10,000 IOPS的高性能吞吐量。
      • 卷大小为4GB至16TB
      • 每卷最大IOPS为32,000
      • 每个卷的最大吞吐量为每秒500 MB
      • 性能属性= IOPS
  • EBS硬盘驱动器(HDD)卷类型(适合顺序访问):
    • 吞吐量优化的硬盘(st1)
      • 用例包括:该卷不能用作引导卷;不能用作启动卷。它最适合数据仓库,大数据,日志处理和流工作负载。
      • 卷大小为500GB至16TB
      • 每个卷的最大IOPS为500
      • 每卷最大吞吐量为每秒500 MB
      • 性能属性=每秒MB
    • 冷硬碟(sc1)
      • 使用案例包括:该卷不能用作引导卷,最适合存储不经常访问的大量数据,并且可以用作低成本的存储解决方案。
      • 卷大小为500GB至16TB
      • 每卷最大IOPS为250
      • 每个卷的最大吞吐量为每秒250 MB
      • 性能属性=每秒MB

2.3 弹性文件系统(Elastic File System EFS )

  • EFS是Amazon云存储解决方案。
  • EFS是共享存储解决方案。
  • EFS允许多个EC2实例访问同一EFS卷。
  • EFS卷称为弹性卷,因为容量可以根据需要增加或缩小。
  • EFS卷具有PB级文件系统存储解决方案的能力。
  • EFS卷为:
    • 与Amazon EC2的基于Linux的AMI兼容
    • 支持NFS v4.0协议
    • 支持NFS v4.1(NFSv4)协议
  • EFS不支持Windows
  • 一次只能将一个VPC附加到EFS卷。
  • EFS最适合需要大量数据的工作负载。这是使用分析数据,因为它可以无缝地大规模处理和分析数据。

2.4 亚马逊简单存储服务(Amazon Simple Storage Services S3)

  • Amazon S3是一种可在任何地区使用的解决方案,因此它比仅在特定区域可用的解决方案(例如EBS)更为可取(区域可用性)。
  • Amazon S3可以存储大多数文件类型,包括图像,视频,数据和分析。
  • 这是托管网站的绝佳选择。
  • Amazon S3提供了简单的面向对象的存储,其中所有数据类型均以本机格式存储。
  • Amazon S3被实现为可扩展的分布式系统
    • Amazon S3一致性模型是:
      • 与新对象非常一致-这意味着在首次存储对象时,它会立即显示。
      • 最终一致的更新-更新现有对象时,它可能不会立即被拉入。这可能会导致系统版本问题。
  • Amazon S3具有一些存储类别
    • Amazon S3标准
      • 便宜的上载和下载(访问)。
    • Amazon S3标准不频繁访问(IA)
      • 存储价格便宜,但上传和下载价格更高。
  • Amazon S3服务器端加密(静态数据)
    • SSE-S3-S3主密钥在服务器端加密文件。
    • SSE-KMS-KMS主密钥在服务器端加密文件。
    • SSE-C-客户提供和管理的密钥在服务器端加密文件。
  • Amazon S3服务器端加密(传输中的数据)
    • HTTPS
  • Amazon S3允许对文件进行版本控制,这意味着仍可以访问已更新或删除的文件。
  • Amazon S3设计具有99.999999999%的高耐用性。
  • Amazon S3具有Internet API,因此可以从任何地方访问。
  • Amazon S3具有无限容量;它具有访问控制,并且可以执行多部分上传。

2.4 Amazon Glacier

  • Amazon Glacier是一种存储解决方案,用于存储不经常访问的数据,例如备份,历史数据,档案和保管库(档案的集合)。

  • Amazon Glacier具有三种类型的检索类型:

    • 标准-一种中间选项,其中成本和检索时间取决于存储的数据量。
    • 加急-速度更快,但费用更高,最多可能需要5分钟。
    • 批量-最便宜,最麻烦的选择,因为它可能需要长达12个小时的时间。
    • 对于每种检索类型,都需要在延迟或成本之间做出决定。滞后越少,成本越高。
  • Amazon Glacier可以设置生命周期策略,该策略可以在特定时间段后将数据从S3移至Glacier存储桶。这样可以更轻松地自动存档历史数据。

  • Amazon Glacier的设计具有很高的耐用性,设置为99.999999999。

  • Amazon Glacier也可在所有地区使用(区域可用性)。

了解实例存储和EBS之间的区别很重要。对于EBS,您将需要知道哪种存储容量类型便宜,以及为什么会有价格差异。 您可以在以下链接上找到有关此主题的更多信息。 https://docs.aws.amazon.com/whitepapers/latest/aws-storage-services-overview/welcome.html

https://docs.aws.amazon.com/whitepapers/latest/aws-storage-services-overview/amazon-ec2-instance-storage.html

https://docs.aws.amazon.com/whitepapers/latest/aws-storage-services-overview/amazon-ebs.html

https://docs.aws.amazon.com/whitepapers/latest/aws-storage-services-overview/amazon-efs.html

https://docs.aws.amazon.com/whitepapers/latest/aws-storage-services-overview/amazon-s3.html

https://docs.aws.amazon.com/whitepapers/latest/aws-storage-services-overview/amazon-glacier.html

https://docs.aws.amazon.com/whitepapers/latest/aws-storage-services-overview/amazon-cloudfront.html

3. 容错能力

容错功能应作为正常的操作事件内置到系统中,而不是将其视为异常事件或异常事件。这使得应用程序和系统即使在任何异常事件或故障期间也可以继续运行,以继续向组织或用户提供其服务和价值。 使用AWS服务创建松耦合的系统,您可以确保系统具有较高的容错能力。

通过遵循设计概念和AWS Well-Architected Framework的五个支柱,您可以实现容错弹性系统。 您可以在以下网站链接上找到有关此主题的更多信息。

https://aws.amazon.com/architecture/well-architected/

https://aws.amazon.com/blogs/apn/the-5-pillars-of-the-aws-well-architected-framework/

4. 多层解决方案

只要有可能,最好设计具有多层解决方案的系统。这样可以提高系统的弹性,并提供更高的可用性。如果系统设计有适当的去耦机制,则可以确保一个区域中可能发生的任何停机或故障不会影响另一区域。

CloudFormation是一项AWS服务,它允许创建大型部署,该部署可以由多个S3存储桶,RDS数据库,EC2实例,DynamoDB表和网络组成。 CloudFormation使用JASON模板描述所需的基础架构,然后将模板转换为基础架构。这称为堆栈,是AWS资源的集合,使生成基础架构的多个副本非常容易。 堆栈还使您可以轻松地将所有资源作为一个单元进行更新。 使用Lambda允许完全托管的计算服务,这些服务可以针对定时事件或响应事件运行无状态代码。

您可以在以下网站链接上找到有关此主题的更多信息。

https://docs.aws.amazon.com/cloudformation/

https://docs.aws.amazon.com/lambda/index.html

5. 去耦机制

在设计系统时,始终最好使用AWS服务进行解耦机制。在多层系统中,解耦机制可确保如果一个层发生故障,则它会影响其他任何一个层,因为它们会解耦。这使不受层故障影响的系统部分能够继续工作。 紧密耦合的系统相互之间具有一个或多个依赖性。这意味着,如果其中一项服务离线,则整个系统都会离线。例如,如果您有一个依靠电子邮件服务的Web服务器,或者该Web服务器或电子邮件被关闭或出现故障,那么这两个系统都将无法工作。

如果使用一项AWS服务在Web服务器和电子邮件服务之间创建去耦机制,它将继续收集电子邮件并像往常一样发送。电子邮件将在SQS中排队,直到恢复系统为止。没有电子邮件会丢失。 当需要排队功能的服务(例如日志记录服务)需要使用解耦以实现可伸缩性时,也可以使用AWS Simple Queue Services(SQS)。如果数据库需要处理大量的日志记录请求工作,则它可能会变得超载和备份。它甚至可能会丢弃数据或使系统崩溃。使用解耦机制,可以将队列在SQS中排队,然后定向到提供数据库的其他日志服务。 数据越多,将打开更多的日志记录服务,直到负载减少,然后该服务将减少日志记录服务。就像在杂货店等待付款一样,当一个收银员的排队时间过长时,另一收银员打开,人们的分配更加均匀,直到高峰期结束,多余的收银员可以再次关闭。 诸如AWS Elastic Load Balancing之类的负载均衡器可用于在登录服务器之间平均分配日志记录请求。当有太多请求可能使SQS不堪重负或减慢速度时,此功能很有用。一旦负载减少,该服务可以返回到仅使用SQS服务。 当外部客户端需要通过VPC通过云访问Web服务的信息时,弹性IP地址很有用。在没有弹性IP地址的情况下,如果Web服务中断,客户端将失去连接,并且必须等待与备用服务器一起提议新的IP地址。弹性IP将IP地址与一个服务器ID分离,从而可以使用它和AWS内的多个服务器。客户端通过弹性IP地址与应用程序对话,而不管服务器所在的服务器。 您可以在以下网站链接上找到有关此主题的更多信息。

https://docs.aws.amazon.com/whitepapers/latest/aws-overview-security-processes/amazon-simple-queue-service-amazon-sqs-security.html

https://docs.aws.amazon.com/elasticloadbalancing/

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html

https://docs.aws.amazon.com/route53/

6. 确定弹性架构概述

确定AWS环境的弹性架构设计的最佳方法是牢记以下几点:

  • 将使用AWS托管服务作为首选项。
  • 容错能力和高可用性之间是有区别的。
    • 容错能力-表示服务可以在某些故障或事件下保持增值并运行。通过向最终用户隐藏故障,该系统不会损失任何服务。
    • 高可用性-表示该服务始终可用,并且在发生故障时将进行故障转移。
  • 始终围绕一切最终失败的前提进行设计。
  • 永远不要仅依赖一个可用区。服务应至少能够跨越两个可用区以提供弹性。