Deployment Scenarios

Simple Abuse Shield Deployment

The below diagram shows the logical architecture of a typical Abuse Shield deployment, with three wforce servers in a cluster.

The diagram below shows how the above architecture would be deployed in Kubernetes when OX Abuse Shield Cloud Control is used, showing the Kubernetes objects that are created:

Abuse Shield Deployment Including SyncDB

Many Abuse Shield deployments will want to make use of the SyncDB feature, which enables wforce servers to load the cluster state from another server when starting up. This is achieved with a deployment consisting of dedicated wforce pods that participate in the cluster replication, but never receive query traffic, thus they are always available to send the latest cluster state. The diagram below shows the logical architecture of deployment with that feature enabled:

The diagram below shows the Kubernetes objects that would be created when Cloud Control is used to deploy the above architecture:

Abuse Shield Deployment Including Replication Forwarder

Finally, the replication forwarder is a component that can be used to send and receive statsdb and block/allow list messages to/from other clusters. An example logical architecture including the replication forwarder is shown in the following diagram:

The replfwd component can also be deployed as part of the Kubernetes cluster; the following diagram shows the Kubernetes objects that would be created when deploying the architecture for Cluster A in the above diagram :