1 / 9

Academic Servers Infrastructure

Academic Servers Infrastructure. Distance Education: moodle.dyc.edu (2) ddl.dyc.edu project.dyc.edu (http://*.dl.dyc.edu) [backup systems] Institutional Reseach: survey.dyc.edu IT Dept: multiple servers. Hodgepodge growth. Added services and servers ad hoc.

becca
Download Presentation

Academic Servers Infrastructure

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Academic Servers Infrastructure Distance Education: moodle.dyc.edu (2) ddl.dyc.edu project.dyc.edu (http://*.dl.dyc.edu) [backup systems] Institutional Reseach: survey.dyc.edu IT Dept: multiple servers

  2. Hodgepodge growth Added services and servers ad hoc. This worked until things grew too quickly: bb4 – stable/scalable (php/mysql) ~same tech as moodle bb6 – unstable/scalable (tomcat/o8) bb9 – unstable/unscalable (tomcat/so) Early decisions committed us to be backed into a corner

  3. Planning Consideration – Part 1 Create systems which will serve Academic computing needs far into the future. Agents ~ bus trip analogy Systems Admin ~ Auto mechanic (me) CMS Admins ~ Bus Driver (John et al., Mark et al.) End Users ~ Passengers (Stu./Profs.)

  4. Planning Considerations – Part 2 Scalable: As the number of users increases, does the amount of work to run the system increase? Sys Admin – running an email server for one person or 1000 is just as much work CMS Admin – currently doubling the number of users doubles the amount of work. This needs to be fixed. (Same problem with the labs.)

  5. Planning Considerations – Part 3 User Friendly: Is the system something people will want to use? Currently there are many services possible and available but the problem is that each has its own authentication and so people are lumping everything into one moodle site. (Service depts and courses). Eg. It would also be nice to have a space for disseminating research.

  6. Planning Considerations – Part 4 Money: done Somehow(?) I convinced people to buy $57,000 in equipment. Migration is almost complete to “fault tolerant” systems, ie systems where you have to have two simultaneous breakdowns before loosing service. Even more to loose data.

  7. The Plan and Goals 1) One central authentication for multiple services (LDAP), ie. Just one password for everything. 2) Plugable services – multiple moodles, multiple blogs, multiple drupal (online publication), multiple wikis, etc. Isolated or integrated to the extend needed. 3) Automation for CMS admins

  8. Plugable services A dept may need a customized or isolated site. Quick deployment! Egs. Moodle – http://it.dl.dyc.edu Wikis - http://aclabs.wiki.dl.dyc.edu Gallery - http://basile.gallery.dl.dyc.edu Drupal - http://basile.drupal.dl.dyc.edu (Fac. Research. whitehouse.gov)

  9. Automation for CMS Admins 1) Automatic addition of student accounts and courses with students enrolled to main moodle. Data pulled from NIAS. 2) Automatic addition of low privileged accounts to various CMSes. 3) Automatic addition of students to survey for online student satisfaction. Automatic generation of results.

More Related