APROVISIONAMIENTO MEDIANTE ARRENDAMIENTO DE UNA SOLUCIÓN DE ALMACENAMIENTO PARA LOS CPDs DE LA ORGANIZACIÓN CENTRAL DE OSAKIDETZA-S.V.S.

Transcripción

1 APROVISIONAMIENTO MEDIANTE ARRENDAMIENTO DE UNA SOLUCIÓN DE ALMACENAMIENTO PARA LOS CPDs DE LA ORGANIZACIÓN CENTRAL DE OSAKIDETZA-S.V.S. PLIEGO DE BASES TÉCNICAS

2 Índice 1. Introducción Objeto y alcance Descripción de la infraestructura actual Arquitectura de la solución Red de fibra optica Características de Fabric Características Fabric Conexión entre centros Virtual Fabrics Gestión Almacenamiento en bloque Introducción HDS VSP HDS HUS EMC DMX HP EVA Resumen de conectividad Front-end Arquitectura final deseada Características de los sistemas requeridos Características generales Características técnicas Capacitación Configuración mínima a ofertar Plan de instalación y puesta en marcha Garantía Presupuesto, plazo de ejecución y forma de pago Presupuesto Plazo de ejecución Forma de pago Contenido de las ofertas Propiedad de los productos entregados Confidencialidad

3 Anexo I. Criterios de valoración Criterios de juicio de valor Criterios de fórmula Anexo II. Características de la infraestructura ofertada

4 1. Introducción Dada la rápida evolución de los servicios ofrecidos desde la organización central al resto de organizaciones de Osakidetza, la renovación tecnológica de la infraestructura de almacenamiento (SAN) se hace inevitable para poder continuar ofreciendo el servicio en los niveles de calidad actuales. 3

5 2. Objeto y alcance El objeto del presente expediente de contratación es el aprovisionamiento bajo la modalidad de arrendamiento (renting) del hardware y software necesario para la adecuación a las nuevas necesidades de almacenamiento en los CPDs de la Organización Central de Osakidetza. La infraestructura de almacenamiento comprende la necesaria para los dos CPDs de la Organización Central, cuya finalidad será la de dar soporte en cualquier tipo de contingencia dentro del Plan de Continuidad de Negocio. El alcance de este pliego incluye las herramientas de gestión necesarias para la monitorización, configuración, gestión y aprovisionamiento del almacenamiento de la infraestructura SAN. El contrato de arrendamiento (renting) incluirá: Instalación, configuración y puesta en marcha de la solución. Garantía 24x7 de la solución de almacenamiento para un periodo mínimo de 5 años. La empresa adjudicataria se responsabilizará del buen funcionamiento de toda la infraestructura ofertada que deberá ser nueva, nunca de segunda mano o reparado (refurbished). No se solicitan servicios de gestión de la infraestructura de almacenamiento, los cuales ya se disponen. No es objeto de contratación los servicios de migración de los sistemas del entorno actual al nuevo ya que serán suplidos por los recursos internos de Osakidetza. 4

6 3. Descripción de la infraestructura actual La infraestructura de la red de almacenamiento de Osakidetza se compone de los siguientes componentes hardware (HW) y software (SW). Redundancia de directores FiberChannel Brocade DCX repartidos en dos Fabrics: - Fabric1: Equipo Director Brocade DCX en cada centro interconectados por 3 líneas dedicadas DWDM de 4gbps. - Fabric2: Equipo Director Brocade DCX en cada centro interconectados por 3 líneas dedicadas DWDM de 4gbps Redundancia de almacenamiento en un mismo CPD: - 2 Cabinas EMC Symmetrix DMX4 replicadas entre si mediante el protocolo RDF para los datos críticos. Redundancia de almacenamiento repartidos entre los 2 CPDs: - 1 Cabinas EMC Symmetrix DMX4 en cada CPD, conectadas directamente contra las cabinas HDS VSP de cada centro - 1 Cabina HDS HUS 130 en cada centro, conectada directamente contra las VSP de su centro. - 1 Cabina HDS VSP en cada centro, interconectadas por cada una de las fabric. - 1 Cabina HP EVA 8200 en cada centro. 5

7 3.1 Arquitectura de la solución El dibujo final de la arquitectura queda de la siguiente forma: 6

8 3.2 Red de fibra óptica Osakidetza cuenta con 2 redes de fibra óptica (fiber channel - FC) independientes para aportar redundancia. Cada red cuenta con 2 directores de fibra, modelo Brocade DCX, uno por centro que son quienes aportan el grueso de la conectividad de Osakidetza a nivel de fibra. Ambas redes, Fabric1 y Fabric2, están extendidas entre los centros de proceso de datos (CPD) de Osakidetza ofreciendo una red homogénea dentro de la infraestructura de Osakidetza. Los centros están unidos entre sí por 3 enlaces de DWDM de 4Gbps cada uno por cada una de las Fabric. La versión actual de FabOS tanto en los directores de fibra como en el resto de switches satélite de la red es la versión 6.4.2a. 7

9 3.2.1 Características de Fabric1 La red de fibra con nombre Fabric1 está compuesta de los siguientes switches: Switch Name Domain ID Switch(es) Details IPAddress SwitchWWN Firmware Version SwitchType DCX110_VF :00:00:05:33:21:6D:01 v6.4.2a Brocade DCX 96 DS_4100B :00:00:05:1E:04:B6:D9 v6.4.2a Brocade DCX100_VF :00:00:05:33:24:9A:01 v6.4.2a Brocade DCX 96 ibxscfc :00:00:05:33:DF:DE:A6 v6.4.2a 0 ibxejfc :00:00:05:33:DF:7F:8E v6.4.2a Brocade Ports Distribuidos de la siguiente forma: CPD1 CPD2 8

10 3.2.2 Características Fabric2 La red de fibra con nombre Fabric2 está compuesta por los siguientes switches: Switch Name Domain ID Switch(es) Details IP Address SwitchWWN Firmware Version SwitchType DCX210_VF :00:00:05:33:24:98:01 v6.4.2a Brocade DCX 96 Sw300E_ :00:00:05:1E:C5:2A:66 v6.4.2a Brocade DS_4100B :00:00:05:1E:04:9E:E0 v6.4.2a Brocade DCX200_VF :00:00:05:33:21:6F:01 v6.4.2a Brocade DCX 96 ibxejfc :00:00:05:33:DF:4E:9F v6.4.2a Brocade ibxscfc :00:00:05:33:DE:D5:AA v6.4.2a Brocade Ports Distribuidos de la siguiente forma: CPD1 CPD2 9

