mirror of
https://github.com/minio/docs.git
synced 2025-05-29 12:01:29 +03:00
2376fa9924
* Platformization of Data Encryption Docs: Hashicorp Pass * Platformization of Data Encryption Docs: Hashicorp Pass * Big pass, CR changes + K8s
89 lines
3.2 KiB
ReStructuredText
89 lines
3.2 KiB
ReStructuredText
.. _minio-snsd:
|
|
|
|
======================================
|
|
Deploy MinIO: Single-Node Single-Drive
|
|
======================================
|
|
|
|
.. default-domain:: minio
|
|
|
|
.. contents:: Table of Contents
|
|
:local:
|
|
:depth: 2
|
|
|
|
The procedures on this page cover deploying MinIO in a Single-Node Single-Drive (SNSD) configuration for early development and evaluation.
|
|
This mode was previously called :guilabel:`Standalone Mode` or 'filesystem' mode.
|
|
|
|
Starting with :minio-release:`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 :ref:`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 :ref:`SNSD behavior with pre-existing data <minio-snsd-pre-existing-data>` for more information.
|
|
|
|
.. cond:: container
|
|
|
|
For extended development or production environments in orchestrated environments, use the MinIO Kubernetes Operator to deploy a Tenant on multiple worker nodes.
|
|
|
|
.. cond:: linux
|
|
|
|
For extended development or production environments, deploy MinIO in a :ref:`Multi-Node Multi-Drive (Distributed) <minio-mnmd>` topology
|
|
|
|
|
|
.. _minio-snsd-pre-existing-data:
|
|
|
|
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:
|
|
|
|
.. list-table::
|
|
:header-rows: 1
|
|
:widths: 40 60
|
|
|
|
* - 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, and MinIO backend data
|
|
- MinIO resumes in the legacy filesystem ("Standalone") mode with no erasure-coding features
|
|
|
|
* - Existing filesystem folders, files, but **no** MinIO backend data
|
|
- MinIO returns an error and does not start
|
|
|
|
.. _deploy-minio-standalone:
|
|
|
|
Deploy Single-Node Single-Drive MinIO
|
|
-------------------------------------
|
|
|
|
The following procedure deploys MinIO consisting of a single MinIO server and a single drive or storage volume.
|
|
|
|
.. admonition:: Network File System Volumes Break Consistency Guarantees
|
|
:class: note
|
|
|
|
MinIO's strict **read-after-write** and **list-after-write** consistency
|
|
model requires local disk 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.
|
|
|
|
.. cond:: linux
|
|
|
|
.. include:: /includes/linux/steps-deploy-minio-single-node-single-drive.rst
|
|
|
|
.. cond:: macos
|
|
|
|
.. include:: /includes/macos/steps-deploy-minio-single-node-single-drive.rst
|
|
|
|
.. cond:: container
|
|
|
|
.. include:: /includes/container/steps-deploy-minio-single-node-single-drive.rst |