《深入云存储系统Swift存储节点：存储实现分析》由会员分享，可在线阅读，更多相关《深入云存储系统Swift存储节点：存储实现分析（12页珍藏版）》请在金锄头文库上搜索。
1、在深入云存储系统Swift 核心组件：Ring 实现原理咅0析和深入云存储系统 Swift核心组件：Ring数据结构及构建、重平衡操作两篇博文中,我们详细地分 析了 Swift中数据的映射机制和具体操作。那么在集群中的每一台存储节点上， Swift是如何实现Account、Container、Object的具体存储呢？本篇旨在分析 Storage node与partition, partition与data间的映射关系在实际存储目录中的以何 种格式存储，即怎么存，存什么。在Storage node上运行着Linux系统并使用了 XFS文件系统，逻辑上使用 一致性哈希算法将固定总数的partit
2、ion映射到每个Storage node上，每个Data 也使用同样的哈希算法映射到Partition上，其层次结构如下图所示：Cons-istD untUorHhraI/O Mancg&rBuffer Cac heVolume ManDisk DriversDiskDii他Figurel:Stoage node hierachy以我们的一台storage node sws51为例，该device的文件路径挂载至【/srv/node/sdc, 目录结构如下所示：rootsws51:/srv/node/sdc# lsaccounts async_pending container objects
3、 quarantined tmp其中accounts、containers、objects分别是账号、容器、对象的存储目录， async_pending是异步待更新目录，quarantined是隔离目录，tmp是临时目录。l.objects 目录在objects目录下存放的是各个partition目录，其中每个partition目录是由 若干个suffix_path名的目录和一个hashes.pkl文件组成，suffix_path目录下是由 object的hash_path名构成的目录，在hash_path目录下存放了关于object的数据 和元数据，object存储目录的层次结构如图2所示。
4、(algscLXifFigure2: Object directory hierachyhashes.pkl是存放在每个partition中的一个2进制pickle化文件。例如: rootsws50:/srv/node/sdc/objects/100000# ls8bd hashes.pklIn 1: with open(hashes.pkl； rb) as fp:.:import pickle:hashes = pickle.load(fp)In 2: hashesOut2:8bd: 9e99c8eedaa3197a63f685dd92a5b4b &8bd是 suffix_dir，而 9e9
5、9c8eedaa3197a63f685dd92a5b4b8 则是该 partition 下数 据的md5哈希值。Object path生成过程object的存储路径由object server进程内部称为DiskFile类初始化时产生，过程 如下：1. 由文件所属的 account、container 和 object 名称产生/account/container/object格式的字符串，和HASH_PATH_SUFFIX组成新的字符串，调用hash_path 函数，生成 md5 hash 值 name_hash。其中 HASH_PATH_SUFFIX 作为 salt 来增加安全性，HASH
6、_PATH_SUFFIX 值存放在/etc/swift/swift.conf 中。2. 调用 storage_directory 函数，传入 DATADIR, partition, hash_path 参数生成DATADIR/partition/name_path-3:/name_path 格式字符串3. 连结 path/devcie/storage_directory(DATADIR, partition,name_ hash)生成数据存储路径datadir4. 调用normalize_timestamp函数生成“ 16位.5位的时间戳+扩展名的格式生成对象名称例如，某object的存储路径
7、为：/srv/node/sdc/objects/19892/ab1/136d0ab88371e25e16663fbd2ef42ab1/1320050752. 09979.da ta其中每个目录分别表示：path devke ohj ect partition siiffis_path nsm e_hish timestamp estensioni33勰觀觀瞬職/srv/node / obcts/ I 13SK. jahi/ L3i_i2abl/ j132M 50751.09979 .data1Figure3: Object directory representionObject数据Objec
8、t的数据存放在后缀为.data的文件中，它的metadata存放在以后缀为.meta 的文件中，将被删除的Object以一个0字节后缀为.ts的文件存放。2. accounts 目录在accounts目录下存放的是各个partition，而每个partition目录是由若干个 suffix_path目录组成，suffix_path目录下是由account的hsh名构成的目录，在 hsh目录下存放了关于account的sqlite db，account存储目录的层次结构如图4 所示。pariLiion dir疯lai竽jUfectxjrydis-ectxffyFigure4: Account d
9、irectory hierachyhsiLiihpgTLdjn胃accouniAccount path生成过程account使用AccountController类来生成path，其过程与object类似，唯一 的不同之处在于，account的db命名调用hash_path(account)来生成，而不是使用 时间戳的形式。例如，某account的db存储路径为： /srv/node/sdc/accounts/20443/ac8/c7a5e0f94b23b79345b6036209f9cac8/ c7a5e0f94b 23b79345b6036209f9cac8.dbFigure5: Obje
10、ct directory representionAccount db 数据在 account 的 db 文件中，包含了 account_stat、container、incoming_sync、 outgoing_sync 4 张表。表account_stat是记录关于account的信息，如名称、创建时间、container 数统计等等，其schema如下：TABLE account_stat (account TEXT,created_at TEXT,put_timestamp TEXT DEFAULT 0,delete_timestamp TEXT DEFAULT 0,containe
11、r_count INTEGER,object_count INTEGER DEFAULT 0,bytes_used INTEGER DEFAULT 0,hash TEXT default 00000000000000000000000000000000, id TEXT,status TEXT DEFAULT ,status_changed_at TEXT DEFAULT 0,metadata TEXT DEFAULT );account 表示 account 名称，created_at 表示创建时间，put_timestamp 表示 put request 的时间戳，delete_times
12、tamp 表示 delete request 的时间戳， container_count 为 countainer 的计数，object_count 为 object 的计数，bytes_used 表示已使用的字节数，hash表示db文件的hash值，id表示统一标识符，status 表示account是否被标记为删除，status_changed_at表示状态修改时间，metadata 表示account的元数据。以test账号为例，该db的表account_stat中存放了以下数据项：fiPHjBtJOTI HLW5LS31J33& 口11HwhdWild便linntTLTHd.刖ULLf
13、l表 container 记录关于 container 的信息，其 schema女口下:TABLE container (ROWID INTEGER PRIMARY KEY AUTOINCREMENT,name TEXT, put_timestamp TEXT, delete_timestamp TEXT, object_count INTEGER, bytes_used INTEGER,deleted INTEGER DEFAULT 0);CREATE INDEX ix_container_deleted_name ONcontainer (deleted, name);CREATE TRI
14、GGER container_delete AFTER DELETE ON containerBEGINUPDATE account_statSET container_count = container_count - (1 - old.deleted), object_count = object_count - old.object_count, bytes_used = bytes_used - old.bytes_used,hash = chexor(hash, old.name,old.put_timestamp |-old.delete_timestamp | - old.obj
15、ect_count | - | old.bytes_used); END;CREATE TRIGGER container_insert AFTER INSERT ON containerBEGINUPDATE account_statSET container_count = container_count + (1 - new.deleted), object_count = object_count + new.object_count, bytes_used = bytes_used + new.bytes_used, hash = chexor(hash, new.name, new.put_timestamp |-new.delete_timestamp | -new.object_count |- | new.bytes_used);END;CREATE TRIGGER container_update BEFORE UPDATE ON containerBEGINSELECT RAISE(FAIL, U
