ClearSee Installation and Administration Guide 16.1

ClearSee
Installation and Administration Guide

Version History
Each document has a version and a build number. You can tell the exact version and build
of this document by checking the top row of the table below.
Document updates are released in electronic form from time to time and the most up to
date version of this document will always be found on Allot’s online Knowledge Base. To
check for more recent versions, log in to the support area https://customers.allot.com/,
and from the Knowledge Base tab, enter the title of this document into the search field.
Doc Revision Internal Build Product Published Revisions
Version
16.1 16.1b4 16.1.50 05.11.2019 Added step in Defining Network
Configuration about DNS
Replaced backup and restore procedures
16.1 16.1b3 16.1.10 25.06.2019 Corrected bonding
16.1 16.1b2 16.1.10 06.06.2019 Added Creating Installation Files for Use
at a Later Time
16.1 16.1b1 16.1.10 29.05.2019 First release
R8 R8b1 CS15.1 08.11.17 GA Document Release
R7 R7b1 CS 14.7 16.05.17 GA Document Release
R6 R6b2 CS 14.5 15.06.16 GA Document Release
R5 R5b1 CS14.1 9.6.15 Corrected Network Deployment and
Connectivity
Standalone deployment updated
Time zone updated/corrected
Integration with NetXplorer
Updated ETL commands
Updated upgrading
Updated split brain
Updated Logs and Alerts
R4 R4b1 CS13.4 18.11.14 Addition of:
-Replace DWH server procedure
-Patch management
-Analyze files
R3 R3b1 CS13.3.300 5.10.14 Addition of new kickstart and upgrade
procedure.
R2 R2b1 CS13.3.300 12.6.14 General updates
R1 R1b24 CS13.3.300 2.4.14 Initial Document Release
i ClearSee Installation and Administration Guide

ClearSee Overview
ii
ClearSee Overview
Contents
Version History .............................................................................................................................i
Contents ..................................................................................................................................... iii
1 ClearSee Overview ........................................................................................................ 1-1
1.1 ClearSee Capabilities ........................................................................................ 1-1
1.2 System-Level Data Flow ................................................................................... 1-1
1.3 ClearSee Scalability Options ............................................................................. 1-2
1.4 ClearSee Provisioning Options ......................................................................... 1-2
1.5 Report and NetworkSecure Deployment Modes ............................................. 1-3
1.6 Licensing ........................................................................................................... 1-4
2 Appliance Hardware Specifications .............................................................................. 2-1
2.1 Standard Standalone Specifications ................................................................. 2-1
2.2 Enhanced Standalone Specifications................................................................ 2-2
2.3 Cluster Deployment Specifications .................................................................. 2-3
3 Software-Only Installation Requirements .................................................................... 3-1
3.1 Standard Standalone Requirements ................................................................ 3-1
3.2 Enhanced Standalone Requirements ............................................................... 3-2
3.3 DW Node Requirements................................................................................... 3-4
3.4 BI Server Requirements .................................................................................... 3-6
4 Virtual Template Requirements and Specifications ..................................................... 4-1
4.1 Virtual Machine Requirements ........................................................................ 4-1
4.2 Virtual Enhanced Standalone Requirements ................................................... 4-1
4.3 Virtual DW Requirements ................................................................................ 4-2
4.4 Virtual BI Requirements ................................................................................... 4-2
5 Network Deployment and Connectivity ....................................................................... 5-1
5.1 High Availability ................................................................................................ 5-1
5.2 Ethernet Ports in an Appliance Installation...................................................... 5-2
3550 1U Server.................................................................................... 5-2
3650 2U Server.................................................................................... 5-2
iii
ClearSee Overview
5.3 Standalone Deployments ................................................................................. 5-3
5.4 Cluster Deployments ........................................................................................ 5-4
DW Node Networking ......................................................................... 5-6
Primary and Secondary BI Servers ...................................................... 5-7
BI Server Networking .......................................................................... 5-7
6 ClearSee Installation ..................................................................................................... 6-1
6.1 Standalone Install Workflow ............................................................................ 6-1
6.2 Cluster Install Workflow ................................................................................... 6-5
6.3 Installing the ACP.............................................................................................. 6-9
6.4 Answering the Standalone Wizard ................................................................. 6-12
6.5 Answering the Cluster Wizard ........................................................................ 6-15
6.6 Advanced Wizards .......................................................................................... 6-21
6.7 Creating Installation Files for Use at a Later Time ......................................... 6-22
6.8 Virtual ClearSee Installation ........................................................................... 6-24
Virtual Install Workflow (Standalone) .............................................. 6-24
Virtual Install Workflow (Cluster) ..................................................... 6-28
Deploying the OVF Template ............................................................ 6-35
Deploying the KVM Template ........................................................... 6-43
7 ClearSee Configuration ................................................................................................. 7-1
7.1 Logging in to ClearSee as Web_Admin ............................................................. 7-1
7.2 Accessing NetXplorer ....................................................................................... 7-1
7.3 NetXplorer User Interface ................................................................................ 7-2
7.4 Integrating ClearSee with NetXplorer .............................................................. 7-3
Applying the ClearSee License ............................................................ 7-4
Building a Standalone ClearSee System .............................................. 7-7
Building a Cluster ClearSee System................................................... 7-10
Modifying a ClearSee System............................................................ 7-13
Defining a BI Instance in the Navigation Pane .................................. 7-16
Defining a BI-HA Group in the Navigation Pane ............................... 7-17
Defining a DW Instance in the Navigation Pane ............................... 7-18
iv
ClearSee Overview
Defining the Standalone ETL Group .................................................. 7-19
Defining the Cluster ETL Group ......................................................... 7-23
Editing a Server Node ....................................................................... 7-27
ClearSee Configuration with NetXplorer .......................................... 7-28
Defining DMs with Virtual IPs ........................................................... 7-36
7.5 Performing ClearSee CLI Configuration .......................................................... 7-37
Setting the Time Zone ....................................................................... 7-38
Enabling ClearSee Fields from the AOS CLI ....................................... 7-40
Changing Configuration Parameters ................................................. 7-40
Changing the Real-Time Refresh Rate .............................................. 7-41
Enabling the Exporting of Insights to Syslog ..................................... 7-43
8 ClearSee Maintenance .................................................................................................. 8-1
8.1 Cluster Maintenance ........................................................................................ 8-1
Making Changes to the Internal IP Addresses—Pacemaker and DRBD8-1
Split-Brain Inconsistency Condition .................................................... 8-7
Monitoring DW Load Status.............................................................. 8-11
Restoring the Primary BI Server ........................................................ 8-12
8.2 Standalone Backup and Restore .................................................................... 8-13
Preparing an External Device ............................................................ 8-13
Preparing a Remote Server ............................................................... 8-14
Backing Up Vertica to an External Device ......................................... 8-15
Backing Up Vertica to a Remote Server ............................................ 8-17
Restoring Vertica from an External Device ....................................... 8-19
Restoring Vertica from a Remote Server .......................................... 8-20
8.3 ClearSee Alerts ............................................................................................... 8-21
ClearSee Logs .................................................................................... 8-21
ClearSee SNMP Traps ........................................................................ 8-23
8.4 Intelligent Cubes Maintenance ...................................................................... 8-24
8.5 Changing ClearSee Server Hostnames ........................................................... 8-25
8.6 Performing ETL Administration ...................................................................... 8-27
v
ClearSee Overview
Start, Stop and Restart ...................................................................... 8-30
ETL Status .......................................................................................... 8-30
Queues .............................................................................................. 8-31
Deploy ............................................................................................... 8-32
Displaying Alerts................................................................................ 8-32
8.7 Performing Patch Management ..................................................................... 8-35
Status ................................................................................................ 8-35
Import ............................................................................................... 8-36
Install ................................................................................................. 8-36
Import and Install .............................................................................. 8-37
9 Security and Access Management ................................................................................ 9-1
9.1 Accessing ClearSee ........................................................................................... 9-1
9.2 Security ............................................................................................................. 9-1
Database Security ............................................................................... 9-1
Accessing ClearSee by HTTPS .............................................................. 9-2
Disabling HTTP in a Standalone Deployment ..................................... 9-2
Disabling HTTP in a Cluster Deployment ............................................ 9-3
Changing Web Ports in a Standalone Deployment ............................. 9-3
Changing Web Ports in a Cluster Deployment.................................... 9-4
Changing Passwords ........................................................................... 9-5
Securing Data in Motion between ClearSee and NetworkSecure ...... 9-9
9.3 Access Management ...................................................................................... 9-13
Access Privileges ............................................................................... 9-13
Access Management Process ............................................................ 9-14
Accessing the User Manager............................................................. 9-15
User Management ............................................................................ 9-17
Group Management.......................................................................... 9-24
10 ClearSee Startup and Shutdown ............................................................................... 10-27
10.1 Starting Up Your Standalone System ........................................................... 10-27
10.2 Powering Off Your Standalone System ........................................................ 10-27
vi
ClearSee Overview
10.3 Starting Up Your Cluster System .................................................................. 10-27
10.4 Powering Off Your Cluster System ............................................................... 10-28
10.5 Shutting Down a BI Server ............................................................................ 10-28
10.6 Shutting Down a DW Server ......................................................................... 10-29
10.7 Stopping the DW Database .......................................................................... 10-29
10.8 Starting the DW Database ............................................................................ 10-31
11 Appendices .................................................................................................................. 11-1
11.1 Appendix 1: External Data Source File Structures.......................................... 11-1
vii
1 ClearSee Overview
This guide describes how to install ClearSee and perform administration tasks on
ClearSee’s modules.
1.1 ClearSee Capabilities

ClearSee is Allot’s network analytics tool. As a full Telco analytics solution, ClearSee is
designed for flexibility and ease of use. It has the following characteristics:
• Software Defined. The User can customize the system to meet evolving needs.
• Runs on commodity HW with pre-defined upgrade paths, which permit the
system to scale as usage increases.
• Supports virtualized platforms.
1.2 System-Level Data Flow

The system-level data flow describing how ClearSee obtains the data is as follows:
1. Allot’s Data Mediator (DM) extracts information from the In-line platform, from
the SMP, Allot’s subscriber management platform, and from the Filter servers
belonging to NetworkSecure, Allot’s Web Security solution.
2. The DM loads the data to the Data Warehouse (DW).
3. The DW performs the ETL process, which is comprised of the following:
⧫ Extract: Extracts data from the data source to local working folder
⧫ Transform: Transforms data to format for analysis and query; performs data
validation
⧫ Load: Loads data to the DW Vertica database
4. From the DW, the Business Intelligence application (BI) formats and presents
the information.
The data flow appears in the following illustration:
1-1 ClearSee Installation and Administration Guide

ClearSee Overview
Figure 1-1: ClearSee System-Level Data Flow
1.3 ClearSee Scalability Options

Allot ClearSee runs on standard hardware and is available in three variations:
• Standalone Standard: All of ClearSee components in a co-located environment,
for up to 100,000 data subscribers
• Standalone Enhanced: All of ClearSee components in a co-located environment
with a stronger CPU and additional storage and memory resources, for up to one
million data subscribers
• Cluster: Deployed on a multi-node dedicated highly-available server stack with
superior scalability, for unlimited data subscribers
1.4 ClearSee Provisioning Options

ClearSee is purchased as a pre-provisioned appliance or as software-only for installation
on customer equipment, as follows:
• Appliance: The hardware is pre-configured and delivered by Allot. It arrives on
the customer premises with BIOS and RAID configured, and with operating
system and software installed. The customer carries out system installation and
configuration.
• Software-Only: The customer purchases all the hardware in consultation with
Allot Customer Support, installs the operating system and software, and carries
out system installation and configuration.
1-2
ClearSee Overview
Allot supports two types of software-only provisioning:
⧫ Physical environment
⧫ Virtual environment
Allot provides the following two USB flash drives for installation:
• Kickstart: A CentOS Kickstart for a clean install of the CentOS operating system
and the configuration of the operating system
• System: System installation software
1.5 Report and NetworkSecure Deployment Modes

Depending on the type of network that you provide and the service from ClearSee that
you require, you can choose the reports, dashboards and templates that appear in
ClearSee. This is the report mode.
The report mode can be any of the following:
• Fixed: Those relevant to a fixed network appear.
• Cable: Those reports relevant to a cable network as well as the fixed network
appear.
• Mobile: Those reports relevant to a mobile network as well as the fixed network
appear.
• Security: Those reports relevant to NetworkSecure security features appear.
• All: All reports appear.
Report mode does not affect the Real-Time Monitors.
NetworkSecure Deployment Mode, on the other hand, is relevant only for the
NetworkSecure dashboards and templates. It defines which dashboards and templates
appear. The modes are as follows:
• Enterprise: Those relevant to the enterprise appear.
• Enterprise Extended: Those relevant to the enterprise appear, as well as a few
others.
• ISP: All dashboards and templates appear.
You may not require anything from the ClearSee GUI, rather simply the ClearSee backend.
If so, to save resources, you can select Smart Data Export Only Mode. If you select this
mode, there is no need to select any of the other report and NetworkSecure deployment
modes.
All of these modes are available for you to select while INTEGRATING CLEARSEE WITH
NETXPLORER.
1-3
ClearSee Overview
1.6 Licensing
You must have the following licenses:
• ClearSee Data Warehouse license: Purchased according to the sizing guidelines.
• One of the following:
⧫ ClearSee Network Metrics: This is the light edition, with partial functionality.
Not all reports and dashboards are enabled. This license is free and included
in the NetXplorer by default.
⧫ ClearSee Network Analytics: This is the professional edition, with full
functionality. All reports and dashboards are enabled, including Self Service.
• Real-Time Monitoring: Requiring AOS 14.5, this is purchased per in-line platform
and per 1G network bandwidth.
NOTE After you add a ClearSee system to NetXplorer, as described in
INTEGRATING CLEAR SEE WITH NETXPLORER, the following changes
occur:
• The STC (Short Term Collector) stops collecting data.
• STC/LTC historical data ceases to be available in NetXplorer.
• The Data Mediator starts collecting data for ClearSee (replacing
STC functionality).
1-4
2 Appliance Hardware Specifications
The following sections contain the specifications of the hardware as shipped from Allot in
an Appliance provisioning:
• STANDARD STANDALONE SPECIFICATIONS
• ENHANCED STANDALONE SPECIFICATIONS
• CLUSTER INSTALLATION SPECIFICATIONS
2.1 Standard Standalone Specifications

The Standard Standalone deployment provides a single server to host both the DW and
the BI, and is appropriate for networks of up to 100,000 data subscribers. This ClearSee
system server connects to the DM.
Specifications as a Standalone M4 server are as follows:
Specifications for Clearsee Standard Standalone (M4)
Part Number PA-CS-STRD-SRV-GEN4
Hardware IBM x3550 M4 1U server

2 x Intel Xeon with 6 cores running at 2.0Ghz
64 GB RAM
2 TB of server storage via 2 x146 GB and 6 x 300 GB disks
Dual AC/DC 750W power supply
2 x 1 GbE copper connectivity (extra link for redundancy)
Supported Operating System CentOS Linux 6.6 64-bit x 86 (English only)
CentOS Linux 7.3 64-bit x 86 (English only)
SPECIFICATIONS FOR CLEARSEE Standard STANDALONE (M5)
Part Number PA-CS-STRD-SRV-GEN5
Hardware Lenovo x3550 M5 1U server

Intel Xeon Processor E5-2620 6C 2.4GHz 15MB Cache 1866MHz 85W
Additional Intel Xeon Processor E5-2620 6C 2.4GHz 15MB 1866MHz
85W
64 GB, DDR41866MHz
2.4 TB of server storage on 8 x 300 GB disks
System x 750W High Efficiency Platinum AC Power Supply

Appliance Hardware Specifications
2.2 Enhanced Standalone Specifications

The Enhanced Standalone deployment provides a single server to host both the DW and
the BI, and is appropriate for networks of up to one million subscribers. This ClearSee
system server connects to the DM.
Specifications for ClearSee Enhanced Standalone (M4)
Part Number PA-CS-ENH-SRV-GEN4
Hardware IBM x3650 M4 2U server 2 x Intel Xeon with 8 cores running at 2.0Ghz
128 GB RAM
7.3 TB of server storage via
• 2 x 146 GB
• 12 x 600 GB disks
Specifications for ClearSee Enhanced Standalone (M5)
Part Number PA-CS-ENH-SRV-GEN5
Hardware Lenovo x3650 M5 2U server

90W
128 GB, DDR41866MHz
7.8 TB server storage via:
• 2 x 300GB 15K 12Gbps SAS 2.5" G3HS 512e HDD
• 12 x 600GB 10K 12Gbps SAS 2.5" G3HS 512e HDD
Specifications for the Extended Standalone M5 server are as follows:
2-2
Specifications for ClearSee Enhanced Extended Standalone (M5)
Part Number PA-CS-ENH-SRV-GEN5-EX
Hardware IBM x3650 M5 2U server

256 GB, DDR41866MHz
29.4 TB of server storage via:
• 2 x 300 GB
• 24 x 1,200 GB disks
2.3 Cluster Deployment Specifications

The Cluster deployment provides separate, expandable nodes hosting the DWs and the
BIs respectively. Cluster nodes support many millions of subscribers with effectively
unlimited scalability.
A Cluster deployment consists of a primary BI server and a secondary BI server, and at
least three DWs. With M5 hardware, the DWs may also be extended DWs.
Specifications as M4 servers are as follows:
Specifications for ClearSee Cluster (M4)
DW Hardware Part Number: PA-CS-CLUSTER-GEN4, which is comprised of 3 x PA-CS-
NOD-SRV-GEN4 servers, with each server as follows:
• IBM x3650 M4 2U server
• 2 x Intel Xeon with 8 cores running at 2.0Ghz
• 128 GB RAM
• 7.3 TB of server storage via 12 x 600 GB disks
• Dual AC/DC 750W power supply
• 2 x 1 GE copper connectivity and 2 x 10 GbE SFP+ Multi-Mode SR
connectivity (extra links for redundancy)
BI Server Hardware Part Number: PA-CS-BI-SRV-HAP-GEN4
IBM x 3550 M4 1U server
64 GB RAM
1.2 TB of server storage via 4 x 300 GB disks
6 x 1 GbE copper connectivity (extra links for redundancy and H/A)
2-3
Specifications as M5 servers are as follows:
Specifications for ClearSee Cluster (M5)
DW Hardware Part Number: PA-CS-CLUSTER-GEN5, which is comprised of 3 x PA-CS-
NOD-SRV-GEN5 servers, with each server as follows:
• Lenovo x3650 M5 2U server
• Intel Xeon Processor E5-2640 8C 2.6GHz 20MB Cache 1866MHz
90W
• Additional Intel Xeon Processor E5-2640 8C 2.6GHz 20MB
1866MHz 90W
• 128 GB, DDR41866MHz
• 7.8 TB of server storage via:
⧫ 2 x 300 GB
⧫ 12 x 600 GB disks
• System x 900W High Efficiency Platinum AC Power Supply
DW Extended Hardware Part Number: PA-CS-CLUSTER-GEN5-EX, which is comprised of 3 x PA-
CS-NOD-SRV-GEN5-EX servers, with each server as follows:
• IBM x3650 M5 2U server
• 2 x Intel Xeon with 12 cores running at 2.6Ghz
• 256 GB RAM
• 29.4 TB of server storage via:
⧫ 2 x 300 GB
⧫ 24 x 1,200 GB disks
• Dual AC/DC 900W power supply
• 2 x 1 GE copper connectivity and 2 x 10 GbE SFP+ Multi-Mode SR
connectivity (extra link for redundancy)
BI Server Hardware Part Number: PA-CS-BI-SRV-HAP-GEN5
Lenovo x3550 M5 1U server
85W
64 GB, DDR41866MHz
1.2 TB of server storage 8 x 300 GB disks
6 x 1 GbE copper connectivity (extra links for redundancy and H/A)
2-4
3 Software-Only Installation Requirements
In Software-Only installations, your hardware must comply with requirements regarding
operating system, networking and hard drive settings. This chapter describes these
requirements.
The following sections contain the requirements in a Software-Only installation and a
physical environment, for the three scalability options:
• STANDARD STANDALONE REQUIREMENTS
• ENHANCED STANDALONE REQUIREMENTS
• Cluster:
⧫ DW NODE REQUIREMENTS
⧫ BI SERVER REQUIREMENTS
3.1 Standard Standalone Requirements

In a physical environment, a Standard Standalone Software-Only installation consists of
one unit that must meet the following requirements:
Item Requirements
BIOS Setting Disable CPU Frequency Scaling in BIOS
Disable CPU Power Savings
Hard Drive Minimum of 2 logical drives:
• OS: Recommended RAID 1 (Mirror) with at least 146 GB per disk (2 X 146 GB
per disk)
strip size: 128K
• Data: Recommended RAID 10 with at least 900 GB (can be divided into 6 X 300
GB per disk)
strip size: 256K
Minimum of 10 GB free space in /opt directory
RAM 64 GB minimum, DDR4 1866MHz
CPU Cores Minimum: 12 core CPU (24 hyper-threading)
By means of: 2 x Intel Xeon Processor E5-2620 6C 2.4 GHz 15MB Cache 1866MHz
Network Bond0: 2 X 1GbE interfaces for HA
• HA, in which 2 ports are used, is recommended but not required.
• If possible, the server should include 4 GbE interfaces, as this allows the use of
Allot’s networking configuration script, see CHANGING A SERVER IP ADDRESS)
Configuration Settings: Swap fs configured with a minimum of 8 GB
File System • OS: 2 EXT4 file systems, / and /opt

Software-Only Installation Requirements
• Data: 2 EXT4 file systems, /clearsee_input and /data
OS CentOS Linux 6.6 64-bit x 86 (English only)
Recommended: Brought up in graphic mode (/etc/inittab set to init 5)
If other, contact Allot Support.
IOPS • OS:
⧫ Minimum: 150 MB/sec
⧫ Recommended:200 MB / Sec
• Data:
⧫ Minimum: 240 MB /Sec
⧫ Recommended: 480 MB / Sec
Power Recommended: Disable any Advanced Power Management Options, and allow
maximum power usage by the processors for optimal performance.
3.2 Enhanced Standalone Requirements

In a physical environment, an Enhanced Standalone Software-Only installation consists of
one unit. This unit must meet the requirements of one of the following:
• Requirements for the Enhanced Standalone unit are as follows:
Item Requirements
per disk)
strip size: 128K
• Data: Recommended RAID 10 with at least 3600 GB (can be divided into 12 X
600 GB per disk)
strip size: 256K
By means of: 2 x Intel Xeon Processor E5-2640 8C 2.6GHz 20MB Cache 1866MHz
Enhanced table is OK.
3-2
IOPS • OS:
• Data:
⧫ Minimum: 320 MB / Sec
• Requirements for the Enhanced Extended Standalone unit are as follows:

Item Requirements
• OS: RAID 1 (Mirror) with at least 146 GB per disk (2 X 146 GB per disk)
• Data: RAID 60* with at least 28,800 GB (can be divided into 24 X 1,200 GB per
disk)
* We recommend RAID 60 with two groups of RAID 6.
By means of: 2 X Intel Xeon Processor E5-2690 12C 2.6GHz 30MB Cache 2133MHz
135W or higher
• Data:
3-3
⧫ If the data file systems as a whole are smaller than 16 TB, then with 2 EXT4
file systems, /clearsee_input and /data
⧫ If the data file systems as a whole are larger than 16 TB, then with 3 EXT4
file systems,* /clearsee_input, /data and /data2
OS CentOS Linux 6.6 64-bit x 86:
• Recommended: Brought up in graphic mode (/etc/inittab set to init 5)
• English only
IOPS • OS:
• Data:
3.3 DW Node Requirements

