APROVISIONAMIENTO BAJO LA MODALIDAD DE ARRENDAMIENTO DEL HARDWARE Y SOFTWARE NECESARIO PARA LA CONSOLIDACIÓN DE LOS DIFERENTES CPD HOSPITALARIOS

Transcripción

1 APROVISIONAMIENTO BAJO LA MODALIDAD DE ARRENDAMIENTO DEL HARDWARE Y SOFTWARE NECESARIO PARA LA CONSOLIDACIÓN DE LOS DIFERENTES CPD HOSPITALARIOS PLIEGO DE BASES TÉCNICAS 1

2 1. Introducción Objeto y alcance Descripción de la infraestructura a consolidar Plataformas de virtualización en hospitales VM y vcpu asignadas Comparativa recursos cluster Consumos medios CPU y memoria Información datastores Bases de datos territoriales CPD Territorial de Bizkaia CPD Territorial de Araba CPD Territorial de Gipuzkoa Necesidades imagen medica Necesidades computación Necesidades de almacenamiento Características de los sistemas requeridos Características generales Características técnicas Capacitación Configuración mínima a ofertar CPD de Bizkaia CPD de Gipuzkoa CPD de Araba CPD Organización Central Ambulatorio Dr Areilza, H. Basurto y H. Galdakao 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 11. CONSULTAS AL PLIEGO Anexo I. Criterios de valoración Criterios de juicio de valor Criterios de fórmula

4 1. Introducción Varios de lo Hospitales de la Red de Osakidetza disponen de entornos de virtualización de aplicaciones que aportan servicios y soporte avanzado como pueden ser: alta disponibilidad, almacenamiento escalable y de gran rendimiento, herramientas de salvaguarda y recuperación de datos, etc. Se ve necesario acometer un proyecto de renovación de estos entornos de virtualización de manera que se pueda continuar ofreciendo esos servicios a las nuevas necesidades de los centros. 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 computación al consolidar los diferentes CPD hospitalarios en 3 CPDs (uno por cada Territorio). 4

5 2. Objeto y alcance El objeto del presente pliego es dotar, a centros hospitalarios de la red de Osakidetza, de la infraestructura informática necesaria para la consolidación, conservación y recuperación de servicios y datos. La finalidad es dotar, gradualmente, a las distintas organizaciones, de una infraestructura básica común que permita consolidar los servicios existentes en las mismas, virtualizar los entornos aislándolos del hardware y facilitar una arquitectura, unificable en todos los centros y capaz de crecer escaladamente en servicios de proceso y almacenamiento. Se solicita una solución modular, escalable y que permita ofrecer a cada centro los recursos informáticos necesarios a su situación. Cada uno de los centros tendrá un proyecto a la medida de sus necesidades por lo que la solución a adoptar para cada uno de ellos puede ser distinta aunque partiendo siempre de recursos informáticos homogéneos 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 computación al consolidar los diferentes CPD hospitalarios en 3 CPDs (uno por cada provincia). 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. 5

6 3. Descripción de la infraestructura a consolidar 3.1 Plataformas de virtualización en hospitales Se detallan a continuación las infraestructuras distribuidas de la organización que dan soporte a las plataformas de virtualización VM y vcpu asignadas Comparativa recursos cluster 1

7 3.1.3 Consumos medios CPU y memoria 2

8 3.1.4 Información datastores 3

9 4

10 5

11 6

12 3.2 Bases de datos territoriales A continuación se detallan las infraestructuras actuales que dan soporte a la BBDD territoriales de la organización. Estos recursos deberán integrarse bajo plataforma x86 dentro de la nueva infraestructura a entregar CPD Territorial de Bizkaia H.CRUCES STORAGE Modelo Cabina Ubicación Capacidad Total(bruta) Capacidad Usada Contenido EVA-BIZKAIA EVA8000 CPD- H.Cruces ,33 Gb 9.728,84 Gb Base de Datos Oracle Disk Groups: Tipo de disco Discos físicos dg_backup 1000 Gb 15k FATA ,58 Gb 5.175,00 Gb Pre-backups diarios en disco(rman-exports) dg_ Gb 15k FC ,17 Gb 2.860,98 Gb Filesystems de Oracle-Producción dg_standby 72 Gb 15k FC ,72 Gb 1.692,86 Gb Filesystems de Oracle- Preproducción desagrupados 72 Gb 15k FC ,76 Gb 0,00 Gb Discos físicos disponibles sin datos SERVIDORES Modelo Centro Uso CPU Memoria biz6600 HP IA64- rx6600 Hospital Cruces Producción_Servidor Base de Datos Oracle Gb admbiz HP IA64- rx7620 Hospital Cruces Pre-Producción_Servidor Base de Datos Oracle 4 32 Gb monbiz HP Proliant DL360 G4 Hospital Cruces Servidor de gestión: CellServer-DP,CV- EVA,Oracle-RMAN 2 4 Gb 7

