可用性解决方案设计思路

《可用性解决方案设计思路》由会员分享，可在线阅读，更多相关《可用性解决方案设计思路（20页珍藏版）》请在金锄头文库上搜索。

1、第一部分：可用性( Availability )设计可用性设计的重要性可用性设计是数据中心规范化设计的核心。从总体原则来讲，可用性设计是数据中心面向服务设计的基础，通过可用性设计，理清每一 种业务的可用性等级、所需资源及资源之间的依赖关系，才能最终为相应的业务提供适当的服务；从运维管理来说，可用性设计是服务等级协议(Service Level Agreement，简称SLA)的核心 内容，没有可用性分析和设计，在运维管理中，就无法做到重点突出、张弛有度，将使运维管理的 标准化、流程化失去支撑，变成空中楼阁；从未来的容灾规划来说，可用性设计为容灾设计提供了依据。任何的容灾标准都有科学、严 格的等

2、级划分，任何的容灾规划都会根据业务的可用性等级适用相应的容灾等级，进行科学的匹 配，从而为不同的业务应用提供适用的保护等级；因此，没有可用性设计的数据中心规划是不完整的，将会使核心业务暴露在极高的风险中。可用性设计的原则一、设计逻辑顺序原则应该通过业务的可用性调研，推导出适用的技术，再通过技术推导 出适用的产品，最后再对方案和预算进行双向匹配，作出最优化的调整；二、核心业务优先原则当由于预算、技术条件或其他资源限制而需要妥协时，应首先保证 核心业务需要；三、避免漏洞原则由于可用性是一个“链”，忽略任何一个环节，都可能导致整个业务系 统出现单点故障，而避免出现单点故障也是进行可用性设计最重要的目

3、标之一。另一方 面，任何的系统都不可能没有漏洞，最重要的是当出现问题的时候，一定要有相应的后备 手段。比如：我们都知道高端磁盘阵列的可用性是最高的，设备本身都是全冗余设计，但 我们不能寄希望于这个单一设备不发生故障，如果设备发生故障，我们必须要有相应的后 备手段来控制系统的停机时间；四、以数据为核心的原则由于数据是整个数据中心的核心资产，是业务运行的基础，而且 数据具有唯一性、不可再生性等特点，所以在可用性设计中，数据的可用性是核心；五、平衡性原则掌握平衡是一门艺术，我们要进行集中，但不能为了集中而集中，管理层 面需要集中，将控制点集中，有利于管理。设备层面需要根据客观情况进行分布式部署， 从

4、而为不同的应用提供相应的可用性、冗余度、计算资源、存储资源等。特别需要注意的 是，不能在集中的过程中造成某些环节过于集中，从而形成单点故障，适度的分散和隔离 有利于防止大规模全面瘫痪的恶性事故。可用性分析的基本方法第一，可用性分析是以应用为对象进行的，换句话说，用户需要对前端业务的真实可用性需 求有一个基本准确的把握。如果IT部门不是很清楚的话，调研人员可以协同IT部门向业务需求部 门的主管人员征询，一般可以用单位停机时间造成的损失进行衡量。主要的目标是确定每一个业务 应用可用性的范围，务必实事求是；第二，可用性分析的核心量化指标是RPO/RTO,如下图所示：恢复点恢复时间Recovery P

5、oint 0 bjective (RPO) 是指可以容忍的趾拒壬尖量Recovery Time Objective(RTO) 昱指可以容忍的停讥时间1Miit*IT 系统的可用性核心指标就是恢复点和恢复时间，这是可用性调研的主要内容。 第三，可用性是一个“链”，就像所谓“木桶原理”，可用性的最终指标，取决于最薄弱的 环节也就是我们通常所说的“单点故障(Single-Point-of-Failure )”，因此，我们需要在分析 中，找到每一个应用对应的整个链条，而不是将整个注意力放在某一个焦点上。如下图所示：应曲料序加势器客户jai.fr站即使在一个非常简单的网络中，一个应用系统也会存在一个完整

