Sí, es correcto, siempre que la solución propuesta se gestione de forma centralizada y cumpla de manera integrada todos los requisitos exigidos para la capa de almacenamiento. En particular, debe entenderse que todo el almacenamiento de la plataforma deberá poder ser accedido mediante los tres modos indicados: bloque, objeto compatible S3 y fichero, sin que se limite cada modalidad a silos de datos independientes ni sea necesario incorporar gateways, appliances intermedios o plataformas adicionales para habilitar dichos accesos.

La respuesta a su pregunta está en el PCAP. Revise la información del punto 2 del PCAP.

No se admite la sustitución de la capa de virtualización definida en el pliego por tecnologías alternativas como Proxmox VE u otras plataformas open source. La solución ofertada deberá ajustarse a lo establecido en el Pliego Técnico, que exige que la capa de cómputo se base en VMware vSphere como tecnología de virtualización, sobre la que se desplegará Red Hat OpenShift Container Platform. Asimismo, todos los nodos de cómputo deberán estar licenciados bajo VMware vSphere Foundation o bajo una modalidad de VMware que incluya la funcionalidad de switch distribuido.

- De acuerdo con el requisito RS.E.1, el adjudicatario debe operar y administrar todos los componentes de la solución, incluyendo expresamente la capa de cómputo —entorno VMware y entorno OpenShift— y la capa de almacenamiento. Además, en las medidas de resiliencia, el pliego establece que las copias de seguridad se realizarán conforme a la política que RTVE determine y se almacenarán cifradas en un bucket S3 provisto por RTVE; dichas copias deberán incluir tanto los datos multimedia como las configuraciones de cada uno de los elementos de la infraestructura. - Se confirma que el cumplimiento de los requisitos RS.E.18, RS.E.19, RS.E.20 y RS.E.21 puede realizarse mediante una solución específica de backup y recuperación, integrada en la arquitectura propuesta y suministrada, licenciada, mantenida y operada por el adjudicatario durante toda la vigencia del contrato, siempre que utilice como destino el bucket S3 provisto por RTVE y garantice el cifrado, la seguridad, la restaurabilidad y los objetivos de recuperación exigidos. No se exige que la exportación de las copias hacia S3 sea una funcionalidad nativa de la propia plataforma de almacenamiento. Por tanto, se admite el uso de software adicional de backup, orquestación o automatización, siempre que forme parte de la solución ofertada, no suponga coste adicional para RTVE y quede plenamente integrado en la operación de la plataforma. Esta interpretación es coherente con que el pliego exige que la solución incluya todo el hardware, software, licencias y servicios necesarios, y que el adjudicatario asuma los costes del software durante la vida del contrato. Asimismo, el objeto de las copias debe entenderse como una copia lógica y recuperable de los datos multimedia y de las configuraciones de la infraestructura, conforme a la política que RTVE determine durante la ejecución del proyecto. No se requiere específicamente la exportación de snapshots de cabina al bucket S3.

Las versiones exactas de los sistemas operativos y de los componentes HAProxy, Varnish, Apache, NGINX, PHP, Unified Streaming y Jenkins actualmente en explotación no se detallan adicionalmente en esta fase. El adjudicatario deberá asumir que la arquitectura actual puede haber evolucionado desde la publicación del expediente de 2021 y que los cambios menores derivados de dicha evolución serán concretados en las reuniones iniciales del proyecto.

