Printer Friendly

Development of Weighted Round-Robin with Variable TTL to Improve of Load Balancing Mechanism in a Distributed Web System Using DNS.

1 INTRODUCTION

In recent years, the Internet users increase and much service is performed using Web. Therefore, load of Web servers is growing more and more. If the load is over the limit of server's capacity, it returns the response with large delay, and it goes down in the worst case. Load balancing techniques are often used to avoid overload of servers. There is a Web system that distributes requests to multiple servers such as cache servers or mirror servers for load balancing. Progress of virtualization technology made it easy to build virtual servers on Cloud. They can be used as cache server. Responsiveness, however, does not improve with insufficient cache servers against load. In contrast, costs will increase with surplus cache servers against load. Therefore, we developed a distributed Web system using Load Balancer that dynamically adjust the number of cache servers according to load of them to reduce running cost [1]. In this study, we develop a method to distribute load to cache servers using DNS round-robin. However, load imbalance occurs among the servers with this method and responsiveness decreases because it is difficult to distribute the load uniformly using DNS round-robin. Therefore, we implement a function to suspend the allocation of requests to the overloaded server. From results of experiments, we confirm that improved function is possible to prevent lowering responsiveness with smaller TTL value. However, small TTL increases network traffic and DNS request. Therefore, we implement weighted round-robin with variable TTL to change the TTL value according to load of servers and increase request to the low load server.

2 RELATED WORKS

A Cloud auto-scaling mechanism aiming at providing necessary resources at low cost has been studied [2][3]. In [2], auto-scaling mechanism based on workload information and performance desire is implemented in Windows Azure platform. The result of the experiment shows that cost can be reduced by choosing an instance type of appropriate performance for the workload. This research covers a variety of applications, but our system targets only Web application and aims at cross-use multiple Cloud services.

In [3], an auto-scaling algorithm based on the number of active sessions of the Web server is described. A load balancer is used for load balancing. Although we also use the number of active sessions as the load value, we use DNS for load balancing.

In [4], dynamic load balancing method using dynamic DNS update and round-robin mechanism is proposed. In this method, a server is dynamically added to or removed from the DNS list. The scheduling algorithm considers usage rates of server's CPU, memory, and network. The result of the experiment shows that both the response time and the average file transfer rate of the proposed system are faster than those of a pure round-robin DNS. It is similar to our load balancing method, but ours uses the number of active sessions as the load value.

3 DISTRIBUTED WEB SYSTEM USING DNS

Figure 1 shows our distributed Web system using DNS which consists of management server, authoritative name server, origin server and cache servers on Cloud. The origin server services original contents and cache servers service the cache of them. The managing server manages the number of cache servers and DNS zone of the authoritative name server. For load balancing, this system uses DNS round-robin method which sends the list of IP addresses in a different order to a new client each time. Most clients use the first IP address they receive to connect server. Therefore, requests from clients are sent to each server. By managing the DNS zone of the authoritative name server, it is possible to control the start and stop of allocating request to each server.

The management server has the following functions.

* Load monitoring function

The load monitoring functions monitors load of the origin server and cache servers. This function periodically measures the current and the maximum number of Web server processes and calculates ratio of the current number against the maximum number (Operating Ratio), and calculates average of Operating Ratio of working servers (Average Operating Ratio, AVGOR). This system uses AVGOR as load value.

* Cache server management function

The cache server management function boots up and shuts down cache servers. This function decides the number of required cache servers based on AVGOR obtained by the load monitoring function. When AVGOR is greater than threshold of scale-out ([Th.sub.high]), it boots up a new cache server. When AVGOR is less than threshold of scale-in ([Th.sub.low]), it shuts down a latest booted cache server.

* DNS management function

The DNS management function manages the DNS zone of authoritative name server. According to the booting up and shutting down cache server, IP address of it is added to or removed from the DNS zone dynamically. When the load monitoring function cannot monitor load of a server, it also removes the server. Therefore, it is possible to cope with server failure such as system down.

4 LOAD BALANCING USING DNS ROUND-ROBIN

We experimented with the distributed Web system described in the previous section. The result showed, load imbalance among the servers using the DNS round-robin method.

4.1 Experiment Environment

