Database Sharding¶

Database Sharding is a way to organize large sets of data across multiple servers. Sharded data is stored completely separate from other shards and each individual shard has no knowledge of the other, but the Assure1 web interface seamlessly correlates and displays data collected from all shards allowing for a completely unified view. The Assure1 platform supports database sharding for Events & Historical, and Metric data that is simple to configure and transparent to users.

There are many benefits and use cases when considering sharding a database:

Load balancing - Assure1 applications only talk to the shards needed lightening the load across the databases.
Scaling - Big data can be stored in manageable pieces across the multiple database shards supporting larger scale environments.
Data Storage Compliance - Each shard's data is stored in a standalone fashion and has no knowledge of data from any other shard.

This section details the procedure for installing and configuring new database shards for Events, Historical Events, and Metrics databases within the Assure1 platform.

Pre-Planning Shard Data Organization¶

Event & Historical¶

Assure1 aggregators support different shards but must know at startup what shard it will be communicating with. Within the Assure1 platform, events can be sharded in the following ways:

Collection Point (most common) - Alarm data based on which server received it. This method allows for segregation of data based on geographical regions. For example: Shard 1 is in US and only handles collected events from the US Assure1 aggregation servers, while Shard 2 is in Europe and only handles collected events from the Europe Assure1 aggregation servers.
Alarm Type - Alarm data from a certain aggregator, such as SNMP traps, to a certain shard. This method allows for additional analysis or profiling of a certain type of data.

Metric¶

Assure1 metric collectors and pollers support multiple shards based on the device's and metric's shard definition. Shard information can be set at the device or metric level within the Assure1 platform and metrics can be sharded in a few different manners:

Device (most common) - All metrics for certain devices are stored on a specific shard, this includes separation by Device Zone or Device Group. This method allows for segregation of device data by geographical regions or polling clusters. For example: Shard 1 is in US and only handles collected metrics from the US Assure1 collection servers, while Shard 2 is in Europe and only handles collected metrics from the Europe Assure1 collection servers. (This is the easiest to configure and maintain)
Metric Type - Metric data of certain types, such as Latency & Packet Loss, are stored on a specific shard. This method allows for additional analysis or profiling of a certain type of data, but additional maintenance is required to keep accurate.

Installation¶

New Server(s)¶

Follow the steps in the Preparation section of the Multi-Server Install Guide to get the server ready for Assure1.
Follow the steps in the Database Server section of the Multi-Server Install Guide to get Assure1 installed.

Note

When asked what roles to install, the Database.Event and/or Database.Metric roles can be entered depending on the type of database being sharded. Additional roles can also be installed, if needed.
Wait for the installation to complete.

Existing Servers¶

Login to the command line of the server that will have the database added to it.
Use the Package application to install additional roles with the new database functionality.
```
$A1BASEDIR/bin/Package install-role (Comma-separated list or roles)
```
Note

See the All Server Roles section of the Understanding Server Roles guide for a list of roles that can be installed.
Wait for the installation to complete.

Sharding Procedure¶

New Events Shard¶

Navigate to Configuration -> Databases -> Databases and verify new shard entry for Event database.
Organize event aggregators into shards based on pre-planning or policies.
Clone necessary aggregators and respective application configurations, updating ShardID to appropriate shard.
Verify new events are being inserted into the correct database instance.

New Metric Shard¶

Navigate to Configuration -> Databases -> Databases and verify new shard entry for Metric database.
Organize and set Devices' and Metrics' ShardIDs to appropriate shards based on pre-planning or policies.
Restart any affected polling clusters.
Verify new metrics are being inserted into the correct database instance.

Redundancy¶

Login to the command line of the server that will have the redundancy added to it.
Use the Package application to install the Database.Redundancy role.
```
$A1BASEDIR/bin/Package install-role Database.Redundancy
```
Wait for the installation to complete.
Follow the steps in the Running Redundancy Wizard -> Database Servers section of the Multi-Server Redundant Install Guide to configure database redundancy.