Author Archives: 陈明

Ceph 源代码目录结构详解(转载自:6沙鱼的博客)

从GitHub上Clone的Ceph项目,其目录下主要文件夹和文件的内容为: 
1 根目录 
[src]:各功能某块的源代码 
[qa]:各个模块的功能测试(测试脚本和测试代码) 
[wireshark]:#wireshark的ceph插件。 
[admin]:管理工具,用于架设文档服务器等 
[debian]:用于制作debian(Ubuntu)安装包的相关脚本和文件

[doc]:用于生成项目文档,生成结果参考http://ceph.com/docs/master/ 
[man]:ceph各命令行工具的man文件 
configure.ac:用于生成configure的脚本 
Makefile.am:用于生成Makefile的脚本 
autogen.sh:负责生成configure。 
do_autogen.sh:生成configure的脚本,实际上通过调用autogen.sh实现 
ceph.spec.in:RPM包制作文件

2 src目录

[include]:头文件,包含各种基本类型的定义,简单通用功能等。 
[common]:共有模块,包含各类共有机制的实现,例如线程池、管理端口、节流阀等。 
[log]:日志模块,主要负责记录本地log信息(默认/var/log/ceph/目录) 
[global]:全局模块,主要是声明和初始化各类全局变量(全局上下文)、构建驻留进程、信号处理等。 
[auth]:授权模块,实现了三方认知机制。 
[crush]:Crush模块,Ceph的数据分布算法 
[msg]:消息通讯模块,包括用于定义通讯功能的抽象类Messenger以及目前的实现SimpleMessager 
[messages]:消息模块,定义了Ceph各节点之间消息通讯中用到的消息类型。 
[os]:对象(Object Store)模块,用于实现本地的对象存储功能, 
[osdc]:OSD客户端(OSD Client),封装了各类访问OSD的方法。 
[mon]:mon模块 
[osd]:osd部分 
[mds]:mds模块 
[rgw]:rgw模块的 
[librados]:rados库模块的代码 
[librdb]:libbd库模块的代码 
[client]:client模块,实现了用户态的CephFS客户端 
[mount]:mount模块 
[tools]:各类工具 
[test]:单元测试 
[perfglue]:与性能优化相关的源代码 
[json_spirit]:外部项目json_spirit 
[leveldb]:外部项目leveldb from google 
[gtest]:gtest单元测试框架 
[doc]:关于代码的一些说明文档 
[bash_completion]:部分bash脚本的实现 
[pybind]:python的包装器 
[script]:各种python脚本 
[upstart]:各种配置文件

ceph_mds.cc:驻留程序mds 
ceph_mon.cc:驻留程序mon 
ceph_osd.cc:驻留程序osd 
libcephfs.cc:cephfs库 
librdb.cc:rdb库 
ceph_authtool.cc:工具ceph_authtool 
ceph_conf.cc:工具ceph_conf 
ceph_fuse.cc:工具ceph_fuse 
ceph_syn.cc:工具ceph_syn 
cephfs.cc:工具cephfs 
crushtool.cc:工具crushtool 
dupstore.cc:工具dupstore 
librados-config.cc:rados库配置工具 
monmaptool.cc:工具monmap 
osdmaptool.cc:工具osdmap 
psim.cc:工具psim 
rados.cc:工具rados 
rdb.cc:工具rdb 
rados_export.cc:rados工具相关类 
rados_import.cc:rados工具相关类 
rados_sync.cc:rados工具相关类 
rados_sync.h:rados工具相关类 
sample.ceph.conf:配置文件样例 
ceph.conf.twoosds:配置文件样例 
Makefile.am:makefile的源文件 
valgrind.supp:内存检查工具valgrind的配置文件 
init-ceph.in:启动和停止ceph的脚本 
mkcephfs.in:cephfs部署脚本

明和文化

杭州明和科技股份有限公司

愿景

明和,致力于IT基础架构的云计算公司。

 使命

以客户需求为核心,聚焦客户关注的挑战和压力,提供有竞争力的信息产品和服务,保护客户投资,持续为客户创造最大价值。

 核心价值观

公司核心价值观是扎根于我们内心深处的核心信念,是我们面向未来的共同承诺。她确保我们步调一致地为客户提供有效的服务,实现“IT基础架构的云计算公司”的愿景。

201202161059121307

成就客户

为客户服务是明和存在的唯一理由,客户需求是明和发展的原动力。我们坚持以客户为中心,快速响应客户需求,持续为客户创造长期价值进而成就客户。为客户提供有效服务,是我们工作的方向和价值评价的标尺,成就客户就是成就我们自己。

诚实守信

我们只有内心坦荡诚恳,才能言出必行,信守承诺。诚信是我们最重要的无形资产,明和坚持以诚信赢得客户。公司没有诚信,所有的进取都将失去意义。

艰苦奋斗

我们唯有艰苦奋斗才能赢得客户的尊重与信赖。奋斗体现在为客户创造价值的任何微小活动中,以及在劳动的准备过程中为充实提高自己而做的努力。我们坚持以奋斗者为本,使奋斗者得到合理的回报。

自我批判

自我批判的目的是不断进步,不断改进,而不是自我否定。只有坚持自我批判,才能倾听、扬弃和持续超越,才能更容易尊重他人和与他人合作,实现客户、公司、团队和个人的共同发展。

团队合作

胜则举杯相庆,败则拼死相救。

明和 NETPRO NRS2100产品简介 ——企业级 CDP产品

产品概述

NETPRO®  NRS2100企业级IT应用容灾保护系统,采用先进的IO捕获、录像、压缩、CDP、镜像等技术,通过旁路连接方式,为用户服务器操作系统(Linux/Windows/Unix)、业务数据、应用软件、数据库提供零窗口的实时保护及恢复,同时可为大中型数据中心构建容灾存储系统,实现以业务为导向的灾难恢复,通过连续的数据可用性满足用户业务7×24小时不间断运行要求。

NRS2100具有快速、强健的保护用户业务不间断运行的能力,非常适合大中型数据中心的容灾保护,满足政府、医疗卫生、企业、金融等行业的应用级数据容灾保护。

产品亮点

