Nombre de la compra: CARTEL TÉCNICO PARA LA … · 3.12 Deberá soportar la conexión de teclado,...

ESPHF-AD-010(5)

Cartel para Contratación de Servicios

1

Nombre de la compra: CARTEL TÉCNICO PARA LA ADQUISICIÓN DE IN-

FRAESTRUCTURA DE T.I. PARA EL PROYECTO DE

CLIENTE EMPRESARIAL

Fecha: 30/06/2016

Procedimiento CONCURSO MAYOR 3-2016

I. Objetivo de la Compra

La ESPH requiere la adquisición de Infraestructura de T.I. que permita alojar el aplicativo

de gestión para los comprobantes electrónicos del CLIENTE, solución que se brinda a uno

de sus clientes empresariales. La presente contratación tiene como objetivo la adquisición

de la arquitectura de T.I. así como los servicios de instalación, configuración, puesta en

marcha, y gestión de la plataforma durante el plazo contratado.

II. Objetivo Específico de la Compra

La ESPH requiere contratar una plataforma convergente de procesamiento, almacenamien-

to, respaldo, recuperación, así como los componentes de software y licenciamiento requeri-

dos para que dicha plataforma opere de forma óptima durante el plazo del contrato.

A continuación, se detalla la lista de componentes tecnológicos y los servicios requeridos

para la presente contratación:

1. INFRAESTRUCTURA TECNOLÓGICA CONVERGENTE

2. GABINETES

3. SERVIDORES TIPO BLADE

4. CHASIS (ENCLOSURE) PARA ALBERGAR SERVIDORES BLADE

5. SOFTWARE DE ADMINISTRACIÓN DE LOS SERVIDORES BLADE

6. ELEMENTOS DE INTERCONEXIÓN DE RED INCLUIDO EN EL

CHASIS

7. SWITCHES CONVERGENTES DE ACCESO LAN Y SAN

8. SWITCHES DE DISTRIBUCIÓN

9. SISTEMA DE ALMACENAMIENTO UNIFICADO

10. SOFTWARE DE ADMINISTRACIÓN DEL ALMACENAMIENTO

11. SOFTWARE DE BALANCEO DE CARGAS Y FAILOVER EN SAN

ESPHF-AD-010(5)


2

12. SISTEMA DE MONITOREO DE INFRAESTRUCTURA DE

ALMACENAMIENTO

13. SISTEMA DE RESPALDO A DISCO CON DEDUPLICACIÓN EN

LÍNEA

14. SOFTWARE DE VIRTUALIZACIÓN VMWARE

15. CAPA DE ACCESO VIRTUAL A LA RED DEL CENTRO DE DATOS

16. HERRAMIENTA DE ADMINISTRACIÓN Y CONFIGURACIÓN DE LA

INFRAESTRUCTURA VIRTUAL

17. SOLUCIÓN DE ALMACENAMIENTO DE DATOS NO

ESTRUCTURADOS

18. SOFTWARE PARA GESTIÓN Y OPERACIÓN DE

ALMACENAMIENTO DE DATOS NO ESTRUCTURADOS

19. SERVICIOS DE: INSTALACIÓN Y CONFIGURACIÓN Y PUESTA EN

MARCHA DE LA SOLUCIÓN

20. SERVICIOS DE: MANTENIMIENTO CORRECTIVO Y

MANTENIMIENTO PREVENTIVO DE LA ARQUITECTURA DE T. I

DURANTE EL PLAZO DE LA CONTRATACIÓN

21. SERVICIOS DE GESTIÓN DE LA PLATAFORMA DURANTE EL

PLAZO DEL CONTRATO.

III. ESPECIFICACIONES DEL SERVICIO A CONTRATAR

Se detallan a continuación, las características específicas de la solución y servicios a contra-

tar:

1. ESPECIFICACIONES GENERALES DE LA INFRAESTRUCTURA TEC-

NOLÓGICA CONVERGENTE:

1.1 Se requiere una solución integral en la modalidad “llave en mano” que posea

dispositivos unificados tanto en comunicación de datos, almacenamiento unifi-

cado, almacenamiento de crecimiento horizontal (scale-out), servidores de pro-

cesamiento y respaldo de datos. La solución debe ser configurada, integrada y

probada como un todo, en fábrica, antes de la entrega de manera que sea total-

mente funcional al momento de la entrega, de manera que sea totalmente fun-

cional al momento de la entrega

ESPHF-AD-010(5)


3

1.2 El adjudicatario deberá entregar los equipos de esta contratación debidamente

conectados al suministro eléctrico que proveerá ESPH.

1.3 El adjudicatario deberá realizar la conexión a la instalación eléctrica, de

acuerdo a los lineamientos del IF; de modo que todos los componentes queden

funcionando de forma óptima, de acuerdo a las especificaciones del fabricante y

a plena satisfacción del ESPH.

1.4 El oferente debe garantizar el suministro de repuestos genuinos, mano de obra

especializada, reemplazo de piezas defectuosas y la existencia en Costa Rica de

un centro de mantenimiento y asistencia técnica para todos los equipos y

dispositivos ofertados en esta contratación. El oferente deberá rendir una

declaración jurada en su oferta indicando que cuenta con dicho centro de

mantenimiento y la asistencia técnica calificada, además la ESPH queda

facultada a realizar verificaciones en sitio en caso de resultar necesario.

1.5 La atención de averías y soporte de garantías de todos los componentes de la

solución deberá ser por 3 años. La ESPH SA podrá prorrogar el servicio por 12

meses adicionales de conformidad a sus procedimientos internos. El servicio se

debe atender 24x7 (24 horas x 7 días); por un único fabricante o entidad de so-

porte y un único punto de contacto; de manera que la ESPH no se vea obligada

a comunicarse con varios fabricantes o contactos para recibir el soporte requeri-

do. Igualmente las actualizaciones y nuevas versiones de software y firmware,

deberán entregarse como un único paquete de actualizaciones, previamente

probadas y certificadas, de forma tal que la institución no se vea obligada a ac-

ceder o solicitar actualización de versiones de sus componentes a varios fabri-

cantes o entidades. Además, deberá ofrecer la opción de extender esta garantía

completa y soporte de la solución por periodos adicionales de 12 meses.

2. GABINETES

2.1 Debe cumplir con las especificaciones del Gabinete de referencia Panduit

S7522B.

2.2 Gabinete (RACK) de 45 RMU de alto como máximo.

2.3 Debe ser para equipos de cómputo estándar de 48.26 cm (19”)

2.4 Otras dimensiones

Ancho: 700.00 mm

Fondo: 1000.00 mm o superior

Alto: 2000.00 mm o superior

2.5 Se deben suministrar todos los accesorios (rieles, cables de KVM, cables de po-

der) necesarios para la instalación de los equipos.

2.6 Puertas frontal y posterior micro perforadas (superior o igual al 80%) y paneles

laterales con llave única.

3. SERVIDORES TIPO BLADE

3.1 Se deberán incluir mínimo 10 servidores tipo blade.

3.2 Dos (2) servidores deberán tener cada uno la siguiente configuración de proce-

sador y memoria:

ESPHF-AD-010(5)


4

a. Poseer un (1) solo procesador de la familia Intel Xeon E5-2600 v3 (8

cores) o superior, de 64 bits y de, al menos, 2.40 GHz.

b. Deberá manejar al menos 8 cores totales.

c. Deberá manejar al menos 16 threads totales.

d. Deberá estar equipado con al menos 128 GB RAM DDR4 cada uno.

3.3 Tres (3) servidores deberán tener cada uno la siguiente configuración de proce-

sador y memoria:

a. Poseer dos (2) procesadores de la familia Intel Xeon E5-2600 v3 (8 co-

res) o superior, de 64 bits y de, al menos, 2.40 GHz.




3.4 Cinco (5) servidores deberán tener cada uno la siguiente configuración de pro-

cesador y memoria:

a. Poseer dos (2) procesadores de la familia Intel Xeon E5-2600 v3 (8 co-

res) o superior, de 64 bits y de, al menos, 2.40 GHz.




3.5 La configuración de las memorias de los equipos deberá ser realizada de acuer-

do a las mejores prácticas del fabricante.

3.6 Capacidad mínima de crecimiento de 1.5 TB en RAM (usando DIMMs de

memoria de 64 GB), deben ser expandibles y tipo Hot-Plug.

3.7 La memoria RAM debe ser del tipo DDR4 RDIMM, de 2400 MHz o superior.

Se debe ofertar el último modelo liberado en el mercado.

3.8 La memoria debe estar instalada y certificada de fábrica. No se permitirá la en-

trega de memoria genérica o no certificada por el fabricante.

3.9 Deberá estar equipado con una tarjeta de red con puertos duales 10GE que per-

mita virtualizar múltiples interfaces tipo NIC y HBA.

3.10 Deberá estar equipado con un expansor de la tarjeta de red con puertos duales

de 10GE de manera que cada blade cuente con al menos 20 GE de conexión a

cada bus de conexión interna del chasis.

3.11 Deberá soportar la inserción y remoción en caliente (hot-swap) de discos

duros.

3.12 Deberá soportar la conexión de teclado, pantalla y mouse de manera local

mediante un puerto frontal.

3.13 Deberá soportar el acceso remoto fuera de banda mediante una KVM remota y

el protocolo SSH.

3.14 Al momento de ser insertado en el gabinete para blades, deberá ser reconocido

automáticamente por el sistema de administración de cómputo.

3.15 Deberá ser capaz de asignar la menor cantidad de energía a los procesadores y

memoria conservando el nivel de desempeño requerido.

ESPHF-AD-010(5)


5

3.16 Deberá soportar en forma principal los siguientes sistemas operativos:

Microsoft Windows Server 2012 (y R2)

Microsoft Windows Server 2008 R2 SP1, x64 (incluyendo Hyper-V).

Citrix XenServer

VMware vSphere ESXi

Las nuevas versiones de Sistemas Operativos que vayan saliendo en el

periodo de la garantía y que cumplan con la matriz de compatibilidad

del fabricante

3.17 Deberá soportar los siguientes sistemas operativos de virtualización:

Microsoft Hyper-V en Windows Server 2008 R2, 2012 R2

VMWare VMWare vSphere 6, 5.5, 5.1 y 5

RHEL 5.4 con KVM y RHEV-H, así como versiones más nuevas

Oracle Linux y Oracle VM

Las nuevas versiones de Sistemas Operativos de Virtualización que va-

yan saliendo en el periodo de la garantía y que cumplan con la matriz de

compatibilidad del fabricante.

3.18 Incluir software de administración para cada uno de los servidores, así como

uno que permita su administración en forma centralizada.

3.19 Los servidores deben estar configurados para realizar el arranque (boot) desde

la SAN, por lo que no se solicitan discos en el propio servidor.

3.20 La solución de procesamiento, deberá contener mecanismos de

personalización para los Servidores Blade, de tal forma que en un evento de

falla y subsecuente reemplazo, el servidor de reemplazo pueda mantener la

“funcionalidad” y “personalidad” del servidor sustituido. Los parámetros de

personalización, deberán contemplar al menos los siguientes componentes de

firmware y/o software:

a. Conjunto de direcciones MAC

b. Conjunto de direcciones WWN

3.21 La solución ofertada deberá habilitar la administración de servidores blade,

gabinetes para servidores tipo blade, elementos de interconexión de red y

switches convergentes de acceso LAN y SAN, formando así un domino único

de administración altamente disponible.

3.22 Contar con una herramienta de administración para todos los blades ofertados,

sus gabinetes (con su respectivo par de elementos de interconexión de red) y

los 2 switches convergentes de acceso LAN y SAN.

3.23 Ofrecer una interfaz gráfica de usuario para realizar las tareas administrativas.

3.24 Ofrecer interfaces CLI, API XML y SNMP.

3.25 Manejar un esquema de alta disponibilidad.

ESPHF-AD-010(5)


6

3.26 Ser capaz de identificar de manera automática la adición, movimiento o

remoción de cualquier elemento al sistema, ya sean blades o gabinetes.

3.27 Permitir la configuración de umbrales ambientales para optimizar la

administración de los gabinetes.

3.28 Integrable con el sistema de administración de virtualización.

3.29 Ser capaz de abstraer la identidad completa de un servidor (incluyendo la

definición de la configuración completa de un servidor, que comprende la

dirección MAC y la dirección World-Wide Name (WWN) para la

conectividad de red SAN) para su posterior aplicación a cualquier blade del

sistema sin necesidad de realizar cambios en la configuración física.

3.30 Manejar acceso controlado basado en roles de administración.

3.31 Ser capaz de desplegar eventos con base a su severidad.

3.32 Manejar la instalación remota de sistemas operativos.

3.33 Permitir visualizar la configuración de los equipos que componen el sistema,

así como visualizar el detalle y los monitores del rendimiento de los

componentes críticos, tales como procesadores, memoria, fuentes de

alimentación, niveles de voltaje y ventiladores como mínimo.

3.34 Ser capaz de crear imágenes de inventario y reportes de cambios en el

hardware.

3.35 La configuración ofertada para cada equipo, deberá ser ensamblada por el

fabricante. Así mismo, el oferente deberá entregar una lista de los números de

serie del fabricante de todos y cada uno de los componentes tanto internos

como externos.

4. CHASIS (ENCLOSURE) PARA ALBERGAR SERVIDORES BLADE

4.1 Todos los servidores, deberán ser de tipo Blade, e insertarse en su propio

chasis que permita ofrecer recursos de comunicaciones, energía y

refrigeración de manera unificada y/o centralizada.

4.2 La solución deberá contar con al menos dos (2) chasis que hospeden el

conjunto de servidores blade, de tal manera que permitan ofrecer mecanismos

