Shared Webhosting-Architektur in einem Universitätsumfeld

Shared Webhosting-Architektur in einem Universitätsumfeld

Wir sind dabei, eine gemeinsame Webhosting-Infrastruktur für unsere Universität zu erstellen. Die Abteilungen der Universität können ihre Websites auf dieser Infrastruktur hosten. Wir denken daran, mehrere lastausgeglichene Webserver einzurichten, die an einen gemeinsamen Speicher angeschlossen sind (für Webinhalte und Apache-Konfigurationsdateien). Hinter diesen Webservern werden auch Datenbankserver stehen. Hat jemand andere Vorschläge dazu? Irgendwelche Empfehlungen für ein alternatives Setup? Wäre cPanel/WHM/Plesk eine gute Idee, um die Kontoerstellung/-pflege zu automatisieren?

Antwort1

Ich arbeite für eine Universität mit rund 21.000 Studenten. Wir bieten diesen Service schon seit einiger Zeit mit relativ einfachen Mitteln an. Bisher hatten wir sowohl Apache- als auch IIS-Umgebungen, die die Abteilungen als Webhoster nutzen konnten. Im Moment führen wir ein Upgrade durch, um die Zuverlässigkeit zu verbessern. Dabei platzieren wir mehrere Apache-Hosts mit demselben Speicher hinter einem Hardware-Load Balancer, der auch die SSL-Arbeit für die wenigen Sites übernimmt, die dies benötigen.

Was meine Antwort auf Ihre Frage grundlegend ändert, ist die Frage des Umfangs. Wir haben bereits eine Web Services-Gruppe, die als Vermittler zwischen den Abteilungen und der Backend-Arbeit beim Aufbau einer neuen Site fungiert. Sie arbeitet aktiv mit der Abteilung zusammen, um herauszufinden, ob eine vollständige Site oder eine Subsite auf dem gemeinsam genutzten Host für ihre Anforderungen besser geeignet ist. Wir bekommen jedes Jahr ein paar neue solcher Sites. Das funktioniert für uns.

Ein Freund an einer Universität mit etwa gleicher Größe, aber deutlich mehr Stiftungsvermögen verwaltet jedoch viel mehr physische Webserver als ich, da die Fachbereiche schon immer eine physische Trennung gefordert und auch durchgesetzt haben. Die Umstellung auf eine Architektur wie die unsere wäre für sie ein harter politischer Kampf, deshalb tun sie es nicht.

Wenn Sie mehr als, sagen wir mal, 10 pro Jahr erstellen möchten, können Sie durch die Automatisierung des Prozesses Vorteile erzielen. Aufgrund der aufgestauten Nachfrage kann die Nachfrage im ersten Jahr viel höher sein als in den Folgejahren, aber das können Sie besser beurteilen als wir. Letztendlich werden solche Tools den Prozess einfacher machen, aber wenn die Nachfrage gering genug ist, kann der Aufwand für die Wartung der cPanel-/was-auch-immer-Umgebung den Aufwand für die manuelle Codierung einiger Websites übersteigen.

Antwort2

Die Universität, an der ich vor kurzem gearbeitet habe, arbeitete an der Implementierung eines einzigen kommerziellen CMS-Systems, das alle Abteilungen nutzen sollten. Ich kann ihre Argumentation nachvollziehen – es zentralisiert die gesamte Verwaltung und trägt dazu bei, einheitliche Richtlinien für Grafik, Design, Sicherheit usw. zu fördern. Bisher hatten alle Abteilungen nur ihre eigenen Server betrieben, die über DNS delegiert wurden, und das zentrale Webteam betrieb die Hauptseite und htsearch. Webmail, Bibliothek und Online-Systeme wurden alle zentral von der IT-Abteilung verwaltet.

Berücksichtigen Sie bei der Entscheidung, wie viel Kontrolle Sie den Abteilungen überlassen möchten und wie viel Sie zentral erledigen lassen möchten, die technischen Kompetenzen und die Größe der Abteilungen.

Wenn es nur um das Hosting für Abteilungen geht, sehe ich keinen Bedarf für cPanel, und das würde die Sache tatsächlich nur verkomplizieren. cPanel könnte praktisch sein, wenn Sie für jeden Mitarbeiter (was wahrscheinlich eine gute Idee ist) oder jeden Studenten (was wahrscheinlich keine gute Idee ist, wenn man allein auf die Menge der Ressourcen achtet, die es beanspruchen würde) ein separates Hosting bereitstellen.

Antwort3

