Documentación de productos
Citrix Virtual Apps and Desktops
Servicio Versión actual 2607 LTSR 2511 2507 LTSR 2503 2411 2407 2402 LTSR 2311 2203 LTSR
Ver PDF

Preguntas frecuentes

August 28, 2026
Contribución de: 
C

  1. ¿Cómo puedo comprobar las configuraciones del servidor de registros en ejecución, como MAX_RESERVE_DAYS?

    Puede comprobar los valores del entorno del contenedor utilizando cualquiera de los siguientes comandos:

    docker inspect logserver |findstr MAX_RESERVE_DAYS O comprobando el entorno del contenedor: docker exec -it logserver env |grep MAX_RESERVE_DAYS

    Si no se devuelve nada, significa que el servidor de registros está utilizando el valor predeterminado: MAX_RESERVE_DAYS=7

  2. ¿Necesito comprar licencias de Docker Desktop al instalar la imagen del contenedor del servidor de registros en Windows?

    Sí. Se requiere una licencia válida de Docker Desktop.

  3. ¿Debo usar un servidor nuevo para la instalación del servidor de registros?

    Sí. Se recomienda utilizar un servidor dedicado para la instalación del servidor de registros para garantizar el rendimiento y el aislamiento.

  4. ¿Cuál es la capacidad de ingesta sostenida de un único servidor de registros AOT? ¿Cuáles son los límites máximos y seguros de eventos por segundo (EPS)?

    Un único servidor de registros AOT admite una capacidad de ingesta sostenida de 10 000 eventos por segundo (EPS). Este valor representa tanto el máximo como el umbral de funcionamiento seguro para la ingesta continua.

  5. ¿Cuántos componentes puede manejar un único servidor de registros AOT? ¿Hay un límite máximo?

    Un único servidor de registros puede conectar hasta 128 000 componentes, pero solo puede procesar unos 10 000 registros por segundo. Por lo tanto, el número de máquinas rara vez es el problema; el factor de dimensionamiento real es la cantidad de registros que generan sus usuarios durante la actividad máxima.

  6. ¿Cuál es la tolerancia a ráfagas del servidor de registros AOT? ¿Cuánto pico repentino de registros puede manejar sin pérdidas o incumplimiento de la acumulación?

    El servidor de registros AOT puede manejar ráfagas a corto plazo de hasta 2 veces la tasa de eventos normal sin perder registros. Si el volumen de registros supera este límite (por ejemplo, 5 veces), el sistema no podrá conservar los eventos de forma fiable y OpenSearch comenzará a descartar registros porque no puede indexarlos lo suficientemente rápido.

  7. ¿Puede el Servidor de registros AOT comprimir registros? ¿Qué relación de compresión deberíamos esperar?

    Sí. El Servidor de registros AOT utiliza el algoritmo de compresión LZ4 predeterminado para almacenar registros en OpenSearch. La relación de compresión típica es de aproximadamente 2:1, lo que significa que los datos de registro se reducen a menos de la mitad de su tamaño original, manteniendo un rendimiento rápido de lectura/escritura.

  8. Para cada tipo de infraestructura (local de un solo sitio, local de varios sitios, nube de una sola región, nube de varias regiones, híbrido, MSP/inquilino), ¿dónde debería implementarse el Servidor de registros AOT y por qué?

    El Servidor de registros AOT siempre debe implementarse en la misma línea de visión que los VDA. Esto garantiza una conectividad estable y ayuda a mantener una baja latencia entre los componentes que generan registros y el servidor de registros que los ingiere. Siempre que cada componente (VDA, DDC, StoreFront, Gateway, etc.) pueda alcanzar el servidor de registros de forma fiable, el entorno funcionará correctamente.

  9. ¿Necesitamos un servidor de registros por región, o se puede centralizar todo? ¿Qué pasa con la latencia y la salida de datos?

    Puede centralizar el servidor de registros, pero los clientes deben evaluar las implicaciones de la latencia y el costo de salida de datos para su entorno. La latencia entre regiones puede afectar la ingesta de registros, especialmente durante períodos de alto volumen. Si la latencia de ida y vuelta es alta, los picos o ráfagas de registros pueden causar retrasos, acumulación de trabajo pendiente o una posible pérdida durante las cargas máximas. Pueden aplicarse cargos por salida de datos cuando los registros cruzan límites regionales o de la nube.

  10. ¿Consume AOT un ancho de banda de red o recursos del sistema significativos?

    No. AOT está diseñado para tener un impacto mínimo en el punto final, el VDA o cualquier componente, y el rendimiento de la red.

    AOT recopila registros continuamente y los carga al Servidor de registros AOT casi en tiempo real a través de HTTPS. Los registros individuales suelen ser muy pequeños (a menudo solo unos pocos kilobytes), lo que ayuda a minimizar la sobrecarga de red durante el funcionamiento normal.

    El ancho de banda total consumido depende del número de sesiones activas, los componentes habilitados y la actividad del entorno. En la mayoría de las implementaciones, el tráfico de registros de AOT representa un porcentaje muy pequeño de la utilización total de la red.

    AOT también utiliza compresión para reducir los requisitos de almacenamiento y optimizar la transferencia de datos al Servidor de registros.

  11. ¿Cuáles son las especificaciones mínimas de hardware para admitir 1.000 máquinas con el Servidor de registros AOT?

    Para entornos con hasta 1.000 máquinas, necesita: 1 nodo (Servidor de registros + OpenSearch combinados), 4 vCPU, 8 GB de RAM, 2.000 IOPS mínimo (SSD o NVMe recomendado), NIC de 1 Gbps. Esta configuración es adecuada para implementaciones pequeñas o de un solo sitio con un volumen de registros moderado.

  12. ¿Cómo puedo solucionar problemas si hay un problema con el Servidor de registros?

    LogServer se ejecuta como un contenedor de Docker, por lo que todos los comandos de Docker podrían usarse para encontrar los problemas:

    docker logs logserver
