paint-brush
Comment migrer d'AWS S3 vers MinIO sur Equinix Metalpar@minio
5,852 lectures
5,852 lectures

Comment migrer d'AWS S3 vers MinIO sur Equinix Metal

par MinIO13m2023/11/16
Read on Terminal Reader

Trop long; Pour lire

L’exécution de MinIO sur les SSD Equinix Metal NVMe vous offrira le même niveau de performances, de durabilité des données et de résilience pour une fraction du coût de S3.
featured image - Comment migrer d'AWS S3 vers MinIO sur Equinix Metal
MinIO HackerNoon profile picture
0-item
1-item

L’un des principaux cas d’utilisation de MinIO est le fait qu’il peut fonctionner n’importe où et sur n’importe quoi. Alors que le secteur s'oriente lentement vers le rapatriement des données vers un centre de données ou un centre de données, de plus en plus d'entreprises souhaitent bénéficier des mêmes capacités de stockage objet que celles dont elles disposaient dans le cloud, avec un contrôle total de l'infrastructure.


Pourquoi voudriez-vous avoir des données plus près de chez vous ? Il y a plusieurs raisons, mais la première est le coût. Le cloud public est devenu très cher. Par exemple, il y a quelque temps, j'avais un cluster géré ElasticSearch exécuté sur AWS. J'avais hâte d'essayer ce nouveau service géré, mais je n'avais pas envie de discuter de ma facture surprise de 30 000 $ avec mon patron. Ce fut un réveil douloureux, mais familier, car à ce moment-là, j'ai réalisé que je venais de payer six mois de budget cloud à AWS pour faire quelque chose que j'aurais pu mettre en place moi-même. La morale de l’histoire est qu’à moins d’être très prudent et de surveiller de près vos dépenses cloud, elles peuvent devenir incontrôlables très rapidement.


Il y a aussi la question de la sécurité. Quel que soit l'emplacement de vos données dans le cloud public, elles se trouvent presque toujours sur un nœud ou un pool de stockage partagé par une personne totalement indépendante de vous ; c'est la nature du cloud car c'est ainsi que fonctionne la virtualisation. Le cloud procure une chaleureuse sensation de confort car désormais quelqu'un d'autre doit relever les défis de sécurité, mais s'il y a des problèmes liés à la sécurité, il n'y aura aucune idée du problème (si quelqu'un était capable de le détecter) ni comment le résoudre. . Le sentiment de confort s'évapore rapidement lorsque vous êtes obligé de sécuriser l'infrastructure de quelqu'un d'autre afin de protéger vos données. De nombreuses entreprises ont profité du retour au contrôle total offert par le rapatriement vers MinIO sur le matériel qu'elles gèrent.


Pour tirer le meilleur parti de vos efforts de rapatriement, MinIO est livré avec un certain nombre de fonctionnalités prêtes pour l'entreprise telles que la protection Bitrot pour garantir l'intégrité des données, la hiérarchisation pour siphonner les données vers un niveau de stockage froid, l'effacement du codage qui enregistre les objets sous forme de collection de données et blocs de parité et les reconstruit à la volée sans matériel ni logiciel supplémentaire. En plus de cela, MinIO prend en charge à la fois le chiffrement au repos et en transit . Cela garantit que les données sont chiffrées dans toutes les facettes de la transaction depuis le moment où l'appel est effectué jusqu'à ce que l'objet soit placé dans le compartiment, où il est ensuite protégé par des politiques de style IAM S3 et un IDP intégré ou externe, voir MinIO . Meilleures pratiques - Sécurité et contrôle d'accès pour plus d'informations.


Le rapatriement doit être planifié de manière minutieuse et minutieuse. Si vous traitez des pétaoctets de données, il est généralement plus rentable de disposer de votre propre infrastructure et de vos propres serveurs. Vous pouvez même créer un cloud privé avec votre propre matériel (ou loué). En outre, cela inclut également la gestion de l'immobilier (espace de stockage), de l'alimentation électrique/UPS, du refroidissement/CVC, entre autres composants. Ne vous laissez pas décourager par ces éléments, car nous vous montrerons comment migrer, mais le retour sur investissement global est toujours meilleur que dans le cloud public.


Un cloud privé est comme un appartement (comme aime à le dire notre PDG AB Periasamy). Vous contrôlez totalement les coûts et les dépenses qui y sont associés, vous ne vous réveillez jamais avec une alerte de facture surprise provoquée par une fonction de boucle récursive exécutée pendant la nuit. Il y a, bien sûr, certaines frictions lorsque vous essayez d'améliorer les choses. Par exemple, lorsque vous essayez d'agrandir une autoroute, vous devez inévitablement fermer certaines voies pour que la construction puisse se dérouler en toute sécurité, mais une fois que c'est fait, vous le ferez. non seulement pouvoir circuler sur les voies d'origine, mais aussi sur les voies nouvellement construites pour gérer la capacité.


