Por lo general la preparación de servers FLOSS (Linux+apps), está muy asociada a las funciones necesarias en un ISP, típicamente servicios web+stack de aplicaciones (php, python, ruby, etc.), con su correspondiente soft de administración centralizada (cpanel, ispconfig, etc.). A estos servers se puede agregar los de infraestructura corriendo DNS, LDAP, RADIUS, VPN, etc.
Cuando se llega a tener cierta experiencia en estas soluciones es casi mecánica su instalación y configuración.
En cambio cuando hablamos de servidores Linux intra-organizacionales las soluciones cuasi-metódicas no son tan comunes. En una organización se plantean desafíos a nivel de los procesos de negocio y "capa 8" (personas), que hacen que las soluciones mecánicas lleguen a un buen nivel de personalización.
Es tentador implementar grandes soluciones, basadas en software complejo y/o de amplias capacidades, sin embargo cuando no se prevé la necesidad de escalar la solución o cuando una solución simple va a escalar correctamente, es bueno inclinarse por lo simple y efectivo.
Por ejemplo, y desde una experiencia propia, si tenemos que montar un esquema de backups regular, y se opta por soft FLOSS, se tiende en primera instancia a evaluar AMANDA o Bacula. Es cierto que son soluciones altamente escalables, sin embargo la complejidad de su administración hace casi indelegable la tarea de la adm. de backups a operadores, no hablemos de diagnóstico y control regular de operaciones.
El uso de soft de bak con vastas prestaciones viene dado por el requerimiento del almacenamiento de grandes cantidades de archivos y la necesidad de mantener y almacenar cambios históricos en los mismos a lo largo del tiempo; ello sumado claro, a la necesidad de poder buscar, encontrar y recuperar rápidamente cualquier archivo, sin importar donde esté ubicado físicamente.
Una solución más simple y adecuada a un entorno donde no se requiere lo explicado en el parráfo anterior consiste en el montaje de una solución basada en scripts. Esta es un clásico de los sysadmins experimentados ya que conlleva un alto grado de control de primera mano en cuanto a qué, donde y cómo se almacenan y transportan los archivos de backup.
Particularmente es solo aplicable según la magnitud de los conjuntos de archivos a backupear, por ejemplo se puede mantener un registro histórico de cambios usando tar, y comprimir en gzip, bzip, 7zip, etc. No escala tan bien obviamente cuando tenemos muchos servers y archivos que mantener y hay que documentar todo minuciosamente (es decir que estaríamos realizando manualmente el trabajo que hace Bacula automáticamente!!).
La solución de baks basado en scripting tiene su punto focal en escenarios donde los archivos a resguardar son relativamente escasos, y los puntos de resguardo y almacenamiento a los que debe llegar la información son pocos (al contrario de por ejemplo, Bacula de nuevo, donde podemos tener un elevado número de nodos con información a backupear y podemos distribuir ese backup a lo largo de muchos servers Bacula y también con varios servers de almacenamiento). Adicionalmente, si no se va a usar tar para la solución, es un requerimiento ineludible que no sea necesario el backup de los cambios entre versiones de los archivos.
Saludos.
Cuando se llega a tener cierta experiencia en estas soluciones es casi mecánica su instalación y configuración.
En cambio cuando hablamos de servidores Linux intra-organizacionales las soluciones cuasi-metódicas no son tan comunes. En una organización se plantean desafíos a nivel de los procesos de negocio y "capa 8" (personas), que hacen que las soluciones mecánicas lleguen a un buen nivel de personalización.
Es tentador implementar grandes soluciones, basadas en software complejo y/o de amplias capacidades, sin embargo cuando no se prevé la necesidad de escalar la solución o cuando una solución simple va a escalar correctamente, es bueno inclinarse por lo simple y efectivo.
Por ejemplo, y desde una experiencia propia, si tenemos que montar un esquema de backups regular, y se opta por soft FLOSS, se tiende en primera instancia a evaluar AMANDA o Bacula. Es cierto que son soluciones altamente escalables, sin embargo la complejidad de su administración hace casi indelegable la tarea de la adm. de backups a operadores, no hablemos de diagnóstico y control regular de operaciones.
El uso de soft de bak con vastas prestaciones viene dado por el requerimiento del almacenamiento de grandes cantidades de archivos y la necesidad de mantener y almacenar cambios históricos en los mismos a lo largo del tiempo; ello sumado claro, a la necesidad de poder buscar, encontrar y recuperar rápidamente cualquier archivo, sin importar donde esté ubicado físicamente.
Una solución más simple y adecuada a un entorno donde no se requiere lo explicado en el parráfo anterior consiste en el montaje de una solución basada en scripts. Esta es un clásico de los sysadmins experimentados ya que conlleva un alto grado de control de primera mano en cuanto a qué, donde y cómo se almacenan y transportan los archivos de backup.
Particularmente es solo aplicable según la magnitud de los conjuntos de archivos a backupear, por ejemplo se puede mantener un registro histórico de cambios usando tar, y comprimir en gzip, bzip, 7zip, etc. No escala tan bien obviamente cuando tenemos muchos servers y archivos que mantener y hay que documentar todo minuciosamente (es decir que estaríamos realizando manualmente el trabajo que hace Bacula automáticamente!!).
La solución de baks basado en scripting tiene su punto focal en escenarios donde los archivos a resguardar son relativamente escasos, y los puntos de resguardo y almacenamiento a los que debe llegar la información son pocos (al contrario de por ejemplo, Bacula de nuevo, donde podemos tener un elevado número de nodos con información a backupear y podemos distribuir ese backup a lo largo de muchos servers Bacula y también con varios servers de almacenamiento). Adicionalmente, si no se va a usar tar para la solución, es un requerimiento ineludible que no sea necesario el backup de los cambios entre versiones de los archivos.
Saludos.
No hay comentarios:
Publicar un comentario