前两天小编访问某个网站某个页面的时候，出现了下面这张图，于是小编就想弄明白Nginx究竟是什么，下面和伙伴们一起分享下。    Nginx的定义   Nginx(enginex)是一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP服务器。Nginx是由伊戈尔·赛索耶夫为俄罗斯访问量第二的Rambler.ru站点（俄文：Рамблер）开发的，第一个公开版本0.1.0发布于2004年10月4日。Nginx是一款轻量级的Web服务器，时常用于服务端的反向代理和负载均衡。它的内存占用少，启动极快，高并发能力强。    Nginx的应用   Nginx 可以作为静态页面的 web 服务器，同时还支持 CGI 协议的动态语言，比如 perl、php等。但是不支持 java。Java 程序只能通过与 tomcat 配合完成。Nginx 专为性能优化而开发，性能是其最重要的考量,实际上非常注重效率 ，能经受高负载的考验, Nginx 不仅可以实现动静分离、做反向代理，实现负载均衡。还能用作正向代理来进行上网等功能。动静分离：Nginx 服务器将接收到的请求分为动态请求和静态请求。静态请求直接从 nginx 服务器所设定的根目录路径去取对应的资源，动态请求转发给真实的后台去处理。正向代理：意思是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端才能使用正向代理。vpn是正向代理工具。反向代理：实际运行方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。负载均衡：在服务器集群中，Nginx 可以将接收到的客户端请求“均匀地”（严格讲并不一定均匀，可以通过设置权重）分配到这个集群中所有的服务器上。这个就叫做负载均衡。负载均衡具有分摊服务器集群压力、保证客户端访问的稳定性的作用。   Nginx的优点   Nginx专为性能优化而开发，性能是其最重要的考量,实现上非常注重效率 。它支持内核Poll模型，能经受高负载的考验,有报告表明能支持高达 50,000个并发连接数。Nginx具有很高的稳定性。其它HTTP服务器，当遇到访问的峰值，或者有人恶意发起慢速连接时，也很可能会导致服务器物理内存耗尽频繁交换，失去响应，只能重启服务器。例如当前apache一旦上到200个以上进程，web响应速度就明显非常缓慢了。而Nginx采取了分阶段资源分配技术，使得它的CPU与内存占用率非常低。nginx官方表示保持10,000个没有活动的连接，它只占2.5M内存，所以类似DOS这样的攻击对nginx来说基本上是毫无用处的。就稳定性而言,nginx比lighthttpd更胜一筹。Nginx支持热部署。它的启动特别容易, 并且几乎可以做到7*24不间断运行，即使运行数个月也不需要重新启动。你还能够在不间断服务的情况下，对软件版本进行进行升级。Nginx采用master-slave模型,能够充分利用SMP的优势，且能够减少工作进程在磁盘I/O的阻塞延迟。当采用select()/poll()调用时，还可以限制每个进程的连接数。Nginx代码质量非常高，代码很规范，手法成熟， 模块扩展也很容易。特别值得一提的是强大的Upstream与Filter链。Upstream为诸如reverse proxy,与其他服务器通信模块的编写奠定了很好的基础。而Filter链最酷的部分就是各个filter不必等待前一个filter执行完毕。它可以把前一个filter的输出做为当前filter的输入，这有点像Unix的管线。这意味着，一个模块可以开始压缩从后端服务器发送过来的请求，且可以在模块接收完后端服务器的整个请求之前把压缩流转向客户端。Nginx采用了一些os提供的最新特性如对sendfile (Linux2.2+)，accept-filter (FreeBSD4.1+)，TCP_DEFER_ACCEPT (Linux 2.4+)的支持，从而大大提高了性能。Nginx极具扩展性，它由多个不同功能、不同层次、不同类型且耦合度极高的模块组成，这种低耦合的设计，造就了它庞大的第三方模块。   智能云网   智能云网社区是华为专为开发者打造的“学习、开发、验证、交流”一站式支持与服务平台，该平台涵盖多领域知识。目前承载了云园区网络，云广域网络，数通网络开放可编程，超融合数据中心网络，数通网络设备开放社区共五个场景。为了响应广大开发者需求，还提供了开发者交流、API 体验中心、多媒体课件、SDK工具包、开发者工具以及远程实验室共六大工具，让开发者轻松开发。欢迎各位前来体验。>>戳我了解更多<<

1. 链路聚合基本概念    链路聚合（Link Aggregation），也称为端口捆绑，端口聚集或链路聚集。链路聚合是将多个端口聚合在一起形成一个汇聚组，以实现出/入负荷在各成员端口的负荷分担。从外面看起来，一个汇聚组好像就是一个端口。2. 绑定技术    将多块网卡虚拟成一块网卡，使其具有相同的ip地址，来实现提升主机的网络吞吐量或者是提高可用性，这种技术被称作bonding。3. bonding模式1> round-robin（mode = 0）轮转策略，轮流在每一个slave网卡上发送数据包，提供负载均衡和容错能力。2> active-backup（mode = 1）主备策略，只有一个slave被激活，只有当active的slave的接口down时，才会激活其它slave接口。3> XOR（mode = 2）基于所选择的hash策略，本模式也提供负载均衡和容错能力。4> broadcast（mode = 3）广播策略，向所有的slave接口发送数据包，本模式提供容错能力。5> 802.3ad（mode = 4）动态链路聚合，根据802.3ad标准利用所有的slave建立聚合链路。slave接口的出口取决于传输的hash策略，默认策略是简单的XOR策略，而hash策略则可以通过xmit_hash_policy选项配置。前提：每个slave网卡支持ethtool获取速率和双功状态，交换机支持IEEE 802.3ad标准（可能需要配置启用）IEEE 802.3ad是执行链路聚合的标准方法。6> balance-tlb（mode = 5）自适应传输负载均衡：根据每个slave的负载（相对速度）决定从哪个接口发送数据包，从当前接口接收数据包。如果接收的slave接口故障，其它slave接口将接管它的mac地址接续接收。前提：每个slave网卡支持ethtool获取速率。7> balance-alb（mode = 6）自适应负载均衡前提：每个slave网卡支持ethtool获取速率，每个slave网卡支持启用时重新设置硬件地址4. 动态链路聚合校验（mode = 4）    1> cat /proc/net/boning/bond0 | grep 'Aggregator ID' （具体环境不同可能路径不同）          正常链路聚合时两块网卡的Aggregator ID值应该相同，在故障节点上查询Aggregator ID值不同，则表示链路聚合协商不成功。图1. bond0中Active Aggregator ID：1图2. bond0中nic0 Aggregator ID：1图3. bond0中nic1 Aggregator ID：2         从以上查询发现3个Aggregator ID值不相同，判断动态链路聚合失败。    2> 从速率判断          oom或ruby用户执行ethtool bond0 （注：沙箱外执行）图4. Speed 为10000Mb/s          根据图4发现速率为10000Mb/s。目前DWS集群节点的bond模式均为mode 4，带宽应为两块网卡之和20000Mb/s，但是故障节点显示10000Mb/s，表示链路聚合不成功，节点是以单链路方式运行。5. 动态链路聚合脚本    见附件

