MogileFS安装学习记录
从这里开始
这不是原创，只是对一个过程的记录。
网上已经有不少关于MogileFS的文章，有营养的内容会出现在下面。
我的平台
操作系统：CentOS release 5.3。
硬件架构：i386。
其它：最小化安装，安装了“开发工具”组。
参考
重点参考这篇文章http://durrett.net/mogilefs_setup.html。
可以去看官方的wiki：http://mogilefs.pbwiki.com/。（有可能被GFW了，那么你就安装一个Firefox的gladder插件就可以看了）
MogileFS的特性
MogileFS是一个分布式文件存储的解决方案，他由Six Apart开发下面列出了他的一些特性（由mogileFS页面http://www.danga.com/mogilefs/ 介绍翻译而来）
- 应用层——不需要特殊的核心组件
- 无单点失败——MogileFS安装的三个组件（存储节点、跟踪器、跟踪用的数据库），均可运行在多个 机器上，因此没有单点失败。（你也可以将跟踪器和存储节点运行在同一台机器上，这样你就没有必要用4台机器）推荐至少两台机器。
- 自 动的文件复制——基于不同的文件“分类”，文件可以被自动的复制到多个有足够存储空间的存储节点上，这样可以满足这个“类别”的最少复制要求。比如你有一个图片网站，你可以设置原始的JPEG图片需要复制 至少三份，但实际只有1or2份拷贝，如果丢失了数据，那么Mogile可以重新建立遗失的拷贝数。用这种办法，MogileFS(不做RAID)可以节约 磁盘，否则你将存储同样的拷贝多份，完全没有必要。
- “比RAID好多了”——在一个非存储区域网络的RAID（non-SAN RAID）的建立中，磁盘是冗余的，但主机不是，如果你整个机器坏了，那么文件也将不能访问。 MogileFS在不同的机器之间进行文件复制，因此文件始终是可用的。
- 传输中立，无特殊协议——MogileFS客户端可以通过NFS或HTTP来和MogileFS的存储节点来通信，但首先需要告知跟踪器一下。
- 简单的命名空间——文件通过一个给定的key来确定，是一个全局的命名空间。你可以自己生成多个命名空间，只要你愿意，不过这样可能在同一MogileFS中会造成key冲突。
- 不用共享任何东西——MogileFS不需要依靠昂贵的SAN来共享磁盘，每个机器只用维护好自己的磁盘。
- 不需要RAID——在MogileFS中的磁盘可以是做了RAID的也可以是没有，如果是为了安全性着想的话RAID没有必要买了，因为MogileFS已经提供了。
- 不会碰到文件系统本身的不可知情况——在MogileFS中的存储节点的磁盘可以被格式化成多种格式（ext3,reiserFS等等）。MogilesFS会做自己内部目录的哈希，所以它不会碰到文件系统本身的一些限制，比如一个目录中的最大文件数。你可以放心的使用。
组成MogileFS的组件
1） 数据库（MySQL）部分
你可以用mogdbsetup程序来初始化数据库。数据库保存了Mogilefs的所有元数据，你可以单独拿数据库服务器来做，也可以跟其他程序跑在一起，数据库部分非常重要，类似邮件系统的认证中心那么重要，如果这儿挂了，那么整个Mogilefs将处于不可用状态。因此最好是HA结构。
2）存储节点
mogstored程序的启动将使本机成为一个存储节点。启动时默认去读/etc/mogilefs/mogstored.conf ，具体配置可以参考配置部分。mogstored启动后，便可以通过mogadm增加这台机器到cluster中。一台机器可以只运行一个mogstored作为存储节点即可，也可以同时运行其他程序。
3）trackers（跟踪器）
mogilefsd即trackers程序，类似mogilefs的wiki上介绍的，trackers做了很多工作，Replication ，Deletion，Query，Reaper，Monitor等等。mogadm,mogtool的所有操作都要跟trackers打交道，Client的一些操作也需要定义好trackers，因此最好同时运行多个trackers来做负载均衡。trackers也可以只运行在一台机器上，也可以跟其他程序运行在一起，只要你配置好他的配置文件即可，默认在/etc/mogilefs/mogilefsd.conf。
4）工具
主要就是mogadm，mogtool这两个工具了，用来在命令行下控制整个mogilefs系统以及查看状态等等。
5）Client
Client实际上是一个Perl的pm，可以写程序调用该pm来使用mogilefs系统，对整个系统进行读写操作。
MogileFS的php 扩展
http://www.capoune.net/mogilefs/ 提供了一个php扩展用来在php中使用mogileFS。
这儿也有一个地址，svn的源码库 http://svn.usrportage.de/php-mogilefs/trunk/
MogileFS应用中的几个重要概念
domain：最高域，在一个域下key是唯一的。
class：包含在domain中，可以针对每一个class定义保存的份数。
key：对文件的唯一标识。
file：文件。
MogileFS的适用性
由于Mogilefs不支持对一个文件的随机读写，因此注定了只适合做一部分应用。比如图片服务，静态HTML服务。即文件写入后基本上不需要修改的应用，当然你也可以生成一个新的文件覆盖上去。
MogileFS的工作方式(译)
MogileFS由如下一些部分构成:
- Application: 想要 保存/加载 文件的应用
- Tracker (the mogilefsd process): 基于事件的(event-based) 父 进程/消息 总线来管理所有来之于客户端应用的交互(requesting operations to be performed), 包括将请求负载平衡到 “query workers” 中，让mogilefsd的子进程去处理. 你可以在不同的机器上运行两个Tracker, 为了高可用性, 或使用更多的Tracker为了负载平衡(你需要运行多于两个的Tracker). mogilefsd的子进程有:
- Replication — 个机器间复制文件
- Deletion — 从命名空间删除是立即的，从文件系统删除是异步的
- Query — 响应客户端的请求
- Reaper — 在磁盘失败后将文件复制请求重新放到队列中
- Monitor — 监测主机和设配的健康度和状态
- …
- Database — 数据库用来存放MogileFS的元数据 (命名空间, 和文件在哪里). 这应该设置一个高可用性(HA)的环境以防止单点失败.
- Storage Nodes — 实际文件存放的地方. 存储节点是一个HTTP服务器，用来做 删除，存放等事情，任何WebDAV服务器都可以, 不过推荐使用 mogstored 。 mogilefsd 可以配置到两个机器上使用不同端口… mogstored 为所有 DAV 操作 (和流量监测), 并且你自己选择的快速的HTTP服务器用来做 GET 操作(给客户端提供文件). 典型的用户没一个加载点有一个大容量的 SATA 磁盘，他们被加载到 /var/mogdata/devNN.
High-level 流程:
- 应用程序请求打开一个文件 (通过RPC 通知到 tracker, 找到一个可用的机器). 做一个 “create_open” 请求.
- tracker 做一些负载均衡(load balancing)处理，决定应该去哪儿，然后给应用程序一些可能用的位置。
- 应用程序写到其中的一个位置去 (如果写失败，他会重新尝试并写到另外一个位置去）.
- 应用程序 (client) 通过”create_close” 告诉tracker文件写到哪里去了.
- tracker 将该名称和域命的名空间关联 (通过数据库来做的)
- tracker, 在后台, 开始复制文件，知道他满足该文件类别设定的复制规则
- 然后,应用程序通过 “get_paths” 请求 domain+key (key == “filename”) 文件, tracker基于每一位置的I/O繁忙情况回复(在内部经过 database/memcache/etc 等的一些抉择处理), 该文件可用的完整 URLs地址列表.
- 应用程序然后按顺序尝试这些URL地址. (tracker’持续监测主机和设备的状态，因此不会返回死连接,默认情况下他对返回列表中的第一个元素做双重检查，除非你不要他这么做..)
nginx的http session管理
http session，基本上可以认为就是我们平常所理解的完成GET或者POST请求的HTTP应用的TCP Session。
从自已的使用经验、以及归纳、总结网上各类关于Nginx的文章，个人觉得Nginx最擅长的是对静态内容提供HTTP服务，以及Session管理（HTTP任务管理）。Nginx使用了epoll的模式来管理TCP session，所以，性能高，系统资源消耗低。
实事上，Nginx提供动态内容需要通过FastCGI方式（也支持内置的对perl的支持），当觉得Nginx慢时，实际上是FastCGI慢（而FastCGI慢，大多数时候，又是因为数据库读写慢—-高并发的请求导致的阻塞属于不常见的原因之一，比如在遭遇DDos攻击的时候）。
大量的并发FastCGI请求，会使FastCGI管理器应接不暇，从而引起阻塞，引发系统上的“撞车效应”。所以瓶颈在FastCGI处理。
不少关于使用Nginx做负载均衡的例子，实际上就是利用Nginx的 session 管理能力。将处理较慢、花时间较多的FastCGI处理任务分发到多台系统上，这样可以提高系统的负载能力，提高系统发生阻塞的阈值。
Nginx的upstream模块，对“负载均衡”提供了良好的支持，详见：
http://wiki.nginx.org/NginxHttpUpstreamModule
例：
upstream app_group1 {
server 192.168.1.111:9000 weight=5 ;
server 192.168.1.112:9000 weight=5 ;
server 192.168.1.113:9000 weight=3 ;
server 192.168.1.114:9000 weight=5 ;
}
…………
location ~ \.php$ {
fastcgi_pass app_group_01;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
include extra/fastcgi_params.conf;
}
之前，是将Nginx分别放在四台FastCGI服务器上，然后使用LVS来作负载调度，运行良好。为了给系统构架分层，使架构清晰，更易于管理和扩展，降低维护难度，试着使用Nginx来调度负载。
一个较明显的效果是四个FastCGI的系统负载下降（原来有Nginx运行在同一系统上）。
Nginx系统的负载很低，活动连接1.7k左右，负载系统不超过1，用掉不到50M的物理内存。相对于LVS复杂的实施以及背后的管理成本，Nginx在低于100M流量的应用中相当有优势。
给cacti添加对nginx的统计
官方论坛上有详细说明
http://forums.cacti.net/about26458.html
需要说明的是，本地系统可能没有安装perl的LWP模块，对于CentOS系统来说：
yum -y install perl-libwww-perl
即可。
另一个，便是编译nginx时增加 –with-http_stub_status_module 选项
然后，在Server容器里增加如下配置：
location /status {
stub_status on;
access_log off;
allow 192.168.0.0/16;
deny all;
}
tar之新发现
之前见到tar解压之后的文件或目录的uid和gid为数字，于是错误地以为（这之间似乎也没什么逻辑），tar打包时只记录了uid和gid的数字信息。
然而事实并非如此。
当本地系统上有相同的user时，那么tar解压时，会自动将uid和gid转换成本地相同用户名和组名的uid和gid。
于是这般，方便多了。也合情合理。
Apache关闭ETag头儿
在主配置文件段里添加了
FileETag None
但实际上并不总是有效，原因还没有找到。于是使用下面的方式：
<IfModule mod_headers.c>
header unset Etag
</IfModule>
可行。
处理ddos攻击经验小结
昨天，系统在较短的时间内，某一台机器上有9千多ip，对同一域名，同一文件，以相同的agent，没有referer，进行了七百多万次的访问。于是，先是前端的负载彪升，然后机房的限制下行若干M带宽被用尽，于是攻击效果几何级增长，全线瘫痪，所有服务器都连不上了。
1. 假如不是带宽耗尽，我们能负载得了么？
发现两个问题。
第一，是 ip_conntrack 的问题，net.ipv4.netfilter.ip_conntrack_max 默认 65536 ，就是说，系统只能处理65536个连接，大于这个值时，就会阻塞，收到 kernel: ip_conntrack: table full, dropping packet.这样的信息。并且，系统负载上升。这个玩意儿本来是供给NAT使用的，到现在为止，还没有找到启动iptables，但不加载ip_conntrack模块的办法。为了增加系统处理能力，需要增加这个值，我在rc.local里增加了 sysctl -w net.ipv4.netfilter.ip_conntrack_max=655360 。但是发现无效：原因是，当iptables启动之后，该参数才有效。并且，重启iptables后，该参数会被初始化成默认值。当系统负载高的时候，就出引发 ip_conntrack: table full, dropping packet 导致的连接阻塞问题。
但是我怀疑一件事情，一味的增大此值，是否是在解决问题的根本。六万多连接，定是因为连接处理不了，阻塞而积累起来的。一味的放宽限制，不是意味着连接阻塞问题将导致更多资源被耗尽？
猜想：前端是用了nginx的，就是说高并发，对于nginx并不能够成威胁，那么大量的连接阻塞，定然是出在了fast-cgi处理上。高并发的请求，一下子涌向fast-cgi，于是……
故且不管这些，在高负载的系统上，还是先停止iptables这样的应用吧。尽管是内核级的应用，不占用什么资源。
第二，关于打开文件数的限制。
又是经验性的致命错误。在/etc/security/limits.conf里，增加了对daemon用户打开文件数的限制。然而似乎并没有起到作用。后来突然明白，daemon只是运行程序的用户，是root启动程序后，set的euid，应该是没有以该uid被始化环境，而是直接继承的root用户的环境。所以，这个设置也是没有生效的！
准备采用另外的方法，将ulimit -n 10240 这样的语句写进apache和nginx的启动脚本里，这样，系统就清洁了。并且走到哪里都不会有问题。
2. 抱着主动的态度，ddos的时候，能做些什么？
确定攻击类型之后，有几件事儿可以做。
第一，换IP地址。
第二，查攻击IP，封IP。
第三，查攻击目标，处理之（似之占用负载最小）。
不同的攻击类型，有不同的处理方法。但基本上，ddos最终是要将系统资源耗尽。
第二和第三可同时进行。但是这两个，只有当是小流量的攻击的时候，才可能有机会和时间这么做。需要说明的是，在遭受攻击之情形下，使用iptables封IP时，应使用reject，而不应该使用drop。根据实验结果，reject可以有效降低对方发包的速度，从而降低对带宽的影响。
将受攻击的目标通过DNS解析走，或者封掉，或者禁止访问，可有效降低对系统负载的消耗，但无异是一种对“网络暴力”的妥协，委屈求全。
换IP是个不错的方法，只要对方不是玩命的跟你死磕，一般都能凌效。一般的ddos攻击不会持续时间很长，一来，调动大量的肉鸡，是在消耗自己的资源，攻击的时间越大，将损失的肉鸡就会越多，二来，自己的淫威已经得到证明，没有必要死磕下去。但是换IP地址对用户的影响比较大。从换解析到全部生效，需要一段时间。不是万不得已，还是不用为好。
需要注意的是，原IP必须停止使用，不能配置在任何一台自己的主机上。
假如有抗DDOS攻击的设备，那就另当别论了，或者能在电信部门的配合，能在路由器上做些处理，那效果就更明显了。
将Apache的日志发送到syslog服务器
一直想要统一收集管理Apache的日志，一来可以较实时的分析系统的负载情况、分析系统问题，另一个，也可以把收集日志的工作分散到平时，分散带宽使用，并且解决日志合并问题。
想到的解决方法主要有两个：
第一，使用haproxy。
haproxy本身刚好就支持将日志以udp的方式发送给syslog服务器。看上去完美、感觉上官方。
第二，使用/bin/logger。
这个，是我晚上发梦的时候想到的。试图将CustomLog 管道给/bin/logger，再由本地的syslog forward到远程统一的syslog服务器上。实验了一下，居然成功了。就是绕了那么一道弯子，感觉不太完美。
PS:
发布之后，自己搜了一下，发现了下文：http://www.lslnet.com/linux/dosc1/32/linux-247167.htm
解决方法倒也差不多，不过多了些详细的描述，很实用。
并且要注意：至少默认的syslog配置会将短时候内重复的日志记录给于提示，并不记录：
May 3 14:31:51 localhost last message repeated 99 times
另外，将nginx的日志发送到syslog：
mkfifo /srv/logs/access_log.fifo
将 nginx 的日志写到这个 管道文件上
然后：logger -f /srv/logs/access_log.fifo 即可。
syslog-ng
syslog-ng，官方网址： http://www.balabit.com/network-security/syslog-ng/。
据说是将要取代syslog的日志服务器，企业级的。
syslog-ng有开源版本：http://www.balabit.com/network-security/syslog-ng/opensource-logging-system/。
syslog-ng开源版本是启动于十年之前的syslog-ng项目的“直系后代”。syslog-ng可运行与“server”和“agent”模式，分别支持UDP、可靠的TCP和加密的TLS协议。syslog可以用来在混合复杂的环境里建立灵活的、可靠的日志服务器。
syslog-ng开源版本的特性还有：
1. 支持SSL/TSL协议
2. 支持将日志写入数据库中
支持的数据库有MySQL, Microsoft SQL (MSSQL), Oracle, PostgreSQL, and SQLite.
3. 支持标准的syslog协议
4. 支持filter、parse以及rewrite
5. 支持更多的平台
6. 更高的负载能力
syslog-ng对性能进行了优化，可以处理巨大的数据量。一般的硬件，在正确的配置下，可以实时地处理75000个消息每秒钟，超过24GB的RAW日志每小时。
参考：
http://www.balabit.com/network-security/syslog-ng/opensource-logging-system/
下一代系统日志工具
http://www.techrss.cn/html/2009/02-08/216680.htm
http://evlog.sourceforge.net/
使用基于Apache的 subversion/svn 管理代码
到版本1.5.6，subversion提供的svnserve搭建的SVN服务器，使用的仍然是名文密码文件。
为了使用加密的密码文件，需要借助于Apache，使用subversion的mod_dav_svn和mod_authz_svn.so，使用基于Apache的认证机制。
假如使用发行版的Apache，那么一般发行版都带了相应的svn模块mod_dav_svn（CentOS）、libapache2-svn（Debian／Ubantu），直接安装即可。
下面主要介绍
源代码安装mod_dav_svn：
下载subversion的源代码：http://subversion.tigris.org/
与Apaceh相关的两个编译选择：
–with-apxs[=FILE] Build shared Apache modules. FILE is the optional pathname to the Apache apxs tool; defaults to “apxs”.
–with-apache-libexecdir[=PATH] Install Apache modules to PATH instead of Apache’s configured modules directory; PATH “no” or –without-apache-libexecdir means install to LIBEXECDIR.
一般指定使用 –with-apxs=［apxs的绝对路径]来编译。默认会安装两个模块到Apache的modules目录内，分别mod_authz_svn.so、mod_dav_svn.so。
配置Apache：
1. 加载SVN依赖的模块
LoadModule dav_module modules/mod_dav.so
LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so
2. 建立svn仓库
svnadmin create /srv/_svndata/isystem
svnadmin create /srv/_svndata/iconfig
3. 配置apache对svn仓库的管理
# 注意，/svn目录不能在你的DocumentRoot目录下。
<Location /svn>
# 启用SVN
DAV svn
# 设置SVN仓库的路径
# SVNPath /srv/_svndata/isystem
# 假如在一个目录下有多个仓库，那么可以使用SVNParentPath来指定多仓库的根目录
# 也可以使用SVNPath来进行单独的设置
SVNParentPath /srv/_svndata
AuthType Basic
AuthName “Subversion Repository”
AuthUserFile /etc/apache2/dav_svn.passwd
# 设置SVN的权限控制
AuthzSVNAccessFile /etc/apache2/dav_svn.authz
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>
4. 添加SVN访问账号
htpasswd /etc/apache2/dav_svn.passwd caoyuwei
编辑：/etc/apache2/dav_svn.authz
[groups]
admin = caoyuwei
[/]
@admin = rw
[isystem:/]
@admin= rw
[iconfig:/]
@admin=rw
LVM下的硬连接问题
之前在使用pdumpfs备份时，发现并没有像之前使用时的那样，使用 hardlink 的方式存储没有变化的文件，之后又发现在 LVM 管理的卷中建立文件的hardlink时，有时会失败。
那么，也就是说，hardlink真的像原始文档中说的那样，只能在同一物理设备上使用，即使是LVM（device-mapper）这样逻辑上的设备也不行。
于是，在LVM使用硬连接时，不一定总是成功的。
