F5 LTM 知识点和实验 8-配置和管理高可用性部署

第八章:配置和管理高可用性部署

设备集群（device service clustering）

与许多关键网络和IT基础设施组件一样，BIGIP系统可以部署在高可用性(HA)配置中，以支持持续的应用程序交付，而不会在很长一段时间内中断服务。当前BIG-IP系统的HA功能主要由DSC (Device Service Clustering)特性提供。(ha和DSC这两个术语在整个F5文档中可以互换使用。)提供了几个配置选项，每个选项都有其优点和挑战。

主备：

active/standby是BIG-IP系统中最常见的DSC部署。有时也称为冗余对，这个选项早在BIG-IP版本10之前和v11中DSC可用之前就已经存在了。尽管从那时起底层的功能和术语已经变化，但基本概念是相同的：一个设备处理应用程序流量，另一个是随时待命。在这种情况下，“设备”可以是任何系统，无论是bigip、VIPRION还是bigip虚拟版本(VE)。

active/standby对易于部署和维护，如果两个BIG-IP系统具有相同的容量，那么任何一个系统运行整个应用程序交付工作负载都没有问题。一个缺点是，在任何给定的时间点，至少有50%的设备的总容量未使用。

主主：

active/active对与普遍存在的active/standby对的不同之处在于，它的设计允许两台设备同时主动处理应用流量。应用程序流量通常分为两组，每个设备都在积极地处理其中一组的流量。如果其中一台设备故障，它的流量处理将被另一台设备接收。主/主对在DSC部署中不像主/备对那样常见，可能是因为它需要更严格的容量管理。必须注意确保合并的工作负载永远不会超过任何一个设备的容量，因为在故障转移期间，单个设备临时处理所有流量。

N+1：

在BIG-IP v11中，随着DSC特性的引入，支持高可用性的底层功能发生了变化。DSC允许的不仅仅是配对部署场景。通常在F5文档中称为N+1, DSC允许放置最多8个单个设备组中的BIG-IP系统，用于提供故障转移保护。例如，您可以将应用程序流量划分为七个组，每个组在单独的设备上活动，一个设备处于待命状态，以备出现故障，如图。主/备和主/主对技术上也是N+1部署;它们只是“1+1”。

您可以将应用程序交付流量划分为多达127个不同的流量组（version13），所有流量组都具有故障转移保护!管理大量的设备和流量组可能会带来管理上的挑战，但也有好处，尤其是可以更好地利用容量。有3个主用设备和1个备用设备的设备组只留下25%的未使用容量;7个主动和1个待机留下约12%的未使用容量;而1+1的模式有50%时未使用的。

同步漂移设备组

无论是主/备、主/主还是N+1，这些DSC部署的共同特征是它们都是设备组——更具体地说，是syn-failover设备组，这意味着它们共享公共配置数据，并且在发生故障时可能会相互故障转移。因此，一个BIG-IP系统一次只能属于一个同步故障转移设备组。

同步故障转移设备组中的设备需要相同或同质，即相同的硬件或VE类型和容量，也可以根据您的高可用性需求和业务需求而不同。同构设备组的管理比具有不同容量成员的设备组的管理简单。当涉及到工作负载分离以及流量组的加权和管理时，后者需要更大的尽职调查，特别是当您向组中添加两个以上设备时。

故障切换通信方法介绍

故障转移心跳可以通过两种方法进行通信，即硬连线故障转移和网络故障转移。在VIPRION设备或BIG-IP VE系统上，不支持硬连线故障转移。此外，为了实现硬连线故障转移，BIG-IP设备之间的物理距离必须在50英尺(15米)以内。

心跳线:

心跳故障转移通信可以通过在故障转移端口连接两个BIG-IP系统的特殊线路进行，也可以通过TMM交换机接口进行网络连接

通过硬连线故障转移，电压信号通过一根特殊电缆发送，该电缆在故障转移端口连接两个BIG-IP系统。此选项仅适用于由BIG-IP设备组成的主/备对。硬连线故障转移仅适用于主/备BIG-IP设备对。它不适用于active/active对或VIPRION或BIG-IP VE DSC部署。

网络接口:

网络故障转移发生在同步故障转移设备组中设备之间的网络连接上。心跳包通过网络发送，使用DSC故障转移通信设置中标识的自IP地址。

网络故障切换适用于active/active或包含VIPRION系统、BIG-IP VE系统、vCMP guests或2台以上设备的设备组。

在主/备BIG-IP设备对上，可以将硬连线故障转移与网络故障转移结合起来实现心跳冗余。

故障转移工作原理:

在BIG-IP系统可以相互故障转移之前，同步故障转移设备组中的所有设备必须已经包含大量相同的底层配置数据——相同的虚拟服务器、池、节点、概要文件、监视器、irules等用于定义应用程序交付的方式。