读写分离读写分离是什么读写分离顾名思义，就是将读操作和写操作分离开来，形成一种主备的结构，主机负责写操作，从机负责读操作。openGauss数据库组装成集群并使用JDBC连接时，支持一主多备情况下的读写分离，当URL中配置服务器地址时，可以通过URL中的属性标示来区分JDBC返回的连接是否是区分主机和备机。优越特性自动寻主读写分离一定程度上依赖主机的识别，这里会介绍openGauss数据库的自动寻主机制。openGauss数据库应用场景下，典型配置为一主两备。当主机宕机后，备机会升主，这时和旧主机相连的连接都会失效，所以为了能够让业务以最快的速度恢复使用，我们在驱动层设计一种“自动寻主”的机制，该机制可以找到主备切换后的主机，并且整个寻主过程对于上层应用来说是透明的，上层应用的开发人员不需要自动寻主的具体细节，只需做上一定适配即可实现业务的高可用。性能提升对比PostgreSQL 的读写分离，PostgreSQL 在数据库资源占用超过85%时，查询数据库情况语句会出现失效，针对这一问题我们做了优化。查询语句修改为select local_role, db_state from pg_stat_get_stream_replications();有效的避免了PostgreSQL 在读写分离方面出现的问题。相关参数hostRecheckSeconds参数，Integer类型，因为JDBC尝试连接主机后会保存主机状态：连接成功或连接失败，所以这个参数就是用于设置在主机状态发生更改时再次检查主机状态的时间段，默认的时间是10秒。运作流程读写分离流程第一步，设置参数开启targetServerType=master。第二步，判断输入的主机列表是否已经加入了候选主机列表中，如果不存在hostStatusMap中并且更新时间间隔超过10s同时HostStatus状态也和现在一致，这时直接加入候选主机列表。第三步，对列表进行遍历查找对应的节点信息，如果找到了，通过konwnStatus查看状态是否一致，一致就执行sql查询语句，之后更新全局变量hostStatusMap及局部变量konwnStatus中存储。第四步，当前操作的节点状态如果与用户选择的节点状态一致则返回主机连接，之后用户可以根据连接进行读或者写操作。负载均衡jdbc负载均衡是什么jdbc负载均衡简单来说就是将所有的连接均衡的分摊到多个数据库上面，借此达到减轻单个数据库的数据处理压力从而提高整体的性能的一种方式。但是要注意一点，openGauss的负载均衡是能进行读操作使用，所以在只读时开启时是没有问题的，但如果有写操作的话，因为负载均衡不会考虑主备的区别，所以会让从机进行读操作，这时会报错。独有特性jdbc负载均衡负载均衡是现在很常用的均衡每个服务器性能的处理手段，像我们常见的Nginx的负载均衡，很少会有人在驱动上面直接进行负载均衡。从实际的效果的来看，在开启负载均衡后整体的性能并没有下降，但是因为连接打到了多个不同的数据库上面，整体的处理效率得到了显著的提升。虽然看上去和传统的负载均衡达到的效果差不多，但是对比传统的通过额外的一台机器做负载均衡比起来，我们有着独特的优势。首先我可以通过配置参数开启负载均衡并设置 我们想要的主机列表，这一点上面操作就会比较简单。其次节约了成本，不在需要另外一个机器专门进行负载均衡。并且还具备故障隔离，当某个数据库故障后，负载均衡可以感知到故障，并自动停止向故障数据库节点转发请求。负载均衡的参数设置loadBalanceHosts：在默认模式下（禁用），顺序连接URL中指定的多个数据库。如果启用，则使用洗牌算法从候选主机列表中随机选择一个主机建立连接。洗牌算法(Shuffle)这里使用了collections类中自带的shuffle方法来实现随机的建立连接，名称叫做洗牌算法，所以它就和洗牌一样会把原有的数据库列表顺序打乱，就像洗牌一样。方法的实现大概就是从前往后遍历列表重复的随机选择一个元素交换到当前遍历到的位置。等遍历一遍结束后，我们就会得到一个乱序的数据库列表。优点：调用现有的Java接口，实现简单并且效果显著。运作流程负载均衡流程第一步，设置参数，在url后面拼接loadBalanceHosts参数，其为true时会开启负载均衡，默认是不开启的。第二步，JDBC连接数据库，通过解析url获取可连接的数据库列表第三步，根据洗牌算法获得的数据库列表来，用来调整接下来要连接的数据库。

