Availability of stored data

FNCM has self-healing capabilities. Deployments are resilient when unexpected failures occur, such as loss in dependency, node, or pod. Components can be configured for liveness and readiness so that they react to unhealthy events. For more information, see Administering.

In the context of multi-location deployments, the storage volume is replicated across the AZs so that it can be accessed from any location or the storage volume exists in a single AZ. When storage volumes are in a single AZ, a pod that starts up in a different AZ cannot access the existing state that is stored on that volume.

The AZ-scoped type of storage is more common as it is easier to implement. However, it is only suitable for use with components that provide component-level data replication outside of the volume.

In some environments, drawbacks exist to using storage providers that replicate storage volumes. In particular SDS providers, such as OpenShift Data Foundation or Portworx that run inside a network or customer's account.

The following diagram shows the implications of SDS or cross-AZ replicated storage with FNCM.

The implications are divided into the following categories:

Reduces performance as copies of data are replicated

• Components that include their own replication cause 2 copies of the data to be sent to other replicas to ensure resilience. The diagram shows the replication in green lines across the top, from left to right.
• When that data is written to the local storage volume under each instance, a replicated storage provider copies it to two other locations per volume. It results in 8 times the number of copies in total. The diagram shows the replication in green lines across the bottom.
• Typically the system must wait for each of these writes to synchronously complete before it returns control to the original caller, which reduces runtime performance.

Increased charges for network data transfer

Providers such as AWS charge for data transfer between AZs in a region. So, if the storage provider is running in the customer’s account, as with SDS providers, a direct financial benefit can be made to right-sizing the amount of replication that takes place.

SDS providers increase infrastructure and operational costs

• SDS providers require extra hardware capacity, for example for OpenShift workers, inside the customer’s account to operate the storage layer.
• The customer manages the SDS providers itself, so they have an ongoing operations personnel or a Site Reliability Engineer (SRE) cost to manage and maintain the storage layer.

SDS and replicated storage providers do offer more flexibility in terms of failover scenarios, as a replica instance can restart in one of the other AZs if an AZ fails. However, it is important to make an informed choice about the benefits and tradeoffs.

Components of FNCM that use RWX storage depend on the storage layer to replicate data across AZs or DCs to provide high availability when an AZ or DC fails. If resilience to failure is required for the environment, use replication of file storage or replication of object storage:

Replicated file storage

For deployments in AWS, EFS is provided, which FNCM support.

Replicated object storage

Use object storage as an alternative to RWX file storage. To fulfill the replicated storage requirement, Content Cortex Content Platform Engine can support the use of external object storage directly to store content such as an AWS S3 compatible endpoint. Object storage is easily replicated across AZs in a region as it is more static in nature than a live file system. Object storage is supported in AWS with AWS S3.