Ich würde zunächst festlegen, welche Gruppe(n) Sie unterstützen möchten, die Anforderungen dieser Gruppen ermitteln und dann festlegen, welche Dienste Sie bereitstellen möchten. Anschließend können Sie sich um die Architektur kümmern.

...

Als ich für eine Universität arbeitete, entwickelte sich unser Gopher-Server langsam zum wichtigsten Webserver der Universität. Am Ende hatten wir über tausend Konten, weil jede Gruppe innerhalb der Universität nur einen Mitarbeiter brauchte, der sie freigab. Das bedeutete, dass wir ganze Schulen und Abteilungen hatten, aber auch Studentengruppen, Lieblingsprojekte von Fakultätsmitgliedern usw. (oh – und wir hatten keine Infrastruktur, um zu erkennen, wann Gruppen nicht mehr existierten oder wann Mitarbeiter gewechselt hatten usw., also hatten wir keine Möglichkeit, alte Konten zu bereinigen).

Wenn Sie es wirklich wollen, kann ich Ihnen den Entwurf geben, den ich vorgeschlagen habe, um die "Anforderungen" zu erfüllen, die ein Auftragnehmer der Universität vorgeschlagen hat, und dann darauf bestand, dass er bauen könne, und nachdem er uns monatelang nichts gezeigt hatte, lieferte er uns schließlich Graumarkt-Hardware mitleerSpeicher-Arrays.

(Ich bin vor allem deshalb verbittert, weil wir nur noch Wochen davon entfernt waren, einen Sun-Cluster mit zwei Rechnern einzusetzen, um unsere veraltete Infrastruktur zu ersetzen, und ich ein ziemlich chaotisches System implementiert hatte, um mit Leuten klarzukommen, die sich mit ihren individuellen LDAP-Anmeldeinformationen beim System anmeldeten, dann aber Zugriff auf eine Gruppenverzeichnisstruktur für Daten hatten, während Solaris keine guten Vorkehrungen für Gruppenquoten hatte und ich sogar Konnektoren für ColdFusion schreiben musste, die nicht auf den CF-Server umschalteten, wenn es wirklich ein Webserverausfall war.)

Heutzutage würde ich wahrscheinlich mehr Virtualisierung wählen – vor 7 Jahren bestand unser Auftragnehmer darauf, alles auf einem Cluster aus zwei Maschinen zu installieren (zwei Versionen des iPlanet-Webservers, Apache, Chilisoft ASP, ColdFusion, PHP, Oracle, MySQL und einige andere Datenbanken usw. usw. [Anmerkung: Ursprünglich habe ich iPlanet + ColdFusion + Oracle erstellt, und das war’s]). Ich glaube, mein vorgeschlagener Ersatz war ein Rack voller 1U- und 2U-Boxen, aber heutzutage besteht kein so großer Bedarf an separater Hardware.

...

Der Grund für diese Geschichte (abgesehen davon, dass ich Dampf ablassen wollte) ist: Sie können versuchen,allesverfügbar unter der Sonne, unabhängig davon, ob Ihre Community es benötigt oder nicht, oder Sie können eine Anforderungsanalyse durchführen und die Bedürfnisse der Mehrheit der Community erfüllen, ohne sich selbst etwas aufzubürden, das nahezu unmöglich zu warten ist.

Antwort4

Wir sind dabei, eine gemeinsame Webhosting-Infrastruktur für unsere Universität zu schaffen. Abteilungen innerhalb der Universität können ihre Websites auf dieser Infrastruktur hosten.

Ich würde dringend empfehlen, die Architektur zu überdenken und Anforderungen zu sammeln, bevor Sie sich für eine Vorgehensweise entscheiden. Oberflächlich betrachtet klingt dies im Vergleich zu jedem zentralisierten CMS-System schrecklich ineffizient und schwierig zu verwalten. (z. B.SharePointoderim Freien). Die Vorteile der Umstellung auf ein SharePoint-System (insbesondere in einer Hochschulumgebung) sollten für die IT-Abteilung leicht zu vermitteln sein.

Vor diesem Hintergrund wollen wir einmal davon ausgehen, dass es einen legitimen Grund für die Erstellung mehrerer Websites gibt, ohne dass eine zentrale Informationsverwaltung und Site-Verwaltung erforderlich wäre (normalerweise ist die Rechtfertigung/der Grund politischer Natur).

Im Grunde würden Sie eine Shared-Hosting-Site betreiben, wie es jeder andere kommerzielle Webhoster auch tun würde. Plesk ist in einer Umgebung mit mehreren Betriebssystemen sicherlich eine gute Wahl, außerdem übernimmt Plesk die Verwaltung virtueller und physischer Server.

verwandte Informationen