Mostrando entradas con la etiqueta backup. Mostrar todas las entradas
Mostrando entradas con la etiqueta backup. Mostrar todas las entradas
jueves, 27 de junio de 2013
Tips para diseñar sistemas de backup realmente útiles
El sistema de backup de una infraestructura compleja tiene que ser lo más simple posible: fácil de entender por alguien - un administrador - que no sea un especialista, y se haga cargo de la administración.
Fácil de usar para quienes no sean admins especialistas en backup, fácil para trabajar en una emergencia, cuando se necesita del backup y no se puede prestar atención a los detalles técnicos intrincados de un sistema de backup complejo; y finalmente fácil de restaurar a su funcionamiento normal cuando hay alguna falla interna.
Catálogos internos que se guardan en bases de datos propietarias, backends en bases de datos que pueden fallar, múltiples componentes distribuídos (que necesitan literalmente matemática combinatoria y grafos para llegar a conocer todos los posibles estados de error del sistema), etc. conspiran contra sistemas de backup simples y realmente manejables.
Los casos en que hace falta que un sistema de backup sea complejo e intrincado son escasos, muy raros. La mayoría de la infraestructura se puede diseñar y configurar de modo tal de disponer de "dropboxes" fácilmente recuperables: son directorios/carpetas donde se depositan o hacen disponibles los datos a resguardar.
Un ejemplo de "dropboxes" se da cuando se quiere backupear una base de datos y se guarda datos a un directorio que luego será backpeado:
- Con el clásico procedimiento de dumpear bases a backupear, o
- En un backup "raw", en crudo, bajando la base y backupeando limpiamente todos los directorios donde el software guarde y escriba datos. Lo que es posible en gral. y sin mucho problema en sistemas Linux y *Nix, y suele ser más complicado en Windows Server, debido a que muchos valores de configuración pueden estar guardados en el registro (hace falta crear un paso intermedio donde se "dumpea" todos los valores relevantes del registro a un archivo .reg que permita luego recuperar "crudamente" el software en un Windows "limpio").
domingo, 23 de diciembre de 2012
Las soluciones IT completas y un ejemplo con infraestructura virtual vSphere
En este artículo cuento cómo en gral. las soluciones "completas" no lo son, y hay que completarlas para que realmente cumplan con el objetivo para el cual fueron pensadas. Hay además comentarios sobre los ámbitos de responsabilidad de provedores IT terceros y la relación de los proveedores IT internos de una organización con su cliente principal (la organización).
Soluciones buenas, pero parciales
Es común ver en infraestructura que al comprar una solución IT, la empresa acuerda el trabajo a realizar, viene a la empresa/organización, realiza el trabajo y luego se va. Dejando garantías vigentes, por un tiempo, bajo ciertas condiciones, etc.
Por ejemplo, la instalación de una infraestructura vSphere: se instalan los hipervisores, se monta el server vCenter, se agrega los hipervisores al vCenter, se deploya algunas máquinas virtuales - probablemente no?, y listo (hasta ahí es el trabajo acordado con el proveedor de servicios IT en este ejemplo). El cliente luego toma la posta desde ahí, administrando todo la infraestructura - virtual ahora. Instalando, migrando sistemas operativos de físico a virtual, etc. etc.
El precio de un trabajo puntual de infraestructura y sus límites son indispensables, sino la empresa proveedora va a hacerse cargo hasta el infinito de cualquier cuestión relacionada con lo que instaló/configuró inicialmente.
Soluciones IT completas
Ahora, el caso de las áreas de sistemas internas en la organización es bien diferente. Cada área IT interna en una organización tiene la obligación de sostener la continuidad de la infraestructura en el tiempo, a largo plazo.
Lo que es muy diferente de la obligación de proveedor IT comercial, sin embargo es común encontrar el caso de que las soluciones IT internas en una organización se implementan "por única vez", y luego se las abandona "como están" y sin tomar en cuenta la prerrogativa de mantenimiento y mejora contínua (que es en gral. un requerimiento del puesto para los empleados del área IT interna por cierto).
Siguiendo el ejemplo de la infraestructura vSphere, algunos pasos posteriores a la "simple" instalación y configuración de una infra virtual vSphere podrían ser (más o menos en orden de importancia estratégica-técnica):
1) Implementar backup automatizado de la configuración del vCenter (y su DB de backend)
2) Implementar backup automatizado de la configuración de los ESXi,
3) Deployar (comprar en gral.) una solución de backup virtual (Veem, etc.), para las máquinas virtuales en sí,
4) Implementar chequeo de configuraciones automatizado (extraer toda la configuración de vSphere, volcar a un GIT o similar, y luego ir haciendolo regularmente, para tener un registro centralizado exacto de cada cambio en la configuración), AKA "configuration management".
5) Implementar monitoreo de la infraestructura virtual (hay varias maneras)
6) Deployar un vSphere Update Manager (para mantener todos los hipervisores actualizados/parcheados),
7) Implementar alta disponibilidad para vCenter (o sea, montar otro server vCenter, de alguna de las varias maneras posibles),
8) Implementar automatización en el mantenimiento necesario para vCenter (tip: la DB de backend necesita atención de a ratos).
9) Cómo proceder, y qué hacer exactamente desde lo técnico para recuperar la caída/cuelgue/fuera de servicio de cualquier componente de la infraestructura virtual vSphere (incluye tener instaladas y configuradas las herramientas necesarias, los planes, y que los que vayan a haber la recuperación, hayan realizado prácticas y pruebas de campo para saber que toda las políticas/procedimientos/herramientas funcionan realmente como deberían).
Etc.
Si se fijan, extrapolando la idea general del ejemplo, cualquier infraestructura necesita básicamente (además de la instalación, configuración y puesta en producción inicial):
- Backup,
- Configuration Management,
- Monitoreo y Optimización/Mantenimiento/Mejora Contínua.
- Añadir redundancia/resiliencia adicional (como parte de la mejora contínua)
- Plan de acción de recuperación de desastres.
Sin todos esos detalles (y varios más no mencionados), la solución puede "estrellarse" con mucha facilidad y dejar de funcionar apropiadamente, y con algo de mala suerte además, inesperadamente (por ejemplo: madrugada de año nuevo, 3 de la mañana, llamada del dueño de la empresa al personal IT, cayendo a las 3.10 cuando el personal que usa el sistema le acaba de avisar de que no anda. "Casos de uso": clínica de guardia, farmacia de guardia, empresa de seguridad, polícia, etc.).
Completar la solución
Si una solución integral no incluye lo anterior, habría que ir preguntando al proveedor cuanto saldría implementar backup, config management, monitoreo, y disaster recovery...o pensar cómo se hace internamente para completar la solución de infraestructura. Normalmente esas tareas tercerizadas implica un precio mayor que la instalación/configuración inicial, ese precio más alto es realmente una mejor aproximación al TCO real de la solución.
TCO:
http://es.wikipedia.org/wiki/Coste_total_de_propiedad
* Esto es cuestión de opiniones, pero para completar más el TCO de la solución, se podría agregar la previsión/estimación de costos futuros del lifecycle management, por ejemplo, previendo una migración de plataforma.
Siguiendo el ejemplo: preveer un posible/eventual path de migración de Vmware vSphere 5.1 (+ ESXi) hacia Microsoft Hyper-V 2012 + System Center 2012 Virtual Machine Manager .
Por ejemplo: tener que comprar una SAN "ahora":
- aumenta el TCO de la solución vSphere, pero
- baja el TCO de la - posible a futuro - solución Hiper-V 2012, pero,
- en gral. hace disminuir el TCO de la solución "Infraestructura Virtual"
(que es lo que le interesa a la organización en realidad), y por lo tanto genera un "path de migración" aceptable, y se concluye que comprar la SAN "estaría bueno" :-)
Ambitos y tiempos limitados
Las áreas IT internas tienen un ámbito de injerencia y obligaciones para con la infraestructura IT por lejos mucho mayor que casi cualquier solución "llave en mano" que pueda proveer un tercero, ya que inclusive con el mejor presupuesto disponible, el ámbito de injerencia de un proveedor IT tercerizado siempre - pero siempre - está limitado a determinadas tareas y obligaciones, y a un rango de tiempo - contratado - durante el cual le va a responder al cliente. Y luego del cual, ya no va a tener obligación de responderle al cliente.
El área IT interna por otra parte no está limitada en absoluto de sus obligaciones para con la organización, a la que debe responder por obligación organizacional (o sea, independientemente de quién/es estén integrando esa área como empleados/responsables), de modo contínuo, y tiene la responsabilidad de completar y subsanar cualquier limitación que exista en la infraestructura.
Siguiendo el ejemplo: el que en la solucion "llave en mano" no haya previsto un mecanismo de backup para los hipervisores ESXi. Si no lo hace el proveedor, es obligación del área IT interna completar la solución.
La obligación contractual del proveedor IT, siempre tiene un límite práctico: el tiempo máximo contratado y qué tanto trabajo se puede hacer durante ese tiempo. Aunque y a pesar de que se suele contratar:
- "soluciones completas",
- "soluciones llave en mano",
- "soluciones integrales",
y demás buena jerga de vendedor IT, por más que esté "prometido" las soluciones provistas por un tercero nunca van a poder ser integralmente completas, sino solamente van a estar de acuerdo a lo contratado (una lista de tareas que figura en el contrato), cualquier tarea adicional, paga o no, es a discreción y buena voluntad del tercero proveedor.
...A menos que directamente se los contrate permanentemente para hacer el trabajo del área interna IT...ooops, pero ese contrato también tiene una duración máxima, así que no, no es posible sostener la tercerización ilimitada, siempre va a haber que pagar más o contratar servicios adicionales para poder tener una tercerización ilimitada (por eso es tan buen negocio por cierto :-).
Conclusión
Es bastante seguro decir, falta de presupuestos infinitos mediante, que eventualmente toda organización/empresa se va a volver a hacer cargo de sus propias necesidades de informatización, y lo mejor es que sea lo antes posible y con el mejor grado de previsión y responsabilidad.
lunes, 8 de diciembre de 2008
Notas pre-implementación de Data Protector 6
Esta semana tomé el curso u1620s (HP Data Protector 6 Software Fundamentals). Tengo en este caso una panoramica muy buena de las capacidades reales del software más allá de lo que se puede ver en los datasheets y los manuales. Particularmente para trabajar sobre plataformas *nix, si es que no se tiene una infrastructura distribuída, añade poco a las características de otro soft de backup, libre o no.
Lo que puede ser realmente útil es la capacidad de administración del sistema casi a puro golpe de click, ello si bien no incorpora gran ganancia para los *nix users acostumbrados a navegar entre puertos ssh y largos archivos de configuración de herramientas de backup y administración, en cambio deja al soft en posición perfecta para ser un punto de operación de infraestructura: ya habiendo montado eficazmente la infraestructura de backup y con los manuales de procedimientos bien aceitados (y lo más cortos posible), se puede asignar la tarea de realización y control de backups a operadores, incluso a varios, ya que el subset de skills necesario para operar Data Protector es mínimo (vs. el necesario para instalar, configurar y administrar). Para ello el software colabora con la capacidad de incorporar al sistema credenciales para usuarios de menor privilegio.
Lamentablemente, un soft de backup de este nivel implementado en una gran infraestructura (desde decenas de servidores en adelante), tiende a necesitar un poco más de atención que la de un operador. Por ello es recomendable limitar las funciones de los operadores a celdas de backup a lo sumo (una celda en Data Protector es equivalente a un servidor de backup y puede interconectarse varias celdas en un solo gran sistema).
La tarea para el (verdadero) administrador consiste entonces sí en subir varios niveles de dificultad y avanzar en el control de las posibilidades problematicas que estén dadas según el nivel de complejidad en el subconjunto de funciones de Data Protector elegidas para ser usadas en una implementación particular (en difícil usar el 100%). Igualmente esto se puede planificar y documentar apropiadamente y así no estaremos nunca en situación de verificar los posibles problemas en el marco del 100% de las posibilidades funcionales de la herramienta.
Una limitación práctica de Data Protector dada desde antes de configurar nada: no soporta scheduling ala CRON, no se puede configurar la herramienta para correr backups, por ejemplo, todos los primeros lunes de cada mes...a menos que se configure doce veces las fechas del año que coinciden con el primer lunes de cada mes (y así sucesivamente, año a año). Esto a la versión 6, al último parche disponible hace un par de días cuando terminamos el curso.
Otra limitación práctica: el soporte para backup en Linux, en herramientas FOSS (DB Postgresql, DB Mysql, etc.), y en tareas de DI (Disaster Recovery) está a la misma altura que la de cualquier software de backup FOSS (Amanda y Bacula por ejemplo). Ninguna de las funciones de backup en línea para software está soportada para varias DB FOSS, ni para la mayoría de las herramientas comerciales típicas en sus versiones para Linux.
En particular para mi diseño de implementación particular, voy a tener que prescindir del uso del scheduler de Data Protector y correr los sets de backup configurados desde el server vía CRON. Es decir, en la práctica es exactamente lo mismo que correr los backups vía scripting+CRON (añadiendo catalogos y compresión con tar.bz2 opcionalmente).
La característica de backup on-line para herramientas puede suplirse con snapshots LVM por ejemplo, haciendo un uso adecuado de las características de backups y consolidaciones virtuales en Data Protector. Adicionalmente es para considerar la situación en que un software/servicio particular es "snapshoteado" y luego traído de vuelta a la vida (ciertamente en un /etc/init.d/servicio start, manual), luego de una restauración, a poner cuidado entonces de a qué le aplicamos snapshots y hacer testing exhaustivo (la mayoría del soft, FOSS o no, no tiene referencias de este tipo de stop-start de funciones, más allá de comentarios en foros).
Las características puntuales de backup y restauración en Linux de Data Protector que ya se aprecian desde los datasheets y ahora veo confirmadas son el que permite realizar backups mediante agentes, seleccionando vía click desde un servidor central qué directorios y/o archivos se quiere resguardar. En el momento de la restauración los agentes podrán sobreescribir o no archivos, a elección del admin u operador.
Volviendo un poco a las ausentes características de DI (Disaster Recovery) para Linux, veo que en el momento de restaurar un server desde cero, no habrá posibilidad de restauración Bare Metal directo desde un dispositivo externo (disco, usb, cinta), sino que habrá que instalar el SO (y ello implicará su correspondiente configuración y actualización), luego el agente DP, realizar la conexión con el server DP y luego sí proceder a la restauración de casi seguramente centenares de gigas vía un enlace de red (algo que se complica cuando tienes tu server a restaurar a varios centenares de kilométros del punto de origen de la comunicación vía TCP).
Esto último caso de restauración remota es parcialmente solucionable backupeando un "esqueleto" en varios sets de backups, uno por server. Cada esqueleto de configuración permitiría bajar bastante el downtime evitando bajar a configurar /etc y otros directorios y archivos (sea vía CLI o con GUIs de administración), de configuración si hubiera algun otro soft externo a la distribución implementado.
Quedaría pendiente entonces la cuestión de la imposibilidad práctica de backpear los binarios (parte de los cuales se debería actualizar regularmente, vía parches de seguridad principalmente) para una restauración vía medios externos (dvd, usb, cinta) e independientes de Data Protector y una conexión (rápida) de red (...podrías llevarte el DP, la unidad cinta hasta el server remoto, instalar todo y realizar la restauración ahí mismo...mmm).
Una solución de compromiso consiste en instalar y actualizar todo el sistema operativo, instalar binarios de herramientas externas y luego aplicar los backups de configuraciones ("esqueletos") antes mencionados. Esto último facilitaría mucho un DI en servers remotos, pero hay que contar con un enlace razonable a Internet para actualizar el SO (vía VPN se podría conectar Data Protector y realizar los transportes necesarios más rápidamente que usando los típica y potencialmente más lentos enlaces WAN; y sí, el operador on-site debería ser capaz de configurar este link VPN o seguir instrucciones paso a paso, queda anotado como ítem del manual de procedimientos DI).
Definitivamente la imposibilidad de configurar sets de Bare Metal (aunque fueran a discos/storage, disponibles para grabar a medios trasladables vía camión por ejemplo), va a complicar en exceso una restauración remota, aunque no mucho más de lo que sería el caso si se estuviera usando software FOSS (baks .tar.bz2 en un dvd por ejemplo). Recuerdo que existe software FOSS que permite realizar backups bare metal, a dvd usualmente, pero normalmente es complicado de manejar para operadores y debe ser corrido on-site sobre el servidor.
No hay que olvidar el amplio soporte para librarías y dispositivos de almacenamiento para grandes volumenes de información, así como la facilidad de configuración y administración de dichos recursos, algo que en soluciones FOSS y/o manuales puede dar dolores de cabeza si no se planifica con excesivo cuidado.
En conclusión las caracterísiticas técnicas puntuales que pueden llevar a elegir DP son sus características avanzadas de administración vía GUI. Adicionalmente y ello es crítico en el momento de la selección de herramientas y hardware, DP brinda una lista de soporte de hardware en el que el selector tiene garantizado la integración fina con la herramienta y sus funciones administrativas.
Lo que puede ser realmente útil es la capacidad de administración del sistema casi a puro golpe de click, ello si bien no incorpora gran ganancia para los *nix users acostumbrados a navegar entre puertos ssh y largos archivos de configuración de herramientas de backup y administración, en cambio deja al soft en posición perfecta para ser un punto de operación de infraestructura: ya habiendo montado eficazmente la infraestructura de backup y con los manuales de procedimientos bien aceitados (y lo más cortos posible), se puede asignar la tarea de realización y control de backups a operadores, incluso a varios, ya que el subset de skills necesario para operar Data Protector es mínimo (vs. el necesario para instalar, configurar y administrar). Para ello el software colabora con la capacidad de incorporar al sistema credenciales para usuarios de menor privilegio.
Lamentablemente, un soft de backup de este nivel implementado en una gran infraestructura (desde decenas de servidores en adelante), tiende a necesitar un poco más de atención que la de un operador. Por ello es recomendable limitar las funciones de los operadores a celdas de backup a lo sumo (una celda en Data Protector es equivalente a un servidor de backup y puede interconectarse varias celdas en un solo gran sistema).
La tarea para el (verdadero) administrador consiste entonces sí en subir varios niveles de dificultad y avanzar en el control de las posibilidades problematicas que estén dadas según el nivel de complejidad en el subconjunto de funciones de Data Protector elegidas para ser usadas en una implementación particular (en difícil usar el 100%). Igualmente esto se puede planificar y documentar apropiadamente y así no estaremos nunca en situación de verificar los posibles problemas en el marco del 100% de las posibilidades funcionales de la herramienta.
Una limitación práctica de Data Protector dada desde antes de configurar nada: no soporta scheduling ala CRON, no se puede configurar la herramienta para correr backups, por ejemplo, todos los primeros lunes de cada mes...a menos que se configure doce veces las fechas del año que coinciden con el primer lunes de cada mes (y así sucesivamente, año a año). Esto a la versión 6, al último parche disponible hace un par de días cuando terminamos el curso.
Otra limitación práctica: el soporte para backup en Linux, en herramientas FOSS (DB Postgresql, DB Mysql, etc.), y en tareas de DI (Disaster Recovery) está a la misma altura que la de cualquier software de backup FOSS (Amanda y Bacula por ejemplo). Ninguna de las funciones de backup en línea para software está soportada para varias DB FOSS, ni para la mayoría de las herramientas comerciales típicas en sus versiones para Linux.
En particular para mi diseño de implementación particular, voy a tener que prescindir del uso del scheduler de Data Protector y correr los sets de backup configurados desde el server vía CRON. Es decir, en la práctica es exactamente lo mismo que correr los backups vía scripting+CRON (añadiendo catalogos y compresión con tar.bz2 opcionalmente).
La característica de backup on-line para herramientas puede suplirse con snapshots LVM por ejemplo, haciendo un uso adecuado de las características de backups y consolidaciones virtuales en Data Protector. Adicionalmente es para considerar la situación en que un software/servicio particular es "snapshoteado" y luego traído de vuelta a la vida (ciertamente en un /etc/init.d/servicio start, manual), luego de una restauración, a poner cuidado entonces de a qué le aplicamos snapshots y hacer testing exhaustivo (la mayoría del soft, FOSS o no, no tiene referencias de este tipo de stop-start de funciones, más allá de comentarios en foros).
Las características puntuales de backup y restauración en Linux de Data Protector que ya se aprecian desde los datasheets y ahora veo confirmadas son el que permite realizar backups mediante agentes, seleccionando vía click desde un servidor central qué directorios y/o archivos se quiere resguardar. En el momento de la restauración los agentes podrán sobreescribir o no archivos, a elección del admin u operador.
Volviendo un poco a las ausentes características de DI (Disaster Recovery) para Linux, veo que en el momento de restaurar un server desde cero, no habrá posibilidad de restauración Bare Metal directo desde un dispositivo externo (disco, usb, cinta), sino que habrá que instalar el SO (y ello implicará su correspondiente configuración y actualización), luego el agente DP, realizar la conexión con el server DP y luego sí proceder a la restauración de casi seguramente centenares de gigas vía un enlace de red (algo que se complica cuando tienes tu server a restaurar a varios centenares de kilométros del punto de origen de la comunicación vía TCP).
Esto último caso de restauración remota es parcialmente solucionable backupeando un "esqueleto" en varios sets de backups, uno por server. Cada esqueleto de configuración permitiría bajar bastante el downtime evitando bajar a configurar /etc y otros directorios y archivos (sea vía CLI o con GUIs de administración), de configuración si hubiera algun otro soft externo a la distribución implementado.
Quedaría pendiente entonces la cuestión de la imposibilidad práctica de backpear los binarios (parte de los cuales se debería actualizar regularmente, vía parches de seguridad principalmente) para una restauración vía medios externos (dvd, usb, cinta) e independientes de Data Protector y una conexión (rápida) de red (...podrías llevarte el DP, la unidad cinta hasta el server remoto, instalar todo y realizar la restauración ahí mismo...mmm).
Una solución de compromiso consiste en instalar y actualizar todo el sistema operativo, instalar binarios de herramientas externas y luego aplicar los backups de configuraciones ("esqueletos") antes mencionados. Esto último facilitaría mucho un DI en servers remotos, pero hay que contar con un enlace razonable a Internet para actualizar el SO (vía VPN se podría conectar Data Protector y realizar los transportes necesarios más rápidamente que usando los típica y potencialmente más lentos enlaces WAN; y sí, el operador on-site debería ser capaz de configurar este link VPN o seguir instrucciones paso a paso, queda anotado como ítem del manual de procedimientos DI).
Definitivamente la imposibilidad de configurar sets de Bare Metal (aunque fueran a discos/storage, disponibles para grabar a medios trasladables vía camión por ejemplo), va a complicar en exceso una restauración remota, aunque no mucho más de lo que sería el caso si se estuviera usando software FOSS (baks .tar.bz2 en un dvd por ejemplo). Recuerdo que existe software FOSS que permite realizar backups bare metal, a dvd usualmente, pero normalmente es complicado de manejar para operadores y debe ser corrido on-site sobre el servidor.
No hay que olvidar el amplio soporte para librarías y dispositivos de almacenamiento para grandes volumenes de información, así como la facilidad de configuración y administración de dichos recursos, algo que en soluciones FOSS y/o manuales puede dar dolores de cabeza si no se planifica con excesivo cuidado.
En conclusión las caracterísiticas técnicas puntuales que pueden llevar a elegir DP son sus características avanzadas de administración vía GUI. Adicionalmente y ello es crítico en el momento de la selección de herramientas y hardware, DP brinda una lista de soporte de hardware en el que el selector tiene garantizado la integración fina con la herramienta y sus funciones administrativas.
sábado, 6 de septiembre de 2008
Personalización de solución de backup en servers Linux
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.
lunes, 7 de abril de 2008
Backups con software de código abierto en PyMEs
Mientras preparo una ponencia sobre backups con software libre estoy viendo algunos temas interesantes para tratar. Conversando con un amigo recordé que las soluciones de backup de código abierto tienen mucho que ofrecer a las redes de PyMEs, donde el principal actor es la pc cliente.
En una LAN empresarial puede encontrarse mucho hardware en la actualidad: pcs, impresoras de red, switches L2/L3, routers, gateways appliances de web filtering/seguridad, pequeños servidores, etc. Sin embargo los datos primarios a resguardar permanecen prioritariamente en los directorios privados no compartidos de las pcs cliente, típicamente Mis Documentos en la pc del gerente y/o de la secretaria del mismo (más algún directorio compartido abierto público general también, pero con datos menos importantes). Otro conjunto de datos importante a resguardar está en la base/s de datos del servidor que usualmente corre herramientas empresariales de bajo ratio de crecimiento en disco y por ello se suele ver servers con hardware de pc o modelos básicos de líneas de hard de server.
El software de backup tiene dos tareas allí, resguardar los datos de los directorios importantes de las pcs cliente y la BD empresarial.
Todo ello en un ambiente donde la conectividad de red nos permite llegar de modo simple a todos los nodos, sino directamente por medio del switch, sí indirectamente mediante políticas L2 y/o L3 (Layer 2/Layer 3), que nos den acceso, al menos en intervalos de tiempo (para minimizar las implicaciones potenciales como riesgo en la seguridad). Y todo ello en ambiente relajado de L8 donde todo se resuelve cruzando un par de cubículos hacia el despacho del jefe y mediante autorización verbal, a diferencia de grandes redes y datacenters donde suele nos espera una laboriosa tarea al cumplimentar los lineamientos de las diferentes políticas y controles hasta llegar a obtener el nivel de acceso requerido a clientes y servers para realizar las tareas de backup.
En este entorno "liberal" de sistemas, una solución de backup de código abierto se implementa rápidamente, inicialmente añadiendo a los sets de backup los directorios de los clientes y la BD y luego avanzando a hacia una política de disaster recovery del server y de los clientes relevantes para la continuidad de los procesos de negocios, normalmente con un resguardo (altamente automatizado, incluso para que lo pueda realizar el usuario), para restauración bare metal, mensual o semanal según la criticidad de los datos de los equipos.
En particular, la clave de la velocidad de la implementación radica en que las pc cliente son clientless (no es necesario instalar ningun software cliente para realizar los backups), y se toma los datos directamente mediante el uso de los directorios compartidos y si no estuvieran compartidos explícitamente, se puede llegar a ellos con las correspondientes credenciales de administrador del equipo y mediante los shares administrativos que están habilitados por defecto normalmente, excepto que hubiere algun tipo de firewall que no sea el de Windows, ya que este último habilita el acceso a los shares administrativos mediante la excepción configurada en el firewall necesaria para acceder a otros shares, aún cuando no se comparta ningun directorio.
En cuanto al servidor, si fuera Windows, se puede seguir usando los shares administrativos (asumo que no tendría nada compartido), y si estuvieran deshabilitados y/o bloqueados por un firewall (una rara demostración de buenas prácticas de seguridad para una PyME), se puede solucionar con poco de scheduling en el mismo server habilitando puertos y servicios necesarios en una ventana de tiempo apropiada para la transferencia de la información. El scheduling podría ser muy simple, o podría escalar hasta tener una miniaplicacion basada en scripting que abriera/habilitara puertos y servicios on-demand (por ejemplo, lockeando el server al finalizarse la sesión de copia de los archivos desde la ip del servidor de backup). Adicionalmente para asegurar la imposibilidad de acceder (aún teniendo las credenciales del server de backup), desde las pcs cliente, un hipotético script podría, por ejemplo, llegar a bloquear comunicaciones con todas las ip que no sean la/s del server de backup durante la ventana de tiempo de la transferencia (posiblemente necesites y sea recomendable también usar un producto de firewall diferente/mejor que el incluído en los winservers y deberías verificar que ese soft fuera scripteable también). Estamos asumiendo que la ventana de tiempo de resguardo del server de BD está fuera del horario normal en que los clientes entablan sesiones con la BD, por ejemplo, de madrugada.
Según el hardware que estemos utilizando inclusive, hoy en día puede hablarse de llegar a implementar un pequeño server virtual linux dentro del server windows si hiciera falta y según los requerimientos del entorno de backup y del server en sí.
Como pueden ver, de momento, la implementación de un server de backup completo (SO+software de backup), es la principal desventaja del uso de software libre de backup, ya que necesitamos un *nix (Linux, Solaris, BSDs), forzosamente para correr la mayoría del software que califica como apto para una solución semi-compleja en una PyME: Amanda, Bacula, etc. Pero aún así, y considerando los costos de adquirir una solución comercial PyME no siempre completa (normalmente solo incluye soporte y no capacitación), los potenciales costos de consultoría, implementación y capacitación en el manejo del software de backup de código abierto pueden llegar a ser competitivos aún si hubiera que tercerizar (pagar), su adopción.
De nuevo aclaro que en una LAN PyME balanceamos limitados recursos (de harware y/o económicos), con amplias posibilidades operativas y bajos requerimientos de seguridad IT en general.
En una LAN empresarial puede encontrarse mucho hardware en la actualidad: pcs, impresoras de red, switches L2/L3, routers, gateways appliances de web filtering/seguridad, pequeños servidores, etc. Sin embargo los datos primarios a resguardar permanecen prioritariamente en los directorios privados no compartidos de las pcs cliente, típicamente Mis Documentos en la pc del gerente y/o de la secretaria del mismo (más algún directorio compartido abierto público general también, pero con datos menos importantes). Otro conjunto de datos importante a resguardar está en la base/s de datos del servidor que usualmente corre herramientas empresariales de bajo ratio de crecimiento en disco y por ello se suele ver servers con hardware de pc o modelos básicos de líneas de hard de server.
El software de backup tiene dos tareas allí, resguardar los datos de los directorios importantes de las pcs cliente y la BD empresarial.
Todo ello en un ambiente donde la conectividad de red nos permite llegar de modo simple a todos los nodos, sino directamente por medio del switch, sí indirectamente mediante políticas L2 y/o L3 (Layer 2/Layer 3), que nos den acceso, al menos en intervalos de tiempo (para minimizar las implicaciones potenciales como riesgo en la seguridad). Y todo ello en ambiente relajado de L8 donde todo se resuelve cruzando un par de cubículos hacia el despacho del jefe y mediante autorización verbal, a diferencia de grandes redes y datacenters donde suele nos espera una laboriosa tarea al cumplimentar los lineamientos de las diferentes políticas y controles hasta llegar a obtener el nivel de acceso requerido a clientes y servers para realizar las tareas de backup.
En este entorno "liberal" de sistemas, una solución de backup de código abierto se implementa rápidamente, inicialmente añadiendo a los sets de backup los directorios de los clientes y la BD y luego avanzando a hacia una política de disaster recovery del server y de los clientes relevantes para la continuidad de los procesos de negocios, normalmente con un resguardo (altamente automatizado, incluso para que lo pueda realizar el usuario), para restauración bare metal, mensual o semanal según la criticidad de los datos de los equipos.
En particular, la clave de la velocidad de la implementación radica en que las pc cliente son clientless (no es necesario instalar ningun software cliente para realizar los backups), y se toma los datos directamente mediante el uso de los directorios compartidos y si no estuvieran compartidos explícitamente, se puede llegar a ellos con las correspondientes credenciales de administrador del equipo y mediante los shares administrativos que están habilitados por defecto normalmente, excepto que hubiere algun tipo de firewall que no sea el de Windows, ya que este último habilita el acceso a los shares administrativos mediante la excepción configurada en el firewall necesaria para acceder a otros shares, aún cuando no se comparta ningun directorio.
En cuanto al servidor, si fuera Windows, se puede seguir usando los shares administrativos (asumo que no tendría nada compartido), y si estuvieran deshabilitados y/o bloqueados por un firewall (una rara demostración de buenas prácticas de seguridad para una PyME), se puede solucionar con poco de scheduling en el mismo server habilitando puertos y servicios necesarios en una ventana de tiempo apropiada para la transferencia de la información. El scheduling podría ser muy simple, o podría escalar hasta tener una miniaplicacion basada en scripting que abriera/habilitara puertos y servicios on-demand (por ejemplo, lockeando el server al finalizarse la sesión de copia de los archivos desde la ip del servidor de backup). Adicionalmente para asegurar la imposibilidad de acceder (aún teniendo las credenciales del server de backup), desde las pcs cliente, un hipotético script podría, por ejemplo, llegar a bloquear comunicaciones con todas las ip que no sean la/s del server de backup durante la ventana de tiempo de la transferencia (posiblemente necesites y sea recomendable también usar un producto de firewall diferente/mejor que el incluído en los winservers y deberías verificar que ese soft fuera scripteable también). Estamos asumiendo que la ventana de tiempo de resguardo del server de BD está fuera del horario normal en que los clientes entablan sesiones con la BD, por ejemplo, de madrugada.
Según el hardware que estemos utilizando inclusive, hoy en día puede hablarse de llegar a implementar un pequeño server virtual linux dentro del server windows si hiciera falta y según los requerimientos del entorno de backup y del server en sí.
Como pueden ver, de momento, la implementación de un server de backup completo (SO+software de backup), es la principal desventaja del uso de software libre de backup, ya que necesitamos un *nix (Linux, Solaris, BSDs), forzosamente para correr la mayoría del software que califica como apto para una solución semi-compleja en una PyME: Amanda, Bacula, etc. Pero aún así, y considerando los costos de adquirir una solución comercial PyME no siempre completa (normalmente solo incluye soporte y no capacitación), los potenciales costos de consultoría, implementación y capacitación en el manejo del software de backup de código abierto pueden llegar a ser competitivos aún si hubiera que tercerizar (pagar), su adopción.
De nuevo aclaro que en una LAN PyME balanceamos limitados recursos (de harware y/o económicos), con amplias posibilidades operativas y bajos requerimientos de seguridad IT en general.
Suscribirse a:
Entradas (Atom)