6、的链条：从客户端到网络， 再到服务器、存储设备，任何一个环节出现故障，都会导致应用一定程度的可用性丧失。而越是集 中的点(如存储、服务器)，故障导致的破坏性越大，反之，越是分散的点(如客户端、桌面交换 机)，故障导致的破坏性越小。当然， IT 设备之外的支撑设施(如供电系统、制冷系统)也是应用 可用性链条中的一个环节，但那部分的可用性规划放在机房建设章节中具体论述，此处不作为重 点。第四，在调研的基础上，有针对性地采用不同的技术来满足不同应用的可用性要求。如下图 所示：1陕it业爵g.1抄 幷钱车时天天 申时井钟=紈像恢恢复点恢复时间（粉蛟从这张图上，我们可以简单地对业务系统的关键程度进行级别

7、的划分，RPO/RTO要求越高的应用越是关键，反之亦然。那么，不同的业务级别，相应地就应该采用不同的技术来满足其要求。如非关键业务通常利用传统的备份恢复手段，可以达到小时到天级别的可用性等级，而关键业务则 应采用集群、映像恢复、数据镜像、快照等技术来满足，可以达到分钟到秒级的可用性等级。针对数据中心整合后可用性提高的具体建议在调研的基础上，我们可以对咸阳社保各个委办局的应用进行可用性级别的划分，如下表所服务器类别RPO/RTO重要性A类0分钟级髙B类分钟小时级中C类小时天级低A、B、C三类服务器其实代表了三类不同的应用，它们的可用性级别依次分别为高中低三个 档次。相应地，这三类应用可用性需要采

8、用的技术如下表所示:应用可用性技术级别A类服务器集群、存储镜像B类系统映像恢复、数据快照C类系统映像恢复、传统备份恢复技术解释什么是集群？集群（Cluster ）是由两台或多台节点机（服务器）构成的一种松散耦合的计算节点集合，为 用户提供网络服务或应用程序（包括数据库、Web服务和文件服务等）的单一客户视图，同时提供 接近容错机的故障恢复能力。集群系统一般通过两台或多台节点服务器系统通过相应的硬件及软件 互连，每个群集节点都是运行其自己进程的独立服务器。这些进程可以彼此通信，对网络客户机来 说就像是形成了一个单一系统，协同起来向用户提供应用程序、系统资源和数据。除了作为单一系统提供服务，集群系

9、统还具有恢复服务器级故障的能力。集群系统还可通过在集群中继续增加服务 器的方式，从内部增加服务器的处理能力，并通过系统级的冗余提供固有的可靠性和可用性。集群的分类：1、高性能计算科学集群：以解决复杂的科学计算问题为目的的 IA 集群系统。是并行计算的基础，它可以不使用专门 的由十至上万个独立处理器组成的并行超级计算机，而是采用通过高速连接来链接的一组 1/2/4 CPU的IA服务器，并且在公共消息传递层上进行通信以运行并行应用程序。这样的 计算集群，其处理能力与真正超级并行机相等，并且具有优良的性价比。2、负载均衡集群：负载均衡集群为企业需求提供更实用的系统。该系统使各节点的负载流量可以在服务

10、器集 群中尽可能平均合理地分摊处理。该负载需要均衡计算的应用程序处理端口负载或网络流 量负载。这样的系统非常适合于运行同一组应用程序的大量用户。每个节点都可以处理一 部分负载，并且可以在节点之间动态分配负载，以实现平衡。对于网络流量也如此。通 常，网络服务器应用程序接受了大量入网流量，无法迅速处理，这就需要将流量发送给在 其它节点。负载均衡算法还可以根据每个节点不同的可用资源或网络的特殊环境来进行优 化。3、高可用性集群： 为保证集群整体服务的高可用，考虑计算硬件和软件的容错性。如果高可用性群集中的某 个节点发生了故障，那么将由另外的节点代替它。整个系统环境对于用户是一致的。在可用性设计中，我