所有设备组成员还必须包含相同的流量处理对象，例如虚拟IP地址、SNAT转换地址和浮动自IP地址，因为BIGIP系统正是使用这些对象来代理客户端和服务器之间的连接。无论您的DSC部署是主/备对、主/主对还是其他N+1个设备组中的任何一个，都是如此。

这些流量处理对象被分组到称为流量组(traffic groups)的容器对象中。有两种类型的流量组-浮动(floating)和非浮动(non-floating)。对于本文的故障转移讨论，只有浮动流量组是相关的，因为它们是受益于故障转移保护的应用程序流量。

无论DSC部署方式(主备、主主或N+1)如何配置，syn-failover设备组中的所有成员(设备)都具有相同的浮动流组，并配置相同的底层流量处理对象，但每个流组一次只能在一个成员上为主用，因此在其他成员上为备用。

理解故障转移“心跳”

设备组成员通过设备间建立的通信通道，以故障切换心跳包的形式共享流组状态信息。(这就是为什么网络故障转移通信方法对于同步故障转移设备组的有效运行如此重要。)如果心跳停止并且在用户指定的超时时间内(默认为3秒)无法恢复，或者如果状态信息表明活动的浮动流组需要故障切换，则备用设备上的该流组将变为活动。在F5文档中，这个过程是根据活动流量组浮动到下一个设备来描述的，因此术语浮动流量组（floating traffic group）。客户端流量现在被定向到流量组新激活的设备上，如果开启镜像能力，通常不会察觉到服务中断。

部署新的高可用性配置步骤

• 准备工作：配置网络地址，ntp，安装相同的系统版本等。
• 配置DSC通信配置：配置通信地址。
• 建立信任关系：信任是通过设备证书的相互交换来建立的。
• 建立设备组建：可以将两个设备放入一个syncfailover设备组中，以实现高可用性。
• 同步配置数据：为了使设备组正常工作，所有设备必须共享相同的底层应用程序交付配置数据，例如虚拟服务器、池、节点等。初始的ConfigSync操作确保所有设备都从一个公平的竞争环境开始。

准备部署新的DSC配置

在部署新的DSC配置之前，必须执某些准备，包括:

• 在每个设备上安装相同的BIG-IP软件版本
• 确保在每个设备上授权和提供相同的模块
• 给每个设备一个唯一的设备名称
• 确保所有设备都安装了有效的设备证书
• 在每台设备上配置网络设置(例如:vlan、自ip、接口)
• 使用NTP服务同步所有设备的系统时钟

您还应该为每个设备创建一个UCS存档，以防需要进行回退。

使用专用的VLAN进行DSC通信

F5建议为DSC使用专用VLAN。为了将DSC网络流量与所有其他流量完全隔离，并避免由网络故障引起的潜在问题，F5建议在每个系统上指定一个接口仅执行故障转移通信，并且在可能的情况下，用电缆直接连接这两个接口以避免网络问题。如果不能使用专用VLAN，则使用任何现有的安全的、非面向客户端的VLAN。所有设备组成员必须使用相同的VLAN进行DSC通信。

了解DSC通信协议：

功能	协议	端口
同步配置数据(ConfigSync)	TCP	4353
镜像(连接、持久化和SSL)	TCP	1029-1155(每一个流量组一个端口)
故障转移的数据包	UDP	1026

注：version 13只支持127个流量组。

配置ConfigSync通信

为了让设备组成员协同工作以提供故障转移保护，它们必须维护相同的底层配置数据。ConfigSync功能用于将一个BIG-IP设备的配置变化同步到设备组中的其他设备。

ConfigSync依赖于设备组成员之间建立的底层通信通道。(该通道在F5文档中通常称为CMI通信通道。)通信通道的端点由您在每个设备组成员上配置的本地自IP地址定义。ConfigSync流量在TCP端口4353发送。

配置镜像通信设置

连接、持久性和SSL镜像是可选的DSC特性，可以帮助最小化故障转移对客户端的影响。

如果您希望使用镜像特性作为应用程序高可用性保护的一部分，则必须配置本地BIG-IP设备用于镜像流量的自IP地址。如果可能，您应该指定一个主IP地址和一个从IP地址，以防主IP地址不可用。而且，如果设备组承载了大量镜像流量，F5建议为DSC通信使用两个专用vlan——一个专门用于镜像流量，另一个用于ConfigSync和故障转移流量。

BIG-IP系统为设备组中的每个流组维护单独的镜像通道。每个镜像通道的端口范围从基础值1028开始，每个浮动流量组递增1。例如，缺省浮动流量组名traffic-group-1使用的TCP端口为1029。由于BIG-IP版本13支持最多127个浮动流量组，因此默认的镜像通道端口范围从TCP 1029到TCP 1155。

