tongsiying

阅读|运动|自律

0%

BlockStorage-summary

发表于 更新于 分类于
本文字数： 19k 阅读时长 ≈ 17 分钟 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
https://www.cnblogs.com/wuchanming/p/4893789.html
https://blog.51cto.com/yangdonglin/1246369
https://blog.51cto.com/ixdba/526452
https://blog.csdn.net/willinux20130812/article/details/45769471

http://www.mamicode.com/info-detail-1543374.html
http://www.zhetao.com/content275


ll 查看ll /lib/modules/3.10.0-693.25.4.el7.x86_64/build
[root@block-storage10 3.10.0-693.25.4.el7.x86_64]# ll /lib/modules/3.10.0-693.25.4.el7.x86_64/build
lrwxrwxrwx 1 root root 43 Jun 20  2018 /lib/modules/3.10.0-693.25.4.el7.x86_64/build -> /usr/src/kernels/3.10.0-693.25.4.el7.x86_64

openstack：
丁毅(18119690) 2019-04-15 16:05:10
https://github.com/huaweistorage/FusionStorage_OpenStack_Driver
丁毅(18119690) 2019-04-15 16:05:26
https://docs.openstack.org/mitaka/config-reference/block-storage/drivers/


http://dy.163.com/v2/article/detail/E278D02S05119IE4.html

001-介绍

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
国内 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和缓存作用
1
2
3
4
https://help.aliyun.com/document_detail/25382.html?spm=a2c4g.11186623.6.777.14ef227ccytzi6
阿里
谁是全球最快SSD云盘？5款主流云厂商SSD云盘性能测试 
https://www.sohu.com/a/219636624_695023

SNBS的特点

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
我们的快照用的cow还是row
陈玉强
row

我们的QoS流控用的什么算法？令牌桶吗@陈玉强 @格瓦斯 @金鑫
是的


哪些请求可以拿到令牌 
陈玉强(18101378) 2020-04-07 15:50:23 
所有请求都要来拿令牌，如果令牌足够，就把请求放过，如果令牌不够就把请求挂载桶的等待list上，等来了一批新令牌优先给等待list上的请求 
王老吉(17112231) 2020-04-07 15:51:18 
了解了 排队等放行 
陈玉强(18101378) 2020-04-07 15:51:32 
对 
王老吉(17112231) 2020-04-07 15:51:46 
是否放行取决于令牌够不够 
王老吉(17112231) 2020-04-07 15:51:56 
但还有一个问题 所有的请求都可以排队吗 
王老吉(17112231) 2020-04-07 15:52:01 
还是说你们会筛选 
陈玉强(18101378) 2020-04-07 15:52:29 
所有的 
陈玉强(18101378) 2020-04-07 15:52:49 
只有读写请求，没逼得 
陈玉强(18101378) 2020-04-07 15:52:51 
别的 
王老吉(17112231) 2020-04-07 15:52:57 
ok

002-网络架构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
1.openstack的【业务网（万兆）+存储网（对接snbs的万兆） 合设】、管理网（千兆）
snbs走access

@全体成员 跟数据中心和CTO沟通的情况如下：
1、计算节点业务网和存储网分离的方式，需要考虑增加网卡、布线、扎线、增加交换机，机柜资源、虚机的重启等一系列的操作，结合业内互联网厂商的使用模式，所以暂不采用此方案；
2、计算节点上的业务网和存储网公用万兆网卡，对应的交换机端口配置为trunk模式，OpenStack需要修改ovs支持，请宫旭飞安排周三前验证确认并评估工作量；
3、存储节点万兆网卡对应的交换机端口配置为access模式，可以与计算节点的存储网通信；
4、计算节点上的业务网和存储网是否分离，视后续应用模型，是否带宽是瓶颈再讨论；
5、测试在资源允许的情况下，可以考虑对两种方案都进行验证；

郭靓 2019-08-30 16:32:04
第一步就是这几台机器的万兆网卡接的交换机口找网络的配置成trunk动态聚合
第二步就是万兆交换机要上联汇聚并透传这些环境的vlan
目前看新港sit pre pst环境还不是都能相互通信
只能先接一个环境的来测
王星童 2019-08-30 16:32:44
那就选pst环境测
王星童 2019-08-30 16:33:00
我的万兆能通pst环境嘛？
郭靓 2019-08-30 16:33:05
还有就是 最好不要直接上现网环境 比较还在测试阶段
你们可以先模拟测试 比如建一个环境先跑起来
郭靓 2019-08-30 16:33:16
环境互通得问网络那边了