灵活的数据抓取,确保数据安全

  • NRS2100采用连续或定期(时间点)保护策略,满足甚至超出用户的所有RPO(数据恢复点目标)要求
  • NRS2100提供的CDP数据日志可按每次写入的IO颗粒度级别保护用户数据,允许用户将所有数据内容恢复到业务中断之前写入最后一个数据的时间点,实现数据零丢失或近零丢失
  • 每个卷可提供1,000个定期快照,可根据预设的保护计划(例如每小时或每隔几小时)为用户提供多个可启动的数据恢复版本,与传统的每日进行的磁带备份相比,提供了更多恢复点和更高的恢复速度,提供更高的RTO(时间恢复点目标)标准
  • NRS2100可以在同一数据卷上同时使用CDP日志记录和快照进行双重保护,也可根据不同业务要求分别单独使用。
  • 采用多种策略和方式保留、处理和回收快照空间,使快照的容量管理更加优化,提高了磁盘使用效率。

数据一致性保障,满足数据库业务要求

  • NRS2100支持与生产卷的同步数据镜像。写入到生产卷的数据会同时写入到镜像卷中,两份存储卷中的数据完全一致,消除业务系统数据单点故障隐患,避免因主存储系统物理故障导致的业务中断,尤其适用于企业级IT环境数据库之类对数据一致性要求很高的应用。

零干扰的数据保护、恢复、备份

  • NRS2100采用旁路保护模式,不干扰主存储数据读写,NRS2100运行状态不影响生产业务系统,可随时快速接入或快速退出。
  • NRS2100的数据日志恢复卷、快照卷可以直接挂载至服务器作为应急盘阵使用,无后台恢复时间,可快速实现数据和业务的快速恢复
  • 利用离线备份选件,可直接从虚拟的NRS2100数据卷上将原始数据备份到磁带等介质,而无需通过生产服务器进行备份。这不仅提供了SAN级别的性能,还不会对生产系统的服务器及存储系统产生额外备份开销从而影响生产系统性能,实现Server-Free级别数据备份。

自动化灾难恢复工具实现灾难自动切换

  • 利用自动化灾难恢复工具,可以让复杂的数据保护和恢复以及业务系统的恢复实现自动化运作,真正实现一键自动切换。
  • 支持物理和虚拟服务器,支持物理到物理 (P2P)、物理到虚拟 (P2V) 或虚拟到虚拟 (V2V) 服务器的自动保护和恢复
  • 配置VMware应用快照导向模块实现虚机的快照保护
  • 在实际故障出现之前,自动化灾难恢复工具支持对恢复作业执行在线的无中断测试,真正做到有备无患。

远程容灾实现数据、应用的异地保护

  • NRS2100支持卷的远程复制功能,本地的数据卷可按增量自动复制到远程NRS上,可通过IP链路复制,也可通过FC链路实现高性能低延迟复制,复制的数据可以压缩或加密,提高了传输效率的同时保证数据安全性。
  • 采用精简式复制方式,通过基于扇区的窄带宽容灾优化技术可将IP链路容灾复制数据流量降低多达95%。显著的缩减容灾带宽要求和每月带宽成本,能够同时为更多应用程序提供保护。

设备部署灵活,方便用户按需选择

  • NRS2100支持iSCSI和FC的主机连接方式,并可提供万兆iSCSI接口,可部署于现有的SAN网络,或者融入到企业IP网中,提供数据持续保护和快速恢复。
  • NRS2100-G采用功能网关模式,可以连接兼容的磁盘阵列实现容量扩容,既能保证大型应用环境下的性能稳定,又能整合利用已有的空闲磁盘资源,保护投资。
  • NRS2100支持双机高可用方式,两台NRS2100之间相互备援,当一台NRS2100瘫痪时,另外一台自动接管,确保业务系统7×24随时处于保护状态。支持集群节点并行读写,支持集群节点自动故障切换,可升级支持为8节点集群

国产化自主创新产品,符合国内数据安全要求

  • 国产化自主创新产品,具备自主创新产品认证,符合国产化数据安全要求
  • 拥有多项软件著作权、发明专利、实用新型专利等知识产权证书

典型应用

  • 三甲医院HIS系统高可用保护
  • 省市级政府财政、工商、税收等核心业务系统保护和容灾
  • 企业ERP系统、大型数据中心、生产制造系统、数字资产管理系统等快速保护

技术规格

产品型号 NRS2100-L NRS2100 NRS2100-G
物理规格 2U12盘位 2U24盘位 2U标准机架
处理器类型 2个Intel多核处理器 2个Intel多核处理器
高速缓存 32GB~1024GB ECC DDR3 64GB~1024GB ECC DDR3
RAID保护级别 支持RAID 0、1、5、6、10、50、60 取决于磁盘阵列
端口类型 8Gb/16Gb FC、千兆iSCSI、万兆iSCSI/FCoE 8Gb/16Gb FC、千兆iSCSI、万兆iSCSI/FCoE
端口数量 标配2个8Gb FC和4个千兆iSCSI 标配4个8Gb FC和4个千兆iSCSI
管理接口类型 千兆RJ-45 千兆RJ-45
基础容量 12片900GB 10krpm SAS硬盘 无(NRS功能机头,无数据盘,需连接磁盘阵列提供容量)
支持的磁盘类型 SSD硬盘:200GB/300GB/400GB/800GB MLC

SAS硬盘: 900GB @10Krpm 2.5寸

NL-SAS硬盘:2TB、3TB、4TB@7.2krpm 3.5寸

取决于磁盘阵列
快照数量 1000个
CDP保护窗口 无限,取决于CDP日志区存储容量
最大主机连接数 无限
最大磁盘数量 无限
可保护的文件系统 AIX、HP-UX、Solaris等Unix文件系统和Windows、Linux文件系统以及VMware文件系统
可保护的应用类型 Oracle、Sybase、DB2、Informix、Domino等Unix应用

Oracle、Exchange、SQL Server、MySQL等Windows/Linux应用

VMware vCenter Site Recovery Manage等虚拟化应用

存储虚拟化 支持存储虚拟化功能,容灾保护系统中的数据可直接挂载到任一服务器,以Server-Free方式备份至物理磁带机中,此过程无需业务服务器参与。

提供自动精简配置(Thin Provising)功能,可根据应用保护实际所需要的存储容量,多次、少量的分配给保护系统,降低存储空间需求和管理难度,节省业务投资成本