de redundancia física y lógica. Es muy importante aclarar que se desechará

cualquier propuesta que carezca de redundancia física en el módulo de chasis.

4.3 Los chasis ofertados para la solución propuesta, deberán contar con

mecanismos de comunicación, a través de enlaces de comunicaciones de al

menos 10 Gbps (Gigabits por segundo) en cada uno de sus enlaces, y deberá

manejar al menos 4 enlaces por cada uno de los módulos de interconexión

hacia el resto de la infraestructura.

ESPHF-AD-010(5)


7

4.4 La solución de conectividad de los chasis que hospedan los Servidores Blade,

deberán tener al menos DOS módulos de interconexión en esquema

redundante.

4.5 Los chasis propuestos deberán contar con mecanismos de redundancia n+1 ó

n+n en todos sus componentes activos, de tal manera que en un evento de falla

de cualquiera de sus componentes (por ejemplo, mecanismos de refrigeración,

energía eléctrica, comunicaciones, etc), la solución siga operando a través de

sus módulos redundantes. Se desechará cualquier propuesta que no cumpla

con los requerimientos de redundancia solicitados.

4.6 Los chasis para servidores blade deberán permitir la inserción en caliente de

los servidores, así como de fuentes de poder, ventiladores y elementos de

interconexión de red.

4.7 Los chasis propuestos y los elementos que los componen deberán participar en

el dominio único de administración del sistema de cómputo.

4.8 Se requieren chasis (enclosure) para servidores tipo blade con las siguientes

características mínimas:

a. Manejar un plano medio pasivo y un circuito de monitoreo ambiental

activo

b. Contar al menos con cuatro bahías para fuentes de poder con entrada

de energía en la parte posterior y fuentes de alimentación con

capacidad redundante a las que se debe tener acceso desde el panel

frontal

c. Contar al menos con ocho ventiladores intercambiables en caliente,

con el sistema activo.

d. Las fuentes de poder y ventiladores deberán ser insertados y

removidos en caliente sin necesidad de interrumpir el servicio.

e. Contar con dos ranuras para elementos de interconexión de red a las

que se debe tener acceso desde el panel posterior del gabinete.

f. Contar con ocho ranuras (como mínimo) para los servidores blade, a

las que se debe tener acceso desde el panel frontal

g. Ocupar 10 unidades de rack como máximo.

h. Aceptar la inserción en caliente de los servidores sin necesidad de

interrumpir el servicio.

i. Incluir el 100% de las fuentes que soporta.

j. Incluir el 100% de los ventiladores que soporta.

ESPHF-AD-010(5)


8

k. Estar equipados con todos los accesorios o equipamiento para soportar

la capacidad máxima de servidores, del tal forma que cuando sea

necesario agregar un nuevo servidor, no se requiere ningún

componente adicional además del nuevo servidor.

5. SE DEBE INCLUIR EL SOFTWARE DE ADMINISTRACIÓN PARA

APROVISIONAR Y MONITOREAR LA INFRAESTRUCTURA DE

SERVIDORES BLADES SOLICITADA.

5.1 Se debe incluir el software de administración para aprovisionar y monitorear la

infraestructura de servidores blades solicitada.

5.2 El software debe poseer una interface gráfica.

5.3 El software debe permitir utilizar todas sus funcionalidades en forma remota.

5.4 El software debe trabajar en forma independiente del sistema operativo

instalado en el servidor blade.

5.5 El software debe proveer gráficamente el control completo de la

infraestructura de servidores blades desde un sitio remoto.

5.6 El software debe realizar la administración y manejo de servidores Blades, tanto

del hardware como el sistema operativo y aplicaciones.

5.7 El software debe manejar el inventario de hardware y software, así como

proveer reportes del mismo.

5.8 El software debe incluir una herramienta que administre el consumo eléctrico

de la infraestructura de servidores blades, la cual deberá permitir:

a. Monitorear el consumo de energía del chasis.

b. Monitorear el consumo de energía de los servidores internos.

c. Configurar el máximo consumo de energía por servidor o chasis.

5.9 El software debe administrar la seguridad de acceso mediante una validación de

usuario y contraseña.

5.10 El software deberá tener la funcionalidad de acceso remoto compartido de al

menos tres usuarios concurrentemente independiente del sistema operativo.

5.11 El software deberá incluir el reporte de alertas de todos los dispositivos

integrado en la consola de administración.

5.12 El software debe realizar el encendido y apagado de los blades.

5.13 El software debe incluir una herramienta de administración del rendimiento, la

cual debe:

ESPHF-AD-010(5)


9

a. Proveer acceso detallado a problemas de fallas del sistema e

información de rendimiento.

b. Proveer notificación de eventos por medio de protocolo SMTP, ante

posibles fallas, estos deben poder enviarse a más de un destinatario.

c. Proveer notificación de eventos por medio de protocolo SNMP, ante

posibles fallas como respuesta a consultas del administrador sobre la

operación del sistema.

6. ELEMENTOS DE INTERCONEXIÓN DE RED INCLUIDO EN EL CHASIS

6.1 Los elementos de interconexión de red tendrán la tarea de comunicar a cada

chasis de blades con los switches convergentes LAN y SAN.

6.2 Cada chasis deberá manejar, como mínimo, dos elementos de interconexión.

6.3 Cada elemento de interconexión debe manejar las siguientes características

mínimas:

a. Deberá ser capaz de transportar el tráfico LAN y SAN mediante cuatro

enlaces integrados a 10GE hacia su respectivo switch convergente de

acceso LAN y SAN utilizando el estándar FCoE o deberá ser capaz de

transportar el tráfico LAN y SAN mediante seis enlaces integrados,

cuatro a 10GE hacia los switches de distribución y dos enlaces FC 8Gbs

hacia los switches fibra canal.

b. Los enlaces del chasis a los switches convergentes de acceso LAN y

SAN deben soportar conector a 10GE del tipo SR, LR y CU como

mínimo. LR o los enlaces del chasis a los enlaces directos a los switches

de distribución y switches fibra canal de acceso LAN y SAN deben

soportar conector a 10GE del tipo SR, LR y SFP para FC como mínimo.

c. Deberá manejar una tasa de envío de paquetes de 160 Gbps con baja

latencia.

d. Deberá manejar troncales de VLANs capa 2 y encapsulación IEEE

802.1Q.

e. Deberá manejar al menos 1024 segmentos virtuales de red LAN y SAN.

f. Deberá manejar 802.1p (CoS), encolamiento de salida basado en CoS,

encolamiento de prioridad estricta de salida, WRR.

g. Deberá manejar PFC y DCBX.

6.4 Cada chasis deberá incluir como mínimo, dos elementos de interconexión de

red con cuatro enlaces 10GE FCoE cada uno, el ancho de banda total hacia los

switches convergentes de acceso LAN y SAN deberá ser de 80 Gbps por chasis.

ESPHF-AD-010(5)


10

6.5 Los elementos de interconexión de red deberán participar en el dominio único

de administración del sistema.

7. SWITCHES CONVERGENTES DE ACCESO LAN Y SAN

7.1 Estos switches convergentes deberán consolidar la conectividad de red

proveniente de los elementos de interconexión de red de cada chasis mediante

enlaces de FCoE y 10 Gigabit Ethernet con velocidad de línea, baja latencia y

sin pérdidas.

7.2 Se deberán proponer al menos dos (2) switches convergentes de acceso LAN y

SAN; cada uno con las siguientes características mínimas:

a. Deberá incluir al menos 32 puertos 10 Gigabit Ethernet con factor de

forma pequeña enchufable mejorado (SFP+) FCoE.

b. El elemento de conectividad convergente podrá manejar en cualquiera

de sus puertos los siguientes protocolos: 10Gbps Ethernet, 1Gbps

Ethernet, Fibre Channel over Ethernet (FCoE), Fibre Channel nativo de

1/2/4/8 Gbps, conexión para NAS y iSCSI mediante el uso de puertos

unificados que requieran solamente del intercambio del SFP para

adaptar la funcionalidad bajo el concepto de “puertos unificados”.

c. Deberá ofrecer 6 puertos activos de Fibra Canal a 8 Gbps para la

conexión hacia la SAN con soporte de conectores SW y LW.

d. Deberá soportar el crecimiento a 16 puertos unificados adicionales.

e. Rendimiento de al menos 900 terabit por segundo (Tbps)

f. Deberá manejar cuatro (4) puertos de subida hacia los switches de

distribución LAN mediante enlaces 10GE con soporte de conectores SR,

LR y CU.

g. Deberá ser capaz de conectar a otro switch convergente de acceso LAN

y SAN para habilitar la alta disponibilidad.

h. El sistema deberá ser capaz de mantener una tabla de direcciones MAC

de hasta 32,000 entradas.

i. El sistema deberá ser capaz de proveer conectividad capa 2.

j. Deberá manejar troncales de VLANs capa 2 y encapsulación IEEE

802.1Q.

k. Deberá manejar 1024 segmentos virtuales de red LAN y SAN.

l. Deberá manejar 802.1s, 802.1w, PVRST+, IGMP v1, v2, v3, 802.3ad,

tramas de hasta 9000 bytes.

m. Deberá manejar 802.3x.

ESPHF-AD-010(5)


11

n. Deberá manejar 802.1p (CoS), encolamiento de salida basado en CoS,

encolamiento de prioridad estricta de salida, WRR.

o. Deberá manejar PFC y DCBX.

p. Ocho colas de prioridad basadas en hardware.

q. 802.1Qaz.

r. Deberá manejar redundancia en fuentes de poder y ventiladores.

s. Deberá manejar fuentes de poder y ventiladores redundantes insertables

y removibles en caliente (hot-swap).

7.3 Los switches de acceso convergentes LAN y SAN deberán participar en el

dominio único de administración del sistema.

8. SWITCHES DE DISTRIBUCIÓN

8.1 Los switches de distribución consolidarán los enlaces de comunicación de la

capa de acceso y la comunicarán con los switches para red local modular central

mediante enlaces a 10 Gigabit Ethernet con velocidad de línea, baja latencia y

sin pérdidas.

8.2 Se requieren al menos dos (2) switches de distribución; cada uno con las

siguientes características mínimas

8.3 Deberá manejar un desempeño de 900 Gbps.

8.4 Deberá contar con una capacidad de conmutación de paquetes en capa 2 de 700

Mpps (Millones de paquetes por segundo) como mínimo.

8.5 Deberá ofrecer 32 puertos 10GE.

8.6 Deberá soportar un crecimiento de 16 puertos adicionales para un total de 48

puertos.

8.7 Deberá soportar puertos FC a 2/4/8 Gbps mediante la adición de módulos de

puertos FC.

8.8 Deberá incorporar los puertos necesarios de FC a 2/4/8 Gbps e incluir los

módulos de FC para la interconexión con la SAN.

8.9 Deberá soportar conectores de 10GE LC, SR, LR y CU.

8.10 Deberá manejar, como mínimo, cuatro (4) puertos 10 GE hacia los switches

convergentes de acceso LAN y SAN y cuatro puertos ópticos multimodo con

TIPO SR conexión patch cord LC-LC de 10 GE hacia los switches de núcleo

LAN (SFP-10G-SR). Se debe incluir el conjunto completo de patch cord

dúplex, con conectores LC-LC, fibra óptica multimodo certificada para 10

GBPS para establecer la conexión hacia los switches de núcleo.

ESPHF-AD-010(5)


12

8.11 Deberá manejar un puerto de 100 Base-T para administración.

8.12 Todos los puertos deberán ofrecer desempeños a tasa completa (line-rate).

8.13 En conjunto los switches de distribución, deberán formar un arreglo de alta

disponibilidad.

8.14 Deberá permitir que los 32 puertos 10GE puedan manejar la velocidad de 1GE

como mínimo.

8.15 Los puertos de 10GE deberán permitir el uso del protocolo FCoE especificado

en el estándar INCITS T11 FC-BB-5.

8.16 El switch deberá permitir conectar FCoE a FC nativo simplificando el

cableado dentro del gabinete. Deberá ser capaz de conectarse a los siguientes

tipos de tarjetas de red:

a. NIC (Network Interface Card) para conectividad LAN

b. CNA (Converged Network Adapter) para conectividad de LAN y SAN

consolidada

8.17 Soporte de 1GE: 1000 BASE T, 1000 BASE SX, 1000 BASE LX

8.18 Soporte de 10GE: 10G BASE LC, 10G BASE LR, 10G BASE CU

8.19 El sistema operativo deberá contar con mecanismos de servicio continuo con

el objetivo de evitar interrupción ante operaciones de mantenimiento y

actualización de software.

8.20 Los switches de distribución deberán ser de la misma marca que los switches

convergentes de acceso LAN y SAN.

8.21 Deberán incluir fuentes de poder y módulos de ventilación en un esquema

redundante

8.22 El equipo deberá permitir la circulación del aire a través de este de la parte

frontal a la parte trasera.

8.23 Redundancia de alimentación 1:1 cumpliendo RoHS

8.24 Redundancia de ventilación N:1

8.25 Administración

a. Puerto dedicado 10/100/1000 para administración fuera de banda.

b. Administración dentro de banda.

c. LED para localización.

d. Soporte de SPAN en puertos físicos, VLANs y canales de puerto.

ESPHF-AD-010(5)


13

e. Soporte de SNMP v1, v2 y v3.

f. Control de acceso a la administración basado en roles.

g. Sincronización y restauración de configuraciones.

h. Manejo de AAA.

i. Syslog.

j. RMON.

k. Manejo de NTP.

l. Contadores de paquetes de entrada y salida por interface.

m. Acceso vía Telnet y SSHv2.

n. Encriptación AES para el tráfico de administración.

o. Manejo de RADIUS y TACAC+.