1. HAProxy简介HAProxy是一个开源的项目，其代码托管在Github上，代码链接如下：HAProxy代码链接。HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。HAProxy实现了一种事件驱动, 单一进程模型，此模型支持非常大的并发连接数。2. HAProxy实现openGauss集群的读写分离和负载均衡HAProxy实现openGauss集群的读写分离和负载均衡，前提条件需由Patroni管理openGauss数据库集群，关键点在于配置文件的配置。HAProxy 配置中分成五部分内容，分别如下：- global：设置全局配置参数，属于进程的配置，通常是和操作系统相关。- defaults：配置默认参数，这些参数可以被用到frontend，backend，listen组件；- frontend：接收请求的前端虚拟节点，frontend可以更加规则直接指定具体使用后端的backend；- backend：后端服务集群的配置，是真实服务器，一个backend对应一个或者多个实体服务器；- listen ：frontend和backend的组合体。在HAProxy配置文件中，我们定义了两个listen模块，名称分别为opengauss和opengauss_balance,对应集群主机的写操作和备机的读操作及负载均衡。在listen模块中，使用server关键字设置后端服务器，即设置Patroni管理的openGauss集群中各个数据库节点的ip和端口号，即可将数据库节点的信息加入到HAProxy的管理中。global maxconn 100 defaults log global mode tcp retries 2 timeout client 30m timeout connect 4s timeout server 30m timeout check 5s listen stats mode http bind *:7000 stats enable stats uri / listen opengauss bind *:5000 option httpchk http-check expect status 200 default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions # server opengauss_ip0_port0 ip0:port0 maxconn 100 check port 8008 # server opengauss_ip1_port1 ip1:port1 maxconn 100 check port 8008 # server opengauss_ip2_port2 ip2:port2 maxconn 100 check port 8008 # server opengauss_ip3_port3 ip3:port3 maxconn 100 check port 8008 # server opengauss_ip4_port4 ip4:port4 maxconn 100 check port 8008 # server opengauss_ip5_port5 ip5:port5 maxconn 100 check port 8008 # server opengauss_ip6_port6 ip6:port6 maxconn 100 check port 8008 # server opengauss_ip7_port7 ip7:port7 maxconn 100 check port 8008 # server opengauss_ip8_port8 ip8:port8 maxconn 100 check port 8008 listen opengauss_balance bind *:5001 mode tcp option tcplog balance roundrobin option httpchk OPTIONS /replica http-check expect status 200 default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions # server opengauss_ip0_port0 ip0:port0 maxconn 100 check port 8008 inter 5000 rise 2 fall 2 # server opengauss_ip1_port1 ip1:port1 maxconn 100 check port 8008 inter 5000 rise 2 fall 2 # server opengauss_ip2_port2 ip2:port2 maxconn 100 check port 8008 inter 5000 rise 2 fall 2 # server opengauss_ip3_port3 ip3:port3 maxconn 100 check port 8008 inter 5000 rise 2 fall 2 # server opengauss_ip4_port4 ip4:port4 maxconn 100 check port 8008 inter 5000 rise 2 fall 2 # server opengauss_ip5_port5 ip5:port5 maxconn 100 check port 8008 inter 5000 rise 2 fall 2 # server opengauss_ip6_port6 ip6:port6 maxconn 100 check port 8008 inter 5000 rise 2 fall 2 # server opengauss_ip7_port7 ip7:port7 maxconn 100 check port 8008 inter 5000 rise 2 fall 2 # server opengauss_ip8_port8 ip8:port8 maxconn 100 check port 8008 inter 5000 rise 2 fall 2 2.1 主机的写操作配置listen opengauss # 用于主机 bind *:5000 #开放的端口之一，用于连接主机 option httpchk # 开启对后端服务器的健康检测，接受健康监测[check] http-check expect status 200 default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions # 监测的间隔时间[inter 3s], 监测失败多少次后被认为后端服务器是不可用的[fall 3]，监测正常多少次后被认为后端服务器是可用的[rise 2]，当标记为down时，关闭HAProxy到后台服务器的连接[on-marked-down shutdown-sessions] server opengauss_ip1_port1 ip1:port1 maxconn 100 check port 8008 server opengauss_ip2_port2 ip2:port2 maxconn 100 check port 8008 server opengauss_ip3_port3 ip3:port3 maxconn 100 check port 8008 server opengauss_ip4_port4 ip4:port4 maxconn 100 check port 8008 # 使用server关键字设置后端服务器，为后端服务器所设置的内部名称[opengauss_ip1_port1], 该名称将会呈现在日志或警报中，后端服务器的IP地址，支持端口映射[ip1:port1]原理分析：HAProxy配置中调用了健康监测REST API端点，通过Patroni获取集群中的主机备机信息。Patroni有一个丰富的REST API(Representational State Transfer，表现层状态转化)，所谓REST API，其是前后端分离的最佳实践，是开发的一套标准或者是一套规范，其特点总结如下：(1) 每一个URI代表一种资源；(2) 客户端和服务器之间，传递这种资源的表现层；(3) 客户端通过四个HTTP动词，对服务器端资源进行操作，实现“表现层状态转化”。在HTTP协议中，四个表示操作方式的动词为：GET、POST、PUT、DELETE，它们分别对应四种基本的操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。Patroni中的REST API，有以下几种使用场景：参考链接：Patroni REST API(1) 由Patroni自身使用用以leader竞选；(2) 由patronictl工具使用用以执行 failovers、switchovers、reinitialize、restarts、reloads操作；(3) 由HAProxy或者其他负载均衡器进行HTTP健康监测，或者监控。本文中HAProxy即利用Patroni中的REST API进行健康监测，进而识别集群中的主机，备机，以及各个节点的健康状态。对于健康监测中的GET请求，Patroni返回一个包含节点状态、HTTP状态码的JSON文档。如果不需要复杂的JSON文档，只保留一些关键信息，可以用OPTIONS代替GET。对于下列的请求：当Patroni节点拥有leader锁，且作为primary节点running时，Patroni REST API将返回HTTP状态码200：(1) GET / (2) GET /master (3) GET /primary (4) GET /read-write上述配置中，option httpchk相当于调用了GET /请求，http-check expect status 200相当于过滤出健康监测返回的状态码应为200，对于所配置的数据库，当为主机时，其状态码为200，于是上面的配置即选出了数据库集群中的主机，用HAProxy的ip和5000端口号即可代理集群中的主机。在openGauss集群中，通过gsql命令即可连接到集群的主机gsql -d postgres -h HAProxy_ip -p 5000 -U user -W password2.2 备机的读操作及负载均衡配置listen opengauss_balance #用于备机 bind *:5001 #开放的端口之一，用于连接备机 mode tcp option tcplog balance roundrobin #balance定义负载均衡算法，roundrobin表示基于权重进行轮询，在服务器的处理时间保持均匀分布时，这是最平衡、最公平的算法。此算法是动态的，这表示某权重可以在运行时进行调整 option httpchk OPTIONS /replica http-check expect status 200 default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions server opengauss_ip1_port1 ip1:port1 maxconn 100 check port 8008 inter 5000 rise 2 fall 2 server opengauss_ip2_port2 ip2:port2 maxconn 100 check port 8008 inter 5000 rise 2 fall 2 server opengauss_ip3_port3 ip3:port3 maxconn 100 check port 8008 inter 5000 rise 2 fall 2 server opengauss_ip4_port4 ip4:port4 maxconn 100 check port 8008 inter 5000 rise 2 fall 2原理分析：对于GET /replica请求，当Patroni节点为running状态，角色为replica，未设置noloadbalance标签时，http返回状态码为200。上述配置中，option httpchk OPTIONS /replica即调用了OPTIONS /replica请求，并以OPTIONS代替GET简化返回的信息，http-check expect status 200相当于过滤出健康监测返回的状态码应为200，因此当所配置的数据库为集群中的备机时，其状态码为200，于是上面的配置即选出了数据库集群中的备机，同时配置balance roundrobin，即定义负载均衡算法，对于读请求，将轮询发送于各个运行中的备机，因此，上述的配置可以用HAProxy的ip和5001端口号代理集群中的备机，且实现负载均衡。在openGauss集群中，通过gsql命令即可连接到集群的备机gsql -d postgres -h HAProxy_ip -p 5001 -U user -W password2.3 监控界面描述除此之外，我们还配置了一个HAProxy的监控界面，通过访问该界面可以查看集群中各个节点的状态。listen stats #定义一个名为stats的部分 mode http # 定义为HTTP模式 bind *:7000 #开放的端口之一，用于监控 # 定义监听的套接字 stats enable # stats是HAProxy的一个统计页面的套接字 stats uri / # 设置统计页面的uri为/上述配置中，访问 http://ip:7000/ 即可查看监控界面，其中ip为部署HAProxy机器的ip，页面信息如下图所示：上图中，对应一主三备集群，第一个模块openGauss对应写操作，绿色的一栏表示集群中的主机，第二个模块opengauss_balance对应读操作，绿色的栏表示集群中的备机。至此，已通过HAProxy实现Patroni管理的openGauss集群的读写分离和负载均衡。

