Wednesday, 31 August 2016

Apache Tomcat Clustering using Pacemaker on CentOS 7


Pacemaker is a High Availability cluster Software for Linux like Operating System.Pacemaker is known as ‘Cluster Resource Manager‘, It provides maximum availability of the cluster resources by doing fail over of resources between the cluster nodes.

Pacemaker use corosync for heartbeat and internal communication among cluster components , Corosync also take care of Quorum in cluster.

In this article we will demonstrate the installation and configuration of two Node Apache Tomcat Clustering using Pacemaker on CentOS 7.

Add the following to the /etc/hosts file in both nodes so that they are able to reach each other


Add the following lines in /etc/hosts file in both the nodes.
10.20.9.60       tomcat1

10.20.9.61       tomcat2

Now install the pre-requisites on both nodes

install the java on both node

#yum install -y java

# java -version

openjdk version "1.8.0_101"

OpenJDK Runtime Environment (build 1.8.0_101-b13)

OpenJDK 64-Bit Server VM (build 25.101-b13, mixed mode)

Install Pacemaker like follows on both Nodes.


#yum install -y pcs pacemaker corosync cman wget

Download and extract Apache Tomcat

#cd /opt/
#wget http://ftp.itu.edu.tr/Mirror/Apache/tomcat/tomcat-8/v8.5.4/bin/apache-tomcat-8.5.4.tar.gz

#tar -xvf apache-tomcat-8.5.4.tar.gz

Now set password for the hacluster user on both nodes

#passwd hacluster

Now start pcsd service on both nodes and add it to startup

#service pcsd start
#chkconfig pcsd on

Now authorize the cluster nodes. Will ask for username and password. Use "hacluster"

#mkdir /etc/cluster
#pcs cluster auth tomcat1 tomcat2

Now create the cluster

#pcs cluster setup --name ha_cluster tomcat1 tomcat2 

#pcs cluster start --all


Now disable STONITH and quorum as it is not required for a two node setup

#pcs property set stonith-enabled=false

#pcs property set no-quorum-policy=ignore

Now add the resources. We need a virtual IP and tomcat resource

#pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=10.20.9.62 cidr_netmask=24  op monitor interval=30s

 #pcs resource create tomcat ocf:heartbeat:tomcat params java_home="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre" catalina_home="/opt/apache-tomcat-8.5.4" tomcat_user="root" op monitor interval="15s"

Now to make both resources run in the same node we must have a constraint as follows

# pcs constraint colocation set VirtualIP tomcat

All done. Now stop the cluster and start it.

#pcs cluster stop --all

#pcs cluster start --all

# pcs status

Cluster name: ha_cluster

Last updated: Wed Aug 31 12:14:51 2016          Last change: Mon Aug 29 17:35:34 2016 by root via cibadmin on tomcat1

Stack: corosync

Current DC: tomcat2 (version 1.1.13-10.el7_2.4-44eb2dd) - partition with quorum

2 nodes and 2 resources configured

Online: [ tomcat1 tomcat2 ]

Full list of resources:

 VirtualIP      (ocf::heartbeat:IPaddr2):       Started tomcat2

 tomcat (ocf::heartbeat:tomcat):        Started tomcat2

PCSD Status:

  tomcat1: Online

  tomcat2: Online

Daemon Status:

  corosync: active/enabled

  pacemaker: active/enabled

  pcsd: active/enabled


Install and Configure Linux High-Availability Cluster tool "Pacemaker"

This example is based on the environment like follows. Configure basic cluster environment on here.

DB1:10.20.9.60(db1)

DB2:10.20.9.61(db2)

Install Pacemaker like follows on all Nodes.

[root@db1 ~]# yum -y install pacemaker pcs

[root@db1 ~]# systemctl start pcsd 

 

[root@db1 ~]# systemctl enable pcsd

# set password for cluster admin user

 

[root@db1 ~]# passwd hacluster 

Changing password for user hacluster.

New password:

Retype new password:

