• Operating Systems

• Additional Components

  • OpenJDK version 8 or higher

  • EPEL

  • wget or curl

  • Kernel headers

  • Kernel development packages

  • log4j 2.15.0 or higher

• NVIDIA hardware and software (for GPU installs only)

  • Hardware: Ampere, Turing, Volta, or Pascal series GPU cards. HEAVY.AI recommends that each GPU card in a server or distributed environment be of the same series.

  • NOTE: The recommended NVIDIA driver for all supported HEAVY.AI versions is 535.

  • Software (Run nvidia-smi to determine the currently running driver):

• Up to date Vulkan drivers

• Supported web browsers (Enterprise Edition, Immerse). Latest stable release of:

  • Chrome

  • FireFox

  • Safari version 15.x or higher

The Enterprise Edition of HEAVY.AI contains a rich set of analytical and location intelligence features at various capacity levels. A HEAVY.AI license provides the ability to use these features at specific capacities (e.g. specific number of GPUs) for a specified period of time, typically based on an end user license agreement.

A new license version and mechanism was implement in the 8.0 HEAVY.AI release. This is a breaking change that would require all enterprise customers to request a new license before upgrading to the 8.0 release. This document provides details about the new licensing options and provides guidance on how to decide on the best licensing option for your organization and how to request and apply an appropriate license.

Starting at the 8.0 release, HEAVY.AI supports two types of licenses: Node Locked Licenses and Floating Licenses.

Node Locked Licenses

Node locked licenses restrict the use of the HEAVY.AI platform to a single machine. A node locked license is generated for a specific machine that an organization has set up to run their HEAVY.AI instance and is appropriate for organizations with single instance deployment agreements with dedicated machines for HEAVY.AI use.

In order to get started with a node locked license, a unique machine identifier called a “Host ID“ has to be derived from the machine on which HEAVY.AI will be running. The Host ID can be displayed using the heavysql “\status” command. For example:

$ echo "\status" | ./bin/heavysql -p HyperInteractive
License invalid
Not connected to any database. See \h for help.
Server Version                      : 7.2.4 Enterprise Edition
Host ID                             : 1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqr
--------------------------------------------------
Server Name                         : example.com
Server Start Time                   : 2024-03-01 : 00:00:00

The HEAVY.AI instance that the heavysql client connects to has to be launched on the machine in question and with privileged access (e.g. using “sudo“) in order to view the Host ID and use a Node Locked License. See the “Using systemd to Launch HeavyDB with Privileged Access” section for more details about how to launch HeavyDB with privileged access using systemd. For HEAVY.AI docker deployments, no additional deployment steps are required.

If you intend on getting a Node Locked License, create a new Node Locked License Request support ticket and provide the Host ID in the ticket description.

Floating Licenses

Floating licenses allow for the deployment of the HEAVY.AI platform on multiple machines on the same network. Floating licenses require the deployment of another type of server called a “License Server”. The License Server monitors the use of HEAVY.AI licenses and resources across deployments and determines whether a deployment should proceed based on license restrictions related to the number of allowed deployments and total resources consumed across all deployments. When all license specified resources are used to the limit, no additional HEAVY.AI deployments will be allowed. A floating license is appropriate for organizations who have multiple instance deployment agreements or single instance deployment agreements but cannot rely on a dedicated machines for HEAVY.AI use (e.g. cloud deployments on non-dedicated hosts).

Similar to the process for Node Locked License deployments, a Host ID has to be derived for the machine on which the License Server will run (i.e. the license server is node locked). The steps for getting the Host ID is the same as those mentioned in the “Node Locked Licenses“ section above. If you intend on getting a floating license, create a new Floating License Request support ticket and provide the following information in the ticket description:

1. Host ID of machine on which the License Server will be running.

2. Hostname of License Server (as seen by the HeavyDB instances).

3. License Server port number (as seen by the HeavyDB instances).

License Server Deployment

The License Server can be deployed using the heavyai/heavyai-license-server docker image. A directory containing an initially empty storage directory and license_server.conf file should be bound to the /var/lib/heavyai path. Example deployment:

$ mkdir -p ~/heavyai-license-server/storage
$ echo "port = 6278" > ~/heavyai-license-server/license_server.conf

$ docker run --rm -p 6280:6280 \
  -v ~/heavyai-license-server:/var/lib/heavyai \
  heavyai/heavyai-license-server

Upgrade Scenarios

No Existing HEAVY.AI Deployments

Customers with no existing HEAVY.AI deployments can follow the above steps for getting either a Node Locked or Floating License using the latest HEAVY.AI release.

Existing License on a HEAVY.AI 7.x.x Deployment

Customers with existing 7.x.x HEAVY.AI deployments should follow the above steps for getting either a Node Locked or Floating License using their existing deployment. An upgrade to the latest (or any 8.0 and later releases) should occur only after getting a new license from the Customer Success team. The old heavy.license file should be deleted or renamed before attempting to upgrade.

