이전 게시물에 대한 답변은 다음과 같습니다.
AWS S3에서 데이터를 송환하려면 다음 일반 지침을 따르십시오.
데이터 요구 사항 검토: AWS S3에서 송환해야 하는 특정 버킷과 객체를 결정합니다. 버킷별로 비즈니스 요구 사항과 규정 준수 요구 사항을 이해해야 합니다.
송환 대상 식별: 이미 MinIO로 송환하기로 결정했습니다. 이제 온프레미스 데이터 센터나 다른 클라우드 공급자 또는 코로케이션 시설에서 MinIO를 실행하도록 선택할 수 있습니다. #1의 요구 사항을 사용하여 예상되는 스토리지, 전송 및 가용성 요구 사항에 맞는 하드웨어 또는 인스턴스를 선택합니다.
데이터 전송: AWS S3에서 MinIO로의 데이터 전송을 계획하고 실행합니다. MinIO에 내장된 배치 복제를 사용하거나 MinIO 클라이언트를 사용하여 미러링하기만 하면 됩니다(참조:
데이터 액세스 및 권한: 송환된 데이터에 대해 버킷별로 적절한 액세스 제어 및 권한이 설정되어 있는지 확인합니다. 여기에는 데이터 보안을 보장하기 위해 사용자 액세스, 인증, 권한 부여를 관리하기 위한 IAM 및 버킷 정책이 포함됩니다.
객체 잠금: 마이그레이션 후에 객체 잠금 보존 및 법적 보존 정책을 유지하는 것이 중요합니다. 대상 객체 저장소는 Amazon S3와 동일한 방식으로 규칙을 해석해야 합니다. 확실하지 않은 경우에는
데이터 수명주기 관리: 송환된 데이터에 대한 데이터 수명주기 관리 전략을 정의하고 구현합니다. 여기에는 보존 정책, 백업 및 복구 절차, 버킷별 데이터 보관 방식 정의가 포함됩니다.
데이터 검증: 전송된 데이터의 무결성과 완전성을 보장하기 위해 검증합니다. 데이터가 손상이나 손실 없이 성공적으로 전송되었는지 확인하기 위해 필요한 점검과 테스트를 수행하십시오. 전송 후 개체 이름, ETag 및 메타데이터, 체크섬 및 개체 수는 소스와 대상 간에 모두 일치합니다.
애플리케이션 및 워크플로 업데이트: 좋은 소식은 클라우드 네이티브 원칙에 따라 애플리케이션을 구축하는 경우 새로운 MinIO 엔드포인트에 맞게 애플리케이션을 재구성하기만 하면 된다는 것입니다. 그러나 애플리케이션과 워크플로가 AWS 에코시스템과 함께 작동하도록 설계된 경우 송환된 데이터를 수용하기 위해 필요한 업데이트를 수행하십시오. 여기에는 구성 업데이트, 통합 재구성 또는 경우에 따라 코드 수정이 포함될 수 있습니다.
모니터링 및 최적화: 송환된 데이터 환경을 지속적으로 모니터링하고 최적화하여 최적의 성능, 비용 효율성 및 데이터 관리 모범 사례 준수를 보장합니다.
클라우드 송환에 대한 예산을 책정하고 계획할 때 고려해야 할 요소가 많이 있습니다. 다행스럽게도 우리 엔지니어들은 많은 고객과 함께 이 작업을 수행했으며 귀하를 위한 세부 계획을 개발했습니다. 소수의 워크로드부터 수백 페타바이트까지 모든 것을 본국으로 송환한 고객이 있습니다.
가장 큰 계획 작업은 네트워킹, 임대 대역폭, 서버 하드웨어, 송환하도록 선택되지 않은 데이터에 대한 보관 비용, 자체 클라우드 인프라를 관리하고 유지하는 데 드는 인적 비용에 대한 선택을 고려하는 것입니다. 이러한 비용을 추정하고 이에 대한 계획을 세우십시오. 클라우드 송환 비용에는 클라우드에서 데이터 센터로 데이터를 다시 이동하는 데 드는 데이터 송신 비용이 포함됩니다. 이러한 수수료는 클라우드 잠금을 강제할 만큼 의도적으로 높습니다. 이러한 높은 송신 비용을 기록해 두십시오. 이는 관리하는 데이터의 양이 증가함에 따라 송신 비용이 증가하기 때문에 퍼블릭 클라우드를 떠나는 경제적 주장을 입증합니다. 그러므로 본국으로 송환할 예정이라면, 더 늦기보다는 빨리 조치를 취하는 것이 좋습니다.
우리는 이동해야 하는 데이터와 메타데이터에 중점을 둘 것입니다. 이는 송환에 필요한 작업의 80%입니다. 메타데이터에는 버킷 속성 및 정책(액세스/비밀 키를 기반으로 한 액세스 관리, 수명 주기 관리, 암호화, 익명 공개 액세스, 객체 잠금 및 버전 관리)이 포함됩니다.
지금은 데이터(객체)에 집중하겠습니다. 마이그레이션하려는 각 네임스페이스에 대해 이동하려는 버킷 및 개체의 인벤토리를 작성합니다. DevOps 팀은 이미 중요한 현재 데이터를 보관하는 버킷을 알고 있을 가능성이 높습니다. 당신은 또한 사용할 수 있습니다
네임스페이스 | 총 버킷 | 총 개체 수 | 총 개체 크기(GB) | 일일 총 업로드(TB) | 일일 총 다운로드(TB) |
---|---|---|---|---|---|
ns-001 | 166 | 47,751,258 | 980,014.48 | 50.04 | 14.80 |
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 |
다음 단계는 마이그레이션할 각 버킷과 해당 속성을 네임스페이스별로 나열하는 것입니다. 해당 버킷에 데이터를 저장하고 읽는 애플리케이션을 기록해 둡니다. 사용량에 따라 각 버킷을 핫, 웜, 콜드 계층 데이터로 분류합니다.
요약 버전에서는 다음과 같습니다.
버킷 이름 | 속성 | 앱 | 핫/웜/콜드 계층 |
---|---|---|---|
ㅏ | 여기에 JSON을 복사하여 붙여넣으세요. | 스파크, 아이스버그, 드레미오 | 더운 |
비 | 여기에 JSON을 복사하여 붙여넣으세요. | 탄력있는 | 따뜻한 |
씨 | 여기에 JSON을 복사하여 붙여넣으세요. | 탄력적(스냅샷) | 추운 |
이제 데이터 수명 주기 관리에 관해 몇 가지 결정을 내려야 하며, AWS 수수료를 절약할 수 있는 좋은 방법이 있으므로 세심한 주의를 기울이십시오. 액세스 빈도에 따라 각 버킷의 객체를 핫, 웜 또는 콜드로 분류합니다. 비용을 절약할 수 있는 가장 좋은 방법은 콜드 계층 버킷을 S3 Glacier로 직접 마이그레이션하는 것입니다. 다시 업로드하기 위해 다운로드하는 데 송신 비용이 발생할 이유가 없습니다.
본국으로 송환하는 데이터의 양에 따라 마이그레이션 방법을 선택할 수 있는 몇 가지 옵션이 있습니다. 시간이 지남에 따라 핫 데이터와 웜 데이터를 새 클러스터에 복사하는 동안 새 MinIO 클러스터에서 새 데이터를 로드하고 작업하는 것이 좋습니다. 물론 객체를 복사하는 데 필요한 시간과 대역폭은 복사하는 객체의 수와 크기에 따라 달라집니다.
여기에서 AWS S3에서 송환할 총 데이터를 계산하는 것이 매우 도움이 될 것입니다. 재고를 살펴보고 핫 및 웜으로 분류된 모든 버킷의 총 크기를 확인하십시오.
총 핫 및 웜 계층 데이터 = 1,534,096.7GB |
---|
사용 가능한 대역폭 = 10Gbps |
필요한 최소 전송 시간(총 객체 크기 / 사용 가능한 대역폭) = 14.2일 |
위의 총액을 기준으로 데이터 송신 비용을 계산합니다. 나는 사용하고있다
S3 Glacier에 계층화된 총 데이터 = 767,048.337GB |
---|
S3에서 S3 Glacier로의 전송 수수료($0.05/1000개 객체) = $3,773.11 |
S3 Glacier Deep Archive 월별 스토리지 요금 = $760 |
앞으로 S3 Glacier Deep Archive 사용에 대한 예산을 책정하는 것을 잊지 마십시오.
전송될 총 데이터 = 1,534,096.7GB |
---|
처음 10TB($0.09/GB) = $900 |
다음 40TB($0.085/GB = $3,400) |
다음 100TB는 $0.07/GB = $70,000 |
$0.05/GB로 150TB를 초과하는 추가 = $69,205 |
총 송신 수수료 = $143,504 |
단순화를 위해 위 계산에는 객체당 작업 비용($0.40/1m)이나 LISTing 비용($5/1m)이 포함되지 않습니다. 대규모 송환 프로젝트의 경우 네트워크를 통해 개체를 보내기 전에 개체를 압축하여 송신 비용을 일부 절약할 수도 있습니다.
또 다른 옵션은 AWS Snowball을 사용하여 객체를 전송하는 것입니다. Snowball 디바이스는 각각 80TB이므로 송환을 위해 20개가 필요하다는 것을 미리 알고 있습니다. 기기당 요금에는 사용 기간 10일과 배송 2일이 포함됩니다. 추가일은 기기당 $30로 이용 가능합니다.
20 Snowball 디바이스 서비스 요금(개당 $300) = $6,000 |
---|
R/T 배송(3~5일, 기기당 $400) = $8,000 |
S3 데이터 출력($0.02/GB) = $30,682 |
총 Snowball 요금 = $38,981.93 |
AWS는 다음을 포함한 AWS 서비스에서 읽고 쓰는 데 필요한 표준 요청, 스토리지 및 데이터 전송 요금을 청구합니다.
이제 우리는 이 엄청난 양의 데이터를 마이그레이션하는 데 걸리는 시간과 비용을 알고 있습니다. 시기와 수수료의 조합을 기반으로 어떤 방법이 귀하의 요구 사항을 충족하는지에 대한 비즈니스 결정을 내리십시오.
이 시점에서 우리는 온프레미스 또는 코로케이션 시설에서 MinIO를 실행하는 데 필요한 하드웨어에 대한 요구 사항도 알고 있습니다. 1.5PB의 스토리지에 대한 위의 요구 사항을 고려하여 데이터 증가를 예측하고 당사에 문의하십시오.
첫 번째 단계는 MinIO에서 S3 버킷을 다시 생성하는 것입니다. 개체 마이그레이션 방법에 관계없이 이 작업을 수행해야 합니다. S3와 MinIO는 모두 서버 측 암호화를 사용하여 객체를 저장하지만 암호화 키 마이그레이션에 대해 걱정할 필요가 없습니다. 다음을 사용하여 선택한 KMS에 연결할 수 있습니다.
객체를 복사하는 여러 가지 옵션이 있습니다: 일괄 복제 및 mc mirror
. 예전 블로그 포스팅,
일반적으로 고객은 AWS Snowball 또는 TD SYNNEX의 데이터 마이그레이션 하드웨어 및 서비스와 결합하여 우리가 작성한 도구를 사용하여 더 많은 양의 데이터(1PB 이상)를 이동합니다.
MinIO는 최근 Western Digital 및 TD SYNNEX와 제휴하여 Snowball 대안을 마련했습니다. 고객은 Western Digital 하드웨어 배송을 받기 위한 기간을 예약하고 임대 기간 동안 필요한 비용을 지불할 수 있습니다. 더 중요한 것은 서비스가 특정 클라우드에 묶여 있지 않다는 것입니다. 즉, 기업은 이 서비스를 사용하여 유비쿼터스 S3 프로토콜을 사용하여 클라우드 안팎으로 데이터를 이동할 수 있습니다. 자세한 서비스 내용은 홈페이지에서 확인하실 수 있습니다.
정책 및 버킷 속성을 포함한 버킷 메타데이터는 get-bucket
사용하여 읽을 수 있습니다.
특히 주의하세요
객체 보존, 객체 잠금, 아카이브/계층화 등 데이터 수명주기 관리에 특별한 주의를 기울이십시오. 각 버킷에서 get-bucket-lifecycle-configuration
실행하여 사람이 읽을 수 있는 수명 주기 규칙의 JSON 목록을 얻습니다. MinIO 콘솔 또는 MinIO 클라이언트(mc)를 사용하여 AWS S3 설정을 쉽게 다시 생성할 수 있습니다. get-object-legal-hold
및 get-object-lock-configuration
과 같은 명령을 사용하여 특별한 보안 및 거버넌스 처리가 필요한 개체를 찾아냅니다.
수명주기에 관해 이야기하면서 잠시 백업 및 재해 복구에 대해 이야기해 보겠습니다. 백업 및 재해 복구를 위해 복제할 추가 MinIO 클러스터를 원하십니까?
객체가 AWS S3에서 MinIO로 복사된 후에는 데이터 무결성을 검증하는 것이 중요합니다. 이를 수행하는 가장 쉬운 방법은 MinIO 클라이언트를 사용하여 S3의 이전 버킷과 MinIO의 새 버킷에 대해 mc diff
실행하는 것입니다. 그러면 버킷 간의 차이가 계산되고 누락되었거나 다른 객체의 목록만 반환됩니다. 이 명령은 소스 및 대상 버킷의 인수를 사용합니다. 귀하의 편의를 위해 다음을 생성할 수도 있습니다.
mc diff s3/bucket1 minio/bucket1
좋은 소식은 기존 앱을 새로운 MinIO 엔드포인트로 지정하기만 하면 된다는 것입니다. 일정 기간 동안 앱별로 구성을 다시 작성할 수 있습니다. 객체 스토리지의 데이터 마이그레이션은 파일 시스템보다 방해가 적습니다. 새 클러스터에서 읽기/쓰기가 가능하도록 URL을 변경하기만 하면 됩니다. 이전에 애플리케이션을 지원하기 위해 AWS 서비스에 의존했다면 해당 서비스는 데이터 센터에 존재하지 않으므로 해당 오픈 소스 서비스로 교체하고 일부 코드를 다시 작성해야 합니다. 예를 들어 Athena는 Spark SQL, Apache Hive 및 Presto, Kinesis는 Apache Kafka, AWS Glue는 Apache Airflow로 대체될 수 있습니다.
S3 마이그레이션이 전체 애플리케이션을 온프레미스로 이동하려는 대규모 노력의 일부라면,
이제 송환을 완료했으므로 스토리지 운영, 모니터링 및 최적화에 관심을 돌릴 차례입니다. 좋은 소식은 MinIO에는 최적화가 필요하지 않다는 것입니다. 소프트웨어에 최적화 기능이 내장되어 있어 하드웨어에 대한 최고의 성능을 얻을 수 있다는 것을 알 수 있습니다. 새로운 MinIO 클러스터 모니터링을 시작하여 지속적으로 리소스 활용도와 성능을 평가할 수 있습니다. MinIO 노출
와 함께
클라우드 제공업체에 백지 수표를 보내던 시절이 지났다는 것은 비밀이 아닙니다. 현재 많은 기업이 잠재적인 절감액을 찾기 위해 클라우드 지출을 평가하고 있습니다. 이제 구체적인 기술 단계와 재무 프레임워크를 포함하여 AWS S3에서 MinIO로 마이그레이션을 시작하는 데 필요한 모든 것이 갖추어져 있습니다.
송환 비용 절감에 대한 기대가 있으신 경우 다음 주소로 문의해 주십시오.
여기에도 나타납니다.