谢谢各位专家，特别高兴能有这么一个机会在这跟大家汇报我们的一些工作，我来自中国电信。

今天跟各位专家汇报的题目是Server SAN技术规范探讨，原因是现在我们从运营商角度来讲，在拓展软件定义存储特别是Server SAN走得更快一些，在这个领域在现网里要去实施去推广，这过程当中我们发现可能要制定相关的规范，包括相关的评测标准，正好我们和ODCC还有李洁、郭亮那边一拍即合，一块在推动这个事情。这个事在今年3月份也做了标准的立项，现在借这个机会跟各位同仁、各位专家来汇报和沟通一下相关的工作。

Server SAN成为存储领域的主流技术，今天大家来到这可能都认同这个观念，这上面是Wikibnon2016年发布的报告，可以看到中间红色的区域是传统的存储，包括SAN、NAS、DAS，收入进入瓶颈期，慢慢会缩短，上面绿色的是大规模Server SAN整个市场的情况。下面蓝色的是企业级的Server SAN，从调研结果来看，整个Server SAN这个领域里，会慢慢替代掉传统的存储，五年之内有望超过它。这是2016年做的预测，从现在来看，仅从运营商的角度来看，可能用不了五年那么久，Server SAN的推广，因为它的市场效益已经逐步完成了，大家已经认可它，速度会越来越快。到底Server SAN是什么东西，大家都在说Server SAN，我们现在有一个初步的想法，Server SAN几个要点，一个是分布式的存储软件，它是一个软件的系统，底层是多台服务器，可能目前来看是X86架构为主，但我们不排除以后会有其他架构的服务器尽量。组成里目前看有硬盘、SSD这种统一的资源池，目标一个是为服务器，服务器又分两类，一类是虚拟机，一类是物理机，提供一些块存储的能力。这是我们初步做的Server SAN的定义。

Server SAN，它对SAN可以起到一个替代的作用，原来在SAN的场景里能够发挥作用的场景，Server SAN都可以做到。比如虚拟桌面VDI，包括测试/开发，包括在各种分支机构做生产前调试，原来都要买专用的存储来做这个事情，现在有Server SAN支持，下面都可以做替代。这个还比较泛，估计在座的专家也在生产当中会用到这个东西。

仅从运营商来讲大概有这几个点，三大运营商最近两年陆陆续续都启动了Server SAN相关的评测，增长还是比较迅速的，很多的省公司包括集团一些部门都提出来Server SAN会是一个方向，这也跟整个市场教育相关。正在逐步替代中低端，因为确确实实有一些比较敏感比较关键的环节，我们觉得还是传统的小型机加高端存储会衡量可靠一些，并不排除以后会慢慢被分布式架构、软件定义架构替换掉。当前从电信来讲，Server SAN最主要场景还是用在虚拟化资源池，不管是VMware资源池还是KVM资源池，会把它的SAN替掉，换成Server SAN架构。在资源池基础之上，我们也在做一些更关键的系统，比如今天上午咱们这个大会为广西电信颁发了创新应用奖，就因为广西电信在运营商的计费系统里，等于是IT里比较关键的一个系统，很勇敢的很大胆的用了Server SAN技术，而且效果还不错，整体的性能，能达到20万IOPS的量级，业务系统没问题，性能撑得住，整个效果也不错，慢慢会从虚拟化的场景向更高精尖的场景做演进。第四块，这里是运营商的一个特点，运营商很多Server SAN来讲不像今天开始阿里的专家讲的自己研发的，运营商还是以采购为主，当然我们自主研发也在做，目前来讲，还是以厂商以合作伙伴为主。运营商倡导软硬件解耦方案，前面的定义提到，我们下面的服务器是通用的架构，上面的软件可能会采到A家、B家、C家的来做，避免单一厂商。NVMe好像在去年这个时候还是很遥不可及的东西，到今年后的今天，已经进入到普及阶段，运营商现网里也有大量使用。第五，Server SAN到底有没有弊端，还是有的，刚才说的最核心系统目前还不敢尝试，对我们来讲最大的担心是分布式存储里面，它的磁盘可能都是一批，到一定寿命之后可能会批量的坏掉，这个运维的事情是我们在现网规模部署时最担心的一个事，有没有什么规避的方案，这也是后面可能会跟业界各位专家和厂商探讨的地方。

以上是结合现在电信的进展要跟大家说明的几条。