p. Manejo de SNMP v1, v2 y v3.

q. Soporte de XML.

r. Control de acceso a la administración basado en roles.

9. SISTEMA DE ALMACENAMIENTO UNIFICADO

9.1 Deberá ofrecer una solución de almacenamiento que soporte al menos tres tipos

de discos: Capa 1 (Tier 1), Capa 2 (Tier 2) y Capa 3 (Tier 3) mismas que se

distinguen por sus cualidades de capacidad de almacenamiento, así como los

niveles de desempeño medido en IOPS de cada uno de los discos. El

requerimiento deberá contener al menos la Capa 2 de discos. Los

requerimientos en capacidad de almacenamiento son en espacio crudo, donde

se incluye la capacidad de almacenamiento adicional necesaria (derivada del

overhead de la protección de los arreglos de discos) para poder ofertar las

volumetrías requeridas.

a. Almacenamiento en Capa 1 (TIER 1) Esta capa de almacenamiento

deberá ofrecer el almacenamiento total a través de tecnologías de muy

alto desempeño, mediante la implementación de discos de tipo de

Estado Sólido (SSD por sus siglas en inglés), o discos flash. Los discos

ofertados, deberán tener una capacidad de al menos 200 GBytes de

almacenamiento. Es muy importante aclarar que estas tecnologías no

podrán ser sustituidas por otras tecnologías de menor desempeño,

debido a que lograr estos niveles de desempeño ocasionaría un consumo

de energía y espacio físico significativamente mayor. Es un requisito

indispensable que la solución contenga discos con esta tecnología. En

esta capa de almacenamiento, se hospedarán los datos críticos que tienen

ESPHF-AD-010(5)


14

la mayor frecuencia de acceso por los aplicativos, y que por tanto, tienen

un mayor impacto en el desempeño de los Servicios.

b. Almacenamiento en capa 2 (TIER 2) Esta capa deberá ofrecer

tecnologías almacenamiento a través de discos físicos de al menos 600

GBytes, velocidad de 10,000 o 15,000 RPM, tipo SAS y con

comunicación de 12 Gbps en cada uno de ellos. El oferente no podrá

sustituir esta tecnología de almacenamiento por unidades de menor

desempeño o capacidad, debido a que esto ocasionaría un mayor

consumo de energía eléctrica y espacio físico en el Centro de Datos. Es

en esta capa de almacenamiento donde se hospedarán los datos de alta

frecuencia de acceso por los aplicativos.

c. Almacenamiento en capa 3 (TIER 3) Esta capa de almacenamiento

deberá ofrecer muy altas capacidades de almacenamiento en el menor

espacio posible. La solución ofertada deberá considerar que cada uno de

los discos de esta capa deberá ofrecer una capacidad de discos SATA o

SAS de 2 TB o superior. Evidentemente, en esta capa de

almacenamiento se hospedará la mayor cantidad de información y cuya

frecuencia de acceso es muy baja. Es muy importante aclarar que el

oferente no podrá sustituir las tecnologías de estos discos por otras de

menor capacidad, dado que incrementaría el espacio físico en el Centro

de Datos.

9.2 La oferta presentada deberá proponer una solución de almacenamiento

unificado multiprotocolo de última tecnología que deberá contar con

características de alta disponibilidad y desempeño que asegura la integridad y

disponibilidad de la información que soporte.

9.3 Una plataforma única de la misma marca que provea almacenamiento tipo SAN

y soporte NAS.

9.4 Sistema operativo y/o el micro código de la misma marca del equipo y

propietario del fabricante.

9.5 Deberá soportar conexión a través de los siguientes protocolos:

a. Fibra canal a 8 Gbps como mínimo

b. iSCSI a 1 Gbps y 10 Gbps

c. NFS v2, v3, CIFS, HTTP, FTP

d. Protocolo simple de administración de red (SNMP: simple network

management protocol)

e. Protocolo de resolución de direcciones (ARP: address resolution

protocol)

ESPHF-AD-010(5)


15

f. Protocolo de mensajes de control de internet (ICMP: internet control

message protocol)

g. Protocolo de hora en red (NTP: network time protocol)

h. Protocolo de hora de red simple (SNTP: simple network time protocol)

i. Autentificación kerberos

j. Protocolo ligeros de acceso a directorio (LDAP: lightweight directory

access protocol)

9.6 El sistema de almacenamiento deberá contar con mínimo 2 controladoras para

alta disponibilidad en el hardware.

9.7 Se requiere que las controladoras de disco realicen failover, de manera no

disruptiva.

9.8 El sistema de almacenamiento propuesto deberá de tener al menos 35 TB de

espacio crudo.

9.9 El equipo de almacenamiento propuesto deberá incluir los discos spare

necesarios para permitir una alta disponibilidad.

9.10 Deberá manejar discos al menos con las siguientes características:

a. Tecnología: discos y estado sólido, con interfaces de comunicación SAS

a 12 Gbps

b. Velocidades del dispositivo de lectura/escritura de 7200 rpm para Tier 3

y 10,000 rpm y 15,000 rpm para Tier 2.

c. Capacidad mínima de almacenamiento crudo total en discos Tier 2

(SAS) de 10,000 rpm para aplicaciones es de 32 TB.

d. Capacidad mínima de almacenamiento crudo total en discos Tier 2

(SAS) de 15,000 rpm para sistemas operativos de servidores (Boot over

SAN) es de 3 TB.

e. Incluir al menos cuatro (4) discos de 200 GB de estado sólido para

utilizar como cache, en modalidad mirror para un espacio utilizable de

caché asistido de 400 GB.

9.11 El equipo de almacenamiento debe de soportar las siguientes protecciones en

raid: 10/5/6

9.12 El equipo debe de contar por lo menos con 4 puertos de Fibra Canal (FC),

para conectividad hacia switches o servidores.

9.13 Deberá de ofrecer soporte a discos SAS de 3.5 y 2.5 pulgadas.

ESPHF-AD-010(5)


16

9.14 Capacidad de crecimiento del sistema al menos de 250 slots de disco en su

configuración ofertada.

9.15 El equipo propuesto deberá de ser escalable en sitio de manera no disruptiva.

9.16 Deberá de contar con al menos 48 GB de memoria caché nativa en cada

controladora dedicada a la SAN y a la NAS.

9.17 Las controladoras deben estar basadas en la arquitectura de múltiples cores

estándar de la industria Intel Xeon. Cada controladora debe tener al menos un

(1) procesador de esta arquitectura con al menos ocho (8) cores.

9.18 Deberá contar con la capacidad de utilizar discos de estado sólido en forma de

memoria caché para ampliar la misma hasta una capacidad máxima de 1.2 TB,

tanto para operaciones de lectura como de escritura hacia el almacenamiento.

9.19 Deberá de incluir la funcionalidad de distribuir automáticamente la

información en el tipo de disco más óptimo de acuerdo al comportamiento de la

misma, sin que dicha funcionalidad requiera de la intervención del

administrador, además de que deberá de alterar, de ser necesario, la distribución

de la misma información en caso de que el comportamiento de la misma se vea

alterado con el paso del tiempo.

9.20 Permitir el reemplazo y actualización de componentes en modo no disruptivo

incluyendo componentes como fuentes de poder, ventiladores, etc.

9.21 Poseer la capacidad combinada en una sola unidad de manejar conectividad

iSCSI y Fibra Canal (FC).

9.22 Deberá tener al menos dos controladoras de almacenamiento para

redundancia.

9.23 Deberá de contar con controladoras que provean de forma simultanea

almacenamiento SAN y NAS.

9.24 Fuentes de poder y ventiladores redundantes para controladoras.

9.25 Incluir la Suite de software de administración vía web del sistema que su

permita configuración (accesible a través de cualquier navegador web con

soporte HTML5), así como la administración de la información a través de una

interfaz gráfica (GUI).

9.26 El equipo deberá incluir el licenciamiento de software que permita la

administración del proceso de replicación síncrono y/o asíncrono.

9.27 Deberá soportar upgrade en línea del microcódigo o software de

almacenamiento y/o sistema operativo,

9.28 Además el sistema debe brindar las siguientes funcionalidades:

ESPHF-AD-010(5)


17

a. Agrupación de recursos de almacenamiento. La solución de

almacenamiento del oferente deberá ofrecer mecanismos de agrupación

de arreglos de discos en áreas comunes, mismas que deberán ser

independientes y aisladas a otros grupos de discos. Cada grupo de

recursos de almacenamiento podrá contener discos que pertenecen a las

tres capas (Tiers de Almacenamiento) requeridas en estos Términos de

Referencia, tal como se describen en la sección “Tecnologías de

Almacenamiento”. El conjunto total de arreglos de discos contenidos en

cada Grupo de Recursos, deberá ofrecerse como un repositorio

unificado de almacenamiento accesible por los servidores de

virtualización.

b. Reubicación automatizada de la información. Cada uno de los Grupos

de Arreglos de Discos deberá ofrecer la posibilidad de hospedar y

reubicar los datos almacenados en este, en las distintas capas de

almacenamiento (Tier) de manera automatizada y transparente. Esta

funcionalidad permitirá hospedar los datos con mayor frecuencia de

acceso, en las capas de almacenamiento de mayor desempeño, mientras

que re-ubica de manera automática aquellos datos cuya frecuencia de

acceso es menor. El oferente deberá ofrecer documentación detallada

que explique los mecanismos que permiten hacer el manejo

automatizado de re-ubicación de datos entre las capas.

c. Mecanismos de protección de datos en el almacenamiento. Dada la

criticidad de la información administrada por la Institución, es de

particular importancia contar con mecanismos de protección de la

información en la solución de almacenamiento. El oferente deberá

considerar que todos los datos almacenados en los grupos de arreglos de

discos, deberán tener mecanismos de protección denominada RAID,

permitiendo así la falla en uno de los discos de cada uno de los arreglos,

sin resultar esto en pérdida de información o servicios.

d. Cifrado de datos a nivel de los discos.

e. Sobresuscripción de los recursos de almacenamiento. El oferente deberá

ofrecer tecnologías de Sobresuscripción del Almacenamiento, mismo

que permitan a la Solución de Almacenamiento ofrecer Unidades de

Almacenamiento (LUNs) a los Servidores, cuya suma total sea superior

al total de almacenamiento contenido en cada Grupo de Arreglos de

Discos. La definición de cada Unidad de Almacenamiento se definirá

por ESPH en conjunto con el adjudicatario en las etapas de

configuración de la solución para su puesta en marcha.

f. Elementos de optimización de tiempos de respuesta en escrituras y

lecturas. La solución de almacenamiento propuesta por el oferente,

deberá contener mecanismos de aceleración de respuesta de escritura y

lectura, a través de espacios de memoria conocidos como cache. La

ESPHF-AD-010(5)


18

solución deberá contener al menos 400 GBytes de memoria “cache”

para soportar ráfagas de escritura o lectura en los horarios picos de los

Servicios de Operación, incrementando así el desempeño total de la

solución. El oferente podrá ofrecer una solución de memoria cache en

tecnologías RAM o en tecnologías de estado sólido.

g. Optimización de la ubicación de la información en las capas de

almacenamiento. La solución de almacenamiento, deberá contener

mecanismos de administración del hospedaje de los datos en capas, que

permita la ubicación y re-ubicación de los datos hospedados en las

distintas Capas de Almacenamiento, de una manera dinámica y

automática. La tecnología deberá seleccionar y discriminar las distintas

porciones de los datos hospedados en todo el Grupo de Arreglos de

Discos, y ubicar cada porción de datos en la Capa de Almacenamiento

que más convenga, derivado de las estadísticas de utilización que tenga

cada porción. Los datos que tengan la mayor frecuencia de acceso, de

acuerdo a las estadísticas generadas por la aplicación misma, deberán

hospedarse en la Capa de Almacenamiento 1, de tal forma que su

desempeño sea el más alto, y ofreciendo así mejores tiempos de

respuesta a los aplicativos que hacen uso de las porciones de datos en

cuestión. De igual forma, la solución deberá clasificar y reubicar el resto

de la información en las capas 2 y 3, con la misma filosofía aquí

descrita.

h. La reubicación de los datos deberá hacerse de manera automatizada y

sin requerir intervención de los administradores/operadores de la

plataforma o con opción de modo asistido. Deberá ofrecer

documentación que muestre de manera clara y precisa el funcionamiento

de la solución propuesta de este requerimiento de ESPH.

i. Es muy importante aclarar que el mecanismo de reubicación de

información automatizado, deberá estar en operación en todo momento

durante la vida útil del equipo, y la operación del mecanismo asistido

deberá ser no-disruptivo, permitiendo los movimientos de datos

requeridos, sin impactar a los aplicativos de manera perceptible por el

usuario final. Los movimientos de la información deberán hacerse sin

requerir de una Ventana de Mantenimiento en la operación de los

Servicios.

10. SOFTWARE DE ADMINISTRACIÓN DEL ALMACENAMIENTO

10.1 Software con licenciamiento ilimitado, propio para SAN que tenga la

capacidad de realizar copias lógicas y copias virtuales o clones.

10.2 El software deberá proveer una interfaz gráfica, basada en web (basado en

HTML5 accesible por cualquier navegador web que soporte este protocolo),

para crear, administrar y configurar las copias locales.

ESPHF-AD-010(5)


19

10.3 Habilidad para crear, modificar y borrar las copias.

10.4 Capacidad de recuperación instantánea de una copia a un volumen con el

mismo tamaño.

10.5 Capacidad de copiar datos de producción para poder montarlos en otro

servidor por ejemplo un ambiente de pruebas.

10.6 Capacidad para montar las copias en un host disponible.

11. SOFTWARE DE BALANCEO DE CARGAS Y FAILOVER EN SAN

