At the U.S. National Library of Medicine, we are working towards implementing
redundancy wherever possible in our production Fedora infrastructure. For
example, we are running multiple Fedoras, with multiple filesystems and
databases, across multiple data centers. The goal of this redundancy is to
improve overall system availability, as well as preservation and scalability.
Several weeks ago, we briefly presented on this topic at the recent Washington,
D.C. Area Fedora Users Meeting at the National Museum of the American Indian.
There seemed to be a lot of interest in this topic, and so we have placed this
presentation on the DuraSpace wiki at
https://wiki.duraspace.org/display/cmtygp/Solutions+Integration .
In our current architecture, we maintain two Fedoras at each of two data
centers. Each Fedora is supported by a full independent stack of managed
storage, database, resource index, Solr index, and application code, with
shared external storage of large items. Most of our code is based on Java, and
all application code associated with a single Fedora runs on a single Tomcat
with a separate database server. Off-site replication is accomplished via
existing storage system mirroring strategies to read-only filesystems. Wide
and local load-balancing and failover is implemented using commercial
components such as 3DNS and BIG-IP. We are looking into implementing MySQL
clustering for the database. System updates are accomplished by routing traffic
to one server while updating the other, to maintain availability. The existing
Fedora documentation regarding use of journaling to support replication and
mirroring is great, and we intend to explore this approach for replication
within the same data center once we upgrade our Fedoras.
We are evolving our ingest and maintenance workflows, and are interested to
hear about best practices and other experiences in how organizations have
implemented redundancy within their own systems in the context of operating and
maintaining a production Fedora repository. Questions of particular interest
include:
How many instances of Fedora do you use?
Which system components are located with Fedora on the same container, and
which components are located on other containers or servers?
How are content updates replicated across servers and data centers?
How is load-balancing and failover implemented across servers and data centers?
Are any components clustered, and how is the clustering accomplished?
How often do you perform backups, and what is the backup mechanism?
Many architecture considerations are specific to each organization and may not
translate well to other organizations, but we are still interested to hear
about how others are approaching these issues. If there is enough interest and
feedback, perhaps some space on the wiki could be carved out to capture these
ideas and illustrate some working examples for everyone.
Thanks!
-Doron
_________________________
Doron Shalvi
NLM Digital Collections
http://collections.nlm.nih.gov
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
Fedora-commons-users mailing list
Fedora-commons-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