配置网络故障转移通信设置

尽管您可以仅使用硬连线故障转移来运行主/备BIG-IP设备对，但网络故障转移提供了许多优点，因此F5建议使用它而不是硬连线故障转移(或者至少是在硬连线故障转移之外)。(对于所有其他DSC部署，无论如何都需要网络故障转移。)例如，BIG-IP设备组成员使用通过DSC网络发送的心跳包来通信它们的可用性、状态和其他对设备组的成功运行起至关重要的信息——特别是在通过监控中继和池等资源来维护HA的情况下。

使用网络故障切换时，设备组内所有设备以每秒10个的速率向其他设备组内设备发送心跳报文。如果设备发送心跳包的时间超过FailoveNetTimeoutSecr指定的值，则认为该设备处于down状态。默认为3秒。如果发生这种情况，故障设备上每个流量组的下一个活动设备将尝试切换到该流量的活动状态。当准备让一个BIG-IP系统加入使用网络故障转移的设备组时，您可以定义用于传输心跳包的主单播故障转移地址和备用单播故障转移地址(对于VIPRION，还可以定义组播地址)。您使用的IP地址取决于设备的类型(尽管它们必须始终是静态的，而不是浮动的，并且属于路由域0)。

网络故障转移通信设置的建议

• 对于单播地址，使用静态(非浮动)自身IP地址(如果没有定义专用DSC VLAN，则为非面向客户端的VLAN)。
• 备用单播地址为本端管理接口的IP地址。

建立设备信任关系

每个独立的BIG-IP系统最初位于其自己的本地信任域Root (/Common/Root)中。信任域是通过一个名为device_trust_group的特殊的仅同步设备组来管理的，该设备组只包括一个成员，即本地设备本身。仅同步设备组类似于同步故障转移设备组，但仅限于同步配置对象。对于device_trust_group，同步的信息仅与管理设备信任有关，包括设备证书和设备标识。

文件名	配置路径	描述
/config/ssl/ssl.crt/dtdi.crt	Device Management > Device Trust > Identity	此设备在信任域中的身份证书
/config/ssl/ssl.key/dtdi.key	无	此设备在信任域中的身份证书
/config/ssl/ssl.crt/dtca.crt	Device Management > Device Trust > Local Domain	信任域的根证书
/config/ssl/ssl.key/dtca.key	无	信任域的根密钥

dtca.crt和dtca.key文件表示设备本地信任域的根证书和密钥，用于为加入该信任域的新设备签署证书。

dtdi.crt和dtdi.key文件是本地设备的身份证书和密钥。dtdi.crt包含本地设备的设备名作为证书的公共名称。

理解设备标识

设备标识是一组信息，它唯一地标识设备信任和设备组中的每个设备，用于身份验证。设备标识由上述证书再加上以下信息组成:

• 设备名称
• 主机名平台
• 序列号平台
• MAC地址
• 证书名称、主题、过期日期和序列号
• 证书签名状态

在主/备用对部署中，信任域通常只包含两个成员。一个N+1同步故障转移设备组最多可以有8个成员，因此信任域也将至少包含8个成员。但是，仅同步（syn-only）设备组最多可以有32个成员，因此单个信任域也可以有32个成员。与在设备组级别相比，这为您在设备信任级别管理设备的方式提供了灵活性。例如，您可以将所有设备置于单个设备信任中，然后使用该信任中的任何成员创建多个设备组(对或N+1)。

提供管理员凭据

您必须为远程系统上分配了管理员角色的帐户提供用户名和密码。这可以是任何管理用户，包括默认的admin用户。但是，不能对根用户帐户使用凭据。

信任组

成功完成添加操作后，本地信任域“Root”现在包含本地设备和远程设备，如图所示。对于device_trust_group，设备也处于“同步”状态。

您可以在任何对等体上向本地信任域添加或删除设备(CA-device)。任何信任域成员都可以查看本地信任域内所有设备的身份信息。但是，在维护、修改或重置信任域成员权限时，必须在本地登录信任域成员。

检查信任域设备组状态

通过查看信任域关联的设备组配置，可以检查信任域的状态。这可以从Configuration实用程序或TMSH中完成。下面的示例是根据图中所示的结果设备信任进行建模的。注意，device_trust_group包含在信任域级别上定义的两个相同的成员，并且这是一个同步故障转移设备组(禁用网络故障转移)，被配置为自动同步(启用自动同步)。

设备信任注意事项

• 通过管理IP地址将远端设备加入本端设备的信任域
• 对端设备具有信任的证书签名权限(可以将其他设备添加到信任中)
• 从属设备没有信任证书签名权限(不能添加其他设备)
• 对于主备设备，需要将远端设备添加为对端对于N+1配置，限制设备信任签名机构(对等体)的数量。

创建同步漂移设备组