11、们所说的集群通常指的是高可用性集群，或者叫“故障转移集群”，主 要是用于防止服务器的单点故障造成整个应用的停机。由于传统的双机热备方式，造成服务器利用效率只有 50%，在新上应用或者服务器更新换代 时都同时购买两台，构成双机热备的模式。通过数据中心整合，可以将传统的双机热备模式改造成N:1或者N:M的热备模式，如下图所产股护3（常户咽第!S牛声库毎番牛十胆莽;S学产理鲁31先卢IE養咼静垠话总例如：在一个中型规模的数据中心，具有6个核心应用，原来采用6套双机热备系统，总共 12台服务器，在进行整合以后，可以将整个集群整合为6:1模式，只需要一台热备服务器，总共7 台服务器，即可达到原来 12台

12、服务器所具有的可用性指标（即任意一台服务器发生故障，都有热 备服务器可以接管该应用），节省 5台服务器。这就可以大大提高高可用集群中服务器的利用效 率。什么是存储镜像（WrrorfM ）?镜像功能实现了两台存储设备（支持DAS、SAN、IP-SAN等）之间的镜像关系，每一次I/O 的写入都分别通过两条主机通道到达两台存储设备的控制器，并当两个I/O都返回正确的结果之 后，操作才算完成。如下图所示：通过蠢戟盘技术捋镜橡后鹘存養戲老的靈式，皱透明地提供墜上层M恋储设答荷洁设备二所以，两台磁盘阵列中的数据完全保持实时同步，不用担心任何的数据一致性问题。 当某一台存储设备发生故障时，镜像系统自动将故障

13、设备排除出镜像关系，即在对故障设备 的写入超时达到规定的阈值时，系统自动判断该存储设备发生故障，不再尝试写入到故障设备，而 只是继续对另一台正常存储设备的读写，并将故障信息报告给系统管理员，请求人工干预，修复故 障设备。当故障设备修复之后，如果原来的数据仍然存在，就可以利用快速重新同步(Fast Re-sync) 将故障期间在另一台存储设备上发生的数据变化增量同步到修好的存储设备上，从而大大缩短系统 的故障“愈合期”。在这种存储镜像架构中，没有存储设备的主从关系，实质上，这是镜像(Mirroring)和实时 复制(Replication)的区别。什么是实时复制Replication)?以VER

14、ITAS Volume Replicator为例，解释典型的实时复制是如何实现的。如下图所示：5T数据曲址常枣储(外買.内冒皆EJOracle Control FilecWRI匾徨Oracle Data File业躺诙器容灾fl務器VVRKIVVRiJlgOracle Redo LogOracle Archive Log 文件数据卷V 盗盘存储席卜宣、内量袴臥wrH#Oracle Data FileOracle Control FileOracle Redo LogOracle Archive LogeiaM,_文件数据港,E腹册茜在上图中，有一个单独的卷，是 VVR 复制所需的日志卷，这是一

15、个先进先出的队列，保证对 源端和目的端写入的VVR数据卷中的数据在I/O级别保持一致性即每一个I/O在写入到VVR 数据卷的时候都是完全一样的顺序，不管是在本地VVR数据卷，还是在目的端的VVR数据卷，都 完全一样。如果我们需要将Oracle数据库应用进行远程复制，就需要对服务器中运行的Oracle数据库相 关的数据进行复制，其中主要包括的数据为：Oracle数据文件、Oracle控制文件、Oracle重做日志、Oracle归档日志以及其他文件数据卷的 内容（如应用程序、中间件等），这些数据都需要进行远程保护。因此，我们通过将上述相关的数据都放在VVR数据卷中，保证在复制过程中，上述数据能够 实时复制到目的端对应的位置。除了上述这些有变化的数据之外，在服务器本地所存在的都是一些不会变化的数据，如 Oracle数据库的安装文件等，这些数据在Oracle正常运行过程中是不会变化的，因此，只要配置好 之后，并不需要对其进行实时复制保护，换句话说，在目的端的Oracle安装配置的参数，只要指定 好对数据访问的路径，当进行容灾切换时，就能够将目的端的数据库启动起来，这些参数并不会随 着业务系统的运行而变化。