作者Codelabs助理上架时间  2021/10/13 15:16:51 GMT+08:00基于华为云CLI，以shell脚本模板形式集成CLI调用命令，对弹性负载均衡ELB进行管理和配置。描述基于华为云CLI，以shell脚本模板形式实现对弹性云服务器进行重装系统、切换系统以及job执行状态查询。关于华为云CLI更多使用帮助请参考用户指南。场景介绍本示例以实现切换弹性云服务器(未安装Cloud-Init)为主，同时提供密钥管理、镜像查询、弹性云服务器查询以及重装系统等相关操作，具体如下：密钥相关：创建和导入SSH密钥、删除SSH密钥、查询SSH密钥列表；镜像相关：查询公共镜像列表、查询私有镜像列表、查询可以使用的共享镜像列表；弹性云服务器相关：查询弹性云服务器、重装弹性云服务器操作系统、切换弹性云服务器操作系统、查询任务的执行状态。前提条件下载安装HCloud CLIHCloud CLI的下载安装请参考安装指南。配置（删除配置）HCloud CLI开发者在配置HCloud CLI前需先获取认证相关的信息。1.AK/SK 访问密钥请在华为云控制台“我的凭证-访问密钥”页面上创建和查看您的AK/SK。更多信息请查看访问密钥。2.region 当前可调用的区域华为云各服务应用区域和各服务的终端节点请查看地区和终端节点。3.project-id 云服务所在项目ID根据需要操作的项目所属区域选择对应的项目ID 。配置和删除配置HCloud CLI的命令如下：hcloud configure set --profile=cliProfile --project-id={project_id} --region={region} --mode=AKSK --access-key={AK} --secret-key={SK} --read-timeout=60 --connect-timeout=30hcloud configure delete --profile=cliProfile目标弹性云服务器弹性云服务器ECS购买相关的操作可参考《使用CLI便捷管理弹性云服务器ECS》模板。获取切换或重装弹性云服务器操作系统相关的参数在切换操作系统过程中需获取如下参数：serverId、imageId、adminPass(keyname、userid)。1.serverId：标服务器的ID可通过执行hcloud ECS NovaListServers --name={ecs_name} --json-filter="servers[].id | [0]"命令获取；或可通过”华为云控制台-弹性云服务器ECS“页面，选取指定ECS查看其ID。2.imageId：镜像ID可通过执行hcloud IMS GlanceListImages --__imagetype="gold" --protected=true --visibility="public" --__platform="Ubuntu" --__os_type="Linux" --__os_bit="64" --__isregistered=true --status="active" --json-filter="images[?name=='{image_name}'].id | [0]"命令获取；或可通过“华为云控制台-弹性云服务器ECS-镜像服务”页面，选取指定镜像，查看其ID。 如下所示，选取Ubuntu 18.04 server 64bit版本镜像。3.adminPass：标服务器的管理员密码。4.keyname：密钥名称。使用秘钥方式切换操作系统,则该字段为必选字段。密钥可以通过执行hcloud ECS NovaCreateKeypair --keypair.name={your key name}命令进行创建，或执行hcloud ECS NovaListKeypairs 命令查询已有的密钥。5.userid：用户ID。使用秘钥方式切换操作系统,则该字段为必选字段。在重装系统过程中需获取如下参数：serverId、adminPass(keyname、userid)。1.serverId：标服务器的ID。可通过执行hcloud ECS NovaListServers --name={ecs_name} --json-filter="servers[].id | [0]"命令获取；或可通过”华为云控制台-弹性云服务器ECS“页面，选取指定ECS查看其ID。2.adminPass：标服务器的管理员密码。3.keyname：密钥名称。使用秘钥方式切换操作系统,则该字段为必选字段。密钥可以通过执行hcloud ECS NovaCreateKeypair --keypair.name={your key name}命令进行创建，或执行hcloud ECS NovaListKeypairs 命令查询已有的密钥。4.userid：用户ID。使用秘钥方式切换操作系统,则该字段为必选字段。开发说明本模板默认使用密钥方式切换弹性云服务器操作系统，您也可参考模板中提供的使用密码方式切换弹性云服务器操作系统。使用时请根据实际需要注释或修改部分参数内容。示例代码使用如下代码管理密钥，调用前请根据实际情况修改或替换部分参数内容。# Querying SSH Key Pairs hcloud ECS NovaListKeypairs --limit=20 # Importing an SSH Key Pair hcloud ECS NovaCreateKeypair --keypair.public_key={public_key} --keypair.type="ssh" --keypair.user_id={user ID of the key} --keypair.name={key_name} # Creating an SSH Key Pair hcloud ECS NovaCreateKeypair --keypair.name={key_name} # Deleting an SSH Key Pair hcloud ECS NovaDeleteKeypair --keypair_name={key_name}使用如下代码查询镜像信息，调用前请根据实际情况修改或替换部分参数内容。# Querying Private Images hcloud IMS GlanceListImages --owner={project_id} # Querying Available shared Images hcloud IMS GlanceListImages --__imagetype="shared" --visibility="shared" --member_status="accepted" # Querying Public Images (when you don't know the image name) hcloud IMS GlanceListImages --__imagetype="gold" --visibility="public" --protected=true --json-filter="images[].{id:id,name:name,status:status}" # Querying Public Images (when you know the image name) hcloud IMS GlanceListImages --__imagetype="gold" --protected=true --visibility="public" --__platform="Ubuntu" --__os_type="Linux" --__os_bit="64" --__isregistered=true --status="active" --json-filter="images[?name=='{image_name}'].id | [0]"使用如下代码查询弹性云服务器，调用前请根据实际情况修改部分参数内容。# Querying ECSs hcloud ECS NovaListServers --name={ecs_name} --json-filter="servers[].id | [0]"使用如下代码重装弹性云服务器操作系统，调用前请根据实际情况修改部分参数内容。# Changing an ECS OS with Cloud-Init(Using a Password) hcloud ECS ChangeServerOsWithCloudInit --server_id={server_id} --os-change.imageid={image_id} --os-change.adminpass={adminpass} [--os-change.mode="withStopServer"] # Changing an ECS OS with Cloud-Init(Using a Key) hcloud ECS ChangeServerOsWithCloudInit --server_id={server_id} --os-change.imageid={image_id} --os-change.keyname={key_pair_name} --os-change.userid={user_id} [--os-change.mode="withStopServer"] # Changing an ECS OS without Cloud-Init(Using a Password) hcloud ECS ChangeServerOsWithoutCloudInit --server_id={server_id} --os-change.imageid={image_id} --os-change.adminpass={adminpass} [--os-change.mode="withStopServer"] # Changing an ECS OS without Cloud-Init(Using a Key) hcloud ECS ChangeServerOsWithoutCloudInit --server_id={server_id} --os-change.imageid={image_id} --os-change.keyname={key_pair_name} --os-change.userid={user_id} --os-change.mode="withStopServer" --json-filter=job_id使用如下代码切换弹性云服务器操作系统，调用前请根据实际情况修改部分参数内容。# Reinstalling an ECS OS with Cloud-Init(Using a Password) hcloud ECS ReinstallServerWithCloudInit --server_id={server_id} --os-reinstall.adminpass={adminpass} [--os-change.mode="withStopServer"] # Reinstalling an ECS OS with Cloud-Init(Using a Key) hcloud ECS ReinstallServerWithCloudInit --server_id={server_id} --os-reinstall.keyname={key_pair_name} --os-reinstall.userid={user_id} [--os-change.mode="withStopServer"] # Reinstalling an ECS OS without Cloud-Init(Using a Password) hcloud ECS ReinstallServerWithoutCloudInit --server_id={server_id} --os-reinstall.adminpass={adminpass} [--os-change.mode="withStopServer"] # Reinstalling an ECS OS without Cloud-Init(Using a Key) hcloud ECS ReinstallServerWithoutCloudInit --server_id={server_id} --os-reinstall.keyname={key_pair_name} --os-reinstall.userid={user_id} [--os-change.mode="withStopServer"]使用如下代码查询任务的执行状态，调用前请根据实际情况修改部分参数内容。# Querying Task Execution Status hcloud ECS ShowJob --job_id={job_id}运行示例运行时首先通过sudo ln -s CLI工具所在目录 /usr/local/bin/命令配置华为云CLI工具环境变量，或将脚本模板放置在华为云CLI工具所在目录，并在hcloud开头的相关命令前加“./”。其次，根据实际情况修改部分参数内容、或注释无关的命令，最后执行sh reinstall_or_change_an_ecs_os.sh image_name ecs_name key_pair_name user_id命令运行脚本。运行结果脚本执行成功后，控制台打印云服务器详情列表信息。{ "job_id": "ff8080xxxxxxxxxxxxxxxxxxx7453e4c", "job_type": "changeOS", "begin_time": "2021-08-17T02:08:26.430Z", "end_time": "2021-08-17T02:16:55.498Z", "status": "SUCCESS", "error_code": null, "fail_reason": null, "entities": { "server_id": "a3985dbb-xxxx-xxxx-xxxx-xxxxdab21fe0" } }参考关于华为云CLI的更多信息请参考：https://support.huaweicloud.com/productdesc-hcli/hcli_01.html