在设备之间建立信任后，您可以继续创建同步故障转移设备组，该设备组为通过BIG-IP系统交付的应用程序提供HA保护。您可以根据管理应用程序交付所需的虚拟服务器和地址、池、节点、snat、概要文件、监视器等定义这些应用程序。然后，BIG-IP系统将底层流量处理对象(虚拟IP地址、支持的浮动自IP地址和SNAT转换地址)分组到一个称为流量组的容器对象中，以实现故障转移。

从BIG-IP 11.0版本开始，流量组一直是同步故障转移设备组中的基本故障转移单元。(在v10和以前版本中，故障转移仅发生在设备级别。)在当前的BIG-IP版本中，浮动流量组仍然可以在其活动设备发生故障时进行故障转移，但是如果流量组用于成功交付应用程序所依赖的某些资源低于所需的阈值，则浮动流量组也可以进行故障转移。(请参见本章后面了解HA组监控器。)

到目前为止，我们对流量组的引用仅限于浮动流量组。同步漂移设备组中只有一台设备在主动处理浮动流组的流量;所有其他设备都在为该浮动流量组待命，以防发生故障转移。

虽然在一个同步漂移设备组中最多可以配置127个浮动流组，但缺省情况下只有一个名为traffic-group-1的浮动流组。包含设备组中各系统共享的流量处理对象的IP地址。

还有一个特殊的非浮动流量组，名为traffic-group-local-only，它总是绑定到本地设备，即使本地设备故障，它也不会“浮动”到另一个设备。它包含一个设备组中系统之间不共享的流量处理对象的IP地址，例如非浮动(静态)自IP地址(包括用于DSC通信的IP地址)。

当您定义一个自身IP地址时，它作为浮动或非浮动自IP的指定来源于它所分配的流量组。如果分配给traffic-group-1，则为浮动自IP;如果将它分配给traffic-group-local-only，则它是一个静态的(或非浮动的)

选择网络故障转移

默认情况下，同步故障切换设备组启用网络故障切换。虽然在BIG-IP设备上的主/备部署不需要网络故障转移，网络故障转移提供的不仅仅是心跳信号，但硬连线选项只能提供心跳信号。例如，网络心跳包提供了关于设备组中每个流组的故障转移状态的信息，包括用于确定在处于活动状态的设备发生故障时，哪个设备是下一个发送流组的“最佳”设备的重要标准。

F5建议始终对任何同步故障转移设备组(包括主/备BIG-IP设备对)使用网络故障转移。(您可以在主/备BIG-IP设备对中使用硬连线故障转移来增强网络故障转移。)并且，正如在其他地方提到的，如果可能的话，在每个设备上至少专用一个TMM交换机接口用于网络故障转移，并且，在主/主或主/备对的情况下，直接连接它们。

选择同步类型

创建新设备组时，需要选择同步配置数据的方式。此设置确定组中的设备在响应配置更改时何时以及如何同步其底层配置数据。

• 手动增量
• 同步手动全
• 同步自动增量同步

图:该图展示了两台BIG-IP设备建立信任后的状态。每个设备有一个浮动的和一个非浮动的(local-only)流组，这些流组的内容对设备是唯一的。(参见图15中的AFTER视图。)

创建设备组后的系统状态

设备组创建完成后，系统状态发生变化，如图所示。其中一台设备在traffic-group-1中为主用设备，另一台设备为备用设备。设备组正在等待初始配置同步操作，将traffic-group-1的内容与其他配置数据进行同步。ConfigSync覆盖进程中一个BIG-IP系统的浮动自IP地址。

请记住，浮动自IP地址在同步故障转移设备组中的设备之间共享，并且绑定到流量组，而不是设备。只有该路由组为主的设备才会响应该路由组内所有IP地址(包括浮动IP地址)的arp。

配置完设备组后，就可以同步底层配置数据了，包括traffic-group-1中的故障转移对象。

设备组注意事项

• 一个同步漂移设备组中最多可以有8个设备
• 一个设备只能属于一个同步漂移设备组
• 一个主备设备组只能有一个浮动流组
• 主用/主用和N+1设备组可以有2 ~ 127个浮动流组

同步配置数据

配置同步(ConfigSync)是将支持应用程序交付的底层配置数据传播到设备组中的其他设备的操作，是设备组成功运行的关键。这样的配置数据包括虚拟服务器、虚拟IP地址、池、节点、监视器、概要文件、规则、浮动自IP地址、SNAT转换地址等等。

当您对同步-故障转移设备组的成员进行配置更改时，并且该更改在ConfigSync范围内，如果要成功地进行故障转移，则需要将其推到所有设备组成员。(请参阅本课后面同步哪些配置数据。)例如，在主备配对中，在主用设备上定义了新的虚拟服务器和虚拟池，但在备用设备上没有进行相同的更改，如果主用设备失败，备用设备对新的虚拟服务器一无所知，也不会为其处理流量。

