Skip to end of metadata
Go to start of metadata

Índice

0 Visión general

WBS Airback®  provee una solución unificada para la consolidación de almacenamiento y archivado de datos, así como la gestión de la seguridad de los mismos, permitiendo establecer diferentes niveles de acceso a estos en virtud de sus requerimientos de disponibilidad.


WBS Airback®  supone una nueva generación en los sistemas de gestión y protección del almacenamiento, incluyendo funcionalidades capaces de gestionar almacenamiento heterogéneo para su uso como almacenamiento primario o como repositorio de backup, así como funcionalidades para la gestión del ciclo de vida del backup. Dichas funciones son gestionadas de una manera muy sencilla debido a que abstraen parte de la complejidad técnica y conceptual de los mencionados servicios.

WBS Airback® está basado en una plataforma de tipo appliance que integra todos los componentes lógicos necesarios en una única plataforma. No requiere la adquisición ni instalación de sistemas operativos ni aplicaciones de terceros para funcionar. Puede adquirirse como un appliance físico incluyendo la plataforma hardware adecuada a cada necesidad, o como un appliance virtual incluyendo los ficheros estándar necesarios para desplegar una máquina virtual en las principales plataformas de virtualización.

A través de una sencilla interfaz web accesible desde cualquier navegador, se puede realizar toda la administración y configuración del sistema y de sus funcionalidades principales.

Desde dicha interfaz se realiza la actualización de versiones, actualizaciones, parches, etc. con tan sólo dos o tres clicks.

El esquema general de la solución es el siguiente:

Figura 0: Visión general WBSAirback®

En el presente documento se presenta el módulo de backup sobre dispositivos de almacenamiento nube en WBSAirback®.

1. Introducción

En los últimos años en el mundo de las TIC han ido proliferando diversas tendencias tecnológicas de nueva generación. Estas tendencias tratan de aportar nuevos paradigmas estructurales y funcionales  que persiguen la simplificación y mejora de cualquier solución tecnológica a todos los niveles. Una de las tendencias más importantes sin duda es el 'Cloud' o 'Nube'. Este tipo de paradigma tecnológico lleva entre nosotros mucho tiempo, pero es mucho más reciente su adopción masiva, donde la mejora física de las conexiones y los equipos ha permitido un aprovechamiento más eficiente y ofrecer mejoras reales respecto al uso de estas tecnologías frente a opciones más clásicas. 

Desde la perspectiva de las soluciones de backup o almacenamiento, el envío o recuperación de datos desde nubes públicas o privadas presenta numerosas ventajas, pero también ciertos desafíos. A nivel administrativo, no cabe duda de que el almacenamiento nube puede ser la opción más dinámica y flexible ante cambios relativos a la volumetría de los datos, ya que este tipo de tecnologías presentan una gran facilidad a la hora de añadir o restar recursos en un entorno determinado. A nivel de coste, uno de ls aspectos clave para cualquier solución tecnológica, y si hablamos de almacenar datos de backup, también puede resultar una opción más que interesante, pues la subida de información suele resultar una opción bastante económica, no tanto su recuperación. En las soluciones de backup, obviamente el ratio de información almacenada en relación a la información recuperada es realmente grande. No obstante, también existen aspectos a tener en cuenta como la velocidad de los canales de comunicación, dificultades para usar tecnologías como la deduplicación o aspectos legales de privacidad. 

WBSAirback®, a través de sus módulos de almacenamiento de backup en nube ofrece compatibilidad con diversas tecnologías y proveedores Cloud, tanto en modo público como privado. En este documento se detallan las características y modos de uso de estos módulos y se ofrecen best-practices y recomendaciones para maximizar el uso de estas tecnologías, tratando siempre de minimizar los costes.

Nota: Además de este plugin, WBSAirback® dispone de otro modo de trabajo con dispositivos de almacenamiento S3 directamente en su capa de almacenamiento. Para más información, por favor, consulte el manual del producto.

2. Características

Uno de los principales problemas con el almacenamiento de datos en la nube es que la transmisión de datos desde la nube y hacia la nube es muy lenta en comparación con la misma hacia dispositivos de disco, redes SAN o librerías.  Los plugins de almacenamiento en nube de WBSAirback® ofrecen mecanismos para finalizar rápidamente los trabajos y poder realizar la transmisión hacia la nube posteriormente, en background.

Los tradicionales volúmenes de backup (almacenados en Conjuntos de backup) son divididos en partes mucho más pequeñas que se almacenan localmente en un dispositivo de disco que se usará como 'Caché nube'. Después es posible que se suban inmediatamente estas partes (al finalizar el trabajo) o hacerlo de forma global a través de una rutina general. Una vez las partes han sido subidas a la nube, pueden ser truncadas de la caché, o bien quedarse ahí duplicadas para ofrecer restauraciones más rápidas. El truncado de caché es otro proceso que puede ser configurado para que se ejecute de forma automática durante la ejecución de un trabajo, para que se ejecute después de la ejecución o bien para que se trunque manualmente o a través de un proceso administrativo global. 

A continuación, se muestra visualmente la arquitectura descrita:

Figura 2.1: Arquitectura plugin backup sobre dispositivos nube

3. Compatibilidad

Actualmente, el plugin de backup sobre dispositivos cloud se presenta en los siguientes formatos:

  • Backup a Cloud S3. Compatible con:
    • Sistemas de almacenamiento de Amazon basado en S3
    • Cualquier cabina genérica que trabaje con el protocolo S3
    • Ceph Object Storage, a través de la pasarela S3
    • Swift3 Middleware de OpenStack Swift
  • Backup a Google Cloud Storage. Compatible con:
    • Sistema de almacenamiento Google Cloud Storage
  • Backup a Azure. Compatible con:
    • Sistema de almacenamiento Azure Blob Storage
  • Backup a Oracle Cloud. Compatible con:
    • Sistema de almacenamiento Oracle Cloud Object Storage

