In order to efficiently maintain large PortaSwitch installations (which may involve 10 or more servers), it is essential to have a unified interface for managing all the configuration data. Tasks such as IP address changes, relocating services to different physical servers, or simply changing an option that affects functionality can then be performed quickly and easily, with a minimal chance of error.
Configuration server carries out exactly this task, providing an interface for the administrator to view the current configuration, create a new configuration and correctly apply it to all servers, or rollback to an old configuration if a problem has been detected. Another important role of the Configuration server is that it stores “images” of different versions of the software. Each image is the actual content (in a binary format) of a specific version of the software code (e.g., Maintenance Release 75, build 1). When a specific image is loaded, the server will operate under the corresponding software release.
There are several important concepts involved in the configuration management framework. Configuration management is designed to work in the same way whether it is controlling just a single PortaBilling installation (four servers) or a PortaSwitch Clustered (nine servers). In the rest of this section, we will use some examples related to managing the full PortaSwitch configuration (five servers), so as to better illustrate the capabilities of the configuration framework.
A server is an atomic element of processing capacity. It is either a single physical server, or a separate virtual machine, if virtualization is used. In other words, it is basically a host on which PortaSwitch software can be installed and operated. A server has attributes such as a number of available CPUs, disk space, and so on.
Several servers within the same PortaSwitch installation make up a private cloud environment. They all run the same version of the software and, apart from differences in the available hardware resources (e.g., one server has a faster CPU), they are completely interchangeable – i.e., a PortaSwitch software component that can run on server A can also run on server B.
An instance is a copy of an application (e.g., Replica DB, Web server) configured in a particular way and running on a server, i.e., it is a combination of the software code, configuration data, and running processes that provides an actual service.
For example, you can create a Replica DB instance with IP address 1.2.3.4 on server ABC. Or you can create two instances of PortaSIP® processing node on server XYZ. Both PortaSIP® processing node instances have different IP addresses and may differ in other configuration parameters, e.g., one of them has the “start accounting” option turned on while another one has it turned off. Also, you can create a Web server instance on both ABC and XYZ servers. Web server instances have different IP addresses and configuration parameters on different servers.
An application server is a server with one or more running application instances of a certain type. For example, three instances of PortaSIP processing nodes are running on server ABC and one instance of PortaSIP processing node and one instance of the billing engine are running on server XYZ. In this case you have two PortaSIP application servers and one billing engine application server.
An option is a configuration parameter which alters the system’s functionality. Some examples of options would be “When should statistics generation be done,” or “Should the previous balance be included in the invoice’s amount due.” Depending on an option, you can set its value by selecting it from a list, or by typing it into a text field.
For convenience in administration, a default value is provided for most of the options, so that you do not have to supply a value for every single option in order to make the system work.
The full system configuration includes hundreds of different options, so it would certainly be inconvenient to work with them as a single list. Thus options are grouped together in a tree-like structure.
There are global options at the top level of the tree (PortaSwitch (1)), i.e., those that have an effect on all of the components of the system.
Beneath the global level is the application level (2). Each application is presented as a separate node in the configuration tree. These nodes can be grouped under bigger logical nodes, i.e., sip-cluster nodes are grouped under the PortaSIP Cluster node, which is itself is a subnode of ClusterSuite.
Thus, in order to change the allow_reauth option (which is related to the PortaBilling application), you would go to the desired sip-cluster node of the PortaBilling Cluster: PortaSwitch→Cluster Suite→PortaSIP Cluster→sip-cluster@193.168.1.17→MUB2bua.
Finally, there is the instance level (3), which covers options related to a specific instance.
For example, in order to change the Time_Zone option for the porta-billing-web instance with IP address 193.28.87.21, you would go PortaSwitch→Admin→porta-billing-web-1@193.168.1.17.
Some options may have different values in different virtual environments. These options are organized into environment sets, and each set provides control for options that are specific to a particular virtual environment. Virtual environments have their own hierarchy; the Global set (4) is the highest level and individual virtual environments (5) represent the lower level.
Since there are normally many individual options available at each level, for management’s convenience, the options are split into groups (6), and each group contains a small set of options that is related to a single software module or feature.
When the value for an option is defined at a certain level, it is automatically propagated to all of the levels beneath it – if no value is directly specified for this option at a lower level.
This means that the Configuration server chooses which value to use according to the following rule:
- If you specify an option value at a lower level, the Configuration server uses this value and ignores the data specified at a higher level;
- If you leave the option value at a lower level undefined, the Configuration server uses the default value – that is, the one specified at a higher level.
Consider the following example.
In the Configuration Tree panel you can go to the PortaSwitch→Admin node and in the Global set specify 14 as the default value for the DaysToExpireNotification option (you can find this option in the Cards option group).
This value then becomes the default value for all of the virtual environments (those that exist and those not yet created), and PortaBilling will send notifications to customers about their card expiration 14 days before the expiration date.
However, if you need to notify customers in one of your billing environments (e.g., pb) 10 days before their cards expire, set the DaysToExpireNotification option value to 10, exclusively for this environment.
When a configuration is saved, this stores all the options in it – so every stored configuration contains a complete set of data for operating all PortaSwitch components. In order to preserve system integrity it is not possible to directly alter the active configuration (the one currently applied to the servers).
In the case of changes not producing the desired result, it is always possible to roll the system back to its original, stable state.
The process of changing the system configuration is thus divided into several steps:
-
Clone the current configuration tree into a new one.
-
Make the required changes.
-
Now apply this configuration to the system so that it becomes the active one.
Every server in PortaSwitch runs a configuration update agent, which follows commands from the Configuration server. When a configuration update is received, the agent updates the local files, restarts the processes and does everything else required to put the changes into effect.