13 H.TXAGORRI TXU CPD Territorial de Araba Capacidad Usada Contenido CPD- H.Txagorritxu 6.519,04 Gb 5.116,65 Gb Base de Datos Oracle STORAGE Modelo Cabina Ubicación Capacidad Total(bruta) EVA-ARABA EVA8000 Disk Groups: Tipo de disco Discos físicos 250 Gb 15k Pre-backups diarios en dg_backup FATA ,12 Gb 1.250,53 Gb disco(rman-exports) dg_oracle10 72 Gb 15k FC ,66 Gb 2.220,81 Gb Filesystems de Oracle-Producción Filesystems de Oracledg_standby 72 Gb 15k FC ,26 Gb 1.645,31 Gb Preproducción SERVIDORES Modelo Centro Uso CPU Memoria admgip10 HP IA64-rx7620 Hospital Txagorritxu Producción_Servidor Base de Datos Oracle 4 32 Gb admarasb HP IA64-rx4640 Hospital Txagorritxu Pre-Producción_Servidor Base de Datos Oracle 2 32 Gb monara HP Proliant DL360 G4 Hospital Txagorritxu Servidor de gestión: CellServer-DP,CV- EVA,Oracle-RMAN 2 4 Gb 8

14 H.DONOSTIA CPD Territorial de Gipuzkoa STORAGE Modelo Cabina Ubicación Capacidad Total(bruta) Capacidad Usada Contenido EVA- GUIPUZKOA EVA8000 CPD- H.Donostia 8.662,61 Gb 7.132,56 Gb Base de Datos Oracle Disk Groups: Tipo de disco Discos físicos dg_backup 250 Gb 15k FATA ,23 Gb 2.938,77 Gb Pre-backups diarios en disco(rman-exports) dg_oracle10 72 Gb 15k FC ,59 Gb 2.821,06 Gb Filesystems de Oracle-Producción dg_standby 72 Gb 15k FC ,79 Gb 1.372,73 Gb Filesystems de Oracle- Preproducción desagrupados 72 Gb 15k FC ,76 Gb 0,00 Gb Discos físicos disponibles sin datos SERVIDORES Modelo Centro Uso CPU Memoria admgip10 HP IA64-rx6600 Hospital Donostia Producción_Servidor Base de Datos Oracle Gb admgip HP IA64-rx7620 Hospital Donostia Pre-Producción_Servidor Base de Datos Oracle 4 32 Gb mongip HP Proliant DL360 G4 Hospital Donostia Servidor de gestión: CellServer-DP,CV- EVA,Oracle-RMAN 2 4 Gb 9

15 3.3 Necesidades imagen medica Necesidades computación CPD territorial de Bizkaia CPD Territorial Bizkaia - 3 PACS en 1 Data Center (PACS Hospital de Cruces, Hospital de Galdakao y Hospital de Basurto) Data Center VM's VM # Server name OS vcores vram (GB) VMDK size (GB) VMFS size (GB) PACS Hospital Cruces 1 IMPAX WFM1 1 W2008R IMPAX WFM2 1 W2008R IMPAX WFM3 1 W2008R IMPAX APP1 1 W2008R IMPAX APP2 1 W2008R XERO1 1 OL XERO2 1 OL PACS Hospital Galdakao 1 IMPAX APP1 1 W2008R IMPAX APP2 1 W2008R XERO1 1 OL XERO2 1 OL PACS Hospital Basurto 1 IMPAX APP1 1 W2008R IMPAX APP2 1 W2008R XERO1 1 OL XERO2 1 OL TOTAL Superspoke

