精华内容
下载资源
问答
  • gitlab高可用模式

    2020-12-19 23:52:52
    可用模式企业版社区版我们这里说一下成本比较低的主备模式,它主要依赖的是DRBD方式进行数据同步,需要2台ALL IN ONE的GitLab服务器,也就是通过上面安装方式把所有组件都安装在一起的2台机器。什么是DRBD它是...

    高可用模式

    企业版

    社区版

    我们这里说一下成本比较低的主备模式,它主要依赖的是DRBD方式进行数据同步,需要2台ALL IN ONE的GitLab服务器,也就是通过上面安装方式把所有组件都安装在一起的2台机器。

    什么是DRBD

    它是分布式复制块设备,软件实现的无需共享可以在服务器之间镜像块设备的存储复制解决方案。

    左侧为A节点,右侧为B节点

    DRBD运行在内核里,它是一个内核模块。Linux2.6.33开始已经整合进内核。上图A为活动节点,B为被动节点。A收到数据发往内核的数据通路,DRBD在数据通路中注册钩子检查数据,当发现接收到的数据是发往自己管理的存储位置时,就复制一份,一份存储到本地的DRBD存储设备上,一份就发给TCP/IP协议栈,通过网卡传输到B节点的TCP/IP协议栈,B节点运行的DRBD模块同样在数据通路上坚持,发现有数据过来就存储到DRBD对应的位置上。如果A节点宕机,B节点上线,B节点接收到数据存储到本地,当A节点恢复以后在把变动数据同步到A节点上。

    流程如下:

    SERVICE将数据写入  FIEL SYSEM->BUFFER CACHE->DRDB

    DRDB兵分两路一路通过磁盘DISK DRIVER写入磁盘

    另外一路通过TCP/IP将数据通过网卡发送到对端DRBD节点

    工作模式:

    同步模式:当写入A服务器和B服务器成功后才返回。这是DRBD协议的C模式。生产环境中该模式最常用。

    异步模式:写入A服务器后返回,还有可能是写入本地服务器和远端服务器的缓存成功后返回,这属于DRBD的A、B级别。

    DRBD建立在底层设备之上,对于用户来说一个DRBD设备就像一块物理磁盘。它支持磁盘、软RAID、LVM等其他块设备。

    部署

    # 添加源

    # CentOS 6

    rpm -ivh http://www.elrepo.org/elrepo-release-6-6.el6.elrepo.noarch.rpm

    # CentOS 7

    rpm -ivh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm

    # 安装

    yum -y install drbd84-utils kmod-drbd84

    # 安装后重启

    reboot

    修改配置文件

    下面是主配置文件

    /etc/drbd.conf是主配置文件,但是它里面引用了2个,所以真正需要配置的是在它包含的配置文件中进行配置。

    /etc/drbd.d/global_common.conf包含global和common这两部分DRBD配置信息。而*.res文件而资源文件。

    /etc/drbd.d/global_common.conf配置文件说明

    /usr/share/doc/drbd84-utils-9.3.1/drbd.conf.example这是一个模板文件。

    默认这个配置文件里面没有配置什么具体内容

    我这里就配置了几项,主要就是协议。其他其实都不用配置都是默认值。

    *.res资源文件说明

    默认没有这个文件,手动建立一个,以.res结尾

    资源是一个复制的数据集,它包括Resource name也就是资源名称、

    Volumes也就是卷在一个资源集合里面可以有多个卷复制的使用共用一个复制流;另外还会包含DRBD device,这是一个虚拟块设备,在系统上表现是的/dev/XXX,这里可不是真实的设备,真是的设备都是/dev/sda|b之类的。如果是多个资源再会用到Volumes

    我的资源文件

    注意:网络连接方面建议使用背靠背的直连方式这条链路主要用于复制数据,我这里实验环境就共用一条链路。

    如果你使用LVM如何找到块设备?

    如果你使用普通分区那就是/dev/sda|b[NUMBER]这种形式。

    建立磁盘元数据和启用资源

    保障你使用的块设备是空的否则会初始化失败。两个节点都要这样做初始化。

    启用资源,反之就是 drbdadm down 资源名称

    它这里知道自己是Secondary但是不知道对方,是因为防火墙导致,把两边防火墙关闭就好了,当然你也可以添加测录。

    两台都是这个状态表示正常

    启动服务

    这时候我们之前没有的那个/dev/drbd0就出现了

    设置主节点并创建文件系统

    这一步只能在你确定是主节点的节点上执行,不需要两个节点都执行。设置完成后再次查看状态。

    文件系统只能挂载到主节点上,也只能在设置了主节点后才能对这个/dev/drbd0这个设备格式化和挂载。

    再次查看同步已经完成

    大家肯定觉得我之前安装gitlab的时候设置仓库路径就是/data,没错,我做HA之前把gitlab服务停止掉,然后通过cp –rp命令吧git-data目录都拷贝到其他地方,然后才做的其他操作,当HA完成后使用相同的命令拷贝回来就行。

    主从切换

    监控工具

    drbd-overview 检查角色以及同步状态

    drbdadm status RESOURCE_NAME

    drbdsetup status gitdatadrbd --verbose –statistics 详细信息

    部署遇到的错误

    1. not defined in your config (for this host).

    这是因为配置文件里定义的和主机实际的名称不符。修改/etc/hostname文件。

    2. open(/dev/mapper/gitdata-lv_gitdata) failed: Device or resource busy

    这里是因为我的那个LVM卷挂载了,需要先卸载

    3. ‘drbdmeta 0 v08  terminated with exit code 40

    说明该设备数据不为0

    参考文档

    https://docs.gitlab.com/omnibus/roles/README.html

    https://docs.gitlab.com/ce/administration/high_availability/README.html

    https://docs.linbit.com/docs/users-guide-8.4/#s-distro-packages

    https://www.cnblogs.com/wsl222000/p/5777382.html

    https://segmentfault.com/q/1010000010290689

    https://blog.csdn.net/tjiyu/article/details/52723125

    https://blog.csdn.net/yanggd1987/article/details/50504599

    http://blog.51cto.com/freeloda/1275384

    展开全文
  • RabbitMQ高可用-镜像模式部署使用一、概述RabbitMQ的Cluster集群模式一般分为两种,普通模式和镜像模式。消息队列通过rabbitmq HA镜像队列进行消息队列实体复制。RabbitMQ集群普通模式考虑到性能和存储空间,仅采用...

    RabbitMQ高可用-镜像模式部署使用

    一、概述

    RabbitMQ的Cluster集群模式一般分为两种,普通模式和镜像模式。消息队列通过rabbitmq HA镜像队列进行消息队列实体复制。

    RabbitMQ集群普通模式考虑到性能和存储空间,仅采用元数据同步的方式。即其他节点不会实际存储消息数据。

    生产者和消费者连接在哪个节点上,则消息就存储在哪个节点上,其他节点仅会存储元数据,如果消费者获取的数据不在当前节点上,则内部会路由到实际存储消息的节点上。

    我们在实际集群部署时,考虑到高可用性,一般都会使用镜像模式。

    在RabbitMQ集群中的节点只有两种类型:内存节点/磁盘节点,单节点系统只运行磁盘类型的节点。而在集群中,可以选择配置部分节点为内存节点。内存节点,就是将元数据(metadata)都放在内存里,磁盘节点就是放在磁盘上。如果RabbitMQ是单节点运行,默认就是磁盘节点。在RabbitMQ集群里,至少有一个磁盘节点,它用来持久保存元数据。新的节点加入集群后,会从磁盘节点上拷贝数据。但是,集群里也不必要每个节点都是磁盘节点,这主要是性能问题。例如,压力大的RPC服务,每秒都要创建和销毁数百个队列,如果集群里都是磁盘节点,意味着队列定义在每个节点上,都要写入磁盘才算成功,这样就会非常慢。

    如果集群里只有一个磁盘节点,这个节点挂了,会发生什么?此时消息路由机制仍可正常进行(可以正常投递和消费消息),但是不能做如下事:create queues,create exchanges,create bindings,add users,change permissions,add or remove cluster nodes

    所以,考虑到高可用性,推荐在集群里保持2个磁盘节点,这样一个挂了,另一个还可正常工作。但上述最后一点,往集群里增加或删除节点,要求2个磁盘节点同时在线。

    如果2个节点,则建议都设为磁盘节点,如果3个节点,则可2个磁盘节点+1个内存节点。

    RabbitMQ安装可参考上一篇博文:https://www.cnblogs.com/huligong1234/p/13548573.html

    部署方案:

    CentOS7.8 x64

    mq01:192.168.100

    mq02:192.168.101

    二、配置普通集群模式

    把mq01的cookie值复制到mq02服务器

    配置cookie

    vi /var/lib/rabbitmq/.erlang.cookie

    确保rabbitMQ服务处于停止状态:service rabbitmq-server stop

    确保2个节点的coolie文件使用相同的值

    cookie文件默认路径为/var/lib/rabbitmq/.erlang.cookie(RPM安装)

    或者$home/.erlang.cookie(解压方式安装)

    .erlang.cookie设置可写

    chmod u+w /var/lib/rabbitmq/.erlang.cookie

    加入集群(默认加入的为磁盘节点)

    rabbitmqctl join_cluster rabbit@mq02

    如果要使用内存节点,则可以使用

    rabbitmqctl join_cluster --ram rabbit@mq02

    查看集群状态

    rabbitmqctl cluster_status

    三、配置镜像集群模式

    3.1.通过命令行配置

    rabbitmqctl set_policy [ha-all] "^" '{"ha-mode":"all"}' //策略正则表达式为 “^” 表示所有匹配所有队列名称

    rabbitmqctl set_policy -p [虚拟主机名称] [策略名称如ha-all ] "^" '{"ha-mode":"all" , "ha-sync-mode":"automatic"}'

    在任意一个节点上执行:

    rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all" , "ha-sync-mode":"automatic"}'

    或者指定vhost:

    rabbitmqctl set_policy -p demo ha-all "^" '{"ha-mode":"all" , "ha-sync-mode":"automatic"}'

    将所有队列设置为镜像队列,即队列会被复制到各个节点,各个节点状态保持一直。

    到这里,RabbitMQ 高可用集群就已经搭建好了,最后一个步骤就是搭建均衡器。

    策略名称:自定义

    “^”:匹配所有队列

    ha-sync-mode: 默认为手动,可以配置为自动,区别在于,如果是自动做镜像回复,则该队列会处于不可用状态直到同步完成

    3.2.通过管理界面配置

    配置完后:

    四、配置高可用

    可以采用HAProxy+Keepalived 或 Nginx+Keepalived方式来部署实现。

    我这里根据实际使用场采用另一种简洁方案,如下图所示,仅使用Nginx,配置backup路由策略,减轻部署复杂性。

    五、集群常用命令

    1、加入集群[--ram添加内存模式 默认disk模式]

    rabbitmqctl join_cluster --ram rabbit@mq01

    2、查看集群状态

    rabbitmqctl cluster_status

    3、更改节点模式[顺序 关闭运用-〉更改类型->开启运用]

    rabbitmqctl stop_app –停止运用服务

    rabbitmqctl change_cluster_node_type disc/ram –更改节点为磁盘或内存节点

    rabbitmqctl start_app –开启运用服务

    4、创建策略(集群同步策略……)

    set_policy [-p vhostpath] {name} {pattern} {definition} [priority]

    5、查看策略

    rabbitmqctl list_policies

    6、移除远程offline的节点

    1.节点2停掉应用

    rabbitmqctl stop_app

    2.节点1执行删除

    rabbitmqctl forget_cluster_node rabbit@mq02

    7、设置集群名称

    rabbitmqctl set_cluster_name cluster_name

    8、设置镜像模式

    Rabbit提供镜像功能,需要基于rabbitmq策略来实现,政策是用来控制和修改群集范围的某个vhost队列行为和Exchange行为

    set_policy [-p vhostpath] {name} {pattern} {definition} [priority]

    rabbitmqctl set_policy ha-all "^ha." "{""ha-mode"":""all""}"

    rabbitmqctl set_policy ha-all "^" "{""ha-mode"":""all"",""ha-sync-mode"":""automatic""}"

    rabbitmqctl set_policy -p demo ha-all "^" "{""ha-mode"":""all"",""ha-sync-mode"":""automatic""}"

    9、手动同步queue

    rabbitmqctl sync_queue name

    10、取消queue同步

    rabbitmqctl cancel_sync_queue name

    11、查看所有队列信息

    rabbitmqctl list_queues

    12、获取队列信息

    rabbitmqctl list_queues[-p vhostpath] [queueinfoitem ...]

    Queueinfoitem可以为:name,durable,auto_delete,arguments,messages_ready,messages_unacknowledged,messages,consumers,memory。

    13、获取Exchange信息

    rabbitmqctl list_exchanges[-p vhostpath] [exchangeinfoitem ...]

    Exchangeinfoitem有:name,type,durable,auto_delete,internal,arguments。

    14、获取Binding信息

    rabbitmqctl list_bindings[-p vhostpath] [bindinginfoitem ...]

    Bindinginfoitem有:source_name,source_kind,destination_name,destination_kind,routing_key,arguments。

    15、获取Connection信息

    rabbitmqctl list_connections [connectioninfoitem ...]

    Connectioninfoitem有:recv_oct,recv_cnt,send_oct,send_cnt,send_pend等。

    16、获取Channel信息

    rabbitmqctl list_channels[channelinfoitem ...]

    Channelinfoitem有consumer_count,messages_unacknowledged,messages_uncommitted,acks_uncommitted,messages_unconfirmed,prefetch_count,client_flow_blocked。

    六、rabbitmq中镜像队列注意点

    RabbitMQ的mirror queue(镜像队列)机制是最简单的队列HA方案,它通过在cluster的基础上增加ha-mode、ha-param等policy选项,可以根据需求将cluster中的队列镜像到多个节点上,从而实现高可用,消除cluster模式中队列内容单点带来的风险。

    在使用镜像队列之前,有几点注意事项:

    1.镜像队列不能作为负载均衡使用,因为每个操作在所有节点都要做一遍。

    2.ha-mode参数和durable declare对exclusive队列都不生效,因为exclusive队列是连接独占的,当连接断开,队列自动删除。所以实际上这两个参数对exclusive队列没有意义。

    3.将新节点加入已存在的镜像队列时,默认情况下ha-sync-mode=manual,镜像队列中的消息不会主动同步到新节点,除非显式调用同步命令。当调用同步命令(via rabbitmqctl or web-based ui)后,队列开始阻塞,无法对其进行操作,直到同步完毕。当ha-sync-mode=automatic时,新加入节点时会默认同步已知的镜像队列。由于同步过程的限制,所以不建议在生产环境的active队列(有生产消费消息)中操作。

    4.每当一个节点加入或者重新加入(例如从网络分区中恢复回来)镜像队列,之前保存的队列内容会被清空。

    5.镜像队列有主从之分,一个主节点(master),0个或多个从节点(slave)。当master宕掉后,会在slave中选举新的master。选举算法为最早启动的节点。

    6.当所有slave都处在(与master)未同步状态时,并且ha-promote-on-shutdown policy设置为when-syned(默认)时,如果master因为主动的原因停掉,比如是通过rabbitmqctl stop命令停止或者优雅关闭OS,那么slave不会接管master,也就是说此时镜像队列不可用;但是如果master因为被动原因停掉,比如VM或者OS crash了,那么slave会接管master。这个配置项隐含的价值取向是优先保证消息可靠不丢失,放弃可用性。如果ha-promote-on-shutdown policy设置为alway,那么不论master因为何种原因停止,slave都会接管master,优先保证可用性。

    7.镜像队列中最后一个停止的节点会是master,启动顺序必须是master先起,如果slave先起,它会有30秒的等待时间,等待master启动,然后加入cluster。当所有节点因故(断电等)同时离线时,每个节点都认为自己不是最后一个停止的节点。要恢复镜像队列,可以尝试在30秒之内同时启动所有节点。

    8.对于镜像队列,客户端basic.publish操作会同步到所有节点;而其他操作则是通过master中转,再由master将操作作用于salve。比如一个basic.get操作,假如客户端与slave建立了TCP连接,首先是slave将basic.get请求发送至master,由master备好数据,返回至slave,投递给消费者。

    9.由8可知,当slave宕掉时,除了与slave相连的客户端连接全部断开之外,没有其他影响。当master宕掉时,会有以下连锁反应: 1)与master相连的客户端连接全部断开。 2)选举最老的slave为master。若此时所有slave处于未同步状态,则未同步部分消息丢失。 3)新的master节点requeue所有unack消息,因为这个新节点无法区分这些unack消息是否已经到达客户端,亦或是ack消息丢失在到老master的通路上,亦或是丢在老master组播ack消息到所有slave的通路上。所以处于消息可靠性的考虑,requeue所有unack的消息。此时客户端可能受到重复消息。 4)如果客户端连着slave,并且basic.consume消息时指定了x-cancel-on-ha-failover参数,那么客户端会收到一个Consumer Cancellation Notification通知,Java SDK中会回调Consumer接口的handleCancel()方法,故需覆盖此方法。如果不指定x-cancel-on-ha-failover参数,那么消费者就无法感知master宕机,会一直等待下去。 上面列出的注意事项整理自官方的HA文档。

    七、rabbitmq中镜像队列的故障恢复

    前提:两个节点(A和B)组成一个镜像队列。

    1.场景1:A先停,B后停。 该场景下B是master(disk,A是ram),只要先启动B,再启动A即可。或者先启动A,再在30秒之内启动B即可恢复镜像队列。

    2.场景2: A, B同时停。 该场景可能是由掉电等原因造成,只需在30秒之内连续启动A和B即可恢复镜像队列。

    3.场景3:A先停,B后停,且A无法恢复。 该场景是场景1的加强版,因为B是master,所以等B起来后,在B节点上调用rabbitmqctl forget_cluster_node A,解除与A的cluster关系,再将新的slave节点加入B即可重新恢复镜像队列。

    4.场景4:A先停,B后停,且B无法恢复。 该场景是场景3的加强版,比较难处理,早在3.1.x时代之前貌似都没什么好的解决方法,但是现在已经有解决方法了,在3.4.2版本亲测有效(我们当前使用的是3.3.5)。因为B是master,所以直接启动A是不行的,当A无法启动时,也就没办法在A节点上调用rabbitmqctl forget_cluster_node B了。新版本中,forget_cluster_node支持–offline参数,offline参数允许rabbitmqctl在离线节点上执行forget_cluster_node命令,迫使RabbitMQ在未启动的slave节点中选择一个作为master。当在A节点执行rabbitmqctl forget_cluster_node –offline B时,RabbitMQ会mock一个节点代表A,执行forget_cluster_node命令将B剔出cluster,然后A就能正常启动了。最后将新的slave节点加入A即可重新恢复镜像队列。

    5.场景5: A先停,B后停,且A、B均无法恢复,但是能得到A或B的磁盘文件。 该场景是场景4的加强版,更加难处理。将A或B的数据库文件(默认在$RABBIT_HOME/var/lib目录中)拷贝至新节点C的目录下,再将C的hostname改成A或B的hostname。如果拷过来的是A节点磁盘文件,按场景4处理方式;如果拷过来的是B节点磁盘文件,按场景3处理方式。最后将新的slave节点加入C即可重新恢复镜像队列。

    6.场景6:A先停,B后停,且A、B均无法恢复,且无法得到A或B的磁盘文件。 洗洗睡吧,该场景下已无法恢复A、B队列中的内容了。

    八、更多参考资料

    展开全文
  • 1. 安装helm1.1. 安装helm1.2. 基本命令参考2. 安装Rabbitmq2.1. 下载chart包2.2.... 设置持久化存储2.2.8. 设置service2.3. 部署rabbitmq2.3.1. 创建命名空间2.3.2. 安装2.3.3. 查看rabbitmq安装状态.

    参考说明:

    安装思路: Kubernetes全栈架构师:基于世界500强的k8s实战课程
    镜像模式: RabbitMQ高可用-镜像模式部署使用

    1. 安装helm

    1.1. 安装helm

    • 项目地址:https://github.com/helm/helm

    • 安装:

    # 下载(自行选择版本)
    wget https://get.helm.sh/helm-v3.6.1-linux-amd64.tar.gz
    
    # 解压
    tar zxvf helm-v3.6.1-linux-amd64.tar.gz
    
    # 安装
    mv linux-amd64/helm /usr/local/bin/
    
    # 验证
    helm version
    

    1.2. 基本命令参考

    # 添加仓库
    helm repo add 
    # 查询 charts
    helm search repo
    # 更新repo仓库资源
    helm repo update
    # 查看当前安装的charts
    helm list -A
    # 安装
    helm install 
    # 卸载
    helm uninstall
    # 更新
    helm upgrade
    

    2. 安装RabbitMQ

    2.1. 下载chart包

    # 添加bitnami仓库
    helm repo add bitnami https://charts.bitnami.com/bitnami
    
    # 查询chart
    helm search repo bitnami
    
    # 创建工作目录
    mkdir -p ~/test/rabbitmq
    cd ~/test/rabbitmq
    
    # 拉取rabbitmq
    helm pull bitnami/rabbitmq
    
    # 解压
    tar zxvf [rabbitmq] 
    

    image-20210725143655097

    2.2. 配置参数

    2.2.1. 编辑配置文件

    官方配置参考:https://github.com/bitnami/charts/tree/master/bitnami/rabbitmq

    • 进入工作目录,配置持久化存储、副本数等
    • 建议首次部署时直接修改values中的配置,而不是用–set的方式,这样后期upgrade不必重复设置。
    cd  ~/test/rabbitmq/rabbitmq
    vim values.yaml
    

    2.2.2. 设置管理员密码

    • 方式一:在配置中指定
    auth:
      username: admin
      password: "admin@mq"
      existingPasswordSecret: ""
      erlangCookie: secretcookie
    

    image-20210725144921881

    • 方式二:在安装时通过set方式指定(避免密码泄露)
    --set auth.username=admin,auth.password=admin@mq,auth.erlangCookie=secretcookie
    

    2.2.3. rabbitmq集群意外宕机强制启动

    • 当rabbitmq启用持久化存储时,若rabbitmq所有pod同时宕机,将无法重新启动,因此有必要提前开启clustering.forceBoot
    clustering:
      enabled: true
      addressType: hostname
      rebalance: false
      forceBoot: true
    

    image-20210725153657694

    2.2.4. 模拟rabbitmq集群宕机(可跳过)

    • 未设置clustering.forceBoot时,如下图,通过删除rabbitmq集群所有pod模拟宕机,可见集群重新启动时第一个节点迟迟未就绪

    image-20210725154535139

    • 报错信息如下:

    image-20210725154742499

    • 启用clustering.forceBoot,并更新rabbitmq,可见集群重启正常
    helm upgrade rabbitmq -n test .
    kubectl delete pod -n test rabbitmq-0
    get pod -n test -w
    

    image-20210725155446725

    2.2.5. 指定时区

    extraEnvVars: 
      - name: TZ
        value: "Asia/Shanghai"
    

    image-20210725145746565

    2.2.6. 指定副本数

    replicaCount: 3
    

    image-20210725153715021

    2.2.7. 设置持久化存储

    • 若无需持久化,将enabled设置为false

    • 持久化需使用块存储,本文通过aws的ebs-csi创建storageClass,亦可使用自建块存储storageClass

    注:sc最好具备扩容属性

    persistence:
      enabled: true
      storageClass: "ebs-sc"
      selector: {}
      accessMode: ReadWriteOnce
      existingClaim: ""
      size: 8Gi
    

    image-20210725153802203

    2.2.8. 设置service

    • 默认通过ClusterIP暴露5672(amqp)和15672(web管理界面)等端口供集群内部使用,外部访问方式将在第三章中详细说明
    • 不建议在values中直接配置nodeport,不方便后期灵活配置

    2.3. 部署RabbitMQ

    2.3.1. 创建命名空间

    cd  ~/test/rabbitmq/rabbitmq
    kubectl create ns test 
    

    2.3.2. 安装

    • 方式一 :在配置文件中指定管理员帐号密码
    helm install rabbitmq -n test .
    

    image-20210725151045382

    • 方式二:通过set方式指定密码
    helm install rabbitmq -n test . \
      --set auth.username=admin,auth.password=admin@mq,auth.erlangCookie=secretcookie
    

    后期upgrade时亦须指定上述参数

    2.3.3. 查看rabbitmq安装状态

    • 查看rabbitmq安装进度
    kubectl get pod -n test -w
    
    • 待各节点都正常启动后,查看svc
    kubectl get svc -n test
    

    image-20210725151643559

    当前rabbitmq通过ClusterIP方式暴露,供集群内部访问;外部访问方式将在下章介绍。

    • 查看集群状态
    # 进入pod
    kubectl exec -it -n test rabbitmq-0 -- bash
    
    # 查看集群状态
    rabbitmqctl cluster_status
    
    # 列出策略(尚未设置镜像模式)
    rabbitmqctl list_policies
    
    #设置集群名称
    rabbitmqctl set_cluster_name [cluster_name]
    

    3. 配置RabbitMQ集群外部访问方式

    3.1. 建议方式

    • 不建议在默认安装方式中指定nodeport,而是另外创建

    • 5672:建议通过service-私网负载均衡器暴露给私网其它应用使用

    • 15672:建议通过ingressservice-公网负载均衡器暴露给外界访问

    端口暴露方式(见下文方式三)访问方式
    5672Service-LoadBalancer(配置为私网负载均衡器)k8s集群内:rabbitmq.test:5672
    私网:私网负载均衡IP:5672
    15672ingress-ALB(配置为公网负载均衡器)公网负载均衡URL

    注:本文使用亚马逊托管版k8s集群,已配置aws-load-balancer-controller

    3.2. 方式一:Service-Nodeport(5672,15672)

    • 获取原始Service-ClusterIP的yaml文件:
    cd /test/rabbitmq
    kubectl get svc -n test rabbitmq -o yaml > service-clusterip.yaml
    
    • 参考service-clusterip,创建service-nodeport.yaml
    cp service-clusterip.yaml service-nodeport.yaml
    
    • 配置service-nodeport(去除多余信息)
    apiVersion: v1
    kind: Service
    metadata:
      name: rabbitmq-nodeport
      namespace: test
    spec:
      ports:
      - name: amqp
        port: 5672
        protocol: TCP
        targetPort: amqp
        nodePort: 32672
      - name: http-stats
        port: 15672
        protocol: TCP
        targetPort: stats
        nodePort: 32673
      selector:
        app.kubernetes.io/instance: rabbitmq
        app.kubernetes.io/name: rabbitmq
      type: NodePort
    
    • 创建service
    kubectl apply -f service-nodeport.yaml
    kubectl get svc -n test
    

    image-20210725165223728

    • 即可通过NodeIP:Port访问服务。

    3.3. 方式二:Service-公网LoadBalancer(5672,15672)

    • 创建service-loadbalancer.yaml
    vim service-loadbalancer.yaml
    
    apiVersion: v1
    kind: Service
    metadata:
      name: rabbitmq-loadbalance
      namespace: test
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-type: external
        service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
        service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
    spec:
      ports:
      - name: amqp
        port: 5672
        protocol: TCP
        targetPort: amqp
      - name: http-stats
        port: 15672
        protocol: TCP
        targetPort: stats
      selector:
        app.kubernetes.io/instance: rabbitmq
        app.kubernetes.io/name: rabbitmq
      type: LoadBalancer
    
    • 创建service:
    kubectl apply -f service-loadbalancer.yaml
    kubectl get svc -n test
    

    image-20210725171840468

    浏览器登录控制台: http://k8s-test-rabbitmq-fbff138068-d79b31bdcb2f6f2b.elb.cn-northwest-1.amazonaws.com.cn:15672:

    image-20210725172013248

    3.4. 方式三:Service-私网LoadBalancer(5672)+Ingress-公网ALB(15672)

    3.4.1. 创建Service-私网LoadBalancer

    vim service-lb-internal.yaml
    
    apiVersion: v1
    kind: Service
    metadata:
      name: rabbitmq-lb-internal
      namespace: test
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-type: external
        service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
        # service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing #注释后即为私网
    spec:
      ports:
      - name: amqp
        port: 5672
        protocol: TCP
        targetPort: amqp
      selector:
        app.kubernetes.io/instance: rabbitmq
        app.kubernetes.io/name: rabbitmq
      type: LoadBalancer
    
    kubectl apply -f service-lb-internal.yaml
    

    3.4.2. 创建Ingress-ALB

    vim ingress-alb.yaml
    
    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: rabbitmq
      namespace: test
      annotations:
        kubernetes.io/ingress.class: alb
        alb.ingress.kubernetes.io/scheme: internet-facing
        alb.ingress.kubernetes.io/target-type: ip
      labels:
        app: rabbitmq
    spec:
      rules:
        - http:
            paths:
              - path: /*
                backend:
                  serviceName: "rabbitmq"
                  servicePort: 15672
    
    kubectl apply -f ingress-alb.yaml
    

    image-20210725172536738

    浏览器登录控制台: k8s-test-rabbitmq-4623cb772f-1674334573.cn-northwest-1.elb.amazonaws.com.cn

    image-20210725172921696

    4. 配置镜像模式实现高可用

    4.1. 镜像模式介绍

       镜像模式:将需要消费的队列变为镜像队列,存在于多个节点,这样就可以实现 RabbitMQ 的 HA 高可用性。作用就是消息实体会主动在镜像节点之间实现同步,而不是像普通模式那样,在 consumer 消费数据时临时读取。缺点就是,集群内部的同步通讯会占用大量的网络带宽。

    4.2. rabbitmqctl设置镜像模式

    # 进入pod
    kubectl exec -it -n test rabbitmq-0 -- bash
    
    # 列出策略(尚未设置镜像模式)
    rabbitmqctl list_policies
    
    # 设置镜像模式
    rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all" , "ha-sync-mode":"automatic"}'
    
    # 再次列出策略
    rabbitmqctl list_policies
    

    image-20210725173209193

    控制台查看

    image-20210725173257368

    5. 清理RabbitMQ集群

    5.1. 卸载RabbitMQ

    helm uninstall rabbitmq -n test
    

    5.2. 删除pvc

    kubectl delete pvc -n test data-rabbitmq-0 data-rabbitmq-1 data-rabbitmq-2
    

    5.3. 清理手动创建的service,ingress

    kubectl delete -f service-nodeport.yaml
    kubectl delete -f service-loadbalancer.yaml
    kubectl delete -f ingress-alb.yaml
    

    若本篇内容对您有所帮助,请三连点赞,关注,收藏支持下~

    展开全文
  • redis3.0版本之前只支持单例模式,在3.0版本及以后才支持集群 redis集群采用P2P模式,是完全去中心化的,存在中心节点或者代理节点; 为了实现集群的高可用,即判新节点是否健康(能否正常使用), redis-cluster有...



    一、redis群集介绍

    • redis是一个开源的kevvalue存储系统,受到了广大互联网公司的青睐。redis3.0版本之前只支持单例模式,在3.0版本及以后才支持集群 redis集群采用P2P模式,是完全去中心化的,不存在中心节点或者代理节点;

    • 为了实现集群的高可用,即判新节点是否健康(能否正常使用), redis-cluster有一个投票容错机制:
      如果集群中超过半数的节点投票认为某个节点挂了,那么这个节点就挂了(fail)。如果集群中任意一个节点挂了,而且该节点没有从节点(备份节点),那么这个集群就挂了

    • 为什么没有备份节点,集群会挂掉

    因为集群内置了16384个slot(哈希槽),并且把所有的物理节点映射到了这16384[0-16383]个slot上,或者说把这些slot均等的分配给了各个节点。
    当需要在Redis集群存放一个数据(key-value)时,redis会先对这个key进行crc16算法,然后得到一个结果再把这个结果对16384进行求余,这个余数会对应[0-16383]其中一个槽,进而决定key-value存储到哪个节点中。所以一旦某个节点挂了,该节点对应的slot就无法使用,那么就会导致集群无法正常工作。
    示例(三个节点) : 节点A覆盖0-5460; 节点B覆盖5461-10922; 节点C覆盖10923-16383
    即:每个节点有5460个哈希槽 新增一个节点: 节占A覆盖1365-5460 节占B覆盖6827-10922
    节点C覆盖12288-16383 节点D覆盖0-1364.5461-6826.10923-12287
    即:每个节点有4095个哈希槽 综上所述,每个Redis集群理论上最多可以有16384个节点。

    二、Redis三种模式介绍

    • 在Redis中,实现高可用的技术主要包括持久化、主从复制、哨兵和集群,下而分别说明它们的作用,以及解决了什么样的问题

    1.主从模式

    • 通过持久化功能,redis保证了即使在服务器重启的情况下也不会丢失(或少量丢失)数据,因为持久化会把内存中的数据保存到硬盘上,重启会从硬盘上加载数据,但是由于数据是存储在一台服务器上的,如果这台服务器出现硬盘故障等问题,也会导致数据丢失。
    • 为了避免单点故障,通常的做法是将数据库复制多个副本以部署在不同的服务器上,这样即使有一台服务器出现故障,其他服务器依然可以继续提供服务,为此,redis提供了复制(replication)功能,可以实现当一台数据库中的数据更新后,自动将更新的数据同步到其他数据库上。
    • 在复制的概念中,数据库分为两类,一类是主数据库(master),另一类是从数据(slave)。主数据可以进行读写操作,当写操做导致数据变化时自动将数据同步给数据库,而从数据库一般是只读的,并接收主数据同步过来的数据。一个主数据库可以拥有多个从数据库,而一个从数据库只能拥有一个主数据库

    1.1 流程图

    mark

    • ① 若启动一个Slave机器进程,则它会向Master机器发送一个"sync_command"命令,请求同步连接

    • ② 无论是第一次连接还是重新连接,Master机器都会启动一个后台进程,将数据快照(RDB)保存到
      数据文件中(执行rdb操作),同时Master还会记录修改数据的所有命令并缓存在数据文件中。

    • ③ 后台进程完成缓存操作之后,Master机器就会向Slave机器发送数据文件,Slave端机器将数据
      文件保存到硬盘上,然后将其加载到内存中,接着Master机器就会将修改数据的所有操作一并发送给Slave端机器。若Slave出现故障导致宕机,则恢复正常后会自动重新连接。

    • ④ Master机器收到slave端机器的连接后,将其完整的数据文件发送给Slave端机几器,如果Mater同时收到多个slave发来的
      同步请求则Master会在后台启动一个进程以保存数据文件,然后将其发送给所有的Slave端机器,确保所有的Slave端机器都正常。

    2.哨兵模式(Sentinel)

    2.1 哨兵模式集群架构

    • 哨兵是Redis集群架构中非常重要的一个组件,哨兵的出现主要是解决了主从复制出现故障时需要人为干预的问题

    2.2 哨兵模式主要功能

    • 集群监控:负责监控Redismaster和slave进程是否正常工作
    • 消息通知:如果某个Redis实例有故障,那么哨兵负责发送消息作为报敬通知给管理员
    • 故障转移:如果masternode挂掉了,会自动转移到slave node上
    • 配置中心:如果故障转移发生了,通知client客户端新的master地址

    使用一个或者多个哨兵(Sentinel)实例组成的系统,对redis节点进行监控 在主节点出现故障的情况下, 能将从节点中的一个升级为主节点,进行故障转义,保证系统的可用性。

    2.3 哨兵们监控整个系统节点的过程(图2)

    • 首先主节点的信息是配置在哨兵(Sentinel)的配置文件中

    • 哨兵节点会和配置的主节点建立起两条连接命令连接和订阅连接
      PS:Redis发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消 息,订阅者 (sub) 接收消息。

    • 哨兵会通过命令连接每10s发送一次INFO命令,通过INFO命令,主节点会返回自己的run_id和自己的从节点信息

    • 哨兵会对这些从节点也建立两条连接命令连接和订阅连接

    • 哨兵通过命令连接向从节点发送INFO命令,获取到他的一些信息:
      run id(redis服务器id)
      role(职能)
      从服务器的复制偏移量offset
      其他

    • 通过命令连接向服务器的sentinel:hello频道发送一条消息,内容包括自己的ip端口、run id、配置(后续投票的时候会用到)等

    • 通过订阅连接对服务器的sentinel:hello频道做了监听,所以所有的向该频道发送的哨兵的消息都能被接受到

    • 解析监听到的消息,进行分析提取,就可以知道还有那些别的哨兵服务节点也在监听这些主从节点了,更新结构体将这些
      哨兵节点记录下来

    • 向观察到的其他的哨兵节点建立命令连接----没有订阅连接

    2.4 哨兵模式下的故障迁移

    • 主观下线
      哨兵(Sentinel)节点会每秒一次的频率向建立了命令连接的实例发送PING命令,如果在down-after-milliseconds毫秒内没有做出有效响应包括(PONG/LOADING/MASTERDOWN)以外的响应,哨兵就会将该实例在本结构体中的状态标记为SRI_S_DOWN主观下线

    • 客观下线
      当一个哨兵节点发现主节点处于主观下线状态是,会向其他的哨兵节点发出询问,该节点是不是已经主观下线了。如果超过配置参数quorum个节点认为是主观下线时,该哨兵节点就会将自己维护的结构体中该主节点标记为SRIO DOWN客观下线询问命令SENTINEL is-master-down-by-addr

    • master选举
      在认为主节点客观下线的情况下,哨兵节点节点间会发起一次选举,命令为:SENTINEL is-master-down-by-addr
      只是runid这次会将自己的runid带进去,希望接受者将自己设置为主节点。如果超过半数以上的节点返回将该节点标记为leacer的情况下,会有该leader对故障进行迁移

    • ④ 故障转移

    ####在从节点中挑选出新的主节点
    		通讯正常
    		优先级排序
    		优先级相同时选择offset最大的
    
    ###将该节点设置成新的主节点SLAVEOF no one,并确保在后续的INGO命令时 该节点返回状态为master 
    ###将其他的从节点设置成从新的主节点复制,SLAVEOF命令
    ###将旧的主节点变成新的主节点的从节点
    
    PS:优缺点
    #优点:
    		高可用,哨兵模式是基于主从模式的,所有主从模式的优点,哨兵模式都具有有;主从可以自动切换,系统更健壮,可用性更高
    
    #缺点:
    		redis比较难支持在线扩容,在群集容量达到上限时在线扩容会变得很复杂
    

    3.Cluster群集

    • redis的哨兵模式基本已经可以实现高可用、读写分离,但是在这种模式每台redis服务器都存储相同的数据,很浪费内存资源,所以在redis3.0上加入了Cluster群集模式,实现了redis的分布式存储,也京是说每台redis节点存储着不同的内容根据官方推荐,集群部署至少要3台以上的master节点,最好使用3主3从六个节点的模式。

    • Cluster群集由多个redis服务器组成的分布式网络服务群集,群集之中有多个master主节点,每一个主节点都可读可写,节点之间会相互通信,两两相连,redis群集无中心节点

    • 在redis-Cluster群集中,可以给每个一个主节点添加从节点,主节点和从节点直接尊循主从模型的特性,当用户需要处理更多读请求的时候,添加从节点可以扩展系统的读性能

    • redis-cluster的故障转移:redis群集的主机节点内置了类似redissentinel的节点故障检测和自动故障转移功能,当群集中的某个主节点下线时,群集中的其他在线主节点会注意到这一点,并且对已经下线的主节点进行故障转移

    • 集群进行故障转移的方法和redis sentinel进行故障转移的方法基本一样,不同的是,在集群里面,故障转移是由集群中其他在线的主节点负责进行的,所以群集不必另外使用redis sentinel


    总结

    1. 主从复制
      主从复制是高可用Redis的基础,哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份,以及对于读操作的负载均衡和简单的故障恢复。
      缺陷
         故障恢复无法自动化;
         写操作无法负载均衡;
         存储能力受到单机的限制。
    2. 哨兵
          在主从复制的基础上,哨兵实现了自动化的故障恢复。
      缺陷
         写操作无法负载均衡:存储能力受到单机的限制。
    3. 集群
      通过集群,Redis解决了写操作无法负载均衡,以及存储能力受到单机限制的问题,实现了较为完善的高可用方案。
    展开全文
  • 本文涉及到近年来 Redis 多实例架构的演变过程,包括普通主从架构(Master、slave 可进行写读分离)、哨兵模式下的主从架构、Redis-cluster 高可用架构(Redis 官方默认 cluster 下进行读写分离)的简介。同时还介绍...
  • 点击上方蓝色“明哥的IT随笔”,关注并选择“设星标”,keep striving! 欢迎关注知乎同名专栏!一。背景笔者所在公司某系统在某证券公司现场部署时,客户出于自己集群使用规划的考量...
  • Redis高可用模式 1、主从复制:主从复制是高可用Redis的基础,哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份,以及对于读操作的负载均衡和简单的故障恢复。 缺陷: ●故障恢复无法...
  • 已付费购买专栏的朋友,请在申请查看权限时,备注你的... 文章部分截图如下: 更多详情请见以下链接: 【腾讯文档】Flink K8S模式采用KubernetesHaServicesFactory类来做HA(高可用),HA数据存储在哪里?又存了些什么
  • 我曾提到秒杀场次信息是聚合根,它聚合了秒杀商品信息和秒杀专题信息。...什么是 KV 存储 KV 是 Key-Value 的缩写,KV 存储也叫键值对存储。简单来说,它是利用 Key 做索引来实现数据的存储、修改、查询和删除功能。
  • 模式映像数据库

    2021-03-15 16:45:57
    从数据库管理角度来看,数据库系统通常采用三级模式结构。这是数据库管理系统内部的结构。 从数据库最终用户角度来看,数据库系统的结构分为集中式结构、文件服务器结构、客户端/服务器结构等。这是数据库系统外部...
  • 可用

    2021-07-22 00:37:02
    中文名高可用性外文名High Availability衡量标准平均无故障时间简称HA目的减少停工时间作用保持系统服务的高度可用性高可用性介绍编辑语音计算机的高可用性对于可修复系统, 系统的平均寿命指系统发生失效前的平均...
  • Prometheus高可用 3.1 基本HA: 服务可用性 3.2 基本HA+远程存储 3.3 基本HA+远程存储+联邦集群 3.4 按照实例进行功能分区 3.5 高可用方案选择 4.Alertmanager高可用 4.1 Gossip协议 1.Prometheus存储 Prometheus...
  • 但是,在讨论这些方法之前,了解Windows 10中的安全模式什么,以及无法进入安全模式会带来什么不利影响十分重要。安全模式确实有很多优点,特别是在对一个系统进行基本更改时,它具有可比拟的优越性。对于那些...
  • redis6.2 使用 TLS 的部署"三种高可用模式"安装redis6.2 并启用TLS加密安装创建TLS证书编写配置文件systemd管理测试连接redis 主从 配置 tls安装拷贝master 证书 到 slave编写配置文件systemd管理验证主从服务...
  • Docker 部署 redis 高可用(哨兵模式)

    万次阅读 2020-12-23 15:27:25
    哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。 本文介绍基于docker和...
  • 《RocketMQ技术内幕》作者、博客:https://www.codingw.net/,专注成体系剖析java主流中间件,打造完备的互联网分布式架构体系。一文详细剖析分布式存储领域的负载均衡(数据分片)与数据一致性方案设计理念
  • 我是廖志伟,一名Java开发工程师、幕后大佬社区创始人、Java领域优质...拥有多年一线研发经验,研究过各种常见框架及中间件的底层源码,对于大型分布式、微服务、三高架构(高性能、高并发、高可用)有过实践架构经验。
  • MySQL数据库作为最基础的数据存储服务之一,在整个系统中有着非常重要的地位,因此要求其具备高可用性是无可厚非的。有很多解决方案能实现不同的SLA(服务水平协定),这些方案可以保证数据库服务器在硬件或软件出现...
  • 探索 Windows Server 文件服务器高可用性选项已完成6 分钟文件服务代表 Windows Server 工作负载的主要类型之一。 在许多情况下,其可用性对业务运营至关重要。 Windows Server 提供了多种方法来帮助确保可用性。...
  • 正如标题描述, 是某个语法在低版本中受支持, 只需要升级到高版本即可. 步骤: > 第一种 : 使用快捷键 Alt + Enter 或点击黄色的的提示调出快速操作 选择 将该项目升级 C# 语言版本 “8.0” 如果没有这一...
  • db+Nacos的方式部署高可用集群模式 环境: 电脑环境:Win10专业版 java : jdk1.8.0 MySQL: 5.7 spring cloud alibaba : 2.2.5.RELEASE spring boot : 2.3.11.RELEASE spring cloud : Hoxton.SR8 nacos: 1.4.1 seata...
  • 设计模式,七大原则 开闭原则 对扩展开放(提供方),对修改关闭(使用方)。 抽象提供方的方法,调用方传入抽象类的子类实现,提供方调用子类方法完成具体实现 里氏替换原则 所有引用基类的地方都必须能透明的使用其...
  • 很多玩家都喜欢玩gta5ol,要是发生...最直接的办法,改dns,这个办法 成功率仅仅10%,原理就是通过改变ip改变网关,让你连接R星服务器速度变快。是通过更改DNS,可下载360里安全卫士,直接修改DNS,提高网速,从而...
  • 下载地址: 4、C盘中,只要是自己下载的软件或文件都可以删除(如果系统让删除,请开机按F8到安全模式中删除)。 设置虚拟内存方法:右击我的电脑/属性/高级/性能中的设置/高级/虚拟内存中的更改/选自定义大小,...
  • 1、什么是主机高可用 2、主机高可用主流解决方案 3、主机HA能做什么 4、主机HA高可用定义和切换流程 5、HA三种经典工作方式 6、主机HA的核心组件和实现原理 7、哪些场景适合主机HA 8、主机HA高可用选择参考 9、...
  • TDengine高可用分布式集群详解

    千次阅读 多人点赞 2021-06-23 19:23:04
    1)高可用 如果一个服务能够正常使用,那么我们称之可用”,比如你现在能看到这篇文章,说明网站处于 “可用” 状态。 可用性定义在足够长的时间里,一个服务可用的时间,服务可用时间越长越好。 一般用可...
  • 存储容量

    千次阅读 2021-07-25 05:56:52
    中文名存储容量所属学科计算机科学与技术存储容量单位简介语音网络上的所有信息都是以“位”(bit)单位传递的,一个位就代表一个0或1。每8个位(bit)组成一个字节(byte)。字节是什么概念呢?一个英文字母就占用一个...
  • 一、前言 作为一款消息中间件产品,高可用起着至关重要的作用。那 RocketMQ 是怎么保证高可用机制的呢?...RocketMQ 消息存储的高可用例外。既然这样,那我们就从这两个方向来分析一下。 1、主从复制 2、
  • 声明:本系列博客原创,最先发表在拉勾教育,其中一部分免费阅读部分。被读者各种搬运至各大网站。所有其他的来源均抄袭。 《2021年最新版大数据面试题全面开启更新》 如何实现生产环境中的Flink高可用 ...
  • Nacos 的高可用不仅仅存在于服务端,同时也存在于客户端,以及一些与可用性相关的功能特性中,这些点组装起来,共同构成了 Nacos 的高可用。 客户端高可用 先统一一下语义,在微服务架构中一般会有三个角色: ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 483,720
精华内容 193,488
关键字:

为什么存储模式不可用