11 3.2.3 Conexión entre centros Los CPDs de Osakidetza están conectados por 2 anillos de fibra oscura de distintos proveedores. Uno de los circuitos tiene una longitud de 9KM mientras que el segundo tiene 13KM de longitud. Fabric1: Switch Name Para la conectividad SAN disponemos de 3 enlaces por Fabric de 4Gbps cada una. Los enlaces actualmente están configurados en modo larga distancia manual con una longitud de conexión de 50KM. From Switch ISL/Trunk Summary To Switch Domain ID Port # Switch Name Domain ID Port # ISL/Trunk DCX100_VF DCX110_VF TRUNK DCX100_VF DS_4100B ISL DCX100_VF DS_4100B ISL DCX100_VF DCX110_VF TRUNK DCX110_VF DCX100_VF TRUNK DCX110_VF ibxejfc ISL DCX110_VF DCX100_VF TRUNK DS_4100B DCX100_VF ISL DS_4100B DCX100_VF ISL ibxejfc DCX110_VF ISL 10

12 Fabric 2: Switch Name From Switch ISL/Trunk Summary To Switch Domain ID Port # Switch Name Domain ID Port # ISL/Trunk DCX200_VF DCX210_VF TRUNK DCX200_VF DCX210_VF TRUNK DCX200_VF DS_4100B ISL DCX200_VF DS_4100B ISL DCX200_VF DCX210_VF TRUNK DCX210_VF DCX200_VF TRUNK DCX210_VF DCX200_VF TRUNK DCX210_VF Sw300E_ ISL DCX210_VF Sw300E_ ISL DCX210_VF ibxejfc ISL DCX210_VF DCX200_VF TRUNK DS_4100B DCX200_VF ISL DS_4100B DCX200_VF ISL Sw300E_ DCX210_VF ISL Sw300E_ DCX210_VF ISL ibxejfc DCX210_VF ISL Virtual Fabrics La configuración desplegada en Osakidetza contiene 2 particiones. La FID-128 es la partición por defecto debido a configuraciones legacy que presuponen que el FID siempre es 128. En esta partición están los puertos de expansión que no están en uso. La partición que está en uso es el FID-1 y están configurados todos los puertos disponibles en los DCX Gestión Para la gestión de la red de fibra contamos con acceso SSH y WEB a los switches así como de la herramienta Brocade Network Advisor. 11

13 3.3 Almacenamiento en bloque Introducción El cuadro resumen del almacenamiento es el siguiente Modelo Centro SN Almacenamiento Neto HDS VSP CPD TB HDS VSP CPD TB EMC DMX4 CPD TB EMC DMX4 CPD TB EMC DMX4 CPD TB EMC DMX4 CPD TB HDS HUS 130 CPD TB HDS HUS 130 CPD TB HP EVA8200 CPD1 35 TB HP EVA8200 CPD2 35 TB 12

14 3.3.2 HDS VSP Disponemos de 2 HDS VSP, una por centro. Las características más importantes dentro las HDS VSP que usamos son la Virtualización, HDT, y Volume migration. - Virtualización: Esto nos permite presentar luns virtuales de distintos orígenes a los host como si fuesen iguales. Para el host todos son de la misma cabina/pool. Y es soporte almacenamiento quien decide realmente donde está físicamente ubicado cada dato. Dentro del concepto de virtualización también nos permite conectar varias cabinas de distintos modelos dentro de la configuración de cada HDS VSP, siendo la HDS VSP la única cabina de almacenamiento que se presenta a los hosts, reduciendo de esta forma la administración de zonas y tareas en el host, ya que se comparten drivers, multipath, etc. - HDT: Dentro de cada HDS VSP hay un pool específico de discos denominado HDT, esto nos permite en un mismo pool de discos asignar distintas categorías. En nuestro caso tenemos 3, ordenadas por calidades de disco: 1-SSD, 2-SAS, 3-SATA. Este pool es el que se asigna a los host de producción, y es la cabina la que automáticamente y basándose en un estudio del uso de las LUNs el que determina que paginas son las más/menos accedidas y en función de dicho análisis se encarga de ir moviendo dichas paginas para garantizar el mejor rendimiento. - Volume migration: Nos permite mover luns entre diskpool en caliente sin que afecte al rendimiento del host, ni que tengamos que hacer ningún tipo de parada/intervención en el host. Las VSP son las únicas cabinas de almacenamiento que se presentan a los hosts, el resto de almacenamiento cuelga de las HDS VSP, y es esta la que se encarga de la creación de luns, borrado, etc. 13

15 HDS VSP CPD1 Frontal Trasera Tipo de disco Discos Pool Disponible Bruto Configuración SSD 400GB 8 HDT Tier 0 3,2 TB RAID (7+1) SAS 300G - 10K 32 HDT Tier 1 9,6 TB RAID (6+2) SATA 2T -7,2K 32 HDT Tier 2 64 TB RAID (6+2) 14

16 Como hemos comentado antes esta cabina tiene virtualizadas otras cabinas y las tiene repartidas internamente por pools. La forma que tiene la cabina de trabajar es basándose en esos disk pools, que están repartidos de la siguiente forma: Pool Name Capacidad Cabina Tipo CPD1 HDT (0) 52 TB VSP HDT Ext-73HDD(1) 20 TB DMX 670 HDP Ext-146HDD(2) 8,5 TB DMX 670 HDP Ext-300HDD CoW(3) 3,2 TB DMX 670 CoW HUS-SAS(4) 30 TB HUS 211 HDP HUS-NLSAS(5) 65 TB HUS 211 HDP 15

17 HDS VSP CPD2 Tipo de disco Discos Pool Disponible Bruto Configuración SSD 400GB 8 HDT Tier 0 3,2 TB RAID (7+1) SAS 300G - 10K 46 HDT Tier 1 13,8 TB RAID (6+2) SATA 2T -7,2K 32 HDT Tier 2 64 TB RAID (6+2) Como hemos comentado antes esta cabina tiene virtualizadas otras cabinas y las tiene repartidas internamente por pools. La forma que tiene la cabina de trabajar es basándose en esos disk pools, que están repartidos de la siguiente forma: 16