远程复制功能 提供基于IP或FC网络的复制功能,提供基于增量和时间的复制策略,复制时支持加密、压缩和断点续传;具备窄带传输能力,仅传输变化的数据量,消除重复数据块,重复数据块比对尺寸小于等于512byte ,降低容灾链路带宽成本,便于远程数据容灾
持续数据保护功能 提供持续数据保护,支持任意时间粒度的数据保护及快速恢复,支持毫秒级数据恢复,可以对同一个卷同时使用连续保护和快照两种保护模式
数据快照 可为每个目标提供≥1000个数据快照,每个快照点可随时独立挂载服务器使用,无回滚或恢复个,无需影响生产系统,快照卷可读可写;快照更新的数据可根据需求反向同步更新至生产卷;针对数据库配置数据一致性专用软件,无需编写脚本保证一致性;
系统保护 支持操作系统的远程历史点启动(光纤、iSCSI等方式)
数据镜像 支持数据镜像,实现存储系统的‘零’停机迁移
管理方式 简洁的图形化管理能力;支持集中化管理控制台;支持系统状态监控 (SNMP & e-mail);支持对磁盘系统的状态监控;具备多种方式的报告(Report)机制,统计使用状况;支持中心化管理,支持CLI、GUI管理方式,支持自动邮件报警
其它功能 支持HA, IP Trunking, MPIO, CallHome, X-RAY系统报告等
电源模块 全冗余电源模块
物理尺寸 宽437mm × 高89mm × 深648mm
环境规范 电气参数:100V AC~120V AC或 200V AC~240V AC;

温度指标:工作态5°C~45°C;

相对湿度:工作态10%~85%;

海拔高度:0~12000英尺;

明和NETPRO PX5000存储网关 ——双活数据中心存储虚拟化

201404221102108909

产品概述

NETPRO PX5000(以下简称 PX5000)存储虚拟化集群管理系统,基于先进的集群虚拟化管理引擎,采用Cache镜像、Cache加速、数据压缩、自动精简、同步镜像、异步复制、自动分层、异构透明数据迁移、无限容量扩展等关键技术,为用户的应用提供双活异地容灾解决方案、存储虚拟化整合、存储高可用、本地CDP数据保护、,满足用户业务系统弹性扩展及7×24小时不间断运行,打造EDC高效能数据中心。

功能价值

ORACL远程RAC双活数据中心 ( <= 100km )

提供Oracle远程RAC 双活数据库连续性

超强的存储虚拟化整合能力

桌面虚拟化、服务器虚拟化、存储虚拟化,三个要素相加构成用户业务的全局虚拟化,EDC是全局虚拟化最为关键的核心,PX5000作为EDC的中枢神经,提供以下三大应用价值:

虚拟化服务器与虚拟化存储相融合

适用于传统方案中主流的服务器

虚拟化服务器的基础,提供设备兼容性、应用兼容性和虚拟化服务器的高性能需求

通过虚拟化技术,提高服务器设备和存储设备利用率

 

提供存储节点高可用与业务连续性

生产系统7×24小时不间断运行

消除共享式存储单点故障

 

数据中心双活容灾

异构存储的Cache加速,提升业务系统的IOPS和吞吐率

独具特色的远程压缩复制

一键主备切换、一键智能恢复

 

丰富的软件功能

自动分层: PX5000支持SSD、SAS、SATA多种存储介质,在同一存储池内为不同性能的磁盘分层,它能够自动监测 I / O的访问频率,动态的将数据迁移到最佳的存储磁盘层次上,优化整个业务运转效率;

高速缓存: PX5000通过其高速缓存,可以将主机数据块进行整合,并行均衡的写入到磁盘中,提高了应用主机访问存储的速率;

在线快照:PX5000在线快照仅仅记录数据的增量变化并可以驻留在精简配置的虚拟卷中,以降低系统资源的损耗,针对同一份源数据最多可产生1024份快照副本;

CDP功能:PX5000的CDP功能可以通过日志和时间戳能够不间断的记录相对应虚拟磁盘的I / O,可以选择任何时间点的恢复,而不需要中断应用程序、不需要在主机端安装任何代理程序;

N+1 高可用性架构

在经典的双存储冗余架构之上,用户能以虚拟卷为单元,根据不同业务等级配置 高可用性,推荐的N +1 方案在提高可用性的同时,也提高了系统整体存储性能

FC、IP无缝融合

全面支持FC和iSCSI主机端口和阵列端口,支持10GE iSCSI接口

 

异构数据在线迁移

利用PX5000的在线迁移功能,可以在不同品牌、不同架构的盘阵间实现数据卷的迁移,在这一过程中服务器不需要停机,实现异构存储设备之间数据在线迁移,为企业级用户节省时间成本和管理成本。

便捷的管理功能

PX5000提供强大的GUI图形管理界面和可视化管理,通过一个集中的界面实现快速的存储配置和管理;

PX5000整合不同品牌/厂商异构存储,通过中央控制台独立的工具控制和监视整个存储资源,实时更新虚拟存储池的状态,实现远程集中管理;

PX5000的存储资源以虚拟存储池为基础,存储池扩容不需要停机,充分保证用户业务持续可用

典型应用

PX5000拥有超强的存储虚拟化整合能力和容灾保护功能,尤其适合不同存储厂商/品牌混和的信息中心或数据中心,满足地市级以上政府、科研教育、医疗卫生、企业、能源、交通、金融等行业客户的存储虚拟化整合及容灾保护,为客户构建安全可靠、高性能、开放的存储系统。

NETPRO PX5000典型应用包括:公安、检查院、法院、国土资源、教育、医院等存储虚拟化整合等;医疗HIS系统、大中型企业的ERP系统等存储高可用环境。

技术规格

产品系列 NETPRO PX5000
最大集群节点数量 8
每节点标配处理器 2个多核处理器
每节点缓存容量(标配/最大) 32GB/512GB
最大虚拟化管理容量 无限
主机连接数量 无限
每节点IO接口 u       标配4个8Gb FC和2个千兆iSCSI接口,支持端口类型和数量升级,可选升级模块如下:

n         4端口/8端口8Gb FC模块

n         4端口/8端口千兆iSCSI模块

n         4端口万兆iSCSI模块

管理方式 功能强大的GUI人机交互管理界面
报警功能:高级状态提醒(包括日志、自动弹出气球通知等)
通过内置向导建立系统健康状态,LOG关键字,触发信息的预警通知(内置SMTP mailpost);可自制任务计划,系统智能实施;
支持的高级功能
性能保障 支持Caching加速功能,通过高性能磁盘资源(如SSD)对资源池中的所有存储系统提供性能加速;
数据安全 基于IO的连续数据保护、数据镜像和数据快照、远程数据复制等高级功能;不受应用系统、网络、操作系统限制,可动态增加保护对象
业务连续保障 一键主备切换、一键智能恢复,支持集群节点自动故障切换,支持对主机无影响的透明数据迁移功能,迁移后主机配置不做任何修改即可投入使用;
虚拟化支持 自动分层存储、异构存储整合、自动精简配置、提供VMware vSphere插件,支持异构存储系统虚拟化聚合;支持Vmware(VI3,VI4)、Hyper-V、XenServer、KVM等虚拟化管理软件
存储兼容性 l         IBM DS系列、V系列、FAS系列存储