1) La solución deberá almacenar histórico de métricas y alertas durante un periodo mínimo de 12 meses, accesible para informes y auditorías. Asimismo, los datos de medición de los ANS deberán estar disponibles para RTVE en tiempo real y conservarse durante al menos 12 meses. El pliego no establece un volumen diario cerrado de eventos o logs. El licitador deberá dimensionar la solución de monitorización, observabilidad y almacenamiento de logs de forma coherente con la arquitectura propuesta, el conjunto de componentes incluidos en el alcance y los requisitos de integración con herramientas SIEM corporativas. 2) El requisito RT.SP.10 se refiere a la capa de seguridad perimetral y exige que la solución cuente con almacenamiento local integrado para logs y configuraciones superior a 900 GB. Dado que el pliego exige dispositivos de seguridad perimetral con características físicas concretas, , deberá entenderse que este requisito aplica a la solución de firewall/perímetro propuesta. No se contempla como equivalente sustituir dicha capa por una solución exclusivamente virtual si ello impide cumplir las exigencias de hardware, rendimiento, interfaces y almacenamiento local integrado indicadas en el pliego. 3) La capa de balanceo debe cubrir, como mínimo las funcionalidades de balanceo descritas en pliego. Por tanto, WAF, AntiDDoS o protección avanzada de APIs no se configuran como mínimos obligatorios salvo en la medida en que formen parte de las capacidades requeridas u opcionales descritas, pero sí podrán ser valorados si se presentan como valor añadido o como implementación de los requisitos opcionales aplicables. 4) El flujo funcional descrito en el pliego establece que las peticiones procedentes de CDN llegan primero a la capa de seguridad perimetral, donde se aplican políticas de filtrado, y posteriormente son encaminadas a través de la capa de balanceo hacia la caché o los backends correspondientes. Por tanto, la capa de balanceo debe entenderse ubicada lógicamente tras la capa de seguridad perimetral. 5) RTVE admite que el licitador proponga un modelo consolidado de balanceo sobre la plataforma ADC/balanceo principal, siempre que se mantenga la separación lógica y funcional entre verticales, entornos y servicios, y se cumplan todos los requisitos de rendimiento, resiliencia, seguridad, trazabilidad, multi-tenancy e integración exigidos en el pliego. No se exige que todos los balanceos internos actualmente asociados a HAProxy se mantengan necesariamente sobre plataformas independientes.

6) Los HAProxy internos existentes realizan actualmente funciones de balanceo y encaminamiento de tráfico hacia los distintos orígenes, backends y servicios internos asociados a los verticales de distribución de media. En la nueva arquitectura no se exige mantener HAProxy como tecnología específica. Lo que debe mantenerse obligatoriamente es la funcionalidad actualmente prestada: el correcto enrutamiento y balanceo de los distintos verticales, la publicación de los servicios necesarios, la segregación funcional entre verticales, la integración con las capas de caché y demás funciones descritas en pliego. El detalle de configuraciones vigentes, reglas específicas y posibles evoluciones menores del entorno actual se facilitará durante las reuniones iniciales de proyecto, conforme a lo previsto en el pliego para la fase de migración. 7) El requisito RS.E.16 debe entenderse como una obligación de ejecutar análisis periódicos de vulnerabilidades y pruebas de seguridad acordadas con RTVE sobre los activos incluidos en el alcance. Se considera válido proponer una línea base de pruebas periódicas incluida dentro del servicio fijo, siempre que cubra el cumplimiento del requisito, y complementar actuaciones adicionales de mayor alcance mediante los servicios profesionales especializados previstos en el contrato, cuando RTVE las solicite y apruebe expresamente. 8) La arquitectura general debe garantizar alta disponibilidad, resiliencia y continuidad del servicio entre los dos CPD. El PCT exige que toda la infraestructura y los datos estén replicados en ambos centros, permitiendo que cada CPD pueda funcionar de forma autónoma ante la caída del otro. No obstante, existen requisitos específicos por capa. En seguridad perimetral, el pliego exige como mínimo alta disponibilidad activo-pasivo. En balanceo, el requisito general es activo-activo con failover automático, si bien se admite una configuración activo-pasivo cuando el licitador la justifique técnicamente. Por tanto, la solución debe respetar el modelo de alta disponibilidad exigido en cada capa, pudiendo justificarse esquemas activo-pasivo en los casos expresamente admitidos por el pliego. 9) Durante la migración, las tareas no deberán afectar al servicio productivo actual salvo en el día de cutover. La estrategia deberá incluir copia previa al cutover y sincronizaciones periódicas para reducir las ventanas de corte.

10) La migración de la capa de seguridad y balanceo forma parte del alcance del contrato. El adjudicatario deberá migrar configuraciones de firewalls, balanceadores y cachés, además de los servicios en máquinas virtuales, contenedores y datos asociados. El pliego no fija en esta fase fabricante, modelo, número exacto de políticas ni número cerrado de funcionalidades activas del entorno actual. Sí establece los requisitos mínimos que deberá cumplir la nueva solución, indicadas en el PCT.

