5.9. Controlling Bandwidth Usage

Ngenea Hub can control the amount of traffic speed for each node within each site that processes files through Ngenea. This will limit both outgoing and incoming traffic with defined cloud services.

5.9.1. Enabling the bandwidth feature in the UI

Regardless of enabling this feature, it is possible to change the bandwidth via REST and will enable changing of bandwidth when the Site instance has its bandwidth attribute changed.

This can be enabled by enabling the feature flag, details on how to do this can be found on the Feature Flags page.

This will enable the UI within the Site details page and represents the bandwidth limit in Mb/s.

5.9.2. Checking Node status

Each site within Ngenea Hub is the collection of all nodes running an instance of Ngenea Worker using the name of a given site. These are nodes within a cluster that are collectively listening to the same queue for a given site. Each time any worker comes online on a new node or a known node, this is tracked within Ngenea Hub using Node objects. These are automatically created when first starting up a worker, after creation their online status can be monitored.

You can view the nodes for each site within /api/nodes/ this will be a complete list of all nodes known to Ngenea Hub.

For bandwidth control, there will need to be existing nodes known to Ngenea Hub, otherwise the bandwidth rules cannot be applied. If your worker coming online was not tracked due to timing issues, you can manually scan for existing nodes using one of the Actions.

5.9.3. Registering Datastores

In order to control the bandwidth for all nodes under a site, the site will need to have the Ngenea policy targets defined as Datastore instances within Ngenea Hub.

The following example is for defining an AWS S3 target for Ngenea within Ngenea Hub:

{
    "name": "site1_amazon",
    "type": "S3",
    "bucket": "bucket01",
    "secretaccesskey": "secret-key",
    "accesskey": "access-key"
}

With this established datastore, all that is left to do is link the created datastore to a site so that when a change in bandwidth is applied, the site knows what service to limit the traffic to.

5.9.3.1. Cloud IPAddresses

Each datastore that points to a cloud target will have access to a list of all known IP addresses that are associated with that specific service. This will be used to limit all traffic between those IP ranges and the nodes currently running a worker instance when a bandwidth limit is applied.

These IP ranges are updated internally once a day in a scheduled task.

5.9.3.2. Using manual IP addresses

Manual IP addresses can be used to override the list of cloud related IPs, this can be useful to control bandwidth to custom endpoint targets such as services like minio making use of POST api/ipaddresses/. Using the following example to add an address to the list of IPAddresses:

Note

This will disable the use of all cloud addresses for a datastore and will instead only use the custom IP addresses.

{
    "ipaddr": "208.65.153.237",
    "datastore": 1
}

This will ensure that all traffic between those nodes and the defined IP addresses will be limited to the max bandwidth limit

5.9.4. Linking a Datastore to a Site

With our example site site1 creating a SiteLink between site1 and the datastore site1_amazon allows the bandwidth to be applied to all S3 targets on all nodes that are running the Ngenea Worker service.

For this example all local data for this Ngenea is located in /mmfs1/data/aws_data with data being placing data in the bucket bucket01 under aws_data/.

The following SiteLink can be used to represent this:

{
    "site": "site1",
    "datastore": "site1_amazon",
    "site_path": "/mmfs1/data/aws_data/",
    "datastore_path": "aws_data/"
}

This will ensure that each Node under site1 will limit its traffic to all related addresses.

5.9.5. Applying the bandwidth

Note

This will effect all traffic on each node running a worker to the cloud services defined with the sites linked datastores.

With the SiteLink in place, changing the bandwidth attribute to the Mb/s desire on the site instance via the API route PATCH /api/site/{id}:

{
  "bandwidth": 1000
}

Using this or the UI, this will cause the hub to signal the worker to limit traffic using the IP ranges defined for the datastores.

This total bandwidth will be divided between all nodes for any given site, so if a site has a bandwidth of 1Gb/s then both nodes will be limited to 500mb/s.