Existing license on a HEAVY.AI 6.x.x deployment

Customers with existing 6.x.x HEAVY.AI deployments should first upgrade to a 7.0.x release and follow the steps specified in the above “Existing license on a HEAVY.AI 7.x.x deployment“ section.

Using systemd to Launch HeavyDB with Privileged Access

In order to launch HeavyDB with privileged access using systemd, the [Service] User and [Service] Group fields in the /lib/systemd/system/heavydb.service file (see CUDA Compatibility Drivers | v7.2.4 (latest) | HEAVY.AI Docs for more details) should be removed. The updated file should look like:

[Unit] 
Description=HEAVY.AI database server 
After=network.target remote-fs.target

[Service] 
Environment=LD_LIBRARY_PATH=/usr/local/cuda-11.0/compat:$LD_LIBRARY_PATH
WorkingDirectory=/opt/heavyai
ExecStart=/opt/heavyai/bin/heavydb --config /var/lib/heavyai/heavy.conf 
KillMode=control-group 
SuccessExitStatus=143 
LimitNOFILE=65536 
Restart=always

[Install] 
WantedBy=multi-user.target

After updating the service file, force reload of the systemd configuration by executing the following command:

sudo systemctl daemon-reload

The amount of data you can process with the HEAVY.AI database depends primarily on the amount of GPU RAM and CPU RAM available across HEAVY.AI cluster servers. For zero-latency queries, the system caches compressed versions of the row- and column-queried fields into GPU RAM. This is called hot data (see Hot Records and Columns). Semi-hot data utilizes CPU RAM for certain parts of the data.

System Examples show example configurations to help you configure your system.

Optimal GPUs on which to run the HEAVY.AI platform include:

• NVIDIA Tesla A100

• NVIDIA Tesla V100 v2

• NVIDIA Tesla V100 v1

• NVIDIA Tesla P100

• NVIDIA Tesla P40

• NVIDIA Testa T4

The following configurations are valid for systems using any of these GPUs as the building blocks of your system. For production systems, use Tesla enterprise-grade cards. Avoid mixing card types in the same system; use a consistent card model across your environment.

Primary factors to consider when choosing GPU cards are:

• The amount of GPU RAM available on each card

• The number of GPU cores

• Memory bandwidth

Newer cards like the Tesla V100 have higher double-precision compute performance, which is important in geospatial analytics. The Tesla V100 models support the NVLink interconnect, which can provide a significant speed increase for some query workloads.

For advice on optimal GPU hardware for your particular use case, ask your HEAVY.AI sales representative.

HeavyDB Architecture

Before considering hardware details, this topic describes the HeavyDB architecture.

HeavyDB is a hybrid compute architecture that utilizes GPU, CPU, and storage. GPU and CPU are the Compute Layer, and SSD storage is the Storage Layer.

When determining the optimal hardware, make sure to consider the storage and compute layers separately.

Loading raw data into HeavyDB ingests data onto disk, so you can load as much data as you have disk space available, allowing some overhead.

When queries are executed, HeavyDB optimizer utilizes GPU RAM first if it is available. You can view GPU RAM as an L1 cache conceptually similar to modern CPU architectures. HeavyDB attempts to cache the hot data. If GPU RAM is unavailable or filled, HeavyDB optimizer utilizes CPU RAM (L2). If both L1 and L2 are filled, query records overflow to disk (L3). To minimize latency, use SSDs for the Storage Layer.

You can run a query on a record set that spans both GPU RAM and CPU RAM as shown in the diagram above, which also shows the relative performance improvement you can expect based on whether the records all fit into L1, a mix of L1 and L2, only L2, or some combination of L1, L2, and L3.

Hot Records and Columns

The Hardware Sizing Schedule table refers to hot records, which are the number of records that you want to put into GPU RAM to get zero-lag performance when querying and interacting with the data. The Hardware Sizing Schedule assumes 16 hot columns, which is the number of columns involved in the predicate or computed projections (such as, column1 / column2) of any one of your queries. A 15 percent GPU RAM overhead is reserved for rendering buffering and intermediate results. If your queries involve more columns, the number of records you can put in GPU RAM decreases, accordingly.

Projection-only Columns

HeavyDB does not require all queried columns to be processed on the GPU. Non-aggregate projection columns, such as SELECT x, y FROM table, do not need to be processed on the GPU, so can be stored in CPU RAM. The Hardware Sizing Schedule CPU RAM sizing assumes that up to 24 columns are used in only non-computed projections, in addition to the Hot Records and Columns.

CPU RAM