El requisito RT.GEN.4 exige que la plataforma disponga de un servicio de gestión de nombres y FQDNs que permita la correcta gestión, publicación y operación de los servicios desplegados en la solución. A estos efectos, se considerará válido que el licitador proponga un servicio DNS altamente disponible, redundado e integrado con la arquitectura de la plataforma, siempre que permita gestionar de forma adecuada los nombres internos y, cuando aplique, los nombres asociados a los servicios expuestos o integrados con el resto de capas de la solución. No se exige una solución concreta de mercado ni una plataforma específica de gestión centralizada tipo Infoblox, siempre que la solución propuesta cumpla los requisitos del pliego, sea coherente con la arquitectura ofertada, garantice alta disponibilidad, operación segura, trazabilidad y adecuada integración con los sistemas de gestión, monitorización, automatización y documentación de la plataforma. Serán admisibles soluciones basadas en tecnologías open source, siempre que el licitador garantice su soporte, mantenimiento, actualización, seguridad, operación durante toda la vigencia del contrato y ausencia de costes adicionales para RTVE, en los términos establecidos en el pliego. En relación con la integración con plataformas corporativas existentes, RTVE facilitará durante la fase de proyecto la información técnica necesaria sobre los sistemas corporativos con los que, en su caso, deba integrarse la solución, no existiendo, a priori, una plataforma sobre la que integrar el servicio de gestión de nombres y FQDNs.

1. En relación con el requisito RT.CACH.7, se aclara que la solución deberá estar formada por un mínimo de 4 nodos de caché Varnish en total. Dado que la solución debe desplegarse en dos CPD y que la infraestructura susceptible de réplica debe disponer de un mínimo de 2 réplicas por centro, la interpretación correcta es 2 nodos por CPD, 4 nodos en total, sin perjuicio de que los licitadores puedan proponer un número superior de nodos como mejora o por necesidades de dimensionamiento. 2. No se exige de forma cerrada un número concreto de clústeres independientes de Varnish. Se requiere una capa de caché distribuida, balanceada, en alta disponibilidad y tolerante a fallos, desplegada entre los dos CPD, de forma que cada CPD pueda operar de manera autónoma ante la caída del otro. Serán admisibles diseños con un único clúster lógico distribuido o con clústeres diferenciados por CPD, siempre que se justifique técnicamente el diseño propuesto y se cumplan los requisitos de disponibilidad, resiliencia, operación y monitorización establecidos en el pliego. 3. El pliego no establece un valor adicional específico de pico de tráfico exclusivo para la capa Varnish. El dimensionamiento deberá realizarse por el licitador de forma coherente con la arquitectura global, las capacidades mínimas exigidas para líneas, balanceadores, red y caché, y los esquemas de carga de trabajo incluidos en el apéndice de verticales de distribución. En todo caso, la solución deberá soportar desde su puesta en producción la carga máxima prevista con el rendimiento exigido en el pliego. 4. No se contempla la ejecución ni entrega de salidas del comando `varnishgather` sobre la plataforma actual como información adicional de licitación. La información de referencia disponible para el dimensionamiento es la incluida en los pliegos, incluyendo los requisitos técnicos mínimos, los esquemas de carga de trabajo por vertical y las obligaciones de monitorización de la capa de caché.

RTVE no puede garantizar en fase de licitación la disponibilidad ni la reserva de capacidad de las líneas asociadas al expediente anterior S-01421-2021 para su uso por el nuevo adjudicatario durante la migración. No obstante, durante la fase de planificación de la migración, y siempre que sea técnicamente viable, no afecte al servicio productivo ni a las obligaciones vigentes con el proveedor actual, RTVE podrá facilitar la coordinación necesaria para analizar el uso parcial y temporal de la conectividad existente. En todo caso, el adjudicatario deberá dimensionar y prever en su oferta los canales de comunicación necesarios para la migración, siendo responsable último de su provisión conforme al requisito RS.M.5. En caso de autorizarse dicho uso parcial de líneas existentes, su duración quedaría limitada estrictamente al periodo necesario para la migración y, como máximo, al plazo previsto para dicha fase en el pliego, esto es, 12 semanas, sin perjuicio de que las ventanas concretas, caudales disponibles y condiciones operativas deban acordarse durante la ejecución del proyecto y coordinarse con RTVE y con el proveedor saliente.

