resume

自我介绍
本身负责哪一块；
ceph维护；
sdfs维护；
对象存储介绍；（涉及多活测试、region、迁移、垃圾数据）
etcd使用；（备份，版本，能力）
snbs、实现原理、模块功能、当前使用情况、性能（涉及多家厂家的性能数据对比）、一些功能介绍（基本功能：独立克隆、链接克隆、断链、快；租约、一些多读、超时优化、读写缓存）；Iscsiserver命令积累

其它能力：
mysql一些常用命令（包括数据库备份、数据库恢复）
自动化编写能力；
工具使用；（突出改造vdbench）
手撕脚本；（数据一致性脚本实现逻辑、crc32、hash）
python、java

自动化
协议
sql
etcd
redis
网络：dns dhcp
接口测试：
代码：c c++ java
测试工具：

简单介绍：

自我介绍下：
我负责过的产品有分布式对象存储（oss、uimg）/自研分布式块存储（snbs）/分布式文件系统（苏宁叫sdfs，外面叫glusterfs）以及ceph
当前的话sdfs和ceph只有我一个人在维护；
sdfs就是生产的应急以及和容器、ks8s对接工作（主要是给业务放镜像之类的，当前苏宁用的人已经不多了）
ceph用fio测试性能以及在生产上搭建过环境并部署nagiso进行监控（ceph主要是公有云搭建的）
对象的现在已经交接出去了，主要产出就是自动化案例的编写、多活项目的测试、以及新增region模块的测试工作、以及多活上线和region的上线
当前主要任务就是块存储，2018年8、9月开始介入测试，到2019年7月份都是我一个人在搞，包括测试设计、测试案例、验收方案、测试报告、性能测试、poc测试脚本、对接openstack、以及上线生产

技能方面的话：
自动化;
1.我们使用的是robotframework，对象基本功能的自动化都是我维护的，之后region，多活案例都是我新增上去的，这个比较简单，就是上传下载校验md5值
，块存储这边开始只搞了接口，可以快速回归基本所有的接口，今年我已经开始搞流程较为复杂的案例自动化，如自动调用vdbench跑读写，校验副本一致性，克隆、快照和原卷的副本一致性、增加冷热扩容的测试案例

shell:
1.积累还是挺多，脚本执行带参数，多线程这边都可以，然后之前sdfs需要搞监控需要写nrpe脚本，sdfs相关的都是我写的

python和java：
1.java之前也用过，现在用的少了
2.主要是使用python，改造了vdbench，现在不管是拷机还是跑性能，自动的将vdbench的结果生成折线图，已经各个节点cpu、内存、磁盘、以及捞取各模块日志，筛选日志中的实时性能打印（类似iostat）我这边都会生成折线图，方便分析；另外的数据一致性校验的小工具，为了校验本地镜像和snbs的镜像或者两个卷之间的数据一致性比较

ETCD：
etcd正常是三个节点，节点越多性能越差，etcd对并发数也有限制为10000
当集群内健康机器少于 3 台的时候,客户端报错,集群整体不可用

原来版本：3.13（支持v2版本的命令）
当前版本：3.5.0-pre

数据库：
mysql之前也一直用，现在用的不多，但是基础还在

snbs

环境说明：

机器数量：共9台

6台存储服务器：

配置2块cpu， 有40个逻辑CPU.； 每个CPU核心数 10核
内存128G
缓存盘两块960G*2
主存盘：4T*10

3台元数据服务器：

2块cpu， 有40个逻辑CPU.； 每个CPU核心数 10核
内存128G
缓存盘两块960G*2

一个块存储集群内部有多个区域（region），一个region有若干个资源池（POOL），每个POOL可以有多个故障域（ZONE）。每个集群只有一组MASTER，使用ETCD存储元数据（卷信息和chunk信息）。每个ZONE有若干个chunkserver
zone1、zone2、zone3之间是三副本，zone1、zone2、zone3数据是一致的。超过3个zone，exten副本数是分布在任意三个zone上的

1.master主要负责分配节点(目的：控制修复和均衡),master之间没有数据通信,但是相互之间是通过etcd来同步的，master本身数据存在内存中
2.gateway 所有extent信息master提供给gateway，loaction;extent信息（位置在哪个节点上），缓存的也是位置信息（主要是master给的），info信息 seq，chunkserver给的，（gateway主动来要的）主要是读和写


ISCSI：对外提供iscsi接口，因此ISCSI Server通过tgt实现iscsi的target，负责将iscsi客户端（iscsi initiator）发过来的iqn操作请求转发到对应的Getway，实现对绑定的块设备卷的操作；

Getway：作为SNBS的数据处理网关，将ISCSI Server发过来的数据读写请求映射到块设备卷的读写逻辑处理：如果是写请求，Getway会根据对应卷操作的偏移和size，到Master创建chunk，并到对应的Chunkserver完成实际数据的写入；如果是读请求，Getway根据本地缓存中的元数据信息，找到对应的chunkid，并到对应的chunkserver读取数据；

Master：作为SNBS大脑，负责核心元数据的存储、资源的分配、任务（均衡、修复、迁移）的调度等。核心元数据包括卷信息和chunk信息。Master通过etcd进行选主：MASTER上电时会统一发事务请求给ETCD进行选主，当主Master挂了后，etcd会通知其他Master竞争选主；

Chunkserver：存储数据的服务器。SNBS的Chunkserver最大的特点就是不通过文件系统直接管理裸盘，提高了数据的读写效率，并通过追加写和元数据缓存进一步提高写性能。一个Chunkserver管理若干个裸盘

Etcd：首先ETCD提供Master的数据存储；其次，ETCD还作为Master模块选主的仲裁。ETCD自身通过raft协议进行选主。

