Tổng quan về Openstack

Báo cáo bài tập môn:
CÁC VẤN ĐỀ HIỆN ĐẠI VỀ CÔNG NGHỆ PHẦN MỀM

Đề tài:

CÁCH THỨC HOẠT ĐỘNG CỦA CÁC MODULE
TRONG OPENSTACK
Nội dung nghiên cứu:
- Compute (Nova): chạy máy ảo, cấu hình mạng…
- Image Service (Glance): Các kiến trúc, cách truy vấn hình ảnh ổ đĩa
ảo.
- Object Storage (Swift): lưu dữ liệu, có thể mở rộng và chịu lỗi bằng
cách sao lưu dữ liệu.

GVHD:

TS. Võ Đình Hiếu

Học viên: Cung Công Đại
Phạm Thị My
Hoàng Thị Huế


MỤC LỤC
Swift (OpenStack Object Storage)................................................................................................................10
I. Giới thiệu Swift......................................................................................................................................10
II. Đặc điểm và lợi ích của Swift................................................................................................................10
2.2. Lợi ích của Swift:...........................................................................................................................11
2.2.1. Đối với các nhà phát triển ứng dụng:......................................................................................11
2.2.2. Đối với các nhóm IT:...............................................................................................................12
III. Swift Architectural Overview (kiến trúc)..............................................................................................12

3.1. Building Blocks...............................................................................................................................12
3.2. Proxy Servers.................................................................................................................................13
3.3. Ring................................................................................................................................................13
3.4. Zone: Failure Boundaries (không ranh giới)...................................................................................14
3.5. Accounts & Containers..................................................................................................................14
a, Container Server...........................................................................................................................15
b, Account Server.............................................................................................................................15
3.6. Object Server ................................................................................................................................15
3.7. Partitions (Phân vùng)...................................................................................................................15
3.8. Replication (tạo bản sao)...............................................................................................................16
3.9. Updaters .......................................................................................................................................16
3.10. Auditors (Kiểm toán viên)............................................................................................................17

Page 2


Image Service (Glance)
1.Giới thiệu
Image Service (hay được gọi là Glance) là dịch vụ OpenStack mới nhất.Đầu tiên ra
mắt trong bản phát hành Bexar, Glance cung cấp một dịch vụ danh mục để lưu trữ và truy
vấn hình ảnh ổ đĩa ảo.Glance đã được thiết kế là một dịch vụ độc lập cho những người cần
phải tổ chức tập hợp lớn các hình ảnh đĩa ảo. Tuy nhiên, khi được sử dụng cùng với Nova
và Swift, nó cung cấp một giải pháp end-to-end cho quản lý đĩa hình ảnh đám mây.

Hình 1-1 OpenStack Computer
2. Kiến trúc Glance
Có ba phần kiến trúc: glance-api, glance-registry, và image store. Như bạn có thể
đoán, Glance-api chấp nhận cuộc gọi API, giống như nova-api, và các đốm màu hình ảnh
thực tế được đặt trong kho lưu trữ hình ảnh. Các lưu trữ Glance-registry và siêu dữ liệu lấy
về những hình ảnh. Các lư trữ hình ảnh có thể là một số các lưu trữ đối tượng khác nhau,

bao gồm cả Swift. Hình 3-1 minh họa kiến trúc lôgic Glance.
Glance-api là tương tự như chức năng để nova-api, trong đó nó chấp nhận yêu cầu
API đến và sau đó giao tiếp với các thành phần khác (Glance-registry và hình ảnh lưu trữ)
để tạo điều kiện truy vấn, lấy lên, tải lên, hoặc xóa hình ảnh. Theo mặc định, Glance-api
lắng nghe trên cổng 9292.
Glance-registry quá trình lưu trữ và truy xuất siêu dữ liệu về những hình ảnh. Phiên
bản đi kèm với Glance chỉ được coi là một thực hiện tham chiếu.Các phiên bản tài liệu
Page 3


