You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
title: "Configuring Momentum for High Availability and Failover"
4
-
description: "Momentum's architecture supports fault tolerant configurations This means that you can operate in an environment that is readily configured to support failing over automatically Components that support high availability and fault tolerance include the following ecconfigd Dura VIP™ bindings Centralized logging and Aggregration Per node data Per node logs can..."
4
+
description: "Momentum's architecture supports fault tolerant configurations This means that you can operate in an environment that is readily configured to support failing over automatically"
5
5
---
6
6
7
7
Momentum's architecture supports fault-tolerant configurations. This means that you can operate in an environment that is readily configured to support failing over automatically.
8
8
9
9
Components that support high availability and fault tolerance include the following:
*[Centralized logging and Aggregration](/momentum/4/log-aggregation)
@@ -22,4 +20,4 @@ Components that support high availability and fault tolerance include the follow
22
20
23
21
*[cidr_server](/momentum/4/4-cluster-cidr-server) and [as_logger](/momentum/4/modules/as-logger)
24
22
25
-
The **cidr_server** queries the data created by an as_logger module and displays the result in the cluster console. The **cidr_server** and as_logger can be configured to log data to a SAN. Locking semantics must be checked.
23
+
The **cidr_server** queries the data created by an as_logger module and displays the result in the cluster console. The **cidr_server** and as_logger can be configured to log data to a SAN. Locking semantics must be checked.
description: "Clustering is based on the concept of having a cluster of machines that communicate using a group communication messaging bus A cluster is comprised of at least one Manager node and one or more MTA nodes The Manager in the cluster will be your central point of management for the..."
4
+
description: "Clustering is based on the concept of having a cluster of machines that communicate using a group communication messaging bus A cluster is comprised of at least one Manager node and one or more MTA nodes"
5
5
---
6
6
7
7
8
8
Clustering is based on the concept of having a cluster of machines that communicate using a group communication messaging bus. A cluster is comprised of at least one Manager node and one or more MTA nodes. The Manager in the cluster will be your central point of management for the cluster. Ideally, a cluster will have a dedicated gigabit network for transmission of replicated data and internal message moves.
9
9
10
10
The clustering capabilities of Momentum enable the following features:
11
11
12
-
* Centralized management of configuration for multiple MTA nodes
13
-
14
-
* Replicated, redundant, configuration repository with revision control
15
-
16
12
* Log aggregation pulling log files from MTA nodes to centralized location(s) on the network
17
13
18
14
* Replication of a variety of real-time metrics to allow cluster-wide coordination for inbound and outbound traffic shaping
@@ -47,49 +43,6 @@ For general information about Momentum's configuration files, see [“Configurat
47
43
48
44
For additional details about editing your configuration files, see [“Changing Configuration Files”](/momentum/4/conf-overview#conf.manual.changes).
Momentum configuration files are maintained in a version control repository and exported to your cluster network via the [`ecconfigd`](/momentum/4/conf-overview#conf.ecconfigd) service running on the cluster manager. This daemon is auto-configuring and will replicate your configuration repositories to all participating cluster nodes. On the cluster manager, the repository resides in the `/var/ecconfigd/repo` directory. Nodes pull their configuration from this repository and store their working copy in the `/opt/msys/ecelerity/etc/conf` directory.
53
-
54
-
The default installation has a cron job deployed on the nodes that uses [**eccfg pull**](/momentum/4/executable/eccfg) to update the local configuration from the `ecconfigd` service. **eccfg** is built in such a way that these updates are applied atomically to the configuration checkout directory.
55
-
56
-
The tools that operate on the configuration checkout directory try very hard to avoid leaving it in a broken state. Every minute, each node will attempt to update its directory to match the repository. If you have made local changes to the directory, the update will attempt to merge updates from the repository with your changes. The update process will only modify the directory if the complete revision was able to be pulled. In other words, it will not modify the configuration checkout directory if doing so causes a conflict and will never leave a directory with a half-applied update.
57
-
58
-
In some situations, it is possible to put the configuration replication into a conflicted state. For instance, in a two node cluster, if one of the nodes is unplugged from the network while configuration changes are made and committed on both nodes, when the network cable is re-connected, the configuration will attempt to sync but will notice that conflicting changes have been made. If conflicting changes were found, `ecconfigd` will warn you and provide you with instructions on how to resolve the conflict. You may need to manually resolve the conflicting configuration files. For instructions on changing configuration files, see [“Changing Configuration Files”](/momentum/4/conf-overview#conf.manual.changes).
59
-
60
-
**<aname="cluster.config_files.mgmt.cluster"></a> 16.1.1.1. Repository Working Copy for Cluster**
61
-
62
-
On the client side of the configuration management, each node has a working copy checkout of the repository located at `/opt/msys/ecelerity/etc/conf`. The following are descriptions of the subdirectories in a cluster configuration:
63
-
64
-
*`global` – location for sharing cluster-wide configuration information between nodes
65
-
66
-
Every node has access to this subdirectory.
67
-
68
-
*`default` – contains your default configuration files, which are shared across multiple nodes
69
-
70
-
`default` is the name of the default subcluster and represents the default configuration for nodes in that subcluster.
When you create a node-specific configuration file, a directory bearing the node name and a node-specific `ecelerity.conf` file are created on *all* nodes in the cluster.
75
-
76
-
When nodes use common values for a number of options, if you wish you can put these options in a configuration file stored in the `global` directory rather than repeating them in each /opt/msys/ecelerity/etc/conf/*`nodename`*/ecelerity.conf file. However, you must add include statements to the /opt/msys/ecelerity/etc/conf/*`nodename`*/ecelerity.conf file on each node.
77
-
78
-
**`peer`* – any files shared by multiple nodes in a single subcluster
79
-
80
-
By default the order is:
81
-
82
-
```
83
-
/opt/msys/ecelerity/etc
84
-
/opt/msys/ecelerity/etc/conf/global
85
-
/opt/msys/ecelerity/etc/conf/{NODENAME}
86
-
/opt/msys/ecelerity/etc/conf/default
87
-
```
88
-
89
-
Directories are separated by the standard path separator.
90
-
91
-
If you wish to change the search order, set the environment variable `EC_CONF_SEARCH_PATH`. For more information about `EC_CONF_SEARCH_PATH`, see [*Configuring the Environment File*](/momentum/4/environment-file) .
92
-
93
46
### <aname="cluster.config_files.local.include"></a> Using Node-local `include` Files
94
47
95
48
If you have any configurations specific to a particular node, fallback values for configuration options in that node-local configuration file *cannot* be included via the `/opt/msys/ecelerity/etc/conf/ecelerity.conf` file. For an included file, the parent file's path is added to the search path, so if a file is included from `/opt/msys/ecelerity/etc/conf/default/ecelerity.conf`, the search path becomes:
@@ -109,4 +62,4 @@ Set `OPTION` in a `node-local.conf` file in all the /opt/msys/ecelerity/etc/conf
109
62
110
63
Add an "include node-local.conf" statement to `/opt/msys/ecelerity/etc/default/ecelerity.conf`.
111
64
112
-
If there are major differences between node configurations, it is probably simpler to create a separate configuration file for each node as described in [“Repository Working Copy for Cluster”](/momentum/4/4-cluster#cluster.config_files.mgmt.cluster).
65
+
If there are major differences between node configurations, it is probably simpler to create a separate configuration file for each node as described in [“Repository Working Copy for Cluster”](/momentum/4/4-cluster#cluster.config_files.mgmt.cluster).
Copy file name to clipboardExpand all lines: content/momentum/4/4-implementing-policy-scriptlets.md
+9-39
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
---
2
-
lastUpdated: "03/26/2020"
2
+
lastUpdated: "05/21/2024"
3
3
title: "Policy Scriptlets"
4
-
description: "Lua scripts provide you with the capability to express the logic behind your policy Aside from being very convenient policy scripts can be reloaded on the fly allowing real time adjustment of policy without interrupting service the Momentum implementation has extremely low overhead and tightly integrates with the event based..."
4
+
description: "Lua scripts provide you with the capability to express the logic behind your policy Momentum implementation has extremely low overhead and tightly integrates with the event based architecture"
5
5
---
6
6
7
7
Lua scripts provide you with the capability to express the logic behind your policy. Aside from being very convenient (policy scripts can be reloaded on the fly, allowing real-time adjustment of policy without interrupting service), the Momentum implementation has extremely low overhead and tightly integrates with the event-based architecture, being able to suspend processing until asynchronous operations (such as DNS resolution, or database queries) complete. Note that variables used in a policy script are scoped locally and only persist in the particular policy script in which it is defined. Use the [validation context](/momentum/4/4-policy#policy.validation) to persist data over different policy phases and policy scripts.
@@ -106,31 +106,19 @@ In the `default_policy.conf` file, you should also enable the datasource(s) suit
Following best practices when creating policy scripts is important, especially in a cluster environment when scripts are used on more than one node. Scripts should take advantage of Momentum's built-in revision control and be added to the repository using the [eccfg](/momentum/4/executable/eccfg) command.
109
+
Following best practices when creating policy scripts is important, especially in a cluster environment when scripts are used on more than one node.
110
110
111
111
To create a policy script, perform the following:
112
112
113
-
1. Take steps to avoid conflicts.
114
-
115
-
When working with files that are under revision control, it is important to take steps to avoid conflicts with changes made elsewhere in the system and to be able to track changes. For this reason, perform the following actions before creating any policy scripts:
116
-
117
-
* Provision a user account for each admin user, so that the history in the repository is meaningful.
118
-
119
-
* Ensure that you have the latest updates on the node where you are creating the scripts by running **`/opt/msys/ecelerity/bin/eccfg pull`** .
120
-
121
-
### Note
122
-
123
-
Pay special attention to the instructions for using the **pull** command—if the configuration is updated your current directory may be invalidated. For more information, see [eccfg](/momentum/4/executable/eccfg).
124
-
125
-
2. Create a directory for your script.
113
+
1. Create a directory for your script.
126
114
127
115
Scripts should be created in a directory that is under revision control. Create a directory for your scripts in the working copy of the repository on a node where you intend to run the script:
128
116
129
117
* If your scripts apply to all nodes in the cluster, create this directory under the `/opt/msys/ecelerity/etc/conf/default` directory or store them in the `global` directory. Typically, policy scripts are saved under Momentum's default working copy directory `/opt/msys/ecelerity/etc/conf/default/scripts`.
130
118
131
119
* If your scripts apply to only one node, create a node-specific directory.
132
120
133
-
3. Write your script.
121
+
2. Write your script.
134
122
135
123
All scripts must
136
124
@@ -175,7 +163,7 @@ To create a policy script, perform the following:
175
163
176
164
These messages indicate a scriptlet error and give both the name of the script and the callout that failed.
177
165
178
-
4. Update your configuration to properly reference your script.
166
+
3. Update your configuration to properly reference your script.
179
167
180
168
After writing a script and saving it to the repository, you must include it in the [`scriptlet`](/momentum/4/modules/scriptlet) module using a `script` stanza in your `ecelerity.conf` file.
181
169
@@ -219,7 +207,7 @@ To create a policy script, perform the following:
219
207
220
208
For additional details about editing your configuration files, see [“Changing Configuration Files”](/momentum/4/conf-overview#conf.manual.changes).
221
209
222
-
5. Check the validity of your script.
210
+
4. Check the validity of your script.
223
211
224
212
Since a malformed configuration file will not reload, using **config reload** is one way of validating your scriptlet syntax. After your configuration has been changed, issue the command:
225
213
@@ -244,7 +232,7 @@ To create a policy script, perform the following:
244
232
245
233
However, please note that Message Systems does not provide support for the use of any third party tools included or referenced by name within our products or product documentation; support is the sole responsibility of the third party provider.
246
234
247
-
6. Debug your script.
235
+
5. Debug your script.
248
236
249
237
Successfully reloading the configuration file does not guarantee that your script will run. Your script may be syntactically correct but have semantic errors. As always, you should test the functionality of scripts before implementing them in a production environment.
250
238
@@ -288,24 +276,6 @@ To create a policy script, perform the following:
288
276
note="No email received at this address", code="550"}
289
277
```
290
278
291
-
7. Commit your changes.
292
-
293
-
Once you are satisfied that your scripts function correctly, commit your changes. From the directory above your newly created directory, use **eccfg** to add both the directory and the script to the repository:
294
-
295
-
* If you are adding a new script, issue the command
* If you are editing a script, you need not use the `––add-all` option.
300
-
301
-
8. Repply your changes, if required.
302
-
303
-
In all cases, edits made to the local configuration will need to be manually applied to the node via **config reload** . The **eccfg commit** command will not do it for you. If you have not reloaded your configuration, issue the console command:
If your changes affect more than one node, each node will check for an updated configuration each minute and automatically check out your changes and issue a **config reload** .
This section includes examples of using policy scripts.
@@ -336,4 +306,4 @@ Use `msg.priority` to read the priority of a message.
336
306
337
307
### Note
338
308
339
-
It is important not to overuse the priority setting. High priority messages should be reserved for messages that need to go out immediately, before other messages. Keeping high priority messages to a low percentage of the total message volume is important so the high priority messages do not cause delays for normal priority messages. A common use case for high priority messages is sending out password resets in the midst of a major mail campaign.
309
+
It is important not to overuse the priority setting. High priority messages should be reserved for messages that need to go out immediately, before other messages. Keeping high priority messages to a low percentage of the total message volume is important so the high priority messages do not cause delays for normal priority messages. A common use case for high priority messages is sending out password resets in the midst of a major mail campaign.
Copy file name to clipboardExpand all lines: content/momentum/4/4-preface.md
+4-4
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
---
2
-
lastUpdated: "03/27/2020"
2
+
lastUpdated: "05/21/2024"
3
3
title: "Preface"
4
-
description: "Certain typographical conventions are used in this document Take a moment to familiarize yourself with the following examples Text in this style indicates executable programs such as ecelerity Text in this style is used when referring to file names For example The ecelerity conf file is used to configure Momentum..."
4
+
description: "Certain typographical conventions are used in this document Take a moment to familiarize yourself with the following examples"
5
5
---
6
6
7
7
## <aname="typographical"></a> Typographical Conventions Used in This Document
@@ -37,5 +37,5 @@ The preceding line would appear unbroken in a log file but, if left as is, it wo
37
37
38
38
Where possible, Unix command-line commands are broken using the ‘`\`’ character, making it possible to copy and paste commands. For example:
0 commit comments