18 Pool Name Capacidad Cabina Tipo CPD1 HDT (0) 56 TB VSP HDT Ext-73HDD(1) 20 TB DMX 618 HDP Ext-146HDD(2) 8,5 TB DMX 618 HDP Ext-300HDD CoW(3) 3,2 TB DMX 618 CoW HUS-SAS(4) 30 TB HUS 196 HDP HUS-NLSAS(5) 65 TB HUS 196 HDP HDS HUS Disponemos de 2 HDS HUS 130, una por centro con una capacidad 169,5TB brutos cada una. Actualmente su principal función es proveer almacenamiento a la infraestructura de VMware y en una pequeña parte como cabina para disco de quórum en los Oracle RAC sobre VSP. La configuración de las dos cabinas es exactamente la misma, tienen 2 tipos de disco: SAS de 600GB y NL-SAS7K de 3TB Tipo de disco SAS 600GB NL-SAS 3TB SAS 600GB NL-SAS 3TB CPD Discos Tamaño Bruto Neto Configuración CPD TB 30 TB RAID 1+0 (4D + 4D) CPD TB 65 TB RAID 6 ( 6D+2P) CPD TB 30 TB RAID 1+0 (4D + 4D) CPD TB 65 TB RAID 6 ( 6D+2P) 17

19 Estos discos están distribuidos de la siguiente manera: EMC DMX4 También disponemos de 4 EMC DMX-4 en el entorno de Osakidetza. Tres de ellos en el CPD2, 2 para servidores en producción AIX conectados directamente y otro para alimentar a la HDS VSP de CPD2. Y otro más en CPD1 para alimentar la VSP de servicios centrales. EMC DMXs-> HDS VSPs Dos EMC DMX uno por cada centro conectado directamente contra la VSP. Es la VSP la que se encarga a través de la virtualización de presentar estos discos a los servidores. CPD ID Tipo de Disco Tipo Raid Tamaño Neto CPD GB RAID 5 20 TB 146 GB RAID 5 9 TB 36 GB RAID 10 3 TB CPD GB RAID 5 20 TB 146 GB RAID 5 9 TB 36 GB RAID 10 3 TB 18

20 DMXs Red.es Dos DMX en CPD2 para dar servicio directo a servidores de producción. CPD ID Tipo de Disco Tipo Raid Tamaño Neto CPD2 815 FC RAID10 18 TB SATA RAID5 3 TB CPD2 966 FC RAID10 18 TB SATA RAID5 3 TB HP EVA8200 Disponemos de 2 HP EVA8200, una por centro con una capacidad de 40TB brutos cada una. Actualmente está destinada para usarse como almacenamiento para el proyecto Exchange Tiene 3 tipos de discos: FATA, Fibra 146 y Fibra 300. Los discos FATA no se usan por pobre rendimiento. Tipo de disco Disponible bruto Configuración FATA 15,7TB 19 x 1TB Fibra 146 9TB 68 x 146GB Fibra ,4TB 36 x 300GB Resumen de conectividad Front-end NUMERO SUMA TIPO SO SERVIDORES HBA AIX HP-UX ESXi Windows 7 13 Linux CABINAS CABINA PUERTOS VSP VSP EVA8100_CPD2 4 EVA8100_CPD1 4 DMX618 8 DMX670 8 IBRIX_EVA_CPD2 8 IBRIX_EVA_CPD1 8 DMX DMX

21 3.4 Arquitectura final deseada 20

22 4. Características de los sistemas requeridos. Al presentar la oferta, el licitador deberá ajustarse a la terminología utilizada en este apartado. Las propuestas que ofrezcan características inferiores a las requeridas serán excluidas. El licitador puede ofertar prestaciones superiores a las solicitadas. Los requisitos detallados en este apartado no pretenden ser una relación exhaustiva de las características técnicas de las actuaciones demandadas en el presente pliego, éste sólo recoge las características relevantes de las actuaciones objeto del procedimiento de licitación. Las ofertas de los licitadores deberán proporcionar la especificación técnica completa de dichas actuaciones. El licitador debe garantizar la total compatibilidad e integración de los componentes que ofrezca con los elementos y aplicaciones existentes en Osakidetza y en la infraestructura ya desplegada tanto en los CPDs corporativos como en los distintos complejos hospitalarios conectados a ellos, pertenecientes a Osakidetza y detallados en el apartado 3 del presente pliego. Toda integración, cambio, sustitución o adquisición que resulten necesarios, derivados de la no compatibilidad de los sistemas ofertados con los existentes, será responsabilidad del adjudicatario, quien deberá realizar todas las tareas oportunas para conseguir el funcionamiento total del entorno final requerido, sin que esto suponga ningún coste añadido para la entidad ni para el organismo destinatario, sin pérdida de la continuidad del servicio que se presta, y sin perjuicio de los plazos establecido en el apartado 7 del presente Pliego. El personal técnico de Osakidetza cuenta con capacitación en cuanto a la arquitectura técnica que se ha presentado en el apartado anterior. Para otras soluciones ofertadas distintas a las mencionadas, el adjudicatario deberá proveer de formación específica a todo el personal técnico mencionado así como al personal que pueda verse afectado por el cambio de sistema, y deberá colaborar en la confección, definición y/o modificación de los procedimientos e instrucciones técnicas que afecten a la gestión y administración del software, sin que ello suponga ningún coste añadido para la entidad ni para el organismo destinatario, y sin perjuicio de los plazos establecidos en el apartado 7 del presente Pliego. Con el objeto de garantizar el correcto funcionamiento de la solución en su conjunto, Osakidetza se reserva el derecho a solicitar al licitador una batería de pruebas del equipamiento ofertado, y una propuesta de documentación asociada que contemple el detalle de las mismas, resultados obtenidos, etc. 21