Deux des considérations financières les plus importantes que nous devons prendre en compte dans le cloud public sont la quantité d'espace de stockage dont vous avez besoin et les coûts de sortie lors de l'accès/du déplacement de ces données – ceux-ci peuvent être respectivement environ 39 % et 42 % plus élevés par rapport à votre propre matériel. dans votre centre de données ou installation de colocation. En plus de cela, certains des autres facteurs de coût à prendre en compte sont les logiciels, le matériel, la mise en réseau/les commutateurs, l'immobilier/l'espace de rack/la location de colocation, les appels S3-API – tout ce à quoi vous pouvez penser et plus encore. Apprenez-en davantage sur les économies possibles résultant du passage à votre propre cloud privé dans Le cycle de vie du cloud .


Entre le cloud public et votre centre de données, il existe un juste milieu où vous pouvez avoir un contrôle total sur le matériel de l'infrastructure, sans le coût d'investissement initial élevé. Equinix Metal , comme son nom l'indique, fournit des serveurs nus avec les spécifications exactes demandées par le client. Si vous souhaitez utiliser des SSD NVMe, vous pouvez ajouter ces disques au serveur nu. Equinix fournit une API de gestion pour simplifier le déploiement et les opérations du matériel. Pour le développeur/utilisateur final, c'est aussi simple que de lancer une instance dans le cloud. En fait, il existe même un fournisseur Terraform pour Equinix Metal (que nous vous montrerons plus tard).


Commençons!

Déployer l'infrastructure

Bien que nous puissions déployer des ressources manuellement, le DevOps en moi souhaite automatiser au moins certaines des parties répétitives de ce processus pour économiser du temps et des efforts, en particulier lorsque nous souhaitons effectuer, entre autres, une réplication de site à site.

Configurer Equinix Metal Terraform

Equinix est l'un des rares fournisseurs de matériel nu à disposer d'une API pour automatiser entièrement le processus de gestion de l'infrastructure. Grâce à leur API , vous pouvez automatiser le déploiement de serveurs physiques, les arrêter et même y mettre fin. Vous pouvez faire tout cela sans utiliser votre propre matériel, commutateurs, routeurs et autres ressources. C'est aussi proche que possible de l'automatisation au niveau du cloud public tout en garantissant que personne d'autre ne partage votre matériel. Parce qu'Equinix Metal prend en charge une myriade de types d'instances, d'options de stockage et d'interconnexions telles que SAS ou SATA, ainsi que SSD, NVMe SSD ou HDD, dans une variété de tailles. Vous pouvez également configurer le matériel sur lequel MinIO s'exécute selon vos spécifications exactes, jusqu'au type exact de lecteur pour héberger les partitions MinIO.


Personne ne s'attend à ce que vous écriviez des scripts Python pour communiquer avec l'API Metal ; Equinix Metal dispose d'un fournisseur Terraform qui nous permet de nous y connecter et de fournir les informations de haut niveau nécessaires au déploiement des ressources du cluster, tout en éliminant la jonglerie interne requise pour configurer le réseau, le matériel, MinIO et d'autres applications.


 provider "metal" { auth_token = var.auth_token }


Si Terraform n'est pas déjà installé, vous pouvez le télécharger à partir de leur page de téléchargements .


Clonez le dépôt GitHub equinix/terraform-metal-distributed-minio sur votre poste de travail local.


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


Accédez au dépôt et initialisez Terraform afin qu'il puisse télécharger tous les modules et plugins requis en amont.


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


Cela garantira que tous les modules requis sont téléchargés automatiquement. Maintenant, assurons-nous que quelques variables obligatoires sont définies. Vous pouvez soit les définir comme variables d'environnement , soit il existe un fichier dans le dépôt cloné ci-dessus appelé vars.template , que vous pouvez copier sous cp vars.template terraform.tfvars .


En fin de compte, quelle que soit la méthode que vous choisissez, vous devez définir les deux variables suivantes

  • auth_token
  • id_projet


Vous pouvez trouver plus d’informations à ce sujet dans la documentation de l’API .


Il existe plusieurs autres variables que vous pouvez modifier dans terraform.tfvars , et nous modifierons ce qui suit plus tard lorsque nous effectuerons une réplication de site à site.



Une fois que vous avez défini votre configuration préférée, appliquez le plan Terraform. Si le plan semble correct, exécutez la commande approve .


 $ terraform plan $ terraform apply --auto-approve


