Maaz Anjum's Blog

At Bobby’s (@dbasolved) insistence, I decided to write this post because it might prove useful for some folks. He mentioned following a note by Jeff Smith (@thatjeffsmith) that he is unable to locate at this time. If you are a VirtualBox user, you obviously have a need to maintain multiple Virtual Machines. You would also need to setup a type for one (or more) of its network adaptors. Let’s keep going here, I promise there’s a point to this :) Below is a list of your options:

By default, the NAT option for the first adaptor is selected. NAT = Network Address Translation and will basically let the Guest VM share the same network as your Host (laptop/desktop_ where you can check emails or browse the internet. Chapter 6 of the VBox Documentation here will explain the other options. Without going into too many details about the other options, if you really knew what you were doing and how you’d like your network to be configured then most likely NAT will not be your choice. Myself, I prefer to use Bridged Adaptor which effectively assigned an IP address within the VBox network and I can easily SSH or SQLPlus onto the VM.

This post is aimed to discuss network connectivity to a Guest VM while using NAT using Port Forwarding. I use OSX so my screenshots and menu options might be in a slightly different location than on Windows, however the steps are pretty much the same. Also note that the VM can remain powered on during the setup steps below.

Si Comencia!

1. Navigate to the Settings menu for the VM in question.

 

2. Click on the “Network Tab”.

 

3. Assuming your adaptor is enable and configured for NAT, click on the “Advanced” section.

 

4. Now, the key here is to setup Port Forwarding.

 

5. Port Forwarding is controlled via “Rules”. These can be configured for TCP and/or UDP protocols. In this example, I want to setup SSH and SQLNET rules. Enter a Rule Name, Select the TCP Protocol, Host Port, and Guest Port. You’ll notice that I intentionally left the IP address sections blank, that is because the rule is generic enough that it will apply to any IP address on the adaptor. Click OK when done.

 

6. Similarly add a SQLNET port as well and click OK twice.

 

6. At this point, we are ready to test connectivity. I used the “Terminal” app on OSX, but the same can done from putty. Why am I connecting to my localhost? Well, the nature of NAT is a shared network so when a connection attempt to the port 2222 is made, it is automatically forwarded (via the VBox VM Rule) to the correct Guest VM. 

theStone:~ maazanjum$ ssh -p 2222 root@localhost
The authenticity of host '[localhost]:2222 ([127.0.0.1]:2222)' can't be established.
RSA key fingerprint is ad:ea:6e:84:d8:2d:1e:ff:bc:69:fc:14:47:2e:67:b5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[localhost]:2222' (RSA) to the list of known hosts.
root@localhost's password: 
Last login: Wed Mar  5 16:04:40 2014 from 10.0.2.2
[root@db12c ~]#  

To pictorially review, we basically enabled Port Forwarding for SSH and SQL as illustrated below.

 

The only catch is that your rules across all Guest VM’s need to be unique. For example, if Rule:SSH:2222 points to Guest VM 1’s Port SSH:22, then for a Guest VM 2 you would likely need a Rule:SSH:2223. I know, it can get a bit confusing but come up with a port numbering scheme. I imagine that you wouldn’t set up Port Forwarding for all of your Guest VMs!

 

 

Hope this was helpful!

Cheers.

Add Your Opinion 2 Opinions

Back in August of 2013, I wrote a post on “Alternative Method to monitor GoldenGate from EM12c outside the GoldenGate 12.1.0.1.0 Plugin” and then back in December of 2013 I wrote another one a Metric Extension to Monitor Unsupported Database Versions. As it turns out, the first post has been quite useful in many customer sites but what it lacks is the process to actually build the Metric Extension (ME).

Note: If you are interested in more ways to monitor GoldenGate, be sure to check out my older posts, Bobby Curtis’ posts (1 & 2), and his upcoming presentation at Collaborate 14. Coincidentally, he is sitting with me on the plane ride over to #C14LV at the moment :-)

It’s important for me to share my experience and reason for not using the metrics provided with the EM12c GoldenGate plugin; I have found it to be a little inconsistent due to several reasons. Starting from the Berkley DB Datastore corruptions, to JAgent hangs, to inaccurate results on the GoldenGate homepage in EM12c, and lastly I’ve experienced unreliable alerting. The JAgent architecture was inherited from the GoldenGate Monitor days and can be roughly described by the illustration below (if this is inaccurate, I’d be more than happy to adjust the diagram below). The parts in green describe the components involved with collecting the data from the GoldenGate instance, as well as, the EM12c side. The process, at certain times, and on certain platforms (Windows) has broken from my experience and after working with Oracle Support for a while until the fixes were released with subsequent patches (11.2.1.0.X), but I still found the incident management and subsequent notifications to work unreliably.

The data flow, as illustrated below described the JAgent which connects to and stores information from the GG Objects periodically in its Datastore (dibdb directory). When the EMAgent polls for updates via the JMX port, it will do so by checking the datastore. Once the raw metric is collected within the repository, it is the EM12c incident management framework which triggers notifications.

With that being said, I’d like to pick up where I left off way back in August of last year.

I already have the output from the monitor_gg.pl script which I will invoke from my new Metric Extension. Let’s begin with a refresher on the lifecycle of an ME:

This post assumes that:

1. You have already downloaded the monitor_gg.pl script onto your host where Golden Gate instances are running.

2. You have tested the script from command line by invoking it, i.e. $ perl monitor_gg.pl and receive the output mentioned in my previous post.

Steps

1. Make your way to the Metric Extensions home page.

2. Click on “Create”, and enter the relevant details such as “Name”, and “Display Name”. Make sure you select the Adapter as “OS Command - Multiple Columns”. The rest you can leave at default values, or change as per your desired check frequency.

3. On the next page, enter the full path of the script in the “Command” section. Alternatively, you could also leave the “Command” section with the %perlBin%/perl and enter the absolute path of the script in the “Script” section.

4. On the next page, you need to specify the columns returned by the status check. The process is similar to what I mentioned in my previous post Metric Extension to Monitor Unsupported Database Versions, so I will quickly skim through the important bits.

It is important to note that I specified this and the following column as Key Columns. This is because the result set in the ME framework requires unique identifiers.

5. The next column represents the actual program name, i.e. Extract, Replicat, Manager etc.

6. Status is an important column because we can use it to trigger state alerts. Note, that I have specified the Warning and Critical thresholds, alert and clear messages. Its quite cool how customizable the framework can be.

7. Next, we have the Lag at Checkpoint, a column which we will use for Alerting. Note, that I have specified the Warning and Critical thresholds, alert and clear messages.

7. Time Since Last Checkpoint is set up in the same manner as the previous column.

8. With that, we are done with the column configuration.

9. I leave the default monitoring credentials in place, however if you are running GoldenGate as user other than the “oracle” user, you will have to either a) create a new monitoring credential set or b) grant the oracle user execute on the monitoring script.

 

10. We’re coming to the end now. On the next screen, we can actually see this metric in action by running it against a target.

11. Next, we review our settings and save the Metric Extension.

12. Now, back on the ME home page, the metric is in Editable Stage.

13. We simply need to save it as a “Deployable Draft” or a “Published” extension. The former state allows for deployments to individual targets, where as the latter is required for deployments to Monitoring Templates.

14. Follow steps listed under section 10 on my post on creation of metric extensions to deploy the ME.

Once deployed, the metric is collected at the intervals specified in step 2. Depending on how your incident rule sets are configured, you will most likely start receiving alerting once the thresholds we defined above are crossed.

I do have some lessons learned to add to the above posts from an Incident Management perspective, but that will have to be a completely different post :-)

Hope this helps.

Cheers! 

Add Your Opinion 2 Opinions