openstack 侧：
iscsi客户端服务端节点：
郭总，这两台机器，王星童还需要配置一个存储网络，之前这个机器是接了6跟线的，一组千兆管理网，配置动态access，一组万兆业务网，配置动态access，一组千兆业务网，配置trunk。目前看这两台服务器只接了四根线，另外两个网口也需要接线和配置


涉及网络磁盘
网络：
1.openstack的【业务网（万兆）+存储网（对接snbs的万兆） 合设】、管理网（千兆）
2.snbs走access
3.两个万兆做bond（存储sit）
[root@host102438014 ~]# cat /etc/sysconfig/network-scripts/ifcfg-bond0 
DEVICE="bond0"
BOOTPROTO="none"
ONBOOT="yes"
TYPE=Bond
BONDING_OPTS="mode=4 miimon=100 xmit_hash_policy=layer3+4"
IPADDR=10.243.80.14
GATEWAY=10.243.80.254
NETMASK=255.255.255.0

所有存储节点也需要关闭swap：
1.关闭swap：【KiB Swap都是0】
可以执行命令刷新一次SWAP（将SWAP里的数据转储回内存，并清空SWAP里的数据）
swapoff -a
sysctl -p  (执行这个使其生效，不用重启)

[root@host102442549 peace]# top
top - 16:55:39 up 99 days, 23:57, 10 users,  load average: 3.26, 4.35, 4.49
Tasks: 423 total,   1 running, 422 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.8 us,  0.7 sy,  0.0 ni, 90.6 id,  7.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 13173758+total,   527136 free, 14635356 used, 11657509+buff/cache
KiB Swap:        0 total,        0 free,        0 used. 11307603+avail Mem 

所有chunkserver节点需要关闭硬盘写缓存（Write Cache）：
http://ilinuxkernel.com/?p=897
1
2
3
4
openstack+pcp+snbs：
1、pcp建虚机是串行的，每台之间有个5s钟的间隔
2、这个虚机挂了个数据盘 根据fiaas的逻辑 挂数据盘时 先要ping通虚机 只有虚机网络通了之后才挂数据盘，虚机网络通 需要经历虚机系统启动 中间还有个cloud-init读取配置时间(120秒)
3、PCP目前优先指的是SNBS容量不够的情况下，调用本地
1
2
3
4
存储节点：
1.2019.12月之前压测环境是带raid 0的，WT模式
2.2019.12月之后压测环境去除raid 0，WB模式
对比下来WT性能好于WB模式，现阶段需要解决WB性能问题
1
2
3
4
5
6
7
8
建在块存储的虚机：
1.关闭swap：
可以执行命令刷新一次SWAP（将SWAP里的数据转储回内存，并清空SWAP里的数据）
swapoff -a
sysctl -p  (执行这个使其生效，不用重启)
 
2.关闭ps -ef | egrep "sendmail|postdrop"
上面都会刷内存
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
通过修改iscsi源码，可以实现不停业务扩容。在存储后端扩容块设备，然后在iscsi端通过重新扫描磁盘，块设备的容量更新成扩容后的容量

块应用场景：
1、 申请云硬盘（快照可选）最小10G，10G递增
需要用户填写内容：
空间、性能类型、计费模式（按量、包年包月）、名称、创建方式（备份创建、快照创建）

内部流程一：
1）根据性能类型选择存储池
2）在符合的存储池创建指定大小的卷1
3）创建target；（是否在安装时完成）
4）把卷1添加到target； 
5）设置target访问控制策略（所有/指定IP/IP段的initiator）；（是否在安装时完成，界面可编辑修改）

内部流程二：
a)提前在各个存储池创建一批固定规格的精简卷，同时提前完成流程一中3）5）
b)按照用户申请时，选择未使用的卷(卷空间>=申请空间，超过的空间进行缩容)

其他流程（客户端操作）：
设置CHAP认证用户名和密码，单向/双向； 
挂载后可以进行分区、格式化创建文件系统，挂载分区


