Aspire as a content processing framework is capable of coordinating work with other Aspire servers in order to balance the resource utilization and provide high availability.
This section describes how does Aspire work in a distributed environment and how to configure it.
When configured to work in a cluster, Aspire interacts with two different external systems simultaneously:
All servers are equal in an Aspire cluster, this means there is no "master" server.
By default the Aspire distributions are configured to work in standalone mode:
Code Block | ||
---|---|---|
| ||
<configAdministration> <zookeeper enabled="false" root="/aspire"> <!-- <externalServer>127.0.0.1:21822181,127.0.0.1:21832181,127.0.0.1:2181</externalServer> --> </configAdministration> |
Let's configure our Aspire cluster, in each Aspire server modify the config/settings.xml:
So our first step would be to enable zookeeper and point to our zookeeper cluster. (Let's assume we have a three server zookeeper cluster zooA.dev.com, zooB.dev.com and zooC.dev.com)
Code Block | ||
---|---|---|
| ||
<configAdministration> <zookeeper enabled="true" root="/aspire"> <externalServer>zooA.dev.com:2182,zooB.dev.com:2183,zooC.dev.com:2181</externalServer> </configAdministration> |
Its recommended that you name each server with some unique id, otherwise Aspire will set its unique ID as the IP address.
Code Block | ||
---|---|---|
| ||
<configAdministration>
<zookeeper enabled="true" root="/aspire">
<externalServer>zooA.dev.com:2182,zooB.dev.com:2183,zooC.dev.com:2181</externalServer>
<serverId>aspireA</serverId>
</configAdministration> |
If we were to start our Aspire servers now, they would not interact with each other as a cluster, this is because they do not share the same cluster ID. So let's define our clusterID to be "dev", by uncommenting the <clusterID> field:
Code Block | ||
---|---|---|
| ||
<!-- By default all Aspire servers start in their own cluster. To make servers work together, set a common cluster id across multiple instances that are connected to a common zooKeeper instance and database provider (for example "dev" or "prod") --> <clusterId>dev</clusterId> |
From that server execute
Code Block | ||
---|---|---|
| ||
$ bin/pushLicense.sh 2019-06-03T18:10:35Z INFO [BOOTLOADER]: Connection state is CONNECTED 2019-06-03T18:10:36Z INFO [BOOTLOADER]: Settings File: /aspire/config/settings.xml License File: /aspire/config/license/AspireLicense.lic License copied to /aspire/dev/license/AspireLicense.lic |
Info |
---|
Now any new Aspire server connecting to this ZooKeeper cluster with the same cluster ID will use the same license, so you don't need to copy it into the serverThis will upload the license into the ZooKeeper cluster, so all new servers connecting to it will automatically download it. |
From now on, any configuration done on one server will be synchronized into the others.
Property | Default | Description |
---|---|---|
sharedFolder | config/shared | Path where the shared folder is located. This folder is used to share configuration files between servers in the cluster. (seed files, mappings, transformation files, etc.). |
connectionTimeout | 3000 | Connection timeout (in ms) is how long to wait for a server response. |
sessionTimeout | 6000 | The session timeout (in ms) to negotiate with the zookeeper servers. |
syncTime | 10000 | How often the non cluster mode should check for updates. In cluster mode, this is only used for updates frequency for the sharedFolder. |
releaseTimeoutSeconds | 30 | Time (in seconds) to wait for a server to become available after leaving the cluster. If the server detected to be down, does not appear as online after this timeout, all its resources will be "released" from the NoSQL database. |
maxRetries | 50 | Max retries for the zookeeper connections |
maxBackoffSleepTime | 5000 | Maximum time (in ms) to wait between each retry. Exponential increases will be applied for successive failures, starting at 500 ms. |
As we mentioned above, when starting in cluster mode, Aspire pulls the configuration from ZooKeeper, this means it discards any local configuration it has. If you were using Aspire in standalone mode, then all your configuration was locally stored in the config folder of your distribution, so when you connected Aspire for the first time to ZooKeeper it discarded it all in favor of pulling the configuration from ZooKeeper (which has nothing)
But don't worry, every time Aspire starts, it creates a backup of the system configuration and stores it under config/backups: once you have started your distribution with ZooKeeper you can import the backup and restore your system configuration!
If you need to upload the license again, use the -force argument like this:
Code Block | ||
---|---|---|
| ||
$ bin/pushLicense.sh -force |
Then in order to force all servers to download the new license, delete all files under config/license in all servers