23 4.1 Características generales. La infraestructura a adquirir estará compuesta por dos soluciones de almacenamiento SAN que sin impacto en el servicio y de forma transparente para los servidores, aporten alta disponibilidad y contingencia en el acceso de los servidores al almacenamiento, ante el escenario de pérdida de la infraestructura de almacenamiento en cualquiera de los CPDs. Considerando infraestructura de almacenamiento tanto las cabinas como los virtualizadores si los hubiera. En caso de que desde Osakidetza se determine algún tipo de problema de rendimiento en la ejecución de las aplicaciones de Osakidetza, achacable a la infraestructura de almacenamiento, el proveedor deberá de suministrar, sin coste para Osakidetza (no se imputará a Osakidetza ni el coste de adquisición ni el coste de su mantenimiento, en los mismos términos que el resto de la infraestructura de almacenamiento) los elementos hardware necesarios para alcanzar el grado óptimo de ejecución de dichas aplicaciones. 22

24 4.2 Características técnicas. Para completar la arquitectura descrita en el presente pliego, OSAKIDETZA solicita una infraestructura potente, realmente escalable, sencilla de administrar y muy fiable, con referencias contrastadas en el sector. Por estas razones, la infraestructura a proponer deberá ser una infraestructura SAN con escalabilidad horizontal y por tanto cumplir las siguientes características mínimas: Requerimientos Gestión Consola de gestión instalable o web Las consolas de gestión deben poder cargarse en una amplia gama de sistemas operativos con un mínimo de requisitos. Monitorización de eventos y estado Analítica Disponibilidad Ampliación no disruptiva de capacidad de disco Ampliación de conectividad nodisruptiva Actualizaciones de firmware no disruptiva Los operadores deben ser conscientes de la situación y actividades de la solución para uso efectivo. La notificación de alertas a través de correo electrónico, consolas de usuario, Simple Network Management Protocol (SNMP), y / o scripts de usuario y la integración con las aplicaciones de monitorización de sistemas. Las aplicaciones de gestión deben prever mecanismos de gráficos e informes para rastrear los patrones de uso y el estado del almacenamiento La adición de espacio de almacenamiento debe ser una operación transparente y no afecta el rendimiento o la disponibilidad. La expansión de la conectividad adicional (por ejemplo, Fibre Channel [FC]) debe ser una operación transparente y no afecta el rendimiento o la disponibilidad. Cualquier actualización de firmware debe ocurrir sin interrumpir las operaciones. Redundancia Gestión preventiva de los discos Debe ser compatible con las estrategias para la detección preventiva de fallas de disco. Detección preventiva de fallos Metodologías de previsión de fallos para evitar fallos inesperados, al permitir a los usuarios eliminar hardware sospechoso de fallar. 23

25 Cache mirroring de controladora Redundancia de controladora de sistema Se requiere duplicación de caché para operaciones de escritura. Debe de disponer de la redundancia a nivel de controladora. El evento de fail-over no debe interrumpir los servicios de almacenamiento de conformidad con los requisitos de disponibilidad y no causa la pérdida de datos. Las controladoras redundantes deben compartir las cargas de trabajo durante el funcionamiento sin fallo. Redundancia en elementos internos de conectividad, ventilación, fuentes de alimentación etc. Gestión proactiva de las baterías Fuentes de alimentación redundadas El fallo de componentes individuales no debe causar una interrupción del servicio de datos. Debe proporcionar características de alerta para informar a los operadores cuando la batería (para protección de la memoria caché) o el sistema de alimentación ininterrumpida [SAI] requiere una acción de mantenimiento. System UPS Redundancia para la solución de virtualización Continuidad de negocio Para la alta disponibilidad o continuidad de las operaciones, se debe ofrecer la capacidad de suministrar energía desde baterías con la capacidad suficiente para permitir un apagado ordenado y / o múltiples reinicios hasta que se restablezcan las operaciones normales de corriente. La solución de virtualización ofertada no debe tener puntos de fallo únicos, el fallo de componentes individuales no debe causar interrupción del servicio de datos Replicación síncrona Replicación asíncrona Failover/failback Conmutación por error que permita la continuidad de las operaciones en un lugar secundario en el caso de un desastre o mantenimiento del equipo. Conmutación por recuperación que permita volver a las operaciones normales después de la recuperación de sistema principal que ha fallado. Todo ello sin pérdida de servicio 24

26 Replicación ininterrumpida Seguridad Una actividad de replicación a otro sistema no se debe interrumpir por otros eventos de movimiento de información generados en el sistema. Acceso autenticado con registro de acceso Soporte al a autenticación MS AD y LDAP Detección de intrusión y alarmas de retirada de HW no autorizado Thin Provisioning Thin-provisioning Debe soportar la validación de usuarios mediante los protocolos descritos Debe alertar a los operadores a una intrusión física en los sistemas de almacenamiento y / o una eliminación del dispositivo. Soporte thin-provisioning Terceras Copias Debe soportar la creación de terceras copias Storage tiering Migraciones concurrentes de volúmenes Block granularity Soporte discos Soporte a múltiples tecnologías de disco Soporte Solid-state disk (SSD) Flash LUNs Flash SSD auto-tier Protocolos y conectividad Multipathing FC 4 Gbit/s FC 8 Gbit/s Entornos operativos Debe ser compatible con las migraciones de volumen entre los niveles de almacenamiento predefinidos dentro de un marco. La granularidad para el movimiento de información entre tiers debe de ser a nivel de bloque Debe permitir la selección y mezcla de varios tipos de unidades de disco. Debe soportar la creación de volúmenes individuales exclusivamente en Flash SSD. Debe soportar configurar los discos SSD para apoyar el movimiento automatizado de los datos activos dentro de una LUN entre los dispositivos SSD y los discos de alta capacidad. Debe soportar el acceso de los host por más de un path y balancear la carga entre dichos path. Esta integración a nivel de host puede ser con software propietario del sistema de almacenamiento o con las utilidades de cada S.O. Debe soportar puertos a 4 Gbit / s FC. Debe soportar puertos a 8 Gbit / s FC. 25

