EXPEDIENTE 030/12 EXPEDIENTE 030/12 EXPEDIENTE

EXPEDIENTE 030/12 EXPEDIENTE 030/12 EXPEDIENTE

FAQ - EXPEDIENTE 030/12030/12-SP
“Sistemas de almacenamiento deduplicado para OSAKIDETZA”
Diagrama arquitectura de backup actual de Osakidetza:
o Servidores de backup y media servers. SS.OO. y número de estos.
o Librerías de cinta que utilizan, modelo, drives y conectividad.
o Esquema de conectividad de los componentes del sistema de backup
(suponemos que existe una SAN FC, modelo de switches y tipo)
=> Información no disponible en tiempo de licitación.
El pliego indica que el software de backuo actual de Osakidetza es Symantec
NetBackup 7.1, y que los sistemas deben utilizar OST. Entendemos que el SW de
backup ya tienen licenciado OST? Si no es así, debe ofertarse? Necesitaríamos en tal
caso, conocer el licenciamiento que actualmente tienen (modulo Enterprise disk).
=> Sí, el sw de backup ya tiene licenciado OST.
El alcance incluye reconfigurar las tareas de backup existentes? Si es asi,
necesitamos conocer cuantas políticas-tareas serán objeto de reconfiguración.
=> No es necesario reconfigurar las tareas existentes.
Existe alguna política de disaster recovery implementada actualmente? Si es así,
descripción de la misma.
=> Actualmente no está implementada, pero lo estará en un futuro.
El detalle técnico de la oferta, es decir la memoria técnica de la oferta desarrollada
solo se solicita a posteriori de una hipotética adjudicación? No hay que incluirla en
ningún sobre? En caso que SI haya que incluirla en qué sobre iría?
=> El detalle técnico de la oferta se solicita, tras valorar todos los criterios
cuantificables, a aquel licitador que haya obtenido mayor puntuación, por tanto no
hay que incluirla en ningún sobre.
Cual es el periodo limite (si lo hubiera) para la instalación y configuración de la
solución?
=> De acuerdo con el apartado 3.3 del Pliego de Prescripciones Técnicas, no hay
tiempo límite, si bien la disponibilidad del adjudicatario debe ser completa hasta
finalizar estas actuaciones.
Bajo nuestra interpretación del espíritu y alcance del pliego, entendemos que el
objetivo principal del mismo es la optimización del backup basado en la mayor
integración y aprovechamiento posibles con respecto a funciones avanzadas de las
que se podría disponer con los sistemas de gestión de salvaguardia ya existentes.
Tras el estudio detallado de los objetivos y requistos del pliego, hemos detectado que
existen algunos aspectos y requerimientos técnicos concretos que entrarían en
conflicto con otros requisitos sumamente importantes también solicitados en el
mismo y que de no poder ser éstos empleados por esa causa, limitarían
considerablemente el empleo eficiente de funcionalidades y operativas avanzadas, tal
y como entendemos se pretende en la solución global con el software de backup de
Osakidetza (Symantec Netbackup).
Basado tanto en nuestro conocimiento y experiencia con este producto , así como de
la información contrastada con el propio fabricante (Symantec), quisiéramos poner
en conocimiento de RED.es dichos aspectos para su consideración y su posible
modificación/matización, si así lo estima conveniente.
En concreto se refieren al uso obligatorio de VTL para OSAKIDETZA, desde el punto
de vista de NetBackup, solución de salvaguarda de Osakidetza , que implica: ·
Imposibilidad de usar deduplicación en origen: Es decir, la deduplicación realizada en
el cliente del que se va a hacer backup (sea remoto o no). Por lo tanto, se impide que
viajen por la red los datos ya deduplicados.
· Imposibilidad de aplicar GRT (Tecnología de Restauración Granular) en
backups de Exchange, Sharepoint. Tanto en entorno físico como mediante la política
de protección avanzada de aplicaciones a través de vStorage API si las aplicaciones
están montadas sobre VMWare, del que Osakidetza tiene un importante entorno.
· Imposibilidad de uso de las funcionalidad Optimized Duplication de la API
OST: Impide que NetBackup sea consciente de la replicación de imágenes de forma
optimizada (automática, sin intervención manual) entre dispositivos (Data Domain,
CentricStore…).
La parte VTL, por tanto, no sería compatible con OST, de esta forma, sería
incompatible con otros dos puntos del pliego:
“Catálogo único del software de backup: Utilizando la funcionalidad OST del software
de backup, la réplica deberá ser consistente manteniendo catálogo único, teniendo
en todo momento el software
software de backup corporativo control y constancia de dónde
se encuentra la información primaria y externalizada. De esta forma se evita la
administración de las réplicas desde el software de backup y la intervención manual
en la recuperación desde el site principal en caso de desastre”
La solución de backup NO tendría con la parte de VTL control y constancia de dónde
se encuentra la información primaria y externalizada.
“Deduplicación: El sistema en su conjunto debe contar con mecanismo de
deduplicación inline de forma que el almacenamiento de los trabajos de backup se
produzca deduplicado y siendo compatible con OST (Open Storage Technology).”
El sistema en su conjunto no sería compatible con OST.
En consecuencia y tras valorar el impacto y pesos relativos de estos puntos en el
alcance del pliego, sugeriríamos a RED.es , si así lo estima oportuno , la modificación
del punto referido a VTL y su valoración, de requisito imprescindible y por tanto
excluyente , por la de "requisito valorable", siendo en cualquier caso conscientes de
que el cumplimiento de éste último inhabilitaría el posible cumplimiento de otros y, en
consecuencia, entendemos, de la valoración que se les haya asignado.
=> Como se indica en el apartado 2.1 del Pliego de Prescripciones Técnicas, el sistema
debe poder realizar backup mediante OST o mediante sw VTL, y de forma simultánea.
Todos los requisitos solicitados que aplican al uso de OST se deben tener en cuenta
sólo en aquella parte del backup que se realice mediante este protocolo y no en la
parte realizada mediante VTL.
La valoración de que la réplica de los datos deduplicados pueda realizarse de forma
cifrada (página 6 de 32 del PPT), ¿significa que el sistema propuesto tenga activa
dicha funcionalidad (incluyéndose las licencias de uso u otros medios si fuera
necesario) o se pretende conocer la posibilidad de que lo soporte en caso de que sea
necesario?
=> En caso de que el sistema posea esa funcionalidad, para que sea valorada debe
estar activada, incluyendo los medios que sean necesarios.