TFS dataserver故障测试

简介:

本文将介绍和演示部分data server故障条件下的tfs数据写入问题。

 

环境介绍:

Tfs name server vip:  192.168.1.229

Tfs namerver 1: 192.168.1.225

Tfs namerver 2: 192.168.1.226

Data server 1:  192.168.1.226

Data server 2:  192.168.1.227

Data server 3:  192.168.1.228 

 

一:下列配置环境下,模拟单台data server 故障

1
2
max_replication = 3   #Block 最大备份数, default: 2
min_replication = 2   #Block 最小备份数, default: 2


修改完成后重启name server服务,本文中测试均采用一个data server 挂载点 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
225服务器:
# /usr/local/tfs/scripts/tfs  check_ns
  nameserver is running pid: 1061 
  
226服务器:
# /usr/local/tfs/scripts/tfs  check_ns
  nameserver is running pid: 32506 
# /usr/local/tfs/scripts/tfs  check_ds
  dataserver [ 1 ] is running 
  
227服务器:
# /usr/local/tfs/scripts/tfs  check_ds
  dataserver [ 1 ] is running 
  
228服务器:
# /usr/local/tfs/scripts/tfs  check_ds
  dataserver [ 1 ] is running


使用ssm工具查看当前的状态:


1
2
# /usr/local/tfs/bin/ssm -s 192.168.1.229:8108
show > server -m

wKiom1QqAtfAdMv1AALk3q99Su4334.jpg


1
2
3
4
写入测试:
# /usr/local/tfs/bin/tfstool -s 192.168.1.229:8108 
TFS> put /etc/security/limits.conf
put /etc/security/limits.conf => T1RtZTByJT1RCvBVdK success.


wKiom1QqAvrxS_rEAAYaJFehgbg241.jpg


1
2
3
4
5
6
关闭226的data server后再次写入测试
# /usr/local/tfs/scripts/tfs  stop_ds 1
  dataserver 1 exit SUCCESSFULLY 
  
TFS> put /etc/security/limits.conf  //发现写入失败
put /etc/security/limits.conf =>  fail.


wKiom1QqAymi_9b-AAdqMKvOaKo002.jpg


1
show > server -m //发现找不到master块

wKioL1QqA3uxrQP8AADc1xOwbpk246.jpg


二:下列配置环境下,重新测试

1
2
3
4
5
max_replication = 2   #Block 最大备份数, default: 2
min_replication = 2   #Block 最小备份数, default: 2
  
# /usr/local/tfs/bin/ssm -s 192.168.1.229:8108
show > server -m


wKiom1QqA4TSPyUAAAKMRppsr1I636.jpg


1
2
TFS> put /etc/security/limits.conf  //可成功写入
put /etc/security/limits.conf => T1btxTByhT1RCvBVdK success.

wKiom1QqA7TCr3HkAA0Y7niT2t8533.jpg


上传文件成功后,tfs会返回三个重要的参数:block_id,file_id和filename。我们可以通过admintool工具查询block_id在哪些dataserver上,然后用ds_clinet工具列出对应block上的所有的file_id和filename


1
2
3
4
5
6
# /usr/local/tfs/bin/admintool -s 192.168.1.229:8108
TFS > listblk 1011
list block 1011 success.
------block: 1011, has 2 replicas------
block: 1011, (0)th server: 192.168.1.226:10000 
block: 1011, (1)th server: 192.168.1.227:9998


三:总结

1: 如果想要成功写入,那么实际存活的data server的数量要大于或等于max_replication的设置值。例如3data server存活情况下,如果max_replication参数设置为3,那么data server 宕机一台,则会写入失败。

 

2: 当只存在一台data server的情况下,max_replicationmin_replication参数值均要设置为1,否则将会写入失败。


3: 猜想tfs的数据容灾机制

例如:3data server服务器,每台服务器提供三个mount point,一个mount point 可写入数据为200G; max_replicationmin_replication参数均设置为2那么实际上,总的tfs可用空间应该为200G * 3  *  3 = 1.8T 。 

由于max_replicationmin_replication参数均设置为2,也就是说数据至少要存两份。由此得出实际tfs的可用空间为900G

本文转自斩月博客51CTO博客,原文链接http://blog.51cto.com/ylw6006/1559618如需转载请自行联系原作者


ylw6006


相关文章
|
3月前
|
安全 数据库连接 数据库
可靠性测试-故障注入工具
【7月更文挑战第19天】可靠性测试中的故障注入工具对评估系统容错性与稳定性至关重要。常见工具如 **FaultInjector** (模拟多类故障)、**Xception** (针对特定组件注入错误) 和 **Chaos Monkey** (验证云环境下系统弹性) 帮助开发者提前发现潜在问题, 优化系统设计, 如电商公司通过测试确保促销期稳定, 金融机构降低交易风险。选择合适工具并结合业务场景测试对提升可靠性至关重要。
129 0
|
Kubernetes jenkins 测试技术
【Kubernetes的DevOps自动化,Jenkins上的Pipeline实现自动化构建、测试、部署、发布以及Bookinginfo实例的部署灰度发布故障注入流量】
【Kubernetes的DevOps自动化,Jenkins上的Pipeline实现自动化构建、测试、部署、发布以及Bookinginfo实例的部署灰度发布故障注入流量】
260 1
|
NoSQL MongoDB 开发者
故障测试2|学习笔记
快速学习故障测试2
故障测试2|学习笔记
|
NoSQL MongoDB 开发者
故障测试_1|学习笔记
快速学习故障测试_1
故障测试_1|学习笔记
|
SQL 前端开发 关系型数据库
探索MySQL-Cluster奥秘系列之SQL节点故障测试(10)
在这一小节中,我继续来对MySQL-Cluster集群环境的高可用性进行测试,接下来我们来看下当SQL节点出现故障时,MySQL-Cluster集群环境是如何保障其高可用性的。
361 0
|
Kubernetes 测试技术 网络安全
公司测试环境k8s节点故障解决
公司测试环境k8s节点故障解决
|
测试技术
软件测试面试题:自动化遇到用例fail掉如何排查故障?
软件测试面试题:自动化遇到用例fail掉如何排查故障?
140 0
|
存储 SQL 文字识别
虚拟机模拟部署Extended Clusters(四)故障模拟测试,存储链路恢复
asm 磁盘组 当链路恢复之后,磁盘状态显示MISSING(CRS_0000,OCR_0000)。 [grid@prod02 ~]$ sqlplus / as sysdba SQL*Plus: Release 11.
4851 0
|
存储 文字识别 Oracle
虚拟机模拟部署Extended Clusters(三)故障模拟测试,存储链路断开
集群状态: [root@prod02 ~]# crsctl stat res -t -------------------------------------------------------------------------------- NAME TARGET ST.
1560 0

热门文章

最新文章