11.1 Utilizar múltiples paths para distribuir la carga de modo balanceado.

11.2 Utilizar dos o más paths de datos de manera simultánea para operaciones de

lectura y escritura.

11.3 Comprobar mediante documentación que realiza una mejora en el rendimiento

mediante el uso de múltiples paths.

11.4 Trasladar el I/O de paths más cargados hacia los de menor carga.

11.5 Tener detección automática de fallas de paths o rutas de I/O.

11.6 Redistribuir la carga del path en falla, hacia los paths restantes.

11.7 Deberá tener la capacidad de detectar de manera automática paths en falla y

de igual manera en forma automática restablecer el path cuando la falla haya

sido reparada.

11.8 Soportar drivers de HBA tanto comunes como nativos.

11.9 Deberá tener la capacidad para funcionar con máquinas virtuales.

11.10 Deberá tener la capacidad de trabajar con ambientes Microsoft Hyper-V,

VMWare ESXi Server.

11.11 Deberá mantener de manera automática el rendimiento general de I/O para

ambientes ESXi.

11.12 Deberá soportar los siguientes sistemas operativos y las versiones que surjan

durante la vigencia de la garantía: Windows, Linux, Solaris, AIX y HP-UX.

12. SISTEMA DE MONITOREO DE INFRAESTRUCTURA DE

ALMACENAMIENTO

12.1 Deberá proporcionar un sistema de monitoreo remoto con ejecución de

diagnósticos periódicos.

12.2 Deberá contar con un sistema de autentificación de usuarios para el acceso a

la consola de administración (local y remoto).

ESPHF-AD-010(5)


20

12.3 Deberá contar con un mecanismo de auto monitoreo interno las 24 horas del

día. El monitoreo debe ser pro-activo y deberá proveer la facilidad de reportar

automáticamente las fallas o cambios en la configuración a un centro de

monitoreo remoto.

12.4 Deberá permitir el diagnóstico remoto con la posibilidad de que el centro de

soporte tome el control de la consola para un diagnóstico más oportuno del

sistema.

12.5 Permitir el control y manejo de alertas en forma proactiva.

12.6 Debe mostrar el comportamiento de todos los componentes físicos de la

unidad (discos, canales, ventiladores, etc.).

12.7 Deberá contar con una línea de comandos que permita obtener información y

administrar en su totalidad (generación de LUNs, asignación de LUNs a

servidores, etc.) la unidad de almacenamiento.

13. SISTEMA DE RESPALDO A DISCO CON DEDUPLICACIÓN EN LÍNEA

13.1 El sistema de almacenamiento de respaldo debe permitir conectividad con

tecnologías vía LAN con conexiones de cobre a 1 Gbps y ópticas de 10 Gbps.

13.2 El sistema de almacenamiento de respaldo debe ser 100% compatible con las

siguientes herramientas de respaldo: EMC Networker y Avamar, IBM TSM,

Veritas Netbackup y BackupExec, Sympana Commvault, entre otros.

13.3 El sistema de almacenamiento de respaldo debe ser compatible con protocolos

de conectividad IP (CIFS, NFS), FC, OST (Open Storage Tape).

13.4 El sistema de almacenamiento de respaldo debe manejar el proceso de

deduplicación de datos de manera nativa sin requerir componentes

adicionales.

13.5 El sistema de almacenamiento de respaldo debe tener la capacidad de hacer la

ingesta de datos deduplicados y encriptados antes de ser escritos en disco con

el fin de garantizar la deduplicación en línea.

13.6 El sistema de almacenamiento de respaldo debe ser compatible con protocolos

de conectividad el cual permitan la utilización de procesos de segmentación

de datos distribuidos para garantizar ventanas de respaldos más cortas.

13.7 El sistema de almacenamiento de respaldo debe ser por diseño una solución

dedicada y diseñada exclusivamente para tareas de respaldo y recuperación de

datos. Caen fuera de esta definición/requerimiento las configuraciones

conformadas por arreglos de discos vía SAN/NAS conectados a soluciones de

conversión para respaldo tipo “Appliance” o “Gateway”, entre otros.

ESPHF-AD-010(5)


21

13.8 El sistema de almacenamiento de respaldo debe tener la capacidad de hacer

réplicas de datos deduplicados de forma simultánea y bidireccional mediante

enlaces IP-WAN.

13.9 El sistema de almacenamiento de respaldos debe estar basado en un arreglo

de discos SATA (Serial ATA) que soporte tecnologías de discos de 2TB y 3

TB con protección RAID 6.

13.10 El sistema de almacenamiento de respaldos debe tener al menos dos discos

hotspare en cada bandeja de discos que funcionen de manera global dentro de

todo el equipo.

13.11 El sistema de almacenamiento de respaldos debe garantizar un rendimiento

centrado en el CPU del equipo y minimizar la utilización de disco para

rendimiento.

13.12 El sistema de almacenamiento de respaldos debe contar con una capacidad de

36 TB Raw (24 TB usables) deduplicados en línea con opción a crecimiento

en el mismo sistema.

13.13 El sistema de almacenamiento de respaldos debe contar con tecnologías de

deduplicación de datos IN LINE o “en línea”, es decir, que los datos sean

deduplicados antes de ser almacenados en el disco.

13.14 El proceso de deduplicación se debe llevar a cabo mediante el uso de ciclos de

CPU del mismo equipo y no utilizar ciclos de CPU de los servidores.

13.15 El proceso de deduplicación deberá poder distribuirse en el origen y en el

destino a través de los protocolos Ethernet y Fibra Canal (FC).

13.16 El sistema de almacenamiento de respaldo debe tener la capacidad de manejar

períodos de retención que van de meses a años.

13.17 El sistema de almacenamiento de respaldos puede ser utilizado como

repositorio único de respaldos con retenciones a corto plazo y largo plazo así

como para soluciones de archivado de datos deduplicados.

13.18 El sistema de almacenamiento de respaldos debe permitir los siguientes tipos

de conexiones:

a. Tarjetas Cobre 1Gbps (1Gigabit Ethernet) - Quad Port (Debe venir

incluida como una tarjeta de expansión o integrada al sistema)

b. Tarjetas Ópticas 10Gbps (10Gigabit Ethernet) - Dual Port (Debe

venir incluida como una tarjeta de expansión o integrada al sistema)

c. Tarjetas de Fibra 4 y 8 Gbps (Fiber Channel) – Dual Port

(implementación a futuro)

ESPHF-AD-010(5)


22

13.19 El sistema de almacenamiento de respaldos debe contar con la capacidad de

realizar funciones de Replicación, Cifrado, Retention Lock, y OST.

13.20 El sistema de almacenamiento de respaldos debe contar con el protocolo de

conectividad OST para plataformas de respaldos existentes en el mercado

(Networker, Netbackup).

13.21 El sistema de almacenamiento de respaldos debe soportar niveles de

deduplicación entre 10x y 30x, dependiendo del tipo de dato respaldado.

13.22 El sistema de almacenamiento de respaldos debe soportar cualquiera de los

siguientes sistema operativos de 32/64bits, tales como: Windows Server

2008/2012 o superiores, Linux Red Hat, Linux SuSE, IBM AIX, HP-UX, Sun

Solaris.

13.23 El sistema de almacenamiento de respaldos debe tener la capacidad de

crecimiento mediante la incorporación de bandejas de discos adicionales.

13.24 El sistema de almacenamiento de respaldos debe tener la capacidad de

crecimiento vertical.

13.25 El sistema de almacenamiento debe alcanzar capacidades de almacenamiento

usable de al menos 120TB.

13.26 El sistema de almacenamiento de respaldos debe contar con fuentes

redundantes tipo Hot Swap.

13.27 El sistema de almacenamiento de respaldos debe contar con ventiladores

redundantes.

13.28 El sistema de almacenamiento de respaldos no debe requerir de espacio en

disco temporal o adicional (staging o cache) para realizar la operación de

deduplicación, es decir, los datos que se reciben son deduplicados por el CPU

del equipo y escritos directamente al almacenamiento del equipo.

13.29 El sistema de almacenamiento de respaldos debe soportar tasas de

transferencia con deduplicación en línea de hasta 13 TB/hr mediante

protocolos de conectividad el cual permitan la utilización de procesos de

segmentacion de datos distribuidos (LAN 10 Gbps) y 5 TB/hr con el resto de

protocolos.

13.30 El sistema de almacenamiento de respaldos debe soportar la funcionalidad de

replicación de datos entre dos o más sitios a través de la red de comunicación

WAN permitiendo establecer un plan de desastres al sitio alterno.

13.31 La funcionalidad de replicación del sistema de almacenamiento de respaldo

debe permitir:

ESPHF-AD-010(5)


23

a. Replicar los datos en forma de-duplicada, es decir, solo se transfieren

datos únicos y la meta-data con los punteros de los datos que están

duplicados.

b. Puede ser de tipo espejo y por directorios Bi-direccional, es decir de

un appliance local a otro appliance remoto y viceversa.

c. La replicación selectiva a nivel directorio, es decir la posibilidad de

seleccionar uno o más directorios y ser replicados al appliance remoto.

d. Replicación de tipo cascada, es decir una: sitio principal >> 1er. sitio

DR >> 2do. Sitio DR.

e. 1-1, 1-N, N-N

f. La replicación deberá ocurrir de manera concurrente durante la

ventana de respaldo, permitiendo así que los datos estén replicados en

el sitio al término del proceso de respaldo.

g. Contar con los siguientes modos de operación: modo de suspensión,

modo programado y modo de manipulación de ancho de banda para

optimización del tráfico

h. El sistema de almacenamiento de respaldos debe incorporar la

herramienta de respaldos que le permita operar considerándose una

solución completa

13.32 La herramienta de respaldo debe estar contenida en una solución tipo

appliance separada del sistema de respaldo a disco, la cual debe tener

capacidad interna de almacenamiento para los meta-datos de la solución.

13.33 La herramienta de despaldo debe soportar deduplicación distribuida entre

origen y destino, a fin de optimizar el ancho de banda entre los clientes, la

herramienta de respaldo y el sistema de respaldo a disco.

13.34 Tanto el sistema de respaldo a disco como la herramienta de respaldo deben

aplicar un algoritmo de deduplicación basado en segmentos de tamaño

variable, a fin de aumentar la tasa de deduplicación de los datos.

13.35 Sobre ambientes virtualizados, la herramienta de respaldo debe ser capaz de

respaldar tanto las imágenes de las máquinas virtuales como el contenido de

estas dentro del sistema operativo “guest” dentro de cada máquina.

13.36 Sobre ambientes virtualizados, tanto la herramienta de respaldo como el

sistema de respaldo a disco deben permitir, en caso de pérdida de una máquina

virtual, el acceso e inicio de esta de forma instantánea desde el sistema de

respaldo a disco, reduciendo el tiempo de recuperación (RTO) a su mínima

expresión sin necesidad de pasar por un proceso previo de restauración.

Posteriormente, mediante los mecanismos propios de movilidad del

ESPHF-AD-010(5)


24

virtualizador, la imagen completa de la máquina virtual se pueden reubicar en

su ubicación definitiva dentro del almacenamiento primario.

13.37 La herramienta de respaldo debe proporcionar una solución de deduplicación

de software y hardware completo que facilite los respaldos diarios completos

y rápidos para entornos virtuales, oficinas remotas, aplicaciones empresariales

(NAS) servidores conectados a la red de almacenamiento y equipos de PC,

Laptops, Portátiles.

13.38 La herramienta de respaldo debe contar con un algoritmo de deduplicación

con segmentos de datos de longitud variable para la eficiencia y el ahorro

óptimo, al igual que el sistema de respaldo a disco.

13.39 La herramienta de respaldo debe proporcionar eficientes full backups diarios y

rápidos.

13.40 La herramienta de respaldo deberá proporcionar automáticamente

comprobaciones de integridad del servidor de respaldo diaria.

13.41 La herramienta de respaldo deberá proporcionar automáticamente la

verificación diaria, sin intervención humana, de que los datos respaldados son

totalmente recuperables.

13.42 La herramienta de respaldo deberá realizar el respaldo y recuperación de la

solución de almacenamiento de datos no estructurados solicitada en el

presente cartel, empleando para tal fin el protocolo NDMP. La herramienta de

respaldo deberá contar con todos los elementos de hardware y software

necesarios para optimizar y acelerar los procesos de respaldo y recuperación

realizados a través del protocolo NDMP.

13.43 La herramienta de respaldo debe permitir definir de forma granular el

conjunto de datos a ser respaldados en una sesión de respaldos, ya sea un

grupo de archivos, sistemas de archivos completos, datos de aplicaciones

(como bases de datos) o la configuración de los sistemas operativos.

13.44 La herramienta de respaldo debe realizar verificaciones de los respaldos,

comprobando que los tipos de archivos, fechas y tiempos de modificación,

tamaño y contenido de los archivos guardados sean los correctos. Si el

software de respaldos detecta algún cambio, debe alertar dicha condición al

usuario, así como si algún respaldo no fue completado exitosamente.

13.45 La herramienta de respaldo debe permitir la ejecución de respaldos completos

sintéticos (Synthetic Full Backups), que permitan combinar un respaldo

completo ya existente con respaldos incrementales subsecuentes, para

conformar un nuevo respaldo completo. Esto con el objetivo de reducir la

ventana de respaldo, los tiempos de recuperación y el tratico de información a

respaldar en la red.

ESPHF-AD-010(5)


25

13.46 La herramienta de respaldo debe permitir la ejecución de respaldos basado en

eventos definidos por el usuario que ocurran en los clientes, así como eventos

basados en tiempo.

13.47 La herramienta de respaldo debe permitir la encriptación de 256bits de los

