Como migrar do AWS S3 para MinIO no Equinix Metal

Um dos fortes casos de uso do MinIO é o fato de que ele pode ser executado em qualquer lugar e em tudo. À medida que a indústria avança lentamente no sentido da repatriação de dados para um colo ou data center, cada vez mais empresas desejam os mesmos recursos de armazenamento de objetos que tinham na nuvem, com controle total da infraestrutura.

Por que você deseja ter dados mais perto de casa? Existem vários motivos, mas o principal é o custo. A nuvem pública tornou-se muito cara. Por exemplo, há algum tempo eu tinha um cluster gerenciado ElasticSearch em execução na AWS. Eu estava ansioso para experimentar esse novo serviço gerenciado, mas não estava ansioso para discutir minha conta surpresa de US$ 30 mil com meu chefe. Este foi um alerta doloroso, mas familiar, porque naquele momento percebi que tinha acabado de pagar à AWS seis meses de orçamento de nuvem para fazer algo que eu mesmo poderia ter configurado. A moral da história é que, a menos que você seja muito cuidadoso e monitore de perto seus gastos com nuvem, eles podem ficar fora de controle muito rapidamente.

Há também a questão da segurança. Não importa onde seus dados estejam localizados na nuvem pública, eles quase sempre estão em um nó ou pool de armazenamento compartilhado por alguém que não tem nenhuma relação com você; esta é a natureza da nuvem porque é assim que a virtualização funciona. A nuvem proporciona uma sensação calorosa de conforto porque agora outra pessoa deve enfrentar os desafios de segurança, mas se houver algum problema relacionado à segurança, não haverá informações sobre o problema (se alguém foi capaz de detectá-lo) e como resolvê-lo . A sensação de conforto evapora rapidamente quando você fica preso na segurança da infraestrutura de outra pessoa para proteger seus dados. Muitas empresas aproveitaram o retorno ao controle total proporcionado pela repatriação para o MinIO do hardware que gerenciam.

Para aproveitar ao máximo seus esforços de repatriação, o MinIO vem com uma série de recursos prontos para empresas, como Bitrot Protection para garantir a integridade dos dados, Tiering para desviar dados para um nível de armazenamento frio, Erasure Coding que salva objetos como uma coleção de dados e blocos de paridade e os reconstrói rapidamente, sem qualquer hardware ou software adicional. Além disso, o MinIO suporta criptografia em repouso e em trânsito . Isso garante que os dados sejam criptografados em todas as facetas da transação, desde o momento em que a chamada é feita até o objeto ser colocado no bucket, onde são então protegidos com políticas estilo IAM S3 e um IDP integrado ou externo, consulte MinIO Melhores Práticas - Segurança e Controle de Acesso para obter mais informações.

A repatriação deve ser planejada minuciosamente e com cuidado. Se você está lidando com petabytes de dados, geralmente é mais econômico ter sua própria infraestrutura e servidores para rodar, você pode até construir uma nuvem privada com seu próprio hardware (ou alugado). Além disso, inclui também a gestão do imobiliário (espaço colo), energia/UPS, refrigeração/HVAC, entre outros componentes. Não se deixe intimidar por isso, pois demonstraremos como você pode migrar, mas o ROI geral ainda é melhor do que na nuvem pública.

Uma nuvem privada é como um apartamento (como gosta de dizer nosso CEO AB Periasamy). Você tem controle total dos custos e despesas associados a ela, nunca acorda com um alerta de uma fatura surpresa causada por alguma função de loop recursivo que funcionou durante a noite. É claro que há algum atrito na mudança quando você está tentando melhorar as coisas, por exemplo, quando você está tentando expandir uma rodovia, você inevitavelmente terá que fechar algumas pistas para que a construção possa prosseguir com segurança, mas uma vez concluída, você não apenas ser capaz de dirigir nas pistas originais, mas também nas recém-construídas para lidar com a capacidade.