这个图是我们勾画的一个大概的Server SAN整体架构，大概分为五层，最底下是硬件设备层，包括X86通用服务器，不排除以后可能有其他的也许面向低能耗的也许面向高性能的新的架构出来，上面会有SAS/SATA/SSD，包括NVMe SSD，会看到万兆起包括RoCE技术。上面是存储引擎层，有集群状态控制，数据分布于路由，包括一致性检查和组件冗余等。上面是服务层，能做卷映射，做快照与克隆，包括精简置备等，把这些功能，我们叫做服务层。再上面是接口层，至少包括iSCSI网关和SCSI客户端等，最上面是应用层，可能需要VMware、KVM这些环境，还需要数据库、物理机，并且跟云管平台做对接。存储管理，对系统配置、集中部署、可视化运维等放在管理这一侧。这是我们现在结合很多厂商和我们交流的，特别是像Ceph这种开源的技术也不断完善，给我们的一些启发，我们会依托这些业界的现状和一些开源技术的挖掘，我们理了这么一个框图。今天这个题目是探讨，我们还在不断的演进当中，这个工作还会不断修订，让它不断完善。

下面列了五个方面的需求，第一是Server SAN的业务场景，提供标准块存储接口来支持虚拟化环境、物理机环境，支持Oracle、DB2。第二，对于存储来讲，不丢数据，可靠性、稳定性很重要，所以要求支持数据强一致性，包括多副本配置策略，多存储池配置和管理，还有多路径与组件冗余、自动数据重构和备份容灾。另外还能支持多个级别的故障隔离，包括在主机这个级别上，可能在机架这个级别上，可能在机房这个级别上，我们是不是都能做到一定的故障域，来做相应的故障隔离。第三块是部署和运维上，服务器是具有通用架构的，支持计算资源分离部署，能够提供自动化部署和运维，能够用于大规模部署、运维和管理整个分布式存储系统，有统一管理的环境。第四块，Server SAN当前重点是在迅速这个环境下，要跟云管理平台集成，能够提供插件和自动化管理配置接口，和云管理平台做对接。最后一个是运维平台对接，能够做一些必要系统的性能、故障、容量等信息的集中监控。总体来讲这五大方面是满足的。

下面是一些比较细的条目，比如业务功能方面，最主要就是访问接口不能影响业务，存储业务能够正常访问到存储，这是最关键的，所以要求iSCSI的网关或者SCSI客户端来支持，这里面涉及到卷映射、访问路径、网关冗余等。另外在存储池上，可以把集群划分为多个不同的存储池，这里面能够创建池、扩容池，标红的地方跟业界伙伴讨论的时候，可能大家会觉得焦点比较集中的地方，比如缩容资源池，到底这个功能是不是一定要必需。还有设置资源池，支持设置硬盘保留容量阈值，还有副本数，两副本也好，三副本也好，这些策略是不是能在线修改，开始是三副本，可能中间改成两副本，过段时间又恢复成三副本，这种事情是不是允许发生。有的合作伙伴说没问题，也有合作伙伴提出质疑，可能这种东西实现起来会有很多复麻烦，包括数据重构的问题，包括数据一致性的问题，这些都是值得探讨的。在业务功能方面，比如逻辑卷功能，在卷创建的时候精简置备，现在可能大家都会支持，按需提供，需要多少黑暗你多少。但是厚置备是不是一定是必须，还是可选或者怎么样。删除、扩容到迁移的时候，我们要不要做在线的数据的卷的迁移。在快照里，包括整个卷的，是现在整个Server SAN很关键的。比如做一致性组快照，多个卷能不能做同时快照，后面还有数据重构，在Server SAN包括软件定义存储里，一旦发现数据重构，这里面可能会占大量的带宽，占很多时间在上面，甚至影响业务，这里面必须有相应的控制，包括看重构的速率、重构的时间、重构触发的点，这些需要在Server SAN里做必要的描述和要求。