刚才短会主要内容：
1、集群状态管理、维护。
2、整理修复、均衡、回收等功能，使用场景、测试用例、实现细节等
3、模块启动参数配置文件调研
4、文件权限相关功能，类似于文件系统，调研、字段预留
5、后面要兼容文件存储
6、深入挖掘事物序列号的用法
7、数据修复场景表格及对应的测试用例
8、回收流程与master配合，master起管理调度作用
9、主要模块分工情况，金鑫---master，朱晓伟---chunkserver，陈玉强---iscsi、gateway。后续主要工作内容、方向

003-理解

1
2
3
4
5
6
7
8
*master主要负责分配节点(目的：控制修复和均衡),master之间没有数据通信,但是相互之间是通过etcd来同步的，master本身数据存在内存中
*zone1、zone2、zone3之间是三副本，zone1、zone2、zone3数据是一致的。超过3个zone，exten副本数是分布在任意三个zone上的
*单个节点异常是无法创建克隆的，因为克隆是在本节点克隆，如果本节点异常了，该节点的克隆会失败
*嗯。读写数据块> 16k,会自动关闭读缓存。否则打开读缓存
*gateway 所有extent信息master提供给gateway，
loaction;extent信息（位置在哪个节点上），缓存的也是位置信息（主要是master给的）
inf信息 seq，chunkserver给的，（gateway主动来要的）主要是读和写
*克隆和快照过程中chunkserver异常导致只有两个副本的存在
1
2
3
4
5
支持精简配置（thin），当用户对卷进行写操作时，系统才分配实际物理空间如果用户申请1T，并不是真正预留1T的空间给用户，而是用多少分配多少
支持精简配置（thin），当用户对卷进行写操作时，系统才分配实际物理空间，用多少分配多少（百度的解释）

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

003-升级顺序

1
2
3
4
5

----------------------------- SNBS升级流程 ------------------------------
1.gateway和chunkserver顺序：先起chunkserver再起gateway
原因：gateway异常，这个gateway上卷切换到正常gateway上。如果异常的gateway恢复之后，卷切换回来，切换回过程中要去chunkserver加载元数据，发现chunkserver异常，就判定元数据缺失，可能就会引起修复
2.iscsiserver最后起

002-虚机环境：

DEV环境（测试) 登录方式 DEV环境（测试) 登录方式
10.242.180.207 root/suning@123 10.242.208.65 root/suning@123
10.242.180.208 root/suning@123 10.242.231.120 root/suning@123
10.242.180.209 root/suning@123 10.242.231.121 root/suning@123
10.242.180.210 root/suning@123 10.242.231.122 root/suning@123
10.242.180.211 root/suning@123 10.242.231.123 root/suning@123
10.242.180.212 root/suning@123 10.242.231.65 root/suning@123 
1
2
3
4
5
6
7
8
9
6台虚机配置：
1.数据盘共3个：
	2个数据盘 500g（裸盘，不要挂载目录）
	1个数据盘 100g（100GB的 /mnt/data）
	etcd元数据80g
2.opt   30g
3.最好申请6台，没有6台先申请3台
	4C8G
	系统：centos7.3

003-压测环境：

类型 压测环境（测试） 登录方式
10.238.161.1 root/123$%^yhn
10.238.161.2 root/123$%^yhn
10.238.161.3 root/123$%^yhn
snbs 10.238.161.4 root/123$%^yhn
10.238.161.5 root/123$%^yhn
10.238.161.6 root/123$%^yhn
10.238.160.1 root/654321
10.238.160.2 root/654321
计算节点 10.238.160.3 root/654321
10.238.160.4 root/654321
10.244.25.1 root/654321
控制节点 10.244.25.2 root/654321
10.244.25.3 root/654321
类型 pre环境（测试） 登录方式
snbsp http://snbspprexg.cnsuning.com
Nginx 10.242.227.143 suning@123
10.242.227.142 suning@123
jboss 10.242.227.141 suning@123
10.242.227.140 suning@123
MySQL5.7 10.238.147.127（主） suning@123
10.238.147.126（备） suning@123
10.238.147.125（vip） 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
存储节点
管理	
10.244.25.49 - 54	
网段：10.244.25.0/25

业务	
10.243.0.1-6	
业务地址段:10.243.0.1-125
网关:126
vlan:3600
网关:10.243.0.126
掩码:255.255.255.128"
网段：10.243.0.0/25