Importante: Cada uno de los formatos soportados tiene su propio código de servicio individual asociado. Es necesario adquirir cada plugin de forma separada. Puede consultar sus códigos de servicio asociados en la pestaña de estado o de suscripción:

Figura 3.1: Códigos de servicio

Ninguno de los plugins es compatible con deduplicación. No obstante, esa es la única excepción en cuanto a compatibilidad con otras funciones de WBSAirback®. Cualquier tipo de backup o copia, con todas sus funciones asociadas, es compatible con este plugin de almacenamiento de backup en nube.

4. Gestión de repositorios nube

El plugin de backup sobre dispositivos cloud permite definir repositorios nube, desde el menú general de repositorios de WBSAirback®:

Figura 4.1: Menú repositorios

A partir de este menú es posible añadir, editar, copiar o eliminar un repositorio cloud:

Figura 4.2: Lista repositorios cloud

6. Conjuntos, volúmenes y Partes Cloud

Los conjuntos asociados a repositorios nube tienen ciertas particularidades con respecto a sus homónimos. A continuación se detalla cada una de ellas.

6.1.  Volúmenes de un conjunto cloud

La diferencia más importante que presentan los conjuntos cloud aparece en cuanto al formato de almacenamiento de los volúmenes de backup:

  • Los backups a disco almacenan sus volúmenes en forma de ficheros: un fichero para cada volumen, o bien dos, en el caso de que se utilice deduplicación ZFS.
  • En el caso de los conjuntos asociados a repositorios nube, los volúmenes pasan a ser directorios sin tamaño, que almacenan las diferentes partes que componen un volumen. 

El tamaño de las partes cloud de un volumen viene establecido por lo que ocupa o bien por el máximo definido en el repositorio (Tamaño máximo de partes).

Por otro lado, un volumen cloud puede encontrarse en varias situaciones:

  • Presente en la caché local del disco, pero no en la nube (aún no fue subido)
  • Presente en nube, pero no en caché (fue subido y posteriormente la caché fue truncada)
  • Presente en ambos lugares: caché y nube.
  • Presente en la nube, pero truncado.

Para visualizar el estado de cada volumen, los conjuntos cloud muestran en el listado de volúmenes un campo especial: 'Partes en cloud', que nos indica si las partes que componen cada volumen se han subido o no a la nube.

Figura 6.1.1: Volúmenes cloud

Además de la ubicación general del volumen, es posible entrar al detalle de un volumen dado y consultar el estado de sus partes utilizando el botón de 'Partes cloud':

Figura 6.1.2: Partes cloud

En la ventana de 'Partes cloud' podremos ver exactamente donde se encuentra cada parte, su tamaño y fecha de modificación.

6.2. Configuración de un conjunto cloud

En un conjunto cloud es necesario configurar el parámetro 'Duración de uso del volumen' para especificar el máximo tiempo que estará abierto un volumen cloud, de forma que podamos limitar el número de volúmenes generados. 

Otro aspecto a tener en cuenta es que un conjunto cloud dispone de una directiva adicional especial: Retención caché cloud. Esta directiva indica el tiempo que deben permanecer los datos en la caché local del repositorio nube. Recordemos que el método de truncado de la caché se configura en las opciones del repositorio nube (Configuración de caché).

Por último, tal y como fuerza la interfaz en tiempo de creación (aunque sería posible modificar cualquier aspecto posteriormente al editar), también se recomienda limitar el número de trabajos por volumen a 1.

La siguiente imagen expone un ejemplo de configuración:

Figura 6.2.1: Pool Cloud

7. Rutina general de subida a nube y truncado de caché

El almacenamiento en nube utilizando cualquiera de los plugin cloud permite diversos modos de trabajo en cuanto a la subida de los datos a nube. Podemos elegir entre:

  1. Subir los datos en cuanto se escribe cada parte de cada volumen.
  2. Subir los datos al finalizar cada trabajo (al finalizar su escritura a disco). Este es el método recomendado en general.
  3. Subir los datos de forma global, en una rutina independiente.

El método de subida se configura en el repositorio nube, opción: Configuración de caché > Método de subida.

Figura 7.1: Método de subida en un repositorio cloud

La elección de una estrategia u otra, vendrá dada por las característica de cada despliegue. En general, se recomienda incluir la subida dentro de cada trabajo porque de esta manera podemos controlar de forma granular el resultado real de un trabajo que se pretende subir a la nube, además de separar el trabajo en 2 fases (fase backup y fase subida). La estrategia de subir cada parte, por su parte, asegura que la subida se produzca lo antes posible, pero podríamos estar subiendo partes de un trabajo que falle posteriormente, por lo que es más recomendable hacer la subida en una fase independiente, en general. Por otro lado, con la rutina global, puede ser más difícil hacer el seguimiento de qué trabajos están efectivamente subidos a la nube o no, ya que el indicador de 'completado con éxito' de cada trabajo, no nos incluirá esta información de subida.

Si la estrategia elegida es la tercera, la rutina general que implementa WBSAirback para subir los datos a nube es el trabajo especial 'cloud-storage-upload' que encontraremos listado en el cliente airback-control:

Figura 7.2: Configuración de cloud-storage-upload


Esta rutina se encargará comprobar los datos almacenados en conjuntos cloud y subir cualquiera de ellos que no haya sido subido previamente. Es importante mencionar que, aunque se utilice la estrategia 1 ó 2, también es necesario planificar esta tarea de subida, pues cualquier trabajo que no haya podido completar su subida, pero sí terminar con éxito, también sería procesado por esta rutina general y sus datos serían subidos a la nube.

