Phần này tóm tắt các phương pháp hay nhất và đưa ra các đề 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á Casssandra cho môi trường AWS.
Yêu cầu về bộ nhớ và I/O
Hầu hết Cassandra I/O đều diễn ra tuần tự, nhưng có những trường hợp bạn yêu cầu I/O ngẫu nhiên. Ví dụ là 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ì ổ SSD cung cấp thời gian phản hồi rất 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 thực thể 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à thực thể EC2 được lưu trữ. Apigee đề xuất tận dụng cả ổ SSD và kho lưu trữ thực thể khi chạy Cassandra trong phiên bản chính thức. Khi sử dụng một loại thực thể có nhiều ổ SSD, bạn có thể sử 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 tính chất phân phối 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 đề xuất sử dụng loại Phiên bản có băng thông mạng tối thiểu là 1Gbps và trên 1Gbps đối với các hệ thống phát hành chính thức.
Sử dụng VPC với CIDR là /16. Vì các mạng con trong AWS không thể mở rộng trên nhiều hơn 1 AZ, nên Apigee đề xuất những biện pháp sau:
- Tạo 1 mạng con cho mỗi Khu vực sẵn sàng (AZ)
- Sử dụng 3 mạng con riêng để cài đặt Apigee, trong đó có 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 với 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ó chủ sở hữu, trong đó tất cả các nút đều đóng vai trò giống nhau, do đó không có điểm lỗi duy nhất. Hãy cân nhắc trải rộng các nút Cassandra trên nhiều AZ để mang lại khả năng sử dụng cao. Bằng cách trải các nút trên các AZ, bạn vẫn có thể duy trì khả năng sử dụng và thời gian hoạt động trong trường hợp xảy ra thảm hoạ.
Chọn nhóm thực thể
Khi xem xét các yêu cầu về CPU của Cassandra, bạn cần lưu ý rằng những tải công việc nặng về chèn được ràng buộc với CPU trong Cassandra trước khi bị ràng buộc với IO. Nói cách khác, tất cả các thao tác ghi đều chuyển đến nhật ký cam kết, nhưng Cassandra viết văn bản hiệu quả đến mức CPU trở thành yếu tố giới hạn. Cassandra hoạt động đồng thời và sử dụng nhiều lõi CPU nhất có thể.
Apigee đề xuất sử dụng 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 thực thể nhóm gia đình C5 nếu có tại khu vực AWS và C3 làm phương án dự phòng. Trong một số trường hợp, 4xlarge là thực thể tối ưu trong cả hai gia đình với mức giá/hiệu suất tốt nhất.
Apigee cũng đề xuất sử dụng giá trị thuê mặc định cho các thực thể Cassandra. Khi bạn điều chỉnh tỷ lệ thành nhiều hơn 1 thực thể trên mỗi AZ, rất có thể tất cả các thực thể 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 giá trị thuê bao là dành riêng. Vì vậy, khi phần cứng gặp lỗi, có thể bạn sẽ mất tất cả các thực thể 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 phiên bản | C(x).4xlarge |
| Kho lưu trữ thực thể | SSD (bộ nhớ cục bộ) với RAID0 |
| Loại nhà thuê | mặc định |
| Vị trí nút | 1 nút Cassandra trên mỗi AZ |
| VPC và Subnet | 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 Các loại thực thể của Amazon.