Duas das considerações de custo mais importantes que precisamos fazer na nuvem pública são a quantidade de espaço de armazenamento necessário e os custos de saída ao acessar/mover esses dados – estes podem ser cerca de 39% e 42% mais altos, respectivamente, em comparação com o seu próprio hardware. em seu data center ou instalação de colocation. Além disso, alguns dos outros fatores de custo a serem considerados são software, hardware, redes/switches, imóveis/espaço de rack/aluguel de colocation, chamadas S3-API – tudo que você possa imaginar e muito mais. Saiba mais sobre as possíveis economias resultantes da mudança para sua própria nuvem privada em O Ciclo de Vida da Nuvem .

Entre a nuvem pública e o seu data center existe um meio-termo onde você pode ter controle total sobre o hardware da infraestrutura, sem o alto custo inicial de investimento. A Equinix Metal , como o nome indica, fornece servidores bare metal com as especificações exatas solicitadas pelo cliente. Se quiser usar SSDs NVMe, você poderá adicionar esses discos ao servidor bare metal. A Equinix fornece uma API de gerenciamento para simplificar a implantação e as operações de hardware. Para o desenvolvedor/usuário final, é tão simples quanto iniciar uma instância na nuvem. Na verdade, existe até um provedor Terraform para Equinix Metal (que mostraremos mais tarde).

Vamos começar!

Implantar a infraestrutura

Embora possamos implantar recursos manualmente, o DevOps em mim deseja automatizar pelo menos algumas das partes repetitivas desse processo para economizar tempo e esforço, especialmente quando queremos fazer replicação site a site, entre outras coisas.

Configurar o Equinix Metal Terraform

A Equinix é um dos poucos fornecedores bare metal que possui uma API para automatizar totalmente o processo de gerenciamento de infraestrutura. Usando sua API , você pode automatizar a implantação de servidores físicos, desligando-os e até mesmo encerrando-os. Você pode fazer tudo isso sem usar hardware, switches, roteadores e outros recursos próprios. Isso é o mais próximo possível da automação em nível de nuvem pública, ao mesmo tempo que garante que ninguém mais compartilhe seu hardware. Porque o Equinix Metal oferece suporte a uma infinidade de tipos de instâncias, opções de armazenamento e interconexões, como SAS ou SATA e SSD, SSD NVMe ou HDD, em diversos tamanhos. Você também pode configurar o hardware em que o MinIO é executado de acordo com suas especificações exatas – até o tipo exato de unidade para hospedar as partições do MinIO.

Ninguém espera que você escreva scripts Python para se comunicar com a API Metal; A Equinix Metal tem um provedor Terraform que nos permite conectar a ele e fornecer as informações de alto nível necessárias para implantar recursos de cluster, ao mesmo tempo em que abstrai o malabarismo interno necessário para configurar a rede, o hardware, o MinIO e outros aplicativos.

 provider "metal" { auth_token = var.auth_token }

Se você ainda não tiver o Terraform instalado, poderá baixá-lo na página de downloads .

Clone o repositório GitHub equinix/terraform-metal-distributed-minio em sua estação de trabalho local.

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

Acesse o repositório e inicialize o Terraform para que ele possa baixar todos os módulos e plug-ins necessários do upstream.

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

Isso garantirá que todos os módulos necessários sejam baixados automaticamente. Agora, vamos garantir que algumas variáveis obrigatórias estejam definidas. Você pode defini-los como variáveis de ambiente ou há um arquivo no repositório clonado acima chamado vars.template , que você pode copiar como cp vars.template terraform.tfvars .

Em última análise, seja qual for o método escolhido, você precisa definir as duas variáveis a seguir

• auth_token
• id_do_projeto

Você pode encontrar mais informações sobre isso na documentação da API .

Existem várias outras variáveis que você pode modificar em terraform.tfvars , e modificaremos as seguintes posteriormente, quando fizermos a replicação site a site.

• instalação: https://deploy.equinix.com/developers/docs/metal/locations/metros/
• minio_region_name: a região onde o cluster MinIO está implementado.

Depois de definir sua configuração preferida, aplique o plano Terraform. Se o plano parecer correto, execute o comando approve .

 $ terraform plan $ terraform apply --auto-approve

Se os recursos foram aplicados corretamente com a configuração correta, a saída resultante deverá ser semelhante a esta

 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

Esta é a coisa toda. Ao ver esta saída, não apenas seus servidores físicos foram provisionados, mas também o MinIO foi implementado nesses nós e os nós foram configurados como um cluster de armazenamento distribuído.