passwd: all authentication tokens updated successfully.

 

[2] Configure like follows on a Node.

 

# establish authorization

 

[root@db1 ~]# pcs cluster auth db1 db2 

Username: hacluster 

Password:

db1: Authorized

db2: Authorized

# configure cluster

 

[root@db1 ~]# pcs cluster setup --name ha_cluster db1 db2 

Shutting down pacemaker/corosync services...

Redirecting to /bin/systemctl stop pacemaker.service

Redirecting to /bin/systemctl stop corosync.service

Killing any remaining services...

Removing all cluster configuration files...

db1: Succeeded

db2: Succeeded

# start srvices for cluster

 

[root@db1 ~]# pcs cluster start --all 

db2: Starting Cluster...

db1: Starting Cluster...

# enable cluster

 

[root@db1 ~]# pcs cluster enable --all 

db1: Cluster Enabled

db2: Cluster Enabled

# show status

 

[root@db1 ~]# pcs status cluster

Cluster Status:

 Last updated: Wed Aug 31 11:28:19 2016         Last change: Wed Aug 31 06:17:00 2016 by root via cibadmin on db1

 Stack: corosync

 Current DC: db2 (version 1.1.13-10.el7_2.4-44eb2dd) - partition with quorum

 2 nodes and 1 resource configured

 Online: [ db1 db2 ]

PCSD Status:

  db1: Online

  db2: Online

 

 

[root@db1 ~]# pcs status corosync

Membership information

----------------------

    Nodeid      Votes Name

         1          1 db1 (local)

         2          1 db2

 

 

Wednesday, 8 July 2015

SonicWALL NAT Policy Settings


Manually opening Ports to allow Email traffic (SMTP, IMAP or POP3) from Internet to a server behind the SonicWALL in SonicOS Enhanced involves the following steps:

Step 1: Creating the necessary Address Objects
Step 2: Create a Service Group
 Step 2: Defining the appropriate NAT Policies (Inbound, Outbound and Loopback)
 Step 3: Creating the necessary WAN > Zone Access Rules for public access

Recommendation: The Public Server Wizard quickly configure your SonicWALL to provide public access to an internal server. The Public Server Wizard is the most ambitious and functional wizard developed to date. It simplifies the complex process of creating a publicly and internally accessible server resource by automating above mentioned steps.Scenario:
  The following example covers allowing Email traffic (SMTP, IMAP or POP3) service from the Internet to a server on the LAN with private IP address as 192.168.1.100.  Once the configuration is complete, Internet users can Send emails to the Email Server behind the SonicWALL UTM appliance through the WAN (Public) IP address 1.1.1.1. 




Procedure: 
In this example we have chosen to demonstrate using SMTP service, however the following steps apply to any service you wish to use (like HTTPS, SMTP, FTP, Terminal Services, SSH, etc).

Step 1: Creating the necessary Address Objects 
1. Select Network > Address Objects.
2. Click the Add a new address object button and create two address objects one for Server IP on LAN and another for Public IP of the server: 

Address Object for Server on LAN
Name: MailServer Private 
Zone Assignment: LAN  
Type: Host   
IP Address: 192.168.1.100

  
Address Object for Server's Public IP

Name: MailServer Public
Zone Assignment: WAN  
Type: Host   
IP Address: 1.1.1.1

3.Click the OK button to complete creation of the new address objects.

Step 2: Create a Service Group
1. The Services page can be accessed either from Firewall > Services or Network > Services. 
2. Click Add Group.
3.Select individual services from the list in the left column. Click - > to add the services to the group.
4.To remove services from the group, select individual services from the list in right column. Click < -to remove the services.

