Wednesday, September 27, 2017

[EVE-NG] Một số câu hỏi thường gặp

Hỏi: Các cổng nào tôi phải mở trên tường lửa để cấp quyền truy cập telnet từ kết nối từ xa?
A: EVE đang sử dụng cổng bắt đầu từ 32768 

Công thức = 32768 + 128 * POD + 1 -> 32768 + 128 * POD + 128 POD: id người dùng (admin = 0)

Ví dụ: bạn có quản trị viên (POD 0) + 2 người dùng (POD 1, POD 2) 
32768 + 128 * 0 + 1 (cổng đầu tiên cho POD0) -> 32768 + 128 * 2 + 128 (cổng cuối của POD 2) = 32769 -> 33152
Cảng dành cho người vượt trội:
PODCảng đầu tiênCảng Cuối cùng
13276932896
23289733024
33302533152
43315333280
53328133408
63340933536
73353733664
số 83366533792
93379333920
103392134048
113404934176
123417734304
133430534432
143443334560
153456134688
163468934816
173481734944


vì vậy, ... toán học đơn giản. 
Tất nhiên bạn phải chắc chắn rằng mở cổng 80 (443 nếu bạn sử dụng SSL) và 22.
Hỏi: Làm thế nào để thiết lập lại cài đặt EVE quản lý IP / DNS / NTP / Root mật khẩu? 
A: từ loại EVI cli: rm -f /opt/ovf/.configured . Sau đó, khởi động lại và đăng nhập từ cli một lần nữa. EVE của bạn sẽ nhảy tới trình hướng dẫn cài đặt ban đầu.
H: Điều gì đã xảy ra với vai trò người dùng (Người dùng, Người biên tập)? 
A: Vai trò của người dùng đã bị xóa khỏi ấn bản cộng đồng và tất cả người dùng đều là quản trị viên. Vai trò người dùng là một phần của Trung tâm Đào tạo. (Thông tin chi tiết về phiên bản này, tính năng và ngày phát hành sẽ được đăng trên trang web, hãy theo dõi)
Hỏi: Tại sao các nút Qemu chậm trên I7 64G ram của tôi? 
A: Thông thường, chương trình chống sâu virus sẽ làm chậm Vmware Workstation và Virtual machines. Quan sát gần đây nhất là thậm chí các nút (vios, CSR) chạy trên EVE đã được kiểm tra AV. Tránh sử dụng AV trên vmware nhị phân.

Hỏi: Làm thế nào để nâng cấp EVE của tôi?
Xem VIDEO 
A: chạy các lệnh sau:
        apt-get update
        apt-get upgrade
QUAN TRỌNG: sau khi cập nhật VM EVE của bạn khởi động lại nó và CLEAR bộ nhớ cache của trình duyệt của bạn. 

Hỏi: Làm thế nào để di chuyển từ UNL sang EVE? Có thể nâng cấp được không? 
A: Không. Cách duy nhất là sao lưu tất cả các hình ảnh, phòng thí nghiệm từ UNL, cài đặt EVE tươi từ ISO hoặc OVA và khôi phục lại các bản sao lưu. 

Hỏi: Tại sao wireshark của tôi không hoạt động? 
A: Bạn cần phải chỉnh sửa tệp C: \ Program Files \ UNetLab \ wireshark_wrapper.bat và thay đổi mật khẩu gốc để khớp với mật khẩu bạn sử dụng. 

Hỏi: Bắt đầu hơn 10 CSR cho CPU HOG. Phải làm gì? 
Đáp: UKSM có lợi cho 10 CSR, nếu bạn muốn khởi chạy hơn 10 CSR, hãy vô hiệu UKSM
H: Làm thế nào để sửa các điều khoản? 
A: Run bellow lệnh từ cli 
        / opt / unetlab / wrappers / unl_wrapper-a fixpermissions 

Q: Làm thế nào để kiểm tra phiên bản EVE-NG đang chạy từ CLI? 
A: Chạy các lệnh từ cli 
        dpkg -l eve-ng
Hỏi: Tôi đang chạy trên không gian, làm thế nào tôi có thể thêm nhiều lưu trữ cho máy ảo?
Xem video
A: Hãy chắc chắn rằng bạn đang chạy phiên bản 2.0.2-23 EVE hay muộn 
        Power off VM 
        Add New Disk để VM với mong muốn kích thước 
        Bật VM
Hỏi: Tên người dùng và mật khẩu mặc định cho EVE-NG là gì? 
A: CLI - root / eve 
    WEB - admin / eve 
Hỏi: Làm thế nào để kết nối nhiều nút với cùng một mạng? 
A: Thêm một đối tượng mạng vào topology của phòng thí nghiệm và kết nối nhiều nút với nó.  
H: Trạng thái Giới hạn CPU là gì? 
Đáp: Nó hạn chế quá tải CPU cho mỗi nút, nhưng nó không liên quan đến việc sử dụng CPU thông thường.
Hỏi: Các nút IOL của tôi mất cấu hình trong NVRAM sau khi nâng cấp lên v2.0.3-53, tôi nên làm gì? 
Đ: Đúng, nếu phòng thí nghiệm đã được tạo ra trước phiên bản v2.0.2-23, IOL đã sử dụng mã cũ với lỗi được khắc phục trong bản phát hành sau này. phiên bản mới cần phải chạy lại nút đó sẽ tạo ra NVRAM mới cho IOL của bạn. Giải pháp để giữ cấu hình của bạn: Cách tốt nhất nếu bạn đã xuất khẩu các cấu hình bằng cách sử dụng tính năng xuất khẩu cfg. Sau đó, bạn có thể khởi động nút sau khi NVRAM quét sạch với cấu hình của bạn trong phiên bản EVE mới.
Hỏi: Làm thế nào để thiết lập lại / phục hồi truy cập quản trị web? 
A: Gõ tiếp theo EVE CLI như người dùng gốc: 
     echo "INSERT INTO users VALUES ('admin', NULL, 'root @ localhost', - 1, 'Eve-NG Administrator', '85262adf74518bbb70c7cb94cd6159d91669e5a81edf1efebd543eadbda9fa2b', NULL, '', ' admin ',' ', 1); " | mysql --host = localhost --user = root --password = eve-ng eve_ng_db
    Thao tác này sẽ thêm / khôi phục lại tài khoản "admin" với mật khẩu "eve" (không có dấu ngoặc kép)
