Muy buenas, aquí estamos otra vez.
Vamos a asumir que nos toca llevar/ayudar/colaborar con alguien y acabamos montándole un servidor, aunque sólo sea para guardar documentación. Y como somos como somos se lo montamos con un ubuntu para simplificar (en mi caso, es por principio y práctica, pero me da igual).
¿Qué dice la teoría oficial? Que un servidor se mantiene 7/24 y no se toca mientras funcione. Correcto. ¿Y cuando falla? ¿Cuándo se hacen las copias de seguridad? ¿Dónde? ¿Qué pasa si el número de usuarios aumenta y te das cuenta que se bloquea cuando trabajan en firme? ¿Compras otra máquina más potente? ¿Con qué presupuesto? Por muy estable que sea el sistema de ficheros, tarde o temprano habrá algún problema y en un reinicio puede clavarse...
La experiencia es que algún reinicio siempre es necesario; y un refresco aún más; y habitualmente no tenemos demasiado margen de tiempo para hacerlo sea porque no nos lo dan o porque sólo estamos ayudando y hemos de desviarnos mucho del camino habitual dar el soporte y vamos, como es habitual, con el petardo en el culo.
¿Alternativas? ¿Se pueden programar tareas de mantenimiento que nos tranquilicen? Os ofrezco mis alternativas, ya me diréis qué opináis de ellas.
Estado: Dos discos -sistema, usuarios y datos compartidos, montados en RAID- y un segundo disco más pequeño donde se realiza una copia de seguridad de los homes y de las carpetas compartidas. Asumo que se han configurado en la instalación los detalles de configuración que he comentado otras veces (sysctl, etc).
1.- Me aseguro que el disco del copias de seguridad no entre más que mientras se hace la copia (y no se está trabajando) y que se desconecte una vez acabada. reducción de accesos y mantenerlo en el mejor estado posible.
Si salen fallos, esos problemas hubieran saltado igualmente: Un disco duro con fallos, una fuente de alimentación que pierde potencia,... La mayoría de estos errores avisan con tiempo a poder comprar piezas de recambio sin tener que aceptar cualquier precio o condición... excepto si no apagamos jamás la maquina y, entonces, en el primer apagado no se rearma y tenemos que correr como gallinas descabezadas. Así que por esa parte, también bien.
Incluso en el peor de los casos, que no se reinicie, es lunes por la mañana; empieza la jornada de trabajo y es más fácil organizarte sabiendo que las prioridades acaban de cambiar que no reorganizar todo el trabajo a media semana para cubrir una emergencia, presionado por todas partes... aunque esa última parte no te la podrás ahorrar, no nos engañemos.
Bueno, acábose el ladrillo. Ya me diréis qué opináis del tema o si lo haríais de otra manera. Hasta luego.
PS: Para las copias de seguridad utilizo el systemback, por eso no hay ninguna llamada aquí, no es que me haya olvidado; pero en caso de hacerlo lanzaría un rsync incremental con compresión a la partición de destino. Hasta luego.
¿Alternativas? ¿Se pueden programar tareas de mantenimiento que nos tranquilicen? Os ofrezco mis alternativas, ya me diréis qué opináis de ellas.
Estado: Dos discos -sistema, usuarios y datos compartidos, montados en RAID- y un segundo disco más pequeño donde se realiza una copia de seguridad de los homes y de las carpetas compartidas. Asumo que se han configurado en la instalación los detalles de configuración que he comentado otras veces (sysctl, etc).
1.- Me aseguro que el disco del copias de seguridad no entre más que mientras se hace la copia (y no se está trabajando) y que se desconecte una vez acabada. reducción de accesos y mantenerlo en el mejor estado posible.
nano /etc/cron.d/BackUps2.- Vaciamos, una vez a la semana, cada sábado por la noche, esas papeleras que los usuarios no suelen vaciar sin darse cuenta de la saturación de espacio que provocan.
59 20 * * * root /bin/mount UUID=[o /dev/sd**, lo que os vaya bien] /media/lnadmin/ [la carpeta se puede cambiar, es cosa vuestra.]
00 06 * * * root / bin/umount UUID=___[Igual que arriba]
nano /etc/cron.d/Papeleras3.- Forzamos la revisión de los sistemas de ficheros en el siguiente reinicio de domingo por la noche, por el simple expediente de incrementar artificialmente el contador de montajes. En principio cada cuatro activaciones -una vez al mes- se revisaba el sistema, pero debido a los problemas detectados y a ser un servidor sensible, no nos la jugamos. Cada vez que se arranca revisa TODO y nos aseguramos que el sistema es estable y el disco duro no se ha dañado. ¿Tarda más en iniciarse? Sí, pero ¿qué preferís en estas condiciones, tranquilidad o velocidad? Por mi parte lo tengo claro.
00 22 * * 6 root rm -rf /home/*/.local/share/Trash/*
nano /etc/cron.d/Revisiones4.- Una vez creado el escenario, hacemos magia. ¿cuándo va más fino un telefono, un portátil...? Cuando lo acabamos de arrancar. La maquinaria que requiere calentamiento no goza de buena fama entre los usuarios -entre el gremio sería otra discusión- Así pues, a primerísima hora del lunes, cuando el relente hace que el equipo no padezca demasiado por la temperatura -no tengo una sala blanca ni refrigerada, por si no se nota- y mucho antes de que cualquier usuario entre al centro a trabajar, lanzamos la orden de reinicio al servidor; un servidor que, en estas circunstancias, se puede permitir tomarse todo el tiempo del mundo para su reinicio. En este caso dado que el mes de Agosto el centro permanece cerrado (se supone) y por si se olvida apagar la máquina se incluye la linea que apaga el servidor el último día de Julio, a las 23 y 59, para que no esté en funcionamiento inútilmente durante el mes de Agosto. Por ahora, siempre he podido apagar toda la instalación -que es lo mejor- pero por si acaso, no va mal tener esa seguridad y proteger la parte más vital del sistema.
50 23 * * 0 root /sbin/tune2fs -C 50 /dev/sda1
51 23 * * 0 root /sbin/tune2fs -C 50 /dev/sda2
...[siguen todas las lineas necesarias, en función de las particiones; hay que ajustar los tiempos y, para asegurar, dejo un minuto entre partición y partición].
nano /etc/cron.d/ReinicioSi hemos tenido suerte, ya está. Nuestros compañeros llegarán a las siete, o a las ocho, se pondrán a trabajar y ni se enteraran de qué ha pasado porque el servidor saltará alegre como un cervatillo.
00 04 * * 1 root /sbin/reboot
59 23 31 7 * root /sbin/shutdown -h
Si salen fallos, esos problemas hubieran saltado igualmente: Un disco duro con fallos, una fuente de alimentación que pierde potencia,... La mayoría de estos errores avisan con tiempo a poder comprar piezas de recambio sin tener que aceptar cualquier precio o condición... excepto si no apagamos jamás la maquina y, entonces, en el primer apagado no se rearma y tenemos que correr como gallinas descabezadas. Así que por esa parte, también bien.
Incluso en el peor de los casos, que no se reinicie, es lunes por la mañana; empieza la jornada de trabajo y es más fácil organizarte sabiendo que las prioridades acaban de cambiar que no reorganizar todo el trabajo a media semana para cubrir una emergencia, presionado por todas partes... aunque esa última parte no te la podrás ahorrar, no nos engañemos.
Bueno, acábose el ladrillo. Ya me diréis qué opináis del tema o si lo haríais de otra manera. Hasta luego.
PS: Para las copias de seguridad utilizo el systemback, por eso no hay ninguna llamada aquí, no es que me haya olvidado; pero en caso de hacerlo lanzaría un rsync incremental con compresión a la partición de destino. Hasta luego.
| Tweet |
0 comentarios:
Publicar un comentario