datos de los respaldos, basado en una frase definida por el usuario.

13.48 La herramienta de respaldo debe permitir la compresión de los datos de los

respaldos permitiendo reducir el tráfico en la red.

13.49 Se debe incorporar el licenciamiento por capacidad para al menos 2 TB.

13.50 La solución debe incluir las licencias de software necesarias para aumentar en

forma significativa el rendimiento de los respaldos, mediante la distribución

de parte del proceso de deduplicación al servidor de respaldo o a los clientes

de aplicaciones.

13.51 Se debe incluir todo el licenciamiento requerido para brindar el servicio de

respaldo a todos los clientes (usuarios o equipo).

13.52 La propuesta debe incluir todos los elementos de Hardware y Software

necesarios para el correcto funcionamiento de la solución.

13.53 La solución ofertada debe contemplar el licenciamiento de un software de

monitoreo y análisis, que sea capaz de analizar, alertar y reportar sobre el

funcionamiento y comportamiento de los diferentes componentes que

conforman la solución ofertada.

13.54 El software de monitoreo y análisis debe proveer una vista unificada del

estado de la protección de los datos.

13.55 El software de monitoreo y análisis debe recolectar información de múltiples

fuentes, para el usuario.

13.56 El software de monitoreo y análisis debe proveer un resumen consolidado de

la infraestructura de respaldos, así como brindar información sabré tendencias

y pronósticos del estado de protección de los datos.

13.57 El software de monitoreo y análisis debe brindar información granular

mediante resúmenes, reportes y alertas que permitan a los usuarios identificar,

investigar y resolver rápidamente problemas relacionados con la protección de

los datos.

13.58 El software de monitoreo y análisis debe ser cien por ciento (100%)

compatible con la herramienta de respaldo y el sistema de respaldo a disco

ofertados y debe ser del mismo fabricante de la solución ofertada en el

presente cartel, para garantizar el optima funcionamiento de la solución.

13.59 El software de monitoreo y análisis debe ser compatible con los sistemas

operativos Windows 2008 R2 y Windows 2012 R2.

ESPHF-AD-010(5)


26

13.60 El software de monitoreo y análisis debe soportar recolectar datos de un

amplio rango de infraestructura para protección de datos incluyendo:

a. Servidores de respaldos de fabricantes como Symantec, IBM e EMC,

garantizando cien par ciento (100%) de compatibilidad con el

software de respaldos ofrecido, pero no limitado a este software.

b. Unidades de cintas de los fabricantes IBM, HP, Quantum y Oracle

StorageTek.

c. Switches de fibra canal de los fabricantes Cisco y Brocade

d. Sistemas Operativos Windows, RHEL, SUSE Linux.

e. Bases de datos Oracle y Microsoft SQL Server.

13.61 El software de monitoreo y análisis debe permitir a los usuarios crear políticas

de análisis que generen de forma automática alertas de correo o SNMP,

cuando se cumplan las reglas definidas en la política.

13.62 El software de monitoreo y análisis debe soportar políticas basadas en

eventos, en respuesta a datos recolectados en tiempo real.

13.63 El software de monitoreo y análisis debe soportar políticas basadas en tiempo,

permitiendo definir horarios en los que la data es analizada para determinar si

amerita detonar una alerta.

13.64 El software de monitoreo y análisis debe soportar políticas basadas en reglas

relacionadas a la protección de los datos, cambios en la configuración,

planificación de la capacidad, recuperación y desempeño.

13.65 El software de monitoreo y análisis debe poder alertar situaciones como:

a. Trabajos de respaldo que no se completaron exitosamente.

b. Si se estima que el espacio del almacenamiento se agotara en un

periodo determinado de tiempo

13.66 El software de monitoreo y análisis debe permitir ejecutar reportes en

demanda, así como enviar por correo reportes que se ejecutan de forma

automática en horarios definidos.

13.67 El software de monitoreo y análisis debe proveer una amplia variedad de

reportes pre-configurados capaces de brindar información de resumen y/o

detalle. Además debe permitir la creaci6n de reportes personalizados por el

usuario.

13.68 El software de monitoreo y análisis debe permitir el análisis de tendencias de

utilizaci6n de capacidad de los recursos monitoreados.

ESPHF-AD-010(5)


27

13.69 El software de monitoreo y análisis debe soportar una arquitectura flexible

y escalable basada en nodos de recolección, que permita incrementar el

número de nodos basado en la cantidad de recursos monitoreados.

13.70 El software de monitoreo y análisis debe soportar una interfaz web

intuitiva (accesible desde un navegador web), personalizable para cada

usuario.

13.71 El software de monitoreo y análisis debe permitir monitorear

infraestructuras virtuales, asegurando que todas las máquinas virtuales se

encuentren protegidas, incluso si estas son migradas entre servidores dentro de

un clúster VMware

13.72 El software de monitoreo y análisis debe proveer un API basado en los

protocolos HTTPS/XML, para que aplicaciones de terceros puedan acceder a

las funciones del software.

13.73 La propuesta debe incluir todos los servicios de instalación y soporte

necesarios para poner en marcha y brindar mantenimiento efectivo de la

solución.

13.74 Debido a la naturaleza crítica de estos equipos y los equipos a ser respaldados,

la instalación debe ser realizada por un ingeniero o técnico directo del

fabricante que esté certificado para realizar este tipo de instalaciones. Se debe

adjuntar carta del fabricante que haga constar lo anterior.

13.75 La implementación se realizará de acuerdo a las mejores prácticas de

seguridad y eficacia, siguiendo las normativas de instalación de ESPH.

14. SOFTWARE DE VIRTUALIZACIÓN VMWARE

14.1 El software de virtualización deberá basarse en un Sistema operativo para

virtualizar (hypervisor) que ejerza el control del hardware sin requerir la

asistencia de un sistema operativo anfitrión.

14.2 El software de virtualización deberá ser VMware vSphere 6.0 Enterprise Plus

con Operations Management o superior, para cumplir con la normativa

institucional.

14.3 El componente básico del cómputo virtual deberá ser un hipervisor instalable

en forma directa sobre un servidor físico para habilitar la creación y ejecución

simultánea de múltiples máquinas virtuales sobre dicho servidor físico.

14.4 Se deberán ofertar las licencias de software de virtualización basados en el

número de CPU físicos o sockets. En el caso de este cartel de debe ofertar el

licenciamiento para ocho (8) procesadores físicos o sockets.

14.5 El software de virtualización deberá trabajar bajo arquitectura de procesadores

tipo x86/x64.

ESPHF-AD-010(5)


28

14.6 El software de virtualización deberá poder crear máquinas virtuales que

soporten los siguientes sistemas operativos y las versiones que surjan durante

la vigencia de la garantía:

a. Windows Server 2003, 2008, 2012 (Standard y Enterprise) R2 o

superior a 32 y 64 bits.

b. Linux Red Hat Enterprise versiones 3, 4, 5 y 6

c. Linux SUSE Linux Enterprise Server 8, 9, 10 y 11

14.7 La capa de virtualización deberá poder otorgar 128 CPUs virtuales a una sola

máquina virtual y proporcionar a la vez capacidades de multiprocesamiento

simétrico (SMP) entre dichos CPUs virtuales. Así mismo, deberá ser capaz de

entregar máquinas virtuales hasta con 4 TB de RAM.

14.8 La capa de virtualización deberá ser capaz de funcionar en servidores físicos

de hasta 480 núcleos de procesamiento lógicos (cores) y hasta 6TB de

memoria RAM.

14.9 La capa de virtualización deberá eliminar la necesidad de detener el servicio

de las aplicaciones para poder realizar mantenimiento de los servidores

físicos. Para lograr esto es necesario que sea posible dar la orden de

evacuación de un servidor físico para que las máquinas virtuales (y las

aplicaciones que estas sustentan) empiecen a migrarse en línea a otros

servidores. El orden de las migraciones y la selección del servidor físico

destino deberá ser determinado por un proceso automatizado que permita

hacer la evacuación en forma sistemática de forma que no haya impacto en el

desempeño de las aplicaciones en ejecución en los servidores físicos

encargados de captar las máquinas virtuales que se están evacuando.

14.10 La capa de virtualización deberá contar con la capacidad de permitir el

mantenimiento o sustitución del medio de almacenamiento en disco donde

residen los archivos de los sistemas operativos, aplicaciones y datos que cada

máquina virtual utiliza sin que haya interrupción en el funcionamiento de las

máquinas virtuales.

14.11 Para el caso donde exista una falla en un elemento físico de procesamiento

(servidor) que le impida continuar con la ejecución de máquinas virtuales, la

capa de virtualización deberá detectar la pérdida de los signos vitales del

elemento físico en cuestión y poner las máquinas virtuales afectadas

nuevamente en ejecución sobre otros servidores físicos distribuyéndolas en

forma automática de forma que la carga de trabajo sea dividida

equilibradamente entre los servidores físicos que sigan funcionando

correctamente.

14.12 El software de virtualización deberá ser capaz de crear un switch Ethernet

lógico distribuido, de tal manera que la configuración aplicada a éste se

distribuya y aplique a las máquinas virtuales de todos los servidores físicos.

ESPHF-AD-010(5)


29

14.13 El software de virtualización deberá estar certificado para soportar switches

virtuales.

15. CAPA DE ACCESO VIRTUAL A LA RED DEL CENTRO DE DATOS

15.1 Características del switch virtual que deberá estar incluido en la misma

licencia que el software de virtualización.

15.2 Brindar la capacidad de agregar consistencia en la administración y las

políticas de seguridad y calidad de servicio para cualquier aplicativo en la red.

15.3 Con la finalidad de mantener la consistencia de políticas, administración y la

capacidad de tener visibilidad del tráfico de aplicativos no importando si la

aplicación se encuentra montada en un servidor físico o en un servidor virtual,

se requiere un componente de software que permita el control de los puertos

virtuales de los servidores virtuales.

15.4 La solución deberá ser un switch en software que permita administrar los

puertos virtuales de manera consistente y de la misma forma en que se

aprovisiona un puerto físico en el centro de datos.

15.5 La solución deberá componerse de un módulo de Ethernet virtual y un módulo

de supervisión virtual de los puertos virtuales.

15.6 El módulo de Ethernet virtual permite desempeñar las siguientes funciones

avanzadas de switcheo:

a. Calidad de servicio (QoS)

b. Seguridad: private VLAN, listas de control de acceso (ACL), firewalls

virtuales

c. Monitoreo: netflow, span, erspan (Encapsulated Remote Switched Port

Analyzer)

15.7 Con la finalidad de brindar mayores capacidades de red a los puertos virtuales

de red de las máquinas virtuales, el módulo de Ethernet virtual deberá operar

como parte íntegra del kernel del sistema operativo de virtualización.

15.8 Es un requerimiento que se incluya redundancia del punto de control y gestión

de los puertos virtuales. Los puertos virtuales Deberá tener la capacidad de

seguir operando y hacer switching del tráfico basado en la última

configuración realizada aún en caso de un evento en el que se pierda la

comunicación con el módulo de supervisión virtual.

15.9 El módulo de supervisión virtual es el componente de la arquitectura de

switcheo virtual que permite la configuración, operación, administración y

control de todos módulos de Ethernet virtuales (puertos virtuales).

ESPHF-AD-010(5)


30

15.10 Para tener un modelo operacional más eficiente y al mismo tiempo mantener

la independencia entre los equipos de telecomunicaciones y los

administradores de aplicaciones y servidores al aprovisionar una aplicación, es

requisito que el switch en software soporte la creación de perfiles de puertos.

De esta forma, se pueden crear un cierto número de perfiles (por ejemplo: 1.

Puerto de servidor web, 2. Puerto de servidor de aplicaciones, 3. Puerto de

servidor de correo, 4. Puerto de servidor de bases de datos) y los responsables

de aplicaciones asignar el perfil de puerto a la aplicación virtual desde el

mismo sistema de aprovisionamiento de máquinas virtuales.

15.11 El sistema deberá ser capaz de soportar por módulo de supervisión virtual:

a. Hasta 64 servidores físicos

b. 512 VLANs activas

c. 32 interfaces físicas por cada servidor

15.12 Funcionalidades de Administración, Monitoreo y Alta disponibilidad. Deberá

manejar:

a. Switcheo en capa 2

b. Encapsulación de VLANs – IEEE 802.1Q

c. Multicast mediante el uso de los protocolos IGMPv2 e IGMPv3

d. Soporte de agregación de puertos físicos de varias tarjetas de red en un

solo puerto lógico

e. Soporte de terminación de un canal de puertos de las tarjetas de red a

switches distintos

f. Soporte de Link Aggregation Control Protocol (LACP)

g. Algoritmos de balanceo:

i. Identificación de puerto virtual

ii. Dirección MAC fuente

iii. Dirección MAC fuente y destino

iv. Puerto IP fuente y destino

h. Limitación de ancho de banda utilizado tanto en la transmisión como

en la recepción del tráfico hacia y desde la máquina virtual (rate

limiting)

i. Marcado de paquetes de calidad de servicio (por puerto virtual):

ESPHF-AD-010(5)


31

i. DSCP

ii. ToS

iii. CoS

j. Seguridad de puerto

k. VLANs privadas

l. Listas de control de acceso

m. Firewalls virtuales

n. Inspección dinámica de protocolo ARP

15.13 Deberá soportar las siguientes funciones y protocolos de switches:

a. Administración mediante el uso de la herramienta de gestión propia

del fabricante de software de virtualización de máquinas.

b. APIs para integración con herramientas de terceros

c. Capacidad de tener port mirroring de puertos virtuales para análisis de

tráfico de ciertas máquinas virtuales

d. Capacidad de realizar puerto mirroring a un puerto físico de la red

