arquitectura de alojamiento web compartido en un entorno universitario

arquitectura de alojamiento web compartido en un entorno universitario

Estamos en el proceso de crear una infraestructura de alojamiento web compartido para nuestra universidad. Los departamentos de la universidad pueden alojar sus sitios en esta infraestructura. Estamos pensando en configurar múltiples servidores web con carga equilibrada conectados a un almacenamiento compartido (para contenido web y archivos de configuración de Apache). También habrá servidores de bases de datos detrás de estos servidores web. ¿Alguien tiene alguna otra sugerencia sobre esto? ¿Alguna recomendación para una configuración alternativa? ¿Sería una buena idea tener cPanel/WHM/Plesk para automatizar la creación/mantenimiento de cuentas?

Respuesta1

Trabajo para una universidad con alrededor de 21.000 estudiantes. Llevamos algún tiempo brindando este servicio a través de medios bastante simples. Históricamente hemos tenido entornos Apache e IIS para que los departamentos los utilicen como host web. En este momento estamos realizando una actualización para mejorar la confiabilidad, colocando múltiples hosts Apache usando el mismo almacenamiento detrás de un balanceador de carga de hardware que también hace el trabajo pesado de SSL para aquellos pocos sitios que lo necesitan.

Lo más importante que cambia mi respuesta a su pregunta es la cuestión de la escala. Ya tenemos un grupo de servicios web que actúa como mediador entre los departamentos y el trabajo de back-end para crear un nuevo sitio, y trabajan activamente con el departamento para determinar si es un sitio completo o un subsitio en el host compartido. es mejor para sus necesidades. Recibimos un par de sitios nuevos de este tipo al año. Esto funciona para nosotros.

Sin embargo, un amigo en una universidad de aproximadamente el mismo tamaño pero con una dotación significativamente mayor está administrando muchos más servidores web físicos que yo, ya que los departamentos históricamente han exigido la separación física y la han conseguido. Pasar a una arquitectura como la nuestra sería una dura lucha política para ellos, así que no lo harán.

Si espera construir más de 10 al año, puede obtener ganancias al automatizar el proceso. La demanda reprimida puede hacer que el primer año sea mucho más alto que los años posteriores, pero usted puede juzgar eso mejor que nosotros. En última instancia, estas herramientas facilitarán el proceso, pero si la demanda es lo suficientemente baja, el esfuerzo de mantener el entorno cPanel/lo que sea puede superar el esfuerzo de codificar manualmente algunos sitios.

Respuesta2

La universidad en la que trabajé recientemente estaba trabajando para implementar un único sistema CMS comercial que se alentaría a todos los departamentos a utilizar. Puedo ver su razonamiento: centraliza toda la gestión y ayuda a fomentar políticas únicas sobre arte, diseño, seguridad, etc. Históricamente, todos los departamentos simplemente ejecutaban sus propios servidores, delegados a través de dns, y con el equipo web central ejecutando el sitio principal y htsearch. El departamento de TI gestionaba de forma centralizada el correo web, la biblioteca y los sistemas en línea.

Querrá pensar en las competencias técnicas y el tamaño de los departamentos al considerar cuánto desea entregarles el control y cuánto desea manejar de forma centralizada.

Si solo estamos hablando de alojamiento para departamentos, entonces no veo que haya necesidad de cPanel y, de hecho, eso complicaría las cosas. cPanel puede resultar útil si proporciona alojamiento independiente para cada miembro del personal (lo que probablemente sea una buena idea) o para cada estudiante (lo que probablemente no sea una buena idea basándose únicamente en la cantidad de recursos que consumiría).

Respuesta3

Primero consideraría determinar qué grupo(s) desea apoyar, estudiar las necesidades de esos grupos y luego determinar qué servicios está dispuesto a brindar... luego podrá preocuparse por la arquitectura.

...

Cuando trabajaba para una universidad, nuestro servidor Gopher creció lentamente hasta convertirse en el servidor web principal de la universidad; al final, teníamos más de mil cuentas, porque cualquier grupo dentro de la universidad solo necesitaba que un miembro del personal lo aprobara. Esto significaba que teníamos escuelas y departamentos completos, pero también grupos de estudiantes, proyectos favoritos de los profesores, etc. (oh, y no teníamos infraestructura para identificar cuándo los grupos habían desaparecido, o cuándo los miembros del personal habían cambiado, etc., así que no teníamos forma de limpiar cuentas antiguas).

Si realmente lo desea, puedo darle el diseño que propuse para cumplir con los "requisitos" que un contratista propuso a la universidad, y luego insistió en que podía construir y, después de meses de mostrarnos nada, finalmente nos envió hardware del mercado gris convacíomatrices de almacenamiento.

(Estoy sobre todo amargado porque estábamos a semanas de implementar un cluster solar de dos máquinas para reemplazar nuestra infraestructura obsoleta, y había implementado un sistema bastante desordenado para lidiar con las personas que iniciaban sesión usando sus credenciales LDAP individuales en el sistema, pero luego tenían acceso a una estructura de directorio de grupo para datos, mientras que Solaris no tenía buenas disposiciones para cuotas de grupo, e incluso tuvo que escribir conectores para ColdFusion que no fallarían en el servidor CF si realmente se tratara de una falla del servidor web)

Hoy en día, probablemente optaría por más virtualización: hace 7 años, nuestro contratista insistió en colocar todo en un clúster de dos máquinas (dos versiones del servidor web iPlanet, apache, chilisoft ASP, ColdFusion, PHP, Oracle, mysql y algunos otros). bases de datos, etc, etc. [nota, originalmente estaba construyendo iPlanet + ColdFusion + Oracle, y eso fue todo]) Creo que mi reemplazo propuesto era un rack lleno de cajas de 1U y 2U, pero no hay tanta necesidad de hardware separado como estos. días.

...

Entonces, la razón de esta historia (además de desahogarse) es: puedes intentar proporcionartododisponible bajo el sol, sin importar si su comunidad lo necesita o no, o puede hacer algunos análisis de requisitos y satisfacer las necesidades de la mayoría de la comunidad sin tener que tener algo que sea casi imposible de mantener.

Respuesta4

Estamos en el proceso de crear una infraestructura de alojamiento web compartido para nuestra universidad. Los departamentos de la universidad pueden alojar sus sitios en esta infraestructura.

Recomiendo encarecidamente repensar la arquitectura y recopilar los requisitos antes de decidir un curso de acción. A primera vista, esto suena terriblemente ineficiente y difícil de administrar en comparación con cualquier sistema CMS centralizado. (p.ejpunto compartidooal aire libre). Los beneficios de optar por un sistema de tipo sharepoint (particularmente en un entorno universitario) deberían ser fáciles de vender para TI.

Dicho esto, supongamos que hubo una razón legítima para crear múltiples sitios web sin la necesidad de una gestión centralizada de la información y del sitio (normalmente la política es la justificación/razón).

Para todos los efectos, estaría ejecutando un sitio de alojamiento compartido como lo haría cualquier otro proveedor de alojamiento web comercial. Plesk es sin duda una buena opción en un entorno de múltiples sistemas operativos; además, Plesk se encarga de la gestión de servidores físicos y virtuales.

información relacionada