minio/docs

mirror of https://github.com/minio/docs.git synced 2025-04-25 17:22:39 +03:00

Adds an admonition for exclusive drive access (#1196 )

Admonition added as an include, then put in many files throughout the
docs.
Where it is included, it's the same admonition and text.

It's worth making sure where I placed the include makes sense.

Closes #1186

2024-04-25 14:19:30 -04:00

4.9 KiB

Raw Blame History

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. deployments use a zero-parity erasure coded backend that provides no added reliability or availability beyond what the underlying storage volume implements. These deployments are best suited for local testing and evaluation, or for small-scale data workloads that do not have availability or performance requirements.

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 deployment. You should also recreate any necessary users, groups, policies, and bucket configurations on the 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 mode and creates the zero-parity backend
Existing zero-parity objects and MinIO backend data	MinIO resumes in 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

Prerequisites

Storage Requirements

The following requirements summarize the minio-hardware-checklist-storage section of MinIO's hardware recommendations:

Use Local Storage

Direct-Attached Storage (DAS) has significant performance and consistency advantages over networked storage (NAS (Network Attached Storage), SAN (Storage Area Network), NFS (Network File Storage)). MinIO strongly recommends flash storage (NVMe, SSD) for primary or "hot" data.

Use XFS-Formatting for Drives

MinIO strongly recommends provisioning XFS formatted drives for storage. MinIO uses XFS as part of internal testing and validation suites, providing additional confidence in performance and behavior at all scales.

Persist Drive Mounting and Mapping Across Reboots

Use /etc/fstab to ensure consistent drive-to-mount mapping across node reboots.

Non-Linux Operating Systems should use the equivalent drive mount management tool.

Memory Requirements

RELEASE.2024-01-28T22-35-53Z

MinIO pre-allocates 2GiB of system memory at startup.

MinIO recommends a minimum of 32GiB of memory per host. See minio-hardware-checklist-memory for more guidance on memory allocation in MinIO.

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.

MinIO cannot provide consistency guarantees if the underlying storage volumes are NFS or a similar network-attached storage volume.