I would not recommend using the architecture or systems described in that tutorial. Heartbeat has been EOL for nearly a decade, two-node master-master clusters only have a hope of resilience if thy employ highly effective fencing (as there is no hope of quorum in two nodes), which is not even touched on in that tutorial.
Further, there's very little point to a highly active cluster on two nodes - the goal is to be able to lose a node, so if the system gets "balanced" across two read/write replicas, both systems should enforce a maximum 40% load utilization. It's much more sensible and less overhead to use an active/passive system that describes a single primary read/write replica, with a read-only replica standing by that can be promoted.
It is also important to establish stronger cluster stability guarantees than a total lack of fencing or quorum can. Rather than express this with Heartbeat, this could be expressed in Pacemaker and Corosync. A third (very small) node can be used to establish quorum - either with Galera, or via Corosync. I would suggest both.
As an alternative to Galera, replicating the underlying storage and running only one SQL server instance is a very fast, low-overhead option. This can be accomplished via DRBD, Pacemaker, and Corosync. Managing MySQL clusters in Pacemaker is something that's been solved for over a decade, and works very reliably.