© IEEE, 2013

2013 IEEE International Conference on Anti-Counterfeiting, Security, and Identification (ASID 2013). October 25-27, 2013, Shanghai, China

Proceedings, pp. 7-10. ISBN 978-1-4799-1110-3, IEEE Catalog Number: CFP 1320C-CDR

Slides

Evaluation of Distributed Security Systems Server Modules Peak Workload

Sergey Panasenko

ANCUD Ltd.
Moscow, Russia
serg@panasenko.ru

Abstract: In this paper we examine distributed security systems with dedicated server modules which perform client modules managing and monitoring. Distributed security systems provide optimal solutions for various problems such as user authentication and system components access control.
Workload of distributed access control systems server modules has distinct peak periods because an amount of user authentication requests is definitely unbalanced in time. We analyze workload profile and evaluate peak and average workload of distributed access control system server modules. Then we generalize the calculation of peak workload to any distributed security system with dedicated server modules.
Knowledge of server modules peak workload may be used to determine the sufficient level of server resources to perform the predefined set of operations while managing client security modules. If peak workload exceeds server resources (allocated for management of distributed system modules) at any time period, it is required to increase performance of server hardware or to design a server cluster. An alternative way is making server workload uniform to avoid distinct periods of peak workload.

Keywords: distributed security system; access control system; centralized management; peak workload; average workload; user authentication; peak performance; resource requirements

I. Introduction

Distributed security systems allow to solve a variety of security problems. In this paper we examine distributed security systems with dedicated servers. The servers manage and monitor client modules, which, in their turn, may perform various security functions, e. g. access control modules, anti-virus software, firewalls, virtual private network modules, intrusion detection/prevention sensors, identification and authentication modules and so on (some examples were described in [1-3]).
The list of possible problems is being expanded as the spectrum of information security threats grows. In all these cases the server modules perform similar set of operations. Let us consider distributed access control systems as an example.
The distributed access control system may consist of distributed access control hardware modules (access control boards) with centralized management by the dedicated server (Fig. 1). The server may contain at least the following information required to perform user authentication requests from access control boards [1]:

• a register of all managed hardware modules;
• a register of users, who are permitted to gain access on each module;
• user accounts and so on.

Fig. 1. Distributed access control hardware with centralized management

Server modules of such distributed system may also perform many additional service functions, including real-time monitoring hardware modules and authenticated users or storage of event logs received from distributed modules.
Let us analyze a workload profile of distributed security system server modules. Such profile allows us to develop organizational and technical measures to increase the peak performance of server modules.

II. Server Modules Workload Profile

Goals of server modules are setting the workload profile. It can be supposed that in the most cases the workload has distinct peak periods (excluding several non-typical applications). The main peak interval is a short time period at the beginning of working time. This peak appears because of simultaneous authentication of users in access control boards. Consequently, immediately after that the access control boards connect server modules requesting user authentication. Server distributes its resources to process such requests.
A typical workload/time dependence graph of a database server is depicted on Fig. 2 [4, 5]. We can see two distinct workload peaks at the beginning of working day and at the end of lunch break; during other periods of working time the workload is close to average. Such workload profile is fully sufficient to evaluate the workload of distributed access control systems server modules in most typical cases.

Fig. 2. Typical workload/time dependence graph

Reference [6] discusses the dependence of a datacenter multi-processor server processing time usage on a daytime with similar conclusions.
During the periods of peak workload server modules of typical distributed systems may have an order of magnitude greater workload than an average one on same modules [7]. Therefore, the problem of server modules peak workload must be determined and solved while designing the distributed system including beforehand calculation of required system resources when possible. Otherwise, using the storage subsystem as an example, “if the storage subsystem is not provisioned for its peak load, its performance during peaks degrades significantly, resulting in I/O operations having significant latency” [7].
The examples of peak workload periods of the storage subsystem and consequent delays (up to two orders of magnitude relative to the average workload) in response time during the peaks are shown on Fig. 3 and 4 [7].

Fig. 3. Request rate over 24-hour period (logarithmic scale)

