Image Service (Glance)



tải về 111.5 Kb.
Chuyển đổi dữ liệu26.01.2019
Kích111.5 Kb.




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 15

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


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 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 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

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



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 identifier: {u'checksum': u'b420e097baf54cd32af5970b3f0cb93b',

u'container_format': u'ami',

u'created_at': u'2011-07-06T00:54:23.600181',

u'deleted': False,

u'deleted_at': None,

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

Size

6

natty-uec

ami

ami

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.



Tài liệu tham khảo

[1] Openstask.org

[2] Deploying OpenStack - Reilly.

[3] OS image service devguide – Diablo (22/10/2011)


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

  • 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 http://swift.example.com/v1/account/

Để tạo container mới, sử dụng lệnh PUT  với tên của các container mới:



PUT http://swift.example.com/v1/account/new_container

Để 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 http://swift.example.com/v1/account/container/

Để tạo các đối tượng mới với một PUT trên đối tượng:



PUT http://swift.example.com/v1/account/container/new_object

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

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))


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ư:



https://swift.example.com/v1/account/container/object

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 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 đó.



Để 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.

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 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. http://swift.openstack.org

  2. http://swiftstack.com/

  3. http://docs.openstack.org/developer/swift/






Поделитесь с Вашими друзьями:


Cơ sở dữ liệu được bảo vệ bởi bản quyền ©tieuluan.info 2019
được sử dụng cho việc quản lý

    Quê hương