运维管理，一个是强调图形界面，Ceph这个东西的存在，使得Server SAN门槛一下低了好多，很多用的是原生的Ceph的界面也好、操作方式也好，对于运维人员来讲，上了规模的软硬存储的环境来看，还是需要有图形化的界面，所以我们要求运维管理方面一定要有图形界面进行必要的操作。系统配置里有运行状态、配置流程、状态查看。服务器管理里能看到每一个硬件节点的拓扑，这个事情跟我的服务器节点有没有提一些要求，服务器是不是有必要的信息的设施。磁盘管理方面，里面会有磁盘查看，包括型号、转速、I/O值等，还有硬盘定位。硬盘发生故障之后，这个硬盘是在哪个架子上哪个服务器上的哪个节点，而且前面是不是应该有个灯来闪灯或者告警，这个跟整个下面的硬盘设备有一些关系，这些信息怎么集成进来，怎么体现出来，这是运维管理要求。还有维护模式，我是不是能够提供延迟机制，并不是发生故障进入维护模式，可以设定阈值或者设定触发期，满足这些条件以后用这个方式来做必要的数据恢复。还有远程复制管理，恢复支持两套或多套存储之间，通过IP链路进行数据复制和拷贝。还有版本升级里，里面会有很多分布式存储里会有软件的应用，会有操作系统，会有硬件驱动等，这些驱动补丁怎么通过管理界面做运维和相应的升级和维护。后面还有权限管理，为不同用户赋予特定的管理权限。

还有监控要求，主要是一些指标，会把整个性能采样的间隔、保存等反馈上来，故障告警预警，还有网关对接，比如SNMP，SNMP功能上其实是有限的，特别是存储场景里未必特别合适，有一种新的协议提供出来来方便做Server SAN的监控。另外还有日志报表也都是必不可少的。

性能要求方面，这里大概列的只是一个示例，要说起来，这个东西应该是以现网测试时，跟场景和整个测试步骤相匹配，光提这个指标，意思并不大，只想测一些大的数据库、小的数据库，多种场景下来做，这里会对随机写、数据读各种各样的场景做评测。性能测试方法很有可能后面会是一个场景化的做一个细化，不管从厂商角度来讲还是从用户角度来讲，希望大家能够帮助提供一些相关的输入，我们来完善这部分工作。

可靠性要求，我说的Server SAN，它的分布式架构比原来传统的很重要的一点，它在软件层面上进行维护，有可能单个的服务器节点可靠性差一些，但是通过集成化满足可靠性要求，这里面比较重要的是数据一致性，如果多个写操作，如果中间有问题了，那是不是能够回滚到一个确定的数据状态，所有的副本写完以后是不是才能成功，还有数据保护方面，我要有多副本的支持，处理一个故障时又发生心的故障，怎么来做这个事情，还有容灾的要求，这个是对Server SAN来讲都是比较关键的地方。存储最关键还是不能丢数据，特别是用到关键业务领域时。

下面是硬件要求，通用服务器设备，这里主要提到一些，因为像CPU、内存那些配置都很多，像我们电信也有很多定制服务器的规范，对于这种Server SAN的存储服务器，它会有些什么要求，比如它要有SSD，像NVMe SSD应该满足什么样的时延和要求，像NvDIMM，它对时延、带宽要求是什么，比如磁盘提供亚健康状态高清，还有减震设计，还有控制器支持故障告警和介质错误码，还有存储交换机应支持DCB和线速转发。

还有安全要求，其实安全里面没有多提，整个数据中心来讲，整个业务系统来讲，都会有自己的安全要求，从软件方面看其他的相关技术要求就可以了。而数据访问里，要CHAP的认证方式，还有通过存储网关隔离不同客户端。控制台方面，主要是对用户权限控制，安全块也有很多文章可以做的，如果感兴趣的伙伴我们可以一起来做这方面的事情。

还有兼容性要求，特别对于电信来讲，很多都是来自不同厂商的来源，比如现有存储节点服务器，有不同品牌和不同批次，怎么做到一块兼容、一块互操作。还有支持PCIe接口和U.2接口的NVMe SSD怎么做适配，还有存储节点，要支持阵列控制器，到服务器还要做一些Read的工作，整个硬件也要支持，还有支持高速以太网组网能力，还有支持主流数据库软件，还有Server SAN存储软件需要自带操作系统。

最后一点是云管平台，现在Server SAN在运营商场景里还是跟虚拟化整合得比较密切，这里面提供一种RestFul接口或者命令行接口，双方控制在一起，里面包括存储池管理、卷管理、快照管理、系统用户管理等等。做到云管平台要整合，OpenStack和VMware这两种类型要做必要的适合和整合。

以上稍微细一些，这部分内容比较枯燥，因为都是条条框框的东西，但是整个讨论过程还是很愉快的，刚刚跟大家汇报的，我们这个事情是在3月份的时候立项，也是在李博士和郭主任那边带着我们一块做这个事，现在借这个机会，诚挚邀请大家一起加入到规范制定当中，推动整个Server SAN产业往前进步，能够实现现网大规模推广，我的汇报就到这，谢谢大家！