16 CPD territorial de Araba CPD Territorial de Araba VM # Server name OS vcores vram (GB) VMDK size (GB) VMFS size (GB) Data Center VM's PACS Hospital Txagorritxu 1 IMPAX WFM1 1 W2008R IMPAX WFM2 1 W2008R IMPAX WFM3 1 W2008R IMPAX WFM/AS 1 W2008R IMPAX APP1 1 W2008R IMPAX APP2 1 W2008R IMPAX APP Medicina Nuclear 1 W2008R XERO1 1 OL XERO2 1 OL TOTAL Superspoke

17 CPD territorial de Gipuzkoa HOSPITAL DONOSTI Server name OS vcores VM # vram (GB) VMDK size (GB) VMFS size (GB) Data Center VM's PACS Hospital Donostia 1 IMPAX WFM1 1 W2008R IMPAX WFM2 1 W2008R IMPAX WFM3 1 W2008R IMPAX WFM/AS 1 W2008R IMPAX APP1 1 W2008R IMPAX APP2 1 W2008R IMPAX APP Medicina Nuclear 1 W2008R XERO1 1 OL XERO2 1 OL TOTAL Superspoke

18 Ambulatorio Dr Areilza, H. Basurto y H.Galdakao WFM remoto Data Center 1 IMPAX WFM1 1 IMPAX WFM2 1 IMPAX WFM3 TOTAL Superspoke VM's VM # Server name OS vcores vram (GB) VMDK size (GB) 1 W2008R W2008R W2008R VMFS size (GB)

19 3.3.2 Necesidades de almacenamiento CPD Territorial Bizkaia Impax application Comments Access Tier 1 Tier 2 FC/SAS 10KRPM GB GB RAID 10 RAID 5 IMPAX PACS Basurto Impax PACS BBDD ref YR 5 SAN 400 Impax CM SAN 100 Impax PACS BBDD - backup SAN 1600 Impax CM backup SAN 200 IMPAX WFM front-end 1 3 months SAN 572 IMPAX WFM front-end 2 3 months SAN 572 WFM back-end - Dicom cache VM Volumes 10KRPM 5% annual increment productivity year 2016 year 2017 year 2018 year year online, ref YR5 SAN VM's (80GB)+2 Xero SAN VMware volumes 1 VMware volumes 1&2 back-up SAN Total Net Capacity IMPAX PACS Galdako Impax PACS BBDD ref YR 5 SAN 350 Impax CM SAN 100 Impax PACS BBDD - backup SAN 1400 Impax CM backup SAN 200 IMPAX WFM front-end 1 3 months SAN 465 IMPAX WFM front-end 1 3 months SAN 465 WFM back-end - Dicom cache 5% annual increment productivity year 2016 year 2017 year 2018 year year online, ref YR5 SAN

20 VM Volumes VMware volumes 1 VM's (80GB)+2 Xero SAN VMware volumes 1&2 back-up SAN Total Net Capacity IMPAX PACS Cruces Impax PACS BBDD ref YR 5 SAN Impax CM SAN 100 Impax PACS BBDD - backup SAN 4000 Impax CM backup SAN 200 IMPAX WFM front-end 1 3 months SAN % annual IMPAX WFM front-end 1 3 months SAN 1220 increment productivity IMPAX WFM front-end 1 3 months SAN 1220 year 2015 WFM back-end - Dicom cache VM Volumes year 2016 year 2017 year year online, ref YR5 SAN VM's (80GB)+2 Xero SAN VMware volumes 1 VMware volumes 1&2 back-up SAN Total Net Capacity TOTAL

21 CPD Territorial de Araba Impax application Comments Access Tier 1 Tier 2 FC/SAS FC/SAS 10KRPM 10KRPM GB GB RAID 10 RAID 5 IMPAX PACS Impax PACS BBDD ref YR 5 SAN 300 Impax CM SAN 100 Impax PACS BBDD - backup SAN 1200 Impax CM backup SAN 200 IMPAX WFM front-end 1 3 months SAN 507 5% annual IMPAX WFM front-end 1 3 months SAN increment 507 productivity IMPAX WFM front-end 1 3 months SAN 507 year 2015 WFM back-end - Dicom cache VM Volumes year 2016 year 2017 year year online, ref YR5 SAN VM's (80GB)+2 Xero SAN VMware volumes 1 VMware volumes 1&2 back-up SAN Total Net Capacity

