At work we’ve recently made the decision to migrate to Exchange 2010 from Exchange 2003. While we do have an environment that we can use for some testing of the migration it doesn’t mimic our production environment [...]]]> [Part 2 of this series which involves the actual configuration of the Vyatta routers is now up here -crt]

At work we’ve recently made the decision to migrate to Exchange 2010 from Exchange 2003. While we do have an environment that we can use for some testing of the migration it doesn’t mimic our production environment closely enough for me to be comfortable using it as the sole test area. Given the changes in how Exchange 2010 (E2KX) works vs 2003 I wanted to be able to simulate multiple (2) Active Directory sites (i.e. subnets), a DMZ, and the “Internet” including some really simple firewalls.

I wanted to use virtual machines to go through this exercise so that I could take snapshots and repeat the various steps and/or variations of them if necessary. In order to do this I utilized the Vyatta Community Edition based routers to help create my virtual “enterprise” environment. I’ve talked about Vyatta before in this article. In this post I’ll talk a little about the process I went through to get to my final configuration (shown below).  In subsequent articles I’ll go  through the actual router and VMware configuration process.

The final environment as laid out on two interconnected servers

Physical view of the network

In initially penciling out a plan for what I wanted to do I had nine VMs scattered across four subnets.

Isolated environment with multiple gateways per subnet

Consolidating functions to reduce # of VMs

In further looking at this from a networking perspective, I was hit with the realization the initial configuration with two routers attached to the HQ and DMZ subnets would require me to manage routing on each individual VM in each of those subnets as well as on each of the routers. As an example one can look at the Exchange 2010 server in the HQ site/subnet.

In this particular case the Exchange server would need to be able to route some traffic to the DMZ via 192.168.2.253 and other traffic to the “Remote” site via 192.168.2.254. (If the server was going to communicate directly with machines in our fake “Internet” I’d have to add yet another routing entry.) I can of course configure a default gateway when configuring the NIC, but still have to manually add a route for the other gateway. This process then has to be repeated on each machine. It then gets more complicated if I want to be able to use Terminal Services (RDP) to connect to the VMs rather than using the VM remote console because I now have to figure out how to connect the virtual routers to my home network and potentially add yet another routing entry.

I decided I’d rather have a single gateway on each subnet (so I only had to specify a default gateway on each VM) and then rely on the routers to do all the routing. I considered a couple of different ways to do this. One option was do something “meshy” where the router for each subnet was connected to common shared subnet.

This would have had the desired effect a single gateway for each subnet regardless of where traffic was going, but would have required 5 virtual routers which seemed a little excessive. Going in the other direction, another option was to have a single router connected to everything.

Single-router solution

I ended up with a solution somewhere between the “mesh” and the single mongo router. It employs three routers. I decided on this partly because I wanted to keep things relatively simple especially since I was going to be enabling the firewall functionality between the DMZ and Internet (and wanting to limit the damage I could do to myself when working late at night).

Again, when all was said and done the environment I ended up with looks like the one below. In the next couple of entries I’ll go through the actual process of building the networking side of this.

Physical/Logical view

It turns out that they are usable pretty much as is though there is a minor modification that needs to be [...]]]> One of the things I wanted to check in looking at Zabbix was how hard it would be to use the Nagios plugins I wrote/modified for monitoring ESX 3i in Zabbix.

It turns out that they are usable pretty much as is though there is a minor modification that needs to be made on how they accept/expect parameters. There are however a couple of ways to approach setting them up. Zabbix supports maintaining a couple of different kinds of data for external checks (as well as in general). These include:

• Float

• Integer

• Text

• Log

• Character

The Nagios plugins I ‘m concerned in looking at will probably work with either the Log type or Integer. The external check “Item” type is just that a check. In and of itself it doesn’t make anything happen in terms of alerting or notifications. For that we need to set up “Triggers.” I’ll cover setting up an Item using Log type data in this post.

I’ve created a template in Zabbix for my 3i boxes to which I’ll be attaching these “Items” so that they’re available for anything built off this template.

To start we’ll need to log into the Zabbix web console, select “Configuration” and then Items. Then we need to narrow down object we’re working on using the Group and Host dropdowns. Here I’ve used the group GO_ESX and the template Template_GO_ESX_3i. Next click “Create Item”

We need to fill in the “description” field with something meaningful to us. In this case we’re going to be using the script check_3i_sensors which returns info about the various sensors in the machine (of particular interest are the power supplies and their redundancy) So we’ll use “Check 3i Sensors” as the description. The “Type” needs to be changed to External Check. The key in this case is actually the name of the script to run and any parameters. For external checks the format is:

Script(parameters)

Where:

script – is the name of the script

Parameters is the list of command line parameters

Zabbix will execute the script from the directory specified by the ExternalScripts option in zabbix_server.conf. (By default this /etc/zabbix/externalscripts) Zabbix will add the hostname as the first parameter and then append the list specified in the (parameters) piece of the definition. As an example:

check_oracle.sh[-h 192.168.1.4]

ZABBIX will execute:

check_oracle.sh www1.company.com -h 192.168.1.4.

[ Here is where one of the drawbacks of Zabbix appears when compared to Nagios. I haven't yet found a way to alter the parameters that are sent to the script on a per host basis. It is of course possible to set up the checks on each host rather than using the template, but the template should in theory be used to save us some of that repetitive work. If we were to go forward with this it ought to be possible to automate the process. If we define our process to include creating a monitoring user on each ESX host with the same name and password then using the template becomes much more feasible ]

So for the sensors script we would enter the following for the key: check_3i_sensors( –username zabbix –password zabbix)

Since zabbix already includes the hostname for us we don’t need to specify it. (But this is where the modification to the nagios plugins becomes necessary to properly handle the way the argument is passed) On my test ESX 3i server I’ve created a local user called ‘zabbix’ which has read-only privileges to use for connecting and running the external check.

In the “Type of information” field select “Log” via the dropdown menu. This will cause the fields on the screen to change. Specify a value for the update interval (I usually use 60 seconds) and any flexible intervals if necessary as well as the number of days to keep history and trend data (see image below) Then click the “Save” button.

This needs to be repeated for any other plugins that are applicable to the template. As show below I’ve created two External checks, one for Sensor data, one for Storage status.

Next you’ll need to create a host based on your template. Here I’ve created a host call “Steve_ESX_2950″ based on the template. Next if you wait a few minutes and then go the “Monitoring” tab and select overview (and if necessary narrow down the show servers to see your new host) you should see something like the image below:

Looking at this we can tell out external check has run and in this particular case it appears the sensor status is “GREEN”. If you click on the field you can see the last couple of hundred values for that particular item. You’ll notice the “Severity” is not classified. What we need to do next (in the next post) is to set up a trigger based on the Value of the Item (i.e. when it’s not “Green”).