tham khảo sử dụng SQLite 3 để lưu trữ các siêu dữ liệu và Glance-api cho thông tin liên
lạc. Theo mặc định, Glance- registry lắng nghe trên cổng 9191.

Hình 2-1. Kiến trúc logic của Glance
Cở sở dữ liệu Glance chứa chỉ có hai bảng: Image và Image Property. Bảng Image
đại diện cho hình ảnh trong kho dữ liệu (định dạng đĩa, chứa định dạng, kích thước, ...),
trong khi bảng Image Property chứa siêu dữ liệu hình ảnh tùy chỉnh. Trong khi các đại
diện Image và siêu dữ liệu hình ảnh được lưu trữ trong cơ sở dữ liệu, những hình ảnh thực
tế được lưu trữ trong các image stores.
Image stores là các địa điểm lưu trữ cho tập tin ảnh ổ đĩa ảo và có một số lựa chọn
khác nhau. Image stores hiện đang được hỗ trợ được thể hiện trong bảng 3-1.
Bảng 2-1. Tùy chọn Glance Image Store
Image Store

Mô tả

File system

Lưu trữ, xóa, và nhận được hình ảnh từ một thư mục hệ thống
tập tin được quy định trong file cấu hình

(filesystem_store_datadir tùy chọn). Điều này có thể là một hệ
thống tập tin trên một ổ đĩa chia sẻ (ví dụ, NFS).

HTTP

Lấy hình ảnh từ một URL. Nó chỉ đọc hình ảnh tùy chọn lưu
Page 4


trữ. Hình ảnh sẽ cần phải được lưu vào URL thông qua cơ chế
khác.
Swift

Lưu trữ, xóa, và nhận được hình ảnh từ một cài đặt Swift. Yêu
cầu một số tùy chọn cấu hình trong glance.conf.

S3

Xóa hoặc lấy hình ảnh (nhưng không phải lưu trữ) từ dịch vụ S3
của Amazon.

Mỗi tùy chọn này đều có những điểm mạnh và điểm yếu của họ. Tuy nhiên, hầu hết
các phần cài đặt sẽ sử dụng Swift, trong khi cài đặt nhỏ hơn có thể sẽ dẫn đến sự đơn giản
của các tùy chọn hệ thống tập tin với một máy chủ chia sẻ NFS. S3 hoặc HTTP lưu trữ
hình ảnh có lẽ chỉ hữu ích cho việc tham khảo các hình ảnh được công bố công khai.
Với cái nhìn tổng quan về Glance, được rõ ràng như thế nào Glance cung cấp "sự
kết hợp" giữa Swift và Nova. Hình 3-2 cho thấy sự tương tác giữa các dự án OpenStack
cho việc lưu trữ và phục hồi hình ảnh đĩa ảo.

Hình 2-2. Hệ OpenStack Image

3. Image Support
Glance hỗ trợ một mảng lớn của ổ đĩa ảo và các định dạng container. Ổ đĩa ảo tương
tự ổ đĩa khởi động của một máy chủ vật lý, chỉ tóm gọn lại một tập tin. Công nghệ ảo hóa
khác nhau hỗ trợ các định dạng đĩa khác nhau. Glance hỗ trợ các định dạng đĩa như thể
hiện trong bảng 3-1.
Bảng 3-1. Glance hỗ trợ các định dạng ổ đĩa

Page 5


Glance cũng hỗ trợ các khái niệm định dạng nơi chứa, trong đó mô tả các định dạng
tập tin và bao gồm thêm cả siêu dữ liệu. Glance hỗ trợ hai định dạng chứa cũng như sự
vắng mặt của một định dạng chứa (trống), như thể hiện trong bảng 3-3.
Bảng 3-2. Glance Container Formats
Container Formats

Chú thích

OVF

Một tiêu chuẩn mở để phân phối một hoặc hình ảnh máy
ảo hơn.

aki, ari, ami

Amazon kernel, RAM disk, hoặc máy ảnh.

Bare

