精华内容
下载资源
问答
  • 衡量容灾系统性能的两个关键技术指标-RTO与RPO @(容灾)[RTO, RPO, 帮助] 对于信息系统而言,容灾就是使信息系统具有应对一定的灾难袭击,保持系统或间断运行的能力。 [外链图片转存失败,源站可能有防盗链机制,建议...

    衡量容灾系统性能的两个关键技术指标-RTO与RPO

    @(容灾)[RTO, RPO, 帮助]

    • 对于信息系统而言,容灾就是使信息系统具有应对一定的灾难袭击,保持系统或间断运行的能力。
      [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传在这里插入图片描述

    RTO

    • (RTO: Recovery Time Objective):以应用为出发点,即应用的恢复时间目标,主要指的是所能容忍的应用停止服务的最长时间,即从灾难发生到业务系统恢复服务功能所需要的最短时间周期。
    • RTO是反映业务恢复及时性的指标,表示业务从中断到恢复正常所需的时间。RTO的值越小,代表容灾系统的数据恢复能力越强;

    RPO

    • 恢复点目标(RPO: Recovery Point Objective):RPO是反映恢复数据完整性的指标。
    • 以数据为出发点,主要指的是业务系统所能容忍的数据丢失量

    另外的一种说法

    • RTO(RecoveryTime Object)指灾难发生后,从系统停机导致业务停顿开始,到IT系统恢复,业务重新运营,中间所需要的时间,即为RTO。
    • RPO(Recovery Point Object)是指一个过去的时间点,当灾难或紧急事件发生时,数据可以恢复到的时间点。(数据的丢失量)

    举例:

    • RPO=0:数据恢复到灾难发生时,数据不丢失
    • RPO=30:数据恢复到灾难发生前30分种,换句话说允许损失灾难前30分钟内的部分数据
    • RTO=0:立即恢复业务
    • RPO=30:30分钟内恢复业务
    展开全文
  • 目 录第 1 章 容灾技术规范1.1 容灾的总体规划1.1.1 技术指标 RPO、RTO1.1.2 国际标准 SHARE 781.1.2.1 Tier01.1.2.2 Tier11.1.2...

    目 录

    第 1 章 容灾技术规范

    1.1 容灾的总体规划

    1.1.1 技术指标 RPO、RTO

    1.1.2 国际标准 SHARE 78

    1.1.2.1 Tier0

    1.1.2.2 Tier1

    1.1.2.3 Tier2

    1.1.2.4 Tier3

    1.1.2.5 Tier4

    1.1.2.6 Tier5

    1.1.2.7 Tier6

    1.1.3 界定灾备系统的适用范围

    1.1.4 界定灾备建设的目标

    1.1.5 界定灾备系统的总体架构

    第 2 章 主流容灾技术说明

    2.1 数据备份

    2.2 实时数据保护

    2.2.1 数据镜像(Mirroring)

    2.2.2 数据复制(Replication)

    2.2.2.1 软件复制

    2.2.2.2 硬件复制

    2.2.2.3 数据库复制

    2.2.2.4 Datacore SDS

    2.3 应用系统恢复

    2.4 网络系统恢复

    2.5 容灾切换过程 

    2.6 消防演习

    第 3 章 主流容灾技术分析与对比

    3.1 数据备份

    3.2 实时数据保护

    3.2.1 数据镜像(Mirroring)

    3.2.1.1 硬件镜像

    3.2.1.2 软件镜像

    3.2.1.3 软件智能存储镜像

    3.2.1.4 镜像技术在容灾中的利用

    3.2.2 数据复制(Replication)

    3.2.2.1 软件复制(卷复制)

    3.2.2.2 硬件复制

    3.2.2.3 基于软件控制器的复制

    3.2.2.4 数据库复制

    3.3 应用系统恢复

    3.4 网络系统恢复

    第 4 章 容灾系统设计步骤

    4.1 第一步,深化数据备份系统

    4.2 第二步,存储、应用整合

    4.2.1 存储整合

    4.2.2 应用整合

    4.3 第三步,实现远程实时数据卷保护

    4.4 第四步,建立远程切换消防演习机制

    4.5 第五步,建立远程切换机制

    第 5 章 数据容灾的性能分析

    5.1 同步数据容灾的性能分析

    5.1.1 带宽

    5.1.2 距离

    5.1.3 中间链路设备和协议转换的时延

    5.2 异步数据容灾的性能分析

    第 1 章 容灾技术规范

    作为风险防范系统,灾备系统建设本身在总体规划、方案选择和投产实施后的管理运行,以及真正面对灾难时的切换操作等方面也存在着潜在的风险。

    计算机信息系统实现数据大集、应用大集中后,系统的运行安全成为风险控制的焦点。目前,已经有多系统开始或准备进行灾备系统的建设,灾备系统建设的目标是减灾容灾, 使计算机信息系统和数据能够最大限度地防范和化解各种意外和灾害所带来的风险。然而,与大多数工程一样,灾备系统建设本身在总体规划、方案选择和投产实施后的管理运行,以及真正面对灾难时的切换操作等方面也存在着潜在的风险。

    可以说,风险防范系统本身也存在风险点,需要小心应对。

    灾备系统建设中所涉及的潜在风险大致可分为技术风险、管理风险和投资风险,其中尤以技术选择风险最大,技术方案选择优越,可以规避一定的管理风险和投资风险。而这三者也存在内在的相互关联,不同灾备级别对应的建设投资规模、所采用的技术以及实施和管理的复杂度也不同,应考虑保护计算机系统的原有投资并提高灾备系统建设投资的利用率。

    1.1 容灾的总体规划

    真正的容灾是数据被不间断的一致性访问!

    在灾难备份的世界里,是有等级观念的,级别不同,灾备系统所采用的技术和达到的功能是不同的,在系统建设资金投入方面的差距也很巨大。所以,对用户来说,明确灾备系统建设的总体规划十分必要。

    1.1.1 技术指标 RPO、RTO

    衡量容灾技术的两个技术指标 RPO、RTO 

    RPO(Recovery Point Objective): 以数据为出发点,主要指的是业务系统所能容忍的数据丢失量。及在发生灾难,容灾系统接替原生产系统运行时,容灾系统与原生产中心不一致的数据量。RPO 是反映恢复数据完整性的指标,在同步数据复制方式 下,RPO 等于数据传输时延的时间;在异步数据复制方式下,RPO 基本为异步传输数据排队的时间。在实际应用中,考虑到数据传输因素,业务数据库与容灾备份数据库的一致性(SCN)是不相同的,RPO 表示业务数据与容灾备份数据的 SCN 的时间差。 发生灾难后,启动容灾系统完成数据恢复,RPO 就是新恢复业务系统的数据损失量。

    RTO(Recovery Time Objective):以应用为出发点,即应用的恢复时间目标,主要指的是所能容忍的应用停止服务的最长时间, 也就是从灾难发生到业务系统恢复服务功能所需要的最短时间周期。是反映业务恢复及时性的指标,表示业务从中断到恢复正常所需的时间。RTO 值越小,代表容灾系统的数据恢复能力越强。各种容灾解决方案的 RTO 有较大差别,基于光通道技术的同步数据复制,配合异地备用的业务系统和跨业务中心与备份中心的高可用管理,这种容灾解决方案具有最小的 RTO。容灾系统为获得最小的 RTO,需要投入大量资金。

    不同容灾方案的 RTO 和 RPO 是不相同的。

    1.1.2 国际标准 SHARE 78

    要建设容灾系统,就必须提出相应的设计指标,以此作为衡量和选择容灾解决方案的参数。目前,国际上通用的容灾系统的评审标准为 SHARE 78,主要包括以下内容。 

    ●备份/恢复的范围 

    ●灾难恢复计划的状态 

    ●业务中心与容灾中心之间的距离 

    ●业务中心与容灾中心之间如何连接 

    ●数据是怎样在两个中心之间传送的 

    ●允许有多少数据丢失 

    ●保证更新的数据在容灾中心被更新 

    ●容灾中心可以开始容灾进程的能力 

    SHARE 78 是建立容灾系统的一种评审标准。建立容灾系统的最终目的,是为了在灾难发生后能够以最快速度恢复数据服务, 主要体现在 RTO Objective)和 RPO 上。 SHARE 78, M028 报告中定义的灾备的七个级别和与其对应的数据丢失量与恢复时间情况详见下表:

    1.1.2.1 Tier 0

    Tier 0 - 无异地数据备份(No off-site Data) 

    Tier 0 被定义为没有信息存储的需求,没有建立备份硬件平台的需求,也没有发展应急计划的需求,数据仅在本地进行备份恢复, 没有数据送往异地。这种方式是最为低成本的灾难备份解决方案, 但事实上这种灾难备份并没有真正灾难备份的能力,因为它的数据并没有被送往远离本地的地方,而数据的恢复也仅是利用本地的记录。

    1.1.2.2 Tier 1

    Tier 1- PTAM 车辆转送方式( Pickup Truck Access Method) 

    作为 Tier 1 的灾难备份方案需要设计一个应急方案,能够备份所需要的信息并将它存储在异地,然后根据灾难备份的具体需求,有选择地建立备份平台, 但事先并不提供数据处理的硬件平台。 

    PTAM 是一种用于许多中心备份的标准方式, 数据在完成写操作之后, 将会被送到远离本地的地方,同时具备有数据恢复的程序。在灾难发生后,一整套系统和应用安装动作需要在一台未启动的计算机上重新完成。 系统和数据将被恢复并重新与网络相连。这种灾难备份方案相对来说成本较低(仅仅需要传输工具的消耗以及存储设备的消耗)。 但同时有难于管理的问题,即很难知道什么样的数据在什么样的地方。一旦系统可以工作,标准的做法是首先恢复关键应用,其余的应用根据需要恢复。这样的情况下,恢复是可能的,但需要一定的时间,同时依赖于什么时候硬件平台能够被提供准备好。

    1.1.2.3 Tier 2

    Tier 2 - PTAM 卡车转送方式+热备份中心 (PTAM+Hot Site) 

    Tier 2 相当于是 Tier 1 再加上具有热备份能力中心的灾难备份。热备份中心拥有足够的硬件和网络设备去支持关键应用的安装需求。对于十分关键的应用,在灾难发生的同时,必须在异地有正运行着的硬件平台提供支持。这种灾难备份的方式依赖于用 PTAM 的方法去将日常数据放在异地存储,当灾难发生的时候,数据再被移动到一个热备份的中心。虽然移动数据到一个热备份中心增加了成本,但却明显降低了灾难备份的时间。

    1.1.2.4 Tier 3

    Tier 3 - 电子传送(Electronic Vaulting)

    Tier 3 是在 Tier 2 的基础上用电子链路取代了车辆进行数据传送的灾难备份。接收方的硬件平台必须与生产中心物理地相分离,在灾难发生后,存储的数据用于灾难备份。由于热备份中心要保持持续运行,因此增加了成本。但确实是消除了运送工具的需要,提高了灾难备份的速度。

    1.1.2.5 Tier 4

    Tier 4 - 活动状态的备份中心 (Active Secondary Site) 

    Tier 4 这种灾难备份要求两个中心同时处于活动状态并管理彼此的备份数据,允许备份行动在任何一个方向发生。 接收方硬件平台必须保证与另一方平台物理地相分离,在这种情况下,工作负载可以在两个中心之间被分担,两个中心之间之间彼此备份。在两个中心之间,彼此的在线关键数据的拷贝不停地相互传送着。在灾难发生时,需要的关键数据通过网络可迅速恢复,通过网络的切换,关键应用的恢复时间也可降低到了小时级。

    1.1.2.6 Tier 5

    Tier 5 - 两中心两阶段确认 (Two-Site Two-Phase Commit) 

    Tier 5 是在 Tier 4 的基础上在镜像状态上管理着被选择的数据 (根据单一 commit 范围,在本地和远程数据库中同时更新着数据),也就是说,在更新请求被认为是满意之前,Tier 5 需要生产中心与备份中心的数据都被更新。我们可以想象这样一种情景,数据在两个中心之间相互映像,由远程 two-phase commit 来同步,因为关键应用使用了双重在线存储,所以在灾难发生时,仅仅传送中的数据被丢失,恢复的时间被降低到了小时级。

    1.1.2.7 Tier 6

    Tier 6 - 零数据丢失 (Zero Data Loss) Tier 6 可以实现零数据丢失率,同时保证数据立即自动地被传输到备份中心。 Tier 6 被认为是灾难备份的最高的级别,在本地和远程的所有数据被更新的同时,利用了双重在线存储和完全的网络切换能力。Tier 6 是灾难备份中最昂贵的方式,也是速度最快的恢复方式,恢复的时间被降低到了分钟级。对于 Tier 6 的灾难备份解决方案,可以应用两种远程拷贝技术来实现,即 PPRC 同步远程拷贝和 XRC 异步远程拷贝。

    因此,企业需要根据其计算机处理系统中数据的重要性,以及需要恢复的速度和程度,来进行灾备系统建设的整体考虑和不同灾难对业务冲击的分析,并最终确定灾备系统建设的总体规划。 

    灾备系统建设的总体规划应包括以下几个方面:

    1.1.3 界定灾备系统的适用范围

    分析不同的应用系统,确定灾备系统是一个覆盖整个计算机系统的工程,根据业务的重要性, 对不同的系统采用不同级别的容灾方案,如针对关键的业务应用子系统,实施高级别的容灾工程;对低级别的业务系统,实施低级别的容灾工程。总之要建立一个综合性的整体灾备建设工程。

    1.1.4 界定灾备建设的目标

    生产系统在单位时间内的数据处理能力或 IO 流量确定的情况下,RPO 实际上成 为一个反映灾备恢复过程中的数据丢失量的指标。而 RTO 则是指从灾难发生到备份系 统可以接管原有生产系统所需要花费的时间,这不仅要考虑数据的恢复时间,还应该考虑恢复后数据的完整性、一致性的修复和确认、备份中心计算机处理系统的启动和备份中心的网络切换等全部时间。总体规划中应为灾备系统设定明确的 RPO 和 RTO 指标。

    但是设计容灾系统不能只看 RTO 和 RPO, 对于不同的业务系统和用户特殊的要求,其它一些指标有可能成为选择容灾解决方案的主要因素。例如,某些地区为了防范一些特定自然灾害的风险,要求容灾备份中心与业务中心保持足够的距离,在这种情况下,容灾备份中心与业务中心的距离要求就是容灾系统的重要指标。

    通信网络是容灾系统的组成部分,通信线路的质量也是容灾系统的性能指标之一,其中包括网络的数据传输带宽、网络传输通道的冗余和网络服务商的服务水平(网络年中断率)。如果容灾系统使用的通信网络是确定的,为了比较不同容灾解决方案, 可以用单位存储容量的数据库在同一通信网络上的数据完全恢复时间作为一项设计指标。

    大部分业务系统都是数据库应用结构,但业务系统容灾并不等于是数据库容灾, 还包括访问数据库的应用程序和相关配置信息。实现数据库容灾是容灾的基础,在保障数据库数据一致的前提下,还要实现应用程序和配置信息的一致性;实现应用系统的高可用性、应用程序在容灾中心与生产中心接管和切回的过程,因此,还要考虑应用的模式是 C/S、B/S,两层、三层、多层次的应用结构等等。

    1.1.5 界定灾备系统的总体架构

    根据实际需求、现有技术、所在地域、计划防范的灾难种类和预算投入的资金量等实际情况,确定灾备系统预期达到的级别,并以此来确定灾备系统与生产运行系统在地理位置上的距离(同城还是异地或两者兼备-堡垒节点),备份数据存储所在的介质(磁盘还是磁带或两者兼备),备份数据在生产中心与备份中心传输的方式( 就涉及到了具体的计算机存储与网络技术),以及备份中心计算机系统的处理能力和网络接管所需的具体架构 (是否与生产中心采用完全同等数量、容量和性能的计算机、存储设备和网络体系结构)。

    第 2 章 主流容灾技术说明

    根据 SHARE 78 评审标准,容灾技术必需涵盖了如下内容:

    2.1 数据备份

    数据备份是系统、数据容灾的基础,也是低端容灾的实现,是高端容灾(实时数 据保护)的有力保障。目前备份技术主要有快照备份、离线备份、异地存储备份。备份系统通过备份策略,对计算机信息系统的操作系统、文件系统、应用程序、数据库系统等数据集,实现某一时间点的完整拷贝,拷贝的数据处在非在线状态,不能被立刻访问,必须通过相应操作,如恢复等方式使用备份数据。这也解决了高端容灾(实时数据保护)不能解决的问题:人为误操作、恶意性操作等,这类操作,计算机系统是不能区分的,一旦执行,将造成数据中心、灾备中心同时修改;对于数据库系统, 在日志方式下,可以通过回滚方式修改,对于文件系统、操作系统等其他配置信息是不能回滚的,将造成毁灭性的结果。因此在建设高端容灾系统的前提,一定要做好本地系统的备份,这是容灾技术的起点。 

    2.2 实时数据保护

    实时数据保护,就是在多块磁盘上、多个阵列、多台服务器、多个数据中心实时的保存同一份数据的多份存储,目的是为了避免物理故障,数据不会因为一块磁盘、 一个阵列、一台服务器、一个数据中心的故障,而不能访问。 

    注意,实时数据保护需要以数据备份作为前提,它不能防范人为误操作和恶性操作。

    这里我们要强调容灾的目的是让数据在灾难发生时,还能被访问,通过实时数据保护,保证数据的完整性;因此实时数据保护是容灾手段,而不是目的。 目前实时数据保护的技术主要有两种:数据镜像和数据复制。

    2.2.1 数据镜像(Mirroring)

    数据镜像(Mirroring)是冗余的一种类型,一个磁盘上的数据在另一个磁盘上存在一个完全相同的副本即为镜像。分软件镜像与硬件镜像,它们的的区别就在于实现镜像所需的 CPU 周期所处的位置。最终,都是根据程序的指令,为硬件(磁盘,以及磁盘上存储的数据)制作一个镜像副本。镜像可以保证两份数据完全一样。镜像软件有 Symantec Volume Manager;各硬件厂商都有基于自己阵列的硬件镜像方式。

    2.2.2 数据复制(Replication)

    数据复制(Replication)是将一个原数据的及其改动,通过后续机制拷贝到另外一处,可以是另一个磁盘、另一个阵列、另一个服务器、另一个数据中心。由于实现的机制不同,又分为同步复制和异步复制两种方式。同步复制,能够确保两份数据 完全一致,但对系统的影响较大,一般不会采用;异步复制,通过后续机制,确保将本地改动的数据复制的异地,对系统的影响较小,但数据同步有延迟,是目前实现远程数据同步的主要方法。 

    根据实现机制,数据复制分为软件方式和硬件方式;硬件方式往往又被称为远程镜像。软件复制有 Symantec Volume Replicator;Datacore 等;其中 Symantec 是基于卷的复制,Datacore 是基于 block 的复制,类似于硬件的复制,纯硬件复制有 HDSTrueCopy、 EMC SRDF 等。 其中软件复制是可以跨硬件平台,可以实现多厂商集成,一般硬件复制则是相同品牌之间的磁盘子系统的操作。具有一定的限制性。

    2.2.2.1 软件复制

    Symantec Volume Replicator(简称 VVR)负责远程数据复制。 VVR 复制基于 Volume 进行。复制的数据可以是数据库中的数据(文件方式或裸设备方式),数据库日志, 复制的数据也可以是各种文件, 如应用和数据库配置文件,应用程序, 库文件, 等等。 复制的示意图见下图。

    VVR 与 VxVM 完全集成在一起。用 VxVM 管理界面和命令统一配置管理;由于 VVR 仅仅将 Volume 上每次 I/O 的实际数据实时复制到远程节点,所以在网络线路上传输的数据量很少,对带宽的需求也很小,因此也与应用无关,只要是在定义的复制卷上的任何操作,都会被复制到异地。 Datacore 则是基于软件的块设备复制, 处于卷的更底层, 属于块设备的远程复制, 与基于卷的复制不同的是,他具有应用操作系统的独立性,数据的远程复制与操作系 统无关,并且不需要远端主机应用系统的运行,支持异步和同步的方式,并且与硬件存储子系统不同的是,Datacore 可以实现异构存储子系统的集中管理,打破了单一厂商选择的限制,对于磁盘子系统的选择更加灵活。其复制示意图如下:

    通过整合原有存储子系统以及新购的存储子系统,将数据的改动记录在 Datacore 的 SDS 设备当中,采用存储转发的传输机制,利用 cache 的技术和 buffer 的技术,记录数据的改变,然后通过传输机制将所有应用的数据传输到对端,该软件支持一对多的远程复制。类似于硬件复制,但是可以不受品牌限制。 

    2.2.2.2 硬件复制

    以 EMC 的 SRDF 为例,如下图: 

    1.系统定期检测磁盘物理数据块的改变状况。

    如果发现有数据块改动,将会被系统记录,并一次性将改动过的数据块考到复制缓存,这一动作被称为 Switch。

    拷贝到缓存中的数据块,在下一个 Switch 来临之前,被复制到异地相应的阵列缓存中。

    在下一个 Switch 时,本地数据块被复制到本地存中,而异地缓存中上一次被改动过的数据块才被复制到容灾系统中。

    根据实应用范围,数据复制分为应用复制、数据库复制、卷复制、控制器复制。 

    应用复制,是指通过应用系统直接向原生产中心和容灾中心同时发交易,生产中心和容灾中心都处理成功,该笔交易才算成功;只要有一边应用处理失败,该笔交易就算失败。由于交易的延迟性较大、健壮性较差,应用复制一般不会考虑。

    2.2.2.3 数据库复制

    数据库复制,如 Oracle 的 Data Guard、Quest SharePlex、DSG RealSync 等, 通过分析数据库 Redo Log 和 Archive Log 实现日志的复制,将分析结果直接或转化为 SQL 语句传到容灾中心,在容灾中通过心 Aply 数据库日志或将日志转化的 SQL 语句重做,来保证数据库数据的一致性。数据库复制实际上是应用复制的数据库实现, 复制方式通过异步完成。 卷复制如上 Symantec Volume Replicator。 控制器复制,如上 EMC 的复制过程。

    2.2.2.4 DatacoreSDS

    实际上还有一种新的复制方式, 称为基于 SAN 网络的卷复制, 如 Datacore 的 SDS。 它是通过特殊的运行于操作系统上的 SDS SAN 控制器,实际是将低端的无智能存储变为高端的智能存储,使得他们得以建立基于智能 SAN 控制器的卷,通过这种与主机应用无关,但与 SDS 控制器直接相关的卷实现复制。 Datacore 是较早的研发厂商,还有 IBM 的 SVC 和 HDS 的 USP 系列也是采用此种技术。

    2.3 应用系统恢复

    正如前所述,数据复制是容灾的手段,不是目的,容灾的目的是数据的访问。因此应用的恢复和以下的网络的恢复也是容灾的关键。 

    应用系统恢复,这和系统的应用模式直接相关。需要考虑应用系统的应用架构。 是 Client/Server 架构,还是 Broswer/Server 架构;是 2 层架构、还是 3 层架构、 还是多层架构。两层架构,表示容灾中心的应用只要启动数据库就可以服务了。如果是三层架构, 就意味着应用系统除数据库以外,还有网络服务程序, 如中间件 Tuxedo、 CICS、WebLogic、WebSphere、9iAS、SAP 等等。在容灾应用切换时,能够手工或自动化的将这些服务一一启动。

    2.4 网络系统恢复

    在灾难发生后,应用切换到灾备中心了,本地的应用前端需要重新访问容灾节点的服务,带来另外一个问题,网络如何切换?是建立新的网络,还是使用动态路由,还是有其它办法?实际上最简单的办法,就是通过外部 DNS 服务器,改变服务器名和 IP 的映射关系,将原服务器名映射到新的 IP 地址上,就可以利用容灾网络,实现前端对容灾中心服务器数据的访问。

    2.5 容灾切换过程

    就是在灾难发生后,数据库切换、应用重新启动、网络实现切换等等,容灾中心接管原生产中心的整个过程;同时还包含了在原数据中心修复后,数据库、应用、网络需要重新切会来的整个过程。这些过程,可以通过手工切换、也可以通过自动化过程完成。

    2.6 消防演习

    大部分的容灾方案,在项目实施后,很难有机会来实现预演,因为对于大部分方案来说,这种预演活动,需要耗费大量的人力财力。

    但是消防预演是必不可少的,它是实时测试目前的容灾方案的漏洞,保证容灾方案在灾难发生时,能够真正生效。

    第 3 章 主流容灾技术分析与对比

    没有一种技术可以解决所有IT 问题,因此,也没有一个解决方案是完美无缺的,依据现状、技术要求、和未来的拓展,我们在此讨论的是最合适容灾技术的解决方案。

    3.1 数据备份

    SHARE 78 评审标准中,Tier 0、Tier 1、Tier2 级别容灾要解决的问题。 

    如前面所阐述的,数据备份是容灾系统的起点,是最低端的容灾方案。不是说有了高端的实时容灾方案,就可以不要备份系统了,因为实时容灾不能解决恶性操作、 误操作等故障,而备份系统可以解决。 

    在此我们要讨论的是,如何利用现有的备份系统,是容灾方案更加完备。备份软件必须具备跨平台能力, 对目前所有的操作系统 AIX、 Solaris、 HP-Unix、 Windows、数据库 Oracle、SQL Server、DB2、SybaseASE 等,备份软件除了要可以很好的备份相关的文件系统数据、数据库系统数据外,同时必须要满足系统的裸机快速恢复功能,减少系统重建时间,可以对 AIX、Solaris、HP-Unix、Windows、Linux 操作系统实现备份,备份这些操作系统的相关补丁、外设驱动程序、相关的文件系统 配置信息、相关的卷配置信息、内核参数等。在灾难修复时,可以通过恢复的方式快速恢复相关操作系统。实际经验,操作系统安装、打补丁,安装相关驱动程序、恢复 内核参数、恢复文件系统配置、恢复卷管理系统配置等整个过程,可以缩短在 1 小时 内完成, 并且降低了人为错误操作过程。 这样大大提高了原生产中心容灾恢复的能力。 

    目前市场上的备份产品,Veritas 是市场占有率最高,功能相对较全的产品,其他备份产品,或没有类似与 BMR 的模块;或是不能支持 AIX、Solaris、HP-Unix、 Windows、Linux 全部操作系统,这些用户可以根据实际情况来选择。 

    备份软件还必须对远程磁带具有管理功能,可以实现对备份数据的自动拷贝,并实现异地存放和管理。-Share 78 中 Tier 1 、Tier 2 级别容灾。

    3.2 实时数据保护

    SHARE 78 评审标准中,Tier 3 级别容灾。

    3.2.1 数据镜像(Mirroring)

    数据镜像分软件镜像与硬件镜像。

    3.2.1.1 硬件镜像

    通过硬件级别的 Raid-1 实现,其实现过程简单,但要求严格。只能基于同一厂商、同一阵列、同样容量大小的两块磁盘来实现。基本上硬件的磁盘子系统供应商都提供能够实现此种功能的设备,但一般价格较高,投入大,并且只能限定在同一厂商品牌。 

    3.2.1.2 软件镜像

    软件镜像可以实现逻辑卷级镜像,对存储空间要求较低,只要有空间且至少两块磁盘就行。不要求同一厂商、同一阵列、同样容量大小的两块磁盘,软件镜像能够实现跨厂商、跨阵列的镜像,在磁盘空间不均时,能够实现 1 块磁盘对多块磁盘、N 块磁盘对 M 块磁盘的镜像。软件镜像的产品有 Symantec 的 Storage foundation,这种软件通常安装在主机上,通过主机的线程对镜像进行控制。 

    3.2.1.3 软件智能存储镜像

    目前新兴的虚拟存储技术,使得让原来非智能的存储可以实现智能化,改变 了原来只有高端存储才具有的智能功能的局面,这种智能的控制器软件可以实现存储间的镜像和存储内部的硬盘镜像,同时,此种软件的可以实现跨厂商的磁盘子系统设备的镜像。 

    3.2.1.4 镜像技术在容灾中的利用

    在通过 SAN 的支持,DWDM 的拓展,光纤网络可以扩展到 100 公里或更远,镜像可以在较远的两个数据中心的磁盘上建立。但由于镜像系统是以同步方式实现的,受到距离、 光纤协议、 和相关协议转换的影响, 同步方式会影响本地服务器的性能, 所以, 一般建议在<20 公里的同城容灾中使用,在远程容灾中可作为一种加强方案与远程容灾方案整合,将在我们的详细方案中描述。

    常说的基于硬件的远程磁盘镜像,实际上是远程磁盘复制,不是真正意义上的镜像。我们将在后续文章描述。

    基于 SAN 的镜像,在容灾实现中,使用范围较小,如上说述,适用于同城容灾, 但支持所有的类型数据同步,包括文件数据、数据库数据、裸设备、应用配置文件、 应用程序、库函数等,因而支持各类应用系统容灾,包括数据库、中间件、客户自己开发的应用,适用于 2 层架构、3 层或多层应用架构。

    3.2.2 数据复制(Replication)

    数据复制是运程容灾实现的基础。

    3.2.2.1 软件复制(卷复制)

    卷复制软件负责远程数据复制。复制基于卷进行,将数据特别是需要进行远程复制的相关文件系统、数据库、裸设备、应用程序等,存放在复制卷组中,系统便能自动同步本地和异地相应的复制卷组。

    卷复制软件与卷管理软件完全集成在一起。由于卷复制软件仅仅将卷上每次 I/O 的操作复制到远程节点,复制的信息是卷的日志,所以在网络线路上传输的数据量很少,对带宽的需求也较小。

    基于卷的日志(SRL:先进先出)保正了再极端情况下,如容灾网络中断、数据复制不能正常进行,容灾中心数据于生产中心数据有延迟,在一切故障排除后,能够严格保证所以 I/O 的写顺序,这类似于数据库数据块和数据库日志的关系,通过带时间戳的数据块和顺序日志,保证数据的一致性。

    基于软件的远程复制,在容灾实现中,使用范围最广,支持所有的类型数据同步,包括文件数据、数据库数据、裸设备、应用配置文件、应用程序、库函数等,支持各类应用系统容灾,包括数据库、中间件、客户自己开发的应用,适用于 2 层架构、3 层或多层应用架构。

    3.2.2.2 硬件复制

    通过基于硬件的远程磁盘镜像实现,其实现要求严格。只能基于同一厂商、同型号阵列、同样容量大小的两个阵列来实现。厂商一般建议使用间歇性复制。

    远程磁盘镜像(复制),在容灾实现中,支持所有的类型数据同步,包括文件数据、数据库数据、裸设备、应用配置文件、应用程序、库函数等,支持各类应用系统容灾,包括数据库、中间件、客户自己开发的应用,适用于 2 层架构、3 层或多层应 用架构。与应用无关,但与磁盘阵列直接相关。只能基于同一厂商、同样容量大小的两个阵列来实现。受光纤线路影响、复制数据量大,在使用间歇性复制时,数据延迟大,磁盘容量要求 4 倍于源数据,并且在极端情况下,不能保证数据一致性。

    硬件复制的过程,在上文已经描述。下面我们将描述极端情况。

    磁盘复制在生产中心和容灾中心复制的是改动过的物理数据块,而物理数据块的写是无序的。为了保证数据的一致性,通过带时间戳的数据块,改善了一定的数据块的无序性,但仍然不能解决。我们看到,数据库是通过带时间戳的数据块和联机日志 一起来解决, 如果一个数据文件中的数据块的时间戳不一致, 数据库需要日志来修正, 日志中记录的是一些有序的数据库操作, 通过 Recover 的动作, 将不一致的数据文件, 前滚或后滚到某一特定时间点。带时间戳的数据文件和有序的日志,二者缺一不可, 否则不能保证数据的一致性。在磁盘复制中,唯独少了至关重要的磁盘写日志(不可能有)。更有甚,如果这种磁盘块的无序写,发生在数据库的联机日志上,那将对数据库数据的一致性造成破坏。

    3.2.2.3 基于软件控制器的复制

    基于软件控制器的复制,打破了基于硬件的复制的单厂商设备的限制,并且具有更大的灵活性,通过建立虚拟磁盘卷的镜像关系,真正可以建立数据的镜像,其与软件复制的不同之处又在于其对应用的无关性,这点又与基于硬件的复制相同。 

    在前面我们提到基于块设备复制的应用无关性,但是也具有对数据库的数据一致 性的问题, 所幸的是这种基于软件控制器的复制可以具有比基于纯硬件复制更多的定制功能,可以对数据库的数据一致性提供支持,其实现的方式是在数据库的运行主机上安装 agent 或者是编写脚本的方式实现,并且脚本与软件控制器相结合,从而保证数据库的数据复制一致性,防止在极端情况下的数据损失。

    我们可以认为基于软件控制器的数据复制是一种介于卷复制和硬件控制器复制之间的数据复制方式。 并且解决了单一硬件厂商平台的限制, 是未来的主流发展方向。 

    3.2.2.4 数据库复制

    数据库复制,如 Oracle 的 Data Guard、Quest SharePlex、DSG RealSync 等, 通过分析数据库 Redo Log 和 Archive Log 实现日志的复制,将分析结果直接或转化为 SQL 语句传到容灾中心,在容灾中通过心 Aply 数据库日志或将日志转化的 SQL 语句重做,来保证容灾中心数据与生产中心数据一致。 

    数据库复制也存在一定的限制,在简单的环境中,实现两个较小的数据库数据同步,可以说是一个简化的解决方案。对于容灾环境,其部分限制如下。 

    数据库复制,是专门针对相应数据库的,只能实现单一的数据库复制。现有的数据库就有 Oracle ,SQL Server,DB2,Sybase ASE。在容灾系统中,如果使用数据库复制方式,管理员将要维护 Oracle 一套、SQL Server 一套、DB2 一套、等相互各不相同的数据库复制技术,管理和维护工作根本不能保证其能够正常运行。 

    下面我们就以 Oracle 为例,虽然有众多厂商、技术方案支持的数据库复制,仍然有不可逾越的技术障碍。 Oracle 数据库的容灾复制被称为 Standby Database, 其产生于 Oracle 7.3,在 Oracle 9i 后,改称为 Data Guard。Standby Database 又分为 Physical Standby, 和 Logical Standby。Physical Standby 方式是将生产中心产生的数据库 redo log 和 archive log,不停复制到容灾中心,不停的 apply log,来实现容灾中心的数据库与生产中心一致。Logical Standby,是通过解析 redo log 和 archive log,产生相关的 SQL 语句,把这些语句传到容灾中心重做。Quest SharePlex 和 DSG 的 Realsync 类似与 Data Guard 的 Logical Stand by,复制 SQL 语句。 

    1.容灾的目的是使数据能够被正常访问, 业务能够正常运行。 数据库复制技术, 不是一个完整的容灾解决方案,只能有限的复制数据库数据,不能复制其他的应用程序, 配置文件, 就是 Oracle 自己的 tnsnames.ora, listner.ora, initSID.ora, *.ctl 也不能复制,一旦这些文件改动过,将需要管员人为操作或者需要其他软件的管理, 保证容灾中心与生产中心同步应用、程序、配置文件同步。 

    2.由于 Data Guard 是通过日志来实现的,这要求数据库必须运行在归档日志模式下。但我们知道,并不是所有的数据库操作都写日志:oracle 的 DML(Data Manipulation Language)或 DDL(Data Dictionary Language)语句是不能被复制的,如 create index、table,alter table 等等;触发器、存储过程操作不能被复制;系统升级、patchs 更新不能被复制。 

    3.与备份软件的冲突。如前所述,对于核心应用系统,数据备份必不可少。对于数据库的备份,也要求数据库在归档模式下运行。备份系统在备份作用发起时,需要备份数据文件、control file、归档日志、甚至需要数据库实现强制归档,来备份 归档日志,备份作业成功后,由备份系统自动删除备份过的归档日志,应为当数据库 运行在归档日志模式下时,归档日志往往因数据库繁忙而快速大量产生,需要备份软件自动清除维护,否则当归档日志空间占满后,联机日志不能归档时,生产数据库不在运作,则所有应用业务不能操作,酿成生产事故。为了不影响生产环境,问题一, 在备份作业发起,强制归档;备份完成后,删除归档日志后,数据库复制软件,该如 何操作, 将严重造成生产中心和容灾中心数据不一致。 如果备份作用不删除归档日志, 系统管理员将不定时的来维护归档目录,他必须知道本地归档目录中,哪一个归档日志已经被备份,通过检查容灾中心数据库中哪一个归档日志已经被 apply,这将是一个恶梦一样的维护工作。 

    4.极限情况下的危害。当生产中心和容灾中心的复制链路一定时期内不能恢复时,同样需要在生产主机中保留所有的归档日志,这又需要管理员大量的维护工作。

    3.3 应用系统恢复

    对于核心的应用环境,在实现容灾前,一般都要求在本地实现高可用性,通过集群软件,保证应用、数据访问在服务器级故障,如网卡、IP、操作系统、磁盘、其他相关应用的故障时, 能够自动切换到另外一台可用的服务器上, 能够被用户继续访问。 容灾应用切换,就是把这种高可用性的应用,拓展到广域网上。

    也就是说通过 HA 软件实现生产中心的高可用、实现容灾中心应用的自动启动、 实现生产中心在灾难修复后应用的回切过程。

    目前主流的高可用方案主要有 Symantec VCS、 IBM HACMP、 HP MC/Service Guard、 Sun Cluster、Windows CCS 等。 

    3.4 网络系统恢复

    在灾难发生后,本地应用访问路径如何由指向原生产中心改为指向容灾中心。在灾难修复后,又需要指向原生产中心。 

    我们提到,最简单的方法就是更改外部 DNS 服务器得 IP 映射关系。在灾难发生前,IP 映射为生产中心服务器;在灾难发生后,IP 由映射为容灾中心得服务器;在灾难修复后,IP 又映射为生产中心得服务器。

    当然,在一些中间件软件中,支持多服务器、多 IP 得配置,那也是可以考虑的。

    第 4 章 容灾系统设计步骤

    如上图,对于容灾系统的建立,我们建议通过分步实施,逐渐建立一套完善的系统容灾解决方案。 

    第一步,深化数据备份系统; 

    第二步,存储、应用整合; 

    第三步,实现远程实时数据保护; 

    第四步,建立远程切换消防演习机制; 

    第五步,建立远程切换机制。

    4.1 第一步,深化数据备份系统

    通过相应的备份软件,对目前所有的计算机系统,做好完善的数据备份,特别是做好操作系统备份、文件系统备份、数据库系统文件备份、数据库数据文件备份、相关的核心应用程序备份;建立好完善的备份/恢复机制和远程磁带保管机制。 这也是下一步实现远程数据复制容灾的基础,容灾中心与生产中心的数据初始化同步,都是通过磁带备份恢复方式,实现一个同步起点。

    4.2 第二步,存储、应用整合

    4.2.1 存储整合

    通过相关的产品选择, 将各服务器的数据、或应用, 通过基于一定的管理及后续, 实现数据的快照、镜像等技术,迁移到外置基于 SAN 的阵列库中,通过唯一的管理接口,实现统一管理,屏蔽不同厂商阵列的差异。

    4.2.2 应用整合

    通过相应的应用集群管理软件,管理所有的应用系统状态。对现有的数据库系统 Oracle、SQL Server、DB2、Sybase、中间件等应用,实现双机、多机或是单机集群管理。操作系统平台相同的,可以整合在一起,实现多机集群,不同的数据库实例, 只是作为一个 “数据库服务组” , 运行在多机或双机中的某一台服务器上,为中间件、 其他应用建立 “应用服务组” , 也纳入到集群软件的管理; 并且动过集权软件建立 “应用服务组” 与 “数据库服务组”或其他 “应用服务组” 的依赖关系, 实现对应用启动、 关闭的有序管理。 

    如果是 Oracle RAC 的应用,则需要集权软件支持,因此在选择集权管理软件时要纳入考虑因素,通过 RAC 的支持使得数据库的 RAC 应用也在集群软件的管理之下。

    4.3 第三步,实现远程实时数据卷保护

    通过第二步的存储和应用整合,使得所有需要容灾的核心系统,全部纳入到一个统一的管理平台之下,我们将规划好应用数据的存放方式、数据文件的存放地点、日志的存放地点,然后统一为这些数据指定一定的存储策略,实现远程数据复制。

    4.4 第四步,建立远程切换消防演习机制

    在数据库复制初始化完成,相关应用复制完成,就可以实现相关应用的消防演习了。这是保证容灾系统正常唯一的、最有效的手段,整个过程生产中心应用在线。 

    对数据库实现快照; 

    启动数据库; 

    启动相关的应用; 

    通过压力程序或测试程序验证应用。

    4.5 第五步,建立远程切换机制

    确定外部 DNS 服务器对本地服务器与容灾中心服务器 IP 地址的对应关系,确定 GCO 对 DNS 更新的内容。

    第 5 章 数据容灾的性能分析

    5.1 同步数据容灾的性能分析

    利用同步传输方式建立异地数据容灾,可以保证在本地系统出现灾难时,异地存在一份与本地数据完全一致的数据备份。但利用同步传输方式建立这样一个系统,必须考虑“性能”这个因素。 

    采用同步数据传输方式时,从前面的描述来看,本地系统必须等到数据成功的写到异地系统,才能进行下一个 I/O 操作。一个 I/O 通过远程链路写到异地系统,涉及到 3 个技术参数:带宽、距离和中间设备及协议转换的时延。

    5.1.1 带宽

    本地 I/O 的带宽是 100MB/秒,在 I/O 流量很大的情况下,如果与远程的 I/O 带宽 相对“100MB/秒 == 800Mbit/秒”窄得多的话,如 E1:2Mbit/秒;E3:45Mbit/秒, 将会明显拖慢生产系统的 I/O,从而影响系统性能。

    5.1.2 距离

    光和电波在线路上传输的速度是 30 万公里/秒,当距离很长时,这种线路上的延时将会变得很明显。例如:一个异地容灾系统的距离是 1000KM,其数据库写盘的数据块大小是 10KB(一次 I/O 的数据量),那么:

    本地 I/O 时(100 米距离内) :

    此数字远远超过光纤通道带宽本身,也就是说,光电在 100 米距离的线路上的延时对性能的影响可以忽略不计。 

    异地 I/O 的(1000 公里) :

    此数据表明,在 1000 公里距离上,允许的最大 I/O 量在不存在带宽限制时,已经远远低于本地 I/O 的能力。 

    (注:上面分析还未考虑中间设备及协议转换的延时) 。

    5.1.3 中间链路设备和协议转换的时延

    中间链路设备和协议转换的方式的不同,时延不同,对性能的影响也不同。在对性能影响的分析中,这个因数也应计算在内。目前不同异地数据复制技术所依赖的介质和协议不同,我们将介质、协议和大概时延例表如下,这里提供的数据只精确到数量级,仅供参考,实际数据应该像设备供应上索取。

    下面是一个线路时延分析对照表,供参考。

    在 1000 公里和 100 公里距离上,采用租用线路和 ATM,允许的最大 I/O 能力 (假定带宽足够,数据块大小以 10KB 为例) :

    在 10 公里距离上, 采用各种传输协议允许的最大 I/O 能力, 数据块大小以 10KB 为例(假定带宽足够) :

    5.2 异步数据容灾的性能分析

    从前面的分析来看, 同步数据容灾一般只能在较短距离内部署 (10KM-100KM) ,大于这个距离,就没有实际应用价值了。因为即使在 1000KM 距离上,4.5MB 的速率足够将数据复制到异地,每个 I/O 的响应时间也会超过 10ms,这种响应速度太慢。 

    异步数据容灾主要是针对“线路带宽和距离能保证完成数据复制过程,同时,希望异地数据复制不影响生产系统的性能” 这样的要求下提出来的。 考虑异步数据容灾, 应该注意到以下几个技术条件和事实。 

    1. 带宽必须能保证将本地生产数据基本上完全复制到异地容灾端,还要考虑距离对传输能力的影响。

    按照前面的估算:在 1000 公里范围内,一条带宽足够的线路能支持的 I/O 流量最大为(数据块大小 10KM ) :1.4MB×3600 秒×24 小时=120GB/天

    2. 异地容灾端数据虽然落后,但必须保证该数据库内在的数据完整性(一致性)、 可用性,否则,这种数据复制就没有应用价值了。 

    3. 异地容灾端数据会比本地生产端数据落后一定时间 ,这个时间随采用的技术, 带宽、距离、数据流特点的不同而不同。 

    4. 异步容灾基本不影响本地系统性能。

    与同步传输方式相比,异步传输方式对带宽和距离的要求低很多,它只要求在某个时间段内能将数据全部复制到异地即可,同时异步传输方式也不会明显影响应用系 统的性能。其缺点是在本地生产数据发生灾难时,异地系统上的数据可能是几分钟以前的数据,即最近几分钟内的交易会丢失。(注:一个经过仔细计算和规划的系统, 才能保证其数据丢失只有几分钟。 ) 

    通过异步传输模式进行异地数据复制的技术,包括: 

    1. 基于主机逻辑卷的数据复制方式 

    2. 基于磁盘系统 I/O 控制器的数据复制方式 

    3. 基于软件控制器的数据复制方式

    基于主机逻辑卷(Volume) ,由于采用 Log 技术作技术保障的数据复制方式,其数据具有较高的完整性保障,而基于磁盘系统 I/O 控制器的数据复制方式,不能满足前面提到的技术条件二,也即不能保证异地容灾端数据(库)的完整性,所以,这种方式对于基于数据库的应用具有一定的局限性。 基于软件控制器的复制由于采用了脚本和控制器的联动,可以支持数据库的文件的一致,但是必须调动脚本的运行时间, 在两个脚本运行时间之间的数据会存在不一致的可能性。

    资料免费送(点击链接下载)

    史上最全,数据中心机房标准及规范汇总(下载)

    数据中心运维管理 | 资料汇总(2017.7.2版本)                                                    

    加入运维管理VIP群(点击链接查看)

    《数据中心运维管理》VIP技术交流群会员招募说明

    扫描以下二维码加入学习群

    展开全文
  • 绍兴市人力资源和社会保障局异地数据容灾系统 项目征求意见 经绍兴市政府采购管理部门批准,绍兴市公共资源交易中心将于近期就绍兴市人力资源和社会保障局异地数据容灾系统项目进行公开采购。现将有关技术需求公布...

     

    项目征求意见
    经绍兴市政府采购管理部门批准,绍兴市公共资源交易中心将于近期就绍兴市人力资源和社会保障局异地数据容灾系统项目进行公开采购。现将有关技术需求公布如下,并征求意见。
    一、征求意见范围:
    1、是否出现限制品牌、型号;
    2、是否出现明显的倾向性意见和特定的性能指标;
    3、影响政府采购“公开、公平、公正”原则的其他情况。
    二、征求意见的回复:
    各供应商及专家提出修改意见和建议的,请于201175日下午17时前(节假日除外)将书面材料密封后送至绍兴市公共资源交易中心政府采购科。同时将书面材料的电子文档发送至以下信箱:ruanhaixiang@126.com。联系电话:0575-88021642    联系人:阮海祥。
    三、合格的修改意见和建议书要求
    1、供应商提出修改意见和建议的,书面材料须加盖单位公章和经法人代表签字确认,是授权代理人签字的,必须出具针对该项目的法人代表授权书及联系电话。
    2、专家提出修改意见和建议的,须出具本人与该项目相关专业证书复印件及联系电话。
    3、各供应商及专家提出修改意见和建议内容必须是真实的,并附相关依据,如发现存在提供虚假材料或恶意扰乱政府采购正常秩序的,一经查实将提请有关政府采购管理机构,列入不良行为记录。
    四、拟采购项目货物清单及技术要求:
    1.存储虚拟化设备一台

    产品类别(参考品牌)
    指标项
    技术规格要求
    HDSIBM、华为赛门铁克
    产品要求
    OEM产品拥有自主知识产权;
    提供该产品的自主创新认定证书的复印件;
    基于网络层的虚拟化容灾设备;
    体系架构
    采用2节点集群架构,每节点配置不小于2路2.0GHz 4核处理器,任意一节点故障时,另一节点可自动接管其业务;
    配置接口
    4Gb/s FC接口≥8个,1Gb/s iSCSI接口≥4个;
    4Gb/s FC最大接口数量接口≥24个;
    最大LUN数量
    ≥2048
    缓存配置
    配置Cache容量≥16GB
    虚拟化容量
    最大可支持的虚拟化容量可达到2048TB
    虚拟化特性
    支持将不同型号,不同厂家的存储整合成一个存储资源池,实现存储空间的统一管理和分配;
    将本次投标新增存储设备与社保原有两台存储设备实现虚拟化镜像,保证存储设备端的高可用性,任意一台存储设备故障不影响业务的正常运行。
    支持EMC、HP、HDS、IBM、Huawei、SUN等多个厂家的FC或iSCSI阵列;
    快照特性
    支持数据快照功能,对于单卷支持快照数量≥128个;
    支持在不同型号,不同厂家的设备之间实现数据快照;
    支持快照的分离,将快照独立为一个卷;
    支持快照代理功能;
    集群特性
    支持4到8节点集群扩展能力
    复制特性
    支持基于IO级的同步复制软件,实现两台设备之间的远程数据复制;
    复制模式支持同步、异步和周期三种模式;
    Thin Provision特性
    支持存储容量超额划分,节约前期投资。Thin Provision单卷容量≥256TB;
    操作系统支持
    支持Linux、Windows、AIX、HP-UX、Solaris等主流操作系统;
    冗余组件
    电源、风扇、系统盘冗余;
    安装服务
    提供设备初次原厂工程师现场安装验收服务;
    原厂工程师必须提供实现社保机房搬迁业务不中断在线数据迁移服务。
    中标方将×××能,功能测试,测试如不满足要求,将导致废标。
    中标方一周内将提供项目实施方案,实施方案如不满足要求,将导致废标。
    技术支持服务
    设备生产商需在国内设有400技术服务热线。
    产品认证授权
    承诺中标后签订合同时提供原厂商针对该项目授权书;
    承诺中标后签订合同时提供原厂商针对该项目三年质保函,签订合同时无法提供原厂质保函的,按无效投标处理。
     
    2.镜像存储设备 一台

    产品类别(参考品牌)
    指标项
    技术规格要求
    与存储虚拟化设备同一品牌
    产品
    OEM产品拥有自主知识产权;
    提供该产品的自主创新认定证书的复印件;
    ★体系架构
     
    SAN架构(具备FC和IP SAN融合组网能力),Active-Active双控制器架构;控制器数量≥2;64位多核处理芯片;
    配置FC和IP两种主机连接,主机端口数量≥16,且可扩展到32个,其中:
    8Gb FC主机接口≥8个(满配光模块),且1Gb iSCSI主机接口≥8个;
    后端主机通道
    SAS 2.0宽端口硬盘通道, 数量≥4个,且可扩展到16个,或者4Gb FC硬盘通道, 数量≥8个,且可扩展到32个
    IOPS处理能力
    1,000,000 IOPS
    支持主机数量
    1024台主机
    最大LUN数量
    4096 LUN
    RAID支持
    RAID 0,1,3,5,6,10,50; 支持全局热备盘和降级访问;
    Cache容量
    最大缓存容量≥48GB,本次配置24G
    Cache镜像
    两条物理全冗余全双工的镜像通道,实现两个控制器的Cache数据通过相互镜像实现备份
    掉电保护
    与控制器一体化的UPS,保证掉电时Cache数据可安全写入硬盘永久保存,实现无限时断电保护Cache数据的目的
    Cache预读优化技术
    能够智能识别主机读取模式,通过预读机制优化应用性能
    ★硬盘容量
    配置不少于30块600GB 15K RPM FC硬盘
    单框支持≥24个硬盘,最大可支持扩展576块硬盘
    未来硬盘阵列扩充容量,不得额外收取许可费用
    兼容性
    支持SSD/SAS/SATA硬盘混插,且支持SSD/FC/SATA硬盘混插;支持2.5"硬盘且支持3.5"硬盘;不得额外收取配置混插许可费用
    硬盘坏道自动修复
    可对硬盘的坏道进行自动修复,增加硬盘使用寿命
    绿色节能技术
    支持智能硬盘休眠、风扇智能调速、CPU智能调频等绿色节能功能
    智能化硬盘上电
    支持智能化硬盘加电技术,即硬盘缓上电技术,避免大量硬盘同时上电时,引起电流过载,跳闸风险。
    磁盘预拷贝技术
    能够实时智能监控磁盘状态,将疑似故障盘的数据迁移到热备盘上,预防或降低硬盘失效风险
    阵列安全管理软件
    配置基于存储阵列的安全控制管理软件,以保证在SAN环境下,不同主机系统对存储阵列访问的安全性,配置最大支持分区数,不得额外收取许可费用。
    路径冗余软件
    配置路径冗余管理软件,路径冗余管理软件要求具备自主知识产权,以实现主机的多通道访问以及对应用透明的自动故障通道切换功能,确保用户在通道发生故障的情况下,仍可以连续访问信息;配置≥128 server license,且未来增加主机数量,不得额外收取许可费用
    智能SSD Cache
    能够智能识别系统热点数据,并自动复制到在SSD硬盘,以提高系统效率,SSD Cache最大容量≥2400GB
    ★远程复制功能
    配置远程复制功能,存储远程复制软件应具备与主机平台无关性、应用透明性,以充分支持今后主机平台的更换、应用的更换、数据库的更换
    实现与灾备存储的异步远程复制功能。
    软件高级特性
    支持数据快照功能,系统最大支持2048个快照
    支持数据卷复制功能
    中英文管理界面,可通过GUI或CLI设置阵列;
    使用C/S或B/S架构,无需在管理端安装软件,直接可通过Web浏览器管理阵列,可管理客户端数量≥16 server license;
    可管理多台阵列;
    能提供加密和通过安全端口传输,防止数据窃取;
    可×××能统计、告警管理、故障管理等多种功能;
    支持windows、Linux、Solaris、HP-UX、AIX、FreeBSD、MAC OS等主流操作系统;
    ★技术支持服务
    提供设备初次原厂工程师现场安装验收服务;
    原厂工程师必须提供实现社保机房搬迁数据迁移服务。
    中标方×××能,功能测试,测试如不满足要求,将导致废标。
    中标方一周内将提供项目实施方案,实施方案如不满足要求,将导致废标。
     
    产品认证授权
    承诺中标后签订合同时提供原厂商针对该项目授权书;
    承诺中标后签订合同时提供原厂商针对该项目三年质保函,签订合同时无法提供原厂质保函的,按无效投标处理。
    3.灾备存储阵列 一台
    产品类别(品牌)
    指标项
    技术规格要求
    与存储虚拟化设备同一品牌
    产品
    OEM产品拥有自主知识产权;
    提供该产品的自主创新认定证书的复印件;
    ★体系架构
    冗余Active-Activ架构,配置控制器数量≥2;64位多核处理芯片;
    配置FC和IP两种主机连接,主机端口数量≥8,其中:4Gb FC主机接口≥4个,且iSCSI主机接口≥4个。
    支持主机数量
    256台
    最大LUN数量
    512 LUN
    RAID支持
    RAID 0/1/3/5/6/10/50; 支持全局热备盘和降级访问
    Cache容量
    8G
    Cache镜像
    物理全冗余全双工的镜像通道,实现两个控制器的Cache数据通过相互镜像实现备份
    Cache预读优化技术
    能够智能识别主机读取模式,通过预读机制优化应用性能
    ★硬盘容量
    12个2TB 7.2K RPM SATA硬盘,最大可支持扩展96 块硬盘
    磁盘休眠
    支持按RAID组的磁盘休眠
    硬盘坏道自动修复
    可对硬盘的坏道进行自动修复,增加硬盘使用寿命
    智能化硬盘上电
    支持智能化硬盘加电技术,即硬盘缓上电技术,避免大量硬盘同时上电时,引起电流过载,跳闸风险。
    磁盘预拷贝技术
    能够实时智能监控磁盘状态,将疑似故障盘的数据迁移到热备盘上,预防或降低硬盘失效风险
    多路径冗余软件
    配置无限制的服务器多路径冗余软件License,不少于120台,路径冗余管理软件要求具备自主知识产权
    ★远程复制功能
    配置远程复制功能,存储远程复制软件应具备与主机平台无关性、应用透明性,以充分支持今后主机平台的更换、应用的更换、数据库的更换
    实现与主存储设备的异步远程复制功能。
    软件高级特性
    支持数据快照功能
    支持数据卷复制功能
    中文管理界面,可通过GUI或CLI设置阵列;
    可×××能统计、告警管理、故障管理等多种功能;
    支持windows、Linux、Solaris、HP-UX等主流操作系统
    技术支持服务
    提供设备初次原厂工程师现场安装验收服务;
    原厂工程师必须提供实现社保机房搬迁数据迁移服务。
    中标方×××能,功能测试,测试如不满足要求,将导致废标。
    中标方一周内将提供项目实施方案,实施方案如不满足要求,将导致废标。
     
    产品认证授权
    国家强制性产品(3C)认证证书复印件
    承诺中标后签订合同时提供原厂商针对该项目授权书;
    承诺中标后签订合同时提供原厂商针对该项目三年质保函,签订合同时无法提供原厂质保函的,按无效投标处理。
    4.其他辅助设备

    指标项
    技术规格要求
    级联授权
    两台博科24口(全开)与两台博科8口(全开)的级联授权
    一台三层交换机
    参考品牌:思科、H3C、华为
     
    1、售后服务:   
    主要设备原厂提供原厂工程师上门安装实施服务。
    2付款方式:货到安装调试完毕验收合格后10个工作日内付85%,设备正常运行1个月后付10%,半年之后支付5%(不计息)。
    3、安装到货期:
    合同签订后10个工作日内到货并开始安装调试。
    评标办法及标准
    1.评分方法
    本次评标采用综合评分法,即在最大限度满足招标文件实质性要求前提下,由评标委员会对各投标人报价、投标设备技术参数与功能配置、品牌、市场占有率、售后服务承诺、评委印象等方面进行综合评审。经各评委独立打分,按总得分从高到低顺序推荐确定中标候选人。
    开标后,评标委员会首先对各投标人递交的投标文件进行符合性审查,凡招标文件对投标人相关资格要求和投标文件实质性内容严重不符合有关规定或不响应招标文件要求者,由评标委员会认定作为无效投标予以废除。对投标文件中的疑问,由评标委员会对投标供应商进行询标,投标供应商做出的书面答复作为投标文件的补充,但不得对投标文件的实质性内容进行修改。
    2.评分标准:100分,其中技术分60分,商务分40分。评分依下述所列为评标打分依据,分值如下(评标小组成员为五人以上,评分计算技术分时,去掉一个最高分,去掉一个最低分,平均值保留小数2位):
    2.1技术分60分

    序号
    项目
    评分内容和标准
    分值
    1
    技术参数配置
    30分)
    基本技术参数配置分:完全满足标文技术参数配置要求得基本分30分,含为必须项,如有负偏离,则技术参数配置得分为0分,含的为主要功能指标,如负偏离则每项扣4分,其它一般性能指标负偏离的每有一项扣2分,最多扣分不超过30分。
    30
    2
    产品成熟度及市场占有率
    2分)
    根据投标的设备技术先进性、品牌形象进行评价, 并进行打分,很好2分,较好1分,一般0.5分,由专家酌情打分。
    2
    3
    投标公司技术实力(18分)
    拥有省级以上高新技术企业或科技型企业资格的得2分;有CCNA或者CCDA认证工程师资格的,每一个认证得2分,最多不超过4分;具有国家信息安全部门颁发的CISP安全服务工程师证书的每一个认证得2分,最多不超过4分; 投标产品原厂认证工程师证书每证得2分, 最多不超过4分(标书中提供所有证书复印件,原件随带备查,认证工程师需提供社保关系证明如有弄虚作假,技术标零分处理);有2008年后200万元以上类容灾案例的合同每个得1分,最高不超过2分;投标公司具有机房搬迁数据迁移案例的每个得1分,最高不超过2分;
    18
    3
    项目实施方案
    (4)
    工程管理和组织到位,工程计划科学合理,符合招标文件的时间安排,很好2分,较好1分,一般0.5分,由专家酌情打分。
    2
    项目由原厂商工程师实施,提供原厂备件,由专家酌情打分。
    2
    4
    服务和培训
    4分)
    是否提供合理、科学、完整的培训计划、培训内容和培训人数,培训是否由原厂商工程师完成。很好2分,较好1分,一般0.5分,由专家酌情打分。
    2
    提供本地化服务,非本地企业需提供本地办事处服务机构营业执照的注册证明,注册地在绍兴的得2分,浙江省内的得1分,浙江省外的得0分
    2
    5
    投标文件质量(2分)
    投标文件的编写质量,内容完整性、准确性、可检索性和简洁程度,投标文件不应以大量与本项目要求无关的内容充数,由专家酌情打分。很好2分,较好1分,一般0.5分
    2
     
    2.2商务分40分即投标报价40分:
    2.2.1评标基准价:即满足招标文件要求且投标价格最低的投标报价为评标基准价,其价格分为满分。
    2.2.2其他投标人的价格分统一按照下列公式计算:
    投标报价得分=(评标基准价/投标报价)×价格权值×100
    投标报价超过上限价的,投标报价作零分处理。
    注:如投标文件未按规定制作、填写密封封装的技术总分评标委员会将酌情予以15分的扣分
     
    五、投标供应商的资格要求
    1、符合政府采购法第二十二条之供应商资格规定,注册资金200万(含)以上。
    2、具备本中心政府采购供应商会员资格。
    3、投标公司必须具备系统集成三级(或以上)资质;
    4、多家具有投标资质的关联企业只接受其中一家参加招投标活动。
     
     
    绍兴市公共资源交易中心
    2011年7月1 日
     

    转载于:https://blog.51cto.com/64239/600524

    展开全文
  • 扬州市住房公积金管理中心业务系统须进行升级,为满足业务系统运行需要,需建设应用支撑平台及容灾系统系统。配置及性能要求:(1) 投标人必须对以下所有招标参数要求逐项编写《技术规格偏离表》,没有按照要求编写...

    扬州市住房公积金管理中心业务系统须进行升级,为满足业务系统运行需要,需建设应用支撑平台及容灾系统系统。

    配置及性能要求:

    (1)       投标人必须对以下所有招标参数要求逐项编写《技术规格偏离表》,没有按照要求编写技术规格偏离表的,缺项或漏项的,不进入实质性评标。

    (2)       以下加★项必须完全符合招标参数要求,否则不进入实质性评标。

    1.业务数据库主服务器2台

    序号

    指标

    指标项

    指标要求

    基本要求

    1

    总体要求

    应用类别

    数据库服务器及应用服务器

    ★型号

    UNIX服务器,且必须为货物生产原厂商的高端企业级小型机产品

    ★类别

    机架式服务器

    2

    处理器

    ★架构及字长

    RISC或者EPIA架构;

    64bit,UNIX,必需支持多线程技术,至少要使用到双核技术

    ★主频以及配置CPU个数

    CPU主频 ≥2.5GHz ,主频高的优先考虑;

    当前配置CPU≥2,CPU核数≥16

    当前配置CPU主频*内核总数*每核线程数520

    ★可扩展CPU核数

    ≥20

    ★高速缓存

    1.每个处理器核心配置:

    二级缓存≥512KB/核心

    三级缓存≥4MB/核心

    配置有四级缓存的优先考虑

    2.最大支持CPU总缓存数≥192MB;

    SPECint_rate2006

    实配SPECint_rate2006值≥1310

    实配置和满配置SPECint_rate2006值必须以www.spec.org官方网站发布值为准。

    如投标机型的SPECint_rate2006值没有官方网站公开发布的实测值,则应以投标机型或与投标机型相当的机型在SPEC官方公开发布值为基础,按照CPU主频和数量进行线性推算,并提供SPEC组织网站上截图,并且不接受任何其他推算方法。

    投标方必须按照本办法给出推导过程和计算结果,以下是SPECint_rate2006的线性推算方法:

    基础值=测试机器的数值÷测试时的CPU个数÷测试机器的主频

    投标机器的SPECint_rate2006的线性推算值=基础值x 投标机器配置的CPU数 x 投标机器的主频。

    3

    内存

    种类

    DDR3内存,采用RDIMM技术

    ★配置容量

    实配内存容量≥128GB;

    最大内存带宽

    ≥384GB/s

    ★最大内存扩展能力

    ≥1TB

    4

    系统硬盘

    数量

    ≥2块600G15k SAS硬盘

    可扩展能力

    服务器内部可配置的最大硬盘数量≥12;支持SSD盘,支持服务器内部硬盘热点数据自动分层技术的优先考虑。

    硬盘规格

    SAS:146GB/300GB/600GB/1.2TB;

    SSD:387GB/775GB

    容错

    支持操作系统镜像,实现数据保护

    5

    DVD-RAM光驱

    数量

    1

    6

    ★PCI插槽

    配置数量

    ≥9个PCIe3插槽

    热插拔能力

    支持PCIe卡热插拔

    8

    网卡显卡

    接口类型与数量

    2块双口10Gb光口网卡,1块4口千兆网卡

    接口类型与数量

    1块显卡

    9

    光纤通道卡

    接口类型

    独立8 Gb光纤通道双口卡

    接口数量

    ≥2块

    10

    ★操作系统

    全64位UNIX操作系统

    支持国家中文标准GB-18030

    有字符菜单及图形系统管理工具,免除复杂命令的记忆

    自带卷管理功能,实现操作系统的磁盘镜像。

    无限用户使用许可

    支持IPV6网络协议

    支持C2安全标准

    支持JAVA开发环境

    支持Oracle、DB2等数据库,要求提供数据库厂商原厂官方链接证明

    能直接从系统备份磁带启动机器并恢复操作

    11

    分区

    支持4个硬件分区或逻辑分区(如 HP nPar、IBM DLPAR、sun Ldomain等), CPU、内存、IO等资源可以在各个分区之间在线调配。分区之间系统资源能在不需要停机的情形下,动态调整包括处理器能力、内存容量、I/O插槽等系统资源。

    12

    ★管理软件

    提供系统管理软件、可对进程、线程进行管理;提供分区管理软件,实现对分区资源进行自由调整和监控功能

    可靠性要求

    1

    冗余部件

    N+1冗余电源,N+1冗余风扇

    热拔插磁盘和I/O插槽

    2

    ★其它

    配置用于分区资源管理的软硬件设备

    配置小型机专用机柜及套件一套,要求与主机同一品牌

    配置一套8端口KVM管理系统,要求:17寸LCD、键盘(含小数字键)、触摸式鼠标。含8口 USB 接口主板,一体化抽拉式操作台,机架式安装,1U高度。

    售后服务要求

    1

    ★原厂授权和售后服务

    3年原厂售后服务,服务级别7x24,要求出具原厂盖章的针对本项目的授权函和服务承诺函

    2

    兼容性要求

    要求原厂有稳定的产品路线,实现二进制兼容

     

    指标项

    指标要求

    设备类型

    企业级磁盘阵列

    ★控制器

    配置双控制器,可升级到8个控制器

    ★缓存

    当前配置缓存≥64GB ,可升级到512GB

    Cache保护

    支持双Cache互为镜像技术,支持Cache断电数据保护

    ★主机接口

    配置8个8Gb FC主机接口和6个1G iSCSI主机接口(标配?)

    支持磁盘类型

    支持6Gb/12Gb SAS接口硬盘,支持固态盘,支持各类磁盘混插

    ★支持磁盘数量

    最大支持磁盘数量≥ 1050

    ★配置磁盘容量

    配置24块600GB 15k 2.5寸SAS硬盘

    ★存储虚拟化

    支持外部存储虚拟化功能,可通过外接不同种类和品牌的磁盘阵列,实现一个集中化、虚拟化的磁盘存储池,可支持HP, IBM, SUN, EMC, HDS, Netapp,HUAWEI等主流存储厂商

    数据快照软件

    支持在同一磁盘系统内和跨不同的磁盘系统瞬间复制(时间点快照)

    瘦供给功能

    配置瘦供给(Thin Provision)功能

    自动化数据分层能力

    配置自动化数据分层存储功能,能够自动分析和寻找热点数据,并自动将热点数据迁移到固态盘

    数据压缩功能

    支持和在线数据压缩功能,能够对数据进行在线实时数据压缩,在相同的物理磁盘空间内存储多达五倍的活动原始数据。

    ★数据迁移

    支持透明的、不影响应用运行的数据在不同存储设备和同一存储设备上的迁移;提供并详细描述关于用户原有数据迁移到新磁盘阵列的迁移方案

    ★高级远程复制技术

    支持远程数据镜像或拷贝功能,可支持以下三种模式:

    数据远程同步镜像;数据远程异步拷贝;

    数据远程异步镜像,保证写操作的顺序和数据一致性

    ★服务

    要求与小型机同一品牌,提供原厂三年7*24服务。

    2、数据存储 1套

     

     

    3、虚拟化应用服务器   4台

     

    指标项

    技术参数要求

    机箱形态

    ★2U设备, 设备面板支持硬件内部风扇、内存状态显示;4个千兆电口;独立管理千兆端口,可以实现虚拟介质、远程控制台、虚拟KVM功能、支持集成系统软件及驱动在主板上,无需启动光盘即可直接部署安装服务器;

    处理器

    ★配置2颗处理器E5-2680 V3 2.5GHz/12核/30MB/120W及以上的CPU

    内存

    ★配置8根16GB DDR4-2133P内存。要求:支持RDIMM,LRDIMM类型的内存。最大可扩展内存≥768GB,大于24个DIMM内存插槽

    I/O插槽

    ★配置至少6个PCIe3.0插槽。要求:可以支持扩展到≥6个网卡;支持扩展CNA网卡、HBA网卡、万兆以太网卡

    网卡

    配置4端口千兆电口;2端口8Gb HBA卡,2个FC模块。

    硬盘

    配置4块600GB 12G SAS 转速15K rpm SFF(2.5-inch) 硬盘,硬盘托架支持状态显示,防止读写数据中错误拔出硬盘,最大支持硬盘数≥8

    阵列控制器

    配置2GB非易失性阵列缓存和大电容方案,掉电瞬间,RAID卡内存信息写到flash,提供永久保护;实配支持RAID0/1/5/10/50/6/60

    最大支持4 GB缓存,支持Dynamic Smart技术:备盘预先激活、ADM、逻辑盘高级迁移、阵列修复、在线分割

    硬件集成管理

    ★要求:硬件集成1个独立管理GE端口,实现虚拟介质、远程控制台、虚拟KVM功能、支持集成系统软件及驱动在主板上,无需启动光盘即可直接部署安装服务器;必须支持同时多人进行远程控制,以协同工作,无需另配远程控制卡。支持系统的在线升级,业务不中断。以上服务器管理必须是无代理方式的,无需在OS下安装代理软件,以免对服务器产生影响

    风扇

    配置6个风扇

    光驱

    配置1个内置光驱。

    机柜导轨

    配置机架导轨

    电源

    配置2个电源模块。要求:支持1+1通用接口热插拔高效电源模块。电源功率≤800W。

    配置要求

    ★为保证系统的稳定性,必须与虚拟化软件同一品牌。

    ★资质证书

    投标产品供应商需具备科学、系统的知识产权管理体系。能够全面保护、并系统管理知识产权,支撑企业的技术创新能力。投标产品供应商必需通过知识产权管理体系认证,提供知识产权管理体系认证证书;

    为保障产品代码质量,生产厂商国内研发机构需通过CMMI4认证,提供证书复印件并加盖生产厂商鲜章,其证书必须能在官方网站查询

    授权和服务

    ★提供三年原厂7*24现场保修服务;提供生产厂商盖章的授权书和服务承诺函;

     

    4、虚拟化应用软件 1套

    功能及技术指标

    参数要求

    ★虚拟化架构

    虚拟化软件非OEM或贴牌产品;采用裸金属架构

    虚拟化软件支持CPU硬件虚拟化技术,如Intel VT和AMD-V技术,虚拟机可在Intel和AMD CPU间进行迁移

    不仅支持有Intel VT/AMD-V  processors技术的服务器, 而且支持没有Intel VT/AMD-V processors技术的服务器

    提供基于B/S架构的WEB管理平台统一管理

    ★虚拟化管理

    支持完整的虚拟机生命周期管理,提供虚拟机的创建、启动、暂停、恢复、休眠、重启、关闭、关闭电源、修改、删除、查询等功能,提供完整界面的截图

    支持批量修改虚拟机的配置参数,包括:I/O优先级、启动优先级、是否自动迁移、CPU调度优先级、CPU个数、内存大小、自动启动、VM启动设备、启用VNC代理等,提供完整界面的截图

    支持主机维护模式,将需要停机的物理主机上运行的所有虚拟机迁移至另外的物理主机中,然后关闭待修复的主机,确保计划内停机不会导致任何的业务中断

    支持虚拟机的在线迁移功能

    提供P2V/V2V在线迁移工具

    提供日志文件一键收集功能,收集日志文件时能够选择收集的时间范围,同时可以限制收集的日志文件大小,提供完整界面的截图

    支持自动定时快照功能,定时将虚拟机当前的内存数据状态保存到镜像文件中,提供完整界面的截图

    支持虚拟共享存储,能够将管理服务器或虚拟化节点的本地磁盘做成共享存储,提供完整界面截图

    虚拟网络管理

    支持虚拟交换机并提供虚拟机带宽限制、网络流量限制等功能

    虚拟机的虚拟网卡支持划分VLAN;通过虚拟交换机对虚拟机进行二层VLAN隔离来提升虚拟机的安全性

    虚拟交换机支持802.1Qbg标准,支持VEB、VEPA、多通道转发模式,在官方网站可查

    虚拟化软件允许物理接入交换机监控到物理服务器上所有虚拟机的所有流量信息,并允许物理接入交换机配置相应的网络策略以对虚拟机进行管理

    虚拟机迁移至位于不同物理接入交换机上的物理服务器后,部署在源物理接入交换机上的所有网络配置策略能够自动随之迁移,并快速生效

    ★支持802.1Qbg虚拟网络拓扑展示,包括物理主机、虚拟机、虚拟网卡、虚拟连接、物理端口与物理接入交换机的全面网络连接关系拓扑展示,提供完整界面的截图

    ★支持虚拟机的ACL访问控制,包括三层ACL和四层ACL,提供完整界面的截图

    资源动态扩展

    ★能够根据虚拟机CPU、内存等参数的利用率动态的克隆虚拟机或删除虚拟机以满足“业务量大时使用多个虚拟机提供服务、业务量少时使用少量虚拟机提供服务”的业务需求,整个过程不需要人工干预,提供完整界面的截图

    ★产品资质

    提供×××出具的软件著作权证书复印件

    投标产品供应商需具备科学、系统的知识产权管理体系。能够全面保护、并系统管理知识产权,支撑企业的技术创新能力。投标产品供应商必需通过知识产权管理体系认证,提供知识产权管理体系认证证书;

    提供第三方权威机构出具的云服务迁入迁出测试报告

    软件产品厂商要求提交以原厂身份参加SPECvirt_sc2103的测试结果,并提供SPEC官网截图证明文件

    厂商软件开发必须通过CMMI4级国内认证,要求CMMI官方可查询并提供网站截图

    ★配置及服务等要求

    虚拟化平台配置8个CPU授权许可,要求必须提供原厂商针对本次项目的授权书,并且最终用户名为“扬州市住房公积金管理中心”。  为保证系统的良好兼容性、稳定性和统一的售后服务,虚拟化软件要求与应用服务服务器同一品牌。为提供更好的项目交互,提供原厂部署服务和原厂3年7X24小时技术支持服务,需出具原厂商针对本次项目的服务承诺函,最终用户名为“扬州市住房公积金管理中心”。

     

    5、光纤交换机 2台

    指标项目

    指标要求

    机型

    24口SAN光纤交换机,要求24端口激活

    ★端口速率

    支持8 Gbit/sec(全双工);4 Gbit/sec、2 Gbit/sec端口速度自适应

    端口支持

    配置24个短波SFP 8Gb LC接口模块,24根10M光纤跳线

    授权

    Web tools、Zonging、EGM软件授权

    ★服务及其它要求

    提供三年原厂7*24保修服务;

     

    6、运维审计平台  1套

    功能项

    指标要求

    硬件性能参数

    1U机架式结构型4个10/100/1000BASE-T电口采集口,1个可插拔扩展插槽,单电源,500G硬盘;50个主机/设备许可。

    系统架构

    WEB方式管理,对常见的资源访问方式提供代填登录。

    提供4A管理平台的认证接口,支持active-stanby方式的HA部署

    支持集群部署。

    基础功能

    提供运维审计系统自身状态的监控功能。支持管理配置的批量功能。

    支持WEB方式升级。

    帐号管理

    帐号的整个生命周期管理,对主帐号进行增加、修改、删除及锁定、解锁等操作。

    能够对各种资源上的帐号进行推、拉、同步。

    账号可以添加时间策略、地址策略、命令策略进行细粒度的权限控制。

    认证管理

    支持证书认证、运维审计系统本身可以提供证书认证、并可以和现有的其他证书认证结合:如生物特征认证,OTP认证、AD域、MAC地址、智能卡等

    授权管理

    可以将资源和资源的从帐号授权给主帐号。授权给主帐号的资源可以新增和删除。授权时可以按照树形组显示资源,方便资源的选择。

    授权分为运维审计系统管理功能授权和资源访问授权。内部管理功能授权可以限制到某个树形节点的范围内。

    审计及报表

    审计结果支持按照如下关键字进行查询:主帐号名称、资源名称、资源IP、从帐号名称、起始时间、终止时间、命令关键字。

    支持对象变更操作报表功能,变更操作包括但不限于自然人变更、资源变更、从账号变更、角色变更、授权关系变更等。报表可按照时间段、操作等条件生成与排序,且可以Word、Pdf等格式导出。

    单点登录

    主帐号WEB方式登录运维审计系统后,可以展现所有已经授权给自己的资源,包括字符型和图形的授权资源。

    ★SSO单点登陆,采用一次性会话号机制,提高安全性。(提供截图加盖原厂公章)

    单点登录后,支持目标资源的地址提示,方便同时开启多个目标资源的连接窗口时区分出不同的连接对象。

    支持对SSH、TELNET、RDP等协议的实时会话监视和阻断功能。

    批量管理

    支持批量录入和配置自然人信息;

    支持批量录入和配置资源信息;

    支持批量的录入和修改资源从账号信息;

    对外接口

    可以将审计日志以SYSLOG方式外发,支持SYSLOG发送的目标和端口。

    对所有审计日志提供外发接口,可以配置只外发字符审计,也可以配置外发所有审计(将字符和图形录像的审计日志外发其他设备),并且可以配置对端端口。

    支持认证接口,可以配置认证服务器地址和端口。

    专业功能

    目录树结构无线扩展,易于资源分类和定位检索。

    ★内置×××模块,可以实现外网专线连接运维审计系统。(提供截图加盖原厂公章)

    ★Windows文件夹共享,资源文件夹共享后,可以授权给主机主账号。

    支持磁盘映射,便于终端与服务器之间的文件交互。

    ★双人共管模式,实现重要服务器两个人确定,方可访问资源,同时,第二方人员可以实时监控和阻断操作。(提供截图加盖原厂公章)

    自身安全性

    产品自身不允许开放Telnet(23)、FTP(21)等高危服务端口

    应支持设定密码登录错误次数。当重复登录错误达到设定次数后,系统将锁定账号

    系统具有自身审计功能,能记录所有管理账户的登录、操作、退出等行为,且不可删除

    系统扩展

    要求支持与邮件服务器的联动,可以将告警信息以邮件形式发送。

    要求支持与外接存储设备联动,可直接将审计信息直接存储到外接存储设备上,至少支持Linux和W indows两种类型的外接存储服务器。

    要求支持4A扩展,可以将审计日志输出到4A平台。

    要求支持与SOC联动,可以将审计日志输出到SOC平台。

    ★资质要求

    具备公安部颁发的《计算机信息系统安全专用产品销售许可证》

    具备保密局颁发的《涉密信息系统产品检测证书》

    具备×××颁发的《计算机软件著作权登记证书》

    具备中国国家信息安全产品认证证书(CCC证书)

    要求厂方通过TL9000认证

    要求产品厂商为国家级网络安全应急服务支撑单位

    ★服务及其他要求

    三年原厂商服务,原厂工程师上门安装服务,必须提供设备厂商出具的正式授权书和原厂质保函(加盖原厂公章)

     

    7容灾系统系统建设

    扬州市住房公积金管理中心小型机、数据库等系统更新换代后,为保护数据,保证业务连续性,本着经济,高效的原则,在充分利用现有旧硬件资源的基础之上,进行异地容灾系统建设。

    容灾系统部分招标各项要求如下: (★为必须满足项,否则做废标处理。)

    ★(1)在中心机房和仪征分中心机房之间的小型机设备上搭建一套容灾系统,当中心机房生产系统出现小型机等系统宕机等异常情况后,远程容灾系统(仪征分中心)能够在20分钟内接管中心机房生产系统的业务,提供网络、主机和数据库服务;同时,须及时采取措施使生产系统恢复正常(2小时现场响应,4小时内恢复使用,8小时内完全修复,否则甲方将自行采取必要的措施,由此产生的风险和费用应由投标人承担)。容灾系统系统与生产系统数据保持动态一致,数据延迟不能超过5分钟;容灾系统系统具备同步和异步方式,时间延迟可动态调整。

    ★(2)作为生产系统的辅助系统,容灾系统系统对生产系统主机的负荷不能有明显影响,资源占用(CPU、内存、I/O、网络等)平均不能超过5%,始终保持生产系统的高效稳定运行。

    (3)重新安装原小型机上的操作系统至最新版本和双机软件,重新安装Oracle数据库。

    ★(4)投标人在投标前,须到用户现场进行详细调研,充分了解用户应用环境,现有系统设备、网络和应用软件及其它系统状况,制定最切合用户实际的灾备方案,进行灾备系统详细设计,并制定实施方案,投标时必须提交完整的设计方案和实施方案。

    ★(5)投标人必须根据用户的实际需求情况制订详细的灾难恢复计划,若中标,在新旧系统切换完成后,一周内搭建完成容灾系统系统,达到以上要求的技术性能指标,并按灾难恢复计划进行第一次灾难恢复演练,确保一次成功;若不能实现,取消中标资格。

    ★(6)本项目为交钥匙工程,投标报价须包含容灾系统系统建设及运维所需的各种设备、软件及材料,用户不再单独另外支付任何费用,且必须保证所提供的产品与现有产品及系统稳定、可靠对接,完全达到有效互联互通。若需要使用第三方软件,需提供原厂商关于本项目的授权书原件,中标后提供的软件为合法正版,能享受原厂商的售后支持服务,最终用户名为:扬州市住房公积金管理中心。

    ★(7)服务要求:在服务周期内,中标人需根据用户主节点系统使用情况的变化,不断跟踪容灾系统系统运行状态,并做调整和更新,确保容灾系统系统长期稳定运行。当生产系统应用发生变化,主数据库表结构发生改变时或其它需要手工同步的情况发生时,须及时更新容灾系统系统及备用库的相应内容。

    每周容灾系统系统运行检查,数据自动同步完成情况记录分析,形成运行报告;并每月末进行主备节点生产系统和容灾系统系统切换演练,确保容灾系统机制的可靠稳定。

     

    8、其他

        本项目为交钥匙工程,各投标人需充分响应并满足以上各项需求和要求。报价时须包含各系统及设备间连接配件和线缆等一切材料,采购人不再承担任何其他费用。


    转载于:https://blog.51cto.com/64239/1884350

    展开全文
  • 网站可用性所谓网站可用性...容灾恢复能力的关键指标RPO:(Recovery Point Obejective,恢复点目标)是指业务系统所允许的在灾难过程中的最大数据丢失量,用来衡量容灾系统的数据冗余备份能力。RTO:(Recovery Time O...
  • 针对提高局域网中数据安全的目的,本文通过对容灾备份应急服务的系统结构、评价指标、关键技术以及备份方法进行分析论证,从理论上对不同容灾技术和方法进行比较和归纳,得出局域网容灾应急服务具体实施方案。
  • 备份容灾系统招标文件 一、 技术参数要求 以下主要产品技术参数要求中,凡标有“★”的地方均被视为重要的指标要求或性能要求。投标方要特别加以注意,不得出现负偏离。若有一项带“★”的指标出现负偏离,将被视...
  • 高可用性及容灾的几个衡量指标

    千次阅读 2020-03-29 19:33:52
    网站可用性 所谓网站可用性(availability)也即网站正常...RPO:(Recovery Point Obejective,恢复点目标)是指业务系统所允许的在灾难过程中的最大数据丢失量,用来衡量容灾系统的数据冗余备份能力。 RTO:(R...
  • 第二章招标项目内容、数量、规格和技术要求 一、WEB安全防护设备1套 指标项 ...
  • 山东中医药大学第二附属医院项目需求和技术方案要求 一、技术要求 容灾备份系统一、项目概述 山东中医药大学第二附属医院容灾备份系统实现医院现信息系统 HIS、电子 病历、检验 LIS、影像 PACS 系统等的数据集中实时...
  • 快速、可靠的容灾切换控制是实现高等级容灾的基本保证,同时也是容灾系统实现上的一个难点。Petri机制作为一种描述基于实时状态的并发控制模型,已经在多个领域得到了广泛应用,但在国内电信行业的应用尚属空白。...
  • A2包: 一、技术指标要求 ...目前,已利用IBM TSM备份软件实现数据库本地备份,根据公安部《公安交通管理信息系统数据安全备份建设指导意见》要求,现计划在公安部无锡科研所信息中心建设交管数据异地容灾...
  • 容灾备份资料

    2017-02-10 16:34:39
     容灾是企业数据管理中的一个重要环节,容灾备份系统要保证灾难发生时系统能够做到最快恢复和最小损失,RTO和RPO是衡量容灾系统的两个重要指标,通俗来讲,是这两个指标可以描述为业务连续性目标及数据一致性目标 ...
  • HA和DR的关系容灾和备份的区别衡量容灾系统的主要指标容灾系统的级别说明容灾建设等级对标分析容灾解决方案全景图容灾方案架构容灾备份解决方案框架容灾设计模式:同步、异步相结合主备容灾方案两地三中心(3DC)...
  • 容灾】RTO和RPO

    2016-12-18 22:43:31
    要建设容灾系统,就必须提出相应 的设计指标,以此作为衡量和选择容灾解决方案的参数。目前,国际上通用的容灾系统的评审标准为Share 78,主要包括以下内容。 ●备份/恢复的范围 ●灾难恢复计划的状态 ●业务中心与...
  • 绍兴市公共资源交易中心容灾及数据备份系统征求意见 经绍兴市政府采购管理部门批准,绍兴市公共资源交易中心将于近期就绍兴市公共资源交易中心容灾及数据备份系统进行公开招标采购。现将有关技术需求公布如下,并...
  • UIT信息容灾概论(1)

    2009-06-10 10:47:15
    UIT信息容灾概论. 1 前言....1.2. 容灾系统的主要设计指标. 5 1.3. 国家及各行业对容灾的要求. 7 1.3.1. 可参考法规及规范. 7 1.3.2. 灾难恢复策略制定的要素. 8 1.3.3. 容灾系统实施要点. 9 1.4....
  • 在分布式存储系统中,系统可用性是最重要的指标之一,需要保证在机器发生故障时,系统可用性不受影响,为了做到这点,数据就需要保存多个副本,并且多个副本要分布在不同的机器上,只要多个副本的数据是一致的,在...
  • RPO:企业能容忍的最大数据丢失量 RTO: 系统从发生故障到恢复的时间   比如系统的RPO是20分钟,即RPO=20,就是系统允许最多丢失20分钟的数据量。...系统的RTO是10分钟,就是系统必须在10分钟之类修好系统
  • 随着电子政务建设深入发展,越来越多的关键业务运行在电子政务平台上.业务系统的可用性和盟务数据的完整憾、...本文对予电予改务 宙下容灾备份的技术架构作了初步的分析、探讨 并就容灾备份系统建设提出了些关键指标
  • 容灾是企业数据管理中的一个重要环节。近年来,国内频频发生的自然灾害事件给企业CIO提出了一个问题,灾难备份到底要做成什么...RPO和RTO是衡量容灾系统的两个重要指标。RPO(Recovery Point Objective) 是指灾难发生...
  • 青海省地市(州)及区县容灾备份项目技术参数一、设备清单序号 产品名称 数量 单位一、省级容灾中心设备1 虚拟带库 1 套2 系统集成 1 套二、各地市数据中心设备1 虚拟带库 8 套2 系统集成 8 套二、产品技术指标1、...
  • 为了满足金融行业全面的灾难防御要求,实现高标准的灾难防御指标,同时避免出现国内常发生的容灾备份体系建设之后,仍出现“有灾无备”的现象,美国飞康公司所提出的基于IPStor技术的CDP(连续数据保护技术)灾备方案...
  •  其实这个问题也可以被反问为:你希望容灾系统能达到什么效果?要想阐述清楚此问题,首先要明白两个指标:RTO和RPO。 RTO,Recover Time Object,恢复时间指标,是指当灾难发生后,生产系统需要多长时间能够恢复...
  • 前言 ...爱数应用容灾方案采用容灾服务器模式,基于持续数据保护(CDP)技术,内置实时复制、灾难恢复和介质同步模块,可实现应用系统的实时备份、本地高可用、一体化集成保护、异地业务持续性容灾...
  • 容灾项目需要注意的几大问题

    千次阅读 2007-07-14 10:38:00
     其实这个问题也可以被反问为:你希望容灾系统能达到什么效果?要想阐述清楚此问题,首先要明白两个指标:RTO和RPO。 RTO,Recover Time Object,恢复时间指标,是指当灾难发生后,生产系统需要多长时间能够恢复...
  • 因此可以同时保障数据备份与系统、应用容灾的灾备解决方案应势而生,且发展迅速。 下面我们来看,在阿里云和阿里云产品都有哪些灾备的解决方案和能力。 容灾解决方案(个性化定制) 帮助应用系统在设计和部...
  • 本文从证券公司进行热备容灾角度介绍了,需要关心的哪些同步指标,也针对具体的实施步骤进行建议,本文可以提供给专业系统集成商进行方案的制作...
  • 重庆市永川区信息化建设管理办公室协同办公容灾备份设备采购第三部分 项目技术规格、数量及质量...招标项目技术需求虚拟化软件技术指标指标项目指标要求数量基本要求虚拟化平台采用裸金属架构,无需借助通用操作系统...

空空如也

空空如也

1 2 3 4 5
收藏数 88
精华内容 35
关键字:

容灾系统指标