精华内容
下载资源
问答
  • 突破存储跨中心双活方案设计阶段难点(一):脑裂风险存储跨中心双活方案设计阶段该如何尽量避免脑裂?如何避免脑裂是每个双机系统都要重视的问题,存储双活系统尤其如此,脑裂会带来长时间的存储读写IO HANG住,轻则...

    突破存储跨中心双活方案设计阶段难点(一):脑裂风险

    存储跨中心双活方案设计阶段该如何尽量避免脑裂?

    如何避免脑裂是每个双机系统都要重视的问题,存储双活系统尤其如此,脑裂会带来长时间的存储读写IO HANG住,轻则导致业务性能下降,重则因磁盘IO超时,导致数据库挂起甚至宕机,对生产业务系统造成重大影响。所以在存储跨中心双活架构设计时,究竟应该如何尽量避免脑裂?

    存储跨中心双活方案设计阶段该如何尽量避免脑裂?

    如何避免脑裂是每个双机系统都要重视的问题,存储双活系统尤其如此,脑裂会带来长时间的存储读写IO HANG住,轻则导致业务性能下降,重则因磁盘IO超时,导致数据库挂起甚至宕机,对生产业务系统造成重大影响。所以在存储跨中心双活架构设计时,究竟应该如何尽量避免脑裂?

    解析和解答:

    ▼▼▼

    ■邓毓 某农信社资深骨干工程师

    数据中心脑裂简单说就是两个数据中心间的网络和存储链路同时发生中断,导致两个数据中心内的应用、数据库或者操作系统同时抢占和利用共享的资源,造成资源的数据不一致,产生重大影响。

    这个问题是存储跨中心双活方案设计、实施阶段不可避免要遇到的问题。各个存储厂商、存储虚拟化产品厂商都有自己的避免脑裂的方式:

    (1)IBM SVC ESC/HYPERSWAP 或者IBM V9000/V7000/V5000 HYPERSWAP

    对于上述存储双活方案架构来说,呈现的是一种对称式的整体架构,为了防范脑裂,仲裁站点是必需的。在仲裁站点中,基于IP的quorum节点和物理quorum磁盘都可以提供脑裂的仲裁服务,存储双活集群最多能够拥有3个物理quorum磁盘,也可以选择最多5个基于IP的quorum节点,这个基于IP的quorum节点可以是任何站点的任何服务器,或者公有云的一个虚拟机,在这个服务器内运行一个简单的仲裁JAVA程序即可。所以可以看到,基于IP的仲裁服务其实大大提高了仲裁站点的选择空间,节省了企业双活建设成本,只要求IP可达,延时在80MS内即可。

    但是,只有物理quorum磁盘的仲裁方式才能够被用来做T3 Recovery,所有的SVC节点都会将节点的相关信息同步至该物理quorum磁盘,当节点或者集群出现故障时,可以通过该物理quorum磁盘进行T3 Recovery

    在SVC集群中有一个概念configuration node---配置节点,是配置SVC集群后,系统自动产生的保存着所有系统配置行为的节点,不能人工更改配置节点,当配置节点失效后,系统会自动选择新的配置节点,配置节点十分重要,它对SVC节点仲裁胜利起着决定性作用,仲裁胜利的排序规则通常如下:

    1.配置节点(配置节点获得仲裁胜利的概率最高)

    2.距离仲裁站点近的节点(探测延时较低的SVC节点获得仲裁胜利的概率次之)

    3.距离仲裁站点远的节点(探测延时较低的SVC节点获得仲裁胜利的概率最低)

    举例:

    当两站点间光纤链路中断,第三站点仲裁节点活动时,脑裂发生,将通过投票仲裁选举获胜的站点,按照上述的仲裁胜利规则,configuration node位于节点2,选举站点2优先赢得仲裁,通过站点2恢复业务的正常存储访问。

    当第三站点仲裁节点不活动时,不影响主机的正常存储访问,但是此时,两站点间光纤链路也中断了,发生脑裂,这时因为节点2为configuration node,它所拥有候选的Quorum将变为active Quorum,该Quorum选举站点2为仲裁胜利站点,通过站点2恢复业务的正常存储访问。

    (2)EMC VPLEX Metro

    VPLEX有着自己专属的防脑裂规则:

    1.分离规则

    分离规则是在与远程群集的连接中断(例如,网络分区或远程群集故障)时,确定一致性组 I/O 处理语义的预定义规则。在这些情况下,在恢复通信之前,大多数工作负载需要特定虚拟卷集,才能在一个群集上继续 I/O 并在另一个群集上暂停I/O。在 VPLEX Metro 配置中,分离规则可以描述静态首选群集,方法是设置:winner:cluster-1、winner:cluster-2或 No Automatic Winner(无自动优胜者)(其中,最后一项指定无首选群集)。如果部署的系统没有 VPLEX Witness,一致性组设备 I/O 将在首选群集中继续,并在非首选群集中暂停。

    2.VPLEX Witness

    VPLEX Witness 通过管理 IP 网络连接至两个 VPLEX Metro 群集。VPLEX Witness通过将其自身的观察与群集定期报告的信息进行协调,让群集可区分群集内网络分区故障和群集故障,并在这些情况下自动继续相应站点上的 I/O。VPLEX Witness 仅影响属于 VPLEX Metro 配置中同步一致性组成员的虚拟卷,并且仅当分离规则指明群集1或群集 2 是一致性组首选群集时才会影响(也就是说,“无自动优胜者”规则未生效时,VPLEX Witness 不影响一致性组)。没有 VPLEX Witness 时,如果两个VPLEX 群集失去联系,生效中的一致性组分离规则将定义哪个群集继续操作以及哪个暂停 I/O,如上所述。仅使用分离规则来控制哪个站点是优胜者时,可能会在出现站点故障时增加不必要的复杂性,因为可能需要手动干预才能恢复仍正常运行的站点 I/O。VPLEX Witness会动态地自动处理此类事件,这也是它成为扩展 Oracle RAC 部署绝对必要项的原因。它提供了以下几项内容:

    a.在数据中心之间自动实现负载平衡

    b.主动/主动使用两个数据中心

    c.存储层的完全自动故障处理

    为了让 VPLEX Witness 能够正确区分各种故障情况,必须使用互不相同的网络接口在独立于任意群集的故障域中安装它。这将消除单个故障同时影响群集和 VPLEX Witness 的可能性。例如,如果将 VPLEX Metro 配置的两个群集部署在同一数据中心的两个不同楼层,请在不同楼层部署 VPLEX Witness。另一方面,如果将 VPLEX Metro 配置的两个群集部署在两个不同的数据中心,请在第三个数据中心部署VPLEX Witness。

    (3)HDS HAM/GAD

    HDS的HAM/GAD存储双活方案是建立在VSP TrueCopy同步复制技术之上的,整个架构也需要仲裁机制防止脑裂,能保证心跳故障后,整个集群系统能对外提供数据一致性存储服务。目前,HAM/GAD仲裁的实现方式有下面几种:

    1、优先级站点方式。这种方式最简单,在没有第三方站点的情况下使用,从两个站点中选一个优先站点,发生脑裂后优先站点仲裁成功。但如集群果发生脑裂后,优先站点也发生故障,就是导致业务中断,因此这种方案并非推荐的方案。

    2、软件仲裁方式。这种方式应用比较普遍,采用专门的仲裁软件来实现,仲裁软件放在第三站点,可以跑在物理服务器或VM上,甚至可以部署到公有云上,PureStorage的ActiveCluster就把仲裁软件以OVF文件部署在公有云上。

    3、阵列仲裁盘方式。这种方式是在第三站点采用另外一台阵列创建仲裁盘。这种方式稳定性,可靠性比较高。GAD的仲裁机制原理是采用仲裁盘的方式实现。

    (4)NETAPP Clustered Metro Cluster(MCC)

    MCC的MetroCluster的仲裁软件TieBreak支持装在第三站点的linux的主机上,通过检查对节点Ssh的session对HA pair和集群进行状态监控。TieBreak软件能够在3到5秒内检查到ssh session的故障,重试的时间间隔为3秒。所以这种方式也很灵活,第三站点可以选择两个数据中心中的一个,也可以选择公有云中的一个虚拟机,保证SSH网络可达,还可以选择其他建筑内的任意一台Linux虚拟机。

    (5)IBM DS8800系列HYPERSWAP

    DS8800 HYPERSWAP架构下的存储为ACTIVE-STANDBY模式,整体是对称式的架构,但是却没有第三仲裁站点,在双数据中心间链路全部中断时,要恢复业务需要人为关闭非存活站点的集群服务,并且修复链路,如下红皮书原文:

    Unplanned HyperSwap: Site partition

    In the scenario of Site parttion, the workload continues to run on Site_A.Because both sites are partitioned, each site thinks it is the only surviving site, as such, the nodes in each site try to start the workload on each site.

    Running the workload at the same time on both nodes results in data corruption. To maintain data integrity, PowerHA SystemMirror supports recovery mode for HyperSwap through manual workload activation. This option indicates that when the link between the sites is down (both sites are down), user intervention for manual recovery is needed, therefore

    maintaining data integrity.

    When the site is down, because Auto Recovery Action is not supported, the resource groups(RGs) will remain in the ERROR state. User intervention is needed to correct the problem.

    The user has to shut down the cluster services on Site_B and fix the connectivity issues. When done, the user can start the cluster services on Site_B.

    ▼▼▼

    ■赵海 大连农商银行 架构师

    其实这个问题,我觉得还是要看整体的架构是什么样的?

    假设定位到存储双活,那么是不是就割裂了数据库层的仲裁问题。实际上存储最终是为上层数据库及应用服务,如果这个夸中心的架构涉及到数据库、存储两层的组合,比如说存储双活之上是oracle rac,那么就比较复杂了。

    首先对于存储本身的仲裁,应该有自己的算法,例如:

    1)仲裁中心

    2)最坏情况下,默认的算法。

    对于夸中心的rac集群,同样有自己的规则:

    1)仲裁盘

    2)通过网络和磁盘心跳保证获得票数最多的子集活着。

    3)实例小的节点存活。

    但是当二者结合的时候,就有更复杂的场景可能会出现,尤其是出现两层架构仲裁的结果不一致。

    为了避免这个结果出现,那么我们需要攻克以下问题:

    1. 如何保障仲裁触发的时间序列一致。

    2. 极端情况下的仲裁算法一致性。

    例如,你可以通过oracle的仲裁参数misscount结合vplex的仲裁timeout参数来保障时间序列的一致性。

    例如,你也可以调整各自默认算法的最终结果落到一边。

    例如,你也可以通过二次开发来实现二者的联动。

    最后,所有的前提条件和策略都需要得到模拟实践的检验。

    展开全文
  • 在HA架构中有一个非常重要的问题,就是需要保证同一时刻只有一个处于Active状态的NameNode,否则就会出现两个NameNode同时修改命名空间的问题,也就是脑裂(split-brain)。...共享存储隔离:同一时间只允许一个NameNo...

      在HA架构中有一个非常重要的问题,就是需要保证同一时刻只有一个处于Active状态的NameNode,否则就会出现两个NameNode同时修改命名空间的问题,也就是脑裂(split-brain)。脑裂的HDFS集群很有可能造成数据块的丢失,以及向DataNode下发错误指令等异常情况。

     为了预防脑裂的情况,HDFS提供了三个级别的隔离机制。

    • 共享存储隔离:同一时间只允许一个NameNode向JournalNodes写入EditLog数据。
    • 客户端隔离:同一时间只允许一个NameNode响应客户端请求。
    • DataNode隔离:同一时间只允许一个NameNode向DataNode下发名字节点指令,例如删除、复制数据块指令等。
    展开全文
  • keepalived脑裂

    2020-08-07 11:42:31
    keepalived脑裂 keepalived脑裂 ...或者2边“服务”都起来了,但同时读写“共享存储”,导致数据损坏(常见如数据库轮询着的联机日志出错)。   对付HA系统“裂脑”的对策,目前达成共识的的大概有以下

    keepalived脑裂

    keepalived脑裂
    在高可用(HA)系统中,当联系2个节点的“心跳线”断开时,本来为一整体、动作协调的HA系统,就分裂成为2个独立的个体。由于相互失去了联系,都以为是对方出了故障。两个节点上的HA软件像“裂脑人”一样,争抢“共享资源”、争起“应用服务”,就会发生严重后果——或者共享资源被瓜分、2边“服务”都起不来了;或者2边“服务”都起来了,但同时读写“共享存储”,导致数据损坏(常见如数据库轮询着的联机日志出错)。
      
    对付HA系统“裂脑”的对策,目前达成共识的的大概有以下几条:

    添加冗余的心跳线,例如:双线条线(心跳线也HA),尽量减少“裂脑”发生几率;
    启用磁盘锁。正在服务一方锁住共享磁盘,“裂脑”发生时,让对方完全“抢不走”共享磁盘资源。但使用锁磁盘也会有一个不小的问题,如果占用共享盘的一方不主动“解锁”,另一方就永远得不到共享磁盘。现实中假如服务节点突然死机或崩溃,就不可能执行解锁命令。后备节点也就接管不了共享资源和应用服务。于是有人在HA中设计了“智能”锁。即:正在服务的一方只在发现心跳线全部断开(察觉不到对端)时才启用磁盘锁。平时就不上锁了。
    设置仲裁机制。例如设置参考IP(如网关IP),当心跳线完全断开时,2个节点都各自ping一下参考IP,不通则表明断点就出在本端。不仅“心跳”、还兼对外“服务”的本端网络链路断了,即使启动(或继续)应用服务也没有用了,那就主动放弃竞争,让能够ping通参考IP的一端去起服务。更保险一些,ping不通参考IP的一方干脆就自我重启,以彻底释放有可能还占用着的那些共享资源

    1. 脑裂产生的原因
    一般来说,脑裂的发生,有以下几种原因:

    高可用服务器对之间心跳线链路发生故障,导致无法正常通信
    因心跳线坏了(包括断了,老化)
    因网卡及相关驱动坏了,ip配置及冲突问题(网卡直连)
    因心跳线间连接的设备故障(网卡及交换机)
    因仲裁的机器出问题(采用仲裁的方案)
    高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输
    高可用服务器上心跳网卡地址等信息配置不正确,导致发送心跳失败
    其他服务配置不当等原因,如心跳方式不同,心跳广插冲突、软件Bug等
    注意:

    Keepalived配置里同一 VRRP实例如果 virtual_router_id两端参数配置不一致也会导致裂脑问题发生。

    2. 脑裂的解决方案
    在实际生产环境中,我们可以从以下几个方面来防止裂脑问题的发生:

    同时使用串行电缆和以太网电缆连接,同时用两条心跳线路,这样一条线路坏了,另一个还是好的,依然能传送心跳消息
    当检测到裂脑时强行关闭一个心跳节点(这个功能需特殊设备支持,如Stonith、feyce)。相当于备节点接收不到心跳消患,通过单独的线路发送关机命令关闭主节点的电源
    做好对裂脑的监控报警(如邮件及手机短信等或值班).在问题发生时人为第一时间介入仲裁,降低损失。例如,百度的监控报警短信就有上行和下行的区别。报警消息发送到管理员手机上,管理员可以通过手机回复对应数字或简单的字符串操作返回给服务器.让服务器根据指令自动处理相应故障,这样解决故障的时间更短.
      
    当然,在实施高可用方案时,要根据业务实际需求确定是否能容忍这样的损失。对于一般的网站常规业务.这个损失是可容忍的

    3. 使用zabbix对脑裂进行监控
    对脑裂的监控应在备用服务器上进行,通过添加zabbix自定义监控进行。
    只要备节点出现VIP就报警,这个报警可以有两种情况,一是主机宕机了备机接管了;二是主机没宕,裂脑了,不管哪种情况,都进行报警,然后由人工查看判断及解决。
    如果备节点出现对应的VIP,并且主节点及对应的服务还活着,就说明发生脑裂了。

    备机上出现VIP有两种情况:

    发生了脑裂
    正常的主备切换
    监控只是监控发生脑裂的可能性,不能保证一定是发生了脑裂,因为正常的主备切换VIP也是会到备上的。

    环境说明

    系统信息 主机名 IP
    centos7 master 192.168.32.125
    centos7 slave(zabbix-agentd) 192.168.32.130
    centos7 zabbix(zabbix-server) 192.168.32.136

    master和slave分别配置了keepalived的主和从keepalived高可用
    slave端部署zabbix客户端
    zabbix的server端已经配置好,zabbix监控服务部署

    3.1 在slave上配置zabbix客户端

    #安装依赖包
    [root@slave ~]# yum -y install gcc gcc-c++ pcre-devel
     
    #下载软件包,解压安装
    [root@slave ~]# wget https://cdn.zabbix.com/zabbix/sources/stable/5.0/zabbix-5.0.1.tar.gz
    [root@slave ~]# ls
    anaconda-ks.cfg  zabbix-5.0.1.tar.gz
    [root@slave ~]# tar xf zabbix-5.0.1.tar.gz 
    [root@slave ~]# cd zabbix-5.0.1
    [root@slave zabbix-5.0.1]# ./configure --enable-agent
    ......
     
    [root@slave zabbix-5.0.1]# make install
    ......
     
     
    #修改配置文件
    [root@slave zabbix-5.0.1]# vim /usr/local/etc/zabbix_agentd.conf
     
    Server=192.168.32.136		#服务端IP
     
    ServerActive=192.168.32.136		#服务端IP
     
    Hostname=001
     
    #创建zabbix用户
    [root@slave zabbix-5.0.1]# useradd -r -M -s /sbin/nologin zabbix
     
     
    [root@slave zabbix-5.0.1]# zabbix_agentd 
    [root@slave zabbix-5.0.1]# ss -tanl
    State      Recv-Q Send-Q                 Local Address:Port                                Peer Address:Port              
    LISTEN     0      100                        127.0.0.1:25                                             *:*                  
    LISTEN     0      128                                *:10050                                          *:*                  
    LISTEN     0      128                                *:22                                             *:*                  
    LISTEN     0      100                            [::1]:25                                          [::]:*                  
    LISTEN     0      128                             [::]:22   
    

    3.2 将被监控主机加入监控
    3.2.1 创建主机组
    在这里插入图片描述
    创建一个名字叫keepalived的主机组
    在这里插入图片描述
    在这里插入图片描述
    3.2.2 将主机加入主机组
    在这里插入图片描述
    在这里插入图片描述
    3.3 配置自定义监控
    3.3.1 编写脚本

    [root@slave ~]# mkdir -p /scripts/
    [root@slave ~]# cd /scripts/
    [root@slave scripts]# vim check_keepalived.sh
    #!/bin/bash
    if [ `ip a show ens33 |grep 192.168.32.250|wc -l` -ne 0 ]
     
    then
        echo 1
    else
        echo 0
    fi
    

    3.3.2 修改配置文件,添加自定义key

    [root@slave scripts]# vim /usr/local/etc/zabbix_agentd.conf
    # UnsafeUserParameters=0
    UnsafeUserParameters=1           //0改为1
    ### Option: UserParameter
    #       User-defined parameter to monitor. There can be several user-defined parameters.
    #       Format: UserParameter=<key>,<shell command>
    #       See 'zabbix_agentd' directory for examples.
    #
    # Mandatory: no
    # Default:
    # UserParameter=
    #添加以下路径
    UserParameter=check_keepalived[*],/bin/bash /scripts/check_keepalived.sh
     
    #配完重启zabbix_agentd
    

    3.3.3 配置监控项
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    3.3.4 添加触发器
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    #virtual_router_id两端参数配置不一致也会导致裂脑问题发生。所以改变salve上的virtual_router_id
    #由原来的33改为22
    ......
        virtual_router_id 22
    ......
     
    #slave上也有了vip
    [root@slave scripts]# ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host 
           valid_lft forever preferred_lft forever
    2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
        link/ether 00:0c:29:d7:d9:41 brd ff:ff:ff:ff:ff:ff
        inet 192.168.32.130/24 brd 192.168.32.255 scope global noprefixroute ens33
           valid_lft forever preferred_lft forever
        inet 192.168.32.250/32 scope global ens33
           valid_lft forever preferred_lft forever
        inet6 fe80::20c:29ff:fed7:d941/64 scope link 
           valid_lft forever preferred_lft forever
    

    在这里插入图片描述
    3.3.5 配置媒介和动作

    在这里插入图片描述
    在这里插入图片描述

    在这里插入图片描述
    在这里插入图片描述

    在这里插入图片描述
    3.3.6 触发验证
    在这里插入图片描述
    在这里插入图片描述

    [root@slave scripts]# vim /etc/keepalived/keepalived.conf
    #将virtual_router_id改回去
    ......
        virtual_router_id 33
    ......
    [root@slave scripts]# vim /etc/keepalived/keepalived.conf
    [root@slave scripts]# systemctl restart keepalived
    [root@slave scripts]# ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host 
           valid_lft forever preferred_lft forever
    2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
        link/ether 00:0c:29:d7:d9:41 brd ff:ff:ff:ff:ff:ff
        inet 192.168.32.130/24 brd 192.168.32.255 scope global noprefixroute ens33
           valid_lft forever preferred_lft forever
        inet6 fe80::20c:29ff:fed7:d941/64 scope link 
           valid_lft forever preferred_lft forever
    #vip消失了
    
    展开全文
  • RAC脑裂

    2013-11-08 16:06:18
    在集群中,节点间通过某种机制(心跳)了解彼此的健康状态,以确保各... 在集群环境中,存储设备都是共享的, 这就意味着数据灾难, 这种情况就是"脑裂" 解决这个问题的通常办法是使用投票算法(Quorum Algorithm)
    
    

                     在集群中,节点间通过某种机制(心跳)了解彼此的健康状态,以确保各节点协调工作。 假设只有"心跳"出现问题, 各个节点还在正常运行, 这时,每个节点都认为其他的节点宕机了, 自己是整个集群环境中的"唯一建在者",自己应该获得整个集群的"控制权"。 在集群环境中,存储设备都是共享的, 这就意味着数据灾难, 这种情况就是"脑裂"

    解决这个问题的通常办法是使用投票算法(Quorum Algorithm). 它的算法机理如下:

                  集群中各个节点需要心跳机制来通报彼此的"健康状态",假设每收到一个节点的"通报"代表一票。对于三个节点的集群,正常运行时,每个节点都会有3票。 当结点A心跳出现故障但节点A还在运行,这时整个集群就会分裂成2个小的partition。 节点A是一个,剩下的2个是一个。 这是必须剔除一个partition才能保障集群的健康运行。 

              对于有3个节点的集群, A 心跳出现问题后, B 和 C 是一个partion,有2票, A只有1票。 按照投票算法, B 和C 组成的集群获得控制权, A 被剔除。 

             如果只有2个节点,投票算法就失效了。 因为每个节点上都只有1票。 这时就需要引入第三个设备:Quorum Device. Quorum Device 通常采用饿是共享磁盘,这个磁盘也叫作Quorum disk。 这个Quorum Disk 也代表一票。 当2个结点的心跳出现问题时, 2个节点同时去争取Quorum Disk 这一票, 最早到达的请求被最先满足。 故最先获得Quorum Disk的节点就获得2票。另一个节点就会被剔除。

    展开全文
  • 脑裂简介 ...或者2边“服务”都起来了,但同时读写“共享存储”,导致数据损坏(常见如数据库轮询着的联机日志出错)。  对付HA系统“裂脑”的对策,目前达成共识的的大概有以下几条:  1)添加冗余的心
  • 数据库集群脑裂

    2020-07-28 11:23:54
    心跳网络故障,两个实例同时把共享存储挂载上,进行操作。 规避方法: 提供稳定的网络,内网网卡、交换机冗余; 引入磁盘锁,dm.ini中提供配置参数HA_INST_CHECK_IP和HA_INST_CHECK_PORT,防止两个实例同时启动;...
  • 脑裂告警

    2020-08-07 11:24:58
    或者两边“服务”都起来了,但同时读写“共享存储”,导致数据损坏 对付脑裂的对策: 添加冗余的心跳线,例如:双线条线(心跳线也HA),尽量减少“裂脑”发生几率 启用磁盘锁。正在服务一方锁住共享磁
  • zabbix监控keepalived脑裂

    2020-08-07 11:44:10
    zabbix监控keepalived脑裂1 . 脑裂的概述2 . 脑裂产生的原因3 . 脑裂的常见解决方案4 . 对脑裂进行监控 1 . 脑裂的概述 在高可用(HA)系统中,当...或者2边“服务”都起来了,但同时读写“共享存储”,导致数据损坏
  • 技术名词:脑裂

    2020-05-29 18:18:28
    脑裂(brain-split):脑裂是指在主备切换时,由于切换不彻底或其他原因,导致客户端和Slave误以为出现... 共享存储fencing:确保只有一个Master往共享存储中写数据。 客户端fencing:确保只有一个Master可以响应...
  • keepalived-脑裂

    2020-08-07 11:02:38
    1. 脑裂介绍 在高可用(HA)系统中,当联系2个节点的“心跳线”断开时,本来为一整体、动作协调的HA系统,就分裂成为2个独立的个体。由于相互失去了联系,都以为是对方出了故障。两个节点上的HA软件像“裂脑人”一样...
  • 脑裂问题以及如何避免

    万次阅读 2018-07-26 19:54:16
    脑裂(brain-split):脑裂是指在主备切换时,由于切换不彻底或其他原因,导致客户端和Slave误以为... 共享存储fencing:确保只有一个Master往共享存储中写数据。  客户端fencing:确保只有一个Master可以响应...
  • 文章目录1. 概述2. 脑裂产生的原因3. 脑裂常见的解决方案4. 配置zabbix监控脑裂 1. 概述 什么是脑裂?...或者两边“服务”都起来了,但同时读写“共享存储”,导致数据损坏 对付脑裂的对策: 添加冗
  • 脑裂产生以及解决办法

    万次阅读 多人点赞 2018-05-24 00:01:34
    2.2 脑裂 在高可用(HA)系统中,当联系2个节点的“心跳线”断开时,本来为一整体、动作协调的HA系统,就分裂成为2个独立的个体。由于相互失去了联系,都以为是对方出了故障。两个节点上的HA软件像“裂脑人”一样,...
  • 1. keepalived脑裂 在高可用(HA)系统中,当联系2个节点的“心跳线”断开时,本来为一整体、动作协调的HA系统,就分裂成为2个独立的个体。由于相互失去了联系,都以为是对方出了故障。两个节点上的HA软件像“裂脑人...
  • keepalived监控脑裂及解决

    千次阅读 2019-03-10 21:31:47
    1 脑裂 在高可用(HA)系统中,当联系2个节点的“心跳线”断开时,本来为一整体、动作协调的HA系统,就分裂成为2个独立的个体。由于相互失去了联系,都以为是对方出了故障。两个节点上的HA软件像“裂脑人”一样,...
  • zabbix监控Keepalived脑裂

    2020-08-07 07:32:50
    或者2边“服务”都起来了,但同时读写“共享存储”,导致数据损坏(常见如数据库轮询着的联机日志出错)。   对付HA系统“裂脑”的对策,目前达成共识的的大概有以下几条: 添加冗余的心跳线,例如:双线条线(心跳
  • 脑裂及其常见处理

    2018-06-08 09:41:00
    在高可用(HA)系统中,当联系2个节点的“心跳线”断开时,本来为一整体、动作协调的HA系统,就分裂成为2个独立的个体。...或者2边“服务”都起来了,但同时读写“共享存储”,导致数据损坏(常见如数据...
  • keepalived中的脑裂

    2018-04-07 00:47:16
    在高可用(HA)系统中,当联系2个节点的“心跳线”断开时,本来为一整体、动作协调的HA系统,就分裂成为2个独立...或者2边“服务”都起来了,但同时读写“共享存储”,导致数据损坏(常见如数据库轮询着的联机日志出...
  • 高可用脑裂问题

    2017-12-22 15:20:48
    在“双机热备”高可用(HA)系统中,当联系2个节点的“心跳线”断开时,本来为一整体、动作协调的HA系统,就分裂成为2个独立的...或者2边“服务”都起来了,但同时读写“共享存储”,导致数据损坏(常见如数据库轮询着
  • 在“双机热备”高可用(HA)系统中,当联系2个节点的“心跳线”断开时,本来为一整体、动作协调的HA系统,就分裂成为2个独立的...或者2边“服务”都起来了,但同时读写“共享存储”,导致数据损坏(常见如数据库轮询着...
  • 高可用(HA)脑裂

    2018-11-13 23:15:30
    脑裂”的概念 在高可用(HA)系统中,当联系2个节点的“心跳线”断开时,本来为一整体、动作协调的HA系统,就分裂成为2个独立的个体。由于相互失去了联系,都以为是对方出了故障。两个节点上的HA软件像“裂脑人”...
  • [root@foundation78 dir1]# mfsfileinfo passwd # 查看文件具体信息,数据存储在chunk1上,因为我们设置了数据只能存储在一台服务器上 [root@foundation78 dir1]# cd ../dir2/ [root@foundation78 dir2]# cp /...
  • 一、什么是Elasticsearch集群脑裂   Elasticsearch集群由一个主节点(可以有多个备选主节点)和多个数据节点组成。其中主节点负责创建、删除索引、分配分片、追踪集群中的节点状态等工作,即调度节点,计算压力较...

空空如也

空空如也

1 2 3 4 5 ... 11
收藏数 214
精华内容 85
关键字:

存储脑裂