Persisting_And_Sharing.md

4. Persisting and Sharing

This chapter depicts important information about runtime artifact storage of an existing WSO2 product deployment in a container platform.

Contents

The following will be discussed in detail in the document.

• 4.1. Why do we need to store?
• 4.2. Recommended storage options for WSO2 products

Why do we need to store?

In the context of WSO2 product deployment, the need for storage of artifacts arises due to the following reasons:

• Persist created runtime artifacts

• Share created runtime artifacts across multiple instances in deployments with high availability support

For example, in WSO2 API Manager production deployment patterns, it is recommended to use a suitable storage option for the aforementioned purposes.

Following are some such scenarios.

• Persist Apache Solr-based indexed data in every Publisher and DevPortal profile instance, individually

• Persist and share API runtime artifacts (created in <APIM_HOME>/repository/deployment/server/synapse-configs) directory across multiple instances of the API Manager Gateway profile

For advanced details on persistent runtime artifacts of WSO2 API Manager, please refer to the official documentation.

Recommended storage options for WSO2 products

As highlighted in the previous section, there are numerous use cases which instigate the need for storage in WSO2 product deployments.

WSO2 recommends using the most suitable persistent storage solution depending on the scenario.

• Persist runtime artifacts of a single instance:

  For this purpose, you may use any persistent storage solution supporting either ReadWriteOnce or ReadWriteMany access modes.

• Persist and share runtime artifacts across multiple instances of a product profile

  For this purpose, you may use any persistent storage solution supporting ReadWriteMany access mode.

The following is a list of storage options using with production grade WSO2 product deployments in Kubernetes environments that have been tested along with the corresponding Kubernetes StorageClasses.

• Network File System (NFS)

  • WSO2 product Helm charts use the stable NFS Server Provisioner to render a NFS server, for the purpose of evaluation.

  • WSO2 product deployments have been tried and tested with NFS based solutions like Google FileStore (please refer to instructions for WSO2 API Manager and WSO2 Identity Server).

• Ceph File System (CephFS)

  • WSO2 product deployments have been tested with CephFS cluster deployed using the Rook Operator version 1.3. (Refer to instructions for WSO2 API Manager and WSO2 Identity Server).

• Azure Storage

  • WSO2 product deployments have been tested with Azure File storage solution (Refer to instructions for WSO2 Open Banking).