5.When you are finished, click OK to add the group to Custom Services Groups.
Step 3: Defining the appropriateNAT Policies
1. Select Network > NAT Policies.
2. Click the Add a new NAT Policy button and chose the following settings from the drop-down menu:
Understanding how to use NAT policies starts with the construction of an IP packet. Every packet contains addressing information that allows the packet to get to its destination, and for the destination to respond to the original requester. The packet contains (among other things) the requester’s IP address, the protocol information of the requestor, and the destination’s IP address. The NAT Policies engine in SonicOS Enhanced can inspect the relevant portions of the packet and can dynamically rewrite the information in specified fields for incoming, as well as outgoing traffic.

Adding appropriate NAT Policies
Original Source: Any
 Translated Source: Original
 Original Destination: MailServer Public
Translated Destination: MailServer Private
 Original Service: MailServer Services
 Translated Service: Original
 Inbound Interface: Any
Outbound Interface: Any
 Comment: Webserver behind SonicWALL.
Enable NAT Policy: Checked
 Create a reflexive policy: Checked

Note: Create a reflective policy: When you check this box, a mirror outbound or inbound NAT policy for the NAT policy you defined in the Add NAT Policy window is automatically created.
3. Click the Addbutton.

Loopback Policy:
If you wish to access this server from other internal zones using the Public IP address 1.1.1.1 consider creating a Loopback NAT Policy else go to next step:
Original Source: Firewalled Subnets  
Translated Source: MailServer Public 
Original Destination: MailServer Public 
Translated Destination: MailServer Private 
Original Service: MailServer Services 
Translated Service: Original 
Inbound Interface: Any 
Outbound Interface: Any 
Comment: Loopback policy 
Enable NAT Policy: Checked 
Create a reflexive policy: unchecked



4.  Upon completion under Network > Nat Policies tab the above Inboundand Outbond NAT policies will be created.

Step 3: Creating Firewall Access Rules
1. Click Firewall > Access Rules tab.
2. Select the type of view in the View Style section and go to WAN to LAN access rules.
3.Click Add a new entry and create the rule by entering the following into the fields:
Caution: The ability to define network access rules is a very powerful tool. Using custom access rules can disable firewall protection or block all access to the Internet. Use caution when creating or deleting network access rules.

Action: Allow 
 From Zone: WAN
 To Zone: LAN
Service: MailServer Services 
Source: Any 
Destination: MailServer Public 
 Users Allowed: All
 Schedule: Always on
 Enable Logging: checked
Allow Fragmented Packets: checked

5:Click OK.


How to Test:
Testing from within the private network: Ensure that the Email Server is working from within the private network itself.
Testing from the Internet: Go to www.mxtoolbox.com and enter your Email Server's Public IP address in the Domain Name field i.e 1.1.1.1 

Troubleshooting:
Ensure that the EmailServer's Default Gateway IP address is SonicWALL's LAN IP address.
Ensure that the Email Server is able to access the Internet.
Try to reduce the MTU value on your SonicWALL appliance.
Displaying Access Rule Traffic Statistics:

1. Click Firewall > Access Rules tab.
2. Select the type of view in the View Style section and go to WAN to LAN access rules.
3.Move your mouse pointer over the Graph icon to display the following access rule receive (Rx) and transmit (Tx) traffic statistics: 
• Rx Bytes 
• Rx Packets 
• Tx Bytes 
• Tx Packets


Ensure you do not have duplicate NAT Policies and Firewall Access Rules for your Email Server.
For further troubleshooting go to SonicWALL Logs under Log > View page and check for Alerts, Denied IP's, Dropped messages, etc.


Saturday, 4 July 2015

Static Route Tracking using IP SLA


The best and simplest way to achieve WAN redundancy on Cisco devices is to use Reliable Static backup routes with IP SLA tracking.
IP SLAs is a feature included in the Cisco IOS Software that can allow administrators the ability to Analyze IP Service Levels for IP applications and services. IP SLA's uses active traffic-monitoring technology to monitor continuous traffic on the network. This is a reliable method in measuring over head network performance. Cisco Routers provide IP SLA Responders that give accuracy of measured data across a network.
With IP SLAs, routers and switches perform periodic measurements. The number and type of available measurements are vast and in this article I will be covering just the ICMP ECHO feature. IP SLA in itself is a very big topic to cover J
Let us take an example of a basic redundant WAN link scenario as shown below:
 