externa

e. Soporte de Netflow

f. Soporte de SNMPv3

g. Protocolo de descubrimiento de dispositivos en capa 2

h. Syslog

i. Radius

j. TACACS+

15.14 Deberá soportar las siguientes funciones y protocolos de switcheo:

a. habilitar la tarjeta de red del servidor como un uplink de switch

b. Encapsulación de VLANs - IEEE 802.1Q

c. Soporte de 500 VLANs activas

d. Soporte de agregación de enlaces 802.3ad (LACP)

e. IGMP Snooping v1, v2 y v3

ESPHF-AD-010(5)


32

f. Marcado de tráfico para calidad de servicio (CoS, ToS y DSCP)

g. Soporte de multicast

h. Limitación de uso de ancho de banda por puerto virtual (Policing)

i. Soporte de tramas jumbo (jumbo frame) 64-9216 bytes

j. Filtrado de BPDU

15.15 Deberá soportar las siguientes funciones y protocolos de seguridad:

a. Listas de control de acceso de capa 2 y capa 3

b. El sistema deberá asegurar que los switches físicos no permitan ver

una dirección MAC de una máquina virtual a través de varios puertos

físicos. Esta seguridad deberá contemplar el caso en que una máquina

virtual se mueva de un servidor físico a otro.

c. Integración con TACACS+ y Radius

15.16 El switch lógico deberá tener la capacidad de:

a. Identificar la ubicación de los hosts en la red.

b. Asegurarse que sólo los hosts autorizados utilicen las direcciones IP

asignadas a ellos.

c. Asegurarse que sólo los DHCPs autorizados en la red sean accesibles y

puedan asignar direcciones IP.

d. Validar e inspeccionar los paquetes de ARP y descartar los paquetes

en que la relación entre la dirección MAC y la dirección IP no sea

válida

16. HERRAMIENTA DE ADMINISTRACIÓN Y CONFIGURACIÓN DE LA

INFRAESTRUCTURA VIRTUAL

16.1 Se deberá también proporcionar un producto de administración especializado

en infraestructuras virtuales que permita hacer las siguientes tareas:.

a. Creación de máquinas virtuales nuevas.

b. Supervisión de los signos vitales de las máquinas virtuales.

c. Definición de plantillas de máquinas virtuales

d. Ser compatible con el protocolo SNMP

e. El software debe operar en un equipo físico independiente de la solución

convergente.

ESPHF-AD-010(5)


33

16.2 El software de administración deberá ser capaz de mover máquinas virtuales

entre servidores físicos para balancear cargas en forma automática.

16.3 El software de administración deberá ser capaz de generar reportes de

consumo de CPU, RAM, ancho de banda usado en la red e indicación de

operaciones de entrada/salida del sistema de discos.

16.4 El software de administración deberá ser capaz de identificar la posibilidad de

prescindir de un número determinado de servidores físicos en horas no pico,

de forma que pueda mover automáticamente máquinas virtuales a un número

mínimo de servidores físicos de forma que pueda automáticamente poner en

estado de ahorro de energía (standby) los servidores prescindibles y

automáticamente volverlos a poner en servicio en horas de operación normal.

16.5 En caso de falla de un servidor físico, el software de administración deberá ser

capaz de reiniciar las máquinas virtuales que corren en dicho servidor, en

otros servidores que sean parte de la misma infraestructura virtual. Además se

deberá poder hacer esto en forma automática.

16.6 El software de administración deberá ser capaz de proteger máquinas virtuales

utilizando un mecanismo de espejo a nivel de procesamiento entre dos

máquinas virtuales ejecutándose en servidores físicos diferentes de forma que

si uno de los servidores falla y por consecuencia la máquina virtual que está

sobre este interrumpe su servicio, la máquina virtual que forma el espejo (y

que está sobre un servidor físico distinto) tome el control del servicio en

tiempo real de forma que el servicio no se interrumpa. En caso de presentarse

un evento como el recién descrito, la máquina virtual que queda sustentando

el servicio deberá ser protegida automáticamente por la capa de virtualización

mediante la creación de un nuevo espejo con otra máquina virtual que sea

creada automáticamente en otro servidor físico en funcionamiento dentro de la

misma infraestructura.

16.7 El software de administración deberá proporcionar un sistema automatizado

para la aplicación de actualizaciones al software del hipervisor que sumado a

la tecnología de movilidad permita la actualización de los hipervisores de una

plataforma, sin necesidad de interrumpir los servicios de las máquinas de

virtuales.

16.8 El software de administración deberá de incluir un sistema automatizado que

permita la aplicación de actualizaciones a los sistemas operativos (windows y

linux) residentes en las máquinas virtuales. La herramienta de actualización

deberá generar copias de protección de cada máquina virtual antes de aplicar

actualización de forma que exista la posibilidad de regresar la máquina virtual

al estado previo a la aplicación de la actualización en caso de que sea

necesario.

16.9 El software de administración deberá ser capaz de mover máquinas virtuales

entre servidores físicos y/o sistemas de almacenamiento tipo SAN/fibracanal,

ESPHF-AD-010(5)


34

iSCSI y NFS sin la necesidad de apagar las máquinas virtuales, es decir,

deberá poder migrar máquinas virtuales entre máquinas físicas en línea y sin

interrupción en la disponibilidad de las aplicaciones y servicios que residen

sobre las máquinas virtuales.

17. SOLUCIÓN DE ALMACENAMIENTO DE DATOS NO ESTRUCTURADOS

Características generales de la Unidad de Almacenamiento de datos No

Estructurados

17.1 El contratista deberá entregar la última actualización tecnológica del

Hardware y Software ofertado, cuando dicha versión tenga al menos un mes

de liberada en el mercado a la fecha de emisión de la orden de compra.

17.2 Los bienes ofrecidos deberán poseer una única marca de fábrica, y ser la

empresa fabricante la propietaria de dicha marca, la que deberá acreditar en

forma explícita tal situación.

17.3 El oferente deberá garantizar que los equipos que ofertan son totalmente

nuevos y de última tecnología, y que no contienen partes reconstruidas o

reparadas. Bajo ningún esquema se aceptarán equipos o componentes

genéricos o de segunda mano.

17.4 El equipo ofertado debe soportar trabajar 24 horas al día durante 365 días al

año. Los componentes ofrecidos deben funcionar e integrarse entre ellos,

eficientemente y sin problemas. La descripción dada en las especificaciones

técnicas, debe corresponder a dispositivos de almacenamiento que funcionen

correctamente con todas las partes descritas, y no servidores realizando

funciones de almacenamiento.

17.5 Se debe garantizar por escrito que el equipo se encuentra libre de errores (o

sea, que el equipo es nuevo y se encuentra libre de defectos).

17.6 La oferta debe incluir un listado de todos los componentes de la solución

indicando en cada uno el número de parte original del fabricante.

17.7 La solución debe ser monitoreable mediante herramientas que utilicen el

protocolo SNMP.

Características Específicas de la Unidad de Almacenamiento de Datos

17.8 El sistema de almacenamiento debe soportar la actualización en caliente del

microcódigo, firmware y drivers de componentes, a fin de no afectar la

disponibilidad del servicio.

17.9 La solución para Almacenamiento debe incluir todos los componentes

necesarios para su correcta conexión de datos y conexión eléctrica, instalación

y funcionamiento.

ESPHF-AD-010(5)


35

17.10 La memoria caché deberá estar protegida por mecanismos de redundancia y

tolerancia a fallas, de forma que la información se encuentre siempre

protegida ante la falla de cualquiera de sus componentes y que aún en caso de

falla de un módulo de memoria, se mantenga la integridad de la información y

ésta pueda ser grabada en disco.

17.11 En cualquier situación de pérdida del fluido eléctrico o falla de las plantas

eléctricas del centro de cómputo, el equipo debe tener la capacidad de

salvaguardar cualquier dato que se encuentre en memoria cache y no haya

sido almacenada en los discos de la solución de manera que garantice la

integridad lógica de la información.

17.12 El caché debe ser propio de las controladoras, no se permite caché simulado o

generado por discos.

17.13 Se deberán incluir todos los cables requeridos para conectar todos los puertos

del sistema de almacenamiento a la red LAN de la solución convergente

solicitada por ESPH en el presente cartel.

17.14 Arquitectura modular de escalabilidad horizontal construida con base en

elementos individuales completos (arquitectura scale-out).

17.15 Todos los nodos del sistema ofrecido deben operar como un “cluster paralelo”

de n-vías para servicios de almacenamiento de archivos.

17.16 El sistema debe actuar como un (1) único filesystem y un (1) único name-

space a lo largo de todo el sistema.

17.17 Factor de forma: Diseño modular basado en un chasis para montar en Racks

normalizados de 19”.

17.18 Se requiere de conectividad para Servicios de Archivos y datos no

estructurados de 1Gb/s, y 10Gb/s.

17.19 Los protocolos soportados deberán ser: NFS, CIFS, FTP, HTTP, NDMP,

SWIFT, REST y HDFS.

17.20 A medida que el sistema va creciendo en el tiempo, debe crecer linealmente

en rendimiento, capacidad y poder de I/O en red. (incluir mediciones de lo

ofertado)

17.21 La capacidad inicial requerida del sistema es de 20 TB efectivos utilizables.

17.22 La escalabilidad máxima de todo el sistema no podrá ser inferior a los 50 PB

usables, debiendo alcanzar ese volumen sin afectar el rendimiento global de la

solución.

17.23 Se requiere no menos de: 6 puertos Ethernet de 1Gb/s y 6 puertos Ethernet de

10Gb/s en la totalidad del sistema, estos últimos con interfaz de fibra óptica

para red LAN de 10Gbps.

ESPHF-AD-010(5)


36

17.24 El sistema debe ofrecer soporte para discos con conectividad, SATA y de

Estado Sólido. Especificar cuáles discos se entregan.

17.25 El equipo deberá soportar un mínimo de 3 controladoras paralelas o nodos

scale-out en un único sistema completo.

17.26 Se requiere una solución con no menos de tres (3) controladoras activas o

nodos scale-out.

17.27 Cada controladora activa o nodo scale-out debe poseer no menos de 24 GB de

memoria. Esta memoria debe estar configurada de tal forma, que ante la falla

de una controladora o nodo la memoria total no podrá ser inferior a 48GB con

coherencia global. La memoria deberá ser consistente entre todas las

controladoras del sistema.

17.28 Cada controlador o nodo de procesamiento deberá contar con single CPU

multi-core como mínimo, de la arquitectura x86/x64.

17.29 La solución deberá soportar como mínimo un nivel de protección N+1 ya sea

por archivo individual o por directorio/subdirectorio individual. A medida que

la solución crezca en cantidad de controladoras o nodos scale-out a futuro, se

deberán permitir niveles de protección N+2 hasta N+4.

17.30 La solución deberá presentarse como única, tanto en la implementación como

un su gestión.

17.31 La gestión de la solución debe efectuarse mediante una interfaz estándar tipo

web.

17.32 La capacidad efectiva ofrecida debe estar expresada en forma decimal.

17.33 El sistema deberá poseer fuentes de alimentación y ventiladores redundantes.

17.34 El sistema deberá soportar capacidad de WORM (protección contra borrado y

modificación de datos previamente escritos en el sistema, acorde a políticas)

para la información que así lo demande a nivel de archivo y/o directorios.

17.35 El sistema deberá ser compatible con el sistema operativo Linux kernel 2.6 o

superior (RedHat Enterprise Linux, SUSE Linux Enterprise Server, Oracle

Solaris, HP-UX, IBM AIX), Windows 2003/2008 Server y versiones

posteriores.

17.36 Deberá adjuntarse a la Oferta información oficial de la empresa fabricante de

los diferentes sistemas operativos, en el caso de indicar el soporte nativo

solicitado en el párrafo anterior.

17.37 El sistema deberá soportar respaldos vía protocolo NDMP, permitiendo de ser

requerido a futuro la instalación de una controladora o nodo scale-out

específico y dedicado para la aceleración de respaldos.

ESPHF-AD-010(5)


37

18. SOFTWARE PARA GESTIÓN Y OPERACIÓN DE ALMACENAMIENTO

DE DATOS NO ESTRUCTURADOS

18.1 El contratista deberá entregar la última actualización tecnológica del

Hardware y Software ofertado, cuando dicha versión tenga al menos un mes

de liberada en el mercado a la fecha de emisión de la orden de compra.

18.2 La oferta debe incluir las licencias de software para cubrir la capacidad de

espacio ofertada y la cantidad de discos entregados.

18.3 El adjudicatario debe garantizar en la ejecución del contrato el correcto

funcionamiento del software, instalando todos los parches del producto

cuando sea necesario y las actualizaciones de nuevas versiones del software

cuando estas sean liberadas, durante un periodo de cuatro (4) años a partir de

la emisión de la Orden de Compra, esto sin costo adicional para ESPH.

18.4 La solución de almacenamiento debe poseer una interface Web para la

ejecución de las labores de administración y operación, debe incluir todas las

licencias requeridas para su operación y administración.

18.5 Debe incluir las licencias necesarias de software que permita conocer el

estatus de la solución y de las capacidades de discos asignadas y libres a cada

servidor.

18.6 Debe contar con mecanismos de autorización y autenticación que garanticen

la seguridad de los datos y el control de acceso a las diferentes herramientas

sólo por el personal autorizado de ESPH.

18.7 Debe permitirse la actualización de cualquier componente de software

garantizando que no afecte al sistema de almacenamiento y el acceso continuo

a la información.

18.8 Se debe administrar, entre otras acciones:

a. La configuración de los componentes y recursos de almacenamiento.

b. La asignación del espacio en disco.

c. La disponibilidad y el desempeño de la infraestructura.