Không chứa hình ảnh.

4. API support
Glance API là một REST API đơn giản cho các truy vấn siêu dữ liệu hình ảnh hoặc
lưu trữ hoặc lấy hình ảnh thực tế. Dữ liệu được trả về như một ánh xạ JSON-encoded (truy
vấn) hoặc nhị phân (hình ảnh truy hồi). Dưới đây là một ví dụ về truy vấn Glance bằng
cách sử dụng curl để biết thêm chi tiết về tất cả các hình ảnh:
$ curl http://localhost:9292/images
{"images":
[{"name": "natty-uec",
"container_format": "ami",
"disk_format": "ami",
"checksum": "b420e097baf54cd32af5970b3f0cb93b",
"id": 6,
"size": 1476395008}]
}
Trong ví dụ này, Glance cho thấy rằng chỉ có một hình ảnh trong registry. Danh
sách và hình ảnh chi tiết danh sách các hàm gọi hình ảnh có thể trả về một lượng lớn dữ
liệu cho các kho hình ảnh lớn, như là không có bản ghi lọc nào tồn tại rong phiên bản này
của Glance.
Chi tiết Glance API có thể gọi trong bảng 3-4.
Bảng 4-1. Glance API Calls
Action API Call Description
Page 6


5. Installation
Nếu bạn đang trên Ubuntu 11.04 hoặc phiênbản sau đó, Glance có thể được cài đặt
với một đơn giản apt-get
$ sudo apt-get install glance python-glance-doc
Glance đòi hỏi một số lượng lớn các phụ thuộc. Sau khi cài đặt, nó cần phải được

bắt đầu với các tiện ích kiểm soát Glance.
$ sudo glance-control all start
Glance đã sẵn sàng để tải lên và truy vấn các hình ảnh đĩa ảo. Các lệnh chỉ Glance
cho thấy tất cả các hình ảnh đĩa ảo hiện trong Glance.
$ glance index
No public images found.
Như bạn có thể nhìn thấy từ ví dụ trên, Glance hiện tại là rỗng . Hãy đặt một hình
ảnh vào nó.Lệnh Glance-upload đặt một bản ghi hình ảnh vào glance-registry và lưu trữ
các tập tin dữ liệu trong kho lưu trữ hình ảnh. Nó đòi hỏi một định dạng đĩa và chứa định
dạng như là một tập tối thiểu của các đối số. Trong ví dụ này, ổ đĩa ảo được định dạng như
một AMI từ kho lưu trữ hình ảnh Ubuntu Enterprise Cloud.
$ glance-upload natty-server-uec-amd64.img natty-uec --disk-format ami \
--container-format ami
Stored
image.
Got
u'b420e097baf54cd32af5970b3f0cb93b',

identifier:

{u'checksum':

u'container_format': u'ami',
u'created_at': u'2011-07-06T00:54:23.600181',
u'deleted': False,
u'deleted_at': None,
Page 7


u'disk_format': u'ami',

u'id': 6,
u'is_public': True,
u'location': u'file:///var/lib/glance/images/6',
u'name': u'natty-uec',
u'properties': {u'type': u'raw'},
u'size': 1476395008,
u'status': u'active',
u'updated_at': u'2011-07-06T00:55:01.901066'}
Bây giờ là một hình ảnh đã được tải lên, Glance sẽ hiển thị thông qua lệnh chỉ
Glance.
$ glance index
Found 1 public images...
ID

Name

Disk Format

Container Format

6

natty-uec

ami

ami

Size
1476395008

Lệnh show Glance: có thể hiển thị thông tin chi tiết về hình ảnh mới được tải lên
$ glance show 6
URI: http://0.0.0.0/images/6
Id: 6
Public: Yes
Name: natty-uec
Size: 1476395008
Location: file:///var/lib/glance/images/6
Disk format: ami
Container format: ami
Property 'type': raw
Hình ảnh này có thể sử dụng.

Page 8


