rafacorre
By:
rafacorre

Update the droplets in the load balance

March 10, 2017 744 views
Load Balancing Deployment Ubuntu 16.04

How do I keep all servers with the same content?

I have 3 droplets and I thought of copying the contents of the first one to the other 2.
Is there any option that does this automatically?

I researched and did not find it, so I was thinking of doing it with scp just by copying the contents of the web server.

2 comments
  • So is it flat files, databases or ?
    If it's databases, then you want master-master replication like MariaDB Galera.
    If it's flat files, then it depends on how important the lag is. So if it needs to be real time use something like GlusterFS. If a few seconds delay is okay, then Syncthing or rsync might be a solution.

  • Hi @hansen, thakyou very much!
    I thought of replicating only the files, I did not know this option of MariaDB Galera.
    I was thinking of doing something similar to what I saw on Amazon, I wanted to leave the database and the images in separate locations of the web server.

    And then I would replicate the files from this server to other droplets.
    I will test Syncthing and rsync also to see which of these options meet my needs.

2 Answers

@rafacorre

If you want something relatively simple, I'd recommend using lsyncd.

https://www.digitalocean.com/community/tutorials/how-to-mirror-local-and-remote-directories-on-a-vps-with-lsyncd

Without going the storage-only Droplet route where you'd deploy Droplets with Block Storage and use something such as GlusterFS, MooseFS, or XtremeFS, lsyncd is going to be the easiest.

That said, when it comes to bi-directional syncing or x-directional, depending on how many servers are at play now and in the future, you'd need to set it up on each of the Droplets.

So something such as:

Droplet01 syncs to Droplet02 + Droplet03
Droplet02 syncs to Droplet01 + Droplet03
Droplet03 syncs to Droplet01 + Droplet02

It can be a little tricky, so take your time. The guide I've linked to covers setting up one server, so what you'd do is simply replicate that and change the destinations.

To avoid having to setup so much syncing across servers, you'd most likely need to setup something a little more advanced. I tried GlusterFS on my end and it's a major pain. Setting up 4x storage-only Droplets with 100GB Block Storage worked without any issues, though when it came to fail-over, GlusterFS failed majorly.

Supposedly, it's supposed to be aware of the other servers in the cluster, though each time I brought down the primary, it dropped the mount and failed to remount one of the backup devices.

I even reached out to DO's support team for help on this one as my experience with GFS is limited, though even they couldn't make heads or tails of the rather cryptic error messages that resulted.

by Justin Ellingwood
While administrating web and application servers, there are many times when it is useful to mirror directories. The lsyncd service can mirror local and remote directories in order to propagate changes from one location to another. This guide will cover the basic usage of this tool.

@rafacorre

The configuration file for lsyncd would look something like this for multiple servers. The following is an example of what you'd use on the "master" server, or the primary.

/etc/lsyncd/lsyncd.conf.lua
settings = {
    logfile = "/var/log/lsyncd/lsyncd.log",
    statusFile = "/var/log/lsyncd/lsyncd.status"
}

targetlist = {
    "root@DROPLET_IP_02:/path/to/data",
    "root@DROPLET_IP_03:/path/to/data"
}

for _, server in ipairs( targetlist ) do
    sync {
        default.rsync,
        source = "/path/to/data",
        target = server,
        rsync = {
            rsh = "ssh -i ~/.ssh/id_rsa"
        }
    }
end

In the above:

DROPLET_IP_02 and DROPLET_IP_03 would be the IP's or Hostnames of the Droplets that you'd be mirroring data to.

/path/to/data under targetlist would be the path where all content to be mirrored.

/path/to/data under source is the path to where the data to be mirror exists.

rsh = "ssh -i ~/.ssh/id_rsa" would need to be changed to the location of the private key that you'll be using to login to the other servers.

...

If the source and destination are both the same (as would be the case in most configurations), then you'd just change /path/to/data to be the same in all three instances.

...

As an important note, you will need to use ssh-copy-id or physically login to the servers from one another to get the initial setup done. If you don't, the connection will fail as initial authentication has to be done first.

...

I just tested the above configuration using a DigitalOcean LB and 3x 1GB Droplets and it does work, though I've not setup multi-directional syncing just yet. To do this, the same configuration would essentially exist on each server with lsyncd installed on each.

You would need to change the root@DROPLET_IP to make sure each sever syncs to the correct server and that ~/.ssh/id_rsa is correctly set for each one as well.

  • @rafacorre

    As a follow-up on lsyncd, this will work with multiple servers.

    The above configuration is valid and will sync across multiple servers, though when one of the servers is brought down (thus removed from the LB) and then brought back online, it seems to delete the file(s) uploaded to the other servers, which is what I'm trying to figure a way around right now.

    So as far as using this in production, we'd need to find a way to prevent new file deletion when one of the Droplets is put back online, otherwise it's problematic since we don't want new files to be deleted -- we want the sync to continue -- else you'll end up losing more than just deleted files.

    • Thank you very much, your answers gave me a direction!
      I took a look at the documentation and tutorials from GlusterFS and lsyncd.
      Although it seems to be more difficult, I'm going to test GlusterFS first and if it fails or it's too complicated I'm going to go to lsyncd.

      I want to replicate the / var / www files from my server and maybe the apache virtualhosts as well.

      • @rafacorre

        The biggest issue I ran in to with GlusterFS was that it didn't fail over as intended. So if I brought down the master, even though the other two were perfectly fine, it would never fail over and "pick up" where it should have. To me, that's an issue as it makes it totally unreliable.

        If you happen to get failover working, please feel free to share what you've found as I spent about a week trying to get it to work, only to drop it entirely. Without failover, it's not reliable enough for me to count on.

    • Thank you very much, your answers gave me a direction!
      I took a look at the documentation and tutorials from GlusterFS and lsyncd.
      Although it seems to be more difficult, I'm going to test GlusterFS first and if it fails or it's too complicated I'm going to go to lsyncd.

      I want to replicate the / var / www files from my server and maybe the apache virtualhosts as well.

Have another answer? Share your knowledge.