Uno de los casos de uso más importantes de MinIO es el hecho de que puede ejecutarse en cualquier lugar y en todo. A medida que la industria avanza lentamente hacia la repatriación de datos a una colo o centro de datos, cada vez más empresas quieren las mismas capacidades de almacenamiento de objetos que tenían en la nube, con control total de la infraestructura.
¿Por qué querrías tener datos más cerca de casa? Hay varias razones, pero la principal es el costo. La nube pública se ha vuelto muy cara. Por ejemplo, hace algún tiempo tenía un clúster administrado de ElasticSearch ejecutándose en AWS. Estaba ansioso por probar este nuevo servicio administrado, pero no estaba ansioso por discutir mi factura sorpresa de $30 mil con mi jefe. Esta fue una llamada de atención dolorosa, pero familiar, porque en ese momento me di cuenta de que acababa de pagarle a AWS seis meses de presupuesto de nube para hacer algo que podría haber configurado yo mismo. La moraleja de la historia es que, a menos que tenga mucho cuidado y controle de cerca su gasto en la nube, puede salirse de control muy rápidamente.
También está la cuestión de la seguridad. No importa dónde se encuentren sus datos en la nube pública, casi siempre están en un nodo o grupo de almacenamiento compartido por alguien que no tiene ninguna relación con usted; Esta es la naturaleza de la nube porque así es como funciona la virtualización. La nube proporciona una cálida sensación de comodidad porque ahora alguien más debe abordar los desafíos de seguridad, pero si hay algún problema relacionado con la seguridad, no habrá información sobre el problema (si alguien fue capaz de detectarlo) y cómo resolverlo. . La sensación de comodidad se evapora rápidamente cuando te quedas atascado asegurando la infraestructura de otra persona para proteger tus datos. Muchas empresas han disfrutado del retorno al control total que ofrece la repatriación a MinIO en el hardware que administran.
Para aprovechar al máximo sus esfuerzos de repatriación, MinIO viene con una serie de funciones listas para la empresa, como Bitrot Protection para garantizar la integridad de los datos, Tiering para desviar datos a un nivel de almacenamiento en frío, Erasure Coding que guarda objetos como una colección de datos y bloques de paridad y los reconstruye sobre la marcha sin ningún hardware o software adicional. Además de estos, MinIO admite tanto el cifrado en reposo como en tránsito . Esto garantiza que los datos estén cifrados en todas las facetas de la transacción desde el momento en que se realiza la llamada hasta que el objeto se coloca en el depósito, donde luego se protege con políticas estilo IAM S3 y un IDP integrado o externo, consulte MinIO . Mejores prácticas: seguridad y control de acceso para obtener más información.
La repatriación debe planificarse minuciosa y cuidadosamente. Si se trata de petabytes de datos, generalmente es más rentable tener su propia infraestructura y servidores para ejecutarlos; incluso puede crear una nube privada con su propio hardware (o alquilado). Además, esto también incluye la gestión de los bienes inmuebles (espacio de colo), energía/UPS, refrigeración/HVAC, entre otros componentes. No se deje disuadir por esto, ya que le demostraremos cómo puede migrar y, sin embargo, el retorno de la inversión general sigue siendo mejor que en la nube pública.
Una nube privada es como un apartamento (como le gusta decir a nuestro CEO AB Periasamy). Usted tiene el control total de los costos y gastos asociados con él, nunca se despierta con una alerta de una factura sorpresa causada por alguna función de bucle recursivo que se ejecutó durante la noche. Por supuesto, existe cierta fricción al moverse cuando se intenta mejorar las cosas; por ejemplo, cuando se intenta ampliar una carretera, inevitablemente hay que cerrar algunos carriles para que la construcción pueda continuar con seguridad, pero una vez hecho esto, no sólo podrá circular por los carriles originales sino también por los de nueva construcción para manejar la capacidad.
Dos de las consideraciones de costos más importantes que debemos tener en cuenta en la nube pública son la cantidad de espacio de almacenamiento que necesita y los costos de salida al acceder o mover esos datos; estos pueden ser alrededor de un 39 % y un 42 % más altos, respectivamente, en comparación con su propio hardware. en su centro de datos o instalación de colocación. Además de esto, algunos de los otros factores de costos a considerar son el software, hardware, redes/switches, bienes raíces/espacio en rack/alquiler de colocación, llamadas S3-API: todo lo que se pueda imaginar y más. Obtenga más información sobre los posibles ahorros que resultan de migrar a su propia nube privada en El ciclo de vida de la nube .
Entre la nube pública y su centro de datos existe un punto medio donde puede tener control total sobre el hardware de la infraestructura, sin el alto costo inicial de inversión. Equinix Metal , como su nombre indica, proporciona servidores bare metal con las especificaciones exactas solicitadas por el cliente. Si desea utilizar SSD NVMe, puede agregar esos discos al servidor básico. Equinix proporciona una API de administración para simplificar la implementación y las operaciones de hardware. Para el desarrollador/usuario final, es tan sencillo como lanzar una instancia en la nube. De hecho, incluso existe un proveedor de Terraform para Equinix Metal (que le mostraremos más adelante).
¡Empecemos!
Si bien podemos implementar recursos manualmente, el DevOps que hay en mí quiere automatizar al menos algunas de las partes repetitivas de este proceso para ahorrar tiempo y esfuerzo, especialmente cuando queremos realizar replicación de sitio a sitio, entre otras cosas.
Equinix es uno de los pocos proveedores bare metal que tiene una API para automatizar completamente el proceso de gestión de la infraestructura. Usando su API , puede automatizar la implementación de servidores físicos, apagándolos e incluso finalizándolos. Puede hacer todo esto sin utilizar su propio hardware, conmutadores, enrutadores y otros recursos. Esto es lo más cerca que puede llegar a la automatización a nivel de nube pública y al mismo tiempo garantizar que nadie más comparta su hardware. Porque Equinix Metal admite una gran variedad de tipos de instancias y opciones de almacenamiento e interconexiones como SAS o SATA y SSD, NVMe SSD o HDD, en una variedad de tamaños. También puede configurar el hardware en el que se ejecuta MinIO según sus especificaciones exactas, hasta el tipo exacto de unidad para albergar las particiones MinIO.
Nadie espera que escribas scripts de Python para comunicarte con la API de Metal; Equinix Metal tiene un proveedor Terraform que nos permite conectarnos a él y proporcionar la información de alto nivel necesaria para implementar los recursos del clúster, al mismo tiempo que abstraemos los malabarismos internos necesarios para configurar las redes, el hardware, MinIO y otras aplicaciones.
provider "metal" { auth_token = var.auth_token }
Si aún no tienes Terraform instalado, puedes descargarlo desde su página de descargas .
Clona el repositorio de GitHub equinix/terraform-metal-distributed-minio
en tu estación de trabajo local.
git clone https://github.com/equinix/terraform-metal-distributed-minio.git
Vaya al repositorio e inicialice Terraform para que pueda descargar todos los módulos y complementos necesarios desde arriba.
$ cd terraform-metal-distributed-minio $ terraform init
Esto garantizará que todos los módulos necesarios se descarguen automáticamente. Ahora, asegurémonos de que estén configuradas un par de variables obligatorias. Puede configurarlos como variables de entorno o hay un archivo en el repositorio clonado anteriormente llamado vars.template
, que puede copiar como cp vars.template terraform.tfvars
.
En última instancia, cualquiera que sea el método que elija, debe configurar las dos variables siguientes
Puede encontrar más información sobre estos en los documentos API .
Hay varias otras variables que puede modificar en terraform.tfvars
, y modificaremos las siguientes más adelante cuando realicemos la replicación de sitio a sitio.
Una vez que haya establecido su configuración preferida, aplique el plan Terraform. Si el plan parece correcto, ejecute el comando approve
.
$ terraform plan $ terraform apply --auto-approve
Si los recursos se han aplicado correctamente con la configuración correcta, entonces el resultado resultante debería verse así
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
Este es todo el asunto. Cuando vea este resultado, no solo se han aprovisionado sus servidores físicos, sino que también se ha implementado MinIO en estos nodos y los nodos se han configurado como un clúster de almacenamiento distribuido.
Usamos Terraform para automatizar la mayor parte del proceso, por lo que ahora todo lo que queda es acceder al clúster MinIO. Nuestra herramienta recomendada es utilizar mc
. Utilice el siguiente comando para descargar el binario
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/
Cree un alias que apunte al clúster MinIO que implementamos
mc config host add minio1 $MINIO_ENDPOINT $MINIO_ACCESS_KEY $MINIO_SECRET_KEY
Puede reemplazar las variables anteriores con los valores que configuró al iniciar el clúster MinIO a través de Terraform, pero asegúrese de establecer el nombre de alias en minio1
. Esto tendrá sentido más adelante, cuando le mostremos cómo realizar la replicación de sitio a sitio.
Verifique si puede conectarse correctamente obteniendo algunos metadatos del clúster
$ mc admin info minio1 --json | jq .info.backend { "backendType": "Erasure", "onlineDisks": 48, "rrSCData": 6, "rrSCParity": 2, "standardSCData": 6, "standardSCParity": 2 }
Si ve un resultado similar al anterior, entonces podrá acceder con éxito al clúster MinIO mediante el comando mc
. ¿Qué es lo siguiente? ¿Cuándo deberíamos migrar los datos de S3?
Podemos migrar los datos desde S3, o incluso agregar algunos de nuestros propios datos y comenzar a usar el clúster. Pero vayamos un paso más allá. Queremos lograr el mismo nivel de redundancia que AWS S3, lo que significa que si un sitio deja de funcionar, queremos asegurarnos de que nuestros datos sean accesibles en otro sitio. AWS logró esto con regiones, pero ¿cómo lo logramos con MinIO?
Ahora podemos ver la belleza de la pequeña automatización que hicimos anteriormente con Terraform. Permítame mostrarle lo sencillo que es crear otra región MinIO en Equinix Metal.
Vamos git clone
nuestro repositorio fuente nuevamente, pero esta vez en un nuevo directorio terraform-metal-distributed-minio-site-2
git clone https://github.com/equinix/terraform-metal-distributed-minio.git terraform-metal-distributed-minio-site-2
Vaya al repositorio terraform-metal-distributed-minio-site-2
e inicialice Terraform para que pueda descargar todos los módulos y complementos necesarios desde arriba, de manera similar a la implementación original de MinIO.
$ cd terraform-metal-distributed-minio-site-2 $ terraform init
Una vez que se hayan descargado todos los módulos, copie el archivo de variables cp vars.template terraform.tfvars
y configure las dos variables
Hasta ahora, el proceso debería ser muy similar a cómo lanzamos el primer clúster, pero aquí es donde las cosas serán diferentes.
Establezcamos las variables que diferencian el segundo sitio del primer sitio.
Primero, configuremos la facility
en sv16
o elijamos una de esta lista de instalaciones . A continuación, configure minio_region_name
en us-west-1
o cualquier cosa que lo diferencie del otro clúster.
Ejecute el plan para asegurarse de que los cambios que realizó se reflejen en el resultado.
$ terraform plan $ terraform apply --auto-approve
Si los recursos se han aplicado correctamente, con la configuración correcta, entonces el resultado resultante debería verse así
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 ve minio_region_name
como us-west-1
, entonces ha iniciado exitosamente el segundo clúster. Agreguemos eso a mc
.
mc config host add minio2 $MINIO_ENDPOINT $MINIO_ACCESS_KEY $MINIO_SECRET_KEY
Establezca el nombre de alias en minio2
y verifique si puede conectarse correctamente obteniendo algunos metadatos del clúster.
$ mc admin info minio2 --json | jq .info.backend { "backendType": "Erasure", "onlineDisks": 48, "rrSCData": 6, "rrSCParity": 2, "standardSCData": 6, "standardSCParity": 2 }
En este punto, debería tener 2 sitios: minio1
y minio2
.
Configuremos la replicación en ambos clústeres.
$ mc admin replicate add minio1 minio2 Requested sites were configured for replication successfully.
Verifique que ambos sitios estén configurados correctamente
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 para asegurarse de que la replicación esté funcionando correctamente
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
Pruebe creando un depósito en minio1
/opt/minio-binaries/mc mb minio1/testbucket
Añade cualquier objeto al depósito.
/opt/minio-binaries/mc cp my_object minio1/testbucket
Listar los objetos en los otros sitios, en este caso en minio2
/opt/minio-binaries/mc ls minio2/testbucket [2023-07-20 18:52:09 UTC] 3.0KiB STANDARD my_object
Como puede ver, es casi instantáneo replicar datos en otras implementaciones de MinIO, aunque sean geográficamente dispares.
Hagamos una prueba rápida para ver si realmente esto es tan simple como parece. Recuerde que MinIO es un reemplazo directo de AWS S3, por lo que todo lo que se supone que funciona con S3 también funcionará con MinIO. En este caso, usaremos Terraform para cargar un objeto en un depósito MinIO. En Terraform, esto se hace a través del proveedor de AWS, que es esencialmente un módulo que se conecta a la API de AWS para realizar diversas operaciones en el ecosistema de AWS, pero en este caso, usaremos el recurso Terraform AWS S3 para acceder al depósito MinIO.
Cree un proveedor de AWS en Terraform como se muestra a continuación. Asegúrese de actualizar los detalles para que coincidan con el clúster Equinix Metal minio1
que acabamos de implementar.
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" } }
Cargue un archivo usando el 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 puede ver arriba, no hemos utilizado ningún recurso Terraform específico de MinIO, estamos utilizando el recurso aws_s3_bucket_object
del proveedor de AWS. Aunque estamos utilizando el recurso existente de AWS S3 Terraform, el almacén de objetos está completamente impulsado por MinIO de producción de nivel empresarial.
Ahora tenemos todos los componentes básicos listos para que usted tenga un almacenamiento de objetos de nivel de producción y un control total de toda la infraestructura. A continuación, migraremos los datos que ya están en S3.
Hay varias formas de migrar sus datos de AWS S3 a MinIO, pero la que recomendamos es usar mc
.
mc mirror
es una navaja suiza de sincronización de datos. Puede copiar objetos de almacenes de objetos compatibles con S3 o S3-API y reflejarlos en MinIO. Uno de los casos de uso más populares de esto es reflejar un depósito de Amazon S3 en MinIO para exponer datos a aplicaciones y servicios que no son de AWS.
Cree una nueva política de IAM con una clave de acceso y una clave secreta, permitiendo el acceso solo a nuestro depósito. Guarde las credenciales generadas para el siguiente paso.
/opt/minio-binaries/mc alias set s3 https://s3.amazonaws.com BKIKJAA5BMMU2RHO6IBB V7f1CwQqAcwo80UEIJEjc5gVQUSSx5ohQ9GSrr12 --api S3v4
Utilice mc mirror para copiar los datos de S3 a MinIO
mc mirror s3/mybucket minio1/testbucket
Dependiendo de la cantidad de datos, las velocidades de la red y la distancia física desde la región donde se almacenan los datos del depósito, es posible que le lleve unos minutos o más reflejar todos los datos. Verá un mensaje cuando mc
termine de copiar todos los objetos.
Una vez que se copian los datos o mientras se copian, enumere el contenido del depósito en el sitio minio2
. Notarás que algunos de los datos ya están ahí desde minio1
.
/opt/minio-binaries/mc ls minio2/testbucket [2022-12-19 18:52:09 UTC] 3.0KiB STANDARD all_object s
En última instancia, la computadora portátil desde donde ejecuta mc mirror
es un cuello de botella porque los datos tienen que atravesar el sistema donde se ejecuta el comando mc mirror
. Podrían tratarse de varios petabytes de datos que podrían tardar días, si no semanas, en migrarse, dependiendo de la velocidad de la red. Para migrar datos de S3 a MinIO, existe un método más eficiente llamado replicación por lotes. Consulte Cómo repatriar de AWS S3 a MinIO para obtener más información sobre la replicación por lotes y otras mejores prácticas de migración.
Esta publicación de blog demostró que MinIO ejecutándose en SSD Equinix Metal NVMe, en una configuración de replicación de sitio a sitio, le brindará el mismo nivel, si no más, de rendimiento, durabilidad de datos y resiliencia a una fracción del costo de S3 mientras conservando el control total sobre su nube.
¿Tienes el 100% de control de toda la infraestructura? No exactamente. Equinix administra los conmutadores, enrutadores y otros equipos de red, pero las ventajas de estar en su red superan las desventajas. Puede obtener circuitos punto a punto, WAN u otros circuitos dedicados para conectarse virtualmente a cualquier otro proveedor. En esencia, puede tener un circuito privado conectado directamente a AWS (a través de Equinix Connect) y luego puede mover sus datos 10 veces más rápido, y al mismo tiempo ser seguro porque no atraviesa la Internet pública abierta y solo pasan sus datos. ese circuito.
Además, los puntos de referencia de MinIO muestran repetidamente muy poca degradación del rendimiento del rendimiento (<1%) con el cifrado activado; por lo tanto, recomendamos que todas las implementaciones de MinIO utilicen cifrado en reposo y que todas las implementaciones de MinIO también protejan las comunicaciones de red mediante TLS. Felicitaciones, ahora sus datos están en un sistema más seguro, pero transparente, donde usted tiene total control y responsabilidad.
Si tiene alguna pregunta sobre la migración de AWS S3 a MinIO en Equinix Metal, asegúrese de comunicarse con nosotros en Slack .
También publicado aquí .