Nguồn : http://www.eve-ng.net/
Posted by at 2 comments:

[EVE-NG] Thêm các Host Windows và Kali Linux vào EVE-NG

1. Thêm Host Windows vào EVE-NG

Đầu tiên bạn cần 1 bản cài Windows : file  .ISO  ,(hoặc file máy ảo thì càng tốt vì mục đích cuối cùng là chuyển sang định dạng .qcow2)
Chúng tôi đang sử dụng: Windows7SP1Ultimate_64_Bit.iso. Hãy chắc chắn rằng tên file không có dấu cách trong tên tập tin!  Bất kỳ phiên bản Windows nào cũng làm tương tự
  1. Tạo thư mục hình ảnh mới:
mkdir /opt/unetlab/addons/qemu/win-7test/


chú ý : *  win- là bắt buộc còn phần sau bạn có thể đặt tùy ý


        *  Bạn cũng có thể dùng WINSCP để thực hiện các thao tác Tạo foder , upload, di chuyển file, đổi tên file ...
  1. Sử dụng WINSCP hoặc FileZilla SFTP hoặc SCP (cổng 22) để sao chép file .ISO vào thư mục mới tạo, đường dẫn: / opt / unetlab / addons / qemu / win-7test /
  2. Từ console đi đến
cd /opt/unetlab/addons/qemu/win-7test/
  1. Đổi tên file này thành cdrom.iso
mv Windows7SP1Ultimate_64_Bit.iso cdrom.iso
  1. Từ EVE console vào thư mục Image được tạo
cd /opt/unetlab/addons/qemu/win-7test/
  1. Tạo mới hda.qcow2
/opt/qemu/bin/qemu-img create -f qcow2 virtioa.qcow2 30G


30G ở đây là dung lượng ổ cứng mình tạo cho nó , bạn có thể tùy chỉnh
  1. Tạo phòng thí nghiệm mới và thêm nút win-7test mới được tạo ra
  2. Chỉnh sửa cài đặt nút và thiết lập, qemu phiên bản 2.2.0 và NIC e1000.
  3. Tiến hành cài đặt Windows một cách bình thường như cài trên một máy tính
  4. Hoàn tất việc cài đặt và tắt máy windows vừa tạo
  5. Trên trang web của EVE LAB trên thanh bên trái chọn "Lab Details" để xem chi tiết về phòng thí nghiệm của bạn: trường hợp của tôi: UUID: 3491e0a7-25f8-46e1-b697-ccb4fc4088a2
  6. QUAN TRỌNG: Chuyển đổi hình ảnh tmp đã cài đặt của bạn:
qemu-img convert -c -O qcow2 /opt/unetlab/tmp/10/3491e0a7-25f8-46e1-b697-ccb4fc4088a2/1/hda.qcow2  /tmp/hda.qcow2
( 10 là POD số người sử dụng, trường hợp của tôi là 10, admin người sử dụng nó là 0, 1 là foder của node)
  1. Di chuyển image mới vào thư mục nút để ghi đè lên đĩa trống:
mv /tmp/hda.qcow2  /opt/unetlab/addons/qemu/win-7test/hda.qcow2
  1. Loại bỏ cdrom.iso khỏi / opt / unetlab / addons / qemu / win-7test /
cd /opt/unetlab/addons/qemu/win-7test/
rm -f cdrom.iso
LÀM XONG

Cách thêm một máy ảo có sẵn Vào EVE-NG :

      Chuẩn bị một máy ảo VM-ware (một foder máy ảo đầy đủ)


Từ EVE Console, tạo thư mục tmp :

mkdir tmp
cd tmp
Dùng WINSCP upload các file trong foder vừa chuẩn bị vào thư mục tmp vừa tạo
Chuyển đổi đĩa sang định dạng qcow2:
/opt/qemu/bin/qemu-img convert -f vmdk -O qcow2 Windows7SP1Ultimate_64_Bit.vmdk hda.qcow2
Tạo thư mục cho image HDD và di chuyển nó:
mkdir /opt/unetlab/addons/qemu/win-7vmdk
mv hda.qcow2 /opt/unetlab/addons/qemu/win-7vmdk

Dọn dẹp và chỉnh sửa điều khoản
cd ..
rm -rf tmp
/opt/unetlab/wrappers/unl_wrapper -a fixpermissions

Tạo phòng thí nghiệm mới và thêm node win-7vmdk mới được tạo ra

Lời khuyên : nên dùng cách này thay cho cách dùng file .iso nói trên vì nó sẽ nhanh hơn nhiều

Đối với Linux ta có thể làm tương tự