l         HP StorageWorks MSA系列、EVA系列、XP系列、P系列

l         EMC CLARiiON CX系列、Symmetrix DMX系列、VNX系列

l         Fujitsu ETERNUS 2000系列

l         Hitachi AMS/WMS系列、Lightning系列、Thunder系列、USP/NSC系列、HUS系列

l         SUN StorageTek系列

l         Infortrend DS/ES系列、ESVA系列

l         Promise Vtrak系列、Vess系列

等FC SAN存储系统

主机OS兼容性 Windows Server 2000, 2003, 2008, Hyper-V, Windows XP, Windows 7, UNIX, HP-UX, Sun Solaris, IBM AIX, RedHat Linus, Suse Linux, Apple MacOs, VMware ESX / vSphere, Citrix XenServer等
支持的网络文件系统 CIFS、NFS
物理尺寸 89mm Hx430mm Wx660mm D
电源 全冗余电源,80plus认证电源
环境规范 电气参数:100V AC~120V AC或 200V AC~240V AC;

温度指标:工作态5°C ~ 35°C;

相对湿度:工作态8%~85%,非凝结;

海拔高度:0~12000英尺;

 

 

(转)几个 Ceph 性能优化的新方法和思路(2015 SH Ceph Day 参后感)

一周前,由 Intel 与 RedHat 在10月18日联合举办了 Shanghai Ceph Day。在这次会议上,多位专家做了十几场非常精彩的演讲。本文就这些演讲中提到的 Ceph性能优化方面的知识和方法,试着就自己的理解做个总结。

0. 常规的 Ceph 性能优化方法

(1). 硬件层面

  • 硬件规划:CPU、内存、网络
  • SSD选择:使用 SSD 作为日志存储
  • BIOS设置:打开超线程(HT)、关闭节能、关闭 NUMA 等

(2). 软件层面

  • Linux OS:MTU、read_ahead 等
  • Ceph Configurations 和 PG Number 调整:使用 PG 计算公式(Total PGs = (Total_number_of_OSD * 100) / max_replication_count)计算。
  • CRUSH Map

更多信息,可以参考下面的文章:

1. 使用分层的缓存层 – Tiered Cache

显然这不是一个 Ceph 的新特性,在会议上有这方面的专家详细地介绍了该特性的原理及用法,以及与纠错码方式结合的细节。

151026103710731

简单概括:

  • 每一个缓存层次(tiered cache)使用一个 RADOS pool,其中 cache pool 必须是拷贝(replicated)类型,而 backing pool 可以是拷贝类型也可以是纠错码类型。
  • 在不同的缓存层次,使用不同的硬件介质,cache pool 使用的介质必须比 backing pool 使用的介质速度快:比如,在 backing pool 使用一般的存储介质,比如常规的HDD或者 SATA SDD;在 cache pool 使用快速介质,比如 PCIe SDD。
  • 每一个 tiered cache 使用自己的 CRUSH rules,使得数据会被写入到指定的不同存储介质。
  • librados 内在支持 tiered cache,大多数情况下它会知道客户端数据需要被放到哪一层,因此不需要在 RDB,CephFS,RGW 客户端上做改动。
  • OSD 独立地处理数据在两个层次之间的流动:promotion(HDD->SDD)和 eviction(SDD -> HDD),但是,这种数据流动是代价昂贵(expensive)和耗时的(take long time to “warm up”)。

2. 使用更好的 SSD – Intel NVM Express (NVMe) SSD

在 Ceph 集群中,往往使用 SSD 来作为 Journal(日志)和 Caching(缓存)介质,来提高集群的性能。下图中,使用 SSD 作为 Journal 的集群比全 HDD 集群的 64K 顺序写速度提高了 1.5 倍,而 4K 随机写速度提高了 32 倍。

151026103710733

而Journal 和 OSD 使用的 SSD 分开与两者使用同一块SSD,还可以提高性能。下图中,两者放在同一个 SATA SSD 上,性能比分开两块 SSD (Journal 使用 PCIe SSD,OSD 使用 SATA SSD),64K 顺序写速度下降了 40%,而 4K 随机写速度下降了 13%。

151026103710734

因此,更先进的 SSD 自然能更加提高Ceph 集群的性能。SSD 发展到现在,其介质(颗粒)基本经过了三代,自然是一代比一代先进,具体表现在密度更高(容量更大)和读写数据更快。目前,最先进的就是 Intel NVMe SSD,它的特点如下:

  • 为 PCI-e 驱动器定制的标准化的软件接口
  • 为 SSD 定制(别的是为 PCIe 所做的)
  • SSD Journal : HDD OSD 比例可以从常规的 1:5 提高到 1:20
  • 对全 SSD 集群来说,全 NVMe SSD 磁盘Ceph 集群自然性能最好,但是它造价太高,而且性能往往会受限于网卡/网络带宽;所以在全SSD环境中,建议的配置是使用 NVMe SSD 做 Journal 而使用常规 SSD 做 OSD 磁盘。

同时,Intel SSD 还可以结合 Intel Cache Acceleration Software 软件使用,它可以智能地根据数据的特性,将数据放到SSD或者HDD:

151026103710732

测试:

  • 测试配置:使用 Intel NVMe SSD 做 Cache,使用 Intel CAS Linux 3.0 with hinting feature (今年年底将发布)
  • 测试结果:5% 的 cache,使得吞吐量(ThroughOutput)提交了一倍,延迟(Latency)降低了一半

3. 使用更好的网络设备 – Mellanox 网卡和交换机等

3.1 更高带宽更低延迟的网卡设备

Mellanox 是一家总部在以色列的公司,全球约 1900 名员工,专注高端网络设备,2014 年revenue 为 ¥463.6M 。(今天正好在水木BBS上看到该公司在中国的分公司待遇也是非常好)。其主要观点和产品:

  • Ceph 的 Scale Out 特性要求用于 replicaiton、sharing 和 metadata (文件)的网络吞吐量更高、延迟更低
  • 目前 10 GbE(万兆以太网络) 已经不能满足高性能Ceph 集群的要求(基本上 20个 SSD 以上的集群就不能满足了),已经开始全面进入 25, 50, 100 GbE 时代。目前,25GbE 性价比比较高。
  • 大部分网络设备公司使用的是高通的芯片,而 Mellanox 使用自研的芯片,其延迟(latency)是业界最低的(220ns)
  • Ceph 高速集群需要使用两个网络:public network 用于客户端访问,Cluster network 用于 heartbeat、replication、recovery 和 re-balancing。
  • 目前 Ceph 集群广泛采用 SSD, 而快速的存储设备就需要快速的网络设备

