(Final Report) Configuration Management and Network Traffic
-
Upload
moise-edner-brutus -
Category
Documents
-
view
16 -
download
3
description
Transcript of (Final Report) Configuration Management and Network Traffic
-
Running head: CONFIGURATION MANAGEMENT AND NETWORK TRAFFIC 1
NSSA-789 Cloud Computing Seminar
CM and Network Traffic: an Analysis of Application Deployment and Server Provisioning
Mose Edner Brutus
Pontificia Universidad Catlica Madre y Maestra
Santo Domingo, Dominican
May 2th
, 2015
-
CONFIGURATION MANAGEMENT AND NETWORK TRAFFIC 2
CM and Network Traffic: an Analysis of Application Deployment and Server Provisioning
Network design is a concern when it comes to develop new IT system or to extend
existing one. However, once the administrators set the system based on customer expectations;
the new topology is ready for testing phase; and thereafter it is put in production. Responding to
business expectations, administrators apply a couple of changes on systems. Those changes
occurred because of organizational restructuring; or, if it is a joint venture, for integrating
heterogeneous systems; or because of companys acquisitions. Therefore, all those events
produce multiple arrays of configurations affecting the whole system. And given that such
manual intensive process is error-prone, so usually we end up with misconfigurations or
configuration conflicts. Coping with this sort of issue, many solutions have been proposed. The
last that appears more effective and resilient is the configuration management approach. This one
consists in deploying hierarchical repositories of devices configuration and other mechanisms
for maintaining uniformity among configuration items; ensuring that all configuration items are
properly set up with the latest updates. In this vein, the present project reports the results of a
simulation made on a sort of campus network topology for evaluating predictively the
effectiveness of managing large-scale network infrastructure with configuration management
tools. During the experiment, the network topology encompassed two web application servers
with two different sets of configurations; a database server; a domain controller; a file server;
and all necessary services for ensuring that the network is working properly. The project pursued
two goals by doing that way: first we intended to measure the effectiveness of such an approach;
second we attempted to seize the impact of server provisioning and application deployment on
the network traffic given bandwidth constraint. Consequently, we found that 100% of
automatized tasks performed with CM were executed successfully. However, the usage of CM
-
CONFIGURATION MANAGEMENT AND NETWORK TRAFFIC 3
for deploying application for multiple servers increased Link utilization from 12% up to 18%
while presenting same average delay of 0.0075 milliseconds.
Literature Review
In the marketplace, there are many different tools and systems to manage network
configuration and software deployment. The most usual is CFEngine, old of more than a decade;
it offers interesting functionalities which enforce administrative tasks execution significantly. Its
architecture, however, imposes several constraints. For instance, we might consider the
implementation of a client-agent for all attached client; the workload of synchronization process
between policy server and nodes. Moreover, there is Chef, a more flexible configuration
management, written in Ruby and Erlang. It was one of the rare pure-Ruby, domain-specific
language (DSL) for writing system configuration recipes. On the other hand, we have Puppet
another Ruby-based and open source configuration management tool. It runs on many UNIX-like
as well as Microsoft Windows and has its own declarative language describing system
configuration. Basically, to get things done with Puppet, we do write custom configurations in
Ruby which can be afterward whether applied directly to the system, in a standalone
environment, or compiled into a catalog and then distributed as needed. Puppet is also model-
driven. Furthermore, we have Ansible from Ansible Inc. which is the principal sponsor of
Ansible configuration management software, an open source platform able to run on most UNIX
and Linux distribution and Microsoft Windows. It is Python-based and uses YAML to
implement reusable descriptions of systems. Mostly, its remarkable notoriety is based on its easy
learning curve and its other design goals as such: be minimal in nature, be consistent, be secure,
and provide a high reliability.
-
CONFIGURATION MANAGEMENT AND NETWORK TRAFFIC 4
Methodology
For this experiment, we have considered two steps: the former was dedicated to design
and development tasks thereby we were performing the principal network configurations:
naming convention; network addressing; playbooks and roles design; and deployment on
targeted nodes. We configured no less than five servers as follows: 2 web servers with different
sets of configurations, 1 database server running PostgreSQL, and 1 File Server. For more details
on workstations and servers configurations, please see Table 1.
Web Server Database Server Inventory Server
OS: CentOS 6.2
Server: Apache
NIC: 1
OS: CentOS 6.5
Server: PostgreSQL 9.3
NIC: 1
OS: CentOS 6.5
Server: Ansible 2.1
NIC: 1
File Server Domain Server
OS: CentOS 6.2
Server: Samba 3.6.3
NIC: 1
OS: Ms Server 2012
Server: Domain Controller
NIC: 1
Table 1 Server Configurations
The latter part consisted of gathering information for analyzing effectiveness and
efficiency of tasks execution and network traffic variations. We used utilities such as: Nload,
Iptraf, Iftop, VNStats, and Bandwidthd.
-
CONFIGURATION MANAGEMENT AND NETWORK TRAFFIC 5
Results
We begin by dividing the results in two sets of statistics: the former describes the regular
traffic observed on LAN, followed by the turnaround observed because of application
development and server provisioning; the latter depicts tasks execution while deploying
applications and provisioning servers and discusses effectiveness and efficiency of such a
execution.
As we can see through Illustration 1, in turn, the LAN traffic is relative low. The highest
frequency is among of the smallest packet sizes. Consequently, we might assume that workload
actual is affordable by the network topology.
Fig. 1 Network Topology
-
CONFIGURATION MANAGEMENT AND NETWORK TRAFFIC 6
Illustration 1 Frequency of Packet Size
Additionally, Illustration 2 and Illustration 3 provide more precision about this
distribution; this way, it is quite obvious that the highest frequency is between packet sizes of 76
to 150 bytes.
Illustration 2 Frequency of Packet Size Set 1
0
100
200
300
400
500
600
700
75
15
0
22
5
30
0
37
5
45
0
52
5
60
0
67
5
75
0
82
5
90
0
97
5
10
50
11
25
12
00
12
75
13
50
14
25
15
00
+
to to to to to to to to to to to to to to to to to to to to
1 76 151 226 301 376 451 526 601 676 751 826 901 976105111261201127613511426
F
r
e
q
u
e
n
c
y
Bytes
Frequency of Packet Size
Packet Size
0100200300400500600700
75 150 225 300 375 450 525 600 675 750
to to to to to to to to to to
1 76 151 226 301 376 451 526 601 676
F
r
e
q
u
e
n
c
y
Bytes
Frequency of Packet Size
Packet Size set 1
-
CONFIGURATION MANAGEMENT AND NETWORK TRAFFIC 7
Illustration 3 Frequency of Packet Size Set 2
The total rates observed are of 2.1 Kbits/sec or 3.0packets/sec with incoming rate and outgoing
rate of 1.6packets/sec and 1.4packets/sec respectively. For further details, lets take a look at
Table 2.
Table 2 Network Metric for Regular Traffic
Metric Values
Average Arrival Rate (Packets/sec) 1.6
Average Service Rate (Packets/sec) 133,244.500
Average Delay (milliseconds) 0.0075
Link Speed (Mbps) 100
Average Packet Size (bytes) 750.5
Arrival Rate (Mbps) 1,200.800
Link Utilization (%) 12
020406080
100120140160180
82
5
90
0
97
5
10
50
11
25
12
00
12
75
13
50
14
25
15
00
+
to to to to to to to to to to
751 826 901 976 105111261201127613511426
F
r
e
q
u
e
n
c
y
Bytes
Frequency of Packet Size
Packet Size set 2
-
CONFIGURATION MANAGEMENT AND NETWORK TRAFFIC 8
For now, we are moving on to the latter scenario, which describes how those metrics are
populated in case of deployment. So doing, we start over with the graphic of frequencies of
Packet size as follows.
Illustration 4 Packet Size 2
Based on this plot, we suspect that IP Datagram fragmentation is being performed on the IP
datagrams. Thus, the amount of small packets is getting high than before. This as side effect
might carry out an inefficient use of resources allocated to network architecture; an increasing
loss of fragments, which leads, in turn, to degraded performance. Moreover, we could remark
that the highest frequency still remains among the smallest packet sizes (between 1 to 75 bytes).
0100020003000400050006000700080009000
75
15
0
22
5
30
0
37
5
45
0
52
5
60
0
67
5
75
0
82
5
90
0
97
5
10
50
11
25
12
00
12
75
13
50
14
25
15
00
+
to to to to to to to to to to to to to to to to to to to to
1 76 151 226 301 376 451 526 601 676 751 826 901 976105111261201127613511426
F
r
e
q
u
e
n
c
y
Bytes
Frequency of Packet Size
Normal Traffic On Deployment and Provisioning
-
CONFIGURATION MANAGEMENT AND NETWORK TRAFFIC 9
Figure 1 Frequency of Packet Size for Lower size
The plot at Figure 1 lets us see how fragmented packets are because of applications traffic is
increasing when provisioning servers. Now, to have an idea about the distribution of this traffic,
we are moving on to the recap table of bandwidth use, which, in a sense, summarizes network
traffic for one single week by protocols.
Table 1 Recap Table of Bandwidth Use Weekly
0
1000
2000
3000
4000
5000
6000
7000
8000
75 150 225 300 375 450 525 600 675 750
to to to to to to to to to to
1 76 151 226 301 376 451 526 601 676
F
r
e
q
u
e
n
c
y
Bytes
Frequency of Packet Size
Regular Traffic
On Deployment andProvisioning
-
CONFIGURATION MANAGEMENT AND NETWORK TRAFFIC 10
We admit, however, the network traffic isnt heavy. The significant turnaround has been detected
trough only days of deployment; otherwise, the network traffic is quite low. For more details, we
refer to the plot of bandwidth use while receiving traffic weekly below.
Illustration 5 Bandwidth Use while receiving weekly
Based on Illustration 5, we assume that even though the bandwidth usage is increasing
while deploying applications and provisioning servers so far it isnt a burden for network traffic.
For instance, lets take a look at Illustration 6 and Table 3. As you can see, the traffic isnt heavy.
We have for two days respectively a peak receive rate of 1.7Mbits/sec for a network topology
with at least five servers and three applications. We should admit that actually we generate traffic
only for testing purpose.
Illustration 6 Bandwidth Usage While receiving traffic daily
-
CONFIGURATION MANAGEMENT AND NETWORK TRAFFIC 11
Metric Values
Average Arrival Rate (Packets/sec) 2.5
Average Service Rate (Packets/sec) 133,244.500
Average Delay (milliseconds) 0.0075
Link Speed (Mbps) 100
Average Packet Size (bytes) 750.5
Arrival Rate (Mbps) 1,876.25
Link Utilization (%) 18.76
Table 3 Network Metric when Deployment is being performed
We end up with the same conclusions for Table 2 whereby we depict the bandwidth usage
daily. Certes, automated tasks such as fetching baseline of each configuration item,
configuration monitoring, and so forth consume a certain extent of bandwidth, however, not
enough to break down network traffic wholly.
Table 2 Recap Table of Bandwidth Usage Daily
-
CONFIGURATION MANAGEMENT AND NETWORK TRAFFIC 12
By now, we move on to the latter part of this section, which discusses effectiveness and
efficiency of managing with CM tool. To do so, we come up with the distribution of tasks chart
and the account of frequency by task category. Those charts classify all tasks performed in four
categories such as creation tasks which imply creation of new baselines for devices; modification
tasks which consist of configuration modification, package update, environment configuration;
unreachable tasks; failed tasks.
Categories of Tasks Count
Creation Tasks 68
Modification Tasks 50
Unreachable Tasks 0
Failed Tasks 0
Distribution of Tasks
Creation Tasks
Modification Tasks
Unreachable Tasks
Failed Tasks
Table 4 Distribution of Tasks by Category
Figure 2 Distribution of Tasks by Category Chart
-
CONFIGURATION MANAGEMENT AND NETWORK TRAFFIC 13
As you see, there is no failed task or unreachable task. This expresses effectiveness of
managing with CM. With only the least of tasks, we were able to install and configure the whole
network topology including all expected applications. We carry out all those tasks in a
centralized way and with an automatized intense process.
Moreover, a configuration management system for being effective must provide relevant
information to afford diagnostic for troubleshooting. This way, network configuration
management with CM is suitable based on troubleshooting information that we have in verbose
mode. For instance, the excerpt of Illustration 7 teases out the sequence of task execution for
installing PostgreSQL 9.3 with sufficient information on each mere step.
Illustration 7 Installation of PostgreSQL 9.3
-
CONFIGURATION MANAGEMENT AND NETWORK TRAFFIC 14
Future Works
We close up this report by pointing out a couple of remarks drawing from this
experiment; such remarks might drive subsequent researches to leverage integration of CM with
other technology as such Jenkins, Dockers container, or Git. We also consider developing a load
balance and a hierarchical repository structure for supporting the configuration management
environment. Among other things, we might consider developing patterns of baselines for routers
regarding role-play; patterns of baselines for workstations and servers.