minio/docs
1
0
Fork 0
mirror of https://github.com/minio/docs.git synced 2025-07-28 19:42:10 +03:00
Code Activity

DOCS-493: Single-Node Single-Drive XL Backend

Browse Source
This commit is contained in:
Ravind Kumar
2022-06-02 15:54:01 -04:00
committed by Ravind Kumar
parent f92582fd5a
commit bedb656de7
12 changed files with 46 additions and 93 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
source/concepts/erasure-coding.rst
View File

@ -48,6 +48,14 @@ Use the MinIO `Erasure Code Calculator
designing your MinIO deployment to explore the effect of erasure code settings designing your MinIO deployment to explore the effect of erasure code settings
on your intended topology. 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: .. _minio-ec-erasure-set:
Erasure Sets Erasure Sets

3
source/conf.py
View File

@ -145,5 +145,8 @@ rst_prolog = """
.. |minio-deb| replace:: https://dl.min.io/server/minio/release/linux-amd64/minio_20220519182059.0.0_amd64.deb .. |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| replace:: `MinIO SUBNET <https://min.io/pricing?jmp=docs>`__
.. |subnet-short| replace:: `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)`
""" """

34
source/installation/deploy-minio-standalone.rst
View File

@ -1,6 +1,6 @@
=============================== =====================================
Deploy MinIO in Standalone Mode Deploy Single-Node Single-Drive MinIO
=============================== =====================================
.. default-domain:: minio .. default-domain:: minio
@ -8,22 +8,21 @@ Deploy MinIO in Standalone Mode
:local: :local:
:depth: 1 :depth: 1
The procedures on this page cover deploying MinIO in The procedures on this page cover deploying MinIO in a Single-Node Single-Drive (SNSD) configuration for early development and evaluation.
:guilabel:`Standalone Mode`. A standalone MinIO deployment consists of a single This mode was previously called :guilabel:`Standalone Mode` or 'filesystem' mode.
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>`.
For extended development or production environments, *or* to access For extended development or production environments, deploy MinIO
:ref:`advanced MinIO functionality <minio-installation-comparison>` deploy MinIO
in :guilabel:`Distributed Mode`. See :ref:`deploy-minio-distributed` for more in :guilabel:`Distributed Mode`. See :ref:`deploy-minio-distributed` for more
information. information.
Pre-Existing Data Pre-Existing Data
----------------- -----------------
When starting a new standalone MinIO server, the storage path may have existing data already grouped into directories. Starting with :minio-release:`RELEASE.2022-06-02T02-11-04Z`, MinIO implements a zero-parity erasure coded backend for single-node single-drive deployments.
MinIO displays this data as buckets and objects in the MinIO deployment. 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. - Top-level folders at the starting path become MinIO buckets.
- Files in folders within the starting path become objects within the 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 - ``file3.txt`` displays in the ``bar`` bucket
- ``file.txt`` does not display in MinIO anywhere, but remains available through the file system - ``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-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 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.
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 .. admonition:: Network File System Volumes Break Consistency Guarantees
:class: note :class: note

50
source/installation/deployment-and-management.rst
View File

@ -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 You can run MinIO on consumer or enterprise-grade hardware and a variety
of operating systems and architectures. 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: .. _minio-installation-comparison:
The following table compares the key functional differences between MinIO supports three deployment topologies:
:guilabel:`Standalone` and :guilabel:`Distributed` MinIO deployments:
.. list-table:: Single-Node Single-Drive
:header-rows: 1 A single MinIO server with a single storage volume or folder.
:widths: 20 40 40 |SNSD| deployments are best suited for evaluation and initial development of applications using MinIO for object storage.
:width: 100% This topology is also known as :guilabel:`Standalone Mode`.
* - 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.
- :guilabel:`Standalone` 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.
- :guilabel:`Distributed`
* - Site-to-Site Replication Single-Node Multi-Drive
- Client-Side via :mc:`mc mirror` 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.
- :ref:`Server-Side Replication <minio-bucket-replication>`
* - Versioning Multi-Node Multi-Drive
- No Multiple MinIO servers with at least four drives across all servers.
- :ref:`Object Versioning <minio-bucket-versioning>` The distributed |MNMD| topology supports production-grade object storage with drive and node-level availability and resiliency.
* - 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>`.
For tutorials on deploying or expanding a distributed MinIO deployment, see: For tutorials on deploying or expanding a distributed MinIO deployment, see:

9
source/installation/restore-minio.rst
View File

@ -11,11 +11,10 @@ Recover after Hardware Failure
:local: :local:
:depth: 1 :depth: 1
Distributed MinIO deployments rely on :ref:`Erasure Coding MinIO deployments rely on :ref:`Erasure Coding <minio-erasure-coding>` to provide built-in tolerance for multiple disk or node failures.
<minio-erasure-coding>` to provide built-in tolerance for multiple disk or node 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.
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 :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.
deployment while maintaining read access ("read quorum") to objects.
The following table lists the typical types of failure in a MinIO deployment The following table lists the typical types of failure in a MinIO deployment
and links to procedures for recovering from each: and links to procedures for recovering from each:

5
source/object-retention/bucket-versioning.rst
View File

@ -206,11 +206,6 @@ Tutorials
Enable Bucket Versioning 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 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 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. enable versioning on only a prefix or subset of objects in a bucket.

4
source/quickstart/container.rst
View File

@ -8,9 +8,7 @@ Quickstart for Containers
.. |OS| replace:: Docker or Podman .. |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. 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.
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`. For instructions on deploying to production environments, see :ref:`deploy-minio-distributed`.

4
source/quickstart/k8s.rst
View File

@ -8,9 +8,7 @@ Quickstart for Kubernetes
.. |OS| replace:: 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. 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.
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 production-ready :ref:`Distributed <minio-installation-comparison>` MinIO deployments on Kubernetes, use the :docs-k8s:`MinIO Kubernetes Operator <>`. For production-ready :ref:`Distributed <minio-installation-comparison>` MinIO deployments on Kubernetes, use the :docs-k8s:`MinIO Kubernetes Operator <>`.

2
source/quickstart/linux.rst
View File

@ -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. 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`. For instructions on deploying to production environments, see :ref:`deploy-minio-distributed`.
Prerequisites Prerequisites

4
source/quickstart/macos.rst
View File

@ -8,9 +8,7 @@ Quickstart for Mac OSX
.. |OS| replace:: MacOS .. |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. 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.
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`. For instructions on deploying to production environments, see :ref:`deploy-minio-distributed`.

4
source/quickstart/windows.rst
View File

@ -8,9 +8,7 @@ Quickstart for Windows
.. |OS| replace:: 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. 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.
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`. For instructions on deploying to production environments, see :ref:`deploy-minio-distributed`.

12
source/reference/minio-mc/mc-version.rst
View File

@ -154,18 +154,6 @@ object locking on a bucket or an object in that bucket automatically
enables versioning for the bucket. See enables versioning for the bucket. See
:mc:`mc retention` for more information on configuring object locking. :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 Bucket Versioning with Existing Data
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~