From 8e4b9524e5886597c93479a2e2f4b73a37e709dd Mon Sep 17 00:00:00 2001 From: Ravind Kumar Date: Thu, 3 Feb 2022 19:34:18 -0500 Subject: [PATCH] Removing missed file --- source/installation/decomission-pool.rst | 155 ----------------------- 1 file changed, 155 deletions(-) delete mode 100644 source/installation/decomission-pool.rst diff --git a/source/installation/decomission-pool.rst b/source/installation/decomission-pool.rst deleted file mode 100644 index 90c704d8..00000000 --- a/source/installation/decomission-pool.rst +++ /dev/null @@ -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 ` 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 ` 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 `__ users can - `log in `__ 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 - `__. 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 ` 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 `__ -- `HAProxy `__ - -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 ` 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 `. 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. \ No newline at end of file