Requisitos del sistema

Modelos de despliegue, dimensionamiento de la máquina, planificación del almacenamiento y dependencias de plataforma de una instancia de DataDike PAM, con las cifras que publica DataDike y las la

Qué cubre esta página

Lo que una instancia de la solución necesita para funcionar: dónde puede desplegarse, qué tamaño debe tener la máquina, cuánto disco consumirán las grabaciones y de qué servicios de plataforma depende.

Para la conectividad que necesita, consulte Requisitos de red y conectividad. Para los puertos que se usan para alcanzar activos, consulte Puertos y protocolos.

Las cifras de dimensionamiento de más abajo son las publicadas en la ficha técnica de DataDike. Son un punto de partida, no un modelo de capacidad: el almacenamiento, en particular, depende de su propia política de retención y de su mezcla de sesiones. Confirme el dimensionamiento de su despliegue con DataDike antes de comprometer hardware, y confírmelo contra la versión que realmente está desplegando.

Modelos de despliegue

La solución funciona sobre infraestructura x86_64 estándar, en servidores físicos o en máquinas virtuales.

Modelo	Qué significa
On-premises	Desplegada en el centro de datos del propio cliente
Nube privada	VMware, Hyper-V, KVM u OpenStack
Nube pública	AWS, Azure, Google Cloud u Oracle Cloud
Híbrido	Instancia central on-premises, conectores en la nube

La documentación de DataDike OS añade Nutanix y KVM/Proxmox a la lista de hipervisores, y recomienda instalar directamente sobre bare metal, sin virtualización, para obtener el mejor rendimiento.

Dimensionamiento de la máquina

Mínimo: laboratorios, pruebas y prueba de concepto

Recurso	Mínimo
CPU	4 vCPU
Memoria	8 GB de RAM
Almacenamiento	100 GB SSD
Red	1 Gbps
Arquitectura	x86_64
Sistema operativo	Oracle Linux, Ubuntu Server, Red Hat, Debian, DataDike OS

Recomendado para producción

Recurso	Recomendado
CPU	8 vCPU
Memoria	8 a 16 GB de RAM
Almacenamiento	500 GB SSD
Tipo de disco	SSD o NVMe
Red	1 Gbps

Qué empuja esas cifras hacia arriba

El almacenamiento, por encima de todo. La ficha técnica nombra cuatro factores:

• el periodo de retención de las grabaciones de sesión;

• el volumen de registros de auditoría;

• el número de activos gestionados;

• el número de sesiones simultáneas.

Almacenamiento para las grabaciones de sesión

Las grabaciones se comprimen y optimizan antes de almacenarse, tanto en el almacenamiento local como en el almacenamiento de objetos externo. La ficha técnica publica esta media:

Sesiones al día	Almacenamiento al mes
100	~50 GB
500	~250 GB
1000	~500 GB

La fuente no indica la duración de las sesiones, la mezcla de protocolos ni el ajuste de compresión que hay detrás de esas cifras, y las sesiones gráficas (RDP y VNC) consumen mucho más espacio que las de terminal. Trate la tabla solo como un orden de magnitud, y mida su propio consumo durante las primeras semanas de operación.

De ahí se derivan dos puntos operativos:

• El backend de grabación instalado por defecto (default, de tipo Servidor) es disco local en el nodo. No tiene redundancia, consume el disco del propio nodo y no escala. Pase a almacenamiento de objetos externo para producción.

• El ajuste de retención de la consola controla los metadatos de la base de datos, no los archivos. El ciclo de vida real de los archivos de grabación se configura en el bucket o el contenedor que los aloja.

Dependencias de plataforma