Chú ý : Foder Qmenu của Linux là linux- (ví dụ : linux-kali)


Posted by at 1 comment:
Labels:

Sunday, September 17, 2017

Tổng quan Cinder

Tổng quan Cinder

Mục lục

1. Giới thiệu Cinder
  • 1.1. Giới thiệu
  • 1.2. Các đặc điểm
  • Kiến trúc Cinder
2. Các thành phần
3. Tham khảo

1. Giới thiệu Cinder


1.1. Giới thiệu

  • Dịch vụ block storage cung cấp các tài nguyên lưu trữ dạng block theo kiểu persistent mà máy ảo compute có thể sử dụng. Đây là dịch vụ lưu trữ thứ cấp giống với dịch vụ lưu trữ Amazone Elastic Block Storage (EBS). Ngoài ra, bạn có thể ghi image vào một thiết bị lưu trữ Block storage cho Compute để sử dụng như là boot một máy ảo.
  • Dịch vụ Block storage khác với Amazon EBS. Dịch vụ Block storage không cung cấp giải pháp lưu trữ dùng chung như NFS. Với dịch vụ Block Storage, bạn có thể gán một thiết bị chỉ với một máy ảo.
    img
  • Trong Openstack, dịch vụ này được triển khai dưới tên gọi là Cinder.

1.2. Các chức năng

  • Cung cấp và quản lý các tài nguyên lưu trữ dạng persistent block storage (volume) cho các máy ảo.
  • Các volume này có thể được tách từ máy ảo này và gán lại vào một máy ảo khác, mà dữ liệu được giữ nguyên không bị thay đổi.
  • Hiện tại, một volume chỉ có thể được gán (attached) và một máy ảo tại một thời điểm.
  • Các volume tồn tại độc lập với các máy ảo (tức là khi máy ảo bị xóa thì volume không bị xóa).
  • Phân chia tài nguyên lưu trữ thành các khối gọi là Cinder volume.
  • Cung cấp các API như là tạo, xóa, backup, restore, tạo snapshot, clone volume và nhiều hơn nữa. Những API này thực hiện bởi các backend lưu trữ mà được cinder hỗ trợ.
  • Các kiến trúc plugin drive cho phép nhiều lựa chọn làm backend storage.

1.3. Kiến trúc Cinder

Các dịch vụ mà Block Storage - Cinder cung cấp là:
  • cinder-api - một ứng dụng WSGI dùng để xác thực và định tuyến các request yêu cầu trong dịch vụ Block Storage. Nó chỉ hỗ trợ các API của OpenStack, mặc dù có một translation có thể được thực hiện thông qua giao diện EC2 của Compute, mà sẽ gọi đến Block storage client.
  • cinder-scheduler - lập lịch trình và định tuyến các request yêu cầu tới một volume thích hợp. Tùy thuộc vào cấu hình của bạn, việc này có thể là lập lịch trình kiểu round-robin đơn giản cho các dịch vụ volume đang chạy, hoặc nó có thể phức tạp hơn thông qua việc sử dụng Filter Scheduler. Bộ lọc Filter Scheduler là cấu hình mặc định và cho phép bộ lọc về những thứ như Dung lượng - Capacity, Availability Zone, Volume Types, và Capabilities vcũng như các bộ lọc tùy chỉnh.
  • cinder-volume : quản lý các thiết bị Block Storage, cụ thể là các thiết bị back-end của chính chúng.
  • cinder-backup: cung cấp một phương tiện để sao lưu một Bloack storage volume tới khối lưu trữ OpenStack Object storage (Switf).
    img
  • cinder-client: CLI/UI để tạo request
  • drive: chứa các backend xác định để liên kết với nhiều loại storage khác nhau
  • Storage: Các nhà cung cấp thiết bị lưu trữ backend khác nhau
  • SQL DB: theo dõi các volume đang được sử dụng

2. Các thành phần Cinder

Dịch vụ Block Storage chứa các thành phần sau:
  • Back-end Storage Devices: dịch vụ Block Storage yêu cầu một số dạng lưu trữ back-end là nền tảng để triển khai. Việc triển khai mặc định là sử dụng LVM trên một logical volume group tên là 'cinder-volumes'. Ngoài việc triển khai trên drive mặc định, dịch vụ Block Storage còn cung cấp phương tiện để hỗ trợ các thiết bị lưu trữ khác được sử dụng như Raid Array hoặc các thiết bị lưu trữ khác. Các back-end này có thể tùy chỉnh kích thước block khi sử dụng KVM hoặc QEMU làm hypervisor.
  • Users và Tenants (Projects): dịch vụ Block Storage có thể được sử dụng bởi nhiều khách hàng hoặc khách hàng điện toán đám mây khác nhau (những tenant trên một hệ thống shared system), sử dụng gán quyền truy cập theo role. Các role điểu khiển các hành động mà người dùng được phép thực hiện. Trong cấu hình mặc định, hầu hết các hành động không yêu cầu role cụ thể, nhưng điều này có thể được cấu hình bởi quản trị viên hệ thống trong tệp policy.json thích hợp để duy trì các quy tắc. Quyền truy cập vào một volume cụ thể của người dùng bị giới hạn bởi tenant (project), nhưng tên người dùng và mật khẩu được chỉ định cho mỗi người dùng. Các cặp khóa key-pairs cho phép truy cập vào một volume được kích hoạt cho mỗi người dùng, nhưng hạn ngạch quotas để kiểm soát tài nguyên sử dụng trên các thiết bị phần cứng có sẵn là cho mỗi tenant. Với các tenant, kiểm soát quota có thể hạn chế:
    • Số volume có thể tạo.
    • Số snapshot có thể tạo.
    • Tổng dung lượng (GB) cho phép mỗi tenant (được chia sẻ giữa các bản snapshot và volume).
    Bạn có thể điều chỉnh được lượng quota mặc định với Block storage CLI, nhưng lượng quota đó vẫn có thể điều chỉnh bởi người dùng admin.
  • Volume, Snapshots và Backups - các tài nguyên cơ bản được cung cấp bởi dịch vụ Block Storage là các volume và snapshots có nguồn gốc từ volume và volume backup:
    • Volumes- cấp phát tài nguyên lưu trữ block storage có thể gắn với các instance như secondary storage hoặc chúng có thể được sử dụng như là root store để boot máy ảo. Volume là thiết bị lưu trữ dạng block R/W persistent được gắn với node compute thông qua giao thức iSCSI.
    • Snapshot: bản copy tại một thời điểm của volume. Snapshot có thể được tạo ra từ một volume hiện đang được sử dụng (thông qua sử dụng tùy chọn --force True) hoặc ở trạng thái available. Snapshot sau đó có thể được sử dụng để tạo một volume mới thông qua việc tạo từ Snapshot.
    • Backups: một bản copy lấy được từ volume hiện tại được lưu trữ trong Object storage (Swift).
