Pulsar

The Apache Pulsar microservice provides server-to-server messaging for Unified Assurance microservices.

It is a supporting microservice for all microservice pipelines and runs in the a1-messaging namespace. See Understanding Microservice Pipelines in Unified Assurance Concepts for conceptual information.

Pulsar Prerequisites

Before deploying the microservice, confirm that a microservice cluster is set up. See Microservice Cluster Setup.

Deploying Pulsar

To deploy the microservice, run the appropriate command for your environment:

For a single server with a single node replica for each pod:
```
su - assure1
export WEBFQDN=<WebFQDN> 
a1helm install <microservice-release-name> assure1/pulsar -n a1-messaging --set global.imageRegistry=$WEBFQDN --set singleNode=true
```
In the commands:
- Note that this microservice must be deployed to the a1-messaging namespace rather than a zone-specific namespace.
- <WebFQDN> is the fully-qualified domain name of the primary presentation server for the cluster.
- <microservice-release-name> is the name to use for the microservice instance. Oracle recommends using the microservice name (pulsar) unless you are deploying multiple instances of the microservice to the same cluster.
For standard high-availability deployments, deploy the microservice with the default number of node replicas (three) for each non-monitoring pod by omitting the singleNode parameter:
```
su - assure1
export WEBFQDN=<WebFQDN> 
a1helm install <microservice-release-name> assure1/pulsar -n a1-messaging --set global.imageRegistry=$WEBFQDN
```

For non-standard high-availability deployments, deploy the microservice with a custom number of node replicas by adding the targetReplicas parameter:

su - assure1
export WEBFQDN=<WebFQDN> 
a1helm install <microservice-release-name> assure1/pulsar -n a1-messaging --set global.imageRegistry=$WEBFQDN --set targetReplicas=5

For systems with 8 or more CPUs, deploy the microservice with a custom number of HTTP threads by setting the broker.configData.numHttpServerThreads and proxy.configData.httpNumThreads parameters to 16. For example:
```
su - assure1
export WEBFQDN=<WebFQDN> 
a1helm install <microservice-release-name> assure1/pulsar -n a1-messaging --set global.imageRegistry=$WEBFQDN --set-string broker.configData.numHttpServerThreads=16 --set-string proxy.configData.httpNumThreads="16" --set singleNode=true
```
If you do not set these values appropriately for your environment, Pulsar may enter a crash loop with the logs indicating insufficient threads.

You can also use the Unified Assurance UI to deploy microservices. See Deploying a Microservice by Using the UI for more information.

Changing Pulsar Configuration Parameters

When running the install command, you can optionally change default configuration parameter values by including them in the command with additional --set arguments. You can add as many additional --set arguments as you need.

For example, set a parameter described in Default Pulsar Configuration by adding --set config.<parameter_name>=<parameter_value>. For example, disable IPv4 support and use IPv6 instead by adding --set config.pulsarIPv4Stack=false.

Default Pulsar Configuration

The following table describes the default configuration parameters found in the Helm chart under config for the microservice.

Name	Possible Values	Default Value	Notes
bookkeeperEnsemble	int	When singleNode is set to true, the default is 1. When singleNode is set to false, the value for replicaCount is used. If you specify a value when deploying the microservice, that value is used.	The number of BookKeeper bookies.
bookkeeperWriteQuorum	int	When singleNode is set to true, the default is 1. When singleNode is set to false, the value for replicaCount is used. If you specify a value when deploying the microservice, that value is used.	The replication factor for BookKeeper entries.
bookkeeperAckQuorum	int	When singleNode is set to true, the default is 1. When singleNode is set to false, the value for replicaCount is used. If you specify a value when deploying the microservice, that value is used.	The number of guaranteed BookKeeper copies (number of acks in a complete write).
pulsarIPv4Stack	bool	true	Whether to use IPv4 (true) or IPv6 (false).

Restarting Pulsar Workloads

When you restart Pulsar, run the following commands as the assure1 user to restart the Pulsar workloads in this order:

Restart ZooKeeper and wait for the rollout to complete:

a1k -n a1-messaging rollout restart sts/pulsar-zookeeper
a1k -n a1-messaging rollout status sts/pulsar-zookeeper --timeout=5m

Restart BookKeeper and wait for the rollout to complete:

a1k -n a1-messaging rollout restart sts/pulsar-bookie
a1k -n a1-messaging rollout status sts/pulsar-bookie --timeout=5m

Restart the broker and wait for the rollout to complete:

a1k -n a1-messaging rollout restart sts/pulsar-broker
a1k -n a1-messaging rollout status sts/pulsar-broker --timeout=5m

Restart the proxy and wait for the rollout to complete:

a1k -n a1-messaging rollout restart sts/pulsar-proxy
a1k -n a1-messaging rollout status sts/pulsar-proxy --timeout=5m

Restart recovery and wait for the rollout to complete:

a1k -n a1-messaging rollout restart sts/pulsar-recovery
a1k -n a1-messaging rollout status sts/pulsar-recovery --timeout=5m

Restart the toolset and wait for the rollout to complete:

a1k -n a1-messaging rollout restart sts/pulsar-toolset
a1k -n a1-messaging rollout status sts/pulsar-toolset --timeout=5m

Note:

The --timeout=5m option tells a1k to wait up to 5 minutes for the rollout to complete. The command returns earlier if the rollout completes before the timeout. You can increase the timeout value for larger or slower environments. If a rollout times out, do not continue with the next Pulsar workload until you investigate and resolve the issue.

Title and Copyright Information

Implementation Guide

G49441-03