In a physical environment, a Cluster Software-Only installation consists of at least three
DW servers. We recommend that each DW server is configured with the same hardware
specification, as DW strength is determined by the weakest node in the cluster.
Each DW node must meet the requirement of one of the following:
• Requirements for a DW unit are as follows:
Item Requirements
CPU Configuration Disable CPU Frequency Scaling in BIOS
per disk)
strip size: 128K
• Data: Recommended RAID 10 with at least 3600 GB (can be divided into 12 X
600 GB per disk)
strip size: 256K
CPU Minimum: 16 core CPU (32 hyper-threading)
By means of: 2 x Intel Xeon Processor E5-2640 8C 2.6GHz 20MB Cache 1866MHz
Enhanced table: OK
3-4
Network • Bond0: 2 X 1GbE interfaces for HA (Public IP)
• Bond1: 2 X 10GbE SFB+ Multi-Mode SR interfaces for HA (Private IP)
HA, in which 2 ports are used, is recommended but not required. Otherwise each
bond contains 1 port.
Configuration Settings Swap fs configured with a minimum of 8 GB

IOPS • OS:
• Data:
⧫ Minimum: 320 MB / Sec
• Requirements for the Extended DW unit are as follows:

Item Requirements
• OS: RAID 1 (Mirror) with at least 146 GB per disk (2 X 146 GB per disk)
• Data: RAID 60* with at least 28,800 GB (can be divided into 24 X 1,200 GB per
disk)
* We recommend RAID 60 with two groups of RAID 6.
By means of: 2 X Intel Xeon Processor E5-2690 12C 2.6GHz 30MB Cache 2133MHz
135W or higher
Network • Bond0: 2 X 10GbE SFB+ Multi-Mode SR interfaces for HA (Private IP)
• Bond1: 2 X 1GbE interfaces for HA (Public IP)
3-5
• Data:
⧫ If the data file systems as a whole are smaller than 16 TB, then with 2 EXT4
file systems, /clearsee_input and /data
⧫ If the data file systems as a whole are larger than 16 TB, then with 3 EXT4
file systems,* /clearsee_input, /data and /data2
IOPS • OS:
• Data:
3.4 BI Server Requirements

In a physical environment, a Cluster Software-Only installation and consists of two BI
servers, a primary and the secondary. Each must meet the following requirements:
Item Requirements
per disk)
strip size: 128K
• Data: Recommended RAID 1 with at least 300 GB (can be divided into 2 X 300
GB per disk)
strip size: 128K
The second disk should remain undefined.
CPU Minimum: 12 CPU Cores (24 hyper-threading)
By means of: 2 x Intel Xeon Processor E5-2620 6C 2.4 GHz 15MB Cache 1866MHz
Network • Bond0: 2 X 1GbE interfaces for the Public IP
• Bond1: 2 X 1GbE interfaces for the Data Sync IP if running through a switch. If
using cross-cable links use only 1 port!
3-6
• Bond2: 2 X 1GbE interfaces for the Internal HA IP if running through a switch. If
using cross-cable links use only 1 port!
HA, in which 2 ports are used, is recommended but not required. Otherwise each
bond contains 1 port.
Security 2 SSH keys generated for "root" user, between the two BI servers
Configuration Settings Swap fs configured with a minimum of 8 GB

OS CentOS Linux 6.6 64-bit x 86:
• Recommended: Brought up in graphic mode (/etc/inittab set to init 5)
• English only
IOPS Per each logical drive:
• Minimum: 150 MB/sec
• Recommended:200 MB / Sec
When connecting the BI Servers, make sure that the server indicated as the PRIMARY is
configured as the primary BI server. The label may be seen on the top of the server chassis
(see below) listing the serial numbers of the BI servers.
Figure 3-1: Business Intelligence (BI) Server Labeling
3-7
4 Virtual Template Requirements and
Specifications
ClearSee can be purchased and delivered as a virtual appliance file (templates) with the
relevant products pre-installed and configured.
Allot Virtual NMS (vNMS) components are provided with two types of template:
• OVF template for deployment in VMWare/ESXi environment
• QCOW2 template for deployment in OpenStack/KVM environment
The template files for each product may be configured to support both larger and smaller
scale environments.
4.1 Virtual Machine Requirements

The following table contains requirements for building the virtual machine on which to
install the template.
Hypervisor
VMWare ESXi VMWare vShpere 5.5 and above
RedHat KVM RedHat RHEL 6.7 and above
Operating system
CentOS Linux CentOS 7.3, 64-bit x86
See the following for specifications in a Software-Only installation, with a virtual

environment, for the three deployment variations:
• VIRTUAL ENHANCED STANDALONE REQUIREMENTS
• Cluster:
⧫ VIRTUAL DW REQUIREMENTS
⧫ VIRTUAL BI REQUIREMENTS
4.2 Virtual Enhanced Standalone Requirements

In a virtual environment, an Enhanced Standalone Software-Only installation consists of
one unit. This unit is configured to support the following workload:

Virtual Template Requirements and Specifications
Download Size VDISK VCPU RAM NICS
10.3 GB OVF / 14.8 GB • Disk 1: 1.4 TB for 32x (2 vSockets * 16 Up to 128 GB 4 network
QCOW2 OS and software cores per vSocket) (no min limit) adapters
• Disk 2: 3.6 TB for
data
4.3 Virtual DW Requirements

In a virtual environment, a Cluster Software-Only installation consists of at least three DW
servers.
Each virtual DW server is configured to support the following workload:
11.6 GB OVF / 14 GB • Disk 1: 146 GB for 32x (8 vSockets * Up to 128 GB 4 network
QCOW2 OS and software 4 (no min limit) adapters
• Disk 2: 1.2 TB for cores per vSocket)
data
4.4 Virtual BI Requirements

In a virtual environment, Cluster Software-Only installation consists of two BI servers, a
primary and the secondary. Each virtual BI server is configured to support the following
workload:
11.6 GB OVF / 14.1 GB • Disk 1: 300 GB for 24x (8 vSockets * 3 Up to 64 GB 5 network
QCOW2 OS and software cores per vSocket) (no min limit) adapters
• Disk 2: 300 GB for
data
4-2
5 Network Deployment and Connectivity
This chapter covers all aspects of physical connectivity and deployment, such as cabling,
interconnectivity and high availability, for the following:
• STANDALONE DEPLOYMENTS
• CLUSTER DEPLOYMENTS
Each deployment is presented in both a High Availability configuration and a non-High
Availability configuration. For more about High Availability, see HERE.
The following sections contain a table for each type of configuration, with a row for each
networking bond. These configurations are provided for the following purposes:
• As guidelines when planning a Software-Only installation.
• As a description of an Appliance installation. In the following tables, the
Connectivity column contains the actual ports employed in an Appliance
installation.
For firewall configuration, see the AOS documentation for appropriate settings.
5.1 High Availability

Minimally, the distributed deployment model relies upon and assumes use of one core
switch to provide connectivity, as follows:
• For all outbound communication, from ClearSee to clients on the corporate
network
• For internal communication, as follows:
⧫ In a Standalone deployment, between the DM and ClearSee
⧫ In a Cluster deployment, between the DM and ClearSee, between the DM
and the DW nodes and between the BI servers
The core switch can be a layer 2 switch, and must be capable of supporting 10 GbE optical
interfaces, of type SFP+ Multi-Mode (Short-Range).
We recommend that the ClearSee system support High Availability, both between DWs
and between BIs. This is achieved as follows:
1. Adding a second 10 GbE switching entity, so that one core switch is active and
the other passive
2. Duplicating all the networking paths
In a High Availability configuration, each networking bond on a system unit contains two
Ethernet links. The links must be in Active/Passive mode, one per bond of each kind, to

Network Deployment and Connectivity
provide fail-over support for all traffic types. The switch need not support Ether-Channel
or 802.3ad (LACP).
For the reduction of latency, we recommend that the ClearSee system be connected to
the same segment as the DMs (one or more) in a LAN environment.
5.2 Ethernet Ports in an Appliance Installation

3550 1U Server
The 3550 1U server is used as the following:
• The Standard Standalone server
• The BI server in a Cluster deployment
The following figure identifies the Ethernet ports on an IBM x3550 M4:
Figure 5-1: Ethernet Ports on an IBM x3550 M4 1U Server

The following figure identifies the Ethernet ports on a Lenovo x3550 M5:
Figure 5-2: Ethernet Ports on a Lenovo x3550 M5 1U Server
3650 2U Server
The IBM x3650 2U server is used as the following:
• The Enhanced Standalone server
• The DW node in a Cluster deployment
5-2
The following figure identifies the Ethernet ports on an x3650 M4:
Figure 5-3: Ethernet Ports on an IBM x3650 M4 2U Server

The following figure identifies the Ethernet ports on an x3650 M5:
Figure 5-4: Ethernet Ports on a Lenovo x3650 M5 2U Server
5.3 Standalone Deployments

There are two ways to configure the ClearSee network in a Standalone deployment:
Availability Description Mode Connectivity
High Availability There are two core active- On Bond 1:

switches, each backup • Standard:
receiving from both
⧫ Port 3
ClearSee and the
DM and sending to ⧫ Port 4
external clients. • Enhanced:
⧫ Port 1
⧫ Port 2
5-3
Non-High Availability One core switch balance-rr • Standard:
receives from both ⧫ Port 3
ClearSee and the
• Enhanced:
DM and sends to
external clients. ⧫ Port 1
Connections are
cross-cabled.
The following figure illustrates the network architecture of a Standalone deployment.
Those connections enabling High Availability are marked with a broken red line.
Figure 5-5: ClearSee Standalone Deployment Network Architecture
5.4 Cluster Deployments

The following figure illustrates the network architecture of a Cluster deployment with full
High Availability. Those connections enabling High Availability are marked with a broken
line.
5-4
Figure 4-2: ClearSee Cluster Distributed Deployment Network Architecture

In this network deployment:
• Six switches are used, as follows:
⧫ Two for the BI private network
⧫ Two for the DW private network
⧫ Two for the public network, connecting to both the BI servers and the DW
nodes
NOTE The BI private network should be configured so as not to block
unicast and multicast traffic.
• 16 ports are used, as follows:
⧫ Six 10Gb ports for the DW private network
⧫ Six 1Gb ports for the public network, connecting to both the BI servers and
the DW nodes
⧫ Four 1Gb ports for the BI private network
5-5
DW Node Networking
The DW nodes can be configured according to the following setups:
Availability Bond Description Mode Connectivity
High Availability Public IP: Communication with the two active- On Bond 0:
public 1GbE core switches common with backup • M4:
the BIs. Each link connects to a separate
⧫ Port 5
and interconnected switch. IP addresses
allow connectivity to the BI servers & DM. ⧫ Port 6
• M5:
⧫ Port 0 (Vertica)
⧫ Port 1 (Vertica)
Private IP: DW cluster On Bond 1:
intercommunication via two 10GbE • Port 1
Ethernet optical links. Each link connects
• Port 2
to a separate and interconnected 10GbE
switch. This network runs on a private
VLAN, with IP addresses that are not part
of the management network.
Non-High Private IP: DW cluster balance • M4:
Availability intercommunication and contains one -rr ⧫ Port 5
10GbE Ethernet optical links. This network
• M5:
runs on a private VLAN, with IP addresses
that are not part of the management ⧫ Port 0 (Vertica)
network.
Public IP: Communication with the 1GbE • Port 1
core switches for both DM (south-bound)
and BI (north-bound) communication, and
contains one 1GbE Ethernet link, and with
IP addresses that allow connectivity to the
BI servers & DM.
The possible combinations of DW servers in a Cluster deployment are as follows:
• PA-CS-CLUSTER-GEN4 server, which is comprised of 3 x PA-CS-NOD-SRV-GEN4
nodes, with additional PA-CS-NOD-SRV-GEN4 nodes as per sizing
• PA-CS-CLUSTER-GEN5 server, which is comprised of 3 x PA-CS-NOD-SRV-GEN5
nodes, with additional PA-CS-NOD-SRV-GEN5 nodes as per sizing
• PA-CS-CLUSTER-GEN5-EX server, which is comprised of 3 x PA-CS-NOD-SRV-
GEN5-EX nodes, with additional PA-CS-NOD-SRV-GEN5-EX nodes as per sizing
NOTE If the number of database nodes exceed the capacity of one 10GbE
switch (for example if the number of nodes exceed the capacity of 1
rack space), then the networking bandwidth requirement between
each of the switching entities should be as follows:
Bandwidth = Number of database nodes X 3.5Gbps + 10Gbps
5-6
Primary and Secondary BI Servers
When connecting the BI Servers received from Allot as an Appliance, make sure that the
server indicated as the PRIMARY is configured as the Primary server. The label may be
seen on the top of the server chassis (see below) listing the serial numbers of the BI
servers.
Figure 5-6: BI Server Labeling

The server with the PRIMARY sticker is that which received the DNS name ha-primary. The
other is named ha-secondary. By default, ha-primary is the Primary BI server (the active
server), while ha-secondary is the Secondary BI server (the passive server). However, it
does not need to be so.
For example, if the Primary BI server fails, then ha-secondary takes its place as the
Primary BI server, and after ha-primary is returned to the cluster, as described in
RESTORING THE PRIMARY BI SERVER, then ha-primary becomes the Secondary BI server.
BI Server Networking
There are four different setups according to which to configure the BI server networking
in a Cluster deployment, two for High Availability and two not. The first, Full High
Availability, is the most recommended. The configuration setups are as follows:
• High Availability: The most recommended, there are two sets of two
interconnected switches. One set is public and the other private, and within each
set one switch is active and one backup. The public set is common with the DW.
Each BI server extends six links, with bonds as follows:
Full High Availability Public IP: External traffic connected to active- On Bond 0:
the active and backup core switches backup • Port 1
• Port 2
5-7
Data Sync IP: Internal DRBD On Bond 1:
communication connected to the active • Port 5
and backup core switches
• Port 6
Internal HA: Communication On Bond 2:
connected to the active and backup • Port 3
core switches
• Port 4

• Non-High Availability: There is one switch, split between private and public. All
communication goes through the core switch. The same port numbers should be
used on each BI server. Each BI server extends three links, with bonds as follows:
Non-High Public IP: External traffic connected to balance- Port 1
Availability (1) the core switch rr
Data Sync IP: Internal DRBD Port 5
communication connected to the core
switch
Internal HA: Communication connected Port 3
to the core switch

5-8
6 ClearSee Installation
This chapter contains all ClearSee installation workflows and procedures, both
STANDALONE and CLUSTER.
Each workflow is comprised of a number of links to installation procedures, as follows:
• Use the workflow as a guide in navigating the procedures.
• Verify throughout that you perform the procedures in the order indicated by the
workflows.
There are two flash drives:
• The ACP flash drive is provided, for the installation and configuration of the Allot
Common Platform.
• For all types of installations, the System flash drive includes the installation of the
application software.
The STANDALONE and CLUSTER workflows describe installation at the same time as running
the wizard. Alternatively, you can run the wizard and create installation files for use at a
later time, as described HERE.
After performing a workflow, the last step is to finalize the installation, which is described
in CLEARSEE CONFIGURATION .
6.1 Standalone Install Workflow

This workflow describe the detailed steps to install the Standalone ClearSee system,
according to provisioning. The types of provisioning are as described in CLEARSEE
PROVISIONING OPTIONS.
The workflow includes the following installations:
• Appliance: A ClearSee installation upon Allot hardware, after receiving this
hardware from Allot
• Software-Only: A ClearSee installation upon non-Allot hardware
IMPORTANT The command /root/netwconf.sh should never be run on any
ClearSee server.
IMPORTANT Before proceeding to a step or sub-step, verify that the processes of
the previous step or sub-step have completed.
1. Do one of the following:
⧫ For an Appliance installation, connect the system network and power cables
as described in STANDALONE DEPLOYMENTS , and then power up the server.

ClearSee Installation
⧫ For a Software-Only installation, verify that your hardware and operating
systems comply with the prerequisites described in SOFTWARE-ONLY
INSTALLATION REQUIREMENTS , and then INSTALL THE ACP.
IMPORTANT In BIOS settings, verify that CPU Frequency Scaling and CPU Power
Savings are disabled.
2. From the CLI, log in as admin, and then change user to root, as follows:
⧫ User: root
⧫ Password: bagabu
3. Insert the System flash drive, and then define the network configuration with the
netmenu script, as follows:
a. Run /root/netmenu.sh.
Similar to the following appears:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I n i t i a l N e t w o r k C o n f i g u r a t i o n M e n u
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# I/F MAC Address IP Address NETMASK UP

~~~ ~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~ ~~
1) eno1 : 40:f2:e9:09:93:4c V
2) eno2 : 00:25:90:05:10:0c V
3) eno3 : 40:f2:e9:09:93:4e V
4) eno4 : 40:f2:e9:09:93:4c V
5) enp134s0f0 : 00:25:90:05:10:0c V
6) enp134s0f1 : 00:25:90:05:10:0c V
~~~ ~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
7) Gateway :
8) Hostname : localhost.localdomain
9) DNS :
10) MNGT I/F :
11) NTP :
~~~ ~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
12) Clear All Network Configuration
13) Quit
b. Define the Hostname.

NOTE The hostname as you define it here is temporary and overwritten
when the ClearSee wizard is run.
a. Define the IP and subnet mask of the interface that you plan to be the MNGT
I/F, which is normally eno1.
b. Define the interface of the MNGT I/F.
c. Optionally, provide the IP address of the Gateway, which must belong to the
management IP subnet.
A completed netmenu for a Standalone server looks similar to the following:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
6-2

~~~ ~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~ ~~
1) eno1 : 40:f2:e9:09:93:4c 10.4.100.37 255.255.0.0 V
2) eno2 : 00:25:90:05:10:0c V
3) eno3 : 40:f2:e9:09:93:4e V
4) eno4 : 40:f2:e9:09:93:4c V
5) enp134s0f0 : 00:25:90:05:10:0c V
6) enp134s0f1 : 00:25:90:05:10:0c V
~~~ ~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
7) Gateway : 10.4.0.1
8) Hostname : clearsee-single.clearsee-single
9) DNS :
10) MNGT I/F : eno1
11) NTP :
~~~ ~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
13) Quit
d. Quit netmenu.
4. Move the ClearSee TGZ file to /opt/admin, and then extract the file with the
following command:
tar -xvzf <TGZ>
Where <TGZ> is the name of the file, including the extension
5. You may have previously created configuration files for use at a later time, as
described HERE. If you plan now to install ClearSee from these configuration files,
then copy the ansible_conf folder that contains the files into
/opt/admin/<TGZ>/install/, where <TGZ> is the name of the file including the
extension, and then continue with the install workflow. Otherwise, continue with
the install workflow.
6. Run the allotlogin script, as follows:
/opt/admin/bin/allotlogin.sh enable
7. Change to the folder containing the installation files:
cd /opt/admin/<TGZ>/install
NOTE If you fear you may get disconnected from the network in the course
of the installation, then you should perform the following step from
the console.
8. Run ./Allot_ClearSee.sh with any combination of flags, as described in the
following table:
If you want to do this: Do the following:
Launch the standard wizard 1. Run the script with no flags added:
./Allot_ClearSee.sh
2. Continue with the STANDALONE WIZARD .
6-3
Launch the standard wizard so that ClearSee installs with 1. Run the script with the -e flag:
encryption ./Allot_ClearSee.sh -e
2. Continue with the STANDALONE WIZARD .
Launch the advanced wizard 1. Run the script with the -a flag:
./Allot_ClearSee.sh -a
2. Continue with the STANDALONE WIZARD , with
additional questions described HERE.
Launch the advanced wizard so that ClearSee installs with 1. Run the script with the -e and -a flags:
encryption ./Allot_ClearSee.sh -e -a
2. Continue with the STANDALONE WIZARD , with
Install ClearSee from a PREVIOUSLY-CREATED CONFIGURATION Run the script with with the -d flag:
FILE ./Allot_ClearSee.sh -d
Install ClearSee from a PREVIOUSLY-CREATED CONFIGURATION Run the script with the -e flag:
FILE with encryption ./Allot_ClearSee.sh -e
NOTES:
• On an Allot appliance, Allot does not recommend running the advanced
wizard.
• For servers with only one interface (no bond), you should run the
advanced wizard.
• For help, run the script with the -h flag: ./Allot_ClearSee.sh -h
Installation commences.
9. You can use the following for troubleshooting:
⧫ For details on the progress of the installation, read
/var/log/allot/ansible.log, as described in INSTALLATION AND UPGRADE LOGS.
⧫ For the installation files that ClearSee based the installation on, go to
/opt/admin/<TGZ>/ansible_conf, where <TGZ> is the name of the file,
including the extension.
10. Clean the browser cache before connecting again to the system.
11. To finalize the installation, continue with CLEARSEE CONFIGURATION .
NOTE After the installation procedure, we recommend that you do the
following:
• If you did not do so during installation, change the DW password
and system root password to be secure and unique, as described
HERE .
• Perform a sanity check, as described HERE.
6-4
6.2 Cluster Install Workflow

This workflow describe the detailed steps to install the Cluster ClearSee system, according
to provisioning. The types of provisioning are as described in CLEARSEE PROVISIONING
OPTIONS.
The workflow includes the following installations:
• Appliance: A ClearSee installation upon Allot hardware, after receiving this
hardware from Allot
• Software-Only: A ClearSee installation upon non-Allot hardware
IMPORTANT The command /root/netwconf.sh should never be run on any
ClearSee server.
⧫ For an Appliance installation, connect the system network and power cables
as described in CLUSTER DEPLOYMENTS .
⧫ For a Software-Only installation, verify that your hardware and operating
systems comply with the prerequisites described in SOFTWARE-ONLY
INSTALLATION REQUIREMENTS .
IMPORTANT For Software-Only, in BIOS settings, verify that CPU Frequency
Scaling and CPU Power Savings are disabled.
2. On the secondary BI server and on the DW servers, do the following:
a. For a Software-Only installation, INSTALL THE ACP and then continue. For an
Appliance installation, just power up the server.
b. From the CLI, log in as admin, and then change user to root, as follows:
▪ User: root
▪ Password: bagabu
c. Insert the System flash drive, and then define the network configuration with
the netmenu script, as follows:
i. Run /root/netmenu.sh.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~ ~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~ ~~
1) eno1 : 40:f2:e9:09:93:4c V
2) eno2 : 00:25:90:05:10:0c V
3) eno3 : 40:f2:e9:09:93:4e V
6-5
4) eno4 : 40:f2:e9:09:93:4c V
5) enp134s0f0 : 00:25:90:05:10:0c V
6) enp134s0f1 : 00:25:90:05:10:0c V
~~~ ~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
7) Gateway :
8) Hostname : localhost.localdomain
9) DNS :
10) MNGT I/F :
11) NTP :
~~~ ~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
13) Quit
ii. Define the Hostname.