d. La configuración de nuevos volúmenes.

e. La revisión de estado de funcionamiento.

f. La definición de mapeos.

g. Configuración de cuotas de uso.

h. Balanceo de cargas automático en las interfaces de red.

ESPHF-AD-010(5)


38

i. Reconstrucción automática de los datos en caso de fallas de

componentes físicos.

j. Niveles de protección.

k. El ajuste de parámetros de rendimiento.

l. El manejo de rutinas de mantenimiento.

m. Agregar nuevos LUNS o discos.

18.9 En la oferta deberá incluirse el software necesario para cumplimentar los

siguientes requisitos:

a. Deberá poder realizar ampliaciones tanto de hardware como de

software en línea sin interrupción en el acceso de datos

b. Deberá poder balancear de forma automática el acceso a los datos a

través de todas las controladoras o nodos scale-out disponibles

c. Deberá tener la capacidad de movimiento de volúmenes de

información entre diferentes controladoras (nodos), mediante políticas,

y sin cambiar el punto de montaje en el servidor productivo, de forma

automática y transparente para el usuario. Si el movimiento demanda

de un software adicional, este deberá ser contemplado por el

proponente.

d. Deberá contar con la capacidad de ThinProvisioning, siendo esto una

parte fundamental de la implementación.

e. Deberá poder realizar cambios dinámicos de los niveles de protección

de datos (N+1, N+2, N+2:1, etc).

f. El sistema deberá soportar la agrupación de múltiples interfaces de red

en un solo dominio de red (trunking) y deberá poder balancear las

cargas entre todas las interfaces de red que pertenezcan a un

determinado segmento, dominio o VLAN. Si se requiere software

adicional para esto, deberá quedar contemplado y licenciado.

g. Deberá contar con la capacidad de WORM para los volúmenes que se

destinen para dicho propósito.

h. Deberá integrar el protocolo de acceso SWIFT.

i. Deberá integrar el protocolo de acceso HDFS (Hadoop File System)

j. Deberá contar con integración a Active Directory, siendo esto parte

fundamental de la implementación.

18.10 La solución deberá soportar a futuro la inclusión o licenciamiento de las

siguientes funcionalidades:

ESPHF-AD-010(5)


39

a. Deberá soportar la capacidad de analizar el rendimiento del

equipamiento, entregando detalles de los valores de máximos y

actuales IOPS.

b. Deberá contar con la capacidad de Quota Management.

c. Deberá soportar la realización de réplica remota asincrónica de manera

concurrente, entre equipos similares, mediante enlaces de tipo TCP/IP.

d. Capacidad de administrar múltiples niveles de almacenamiento a nivel

volumen completo (Tiering) entre distintas tecnologías de discos:

SSD, SAS y SATA, sin que el usuario de los archivos se percate del

movimiento. Esta funcionalidad debe estar incluida.

e. Deberá contar con la capacidad de permitir la creación de Tiers de

servicio con el fin de garantizar niveles de rendimiento adecuados a las

aplicaciones. Deberá contar con la capacidad de proveer las

herramientas necesarias con el fin de poder definir “Tiers”

automáticos, de modo que los datos más accedidos o inmediatos sean

reubicados en medios de acceso más veloces (calidad de servicio

automática).

f. Se deberá incluir licencia de copias “point in time” de tipo Snapshot

para la totalidad de la capacidad soportada por el equipamiento.

g. Para las copias tipo Snapshot, se requiere poder mantener por lo menos

256 imágenes de un mismo volumen.

18.11 Oferente deberá suministrar toda la documentación técnica que permita

verificar las características de los equipos y componentes ofertados. La

documentación podrá ser únicamente en idioma español o inglés. En donde se

mencionen Normas o Estándares, debe valorarse que se aceptarán otros que

sean reconocidos internacionalmente y que garanticen una calidad igual o

superior a lo estipulado por ESPH (se debe documentar ampliamente).

18.12 Toda la solución debe ser monitoreable mediante herramientas que utilicen el

protocolo SNMP.

19. INSTALACIÓN Y CONFIGURACIÓN DE LA SOLUCIÓN

19.1 El Contratista será responsable de la instalación y configuración completa de

los módulos de hardware y software objeto de esta contratación, así como del

soporte y mantenimiento de los mismos. Debe contemplar las pruebas que

sean necesarias y su puesta en operación. El personal de ESPH debe participar

durante todo el proceso de instalación, configuración, pruebas y puesta en

operación.

ESPHF-AD-010(5)


40

19.2 El oferente debe cotizar la instalación, el cableado de fibra y eléctrico, el tiraje

de estos cables y cualquier otro componente adicional que se requiera para el

correcto funcionamiento del dispositivo, de acuerdo con las especificaciones

de ESPH.

19.3 La configuración inicial de la solución solicitada debe poder instalarse en un

solo RACK o gabinete (enclosure) de 42 o 45 unidades de rack (U), el cual

debe ser incluido en la solución.

19.4 El color del Rack debe ser negro o gris, adicionalmente las puertas traseras y

delanteras deben contar con la respectiva ventilación, el oferente deberá

proveer todos los dispositivos que permitan que la totalidad de los equipos

contenidos en el gabinete no se vean afectados por problemas de temperatura

o calor internos al gabinete, deberá acondicionarlos para este fin,

considerando que cada gabinete contendrá tantos equipos como su capacidad

lo permita. De requerir instalar abanicos o disipadores de calor para cumplir

con este requerimiento, deberá instalar en cada gabinete la cantidad de estos

dispositivos que sean necesarios de acuerdo a las recomendaciones del

fabricante.

19.5 Adicionalmente se debe entregar en el rack al menos dos distribuidores de

potencia (PDU) y sus respectivas barras de conexión con la capacidad de

soportar la solución de almacenamiento a su máxima capacidad de

crecimiento. Las PDU deben ser de 220 voltios y deben contar con todos los

accesorios que permitan su instalación sin ocupar un espacio U en Rack.

19.6 El sistema de almacenamiento debe quedar debidamente instalado y cableado

dentro del Rack, asegurando la aplicación de las mejores prácticas del

fabricante en el proceso.

19.7 El Contratista debe presentar una propuesta preliminar de las actividades a

realizar para llevar a cabo la instalación y configuración de los componentes

de esta contratación, incluyendo las pruebas de funcionamiento de los

componentes de hardware y software involucrados, así como la

interconectividad requerida con los servidores a ser aprovisionados al

momento de la instalación, de manera que la instalación y configuración se

realice a satisfacción de ESPH. Para ello debe proponer, a más tardar después

de ocho días hábiles a partir de la fecha de notificación del Contrato de

Servicio, un cronograma general de las actividades a realizar para llevar a

cabo la instalación y configuración de los componentes de esta contratación.

Dicho cronograma deberá ser aprobado por el administrador del contrato.

19.8 El oferente debe especificar los requerimientos físicos, eléctricos y

ambientales requeridos para la correcta instalación de la configuración

propuesta de los equipos objeto de esta contratación.

ESPHF-AD-010(5)


41

19.9 La instalación deberá ser efectuada por personal técnico de la empresa

adjudicataria, debidamente certificados y en las instalaciones del ESPH, en

coordinación y apoyo de funcionarios del ESPH.

19.10 El oferente debe realizar una revisión en el Centro de Cómputo designado por

ESPH, para verificar que existan las condiciones de previstas eléctricas para la

correcta instalación de los equipos ofertados, esta conexión eléctrica es desde

el tablero principal de alimentación eléctrica provisto por el ESPH, previa

coordinación con la parte técnica de un mínimo de dos días antes de la fecha

efectiva de visita.

19.11 ESPH debe realizar toda la instalación eléctrica partiendo desde el tablero

principal de alimentación eléctrica que posee en su Sala de Cómputo hasta el

rack de ésta contratación y proveer todos los componentes necesarios (tableros

secundarios, cableado, conectores eléctricos, regletas). De modo que todos los

componentes queden funcionando de forma óptima, de acuerdo a las

especificaciones del fabricante y a plena satisfacción del ESPH.

19.12 El Oferente deberá suministrar toda la documentación técnica que permita

verificar las características de los equipos y componentes ofertados y la forma

en que fueron instalados. La documentación podrá ser únicamente en idioma

español o inglés. En donde se mencionen Normas o Estándares, debe

valorarse que se aceptarán otros que sean reconocidos internacionalmente y

que garanticen una calidad igual o superior a lo estipulado por el ESPH (se

debe documentar ampliamente).

20. SERVICIOS DE: MANTENIMIENTO CORRECTIVO Y

MANTENIMIENTO PREVENTIVO DE LA ARQUITECTURA DE T. I

DURANTE EL PLAZO DE LA CONTRATACIÓN

1. Durante el plazo de la contratación el contratista tendrá la responsabilidad de

proporcionar los servicios de mantenimiento preventivo y correctivo para

garantizar el buen funcionamiento de la plataforma tecnológica con una

continuidad de 99,98% del tiempo

21. SERVICIOS DE: GESTIÓN DE LA PLATAFORMA (INFRAESTRUCTURA

DE T. I) DURANTE EL PLAZO DE LA CONTRATACIÓN

1. El contratista deberá gestionar la plataforma durante el plazo de la contratación.

2. Durante el plazo el contratista de be administrar la plataforma para garantizar

tiempos continuos de servicio 24x7x365 y disponer de un nivel de operación de

99,98%

3. Se debe cumplir con los niveles de servicio señalados en el presente documento

ESPHF-AD-010(5)


42

4. Se deben atender y resolver niveles de incidentes, realizar monitoreo proactivo y

preventivo 24x7x365, para lo cual debe contar con herramientas tecnológicas

que permitan llevar a cabo el monitoreo de la infraestructura.

5. Presentar reportes y gráficas necesarias para detallar el comportamiento de la

infraestructura tecnológica.

6. Niveles de disponibilidad del servicio:

La atención y solución de estos niveles de disponibilidad deben estar

bajo la modalidad de trabajo 24x7x365

Nivel de disponibilidad 1: En este nivel la solución debe estar disponible

mínimo 99,98% del tiempo

Nivel de disponibilidad 2: En este nivel la solución debe estar disponible

mínimo un 98,8% del tiempo

Niveles de Servicio:

TIPO DE NIVEL DE SERVICIO

DESCRIPCIÓN DEL TIPO DE ATENCIÓN TIEMPO MÁXIMO

DE ATENCIÓN TIEMPO MÁXIMO DE RESOLUCIÓN

Averías Críticas

Corresponden a incidentes o proble-mas que interrumpen el servicio tales como: - El servicio no está disponible -No cumple con el nivel 1 solicitado - Los tiempos de respuesta en el envío de los mensajes no es el solicitado

15 minutos después del reporte de la avería

1 hora natural después de re-portada la avería

Averías No Crí-ticas

Corresponden a incidentes o proble-mas que no interrumpen el servicio, tales como: - El servicio está disponible y la falla presentada no afecta el servicio. - No cumple con el nivel de disponibili-dad 2 solicitado.

1 hora natural des-pués de reportada la avería

2 horas naturales después de repor-tada la avería

Trabajos de implementación de mejoras correctivas o preventivas

Corresponde a actividades programadas o no programadas a fin de realizar la implementación de mejo-ras, mantenimientos correctivos y/o preventivos sobre el servicio.

8 horas hábiles después de solicitado el mismo

Según lo establecido en el plan de trabajo respectivo

Si el proveedor manifiesta que requiere de un mayor tiempo de respuesta, debe brindar la justificación formal correspondiente, la cual será valorada por el responsable contractual, quién de-termina si es válida.

ESPHF-AD-010(5)


43

7. Requerimientos para la atención de incidentes y/o solicitudes

Debe facilitar una herramienta oficial para el registro y reporte de los

incidentes y solicitudes que puedan presentarse. ESPH reportará por

medio de dicha herramienta, cualquier evento que sea detectado y que

forme parte del alcance de esta contratación. El caso incluido debe ser

enviado automáticamente a las personas encargados para que se inicie el

proceso de atención y solución del mismo según los tiempos

establecidos.

Debe facilitarse acceso a la herramienta del personal que ESPH designe

para que puedan abrir casos de reportes de incidentes, así como para

consultar el avance de alguno incluido, sacar estadísticas de atención,

entre otros.

La atención de los incidentes reportados debe ser realizada 24x7x365

La información oficial del tiempo de atención y solución de los

incidentes o problemas reportados será generada de dicha herramienta y

será el insumo oficial para determinar cualquier incumplimiento

contractual. Por esta razón, en todo momento debe mantener una

bitácora de lo sucedido en cada caso.

Deberá indicar los números de teléfono, correo electrónico y

dirección Web para que la ESPH pueda contactar a los encargados de

resolver los incidentes reportados.

En el informe que se debe entregar mensualmente se debe incorporar la

información de los incidentes, problemas y/o solicitudes suscitados

durante el mes.

8. Debe realizar monitoreo proactivo y preventivo 24X7X365 para lo cual debe

contar con herramientas tecnológicas que permitan llevar a cabo el monitoreo

del aplicativo y de la infraestructura. Debe ofrecer a la Administración los

reportes y gráficas necesarias para el seguimiento del comportamiento de la

solución. Adicionalmente se debe permitir acceso a dichas herramientas a

personal autorizado de la ESPH.

IV. Plazo de la Contratación

Tiempo de entrega de equipos:

El tiempo de entrega de los equipos será de 75 días naturales computados a partir de

la notificación de la orden de compra.

Tiempos de Implementación de la plataforma (Infraestructura de TI):

El tiempo de implementación será de 30 días naturales a partir de la entrega del

equipo.

ESPHF-AD-010(5)


44

Plazo del Servicio soporte y mantenimiento de la plataforma (Infraestructura

de TI):