docker inspect logserver
<!--NeedCopy-->

    Y además, el usuario podría conectarse al contenedor en ejecución y ver los registros del propio logserver:

    docker exec –it logserver bash
<!--NeedCopy-->

    En el shell bash del contenedor docker de logserver, el usuario puede verificar el estado de logserver y opensearch:

    curl http://localhost:5000/Ping
curl http://localhost:9200/_cluster/health?pretty
<!--NeedCopy-->

    Y comprobar los registros dentro del contenedor:

    tail Config/applogs.txt
tail Config/weblogs.txt
<!--NeedCopy-->

    Si necesita más registros, el usuario puede modificar LOG_LEVEL=0 en StartLogServer.sh/StartLogServer.bat y reiniciar el logserver mediante estos archivos de script. Entonces, los registros detallados incluirán todos los niveles: TRACE, DEBUG, INFO, WARN, ERROR.

  13. Recuperarse de un disco de almacenamiento del servidor de registros desasociado incorrectamente

    Si quita o desasocia el disco de almacenamiento del servidor de registros directamente del hipervisor o del proveedor de la nube sin desasociarlo primero de la interfaz de usuario de administración de Citrix Connector Appliance, el Connector Appliance conserva la configuración de almacenamiento y asume que el disco sigue conectado. Como resultado, el disco previamente conectado permanece configurado en el Connector Appliance, la conexión de un nuevo disco falla y es posible que vea un error similar a: Ya hay un disco local montado en el proveedor.

    Opción 1 (recomendada): Si el disco original todavía está disponible:

    1. Vuelva a conectar el disco original a la VM de Connector Appliance desde el hipervisor o el proveedor de la nube.

    2. Reinicie el Connector Appliance.

    3. Una vez que el dispositivo se inicie correctamente, desasocie el disco mediante la interfaz de usuario de administración de Connector Appliance.

    4. Ahora puede conectar un nuevo disco si es necesario.

    Opción 2: Si el disco original ya no está disponible, elimine manualmente la configuración de almacenamiento obsoleta ejecutando la siguiente solicitud de API. Recupere un token de autorización y ejecute el comando apropiado:

    Linux:

    curl -X POST "https://<connector-fqdn>/storage/$detach" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <token>" \
-d '{"targetProvider":"logserver-provider","storageType":"local"}'
<!--NeedCopy-->

    Windows:

    curl -X POST "https://<connector-fqdn>/storage/$detach" ^
-H "Content-Type: application/json" ^
-H "Authorization: Bearer <token>" ^
-d "{\"targetProvider\":\"logserver-provider\",\"storageType\":\"local\"}"
<!--NeedCopy-->

    Nota:

    La API puede devolver un error aunque la configuración de almacenamiento obsoleta se haya eliminado correctamente. verificar la configuración de almacenamiento antes de volver a intentar la conexión del disco.

    Como práctica recomendada, desvincule siempre el disco de almacenamiento del servidor de registros de la interfaz de usuario de administración de Connector Appliance antes de quitar o desvincular el disco del hipervisor o proveedor de la nube. Esto garantiza que Connector Appliance limpie su configuración de almacenamiento y evite referencias de almacenamiento obsoletas.

Preguntas frecuentes
August 28, 2026
Contribución de: 
C
August 28, 2026
Contribución de: 
C

En este artículo

Comentarios sobre el sitio | Your privacy choices footer linkSus opciones de privacidad | Condiciones legales y de privacidad | Preferencias de cookies | Parámetros de consentimiento | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.