Trên đây chỉ là một vài thông tin sơ bộ, chi tiết về Cinder tìm hiểu kĩ hơn tại đây.

3. Tham khảo

[1] https://docs.openstack.org/ocata/config-reference/block-storage/block-storage-overview.html
[2] https://www.slideshare.net/dpkshetty/gluster-meetup-openstackdeepakcs

nguồn:hocchudong
Posted by at No comments:
Labels:

LibVM

Một trong các giải pháp thu thập thông tin mức thấp của các máy ảo, LibVM là một công cụ được phát triển với nhiều triển vọng. LibVMI là thư viện thu thập thông tin đọc, ghi vào bộ nhớ từ máy ảo (VMs). Nhằm sử dụng thuận lợi hơn, LibVMI cung cấp chức năng truy cập thanh ghi CPU, dừng máy ảo, in dữ liệu và nhiều chức năng khác. LibVMI được thiết kế để làm việc độc lập nền tảng ảo hóa. LibVMI hỗ trợ chạy trên Xem và KVM, nó cũng hỗ trợ đọc bộ nhớ vật lý trong bản snapshot khi nó được lưu thành các file.
Tìm hiểu chi tiết tại http://libvmi.com
Phân tích sâu tại https://www.acsac.org/2007/papers/138.pdf
https://drakvuf.com/
Posted by at No comments:
Labels: , ,

Monday, September 11, 2017

# Các project trong OpenStack # Mục lục

A. Kiến trúc của OpenStack

B. Các project trong OpenStack

---

A. Kiến trúc của OpenStack

  • I - Kiến trúc mức khái niệm

    Kiến trúc mức khái niệm thể hiện mối quan hệ giữa các dịch vụ trong OpenStack, như sơ đồ dưới đây.

  • II - Kiến trúc mức logic

    Kiến trúc mức logic thể hiện rõ ràng mối quan hệ giữa các tiến trình trong mỗi project và quan hệ của chúng với tiến trình của các project khác trong OpenStack. Người quản trị cloud OpenStack muốn thiết kế, triển khai, cấu hình hệ thống của mình cần phải hiểu sơ đồ này. Dưới đây là kiến trúc mức logic của một cloud OpenStack. (Cập nhật theo phiên bản Mitaka).
---

