> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/es/pam/deploy-operate/requirements.md). # 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](/es/pam/deploy-operate/network-requirements.md). Para los puertos que se usan para alcanzar *activos*, consulte [Puertos y protocolos](/es/pam/reference/ports.md). {% hint style="warning" %} 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. {% endhint %} ## 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 | {% hint style="warning" %} 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. {% endhint %} 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 | {% hint style="danger" %} 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. {% endhint %} ## 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](/es/pam/deploy-operate/install-cluster.md) 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](/es/pam/deploy-operate/network-requirements.md) * [Instalar un nodo único](/es/pam/deploy-operate/install-single-node.md) * [Instalar un clúster de alta disponibilidad](/es/pam/deploy-operate/install-cluster.md) * [Puertos y protocolos](/es/pam/reference/ports.md) * [Conceptos esenciales](/es/pam/get-started/core-concepts.md)