Acesse o cluster MinIO

Usamos o Terraform para automatizar a maior parte do processo, então agora só falta acessar o cluster MinIO. Nossa ferramenta recomendada é usar mc . Use o seguinte comando para baixar o binário

 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/

Crie um alias que aponte para o cluster MinIO que implantamos

 mc config host add minio1 $MINIO_ENDPOINT $MINIO_ACCESS_KEY $MINIO_SECRET_KEY

Você pode substituir as variáveis acima pelos valores definidos ao iniciar o cluster MinIO por meio do Terraform, mas certifique-se de definir o nome do alias como minio1 . Isso fará sentido mais tarde, quando mostrarmos como fazer a replicação site a site.

Verifique se você consegue se conectar com sucesso buscando alguns metadados do cluster

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

Se você vir uma saída semelhante à acima, poderá acessar com êxito o cluster MinIO por meio do comando mc . Então o que vem depois? Quando devemos migrar os dados do S3?

Balanceamento de carga do cluster MinIO

Podemos migrar os dados do S3, ou até mesmo adicionar alguns dos nossos próprios dados, e começar a usar o cluster. Mas vamos dar um passo adiante. Queremos alcançar o mesmo nível de redundância do AWS S3, ou seja, se um site ficar inativo, queremos ter certeza de que nossos dados estarão acessíveis em outro site. A AWS conseguiu isso com regiões, mas como fazemos isso com MinIO?

Agora podemos ver a beleza da pequena automação que fizemos anteriormente com o Terraform. Deixe-me mostrar como é simples criar outra região MinIO no Equinix Metal.

Vamos git clone nosso repositório de origem novamente, mas desta vez em um novo diretório terraform-metal-distributed-minio-site-2

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

Acesse o repositório terraform-metal-distributed-minio-site-2 e inicialize o Terraform para que ele possa baixar todos os módulos e plug-ins necessários do upstream, semelhante à implantação original do MinIO.

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

Depois que todos os módulos forem baixados, copie o arquivo de variáveis cp vars.template terraform.tfvars e defina as duas variáveis

• auth_token
• id_do_projeto

Até agora, o processo deve ser muito semelhante ao modo como lançamos o primeiro cluster, mas é aqui que as coisas serão diferentes.

Vamos definir as variáveis que diferenciam o segundo site do primeiro site.

Primeiro, vamos definir o facility como sv16 ou escolher um desta lista de recursos . Em seguida, defina minio_region_name como us-west-1 ou qualquer coisa que o diferencie do outro cluster.

Execute o plano para garantir que as alterações feitas sejam refletidas na saída.

 $ terraform plan $ terraform apply --auto-approve

Se os recursos foram aplicados corretamente, com a configuração correta, a saída resultante deverá ser semelhante a esta

 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

Se você vir minio_region_name como us-west-1 , então você iniciou com sucesso o segundo cluster. Vamos adicionar isso a mc .

 mc config host add minio2 $MINIO_ENDPOINT $MINIO_ACCESS_KEY $MINIO_SECRET_KEY

Defina o nome do alias como minio2 e verifique se você consegue se conectar com sucesso buscando alguns metadados do cluster

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

Neste ponto, você deverá ter 2 sites: minio1 e minio2 .

Vamos configurar a replicação nos dois clusters

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

Verifique se os dois sites estão configurados corretamente

 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>

Verifique se a replicação está funcionando corretamente

 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

Teste criando um bucket no minio1

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

Adicione qualquer objeto ao bucket

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

Liste os objetos nos outros sites, neste caso no minio2

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

Como você pode ver, é quase instantâneo replicar dados para outras implantações do MinIO, mesmo que elas sejam geograficamente díspares.

Vamos fazer um teste rápido para ver se isso é realmente tão simples quanto parece. Lembre-se de que o MinIO é um substituto imediato para o AWS S3, portanto, tudo o que deveria funcionar com o S3 também funcionará com o MinIO. Nesse caso, usaremos um Terraform para fazer upload de um objeto para um bucket MinIO. No Terraform isso é feito através do provedor AWS que é essencialmente um módulo que se conecta à API AWS para realizar diversas operações no ecossistema AWS, mas neste caso, usaremos o recurso Terraform AWS S3 para acessar o bucket MinIO.

