minio/docs
1
0
Fork 0
mirror of https://github.com/minio/docs.git synced 2025-08-09 13:02:53 +03:00
Code Activity

additional discussion of mismatched pool sizes

Browse Source
This commit is contained in:
Andrea Longo
2024-08-22 17:15:17 -06:00
parent a9bfde7372
commit 40606ceb7f
4 changed files with 26 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
source/operations/checklists/hardware.rst
View File

@@ -339,6 +339,9 @@ Storage
MinIO limits the maximum usable size per drive to the smallest size in the deployment.
For example, if a deployment has 15 10TB drives and 1 1TB drive, MinIO limits the per-drive capacity to 1TB.
For deployments with multiple server pools, each individual pool may have its own hardware configuration.
However, significant capacity differences between pools may temporarily result in high loads on a new pool's nodes during :ref:`expansion <expand-minio-distributed>`. For more information, see :ref:`How do I manage object distribution across a MinIO deployment? <minio-rebalance>`
Recommended Hardware Tests
--------------------------

15
source/operations/concepts.rst
View File

@@ -140,23 +140,26 @@ There are several options to manage your MinIO deployments and clusters:
How do I manage object distribution across a MinIO deployment?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MinIO optimizes storage of objects across available pools by writing new objects (that is, objects with no existing versions) to the server pool with the most free space compared total amount of free space on all available server pools.
MinIO optimizes storage of objects across available pools by writing new objects (that is, objects with no existing versions) to the server pool with the most free space compared to the total amount of free space on all available server pools.
MinIO does not perform the costly action of rebalancing objects from older pools to newer pools.
Instead, new objects typically route to the new pool as it has the most free space.
As that pool fills, new write operations eventually balance out across all pools in the deployment.
For more information on write preference calculation logic, see :ref:`Writing Files <minio-writing-files>` below.
As the new pool fills, write operations eventually balance out across all pools in the deployment.
Until then, the new pool's nodes may experience higher loads and slower writes.
To reduce this temporary performance impact, MinIO recommends expanding a deployment well before its existing pools are near capacity and with new pools of a similar size.
For more information on write preference calculation logic, see :ref:`Writing Files <minio-writing-files>`.
Rebalancing data across all pools after an expansion is an expensive operation that requires scanning the entire deployment and moving objects between pools.
This may take a long time to complete depending on the amount of data to move.
MinIO does not recommend manual rebalancing.
If required, you can manually initiate a rebalancing operation across all server pools using :mc:`mc admin rebalance`.
MinIO recommends `SUBNET <https://min.io/pricing?jmp=docs>`__ users `log in <https://subnet.min.io/>`__ and create a new issue to discuss appropriate rebalancing strategies for deployments.
Rebalancing does not block ongoing operations and runs in parallel to all other I/O.
This can result in reduced performance of regular operations.
Consider scheduling rebalancing operations during non-peak periods to avoid impacting production workloads.
MinIO recommends `SUBNET <https://min.io/pricing?jmp=docs>`__ users `log in <https://subnet.min.io/>`__ and create a new issue to discuss capacity planning or rebalancing considerations for their deployments.
How do I upload objects to MinIO?
---------------------------------

13
source/operations/install-deploy-manage/expand-minio-deployment.rst
View File

@@ -143,8 +143,7 @@ Writing Files
~~~~~~~~~~~~~
MinIO does not automatically rebalance objects across the new server pools.
Instead, MinIO performs new write operations to the pool with the most free
storage weighted by the amount of free space on the pool divided by the free space across all available pools.
Instead, MinIO performs new write operations to the pool with the most free storage weighted by the amount of free space on the pool divided by the free space across all available pools.
The formula to determine the probability of a write operation on a particular pool is
@@ -162,14 +161,14 @@ MinIO calculates the probability of a write operation to each of the pools as:
- Pool B: 20% chance (:math:`2TiB / 10TiB`)
- Pool C: 50% chance (:math:`5TiB / 10TiB`)
In addition to the free space calculation, if a write option (with parity) would bring a drive
usage above 99% or a known free inode count below 1000, MinIO does not write to the pool.
In addition to the free space calculation, if a write option (with parity) would bring a drive usage above 99% or a known free inode count below 1000, MinIO does not write to the pool.
Since a pool with more free space has a higher probability of being written to, the nodes of that pool may experience higher loads as free space equalizes.
MinIO does not recommend manual rebalancing.
If required, you can manually initiate a rebalance procedure with :mc:`mc admin rebalance`.
MinIO recommends `SUBNET <https://min.io/pricing?jmp=docs>`__ users `log in <https://subnet.min.io/>`__ and create a new issue to discuss appropriate rebalancing strategies for deployments.
MinIO recommends `SUBNET <https://min.io/pricing?jmp=docs>`__ users `log in <https://subnet.min.io/>`__ and create a new issue to discuss capacity planning or rebalancing considerations for their deployments.
For more about how rebalancing works, see :ref:`managing objects across a deployment <minio-rebalance>`.
For more about how rebalancing works see :ref:`managing objects across a deployment <minio-rebalance>`.
Likewise, MinIO does not write to pools in a decommissioning process.

13
source/reference/minio-mc-admin/mc-admin-rebalance.rst
View File

@@ -22,7 +22,7 @@ Description
.. start-mc-admin-rebalance-desc
The :mc-cmd:`mc admin rebalance` command allows starts or monitors a rebalancing operation on a MinIO deployment.
The :mc-cmd:`mc admin rebalance` command starts, stops, or monitors a rebalancing operation on a MinIO deployment.
Rebalancing redistributes objects across all pools in the deployment.
.. end-mc-admin-rebalance-desc
@@ -67,6 +67,9 @@ The :mc-cmd:`mc admin rebalance` command has the following subcommands:
* - :mc-cmd:`mc admin rebalance status`
- Outputs the current status of an in-progress rebalance operation.
* - :mc-cmd:`mc admin rebalance stop`
- Stops an in-progress rebalance operation.
Syntax
------
@@ -133,12 +136,12 @@ Syntax
Ends an in-progress rebalance job on the specified deployment.
.. admonition:: Stop may cause data loss
.. admonition:: Stopping a rebalance job on previous versions of MinIO may cause data loss
:class: warning
At this time, MinIO does not recommend stopping an in-progress rebalance job.
Interrupting rebalance may result in data loss.
A bug in MinIO prior to :minio-release:`RELEASE.2024-08-17T01-24-54Z` can overwrite objects while stopping a in-progress rebalance operation.
Interrupting rebalance on these older versions may result in data loss.
.. tab-set::
.. tab-item:: EXAMPLES