- 06 Jun 2022
- 4 Minutes to read
- Print
- DarkLight
- PDF
Using Virtual Machine as RIG
- Updated on 06 Jun 2022
- 4 Minutes to read
- Print
- DarkLight
- PDF
Overview
In order to virtualize the Nectar Remote Intelligence Gateway (RIG), it is important that your Virtualization Administrator and your SAN Administrator understand what the RIG is and the behavior of the RIG.
The Nectar RIG is a combination application/database server. Best practices for each tend to apply.
- Because of the RIG's resource requirements, as in a physical server, Nectar recommends that the Operating System be a clean, fresh installation, and the server is not multi-purposed. For example, do not run the RIG and your custom MySQL database application.
- Nectar recommends dedicated hardware whenever possible. Whether it is a blade or traditional Server, please attempt to allocate properly.
- The Nectar RIG functions as a database server:
- The RIG constantly receives poller data and collects RTCP data. A healthy portion of this data is written to disk.
- Nectar recommends individual hardware for the disk subsystems to accommodate this high amount of disk input/output (I/O).
- Storage Area Network (SAN) on the back end:
- If your intention is to run the virtual machine (VM) from the SAN, or put the application on a SAN spindle, Nectar recommends using a logical unit number (LUN) housed on a RAID 1+0 spindle. However, RAID 1+0 versus RAID-5 or RAID-6 is largely a preference of the SAN Administrator.
- Nectar does recommend that you dedicate the spindle (at least initially) until the SAN and Virtualization Administrators have established baselines.
- The Nectar RIG also acts as an Application Server, which means many of the Java components run within memory and only write to disk when instructed to do so. Available memory will have a direct impact on the end-user experience and overall product performance. Please allocate appropriately.
Audience
This guide is intended for system administrators or engineers who are responsible for RIG installation and administration.
Supported Software Versions
- Nectar UCMP v8.7
Technical Notes
Important After upgrading, if you have or plan to manipulate a properties file that uses a file path or directory, then you must verify that you are using the proper backslash (\) or forward slash (/):
- Windows:
Use double backslash (\\), for example, :\\\\
or
Use single forward slash (/), for example, ://
- Linux/iOS:
Use single forward slash (/), for example, //
General Data Protection Regulation
For more information on how to enable auditing to prepare for the General Data Protection Regulation (GDPR), refer to one of the following guides:
Installation Guide
Central Intelligence Platform (CIP) Install/Upgrade Guide
CIP/EIP Administration Guide
Remote Intelligence Gateway (RIG) Administration Guide
Perspective Administration and User Guide
Technical Support
For technical support, contact Nectar in one of the following ways:
- Nectar technical support e-mail address: support@nectarcorp.com
- Visit http://www.nectarcorp.com for additional information.
Use your company's login information to access the documentation.
Product Documentation
- For additional information, see:
Remote Intelligence Gateway (RIG) Administration Guide
- Documents can be found on the Partner Hive:
https://nectar.seismic.com/directlogon.aspx
- To provide feedback on Nectar documentation:
documentation@nectarcorp.com
Technical Specifications
While every Nectar RIG deployment is different, with varying amounts of monitored devices and transaction volume, the following guidelines should be followed:
- Operating System - The Operating System can be Windows, CentOS, or RHEL with the following requirements (English only):
- Windows Server 2016 64 Bit
- CentOS R7 64 Bit
- RHEL R7 64 Bit
For more information, refer to the relevant installation document.
- Random Access Memory (RAM) - Nectar recommends a minimum of 16GB of RAM. However, depending on your design intentions, you may need additional RAM.
- For smaller deployments, once a baseline is established, you may be able to reduce to the RAM allocated to the VM. However, this should never drop below 4GB.
- Processor - Nectar recommends Intel processors.
- Based on experience, a minimum of 3.4GHz (4C/8T) provides quality performance for Windows 2016 Server 64-bit and Nectar Unified Communications Management Platform (UCMP).
- Disk I/O - As previously stated, Nectar recommends either dedicated local drives or a dedicated spindle. As in all database systems, disk usage depends on usage. The disk numbers provided are baseline only.
- I/O Requirements - These will vary based on the size of the system, number of items being polled, and number of concurrent calls (RTCP data collection). Nectar recommends that you monitor and scale your system appropriately. It is recommended to plan for 50-100 IOPS. However, this can vary greatly depending on your configuration.
- Additional Disk Information - By default, the Nectar database writes in 4KB blocks and 32KB in tables, which require long columns defined.1
For more information, see VMWare for reference information.
1. Special thanks to Philip Dispensa.
VMWare
The Virtual Machine File System (VMFS) has the capability for multiple block sizes:1
Block Size | Largest Virtual Disk on VMFS-2 | Largest Virtual Disk on VMFS-3 | Largest Virtual Disk on VMFS-5 |
1MB | 456GB | 256GB | 2TB minus 512B |
2MB | 912GB | 512GB | Invalid block size |
4MB | 1.78TB | 1TB | Invalid block size |
8MB | 2TB | 2TB minus 512GB | Invalid block size |
16MB | 2TB | Invalid block size | Invalid block size |
32MB | 2TB | Invalid block size | Invalid block size |
64MB | 2TB | Invalid block size | Invalid block size |
Table 3-1 VMWare
Note
VMFS-5 has a maximum virtual disk size of 2TB minus 512B. However, pass-through RDMs are supported up to ~60TB.
VMFS-3 uses sub-blocks for directories and small files (files smaller than 1MB). When the VMFS uses all of the sub-blocks (4096 sub-blocks of 64KB each), file blocks are used. For files of 1MB or higher, file blocks are used. The size of the file block depends on the block size you selected when the data store was created.
VMFS-5 uses very small files (files smaller than 1K) that are stored in the file descriptor location in the metadata rather than file blocks. Once the files increase beyond 1K, file sub blocks are used. As VMFS-5 uses sub blocks of 8K rather than 64K (as in VMFS-3), this reduces the amount of disk space used by the small files.
For more information on VMFS-5, see https://kb.vmware.com/s/article/2003813.
1. Reference vmware.com KB reference: 1003565
Citrix XenServer
Xen relies on Ext3 for its Storage Repository (LVM SR).1
Ext3 has a maximum size for both individual files and the entire file system. For the File System as a while, that limit is 232 blocks. Both limits are dependent on the block size of the file system.
The following chart summarizes the limits:2
Block Size | Maximum File Size | Maximum File System Size |
1KB | 16GB | 2TB |
2KB | 256GB | 8TB |
4KB | 2TB | 16TB |
8KB (limits 1) | 2TB | 32TB |
Table 4-1 Limits
For more information on blocks, see https://en.wikipedia.org/wiki/Block.
- Reference Citrix.com XenServer Administrative Guides
- Reference Wikipedia.org ext3 filesystem