With your business application deployed to a correctly-configured AMI instance, the next step is to establish monitoring of the platform via JBoss Operations Network (JON). This is optional, of course, but recommended since the infrastructure is off-premises. The JON server is commonly located inside a corporate network, so it's necessary to establish a secure connection between the server and each of its agents. Establishing a VPN between the two points is the most common solution to this but this complicates the required networking configuration.
This chapter provides network configuration guidelines for enabling communication between the JON agent and JON server. For more extensive information on JBoss Operations Network's configuration, management and usage refer to the Red Hat documentation.
Connectivity Requirements
Registering a JON agent with its servers requires two-way communication between agent and servers. The JON Agent needs access to port 7080 (or 7443 in case SSL is used) on all JON servers, and each JON server must be able to access each of the connected agents on a unique IP:TCP port pair (agent port is usually 16163). If there are multiple, clustered JON servers, make sure each agent can communicate with all servers in the JON cluster via the IPs/hostname pairs as configured through the JON server administration console. The JON server used by the agent to register may not be the server it tries to use after initialization.
Network Address Translation (NAT)
A corporate VPN gateway acting in routed mode greatly simplifies network configuration. However, if the corporate VPN gateway is acting in NAT mode, the JON server does not have direct visibility of agents. Port forwarding needs to be configured so that for each agent, one port on the gateway is forwarded to the JON agent's address or port on the managed machine. The JON agent also needs to be configured to tell the server the forwarded port number and IP address (see rhq.communications.connector.* description in agent-configuration.xml for more information).
DNS
JON servers and JON agents need to be able to resolve each others' hostnames but DNS resolution is complicated in a VPN configuration. Connected servers can use the Amazon EC2 DNS servers, the corporate network's DNS servers or use a split DNS configuration where the corporate DNS servers are used for resolving names in particular domains and the Amazon EC2 DNS servers are used for resolving all other names.
Routing in EC2
All EC2 server have, by default, activated a "source/destination checking" routing feature. This feature drops any packets to the server which have a destination different from the machine's IP address. If the VPN solution selected for connecting agents to the JON Server includes a router, this feature needs to be turned off for the server(s) acting as routers/VPN gateways. This configuration setting can be accessed via the Amazon AWS console by right-clicking on the instance. Disabled source/destination checking is also required in a Virtual Private Cloud (VPC).
Some VPN configurations, by default, route traffic intended for the Internet through the corporate VPN. Avoid this for EC2 instances because it's generally much slower and less efficient.
A concern not specific to JON (but still can affect it) is the use of a proper addressing schema. Amazon EC2 assigns IP addresses from the 10.0.0.0/8 network. Instances usually have a public IP address also but only network traffic on the internal IP address within the same availability zone is free. To avoid using the 10.0.0.0/8 network in private addressing, there are a few things to consider:
-
When creating a VPC, avoid allocating addresses already in use in the private network to avoid connectivity problems;
-
If an instance needs access to availability zone local resources, make sure EC2 private addresses are used and traffic is not routed through the VPN;
-
If and EC2 instance will access a small subset of corporate private network addresses (for example only JON servers), only these addresses should be routed through the VPN for increased security and a lower chance of EC2/private network address space collisions.
Terminating and restarting instances
In a cloud environment it is very easy to terminate an instance and, when needed later, launch a new instance identical to the initial one. There is a potential problem if a new instance tries to register with JON server using the same agent name as a previously running agent. In this case the JON server will not allow an agent to reconnect with a missing or non-matching identification token. Make sure that terminated agents are removed from the JON inventory before trying to connect an agent with the same name or specify the correct identification token when starting new agent.
Another problem is when an agent machine is assigned a new VPN IP address (i.e. machine is restarted or VPN connection is terminated). Refer to "Configuring JBoss ON Servers and Agents Guide" for instructions on how to change the agent's IP address. If this does happen it's best to bind the JON agent's lifecycle to the VPN connection's lifecycle. When the connection drops, stop the agent. When connection is back up, then update JON_AGENT_ADDR in /etc/sysconfig/jon-agent-ec2 to reflect the new IP and restart the agent.
With a high number of instances launched or terminated it can become impractical to add/remove them manually from the JON inventory. JON's scripting capabilities can be used for automate these steps. Refer to the JON documentation for further information.
VPC example
private corporate network:
many subnets: ...
JON server (10.0.7.12)
JON server (10.0.5.12)
VPC:
public subnet (10.1.15.0/24,ACL to allow all in/out connections, route to JON servers through VPN):
NAT instance/VPN gateway/mod_cluster machine + elastic IP + disable source/dest checking + setup proper routing to JON servers
other machines managed by JON with elastic IPs...
private subnet (10.1.16.0/24, ACL to allow all in/out connections, route to Internet through the VPN gateway instance):
EAP cluster
private subnet (10.1.17.0/24, ACL to allow all in/out connections, route to Internet through the VPN gateway instance):
some other EC2 machines managed by JON
* 10.1.15.0, 10.1.16.0 and 10.1.17.0 networks are not allocated in the private corporate network