The amount of CPU RAM should equal four to eight times the amount of total available GPU memory. Each NVIDIA Tesla P40 has 24 GB of onboard RAM available, so if you determine that your application requires four NVIDIA P40 cards, you need between 4 x 24 GB x 4 (384 GB) and 4 x 24 GB x 8 (768 GB) of CPU RAM. This correlation between GPU RAM and CPU RAM exists because the HeavyDB uses CPU RAM in certain operations for columns that are not filtered or aggregated.

SSD Storage

A HEAVY.AI deployment should be provisioned with enough SSD storage to reliably store the required data on disk, both in compressed format and in HEAVY.AI itself. HEAVY.AI requires 30% overhead beyond compressed data volumes. HEAVY.AI recommends drives such as the Intel® SSD DC S3610 Series, or similar, in any size that meets your requirements.

Hardware Sizing Schedule

This schedule estimates the number of records you can process based on GPU RAM and CPU RAM sizes, assuming up to 16 hot columns (see Hot Records and Columns). This applies to the compute layer. For the storage layer, provision your application according to SSD Storage guidelines.

If you already have your data in a database, you can look at the largest fact table, get a count of those records, and compare that with this schedule.

If you have a .csv file, you need to get a count of the number of lines and compare it with this schedule.

CPU Cores

HEAVY.AI uses the CPU in addition to the GPU for some database operations. GPUs are the primary performance driver; CPUs are utilized secondarily. More cores provide better performance but increase the cost. Intel CPUs with 10 cores offer good performance for the price. For example, so you could configure your system with a single NVIDIA P40 GPU and two 10-core CPUs. Similarly, you can configure a server with eight P40s and two 10-core CPUs.

Suggested CPUs:

• Intel® Xeon® E5-2650 v3 2.3GHz, 10 cores

• Intel® Xeon® E5-2660 v3 2.6GHz, 10 cores

• Intel® Xeon® E5-2687 v3 3.1GHz, 10 cores

• Intel® Xeon® E5-2667 v3 3.2GHz, 8 cores

PCI Express (PCIe)

GPUs are typically connected to the motherboard using PCIe slots. The PCIe connection is based on the concept of a lane, which is a single-bit, full-duplex, high-speed serial communication channel. The most common numbers of lanes are x4, x8, and x16. The current PCIe 3.0 version with an x16 connection has a bandwidth of 16 GB/s. PCIe 2.0 bandwidth is half the PCIe 3.0 bandwidth, and PCIe 1.0 is half the PCIe 2.0 bandwidth. Use a motherboard that supports the highest bandwidth, preferably, PCIe 3.0. To achieve maximum performance, the GPU and the PCIe controller should have the same version number.

The PCIe specification permits slots with different physical sizes, depending on the number of lanes connected to the slot. For example, a slot with an x1 connection uses a smaller slot, saving space on the motherboard. However, bigger slots can actually have fewer lanes than their physical designation. For example, motherboards can have x16 slots connected to x8, x4, or even x1 lanes. With bigger slots, check to see if their physical sizes correspond to the number of lanes. Additionally, some slots downgrade speeds when lanes are shared. This occurs most commonly on motherboards with two or more x16 slots. Some motherboards have only 16 lanes connecting the first two x16 slots to the PCIe controller. This means that when you install a single GPU, it has the full x16 bandwidth available, but two installed GPUs each have x8 bandwidth.

HEAVY.AI recommends installing GPUs in motherboards with support for as much PCIe bandwidth as possible. On modern Intel chip sets, each socket (CPU) offers 40 lanes, so with the correct motherboards, each GPU can receive x8 of bandwidth. All recommended System Examples have motherboards designed for maximizing PCIe bandwidth to the GPUs.

HEAVY.AI does not recommend adding GPUs to a system that is not certified to support the cards. For example, to run eight GPU cards in a machine, the BIOS register the additional address space required for the number of cards. Other considerations include power routing, power supply rating, and air movement through the chassis and cards for temperature control.

For an emerging alternative to PCIe, see NVLink.

NVLink

NVLink is a bus technology developed by NVIDIA. Compared to PCIe, NVLink offers higher bandwidth between host CPU and GPU and between the GPU processors. NVLink-enabled servers, such as the IBM S822LC Minsky server, can provide up to 160 GB/sec bidirectional bandwidth to the GPUs, a significant increase over PCIe. Because Intel does not currently support NVLink, the technology is available only on IBM Power servers. Servers like the NVIDIA-manufactured DGX-1 offer NVLink between the GPUs but not between the host and the GPUs.

System Examples

A variety of hardware manufacturers make suitable GPU systems. For more information, follow these links to their product specifications.

• Dell 2 GPU 2U Server

• NVIDIA DGX Workstation

• System 76 Ibex Pro GPU Workstation

• HPE ProLiant DL580 Gen10 Server

• Penguin Computers NVIDIA DGX Workstations

• Thinkmate NVIDIA Tesla GPU Servers

• Colfax NVIDIA DGX Workstations