信息存储与共享（共5篇）
信息存储与共享 篇1
0 引言
数据库是信息系统的重要支撑,其高可用性是信息系统稳定运行和数据安全的关键。以往部署时常采用小型性机及双机热备等技术实现,但对于中小型企业或普通高校来说,购配如此高档的设备其投资难以支付。Oracle10g提供了应用集群(RAC)高可用性实现方案,具有并行服务、负载均衡、故障转移、易于扩展等优势,且能在多台性能相同或不同的低价位服务器上部署。采用刀片服务器和共享存储部署Oracle集群,使信息系统的可靠性与经济性之间的矛盾得到平衡。根据在刀片和存储上Oracle集群的部署实践,就部署的规划与步骤作了简要阐述。
1 部署规划
1.1 硬件规划
实现集群的硬件主要由刀片服务器和SAN存储设备组成。早期的刀片服务器产品,没能集成以太网交换模块和光交换模块,架构时需另购配以太网交换机和光交换机产品。设备间连线(网线和光纤跳线)较多,且易发生连接故障。近期的刀片服务器产品,大都将以太网交换机和光纤交换机作为模块集成在一起,设备间是以背板卡座方式内部连接,外部连线清晰简洁,可靠性提高。采用了IBM LS21刀片服务器和EMC CX3-40C存储,其结构如图1所示。刀片服务器产品通常有14～16个刀片,可根据信息系统的性能需要选取其中的多片部署集群。无论参与集群的刀片数多少,其部署方法基本相同,以四片刀(1#～4#)为案例进行了部署。每块刀片上都配置了双通道高速数据通信卡(HBA),通过内部背板分别与两个光交换模块相连。光交换模块与共享存储间通过光纤跳线采取4通道冗余连接。共享存储从光纤盘所在的RAID组中划出500GB,建立一个数据库共享访问存储组(dbms),在组中授权给第1～4号刀片。
1.2 IP地址规划
每个刀片服务器上通常配置两块以太网卡,并分别与两个以太网交换模块相连。集群配置时将1～4号刀片的第一块网卡eth0用于网络通信,其IP规划为:192.168.100.[1]/26;并配置用于RAC集群的数据访问的虚拟地址,IP规划为:192.168.100.[21～24]/26。第2块网卡eth1用于 RAC集群内部通信,其IP规划为:172.20.1.[1]/26。刀片控制中心的网卡IP地址规划为:192.168.100.20/26,用于RAC集群仲裁控制。上述列举的IP地址,仅从通信功能的角度做的划分,实际部署时可根据所在园区网的真实地址进行规划。
2 部署步骤
2.1 操作系统安装与升级
操作系统采用了CentOS4,可从网站下载后分别对各个刀片服务器进行安装,具体安装步骤不再赘述。数据库集群部署前必须安装全局文件系统(GFS),而要安装GFS必须对CentOS4版本的内核进行在线升级。在线升级必须做如下工作:(1)接入Internet,配置刀片的网卡上网地址;(2)修改升级脚本文件CentOS-Base.repo,位置在/etc/yum.repos.d/目录下,将脚本文件中的下载连接地址,替换为中国科学技术大学的下载镜像地址http://centos.ustc.edu.cn,目的是为了提高下载速度;(3)运行公钥数字签名命令,到镜像站点下载须进行数字签名;(4)运行升级命令,#yum-y updata;(5)内核升级后须重新启动系统;(6)GFS组件安装与升级。为了方便安装与升级的命令操作,可建立一个升级与安装脚本文件。其内容如下:
运行上述脚本文件即可升级与安装,完毕后也须重新启动系统。
2.2 存储驱动与代理安装
刀片服务器要与存储连接,必须在各个刀片上安装HBA卡的驱动与代理程序,才能使刀片与存储达成通信和进行授权管理。对于EMC存储的驱动与代理程序有:EMCpower.LINUX-4.5.1-022.rhel.x8664.rpm和naviagentcli.noarch. rpm的安装包。分别在各个刀片上运行如下命令安装:
#rpm ivh EMCpower.LINUX-4.5.1-022.rhel.x8664.rpm
#rpm ivh naviagentcli.noarch.rpm
驱动安装后须重新启动系统。然后进入EMC存储管理系统,进行物理存储组划分和节点授权等操作。
2.3 共享存储的配置
对共享存储的配置主要有:建立磁盘分区,划分物理卷、逻辑卷组、逻辑卷,对逻辑卷格式化。部署Oracle集群须建立七个逻辑卷,其名称笔者示例为:odata,red01,red02,redo3,recovery,v1和v2。Odb为逻辑卷组名。操作命令如下:
然后分别对各逻辑卷进行格式,命令示例为:
#gfs-mkfs t ClusterName:odata p lockdlm j 3 /dev/odb/odata
上述操作也可用Xwindows下配置工具来建立,具体配置操作不再详述。命令是:#system-config-lvm。
2.4 GFS配置
首先编辑位于/etc/目录下的hosts文件,其内容如下:
127.0.0.1 localhost.localdomain localhost
192.168.100.1 node1
192.168.100.2 node2
192.168.100.3 node3
192.168.100.4 node4
172.20.1.1 node1-priv
172.20.1.2 node2-priv
172.20.1.3 node3-priv
172.20.1.4 node4-priv
192.168.100.21 node1-vip
192.168.100.22 node1-vip
192.168.100.23 node1-vip
192.168.100.24 node1-vip
node1,node2,node3,node4是主机名称。node1-priv,node2-priv,node3-priv,node4-priv是Oracle数据库内部通信的IP地址名称。node1-vip,node2-vip,node3-vip,node4-vip是外部访问Oracle数据库的连接验拟IP地址名称,它是实现故障自动转移必须的地址配置。
在XWindows下运行配置集群工具,命令是:#system-config-cluster。按照新增集群(ClusterName),增加节点(nodex),增加栅栏(fence),栅栏设置(fencebladecenter),错误处理等项目配置操作。完成后在/etc/cluster/目录下产生名为cluster.conf的配置文件,将此配置文件拷贝到其它节点的对应目录下,其具体内容不再详述。
2.5 挂载脚本配置
首先用mkdir命令在根目录下建立挂载点目录,具体为/gfs/odata,/gfs/log1,/gfs/log2,/gfs/log3,/gfs/log4和/gfs/recovery。为了使上述存储设备在系统启动时自动加载,在/etc/目录下的加载脚本文件fstab中增加如下命令:
而后将该脚本文件分别拷贝到其它节点的对应目录下。
2.6 Oracle 10g数据库安装
安装过程中应注意集群安装与单台安装选项的区别,具体安装细节不再细述。安装命令为:
安装后分别重新启动各节点的操作系统。可用命令检查各节点和数据库的运行情况。
2.7 连接Oracle的JNDI配置
集群下的JDBC连接(连接池)JNDI的配置描述与单机时有所变化,在信息系统具体应用配置文件中也应做相应变化,其描述如下:
3 结束语
用低价位的刀片服务器部署Oracle集群,既能保证有较高的服务性能,又降低经费的投入。随着数据库信息服务强度的增大和访问负荷的加重,可随时增加参与集群的刀片数量,调整部署配置也较简便灵活。采用集群方案部署了数字化校园的应用系统,经过一年来的实际检验,集群运行稳定可靠。尤其在单个刀片发生硬件故障时,系统仍能提供不间断的数据服务。
参考文献
[1]Oracle Database 10g高可用性实现方案[M].刘永健,译.清华大学出版社,2005(5).
信息存储与共享 篇2
关键词：多云存储,资源共享,安全架构
1 概述
近二十几年来, 随着计算机的普及, 企业信息化的大力建设, 政府部门及企事业等单位都建立了存储着大量的媒体和数据文件的应用系统。为此, 为了避免数据的丢失, 相关部门购买了大量多余服务器、网络设备来进行冗余。此外, 这些文件在企业总部和多个分支机构中大量重复的传输导致企业主干网的阻塞、用户访问速度下降, 甚至使应用系统崩溃。例如, “办公自动化系统”或“文件共享系统”中最新的信息或文件刚发布时, 大量的客户端同时访问应用系统导致的网络阻塞问题。另外还有数据传输和存储的引发的安全问题。因此, 为了能充分利用计算与存储资源、提供计算效率和降低成本, 学术界与产业界先后提出了网格计算 (Grid Computing) 、分布式计算、效能计算 (utility computing) 等技术。当前则主要提出了“云计算”技术, 由于它具有清晰的商业模式而受到广泛关注, 从而得到产业界和学术界的普遍认可和关注。云计算是基于网络的计算机模式来通过共享的服务器实时的为计算机或其他设备提供所需资源、软件和数据[1]。云计算的服务模式包括了基础即服务 (Infrastructure as a Service, Iaas) 、平台即服务 (Platform as a Service, Paas) 和软件及服务 (Software as a Service, Saas) 等多种模式。其中Iaas模式, 并不是要求用户去购买服务器或空间, 而是以一种外包的形式将资源租赁给用户。如果用户只需要额外的存储空间, 这种服务称之为存储服务 (Storage as a Service) 。云存储是相对基本而且已经本广泛应用的服务, 它能提供用户稳定的、大量的网络存储空间。
亚马逊 (Amazon) 推出的“简单存储服务 (Simple Storage Service, S3) 和”弹性计算云 (Elastic Compute Cloud, EC2) 标志着“云计算”发展的新阶段。谷歌 (Google) 公司一直致力于推广以 (Google File System, GFS[2]) 等技术为基础的应用引擎 (App Engine) 来为用户进行海量数据处理提供了手段。而IBM也在2007年推出了“蓝云” (Blue Cloud) 计算平台, 采用了xen[3], Power VM虚拟技术[4]和Hadoop技术[5]以期帮助客户构建云计算环境。微软也在推出了Windows Azure云计算操作系统.此外, 国内外学术界也纷纷就云计算进行了深层次的研究。Google专门启动了云计算学术合作计划, 并先后与麻省理工学院、斯坦福大学、卡耐基梅隆大学、清华大学等高校建立合作关系推动云计算的普及和理论研究。
然而, 当前云存储服务的架构还是集中控制方式, 所有的数据节点都必须通过一个主控服务器来进行索引和管理。随着节点数的增加, 这个主控节点成了云储存系统的瓶颈。此外, 主控节点的单点错误也将导致整个服务的中断, 从而造成巨大的损失。几乎所有的云存储技术在面向用户时或多或少使用了对等网络技术, 但在它们的后台还是使用的是客户/服务器的模式。客服/服务器架构的容易导致服务器的产生故障、延迟甚至崩溃。本文针对这些问题提出一种基于P2P和HDFS的多云存储架构来解决集中控制导致的单点错误问题, 并针对数据存储、安全和检索问题进行探讨。
2 基于P2P和HDFS的多云存储架构
P2P是早期的一种技术, 它通过将计算机即作为客户端又作为服务端相互连接在一起来共享数据和应用[6]。在P2P网络中, 节点通过加入到一个分布式的网络中去共享它的CPU资源、硬盘空间、网络带宽等。这个过程需要节点之间相互协调, 并需要一个中心授权。现有的P2P系统如DC++、Gnutella等只提供了网络中不同节点间的文件共享功能, 并无法将自己的数据存储在对方的系统中。
HDFS[7]是根据GFS的技术而开发的开源云存储系统, HDFS允许将存储系统部署在多个廉价的服务器上, 并具备有高容错性、高吞吐量等特点, 非常适合与对大数据集的访问与处理操作。HDFS是一个的主从结构系统, 由一个名字节点和多个数据节点组成。其中名字节点主要用于对文件命名空间的管理和用户访问请求的管理, 而数据节点则主要存储相应的数据以及接受用户对数据的各项请求。
如图1所示, 利用P2P中经典的DHT算法Chord可以将存储在不同云存储平台的的资源文件链接起来实现共享从而剔除传统云存储中所谓的中心节点, 所有的节点都相互连接着, 如果其中一个节点出现了问题, 将会有其他最适合的节点替代它的工作。
基于P2P的云存储技术综合了云计算技术和对等网络技术的优点, 通过将所有的节点作为可控制的云端来提供公平的服务。它通过将不同的云端相互连接起来实现信息共享从而避免了传统云存储中存在的效率瓶颈和单点错误等问题。因此利用P2P技术实现的云存储服务采用高度可扩展的对等结构, 实现互联网范围内个人计算机的连接, 整合闲置的存储资源, 构建一个具有高性能、高可靠性和高服务质量的面向互联网的廉价分布式对等云存储服务系统。这个方式不仅节省了大量的成本、降低服务器的负载, 同时如果数据存储在你较近的节点的话, 也会较少延迟。
3 多云存储平台安全架构设计
基于HDFS存储系统虽然已经引入了多个安全机制, 但任然存在多个问题。首先, HDFS安全机制授权能力比较有限, 目前仅支持群组或ACL方式的授权, 这对很多需要进行角色授权的应用系统来说是不够的。其次, HDFS系统还未解决多云存储系统的认证问题, 即当用户在任何一个HDFS云存储系统上获得认证时, 他再去访问其他的信任HDFS集群上的数据是不需要重新进行认证。最后, 当前的HDFS的数据无论是存储还是传输都是没有加密的, 因此, 不能满足对Hadoop集群中的数据加密有严格安全要求的单位或机构。
针对当前HDFS在认证、授权以及集群单点登录上的安全方面存在的问题和改进空间, 提出基于令牌方式的安全架构, 如图2所示。其中HDFS客户端主要用于为用户提供接入HDFS服务的工具, 包括了操作文件系统的命令等。而令牌认证服务则主要用于通过调用不同的认证机制如LDAP或数据库等来认证用户, 同时颁发身份令牌给该用户;授权服务 (AS) 则是通过用户所提供的身份令牌结合对资源请求的粒度授予用户一个访问控制的令牌, 以作为访问某个具体服务时提供的授权依据。
将令牌技术应用到多云存储平台中, 解决了统一认证问题及HDFS客户端和数据端的认证问题, 保障了资源的安全访问。
4 多云存储平台快速检索架构设计
基于P2P与HDFS结合多云存储平台克服了云存储的中心控制和单点错误问题, 表现出较好的可靠性和可拓展性, 也使得在大规模且快速增长的互联网中以最少的代价来共享资源和应用成为可能。然而, 一个有效的多云存储系统不仅需要具备很好的资源存储能力, 同时要求需要具备有对大规模资源的快速检索能力。由于用户产生的数据多种多样, 这些数据具备有很多的属性, 因此如何快速有效的对这些数据进行检索是对多云存储平台的挑战。
图1中给出的架构利用的分布式哈希表技术Chord来提供跨不同云平台提供可拓展、负载均衡且稳定的分布架构。为了能实现资源的快速检索, 所有的资源都被映射成相关的整数并放置在Chord环中。因此对于精确的检索, 该系统可以快速的得到准确的结果。针对相似性搜索, 系统引入了局部敏感哈希 (LSH) [8]来对多特征的数据进行索引, 即任何资源或文档都被表示成为一个向量, 而该向量则被映射到Chord环的一个节点上。然后, 利用LSH技术将相似的向量映射到同个或相邻的Chord节点中。当用户进行查询时, 用户查询的请求也用一个向量来表示, 并通过映射找到该向量对于的Chord环上的节点, 最终在该节点及其领域内进行匹配查找。最终按照不同资源的表示向量的相似度来对查找到的资源进行排序返回检索的结果。
将LSH技术应用到基于P2P和HDFS的多云存储平台中, 实现了在大规模资源中快读进行准确、相似查找, 提高了多云系统的可用性, 提高了共享资源的利用率。
5 结论
基于P2P和HDFS多云存储服务的具有较强的安全性、稳定可靠且易于扩展, 可以被大中企业用来部署企业私有云的, 从而为企业提供一个多个云存储平台的资源共享方案。平台无须增加额外的硬件, 减少企业对数据备份硬件的投入。同时多云存储技术已经将用户的文件存储在接近用户端的节点, 这将提高企业应用系统的访问速度。基于P2P多云存储平台还可以进行改进并推广成为面向互联网大规模、高动态开放环境用户的开放P2P云存储服务系统, 并为互联网用户提供较高质量的云存储服务。
参考文献
[1]D.Krissi, “Distinguishing cloud computing from utility computing.”[Online].Available:http://www.ebizq.net/.
[2]Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung.The Google file system.In:Proc.of the 19th ACM SOSP.New York:ACM Press, 2003, 29~43.
[3]Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt, Andrew Warfield.Xen and the art of virtualization, In:Proc.of the nineteenth ACM symposium on Operating systems principles.Bolton Landing, NY, USA, 2003, 164-177.
[4]Kelly Sims.IBM introduces ready-to-use cloud computing collaboration services get clients started with cloud computing.http://www-03.ibm.com/press/us/en/pressrelease/22613.wss, 2011.
[5]Apache Hadoop.http://hadoop.apache.org/index.htm1, 2011.
[6]R.Schollmeier, “A definition of peer-to-peer networking for the classification of peer-to-peer architectures and applications, ”in Proceedings of the First International Conference on Peer-to-Peer Computing, P2P'01, (Washington, DC, USA) , pp.101-, IEEE Computer Society, 2001.
[7]Shvachko K, Kuang H, Radia S, et al.The hadoop distributed file system[C].Mass Storage Systems and Technologies (MSST) , 2010IEEE 26th Symposium on, Inclinevillage, Nevada:IEEE, 2010:1-10
信息存储与共享 篇3
分布式共享存储器 (Distributed Shared Memory—DSM) 作为分布式操作系统中的一个资源管理部件, 帮助没有物理上共享的存储器的分布式操作系统实现共享存储器模式。其原理就是在分布式系统中提供一个可供系统内所有节点共享的虚拟地址空间, 该虚拟地址空间可以被用户自由使用, 每一个节点都可以拥有存储在空间的数据, 以此类推, 可以利用多个节点存储非常多的数据, 当需要对共享地址空间中的数据进行访问时, 映像管理员就会把共享存储器地址变换为本地地址或远程的物理存储器地址, 是一种物理上分布、逻辑上共享的分布式共享存储器。
2 DSM设计与实现的相关问题
(1) 共享地址空间结构和粒度。地址空间可以是平面的、分段的和物理的。共享地址空间结构是指存储器中共享数据的布局方法。粒度指的是共享单元的大小, 一般是指字节、数据结构等。共享地址空间结构与粒度联系非常紧密。
(2) 缓存一致性协议。DSM经常出现缓存一致性问题。不同的协议有不同的假设, 选择协议依赖于存储器访问模式和支持环境。在写无效协议中, 一块共享数据可能有很多个只读副本, 但仅有一个可写副本, 每进行一次写时, 除了一个以外, 其他副本均变成无效。在写更新协议中, 每次写都要对所有副本进行更新。
(3) 可扩充性。DSM系统具有可扩充性。集中的瓶颈和全局公用信息的操作及存储是限制DSM系统可扩充性的两个重要因素。
(4) 数据定位和访问。在DSM系统中共享数据, 必须要先通过应用程序能找到相关的数据, 对数据进行定位。DSM系统是一个支持数据迁移的系统, 在数据定位和访问方面存在一定的困难。
(5) 同步原语。缓存一致性协议对于维持共享数据一致性具有一定的作用。但是, 还需要利用同步原语来对访问共享数据的活动进行同步, 这样才能够确保共享数据一致性。
(6) 异构性。系统结构不同的两台机器之间要能够实现数据共享是存在一定困难的。所以, 首先要解决异构性问题, 才能够实现分布式共享。
(7) 替换策略。分布式共享存储系统中的共享数据如果过多, 就会占满缓存器的有效空间, 如何将这些共享数据转移出去和放到哪里去也成了一大难题。
(8) 颠簸。DSM系统很容易就出现颠簸, 例如, 当两个节点对一个数据项同时进行写的过程中, 就可能产生以高速率来回传送数据的现象, 称之为乒乓效应, 这样就会使任何实际工作都不能进行。
3 实现DSM的算法
共享存储器模型为访问共享数据包含两个基本操作:data:=read (address) 和write (data, address) , 其中read是指返回由address指出的数据项, write是指把由地址address指出的内容设置为data。根据是否允许迁移或复制, 针对DSM设计与实现的相关问题, 可以提供中央服务员算法、迁移算法、读复制算法和全复制算法来解决这一问题, 具体如下所示:
(1) 中央服务员算法。中央服务员算法是指利用一个中央服务员来为所有对共享数据的访问提供服务并保持共享数据唯一的副本。读和写操作都包括由执行该操作的进程向中央服务员发送请求报文, 中央服务员执行请求并回答, 读操作时回答数据项, 写操作时回答一个承认。
(2) 迁移算法。迁移算法会将数据迁移到访问它的节点。实际上, 它就是一个“单读者/单写者” (SRSW) 协议, 确保在整个系统中一次只有一个进程读或写指定的数据项。
(3) 读复制算法。读复制算法是指对于一个当前不在本地的块中的一个数据项进行读操作时, 先与远程节点通信以获得那个块的一个只读副本, 然后再进行读操作。如果被执行写操作的数据所在的块不在本地或在本地但主机无写权时, 必须先使此块在其他节点的所有副本无效, 之后再进行写操作。
(4) 全复制算法。全复制算法允许数据块在进行写时也可以复制, 遵循“多读者/多写者” (MRMW) 协议。通过对所有的写操作进行全局排序可以实现保持复制数据一致性, 并且只是对与发生在执行读操作节点上的写操作相关的那些读操作进行排序。
4 结语
DSM系统与机密耦合的多机系统相比, 其具有性价比高、规模可扩充、兼容性良好等优点。本文分析了DSM系统设计与实现的相关问题, 研究了DSM的实现算法, 对于改善分布式共享系统的性能具有重要的作用。
摘要：目前, 分布式共享存储系统已经能够支持科学计算、Web服务器以及大型数据库管理等多种应用, 具有较好的可扩展性和较高的性价比, 同时也容易进行程序开发。文章对分布式共享存储系统的设计与实现进行了研究, 分析了DSM设计和实现问题, 论述了DSM的实现算法。
关键词：分布式,共享存储器系统,设计,实现
参考文献
[1]韩德志.网络存储技术及其进展[J].计算机应用研究, 2005 (7) :5-8
信息存储与共享 篇4
随着现代医学的发展, 医院诊疗工作越来越多地依赖现代化的检查结果。像X光检查、CT、MRI、超声、胃肠镜、血管造影等影像学检查的应用越来越普遍。在传统的医学影像系统中, 影像的存储介质是胶片、磁带等, 其耗材成本支出高, 存放、查找、借阅难, 且由于信息资源不能共享, 难以避免病人重复检查等问题, 使得病人检查费用居高不下。因此, 传统的医学影像管理已经无法适应新型医疗卫生服务的要求, 采用数字化影像管理方法来解决这些问题已迫在眉睫。目前, 虽然有部分医院已经开始对医疗影像的数字化管理, 在医院内部实现了这些资源的共享, 但跨院间的信息共享尚不能实现。
鉴于此, 区域PACS平台的业务建设将紧紧围绕“完善公共卫生和医疗服务体系、合理配置医疗卫生资源”的重点进行, 预期本项目实施后, 将达到以下效果:
从社会角度, 通过实现对医学影像检查设备资源的合理配置、整合与共享, 从而节省医疗资源的重复设置, 减少医疗设备投资浪费。通过率先在联网医院的范围内建立区域内居民“以人为本”的诊疗信息资料库, 为将来实现区域医疗信息化打下基础。另外, 通过减少对传统影像胶片的使用, 从而降低对环境的污染。
从病人角度, 实现在某一家医院进行过检验检查后, 即可在联网范围内的其它医院调阅到相关的影像图像和报告。从而避免病人在多家医院的重复检验检查, 降低医疗费用支出负担, 缓解“看病难、看病贵”矛盾。通过诊疗信息的交换共享, 方便就医者在某医院内以及联网医院范围跨医院的诊疗。
从临床医生角度, 实现对病人历史诊疗资料、医学影像检查资料的跨院调阅, 便于掌握病人病历和诊疗的整体情况, 为提高医疗服务的质量创造条件, 减少误诊或错诊的可能性。此外, 通过整体上把握病人的病史资料, 从而方便了对疑难病症实现专家会诊、实现对医学科学专题研究等提供有效信息和有利手段。
区域医疗信息交换共享在国内外受到了普遍关注, 国内各地纷纷出台了相应的建设项目和计划方案。国际上一些基于IHE解决方案的项目已经或者正在进行中, 从技术架构上理解这些项目对我国区域医疗信息共享交换有重要意义。
基于区域医疗共享的PACS用于将患者分布在各级医院中的诊疗信息、检验检查结果和医学影像进行基于国际IHE规范的共享交换和协同医疗。通过构造区域内部的医学影像信息交换平台, 以实现区域内医院的医学影像资源的共享与整合。此平台是卫生主管部门推动双向转诊和远程医疗的关键技术辅助手段, 可以有效地避免患者重复检查, 远程诊断咨询或者远程会诊, 远程教学和医学继续教育, 区域内部医学影像资源共享或者医院内部PACS系统的互联互通, 远程医学影像质量控制等。
该系统的研发和推广使用, 可以很大提高医院医疗技术水平, 实现高档设备, 优质医疗资源等信息共享和远程诊断等, 同时也会产生很大的社会效益和经济效益。
2 系统总体设计
根据影像图像和报告数据交换的特点及其功能需求, 影像数据中心系统架构设计遵循以下原则:
开放性。可与各医院异构PACS系统集成互联通信;可逐步将各级医院的影像纳入进行存储管理和应用。
标准化。遵循国际医疗影像信息共享技术架构框架文件IHE XDS–I;遵循医学影像通信标准D ICOM和其它相关医疗标准 (如HL7等) ;支持常用各类DICOM图像的共享交换和相应的通信传输语法。
可管理性。具有对所有共享影像进行中心注册管理功能;能对所有图像进行集中式存储备份。
安全性。在图像提交、传输和查询中提供数据私密性和完整性保护;符合DICOM有关数据通信安全性和使用可追踪性要求;系统具有容灾设计和快速灾难恢复能力。
根据以上原则, 通过研究集中分布系统架构具有的诸多优点, 完全适合区域共享的需求。采用集中分布系统架构能够:
(1) 集中与分布式相结合的架构, 合理利用了已有的医院资源, 同时又增加了数据的获取渠道, 平衡利用有限网络带宽资源;
(2) 影像数据中心系统的中心节点和医院节点自动互为备援数据在医院和中心异地备份;
(3) 在医院前置机正常工作的前提下, 整体架构将为分布式。
医院间共享数据尤其是医学影像的共享成为越来越迫切的需求。如图1所示, 显示了医学影像共享的一般需求:
影像仪器端传入各医院端PACS服务器中, 经过医院端前置服务器对影像进行数据匹配后, 定时通过DICOM通讯方式传到医学影像数据中心PACS应用服务器。中心端PACS应用服务器在收到影像资料的同时在数据库服务器中建立对应影像数据的索引, 在索引服务器中建立病人影像检查的索引。因此本共享系统主要分为中心PACS服务系统, 医院PACS系统, 和工作站系统。
(1) 区域PACS数据中心。建立一个影像数据中心, 连接区域内所有医院, 用于存储病人在就诊过程中所产生的所有文字信息和影像, 存储设备部署在中心医院。各医院生产的数据存储在本地, 同时, 为影像数据中心提供一个备份数据。
(2) 区域PACS信息共享与交换平台。建立一个区域PACS信息共享与交换平台, 采用Web方式发布到各个医院临床工作站, 可以与医院HIS或电子病历系统进行嵌入式集成, 方便医护人员使用。在该平台上, 医生可以完成会诊和转诊业务。同时, 也可以借助此平台实现患者在各医院之间的影像信息共享和调阅。
(3) 应用系统及接口。遵循IHE技术框架, 采用国际标准的HL7接口和DICOM接口与各相关系统进行通讯。区域PACS信息交换平台可支持多个接口组的方式, 每个接口组按照医院数据量的大小来确定连接一家或者多家医院, 避免由于数据量过大而对接口吞吐量造成影响。
建立影像业务患者个人唯一索引机制, 进而建立患者病案资料档案库。
(4) 共享流程
(1) 医院C工作站向数据中心搜索A医院PACS系统的病人数据;
(2) 中心服务器返回确认数据可用, 并返回数据列表;
(3) 医院C工作站根据列表直接请求A医院PACS系统取回病人的医学影像、报告等。
3 系统功能
3.1 中心PACS服务系统
中心PACS服务系统是区域共享系统的关键, 负责存储各医院PACS系统信息, 经过用户认证的医院工作站客户端可以通过WCF服务取得可访问的各医院PACS系统信息, 直接访问获取远程数据列表和DICOM影像。中心服务系统包括系统数据库信息管理、医院信息增删改管理、访问量统计、访问控制、用户认证、远程WCF获取访问量、WCF获取访问列表信息。中心PACS服务系统的层次方框图如图2所示。
3.2 医院PACS系统
医院PACS系统管理和存储了医院服务器的全局信息, 包括了设备管理、网关管理、工作站管理、用户管理、系统信息管理、DICOM上传请求监听、DICOM下载请求监听等。可以医院内部独立使用, 必要时与外部医院进行图像传输。
3.3 医生工作站系统
工作站系统是医生终端使用, 它提供了:DICOM影像获取模块, 主要有读取本地DICOM列表、读取远程DICOM列表、获取可访问医院列表、远程下载DICOM影像等功能;DICOM影像操作模块, 主要有图像旋转、图像放大、图像测量、图像灰度调节、图像亮度调节、放置各种标签等功能;诊断报告编写模块, 包括获取编写模板、保存报告到数据库等功能;工作站信息管理模块, 包括了各种模板管理 (如报告词条、报告标题、检查方法的管理) 、工作站系统配置 (如修改密码、数据库配置) 等功能。
3.4 主要功能模块
(1) 医院PACS信息管理模块
此模块是中心服务系统提供的进行各医院服务器信息的管理, 加入局域网共享的医院需要在这个中心服务器中登记, 增删改操作正确完整后点击保存按钮将一次性保存到数据库中, 并触发添加访问权限和记录访问量, 减少与数据库的交互。
(2) 医院访问控制模块
此模块主要实现各医院之间的访问控制, 通过设置访问权可以控制对其他医院是否可见, 从而实现访问控制。
(3) 设备管理模块
此模块是医院PACS系统提供对医院内各个相关网络设备的管理, 可以设置医院内网关、各科室影像上传设备、医生终端工作站等。
(4) DICOM请求侦听模块
DICOM请求侦听模块的设计使用DICOM标准中的SCP、SCU两个服务, 其中SCP是服务提供者, SCU是服务使用者。在模块设计中, 所要做的是在需要对远程图像进行获取的时候, 开启SCU服务, 查询远程服务端是否开启服务并进行验证, 验证成功后才发送接收图像的C-GET请求。而在需要将文件传输至远程客户端的时候, 则需要开启SCP服务来为远程客户端提供传输服务。接收的图像将存在本地指定目录中, 以方便医生的查看和诊断。
(5) DICOM列表获取模块
医生工作站可以获取本地DICOM影像列表, 和本医院可访问的其他医院的DICOM影像列表, 下载远程DICOM影像列表将调用中心服务器提供的WCF服务, 获取的可访问医院列表中包含了远程下载该医院DICOM影像列表的信息。
(6) DICOM远程下载模块
医生工作站可以通过SCP、SCU服务向医院PACS系统提供的DICOM图像进行远程接收。接收的图像将存在本地指定目录中, 以方便医生的查看和诊断。
(7) DICOM影像操作模块
此模块是医生工作端提供对图像处理以方便医生对图像进行更细致的查看和诊断, 其中包括了图像旋转、图像放大、图像锐化、测量长度、测量角度、调节灰度、放置各类标签, 以及设置显示窗口的数量。
(8) 诊断报告编辑模块
此模块是医生工作端提供医生对患者报告进行浏览、编写的功能。报告是医生对患者病情的描述, 是对患者诊断的重要依据。医生可以在允许的情况下下载患者在其他医院的诊断报告, 如果是在本医院的新检查, 可以编写对患者此次检查的报告, 以记录病情以及提供其他医院的医生查看。并且模块提供了各类报告编写模板, 增加医生工作效率, 医生也可以保存自己的模板。
4 结束语
笔者采用集中与分布式相结合的架构, 合理利用了已有的医院资源, 同时又增加了数据的获取渠道, 平衡利用有限网络带宽资源, 较好的解决了共享的问题, 在实际应用中取得了较好的效果。
参考文献
[1]石琳.以SOAP协议为基础的Web Service安全机制分析[J].科技致富向导, 2011, (30) .
[2]吕海燕, 李华伟, 车晓伟, 王丽娜.数据元注册方法研究与应用[J].电子设计工程, 2011, (19) .
[3]张冰波, 宋荣华.基于Web services的分布式信息检索机制的研究[J].软件导刊, 2011, (7) .
[4]罗爱静, 平静波.区域卫生信息化建设探讨[J].医学与哲学 (人文社会医学版) , 2011, (7) .
[5]伍枫, 胥悦雷.基于UDDI的服务注册中心的研究与优化[J].现代电子技术, 2011, (12) .
[6]李维, 陈祁.基于IHE PIX的MPI研究及其在医院的应用分析[J].医疗卫生装备, 2011, (6) .
[7]马文虎, 刘友华, 翟油华.基于IHE的医学影像信息系统集成研究与实现[J].信息技术与信息化, 2011, (2) .
[8]刘俊梅.医院信息系统的现状及其发展趋势[J].解放军护理杂志, 2011, (7) .
[9]宇文姝丽, 杨小平.电子病历存储模式研究[J].医学信息学杂志, 2011, (3) .
信息存储与共享 篇5
关键词：云存储,数据共享,身份代理重加密
1 云存储数据共享存在的主要安全性问题
云计算是一种对互联网上软硬件资源进行充分利用的新的计算模式。根据美国国家标准与技术研究院 (NIST) 的定义, 云计算是这样一种模式, 它提供对可配置的计算资源共享池进行可用的、便捷的、按需的网络访问。用户通过调用服务的方式使用这些资源, 包括网络、存储、服务器硬件、应用软件等, 并进行按需付费。随着互联网的发展, 信息量呈现爆炸式增长, 传统的数据存储方式已不能满足海量数据的存储需求, 以数据存储和管理为核心的云计算系统的延伸——云存储得到了广泛应用。现今, 各大云计算服务商, 如阿里云、七牛云存储、华为企业云等等, 基于存储即服务的理念为人们提供大量廉价的存储服务, 极大地方便了人们的使用。尽管如此, 这种公有云存储的数据存取方式的可信度仍然存在很大争议。从Twinstrata公司2012年最新的云存储的应用调查来看, 只有20%的人愿意将自己的私有数据放在云存储中。这种不安全感也不是无中生有的, 实际上全球多家云存储的服务提供商曾经遭遇过云存储安全的重大事故, 用户数据泄露事件层出不穷, 引发了严重的信任问题。并且, 当用户将他们在云端存储的数据进行共享时, 一般是通过对URL链接进行加密的方式, 恶意用户只要获得加密密码就可以获取数据, 因而存在安全隐患。
Kamara和Chow在其文献中指出, 客户端对需要存储在公有云中的数据进行加密是减轻用户对数据私密性顾虑的一个有效的对策。市场占有率极高的Amazon S3就提供了服务端和客户端两种类型的数据加密方式。开源云存储系统Seafile也提供对于不同文件夹进行加密的措施, 密码不会保存到服务器端。但是, 由客户端加密文件的方式需要用户保存密钥, 并且存在解密密钥的授权分发问题, 特别是针对群组用户分享密钥的难度很大。
2 已有解决方案的有效性分析
现有的技术解决方案主要有基于身份的加密访问控制和基于属性的加密访问控制方式。
2.1 基于身份加密算法概述
基于身份的公钥密码学是Shamir在1984年首次提出的, 但是第一个实用的基于身份公钥加密方案 (IBE) 由Boneh和Franklin在2001年研究得出, 并证明其在选择性明文攻击 (CPA) 下是安全的。基于身份的公钥密码学区别于传统PKI, 它提出的初衷是为了提供一种不需要部署认证中心CA和不需要使用公钥证书的公私钥密码方案, 用于加密数据和进行数字签名。在IBE的概念中, 每一个实体使用它唯一的身份信息作为公钥, 比如用户的电子邮件名称。实体要获取私钥, 需要用自己的公钥向系统内名为私钥生成中心 (PKG) 的机构进行申请。PKG保存主密钥, 用于生成实体的私钥, 并且实体的私钥与用户公钥信息是绑定的。
基于代理重加密最初由Blaze等在1998年提出, 它的工作原理是将由用户A的公钥加密的密文, 由一个重加密密钥加密, 转换为由用户B的公钥加密的密文, 这样用户B不能获取用户A的私钥, 而用自己的私钥解密。这在授权密钥分发中具有广泛应用。
Matthew Green和Giuseppe Ateniese在前人研究的代理重加密算法基础上, 对Boneh和Franklin的方案进行改进, 提出基于身份的代理重加密算法。陈康康在提出分层的云存储安全架构基础上, 针对跨域身份认证困难问题设计了三个安全的身份认证和参数交换协议, 并利用Matthew Green和Giuseppe Ateniese的基于身份加密方法在Hadoop云平台上设计了安全的数据共享机制。而Kaaniche详细划分了用户使用云存储的方式, 分别是个人数据存储、一对一分享数据和一对多分享数据, 每个用户都扮演了一个私钥生成器PKG的角色, 只对自己存储在云端的数据的安全性负责, 一定程度上解决了密钥托管的问题;但是针对一对多的分享方式只是提出利用基于身份的代理重加密机制, 并没有给出具体的实现方式, 并且数据是直接利用IBE公钥加密, 时间和存储代价很高, 加重了客户端的负担。
2.2 基于属性加密算法
Sahai和Waters在2005年提出基于属性的密码学概念, 是一种新的密文访问控制方式。加密密文由一系列属性作为标识, 用户要访问密文必须获得解密密钥, 由此需要提供满足门限参数个数的属性才能获取密钥, 并解密密文。Goyal等在2006年提出基于密钥策略的属性加密 (KP-ABE) , 随后, Bethencourt提出基于密文策略的属性加密机制 (CP-ABE) 。
由于其细粒度的访问控制方式, 基于属性的密码学被称为是管理云存储中文件共享的最具吸引力的方式之一。但是, 它也有一些弊端, 其中之一是存在固有的密钥托管问题。
3 构建基于身份代理重加密的文件共享机制
共享机制是建立在基于身份的代理重加密技术之上的。用户公钥能够包含属性信息或是表示不同的访问控制条件。譬如, 用户公钥的表示规则是“Alice||lawyer||from01/01/2010”, 用此公钥加密数据信息, 只有对方是Alice并且是一名律师, 还需要在2010年1月1日前才能向PKG获取私钥, 以解密数据信息。此方法可以应用到代理重加密授权规则中:代理负责分发重加密密文, 数据的拥有者指定代理在满足一定条件的情况下才能为数据共享者分发重加密密文。譬如, 重加密密钥表示规则是“”, 则代理只能让Bob在2007年11月后, 并且在满足安全状态情况下才能获取重加密密文。按此思路, 我们还可以将此方法应用到群组加密共享环境中, 重加密密钥包含指定的群组信息, 并且可以指定群组中特定用户。这样, 数据分享的控制权掌握在用户和代理手中, 支持群组和特定条件下的重加密密文的分发策略, 增强了代理重加密的安全性, 扩充了其使用范围。
3.1 基于身份的代理重加密实施步骤
3.2 基于身份代理重加密的云存储文件共享流程
总体通信过程如下图所示:
1) 发送方:用户使用云存储时先进行注册, 然后本地客户端生成AES密钥。密钥的生成可以采用多种方式, 此处利用文件的哈希值SHA-256作为AES密钥, 同时可以检验文件完整性。用户在本地用AES密钥对文件进行加密, 上传至云存储端指定位置。当然, 此处只是采取最简单的方式, 为了更大程度地增强安全性, 针对不同用户组的加密文件应当采用不同强度方式生成的加密密钥。
用户指定分享文件的用户角色, 这里使用用户组代替。设计用户身份的表示规则:
其中, depositor字段标识数据发送方;IDdata标识分享文件的元数据信息, 上传文件后通过访问云存储端API获得;group name字段标识共享数据的群组名称, specified time字段标识特定时间。客户端发送用户身份信息给私钥生成中心即PKG, 请求获取IBE私钥1;客户端用公钥1加密AES密钥, 用获得的私钥1生成重加密密钥;将加密的AES密钥, 重加密密钥和公钥1上传到代理服务器指定目录, 同时指定群组中的一个用户集。
2) 代理服务器:群组用户登录云存储访问界面, 并从云端取得加密文件和文件元数据信息, 但是此时并不能解密, 因为密钥由代理服务器负责分发。由此, 用户向代理服务器提出获取解密密文的请求, 上传有关访问控制信息与预解密文件的元数据信息。代理服务器检查用户访问信息, 确定用户的群组标识是否正确, 用户是否是群组内所指明获得文件的用户, 确定进行解密的文件元数据是否与发送方上传的一致, 并检查密钥的取得是否在文件发送方公钥所指明的时间范围内。所有条件都符合后, 代理服务器提取重加密密钥和被加密的AES密钥, 执行重加密算法加密AES密钥信息, 生成重加密密文, 发送给群组用户即文件共享方。
3) 文件共享方:共享者向PKG请求获取IBE私钥2, 用私钥2解密重加密密文, 得到AES密钥, 从而才能解密加密文件, 获取数据。
3.3 共享机制的增强安全性分析
本方案所应用的基于身份代理重加密技术的安全性是建立在解决双线性D-H困难问题基础上, 并证明在标准模型下具有选择明文安全性。通过对用户公钥的重新构造, 发送方实际上对于每一次上传的加密文件的对称密钥都使用了不同的公钥进行加密, 这样即使非法用户获得重加密密文, 也只能解密一次上传的加密文件, 并不会影响其他的加密文件;通过指定共享文件的群组并选择群组内指定用户, 增强文件共享的私密性和针对性;文件所有权虽然在云存储端, 但解密控制权掌握在用户手中, 云存储端并不能获取解密密钥, 增加了文件存储与共享的安全性;代理服务器授权解密密钥的分发, 发送方可以不用在线分发解密密钥, 减轻了数据发送方的负担。
4 结束语
基于身份代理重加密方案, 重新构建用户公钥表示规则, 包含时间、文件元数据信息和用户组信息, 用户可以指定用户组中的用户集, 约束代理服务器在被分享方满足条件的情况下, 才能分发重加密密文, 限制了分享方获取解密密钥的有效性条件, 进一步增强了数据共享的安全性。
参考文献
[1]傅颖勋, 罗圣美, 舒继武.安全云存储系统与关键技术综述[J].计算机研究与发展, 2013, 50 (1) :136-145.
[2]Kamara S, Lauter K.Cryptographic cloud storage[C]//International Conference on Financial Cryptography and Data Security.Springer Berlin Heidelberg, 2010:136-149.
[3]Chow R, Golle P, Jakobsson M, et al.Controlling data in the cloud:outsourcing computation without outsourcing control[C]//Proceedings of the 2009 ACM workshop on Cloud computing security.ACM, 2009:85-90.
[4]Shamir A.Identity-based cryptosystems and signature schemes[C]//Workshop on the Theory and Application of Cryptographic Techniques.Springer Berlin Heidelberg, 1984:47-53.
[5]Boneh D, Franklin M.Identity-based encryption from the Weil pairing[C]//Annual International Cryptology Conference.Springer Berlin Heidelberg, 2001:213-229.
[6]Green M, Ateniese G.Identity-based proxy reencryption[C]//Applied Cryptography and Network Security.Springer Berlin Heidelberg, 2007:288-306.
[7]陈康康.面向云存储的身份认证机制和数据共享方法的研究[D].北京邮电大学, 2015.