paint-brush
Tất cả những điều bạn cần biết để hồi hương từ AWS S3 về MinIOtừ tác giả@minio
8,892 lượt đọc
8,892 lượt đọc

Tất cả những điều bạn cần biết để hồi hương từ AWS S3 về MinIO

từ tác giả MinIO12m2024/03/22
Read on Terminal Reader
Read this story w/o Javascript

dài quá đọc không nổi

Hãy tìm hiểu sâu hơn một chút về chi phí và khoản tiết kiệm liên quan đến việc hồi hương để giúp bạn dễ dàng tổng hợp phân tích của riêng mình hơn.

People Mentioned

Mention Thumbnail
featured image - Tất cả những điều bạn cần biết để hồi hương từ AWS S3 về MinIO
MinIO HackerNoon profile picture


Phản hồi cho bài viết trước của chúng tôi, Cách hồi hương từ AWS S3 về MinIO , thật phi thường - chúng tôi đã nhận được hàng chục cuộc gọi từ các doanh nghiệp yêu cầu chúng tôi tư vấn về việc hồi hương. Chúng tôi đã tổng hợp những phản hồi đó vào bài đăng mới này, nơi chúng tôi tìm hiểu sâu hơn một chút về chi phí và khoản tiết kiệm liên quan đến việc hồi hương để giúp bạn dễ dàng tổng hợp phân tích của riêng mình hơn. Di chuyển dữ liệu là một nhiệm vụ khó khăn đối với nhiều người. Trên thực tế, họ nhắm mục tiêu dữ liệu mới đến MinIO và dành thời gian để di chuyển dữ liệu cũ từ đám mây hoặc để nguyên và không phát triển.

Tổng quan về hồi hương

Để hồi hương dữ liệu từ AWS S3, bạn sẽ tuân theo các nguyên tắc chung sau:


  1. Đá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.


  2. 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.


  3. 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 Cách hồi hương từ AWS S3 về MinIO để biết chi tiết). Có một số phương pháp bổ sung mà bạn có thể sử dụng để truyền dữ liệu, chẳng hạn như sử dụng AWS DataSync, AWS Snowball hoặc Di chuyển dữ liệu TD SYNNEX hoặc trực tiếp sử dụng API AWS.


  4. 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.


  5. 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 Đánh giá tuân thủ của Cohasset Associates về việc triển khai cửa hàng đối tượng mục tiêu.


  6. 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.


  7. 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.


  8. 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ã.


  9. 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ác bước hồi hương

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 Hàng tồn kho Amazon S3 . Ở cấp độ cao, nó sẽ trông giống như sau:


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 bảng giá , nhưng tổ chức của bạn có thể đủ điều kiện được giảm giá từ AWS. Tôi cũng đang sử dụng 10 Gbps làm băng thông kết nối, nhưng bạn có thể tùy ý sử dụng ít nhiều. Cuối cùng, tôi đang làm việc dựa trên giả định rằng 1/3 dữ liệu S3 sẽ chỉ được chuyển sang S3 Glacier Deep Archive.


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 Amazon S3 Dịch vụ quản lý khóa AWS (KMS) . Có những cân nhắc khác khi làm việc với Các lớp lưu trữ của Amazon S3 . Đối với các tác vụ xuất S3, dữ liệu được truyền tới thiết bị Snow Family của bạn từ S3 sẽ được tính phí theo mức phí S3 tiêu chuẩn cho các hoạt động như LIST, GET và các hoạt động khác. Bạn cũng bị tính phí theo mức giá tiêu chuẩn cho Amazon CloudWatch Logs, Amazon CloudWatch Metrics và Amazon CloudWatch Events.


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 Phần cứng và cấu hình được đề xuất trang và Chọn phần cứng tốt nhất để triển khai MinIO của bạn .


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 MinIO KES để quản lý khóa mã hóa . Bằng cách này, các khóa mới sẽ được tạo tự động cho bạn khi đối tượng thuê và nhóm được mã hóa được tạo trong MinIO.


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, Cách hồi hương từ AWS S3 về MinIO bao gồm hướng dẫn chi tiết cho cả hai phương pháp. Bạn có thể sao chép các đối tượng trực tiếp từ S3 sang MinIO tại chỗ hoặc sử dụng cụm MinIO tạm thời chạy trên EC2 để truy vấn S3 rồi phản chiếu sang MinIO tại chỗ.


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 Dịch vụ di chuyển dữ liệu trang trên trang TD SYNNEX.


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 Lệnh gọi API S3 và sau đó thiết lập trong MinIO. Khi bạn đăng ký MinIO SUBNET, các kỹ sư của chúng tôi sẽ làm việc với bạn để di chuyển các cài đặt này từ AWS S3: quản lý quyền truy cập dựa trên khóa truy cập/khóa bí mật, chính sách quản lý vòng đời, mã hóa, quyền truy cập công khai ẩn danh, tính bất biến và lập phiên bản. Một lưu ý về việc lập phiên bản, ID phiên bản AWS thường không được giữ nguyên khi dữ liệu được di chuyển vì mỗi ID phiên bản là một UUID nội bộ. Đây phần lớn không phải là vấn đề đối với khách hàng vì các đối tượng thường được gọi bằng tên. Tuy nhiên, nếu cần có ID phiên bản AWS thì chúng tôi có tiện ích mở rộng sẽ lưu giữ ID phiên bản đó trong MinIO và chúng tôi sẽ giúp bạn kích hoạt nó.