存储	
10.243.0.129-134	
存储地址段:10.243.0.129-253
网关:254
vlan3700
网关:10.243.0.254
掩码:255.255.255.128
网段:10.243.0.128/25

Bmc	
10.255.133.41-46	
BMC网关:10.255.133.254
BMC掩码:255.255.255.0
从1——253

root/123$%^yhn
1
2
3
4
5
6
7
8
9
10
计算节点	
"10.255.133.40---BMC
10.244.25.48---管理
10.243.0.8---业务
10.243.0.136---存储"

"10.255.133.39---BMC
10.244.25.44---管理
10.243.0.7---业务
10.243.0.135---存储"
1
2
3
4
5
6
7
8
9
10
11
控制节点	
"10.255.133.38---BMC
10.244.25.3---管理"

"10.255.133.37---BMC
10.244.25.2---管理"

"10.255.133.36---BMC
10.244.25.1---管理"

654321
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
金泉洁 2019-01-23 16:15:30
Inquiry Data: SEAGATE ST300MM0006     0003S0K5BH1Y            
Inquiry Data: SEAGATE ST300MM0048     N001S0K6G7KK            
Inquiry Data: BTDV71730B79480BGN  INTEL SSDSC2BB480G7                     N2010112
Inquiry Data: BTDV717301VS480BGN  INTEL SSDSC2BB480G7                     N2010112
Inquiry Data:             ZC1753E8ST4000NM0035-1V4107                     TN04    
Inquiry Data:             ZC1750B6ST4000NM0035-1V4107                     TN04    
Inquiry Data:             ZC1758JVST4000NM0035-1V4107                     TN04    
Inquiry Data:             ZC17528HST4000NM0035-1V4107                     TN04    
Inquiry Data:             ZC1746SVST4000NM0035-1V4107                     TN04    
Inquiry Data:             ZC1753A8ST4000NM0035-1V4107                     TN04    
Inquiry Data:             ZC174GRDST4000NM0035-1V4107                     TN04    
Inquiry Data:             ZC174Q5MST4000NM0035-1V4107                     TN04

金鑫 2019-01-23 16:15:48
这个是是什么？
金泉洁 2019-01-23 16:18:12
系统盘（SAS接口）：西数2块 280GB（做Raid1）
数据盘SSD（SATA接口）：英特尔2块 450GB（做Raid0）
数据盘SATA（SATA接口）：希捷8块 3.6TB（每块都做成了Raid0）

【系统盘（SAS接口）：西数2块 280GB（做Raid1）这个应该是用的2.5寸的10Krpm SAS盘】--王坚say

10.244.33.1-10.244.33.250    10.244.34.1-10.244.34.250新分配的；网关分别是10.244.33.254/24 ;   10.244.34.254/24

004-全闪环境

DEV环境（测试) 登录方式
10.244.208.3 root/suning@123
10.244.208.4 root/suning@123
10.244.208.5 root/suning@123
10.242.180.211 root/suning@123

004-对接环境

1
2
3
4
5
6
7
snbs-openstack-pcp对接环境
10.243.30.1
10.243.30.2
10.243.30.3
root/654321

节点网络时断时续

005-sit环境ocata8 集群

类型 SIT环境（半生产) 登录方式
snbsp http://snbspsit1.cnsuning.com
10.243.171.216（vip）
Nginx 10.243.83.101 suning@123
10.243.83.100 suning@123
jboss 10.243.83.99 suning@123
10.242.227.140 suning@123
MySQL5.7 ip1：10.243.142.177 suning@123
10.238.147.126（备） suning@123
10.238.147.125（vip）
读写vip：10.243.142.175
SIT环境（半生产,谨慎操作) 机架 模块
10.243.80.13 机架1 master/etcd/tgtmaster
10.243.80.14 机架1
10.243.80.15 机架1
10.243.80.16 机架2 master/etcd/tgtmaster
10.243.80.17 机架2
10.243.80.18 机架2
10.243.80.19 机架3 master/etcd/tgtmaster
10.243.80.20 机架3
10.243.80.21 机架3
虚机IP地址 物理机IP 镜像
10.237.2.32 10.243.72.23 win_2008_32_update_securityplugin_20190524_001
10.237.2.33 10.243.72.80 win_2008_32_update_securityplugin_20190524_001
10.237.2.34 10.243.72.110 win_2012_64_update_securityplugin_20191218_stable
10.237.2.35 10.243.72.22 win_2012_64_update_securityplugin_20191218_stable
10.237.2.37 10.243.72.62 windows2016_x64 update_securityplugin_50G_20191209
10.237.2.38 10.243.72.27 windows7_Professional_x64_20190524_updateSecurityPlugin_001
10.237.2.39 10.243.72.110 windows7_Professional_x64_20190524_updateSecurityPlugin_001 
1
2
3
4
5
6
7
8
建了两台windows：