Tài liệu tham khảo
[1] Openstask.org
[2] Deploying OpenStack - Reilly.
[3] OS image service devguide – Diablo (22/10/2011)

Page 9


Swift (OpenStack Object Storage)
I. Giới thiệu Swift
Swift là mã nguồn mở phát hành theo giấy phép Apache 2.0. Swift để sao lưu web,
nội dung di động và bất kỳ dữ liệu phi cấu trúc khác, có thể phát triển mà không bị ràng
buộc.

Swift: đa người dùng (multi-tenant) có khả năng mở rộng cao, hệ thống lưu trữ dự
phòng đối tượng bền vững đã được thiết kế để lưu trữ một lượng lớn dữ liệu phi cấu trúc
với chi phí thấp thông qua một http RESTful API. "Khả năng mở rộng cao" có nghĩa là nó
có thể mở rộng đến hàng ngàn máy với hàng chục ngàn của ổ đĩa cứng. Swift được thiết kế
có khả năng mở rộng theo chiều ngang. Swift là lý tưởng để lưu trữ và phục vụ cho nhiều
người, nhiều người sử dụng đồng thời - một đặc điểm phân biệt nó với các hệ thống lưu trữ
khác.
"Dự phòng" có nghĩa là swift lưu trữ nhiều bản sao của mỗi thực thể trong hệ thống.
Mỗi bản sao được lưu trữ sẵn trong khu vực vật lý riêng biệt, những thất bại phổ biến như
các vấn đề về ổ cứng, mạng không gây khó khăn, không gây mất dữ liệu hoặc thời gian
chết.
"Lưu trữ dữ liệu phi cấu trúc" có nghĩa là Swift lưu trữ theo các bits. Swift không
phải là một cơ sở dữ liệu, không phải là một hệ thống lưu trữ khối cấp, Swift lưu trữ blobs
(Binary large Object) của dữ liệu.
Ngoài ra, vì Swift đảm bảo rằng các object sẽ có sẵn dữ liệu ngay khi chúng được
ghi thành công, nên Swift có thể được sử dụng để lưu trữ các nội dung thay đổi thường
xuyên. Để thích ứng với những nhu cầu thay đổi, hệ thống lưu trữ phải có khả năng để xử
lý khối lượng công việc quy mô web với đồng thời nhiều reader và writer để lưu trữ dữ
liệu. Một số dữ liệu thường viết ra và tìm kiếm, chẳng hạn như: các tập tin cơ sở dữ liệu và
hình ảnh máy ảo, dữ liệu khác như: văn bản, hình ảnh, tài liệu (và sao lưu thường được ghi
một lần và hiếm khi truy cập). Web và các dữ liệu di động cũng cần phải được truy cập qua
web thông qua một URL để hỗ trợ web / ứng dụng di động.
Sự khác biệt Swift với nhiều hệ thống lưu trữ khác là nó có nguồn gốc trong một
môi trường sản xuất quy mô lớn, có nghĩa là nó được thiết kế để chịu được các lỗi phần
cứng mà không cần bất kỳ thời gian chết và cung cấp các nhóm hoạt động các phương tiện
để duy trì, nâng cấp và tăng cường một cluster. Swift có quy mô tuyến tính để hoạt động
có thể thêm dung lượng lưu trữ khi cần thiết mà không cần lo lắng về chi phí.
II. Đặc điểm và lợi ích của Swift
2.1. Đặc điểm:
Các đặc tính quan trọng của Swift bao gồm:

-

Tất cả các đối tượng được lưu trữ trong Swift có một URL
Tất cả các đối tượng được lưu trữ được nhân rộng 3x trong các zone (coi như là duy
nhất), có thể được định nghĩa là một nhóm các ổ đĩa, một nút, một rack.

-

Tất cả các đối tượng có siêu dữ liệu của riêng mình
Page 10


-

Các nhà phát triển tương tác với hệ thống lưu trữ đối tượng thông qua một HTTP
RESTful API

-

Dữ liệu object có thể được đặt bất cứ nơi nào trong cluster.