iii. Define the IP and subnet mask of the interface that you plan to be the
MNGT I/F, which is normally eno1.
iv. Define the interface of the MNGT I/F.
v. Optionally, provide the IP address of the Gateway, which must belong to
the management IP subnet.
A completed netmenu looks similar to the following:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~ ~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~ ~~
1) eno1 : 40:f2:e9:09:93:4c 10.4.100.37 255.255.0.0 V
2) eno2 : 00:25:90:05:10:0c V
3) eno3 : 40:f2:e9:09:93:4e V
4) eno4 : 40:f2:e9:09:93:4c V
5) enp134s0f0 : 00:25:90:05:10:0c V
6) enp134s0f1 : 00:25:90:05:10:0c V
~~~ ~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
7) Gateway : 10.4.0.1
8) Hostname : clearsee-dw-1.clearsee-dw-1
9) DNS :
10) MNGT I/F : eno1
11) NTP :
~~~ ~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
13) Quit
vi. Quit netmenu.

d. Run the allotlogin script, as follows:
3. On the primary BI server, do the following:
a. For a Software-Only installation, INSTALL THE ACP and then continue. For an
Appliance installation, just power up the server.
6-6
b. From the CLI, log in as admin, and then change user to root, as follows:
▪ User: root
▪ Password: bagabu
4. On the primary BI server, insert the System flash drive, and then define the
network configuration with the netmenu script, as follows:
a. Run /root/netmenu.sh.
b. Define the Hostname.
c. Define the IP and subnet mask of the interface that you plan to be the MNGT
I/F, which is normally eno1.
d. Define the interface of the MNGT I/F.
e. Optionally, provide the IP address of the Gateway, which must belong to the
management IP subnet.
A completed netmenu for a Standalone server looks similar to the following:
f. Quit netmenu.
5. Move the ClearSee TGZ file to opt/admin, and then extract the file with the
following command:
tar -xvzf <TGZ>
6. You may have previously created configuration files for use at a later time, as
described HERE. If you plan now to install ClearSee from these configuration files,
then copy the ansible_conf folder that contains the files into
/opt/admin/<TGZ>/install/, where <TGZ> is the name of the file including the
extension, and then continue with the install workflow. Otherwise, continue with
the install workflow.
7. Run the allotlogin script, as follows:
cd /opt/admin/<TGZ>/install
NOTE If you fear you may get disconnected from the network in the course
of the installation, then you should perform the following step from
the console.
following table:
6-7
./Allot_ClearSee.sh
4. Continue with the CLUSTER WIZARD .
Launch the standard wizard so that ClearSee installs with 5. Run the script with the -e flag:
encryption ./Allot_ClearSee.sh -e
6. Continue with the CLUSTER WIZARD .
8. Continue with the CLUSTER WIZARD , with
Launch the advanced wizard so that ClearSee installs with 9. Run the script with the -e and -a flags:
encryption ./Allot_ClearSee.sh -e -a
10. Continue with the CLUSTER WIZARD , with
Install ClearSee from a PREVIOUSLY-CREATED CONFIGURATION Run the script with with the -d flag:
FILE ./Allot_ClearSee.sh -d
Install ClearSee from a PREVIOUSLY-CREATED CONFIGURATION Run the script with the -e flag:
FILE with encryption ./Allot_ClearSee.sh -e
NOTES:
wizard.
• For servers with only one interface (no bond), you should run the
advanced wizard.
Installation commences.
10. You can use the following for troubleshooting:
⧫ For details on the progress of the installation, read
/var/log/allot/ansible.log, as described in INSTALLATION AND UPGRADE LOGS.
⧫ For the installation files that ClearSee based the installation on, go to
/opt/admin/<TGZ>/ansible_conf, where <TGZ> is the name of the file,
including the extension.
following:
6-8
HERE .
6.3 Installing the ACP

This procedure describes how to install the ACP, and is part of the STANDALONE and
CLUSTER workflows. You do this on every server in your deployment.
To install the ACP:
1. Insert the ACP flash drive, and then power up the server.
After the server boots, the ACP Installation Kickstart appears.
Figure 6-1: ACP Installation Kickstart

2. Select Install CentOS 7 from Kickstart.
The installation is complete when the login page appears.
6-9
Figure 6-2: CentOS Login Dialog Box

3. Click N.
4. Login options appear.
6-10
Figure 6-3: CentOS Login

5. Enter the following credentials:
⧫ Username: root
6. Click Log In.
7. Right click on an open area of the screen, and then click Open in Terminal.
6-11
Figure 6-4: Allot Kickstart Process (Opening a Terminal)

The CLI opens.
8. Remove the USB flash drive.
The ACP has been installed.
9. Return to the STANDALONE or CLUSTER workflow.
6.4 Answering the Standalone Wizard

This procedure describes how to answer the Standalone wizard, and it is part of the
STANDALONE workflow as well as CREATING INSTALLATION FILES FOR USE AT A LATER TIME.
After running ./Allot_ClearSee.sh or ./Allot_ClearSee.sh -e, the following
appears:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--- Installation Mode ---
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Options:
1: New single installation

2: New cluster installation
3: Exit
Please enter the option number:
1. Enter 1, and then continue with and answer the following questions:
--- System Configuration ---
6-12
---------------------------------------------------------------------------
ClearSee needs the IP of the NTP server to which ClearSee is to connect.
---------------------------------------------------------------------------
Please enter the NTP server IP address [8.8.8.8]:

- Your answer:
---------------------------------------------------------------------------
ClearSee needs the default gateway.
---------------------------------------------------------------------------
Please enter the default gateway [10.50.0.1]:

- Your answer:
---------------------------------------------------------------------------
ClearSee needs the IP of your SMTP mail server.
---------------------------------------------------------------------------
Please enter the Mail server IP address [127.0.0.1]:

- Your answer:
---------------------------------------------------------------------------
ClearSee needs the hostname of the ClearSee server.
---------------------------------------------------------------------------
Please enter the server hostname [single]:

- Your answer: single
---------------------------------------------------------------------------
ClearSee needs the password for the root user on the ClearSee server.
---------------------------------------------------------------------------
Please enter the root user password:
Please re-enter the root user password:
NOTE ClearSee supplies many of the default answers from the netmenu
script.
The following appears, completed:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please confirm the System Configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Options:
1) NTP Server :
2) DNS Server :
3) Gateway :
6-13
4) Mail Server :
5) Hostname : single
6) Vertica Data Disk : sdb
7) Create Bonds : yes
To change an answer, enter the number of the row. To continue, enter OK:
2. Enter the number of the row that you want to change, or enter ok and then
continue with and answer the following questions:
--- Network Configuration for single, bond0 ---
---------------------------------------------------------------------------
ClearSee needs to know the IP address.
---------------------------------------------------------------------------
Please enter the IP address for single, bond0:

- Your answer:
---------------------------------------------------------------------------
ClearSee needs to know the netmask address.
---------------------------------------------------------------------------
Please enter the netmask for single, bond0 [255.255.0.0]:

- Your answer:
---------------------------------------------------------------------------
ClearSee needs to know the bond's first NIC interface.
---------------------------------------------------------------------------
Please enter the first NIC interface for single, bond0:

- Your answer:
---------------------------------------------------------------------------
ClearSee needs to know the bond's second NIC interface.
---------------------------------------------------------------------------
Please enter the second NIC interface for single, bond0:

- Your answer:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please confirm the network configuration of the single server
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Options:
1) Bond0_address :
2) Bond0_netmask :
3) Bond0_Bond-interface-1 :
6-14
3. Enter the number of the row that you want to change, or enter ok.
The wizard’s final question appears:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
How do you want to continue?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Options:
1: Installation
2: Save configuration file
3: Exit

⧫ If you want to install now, then answer 1, and then return to the STANDALONE
INSTALL WORKFLOW.
⧫ If you want to save the configuration file for installation at a later time, then
answer 2 and and specify the folder in which to save the ansible_conf folder,
and then return to CREATING INSTALLATION FILES FOR USE AT A LATER TIME.
6.5 Answering the Cluster Wizard

This procedure describes how to answer the Standalone wizard, and it is part of the
CLUSTER workflow as well as CREATING INSTALLATION FILES FOR USE AT A LATER TIME.
After running ./Allot_ClearSee.sh or ./Allot_ClearSee.sh -e, the following
appears:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--- Installation Mode ---
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Options:
1: New single installation

2: New cluster installation
3: Exit
5. Enter 2, and then continue with and answer the following questions:
--- System Configuration ---
---------------------------------------------------------------------------
ClearSee needs the IP of the NTP server to which ClearSee is to connect.
---------------------------------------------------------------------------
Please enter the NTP server IP address [8.8.8.8]:

- Your answer:
6-15
---------------------------------------------------------------------------
ClearSee needs the IP of your SMTP mail server.
---------------------------------------------------------------------------
Please enter the Mail server IP address [127.0.0.1]:

- Your answer:
---------------------------------------------------------------------------
ClearSee needs to know the Cluster VIP address.
---------------------------------------------------------------------------
Please enter the Cluster VIP address [14.15.16.17]:

- Your answer:
---------------------------------------------------------------------------
ClearSee needs the default gateway.
---------------------------------------------------------------------------
Please enter the default gateway [10.50.0.1]:

- Your answer:
---------------------------------------------------------------------------
ClearSee needs to know the number of DW servers.
---------------------------------------------------------------------------
Please enter the number of DW servers [3]:

- Your answer: 3
---------------------------------------------------------------------------
ClearSee needs the password for the root user on the ClearSee server.
---------------------------------------------------------------------------
Please enter the root user password or press ENTER for the default:
Please re-enter the root user password or press ENTER for the default:
NOTE ClearSee supplies many of the default answers from the netmenu
script.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please confirm the System Configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Options:
1) NTP Server :
2) DNS Server :
3) Mail Server :
4) Vertica Data Disk : sdb
6-16
5) Create Bonds : yes
6) VIP ADDRESS :
7) Gateway :
8) Number of DW servers : 3
6. Enter ok, and then continue with and answer the following questions about the
BI servers, first for the Primary BI server, and second for the Secondary BI server:
---------------------------------------------------------------------------
---------------------------------------------------------------------------
Please enter the server hostname [clearsee-bi-primary]:

- Your answer: clearsee-bi-primary
--- Server clearsee-bi-primary: management bond0 configuration ---

---------------------------------------------------------------------------
---------------------------------------------------------------------------
Please enter the IP address for clearsee-bi-primary, bond0:

- Your answer:
---------------------------------------------------------------------------
---------------------------------------------------------------------------
Please enter the netmask for clearsee-bi-primary, bond0 [255.255.0.0]:

- Your answer:
---------------------------------------------------------------------------
---------------------------------------------------------------------------
Please enter the first NIC interface for clearsee-bi-primary, bond0:

- Your answer:
---------------------------------------------------------------------------
---------------------------------------------------------------------------
Please enter the second NIC interface for clearsee-bi-primary, bond0:

- Your answer:
--- Server clearsee-bi-primary: cluster bond1 configuration ---

---------------------------------------------------------------------------
6-17
---------------------------------------------------------------------------

- Your answer:
---------------------------------------------------------------------------
---------------------------------------------------------------------------

- Your answer:
---------------------------------------------------------------------------
---------------------------------------------------------------------------

- Your answer:
---------------------------------------------------------------------------
---------------------------------------------------------------------------

- Your answer:
--- Server clearsee-bi-primary: VIP bond2 configuration ---

---------------------------------------------------------------------------
---------------------------------------------------------------------------

- Your answer:
---------------------------------------------------------------------------
---------------------------------------------------------------------------

- Your answer:
---------------------------------------------------------------------------
---------------------------------------------------------------------------
6-18
- Your answer:
---------------------------------------------------------------------------
---------------------------------------------------------------------------

- Your answer:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please confirm the network configuration of the clearsee-bi-primary server
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Options:
1) Hostname :
2) Bond0_address :
3) Bond0_netmask :
6) Bond1_address :
7) Bond1_netmask :
10) Bond2_address :
11) Bond2_netmask :
7. Enter the number of the row that you want to change, or enter ok and then
continue with the DW servers, once for each DW server:
---------------------------------------------------------------------------
---------------------------------------------------------------------------
Please enter the server hostname [clearsee-dw-1]:

- Your answer: clearsee-dw-1
--- Server clearsee-dw-1: management bond0 configuration ---
NOTE On the DWs, Bond 0 is the Public IP.

---------------------------------------------------------------------------
---------------------------------------------------------------------------
Please enter the IP address for clearsee-dw-1, bond0:

- Your answer:
6-19
---------------------------------------------------------------------------
---------------------------------------------------------------------------
Please enter the netmask for clearsee-dw-1, bond0 [255.255.0.0]:

- Your answer:
---------------------------------------------------------------------------
---------------------------------------------------------------------------
Please enter the first NIC interface for clearsee-dw-1, bond0:

- Your answer:
---------------------------------------------------------------------------
---------------------------------------------------------------------------
Please enter the second NIC interface for clearsee-dw-1, bond0:

- Your answer:
--- Server clearsee-dw-1: cluster bond1 configuration ---
NOTE On the DWs, Bond 1 is the Private IP.

---------------------------------------------------------------------------
---------------------------------------------------------------------------
Please enter the IP address for clearsee-dw-1, bond1:

- Your answer:
---------------------------------------------------------------------------
---------------------------------------------------------------------------
Please enter the netmask for clearsee-dw-1, bond1 [255.255.0.0]:

- Your answer:
---------------------------------------------------------------------------
---------------------------------------------------------------------------
Please enter the first NIC interface for clearsee-dw-1, bond1:

- Your answer:
---------------------------------------------------------------------------
6-20
---------------------------------------------------------------------------
Please enter the second NIC interface for clearsee-dw-1, bond1:

- Your answer:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please confirm the network configuration of the clearsee-dw-1server
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Options:
1) Hostname :
2) Bond0_address :
3) Bond0_netmask :
6) Bond1_address :
7) Bond1_netmask :
8. Enter the number of the row that you want to change, or enter ok.
The wizard’s final question appears:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
How do you want to continue?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Options:
1: Installation
2: Save configuration file
3: Exit

⧫ If you want to install now, then answer 1, and then return to the CLUSTER
INSTALL WORKFLOW.
⧫ If you want to save the configuration file for installation at a later time, then
answer 2 and and specify the folder in which to save the ansible_conf folder,
and then return to CREATING INSTALLATION FILES FOR USE AT A LATER TIME.
6.6 Advanced Wizards

If you launched the the advanced ClearSee STANDALONE or CLUSTER installation wizard, by
running ./Allot_ClearSee.sh -e -a or ./Allot_ClearSee.sh -a, then the following additional
questions appear in the wizard:
6-21
• In the System Configuration section, the following appear:
---------------------------------------------------------------------------
ClearSee needs the data disk type of the server on which ClearSee is to be
installed. This may be, for example, sda or sdb.
---------------------------------------------------------------------------
Please enter the ClearSee data disk type:

- Your answer:
---------------------------------------------------------------------------
ClearSee wants to know if you want high availability (HA) on the network
level. High Availability is achieved through creating a bond out of the
NICs on your ClearSee server.
---------------------------------------------------------------------------
Do you want network High Availability (HA)? [yes]:

Options:
1: yes
2: no
- Your answer:
NOTE Allot recommends installing ClearSee with High Availability.

• In the Network Configuration section of a server, the following appears:
---------------------------------------------------------------------------
ClearSee needs the number of HA network interfaces (bonds).
---------------------------------------------------------------------------
How many bonds do you want to create from the NICs for single: [2]
- Your answer:
6.7 Creating Installation Files for Use at a Later Time

This procedure describes how to create installation files for Standalone or Cluster
installations, by running the ClearSee wizard and saving your answers so that you can
install ClearSee from these files at any later time. This is also useful if you want to install
multiple instances of ClearSee with the same configuration.
With these installation files, you can install ClearSee using the the STANDALONE and
CLUSTER workflows.
To create ClearSee installation files for use at a later time:
1. At any workstation, from the CLI, log in as admin, and then change user to root,
as follows:
⧫ User: root
6-22
2. Insert the System flash drive.
3. Move the ClearSee TGZ file to opt/admin, and then extract the file with the
following command:
tar -xvzf <TGZ>
cd /opt/admin/ClearSee_16.1.10/install
following table:
./Allot_ClearSee.sh
2. Continue with the STANDALONE or CLUSTER
wizard.
3. For the wizard’s final question, answer 2 and
specify the folder in which to save the
ansible_conf folder.
2. Continue with the STANDALONE or CLUSTER
wizard, with additional questions described
HERE .
3. For the wizard’s final question, answer 2 and
specify the folder in which to save the
ansible_conf folder.
NOTES:
wizard.
The files are saved in a folder called ansible_conf, within
/opt/admin/ClearSee_16.1.10/install/.
6. Save the ansible_conf folder for use at a later time.
6-23
6.8 Virtual ClearSee Installation

For a virtual ClearSee installation, see ATN 1431 – Virtual Management Module
Installation Guide.
Virtual Install Workflow (Standalone)

This workflow describes how to perform a virtual Standalone ClearSee installation.
Installation should take around 30 minutes.
1. Verify that your hardware and operating systems comply with the prerequisites
described in VIRTUAL TEMPLATE REQUIREMENTS AND SPECIFICATIONS .
2. Deploy the template and power on the machine, according to one of the
following:
⧫ DEPLOYING THE OVF TEMPLATE
⧫ DEPLOYING THE KVM TEMPLATE
3. Open the Console tab of the server.
4. In the allot.com dialog box, select Not Listed, and, when prompted, enter the
following:
⧫ Username: root
⧫ Default Password: bagabu
Figure 6-5: vSphere Console – allot.com Dialog Box

5. Click Sign In, and then double-click Product Install.
6-24
Figure 6-6: vSphere Console – Product Install

The Welcome dialog box opens.
Figure 6-7: ClearSee Standalone Welcome Dialog Box

6. Click Continue.
6-25
Figure 6-8: Bond 0 NICs Dialog Box

7. On the Bond 0 NICs dialog box, select the NICs for bond 0, and then click OK.

8. On the Bond 1 NICs dialog box, select the NICs for bond 1, and then click OK.
6-26
Figure 6-10: Bond 1 Network Configuration Dialog Box

9. On the Bond 1 Network Configuration dialog box, enter the network
configuration address for bond 1, and then click OK.
Installation from this point takes up to 30 minutes.
The following happens:
a. The installation runs and installs ClearSee. Installation from this point takes
up to two hours.
b. Upon completion, the Installation Successful dialog box appears.
Figure 6-11: Installation Successful Dialog Box

10. For details on the progress of the installation, read /var/log/clearsee_intall.log.
following:
HERE .
6-27
Virtual Install Workflow (Cluster)
This workflow describes how to perform a virtual Cluster ClearSee installation. Installation
should take around two hours.
We recommend placing the virtual DWs on separate physical servers and the virtual BIs on
separate servers. However, a virtual DW and a virtual BI may be on the same physical
server.
1. Verify that your hardware and operating systems comply with the prerequisites
described in VIRTUAL TEMPLATE REQUIREMENTS AND SPECIFICATIONS .
2. Install the DW servers by doing the following for each:
a. Deploy the DW template and power on the machine, according to one of the
following:
▪ DEPLOYING THE OVF TEMPLATE
▪ DEPLOYING THE KVM TEMPLATE
b. Double-click Product Install.
Figure 6-12: vSphere Console – Product Install

The Welcome dialog box appears:
6-28
Figure 6-13: DW Cluster Installation Welcome Dialog Box

c. Click Continue.
The Bond 0 NICs dialog box appears.

d. On the Bond 0 NICs dialog box, select the internal NICs for bond 0, and then
click OK.
The Network Configuration for Bond 0 dialog box appears.
6-29
Figure 6-15: Bond 0 Network Configuration Dialog Box

e. On the Network Configuration for Bond 0 dialog box, enter the network
configuration for bond 0, and then click OK.
f. On the Bond 1 NICs dialog box, select the external NICs for bond 1, and then
click OK.
g. On the Network Configuration for Bond 1 dialog box, enter the network
configuration address for bond 1, and then click OK.
i. The installation runs and installs the DW server.
ii. Upon completion, the Installation Successful dialog box appears.
Figure 6-16: Installation Successful Dialog Box

h. Click OK.
3. Install the Secondary BI server by doing the following:
a. Deploy the BI template and power on the machine, according to one of the
following:
6-30
b. Open the Console tab of the server.
c. In the allot.com dialog box, select Not Listed, and, when prompted, enter the
following:
▪ Username: root
▪ Default Password: bagabu
d. Click Sign In, and then double-click Product Install.
The Welcome dialog box appears.
Figure 6-17: BI Cluster Installation Welcome Dialog Box

e. Select BI-Secondary.
6-31

f. On the Bond 0 NICs dialog box, select the external NICs for bond 0, and then
click OK.
Figure 6-19: Bond 1 Dialog Box

h. On the Bond 1 NICs dialog box, select the internal NICs for bond 1, and then
click OK.
6-32
Figure 6-20: Bond 2 Dialog Box

i. On the Bond 2 NICs dialog box, select the internal NICs for bond 2, and then
click OK.
i. The installation runs and installs the Secondary BI server.
4. Install the Primary BI server by doing the following:
a. Deploy the BI template and power on the machine, according to one of the
following:
b. Open the Console tab of the server.
c. In the allot.com dialog box, select Not Listed, and, when prompted, enter the
following:
▪ Username: root
d. Click Sign In, and then double-click Product Install.
The Welcome dialog box appears.
e. Select BI-Secondary.
f. On the Bond 0 NICs dialog box, select the NICs for bond 0, and then click OK.
6-33
h. On the Bond 1 NICs dialog box, select the NICs for bond 1, and then click OK.
i. On the Bond 2 NICs dialog box, select the NICs for bond 2, and then click OK.
The Number of DW Nodes dialog box appears.
Figure 6-21: Number of DW Nodes Dialog Box

j. Enter the number of DWs on your network.
The Configure Management IPs dialog box appears.
Figure 6-22: Configure Management IPs Dialog Box

k. Complete the Configure the Management IPs dialog box, and then click OK.
6-34
i. Installation from this point takes up to two hours.
5. For details on the progress of the installation, read /var/log/clearsee_intall.log.
following:
HERE .
Deploying the OVF Template

1. Insert the USB flash drive.
2. Open the VMWare vSphere client, select the File menu and choose Deploy OVF
Template….
Figure 6-23: vSphere Summary

The Deploy OVF Template dialog box appears, on the Source tab.
3. On the Source tab, click the Browse button, select an OVF file on the USB flash
drive, and then click Next.
6-35
Figure 6-24: vSphere Deploy OVF Template

The OVF Template Details tab appears.
6-36
Figure 6-25: vSphere Template Details

4. On the OVF Template Details tab, check that all information is correct (for
example, version and sizes), and then click Next.
The Name and Location tab appears.
5. Enter a name for the virtual machine (no more than 80 characters) or leave the
default name in the field and then click Next.
The Storage tab appears.
6-37
Figure 6-26: vSphere Storage

6. Select a datastore to store the deployed OVF template.
NOTE Datastores are a unifying abstraction for storage locations such as
Fibre Channel, iSCSI LUNs, or NAS volumes. On this page, you
select from datastores already configured on the destination cluster
or host. The virtual machine configuration file and virtual disk files
are stored on the datastore. Select a datastore large enough to
accommodate the virtual machine and all of its virtual disk files.
7. Click Next.
The Disk Format tab appears.
6-38
Figure 6-27: vSphere Disk Format

