Disabling the Analytics subsystem on OpenShift

During maintenance of an API Connect cluster, you can shut down the Analytics subsystem by disabling the client, ingestion, and storage microservices so that those processes are not running and there is no way to reach them.

1. Back up your Analytics data as explained in Backing up and restoring the analytics database.
2. Disable shard allocation for storage.

   Disabling shard allocation is optional, but is recommended because it prevents new shards from being created for replication when a node is unavailable, and helps avoid corruption issues in full system restarts. Disable shard allocation for storage by running the following command:

   oc -n namespace exec -it storage-master|shared_pod -- curl_es _cluster/settings -XPUT -d '{"persistent":{"cluster.routing.allocation.enable":"none"}}'

   where:

   • namespace is the namespace where the Analytics subsystem is installed.
   • storage-master|shared_pod is the name of any storage-master or storage-shared pod. You can get the name of your storage pods by running the following command and substituting in the namespace where Analytics is installed:

     oc -n namespace get po

   When you disable shard allocation, the response looks like the following example:

   {"acknowledged":true,"persistent":{"cluster":{"routing":{"allocation":{"enable":"none"}}}},"transient":{}}

3. Unassociate the Analytics service from all gateway services.
   1. In Cloud Manager, click Topology.
   2. In the section for the Availability Zone that contains the Analytics service, locate the Gateway service that the Analytics service is associated with.
   3. Click and select Unassociate analytics service.

   All analytics collection will be disabled and there will be no data in either the API Manager Dashboards or third-party offloads. For more information, see Associating an analytics service with a gateway service.

4. Unregister the Analytics service from Cloud Manager:
   1. In Cloud Manager, click Topology.
   2. In the section for the Availability Zone that contains the Analytics service, locate the Analytics service and click Delete.

   For more information, see Registering an analytics service.

5. Perform a synced flush of storage.

   Flushing the storage is optional, but is recommended because it helps to avoid losing the data that was not yet written to disk. This step flushes all current index operations synchronously and attempts to write everything that is in flux to disk. Perform a synced flush of storage by running the following command:

   oc -n namespace exec -it storage-master|shared_pod -- curl_es _flush/synced -XPOST

   When you flush storage, the response looks like the following example:

   {"_shards":{"total":33,"successful":13,"failed":0},".export-status":{"total":1,"successful":1,"failed":0},".apic-config":{"total":1,"successful":1,"failed":0},".kibana-6":{"total":1,"successful":1,"failed":0},"apic-api-2020.06.19-000002":{"total":15,"successful":5,"failed":0},"apic-api-2020.06.18-1":{"total":15,"successful":5,"failed":0}}

   The operation often fails, and it is safe to rerun it multiple times until it passes and there are all "failed" counts are zero. If it continues to fail after running multiple attempts over the span of a couple minutes, you can proceed to the next step.

6. Run the following two commands to configure analytics for ingestion-only:

   $ apicup subsys set <analytics-subsystem-name> ingestion-only=true
   
   $ apicup subsys install <analytics-subsystem-name>

7. Scale the analytics-ingestion deployment down to 0 replicas by completing the following steps.
   1. Get a list of all deployments so that you can find the name of the analytics-ingestion deployment:

      $ oc get deployments -n <namespace>

   2. Scale the analytics-ingestion deployment down to 0 replicas:

      $ oc scale deployment/<analytics-ingestion-deployment-name> --replicas=0 -n <namespace>