AWS S3에서 Equinix Metal의 MinIO로 마이그레이션하는 방법

MinIO의 강력한 사용 사례 중 하나는 어디에서나 모든 환경에서 실행될 수 있다는 것입니다. 업계가 점차 데이터를 콜로세움이나 데이터 센터로 송환하는 방향으로 전환함에 따라 점점 더 많은 기업이 인프라를 완벽하게 제어하면서 클라우드에 있던 것과 동일한 개체 스토리지 기능을 원하고 있습니다.

왜 집 근처에 데이터를 갖고 싶습니까? 여러 가지 이유가 있겠지만 무엇보다도 비용이 가장 큰 이유입니다. 퍼블릭 클라우드는 매우 비싸졌습니다. 예를 들어, 얼마 전 AWS에서 ElasticSearch 관리형 클러스터를 실행하고 있었습니다. 저는 이 새로운 관리형 서비스를 시험해보고 싶었지만, 30,000달러라는 놀라운 청구서를 상사와 논의하고 싶지 않았습니다. 이는 고통스러우면서도 친숙한 깨우침이었습니다. 그 순간 저는 제가 스스로 설정할 수 있는 일을 하기 위해 AWS에 6개월 간의 클라우드 예산을 지불했다는 것을 깨달았기 때문입니다. 이야기의 교훈은 매우 조심하고 클라우드 지출을 면밀히 모니터링하지 않으면 매우 빠르게 통제할 수 없게 될 수 있다는 것입니다.

보안 문제도 있습니다. 데이터가 퍼블릭 클라우드 어디에 있든 관계없이 거의 항상 귀하와 전혀 관련이 없는 사람이 공유하는 노드나 스토리지 풀에 있습니다. 이것이 가상화가 작동하는 방식이기 때문에 클라우드의 특성입니다. 클라우드는 이제 다른 사람이 보안 문제를 해결해야 하기 때문에 따뜻한 편안함을 제공하지만 보안 관련 문제가 있는 경우 문제에 대한 통찰력(누군가 감지할 수 있었다면)과 해결 방법에 대한 통찰력이 없습니다. . 자신의 데이터를 보호하기 위해 다른 사람의 인프라를 보호하는 데 어려움을 겪게 되면 편안함은 급속히 사라져 버립니다. 많은 기업에서는 자신이 관리하는 하드웨어에 MinIO를 다시 설치함으로써 완전한 제어권을 되찾았습니다.

송환 노력을 최대한 활용하기 위해 MinIO에는 데이터 무결성을 보장하는 Bitrot Protection , 데이터를 콜드 스토리지 계층으로 사이펀 하는 계층화 , 개체를 데이터 모음으로 저장하는 Erasure Coding 과 같은 다양한 엔터프라이즈 지원 기능이 함께 제공됩니다. 패리티 블록은 추가 하드웨어나 소프트웨어 없이 즉시 재구성됩니다. 이 외에도 MinIO는 저장 및 전송 중 암호화를 모두 지원합니다. 이렇게 하면 호출이 이루어진 순간부터 객체가 버킷에 배치될 때까지 트랜잭션의 모든 측면에서 데이터가 암호화되어 버킷에서 IAM S3 스타일 정책과 내장 또는 외부 IDP로 보호됩니다. MinIO를 참조하세요. 모범 사례 - 보안 및 액세스 제어 에 대한 자세한 내용을 확인하세요.

송환은 철저하고 신중하게 계획되어야 합니다. 일반적으로 페타바이트 규모의 데이터를 처리하는 경우 실행할 자체 인프라와 서버를 보유하는 것이 더 비용 효율적이며, 자체(또는 임대) 하드웨어로 프라이빗 클라우드를 구축할 수도 있습니다. 또한 여기에는 부동산(콜로 공간), 전력/UPS, 냉각/HVAC 등의 구성 요소 관리도 포함됩니다. 마이그레이션할 수 있는 방법을 보여드릴 것이므로 이에 대해 단념하지 마십시오. 전체 ROI는 퍼블릭 클라우드보다 여전히 좋습니다.

