目的
Python中的multiprocess提供了Process类，实现进程相关的功能。但是它基于fork机制，因此不被windows平台支持。想要在windows中运行，必须使用 if name == ‘main: 的方式)。并且多进程就是开启多个进程，每个进程之间是不会互相通信互相干扰的，适用于密集计算。
GlusterFS分布式存储集群之部署
Glusterfs框架
Glusterfs（Gluster file system）是开源的，具有强大横向扩展能力的（scale-out）,分布式的，可将来自多个服务器的存储资源通过tcp/ip或infiniBand RDMA 网络整合到一个统一的全局命名空间中的文件系统。
框架
- GlusterFS主要由存储服务器（Brick Server）、客户端以及 NFS/Samba 存储网关组成；
- 架构中无元数据服务器组件，无对于提升整个系统的性单点故障和性能瓶颈问题，可提高系统扩展性、性能、可靠性和稳定性；
- GlusterFS支持 TCP/IP 和 InfiniBand RDMA 高速网络互联；
- 客户端可通过原生 GlusterFS 协议访问数据，其他没有运行 GlusterFS 客户端的终端可通过 NFS/CIFS 标准协议通过存储网关访问数据（存储网关提供弹性卷管理和访问代理功能）；
- 存储服务器主要提供基本的数据存储功能，客户端弥补了没有元数据服务器的问题，承担了更多的功能，包括数据卷管理、I/O 调度、文件定位、数据缓存等功能，利用 FUSE（File system in User Space）模块将 GlusterFS 挂载到本地文件系统之上，实现 POSIX 兼容的方式来访问系统数据。
常见术语
- Brick：GlusterFS中最基本的存储单元，表示为受信存储池（trusted storage pool）中输出的目录，供客户端挂载用，可以通过主机名与目录名来标识，如’SERVER:EXPORT’；
- Volume：卷，逻辑上由N个brick组成；
- FUSE：Unix-like OS上的可动态加载的模块，允许用户不用修改内核即可创建自己的文件系统；
- Glusterd：Gluster management daemon，在trusted storage pool中所有的服务器上运行；
- Volfile：Glusterfs进程的配置文件，通常是位于/var/lib/glusterd/vols/目录下的{volname}文件；
- Self-heal：用于后台运行检测复本卷中文件与目录的不一致性并解决这些不一致；
- Split-brain：脑裂；
- GFID：GlusterFS卷中的每个文件或目录都有一个唯一的128位的数据相关联，用于模拟inode；
- Namespace：每个Gluster卷都导出单个ns作为POSIX的挂载点。
数据访问流程
- 在客户端,用户通过 glusterfs的mount point读写数据；
- 用户的这个操作被递交给本地 Linux 系统的VFS 来处理；
- VFS 将数据递交给 FUSE 内核文件系统（在启动 glusterfs 客户端以前,需要向系统注册一个实际的文件系统 FUSE），该文件系统与 ext3 在同一个层次， ext3 是对实际的磁盘进行处理，而 fuse 文件系统则是将数据通过 /dev/fuse 这个设备文件递交给了glusterfs client 端，可以将 fuse 文件系统理解为一个代理；
- 数据被 fuse 递交给 Glusterfs client 后， client 对数据进行一些指定的处理（即按 client 配置文件来进行的一系列处理）；
- 在 glusterfs client 的处理末端,通过网络将数据递交给 Glusterfs Server, 并且将数据写入到服务器所控制的存储设备上。
分布式存储的优劣对比
目的
本文通过对比当前主流的几种分布式存储方案（Ceph,TFS,FastDFS,MogileFS,MooseFS,GlusterFS等），让你知道他们的优缺点，便于你根据使用场景选择合适的方案。
系统整体对比
| 对比说明/文件系统 | TFS | FastDFS | MogileFS | MooseFS | GlusterFS | Ceph |
|---|---|---|---|---|---|---|
| 开发语言 | C++ | C | Perl | C | C | C++ |
| 开源协议 | GPL V2 | GPL V3 | GPL | GPL V3 | GPL V3 | LGPL |
| 数据存储方式 | 块 | 文件/Trunk | 文件 | 块 | 文件/块 | 对象/文件/块 |
| 集群节点通信协议 | 私有协议（TCP） | 私有协议（TCP） | HTTP | 私有协议（TCP） | 私有协议（TCP）/ RDAM(远程直接访问内存) | 私有协议（TCP） |
| 专用元数据存储点 | 占用NS | 无 | 占用DB | 占用MFS | 无 | 占用MDS |
| 在线扩容 | 支持 | 支持 | 支持 | 支持 | 支持 | 支持 |
| 冗余备份 | 支持 | 支持 | - | 支持 | 支持 | 支持 |
| 单点故障 | 存在 | 不存在 | 存在 | 存在 | 不存在 | 存在 |
| 跨集群同步 | 支持 | 部分支持 | - | - | 支持 | 不适用 |
| 易用性 | 安装复杂，官方文档少 | 安装简单，社区相对活跃 | - | 安装简单，官方文档多 | 安装简单，官方文档专业化 | 安装简单，官方文档专业化 |
| 适用场景 | 跨集群的小文件 | 单集群的中小文件 | - | 单集群的大中文件 | 跨集群云存储 | 单集群的大中小文件 |
开源协议说明
haproxy+keepalived实现Web服务器负载均衡
环境
操作系统：CentOS 6.X 64位
Web服务器：192.168.21.127、192.168.21.128
站点：bbs.osyunwei.com和sns.osyunwei.com部署在两台Web服务器上
实现目的
增加两台服务器（主主模式），通过HAProxy+Keepalived实现Web服务器负载均衡
架构规划
HAProxy服务器：192.168.21.129、192.168.21.130
虚拟服务器（VIP）：192.168.21.253、192.168.21.254
验证说明
- VIP：192.168.21.253指向192.168.21.129；VIP：192.168.21.254指向192.168.21.130；
- 当192.168.21.129宕机时，VIP：192.168.21.253漂移到192.168.21.130上；
- 当192.168.21.130宕机时，VIP：192.168.21.254漂移到192.168.21.129上；
这样的主主模式好处是，两台服务器在提供服务的同时，又互为对方的备份服务器。