22 CPD Territorial de Gipuzkoa Impax application Comments Access Tier 1 Tier 2 FC/SAS FC/SAS 10KRPM 10KRPM GB GB RAID 10 RAID 5 IMPAX PACS Impax PACS BBDD ref YR 5 SAN 900 Impax CM SAN 100 Impax PACS BBDD - backup SAN 3600 Impax CM backup SAN 200 IMPAX WFM front-end 1 3 months SAN % annual IMPAX WFM front-end 1 3 months SAN increment 1260 productivity IMPAX WFM front-end 1 3 months SAN 1260 year 2015 WFM back-end - Dicom cache VM Volumes year 2016 year 2017 year year online, ref YR5 SAN VM's (80GB)+2 Xero SAN VMware volumes 1 VMware volumes 1&2 back-up SAN Total Net Capacity

23 Ambulatorio Dr Areilza, H. Basurto y H. Galdakao Impax application Comments Access Tier 1 Tier 2 IMPAX PACS IMPAX front-end 1 IMPAX front-end 1 IMPAX front-end 1 VM Volumes WFM WFM WFM VMware volumes 1 VMware volumes 1&2 back-up Total Capacity Net FC/SAS 10KRPM GB FC/SAS 10KRPM GB RAID 10 RAID 5 3 months SAN months SAN months SAN 1000 VM's Xero (80GB)+2 SAN 240 SAN

24 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. 1

25 4.1 Características generales. La infraestructura a adquirir estará compuesta por servidores y almacenamiento. Las infraestructuras tendrán que dar soporte a la consolidación de las plataformas de virtualización de cada provincia, las necesidades de la unificación de recursos de la plataforma de imagen médica de AGFA y a las bases de datos territoriales. Así mismo, parte del almacenamiento contratado dará servicio a la solución de copias de seguridad que se implementará desde la organización central. Dejamos al criterio de licitador la conectividad interna de los equipos a los recursos de almacenamiento, pero deberá ser acorde a los requisitos de rendimiento especificados a partir de la capacidad demandada para cada pool de almacenamiento. Si será necesario que la infraestructura entregada se integre correctamente con los recursos de conectividad LAN de cada centro. 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, 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. 2

26 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 Cloud con escalabilidad horizontal sin parada de servicio y por tanto cumplir las siguientes características mínimas: Servidor tipo I 1 Procesador Servidor de 2 socket CPU Procesador x86 SPECrate CPU 2006 puntuación mínima de 900 (CINT2006rate y CFP2006rate) 2 Chipset Ultimo chipset Intel/AMD suportado por el procesador 3 Memoria 128 GB ampliable a 256 GB 4 Protección de memoria ECC avanzado con protección de error multibit y soporte memory mirroring 5 Discos duros Hot Swap 2 x 300GB 10k/15k SAS. Soporte RAID 0/1 6 Conectividad Ethernet 2x10Gb. Soporte HW para iscsi y FCoE 7 Bus slots 2 slots adicionales de expansión PCI-E 8 Soporte SO VMware vsphere 5.5, Linux Red HAT 9 Diagnostico Notificación pre-fallo de los componentes mas importantes: CPU, memoria, discos etc. 10 Administración Suite de administración centralizada para todos los servidores. Control de salud del sistema, capacidad de apagado y encendido, acceso remoto a CD-rom o imágenes ISO. Acceso basado en web. 12 Seguridad Contraseña de encendido, contraseña de administrador 3

