Hybrid Cloud computing with the Cast Iron Appliance.

( Views and opinions are my own, and does not reflect IBM's point of view )
Cast Iron XH40 is an appliance hosting the IBM's application server. This appliance can be used for connecting the On premise Applications like Tivoli and Off Premise agents on the cloud.
This appliance would act as a Gateway between the Cloud on one end , and the On Premise apps on the other.
This model is the Hybrid cloud, where the CastIron Appliance acts as an Interface between the two ends.

For this to happen -some cloud integration is required on the Cast Iron Appliance.
(I will try not to get into the Appliance, but will focus on the Integration here.)


First the definitions:
On Premise Applications : meaning the Tivoli Enterprise Management Server, Tivoli Enterprise Portal Server that are situated behind the firewall in the Company's/Business's infrastructure.

Off Premise : meaning the entities on the Cloud, ( it could be either the Tivoli Network Monitoring Agents on the IBM Cloud, or the Amazon Cloud.)

Appliance : this is the IBM's technology web server on the Cast Iron Appliance, It could be a virtual Appliance, or a real piece of hardware where the WebSphere is installed.

Agents: Tivoli Network Monitoring Agents installed on the Off Premise agents sitting on the servers to collect network monitoring data.

The Hybrid model :
To get the data from the network monitoring agents on the Off Premise (Agents on the cloud), the Cast Iron App has to be configured to get the data from the Off Premise.

Only one agent on the Off premise cloud will be configured to listen to the CastIron appliance.
Other agents on the cloud will point their TEMS (Tivoli Enterprise Monitoring Server) to the lead server.
The lead server (on Off-Premise)will have firewall enabled to listen to CastIron.

The Cast Iron Appliance will have the Tivoli monitoring agent with capabilities to punch thru the firewall ( configured in gateway.xml) [since the CastIron is sitting behind the firewall ] and get across to the Off-Premise agent on the lead server and collect the data.

The integration is the GUI Interface that the user will configure pointing the source (i.e the TEMS ) and the destination (i.e the lead server on the Off Premise ) which is a simple operation where the user selects the default ports to communicate to and activates the Tivoli Monitoring Agent on the Cast Iron.

This interface is a WebSphere plugin that the user has to install in order to collect server network monitoring.

Once the CastIron Appliance gets the data with the help of the Monitoring agent running on it, it will send it to the Tivoli Enterprise Monitoring Server and which in turn will feed to the Tivoli Enterprise Portal Server thereby rendering the Network Data on the Portal.

This completes the integration with no coding !

Tivoli Service Automation Manager and Blue Nimbus

The new offering from IBM ( to maybe just the regional users in India ) is called the Blue Nimbus.

https://bluenimbus.in.ibm.com/SimpleSRM/login.jsp

One has to enter the Official Intranet user id and password to login.
Once you are in - the Tivoli Service Automation manager console comes in.
Just for kicks I tried to configure a server.. and below is the snapshot and approx charges one can expect.

Looks like a neat tool to provision servers for some one who dont want to invest into infrastructure and maintenance.




This certainly, opens up users who are in the India region to use/configure or provision servers.

The other offerings I found in this site are .....



More, when I provision servers and start using it.

Security in IBM Cloud - in reference to Tivoli Monitoring SaaS

 ( Expressions in this article are mine and does not reflect my employer's IBM point of view )

One of the key questions or rather the first question that I have heard when I meet people at trade shows/ conferences or other informal meeting with folks who are curious about the IBM products on the cloud is "SECURITY ".


ITM 6.2.3 ( IBM Tivoli Monitoring 6.2.3 ) is deployed on the IBM Cloud, and has the security measures as described in this blog are in place.
Firstly no one can access or login to the ITM Image as 'root', which means no one can login as 'su' or 'ssh' as root.
However a default user "idcuser" is created and ssh connections to this user has been enabled by default.

Services like FTP/ and telnet are disabled.
SSH has been configured to accept only key authentication instead of password authentication (giving it a greater level of security)
No SFTP is provided to the Tivoli Monitoring image.
No VNC is permitted - in other words - some one cannot start a VNC session to this Tivoli Monitoring Instance.

Firewalls:  Two levels of security for the Tivoli Monitoring app is provided. One is the operating system level and other is at the application level.

In the IBM cloud instance VM that is hosting the Tivoli application - the guest VM is locked down by disabling the ports and only allowing the ports required for the application in a special file called " parameters" file. 
At the outset - all the incoming and outcoming ports are disabled, and only related ports are enabled.

( e.g: these ports are enabled ) "22 80 443 2809 8880 9401 9403 9402 9060"  

 

Tivoli Network Monitoring - Hybrid Cloud Integration

During any cloud discussion, often you come across a term like 'Hybrid Cloud', with multiple vendors having their own interpretations and definitions.

Here, I will write about our IBM Hybrid cloud scenarios and how we were able to deploy a Hybrid Model where the 1. Servers being monitored are on the Cloud and the 2. Tivoli Monitoring is on-premise and the 3. gateway is placed in between, and this combination would suit the definition of a "Hybrid Cloud".

(References to the term "On-Premise" means that they are behind a firewall.)

A simple Hybrid model described in this blog is :




In this picture above, on the left is the On-Premise, where there is Tivoli installed and on the right is the Cloud where there are servers that are to be monitored, and in between is the gateway.
This gateway sits on-premise and has the ability to go out and collect stats on the servers on the cloud.
The gateway is another piece of hardware, where the user installs an agent, and that has the ability to pull down the Monitoring information from the cloud and pass on to Tivoli. 

In order that the cloud infrastructure provide the necessary Monitoring data to the gateway,  the user has to configure one of the servers on the Cloud with appropriate security permissions,
This lead server would act as a central repository point ( at least that's my interpretation) to other agents on the cloud.
Other agents in the cloud would send their monitoring data to the 'lead' agent.  The data from the lead agent ( in the cloud ) would in turn -on a request from the gateway, provide that data to complete the monitoring circle.


A better pictorial representation would be :

 


Here, the focus is on the On-Premise Data Center where Tivoli Monitoring is installed (meaning the Monitoring Server a.k.a TEMS,and Portal Server a.k.a TEPS and the gateway is an "IBM CastIron" hardware block,


The Tivoli Network Monitoring block renders the monitoring data of the agent(s) on the cloud where it can be managed and remedial actions taken.

Security aspects of this will be covered in a later blog.