프라이빗 클라우드는 아파트와 같습니다(CEO AB Periasamy가 말했듯이). 귀하는 이와 관련된 비용 및 지출을 완전히 통제할 수 있으며 밤새 실행된 일부 재귀 루프 기능으로 인해 발생하는 예상치 못한 청구서에 대한 경고에 깨어나지 않습니다. 물론 상황을 개선하려고 할 때 이동할 때 약간의 마찰이 있습니다. 예를 들어 고속도로를 확장하려고 할 때 건설이 안전하게 진행될 수 있도록 필연적으로 일부 차선을 폐쇄해야 하지만 일단 완료되면 원래 차선뿐만 아니라 용량을 처리할 수 있도록 새로 건설된 차선에서도 운전할 수 있습니다.

퍼블릭 클라우드에서 고려해야 할 가장 중요한 두 가지 비용 고려 사항은 필요한 저장 공간의 양과 해당 데이터에 액세스/이동할 때 발생하는 송신 비용입니다. 이는 자체 하드웨어에 비해 각각 약 39% 및 42% 더 높을 수 있습니다. 데이터 센터 또는 코로케이션 시설에서. 이 외에도 고려해야 할 다른 비용 요소로는 소프트웨어, 하드웨어, 네트워킹/스위치, 부동산/랙 공간/코로케이션 임대, S3-API 호출 등 생각할 수 있는 모든 것이 있습니다. 클라우드 수명주기 에서 자체 프라이빗 클라우드로 전환하여 얻을 수 있는 절감 효과에 대해 자세히 알아보세요.

퍼블릭 클라우드와 데이터 센터 사이에는 높은 초기 투자 비용 없이 인프라 하드웨어를 완벽하게 제어할 수 있는 중간 지점이 있습니다. Equinix Metal은 이름에서 알 수 있듯이 고객이 요청한 정확한 사양을 갖춘 베어메탈 서버를 제공합니다. NVMe SSD를 사용하려는 경우 해당 디스크를 베어메탈 서버에 추가할 수 있습니다. Equinix는 하드웨어 배포 및 운영을 단순화하는 관리 API를 제공합니다. 개발자/최종 사용자에게는 클라우드에서 인스턴스를 시작하는 것만큼 간단합니다. 실제로 Equinix Metal을 위한 Terraform 제공업체도 있습니다(나중에 설명하겠습니다).

시작하자!

인프라 배포

리소스를 수동으로 배포할 수도 있지만 DevOps는 특히 사이트 간 복제를 수행하려는 경우 시간과 노력을 절약하기 위해 이 프로세스의 반복적인 부분 중 적어도 일부를 자동화하려고 합니다.

Equinix Metal Terraform 설정

Equinix는 인프라 관리 프로세스를 완전히 자동화하는 API를 갖춘 몇 안 되는 베어메탈 공급업체 중 하나입니다. API를 사용하면 물리적 서버 배포를 자동화하고 종료할 수 있으며 심지어 종료할 수도 있습니다. 자체 하드웨어, 스위치, 라우터 및 기타 리소스를 사용하지 않고도 이 모든 작업을 수행할 수 있습니다. 이는 다른 사람이 귀하의 하드웨어를 공유하지 않는다는 것을 보장하면서 퍼블릭 클라우드 수준 자동화에 도달할 수 있는 것과 가장 가깝습니다. Equinix Metal은 다양한 크기의 수많은 인스턴스 유형과 스토리지 옵션, SAS, SATA, SSD, NVMe SSD, HDD와 같은 상호 연결을 지원하기 때문입니다. 또한 MinIO 파티션을 수용할 드라이브의 정확한 유형까지 MinIO가 실행되는 하드웨어를 정확한 사양에 맞게 구성할 수 있습니다.

Metal API와 통신하기 위해 Python 스크립트를 작성하는 사람은 아무도 없습니다. Equinix Metal에는 네트워킹, 하드웨어, MinIO 및 기타 애플리케이션을 설정하는 데 필요한 내부 작업을 추상화하는 동시에 연결하고 클러스터 리소스를 배포하는 데 필요한 상위 수준 정보를 제공할 수 있는 Terraform 공급자가 있습니다.

 provider "metal" { auth_token = var.auth_token }