实际测试:

(1)测试环境:Cluster network 使用 40GbE 交换机,Public network 分布使用 10 GbE 和 40GbE 设备做对比

151026103710735

(2)测试结果:结果显示,使用 40GbE 设备的集群的吞吐量是使用 10 GbE 集群的 2.5 倍,IOPS 则提高了 15%。

目前,已经有部分公司使用该公司的网络设备来生产全SSD Ceph 服务器,比如,SanDisk 公司的 InfiniFlash 就使用了该公司的 40GbE 网卡、2个 Dell R720 服务器作为 OSD 节点、512 TB SSD,它的总吞吐量达到 71.6 Gb/s,还有富士通和Monash 大学。

3.2 RDMA 技术

传统上,访问硬盘存储需要几十毫秒,而网络和协议栈需要几百微妙。这时期,往往使用 1Gb/s 的网络带宽,使用 SCSI 协议访问本地存储,使用 iSCSI 访问远端存储。而在使用 SSD 后,访问本地存储的耗时大幅下降到几百微秒,因此,如果网络和协议栈不同样提高的话,它们将成为性能瓶颈。这意味着,网络需要更好的带宽,比如40Gb/s  甚至 100Gb/s;依然使用 iSCSI 访问远端存储,但是 TCP 已经不够用了,这时 RDMA 技术应运而生。RDMA 的全称是 Remote Direct Memory Access,就是为了解决网络传输中服务器端数据处理的延迟而产生的。它是通过网络把资料直接传入计算机的存储区,将数据从一个系统快速移动到远程系统存储器中,而不对操作系统造成任何影响,这样就不需要用到多少计算机的处理功能.它消除了外部存储器复制和文本交换操作,因而能腾出总线空间和CPU 周期用于改进应用系统性能. 通用的做法需由系统先对传入的信息进行分析与标记,然后再存储到正确的区域。

1510261037107313

这种技术上,Mellanox  是业界领先者。它通过 Bypass Kenerl 和 Protocol Offload 的实现,提供高带宽、低CPU占用和低延迟。目前,该公司在 Ceph 中实现了 XioMessager,使得Ceph 消息不走 TCP 而走 RDMA,从而得以提高集群性能,该实现在 Ceph Hammer 版本中提供。

更多信息,可以参考:

http://www.mellanox.com/related-docs/solutions/ppt_ceph_mellanox_ceph_day.pdf

http://ir.mellanox.com/releasedetail.cfm?ReleaseID=919461

What is RDMA?

RDMA 百度百科

4. 使用更好的软件 – Intel SPDK 相关技术

4.1 Mid-Tier Cache 方案

该方案在客户端应用和 Ceph 集群之间添加一个缓存层,使得客户端的访问性能得以提高。该层的特点:

  • 对 Ceph 客户端提供 iSCSI/NVMF/NFS 等协议支持;
  • 使用两个或者多个节点提高可靠性;
  • 添加了Cache,提高访问速度
  • 使用 write log 保证多节点之间数据一致性
  • 使用 RBD 连接后端Ceph集群
  • 151026103710736
  • 4.2 使用 Intel DPDK 和 UNS 技术

  • 151026103710737
  •     Intel 使用该技术,在用户空间(user space)实现了全 DPDK 网卡及驱动、TCP/IP协议栈(UNS)、 iSCSI Target,以及 NVMe 驱动,来提高Ceph的 iSCSI 访问性能。好处:
    • 与 Linux*-IO Target (LIO) 相比,其 CPU overhead 仅为 1/7。
    • 用户空间的 NVMe 驱动比内核空间的 VNMe 驱动的 CPU 占用少 90%

    该方案的一大特点是使用用户态网卡,为了避免和内核态的网卡冲突,在实际配置中,可以通过 SRIOV 技术,将物理网卡虚拟出多个虚拟网卡,在分配给应用比如OSD。通过完整地使用用户态技术,避免了对内核版本的依赖。

    目前,Intel 提供 Intel DPDK、UNS 、优化后的 Storage 栈作为参考性方案,使用的话需要和 Intel 签订使用协议。用户态NVMe驱动已经开源。

  • 4.3  CPU 数据存放加速 – ISA-L 技术

    该代码库(code libaray)使用 Intel E5-2600/2400 和 Atom C2000 product family CPU 的新指令集来实现相应算法,最大化地利用CPU,大大提高了数据存取速度,但是,目前只支持单核 X64 志强和 Atom CPU。在下面的例子中,EC 速度得到几十倍提高,总体成本减少了百分之25到30.

  • 151026103710738
  • 5. 使用系统的工具和方法 – Ceph 性能测试和调优工具汇总

    本次会议上,还发布了若干Ceph 性能测试和调优工具。

    5.1 Intel CeTune

    Intel的该工具可以用来部署、测试、分析和调优(deploy, benchmark, analyze and tuning)Ceph 集群,目前它已经被开源,代码 在这里。主要功能包括:

    • 用户可以对 CeTune 进行配置,使用其 WebUI
    • 部署模块:使用 CeTune Cli 或者 GUI 部署 Ceph
    • 性能测试模块:支持 qemurbd, fiorbd, cosbench 等做性能测试
    • 分析模块:iostat, sar, interrupt, performance counter 等分析工具
    • 报告视图:支持配置下载、图标视图

    5.2 常见的性能测试和调优工具

    Ceph 软件栈(可能的性能故障点和调优点):

  • 151026103710739

可视性性能相关工具汇总:

Benchmarking 工具汇总:

调优工具汇总:

6. 综合评价

上面的几种方法,与传统的性能优化方法相比,部分具有其创新性,其中,

  • 更好的硬件,包括SSD和网络设备,自然能带来更好的性能,但是成本也相应增加,而且带来的性能优化幅度具有不一致性,因此,需要在应用场景、成本、优化效果之间做综合权衡;
  • 更好的软件,目前大都还没有开源,而且大都还处于测试状态,离在生产环境中使用尚有距离,而且都和 Intel 的硬件紧密绑定;
  • 更全面的方法,则是广大 Ceph 专业人员需要认真学习、使用到的,在平时的使用中能够更高效的定位性能问题并找到解决方法;
  • Intel 在 Ceph 上的投入非常大,客户如果有Ceph集群性能问题,还可以把相关数据发给他们,他们会提供相应建议。