27 Servidor tipo II 1 Procesador Servidor de 1 socket CPU. Procesador x86 SPECrate CPU 2006 puntuación mínima de 200 (CINT2006rate y CFP2006rate) 2 Chipset Ultimo chipset Intel/AMD suportado por el procesador 3 Memoria 32 GB ampliable a 128 GB 4 Protección de memoria ECC avanzado con protección de error multibit y soporte memory mirroring 5 Discos duros Hot Swap 2 x 300GB 10k/15k SAS. Soporte RAID 0/1 6 Conectividad Ethernet 4x1Gb. 7 Bus slots 2 slots adicionales de expansión PCI-E 8 Soporte SO VMware vsphere Diagnostico Notificación pre-fallo de los componentes mas importantes: CPU, memoria, discos etc. 10 Administración Suite de administración centralizada para todos los servidores. Control de salud del sistema, capacidad de apagado y encendido, acceso remoto a CD-rom o imágenes ISO. Acceso basado en web. 12 Seguridad Contraseña de encendido, contraseña de administrador 4

28 Chasis blade 1 Chasis formato rack Soporte para servidores full height y half height con capacidad mínima de 8 servidores por chasis 2 Soporte para módulos de gestión hot-swap 5 Ventiladores redundantes y hot-swap. Se han de instalar todos los ventiladores del chasis. 6 Conectividad dual redundante para cada servidor. 7 Al menos capacidad para 4 módulos I/O 8 Se han de instalar todas las fuentes de alimentación en el chasis. Deben de soportar configuraciones N+N, N+1 donde es superior a 1 9 Power management: Visión en tiempo real del consume energético y de temperatura de los componentes 11 2 Generar gráficas de consumo. 12 El chasis debe disponer de switches redundantes de Ethernet a 10GB con soporte FCoE. 13 El chasis debe de proveer al menos 1 DVD que se pueda usar por todos los servidores blade o se debe soportar presentar DVD remotos virtuales. 5

29 Almacenamiento 1 Controladoras Dobles redundantes en modo activo-activo 2 Cache 8GB netos de mirrored cache 3 Conectividad 4 puertos de FE por controladora 8 gbps. Multiprotocolo FC, iscsi, FCoE, NFS 5 Niveles de RAID 6 Ventilación, fuentes alimentación de 0, 0+1, 1, 5, 6 o equivalente. Duales redundantes y hot-swap 7 Soporte SAN El array debe de ser compatibles con entornos SAN 8 Soporte discos 600, 900, 1200GB o superiores 10K RPM FC/SAS 1, 2, 3, 4TB o superiores 7,2K NL-SAS/SATA 200, 400, 800 SSD/Flash 9 Soporte Multi-tiering para la optimización de rendimiento/coste con la tecnología SSD/Flash 10 Soporte protocolos FC, iscsi, FCOE,NFS 11 Debe proporcionar mecanismos de protección de memoria cache 12 Todo el SW necesario para configurar o gestionar el espacio de almacenamiento, configuración RAID, gestión de LUNs, virtualización, snapshots etc, para toda la capacidad ofertada. 13 Fuentes de alimentación, baterías, ventiladores y data path redundantes. 14 Soporte nativo multipath. La misma debe ser documentada en una matriz de interoperabilidad. 15 Soporte para replicación remota vía IP. 16 Actualización de firmware online para controladoras y discos 17 El almacenamiento ha de ser capaz de redirigir el tráfico en caso de caída del path principal de acceso a servidor. 6

30 Almacenamiento 18 Soporte de virtualización de almacenamiento y thinprovisioning 19 Escalabilidad horizontal de la solución sin parada del servicio, permitiendo crecimiento bandejas de discos y controladoras en caliente, así como su sustitución en caliente para realizar renovaciones tecnológicas o cambios en la configuración. 20 Se suprime esta característica técnica 21 Soporte para snapshots y clones. Será necesario incluir los agentes necesarios para garantizar la consistencia de las copias, así como la rápida recuperación de los datos a partir de los snapshots 22 El software de gestión debe permitir el control y la monitorización del rendimiento del sistema, definiendo niveles de servicio basados en IOPS y/o MB/s por entornos de aplicaciones y volúmenes/luns que limiten el consumo de rendimiento 23 La solución Integración con herramientas de gestión de Cloud vía APIs abiertas, para automatizar tareas de aprovisionamiento y protección de datos, y estandarizar procesos de administración 7

