Installation
Installation Overview
The N-Squared Advanced Call Distribution software is released in multiple packages to provide the various logical components for a complete platform.
Instructions for installing these packages are given below.
Once installed, the appropriate configuration must be applied in order to bring the platform into service.
OS Support
All N2ACD packages are designed to be installed on Linux-based systems such as Red Hat Linux and Debian. Installation is performed using standard package management tools:
yum
/dnf
andrpm
on Red Hat systems.apt
,apt-get
anddpkg
on Debian systems.
N2ACD is officially supported on the following systems:
- Red Hat systems:
- Red Hat Enterprise Linux 7
- Red Hat Enterprise Linux 8
- Debian systems:
- Ubuntu 18.04 LTS
- Ubuntu 20.04 LTS
In practice, N2ACD will run on any relatively modern Debian-based or Red Hat-based distribution with appropriate adjustments to these installation instructions.
Minimum Server Requirements
Each logical component has slightly different recommended minimum requirements:
Type | Free Disk | RAM | CPU GHz | Notes |
---|---|---|---|---|
GUI | 1Gb | 1Gb | 2GHz | Lightweight web application only. |
API | 1Gb | 1GB | 2GHz | Lightweight API application only. |
SVC | 5GB | 8GB | 2x 2GHz | Resource-intensive under load; scale according to expected call traffic. |
DB | 50GB | 8GB | 2GHz | Moderately intensive under load. |
LDB | 1GB | 1GB | 2GHz | Moderately intensive under load. |
MIG | varies | 1Gb | 2GHz | Resource footprint only used during migration. |
In cases where components are co-installed, resources must be increased to accommodate. See the separate reporting server overview for information on the report service node requirements.
Installation Planning
At minimum, an N2ACD platform must be able to perform the functions of the GUI, API, SVC, LDB, and DB logical components. These may be on separate physical or virtual servers, or co-hosted as required. There may also be multiple instances of any component type, as required for business continuity or expected traffic load.
If the reporting function is desired, the REP and RDB components should also be included in planning.
Should data migration be required, a separate node is not required; these tools may be put onto any N2ACD platform node. Should the migration tools be required, installation on the primary DB node is recommended as these tools communicate primarily with the ACD database. However, this is not required, and these can be installed anywhere (even outside the N2ACD platform itself if necessary).
When planning the footprint of an N2ACD platform, the following recommendations apply for production environments:
- At least two SVC nodes should be present, with each able to take the projected full load of call traffic. This allows maintenance of one node at a time while still providing service. It is expected that the signalling network will perform the appropriate loadsharing of calls during both day-to-day activities and maintenance windows. Note that each call, once started, will be affined to a single SVC node.
- Similarly, if BSS/OSS continuity is required, multiple API nodes can be used in an active/active setup. These can be loadshared to as required by your IP infrastructure.
- If multiple API instances are used, consider also having multiple DB instances to prevent a single point of failure. There must always be a single active primary database used for all provisioning and updates, with as many replica databases as required for API or SVC nodes. It is generally considered good practice for each API and SVC node to have their own database instance, but this is not required.
- At least one LDB instance should be present. Generally, these are paired 1:1 with SVC nodes, but can be installed remotely and/or shared amongst SVC nodes if required. Note that if sharing of LDB instances is used, all SVC nodes will use the same scratch data storage for call processing, which may introduce a bottleneck under load.
- If reporting instances are included, there is no requirement for their database(s) to be synchronised or shared with any API or SVC nodes, as there is no data overlap between them.
- It is not recommended that the SVC and reporting components be co-hosted on a single node, as these are both demanding of resources under load. As SVC nodes carry live customer traffic, these should be prioritised when assigning resources.
Installation Disclaimer
No installation guide can cover every pre-requisite or potential eventuality of package installation. While N-Squared has documented the expected N2ACD installation steps, sometimes a target environment may differ in an unexpected manner and require additional or alternative steps actions to achieve an operational N2ACD environment. Please contact N-Squared to discuss such situations.
Package Availability
Individual packages for manual installation are available on request from N-Squared as part of a licensed software or services agreement.
N-Squared may alternately furnish access details for a software repository that can be integrated with your OS package management tools or satellite repository server directly for ease of installation and maintenance.
Package Versions
All packages distributed by N-Squared will include the following parts to identify them uniquely:
<NAME>
- the name of the package, as referred to in these instructions.<M>
- the major revision number of the package.<m>
- the minor revision number of the package.<p>
- the point release number of the package.<b>
- the build number of the package release.
Package names take a slightly different format, depending on the OS type.
RPM-based Systems | DEB-based Systems |
---|---|
<NAME>-<M>.<m>.<p>-b.noarch.rpm |
<NAME>_<M>.<m>.<p>-<b>_all.deb |
Installation Instructions
Instructions for the installation of each logical component are given in the following sub-sections:
For service nodes:
For Reporting nodes, see the separate instructions.
Additional instructions are available for:
Generally is no required order of installation for N2ACD components. However, in order to complete the appropriate configuration of the platform, all planned components should be fully installed before such configuration is started.
Note that specific steps may have to be performed prior to component installation on Red Hat or Debian systems.