8. On the Disk Format tab, select the disk format for the virtual machine virtual
disks, as follows:
⧫ Thick Provisioned Lazy Zeroed: All storage is immediately allocated. Data
remaining on the physical device is not erased during creation, but is zeroed
out on demand at a later time on first write from the virtual machine
⧫ Thick Provisioned Eager Zeroed: All storage is immediately allocated. Data
remaining on the physical device is zeroed out when the virtual disk is
created. It might take much longer to create disks in this format than to
create other types of disks. This type of thick virtual disk supports clustering
features such as Fault Tolerance
⧫ Thin Provisioned: The storage is allocated on demand as data is written to
the virtual disks.
9. Click Next.
The Ready to Complete tab appears.
6-39
Figure 6-28: vSphere Ready to Complete

10. On the Ready to Complete tab, verify that the summary is correct, and then click
Finish.
The import process may take a few minutes to complete.
Figure 6-29: vSphere Deploying Progress Box

The virtual machine appears on the list.
6-40
Figure 6-30: vSphere Summary

11. Edit the Power Policy Settings, as follows:
a. From the list, select the host, and then, from the upper tabs, select
Configuration.
b. From the Hardware area, select Power Management, and then click
Properties.
The Edit Power Policy Settings dialog box appears.
c. From the Edit Power Policy Settings dialog box, select High Performance,
and then click OK.
6-41
Figure 6-31: Edit Power Policy Settings Dialog Box

NOTE We recommend remaining with the CPU and Memory values that are
default from the template. Decreasing these values may result in
ClearSee not working properly.
12. Power on the virtual machine, as follows:
a. From the list, select the machine.
b. From the Summary tab, click the Power On button.
Figure 6-32: vSphere Summary – Power On

The virtual machine powers on.
c. Open the Console tab of the server.
6-42
d. In the allot.com dialog box, select Not Listed, and, when prompted, enter the
following:
▪ Username: root
e. Click Sign In.
Deploying the KVM Template

Note: For the purpose of example, the following procedure uses Virt Manager and
RHEL.
1. Download the Virtual Manager of your choice such as Virt-Manager on the server
itself (from https://virt-manager.org/download/) and install it if you do not
already have one installed.
NOTE If you are using Xming (http://xming.en.softonic.com/) on your PC to run
the Virt-Manager in remote by using SSH, then open the Xming XLaunch
application and set your SSH program to forward X11 packets to the X
server.
For example with “SecureCRT”, under Options /Session Options,
select Port Forwarding/Remote/X11, and then click in the Forward
X11 packets checkbox.
2. Within the home folder, create the images folder, and then within images, create
the folder into which you will copy the template:
# mkdir /home/images/
# mkdir /home/images/<FOLDER NAME>
Where FOLDER NAME is the name of your folder.
3. Copy the two QCOW2 files and the XML file for the most recent version from the
USB drive to your new folder using the following commands:
# cp <USB LOCATION> /home/images/<FOLDER
NAME>/<FILENAME>_Disk-1.qcow2
NAME>/<FILENAME>_Disk-2.qcow2
NAME>/<FILENAME>.xml
Where FILENAME is the name of the QCOW or XML file.
4. Edit the XML file so that it contains the right path to the two QCOW2 files, on the
following line, for example:
<source file='/path/to/<FILENAME>_Disk-1.qcow2'/>
NOTE If you wish to change the name of the Virtual Machine, then you may
do so by editing the following values in the XML file:
</name><VM_NAME></name>
6-43
5. Create a new instance using the following command:
virsh define <FILENAME>.xml
The Virt-Manager appears.
Figure 6-33: Virt-Manager Interface

6. Select the desired ClearSee installation.
7. Click Open, and then click the light bulb icon to open the Virtual Machine Details
screen.
NOTE Do NOT click on the Start button at this time.
8. For each of the four NICs, do the following:
a. From the tabs on the left, select the virtual NIC.
6-44
Figure 6-34: Virtual Machine Details on the NIC Tab

b. From the Network Source dropdown list, select the physical Management
interface.
▪ For the two virtual NICs belonging to bond 1, select the active
Management interface.
▪ In a Cluster, for the two virtual NICs belonging to bond 0, select the
backup Management interface.
c. From the Source Mode dropdown list, select Bridge.
d. Click Apply.
9. Power on the Virtual Machine, and then log in as root to the machine using the
Virtual Manager UI, with default password as bagabu.
6-45
7 ClearSee Configuration
To finalize your ClearSee installation, you must perform the following configuration
procedures, which are relevant for both Standalone and Cluster deployments, and
Appliance and Software-Only installations.
Configuration takes place in the following areas:
• INTEGRATING CLEARSEE WITH NETXPLORER: Integrate ClearSee with NetXplorer, for
the sake of building your ClearSee system.
• PERFORMING CLEARSEE CLI CONFIGURATION: Configure ETL parameters, as well as:
⧫ SETTING THE TIME ZONE: Set the time zone, which is comprised of steps from
the Setup Tool, the Vertica menu and the Reporting panel.
⧫ ENABLING CLEARSEE FIELDS FROM THE AOS CLI: Enable some parameters so that
they can be viewed in ClearSee reports and dashboards.
⧫ CHANGING THE REAL TIME REFRESH RATE: Change how often the data refreshes
in the Real-Time monitors.
Also included is LOGGING IN TO CLEARSEE AS ADMINISTRATOR, which is helpful in setting the
time zone and elsewhere.
7.1 Logging in to ClearSee as Web_Admin

This procedure describes how to log in to ClearSee as Web_Admin, and it is important
when performing administrator tasks such as SETTING THE TIME ZONE.
1. Open ClearSee home:
http://<IP ADDRESS>:8080/ClearSee/servlet/mstrWeb
The ClearSee home login page appears:

ClearSee Configuration
Figure 7-1: ClearSee Login Page

1. Enter the following first-time login credentials:
⧫ Username: Web_Admin
⧫ Password: Web_Admin
NOTE At a later stage, you must change your password from the default to
a unique, secure password, as described in MODIFYING A USER
ACCOUNT.
2. Click Login.
You are logged in to ClearSee as Web_Admin, and the ClearSee home page
appears.
7-2
7.2 Accessing NetXplorer
This procedure describes how to access NetXplorer, which you must do in order to
integrate ClearSee with NetXplorer. The first time that you connect to the NetXplorer, you
may be prompted to install Java 1.6.
To connect to NetXplorer:
1. In Internet Explorer, browse to http://<NX IP> and select Launch NetXplorer in
the NetXplorer Control Panel.
OR
Double click the shortcut icon on the desktop or in the system’s Start menu.
2. The Java Application Starting window is displayed.
3. The NetXplorer Log On dialog is displayed.
Figure 7-2: NetXplorer Login Dialog Box

4. In the User Name field, enter admin and in the Password field, enter allot or the
password that was established at set up. These are the default user name and
password. They may be different if you changed them during the initial
configuration.
5. Click Log On. The NetXplorer GUI is displayed. For an overview of NetXplorer
navigation, see NETXPLORER USER INTERFACE.
NOTES

o It may take a few moments to display the NetXplorer GUI.
o For additional security it is possible to require authentication on all transactions
between the NetXplorer Client and Server. For more information, contact Allot
Customer Support.
o If a user tries to login to a particular account using the wrong password within a
configurable time period (the default is 1 hour), then he can be "locked out" after a
configurable number of failed attempts (the default is 3 attempts). The user will be
locked out for a configurable length of time (the default is 1 hour). This feature is
disabled by default. Contact Allot Customer Support to enable the feature and/or
change any of the default values.
7.3 NetXplorer User Interface

The NetXplorer window is displayed when you open the program.
Menu
Bar
Quick Access
Toolbar
Main
Toolbar
Navigation
Pane
Application
Pane
Logs Pane
Figure 7-3: NetXplorer Window Components

The NetXplorer interface is comprised of the following components:
• Menu Bar: Provides easy access to the key functionality of the NetXplorer
applications
• Main Toolbar: Provide access to key NetXplorer functionality
• Quick Access Toolbar: Displays those buttons which are most relevant for the
operation currently active in the Applications Pane
• Navigation Pane: Divided into the following two sections:
⧫ The lower portion enables you to select and open various NetXplorer
applications.
7-2
⧫ The upper portion displays a tree-like list of subcomponents or entries
according to the application selected in the portion.
• Application Pane: Displays data regarding the currently active applications and
operations
• Logs Pane: Displays the Alarms Log, a list of the alarms triggered by the alarm
definitions
7.4 Integrating ClearSee with NetXplorer

After installation, you must integrate ClearSee with NetXplorer. NetXplorer provides a
centralized management system for all NetEnforcers or Service Gateway devices on the
network.
To integrate ClearSee with NetXplorer:
1. ACCESS NETXPLORER.
2. APPLY THE CLEARSEE LICENSE .
3. Depending on your installation, do one of the following:
⧫ BUILD A STANDALONE CLEARSEE SYSTEM .
⧫ BUILD A CLUSTER CLEARSEE SYSTEM .
4. For the reports and dashboards that you need, verify that all required DRs are
enabled, as follows:
a. Refer to the ClearSee Operation Guide, Chapter 5: Report and Dashboard
Profiles and Mapping for a list of the ClearSee reports and dashboards and
the DRs required for each.
b. Refer to the Data Mediator Install & Admin Guide, Chapter 4: Enabling CDR
Types and Working with Profiles for procedures to enable the required
buckets. Use the following table as a quick reference:
CDR Type Location Area on Tab
HTTP Network Configuration, Integrated WebSafe Service Specific Configuration
Service tab
RT Solicited Network Configuration, Servers tab Allowed Hosts
HDR Service Activation tab HTTP CDR
MOU VOIP Reports
VDR Video Data Records
5. After adding ClearSee to NetXplorer, do the following:
a. Wait a few minutes until you are able to open Data Mediator configuration.
7-3
b. In the Data Mediator Properties dialog box, verify that the associated output
profile appears in the Associated Output Profiles area, and that no other
associated profile appears there. For more information, see Chapter 4 of the
Data Mediator Install and Admin Guide.
NOTE After you add a ClearSee system to NetXplorer, the following
changes occur:
• The STC (Short Term Collector) stops collecting data.
• STC/LTC historical data ceases to be available in NetXplorer.
• The Data Mediator starts collecting data for ClearSee (replacing
STC functionality).
If you have already built your system, and now you want to make changes, see MODIFYING
A CLEARSEE SYSTEM .
Applying the ClearSee License

This procedure describes how to apply your NetXplorer license including ClearSee, which
you must do before building your ClearSee system. It is part of INTEGRATING CLEARSEE WITH
NETXPLORER and CLEARSEE CONFIGURATION .
ClearSee licensing is described HERE.
To apply the ClearSee license:
1. From the NetXplorer menu, select Tools > NetXplorer Application Server
Registration.
The NetXplorer Application Server Registration dialog box appears.
7-4
Figure 7-4: NetXplorer Application Server Registration Dialog Box

2. Do the following:
⧫ In the Activation Key field, enter your activation key.
⧫ In the Serial Number field, enter your serial number.
7-5
Figure 7-5: NetXplorer Application Server Registration Dialog Box

3. Under Attributes, verify the following:
⧫ ClearSee DB Capacity must be more more than 1.
⧫ If you have a license for ClearSee Analytics, then Active Subscriber must be a
positive number.
4. Click Save.
NetXplorer updates to include ClearSee.
5. Continue with Building the ClearSee System, either STANDALONE or CLUSTER.
7-6
Building a Standalone ClearSee System
This procedure describes how to build the Standalone ClearSee system, which you must
do after installation. It is part of INTEGRATING CLEARSEE WITH NETXPLORER and CLEARSEE
CONFIGURATION .
Involved is defining the BI-DW instance and the DM, then configuring the system on the
network, and finally performing some optional configurations.
To build the Standalone ClearSee system:
1. Define the BI-DW instance, as described in DEFINING A BI INSTANCE IN THE
NAVIGATION PANE.
NOTE When situated in a standalone system, the BI instance is actually
referred to as the BI-DW instance.
⧫ Define the DM, as described in Chapter 3 of the Data Mediator Install and
Admin Guide, and associate the ClearSee output profile with it.
⧫ If, for the purpose of HA, you defined multiple DMs in virtual IP groups, then
connect the HAP DMs to ClearSee, as described in DEFINING DMS WITH
VIRTUAL IPS.
3. In the NetXplorer Navigation pane, right-click the Network node, and then select
Configuration.
The Network Configuration area appears.
4. Select the ClearSee tab.
Figure 7-6: ClearSee Tab in NetXplorer

5. In the ClearSee Systems area, click Add.
The ClearSee System – New dialog box appears, on the General tab.
7-7
Figure 7-7: ClearSee System – Dialog Box

⧫ In the System Name field, name your ClearSee system.
⧫ From the Selected BI dropdown list, select the BI instance for your ClearSee
system.
The BI Type and Deployment Type fields are populated accordingly.
NOTE When situated in a Standalone system, the BI instance is actually
the BI-DW instance, and thus it is referred.
⧫ From the NetworkSecure Deployment Mode dropdown list, select the
appropriate mode, which determines the NetworkSecure dashboards and
templates that appear for you in ClearSee. For more information, see REPORT
AND NETWORK SECURE DEPLOYMENT M ODES . For a list of which reports,
dashboards and templates appear with which modes, see the ClearSee
Operation Guide, Chapter 4: Reports and Dashboards, Reports and
Dashboards Overview.
7-8
⧫ If you do not intend to use ClearSee’s GUI, but rather just use the ClearSee
back end, then, to save resources, select Smart Data Export Only Mode, as
described in REPORT AND NETWORKSECURE DEPLOYMENT MODES.
⧫ Define the ETL group, as described in DEFINING THE STANDALONE ETL GROUP.
⧫ From the SNMP tab as needed, CONFIGURE ADDITIONAL SNMP TRAPS
DESTINATION .
⧫ From the Data Source Files tab as needed, DEFINE EXTERNAL DATA FILES.
⧫ From the Aggregations tab, CONFIGURE DATA RETENTION AND AGGREGATION
DELAY .
NOTES
• The actions performed on the Aggregations tab are required.
• As Transfer Method, the FTP option is currently not in use.
⧫ From the Report Mode dropdown list, select the appropriate mode, which
determines the reports and dashboards that appear for you in ClearSee. For
more information, see REPORT AND NETWORKSECURE DEPLOYMENT MODES. For
a list of which reports, dashboards and templates appear with which modes,
see the ClearSee Operation Guide, Chapter 4: Reports and Dashboards,
Reports and Dashboards Overview.
⧫ Click Prime Time Configuration for Prime Time settings, as described in
DEFINING PRIME TIME SETTINGS.
7. Click OK.
On the ClearSee tab of the Network Configuration area, in the ClearSee Systems
area, the Standalone ClearSee system appears.
7-9
Figure 7-8: Completed ClearSee Systems Area (Standalone)

8. From the NetXplorer menu bar, click Save to permanently save the ClearSee
system.
In the Network Configuration area, under Data Mediation > Output Profiles, a
new associated output profile is automatically created, called after the name of
your ClearSee system, as follows:
⧫ If you have a Metrics license, then the name of the profile is comprised of
ClearSee Light Profile and then your ClearSee system.
⧫ If you have an Analytics license, then the name of the profile is comprised of
ClearSee Professional Profile and then your ClearSee system.
9. Return to INTEGRATING CLEARSEE WITH NETXPLORER.
Building a Cluster ClearSee System

This procedure describes how to build the Cluster ClearSee system, which you must do
after installation. It is part of INTEGRATING CLEARSEE WITH NETXPLORER and CLEARSEE
CONFIGURATION .
Involved is defining the BI and DW instances and the DM, then configuring the system on
the network, and finally performing some optional configurations.
To build the Cluster ClearSee system:
1. Define the BI Instances, as described in DEFINING A BI INSTANCE IN THE NAVIGATION
PANE.
2. Define a BI-HA group, as described in DEFINING A BI-HA GROUP IN THE NAVIGATION
PANE.
7-10
3. Define at least three DW instances, as described in DEFINING A DW INSTANCE IN THE
NAVIGATION PANE.
⧫ Define the DM, as described in Chapter 3 of the Data Mediator Install and
Admin Guide, and associate the ClearSee output profile with it.
⧫ If, for the purpose of HA, you defined multiple DMs in virtual IP groups, then
connect the HAP DMs to ClearSee, as described in DEFINING DMS WITH
VIRTUAL IPS.
Configuration.
7. In the ClearSee Systems area, click Add.
The ClearSee System – New dialog box appears, on the General tab.
⧫ In the System Name field, name your ClearSee system.
⧫ From the Selected BI dropdown list, select the BI-HA group that you defined
in DEFINING A BI-HA GROUP IN THE NAVIGATION PANE for your ClearSee system.
The BI Type and Deployment Type fields are populated accordingly.
⧫ From the NetworkSecure Deployment Mode dropdown list, select the
appropriate mode, which determines the NetworkSecure dashboards and
templates that appear for you in ClearSee. For more information, see REPORT
AND NETWORK SECURE DEPLOYMENT M ODES . For a list of which reports,
dashboards and templates appear with which modes, see the ClearSee
Operation Guide, Chapter 4: Reports and Dashboards.
⧫ If you do not intend to use ClearSee’s GUI, but rather just use the ClearSee
back end, then, to save resources, select Smart Data Export Only Mode, as
described in REPORT AND NETWORKSECURE DEPLOYMENT MODES.
⧫ Define the ETL group, as described in DEFINING THE CLUSTER ETL GROUP.
⧫ From the SNMP tab, as needed, CONFIGURE ADDITIONAL SNMP TRAPS
DESTINATION .
⧫ From the Data Source Files tab, as needed, DEFINE EXTERNAL DATA FILES.
DELAY .
NOTES
• The actions performed on the Aggregations tab are required.
7-11
• As Transfer Method, the FTP option is currently not in use.
⧫ From the Report Mode dropdown list, select the appropriate mode, which
determines the reports and dashboards that appear for you in ClearSee. For
more information, see REPORT AND NETWORKSECURE DEPLOYMENT MODES. For
a list of which reports, dashboards and templates appear with which modes,
see the ClearSee Operation Guide, Chapter 4: Reports and Dashboards.
⧫ Click Prime Time Configuration for Prime Time settings, as described in
DEFINING PRIME TIME SETTINGS.
9. Click OK.
area, the Cluster ClearSee system appears.
Figure 7-9: Completed ClearSee Systems Area (Cluster)

10. From the NetXplorer menu bar, click Save to permanently save the ClearSee
system.
In the Network Configuration area, under Data Mediation > Output Profiles, a
new associated output profile is automatically created, called after the name of
your ClearSee system, as follows:
⧫ If you have a Metrics license, then the name of the profile is comprised of
ClearSee Light Profile and then your ClearSee system.
⧫ If you have an Analytics license, then the name of the profile is comprised of
ClearSee Professional Profile and then your ClearSee system.
11. Return to INTEGRATING CLEARSEE WITH NETXPLORER.
7-12
Modifying a ClearSee System
After building a ClearSee system, you may need to modify it at a later date.
To modify a ClearSee system:
1. Do any of the following:
⧫ If your modification involves editing a server node, see EDITING A SERVER
NODE.
⧫ If your modification involves defining a new server node, see any of the
following:
▪ DEFINING A BI INSTANCE IN THE NAVIGATION PANE
▪ DEFINING A BI-HA GROUP IN THE NAVIGATION PANE
▪ DEFINING A DW INSTANCE IN THE NAVIGATION PANE
⧫ If your modification involves defining a new DM or editing the current one,
see Chapter 3 of the Data Mediator Install and Admin Guide.
Configuration.
7-13
Figure 7-10: NetXplorer ClearSee Tab

4. In the ClearSee Systems area, select the system you want to edit, and then click
Edit.
The ClearSee System – Update dialog box appears, on the General tab.
7-14
Figure 7-11: General Tab of ClearSee System Dialog Box

5. In the ClearSee System – Update dialog box, as needed, modify the system
criteria, as needed, using any of the following as reference:
⧫ DEFINING THE STANDALONE ETL GROUP
⧫ DEFINING THE CLUSTER ETL GROUP
6. In the ClearSee System – Update dialog box, as needed, modify the optional
configuration, using any of the following as reference:
⧫ From the SNMP tab, CONFIGURE ADDITIONAL SNMP TRAPS DESTINATION .
⧫ From the Data Source Files tab, DEFINE EXTERNAL DATA FILES.
DELAY.
7. Click OK.
area, the Standalone ClearSee system appears.
7-15
Figure 7-12: ClearSee Systems Area in Network Configuration

8. From the toolbar, click Save to permanently save the ClearSee system.
Defining a BI Instance in the Navigation Pane

Define in the NetXplorer Navigation pane the BI instance that you created earlier. If this is
a Standalone deployment, then the instance is called BI-DW.
To define the BI instance:
1. In the NetXplorer Navigation pane, in the Network tree, right-click the Servers
node , and then select New ClearSee BI.
The ClearSee BI Properties – New dialog box appears.
Figure 7-13: ClearSee BI Properties – New Dialog Box

a. In the Name field, name the BI instance as you want it to appear in the
Navigation pane.
b. In the IP Address field, enter the address of the BI instance.
c. Click Save.
The BI instance appears in the Navigation pane, under Servers.
7-16
3. Click Save to permanently save the BI instance on the network.

4. Return to any of the following:
⧫ BUILDING A STANDALONE CLEARSEE SYSTEM
⧫ BUILDING A CLUSTER CLEARSEE SYSTEM
⧫ MODIFYING A CLEARSEE SYSTEM
Defining a BI-HA Group in the Navigation Pane

For a Cluster deployment, define in the NetXplorer Navigation pane a BI-HA group, which
is comprised of the two BI instances that you created earlier.
To define the BI-HA group:
1. Define two BI instances, as described in DEFINING A BI INSTANCE IN THE NAVIGATION
PANE.
2. In the NetXplorer Navigation pane, with Network selected, right-click the Servers
node , and then select New ClearSee BI-HA Group.
The ClearSee BI-HA Properties – New dialog box appears.
Figure 7-14: ClearSee BI-HA Group Properties - New

3. In the Name field, name the BI-HA group as you want it to appear in the
Navigation pane.
4. In the Virtual IP field, enter the IP address of the virtual IP.
7-17
5. In the BI 1 field, select the BI instance that you want to serve as the primary BI
instance.
6. In the BI 2 field, select the BI instance that you want to serve as the secondary BI
instance.
7. Click Save.
The BI-HA group appears in the Navigation pane, under Servers.
8. From the toolbar, click Save to permanently save the BI-HA group on the
network.
Defining a DW Instance in the Navigation Pane

For a Cluster deployment, define in the NetXplorer Navigation pane the DW instance that
you created earlier. Repeat this procedure for each DW.
To define a DW instance:
1. In the NetXplorer Navigation pane, with Network selected, right-click the Servers
node , and then select New ClearSee DW.
The ClearSee DW Properties – New dialog box appears.
7-18
Figure 7-15: ClearSee DW Properties – New Dialog Box

a. In the Name field, name the DW instance as you want it to appear in the
Navigation pane.
b. In the IP Address field, enter the address of the DW instance.
c. Click Save.
The DW instance appears in the Navigation pane, under Servers.
3. From the toolbar, click Save to permanently save the DW instance on the
network.
Defining the Standalone ETL Group

This procedure is part of BUILDING A STANDALONE CLEARSEE SYSTEM, and describes how to
define the ETL group in a Standalone deployment. Involved is adding the ETL group
including the DW, and selecting the DM.
To configure the Standalone ClearSee system on the network:
1. In the ETL Groups area, click Add.
The ETL Group – New dialog box appears.
7-19
Figure 7-16: ETL Group – New Dialog Box (Standalone)

2. In the ETL Group Name field, name the ETL group.
3. In the DWs area, use the arrow key to move the BI-DW instance from Available
DWs to Selected DWs.
NOTE As this is a Standalone deployment, there is only one available DW,
that which the BI-DW instance comprises.
4. In the DMs area, click Add.
The Add DM to ETL Group dialog box appears.
7-20
Figure 7-17: Add DM to ETL Group Dialog Box

a. From the Selected DM dropdown list, select for your ETL group the DM with
the associated ClearSee output file.
In the IP field, the IP of the DM appears.
b. Ensure that Enable Data Collection is selected.
c. Click OK.
In the DMs area of the ETL Group – New dialog box, the DM appears in the table.
7-21
Figure 7-18: DMs Area of ETL Group – New

6. Click OK.
In the ETL Groups area of the ClearSee System – New dialog box, the ETL group
appears.
7-22
Figure 7-19: ETL Groups Area of ClearSee Systems – New

Defining the Cluster ETL Group

This procedure is part of BUILDING A CLUSTER CLEARSEE SYSTEM, and describes how to define
the ETL group in a Cluster deployment. Involved is adding the ETL group including the
DWs, and selecting the DM.
To configure the Cluster ClearSee system on the network:
1. In the ETL Groups area, click Add.
The ETL Group – New dialog box appears.
7-23
Figure 7-20: ETL Group – New Dialog Box (Cluster)

2. In the ETL Group Name field, name the ETL group.
3. In the DWs area, use the arrow key to move the DW instances from Available
DWs to Selected DWs.
4. In the DMs area, click Add.
The Add DM to ETL Group dialog box appears.
7-24
Figure 7-21: Add DM to ETL Group Dialog Box

a. From the Selected DM dropdown list, select for your ETL group the DM with
the associated ClearSee output file.
In the IP field, the IP of the DM appears.
b. Ensure that Enable Data Collection is selected.
c. Click OK.
In the DMs area of the ETL Group – New dialog box, the DM appears in the table.
7-25
Figure 7-22: DMs Area of ETL Group – New

6. Click OK.
In the ETL Groups area of the ClearSee System – New dialog box, the ETL group
appears.
7-26
Figure 7-23: ETL Groups Dialog Box

Editing a Server Node

After defining a BI instance, BI-HA group or DW instance, you may need to edit it at a later
date.
To edit a BI-DW instance, BI-HA group or DW instance:
1. In the NetXplorer Navigation pane, right-click the node, and then select
Properties.
That node’s Properties – New dialog box opens, for example, ClearSee BI.
7-27
Figure 7-24: ClearSee BI Properties – Update Dialog Box

2. Edit the fields as needed, by continuing as follows:
⧫ DEFINING A BI INSTANCE IN THE NAVIGATION PANE
⧫ DEFINING A BI-HA GROUP IN THE NAVIGATION PANE
⧫ DEFINING A DW INSTANCE IN NAVIGATION PANE
3. From the toolbar, click Save to permanently save the server node on the
network.
ClearSee Configuration with NetXplorer

The following configuration procedures are mostly optional. These procedures are part of
the following:
• BUILDING A STANDALONE CLEARSEE SYSTEM
• BUILDING A CLUSTER CLEARSEE SYSTEM
• MODIFYING A CLEARSEE SYSTEM
Configuring Additional SNMP Trap Destinations

The default SNMP traps destination is the NetXplorer server. However, you can configure
another five destination IP addresses.
This procedure is a part of the following:
7-28
To configure additional SNMP traps destinations:
1. From the ClearSee System – New or Update dialog box, open the SNMP tab.
Figure 7-25: SNMP Tab of the ClearSee System Dialog Box

2. In the IP field, type the IP of the traps destination you want to configure, and
then click Add.
The IP is added to the Destination IP table.
NOTE To remove a traps destination, select it from the Destination IP table,
and then click Delete.
Defining the External Data Files

To enrich your ClearSee reports and dashboards with various data not included by the
DM, you can upload the following external sources:
7-29
Filename Description Integration Granularity
iana.csv A presentation of a Data source for the Row = Single
common, clearly Autonomous autonomous system
defined routing System dimension value
policy to an
Internet segment
devices.csv List of user device Data source for the Row = Information
codes Devices dimension for a single device
information
subscribers.csv List of all Data source for the Row = Single
subscribers and Subscribers subscriber with
their relevant dimension various attributes
attributes, for
example age,
gender,
location/zip code,
alias name
network_access_technology. Network Access Data source for the Row = Single
csv Technology based Network Access network access
on SDR.SessionRAT Technology technology (code &
(2G, 3G, 4G) dimension name)
To define the external data files:
4. From the ClearSee System – New or Update dialog box, open the Data Source
Files tab.
7-30
Figure 7-26: Data Source Files Tab of the ClearSee System Dialog Box
5. Refer to Appendix 1: EXTERNAL DATA SOURCE FILE STRUCTURES for the file
structures.
6. For each file, click the Browse button.
The Choose File dialog box appears.
7. Navigate to and select the file, and then click Select.
The path appears in the Upload File column.
Configuring Data Retention and Aggregation Delay

For each data type in your ClearSee system you must configure two aggregation
parameters, data retention and delay. ClearSee applies these parameters differently for
each aggregation period, as follows:
7-31
Aggregation Period Data Retention Delay
Hour The number of days that the hour The delay in hours after the hour
is retained to appear in reports has concluded for data calculations
to commence
Day The number of days that the day The delay in hours after the day
is retained to appear in reports has concluded for data calculations
to commence
Month The number of months that the The delay in hours after the month
month is retained to appear in has concluded for data calculations
reports to commence
To configure data retention and aggregation delay:
1. From the ClearSee System – New or Update dialog box, open the Aggregations
tab.
7-32
Figure 7-27: Aggregations Tab of the ClearSee System Dialog Box

2. For each bucket type that you want to configure data retention and delay
settings, do the following:
a. From the Bucket Type dropdown list, select the bucket type.
b. Edit the Data Retention and Delay fields as needed, providing values within
those specified in parentheses.
Defining Prime Time Settings

This procedure describes how to configure Prime Time settings, so that your locale’s
conventions are properly reflected in the data of the Busy Hours dashboard, among
others.
Prime Time configuration is comprised of the following:
• Weekend Days: The days that constitute the weekend in your locale. The default
is Saturday and Sunday.
7-33
• Prime Time: The hours of the weekday in your locale when people have the most
free time and are likely to spend time online. The hours can be split up into
separate ranges of hours at different times of the day and different for weekdays
and weekends.
• Working Hours: The hours of the weekday in your locale when people are usually
at work or school, and therefore are less likely to spend time online. The hours
must be in a range and consecutive. The default is 09:00–17:00.
To define Prime Time settings:
1. From the ClearSee System – New or Update dialog box, on the General tab, click
Prime Time Configuration.
The Prime Time Configuration – Update dialog box appears.
7-34
Figure 7-28: Prime Time Configuration Dialog Box

2. From the Weekend Days area, select the days of your weekend, and for
Activation Date, enter today’s date.
3. For each of the fields in the Prime Time and Working Hour areas, do the
following:
a. Click the corresponding ellipsis button .

The Set Hours dialog box appears.
7-35
Figure 7-29: Set Hours Dialog Box

b. In the From and To fields, enter a range, and then click Add Range.
The range appears in the Hour Ranges listbox.
NOTE You can remove a range by clicking Remove.
c. Click OK.
The ranges appear in the corresponding field.
4. For Prime Time and for Working Hours, supply today’s date as the Activation
Dates.
5. Click OK.
The Prime Time Configuration – Update dialog box closes.
Defining DMs with Virtual IPs

This procedure describes how to define your DMs if, for the purpose of High Availability,
you enabled your DMs with virtual IP groups. This is an alternative step in Building a
ClearSee System (STANDALONE or CLUSTER), in order to add the DM to your ETL group and
connect the HAP DMs to ClearSee.
Each DM HAP contains two actual DMs.
To define the DM with virtual IPs, do all of the following:
• On each server comprising the solution:
7-36
a. Log in as admin and then as root.
b. For each DM HAP, run the command described below.
• In a Standalone deployment, and on the DWs of a Cluster deployment:
c. Log in as admin and then as root.
d. For each DM HAP, run the command described below.
For the procedure, run the following command:
dm_ipv=<DM HAP> ; for i in {<DM,DM>} ; do ssh-keyscan -
t rsa $i | sed "s/$i/$dm_ipv/g" >> ~/.ssh/known_hosts ;
done
Where:
• <DM HAP> is the virtual IP of the DM HAP.
• <DM> is the actual IP of a DM in the DM HAP, each separated by a comma.
As an example, consider the following solution deployment:
• 2 BI servers
• 5 DW servers
• 10 DM servers, 5 DM HAPs containing 2 DMs each
In such a deployment, the above command must be run as follows:
As Root
(2 5) 5
+ =7 * = 35 times as root
2 BIs 5 DWs 5 DM HAPs
As dbadmin
5 5 = 25 times as
* dbadmin
5 DWs 5 DM HAPs
35 + 25 = 60 times all
together
7.5 Performing ClearSee CLI Configuration

This procedure describes how to use the ClearSee Setup tool to change ETL parameters
and create configurations suitable to your system.
To perform ClearSee CLI configuration:
7-37
1. As user dbadmin, launch the ClearSee Setup tool by typing, from the CLI, the
following:
cs_setup
The ClearSee Setup tool menu appears.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Select configuration to edit or q to quit. |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
16.1.50.24
1) Configuration parameters
2) Copy Command
3) SNMP Configurations
4) Busy hours
5) Concurrent Users in ClearSee
6) TimeZone configuration
7) Enable/Disable all present insights.
8) Frequency
9) Asymmetric Traffic
10) Scheduled Tasks
Figure 7-30: ETL Configuration Tool Menu

