F5 与 AWS： 云端高级application交付服务

亚马逊网络服务（AWS）已成为最大和最普遍的公共云基础设施即服务（IaaS）提供商。 企业现在可以构建、测试和部署整个应用堆栈，而无需购买或重新配置内部部署基础设施。 生产应用s可以受益于先进的应用交付服务，例如 Web应用防火墙 (WAF)、SSL 加速、基于内容的路由、负载平衡、DDoS 缓解、身份和访问权限管理以及协议敏捷性，这些服务可以使这些关键应用s运行得更快、更智能、更安全。 对于云原生 AWS 部署，F5 解决方案支持将这些应用服务简单轻松地交付到 AWS 云环境。

作为 IaaS 提供商，Amazon Web Services (AWS) 提供足以开发应用s的租用计算基础设施。 无需花费任何资本支出或维护费用，就可以开发和部署完整的应用套件。 除了提供像在现场那样的计算基础设施之外，AWS 还提供应用服务、自动扩展基础设施并在许多位置托管应用s。 由于这些附加功能，AWS 的最佳实践与传统数据中心的最佳实践不同。 为了更好地理解 AWS 与传统数据中心之间的差异，了解 AWS 如何提供其服务非常重要。

为了从 AWS 获得最大收益，让我们来看看其 IaaS 产品的几个重要属性，例如地理分布、计算实例、网络和存储概念。

了解 AWS 始于资源分布方式的物理描述。 在最高级别，AWS 有多个区域，每个区域覆盖一大片地理区域，例如美国东部。 每个地理区域包含多个可用区，之所以如此命名，是因为它们被设计为彼此隔离，不会发生故障。 一个可用区域 (AZ) 中的故障不会级联到区域内的另一个 AZ。 虽然每个 AZ 都是独立的，但区域内的 AZ 通过低延迟网络链路连接。 出于可用性目的，存在跨区域内多个可用区的冗余能力的设计模式。

计算实例开始于一个软件磁盘映像，称为 Amazon 系统映像 (AMI)。 每个 AMI 都是不可变的，这意味着它对于使用它的计算机来说是只读的。 针对 AMI 启动计算实例会在云中创建一个正在运行的虚拟机。 计算实例的虚拟硬件特性可能有所不同，例如实例可用的 CPU 和 RAM 数量。

每个计算实例都存在于虚拟私有云 (VPC) 中，该虚拟私有云大致相当于物理世界中的 LAN。 每个VPC在逻辑上都是分开的。 VPC 可以由多个子网组成，子网之间有隐式路由。 公共子网可从互联网路由，而私有子网仅供内部使用。 要部署完整的应用，需要在 VPC 内部署一个或多个计算实例。当计算实例或负载均衡器具有分配的 DNS 条目时，可以跨 VPC 进行通信。

如上所述，每个 AMI 对于使用它的实例来说都是不可变的。 对于持久存储，AWS 提供了许多解决方案，主要是简单存储服务 (S3) 和弹性块存储 (EBS)。 S3 是一种对象存储服务，可以通过名称存储和访问对象。 该对象的大小范围是从零字节到 5 TB。 事实上，每个 AMI 都隐含地是一个 S3 对象。 对象无法被修改，只能创建和删除，这使得它们非常适合相对静态的内容，例如照片或虚拟机图像。

EBS 提供的存储更类似于传统存储。 连接到 EBS 的计算实例将 EBS 视为传统硬盘。 每次只能有一个正在运行的实例附加到 EBS 卷，因此 EBS 不能用于共享存储。

除了提供关键基础设施组件之外，AWS 还提供支持应用扩展的附加服务。 由于 AWS 可以快速配置基础设施资源，因此亚马逊开发了允许这些资源自动扩展和负载平衡的解决方案。

AWS 提供弹性负载平衡 (ELB) 服务。 最初，ELB 是指在第 4 层运行的简单负载均衡器，它将流量分散到池中的多个健康节点之间。 该池可以跨越多个可用区域，以便在一个可用区域出现故障时自动创建冗余。 虽然此负载均衡器提供了一些基本的网络第 7 层功能，但它主要在第 4 层运行，只是以循环方式将 TCP 流量路由到池中的节点。 健康检查确定哪些节点可用，从而成为流量的候选节点。 AWS 现在将此初始负载均衡器称为经典负载均衡器，以将其与新的application负载均衡器 (ALB) 区分开来。

