hyperion-cs / dhaf Goto Github PK

OS: Windows 10 x64, Windows Server 2016
Dhaf: 1.2.2
etcd: 3.5.8

Dhaf.node works fine:
dhaf>dhaf.node --config config-n1.dhaf
←[97m2023-05-04 14:09:57.1963 INFO: Configuration file is <config-n1.dhaf>.←[0m
←[97m2023-05-04 14:09:57.5336 INFO: I am in the cluster.←[0m
←[37m2023-05-04 14:09:57.5336 DEBUG: Switcher provider for

but when i launch Dhaf.CLI.exe it gets error:
dhaf.cli status-services --config config-n1.dhaf

Unhandled exception. System.UriFormatException: Invalid URI: The hostname could not be parsed.
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at System.Uri..ctor(String uriString)
at Dhaf.CLI.Actions.PrepareRestClient(IConfigPath opt)
at Dhaf.CLI.Actions.ExecuteStatusServicesAndReturnExitCode(StatusServicesOptions opt)
at Dhaf.CLI.Program.Main(String[] args)
at Dhaf.CLI.Program.

Please help.

In the future, switcher providers may be added that switch longer than the dhaf.tact-interval parameter in the dhaf configuration. Thus, it is worth adding another parameter in the services.[i] section (e.g., after-switching-delay), which will contain the delay time before the next tact after switching to another entry point for the web service.
This parameter cannot be dhaf.tact-interval directly, because in other cases the delay between the tacts should normally be shorter (e.g: 10 seconds in normal state, and 1 minute after failover).

G-Core Labs (gcorelabs):

1. Does not require working on the lower network layers according to the OSI model;
2. Has a free plan;
3. Has ~100% uptime;
4. Has an official API.

In general, etcd nodes should be protected by a firewall. However, some users may also need authorization support for etcd.

In general, the principles and mechanisms of health checks are the same for any network service. As well as the principles of server redundancy to provide HA. Thus, the idea of dhaf can be scaled to a general-purpose failover system (not just for Clouflare).

This can be implemented roughly as follows:

1. dhaf makes health checks;
2. If dhaf detects that the network service is unavailable, then immediately apply the action to switch to the replica scheme of operation;
3. if dhaf detects that the master network service scheme is available again, then immediately switch to it.

* Of course, there can be several replica schemes. Which one to switch to is a configurable decision.

Idea:
At the moment, you have to wait for a health inspection of all network configurations of the service to decide whether to failover/switching. However, in case one or more NCs are unhealthy the inspection may take some time (e.g. waiting for a connection timeout).

Technically, there is no need to wait for some NCs to be inspected if the higher priority NCs are already marked as healthy. You can immediately failover/switching to a healthy priority NC.

This can definitely speed up "switching". With "failover" you can hardly expect a big speed increase.

It may be worth encapsulating etcd nodes (and their management) inside dhaf to simplify the process of starting a dhaf cluster. If this is optional (e.g.: etcd.self-hosted parameter), it will still be able to manually manage (including on individual servers) the etcd nodes.

Proposed part of the configuration (feature on):

etcd:
  self-hosted: false
  nodes:
    current: http://111.111.101.1:2379
    other: 
      - http://111.111.101.2:2379
      - http://111.111.101.3:2379

Proposed part of the configuration (feature off):

etcd:
  self-hosted: true # default value
  hosts: http://111.111.101.1:2379,http://111.111.101.2:2379,http://111.111.101.3:2379

This will allow much faster checks when one or more network configurations are unhealthy. Of course, because of the timeouts.

This is necessary because someone could accidentally change the record via Cloudflare Dash.