ESP Deployment – Viya Overlap and Differences

2 Likes

Viya 3.3 introduced improved integration of ESP 5.1 components and products. Those paying attention to SAS products have heard the ESP products names but may not have time to dive into each product, its role and how deployment of ESP relates to Viya. Based on the number of queries received by the GEL team regarding the integration of ESP, it may be helpful to provide a review of products, components, services and service placement. So in this article we will attempt to provide some clarity on these topics, albeit at a fairly high level.

The Products

There are four licensed ESP-related products. Here is a brief summary of products and components, as well as the associated 9-byte codes.

SAS Event Stream Processing (EVNTSTM) - This is the core product around which the other products are built. It provides the engine to process and model events in real-time via the ESP engine. There are several components that are included when SAS ESP is ordered.
- SAS ESP Analytics (ESPANALYT) - provides additional analytic capability beyond that of SAS ESP. Once considered a separate licensable product, it is now included automatically with SAS ESP
- SAS ESP Studio - a development tool used to build and generate ESP models using a drag and drop web-based user interface
- SAS ESP Streamviewer - a web-based dashboard tool used to visualize events as they flow through a model
- SAS ESM Agent - agent used in conjunction with SAS Event Stream Manager
SAS Event Stream Processing for Edge (ESPEDGE) - A smaller footprint version of SAS ESP to allow it to run on edge devices such a sensors, routers, etc. It includes the following components
- SAS ESP Analytics - adds analytic capability to each ESP for Edge instance
SAS Event Stream Processing for CAS (ESPCLUSTR) - ESP capability that stands alongside CAS and provides the ability to run ESP models in a cluster and interact with CAS. Two CAS action sets are available for interactions: loadStreams and espCluster. Must be ordered with SAS ESP and SAS VA.
SAS Event Stream Manager (ESPMGR) - A tool used to manage ESP models and projects. Provides the operational tool to centralize and automate model deployment. Simplifies management when many engines are being used. SAS ESP is required for SAS ESM orders.

Deployment Options

If SAS ESP is ordered as a standalone product it is installed differently than if it is ordered with another Viya solution. When ordered as a standalone product a small script is provided to perform the deployment. When ordered with a Viya solution, including SAS Event Stream Manager, the deployment is integrated with the Ansible playbook. Under the covers both use yum to install RPMs from SAS's repositories. In both scenarios the Software Order Confirmation email contains a zip file, SAS_Viya_deployment_data.zip, that provides the certificates and license information.

SAS ESP - Standalone

A standalone order of SAS ESP directs the installer to move the zip file included in the email to the target machine and unzip. In addition to the certificates and license, this file includes a small script (orderinputs.sh) that contains the repositories and yum groups to install.

The contents of orderinputs.sh script:

# Entitled yum repo definitions

entitledRepos=””sas-esp-102-x64_redhat_linux_6-yum” “sas-espanalyt-101-x64_redhat_linux_6-yum””

# Function that adds yum groupinstall list
function install_yum_groups() {
yum groupinstall “SAS Event Stream Processing Analytics”
yum groupinstall “SAS Event Stream Manager Agent”
yum groupinstall “SAS Event Stream Processing”
yum groupinstall “SAS Event Stream Processing Studio”
yum groupinstall “SAS Event Stream Processing Streamviewer”
yum groupinstall “SAS Text Analytics for English”

}
licenseFile=SASViyaV0300_09****_Linux_x86-64.txt

The next step is to acquire the deployment script using a link in the email.

The deployment script is then placed in the root directory of the unzipped file from the email.

Once these pieces are in place the deployment script (customized_deployment_script.sh) is executed as an account with sudo rights or with the root account to perform the install.

SAS ESP for Edge Computing - Standalone

SAS ESP for Edge Computing is often included in IoT scenarios. From an order perspective SAS ESP Edge is excluded from full product orders, indicating it is incompatible with a full product order. Therefore ESP Edge will be ordered separately from Viya orders.

The email sent from an order of SAS ESP for Edge Computing includes four separate files: the license file, two certificates and a deployment script.

Deployment of the software is accomplished via the ESP_Edge_Script.sh script. The script includes code to install on Red Hat and Debian-based operating systems. All files from the email are moved to the target machine, the script made executable and then executed to perform the install.

With a Viya Product

If SAS ESP is ordered with Viya products (e.g. VA 8.2), including SAS Event Stream Manager, the deployment process uses Ansible to deploy the software. Multiple host groups are included in the inventory depending on which products are ordered. The groupings are shown here along with related services.

From the table above one might be tempted to interpret that the service associated with [espServer], sas-viya-esmagent-default, is used to start/stop ESP servers and load models. This is true only if SAS Event Stream Manager is included with the order. The esmagent service is included with all SAS ESP orders, but only used when SAS ESM is available and used to manage projects, models and ESP servers.