Table 1 shows the experiment environment. All servers and clients are built as virtual machine on hypervisors which specifications are shown in Table 2. The management server and DNS servers are built on hypervisor1, the origin server and nine cache servers are built on hypervisor2 and hypervisor3, and twelve clients are built on hypervisor4. Mirror server is used instead of cache server because cache mechanism is now developing. Apache2.4 [5] is used as a Web server software. DokuWiki [6] runs on all servers. Each client accesses the Web server using Siege [7]. Siege is the stress test tool. The number of simultaneous accesses is set to 100. Therefore, the maximum number of simultaneous accesses is 1,200 (100x12). TTL value for DNS is set to 60 seconds. [Th.sub.high] and [Th.sub.low] are set to 0.6 and 0.1, respectively.

4.2 Experiment Procedure

The scenario of the experiment is shown in below. To examine the load and the response time of each server, the number of simultaneous accesses to Web servers is stepwise changed.

I. Start with no accesses.

II. Add 1 client every 30 seconds.

III. After all clients are added, keep all clients accessing for 500 seconds.

IV. Remove 1 client every 30 seconds.

V. End when no accesses.

4.3 Experiment Result

Figure 2 shows Operating Raito of each server. Figure 3 shows the response time and the Operating Raito of the origin server.

In Figure 2, several servers are overloaded for a long time, and some servers remain low load. This phenomenon happens clearly around 500 seconds.

In Figure 3, purple line and blue line show average response time and maximum response time for one second, respectively, green line shows Operating Ratio. Maximum response time varies very much. Requests from clients are distributed to each server by using the round-robin method. However, this method cannot consider the load of each server and it causes load imbalance among the servers and response time lengthens.

5 SUSPENDING FUNCTION

We think that the problem described in the previous section can be coped with by suspending the allocation of requests to the overloaded server. We implement a function that excludes overloaded servers from DNS answer. We call this function suspending function. In this section, we describe the implementation and evaluation of suspending function.

5.1 Implementation

The function uses the PipeBackend of PowerDNS[8] that is DNS software. It can call external program that resolves DNS queries dynamically through PipeBackend module. We implement the program that resolves DNS queries based on the configuration file shown in Figure 4. The file contains a FQDN, IP address, status value of each server and TTL value. The status value is updated every second based on Operating Ratio of each server obtained by the management server and sent to the authoritative name server. The status value is set to 0 while the corresponding server stay in overloaded. otherwise, the status value is set to 1. The IP address is included in DNS answer if the corresponding status value is 1. In contrast, the IP address is excluded from DNS answer if the corresponding status value is 0. For example, IP address 192.168.11.21 and 192.168.11.22 is included in DNS answer with configuration shown in Figure 4.

5.2 Experiment Result

The experiment environment and the experiment procedure are the same as in Section 4. When the Operating Ratio of a server is the specific threshold value and over, the function decides that the server is overloaded and set the status value in configuration file to 0. Otherwise, the value is set to 1. In this experiment, the threshold value is set to 0.6 (case A), 0.8 (case B) or 1 (case C). Experiment without the suspending function is represented as case D. We performed experiments five times in all cases.

The average of results is shown Table 3. The cost is the sum of uptime of all servers. The unit of cost, total response time and average response time is second. The blue and red letters indicate the best and worst case, respectively. The average response time in case C is the best in all cases. The number of requests per cost in case C is also the best. However, there is no big difference in the result of each case.

Table 4 shows the distribution of response time. By using the suspending function, the percentage of short response time has increase and the percentage of long response time has decrease. However, the percentage of response time between 9 and 60 seconds increases.

These results show the effectiveness of the function is low. In DNS, the TTL value specifies the expiration date of the DNS cache. It takes long time to reflect the update of DNS zone with large TTL. Therefore, the suspending function takes low effect on response time. So, the same experiments except TTL value set to 30 seconds is performed.

The average of results is shown Table 5. The average response time in case B is the best. The number of requests per cost in case C is the best. By using suspending function, both the average response time and the number of requests per cost are better than that of case D.

Table 6 shows the distribution of response time. By using the suspending function, the percentage of response time less than 3 seconds increases. Otherwise, the percentage of response time decreases except between 15 and 30 seconds in case C.