27 Soporte a S.O. Soporte a virtualización VMware vsphere Monitorizacion hardware Monitorización ambiental Control adaptativo de la temperatura de funcionamiento AIX 6.1 o superior HP-UX o superior ESXi 5.x o superior Windows 2008 o superior Red Hat Linux 5 o superior Debe facilitar características, capacidad y conectividad suficientes para apoyar la virtualización de servidores. Debe ofrecer un plug-in de gestión para VMware vcenter e integración con VMware vstorage API. Debe monitorizar su estado incluyendo la temperatura ambiente, estado de energía, consumo de energía y proporcionar alertas a la infraestructura de gestión para las condiciones fuera de rango. Debe ser compatible con la gestión del ventilador de refrigeración para mantener la temperatura de los componentes y con gracia apagar un sistema o parte de un sistema para protegerlo de condiciones de sobrecalentamiento. Front-to-back airflow Escalabilidad Servicios de test de rendimiento Proteccion de la inversión Non-disruptive data migration and operating system support Servicios y soporte Lista de compatibilidad de Hardware Informes de almacenamiento El proveedor debe proporcionar la posibilidad de hacer pruebas de rendimiento, ya sea en las instalaciones del cliente o en un centro de pruebas para probar las reclamaciones de rendimiento utilizando las cargas de trabajo de los clientes. El proveedor debe proporcionar herramientas de migración para mover los datos, ya sea hacia adelante sobre el hardware de nueva generación o de un equipo remplazado. Durante la migración, el vendedor debe ser compatible con la continuidad / coherencia del proceso de DR. Se debe mantener una lista de referencia con la matriz de compatibilidad con otros proveedores de infraestructuras TI como por ejemplo: dispositivos de red, software de gestión de almacenamiento, copias de seguridad, archivado y virtualización. Esta lista debe ser lo más amplia posible. Informes de capacidad: 26

28 Capacidad bruta, usable, libre, así como la información en cuanto a thin provisioning se refiere Informes de espacio a nivel de RAID group/raid set y LUN. Informes de rendimiento: Informes de rendimiento a nivel de frame o SAN, con históricos Informes sobre rendimiento, longitud de colas y otras métricas que puedan indicar problemas de rendimiento en aplicaciones o bases de datos. Rendimiento a nivel de front-end y back-end Rendimiento de discos (% uso, longitud de cola). Rendimiento a nivel de LUN. Capacidad de agrupar objetos e informar sobre el grupo seleccionado 27

29 4.3 Capacitación Requerimientos Realización de capacitación sobre los sistemas de almacenamiento, incluyendo al personal operativo que designe Osakidetza. El programa de capacitación se convendrá con Osakidetza, pudiendo ser el propio programa oficial del fabricante en cuanto a contenidos o un programa a medida para la transferencia de conocimientos. Esta capacitación será, como mínimo, de 24 horas. Deberá especificarse el calendario propuesto y el número de horas ofertadas. Podrá exigirse que la capacitación se imparta en horario de mañana y/o tarde. Se debe garantizar que, tras la capacitación impartida, la administración y la configuración de estos sistemas sea completamente autónoma por parte del personal de Osakidetza, sin que se precise la actuación de personal de la empresa adjudicataria para dicha labor. El lugar de realización de la capacitación será a criterio de Osakidetza en el centro Corporativo que considere. 28

30 4.4 Configuración mínima a ofertar. Es objeto del contrato el aprovisionamiento mediante la modalidad de arrendamiento de nueva infraestructura de almacenamiento (que sustituya a la actual), consistente en la adquisición de cabinas de almacenamiento y solución para la virtualización de dicho almacenamiento, en los siguientes términos: Componentes equipos para cada CPD: o 600 TB de capacidad neta o Capacidad de servir IOPS sostenidos (esta capacidad deberá ser servida desde el conjunto de cabina de almacenamiento + sistema de virtualización) con tiempos de respuesta inferiores a 3 msg. para cargas de IO generadas por los aplicativos e infraestructura de servidores descrita. Para estas mediciones será necesario que se ofrezcan estudios de rendimiento de las configuraciones ofertadas, basándose en benchmark s tipo los publicados por storageperformance.org o mediante simulaciones realizadas con las herramientas de dimensionado propias de cada fabricante; y aportar gráficas de rendimiento. o El perfil de carga es el siguiente: 60% de las operaciones son escrituras 80% de las operaciones son random Tamaño de bloque medio de las operaciones random: 8K Tamaño de bloque medio de las operaciones secuenciales: 256K 60% de acierto en cache de lectura A nivel general y además de las condiciones apuntadas para la solución en cada CPD (CPD1 y CPD2), la solución de almacenamiento (cabinas + virtualizador), deberá de cumplir los siguientes requisitos: Multipathing en el acceso al almacenamiento SAN. La oferta deberá de incluir, a través de mecanismos de multipathing nativos de SO o solución de multipath de fabricante, solución para dotar a los servidores de caminos redundantes al almacenamiento y que las dos tarjetas de fibra sean capaces de trabajar en paralelo sobre la misma LUN. La solución (cabina + virtualizador) deberán ser ampliables en los términos necesarios para dar cabida a un futurible proyecto de VDI (Virtual Desktop Infraestructure) que despliegue puestos virtuales. La solución (cabina + virtualizador) deberán ser ampliables en los términos necesarios para conseguir un 25% más de capacidad de almacenamiento neta y ser capaz de servir un 40% adicional de IOPS sin pérdida de rendimiento. La solución será capaz de aportar solución de alta disponibilidad y contingencia (sin impacto en el servicio y de forma transparente para los servidores) en el acceso de los servidores al almacenamiento, como mínimo en los siguientes casos: o Pérdida de un camino físico a la SAN desde un servidor. 29

31 o Pérdida de un camino físico a la SAN desde el sistema de virtualización y/o cabina de almacenamiento. o Caída de algún nodo del sistema de virtualización y/o nodo/controladora de la cabina de almacenamiento. o Caída de una cabina de almacenamiento o Caída de un Fabric de la SAN. o Caída de un CPD completo. Solución de migración entre cabinas sin disrupción del servicio al usuario y de forma transparente para los servidores. La solución de almacenamiento deberá proporcionar un mecanismo de terceras copia que se integre con las aplicaciones de Osakidetza. 30

