© 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
Evaluation of Distributed Security Systems Server Modules Peak Workload
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
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 :
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  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 . 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” .
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 .
Fig. 3. Request rate over 24-hour period (logarithmic scale)
Fig. 4. Response time over 24-hour period (logarithmic scale)
It is widely known  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:
We should also take into consideration the periodicity of peak workload periods that is appropriate to various applications of client-server architecture . 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 NC access control boards. The access control system works 24 hours a day. Every access control board authenticates a user NA 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:
It is clear how to define an average server workload per time unit (Pavg) using the notation listed above:
We can also assume that an average server workload in peak periods (Ppeak) does not vary significantly during peak workload periods independently from the workload profile. Let us introduce more additional variables:
Ppeak may be represented via Pavg as follows:
All variables of the right part of Eq. 2 may be determined easily (including the value of PA, which may be defined using the system metrics  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 TP to capture the second-order peaks only. The coefficient CP should also be corrected, because the shorter TP, the smaller CP (and vice versa: CP 1 when TP TT).
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 PA.
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:
We can calculate an average workload of distributed security system server by the following formula:
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 CP 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 TP.
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 TP,T time units to a total number of n-type operations per a day) as Cn,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: T1 and T2. An alternate variant is to analyze workload during T1 and T2 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 Ppeak(n,T) may be determined as (with taking into consideration Eq. 2 and Eq. 3):
and an average server workload for all types of operations during the same time period T per time unit may be calculated as follows:
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 Ppeak(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 CP 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.
We would like to thank Anna Kuznetsova and Sergey Smagin for reviewing and valuable comments on this paper.