Es posible consultar el progreso de esta rutina abriendo su log, como cualquier otro trabajo. No obstante, esta rutina trabaja subiendo de forma global todos los volúmenes de cada pool. Esto hace que el progreso de subida de cada pool solamente se muestre una vez ha finalizado el mismo, por lo que es posible percibir tiempos largos sin que aparezca nueva información en el log mientras la rutina se encuentra en ejecución. A continuación, un ejemplo de log de subida:

Figura 7.3: Log de subida de volúmenes

La rutina general cloud-storage-upload, no solamente se encarga de subir los archivos a cada dispositivo nube respectivo, sino que también se encarga de truncar las cachés. Al igual que para la subida, disponemos de diversas opciones:

  • Truncar cada volumen al finalizar su subida a la nube.
  • Truncar todos los volúmenes de un trabajo al finalizar el mismo. Este es el método recomendado en general.
  • Truncar de forma global con una rutina independiente.

El método de subida se configura en el repositorio nube, opción: Configuración de caché > Método truncado de caché.

Figura 7.4: Método de truncado de caché en repositor

La aplicación de una estrategia u otra, al igual que hemos comentado en la subida, dependerá de las características de cada despliegue. Si elegimos el truncado tras la subida de cada volumen, tendremos una caché con el menor tamaño posible, pero los trabajos tendrán una duración algo mayor. Si elegimos el truncado tras finalizar cada trabajo, la caché seguirá siendo pequeña, pero los trabajos finalizarán en el menor tiempo posible. Si truncamos con la rutina general, mantendremos más tiempo los datos en caché, lo cual puede ser adecuado si queremos mantener un nivel adicional en nuestra estructura de tiering, donde una restauración de datos recientes pueda utilizar datos en disco y no necesariamente conectar a la nube (evitando los posibles costes asociados).

El truncado de caché deja entradas de este tipo en el log del trabajo cloud-storage-upload:

Figura 7.5: Truncado de caché

El truncado de caché, en el modo de rutina general que se corresponde con Método de truncado de caché Manual, se ejecuta respetando el período de retención de caché cloud definido en el pool correspondiente.

Figura 7.6: Retención de caché

Por lo tanto, se purga cualquier volumen que haya expirado o bien se haya purgado manualmente.

Importante

Es importante resaltar que la caché de truncado respetará su retención siempre que se utilice la opción Manual y este método general de cloud-storage-upload. Si se selecciona cualquiera de las otras 2 opciones, cada trabajo truncará su caché inmediatamente, ya sea al terminar de subir cada parte o al finalizar el job, sin aplicar ningún tipo de retención.

8. Ejecución de trabajos sobre dispositivos cloud

Para que un trabajo escriba en un dispositivo cloud, es necesario haber configurado previamente el repositorio cloud asociado y asociar un pool al mismo, configurando su retención de caché cloud correspondiente, duración de uso de volumen, etc.

Una vez hemos completado la configuración, previa, podremos asociar cualquier trabajo a un pool cloud para que escriba directamente en él. También es posible utilizar un pool cloud como destino de copia de otro pool origen. En general, este es un caso de uso muy adecuado, donde guardamos datos de backup en un primer nivel en disco, para después enviar una copia de una retención más larga al dispositivo nube, aplicando lo que se conoce como Tiering de backup. Para más información sobre cómo configurar un trabajo o una rutina de copia, por favor, consulte el manual del producto.

Como se ha explicado en secciones anteriores secciones de este documento, es posible que un trabajo suba directamente archivos a la nube, o que esta tarea se realice de forma global por la rutina cloud-storage-upload. Si es el propio trabajo el que sube los datos (ya sea al finalizar el mismo, o al finalizar la escritura en disco de cada parte), el resultado de la subida afectará al resultado del trabajo. Por lo tanto, una subida fallida hará que el resultado del trabajo no sea 'Completed succesfully'.

Es posible hacer el seguimiento de la subida utilizando el log:

Figura 8.1: Subida desde job

De la misma manera, un trabajo puede realizar truncados de caché cloud o no. En caso de hacerlo desde el job el truncado ocurre de forma totalmente transparente y no aparecerá registro en el log

9. Recuperación de trabajos sobre dispositivos cloud

Durante una restauración, si los volúmenes implicados en los archivos a restaurar conservan sus partes en la caché cloud, esas partes serán utilizadas sin contactar con la nube. En caso contrario, se contactará con la nube para descargar solamente partes necesarias de los volúmenes requeridos para completar la restauración. En este sentido, el proceso es eficiente y solamente descargará aquello que necesite y no esté en la caché local.

Debido a los costes asociados a las descargas en la mayoría de proveedores cloud, es recomendable configurar el tamaño de las partes a un valor pequeño, que permita que no se descargue una cantidad de datos superior a la necesaria en una restauración, provocando costes innecesarios. El tamaño de las partes se configura en la sección de parámetros avanzados de un repositorio de tipo cloud:

Figura 9.1: Tamaño de partes cloud

El proceso de descarga, durante una restauración, sucede en background mientras el trabajo de restauración se está ejecutando. No obstante, es posible consultar los datos descargados en el log del trabajo de restauración, a medida que estos se van completando:

Figura 9.2: Log de restauración con descarga

Para minimizar el uso de la nube en las restauraciones, una posible estrategia es definir un período de retención amplio en la caché local y configurar el método de truncado de caché en modo 'Manual'. De esta forma los datos recientes permanecerán más tiempo en la caché local y será menos probable la necesidad de realizar descargas.

10. Reciclado y truncado de datos cloud

WBS Airback® gestiona de manera interna y transparente el reciclado de datos en conjuntos asociados a repositorios nube. Por supuesto, la operación de borrado debe comunicarse con la infraestructura cloud correspondiente y eliminar los datos en ese destino, esto será realizado tanto en una operación de borrado manual desde la interfaz de gestión de volúmenes de un conjunto, como a través del borrado automático de la rutina de reciclado 'delete-purged-volumes'.

