YuShuoxin的小破网站

来啦~老弟/老妹儿~~

通过Lambda+CloudWatch实现AWS中SDWAN instance(vAER)双机热备+路由自动切换

技术博客

通过Lambda+CloudWatch实现AWS中SDWAN instance(vAER)双机热备+路由自动切换

By YuShuoxin 0

1. 背景

在AWS中使用Axesdn的NAAS (Network As A Service)组网的场景中，Axesdn会通过启动实例的方式，在您的VPC内部署 Virtual AXESDN Edge Router (vAER)，作为接入Axesdn就近POP点的边缘路由器。

在设计网络架构的时候，我们需要考虑尽可能的避免单点故障，已实现高可用/冗余性（HA）。基于这点考虑，有人会考虑部署两个SDWAN实例，以实现双机热备，如下图拓扑所示。

基于这点需求，在一个VPC内的部署两个vAER做冗余，对于SDWAN配置的线路部分来说，是可以实现的，也是常用的做法。这里比较难办的一个地方在于，VPC内的路由表，针对一个目的网段（Destination）只能配置一个网关（Target）。

以上图为例，宁夏的VPC中需要配置路由：目的网段为10.0.0.0/16的网关为vAER-A，或者vAER-B，只能任选其一。假设选择vAER-A，如果vAER-A的实例出现了问题，只能手动修改路由表，将其网关修改为vAER-B。

这样做当然可以，但这不是自动切换，不够自动化，理论上会增加RTO，也会增加运维成本。

我们需要一个不需要人为干预、可以自动切换的解决方案。

2. 解决思路

在这里我们尝试提供一套serverless的解决方案，通过简单的配置，即可实现同一VPC下，两个vAER的双机热备+路由自动切换。

这里主要用到AWS的两个服务 — CloudWatch和Lambda：

  • CloudWatch Events负责检测两个VAER实例的状态，如果检测到异常，就触发Lambda；
  • Lambda则负责运行修改路由的脚本，实现自动的切换。

需要操作的步骤大致如下：

  1. 获取脚本所需的region、vpcID、实例的ENI等参数信息；
  2. 配置lambda，包括：配置Role Policy、配置代码、配置环境变量、配置Test Event等；
  3. 配置CloudWatch Events；

3. 配置步骤

下述步骤，默认您已经完成了vAER-A和vAER-B的启动和相关配置，包括但不限于：

  • 两个vAER都已启动，并确认在同一VPC中；
  • 已经为两个vAER绑定了各自的弹性公网IP(EIP)；
  • 已经为vAER配置了合适的安全组；
  • vAER经过AXESDN技术支持确认，已配置完毕，且可用；
  • VPC已配置相关路由表，将网关设置为两个vAER中的其中一个；
  • 到对端的内网已验证可以ping通。

请注意：

  • 这里建议两个vAER启动在同一VPC下的不同可用区(Available Zone)中，以避免某AZ出现故障影响vAER可用性；
  • 该文档中的截图，都是以英文界面截取的，如您使用的是中文版，可以点击AWS管理页面左下角进行语言切换，或参考截图中对应位置进行操作。

3.1 获取必要的参数信息

因为我们需要告诉lambda脚本，它需要检测和倒换的vAER-A和vAER-B的ENI，因此，我们需要收集如下参数：

  • 两个实例所在的区域(region)，记录为 region
  • 两个实例所在的VPC的vpcID，记录为 vpcid
  • 两个实例各自的ENI，记录为 host1eni & host2eni

下面我们逐一获取。

注：上述参数实际上都可以通过AWS的CLI命令行获取，这里为了涵盖绝大多数用户，仅介绍通过GUI管理页面获取的方式。想使用CLI方式的用户，请参考AWS官方说明按需使用。

3.1.1 获取区域(region)信息

进入需要配置自动路由倒换的vAER的EC2管理页面，

在管理页面的右上角，点击下图红框处即可看到vAER所在的region信息

这里记录为

region = us-west-1

3.1.2 获取VPCID

在EC2管理页面中，选中vAER-A，点击Network，查看VPC ID

这里记录为

vpcid = vpc-0bf5741eb0ef56a41

注：通过vAER-B应该得到相同的VPCID，如果不是，请检查配置。

3.1.3 获取两个vAER的ENI

还是在EC2管理页面中，选中vAER-A，点击Network，页面往下翻，可以看到Network interfaces一项，里面可以看到“interface ID”

这里记录为
host1eni = eni-071b4d6cbf57de651