Đặc biệt chú ý tới Chính sách IAM và nhóm . S3 sẽ không phải là phần duy nhất trong cơ sở hạ tầng của AWS mà bạn bỏ lại phía sau. Bạn sẽ có rất nhiều tài khoản dịch vụ để ứng dụng sử dụng khi truy cập nhóm S3. Đây sẽ là thời điểm tốt để liệt kê và kiểm tra tất cả các tài khoản dịch vụ của bạn. Sau đó, bạn có thể quyết định có tạo lại chúng trong nhà cung cấp danh tính của mình hay không. Nếu bạn chọn tự động hóa, hãy sử dụng Amazon Cognito để chia sẻ thông tin IAM với IDP OpenID Connect và AD/LDAP bên ngoà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-holdget-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 bí danh dành cho S3 và MinIO để bạn không cần phải nhập đầy đủ địa chỉ và thông tin xác thực. Ví dụ:


 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 Thông báo sự kiện S3 để gọi các dịch vụ xuôi tuyến khi có dữ liệu mới đến. Nếu đúng như vậy thì đừng lo lắng - MinIO hỗ trợ Thông báo sự kiện cũng. Việc di chuyển đơn giản nhất ở đây là triển khai webhook tùy chỉnh để nhận thông báo. Tuy nhiên, nếu bạn cần một đích đến bền vững và linh hoạt hơn thì hãy sử dụng các dịch vụ nhắn tin như Kafka hoặc RabbitMQ. Chúng tôi cũng hỗ trợ gửi sự kiện đến cơ sở dữ liệu như PostgreSQL và MySQL.


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 số liệu thông qua điểm cuối Prometheus mà bạn có thể sử dụng trong nền tảng giám sát và cảnh báo được lựa chọn . Để biết thêm về giám sát, vui lòng xem Giám sát và cảnh báo trên nhiều đám mây với Prometheus và Grafana Số liệu với MinIO sử dụng OpenTelemetry, Flask và Prometheus .


Với MẠNG PHỤ , chúng tôi luôn ủng hộ bạn khi nói đến Hoạt động ngày thứ 2 với MinIO. Người đăng ký có quyền truy cập vào các công cụ khắc phục sự cố tự động tích hợp để giữ cho cụm của họ hoạt động trơn tru. Họ cũng nhận được hỗ trợ trực tiếp, không giới hạn cho kỹ sư trong thời gian thực thông qua cổng hỗ trợ của chúng tôi. Chúng tôi cũng giúp bạn đảm bảo đầu tư lưu trữ đối tượng của mình trong tương lai bằng việc đánh giá kiến trúc hàng năm.

Di chuyển và lưu

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ỉ xin chà[email protected] .


Cũng xuất hiện ở đây .


L O A D I N G
. . . comments & more!

About Author

MinIO HackerNoon profile picture
MinIO@minio
MinIO is a high-performance, cloud-native object store that runs anywhere (public cloud, private cloud, colo, onprem).

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI...