碧海分布式存储和Ceph的对比

碧海分布式存储系统是依托于国内百年学府上海交通大学海量存储与安全实验室自主研发的分布式存储系统,起源于 2010年上海市科委“PB 级海量存储系统”重大项目。软件使用 C++语言编写,代码约 35 万行。
Ceph 是开源软件,目前由 Redhat 公司维护。使用 C++语言,代码逾百万行。国内公司的分布式软件定义存储产品大多都基于 Ceph。开源 Ceph 本身复杂性极高,存储厂商很难吃透并彻底掌握,通常只是跟随社区主导者的步伐发展,没有真正的核心技术,均面临如技术更新慢、稳定性不足、产品维护难等各种挑战;另外,开源模式并不意味着免费或低成本,往往导致更高的后期运维成本。
Ceph 在存储节点上为每块磁盘创建一个 OSD 进程,每个进程内多达 80 个线程,共有几百个线程,非常消耗 CPU 和内存资源,导致 IOPS 性能比较低。
碧海存储系统使用事件驱动模型,每个 CPU 启动一个 IO 进程,避免了进程/线程在 CPU 之间调度的开销。对 CPU 和内存要求低,性能更高。碧海分布式存储的 IOPS 性能达到业内领先水平,性能高于 EMC Scaleio、VMWare vSAN,是 Ceph 类产品所不具备的。
经实际测试,在硬件配置相同、存储介质为 SSD 时,碧海存储系统 IOPS 性能指标是 Ceph 的3 倍,而且 CPU 和内存开销更少。
对于碧海存储系统性能优化和稳定性的部分技术原理,可以参考学术报告:分布式存储系统的一些关键问题(https://mp.weixin.qq.com/s/OyGH9qTajcq0o4nsQPI63g)。

bind9+namedmanager实现内网DNS UI界面管理

1、操作系统:centos7.9+bind9+mariadb+namedmanager-v1.9.o

2、修改yum源

cd /etc/yum.repos.d/

vim jethrocarr-c7-public.repo

# CentOS / RHEL 7 Repositories
#
# www.jethrocarr.com
#

# Packages of third party software that extend the OS and won't replace any
# standard OS or EPEL packages. Generally these are always safe to install
# since they won't override anything else that is present on a system if you're
# only using stock repos.
#
# Some of these packages may require packages in jethrocarr-updates.
[jethrocarr-os]
name=jethrocarr-os
baseurl=https://repos.jethrocarr.com/pub/jethrocarr/linux/centos/7/jethrocarr-os/$basearch/
gpgcheck=1
gpgkey=https://repos.jethrocarr.com/jethrocarr_signing_key.gpg
enabled=1

# Provides upgrades to packages included in the distribution (eg: PHP or the
# kernel). These packages could potentially break other applications you have
# installed onto your computer. Some of these packages may require packages
# in jethrocarr-os.
[jethrocarr-updates]
name=jethrocarr-updates
baseurl=https://repos.jethrocarr.com/pub/jethrocarr/linux/centos/7/jethrocarr-updates/$basearch/
gpgcheck=1
gpgkey=https://repos.jethrocarr.com/jethrocarr_signing_key.gpg
enabled=1

# All RPMs developed by Jethro Carr are located in this repository. Some of
# these programs may require packages in jethrocarr-os or jethrocarr-updates
# in order to install and run
[jethrocarr-custom]
name=jethrocarr-custom
baseurl=https://repos.jethrocarr.com/pub/jethrocarr/linux/centos/7/jethrocarr-custom/$basearch/
gpgcheck=1
gpgkey=https://repos.jethrocarr.com/jethrocarr_signing_key.gpg
enabled=1

3、安装软件包

yum install -y namedmanager-www namedmanager-bind bind-chroot

4、修改配置文件named.conf

vim /etc/named.conf
******************************************************************************************************
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
// See the BIND Administrator's Reference Manual (ARM) for details about the
// configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html
options {
listen-on port 53 { any; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
recursing-file "/var/named/data/named.recursing";
secroots-file "/var/named/data/named.secroots";
allow-query { any; };
/* 
- If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
- If you are building a RECURSIVE (caching) DNS server, you need to enable 
recursion. 
- If your recursive DNS server has a public IP address, you MUST enable access 
control to limit queries to your legitimate users. Failing to do so will
cause your server to become part of large scale DNS amplification 
attacks. Implementing BCP38 within your network would greatly
reduce such attack surface 
*/
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.root.key";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
include "/etc/named.namedmanager.conf";
*********************************************************************
chown named.root /etc/named.namedmanager.conf
chkconfig --level 35 namedmanager_logpush on

5、配置数据库

systemctl start mariadb
mysqladmin -u root password 123456
/usr/share/namedmanager/resources/autoinstall.pl

6、修改config-bind.php配置文件

vim /etc/namedmanager/config-bind.php
******************************************************************************************************
<?php
/*
Sample Configuration File
Copy this file to config-settings.php
This file should be read-only to the user whom the bind configuration scripts are running as.
*/

/*
API Configuration
*/
$config["api_url"] = "http://192.168.5.137/namedmanager"; // Application Install Location
$config["api_server_name"] = "dns.myd.com"; // Name of the DNS server (important: part of the authentication process)
$config["api_auth_key"] = "dns"; // API authentication key

/*
Log file to find messages from Named. Note that:
* File should be in syslog format
* Named Manager uses tail -f to read it, this can break with logrotate - make sure that either "copytruncate" mode is used, or tail processes are killed
*/
$config["log_file"] = "/var/log/messages";

/*
Lock File
Used to prevent clashes when multiple instances are accidently run.
*/
$config["lock_file"] = "/var/lock/namedmanager_lock";


/*
Bind Configuration Files
Theses files define what files that NamedManager will write to. By design, NamedManager does
not write directly into the master named configuration file, but instead into a seporate file
that gets included - which allows custom configuration and zones to be easily added without
worries of them being over written by NamedManager.

*/
$config["bind"]["version"] = "9"; // version of bind (currently only 9 is supported, although others may work)
$config["bind"]["reload"] = "/usr/sbin/rndc reload"; // command to reload bind config & zonefiles
$config["bind"]["config"] = "/etc/named.namedmanager.conf"; // configuration file to write bind config too
$config["bind"]["zonefiledir"] = "/var/named/"; // directory to write zonefiles too
// note: if using chroot bind, will often be /var/named/chroot/var/named/
$config["bind"]["verify_zone"] = "/usr/sbin/named-checkzone"; // Used to verify each generated zonefile as OK
$config["bind"]["verify_config"] = "/usr/sbin/named-checkconf"; // Used to verify generated NamedManager configuration

/*
Unusual Compatibility Options
*/
// Include a full path to the zonefiles in Bind - useful if Bind lacks a
// directory configuration or you really, really to store you zonefiles
// in a different location
//
// $config["bind"]["zonefullpath"] = "on";

// force debugging on for all users + scripts
// (note: debugging can be enabled on a per-user basis by an admin via the web interface)
//$_SESSION["user"]["debug"] = "on";

?>
****************************************************************************

7、启动服务

systemctl start named
systemctl start httpd
hostnamectl set-hostname dns.myd.com

8、修改配置php.ini

将php.ini文件中的error_reporting = E_ALL改写成error_reporting = E_ALL & ~E_NOTICE(该方法关闭了PHP的提示功能)

9、修改apache配置

# vi /etc/httpd/conf/httpd.conf
# 这里将 ServerName 改为 192.168.65.123(修改成自己主机的IP地址或者域名)
   ServerName 192.168.65.123


  <Directory />
     AllowOverride none
     #    Require all denied
  </Directory>

# vi /etc/httpd/conf.d/namedmanager.conf   
  Alias /namedmanager /usr/share/namedmanager/htdocs

  <Location /namedmanager>
        Order allow,deny
        Allow from all
        AllowOverride None
        Require all granted

  </Location>

10、登录界面配置DNS服务器

web登录http://192.168.65.123/namedmanager/ 默认账号密码setup/setup123

PACS影像存储技术专刊

一、医疗PACS影像的现状和挑战

  • 数据增长迅速,PACS调图卡顿成常态

医疗影像检查技术发展日新月异,设备分辨率越来越高。CT检查设备从早期的64排已经发展到256排;人工智能辅助诊断推广泛使用,扫描切层厚度从5mm 减小到0.5mm。这些因素使得患者每次检查的数据量大幅增加。 10年前,一位患者检查产生的CT图像大约几百张,数据量不到100MB;目前患者一次检查产生的图像数量增长到3000幅以上,数据量达到1GB。和10年前相比,患者一次检查产生的数据量增长到10倍以上。

这些因素使得PACS影像数据量急速增加,每年增长高达30%以上。

不断增长的数据量加剧了PACS系统的调图压力,医生调图越来越卡顿,一次调图长达2~3分钟成为常态,严重影响了医生的工作效率。

在大多数场景下,PACS系统的调图性能瓶颈主要在于存储设备,而不在于PACS软件。目前普遍30~50幅/秒的调图速度就是传统存储设备的正常性能。

使用SAN存储设备时,承担数据管理功能的文件系统运行在Windows 服务器上,该服务器往往会成为性能瓶颈,大幅增加该服务器的内存会改善性能。

  • 存储架构复杂,运维工作繁重

为了解决PACS影像调图性能的问题,业界采取的基本思路都是把存储分为在线、近线、离线三层。在线存储通常为FC-SAN存储,只保存最近几个月的热数据;近线存储用中低端NAS存储,离线存储使用磁盘库或光盘塔。

SAN存储设备扩容困难,需要划分很多逻辑卷。使用小的逻辑卷,数据风险小,但盘符数量多,而Windows 服务器对盘符数量又有限制;使用大的逻辑卷,盘符数量少,但是数据安全风险大,一旦发生文件系统损坏,检查修复时间会长达几周。 传统存储设备的扩展能力有限,医院需要不断购买新的存储设备,需要不断做数据迁移,存储架构复杂,运维负担繁重。

二、PACS系统性能瓶颈分析

PACS系统涉及多个环节,包括PACS软件、医生端电脑、网络、存储设备,它们都对调图性能有重要影响。

  • PACS软件

本文不关注PACS软件的核心功能,只从PACS软件调图性能角度分析。PACS软件的并发度对调图性能有很大影响。比如,用4个线程同时调取4个图像文件,其性能就是1线程方式的4倍!

有一些旧版本PACS软件是单线程模式,这时PACS软件就是系统的主要性能瓶颈。对于这种场景,升级PACS软件就成为必须要做的工作。

PACS数据库也是影响性能的重要因素,其记录条数可能高达几十亿条,使用SSD全闪存储和数据库访问优化是提升性能的重要途经。

  • 医生端电脑

医生端电脑硬件配置对PACS调图性能也有一定影响。如果启用了AI辅助分析,则CPU/GPU的配置对性能就很关键。

由于每位患者的PACS影像数据量都比较大,无法全部存储在内存,因此PACS软件都会把下载的PACS文件先写入本地硬盘,再从本地硬盘读取,本地盘的读写性能往往会成为瓶颈。

医生端电脑使用SSD固态盘会显著提升性能。

  • 网络宽带

从网络角度看,只要做到千兆到桌面,万兆到核心,网络就不会成为性能瓶颈。

PACS服务器到网络存储设备之间数据流量比较大,应使用万兆以太网,而不是千兆以太网,否则网络也会成为性能瓶颈。

  • 存储设备

在大多数场景下,PACS系统的调图性能瓶颈主要在于存储设备,而不在于PACS软件。目前普遍30~50幅/秒的调图速度就是传统存储设备的正常性能。

使用SAN存储设备时,承担数据管理功能的文件系统运行在Windows 服务器上,该服务器往往会成为性能瓶颈,大幅增加该服务器的内存会改善性能。

三、传统集中式存储是否适用于PACS影像?

传统SAN/NAS存储的硬件架构采用“控制器+硬盘柜”的方式。中高端存储支持多个控制器,以保障高可用并提高性能。多控制器为紧耦合,通过PCIE总线或Infiniband网络互连,共享磁盘阵列,共享缓存。

可以看出,传统存储的NAS服务器、控制器和磁盘柜是串联结构。NAS服务器是单点性能瓶颈,当文件数量增多时CPU、内存和I/O吞吐能力成为瓶颈,性能必然下降。虽然可以通过增加磁盘柜扩展容量,但由于不同磁盘柜为串联结构,无法并发访问,以及NAS机头的瓶颈限制,性能随容量扩展而下降。

四、医疗PACS影像数据是否适合上云?

大型三级医院中HIS系统每年新增的数据量为 100G左右,PACS影像系统每年新增的数据量为80T左右,是HIS系统数据量的800倍!国家法规要求医疗电子病历保存30年以上,医疗影像数据保存15年以上。PACS影像数据占医院信息化数据总量的80%以上。

医疗PACS影像数据占比达到80%

随着互联网医院以及云PACS胶片的推广应用,医院信息化部门也自然而然产生了这样的想法:能否将PACS影像数据也上公有云?一劳永逸地解决PACS影像数据的存储难题?以下将从业务性能需求、成本、业界实践角度探讨该问题。

  • 网络带宽与延迟

PACS影像数据量很大,属于高带宽应用。在医院内部,网络带宽可得到充分保证,各个大楼都通过独立的万兆以太网链路接入医院信息中心;但当访问公有云存储时,医院到公有云的网络带宽只有千兆,而且全院的医生共享这一条网络链路。

使用公有云存储之后,网络延迟会加大。医院内部访问数据中心存储设备的延迟为1~3ms,访问公有云存储的延迟为10~100ms。

使用公有云存储之后,医院和公有云存储之间的网络带宽和延迟会成为性能瓶颈,严重制约PACS系统的性能。

因此,从医院业务系统的性能需求角度看,将在线/近线PACS影像数据(热数据)上公有云是缺乏可行性的。但将离线PACS影像数据(冷数据)备份到公有云存储,则另当别论,可以探讨。

  • 成本        

对于医院的HIS等业务,数据量小,产生的网络流量也小,因此上公有云后网络流量费用带来的成本可以忽略,但对于PACS影像业务,却需要慎重评估流量费用。PACS影像一次访问需要读取500MB的数据量,一次检查产生的数据,会被影像科初审、复审、门诊、人工智能训练等多次读取,一般是写入一次,读取6~7次。众所周知,经营网络流量是云厂商利润的主要来源之一。PACS影像上公有云,医院不仅要支付网络带宽租赁费,还要支付数据访问的流量费。

云厂商能够通过分时复用的机制提高计算服务器的设备利用率,从而有效降低云主机的成本。但对于云存储,却并没有类似的机制能够有效降低后端存储设备的成本。用户需要为存储在云端的数据每年都支付费用,从长期来看,用户支付的总成本“可能”会高于本地存储方式。

  • 业界实践

医疗影像数据是否“上云”,需要根据医院自身需求和规划来定,也不能一概而论。

对于二级医院或社区医院,将PACS影像数据上云,或者上区域影像中心,能够解决中小医院有设备拍片但没有能力诊断的问题。这些场景业务量不大,通过云端共享,获得更多医疗领域内的专家、学者和上级医院的支持,让患者就近诊疗、提升医疗体系服务能力。 对于业务量较大的三级医院,将在线/近线PACS影像数据(热数据)上云在技术和成本层面缺乏可行性。至于将离线PACS影像数据(冷数据)备份到云端的方案,则需要全面核算长期存储的成本,与蓝光存储等可选方案比较后决策。

五、超融合是否适合做PACS影像存储?

超融合中也包括分布式存储,它和其它分布式文件/对象存储有什么区别?它能够做为PACS影像存储吗?很多用户都有这个疑问,以下将回答这个问题。

  • 超融合架构

首先从定义来看:超融合基础架构(hyper-converged infrastructure,简称HCI)是一个基于软件定义的 IT 基础架构。HCI运行在标准X86服务器之上,功能组件包含:虚拟化计算(hypervisor),分布式存储(SDS:软件定义存储)和虚拟网络。

超融合中的分布式存储,通常为分布式块存储
  • 超融合中文件存储的实现方式

超融合平台实现的是分布式块存储,主要功能是给虚拟机提供云硬盘,作为操作系统安装盘或数据盘。当HCI平台创建很多个虚拟机时,就需要创建很多个云硬盘。每个云硬盘的存储空间分布在多个X86服务器的所有硬盘上,因此单个云硬盘具有高于传统RAID阵列的性能。

如果要基于超融合平台对外提供文件服务,常用的方法是:

(1)   创建一个大容量的云硬盘;

(2)   将云硬盘挂载到一个虚拟机;

(3)   在这个虚拟机上启动文件服务,作为NAS网关,对外提供服务。

  • 超融合中文件存储的局限

首先,虽然超融合的底层块存储空间是分布式的,但承担数据管理功能的NAS网关是单点性能瓶颈。这种架构适用于管理少量数据,比如数据量不超过10TB,文件数量在百万级的场景,但这种架构无法管理更大规模的PACS海量文件,其性能和可靠性也存在风险。

其次,从产品的定位看,超融合要兼顾计算和存储,每个节点中配置的CPU和内存比较高,但磁盘数量比较少;而海量数据存储需要更多的硬盘数量,但对CPU和内存要求比较低,因此将超融合用于海量数据存储也是不经济的。

六、分布式存储是否适用于PACS影像?

  • 分布式软件定义存储的架构

分布式软件定义存储(SDS: Software Defined Storage)的底层硬件架构,和超融合相同,都采用“标准的x86服务器硬件+存储软件”的架构,将标准X86服务器通过高速以太网互连,通过分布式存储软件将服务器组织成统一的大规模存储资源池。

分布式存储有效解决了传统集中式存储的可扩展性问题,规模可扩展至上百上千个节点,容量扩展到上百PB甚至EB级。

  • 纠删码与多副本

分布式存储使用多副本和纠删码技术实现数据保护。多副本方式(业界常用的多副本方式一般为2副本或3副本),其优点是可靠性高,性能高;但缺点是存储容量有效利用率低(2副本为50%,3副本为33%)。业界常用的纠删码配置方式一般为8+4(8个数据块,4个校验块,容量利用率为66%)。纠删码的优点是可靠性高,容量利用率高,缺点是性能低。

一般选择原则是:

  • 在线存储设备用多副本;备份归档用纠删码;
  • 小文件用多副本;大文件用纠删码。
  • 适合做PACS影像存储吗?

    分布式存储产品的硬件架构基本是相同的,存储软件决定了存储系统的性能。分布式存储的其性能并不一定高于传统集中式存储,需要针对不同的业务场景和产品进行具体分析。

    从目前业界实践看, 基于开源存储软件Ceph改造的分布式存储产品在PACS场景中性能低于传统集中式存储,可以作为PACS影像系统的近线或归档存储,但不适宜作为在线存储使用。

七、碧海分布式存储,解决PACS影像性能痛点

  • 碧海分布式存储的技术优势

上海霄云信息科技是国内软件定义分布式存储的引领者,为医疗PACS影像带来了革新的数据存储解决方案。

自主研发的碧海分布式存储系统,采用一系列创新技术,突破了传统集中式存储的性能和容量瓶颈;针对PACS影像的海量小文件特征进行深度优化,彻底解决PACS影像数据存储的挑战:

  1. PACS影像调图速度提高到300幅/秒!提升3~10倍!
  2. 1000幅的CT图像,只需要4秒就可以调取完成!调图再也不卡顿!
  3. 只需一套存储,数据全部在线高速调取,再也不要做数据迁移了!
  4. 很多医生电脑同时访问时会不会变慢?
    • 碧海存储可以支持高达10000个并发连接,小文件读取总吞吐率超过1GB/s,可以保证医院工作高峰期间几百台电脑同时高速调阅;
  5. 以后数据量增多时会不会变慢?
    • 大型3甲医院每年生产的PACS文件数为2亿左右。碧海存储写入100亿文件,读写性能衰减小于10%!     

碧海分布式存储系统不仅支持块/文件/对象存储功能,性能上显著优于传统集中式SAN和NAS存储,也高于其它知名高端集群存储,性能达到国际领先水平。

碧海分布式存储通过万兆以太网接入数据中心,现有网络架构无需调整。碧海分布式存储所有功能都采用冗余设计,避免单点故障,保证高可用。具有独有的智能自适应修复技术,在磁盘发生故障进行数据修复时可以保障业务性能不受影响。

  • 碧海分布式存储是如何实现高性能的呢?
  1. 分布式元数据管理

碧海分布式存储使用基于分布式架构管理文件元数据,所有的文件数据和元数据管理都是分布式的,均衡分布在所有的x86服务器上,因此不存在单点性能瓶颈,性能更好,可扩展性和可靠性更高;可管理文件数量达到百亿级以上(对于PACS影像数据,100TB对应的文件数量约为2亿。目前国内大型三甲医院的历史PACS影像数据一般在500TB左右,文件数约为10亿)。

  1. 针对PACS海量小文件的定制优化

碧海分布式存储针对PACS小文件进行了深度定制优化,减少了小文件元数据规模,对于PACS影像等小文件场景,文件数可压缩到1/100;将小文件的读写合并后写盘,大幅提高了小文件读写性能。

  1. 高效SSD缓存设计

传统的SAN/NAS的SSD缓存方式在块设备底层实现,无法获得文件层的信息,比如哪些内容是目录,哪些是文件元数据inode等,只有当数据被反复多次访问时才会保持在SSD中,因此SSD缓存的命中率比较低。

碧海分布式存储系统在系统架构设计中融入了SSD缓存设计,将目录数据、文件元数据、热点数据全部保持在SSD中,大幅提高了SSD缓存的命中率,从而能够在节省成本的前提下大幅提高读写性能。

  1. 对象和文件互通访问,性能无衰减

碧海分布式存储的底层使用统一方式管理数据,文件和对象无需转换网关就能够互通访问,对象的读写性能和文件一样优异,突破了对象存储性能低的局限。

  1. 自适应数据修复

具有创新的智能自适应修复技术,能够根据业务负载情况自动调整数据修复速率,能够保障业务性能不受影响,而且能尽快修复故障磁盘的数据,保障数据安全性。

  • 实践案例

上海市胸科医院是国内最大的胸外科三甲医院,所有的检查诊断都需要拍片,PACS系统的数据量的调阅性能要求高于很多综合性大型三甲医院,每年新增PACS数据量压缩后达到80TB,历史PACS数据总量超过500TB。

由于检查数量增多,调图性能问题日益突出,影像科复核医生在阅片时会发生卡顿。

为了解决PACS调图性能问题,院方不断研究探索新的技术解决方案。在2019年经过长达1年的测试评估之后引入碧海分布式存储,PACS软件也做了相应优化提升并发数,新的方案获得显著提升效果:调图速度达到300幅/秒,1000幅的CT图像可在4秒内调阅完毕。影像科复核医生每天审核的报告数提升了50%。

2021年4月,权威第三方测评机构在医院影像科现场对PACS影像调图性能进行了评测,结果如下:

新的PACS影像存储方案具有如下优势:

  • 大幅提高了PACS调图性能,超越国际高端SAN存储;
  • 实现了一套存储数据全部在线,历史影像数据也可以实时调阅,显著提升了医生工作效率和患者体验;
  • 新的存储架构也有力支撑了新业务的拓展,包括AI辅助阅片和云胶片等。新业务上线后,放射科医生调图的性能未受影响。 

关于案例的更具体的内容,可参考 CHIMA大讲堂第57期: 赋能PACS影像存储建设研讨会。 https://djt.chima.org.cn/lecture/3082660