DWS 8.0/8.1 ,  目前使用的 ELB 加权最小连接方式来进行负载均衡 。 如下是官方文档。  负载均衡采用的算法。加权轮询算法：根据后端服务器的权重，按顺序依次将请求分发给不同的服务器。它用相应的权重表示服务器的处理性能，按照权重的高低以及轮询方式将请求分配给各服务器，相同权重的服务器处理相同数目的连接数。加权最少连接：最少连接是通过当前活跃的连接数来估计服务器负载情况的一种动态调度算法。加权最少连接就是在最少连接数的基础上，根据服务器的不同处理能力，给每个服务器分配不同的权重，使其能够接受相应权值数的服务请求。源IP算法：将请求的源IP地址进行一致性Hash运算，得到一个具体的数值，同时对后端服务器进行编号，按照运算结果将请求分发到对应编号的服务器上。这可以使得对不同源IP的访问进行负载分发，同时使得同一个客户端IP的请求始终被派发至某特定的服务器。  问题： 1.     通过当前活跃的连接数来估计服务器负载情况的一种动态调度算法  ----    当前活跃连接是指DWS的 active ，idle in transaction 状态的连接 ？ idle连接不算 ？   ELB 是通过连接是否有网络信号判断是否活跃的  ？      2.     加权最少连接就是在最少连接数的基础上，根据服务器的不同处理能力，给每个服务器分配不同的权重    -----   ELB 是如何知道服务器的处理能力  ？  是需要手工单独配置 ？     

云计算以及分布式架构，本质上也是将后端服务器作为计算资源、存储资源，由某台管理服务器封装成一个服务对外提供，客户端不需要关心真正提供服务的是哪台机器，在它看来，就好像它面对的是一台拥有近乎无限能力的服务器，而本质上，真正提供服务的，是后端的集群。LVS、Nginx、HAProxy 是目前使用最广泛的三种软件负载均衡软件。LVS   LVS 是 Linux Virtual Server 的简称，也就是 Linux 虚拟服务器。现在 LVS 已经是 Linux 标准内核的一部分，从 Linux2.4 内核以后，已经完全内置了 LVS 的各个功能模块，无需给内核打任何补丁，可以直接使用 LVS 提供的各种功能。LVS 架设的服务器集群系统有三个部分组成：(1) 最前端的负载均衡层，用 Load Balancer 表示(2) 中间的服务器集群层，用 Server Array 表示(3) 最底端的数据共享存储层，用 Shared Storage 表示LVS 负载均衡机制   LVS 不像 HAProxy 等七层软负载面向的是 HTTP 包，所以七层负载可以做的 URL 解析等工作，LVS 无法完成。LVS 是四层负载均衡，也就是说建立在 OSI 模型的第四层——传输层之上，传输层上有我们熟悉的TCP/UDP，LVS 支持 TCP/UDP 的负载均衡。因为 LVS是四层负载均衡，因此它相对于其它高层负载均衡的解决办法，比如 DNS 域名轮流解析、应用层负载的调度、客户端的调度等，它的效率是非常高的。所谓四层负载均衡 ，也就是主要通过报文中的目标地址和端口。七层负载均衡 ，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容。LVS 的转发主要通过修改 IP 地址（NAT 模式，分为源地址修改 SNAT 和目标地址修改 DNAT）、修改目标 MAC（DR 模式）来实现。LVS 的优点   抗负载能力强、是工作在传输层上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的，对内存和 cpu 资源消耗比较低。配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率。工作稳定，因为其本身抗负载能力很强，自身有完整的双机热备方案，如 LVS + Keepalived。无流量，LVS 只分发请求，而流量并不从它本身出去，这点保证了均衡器 IO 的性能不会受到大流量的影响。应用范围比较广，因为 LVS 工作在传输层，所以它几乎可以对所有应用做负载均衡，包括 http、数据库、在线聊天室等等。LVS 的缺点   软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是 Nginx、HAProxy + Keepalived 的优势所在。如果是网站应用比较庞大的话，LVS/DR + Keepalived 实施起来就比较复杂了，相对而言，Nginx / HAProxy + Keepalived 就简单多了。Nginx   Nginx 是一个强大的 Web 服务器软件，用于处理高并发的 HTTP 请求和作为反向代理服务器做负载均衡。具有高性能、轻量级、内存消耗少，强大的负载均衡能力等优势。Nignx 的架构设计   相对于传统基于进程或线程的模型（Apache就采用这种模型）在处理并发连接时会为每一个连接建立一个单独的进程或线程，且在网络或者输入/输出操作时阻塞。这将导致内存和 CPU 的大量消耗，因为新起一个单独的进程或线程需要准备新的运行时环境，包括堆和栈内存的分配，以及新的执行上下文，当然，这些也会导致多余的 CPU 开销。最终，会由于过多的上下文切换而导致服务器性能变差。反过来，Nginx 的架构设计是采用模块化的、基于事件驱动、异步、单线程且非阻塞。Nginx 大量使用多路复用和事件通知，Nginx 启动以后，会在系统中以 daemon 的方式在后台运行，其中包括一个 master 进程，n(n>=1) 个 worker 进程。所有的进程都是单线程（即只有一个主线程）的，且进程间通信主要使用共享内存的方式。其中，master 进程用于接收来自外界的信号，并给 worker 进程发送信号，同时监控 worker 进程的工作状态。worker 进程则是外部请求真正的处理者，每个 worker 请求相互独立且平等的竞争来自客户端的请求。请求只能在一个 worker 进程中被处理，且一个 worker 进程只有一个主线程，所以同时只能处理一个请求。Nginx 负载均衡   Nginx 负载均衡主要是对七层网络通信模型中的第七层应用层上的 http、https 进行支持。Nginx 是以反向代理的方式进行负载均衡的。反向代理（Reverse Proxy）方式是指以代理服务器来接受 Internet 上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给 Internet 上请求连接的客户端，此时代理服务器对外就表现为一个服务器。Nginx 实现负载均衡的分配策略有很多，Nginx 的 upstream 目前支持以下几种方式：轮询（默认）：每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器 down 掉，能自动剔除。weight：指定轮询几率，weight 和访问比率成正比，用于后端服务器性能不均的情况。ip_hash：每个请求按访问 ip 的 hash 结果分配，这样每个访客固定访问一个后端服务器，可以解决 session 的问题。fair（第三方）：按后端服务器的响应时间来分配请求，响应时间短的优先分配。url_hash（第三方）：按访问 url 的 hash 结果来分配请求，使每个 url 定向到同一个后端服务器，后端服务器为缓存时比较有效。Nginx 的优点   跨平台：Nginx 可以在大多数 Unix like OS编译运行，而且也有 Windows 的移植版本；配置异常简单：非常容易上手。配置风格跟程序开发一样，神一般的配置；非阻塞、高并发连接：官方测试能够支撑5万并发连接，在实际生产环境中跑到2～3万并发连接数事件驱动：通信机制采用 epoll 模型，支持更大的并发连接；Master/Worker 结构：一个 master 进程，生成一个或多个 worker 进程；内存消耗小：处理大并发的请求内存消耗非常小。在3万并发连接下，开启的10个 Nginx 进程才消耗150M 内存（15M*10=150M）；内置的健康检查功能：如果 Nginx 代理的后端的某台 Web 服务器宕机了，不会影响前端访问；节省带宽：支持 GZIP 压缩，可以添加浏览器本地缓存的 Header 头；稳定性高：用于反向代理，宕机的概率微乎其微。Nginx 的缺点   Nginx 仅能支 持http、https 和 Email 协议，这样就在适用范围上面小些，这个是它的缺点对后端服务器的健康检查，只支持通过端口来检测，不支持通过 ur l来检测。不支持 Session 的直接保持，但能通过 ip_hash 来解决HAProxy   HAProxy 支持两种代理模式 TCP（四层）和HTTP（七层），也是支持虚拟主机的。HAProxy 的优点能够补充 Nginx 的一些缺点，比如支持 Session 的保持，Cookie 的引导；同时支持通过获取指定的 url 来检测后端服务器的状态。HAProxy 跟 LVS 类似，本身就只是一款负载均衡软件；单纯从效率上来讲 HAProxy 会比 Nginx 有更出色的负载均衡速度，在并发处理上也是优于 Nginx 的。HAProxy 支持 TCP 协议的负载均衡转发，可以对 MySQL 读进行负载均衡，对后端的 MySQL 节点进行检测和负载均衡，大家可以用 LVS+Keepalived 对 MySQL 主从做负载均衡。HAProxy 负载均衡策略非常多：Round-robin（轮循）、Weight-round-robin（带权轮循）、source（原地址保持）、RI（请求URL）、rdp-cookie（根据cookie）。

 网站访问量已经越来越大，响应速度越来越慢。        考虑： Scale Up（也就是 Scale vertically）纵向扩展，向上扩展：机器硬件升级，增加配置，如添加CPU、内存。（往往需要购置新机器）–>旧机器不能利用上。        Scale Out（也就是 Scale horizontally）横向扩展，向外扩展：向原有的 web、邮件系统添加一个新机器。–>旧机器仍然可以发挥作用。        负载均衡技术为 scale out 服务。        Nginx 负载均衡器的特点是：        1. 工作在网络的 7 层之上，可以针对 http 应用做一些分流的策略，比如针对域名、目录结构；        2. Nginx 安装和配置比较简单，测试起来比较方便；        3. 也可以承担高的负载压力且稳定，一般能支撑超过上万次的并发；        4. Nginx 可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持 url来检测；        5. Nginx 对请求的异步处理可以帮助节点服务器减轻负载；        6. Nginx 能支持 http 和 Email，这样就在适用范围上面小很多；        7. 默认有三种调度算法: 轮询、weight 以及 ip_hash（可以解决会话保持的问题），还可以 支持第三方的 fair 和 url_hash 等调度算法；