对vAER-B做相同操作，获取vAER-B的ENI，记录为

host2eni = eni-0847da0f62b486046

3.1.4 小结

通过本节的操作，我们获取了必要的参数信息，汇总如下

region = us-west-1
vpcid = vpc-0bf5741eb0ef56a41
host1eni = eni-071b4d6cbf57de651
host2eni = eni-0847da0f62b486046

3.2 配置Lambda

3.2.1 创建lambda

AWS管理页面选择Lambda服务并进入

点击Create function

选择Author from scratch;

Function name就是该lambda程序的名字，可按需填写，原则就是清晰易识别，我这里填写 AxesdnRouterTableAutoFailoverForSDWAN-vAER；

Runtime选择最新的Python，我这里是Python 3.9；

Change default execution role选择默认的Create a new role with basic Lambda permissions；

Advanced settings保持默认不动即可。

然后点击最下面的“Create function”

稍等片刻，即可看到页面最上方绿色的创建成功的提示，如下图。

3.2.2 配置Role Policy

因为该lambda脚本涉及到修改路由等操作，所以我们需要赋予该lambda最小但是足够运行的权限，以实现路由切换。

我们在这里先创建一个Role Policy。

AWS管理页面选择IAM服务，点击进入。

点击Policies中的Create Policy

这里我们点击JSON直接编辑JSON文件

贴入如下代码，并点击Next:Tags

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeTags",
                "ec2:DescribeVpcs",
                "ec2:DescribeRouteTables",
                "ec2:CreateRoute",
                "ec2:DeleteRoute",
                "ec2:ReplaceRoute"
            ],
            "Resource": "*"
        }
    ]
}

这页Add tags (Optional)我们跳过，直接点击“Next:Review”即可

Name这里填入给这条policy起的名字，最好还是满足清晰易识别的原则，我这里填入 Policy-forLambda-Axesdn-ChangeRouteTableAuto；

Description可以填入一些必要的信息，以方便以后整理和回忆，我这里填入：

For lambda AxesdnRouterTableAutoFailoverForSDWAN-vAER to change route table automatically. Please do NOT delete it.

在点击Create policy完成创建之前，我们也可以点击Summary中的Service查看目前这条policy都包含了哪些内容，当然，这步不是必需的。

可以看到涉及到改动的操作，是创建、删除、替换路由；其他都是describe的操作。

点击Back即可返回之前的页面。

然后，我们点击页面最下面的“ Create policy ”即可完成该policy的创建了。

此时，在policy中，我们就可以看到刚刚创建的policy条目了。

下面，我们需要把新增的这条policy “Policy-forLambda-Axesdn-ChangeRouteTableAuto”，attach到当前lambda的role中。操作方法如下。

进入我们刚刚创建的Lambda “AxesdnRouterTableAutoFailoverForSDWAN-vAER”，点击Configuration->Permission->Execution role下面的Role name

此时，浏览器会在新窗口中打开这条IAM role，可以看到当前的role只有lambda写入log的权限，并不足以完成修改路由的操作。

下面我们点击Permissions中的“Attach policies”

勾选Filter policies中的“Customer managed”

然后就能看到我们刚刚创建的这条policy “Policy-forLambda-Axesdn-ChangeRouteTableAuto” 了，选中它，点击“Attach policy”。

此时，lambda的role policy配置完成。

3.2.3 配置代码

进入我们创建的Lambda “AxesdnRouterTableAutoFailoverForSDWAN-vAER”，点击Code。

将上图中lambda_function.py中的代码全部删除，替换为如下代码：

请联系Axesdn技术支持获取代码部分。

然后点击Deploy。

会显示“Changes deployed”

3.2.4 配置环境变量

在lambda程序中，我们配置了程序读取相应的环境变量。

在Lambda “AxesdnRouterTableAutoFailoverForSDWAN-vAER”中，点击Configuration->Environment variables->Edit。

点击“Add environment variable”，然后我们把本文3.1节获取的如下参数信息，逐条填入环境变量。

region = us-west-1
vpcid = vpc-0bf5741eb0ef56a41
host1eni = eni-071b4d6cbf57de651
host2eni = eni-0847da0f62b486046
注意：为了避免不必要的错误，请留意填入的值不要有空格。

点击Save完成保存。

环境变量这部分配置完毕。

3.2.5 配置Test Event

Test Event的作用，在本例中，是模拟CloudWatch Event来触发Lambda。这本身是一个调试程序用的功能，在实际生产环境中，如果不手动触发Test，这部分也不会实际发生作用。