Al igual que cualquier otro conjunto, para ser candidato dentro del grupo de conjuntos que serán reciclados por el proceso 'delete-purged-volumes' es necesario que el pool tenga desactivado el 'Reciclado automático', así como definido un valor en la directiva 'Duración de uso del volumen' (ambas son las opciones por defecto).

Cuando un volumen cloud es reciclado, veremos entradas en el log del trabajo delete-purged-volumes como las siguientes:

Figura 10.1: Log de truncado

No obstante, existe una diferencia fundamental entre la gestión de volúmenes purgados en disco y los volúmenes purgados en cloud. En pools de tipo cloud se sigue una filosofía de reutilización y no se eliminan volúmenes completamente

El ciclo de reciclado de dispositivos nube es el siguiente:

  • Cuando expira un volumen, se trunca su cache si no se ha hecho antes.
  • Se marca como purgado si no lo está
  • Se truncan los datos en nube, pero el volumen permanece dentro del pool, a diferencia de los volúmenes de repositorios tipo disco.

Cuando un trabajo nuevo entra en ejecución, se buscará primero volúmenes en estado 'Purged'. De encontrar alguno, ese volumen será reutilizado y sólo se creará uno nuevo en caso de no encontrar ninguno en este estado.

Otra característica importante a mencionar sobre el reciclado de datos de repositorios cloud es que todos los repositorios se agrupan en una lista independiente dentro de la rutina delete-purged-volumes. Por lo tanto, los datos cloud se eliminan en paralelo a los datos de la lista de deduplicación y de la lista sin deduplicación.

Es posible eliminar un volumen completamente si utiliza la función manual de 'Eliminar' desde el listado de volúmenes de un pool:

Figura 10.2: Eliminar volumen

Esto truncaría los datos cloud, pero también eliminaría el volumen del catálogo de WBS Airback®.

No obstante, es importante aclarar que WBS Airback® no tiene capacidad para borrar los directorios y ficheros de metadatos que se generan el la nube. Por lo tanto, si eliminamos un volumen de esta forma, el directorio asociado a su volumen y su fichero de metadatos (de 257 Bytes) permanecerán en el dispositivo nube y, si se quieren eliminar, sería necesario que el administrador del recurso cloud proceda accediendo directamente al recurso o a través de cualquier otro medio que considere oportuno.

Por otro lado, el botón de 'Limpiar' en el caso de un pool asociado a dispositivo nube:

Figura 10.3: Limpiar volumen


Realiza el proceso completo de purgado del volumen, es decir, que no sólo lo marca como 'Purged' como en el caso de volúmenes de disco, sino que también lo trunca en el dispositivo nube asociado.

11. Configuración de repositorios

En esta sección se describen las particularidades de configuración de cada tipo de repositorio.

11.1. Parámetros comunes

El formulario de configuración de dispositivos en la nube presenta una serie de elementos comunes de configuración, se cual sea el proveedor nube implicado:

Figura 11.1.1: Formulario de repositorio cloud

Para cualquier repositorio cloud, debemos establecer un nombre único, la descripción es opcional. Una vez seleccionemos el tipo de Driver se habilitarán o deshabilitarán automáticamente los campos apropiados para ese tipo de nube.

El resto de parámetros comunes son:

  • Protocolo: Es necesario indicar si la conexión se realiza por HTTP o por HTTPS
  • Configuración de caché:
    • Volumen de caché: Debemos seleccionar un volúmen interno de WBSAirback si decidimos que la caché cloud de disco debe residir en un volumen del equipo (recomendado)
    • Volumen externo de caché: Nos permite seleccionar un volumen compartido por una plataforma externa (por NFS o CIFS) como volumen de caché, en caso de decidir no utilizar un volumen de caché local.
    • Método truncado de caché: Especifica si se debe eliminar automáticamente los datos locales de caché una vez subidos y cómo. Los datos locales de la caché solamente pueden ser eliminados una vez han sido subidos al recurso Cloud
    • Método de subida: Especifica cuándo se deben subir al recurso Cloud los datos locales almacenados en la caché: Después de escribir cada parte de volúmen, al finalizar cada trabajo o manualmente en la ejecución del script 'cloud-storage-upload'
  • Configuración de repositorio (Parámetros comunes a cualquier repositorio.):
    • Interfaz: Indica la interfaz de comunicación que deben utilizar los clientes al enviar datos a este repositorio.
    • Jobs en paralelo: Limita la cantidad de trabajos que pueden ser ejecutados en paralelo contra este repositorio. El excedente quedaría encolado.
  • Avanzado:
    • Tamaño máximo de partes: Especifica el tamaño máximo de cada parte (archivo) que será almacenado en la caché local, para su posterior proceso de subida final al recurso Cloud.
      • Defina cuidadosamente este parámetro en base a los siguientes criterios:
        • Intente que la parte no sea extremadamente pequeña para no fragmentar excesivamente cada volumen y provocar que las subidas o descargas de cada volumen demoren más.
        • Intente que no sea tan grande como para que una subida o descarga fallida que se debe reintentar suponga un problema temporal
        • Considere el coste de la descarga. Partes más pequeñas hacen que una restauración descargue menos datos y pueda resultar más económica.
      • Los límites de un repositorio en cloud en cuanto a sus partes gestionadas son los siguientes:
        • Máximo número de partes permitidas en un Volumen Cloud: 524288.
        • Máximo tamaño de una sola parte:  17.5TB
    • Máximas descargas concurrentes: Esta directiva limita el número máximo de descargas concurrentes sobre este recurso Cloud
    • Máximas subidas concurrentes: Esta directiva limita el número máximo de subidas concurrentes sobre este recurso Cloud
    • Ancho de banda máximo descarga: Por defecto es ilimitado, pero puede ajustar el ancho de banda para descargas de forma global para este recurso a través de esta directiva
    • Ancho de banda máximo subida: Por defecto es ilimitado, pero puede ajustar el ancho de banda para subidas de forma global para este recurso a través de esta directiva

