mirror of
https://github.com/minio/docs.git
synced 2025-07-28 19:42:10 +03:00
Final pass on platformization (#555)
This commit is contained in:
Ravind Kumar
GitHub
@ -170,7 +170,7 @@ Decommission a Server Pool
|
||||
1) Review the MinIO Deployment Topology
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The :mc-cmd:`mc admin decommission` command returns a list of all
|
||||
The :mc:`mc admin decommission` command returns a list of all
|
||||
pools in the MinIO deployment:
|
||||
|
||||
.. code-block:: shell
|
||||
@ -280,7 +280,7 @@ the next step once decommissioning is completed.
|
||||
|
||||
If :guilabel:`Status` reads as failed, you can re-run the
|
||||
:mc-cmd:`mc admin decommission start` command to resume the process.
|
||||
For persistent failures, use :mc-cmd:`mc admin console` or review
|
||||
For persistent failures, use :mc:`mc admin console` or review
|
||||
the ``systemd`` logs (e.g. ``journalctl -u minio``) to identify more specific
|
||||
errors.
|
||||
|
||||
@ -340,5 +340,5 @@ to restart the MinIO service:
|
||||
:start-after: start-nondisruptive-upgrade-desc
|
||||
:end-before: end-nondisruptive-upgrade-desc
|
||||
|
||||
Once the deployment is online, use :mc-cmd:`mc admin info` to confirm the
|
||||
Once the deployment is online, use :mc:`mc admin info` to confirm the
|
||||
uptime of all remaining servers in the deployment.
|
||||
|
||||
@ -366,208 +366,3 @@ MinIO service:
|
||||
|
||||
- :ref:`Create users and policies to control access to the deployment
|
||||
<minio-authentication-and-identity-management>`.
|
||||
|
||||
|
||||
.. _deploy-minio-distributed-recommendations:
|
||||
|
||||
Deployment Recommendations
|
||||
--------------------------
|
||||
|
||||
Minimum Nodes per Deployment
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For all production deployments, MinIO recommends a *minimum* of 4 nodes per
|
||||
:ref:`server pool <minio-intro-server-pool>` with 4 drives per server.
|
||||
With the default :ref:`erasure code parity <minio-erasure-coding>` setting of
|
||||
``EC:4``, this topology can continue serving read and write operations
|
||||
despite the loss of up to 4 drives *or* one node.
|
||||
|
||||
The minimum recommendation reflects MinIO's experience with assisting enterprise
|
||||
customers in deploying on a variety of IT infrastructures while maintaining the
|
||||
desired SLA/SLO. While MinIO may run on less than the minimum recommended
|
||||
topology, any potential cost savings come at the risk of decreased reliability.
|
||||
|
||||
Server Hardware
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
MinIO is hardware agnostic and runs on a variety of hardware architectures
|
||||
ranging from ARM-based embedded systems to high-end x64 and POWER9 servers.
|
||||
|
||||
The following recommendations match MinIO's
|
||||
`Reference Hardware <https://min.io/product/reference-hardware>`__ for
|
||||
large-scale data storage:
|
||||
|
||||
.. list-table::
|
||||
:stub-columns: 1
|
||||
:widths: 20 80
|
||||
:width: 100%
|
||||
|
||||
* - Processor
|
||||
- Dual Intel Xeon Scalable Gold CPUs with 8 cores per socket.
|
||||
|
||||
* - Memory
|
||||
- 128GB of Memory per pod
|
||||
|
||||
* - Network
|
||||
- Minimum of 25GbE NIC and supporting network infrastructure between nodes.
|
||||
|
||||
MinIO can make maximum use of drive throughput, which can fully saturate
|
||||
network links between MinIO nodes or clients. Large clusters may require
|
||||
100GbE network infrastructure to fully utilize MinIO's per-node
|
||||
performance potential.
|
||||
|
||||
* - Drives
|
||||
- SATA/SAS NVMe/SSD with a minimum of 8 drives per server.
|
||||
|
||||
Drives should be :abbr:`JBOD (Just a Bunch of Disks)` arrays with
|
||||
no RAID or similar technologies. MinIO recommends XFS formatting for
|
||||
best performance.
|
||||
|
||||
Use the same type of disk (NVMe, SSD, or HDD) with the same capacity
|
||||
across all nodes in the deployment. MinIO does not distinguish drive
|
||||
types when using the underlying storage and does not benefit from mixed
|
||||
storage types. Additionally. MinIO limits the size used per disk to the
|
||||
smallest drive in the deployment. For example, if the deployment has 15
|
||||
10TB disks and 1 1TB disk, MinIO limits the per-disk capacity to 1TB.
|
||||
|
||||
Networking
|
||||
~~~~~~~~~~
|
||||
|
||||
MinIO recommends high speed networking to support the maximum possible
|
||||
throughput of the attached storage (aggregated drives, storage controllers,
|
||||
and PCIe busses). The following table provides general guidelines for the
|
||||
maximum storage throughput supported by a given NIC:
|
||||
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
:width: 100%
|
||||
:widths: 40 60
|
||||
|
||||
* - NIC bandwidth (Gbps)
|
||||
- Estimated Aggregated Storage Throughput (GBps)
|
||||
|
||||
* - 10GbE
|
||||
- 1GBps
|
||||
|
||||
* - 25GbE
|
||||
- 2.5GBps
|
||||
|
||||
* - 50GbE
|
||||
- 5GBps
|
||||
|
||||
* - 100GbE
|
||||
- 10GBps
|
||||
|
||||
CPU Allocation
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
MinIO can perform well with consumer-grade processors. MinIO can take advantage
|
||||
of CPUs which support AVX-512 SIMD instructions for increased performance of
|
||||
certain operations.
|
||||
|
||||
MinIO benefits from allocating CPU based on the expected per-host network
|
||||
throughput. The following table provides general guidelines for allocating CPU
|
||||
for use by based on the total network bandwidth supported by the host:
|
||||
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
:width: 100%
|
||||
:widths: 40 60
|
||||
|
||||
* - Host NIC Bandwidth
|
||||
- Recommended Pod vCPU
|
||||
|
||||
* - 10GbE or less
|
||||
- 8 vCPU per pod.
|
||||
|
||||
* - 25GbE
|
||||
- 16 vCPU per pod.
|
||||
|
||||
* - 50GbE
|
||||
- 32 vCPU per pod.
|
||||
|
||||
* - 100GbE
|
||||
- 64 vCPU per pod.
|
||||
|
||||
.. _minio-k8s-production-considerations-memory:
|
||||
|
||||
Memory Allocation
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
MinIO benefits from allocating memory based on the total storage of each host.
|
||||
The following table provides general guidelines for allocating memory for use
|
||||
by MinIO server processes based on the total amount of local storage on the
|
||||
host:
|
||||
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
:width: 100%
|
||||
:widths: 40 60
|
||||
|
||||
* - Total Host Storage
|
||||
- Recommended Host Memory
|
||||
|
||||
* - Up to 1 Tebibyte (Ti)
|
||||
- 8GiB
|
||||
|
||||
* - Up to 10 Tebibyte (Ti)
|
||||
- 16GiB
|
||||
|
||||
* - Up to 100 Tebibyte (Ti)
|
||||
- 32GiB
|
||||
|
||||
* - Up to 1 Pebibyte (Pi)
|
||||
- 64GiB
|
||||
|
||||
* - More than 1 Pebibyte (Pi)
|
||||
- 128GiB
|
||||
|
||||
.. _minio-requests-per-node:
|
||||
|
||||
Requests Per Node
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can calculate the maximum number of concurrent requests per host with this formula:
|
||||
|
||||
:math:`totalRam / ramPerRequest`
|
||||
|
||||
To calculate the amount of RAM used for each request, use this formula:
|
||||
|
||||
:math:`((2MiB + 128KiB) * driveCount) + (2 * 10MiB) + (2 * 1 MiB)`
|
||||
|
||||
10MiB is the default erasure block size v1.
|
||||
1 MiB is the default erasure block size v2.
|
||||
|
||||
The following table lists the maximum concurrent requests on a node based on the number of host drives and the *free* system RAM:
|
||||
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
:width: 100%
|
||||
|
||||
* - Number of Drives
|
||||
- 32 GiB of RAM
|
||||
- 64 GiB of RAM
|
||||
- 128 GiB of RAM
|
||||
- 256 GiB of RAM
|
||||
- 512 GiB of RAM
|
||||
|
||||
* - 4 Drives
|
||||
- 1,074
|
||||
- 2,149
|
||||
- 4,297
|
||||
- 8,595
|
||||
- 17,190
|
||||
|
||||
* - 8 Drives
|
||||
- 840
|
||||
- 1,680
|
||||
- 3,361
|
||||
- 6,722
|
||||
- 13,443
|
||||
|
||||
* - 16 Drives
|
||||
- 585
|
||||
- 1,170
|
||||
- 2.341
|
||||
- 4,681
|
||||
- 9,362
|
||||
|
||||
@ -1,6 +1,12 @@
|
||||
.. The following label handles links from content to distributed MinIO in K8s context
|
||||
.. _deploy-minio-distributed:
|
||||
|
||||
.. Redirect all references to tenant topologies here
|
||||
|
||||
.. _minio-snsd:
|
||||
.. _minio-snmd:
|
||||
.. _minio-mnmd:
|
||||
|
||||
.. _minio-k8s-deploy-minio-tenant:
|
||||
|
||||
=====================
|
||||
@ -21,6 +27,9 @@ This procedure documents deploying a MinIO Tenant using the MinIO Operator Conso
|
||||
:class: no-scaled-link
|
||||
:alt: MinIO Operator Console
|
||||
|
||||
The MinIO Operator supports only the Distributed (Multi-Node Multi-Drive) MinIO topology.
|
||||
You can use basic Kubernetes YAML resource definitions to deploy Single-Node Single-Drive and Single-Node Multi-Drive topologies for local testing and evaluation as necessary.
|
||||
|
||||
The Operator Console provides a rich user interface for deploying and managing MinIO Tenants on Kubernetes infrastructure.
|
||||
Installing the MinIO :ref:`Kubernetes Operator <deploy-operator-kubernetes>` automatically installs and configures the Operator Console.
|
||||
|
||||
@ -228,7 +237,7 @@ Settings marked with an asterisk :guilabel:`*` are *required*:
|
||||
|
||||
* - :guilabel:`Memory per Node [Gi]`
|
||||
- Specify the total amount of memory (RAM) to allocate per MinIO server pod.
|
||||
See :ref:`minio-k8s-production-considerations-memory` for guidance on setting this value.
|
||||
See :ref:`minio-hardware-checklist-memory` for guidance on setting this value.
|
||||
|
||||
The Kubernetes cluster *must* have worker nodes with sufficient free RAM to match the pod request.
|
||||
|
||||
@ -374,7 +383,7 @@ This includes configuring an external IDP such as :ref:`OpenID <minio-external-i
|
||||
- Configure additional internal MinIO users for the Operator to create as part of deploying the Tenant.
|
||||
|
||||
* - :guilabel:`OpenID`
|
||||
- Configure an OpenID Connect-compatible servce as an external Identity Provider (e.g. Keycloak, Okta, Google, Facebook, Dex) to manage MinIO users.
|
||||
- Configure an OpenID Connect-compatible service as an external Identity Provider (e.g. Keycloak, Okta, Google, Facebook, Dex) to manage MinIO users.
|
||||
|
||||
* - :guilabel:`Active Directory`
|
||||
- Configure an Active Directory or OpenLDAP service as the external Identity Provider to manage MinIO users.
|
||||
|
||||
@ -152,7 +152,7 @@ Configure Site Replication
|
||||
To add additional sites beyond two, select the ``+`` button to the side of one of the Site entries.
|
||||
To remove a site previously added, select the ``-`` button to the side of the site.
|
||||
|
||||
Site replication adds a :mc-cmd:`~mc admin user svcacct` under the ``root`` user to perform replication activities.
|
||||
Site replication adds a :mc:`~mc admin user svcacct` under the ``root`` user to perform replication activities.
|
||||
|
||||
#. Select **Save**
|
||||
|
||||
@ -178,7 +178,7 @@ Configure Site Replication
|
||||
|
||||
For example, for three MinIO sites, you might create aliases ``minio1``, ``minio2``, and ``minio3``.
|
||||
|
||||
Use :mc-cmd:`mc alias set`
|
||||
Use :mc:`mc alias set`
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
@ -300,11 +300,11 @@ The new site must meet the following requirements:
|
||||
|
||||
#. Configure an alias for each site
|
||||
|
||||
To check the existing aliases, use :mc-cmd:`mc alias list`.
|
||||
To check the existing aliases, use :mc:`mc alias list`.
|
||||
|
||||
For example, for three MinIO sites, you might create aliases ``minio1``, ``minio2``, and ``minio3``.
|
||||
|
||||
Use :mc-cmd:`mc alias set`
|
||||
Use :mc:`mc alias set`
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
|
||||
@ -84,7 +84,7 @@ Use these steps to upgrade a MinIO deployment where the MinIO server process is
|
||||
|
||||
3. Validate the Upgrade
|
||||
|
||||
Use the :mc-cmd:`mc admin info` command to check that all MinIO servers are online, operational, and reflect the installed MinIO version.
|
||||
Use the :mc:`mc admin info` command to check that all MinIO servers are online, operational, and reflect the installed MinIO version.
|
||||
|
||||
4. Update MinIO Client
|
||||
|
||||
@ -104,7 +104,7 @@ Update Non-System Managed MinIO Deployments
|
||||
Use these steps to upgrade a MinIO deployment where the MinIO server process is managed outside of the system (``systemd``, ``systemctl``), such as by a user, an automated script, or some other process management tool.
|
||||
This procedure only works for systems where the user running the MinIO process has write permissions for the path to the MinIO binary.
|
||||
|
||||
The :mc-cmd:`mc admin update` command updates all MinIO server binaries in the target MinIO deployment before restarting all nodes simultaneously.
|
||||
The :mc:`mc admin update` command updates all MinIO server binaries in the target MinIO deployment before restarting all nodes simultaneously.
|
||||
The restart process typically completes within a few seconds and is *non-disruptive* to ongoing operations.
|
||||
|
||||
- For deployments managed using ``systemctl``, see
|
||||
|
||||
Reference in New Issue
Block a user