I've had some luck putting a load balancer infront of multiple zones to get around the multiple URL issue. You can get the LB to send POST/DELETE et al to the primary zone, but GET requests can be distributed to multiple zones. The only issue is the replication delay; your data may not be available on the secondary for reading yet...
I'm pretty sure you can most LB's to check multiple zones for the object existing when doing a GET, and redirect to the primary if replication hasn't caught up; for what I was looking at, I didn't need this! Dave On Tue, Oct 7, 2014 at 1:33 AM, Craig Lewis <cle...@centraldesktop.com> wrote: > This sounds doable, with a few caveats. > > > Currently, replication is only one direction. You can only write to the > primary zone, and you can read from the primary or secondary zones. A > cluster can have many zones on it. > > I'm thinking your setup would be a star topology. Each telescope will be > a primary zone, and replicate to a secondary zone in the main storage > cluster. The main cluster will have one read-only secondary zone for each > telescope. If you have other needs to write data to the main cluster, you > can create another zone that only exists on the main cluster (possibly > replicated to one of the telescopes with a good network connection). > > Each zone has it's own URL (primary and secondary), so you'd have a bit of > management problem remembering to use the correct URL. The URLs can be > whatever. Convention follow's Amazon's naming scheme, but you'd probably > want to create your own scheme, something like > http://telescope_name-site.inasan.ru/ and > http://telescope_name-campus.inasan.ru/ > > > You might have some problems with the replication if your VPN connections > aren't stable. The replication agent isn't very tolerant of cluster > problem, so I suspect (but haven't tested) that long VPN outages will need > a replication agent restart. For sites that don't have permanent > connections, just make the replication agent startup and shutdown part of > the connection startup and shutdown process. Replication state is > available via a REST api, so it can be monitored. > > > I have tested large backlogs in replication. When I initially imported my > data, I deliberately imported faster than I had bandwidth to replicate. At > one point, my secondary cluster was ~10 million objects, and ~10TB behind > the primary cluster. It eventually caught up, but the process doesn't > handle stops and restarts well. Restarting the replication while it was > dealing with the backlog will start from the beginning of the backlog. > This can be a problem if your backlog is so large that it won't finish in a > day, because log rotation will restart the replication agent. If that's > something you think might be a problem, I have some strategies to deal with > it, but they're manual and hacky. > > > Does that sound feasible? > > > On Mon, Oct 6, 2014 at 5:42 AM, Pavel V. Kaygorodov <pa...@inasan.ru> > wrote: > >> Hi! >> >> Our institute now planning to deploy a set of robotic telescopes across a >> country. >> Most of the telescopes will have low bandwidth and high latency, or even >> not permanent internet connectivity. >> I think, we can set up synchronization of observational data with ceph, >> using federated gateways: >> >> 1. The main big storage ceph cluster will be set up in our institute main >> building >> 2. The small ceph clusters will be set up near each telescope, to store >> only the data from local telescope >> 3. VPN tunnels will be set up from each telescope site to our institute >> 4. Federated gateways mechanism will do all the magic to synchronize data >> >> Is this a realistic plan? >> What problems we can meet with this setup? >> >> Thanks in advance, >> Pavel. >> >> _______________________________________________ >> ceph-users mailing list >> ceph-users@lists.ceph.com >> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com >> > > > _______________________________________________ > ceph-users mailing list > ceph-users@lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > >
_______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
