Phần này tóm tắt các phương pháp hay nhất và đưa ra đề xuất của chúng tôi về việc sử dụng OPDK với đám mây AWS.
Cassandra được dùng làm phần phụ trợ và kho dữ liệu cho hầu hết các chính sách, đồng thời là một phần quan trọng trong môi trường thời gian chạy Apigee Edge. Tài liệu này tập trung vào việc tối ưu hoá Cassandra cho môi trường AWS.
Yêu cầu về bộ nhớ và I/O
Hầu hết hoạt động I/O của Cassandra đều tuần tự, nhưng có những trường hợp bạn cần I/O ngẫu nhiên. Ví dụ: khi đọc Bảng chuỗi đã sắp xếp trong các thao tác đọc. SSD là cơ chế lưu trữ được đề xuất cho Cassandra, vì cơ chế này cung cấp thời gian phản hồi có độ trễ cực thấp cho các thao tác đọc ngẫu nhiên, đồng thời cung cấp đủ hiệu suất ghi tuần tự cho các thao tác nén. Việc sao chép cũng được xem xét ở đây.
Nhiều phiên bản trong AWS EC2 đi kèm với bộ nhớ cục bộ, trong đó ổ đĩa cứng được gắn vật lý vào phần cứng mà phiên bản EC2 được lưu trữ. Apigee khuyên bạn nên tận dụng cả SSD và kho lưu trữ thực thể khi chạy Cassandra trong môi trường thực tế. Khi sử dụng loại phiên bản có nhiều hơn 1 ổ SSD, bạn có thể dùng RAID0 để tăng công suất và dung lượng lưu trữ.
Yêu cầu về mạng
Cassandra sử dụng giao thức Gossip để trao đổi thông tin với các nút khác về cấu trúc liên kết mạng. Việc sử dụng Gossip cộng với bản chất phân tán của Cassandra (bao gồm việc giao tiếp với nhiều nút cho các thao tác đọc và ghi) dẫn đến việc truyền rất nhiều dữ liệu qua mạng. Apigee khuyên bạn nên sử dụng loại Phiên bản có băng thông mạng ít nhất là 1 Gb/giây và hơn 1 Gb/giây cho hệ thống phát hành công khai.
Sử dụng VPC có CIDR là /16. Vì mạng con trong AWS không thể trải dài trên nhiều AZ, nên Apigee đề xuất những điều sau:
- Tạo 1 mạng con cho mỗi Vùng sẵn sàng (AZ)
- Sử dụng 3 mạng con riêng tư cho quá trình cài đặt Apigee, với một nút Cassandra trong mỗi AZ. 3 mạng con phải có đủ khối CIDR để phù hợp với việc mở rộng theo chiều ngang của cụm Cassandra.
- Định cấu hình 3 mạng con công khai có NAT chuyên dụng để Cassandra có thể giao tiếp với Internet nhằm tải phần mềm xuống và cập nhật bảo mật.
Không giống như kiến trúc chính-phụ cũ, Cassandra có kiến trúc không có nút chính, trong đó tất cả các nút đều đóng vai trò giống hệt nhau, vì vậy không có điểm lỗi duy nhất. Cân nhắc việc phân bổ các nút Cassandra trên nhiều AZ để đảm bảo tính sẵn sàng cao. Bằng cách phân tán các nút trên nhiều AZ, bạn vẫn có thể duy trì khả năng hoạt động và thời gian hoạt động trong trường hợp xảy ra sự cố.
Chọn nhóm phiên bản
Khi xem xét các yêu cầu về CPU của Cassandra, bạn nên lưu ý rằng các khối lượng công việc có nhiều thao tác chèn sẽ bị ràng buộc bởi CPU trong Cassandra trước khi bị ràng buộc bởi IO. Nói cách khác, tất cả các thao tác ghi đều được chuyển đến nhật ký cam kết, nhưng Cassandra hoạt động hiệu quả đến mức CPU trở thành yếu tố hạn chế. Cassandra có tính đồng thời cao và sử dụng nhiều lõi CPU nhất có thể.
Apigee khuyên bạn nên sử dụng một nhóm thực thể có sự cân bằng giữa cả CPU và bộ nhớ. Cụ thể, bạn nên sử dụng các phiên bản thuộc dòng C5 nếu có trong khu vực AWS của bạn và C3 làm phương án dự phòng. Trong một số trường hợp, 4xlarge là phiên bản tối ưu trong cả hai nhóm, mang lại tỷ lệ giá/hiệu suất tốt nhất.
Apigee cũng đề xuất sử dụng một đối tượng thuê mặc định cho các thực thể Cassandra. Khi bạn mở rộng quy mô lên hơn 1 phiên bản cho mỗi AZ, nhiều khả năng tất cả các phiên bản Cassandra của bạn sẽ được đặt trên cùng một phần cứng cơ bản nếu bạn đặt chế độ thuê là chuyên dụng. Vì vậy, khi phần cứng gặp sự cố, bạn có thể mất tất cả các phiên bản trong AZ đó.
Nội dung tóm tắt về đề xuất
Bảng sau đây tóm tắt các đề xuất của Apigee về việc sử dụng AWS với Apigee Edge cho đám mây riêng tư:
| Nhóm thực thể | C5d (ưu tiên) hoặc C3 |
| Loại thực thể | C(x).4xlarge |
| Kho lưu trữ thực thể | SSD (bộ nhớ cục bộ) có RAID0 |
| Loại hình thuê nhà | mặc định |
| Vị trí nút | 1 nút Cassandra cho mỗi AZ |
| VPC và mạng con | 1 mạng con cho mỗi AZ và một VPC cho mỗi khu vực |
Để biết thêm thông tin, hãy xem bài viết Các loại phiên bản Amazon.