一 Swift源码结构
[root@localhost swift]# tree -L 1
bin
etc
swift
├── account
├── cli
├── common
├── container
├── __init__.py
├── __init__.pyc
├── __init__.pyo
├── obj
└── proxy
setup.cfg
setup.py
test
- bin:一些启动脚本,以及工具脚本。比如swift-proxy-server负责启动proxy server,swift-ring-builder用来创建Ring。
- swift:swift的核心代码。account、container、obj、proxy几个子目录分别是Account、Container、Object、Proxy几个服务的具体实现。common子目录包含的是一些可以被多个组件共用的公共代码,比如Account、Container以及Object服务都有Ring的操作,那么这些共用的代码就存放在common目录下。
- etc:配置文件模板,包括Paste配置文件等。
二 setup.cfg
依照惯例,理解具体的实现之前,我们需要仔细浏览setup.cfg文件。
scripts =
bin/swift-account-audit
bin/swift-account-auditor
bin/swift-account-info
bin/swift-account-reaper
bin/swift-account-replicator
bin/swift-account-server
bin/swift-config
bin/swift-container-auditor
bin/swift-container-info
bin/swift-container-replicator
bin/swift-container-server
bin/swift-container-sync
bin/swift-container-updater
bin/swift-container-reconciler
bin/swift-reconciler-enqueue
bin/swift-dispersion-populate
bin/swift-dispersion-report
bin/swift-drive-audit
bin/swift-form-signature
bin/swift-get-nodes
bin/swift-init
bin/swift-object-auditor
bin/swift-object-expirer
bin/swift-object-info
bin/swift-object-replicator
bin/swift-object-server
bin/swift-object-updater
bin/swift-oldies
bin/swift-orphans
bin/swift-proxy-server
bin/swift-recon
bin/swift-recon-cron
bin/swift-ring-builder
bin/swift-temp-url
对于Swift来说,setup.cfg文件中值得关注的是script关键字所对应的内容,其中每一项都代表一个被安装在系统里的可执行的脚本,它们同时也是Swift各项工作的入口,完全可以作为我们理解Swift具体实现的起点。
- swift-proxy-server:代理服务(Proxy Server)进程,通常运行这个进程的服务器又被称为代理服务器。
- *-auditor:swift-account-auditor、swift-container-auditor、swift-object-auditor分别对应了Account、Container和Object的Auditor(审计)进程。
- *-updater:swift-container-updater与swift-object-updater分别对应了Container和Object的Updater进程,并不存在Account的Updater。
- *-replicator:基于Account、Container和Object存储方式不同,它们的Replicator进程又分两类:一是针对Account与Container这两种以数据库形式存在的数据,swift-account-replicator和swift-container-replicator完成的是数据库的复制;二是swift-object-replicator针对Object完成数据对象数据的复制。
- swift-account-server、swift-container-server、swift-object-server,分别对应了Account、Container、Object三种服务的进程。
- swift-account-audit:与*-auditor不同,swift-account-audit并不是一个后台服务进程,它只是一个命令行工具。可以手动地对指定的Account、Container或Object的数据进行完整性检查。指定了Container时,将递归检测该Container中的每个Object,同理,指定Account时,将递归检测该Account下的每个Container,并进一步检查每个Container下的各个Object。
- *-info:打印Account、Container和Object的内容或元数据信息。
- swift-account-reaper:Account收割器,负责清除被删除Account中所包含的数据。
- swift-container-sync:实现Container同步功能。一个Container的所有内容可以通过后台同步镜像到另外一个Container(两个Container可以在同一个集群也可以在完全不同的集群)。比如可以使用这个功能实现Account的迁移,将旧的Account中的所有Container都同步到新的Account中去,利用这个功能,数据可以在不同的云服务提供商之间迁移,而不会被锁定在一个特定的供应商,比如数据可以在不同的云服务提供商之间迁移,而不会被锁定在一个特定的供应商,比如数据可以从私有的Swift集群迁移到一个公共Swift。
- swift-container-reconciler:伴随Storage Policies(存储策略)而出现的一个后台进程,简单地说,一种Storage Policy就是一种存储的方式,比如创建2个副本或创建3个副本,swift-container-reconciler主要负责将错误Storage Policy中的对象迁移到正确的Storage Policy中去。
- swift-dispersion-report:通过检测Container和Object是不是在集群中合适位置来估计整个集群的健康状态。比如说,每个对象有3个副本,如果3个副本中只有两个在适当位置,那么这个对象的健康值就是66.66%,最佳是100%。如果我们在占集群一定百分比的Partition中(比如1%)创建足够的对象,就可以获得一个对整个集群健康度相当有效的估计。为了估计健康状态,我们所要做的第一件事情就是创建一个专门用于该工作的Account,然后,我们需要向不同的Partition中放置容器和对象。swift-dispersion-populate工具能完成这个工作,它创建随机的Container和Object直到它们落在不同的Partition里。最后,我们运行swift-dispersion-tool来进行检测。
- swift-drive-audit:经验表明,当一个设备快要出故障时,错误信息会涌入/var/log/kern.log。此时我们可以通过cron运行swift-drive-audit脚本来寻找坏掉的硬盘,并将其卸载,从而Swift能够绕开它工作。
- swift-get-nodes:如果我们希望知道对象在哪个存储节点上,可以使用这个工具。
- swift-init:启动swfit基本服务。
- swift-object-expirer:在指定时间内删除对象。当对象过期达到删除的时间时,Swift会停止向用户提供针对该对象的服务,并在短时间内把该对象删除。
- swift-oldies:可以列出运行时间很长的Swift服务进程,比如“swift-oldies –a 48”打印出已经运行超过48个小时的那些进程。
- swift-orphans:可以清除那些孤儿进程(父进程已经退出)
- swift-recon:可以用于收集一些Swift统计数据,比如Account、Container和Object的数量等。
- swift-ring-builder:用于构建Ring。