En 2006, nos encontramos con un problema de sistemas distribuidos en la Universidad de Minnesota. En ese momento, cada departamento tenía un «TI en la sombra» departamento. Si bien esto suele estar bien para algunas tareas de soporte (como la mesa de ayuda), no es adecuado para funciones de TI más grandes (incluida la administración de servidores). Y parece que cada departamento quiere ejecutar su propio servidor web.
[ Get the guide to installing applications on Linux. ]
Algunos departamentos son tan independientes que ejecutan servidores web en computadoras de escritorio en oficinas o cubículos vacíos. Un departamento esconde su servidor web debajo de una mesa de conferencias. Esto significa que si alguien presiona el interruptor de encendido durante la reunión, la computadora y su sitio web corren el riesgo de apagarse. Eso pasó.
Fue entonces cuando nos dimos cuenta de que la universidad necesitaba una nueva solución que pudiéramos respaldar en un departamento central de TI que otros departamentos pudieran usar para alojar sus sitios web. Necesitamos servicios de alojamiento web empresarial.
Diseño de un servicio de alojamiento web compartido
El desafío al que nos enfrentamos al crear un servicio administrado para toda la empresa estaba limitado principalmente por el costo. En la educación superior, a menudo nos enfrentamos a presupuestos ajustados. Pero crear un servicio de hospedaje web seguro y compartido que todos puedan usar es una tarea abrumadora. Se complica aún más por la necesidad de financiarlo a través de nuestro modelo existente de «impuesto corporativo de TI», que es una tarifa que pagan los departamentos para respaldar los proyectos centrales de TI. Si podemos crear un servicio de alojamiento web que se financie con el impuesto de TI, será más probable que los departamentos lo adopten. Después de todo, ya lo han «pagado» a través de los impuestos de TI, por lo que es poco probable que los decanos gasten dinero departamental para que sus equipos de TI operen sus propios servidores web.
Ya ejecutamos Red Hat Enterprise Linux (RHEL) para TI central, por lo que lo usamos para nuestro nuevo alojamiento web compartido. Comenzamos con este esquema:
- Servidor de red: Dos servidores web Linux que ejecutan sitios web HTTP y HTTPS mediante Apache.
- Tenemos varios centros de datos, por lo que tenemos un servidor web Linux en cada uno de los centros de datos. Acceden a la raíz del documento web público a través de un sistema de archivos de red (NFS) de solo lectura montado desde un sistema de almacenamiento empresarial.
- Montar la raíz del documento como de solo lectura es una función de seguridad. La mayoría de los sitios web no necesitan modificar sus páginas.pero las palabras clave son la mayoría de los sitiosResulta que algunos sitios web de departamentos grandes escriben actualizaciones en sus archivos de red, por lo que terminamos teniendo que montar el almacenamiento compartido como lectura-escritura.
- servidor de shell: Otros dos servidores Linux actúan como servidores shell donde los webmasters pueden actualizar su contenido web. Este es el único lugar donde los webmasters pueden editar archivos y se puede acceder a través de SSH o SFTP. Las raíces de documentos se montan en lectura y escritura desde estos servidores.
Con dos servidores web y dos servidores shell, tenemos redundancia en el lado de Linux. Nuestro almacenamiento también tiene redundancia. El marco de almacenamiento replica o refleja periódicamente la raíz del documento en un segundo marco de almacenamiento ubicado en otro centro de datos. Si uno de nuestros centros de datos se desconecta, podemos actualizar los servidores Linux para que apunten al marco de almacenamiento superviviente.
¡Esta arquitectura simple realmente funciona! Si un servidor falla, podemos usar inmediatamente un servidor de respaldo. Si todo el sitio se desconecta, podemos cambiar rápidamente a un segundo sitio.
[ You may also be interested in reading How to deploy an Apache web server quickly. ]
algunas lecciones aprendidas
Recientemente retiramos nuestro entorno de alojamiento web Linux. Después de 16 años de alojar más de 650 sitios web y 200 creadores de contenido en 3,6 TB, recurrimos a un proveedor de alojamiento web. Pero los servicios de alojamiento web de Linux funcionan bien y nos enseñaron algunas lecciones sobre cómo ejecutar grandes sistemas Linux.
1. Use permisos de archivos POSIX/Unix estándar cuando sea posible
Dado un sistema de archivos compartido común, la estructura de permisos de nuestro sistema de archivos es fundamental para proporcionar una arquitectura segura y con menos privilegios.Este apache De forma predeterminada, los usuarios tienen permisos de solo lectura en los archivos y permisos de solo lectura en los directorios.Para casos de uso que lo requieran, acceso de escritura apache Permita a los usuarios caso por caso mediante el uso de configuraciones de acceso basadas en grupos segmentados. Automatizamos la configuración para hacer cumplir las estructuras de permisos y evitar la «desviación de la configuración».
El uso de un diseño de estructura de permisos de sistema de archivos maduro realmente ayuda a mantener la arquitectura de seguridad general más simple y clara, al mismo tiempo que reduce al mínimo la sobrecarga operativa adicional. Tener una estructura de permisos sólida minimiza el impacto de cualquier incidente de seguridad.
[ Learn how to manage your Linux environment for success. ]
2. Simplifique la instalación para que coincida con la usabilidad para el público objetivo
En 2006, las personas que usaban instalaciones Apache alojadas en escritorio usaban Dreamweaver para diseñar y mantener sus sitios. Esta es la gran mayoría de los creadores de contenido objetivo. Solo necesitan usar HTML y CSS para construir su sitio web. Los creadores de contenido publican mediante SFTP de Dreamweaver. Esto significa que solo necesitan darles el nombre de host, la cuenta, la contraseña y la ruta DocumentRoot a su VirtualHost, nada más. Esto ayuda a mantener el diseño del sistema de archivos subyacente muy simple y fácil de documentar.
Esto también significa que la instalación de Apache puede eliminarse de todos los módulos no esenciales. Apache es lo más fácil de configurar posible y todavía se ejecuta como un servidor web y es seguro. A lo largo de los años, esto ha ayudado mucho con eventuales problemas de seguridad. Simplemente nada que romper.
3. La falta de actualizaciones del servicio conduce a una deuda técnica
El servicio ha estado funcionando durante más de 16 años sin cambios en la arquitectura básica. Hemos cambiado muy poco a lo largo del camino, incluidos algunos cambios basados en el ciclo de vida a medida que las implementaciones básicas iniciales dieron paso a los servidores virtuales. El marco de almacenamiento de back-end también ha sufrido varios cambios en el ciclo de vida.
Sin embargo, el diseño de caso de uso para el servicio no lo hace. Después de tanto tiempo, el alojamiento web simple ha superado los casos de uso para los que fue diseñado. Al carecer de actualizaciones de funciones para satisfacer las crecientes necesidades de administración de contenido, nuestro servicio de alojamiento web terminó siendo el hogar de todos los sitios web «antiguos». La simplicidad de la arquitectura significa que nuestro alojamiento web basado en Linux tiene un ciclo de vida prolongado y funciona con costos operativos mínimos. No añadimos nuevos servicios para mejorar el servicio, y esta complacencia condujo a una disminución en la adopción de nuevos sitios.
En conclusión
Si bien finalmente trasladamos nuestro alojamiento web a un servicio externo, también reconocemos la longevidad de este servicio. La ejecución de un servidor web en Linux facilita la compatibilidad con muchos usuarios y sitios web con muy poco esfuerzo para los administradores del sistema.
Si desea configurar un servicio similar en su propia organización, use estos consejos para hacer que su sistema sea poderoso, flexible y fácil de usar.
