图片 14

达沃时代携手陇南第一人民医院,构建新型超融合容灾备份平台

引言

  昨天和刚入行就带我的老领导相约北京酒吧,4年师徒情,7年未见,从老公司境况到老熟人的现状,到现在的工作,未来的发展。从当下的技术到新技术的展望,聊到数据库架构,我说我现在还是在做传统的数据库架构,而老领导满心的分布式,好像不是分布式都是比较LOW了,这里面依然存在着这样一个问题,什么是“分布式”,因为每个人说的都不一样,理解的也都不一样。

   而分布式又是怎样一步一步演变的,不同情况下又该如何设计规划自己的架构,文章篇幅有限内容太多,这里只能粗浅的说一说啦。

——————本文纯属个人观点,如有错误、不足望指教—————-

“无论多么繁忙,一家好的医院都必须永远保持有序,高效,科学的营运”。现代化医疗建设,不仅仅局限于追求设备仪器、医疗水平的提高,通过高效的数据管理、信息系统建设等手段,更有利于为患者提供安全、便利、优质的诊疗服务。
客户背景
陇南市第一人民医院是甘肃省陇南市武都区的一所三级综合医院,始建于1952年。也是陇南市医疗急救、预防保健、科研教学及医疗技术指导中心。坚持“以病人为中心”,
积极致力于追求卓越的医疗技术,提高医疗服务水平,努力建设成“环境、设施、技术、服务”
一流的现代化医院。
在早期的信息化建设过程中,陇南市第一人民医院已经建有HIS、LIS、CIS、EMR、PACS等医疗信息系统。近年来随着门诊量的大幅增加,HIS、LIS、CIS、EMR等医疗信息系统迫切需要更加高可靠的运行环境,PACS、EMR等医疗信息系统需要大容量、持久稳定的数据存储平台,需要升级改造数据中心。
业务挑战
医院原始业务系统架构由3台物理服务器加1台IBM集中式存储构成。其中有2台物理服务器使用NEC双机热备软件外加IBM集中式存储,支撑oracle数据库业务运行。第3台物理服务器支撑4类应用的运行,分别为:HIS医院挂号收费、LIS实验室检验、临床药学和电子病历等管理系统。
原始系统架构主要面临以下挑战: 1. 容灾备份挑战
由于原始系统架构没有一套完整的容灾备份机制来保障数据的安全性、完整性,随着数据量的增大,系统运行负担加大,为了确保业务系统的稳定性、高可用性,需要构建一套容灾备份机制。

 

  1. 应急响应挑战
    医院的信息系统规模庞大,业务模式、流程运行复杂,外加上门诊人次的大幅增多,给业务系统在应急实践响应速度方面施加了很大的压力,迫切需要升级部署高可用的数据中心,实现业务系统的高可用。
  2. 业务并发挑战
    原有系统架构使用NEC双机热备机制,而且多个业务系统部署在同一台服务器上,业务系统并发量大,对系统的稳定性产生很大的影响。需要建立一套能够实现主备用快速切换,并且各个业务系统分离的系统平台。
    方案简介
    原有系统环境的可用性、可靠性较差,NEC双机热备模式的稳定性不高,系统资源利用率低,就有了构建高可靠容灾备份平台的诉求。经过重重比较、筛选和慎重考察,陇南市第一人民医院最终选择部署达沃时代小金刚超融合容灾备份解决方案。
    本次方案,充分利用小金刚超融合平台强大的稳定性和高可用性优势,即能保证数据的安全性,又可保证业务的连续性,结合医院原有系统,部署一套达沃小金刚及备份容灾软件,构成容灾备份平台。
    升级后的数据中心将之前单机运行的HIS医院挂号收费、LIS实验室检验、zemr电子病历、临床药学等管理系统转换成虚拟服务器承载的独立业务系统,迁移到小金刚超融合容灾备份系统平台,实现了业务系统及数据的备份,提供了能够快速响应的容灾平台,并将原有各个业务系统分离部署,进行业务负载的隔离,保证了各业务系统的高可用、高可靠和持续稳定运营。
    客户收益 1. 容灾备份
    利用超融合容灾平台和容灾软件,在主业务服务器故障后,可以在很短的时间内切换到容灾系统。
  3. 高可用性
    将原先物理单机上运行的业务系统迁移到小金刚超融合容灾备份平台后,实现了业务系统资源的灵活调配,同时从服务器、网络、存储等多个方面保障了整个业务环境的高可用。
  4. 一体化交付
    小金刚超融合容灾备份解决方案,三台服务器存储网络通过万兆端口两两互联,无需万兆交换机,大大简化了IT架构,节省成本的同时,一体化交付方式也大大缩短了项目周期,加速了业务部署。
    作为中国存储的创新力量,
    达沃时代自主研发的全球首创三节点轻融合IT基础架构,以致力于推进企业IT信息化建设为己任,为企业用户构建架构精简、高可靠、低成本、快速部署、运维简单的微数据中心解决方案。分享阅读:昆明尖锐湿疣医院黄冈治疗性病的医院淄博治疗生殖器疱疹的医院

架构的演变

  架构演变一定是根据当时要求的场景、压力下性能的需要、安全性、连续性的要求、技术的发展…..

  我把架构的发展分为大概4个阶段:

  1.单机模式

  图片 1

   IT建设初期,高速建设阶段,大家要做的只有一件事,我需要什么构建什么,我需要ERP我买软件,需要HIS买HIS,这个时期按需构建大量的系统基本在这个时期产生,当然那个时候也没什么高可用的要求。

  2.双机热备 和 镜像

  图片 2  图片 3

  基本是20年前的技术了,在高速构建后,一堆的系统运行中,用户发现我们的核心业务如果坏掉业务受影响,停机几个小时做恢复
