hast.conf man page on PC-BSD

Man page or keyword search:  
man Server   9747 pages
apropos Keyword Search (all sections)
Output format
PC-BSD logo
[printable version]

HAST.CONF(5)		    BSD File Formats Manual		  HAST.CONF(5)

NAME
     hast.conf — configuration file for the hastd(8) daemon and the hastctl(8)
     utility.

DESCRIPTION
     The hast.conf file is used by both hastd(8) daemon and hastctl(8) control
     utility.  Configuration file is designed in a way that exactly the same
     file can be (and should be) used on both HAST nodes.  Every line starting
     with # is treated as comment and ignored.

CONFIGURATION FILE SYNTAX
     General syntax of the hast.conf file is following:

	   # Global section
	   control <addr>
	   listen <addr>
	   replication <mode>
	   timeout <seconds>
	   exec <path>

	   on <node> {
		   # Node section
		   control <addr>
		   listen <addr>
	   }

	   on <node> {
		   # Node section
		   control <addr>
		   listen <addr>
	   }

	   resource <name> {
		   # Resource section
		   replication <mode>
		   name <name>
		   local <path>
		   timeout <seconds>
		   exec <path>

		   on <node> {
			   # Resource-node section
			   name <name>
			   # Required
			   local <path>
			   # Required
			   remote <addr>
		   }
		   on <node> {
			   # Resource-node section
			   name <name>
			   # Required
			   local <path>
			   # Required
			   remote <addr>
		   }
	   }

     Most of the various available configuration parameters are optional.  If
     parameter is not defined in the particular section, it will be inherited
     from the parent section.  For example, if the listen parameter is not
     defined in the node section, it will be inherited from the global sec‐
     tion.  In case the global section does not define the listen parameter at
     all, the default value will be used.

CONFIGURATION FILE DESCRIPTION
     The ⟨node⟩ argument can be replaced either by a full hostname as obtained
     by gethostname(3), only first part of the hostname, or by node's UUID as
     found in the kern.hostuuid sysctl(8) variable.

     The following statements are available:

     control ⟨addr⟩

	   Address for communication with hastctl(8).  Each of the following
	   examples defines the same control address:

		 uds:///var/run/hastctl
		 unix:///var/run/hastctl
		 /var/run/hastctl

	   The default value is uds:///var/run/hastctl.

     listen ⟨addr⟩

	   Address to listen on in form of:

		 protocol://protocol-specific-address

	   Each of the following examples defines the same listen address:

		 0.0.0.0
		 0.0.0.0:8457
		 tcp://0.0.0.0
		 tcp://0.0.0.0:8457
		 tcp4://0.0.0.0
		 tcp4://0.0.0.0:8457

	   The default value is tcp4://0.0.0.0:8457.

     replication ⟨mode⟩

	   Replication mode should be one of the following:

	   memsync

		 Report the write operation as completed when local write com‐
		 pletes and when the remote node acknowledges the data
		 receipt, but before it actually stores the data.  The data on
		 remote node will be stored directly after sending acknowl‐
		 edgement.  This mode is intended to reduce latency, but still
		 provides a very good reliability.  The only situation where
		 some small amount of data could be lost is when the data is
		 stored on primary node and sent to the secondary.  Secondary
		 node then acknowledges data receipt and primary reports suc‐
		 cess to an application.  However, it may happen that the sec‐
		 ondary goes down before the received data is really stored
		 locally.  Before secondary node returns, primary node dies
		 entirely.  When the secondary node comes back to life it
		 becomes the new primary.  Unfortunately some small amount of
		 data which was confirmed to be stored to the application was
		 lost.	The risk of such a situation is very small.  The
		 memsync replication mode is currently not implemented.

	   fullsync

		 Mark the write operation as completed when local as well as
		 remote write completes.  This is the safest and the slowest
		 replication mode.  The fullsync replication mode is the
		 default.

	   async

		 The write operation is reported as complete right after the
		 local write completes.	 This is the fastest and the most dan‐
		 gerous replication mode.  This mode should be used when
		 replicating to a distant node where latency is too high for
		 other modes.  The async replication mode is currently not
		 implemented.

     timeout ⟨seconds⟩

	   Connection timeout in seconds.  The default value is 5.

     exec ⟨path⟩

	   Execute the given program on various HAST events.  Below is the
	   list of currently implemented events and arguments the given pro‐
	   gram is executed with:

	   <path> role <resource> <oldrole> <newrole>

		 Executed on both primary and secondary nodes when resource
		 role is changed.

	   <path> connect <resource>

		 Executed on both primary and secondary nodes when connection
		 for the given resource between the nodes is established.

	   <path> disconnect <resource>

		 Executed on both primary and secondary nodes when connection
		 for the given resource between the nodes is lost.

	   <path> syncstart <resource>

		 Executed on primary node when synchronization process of sec‐
		 ondary node is started.

	   <path> syncdone <resource>

		 Executed on primary node when synchronization process of sec‐
		 ondary node is completed successfully.

	   <path> syncintr <resource>

		 Executed on primary node when synchronization process of sec‐
		 ondary node is interrupted, most likely due to secondary node
		 outage or connection failure between the nodes.

	   <path> split-brain <resource>

		 Executed on both primary and secondary nodes when split-brain
		 condition is detected.

	   The ⟨path⟩ argument should contain full path to executable program.
	   If the given program exits with code different than 0, hastd will
	   log it as an error.

	   The ⟨resource⟩ argument is resource name from the configuration
	   file.

	   The ⟨oldrole⟩ argument is previous resource role (before the
	   change).  It can be one of: init, secondary, primary.

	   The ⟨newrole⟩ argument is current resource role (after the change).
	   It can be one of: init, secondary, primary.

     name ⟨name⟩

	   GEOM provider name that will appear as /dev/hast/<name>.  If name
	   is not defined, resource name will be used as provider name.

     local ⟨path⟩

	   Path to the local component which will be used as backend provider
	   for the resource.  This can be either GEOM provider or regular
	   file.

     remote ⟨addr⟩

	   Address of the remote hastd daemon.	Format is the same as for the
	   listen statement.  When operating as a primary node this address
	   will be used to connect to the secondary node.  When operating as a
	   secondary node only connections from this address will be accepted.

	   A special value of none can be used when the remote address is not
	   yet known (eg. the other node is not set up yet).

FILES
     /etc/hast.conf    The default hast.conf configuration file.
     /var/run/hastctl  Control socket used by the hastctl(8) control utility
		       to communicate with the hastd(8) daemon.

EXAMPLES
     The example configuration file can look as follows:

	   resource shared {
		   local /dev/da0

		   on hasta {
			   remote tcp4://10.0.0.2
		   }
		   on hastb {
			   remote tcp4://10.0.0.1
		   }
	   }
	   resource tank {
		   on hasta {
			   local /dev/mirror/tanka
			   remote tcp4://10.0.0.2
		   }
		   on hastb {
			   local /dev/mirror/tankb
			   remote tcp4://10.0.0.1
		   }
	   }

SEE ALSO
     gethostname(3), geom(4), hastctl(8), hastd(8).

AUTHORS
     The hast.conf was written by Pawel Jakub Dawidek ⟨pjd@FreeBSD.org⟩ under
     sponsorship of the FreeBSD Foundation.

BSD				August 30, 2010				   BSD
[top]

List of man pages available for PC-BSD

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net