Terraform을 아직 설치하지 않은 경우 다운로드 페이지 에서 다운로드할 수 있습니다.

GitHub 저장소 equinix/terraform-metal-distributed-minio 로컬 워크스테이션에 복제합니다.

git clone https://github.com/equinix/terraform-metal-distributed-minio.git

저장소로 이동하여 업스트림에서 필요한 모든 모듈과 플러그인을 다운로드할 수 있도록 Terraform을 초기화합니다.

 $ cd terraform-metal-distributed-minio $ terraform init

이렇게 하면 필요한 모든 모듈이 자동으로 다운로드됩니다. 이제 몇 가지 필수 변수가 설정되어 있는지 확인해 보겠습니다. 환경 변수 로 설정하거나 위에 복제된 저장소에 vars.template 이라는 파일이 있습니다. 이 파일은 cp vars.template terraform.tfvars 로 복사할 수 있습니다.

궁극적으로 어떤 방법을 선택하든 다음 두 변수를 설정해야 합니다.

• 인증_토큰
• 프로젝트_ID

이에 대한 자세한 내용은 API 문서에서 확인할 수 있습니다.

terraform.tfvars 에서 수정할 수 있는 다른 변수가 여러 개 있으며, 나중에 사이트 간 복제를 수행할 때 다음을 수정하겠습니다.

• 시설: https://deploy.equinix.com/developers/docs/metal/locations/metros/
• minio_region_name: MinIO 클러스터가 배포되는 지역입니다.

원하는 구성 세트가 있으면 Terraform 계획을 적용하세요. 계획이 괜찮아 보이면 approve 명령을 실행하십시오.

 $ terraform plan $ terraform apply --auto-approve

리소스가 올바른 구성으로 제대로 적용되었다면 결과 출력은 다음과 같아야 합니다.

 Apply complete! Resources: 10 added, 0 changed, 0 destroyed. Outputs: minio_access_key = Xe245QheQ7Nwi20dxsuF minio_access_secret = 9g4LKJlXqpe7Us4MIwTPluNyTUJv4A5T9xVwwcZh minio_endpoints = [ "minio-storage-node1 minio endpoint is http://147.75.65.29:9000", "minio-storage-node2 minio endpoint is http://147.75.39.227:9000", "minio-storage-node3 minio endpoint is http://147.75.66.53:9000", "minio-storage-node4 minio endpoint is http://147.75.194.101:9000", ] minio_region_name = us-east-1

이것이 전체 셔뱅입니다. 이 출력이 표시되면 물리적 서버가 프로비저닝되었을 뿐만 아니라 MinIO도 이러한 노드에 배포되었으며 노드가 분산 스토리지 클러스터로 구성된 것입니다.

MinIO 클러스터에 액세스

Terraform을 사용하여 대부분의 프로세스를 자동화했으므로 이제 남은 것은 MinIO 클러스터에 액세스하는 것뿐입니다. 우리가 권장하는 도구는 mc 사용하는 것입니다. 바이너리를 다운로드하려면 다음 명령을 사용하십시오.

 curl https://dl.min.io/client/mc/release/linux-amd64/mc \ --create-dirs \ -o $HOME/minio-binaries/mc chmod +x $HOME/minio-binaries/mc export PATH=$PATH:$HOME/minio-binaries/

우리가 배포한 MinIO 클러스터를 가리키는 별칭을 만듭니다.

 mc config host add minio1 $MINIO_ENDPOINT $MINIO_ACCESS_KEY $MINIO_SECRET_KEY

위의 변수를 Terraform을 통해 MinIO 클러스터를 시작하는 동안 설정한 값으로 바꿀 수 있지만 별칭 이름을 minio1 로 설정해야 합니다. 이는 나중에 사이트 간 복제를 수행하는 방법을 보여줄 때 의미가 있습니다.

