4.8. On-premises Considerations
When IRM is deployed onto a customer's server, as compared to running in Planet's software-as-a-service environment, there are some additional considerations that the customer should be aware of.
Minimum hardware requirements
For enterprise-scale installations, the main IRM host machine should meet the following minimum requirements:
-
Operating System: Windows Server 2016 (using Windows Server 2012 or 2019 is possible, but requires a different distribution of IRM's Docker containers)
-
CPUs: 2 Intel 3.2 GHz 8-core Xeon processors (Intel® Xeon® E5-2667 v4 or better)
-
DRAM: 128GB 2666MT/s dual bank
-
Disk: 3 480GB general-purpose SSDs in a RAID 5 configuration
Less powerful hardware may work, but will likely result in degraded performance depending on the amount of IRM data and number of IRM users. To ensure the best results, please discuss your proposed hardware and target data size with Planet Associates personnel.
In addition to the main server, IRM can make use of an optional, separate map tile server, which supports the display of built-in world-wide maps in the IRM Global Console. Customers who use only a single Site or a small number of Sites and/or Areas in a single geographic region, like a campus, likely do not need to use this feature. Also, basic fixed-background map images in Sites and data imported from CAD or shapefiles to IRM Sites do not require this server, but a future version of IRM may support built-in world-wide maps in Sites and the map tile server would be required for that feature to work. Such maps are most useful for customers with extensive outside plants and/or WANs.
Note that even though IRM software components run in containers (see below), a separate physical machine is needed for the map tile server because it requires Linux and at least currently, Docker for Windows does not allow running both Windows containers and Linux containers at the same time. This is a Docker for Windows limitation.
The map tile server has significantly reduced requirements compared to the main IRM server:
-
Operating System: recent LTS Linux, such as CentOS 7.6 or RHEL 7.6
-
CPU: Intel 2.2 GHz 4-core processor
-
-
Docker containers
IRM is distributed only as a suite of Docker Windows container images, via a private Docker registry. Docker for Windows requires that the Windows Server Core image used to create the container images must match the host software version, and Planet is currently using Windows Server Core for Windows Server 2016. It is possible for IRM to run against Windows Server 2012 or Windows Server 2019, but but the container images would need to be rebuilt and tested with the appropriate Windows Server Core. Please contact Planet Associates if you require IRM to be run on an OS other than Windows Server 2016.
The host OS must have Docker for Windows installed. If it doesn't come pre-installed, it can be installed as part of the process of installing IRM. This topic is covered in more detail in the IRM On-premises Installation Guide.
Installation overview
Details of how to install IRM are covered in the IRM On-premises Installation Guide, but this sub-section provides a high-level overview.
To install IRM, a machine that is connected to the internet must be used, at least initially. The user first downloads a single PowerShell script, and running that script fetches a suite of other PowerShell scripts that make it easy to install and administer IRM. Following the IRM On-premises Installation Guide, the user runs a small number of scripts that download, configure, and start the IRM containers. The core technology that allows the IRM system to work using a set of cooperating containers is Docker Compose. The containerized approach and the scripts make the process quite straightforward, though IRM is a large and complex system with many different components -- a full install requires more than ten containers.
Depending on the customer's requirements, the system can be used directly from the machine on which it's initially installed, or it can be migrated to another system that does not have access to the Internet. Migrating an IRM installation is also a relatively simple task due to the availability of additional scripts to save the IRM container images to local files, which can then be copied to removable media or drives and transported to a system that does not have Internet access. Finally, a last script can reconstitute the IRM system on the Internet-disconnected machine. Of course, it is also possible to perform software upgrades on such disconnected systems, but a similar set of steps to the original installation must be followed.
Network requirements
The containerized environment and the fact that all IRM containers can be hosted on the same physical machine means that the network and other infrastructure requirements for IRM are minimal. IRM is a pure web application and all traffic between the end user's web browser plus the IRM Web Client to the IRM server is over HTTPS on port 443 or HTTP on port 80, and HTTPS or HTTP on port 8080 for REST API traffic. If necessary, port 8080 can be replaced by a different port. Contact Planet Associates for details of how to configure such access.
Backups
Of course, IRM data needs to be backed up on a regular basis. There are different ways to approach this task:
-
make complete images of the host computer's data drive (the one holding the IRM containers, usually D:\)
-
back up all the files on the host computer's data drive
-
back up the IRM MongoDB and PostgreSQL databases, plus specific folders for file attachments, report-related files, export-related files, etc.
Planet Associates recommends daily backups of all the files on the host computer's data drive (the one holding the IRM containers, usually D:\).
Library and report file updates
For on-premises customers, IRM has a manual mechanism for updating the IRM Library and report files via distribution zip files. See the
Maintenance section in this Administrators' Guide for more details on these mechanisms.
Disconnected environment
To support certain customers, IRM is capable of running in a network environment that is disconnected from the Internet. IRM has specific features and attributes to make operating in a disconnected environment possible:
-
IRM container images can be updated via a proxy machine that is connected to the Internet, then container images can be moved via removable media to a disconnected system. See the IRM On-premises Installation Guide for additional details.
-
IRM includes features for Library and report file updates as mentioned above
-
The IRM license enforcement mechanism does not depend on connection to Planet Associates servers
-
IRM includes packaged versions of the various third-party library on which it depends
-
IRM can make use of its own map tile server, which can also be deployed on the customer's disconnected network
-
IRM generally does not require communication with IRM or any third-party servers to operate
While IRM is designed to operate in disconnected environments, customers should not underestimate the challenges inherently imposed by such environments in terms of software updates, Library updates, and dealing with operational issues that inevitably arise in a product as large and complex as IRM. In these environments, to ensure smooth operations, IRM requires system administration and support staff with adequate knowledge and experience in the following areas:
-
Windows system administration
-
Docker networking and container administration
-
MongoDB and PostgreSQL administration
-
IRM system administration
-
Administration of any specific third-party software that IRM is integrated with in the installation, such as trouble ticketing or network discovery software
To ensure proper skills and coverage, Planet Associates strongly recommends taking advantage of Planet's on-site support staff.
On-premises environments that are connected to the Internet have similar requirements of administration knowledge and experience, but depending on the details of the IRM support and maintenance contract that is in place, it may be possible for Planet Associates off-site support personnel to assist with some issues directly on the customer's servers. Of course, with disconnected deployments that isn't possible.