基于MFS的分布式文件系统方案[实践过程]:

　　我先用我的小型linux做为宿主机, 建立了大约36个虚拟机, 包括两个windows2003. 其中以dfs开头的13台xen虚拟机用来做mfs的实验（见图1）, 它们用我建立的半虚拟化的小型linux做为客户机.
　　然后夏望胜通过VPN拨号, 穿过我家的ADSL, 进入到服务器集群里, 开始布署.
　　搭建方法具体可以去看田逸的博客, 在此不再描述.

　　实验目的: 旨在于建立一个完整的维护和保障方案（包括:扩容, 灾难和风险应对方法, 快速布署, 培训……）, 而不仅仅是安装.
　　图1, 大家已看到每个trunkServer我仅仅给64M内存, 跟踪服务器（Master和logger）我给得多一些.
　　图2, 显示了一些内存消耗（39M）和硬盘占用（70M）[一块系统盘128M, 挂一4G的数据盘], 这些实验空间用来和流媒体服务器配合使用.
　　图3, 显示我用了5台机器做trunkServer. (另3台备用)

　　在这个实验中: 小型linux和redhat企业版的C库完全一致, 内核封装了基本的协议支持和防火墙模块, 展开后一共70M的文件系统, 特别易于布署.
　　我们用它把所有的通讯原理和运维程序全部沉淀下来, 当在生产机上实施的时候, 我们只需把对应物理机硬件的内核换上, 把对应高内存和硬盘存贮的配置文件换上即完成布署.

　　适用范围: trunkServer对于CPU和内存的要求很低, 可以使用低功耗刀片做为载体, 还有一种极端的用法就是: 用一台8个1T的SATA硬盘的廉价服务器, 以一个64M的IDE口的dom硬盘(大约几十块钱)装上我的小型linux作为宿主机启动, 以半虚拟化的小型linux启动8个虚拟机(同一虚拟机镜像, 8个不同配置文件, 分别单独管理8块硬盘.)

　　MFS的风险点和加固: 按照官方构架图: 跟踪服务器Master宕机后, 整个集群就不能使用了.
　　此处改进1为: 建立两个Master, 一个active, 一个standby, 它们共享一个磁盘柜, 当active的Master宕机, 另一个standby立即取代。
　　改进2: 在MFS架构中, 所有trunkServer和client都连向Master, 我们在Master的前端再加一层端口代理层（iptables, fastfwd）, 兼作整个集群的健康检查者, 发现问题就推送切换指令.
　　改进3: 后端的磁盘柜使用RAID, 或者有冗余热备方案.

图1


图2


图3


　　实验环境同生产环境具有很高近似性, 这样我们可以通过破坏性实验, 预知道未来的风险. 例如: 曾出过一次停电, 导致master没有启动, 而truckServer不断连接master, 连接失败的日志很快填满系统日志区...