ecelerity-cluster.conf

# Ensure that we have appropriate privileges
Security {
  user = "ecuser"
  group = "ecuser"
  # Linux
  Capabilities = "cap_net_admin+ep cap_net_bind_service+ep cap_net_raw+ep cap_sys_resource+ep"
  # Solaris
  Privileges = "basic net_privaddr net_bindmlp sys_resource sys_net_config net_rawaccess"
}

ec_logger "ec_logger_cluster" {
  mainlog = "cluster:///var/log/ecelerity/mainlog.cluster=>master"
  paniclog = "cluster:///var/log/ecelerity/paniclog.cluster=>master"
  rejectlog = "cluster:///var/log/ecelerity/rejectlog.cluster=>master"
  acctlog = "cluster:///var/log/ecelerity/acctlog.cluster=>master"
}

bounce_logger "bounce_logger_cluster" {
  bouncelog = "cluster:///var/log/ecelerity/bouncelog.cluster=>master"
}
# The ECCluster_Listener stanza is available as of version 3.0.15
ECCluster_Listener {
  Listen "*:4802" {}
}

cluster {
  #cluster_listener = *:4802 Replaced by the ECCluster_Listener stanza
  #mbus_daemon = 4803 Deprecated in version 3.4
  cluster_group = "ec_cluster"
  control_group = "ec_console"
  logs = [
    rejectlog = "/var/log/ecelerity/rejectlog.cluster"
    paniclog = "/var/log/ecelerity/paniclog.cluster"
    mainlog = "/var/log/ecelerity/mainlog.cluster"
    acctlog = "/var/log/ecelerity/acctlog.cluster"
    bouncelog = "/var/log/ecelerity/bouncelog.cluster"
  ]
  Replicate "inbound_cidr" {}
  Replicate "outbound_cidr" {}
  Replicate "outbound_domains" {}
  Replicate "outbound_binding_domains" {}
  Replicate "shared_named_throttles" {}

  # DuraVIP network topology hints
  Topology "10.1.1.0/24" {
    cidrmask = "32"
    interface = "eth1"
  }
}

mbus_daemon

The most important underlying component of the clustering system is the underlying messaging bus. The Momentum clustering module utilizes a messaging bus that provides extended virtual synchrony (EVS) messaging semantics. The Momentum instance will attach to this node over some form of inter-process communication socket (IPC) (currently either AF_INET or AF_UNIX) as specified by the mbus_daemon configuration option.

**Configuration Change. ** As of version 3.4, cluster communication is handled by the msgc modules rather than by mbus. For more information see “msgc – Modules”.

cluster_group

The DuraVIP™ system will coordinate IP ownership responsibilities via the cluster_group EVS group.

control_group

Each node can respond to normal console commands received on the control_group. The cluster console manager utilizes this group to issue cluster-wide configuration commands to update and discover changes in configuration information. For more information about cluster console commands see “Cluster Management Using Console Commands”.

interface

In the Topology configuration shown in “The ecelerity-cluster.conf file”, 10.1.1.0/24 informs the clustering module that IPs in the range specified will be added to the eth1 ethernet interface.

cidrmask

When bringing an IP address online, you must also know the netmask it will be using. The cidrmask option indicates the number of bits in the netmask for a given IP address. Above, we see that the IP address should be added with a /32 netmask (i.e. 255.255.255.255). It is most common to add IP aliases with a 255.255.255.255 netmask, but this can vary between operating systems.

log_group

When this is enabled, the panic log messages are broadcast over spread, using the specified group name. Another spread enabled application, or the spuser tool, can then listen in on paniclog events.

nodename

Override the node name that is used to canonically identify this cluster node. The nodename is determined according to the following logic: When ec_ctl runs, it determines the node name (and subcluster) as configured from cluster.boot and exports EC_SUB_CLUSTER and EC_NODE_NAME to the environment. If you do not explicitly configure the nodename option, the cluster module will look for the EC_NODE_NAME environment variable and take that as the value. If EC_NODE_NAME is not set in the environment, it will use the system hostname, truncated at the first ‘.’. Note also that modules can use the cluster_nodename hook to determine the effective value of the nodename.

nodeaddr

nodeaddr is the canonical cluster address for the node. If not specified, gethostbyname(nodename) is used to determine the address. The address must be routable via the cluster network, and must not be 127.0.0.1.

log_active_interval

This option, along with log_idle_interval, is used to tune centralized logging (logmove). When logmove is actively sending data to the manager, it will sleep for log_active_interval seconds between each segment send. When the job idles (no segments are pending), then it will sleep for log_idle_interval seconds before looking for another segment, The default value for this option is 1.

log_idle_interval

The amount of time to sleep before looking for another segment. The default value for this option is 10.

heartbeat_start_delay

How many seconds to wait after startup before the cluster heartbeat is activated. The default value for this option is 15.

heartbeats_per_sec

How often to send a heartbeat. The heartbeat is used to help detect "byzantine" nodes in the cluster. The default value for this option is 1.

if_check_interval

How often to run through a maintenance cycle to make sure that the interfaces plumbed on the system match up to the cluster internal view. The default value for this option is 30.

if_down_limit

As part of the maintenance cycle, when detecting that we need to plumb an IP address, how long to wait before deciding that we should bring it online. This avoids rapid "flapping". The default value for this option is 4.

duravip_balance_set_size

When balancing DuraVIP™s, how many to process as a batch in response to a balance request. Clusters with large numbers of DuraVIP™s (especially when they are not explicitly preferenced) will take less time to converge if this number is increased. It is imperative that this number be set consistently across all nodes, as inconsistent values across the nodes will result in a cluster that will not converge (since the nodes will not all agree on the same parameters). Therefore, it is strongly recommended that all the nodes be brought down before changing this option. The value of this option must be greater than 1.

arp_all_hosts

When plumbing a DuraVIP™, you can either aggressively send out ARP information to ensure that the network knows about the IP address assignment (true), or target the ARP to specific hosts of interest (false). You may consider changing this to false if your network experiences problems with the burst of ARP traffic around the DuraVIP™ move. The default value for this option is true.

view_mature_time

How long a DuraVIP™ view needs to remain unchanged before considering it "mature". Increasing the value will make the cluster take longer to fully converge and balance DuraVIP™s. Reducing the value will make it take less time. This option should not generally need to be altered, but you may consider doing so if the cluster is experiencing instability. Best to seek advice from support if that is the case. The default value for this option is 5.

view_balance_interval

How often DuraVIP™ views are subject to balancing. This option is similar to view_mature_time and should to be adjusted without consultation with support. The default value for this option is 10.

unconditional_rebind

Whether the full set_binding logic is invoked when assessing messages for internal cluster message moves or whether to use an optimization that avoids calling out to whatever set_binding logic is in place. The default value for this option is true.

view_broadcast_interval

When non-zero, how often to speculatively broadcast a view announcement to the cluster. Should not be needed except in rare cases when the cluster does not seem to be in sync with views; only enable as directed by support. The default value for this option is 0.