我可以: 邀请好友来看>>
ZOL论坛 > 技术论坛 > 局部NGINX后业务实例过载怎么办?F5有什么负载均衡解决方案?
帖子很冷清,卤煮很失落!求安慰
返回列表
签到
手机签到经验翻倍!
快来扫一扫!

局部NGINX后业务实例过载怎么办?F5有什么负载均衡解决方案?

2043浏览 / 0回复

ntsx9u

ntsx9u

0
精华
56
帖子

等  级:Lv.3
经  验:1155
  • Z金豆: 310

    千万礼品等你来兑哦~快点击这里兑换吧~

  • 城  市:
  • 注  册:2019-12-25
  • 登  录:2020-05-30
发表于 2020-04-02 15:50:11
电梯直达 确定
楼主

  

  LTM给NGINX做LB是一种较为典型的双层负载均衡,也就是典型的L4.L7分离的双层负载均衡解决方案。我们用了这个方案后,出现了 NGINX 后的服务器过载,怎么办?应该如喝解决?


  根绝我分析,如果LTM的pool member中的NGINX是位于不同的可用区或者不同的DC,此时LTM如仅做应用层负载均衡或仅monitor nginx本身,那么LTM是无法感知到 NGINX 背后(upstream)到底有多少可用的业务服务器。如果某个 NGINX 的upstream中可用服务器已经很少,此时LTM会依旧分配同等数量的连接请求给该NGINX,会导致该 NGINX 后的服务器过载,从而降低服务质量。


  F5提供的负载均衡解决方案的思路如下:


  如果能够让LTM感知到NGINX的upstream中当前有多少可用的服务器,并设置一个阀值,如低于该可用数量则LTM不再向该NGINX实例分配连接。这样就可以较好的避免上述问题。运维人员可根据LTM报出的日志或  Telemetry Streaming输出,及时触发相关自动化流程对该NGINX下的服务实例进行快速扩容,当可用服务实例数量恢复大于阀值后,LTM则又开始向该NGINX分配新的连接。


  NGINX Plus本身提供了一个API endpoint,通过获取该API并做相应处理即可获得可用的服务器实例数量,在LTM上则可以利用external monitor实施对该API的自动化监控与处理。

  局部NGINX后业务实例过载怎么办?F5有什么负载均衡解决方案?


  F5给出的负载均衡解决方案的具体操作


  1.获取的API资源路径是:安装可在中国使用的VPN。注:api后的版本6可能会因nginx plus的版本不同而不同.


  2.返回的内容示例如下,主要关心state: up, 只要获取到总的state: up数量即可

  {

    "peers": [

  {

        "id": 0,

        "server": "10.0.0.1:8080",

        "name": "10.0.0.1:8080",

        "backup": false,

        "weight": 1,

        "state": "up",

        "active": 0,

        "requests": 3468,

        "header_time": 778,

        "response_time": 778,

        "responses": {

          "1xx": 0,

          "2xx": 3435,

          "3xx": 6,

          "4xx": 20,

          "5xx": 4,

          "total": 3465

     },

        "sent": 1511086,

        "received": 99693373,

        "fails": 0,

        "unavail": 0,

        "health_checks": {

          "checks": 1754,

          "fails": 0,

          "unhealthy": 0,

          "last_passed": true

    },

        "downtime": 0,

        "selected": "2020-01-03T07:52:57Z"

    },

      {

        "id": 1,

        "server": "10.0.0.1:8081",

        "name": "10.0.0.1:8081",

        "backup": true,

        "weight": 1,

        "state": "unhealthy",

        "active": 0,

        "requests": 0,

        "responses": {

          "1xx": 0,

          "2xx": 0,

          "3xx": 0,

          "4xx": 0,

          "5xx": 0,

          "total": 0

   },

        "sent": 0,

        "received": 0,

        "fails": 0,

        "unavail": 0,

        "health_checks": {

          "checks": 1759,

          "fails": 1759,

          "unhealthy": 1,

          "last_passed": false

  },

        "downtime": 17588406,

        "downstart": "2020-01-03T03:00:00.427Z"

  }

    ]

  }

  3.可以编写如下python脚本:

  #!/usr/bin/python

  # -*- coding: UTF-8 -*-

  import sys

  import urllib2

  import json

  def get_nginxapi(url):

      ct_headers = {'Content-type':'application/json'}

      request = urllib2.Request(url,headers=ct_headers)

      response = urllib2.urlopen(request)

      html = response.read()

      return html

  api = sys.argv[3]

  try:

      data = get_nginxapi(api)

      data = json.loads(data)

  except:

      data = ''

  m = 0

  lowwater = int(sys.argv[4])

  try:

      for peer in data['peers']:

          state = peer['state']

          if state == 'up':

              m = m + 1

  except:

      m = 0

  #print data['peers'][]['state']

  #print m

  if m >= lowwater:

      print 'UP'


  4.将该脚本上传至LTM,上传路径:system–file management–external monitor–import, 效果如下

  局部NGINX后业务实例过载怎么办?F5有什么负载均衡解决方案?


  5.配置external-monitor, 注意arguments部分填写:

  注意空格前填写的是相关API的URL,空格后填写阀值

  局部NGINX后业务实例过载怎么办?F5有什么负载均衡解决方案?


  6.随后将该monitor 关联到某个nginx pool member上

  局部NGINX后业务实例过载怎么办?F5有什么负载均衡解决方案?


  可以看到,该member 此时标记为up

  局部NGINX后业务实例过载怎么办?F5有什么负载均衡解决方案?


  7.如果将阀值改为3,由于当前upstream中仅有2台可用,因此LTM将标记该NGINX实例为down

  局部NGINX后业务实例过载怎么办?F5有什么负载均衡解决方案?

  局部NGINX后业务实例过载怎么办?F5有什么负载均衡解决方案?


  其它:


  输入错误的url或者错误的endpoints 等,都直接置为down,这样用户可以比较容易发现问题?Upstream中被设置为backup的状态的成员认为是可用的?此方法还可以避免实际服务器被LTM和nginx两次monitor


  如果nginx有很多个upstream的话,LTM怎么设定?


  从前端ltm到nginx来说,如果此nginx后端的任何upstream容量不足的话,都不应该给这个nginx再分链接,所以多个upstream的话,可以ltm上设置多个monitor,并设置 all need up。


  如果nginx的上的配置有问题,实际业务访问不了,上述方案似乎无法发现此场景问题?


  是的,对于nginx本身可用性及配置问题,可考虑在LTM上加一个穿透性的7层健康检查,但是如果NGINX本身有很多server/locetion段落配置,又想发现所有这些段落可能存在的问题,那就意味着要对每个服务都进行7层健康检查,这个在服务特别多场景下,需要思考,或许过度追求探测的完美性会对业务服务器带来更多的探测压力。理论上,LTM上一个穿透性检查+所有upstream的API检查,能够满足大部分场景。


  在大规模NGINX部署场景下,如何降低NGINX健康检查对后端服务的压力?


  可考虑nginx做动态服务发现app,app的可用性由注册中心类工具来解决,从分布式的健康检查变成注册中心集中式的健康检查; 或者借助NGINX plus的upstream API 通过集中健康检查系统来动态性更新upstream,这样可避免频繁reload配置, 从而减低健康检查带来的压力。


  以上内容就是局部NGINX后业务实例过载后F5负载均衡解决方案的实际操作方法,希望对您有所帮助。如果您看完还不会操作,建议联系F5客服,F5将会快速的,针对性的帮您解决问题。


  【文章来源】F5软件方向解决方案架构师林静的《F5社区好文推荐:多可用区双层负载下,如何借助F5避免局部NGINX后业务实例过载》。


高级模式
论坛精选大家都在看24小时热帖7天热帖大家都在问最新回答

针对ZOL论坛您有任何使用问题和建议 您可以 联系论坛管理员查看帮助  或  给我提意见

快捷回复 APP下载 返回列表