We’re hosting 20+ journals on a single multi-journal OJS3 instance. Since we’ve had some problems in the past we’re trying to reduce possible downtimes by breaking up one large instance into several smaller instances. In particular we want to avoid situations where the entirety of our journals is down for an extended period of time (e.g. in connection with an OJS update, problematic XML imports, failing plugins, problems with language packages, etc.). Our thinking is that by spreading our journals over several instances only a smaller subset would be affected should we run into problems. In addition this would facilitate OJS upgrades by allowing us to roll them out over a longer period of time.
Since the native import/export functionality doesn’t include any workflow information and comes with its own set of problems, we’ve had the idea of cloning our production instance several times and just deleting unneeded journals in the cloned instances until we reach a more manageable number in those clones. They would, however, run using the same OS, PHP, and DB software and in the same webcluster environment. What we’re wondering is this:
Has anyone in the community done something like this before? What have your experiences been?
Are there reasons that would render this idea entirely unfeasible?
Are there better strategies for improving stability that we’re not seeing?
This is a question that I have been thinking about for a long time and to which I would like to arrive at a universal answer… but I think that in the end it all depends on the context in which you are, the resources and your team preferences.
I will try to answer your questions quickly, but feel free to ask further is something is not clear enough:
1. Has anyone in the community done something like this before? What has been your experience?
Yes. There are several institutions that use the “single-tenant” (understood as “one ojs for each journal”) model.
I am writing to you from the UAB, where we have more than 50 journals with independent ojs since… more than 10 years ago.
We like this model because it corrects the problems you mention (and some others), but let me notice it is not without its drawbacks.
If I remember well, @ctgraham (form the University of Pittsburgh) moved to single recently, so I’m sure he can contribute from his experience.
Comment that there are also organizations that have opted for a mixed strategy (some journals in single and others in multi). Probably PKP services is the most relevant example here.
2. Are there any reasons that make this idea unfeasible?
No. The multi-tenant to single-tenant migration process that you describe is the one that most of us have followed because it allows us to preserve the history of the magazine. The structure of OJS is clear and that allows each journal to be easily isolated (files and database). I do not recommend any other mechanism, unless you don’t mind losing a lot of information about the life of the articles.
While that path (multi 2 single) is relatively easy to walk, it is important to note that the reverse path (single 2 multi) is NOT.
In other words, if you change to a single-tenant model it will be a difficult change to reverse.
3. Are there better strategies for improving stability that we are not seeing?
I can’t tell you in the multi-tenant context but in single, I think one way to improve stability is dockerizing your ojs.
That improves testing (container’s portability let you test migrations with an exact copy of your production service), its resilience (if a container falls, you restart it and mess up)
and it even offers some improvement in terms of security (the cages isolate the processes).
4. Any guidance would be appreciated.
Make a decision (single vs multi) and we will tell you here the steps to take.
But before this, although apparently the post is unrelated, I think this thread can be useful for you… specifically this table:
It’s quite obvious that I’m very convinced of the “single-tenant” model, so I think you also need to hear arguments of the ones that are happy with the ones that maintain large installations under a multi-tenant model (@ajnyga any comments about this?)