注:以上所有内容皆来自于本次会议上展示的资料以及会后发送的资料。如有内容不合适在本文发布,请与本人联系。再次感谢 Intel 和 RedHat 举办本次会议。

CentOS 7.1 上安装分布式存储系统 Ceph  http://www.linuxidc.com/Linux/2015-08/120990.htm

Ceph环境配置文档 PDF http://www.linuxidc.com/Linux/2013-05/85212.htm

CentOS 6.3上部署Ceph http://www.linuxidc.com/Linux/2013-05/85213.htm

Ceph的安装过程 http://www.linuxidc.com/Linux/2013-05/85210.htm

HOWTO Install Ceph On FC12, FC上安装Ceph分布式文件系统 http://www.linuxidc.com/Linux/2013-05/85209.htm

Ceph 文件系统安装 http://www.linuxidc.com/Linux/2013-05/85208.htm

CentOS 6.2 64位上安装Ceph 0.47.2 http://www.linuxidc.com/Linux/2013-05/85206.htm

Ubuntu 12.04 Ceph分布式文件系统 http://www.linuxidc.com/Linux/2013-04/82588.htm

Fedora 14上安装 Ceph 0.24 http://www.linuxidc.com/Linux/2011-01/31580.htm

Ceph 的详细介绍请点这里
Ceph 的下载地址请点这里

本文永久更新链接地址http://www.linuxidc.com/Linux/2015-10/124526.htm

(转) flash卡的擦写问题

  • 可用性
  •   本身自保护:存储模块之间有类似Raid5+hotspare保护,如果有有存储模块损坏,hotspare进行顶替。如果再坏一个模块,整块卡会置成readonly,将卡保护起来。并且所有过程都有日志输出,我们可以监控起来。
  •   擦写次数:MLC类型,每个block 10000次擦写。数据修改,是将需要修改的block的数据先读取到内存中,修改完成后,通过一个均衡算法,将数据写回到写入寿命相对较小的block。所以不会存在某些block损坏的情况,要坏是整个卡同时坏。

按照这个算法,一块400G的flash卡,需要写入400*10000G,即4PB数据才会整体写坏。我们测算过,按照淘宝双11一天的写入量,每天都这样写入,要写7年时间。淘宝用了5年这款产品,从来没有出现自然寿命损坏的问题。

 

监控软件: 驱动自带监控的,  现在卡 已经写了多少次了,还剩下多少寿命

 

 

(转)历经十年:关于Ceph现状与未来的一些思考 作者:袁冬

Ceph从2004年提交了第一行代码,至今为止已经10年了。特别是随着云计算的发展,Ceph乘上了OpenStack的春风,受到各大厂商的待见,Intel、 DreamHost、SanDisk、CISCO、Yahoo等公司都或多或少的参与其中。RedHat更是一掷千金,直接砸了1.75亿美金将Sage 创建的Inktank公司及其Ceph团队收入囊中,将其作为IaaS三大组件计算、网络、存储之一。

在这十年的发展过程中,Ceph似乎越来越向着云计算的方向靠拢,最先的CephFS文件系统已经不再是开发重点,甚至开发已经陷入了停滞状态。而与虚拟化相关的RBD、RGW则成了发展重点,成为发展最快的模块。但是从代码中仍然能够看到各种遗迹,似乎在告诉后来人这段饶了一个大弯的历史。

Ceph发展现在仍然快的眼花缭乱,让我们暂时停下脚步,看看经过十年发展后,现在Ceph的优势与缺点。

一、优势

CRUSH算法

CRUSH算法是Ceph最初的两大创新之一(另一个是基于动态子树分区的元数据集群),也是整个RADOS的基石,是Ceph最引以为豪的地方。

CRUSH在一致性哈希基础上很好的考虑了容灾域的隔离,能够实现各类负载的副本放置规则,例如跨机房、机架感知等。同时, CRUSH算法支持副本和EC两种数据冗余方式,还提供了四种不同类型的Bucket(Uniform, List, Tree, Straw),充分考虑了实际生产过程中硬件的迭代式部署方式,虽然实际生产中大多数情况下的都是只用了一种Straw。

另外根据Sage的论文,CRUSH算法具有相当好的可扩展性,在数千OSD的情况下仍然能保证良好的负载平衡。但这更多是理论层面的,目前还没有人给出在数PB规模的生产环境中的测试结果。

总的来看,CRUSH算法仍然是目前经过实践检验的最好的数据分布算法之一。

2. 统一存储架构

Ceph最初设计的RADOS是为其实现一个高性能的文件系统服务的,并没有考虑对于块设备、对象存储的支持,也就没有什么RBD、RADOS GateWay,跟别提OpenStack和qemu之类的了。但谁想无心插柳柳成荫,由于 RADOS 出色的设计和独立简洁的访问接口,再加上Sage敏锐的眼光,Ceph社区果断推出了用于支持云计算的分布式块存储RBD和分布式对象存储RADOS GateWay,并将开发中心全面转向云计算领域。

不得不说,RADOS的设计还是非常的优秀。从架构上来看,RBD和RADOSGateWay实际上都只是RADOS的客户端而已,但得益于RADOS的优秀设计,RBD和RADOSGateWay的设计和实现都很简单,不需要考虑横向扩展、冗余、容灾、负载平衡的等复杂的分布式系统问题,同时能够提供足够多的特性和足够优秀的性能,因此迅速得到了社区的认可。另一方面,Ceph为OpenStack提供了良好的支持,成为了目前最火的OpenStack底层存储系统。乘着云计算和OpenStack的东风,Ceph作为一个统一存储系统,似乎大有舍我取谁之势。

3.丰富的特性

Ceph的特性不可谓不多,从分布式系统最基本的横向扩展、动态伸缩、冗余容灾、负载平衡等,到生产环境环境中非常实用的滚动升级、多存储池、延迟删除等,再到高大上的CephFS集群、快照、纠删码、跨存储池缓存等,不可谓不强大。

但是就像大多数开源系统一样,Ceph的基本特性,或者说真正在生产环境中用的上的特性还是非常靠谱的,但其他“高级”特性就只能打一个问号了。特别是在CephFS模块,由于Ceph社区目前的开发重点主要还是与云计算相关的部分,即RBD和RADOSGateWay,导致CephFS的开发停滞了很久,相关的特性,例如元数据集群、快照等,目前都不满足生产环境的要求。

二、缺点

代码质量

代码质量的问题,实际上是个仁者见仁智者见智的问题。