32 5. Plan de instalación y puesta en marcha. El contrato de arrendamiento incluirá: Diseño o o Implantación Diseño de la arquitectura de alta disponibilidad y continuidad del servicio entre los sistemas ofertados. Propuesta del plan de pruebas que se ejecutará para validar el correcto funcionamiento del conjunto final, y que incluirá, como mínimo, el rendimiento, el proceso de deduplicación y la alta disponibilidad entre ambos sistemas. o Una vez validado por Osakidetza el diseño propuesto, se deberá implantar y configurar dicho diseño. o Desembalaje y montaje de todos los elementos. o Instalación, configuración, puesta en marcha y validación de todos los elementos hardware y software ofertados, incluyendo la configuración de las funcionalidades al nivel existente previamente, en caso de que aplique. o Integración con la infraestructura SAN existente en Osakidetza o Realización de pruebas para verificar el rendimiento de los sistemas y el correcto funcionamiento. o Realización de pruebas para la verificación de la continuidad del servicio y la alta disponibilidad entre los sistemas. o Si fuera necesario por requisitos de servicio del centro destinatario, la instalación, la puesta en funcionamiento y la realización de las pruebas, y las labores de garantía, se realizarán fuera del horario laboral habitual. o El adjudicatario deberá suministrar todos los elementos necesarios para que los equipos queden plenamente operativos, como por ejemplo: latiguillos de red, etiquetas y bridas. o Los criterios de instalación y ubicación de los equipos, así como la fecha, los tiempos y horarios de instalación serán determinados por el personal del organismo destinatario, debiendo el adjudicatario proveer los medios necesarios para satisfacer estos requisitos. Documentación o Una vez concluida la instalación de los elementos y realizada la configuración y las pruebas necesarias, el adjudicatario deberá entregar la documentación de la instalación, que deberá incluir, como mínimo, la siguiente: Documentación con la configuración realizada y las pruebas realizadas con sus resultados 31

33 6. Garantía. Todo el material ofertado (hardware y software) deberá incluir la garantía durante el periodo del contrato según las condiciones que se detallan a continuación: Cobertura: 24 horas x 365 días a nivel de stocks, hardware y software. Soporte Remoto: la solución deberá estar monitorizada 24x7 por el fabricante. Para ello, deberá de implementar mecanismos de llamada a casa, que permitan al fabricante actuar de forma inmediata ante errores o fallos en la infraestructura de almacenamiento. Asistencia telefónica y web Tiempo de respuesta: 4 horas. Tiempo máximo de resolución: 24 horas. Acceso a las versiones actualizadas del producto y parches o revisiones de corrección de errores o mejoras. Acceso a la documentación on-line. Acceso a la base de datos de conocimiento. El licitador deberá presentar una propuesta que incluya detalladamente: Ubicación de sus instalaciones. Plan de revisiones periódicas. Plan de acción preventivo. Se requiere que todos los elementos hardware que se oferten no se encuentren incluidos en procesos de discontinuidad, descatalogación o fin de vida del fabricante. Posteriormente a esos 60 meses el proveedor deberá proponer un precio de soporte en la presente oferta, que nunca podrá superar el 20% anual del precio ofertado de licencia (+ IPC). 32

34 7. Presupuesto, plazo de ejecución y forma de pago. 7.1 Presupuesto. El presupuesto máximo asignado para este expediente es de sin IVA, % de IVA incluido. Los importes reflejados son máximos, y en ellos estarán incluidos todos los costes de desplazamiento, transporte, mano de obra y kit de equipos y piezas necesarias, no siendo propiedad de Osakidetza, para mantener el correcto funcionamiento de los equipos relacionados. 7.2 Plazo de ejecución. El plazo de ejecución es de 60 meses. 7.3 Forma de pago. Se presentarán facturas mensuales por el mismo importe. 33

35 8. Contenido de las ofertas. Los licitadores deberán incluir obligatoriamente en sus propuestas documentación tanto en formato impreso como en formato electrónico, con el siguiente contenido: 1. Información de la empresa vendedora a. Personas de contacto. Lista de personas a las que se les pueda solicitar información relacionada con el presente pliego b. Presentación de la compañía c. Certificaciones dentro de las tecnologías referenciadas en el presente pliego 2. Arquitectura de la solución propuesta a. Presentación de la arquitectura propuesta b. Detalle de la solución i. Descripción de los elementos HW ii. Descripción de opciones software iii. Protocolos de comunicación iv. Tecnologías de disco v. Plan de continuidad vi. Listado de funcionalidades no disruptivas y disruptivas de servicio vii. Mecanismo de protección viii. Descripción del proceso de reconstrucción de la información c. Escalabilidad i. Escalabilidad en capacidad del sistema ii. Escalabilidad en rendimiento iii. Capacidades de storage tiering iv. Capacidades de thin provisioning y expansión dinámica de volúmenes d. Gestión de la información i. Descripción de la herramienta de gestión ii. Automatización de procesos iii. Herramientas de configuración automática iv. Calidad de servicio v. Gestión del almacenamiento en base a políticas vi. Herramientas de análisis de información y reporting e. Eficiencia de almacenamiento i. Thin provisioning ii. Características del proceso de clonados 34

36 iii. Capacidades Green. Certificaciones de eficiencia energética f. Protección de la información i. Descripción general de las capacidades de protección de la información de la solución ii. Proceso de disaster recovery iii. Terceras copias. Método y capacidades máximas en número, volumen y rendimiento. 3. Seguridad de la información a. Acceso basado en roles b. Cifrado 4. Mejoras a lo demandado 5. Atención al cliente y soporte técnico a. Servicios de atención al cliente y soporte técnico b. Proceso de escalado c. Descripción de los servicios pro-activos ofertados d. Descripción de los servicios profesionales asociados al pliego e. Formación 6. Planificación de actividades a. Cronograma de tareas. Recoge la planificación en el tiempo de las tareas a realizar, marcando los módulos que servirán para realizar el control de la marcha del proyecto. b. Equipo de trabajo. En este apartado se describirán los perfiles técnicos de las personas que constituirán los equipos de trabajo para cada una de los S.I. objeto de este expediente. Se concretará la composición de la Oficina de Proyecto, la cual deberá realizar las siguientes tareas: i. Aplicación de la metodología propuesta ii. Coordinación del proyecto iii. Soporte a los equipos de trabajo iv. Organización, seguimiento y control del proyecto global v. Control de Calidad vi. Control de Cambios vii. Comunicaciones internas viii. Relaciones con terceros ix. Informes de Evolución del proyecto 35