31 Pool Tipo I almacenamiento Disco SSD/Flash Capacidad neta total en SSD/Flash para optimizar el rendimiento/coste del sistema de almacenamiento, pudiendo utilizar esta tecnología combinada con almacenamiento de tipo II y III con funcionalidades de tiering de almacenamiento. Pool Tipo II almacenamiento SAS Capacidad neta total en discos SAS a 10k rpm en R5 o similar, para entornos con necesidades de rendimiento medio/alto Pool Tipo III almacenamiento NL-SAS/SATA Capacidad neta total en discos NL-SAS a 7,2k rpm en R6 o similar, para entornos con necesidades de rendimiento bajo Consola 1 Form factor Rack 2 Monitor 17 TFT LCD/LED Resolución 1280 x Puntero Estándar touch pad / ratón de 3 botones 4 Teclado Teclado estándar 104 teclas. 5 Switch kvm 8 puertos Acceso LAN Usuarios concurrentes Usuarios remotos concurrentes Si 1 1 8

32 4.3 Capacitación Requerimientos Realización de capacitación sobre los sistemas, 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. 9

33 4.4 Configuración mínima a ofertar. La configuración mínima debe poder consolidar los requisitos expuestos en el punto 3 del presente documento, así como una previsión de crecimiento de un 20% en 5 años. La configuración mínima a presentar a criterio de Osakidetza se detalla en los siguientes puntos CPD de Bizkaia Servidores o o Almacenamiento o o o 10 servidores de tipo 1. Los servidores pueden ser en formato blade o rack. En caso de suministrar los servidores en formato rack, el chasis debe cumplir las especificaciones mínimas del apartado Características técnicas. Se ha de suministrar RACK y consola para su instalación Pool de discos tipo I para producción de 8 TB netos Pool de discos tipo II para producción de 200 TB netos Pool de discos tipo III para copias de 100 TB Todo el sistema se debe integrar con la infraestructura de comunicaciones del centro. En el CPD territorial de Bizkaia el core de comunicaciones esta compuesto por: 2 equipos Cisco 6509-E con dos tarjetas tarjetas de 48 puertos RJ45 10/100/1000 por equipo, y 40 puertos libres por equipo CPD de Gipuzkoa Servidores o o Almacenamiento o o o 5 servidores de tipo 1. Los servidores pueden ser en formato blade o rack. En caso de suministrar los servidores en formato rack, el chasis debe cumplir las especificaciones mínimas del apartado Características técnicas. Se ha de suministrar RACK y consola para su instalación Pool de discos tipo I para producción de 4 TB netos Pool de discos tipo II 80 TB netos Pool de discos tipo III para copias de 50 TB Todo el sistema se debe integrar con la infraestructura de comunicaciones del centro. En el CPD territorial de Gipuzkoa el core de comunicaciones esta compuesto por: 4 equipos Cisco WSC3750X-48T-L de 48 bocas recientemente instalados en la renovación LAN CPD de Araba Servidores o o Almacenamiento 5 servidores de tipo 1. Los servidores pueden ser en formato blade o rack. En caso de suministrar los servidores en formato rack, el chasis debe cumplir las especificaciones mínimas del apartado Características técnicas. Se ha de suministrar RACK y consola para su instalación 10

34 o o o Pool de discos tipo I para producción de 4 TB Pool de discos tipo II para producción de 50 TB netos Pool de discos tipo III para copias de 30 TB CPD Organización Central Almacenamiento copias de seguridad o o Pool tipo III de 200 TB 1 servidor tipo 1 con 256 GB de RAM en formato RACK Todo el sistema se debe integrar con la infraestructura de comunicaciones del centro Ambulatorio Dr Areilza, H. Basurto y H. Galdakao En cada uno de los centros se debe de instalar la siguiente infraestructura. Servidores o Almacenamiento o o 2 servidores de tipo 2 en formato RACK Pool tipo I de discos SSD/SAS para producción de 1 TB neto. Pool tipo II de discos SSD/SAS para producción de 5 TB netos Todo el sistema se debe integrar con la infraestructura de comunicaciones de cada centro. Las características por cada centro: H. Galdakao y H. Basurto: 2x 3750E-48-TD-S con 37 puertos libres (sin problema) Ambulatorio de Dr Areilza: un Cisco TT-L 11

35 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 12

36 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. 13