如何能构建高可用性高扩展性地系统
如何构建高可用性高扩展性的系统
1高可用性
1.1避免故障
1.1.1明确使用场景
保持系统简单
1.1.2设计可容错系统
Fail Fast原则
主流程任何一步出现问题，就应该快速结束接口和对象设计要严谨
能否被重复调用
多线程并发环境下是否有异常
对象类型是否需要检查
1.1.3设计具备自我保护能力的系统对第三方资源持怀疑态度，提供降级措施1.1.4限制使用资源
内存
防止集合容量过大造成OOM
及时释放不再使用的对象
文件
网络
连接资源
线程池
1.1.5其他角度
分析可能的风险
1.2及时发现故障
1.2.1监控报警系统
1.2.2日志系统和分析系统1.3及时故障处理
1.3.1降级
1.3.2限流
1.4访问量上涨的应对策略
1.4.1垂直伸缩
增加配置
1.4.2水平伸缩
增加机器
1.4.3拆分
按业务拆库
按规则拆表
1.4.4读写分离
实时性要求不高、读多写少的系统如何快速地从写库复制到读库
1.4.5其他
容量规划
2高可扩展性
2.1垂直伸缩
2.1.1高访问量
增加CPU
锁
线程数
单线程程序
增加内存
cache
JVM堆
2.1.2大数据量
分表
单表数据量减少
跨表查询、分页查询复杂度提升2.1.3计算能力
线程数提升
2.2水平伸缩
2.2.1高访问量
SNA（Shared Nothing Architecture）有状态的部分，放入缓存或数据库中有状态的情况
存在内存的状态
广播同步
例如session同步
单台机器容量有限
分布式缓存
一致性hash
文件
直连存储DAS((Direct-Attached Storage) 网络存储
NAS(Network Attached Storage)
SAN(Storage Area Network)
分布式文件系统
GFS
HDFS
数据库问题
cache
页面静态化
页面片段缓存
数据缓存
分库
按业务拆库
跨库访问需要多次查询；跨库写需要分布式事务异步数据库访问
传统方式：阻塞IO
异步方式：非阻塞、异步IO
中间层DAL（Data Access Layer）
透明化分库分表规则
隔离业务服务器和数据库服务器
2.2.2大数据量
性能压力
读写分离
对称复制
非对称复制
多master
多个master数据不同多个master数据相同数据一致性问题
复制
两阶段提交
三阶段提交
Google paxos
自增id
程序统一生成
2.2.3计算能力MapReduce
MPI
如何构建高可用性HIS系统方案
构建高可用性HIS 近几年来，我国的HIS系统建设已从单纯的经济管理逐步向以病人为中心的临床应用发展，如联机检验数据采集、PACS系统以及电子病历等等，使医院对HIS系统的依赖程度越来越高，这就要求HIS系统需要达到7X24小时永不间断地高效可靠运行，计算机集群系统能够较好地满足这一要求。 1集群系统及其基本架构 1.1 集群的概念 集群就是把多个独立的计算机连接在一起，面对客户机作为一个虚拟整体，使整个系统能够提供更大的可用性、更好的可伸缩性和更强的容灾能力。 1.2 集群系统的基本构成 一个集群系统通常由多个服务器(或称为节点)、共享存储子系统和使节点可以进行信息传递的内部节点连接构成。图1为两节点集群的基本架构。 每个集群节点具有两类资源：非共享资源和共享资源。非共享资源包括安装网络操作系统的本地硬盘、系统页面文件（虚拟内存）。本地安装的应用程序，以及特定节点访问的各种文件。共享资源包括存储在共享设备中的文件，每个集群节点使用共享存储系统访问集群的quorum资源和应用程序数据库等。 1.3 集群系统中的几个重要组件 ①后台共享存储设备：所有的节点都必须与至少一个集群系统的共享存储设备相连。共享存储设备将存储集群本身的系统数据及应用程序所产生的数据。 ②集群内部网络通讯：这个网络提供信息传递的服务，被称为心跳网络，它用来传递各个节点的状态。内部连接可采用高带宽的通讯机制（例如千兆以太网），以确保集群中的节点可以快速交换信息和同步数据。 ③公共网络：为客户端提供访问服务的网络，这个网络为其它的应用服务提供必要的网络通讯基础。 ④虚拟的前台界面：所有的节点被合为一组，有一个虚拟的服务器名称，为了管理集群系统，也需要为集群提供一个名称。应用程序在集群环境下运行的时候，也需要创建自己的虚拟服务器名称，便于客户端的访问。 1.4 集群中节点的运行模式 在集群中节点可以有几种运行模式，取决于实际应用环境。 ①Active/passive模式。在两个节点集群环境中，其中一个集群节点处理所有集群应用请求而另外一个节点则只简单地等待那个起作用的节点失效。这种Active/passive集群方式从性能价格比方面来讲并不合算，因为其中一个服务器在大多数时间处于空闲状态。但在失效时应用可以完全使用另一个服务器的处理能力，所以这种配置比较适用于一些关键业务环境。 ②Active/active模式。在集群中每一个节点都作为一个虚拟的服务器，当一个应用运行在节点A时，节点B不需要处于空闲状态以等待节点A的失效，节点B可以在为节点A的资源提供失效恢复能力的同时运行它自己的集群相关应用。由于这种模式各个系统都是独立运行，因此在资源的应用上其效率要更高一些。但一个Active/active方式的节点必须具备相应的能够处理两个节点上的负载的能力（在发生失效恢复事件时），否则接管了失效节点的服务也会很快因不堪重负而垮掉。 ③3-active/passive模式。Microsoft Windows 2000 Datacenter Server支持这种配置方式，由三个服务器共同作为一个虚拟服务器运行，第四个服务器作为备份服务器，当虚拟服务器中任何一个服务器出现故障，备份服务器接管其原有的应用和资源。这种集群环境提供更强大的处理能力，适用于更高的企业用户需求，能够满足更多的客户访问。
高可用性集群系统的实现
高可用性集群系统的实现 《Linux企业应用案例精解》第8章主要介绍一下虚拟化技术应用。本节为大家介绍高可用性集群系统的实现。 8.3.5 高可用性集群系统的实现（1） VMware Infrastructure 的体系结构和典型配置 资源动态分配和高可用性的实现为构建高可用性集群系统提供了有力的保障，采用VMwae构建铁路企业高可用性集群，不需要为系统中的每台服务器分别添置备用服务器，就可以有效地降低系统成本，在基于VMware的我企业高可用性集群中，备用服务器安装了VMware ESX Server，与数据库服务器、Web服务器、OA服务器和文件服务器等构成高可用性集群，同时采用数据库备份服务器实现差额计划备份。 使用VMware提供的虚拟基础架构解决方案，服务器不再需要随着业务增加而添加，整个IT基础架构能得到有效控制并可充分发挥效能。只有当整体资源出现不足的时候，才需要增加服务器。而且对系统资源的
添加也非常简单，不再需要做繁琐的硬件维护以及业务迁移，只需要简单地将新服务器安装VMWARE? INFRASTRUCTURE 3软件，并添加到已有的VMWARE? INFRASTRUCTURE 3架构中即可，新增资源将自动分配到各个最需要的业务环境中。 在HA和DRS功能的共同支撑下，虚拟机的稳定、不间断运行得到了保证，而且，在没有搭建Cluster环境的情况下，迁移、升级依旧能不中断服务。哪怕是硬件升级、添加，正常停机维护等情况，也能够保证所有的业务正常运行，客户端访问服务器不产生业务中断现象。新的服务器虚拟化架构中另一个重点是VMware HA 的部署，它是整个服务器系统安全、可靠运行的一道防线。传统的热备机方式最大的问题就是容易造成资源的大量闲置；在正常运行状态下，所有备机服务器都处于闲置状态，不仅造成计算资源的空耗，而且还浪费大量的电力和散热资源，投资回报率非常低。 如何应对Linux系统软件包的依赖性问题 不管是初步跨入Linux殿堂的新手还是，具有多年经验的专家，在安装或编译软件包的过程中或多或少的都会遇到包的依赖问题从而导致安装过程无法继续，比如管理员在安装php软件包需要libgd.so文件，而这个文件属于gb软件包。但是在安装gb软件包时，可能这个软件包跟其他软件包又具有依赖关系，又需要安装其他软件包才行。这时有的管理员便失去耐心。在遇到这种Linux软件包依赖关系问题，该如何解决呢?在谈这个具体的措施之前，先跟大家聊聊Linux系统里的软件爱你依赖性问题。 我们把处理rpm依赖性故障的策略可以分成两类解决依赖性故障的自动方法和手工方法。但当安装不属于发行一部分的软件包时自动方法是不可用的。在描述如何手工解决依赖性故障后，将简要描述如何使用自动方法之一（YUM），但首先需要了解它们是什么及rpm如何强制实施它们。 一、什么是依赖性 程序依赖于程序代码的共享库，以便它们可以发出系统调用将输出发送到设备或打开文件等（共享库存在于许多方面，而不只局限于系统调用）。没有共享库，每次程序员开发一个新的程序，每个程序员都需要从头开始重写这些基本的系统操作。当编译程序时，程序员将他的代码链接到这些库。如果链接是静态的，编译后的共享库对象代码就添加到程序执行文件中；如果是动态的，编译后的共享库对象代码只在运行时需要它时由程序员加载。动态可执行文件依赖于正确的共享库或共享对象来进行操作。RPM依赖性尝试在安装时强制实施动态可执行文件的共享对象需求，以便在以后--当程序运行时--不会有与动态链接过程有关的任何问题。
系统总体设计原则汇总
1.1系统总体设计原则 为确保系统的建设成功与可持续发展，在系统的建设与技术方案设计时我们遵循如下的原则：1、统一设计原则统筹规划和统一设计系统结构。尤其是应用系统建设结构、数据模型结构、数据存储结构以及系统扩展规划等内容，均需从全局出发、从长远的角度考虑。2、先进性原则系统构成必须采用成熟、具有国内先进水平，并符合国际发展趋势的技术、软件产品和设备。在设计过程中充分依照国际上的规范、标准，借鉴国内外目前成熟的主流网络和综合信息系统的体系结构，以保证系统具有较长的生命力和扩展能力。保证先进性的同时还要保证技术的稳定、安全性。3、高可靠/高安全性原则系统设计和数据架构设计中充分考虑系统的安全和可靠。4、标准化原则系统各项技术遵循国际标准、国家标准、行业和相关规范。5、成熟性原则系统要采用国际主流、成熟的体系架构来构建，实现跨平台的应用。6、适用性原则保护已有资源，急用先行，在满足应用需求的前提下，尽量降低建设成本。7、可扩展性原则信息系统设计要考虑到业务未来发展的需要，尽可能设计得简明，降低各功能模块耦合度，并充分考虑兼容性。系统能够支持对多种格式数据的存储。 1.2业务应用支撑平台设计原则 业务应用支撑平台的设计遵循了以下原则：1、遵循相关规范或标准遵循J2EE、XML、JDBC、EJB、SNMP、HTTP、TCP/IP、SSL等业界主流标准2、采用先进和成熟的技术系统采用三层体系结构，使用XML规范作为信息交互的标准，充分吸收国际厂商的先进经验，并且采用先进、成熟的软硬件支撑平台及相关标准作为系统的基础。3、可灵活的与其他系统集成系统采用基于工业标准的技术，方便与其他系统的集成。4、快速开发/快速修改的原则系统提供了灵活的二次开发手段，在面向组件的应用框架上，能够在不影响系统情况下快速开发新业务、增加新功能，同时提供方便地对业务进行修改和动态加载的支持，保障应用系统应能够方便支持集中的版本控制与升级管理。5、具有良好的可扩展性系统能够支持硬件、系统软件、应用软件多个层面的可扩展性，能够实现快速开发/重组、业务参数配置、业务功能二次开发等多个方面使得系统可以支持未来不断变化的特征。6、平台无关性系统能够适应多种主流主机平台、数据库平台、中间件平台，具有较强的跨系统平台的能力。7、安全性和可靠性系统能保证数据安全一致，高度可靠，应提供多种检查和处理手段，保证系统的准确性。针对主机、数据库、网络、应用等各层次制定相应的安全策略和可靠性策略保障系统的安全性和可靠性。8、用户操作方便的原则系统提供统一的界面风格，可为每个用户群，包括客户，提供一个一致的、个性化定制的和易于使用的操作界面。 9、应支持多CPU的SMP对称多处理结构 1.3共享交换区数据库设计原则 1.统一设计原则为保证数据的有效性、合理性、一致性和可用性，在全国统一设立交换资源库基本项目和统一编码的基础上，进行扩展并制定统一的交换资源库结构标准。 2.有效提取原则既要考虑宏观决策需要，又要兼顾现实性，并进行业务信息的有效提取，过滤掉生产区中的过程性、地方性数据，将关键性、结果性数据提交集中到交换区数据库中。 3.保证交换原则统一设计数据交换接口、协议、流程和规范，保证数据通道的顺畅。 4.采用集中与分布式相结合的系统结构根据XX电子政务网络发达，地区经济差异性等特点，交换区采用集中与分布式相结合的数据库系统结构，并逐步向大型集中式数据库系统过渡。这些与外部系统交换的数据也需要从生产区数据得到，也就是说需要XXXX数据和各XXXX 数据的采集不只是局限于XXXX和XXXX原定的指标。 1.4档案管理系统设计原则
高可用性集群解决方案设计HA
1.业务连续 1.1.共享存储集群 业务系统运营时，服务器、网络、应用等故障将导致业务系统无常对外提供业务，造成业务中断，将会给企业带来无法估量的损失。针对业务系统面临的运营风险，Rose提供了基于共享存储的高可用解决方案，当服务器、网络、应用发生故障时，Rose可以自动快速将业务系统切换到集群备机运行，保证整个业务系统的对外正常服务，为业务系统提供7x24连续运营的强大保障。 1.1.1.适用场景 基于共享磁盘阵列的高可用集群，以保障业务系统连续运营 硬件结构：2台主机、1台磁盘阵列
主机 备机心跳 磁盘阵列 局域网 1.1. 2.案例分析 某证券公司案例 客户需求分析 某证券公司在全国100多个城市和地区共设有40多个分公司、100多个营业部。经营围涵盖：证券经纪，证券投资咨询，与证券交易、证券投资活动有关的财务顾问，证券承销与保荐，证券自营，证券资产管理，融资融券，证券投资基金代销，金融产品代销，为期货公司提供中间介绍业务，证券投资基金托管，股票期权做市。 该证券公司的系统承担着企业的部沟通、关键信息的传达等重要角色，随着企业的业务发展，系统的压力越来越重。由于服务器为单机运行，如果发生意外宕机，将会给企业的日常工作带来不便，甚至
给企业带来重大损失。因此，急需对服务器实现高可用保护，保障服务器的7×24小时连续运营。 解决方案 经过实际的需求调研，结合客户实际应用环境，推荐采用共享存储的热备集群方案。部署热备集群前的单机环境：业务系统，后台数据库为MySQL，操作系统为RedHat6，数据存储于磁盘阵列。 在单机单柜的基础上，增加1台备用主机，即可构建基于共享存储的热备集群。增加1台物理服务器作为服务器的备机，并在备机部署系统，通过Rose共享存储热备集群产品，实现对应用的高可用保护。如主机上运行的系统出现异常故障导致宕机，比如应用服务异常、硬件设备故障，Rose将实时监测该故障，并自动将系统切换至备用主机，以保障系统的连续运营。
双机热备、集群及高可用性入门
双机热备、集群及高可用性入门
什么是双机热备？ 双机热备这一概念包括了广义与狭义两种意义。 从广义上讲，就是对于重要的服务，使用两台服务器，互相备份，共同执行同一服务。当一台服务器出现故障时，可以由另一台服务器承担服务任务，从而在不需要人工干预的情况下，自动保证系统能持续提供服务。(相关文章：为什么需要双机热备？) 双机热备由备用的服务器解决了在主服务器故障时服务不中断的问题。但在实际应用中，可能会出现多台服务器的情况，即服务器集群。(相关文章：双机软件与集群软件的异同) 双机热备一般情况下需要有共享的存储设备。但某些情况下也可以使用两台独立的服务器。(相关文章：双机热备的实现模式) 实现双机热备，需要通过专业的集群软件或双机软件。(相关文章：双机与集群软件的选择) 从狭义上讲，双机热备特指基于active/standby方式的服务器热备。服务器数据包括数据库数据同时往两台或多台服务器写，或者使用一个共享的存储设备。在同一时间内只有一台服务器运行。当其中运行着的一台服务器出现故障无法启动时，另一台备份服务器会通过软件诊测（一般是通过心跳诊断）将standby机器激活，保证应用在短时间内完全恢复正常使用。(相关文章：双机热备、双机互备与双机双工的区别) 为什么要做双机热备？ 双机热备针对的是服务器的故障。 服务器的故障可能由各种原因引起，如设备故障、操作系统故障、软件系统故障等等。一般地讲，在技术人员在现场的情况下，恢复服务器正常可能需要１０分钟、几小时甚至几天。从实际经验上看，除非是简单地重启服务器（可能隐患仍然存在），否则往往需要几个小时以上。而如果技术人员不在现场，则恢复服务的时间就更长了。 而对于一些重要系统而言，用户是很难忍受这样长时间的服务中断的。因此，就需要通过双机热备，来避免长时间的服务中断，保证系统长期、可靠的服务。 决定是否使用双机热备，正确的方法是要分析一下系统的重要性以及对服务中断的容忍程度，以此决定是否使用双机热备。即，你的用户能容忍多长时间恢复服务，如果服务不能恢复会造成多大的影响。 在考虑双机热备时，需要注意，一般意义上的双机热备都会有一个切换过程，这个切换过程可能是一分钟左右。在切换过程中，服务是有可能短时间中断的。
高可用系统部署方案
高可用性系统部署方案 2010年2月5日 1.1 概述 1.1.1 前言 在金融工程系统应用中，对服务器的安全性、可靠性要求较高，在服务器故障情况下，要求尽可能短的时间内恢复运行，并且能对故障发生时的数据进行恢复和处理，而能否实现这一功能是一个系统是否达到高可用性的主要指标。
高可用性可体现于应用系统和数据库存储两部分，应用系统部分重点是主备机达到故障自动切换，而数据存储部分注重数据的完整性、安全性和故障转移。 1.1.2 目前情况 股指套利、算法交易、交易网关等系统在使用上需要作整个架构部署的高可用性考虑，但目前只是部分或没有作整个系统的高可用性方案及实现。 1.1.3 参考文档 附件：SQL2005数据镜像方案测试报告_20100204.doc 1.2 高可用性需求 即要实现高可用性，又要控制成本投入，实施部署也要可操作性强是这次方案的主要目标，基于此目标，本方案对成本很高的共享磁盘阵列的故障转移群集和第三方商业故障系统不作为实现技术方案。 本方案解决的高可用性需求如下： 1、应用主服务器故障发生时，连接能够短时间内自动连接到备机继续工作。 2、数据库主服务器发生时，备机上要有完整的数据，并且连接到主数据库的连 接会话能很快的重新连接到备机上继续工作 3、应用系统和数据库的服务器均能达到自动故障切换转移，以达到快速故障恢 复的目的。 4、服务器数量尽可能少，成本投入不能太高。 1.3 解决方案 出于安全和可靠性考虑，建议数据库和应用系统部署在不同的服务器上，以减少性能上的彼此影响。以算法交易服务应用为例，在母单下得较多的时候会出现系统CPU和内存上的较大消耗，如果再加上数据库的占用资源，很容易出现系统负载过重，故在方案中将应用系统与数据库分布在不同服务器，便于管理及提高整体性能。
核心系统高可用性设计
关于系统稳定性策略的探讨 1.前言 系统作为业务系统的核心，其运行稳定性和高可用性至关重要。因此，需要通过高可用性设计来尽量减少系统的计划内和计划外停机，并在系统出现故障时及时响应、快速恢复，以保障关键数据和业务系统的运行稳定性和可持续访问性。其中： 1.计划内停机是指管理员有组织、有计划安排的停机，比如升级硬件微码、升 级软件版本、调整数据库库表、更换硬件设备、测试系统新功能等时，可能需要的停止系统运行。 2.计划外停机是指非人为安排的、意外的停机，比如当硬件出现重大故障、应 用程序停止运行、机房环境遭到灾难性的破坏时所引起的业务系统停止运行。 目前，对于计划内和计划外停机，可通过消除系统中的单点失效来尽量减少停机时间。同时，通过采用可在线维护（固件升级、在线扩充、故障部件更换）的设备，并通过负载均衡机制实现应用系统的在线升级、维护，将有效消除计划内停机对业务系统的影响。此外，由于系统中采用了全面的负载均衡设计，并针对系统失效提供了可靠的数据备份恢复和多点容灾保护，因而能够有效减少系统计划外停机的恢复时间。 在造成系统宕机的原因方面，有统计中表明并非都是硬件问题。其中，硬件问题只占40％，软件问题占30％，人为因素占20％，环境因素占10％。因此，高可用性设计应尽可能地考虑到上述所有因素。对于系统而言，其整体的可用性将取决于内部的应用系统、主机、数据库等多种因素；同时，训练有素的系统维护人员和良好的服务保障也是确保系统稳定运行和故障快速恢复的关键。 2.应用系统 系统在应用软件架构设计中应从渠道层、渠道管理层、业务处理层等不同
层面通过多种措施和策略的综合设计来提高应用系统的高可用性和稳定性。 在渠道管理层和业务处理层的设计中，要考虑设置应用负载均衡、应用软件失效备援、vip服务通道、流量控制、故障隔离等机制。 1.应用负载均衡 应用软件负载均衡通过多个层次上不同的负载均衡策略一起实现整体的负载均衡，应用负载均衡的设计思路是将大量的并发访问或数据流量分担到多台节点设备上分别处理和将单个重负载的运算分担到多台节点设备上做并行处理来达到负载均衡的效果，从而提高服务响应速度，提高服务器及其他资源的利用效率，避免服务请求集中于单一节点导致拥塞。 2.应用软件失效备援 应用软件构建在面向服务的架构、设计思想上，应用服务具有较高的可灵活部署性。通过这种灵活性，结合系统基础设施的规划、部署可以实现应用软件的失效备援。系统可以考虑实现基于应用服务和基于应用服务管理框架的多种应用软件失效备援机制。 基于应用服务的失效备援是在应用服务管理框架中可以实现应用服务的冗余部署，利用硬件负载均衡设备或应用软件负载均衡可以在需要时将服务请求切换到相应的冗余服务。 基于应用服务管理框架的失效备是将应用服务框架在系统中冗余部署，利用硬件负载均衡设备或应用软件负载均衡可以在需要时将服务请求切换到相应的冗余的应用服务管理框架。 3.vip服务通道 在系统中，从系统运行稳定性、持续性及处理性能的角度，配合物理设备、系统支撑软件（数据库系统、操作系统）的相关措施，应用软件可通过构建VIP服务通道的方式降低应用服务运行期间的相互影响。服务通道可以基于不同业务产品或不同应用服务管理框架的不同粒度来设置，从而满足部分应用处理资源只响应特定的服务请求或不同的服务监听响应不同的通道传递过来的服务申请的功能。 4.流量控制 在系统中，从系统运行稳定性、持续性角度，配合物理设备、系统支撑软
如何构建高可用性高扩展性的系统方案
如何构建高可用性高扩展性的系统
1高可用性 1.1避免故障 1.1.1明确使用场景 保持系统简单 1.1.2设计可容错系统 Fail Fast原则 主流程任何一步出现问题，就应该快速结束接口和对象设计要严谨 能否被重复调用 多线程并发环境下是否有异常 对象类型是否需要检查 1.1.3设计具备自我保护能力的系统对第三方资源持怀疑态度，提供降级措施1.1.4限制使用资源 内存
防止集合容量过大造成OOM 及时释放不再使用的对象 文件 网络 连接资源 线程池 1.1.5其他角度 分析可能的风险 1.2及时发现故障 1.2.1监控报警系统 1.2.2日志系统和分析系统1.3及时故障处理 1.3.1降级 1.3.2限流 1.4访问量上涨的应对策略
1.4.1垂直伸缩 增加配置 1.4.2水平伸缩 增加机器 1.4.3拆分 按业务拆库 按规则拆表 1.4.4读写分离 实时性要求不高、读多写少的系统如何快速地从写库复制到读库 1.4.5其他 容量规划 2高可扩展性 2.1垂直伸缩 2.1.1高访问量
增加CPU 锁 线程数 单线程程序 增加内存 cache JVM堆 2.1.2大数据量 分表 单表数据量减少 跨表查询、分页查询复杂度提升2.1.3计算能力 线程数提升 2.2水平伸缩 2.2.1高访问量
SNA（Shared Nothing Architecture）有状态的部分，放入缓存或数据库中有状态的情况 存在内存的状态 广播同步 例如session同步 单台机器容量有限 分布式缓存 一致性hash 文件 直连存储DAS((Direct-Attached Storage) 网络存储 NAS(Network Attached Storage) SAN(Storage Area Network) 分布式文件系统 GFS HDFS 数据库问题 cache
计算机集群技术的解释
【赛迪网独家特稿】集群技术是使用特定的连接方式，将相对于超级计算机便宜许多的计算机设备结合起来，提供与超级计算机性能相当的并行处理技术。早在七十年代就有人提出可以使用这种集群技术完成并行处理，但是由于受到当时网络交换技术的限制，集群系统在性能上与其他并行处理系统相距甚远，直到网络技术逐渐成熟的今天，它才具备了与超级计算机相匹敌的能力。 什么是集群 集群（Cluster）技术是指一组相互独立的计算机，利用高速通信网络组成一个计算机系统，每个群集节点（即集群中的每台计算机）都是运行其自己进程的一个独立服务器。这些进程可以彼此通信，对网络客户机来说就像是形成了一个单一系统，协同起来向用户提供应用程序、系统资源和数据，并以单一系统的模式加以管理。一个客户端（Client）与集群相互作用时，集群像是一个独立的服务器。 计算机集群技术的出发点是为了提供更高的可用性、可管理性、可伸缩性的计算机系统。一个集群包含多台拥有共享数据存储空间的服务器，各服务器通过内部局域网相互通信。当一个节点发生故障时，它所运行的应用程序将由其他节点自动接管。在大多数模式下，集群中所有的节点拥有一个共同的名称，集群内的任一节点上运行的服务都可被所有的网络客户所使用。 集群的特点 1．提供强大处理能力的高性能计算机系统：计算机集群可以通过负载均衡、并行处理、时间片处理等多种形式，将多台计算机形成高性能计算机集群。对用户端（Client）而言，计算机集群则是一个单一的系统，可以为用户提供高性能的计算机系统，而用户不用关心有多少计算机承担了系统实现的任务，而只需要关注系统的整体处理能力。因此，计算机集群可以用多台普通性能的计算机组成具有高性能的计算机系统，承担只有超级计算机才能胜任的工作。 2．提供高可用性的计算机系统：通过计算机集群技术组成的系统，可以确保数据和应用程序对最终用户的高可用性，而不管故障属于什么类型。即当计算机集群中的节点计算机出现软硬件故障的时候，高可用性集群提供了对软件和硬件失败后的接替。它将服务器镜像到备用系统或节点中，当主节点上的系统崩溃时，冗余节点就从替补角色转换到正式角色，并自动投入应用，从而保证了系统运行的不间断。
企业级信息管理系统的高可扩展性和灵活性
企业级信息管理系统的高可扩展性和灵活性 骆金松 我一直在从事企业信息管理系统的开发，目前的产品拥有了数百个企业客户，作为企业管理信息系统，最大的挑战是如何满足不同企业通用需求的同时快速满足企业个性化需求，除了企业战略、组织架构、流程体系等紧密相关外，软件的平台化水平，可扩展性和灵活性至关重要。有一句话很经典：“最好的架构师是能够在软件开发所涉及的诸多内部因素和外部因素寻求最佳的平衡”。一个高度平台化的系统，对高可扩展性和灵活性是非常关注的，今天我想讨论如何满足企业信息管理系统的扩展性和灵活性。这个话题涉及的内容太多了，我只是在做产品和项目过程中谈谈我的体会，希望对大家有一些参考价值。 （1）高可扩展性和灵活性的系统一般是分层架构的，这里说的分层是指将客户的需求按需求的通用性分层。根据自己平台所应用的目标客户群，分析客户的共性需求，将共性部分的需求放在平台的最底层实现，所有的客户共用，不要有分支版本，个性的需求放在高层实现，不同的客户可以完全定制。至于整个架构的层次数量没有绝对的标准，可参考的方法分为4层，“公共平台层”、“产品平台层”、“行业扩展层”、“个性扩展层”。这里的分层与软件架构中的表示层、中间层、持久层的分发属于不同的维度，是没有冲突的。 （2）高可扩展性和灵活性的系统一般是模块化的。系统最好提供统一的主板插件体系，每一层都应该提供若干插槽，通过二次开发的手段供上层扩展，做项目多了一般都会形成组件库，应该对这些组件进行分类分级管理。一旦有了新的项目，一般从现有的组件库中挑选进行配置，部分不满足要求的可以进行修改后满足，其他个性化很强的完全定制。 （3）高可扩展性和灵活的系统一般都支持数据建模。许多人理解系统可扩展就是指系统提供API，可以二次开发，其实这种理解不全面。数据结构是企业信息管理系统很重要的一部分，是否可以方便支持数据结构的扩展非常重要，我们的经验是提供图形化的数据建模模块，可以自动生成数据库的表结构，同时将数据库的结构也保存为元数据，通过解析元数据可实现数据的对象关系映射，而不依赖于硬编码。一般采用了数据建模的系统将数据进行对象化统一管理，这样的好处是统一风格，也容易实现。因为有了元模型，可以动态生成部分用户界面，减少用户界面开发工作量。 （4）高可扩展性和灵活的系统一般都支持流程建模。不同企业的业务流程是千变万化的，所以需要提供业务流程建模模块，可以用图形化的方式定义企业的业务流程，依赖业务流程的驱动
高可用性报告
高可用报告 一、 高可用分析 1、三个概念 失效(fault)：指设备或程序自身固有缺陷导致的瞬间或永久性的功能失常。 错误(error)：由失效导致的系统内部不正确行为。错误可以被发现并进行纠正。 故障(failure)：指由于出现错误导致了系统产生了不正确的结果。 2、平均故障发生时间MTTF ( Mean Time To Failure ) MTTF 是一个统计上可测量的参数 MTTF 寿命 MTTF= 1 / 稳态运行期间的故障发生率 N 台机器T 时间内故障数: E = (N ×T)/ MTTF 3 可靠性: 系统连续提供服务的能力，MTTF: Mean Time To Failure 可维护性:修复故障使系统恢复正常的能力，MTTR: Mean Time To Repair 4、可用性(Availability) 可用性= MTTF / (MTTF + MTTR) 例: MTTF=5000小时, MTTR=1天, 则可用性为： 5000/(5000+24) = 99.52% 5、提高可用性的途径 1) 提高 MTTF 2) 降低 MTTR 二、硬件高可用 （一） Cluster 中硬件HA 的目标 1、 问题的起源：单点故障问题及其应对策略
单点故障：某些硬件或软件部件，它们的故障会导致整个系统的崩溃。[6] 机群系统可能出现的单点故障有： ●处理器或节点 ●存储程序或数据的磁盘 ●适配器、控制器和连接节点到磁盘的电缆 ●用户访问机群节点的网络。 ●应用程序 应对策略：通过系统地消除那些单点故障来尽可能使更多的故障成为部分故障。[6]解决机群中的单点故障问题：解决大多数的单点故障问题并不需要使用任何分层软件产品。计算从任何特殊错误中恢复所需人工干涉的总时间和精力。然后再考虑系统能否承受停机造成的损失，以及能否提供全天操作中必须的人工干预。对于机群设计者而言，这将有助于决定是使用人工干预来管理还是需要采取其它措施来满足高可用性的要求。 ?节点故障 在机群中，当一个节点提供的服务是关键性的话，那么当该节点失效时，机群中必须有另外的节点来代替它的资源，向终端拥护提供相同的服务。 包括以下步骤： 1、在备用节点的网络适配器配置失效节点的地址，或者提示用户（或改变客户端应用程序） 使用一个替换的地址。 2、在故障和备用节点之间引入和改变所有组的卷，并且装上所有需要的文件系统。 3、修复存储在故障节点内部磁盘上的所有应用程序和数据。 4、执行任何鉴定性的应用程序。 假定后备节点在关键服务中还没有被网络访问。这样，每个节点需要额外的网络适配器，这个节点将被备份。如果用户通过串行连接访问失效节点，每个终端应该物理上重连接到后备节点的端口上。如果外部磁盘没有连接到失效节点和后备节点之间的通用总线上，则需要手工将他们从一个转换到另一个。所有关键数据被保存在外部磁盘上。如果最后的后备节点变为不可用，所有关键数据则被保存至节点的内部磁盘。 ?磁盘和I/O总线故障 为了防止包括磁盘的外部I/O通道中的任何部分出错，应该在两路I/O总线上将磁盘镜象或者使用从节点到存储子系统有双重路径的磁盘阵列系统。 ?网络适配器故障 为了防止网络适配器故障，每个提供关键服务的节点需要配置备用网络适配器。这个适配器连接到与用户正在访问的主适配器相同的网络主干上。如果网络适配器失效，可以将备用适配器的地址改为失效适配器的地址。另外一种方法是始终有一个热备份的网络适配器可以随时替代出错适配器。这种方法从故障中恢复的时间更短，因为系统安装备用适配器无需停机。 ?网络故障 如果用户正在和一个节点通信时网络主干停止工作，解决方案之一是人工地将所有机群节点和客户端机器切换到另外一个主干上。即便有足够的时间和精力去这样做，还得保证没有松散的连接或网络设备（路由器、集线器或网桥）故障引起主干失效。另外一个解决方案是连接一个终端的子集到备用节点的串口上，这样还可以提供最小级别的服务。在这种情况下应用程序必须被设计成允许用户既可以通过网络连接到终端也可以通过串口连接到终端。 ?应用程序故障 根据应用程序的设计，为监控应用程序使用的后台程序，并及时对状态改变作出反应，应该使用AIX子系统资源控制器。 2、人工干预的缺点 根据上述的讨论，依据故障的不同类型。包括检测故障所花时间，很明显从任何机群故障中人工恢复的时间为30分钟到几个小时。这对许多应用在重要场合的机群来说已经是不可容忍的了。
RoseHA 高可用性系统解决实施方案
RoseHA 高可用性系统解决方案
————————————————————————————————作者：————————————————————————————————日期： 2
RoseHA 高可用性系统解决方案 RoseHA 高可用性系统解决方案以低成本且简便的方式，实现了两个节点的Cluster环境.客户只需要在 原有的单机系统上增加一台服务器、一个共享存储设备，通过Rose基于共享存储的高可用解决方案即 可实现关键业务的7X24小时连续运行，对于需要更有效应用现有服务器资源的用户而言，是最为适用 的解决方案。 RoseHA的工作原理 RoseHA双机系统的两台服务器（主机）都与磁盘阵列（共享存储）系统直接连接，用户的操作系统、应用软件和RoseHA高可用软件分别安装在两台主机上，数据库等共享数据存放在存储系统上，两台主机之间通过私用心跳网络连接。配置好的系统主机开始工作后，RoseHA软件开始监控系统，通过私用网络传递的心跳信息，每台主机上的RoseHA软件都可监控另一台主机的状态。当工作主机发生故障时，心跳信息就会产生变化，这种变化可以通过私用网络被RoseHA软件捕捉。当捕捉到这种变化后RoseHA 就会控制系统进行主机切换，即备份机启动和工作主机一样的应用程序接管工作主机的工作（包括提供TCP/IP网络服务、存储系统的存取等服务）并进行报警，提示管理人员对故障主机进行维修。当维修完毕后，可以根据RoseHA的设定自动或手动再切换回来，也可以不切换，此时维修好的主机就作为备份机，双机系统继续工作。 RoseHA实现容错功能的关键在于，对客户端来说主机是透明的，当系统发生错误而进行切换时，即主机的切换在客户端看来没有变化，所有基于主机的应用都仍然正常运行。RoseHA采用了虚拟IP地址映射技术来实现此功能。客户端通过虚拟地址和工作主机通讯，无论系统是否发生切换，虚拟地址始终指向工作主机。在进行网络服务时，RoseHA提供一个逻辑的虚拟地址，任何一个客户端需要请求服务时只需要使用这个虚拟地址。正常运行时，虚拟地址及网络服务由主服务器提供。当主服务器出现故障时，RoseHA会将虚拟地址转移到另外一台服务器的网卡上，继续提供网络服务。切换完成后，在客户端看来系统并没有出现故障，网络服务仍然可以使用。除IP地址外，HA还可以提供虚拟的计算机别名供客户端
Linux高可用集群系统的结构和原理分析
收稿日期:2007-09-15 第一作者简介:左 婷(1979-),女,吉林省四平市人,现为吉林师范大学信息网络中心研究实习员. 2007年11月 吉林师范大学学报(自然科学版) .4第4期Journal of Jilin Normal University(Natural Science Edition)Nov.2007 Linux 高可用集群系统的结构和原理分析 左 婷1,吴会军2 (1.吉林师范大学信息网络中心,吉林四平136000;2.吉林省水文水资源局,吉林长春130000) 摘 要:通过对目前常用Linux 平台上高可用集群系统的软、 硬件基本结构和工作原理的分析与研究,构建容易扩展、高可用、易维护和管理、高性价比的计算机系统. 关键词:L inux;高可用集群系统;结构;原理 中图分类号:T P393 文献标识码:A 文章编号:1000-1840-(2007)04-0115-02 目前,很多国际知名软件公司和计算机厂商都推出了 自己的集群产品,其中值得一提的是T he H igh A vailability L inux Project 的开放源代码Heartbeat,已经同商业集群软件 一样成熟,而且较后者应用更为灵活.本文将着重介绍SuSE L inux Enterpr i se Server 10平台上Heartbeat2.0.8组成结构 和工作原理.1 Linux 高可用集群系统的基本概念伴随着集群技术的发展,出现了一些关于集群系统的概念和术语.(1)集群资源和集群资源代理.在集群系统中,所有由集 群控制和管理,并将其以单一和统一的形式提供给客户端用 户使用的计算机资源称为集群资源,例如:一种服务、一个 IP 地址、一个磁盘驱动,甚至可以说:除了节点,其它任何软 硬件资源都可以成为集群资源.而集群资源代理是为了控制 和管理某一集群资源而编写的代理程序脚本,集群软件通过 特定集群资源代理来操控某一集群资源,Heartbeat 套件本 身已经包含了一些常用资源代理,开发人员也可以自己按照 一定的规范编写;(2)指定协调者(也称主节点).主节点除了 具有其它一般节点具有的集群节点基本功能外,还负责对整 个集群系统的状态进行监控、分析和转换,对集群系统下达 集群指令,协调各节点的操作等,实际上是整个集群系统的 大脑!,显然一般情况下,整个集群系统只有一个主节点,但 当某些特殊情况发生时,例如主节点不再是集群中的节点, 主节点将发生迁移,即位置发生了变化,另一个节点将代替 它成为主节点;(3)ST ON IT H.英文 Shoot T he Other Node In T he Head !的缩写,代表一种将错误操作的节点进行隔离 的技术,为了防止错误操作的节点对集群资源进行破坏性控 制和操作,使其不断重新启动或关机,从而使其无法取得对 集群资源的控制权;(4)裂脑和仲裁.在某种情况下,由于软 硬件失败导致各节点无法相互确定彼此的状态时,整个集群将被分裂为几个部分,每个部分都想取得对集群资源的控制权,以保证集群的高可用,这种对集群资源的竞争将严重破坏集群资源的完整性和一致性,甚至导致整个集群瘫痪、硬件被损坏的严重后果,这种情况称为裂脑.为了防止裂脑的发生,由仲裁协议决定哪个部分来取得对集群资源的控制 权,为了继续保证系统的高可用,一般将控制权交给节点数 超过原集群节点数一半的部分,同时将其它节点进行隔离; (5)单点故障(失败).单点故障是指由于系统中某一组件的 故障或运行失败从而导致整个集群系统瘫痪和应用服务完 全停止,因此,在高可用集群的构建中应尽量避免单点故障.2 Heartbeat 的主要进程Heartbeat 的所有集群功能都是由它的进程和它们之间相互通信来具体实现的.(1)集群资源管理器(CRM ,Cluster Resource M anager).CRM 是集群系统中最主要的管理进程,它负责对整个集群资源的管理和约束,包括资源的配置及相互间依赖关系,并决定资源运行的状态、位置和时间等.另外它还负责监控本地资源管理器完成这些工作,CRM 通过与系统的每一个组件通信来相互作用和协调操作,CRM 通过heartbeat 通讯模块进行节点间通讯,从CCM 接受当前集群的成员信息,指令ST O NI TH Daremon 如何工作,负责记录系统日志等;(2)策略引擎(PE,CR M Policy Eng ine).PE 是CRM 的一个组件,只能在主节点上运行.PE 的功能是根据当前集群的状态及集群资源的约束配置计算出集群的下一个状态,即为T E 生成将要执行的计划和策略;(3)执行引擎(T E,CRM T ransi tion Engine).T E 也是CRM 的一个组件,只能在主节点上运行.T E 的功能是按照P E 生成的集群状态变化计划和策略,指令集群节点上的LRM 对具体的集群资源进行操作;(4)?115?
系统的可扩展性
什么是系统的可扩展性？ 到底什么是可扩展性？这年头，作为软件设计架构师如果系统没有可扩展性对外交流时都不好意思。但是如何选择可扩展性方案？水平扩展还是垂直扩展？是不是很矛盾呢，本文为你分析可扩展性的真实含义和实际项目中的取舍。 When asked what they mean by scalability,a lot of people talk about improving performance,about implementing HA,or even talk about a particular technology or protocol.Unfortunately,scalability is none of that.Don’t get me wrong.You still need to know all about speed,performance,HA technology,application platform,network,etc.But that is not the definition of scalability. 每每和别人提及可扩展性的含义时，很多人开始讨论提高性能，实施高可用性，甚至谈论特定的技术或协议。显然这些并不是可扩展性。不要误会，您当然需要了解关于速度，性能，可用性，应用平台，网络等相关的一切，但这并非可扩展性的定义。 Scalability,simply,is about doing what you do in a bigger way.Scaling a web application is all about allowing more people to use your application.If you can’t figure out how to improve performance while scaling out,its okay.And as long as you can scale to handle larger number of users its ok to have multiple single points of failures as well. 简单地说，可扩展性就是关于如何处理更大规模的业务。比如，Web应用程序就是允许更多的人使用你的服务。如果你不能弄清楚如何提高性能的同时
高可用多机集群数据备份双机热备方案
PLUSWELL多机集群、数据备份解决方案 北京蓝科泰达科技有限公司 2008年7月
一：概述 企业和事业单位的运转越来越依赖于计算机系统，如果一旦这个数据处理中心无法正常运转，就会造成业务停顿，导致不可挽回的损失。 而现有的双机热备份设备存在价格高昂，成本较高的情况，往往使用户望而却步。而用户寻求底成本的纯软件方案又往往因产品不容易维护，纯软件双机方案不稳定等因素，往往给用户造成不必要的使用麻烦。有时因护理不当造成数据损坏，发生更大的事故。 蓝科泰达凭借其丰富的研发经验，为您提供高可用性系列产品和优质的服务，推出了蓝科泰达双机容错打包解决方案，目的在于保证数据永不丢失和系统永不停顿，同时为用户节省大量的开支。蓝科泰达容错系统结合了蓝科泰达磁盘阵列产品的安全可靠性与双机容错技术高可用性的优点，相互配合二者的优势。蓝科泰达磁盘阵列针对双机容错技术做了许多优化和改进，满足了双机硬件的连接要求，根据应用环境的实际情况，适用于Windows2000平台以上，开放源代码Linux 平台，SCO UNIX平台上的多种双机热备软件。 二、需求分析 企业关键业务一旦中断，企业的日常运作将受到致命的影响，那么就要求我们的系统在最短的时间内将系统恢复到正常状态。 所以我们要求双机软件能够实现以下几点： 1、异常终端检测 2、网络故障，系统故障，应用程序故障等全系统检测 3、当高可用系统中的某个节点故障，无须人工干预自动切换，保障系统运行 4、速度快（快速恢复） 贵单位业务平台，是以Windwos 2003 Server系统平台为基础，以SQL Server核心的数据 库应用系统，该系统对稳定性要求很高、系统实时性和可用性提出要有连续运行的能力，系统一旦出现故障，其损失是惨重的。 因此，建议用户采用高可用技术，高可用系统在各个节点间保持的间歇的通讯，使系统中的独立节点组合成整体的一套系统，并使用PlusWell 软件可以保障该系统中的某一节点故障都可 被PlusWell 软件所监控，如主服务器应用程序、网卡、操作系统，均纳入公共的安全体系，确 保7*24的不停机。 比较典型的危及系统安全应用和系统错误主要有： （1）进程错误，比如用户应用与文件数据库的连接异常中断或用户进程发生错误。 （2）文件系统故障，由于异常操作或其它原因造成文件系统内部部分信息丢失或不一致。 （3）操作系统故障，操作系统本身的系统调用问题及底层的应用驱动在安装或更新出现冲突； （4）网络线缆故障。 （5）介质问题，网络连接或物理硬盘也可能会出现问题。 方案拓扑：