EC2 Instance Storage - Cơ chế lưu trữ trên AWS (Phần 2)

Bài viết này là phần tiếp theo của bài viết về EC2 Instance Storage (Phần 1). Trong bài viết này, chúng ta sẽ tìm hiểu về các volumes Types, Multi Attach và mã hóa và EFS– Elastic File System.

EBS Volume Types

EBS Volume được chia thành 6 loại khác nhau dựa trên nhiều yếu tố như Size, Throughput và IOPS (I/O Ops Per Sec). Các loại EBS Volume được chia thành 4 nhóm liệt kê trong bảng sau:

• gp2 / gp3 (SSD): Các ổ đĩa SSD có thể sử dụng cho nhiều mục đích khác nhau, được cân bằng giữa chi phí và hiệu suất.
  
• io1 / io2 (SSD): Các ổ đĩa SSD hiệu suất cao, được thiết kế cho các ứng dụng đặc biệt, yêu cầu độ trễ thấp cũng như throughput cao.
  
• st1 (HDD): Ổ đĩa HDD giá rẻ, được thiết kế cho các ứng dụng có lượng truy cập thường xuyên và yêu cầu throughput tương đối lớn.
  
• sc1 (HDD): Là loại ổ đĩa HDD có chi phí rẻ nhất, được thiết kế cho các ứng dụng không cần phải đáp ứng các truy cập một cách thường xuyên.
  

  Cần lưu ý rằng chỉ các ổ đĩa SSD (ở các nhóm gp2/gp3 và io1/io2) là có thể được sử dụng như boot volumes.
  

Use Cases

General Purpose SSD

• Chi phí lưu trữ dữ liệu tương đối vừa phải, độ trễ thấp.
  
• Có thể sử dụng như System Boot, Máy ảo, sủ dụng được cho cả các môi trường Development hay Test.
  
• Dải giới hạn dung lượng lưu trữ khá rộng, từ 1GiB tới 16TiB.
  
• gp3: Bản cơ bản có tốc độ đọc ghi 3,000 IOPS và throughput lên tới 125 MiB/s tuy nhiên có thể nâng lên lần lượt 16000 IOPS và 1000MiB/s một cách độc lập.
  
• gp2: Kích thước ổ đĩa và IOPS sẽ được liên kết với nhau, các ổ đĩa kích thước nhỏ thường chỉ đạt tới 3000IOPS, các ổ đĩa lớn hơn tối đa có thể lên tới 16000IOPS (Thông thường sẽ là 3 IOPS/GB, điều này có nghĩa là ổ đĩa với kích thước khoảng 5334 GB sẽ đạt được mức tối đa - 16000IOPS).
  

Provisioned IOPS (PIOPS) SSD

• Thường được sử dụng cho các ứng dụng đặc biệt cần yêu cầu duy trì hiệu suất đọc ghi cao hoặc các ứng dụng cần nhiều hơn 16000 IOPS. Loại ổ đĩa này đặc biệt phù hợp cho các ứng dụng cơ sở dữ liệu (database) yêu cầu cao về hiệu suất lưu trữ cũng như tính toàn vẹn dữ liệu.
  
• io1/io2 (4 GiB - 16 TiB): Đạt tới 64000IOPS với phiên bản Nitro EC2 instances và 32,000IOPS với các phiên bản khác. Các ổ đĩa này cũng có thể tăng PIOPS một cách độc lập với dung lượng lưu trữ. Các ổ đĩa io2 sẽ có độ bền vững cũng như tỉ lệ IOPS trên dung lượng lưu trữ cao hơn khi so với các ổ đĩa io1 cùng tầm giá.
  
• io2 Block Express (4 GiB – 64 TiB): Đáp ứng được các ứng dụng yêu cầu độ trễ cực thấp, có thể đạt mức PIOPS tối đa lên tới 256000 với tỷ lệ IOPS/GiB khoảng 1000:1.
  
• Hỗ trợ EBS Multi-attach.
  

Hard Disk Drives (HDD)

• Không thể được sử dụng như các boot volumes.
  
• Dung lượng lưu trữ trong khoảng 125 GiB tới 16 TiB.
  
• st1: Phiên bản được tối ưu về throughput, thường được dùng cho các ứng dụng như Big Data, Data Warehouses, Log Processing. Phiên bản này có thể đạt throughput tối đa 500 MiB/s và IOPS là 500.
  
• sc1: ColdHDD - Được sử dụng cho các ứng dụng lưu trữ không cần truy cập thường xuyên, tối ưu hóa cho mục đích ưu tieemn chi phí lưu trữ với các giá trị throughput và IOPS tối đa lần lượt rơi vào khoảng 250 MiB/s – 250IOPS.
  

Volume Types Summary

EBS Multi-Attach – io1/io2 family

ESB Multi-Attach cho phép gắn cùng một ESB volumes vào nhiều EC2 Instance khác nhau trong cùng một Availability Zone. Mỗi Instance trong số đó đều có đầy đủ các quyền read & write đối với ESB volumes này.
Use cases:

• Tăng cường tính khả dụng trong các cụm ứng dụng Linux (VD: Teradata) cũng như các ứng dụng cần phải quản lý nhiều hoạt động write đồng thời.
  
• EBS Multi-attach hỗ trợ lên tới 16 EC2 Instance trong cùng một thời điểm, tuy nhiên ta cần phải sử dụng hệ thống tệp nhận biết cụm (không phải các loại như XFS, EX4, v.v.) để có thể xử lý nhiều instances truy cập tới một ổ đĩa cùng một lúc.
  

  Hệ thống tệp nhận biết cụm (Cluster-aware file systems) được thiết kế để ngăn chặn tình trạng dữ liệu bị hư hỏng và đảm bảo tính nhất quán giữa các phiên bản. Một số ví dụ về hệ thống tệp nhận biết cụm là GFS2, OCFS2 và Lustre.
  

Mã hóa EBS volumes - EBS Encryption

EBS Encryption cung cấp một cơ chế mã hóa đơn giản nhằm bảo vệ các tài nguyên của người dùng trong EBS volumes. Khi thực hiện mã hóa EBS volumes, các thông tin sau sẽ đều được mã hóa một cách dễ dàng:

• Dữ liệu trong toàn bộ volumes sẽ được mã hóa.
  
• Toàn bộ dữ liệu được di chuyển giữa các instance cũng sẽ được mã hóa.
  
• Tất cả các bản snapshot và các volumes mới được tạo ra từ snapshot cũng sẽ được mã hóa.
  Toàn bộ quy trình mã hóa và giải mã của các EBS volumes được thực thi hoàn toàn bởi AWS, điều này có nghĩa là các thao tác này hoàn toàn "trong suốt" với người dùng, người dùng không nhất thiết phải quan tâm đến cách nó hoạt động hay các vấn đề khác như lưu trữ và bảo hệ key mã hóa. Các key này (sử dụng thuật toán mã hóa AES-256) sẽ được AWS quản lý thông qua hệ thống KMS (Key Management System) riêng biệt.
  Việc mã hóa này cũng không ảnh hưởng quá nhiều đến độ trễ của ứng dụng.
  Đối với các bản snapshot, phiên bản copy của một bản snapshot chưa được mã hóa vẫn có thể được mã hóa thông qua cấu hình khi copy. Ngoài ra, mặc định bản snapshot của một volumes đã được mã hóa sẽ cũng được mã hóa.
  

Amazon EFS – Elastic File System

Amazon EFS là dịch vụ quản lý NFS (network file system - một giao thức chia sẻ file qua mạng) và chúng có thể được gắn trên nhiều EC2 Instance cũng như trên nhiều Availability Zone khác nhau.
Amazon EFS cung cấp tính sẵn sàng cũng như khả năng mở rộng tương đối tốt, tuy nhiên đi kèm với đó là chi phí tương đối cao (khoảng 3 lần gp2) và người dùng sẽ phải trả tiền theo mức độ sử dụng.

EFS thường được sử dụng trong các trường hợp sau: content management, web serving, data sharing, Wordpress...
Ngoài ra càn lưu ý các đặc điểm sau khi sử dụng EFS:

• EFS sẽ sử dụng NFSv4.1 protocol.
  
• Chúng ta có thể quản lý EFS thông qua các Security Groups.
  
• Chỉ tương thích với các AMI chạy Linux
  
• Có thể được mã hóa toàn bộ sử dụng KMS.
  
• Do sử dụng POSIX file system (~Linux) nên chúng ta cũng có sẵn các API (Các hệ thống command, phần mềm tương tự như trên các hệ điều hành dựa trên linux thông thường) để quản lý cũng như truy cập dữ liệu trên EFS.
  

  EFS sẽ tự động scale tùy theo mức độ sử dụng của người dùng, tuy nhiên sẽ không có bất cứ plan trả trước hay discount nào cho người dùng. Toàn bộ sẽ được trả theo mức độ sử dụng!
  

EFS cung cấp khả năng mở rộng (scale) tương đối tốt, có thể lên tới > 1000 NFS clients cùng lúc cũng như đạt tới thông lượng (throughput) 10GB+/s. Điều này chứng minh rằng EFS thực sự là một hệ thống được thiết kế cho phép tự động mở rộng lên tới hàng Petabyte network file system.
EFS cũng cung cấp các chế độ tối ưu hóa riêng cho các yếu tố liên quan đến hiệu suất như:

• Performance Mode (Cấu hình lúc tạo EFS):
  
  • General Purpose (mặc định) – Dùng cho các trường hợp yêu cầu độ trễ thấp (web server, CMS, etc…).
    
  • Max I/O - Dùng cho các trường hợp không yêu cầu sự tối ưu về mặt độ trễ và throughput, tuy nhiên cần được cung cấp khả năng xử lý nhiều luồng song song tốt hơn (big data, media processing).
    
• Throughput Mode:
  
  • Bursting – Được cấp 50MiB/s throughput với mỗi 1TB + tuy nhiên có thể tăng lên tới 100MiB/s.
    
  • Provisioned – Cho phép cấu hình throughput mà không cần quan tâm đến kích thước của EFS, VD: 1 GiB/s/1 TB lưu trữ.
    
  • Elastic –Tự động scale throughput tùy theo workload của hệ thống:
    - Lên tới 3GiB/s Đọc và 1GiB/s cho quá trình Ghi.
    - Thường được sử dụng cho các hệ thống không thể đoán trước được mức độ sử dụng (workload).
    Trong trường hợp cần tối ưu về khả năng lưu trữ, AWS cũng cung cấp các Storage Class với các đặc điểm như sau:
    

• Storage Tiers (Tính năng quản lý vòng đời - Di chuyển file sau N ngày):
  
  • Bản tiêu chuẩn: Thường được sử dụng cho các file được truy cập thường xuyên.
    
  • Infrequent access (EFS-IA): Sử dụng cho các file không cần truy cập thường xuyên, tính năng này sẽ yêu cầu chi phí khi truy xuất tệp, tuy nhiên chi phí lưu trữ sẽ được giảm đi đáng kể. Để sử dụng Enable EFS-IA, cần cấu hình Lifecycle Policy
    
• Availability and durability:
  • Bản tiêu chuẩn: Có thể sử dụng tại nhiều Availability Zone khác nhau, vô cùng thích hợp cho các phiên bản Production.
    
  • Bản giới hạn theo AZ: Phù hợp sử dụng cho các phiên bản Test, Development hay các hệ thống cần được backup một cách tự động. Nó cũng tương thích với IA (EFS One Zone -IA)
    

    Nếu sử dụng một cách hợp lý các Storage Class, chúng ta có thể tiết kiệm tới 90% chi phí lưu trữ.

So sánh EBS với EFS: Elastic Block Storage

• EBS volumes:
  
  • Chỉ sử dụng được duy nhất 1 Instance (ngoại trừ multi-attach io1/io2)
    
  • Bị giới hạn ở một Availability Zone (AZ) nhất định
    
  • gp2: IOPS sẽ chỉ tăng nếu kích thước disk tăng
    
  • io1: Có thể tăng IOPS một cách độc lập
    

• Để migrate một EBS Volume giữa các AZ cần thực hiện các thao tác sau:
  
  • Tạo một bản snapshot.
    
  • Restore bản snapshot này tới AZ khác cần chuyển.
    
  • Sử dụng AWS Storage Gateway để migrate dữ liệu.
    
  • EBS sẽ thực hiện quá trình backup thông qua kênh IO, vậy nên không nên sử dụng tính năng này khi ứng dụng đang chạy với workload lớn.
    
• Mặc định, Root EBS Volume gắn với Instance sẽ bị xóa khi Instance bị Terminate, tuy nhiên có thể thay đổi bằng cách thay đổi giá trị “Delete on Termination” sang False trong phần config của Instance.
  

So sánh EBS với EFS: Elastic File System

• Có thể được mount với hàng trăm Instance trên nhiều AZ khác nhau.
  
• Chỉ sử dụng được trên Linux Instances (POSIX).
  
• EFS tốn chi phí hơn nhiều so với EBS (khoảng từ 3-5 lần) tuy nhiên có thể tiết kiệm phần nào chi phí dựa vào EFS-IA.
  

Phần trên chỉ đưa ra các đặc điểm của EFS và EBS, tùy vào nhu cầu của dự án cũng như các yếu tố khác như Budget, Security, Availability, Performance, Cost, etc… mà chúng ta sẽ phải đưa lựa chọn phù hợp nhất cho dự án của mình.