ConfigSync类型

• 手动增量同步：(默认)需要手动同步组成员设备之间的BIG-IP配置，以保证组成员设备之间保持同步。只有那些比目标设备上更新的更改才会同步。
• 手动全同步：与手动增量同步相同，但整个BIG-IP配置数据是同步的。完全同步比增量同步需要更长的时间。
• 自动增量同步：(也称为自动同步)当您对其中任何一个设备进行更改时，BIG-IP系统会自动在设备组成员之间同步配置数据。如果您希望控制何时将配置更改从一个设备推到另一个设备，就像在其中一个设备上测试一组新的配置更改时一样，请不要使用此选项。“自动同步”选项不支持完全同步。

不管选择的同步方法是自动还是手动，对于新设备组或现有组中的新设备的初始(第一个)ConfigSync操作始终是手动全同步。

了解ConfigSync命令对目标设备配置的影响

ConfigSync操作将覆盖目标系统上的配置数据。在完全同步的情况下，将覆盖目标系统上所有适用configsync的配置数据。在增量同步的情况下，只有那些已更改的对象会在目标系统上被覆盖。“覆盖”可以包括添加新对象、更改现有对象或删除已删除的对象

手动ConfigSync操作同步目标设备的运行配置和存储的配置文件。相反，自动ConfigSync操作只修改目标设备上的运行配置。这种行为是经过设计的，以避免同步较大的配置消耗过长ConfigSync持续时间。这时，您必须登录到每个设备组成员，并发出“tmsh save /sys config”命令，将正在运行的配置保存到存储的配置中。

缺省情况下，自动同步功能只修改目标设备的运行配置。(手动同步同时修改运行配置和存储配置。)您可以使用save-on-auto-sync覆盖此行为。

同步哪些配置数据

未同步配置数据示例:

• MGMT IP地址
• 非浮动自self IPs
• 接口，VLAN, VLAN组，中继，路由域，路由协议。
• 许可证
• 系统证书和密钥
• 软件映像、补丁……
• 系统文件(外部监视器…)
• 模块配置信息
• 静态ARP表项
• vCMP hypervisor设置(MGMT网络、中继、容量、VLAN成员)
• MGMT DHCP配置
• 节点和池成员状态(来自监控)
• 设备分组状态
• HA组

尽管池成员状态(启用、禁用、离线)在设备组成员之间同步，但由监视器确定的资源状态却没有同步。相反，设备组中的每个设备独立于其他设备组成员监视该组交付的所有应用程序的运行状况。这意味着池成员可能在一台设备上被标记为不可用(可能是由于网络问题)，但在其他设备上可用。

选择同步选项

• push：将所选设备的配置推到组中
• pull：将最近的配置拉到所选设备

了解最大增量同步大小

增量同步操作比完全同步花费的时间更少，因此从性能角度来看更可取。增量同步受另一个称为最大增量同步大小(KB)的设置的影响，该设置指定用于保存同步到其他设备的配置的缓存大小。默认为1024KB。当选择“手动增量同步”时，如果您所做的更改超出了缓存容量，系统将在下一次ConfigSync操作时执行完全同步。

同步配置数据

第一次同步配置数据

在创建一个新的设备组后，例如在我们的主/备例中，设备为Awaiting Initial Sync，同步内容：

• 浮动自ip
• 默认的root和admin用户帐号(含密码)

从配置工具或TMSH查看ConfigSync状态:

• 从配置实用工具:设备管理»概述从
• TMSH: TMSH show /cm sync-status

如果选中bigip4，将bigip4的配置数据推送到bigip3, bigip4上traffic-group-1的内容将覆盖bigip3上traffic-group-1的内容。结果是bigip3上的浮动自身IP地址被bigip4上的浮动自身IP地址所取代，并且设备组现在共享这个公共的浮动自IP集，如图所示。

在正常运行时同步配置数据

当对某个成员的配置进行了更改，并且设备组配置了自动同步，则更改立即同步到该组。如果设备组配置了手动同步，系统将在Configuration实用工具的左上角或命令行提示符中通过Changes Pending消息通知您。

对于这样的消息，查看ConfigSync状态以确定推荐的操作过程。例如，如果您向bigip4添加了一个池，ConfigSync状态可能类似于配置实用程序的图或TMSH中:

show cm device-group sf_3_4-dg
show cm sync-status

在成功完成ConfigSync操作后，设备将返回到In Sync状态。

show cm device-group sf_3_4-dg
show cm sync-status

探究流组行为

配置流量组的IP地址

如前所述，流量组是用于支持通过BIG-IP系统交付应用程序的相关流量处理对象的容器。有两种类型的流量组:浮动和非浮动(或仅本地)。