windows 2012Server（64bit）： 10.237.3.83
centos 7：10.237.3.72
window 7：10.237.3.173


密码都是cloud@123
1
2
3
4
2012 administrator/cloud@123
2016 administrator/w5cx5WI/
2008 administrator/w5cx5WI/
win7 administrator/cloud@123

006-java开发环境

java开发 登录方式
10.27.38.75 root/cloud@123
10.27.38.76 root/cloud@123
10.27.38.77 root/cloud@123
java开发 登录方式
10.27.38.78 root/cloud@123
10.27.38.79 root/cloud@123

007-自动化环境

环境 登录方式
10.242.12.8 root/suning@123
10.242.12.9 root/suning@123
10.242.12.10 root/suning@123
Robotframework 系统 登录方式
10.242.11.232 对象存储 administrator/mOQ:k03g
10.242.11.233 块存储 administrator/Y2hC0!xc（已修改为suning@123）

006-

1
2
3
4
5
6
7
8
9
10
新港给块sit扩容的6台大盘+ssd的机器已到
就是这批里的，4块SSD+8块4Tsata
这6台 我们可以单独搭个独立集群 自己先测测这种硬件配置，后面等SIT上新版本后，在把这个集群拆了扩到原有SIT@王星童 
检查下机器的配置 比如是不是SAS直通的

4块SSD怎么分配
1个元数据缓存盘，
2块拿出来做chunkserver的写缓存和gateway的读缓存，（4个3G分区给写缓存，剩下的给gateway读缓存）

考虑V2.2版本扩容等问题，以及版本升级等问题
1
2
3
4
5
6
对象、块、文件系统的作用，本质区别
容灾和备份啥区别
数据的走向
性能

和ceph比较的区别

openstack

1
2
3
4
5
6
7
1背景简介
	OpenStack是开源的云计算IaaS解决方案，当前采用的OpenStack版本是Ocata。线上部署架构中，块存储直接采用计算节点本地磁盘，底层由LVM实现块存储的生命周期管理，由libVirt实现块存储向虚拟机的挂载和卸载等操作。镜像文件直接存储在本地磁盘。
	SNBS是由公司内部存储团队研发的集中存储系统，依托iscsi协议，实现存储的集中管理以及存储的克隆、快照、纠删码等。存储资源可以灵活扩展、统一管理，操作便捷。
	本集成工作完成OpenStack中存储实现向SNBS的迁移，由SNBS作为OpenStack相关存储的后端实现，对OpenStack相关存储进行统一管理和运维。
	
2对比分析
环境说明：块存储及镜像均采用计算节点本地磁盘，虚拟机从镜像启动，下表列举相关功能点或问题，并从本地磁盘和集中存储两种方式进行对比分析。
功能\问题 相关背景 本地磁盘 集中存储 潜在问题
虚机热迁移 1. 所处计算节点负载过高，部分虚机迁移至低负载计算节点2. 其他迁移需求 虚机热迁移涉及虚机内存、计算节点本地系统盘以及数据盘的三部分迁移操作 仅涉及到虚机内存迁移，虚机系统盘和数据盘均在集中存储 内存迁移部分需要进一步优化，可最大提升虚机热迁移效能
数据备份\快照 对虚机系统或数据进行备份或快照 备份\快照操作均在计算节点或跨计算节点，若计算节点存储资源不足，需要扩展磁盘 备份\快照操作均在集中存储，存储资源可弹性管理 暂无
虚机启动 虚机镜像启动、卷启动 由于处在本地，启动速率较高 由于处在集中存储，需要通过网络加载镜像卷 需要对卷启动进一步辅助优化
计算节点重启 在一些特定问题或需求下，计算节点进行重启操作 计算节点重启操作将会影响虚机运行 在重启前可将虚机快速迁移至其他计算节点 需要对重启的情况进行详细摸排
块存储相关 块存储创建、删除、挂载、卸载等生命周期管理 块存储挂载可能执行在虚机所处计算节点以外的节点 块存储生命周期管理操作均在集中存储 需要针对集中存储侧请求无响应或其他相关问题做出合理决策
存储故障 线上环境存储层故障 本地磁盘故障将造成计算节点或虚机无法运行，故障恢复较为缓慢 集中存储提供数据备份冗余或数据恢复机制(纠删码) 暂无
资源占用 在不同结构中，存储资源所占用的计算、内存、IO等资源 块存储操作将占用所处计算节点的CPU、内存资源以及大量IO操作 集中存储将存储资源剥离计算节点，计算节点 暂无
运维效率 针对不同结构所花费的运维工作以及效率 存储服务分散在各计算节点，运维精力较为分散 存储资源集中管理、统一运维 暂无 
1
2
3
4
5
6
7
8
9
10
以上表格列举出部分功能\问题对比分析点，还有其他实际问题，不再一一列举。