Figure 5 and Figure 6 show the response time and the Operating Raito of the origin server in case A and case D, respectively. Line colors are same as in Figure 3. In Figure 5, the maximum response time is about half of the maximum response time in Figure 6. These results show the effectiveness of the suspending function with small TTL.

6 WEIGHTED ROUND-ROBIN WITH VARIABLE TTL

In previous section, we confirmed that it is possible to relax load imbalance among the servers and improve responsiveness with small TTL. However, small TTL increases network traffic and DNS request. In contrast, large TTL delays the effect of auto scaling and suspending function. The optimal TTL value varies depending on the load situation of each server. Therefore, we develop a weighted round-robin function with variable TTL. We call variable TTL varTTL

6.1 Design

This function decides weight and TTL of each server according to its load state. low load server is assigned to large weight. The weighted round-robin selects the specific number of IP addresses according to weight with server. The probability of selecting IP address is proportional to weight of its server. The goal of weighted round-robin is to reduce request toward to high load servers by selecting low load server more likely. Each IP address is assigned to its TTL. The varTTL reduces TTL as the load of server increases. The smallest TTL among the selected IP addresses is used as the TTL of DNS response. Therefore, the smaller the number of selected IP addresses, high load server is more likely not to be selected and average TTL increases. However, small number of selected IP addresses causes overload of selected servers.

In contrast, larger the number of selected IP addresses increases average TTL, but distribute requests to many servers. Thus, requests directed to high load server are not reduced so much. It is necessary to use an optimal value according to the situation.

The function uses Operating Ratio, throughput, and the number of failed times for obtaining them as load value.

6.2 Implementation

We implement the program to resolve DNS queries based on weight of each server. This program is implemented based on the external program described in Section 5.1. An example of the configuration file is shown in Figure 7. The file contains a FQDN, record type, number of IP address used for DNS resolution, IP address, weight value and TTL value of each server. "num" IP addresses are selected based on weight. For example, IP address 192.168.11.21 and 192.168.11.22 and TTL 30 is used for DNS resolution with configuration shown in Figure 7. Weight and TTL are updated based on load obtained by the management server.
Figure 7. An Example configuration file containing
weight and TTL value

{
    "domain": "www.example.com",
    "type": "a",
    "num": 2,
    "record": [
      {
        "ip": "192.168.11.21",
        "weight": 150,
        "ttl": 60
      },
      {
        "ip": "192.168.11.22",
        "weight": 100,
        "ttl": 30
      }
    ]
}


6.3 Evaluation

The effect of changes in the number of IP addresses used for DNS resolution is examined.

The effect of weighted round-robin with variable TTL is also examined.

6.3.1 Experiment Environment

Table 7 shows the experiment environment. We use large experiment environment than previous experiment environment. Specifications of each hypervisors are shown in Table 8. Web server software and content are same as in the previous experiment. The number of simultaneous accesses is set to 50. The maximum number of simultaneous access is same as that of previous experiment, but the number of clients is twice. Therefore, the maximum number of simultaneous accesses is 1,200 (50x24). Each client accesses using stress test tool that send DNS request to randomly chosen caching name servers for each request. Weight and TTL are set to 100 and 60 as default values, respectively. Table 9 shows the increment / decrement value of weight and TTL for each Operating Ratio. In low load and normal load state, weight is added when the throughput falls below the moving average of 10 throughputs. Weight and TTL decrease by 5 and 3 each time load value obtainment fails, respectively. If it fails 10 consecutive times, the weight is 0. The other thresholds are the same as in the previous experiment.

6.3.2 Effect of change in the number of IP addresses

In this experiment, the effect of changes in the number of IP addresses used for DNS resolution is examined. The "num" value is set to 1 (case A), 2 (case B), 4 (case C) or 8 (case D).

The result is shown in Table 10 and Table 11. In Table 10, the average response time and the number of requests per cost in case A are the worst. Whereas, case C is the best. Similarly, case C is the best in Table 11. The result improves as the number of IP addresses increases except in case D. Also, As the number of IP addresses used for DNS resolution increases, the average TTL value decreases. This means that the DNS requests and load on DNS increases. In this experiment, the optimal number of IP addresses is 4. It shows that this function is effective depending on the parameters.