每个设备只有一个非浮动流量组，命名为traffic-group-local-only。此流量组中的任何对象都不提供故障转移保护。通常，在traffic-group-local-only中可以找到的唯一对象是静态(非浮动)自IP地址。

一个主备组只能有一个浮动流组，即默认流组traffic-group-1。在配置流量处理对象(例如虚拟IP地址、SNAT转换地址和浮动自IP地址)时，它们将作为故障转移对象与traffic-group-1关联。

所有其他HA部署也有默认的浮动流量组traffic-group-1。它们还支持总共127个浮动流量组(包括traffic-group-1)。

了解流组漂移方式

同步故障转移设备组中的每个流量组都配置了一个称为故障转移方法的属性。此方法指定流量组当前应该处于活动状态的设备，以及在主用设备上触发故障转移时流量组的下一个活动设备。有三种可用的故障转移方法（version15应该只有两个方式）:

• Preferred Device Order 允许您指定用于故障转移的设备的顺序。(在以前的版本中，这个方法被称为HA Order，在v13.0中的一些配置位置仍然使用这个名称。)
• Load Aware 允许您指定每个流量组所代表的负载，系统使用此信息和当前操作条件来确定在触发故障转移时将流量组发送到下一个设备。(此方法被认为是v13.0中首选设备顺序的回退方法。)
• HA Score 使用设备评分来确定流量组现在应该在哪里活动，以及在发生故障转移时应该在哪里浮动。每个设备的评分是根据流量组的关联HA Monitor(以前的HA group)和每个设备上这些HA监控资源的当前可用性来计算的。HA Monitor允许您为池成员、中继链路和/或VIPRION集群成员设置可用性阈值。如果定义的资源在当前设备上的可用性低于阈值，则触发故障切换事件，流组漂移到评分最高的设备。

确定下一个活动设备:每个流量组的下一个主设备在心跳线之间通讯。(这也是为什么不应该单独使用硬连线故障转移的另一个原因，因为电压信号不包含任何这些信息，使得流量组故障转移方法毫无意义。)在主/备或主/主对的情况下，显然只有一个“下一个”设备，即“另一个”设备。但是，在较大的同步故障转移设备组部署中，它可以是任何其他设备组成员。哪一个取决于流量组的故障转移方法，在负载感知和HA评分的情况下，取决于每个设备上的当前条件。

使用HA组监控器

可以将HA Monitor与三种流量组故障转移方法中的任何一种一起使用。它是HA Score方法所必需的，因为来自监视器的分数用于确定活动设备和下一个活动设备的选择。您可以选择使用具有首选设备顺序或负载感知方法的HA监视器。如果你这样做了，它就像一个健康监控器，只是决定设备是向上还是向下。在这两种方法中都不使用来自监视器的分数值。

使用自动Failback特性

您还可以在首选设备顺序方法上配置自动Failback功能，以便在首选设备顺序列表中定义的第一个设备再次可用时，将流量组返回给该设备。注意，这将触发另一个故障转移事件，并可能影响流量处理。

应该选择哪种流量组故障转移方法

• 如果您的设备组中流量组较少，则“首选设备顺序”为一般来说是最好的选择。您可以控制故障转移发生的顺序。
• 如果你想控制流量组在那台设备上，就哪个设备应该为特定的流量组激活而言，将自动故障恢复添加到首选设备顺序。
• 如果有很多流量组，那么将流量可靠地分配到每台设备就变得更加困难。在这些条件下，使用Load Aware(带有一个流量组负载因子)，并让系统设备由哪个设备承载每个流量组。
• 如果您正在使用不同类型的具有不同容量的硬件，则可以为每个设备使用具有HA容量设置的负载感知。或者，您可以使用具有自动故障恢复的首选设备顺序来根据设备的容量手动加载设备。这取决于你要处理多少流量组。
• 如果您在设备上遇到池成员、VIPRION集群成员或中继链路成员振荡问题，则应该考虑使用HA Score。

对于主/备部署，选择哪种方法并不重要，除非您希望基于资源可用性进行控制。对于两台容量相同的设备，选择不带自动Failback的“首选设备顺序”为最优选择。如果两台设备的容量不一致，请使用“优先设备顺序”自动回切到容量较大的设备。

将流量引导到相应的设备

虽然设备组中的每个设备都有该设备组内配置的所有浮动流组的副本，但一个流组在同一时间只能在一台设备上激活。BIG-IP系统作为流量组的主用设备，响应流量组内所有故障切换对象的ARP请求。回复提供了ARP请求到达的接口预先分配的MAC地址，如图所示。

在发生故障转移时，流量组浮动到下一个主用设备(流量组下一个将成为活动设备的设备)。下一个活动设备发出免费ARP (garp)，以便邻居可以用流量组中的故障转移对象的新MAC地址更新它们的ARP缓存，如图所示。gARP公告不局限于虚拟地址所在的vlan。相反，它们被发送到所有配置的vlan。

