mirror of
https://github.com/minio/docs.git
synced 2025-07-28 19:42:10 +03:00
DOCS-493: Single-Node Single-Drive XL Backend
This commit is contained in:
Ravind Kumar
committed by
Ravind Kumar
Ravind Kumar
parent
f92582fd5a
commit
bedb656de7
@ -48,6 +48,14 @@ Use the MinIO `Erasure Code Calculator
|
||||
designing your MinIO deployment to explore the effect of erasure code settings
|
||||
on your intended topology.
|
||||
|
||||
Zero-Parity Deployments
|
||||
-----------------------
|
||||
|
||||
Starting with :minio-release:`RELEASE.2022-06-02T02-11-04Z`, MinIO supports a Single-Node Single-Drive (SNSD) topology with a zero-parity erasure coding backend.
|
||||
This provides access to erasure coding features while deferring any and all drive-level resiliency to the underlying storage volume.
|
||||
|
||||
Zero-parity deployments necessarily depend on the underlying storage for resiliency and availability. Erasure Coding protections and behavior do not apply to |SNSD| deployments.
|
||||
|
||||
.. _minio-ec-erasure-set:
|
||||
|
||||
Erasure Sets
|
||||
|
||||
@ -145,5 +145,8 @@ rst_prolog = """
|
||||
.. |minio-deb| replace:: https://dl.min.io/server/minio/release/linux-amd64/minio_20220519182059.0.0_amd64.deb
|
||||
.. |subnet| replace:: `MinIO SUBNET <https://min.io/pricing?jmp=docs>`__
|
||||
.. |subnet-short| replace:: `SUBNET <https://min.io/pricing?jmp=docs>`__
|
||||
.. |SNSD| replace:: :abbr:`SNSD (Single-Node Single-Drive)`
|
||||
.. |SNMD| replace:: :abbr:`SNMD (Single-Node Multi-Drive)`
|
||||
.. |MNMD| replace:: :abbr:`MNMD (Multi-Node Multi-Drive)`
|
||||
|
||||
"""
|
||||
@ -1,6 +1,6 @@
|
||||
===============================
|
||||
Deploy MinIO in Standalone Mode
|
||||
===============================
|
||||
=====================================
|
||||
Deploy Single-Node Single-Drive MinIO
|
||||
=====================================
|
||||
|
||||
.. default-domain:: minio
|
||||
|
||||
@ -8,22 +8,21 @@ Deploy MinIO in Standalone Mode
|
||||
:local:
|
||||
:depth: 1
|
||||
|
||||
The procedures on this page cover deploying MinIO in
|
||||
:guilabel:`Standalone Mode`. A standalone MinIO deployment consists of a single
|
||||
MinIO server process with a single drive or storage volume ("filesystem mode").
|
||||
The MinIO server provides an S3 access layer to the drive or volume and stores
|
||||
objects as-is without any :ref:`erasure coding <minio-erasure-coding>`.
|
||||
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.
|
||||
|
||||
For extended development or production environments, *or* to access
|
||||
:ref:`advanced MinIO functionality <minio-installation-comparison>` deploy MinIO
|
||||
For extended development or production environments, deploy MinIO
|
||||
in :guilabel:`Distributed Mode`. See :ref:`deploy-minio-distributed` for more
|
||||
information.
|
||||
|
||||
Pre-Existing Data
|
||||
-----------------
|
||||
|
||||
When starting a new standalone MinIO server, the storage path may have existing data already grouped into directories.
|
||||
MinIO displays this data as buckets and objects in the MinIO deployment.
|
||||
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.
|
||||
The specified data volume or folder *must* be empty *or* only contain files generated by a previous |SNSD| deployment.
|
||||
|
||||
Starting MinIO against a folder with existing filesystem data (e.g. not MinIO-created or managed) retains the legacy filesystem behavior. Specifically:
|
||||
|
||||
- Top-level folders at the starting path become MinIO buckets.
|
||||
- Files in folders within the starting path become objects within the MinIO buckets.
|
||||
@ -47,17 +46,14 @@ When you deploy the server with a starting path of ``/data``, MinIO displays the
|
||||
- ``file3.txt`` displays in the ``bar`` bucket
|
||||
- ``file.txt`` does not display in MinIO anywhere, but remains available through the file system
|
||||
|
||||
On a standalone deployment with a single drive, you can manage buckets and objects with the :ref:`Console <minio-console>`, :ref:`command line client <minio-client>`, or create and delete files and folders directly in the starting path folders.
|
||||
|
||||
A MinIO deployment in filesystem mode does *not* support any :ref:`erasure coding features <minio-erasure-coding>` such as versioning or object locking.
|
||||
|
||||
.. _deploy-minio-standalone:
|
||||
|
||||
Deploy Standalone MinIO on Baremetal
|
||||
------------------------------------
|
||||
Deploy Single-Node Single-Drive MinIO on Baremetal
|
||||
--------------------------------------------------
|
||||
|
||||
The following procedure deploys MinIO in :guilabel:`Standalone Mode` consisting
|
||||
of a single MinIO server and a single drive or storage volume. Standalone
|
||||
deployments are best suited for evaluation and initial development environments.
|
||||
The following procedure deploys MinIO consisting of a single MinIO server and a single drive or storage volume. Standalone deployments are best suited for evaluation and initial development environments.
|
||||
|
||||
.. admonition:: Network File System Volumes Break Consistency Guarantees
|
||||
:class: note
|
||||
|
||||
@ -14,50 +14,24 @@ MinIO is a software-defined high performance distributed object storage server.
|
||||
You can run MinIO on consumer or enterprise-grade hardware and a variety
|
||||
of operating systems and architectures.
|
||||
|
||||
MinIO supports two deployment modes: :guilabel:`Standalone` and
|
||||
:guilabel:`Distributed`:
|
||||
|
||||
Standalone Deployments
|
||||
A single MinIO server with a single storage volume or folder. Standalone deployments are best suited for evaluation and initial development of applications using MinIO for object storage, *or* for providing an S3 access layer to single storage volume. Standalone deployments do not provide access to the full set of MinIO's advanced S3 features and functionality - specifically those dependent on :ref:`Erasure Coding <minio-erasure-coding>`.
|
||||
|
||||
Distributed Deployments
|
||||
One or more MinIO servers with *at least* four total storage volumes across all servers. Distributed deployments are best for production environments and workloads and support all of MinIO's core and advanced S3 features and functionality.
|
||||
|
||||
MinIO recommends a baseline topology of 4 nodes with 4 drives each for production environments.
|
||||
|
||||
.. _minio-installation-comparison:
|
||||
|
||||
The following table compares the key functional differences between
|
||||
:guilabel:`Standalone` and :guilabel:`Distributed` MinIO deployments:
|
||||
MinIO supports three deployment topologies:
|
||||
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
:widths: 20 40 40
|
||||
:width: 100%
|
||||
Single-Node Single-Drive
|
||||
A single MinIO server with a single storage volume or folder.
|
||||
|SNSD| deployments are best suited for evaluation and initial development of applications using MinIO for object storage.
|
||||
This topology is also known as :guilabel:`Standalone Mode`.
|
||||
|
||||
* -
|
||||
- :guilabel:`Standalone`
|
||||
- :guilabel:`Distributed`
|
||||
Starting with :minio-release:`RELEASE.2022-06-02T02-11-04Z`, |SNSD| deployments implement a zero-parity erasure coding backend and includes support for erasure-coding dependent features.
|
||||
This new feature is incompatible with the older filesystem-style behavior where MinIO acted as a simple S3 API layer while allowing POSIX-style access to managed files.
|
||||
|
||||
* - Site-to-Site Replication
|
||||
- Client-Side via :mc:`mc mirror`
|
||||
- :ref:`Server-Side Replication <minio-bucket-replication>`
|
||||
Single-Node Multi-Drive
|
||||
A single MinIO server with four or more storage volumes. |SNMD| deployments provide drive-level reliability and failover only and are best suited for early development or small-scale storage with minimal uptime requirements.
|
||||
|
||||
* - Versioning
|
||||
- No
|
||||
- :ref:`Object Versioning <minio-bucket-versioning>`
|
||||
|
||||
* - Retention
|
||||
- No
|
||||
- :ref:`Write-Once Read-Many Locking <minio-bucket-locking>`
|
||||
|
||||
* - High Availability / Redundancy
|
||||
- Drive Level Only (RAID and similar)
|
||||
- :ref:`Erasure Coding <minio-erasure-coding>`
|
||||
|
||||
* - Scaling
|
||||
- No
|
||||
- :ref:`Server Pool Expansion <expand-minio-distributed>`.
|
||||
Multi-Node Multi-Drive
|
||||
Multiple MinIO servers with at least four drives across all servers.
|
||||
The distributed |MNMD| topology supports production-grade object storage with drive and node-level availability and resiliency.
|
||||
|
||||
For tutorials on deploying or expanding a distributed MinIO deployment, see:
|
||||
|
||||
|
||||
@ -11,11 +11,10 @@ Recover after Hardware Failure
|
||||
:local:
|
||||
:depth: 1
|
||||
|
||||
Distributed MinIO deployments rely on :ref:`Erasure Coding
|
||||
<minio-erasure-coding>` to provide built-in tolerance for multiple disk or node
|
||||
failures. Depending on the deployment topology and the selected erasure code
|
||||
parity, MinIO can tolerate the loss of up to half the drives or nodes in the
|
||||
deployment while maintaining read access ("read quorum") to objects.
|
||||
MinIO deployments rely on :ref:`Erasure Coding <minio-erasure-coding>` to provide built-in tolerance for multiple disk or node failures.
|
||||
Depending on the deployment topology and the selected erasure code parity, MinIO can tolerate the loss of up to half the drives or nodes in the deployment while maintaining read access ("read quorum") to objects.
|
||||
|
||||
:ref:`Single-Node Single-Drive <minio-installation-comparison>` deployments are zero-parity and depend on the underlying storage volume to provide recovery. Ensure the storage volume has the necessary resiliency settings and defer to the tools or software associated to that volume for recovery.
|
||||
|
||||
The following table lists the typical types of failure in a MinIO deployment
|
||||
and links to procedures for recovering from each:
|
||||
|
||||
@ -206,11 +206,6 @@ Tutorials
|
||||
Enable Bucket Versioning
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. note::
|
||||
|
||||
Versioning requires :ref:`erasure coding <minio-erasure-coding>` and is only
|
||||
available on :ref:`distributed MinIO deployments <deploy-minio-distributed>`.
|
||||
|
||||
You can enable versioning using the MinIO Console, the MinIO :mc:`mc` CLI, or
|
||||
using an S3-compatible SDK. Versioning is a bucket-scoped feature. You cannot
|
||||
enable versioning on only a prefix or subset of objects in a bucket.
|
||||
|
||||
@ -8,9 +8,7 @@ Quickstart for Containers
|
||||
|
||||
.. |OS| replace:: Docker or Podman
|
||||
|
||||
This procedure deploys a :ref:`Standalone <minio-installation-comparison>` MinIO server onto |OS| for early development and evaluation of MinIO Object Storage and it's S3-compatible API layer.
|
||||
|
||||
Standalone deployments (also called "filesystem mode") support a :ref:`subset of MinIO features <minio-installation-comparison>` where redundancy or availability are dependent entirely on the underlying drive or volume.
|
||||
This procedure deploys a :ref:`Single-Node Single-Drive <minio-installation-comparison>` MinIO server onto |OS| for early development and evaluation of MinIO Object Storage and it's S3-compatible API layer.
|
||||
|
||||
For instructions on deploying to production environments, see :ref:`deploy-minio-distributed`.
|
||||
|
||||
|
||||
@ -8,9 +8,7 @@ Quickstart for Kubernetes
|
||||
|
||||
.. |OS| replace:: Kubernetes
|
||||
|
||||
This procedure deploys a :ref:`Standalone <minio-installation-comparison>` MinIO server onto |OS| for early development and evaluation of MinIO Object Storage and it's S3-compatible API layer.
|
||||
|
||||
Standalone deployments (also called "filesystem mode") support a :ref:`subset of MinIO features <minio-installation-comparison>` where redundancy or availability are dependent entirely on the underlying drive or volume.
|
||||
This procedure deploys a :ref:`Single-Node Single-Drive <minio-installation-comparison>` MinIO server onto |OS| for early development and evaluation of MinIO Object Storage and it's S3-compatible API layer.
|
||||
|
||||
For production-ready :ref:`Distributed <minio-installation-comparison>` MinIO deployments on Kubernetes, use the :docs-k8s:`MinIO Kubernetes Operator <>`.
|
||||
|
||||
|
||||
@ -10,8 +10,6 @@ Quickstart for Linux
|
||||
|
||||
This procedure deploys a :ref:`Standalone <minio-installation-comparison>` MinIO server onto |OS| for early development and evaluation of MinIO Object Storage and it's S3-compatible API layer.
|
||||
|
||||
Standalone deployments (also called "filesystem mode") support a :ref:`subset of MinIO features <minio-installation-comparison>` where redundancy or availability are dependent entirely on the underlying drive or volume.
|
||||
|
||||
For instructions on deploying to production environments, see :ref:`deploy-minio-distributed`.
|
||||
|
||||
Prerequisites
|
||||
|
||||
@ -8,9 +8,7 @@ Quickstart for Mac OSX
|
||||
|
||||
.. |OS| replace:: MacOS
|
||||
|
||||
This procedure deploys a :ref:`Standalone <minio-installation-comparison>` MinIO server onto |OS| for early development and evaluation of MinIO Object Storage and it's S3-compatible API layer.
|
||||
|
||||
Standalone deployments (also called "filesystem mode") support a :ref:`subset of MinIO features <minio-installation-comparison>` where redundancy or availability are dependent entirely on the underlying drive or volume.
|
||||
This procedure deploys a :ref:`Single-Node Single-Drive <minio-installation-comparison>` MinIO server onto |OS| for early development and evaluation of MinIO Object Storage and it's S3-compatible API layer.
|
||||
|
||||
For instructions on deploying to production environments, see :ref:`deploy-minio-distributed`.
|
||||
|
||||
|
||||
@ -8,9 +8,7 @@ Quickstart for Windows
|
||||
|
||||
.. |OS| replace:: Windows
|
||||
|
||||
This procedure deploys a :ref:`Standalone <minio-installation-comparison>` MinIO server onto |OS| for early development and evaluation of MinIO Object Storage and it's S3-compatible API layer.
|
||||
|
||||
Standalone deployments (also called "filesystem mode") support a :ref:`subset of MinIO features <minio-installation-comparison>` where redundancy or availability are dependent entirely on the underlying drive or volume.
|
||||
This procedure deploys a :ref:`Single-Node Single-Drive <minio-installation-comparison>` MinIO server onto |OS| for early development and evaluation of MinIO Object Storage and it's S3-compatible API layer.
|
||||
|
||||
For instructions on deploying to production environments, see :ref:`deploy-minio-distributed`.
|
||||
|
||||
|
||||
@ -154,18 +154,6 @@ object locking on a bucket or an object in that bucket automatically
|
||||
enables versioning for the bucket. See
|
||||
:mc:`mc retention` for more information on configuring object locking.
|
||||
|
||||
Bucket Versioning Requires Distributed MinIO
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
MinIO bucket versioning is available only on
|
||||
:ref:`distributed MinIO deployments <deploy-minio-distributed>`. Specifically,
|
||||
Bucket versioning requires that the MinIO deployment supports
|
||||
:ref:`erasure coding <minio-erasure-coding>` (4+ drives). Standalone
|
||||
MinIO deployments (1 drive) cannot support bucket versioning.
|
||||
|
||||
See the linked :ref:`comparison table <minio-installation-comparison>` for
|
||||
a complete list of features available only with distributed MinIO deployments.
|
||||
|
||||
Bucket Versioning with Existing Data
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
Reference in New Issue
Block a user