At time 23, 𝐽2 is scheduled on 𝑀1 and reads its data from 𝐷2 and stores its output to 𝐷2. Finally, It costs 6/2 + 60/2 + 10/2= 38 unit time and it finishes at time 52.这个60 /10 是哪里来的，用例J2的熟悉为2 20 6 2 1 2Affinity of machines: In this case, the only restriction of affinity is that task 6 can only run in machine 1. And in this solution, it DOES.用例里面，task 6不是只和机器2亲和么，为什么这里只能运行在机器1

前言随着互联网的快速发展，负载均衡技术成为了保证高可用性、高性能和可扩展性的关键手段。在众多负载均衡软件中，Nginx和HAProxy都是非常受欢迎的选择。本文将详细探讨这两种软件的差异、优势与劣势，以及它们各自适用的场景。一、Nginx1. 优势高度模块化：Nginx的设计高度模块化，支持动态加载和卸载模块，使其具有很高的灵活性。高性能：Nginx在处理静态内容方面表现出色，非常适合作为Web服务器和反向代理服务器。易于配置：Nginx的配置文件简洁明了，易于上手。2. 劣势功能相对有限：与HAProxy相比，Nginx的负载均衡功能相对较为简单，不支持动态权重调整等高级功能。社区支持：虽然Nginx的社区非常活跃，但相较于HAProxy，其社区支持略显不足。3. 使用场景Web服务器：Nginx适合作为高性能的Web服务器，处理静态内容。反向代理：Nginx可以作为反向代理服务器，将请求转发给后端服务器。二、HAProxy1. 优势功能强大：HAProxy支持多种负载均衡算法和会话保持机制，还提供了动态权重调整等高级功能。高性能：HAProxy在处理大量并发连接时表现出色，非常适合作为负载均衡器。稳定性：HAProxy经过严格的测试和生产环境验证，具有极高的稳定性。2. 劣势配置复杂度：HAProxy的配置文件相对复杂，需要一定的学习成本。社区支持：虽然HAProxy的社区支持不错，但与Nginx相比略显逊色。3. 使用场景大型网站和应用：HAProxy适合用于大型网站和应用的负载均衡，能够处理大量的并发连接。动态权重调整：当需要根据后端服务器的性能动态调整权重时，HAProxy是一个很好的选择。三、总结Nginx和HAProxy都是非常优秀的负载均衡软件，各自具有独特的优势和适用场景。在选择时，应根据实际需求、团队技能和项目规模等因素进行综合考虑。对于小型项目或需要快速上手的场景，Nginx可能是一个更好的选择；而对于大型项目或需要高级负载均衡功能的场景，HAProxy则更具优势。

前言在当今云计算和大数据的时代，负载均衡作为一种关键技术，广泛应用于各类互联网服务和大型企业应用中。它能够有效地提高系统的可扩展性、稳定性和性能。本文将介绍几种常见的负载均衡方式，并探讨它们各自的使用场景。一、负载均衡概述负载均衡（Load Balancing）是一种将网络请求分发到多个服务器或服务的计算方法，旨在优化资源利用、最大化吞吐量和加强系统可靠性。负载均衡器会根据预定义的策略将流量分配给后端的服务器或服务，从而实现负载的均衡分布。二、常见的负载均衡方式软件负载均衡软件负载均衡通过软件程序实现，通常运行在通用操作系统上。常见的软件负载均衡工具有Nginx、HAProxy等。它们可以在低成本的硬件上运行，配置灵活，且易于扩展。使用场景：适用于中小型网站、Web应用、API服务等，需要高性能、低成本且易于管理的场景。硬件负载均衡硬件负载均衡器使用专门的硬件设备来实现负载均衡功能，通常集成有高性能的处理器和专用的负载均衡算法。硬件负载均衡器通常提供硬件级别的故障转移和冗余备份，确保系统的高可用性。使用场景：适用于大型企业、金融机构等对系统稳定性和可靠性要求极高的场景。DNS负载均衡DNS负载均衡通过修改DNS记录来实现负载均衡，将不同的域名解析到不同的服务器上。这种方式简单易用，但无法实现会话保持和故障转移。使用场景：适用于简单的场景，如根据地理位置或访问量将流量分配到不同的服务器上。反向代理负载均衡反向代理负载均衡通过反向代理服务器将客户端的请求转发给后端服务器。这种方式可以实现会话保持、缓存和压缩等功能，提高系统的性能和稳定性。使用场景：适用于需要实现复杂负载均衡策略的场景，如根据请求头、URL或Cookie等信息进行流量分发。三、总结负载均衡是提高系统性能和可靠性的关键技术，不同的负载均衡方式各有优缺点，适用于不同的场景。在选择负载均衡方式时，需要根据实际需求进行综合考虑，如系统规模、性能要求、成本预算等因素。同时，也需要关注负载均衡器的可扩展性、可维护性和安全性等方面的问题，以确保系统的长期稳定运行。