3相关组件
3.1Cinder
	Cinder是OpenStack的Block Storage服务，负责块存储的创建、删除、挂载、卸载、快照等生命周期管理操作。Cinder可为虚机提供数据卷功能，也可作为虚机的启动卷或作为Glance服务的后端存储服务。Cinder在OpenStack以组件形式存在，以高可用、容错、可恢复为目标，并制定上层统一标准，实现对各类存储厂商的兼容，可灵活扩展和切换。
3.2Glance
	Glance是OpenStack的Image服务，负责镜像Image的存储、下载以及较为灵活的编排功能，提供虚机镜像，同时Glance实现各类存储集成和兼容以及多种Image Type的支持和转换。
3.3Nova
	Nova是OpenStack的核心服务，负责管理和维护云环境的计算资源，虚机的生命周期管理。具体涉及到虚机CPU、内存、磁盘、镜像、网络各类资源的管理，以及虚机创建、删除、迁移、扩展、关闭等操作。
4总体设计

1
2
3
4
	Cinder组件中实现SNBS Plugin，作为Cinder与SNBS存储集群的桥梁，SNBS存储集群作为Cinder的Storage Provider。OpenStack Ocata版本中Glance可将Cinder作为Image存储后端，故在Ocata版本中，Glance与SNBS的集成实现直接交给Cinder即可，若为旧版本OpenStack，则需要在Glance中实现SNBS Plugin，作为Glance与SNBS存储集群的桥梁。Nova组件调用Glance完成镜像从远端到本地的加载，调用Cinder实现块存储的挂载\卸载等。虚机的卷启动等详细流程参见5.3小节。
	
5流程设计
5.1Cinder

1
2
3
	Cinder API接收请求后，将相关指令消息发送到对应的Queue(RabbitMQ)，Cinder Scheduler监听对应的Queue进行实际调度，筛选出合适的Volume节点并发送指令消息到Queue，Cinder Volume监听Queue，接收指令，通过SNBS Plugin完成指令操作。对于Volume挂载到虚机，Nova volume根据Volume ID获取对应的Meta信息，将SNBS存储集群中具体的存储节点的块设备挂载到计算节点，再有libvirt实现Volume修改VM xml，并挂载到虚机。
	
5.2Glance

1
2
	Glance API接收请求，由Glance Registry完成镜像的Meta信息操作，由Glance Store中的SNBS Plugin与SNBS存储集群通信，完成镜像文件的上传或删除。对于OpenStack Ocata版本，Glance Store可通过Cinder直接操作。
5.3Nova

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
	以Boot from image(Create a new Volume)举例，Nova服务从Glance服务拉取Image文件到计算节点本地，生成启动卷，通过Cinder Client上传到SNBS存储集群，并将存储集群远端启动卷块设备挂载到计算节点本地，后从该启动卷启动虚机。
6功能设计
6.1Cinder
1.一期目标
创建块存储
删除块存储
克隆块存储
查询块存储
2.二期目标
扩展块存储
创建快照
删除快照
回滚快照
查询快照
QOS
6.2Glance
上传镜像
删除镜像
6.3Nova
卷启动
镜像启动(创建新卷)
卷快照启动(创建新卷)
7接口设计
请参见《块存储接口定义V3.0》和《SNBS-接口整理》文档。
备注：OpenStack对外API服务接口不需改变
8部署示例
8.1延续现有部署架构
结合当前线上部署结构，部署SNBS集群后，部署结构如下：