Crie um provedor AWS no Terraform como abaixo. Certifique-se de atualizar os detalhes para corresponder ao cluster Equinix Metal minio1 que acabamos de implantar.

 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" } }

Faça upload de um arquivo usando o recurso 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") }

Como você pode ver acima, não usamos nenhum recurso Terraform específico do MinIO, estamos usando o recurso aws_s3_bucket_object do provedor AWS. Embora estejamos usando o recurso AWS S3 Terraform existente, o armazenamento de objetos é totalmente desenvolvido com MinIO de produção de nível empresarial.

Migrando dados do AWS S3

Agora temos todos os blocos de construção prontos para que você tenha armazenamento de objetos de nível de produção e controle total de toda a infraestrutura. A seguir, migraremos os dados que já estão no S3.

Existem várias maneiras de migrar seus dados do AWS S3 para o MinIO, mas a que recomendamos é usar mc .

mc mirror é um canivete suíço de sincronização de dados. Ele pode copiar objetos de armazenamentos de objetos compatíveis com S3 ou S3-API e espelhá-los para MinIO. Um dos casos de uso mais populares disso é o espelhamento de um bucket do Amazon S3 para MinIO para expor dados a aplicativos e serviços que não sejam da AWS.

Crie uma nova política IAM com uma chave de acesso e uma chave secreta, permitindo acesso apenas ao nosso bucket. Salve as credenciais geradas para a próxima etapa.

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

Use mc mirror para copiar os dados do S3 para MinIO

mc mirror s3/mybucket minio1/testbucket

Dependendo da quantidade de dados, da velocidade da rede e da distância física da região onde os dados do bucket estão armazenados, pode levar alguns minutos ou mais para você espelhar todos os dados. Você verá uma mensagem quando mc terminar de copiar todos os objetos.

Depois que os dados forem copiados ou enquanto os dados estiverem sendo copiados, liste o conteúdo do bucket no site minio2 . Você notará que alguns dos dados já estão lá em minio1 .

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

Em última análise, o laptop onde você está executando mc mirror é um gargalo porque os dados precisam passar pelo sistema onde o comando mc mirror é executado. Podem ser vários petabytes de dados que podem levar dias, senão semanas, para serem migrados, dependendo da velocidade da rede. Para migrar dados do S3 para o MinIO, existe um método mais eficiente chamado Replicação em lote. Consulte Como repatriar do AWS S3 para o MinIO para saber mais sobre a replicação em lote e outras práticas recomendadas de migração.

Coloque o pedal no metal

Esta postagem do blog demonstrou que o MinIO executado em SSDs Equinix Metal NVMe, em uma configuração de replicação site-to-site, fornecerá o mesmo nível, se não mais, de desempenho, durabilidade de dados e resiliência por uma fração do custo do S3, enquanto mantendo o controle total sobre sua nuvem.

Você tem 100% de controle de toda a infraestrutura? Não exatamente. Os switches, roteadores e outros equipamentos de rede são gerenciados pela Equinix, mas as vantagens de estar em sua rede superam as desvantagens. Você pode obter circuitos ponto a ponto, WAN ou outros circuitos dedicados para conectar-se virtualmente a qualquer outro provedor existente. Em essência, você pode ter um circuito privado conectado diretamente à AWS (via Equinix Connect) e então mover seus dados 10 vezes mais rápido, ao mesmo tempo seguro porque não atravessa a Internet pública aberta e apenas seus dados passam. esse circuito.

Além disso, os benchmarks do MinIO mostram repetidamente muito pouca (<1%) degradação do desempenho da taxa de transferência com a criptografia ativada, portanto, recomendamos que todas as implantações do MinIO usem criptografia em repouso e todas as implantações do MinIO também protejam as comunicações de rede usando TLS. Parabéns, agora seus dados estão em um sistema mais seguro, porém transparente, onde você tem total controle e responsabilidade.

Se você tiver alguma dúvida sobre a migração do AWS S3 para o MinIO no Equinix Metal, entre em contato conosco no Slack !