MAC伪装地址是一个唯一的浮动MAC地址，可以分配给一个浮动流量组。通过将MAC伪装地址分配给流量组，可以间接地将该地址与该组中的所有故障转移对象关联起来。该应答不是用设备预先分配的MAC地址之一来回复ARP请求，而是包含MAC伪装地址，如图所示。使用MAC伪装地址可以最大限度地减少故障转移期间由于交换机对免费arp响应缓慢而导致的错误定向流量。无论哪个设备在流量组中处于活动状态，MAC地址保持不变。

MAC伪装地址可以是通用的，也可以是本地管理的，但是对于每个浮动流量组和BIG-IP设备通信的L2网段必须是唯一的。本地管理的MAC地址很容易构造，只需要第一个字节的倒数第二个位是1。您可以创建自己的—例如traffic-group-1的02:00:00:00:01，02:00:00:00:00:02用于第二个流量组，以此类推。

使用MAC伪装地址不会影响运行状况监控器流量。设备组中的每个BIG-IP系统在执行健康检查时，继续使用自己预先分配的MAC地址。请记住，每个设备独立于其他设备组成员执行所有运行状况监控器测试(针对所有流量组，主或备用)。因此，使用通用MAC伪装地址进行此类测试是不可能的。

了解故障转移管理器和触发器

在同步故障转移设备组中，有几个事件可以触发故障转移事件:

• 故障转移心跳丢失
• 由系统故障安全特性检测到的主要HA状态特性丢失，例如BIG-IP系统进程(守护进程)
• HA监视器资源损失低于定义的阈值
• 自动故障恢复(请参阅本章前面的研究流量组行为)

由于丢失故障转移心跳而导致的故障转移

当配置网络故障转移(建议所有同步故障转移设备组部署)时，设备组成员会传输包含有关流量组的重要信息的故障转移包——当前活动的设备是什么、下一步应该去哪里、上次移动之前在哪里以及为什么移动。每个BIG-IP系统上的SOD监视此流量，以确定是否需要故障转移，如图29所示。

如果同时配置了网络故障转移和硬连线故障转移，那么SOD将使用所有可用信息来确定设备是否发生故障。如果有一个以上的浮动流量组或两个以上的设备，则硬连线故障转移电缆上的信号完全被忽略。它仅用于主/备BIG-IP设备对场景。正常情况下，对于同一个浮动流组traffic-group-1，一台设备为主用，另一台设备为备用。

备用设备一直保持备用状态，直到它发现主用设备不再可用为止。如果只配置了硬连接故障转移，则拔掉电缆会导致这种情况发生，从而导致两个系统对相同的流量都处于活动状态。(不好!)但是，如果还配置了网络故障转移，则网络故障转移将继续为主用设备提供状态，备用设备仍然是备用设备。

如果同时配置了硬连线和网络故障转移，并且网络故障转移通道消失，备用设备将保持备用状态，因为它仍然可以看到硬连线故障转移电缆信号。

在设备组中的任何设备上都可以通过TCPDUMP查看网络故障切换心跳报文。例如:

tcpdump -ni internal udp and port 1026

由于守护进程心跳故障而导致的故障转移(系统故障安全)

系统故障安全特性为BIGIP系统的一些关键进程(如mcpd、tmm、sod等)提供了心跳和心跳监控功能。如果其中一个进程发生了严重的故障，则可能需要进行故障转移。因此，每个进程都维护自己的内部心跳信号，以指示它们的健康状况(或不健康状况)。

BIG-IP系统维护了一个关于这些重要进程的内部表(称为HA表)，其中包括在某些故障操作(如重新启动、重新启动-all或重新启动)发生之前，进程心跳未被检测到的时间长度。Overdog监视HA表，当它看到需要执行其中一个心跳故障操作时，它就会执行。该心跳故障操作可能会导致实际的故障转移。(当然，重启会导致故障转移，但重启单个守护进程可能不会。)

show sys ha-status all-properties

界面：System>>High Availability :Fail-safe : System

由于HA组监视活动而发生故障转移

HA Score流量组故障转移方法依赖于一个关联的HA组监控器来做两件事:

• 在流量组当前处于活动状态的设备上评估流量组的运行状况
• 为组中的其他设备分配HA评分，以确定哪个设备是下一个活动设备。

HA评分标准表示为当前活动设备可用的池、中继和/或VIPRION集群的最小数量，以便流量组保持当前活动设备的状态。如果当前设备上的资源水平低于定义的阈值，流量组将迅速故障转移到下一个主用设备。

HA组监控器需要用于HA Score流量组故障转移方法，但也可以用于首选设备顺序或负载感知。但是，根据故障转移方法的不同，其功能也有所不同。

