Phản hồi cho bài viết trước của chúng tôi,
Để hồi hương dữ liệu từ AWS S3, bạn sẽ tuân theo các nguyên tắc chung sau:
Đánh giá yêu cầu dữ liệu: Xác định các nhóm và đối tượng cụ thể cần được hồi hương khỏi AWS S3. Đảm bảo bạn hiểu nhu cầu kinh doanh và yêu cầu tuân thủ theo từng nhóm.
Xác định điểm đến hồi hương: Bạn đã quyết định hồi hương về MinIO, giờ đây bạn có thể chọn chạy MinIO trong trung tâm dữ liệu tại chỗ hoặc tại một nhà cung cấp đám mây hoặc cơ sở colocation khác. Bằng cách sử dụng các yêu cầu từ số 1, bạn sẽ chọn phần cứng hoặc phiên bản cho nhu cầu lưu trữ, truyền tải và tính khả dụng được dự báo.
Truyền dữ liệu: Lập kế hoạch và thực hiện truyền dữ liệu từ AWS S3 sang MinIO. Chỉ cần sử dụng Bản sao hàng loạt hoặc bản sao tích hợp của MinIO bằng Ứng dụng khách MinIO (xem
Quyền truy cập và quyền dữ liệu: Đảm bảo rằng các quyền và quyền kiểm soát truy cập phù hợp được thiết lập cho dữ liệu được hồi hương trên cơ sở từng nhóm. Điều này bao gồm các chính sách IAM và bộ chứa để quản lý quyền truy cập, xác thực và ủy quyền của người dùng nhằm đảm bảo tính bảo mật của dữ liệu.
Khóa đối tượng: Điều quan trọng là phải duy trì các chính sách lưu giữ khóa đối tượng và lưu giữ pháp lý sau khi di chuyển. Kho đối tượng mục tiêu phải diễn giải các quy tắc giống như Amazon S3. Nếu bạn không chắc chắn, hãy yêu cầu
Quản lý vòng đời dữ liệu: Xác định và triển khai chiến lược quản lý vòng đời dữ liệu cho dữ liệu được hồi hương. Điều này bao gồm việc xác định các chính sách lưu giữ, quy trình sao lưu và phục hồi cũng như các biện pháp lưu trữ dữ liệu trên cơ sở từng nhóm.
Xác thực dữ liệu: Xác thực dữ liệu được truyền để đảm bảo tính toàn vẹn và đầy đủ của nó. Thực hiện các kiểm tra và thử nghiệm cần thiết để đảm bảo rằng dữ liệu đã được truyền thành công mà không bị hỏng hoặc mất mát. Sau khi truyền, tên đối tượng, ETag và siêu dữ liệu, tổng kiểm tra và số lượng đối tượng đều khớp giữa nguồn và đích.
Cập nhật ứng dụng và quy trình làm việc: Tin vui là nếu bạn tuân theo các nguyên tắc gốc trên đám mây để xây dựng ứng dụng của mình thì tất cả những gì bạn phải làm là cấu hình lại chúng cho điểm cuối MinIO mới. Tuy nhiên, nếu ứng dụng và quy trình làm việc của bạn được thiết kế để hoạt động với hệ sinh thái AWS, hãy thực hiện các bản cập nhật cần thiết để phù hợp với dữ liệu hồi hương. Điều này có thể liên quan đến việc cập nhật cấu hình, định cấu hình lại các phần tích hợp hoặc trong một số trường hợp sửa đổi mã.
Giám sát và tối ưu hóa: Liên tục giám sát và tối ưu hóa môi trường dữ liệu hồi hương để đảm bảo hiệu suất tối ưu, hiệu quả chi phí và tuân thủ các phương pháp hay nhất về quản lý dữ liệu.
Có nhiều yếu tố cần xem xét khi lập ngân sách và lập kế hoạch cho việc hồi hương đám mây. May mắn thay, các kỹ sư của chúng tôi đã thực hiện việc này với nhiều khách hàng và chúng tôi đã phát triển một kế hoạch chi tiết cho bạn. Chúng tôi có những khách hàng đã chuyển mọi thứ từ một số khối lượng công việc đến hàng trăm petabyte về nước.
Nhiệm vụ lập kế hoạch lớn nhất là cân nhắc các lựa chọn xung quanh mạng, băng thông thuê, phần cứng máy chủ, chi phí lưu trữ cho dữ liệu không được chọn để hồi hương và chi phí nhân lực để quản lý và duy trì cơ sở hạ tầng đám mây của riêng bạn. Ước tính những chi phí này và lập kế hoạch cho chúng. Chi phí hồi hương đám mây sẽ bao gồm phí xuất dữ liệu để di chuyển dữ liệu từ đám mây trở lại trung tâm dữ liệu. Các khoản phí này được cố ý đủ cao để buộc phải khóa đám mây. Hãy lưu ý đến các khoản phí đầu ra cao này - chúng chứng minh lập luận kinh tế để rời khỏi đám mây công cộng vì khi lượng dữ liệu bạn quản lý tăng lên thì phí đầu ra cũng tăng. Vì vậy, nếu bạn định hồi hương, bạn nên hành động sớm hơn là muộn hơn.
Chúng tôi sẽ tập trung vào dữ liệu và siêu dữ liệu cần phải di chuyển – đây là 80% công việc cần thiết để hồi hương. Siêu dữ liệu bao gồm các chính sách và thuộc tính nhóm (quản lý quyền truy cập dựa trên quyền truy cập/khóa bí mật, quản lý vòng đời, mã hóa, quyền truy cập công khai ẩn danh, khóa đối tượng và lập phiên bản).
Bây giờ hãy tập trung vào dữ liệu (đối tượng). Đối với mỗi không gian tên bạn muốn di chuyển, hãy kiểm kê các nhóm và đối tượng bạn muốn di chuyển. Có khả năng nhóm DevOps của bạn đã biết nhóm nào chứa dữ liệu quan trọng hiện tại. Bạn cũng có thể dùng
Không gian tên | Tổng số nhóm | Tổng số đối tượng | Tổng kích thước đối tượng (GB) | Tổng tải lên hàng ngày (TB) | Tổng số lượt tải xuống hàng ngày (TB) |
---|---|---|---|---|---|
ns-001 | 166 | 47.751.258 | 980.014,48 | 50.04 | 14h80 |
ns-002 | 44 | 24.320.810 | 615.033,35 | 23,84 | 675,81 |
ns-002 | 648 | 88.207.041 | 601.298,91 | 328,25 | 620,93 |
ns-001 | 240 | 68.394.231 | 128.042,16 | 62,48 | 12:45 |
Bước tiếp theo là liệt kê từng nhóm theo không gian tên và các thuộc tính của nó cho mỗi nhóm mà bạn sắp di chuyển. Lưu ý (các) ứng dụng lưu trữ và đọc dữ liệu trong nhóm đó. Dựa trên cách sử dụng, hãy phân loại từng nhóm thành dữ liệu cấp nóng, ấm hoặc lạnh.
Trong phiên bản rút gọn, nó sẽ trông giống như
Tên nhóm | Của cải | (Các) ứng dụng | Cấp nóng/Ấm/Lạnh |
---|---|---|---|
MỘT | Sao chép và dán JSON vào đây | Tia lửa, tảng băng trôi, Dremio | Nóng |
B | Sao chép và dán JSON vào đây | đàn hồi | Ấm |
C | Sao chép và dán JSON vào đây | Đàn hồi (ảnh chụp nhanh) | Lạnh lẽo |
Tại thời điểm này, bạn phải đưa ra một số quyết định về quản lý vòng đời dữ liệu và hãy hết sức chú ý vì đây là một cách tuyệt vời để tiết kiệm tiền phí AWS. Phân loại các đồ vật trong mỗi nhóm thành nóng, ấm hoặc lạnh dựa trên tần suất truy cập chúng. Một nơi tuyệt vời để tiết kiệm tiền là di chuyển trực tiếp các nhóm cấp nguội sang S3 Glacier – không có lý do gì phải chịu phí đầu ra khi tải xuống chỉ để tải lên lại.
Tùy thuộc vào lượng dữ liệu bạn đang hồi hương, bạn có một số tùy chọn để chọn cách di chuyển. Chúng tôi khuyên bạn nên tải và làm việc với dữ liệu mới trên cụm MinIO mới đồng thời sao chép dữ liệu nóng và ấm sang cụm mới theo thời gian. Tất nhiên, lượng thời gian và băng thông cần thiết để sao chép các đối tượng sẽ phụ thuộc vào số lượng và kích thước của các đối tượng bạn đang sao chép.
Đây là nơi sẽ rất hữu ích khi tính toán tổng dữ liệu mà bạn sẽ chuyển về từ AWS S3. Nhìn vào kho của bạn và tính tổng kích thước của tất cả các thùng được phân loại là nóng và ấm.
Tổng dữ liệu cấp nóng và ấm = 1.534.096,7 GB |
---|
Băng thông khả dụng = 10 Gbps |
Thời gian truyền tối thiểu cần thiết (tổng kích thước đối tượng / băng thông khả dụng) = 14,2 ngày |
Tính phí đầu ra dữ liệu dựa trên tổng số trên. Tôi đang sử dụng
Tổng dữ liệu được phân cấp cho S3 Glacier = 767.048,337 GB |
---|
Phí chuyển S3 sang S3 Glacier ($0,05/1000 đối tượng) = $3.773,11 |
Phí lưu trữ hàng tháng của S3 Glacier Deep Archive = 760 USD |
Đừng quên lập ngân sách cho việc sử dụng S3 Glacier Deep Archive trong tương lai.
Tổng dữ liệu được chuyển = 1.534.096,7 GB |
---|
10 TB đầu tiên ở mức 0,09 USD/GB = 900 USD |
40 TB tiếp theo ở mức 0,085 USD/GB = 3.400 USD |
100 TB tiếp theo ở mức 0,07 USD/GB = 70.000 USD |
Bổ sung trên 150 TB ở mức 0,05 USD/GB = 69.205 USD |
Tổng phí xuất cảnh = $143,504 |
Để đơn giản, phép tính trên không bao gồm phí cho mỗi hoạt động đối tượng ($0,40/1 triệu) cũng như chi phí NIÊM YẾT ($5/1 triệu). Đối với các dự án hồi hương rất lớn, chúng tôi cũng có thể nén các đối tượng trước khi gửi chúng qua mạng, giúp bạn tiết kiệm một phần chi phí đầu ra.
Một tùy chọn khác là sử dụng AWS Snowball để chuyển đối tượng. Mỗi thiết bị Snowball có dung lượng 80 TB, vì vậy chúng tôi biết trước rằng chúng tôi cần 20 thiết bị trong số đó cho nỗ lực hồi hương. Phí mỗi thiết bị bao gồm 10 ngày sử dụng, cộng thêm 2 ngày vận chuyển. Những ngày bổ sung có sẵn với giá $30/thiết bị.
20 Phí dịch vụ thiết bị Snowball ($300 mỗi cái) = $6.000 |
---|
Vận chuyển R/T (3-5 ngày với giá 400 USD/thiết bị) = 8.000 USD |
Dữ liệu ra S3 (0,02 USD/GB) = 30.682 USD |
Tổng phí Snowball = 38.981,93 USD |
AWS sẽ tính phí yêu cầu, lưu trữ và truyền dữ liệu tiêu chuẩn để đọc và ghi vào các dịch vụ AWS bao gồm
Bây giờ chúng tôi biết sẽ mất bao lâu để di chuyển lượng dữ liệu khổng lồ này và chi phí. Đưa ra quyết định kinh doanh về phương pháp nào đáp ứng nhu cầu của bạn dựa trên sự kết hợp giữa thời gian và phí.
Tại thời điểm này, chúng tôi cũng biết các yêu cầu về phần cứng cần thiết để chạy MinIO tại chỗ hoặc tại cơ sở colocation. Thực hiện yêu cầu trên về 1,5PB dung lượng lưu trữ, ước tính mức tăng trưởng dữ liệu và tham khảo ý kiến của chúng tôi
Bước đầu tiên là tạo lại nhóm S3 của bạn trong MinIO. Bạn sẽ phải thực hiện việc này bất kể bạn chọn cách di chuyển đối tượng như thế nào. Mặc dù cả S3 và MinIO đều lưu trữ các đối tượng bằng mã hóa phía máy chủ nhưng bạn không phải lo lắng về việc di chuyển các khóa mã hóa. Bạn có thể kết nối với KMS bạn chọn bằng cách sử dụng
Bạn có nhiều tùy chọn để sao chép các đối tượng: Sao chép hàng loạt và mc mirror
. bài viết blog trước đây của tôi,
Thông thường, khách hàng sử dụng các công cụ do chúng tôi viết kết hợp với dịch vụ và phần cứng di chuyển dữ liệu của AWS Snowball hoặc TD SYNNEX để di chuyển lượng dữ liệu lớn hơn (trên 1 PB).
MinIO gần đây đã hợp tác với Western Digital và TD SYNNEX để đưa ra giải pháp thay thế Snowball. Khách hàng có thể lên lịch nhận phần cứng Western Digital và thanh toán những gì họ cần trong thời gian thuê. Quan trọng hơn, dịch vụ này không bị ràng buộc với một đám mây cụ thể - nghĩa là doanh nghiệp có thể sử dụng dịch vụ để di chuyển dữ liệu vào, ra và xuyên qua các đám mây - tất cả đều sử dụng giao thức S3 phổ biến. Các chi tiết bổ sung về dịch vụ có thể được tìm thấy trên
Siêu dữ liệu nhóm, bao gồm các chính sách và thuộc tính nhóm, có thể được đọc bằng get-bucket
Đặc biệt chú ý tới
Đặc biệt chú ý đến Quản lý vòng đời dữ liệu, chẳng hạn như lưu giữ đối tượng, khóa đối tượng và lưu trữ/phân tầng. Chạy cấu hình get-bucket-lifecycle-configuration
trên mỗi nhóm để có được danh sách các quy tắc vòng đời JSON mà con người có thể đọc được. Bạn có thể dễ dàng tạo lại cài đặt AWS S3 bằng Bảng điều khiển MinIO hoặc Máy khách MinIO (mc). Sử dụng các lệnh như get-object-legal-hold
và get-object-lock-configuration
để xác định chính xác các đối tượng yêu cầu xử lý quản trị và bảo mật đặc biệt.
Trong khi chúng ta đang nói về chủ đề vòng đời, chúng ta hãy nói một chút về sao lưu và khắc phục thảm họa. Bạn có muốn có thêm một cụm MinIO để sao chép vào để sao lưu và khắc phục thảm họa không?
Sau khi sao chép đối tượng từ AWS S3 sang MinIO, điều quan trọng là phải xác thực tính toàn vẹn của dữ liệu. Cách dễ nhất để thực hiện việc này là sử dụng MinIO Client để chạy mc diff
với các nhóm cũ trong S3 và các nhóm mới trên MinIO. Điều này sẽ tính toán sự khác biệt giữa các nhóm và trả về danh sách chỉ những đối tượng bị thiếu hoặc khác biệt. Lệnh này lấy các đối số của nhóm nguồn và nhóm đích. Để thuận tiện cho bạn, bạn có thể muốn tạo
mc diff s3/bucket1 minio/bucket1
Tin vui là tất cả những gì bạn phải làm là trỏ các ứng dụng hiện có vào điểm cuối MinIO mới. Cấu hình có thể được viết lại theo từng ứng dụng trong một khoảng thời gian. Việc di chuyển dữ liệu trong bộ lưu trữ đối tượng ít gây gián đoạn hơn so với hệ thống tệp, chỉ cần thay đổi URL để đọc/ghi từ một cụm mới. Lưu ý rằng nếu trước đây bạn dựa vào các dịch vụ AWS để hỗ trợ ứng dụng của mình thì các dịch vụ đó sẽ không có trong trung tâm dữ liệu của bạn, vì vậy, bạn sẽ phải thay thế chúng bằng nguồn mở tương đương và viết lại một số mã. Ví dụ: Athena có thể được thay thế bằng Spark SQL, Apache Hive và Presto, Kinesis bằng Apache Kafka và AWS Glue bằng Apache Airflow.
Nếu quá trình di chuyển S3 của bạn là một phần trong nỗ lực lớn hơn nhằm di chuyển toàn bộ ứng dụng tại chỗ thì rất có thể bạn đã được sử dụng
Bây giờ bạn đã hoàn tất việc hồi hương, đã đến lúc chuyển sự chú ý của bạn sang hoạt động lưu trữ, giám sát và tối ưu hóa. Tin vui là MinIO không cần tối ưu hóa – chúng tôi đã tích hợp tính năng tối ưu hóa ngay trong phần mềm để bạn biết rằng mình đang đạt được hiệu suất tốt nhất cho phần cứng của mình. Bạn sẽ muốn bắt đầu theo dõi cụm MinIO mới của mình để liên tục đánh giá việc sử dụng tài nguyên và hiệu suất. MinIO lộ diện
Với
Không có gì bí mật khi thời kỳ viết séc trống cho các nhà cung cấp dịch vụ đám mây đã không còn nữa. Nhiều doanh nghiệp hiện đang đánh giá chi tiêu trên nền tảng đám mây của họ để tìm ra những khoản tiết kiệm tiềm năng. Giờ đây, bạn đã có mọi thứ cần thiết để bắt đầu quá trình di chuyển từ AWS S3 sang MinIO, bao gồm các bước kỹ thuật cụ thể và khung tài chính.
Nếu bạn hào hứng với khả năng tiết kiệm chi phí hồi hương, vui lòng liên hệ với chúng tôi theo địa chỉ
Cũng xuất hiện ở đây .