sdn-hadoop
Software-Defined Networks for Traffic Management in Data Commons
Data commons co-locate data, storage and computing resources and enable to researchers to execute data intensive workflows over the hosted data. It is a challenge to support both large numbers of downloads along with data intensive workflows. Software-defined networking (SDN) offers a more dynamic and fine-grained traffic engineering capability for network management. Specifically, it enables us to provide network-as-a-service at the application level, that helps to manage networking in a much more automatic and convenient way. In this research, we investigate and demonstrate how a dynamic, fine-grained traffic engineering capability can improve the performance of a data commons and support both downloading the data and processing the data using data intensive workflows.
SDN traffic engineering experiments
Testbed setup
The experiments demonstrate the ability to configure the network traffic dynamically in response to the current demands on the network. We show how these changes in configurations can improve the overall network throughput as well as the execution times of the pipelines. We show the ability to manage dynamically the traffic at two OSI layers: layer 3 using IP Addresses and layer 4 using TCP port numbers.
Our analysis cluster includes computers with following roles:
- data storage: store input data of all pipelines.
- controller: control switch and run scheduling algorithm that allocate compute and net- work resource for pipelines.
- worker: download data and run pipelines.
We do our experiments in CloudLab infrastructure. We subscribe the whole chassis including a HPE 45XGc Moonshot switch with 45 10Gb ports each of them connects to a computer with 16 64-bit Intel(R) Xeon(R) CPU D-1548 @ 2:00GHz. Each port has eight traffic classes (i.e. queue) (w7, w6, …, w0) with the guaranteed speed at (5Gbps, 1:5Gbps, 1Gbps, 500Mbps, 500Mbps, 500Mbps, 500Mbps, 500Mbps) respectively. In order to avoid the read/write bottleneck of hard disk. We use iperf3 to generate traffic from memory to memory to completely utilize the network bandwidth.
Running experiment
We first ran two jobs in workers 1 and 2 that connected to the storage service with queue w7. Then, we ran a critical pipeline on worker 3 that wanted to connect to the storage service with a higher priority than any existing job in order for it to finish downloading the data as soon as possible.
The link to the storage service was limited to 10Gbps. Without modifying the existing traffic, the critical pipeline could reach, at most, 3:33Gbps, because it needed to share the bandwidth with the two other workers without priority. By modifying the existing traffic (reassigning queues to existing connections from workers 1 and 2), we could guarantee at least 5Gbps to worker 3.
We ran this experiment with two scenarios where the existing traffic was and was not modified, (i) and (ii) respectively. We compared the time for the critical worker (worker 3) to finish downloading the input data and the total time to finish downloading data of the three workers in the two scenarios.
Evaluation result
We ran the experiment with the traffic management mechanism described above. Figure 2 shows the performance gained when applying traffic management. We started 3 jobs, each of them transferred, respectively, 50; 100; 200; 300; 400; 500 and 1000 GB from its node to the object storage server. We measured the time in which the highest priority (Figure 2a) and lowest priority (Figure 2b) jobs finished transferring data.
Figure 2a
Figure 2b
The results show that we can improve the time to transfer all of the data of the highest priority job with minor impact to the lower priority jobs. In particular, we can reduce by 63% the time to transfer the data of the highest priority job while only increasing by 2% the time to transfer the data of the lowest priority job. In theory, the total time to completely transfer the data for all the jobs when applying traffic modification mechanisms and when
Applying to Hadoop cluster
Motivated from the results above, we also apply our traffic management mechanisms in the Hadoop cluster. We setup a Hadoop cluster consisting of 15 slaves as data nodes (named as hu26-i; 0 < i < 16]) and 1 master. Each slave node connects with a Pica8 switch via a 1Gbps port, master node connects to the same switch via a 10Gbps port.
We assume there exists a background traffic at 1Gbps between every two adjacent servers in ring topology subgraph which is represented by green arrow line in Figure 3. In particular, server hu26-i sends to hu26-(i+1) a traffic at 1Gbps. Similarly, server hu26-15 sends 1Gbps to server hu26-1. With these 1Gbps traffics in the background, master node uploads data file to the hadoop cluster via its 10Gbps link connected to the switch.
Hadoop experiment evaluation
We run the experiment with the traffic management mechanism described in section 2. Firstly, we run experiments to upload 20, 40, 80GB of input data to HDFS respectively with 1GB traffic in the background without any traffic engineering mechanism applied, consequently, the queue will be assigned randomly to the packet. Then, we run all upload again. This time, background traffic is assigned to low priority queue limited by 100Mbps and hadoop traffic is assigned to a higher priority queue limited by 900Mbps. For every scenario, we repeat the experiement 4 times and compute the average time.
The results show that we can significantly improve the time to upload all data to HDFS cluster. In particular, we can reduce up to 50% the time to upload data to HDFS cluster. The detailed results are listed in Table 1.
| Size (GB) | modified (s) | not modified (s) |
|---|---|---|
| 20 | 121 | 246.5 |
| 40 | 259 | 524.0 |
| 80 | 561 | 1125.5 |
Demo
Real-time traffic of the demo can be observed in the link below: Hadoop traffic