El plazo del contrato es por 36 meses, prorrogable un año, a partir de la instalación

y puesta en marcha de la solución. El oferente debe elaborar un cronograma de

ejecución. La ESPH está en su derecho de modificar el cronograma si lo considera

pertinente.

V. Multas

Entrega de equipos:

Por cada día natural de atraso en la entrega se aplicará un 2% del costo total de la

solución hasta un máximo de un 25% del costo total del monto total adjudicado.

Implementación de la plataforma (Infraestructura de TI):

Por cada día natural de atraso de la implementación se aplicará un 2% del costo

total de la solución hasta un máximo de un 25% del costo total.

Servicio soporte y mantenimiento de la plataforma (Infraestructura de TI):

Para la entrega de las líneas detalladas en la presente solicitud aplicarán las

siguientes multas o sanciones por la no entrega con la debida aceptación por la

correspondiente unidad administradora en las fechas establecidas.

TIPO DE SERVICIO MULTA

Averías Críticas 1% del monto mensual por cada hora natural de atraso presentado, adicional al tiempo que prevé el SLA

Averías no Críticas 0,5% del monto mensual, por cada hora na-tural de atraso presentado, adicional al tiempo que prevé el SLA

Trabajos de implementación de mejoras correctivas o preventivas

0,5% del monto mensual de mantenimiento por cada 6 horas hábiles de atraso presenta-do, adicional al tiempo que prevé el SLA.

Adicionalmente se aplicarán las siguientes multas en caso de incumplimiento en la

entrega de los informes.

Si no es presentado algún informe según las fechas acordadas con el

Administrador del Contrato, se cobrará un 2% por cada día hábil de atraso

hasta un máximo de 25% del monto facturado durante el mes en que se dio

el incumplimiento o atraso, salvo casos de fuerza mayor debidamente

comprobados a juicio de ESPH.

ESPHF-AD-010(5)


45

En caso de atraso o incumplimiento en la atención de una corrección de

garantía, el proveedor debe cubrir por concepto de multa, el 2% por cada día

hábil de atraso, salvo casos de fuerza mayor debidamente comprobados a

juicio de ESPH.

El cobro de las multas se podrá hacer con cargo a las facturas pendientes de pago,

previo debido proceso al contratista y de conformidad con lo indicado por la Sala

Constitucional en el voto 6639-2013.

VI. Formalización y vigencia de la Contratación

El adjudicatario debe firmar un contrato con la ESPH S.A. para lo cual tendrá un

plazo de 5 días hábiles posterior a la recepción de la adjudicación para firmar dicho

contrato. Además deberá cancelar las especies fiscales correspondientes.

El tiempo de vigencia del contrato de soporte a la plataforma será de 36 meses,

prorrogable a 12 meses adicionales de conformidad a los procesos establecidos en la

ESPH S.A.

VII. Modalidad de Pago

El pago del equipo se realizará de hasta 60 días después de que la instalación y

puesta en marcha de la Infraestructura tecnológica con la aprobación de la unidad

administrativa y con la previa presentación de la factura. La instalación de la

infraestructura se realizará en el centro de datos que defina ESPH.

Los servicios de soporte, mantenimiento preventivo, mantenimiento correctivo, y

gestión de la plataforma se pagarán mensualmente, luego de la presentación de un

informe mensual en el que se indique las condiciones de prestación del servicio, así

como los tiempos de interrupción de los servicios y procedimientos de resolución

del contratista.

VIII. Garantías

Los oferentes deberán rendir garantía de participación por un 5% del monto

ofertado, la misma deberá contar con una vigencia de 120 días naturales

computados a partir de la fecha de recepción de las ofertas.

Y el adjudicatario deberá rendir garantía de cumplimiento por el valor de 5% del

monto adjudicado, garantía que deberá permanecer vigente hasta un mes adicional a

la vigencia total del contrato principal o sus prorrogas. (esto incluye también el

periodo de mantenimiento y servicio de gestión)

IX. Cesión del Contrato

ESPHF-AD-010(5)


46

El contratista no se podrá ceder ni parcial ni totalmente, ni transferir de modo

alguno se gratuito u oneroso, salvo autorización expresa y escrita de la ESPH, S.A.

X. Responsabilidad Social del Contratista

El contratista deberá apegarse a lo estipulado en la legislación vigente, y no podrán

emitir mecanismos de discriminación en sus contrataciones por género, credo o

raza. Así como los requerimientos de las autoridades competentes:

Estar al día en materia de pago de impuestos

Estar al día en materia de pago de obligaciones obrero-patronales con CCSS

Estar al día en materia de pago del Fondo de Desarrollo Social y Asignaciones

Familiares (FODESAF)

El contratista estará obligado a conocer y cumplir lo establecido en el documento Reglas de

Calidad, Saludo y Seguridad y Ambiente para Contratistas de la ESPH S.A. (el docu-

mento se encuentra en la página de la empresa: www.esph-sa.com en la pestaña proveedo-

res) y también debe someterse a las inspecciones periódicas que la ESPH S.A. realice para

verificar el cumplimiento del mismo.

Las consecuencias de orden laboral y de accidentes de trabajo, serán de entera responsabili-

dad del contratista, al igual que las derivadas de daños a las personas o bienes a terceros, en

consecuencia, el contratista, para todos los efectos, será reputado como patrón único y ex-

presamente deja exonerada a la Empresa de cualquier responsabilidad de orden civil y labo-

ral, con motivo en razón o consecuencia de los servicios contratados. En caso de producirse

una situación de emergencia o accidente laboral se debe notificar al administrador del con-

trato por parte de la Unidad Interesada (responsable de la contratación) para que este infor-

me al departamento de Salud Ocupacional de la ESPH S.A.

XI. Condiciones de Admisibilidad

1. Por la relevancia de este proyecto, se debe ofrecer una solución llave en mano,

por lo tanto, el oferente debe cotizar la totalidad de los ítems.

2. El oferente deberá demostrar que en los últimos cuatro años (contados a partir de

la fecha fijada para la recepción de ofertas de este concurso) ha brindado servi-

cios iguales o similares a la caracterización del objeto de la presente contratación

(entiéndase similares a servicio de administración de plataformas como la del ob-

jeto de esta contratación, con licencias y equipos de la misma tecnología, marca o

fabricante a la indicada en el presente cartel, pero de modelos o versiones dife-

rentes), para lo cual deberá presentar una declaración jurada con al menos un

clientes diferentes a los cuales les haya brindado el servicio, Dicha declaración,

deberá contener la siguiente información por cada uno de ellos:

http://www.esph-sa.com/

ESPHF-AD-010(5)


47

Nombre del cliente

Nombre del funcionario contacto

Número de teléfono, correo electrónico de la persona contacto

Descripción del servicio brindado (detallar la solución a la cual se le

brindó el servicio)

Mes y Año de la realización del servicio

Calidad del servicio, excelente, muy bueno o satisfactorio. Para efectos

de considerar el cumplimiento, solamente se considerarán los criterios

de: excelente, muy bueno o satisfactorio.

2. El oferente deberá presentar una carta del fabricante dirigida a la ESPH con NO

más de 3 meses de haberse emitido contando a partir de la fecha fijada para la re-

cepción de las ofertas, en la cual demuestre que cumple con al menos 2 (dos)

años de ser partner GOLD del fabricante ofertado.

3. El oferente deberá adjuntar una nota del fabricante dirigida a la ESPH, en donde

indique expresamente que atenderá los reportes durante el período de garantía,

con las mismas condiciones, en caso de que el proveedor no las atienda según lo

estipulado en esta contratación.

4. El oferente para esta oferta debe como minino haber implementado un proyecto.

XII. Condiciones del Personal del Oferente

1. El oferente deberá adjuntar una nota del fabricante dirigida a la ESPH, en donde

indique expresamente que atenderá los reportes durante el período de garantía,

con las mismas condiciones, en caso de que el proveedor no las atienda según lo

estipulado en esta contratación:

Currículum de cada uno de los técnicos.

Copias de las certificaciones del fabricante del hardware en la tecnolo-

gía ofertada, para brindar el servicio de soporte respectivo de los pro-

ductos ofertados.

Copia de las planillas presentadas a la Caja Costarricense del Seguro

Social de los seis meses anteriores a la fecha de la apertura de ofertas.

2. El oferente deberá contar con al menos 2 (dos) técnicos en informática, con una

experiencia mínima de un año cada uno en la operación y mantenimiento en la

marca del software de virtualización ofertado, lo que le garantice a la ESPH el

servicio, los técnicos deberán formar parte de la planilla del oferente (como mí-

ESPHF-AD-010(5)


48

nimo durante los últimos seis meses, previo a la apertura de ofertas en el presente

concurso), para lo cual deberá presentar la siguiente documentación:

Currículum de cada uno de los técnicos.

Copias de las certificaciones del fabricante del software en la tecnología

ofertada, para brindar el servicio de soporte respectivo de los productos

ofertados

Copia de las planillas presentadas a la Caja Costarricense del Seguro

Social de los seis meses anteriores a la fecha de la apertura de ofertas.

3. El oferente deberá contar con al menos 1 (un) técnico en informática, con una


marca del hardware y software de respaldo y recuperación ofertado, lo que le ga-

rantice a la ESPH el servicio, para lo cual deberá presentar la siguiente documen-

tación:

Currículo vitae del técnico

Copias de las certificaciones del fabricante del software y hardware en

la tecnología ofertada, para brindar el servicio de soporte respectivo de

los productos ofertados

4. El oferente deberá contar con al menos 2 (dos) técnicos en informática, con una


marca del hardware y software de la solucion de almacenamiento de datos NO

estructurados (scale-out) ofertada lo que le garantice a la ESPH el servicio, para

lo cual deberá presentar la siguiente documentación:

Currículum del técnico

Copias de las certificaciones del fabricante del software y hardware en

la tecnología ofertada, para brindar el servicio de soporte respectivo de

los productos ofertados

5. Currículum del técnico

6. Copias de las certificaciones del fabricante del software y hardware en la tecno-

logía ofertada, para brindar el servicio de soporte respectivo de los productos

ofertados

XIII. Lugar de Entrega

ESPHF-AD-010(5)


49

Todos los equipos se entregarán en el centro de datos que defina e indique el líder de

operación y soporte de TIC de la ESPH para este propósito. Esta información se brin-

dará en reunión inicial del Proyecto (Kick Off).

XIV. Tabla de Valoración para Calificación y Adjudicación

Para efectos de valoración de las ofertas, se considera la siguiente tabla de puntaje:

CRITERIO PESO %

PRECIO

Menor precio 80%

Otros precios proporcional aplicando la siguiente fórmula:

P= 80*(Pb/Po)

Dónde:

P= Puntaje obtenido por la oferta en estudio

Pb= Precio de la oferta de menor precio

Po= Precio de la oferta en estudio

80%

TIEMPO DE ENTREGA

Al oferente que ofrezca menor tiempo de entrega, se le otorgarán 10 puntos, a cada oferen-

te se le calculará el puntaje de acuerdo con la siguiente fórmula:

T= X* (Tb/To)

Dónde:

T = Puntaje obtenido por la oferta en estudio.

X = Valor asignado proporcional al 100%.

Tb = Período de la oferta de menor tiempo de entrega en días naturales.

To = Período de la oferta en estudio en días naturales.

10%

EXPERIENCIA DEL PROVEEDOR

Se otorgará 10% a la empresa que demuestre mayor experiencia brindando servicios como

los aquí contratados. Únicamente serán evaluadas las ofertas que cumplan con los requisi-

tos de admisibilidad y para ello se utilizará la siguiente tabla;

1 proyecto 0 puntos

2 proyectos 4 puntos

3 proyectos 6 puntos

4 o más proyectos 10 puntos

Se entenderá por proyectos aquellas implementaciones en donde se haya implementado

Software como Servicio en al menos un servicio de los ofertados

Los oferentes deberán acreditar dicha experiencia en la declaración jurada que se indica en

el pinto XI.2, la ESPH podrá contactar a los clientes para validar la veracidad de la in-

formación.

10%

Total Puntos a obtener 100%

ESPHF-AD-010(5)


50

Las ofertas admitidas se compararán y adjudicarán de acuerdo al sistema de puntajes que

cada usuario desee utilizar, siendo la(s) oferta(s) seleccionada(s) para su adjudicación la

que logre el mayor puntaje y cumpla con lo requerido por la Unidades Interesada y que a la

vez favorezca los intereses de la ESPH, S.A.

Nota: Esta contratación será adjudicada a un solo proveedor, dada la integración necesaria

de los requisitos del cartel

A continuación, se determina la fórmula para calcular el puntaje obtenido según los rubros

de la tabla anterior:

XV. Consideraciones en Salud - Seguridad Ocupacional y Ambiente

En cuanto a seguridad y salud ocupacional, el oferente debe apegarse a lo establecido en El

Procedimiento ESPHP-SGI-013 Relación con Proveedores y Contratistas.

ESPH dispondrá de un administrador del contrato quien validará el cumplimiento de las

normas establecidas para los Proveedores.

Especificar que antes de iniciar la prestación del servicio, el contratista deberá recibir la

Inducción del SGI y portar siempre el carnet de contratista; esto durante el periodo que

presta el servicio.

El proveedor debe indicar los procedimientos a llevar a cabo para el manejo de residuos

producto del servicio y según se establece en la Ley de Gestión Integral de Residuos Nº

8839 y su Reglamento

Nombre de la compra: CARTEL TÉCNICO PARA LA … · 3.12 Deberá soportar la conexión de teclado,...

Documents

Transcript of Nombre de la compra: CARTEL TÉCNICO PARA LA … · 3.12 Deberá soportar la conexión de teclado,...