11.2. Repositorios para dispositivos S3

Para conectarse con un repositorio S3 solamente es necesario completar la configuración del repositorio, seleccionando como Driver el tipo S3. No es necesaria ninguna otra acción previa.

Un repositorio S3 tiene los siguientes parámetros particulares:

Figura 11.2.1: Repositorio S3

  • Región: El recurso Cloud se puede configurar para que utilize un endpoint de una región específica. Esto es un requisito en regiones de AWS-V4. Ejemplo: eu-central-1.
    • El campo es auto-completable con todas las posibles regiones del servicio público de Amazon, por lo que es necesario elegir alguna de las opciones sugeridas en caso de que el servicio sea de Amazon.
  • Host: Especifica el nombre de host a utilizar en la URL. Cada proveedor de servicios Cloud está ubicado en un nombre de host diferente y único
    • El campo es auto-completable con todas las posibles regiones del servicio público de Amazon, por lo que es necesario elegir alguna de las opciones sugeridas en caso de que el servicio sea de Amazon.
  • Estilo de URI: Especifica el estilo de URI utilizado para comunicarse con el proveedor Cloud.
    • Para S3 CEPH se debe indicar 'Path'
    • Para el resto de servicios, en general el valor por defecto 'VirtualHost' es el adecuado.
  • Nombre de bucket: Especifica el nombre de bucket que se debe utilizar en el servicio Cloud. Normalmente es un nombre único que identifica donde desea almacenar sus datos dentro de su servicio Cloud.
    • Ell bucket debe existir previamente a cualquier backup. 
  • Prioridad de transferencia: Cuando se trabaja con Amazon S3 Glacier, esta directiva indica la prioridad de transferencia, cuyos valores se corresponden respectivamente con las capas: Expeditive (Alta), Standard (Media) y Bulk (Baja) del propio servicio de Amazon. La petición de los datos (aquellos no presentes en la capa inicial de S3, porque han sido movidos a Glacier en base a las políticas configuradas en Amazon) se realizará con esta configuración.
  • Retención de re-hidratación: En Amazon S3 Glacier indica los días de retención que deben mantenerse los datos re-hidratados online, una vez estos han sido recuperados por alguna operación de recuperación. Pasado este tiempo, los datos volverán a ser archivados.
  • Clave de acceso: Clave de acceso al bucket
  • Clave secreta: 'Secret' de acceso al bucket

11.2.1. Credenciales en Amazon

Figura 65: Credenciales Amazon S3

Esos dos valores: Access Key ID y Secret Access Key son los que hay que utilizar en la 'Cuenta Cloud' de WBSAirback:

  • Clave de usuario = Access Key ID
  • Clave secreta = Secret Access Key
  • Nota: Estos valores no tienen nada que ver con el email/usuario o password de login de la cuenta AWS.

Por último, resaltar que el nombre de bucket a utilizar en WBSAirback®, en general es el nombre simple que se utilice al crearlo en la cuenta S3 (es decir, no es necesario incluir ningún tipo de prefijo tipo .amazonaws.com).

11.2.2 Sincronización de reloj con Amazon S3

El servicio S3 de Amazon es muy sensible a cualquier diferencia de reloj existente entre el servicio de origen y los servidores de Amazon. Esta particularidad puede llegar a provocar que las subida fallen y se obtengan mensajes de tipo: 

Si esto ocurre, es necesario que configure como servidores NTP de WBSAirback® los propios de Amazon. Para más información, consulte el siguiente enlace: http://www.emind.co/how-to/how-to-fix-amazon-s3-requesttimetooskewed

11.3. Repositorios para dispositivos Google Cloud Storage

Para conectarse con un repositorio Google Cloud es necesario primero seguir un procedimiento de conexión especial a nivel de sistema, donde configuraremos las credenciales y el endpoint oportuno. Después terminaremos la configuración completando la configuración del repositorio.

11.3.1. Administración de servicios Google Cloud Storage

En esta sección se describe brevemente la ubicación en la consola de administración de Google Cloud de los elementos necesarios para poder utilizar el plugin de almacenamiento en nube sobre un repositorio asociado a Google Cloud Storage.

Los servicios de goolge cloud se gestionan desde: console.cloud.google.com

Una vez hemos accedido, los elementos de almacenamiento están accesibles en la opción Storage del menú principal:

Figura 11.3.1.1: Menú Storage

Desde esta sección podremos gestionar los buckets (o segmentos):

Figura 11.3.1.2: Buckets GCloud

11.3.2. Proceso de sistema para conectar con Google Cloud Storage

Para configurar el acceso a un storage google cloud es necesario ejecutar el siguiente comando e introducir la información que se va solicitando:

setup gcloud
sudo -u bacula HOME=/opt/bacula/etc/google gcloud init

A continuación se muestra un ejemplo de sesión, donde tendremos que hacer login con el navegador y pegar un código que generará google automáticamente:

GCloud Install
root@wbsairback:~# sudo -u bacula HOME=/opt/bacula/etc/google gcloud init
Welcome! This command will take you through the configuration of gcloud.

Your current configuration has been set to: [default]

You can skip diagnostics next time by using the following flag:
  gcloud init --skip-diagnostics

Network diagnostic detects and fixes local network connection issues.
Checking network connection...done.                                                                                                                                  
Reachability Check passed.
Network diagnostic passed (1/1 checks passed).

You must log in to continue. Would you like to log in (Y/n)?  Y

Go to the following link in your browser:

    https://accounts.google.com/o/oauth2/auth?redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&prompt=select_account&response_type=code&client_id=32555940559.apps.googleusercontent.com&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fappengine.admin+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcompute+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Faccounts.reauth&access_type=offline


Enter verification code: 4/sgHXNw5bTJtQZUvzmZ0TZ7oK_HbJ1rwzifpgNFk0fXcquKeAYA74lMc
You are logged in as: [jorgegea@gmail.com].