Si les ressources ont été appliquées correctement avec la bonne configuration, le résultat devrait ressembler à ceci :


 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


C'est tout le shebang. Lorsque vous voyez ce résultat, non seulement vos serveurs physiques ont été provisionnés, mais également MinIO a été déployé sur ces nœuds, et les nœuds ont été configurés en tant que cluster de stockage distribué.

Accéder au cluster MinIO

Nous avons utilisé Terraform pour automatiser la majeure partie du processus, il ne reste donc plus qu'à accéder au cluster MinIO. Notre outil recommandé est d’utiliser mc . Utilisez la commande suivante pour télécharger le binaire


 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/


Créez un alias qui pointe vers le cluster MinIO que nous avons déployé


 mc config host add minio1 $MINIO_ENDPOINT $MINIO_ACCESS_KEY $MINIO_SECRET_KEY


Vous pouvez remplacer les variables ci-dessus par les valeurs que vous avez définies lors du lancement du cluster MinIO via Terraform, mais assurez-vous de définir le nom d'alias sur minio1 . Cela aura du sens plus tard lorsque nous vous montrerons comment effectuer une réplication de site à site.


Vérifiez si vous parvenez à vous connecter avec succès en récupérant certaines métadonnées du cluster


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


Si vous voyez une sortie similaire à celle ci-dessus, vous pouvez accéder avec succès au cluster MinIO via la commande mc . Alors, quelle est la prochaine étape ? Quand devons-nous migrer les données de S3 ?

Équilibrage de charge du cluster MinIO

Nous pouvons migrer les données de S3, ou même ajouter certaines de nos propres données, et commencer à utiliser le cluster. Mais allons plus loin. Nous voulons atteindre le même niveau de redondance qu'AWS S3, ce qui signifie que si un site tombe en panne, nous voulons nous assurer que nos données sont accessibles sur un autre site. AWS a accompli cela avec les régions, mais comment y parvenir avec MinIO ?


Nous pouvons maintenant voir la beauté de la petite automatisation que nous avons réalisée plus tôt avec Terraform. Laissez-moi vous montrer à quel point il est simple de créer une autre région MinIO dans Equinix Metal.


Permet à git clone à nouveau notre dépôt source, mais cette fois dans un nouveau répertoire terraform-metal-distributed-minio-site-2


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


Accédez au référentiel terraform-metal-distributed-minio-site-2 et initialisez Terraform afin qu'il puisse télécharger tous les modules et plugins requis depuis l'amont, de manière similaire au déploiement MinIO d'origine.


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


Une fois tous les modules téléchargés, copiez le fichier de variables cp vars.template terraform.tfvars et définissez les deux variables


  • auth_token
  • id_projet


Jusqu’à présent, le processus devrait ressembler beaucoup à la façon dont nous avons lancé le premier cluster, mais c’est là que les choses différeront.


Définissons les variables qui différencient le deuxième site du premier site.


Tout d'abord, définissons l' facility sur sv16 ou choisissons-en une dans cette liste d' installations . Ensuite, définissez minio_region_name sur us-west-1 ou tout ce qui le différencie de l'autre cluster.


Exécutez le plan pour vous assurer que les modifications que vous avez apportées sont reflétées dans le résultat.


 $ terraform plan $ terraform apply --auto-approve


Si les ressources ont été appliquées correctement, avec la bonne configuration, le résultat devrait ressembler à ceci :


 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


Si vous voyez minio_region_name comme us-west-1 , vous avez lancé avec succès le deuxième cluster. Ajoutons cela à mc .


 mc config host add minio2 $MINIO_ENDPOINT $MINIO_ACCESS_KEY $MINIO_SECRET_KEY


Définissez le nom d'alias sur minio2 et vérifiez si vous parvenez à vous connecter avec succès en récupérant certaines métadonnées du cluster.


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


À ce stade, vous devriez avoir 2 sites : minio1 et minio2 .


Configurons la réplication sur les deux clusters


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


Vérifiez que les deux sites sont correctement configurés


 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>


Vérifiez que la réplication fonctionne correctement


 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


Testez en créant un bucket dans minio1


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


Ajouter n'importe quel objet dans le bucket


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


Lister les objets dans les autres sites, en l'occurrence sur minio2


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


Comme vous pouvez le constater, la réplication des données vers d'autres déploiements MinIO est presque instantanée, même s'ils sont géographiquement disparates.


Faisons un test rapide pour voir si c'est vraiment aussi simple qu'il y paraît. N'oubliez pas que MinIO remplace AWS S3, donc tout ce qui est censé fonctionner avec S3 fonctionnera également avec MinIO. Dans ce cas, nous utiliserons un Terraform pour télécharger un objet dans un bucket MinIO. Dans Terraform, cela se fait via le fournisseur AWS qui est essentiellement un module qui se connecte à l'API AWS pour effectuer diverses opérations dans l'écosystème AWS, mais dans ce cas, nous utiliserons la ressource Terraform AWS S3 pour accéder au compartiment MinIO.