In the above figure the Cisco device is connected to two WAN links ISP1 and ISP2. The most common setup that we use in day to day life is to have to default routes configured on the Cisco router pointing to the respective next hop IPs as shown below:
R1(config)# ip route 0.0.0.0 0.0.0.0 2.2.2.2
R1(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.3 10
If you notice the Administrative Distance for the secondary route pointing to ISP2 is increased to 10 so that it becomes the backup link.
The above configuration with just two floating static routes partially accomplishes our requirement as it will work only in the scenario where the routers interfaces connected to the WAN link are in up/down or down/down status. But in a lot of situations we see that even though the links remain up but we are not able to reach the gateway, this usually happens when the issue is at the ISP side.
In such scenarios, IP SLAs becomes an engineer's best friend. With around six additional IOS commands we can have a more reliable automatic failover environment.
Using IP SLA the Cisco IOS gets the ability to use Internet Control Message Protocol (ICMP) pings to identify when a WAN link goes down at the remote end and hence allows the initiation of a backup connection from an alternative port. The Reliable Static Routing Backup using Object Tracking feature can ensure reliable backup in the case of several catastrophic events, such as Internet circuit failure or peer device failure.
IP SLA is configured to ping a target, such as a publicly routable IP address or a target inside the corporate network or your next-hop IP on the ISP's router. The pings are routed from the primary interface only. Following a sample configuration of IP SLA to generate icmp ping targeted at the ISP1s next-hop IP.
R1(config)# ip sla 1
R1(config)# icmp-echo 2.2.2.2 source-interface FastEthernet0/0
R1(config)# timeout 1000
R1(config)# threshold 2
R1(config)# frequency 3
R1(config)# ip sla schedule 1 life forever start-time now
Please note that the Cisco IP SLA commands have changed from IOS to IOS to know the exact command for IOS check the Cisco documentation. The above commands are for IOS 12.4(4)T, 15.(0)1M, and later releases.
The above configuration defines and starts an IP SLA probe.
The ICMP Echo probe sends an ICMP Echo packet to next-hop IP 2.2.2.2 every 3 seconds, as defined by the “frequency” parameter.
Timeout sets the amount of time (in milliseconds) for which the Cisco IOS IP SLAs operation waits for a response from its request packet.
Threshold sets the rising threshold that generates a reaction event and stores history information for the Cisco IOS IP SLAs operation.
After defining the IP SLA operation our next step is to define an object that tracks the SLA probe. This can be accomplished by using the IOS Track Object as shown below:
R1(config)# track 1 ip sla 1 reachability
The above command will track the state of the IP SLA operation. If there are no ping responses from the next-hop IP the track will go down and it will come up when the ip sla operation starts receiving ping response.
To verify the track status use the use the “show track” command as shown below:
R1# show track 

Track 1 
IP SLA 1 reachability 
Reachability is Down 
1 change, last change 00:03:19 
Latest operation return code: Unknown
The above output shows that the track status is down. Every IP SLAs operation maintains an operation return-code value. This return code is interpreted by the tracking process. The return code may return OK, OverThreshold, and several other return codes.
Different operations may have different return-code values, so only values common to all operation types are used. The below table shows the track states as per the IP SLA return code.
Tracking
Return Code
Track State 
Reachability 
OK or over threshold 
(all other return codes) 
Up 
Down 
The Last step in the IP SLA Reliable Static Route configuration is to add the “track” statement to the default routes pointing to the ISP routers as shown below:
R1(config)# ip route 0.0.0.0 0.0.0.0 2.2.2.2 track 1
R1(config)# ip route 0.0.0.0 0.0.0.0 3.3.3.3 10
The track number keyword and argument combination specifies that the static route will be installed only if the state of the configured track object is up. Hence if the track status is down the secondary route will be used to forward all the traffic.