因此，如果您对上面的配置有信心，理论上，Test Event的配置部分，是可以跳过的。

但是为了保证该配置教程的完整性，这里还是介绍下具体配置步骤，以及使用Test Event进行测试的方法。

在Lambda “AxesdnRouterTableAutoFailoverForSDWAN-vAER”中，点击Test。

选择New event;

Template选择默认的hello-world即可；

Name我这里填入 Event-vAER-A-Issue；

Event内容框，填入如下代码

{
  "id": "153bbf21-05cb-aa5f-f22d-c602cd2dbee4",
  "detail-type": "EC2 Instance State-change Notification",
  "source": "aws.ec2",
  "account": "731262942057",
  "time": "2021-12-11T12:59:41Z",
  "region": "us-west-1",
  "resources": [
    "arn:aws:ec2:us-west-1:731262942057:instance/i-045ebd27124159b6d"
  ],
  "detail": {
    "instance-id": "i-045ebd27124159b6d",
    "state": "pending"
  }
}

然后点击Save changes.

这里稍微解释下。上面event的内容，是模拟的当vAER-A的状态变为pending时，CloudWatch Event发给lambda的消息，以触发lambda运行路由倒换。我们lambda脚本中主要读取的内容，为detail中的instance-id。

这里为了配置Event模拟vAER-A的故障，里面 instance-id 填写的是vAER-A的instanceID i-045ebd27124159b6d。

扩展：如何查看instanceID？

点击AWS中的EC2服务，找到vAER的实例，即可直接看到instanceID，如下图。

下面继续配置Test Event。

我们再按照上面的方法，配置另一个 Event，以模拟vAER-B的故障。

还是刚刚Lambda中Test选项下，再次选择New event；

Template选择刚刚创建的 Event-vAER-A-Issue ；

Name我这里填入 Event-vAER-B-Issue；

Event内容框中，将 vAER-A 的 instanceID i-045ebd27124159b6d，替换为 vAER-B 的instanceID i-09ff574d23245419a；

然后点击Save changes.

vAER-A和vAER-B故障的Test Event配置好后，我们就可以通过这两个Test Event来模拟CLoudWatch发来的Event，并以此触发lambda，测试路由的自动倒换了。

【特别注意 Caution！~】

下面的操作会改动涉及到vAER-A和vAER-B的路由表，在生产环境请谨慎操作！！

请在操作前，备份现有路由表配置。

在测试倒换前，我们检查下当前VPC的路由表如下

图中可见，这里配置了两个网段 1.1.1.1/32 和 10.0.0.0/16的下一跳网关设置为vAER-A的ENI eni-071b4d6cbf57de651。

下面用 Event-vAER-A-Issue 模拟vAER-A状态变为pending，看能否触发路由切换。

进入Lambda “AxesdnRouterTableAutoFailoverForSDWAN-vAER”，点击Code。

点击Code下Test旁边的下拉菜单（小三角），选择 Event-vAER-A-Issue，然后再点击Test。

执行后，会自动弹出Execution results，如下图红框所示

Printout结果如下：

Test Event Name
Event-vAER-A-Issue

Response
null

Function Logs
START RequestId: 20946866-9d20-46e3-bb5a-18fc56dc61af Version: $LATEST
{'id': '153bbf21-05cb-aa5f-f22d-c602cd2dbee4', 'detail-type': 'EC2 Instance State-change Notification', 'source': 'aws.ec2', 'account': '731262942057', 'time': '2021-12-11T12:59:41Z', 'region': 'us-west-1', 'resources': ['arn:aws:ec2:us-west-1:731262942057:instance/i-045ebd27124159b6d'], 'detail': {'instance-id': 'i-045ebd27124159b6d', 'state': 'pending'}}
The instance i-045ebd27124159b6d with the ENI eni-071b4d6cbf57de651 is NOT RUNNING currently
So this script will failover the related TARGET eni in the route table, from eni-071b4d6cbf57de651 to eni-0847da0f62b486046, if it's NOT eni-0847da0f62b486046 currently
rtb-024855d8566b8128b Route Deleting started for 1.1.1.1/32 with eniid eni-071b4d6cbf57de651
rtb-024855d8566b8128b Route Deleted for 1.1.1.1/32 with eniid eni-071b4d6cbf57de651
rtb-024855d8566b8128b Route creating started for 1.1.1.1/32 with eniid eni-0847da0f62b486046
rtb-024855d8566b8128b Route created for 1.1.1.1/32 with eniid eni-0847da0f62b486046
rtb-024855d8566b8128b Route Deleting started for 10.0.0.0/16 with eniid eni-071b4d6cbf57de651
rtb-024855d8566b8128b Route Deleted for 10.0.0.0/16 with eniid eni-071b4d6cbf57de651
rtb-024855d8566b8128b Route creating started for 10.0.0.0/16 with eniid eni-0847da0f62b486046
rtb-024855d8566b8128b Route created for 10.0.0.0/16 with eniid eni-0847da0f62b486046
END RequestId: 20946866-9d20-46e3-bb5a-18fc56dc61af
REPORT RequestId: 20946866-9d20-46e3-bb5a-18fc56dc61af	Duration: 2594.08 ms	Billed Duration: 2595 ms	Memory Size: 128 MB	Max Memory Used: 75 MB	Init Duration: 253.09 ms

