Libcluster intermittent disconnects - what can I configure to create a more reliable cluster?

It is my understanding that distributed erlang is not really built for geographically distributed clusters by default. These connections are not (as you have observed) the most reliable, and this leads to partitioning and other problematic behavior.

This seems pretty high, can you talk about the load that you see?

Did you check net_ticktime: https://www.erlang.org/doc/man/kernel_app.html#net_ticktime

So would Redis clustering be the way to go?

I have 20 nodes because Fly doesn’t have auto-scaling for their Apps v2 platform, you have to pre-allocate your machines

Cool, would this configured inside the runtime file in the Elixir app?

Yes, something like this should work:

config :kernel,
  net_ticktime: 120

Thanks, I did try that but I get the following:

Cannot configure base applications: [:kernel]

These applications are already started by the time the configuration
executes and these configurations have no effect.

If you want to configure these applications for a release, you can
specify them in your vm.args file:

-kernel config_key config_value

Alternatively, if you must configure them dynamically, you can wrap
them in a conditional block in your config files:

if System.get_env("RELEASE_MODE") do
  config :kernel, ...
end

and then configure your releases to reboot after configuration:

releases: [
  my_app: [reboot_system_after_config: true]
]

This happened when loading config/config.exs or
one of its imports.

I’m going to try and set it through the vm.args.eex file. Is there a command I can use with iex to check the net_ticktime? I’ve been doing some searching but nothing is jumping out at me

It appears that nodes just lose connection from time to time

This is what global source code says about it:

%% ----------------------------------------------------------------
%% Prevent Overlapping Partitions Algorithm
%% ========================================
%%
%% 1. When a node lose connection to another node it sends a
%%    {lost_connection, LostConnNode, OtherNode} message to all
%%    other nodes that it knows of.
%% 2. When a lost_connection message is received the receiver
%%    first checks if it has seen this message before. If so, it
%%    just ignores it. If it has not seen it before, it sends the
%%    message to all nodes it knows of. This in order to ensure
%%    that all connected nodes will receive this message. It then
%%    sends a {remove_connection, LostConnRecvNode} message (where
%%    LostConnRecvNode is its own node name) to OtherNode and
%%    clear all information about OtherNode so OtherNode wont be
%%    part of ReceiverNode's cluster anymore. When this information
%%    has been cleared, no lost_connection will be triggered when
%%    a nodedown message for the connection to OtherNode is
%%    received.
%% 3. When a {remove_connection, LostConnRecvNode} message is
%%    received, the receiver node takes down the connection to
%%    LostConnRecvNode and clears its information about
%%    LostConnRecvNode so it is not part of its cluster anymore.
%%    Both nodes will receive a nodedown message due to the
%%    connection being closed, but none of them will send
%%    lost_connection messages since they have cleared information
%%    about the other node.
%%
%% This will take down more connections than the minimum amount
%% of connections to remove in order to form fully connected
%% partitions. For example, if the user takes down a connection
%% between two nodes, the rest of the nodes will disconnect from
%% both of these nodes instead of just one. This is due to:
%% * We do not want to partition a remaining network when a node
%%   has halted. When you receive a nodedown and/or lost_connection
%%   messages you don't know if the corresponding node has halted
%%   or if there are network issues.
%% * We need to decide which connection to take down as soon as
%%   we receive a lost_connection message in order to prevent
%%   inconsistencies entering global's state.
%% * All nodes need to make the same choices independent of
%%   each other.
%% 
%% ----------------------------------------------------------------

So, the real question is are you sure that the connection between nodes is not lost from time to time? If you’re sure, what tool do you use to check it?

If you don’t need global then i would set prevent_overlapping_partitions to false https://www.erlang.org/doc/man/kernel_app.html#prevent_overlapping_partitions

And depending on how many messages you’re sending between nodes you might want to increase the distribution buffer busy limit as well, default is only 1 MB

Also net_setuptime https://www.erlang.org/doc/man/kernel_app.html#net_setuptime

You can use Application.get_env(:kernel, :net_ticktime) to check the value.

Thanks everyone for the tips. I’m testing the different configurations and adding a little more monitoring so I can more easily see improvements. I’ll update again once I’ve seen some improvements

Also very interested in the ideal global config.

We see a lot of packet loss between regions on Fly depending on the region and have managed to only get 4 regions (8 nodes) running somewhat reliably.

Had to build latency monitoring. See: Realtime Status

It logs latencies to our logging infra too if they are over a threshold.

Note: the default PubSub adapter sends all messages to all nodes.

The Redis adapter would route everything through one box which would negate the whole global cluster idea.