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

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

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运行触发邮件告警的功能,已配置完毕,并且已验证可以正常运行。

发表回复

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