前言LVS和Nginx都是常见的负载均衡软件，它们各自具有不同的特点和优势。LVS是Linux内核级别的负载均衡软件，专注于负载均衡功能的实现，可以提供高性能和稳定性。它具有以下优点：抗负载能力强：由于其简单的工作方式和位于网络层第4层的特性，LVS主要进行请求分发，没有流量，因此在效率上基本不需要过多考虑。配置性低：这是一个优势，因为不需要经常去触碰它，从而大大减少了人为出错的几率。工作稳定：由于其本身抗负载能力很强，所以稳定性高。另外，各种LVS都有完整的双机热备方案，所以系统整体非常稳定。无流量：LVS仅仅分发请求，而流量并不从它本身出去，所以可以利用它来做一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。基本上能支持所有应用：由于工作在第4层，所以它可以对几乎所有应用做负载均衡，包括http、数据库、聊天室等。然而，LVS也有一些潜在的缺点。例如，它无法完全判别节点故障，如在使用wlc分配方式下，集群里有一个节点没有配置vip，会使整个集群不能使用。Nginx则是一个应用级的、采用事件驱动的方式进行负载均衡软件。除了负载均衡外，Nginx还可以作为Web服务器、反向代理服务器、缓存服务器等多种用途。它的特点是：高性能：Nginx使用了异步事件驱动架构，能够处理大量的并发连接。配置灵活：Nginx的配置非常灵活，可以通过配置文件进行各种定制化的设置。功能丰富：Nginx除了基本的负载均衡功能外，还提供了反向代理、请求缓存、SSL加密传输等许多其他功能。社区支持：Nginx有一个活跃的开发者社区，为使用者提供技术支持和新的功能模块。然而，与LVS相比，Nginx的抗负载能力和稳定性可能稍逊一筹。因此，选择LVS还是Nginx取决于具体需求和环境。如果需要一个专注于负载均衡的高性能和稳定性的解决方案，LVS可能是一个更好的选择。而如果需要一个功能丰富、配置灵活的负载均衡软件，并能处理大量的并发连接，那么Nginx可能更适合。LVS三种模式LVS三种模式中，虽然DR模式以及TUN模式只有请求的报文经过Director，但是NAT模式，Real Server回复的报文也会经过Director Server地址重写：首先要清楚的一点是,LVS是一个四层的负载均衡器,虽然是四层,但并没有TCP握手以及分手,只是偷窥了IP等信息,而Nginx是一个七层的负载均衡器,所以效率势必比四层的LVS低很多,但是可操作性比LVS高,后面所有的讨论都是基于这个区别。为什么四册比七层效率高?四层是TCP层，使用IP+端口四元组的方式。只是修改下IP地址，然后转发给后端服务器，TCP三次握手是直接和后端连接的。只不过在后端机器上看到的都是与代理机的IP的established而已,LVS中没有握手。7层代理则必须要先和代理机三次握手后，才能得到7层（HTT层）的具体内容，然后再转发。意思就是代理机必须要与client和后端的机器都要建立连接。显然性能不行，但胜在于七层，人工可操作性高,能写更多的转发规则。Nginx特点Nginx 专为性能优化而开发，性能是其最重要的要求，十分注重效率，有报告 Nginx 能支持高达 50000 个并发连接数。另外，Nginx 系列面试题和答案全部整理好了，微信搜索Java技术栈，在后台发送：面试，可以在线阅读。正向代理与反向代理正向代理 ：局域网中的电脑用户想要直接访问服务器是不可行的，服务器可能Hold不住,只能通过代理服务器来访问，这种代理服务就被称为正向代理,特点是客户端知道自己访问的是代理服务器。反向代理 ：客户端无法感知代理，因为客户端访问网络不需要配置，只要把请求发送到反向代理服务器，由反向代理服务器去选择目标服务器获取数据，然后再返回到客户端。此时反向代理服务器和目标服务器对外就是一个服务器，暴露的是代理服务器地址，隐藏了真实服务器 IP 地址。负载均衡客户端发送多个请求到服务器，服务器处理请求，有一些可能要与数据库进行交互，服务器处理完毕之后，再将结果返回给客户端。推荐程序员摸鱼地址：https://www.yoodb.com/slack-off/home.html普通请求和响应过程如下图：但是随着信息数量增长，访问量和数据量增长，单台的Server以及Database就成了系统的瓶颈,这种架构无法满足日益增长的需求,这时候要么提升单机的性能,要么增加服务器的数量。关于提升性能,这儿就不赘述,提提如何增加服务器的数量，构建集群，将请求分发到各个服务器上，将原来请求集中到单个服务器的情况改为请求分发到多个服务器，也就是我们说的负载均衡。图解负载均衡：关于服务器如何拆分组建集群,这儿主要讲讲负载均衡,也就是图上的Proxy,可以是LVS,也可以是Nginx。假设有 15 个请求发送到代理服务器，那么由代理服务器根据服务器数量，这儿假如是平均分配，那么每个服务器处理 5 个请求，这个过程就叫做负载均衡。动静分离为了加快网站的解析速度，可以把动态页面和静态页面交给不同的服务器来解析，加快解析的速度，降低由单个服务器的压力。动静分离之前的状态动静分离之后光看两张图可能有人不理解这样做的意义是什么,我们在进行数据请求时,以淘宝购物为例,商品详情页有很多东西是动态的,随着登录人员的不同而改变,例如用户ID,用户头像,但是有些内容是静态的,例如商品详情页,那么我们可以通过CDN(全局负载均衡与CDN内容分发)将静态资源部署在用户较近的服务器中,用户数据信息安全性要更高,可以放在某处集中,这样相对于将说有数据放在一起,能分担主服务器的压力,也能加速商品详情页等内容传输速度。Nginx优势可操作性大Nginx是一个应用层的程序,所以用户可操作性的空间大得多,可以作为网页静态服务器，支持 Rewrite 重写规则；支持 GZIP 压缩，节省带宽；可以做缓存；可以针对 http 应用本身来做分流策略，静态分离，针对域名、目录结构等相比之下 LVS 并不具备这样的功能，所以 nginx 单凭这点可以利用的场合就远多于 LVS 了；但 nginx 有用的这些功能使其可调整度要高于 LVS，所以经常要去触碰，人为出现问题的几率也就大网络依赖小nginx 对网络的依赖较小，理论上只要 ping 得通，网页访问正常，nginx 就能连得通，nginx 同时还能区分内外网，如果是同时拥有内外网的节点，就相当于单机拥有了备份线路；LVS 就比较依赖于网络环境，目前来看服务器在同一网段内并且 LVS 使用 direct 方式分流，效果较能得到保证。另外注意，LVS 需要向托管商至少申请多于一个 ip 来做 visual ip安装简单nginx 安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。LVS 的安装和配置、测试就要花比较长的时间，因为同上所述，LVS 对网络依赖性比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦的多nginx 也同样能承受很高负载且稳定，但负载度和稳定度差 LVS 还有几个等级：nginx 处理所有流量所以受限于机器 IO 和配置；本身的 bug 也还是难以避免的；nginx 没有现成的双机热备方案，所以跑在单机上还是风险比较大，单机上的事情全都很难说支持健康检查以及请求重发nginx 可以检测到服务器内部的故障（健康检查），比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前 LVS 中 ldirectd 也能支持针对服务器内部的情况来监控，但 LVS 的原理使其不能重发请求。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，nginx 会把上传切到另一台服务器重新处理，而 LVS 就直接断掉了。LVS优势抗负载能力强因为 LVS 工作方式的逻辑是非常简单的，而且工作在网络的第 4 层，仅作请求分发用，没有流量，所以在效率上基本不需要太过考虑。LVS 一般很少出现故障，即使出现故障一般也是其他地方（如内存、CPU 等）出现问题导致 LVS 出现问题配置性低这通常是一大劣势同时也是一大优势，因为没有太多的可配置的选项，所以除了增减服务器，并不需要经常去触碰它，大大减少了人为出错的几率工作稳定因为其本身抗负载能力很强，所以稳定性高也是顺理成章的事，另外各种 LVS 都有完整的双机热备方案，所以一点不用担心均衡器本身会出什么问题，节点出现故障的话，LVS 会自动判别，所以系统整体是非常稳定的无流量LVS 仅仅分发请求，而流量并不从它本身出去，所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的 IO 性能不会受到大流量的影响LVS 基本上能支持所有应用，因为 LVS 工作在第 4 层，所以它可以对几乎所有应用做负载均衡，包括 http、数据库、聊天室等。