⧫ To set the time zone of the system, continue with SETTING THE TIME ZONE.
⧫ To change any parameters, continue with CHANGING CONFIGURATION
PARAMETERS.
⧫ To change the Real-Time refresh rate, continue with CHANGING THE REAL-TIME
REFRESH RATE.
NOTE Options 1, 2, 3 and 5 have been deprecated and are currently
managed in NetXplorer.
⧫ To exit the ClearSee Setup tool, type q, and then press enter.
⧫ To perform further configurations, type q, and then return to step 1.
Setting the Time Zone

Following installation, the time zone must be set on all servers. If a server does not have
its time zone manually set, the default is UTC.
1. From the CLEARSEE SETUP TOOL MENU , type 6 for Time Zone configuration.
2. Enter the time zone identifier for the time zone, as appears, for example, in this
list of tz database time zones, in the TZ column.
7-38
3. In a new SSH session, check that the time zone did change, and then do the
following:
⧫ If the time zone did not change, repeat the procedure until now.
⧫ If the time zone did change, continue with the procedure.
4. Restart the DW database as follows:
a. STOP THE DW DATABASE.
b. START THE DW DATABASE.
5. LOG IN TO CLEARSEE AS WEB_ADMIN.
6. From the ClearSee Reporting panel, open Preferences.
Figure 7-31: Reporting Panel with Preferences Option
7. From the menu panel on the left, under Preferences Level,
select Project Defaults.
8. From the menu panel on the left, under Preferences, on the
General tab, in the Language area, select your Time Zone.
Figure 7-32: Time Zone Option in Preferences

9. In the upper left corner, click the Save icon.
A confirmation message appears that your personal preferences have been

saved.
7-39
NOTE If the time zone change does not take effect immediately, then log
out of ClearSee and then LOG BACK IN .
Enabling ClearSee Fields from the AOS CLI

This procedure describes how to enable certain parameters so that they can be viewed in
ClearSee analytics. The steps are performed from the AOS CLI.
To enable the ClearSee fields:
• In order to see the Activity Time per User field in the User Segmentation
dashboard, you must enable network_activity_time. Do the following:
a. From the AOS CLI, run the following command:
go config xml -node netw_act_time_state 1
b. Verify that network_activity_time is enabled:
go config view netw_act_time_state
• In order to view QoE measurement in certain Self Service reports, from the AOS
CLI you must run the following command:
go config xml -node dp_quality_measurement_enable
-value 1
This enables the following parameters:
⧫ RetransmittedTcpDataSegmentsIn
⧫ TotalTcpDataSegmentsIn
⧫ RetransmittedTcpDataSegmentsOut
⧫ TotalTcpDataSegmentsOut
⧫ RttEstimateExternalAvgMsec
⧫ RttEstimateInternalAvgMsec
• In order to enable the collection of subscriber device (mobile/station) types and
present the types in certain ClearSee graphs (such as Device Usage Trends), you
must enable device awareness. Do the following:
a. From the AOS CLI, run the following command:
go config xml -node dpi_device_classification_state -
value 1
b. To verify that dpi_device_classification_state is now set to 1, run the
following command:
go config view xml -node
dpi_device_classification_state
Changing Configuration Parameters

To change ClearSee configuration parameters:
7-40
1. From the CLEARSEE SETUP TOOL MENU , type 1 for Configuration Parameters.
The parameters appear that are available for changing.
2. Refer to the table below for a selection of Real-Time parameters, and for each
value you want to change, do the following:
a. Type the Configuration number of the parameter.
b. Change the value.
c. Confirm the change.
Configuration Number Parameter Description Default Value
43 rt_top_values Number of top values to 15
display
52 rt_min_refresh_interval • Refresh rate for all 15
Real-Time monitors, in
seconds
• Can be any multiple of
5 between 5–30
• Must be aligned with
the device
45 rt_max_rows Maximum rows when 200000
exporting to Excel
51 maxSolicited Maximum number of open 50
Real-Time solicited jobs
Changing the Real-Time Refresh Rate

This procedure describes how to change the refresh rate for the Real-Time monitors. The
default refresh rate is 15 seconds, which means that new data updates the monitors every
15 seconds. The rate can be changed to any multiple of 5 between 5 and 30 seconds.
To change the Real-Time refresh rate:
1. Refering to CHANGING CONFIGURATION PARAMETERS, change the
rt_min_refresh_interval value to the refresh rate you want, in seconds.
2. From the AOS CLI, run the following commands:
go config data_collect -rt_unsolic_conv_interval
<VALUE>
go config data_collect -rt_solic_conv_interval <VALUE>

Where <VALUE> is the new refresh rate.
7-41
3. In NetXplorer, in the Navigation pane, right-click Network and then, from the
popup menu, select Configuration.
4. Select the Data Mediation > Output Profiles tab.
5. From the Output Profiles list, select the ClearSee Analytics Profile, and then click
Edit.
Figure 7-33: Data Mediation > Output Profiles Tab

The Edit Data Output Profile dialog box appears.
6. Change the refresh rate in the CONV_RTU_CS output record as follows:
a. From the Associated Output Records list, select CONV_RTU_CS.
b. In the CONV_RTU_CS Output File > File Attributes area, change the File
Closing Interval (secs) to the new refresh rate.
7-42
c. Click OK.
7. Change the refresh rate in the CONV_RTS_CS output record as follows:
a. From the Associated Output Records list, select CONV_RTS_CS.
b. In the CONV_RTS_CS Output File > File Attributes area, change the File
Closing Interval (secs) to the new refresh rate.
c. Click OK.
8. Click or select Save from the File menu to save the changes to the
configuration.
Enabling the Exporting of Insights to Syslog

This procedure describes how to enable the exporting of ClearSee Insights to Syslog as
individual alerts. ClearSee Insights are notifications in real time of applicable insights from
activity on your network, and they appear in the GUI on certain dashboards.
7-43
Figure 7-34: Dashboard Insights

For more information about Insights, see the ClearSee Operation Guide, Viewing
Dashboard Insights.
To enable Syslog Insight exporting:
1. From the CLEARSEE SETUP TOOL MENU , type 7 for Enable/Disable all present
insights.
2. The option appears to enable the Insights’ export.
1) Disable
2) Enable
Enable or disable?
3. Enter option 2.
4. As writing to Syslog is based on the severity level, you must change, in the
$ETL_HOME/cfg/connection INI file, the minimum severity level for
syslog_debug_level, as described in CHANGING THE ETL ERROR SEVERITY LEVEL.
7-44
8 ClearSee Maintenance
8.1 Cluster Maintenance
This chapter covers various maintenance and repair procedures relevant to Cluster
installations.
Making Changes to the Internal IP Addresses—Pacemaker and

DRBD
Once the Cluster is installed, it is not possible to simply change the internal IP Addresses
directly. Instead, use the following procedure for changing the internal IP addresses for
the Pacemaker and DRBD networks.
IMPORTANT Before commencing this procedure, review HERE the difference
between the active server, the Primary BI server and ha-primary on
the one hand, and on the other the passive server, the Secondary BI
server and ha-secondary.
1. Checking which of the cluster servers is the “Active Server”. Type:
[root@clearsee-bi-primary ~]# pcs status
NOTE The following output will appear on the screen. In this case, the
server named “ha-primary” is identified as the Active Server:
Last updated: Wed Jan 22 04:48:14 2014
Last change: Wed Jan 22 03:19:08 2014 via crm_resource on ha-primary
Stack: cman
Current DC: ha-primary - partition with quorum
Version: 1.1.10-1.el6_4.4-368c726
2 Nodes configured
6 Resources configured
Online: [ ha-primary ha-secondary ]
Full list of resources:
ClusterIP (ocf::heartbeat:IPaddr2): Started ha-primary

Master/Slave Set: DRBDResource [pgsql]
Masters: [ ha-primary ]
Slaves: [ ha-secondary ]
DBFileSystem (ocf::heartbeat:Filesystem): Started ha-primary
PostgreSQL (ocf::heartbeat:pgsql): Started ha-primary
Tomcat (ocf::heartbeat:tomcat): Started ha-primary
2. Stopping the non-Active server. Go to the console of the non-Active server (as
identified in the above step) and type the following:
[root@clearsee-bi-secondary ~]# /etc/init.d/pacemaker
stop
The following is returned:

ClearSee Maintenance
Waiting for shutdown of managed resources. [ OK ]
Signaling Pacemaker Cluster Manager to terminate [ OK ]
Waiting for cluster services to unload. [ OK ]
Stopping cluster:
Leaving fence domain... [ OK ]
Stopping gfs_controld... [ OK ]
Stopping dlm_controld... [ OK ]
Stopping fenced... [ OK ]
Stopping cman... [ OK ]
Waiting for corosync to shutdown: [ OK ]
Unloading kernel modules... [ OK ]
Unmounting configfs... [ OK ]
3. Stopping the DRBD on the non-Active Server. Type:

[root@clearsee-bi-secondary ~]# /etc/init.d/drbd stop
Stopping all DRBD resources: .
Stopping the Cluster Services on the Active Server:
Continue stopping the DRBD on the non-Active server by typing:
[root@clearsee-bi-primary ~]# pcs resource stop PostgreSQL
[root@clearsee-bi-primary ~]# pcs resource stop DBFileSystem
[root@clearsee-bi-primary ~]# pcs resource stop Tomcat
[root@clearsee-bi-primary ~]# pcs resource stop ClusterIP
[root@clearsee-bi-primary ~]# pcs resource stop DRBDResource
[root@clearsee-bi-primary ~]# /etc/init.d/pacemaker stop
Waiting for shutdown of managed resources [ OK ]
Waiting for cluster services to unload...... [ OK ]
Stopping cluster:
4. Stopping the DRBD on the Active Server. Type:

-[root@clearsee-bi-primary ~]# /etc/init.d/drbd stop
--== Thank you for participating in the global usage survey ==--
The server's response is:
you are the 13740th user to install this version

Stopping all DRBD resources:
5. Changing the internal IP on the PACEMAKER network, on the Primary BI Server:

First, we must determine the current Internal IP Address on the network before
the change. (The default is 192.168.216.216)
This can be checked by the following procedure:
8-2
[root@clearsee-bi-primary ~]# cat
/etc/sysconfig/network-scripts/ifcfg-bond1 | grep
IPADDR
6. Determine the internal mask on the network after the change (Default:
255.255.255.0)
NETMASK
[root@clearsee-bi-primary ~]# sed 's/<OLD IP>/<NEW
IP>/g' -i /etc/sysconfig/network-scripts/ifcfg-bond1
[root@clearsee-bi-primary ~]# sed 's/<OLD MASK>/<NEW
MASK>/g' -i /etc/sysconfig/network-scripts/ifcfg-bond1
7. Changing the Internal IP address on the PACEMAKER network for the secondary
BI Server:
First: determine the Internal IP Address on the network before the change.
(Default is 192.168.216.217)
This can be checked by the typing:
IPADDR
Determine the internal IP mask on the network. (Default: 255.255.255.0)
NETMASK
[root@clearsee-bi- secondary ~]# sed 's/<OLD IP
ADDRESS>/<NEW IP ADDRESS>/g' -i /etc/sysconfig/network-
scripts/ifcfg-bond1
[root@clearsee-bi- secondary ~]# sed 's/<OLD MASK>/<NEW
MASK>/g' -i /etc/sysconfig/network-scripts/ifcfg-bond1
8. Changing the internal IP Address on the PACEMAKER network that is configured
in the hosts file for two servers (run two scripts on each server).
[root@clearsee-bi-primary ~]# sed 's/<OLD IP
ADDRESS>/<NEW IP ADDRESS>/g' -i /etc/hosts
Run the following commands on the BI-Primary Server:
ADDRESS>/<NEW IP ADDRESS>/g' -i /etc/ansible/hosts
8-3
9. Changing the Internal IP Address on the DRBD network on the Primary BI server:
a. Determine the internal IP Address of the Server before the change (default is
192.168.219.216). This can be checked by issuing the following command:
IPADDR
b. Determine the internal netmask of the Server before the change (default is
255.255.255.0). This can be checked by issuing the following command:
NETMASK
10. Internal IP Address of the Server after the change:
scripts/ifcfg-bond2
[root@clearsee-bi-primary ~]# sed 's/<OLD NETMASK>/<NEW
NETMASK>/g' -i /etc/sysconfig/network-scripts/ifcfg-
bond2
11. Changing the internal IP Address for the DRBD connection of the Secondary BI
server:
a. Determine the internal IP Address of the Server before the change (the
default is 192.168.219.217). To check the address, execute the following
command:
IPADDR
b. Determine the Internal netmask of the Server before the change (the default
is 255.255.255.0). To check the netmask execute the following command:
NETMASK
12. Internal Network address after the change:
[root@clearsee-bi- secondary ~]# sed 's/<OLD IP
scripts/ifcfg-bond2
[root@clearsee-bi- secondary ~]# sed 's/<OLD
NETMASK>/<NEW NETMASK>/g' -i /etc/sysconfig/network-
scripts/ifcfg-bond2
13. Changing the Internal IP Address for the DRBD Connection that is configured in
the hosts file in the two servers (run the following 2 commands on both servers):
8-4
[root@clearsee-bi-secondary ~]# sed 's/<OLD IP
14. Run the following commands only on the Primary BI server:
15. Changing the Internal IP Address for the DRBD connections that are configured in
the DRBD conf file on the two servers (run the following 2 commands on all
servers):
ADDRESS>/<NEW IP ADDRESS>/g' -i /etc/drbd.d/pgsql.res
ADDRESS>/<NEW IP ADDRESS>/g' -i /etc/drbd.d/pgsql.res
16. Restarting networking on the two servers (execute both commands on both
servers) and check that all connections restarted successfully:
[root@clearsee-bi-primary ~]# /etc/init.d/network
restart
Shutting down interface bond0: [ OK ]
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface bond0: [ OK ]
17. Checking that networking has restarted with the new IP Addresses correctly
configured:
a. Type:
[root@clearsee-bi-primary ~]# ping -c 2 192.168.120.2
PING 192.168.120.2 (192.168.120.2) 56(84) bytes of data.
64 bytes from 192.168.120.2: icmp_seq=1 ttl=64 time=0.036 ms
--- 192.168.120.2 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.033/0.034/0.036/0.006 ms
b. Type:
8-5
--- 192.168.120.3 ping statistics ---