由于 AWS 具有可用的备用容量，因此它可以提供在池内扩展节点的选项。 AWS CloudWatch 服务监控池中每个节点的性能指标。 当超过预定义的阈值（例如 CPU 利用率在 5 分钟内超过 60%）时，将配置另一个节点。 相反，当超过较低阈值时，节点会被删除。 设计人员可以确定池中的最大和最小节点数以及触发节点实例化或节点删除的阈值。 在负载均衡器后面使用自动缩放可以使节点池根据负载根据需要进行扩展或收缩。

虽然应用s可以处理业务规则和逻辑，但它们通常缺乏大规模生产部署、管理和运营所需的强化。 F5 解决方案通过提供下表详述的高级应用交付服务，使应用s运行得更快、更智能、更安全。

F5 高级application交付服务

应用程序级监控

• 高级应用健康检查（使用多步监视器）
• 多级健康检查（例如检查数据库和应用是否可用）
• 非 HTTP 健康检查（例如 SIP、Microsoft Windows SQL Server 和 FTP）
• 先进的算法可以更好地将流量分配到运行最佳的服务器

全球可用性

• 跨不同云提供商或数据中心的异构组合的application可用性
• 与 BIG-IP 高级监视器集成
• DNSSec 支持

高级应用交付服务使应用s能够在更高水平上执行，同时具有可用性和更安全性。 这些服务可以存在于独立于每个应用的战略控制点。 将服务与应用业务逻辑分离，可以使应用s满足业务需求，而不会给开发团队带来基础设施、管理和性能方面的负担。 战略控制点还允许统一且独立地处理每个应用的治理问题。

通过提供与 AWS 基础设施的云原生集成，F5 使企业能够充分利用其 AWS 部署，为其applications提供更好的性能、更高的可用性和更强的安全性。 在下一部分中，我们将研究 AWS 和 F5 如何协同工作。

当服务器实例从通用映像启动时，更改参数或设置配置（例如主机名和 IP 地址）通常是有意义的。 在客户端机器上，这些参数是通过 DHCP 设置的，但通过 DHCP 设置服务器参数通常会导致问题。 除了网络设置之外，有时特定实例还需要特定的软件包或某些软件配置。

对于 BIG-IP 部署，管理员可能希望自动化每个模块的配置，例如 BIG-IP 本地流量管理器 (LTM) 的虚拟服务器和池配置、BIG-IPapplication安全管理器的特定 WAF 配置，或者 BIG-IP 高级防火墙管理器的防火墙设置。 任何安装服务器实例的人都会面临同样的问题：基础映像需要额外的配置才能正常运行。

AWS 提供两种配置实例的主要方法：创建新的 AMI，或使用 cloud-init 在启动过程中修改服务器。 对于不太可能经常更新的多个实例之间的常见更改，创建新的 AMI 更为合适。 相比之下，cloud-init 更适合影响较少实例且寿命较短的更改。

对于预计会持续较长时间的更改（以及多个实例所共有的更改），一个好的方法是通过从与所需配置类似的 AMI 启动机器来创建新的 AMI。 管理员对正在运行的实例进行必要的更改后，实例将停止并生成新的 AMI 并在 AWS 上注册。 从此 AMI 启动的所有未来实例都将应用更改。 由于这种方法使得更改实际上具有永久性，并且生成新的 AMI 会耗费时间，因此 AMI 中嵌入的更改通常将持续很长时间并可在多个实例中使用。 使用 AMI 的另一个原因是它可以缩短启动时间，因为某些云初始化过程可能非常耗时。

不适合合并到新 AMI 中的必要更改是 cloud-init 的良好候选者，它本质上会在实例启动时启用启动脚本。 使用 cloud-init 允许将简单且特定于实例的更改嵌入到实例中。

cloud-init 的缺点包括必须在启动时运行配置更改（例如包安装），从而导致启动时间更长。 较长的启动时间对自动扩展场景会产生实际影响，延长的启动时间可能会使自动扩展无效。 出于这些原因，需要花费大量时间的更改应该包含在新的 AMI 中，而不是通过 cloud-init 进行更改。

当一个更改可以在多个实例（但不是所有实例）中使用时，管理配置也会很麻烦。 例如，假设在具有特定虚拟服务器配置的自动扩展组中使用特定的 BIG-IP 部署。 单个 AMI 可以为这些机器提供服务，而另一个 AMI 可以为另一个自动缩放组中的其他 BIG-IP 机器提供服务。 为每个自动缩放组使用单个 AMI 可确保在 cloud-init 过程中只需要对每个主机进行特定的更改。 组内的任何共同更改都可以嵌入到 AMI 中。这种方法的缺点是，它要求对所有机器的共同更改都更新 AMI。

应用s通常会同时向多个用户提供某种功能。 随着应用变得越来越成功，它可能会超出运行它的计算机的容量。 一旦应用的需求超出了计算机的能力，就需要评估增加容量的选项。 扩展有三种通用方法：纵向扩展、流水线扩展和横向扩展。

