Solved Some basic newbie questions about HAST

gladiola

Active Member

Reaction score: 7
Messages: 106

I would like to know how should I plan to administrate pairs of computers wired together with HAST. Should these pairs of hosts be treated as one computer all the time? Or, should they sometimes be administered as separate machines?

I've got a couple of computers with a fresh FreeBSD installation wired together with HAST. The machines are the same model. They are alike in CPU, hard drives, wiring, and other assets. I looked over the manual and some tutorials; I'm confident that HAST is working. With both hosts up and running, we can ensure that each is in its role as primary or secondary. With HAST functional, and only a base system on each machine, I would like to know what I should expect the machines to do in common situations.
1. For example, will both machines react at the same time in the same way:
  • if we add a user with a username and password
  • if we add a jail
  • if we attach, create, remove or destroy a ZFS pool
  • if we create or remove VNET epair.
2. What if one machine is separated from the HAST pair? If one machine is turned off, and the other goes through the actions listed above? Then, when the second machine returns to the HAST pair by being turned on and assigned a role, it will no longer match the primary. Will the primary identify this difference somehow? Or, will the primary attempt to resume its writes to both machines as if they were the same?

It seems to me that once a HAST pair is created, that it would be up to the sysadmin to keep both machines in line. Maybe it might be very easy for machines to get out of sync. Maybe if one was out of sync, no longer matching the other, and the roles were reversed: it might be possible to tie the structure in a knot.

On one hand, because there is block-level replication, I would expect that actions that write to a disk would be replicated. So, maybe a user would be added in both places. On the other hand, it seems to me that some changes won't involve necessarily writing to disk. Let's say you start a process to echo "Hello world." Perhaps that would only be executed on the primary. But, if we started a process to echo to a file, perhaps the file would be written to both the primary and secondary disks tied together with HAST. So, maybe in a situation like mine, where we are bringing up a system with HAST from the very beginning, it might still be necessary to carry out installation and configuration tasks on both computers separately. Maybe one of the limitations of HAST is that it's about replicating storage, and not necessarily about replicating every action that takes place on the two different hosts.

How do successful sysadmins make sure that these HAST pairs stay even and up-to-date? Yes, I will experiment some in the next few weeks, but I would like to know what's the main path successful people use with HAST. I mostly have to coach myself; any advice you provide might be helpful.
 

mjollnir

Daemon

Reaction score: 699
Messages: 1,154

[...] Maybe one of the limitations of HAST is that it's about replicating storage, and not necessarily about replicating every action that takes place on the two different hosts.
Yes. A HAST+CARP is not a cluster that appears & behaves as one system. You would have to add that e.g. with (sorry there used to be a quasi-standard cluster/grid shell but I do not remember it's name... :( )
make -C /usr/ports search key='cluster' | egrep '^(Port|Info):' | less The same command with parallel show some more. You can use ansible to aid administration.
How do successful sysadmins make sure that these HAST pairs stay even and up-to-date?
You have to set that up for each service. Some commonly used services provide that, especially databases. pkg search cluster tells there are libraries for Perl & Python, so you can write scripts to synchronize your services. Obviously things like write a file to a tmpfs, then do something with it can be hairy.
 
Top