TFS运维平台改造

1

TFS负责运维的同学在工作过程中,积累了各种运维脚本,全部使用shell编写,用于完成TFS机器的上下线、坏盘下线、集群同步、迁移等功能,这些脚本构成现在的运维平台;但由于运维同学的不断更替,新同学在使用前辈们留下来的运维脚本过程中经常踩坑,严重影响运维工作效率。

以下列举了TFS运维过程中,出过的一些问题: (更多…)

巧用Systemtap注入延迟模拟IO设备抖动

0

当我们的IO密集型的应用怀疑设备的IO抖动,比如说一段时间的wait时间过长导致性能或其他疑难问题的时候,这个现象处理起来就比较棘手,因为硬件的抖动有偶发性很难重现或者重现的代价比较高。

幸运的是systemtap可以拯救我们。从原理上讲,我们应用的IO都是通过文件系统来访问的,不管read/write/sync都是,而且我们的文件大部分都是以buffered方式打开的。在这个模式下,如果pagecache不命中的话,就需要访问设备。 知道了这个基本的原理以后,我们就可以用万能的systemtap往vfs的读写请求中受控的注入延迟,来达到这个目的。

要点有以下几个:
1. 受控的时间点。
2. 延迟时间可控。
3. 目标设备可控。

我写了个脚本注入IO延迟,模拟ssd/fio硬件的抖动来验证是否是IO抖动会给应用造成影响,三个步骤如下:
步骤1: 编译模块
(更多…)

TFS Erasure code实现方案

0

TFS发展至今,集群部署总容量已超过50PB,机器数量约2700台。TFS在阿里内部主流部署方式是主集群内数据块2个副本,每个主集群配置两个备集群,分别在同城和异地机房,实际上每份数据6个副本,存储成本非常高,为了降低TFS存储成本,我们将Erasre code引入到TFS系统,本文将详细介绍TFS应用Erasure code的技术方案。

异步编码,对用户透明

目前已经应用Erasure code的分布式文件系统里,HDFS、Windows Azure等系统采用异步编码的方式,写流程和数据编码流程完全解耦;而GPFS、pangu(阿里云的分布式文件系统)等系统则是采用实时编码的方式,在数据写入时进行编码。
(更多…)

TFS的数据服务化之路

1

很多人可能都只知道,TFS需要配置一个特定的客户端才能访问。其实,如今通过一系列web_service的接口就可以轻松存储、获取TFS里面的数据,TFS在去年就已经实现了数据服务化。今天我们就来说说TFS的数据服务化之路。

在2012年以前,TFS有一个java和c++的客户端。最早只支持小文件的时候,TFS的客户端只需要在读写流程中和NameServer以及DataServer交互即可。后来在客户端实现了文件去重和大文件的支持。随着应用的增长、数据规模扩大以及跨机房容灾的需要,我们引入了RcServer来对应用、集群进行管理,并在客户端实现了相应逻辑,以达到集群选择、容灾功能都对应用透明的目的,大大简化了应用的配置,降低了应用使用TFS的成本。再后来,我们在原生文件的基础上开发了新的功能,允许应用使用自己定义的文件名来进行访问,拓展了TFS的用法。至此,客户端与后端Server的交互对象又增加了两个,逻辑复杂化的趋势愈演愈烈,需要bugfix的频率也越来越高。而每次新功能或bugfix都需要将新的客户端推到所有使用TFS的应用,这个过程异常的痛苦。不知不觉间,客户端已成为限制TFS前进的一个绊脚石,客户端改革势在必行。
(更多…)

TFS新版本特性介绍

0

TFS新版本(tfs-2.6)的开发主要因为要将erasure code应用到TFS中,以节省存储成本。erasure code的引入,需要TFS在数据存储结构上做改变,这对于存储系统来说是非常大的改变,借着这个机会,也对TFS做了很多的优化工作,本文主要介绍2.6.0版本TFS的一些新特性。

block id升级至64位

TFS采用每个数据块(block)由一个uint32_t类型的blockid来标识,每个block 72MB,理论上单集群能支持约300PB的存储空间,但实际上并不是每个blockid都能被利用上;另外,TFS在应用erasure code后,会引入一种新的校验块(parity block);系统设计上是直接通过blockid的值就能判断出block的类型(最高位是否为0来区分),这样就使得数据块可用的blockid范围又缩小了一半。

为了有效解决可用blockid数量不足的问题,将blockid从uint32_t升级至uint64_t;由于TFS生成的文件名里编码了blockid,升级后,生成的新文件名将比原来更长,从原来的18字节扩张到27字节。

(更多…)

多线程程序问题分析小结

7