Note there is no associated service for [espStreamviewer]. SAS ESP Streamviewer is started via a script that is installed at deployment time. The script can be found at

/opt/sas/viya/home/SASEventStreamProcessingEngine/5.1.0/bin/streamviewer.sh

SAS ESM contains the core Viya components and services that are included with other Viya products. Included with SAS ESM are consul, pgpool, httpproxy, rabbitmq, sasdatasvrc and CoreServices. In a scenario where SAS ESP and ESM are ordered together, then all of the Viya pieces are available to enable SAS ESM and ESP Studio to authenticate users to LDAP via included Viya services.

Associated Data Stores

SAS ESP is all about processing events. However, the developmental and operational aspects of SAS ESP and related products require data stores. SAS ESP Studio, SAS ESM and SAS ESP Streamviewer require a database to store project, model, job and dashboard related objects. When SAS ESP and SAS ESM are deployed together or with other Viya products, objects for ESP Studio and ESM will be stored in the SAS Infrastructure Data Server (i.e. Postgres tables). There is no special configuration required.

Shown below are the schemas and table names for ESM and ESP Studio.

Although ESP Streamviewer is enabled to communicate with and store objects in numerous databases, the data store location shipped with ESP Streamviewer is an H2 database. H2 is a small footprint, file-based database that is included with a standalone ESP deployment. H2 is also the default data store for the ESP Studio in a standalone deployment. If another database is to be used for ESP Streamviewer, it will be necessary to attain the connection and authentication information.

Finally, licensing for ESP is different than most Viya solutions. ESP is licensed by number of events. In order to capture the counts and bits of information needed to properly report usage, it is necessary to start the metering service. The metering service uses an H2 database to save usage metrics. With ESP 5.1, H2 is the only supported database for the metering service.

The following table captures the key components that require data stores and which data stores are defaults.

Host Group Placement

In the prior section it was noted that when ESP and related products are deployed with Viya products there are one or more included host groups. You are likely aware a host group is the default unit of control for deploying software per machine. So you might be wandering about topology.

Here are some thoughts regarding host groups and placement.

SAS ESP Server [espServer]

Since the ESP Server is the engine that processes events in real-time, it is important that the ESP server not be impacted by other workloads on the same machine. If not managed properly, a resource usage flare-up by non-ESP server workloads could impact the throughput and responsiveness of ESP processing. Therefore it is suggested that the ESP server be placed on a machine by itself when possible.

SAS ESP Studio [espStudio]

ESP Studio is a web application that provides an environment for building and testing ESP models. As a result it is suggested that it be placed alongside the other web applications of a deployment.

SAS ESP Streamviewer [espStreamviewer]

ESP Streamviewer is a web application that enables the customer to build dashboards fed by events as they flow through ESP models. Like ESP Studio it is recommended that it be placed with other web applications.

SAS Event Stream Manager [viprESM]

As you might have guessed by now, SAS ESM is also a web application used for management and operations of ESP models and servers. Therefore, like ESP Studio and ESP Streamviewer, it would feel at home with them along with any other web applications.

One aspect that should be noted about ESP web applications is that there typically won't be a large number of users. Most customers will have only a few developers and testers who design and test ESP models and generate related dashboards. In addition they will likely maintain a small number of operational staff. As a result the load imposed by the web applications will have a much different resource profile than the many of the web applications of other Viya products.

The following diagram shows the ESP components and their placement with respect to other Viya services.

HA Considerations

When deployed with Viya some of the host groups can be configured to be highly available. SAS ESP Studio [espStudio] and ESM [viprESM] are capable of being clustered by defining more than one host to the respective host group. When configured in this manner the Apache proxy server is configured to balance requests across the web application instances during deployment. The web applications will use Postgres on the back end to centralize and store database objects.

The same is not true for SAS ESP Streamviewer [espStreamviewer]. Placing multiple machines in this host group will simply ensure that the software is installed. If three machines are defined and all three instances are started there is no coordination across the machines. Each instance of Streamviewer will act independently of each other. In addition it should be noted that they require configuration to use a database. If all instances "point" to the same database then theoretically they should be able to maintain a single copy of each dashboard, rather than three copies. (This is something that I haven't had time to test. Feel free to test and let us know your results. If you start down this road you may as well test updating the proxy settings to balance workload across instances.)

If multiple servers are specified for the [espServer] the deployment process will install the required software for clustering, but clustering ESP servers is substantially more involved than the automatic process for other Viya components. For more information about configuring HA ESP servers, see ESP Failover using Kafka on failover.

I think that's enough for this post. Let's wrap things up.

Final Thoughts

SAS ESP can exist on its own or as part of a Viya deployment with other products. The deployment for these two scenarios is quite different. When deploying in a Viya environment it is important to understand the components to ensure they are deployed in the appropriate location. In addition it is also helpful to know with which data store each component is configured. Hopefully this has helped clarify some of the questions about ESP and its relationship to Viya deployments.