mirror of
https://github.com/minio/docs.git
synced 2025-07-28 19:42:10 +03:00
Removing missed file
This commit is contained in:
Ravind Kumar
@ -1,155 +0,0 @@
|
|||||||
.. _minio-decommissioning:
|
|
||||||
|
|
||||||
==========================
|
|
||||||
Decommission a Server Pool
|
|
||||||
==========================
|
|
||||||
|
|
||||||
.. default-domain:: minio
|
|
||||||
|
|
||||||
.. contents:: Table of Contents
|
|
||||||
:local:
|
|
||||||
:depth: 1
|
|
||||||
|
|
||||||
Starting with RELEASE, MinIO supports decommissioning and removing a
|
|
||||||
:ref:`server pools <minio-intro-server-pool>` from a deployment. Decommissioning
|
|
||||||
is designed for removing an older server pool whose hardware is no longer
|
|
||||||
sufficient or performant compared to the pools in the deployment. MinIO
|
|
||||||
automatically migrates data from the decommissioned pool to the remaining pools
|
|
||||||
in the deployment based on the ratio of free space available in each pool.
|
|
||||||
|
|
||||||
A decommissioned pool can *only* service read operations (e.g. ``GET``,
|
|
||||||
``LIST``, ``HEAD``). MinIO routes all write operations to the remaining
|
|
||||||
"active" pools in the deployment. Versioned objects maintain their ordering
|
|
||||||
throughout the migration process.
|
|
||||||
|
|
||||||
The procedure on this page decommissions and removes a server pool from
|
|
||||||
a :ref:`distributed <deploy-minio-distributed>` MinIO deployment with
|
|
||||||
*at least* two server pools.
|
|
||||||
|
|
||||||
.. admonition:: Decommissioning is Permanent
|
|
||||||
:class: important
|
|
||||||
|
|
||||||
Once MinIO begins decommissioning a pool, it marks that pool as *permanently*
|
|
||||||
inactive ("draining"). Cancelling or otherwise interrupting the
|
|
||||||
decommissioning procedure does **not** restore the pool to an active
|
|
||||||
state.
|
|
||||||
|
|
||||||
Decommissioning is a major administrative operation that requires care
|
|
||||||
in planning and execution, and is not a trivial or 'daily' task.
|
|
||||||
|
|
||||||
`MinIO SUBNET <https://min.io/pricing?jmp=docs>`__ users can
|
|
||||||
`log in <https://subnet.min.io/>`__ and create a new issue related to
|
|
||||||
decommissioning. Coordination with MinIO Engineering via SUBNET can ensure
|
|
||||||
successful decommissioning, including performance testing and health
|
|
||||||
diagnostics.
|
|
||||||
|
|
||||||
Community users can seek support on the `MinIO Community Slack
|
|
||||||
<https://minio.slack.com>`__. Community Support is best-effort only and has
|
|
||||||
no SLAs around responsiveness.
|
|
||||||
|
|
||||||
.. _minio-decommissioning-prereqs:
|
|
||||||
|
|
||||||
Prerequisites
|
|
||||||
-------------
|
|
||||||
|
|
||||||
Networking and Firewalls
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
Each node should have full bidirectional network access to every other node in
|
|
||||||
the deployment. For containerized or orchestrated infrastructures, this may
|
|
||||||
require specific configuration of networking and routing components such as
|
|
||||||
ingress or load balancers. Certain operating systems may also require setting
|
|
||||||
firewall rules. For example, the following command explicitly opens the default
|
|
||||||
MinIO server API port ``9000`` on servers using ``firewalld``:
|
|
||||||
|
|
||||||
.. code-block:: shell
|
|
||||||
:class: copyable
|
|
||||||
|
|
||||||
firewall-cmd --permanent --zone=public --add-port=9000/tcp
|
|
||||||
firewall-cmd --reload
|
|
||||||
|
|
||||||
If you set a static :ref:`MinIO Console <minio-console>` port (e.g. ``:9001``)
|
|
||||||
you must *also* grant access to that port to ensure connectivity from external
|
|
||||||
clients.
|
|
||||||
|
|
||||||
MinIO **strongly recomends** using a load balancer to manage connectivity to the
|
|
||||||
cluster. The Load Balancer should use a "Least Connections" algorithm for
|
|
||||||
routing requests to the MinIO deployment, since any MinIO node in the deployment
|
|
||||||
can receive, route, or process client requests.
|
|
||||||
|
|
||||||
The following load balancers are known to work well with MinIO:
|
|
||||||
|
|
||||||
- `NGINX <https://www.nginx.com/products/nginx/load-balancing/>`__
|
|
||||||
- `HAProxy <https://cbonte.github.io/haproxy-dconv/2.3/intro.html#3.3.5>`__
|
|
||||||
|
|
||||||
Configuring firewalls or load balancers to support MinIO is out of scope for
|
|
||||||
this procedure.
|
|
||||||
|
|
||||||
Deployment Must Have Sufficient Storage
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
The decommissioning process migrates objects from the target pool to other
|
|
||||||
pools in the deployment. The total available storage on the deployment
|
|
||||||
*must* exceed the total storage of the decommissioned pool.
|
|
||||||
|
|
||||||
For example, consider a deployment with the following distribution of
|
|
||||||
used and free storage:
|
|
||||||
|
|
||||||
.. list-table::
|
|
||||||
:stub-columns: 1
|
|
||||||
:widths: 30 30 30
|
|
||||||
:width: 100%
|
|
||||||
|
|
||||||
* - Pool 1
|
|
||||||
- 100TB Used
|
|
||||||
- 200TB Total
|
|
||||||
|
|
||||||
* - Pool 2
|
|
||||||
- 100TB Used
|
|
||||||
- 200TB Total
|
|
||||||
|
|
||||||
* - Pool 3
|
|
||||||
- 100TB Used
|
|
||||||
- 200TB Total
|
|
||||||
|
|
||||||
Decommissioning Pool 1 requires distributing the 100TB of used storage
|
|
||||||
across the remaining pools. Pool 2 and Pool 3 each have 100TB of unused
|
|
||||||
storage space and can safely absorb the data stored on Pool 1.
|
|
||||||
|
|
||||||
However, if Pool 1 were full (e.g. 200TB of used space), decommissioning would
|
|
||||||
completely fill the remaining pools and potentially prevent any further write
|
|
||||||
operations.
|
|
||||||
|
|
||||||
Decommissioning Does Not Support Tiering
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
MinIO does not support decommissioning pools in deployments with
|
|
||||||
:ref:`tiering <minio-lifecycle-management-tiering>` configured. The MinIO
|
|
||||||
server rejects decommissioning attempts if any bucket in the deployment
|
|
||||||
has a tiering configuration.
|
|
||||||
|
|
||||||
Considerations
|
|
||||||
--------------
|
|
||||||
|
|
||||||
Decommissioning Ignores Delete Markers
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
MinIO does *not* migrate objects whose only remaining version is a
|
|
||||||
:ref:`delete markers <minio-bucket-versioning-delete>`. This avoids creating
|
|
||||||
empty metadata on the remaining server pools for objects already considered
|
|
||||||
fully deleted.
|
|
||||||
|
|
||||||
Decommissioning is Resumable
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
MinIO resumes decommissioning if interrupted by deployment restarts,
|
|
||||||
failed decommissioning attempts, or manual pausing of decommissioning.
|
|
||||||
|
|
||||||
Decommissioning Requires Downtime
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
Removing a decommissioned server pool requires restarting *all* MinIO
|
|
||||||
nodes in the deployment at around the same time. This results in a
|
|
||||||
brief period of downtime. S3 SDKs typically include retry logic, such that
|
|
||||||
application impact should be minimal. You can plan for a maintenance period
|
|
||||||
during which you perform this procedure to provide additional buffer.
|
|
||||||
Reference in New Issue
Block a user