Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 2. 3scale operations and scaling

Note

This document is not intended for local installations on laptops or similar end user equipment.

This section describes operations and scaling tasks of a Red Hat 3scale API Management 2.13 installation.

Prerequisites

To carry out 3scale operations and scaling tasks, perform the steps outlined in the following sections:

2.1. Redeploying APIcast
Copia collegamento

You can test and promote system changes through the 3scale Admin Portal.

Prerequisites

  • A deployed instance of 3scale On-premises.
  • You have chosen your APIcast deployment method.

By default, APIcast deployments on OpenShift, both embedded and on other OpenShift clusters, are configured to allow you to publish changes to your staging and production gateways through the 3scale Admin Portal.

To redeploy APIcast on OpenShift:

Procedure

  1. Make system changes.
  2. In the Admin Portal, deploy to staging and test.
  3. In the Admin Portal, promote to production.

By default, APIcast retrieves and publishes the promoted update once every 5 minutes.

If you are using APIcast on the Docker containerized environment or a native installation, configure your staging and production gateways, and indicate how often the gateway retrieves published changes. After you have configured your APIcast gateways, you can redeploy APIcast through the 3scale Admin Portal.

To redeploy APIcast on the Docker containerized environment or a native installations:

Procedure

  1. Configure your APIcast gateway and connect it to 3scale On-premises.
  2. Make system changes.
  3. In the Admin Portal, deploy to staging and test.
  4. In the Admin Portal, promote to production.

APIcast retrieves and publishes the promoted update at the configured frequency.

2.2. Scaling up 3scale on-premise
Copia collegamento

As your APIcast deployment grows, you may need to increase the amount of storage available. How you scale up storage depends on which type of file system you are using for your persistent storage.

If you are using a network file system (NFS), you can scale up your persistent volume (PV) using this command: 

$ oc edit pv <pv_name>
Copy to Clipboard Toggle word wrap

If you are using any other storage method, you must scale up your persistent volume manually using one of the methods listed in the following sections.

2.2.1. Method 1: Backing up and swapping persistent volumes
Copia collegamento

Procedure

  1. Back up the data on your existing persistent volume.
  2. Create and attach a target persistent volume, scaled for your new size requirements.
  3. Create a pre-bound persistent volume claim, specify: The size of your new PVC (PersistentVolumeClaim) and the persistent volume name using the volumeName field.
  4. Restore data from your backup onto your newly created PV.

  5. Modify your deployment configuration with the name of your new PV: 

    $ oc edit dc/system-app
    Copy to Clipboard Toggle word wrap
  6. Verify your new PV is configured and working correctly.
  7. Delete your previous PVC to release its claimed resources.

2.2.2. Method 2: Backing up and redeploying 3scale
Copia collegamento

Procedure

  1. Back up the data on your existing persistent volume.
  2. Shut down your 3scale pods.
  3. Create and attach a target persistent volume, scaled for your new size requirements.
  4. Restore data from your backup onto your newly created PV.

  5. Create a pre-bound persistent volume claim. Specify:

    1. The size of your new PVC
    2. The persistent volume name using the volumeName field.
  6. Deploy your amp.yml.
  7. Verify your new PV is configured and working correctly.
  8. Delete your previous PVC to release its claimed resources.

2.2.3. Configuring 3scale on-premise deployments
Copia collegamento

The key deployment configurations to be scaled for 3scale are:

  • APIcast production
  • Backend listener
  • Backend worker

2.2.3.1. Scaling via the OCP
Copia collegamento

Via OpenShift Container Platform (OCP) using an APIManager CR, you can scale the deployment configuration either up or down.

To scale a particular deployment configuration, use the following:

  • Scale up an APIcast production deployment configuration with the following APIManager CR: 

    apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
  name: example-apimanager
spec:
  apicast:
    productionSpec:
      replicas: X
    Copy to Clipboard Toggle word wrap

  • Scale up the backend listener, backend worker, and backend cron components of your deployment configuration with the following APIManager CR: 

    apiVersion: apps.3scale.net/v1alpha1
kind: APIManager
metadata:
  name: example-apimanager
spec:
  backend:
    listenerSpec:
      replicas: X
    workerSpec:
      replicas: Y
    cronSpec:
      replicas: Z
    Copy to Clipboard Toggle word wrap

  • Set the appropriate environment variable to the desired number of processes per pod.

    • PUMA_WORKERS for backend-listener pods: 

      $ oc set env dc/backend-listener --overwrite PUMA_WORKERS=<number_of_processes>
      Copy to Clipboard Toggle word wrap

    • UNICORN_WORKERS for system-app pods: 

      $ oc set env dc/system-app --overwrite UNICORN_WORKERS=<number_of_processes>
      Copy to Clipboard Toggle word wrap

2.2.3.2. Vertical and horizontal hardware scaling
Copia collegamento

You can increase the performance of your 3scale deployment on OpenShift by adding resources. You can add more compute nodes as pods to your OpenShift cluster, as horizontal scaling or you can allocate more resources to existing compute nodes as vertical scaling.

Horizontal scaling

You can add more compute nodes as pods to your OpenShift. If the additional compute nodes match the existing nodes in your cluster, you do not have to reconfigure any environment variables.

Vertical scaling