1
2
3
以上图示结构不改变当前环境部署结构，部署SNBS存储集群后，调整Controller Node和Compute Node相关服务的存储配置。
8.2优化现有部署架构
将SNBS作为集中存储，Cinder\Glance\Nova完成与SNBS集中存储的集成，Cinder Volume可从Compute Node中去除，部署在Controller Node中即可。部署结构如下：

以上图示结构需要改变当前部署结构，将Cinder Volume迁移至Controller Node。

测试

1
2
3
正常测试是测试内存的2倍
比如内存是8g，那就是测试16g的数据
16g/目录数=结果*1024*1024=转换的结果/文件大小=结果（结果测试的文件数）

文件系统准确性：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
文件系统准确性：
见附件：file_accuracy.sh  if_accuracy.sh
file_accuracy.sh
#!/bin/bash
function rand(){
    min=$1
    max=$(($2-$min+1))
    num=$(cat /proc/sys/kernel/random/uuid | cksum | awk -F ' ' '{print $1}')
    echo $(($num%$max+$min))
}

num=11
num_txt_max=10001
for((i=1; i<${num}; i++));do
		for((j=1; j<${num_txt_max}; j++));do
		rnd=$(rand 100000000 1000000000)
		rnf=$(rand 100000000 1000000000)
		a=`echo $rnd$rnf`
		b=`echo -n "$rnd$rnf"|md5sum`
		c=`date +%s`
		d=`hostname`
		echo -e "$d\t$c\t$b\t$a" >>"$i".txt
		done
done

if_accuracy.sh
#!/bin/bash
hostname1=sdfspstapp04
a=()
a=`ls *.txt`
pid=$$
thread=200
tmp_fifo="/tmp/$$.fifo"
mkfifo $tmp_fifo
exec 8<>$tmp_fifo
rm $tmp_fifo
for i in $(seq 1 $thread)
do
    echo
done >&8

for item in ${a[@]}
do
        read -u8
        {
		i=0
		b=()
		c=()
		b=`cat ${item}|awk '{print $5}'`
		c=`cat ${item}|awk '{print $3}'`
		c_txt=`echo ${c[@]}`
		for item2 in ${b[@]}
		do
			b_md5=`echo -n "${item2}"|md5sum|sed 's/ -//g'`
			list[$i]=$b_md5
			i=`expr $i + 1`
		done
		list_test=`echo ${list[@]}`
		if [ "$c_txt" != "$list_test" ];then
                	echo $item >>error.log
        	fi
		first_num=`cat ${item}|grep "$hostname1" |awk '{print $2}'|sort|uniq|head -1`
		end_num=`cat ${item} |grep "$hostname1"|awk '{print $2}'|sort|uniq|tail -1`	
		D1=`expr $end_num - $first_num + 1`
		D2=`cat ${item}|grep "$hostname1" |awk '{print $2}'|sort|uniq|wc -l`
		if [ "$D1" != "$D2" ];then
                       echo $item >>error.log
                fi
		D3=`cat 1.txt |awk '{print $4}'|uniq`
		if [ "$D3" != - ];then
                       echo $item >>error.log
                fi
        echo "" >&8
        } &
done

wait
exec 8>&-

拷机模型

蛙测

1
2
3
4
5
HTTPPluginControl.getConnectionDefaults().timeout = 6000000//定义HTTP请求超时时间，单位毫秒

这是是一连串的逻辑，超时本身可以随意设置，但是我们性能指标采集是默认5s一次，且超过2分钟没有数据上报就判定为异常终止任务；所以你上面这个超时违反了约束

你不设置timeout，就不会超时，一直等请求返回，不设置timeout就会一直等待
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
读事先准备好文件
追加写、读128k（10G文件）
10G*400  4T 128k  32768   ---81920文件82000

400台，轮询（线程选了这么多虚机）结束了再选下下一批

计算出来，突发线程针对60%的虚机（240台），连续搞几把（3遍）9（到时候再定） 【加sleep】

1.正常压测任务确认模型和线程数
2.突发压测任务确认模型和线程数
只有正常压测任务和包含突发压测任务的读写响应延时对比
查看蛙测的iops、时延统计