c. Type:
--- 192.168.130.2 ping statistics ---

d. Type:
--- 192.168.130.3 ping statistics ---

18. Bringing up the Pacemaker and DRBD processes on the active server:
[root@clearsee-bi-primary ~]# /etc/init.d/pacemaker
start
Starting cluster:
Checking if cluster has been disabled at boot... [ OK ]
Checking Network Manager... [ OK ]
Global setup... [ OK ]
Loading kernel modules... [ OK ]
Mounting configfs... [ OK ]
Starting cman... [ OK ]
Waiting for quorum... [ OK ]
Starting fenced... [ OK ]
Starting dlm_controld... [ OK ]
Tuning DLM kernel config... [ OK ]
Starting gfs_controld... [ OK ]
Unfencing self... [ OK ]
Joining fence domain... [ OK ]
Starting Pacemaker Cluster Manager [ OK ]
[root@clearsee-bi-primary ~]# pcs resource start ClusterIP
[root@clearsee-bi-primary ~]# pcs resource start DRBDResource
8-6
[root@clearsee-bi-primary ~]# pcs resource start DBFileSystem
[root@clearsee-bi-primary ~]# pcs resource start PostgreSQL
[root@clearsee-bi-primary ~]# pcs resource start Tomcat
19. Bringing up the Pacemaker and DRBD processes on the Inactive Server:
[root@clearsee-bi-secondary ~]# /etc/init.d/pacemaker
start
Starting cluster:
Split-Brain Inconsistency Condition

The split-brain condition with regards to ClearSee occurs when the DRBD process
connecting the primary and secondary BI servers loses coherence, rendering them out of
sync. The result is that the integrity of the data on the two disks is compromised, with the
data on the one different from that on the other.
The solution of a split-brain condition is to duplicate the data from the primary server to
the secondary server, thus overwriting the data on the latter.
If you suspect that a split-brain condition has developed, follow the diagnosis procedure
described HERE.
To resolve a split-brain condition, see HERE.
Diagnosing a Split-Brain Condition

To diagnose a split-brain condition:
1. An SNMP event will be sent to the SNMP Receiver. In the OS log of one of the BI
Servers you will see the following messages. To see the messages, type the
following command:
[root@clearsee-bi-secondary ~]# cat /var/log/messages
Feb 19 14:12:53 clearsee-bi-secondary kernel: block drbd0: helper command:
/sbin/drbdadm initial-split-brain minor-0
8-7
/sbin/drbdadm initial-split-brain minor-0 exit code 0 (0x0)
/sbin/drbdadm split-brain minor-0
/sbin/drbdadm split-brain minor-0 exit code 0 (0x0)
2. Check the status of the DRBD process by typing the following:

[root@clearsee-bi-primary /]# drbdadm status
3. Decide which of the two servers to designate as the active server. Consult the
SNMP logs to determine first when the failure occurred, and then which data is
more critical and up-to-date.
Resolving a Split-Brain Condition

This procedure describes how to resolve a split-brain condition. You can only do this after
performing diagnosis, which includes designating the primary server as described HERE.
To resolve a spit-brain inconsistency problem:
1. Check the communication status on the internal DRBD network between the two
BI servers, as follows:
a. From the console of BI Server that will become the primary server, type:
[root@clearsee-bi-primary cluster]# ping -c 2 drbd-
clearsee-bi-primary
PING drbd-clearsee-bi-primary (192.168.130.2) 56(84) bytes of data.
64 bytes from drbd-clearsee-bi-primary (192.168.130.2): icmp_seq=1 ttl=64
time=0.034 ms
64 bytes from drbd-clearsee-bi-primary (192.168.130.2): icmp_seq=2 ttl=64
time=0.039 ms
--- drbd-clearsee-bi-primary ping statistics ---

b. From the console of the Server to be set to secondary server, type:

[root@clearsee-bi-primary cluster]# ping -c 2 drbd-
clearsee-bi-secondary
PING drbd-clearsee-bi-secondary (192.168.130.3) 56(84) bytes of data.
64 bytes from drbd-clearsee-bi-secondary (192.168.130.3): icmp_seq=1 ttl=64
time=7.49 ms
64 bytes from drbd-clearsee-bi-secondary (192.168.130.3): icmp_seq=2 ttl=64
time=0.513 ms
--- drbd-clearsee-bi-secondary ping statistics ---

c. Do one of the following:
8-8
▪ If the output matches the examples above, then continue to the next
step.
▪ If the output does not match the examples above, then resolve the
networking problem and then retry STEP 1.
2. Determine which server is currently the active server, that on which the cluster
services are located, as follows:
a. Type:
[root@clearsee-bi-primary ~]# pcs status
Similar to the following is returned:
Last updated: Thu Mar 6 07:42:04 2014
Last change: Tue Jan 21 11:16:53 2014 via cibadmin on ha-secondary
Stack: cman
Current DC: ha-secondary - partition with quorum
Version: 1.1.10-1.el6_4.4-368c726
2 Nodes configured

Masters: [ ha-secondary ]
Slaves: [ ha-primary ]
b. Do one of the following:

▪ If the active server is the server you had decided upon in DIAGNOSING A
SPLIT-BRAIN CONDITION, then continue with STEP 3.
▪ If the active server is not the server you had decided upon in DIAGNOSING
A SPLIT-B RAIN CONDITION , then continue with SWITCHING THE ACTIVE
SERVER, to switch the active server to the desired server.
a. From the console of the passive server, type the following:
[root@clearsee-<passive server> ~]# drbdadm secondary
pgsql
[root@clearsee-<passive server> ~]# drbdadm connect --
discard-my-data pgsql
b. From the console of the active server, type the following:
[root@clearsee-<active server> ~]# drbdadm connect
pgsql
8-9
4. Check that the fault has been repaired and that the cluster is functioning
properly by doing the following:
a. Type the following:
[root@clearsee-<active> ~]# drbdadm status
b. Verify that the output includes the statement appears as follows:
pgsql role:Primary
disk:UpToDate
<HOSTNAME> role:Secondary
peer-disk:UpToDate
Where <HOSTNAME> is the name of the passive server.

NOTE The statement UpToDate/UpToDate may take some time to appear as
data synchronization takes time.
Switching the Active Server

This procedure describes how to switch the active server from ha-secondary to ha-
primary, which may be important in RESOLVING A SPLIT-BRAIN CONDITION, as well as in
PERFORMING A CLUSTER UPGRADE.
The active server and the Primary BI server are the same. For more on the Primary BI
server and ha-primary, see PRIMARY AND SECONDARY BI SERVERS.
To switch the active server from ha-secondary to ha-primary:
1. From the console of the passive server, stop all processes by typing the following:
[root@clearsee-<passive server> ~]#
/etc/init.d/pacemaker stop
Waiting for shutdown of managed resources. [ OK ]
Waiting for cluster services to unload. [ OK ]
Stopping cluster:
2. From the console of the active server, verify that all the processes started by
typing:
[root@clearsee-<active server> ~]# pcs status
Last updated: Thu Mar 6 07:52:12 2014
Last change: Thu Mar 6 07:57:02 2014 via crm_resource on ha-primary
Stack: cman
8-10
Current DC: ha-secondary - partition with quorum
Version: 1.1.10-1.el6_4.4-368c726
2 Nodes configured

Masters: [ ha-primary ]
Slaves: [ ha-secondary ]
3. From the console of the passive server, type the following:

[root@clearsee-<passive server> ~]#
/etc/init.d/pacemaker start
Starting cluster:
The active server, the Primary BI server, has been switched from ha-secondary to
ha-primary.
Monitoring DW Load Status

The following section covers monitoring the load on the DW in a Cluster deployment. If
the load is too high, performance will suffer and it is advisable to add one or more
additional DW servers to the cluster.
The command for monitoring the DW, vnetperf, is a Vertica command. For more
information, see the Vertica documentation.
NOTE Be prepared to supply the command line with the internal IP
addresses of the DW Servers.
1. Verify that the time setting of all the DW servers are in sync.
8-11
2. Type the following command from any of the DW servers.
/opt/vertica/bin/vnetperf --hosts <IP NODE1>,<IP
NODE2>,<IP NODE3>
Where <IP NODE1>,<IP NODE2>,<IP NODE3> are the internal IP addresses of the
DWs
3. Check the following:
⧫ Value for each server: Close to 600 MB
⧫ RTT latency:
▪ Maximum recommended: 2 milliseconds
▪ Ideal RTT latency: 200 microseconds or less
⧫ Clock skew: Kept under 1 second
⧫ Throughput:
▪ Minimum recommended: 100 MB/s
▪ Ideal: 800 MB/s or more
test | date | node
| index | rtt latency (us) | clock skew (us)
---------------------------------------------------------------------------
----------------------------------------------
latency | 2014-03-05_08:49:31,924 | 192.168.10.11
| 0 | 99 | 7
latency | 2014-03-05_08:49:31,924 | 192.168.10.12
| 1 | 70 | 23128454
latency | 2014-03-05_08:49:31,924 | 192.168.10.13
| 2 | 103 | -10942248
NOTE UDP numbers may be lower, multiple network switches may reduce
performance results.
date | test | rate limit (MB/s) |
node | MB/s (sent) | MB/s (rec) | bytes (sent) | bytes
(rec) | duration (s)
---------------------------------------------------------------------------
---------------------------------------------------------------------------
----------------------------
2014-03-05_08:49:31,926 | udp-throughput | 32 |
192.168.10.11 | 30.5477 | 30.5477 | 32047104 |
32047104 | 1.00048
2014-03-05_08:49:31,926 | udp-throughput | 32 |
192.168.10.12 | 30.5141 | 30.5141 | 32047104 |
32047104 | 1.00159
…
2014-03-05_08:49:39,933 | udp-throughput | 2048 |
average | 573.521 | 572.904 | 601576789 |
601052501 | 1.00046
Restoring the Primary BI Server