6.3.3 Effect of weighted Round-Robin with variable TTL

In order to examine effect of weighted round-robin function with variable TTL, we examine the cases with and without the implemented function using almost the same average TTL.

In the previous experiment, the average TTL for the best result, case C, was 42.46. TTL without implemented function is set to 40.

The results are shown Table 12 and Table 13. The result with implemented function is better than the result without it. This function improves responsiveness and cost performance while reducing DNS request.

7 CONCLUSION

We implemented the suspending function to exclude overloaded servers from DNS answer and evaluated it. By the experiment, it is confirmed that the function is possible to improve responsiveness with smaller TTL value. However, small TTL increases network traffic and DNS request. Therefore, we implemented the weighted round-robin with variable TTL function. By the experiments, it is possible to improve performance with optimal parameters.

The followings are future works.

* More detailed examination of parameters such as CPU usage, memory, I/O and so on

* Improvement of auto-scaling algorithm

* Experiment using Cloud environment

REFERENCES

[1] A. Horiuchi, and K. Saisho. "Prototyping and Evaluation of Virtual Cache Server Management Function for Distributed Web System," The 2015 International Conference on Computational Science and Computational Intelligence (CSCI'15), pp. 324-329, 2015.

[2] M. Mao, J. Li, and M. Humphrey. "Cloud auto-scaling with deadline and budget constraints," 11th ACM/IEEE International Conference on Grid Computing (Grid 2010), 2010.

[3] T.C. Chieu, A. Mohindra, A.A. Karve, and A. Segal. "Dynamic Scaling of Web Applications in a Virtualized Cloud Computing Environment," 2009 IEEE International Conference on e-Business Engineering, pp. 281-286, 2009.

[4] JB. Moon, and MH. Kim, "Dynamic Load Balancing Method Based on DNS for Distributed Web Systems," International Conference on Electronic Commerce and Web Technologies, pp. 238-247, 2005.

[5] Apache, https://httpd.apache.org/

[6] DokuWiki, https://www.dokuwiki.org/dokuwiki#

[7] Siege, https://www.joedog.org/siege-home/

[8] PowerDNS, https://www.powerdns.com/

Kota MORIGAKI and Keizo SAISHO

Kagawa University

2217-20 Hayashi-cho, Takamatsu 761-0396, Japan

s16g473@stu.kagawa-u.ac.jp, sai@eng.kagawa-u.ac.jp

Caption: Figure 1. Distributed Web System using DNS

Caption: Figure 2. Operating Ratio of each server

Caption: Figure 3. Operating Ratio and response time of origin server

Caption: Figure 5. Operating Ratio and response time of origin server in case A (TTL 30)

Caption: Figure 6. Operating Ratio and response time of origin server in case D (TTL 30)
Table 1. Experiment environment

                    Virtual Machine        Number   CPU   Memory

Hypervisor 1   Management Server               1     2      2GB
               Root Name Server                1     1    512MB
               Authoritative Name Server       1     1    512MB
               Caching Name Server            12     1    512MB

Hypervisor     Origin Server                   1     1      1GB
2 x 3          Cache Server                    9     1      1GB

Hypervisor 4   Client                         12     1      1GB

Table 2. Spec of each hypervisor

                      CPU           Memory

Hypervisor1   Intel Xeon E5-2620     32GB
Hypervisor2   Intel Xeon E5-2620     32GB
Hypervisor3   Intel Xeon E5-2620     32GB
Hypervisor4   Intel Core i7-4790K    32GB

Table 3. Experiment result of each case (TTL 60)

               Total       Total     Average    Number of
              response   number or   response   requests
Case   Cast     time     requests      time     per cost

A      7904    629728      725834       0.87       91.83
B      7752    635798      716271       0.89       92.39
C      7909    622597      739972       0.84       93.56
D      7571    627947      700772       0.90       92.56

Table 4. Distribution of response time (TTL 60)

Case    0~3      3~9    9~15    15~30   30~60    60~

A      93.251   5.744   0.497   0.337   0.169   0.002
B      92.595   6.285   0.545   0.365   0.207   0.004
C      94.303   4.972   0.376   0.234   0.113   0.002
D      89.732   9.683   0.340   0.151   0.066   0.028

Table 5. Experiment result of each case (TTL 30)

               Total       Total     Average    Number of
              response   number of   response   requests
Case   Cost     time     requests      time     per cost

A      8046    600700      786708       0.76       97.77
B      8272    591389      804834       0.73       97.29
C      7576    608056      768810       0.79      101.48
D      7257    643281      661994       0.97       91.22

Table 6. Distribution of response time (TTL 30)

Case    0~3      3~9     9~15    15~30   30~60    60~

A      95.970    3.613   0.224   0.148   0.045   0.000
B      95.617    4.022   0.207   0.115   0.038   0.000
C      94.373    5.132   0.279   0.161   0.055   0.000
D      89.105   10.328   0.310   0.151   0.070   0,036

Table 7. Experiment environment

                Virtual Machine          Number   CPU   Memory

Hypervisor   Management Server                1     2      2GB
1 x 2        Root Name Server                 1     1    512MB
             Authoritative Name Server        1     1    512MB
             Caching Name Server             24     1    512MB
Hypervisor   Origin Server                    1     1      1GB
3 x 4        Cache Server                     9     1      1GB
Hypervisor   Client                          24     1      1GB
5 x 6

Table 8. Spec of each hypervisor

                     CPU            Memory

Hypervisor1   Intel Core i5-3470      16GB
Hypervisor2   Intel Core i5-4460      16GB
Hypervisor3   Intel Xeon E5-2620      32GB
Hypervisor4   Intel Xeon E5-2620      32GB
Hypervisor5   Intel Core i5-3470       8GB
Hypervisor6   Intel Core i7-4790K     32GB

Table 9. Increment / Decrement value of TTL and weight

Operating Ratio                Weight   TTL

0.0 ~ 0.1 (low load)             +30     0
0.1 ~ 0.4 (normal load)           0      0
0.4 ~ 0.6 (high load)            -30    -18
0.6 ~ 0.8 (medium high load)     -40    -24
0.8 ~ 1.0 (too high load)        -50    -30

Table 10. Experiment results of each case

                 Total       Total     Average    Number of
                response   number of   response   requests    Average
Case    Cost      time     requests      time     per cost      TTL

A       7103     478190     452622       1.06       63.72      56.50
B       7754     411042     524793       0.78       67.68      51.60
C       *192     343047     624244       0.55      76.2(1      42.46
D       8109     366767     582246       0.63       71.80      33.37
E       *374     345536     572148       0.60       68.33      40.00

Table 11. Distribution of response time

Case    0~3       3~9        9~15       15~30       30~60       60~

A      93.254    5.045       0.484      0.612       0.445      0.161
B      95.094    3.859       0.360      0.397       0.241      0.049
C      97.200    2.387       0.197      0.154       0.059      0.004
D      96.189    3,162       0.322      0.222       0.081      0.024

Table 12. Experiment result with and without function

                      Total       Total     Average    Number of
                     response   number of   response   requests
Function     Cost      time     requests      time     per cost

with         8192     343047     624244       0.55       76.20
without      8374     345536     572148       0.60       68.33

Table 13. Distribution of response time

Function    0~3      3~9    9~15    15~30   30~60    60~

with       97.200   2.387   0.197   0.154   0.059   0.004
without    96.309   3.151   0.254   0.208   0.061   0.016

Figure 4. An Example configuration file

www.example.com:
  A:
    IP:
        192.168.11.21: 1
        192.168.11.22: 1
        192.168.11.23: 0
        192.168.11.24: 0
        192.168.11.25: 0
        192.168.11.26: 0
    TTL: 60
COPYRIGHT 2017 The Society of Digital Information and Wireless Communications
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2017 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Morigaki, Kota; Saisho, Keizo
Publication:International Journal of Digital Information and Wireless Communications
Article Type:Report
Date:Jul 1, 2017
Words:3835
Previous Article:Vulnerability Assessment of Some Key Nigeria Government Websites.
Next Article:The Influences of Meteorological Parameters on Digital Terrestrial Television (DTT) Signal in the Tropics.
Topics:

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters