Bạn đang sử dụng EBS và muốn cắt giảm chi phí, loại bỏ những lãng phí? Bài viết này là dành cho bạn!

Sử dụng Amazon Elastic Block Store (EBS) để lưu trữ dữ liệu là một phần không thể thiếu khi sử dụng Amazon Elastic Compute Cloud (EC2). Mặc dù khối lượng EBS dễ thiết lập, nhưng nhiều tổ chức không quản lý chúng theo cách tối ưu nhất để có được hiệu suất tốt nhất. Điều này dẫn đến sự gia tăng lãng phí trên mây.

Trong bài viết này, chúng tôi đưa ra một số trường hợp phổ biến nhất mà bạn nên tránh.

Dư thừa dung lượng EBS

Không có gì đáng ngạc nhiên, trường hợp phổ biến nhất là cung cấp quá mức. Dư thừa xảy ra khi EBS có dung lượng lớn, hiệu suất cao được gắn vào các EC2 instance chứa ít hoặc không có dữ liệu, hoặc vẫn hoạt động tốt mà không cần đến cấu hình hiện tại. Thông thường, điều này xảy ra khi doanh nghiệp chưa có kế hoạch cụ thể về các yêu cầu về dung lượng và hiệu suất.

Một ví dụ khác là khi EBS hiệu suất cao được gắn với các EC2 băng thông mạng thấp. Ổ đĩa EBS được truy cập qua mạng. Do đó, hiệu suất của ổ đĩa EBS phụ thuộc nhiều vào băng thông mạng và thông lượng của EC2 mà nó được gắn vào. Việc gắn một EBS có hiệu suất cao vào một EC2 thông lượng mạng thấp sẽ dẫn đến việc sử dụng dung lượng thấp. Ngoài ra, việc sử dụng EBS hiệu suất cao với các nút EC2 không được tối ưu hóa EBS sẽ dẫn đến độ trễ lớn hơn.

Những lỗi EBS phổ biến này trông có vẻ nhỏ, nhưng đối với nhiều người nó là cả một vấn đề. 

Dư thừa làm gia tăng chi phí không cần thiết, nhưng nó có thể được chẩn đoán bằng cách kiểm tra số liệu EBS.

Giữ các EBS và snapshot không sử dụng

Đây là một tình huống khác trong đó các EBS được thiết lập để có thể sử dụng trong tương lai hoặc tách rời khỏi các phiên bản EC2 hiện có, nhưng lại không bao giờ được sử dụng. Dù không hoạt động nó vẫn bị tính phí trong tài khoản của khách hàng, gây tốn kém tiền bạc.

Bạn có thể kiểm tra AWS EC2 console để tìm các ổ đĩa chưa được sử dụng và xóa chúng nếu chúng không thực sự cần thiết.

Sử dụng một ổ đĩa duy nhất để lưu trữ mọi thứ

Trường hợp này xảy ra khi không tính toán đến workload mà chỉ cấu hình các EC2 đi kèm với EBS.

Khi đó, hệ điều hành, ứng dụng, dữ liệu, logs đều chia sẻ chung dung lượng. Có nhiều ý kiến cho rằng việc sử dụng một đĩa duy nhất cho mọi thứ là do quan niệm ngày xưa khi ổ cứng được gắn trực tiếp vào máy chủ vật lý. Ngày nay, không gian lưu trữ trên đám mây có thể kết nối tới nhiều máy trên nhiều vùng khác nhau. Tuy nhiên, điều này liên quan nhiều đến công suất hơn là hiệu suất.

Đối với hệ điều hành, nó vẫn coi ổ đĩa đơn là một vùng lưu trữ có giới hạn hữu hạn. Nên khi hết dung lượng đó thì các ứng dụng trong máy vẫn bị ảnh hưởng.

Hãy cùng xem xét một EC2 đơn lẻ đang chạy một cơ sở dữ liệu quan trọng. Máy này sẽ có bộ nhớ cache của hệ điều hành, log file và tệp tạm thời – tất cả đều được tạo trong cùng một ổ lưu trữ tệp dữ liệu. Nếu tất cả các log file đều bị tăng kích thước (có thể do lỗi ứng dụng gửi thông báo theo dõi lớn đến các tệp), bộ nhớ có thể hết nhanh hơn nhiều so với dự đoán. Nó sẽ ảnh hưởng đến tính khả dụng của cơ sở dữ liệu.

Do đó, điều quan trọng là phải hiểu rõ cấu trúc EC2 cần trong giai đoạn lên kế hoạch kiến ​​trúc hạ tầng. Tình huống duy nhất sử dụng một ổ đĩa duy nhất hoặc ổ đĩa gốc để lưu trữ mọi thứ là khi máy đang lưu trữ một ứng dụng nhỏ hoặc ít quan trọng. Nó cũng giúp bạn dễ dàng snapshot.

Đừng bao giờ lưu trữ mọi thứ ở cùng một nơi

Sử dụng hệ thống tệp dưới mức tối ưu

File system quy định cách dữ liệu trong một ổ lưu trữ được lưu trữ, truy cập, tìm kiếm, ghi hoặc theo dõi. Có các file system khác nhau cho các hệ điều hành khác nhau như Linux, UNIX hoặc Windows.

Một file system thường có hoạt động tốt hơn hệ thống khác trên cùng một loại khối lượng công việc. Thường thì một EC2 đang chạy nhiều loại khối lượng công việc, mỗi loại truy cập một phân khu khác nhau cho dữ liệu của nó. Vậy, có nên sử dụng các hệ thống tệp khác nhau cho các EBS khác nhau trên EC2. Thực tế thường là không, cùng một hệ thống tệp được sử dụng trong tất cả các ổ đĩa – dẫn đến hiệu suất dưới mức tối ưu.