1.背景介绍随着 Internet 的快速发展和业务量的不断提高，基于网络的数据访问流量迅速增长，特别是对数据 中心、大型企业以及门户网站等的访问，其访问流量甚至达到了 10Gb/s 的级别；同时，服务器网 站借助 HTTP、FTP、SMTP 等应用程序，为访问者提供了越来越丰富的内容和信息，服务器逐渐 被数据淹没；另外，大部分网站（尤其电子商务等网站）都需要提供不间断 24 小时服务，任何服 务中断或通信中的关键数据丢失都会造成直接的商业损失。所有这些都对应用服务提出了高性能和 高可靠性的需求。 但是，相对于网络技术的发展，服务器处理速度和内存访问速度的增长却远远低于网络带宽和应用 服务的增长，网络带宽增长的同时带来的用户数量的增长，也使得服务器资源消耗严重，因而服务 器成为了网络瓶颈。传统的单机模式，也往往成为网络故障点。针对以上情况的解决方案：(1) 服务器进行硬件升级：采用高性能服务器替换现有低性能服务器。 该方案的弊端：高成本：高性能服务器价格昂贵，需要高额成本投入，而原有低性能服务器被闲置，造成资 源浪费。可扩展性差：每一次业务量的提升，都将导致再一次硬件升级的高额成本投入，性能再卓越 的设备也无法满足当前业务量的发展趋势。无法完全解决现在网络中面临的问题：如单点故障问题，服务器资源不够用问题等。(2) 组建服务器集群，利用负载均衡技术在服务器集群间进行业务均衡。该方案的优势： 低成本可扩展性：当业务量增长时，系统可通过增加服务器来满足需求，且不影响已有业务，不降 低服务质量高可靠性：单台服务器故障时，由负载均衡设备将后续业务转向其他服务器，不影响后续业 务提供，保证业务不中断。2.知识剖析负载均衡原理系统的扩展可分为纵向（垂直）扩展和横向（水平）扩展。纵向扩展，是从单机的角度通过增加硬件处理能力，比如CPU处理能力，内存容量，磁盘等方面，实现服务器处理能力的提升，不能满足大型分布式系统（网站），大流量，高并发，海量数据的问题。因此需要采用横向扩展的方式，通过添加机器来满足大型网站服务的处理能力。比如：一台机器不能满足，则增加两台或者多台机器，共同承担访问压力。这就是典型的集群和负载均衡架构：如下图：应用集群：将同一应用部署到多台机器上，组成处理集群，接收负载均衡设备分发的请求，进行处理，并返回相应数据。负载均衡设备：将用户访问的请求，根据负载均衡算法，分发到集群中的一台处理服务器。（一种把网络请求分散到一个服务器集群中的可用服务器上去的设备）负载均衡的作用：1.解决并发压力，提高应用处理性能（增加吞吐量，加强网络处理能力）；2.提供故障转移，实现高可用；3.通过添加或减少服务器数量，提供网站伸缩性（扩展性）；4.安全防护；（负载均衡设备上做一些过滤，黑白名单等处理）负载均衡分类:根据实现技术不同，可分为DNS负载均衡，HTTP负载均衡，IP负载均衡，反向代理负载均衡、链路层负载均衡等。负载均衡算法:lun询、 随机、最少链接、Hash（源地址散列）、加权硬件负载均衡:采用硬件的方式实现负载均衡，一般是单独的负载均衡服务器，价格昂贵，一般土豪级公司可以考虑，业界领先的有两款，F5和A10。价格：F5， 15w~55w不等；A10， 55w-100w不等。优点：功能全面支持各层级的负载均衡，支持全面的负载均衡算法，支持全局负载均衡。一般软件负载均衡支持到5万级并发已经很困难了，硬件负载均衡可以支持。商用硬件负载均衡稳定性高，具备防火墙，防DDOS攻击等安全功能，提供售后支持。3.常见问题怎么配置负载均衡？4.解决方案1.部署至少两台服务器，我选择在本地部署一台jetty、一台tomcat。2.在nginx.conf配置文件中http括号内添加如下配置:upstream  local_tomcat {server    localhost:8088;server    localhost:8089;}server{location / {proxy_pass http://local_tomcat;}}3.在hosts文件中添加解析域名127.0.0.1     local_tomcat5.扩展思考什么是反向代理负载均衡？反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器，该服务器就可称之为代理服务器。由于代理服务器处在最终处理请求访问的服务器之前，因此可以在代理服务器上做负载均衡。

延迟加载：// 将商品信息加载到缓存中 public void loadGoodsToCache() { List<Goods> goodsList = goodsService.getGoodsList(); for (Goods goods : goodsList) { redisTemplate.opsForValue().set("goods:" + goods.getId(), goods); } } // 秒杀开始时将缓存中的商品信息加载到数据库中 public void startSeckill() { List<Goods> goodsList = redisTemplate.opsForValue().multiGet(redisTemplate.keys("goods:*")); for (Goods goods : goodsList) { goodsService.updateGoods(goods); } }队列：java // 将秒杀请求放入消息队列中 public void seckill(String userId, String goodsId) { SeckillRequest request = new SeckillRequest(userId, goodsId); rabbitTemplate.convertAndSend("seckill.exchange", "seckill.queue", request); } // 消费者处理秒杀请求 @RabbitListener(queues = "seckill.queue") public void handleSeckillRequest(SeckillRequest request) { // 处理秒杀请求 }限流：java // 使用Guava RateLimiter进行限流 private static final RateLimiter rateLimiter = RateLimiter.create(100); // 处理秒杀请求 public void seckill(String userId, String goodsId) { if (rateLimiter.tryAcquire()) { // 处理秒杀请求 } else { // 返回错误信息 } }分布式锁：java // 使用Redisson实现分布式锁 private static final RLock lock = redissonClient.getLock("seckill"); // 处理秒杀请求 public void seckill(String userId, String goodsId) { try { lock.lock(); // 处理秒杀请求 } finally { lock.unlock(); } }CDN加速：java // 使用Nginx配置CDN加速 location /static/ { proxy_pass http://cdn.example.com/static/; }分布式缓存：java // 使用Redis缓存商品信息 public Goods getGoodsById(String goodsId) { Goods goods = redisTemplate.opsForValue().get("goods:" + goodsId); if (goods == null) { goods = goodsService.getGoodsById(goodsId); redisTemplate.opsForValue().set("goods:" + goodsId, goods); } return goods; }异步处理：java // 将秒杀请求放入消息队列中，由异步处理程序进行处理 public void seckill(String userId, String goodsId) { SeckillRequest request = new SeckillRequest(userId, goodsId); rabbitTemplate.convertAndSend("seckill.exchange", "seckill.queue", request); } // 异步处理程序处理秒杀请求 @RabbitListener(queues = "seckill.queue") public void handleSeckillRequest(SeckillRequest request) { // 处理秒杀请求 }​​

背景DWS为多CN架构，建议在CN之上假设负载均衡组件。作用：将前端负载均匀分布到各个CN上，避免单个CN成为整个集群的瓶颈。配合CN自动剔除，可以支持单个CN故障后，不向故障CN发送任务，将CN故障对业务的影响降到最低。注意事项DWS搭配负载均衡组件时，负载均衡组件使用DR模式，客户端连接服务器时，首先会访问负载均衡服务器，负载均衡服务器将连接按照一定的算法（如轮询算法）分发到各个数据库服务器上（CN），数据返回时，不经过负载均衡服务器，直接返回到客户端。因此，如果客户端的访问请求流量较大，可能会将负载均衡服务器流量打满，而结果返回时，由于是直接返回客户端，不经过负载均衡服务器。DWS客户端访问可能导致流量大的操作场景主要是copy from、copy from任务。copy from、copy from命令用于将本地文件或数据流高效拷贝到数据库表中，因此会存在大量数据从客户端传送到服务端，如果配置了负载均衡服务器，数据会经过负载均衡服务器，当copy from、copy from任务要拷贝的文件较大、并发较高，超出了负载均衡服务器可承载的流量后，会导致负载均衡服务器成为瓶颈。因此，建议大流量的copy、copy任务直接连接固定CN IP执行。在此CN出现异常后，需要业务修改连接字符串中CN IP，将业务切换到其他CN执行。使用copy from、copy from的场景主要有：1.使用gsql客户端，调用copy from、 copy from命令向服务端传送数据。其中copy from命令只能在CN所在节点执行，copy from命令可以远程执行。示例如下：COPY tpcds.ship_mode_t1 FROM "/home/omm/ds_ship_mode.dat" WITH(format "text", delimiter E" ", ignore_extra_data "true", noescaping "true"); 2.使用jdbc copy manager接口，或使用封装了jdbc copy manager接口的工具，向服务端传送数据。copy manager接口如下：CopyManager copyManager = new CopyManager((BaseConnection)connection);          fileInputStream = new FileInputStream(filePath);         copyManager.copyIn("COPY " + tableName + " FROM STDIN", fileInputStream); 3.sql on oracle, sql on other gaussdb, sql on spark这些也都是走CN和负载均衡的。若使用F5做负载均衡，请关注以上场景

公网和私网负载均衡器_弹性负载均衡 ELB_产品介绍_华为云 (huaweicloud.com)负载均衡按照支持的网络类型的不同分为公网负载均衡器和私网负载均衡器。公网负载均衡器通过给负载均衡器绑定弹性公网IP，使其支持转发公网流量请求，称为公网负载均衡器。通过公网IP对外提供服务，将来自公网的客户端请求按照指定的负载均衡策略分发到后端云服务器进行处理。图1 公网负载均衡器

虚拟机高可用高并发场景的组网负载均衡方案：1.在VPC/子网内创建弹性负载均衡实例作为服务接口对外提供

                     X企业容器化改造方案 【背景】A企业是一家位于杭州的软件开发公司，具备自主设计软件，交付软件及销售的能力，目前公司业务已经上华为云，考虑到开发及交付的便利性，准备进行容器化改，目标是能够实现软件开发即交付。业务现网状况如下：目前2台web服务器作为前端，mysql数据库，软件负载均衡器，无数据库中间件，后端EVS云硬盘，针对于本企业的现状，给出各部分的容器化改造及后续方案.1：负载均衡应用改造点：选择合适的负载均衡器中小型的Web应用可以使用ngnix或HAProxy，大型网站或重要的服务可以使用LVS，目前该企业业务较小，选取nginx作为负载均衡器！2：web应用改造点：应用存在长时间执行请求   增加消息队列，通过消息队列将长任务与用户请求解耦3：应用服务器应用改造点：应用实例依赖于本地的存储来持久化数据如果是日志，建议变成流汇聚到分布式日志系统中。如果必须要使用存储，要使用共享文件系统如NFS。4：资源及集群规划规划：目前采用单集群规划，云资源中有其他应用项目请画出简要的资源规划图：5：高可用规划   结合华为云，给出高可用规划的简单说明：    分别在2个AZ中部署两套CCE集群，K8S Master采用本地3节点高可用部署；应用AZ内高可用部署，通过ClusterIP服务调用不跨AZ。应用发布LoadBalancer类型的Service对接到集群所在AZ的融合ELB服务实例；应用通过VIP访问数据库，数据库自动切换应用不感知。支持多AZ动态容器存储，根据pod所在AZ创建数据卷。6：网络规划：集群内部应用默认可通过ClusterIP类型服务相互通信。k8s集群内置DNS服务，服务间访问可以通过IP或域名访问，请画出K8S集群内部应用网络互通示意图：Step1：kube-proxy、core-dns从Master中kube-apiserver订阅service，POD2的Service创建时，kube-proxy刷新本节点iptables，core-DNS更新路由数据。Step2：Pod2通过域名访问Pod4的service4，发起到core-dns查询请求，并获取对应的ClusterIP（如果使用ClusterIP直接访问则忽略这一步骤）Step3：Pod2发送业务报文，目的地址为获取到的ClusterIP。容器网络根据目的地址匹配策略后进行VxLAN封装，封装源地址为容器所在的VM IP地址，目的地址为目的容器所在VM IP，并将报文发给I层vSwitch，然后转发至目的容器所在VM，容器网络解VxLAN封装后，根据ClusterIP将业务报文发送目的service及POD。   

一、为什么要做负载均衡？(下面的话是引用网上的)在网站创立初期，我们一般都使用单台机器对外提供集中式服务，但是随着业务量越来越大，无论是性能上还是稳定性上都有了更大的挑战。这时候我们就会想到通过扩容的方式来提供更好的服务。我们一般会把多台机器组成一个集群对外提供服务。然而，我们的网站对外提供的访问入口都是一个的，比如www.huaweicloud.com 。那么当用户在浏览器输入www.huaweicloud.com 的时候如何将用户的请求分发到集群中不同的机器上呢，这就是负载均衡在做的事情。针对以上情况的解决方案：(1) 服务器进行硬件升级：采用高性能服务器替换现有低性能服务器。 该方案的弊端：高成本：高性能服务器价格昂贵，需要高额成本投入，而原有低性能服务器被闲置，造成资 源浪费。可扩展性差：每一次业务量的提升，都将导致再一次硬件升级的高额成本投入，性能再卓越 的设备也无法满足当前业务量的发展趋势。无法完全解决现在网络中面临的问题：如单点故障问题，服务器资源不够用问题等。(2) 组建服务器集群，利用负载均衡技术在服务器集群间进行业务均衡。该方案的优势： 低成本可扩展性：当业务量增长时，系统可通过增加服务器来满足需求，且不影响已有业务，不降 低服务质量高可靠性：单台服务器故障时，由负载均衡设备将后续业务转向其他服务器，不影响后续业 务提供，保证业务不中断。二、什么是负载均衡？负载均衡：分摊到多个操作单元上进行执行，和它的英文名称很匹配。就是我们需要一个调度者，保证所有后端服务器都将性能充分发挥，从而保持服务器集群的整体性能最优，这就是负载均衡。(大白话解释：就是有一台服务器用来接收请求并将请求做分(转)发，将发过来的请求按照你自己制定的分发规则分别转发到其它的服务器上。重点：有一台服务器专门用来做请求分发的服务器)负载均衡这里面涉及的东西相对也是比较多的，理论就不说太多了，网上，书上很多，今天我们就利用Nginx服务器来实现一个简单的负载均衡来，我们上负载均衡工作流程图至此 也就是说 要想搭建负载均衡服务器 至少需要三台服务器 有一台用来做负载均衡服务器，另外两台用来做web服务器三、相关准备工作我们使用三台服务器(三台服务器都已安装了nginx)负载均衡服务器：119.3.220.26 (用来将请求分发给下面的web server服务器1和web server服务器2)web server服务器1：111.231.138.248 (给站点增加一个index.html文件 里面写上 web server1)web server服务器2：114.116.115.71 (给站点增加一个index.html文件 里面写上 web server2)注意：为了防止不必要的出错 我们将三台服务器的防火墙都关闭以及关闭setlinux1、关闭防火墙 centos6系列：service iptables stop centos7系列：systemctl stop firewalld2、关闭setlinux 命令：setenforce 0四、开始配置我们使用nginx 中的upstream模块来实现nginx将跨越单机的限制，完成网络数据的接收、处理和转发。我们主要使用提到的转发功能进行调度分发。1、119.3.220.26服务器中的nginx.conf配置文件中加入如下配置：#配置负载均衡请求分发的服务器 连接池(列表)``upstream lb {`` ``server 111.231.138.248;`` ``server 114.116.115.71;``}` `server{` ` ``.....``#这里省略其它不相关配置.` ` ``location / {`` ` ` ``proxy_pass http:``//lb``; ``#指定代理的连接池，lb是你在上面中upstream后定义的名字`` ``proxy_set_header Host $host; ``#转发请求头信息`` ``proxy_set_header X-Forward-For $remote_addr; ``#转发请求IP地址 `` ` ` ``}``}示例配置截图：重启119.3.220.26中的nginx浏览器访问负载均衡服务器IP地址：119.3.220.26 会显示web server1 刷新后会显示web server2 再次刷新又会显示web server1 以此类推下去。。这种分发方式是upstream模块默认的轮询法，每个ip分发一次 就是我们现在的效果 第一次分发给111.231.138.248这台服务器 再次请求的时候就会分发给114.116.115.71服务器 这样一直重复下去。。2、如果你想让某一台服务器被分发到的概率高一些 那么119.3.220.26服务器中的nginx.conf配置文件中的upstream模块中的每个ip地址可以设置权重(加权轮询法)改成如下配置：#配置负载均衡请求分发的服务器 连接池(列表)``upstream lb {`` ``server 111.231.138.248 weight=5; ``#weight表示权重的意思，数字越大，权重越高,即 会优先分发给权重高的服务器`` ``server 114.116.115.71 weight=2;``}示例配置截图：我们可以看到多了一个weight关键字，除了weight还有down backup等......``//down``： 表示单前的server临时不參与负载.``//weight``：默认为1 weight越大，负载的权重就越大``//backup``：表示当前server是备用服务器，只有其它非backup后端服务器都挂掉了或者很忙才会分配到请求 所以这台机器压力会最轻这样就简单的实现了负载均衡的搭建五、负载均衡请求分发算法轮询法：将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载。(就是我们第一张截图中的配置文件的配置方式)加权轮询法：不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重，让其处理更多的请；而配置低、负载高的机器，给其分配较低的权重，降低其系统负载，加权轮询能很好地处理这一问题，并将请求顺序且按照权重分配到后端。(就是我们第二张截图中的配置文件的配置方式)加权随机法：与加权轮询法一样，加权随机法也根据后端机器的配置，系统的负载分配不同的权重。不同的是，它是按照权重随机请求后端服务器，而非顺序。源地址哈希法：根据获取客户端的IP地址，通过哈希函数计算得到一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。最小连接数法：由于后端服务器的配置不尽相同，对于请求的处理有快有慢，最小连接数法根据后端服务器当前的连接情况，动态地选取其中当前积压连接数最少的一台服务器来处理当前的请求，尽可能地提高后端服务的利用效率，将负责合理地分流到每一台服务器。

>摘要：GaussDB使用cgroup实现了两种cpu管控能力，基于cpu.shares的共享配额管控和基于cpuset的专属限额管控。 本文分享自华为云社区《[GaussDB(DWS)的CPU资源隔离管控能力【这次高斯不是数学家】](https://bbs.huaweicloud.com/blogs/355346?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)》，作者：门前一棵葡萄树。 # 一、cgroup概述 cgroup全称control group，是linux内核提供的用于对进程/线程使用的资源进行隔离、管控以及记录的组件。 相关概念： 1. 任务（task）：对应系统中的一个进程/线程； 2. 控制组（control group）：进行资源限制隔离的基本单位，一个任务加入到控制组任务列表（tasks）后即受控制组资源控制，支持在线将一个任务从一个控制组迁移到另外一个控制组。 3. 层级（hierarchy）：控制组是一种树形结构，一个父控制组可以有多个子控制组，一个子控制组只能属于一个父控制组。同属一个父控制组的子控制组间按照资源配置进行资源争抢、隔离，子控制组继承父控制组的资源配置。 4. 子系统（subsytem）：一个子系统对应一种资源的资源控制器，比如CPU子系统是控制CPU时间分配的控制器，CPUSET子系统是控制CPU核分配的控制器。 cgroup主要子系统介绍： 1. cpu子系统：限制任务的cpu使用率； 2. cpuacct 子系统：统计cgroup中所有任务使用cpu的累积信息，单位ns； 3. cpuset子系统：限制任务能够使用的cpu核； 4. memory子系统：限制任务的memory使用； 5. blkio子系统：限制任务磁盘IO； 这里我们着重介绍GaussDB应用到的cgroup子系统，涉及的子系统包括：cpu子系统、cpuacct 子系统以及cpuset子系统。 ## 1.1 cgroup文件系统 VFS (Virtual File System) 虚拟文件系统是系统内核非常强大的一个功能，它把文件系统的具体实现细节隐藏起来，给用户态进程提供一个统一的文件系统API接口。cgroup的接口操作也是基于VFS实现的，可以通过mount命令查看cgroup挂载信息，每个目录对应cgroup的一个子系统。  ### 1.1.1 cpu & cpuacct 子系统 cpu子系统和cpuacct子系统相辅相成，cpu子系统限制cgroup使用的cpu时间，cpuacct统计cgroup使用的cpu时间，同时cpu子系统与cpuacct子系统挂载路径一致，因此可以把这两个子系统放在一起讨论：  **tasks** tasks记录着关联到该cgroup的任务（进程/线程）pid，只有加入tasks的任务才受cgroup控制。 cpu子系统用于控制cgroup中所有任务可以使用的cpu时间，主要包含以下几个接口： **cpu.cfs_period_us & cpu.cfs_quota_us** cfs_period_us 与cfs_quota_us 需要组合使用，cfs_period_us用来配置进行cpu限制的单位时间周期，cfs_quota_us用来配置在设置的时间周期内所能使用的CPU时间。二者单位都是微秒（us），cfs_period_us的取值范围为1毫秒（ms）到1秒（s），cfs_quota_us的取值大于1ms即可，如果cfs_quota_us的值为-1（默认值），表示不受cpu周期的限制。举例说明： ``` 1. 限制只能使用1个CPU（每100ms能使用100ms的CPU时间，即可以使用一个cpu） # echo 100000 > cpu.cfs_quota_us /* quota = 100ms */ # echo 100000 > cpu.cfs_period_us /* period = 100ms */ 2. 限制使用3个CPU（内核）（每100ms能使用300ms的CPU时间，即可以使用两个cpu） # echo 300000 > cpu.cfs_quota_us /* quota = 300ms */ # echo 100000 > cpu.cfs_period_us /* period = 100ms */ 3. 限制使用1个CPU的30%（每100ms能使用30ms的CPU时间，即可以使用30%的cpu） # echo 30000 > cpu.cfs_quota_us /* quota = 30ms */ # echo 100000 > cpu.cfs_period_us /* period = 100ms */ ``` **cpu.shares** shares用来设置cgroup中任务CPU可用时间的相对比例，针对所有可用cpu，默认值是1024，在cpu出现满负载争抢时，各控制组按照shares设置的相对比例争抢cpu。假如系统中有两个cgroup，分别是A和B，A的shares值是10000，B的shares值是20000，那么A和B出现cpu争抢时A将获得10000/(10000+20000)=33.3%的CPU资源，而B将获得66.7%的CPU资源。shares作为一种共享配额的cpu管控方式，具备以下几个特点： - cpu空闲情况下，shares不起作用，只有在cpu出现满负载争抢时，各控制组任务才按照shares配置比例争抢cpu - 空闲cpu其他控制组可以使用，如果A没有使用到33.3%的cpu时间，那么剩余的cpu时间将会被分配给B，即B的CPU使用率可以超过66.7% - 如果添加了一个新的控制组C，且它的shares值是10000，那么A的配额比例变成10000/(10000+20000+10000)=25%，B的cpu配额比例变成50% - 由于shares是一个权重值，需要和其它控制组的权重值进行对比才能得到自己的配额比例，在一个负载多变的环境上，cgroup数量和权重可能是多变的，这样给cgroup配置的配额比例，可能因为增加cgroup或修改其他cgroup权重导致该cgroup配额比例发生变化，无法精确控制cpu使用率。 **cpu.stat** stat包含以下三项统计结果 - nr_periods： 表示经历了多少个cpu.cfs_period_us里面配置的时间周期 - nr_throttled： 在上面的这些周期中，有多少次cpu受到了限制（即cgroup中的进程在指定的时间周期中用光了它的配额） - throttled_time: cgroup中的进程被限制使用CPU持续了多长时间(纳秒) **cpu.rt_runtime_us & cpu.rt_period_us** rt_runtime_us与rt_period_us组合使用可以对cgroup中的实时调度任务进行cpu时间限制，只可用于实时调度任务。rt_period_us用来配置进行cpu限制的单位时间周期，设置每隔多久cgroup对cpu资源的存取进行重新分配，rt_runtime_us用来配置在设置的时间周期内任务对cpu资源的最长连续访问时间，二者单位都是微秒（us）。 cpuacct（cpu accounting）子系统用于统计cgroup中任务所使用的cpu时间，主要包含以下接口： **cpuacct.usage** 统计cgroup中所有任务使用的cpu时间，单位ns，可以通过写入0值重置统计信息 **cpuacct.usage_percpu** 统计cgroup中所有任务在每个cpu核上使用的cpu时间，单位ns **cpuacct.stat** 统计cgroup中所有任务使用的用户态和系统态cpu时间，单位USER_HZ，格式如下： - user：cgroup中所有任务使用的用户态cpu时间 - system：cgroup中所有任务使用的内核态cpu时间 ### 1.1.2 cpuset 子系统 cpuset子系统可以为cgroup分配专属的cpu核和内存节点，cgroup中所有任务只能运行在分配的cpu和内存节点上。GaussDB仅应用了cpuset子系统的cpu控制能力，因此我们这里仅介绍cpu相关控制接口。 **cpuset.cpus** 设置cgroup中任务可以使用的cpu，使用小横线‘-’设置连续cpu，不连续cpu之间使用逗号‘,’分隔。例如：0-1,11-12,17 表示cgroup可以使用cpu 0、1、11、12、17。 **cpuset.cpu_exclusive** 包含标签0和1，可以控制其他cpuset及其父子cpuset是否可以共享该cpuset的cpu，默认值为0，cpu不会专门分配给某个cpuset。 **cpuset.sched_load_balance** 包含标签0和1，设定内核是否可以在该cpuset的cpu上进行负载均衡，默认值1，表示内核可以将超载cpu上的任务移动至低负载cpu上以平衡负载。 注意：如果父cgroup启用了负载均衡，则其所有子cgroup默认开启负载均衡，因此如果要禁用cgroup的负载均衡，则其所有上层cgroup都需要关闭负载均衡，同时需要考虑其他同层cgroup是否能够关闭负载均衡。 **cpuset.sched_relax_domain_level** 表示内核进行负载均衡的策略，如果禁用负载均衡则该值无意义。不同系统框架下，该值意义可能不同，以下为常用值的含义：  # 二、GaussDB的cpu管控 GaussDB支持两种cpu管控能力，基于cpu.shares的共享配额管控和基于cpuset的专属限额管控。在介绍GaussDB的cpu管控之前，我们首先介绍GaussDB中的cgroup结构。 ## 2.1 GaussDB的cgroup层级模型 GaussDB的cpu管控需要考虑其他进程与GaussDB之间的cpu管控，GaussDB内核后台线程与用户线程之间的cpu管控，用户之间的cpu管控。为了应对不同层级的cpu隔离管控需求，GaussDB设计了基于cgroup层级特点的cpu分层隔离管控，GaussDB的cgroup层级模型如下图所示：  以上cgroup均适配了cpu子系统和cpuset子系统，每一个cgroup都包含两个值：cpu.shares和cpuset.cpus。GaussDB借助cgroup提供了三个维度的cpu隔离管控能力： 1. GaussDB与其他进程之间的隔离管控 2. 数据库常驻后台线程与作业线程的隔离管控 3. 数据库用户之间的隔离管控 **GaussDB与其他进程之间的隔离管控** 数据库集群的每个节点在cgroup的cpu子系统和cpuset子系统内均包含一个专属目录：“GaussDB:gaussdba”，作为GaussDB的主cgroup节点（目录），用于限制和记录GaussDB内所有线程使用的cpu，GaussDB进程内所有线程均直接或间接的受到该cgroup的限制。通过限制GaussDB内核使用的cpu，可防止数据库系统对其他应用程序造成影响。 **数据库常驻后台线程与作业线程的隔离管控** GaussDB主cgroup节点之下包含两个cgroup：Backend控制组和Class控制组。Backend控制组用于GaussDB常驻后台线程的cpu隔离管控，Class控制组用于作业线程的cpu隔离管控。大部分后台常驻线程cpu资源占用较少，但AutoVacuum线程cpu资源占用可能较多，因此在Backend控制组单独提供Vacuum控制组用于AutoVaccum线程的cpu资源限制，而除AutoVacuum之外的其他后台常驻线程均受到DefaultBackend控制组的cpu资源限制。 **数据库用户之间的隔离管控** 通常情况下数据库系统会同时运行多种类型的作业，不同类型作业之间可能出现cpu资源争抢。GaussDB资源管理为用户提供了双层的cgroup层级结构用于cpu隔离管控，用户可按需创建和修改cgroup配置实现不同类型作业之间的cpu资源限制。用户双层cgroup包含以下控制组： - UserClass控制组：用户创建的父控制组，主要实现cpu资源的初步划分，如：不同的父控制组可以属于不同的部门/分公司 - RemainWD控制组：包含UserClass控制组创建UserWD控制组后剩余的cpu资源 - Timeshare控制组：创建UserClass控制组时默认创建的优先级控制组，包含四个优先级的控制组：Rush:High:Medium:Low，资源配比为：8:4:2:1 - UserWD控制组：用户创建的子控制组，在父控制组基础上实现cpu资源的细粒度划分，如：不同的子控制组可以属于同一部门下的不同类型作业 ## 2.2 GaussDB作业的cpu管控 数据库系统中运行多种类型作业出现cpu争取时，不同用户可能有不同的诉求，主要诉求如下： 1. 实现cpu资源的充分利用，不在意单一类型作业的性能，主要关注cpu整体吞吐量 2. 允许一定程度的cpu资源争抢和性能损耗，在cpu空闲情况下实现cpu资源充分利用，在cpu满负载情况下希望各类型按比例使用cpu 3. 部分作业对性能敏感，不在意cpu资源的浪费 对于第一种诉求，不建议进行用户之间的cpu隔离管控，不管控哪一种的cpu管控都或多或少的对cpu整体使用率产生影响；对于第二种诉求可以采用基于cpu.shares的共享配额管控方式，实现满负载cpu隔离管控前提下尽量提高cpu整体使用率；对于第三种诉求可以采用基于cpuset.cpus的专属限额管控方式，实现不同类型作业之间的cpu绝对隔离。下面对这两种作业cpu管控方式进行简要介绍，具体细节和使用中的疑问，我们后面文章再详细介绍，用兴趣的朋友也可以自己动手实验。 ### 2.2.1 CPU的共享配额管控 共享配额有两层含义： 共享：cpu是所有控制组共享的，空闲的cpu资源其他控制组能够使用 配额：业务繁忙cpu满负载情况下，控制组之间按照配额比例进行cpu抢占 共享配额基于cpu.shares实现，通过上面cgroup的介绍我们可知这种管控方式只有在cpu满负载情况下生效，因此在cpu空闲情况下并不能保证控制组能够抢占到配额比例的cpu资源。cpu空闲是不是可以理解为没有cpu资源争抢，控制组内任务可以任意使用cpu，因此不会有性能影响呢？答案是错误的，虽然cpu平均使用率可能不高，但是某个特定时刻还是可能存在cpu资源争抢的。示例： 10个cpu上运行10个作业，每个cpu上运行一个作业，这种情况下各作业在任意时刻请求cpu都可以瞬间得到响应，作业之间没有任何cpu资源的争抢；但是假如10个cpu上运行20个作业，因为作业不会一直占用cpu，在某些时间可能等待IO、网络等，因此cpu使用率可能并不高，此时cpu资源看似空闲，但是在某个时刻可能出现2~N作业同时请求一个cpu的情况出现，此时即会导致cpu资源争抢，影响作业性能。 通过测试验证，在cpu满负载情况下，控制组之间基本可以按照配额比例占用cpu，实现cpu资源的配额管控。 ### 2.2.2 CPU的专属限额管控 专属限额有两层含义： 专属：cpu是某个控制组专属的，空闲的cpu资源其他控制组不能使用 限额：只能使用限额配置的cpu资源，其他控制组空闲的cpu资源，也不能抢占 专属限额基于cpuset.cpus实现，通过合理的限额设置可以实现控制组之间cpu资源的绝对隔离，各控制组间任务互不影响。但是因为cpu的绝对隔离，因此在控制组空闲时就会导致cpu资源的极大浪费，因此限额设置不能太大。那从作业性能来看是不是限额越大越好呢？答案是不完全正确，示例： 假设10个作业运行在10个cpu上，cpu平均使用率5%左右；10个作业运行在5个cpu上，cpu平均使用率10%左右。通过上面共享配额的性能分析我们可知：虽然10个作业运行在5个cpu上cpu使用率很低，看似空闲，但是相对10个作业运行在10个cpu上还是存在某种程度的cpu资源争抢的，因此10个作业运行在10个cpu上性能要好于运行在5个cpu上。那是不是越多越好呢？10个作业运行在20个cpu上，在任意一个时刻，总会至少10个cpu是空闲的，因此理论上10个作业运行在20个cpu上并不会比运行在10个cpu上性能更好。 因此我们可以得知，对于并发为N的控制组，分配cpus小于N的情况下，cpu越多作业性能越好；但是当分配cpus大于N的情况下，性能就不会有任何提升了。 ### 2.2.3 共享配额与专属限额对比 cpu共享配额和专属限额的管控方式各有优劣，共享配额能够实现CPU资源的充分利用，但是各控制组之间资源隔离不彻底，可能影响查询性能；专属限额的管控方式可以实现cpu资源的绝对隔离，但是在cpu资源空闲时会造成cpu资源的浪费。相对专属限额来说，共享配额拥有更高的cpu使用率和更高的整体作业吞吐量；相对共享配额来说，专属限额cpu隔离彻底，更满足性能敏感用户的使用诉求。 从上面GaussDB的cgroup层级结构我们得知，用户cgroup是包含父子两层控制的，那可不可以父控制组一层使用专属限额，而子控制组一层使用共享配额呢？答案是肯定的，另外同一层控制组也可以同时有使用专属限额和共享配额的控制存在。具体使用本文不做介绍，有兴趣的可以自己试验。

序言Nginx的代理功能与负载均衡功能是最常被用到的，关于nginx的基本语法常识与配置已在Nginx 配置详解中有说明，这篇就开门见山，先描述一些关于代理功能的配置，再说明负载均衡详细。Nginx 代理服务的配置说明1、设置 404 页面导向地址error_page 404 https://www.runnob.com; #错误页proxy_intercept_errors on; #如果被代理服务器返回的状态码为400或者大于400，设置的error_page配置起作用。默认为off。2、如果我们的代理只允许接受get，post请求方法的一种proxy_method get; #支持客户端的请求方法。post/get；3、设置支持的http协议版本proxy_http_version 1.0 ; #Nginx服务器提供代理服务的http协议版本1.0，1.1，默认设置为1.0版本4、如果你的nginx服务器给2台web服务器做代理，负载均衡算法采用轮询，那么当你的一台机器web程序iis关闭，也就是说web不能访问，那么nginx服务器分发请求还是会给这台不能访问的web服务器，如果这里的响应连接时间过长，就会导致客户端的页面一直在等待响应，对用户来说体验就打打折扣，这里我们怎么避免这样的情况发生呢。这里我配张图来说明下问题。如果负载均衡中其中web2发生这样的情况，nginx首先会去web1请求，但是nginx在配置不当的情况下会继续分发请求道web2，然后等待web2响应，直到我们的响应时间超时，才会把请求重新分发给web1，这里的响应时间如果过长，用户等待的时间就会越长。下面的配置是解决方案之一。proxy_connect_timeout 1; #nginx服务器与被代理的服务器建立连接的超时时间，默认60秒proxy_read_timeout 1; #nginx服务器想被代理服务器组发出read请求后，等待响应的超时间，默认为60秒。proxy_send_timeout 1; #nginx服务器想被代理服务器组发出write请求后，等待响应的超时间，默认为60秒。proxy_ignore_client_abort on; #客户端断网时，nginx服务器是否终端对被代理服务器的请求。默认为off。5、如果使用upstream指令配置啦一组服务器作为被代理服务器，服务器中的访问算法遵循配置的负载均衡规则，同时可以使用该指令配置在发生哪些异常情况时，将请求顺次交由下一组服务器处理。proxy_next_upstream timeout; #反向代理upstream中设置的服务器组，出现故障时，被代理服务器返回的状态值。状态值可以是：error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|offerror：建立连接或向被代理的服务器发送请求或读取响应信息时服务器发生错误。timeout：建立连接，想被代理服务器发送请求或读取响应信息时服务器发生超时。invalid_header:被代理服务器返回的响应头异常。off:无法将请求分发给被代理的服务器。http_400，....:被代理服务器返回的状态码为400，500，502，等。6、如果你想通过http获取客户的真实ip而不是获取代理服务器的ip地址，那么要做如下的设置。proxy_set_header Host $host; #只要用户在浏览器中访问的域名绑定了 VIP VIP 下面有RS；则就用$host ；host是访问URL中的域名和端口 www.taobao.com:80proxy_set_header X-Real-IP $remote_addr; #把源IP 【$remote_addr,建立HTTP连接header里面的信息】赋值给X-Real-IP;这样在代码中 $X-Real-IP来获取 源IPproxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;#在nginx 作为代理服务器时，设置的IP列表，会把经过的机器ip，代理机器ip都记录下来，用 【，】隔开；代码中用 echo $x-forwarded-for |awk -F, '{print $1}' 来作为源IP关于X-Forwarded-For与X-Real-IP的一些相关文章可以查看：HTTP 请求头中的 X-Forwarded-For 。7、下面是我的一个关于代理配置的配置文件部分，仅供参考。include mime.types; #文件扩展名与文件类型映射表default_type application/octet-stream; #默认文件类型，默认为text/plain#access_log off; #取消服务日志 log_format myFormat ' $remote_addr–$remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for'; #自定义格式access_log log/access.log myFormat; #combined为日志格式的默认值sendfile on; #允许sendfile方式传输文件，默认为off，可以在http块，server块，location块。sendfile_max_chunk 100k; #每个进程每次调用传输数量不能大于设定的值，默认为0，即不设上限。keepalive_timeout 65; #连接超时时间，默认为75s，可以在http，server，location块。proxy_connect_timeout 1; #nginx服务器与被代理的服务器建立连接的超时时间，默认60秒proxy_read_timeout 1; #nginx服务器想被代理服务器组发出read请求后，等待响应的超时间，默认为60秒。proxy_send_timeout 1; #nginx服务器想被代理服务器组发出write请求后，等待响应的超时间，默认为60秒。proxy_http_version 1.0 ; #Nginx服务器提供代理服务的http协议版本1.0，1.1，默认设置为1.0版本。#proxy_method get; #支持客户端的请求方法。post/get；proxy_ignore_client_abort on; #客户端断网时，nginx服务器是否终端对被代理服务器的请求。默认为off。proxy_ignore_headers "Expires" "Set-Cookie"; #Nginx服务器不处理设置的http相应投中的头域，这里空格隔开可以设置多个。proxy_intercept_errors on; #如果被代理服务器返回的状态码为400或者大于400，设置的error_page配置起作用。默认为off。proxy_headers_hash_max_size 1024; #存放http报文头的哈希表容量上限，默认为512个字符。proxy_headers_hash_bucket_size 128; #nginx服务器申请存放http报文头的哈希表容量大小。默认为64个字符。proxy_next_upstream timeout; #反向代理upstream中设置的服务器组，出现故障时，被代理服务器返回的状态值。error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off#proxy_ssl_session_reuse on; 默认为on，如果我们在错误日志中发现“SSL3_GET_FINSHED:digest check failed”的情况时，可以将该指令设置为off。Nginx 负载均衡详解在文章Nginx 配置详解中我说啦nginx有哪些中负载均衡算法。这一结我就给如何操作配置的给大家做详细说明下。首先给大家说下upstream这个配置的，这个配置是写一组被代理的服务器地址，然后配置负载均衡的算法。这里的被代理服务器地址有两种写法。upstream mysvr { server 192.168.10.121:3333; server 192.168.10.122:3333;}server { .... location ~*^.+$ { proxy_pass http://mysvr; #请求转向mysvr 定义的服务器列表 }}然后，就来点实战的东西。1、热备：如果你有2台服务器，当一台服务器发生事故时，才启用第二台服务器给提供服务。服务器处理请求的顺序：AAAAAA突然A挂啦，BBBBBBBBBBBBBB.....upstream mysvr { server 127.0.0.1:7878; server 192.168.10.121:3333 backup; #热备 }2、轮询：nginx默认就是轮询其权重都默认为1，服务器处理请求的顺序：ABABABABAB....upstream mysvr { server 127.0.0.1:7878; server 192.168.10.121:3333; }3、加权轮询：跟据配置的权重的大小而分发给不同服务器不同数量的请求。如果不设置，则默认为1。下面服务器的请求顺序为：ABBABBABBABBABB....upstream mysvr { server 127.0.0.1:7878 weight=1; server 192.168.10.121:3333 weight=2;}4、ip_hash:nginx会让相同的客户端ip请求相同的服务器。upstream mysvr { server 127.0.0.1:7878; server 192.168.10.121:3333; ip_hash;}5、如果你对上面4种均衡算法不是很理解，可以查看Nginx 配置详解，可能会更加容易理解点。到这里你是不是感觉nginx的负载均衡配置特别简单与强大，那么还没完，咱们继续哈，这里扯下蛋。关于nginx负载均衡配置的几个状态参数讲解。down，表示当前的server暂时不参与负载均衡。backup，预留的备份机器。当其他所有的非backup机器出现故障或者忙的时候，才会请求backup机器，因此这台机器的压力最轻。max_fails，允许请求失败的次数，默认为1。当超过最大次数时，返回proxy_next_upstream 模块定义的错误。fail_timeout，在经历了max_fails次失败后，暂停服务的时间。max_fails可以和fail_timeout一起使用。upstream mysvr { server 127.0.0.1:7878 weight=2 max_fails=2 fail_timeout=2; server 192.168.10.121:3333 weight=1 max_fails=2 fail_timeout=1; }到这里应该可以说nginx的内置负载均衡算法已经没有货啦。如果你像跟多更深入的了解nginx的负载均衡算法，nginx官方提供一些插件大家可以了解下。原文地址：https://www.cnblogs.com/knowledgesea/p/5199046.html

客户端在连接服务器时，首先会访问负载均衡服务器LVS，负载均衡服务器将连接按照一定的算法分发到各个CN上，从而实现业务的负载均衡2 LVS日志路径lvs安装日志：/var/log/Bigdata/mpp/omm/om/gs_loadbalance-xxxx-xx-xx_xxxxx.log 主备lvs节点lvs运行日志：安装lvs节点的系统日志/var/log/messsges3 常见问题处理思路 3.1 安装lvs报错 解决思路：查看报错信息，提示系统版本不支持(如果是suse12.3系统，最新补丁已修改)，需要查看产品文档看系统是否支持当前版本。如果所选虚拟ip和主备节点不在同一网段，也会报所选虚拟ip和当前节点不在同一网段，需要重新选择虚拟ip，所选虚拟ip必须和主备节点、cn节点ip在同一网段。 3.2 安装报写入文件权限不足 解决思路：询问现网操作系统是否做过安全加固，如果做过，需要先消除安全加固后再安装LVS。 3.3 ipvsadm -Ln显示没有CN信息 解决思路： 1）查看/etc/keepalived/keepalived.conf中的real_server块，是否包含各节点cn。 2）如果a步骤正常，查看cn的配置文件，conf里是否包含cn的大小网ip（如果现网是双网卡），不包含则需添加大网或者小网ip到listen_addresses里，再killcn进程使其生效。    3）1、2步骤均正常，查看keepalived信息，ps -ef | grep keepalived,如果显示三个keepalived进程号说明keepalived运行正常，如果只有一个或者两个，说明keepalived进程异常，主进程异常退出，只留下子进程，此时需要kill 剩余进程，执行以下命令重启keepalived进程。  /etc/inid.d/gs_keepalived stop; /etc/inid.d/gs_keepalived start3.4 客户端连接gsql报错 解决思路：是否将客户端ip加入到白名单，未加入则添加后重试，已加入则先检查3.3步骤并排查，查看客户端ip是否和LVS虚拟ip在同一网段，如果不在同一网段，需找和LVS虚拟ip在同一网段的客户端机器重新连接（客户端机器必须是集群外的一台机器）3.5 客户端连接lvs不轮询 解决思路： 1）查看系统日志/var/log/messages,查找Keepalived关键字，如果大量刷如下日志：ip address associated with 51 not present in received packet : 虚ip地址说明LVS的virtual_router_id冲突，需要修改主备节点/etc/keepalived/keepalived.conf中的virtual_router_id，主备节点取值一样，和之前的值不同，取值0-255.    2）LVS主备节点的iptables是否挂载。执行iptables -t mangle --list查看是否有mac地址，主节点的mac地址必须是备机和LVS同一网段ip网卡的mac地址，备节点的mac地址必须是主节点和LVS同一网段ip网卡的mac地址，如果发现不一致，先执行iptables -t mangle –F清理，再重新执行如下命令：iptables -t mangle -I PREROUTING -p tcp -m tcp -d $VIP --dport $VPORT -m mac ! --mac-source $MAC_Director_B -j MARK --set-mark 0x1 注意：主机添加备机mac地址，备机添加主机mac地址，网卡地址必须是LVS同一网段的网卡，执行完成后添加到开机启动项。3.6  交换机上连接主 lvs 节点的端口配置了 IPSG 安全功能，该功能会检测 ip 和 mac 的绑定关系，虚拟 ip 不能通过除主 lvs 的 cn 返回数据包解决思路：关闭 IPSG 功能即可3.7  系统日志显示不停的刷 LVS 主备切换解决思路：查看 root 下的定时任务 ， 是否有重启 LVS 的脚本存在 ， 如果是主备从集群 ， 删除此定时任务 。 一主多备多 AZ 场景才会部署该定时任务 。3.8  如果指定的虚拟 ip 不是和集群 xml 在同一网段的 ip ， ( 即 xml 里用的是业务 ip ， lvs 的虚拟 ip 用的是管理 ip) ，那么 keepalived.conf 中就不会写进去 real_server ，解决思路： 如果需要使用管理 ip ，那么就需要手动配置 keepalived.conf 和 CN 节点的 postgresql.conf 文件。3.9  武汉安装 lvs 现场问题根因分析：使用的是 R6C10 的版本，因为版本太过陈旧，接口都不一样，好多的配置文件都是手动配置，导致资料不全，安装 lvs 的时候，将虚拟 ip 写进 cn 的postgresql.conf 中导致重启集群失败，最后找到原因是在 cn 上，没有 gs_vip 这个脚本，手动配置好之后，启动 gs_vip 的脚本，重启集群成功。3.10  客户端gsql的版本要和cn节点的gsql版本相同，否则可能导致连接不上4  手动部署lvs在suse操作系统上需要关注的地方LVS 主备节点需要做的事：1.cp .ko 文件 到 /lib/modules/uname -r/kernel/net/netfilter2. 配置 /lib/modules/uname -r/modules.dep 和 /etc/modprobe.d/unsupported-modules3.modprobe 导入 ko4.cp ipvsadm 和 keepalived 到 /sbin 下5.cp keepalived.conf 到 /etc/keepalived 下,并修改6.cp keepalived.sh 到/etc/init.d/并配置自启动安装gs_loadbalance的前提约束条件1. 在集群安装好的前提下才能安装 LVS 服务。2. 建议在 LibrA 集群中选择两个没有部署 CN 的主机作为 LVS 主、备服务器。原因：如果安装在两台带 CN 的服务器上，配置负载均衡时不能将这两个 CN 作为 LVS 转发的服务器。如果配置了，客户端的部分连接会丢失 ( 由于备 CN 上的 LVS 服务器接收到连接后也会产生一次新的转发，当这个连接被转发到 LVS 主机上时，主机将再次转发给备机造成循环，最后客户端超时退出。3. 当 LibrA 集群使用混合操作系统时，请为 LVS 主、备选择操作系统一致的服务器。如果操作系统版本号无法完全一致，则请至少保证大版本相同。4. 要求客户端和服务器需要在同一个网段。如果集群中使用虚拟机时，虚拟机网络如果无法使用虚拟 IP ，则无法使用负载均衡。5.LVS 主备机需要绑定的网卡上不能绑定其他虚拟 IP 。6.LVS 服务器工作在内核态， keepalived 软件使用 API 调用 LVS 内核接口，因此与 LVS+Keepalived 的设置均需要在 root 权限下执行。7.lvs 指定的虚拟 IP 必须是没被使用的虚拟 IP （ ping 不通而且不是集群信息的 IP ），虚拟 ip 必须和集群信息的 ip 在同一网段，安装成功后可以 ping 通如果 xml 集群中 CN 配置的 listenIP 是业务 ip ，那么虚拟 IP 地址必须与业务 IP 在同一网段。命令： ping 10.146.175.222 -i 1 -c 3 | grep -E '' | wc -l8. 需要在每个 CN 节点上执行 gs_loadbalance 安装命令（在 lvs 主备上也要执行）9. 可以部署一主一备或者一主 ,LVS 主和备在集群内 , 需要在当前节点安装。10. 负载均衡本身不支持升级操作，如果需要升级负载均衡，则需要卸载后再安装新版本负载均衡；负载均衡不支持集群的升级，即集群升级后负载均衡不会随着升级。11. 在集群使用混合操作系统时不支持使用负载均衡。12. 不能在 LVS 的主备节点上通过 gsql 客户端或 JDBC/ODBC 接口去访问 LVS 配置的虚拟 IP ，下发数据库操作13.LVS 服务器当主机故障时（ keepalived 软件异常退出、主机宕机、掉电等），备机会自动接 管浮动 IP ，但是当前所有与主机相连的连接会断开，再次发起时可以重新连接。14. 使用负载均衡时各个 CN 在各个物理机上需要配置相同的端口号 , 一台物理机只能配置一个 C 。15. 通过在 SUSE 和 Redhat 上实验发现 SUSE 上如果没有安装 lsb_release ，那么第一次安装 lvs 会成功，卸载 lvs 会失败，而 Redhat 系统，安不安装 lsb_release ，负载均衡都会安装和卸载成功， 还有一个问题，如果主机名在安装 lvs 后发生改变，那么卸载后第二次安装就会出现 lvs 组件没有安装进去的现象，但是不会报错，解决办法是修改 /etc/hostname 里面的主机名，使 其与该机器的主机名保持一致，并且与 /proc/sys/kernel/hostname 里的主机名保持一致，也要和安装集群的 xml 里的主机名保持一致。LVS 网络问题定位1、进行抓包查看是否有数据包通过端口tcpdump host VIP and port 8080 -X -vv注意：集群在修改 CN 下的 postgresql.conf 文件之后，都要重启集群（ gs_om - t stop /gs_om -t start 或者杀死 CN 进程会自动重启）ps aux | grep coordinatorkill -9 进程号安装成功以后查看以下命令：ip addr 命令查看 lo 网卡上面绑定了 lvs 虚拟 ip ，当前使用的 lvs 节点的业务 ip 上面也绑定2、分析 cpu 性能top ：按 1 可以看到每个 cpu 核的 cpu 使用情况，同时还能看到各个进程的情况。sar -u 1 ：每隔 1 秒打印出当前 cpu 的整体使用情况。mpstat -P ALL 1 ：每隔 1 秒打印出所有 cpu 核的使用情况。ps ： sar 和 mastat 需要安装 sysstat 工具包。3、. 分析网卡流量sar -n DEV 1 ：每隔 1 秒打印出所有网卡的流量传输情况。4、查看网卡配置ethtool xxx系统参数优化关闭网卡 LRO 和 GRO 现在大多数网卡都具有 LRO/GRO 功能，即 网卡收包时将同一流的小包合并成大包 （ tcpdump 抓包可以看到 >MTU 1500bytes 的数据包）交给 内核协议栈； LVS 内核模块在处理 >MTU 的数据包时，会丢弃； 因此，如果我们用 LVS 来传输大文件，很容易出现丢包，传输速度慢； 解决方法，关闭 LRO/GRO/TSO/GSO 功能，命令： 查看 bond 网卡使用的物理网卡ifconfig|grep `ifconfig|grep "bond0"|awk '{print $NF}'`|awk '{print $1}'ethtool -k eth0 查看 LRO/GRO 当前是否打开ethtool -K bond0 lro off gro off tso off gso off  关闭bond网卡lro/gro/tso/gso参数ethtool -K bond0 lro on gro on tso on gso on  打开bond网卡lro/gro/tso/gso参数https://wenku.baidu.com/view/4451846901f69e314332946a.htmlTSO、GSO、LRO、GRO参数说明- TSO:使用 TCP 协议发送大数据包。使用 NIC 处理分段，然后将 TCP ， IP 和数据链路层协议标头添加到每个分段。- GSO:使用 TCP 或 UDP 协议发送大数据包。如果 NIC 无法处理分段 / 分段，则 GSO 将绕过 NIC 硬件执行相同的操作。这是通过将分段延迟到尽可能晚的时间来实现的，例如，当设备驱动程序处理数据包时。- LRO:使用 TCP 协议。所有传入的数据包在接收时都被重新分段，从而减少了系统必须处理的分段数量。它们可以在驱动程序中或使用 NIC 合并。 LRO 的问题在于，它倾向于重新分段所有传入的数据包，通常会忽略标头和其他可能导致错误的信息的差异。启用 IP 转发后，通常无法使用 LRO 。 LRO 与 IP 转发结合使用会导致校验和错误。如果 /proc/sys/net/ipv4/ip_forward 设置为 1 ，则启用转发。- GRO:GRO(Generic Receive Offload) 是LRO的增强版，对skb merge的限制更多，同时不限于tcp/ip，GRO 是 LRO 的一种软件实现。 某些设备设置可能会列为 fixed ，表示无法更改。- MSS 是 TCP 数据包每次能够传输的最大数据分段。MSS=TCP 报文段长度 -TCP 首部长度。查看连接CN的SQL 语句 ：创建用户名为 jack 密码为 Gaussdba@Mpp 的用户gs_guc set -Z coordinator -N all -I all -h "host all all 0.0.0.0/0 sha256" -------> 创建白名单CREATE USER jack PASSWORD 'Gaussdba@Mpp'; -------> 创建用户GRANT ALL PRIVILEGES TO jack; ---> 为 Jack 用户添加权限gsql -p 9500 -U jack -W test_123 -h vitual_ip -d postgres -r -c "show pgxc_node_name";如果已经登进去数据库那就直接用 select pgxc_node_str(); 这个命令原理： lvs 的虚拟 ip 转化为实际的 CN 的 ip 是在 gsql 连接过程中转换的，因为 parallel 实际是启多个 gsql 连接，所以只有是在连接过程中转换才能连接到不同的 CN 节点在双网卡下，使用大网可以部署集群，也可以用小网来部署集群，也可以部署 lvs ，一般是用小网来部署集群， down 掉小网网卡，来测试 lvs 的虚拟 ip 是否可以切换到备机上面，测试没有报错。gs_keepalived 脚本：condrestart 是 conditional restart 的意思，如果服务当前已经是运行的话，它可以重启这个服务，但是如果服务没有运行， condrestart 是无法启动这个服务的。而 restart 都可以。注意： keepalived.conf 的权限是 640 ，权限不对， gs_keepalived 脚本无法启动。查看系统内核 ipvs 模块的 .ko 文件find /lib/modules/$(uname -r)/ -iname "ip_vs*.ko*" | cut -d/ -f5-解决主备 lvs 在 CN 上安装出现的问题http://3ms.huawei.com/km/groups/8225/blogs/details/5954953开启 ip 转发vim /etc/sysctl.confnet.ipv4.ip_forward=1Keepalived.conf中一些配置项的说明 ：delay_loop ：健康检查的时间间隔。 service polling 的 delay 时间，即服务轮询的时间间隔connect_timeout ：连接超时时间。默认是 5spersistence_timeout 120 # 会话保持时间（秒为单位），即以用户在 120 秒内被分配到同一个后端 realserver当主负载均衡器宕机以后，备机提升为主，但备机缺省没有这些连接信息，会导致客户端的连接失效，为了解决这一问题， LVS 在 Linux 内核实现了同步连接信息的功能 .ipvsadm使用方法 ：ipvsadm -L --daemon 查看同步进程信息ipvsadm --start-daemon master|backup --mcast-interface= 网卡名称 --syncid 编号 , 主备需要一致ipvsadm --stop-daemon master|backup 停止同步ipvsadm -L -n -c 查看连接状态信息ipvsadm -Ln --stats | --rate--stats 和 --rate 统计在分析问题时经常用到，输出各项的含义：--stat 选项是统计自该条转发规则生效以来的包Conns (connections scheduled) 已经转发过的连接数InPkts (incoming packets) 入包个数OutPkts (outgoing packets) 出包个数InBytes (incoming bytes) 入流量（字节）OutBytes (outgoing bytes) 出流量（字节）--rate 选项是显示速率信息CPS (current connection rate) 每秒连接数InPPS (current in packet rate) 每秒的入包个数OutPPS (current out packet rate) 每秒的出包个数InBPS (current in byte rate) 每秒入流量（字节）OutBPS (current out byte rate) 每秒入流量（字节）集群卸载但LVS没执行卸载导致LVS虚拟ip残留，删除LVS的虚拟ip步骤 :在 LVS 主备节点上执行/etc/init.d/gs_keepalived stop/etc/init.d/gs_vip stoprm -rf /etc/init.d/gs_keepalived gs_viprm -rf /etc/keepalivedrm -rf /sbin/keepalived ipvsadmCN 节点上执行 /etc/init.d/gs_vip stoprm -rf /etc/init.d/gs_vip监测连接保持状态 (2s 刷新一次状态 ) [root@DR1 keepalived]# watch ipvsadm -L -n -c