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

    千次阅读 2012-07-20 17:40:46
    -、高可用策略 1- 一个性能差的高可用其实上是假的高可用高可用一定有性能的下限 2- 高可用首先是要保证重要业务的高可用,需要对业务进行取舍,关注于最重要的方面 3- 根据业务的优先级进行区分,高优先级的...

    -、高可用策略

    1- 一个性能差的高可用其实上是假的高可用,高可用一定有性能的下限

    2- 高可用首先是要保证重要业务的高可用,需要对业务进行取舍,关注于最重要的方面
    3- 根据业务的优先级进行区分,高优先级的业务走不同的通道,保持高的服务质量,即QoS是高可用的重要组成部分
    4- 高可用的一个最廉价同时也是最简单的方案就是扩容
    5- 可服务节点的水平扩展和流量分流是保证高可用的常见手段
    6- 对于异常的事件,或者说峰拥,需要进行自我保护,通过排队的机制来确保业务能够能够继续。否则的话事情只会是更糟


    二、相关技术

    高可用包含了如上所示的这些方面,每一个方面都不能够独立地解决高可用的问题,而需要统筹考虑。简单地说,相关的技术有:
    1- 性能评估和测量
    2- 业务的重要度区分
    3- 不同重要的业务不同的通道,业务上进行分离
    4- 服务的水平扩展
    5- 流量的均衡分配
    6- 性能的动态监控
    7- 软件的自我保护
    8- 协商式的请求分流
    展开全文
  • 当服务很多时,都需要同时从配置中心读取文件的时候,这时我们可以考虑将配置中心做成一个微服务,并且将其集群化,从而达到高可用,架构图如下:一、准备工作继续使用上一篇文章的工程,创建一个eureka-server工程...

    转载请标明出处:
    https://www.fangzhipeng.com/springcloud/2017/06/07/sc07-config.html
    本文出自方志朋的博客

    个人博客纯净版:https://www.fangzhipeng.com/springcloud/2017/06/07/sc07-config.html

    最新Finchley版本请访问:
    https://www.fangzhipeng.com/springcloud/2018/08/07/sc-f7-config.html
    或者
    http://blog.csdn.net/forezp/article/details/81041045

    上一篇文章讲述了一个服务如何从配置中心读取文件,配置中心如何从远程git读取配置文件,当服务实例很多时,都从配置中心读取文件,这时可以考虑将配置中心做成一个微服务,将其集群化,从而达到高可用,架构图如下:

    在这里插入图片描述

    一、准备工作

    继续使用上一篇文章的工程,创建一个eureka-server工程,用作服务注册中心。

    在其pom.xml文件引入Eureka的起步依赖spring-cloud-starter-eureka-server,代码如下:

    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    	<modelVersion>4.0.0</modelVersion>
    
    	<groupId>com.forezp</groupId>
    	<artifactId>eureka-server</artifactId>
    	<version>0.0.1-SNAPSHOT</version>
    	<packaging>jar</packaging>
    
    	<name>eureka-server</name>
    	<description>Demo project for Spring Boot</description>
    
    	<parent>
    		<groupId>org.springframework.boot</groupId>
    		<artifactId>spring-boot-starter-parent</artifactId>
    		<version>1.5.2.RELEASE</version>
    		<relativePath/> <!-- lookup parent from repository -->
    	</parent>
    
    	<properties>
    		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    		<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    		<java.version>1.8</java.version>
    	</properties>
    
    	<dependencies>
    		<dependency>
    			<groupId>org.springframework.cloud</groupId>
    			<artifactId>spring-cloud-starter-eureka-server</artifactId>
    		</dependency>
    		<dependency>
    			<groupId>org.springframework.boot</groupId>
    			<artifactId>spring-boot-starter-web</artifactId>
    		</dependency>
    
    		<dependency>
    			<groupId>org.springframework.boot</groupId>
    			<artifactId>spring-boot-starter-test</artifactId>
    			<scope>test</scope>
    		</dependency>
    	</dependencies>
    
    	<dependencyManagement>
    		<dependencies>
    			<dependency>
    				<groupId>org.springframework.cloud</groupId>
    				<artifactId>spring-cloud-dependencies</artifactId>
    				<version>Dalston.RC1</version>
    				<type>pom</type>
    				<scope>import</scope>
    			</dependency>
    		</dependencies>
    	</dependencyManagement>
    
    	<build>
    		<plugins>
    			<plugin>
    				<groupId>org.springframework.boot</groupId>
    				<artifactId>spring-boot-maven-plugin</artifactId>
    			</plugin>
    		</plugins>
    	</build>
    
    	<repositories>
    		<repository>
    			<id>spring-milestones</id>
    			<name>Spring Milestones</name>
    			<url>https://repo.spring.io/milestone</url>
    			<snapshots>
    				<enabled>false</enabled>
    			</snapshots>
    		</repository>
    	</repositories>
    
    
    </project>
    
    

    在配置文件application.yml上,指定服务端口为8889,加上作为服务注册中心的基本配置,代码如下:

    server:
      port: 8889
    
    eureka:
      instance:
        hostname: localhost
      client:
        registerWithEureka: false
        fetchRegistry: false
        serviceUrl:
          defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
    

    入口类:

    @EnableEurekaServer
    @SpringBootApplication
    public class EurekaServerApplication {
    
    	public static void main(String[] args) {
    		SpringApplication.run(EurekaServerApplication.class, args);
    	}
    }
    
    

    二、改造config-server

    在其pom.xml文件加上EurekaClient的起步依赖spring-cloud-starter-eureka,代码如下:

    <dependencies>
    		<dependency>
    			<groupId>org.springframework.cloud</groupId>
    			<artifactId>spring-cloud-config-server</artifactId>
    		</dependency>
    
    		<dependency>
    			<groupId>org.springframework.boot</groupId>
    			<artifactId>spring-boot-starter-test</artifactId>
    			<scope>test</scope>
    		</dependency>
    
    		<dependency>
    			<groupId>org.springframework.cloud</groupId>
    			<artifactId>spring-cloud-starter-eureka</artifactId>
    		</dependency>
    	</dependencies>
    
    

    配置文件application.yml,指定服务注册地址为http://localhost:8889/eureka/,其他配置同上一篇文章,完整的配置如下:

    spring.application.name=config-server
    server.port=8888
    
    spring.cloud.config.server.git.uri=https://github.com/forezp/SpringcloudConfig/
    spring.cloud.config.server.git.searchPaths=respo
    spring.cloud.config.label=master
    spring.cloud.config.server.git.username= your username
    spring.cloud.config.server.git.password= your password
    eureka.client.serviceUrl.defaultZone=http://localhost:8889/eureka/
    

    最后需要在程序的启动类Application加上@EnableEureka的注解。

    三、改造config-client

    将其注册微到服务注册中心,作为Eureka客户端,需要pom文件加上起步依赖spring-cloud-starter-eureka,代码如下:

    <dependency>
    			<groupId>org.springframework.cloud</groupId>
    			<artifactId>spring-cloud-starter-config</artifactId>
    		</dependency>
    
    		<dependency>
    			<groupId>org.springframework.boot</groupId>
    			<artifactId>spring-boot-starter-web</artifactId>
    		</dependency>
    
    		<dependency>
    			<groupId>org.springframework.cloud</groupId>
    			<artifactId>spring-cloud-starter-eureka</artifactId>
    		</dependency>
    		<dependency>
    			<groupId>org.springframework.boot</groupId>
    			<artifactId>spring-boot-starter-test</artifactId>
    			<scope>test</scope>
    		</dependency>
    

    配置文件bootstrap.properties,注意是bootstrap。加上服务注册地址为http://localhost:8889/eureka/

    spring.application.name=config-client
    spring.cloud.config.label=master
    spring.cloud.config.profile=dev
    #spring.cloud.config.uri= http://localhost:8888/
    
    eureka.client.serviceUrl.defaultZone=http://localhost:8889/eureka/
    spring.cloud.config.discovery.enabled=true
    spring.cloud.config.discovery.serviceId=config-server
    server.port=8881
    
    
    
    • spring.cloud.config.discovery.enabled 是从配置中心读取文件。
    • spring.cloud.config.discovery.serviceId 配置中心的servieId,即服务名。

    这时发现,在读取配置文件不再写ip地址,而是服务名,这时如果配置服务部署多份,通过负载均衡,从而高可用。

    依次启动eureka-servr,config-server,config-client
    访问网址:http://localhost:8889/

    在这里插入图片描述

    访问http://localhost:8881/hi,浏览器显示:

    foo version 3

    本文源码下载:
    https://github.com/forezp/SpringCloudLearning/tree/master/chapter7

    四、参考资料

    spring_cloud_config

    更多阅读

    史上最简单的 SpringCloud 教程汇总

    SpringBoot教程汇总

    Java面试题系列汇总


    扫码关注公众号有惊喜

    (转载本站文章请注明作者和出处 方志朋的博客

    展开全文
  • nuget.exe spec //spec 在.csproj文件目录下执行命令
  • [Route("api/[controller]")] [ApiController] public class Sample02Controller : ControllerBase { private readonly IMemoryCache _cache; public Sample02Controller(IMemoryCache memoryCache) ...
  • Marvin.Cache.Headers
  • 高可用集群

    万次阅读 多人点赞 2016-09-23 20:49:13
    本文将详细介绍:高可用集群、高可用集群衡量标准、高可用集群实现原理、高可用集群工作模型、高可用集群构架、高可用集群软件、共享存储

    高可用集群

     

    这篇先来认识高可用集群的一些基本概念。

    1、什么是高可用集群

           高可用集群(High Availability Cluster,简称HA Cluster),是指以减少服务中断时间为目的的服务器集群技术。它通过保护用户的业务程序对外不间断提供的服务,把因软件、硬件、人为造成的故障对业务的影响降低到最小程度。

           简单说就是:保证服务不间断地运行,比如,在淘宝网什么时候都可以上去买东西,微信随时可以打开发消息聊天。

    2、高可用集群的衡量标准

           要保证集群服务100%时间永远完全可用,几乎可以说是一件不可能完成的任务。比如,淘宝在这几年双十一刚开始的时候,一下子进来买东西的人很多,访问量大,都出现一些问题,如下单后却支付不了。所以说只能保证服务尽可能的可用,当然有些场景相信还是可能做到100%可用的。

           通常用平均无故障时间(MTTF)来度量系统的可靠性,用平均故障维修时间(MTTR)来度量系统的可维护性。于是可用性被定义为:HA=MTTF/(MTTF+MTTR)*100%。

          具体HA衡量标准:

    描述

    通俗叫法

    可用性级别

    年度停机时间

    基本可用性

    2个9

    99%

    87.6小时

    较高可用性

    3个9

    99.9%

    8.8小时

    具有故障自动恢复能力的可用性

    4个9

    99.99%

    53分钟

    极高可用性

    5个9

    99.999%

    5分钟

     

    3、高可用集群实现原理

          高可用集群主要实现自动侦测(Auto-Detect)故障、自动切换/故障转移(FailOver)自动恢复(FailBack)。

          简单来说就是,用高可用集群软件实现故障检查和故障转移(故障/备份主机切换)的自动化,当然像负载均衡、DNS分发也可提供高可性。

    3-1、自动侦测(Auto-Detect)/ 故障检查

         自动侦测阶段由主机上的软件通过冗余侦测线,经由复杂的监听程序,逻辑判断,来相互侦测对方运行的情况。

         常用的方法是:集群各节点间通过心跳信息判断节点是否出现故障。

    3-1-1、问题是:当有节点(一个或多个)和另外节点互相接收不到对方心跳信息时,如何决定哪一部分节点是正常运行的,而哪一部分是出现故障需要隔离的呢(避免集群脑裂)?

          这时候通过法定票数(quorum)决定,即当有节点故障时,节点间投票决定哪个节点是有问题的,票数大于半数为合法

    票数:

           每个节点可以设置票数,即决定节点在集群内是否合法(正常)的权限值,这个是可以有多有少的,例如有些节点的性能较好或有其他优势,可以设置较多的票数。

    法定票数(quorum):

           当一个节点能和另一个节点保持心跳信息,该节点就获取得了另一个节点的票数,该节点获得的所有票数就是法定票数。

    3-1-2、比较特殊的是只有两个节点的集群,或两边票数相等

           这时候可以借助另外的参考节点,如ping网关(可以是一个节点),可以和测试点ping通,但不可以和对方通,说明对方节点有问题,或本节点有问题;还有就是通过仲裁设备,如仲裁磁盘,每个节点都间隔一定时间不停往磁盘写数据,若监测到对方不再写入的时候,可能对方节点出故障。

          但最好还是使得组成集群的节点数量为单数台(2n+1),当集群分区脑裂时,节点数量小于一半(>n+1)的分区自动停止对外提供服务。

    3-1-3、Pasox算法和Zookeeper

          关于“投票”,有必要知道著名的Pasox算法和Zookeeper:

    Paxos算法:

          Paxos算法解决的是保证集群中每个节点执行相同的操作序列,可以保证分布式群集中的数据一致性。

          例如,通过投票来对写操作进行全局编号,同一时刻,只有一个写操作被批准,同时并发的写操作要去争取选票,只有获得过半数选票的写操作才会被 批准(所以永远只会有一个写操作得到批准);而其他的写操作竞争失败只好再发起一轮投票,就这样,在日复一日年复一年的投票中,所有写操作都被严格编号排序。

          编号严格递增,当一个节点接受了一个编号为100的写操作,之后又接受到编号为99的写操作(因为网络延迟等很多不可预见原因),它马上能意识到自己数据不一致了,自动停止对外服务并重启同步过程。

          任何一个节点挂掉都不会影响整个集群的数据一致性(总2n+1台,除非挂掉大于n台)。

    Zookeeper:

          Zookeeper是 Hadoop 大数据生态的一个独立组件,是 Google 的 Chubby一个开源的实现,可以说是Paxos算法(类似)的实现。

          Zookeeper主要提供分布式协调服务,分布式应用程序可以基于它实现服务注册(高可用),同步服务,配置维护和命名服务等。

          Zookeeper真正提供的是类似我们普通电脑上的文件系统目录的功能,不过可以原子的进行增/删/改/查操作;具体要实现什么分布式协调服务,需要自己写程序来操作Zookeeper上的“目录”。

          Zookeeper为什么可以作为分布式系统提供协调服务?

          最主要的是Zookeeper本身运行的是一个由多个Zookeeper节点组成的稳定的高可用集群。

           Zookeeper集群的高可用性和各节点“目录”数据的一致性正是基于 类似 Paxos算法实现的投票机制来保证的。

          所以 Zookeeper集群节点数量最好也是单数(2n+1),当集群脑裂分区时,分区节点数量不超过一半的(<n+1),会自动停止对外服务。
           比如:

          5台ZK节点组成ZK集群,当分成2台和3台的两个分区时,2台的分区会自动停止对外服务,3台的分区会继续提供服务。

          另外,如果用6台节点组成ZK集群,当分成3台和3台的两个分区时,这两个分区都自动停止对外服务,所以,容错率和5台节点组成的集群的是一样的,更应该用单数(2n+1)节点数量组成集群。

    3-2、自动切换/故障转移(FailOver)

          自动切换阶段某一主机如果确认对方故障,则正常主机除继续进行原来的任务,还将依据各种容错备援模式接管预先设定的备援作业程序,并进行后续的程序及服务。

          通俗地说,即当A无法为客户服务时,系统能够自动地切换,使B能够及时地顶上继续为客户提供服务,且客户感觉不到这个为他提供服务的对象已经更换。

          通过上面判断节点故障后,将高可用集群资源(如VIP、httpd等,下面详见)从该不具备法定票数的集群节点转移到故障转移域(Failover Domain,可以接收故障资源转移的节点)。

    3-2-1、高可用集群资源(HA Resource)和集群资源类型

    集群资源是集群中使用的规则、服务和设备等,如VIP、httpd服务、STONITH设备等。类型如下:

            1、Primitive:主资源,在某一时刻只能运行在某个节点上,如VIP。

            2、group:组,资源容器,使得多个资源同时停/启等,一般只包含primitive资源。

            3、clone:克隆,可以在多个节点运行的资源,例如stonith设备管理进程、集群文件系统的分布式锁(dlm)作为资源,应运行在所有节点上。

            4、master/slave:特殊的clone资源,运行在两个节点上,一主一从,如:分布式复制块设备drbd(2.6.33之后整合进内核了)。

    3-2-2、转移到哪个节点

    根据资源的倾向(资源粘性、位置约束的分数比较)进行转移;

    资源的倾向(资源定位的依据):

     A、资源粘性:资源对节点倾向程度,资源是否倾向于当前节点。score,正值倾向于当前节点(还要和位置约束结合)。

     B、资源约束(Constraint):资源和资源之间的关系

    a、排列约束 (colocation):资源间的依赖/互斥性,定义资源是否运行在同一节点上。score,正值表示要运行在同一节点上,负值则不可。

    b、位置约束(location):每个节点都有一个score值,正值则倾向于本节点,负值倾向于其他节点,所有节点score比较,倾向于最大值的节点。

    c、顺序约束(order):定义资源执行动作的次序,例如vip应先配置,httpd服务后配置。特殊的score值,-inf 负无穷,inf 正无穷。

           也就是说资源粘性定义资源对资源当前所在节点的倾向性,而位置约束定义资源对集群中所有节点的倾向性。如webip的资源粘性为100,位置约束对node1为200,当webip在node2上时,node1上线资源会转移到node1,因为当前节点node2粘性100小于对node1的位置约束200;如webip的资源粘性为200,位置约束对node1为100,当webip在node2上时,node1上线资源不会转移到node1,继续留在node2上,因为当前节点node2粘性200大于对node1的位置约束100。

    3-3、自动恢复/故障回转(FailBack)

          自动恢复阶段在正常主机代替故障主机工作后,故障主机可离线进行修复工作。在故障主机修复后,透过冗余通讯线与原正常主机连线,自动切换回修复完成的主机上。

    3-3-1、当排除故障后,是否要故障回转?

          根据资源粘性和资源约束的设置,一般备用设备单纯只用于备份,性能低于主设备,所以当主设备恢复时应转回,但故障回转需要资源转移,会影响到正在使用的客户,过程代价较高,所以是否需要回转根据实际判断。

    3-4、其他关注点

    3-4-1、如果节点不再成为集群节点成员时(不合法),如何处理运行于当前节点的资源?

          如果集群没有对其进行Fecning/Stonith隔离前,可以进行相关配置(without_quorum_policy),有如下配置选项:

    1、stop:直接停止服务;

    2、ignore:忽略,以前运行什么服务现在还运行什么(双节点集群需要配置该选项);

    3、Freeze:冻结,保持事先建立的连接,但不再接收新的请求;

    4、suicide:kill掉服务。

    3-4-2、集群脑裂(Split-Brain)和资源隔离(Fencing)

           脑裂是因为集群分裂导致的,集群中有节点因为处理器忙或者其他原因暂时停止响应时,与其他节点间的心跳出现故障,但这些节点还处于active状态,其他节点可能误认为该节点"已死",从而争夺共享资源(如共享存储)的访问权,分裂为两部分独立节点。

           脑裂后果:这时两个节点开始争抢共享资源,结果会导致系统混乱,数据损坏。

           脑裂解决:上面3-1-1、3-1-2的方法也能一定程度上解决脑裂的问题,但完全解决还需要资源隔离(Fencing)。

           资源隔离(Fencing):

                  当不能确定某个节点的状态时,通过fencing把对方干掉,确保共享资源被完全释放,前提是必须要有可靠的fence设备。

       节点级别:

                STONITH(shoot the other node in the head,爆头。硬件方式),直接控制故障节点的电源,绝对彻底。

        资源级别:

                例如:FC SAN switch(软件方式)可以实现在存储资源级别拒绝某节点的访问

    4、高可用集群工作模型

    4-1、Active/Passive:主备模型

           一个活动主节点,另一个不活动作为备用节点,当主节点故障,转移到备节点,这时备节点就成为了主节点。备节点完全冗余,造成一定浪费。如下图,mysql、DRBD主从节点间还要进行同步:

    4-2、Active/Active:双主模型

           两个节点都是活动的,两个节点运行两个不同的服务,也互为备用节点。也可以提供同一个服务,比如ipvs,前端基于DNS轮询。这种模型可以使用比较均衡的主机配置,不会造成浪费。

    4-3、N+1

          N个活动主节点N服务,一个备用节点。这需要额外的备用节点必须能够代替任何主节点,当任何主节点故障时,备节点能够负责它的角色对外提供相应的服务。如下图,最后一个备用节点可以作为前两台主节点的DRBD和第三台主节点的MYSQL提供备用功能:

    4-4、N+M

          N个活动主节点M个备用节点。像上面的N+1模型,一个备用节点可能无法提供足够的备用冗余能力,备用节点的数量M是成本和可靠性要求之间的折衷。

          也有一种说法:N-M: N个节点M个服务, N>M, 活动节点为N, 备用节点为N-M。

    4-5、N-to-1

          这和N+1一样,也是N个活动主节点,一个备用节点;不同是的备用节点成为主节点只是暂时的,当原来故障的节点修复后,必须回转才能正常工作。

    4-6、N-to-N

          N个节点N个备用节点。这是A/A双主和N + M模型的组合,N节点都有服务,如果一个坏了,剩下的每个节点都可以作为替代提供服务。如下图,当共享存储是可用的,每一个节点都可能会被用于故障切换。起搏器甚至可以运行服务的多个副本,以分散工作量。

    5、高可用集群架构层次

       

    5-1、节点主机层

           这一层主要是正在运行在物理主机上的服务,高可用集群相关的软件运行在各主机上,集群资源也是在各主机上。

    5-2、Messaging and Membership Layer

           信息传递层,传递集群信息的一种机制,通过监听UDP 694号端口,可通过单播、组播、广播的方式,实时快速传递信息,传递的内容为高可用集群的集群事务,例如:心跳信息,资源事务信息等等,只负责传递信息,不负责信息的计算和比较。

           成员关系(Membership)层,这层最重要的作用是主节点(DC)通过Cluster Consensus Menbership Service(CCM或者CCS)这种服务由Messaging层提供的信息,来产生一个完整的成员关系。这层主要实现承上启下的作用,承上,将下层产生的信息生产成员关系图传递给上层以通知各个节点的工作状态;启下,将上层对于隔离某一设备予以具体实施。

    5-3、CRM(Cluster Resource Manager)

          集群资源管理器层,它主要是用来提供那些不具有高可用的服务提供高可用性的。它需要借助Messaging Layer来实现工作,因此工作在Messaging Layer上层。

          资源管理器的主要工作是收集messaging Layer传递的节点信息,并负责信息的计算和比较,并做出相应的动作,如服务的启动、停止和资源转移、资源的定义和资源分配。

          在每一个节点上都包含一个CRM,且每个CRM都维护这一个CIB(Cluster Information Base,集群信息库),只有在主节点上的CIB是可以修改的,其他节点上的CIB都是从主节点那里复制而来的。

           CRM会推选出一个用于计算和比较的节点,叫DC(Designated coordinator)指定协调节点,计算由PE(Policy Engine)策略引擎实现,计算出结果后的动作控制由TE(Transition Engine)事务引擎实现。

           在每个节点上都有一个LRM(local resource manager)本地资源管理器,是CRM的一个子功能,接收TE传递过来的事务,在节点上采取相应动作,如运行RA脚本等。

    5-4、RA(Resource Rgent)

          资源代理层,简单的说就是能够集群资源进行管理的脚本,如启动start,停止stop、重启restart和查询状态信息status等操作的脚本。LRM本地资源管理器负责运行。

          资源代理分为:

    1、Legacy heartbeat(heatbeat v1版本的资源管理);

    2、LSB(Linux Standard Base),主要是/etc/init.d/*目录下的脚,start/stop/restart/status;

    3、OCF(Open Cluster Famework),比LSB更专业,更加通用,除了上面的四种操作,还包含monitor、validate-all等集群操作,OCF 的规范在http://www.opencf.org/cgi-bin/viewcvs.cgi/specs/ra/resource-agent-api.txt?rev=HEAD

    4、STONITH:实现节点隔离

    6、高可用集群软件

    6-1、Messaging Layer 集群信息层软件

    1、heartbeat (v1, v2)

    2、heartbeat v3

    可以拆分为:heartbeat, pacemaker, cluster-glue

    3、corosync

    从OpenAIS分离的项目。

    4、cman

    5、keepalived

    一般用于两个节点的集群

    6、ultramokey

    6-2、CRM集群资源管理器软件

    1、Haresource

    heartbeat v1 v2包含,使用文本配置接口haresources

    2、crm

    heartbeat v2包含,可以使用crmsh或者heartbeat-gui来进行配置

    3、pacemaker

    heartbeat v3分离出来的项目,配置接口:CLI:crm、pcs和GUI:hawk(WEB-GUI)、LCMC、pacemaker-mgmt、pcs

    4、rgmanager

    Cman包含,使用rgmanager(resource group manager)实现管理, 具有Failover Domain故障转移域这一特性,也可以使用RHCS(Redhat Cluster Suite)套件来进行管理:Conga的全生命周期接口,Conga(luci/ricci)先安装后,可用其安装高可用软件,再进行配置。

    6-3、常用组合

    heartbeat v2+haresource(或crm) (说明:一般常用于CentOS 5.X)

    heartbeat v3+pacemaker (说明:一般常用于CentOS 6.X)

    corosync+pacemaker (说明:现在最常用的组合)

    cman + rgmanager (说明:红帽集群套件中的组件,还包括gfs2,clvm)

    keepalived+lvs (说明:常用于lvs的高可用)

    7、共享存储

           高可用集群多节点都需要访问数据,如果各节点访问同一个数据文件都是在同一个存储空间内的,就是说数据共享的就一份,而这个存储空间就共享存储。

           如Web或Mysql高可用集群,他们的数据一般需要放在共享存储中,主节点能访问,从节点也能访问。当然这也不是必须的,如可以通过rsync、DRBD来同步分别存储在主、从节点上的块数据,而且相对共享存储实现成本更低,具体使用什么需要根据实际场景来选择。下面我们就简单说一下共享存储的类型:

    7-1、DAS(Direct attached storage,直接附加存储)

           存储设备直接连接到主机总线上的,距离有限,而且还要重新挂载,之间有数据传输有延时;

           这是设备块级别驱动上实现的共享,持有锁是在节点主机本地上的,无法通知其他节点,所以如果多节点活动模型的集群同时写入数据,会发生严重的数据崩溃错误问题,主备双节点模型的集群在分裂的时候了会出现问题;

           常用的存储设备:RAID 阵列、SCSI 阵列。

    7-2、NAS(network attached storage,网络附加存储)

           文件级别交互的共享,各存储设备通过文件系统向集群各节点提供共享存储服务,是用C/S框架协议来实现通信的应用层服务。

           常用的文件系统:NFS、FTP、CIFS等,如使用NFS实现的共享存储,各节点是通过NFS协议来向共享存储请求文件的。

    7-3、SAN(storage area network、存储区域网络)

            块级别的,将通信传输网络模拟成SCSI(Small Computer System Interface)总线来使用,节点主机(initiator)和SAN主机(target)都需要SCSI驱动,并借助网络隧道来传输SAN报文,所以接入到SAN主机的存储设备不一定需要是SCSI类型的。

            常用的SAN:FC光网络(交换机的光接口超贵,代价太高)、IPSAN(iscsi、存取快,块级别,廉价)。


    经过写这篇文章,对高可用集群有了一个基本的认识,下面将会动手进行应用配置……

     

    【参考资料】

    1、《大型网站技术架构:核心原理与案例分析》

    2、《从Paxos到Zookeeper :分布式一致性原理与实践》

    3、《大话存储Ⅱ—存储系统架构与底层原理极限剖析》

    4、Pacemaker:http://clusterlabs.org/wiki/Pacemaker

    5、High-availability cluster:https://en.wikipedia.org/wiki/High-availability_cluster#Node_configurations|

    6、Linux 高可用(HA)集群基本概念详解:http://www.linuxidc.com/Linux/2013-08/88522.htm

    7、高可用集群基本概念与heartbeat文本配置接口:http://www.178linux.com/10982

    8、高可用集群原理:http://boxinknown.blog.51cto.com/10435935/1673396

    9、理解 OpenStack 高可用(HA) (4): Pacemaker 和 OpenStack Resource Agent (RA):http://www.cnblogs.com/sammyliu/p/5025362.html

    展开全文
  • HA高可用

    万次阅读 2018-09-25 20:57:46
    什么事应用程序的高可用 高可用性(high availability)通常用来描述一个系统经过专门的设计,从而减少停工的时间,而保持其服务的高度可用性 高可用程序的类型 主从方式(冷备) 两个相同的应用程序,一个对外提供...

    什么事应用程序的高可用

    高可用性(high availability)通常用来描述一个系统经过专门的设计,从而减少停工的时间,而保持其服务的高度可用性


    高可用程序的类型

    主从方式(冷备)
    两个相同的应用程序,一个对外提供服务,成为主程序,另一个平时不运行为备程序,就是一个主程序的备份,一旦主程序出现问题,备份提供恢复操作
    双主互备(热备)
    两个相同的应用程序,同时对外提供服务(两个程序相互为对方备份的存在,双主热备),当启动一个出现问题时,另一个可以对外提供服务,不会造成服务器宕机

    总结:

    hadoop1.x版本:
    SecondaryNameNode他不是HA,他只是用来阶段性合并edits和fsimage以及缩短集群启动是啊金所使用,默认是1小时进行一次整合,当NN失效的时候,SNN并无法立即提供服务,SNN是无法保证数据完整性
    hadoop2.x
    提供了QJM系统来解决当前NameNode的单点故障问题
    1.QJM的基本原理是基于2N+1每次需要对数据进行操作需要完成一个过半机制会返回成功,数据不会丢失
    2.在HA框架中SNN这个冷备已经不存在了,为了保持standbyNN实时的和ActiveNN的数据保持一致,他们会开启一个进程
    实时监控JN(JournalNode)
    3,任何更改操作在ActiveNN上执行,JN进程同时记录并会修改log
    这是StandbyNN检测JN终有数据同步log发生变化,就会同步当前数据
    4,当发生故障的时候,ActiveNN挂了,StandbyNN会提升成为新的ActiveNN
    读取会签JN里面修改的日志,这样就提供了可靠性
    5.OJM技术
    5.1不需要配置额外的高共享存储,减少复杂度和成本
    5,2系统健壮性得到了增强
    5.3JN不会疑问启动一台延迟而影响整体,亦不会因为JN增多而影响性能

    Zookeeper

    Zookeeper是一个分布式开源的应用协调程序,是谷歌的一个开源项目,是HBase好Hadoop的重要组件,呀是一个为分布式应用所提供一致性服务的软件,主要提供:配置的维护,域名服务,分布式同步…

    集群角色

    在Zookeeper中,没有主从关系,二是引入了新的概念: Leader(头),Flower(随从),Observer(观察者)三种角色
    Zookeeper集群中所有的机器同一个Leader进行管理, Leader通过"选举机制"产生, Leader服务器对客户端进行服务,除了Leader外,其他机器包括Flower和Observer, Flower和Observer都能提供读取服务,区别在Observer机制不参与Leader的选举,Zookeeper中也一样有"过半机制"

    在这里插入图片描述
    在这里插入图片描述
    ps:服务器的个数必须是技术(3,5,7,9…)

    会话(session)

    Session是指客户端会话,在Zookeeper中,一个客户端连接服务器之间会建立一个TCP长连接,Zookeeper对外的服务
    器端口号2181,客户端启动是后,首先户先和服务器创建连接,从第一次连接开始的时候客户端会话的声明周期就开始
    了,通过这个连接,客户端能够心跳检测和服务器保持有效的会话,也能够向Zookeeper服务器发送请求和接收相应,同
    时还用过还该连接收来之服务器的watch事件通知,Session会使用SessionTimeOut的值来设置一个客户端会话超时
    的时间,当由于服务器压力太大,或网络故障或是客户端注定断开连接等因素所导致的客户端断开,只要在
    sessionTimeOut规定的时间内能够重新连接到集群上任意一台服务器,那么之前创建的会话仍然有效

    Zookeeper的数据结构特点

    在分布式中我们通常说”节点”是指组成集群中的每一个台机器,然而在Zookeeper中”节点”分为两类

    1. 同样指的是集群中的机器–>机器节点
    2. 是指数据模型中的数据单元 —.>Znode在这里插入图片描述
      每个 子目录项如 app1 都被称作为 znode,这个 znode 是被它所在的路径唯一标识,如 p1这个 znode 的标识为
      /app1/p1
      znode 可以有子节点目录,并且每个 znode 可以存储数据,注意 EPHEMERAL(ephemeral/ə’fɛmərəl/)类型的目录
      节点不能有子节点目录
      znode 是有版本的,每个 znode 中存储的数据可以有多个版本,也就是一个访问路径中可以存储多份数据
      znode 可以是临时节点,一旦创建这个 znode 的客户端与服务器失去联系,这个 znode 也将自动删除,
      Zookeeper 的客户端和服务器通信采用长连接方式,每个客户端和服务器通过心跳来保持连接,这个连接状态称为
      session,如果 znode 是临时节点,这个 session 失效,znode 也就删除了
      znode 的目录名可以自动编号,如 app1 已经存在,再创建的话,将会自动命名为 app2
      znode 可以被监控,包括这个目录节点中存储的数据的修改,子节点目录的变化等,一旦变化可以通知设置监控的
      客户端,这个是 Zookeeper 的核心特性,Zookeeper 的很多功能都是基于这个特性实现的,后面在典型的应用场
      景中会有实例介绍

    和传统文件系统区别

    共同点:树形文件系统,都可以存储数据
    不同点:传统的文件系统专门用于存储大量数据,zk的存储少量数据
    传统的文件系统目录和文件分明,zk即使文件也是文件目录
    每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识
    节点Znode可以包含数据和子节点(但是EPHEMERAL类型的节点不能有子节点)
    客户端应用可以在节点上设置监视器

    节点类型

    Znode有两种类型:
    短暂(ephemeral)(断开连接自己删除)
    持久(persistent)(断开连接不删除)
    Znode有四种形式的目录节点(默认是persistent )
    PERSISTENT 持久类型
    PERSISTENT_SEQUENTIAL(持久序列类型/test0000000019 )sequential
    EPHEMERAL 短暂类型
    EPHEMERAL_SEQUENTIAL 短暂序列类型
    创建znode时设置顺序标识,znode名称后会附加一个值,顺序号是一个单调递增的计数器,由父节点维护
    在分布式系统中,顺序号可以被用于为所有的事件进行全局排序,这样客户端可以通过顺序号推断事件的顺序

    Zookeeper设计目的

    1.最终一致性:client不论连接到哪个Server,展示给它都是同一个视图,这是zookeeper最重要的性能。第一个
    clinet上传了数据 其他client在访问得到的是同一个数据 2.可靠性:具有简单、健壮、良好的性能,如果消息被到
    一台服务器接受,那么它将被所有的服务器接受。 3.实时性:Zookeeper保证客户端将在一个时间间隔范围内获得
    服务器的更新信息,或者服务器失效的信息。但由于网络延时等原因,Zookeeper不能保证两个客户端能同时得到
    刚更新的数据,如果需要最新数据,应该在读数据之前调用sync()接口。 4.等待无关(wait-free):慢的或者失效
    的client不得干预快速的client的请求,使得每个client都能有效的等待。 5.原子性:更新只能成功或者失败,没有
    中间状态。
    6.顺序性:包括全局有序和偏序两种:全局有序是指如果在一台服务器上消息a在消息b前发布,则在所有Server上
    消息a都将在消息b前被发布;偏序是指如果一个消息b在消息a后被同一个发送者发布,a必将排在b前面。

    HA:Zookeeper部分

    总结:
    1.Hadoop中提供了ZKFailoverController交涉,部署在每个namenode所在的基点上,做一个进程进行监控简称ZKFC
    ZKFailoverController主要包含三个组件
    1.HealthMonitor:监控当前namenode时候出健康(活着)或不健康(死亡)状态,通过当前RPC来调用NN相应的方法来
    完成
    2.ActiveStandbyElector:管理和监控自己的zk中的状态
    3.ZKFailoverController监听HealthMonitor和ActiveStandbyElector的时间来管理NN的状态
    ZKFailoverController的主要职责:
    1.健康测试:周期性的向它监控的NN发送健康探测命令,从而来确定某个NN是否处于健康的状态,若机器宕机,心跳失
    败,那么zkfc就会标记当前出一个不健康的状态集群/节点配置 NN NN DN ZK ZKFC JN
    hadoop01 有 有 有
    hadoop02 有 有 有 有 有
    hadoop03 有 有 有
    hadoop04 有 有
    2.会话管理:如果NN是健康的,zkfc会和zk保持一个打开的会话状态,如果NN同时还是Active状态,那么zkfc还会在zk中
    创建一个类型为短暂类型的znode,当这个NN挂掉,这个znode就会被删除,然后备用的NN将得到这个锁,升级为主
    NN,同时被标记为Acitve
    3.当宕机的NN重新启动的时候,他会再次注册zk,发现已经有znode锁了,它会自动变为standby状态
    循环往复,就可以保证高可用的可靠性
    4.zk中的leader是用过选举机制得到的

    展开全文
  • 能够帮助学员迅速掌握:MySQL 高可用的多种方式,包括DRBD + heartbeat 实现高可用;Galera 高可用集群 PXC;MMM 集群和 MHA 高可用 ;LVS + Keepalived 实现高可用 等等
  • 高并发与高可用知识总结

    万次阅读 2019-09-02 15:48:33
    究竟啥才是互联网架构“并发” 一、什么是并发 并发(High Concurrency)是互联网分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计保证系统能够同时并行处理很多请求。 并发相关常用的一些...
  • Zuul的高可用

    千次阅读 2018-06-27 19:29:20
    Zuul的高可用非常关键,因为外部请求到后端服务的流量都会经过Zuul。故而在生产环境下一般都需要部署高可用的Zuul以避免单点故障。一 Zuul客户端也注册到Eureka Server上这种情况下,Zuul的高可用非常简单,只须将...
  • Keepalived + Nginx 高可用

    千次阅读 2021-08-18 11:45:58
    keepalived+Nginx 高可用配置keepalived+Nginx 高可用配置keepalived+Nginx 高可用配置keepalived+Nginx 高可用配置keepalived+Nginx 高可用配置keepalived+Nginx 高可用配置keepalived+Nginx 高可用配置keepalived+...
  • postgresql高可用对比

    2018-11-04 16:24:32
    本人进行了postgresql数据库两种高可用pgpool和keepalived进行了性能对比,里面包括了自己写的性能测试脚本和测试结果的对比数据。
  • K8S 高可用 多MASTER 部署方案 kubernetes高可用安装部署 直接上淘宝帮你安装 https://item.taobao.com/item.htm?spm=a1z10.1-c.w4004-1135847669.2.633eb74auRSyux&amp;id=575052245964   ...
  • 高可用mysq l第3版pdf

    2017-12-18 08:36:03
    高可用mysql主要讲解真实环境下如何使用MySQL的复制、集群和监控特性,揭示MySQL可靠性和高可用性的方方面面。《高可用MySQL(第3版)》定位于解决MySQL数据库的常见应用瓶颈,在保持MySQL持续可用性的前提下,挖潜...
  • 从 LNMP 架构 WordPress,到 Docker 容器化部署,最后 Kubernetes 实现高可用博客平台。
  • 常用高可用技术

    千次阅读 2017-08-16 21:09:13
    常用高可用技术
  • 什么是高可用

    千次阅读 多人点赞 2018-06-08 15:23:12
    一、什么是高可用   高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。 假设系统一直能够提供服务,我们说系统的可用性是100%。 ...
  • MySQL高可用方案

    千次阅读 2018-07-19 10:36:59
    高可用架构对于互联网服务基本是标配,无论是应用服务还是数据库服务都需要做到高可用。虽然互联网服务号称7*24小时不间断服务,但多多少少有一些时候服务不可用,比如某些时候网页打不开,百度不能搜索或者无法发...
  • activemq高可用集群(zookeeper+leveldb)安装、配置、高可用测试
  • MHA高可用群集

    千次阅读 2019-11-07 17:23:31
    MYSQL高可用集群架构-MHA架构 简介: MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,351,208
精华内容 540,483
关键字:

高可用