Configuring Red Hat Linux for Health Connect
Configure a Red Hat Linux system and install HealthShare® Health Connect as an HL7® integration engine in this step-by-step job aid.
Topic outline
- Configuring Red Hat Linux for Health Connect
- System Requirements
System Requirements
There should be a review of all requirements prior to configuring your environment. While InterSystems typically provides best practice configurations, on occasion, we are asked to quote or provide configurations that allow for an apples to apples comparison with systems that are not enterprise grade and do not provide such features as mirroring. In these circumstances you will want to confirm your configuration is not decided by such a request, but rather what is in the best interest of your facility. If you believe this to be the case for your configuration please request a new configuration, that follows InterSystems best practices guidelines, be provided by your assigned sales team.
1. Configure your hardware environment for RAM and CPU as specified in your site’s hardware architecture guide supplied by InterSystems.
2. In a mirroring environment, you will need a total of N+1 IP addresses where N is the number of servers and the extra one is the one for the virtual IP which will likely be controlled by HealthShare mirroring.
3. You will need at least two network cards per machine, per mirroring best practices.
- 4. With regards to storage, start by allocating the following directories on each of the two servers. Each of these five file systems should be their own LUN; in other words there should be one file system per mount, for a total of five, each with their own set of spindles (no overlap).
- /HealthShare/Database
- /HealthShare/Journal
- /HealthShare/AltJournal
- /HealthShare/Engine — also known as the Write Image Journal, or WIJ, disk
- /HealthShare/Backup — does not necessarily have to be high-grade storage
Ask your sales engineer for the amount of space to allocate to each drive.
- /HealthShare/Database
5. You can translate one LUN to one VMFS (datastore) in a virtual environment such as vSphere (ESXi). When virtualizing, best practice is to have the OS see multiple devices. This is support to segregate journals, databases, and WIJ for performance and resiliency reasons. This is accomplished by presenting multiple VMDKs from that single LUN/VMFS volume to the given virtual machine. Additionally, it is highly recommended to use Paravirtualized SCSI (PVSCSI) controllers and isolate the database VMDKs from the journal VMDKs on separate PVSCSI controllers for optimal performance and provided non-blocking IO / separate queues for databases and journals.
6. In most situations, the default mount options of ext4 and XFS are ideal, especially with the prevalence of all-flash storage arrays. There may be exceptions to tune these values from the defaults because of application specific IO patterns. It is best to contact InterSystems WRC for assistance if performance concerns arise. Continue to follow the best practices for isolating the database from journals on separate devices and mount points. The use of a logical volume manager (LVM) is also highly recommended especially for the database volumes. For best performance of the journals, not using LVM for journals has provided the best journal performance (latency), however your application requirements may vary and using LVM for both journals and databases may be acceptable for your application. Be sure to test your application to confirm the ideal configuration.
- Initial Installation and Set-Up
Initial Installation and Set-Up
7. To install HealthShare Health Connect, you can either log in as user ID root or as su (superuser) to root while logged in from another account and run
cinstall. After installation, it will not be required for the users to continue to have root access.- 8. There are two recommended application-level settings:
- Memory Allocated for Routine Cache (routine buffer) of x MB
- Memory Allocated for 8KB Database Cache (database buffer) of y MB
Refer to your site’s hardware architecture guide supplied by InterSystems for your site-specific routine buffer and database buffer values. After installation succeeds, these values will be configured in the Management Portal. Note that these values are important because they influence other tunings discussed below. You will likely also slightly increase gmheap and locksiz in advanced system memory settings. Again, refer to your site's hardware architecture guide or talk with your Sales Engineer for specific values.
- Memory Allocated for Routine Cache (routine buffer) of x MB
- Setting Up on the OS/Network
Setting Up on the OS/Network
9. In addition to any TCP interface ports, there are three different default ports the application will use, though you can select others if you wish. Make any necessary firewall configuration changes to allow internal access to ports 1972, 57772, and 2188.
10. There should be easy ways of moving files to and from that server (such as file shares or SFTP/FTP), and also an easy way to get to the command line shell (such as PuTTY access or something similar).
11. Mirroring requires that an agent known as ISC Agent is running on both nodes of the mirrored cluster. Once installation completes, you will need to follow these steps in documentation.
- 12. The following is a best-practice list of libraries for you to ensure the OS has. Note that these are not necessarily hard requirements but best practice to include:
- tar
- hostname
- net-tools
- perl
- /usr/bin/dc
- java-1.8.0-openjdk.x86_64
- which
- procps
- findutils.x86_64
- Bash
- SFTP/FTP
- SAR
- GUNZIP
- tar
- Security Considerations
Security Considerations
13. Security considerations should be established before installation consistent with the needs of your specific site. These decisions dictate security settings on both the OS hosting the Health Connect installation and within the Health Connect installation itself. It is recommended that you familiarize yourself with the following resources from documentation, but further consultation with your site's InterSystems account team or the InterSystems Worldwide Response Center may be helpful as well.
14. With regards to the OS, the installation will be performed by root. You can prepare by knowing which users should be able to start and stop Health Connect so that they can be added to the correct group after install. Note that no actual user should be using the irisusr username created upon installation; it is purely for the use of Health Connect itself. Additionally, you must know the OS user that will own the instance.
For more information, review "UNIX® Users, Groups, and Permissions" in documentation.
15. After installation, you will want to review certain security matters inside the Health Connect installation. A few users come by default with the system, depending on level of security specified at installation time, such as SuperUser and _SYSTEM. Depending on the usage, these users should be disabled or have their default password changed. For more information, see "Specifying the Appropriate Privilege Level for the Instance’s Users" in documentation.
- 16. It will generally be important for a complete security model that each user have their own Health Connect username and associated roles/resources that:
- Restrict that user's abilities.
- Are appropriate for that user.
Be aware that a single username used by multiple individuals complicates proper auditing and isolation of privileges.
Any web applications in use have their own security model; for a closer review, see the "Applications" guide in documentation.
- 17. You may wish to discuss additional settings/configurations such as the following with your InterSystems account team:
- Database encryption
- Generic memory heap
- Freeze on journal I/O errors
- Lock table size
- Days of journals to keep
- Regular integrity checks
- Automatic message purging
- Documentation Resources
Documentation Resources
In Step 8, you determined routine and database (or global) buffer values. Let’s use as an example a database buffer of 8 GB and routine buffer of .5 GB. We will use these to calculate settings appropriately.- You will not be using Kerberos Authentication, so no need to worry about that section in the documentation.
- It is recommended that you set SHMMAX equal to the size of: ((database buffer) +(routine buffer) +( 4 MB)).
- Huge Pages default to 2 MB in size. For example, if you had 9 GB of shared memory, you would want about 5000 of them allocated, since it is slightly more than the 9 GB of shared memory allocated as Huge Pages.
- Since we will be using Huge Pages, you do not need to consider the "Locked In Memory” chapter of the RHL notes.
- We should follow the advice for Dirty Page Cleanup per documentation.
- To ensure sufficient swap space, it is recommended to allocate at least 10 GB of swap space.
- You will not be using Kerberos Authentication, so no need to worry about that section in the documentation.