当与首选设备顺序和负载敏感的故障转移方法一起使用时，HA组监控器确定设备被简单地视为up或down的标准。

当与HA Score故障转移方法一起使用时，监控器用于计算一个分数，然后用于确定哪个设备应该为该流量组激活，以及如果主用设备故障或主用设备的资源可用性低于HA组监控器的阈值，哪个设备应该为该流量组下一个激活。

使用镜像实现有状态故障转移

缺省情况下，流组故障切换为无状态状态。换句话说，当前流量处理的信息不会被转移到下一个主用设备，包括:

• 当前会话
• 与维护会话连续性相关的持久性记录
• 用于开放、安全连接的SSL握手信息

故障转移发生得如此之快，以至于对于使用短时间连接的应用程序(如HTTP)，最终用户甚至可能没有注意到该事件。但是对于长时间存在的连接或需要持久性的会话(例如电子商务事务)，对于最终用户来说，连续性的损失可能非常明显(并且令人恼火)，这要求他们重新启动在故障转移是有状态的情况下可能继续进行的进程。

镜像特性通过允许连接、持久性和SSL信息从流量组的活动设备发送到下一个活动设备，将默认的无状态故障转移行为更改为有状态。

流量管理微内核(Traffic Management Microkernel, TMM)管理状态镜像机制，每个数据包或流状态更新时，连接和持久化数据自动发送到流量组的下一个主用设备。下一个活动设备使用此数据相应地更新其连接表和持久记录。在发生故障转移时，下一个活动设备已经拥有维护所选现有连接和会话状态所需的关键信息。

注意，设备组为支持的每个流组维护一个独立的镜像通道。报文从1029 ~ 1155端口上定义的主备镜像IP地址发送。缺省的浮动流量组traffic-group-1使用的端口为1029。每创建一个新的流组，镜像端口通道号加1。

使用连接镜像

启用连接镜像会导致处理开销，只有在故障转移会对应用程序用户造成严重中断时才应该使用。例如，长连接(如FTP和Telnet)是镜像的良好候选，而短连接(如HTTP和UDP)则不是。除了性能开销之外，镜像HTTP和UDP连接通常是不必要的，因为这些协议允许单个请求失败而不会丢失整个会话。

由于镜像连接涉及到很高的开销，F5建议您只对长时间的连接(如FTP和Telnet)使用此功能，而不要对短时间的连接(如HTTP和UDP)使用此功能。

使用持久性镜像

持久性镜像是用于在BIG-IP系统上的记录中存储持久性数据的所有持久性类型的可用配置设置，例如源地址关联目标地址、主机和SIP持久性。对于cookie持久性不是必需的，因为没有为该方法创建持久性记录。(持久性数据存储在cookie中。)虽然持久性镜像在默认情况下是禁用的，但在大多数情况下应该启用它。持久性镜像确保跨故障转移事件保持会话连续性，允许后续连接持久到故障转移前的相同池成员。

除了cookie持久性，一般建议对所有持久性类型使用持久性镜像。因为持久性数据是在cookie中维护的，而不是在BIG-IP系统的持久性记录中。

使用SSL镜像

您可以配置BIG-IP系统，将在BIG-IP系统上终止的SSL连接镜像到对等同步故障转移设备组成员。当您在BIG-IP系统上启用SSL镜像(见下文)并在具有Client SSL配置文件的虚拟服务器上配置连接镜像时，BIG-IP系统还将特定于SSL的数据镜像到适当的设备组成员，从而在发生故障转移时保留SSL连接。

SSL镜像功能在默认情况下是禁用的，并且只能在默认情况下使用TMSH从命令行启用:

modify sys db statemirror.secure value enable
show ltm profile client-ssl <profile_name>

从13版本开始，ssl镜像支持关联了http profile或者 server SSL profile的vs上。不支持关联了UDP或者其他7层特性的vs上。

实验

配置主备组

1、在两个台设备上，创建一个UCS，命名为trainX_pre_ha。

2、恢复到default.ucs上。

3、查看用于配置同步的ip配置为non-floating self IP（172.16.11.2）

路径： Device Management >> Devices >> f5-a.xuexi.com(self) >> ConfigSync

tmsh：

 list cm device F5-a.xuexi.com configsync-ip

4、配置172.16.11.2和192.168.199.233做故障转移的单播地址。

路径：Failover Network

tmsh：

list cm device F5-a.xuexi.com unicast-address

配置和测试会话同步

1、使用ssh连接ssh_vs。

2、使用命令查看会话统计

show sys connection

配置持久性同步

1、在设备上配置一个持久化配置

• Name：configltm_src_persist
• Persistence Type：Source Address Affinity
• Parent Profile：Source_addr
• Timeout：30 seconds
• Prefix length：IPv4 24