珠海市金湾区三灶社区卫生服务中心(如下简称:三灶医院)信息化建设状况:上线使用的系统有HIS,LIS(检验信息系统),体检系统,万晟达系统(旧数据),病案系统,中医体质辨识系统,计免系统以及妇幼、公卫、全科系统。其中计免系统、妇幼、公卫、全科系统是全市统一上线维护;关键业务系统有HIS、LIS、体检系统,且其应用已经很是普遍。在门诊挂号、门诊收费、门诊发药、药品出入库、病人入院、住院医嘱信息、结帐等数据都存放在服务器数据库中,对实时性要求很是高。然而HIS、LIS、体检等系统均是单机运行状态,数据库没有启用实时备份功能,服务器也没有启用双机热备份功能。目前医院HIS系统应用部署在单台服务器上,另一台HIS服务器作冷备服务器处理,该服务器经过光纤网络链接到光纤交换机,再经过光纤链接到后端单台存储设备上;LIS与体检系统运行的服务器则配置较低且设备陈旧(体检系统服务器已在我中心采购计划中)。sql
从信息系统的运行维护管理指标和医院建设现状看,目前面临的主要难题是:数据库
业务中断(RTO指标);后端
数据丢失(RPO指标);浏览器
维护力量不足(连续运营能力)。安全
据了解,为保证数据安全和系统的正常运行,目前大部分医院都使用了双机热备份方案。由于数据的安全性关系到整个系统可否正常运行,最终关系到可否为患者提供正常的服务。系统数据一旦丢失,对医院、社会都会形成没法估量的损失。对此我中心组织对信息系统进行了信息风险排查,并针对会出现的风险提出了相应的解决方案。服务器
1.1 .1 业务中断风险(软件硬件问题)网络
目前LIS、HIS、体检数据库服务器均是单机运行,万一出现硬件或者软件故障,各个应用及数据库将会陷于瘫痪,影响到各个信息业务系统的运行:架构
1)出现故障时,若是是硬件故障,首先要对硬件进行维修或者更换,具体时间要取决于厂商的维修时间或者定货周期;oracle
2)硬件修复或者更换以后,还要进行系统恢复、数据库软件安装、数据恢复,这将花费几个小时甚至更长时间,其中数据库应用每每还须要开发厂家的现场支持。框架
1.1.2 数据丢失风险
1) HIS磁盘阵列虽然作了Raid,为系统提供了相对安全、可靠的运行和存储环境,但也成了系统的单一故障节点。虽然Raid自己有必定的安全策略,可是极端状况下发生故障(控制器、RAID卡故障或其它软硬故障),医院的业务将所有中断,数据可能永久丢失。
2)LIS系统开始上线的时候对业务数据的预估不够充分,致使如今使用时常常出现数据库归档日志溢出,在清除归档日志数据以前检验业务都不能进行了。且该问题出现频繁,平均每两个月就会出现数据库归档日志出错问题。对保障业务不间断和业务人员维护都带来比较大困难。
3) 体检系统服务器设备陈旧且配置较低,曾经出现过服务器硬件设备损坏致使体检服务器没法启动的状况。无双机备份且无有效的快速恢复业务的技术手段,维修设备期间严重耽误体检业务。
2.1.1 预检维护制度落实难度大
系统持续运行的要求比较高,基本无主动停机进行维护维修的机会,预检维护制度没法落实。即使有数据备份的措施,但也没法确认备份的数据是否有效,由于如需验证,就必须将数据倒回原系统运行,原系统就需停顿。
2.1.2 专业要求高、信息工做人员不足
目前三灶医院信息科系统维护人员仅有一个,要负责整个医院的信息工做,且专业技能有限;系统出问题后处理的应急性不够,未能在较短期内恢复系统使用;而数据及服务器维护的专业要求较高,这给常常性的运行维护带来较大的难度。
2.1.3 应急演练、快速恢复手段少
单机单系统设计,在不中断业务状况下,没法组织组织常常性的应急演练,日常也很难进行实际操做的训练,没法保证维护人员在灾难状况下的处置水平。
目前的系统维护都是面向维护工程师专业设计,一线值勤维护人员缺乏简单有效的快速恢复业务的技术手段。在灾难发生时,一线值班人员实际上基本作不到现场快速恢复,需等待相关维护人员、厂商服务商到场,业务中断时间、数据丢失的风险不可控。
【什么是双机】
就是对于重要的服务,使用两台服务器,互相备份,共同执行同一服务。当一台服务器出现故障时,能够由另外一台服务器承担服务任务,从而在不须要人工干预的状况下,自动保证系统能持续提供服务。
【为何须要双机热备】
双机热备针对的是服务器的故障。服务器的故障可能由各类缘由引发,如设备故障、操做系统故障、软件系统故障等等。通常地讲,在技术人员在现场的状况下,恢复服务器正常可能须要10分钟、几小时甚至几天。从实际经验上看,除非是简单地重启服务器(可能隐患仍然存在),不然每每须要几个小时以上。而若是技术人员不在现场,则恢复服务的时间就更长了。 而对于一些重要系统而言,用户是很难忍受这样长时间的服务中断的。所以,就须要经过双机热备,来避免长时间的服务中断,保证系统长期、可靠的服务。
硬件系统
服务器
1. 每台服务器拥有各自的系统盘,用来安装操做系统软件,双机软件。
2. 每台服务器安装一块额外的网卡。(双机互被援用Dual Active Hosting)
3. 每台服务器提供一个还没有使用的网口。(用来做心跳侦测信息的线路)
●公共驱动器
l 磁盘阵列系统
软件系统
操做系统
a) Windows 2003 server/Windows 2008/Linux/SCO UNIX
应用支持
b) 共享文件
c) Microsoft IIS
d) 数据库,Oracle,Sybase,Informix
e) Microsoft BackOffice Server
f) 正式发行的,运行在NT下的应用软件等
●双机容错系统软件
l ROSE HA软件
双机容错基本架构
模式一 双机互备援(Dual Active)基本介绍
双机互被援就是两台服务器均为工做机,在正常状况下,两台工做机均为信息系统提供支持,并互相检测对方的运行状况。当一台主机出现异常时,不能支持信息系统正常运营,另外一主机主动接管异常机的工做,继续支持信息的运营,从而保证信息系统可以不间断的运行。(无需共享存储)以下图:
模式二 双机热备份(Hot Standby)基本介绍
双机热备份就是一台主机为工做机(Primary Server),另外一台主机为备份机(Standby Server),在系统正常状况下,工做机为信息系统提供服务,备份机监视工做机的运行状况(工做机同时也在检测备份机是否正常),当工做机出现异常,不能支持信息系统运营时,备份机主动接管工做机的工做,继续支持信息的服务,保证系统不间断的运行。(需共享存储)以下图:
l 服务器掉电时,能实现自动切换。
l 服务器的硬盘、CPU、RAM发生故障时,能自动切换。
l 网络链接故障时,能发生自动切换。
l 操做系统,数据库或应用程序发生故障时,能实现自动切换。
l 提供手动切换功能,使系统管理员能够在主机负载过大时或其它适当的时候,实现手动切换。
l 能安全完成屡次切换。
双机高可用系统工做原理
双机系统的两台服务器(主机)都与磁盘阵列(共享存储)系统直接链接,用户的操做系统、应用软件和ROSE高可用软件分别安装在两台主机上,数据库等共享数据存放在存储系统上,两台主机之间经过私用心跳网络链接。配置好的系统主机开始工做后,ROSE软件开始监控系统,经过私用网络传递的心跳信息,每台主机上的ROSE软件均可监控另外一台主机的状态。当工做主机发生故障时,心跳信息就会产生变化,这种变化能够经过私用网络被ROSE软件捕捉。当捕捉到这种变化后ROSE就会控制系统进行主机切换,即备份机启动和工做主机同样的应用程序接管工做主机的工做(包括提供TCP/IP网络服务、存储系统的存取等服务)并进行报警,提示管理人员对故障主机进行维修。当维修完毕后,能够根据ROSE的设定自动或手动再切换回来,也能够不切换,此时维修好的主机就做为备份机,双机系统继续工做。
LCHA工做原理示意图
此方案容错功能实现的关键是在系统发生错误进行切换时,对客户端来讲主机是透明的,即主机的切换在工做端看来没有变化,全部基于主机的应用都正常。ROSE采用了虚拟IP地址映射技术来实现此功能。客户端经过虚拟地址和工做主机通信,不管系统是否发生切换虚拟地址始终指向工做主机,在客户端看来主机是透明的。在进行网络服务时,在双机系统后台ROSE提供一个逻辑的虚拟地址,任何一个客户端须要访问系统时只须要使用这个虚拟地址。当双机系统中的一台服务器出现故障时,ROSE会将另一台服务器网卡的IP地址更换为这个虚拟地址,继续提供网络服务。切换完成后,在客户端看来系统并无出现故障,网络服务也没有间断。除IP地址外,ROSE HA还能够提供虚拟的计算机别名供客户端访问。对于数据库服务,当有一台服务器出现故障时,另一台服务器就会自动接管数据库引擎,同时启动数据库和应用程序,使用户数据库能够正常操做。
保持现有网络架构、容灾设计不变,增长一套统一备份系统作全方面备份部署。提高统一容灾、持续运营能力,实现“数据不丢失,业务快速恢复”的运维目标,达到运行维护管理的“可控、简单”。
保持现有的系统构架基本框架不变,部署统一容灾系统备份一体机;
数据丢失小于半小时;
数据恢复点目标RPO小于半小时。
极简操做,数据随时验证恢复;
采用“统1、简单”设计,在统一平台上完成全方位数据、系统的备份,提供极简的自、一体化备份体验,而且数据可随时验证与恢复。
创建基础平台,容灾系统功能可扩展。
在保持如今基础平台的基础上,将来根据经费和管理目标要求,方便地经过增长受权和功能模块,来扩展对其余业务系统的保护或提高维护指标。
4.2.1 方案概述
备份一体机的做用首先是给被保护的服务器增长一个逻辑存储空间,并经过网络映射给被保护服务器,服务器的操做系统、应用环境、相关数据自动备份到逻辑存储空间中。
备份一体机对被保护服务器的数据变化,进行定时快照,实现快速恢复和多版本保存。
4.2.2 复制策略
经过制定不一样、合理的复制策略,实现集中、无人值守、自动化的数据在线复制。在灾难发生时,对系统和数据进行应急接替,及时恢复业务运行,使损失减至最小。
在系统第一次复制时,经过初始复制模式对整个系统盘进行复制,在以后运行中可按须要进行计划性的增量复制,可设置具体复制策略:
服务器名称 |
复制策略 |
实现指标 |
50台虚拟机服务器 |
定时R | 根据须要可设定天级别或更小级别的在线定时复制 |
RTO<5分钟,RPO<60分钟 |
4.2.3 实现效果
采用快照技术,对数据库服务器上的数据变化,造成连续时间点快照。当灾难发生时,能够选择任意时间点的快照造成副本,保证业务数据丢失小于1小时;
在线复制与在线还原,不影响系统的正常运行;
复制的系统、应用和数据独立于生产系统以外;
自动生成多版本快照,确保可用、可靠;
不影响生产系统的正常工做;
具备充分的可扩充的网络容灾应急设计,最大程度保护前期投资,后期能够经过增长受权的方式升级为应用级容灾,保障业务持续性。
4.2.4 方案特色
4.2.4.1全面在线复制的产品设计
备份一体机不只仅复制业务系统的数据,并且复制包括业务服务器操做系统以及业务运行的完整软件环境,包括:
操做系统;数据库系统;中间件系统;各类应用系统等。
4.2.4.2易于扩展的一体化容灾技术实现
备份一体机采用软、硬件一体化设计,可方便地进行“交钥匙”方式业务功能交付,部署、管理便利。
备份一体机采用模块化设计,可根据须要灵活选择相应的功能模块,同时,当应用环境变化时,能够方便地进行升级扩展:包括存储容量的扩展、应急方式的扩展、保护服务器数量的扩容等,可有效地保护用户的初期投资。
4.2.4.3易用易维护
备份一体机的操做管理采用全中文的WebUI,不须要安装任何管理软件,任何具备网络互通能力的终端均可以方便地经过浏览器登录系统管理程序,进行操做和管理。
在统一容灾系统部署完成后,将为每台生产服务器分配一组容灾存储,配合安装在生产服务器上的客户端软件,根据预先设定的策略,自动对各服务器的操做系统、应用软件、数据及数据库实施动态差别量在线复制,复制后在备份一体机系统上生成用于应急、容灾的快照,供应急、容灾、恢复时选用。
当实施网络启动操做系统、应用软件并恢复业务功能后,可在系统I/O比较少的时间(如深夜),使用备份一体机系统的恢复功能,自动或手动对各服务器原有的磁盘进行恢复操做;将存放在网络存储里的可用的操做系统、应用软件、数据及数据库恢复(回写)到本地盘,该操做支持对多台服务器的自动恢复,方便运营管理。
RPO ≦1小时。
支持定时复制, RPO ≦1小时;
提供任快照点回滚的数据保护和恢复功能。
恢复还原方式
采用PXE协议的网络启动应急模式在线恢复还原;
支持手动还原。
保护范围
操做系统、应用程序、数据库、数据文件等。
复制方式
在线复制,支持增量复制、全量复制
操做系统
Microsoft Windows 2003/2008 Server;
Microsoft SQL Server;
Oracle;
扩展存储:支持FC SAN、iSCSI SAN、DAS等方式的存储容量扩展,扩展容量无上限。
业务持续管理功能
内置BCM管理模块
操做界面
支持中文操做界面,支持Web管理方式。
自身安全
系统自身采用自主专用操做平台。
5、容灾平台建设(容灾一体机)
5.1 容灾平台建设的意义
应用级双活容灾系统,是一款融合了云计算、虚拟化技术、CDP技术、数据挖掘技术、迁移技术的容灾产品,引领应用级容灾、灾备恢复、跨平台迁移、业务系统云化、跨平台数据共享的解决方案。具有更高技术条件和要求的应用级双活容灾系统(容灾一体机),既能实现双机备份的自动接管服务器业务功能;也兼有备份一体机对存储数据进行备份的动能;并拥有更高的时效性与数据完整性,可达到RPO和RTO趋于零;能够多系统多机接入,一体管理;并拥有更直观和方便的操做,方便维护。后续须要增长业务系统进入容灾平台,只需购买受权便可。
采用应用级双活容灾系统,对本地机房核心的业务系统进行统一保护,对操做系统、应用、数据进行实时同步,当保护的业务系统或整个机房发生故障(物理故障、逻辑故障),能在3-5分钟内快速的接管故障的业务系统对外提供服务,物理服务器业务系统、虚拟化业务系统、私有云业务系统的高可用性。应用级双活容灾系统不只提供容灾接管功能,同时还附带业务系统历史版本恢复和仿真测试功能,历史版本恢复功能可将业务系统的整个工做负载(系统、应用、数据)恢复到任意时间点;使用仿真测试功能提供与生产环境一摸同样的系统、应用、数据,在对生产服务器升级补丁、升级软件的时候能够仿真测试平台中进行测试,测试经过后再在生产环境中操做,如此可下降升级所致使的故障。
基于软件科技的产品应用级双活容灾系统的技术和功能来实现信息系统的总体容灾平台建设,经过对医院核心的业务系统(操做系统+应用+数据)进行一体化保障,方案拓扑图以下:
(容灾平台拓扑图)
编号 |
要求 |
描述 |
1 |
故障切换时间要求 |
切换时间不超过5分钟,最好在3分钟内实现。 |
2 |
多种故障切换方式 |
提供自动故障切换和手动故障切换方式 |
3 |
计划内维护要求 |
提供计划内维护支持能力,计划内维护切换时间很少于10分钟 |
4 |
数据丢失性要求 |
原则上要求零数据丢失,能够依据状况进行调整 |
5 |
数据传输要求 |
采用异步方式和磁盘底层复制技术以下降对生产业务的性能影响 |
6 |
数据实时复制要求 |
实时复制数据变化的部分,数据丢失RPO趋向与零 |
7 |
物理部件失败要求 |
支持磁盘,文件系统,主机,磁盘柜等各类物理部件问题致使的失败保护 |
8 |
站点失败要求 |
支持因为火灾,电力以及其余因素致使站点失败的数据保护。 |
9 |
逻辑失败要求 |
支持因为数据块损坏致使的数据库没法启动,数据丢失等逻辑失败保护 |
10 |
人为错误失败要求 |
支持因为人为误操做以及***等致使人为错误失败致使的数据保护或者恢复。 |
11 |
生产系统的性能影响要求 |
生产系统性能影响不超过5% |
12 |
生产系统可用性要求 |
容灾系统不会下降生产系统可用性 |
13 |
网络链路分钟级别短暂故障 |
要求不会对生产系统产生影响 |
14 |
网络链路小时级别长期故障 |
要求不会对生产系统产生影响 |
15 |
网络链路密集的秒级别短暂故障 |
要求不会对生产系统产生影响 |
16 |
网络链路容错 |
支持网络链路的容错,能够利用网络的备份链路,好比多路网卡等 |
17 |
容灾系统的硬件故障 |
因为容灾系统硬件故障致使的容灾系统不可用不会对生产系统产生影响,好比网卡,磁盘以及控制卡等 |
18 |
容灾系统的软件故障 |
因为容灾系统软件故障致使的容灾系统不可用不会对生产系统产生影响,好比容灾系统管理软件部件等 |
19 |
网络协议 |
采用IP网络实现 |
20 |
网络带宽 |
现有的百兆或千兆带宽 |
21 |
RTT要求 |
RTT要求在10ms之内便可知足要求,能够容忍部分时间的30ms响应 |
22 |
在线实施要求 |
要求在灾备系统实施期间保持生产系统运行 |
23 |
存储系统失败的原址运行 |
在生产系统主机可用的状况下能够支持系统原址运行 |
24 |
部分文件失败的原址运行 |
在部分文件失败的状况下能够支持系统原址运行 |
25 |
原址运行要求 |
在生产系统出现如下故障时,不进行容灾切换,而原址运行;在生产系统主机可用的状况下能够支持系统原址运行;在部分文件失败的状况下能够支持系统原址运行 |
26 |
容灾切换要求 |
提供一对1、多对一的容灾复制和切换; |
27 |
一键切换 |
支持单健切换,全部切换都要求提供图形界面模式,全部切换都要求一步完成。 |
28 |
全业务切换 |
支持业务系统级别切换,进行完整的数据库,中间件以及其余中间件的自动/手动切换。 |
29 |
业务部件切换 |
支持业务部件级别切换,在业务系统某一部件发生故障,仅仅切换该部件到容灾系统,好比数据库等。 |
30 |
网络切换 |
支持网络切换,而且能够指定在切换时候是否支持网络切换。 |
将本地机房全部业务系统的整个工做负载的变化,实时同步到对应的应急容灾虚拟机,保障生产系统与容灾系统保持一致,当本地数据中心单个业务系统或多个业务系统故障,自动或手动切换到进行接管。因为虚拟机的特性,整个应急容灾接管过程能够在3-5分钟级别内实现。
经过提供用于保护本地数据中心全部业务系统工做负载的经济实惠且易于使用的解决方案,使部署、测试和管理灾难恢复解决方案的方式发生革命性变化。将医院全部的业务系统工做负载保护到统一的可扩展的容灾平台中,免却了昂贵的重复硬件和软件投资。
采用独特的磁盘I/O监控技术,对磁盘块的写入的扇区进行记录。在磁盘驱动层监控到的I/O操做能真实的反应出应用程序在写入文件时所作的实际更改。持续不断的刷新和记录磁盘块的变化bitMap地址表,并对对应的扇区读取数据传输到,确保数据一致。与常见的基于文件的复制技术不一样,采用基于监控磁盘I/O的复制技术,只须要读取变化的磁盘块并传输到,相比基于文件的复制技术,占用系统性能资源极少,数据传输更少的优势,从而将生产服务器性能的影响降到最低,极大的提升数据传输的效率和下降带宽要求。
经过对oracle 等数据库的事务日志(redo log)作实时分析,获取数据库中的全部操做命令和数据,并将这些数据根据不一样的应用类型进行加工处理,处理结果被分配到全部订阅了这些数据的队列中,再由每一个订阅的数据应用程序将数据装入对应的数据库中,一旦双机生产库发生故障,直接切换到应用级双活容灾系统,接管故障的双机数据库系统;在生产库未发生故障的状况下,可将应用级双活容灾系统做为数据库的查询库使用,减轻生产库的压力。
采用自动复制技术,能够制做不止一份的备份版本,提供异地存放的磁盘数据,避免磁盘自己出错形成的数据损失。保证更高的数据安全性。并且可将磁盘上因使用并行流形成的混杂顺序的数据以数据自己顺序的方式复制,可大大提升恢复速度。进一步提升备份和恢复性能。
提供的实时工做负载虚拟化备份,采用传统的虚拟系统格式,所以备份出来的工做负载可在KVM、VMware ESXi等虚拟化平台上直接运行,当程序损坏时也不会影响到备份工做负载的读取。
在一些本来带宽资源就不宽裕的生产网里,用户能够对备份占用的带宽有计划的实施限制,防止因数据备份占用的带宽对生产网产生影响。计划的好处在于当网络处于非繁忙时段,能够全速传输备份数据到指定服务器。也支持计划任务,只在特定的时间段,如凌晨1:00,才开始增量数据的备份。
传统的系统级别的HA解决方案,每每局限于本地实施。基于TCP/IP协议传输数据,所以,没有地理范围的限制。不管是实现数据的高可用仍是系统级别的高可用,都无需局限在本地进行。配合数据压缩和带宽控制技术,能够极大下降用户用在异地数据备份网络上的投资。
经过数据对比校验机制,来保证源服务器和容灾平台上的数据在断开后从新链接进行校验,保证数据全一致性。若是有数据不一致,会把数据增量变化部分复制到容灾平台,能够保证用户源服务器和容灾平台上的数据真正彻底一致。
结合服务器虚拟化技术,经过提供用于保护数据中心的全部工做负载的经济实惠且易于使用的解决方案,使部署、测试和管理灾难恢复解决方案的方式发生革命性变化。可将多台物理和虚拟机工做负载总体保护到单台容灾设备上,从而使您能够保护更多生产系统,并免却了昂贵的重复硬件和软件投资。
为防止业务系统管理员不在现场致使没法及时处理故障切换,用户可对一些关键应用配置自动故障切换。配置监视被保护业务系统的联网状态,在知足指定的条件后,会自动配置并接管源生产系统的全部应用。用户也能够选择手动操做,防止因误操做致使故障切换带来的二次故障。
按期演练测试是灾难恢复计划中很是关键却每每被忽视的部分。能够快速方便地测试工做负载复制的完整性。只需单击鼠标,就能够启动容灾演练虚拟机,用于验证应用系统的副本是否有效。因为演练测试系统与生产网络隔离,所以能够放心操做,而无需担忧影响生产系统的正常运行。
配置清单
序号 |
名称 |
推荐参数 |
数量 |
备注 |
说明 |
1 |
双机备份软件 |
双机热备软件,支持Windows Server版本操做系统(Windows2003/R二、Windows2008/R二、WIndows2012/R2)支持Linux Server 版本操做系统(RedHat 5/6/7.0/7.1;CentOS 5/6/7.0/7.1;SUSE 11/12)支持Oracle、MS SQLServer、Mysql、DB二、Sybase和Informix等主流数据库等 |
1套 |
HIS系统 |
核心产品 |
2 |
双机备份软件 |
双机互被援软件,支持Windows Server版本操做系统(Windows2003/R二、Windows2008/R二、WIndows2012/R2)支持Linux Server 版本操做系统(RedHat 5/6/7.0/7.1;CentOS 5/6/7.0/7.1;SUSE 11/12)支持Oracle、MS SQLServer、Mysql、DB二、Sybase和Informix等主流数据库等 |
2套 |
LIS系统 体检系统 |
核心产品 |
3 |
软件部署调试 |
双机软件安装部署调试 |
1项 |
部署三台双机软件,分别对应HIS系统、LIS系统及体检系统 |
|
4 |
LIS及体检系统服务器 |
CPU:2颗E5-2609v4(1.7GHz/8c)/6.4GT/20ML3 (其2台)4块1T SAS 2.5寸(企业级)硬盘 |
3台 |
现有LIS及体检服务器,配置过低端,容易出现卡顿死机,须要及时清理内存及日志信息等,没法保障运行稳定及安全。因此考虑升级现有LIS服务器,并对LIS和体检系统实现双机 |
核心产品 |
5 |
数据迁移 |
两台HIS服务器及存储部分数据迁移及部署,知足双机软件数据部署应用 |
1项 |
||
两台LIS服务器,知足双机软件数据部署应用 |
1项 |
||||
两台体检系统服务器,知足双机软件数据部署应用 |
1项 |
||||
6 |
备份一体机 |
备份一体机硬件规格:2U机架式设备,8个热插拔硬盘位置,32TB容灾存储,1个6核心处理器,32GB内存,2个千兆以太网接口,冗余电源。 |
1台 |
核心产品 |
注:本招标文件要求中凡标有“*”的地方均被视为重要的指标要求或性能要求。投标方要特别加以注意,必须做出响应,不得出现负偏离,并提供相应技术支持文件(包括但不限于生产厂家出具的技术参数证实文件、产品说明书,产品说明手册,官方网站公布的一些产品资料,加盖投标人公章)。如有一项带“*”的指标未响应或出现负偏离,其投标文件将按无效处理。