This procedure describes how to return the Primary BI server to the cluster after a failure,
in order to restore High Availability.
8-12
NOTE The DNS names of the two servers are ha-primary and ha-
secondary. These names do not indicate which server is actually
currently primary or currently secondary, as follows:
When the Primary BI server fails, the Secondary BI server becomes
primary. After restoration, the formerly primary server becomes
Secondary BI. If the formerly primary server had been ha-primary,
then after restoration the Primary BI server is ha-secondary and the
Secondary BI is ha-primary.
To restore the Primary BI server:
1. Solve the hardware issues or otherwise that prevented normal operation from
the Primary BI server.
2. Verify that the system network and power cables are connected as described in
STANDALONE DEPLOYMENTS.
3. Power on the Primary BI server.
4. Refresh the Intelligence Cubes by running the following five commands:
rm -rf /cube/mstr-cube/ClusterCaches/*
rm -rf /cube/mstr-cube/ClusterCube/*
rm -rf /cube/mstr-cube/ClusterInbox/*
rm -rf /cube/mstr-cube/ClusterInBox/*
/opt/allot/clearsee/python/bin/python2.7
/opt/allot/clearsee/etl/pymodules/CubeInitialPublish/CubeInitialPublish.py
The following results:

⧫ The Primary BI server is returned to the cluster, restoring High Availability.
⧫ If the formerly primary server had been ha-primary, then the Primary BI
server is now ha-secondary and the Secondary BI is ha-primary.
8.2 Standalone Backup and Restore

To mitigate the harm of corruption, Allot recommends performing periodic backups of the
Vertica database. These procedures are specific to a Standalone deployment.
Preparing an External Device

This procedure describes how to prepare an external storage device for the purposes of
BACKUP and RESTORE and for migration.
To prepare an external device:

1. By way of USB, connect the external device to the server.
2. You can find out the name of the device using the following command:
df -h
8-13
3. Mount the disk and create the External directory by running the following
commands:
su -
mkdir /External
mount -o umask=0000,dmask=0000 /dev/[DEVICE NAME]
/External
Where [DEVICE NAME] is the name of the device
4. Create directories in the External directory by running the following commands:
mkdir /External/backup_vertica
mkdir /External/backup_pgsql
5. Give the dbadmin user full rights on this directory by running the following
command:
chmod -R 777 /External
Preparing a Remote Server

This procedure describes how to prepare a remote storage server for the purposes of
BACKUP and RESTORE and for migration.
To prepare a remote storage server:

1. Create the user by running the following commands:
su -
useradd dbadmin
2. Define the password, as follows:
a. Run the following command:
8-14
passwd dbadmin
b. Enter the password.
3. Create sub-directories and give the dbadmin user full rights on them, with the
following commands:
mkdir /home/dbadmin/backup_vertica
chmod 777 /home/dbadmin/backup_vertica
mkdir /home/dbadmin/backup_pgsql
chmod 777 /home/dbadmin/backup_pgsql
4. Ensure that there is no password prompt between servers, as follows:
a. Return to the ClearSee server, and then run the following commands:
su - dbadmin
ssh-copy-id dbadmin@[DEVICE IP]
Where [DEVICE IP] is the IP of the remote storage device
b. Enter dbadmin’s remote password, and then answer yes to the key
fingerprint.
Backing Up Vertica to an External Device

This procedure describes how to back up Vertica to an external device. As a prerequisite,
you must prepare the external device as described HERE. The procedure for restoring
Vertica from an external device is HERE.
To back up Vertica to an external device:
1. Log in to Vertica as user admin, and then switch users to dbadmin, with the
following command:
su - dbadmin
2. Stop the ETL process, as follows:
a. To stop, run the following script:
cs_admin stop
b. Wait until the system is down, and then verify that the system is down with
the following command:
cs_admin status
8-15
3. Run the VBR Python script utility to configure the backup, by doing one of the
following:
⧫ If you are currently in ClearSee 15.1 or below, then run the following
command:
/opt/vertica/bin/vbr.py –setupconfig
⧫ If you are currently in ClearSee 16.1 or above, then run the following
command:
/opt/vertica/bin/vbr.py –c
4. Create the backup’s INI file by completing the following wizard:
Snapshot name (backup_snapshot):
Destination Vertica DB bin directory (only required for object replication)
(/opt/vertica/bin):
Number of restore points (1):
Specify objects (no default):
Object restore mode (coexist, createOrReplace or create) (createOrReplace):
Enter: create
Vertica user name (dbadmin):
Save password to avoid runtime prompt? (n) [y/n]:
Enter: n
Backup host name (no default):
Enter: Localhost
Backup directory (no default):
Enter: /External/backup_vertica/
8-16
Change advanced settings? (n) [y/n]:
Config file name:
Name your INI file.
The INI file is created, and the following message appears:

Saved vbr configuration to [INI FILE].
Where [INI FILE] is the name of your INI file as you just named it
5. Initialize the host server/directory by running the following command:
/opt/vertica/bin/vbr.py --config-file [INI FILE].ini -
-task init
6. Run the VBR backup command with the INI file that you just created:
-task backup
7. When asked, enter the Vertica password.

8. Verify that the backup is completed and that there are files in
/External/backup_vertica/, and then copy the INI file into that directory.
Backing Up Vertica to a Remote Server

This procedure describes how to back up Vertica to a remote server. As a prerequisite,
you must prepare the remote server as described HERE. The procedure for restoring
Vertica from a remote server is HERE.
To back up Vertica to a remote server:
following command:
su - dbadmin
2. Stop the ETL process, as follows:
a. To stop, run the following script:
cs_admin stop
b. Wait until the system is down, and then verify that the system is down with
the following command:
cs_admin status
8-17
3. Run the VBR Python script utility to configure the backup, by doing one of the
following:
⧫ If you are currently in ClearSee 15.1 or below, then run the following
command:
/opt/vertica/bin/vbr.py –setupconfig
⧫ If you are currently in ClearSee 16.1 or above, then run the following
command:
/opt/vertica/bin/vbr.py –c
4. Create the backup’s INI file by completing the following wizard:
Snapshot name (backup_snapshot):
Destination Vertica DB bin directory (only required for object replication)
(/opt/vertica/bin):
Number of restore points (1):
Specify objects (no default):
Object restore mode (coexist, createOrReplace or create) (createOrReplace):
Enter: create
Vertica user name (dbadmin):
Save password to avoid runtime prompt? (n) [y/n]:
Enter: n
Backup host name (no default):
Enter the remote server’s IP.
Backup directory (no default):
Enter: /home/dbadmin/backup_vertica/
8-18
Change advanced settings? (n) [y/n]:
Config file name:
Name your INI file.
The INI file is created, and the following message appears:

Saved vbr configuration to [INI FILE].
Where [INI FILE] is the name of your INI file as you just named it
5. Initialize the host server/directory by running the following command:
-task init
6. Run the VBR backup command with the INI file that you just created:
-task backup
7. When asked, enter the Vertica password.

8. Verify on the remote server that the backup is completed and that there are files
in /home/dbadmin/backup_vertica/, and then copy the INI file from ClearSee to
the remote server.
Restoring Vertica from an External Device

This procedure describes how to restore Vertica after BACKUP TO AN EXTERNAL DEVICE.
To restore Vertica from an external device:
following command:
su - dbadmin
2. Enter the vsql CLI by doing the following:
vsql
b. Enter the dbadmin password.
3. Run the following command:
ALTER SCHEMA prod rename to prod_new;
4. Verify there is no “prod” schema by running the following command:
\dn
5. Press CTRL+D to exit the vsql CLI.
6. Stop the database, as described in STOPPING THE DW DATABASE.
8. Run the VBR restore command using your [INI FILE], as follows:
8-19
/opt/vertica/bin/vbr.py --config-file
/External/backup_vertica/[INI FILE].ini --task init
/External/backup_vertica/[INI FILE].ini --task restore
Vertica is restored to the backed-up version.
9. Verify that the restore has completed, and then start the database, as described
STARTING THE DW DATABASE.
10. Switch users to root by running the following command:
su –
11. Perform an upgrade of the schema, as follows:
/opt/allot/clearsee/install/upgrade/lib/upgrade_vert.py
NOTE You may see errors saying that the column/table already exists. This
is OK.
12. Unmount the USB and then remove it, as follows:
umount /External
rm -rf /External
Restoring Vertica from a Remote Server

This procedure describes how to restore Vertica after BACKUP TO A REMOTE SERVER.
To restore Vertica from a remote server:
following command:
su - dbadmin
2. Enter the vsql CLI by doing the following:
vsql
b. Enter the dbadmin password.
ALTER SCHEMA prod rename to prod_new;
4. Verify there is no “prod” schema by running the following command:
\dn
5. Press CTRL+D to exit the vsql CLI.
6. Stop the database, as described in STOPPING THE DW DATABASE.
7. Verify you are the dbadmin user by running the following command:
ssh-copy-id dbadmin@[DEVICE IP]
Where [DEVICE IP] is the IP of the remote storage device
8-20
8. Copy from remote INI file that you created in BACKING UP THE DW to
/home/dbadmin.
9. Run the VBR restore command using your [INI FILE], as follows:
/home/dbadmin/[INI FILE].ini --task init
/home/dbadmin/[INI FILE].ini --task restore
Vertica is restored to the backed-up version.
10. Verify that the restore has completed, and then start the database, as described
STARTING THE DW DATABASE.
11. Switch users to root by running the following command:
su –
12. Perform an upgrade of the schema, as follows:
/opt/allot/clearsee/install/upgrade/lib/upgrade_vert.py
NOTE You may see errors saying that the column/table already exists. This
is OK.
8.3 ClearSee Alerts

ClearSee supports two main methods of alerts:
• CLEARSEE LOGS
• CLEARSEE SNMP TRAPS
ClearSee Logs
The following detailed ClearSee logs are available:
• ETL LOGS
• INSTALLATION AND UPGRADE LOGS
• VERTICA LOG
• POSTGRESQL LOG
• SYSTEM LOG
You can configure the severity of the alarms, as described in CHANGING THE ETL ERROR
SEVERITY LEVEL, as well as have the alarms sent to the syslog daemon.
Changing the ETL Error Severity Level

This procedure describes how to change the minimum ETL severity level for log entries to
appear.
8-21
To change the ETL severity log level:
1. Open for editing the $ETL_HOME/cfg/connection.ini file, to the [logger] section.
[logger]
; Each handler log level setting defines the
; minimum value for that handler to log with.
; NOTSET implies lowest logging priority.
; Case insensitive.
; Each handler requires a level.
; SQL logs is the level at which queries are logged.
; Disabled implies handler will ignore all logs.
; Accepted values:
;
; CRITICAL
; ERROR
; WARNING
; INFO
; DEBUG
; NOTSET
;
; DISABLED
;
log_debug_level = info
repository_debug_level = warning
syslog_debug_level = disabled
sql_logs = NOTSET
2. Change the minimum severity log levels as required. Whatever level you select
for a log, that level and above will appear in the log.
ETL Logs
These Proprietary ETL (Extract Transform Load) logs are stored in the central repository
DB. These alarms alert for errors and problems related to the data loading procedures,
and they are located as follows:
• /opt/allot/clearsee/etl/logs: Containing info level logs including alerts, errors,
critical information for debugging ETL issues
• Error_log Table: From the postgres database, containing warning level logs of ETL
operation warnings and errors, and accessible via CLI, as described in DISPLAYING
ALERTS
Installation and Upgrade Logs

You can view the following installation and upgrade logs:
• /var/log/allot/clearsee_install.log
• /var/log/clearsee_upgrade.log
• /opt/allot/clearsee/install/log/
• /opt/allot/clearsee/install/upgrade/log/
8-22
Vertica Log
You can find the Vertica log in the following location:
/vertica_catalog/clearseedwh/v_clearseedwh_node0001_catalog/vertica.log
NOTE The system also generates the standard OS MIB2 Alerts, as
described in VERTICA TRAPS .
PostgreSQL Log
The postgres log contains alerts related to postgres events such as connection errors, SQL
errors, internal database errors, exceeded size-limit errors and memory related errors.
You can find the postgres log in the following location:
/var/lib/pgsql/9.2/data/pg_log/
System Log
The system log (syslog) contains a superset of all system-level logs including ETL and DW
logs, as well as additional events not related to ETL, DW or even to ClearSee. As the
system log is disabled by default, to view these alerts you must CHANGE THE ETL SEVERITY
LEVEL.
You can find the system log in the following location:

/var/log/messages
ClearSee SNMP Traps

SNMP traps appear in NetXplorer and are very general. These are based on the Allot MIB
and the ClearSee MIB. You can configure additional SNMP trap destinations as described
HERE, as well as types. The default MIB type is v1. System MIB2 files can be found in the
/usr/share/snmp/mibs folder.
In addition to the default traps, Vertica also creates traps, as described HERE.
Vertica Traps
In addition to the default traps, Vertica also creates traps. You can find the list of Vertica
traps in this link:
https://my.vertica.com/docs/7.1.x/HTML/Content/Authoring/AdministratorsGuide/Monit
oring/Vertica/ConfiguringEventTrappingForSNMP.htm
The following example illustrates a Too Many ROS Containers event posted to SNMP:
Version: 1, type: TRAPREQUEST
Enterprise OID: .1.3.6.1.4.1.31207.2.0.1
Trap agent: 72.0.0.0
Generic trap: ENTERPRISESPECIFIC (6)
Specific trap: 0
.1.3.6.1.4.1.31207.1.1 ---> 4
.1.3.6.1.4.1.31207.1.2 ---> 0
8-23
.1.3.6.1.4.1.31207.1.3 ---> 2008-08-14 11:30:26.121292
.1.3.6.1.4.1.31207.1.4 ---> 4
.1.3.6.1.4.1.31207.1.5 ---> 1
.1.3.6.1.4.1.31207.1.6 ---> site01
.1.3.6.1.4.1.31207.1.7 ---> suse10-1
.1.3.6.1.4.1.31207.1.8 ---> Too many ROS containers exist on this node.
.1.3.6.1.4.1.31207.1.9 ---> QATESTDB
.1.3.6.1.4.1.31207.1.10 ---> Too Many ROS Containers
Figure 8-1 - Example of DW SNMP Event

NetXplorer cannot read the Vertica traps, nor are they enabled by default. To enable
these traps, see ENABLING THE VERTICA TRAPS.
Enabling the Vertica Traps

This procedure describes how to enable the Vertica traps so that the alerts can be read.
To enable the Vertica traps:
1. Connect to ClearSee, or, in a Cluster, connect to a DW.
2. Under the dbadmin user, use the following SQL command:
/opt/vertica/bin/vsql -U dbadmin -w dbadmin -c "ALTER
DATABASE clearseedwh SET SnmpTrapsEnabled = 1;"
3. As NetXplorer cannot read these traps, you must configure an additional SNMP
destination, as described in CONFIGURING ADDITIONAL SNMP TRAPS.
8.4 Intelligent Cubes Maintenance

The following section covers BI Intelligent cube maintenance and manual data updates.
Some of ClearSee reports and dashboards are based on intelligent cubes. Intelligent Cubes
are a form of data caching which allow multiple reports to be stored in the Cube. This
means that when you run a report from the Cube, its SQL has already been executed and
the results stored in the Cube. This allows receiving report’s results in an almost instant
report run time regardless of report size.
ClearSee has a monitor and refresh mechanism that does not require a user interfere.
Reports and dashboard that are built on cubes will automatically refresh every several
hours.
ClearSee also provides a user interface for manually execution of cubes. There are two
forms of refresh: Incremental and Publish.
8-24
Figure 8-21 - ClearSee intelligent cubes interface

ClearSee intelligent cubes interface contains 2 options:
• Incremental Refresh Reports: Used for update latest data into report. In order to
update the cube right click on the cube name and choose “run”.
• Publish Cubes: Used to publish the cube for the entire data set.
If you are publishing cubes it might cause a slow down for the entire system since
some of the reports/ dashboards contain huge amounts of data. This option is
not recommended and it’s used as a resort where cubes return an error message
that indicates cubes were not published.
NOTE When using a cluster setup reports might return an error which
indicates that cubes are not published if the BI cluster is
disconnected. In order to resolve this verify both BI servers are up
and running and connect both servers to the cluster.
8.5 Changing ClearSee Server Hostnames

This procedure describes how to change the hostnames of the ClearSee servers.
To change the hostnames of the ClearSee servers:
1. Have ready the following:
⧫ <NEW HOSTNAME>: The new hostname of the BI server on which you are
currently
⧫ <OLD PRIMARY BI HOSTNAME>: The current hostname of the primary BI
server, which by default is clearsee-bi-primary
⧫ <OLD SECONDARY BI HOSTNAME>: The current hostname of the primary BI
server, which by default is clearsee-bi-secondary
⧫ <OLD DW1 HOSTNAME>: The current hostname of the DW1 server, which by
default is similar to clearsee-dw-1
8-25
⧫ <NEW PRIMARY BI HOSTNAME>: The new hostname of the primary BI
server
⧫ <NEW SECONDARY BI HOSTNAME>: The new hostname of the primary BI
server
⧫ <NEW DW1 HOSTNAME>: The new hostname of the DW1 server
2. On each BI server, do the following:
/opt/MicroStrategy/home/bin/mstrctl -s
IntelligenceServer term
b. Stop the Internal HA communcation with the following command:
service pacemaker stop
c. Run the following command:
hostnamectl set-hostname <NEW HOSTNAME>
d. Run the following commands:
grep -irl <OLD PRIMARY BI HOSTNAME> /etc/ /opt/MicroStrategy/
/opt/allot/clearsee/etl/pymodules/ | xargs sed -i "s/<OLD PRIMARY BI
HOSTNAME>/$<NEW PRIMARY BI HOSTNAME>/Ig"
grep -irl <OLD SECONDARY BI HOSTNAME> /etc/ /opt/MicroStrategy/
/opt/allot/clearsee/etl/pymodules/ | xargs sed -i "s/<OLD SECONDARY BI
HOSTNAME>/$<NEW SECONDARY BI HOSTNAME>/Ig"
grep -irl <OLD DW1 HOSTNAME> /etc/ /opt/allot/clearsee/etl/pymodules/ |
xargs sed -i "s/<OLD DW1 HOSTNAME>/$<NEW DW1 HOSTNAME>/Ig"
e. Run the following commands:

crm_resource -P
service haproxy restart
a. Start the Internal HA communication with the following command:

service pacemaker start
b. Run the following command:
/opt/MicroStrategy/home/bin/mstrctl -s
IntelligenceServer start
8-26
3. On each DW server, do the following:
a. Stop the ETL service with the following command:
cs_admin stop
b. Run the following command:
hostnamectl set-hostname <NEW HOSTNAME>
c. Run the following commands:
sed -i 's/<OLD PRIMARY BI HOSTNAME>/<NEW PRIMARY BI HOSTNAME>/Ig'
/etc/hosts
sed -i 's/<OLD SECONDARY BI HOSTNAME>/<NEW SECONDARY BI HOSTNAME>/Ig'
/etc/hosts
sed -i 's/<OLD DW1 HOSTNAME>/<NEW DW1 HOSTNAME>/Ig' /etc/hosts
d. Run the following commands:

rabbitmqctl stop_app
rabbitmqctl force_reset
rm -rf /var/lib/rabbitmq/mnesia/*
killall -9 rabbitmq-server && killall -u rabbitmq
/etc/init.d/rabbitmq-server stop
/opt/allot/clearsee/etl/install/install_etl_node.py --rabbit-only
'/opt/allot/clearsee/install/install_parameters.ini'
/etc/init.d/rabbitmq-server stop
/etc/init.d/rabbitmq-server start
/etc/init.d/rabbitmq-server start
e. Start the ETL service by running the following command:

cs_admin start
8.6 Performing ETL Administration

The ETL Administration tool is used to manage the operation and administration of the
ETL process.
To access the ClearSee CLI:
1. As user dbadmin, connect to the Standalone server or, in a Cluster, to a DW
server.
2. From the CLI, type the following:
cs_admin
The ETL Administration tool menu appears.
8-27
The following commands are available:

• Start – Launches and activates all ETL modules.
• Stop – Halts the ETL Modules
• Restart – Equivalent to a "Stop" then "Start" sequence
• Status – Displays a report on ETL status
• Queues – Displays CPU and queued file status
• Deploy – Deploys new configuration files to all nodes
• Errors – Display all ClearSee Errors
• Exit – Simply exits the ./admin.py CLI launch application
8-28
Figure 8-3 - cs_admin CLI screen
8-29
Start, Stop and Restart
Start, Stop and Restart are self-explanatory: they are basic commands for launching,
halting and restarting the ETL process.
ETL Status
The ClearSee ETL Status CLI function displays the status of the DW Db status, and the
status of the ETL functions loading data into it.
Database Status Column:
• If the connection to the DW DB is operational and there are no error reports, the
status will display as OK.
• If there are error reports, the status will display as "alert" and the events will be
printed to screen.
• If there is no connection to the DB, the status will show as "failed".
ETL Status Column:
• If all modules are up and running, the status displayed is "OK".
• If one or more ETL modules have malfunctioned or are not running, the status
displayed is "alert" and all module statuses will be printed to the screen.
• If communication with the ETL watchdog fails, all modules will display as "failed".
8-30
Figure 8-4 - ClearSee CLI Setup Screen – ETL Status
Queues
After selecting "Queues", the CLI interface displays the status of the Data Warehouse and
the ETL processes on the node.
• CPU average load during
• the past minute
• the past 5 minutes
• amount of data waiting to be pulled
• data loaded during the past 5 minutes
• amount of data waiting in the queue to be loaded
8-31
Figure 8-5 - ClearSee CLI Command Screen – Queues
Deploy
Deploys all .ini configuration files to the cluster. The .ini configuration files are located in
the directory:
$ETL_HOME/cfg/connection.ini
Figure 8-6 - ClearSee CLI Command Screen – deploying changes
Displaying Alerts
This CLI option allows the display of all ClearSee errors encountered.
The user can select how far back to print. The default value is a week.
8-32
Figure 8-7 - Displaying Error Alerts from the CLI
8-33
Figure 8-8 - Alerts Output from the CLI
8-34
8.7 Performing Patch Management

The Patch Manager is used to manage ClearSee version patches.
1. Connect via an SSH client to the ClearSee server as user admin. For a cluster,
connect to the active primary BI server.
2. Change user to root.
3. With user root, launch the Patch manager CLI by typing:
/usr/local/bin/cs_patches
The following commands are available:

⧫ Status: Display a list of all imported patches along with their installation
status.
⧫ Import: This command gets a path as an argument and imports all the
patches in the path to the patches manager.
⧫ Install: This command gets a patch name as an argument (the exact name as
it shown in the Status command) and installs it.
⧫ IMPSTALL: This command combines import the package and force installs all.
Status
This option allows viewing all existing ClearSee patches and their states:
• If a patch is installed it will appear as “Installed “and will be colored in Green. An
Uninstalled patch will appear as “Not installed” and will be colored in Red.
Figure 37 - cs_patches-Status CLI screen
8-35
Import
This option allows importing patches that were located in a specific path. This command
gets a path as an argument and imports all the patches in the path to the patches
manager
Figure 38 - cs_patches-Import CLI screen
Install
This option allows installing patches that were imported to the Patch manager. This
command gets a patch name as an argument (the exact name as it shown in the status
command) and installs it. It is possible to provide a list of patches separated by a space.
There are two kinds of patches: reversible and irreversible. Irreversible patches can’t be
uninstalled
When trying to install such a patch, the system will inform you that the patch is
irreversible, and ask for your permission to proceed with installation.
Figure 39 - cs_patches-install irreversible patch CLI screen
8-36
Figure 40 - cs_patches-install reversible patch CLI screen
Import and Install

This command imports and installs all patches.
Figure 8-9: cs_patches-IMPSTALL patch CLI screen
8-37
9 Security and Access Management
9.1 Accessing ClearSee
This procedure describes how to access ClearSee.
To access ClearSee:
• Enter the URL as follows:
http://[IP]:8080/ClearSee/servlet/mstrWeb
Where [IP] is the IP of your ClearSee.
NOTE You can also access ClearSee by HTTPS, as described HERE, as well
as change the ClearSee Web ports, as described HERE.
9.2 Security
The Allot ClearSee user interface has a robust security model, which provides controls
over what data the users can see, what objects they can use, and what functional
privileges they have.
Database Security
The ClearSee database component is secured using a number of access control,
communication and database security functions:
• User access controls: User access to the database is password-protected using a
proprietary password authentication scheme.
• Internal data communication (when deployed in a Cluster deployment)
⧫ Communication between database nodes is sent in a compressed database
internal communication format.
⧫ Communication between the BI and the database servers is password
protected.
• Database security
⧫ Access to the database is password protected.
⧫ The database supports client authentication, which prevents unauthorized
access to the database. By default, only the ClearSee BI can access the
database. Additional users and authentication methods can be added as
needed.

Security and Access Management
⧫ By configuration, the database and its clients can use SSL to communicate, as
described here. Connection encryption prevents the interception of data, as
well as authenticating the identity of the server and the client.
Accessing ClearSee by HTTPS

By configuration, you can connect to ClearSee by secured HTTP (HTTPS) by entering the
URL as follows:
https://[IP]:8443/ClearSee/servlet/mstrWeb
Where [IP] is the IP of your ClearSee.
NOTE You can also change the ClearSee Web ports, as described for
STANDALONE and for CLUSTER . You can also disable HTTP, as
described for STANDALONE and for CLUSTER.
Disabling HTTP in a Standalone Deployment

This section explains how to disable HTTP in a Standalone deployment, which is important
if you want to reach ClearSee only by way of HTTPS.
1. Connect to the server using user admin, and then change to root.
2. Run the command:
vim /opt/tomcat/conf/server.xml
3. Move the comment markup --> from before <Connector port="8080" to before
<Connector port="8443", as follows:
Before:
-->
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
<Connector port="8443"
protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true" scheme="https"
secure="true"
keystoreFile="/cert/mykeystore.jks" keystorePass="password"
clientAuth="false" sslProtocol="TLS" />
After:
-->
secure="true"
9-2
4. Save the file, and then run the command:
systemctl restart tomcat.service
Disabling HTTP in a Cluster Deployment

This section explains how to disable HTTP in a Standalone deployment, which is important
if you want to reach ClearSee only by way of HTTPS.
1. Do the following on each BI server:
a. Connect to the server using user admin, and then change to root.
b. Run the command:
c. Move the comment markup --> from before <Connector port="8080" to
before <Connector port="8443", as follows:
Before:
-->
secure="true"
After:
-->
secure="true"
d. Save the file.

2. On the Primary BI, run the command:
pcs resource restart Tomcat
Changing Web Ports in a Standalone Deployment

This section explains how to change the port used by the ClearSee Webserver for web
client connections, in a Standalone deployment.
To change the port:
9-3
3. Connect to the server using user admin, and then change to root.
4. Run the command:
5. To change the port for HTTP access, change the following:
To:
<Connector port="[PORT]" protocol="HTTP/1.1"
Where [PORT] is the new port

6. To change the HTTPS port, change the following:
secure="true"
To:

redirectPort="[PORT]" />
<Connector port="[PORT]"
secure="true"

7. Save the file, and then run the command:
systemctl restart tomcat.service
Changing Web Ports in a Cluster Deployment

This section explains how to change the port used by the ClearSee Webserver for web
client connections, in a Cluster deployment.
To change the port:
1. Do the following on each BI server:
a. Connect to the BI server using user admin, and then change to root.
b. Run the command:
9-4
c. To change the port for HTTP access, change the following:
To:
<Connector port="[PORT]" protocol="HTTP/1.1"

d. To change the HTTPS port, change the following:
secure="true"
To:

redirectPort="[PORT]" />
<Connector port="[PORT]"
secure="true"

e. Save the file.
2. On the Primary BI, run the command:
pcs resource restart Tomcat
Changing Passwords
The following procedures describe how to change ClearSee passwords from the DEFAULT.
After installation, Allot recommends that you change the DW password from the default,
as follows:
• To change the Allot admin password, see CHANGING THE ALLOT ADMIN PASSWORD .
• To change the DW password in a Standalone deployment, do the following:
⧫ CHANGING THE VERTICA DB PASSWORD (STANDALONE)
⧫ CHANGING THE DW USER PASSWORD (STANDALONE )
9-5
• To change the DW password in a Cluster deployment, do the following:
⧫ CHANGING THE VERTICA DB PASSWORD (CLUSTER)
⧫ CHANGING THE DW USER PASSWORD (CLUSTER)
To change the system root password, see CHANGING THE SYSTEM ROOT PASSWORD .
Default Passwords
The following are the default passwords:
• Allot admin: allot
• System root user: bugaboo
• DW:
⧫ Vertica DB: dbadmin
⧫ DW user (dbadmin): dbadmin
Changing the Allot Admin Password

This procedure describes how to change the Allot admin password.
To change the Allot admin password:
• Refer to the specific hardware guide of the In-line platform you are using, and
change it accordingly on every device.
Changing the Vertica DB Password (Standalone)

This procedure describes how to change the Vertica DB password, in a Standalone
deployment, to enable you to enter the DW’s SQL database. This is important if you did
not change it during installation or if you want to change it any time after installation.
NOTE The Vertica DB password and the DW user password should be
identical.
To change the Vertica DB password in a Standalone installation:
1. Log in to the DW with the current DW password, and then do the following:
a. Run the following:
/opt/vertica/bin/vsql
b. At the prompt, enter the current DW password.
alter user dbadmin identified by ‘<PASSWORD>’
Where <PASSWORD> is the new password
b. Run \q to exit.
3. Change the password in the ODBC file, as follows:
9-6
vim /etc/odbc.ini
The contents of the file appear.
b. Type the letter i to enter edit mode.
c. Change the password in the following sections:
▪ [data_browse]
▪ [central_repository]
d. Press ESC to exit edit mode, and then type :wq to save the changes.
4. Change the password in the Connection file, as follows:
vim /opt/allot/clearsee/etl/cfg/connection.ini
c. Change the password in the [vertica] section.
Changing the Vertica DB Password (Cluster)

This procedure describes how to change the Vertica DB password, in a Cluster
deployment, to enable you to enter the DW’s SQL database. This is important if you did
not change it during installation or if you want to change it any time after installation.
identical.
To change the Vertica DB password in a Cluster installation:
1. Log in to one of the DWs with the current DW password, and then do the
following:
a. Run the following:
/opt/vertica/bin/vsql
b. At the prompt, enter the current DW password.
alter user dbadmin identified by ‘<PASSWORD>’
Where <PASSWORD> is the new password
b. Run \q to exit.
3. Change the password in the ODBC file, as follows:
9-7
vim /etc/odbc.ini
c. Change the password in the following sections:
▪ [data_browse]
▪ [central_repository]
4. Change the password in the Connection file, as follows:
vim /opt/allot/clearsee/etl/cfg/connection.ini
c. Change the password in the [vertica] section.
5. Run the command cs_admin.
6. Type deploy.
7. At the prompt, type Y.
8. For each DB server in the cluster, do the following:
cat /opt/allot/clearsee/etl/cfg/connection.ini
b. Change the password in the section [vertica].
c. Type :wq to save the changes.
Changing the DW User Password (Standalone)

This procedure describes how to change the DW user password, otherwise known as the
dbadmin password, in a Standalone deployment.
identical.
To change the DW user password in a Standalone deployment:
1. Log in to one of the DWs with the current DW password, and then enter the
following command:
passwd
2. Enter your old password, and then enter your new password.
NOTE The password may not contain the $ (dollar sign) symbol.
9-8
Changing the DW User Password (Cluster)
This procedure describes how to change the DW user password, otherwise known as the
dbadmin password, in a Cluster deployment. This procedure must be performed on each
DW.
identical.
To change the DW user password in a Cluster deployment, on each DW:
1. Log in to the DW with the current DW password, and then enter the following
command:
passwd
Changing the System Root Password

This procedure describes how to change the system root password, which is
recommended for security purposes.
To change a system root password:
1. Log in to the server as admin and then change to root, and then enter the
following command:
passwd
Securing Data in Motion between ClearSee and

NetworkSecure
In ClearSee’s Vertica, you must secure the data in motion between ClearSee and
NetworkSecure.
To configure ClearSee’s Vertica to encrypt Data in Motion:
⧫ If your ClearSee is Standalone, then connect to Vertica with user admin.
⧫ If your ClearSee is a Cluster, then connect to one of the DWs with user
admin.
4. Switch the user to root using the sh - command.
5. Switch the user to dbadmin:
su - dbadmin
6. Run the following commands:
9-9
echo "select set_config_parameter ('SSLCertificate','$(cat
/cert/selfsigned.crt)');" | vsql
echo "select set_config_parameter ('SSLPrivateKey','$(cat
/cert/server.key)');" | vsql
echo "ALTER DATABASE clearseedwh SET EnableSSL = 1;" | vsql
5. Stop the system with the following command:
cs_admin stop
7. Wait until the system is down, and then verify that the system is down with the
following command:
cs_admin status
8. Restart Vertica using the Vertica menu, as follows:

a. Open the Vertica menu with the following command:
Admintools
b. Select 4 Stop Database, and then press OK.
9-10
c. Press the space bar to select the database, and then press OK.
Enter the dbadmin password, and then press OK.
d. Wait until the database is down, and then press OK.
9-11
e. Start the database.
f. Press the space bar to select the database, and then press OK.
g. Exit the Vertica menu.
9. Verify that the parameter are configured, and then run the following command:
vsql -x -c "select parameter_name, current_value,
default_value from vs_configuration_parameters where
parameter_name in ('EnableSSL', 'SSLCertificate',
'SSLPrivateKey', 'SSLCA');"
10. Enter the dbadmin password.
11. Verify that you see the following:
⧫ The value of EnableSSL is 1.
⧫ The SSL certificate fields contain content.
9-12
9.3 Access Management

Allot recognizes that your reports contain sensitive information, and while it may be
appropriate for some groups in your enterprise to access that information, it may be a
security breach for others.
Access to ClearSee is governed by a powerful security sub-system that enables
administrators to grant access to the ClearSee domains and tools based on user
permissions.
Access Privileges
The administrator grants a user access to the ClearSee domains as well as other tools.
There are two access levels:
9-13
• Granted: The user has access to the reports in the domain or to the tool, and
may perform actions such as drilling down where relevant.
• Denied: The user is denied access to the domain or tool. The user may see the
domain or report in the Reports menu, but clicking it returns a blocked message.
The administrator is Web_Admin in the main client and admin/admin for the User
Manager. The administrator has access to everything.
The groups are predefined, with access levels for the groups as follows:
Access Marketing Management Operator Administrator

Network V V V V
Experience V V X V
Device V V X V
Subscriber V V X V
Create Report V X V V
Real-Time V V V V
Administration X X X V
Access Management Process

Access to information and ClearSee objects is based on the groups to which the users are
assigned.
Users do not partake in ClearSee access privileges on an individual basis. This is for
security purposes, to ensure that users do not fall through the cracks and receive too
many or too few privileges. Rather, users are added to groups or subgroups based on
types of use, and these are granted access to the domains or tools.
ClearSee access management is therefore a three-step process:
1. Creating users, as described in CREATING A USER ACCOUNT.
2. Creating subgroups based on groups with predefined access levels, as described
in CREATING A SUBGROUP.
3. Assigning the users to the groups or subgroups, as described in one of the
following:
⧫ ADDING THE USER TO A GROUP: For one user
⧫ ADDING USERS TO A GROUP OR SUBGROUP : For many users
9-14
Accessing the User Manager
The User Manager is used for all access management procedures, such as creating users
and groups, and assigning users to groups.
Prerequisites
At least one administrator must have the necessary privileges to access the User
Manager.
1. From your browser, access the Administrator site at:
<CLEARSEE IP>:8080/ClearSee/servlet/mstrWebAdmin
2. Sign in as the admin:
⧫ Username: admin
⧫ Password: admin
On the Servers page, in the row of your ClearSee server, hover your mouse in the
Properties column.
The Modify and Administration Portal icons appear.
3. Click the Administration Portal icon.

The ClearSee home login page appears.
9-15
4. Enter the following first-time login credentials:

⧫ Username: Web_Admin
⧫ Password: Web_Admin
NOTE At a later event, you must change your password from the default,
as described in MODIFYING A USER ACCOUNT.
5. Click Login.
The Administration Portal appears.
6. Select User Manager.

The User Manager opens and displays a list of the user groups on the Allot
ClearSee Server.
9-16
User Management
In order for someone to access ClearSee reports and dashboards, you must first give that
person a user account.
All users except for guest users are automatically members of the Everyone group. The
Everyone group is on the public/guest security level, and has privileges only to browse and
read reports.
Creating a User Account

Each user represents a person who uses the Allot ClearSee system, and who is provided
with access to some (or none) of the ClearSee capabilities.
To work with ClearSee, a user must have a user account created for them by an
administrator. This user account defines what access privileges they have, their login ID
and password, and the password time-out policy.
To create a user:
1. Open the User Manager, as described in ACCESSING THE USER MANAGER.
2. On the toolbar, click the New User icon .
The User Editor opens.
9-17
Figure 9-1: User Editor (General Tab)

3. On the General tab, enter the relevant information:
⧫ Log in and full name of the user. You may include a description.
NOTE The length of the login ID is limited to 50 characters.
⧫ Enter a password.
⧫ Indicate whether the user can change the password on their own, and
whether they must change the password at their next logon.
⧫ Set the password expiration criteria.
⧫ Ensure that the Account Disabled checkbox is not checked.
⧫ To add the user to a group now, as described in ADDING THE USER TO A GROUP .
⧫ When dealing with GROUP MANAGEMENT, add the user among others to a
group or groups, as described in ADDING USERS TO A GROUP OR SUBGROUP.
NOTE Privileges are not assigned on an individual basis. If you do not
assign the user to a group, then the user remains in the Everyone
group with only browse and read privileges.
5. On the Addresses tab, associate a user with an email address, and optionally to a
directory or printer, for subscriptions and document delivery, as described in
PROVIDING THE USER’S DELIVERY INFORMATION .
6. Click OK to save the user and return to User Manager.
The user is added to the Everyone group.
Modifying a User Account

1. Open the User Manager, as described in ADDING THE USER TO A GROUP.
2. Click the group containing the user account.
The group opens.
9-18
OR
If you don’t know which group contains the user account, click the Everyone
group, which contains all users.
3. In the row of the user that you want to modify, in the Actions column, hover
your mouse so that the Edit icon appears, and then click the icon.
4. Modify any account criteria as needed by continuing in CREATING A USER ACCOUNT,
from step 3 onward.
5. Click OK to save the changes.
Adding the User to a Group

You can add the user to a group while creating the user account, as described here from
the User Editor, or later during GROUP MANAGEMENT. The latter is ideal if you want to add
a number of users to a group at a time.
This procedure is part of CREATING A USER ACCOUNT or MODIFYING A USER ACCOUNT, and
takes place on the Groups tab of the User Editor.
Figure 9-2: User Editor (Groups Tab)

To add the user to a group during user account creation:
• On the Groups tab, in the Available area, do one of the following:
⧫ Select the group to which you want to add the user, and then click the right
arrow.
The group appears in the Selected area.
⧫ Select the subgroup to which you want to add the user, and then click the
right-facing arrow.
The subgroup appears in the Selected area.
9-19
The user now belongs to the selected group or subgroup, and inherits all its
access permissions.
NOTE Do not add the user to more than one group.
Providing the User’s Delivery Information

Providing delivery information for a user is important if you want to set up subscriptions,
or if you want a simple means to send a user a finished report. The report can be sent to
the user’s email address, personal directory on a server, or printer.
takes place on the Addresses tab of the User Editor.
Figure 9-3: User Editor (Addresses Tab)

To provide the user’s delivery information, do any of the following:
• Email: On the Addresses tab, in the E-mail Addresses area, do the following:
a. Click Add a New Address.
Fields appear for you to enter an email address.
9-20
Figure 9-4: Email Address Fields

b. Complete the following fields:
▪ Address Name: The name of the email account
▪ Physical Address: The email address
▪ Device: The type of email account
c. Click Save.
The email address is saved.
Figure 9-5: Saved Email Address

• File Locations: On the Addresses tab, in the File Locations area, do the following:
a. Click Add a New File Location.
Fields appear for you to enter a file location.
Figure 9-6: File Location Fields

▪ Address Name: The name of the folder
▪ Physical Address: The address of the folder
▪ Device: The device on which the folder resides
c. Click Save.
The file location is saved.
9-21
Figure 9-7: Saved File Location

• Printer Locations: On the Addresses tab, in the File Locations area, do the
following:
a. Click Add a New Folder Printer.
Fields appear for you to enter a printer.
Figure 9-8: Printer Location Fields

▪ Address Name: The name of the printer
▪ Physical Address: The address of the folder
▪ Device: The device on which the folder resides
c. Click Save.
The printer location is saved.
Figure 9-9: Saved Printer Location

See also:
• MANAGING USER DELIVERY INFORMATION
9-22
Managing User Delivery Information
After PROVIDING A USER ’S DELIVERY INFORMATION, you can perform the following
management tasks:
• To edit an address or location, in its row click Edit, and then edit the fields.
• To delete an address or location, in its row click Delete.
Providing the User’s Contact Information

takes place on the Contacts tab of the User Editor.
Enabling/Disabling a User Account

The group opens.
OR
3. In the row of the user that you want to modify, in the Actions column, hover
your mouse so that the Edit icon appears, and then click the icon.
4. On the General tab, select or clear the Account Disabled check box.
Deleting a User Account

The group opens.
OR
3. In the row of the user you want to delete, in the Actions column, click the Delete
icon .
The user is deleted.
9-23
Group Management
Instead of assigning access privileges to many users individually, you rather create groups
and assign appropriate privileges to each group.
Denying is important in order to create an exception within a group.
Creating a Subgroup
Create a subgroup in order to change access to domains or tools for some of the users of
a group.
2. On the toolbar, click the New Group icon .
The Group Editor opens.
Figure 9-10: Group Editor (General Tab)

3. On the General tab, type a name and description for the subgroup.
4. On the Groups tab, select the group to which the subgroup belongs, as described
in ADDING THE SUBGROUP TO A GROUP.
5. On the Members tab, to add users to the subgroup or remove them, see ADDING
USERS TO A GROUP OR SUBGROUP.
6. Click OK to save the new group and return to the User Manager.
Modifying a Group or Subgroup

You can change the name and description of a subgroup, the group that the subgroup
belongs to, and the members of the group or subgroup.
1. Open the User Manager, as described in ACCESSING THE USER MANAGER, and then,
for a subgroup, browse to the subgroup.
9-24
2. In the row of the group or subgroup you want to modify, in the Actions column,
hover your mouse so that the Edit icon appears, and then click the icon.
The Group editor opens.
3. On the General tab, as needed, edit the name and description for the group.
NOTE To advance to the next tab, the group must have a name.
4. On the Groups tab, as needed, change the group to which the subgroup belongs,
as described in ADDING THE SUBGROUP TO A GROUP.
5. On the Members tab, as needed, change the users in the group or subgroup, as
described in ADDING USERS TO A GROUP OR SUBGROUP .
Adding the Subgroup to a Group

You can select the group from which a subgroup draws access privileges. A subgroup can
only be part of one group.
This procedure is part of CREATING A SUBGROUP or MODIFYING A GROUP OR SUBGROUP, and
takes place on the Groups tab of the Group Editor.
To add the subgroup to a group:
1. On the Groups tab, in the Available area, select the group to which you want the
subgroup, and then click the right-facing arrow.
The group appears in the Selected area.
Figure 9-11: Group Editor (Groups Tab)

The subgroup now belongs to the selected group, and inherits all its access
permissions.
NOTES
o Do not add the subgroup to more than one group.
9-25
o To remove the subgroup from the group, select the group from the Selected list,
and click the left-facing arrow.
o Do not assign any of the MicroStrategy Groups to a subgroup. The MicroStrategy
license allows only one administrator (Web_Admin), which is configured
automatically during system installation.
Adding Users to a Group or Subgroup

You can add users to a group or subgroup. This is the preferred way of portioning out
users to groups, as you can add more than one user at a time.
This procedure is part of CREATING A SUBGROUP or MODIFYING A GROUP OR SUBGROUP, and
takes place on the Groups tab of the Group Editor.
• On the Members tab, in the Available list, expand the Everyone group, and then
click the right-facing arrow.
The user appears in the Selected list.
Figure 9-12: Group Editor (Members Tab)

The users now belongs to the selected group, and inherits all its access
permissions.
NOTE To remove a user or a group from the group, select it from the
Selected list, and click the left-facing arrow.
Deleting a Subgroup
You can delete a subgroup that you no longer need. If users are assigned to the group, the
users remain in the Everyone group and any other group to which they may also be
assigned.
1. Open the User Manager, as described in ACCESSING THE USER MANAGER, and then
browse to the subgroup.
2. In the row of the subgroup you want to delete, in the Actions column, click the
Delete icon .
The user is deleted.
9-26
ClearSee Startup and Shutdown
10 ClearSee Startup and Shutdown

This chapter describes how to start your ClearSee system up and shut it down in an
orderly fashion. Failure to follow these procedures can cause serious problems to the
integrity of your system.
The procedures include powering the system components up and down.
10.1 Starting Up Your Standalone System

This procedure describes how to start up your Standalone ClearSee system.
To start up your Standalone system:
• Power on the server.
It takes up to 30 minutes for all ETL processes to start.
10.2 Powering Off Your Standalone System

This procedure describes how to shut down and then power off your Standalone ClearSee
system.
To power off your Standalone system:
1. Log in to the server via SSH, as the user admin, and then change to root.
2. Run the following:
/etc/init.d/clearsee_supervisor stop
3. Change users to dbadmin:
su dbadmin
/usr/local/bin/cs_admin stop
5. Shut down the DW database, as described in STOPPING THE DW DATABASE.
6. Shut down the postGreSQL database by running the following:
systemctl stop postgresql.service
7. Power off the system server.
10.3 Starting Up Your Cluster System

This procedure describes how to power on and then start up your Cluster system.
To start up your Cluster system:
1. Power on the DW servers, and wait for them to complete the powering-up
process.
10-27
2. From any of the DW servers, start the DW database, as described in STARTING THE
DW DATABASE.
a. Power on the Primary BI server.
b. Power on the Secondary BI server.
It takes up to 30 minutes for all ETL processes on all DW nodes to start.
10.4 Powering Off Your Cluster System

This procedure describes how to shut down and then power off your Cluster ClearSee
system.
To power off your Cluster system:
1. Shut down the Secondary BI server, and then the Primary BI server, as described
in SHUTTING DOWN THE BI SERVERS.
2. Power off the BI servers.
3. For each DW server, via SSH, log in as the admin user and then change to root.
5. From any of the DW servers, shut down the DW database, as described in
STOPPING THE DW DATABASE.
6. For each DW server, as the root user, run the following command:
shutdown now
The DW shuts down.
10.5 Shutting Down a BI Server

This procedure describes how to shut down a BI server, which is important in POWERING
OFF YOUR CLUSTER SYSTEM.
To shut down a BI servers:
1. Via SSH and as the admin user, change to root.
2. Log in to the BI server, and then run the following:
systemctl stop pacemaker.service
The internal HA communication stops on the BI server.
shutdown now
The BI server shuts down.
10-28
10.6 Shutting Down a DW Server

This procedure describes how to shut down a DW server.
To shut down a DW server:
4. Via SSH, log in as the admin user and then change to root.
6. Shut down the DW database, as described in STOPPING THE DW DATABASE.
7. As the root user, run the following command:
shutdown now
The DW shuts down.
10.7 Stopping the DW Database

This procedure describes how to stop the DW database for Standalone and the DW cluster
database for a Cluster system, which is important in the following:
• POWERING OFF YOUR CLUSTER SYSTEM
• UPGRADING THE STANDALONE SYSTEM
• SETTING THE TIME ZONE
• Upgrading the Cluster ClearSee system, the UPGRADING THE OPERATING SYSTEMS
(CLUSTER) step
To stop the DW database or cluster database:
1. If you are not already dbadmin, change users to dbadmin:
su dbadmin
2. Open the Vertica menu by running the following:
/opt/vertica/bin/admintools
10-29
Figure 10-1: Vertica Menu

NOTE The Vertica menu is mouse-sensitive.
3. Select 4 Stop Database, and then click OK.
The Database Selection dialog box appears.
Figure 10-2: Stop Database Selection Dialog Box

4. With the SPACE key, select the database (X), and then click OK.
NOTES
• If requested, the password is dbadmin.
• If you receive the following dialog box, just click Proceed.
10-30
The DW database shuts down.
Figure 10-3: Database Stopped Successfully

5. Click OK, and then Cancel to exit the Vertica menu.
10.8 Starting the DW Database

This procedure describes how to start the DW database for Standalone and the DW
cluster database for a Cluster system, which is important in STARTING UP YOUR CLUSTER
SYSTEM.
To start up your Cluster system:
1. Start up the DW by doing the following:
a. Log in to one of the DW servers via SSH as the admin user .
b. Change users to dbadmin:
su dbadmin
c. Open the Vertica menu by running:
/opt/vertica/bin/admintools
10-31
Figure 10-4: Vertica Menu

NOTE The Vertica menu is mouse-sensitive.
d. Select 3 Start Database, and then click OK.
The Database Selection dialog box appears.
Figure 10-5: Start Database Selection Dialog Box

e. With the SPACE key, Select the database (X), and then click OK.
NOTE If requested, the password is dbadmin.
The DW starts up.
10-32
Figure 10-6: Database Started Successfully

f. Click OK, and then Cancel to exit the Vertica menu.
10-33
11 Appendices
11.1 Appendix 1: External Data Source File Structures
External Source: Autonomous System
File Properties
File Name Convention YANA.csv
File Compression Method None
File Type CSV (Unicode)

File
File Owner (Point of Contact) End Customer
File Transfer Method Push
File Location "External Data" folder in Vertica server
A Presentation of a common, clearly defined routing

Description
policy to an Internet segment.
Data Sample "LVLT-1" => "Level 3 Communications, Inc."
this data structure will be used as data source for the

Integration
'Autonomous System' dimension
Every single row represent a single autonomous system

Data Granularity
value
Formatting Issues No
Encoding / Obfuscation
No
Issues
First Row Headers? Yes
Filters No
Source System YANA Web Site

Source
Source Path http://bgp.potaroo.net/cidr/autnums.html
Fields Structure
Field Name Description Type Max Length Key?
as_code autonomous system code varchar 10 Y
autonomous system
as_description varchar 255
description

Appendices
External Source: Devices
Properties
File Name Convention devices.csv

File
Description List of devices codes
Data Sample "10000001" => "iPhone"

Integration
'Devices' dimension
Granularity Every single row represent a single device information
Data
No
Issues
Data Overlapping Over Files

Yes
sequence?
Filters No
Source System to be supplied by customer

Source
Source Path TBD
Fields Structure
TAC Type Allocation Code varchar 255 Y
Model Model name varchar 255
Name of device
Vendor varchar 255
manufacturer
Family Model family name varchar 255
Category Category of the device varchar 255
OS Operating system varchar 255
11-2
Appendices
External Source: Subscribers
Properties
File Name Convention subscribers.csv

File
List all subscribers and their relevant attributes such as:

Description
Age, Gender, Location/Zip code, Alias Name etc.
Data Sample X

Integration
'Subscribers' dimension
Every single row represent a single subscriber with

Granularity
various attributes
Data
No
Issues

Yes
sequence?
Filters No

Source
Source Path TBD
Fields Structure
subscriber_id subscriber code varchar 128 Y
subscriber's year of birth
yob integer 4
(yob)
gender Male/Female varchar 10
Postal zip code or other
location subscriber location varchar 255
information
11-3
Appendices
The subscriber name as used
alias_name varchar 255
by the CRM
An indication if the
payment_type subscriber is pre-pad or varchar 20
post-paid subscriber
The name of the operator
the subscriber buys the
service from (for example
operator varchar 255
the carrier may be VF but
the operator may be MVNO
running on VF infrastructure)
home_city Subscriber City varchar 255
home_region Subscriber Region varchar 255
customer_crm_st
Active/Disable etc varchar 255
atus
subscription_nam
Subscription name varchar 255
e
business_resident
varchar 255
ial_ind
subscriber_reserv
For Additional Data varchar 255
ed_1
subscriber_reserv
ed_2
subscriber_reserv
ed_3
subscriber_reserv
ed_4
subscriber_reserv
ed_5
subscriber_reserv
ed_6
subscriber_reserv
ed_7
subscriber_reserv
ed_8
subscriber_reserv
ed_9
subscriber_reserv
ed_10
11-4
Appendices
External Source: Service Plans
Properties
File Name Convention service_plans.csv

File
Service Plans are pre-defined billing/marketing programs.

Description Every subscriber belongs to one service plan at a certain
time.
Data Sample "Default Service Plan"

Integration
'Service Plan' dimension
Every single row represent a single service plan

Granularity
information
Data
No
Issues

Yes
sequence?
Filters No

Source
Source Path TBD
Fields Structure
service_plan_id Service Plane code varchar 128 Y
service_plan_des Service Plane Name /
varchar 255
cription Description
quota_existence Quota Existence integer 4
11-5
Appendices
quota_amount Quota Amount integer 64
External Source: Network Elements
Properties
File Name Convention network_elements.csv

File
Description Network Cell various attributes based on Cell ID
Data Sample "4294967295"

Integration
'Network Elements' dimension
Every single row represent a single network cell with his

Granularity
attributes
Data
Encoding / Obfuscation Issues No
First Row Headers? No

Yes
sequence?
Filters No

Source
Source Path TBD
Fields Structure
network_cell_ke
The cell location identifier varchar 255 Y
y
Name of the cell as appears in
network_name varchar 255
the carrier records
11-6
Appendices
The Nominal capacity, which
network_nomina
above that the cell is integer
l_capacity_up
congested.
The Nominal capacity, which
network_nomina
below that the cell is not integer
l_capacity_down
congested.
Location of the cell, the top
cell_zone varchar 255
level in the hierarchy
Location of the cell, the
cell_region varchar 255
middle level in the hierarchy
Location of the cell, the
cell_city varchar 255
lowest level in the hierarchy
External Source: Network Access Technology
Properties
File Name Convention network_access_technology.csv

File
Network Access Technology based on SDR.SessionRAT

Description
(2G, 3G, 4G)
Data Sample "4096" => "2G"

Integration
'Network Access Technology' dimension
Every single row represent a single network access

Granularity
technology (code & name)
Data

Yes
sequence?
Filters No
11-7
Appendices
Source
Source Path TBD
Fields Structure
network_access_ The network access
varchar 32 Y
technology_key technology identifier
network_access_
Name of the network access
technology_nam varchar 255
technology
e
External Source: SGSN IP List
Properties
File Name Convention sgsn_ip_list.csv

File
originally, it is initial SGSN addresses as received on

session start (3GPP-SGSN-Address). Based on external IP
Description
list, dimension enable to determines if the session is of a
Local or Roaming type.
Data Sample "Roaming"
this data structure will be used as supporting data source

Integration
in order to deretmain if a sgsn value is roaming or local.
Data Granularity Every single row represent a single IP address

Yes
sequence?
Filters No
Source Source System to be supplied by customer
11-8
Appendices
Source Path TBD
Fields Structure
sgsn_ip_address IP address varchar 40 Y
11-9

ClearSee Installation and Administration Guide 16.1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ClearSee Installation and Administration Guide 16.1

Uploaded by

Copyright:

Available Formats

ClearSee

Installation and Administration Guide

i ClearSee Installation and Administration Guide

1.1 ClearSee Capabilities

1.2 System-Level Data Flow

1-1 ClearSee Installation and Administration Guide

Figure 1-1: ClearSee System-Level Data Flow

1.3 ClearSee Scalability Options

1.4 ClearSee Provisioning Options

1.5 Report and NetworkSecure Deployment Modes

2.1 Standard Standalone Specifications

Hardware IBM x3550 M4 1U server

Hardware Lenovo x3550 M5 1U server

2-1 ClearSee Installation and Administration Guide

2.2 Enhanced Standalone Specifications

Hardware Lenovo x3650 M5 2U server

Hardware IBM x3650 M5 2U server

2.3 Cluster Deployment Specifications

3.1 Standard Standalone Requirements

3-1 ClearSee Installation and Administration Guide

3.2 Enhanced Standalone Requirements

• Requirements for the Enhanced Extended Standalone unit are as follows:

3.3 DW Node Requirements

File System • OS: 2 EXT4 file systems, / and /opt

• Requirements for the Extended DW unit are as follows:

3.4 BI Server Requirements

File System • OS: 2 EXT4 file systems, / and /opt

Figure 3-1: Business Intelligence (BI) Server Labeling

4.1 Virtual Machine Requirements

VMWare ESXi VMWare vShpere 5.5 and above

RedHat KVM RedHat RHEL 6.7 and above

CentOS Linux CentOS 7.3, 64-bit x86

See the following for specifications in a Software-Only installation, with a virtual

4.2 Virtual Enhanced Standalone Requirements

4-1 ClearSee Installation and Administration Guide

4.3 Virtual DW Requirements

4.4 Virtual BI Requirements

5.1 High Availability

5-1 ClearSee Installation and Administration Guide

5.2 Ethernet Ports in an Appliance Installation

Figure 5-1: Ethernet Ports on an IBM x3550 M4 1U Server

Figure 5-2: Ethernet Ports on a Lenovo x3550 M5 1U Server

Figure 5-3: Ethernet Ports on an IBM x3650 M4 2U Server

Figure 5-4: Ethernet Ports on a Lenovo x3650 M5 2U Server

5.3 Standalone Deployments

High Availability There are two core active- On Bond 1:

Figure 5-5: ClearSee Standalone Deployment Network Architecture

5.4 Cluster Deployments

Figure 4-2: ClearSee Cluster Distributed Deployment Network Architecture

Figure 5-6: BI Server Labeling

NOTE The BI private network should be configured so as not to block

NOTE The BI private network should be configured so as not to block

6.1 Standalone Install Workflow

6-1 ClearSee Installation and Administration Guide

# I/F MAC Address IP Address NETMASK UP

b. Define the Hostname.

# I/F MAC Address IP Address NETMASK UP

• Perform a sanity check, as described HERE.

6.2 Cluster Install Workflow

# I/F MAC Address IP Address NETMASK UP

ii. Define the Hostname.

# I/F MAC Address IP Address NETMASK UP

vi. Quit netmenu.

• Perform a sanity check, as described HERE.