Pick cloud project to use: 
 [1] smartlogin-152516
 [2] Create a new project
Please enter numeric choice or text value (must exactly match list 
item):  1

Your current project has been set to: [smartlogin-152516].

Do you want to configure a default Compute Region and Zone? (Y/n)?  Y

Which Google Compute Engine zone would you like to use as project 
default?
If you do not specify a zone via a command line flag while working 
with Compute Engine resources, the default is assumed.
 [1] us-east1-b
 [2] us-east1-c
 [3] us-east1-d
 [4] us-east4-c
 [5] us-east4-b
 [6] us-east4-a
 [7] us-central1-c
 [8] us-central1-a
 [9] us-central1-f
 [10] us-central1-b
 [11] us-west1-b
 [12] us-west1-c
 [13] us-west1-a
 [14] europe-west4-a
 [15] europe-west4-b
 [16] europe-west4-c
 [17] europe-west1-b
 [18] europe-west1-d
 [19] europe-west1-c
 [20] europe-west3-c
 [21] europe-west3-a
 [22] europe-west3-b
 [23] europe-west2-c
 [24] europe-west2-b
 [25] europe-west2-a
 [26] asia-east1-b
 [27] asia-east1-a
 [28] asia-east1-c
 [29] asia-southeast1-b
 [30] asia-southeast1-a
 [31] asia-southeast1-c
 [32] asia-northeast1-b
 [33] asia-northeast1-c
 [34] asia-northeast1-a
 [35] asia-south1-c
 [36] asia-south1-b
 [37] asia-south1-a
 [38] australia-southeast1-b
 [39] australia-southeast1-c
 [40] australia-southeast1-a
 [41] southamerica-east1-b
 [42] southamerica-east1-c
 [43] southamerica-east1-a
 [44] asia-east2-a
 [45] asia-east2-b
 [46] asia-east2-c
 [47] asia-northeast2-a
 [48] asia-northeast2-b
 [49] asia-northeast2-c
 [50] europe-north1-a
Did not print [12] options.
Too many options [62]. Enter "list" at prompt to print choices fully.
Please enter a value between 1 and 62, or a value present in the list:  1

Your project default Compute Engine zone has been set to [us-east1-b].
You can change it by running [gcloud config set compute/zone NAME].

Your project default Compute Engine region has been set to [us-east1].
You can change it by running [gcloud config set compute/region NAME].

