3203cf7c3e
No related issue here, just freewheeling from an internal request. This started with the request to change our recommendation around label/uuid-based drive mounting to a requirement. Looking at the pages I feel like our pre-req and considerations are a little long in the tooth, and are at least slightly duplicative of what is on the checklist pages (hardware, software) This is at least a first swing at tidying things up. I think in a second pass I'll move more of the pre-reqs into the Hardware/Software/Security checklist pages, and keep the on-tutorial sections as simple defnlists so that the page flows more easily. We can push users to the details if they want it while keeping the high level requirements there. Noting this does **not** yet address the new features related to non-sequential hostname support. That has to come later. --------- Co-authored-by: Eco <41090896+eco-minio@users.noreply.github.com> Co-authored-by: Andrea Longo <feorlen@users.noreply.github.com> Co-authored-by: Daryl White <53910321+djwfyi@users.noreply.github.com>
1.6 KiB
Deploy MinIO: Single-Node Multi-Drive
minio
Table of Contents
The procedures on this page cover deploying MinIO in a Single-Node Multi-Drive (SNMD) configuration. |SNMD| deployments provide drive-level reliability and failover/recovery with performance and scaling limitations imposed by the single node.
linux or macos or windows
For production environments, MinIO strongly recommends deploying with
the Multi-Node Multi-Drive (Distributed) <minio-mnmd>
topology for enterprise-grade performance, availability, and
scalability.
container
For production environments, MinIO strongly recommends using the MinIO Kubernetes Operator to deploy Multi-Node Multi-Drive (MNMD) or "Distributed" Tenants.
Prerequisites
Storage Requirements
Deploy Single-Node Multi-Drive MinIO
The following procedure deploys MinIO consisting of a single MinIO server and a multiple drives or storage volumes.
linux
macos
container