目的

线程是操作系统能够进行运算调度的最小单位。它被包含在进程之中，是进程中的实际运作单位。一条线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个线程，每条线程并行执行不同的任务，多线程就是在一个进程中的多个线程，如果使用多线程默认开启一个主线程，按照程序需求自动开启多个线程(也可以自己定义线程数)。

目的

glusterfs作为分布式存储，优点和安装这里就不再赘述了，看博客中教程。本文主要是介绍glusterfs常用命令和案例。

Glusterfs逻辑卷创建与使用

volume是brick的组合，并且大部分glusterfs文件系统的操作都在volume上。

glusterfs支持4种基本卷，并可以根据需求对4种基本卷进行组合形成多种扩展卷（得益于glusterfs的模块化堆栈架构设计）。

以下主要展示各类型逻辑卷的功能性，未对性能做测试验证。

Glusterfs框架

Glusterfs（Gluster file system）是开源的，具有强大横向扩展能力的（scale-out）,分布式的，可将来自多个服务器的存储资源通过tcp/ip或infiniBand RDMA 网络整合到一个统一的全局命名空间中的文件系统。

框架

1. GlusterFS主要由存储服务器（Brick Server）、客户端以及 NFS/Samba 存储网关组成；
2. 架构中无元数据服务器组件，无对于提升整个系统的性单点故障和性能瓶颈问题，可提高系统扩展性、性能、可靠性和稳定性；
3. GlusterFS支持 TCP/IP 和 InfiniBand RDMA 高速网络互联；
4. 客户端可通过原生 GlusterFS 协议访问数据，其他没有运行 GlusterFS 客户端的终端可通过 NFS/CIFS 标准协议通过存储网关访问数据（存储网关提供弹性卷管理和访问代理功能）；
5. 存储服务器主要提供基本的数据存储功能，客户端弥补了没有元数据服务器的问题，承担了更多的功能，包括数据卷管理、I/O 调度、文件定位、数据缓存等功能，利用 FUSE（File system in User Space）模块将 GlusterFS 挂载到本地文件系统之上，实现 POSIX 兼容的方式来访问系统数据。

常见术语

1. Brick：GlusterFS中最基本的存储单元，表示为受信存储池（trusted storage pool）中输出的目录，供客户端挂载用，可以通过主机名与目录名来标识，如’SERVER:EXPORT’；
2. Volume：卷，逻辑上由N个brick组成；
3. FUSE：Unix-like OS上的可动态加载的模块，允许用户不用修改内核即可创建自己的文件系统；
4. Glusterd：Gluster management daemon，在trusted storage pool中所有的服务器上运行；
5. Volfile：Glusterfs进程的配置文件，通常是位于/var/lib/glusterd/vols/目录下的{volname}文件；
6. Self-heal：用于后台运行检测复本卷中文件与目录的不一致性并解决这些不一致；
7. Split-brain：脑裂；
8. GFID：GlusterFS卷中的每个文件或目录都有一个唯一的128位的数据相关联，用于模拟inode；
9. Namespace：每个Gluster卷都导出单个ns作为POSIX的挂载点。

数据访问流程

1. 在客户端,用户通过 glusterfs的mount point读写数据；
2. 用户的这个操作被递交给本地 Linux 系统的VFS 来处理；
3. VFS 将数据递交给 FUSE 内核文件系统（在启动 glusterfs 客户端以前,需要向系统注册一个实际的文件系统 FUSE），该文件系统与 ext3 在同一个层次， ext3 是对实际的磁盘进行处理，而 fuse 文件系统则是将数据通过 /dev/fuse 这个设备文件递交给了glusterfs client 端，可以将 fuse 文件系统理解为一个代理；
4. 数据被 fuse 递交给 Glusterfs client 后， client 对数据进行一些指定的处理（即按 client 配置文件来进行的一系列处理）；
5. 在 glusterfs client 的处理末端,通过网络将数据递交给 Glusterfs Server, 并且将数据写入到服务器所控制的存储设备上。

目的

本文通过对比当前主流的几种分布式存储方案（Ceph,TFS,FastDFS,MogileFS,MooseFS,GlusterFS等），让你知道他们的优缺点，便于你根据使用场景选择合适的方案。

系统整体对比

开源协议说明

前言

​ Haproxy是稳定、高性能、高可用性的负载均衡解决方案，支持HTTP及TCP代理后端服务器池，因支持强大灵活的7层acl规则，广泛作为HTTP反向代理。本文则详细介绍如何利用它的四层交换与Keepalived实现一个负载均衡器，适用于Socket、ICE、Mail、Mysql、私有通讯等任意TCP服务。系统架构图如下：

安装

环境

操作系统：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

验证说明

1. VIP：192.168.21.253指向192.168.21.129；VIP：192.168.21.254指向192.168.21.130；
2. 当192.168.21.129宕机时，VIP：192.168.21.253漂移到192.168.21.130上；
3. 当192.168.21.130宕机时，VIP：192.168.21.254漂移到192.168.21.129上；

这样的主主模式好处是，两台服务器在提供服务的同时，又互为对方的备份服务器。

目的

在运维的日常工作中和很多服务打交道，为了保证各个服务健康稳定运行，高可用和高负载是在一个服务搭建好后，必须要考虑的问题。本文介绍了一种常用的高可用和负载均衡的解决方案：KA+HA(haproxy+keepalived)

环境

haproxy keepalived 主：192.168.1.192
haproxy keepalived 备：192.168.1.193
vip：192.168.1.200
web：192.168.1.187:80

​ 192.168.1.187:8000

架构图

目的

“ssh端口转发”还有一个更加形象的名字，叫做”ssh隧道”，当然，只是纯粹的通过”ssh隧道”这几个字去理解它可能不太容易，我们来描述一些实际的场景，在这些场景中我们可能会遇到一些问题，而这些问题可以通过”ssh隧道”解决，通过这样的方式，我们反而更加容易理解”ssh隧道”是什么以及它的作用。

假如我们现在有两个台主机，主机A与主机B，主机A上安装有mysql客户端，主机B上安装有mysql服务端，现在，主机A中的mysql客户端需要与主机B中的mysql服务端进行通讯，则需要从mysql的客户端连接到mysql服务端。如下图所示

然而我们知道，mysql在传输数据时是进行明文传输的，如果主机A与主机B只能通过公网进行通讯，那么暴露在公网的mysql通讯是非常不安全的，所以，我们需要借助一些手段，提高访问mysql服务时的安全性，比如，我们可以使用SSL证书为数据加密，或者使用stunnel加密隧道，我们还可以使用VPN，当然，这些方法都不是这篇文章所要描述的重点，我们此处要总结的是”ssh隧道”这种方法，我们可以利用ssh，搭建出一条”通道”，然后将mysq的客户端与服务端通过这条”ssh通道”连接起来，如下图所示

mysql的客户端与服务端的连接方式从原来直连的方式变成了如上图所示的连接方式，它们之间并不直接进行通讯，而是借助ssh隧道将通讯数据转发，虽然仍然跨越了公网，但是由于ssh本身的安全特性，所以别人无法看到明文传输的数据，数据依靠ssh隧道实现了加密的效果，达到了保护数据安全的作用，提升了mysql的客户端与服务端通讯的安全性。