##
We are going to make the following changes to the Object Store docs as
part of a larger QC/Content pass:
### Left Navigation
We want to modify the left navigation flow to be a natural progression
from a basic setup to more advanced.
For example:
- Core Concepts
- Deployment Architecture
- Availability and Resiliency
- Erasure Coding and Object Healing
- Object Scanner
- Site Replication and Failover
- Thresholds and Limits
- Installation
- Deployment Checklist
- Deploy MinIO on Kubernetes
- Deploy MinIO on Red Hat Linux
- Deploy MinIO on Ubuntu Linux
- Deploy MinIO for Development (MacOS, Windows, Container)
- Security and Encryption (Conceptual Overview)
- Network Encryption (TLS) (Conceptual overview)
- Enable Network Encryption using Single Domain
- Enable Network Encryption using Multiple Domains
- Enable Network Encryption using certmanager (Kubernetes only)
- Data Encryption (SSE) (Conceptual overview)
- Enable SSE using AIStor Key Management Server
- Enable SSE using KES (Summary page + linkouts)
- External Identity Management (Conceptual Overview)
- Enable External Identity management using OpenID
- Enable External Identity management using AD/LDAP
- Backup and Recovery
- Create a Multi-Site Replication Configuration
- Recovery after Hardware Failure
- Recover after drive failure
- Recover after node failure
- Recover after site failure
- Monitoring and Alerts
- Metrics and Alerting (v3 reference)
- Monitoring and Alerting using Prometheus
- Monitoring and Alerting using InfluxDB
- Monitoring and Alerting using Grafana
- Metrics V2 Reference
- Publish Server and Audit Logs to External Services
- MinIO Healthcheck API
The Administration, Developer, and Reference sections will remain as-is
for now.
http://192.241.195.202:9000/staging/singleplat/mindocs/index.html
# Goals
Maintaining multiple platforms is getting to be too much, and based on
analytics the actual number of users taking advantage of it is minimal.
Furthermore, the majority of traffic is to installation pages.
Therefore we're going to try to collapse back into a single MinIO Object
Storage product, and use simple navigation and on-page selectors to
handle Baremetal vs Kubernetes.
This may also help to eventually stage us to migrate to Hugo + Markdown
---------
Co-authored-by: Daryl White <53910321+djwfyi@users.noreply.github.com>
Co-authored-by: Rushan <rushenn@minio.io>
Co-authored-by: rushenn <rushenn123@gmail.com>
12 KiB
Migrate from Gateway or Filesystem Mode
minio
Table of Contents
Background
The MinIO Gateway and the related filesystem mode entered a feature freeze in July 2020. In February 2022, MinIO announced the deprecation of the MinIO Gateway. Along with the deprecation announcement, MinIO also announced that the feature would be removed in six months time.
As of RELEASE.2022-10-29T06-21-33Z, the MinIO
Gateway and the related filesystem mode code have been removed.
Deployments still using the standalone or
filesystem MinIO modes that upgrade to
MinIO Server RELEASE.2022-10-29T06-21-33Z or later
receive an error when attempting to start MinIO.
Overview
To upgrade to the RELEASE.2022-10-29T06-21-33Z or later
release, those who were using the standalone or filesystem deployment modes must create a new
Single-Node Single-Drive <minio-snsd> deployment
and migrate settings and content to the new deployment.
This document outlines the steps required to successfully launch and migrate to a new deployment.
Important
Standalone/file system mode continues to work on any release up to and including MinIO Server RELEASE.2022-10-24T18-35-07Z. To continue using a standalone deployment, install that MinIO Server release with MinIO Client RELEASE.2022-10-29T10-09-23Z or any earlier release with its corresponding MinIO Client. Note that the version of the MinIO Client should be newer and as close as possible to the version of the MinIO server.
Filesystem mode deployments must be on at least RELEASE.2022-06-25T15-50-16Z to use the MinIO Client import and export commands. Filesystem mode deployments up to and including RELEASE.2022-06-20T23-13-45Z can be migrated by manually recreating users, policies, buckets, and other resources on the new deployment.
Procedure
Note
You can set MinIO configuration settings in environment variables and
using mc admin config set <mc admin config set>.
Depending on your current deployment setup, you may need to retrieve the
values for both.
You can examine any runtime settings using
env | grep MINIO_ or, for deployments using MinIO's systemd
service, check the contents of /etc/default/minio.
For filesystem mode deployments:
If needed, upgrade the existing deployment.
The oldest acceptable versions are:
- MinIO RELEASE.2022-06-25T15-50-16Z
- MinIO Client RELEASE.2022-06-26T18-51-48Z
The newest acceptable versions are:
- MinIO RELEASE.2022-10-24T18-35-07Z
- MinIO Client RELEASE.2022-10-29T10-09-23Z
Create a new Single-Node Single-Drive MinIO deployment.
Follow our
installation instructions <deploy-minio-standalone>for your OS of choice and configure the installation as a Single-Node Single-Drive (SNSD) topology.The location of the deployment can be any empty folder on the storage medium of your choice. A new folder on the same drive can work for the new deployment as long as the existing deployment is not on the root of a drive. If the existing standalone system points to the root of the drive, you must use a separate drive for the new deployment.
If both old and new deployments are on the same host:
Install the new deployment to a different path from the existing deployment.
Set the new deployment's Console and API ports to different ports than the existing deployment.
The following commandline options set the ports at startup:
~minio server --addressto set the API port.~minio server --console-addressto set the Console port.
For deployments managed by
systemd:- Duplicate the existing
/etc/default/minioenvironment file with a unique name. - In the new deployment's service file, update
EnvironmentFileto reference the new environment file.
- Duplicate the existing
The steps below use the
mccommand line tool from both deployments. Existing MinIO Client ismcfrom the old deployment. New MinIO Client ismcfrom the new deployment.Add an alias for the deployment created in the previous step using
mc alias setand the new MinIO Client.mc alias set NEWALIAS PATH ACCESSKEY SECRETKEY- Use the new MinIO Client.
- Replace
NEWALIASwith the alias to create for the deployment. - Replace
PATHwith the IP address or hostname and port for the new deployment. - Replace
ACCESSKEYandSECRETKEYwith the credentials you used when creating the new deployment.
Migrate settings according to the type of deployment:
- The MinIO Gateway is a stateless proxy service that provides S3 API compatibility for an array of backend storage systems.
- Filesystem mode deployments provide an S3 access layer for a single MinIO server process and single storage volume.
Gateway
Migrate configuration settings:
- If your deployment uses
environment variables <minio-server-environment-variables>for configuration settings, copy the environment variables from the existing deployment's/etc/default/miniofile to the same file in the new deployment. -
You may omit any
MINIO_CACHE_*andMINIO_GATEWAY_SSEenvironment variables, as these are no longer used.
If you use
mc admin config set <mc admin config set>for configuration settings, duplicate the existing settings for the new deployment using the new MinIO Client.Filesystem mode
Note
The following Filesystem mode steps presume the existing MinIO Client supports the needed export commands.
If it does not, recreate users, policies, lifecycle rules, and buckets manually on the new deployment using the new MinIO Client.
Export the existing deployment's configurations.
Use the
mc admin config export <mc admin config export>command with the existing MinIO Client to retrieve the configurations defined for the existing standalone MinIO deployment.mc admin config export ALIAS > config.txt- Use the existing MinIO Client.
- Replace
ALIASwith the alias used for the existing standalone deployment you are retrieving values from.
Import configurations from the existing standalone deployment to the new deployment with the new MinIO Client.
mc admin config import ALIAS < config.txt- Use the new MinIO Client.
- Replace
ALIASwith the alias for the new deployment.
- If
~mc admin config importreports an error for a configuration key, comment it out with#at the beginning of the relevant line and try again. -
When you are finished migrating the deployment, verify the current syntax for the target MinIO Server version and set any needed keys manually using
mc admin config set.
Restart the server for the new deployment with the new MinIO Client.
mc admin service restart ALIAS- Use the new MinIO Client.
- Replace
ALIASwith the alias for the new deployment.
Export bucket metadata from the existing standalone deployment with the existing MinIO Client.
The following command exports bucket metadata from the existing deployment to a
.zipfile.The data includes:
- bucket targets
- lifecycle rules
- notifications
- quotas
- locks
- versioning
The export includes the bucket metadata only. This command does not export objects from the existing deployment.
mc admin cluster bucket export ALIAS- Use the existing MinIO Client.
- Replace
ALIASwith the alias for your existing deployment.
This command creates a
cluster-metadata.zipfile with metadata for each bucket.Import bucket metadata to the new deployment with the new MinIO Client.
The following command reads the contents of the exported bucket
.zipfile and creates buckets on the new deployment with the same configurations.mc admin cluster bucket import ALIAS cluster-metadata.zip- Use the new MinIO Client.
- Replace
ALIASwith the alias for the new deployment.
The command creates buckets on the new deployment with the same configurations as provided by the metadata in the .zip file from the existing deployment.
Export IAM settings from the existing standalone deployment to new deployment with the existing MinIO Client.
If you are using an external identity and access management provider, recreate those settings in the new deployment along with all associated policies.
Use the following command to export IAM settings from the existing deployment. This command exports:
- Groups and group mappings
- STS users and STS user mappings
- Policies
- Users and user mappings
mc admin cluster iam export ALIAS- Use the existing MinIO Client.
- Replace
ALIASwith the alias for your existing deployment.
This command creates a
ALIAS-iam-info.zipfile with IAM data.Import the IAM settings to the new deployment with the new MinIO Client.
Use the exported file to create the IAM setting on the new deployment.
mc admin cluster iam import ALIAS alias-iam-info.zip- Use the new MinIO Client.
- Replace
ALIASwith the alias for the new deployment. - Replace the name of the zip file with the name for the existing deployment's file.
Migrate bucket contents with
mc mirror.Use
mc mirrorwith the~mc mirror --preserveand~mc mirror --watchflags on the standalone deployment to move objects to the new |SNSD| deployment with the existing MinIO Clientmc mirror --preserve --watch SOURCE/BUCKET TARGET/BUCKET- Use the existing MinIO Client.
- Replace
SOURCE/BUCKETwith the alias and a bucket for the existing standalone deployment. - Replace
TARGET/BUCKETwith the alias and corresponding bucket for the new deployment.
Stop writes to the standalone deployment from any S3 or POSIX client.
Wait for
mc mirrorto complete for all buckets for any remaining operations.Stop the server for both deployments.
Restart the new MinIO deployment with the ports used for the previous standalone deployment.
Ensure you apply all environment variables and runtime configuration settings and validate the behavior of the new deployment.