程序的核心是逻辑,没有正确逻辑的代码算不上是程序。人脑是物理上的单核,写程序和看代码讲求一个流程,流程其实就是单核顺序执行的过程。怎么保证单核顺序的人脑写出来的多线程程序,在物理上的多核CPU上执行正确的逻辑呢?答案是根本保证不了。多线程程序运行起来就像是开跑的赛马场,谁先跑完,谁会落后,完全无法预测;有时候相互踩踏在所难免。代码里到处充斥锁和共享的内存片段,过多的随机分支和状态导致全路径覆盖的测试case几乎是不可能的。所以多线程程序最痛苦的就是运行中爆出了core,发生了逻辑中认为不可能的事情,而你要在短时间内将其重现,定位,修复,验证。

重现 &&定位
        这是最耗时间的一步,也是最重要的,而且重现和定位是不分先后的。多线程的问题最常见的现象就是发生了不该发生的事情,线程之间产生了冲突,其中一个 assert 掉了。当你听到一个码农在调试程序的时候在嘟囔:“不能够啊,这不科学。”,他一定是在定位多线程的问题。所以第一步是找到矛盾的冲突点,基于此来做进一步的分析。
    1. 内存状态在线程间不一致:
thread1
图1

(更多…)

ulimit限制之nproc问题

11

前两天微博上的@王关胜同学问了个问题:

#ulimit问题# 关于nproc设置:centos6,内核版本是2.6.32. 默认情况下,ulimit -u的值为1024,是/etc/security/limits.d/90-nproc.conf的值限制;注释掉这个限制后,值为95044;手工设置90-nproc.conf文件,值为新设置的值。想请 问这个95044是怎么来的?

这个问题挺有意思的,这里面有二个信息点:

1. 为什么limit配置文件是 /etc/security/limits.d/90-nproc.conf 而不是其他?
2. 为什么是nproc的值95044,而不是其他。

之前我也写了些ulimit的问题的解决,参见 这里

我们来简单的做下实验:
[shell]
$ cat /etc/security/limits.d/90-nproc.conf
* soft nproc 8933
$ ulimit -u
8933

$ cat /etc/security/limits.d/90-nproc.conf #注释掉
#* soft nproc 8933
$ ulimit -u
385962
[/shell]
我们可以看出就是说当注释掉限制的话,不同的机器值是不同的。

我们先来回答第一个问题:为什么limit配置文件是 /etc/security/limits.d/90-nproc.conf 而不是其他
这个问题早些时候 杨德华 同学碰到了,也写了篇 博文 来解释redhat6下面如何破解nproc的限制,但是文章没提到这个问题。
(更多…)

Linux下如何知道文件被那个进程写

9

晚上朔海同学问:

一个文件正在被进程写 我想查看这个进程 文件一直在增大 找不到谁在写 使用lsof也没找到

这个问题挺有普遍性的,解决方法应该很多,这里我给大家提个比较直观的方法。

linux下每个文件都会在某个块设备上存放,当然也都有相应的inode, 那么透过vfs.write我们就可以知道谁在不停的写入特定的设备上的inode。
幸运的是systemtap的安装包里带了inodewatch.stp,位于/usr/local/share/doc/systemtap/examples/io目录下,就是用来用途的。
我们来看下代码:

[shell]
$ cat inodewatch.stp
#! /usr/bin/env stap

probe vfs.write, vfs.read
{
# dev and ino are defined by vfs.write and vfs.read
if (dev == MKDEV($1,$2) # major/minor device
&& ino == $3)
printf ("%s(%d) %s 0x%x/%u\n",
execname(), pid(), probefunc(), dev, ino)
}
[/shell]
这个脚本的使用方法如下: stap inodewatch.stp major minor ino

下面我们构造个场景: dd不停的写入一个文件,查出这个文件的ino, 以及它所在设备的major, minor, 运行stap脚本就可以得到答案。

(更多…)

大话Sheepdog 2 – 对象缓存

17

分布式存储系统的性能一直都是众矢之的,主要是因为数据甚至元数据的存取都添加了网络层的开销。对于多拷贝的对象存储来说,甚至还有复杂的逻辑来保持各个拷贝的一致性。对于拷贝的读写,读写的优化通常是不可兼得。比如通过最终一致性(eventual consistency)优化了写,但是读的时候需要读取大于一份的拷贝,来判断是否是最新的。这些问题都导致了性能的低下。
(更多…)

大话Sheepdog 1 – 智能节点管理

4

Sheepdog是开源的分布式块存储项目,具有零配置、Thin-Provision、高可靠、智能节点管理、容量线性扩展、虚拟机感知(底层支持冷热迁移和快照、克隆等)、支持计算与存储混合架构的特点等,可扩展到上千级别的物理节点。开源软件如QEMU、Libvirt以及Openstack都很好的集成了对Sheepdog的支持。

本系列将手把手让读者体验Sheepdog的各种功能,并解释背后的工作机制和原理。Sheepdog目前只支持Linux的环境,对文件系统没有任何假设。本文以Ubuntu 12.04为背景,假设GIT、GCC、Autoconf以及Make等常见的编译环境已经配置好了。读者可以根据自己的环境微调命令。
(更多…)

Go to Top