This document describes general performance and scalability guidelines for AVIcode Intercept Studio and AVIcode Advisor (the term "AVIcode Solution" will be used throughout the rest of this document to refer to one or both of these products), and recommends hardware configurations for a variety of loads. Because AVIcode Solutions are built to be flexible and scalable, the hardware requirements for your specific scenario may be more or less than the suggested guidelines presented in this document. A discussion of the factors affecting the performance of each AVIcode Solution component is presented so that you can adapt these guidelines to your specific requirements.
The purpose of this document is to aid you in:
This section helps you decide how to deploy your AVIcode Solution to support your environment and provide the necessary performance and reliability. This section can be used either for initial AVIcode Solution installation or for scaling existing installations.
It is important to establish your needs and expectations for your AVIcode Solution installation. Here are some questions whose answers will help you to choose the most appropriate deployment scenario:
It is comparatively easy to answer questions about the number of computers and applications but it is more difficult to estimate the average rate of events from your monitoring system. Here is an auxiliary table that provides average rates from various configurations:
|Server Count||Application count||Application per Server||Average Rate
(events per second)
Please note that the rates shown above are calculated from a number of known customer databases. Your rate can differ from these numbers depending on the following factors:
After you have estimated the event rate and answered the questions listed above, select the appropriate deployment scenario. The table below will help you:
|Server count||Events Rate||Scenario|
|<= 100||<= 3 events per second||see Simple deployment scenario|
|> 100||> 3 events per second||see Distributed deployment scenario|
If you require extra reliability for your AVIcode Solution, you can also consider using the Load balanced scenario together with scenario you have selected.
If you already have installed an AVIcode Solution and want to install new agents, or add new applications for monitoring, please go to your deployment scenario description and read the ‘Scalability’ section to select an appropriate upgrade scenario
This document describes the guidelines and best practices for the following AVIcode Solution components:
The first 5 components (SE-Viewer Application, SELog web service, Advisor Application and Intercept Reporting Service and MS SQL Reporting Services web service) can be installed on a machine without SQL Server installed. This server will be referred to as the "Application Server" throughout this document.
The last 3 components (SE-Viewer, Advisor databases, MSSQL Reporting Services Database) require that SQL Server be installed on the machine. This server will be referred to as the "Database Server" throughout this document.
In following sections of this document you will find server requirements and deployment scenarios for different environment configurations.
This section contains recommendations that will increase the performance and availability of your Application Servers. You should implement all of them if possible.
The Application Server can host the following components:
The Application Server is a main platform for AVIcode Solutions. Most of the work performed by an Application Server is the process of taking operational data sent by the agents and inserting it into the SE-Viewer Database. The most important resource on an Application Server is the CPU: a multiple-core high-speed processor is recommended. I/O and Memory are not as important as the CPU processor.
Please review the typical hardware configuration suggested for Application Servers in the table below:
|CPU||Intel Core Quad or similar desktop processorIntel Xeon (with 4 or higher number of cores) or similar server processor|
|Memory||>4 GB or higher|
|>I/O||2 drives (7200 rpm or higher) in RAID 1|
Application Servers do not typically require high-end hardware.
Ensure that all Application Servers have a good network connection to the SE-Viewer database and Intercept Agents. Applications Servers frequently send large volumes of data to the SE-Viewer and Advisor databases. Therefore, all Application Servers should normally be on the same local area network as the SE-Viewer database. If possible, deploy all components on the highest speed network backbone that is available.
Choose a Server Operating System for Application Servers for additional performance, reliability and performance tuning capabilities. Consider Microsoft Windows Server 2003 or Microsoft Windows Server 2008.
The SELog web service can be configured to process Intercept Agent data with multiple threads. Ensure that the web service has optimal number of worker threads. It should be equal to one half the number of CPU cores, but not less than one.
This section contains recommendations to increase performance and availability of Database Servers. You should implement all of them if possible.
The Database Server can host the following components:
The Database server is another key component in the overall scalability of an AVIcode Solution. The most critical resource used by the SE-Viewer and Advisor databases is the I/O subsystem, but CPU and RAM are also important:
Please review a typical hardware configuration suggested for Database Servers in the table below:
|CPU||Intel Xeon(with 4 or higher number of cores) or similar server processor|
|Memory||8 GB minimum (16GB or higher recommended)|
|I/O||4 (or more) drives (7200 rpm or higher) in RAID 1+0|
SE-Viewer and Advisor support Microsoft SQL Server™ 2005, Microsoft SQL Server™ 2008, Microsoft SQL Server Express Edition with Advanced Services™ 2005 and Microsoft SQL Server Express Edition with Advanced Services™ 2008. Express Edition is not recommended for medium or large environments due to some restrictions such as database size and resource utilization.
Choose a Server Operating System for Application Servers for additional performance, reliability and performance tuning capabilities. Consider Microsoft Windows Server 2003 or Microsoft Windows Server 2008. If possible, use a 64-bit system.
Recommendations for Application Servers also apply to Database Servers.
Review your local network bandwidth to ensure that all Application Servers have a 1 GB (or 100 MB at a minimum) network connection to the Database Servers and Intercept Agents. Applications Servers frequently send large volumes of data to the SE-Viewer and Advisor databases. Therefore, all Application Servers should normally be on the same local area network as the Database Servers. If possible, deploy all components on the highest speed network backbone that is available.
Your AVIcode Solution can be installed in a virtual environment without any functional restrictions: this is true for both the Application Server and the Database Server. Please ensure that the virtual machine performance is sufficient according to the recommendations provided in the Hardware, Software and Network sections in this document. However, we recommend using a physical server for the Database Server instead of a virtual system to achieve optimal performance.
An AVIcode Solution can be deployed using various scenarios. The choice of deployment scenario typically depends on the following factors:
This section will describe typical scenarios, beginning with the simplest. Each scenario will include the maximum number of servers and maximum event rate that can be supported for the Application Server. These characteristics (like the number of agents per SE-Viewer or databases per Database Server) can be used to determine which deployment best fits your environment.
Please note that characteristics provided in current document are not hard limits, they are provided as a guideline. You may find that in your environment you should apply a more simple or more distributed scenario to provide appropriate availability.
For a simple deployment, both SE-Viewer and/or Advisor are installed on single Application Server. The MS SQL Reporting Services web service is also is installed on the Application Server and must be configured to use a remote database.
SE-Viewer, Advisor and MS SQL Reporting Services databases are hosted on a single Database Server.
You can choose this scenario if you have approximately 100 agents with total rate of operational events not exceeding 3 per second.
If high reliability for event processing and delivery is important for your organization, please consider using the Load balanced scenario together with this current scenario.
If you scale up your environment by installing additional machines each with an Intercept Agent, and the new total number of machines exceeds 100 (or the estimated rate of events exceeds 3 events per second), you should consider extending your environment and implementing the Distributed deployment scenario.
Limits for Application Server, SE-Viewer database
|Server Count||<= 100|
|Input Rate||<= 3 events per second|
Distributed deployment scenario
The distributed scenario is proposed for large-scale monitoring systems with more than 100 agents. As you can see in the diagram above, this scenario employs multiple SE-Viewer databases but just a single Advisor database for all application servers. The agents should be divided so that for each Application Server there are 100 agents.
For each Application Server, also install one SE-Viewer, Advisor and Intercept Reporting Service application. In this scenario each SE-Viewer/SELog works with its own separate database. All instances of the Intercept Reporting Services will share a single Advisor database.
Each database server can support up to 3 to 4 SE-Viewer databases simultaneously, especially if each database uses a separate disc volume for the data file. The number of databases that are supported by a single Database Server will also depend on the total rate of events from your agents.
If possible, store fewer SE-Viewer databases (1 or 2) on the Database Server with the Advisor database and MS SQL Reporting Services database. If the number of SE-Viewer databases is more than 12, consider placing the Advisor database and the Reporting Services database on a separate server due to the large amount of data that will be inserted from multiple Intercept Reporting Services.
If high reliability is important for your organization, please consider using the Load balanced scenario for the application and database servers.
You should add an additional Application Server and SE-Viewer database 1) for every additional 100 agents you have installed or 2) if you exceed the 3 events per second threshold per database.
You should add an additional Database Server for the SE-Viewer databases 1) for every 300-400 agents, or 2) in the event you are exceeding 12 events per second total rate per Database server .
If you have more than 12 SE-Viewer databases we recommend allocating a separate Database Server for the Advisor database and MS SQL Reporting Services database.
Limits for single application server
|Agent Count||<= 100|
|Input Rate||<= 3 events per second|
Limits for single SE-Viewer database
|Agent Count||<= 100|
|Input Rate||<= 3 events per second|
Limits for single database server
|SE-Viewer Database Count||<= 4|
|Total Agent Count||<= 400|
|Total Input Rate||<= 12 events per second|
This scenario can be used with both the Simple deployment scenario and the Distributed deployment scenario. The main goal is to provide more reliability and availability to the system by adding redundancy. Load Balancing can be applied to both Application Servers and Database Servers.
To implement redundancy for an Application Server, you must install an additional Application Server which is a copy of the initial server, except that Intercept Reporting Services is set to manual mode and stopped. Implement Load Balancing (e.g. using the Windows Server 2008 Network Load Balancer) between the web applications SE-Viewer, Advisor, and SELog. Your Load Balancer must be configured to use sticky sessions so that the load balancer uses the same internal server for each request from a certain client. This is needed for the SE-Viewer and Advisor applications because they use in-memory session states and application states. Sticky sessions are not required for SELog web-service however.
This load balanced scenario provides increased reliability: if one of the Application Servers fails, then the other server can pick up the additional load. In the event that the main Application Server fails, you must remember to start Reporting Services on the second server.
Manual load balancing without failover
If you do not need failover for your Application Servers, you can implement Load balancing manually. To do this, install an additional Application Server and connect it to the same SE-Viewer database that is used for the Application Server that is being load balanced. On the second server, set Intercept Reporting Services to manual. Configure ½ of the agents to work with the second server. Please take into account that this solution does not provide failover, it just allows distributing the load between 2 Application Servers.
For any Distributed Deployment, Load Balancing can be implemented for a portion of the application servers, e.g., the production servers.
Database servers may become unreliable in the event of server side locks that lead to events being skipped (along with slowing down of SE-Viewer and Advisor), or missing all events (in the event that the database server fails). There are a several ways to increase your Database Servers reliability:
Both “Active/Active” and “Active/Passive” schemas are supported. Select the appropriate schema based on your average database load.
Last update: Friday, December 03, 2010 01:28:44 PM