Créez un fournisseur AWS dans Terraform comme ci-dessous. Assurez-vous de mettre à jour les détails pour qu'ils correspondent au cluster Equinix Metal minio1 que nous venons de déployer.


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


Téléchargez un fichier à l'aide de la ressource 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") }


Comme vous pouvez le voir ci-dessus, nous n'avons utilisé aucune ressource Terraform spécifique à MinIO, nous utilisons la ressource aws_s3_bucket_object du fournisseur AWS. Même si nous utilisons la ressource AWS S3 Terraform existante, le magasin d'objets est entièrement alimenté par MinIO de production de niveau entreprise.

Migration de données depuis AWS S3

Nous disposons désormais de tous les éléments de base prêts à vous permettre de bénéficier d'un stockage objet de niveau production et d'un contrôle total de l'ensemble de l'infrastructure. Ensuite, nous allons migrer les données déjà présentes dans S3.


Il existe plusieurs façons de migrer vos données d'AWS S3 vers MinIO, mais celle que nous recommandons consiste à utiliser mc .


mc mirror est un couteau suisse de synchronisation de données. Il peut copier des objets à partir de magasins d'objets compatibles S3 ou S3-API et les mettre en miroir dans MinIO. L'un des cas d'utilisation les plus courants consiste à mettre en miroir un compartiment Amazon S3 sur MinIO afin d'exposer les données à des applications et services non AWS.


Créez une nouvelle stratégie IAM avec une clé d'accès et une clé secrète, autorisant l'accès uniquement à notre compartiment. Enregistrez les informations d'identification générées pour l'étape suivante.


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


Utilisez mc Mirror pour copier les données de S3 vers MinIO


mc mirror s3/mybucket minio1/testbucket


En fonction de la quantité de données, des vitesses du réseau et de la distance physique par rapport à la région où les données du compartiment sont stockées, la mise en miroir de toutes les données peut prendre quelques minutes ou plus. Vous verrez un message lorsque mc aura fini de copier tous les objets.


Une fois les données copiées ou pendant la copie des données, répertoriez le contenu du bucket sur le site minio2 . Vous remarquerez que certaines données proviennent déjà de minio1 .


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


En fin de compte, l'ordinateur portable à partir duquel vous exécutez mc mirror constitue un goulot d'étranglement car les données doivent traverser le système sur lequel la commande mc mirror est exécutée. Cela pourrait représenter plusieurs pétaoctets de données dont la migration pourrait prendre des jours, voire des semaines, en fonction de la vitesse du réseau. Pour migrer des données de S3 vers MinIO, il existe une méthode plus efficace appelée Réplication par lots. Veuillez consulter Comment rapatrier d'AWS S3 vers MinIO pour en savoir plus sur la réplication par lots et d'autres bonnes pratiques de migration.

Mettez la pédale sur le métal

Cet article de blog a démontré que MinIO fonctionnant sur des SSD Equinix Metal NVMe, dans une configuration de réplication de site à site, vous offrira le même niveau, sinon plus, de performances, de durabilité des données et de résilience pour une fraction du coût de S3 tout en en gardant le contrôle total sur votre cloud.


Avez-vous le contrôle à 100 % de toute l’infrastructure ? Pas assez. Les commutateurs, routeurs et autres équipements réseau sont gérés par Equinix, mais les avantages d'être sur leur réseau dépassent les inconvénients. Vous pouvez obtenir des circuits point à point, WAN ou autres circuits dédiés pour vous connecter virtuellement à n’importe quel autre fournisseur. En substance, vous pouvez avoir un circuit privé connecté directement à AWS (via Equinix Connect) et ensuite déplacer vos données 10 fois plus rapidement, tout en étant sécurisé car il ne traverse pas l'Internet public ouvert, et seules vos données transitent. ce circuit.


De plus, les tests MinIO montrent à plusieurs reprises une très faible dégradation des performances de débit (<1 %) avec le chiffrement activé. Nous recommandons donc que tous les déploiements MinIO utilisent le chiffrement au repos et que tous les déploiements MinIO doivent également sécuriser les communications réseau à l'aide de TLS. Félicitations, vos données se trouvent désormais sur un système plus sécurisé, mais transparent, où vous avez un contrôle et une responsabilité total.


Si vous avez des questions sur la migration d'AWS S3 vers MinIO sur Equinix Metal, n'hésitez pas à nous contacter sur Slack !


Également publié ici .