Skip to main content
OutSystems

Size an environment to run the infrastructure management console

You have two options for installing the centralized console to manage your infrastructure:

  1. In a dedicated environment;
  2. In an existing environment.

OutSystems recommends installing LifeTime in a dedicated environment because:

  • No Performance Issues: in a dedicated environment, features like Logging and Performance Monitoring can be used without worrying with the impact on the environment’s performance. This is not true if LifeTime is installed in an existing environment, especially if it is the Production environment.
  • Bidirectional Communication: LifeTime needs to establish bidirectional communication with the other environments in the infrastructure. Having LifeTime installed in an existing environment (e.g. Production) results in the Production environment communicating with other environments, which may be undesirable depending on your security policies. On the other hand, in a dedicated environment LifeTime communicates directly with Production, thus keeping untouched the security constraints you have between infrastructure environments.
  • Internal Network Configuration: In case LifeTime is installed in an existing environment with an , you must not forget to add and maintain the IPs of infrastructure environments in order to allow the communication between LifeTime and those environments. Use the Configuration Tool where you installed LifeTime to manage the internal network.
  • IT Users Permissions: Some IT users have to have access and operate the environment where LifeTime is installed, as an example for installing a plug-in. By having LifeTime installed in a dedicated environment the management of user permissions for that environment is kept independent from the other environments, thus making it clearer and easier to manage, and more secure.

Independently of the installation choice, you should be aware of the following:

  • Scheduler Service: The OutSystems Scheduler service must be running in the LifeTime environment.
  • Migration: Once LifeTime is installed in an environment, it’s not possible to migrate it to another environment. By doing so, you might lose some of LifeTime’s data like application versions and performance monitoring. 

Installing in a dedicated environment

lifetime-dedicated.PNG

In the example above, there is a dedicated environment with a development license, where LifeTime is installed. Notice that the existing environments do not need to communicate between them, i.e., when deploying an application from Development to Test, LifeTime fetches all the data needed from Development and sends it to Test. The Development environment does not communicate directly with Test.

You should choose to install LifeTime on a dedicated environment if: 

  • There are tight security policies that might prevent LifeTime from establishing a bidirectional http/https communication with every environment in the infrastructure.
  • You’re concerned with the impact that LifeTime may have on an existing environment, and adding a new front-end server to isolate LifeTime in your infrastructure, is not an option.

Installing in an existing environment

lifetime-existing.PNG

LifeTime can be installed on any environment, given that it is able to establish a bidirectional http/https communication channel with every environment in the infrastructure. In this example the Production environment is chosen since it usually presents higher security enforcement policy and hardware performance. Nonetheless, the same setup applies to other environments.

In most cases network security policies may prevent you from doing this directly, e.g., the Production environment is isolated from the Development and Test environments. Without further network configuration LifeTime won’t work in these scenarios.

In the next two sections, possible configurations are suggested to ensure the bidirectional http/https communication between LifeTime and environments, keeping the existing security policies of the infrastructure.

Availability through server isolation (Zones)

Add a new Front-end server to the Production environment and isolate LifeTime using the Zones feature in Service Center. Place the new Front-end server in a new virtual LAN to which the Development and Test environments have to have access. This way, you are providing them with access to LifeTime without granting them full access to the Production environment.

Security through network configuration (Firewall rules)

LifeTime allows you to manually define an external address through which it can be reached by the other environments (its “external address”). This address can include a port number, e.g., “srvproduction.mydomain.com:8088”.

Take advantage of this feature to configure your firewall to only allow the Development and Test environments to have access to this particular port. Next, setup a virtual server in your firewall so that the port in the Production environment (for example 8088 in srvproduction) is redirected to the default Web Server port in that same machine.

Sizing the environment

Once you install OutSystems Platform, it automatically starts to collect client-side metrics of the applications running in the Production environment. You can then use LifeTime to customize which applications you want to monitor and which it does not make sense to do so. For the application you choose to monitor the user experience, OutSystems Platform automatically adds monitoring probes, and for each client request to those applications, metrics are collected and stored in the environment in which the application is running for a period of 48 hours.

The LifeTime environment has the same requirements as any other environment, but due to its capabilities you need to understand how to properly size the storage capacity of the server in which it will run. 

You can estimate the storage needed for the applications you are monitoring. Consider you are only monitoring a subset of the applications running in production:
MaximumStorageNeededInProduction = AveragePageViewsPerDayOfMonitoredApps * 2 days * 1100 Bytes

As an example, imagine that the application you are monitoring in Production has 1 million page views in 2 days (distributed between all the applications), the database size will increase approximately 2.05GB. LifeTime periodically copies the collected metrics from Production to its own database and also keeps this copy for a period of 48 hours. However, LifeTime does an aggregation of collected metrics and stores this information permanently. To estimate the storage needed for Lifetime’s database, calculate it as follows:

  • A fixed storage size equal to what was calculated for the above.
  • Add a constant daily growth due to the aggregated metrics:
    AverageLifeTimeDBDailyGrowth = AveragePageViewsPerDayOfMonitoredApps * 100Bytes 

In this example, it would mean that the LifeTime database would start by having 2.05GB, and increase 95 MB daily. Furthermore, if you have LifeTime database set to use full-recovery model (SQL Server) or Archivelog (Oracle), the transaction log will increase with each Insert and Delete operation performed by LifeTime Performance Monitoring.

To estimate the growth of the transaction log, you can calculate it as follows:
TransactionLogsAvgDailyGrowth = AvgDailyPageViewsOfMonitoredApps * AvgRecordSize * 3

In this example, if both the Production database and LifeTime environment database where set to fullrecovery/ archivelog, then each would grow by 3.3GB per day.

Install the infrastructure management console

The infrastructure management console is installed as part of the OutSystems Platform installation. Learn how to install and set up OutSystems Platform.