0cd491c328
Updates `mc` reference docs for several releases of the MinIO Client.
- Adds missing flags to `mc admin trace`
- Updates `disk` -> `drive` throughout the docs, but not in all cases.
- Adds `--airgap flag` to `mc support profile` and `mc support perf`
commands.
- Updates the flags for `mc ilm add` command
- Adds `mc license unregister` command.
Closes #571
Closes #614
Closes #627
Closes #633
3.8 KiB
Deploy MinIO: Single-Node Single-Drive
minio
Table of Contents
The procedures on this page cover deploying MinIO in a Single-Node Single-Drive (SNSD) configuration for early development and evaluation. |SNSD| deployments provide no added reliability or availability beyond what the underlying storage volume implements (RAID, LVM, ZFS, etc.).
Starting with RELEASE.2022-06-02T02-11-04Z, MinIO
implements a zero-parity erasure coded backend for single-node
single-drive deployments. This feature allows access to erasure coding dependent features <minio-erasure-coding>
without the requirement of multiple drives.
MinIO only starts in |SNSD| mode if the
storage volume or path is empty or only contain files generated
by a previous |SNSD| deployment. See the
documentation on SNSD behavior with pre-existing data <minio-snsd-pre-existing-data>
for more information.
container
For extended development or production environments in orchestrated environments, use the MinIO Kubernetes Operator to deploy a Tenant on multiple worker nodes.
linux
For extended development or production environments, deploy MinIO in
a Multi-Node Multi-Drive (Distributed) <minio-mnmd>
topology
Important
RELEASE.2022-10-29T06-21-33Z fully removes
the deprecated
Gateway/Filesystem backends. MinIO returns an error if it starts up
and detects existing Filesystem backend files.
To migrate from an FS-backend deployment, use mc mirror or mc cp to copy your data over
to a new MinIO |SNSD| deployment. You
should also recreate any necessary users, groups, policies, and bucket
configurations on the |SNSD|
deployment.
Pre-Existing Data
MinIO startup behavior depends on the the contents of the specified storage volume or path. The server checks for both MinIO-internal backend data and the structure of existing folders and files. The following table lists the possible storage volume states and MinIO behavior:
| Storage Volume State | Behavior |
|---|---|
| Empty with no files, folders, or MinIO backend data | MinIO starts in |SNSD| mode and creates the zero-parity backend |
| Existing |SNSD| zero-parity objects and MinIO backend data | MinIO resumes in |SNSD| mode |
| Existing filesystem folders, files, but no MinIO backend data | MinIO returns an error and does not start |
Existing filesystem folders, files, and legacy "FS-mode" backend data |
MinIO returns an error and does not start RELEASE.2022-10-29T06-21-33Z |
Deploy Single-Node Single-Drive MinIO
The following procedure deploys MinIO consisting of a single MinIO server and a single drive or storage volume.
Network File System Volumes Break Consistency Guarantees
MinIO's strict read-after-write and
list-after-write consistency model requires local drive
filesystems (xfs, ext4, etc.).
MinIO cannot provide consistency guarantees if the underlying storage volumes are NFS or a similar network-attached storage volume.
For deployments that require using network-attached storage, use NFSv4 for best results.
linux
macos
container