项目背景:用户通过域名访问vip, nginx做为负载均衡为后端应用分发请求, 后端应用为dubbo服务,存储分为redis和mysql. redis做为持久会存储数据库,支持前端业力. 并且通过mq同步数据到mysql,供后端使用. 同时后台写mysql也要通过mq同步到redis.目前后端服务qps最高可以达到5万,本次架构设计在不重构的情况下短期内最快的方法达到目标10万qps.架构方案:一，现有idc架构可支撑5万qps。这是经过一年考验下来的，可做为保底的；如果应用全部上云，需要从0开始重新验证能否达到现有5万qps，再去验证能否达到10万qps，时间等未知风验很大；  二，10万qps目标，建议用简单粗暴的方式，直接把idc应用层架构复制一套上云；不建议在现有架构上继续调优，现在架构如果不重构，可能很难找到问题；与其这样不如把人力时间用到另一个方向，比如数据中心；   三，由idc+公有云两套系统构成混合云模式，数据统一使用idc的redis和mysql，公有云与idc 的数据库连接建立专线；混合云的方式可以检测公有云的实际性能，也能为将来全部迁移公有云提供真实参考；   四，平时比赛，使用idc架构完全可以支撑，公有云留少量机器和用户请求预热，重要比赛，临时增加云资源扛突发，服务器成本节约，扩展性也灵活；   五，公有云都有出现过大规模事故,造成全站不能访问的情况,为了保险，我们依然要保留idc的服务，所以混合云也许是最适合的；      技术难点：   一，如何将用户请求分流到 idc和公有云两套应用   1，域名解析两条A记录，分别指向idc和公有云两个vip，通过dns平均分配用户请求   2，idc架构在nginx前端增加四层负载均衡（lvs,ha_porxy），由四层负载均衡将用户请求转发给idc的nginx和公有云的负载均衡，lvs与公有云通信通过专线；   二，前端应用入口放大，后端数据中心，需要扩容   1，redis使用多主多从，redis3.0 还是用 代理（predixy,codis）；   2，业务拆分，组建更多的一主多从；      具体实施：   1，双系统流量分发配置lvs即可，本赛季最好能用上几轮，演练资源增减，熟悉流程，检测可行性；   2，redis数据中心需要大量的测试，选型，可做重点研究（这也是目前急需解决的单点）；

k8s的高可用架构，也就是扩容多Master架构。这是因为，k8s作为容器集群系统，通过健康检查+重启策略实现了Pod故障自我修复能力，通过调度算法实现将Pod分布式部署，监控其预期副本数，并根据Node失效状态自动在正常Node启动Pod，实现了应用层的高可用性。Node节点是不需要考虑高可用架构。而Master节点扮演着总控中心的角色，通过不断与工作节点上的Kubelet和kube-proxy进行通信来维护整个集群的健康工作状态。如果Master节点故障，将无法使用kubectl工具或者API任何集群管理而Master节点主要有三个服务kube-apiserver、kube-controller-mansger和kube-scheduler，其中kube-controller-mansger和kube-scheduler组件自身通过选择机制已经实现了高可用，就是说，如果集群里配置了多个kube-controller-mansger和kube-scheduler组件，他们会根据自己的竞争机制选出主用组件。所以Master高可用主要针对kube-apiserver组件，而该组件是以HTTP API提供服务，因此对他高可用实际上与Web服务器类似，增加负载均衡器（如nginx)对其负载均衡即可，而且可以继续水平扩容。针对Kubernetes集群，高可用性还应包含以下两个层面的考虑：Etcd数据库的高可用性和K8s Master组件的高可用性。 而Etcd已经采用多个节点组建集群实现高可用，所以对Master节点高可用就等同于对kube-apiserver的负载均衡的部署实施。

