Bởi Dumlu Timuralp và Eric Heinrichs | vào ngày 10 tháng 5 năm 2024 | trong Amazon Elastic File System (EFS) | Containers, Amazon Elastic Kubernetes Service,  Architecture, Containers, Technical How-to | Liên kết cố định | Chia sẻ 

Giới thiệu

Amazon Elastic File System (EFS) là một dịch vụ lưu trữ được quản lý có thể được sử dụng để cung cấp quyền truy cập chia sẻ vào dữ liệu cho các Pods Kubernetes chạy trên các nút tính toán ở các Availability Zones (AZ) khác nhau được quản lý bởi Amazon Elastic Kubernetes Service (EKS). Amazon EFS hỗ trợ sao chép dữ liệu tự nhiên native replication qua các khu vực AWS (AWS Regions). Tính năng này giúp thiết kế một giải pháp phục hồi thảm họa đa khu vực (multi-Region disaster recovery – DR) cho các khối lượng công việc quan trọng trên các cụm EKS của bạn.

Giao diện lưu trữ Vùng chứa (Container Storage Interface – CSI) là một tiêu chuẩn cho phép bạn hiển thị các hệ thống lưu trữ khác nhau cho các Pods của bạn. Điều này cho phép bạn chạy các khối lượng công việc trạng thái trên các cụm Kubernetes của bạn. CSI hoàn thành nhiệm vụ này bằng cách gắn Các ổ đĩa lưu trữ liên tục (Persistent Volumes – PV) vào các Pods và giữ vòng đời của Pods hoàn toàn độc lập với vòng đời của các PV. Trình điều khiển CSI của Amazon EFS (Amazon EFS CSI Driver) là một giải pháp cấu hình các PV Kubernetes dưới dạng các điểm truy cập (access points) trong hệ thống tệp EFS. Các nhà phát triển sử dụng các Yêu cầu ổ đĩa lưu trữ liên tục (Persistent Volume Claims – PVC) để gắn các ổ đĩa lưu trữ liên tục (volumes persistent) vào các Pods.

Trong bài viết này, chúng tôi thảo luận cách để đạt được tính liên tục kinh doanh trên AWS bằng cách sử dụng Amazon EFS và Amazon EKS qua các khu vực AWS (AWS Regions). Giải pháp chúng tôi đề xuất tương ứng với các chiến lược Đèn báo hiệu và Dự phòng ấm (Pilot light và Warm standby) được định nghĩa trong tài liệu về Phục hồi thảm họa của tải công việc trên AWS (Disaster Recovery of workloads on AWS).

Thách thức

Amazon EFS triển khai một điểm truy cập duy nhất cho mỗi PV trong một cụm Kubernetes. Một ID Điểm Truy cập Hệ thống Tệp Tin (File System Access Point – FSAP) phải được chỉ định cho mỗi volume.

• FSAP có thể được xác định thủ công cho mỗi PV bằng cách Cấp phát tĩnh (Static Provisioning). Tuy nhiên, điều này có thể trở nên tốn thời gian cho các nhà phát triển hoặc quản trị viên lưu trữ, vì mỗi điểm truy cập phải được tạo trong Amazon EFS trước khi tạo một PVC trong Kubernetes. 
• Cấp phát động (Dynamic Provisioning) cho phép các nhà phát triển tạo PVC mà không cần có một điểm truy cập được sắp xếp trước vì nó tạo các điểm truy cập theo yêu cầu bằng cách sử dụng ID hệ thống tệp của hệ thống EFS. 

Mặc dù cấp phát động làm cho trải nghiệm của nhà phát triển tốt hơn nhiều, nhưng có một thách thức khi sử dụng sao chép Amazon EFS. Amazon EFS replication sao chép tất cả dữ liệu trong hệ thống tệp nhưng không sao chép các FSAPs. Do đó, nó giới hạn bạn sử dụng sắp xếp tĩnh trong mỗi cụm EKS. Điều này dẫn đến việc có các sách hướng dẫn khác phục thảm họa phức tạp. Bởi vì bất cứ khi nào bạn muốn quay lại Khu vực chính (primary Region), bạn cần cấu hình lại các ID FSAP duy nhất trong các PV thủ công trong Region đó. Điều này thực sự khó duy trì và dễ gây lỗi. Do đó, chúng ta cần một giải pháp được trừu tượng hóa khỏi lớp Kubernetes nhưng vẫn có thể đảm bảo truy cập chia sẻ vào cùng một bộ dữ liệu từ bất kỳ cụm EKS nào.

