F5 iApps：推动应用交付突破网络边界
简介
如今，企业要求网络具备更高水平的应用感知和管理能力。数据中心旨在交付应用和服务，但仍被作为大型网络进行管理，其中各个网络组件则被视为彼此隔离的单点设备。例如，传统路由器的管理方式仿佛其唯一作用就是独立路由IP流量。然而，应用能否按预期运行完全依赖该路由器。目前，大多数企业将组织网络和数据中心网络视为一系列独立对象，分别由不同团队管理，却缺乏全局视角，无法了解这些组件彼此之间及其与其他基础设施之间的关系，也无法掌握所有组件如何协同工作，向用户交付应用。
将整个基础设施作为独立组件分别管理会阻碍IT工作，因为这需要不同团队协调过多的环节，才能充分管理和控制向用户及数据中心内其他服务交付应用。因此，IT部门通常需要使用复杂的电子表格，详细记录各组件在网络层面的作用，却没有信息说明这些组件与应用之间的关联。由于不了解基础设施组件如何协同交付应用，这种复杂且彼此割裂的基础设施视图给数据中心管理、故障排除以及自助式配置等敏捷模式带来了挑战。
转向以应用为中心
尽管这种过时的数据中心观念仍在影响许多组织的管理方式，但应用正在不断演进，并逐渐成为核心。这一转变促使企业IT部门开始以应用为中心进行管理，而不是从设备和对象入手，再将各个组件拼接起来以交付应用。推动这一转变的主要因素是云计算和软件即服务（SaaS）的普及。在这种模式下，应用成为最重要的组成部分，而基础设施则日趋商品化。
然而，如今的应用管理远比五年前复杂。在后端，应用现在可以部署在任何位置，无论是在企业数据中心内部还是外部。管理员可以跨不同的云提供商部署应用，将其作为SaaS应用运行，甚至将应用分布在不同大洲的数据中心。随着虚拟化的发展，数据中心正逐渐摆脱服务器与应用一一对应的模式；资源不断缩减，服务却持续增长。应用本身也在转向数据更加丰富的模式，并依赖API实现应用间通信，从而提高了对系统和网络资源的要求。然而，尽管企业IT迅速走向消费化，应用成为核心，底层基础设施却未能相应调整。管理应用交付不仅涉及网络组件，还需要结合上下文，了解用户如何实时与应用交互。
iApps：应用时代
F5 iApps是BIG-IP系统中一套功能强大的新功能，可帮助企业以更合理的方式构建数据中心内的应用交付架构。iApps采用以应用为中心的整体方法，用于管理和交付数据中心内部、外部及更广泛环境中的应用。iApps技术在BIG-IP系统内提供了一个框架，可呈现支持业务的应用服务上下文视图和高级统计信息。借助该技术，应用、安全、网络、系统和运维人员可以统一并简化应用交付服务，同时实现更有效的控制。
iApps对交付应用所需的众多独立组件进行抽象，并将这些资源整合到与特定应用关联的模板中，从而减少管理员单独管理网络中各个组件的工作。
大多数企业IT部门会将网络各部分的管理职责分配给不同团队：网络团队负责管理IP地址、路由和DNS；服务器团队负责管理物理和虚拟服务器、操作系统构建及病毒防护；应用和安全团队负责管理API交互、应用标准及访问权限。因此，IT部门通常没有任何一个团队能够回答这个问题：“贵组织需要哪些组件来提供电子邮件服务？每个组件又是如何配置的？”这是因为其中涉及的环节太多，且彼此缺乏协调。
iApps通过以应用为中心的视角管理所有相关内容，改变了这一局面。借助iApps，可以将节点、应用监视器和池等应用交付服务组件整合在一起，并将其作为应用工作流的一部分进行管理。通过自动执行关键管理任务，应用和网络管理员可以轻松定义成功交付应用所需的基础设施组件。
除了配置和管理应用交付服务外，iApps还可以定义自动化任务，例如部署更多应用交付资源。iApps依托BIG-IP系统的多个不同组件来管理应用交付的各个环节，包括通过F5的iRules引擎为AAA安全基础设施应用负载均衡规则，以及向F5面向客户的支持门户iHealth提供应用诊断和可见性数据。
借助iApps，可将所有应用交付服务组件整合在一起，并将其视为应用的扩展。例如，新的SharePoint应用需要特定的运行状况监控器，用于检查SharePoint Web前端、搜索和数据库组件的状态。传统上，这些组件需要逐一分配和管理，容易出错，并会大幅延长部署时间。借助适用于SharePoint的iApp，所有这些部分都会成为应用本身的组件，并可在一个集中位置进行部署和管理。
统一的iApps组件
从内部架构来看，iApps由多个独立组件构成，每个组件负责管理应用交付基础设施的一部分。这些组件相互协同，共同构成统一的BIG-IP应用交付控制器（ADC）。
iApps应用服务
iApps通过创建iApps Application Services，将应用组件整合在一起进行交付。这些服务可在交付过程中应用于应用的任何部分。例如，最初可将面向SharePoint的iApps Application Service与BIG-IP Local Traffic Manager (LTM)策略及一组SSL相关iRules关联。之后，管理员只需选中一个iApps复选框，即可将BIG-IP Access Policy Manager (APM)访问策略与同一个面向SharePoint的iApps Application Service关联，然后在整个网络中重新分发该服务。iApps Application Services可提供对整个应用交付基础设施的洞察，并在一个统一系统中将应用与网络依赖关系关联起来，从而降低运营成本。
正如面向对象编程改变了应用的编写方式，iApps Application Services 也改变了传统应用交付服务部署在应用“前端”的模式。iApps Application Services 可在交付过程中的任意时间应用于应用交付链的任何环节，使组织能够根据具体情境，选择应用的哪些部分在何时受哪些服务组件影响。iApps 策略不仅限于构建负载均衡配置。作为整个 BIG-IP 统一 ADC 平台的一部分，iApps 策略还可包含高级 BIG-IP 系统模块和功能的配置设置，例如使用 BIG-IP APM 为应用分配用户访问策略。
iApps模板
使用模板是iApps极具吸引力的优势之一。虽然BIG-IP LTM从版本10开始提供应用模板，但这些模板仅限于新应用的初始部署阶段。此外，后续无法使用这些模板修改运行配置。
iApps模板灵活易用，可用于部署和管理应用服务。它们可作为单一界面，用于在所有BIG-IP系统模块中构建、管理和监控应用。管理员使用现有模板构建新的iApps配置后，生成的配置将应用于设备服务集群中的所有BIG-IP设备，并为F5 Analytics提供必要信息。
除了配置和管理BIG-IP系统外，iApps Templates还支持IT部门内的多个团队定义交付和管理应用所需的全部设置。由不同职能架构师组成的团队可以定义应用参数，包括由网络团队提供IP地址信息、应用团队配置缓存和压缩策略，以及安全团队定义面向用户和地区的访问策略，并在iApps Template中制定部署流程。随后，他们可以将该模板交给IT运维团队，以便在测试或生产环境中的BIG-IP设备上部署。iApps Templates创建后，可由相应团队修改，并可随着业务和IT需求的变化在整个组织内重复使用。
iApps的另一项主要优势是，消除了在ADC及整个基础设施中部署新应用时对“主题专家”的依赖。应用负责人无需再考虑部署单独的BIG-IP LTM设备来保障可用性，也无需部署BIG-IP ASM设备来保障安全性。借助iApps，应用负责人只需将这些服务添加到iApps应用配置中，BIG-IP平台便会部署相应服务及其所有相关组件。应用负责人通常需要投入大量时间来配置通过BIG-IP系统设备交付的应用。借助iApps Templates，这些前期工作可在整个组织内重复使用。可自定义的iApps Templates有助于组织节省运营支出：只需调整一次应用策略并完成一次测试，之后即可导出配置，并与其他BIG-IP设备及其他IT组织共享，从而重复利用这些工作成果。
iApps生态系统
iApps配置策略旨在支持在BIG-IP系统之间以及用户之间移植。iApps Templates可按应用导出，并在整个应用网络中重复使用。此外，还可将其导出并通过F5社区网站DevCentral上的iApps Ecosystem进行共享。BIG-IP系统管理员和开发人员可在该平台上为其他应用创建、修改和共享自己的iApps Templates，或调整现有iApps Templates。
F5定期通过DevCentral上的iApps Ecosystem发布适用于新应用的官方iApps Templates，充分利用Microsoft、IBM和Oracle等F5合作伙伴针对新应用开展的工程工作，以及专为金融、政府和医疗保健等垂直市场设计的应用模板。
F5 Analytics
iApps策略主要用于配置交付应用所需的流量管理组件。不过，BIG-IP平台还提供应用监控工具和实时应用性能统计信息。此外，它还提供整个应用、虚拟服务器、池和节点的诊断与故障排除信息，例如应用响应时间、网络延迟和连接统计信息。
与传统监控工具不同，F5 Analytics在应用层收集性能数据，并将这些信息与应用本身关联，而不是与各个基础设施组件关联。应用负责人可以监控从应用到应用服务器，再到网络的整个链路性能。这样，组织便可根据应用响应、网络状况和用户上下文，准确地实时监控应用的运行表现。
F5 Analytics利用BIG-IP系统中的统计数据和日志数据，并将这些数据格式化为JSON对象，然后导出，供F5 BIG-IQ等数据使用方或Splunk等应用使用。
借助F5 Analytics，可以配置要导出的多类数据。对于Splunk等数据使用方，还可以配置接收数据的网络端点。
设备服务集群
数据中心硬件设备通常以冗余对的形式运行，采用主动/备用模式（一个系统承担全部任务，另一个系统等待前者离线后再接管这些任务）或主动/主动模式（两个系统共同分担设备间的工作负载）。对于任何任务关键型硬件部署，这两种冗余配置都是常用的推荐做法，但存在一个重大设计缺陷：这种冗余架构以整个设备发生故障为前提。
更合理的方法是根据设备在应用交付过程中任一时刻执行的操作来构建容错架构，而不是依据整个设备处于在线还是停机状态。BIG-IP设备支持在应用层构建可扩展的容错架构，为设备之间的应用配置提供故障转移保护。BIG-IP设备服务集群支持两种不同的配置选项：仅同步（Sync-Only）模式和同步故障转移（Sync-Failover）模式。
仅同步
BIG-IP设备服务集群的Sync-Only模式允许多个BIG-IP硬件和软件设备动态共享设备间特定于应用的交付配置和模板。这样，每当发生变化时，管理员无需手动更新完整的设备配置。由于BIG-IP应用策略与硬件配置相互独立，管理员可以在设备之间同步应用和网络信息，而无需复制整个BIG-IP配置文件。因此，IT团队可以运行配置各不相同的BIG-IP设备，同时仍能在这些设备之间同步特定应用的配置和策略。例如，可以在BIG-IP设备之间同步BIG-IP Application Security Manager（ASM）策略，而不会影响各设备上的其他应用策略，也无需安全团队在每台设备上手动安装各项BIG-IP ASM策略。
同步故障转移
除了在设备之间同步之外，应用配置还可以在设备之间故障转移当前正在处理的实时应用流量，将主动/主动概念扩展到应用层。BIG-IP设备服务集群的同步故障转移模式将主动/主动的1:1模式扩展为N:1，可根据资源限制和可用性，使用所需数量的活动设备分担应用负载。这与RAID 5条带化的理念非常相似，可根据需求和冗余要求确定磁盘数量。
随着应用交付资源需求增加，管理员可以向设备服务集群添加处于活动状态的BIG-IP设备。该集群会分担一部分整体应用交付负载，无需为防范新设备离线而额外添加第二台专用备用设备。在BIG-IP设备服务集群中，每台新加入的设备都能提供一定的冗余能力：如果某台设备离线，其他设备可承接额外的应用负载。加入设备服务集群的BIG-IP设备越多，就越能高效地在所有可用设备之间分配应用负载。
战略控制点
iApps的两项关键原则是可见性和控制力。iApps在整个基础设施中提供前所未有的可见性和控制力；但其实现程度取决于部署位置是否处于战略控制点。在该位置，用户、应用和数据之间的协调中介层可将所有应用交付逻辑动态应用于全部双向应用流量。无论应用和数据当前位于何处，该层都能为其提供一致的接口和一组服务。通过智能理解上下文（谁出于何种原因从何处访问哪些内容），该层可确定用户、应用和数据之间的适当连接。此外，该层还能深入理解上下文，将当前资源需求告知底层应用和数据元素，并指示基础设施实时调整，以优化应用和数据访问。
这种应用信息的战略性流动将成为iApps配置的一部分。使用iApps Template进行初始配置时，以理想架构中的应用交付方式为依据；在整个交付生命周期中，通过iApps Templates和BIG-IP设备服务集群管理应用，从而明确交付内容和位置。F5 Analytics则说明原因，并将相关信息反馈给IT部门进行分析。iApps位于关键控制点，只有这些位置才能实现如此精细且广泛的应用交付管理。
结论
随着组织转向更加模块化的云和SaaS模式，应用管理已变得比基础设施建设更为重要。转向更敏捷模式所带来的许多优势与基础设施管理无关；然而，由于应用仍与基础设施紧密关联，在云和SaaS环境中管理应用部署、性能和可用性往往并不容易。iApps将应用控制、可见性和管理与交付这些应用和服务所需的基础设施相结合，使其覆盖范围超越数据中心。
iApps支持将网络架构从由孤立组件构成的静态资源，转变为与应用或服务直接关联的统一、灵活且具有韧性的资源池。通过这一转变，可以在应用层快速完成网络部署、集成和管理，并获得可见性。iApps通过使网络适配应用，实现对整个应用交付基础设施的全面控制。由此带来的快速部署和单点管理能力有助于降低运营成本。借助F5 iApps，组织可以在关键控制点创建通用且高度可复用的安全、加速和可用性服务目录，从而显著提升F5 BIG-IP设备的组织敏捷性和效率。
发布于2017年12月14日