A efectos de acreditar la solvencia técnica exigida en el PCAP, ésta se ajustará a lo establecido expresamente en el pliego. En consecuencia, únicamente se considerarán trabajos similares aquellos que cumplan la definición prevista en la cláusula de solvencia técnica: servicios de almacenamiento y cómputo para distribución de contenido en Internet, prestados a entidades con al menos 5.000 puestos de trabajo, con cobertura nacional y con una duración mínima de 3 años. Por tanto, las referencias relativas a proyectos de almacenamiento y cómputo de altas prestaciones que no estén orientados específicamente a la distribución de contenidos en Internet no podrán computarse, por sí solas, como trabajos similares a efectos de acreditar la solvencia técnica requerida, aunque presenten complejidad tecnológica, criticidad operativa o requisitos de disponibilidad equivalentes. Sin perjuicio de lo anterior, el licitador podrá aportar dichas experiencias como información complementaria de contexto, pero la acreditación de la solvencia técnica deberá realizarse mediante referencias que se ajusten a la definición indicada en el PCAP.

Se admitirán soluciones tecnológicas equivalentes siempre que se acredite de forma suficiente, verificable y documentada que cumplen todos los requisitos funcionales, técnicos, de rendimiento, disponibilidad, resiliencia, integración y operación exigidos en el pliego

El requisito relativo a conectividad 25GB RoCE o superior debe interpretarse como una exigencia mínima orientada a garantizar baja latencia, alto rendimiento, integración con la arquitectura de red definida y capacidad suficiente para las cabinas SSD NVMe. No obstante, podrán admitirse soluciones basadas en tecnologías alternativas o equivalentes, siempre que el licitador justifique técnica y documentalmente que la solución propuesta proporciona prestaciones iguales o superiores a las exigidas en el pliego y no limita ninguna de las funcionalidades requeridas para la plataforma.

No se requiere que la propuesta se integre con IBM Storage Protect ni que dicha plataforma actúe como elemento de orquestación del backup. La solución ofertada deberá incluir todos los mecanismos necesarios para la realización, gestión, monitorización y recuperación de las copias de seguridad dentro del alcance de la licitación actual, de forma autónoma e independiente de las soluciones corporativas de backup que RTVE pueda tener actualmente desplegadas.

Se confirma que la expresión «sin necesidad de plataformas adicionales (gateways)» debe interpretarse en el sentido de excluir arquitecturas que dependan de pasarelas externas, appliances de traducción de protocolo, componentes de terceros no integrados, desarrollos ad hoc no soportados oficialmente o repositorios separados que obliguen a copiar, mover o sincronizar datos para poder prestar los servicios de fichero u objeto S3. No obstante, dicha expresión no excluye el uso de componentes propios de la solución de almacenamiento, oficialmente soportados por el fabricante e integrados como parte de la arquitectura ofertada, siempre que no constituyan una plataforma adicional independiente ni un gateway externo a la solución de almacenamiento.

Podrá considerarse conforme una solución en la que el almacenamiento en bloque sea proporcionado por cabinas enterprise y los servicios de fichero y objeto S3 sean prestados por componentes integrados de la propia solución de almacenamiento, siempre que el licitador acredite en su oferta que: - la solución cumple todos los requisitos mínimos de la capa de almacenamiento; - el conjunto de almacenamiento ofertado permite el consumo en bloque, fichero y objeto S3 de forma nativa por VMware, OpenShift y las aplicaciones de la plataforma, según corresponda; - no se emplean gateways externos, pasarelas de traducción de protocolo ni appliances ajenos a la solución; - no se requieren copias, movimientos o sincronizaciones entre repositorios separados para exponer los datos por fichero u objeto; - todos los componentes están oficialmente soportados por el fabricante durante toda la vigencia del contrato; - se mantienen los requisitos de alta disponibilidad, ausencia de punto único de fallo, rendimiento, escalabilidad, protección de datos y operación exigidos en el pliego. La conformidad final de la solución se evaluará sobre la oferta técnica concreta presentada por el licitador, atendiendo a su arquitectura, documentación de fabricante, modelo de soporte, integración real con VMware y OpenShift, y evidencias de cumplimiento de los requisitos mínimos exigidos.

Se les informa que se ha ampliado el plazo para la presentación de ofertas hasta el viernes día 26 de junio a las 14:00h (horario peninsular español).