B. Các project trong OpenStack

  • I - Keystone - Identity Service

    • Cung cấp dịch vụ xác thực cho toàn bộ hạ tầng OpenStack
      • Theo dõi người dùng và quyền hạn của họ
      • Cung cấp một catalog của các dịch vụ đang sẵn sàng với các API endpoints để truy cập các dịch vụ đó
    • Về mặt bản chất, Keystone cung cấp chức năng xác thực và ủy quyền cho các phần tử trong OpenStack. Người dùng khai báo chứng thực với Keystone và dựa trên kết quả của tiến trình xác thực, nó sẽ gán "role" cùng với một token xác thực cho người dùng. "Role" này mô tả quyền hạn cũng như vai trò trong thực hiện việc vận hành OpenStack.
    • "User" trong Keystone có thể là:
      • Con người
      • Dịch vụ (Nova, Cinder, neutron, etc.)
      • Endpoint (là địa chỉ có khả năng truy cập mạng như URL, RESTful API, etc.)
    • Keystone gán một tenant và một role cho user. Một user có thể có nhiều role trong các tenants khác nhau. Tiến trình xác thực có thể biểu diễn như sau:
    • Keystone được tổ chức theo nhóm các nội dịch vụ (internal services)tương tác với một hoặc nhiều endpoints. Các nội dịch vụ đó là:
      • Identity:
        • Cung cấp dịch vụ chứng thực và dữ liệu về Users, Groups, Projects, Domains Roles, metadata, etc.
        • Về cơ bản, tất cả các dữ liệu này được quản lý bởi dịch vụ, cho phép các dịch vụ quản lý các thao tác CRUD (Create - Read - Update - Delete) với dữ liệu
        • Trong nhiều trường hợp khác, dữ liệu bị thu thập từ các dịch vụ backend được ủy quyền khác như LDAP
      • Token: Xác nhận và quản lý các tokens được sử dụng để xác thực yêu cầu khi thông tin của người dùng đã được xác minh
      • Catalog: cung cấp một endpoint registry sử dụng để phát hiện endpoint
      • Policy: cung cấp engine để ủy quyền dựa trên rule và kết nối với giao diện quản lý rule
    • Mỗi dịch vụ này có thể được cấu hình để sử dụng một dịch vụ back-end. Một số back-end service điển hình:
      • Key Value Store: cung cấp giao diện hỗ trợ tìm kiếm theo khóa
      • Memcached: Là hệ thống phân phối và lưu trữ bộ nhớ đệm (cache) và chứa dữ liệu trên RAM. (lưu tạm thông tin những dữ liệu hay sử dụng và bộ nhớ RAM)
      • SQL: sử dụng SQLAlchemy để lưu trữ dữ liệu bền vững
      • Pluggable Authentication Module (PAM): sử dụng dịch vụ PAM của hệ thống cục bộ cho việc xác thực
      • LDAP: kết nối thông qua LDAP tới một thư mục back-end, như Active Directory để xác thực các user và lấy thông tin về role
    • Từ bản Juno, Keystone có tính năng mới là federation of identity service. Nghĩa là thay vì việc xác thực tập trung, việc xác thực sẽ phân tán trên Internet, hay còn gọi là Identity Providers(IdPs). Lợi ích của việc sử dụng IdPs:
      • Không cần phải dự phòng các user entries trong Keystone (các bản ghi về người dùng), bởi vì các user entries đã được lưu trữ trong cơ sở dữ liệu của các IdPs
      • Không cần phải xây dựng mô hình xác thực trong Keystone, bởi vì các IdPs chịu trách nhiệm xác thực cho người dùng sử dụng bất kỳ công nghệ nào phù hợp. Do đó có thể kết hợp nhiều công nghệ xác thực khác nhau
      • Nhiều tổ chức hợp tác có thể chia sẻ chung các dịch vụ cloud bằng cách mỗi tổ chức sẽ sử dụng IdP cục bộ để xác thực người dùng của họ

  • II - Nova - Compute Service

    • Chức năng

      • Thực hiện quản lý vòng đời các máy ảo, cung cấp abstract layer tương tác với hypervisors được hỗ trợ: Hyper-V, VMware, XenServer, Xen via libvirt, KVM (libvirt/QEMU)
      • Nova phân lại hypervisors thành 3 nhóm dựa trên số lượng các bài kiểm thử thành công với các driver tương tác với hypervisors:
        • GROUP A: libvirt (qemu/KVM on x86). Các drivers này được hỗ trợ hoàn toàn. Các bài kiểm tra bao gồm: unit test và functional testing
        • GROUP B: Hyper-V, VMware, XenServer. Các drivers này được hỗ trợ ở mức trung bình. Các bài test bao gồm: unit test và functional testing cung cấp bởi một hệ thống bên ngoài.
        • GROUP C: baremetal, docker, Xen via libvirt, LXC via libvirt. Các driver này được thực hiện một số bài kiểm thử nhỏ và có thể hoạt động không ổn định. Việc sử dụng chúng là mạo hiểm. Các bài test bao gồm: unit tests và các bài test chức năng không public

    • Các thành phần - gồm 7 thành phần chính:

      • Cloud Controller: đại diện cho trạng thái toàn cục và tương tác với các component khác
      • API Server: có thể coi như các Web services cho cloud controller
      • Compute Controller: cung cấp tài nguyên máy chủ tính toán
      • Object Store: cung cấp dịch vụ lưu trữ
      • Auth Manager: cung cấp dịch vụ xác thực và ủy quyền
      • Volume Controller: cung cấp các khối lưu trữ bền vững và nhanh chóng cho các computer server
      • Network controller: cung cấp mạng ảo cho phép các compute server tương tác với nhau và với public network
      • Scheduler lựa chọn compute controller phù hợp nhất để host một instance (máy ảo)

    • Mối quan hệ giữa các thành phần

      • Sơ đồ: Chú ý: Message Queue và các back-end database rất quan trọng trong khi vận hành Nova
      • Message Queue có thể là bất kì một AMQP message queue nào. Trong OpenStack đó là RabbitMQ, Apache Qpid và ZeroMQ
      • Back-end database thông thường là sqlite3, MySQL và PostgreSQL
      • Mô tả ngắn gọn về Nova:
        • End users (DevOps, Dev, hoặc có thể là các thành phần khác trong OpenStack) sẽ "nói chuyện" với nova-api để tương tác với OpenStack Nova
        • Các OpenStack Nova daemons trao đổi thông tin qua queue (lưu trữ các actions) và database (infomation) để thực hiện các API requests
        • OpenStack Glance giao tiếp với OpenStack Nova interfaces thông qua Glance API
        • Nova-networking vẫn được sử dụng trong một số use cases. Người dùng có thể lựa chọn nova-networking hoặc Neutron

  • III - Glance - Image Service

    • Giới thiệu

      OpenStack Image Service cung cấp dịch vụ quản lý các disk image của các máy ảo. Dịch vụ này cung cấp dịch vụ tìm kiếm, đăng ký, chuyển các disk image tới Compute service và cũng dùng vào mục đích dự phòng các máy ảo.

    • Các thành phần

      Danh sách các tiến trình của Images Service và chức năng của chúng:
      • glance-api: nó tiếp nhận lời gọi Image API để thực hiện tìm kiếm, thu thập và lưu trữ các images
      • glance-registry: lưu trữ, thực thi và thu thập metadata về các image (size, type, etc.)
      • glance-database: là cơ sở dữ liệu lưu trữ metadata của các image
      • storage repository: là các image files. Glance hỗ trợ hệ thống file thông thường như: RADOS block devices, Amazon S3, HTTP và Swift
      Glance tiếp nhận các API request về images (hoặc metadata của images) từ người dùng cuối hoặc các Nova component và có thể lưu trữ các file ổ đĩa trong object storage service, Swift hoặc các storage repo khác.

    • Danh sách các định dạng ổ đĩa và container được hỗ trợ bao gồm:

      • Disk Format: Disk format của một image máy ảo là định dạng của disk image, bao gồm:
        • raw: là định dạng ảnh đĩa phi cấu trúc
        • vhd: là định dạng ảnh đĩa chung sử dụng bởi các công nghệ VMware, Xen, Microsoft, VirtualBox, etc.
        • vmdk: định dạng ảnh đĩa chung hỗ trợ bởi nhiều công nghệ ảo hóa khác nhau (điển hình là VMware)
        • vdi: định dạng ảnh đĩa hỗ trợ bởi VirtualBox và QEMU emulator
        • iso: định dạng cho việc lưu trữ dữ liệu của ổ đĩa quang
        • qcow2: hỗ trợ bởi QEMU và có thể ở rộng động, hỗ trợ copy on write
        • aki, ari, ami
      • Container Format:
        • bare: định dạng này xác định rằng không có container cho image
        • ovf: định dạng OVF container
        • aki: xác định Amazon kernel image lưu trữ trong Glance
        • ami: Xác định Amazon ramdisk image lưu trữ trong Glance
        • ova: xác định file OVA tar lưu trữ trong Glance

    • oVirt tích hợp với Glance:

      oVirt (Open Virtualization Manager) từ Red Hat là project cho phép oVirt user sử dụng, trích xuất và share images với Glance. Glance sẽ được coi như một External Provider cho oVirt 3.3.
      Bên cạnh việc import và export ác image tới Glance, việc tích hợp oVirt cho phép oVirt thực hiện tìm kiếm image và liệt kê nội dung của Glance trên giao diện của oVirt



      Tính năng hữu ích khác khi tích hợp oVirt với Glance đó là oVirt có thể "discover" kích thước của image định dạng QCOW2 bằng cách tìm kiếm trong QCOW2 header. Glance metadata không cung cấp kích thước của image.

    • Glance API:

      API đóng vai trò quan trọng trong việc xử lý image của Glance. Glance API có 2 version 1 và 2. Glance API ver2 cung cấp tiêu chuẩn của một số thuộc tính tùy chỉnh của image.
      Glance phụ thuộc vào Keystone và OpenStack Identity API để thực hiện việc xác thực cho client. Bạn phải có được token xác thực từ Keystone và gửi token đó đi cùng với mọi API requests tới Glance thông qua X-Auth-Token header. Glance sẽ tương tác với Keystone để xác nhận hiệu lực của token và lấy được các thông tin chứng thực

  • IV - Cinder - Block Storage Service

    • Sơ lược về Cinder

      • Tương tự như Amazon Web Services S3 (Simple Storage Service) cung cấp khối lưu trữ bền vững (persistent block storage) để vận hành các máy ảo.
      • Cinder cung cấp dịch vụ Block Storage. Một cách ngắn gọn, Cinder thực hiện ảo hóa pool các khối thiết bị lưu trữ và cung cấp cho người dùng cuối API để request và sử dụng tài nguyên mà không cần biết khối lưu trữ của họ thực sự lưu trữ ở đâu và loại thiết bị là gì. Cũng như các dịch vụ khác trong OpenStack, self service API được sử dụng để tương tác với dịch vụ Cinder.
      • Ý tưởng chính của Cinder là cung cấp một lớp abstract cho người dùng cuối đối với các khối thiết bị lưu trữ. Người dùng Cinder không cần phải biết chi tiết hay quản lý khối thiết bị lưu trữ vật lý, chỉ cần sử dụng khối lưu trữ được cung cấp.

    • Các thành phần của Cinder




      • Cinder-api:
        • Một ứng dụng WSGI có vai trò xác thực và chuyển request trong toàn bộ dịch vụ Block Storage
        • Request được gửi tới cinder-scheduler rồi điều hướng tới cinder-volumes thích hợp
      • Cinder-scheduler:
        • Dựa trên request được điều hướng tới, cinder-scheduler chuyển request tới Cinder Volume Service thông qua giao thức AMQP (lưu trữ bản tin điều hướng trong Queue của RabbitMQ hoặc Qpid)
        • Có thể được cấu hình để sử dụng cơ chế round-robin
        • Filter Scheduler là mode mặc định xác định nơi để gửi volume dựa trên Capacity, Avalability Zone, Volume Types, Capabilities cũng các bộ lọc tùy biến
      • Cinder-volume:
        • Quản lý các công nghệ lưu trữ back-ends khác nhau
        • Tương tác trực tiếp với phần cứng hoặc phần mềm cung cấp khối lưu trữ
        • Cung cấp khung nhìn của volume cung cấp cho người dùng
      • Cinder-backup: Cung cấp dịch vụ backups của Cinder volumes cho OpenStack Swift

    • Một số khái niệm quan trọng trong Cinder

      • Back-end Storage Devices
        • Mặc định là LVM (Logical Volume Manager) trên nhóm các volume cục bộ - "cinder-volumes"
        • Hỗ trợ các thiết bị khác như RAID ngoài hoặc các thiết bị lưu trữ
        • Kích thước khối lưu trữ được điều chỉnh sử dụng hypervisor như KVM hoặc QEMU
      • Users và Tenants/Projects
        • Sử dụng cơ chế Role-based Access Control (RBAC) cho multi-tenants
        • Sử dụng file "policy.json" để duy trì rule cho mỗi role
        • Volume truy cập bởi mỗi người dùng riêng biệt
        • Định ra Quotas để kiểm soát mức độ tiêu tốn tài nguyên thông qua tài nguyên phần cứng sẵn sàng cho mỗi tenants
        • Quota có thể được sử dụng để kiểm soát: số lượng volume và snapshots có thể tạo ra cũng như tổng dung lượng (theo GBs) cho phép đối với mỗi tenants
      • Volumes, Snapshots và Backups:
        Tài nguyên mà dịch vụ Block Storage service cung cấp là volumes và snapshots:
        • Volumes: Cấp phát các khối lưu trữ có thể attach vào các instance như một khối lưu trữ thứ hai hoặc có thể sử dụng đẻ boot các instances. Volume là các khối lưu trữ đọc/ghi bên vững được attach trên compute node thông qua iSCSI
        • Snapshots: có thể được khởi tạo từ 1 volume đang sử dụng (bằng việc sử dụng tùy chọn --force True) hoặc trong trạng thái sẵn sàng. Snapshot sau đó có thể sử dụng để tạo volume mới.
        • Backups: là bản dự phòng của 1 volume lưu trữ trong OpenStack Object Storage
        Lưu trữ vật lý hỗ trợ Cinder có thể là ổ vật lý HDD hoặc SSD. NÓ cũng có thể là hệ thống lưu trữ ngoài cung cấp bởi giải pháp lưu trữ của bên thứ ba như NetApp hoặc EMC

  • V - Swift - Object Storage Service

    • Giới thiệu

      • Swift là nền tảng lưu trữ mạnh mẽ, có khả năng mở rộng và chịu lỗi cao, đượ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.
      • Swift có tính "dự phòng" 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, tránh được những thất bại phổ biến như các vấn đề về ổ cứng, mạng, mất dữ liệu, etc.
      • Swift lưu trữ dữ liệu phi cấu trú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ữ thep khối, 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.

    • Kiến trúc Swift

      Có thể nhìn nhận swift dưới kiến trúc gồm 2 tầng như sau



      Swift có 2 loại node:
      • Proxy Nodes: những node này tương tác với "Swift client" và thực hiện xử lý các yêu cầu. Client chỉ có thể tương tác với Proxy nodes
      • Storage Nodes: đây là các node lưu trữ các objects

    • Một số thuật ngữ



      • Data access:
        • Ring - "Trái tim" của Swift. 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.
          Sơ đồ dưới đây mô tả mối quan hệ giữa Proxy server với Account, Object, Container server thông qua Ring

        • Partition: 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.
      • Data representation:
        • Objects: là các bản ghi dưới dạng key-value lưu trữ dữ liệu các đối tượng
        • Container: nhóm các object
        • Account: nhóm các 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 đó.
      • Servers type:
        • Proxy server: 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
        • 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ị cục bộ.
        • 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ể.
        • 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.
      • Utility process:
        • Replicator: tiện ích xử lý tạo bản sao dữ liệu
        • Updater: xử lý các bản update không thành công của dữ liệu container hoặc account.
        • Auditor: 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

  • VI - Neutron - Networking Service

    • Neutron - Networking Service

      • Ban đầu khi OpenStack mới ra mắt, dịch vụ network được cung cấp trong Nova - nova-networking. Sau này, khi OpenStack ngày càng trưởng thành, yêu cầu đặt ra là phải có module networking mạnh mẽ và khả chuyển (powerful & flexible).
      • Nova-networking bị hạn chế trong các network topo, và gần như không hỗ trợ các giải pháp của bên thứ ba. Nova-network chỉ có thể sử dụng Linux-bridge, hạn chế network type và iptable để cung cấp dịch vụ mạng cho hypervisor trong Nova. Do đó project network thay thế nova-networking ra đời - ban đầu đặt tên Quantum sau đổi tên lại thành Neutron

    • Các thành phần của neutron

      • neutron server (neutron-server là neutron-*-plugin)
        Dịch vụ này chạy trên các network node để phục vụ Networking API và các mở rộng của nó. Nó cũng tạo ra network model và đánh địa chỉ IP cho mỗi port. neutron-server và các plugin agent yêu cầu truy cập vào database để lưu trữ thông tin lâu dài và truy cập vào message queue (RabbitMQ) để giao tiếp nội bộ (giữa các tiến trình và với các tiến trình của các project khác)
      • plugin agent (neutron-*-agent)
        Chạy trên các Compute node để quản lý cấu hình các switch ảo cục bộ (vSwitch). Các plugin này xác định xem những agent nào đang chạy. Dịch vụ này yêu cầu truy cập vào message queue.
      • DHCP agent (neutron-dhcp-agent)
        Cung cấp dịch vụ DHCP cho tenant networks. Agent này chịu trách nhiệm duy trì cấu hình DHCP. neutron-dhcp-agent yêu cầu truy cập message queue
      • L3 agent (neutron-l3-agent)
        Cung cấp kết nối ra mạng ngoài (internet) cho các VM trên các tenant networks nhờ L3/NAT forwarding.
      • network provider service (SDN server/services)
        Cung cấp dịch vụ mạng nâng cao cho tenant network. Các dịch vụ SDN này có thể tương tác với neutron-server, neutron-plugin, plugin-agents thông qua REST APIs hoặc các kênh kết nối khác.

    • Neutron API

      Neutron API cho phép người dùng định nghĩa:
      • Network: người dùng có thể tạo ra một L2 segment tách biệt, tương tự như VLAN
      • Subnet: người dùng có thể định nghĩa ra được một tập các địa chỉ IP v4 hoặc v6 và các tham số cấu hình liên quan
      • Port: là điểm kết nối cho phép attach một thiết bị đơn lẻ (ví dụ như card mạng của server ảo) vào mạng ảo (Virtual network) cũng như các thông số cấu hình network liên quan như địa chỉ MAC và IP được sử dụng trên port đó.

    • Neutron API extension


      Với API extension. user có thể định nghĩa nên các chức năng mạng bổ sung thông qua Neutron plugins. Sơ đồ dưới đây biểu diễn mối quan hệ giữa Neutron API, Neutron API extension và Neutron plugin - plugin interface để giao tiếp với SDN Controller - OpenDaylight.

    • Neutron plugins


      Là giao diện kết nối giữa Neutron và các công nghệ back-end như SDN, Cisco, VMware NSX. Nhờ đó người dùng Neutron có thể tận dụng được các tính năng nâng cao của các thiết bị mạng hoặc phần mềm mạng của bên thứ ba. Các plugin này bao gồm: Open vSwitch, Cisco UCS/Nexus, Linux Bridge, Nicira Network Virtualization Platform, Ryu OpenFlow Controller, NEC OpenFlow.
      Một trong các plugin không trực tiếp liên quan tới công nghệ bên thứ ba nhưng là 1 plugin quan trọng đó là ML2 (Modular Layer 2) plugin. Plugin này cho phép hoạt động đồng thời của nhiều công nghệ mạng hỗn hợp trong Neutron.


      Không có ML2 driver, Neutron chỉ có thể cung cấp dịch vụ lớp 2. Hai khái niệm về driver trong ML2 là Type và Mechanism:
      • Type Manager: GRE, VLAN, VXLAN
      • Mechanism Manager: Cisco APIC, Cisco Nexus, Linux Bridge, OvS

  • VII - Horizon - Dashboard Service

    Cung cấp giao diện nền web cho người dùng cuối và người quản trị cloud để tương tác với các dịch vụ khác của OpenStack, ví dụ như vận hành các instance, cấp phát địa chỉ IP và kiểm soát cấu hình truy cập các dịch vụ. Một số thông tin mà giao diện người dùng cung cấp cho người sử dụng:
    • Thông tin về quota và cách sử dụng
    • Instances để vậy hành các máy ảo cloud
    • Volume Management điều khiển khởi tạo, hủy kết nối tới các block storage
    • Images and Snapshots để up load và điều khiển các virtual images, các virtual images được sử dụng để back up hoặc boot một instance mới
    • Mục addition cũng cung cấp giao diện cho hệ thống cloud:
      • Project: cung cấp các group logic của các user
      • User: quản trị các user
      • System Info: Hiển thị các dịch vụ đang chạy trên cloud
      • Flavors: định nghĩa các dịch vụ catalog yêu cầu về CPU, RAM và BOOT disk storage

  • VIII - Heat - Orchestration Service

  • IX - Ceilometer - Monitoring and Metering Service

  • X - Trove - Database Service

    • Giới thiệu Trove


      Trove là dịch vụ cho phép người dùng sử dụng database quan hệ hoặc phi quan hệ (Relational database và Non-Relational database - NoSQL) mà không cần quan tâm tới hạ tầng database. Nó tạo ra lớp abstract giữa người dùng và database, thực hiện dự phòng, mở rộng và quản lý database trên hạ tầng OpenStack.

    • Kiến trúc của Trove





      Trove tương tác với các thành phần khác trong OpenStack để cung cấp dịch vụ Database



    • Các thành phần của Trove


      Các thành phần chủ đạo của Trove:
      • API server
      • Message Bus
      • Task Manager
      • Guest Agent
      • Conductor
      Cụ thể hơn:
      • Trove-api service là một WSGI thực hiện REST API mà dựa vào đó người dùng có thể dự phòng database instance, để mở rộng tài nguyên cpu và memory của databas instance cũng như không gian lưu trữ. API cũng có thể sử dụng để quản lý các database instance. Như hình vẽ trên, một database (có thê là MySQL hoặc PosgreSQL) và một Message Bus(RabbitMQ, Qpid) được sử dụng cho trove api server để giao tiếp với trove-taskmanager - tại đó mọi hành động sẽ được thực thi.
      • Trove-taskmanager nói chuyện với Nova, Cinder, Glance khi database image được lưu trữ. Khi database instance chạy, Guest Agent - một thành phần của database instance sẽ thực hiện health check và tương tác trở lại với health status của database instance thông qua trove-conductor
      • Trove cũng tương tác với Keystone để xác thực cũng như Neutron để sử dụng dịch vụ mạng
      • Trove hỗ trợ các hệ quản trị csdl sau: MySQL, MongoDB, Cassandra, Redis, CouchDB, PostgreSQL

  • XI - Messaging and Queuing System in OpenStack

Posted by at No comments:
Labels:
Subscribe to: Posts (Atom)