这是无法接受的,那么双机热备或镜像,Active-Standby的模式出现,这样一台机器工作,一台备用坏了在短时间可以接管业务,造成的损失会低很多!

  那么问题也很明显,备机资源浪费,依赖存储,数据还是单点,成本较高。产品也很多:RoseHA/RoseMirrorHA、NEC
ExpressCluster、微软MSCS、Symantec VCS、Legato、RHCS 太多太多了。

  随后为了解决数据单点的问题有出现了
存储的主备,存储的双活这厂商也太多了,这里就不介绍了

  图片 4  图片 5

 

  基本上传统企业依然停留在第一和第二阶段,也就是要么单机,要么双机热备

 

  3.节点多活 

  图片 6 
 
 图片 7

  随着业务量越来越大,数据量不断飚升,系统高效性的矛盾显现出来,系统卡慢、报表、接口业务无法分离OLAP
OLTP业务混合导致系统锁情况严重,资源消耗极其庞大,光靠升级硬件已经无法满足要求,横向扩展已经成为大势所趋。

  同时切换时间、备机无法启动的问题也困扰着用户。

  那么节点多活,多台机器同时对外提供访问的技术登上舞台,代表的ORACLE
RAC、微软ALWAYSON 、MOEBIUS集群

  多活的两种模式也是从第二带架构的演变

  oracle rac
把双机热备的辅助节点变的可以访问,关键点数据在多节点内存中的调配

  Microsoft awo、Moebius
则是把镜像的辅助节点变的可以访问,关键点数据多节点同步

  这样横向扩展来分担压力,并且可以在业务上进行分离。

   4.分布式架构 

   图片 8

   分布式架构真的不知道从何说起,概念太大,每个人理解的都不一样,只能意会不能言传:

  比如说一份数据分开存成多份

  比如说拆分,水平拆分、垂直拆分、分库、分表、分业务

  比如说….

  其实说到底就是在第三代横向扩展也无法满足的情况下,继续“拆”,根据不同需求各种“拆”,拆到什么样呢?
大家都知道可以说最慢的环节在数据库,传统的做法复杂语句,大存储过程运行非常慢,那我们就把这些拆到表数据量足够小、语句足够简单、业务粒度小、访问压力尽量的小!

  这样细化的设计一切为业务服务,也是精细化设计产物,但这也存在一个问题,传统企业在缺少高端人才,人力的情况下根本无法做到。现在的互联网公司为业务的需要同时对IT团队的大力建设,这是传统企业根本无法达到的。

  

  当然如果有第五代那也许可以说是云,未来业务一切的技术都是云端,云端看不见摸不到,传统行业人回归业务,而IT
建设与管理也必然由专业的人做专业的事儿。

 

  个人总结的架构演变,主架构演变不包含其他辅助技术,仅供参考

  图片 9

其他技术漫谈

   在这四代架构之间也有很多技术出现,主要以数据复制、存储同步为代表,如DG、OGG、LOGSHIPPING、Replication等等,这些都是不同场景下的数据复制,让一个副本变成多个,基本目的在于副本读或者本/异灾备,而这些技术也在不同的场景中扮演这重要的角色,每种技术都有自己的优缺点,不能一概而论。

  图片 10

 

  当然这里面还包含现在所谓的虚拟化、超融合、存储双活,这些技术首先不是数据库本身技术,在很多企业所谓数据库的高可用中扮演着擦边球的角色,虚拟化、超融合、存储双活都有自己适用的场景,而说到数据库的架构,这些方案只是基础架构层面。

  图片 11

如何选架构

  •   选架构

  首先你该选的是几代架构?

  四代架构是按照业务不断细分,以冗余 和 拆分、细化为主线大体过程

  二代冗余

  图片 12

  三代粗拆分

  图片 13

  四代细拆分

  图片 14

 

 

 

  当然这是只是大概的意思,实际中拆分的场景,条件,扩展性一系列复杂的过程。

 

   我曾经无数次遇到几十G的库
几百并发的应用就要规划分片,领导最求高大上,底下技术人员叫苦。

  •   构建

  构建中主要是对建构的细节了解和熟练,这和企业的人员配置有很大的关系,传统企业中很多在架构方案中选择第三方产品?这是为什么,构建需要专业的人,而企业最少的就是这部分人,而维护管理,责任划分也是不得不考虑的事情。

  当然架构越复杂投入的经历也就越大,这也不是一个架构师可以主导的事情。

  •   维护

  维护才是关键,业务变动后的灵活性、压力下的扩展性、出问题的排查、技术力量的支持,一系列漫长的过程开始了…..

 

题外篇

  自己在传统行业玩的太久了,写这片文章的过程中也和PingCAP 联合创始人&
CTO
黄东旭,聊了一些未来技术的发展,tidb做的风声水起,对未来数据库大家都是未知,但随着技术的不断涌现更牛的架构,更牛的理念也必将一一实现。

  比如依靠智能化的机制集群自我修复,性能自提升,架构自适应等等

总结

   架构方案是几代不重要,重要的是适合自己的业务,保证稳定、安全、高效、持续,单机适合简单业务,没有那么高的安全性、连续性依然可以,双机热备可以保障基本的高可用,节点多活的集群适合业务压力较大简单粗暴的分离和压力分担,至于分布式如果企业有能力有资源,业务压力庞大自然会考虑,但在我接触的客户中太多认为自己业务只能通过分布式方案构建,但是其实只是简单优化+三代多活,读写分离负载均衡即可满足。

  所以根据自己业务评估最为重要,一个好的架构规划,不但解决现有问题节省成本,更会避免步子太大激进带来的不必要损失。