PIXILAB Wiki

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
blocks:server:mirror [2024-10-25 07:43] – Broken Links adminblocks:server:mirror [2025-10-01 09:53] (current) – [Introduction] admin
Line 1: Line 1:
 ====== Blocks Mirroring Service ====== ====== Blocks Mirroring Service ======
  
-Our Linux-based server (dated 2020-05-25 and later, running Ubuntu 20.04), supports a redundancy feature for increased system reliability. While the Blocks server software is very robust, the complete system can never be more reliable than the hardware it runs on.+Our Linux-based server supports a hardware redundancy feature for increased system reliability. While the Blocks server software is very robust, the complete system can never be more reliable than the hardware it runs on.
  
 ===== Introduction ===== ===== Introduction =====
Line 21: Line 21:
 However, if your Blocks server dies, and won't come back by turning power off and back on again, things are a bit more difficult. Assuming you have an up-to-date backup of your Blocks root directory, as well as other relevant server settings, you can replace the server with a new one, and bring it back to life using those backups. However, that may take a while to accomplish, rendering your entire Blocks installation non-functional in the meantime. However, if your Blocks server dies, and won't come back by turning power off and back on again, things are a bit more difficult. Assuming you have an up-to-date backup of your Blocks root directory, as well as other relevant server settings, you can replace the server with a new one, and bring it back to life using those backups. However, that may take a while to accomplish, rendering your entire Blocks installation non-functional in the meantime.
  
-A better option is to have a spare server sitting in the rack all along, just as suggested for the main switch above. If you're sufficiently concerned about your system's reliability to keep such a spare on hand, this new feature is for you.+A better option is to have a spare server sitting in the rack all along, just as suggested for the main switch above. If you're sufficiently concerned about your system's reliability to keep such a spare on hand, this feature is for you.
  
 {{ :blocks:server:mirror:mirroring.jpg?nolink |}} {{ :blocks:server:mirror:mirroring.jpg?nolink |}}
  
-The new Blocks Mirroring Service will keep your spare computer up to date with any changes applied to Blocks. As soon as you make any changes, such as editing a block or adding a new spot, those changes are copied across to the mirror server. Note, in the illustration above, that the main Blocks server is still connected and used as it was in the stand-alone illustration shown at the beginning of this article. The Mirror server uses a //second// network port as a backdoor connection to your Blocks server. This backdoor is used as a secure channel for copying all changes across as the system runs. +The Blocks Mirroring Service will keep your spare computer up to date with any changes applied to Blocks. As soon as you make any changes, such as editing a block or adding a new spot, those changes are copied across to the mirror server. Note, in the illustration above, that the main Blocks server is still connected and used as it was in the stand-alone illustration shown at the beginning of this article. The Mirror server uses a //second// network port as a backdoor connection to your Blocks server. This backdoor is used as a secure channel for copying all changes across as the system runs. 
  
 Furthermore, the Mirror Server is en exact copy of the main Blocks Server. All its settings and configurations are identical. The only difference between the two is which one has the Blocks license key. The license key controls which of the two computers that run Blocks. Apart from this difference, they're identical. Furthermore, the Mirror Server is en exact copy of the main Blocks Server. All its settings and configurations are identical. The only difference between the two is which one has the Blocks license key. The license key controls which of the two computers that run Blocks. Apart from this difference, they're identical.
Line 268: Line 268:
   * Server Disk Space. Indicates the amount of free space on the Blocks Server itself. This also makes sens to keep an eye on – especially before adding a significant amount of new content.   * Server Disk Space. Indicates the amount of free space on the Blocks Server itself. This also makes sens to keep an eye on – especially before adding a significant amount of new content.
   * Server Time. Shows the current time of the clock in the Blocks Server. If your server has Internet access, this is generally adjusted automatically. If not, you may want to check this every few monts to make sure that it is reasonably accurate.   * Server Time. Shows the current time of the clock in the Blocks Server. If your server has Internet access, this is generally adjusted automatically. If not, you may want to check this every few monts to make sure that it is reasonably accurate.
 +  * Sync Errors. Cumulative count of data sync errors that have occurred, if any. Check the Mirror log file for details.
  