37 x. Otras funciones que se considere oportunas para el buen fin del proyecto. c. Plazo de Ejecución. 7. Organización y Gestión del Proyecto a. Estructura organizativa. Este apartado deberá reflejar los aspectos organizativos del proyecto tales como las entidades que intervienen directa o indirectamente, los grupos de trabajo a constituir, modo de coordinación de estos grupos, etc. b. Funciones y responsabilidades. Para cada una de las entidades relacionadas en el apartado anterior, se definirán las funciones que deberán realizar y sus responsabilidades. c. Procedimientos de control y seguimiento. Se describirán los procedimientos a seguir para el control del proyecto, a fin de detectar posibles desviaciones y tomar las acciones correctivas adecuadas. 8. Metodología. Se describirá la Metodología seguida por la empresa ofertante para el desarrollo de proyectos de estas características. 9. Referencias de clientes. Entorno similares al presente pliego La omisión de cualquiera de estos apartados será motivo de exclusión de la propuesta. 36

38 9. Propiedad de los productos entregados Los equipos serán propiedad de la empresa adjudicataria o entidad que esta designe para ello, limitándose Osakidetza al pago de un arrendamiento mensual por el uso de los mismos. 37

39 10. Confidencialidad. En consideración al tipo de información procesada, el adjudicatario está obligado a mantener la más absoluta confidencialidad sobre todos aquellos datos y documentos a que tenga acceso con motivo de la adjudicación. A ellos accederán exclusivamente las personas estrictamente imprescindibles para el desarrollo de las tareas inherentes a la misma. Todas ellas serán advertidas del carácter confidencial y reservado de la información a la que tendrán acceso. Todos los ficheros que se pongan a disposición del adjudicatario para la ejecución del contrato son propiedad de Osakidetza y están registrados y sometidos a la salvaguarda que establece la legislación vigente, en especial la relativa a la protección de datos personales. Toda cesión a terceros será perseguida en los tribunales. Osakidetza se reserva el derecho de establecer cualquier tipo de marcaje de los ficheros que se dejarán al adjudicatario, de manera que sus características puedan constituirse como prueba que posibilite localizar el origen y los responsables de las eventuales cesiones. Bajo ningún caso ni circunstancia el adjudicatario podrá suministrar a terceros ni utilizar para sí ni para otros los datos facilitados por Osakidetza para fines distintos a los contemplados en el objeto del presente contrato. El adjudicatario estará obligado a poner en conocimiento de Osakidetza, inmediatamente después de ser detectada, cualquier sospecha de eventuales errores que se puedan producir en el sistema de seguridad de la información. El adjudicatario faculta a Osakidetza para que al terminar el proyecto pueda responsabilizarlo y/o repercutirle los costes derivados de posibles reclamaciones ocasionadas por negligencia y/o falta de confidencialidad del mismo. 38

40 Anexo I. Criterios de valoración Valoración de propuestas Para la elección de los criterios de valoración y su ponderación se han tenido en consideración los aspectos más significativos recogidos en el Pliego de Bases Técnicas que se acompaña a este expediente, a fin de garantizar que las ofertas de los licitadores se ajusten a lo exigido para los suministros objeto de este expediente. De acuerdo con lo antedicho, los criterios que servirán de base para la adjudicación del presente contrato serán los siguientes: Criterios de juicio de valor CRITERIOS DE JUICIO DE VALOR 50 A) Calidad Técnica. 50 Arquitectura tecnológica propuesta. 35 Arquitectura 10 Continuidad de negocio 10 Protección de la información 5 Eficiencia 6 Herramienta de gestión 3 Seguridad 1 Mejoras a las especificaciones demandadas

41 Arquitectura tecnológica propuesta Se valorará la idoneidad de la arquitectura propuesta valorándose de forma relevante la flexibilidad y escalabilidad de la solución así como las funcionalidades avanzadas que presente. 1. Arquitectura a. Escalabilidad en numeró y tipo de puertos de front-end y back-end b. Escalabilidad en capacidad del sistema c. Escalabilidad en rendimiento d. Arquitectura del back-end de discos 2. Continuidad de negocio (Disaster Recovery and Business Continuity) a. Características del proceso de failover/failback b. Capacidad de migrar información entre sistemas de características similares c. Capacidad de definir grupos de consistencia d. Arquitectura hardware propuesta. Se valorará el nivel de disponibilidad y la tolerancia a fallos de la solución. 3. Protección de la información 4. Eficiencia a. Gestión predictiva del estado de la infraestructura b. Copias locales i. Capacidad para hacer snapshots ii. Capacidad para hacer clones iii. Capacidad de realizar CDP iv. Nº máximo de copias locales v. Se valorara que las copias locales, sea cual sea el número, no impacten en el rendimiento vi. La capacidad de restauración de copia local. La velocidad del proceso c. Copia remota i. Replicación síncrona / asíncrona a. Capacidades Green. Certificaciones de eficiencia energética b. Soporte para storage tiering c. Soporte para thin provisioning d. Capacidad de comprimir la información almacenada 5. Herramienta de gestión 40

42 6. Seguridad a. Se valorara la capacidad de la solución de proveer reporting avanzado ( rendimiento, capacidad, uso, protocolos etc.) en tiempo real y guardar un histórico b. Se valorara la capacidad de la solución de permitir la automatización de procesos ( copia local, copia remoto ) así como la prioridad de estos c. Se valorara la capacidad del sistema de permitir la creación de diferentes roles de administración a. Se valorara la capacidad de cifrar la información almacenada b. Se valorara la capacidad de borrar de la información contenida en los discos de forma segura Mejoras en las características demandadas La puntuación se calculara de la siguiente manera: - Se asignará 1 punto por cada 50 TB de ampliación de la capacidad neta demandada para la fase 1 en cada una de las soluciones de almacenamiento de los 2 CPDs principales, hasta un máximo de 5 puntos. - Se asignaran 5 puntos a aquellas propuestas en que las funcionalidades software no dependen de la capacidad de almacenamiento disponible. Las licencias adquiridas, lo son para las futuras ampliaciones de capacidad. - Se asignaran hasta 5 puntos en función de las horas de soporte que se ofrezcan para la Fase 1 del despliegue de la infraestructura. 41

43 Criterios de fórmula CRITERIOS DE FÓRMULA 50 B) Precio. 50 Oferta económica La oferta cuyo importe sea igual al importe de licitación se valorará con 0 Puntos. La puntuación se calculará aplicando la siguiente fórmula: Precio Mínimo x 50 puntos Precio Ofertado 42