You can allocate more resources to existing compute nodes. If you allocate more resources, you must add additional processes to your pods to increase performance.

Note

Avoid the use of computing nodes with different specifications and configurations in your 3scale deployment.

2.2.3.3. Scaling up routers
Copia collegamento

As traffic increases, ensure your Red Hat OCP routers can adequately handle requests. If your routers are limiting the throughput of your requests, you must scale up your router nodes.

2.3. Operations troubleshooting
Copia collegamento

This section explains how to configure 3scale audit logging to display on OpenShift, and how to access 3scale logs and job queues on OpenShift.

2.3.1. Configuring 3scale audit logging on OpenShift
Copia collegamento

This enables all logs to be in one place for querying by Elasticsearch, Fluentd, and Kibana (EFK) logging tools. These tools provide increased visibility on changes made to your 3scale configuration, who made these changes, and when. For example, this includes changes to billing, application plans, API configuration, and more.

Prerequisites

  • A 3scale 2.13 deployment.

Procedure

Configure audit logging to stdout to forward all application logs to standard OpenShift pod logs.

Some considerations:

  • By default, audit logging to stdout is disabled when 3scale is deployed on-premises; you need to configure this feature to have it fully functional.
  • Audit logging to stdout is not available for 3scale hosted.

2.3.2. Enabling audit logging
Copia collegamento

3scale uses a features.yml configuration file to enable some global features. To enable audit logging to stdout, you must mount this file from a ConfigMap to replace the default file. The OpenShift pods that depend on features.yml are system-app and system-sidekiq.

Prerequisites

  • You must have administrator access for the 3scale project.

Procedure

  1. Enter the following command to enable audit logging to stdout: 

    oc patch configmap system -p '{"data": {"features.yml": "features: &default\n  logging:\n    audits_to_stdout: true\n\nproduction:\n  <<: *default\n"}}'
    Copy to Clipboard Toggle word wrap

  2. Export the following environment variable: 

    export PATCH_SYSTEM_VOLUMES='{"spec":{"template":{"spec":{"volumes":[{"emptyDir":{"medium":"Memory"},"name":"system-tmp"},{"configMap":{"items":[{"key":"zync.yml","path":"zync.yml"},{"key":"rolling_updates.yml","path":"rolling_updates.yml"},{"key":"service_discovery.yml","path":"service_discovery.yml"},{"key":"features.yml","path":"features.yml"}],"name":"system"},"name":"system-config"}]}}}}'
    Copy to Clipboard Toggle word wrap

  3. Enter the following command to apply the updated deployment configuration to the relevant OpenShift pods: 

    oc patch dc system-app -p $PATCH_SYSTEM_VOLUMES
oc patch dc system-sidekiq -p $PATCH_SYSTEM_VOLUMES
    Copy to Clipboard Toggle word wrap

2.3.3. Configuring logging for Red Hat OpenShift
Copia collegamento

When you have enabled audit logging to forward 3scale application logs to OpenShift, you can use logging tools to monitor your 3scale applications.

For details on configuring logging on Red Hat OpenShift, see the following:

2.3.4. Accessing your logs
Copia collegamento

Each component’s deployment configuration contains logs for access and exceptions. If you encounter issues with your deployment, check these logs for details.

Follow these steps to access logs in 3scale:

Procedure

  1. Find the ID of the pod you want logs for: 

    oc get pods
    Copy to Clipboard Toggle word wrap

  2. Enter oc logs and the ID of your chosen pod: 

    oc logs <pod>
    Copy to Clipboard Toggle word wrap

    The system pod has two containers, each with a separate log. To access a container’s log, specify the --container parameter with the system-provider and system-developer pods: 

    oc logs <pod> --container=system-provider
oc logs <pod> --container=system-developer
    Copy to Clipboard Toggle word wrap

2.3.5. Checking job queues
Copia collegamento

Job queues contain logs of information sent from the system-sidekiq pods. Use these logs to check if your cluster is processing data. You can query the logs using the OpenShift CLI: 

oc get jobs
Copy to Clipboard Toggle word wrap 
oc logs <job>
Copy to Clipboard Toggle word wrap

2.3.6. Preventing monotonic growth
Copia collegamento

To prevent monotonic growth, 3scale schedules by default, automatic purging of the following tables:

  • user_sessions - clean up is triggered once a week, deletes records older than two weeks.
  • audits - clean up is triggered once a day, deletes records older than three months.
  • log_entries - clean up triggered once a day, deletes records older than six months.
  • event_store_events - clean up is triggered once a week, deletes records older than a week.

With the exception of the above listed table, the following table requires manual purging by the database administrator:

  • alerts
Expand
Table 2.1. SQL purging commands
Database typeSQL command

MySQL 

DELETE FROM alerts WHERE timestamp < NOW() - INTERVAL 14 DAY;
Copy to Clipboard Toggle word wrap

PostgreSQL 

DELETE FROM alerts WHERE timestamp < NOW() - INTERVAL '14 day';
Copy to Clipboard Toggle word wrap

Oracle 

DELETE FROM alerts WHERE timestamp <= TRUNC(SYSDATE) - 14;
Copy to Clipboard Toggle word wrap

Additional resources

Torna in cima
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2025 Red Hat