-

Cluster mở rộng bằng cách thêm các nút bổ sung mà không hy sinh hiệu suất, cho
phép nâng cấp hiệu quả chi phí lưu trữ mở rộng tuyến tính.

-

Dữ liệu không phải di chuyển đến một hệ thống lưu trữ hoàn toàn mới

-

Các nút mới có thể được thêm vào cluster mà không có thời gian chết

-

Các nút và ổ đĩa bị hỏng có thể được hoán đổi với thời gian nghỉ dưỡng

-

Chạy trên phần cứng tiêu chuẩn công nghiệp, chẳng hạn như Dell, HP, Supermicro…

Để có được một danh sách của tất cả các container trong một account, sử
dụng lệnh GET trên tài khoản:
GET />Để tạo container mới, sử dụng lệnh PUT với tên của các container mới:
PUT />Để liệt kê tất cả các đối tượng trong một container, sử dụng lệnh GET trên container:
GET />Để tạo các đối tượng mới với một PUT trên đối tượng:
PUT />Lệnh POST được sử dụng để thay đổi siêu dữ liệu container và objects
2.2. Lợi ích của Swift:

2.2.1. Đối với các nhà phát triển ứng dụng:
− Dữ liệu được lưu trữ và phục vụ trực tiếp qua HTTP
− Truy cập để lưu trữ trong vài phút.
− Một hệ thống lưu trữ multi-tenant (đa người dùng) cho tất cả các ứng dụng.
− Một hệ sinh thái phong phú của các công cụ và thư viện
Page 11


2.2.2. Đối với các nhóm IT:
− Sử dụng chi phí thấp, máy chủ và ổ đĩa tiêu chuẩn công nghiệp

− Quản lý nhiều dữ liệu hơn và các case sử dụng một cách dễ dàng
− Kích hoạt các ứng dụng mới một cách nhanh chóng
− Kiến trúc độ bền cao.
− Không có nhà cung cấp lock-in
III. Swift Architectural Overview (kiến trúc)
3.1. Building Blocks
Các thành phần cho phép Swift để cung cấp tính sẵn sàng cao, độ bền cao và đồng thời
cao là:
−
−

Proxy Servers: xử lý tất cả các yêu cầu API.
Rings: Maps tên logic của dữ liệu đến các địa điểm trên đĩa cụ thể.

−

Zones: Mỗi Zone cô lập dữ liệu từ các zone khác. Một thất bại trong một zone không
ảnh hưởng đến phần còn lại của cluster vì dữ liệu được nhân rộng trên các zone.

−

Accounts & Containers: Mỗi tài khoản và container là cơ sở dữ liệu cá nhân được
phân phối trên cluster. Một cơ sở dữ liệu Account có chứa danh sách các Containers
trong Account đó. Một cơ sở dữ liệu Container chứa danh sách các đối tượng trong
Container đó.

−

Objects: Các dữ liệu của chính các đối tượng.

−

Partitions: phân vùng lưu trữ các đối tượng, cơ sở dữ liệu Account và cơ sở dữ liệu
container. Đây là một trung gian 'vùng chứa' giúp quản lý vị trí, nơi dữ liệu sống
trong cluster.
Swift cung cấp các nhóm tên miền không gian trong tài khoản như container.

Swift sử dụng các nhóm server để lưu trữ dữ liệu tĩnh, chẳng hạn như tài liệu, hình
ảnh hình ảnh, trên cơ sở lâu dài. Hệ thống hoạt động bằng cách sử dụng một thuật toán
băm để cung cấp một định danh duy nhất cho mỗi đối tượng hoặc tập tin, được lưu trữ trên
một node/server dữ liệu. Việc bổ sung các node / server mới cho phép các hệ thống mở
rộng theo chiều ngang.
Siêu dữ liệu cho từng object thường trú trên tất cả các server trong cluster và phần
mềm OpenStack đảm bảo sao chép dữ liệu. File yêu cầu đi tới Swift, Swift ủy quyền
server, server dịch các yêu cầu, xác định vị trí các đối tượng theo các thẻ băm và siêu dữ
liệu của họ, sau đó lấy các đối tượng và các tập tin.
Administrators chỉ định một hoặc nhiều server tới một zone, và mỗi zone có một bản sao
của mọi đối tượng. Hệ thống yêu cầu tối thiểu là ba zone để đảm bảo một sự cân bằng tối
ưu giữa hiệu quả chi phí và phòng chống mất dữ liệu (theo Beth Cohen, một kiến trúc sư
đám mây cao cấp tại Boston-Cloud Technology Partners Inc (cloudTP))
Page 12


