Phần 1: Máy chủ, CPU và RAM
Việc xác định yêu cầu phần cứng cho đám mây OpenStack không phải đơn giản; quá trình phức tạp này bởi khối lượng công việc (workload) và yêu cầu về tính sẵn sàng (availability requirements) của đám mây. Cùng thời điểm, nhiều chủng loại phần cứng sẵn có trên thị trường làm thậm chí còn đem lại nhiều thách thức để lựa chọn phù hợp với yêu cầu của đám mây theo tùy chọn cụ thể.
Trong phần đầu của bài này, sẽ xác định một số nguyên tắc cơ bản để cho phép xác định ưu tiên và xác định CPU, số lượng máy chủ và yêu cầu bộ nhớ cho đám mây build trên OpenStack. Trong phần thứ hai, sẽ tập trung vào các yêu cầu về lưu trữ phần cứng và mạng.
1. Các nút tính toán (Compute nodes)
Trong OpenStack, máy ảo (VM – virtual machine) của người dùng chạy trên các compute node (nút tính toán), các máy chủ hypervisor được quản lý bởi OpenStack. Để lựa chọn đúng số lượng và cấu hình của các nút đó, nói chung, cần chuyển các yêu cầu về khối lượng công việc tương ứng các công suất, về CPU, mạng bộ nhớ và lưu trữ.
1.1. Yêu cầu về CPU
Hầu hết các CPU(trong bối cảnh bài viết này CPU tương ứng với khái niệm chip vật lý) hiện đại đều hỗ trợ ảo hóa phần cứng (công nghệ AMD-V cung cấp bởi AMD, công nghệ VT-x do Intel cung cấp). Kiến trúc CPU phổ biến nhất cho đám mây OpenStack là x86-64.
Tính năng Hyper-Threading (siêu phân luồng) của Intel cải thiện xử lý song song, ví dụ như một CPU 12 nhân với Hyper-Threading có hiệu năng giống như CPU lõi 15-24, tùy thuộc vào khối lượng công việc.
Để xác định số lượng máy chủ, số lượng socket(chip) trên mỗi máy chủ và số core trên mỗi chip, cần có các yêu cầu cho khối lượng công việc của đám mây. Thông thường, cần một số máy ảo, một số VCPU trên mỗi VM và hiệu suất trung bình dự kiến của mỗi VCPU. Ví dụ, có thể tính toán tổng số lõi CPU cần:
Cores = VMs / HT / CO
Trong đó:
Cores – tổng số lõi CPU cần
VMs – tổng số máy ảo cần chạy
HT – hệ số Hyper-Threading. HT bằng 1,3 nếu CPU hỗ trợ Hyper-Threading, và bằng 1 nếu không hỗ trợ.
CO – hệ số quá tải của CPU (1 cho không oversubscription)
Số lượng socket CPU:
Sockets = Cores / Cores_Per_Socket
Trong đó:
Sockets – số socket CPU cần
Cores – tổng socket CPU cần
Cores_Per_Socket – số lõi trên mỗi socket
Cuối cùng, số lượng server cần là:
Servers = Sockets / Sockets_Per_Server
Trong đó Sockets_Per_Server là số lượng Socket trên mỗi Server
Ví dụ:
– OpenStack sẽ cần ảo hóa 100 VM: VMs = 100
– Không sử dụng Hyper-Threading: HT = 1
– Với cách sử dụng CPU oversubscription bằng 2, có nghĩa là trung bình sử dụng một lõi CPU (ví dụ, 2.4GHz) cho 2 VCPUs: CO = 2
– Số lượng CPU Core cần là: Cores = 100/1/2 = 50
– Nếu dự định dùng các chip 8 core: Cores_Per_Socket = 8
– Số lượng chip cần dùng là (lấy phần nguyên trên): Sockets = 50/7 = 8
– Nếu máy chủ cần dùng chỉ cắm được tối đa 2 chip (mainboard chỉ có 2 cpu socket). Vậy số máy chủ cần dùng là: Servers = 8/2 = 4
Do đó, để chạy 100 máy ảo với 2 CPU ảo, không có Hyper-Threading và CPU oversubscription, sẽ cần 4 máy chủ cho các compute node. Mỗi máy chủ sẽ có 2 socket để cắm CPU và 8 lõi CPU 2.4GHz trên mỗi chip.
Chú ý:
Nếu đã có một số loại máy ảo, hãy tính toán tổng số core CPU mỗi loại, sau đó tổng hợp chúng.
Đối với các máy chủ có NUMA, cần cẩn thận về CPU và bộ nhớ để đảm bảo rằng mỗi VM tiêu tốn CPU và bộ nhớ từ cùng một nút NUMA, nếu không hiệu suất của VM sẽ bị giảm xuống.
1.2. Yêu cầu về RAM
Các công thức sau để tính toán bộ nhớ cần thiết cho compute node:
VMs_Per_Server = VMs / Servers
RAM = RAM_Per_VM * VMs_Per_Server / MO + OS_RAM
Trong đó:
VMs – tổng số máy ảo cần chạy
Servers – số máy chủ cần
VMs_Per_Server – số máy ảo được tính trên mỗi máy chủ
RAM_Per_VM – RAM cho mỗi VM
MO – hệ số oversubscription RAM (1 nếu không có oversubscription)
OS_RAM – RAM yêu cầu cho hệ điều hành và hypervisor
Lưu ý, rằng hypervisor cũng có thể sử dụng bộ nhớ hệ thống cho các caches ổ đĩa. Khối lượng RAM cần thiết để lưu trữ cho tất cả các máy ảo là khó ước tính: nó phụ thuộc vào số lượng VM trên máy chủ host, số lượng đĩa cho mỗi máy ảo và loại bộ nhớ cache cho mỗi đĩa.
Ví dụ:
– Cần ảo hóa 100 áy ảo: VMs = 100
– Mỗi máy ảo giả sử cần 4 GB RAM: RAM_Per_VM = 4
– Với ví dụ ở trên dùng 4 máy chủ: Servers = 4
– Số máy ảo được ảo hóa trên mỗi server là: VMs_Per_Server = 100/4 = 25
– RAM không oversubscription nên: MO = 1
– Giả sử đáp ứng mỗi máy chủ RAM cho hệ điều hành là 16 GB: OS_RAM = 16
– Vậy RAM trên mỗi máy chủ tối thiểu là: 4*25 + 16 = 116
Vì vậy, để chạy 100 máy ảo với mỗi ổ cứng 4GB, không có RAM quá tải và ổ đĩa, vậy sẽ cần đến 116GB RAM trên mỗi compute node.
Để giảm lượng RAM vật lý cần thiết để chạy các máy ảo, có thể sử dụng kỹ thuật de-deduplication. Ví dụ, Transparent Page Sharing (TPS) cho Xen và Kernel Samepage Merging (KSM) cho KVM (xem thêm KVM Hypervisor: Quản lý bộ nhớ quá mức cam kết).
2. Các node khác
Một khi các yêu cầu cho các compute node được xác định, đã đến lúc suy nghĩ về các máy chủ cho các dịch vụ OpenStack và có node khác có thể cần cho đám mây OpenStack, chẳng hạn như các node lưu trữ riêng biệt. Nói chung, có hai tham số cho các dịch vụ OpenStack có liên quan đến việc lập kế hoạch phần cứng:
– Có bao nhiêu dịch vụ sẽ được triển khai dự phòng (dự phòng dịch vụ)
– Các dịch vụ sẽ được triển khai ở đâu(deployment mode)
3. Dịch vụ dự phòng
Đối với dấu chân đám mây lớn, sẽ cần nhiều trường hợp dịch vụ và cũng để cân bằng tải cho các dịch vụ. Ngoài ra nên cần nhiều hơn một hệ thống dự phòng cho mỗi dịch vụ để bảo đảm tính sẵn sàng cao.
4. Mode triển khai
Segregated services mode: giả sử rằng có các node vật lý cho các dịch vụ OpenStack và mỗi node chứa tất cả các dịch vụ được yêu cầu. Chế độ này là đơn giản nhất để triển khai và quản trị. Tuy nhiên như vậy có thể không được tối ưu.
Converged services mode: giả sử rằng các dịch vụ OpenStack được triển khai trên các nút hiện có. Có thể, như là một trường hợp cực đoan, mỗi nút trong đám mây có thể chứa tất cả các dịch vụ OpenStack yêu cầu ngoài khối lượng công việc đang chạy. Chế độ này không cần thiết phải có máy chủ riêng, nhưng các nút đám mây nên có thêm tài nguyên CPU và RAM để chạy các dịch vụ OpenStack. Các nguồn lực cho khối lượng công việc và cho các dịch vụ kiểm soát phải được cách ly một cách hợp lý để tránh tình trạng xuống cấp. Không cần phải nói, chế độ này khó triển khai và quản trị hơn segregate service mode
Tài nguyên phần cứng bắt buộc cho các dịch vụ riêng biệt phụ thuộc vào nhiều tham số, bao gồm:
– Số lượng các thể hiện dịch vụ đang chạy trong đám mây và trên nút cụ thể
– Các dịch vụ khác đang chạy trên cùng một nút
– Số nút tính toán
– Làm thế nào các đám mây sẽ được sử dụng
Ở đây, chúng tôi sẽ đưa ra các khuyến cáo phổ biến cho các dịch vụ cụ thể.
Hệ điều hành
Số lượng bộ nhớ, không gian đĩa và các tài nguyên cần thiết đều phụ thuộc vào hệ điều hành và dịch vụ hệ thống đang chạy trên node. Nói chung, nên sử dụng ít nhất 2 lõi CPU và 16 GB RAM cho hệ điều hành, dịch vụ hệ thống và tập tin lưu trữ.
RabbitMQ
RabbitMQ yêu cầu ít nhất 128MB bộ nhớ RAM và theo mặc định sẽ sử dụng tối đa 40% RAM có sẵn (available RAM). Với chế độ Segregated services mode, cần phải xác định bao nhiêu bộ nhớ sẽ dành cho RabbitMQ. Theo mặc định, RabbitMQ yêu cầu 50MB không gian đĩa trống (free disk space) mọi thời điểm và nên sử dụng ít nhất 2GB dung lượng đĩa trống. Càng nhiều consumer và queue càng cần hỗ trợ thêm bộ nhớ và không gian đĩa để dự trữ cho RabbitMQ.
MySQL với Galera
Mỗi node Galera cần ít nhất 1GHz CPU và 512MB RAM. Đối với các đám mây cấp độ chuyên dụng, sẽ cần ít nhất 2 lõi CPU và RAM 4-8 GB.
Các dịch vụ OpenStack
Tùy thuộc vào dịch vụ, có thể cần 0.5-2 core CPU và RAM 2-4GB cho mỗi dịch vụ.
Để tính đơn giản, hãy sử dụng segregated services mode. Trong trường hợp này, nên sử dụng cấu hình sau:
– Một số lẻ (ít nhất 3) các máy chủ phần cứng vật lý (dedicated server).
– Mỗi máy chủ phải có ít nhất 2 socket CPU với 6 lõi CPU (x86-64) cho mỗi socket
– Mỗi máy chủ phải có ít nhất 64GB RAM
Cấu hình này cho phép một đám mây OpenStack với hơn 1000 máy ảo. Lưu ý rằng, có thể thêm các compute node mới khi đám mây phát triển. Ngoài ra, với kiến trúc HA, có thể bắt đầu với một controller node nhỏ (2 lõi CPU, 2-4 GB RAM), nó không sẵn sàng cao, nhưng tất cả các dịch vụ đều có chứa “HA-ready”, cho phép thêm các controller node mà không có thời gian chết (downtime).
5. Các node khác có thể bổ sung
Xem xét rằng bổ sung các node sau đây trong một số trường hợp đối:
– Tùy chọn node director / master để lưu trữ master configuration
– Tùy chọn tách các node Database (3 cho HA configuration)
– Tùy chọn tách các node monitoring (3 cho HA configuration)
– Tùy chọn tách các node lưu trữ log tập trung (3 cho cấu hình HA)
Nguồn dịch: https://www.stratoscale.com/blog/openstack/openstack-hardware-requirements-and-capacity-planning-servers-cpu-and-ram-part-1/