Dependencia	Qué dicen las fuentes
Base de datos	Integrada en el appliance, interna a la solución. Los servicios de base de datos gestionados (Amazon RDS, Cloud SQL) aparecen en la ficha técnica como servicios opcionalmente integrables
Redis	Presente en una instancia desplegada: el endpoint de salud informa de su estado y de su tiempo de respuesta junto a los de la base de datos
Almacenamiento de objetos para grabaciones	S3, Ceph, Swift, OSS, Azure, OBS, COS, SFTP, local (Servidor) o descarte (Null)
Almacenamiento de comandos	Guardado por defecto en la base de datos de la propia solución; en su lugar puede configurarse un índice externo como Elasticsearch
Fuente de hora	NTP, o el propio servicio de fecha y hora del sistema operativo del host

El reloj no es un detalle. Los códigos TOTP se validan al segundo, de modo que un nodo con el reloj desviado rechaza cada contraseña de un solo uso con OTP code invalid, or server time error: una caída que parece un fallo de autenticación. Sincronice el reloj y fije la zona horaria correcta antes de entregar la instancia.

Navegadores

El acceso a la consola está soportado en Mozilla Firefox, Google Chrome, Microsoft Edge, Opera y Safari.

Ejemplos de instancia en nube pública

Estos son los tamaños de ejemplo que la ficha técnica publica para cada proveedor. Son ejemplos, no una matriz de soporte.

	AWS	Azure	GCP	OCI
Instancia	EC2 t3.xlarge o m6i.xlarge	D4s_v5 o D8s_v5	n2-standard-4 o n2-standard-8	VM.Standard3.Flex
CPU	4 a 8 vCPU	4 a 8 vCPU	4 a 8 vCPU	2 a 4 OCPU
Memoria	8 a 16 GB	8 a 16 GB	8 a 16 GB	8 a 16 GB
Almacenamiento	EBS SSD (gp3)	Premium SSD	Persistent SSD	Block Volume SSD
Balanceo de carga	AWS Application Load Balancer	Azure Load Balancer	Google Cloud Load Balancer	OCI Load Balancer

Servicios que la ficha técnica lista como opcionalmente integrables, por proveedor:

Proveedor	Servicios
AWS	Amazon RDS, Amazon S3, AWS IAM, AWS Secrets Manager
Azure	Azure AD, Azure Key Vault, Azure Storage
GCP	Google IAM, Cloud Storage, Cloud SQL
OCI	OCI Object Storage, OCI Vault

Escalado y alta disponibilidad

La solución escala horizontalmente. La ficha técnica nombra cuatro estrategias: varios nodos, proxies de sesión distribuidos, base de datos externa y almacenamiento dedicado para las grabaciones.

La alta disponibilidad se ofrece como clúster activo-activo, activo-pasivo o réplica de DR: varios nodos tras una dirección virtual (keepalived), con los datos replicados entre ellos. El acceso sobrevive a la pérdida de un nodo, y la carga de sesiones se distribuye o se redistribuye entre los restantes. La página de disponibilidad declara objetivos de diseño de RTO ≤ 1 hora y RPO ≤ 15 minutos para la arquitectura activo/activo, y redundancia de los componentes de bóveda, de intermediación de sesiones y de consola de administración, para que ninguno de ellos sea un punto único de fallo.

Consulte Instalar un clúster de alta disponibilidad para saber qué implica un despliegue en clúster.

Cómo contrastar una instancia en marcha con estos requisitos

• Consulte el endpoint de salud no autenticado /api/health/. Devuelve un JSON con status, db_status, db_time, redis_status, redis_time y time, lo que demuestra que la base de datos y Redis son alcanzables, y no solo que el servidor web respondió. Esto es lo que debe vigilar un monitor externo.

• Abra Configuración del sistema › Componentes y lea la columna Stat, que muestra el uso de CPU y memoria por componente, y el Load status, que indica Normal, High load o Sin conexión. Los componentes parados en High load son la señal para añadir capacidad, ya sea agrandando el nodo o añadiendo instancias de ese tipo de componente.

• Revise el backend de grabación antes de que la presión de disco lo encuentre a usted: una instancia dejada en el backend local default llena el disco del propio nodo.

Páginas relacionadas

• Requisitos de red y conectividad

• Instalar un nodo único

• Instalar un clúster de alta disponibilidad

• Puertos y protocolos

• Conceptos esenciales