3.2. Proxy Servers
Proxy Server là giao diện chung của Swift và xử lý các yêu cầu đến tất cả các API,
có trách nhiệm liên kết các phần còn lại của kiến trúc Swift. Với mỗi yêu cầu, nó sẽ tìm
kiếm vị trí của account, container, hoặc object trong Ring và định tuyến theo yêu cầu cho
phù hợp. Các API công cộng cũng được tiếp xúc thông qua Proxy Server.
Khi một Proxy Server nhận được yêu cầu, nó sẽ xác định các nút lưu trữ dựa trên
URL của đối tượng, ví dụ như:

/>Một số lượng lớn những failure cũng được xử lý trong các Proxy Server. Ví dụ, nếu
một server là không có sẵn cho một object PUT, nó sẽ yêu cầu Ring cho một handoff
server (chuyển giao server khác) và tuyến đường có thay thế.
Khi đối tượng được trực tiếp đến hoặc từ một object server thì sẽ được truyền trực tiếp
thông qua proxy server.
Proxy Servers sử dụng một kiến trúc được chia sẻ và có thể mở rộng khi cần thiết
trên cơ sở khối lượng công việc dự kiến. Có ít nhất hai máy chủ Proxy cần được triển khai
để dự phòng. Nếu một máy chủ proxy thất bại, những máy khác sẽ giành quyền điều khiển.
3.3. Ring
Một Ring đại diện cho một ánh xạ giữa tên của các thực thể được lưu trữ trên đĩa và
vị trí địa lý của chúng. Có Ring riêng biệt cho các account, container, và các object. Khi
các thành phần khác cần phải thực hiện bất kỳ hoạt động trên một container, object, hoặc
account, thì cần phải tương tác với Ring thích hợp để xác định vị trí của nó trong cluster.
Cấu trúc dữ liệu Ring bao gồm ba phần chính: một danh sách các thiết bị trong
cluster, một danh sách các danh sách id thiết bị để phân vùng tập thiết bị, và một số nguyên
cho biết số bit để tính toán băm để phân vùng.
Dữ liệu có thể được cô lập với nội dung của zone trong Ring. Mỗi bản sao của một
phân vùng được đảm bảo để thường trú trong một zone khác nhau. Một zone có thể đại
diện cho một ổ đĩa, một server, cabinet, một switch, hoặc thậm chí một trung tâm dữ liệu.
Các phân vùng của Ring được chia đều giữa tất cả các thiết bị trong quá trình cài
đặt Swift. Khi phân vùng cần phải được di chuyển xung quanh (ví dụ nếu một thiết bị được
thêm vào cluster), Ring đảm bảo rằng một số lượng tối thiểu các phân vùng được chuyển
tại một thời điểm, và chỉ có một bản sao của một phân vùng được di chuyển tại một thời
điểm.
Trọng lượng có thể được sử dụng để cân bằng sự phân bố của các phân vùng trên ổ
đĩa trên cluster. Điều này có thể hữu ích, ví dụ, khi ổ đĩa có kích thước khác nhau được sử
dụng trong một cluster.
Ring được sử dụng bởi các Proxy Server và một số tiến trình nền (như sao chép).
Bản đồ Ring phân vùng đến các địa điểm vật lý trên đĩa. Ring duy trì lập bản đồ này
bằng cách sử dụng các zone, thiết bị, phân vùng, và bản sao. Mỗi phân vùng trong Ring