注：
1.put 写 get 读  nginx  请求若干个 高并发  同时有多少写  多少文件

---------------------------------nginx-----------------------------------------------
//顺序写【201】
curl -X PUT -v "http://10.244.30.145/seq-write?fp=/opt/seqfile.1&fs=102400&bs=4"
//追加写【201】
curl -X PUT -v "http://10.244.30.145/append-write?fp=/opt/appendfile.1&fs=1024&bs=4"
//顺序读【200】
curl -X GET -v "http://10.244.30.145/seq-read?fp=/opt/seqfile.1&bs=4"
//随机读【200】
curl -X GET -v "http://10.244.30.145/rand-read?fp=/opt/seqfile.1&bs=4" 


*/5 * * * * /usr/sbin/ntpdate 10.242.39.22

fio

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
for i in test100g test200g test300g test400g test500g test600g
do
	DIR="/opt/vdbench/cases/fio/${i}"
	mkdir -p ${DIR}/1 ${DIR}/2 ${DIR}/3 ${DIR}/4 ${DIR}/5 ${DIR}/6 
	cd ${DIR}/1
	fio -direct=1 -iodepth=128 -rw=randwrite -ioengine=libaio -bs=4k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=/mnt/${i}/iotest -name=Rand_Write_Testing -write_bw_log=rww -write_lat_log=rww -write_iops_log=rw >> ${DIR}/fio.log
	echo "------------------------------------------" >> ${DIR}/fio.log
	cd ${DIR}/2
	fio -direct=1 -iodepth=128 -rw=randread -ioengine=libaio -bs=4k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=/mnt/${i}/iotest -name=Rand_Read_Testing -write_bw_log=rww -write_lat_log=rww -write_iops_log=rw >> ${DIR}/fio.log
	echo "------------------------------------------" >> ${DIR}/fio.log
	cd ${DIR}/3
	fio -direct=1 -iodepth=64 -rw=write -ioengine=libaio -bs=1024k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=/mnt/${i}/iotest -name=Write_PPS_Testinig -write_bw_log=rww -write_lat_log=rww -write_iops_log=rw >> ${DIR}/fio.log
	echo "------------------------------------------" >> ${DIR}/fio.log
	cd ${DIR}/4
	fio -direct=1 -iodepth=64 -rw=read -ioengine=libaio -bs=1024k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=/mnt/${i}/iotest -name=Read_PPS_Testing -write_bw_log=rww -write_lat_log=rww -write_iops_log=rw >> ${DIR}/fio.log
	echo "------------------------------------------ " >> ${DIR}/fio.log
	cd ${DIR}/5
	fio -direct=1 -iodepth=1 -rw=randwrite -ioengine=libaio -bs=4k -size=1G -numjobs=1 -group_reporting -filename=/mnt/${i}/iotest -name=Rand_Write_Latency_Testing -write_bw_log=rww -write_lat_log=rww -write_iops_log=rw >> ${DIR}/fio.log
	echo "------------------------------------------ " >> ${DIR}/fio.log
	cd ${DIR}/6
	fio -direct=1 -iodepth=1 -rw=randread -ioengine=libaio -bs=4k -size=1G -numjobs=1 -group_reporting -filename=/mnt/${i}/iotest -name=Rand_Read_Latency_Testingrandwrite -ioengine=libaio -bs=4k -size=1G -numjobs=1 -group_reporting -filename=/mnt/${i}/iotest -name=Rand_Write_Latency_Testing -write_bw_log=rww -write_lat_log=rww -write_iops_log=rw >> ${DIR}/fio.log
done

流程

基本流程：

修复：

扩容：

离线超时设置：

数据恢复：

缩容：

挂接 iSCSI volume 给虚机的大致流程

挂接 Ceph RBD 卷给虚机的大致交互流程

其它

1
2
3
4
虚拟机在 OpenStack 里的在线迁移https://blog.csdn.net/tomstrong_369/article/details/79747286 ，可以了解下
@何抗洪 @韩盛中 http://docs.ceph.com/docs/mimic/rbd/rbd-openstack/     这是ceph rbd  glance 的介绍，以及
@王星童 ISCSI客户机及多路径的设置   https://blog.csdn.net/huzhenwei/article/details/80690623
把gateway和chunkserver的GOGC都调成100：

赞赏一下吧～