Tahoe-lafs looks interesting if one where locked to cloud storage. I'm planning to deal with storage on the local level, where a simple copy-on-write style system is sufficient. I don't anticipate needing the kind of security provided by Tahoe-lafs, so it seems like overkill to me.
As for HA-Proxy, that might be good for client requests to Zebra. The real problem is handling writes to Zebra. Using the queue table in the database would keep one copy up to date, but short of a copy-on-write system I have my doubts about being able to cluster Zebra. Even with a shared file system I expect Zebra tries to lock it's files, which would mean more than one Zebra server on the same directory of the same file system probably wouldn't work. ( I ran into that with Mysql in an earlier attempt at redundancy, and it corrupted many tables when both servers were access the same files at the same time. ) On Tue, Nov 8, 2016 at 2:11 AM, SUZUKI Arthur <arthur.suz...@univ-lyon3.fr> wrote: > Hi, > > For Zebra and Web-server, this could be a good use case for HA-Proxy. > > Never used this myself but I have read some documentations about how it > can be used to setup redundancy and/or load-balancing between servers for > applications that doesn't support this feature out-of the box. > > For file storage distributed across multiple nodes there is this newcomer > called Tahoe-LAFS : > > https://tahoe-lafs.org/trac/tahoe-lafs > > Hope this help your purpose. > > I have to say I've some interests into the question myself, don't hesitate > to share your results! > > Regards, > > Arthur > > > Le 07/11/2016 à 22:42, Galen Charlton a écrit : > >> Hi, >> >> On Mon, Nov 7, 2016 at 4:36 PM, Michael Hafen <michael.ha...@washk12.org> >> wrote: >> >>> Has anyone tried access Zebra through a network socket instead of the >>> unix >>> one? I was under the impression that that was possible. >>> >> It is, and it's as easy as changing the following lines in koha-conf.xml >> from: >> >> <listen id="biblioserver" >unix:/var/run/koha/SITE/bibliosocket</listen> >> <listen id="authorityserver" >unix:/var/run/koha/SITE/autho >> ritysocket</listen> >> >> to >> >> <listen id="biblioserver" >tcp:HOST_OR_IP:PORT</listen> >> <listen id="authorityserver" >tcp:HOST_OR_IP:ANOTHER_PORT</listen> >> >> Of course, depending on how you arrange things, local tweaks to the >> indexer jobs would be required to ensure that all of the copies of the >> Zebra databases got updated. >> >> Regards, >> >> Galen >> > > -- > Arthur SUZUKI > Service informatique des bibliothèques > BIBLIOTHÈQUES UNIVERSITAIRES > Université Jean Moulin Lyon 3 > 6 Cours Albert Thomas - B.P. 8242 – 69355 Lyon Cedex 08 > ligne directe : +33 (0)4 78 78 79 16 | http://bu.univ-lyon3.fr > L'Université Jean Moulin est membre fondateur de l'Université de Lyon > > > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Michael Hafen Washington County School District Technology Department Systems Analyst
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/