được tái bản, theo mặc định, 3 lần qua cluster, và các địa điểm cho một phân vùng được
Page 13


lưu trữ trong các Map. Ring cũng chịu trách nhiệm xác định những thiết bị được sử dụng
cho handoff (bàn giao) khi failure.

Bản đồ Ring phân vùng đến các địa điểm vật lý trên đĩa.
3.4. Zone: Failure Boundaries (không ranh giới)
Swift cho phép zone được cấu hình để cô lập các ranh giới thất bại. Mỗi bản sao của
dữ liệu nằm trong một zone riêng biệt, nếu có thể. Ở cấp độ nhỏ nhất, một zone có thể là
một ổ đĩa đơn hay nhóm của một vài ổ đĩa. Nếu có năm object servers lưu trữ, thì mỗi máy
chủ sẽ đại diện cho zone riêng của mình. Phát triển lớn hơn thì sẽ có một rack (hoặc nhiều
rack) của object servers, mỗi rack đại diện cho một zone. Mục tiêu của zone là để cho phép
các cluster chịu mất các object server quan trọng mà không bị mất tất cả các bản sao của
dữ liệu.
Tất cả mọi thứ trong Swift được lưu giữ, theo mặc định là ba bản sao. Swift sẽ đặt
mỗi bản sao "như là duy nhất" để vừa đảm bảo tính sẵn sàng cao và độ bền cao. Điều này
có nghĩa là khi lựa chọn một vị trí bản sao, Swift sẽ lựa chọn một máy chủ trong khu vực
không sử dụng, và trong khu vực đó đã có một bản sao của dữ liệu.

Khi một ổ đĩa hỏng, bản sao dữ liệu được tự động phân phối cho các zone khác để đảm
bảo có ba bản sao của dữ liệu
3.5. Accounts & Containers
Mỗi account và container là một cơ sở dữ liệu SQLite riêng lẻ được phân phối trên
cluster. Một account database có chứa danh sách các container trong account đó. Một cơ sở
dữ liệu container chứa danh sách các đối tượng trong container đó.

Page 14

Để theo dõi vị trí của dữ liệu object, mỗi account trong hệ thống có một cơ sở dữ liệu, cơ
sở dữ liệu đó tham chiếu đến tất cả các container, và mỗi cơ sở dữ liệu container tham
chiếu đến mỗi object
a, Container Server
Công việc chính Server container là để xử lý danh sách các đối tượng. Nó không
biết về đối tượng, mà chỉ cần biết các đối tượng đang trong một container cụ thể. Danh
sách được lưu trữ như là các tập tin cơ sở dữ liệu SQLite, và nhân rộng trên các cluster
giống như đối tượng đó như thế nào, luôn theo dõi thống kê tổng số các đối tượng, và tổng
dung lượng sử dụng cho container đó.
SQLite là hệ thống cơ sở dữ liệu quan hệ nhỏ gọn, hoàn chỉnh, có thể cài đặt bên
trong các trình ứng dụng khác. SQLite được Richard Hipp viết dưới dạng thư viện bằng
ngôn ngữ lập trình C.
b, Account Server
Account Server tương đối giống với Server container, ngoại trừ, nó chịu trách nhiệm về
các danh sách các container chứ không phải là các đối tượng.
3.6. Object Server
Server Object là một blob lưu trữ server mà có thể lưu trữ, truy xuất và xóa các đối
tượng được lưu trữ trên các thiết bị địa phương. Đối tượng được lưu trữ như các tập tin nhị
phân trên filesystem với siêu dữ liệu được lưu trữ trong các thuộc tính mở rộng của tập tin
(xattrs). Điều này đòi hỏi: filesystem lựa chọn cho các object servers hỗ trợ xattrs trên các
tập tin. Một số filesystem, như ext3, có xattrs tắt theo mặc định.
Mỗi đối tượng được lưu trữ bằng cách sử dụng một đường dẫn có nguồn gốc từ dữ
liệu hỏng của tên đối tượng và dấu thời gian của hoạt động. Lần ghi cuối luôn thành công,
và đảm bảo rằng đối tượng phiên bản mới nhất sẽ được phục vụ. Xóa là một version (thế
hệ) của tập tin. Điều này đảm bảo rằng các tập tin đã xóa được nhân rộng một cách chính
xác và các phiên bản cũ hơn không xuất hiện trở lại do các failure.
3.7. Partitions (Phân vùng)
Phân vùng là một tập hợp các dữ liệu được lưu trữ, bao gồm databases account,
databases Container, và các object. Phân vùng là cốt lõi để hệ thống sao chép.

