Project S.I.N.
A comparison of network monitoring systems
Brent Grover
Edward Schilla
Lucas Schill
Michigan Technological University
Abstract— In comparison of legacy Nagios and recent forks
Icinga and Shinken, the question of enterprise solution efficiency
comes into play. The project focuses on performance and
usability of these three network monitoring suites on enterprise
simulated computing environments. The goal is to create a
recommendation to firms who are looking into a solution to suit
their network monitoring needs.
Keywords—component; formatting; style; styling; insert (key
words)
I. INTRODUCTION
The goal of project S.I.N. is to compare the three
infrastructure monitoring suites
in respect to the demands of a corporate environment. To
accomplish this, we will create a
network that is designed to simulate the complexities and
requirements of a full scale production
environment. Once completed we will deploy and test the
three suites via a rubric that we will develop. This test will
measure many of the features and qualities of each, from easeof-use to efficiency.
II. ENVIRONMENT OVERVIEW
A. Current Setup
As stated, NFS, PXE, and DNS are managed on one of two
IBM servers while pfSense is managed on the other. Upgrading
or changes to this will be the last thing the project seeks. Three
Dell 2650 1U servers installed with RHEL 6.3 and dedicated
one each to Nagios, Shinken, and Icinga. Two of them are
currently installed and running at the time of this writing.
Upgrades to these servers is of utmost priority, as they are the
root of all testing metrics. Previously mentioned Netgear and
Cisco networking hardware is of least importance on the
upgrade list, as it will be difficult to justify going above
100mbps interfaces in today’s local enterprise networking
environments, except for possible interface upgrades to
uplinks.
The primary site consists of a pfSense firewall, with
one NIC connected to MTU’s network, one NIC connected to
the internal testing networking, and a final nice connected to a
client network. The internet network consists of a Netgear
FSM7352S and a CISCO 3550 48 port. These two switches are
both 100Base -T. The client network is made up of a Netgear
FS105 5 port switch and a Meraki MR12 wireless access point.
B. Goal
Our planned network consists of two sites, the
primary site that holds most of our
equipment and our client machines, and a remote site that will
be used to test specific features
that need to be present to successfully monitor an enterprise
system.
The primary site is located at Michigan Technological
University, behind a pfSense box that serves as DHCP and
NAT for our network and uses the IP provided to us by MTU
for internet access. The client site of this network is located on
a separate interface and subnet to isolate the test environment,
it contains two desktop machines and an access point for other
devices. The other part of this network contains most of our
testing equipment including our three primary SIN nodes that
the software will run on and many clients.
The remote site will contain one SIN node and numerous
clients. The location for this site is still undetermined. This
location’s main purpose is feature testing, with secondary
focus.
III.
TESTING
To properly test specific features such as clustering
while assuring consistent resource access between the three
soft wares we are going to run our SIN nodes as KVM
hypervisors and divide up the available resources evenly
between the KVM guest. Each node will have 3 virtual
machines running on it, one for each software. This design also
gives us the ability to save machine states and restore them
during testing to keep the environment clean, and it is
following the virtualization trend.
OS and Software
Our SIN nodes will be using Debian 6.0.6 (RHEL)
64bit and will have KVM software installed. The guests will
use Debian 6.0.6 64bit but their software will vary depending
on the requirements of Shinken, Nagios and Icinga.
The client nodes will run numerous operating
systems, including CentOS, Debian and Windows to fully test
the software.
Performance, feature testing through custom scripts.
We will write scripts and run them and test features and etc.
We will grade according to a fact based rubric and an opinion
based rubric.
C. pfSense
The pfSense firewall runs on an IBM xSeries 340 and
works as a NAT, DHCP, Firewall, and DNS relay. Each of the
two internal interfaces has a DHCP server running on it to
serve out dynamic IPs and PXE information when needed,
although all permanent equipment uses static assignments. A
Virtual private network (VPN) is configured to allow access
from outside the network, and a NAT Forward for Secure Shell
(SSH) is setup to provide additional access to internal
resources.
D. PXE/WDS
With the large amount of clients and servers on the
project’s network, it was decided that a network based
installation solution would be the most efficient way to add
operating system images to the client and server
computers. The Linux based computers receives the initial
Preboot Execution Environment (PXE) image from the PXE
server which loads the base operating system and then loads
the configuration file. This configuration file streamlines the
installation process by providing the options such as Network
File System (NFS) server location, usernames, passwords, and
additional packages to install. The remaining installation files
for the RHEL installations are retrieved from the NFS server
by the client. For the Debian installations, additional files are
retrieved from the Linux User Group’s servers at Michigan
Technological University. To make diagnosing clients and
servers easier, network based tools such as memtest and
gparted were also added to the PXE server.
Clients utilizing the Windows 7 operating system receive
their images from the Windows Deployment Server (WDS). A
Windows 7 image was placed on a client machine, fully
updated to include service pack one, and captured via the
WDS. This updated image ensures that minimal updating is
required when the new clients are imaged. To streamline the
installation process for Windows 7 clients, the Microsoft
Deployment Toolkit (MDT) along with Automated Installation
Kit (AIK) were installed on the WDS. MDT and AIK allow
for the creation of task sequences so that various scripts can be
run during the installation. This also creates a method for zerotouch deployment, all that needs to be done is start the PXE
session on the client and it will finish the imaging process
automatically.
To run both the Linux PXE server and the WDS server on
the same network, some additional configuration was
needed. Due to the fact that WDS needs to be the primary
network boot server on the network to properly serve out its
installation files, PXELINUX was added to it and set to
override the default PXE service. A new PXE menu was then
created on the WDS to have options for both the WDS and a
pointer to the Linux PXE server.
E. Clients
Client PCs are installed with the latest debian stable net
install, 6.3, and include the packages sshd as well as vim on top
of just the base image. Static IP addresses are configured to
ensure control of testing. A formal inventory of these machines
is kept in a spreadsheet including the processor type, speed,
memory size, and storage size. This information is important
for both capability of the machines but also to test against
scripts that will be run in the testing phases. Currently, there
are ten dell desktop computers with Intel Pentium 4 processors
ranging from 2.26 Gigahertz (GHz) to 3.80GHz and all include
between 512 Megabyte (MB) and 1 Gigabyte (GB) of DDR
memory. The 11th machine is an AMD Athlon xp pro, which
is very similar in performance. All of the clients also have
integrated network interface controllers.
F. Servers
Three Dell 2650 2U rack mount servers are the brains of
the operation. Each is dedicated to its own flavor of network
monitoring system, and includes a fresh, updated image of Red
Hat Enterprise Linux (RHEL). RHEL is some of the most
widely used Linux server operating system software in the
computing industry and is therefore the most logical choice for
this project. Most integration of the network monitoring
systems tested has specific support in the RHEL community
and the systems are also optimized for such enterprise
software.
V. Miscellaneous Project Information
G. A. Project Goals
Motivation behind Project S.I.N. comes from issues
with Nagios being claimed to not have features or lack of
efficiency with feature that Icinga or Shinken may have
advantages in. Testing of network utilization, server utilization,
client load, ease of management, and other factors will help
firms make informed decisions about integrating these tools
into their systems.
H. B. Setbacks
First and foremost has been the inexistence of support
from Nagios, Shinken, and Icinga. Shinken, as of now, is only
community based. While this is positive for correctness,
response time for issues may be a bit slower than expected.
The next largest inconvenience comes with the acquisition of
operating system images, as this has taken around three weeks
worth of time away from the project. Thirdly, more hardware is
needed, whether it is new or not, for client use. As stated in the
“Goals” section of “Environment”, creating multiple virtual
machines as clients would be incredibly beneficial, but at this
point even expanding on our physical machines running
Pentium 4 processors would improve the testing environment.
The last concern that will eventually become a setback during
the testing phase is the age of the Dell 2650 servers. Server age
will depreciate the enterprise environment standard that has
been set and will not allow for accurate testing measurements.
I. D. Website
The group’s website was designed to be the frontend
to possible sponsors and others interested in the project. A
project plan and network diagram are available in PDF form
for easy access. Weekly updates , contact information, and the
budget are also available on the website.
It was designed to be sleek and clean so that it is easy
to read. The Twitter Bootstrap framework was utilized to
layout and style the website.