I quite often get this sort of scenario where customer have a requirement to deploy a Peer in a different network or in DMZ while keeping communication between CDP's and Peer in other network using NAT IP address.
Below is a high level overview of how this sort of deployment configuration which provides connectivity with an LAP located in a different network/DMZ using NAT IP address. This deployment minimizing the impact to the DMZ firewall rules. The grid is deployed in a high-availability configuration to provide redundancy for the processing peers. Inside the DMZ or Other network, a lightweight activity peers exist which can host required adapters.
Lets understand some basic concept of Peer Discover and Peer Communication which is associated with JMS broker.
Each peer is associated with a JMS broker which hosts a set of queues which is involved to send messages targeted to the respective peer. A given broker may host queues for any number of peers. The combination of broker URI and topology queue is referred to as an "advertisement".
Each peer engage and contribute in the management grid "discovery" topology, along with a subset of the peers being designed to provide discovery services to the other peers. The advertisements associated with discovery peers are persisted with each peer in the environment. Upon startup, a peer registers the advertisements for its topology with the master in the discovery topology, and periodically requests advertisements matching topology in which the peer participates.
Non discovery advertisements are never persisted and are maintained only in memory. When a peer learns about a new discovery server (this occurs when an HA CDP is added to a grid), the associated advertisement is persisted with that peer.
Most JMS configuration files are located in $AO_HOME/server/.jms
The broker-config.xml file specifies the JMS broker configuration for individual peer.
The XML document can have below nodes
- external - indicates whether the broker is hosted within this peer's VM or externally
- uri - the broker URI. This specifies the protocol, IP (or host), port, and any ActiveMQ parameters associated with the broker.
- port-upper-bound - if present, indicates that the broker port may range from the port specified in the uri up to the number provided in this element. Upon peer startup, the first available port in the range will be used
- listen-addresses — if present, this would enforce the server to listen only on the addresses specified
- advertise-addresses — if present, this would enforce the server to advertise only the addresses specified
activemq-data - a directory used by ActiveMQ
certificate- the certificate used for SSL JMS connections.
disco - a directory used to hold discovery advertisements (Ideally you will find only CDP and HACDP disco file here)
In the below mentioned example, I have a data-center in which I have a CDP, HACDP, REPO and Authentication System (AM/ASSO/RSSO) based on the version of the production in use.
My CDP 1 has an host IP Address of 10.0.0.4 and its NAT IP address is 192.168.2.103, My CDP - 2 has an host IP address of 10.0.0.5 and NAT IP Address as 192.168.2.104. Rest of my BAO components are in the same data center as CDP's expect for one LAP which is located in different location or different data center or in DMZ. My LAP has an Host IP address as 192.168.2.106.
It is possible to specify an address to advertise which can be a NAT IP other than the CDP's host IP address.
CDP Broker-config.xml (located in $AOCDPHOME\server\.jms)
<uri>ssl://CDP-IP:<Peer Communication Port>?connectionTimeout=1000</uri>
<address>NAT IP Address of CDP</address>
Note: that it is also possible to use "hostnames" in the advertise-addresses block. and further host file mapping for the hostname can be done in the individual peer.