Has anyone tried putting Moodle on a server 18 times (1 for each department) with the matching 18 databases.
If yes was it successful? If not what is the greatest number of installs that work properly?
Are we mad to even contemplate it?
Many thanks
Heather
How many Moodles / databases on one server
Number of replies: 18Re: How many Moodles / databases on one server
Yes - 32 Moodles for about 7000 users at the last count. No problem.
It really has almost nothing to do with the number of Moodles or databases. It's the *total* load on the system that matters. By having multiple moodles you are just spreading the load about. It all takes up a bit more disc space and makes upgrading a pain, but apart from that absolutely fine!
It really has almost nothing to do with the number of Moodles or databases. It's the *total* load on the system that matters. By having multiple moodles you are just spreading the load about. It all takes up a bit more disc space and makes upgrading a pain, but apart from that absolutely fine!
Re: How many Moodles / databases on one server
I want to confirm what Howard just said: you can have as many Moodles on one server as you like and only once your users start to use them really heavily should you start spreading them over more servers. Upgrading many Moodles also is not too bad, especially if you use CVS. I assume you have sorted out some central sign-on mechanism? Otherwise users associated to several departments might find your setup a bit tedious if it requires them to type in a password repeatedly.
Re: How many Moodles / databases on one server
No, we have no central sign-on mechanism sorted, we were going to be cruel and make them keep entering their password - we are using LDAP. To be honest I hadn't even considered it as a possibility that you could log on once to multiple different installs of Moodle. If you can point me towards a useful forum thread on that aspect it would be much appreciated.
Thanks for the advice on usage. Howard's comment was reassuring as we are relatively new to Moodle and are thus unsure of what you can and cannot do with it. I think we will go with the suck it and see and when usage becomes heavy worry about finding some extra hardware then.
Re: How many Moodles / databases on one server
I would certainly give the LDAP a try if you have it anyway. There are a lot of settings on the LDAP page, but the basics are quite straightforward. It simply prevents students having to register on every Moodle they use (not single sign-on as such) - well it does if the LDAP server has the basic information stored in it (Name, Email etc).
Re: How many Moodles / databases on one server
This discussion assumes an American-style university system though. What about a system where specific students take courses within only one faculty or school? In that case the ability to customize the particular Moodle to suit that school's need might be a plus. And the issue of multiple log-ins wouldn't be a problem.
Re: How many Moodles / databases on one server
Sure you could do this, Moodle scalability is more related to the total number of users on the server at a given time than the number of Moodles on the server.
But why would you do that? It seems like it would be pretty nightmarish from a support perspective to have all those duplicated users as well as when you do upgrades. I'd really suggest just putting them all into one Moodle with 18 course categories, one for each dept. I know our students would come and get me if I tried to make them login separately for each department
.
If you want a custom theme for each dept, in Moodle 1.5 you can do this by making a template for each dept. with a forced theme and then creating the courses for each dept. from their template.
This could also be automated with a bit of work. What SIS are you folks using?
But why would you do that? It seems like it would be pretty nightmarish from a support perspective to have all those duplicated users as well as when you do upgrades. I'd really suggest just putting them all into one Moodle with 18 course categories, one for each dept. I know our students would come and get me if I tried to make them login separately for each department
.If you want a custom theme for each dept, in Moodle 1.5 you can do this by making a template for each dept. with a forced theme and then creating the courses for each dept. from their template.
This could also be automated with a bit of work. What SIS are you folks using?
Re: How many Moodles / databases on one server
Bad experience in the past with a VLE that could only list courses alphabetically. With 18 departments and probably 18 courses in each department plus the NLN courses (which have now gone up to 1000 or so) trying to find the course you wanted from ths nightmarish (particularly when at least a third started with BTEC) list made us want to break it into lots of smaller pieces.
Also from past experience the bigger the database, i.e. the more courses / the more people etc. the slower the overall system; again giving us a reason to break into smaller chunks. Is this true of Moodle or just our past VLE?
We were also thinking that one server may not handle all the users in the long term, but one server per department seemed excessive so how many could you put on a server hence the original question.
Currently we are only on version 1.4.4 so the customisation which we are hoping to use is only available by having separate installs.
What does SIS stand for? If you mean MIS (Management Information System) we are on QL.
As we are still in the throws of deciding what to do we are open to suggestion and happy to take on board other peoples' experiences particulary successful experiences, but if you can stop us falling into some huge fatal trap please do.
Many thanks
Re: How many Moodles / databases on one server
Hi Heather, how many students do you have? We have >10,000 in our system (dual 2.8 P4, 3Gb of RAM and RedHat Enterprise), and performance is fine. I thnk you should be ok with a single Moodle, if you plan to have >10,000 students you may want to put the database on one server and apache/php on the other.
I don't think that splitting your Moodle's up on the same server will help much if any with performance.
For a University sized system I would really suggest talking with your MIS admin and seeing if you can't get a text file exported with enrollment data rather than having the students pick their classes from a list. If you can get a text file in the Moodle import format you can just upload this nightly to enroll students in courses, that is what we did here and it didn't take much time to get set up (a few minutes for our Banner admin to build the SQL query and a then a few hours to build and test the script that runs it).
Our Moodle admin gets an email every morning with the new users/enrollments and uploads it to Moodle, then the students are enrolled in their courses automatically, which saves a good deal of student and support staff time in the long run.
In the next iteration, we're going to fully automate the enrollment process by setting all the courses up and enrolling all the students automatically on a nightly basis. We'll set the courses up but have them hidden so that if a faculty wants to teach a moodle course all they have to do is unhide it (and we'll make a simple form for this also
.
We've found Moodle quite quick on db queries and the Martins keep making it faster, so I don't think this will be a problem. However hardware is cheap while faculty and staff time is expensive so we've found it better to make the system work a bit harder so the people don't have too.
I don't think that splitting your Moodle's up on the same server will help much if any with performance.
For a University sized system I would really suggest talking with your MIS admin and seeing if you can't get a text file exported with enrollment data rather than having the students pick their classes from a list. If you can get a text file in the Moodle import format you can just upload this nightly to enroll students in courses, that is what we did here and it didn't take much time to get set up (a few minutes for our Banner admin to build the SQL query and a then a few hours to build and test the script that runs it).
Our Moodle admin gets an email every morning with the new users/enrollments and uploads it to Moodle, then the students are enrolled in their courses automatically, which saves a good deal of student and support staff time in the long run.
In the next iteration, we're going to fully automate the enrollment process by setting all the courses up and enrolling all the students automatically on a nightly basis. We'll set the courses up but have them hidden so that if a faculty wants to teach a moodle course all they have to do is unhide it (and we'll make a simple form for this also
We've found Moodle quite quick on db queries and the Martins keep making it faster, so I don't think this will be a problem. However hardware is cheap while faculty and staff time is expensive so we've found it better to make the system work a bit harder so the people don't have too
Re: How many Moodles / databases on one server
Michael, btw, are you using a php accelerator? I've noticed that even a plain vanilla php can take quite a few hits
Re: How many Moodles / databases on one server
With all due respect to Michael Pinney and Bob Bouford (hey Bob, remember me!),
I'm with Heather on this one. What's wrong with running mulitple instances of
Moodle, one per department?
My deployment would have a DNS name for each departments Moodle instance. Like this: physics.courses.myuni.edu, math.courses.myuni.edu, english.courses.myuni.edu. Now, maybe this seems like a lot of URLs for
the students to remember.... Fine, put up another site for the students
to 1st come to, courses.myuni.edu would work.
On this site you could have static HTML, we don't change departments all that often now do we?
Yes, I understand that one COULD setup a single Moodle server to run
this entire thing. But, if you EVER needed to scale up, your only choice
would be to by a larger computer and take a far sized outage to move the entire
system over.
If, on the other hand, you had this divided up per department, you could move just a few of the departments, or maybe just the one that is very active, onto another server. Now we are using 2 servers. Note in the model of the single server you are going to be left with a box that is idle when you move to a new, bigger server.
Running this way, one could use "any old computer" that was capable of running Moodle. You would need to go out and buy the latest and greatest. It's not all the hard to set up a Moodle server. Some care would need to be taken in naming convensions on setting up these multiple Moodle servers. It's not all that hard to move the Moodle servers around, again some care would be needed in moving the data around.
One potentially attractive option for a small college would be to use a Web Hosting service provider. Maybe contracting with someone "out there" to help with the setup. This would relive you from having to worry about the 7x24 server environment. You could do this either at the entire campus or per department as I describe above.
The thing about the performance, is you don't actually know where it's going to end up and you could be surprized by some single very active course. That's one of the lessons we have learned. You will typically see the highest load either at the start or the end of the semester. If you load peaks out, you will be scrambling. Having a plan to move some of the load to separate boxes in a "firedrill mode" is a good idea!
I'm with Heather on this one. What's wrong with running mulitple instances of
Moodle, one per department?
My deployment would have a DNS name for each departments Moodle instance. Like this: physics.courses.myuni.edu, math.courses.myuni.edu, english.courses.myuni.edu. Now, maybe this seems like a lot of URLs for
the students to remember.... Fine, put up another site for the students
to 1st come to, courses.myuni.edu would work.
On this site you could have static HTML, we don't change departments all that often now do we?
Yes, I understand that one COULD setup a single Moodle server to run
this entire thing. But, if you EVER needed to scale up, your only choice
would be to by a larger computer and take a far sized outage to move the entire
system over.
If, on the other hand, you had this divided up per department, you could move just a few of the departments, or maybe just the one that is very active, onto another server. Now we are using 2 servers. Note in the model of the single server you are going to be left with a box that is idle when you move to a new, bigger server.
Running this way, one could use "any old computer" that was capable of running Moodle. You would need to go out and buy the latest and greatest. It's not all the hard to set up a Moodle server. Some care would need to be taken in naming convensions on setting up these multiple Moodle servers. It's not all that hard to move the Moodle servers around, again some care would be needed in moving the data around.
One potentially attractive option for a small college would be to use a Web Hosting service provider. Maybe contracting with someone "out there" to help with the setup. This would relive you from having to worry about the 7x24 server environment. You could do this either at the entire campus or per department as I describe above.
The thing about the performance, is you don't actually know where it's going to end up and you could be surprized by some single very active course. That's one of the lessons we have learned. You will typically see the highest load either at the start or the end of the semester. If you load peaks out, you will be scrambling. Having a plan to move some of the load to separate boxes in a "firedrill mode" is a good idea!
Re: How many Moodles / databases on one server
What's wrong with running mulitple instances of Moodle, one per department?
If you have single sign-on set up it's not so bad. But I think it will result in very high support costs (or student/faculty frustration) if you don't. The most common support issue here on either Blackboard or Moodle is student/faculty forgets password.
With a single system (or single sign-on) it's easy enough to fix. With multiple instances, it will be a real pain. It didn't sound like Heather's shop was going to set-up single sign-on, but rather have students self register and self enroll. This would probably result in alot of folks with a different password in different departments.
I do still think it's more efficient to scale by clustering if your max user load is not going to saturate the db server. From a user support perspective students (and faculty) often have a hard enough time telling what server they are on, so I'm not real excited about trying to help them figure out which server they are on before I can start to help them with their problem.
N Hansen was right, though, I was assuming the US model with students in multiple departments. If students are in one department only, then it isn't such a big deal.
If you have single sign-on set up it's not so bad. But I think it will result in very high support costs (or student/faculty frustration) if you don't. The most common support issue here on either Blackboard or Moodle is student/faculty forgets password.
With a single system (or single sign-on) it's easy enough to fix. With multiple instances, it will be a real pain. It didn't sound like Heather's shop was going to set-up single sign-on, but rather have students self register and self enroll. This would probably result in alot of folks with a different password in different departments.
I do still think it's more efficient to scale by clustering if your max user load is not going to saturate the db server. From a user support perspective students (and faculty) often have a hard enough time telling what server they are on, so I'm not real excited about trying to help them figure out which server they are on before I can start to help them with their problem.
N Hansen was right, though, I was assuming the US model with students in multiple departments. If students are in one department only, then it isn't such a big deal.
Re: How many Moodles / databases on one server
I'm not letting go of this, Michael
Yes, SSO is a requirement if you have one per dept. Actually, that's
an assumption I'm making for pretty much ANY institution, not merely
large ones. Password management is the #1 support issue, and it's been
#1 on the hit parade since we started with WebCT in 98.
What folks really want is the same password for all the IT services.
Me too, my 50 something brain tends to have middle aged moments
on password
In terms of figuring out where students and faculty are "at", don't you
just ask them which course they are looking at, not which server/URL?
Even with a single server, you can be confused as to where you are at.
We tend to have support email that says "I'm in course xxx".
If you have a cluster, you don't know which server the user is on, since these get picked by some randomizing algorithm, and you have to go to some fancy place to figure that out in the bowels of the server.
I don't think it's so bad to run multiple instances of whatever. In 98,
we immediately setup several instances of WebCT, one per UW campus,
all on the same Sun server. We'd didn't ask WebCT support how to do this,
we just figured it out. Not a biggie. Moodle already has this figured out,
from the installation side. The costs of setup don't look so bad.
In terms of scaling, I really don't like the "big box" approach. (This is where I'm not letting go, Michael, and we may just need to agree to disagree).
This is putting all your eggs in one basket. The risks are higher here,
even with a cluster. It's also hard to schedule outages for upgrades.
Now, what's also at play here is that pretty much anyone can setup a Moodle server on a cast about computer. That means someone could just pop up and run
a Moodle server, if they don't like how central IT is doing it. All they are missing is the SSO and the student rosters. On our campus, they could even do the SSO (WebISO), that need not be centrally hosted. And they get the rosters from the data warehouse, with a 1 day delay. While this is some manual setup and manual futzing for the rosters, if you are motivated enough and have 1 smart student worker, you could get there. I suspect the same conditions will hold true at other universities.
We also are seeing smaller colleges and 2 years slap up Moodle servers. If you are a 2000 student campus, you could likely get by with a single or dual server (db separate) setup. No big deal. As I understand it, there is a bit of a groundswell
going on in FE in UK with Moodle. These are not IT rich places.
What I fear is that we will see Moodle split into 2 products, one for the small places and one for the large "enterprises". There are some features that will be added for the larger places, as you need to go hierarchical for the larger places. Features that are just not needed for a small place. Fine, I say, then let the larger installations mimic the small ones, and add on OUTSIDE of the core Moodle the features needed to support a hierarchy.
From a deep technical support perspective, if you have to figure out what's up, I'd much rather look at a smallish system than a large one. Put another way, what's harder to deal with, 10 things that all are relatively simple with a small amount of data or 1 thing with more complexity and more data. That's easy, it's the 10 small things. When I'm troubleshooting, it will be in the context (mostly, this is our support trend) of a single course. Fine, figure out which instance of Moodle that's on and look around, that's going to be easier with less data in the DB and less courses.
Well, that's enough for now. I do appreciate that one could run a large, single installation of Moodle. I've been involve with doing this, both with course management systems and with portals (not to mention some commercial products where I was staff for the vendor), and this has some merit. What I'm doing here is exploring a different model of deployment, one that I think is relatively unexplored due to the lack of open source products.
Yes, SSO is a requirement if you have one per dept. Actually, that's
an assumption I'm making for pretty much ANY institution, not merely
large ones. Password management is the #1 support issue, and it's been
#1 on the hit parade since we started with WebCT in 98.
What folks really want is the same password for all the IT services.
Me too, my 50 something brain tends to have middle aged moments
on password
In terms of figuring out where students and faculty are "at", don't you
just ask them which course they are looking at, not which server/URL?
Even with a single server, you can be confused as to where you are at.
We tend to have support email that says "I'm in course xxx".
If you have a cluster, you don't know which server the user is on, since these get picked by some randomizing algorithm, and you have to go to some fancy place to figure that out in the bowels of the server.
I don't think it's so bad to run multiple instances of whatever. In 98,
we immediately setup several instances of WebCT, one per UW campus,
all on the same Sun server. We'd didn't ask WebCT support how to do this,
we just figured it out. Not a biggie. Moodle already has this figured out,
from the installation side. The costs of setup don't look so bad.
In terms of scaling, I really don't like the "big box" approach. (This is where I'm not letting go, Michael, and we may just need to agree to disagree).
This is putting all your eggs in one basket. The risks are higher here,
even with a cluster. It's also hard to schedule outages for upgrades.
Now, what's also at play here is that pretty much anyone can setup a Moodle server on a cast about computer. That means someone could just pop up and run
a Moodle server, if they don't like how central IT is doing it. All they are missing is the SSO and the student rosters. On our campus, they could even do the SSO (WebISO), that need not be centrally hosted. And they get the rosters from the data warehouse, with a 1 day delay. While this is some manual setup and manual futzing for the rosters, if you are motivated enough and have 1 smart student worker, you could get there. I suspect the same conditions will hold true at other universities.
We also are seeing smaller colleges and 2 years slap up Moodle servers. If you are a 2000 student campus, you could likely get by with a single or dual server (db separate) setup. No big deal. As I understand it, there is a bit of a groundswell
going on in FE in UK with Moodle. These are not IT rich places.
What I fear is that we will see Moodle split into 2 products, one for the small places and one for the large "enterprises". There are some features that will be added for the larger places, as you need to go hierarchical for the larger places. Features that are just not needed for a small place. Fine, I say, then let the larger installations mimic the small ones, and add on OUTSIDE of the core Moodle the features needed to support a hierarchy.
From a deep technical support perspective, if you have to figure out what's up, I'd much rather look at a smallish system than a large one. Put another way, what's harder to deal with, 10 things that all are relatively simple with a small amount of data or 1 thing with more complexity and more data. That's easy, it's the 10 small things. When I'm troubleshooting, it will be in the context (mostly, this is our support trend) of a single course. Fine, figure out which instance of Moodle that's on and look around, that's going to be easier with less data in the DB and less courses.
Well, that's enough for now. I do appreciate that one could run a large, single installation of Moodle. I've been involve with doing this, both with course management systems and with portals (not to mention some commercial products where I was staff for the vendor), and this has some merit. What I'm doing here is exploring a different model of deployment, one that I think is relatively unexplored due to the lack of open source products.
Re: How many Moodles / databases on one server
In terms of figuring out where students and faculty are "at", don't you
just ask them which course they are looking at, not which server/URL?
Yep, which is why it is great to have all the courses on one server. With two LMS' , we currently have problems with folks who think their one BB but are on Moodle, or vice versa. And those are pretty different looking servers. With multiple moodle servers, we'd have cases with students on the English Dept. server trying to find their Math classes, etc.
Now if we had a portal system it might work better, or a shared "MyCourses" among servers. But we don't have a portal system yet here.
We also do a good deal of phone support, so it's not just a matter of reading the email headers to see where they are coming from.
This is putting all your eggs in one basket. The risks are higher here,
even with a cluster. It's also hard to schedule outages for upgrades.
Hmm, I have the opposite opinion: if one box in the cluster goes down, the cluster is still up. There is a slow down (a slight one if you have excess capacity) and that is all. For our planned cluster we'll have 3 servers, though we only need two to handle our usual peak load (few hundred taking a test or checking grades at the exact same time). That way we can scale for temporary super-peak loads and have a box for failover, so the only downtime is planned.
To reach this level for each of our 3 colleges we would need at least 6 servers (we have 42 depts., not going there).
With upgrades, I'd rather have one server down for a few hours than 3.
What I fear is that we will see Moodle split into 2 products, one for the small places and one for the large "enterprises".
Where do you see evidence of this? The 'enterprise' code from NZVLE that facilitates clustering and tunes db queries make Moodle also run faster for small installs. Enterprise things like batch backup, batch restore, more complete administration tools, seems to me will make Moodle easier to admin if you have five classes or 1000.
What enterprise tools do you see being added that would make Moodle less usable for small installations or organizational units?
what's harder to deal with, 10 things that all are relatively simple with a small amount of data or 1 thing with more complexity and more data. That's easy, it's the 10 small things.
Actually, for me I'd much rather deal with one large, complex problem than 10 little ones, I've found that often the 10 little problems are part of a large problem the full scope of whcih isn't apparent yet.
just ask them which course they are looking at, not which server/URL?
Yep, which is why it is great to have all the courses on one server. With two LMS' , we currently have problems with folks who think their one BB but are on Moodle, or vice versa. And those are pretty different looking servers. With multiple moodle servers, we'd have cases with students on the English Dept. server trying to find their Math classes, etc.
Now if we had a portal system it might work better, or a shared "MyCourses" among servers. But we don't have a portal system yet here.
We also do a good deal of phone support, so it's not just a matter of reading the email headers to see where they are coming from.
This is putting all your eggs in one basket. The risks are higher here,
even with a cluster. It's also hard to schedule outages for upgrades.
Hmm, I have the opposite opinion: if one box in the cluster goes down, the cluster is still up. There is a slow down (a slight one if you have excess capacity) and that is all. For our planned cluster we'll have 3 servers, though we only need two to handle our usual peak load (few hundred taking a test or checking grades at the exact same time). That way we can scale for temporary super-peak loads and have a box for failover, so the only downtime is planned.
To reach this level for each of our 3 colleges we would need at least 6 servers (we have 42 depts., not going there).
With upgrades, I'd rather have one server down for a few hours than 3.
What I fear is that we will see Moodle split into 2 products, one for the small places and one for the large "enterprises".
Where do you see evidence of this? The 'enterprise' code from NZVLE that facilitates clustering and tunes db queries make Moodle also run faster for small installs. Enterprise things like batch backup, batch restore, more complete administration tools, seems to me will make Moodle easier to admin if you have five classes or 1000.
What enterprise tools do you see being added that would make Moodle less usable for small installations or organizational units?
what's harder to deal with, 10 things that all are relatively simple with a small amount of data or 1 thing with more complexity and more data. That's easy, it's the 10 small things.
Actually, for me I'd much rather deal with one large, complex problem than 10 little ones, I've found that often the 10 little problems are part of a large problem the full scope of whcih isn't apparent yet
Re: How many Moodles / databases on one server
Hi and thank you to everyone.
Just to confirm we are a UK education establishment in the FE sector so crossing departments is probably less of an issue to us although some things are pertinent to everyone and thus cross over.
I think what I have gleaned so far is that keeping usernames / passwords constant no matter how many Moodles we have is a definite must and using LDAP (pointing at Active directory) should address this issue. If I can get exports from Central information systems in the right format I can import to Moodle and thus cut down on manual labour from an admin perspective and potential confusion from the student perspective.
If I split my departments one per Moodle I can make some gains on the one hand but some losses on the other. Alternatively I could put them all in the one Moodle and again make some gains on the one hand and some losses on the other. A third alternative is to do a combination of the two; instead of one giant Moodle or 18 tiny ones I could have 3 sort of Middle of the road. The information you have all provided is great as it seems to indicate that whatever I can think of has already been tried and that no one way is correct for everyone, always reassuring.
Again Many thanks.
Re: How many Moodles / databases on one server
At the end of the day, Gustav has said it all. 
Re: How many Moodles / databases on one server
What's wrong with running mulitple instances of Moodle, one per department?
I assume that the institution has a central IT team, and central accounting, SMS, etc. If those things are per-department, then Moodle should follow suit.
With that out of the way, the second assumption is that for a large institution, you need good sysadmins and a good understanding of Moodle. If you don't have that know-how handy (in-house or a responsive contractor) you are in trouble.
With distributed Moodles, the initial setup is easier, and you can get away with it, even if you don't tune your setup. You';ve successfully broken the problem down into smaller pieces, and each piece is simpler.
When the time comes to glue the pieces together, however, the problem is way more complex. And this covers user-facing aspects such as SSO, and also a reasonably coordinated management of users, courses, marks, stats, etc. Version management is also a pain, with customizations, upstream releases and the corresponding merges multiplied several times. And chances are that your "integration" strategies depend on specific versions of Moodle and the corresponding customizations.
And if you made any serious strategic mistakes at the outset, you will have a serious problem in your hand, with all your user data already in the system(s).
A single Moodle install is trickier to setup and tune initially. It also forces all the hard, strategic decisions to be made early. It also limits how custom-crazy each department can get. And this is a good, good thing.
It will keep you from managing a dozen customized Moodles, remerging customizations for every Moodle release. From tearing your hair out when some departments are ready to upgrade and others aren't, and your user account sync scripts (SSO, etc) have weird effects when used across versions.
(In a sense, this is the job we do at Catalyst, keeping many custom Moodles in tune with the latest Moodle release. It's tricky. We use CVS and Arch and now cogito to help us get through and merge the right thing in the right place. It is fun, but it takes a lot of work, and a damned good understanding of the codebase.)
In the long-term, and given that Moodle scales well (and getting better), the single install has a lower cost of ownership.
Re: How many Moodles / databases on one server
Hi Dirk,
Yes, very well. Good to see you again. Michael, you have you hands full keeping up with Dirk. 
In looking at the discussion I think it will ultimately depend on Heather's situation at her instititution. With stronger linkages to external authentication systems (LDAP, Kerberos, etc), the issue of supporting student/faculty with login IDs and passwords is much less than we used to experience with earlier multiple installations of other CMSs.
At least one advantage of a distributed Moodle system is if one system goes down or connectivity is lost to one system, one doesn't lose everything as currently found in a single installation.
Cheers,
Bob
Re: How many Moodles / databases on one server
Heather,
I'll concur with Michael that a single Moodle instance with 18 department categories is much better than 18 separate Moodle instances.
You are basically repeating the hard lesson learned by many early WebCT institutions where different departments (colleges, institutes, schools, faculties, campuses, etc) within the institution (university) had their own WebCT server. Even with external authentication, it was still a management nightmare and generated an infinite number of complaints from students due to the different server addresses. Then there was the nightmare of consolidation that became necessary.
Best to avoid the nightmare before you go too far down an old path.
Cheers,
Bob