Region：一个逻辑概念，不同的区域用于区分一个集群中不同的机房，目前一个集群只会存在于一个机房；

Pool：SNBS会将一个区域中的资源划分为多个资源池，一般是依据不同的存储介质进行划分，通常分为全闪、混合、SATA3中资源池类型，以满足不同的用户对性能的要求。不同的资源池间的数据支持迁移和克隆；

Zone：每个资源池内部有多个故障域（Zone），一个故障域可以是一个机架，一个故障域损坏不会影响整体集群的服务。块存储目前是基于副本机制实现数据的可靠性，同一个chunk的不同副本会在不同的故障域；


*单个节点异常是无法创建克隆的，因为克隆是在本节点克隆，如果本节点异常了，该节点的克隆会失败
*克隆和快照过程中chunkserver异常导致只有两个副本的存在

支持精简配置（thin），当用户对卷进行写操作时，系统才分配实际物理空间如果用户申请1T，并不是真正预留1T的空间给用户，而是用多少分配多少
支持精简配置（thin），当用户对卷进行写操作时，系统才分配实际物理空间，用多少分配多少（百度的解释）

创建链接克隆卷？
创建链接克隆卷可以理解为从快照创建卷

对象、块、文件系统的作用，本质区别
容灾和备份啥区别
数据的走向
性能

和ceph比较的区别

国内 Ceph 厂家一直存在重UI、重功能、而轻稳定性、轻性能的不良倾向，过分依赖Ceph开源社区，甚至无
法对Ceph优缺点有一个深入的认识，自然无从改进Ceph的稳定性和性能面临的问题。


1）块存储目前在苏宁可归纳为两类使用场景：传统的IOE环境中的商用块存储和云计算环境中的本地块存储。其中IOE环境中使用富士通、IBM等外部高端存储，云计算环境中使用X86服务器的本地磁盘存储。云计算是集团IT基础架构发展方向，云计算环境中的块存储是苏宁存储平台优化的重点；
2）为虚机、容器、数据库提供后端高可靠、高性能、高可用的分布式块存储，解决虚拟化（系统盘、数据盘）使用本地存储+RAID5，不支持跨节点高可用问题；
3）系统盘在线热迁移，业务几乎无中断，影响小；有状态应用数据盘，数据不再迁移，速度更快，解决由于资源争抢、热点打散、负载均衡，需要进行虚机迁移,速度慢，业务中断的问题；
4）计算和存储分离，资源分配更加合理,存储性能和容量能够单独规划、单独扩容，解决分配资源时，调度算法维度过多，资源碎片，服务器中SSD磁盘利用率和IO使用率低的问题；
5）不需要数据库级备份，新机器重新挂载数据盘即可恢复，时间短；使用快照可以快速恢复到任意时间点
，解决数据库备份方式单一，目前只支持数据库级备份，备份rpo、rto长的问题；
6）应用数据盘容量可以纵向调整在线弹性扩容，支持精简配置，根据业务使用情况动态分配空间，解决数据库需要扩磁盘，部分宿主机无可用空间扩容。

各类存储适合的应用
1、块存储：适合数据库应用，需要裸盘，且iscsi协议效率较高；
2、文件存储：数据共享容易，利于跨平台文件共享；
3、对象存储：适合为云盘供应商提供底层支撑，静态网站托管，云备份和容灾，视频监控的存储以及构建海量存储资源池；

工作不一样，master是管理元数据的，gateway是对外api和缓存作用

苏宁自研的块存储，简称SNBS：有些模块和GFS差不多，GFS也没开放过原码，GFS不是glusterfs，是谷歌的一个文件系统，有借鉴，但底层逻辑还是有区别的。
snbs特点：
1.高性能： 以SSD设备作为缓存，充分利用SSD低延迟，高IOPS的特性
2.高可靠
	a.通过多副本，保证在服务器宕机时，数据不会丢失
	b.多副本采用强一致性写，保证数据一致性
3.低消耗
	a.兼容商用x86服务器，无特殊硬件需求
	b.存储仅占用有限的计算资源，避免额外购置存储服务器，完美适配超融合架构
	（基本10个机械盘，内存往中等了算32G（实际使用没这么多），大了算64G。不排除以后会占用更多。  cpu基本上一个盘占一个核）
4.横向可扩展
	a.性能与容量同步线性扩展
	b.单集群最大可支持255个节点
5．易于集成
	a.提供标准的isCSI接口，完整的RESTful API支持
	b.支持KVM，VMware ESXi， XenServer等虚拟化/云平台

写缓存：
	对于大小块混合写的业务场景，在SSD Cache中可以识别出大于等于128K的io【snbs是大于1M】，将其Bypass直接下发到HDD，用户可以自定义大块io Bypass的SSD Cache阈值，默认大块io优先写入SSD Cache中，当达到阈值后，超出的大块IO会选择下发到HDD中。但是当HDD盘利用率也较高时，大块io仍然回到SSD Cache中。
	通过这个方式，大块io可以同时打满HDD和SSD，能够解决以下两方面问题：
	1大块io访问SSD Cache会受限于SSD的带宽，影响整个集群的带宽。
	2大块io访问SSD Cache会增大SSD的压力大幅影响SSD上的其他小块io时延。
	
合并刷盘技术：
	在XSKY产品的io栈中，离散的随机小块io会先写到SSD中，通过合并刷盘技术将离散随机小块io合并成连续大块io写入到HDD中，提升系统整体IOPS性能同时减少HDD硬盘寻道次数，降低硬盘损耗，延长硬盘使用寿命。
	
	 1.2.7热卷缓存锁定对指定的卷实现专用缓存加速，避免性能瓶颈。