44 Anexo II. Características de la infraestructura ofertada El licitador debe entregar el desglose de componentes ofertados agrupados por Hardware, Software y CPD de destino. CPD1 y CPD2: Virtualizador 1 Virtualizador N Cabina de almacenamiento 1 Cabina de almacenamiento N Puertos FC Puertos FCoE Capacidad TB Rendimiento IOPS vs ms latency Licencias ofertadas Licencia Tipo 1 Licencia Tipo 2.. Capacidad Capacidad ofertada Capacidad ofertada Requerimientos Gestión SI/NO Consola de gestión instalable o web Las consolas de gestión deben poder cargarse en una amplia gama de sistemas operativos con un mínimo de requisitos. Monitorización eventos y estado Analítica de Los operadores deben ser conscientes de la situación y actividades de la solución para uso efectivo. La notificación de alertas a través de correo electrónico, consolas de usuario, Simple Network Management Protocol (SNMP), y / o scripts de usuario y la integración con las aplicaciones de monitorización de sistemas. Las aplicaciones de gestión deben prever mecanismos de gráficos e informes para rastrear los patrones de uso y el estado del almacenamiento 43

45 Disponibilidad Ampliación no disruptiva de capacidad de disco de no- Ampliación conectividad disruptiva La adición de espacio de almacenamiento debe ser una operación transparente y no afecta el rendimiento o la disponibilidad. La expansión de la conectividad adicional (por ejemplo, Fibre Channel [FC]) debe ser una operación transparente y no afecta el rendimiento o la disponibilidad. Actualizaciones de firmware no disruptiva Cualquier actualización de firmware debe ocurrir sin interrumpir las operaciones. Redundancia Gestión preventiva de los discos Debe ser compatible con las estrategias para la detección preventiva de fallas de disco. Detección preventiva de fallos Metodologías de previsión de fallos para evitar fallos inesperados, al permitir a los usuarios eliminar hardware sospechoso de fallar. Cache mirroring de controladora Redundancia de controladora de sistema Se requiere duplicación de caché para operaciones de escritura. Debe de disponer de la redundancia a nivel de controladora. El evento de fail-over no debe interrumpir los servicios de almacenamiento de conformidad con los requisitos de disponibilidad y no causa la pérdida de datos. Las controladoras redundantes deben compartir las cargas de trabajo durante el funcionamiento sin fallo. Redundancia en elementos internos de conectividad, ventilación, fuentes de alimentación etc. Gestión proactiva de las baterías Fuentes de alimentación redundadas El fallo de componentes individuales no debe causar una interrupción del servicio de datos. Debe proporcionar características de alerta para informar a los operadores cuando la batería (para protección de la memoria caché) o el sistema de alimentación ininterrumpida [SAI] requiere una acción de mantenimiento. System UPS Para la alta disponibilidad o continuidad de las operaciones, se debe ofrecer la capacidad de suministrar energía desde baterías con la capacidad suficiente para permitir un apagado ordenado y / o múltiples reinicios hasta que se restablezcan las operaciones normales de corriente. 44

46 Redundancia para la solución de virtualización La solución de virtualización ofertada no debe tener puntos de fallo únicos, el fallo de componentes individuales no debe causar interrupción del servicio de datos Continuidad de negocio Replicación síncrona Replicación asíncrona Failover/failback Replicación ininterrumpida Seguridad Conmutación por error que permita la continuidad de las operaciones en un lugar secundario en el caso de un desastre o mantenimiento del equipo. Conmutación por recuperación que permita volver a las operaciones normales después de la recuperación de sistema principal que ha fallado. Todo ello sin pérdida de servicio Una actividad de replicación a otro sistema no se debe interrumpir por otros eventos de movimiento de información generados en el sistema. Acceso autenticado con registro de acceso Soporte al a autenticación MS AD y LDAP Detección de intrusión y alarmas de retirada de HW no autorizado Thin Provisioning Debe soportar la validación de usuarios mediante los protocolos descritos Debe alertar a los operadores a una intrusión física en los sistemas de almacenamiento y / o una eliminación del dispositivo. Thin-provisioning Soporte thin-provisioning Terceras copias Storage tiering Migraciones concurrentes volúmenes Block granularity Soporte discos de Debe soportar la creación de terceras copias Debe ser compatible con las migraciones de volumen entre los niveles de almacenamiento predefinidos dentro de un marco. La granularidad para el movimiento de información entre tiers debe de ser a nivel de bloque 45

47 Soporte a múltiples tecnologías de disco Debe permitir la selección y mezcla de varios tipos de unidades de disco. Soporte Solid-state disk (SSD) Debe soportar la creación de volúmenes individuales Flash LUNs exclusivamente en Flash SSD. Debe soportar configurar los discos SSD para apoyar el Flash SSD auto-tier movimiento automatizado de los datos activos dentro de una LUN entre los dispositivos SSD y los discos de alta capacidad. Protocolos y conectividad Debe soportar el acceso de los host por más de un path y balancear la carga entre dichos path. Esta integración a nivel de Multipathing host puede ser con software propietario del sistema de almacenamiento o con las utilidades de cada S.O. FC 4 Gbit/s Debe soportar puertos a 4 Gbit / s FC. FC 8 Gbit/s Debe soportar puertos a 8 Gbit / s FC. Entornos operativos Soporte a S.O. AIX 6.1 o superior HP-UX o superior ESXi 5.x o superior Windows 2008 o superior Red Hat Linux 5 o superior Soporte a virtualización VMware vsphere Monitorización hardware Monitorización ambiental Control adaptativo de la temperatura de funcionamiento Debe facilitar características, capacidad y conectividad suficientes para apoyar la virtualización de servidores. Debe ofrecer un plug-in de gestión para VMware vcenter e integración con VMware vstorage API. Debe monitorizar su estado incluyendo la temperatura ambiente, estado de energía, consumo de energía y proporcionar alertas a la infraestructura de gestión para las condiciones fuera de rango. Debe ser compatible con la gestión del ventilador de refrigeración para mantener la temperatura de los componentes y con gracia apagar un sistema o parte de un sistema para protegerlo de condiciones de sobrecalentamiento. Front-to-back airflow Escalabilidad Servicios de test de rendimiento Protección de la inversión El proveedor debe proporcionar la posibilidad de hacer pruebas de rendimiento, ya sea en las instalaciones del cliente o en un centro de pruebas para probar las reclamaciones de rendimiento utilizando las cargas de trabajo de los clientes. 46