(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


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.


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.


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


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


Packet Size set 1


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

+


751 826 901 976 105111261201127613511426

F

r

e

q

u

e

n

c

y

Bytes


Packet Size set 2


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


Normal Traffic On Deployment and Provisioning


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


1 76 151 226 301 376 451 526 601 676

F

r

e

q

u

e

n

c

y

Bytes


Regular Traffic

On Deployment andProvisioning


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


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


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


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


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.