Fig. 4. Response time over 24-hour period (logarithmic scale)

It is widely known [7] that peak workload periods are unpredictable in a general case. However, such periods of distributed security systems servers workload may depend on several factors; all of the factors are determinate enough to evaluate servers workload during peak periods and to evaluate resource requirements to process all requests during the peaks. These factors include at least the following:

• how tough is the work schedule of employees, who are the users of distributed security system modules (this is especially true for distributed access control systems or similar systems with intensive requests to server modules while loading client computers of the distributed system); i. e. how contemporaneously client modules start to load at the beginning of working day; as discussed above, similar peak workload may occur at the end of the lunch break if it is in the same time period for all users of the system;
• even although the work schedule is semi-free (with non-simultaneous beginning), the same workload peaks may arise as a result of some external factors, e. g. because of public transport schedule (if it is used by significant number of employees): suburban trains, buses and so on, or when corporate transportation delivers employees to office;
• a schedule of service operations on client modules if distributed system server modules are involved into such operations; the examples are software and anti-virus databases updates, client modules self-assessment sequences, background checking of data consistency etc.

We should also take into consideration the periodicity of peak workload periods that is appropriate to various applications of client-server architecture [6]. Preliminary analysis of workload profile and attempts to predict peak workload periods may help to develop optimum organizational and technical measures which allow to smooth out the peaks and/or to increase server modules peak performance.

III. Evaluation of Server Modules Peak Workload

Average and peak workload of distributed access control systems server modules should be evaluated before their deployment. This allows to determine an amount of required resources and to provide clustering. Also, this helps to balance the server modules workload if needed. We start from evaluation of distributed access control system server modules workload to generalize the principles of such evaluation over any distributed security system subsequently.

A. Determining peak workload of distributed access control systems

Let us assume that a distributed access control system consists of N_C access control boards. The access control system works 24 hours a day. Every access control board authenticates a user N_A times a day in average (we can use another time period instead of a whole day without notable impact on the formulae listed below). We can introduce several additional variables:

• T_A – a number of time units (e. g. milliseconds) required to process one authentication request from access control board on a server module in average;
• P_A – average resources of the server needed while authentication request processing per time unit; T_A and P_A represent pure resource requirements – without taking into consideration any potential parallel tasks;
• T_T – the number of time units per a day.

It is clear how to define an average server workload per time unit (P_avg) using the notation listed above:

                                (1)

We can also assume that an average server workload in peak periods (P_peak) does not vary significantly during peak workload periods independently from the workload profile. Let us introduce more additional variables:

• T_P – the length of peak workload periods in a day in aggregate;
• C_P – a coefficient, which is defined like a ratio of a number of user authentication requests during peak workload periods to a total number of such requests per a day; the value of C_P depends on specifics of distributed access control system application; in companies with strict working schedule it may be close to one.

P_peak may be represented via P_avg as follows:

     (2)

All variables of the right part of Eq. 2 may be determined easily (including the value of P_A, which may be defined using the system metrics [8] of operating systems installed on servers of distributed access control systems or using specific diagnostic and performance evaluation tools [9, 10]). Consequently, the peak workload of distributed access control systems servers may be calculated by Eq. 2 in practice.
In the case, when the server workload has non-uniform profile and varies significantly even during the peak workload periods, to calculate the maximum server workload it is possible to determine second-order peaks during peak workload periods by reducing the value of T_P to capture the second-order peaks only. The coefficient C_P should also be corrected, because the shorter T_P, the smaller C_P (and vice versa: C_P 1 when T_P T_T).
We do not take into account any details of server software architecture and functioning. For example, the Eq. 2 does not cover possible resource expenses on switching contexts in multithreaded environment – under normal conditions such expenses may be considered negligible compared to the value of P_A.

B. Generalization on distributed security systems with centralized management

We can generalize the calculation of peak workload for distributed access control system (which is a special case of security system) to a general case of distributed security systems with dedicated server modules.
When considering an arbitrary distributed security system it is impossible to suppose that the server performs user authentication requests only. However, we can assume that the server processes several classes of operations (as a result of client modules requests) with predefined or measurable resource requirements. Every class of server operations may be characterized by the following set of variables:

• N_n – an average amount of n-type operations for each client module during a day;
• T_n – an average amount of time units required to perform one n-type operation;
• P_n – average resources of the server needed while processing one n-type operation per time unit.

We can calculate an average workload of distributed security system server by the following formula:

                  (3)

where the product  indicates resources of the server required to process all n-type operations during a day.
Before determining peak workload of distributed security system servers, note that in common case various types of operations may produce different peak workload periods. As an example, consider the server which manages access control boards as well as anti-virus software installed on client computers (Fig. 5). In this case, it can be supposed that user authentication requests and updating of anti-virus bases make several different workload peaks. Besides that, an analogue of the coefficient C_P for each type of operations depends on certain time period T (for which peak workload is to be calculated) in addition to dependence on its length T_P.

Fig. 5. Example of distributed security system with two main purposes

We denote this coefficient (which represents a ratio of a number of n-type operations during the time period T with length of T_P,T time units to a total number of n-type operations per a day) as C_n,T.
Workload of such management server is depicted on Fig. 6, where the line 1 represents typical workload of distributed access control system server, and the line 2 represents typical server workload while updating anti-virus bases. The first line has two peak workload periods; the second line has one such period only. Two of three peak workload periods may be coinciding (as shown on Fig. 6). Consequently, in such hypothetical system the only period that should be analyzed is the period T, which represents all periods of peak workload: T₁ and T₂. An alternate variant is to analyze workload during T₁ and T₂ periods separately without joining them into one period T.

Fig. 6. Workload of the server that manages access control boards and anti-virus software

As a result, an average server workload for n-type operations processing during the peak time period T per time unit P_peak(n,T) may be determined as (with taking into consideration Eq. 2 and Eq. 3):

                         (4)

and an average server workload for all types of operations during the same time period T per time unit may be calculated as follows:

                       (5)

Equation 5 allows to calculate an average server workload during any time period, which is not necessary a peak period. This formula may be used to determine the sufficient level of server resources to perform the predefined set of operations while managing client security modules. If the value of P_peak(T) exceeds the server resources (allocated for management of distributed system modules) at any time period, it is required to increase performance of server hardware or to develop a server cluster. An alternative way is making server workload uniform to decrease the coefficient C_P for any time period and, consequently, to avoid distinct peak workload periods.
The following conclusion may be drawn: peak workload periods may be predicted and evaluated early during the development of distributed security systems server modules. This allows to determine the sufficient level of server resources before system deployment.

Acknowledgment

We would like to thank Anna Kuznetsova and Sergey Smagin for reviewing and valuable comments on this paper.

References

1. S. Panasenko, “The principles of distributed information security systems server modules development, part 1,” Points of Information Security, no. 2, pp. 30-34, 2009. (In Russian.)
2. “Network and Security Manager. Datasheet,” http://www.juniper.net, 2008.
3. A. Kolesov, “Infrastructures for identification and access rights control,” BYTE/Russia, no. 2, pp. 18-23, 2007. (In Russian.)
4. “Oracle8i designing and tuning for performance. Release 2,” http://download.oracle.com, 1999.
5. “Oracle database performance tuning guide. 10g release 2,” http://download.oracle.com, 2008.
6. X. Zhu, Z. Wang, and S. Singhal, “Utility-driven workload management using nested control design,” in Proceedings of American Control Conference, Minneapolis, June 2006.
7. D. Narayanan, A. Donnelly, E. Thereska, S. Elnikety, and A. Rowstron, “Everest: scaling down peak loads through I/O off-loading,” http://research.microsoft.com.
8. M. Russinovich and D. Solomon, Windows internals: including Windows Server 2008 and Windows Vista. Microsoft Press, 2009.
9. “Sun Java System Application Server 9.1 Deployment Planning Guide,” http://dlc.sun.com, 2007.
10. P. Barford and M. Crovella, “Generating representative web workloads for network and server performance evaluation,” http://www.cs.bu.edu, 1997.