Tổng quan giải pháp

Giải pháp sử dụng hai Khu vực AWS, mỗi Khu vực có một cụm EKS và một hệ thống tệp EFS. Chúng ta sử dụng trình điều khiển CSI trong mỗi cụm EKS. Chúng ta giữ Amazon Route 53 và các chính sách định tuyến của nó để định tuyến các yêu cầu của khách hàng trong kiến trúc đa khu vực này ngoài phạm vi của bài viết này để đơn giản hóa.

Hình 1: Tổng quan giải pháp

Như minh họa trong hình trước, chúng ta dùng hai AZs cho mỗi AWS Region cung cấp khả năng phục hồi cao hơn trong kiến trúc. Chúng ta sử dụng Amazon EFS replication để sao chép dữ liệu gốc từ Region 1 như nguồn (source) dến Region 2 như đích (destinaion). Khi quá trình sao chép ban đầu hoàn tất, dữ liệu trong hệ thống tệp đích chỉ có thể đọc. Mỗi EKS worker node truy cập hệ thống tệp EFS (trong cùng Region) thông qua mục tiêu gắn kết Amazon EFS cụ thể của AZ.

Chúng ta đạt được sự trừu tượng giữa các lớp Amazon EKS và Amazon EFS bằng cách dùng cấu hình một đối tượng Kubernetes StorageClass trong mỗi cụm EKS. Bạn phải chỉ định ID hệ thống tệp EFS của Region tương ứng trong đối tượng StorageClass.

Bạn có thể đang nghĩ “Vậy cái gì mới ở đây? Đây là cách bạn tích hợp Amazon EFS và Amazon EKS bằng cách sử dụng EFS CSI Driver đúng không?” Khi dùng StorageClass với Amazon EFS replication, có một tham số mới gọi là subPathPattern, được giới thiệu trong version 1.7.0 của EFS CSI Driver. Nó cho phép bạn cung cấp quyền truy cập chia sẻ cho cùng một tập dữ liệu trong hai hệ thống tệp EFS khác nhau mặc dù mỗi hệ thống có một FSAP ID riêng biệt cho tệp dữ liệu đó. Hãy cùng xem cách nó hoạt động.

Trong tệp manifest của đối tượng StorageClass, bạn cấu hình subPathPattern, như được minh họa dưới đây, với tên của PVC và biến namespace của PVC. Khuôn mẫu (pattern) này có thể bao gồm các chuỗi cố định và các biến giới hạn (fixed strings and limited variables). Mẫu sau cho phép bạn bắt đầu sử dụng chính xác các manifest Kubernetes Deployment, Pod và PVC cho cả Khu vực chính (primary) và Khu vực phục hồi thảm họa (DR Regions). Bạn không cần phải nhúng các Tham số cấu hình cụ thể của Khu vực AWS (AWS Region-specific configuration parameters), như ID hệ thống tệp EFS và/hoặc FSAP ID, vào các manifest khối lượng công việc của bạn. Tất cả đều được trừu tượng hóa bởi EFS CSI Driver, điều này thực sự tuyệt vời!

Có một tham số nữa mà bạn cần xác định cùng với subPathPattern, đó là ensureUniqueDirectory.

Bằng cách đặt tham số này thành false chúng ta đảm bảo rằng trình điều khiển Amazon EFS trỏ PV (Amazon EFS driver points the PV) trong mỗi Khu vực AWS đến cùng một thư mục trong hệ thống tệp EFS.

Tiếp theo, chúng ta triển khai khối lượng công việc của mình (thực chất là các Pod) và sử dụng các yêu cầu PVC.

Điều đáng nói là việc sử dụng GitOps cho loại kiến trúc này mang lại cho bạn khả năng quản lý trạng thái của nhiều cụm Kubernetes và hệ thống tệp EFS bằng cách sử dụng các thực hành tốt nhất của DevOps, chẳng hạn như kiểm soát phiên bản, các hiện vật bất biến và tự động hóa.

Chuyển đổi dự phòng và khôi phục 

Trong trường hợp xảy ra sự cố ở Khu vực AWS chính, trước tiên bạn phải chuyển đổi hệ thống tệp EFS ở Khu vực DR (đích) từ chế độ chỉ đọc sang chế độ có thể ghi. Bạn đạt được điều này bằng cách đơn giản là xóa cấu hình sao chép của hệ thống tệp EFS.

Chúng tôi gần đây đã giới thiệu khả năng dự phòng (failback capability) cho tính năng sao chép Amazon EFS. Khi bạn quyết định khôi phục về Khu vực chính, trước tiên bạn sao chép dữ liệu gần đây ở Khu vực phục hồi thảm họa (DR Region) trở lại hệ thống tệp tin EFS của Khu vực chính. Khi quá trình sao chép hoàn tất, bạn có thể xóa cấu hình bản sao trên hệ thống tệp tin EFS ở Khu vực chính, về cơ bản chuyển đổi nó từ chế độ chỉ đọc (read-only) sang chế độ có thể ghi (writeable). Cuối cùng, bạn cấu hình lại sao chép để biến Khu vực chính thành hệ thống tệp nguồn mới của sao chép Amazon EFS.

Tham khảo phần Chuyển đổi hệ thống tệp và khôi phục trong hướng dẫn người dùng Amazon EFS để biết thêm thông tin.

Code mẫu

Chúng tôi đã tạo một kho lưu trữ GitHub, nơi bạn có thể triển khai giải pháp trong bài viết này. Chúng tôi hướng dẫn bạn qua các bước triển khai và hướng dẫn bạn cách thực hiện các hoạt động chuyển đổi dự phòng và khôi phục dự phòng. Mẫu mã này chỉ nhằm mục đích trình diễn. Nó không nên được sử dụng trong môi trường sản xuất. Hãy tham khảo Hướng dẫn Thực hành Tốt nhất của Amazon EKS và Thực hành Tốt nhất về Mã hóa của Amazon EFS để tìm hiểu cách chạy tải công việc production bằng Amazon EKS và Amazon EFS.

Những cân nhắc

Amazon EFS replication duy trì một RPO (Recovery Point Objective – Mục tiêu Điểm Khôi phục) là 15 phút cho hầu hết các hệ thống tệp. Bạn cần tính đến điều này khi thiết kế ứng dụng của mình để xử lý bất kỳ loại giao dịch hoặc khôi phục trạng thái nào. Để biết thêm thông tin về RTO (Recovery Time Objective – Mục tiêu Thời gian Khôi phục) và RPO, hãy đọc bài viết trong Bài đăng lưu trữ AWS này và phần Sao chép hệ thống tập tin trong Hướng dẫn Sử dụng Amazon EFS.

Khi bạn triển khai một khối lượng công việc sử dụng một PVC (Persistent Volume Claim – Yêu cầu Khối lượng Lưu trữ) mới trong Khu vực chính, bạn cần đợi quá trình đồng bộ ban đầu của Amazon EFS đồng bộ hóa ban đầu hoàn tất cho tập dữ liệu đó trước khi triển khai cùng khối lượng công việc ở Khu vực phụ. 

Xóa cấu hình bản sao mất vài phút, hãy ghi nhớ điều này khi lập kế hoạch cho các hoạt động của bạn và mục tiêu RTO.

Mỗi PVC tiêu thụ một điểm truy cập Amazon EFS. Hãy kiểm tra hạn mức và giới hạn EFS trước khi đưa ra các quyết định thiết kế.

Kết luận

Trong bài viết này, chúng tôi đã chỉ cho bạn cách sử dụng bản sao của Amazon EFS giữa các Khu vực AWS cho các khối lượng công việc có trạng thái đang chạy trên các cụm EKS, cũng như cách đạt được khôi phục thảm họa trong loại kiến trúc đó. Amazon EFS CSI Driver cung cấp một giải pháp đơn giản để sao chép các khối lượng lưu trữ vĩnh viễn cho Kubernetes giữa các Khu vực AWS, cho phép các khối lượng công việc có trạng thái có thể chuyển đổi dự phòng và khôi phục dự phòng.