Created a default .boto configuration file at [/opt/bacula/etc/google/.boto]. See this file and
[https://cloud.google.com/storage/docs/gsutil/commands/config] for more
information about configuring Google Cloud Storage.
Your Google Cloud SDK is configured and ready to use!

* Commands that require authentication will use jorgegea@gmail.com by default
* Commands will reference project `smartlogin-152516` by default
* Compute Engine commands will use region `us-east1` by default
* Compute Engine commands will use zone `us-east1-b` by default

Run `gcloud help config` to learn how to change individual settings

This gcloud configuration is called [default]. You can create additional configurations if you work with multiple accounts and/or projects.
Run `gcloud topic configurations` to learn more.

Some things to try next:

* Run `gcloud --help` to see the Cloud Platform services you can interact with. And run `gcloud help COMMAND` to get help on any gcloud command.
* Run `gcloud topic --help` to learn about advanced features of the SDK like arg files and output formatting

Una vez completada esta configuración ya será posible crear un repositorio para GCloud.

11.3.3. Configuración de repositorio Google Cloud

Un repositorio Google Cloud Storage tiene los siguientes parámetros particulares:

Figura 11.3.3.1: Repositorio GCloud

Al haber configurado todos los parámetros de acceso al servicio en la rutina de sistema explicada en el punto anterior, la configuración del repositorio queda muy sencilla:

  • Host: Solamente será necesario indicarlo si se trata de un servicio propio o no estándard.
  • Estilo de URI: VirtualHost es el valor adecuado para repositorios GCloud
  • Nombre de bucket: Es necesario indicar el nombre del bucket y que éste exista previamente en GCloud antes de la creación del repositorio.

11.4. Repositorios para dispositivos Azure Blob Storage

Para conectarse con un repositorio S3 solamente es necesario completar la configuración del repositorio, seleccionando como Driver el tipo Azure. No es necesaria ninguna otra acción previa.

Un repositorio Azure tiene los siguientes parámetros particulares:

Figura 11.4.1: Repositorio Azure

  • Blob endpoint: Esta directiva se puede utilizar para especificar un tipo personalizado de URL en Azure Cloud Blob (consultar https://docs.microsoft.com/en-us/azure/storage/blobs/storage-custom-domain-name).
    • Si no se ha personalizado la URL del recurso de almacenamiento, no hace falta especificar ningún valor y se conectará con la URL genérica de almacenamiento de azure.
  • Sufijo endpoint: Utilice este parámetro para especificar una url postfix personalizada para Azure. Ejemplo: core.chinaclouda.cn
    • Si no se ha personalizado la URL del recurso de almacenamiento, no hace falta especificar ningún valor y se conectará con la URL genérica de almacenamiento de azure.
  • Estilo de URI: En general, para repositorios Azure se debe utlizar 'Path'
  • Nombre de bucket: En Azure se refiere al nombre del 'Contenedor'. No obstante, si no existe, el plugin se encargará de crearlo automáticamente
  • Clave de acceso: Aquí se debe indicar el nombre de la 'Cuenta de almacenamiento' de Azure
  • Clave secreta: La clave se puede obtener de la sección 'Claves de acceso' de la cuenta de almacenamiento de Azure

11.4.1 Gestión y credenciales Azure Storage

Los servicios de almacenamiento de Azure se gestionan desde su portal (portal.azure.com) y en la sección de 'Cuentas de almacenamiento':

Figura 11.4.1.1:  Cuentas de almacenamiento de Azure

El nombre que asignemos a la cuenta, será el valor que debemos asignar como clave de acceso.

Figura 11.4.1.2: Formulario de cuenta de almacenamiento de Azure

Dentro de las cuentas de almacenamiento, podemos gestionar 'contenedores'. El nombre del contenedor será el nombre del bucket para el plugin, aunque el plugin es capaz de crearlo en caso de no existir:

Figura 11.4.1.3: Contenedor de Azure

Por otro lado, la clave de acceso se puede obtener desde la sección 'Claves de acceso':

Figura 11.4.1.3: Claves de Azure

A modo de ejemplo, se muestra el contenido de un contenedor, una vez éste tiene datos subidos desde WBSAirback®:

Figura 11.4.1.4: Volúmenes en un contenedor

Figura 11.4.1.5: Partes de un volumen en un contenedor

11.5. Repositorios para dispositivos Oracle Cloud Storage

Para configurar repositorios en la nube de Oracle, es necesario seguir en primer lugar un procedimiento a nivel de sistema que añadirá las herramientas de sistema necesarias a través de las cuales WBSAirback® se podrá comunicar con el almacenamiento nube. Tras ello, es necesario configurar un repositorio con driver de tipo Oracle.

11.5.1. Administración online de Oracle Cloud

En este apartado se describen los aspectos básicos a tener en cuenta con la consola de administración online (Oracle Cloud Infrastructure Console) de la nube de Oracle, en relación a la configuración necesaria para trabajar con este plugin de almacenamiento en dispositivos nube.

En primer, lugar averigüe su 'OCI Console URL', pues es el punto de entrada principal a sus recursos de almacenamiento Oracle. Para ello, desde el Dashboard de servicios de oracle, seleccione su cuenta y elija 'My Admin Accounts' en el menú desplegable. Obtenga la URL de su consola Oracle consultando la URL asociada a 'Compute (OCI) Users'. La URL se genera basada en regiones, por lo que tiene un formato de tipo: https://console.<region>.oraclecloud.com/...

La gestión de Buckets es accesible desde el menú 'Object Storage' de la consola web de servicios de Oracle. El nombre que asigne aquí, es el nombre de bucket que debe utilizar después en la configuración del plugin. Es importante señalar que el Storage Tier del bucket que se seleccione, además de tener diferencias de coste asociadas, no se puede modificar después y tiene implicaciones sobre el modo de trabajo de las restauraciones con este plugin:

  • El modo Standard proporciona acceso instantáneo a los objetos de un bucket.
  • El modo Archive hará que sea necesario restaurar primero los objetos de forma manual con el cliente OCI (vea sección 

    11.5.2) antes de poder restaurarlos con WBSAirback®.

Para más información sobre Storage Tiers de Oracle, consulte: https://cloud.oracle.com/storage/archive-storage/faq

Por último, necesitará acceder a las claves OCID, el Tenancy OCID a través de la página de 'Tenancy Details', así como el User OCID, a través de la página 'User Settings'. Necesitará toda esta información para completar la configuración que se expone en el punto siguiente.

11.5.2. Proceso de sistema para configurar Oracle Cloud

En primer lugar, es necesario instalar Oracle Command Line Interface (OCI), para lo cual ejecutamos:

OCI
bash -c "$(curl -L https://raw.githubusercontent.com/oracle/oci-cli/master/scripts/install/install.sh)"

Es necesario modificar la ubicación por defecto de la siguiente manera:

  • Default location: /usr/local/bin
  • Install location: /usr/local/lib/oracle-cli
  • OCI executable location: /usr/local/bin
  • OCI scripts location: /usr/local/bin/

Cuando se pregunte posteriormente si se quiere modificar el path, responderemos 'No'. Finalmente debemos obtener 'Installation successful'.

Una vez instalado es necesario completar la configuración, par alo cual ejecutaremos:

OCI setup
sudo -u bacula /usr/local/bin/oci setup config

Y debemos indicar los valores correspondientes para:

A continuación será necesario subir la clave pública a la consola web OCI. La clave pública se llama oci_api_key_public.pem y se localiza en /opt/bacula/etc/oci como se ha comentado enel punto anterior. Para subir la clave es necesario ir a Identity > Users y seleccionar el usuario apropiado de la lista. Pulse en Add Public Key y copie los contenidos del archivo de clave.

Después es necesario obtener el namespace asociado al bucket de backup, así como el compartment id. En el menú de navegación de la consola web OCI, selecione Object Storage y después seleccione el Bucket usado con el plugin. En el panel informativo sobre el bucket aparecerá el namespace y el compartment id, que son necesarios para el siguiente paso.

En el fichero /opt/bacula/etc/oci/config es necesario añadir la siguiente sección:

ociconfig
[CLI]
# globally scoped default for all operations with a --compartment-id parameter
compartment-id = <compartment-id>
# globally scoped default for all operations with a --namespace parameter
namespace = <namespace>

[OCI_CLI_SETTINGS]
default_profile=CLI

Indique en <compartment-id> y <namespace> los valores que obtuvo en el paso anterior.

Por último, compruebe que el acceso a su bucket MiBucket es correcto utilizando el siguiente comando:

bucket access
sudo -u bacula /usr/local/bin/oci os object list -bn MiBucket --cli-rc-file /opt/bacula/etc/oci/config --config-file /opt/bacula/etc/oci/config

La respuesta no debería obtener ningún mensaje de error y sí reflejar lo siguiente:

oci cli response
{
"prefixes": []
}

11.5.3. Repositorio de Oracle

Un repositorio de Oracle es muy sencillo de configurar, una vez hemos completado la configuración a nivel de sistema:

Figura 11.5.3.1: Repositorio de Oracle

Se pueden dejar todos los valores por defecto y solamente es necesario definir:

  • Host: En este parámetro debemos indicar la ruta de configuración de la consola OCI
  • Nombre de bucket: El nombre de bucket a utilizar para el almacenamiento


12. Rendimiento

El rendimiento de las subidas y descargas del plugin de almacenamiento sobre dispositivos cloud está directamente relacionado con el tipo de almacenamiento utilizado y la infraestructura.

Cada proveedor dispone de distintas opciones dentro de su catálogo de servicios de almacenamiento. La velocidad de transferencia, con frecuencia, es uno de los factores que distinguen unos tipos de almacenamiento de otros.

Por otro lado, la infraestructura donde despliegue su unidad de WBSAirback®, es otro factor determinante. Las conexiones de red a Internet deben permitir el máximo ancho de banda alcanzable por cada tipo de almacenamiento (a nivel físico, pero también a nivel lógico con el tipo de conexión contratada con el ISP) para poder obtener velocidades de transferencia más altas.

El mecanismo de caché que utiliza WBSAirback®, garantiza que los datos sean respaldados o copiados sin interferencia de posibles problemas de rendimiento o conectividad con la nube. No obstante, es necesario asegurar que se dispone de suficiente ancho de banda y margen temporal para escribir todos los datos que se respaldan o copian en un despliegue, también en la nube y dentro de las ventanas definidas de backup. En caso contrario se pueden producir colapsos y encolamientos que terminen por imposibilitar el correcto funcionamiento de la plataforma. Por favor, planifique cuidadosamente pruebas de rendimiento sobre su almacenamiento cloud contratado y diseñe en consecuencia sus políticas y ventanas de backup.

13. Costes en la nube

Como probablemente ya sepa, el almacenamiento en recursos cloud conlleva una serie de costes. Cada proveedor tiene su propio modelo de costes, normalmente basado en el tipo específico de almacenamiento (variando en base a rendimiento, disponibilidad, etc) y la región donde se aloje el mismo. Asimismo, es necesario considerar el coste de la transferencia de datos:

En el caso general, la subida de archivos no supone coste alguno, mientras que la descarga de los mismos sí supone coste. Por este motivo, lo que se recomienda desde WBSgo es utilizar este tipo de recursos como un segundo nivel de protección dentro de la política general de protección de datos de su entorno. El primer nivel de corta o media retención se puede enviar a disco y aprovechar las bondades de los sistemas de deduplicación de WBSAirback®. Un segundo nivel de copia se enviaría a un dispositivo nube con una retención más larga. Estos datos no serán accedidos frecuentemente, en general, por lo que el coste será reducido. 

Tenga en cuenta que WBSAirback también necesita realizar descargas de parte de los datos cuando se escribe en cualquier dispositivo nube, no solo en las recuperaciones, ya que es necesario realizar ciertas verificaciones para mantener la consistencia de los datos y otras operaciones importantes.

Una forma de reducir costes es utilizar alguna de las técnicas de compresión de los datos que ofrece WBSAirback®. En los trabajos en los que exista almacenamiento nube implicado, active la compresión LZO en el patrón de ficheros.

Por favor, consulte detenidamente el coste que le puede suponer utilizar este plugin con la información específica de su proveedor de almacenamiento nube. Haga también una prueba de concepto con los tipos de backup implicados del ciclo completo de backup, restauración y reciclado, antes de poner cualquier sistema en producción. La mayoría de proveedores ofrecen sistemas de cálculo online donde puede especificar su caso de uso. A continuación se proporcionan enlaces donde es posible consultar los detalles del coste en cada tipo de nube:

14. Seguridad de los datos

La transferencia de los datos hacia la nube utiliza siempre el protocolo HTTPS por defecto, a menos que se configure manualmente HTTP para algún tipo de nube en particular. Por lo tanto, los datos viajan cifrados hacia la nube en una conexión segura.

No obstante, los datos en la nube no se cifran por defecto. Si necesita que los datos se almacenen cifrados, es necesario que utilice la característica de cifrado de backups de WBSAirback®.

15. Limitaciones

A continuación se listan diversas limitaciones o problemas conocidos. En la medida de lo posible, estas limitaciones se abordarán en futuras versiones de WBSAirback®:

  • El tamaño reflejado en un volumen cloud no es correcto, ya que éste solamente refleja el tamaño de la última parte cloud. El tamaño real es la suma de todas las partes.
  • El tamaño total de un pool se basa, al igual que en otros tipos de pools no-cloud, en la suma del tamaño de los volúmenes. Al ser incorrecto el tamaño de cada volumen cloud, también lo es el del pool.
  • La directiva de 'Máximo tamaño', debido a los puntos anteriores, no está soportada para pools de tipo cloud.
  • No es posible utilizar deduplicación de ningún tipo con este plugin Cloud.
    • En general no se recomienda intentar deduplicar en un dispositivo nube. No obstante, WBSAirback® puede hacerlo a través de su módulo de almacenamiento S3, el cual es independiente de este plugin. Si su infraestructura dispone de los elementos necesarios, por favor, consulte la documentación asociada.  

16. Contacto

Consultas o dudas relativas al presente documento, pueden dirigirlas a:

Jorge Gea

e: jorge.gea@wbsgo.com



WBSAirback®

19

WhiteBearSolutions, WBSgo y WBSAirback y sus correspondientes logos son marcas registradas propiedad de WhiteBearSolutions, S.L.

WhiteBearSolutions realiza los mayores esfuerzos para asegurar que la información facilitada en el presente documento es precisa y exacta.

No obstante, no se responsabiliza de cualquier error o inexactitud de la misma recogido en el documento.

Las especificaciones e informaciones recogidas en el presente documento pueden ser modificadas sin previo aviso.

WhiteBearSolutions (WBSgo)

Calle Severo Ochoa 3, Planta 1 Of. 7 – 28232, Las Rozas (Madrid)
t. 902 90 69 69 f. 902 90 69 70 




  • No labels