클러스터에서 일부 메타데이터를 가져와 성공적으로 연결할 수 있는지 확인하세요.

 $ mc admin info minio1 --json | jq .info.backend { "backendType": "Erasure", "onlineDisks": 48, "rrSCData": 6, "rrSCParity": 2, "standardSCData": 6, "standardSCParity": 2 }

위와 유사한 출력이 표시되면 mc 명령을 통해 MinIO 클러스터에 성공적으로 액세스할 수 있습니다. 그럼 다음은 무엇입니까? 언제 S3에서 데이터를 마이그레이션해야 합니까?

MinIO 클러스터의 로드 밸런싱

S3에서 데이터를 마이그레이션하거나 자체 데이터 중 일부를 추가하고 클러스터 사용을 시작할 수도 있습니다. 하지만 한 단계 더 나아가 보겠습니다. 우리는 AWS S3와 동일한 수준의 중복성을 달성하고자 합니다. 즉, 한 사이트가 다운되면 다른 사이트에서 데이터에 액세스할 수 있도록 하려는 것입니다. AWS는 리전을 통해 이를 달성했지만 MinIO를 통해 이를 어떻게 달성합니까?

이제 이전에 Terraform으로 수행한 작은 자동화의 아름다움을 볼 수 있습니다. Equinix Metal에서 또 다른 MinIO 영역을 얻는 것이 얼마나 간단한지 보여드리겠습니다.

git clone 하세요. 하지만 이번에는 새로운 디렉터리 terraform-metal-distributed-minio-site-2 에 있습니다.

git clone https://github.com/equinix/terraform-metal-distributed-minio.git terraform-metal-distributed-minio-site-2

terraform-metal-distributed-minio-site-2 저장소로 이동하여 원래 MinIO 배포와 유사한 업스트림에서 필요한 모든 모듈과 플러그인을 다운로드할 수 있도록 Terraform을 초기화합니다.

 $ cd terraform-metal-distributed-minio-site-2 $ terraform init

모든 모듈이 다운로드되면 변수 파일 cp vars.template terraform.tfvars 복사하고 두 변수를 설정합니다.

• 인증_토큰
• 프로젝트_ID

지금까지의 프로세스는 첫 번째 클러스터를 시작한 방법과 매우 유사해 보이지만 여기서는 상황이 다릅니다.

두 번째 사이트를 첫 번째 사이트와 구별하는 변수를 설정해 보겠습니다.

먼저 facility sv16 으로 설정하거나 이 시설 목록에서 하나를 선택해 보겠습니다. 다음으로 minio_region_name us-west-1 또는 다른 클러스터와 구별할 수 있는 이름으로 설정합니다.

계획을 실행하여 변경 사항이 출력에 반영되었는지 확인하세요.

 $ terraform plan $ terraform apply --auto-approve

올바른 구성으로 리소스가 적절하게 적용되었다면 결과 출력은 다음과 같아야 합니다.

 Apply complete! Resources: 10 added, 0 changed, 0 destroyed. Outputs: minio_access_key = Xe245QheQ7Nwi20dxsuF minio_access_secret = 9g4LKJlXqpe7Us4MIwTPluNyTUJv4A5T9xVwwcZh minio_endpoints = [ "minio-storage-node1 minio endpoint is http://144.45.65.29:9000", "minio-storage-node2 minio endpoint is http://144.45.39.227:9000", "minio-storage-node3 minio endpoint is http://144.45.66.53:9000", "minio-storage-node4 minio endpoint is http://144.45.194.101:9000", ] minio_region_name = us-west-1

minio_region_name us-west-1 로 표시되면 두 번째 클러스터를 성공적으로 시작한 것입니다. mc 에 추가해 보겠습니다.

 mc config host add minio2 $MINIO_ENDPOINT $MINIO_ACCESS_KEY $MINIO_SECRET_KEY

별칭 이름을 minio2 로 설정하고 클러스터에서 일부 메타데이터를 가져와서 성공적으로 연결할 수 있는지 확인하세요.

 $ mc admin info minio2 --json | jq .info.backend { "backendType": "Erasure", "onlineDisks": 48, "rrSCData": 6, "rrSCParity": 2, "standardSCData": 6, "standardSCParity": 2 }