扩大规模是增加容量的最简单方法，因为它仅涉及用更快的计算机替换现有计算机。 通过安装更快的计算机，应用的各个方面以及计算机上的任何其他服务都会变得更快，而无需对应用或基础设施进行任何更改。 扩大规模的缺点是，随着性能的提高，成本往往会呈指数增加，最终导致收益递减。 一旦超过阈值，扩大规模就会变得成本高昂。

流水线是将工作负载分解为连续步骤的结果，类似于装配线。 当不同的计算机可以在每个步骤上独立工作时，总体吞吐量就可以增加。 然而，流水线只能增加吞吐量，并且通常是以延迟为代价的。 换句话说，流水线可以提高整体性能，但会降低单个用户或单个请求的性能。 流水线的另一个缺点是它需要深入了解可分解的工作流程，并要求基础设施与这种理解相匹配。 它将基础设施决策与业务逻辑紧密结合在一起，这与许多组织试图做的事情完全相反。

横向扩展涉及让应用和计算机保持独立，而是选择将请求均匀地分布在服务器池中。 由于应用s通常同时处理多个独立请求，因此请求可以安全地分散到相同的应用服务器池中。 横向扩展具有冗余的额外好处，因为任何池成员的故障都不会导致整个应用的中断。 横向扩展的缺点是它需要应用外部的复杂编排，以确保请求在池中的节点之间保持平衡。

AWS 自动扩展使用横向扩展方法来增加需要的applications的容量。 CloudWatch 服务监控池中的节点。 当节点超过预定义的阈值时，CloudWatch 将根据需要自动启动新节点或关闭池中的节点。 利用 BIG-IP 平台，此过程可以通过以下两种方式之一进行：改变 BIG-IP 实例的数量，或者改变单个 BIG-IP 实例后面的池中的节点数量。 两种方法之间的区别在于扩展的功能：BIG-IP 实例或池。

在第一种情况下，BIG-IP 池位于一对 ELB 设备之间。 第一个 ELB 设备控制实例化和终止 BIG-IP 成员，而第二个 ELB 设备是每个 BIG-IP 实例的服务器池中的唯一条目。 当 BIG-IP 实例提供高级应用交付服务（例如 SSL 终止或充当 Web应用防火墙）时，这种方法很有意义。 第一个 ELB 设备执行负载平衡，同时根据需要扩大或缩小池。

在第二种情况下，后端池成员的数量通过 CloudWatch 增加和减少，但 BIG-IP 实例执行负载平衡。 BIG-IP 实例与 AWS 通信以发现池中添加或删除的节点。 当使用高级负载平衡功能（例如 iRules 脚本语言）或基于 URL 或内容引导请求时，这种方法很有意义。 在这些情况下，单个 BIG-IP 实例足以管理后端池中的服务器负载。

BIG-IP 实例必须至少在两种场景中与 AWS 基础设施交互。 首先，多区域 AWS 部署需要更改 AWS 弹性 IP 后面的 IP 地址。 其次，BIG-IP 实例需要能够查看 AWS CloudWatch 服务添加和删除的池成员，该服务可以在池内扩大或缩小服务器的规模。 与基础设施的每次交互都通过 API 调用进行，并且就像任何其他进行 API 调用的软件一样，BIG-IP 实例必须向 AWS 进行身份验证。 通常，有两种方法可以对 AWS 进行身份验证：通过凭证或 IAM 角色。

最简单的身份验证方法是在 API 调用中包含适当的凭据。 AWS 凭证由一个访问密钥和一个密钥组成，大致对应于用户名和密码。 管理员生成凭证，然后开发人员将其嵌入到应用中。 这使应用可以访问适当的 API 调用。

虽然简单，但将凭证嵌入到应用中却会带来安全风险。 除非开发人员在应用中保护凭据，否则其他人或软件可能会恢复它们并以恶意的方式使用它们。 这种方法还使得如果不改变软件就很难改变凭证。 虽然使用凭证是快速测试的合理方法，但生产解决方案应该使用另一种方法进行身份验证。 这就是为什么 AWS 最佳实践建议不要在应用中使用存储的凭证。

对 API 调用进行身份验证的更安全的方法是使用 IAM 角色。 AWS 身份和访问权限管理(IAM) 允许用户管理对 AWS 基础设施的访问。 任何计算实例（例如 BIG-IP 机器）都可以分配一个授权特定功能集的 IAM 角色。 当实例启动时，IAM 会为该实例生成一组临时凭证。 这些凭证在实例运行时有效，并且仅启用指定的 API 功能。 当配置了 IAM 角色时，BIG-IP 实例不会存储凭证，而是只能访问必要的基础设施 API，从而比基于凭证的身份验证提供更高的安全性。

如前所述，AWS 数据中心存在于地理区域中，每个地理区域都可以存在于一个可用区 (AZ) 中。 区域内的每个可用区都不与其他可用区共享任何内容：没有共享电力、网络或建筑物。 事实上，每个 AZ 在地理上都与区域内的其他 AZ 分隔开。 由于区域之间的分离，AWS 用户可以确信影响一个 AZ 的事件不会影响另一个 AZ。 换句话说，一般来说，一个区域内最多有一个可用区在任何时候都不可用。 这意味着跨两个或多个可用区域部署的任何服务都应该持续可用。

BIG-IP 平台使用 AWS 弹性 IP（一种与计算实例无内在关联的 IP 地址）支持跨 AWS AZ 的高可用性。 相反，IP 地址可以动态转发到正在运行的计算实例的私有 IP 地址。 为了实现多区域高可用性，相同的 BIG-IP 实例和应用服务器分别放置在各自的 AZ 中。 最初，弹性 IP 被分配给其中一个 BIG-IP 实例。 每个客户端都与弹性 IP 建立连接，然后将其转发到其中一个 BIG-IP 实例上的私有 IP 地址。 如果发生故障，另一个 BIG-IP 实例将通过向 AWS 发出 API 调用来承担责任，请求将弹性 IP 地址转发给它。

通过与 ELB 集成，BIG-IP 平台可以提供与 AWS 功能无缝集成的应用服务，例如多个 AZ 和自动扩展的 BIG-IP 节点。

将 ELB 放置在 BIG-IP 实例前面可简化跨多个可用区的部署，因为 ELB 可以无缝平衡到 BIG-IP 实例提供应用服务的每个可用区内的各个应用堆栈的流量。 这种方法简化了跨多个可用区的负载平衡。

当需要 BIG-IP 实例的弹性时，具有自动扩展功能的 ELB 可以自动扩大或缩小 BIG-IP 虚拟设备池，提供应用服务，例如 Web应用防火墙、身份管理或 SSL 终止。 使用 ELB 三明治结构，流量被路由到第一个 ELB，该 ELB 平衡并自动将流量扩展到 BIG-IP 实例池。 为了简化跨 BIG-IP 池的配置，每个 BIG-IP 实例在服务器池中都有一个 ELB 地址。 然后，第二个 ELB 将流量路由到下游服务器池。

ELB 和 BIG-IP 拓扑的各种组合可提供单独使用时无法提供的自动扩展、可用性和应用服务。 通过利用 ELB 和 BIG-IP 平台的优势，架构师可以提供特定部署所需的服务级别。

为了实现可重复和脚本化部署，AWS 提供了云形成模板 (CFT)，可简化部署和持续管理。 为所需的服务或应用架构创建 CFT 后，AWS 可以使用它来快速可靠地配置应用。 CFT 在 DevOps 环境中特别有用，允许团队轻松创建可重复的流程以进行测试和生产部署。

F5 不仅支持使用 CFT 部署 BIG-IP 实例，而且还为典型的 BIG-IP 部署提供了多个参考 CFT 文件。

通过调整参考 CFT 文件中的参数，可以针对不同场景脚本化部署 BIG-IP 解决方案，包括自动扩展 BIG-IP 实例或 BIG-IP 实例后面的后端服务器，以及更复杂的场景。 通过使用 CFT 和 F5 解决方案自动执行 AWS 内的可重复部署，可以快速轻松部署复杂的应用环境。

当然，如果不能充分利用技术，它就毫无用处。 为此，F5 提供了大量文档。 提供有关 BIG-IP 平台的常规文档以及 AWS 中 BIG-IP 实例的具体信息。 对于任何问题，一个很好的起点都是询问 F5 。

文档选项卡提供有关特定 BIG-IP 模块的信息以及有关 AWS 集成的整个部分。 AWS 门户提供了可搜索的界面，其中包含从入门到复杂部署场景的文档、文章、社区和资源。

对于文档未回答的问题， F5 DevCentral 社区随时准备提供答案和帮助。

采用公共云不再只是一时的热潮，而是 IT 领域的持久趋势。 作为全球最大、最全面的公共云服务提供商，亚马逊网络服务使企业无需任何本地设备即可构建、测试和部署应用s。 F5 已将其先进的应用交付服务作为 AWS 生态系统的一部分提供，并对其进行配置，以帮助应用在 AWS 云环境中运行得更快、更智能、更安全。