-The SYNCHRONIZE NOW button can be used to force a full synchronization. Use this after making manual changes to the files in the /home/pixi-server directory of the Blocks server, such as updating Blocks itself or the mirroring service (the files PIXILAN.jar and MIRROR.jar respectvely). Doing so pushes those changes over to the Mirror Server immediately rather than waiting for the next scheduled full synchronization.+The "Synchtronize Now" button can be used to force a full synchronization. Use this after making manual changes to the files in the /home/pixi-server directory of the Blocks server, such as updating Blocks itself or the mirroring service (the files PIXILAN.jar and MIRROR.jar respectvely). Doing so pushes those changes over to the Mirror Server immediately rather than waiting for the next scheduled full synchronization.
  
 ===== Testing the Mirror Server ===== ===== Testing the Mirror Server =====
Line 328: Line 329:
   * Set java.util.logging.FileHandler.level to //ERROR// for less verbose logging, or //INFO// for more details (sometimes useful when troubleshooting).   * Set java.util.logging.FileHandler.level to //ERROR// for less verbose logging, or //INFO// for more details (sometimes useful when troubleshooting).
  
-The settings under //logging// follow the java.util.logging standard, sometimes referred to as JUL, allowing you to use any settings available there, for example to log to an external log handler.+The following additional, advanced settings are available in version 7.1 and later, then specified under the "mirror:" heading as shown above. 
  
 +<code>
 +  interface: enp2s0
 +  subnet: 192.168.0.0/24
 +</code>
  
-=====Troubleshooting===== +:!: **NOTE**: There are two spaces at the beginning of each line, as required when used under the "mirror:" heading.
-The server-to-server connection relies on that connection using self-assigned ("link local") addresses. Such adresses are in the 169.254.x.x address range. There must not be any other network interfaces in either computer having such IP addresses. If there are, make sure you disable any such interfaces, or change their address to keep them out of this address range. +
  
-Some server class computers have a built in remote management network interface that may then also appear in Linux, often with such a 169.254.x.x address. You may not be able to disable or change the address of such a network interface in Linux. Instead, you can disable this in the computer's remote management settings. Here's a screenshot giving and example of how this is done on a Supermicro server.+  * The //interface// setting is useful if your computer have more than one network interface with link local addressing. If so, use this setting to specify the name of the desired synchronization backdoor network interface. 
 +  * The //subnet// setting lets you specify a non link local subnet (in CIDR notation) for use as the data synchronization backdoor. This is useful in cases where you may want to use this interface for other purposes, such as remote management of the servers. You would then either set fixed addresses (within the specified subnet) or use dynamically assigned addresses (DHCP).
  
-{{ :blocks:server:mirror:disable-bmc-nic-for-host-os.png?direct&600 |}} 
  
 +The settings under //logging// follow the java.util.logging standard, sometimes referred to as JUL, allowing you to use any settings available there, for example to log to an external log handler.
 +
 +
 +=====Troubleshooting=====
 +Unless the advanced //subnet// setting is used (see above), the server-to-server backdoor connection assumes the use of self-assigned ("link local") addresses. Such adresses are in the 169.254.x.x address range. There must not be any additional network interfaces in either computer having such IP addresses. If there are, do either of the following:
 +  * Disable any such interface(s). in some cases this may need to be done in the computer's BIOS settings.
 +  * Change their addresses to keep them out of this address range.
 +  * Use the advanced //interface// setting to specify which interface to use. 
    
 === Verifying over SSH === === Verifying over SSH ===
Line 346: Line 358:
 </code> </code>
  
 +=== Custom path to Blocks' Executable Files ===
 +The Mirror service assumes that the main Blocks executable file (named "PIXILAN.jar") is located in /home/pixi-server/, which is the case if you're using our Linux server image. However, if you're configuring a server on your own and chose to locate Blocks executable files elsewhere, you must specify the directory where PIXILAN.jar resides using the BLOCKS_HOME envirtonment variable. This is an advanced configuration option, and is normally not required.
  
 =====Implementation Notes===== =====Implementation Notes=====