Xem một phân vùng như là một thùng di chuyển qua một nhà kho trung tâm. Đơn
đặt hàng riêng lẻ được đặt vào thùng. Hệ thống xử lý rằng thùng này như một thực thể gắn
kết khi nó di chuyển trên toàn hệ thống. Một thùng đầy sẽ tiết kiệm được các pha hoạt
động trên toàn hệ thống.
Page 15


Replication và update object hoạt động trên phân vùng. Khi hệ thống quy mô hơn,
số lượng của phân vùng là một số cố định.
Việc thực hiện các phân vùng là khái niệm rất đơn giản - một phân vùng chỉ là một thư
mục trên một đĩa với một bảng băm tương ứng của những gì nó chứa.

Phân vùng Swift có chứa tất cả các dữ liệu trong hệ thống.
3.8. Replication (tạo bản sao)
Replication được thiết kế để giữ cho hệ thống trong một trạng thái ổn định khi đối
mặt với các điều kiện lỗi tạm thời như mất mạng hoặc ổ đĩa thất bại.
Các quá trình Replication so sánh local data với mỗi bản sao từ xa để đảm bảo tất cả
Replication đều có chứa phiên bản mới nhất. Đối tượng sao chép sử dụng một danh sách
băm để nhanh chóng so sánh các phần phụ của mỗi phân vùng.
Replication cũng đảm bảo việc dữ liệu được xóa khỏi hệ thống, khi một mục
(object, container, hoặc account) bị xóa, thì tombstone được thiết lập như là phiên bản mới
nhất của item đó. Replication cho thấy những tombstone và đảm bảo rằng mục đó đã được
xóa khỏi toàn bộ hệ thống.

Nếu một Zone có dấu hiệu hỏng, một trong các nút có chứa bản sao sẽ thông báo và
chủ động sao chép dữ liệu đến một địa điểm bàn giao
3.9. Updaters
Khi dữ liệu container hoặc account không thể được cập nhật ngay lập tức, điều này
thường xảy ra trong các failure hoặc khoảng thời gian load lớn. Nếu bản cập nhật không
thành công, cập nhật được xếp hàng đợi tại local trên filesystem, và update sẽ xử lý các

bản update không thành công trước đó. Đây là nơi cuối cùng có khả năng đi vào để hoạt
động. Ví dụ: giả sử một container server tải và một object mới được đưa vào hệ thống. Các
object ngay lập tức có sẵn cho lần đọc ngay sau khi các proxy server đáp ứng cho
client. Tuy nhiên, các container server đã không cập nhật danh sách object, do đó, bản cập
Page 16


nhật sẽ được xếp hàng đợi cho một bản cập nhật sau đó. Vì thế danh sách Container có thể
tại thời điểm đó không có các object mới được đưa vào hệ thống.
3.10. Auditors (Kiểm toán viên)
Auditors thu thập dữ liệu local server để kiểm tra tính toàn vẹn của các object,
container, và account. Nếu sai xót được tìm thấy (trong trường hợp của bit rot (mục nát,
hỏng)), tập tin được cách ly, và replication sẽ thay thế các tập tin lỗi bằng bản sao khác.

IV. Tài liệu tham khảo:
1.
2. />3. />
Page 17