Ceph主要使用C/C++语言编写,同时外围的很多脚本和工具用了Python。之所以要说明Ceph的语言构成,是因为代码质量实际上是和语言具有密切的关系。不否认用C++也能写出优雅的代码,但相比于更加“现代”的语言,要想写出具备同样可读性、结构良好、调理清晰代码,C++要困难很多。但是,由于存储作为底层系统,对效率的追求是无止境的,因此不太可能舍弃对于内存等底层系统资源的控制,而使用 Java/Python这类的语言。而作为一个开源项目,期望所有的贡献者都是C++的高手,未免有些强人所难,这似乎成了一个死结。其他类似的开源项目怎么办呢?貌似他们都用的纯c……

另一方面,Ceph广泛使用了STL,在部分核心代码中还是用了BOOST,这两者在底层核心系统代码中的可用性也一直存在争议。这更加加剧了代码质量的挑战性。

最关键的是,Ceph似乎已经被太多已经背负了太多的历史包袱,比如最核心的osd模块,最初的设计包含OSD 和PG类,其中PG类负责PG的通用逻辑,OSD负责管理所有的PG。然后PG的子类ReplicatedPG实现了以副本作为冗余模式的PG。这里就存在了两个半类:OSD、PG及其子类ReplicatedPG,这两个半类实现了osd模块99%的逻辑,可以想象这两个半类会有多大。

在目前的master分支上,相关文件的大小分别是:

OSD.h+OSD.cc = 2383行+8604行 = 10987行

PG.h+PG.cc = 2256行+7611行 = 9867行

ReplicatedPG.h+ReplicatedPG.cc = 1487行+12665行 = 14152行

需要特别注意的是,从C++继承的角度上,理解一个类,必须理解他的父类,也就是说,如果你想理解ReplicatedPG,理论上你必须同时理解PG,也就是说,要同时理解20000+行代码!

更加丧心病狂的是,这两个半类之间存在密切而复杂的调用关系,相互之间直接使用整个类,而没有什么实际上的接口隔离。严重加剧了理解代码的难度。

在EC功能以一种奇葩的方式加入到osd中之后,整个场面更加混乱。按照最初的设计,实现EC应该增加PG的一个子类,类似 ErasureCodePG。但是由于ReplicatedPG包含了太多通用的代码,实际上已经和PG合二为一了,所以EC只能在 ReplicatedPG的基础上改造。于是又出现了PGBackend的概念和相关的实现,这只能说是挑战人脑的极限了。

Ceph社区也曾试着梳理代码,比如添加OSDService类,作为PG与OSD通讯的接口。这样所有的PG全部调用OSDService而非OSD,相当于做了OSD与PG之间的隔离。但是似乎并没有起到足够的效果,现在已经名存实亡了。

Ceph在这样的代码质量下,还能向前走多久,委实是一件令人担忧的事情。

2. 性能

Ceph的性能总的来说还是不错的,基本上能发挥出物理硬件的性能,但是存在以下几个隐患:

1)数据双倍写入。Ceph本地存储接口(FileStore)为了支持事务,引入了日志(Journal)机制。所有的写入操作都需要先写入日志(XFS模式下),然后再写入本地文件系统。简单来说就是一份数据需要写两遍,日志+本地文件系统。这就造成了在大规模连续IO的情况下,实际上磁盘输出的吞吐量只有其物理性能的一半。

2)IO路径过长。这个问题在Ceph的客户端和服务器端都存在。以osd为例,一个IO需要经过message、OSD、FileJournal、FileStore多个模块才能完成,每个模块之间都涉及到队列和线程切换,部分模块在对IO进行处理时还要进行内存拷贝,导致整体性能不高。

3)对高性能硬件的支持有待改进。Ceph最开始是为HDD设计的,没有充分考虑全SSD,甚至更先进的PCIe SSD和NVRAM的情况NVRAM。导致这些硬件的物理性能在Ceph中无法充分发挥出来,特别是延迟和IOPS,受比较大的影响。

3. CephFS

CephFS现在在整个Ceph系统中处于一个较为尴尬的情况,因为POSIX这种借口似乎在云计算中没有用武之地,导致了社区对这个模块的关注不足,也就没有什么进展。

CephFS作为最初Ceph的设计目标,Sage投入了巨大的精力,几乎实现了所有需要的特性,并且进行了大量工程层面的优化。

正所谓成也萧何败萧何,Ceph想把CephFS模块做到足够强大,甚至是最强大,但强大的同时也意味着不菲的代价。元数据动态子树分区、目录分片、快照、权限控制、IOPS优化、故障恢复、分布式缓存、强弱一致性控制,这些高大上的名词背后都意味着复杂的工程性任务,更不要说将这些叠加在一起。很多时候,叠加不是想加,而是相乘的关系。最终的结果就是整个MDS的工程难度已经超过了可以掌控的程度,无法做出足够成熟、稳定的系统。

目前CephFS宣称其单MDS的模式是稳定的,MDS的集群的模式是不稳定的。而快照功能默认关闭,今后也够呛会有开启的可能了。

4. 业务连续性

Ceph中的RADOS采用强一致性设计,即Write-All-Read-One,这种模式的好处在于读取效率较高,而且工程难度较低,比较适合与读多写少的系统。

Write-All-Read-One的特点是必须等待所有的副本全部写入完毕才算是写入成功,这实际上对系统硬件的可靠性要求较高,因为如果在写入过程中存在任意硬件故障,则写入过程都要受影响。通常表现为卡顿,一般在数秒级别,时间长短和判断故障的机制以及故障恢复过程中IO的处理策略相关。

但是当集群非常非常大时,Write-All-Read-One对于硬件可靠性的要求几乎是无法满足的。想象一下一个10PB的系统,按照最大4TB每块盘的计算,就有2500块磁盘。按照我们以往的运维经验,每周存在一块磁盘故障是完全正常的。这种场景下,如果数据分布足够分散,实际上一块磁盘可能涉及到很多数据块,也就是说一块磁盘故障会影响很多IO,而这种情况每周发生一次。这对业务连续性的影响是已经是不可忽略的。

生产环境中的场景比这个更加复杂,因为磁盘或者硬件的故障可能不仅表现为不可写,还有可能是慢或者不稳定。这些情况对于业务连续性的影响也更加严重。

5. 社区

Ceph社区现在已经有很多厂商实际上或者号称参入进来,其中不乏Intel、Dreamhost、SanDisk这样的大厂,也不乏UnitedStack这样的Start-Up公司,还有电信、大学、研究所这类非存储领域的公司或单位。但实际上整个Ceph还是掌握在Inktank或者说RedHat的手中,绝大多数核心代码由他们贡献,也是他们Review和Merge。总的来说还是一个集权组织。