이제 minio1 및 minio2 라는 2개의 사이트가 있어야 합니다.

두 클러스터에 걸쳐 복제를 설정해 보겠습니다.

 $ mc admin replicate add minio1 minio2 Requested sites were configured for replication successfully.

두 사이트가 모두 올바르게 구성되었는지 확인하세요.

 mc admin replicate info minio1 SiteReplication enabled for: Deployment ID | Site Name | Endpoint f96a6675-ddc3-4c6e-907d-edccd9eae7a4 | minio1 | http://<site1_public_ip> 0dfce53f-e85b-48d0-91de-4d7564d5456f | minio2 | http://<site2_public_ip>

복제가 제대로 작동하는지 확인하세요.

 mc admin replicate status minio1 Bucket replication status: No Buckets present Policy replication status: ● 5/5 Policies in sync User replication status: No Users present Group replication status: No Groups present

minio1 에서 버킷을 생성하여 테스트

/opt/minio-binaries/mc mb minio1/testbucket

버킷에 객체 추가

/opt/minio-binaries/mc cp my_object minio1/testbucket

다른 사이트(이 경우 minio2 의 개체를 나열합니다.

 /opt/minio-binaries/mc ls minio2/testbucket [2023-07-20 18:52:09 UTC] 3.0KiB STANDARD my_object

보시다시피 지리적으로 서로 떨어져 있더라도 다른 MinIO 배포에 데이터를 복제하는 것은 거의 즉각적입니다.

이것이 실제로 보이는 것처럼 간단한지 확인하기 위해 간단한 테스트를 해보자. MinIO는 AWS S3를 즉시 대체하므로 S3에서 작동해야 하는 모든 것이 MinIO에서도 작동한다는 점을 기억하세요. 이 경우 Terraform을 사용하여 MinIO 버킷에 객체를 업로드하겠습니다. Terraform에서는 AWS 생태계에서 다양한 작업을 수행하기 위해 AWS API에 연결하는 모듈인 AWS 공급자를 통해 이 작업이 수행되지만, 이 경우에는 Terraform AWS S3 리소스를 사용하여 MinIO 버킷에 액세스합니다.

아래와 같이 Terraform에서 AWS 공급자를 생성합니다. 방금 배포한 Equinix Metal minio1 클러스터와 일치하도록 세부 정보를 업데이트하세요.

 provider "aws" { region = "us-east-1" access_key = "Xe245QheQ7Nwi20dxsuF" secret_key = "9g4LKJlXqpe7Us4MIwTPluNyTUJv4A5T9xVwwcZh" skip_credentials_validation = true skip_metadata_api_check = true skip_requesting_account_id = true s3_force_path_style = true endpoints { s3 = "http://147.75.65.29:9000" } }

Terraform aws_s3_bucket_object 리소스를 사용하여 파일 업로드

 resource "aws_s3_bucket_object" "object" { bucket = "public" key = "my_file_name.txt" source = "path/to/my_file_name.txt" etag = filemd5("path/to/my_file_name.txt") }

위에서 볼 수 있듯이 우리는 MinIO 관련 Terraform 리소스를 사용하지 않았으며 AWS 공급자 aws_s3_bucket_object 리소스를 사용하고 있습니다. 기존 AWS S3 Terraform 리소스를 사용하고 있지만 객체 저장소는 프로덕션 엔터프라이즈급 MinIO로 완전히 구동됩니다.

AWS S3에서 데이터 마이그레이션

이제 우리는 프로덕션급 객체 스토리지와 전체 인프라를 완벽하게 제어할 수 있는 모든 구성 요소를 갖추고 있습니다. 다음으로 이미 S3에 있는 데이터를 마이그레이션하겠습니다.

AWS S3에서 MinIO로 데이터를 마이그레이션할 수 있는 방법은 여러 가지가 있지만 우리가 권장하는 방법은 mc 사용하는 것입니다.

mc mirror 데이터 동기화의 스위스 군용 칼입니다. S3 또는 S3-API 호환 객체 저장소에서 객체를 복사하여 MinIO에 미러링할 수 있습니다. 가장 널리 사용되는 사용 사례 중 하나는 AWS가 아닌 애플리케이션 및 서비스에 데이터를 노출하기 위해 Amazon S3 버킷을 MinIO에 미러링하는 것입니다.

버킷에 대한 액세스만 허용하는 액세스 키와 비밀 키를 사용하여 새 IAM 정책을 생성합니다. 다음 단계를 위해 생성된 자격 증명을 저장합니다.

 /opt/minio-binaries/mc alias set s3 https://s3.amazonaws.com BKIKJAA5BMMU2RHO6IBB V7f1CwQqAcwo80UEIJEjc5gVQUSSx5ohQ9GSrr12 --api S3v4

mc 미러를 사용하여 S3에서 MinIO로 데이터 복사

mc mirror s3/mybucket minio1/testbucket

데이터 양, 네트워크 속도, 버킷 데이터가 저장되는 지역과의 물리적 거리에 따라 모든 데이터를 미러링하는 데 몇 분 이상 걸릴 수 있습니다. mc 모든 개체 복사를 완료하면 메시지가 표시됩니다.

데이터가 복사되면 또는 데이터가 복사되는 동안 minio2 사이트에 버킷의 내용을 나열합니다. 일부 데이터가 minio1 에 이미 있다는 것을 알 수 있습니다.

 /opt/minio-binaries/mc ls minio2/testbucket [2022-12-19 18:52:09 UTC] 3.0KiB STANDARD all_object s

궁극적으로 mc mirror mc mirror 를 실행 중인 랩톱에 병목 현상이 발생합니다. 이는 네트워크 속도에 따라 마이그레이션하는 데 몇 주가 아니더라도 며칠이 걸릴 수 있는 수 페타바이트의 데이터일 수 있습니다. S3에서 MinIO로 데이터를 마이그레이션하려면 배치 복제라는 보다 효율적인 방법이 있습니다. 배치 복제 및 기타 마이그레이션 모범 사례에 대해 자세히 알아보려면 AWS S3에서 MinIO로 송환하는 방법을 참조하십시오.

페달을 금속에 놓으십시오.

이 블로그 게시물은 사이트 간 복제 구성의 Equinix Metal NVMe SSD에서 실행되는 MinIO가 S3보다 훨씬 적은 비용으로 동일한 수준의 성능, 데이터 내구성 및 탄력성을 제공한다는 것을 보여주었습니다. 클라우드에 대한 모든 권한을 유지합니다.

모든 인프라를 100% 통제할 수 있습니까? 좀 빠지는. 스위치, 라우터 및 기타 네트워킹 장비는 Equinix에서 관리하지만 네트워크에 연결되어 있다는 장점이 단점을 능가합니다. 지점 간, WAN 또는 기타 전용 회선을 사용하여 다른 제공업체에 가상으로 연결할 수 있습니다. 본질적으로 개인 회선을 AWS에 직접 연결하면(Equinix Connect를 통해) 데이터를 10배 빠른 속도로 이동할 수 있으며 동시에 공개 공용 인터넷을 통과하지 않고 데이터만 통과하므로 안전합니다. 그 회로.

또한 MinIO 벤치마크에서는 암호화가 설정된 경우 처리량 성능 저하가 거의(1% 미만) 반복적으로 나타납니다. 따라서 모든 MinIO 배포에서는 미사용 암호화를 사용하고 모든 MinIO 배포에서는 TLS를 사용하여 네트워크 통신을 보호 해야 합니다. 축하합니다. 이제 귀하의 데이터는 귀하가 모든 권한을 갖고 책임을 지는 보다 안전하면서도 투명한 시스템에 있습니다.

AWS S3에서 Equinix Metal의 MinIO로 마이그레이션하는 데 대해 질문이 있는 경우 Slack을 통해 문의해 주세요!