Request ID
20946866-9d20-46e3-bb5a-18fc56dc61af

从log可以看出，lambda已成功运行，并尝试failover the related TARGET eni in the route table, from eni-071b4d6cbf57de651 to eni-0847da0f62b486046，也就是把路由中的vAER-A切换到vAER-B。

下面我们去看下路由表是否真的有切换。

已成功切换。

下面我们再用Test Event Event-vAER-B-Issue，模拟vAER-B出问题，看路由能否再切回vAER-A上。

进入Lambda “AxesdnRouterTableAutoFailoverForSDWAN-vAER”，点击Code。

点击Code下Test旁边的下拉菜单（小三角），选择 Event-vAER-B-Issue，然后再点击Test。

Lambda运行的Execution results的Printout结果如下：

Test Event Name
Event-vAER-B-Issue

Response
null

Function Logs
START RequestId: 704ffb59-0b42-48de-b320-b4a745496ad5 Version: $LATEST
{'id': '153bbf21-05cb-aa5f-f22d-c602cd2dbee4', 'detail-type': 'EC2 Instance State-change Notification', 'source': 'aws.ec2', 'account': '731262942057', 'time': '2021-12-11T12:59:41Z', 'region': 'us-west-1', 'resources': ['arn:aws:ec2:us-west-1:731262942057:instance/i-09ff574d23245419a'], 'detail': {'instance-id': 'i-09ff574d23245419a', 'state': 'pending'}}
The instance i-09ff574d23245419a with the ENI eni-0847da0f62b486046 is NOT RUNNING currently
So this script will failover the related TARGET eni in the route table, from eni-0847da0f62b486046 to eni-071b4d6cbf57de651, if it's NOT eni-071b4d6cbf57de651 currently
rtb-024855d8566b8128b Route Deleting started for 1.1.1.1/32 with eniid eni-0847da0f62b486046
rtb-024855d8566b8128b Route Deleted for 1.1.1.1/32 with eniid eni-0847da0f62b486046
rtb-024855d8566b8128b Route creating started for 1.1.1.1/32 with eniid eni-071b4d6cbf57de651
rtb-024855d8566b8128b Route created for 1.1.1.1/32 with eniid eni-071b4d6cbf57de651
rtb-024855d8566b8128b Route Deleting started for 10.0.0.0/16 with eniid eni-0847da0f62b486046
rtb-024855d8566b8128b Route Deleted for 10.0.0.0/16 with eniid eni-0847da0f62b486046
rtb-024855d8566b8128b Route creating started for 10.0.0.0/16 with eniid eni-071b4d6cbf57de651
rtb-024855d8566b8128b Route created for 10.0.0.0/16 with eniid eni-071b4d6cbf57de651
END RequestId: 704ffb59-0b42-48de-b320-b4a745496ad5
REPORT RequestId: 704ffb59-0b42-48de-b320-b4a745496ad5	Duration: 2589.29 ms	Billed Duration: 2590 ms	Memory Size: 128 MB	Max Memory Used: 75 MB	Init Duration: 252.30 ms

Request ID
704ffb59-0b42-48de-b320-b4a745496ad5

从log可以看出，lambda已成功运行，并尝试 failover the related TARGET eni in the route table, from eni-0847da0f62b486046 to eni-071b4d6cbf57de651 ，也就是把路由中的vAER-B切换到vAER-A。

去检查路由表，确认已经从vAER-B切换到vAER-A。

以上就是Test Event的配置和测试过程。

3.2.6 小结

通过本节配置lambda，我们已经实现了路由倒换的核心功能，并且通过Test Event测试触发了lambda，实现了任意vAER出问题，相关的路由都会切换到另外一个vAER上。

下面，我们需要配置CloudWatch Event，来保证某一vAER真正出问题时，可以触发lambda实现路由自动切换。

3.3 配置CloudWatch Event

我们想要实现的效果是：

两个vAER的实例，无论其中任何一个的实例状态（instance state），不是running的，都发送CloudWatch Event到lambda，以触发lambda进行路由切换。

现在开始配置。

进入Lambda “AxesdnRouterTableAutoFailoverForSDWAN-vAER”，点击Function overview中的“+ Add trigger”。

选择EventBridge (CloudWatch Events)。

选择Create a new rule；

Rule name*这里填入这条规则的名字，最好还是满足清晰易识别的原则，我这里填入 CloudWatch-Rule-Axesdn-DetectvAerState-ChangeRouteTableAuto；

Rule description可以填入一些必要的信息，以方便以后整理和回忆，我这里填入：

For triggering lambda AxesdnRouterTableAutoFailoverForSDWAN-vAER, when one of the vAERs‘ state is NOT running, to change route table automatically. Please do NOT delete it.

Rule type选择Event pattern；

Event选择 EC2 –> EC2 instance state-change notification

勾选Detail；并勾选Detail中的State和Instances；

State中选中除了running之外的所有state

Instance ID填入vAER-A和vAER-B的instance ID

填完上面的配置信息后，实际上我们可以看到AWS会自动生成Event pattern如下，这部分无需操作，就是介绍下。

{
  "source": [
    "aws.ec2"
  ],
  "detail-type": [
    "EC2 Instance State-change Notification"
  ],
  "detail": {
    "state": [
      "pending",
      "shutting-down",
      "stopped",
      "stopping",
      "terminated"
    ],
    "instance-id": [
      "i-045ebd27124159b6d",
      "i-09ff574d23245419a"
    ]
  }
}

上面配置完毕后，点击页面最下方的Add。

然后，在Lambda的Function overview中，就可以看到新配置的trigger了。

至此，配置的部分已全部完成。

3.4 本章小结

至此，本教程提及的配置已全部完成。

整个路由切换的流程如下：

  1. CloudWatch监控vAER-A和vAER-B的实例状态（不是running则触发）；
  2. vAER-A或者vAER-B的状态不是running；
  3. 触发CloudWatch发送event给lambda；
  4. lambda开始运行；
  5. lambda读取event中出问题实例的instanceID，并获取该问题实例的ENI；
  6. lambda读取环境变量中vAER-A和vAER-B的ENI，VPC ID，region；
  7. lambda比较出问题实例的ENI和vAER-A & vAER-B实例的ENI，若出问题的为二者之一，则开始准备在路由表中用另一个ENI代替出问题的ENI；
  8. lambda读取现有VPC的路由表，并逐条路由检查，若有路由的target为出问题的ENI，则替换为另一个ENI；
  9. 结束程序。

4. 验收（自动切换测试）

【特别注意 Caution！~】

  • 下面的操作会改动涉及到vAER-A和vAER-B的路由表，在生产环境请谨慎操作！！
  • 请在操作前，备份现有路由表配置。
  • 本章操作涉及到关停vAER实例（stop instance），请确保您有足够的操作权限，并确认您关闭的，是正确的实例。
  • 请确认两个vAER实例都绑定了弹性IP（EIP），否则stop instance再次start后，实例的公网IP可能发生改变。

下面我们让相关路由指向vAER-A，保持vAER-A和vAER-B都为running的状态。

然后做如下操作：

  1. Stop vAER-A的实例，预期效果：相关路由自动切换到vAER-B上；
  2. 再次启动vAER-A，预期效果：相关路由不发生切换，保持在vAER-B上；
  3. Stop vAER-B的实例，预期效果：相关路由自动切换到vAER-A上；
  4. 再次启动vAER-B，预期效果：相关路由不发生切换，保持在vAER-A上。

如果上述操作，可以实现预期效果，则自动切换测试通过。

开始测试前，先检查vAER-A和vAER-B的实例状态，都为running。

检查并存档VPC路由表，确认相关路由指向的是vAER-A的ENI。

下面开始操作。

4.1 Stop vAER-A的实例

预期效果：相关路由自动切换到vAER-B上。

查看路由表，如下图，

可见相关路由，已切换到vAER-B的ENI。

满足预期效果。

此时，通过如下位置，可以查看lambda运行的log

从log上来看，运行也都正常。

4.2 再次启动vAER-A

