1 files changed, 95 insertions, 6 deletions

diff --git a/doc/book-enea-edge-getting-started/doc/advanced_configurations.xml b/doc/book-enea-edge-getting-started/doc/advanced_configurations.xml
index 2f34153..10f1e65 100644
--- a/doc/book-enea-edge-getting-started/doc/advanced_configurations.xml
+++ b/doc/book-enea-edge-getting-started/doc/advanced_configurations.xml
@@ -441,12 +441,15 @@ node0.1048576kB = 3 </programlisting>
     example, two of the machines are running only MariaDB, while the rest are
     hosting a MariaDB server and an Enea Edge Management instance. The entire
     network is hidden behind a firewall that performs NAT. While in protection
-    (cluster) mode, the Enea Edge Management instances promote a Virtual IP
-    (VIP) that represents the IP address of the entire cluster. The firewall
-    in this case will allocate a public IP for the outside world that will be
-    translated into the VIP. Also in this example, the traffic towards the
-    cluster from outside the firewall is done through HTTPS, which will be
-    translated to HTTP inside the private network.</para>
+    (cluster) mode, the Enea Edge Management instances promote a single
+    Virtual IP (VIP). The cluster can be reached either from the primary
+    server IP or via VIP (recommended), since the VIP interface is spawned on
+    the primary server. In case of a primary failure, the newly elected
+    primary (from one of the backups) will respawn the VIP interface. The
+    firewall in this scenario will allocate a public IP for the outside world
+    that will be translated into the VIP. Also in this example, the traffic
+    towards the cluster from outside the firewall is done through HTTPS, which
+    will be translated to HTTP inside the private network.</para>
 
     <note>
       <para>By default, communication to the Enea Edge Management is done with
@@ -953,6 +956,92 @@ Configuration complete.</programlisting>
         role="bold">System</emphasis> and select <emphasis role="bold">Cluster
         View</emphasis>. The list of Enea Edge Management servers should be
         displayed, with one listed as Primary and the rest as Backup.</para>
+
+        <para>The High Availability configuration can be changed at a later
+        point, if, for instance, the IPs of the cluster have changed. Before 
+          changing the settings in the configuration files, the Enea Edge 
+          Management application must first be stopped, followed by the 
+          MariaDB database.</para>
+          
+          <para>To change cluster settings, do the following:</para>
+
+        <itemizedlist>
+          <listitem>
+            <para>Change the configuration of the MariaDB with the new IPs: go
+            to <filename>/etc/my.cnf.d/wsrep.cnf</filename> and modify the
+            <literal>wsrep_cluster_address</literal> property.</para>
+          </listitem>
+
+          <listitem>
+            <para>Go to the Enea Edge Management installation folder, then to
+            application/config and edit
+            <filename>databaseConfig.xml</filename>. Change the list of IPs
+            under the <literal>&lt;location&gt;</literal> tag. The order of
+            the IPs is important, since the Edge Management will try to
+            contact them sequentially. Placing the local IP first (the one
+            identified by the protect.interface, see below) will improve
+            communication latency, since it will be done on the local
+            bus.</para>
+          </listitem>
+
+          <listitem>
+            <para>In the same folder, edit the
+            <filename>elementCenter.xml</filename> file. Below are the most
+            important properties relating to the High Availability
+            feature:</para>
+
+            <itemizedlist>
+              <listitem>
+                <para><emphasis role="bold">protect.enabled</emphasis>:
+                boolean value that enables protection mode.</para>
+              </listitem>
+
+              <listitem>
+                <para><emphasis role="bold">protect.group</emphasis>: the name
+                of the protection group.</para>
+              </listitem>
+
+              <listitem>
+                <para><emphasis
+                role="bold">protect.heartbeat.seconds</emphasis>: the time
+                resolution in which a primary server failure is detected. A
+                primary failure during the heartbeat signal period means that
+                service will no longer be available until the next heartbeat
+                occurs. One of the backup servers will take over as primary
+                afterwards.</para>
+              </listitem>
+
+              <listitem>
+                <para><emphasis
+                role="bold">protect.virtualIpAddress</emphasis>: the IP
+                address of the cluster. This value must be the same for all
+                members of the cluster.</para>
+              </listitem>
+
+              <listitem>
+                <para><emphasis role="bold">protect.vipNetmask</emphasis>: the
+                netmask of the virtual IP.</para>
+              </listitem>
+
+              <listitem>
+                <para><emphasis role="bold">protect.interface</emphasis>: the
+                interface responsible for handling ucpeManager traffic,
+                identified by IP address.</para>
+              </listitem>
+
+              <listitem>
+                <para><emphasis
+                role="bold">protect.arbiterIpAddress</emphasis>: the IP
+                address of the arbiter, used to elect a primary server.</para>
+              </listitem>
+
+              <listitem>
+                <para><emphasis role="bold">protect.arbiterPort</emphasis>:
+                the port to ping on the arbiter.</para>
+              </listitem>
+            </itemizedlist>
+          </listitem>
+        </itemizedlist>
       </section>
     </section>