更加重要的是,Ceph相比OpenStack这种成熟完善的开源社区,缺乏足够的基础设施,例如成熟的单元测试、集成测试、测试环境、Reivew流程、贡献指引、代码规范等。导致整个社区仍然是人治、而非法制的过程,代码和系统的发展方向本质是由RedHat公司控制的。

对于以上这些问题,Ceph社区也非常清楚,并且正在或者将要改进。例如为了增加了对于SSD的支持,改进数据双倍写入问题以及更完善的社区建设和基础设施等。这些都增加了人们对Ceph的信心。

总的来说,Ceph瑕不掩瑜,仍然是一个优秀,甚至出色的开源存储系统。如果说分布式存储在云计算时代是风口上的猪,那么Ceph也是一直优秀的猪。

未来是什么样子,我们拭目以待。

关于作者

袁冬博士,UnitedStack产品副总裁,负责UnitedStack产品、售前和对外合作工作;云计算专家,在云计算、虚拟化、分布式系统和企业级应用等方面有丰富的经验;对分布式存储、非结构数据存储和存储虚拟化有深刻地理解,在云存储和企业级存储领域有丰富的研发与实践经验;Ceph等开源存储项目的核心代码贡献者。

原文链接:https://www.ustack.com/blog/sikao/

(转)InfiniBand可以运行哪些协议?

InfiniBand可以运行哪些协议?

 

发布时间:2013-01-30 00:00:00 来源:博客 作者:Steven.Lee

关键字:Exadata IPoIB Oracle RDS SDP tcp/ip 以太网

 

这不是一篇介绍infiniband是什么的文章,而仅仅站在Oracle RAC和Exadata的角度上阐述infiniband。 如果您不知道infiniband是什么,请点击这里。

 

很多人可能不知道,绝大多数高性能计算机内部或者集群之间都是使用infiniband互联的。在国家超算中心,在亚马逊的云计算中心都有它的身影。为什么infiniband会如此受欢迎呢?原因无非有两个: 一是目前infiniband本身能提供比传统以太网更高的带宽, 二是通常infiniband的开销比以太网要小,对于节点间通信大量数据传输比以太网效率要更高。当然Oracle也是这一技术的主导者, 其中RDS本身就是Oracle的一个开源项目。常见的运行在infiniband之上协议有哪些呢?下面就简单介绍一下Oracle DB可能会用到的几个:

 

IPoIB协议:

Internet Protocol over InfiniBand 简称IPoIB 。传统的TCP/IP栈的影响实在太大了,几乎所有的网络应用都是基于此开发的,IPoIB实际是infiniband为了兼容以太网不得不做的一种折中,毕竟谁也不愿意使用不兼容大规模已有设备的产品。IPoIB基于TCP/IP协议,对于用户应用程序是透明的,并且可以提供更大的带宽, 也就是原先使用TCP/IP协议栈的应用不需要任何修改就能使用IPoIB。例如如果使用infiniband做RAC的私网,默认使用的就是IPoIB。下图左侧是传统以太网tcp/ip协议栈的拓扑结构,右侧是infiniband使用IPoIB协议的拓扑结构。

1111

RDS协议:

 

Reliable Datagram Sockets (RDS)实际是由Oracle公司研发的运行在infiniband之上,直接基于IPC的协议。之所以出现这么一种协议,根本的原因在于传统的TCP/IP栈本身过于低效,对于高速互联开销太大,导致传输的效率太低。RDS相比IPoIB, CPU的消耗量减少了50%, 相比传统的UDP协议,网络延迟减少了一半。下图左侧是使用IPoIB协议的infiniband设备的拓扑图,右侧是使用RDS协议的infiniband设备的拓扑结构。默认情况下,RDS协议不会被使用,需要进行额外的relink。另外即使relink RDS库以后,RAC节点间的CSS通信也是无法使用RDS协议的,节点间心跳维持以及监控总是使用IPoIB。下图左侧infiniband使用IPoIB协议的拓扑结构,右侧是infiband使用RDS协议的拓扑结构。

22222222

 

SDP协议:

 

知道并且使用过RDS协议的人不少,但是可能不少人都没有听过sdp协议 。这个协议实际早在10g时代就存在过,只是没有专门的文档。这个白皮书算是比较少见的。其中只是简要的提到了sdp,所著笔墨不多,也没有提到如何实现,可能在这个版本属于试验性的功能。文中提到依靠一个Oracle Application Server端的驱动,SDP协议可以与TCP/IP协议栈进行透明的转换。Database端如何配置SDP连接可以点击这里: 11.1 11.2, Exalogic端如何配置SDP的链接可以在这里找到。甚至还有如何在java程序中使用SDP协议的案例介绍。在实际应用中,多个Exadata机柜的相连可以通过配置SDP协议连接,Exalogic和Exadata的连接也是通过SDP‘协议的。但是需要注意的是Oracle的Net Service目前是无法走RDS协议的。下图左侧是传统以太网tcp/ip协议栈的拓扑结构,右侧是infiniband使用SDP协议的拓扑结构。

3333333333333

 

还有可能会听过的协议有ZDP和IDB协议,这两个是新名词,如果有一点了解就知道是久瓶装新酒。iDB协议用于Exadata 数据库节点(DB node)和存储节点(cell node)之间的通信。i代表 intelligence, 言下之一就是智能数据库协议,您可不要小看它,整个Exadata的精髓offloading全靠它来完成,之所以其它第三方Oracle数据库一体机只有Exadata的形而没有Exadata的神,原因就在此。简单的说它是由Oracle数据库内核来实现的,可以智能的将表扫描的工作放到存储一端去完成,然后由存储进行过滤,最后只返回查询需要的数据。举个简单的例子: 比如某个表有1亿行,但是满足过滤条件的就只有1万行,数据库节点会发出一个指令告诉存储节点,“我需要查询某某表过滤条件是什么,你去处理一下,把结果告诉我就成,我还有别的事情要忙”。这个指令就是iDB。iDB的实现是Oracle公司的最高机密,除了Exadata的核心研发团队和技术高管没有人知道内部是如何实现的,只知道iDB协议是运行在ZDP协议(Zero-loss Zero-copy Datagram Protocol)之上,基于基于RDS协议的V3版本(OFED version 1.3.1))的标准进行研发的。Oracle的官方数据显示使用ZDP协议进行数据传输能达到每秒3GB/s,而仅仅消耗主机CPU资源的2%。

444444444444