预期效果：相关路由不发生切换，保持在vAER-B上

查看路由表，相关路由未发生切换，还是保持在vAER-B上。

满足预期效果。

此时若查看lambda的log，因为vAER-A会从pending变为running。在pending的状态会触发lambda，程序尝试把路由从vAER-A切换到vAER-B。但此时路由本身就在vAER-B上，因此实际上没有路由被改变。

4.3 Stop vAER-B的实例

预期效果：相关路由自动切换到vAER-A上。

查看路由表，如下图，

可见相关路由，已切换到vAER-A的ENI。

满足预期效果。

此时，查看lambda的log如下，

从log上来看，运行也都正常。

4.4 再次启动vAER-B

预期效果：相关路由不发生切换，保持在vAER-A上。

查看路由表，相关路由未发生切换，还是保持在vAER-A上。

满足预期效果。

此时若查看lambda的log，因为vAER-B会从pending变为running。在pending的状态会触发lambda，程序尝试把路由从vAER-B切换到vAER-A。但此时路由本身就在vAER-A上，因此实际上没有路由被改变。

4.5 本章小结

本章针对本次配置设计的路由自动切换，进行了功能性验收测试。

根据上面的测试步骤，得到了预期的测试效果。因此功能满足预期，可以使用。

补充说明：

本次测试未涉及两个vAER同时出问题的情况，因为如果两个vAER同时不可用了，该倒换机制也就没有意义了。因此该脚本不负责这种场景的恢复。

如果在生产环境中，出现两个vAER同时不可用，请联系AWS和Axesdn的技术支持，并尝试手动恢复。

5. 扩展内容

虽然通过本教程的配置，SDWAN的两个实例可以自动倒换，不需要人为干预。

但是，当您AWS的生产环境中，vAER的实例状态不是running了，或者路由发生了倒换，您作为管理员，可能也想要第一时间被告知。

因此，我们可以为该自动化程序配置一个自动触发的邮件告警，以便实现：

当vAER-A或者vAER-B的实例状态不为running，并触发了lambda时（注：触发lambda不代表路由一定发生切换，因为可能是没在被使用的vAER的状态有变化），发送邮件到指定的邮箱。

这里会用到AWS的SNS（Simple Notification Service) 服务。

配置方法如下。

AWS管理页面的服务中，选择Simple Notification Service服务，并进入。

点击左边导航栏的Topics

点击Create topic

Type选择Standard；

Name和Display name我这里填写：LambdaTriggered-RouteFailoverScirpt-forSDWAN

其他配置保持默认即可，然后点击“Create topic”

然后就可以看到新创建的SNS Topic了。

点击页面中的“Create subscription”

Topic ARN不用改动；

Protocol选择Email；

Endpoint填写您需要接收邮件的邮箱；

其他配置保持默认即可；

然后点击“Create subscription”。

配置中有提到，After your subscription is created, you must confirm it.

现在去邮箱中查收确认邮件如下，

点击邮件中的“Confirm subscription”，弹出浏览器如下页面确认Subscription confirmed。

此时如果回到SNS管理页面中，查看刚刚配置的Topic，如下图。

可见Subscriptions 中配置的条目的状态已变为Confirmed了。

下面，我们到Lambda的配置中，为这条lambda添加刚刚配置的SNS作为destination。

操作方法如下。

进入Lambda “AxesdnRouterTableAutoFailoverForSDWAN-vAER”，点击Function overview中的“+ Add destination”。

Source选择Asynchronous invocation；

Condition先选择“On success”；【解释】这里是指lambda执行成功则会触发这条SNS。我们之后还会配置“On failure”也触发SNS；

Destination type选择SNS topic；

Destination选择刚刚创建的 LambdaTriggered-RouteFailoverScirpt-forSDWAN；

然后点击Save。

然后，我们用相同的方法，再配置一条 “On failure” 的destination，如下图。

配置完毕，如下图。

下面我们测试下。

目前vAER-A和vAER-B都是running的状态。

SDWAN相关路由是指向vAER-A的。

我们现在手动把vAER-A给stop instance。

操作后约1分钟内，收到两封邮件如下，

可见关闭vAER-A的过程中，其状态stopping和stopped都触发的lambda，没有问题。

我们去检查路由表，也的确切换到了vAER-B上。

此时如果再次启动vAER-A实例，也会收到如下邮件，

说明pending状态也会正常触发邮件。

至此，lambda运行触发邮件告警的功能，已配置完毕，并且已验证可以正常运行。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注