【功能模块】华为云服务器负载均衡其中一台无法写入文件到共享磁盘【操作步骤&问题现象】1、2、【截图信息】【日志信息】（可选，上传日志内容或者附件）

nginx的作用三个：1、反向代理(后期补充)2、动静分离（后期补充）3、负载均衡 负载均衡实现效果：在浏览器中输入http://10.10.9.219/edu/a.html然后到达负载均衡的目的，后端的两台服务器轮流提供服务。 准备两台tomcat服务器：一台10.10.9.219  （安装tomcat、nginx）另一台10.10.9.16  （安装tomcat） 第一步：下载tomcat解压：wget https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.29/bin/apache-tomcat-9.0.29.tar.gz1)安装JDK。2)解压Tomcat软件包。tar -xvf apache-tomcat-9.0.29.tar.gz3)运行Tomcat。sh apache-tomcat-9.0.29/bin/startup.sh4)在浏览器中输入URL：http://服务器公网IP地址:8080当出现以下页面，说明Tomcat服务器环境配置成功如果以上URL不能访问，请检查云主机安全组是否放开8080端口。第二步：在两台tomcat服务器的webapps目录中创建edu的文件夹，在edu的文件夹中创建a.html文件。其中    服务器10.10.9.219中的a.html内容为<h1>tomcat2</h1>    服务器10.10.9.16中的a.html内容为<h1>tomcat1</h1>在浏览器输入http://服务器公网IP地址:8080/edu/a.html第三步：源码编译安装nginxhttps://support.huaweicloud.com/prtg-kunpengwebs/kunpengnginx_02_0001.html第四步：配置nginx.conf配置文件添加如下内容：http{ ……upstream tomcatserver1 {      server 10.10.9.219:8080 weight=1;      server 10.10.9.16:8080 weight=2;      }     ……server {          listen       80;          server_name  10.10.9.219;          location / {            ……            proxy_pass   http://tomcatserver1;              ……          }      }}启动nginx进入ngnix安装目录/usr/local/nginx下的sbin目录./nginx –s stop./nginx 第五步：验证在浏览器输入http://nginx服务器ip/edu/a.html 如http://10.10.9.219/edu/a.html因为nginx配置的是监听80端口故可以省略。两台服务器轮流切换附：nginx负载均衡的策略1、ip_哈希算法    ip_hash;2、轮询 ——轮流处理请求（默认）3、权重 ——weight=1;

MRS使用负载均衡实现HA适配说明书 ：https://fusioninsight.github.io/ecosystem/zh-hans/Other/MRS%E4%BD%BF%E7%94%A8%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E5%AE%9E%E7%8E%B0HA%E9%80%82%E9%85%8D%E8%AF%B4%E6%98%8E%E4%B9%A6/MRS使用负载均衡实现HA：基于微软云的适配代码与安装说明书:  https://fusioninsight.github.io/ecosystem/zh-hans/Other/MRS%E4%BD%BF%E7%94%A8%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E5%AE%9E%E7%8E%B0HA%EF%BC%9A%E5%9F%BA%E4%BA%8E%E5%BE%AE%E8%BD%AF%E4%BA%91%E7%9A%84%E9%80%82%E9%85%8D%E4%BB%A3%E7%A0%81%E4%B8%8E%E5%AE%89%E8%A3%85%E8%AF%B4%E6%98%8E%E4%B9%A6/

我们知道GaussDB(DWS)为了保证业务的连续性和高可靠性，各个组件都进行了高可用设计。下图是应用访问GaussDB(DWS)的业务流程架构图，对于业务应用或者用户来说，他们发生请求给CN，CN解析并生成执行计划，交给DN去执行，执行后再由CN汇总将数据返回给业务用户或者业务应用。这个过程是容易理解的，本次我们重点关注的是站在CN前面的LVS+KeepAlived。现在的问题是：CN的返回结果是否会经过LVS，然后再返回给前端应用？如果经过LVS，那么，LVS会不会成为单点瓶颈？带着这两个问题我们探究一下LVS和KeepAlived的原理。一、LVS是什么？ LVS是Linux Virtual Server的简称，也就是Linux虚拟服务器, 是一个由章文嵩博士发起的自由软件项目，它的官方站点是www.linuxvirtualserver.org。现在LVS已经是 Linux标准内核的一部分，在Linux2.4内核以前，使用LVS时必须要重新编译内核以支持LVS功能模块，但是从Linux2.4内核以后，已经完全内置了LVS的各个功能模块，无需给内核打任何补丁，可以直接使用LVS提供的各种功能。二、LVS的目的是什么？LVS主要用于服务器集群的负载均衡，拥有VIP，客户端将所有请求发送至此VIP，LVS负责将请求分发到不同的RS，客户不感知RS。其目的是提高服务器的性能，将请求均衡的转移到不同的服务器上执行，从而将一组服务器构成高性能、高可靠的虚拟服务器。 三、LVS的体系结构使用LVS架设的服务器集群系统有三个部分组成：　　（1）最前端的负载均衡层，用Load Balancer表示；　　（2）中间的服务器集群层，用Server Array表示；　　（3）最底端的数据共享存储层，用Shared Storage表示；在用户看来，所有的内部应用都是透明的，用户只是在使用一个虚拟服务器提供的高性能服务。如图：Load Balancer层：位于整个集群系统的最前端，有一台或者多台负载调度器（Director Server）组成，LVS模块就安装在Director Server上，而Director的主要作用类似于一个路由器，它含有完成LVS功能所设定的路由表，通过这些路由表把用户的请求分发给Server Array层的应用服务器（Real Server）上。同时，在Director Server上还要安装对Real Server服务的监控模块Ldirectord，此模块用于监测各个Real Server服务的健康状况。在Real Server不可用时把它从LVS路由表中剔除，恢复时重新加入。Server Array层：由一组实际运行应用服务的机器组成，Real Server可以是WEB服务器、MAIL服务器、FTP服务器、DNS服务器、视频服务器中的一个或者多个，每个Real Server之间通过高速的LAN或分布在各地的WAN相连接。在实际的应用中，Director Server也可以同时兼任Real Server的角色。Shared Storage层：是为所有Real Server提供共享存储空间和内容一致性的存储区域，在物理上，一般有磁盘阵列设备组成，为了提供内容的一致性，一般可以通过NFS网络文件系统共享数据，但是NFS在繁忙的业务系统中，性能并不是很好，此时可以采用集群文件系统，例如Red hat的GFS文件系统，oracle提供的OCFS2文件系统等。    从整个LVS结构可以看出，Director Server是整个LVS的核心，目前，用于Director Server的操作系统只能是Linux和FreeBSD，linux2.6内核不用任何设置就可以支持LVS功能，而FreeBSD作为Director Server的应用还不是很多，性能也不是很好。对于Real Server，几乎可以是所有的系统平台，Linux、windows、Solaris、AIX、BSD系列都能很好的支持。四、LVS的程序组成部分LVS 由2部分程序组成，包括 ipvs 和 ipvsadm。ipvs(ip virtual server)：一段代码工作在内核空间，叫ipvs，是真正生效实现调度的代码。ipvsadm：另外一段是工作在用户空间，叫ipvsadm，负责为ipvs内核框架编写规则，定义谁是集群服务，而谁是后端真实的服务器(Real Server)五、LVS的负载均衡机制1、 LVS是四层负载均衡，也就是说建立在OSI模型的第四层——传输层之上，传输层上有我们熟悉的TCP/UDP，LVS支持TCP/UDP的负载均衡。因为LVS是四层负载均衡，因此它相对于其它高层负载均衡的解决办法，比如DNS域名轮流解析、应用层负载的调度、客户端的调度等，它的效率是非常高的。2、 LVS的转发主要通过修改IP地址（NAT模式，分为源地址修改SNAT和目标地址修改DNAT）、修改目标MAC（DR模式）来实现。 GaussDB(DWS)目前主要采用的是DR(Direct Routing)模式，所以，我们主要聊一聊DR模式。下图是DR模式的一个示意图：DR模式下需要LVS和RS集群绑定同一个VIP（RS通过将VIP绑定在loopback实现），请求由LVS接受，由真实提供服务的服务器（RealServer, RS）直接返回给用户，返回的时候不经过LVS。详细来看，一个请求过来时，LVS只需要将网络帧的MAC地址修改为某一台RS的MAC，该包就会被转发到相应的RS处理，注意此时的源IP和目标IP都没变，LVS只是做了一下移花接木。RS收到LVS转发来的包时，链路层发现MAC是自己的，到上面的网络层，发现IP也是自己的，于是这个包被合法地接受，RS感知不到前面有LVS的存在。而当RS返回响应时，只要直接向源IP（即用户的IP）返回即可，不再经过LVS。至此，回答了我们第一个问题：CN的返回结果是否会经过LVS，然后再返回给前端应用？答：GaussDB(DWS)采用的是LVS的DR模式，返回时不再经过LVS。 接下来，我们看看keepAlived。一、什么是keepAlived？Keepalived顾名思义，保持存活，在网络里面就是保持在线了，也就是所谓的高可用或热备，用来防止单点故障(单点故障是指一旦某一点出现故障就会导致整个系统架构的不可用)的发生。二、keepAlived的原理Keepalived的实现基于VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议），而VRRP是为了解决静态路由的高可用。虚拟路由器由多个VRRP路由器组成，每个VRRP路由器都有各自的IP和共同的VRID(0-255)，其中一个VRRP路由器通过竞选成为MASTER，占有VIP，对外提供路由服务，其他成为BACKUP，MASTER以IP组播（组播地址：224.0.0.18）形式发送VRRP协议包，与BACKUP保持心跳连接，若MASTER不可用（或BACKUP接收不到VRRP协议包），则BACKUP通过竞选产生新的MASTER并继续对外提供路由服务，从而实现高可用。三、KeepAlived与LVS的关系1、keepalived 是 lvs 的扩展项目，是对LVS项目的扩展增强，因此它们之间具备良好的兼容性。2、对LVS应用服务层的应用服务器集群进行状态监控：若应用服务器不可用，则keepalived将其从集群中摘除，若应用服务器恢复，则keepalived将其重新加入集群中。3、检查LVS主备节点的健康状态，通过IP漂移，实现主备冗余的服务高可用，服务器集群共享一个虚拟IP，同一时间只有一个服务器占有虚拟IP并对外提供服务，若该服务器不可用，则虚拟IP漂移至另一台服务器并对外提供服务，解决LVS本身单点故障问题。 至此，我们可以回答第二个问题：如果经过LVS，那么，LVS会不会成为单点瓶颈或者出现单独故障？答：返回结果不会经过LVS，不会因为返回的数据量太大造成单独瓶颈的问题。对应请求， LVS只需要将用户请求转发给CN即可，负载很低，也不会出现单独瓶颈的问题。另外，LVS通过keepAlived实现了主备冗余，避免了单独故障。

LVS(Linux Virtual Server)作为中国最早出现的自由软件项目之一，在Linux内核中实现了基于IP的四层数据请求负载均衡调度方案。相比Nginx等七层负载均衡方案，LVS处理流程更少，效率更高，更适合大型企业集群使用，目前LVS已经成为Linux官方标准内核模块的一部分。LVS工作过程如下所示，客户端连接LVS，发送请求，LVS通过下发请求给不同的服务器，实现负载均衡。LVS又称LVS Director，因此根据上图实例不同，在LVS中，包含以下术语：CIP（Client IP）、DIP（Director IP）、RIP（Real Server IP）。根据内部的实现原理，LVS包含多种模式：NAT模式、DR模式、TUN模式。NAT模式通过通过修改客户端入站目的地址为RIP将数据包传输至服务器，出站时LVS Director修改数据包地址为CIP将数据包传输至客户端。DR模式通过修改入站数据包的目的MAC地址，将数据包传输至服务器，出站时不经过LVS，数据包由服务器直接返回给客户端。TUN模式即隧道模式，指不修改数据包内容，而是为数据包封装包头（IP头）的方式转发数据，出入站路径和DR模式相同。修改数据包的方法，主要是基于内核netfilter框架和iptables机制实现的。netfilter框架可以理解为内核处理数据包时，在IP层预留的几个数据快照点，如下图绿色节点所示。每一个快照点对应数据包在IP层的一个处理阶段，在数据包经过这些点时，可以通过注册HOOK函数对数据包进行操作。也可以通过iptables工具对数据包的行为进行自定义（丢弃、继续传输等）。数据一定是经由上层传输的，例如通过http、TCP、UDP协议等下发至下层，TCP协议需要建立连接，netfitler实现TCP建连时有两种场景和方案：实现客户端到服务器的透明传输（包含建连），通俗点讲，就是客户端的目的IP地址实际上还是RIP，但是LVS可以代替服务器做应答，并转发数据给服务器，该场景下TCP建连可以视作客户端直接到服务器的一次三次握手。这种场景显然不能达到负载均衡的目的，而是较为适合长时延端到端传输。实现客户端请求向不同服务器转发，建连需要经历两个阶段：一是客户端和LVS建连、LVS再和服务器建连，可以理解为两个三次握手。显然这种场景可以实现LVS的负载均衡目的，但是建连过程变的复杂。为解决建连复杂问题，目前LVS在客户端连接请求发起之前，就和服务器建立很多空连接（仅三次握手），对于数据库集群服务器，此时无法收到startuppackets报文，就会不断打印日志：[BACKEND] WARNING:  could not receive data from client, remote nodename linux*****, detail:none.[BACKEND] LOG:  incomplete startup packet上述日志中，incomplete startup packet表明现象，could not receive data from client表明该现象的具体原因为没有收到数据。从PG官方论坛的讨论中，该日志是无害的。如果我们理解LVS和Gaussdb相关原理，就可以避免疑惑，少走弯路。原文链接：https://bbs.huaweicloud.com/blogs/238621【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