Do đó, việc chọn hệ thống tệp phù hợp cho các khối lượng công việc khác nhau sẽ là một phần trong giai đoạn lên kế hoạch kiến ​​trúc hạ tầng.

Không đồng bộ hóa snapshot

Snapshot được sử dụng để sao lưu các EBS. Thông thường, quy trình snapshot được tự động hóa: một tác vụ lên lịch chạy chương trình hoặc tập lệnh sao lưu dựa trên mọi ổ đĩa EBS gắn trên mọi phiên bản EC2. Sau khi hoàn thành, công việc thường gửi một thông báo đến nhóm vận hành. Nó cũng gửi một cảnh báo nếu nó không thể snapshot. Tuy nhiên, các bản sao lưu cần được thiết kế cẩn thận để đảm bảo dữ liệu có thể được phục hồi trong trường hợp bị lỗi hoặc mất dữ liệu vì sự cố.

Nhiều quy trình snapshot cần đồng bộ hóa chính xác. Ví dụ: hãy xem xét một ứng dụng chạy trên hai máy chủ EC2. Một máy EC2 lưu trữ các tệp cơ sở dữ liệu của ứng dụng, máy còn lại lưu trữ các tệp nhị phân, nhật ký và cấu hình của nó. Suốt cả ngày, cả tệp cấu hình và cơ sở dữ liệu đều được cập nhật và cả hai đều cần được đồng bộ hóa.

Theo mặc định, mỗi ổ đĩa EBS sẽ có một bản sao lưu được thực hiện riêng biệt; không có gì đảm bảo rằng snapshot khối lượng EBS riêng biệt sẽ bắt đầu hoặc kết thúc cùng một lúc, ngay cả khi chúng được gắn trên cùng một EC2.

Bây giờ hãy tưởng tượng điều này. Quy trình snapshot tự động sao lưu khối lượng cơ sở dữ liệu khi bắt đầu công việc và sau một vài giờ, snapshot tệp cấu hình. Giữa hai Snapshot, có khoảng cách vài giờ – khiến các bản sao lưu không đồng bộ. Sau khi được lưu trữ, các tập này có thể không đồng bộ và ứng dụng không thể hoạt động được.

Đó là lý do tại sao, nếu ứng dụng của bạn có nhiều ổ đĩa cần được khôi phục trong trường hợp bị lỗi và chúng cần được đồng bộ hóa, hãy đảm bảo sử dụng snapshot phù hợp trên nhiều ổ đĩa. 

Đảm bảo các bản sao lưu của bạn đều được đồng bộ hóa

Cũng cần lưu ý rằng theo mặc định, sau khi tạo EBS từ snapshot, dữ liệu không có sẵn bên trong tập. Dữ liệu chỉ được tải khi được truy cập.

Đối với một số workload nhất định như cơ sở dữ liệu, có thể dẫn đến việc khôi phục hoạt động chậm hơn thời gian mong muốn cho đến khi tất cả dữ liệu đã được truy cập ít nhất một lần. Fast Snapshot Restore giải quyết được vấn đề này. Mặc dù nó đi kèm với chi phí bổ sung, nhưng cũng đáng xem xét cho các công việc nhạy cảm với độ trễ.

Không mã hóa

Chúng ta đã cùng xem xét 5 sai lầm thường gặp khi cấu hình EBS, chúng tôi xin được chia sẻ thêm một trường hợp khác cho bạn.

Mã hóa đĩa đảm bảo rằng dữ liệu được lưu trữ trong một ổ đĩa được mã hóa bằng thuật toán khóa đối xứng. Trong trường hợp tài khoản AWS bị tấn công, những kẻ xấu có thể đặt snapshot EBS của bạn ở chế độ công khai, sao chép snapshot vào tài khoản của họ, sau đó thay đổi quyền truy cập của Snapshot về chế độ riêng tư. Tiếp theo, họ có thể đính kèm snapshot đã sao chép vào EC2 của riêng họ và truy cập dữ liệu.

Đáng sợ phải không? Nhưng bạn có thể phòng tránh nếu bạn mã hóa tệp của mình. Nếu không có khóa mã hóa tập EBS, không thể snapshot.

Nhiều tổ chức mã hóa khối lượng dữ liệu quan trọng của họ như một phần của việc tuân thủ quy định. Nhiều người chọn không, sẽ có nguy cơ bị vi phạm dữ liệu. Tốt nhất, dữ liệu nên được mã hóa cả khi ở trạng thái nghỉ và truyền nhận.

Mã hóa EBS bằng khóa AWS KMS là một quá trình đơn giản. Bạn có thể tham khảo tài liệu AWS này.

Kết luận

Amazon EBS là một dịch vụ hữu ích, linh hoạt và dễ sử dụng. Hy vọng rằng, bài viết này đã cung cấp cho bạn một số ý tưởng về những tình huống bạn có thể tránh và các cách để giải quyết chúng. Thiết kế và sử dụng EBS một cách tối ưu có thể giúp giảm thiểu chi phí, cải thiện bảo mật dữ liệu, khôi phục dữ liệu và hiệu suất.

Bạn cũng có thể liên hệ với chúng tôi –  những chuyên gia tối ưu hóa trên mây để tìm hiểu thêm về các cách quản lý EBS và tiết kiệm tối đa.