Citrix ADC

Tabla de compatibilidad y pautas de uso

January 12, 2021

Contribuido por:

En este documento se enumeran los diferentes hipervisores y funciones compatibles con una instancia de Citrix ADC VPX, sus pautas de uso y las limitaciones conocidas.

Tabla 1. Instancia VPX en Citrix Hypervisor

Versión del Citrix Hypervisor	SysID	Modelos VPX
8.2 soportado 13.0 64.x en adelante, 8.0, 7.6, 7.1	450000	VPX 10, VPX 25, VPX 200, VPX 1000, VPX 3000, VPX 5000, VPX 8000, VPX 10G, VPX 15G, VPX 25G, VPX 40G

Tabla 2. instancia VPX en el servidor VMware ESX

Versión de VMware ESX	SysID	Modelos VPX
Número de compilación de ESX 7.0 16324942 (compatible con Citrix ADC versión 13.0 compilación 71.x en adelante). 6.0, números de compilación 3620759, 5050593 (compatible con Citrix ADC versión 12.0 compilación 51.24 en adelante), 6765062 (compatible con Citrix ADC versión 12.0 compilación 56.20 en adelante). 6.5, números de compilación 4564106 y parche 67591 6.7, número de compilación 8941472, 13006603 (compatible con Citrix ADC versión 13.0 compilación 47.24 en adelante) ESXi 6.7 actualización 3, número de compilación 14320388 (compatible con la versión 13.0 de Citrix ADC versión 58.9).	450010	VPX 10, VPX 25, VPX 200, VPX 1000, VPX 3000, VPX 5000, VPX 8000, VPX 10G, VPX 15G, VPX 25G, VPX 40G, VPX 100G

Tabla 3. VPX en Microsoft Hyper-V

Versión de Hyper-V	SysID	Modelos VPX
2012, 2012 R2, 2016, 2019	450020	VPX 10, VPX 25, VPX 200, VPX 1000, VPX 3000, VPX 8000

Tabla 4. Instancia VPX en KVM genérico

Versión KVM genérica	SysID	Modelos VPX
RHEL 7.4, RHEL 7.5 (de Citrix ADC versión 12.1 50.x en adelante), RHEL 7.6, RHEL 8.0, Ubuntu 16.04, Ubuntu 18.04, RHV 4.2	450070	VPX 10, VPX 25, VPX 200, VPX 1000, VPX 3000, VPX 5000, VPX 8000, VPX 10G, VPX 15G. VPX 25G, VPX 40G, VPX 100G

Puntos a tener en cuenta: Mantenga los siguientes puntos en mente mientras utiliza hipervisores KVM.

La instancia VPX está calificada para las versiones de versión de Hypervisor mencionadas en la tabla 1—4, y no para las versiones de parche de una versión. Sin embargo, se espera que la instancia de VPX funcione sin problemas con las versiones de parches de una versión compatible. Si no lo hace, registre un caso de soporte técnico para la solución de problemas y la depuración.
Antes de utilizar RHEL 7.6, realice los siguientes pasos en el host KVM:
1. Modifique /etc/default/grub y agregue "kvm_intel.preemption_timer=0" a la variable GRUB_CMDLINE_LINUX.
2. Regenerar grub.cfg con el comando "# grub2-mkconfig -o /boot/grub2/grub.cfg".
3. Reinicie el equipo host.
Antes de usar Ubuntu 18.04, complete los siguientes pasos en el host KVM:
1. Modifique /etc/default/grub y agregue "kvm_intel.preemption_timer=0" a la variable GRUB_CMDLINE_LINUX.
2. Regenerar grub.cfg con el comando "# grub-mkconfig -o /boot/grub/grub.cfg “.
3. Reinicie el equipo host.

Tabla 5. Instancia VPX en AWS

Versión de AWS	SysID	Modelos VPX
N/D	450040	VPX 10, VPX 200, VPX 1000, VPX 3000, VPX 5000, VPX BYOL (VPX 8000, VPX 10G, VPX 15G y VPX 25G solo están disponibles con BYOL con tipos de instancia EC2 (C5, M5 y C5n)

Tabla 6. Instancia de VPX en Azure

Versión de Azure	SysID	Modelos VPX
N/D	450020	VPX 10, VPX 200, VPX 1000, VPX 3000, VPX BYOL

Tabla 7. Tabla de funciones VPX

Función VPX

*La compatibilidad con clústeres está disponible en SRIOV para interfaces orientadas al cliente y al servidor y no para el backplane.

Los eventos de**interfaz DOWN no se registran en instancias de Citrix ADC VPX.

Para LA estática, es posible que aún se envíe tráfico en la interfaz cuyo estado físico sea DOWN.

Para LACP, el dispositivo del mismo par conoce el evento DOWN de la interfaz basado en el mecanismo de tiempo de espera de LACP.

Tiempo de espera corto: 3 segundos

Tiempo de espera largo: 90 segundos

Para LACP, no comparta interfaces entre máquinas virtuales.

Para el enrutamiento dinámico, el tiempo de convergencia depende del Protocolo de enrutamiento, ya que no se detectan eventos de vínculo.

La funcionalidad de ruta estática supervisada falla si los monitores no están enlazados a rutas estáticas, ya que el estado de ruta depende del estado de la VLAN. El estado de la VLAN depende del estado del vínculo.

La detección parcial de fallas no ocurre en alta disponibilidad si hay fallas en el enlace. Una condición cerebral dividida de alta disponibilidad podría ocurrir si hay falla en el enlace.

***Cuando se genera un evento de enlace (inhabilitar/habilitar, reset) a partir de una instancia VPX, el estado físico del enlace no cambia. Para LA estática, cualquier tráfico iniciado por el par se elimina en la instancia.

Para LACP, el dispositivo de par conoce el evento DOWN de la interfaz basado en el mecanismo de tiempo de espera LACP.

Tiempo de espera corto: 3 segundos

Tiempo de espera largo: 90 segundos

Para LACP, las interfaces no deben compartirse entre máquinas virtuales.

Para que funcione la función de etiquetado de VLAN, haga lo siguiente:

En VMware ESX, establezca el ID de VLAN del grupo de puertos en 1—4095 en el vSwitch del servidor VMware ESX. Para obtener más información acerca de cómo configurar un ID de VLAN en el vSwitch del servidor VMware ESX, consulte Soluciones VLAN 802.1Q de VMware ESX Server 3.

Tabla 8. Exploradores web compatibles

Sistema operativo	Explorador y versiones
Windows 7	Internet Explorer- 8, 9, 10 y 11; Mozilla Firefox 3.6.25 y superior; Google Chrome- 15 y superior
Windows de 64 bits	Internet Explorer: 8, 9; Google Chrome: 15 y superior
MAC	Mozilla Firefox: 12 y superior; Safari: 5.1.3; Google Chrome: 15 y superior

Pautas de uso

Siga estas pautas de uso:

Consulte la sección Consideraciones de CPU de VMware ESXi en el documento Prácticas recomendadas de performance para VMware vSphere 6.5. Aquí hay un extracto:

No se recomienda que las máquinas virtuales con alta demanda de CPU/memoria se instalen en un Host/Cluster que esté sobrecomprometido.

En la mayoría de los entornos, ESXi permite niveles significativos de compromiso excesivo de CPU sin afectar el rendimiento de la máquina virtual. Es decir, en un host, puede ejecutar más vCPU que el número total de núcleos de procesador físicos en ese host.

Si un host ESXi se vuelve saturado de CPU (es decir, las máquinas virtuales y otras cargas en el host exigen todos los recursos de CPU que tiene el host), es posible que las cargas de trabajo sensibles a la latencia no funcionen bien. En este caso, es posible que quiera reducir la carga de la CPU, por ejemplo apagando algunas máquinas virtuales o migrándolas a un host diferente (o permitiendo que DRS las migre automáticamente).
Citrix ADC VPX es un dispositivo virtual de alto rendimiento y sensible a la latencia. Para ofrecer el rendimiento esperado, el dispositivo requiere reserva de vCPU, reserva de memoria, fijación de vCPU en el host. Además, el hipersubproceso debe estar inhabilitado en el host. Si el host no cumple estos requisitos, se producen problemas como conmutación por error de alta disponibilidad, picos de CPU dentro de la instancia VPX, lentitud en el acceso a la CLI de VPX, caída del demonio pitboss, caídas de paquetes y bajo rendimiento.
Un Hypervisor se considera sobreaprovisionado si se cumple una de las dos condiciones siguientes:
- El número total de núcleos virtuales (vCPU) aprovisionados en el host es mayor que el número total de núcleos físicos (PCPU).
- El número total de máquinas virtuales aprovisionadas consume más VCPU que el número total de PCPU.
  
  A veces, si una instancia está sobreaprovisionada, es posible que el Hypervisor no pueda garantizar los recursos reservados (como CPU, memoria y otros) para la instancia debido a problemas generales de programación del Hypervisor o errores o limitaciones con el Hypervisor. Esto puede causar la falta de recursos de CPU para Citrix ADC y puede provocar problemas mencionados en el primer punto bajo Pautas de uso. Como administradores, se recomienda reducir el alquiler en el host para que el número total de vCPU aprovisionadas en el host sea menor o igual al número total de PCPU.
  
  Ejemplo
  
  Para el Hypervisor ESX, si el parámetro %RDY% de una vCPU VPX es mayor que 0 en la salida del comando esxtop, se dice que el host ESX tiene gastos generales de programación, lo que puede causar problemas relacionados con la latencia para el VPX.
  
  En tal situación, reduzca el arrendamiento en el host para que %RDY% vuelva a 0 siempre. Alternativamente, póngase en contacto con el proveedor del Hypervisor para seleccionar el motivo por el que no se ha cumplido la reserva de recursos realizada.
La adición en caliente solo se admite para interfaces PV y SRIOV con Citrix ADC en AWS. Las instancias VPX con interfaces ENA no admiten conexión en marcha, y el comportamiento de las instancias puede ser impredecible si se intenta conectar en marcha.
La eliminación en caliente a través de la consola Web de AWS o de la interfaz CLI de AWS no es compatible con las interfaces PV, SRIOV y ENA para Citrix ADC. El comportamiento de las instancias puede ser impredecible si se intenta eliminar en caliente.
Puede utilizar dos comandos (set ns vpxparam y show ns vpxparam) para controlar el comportamiento de uso de CPU del motor de paquetes (no de administración) de instancias VPX en entornos hipervisualizados y en la nube:
- set ns vpxparam [-cpuyield (YES | NO | DEFAULT)] [-masterclockcpu1 (YES | NO)]
  
  Permitir que cada máquina virtual utilice recursos de CPU que se hayan asignado a otra máquina virtual pero que no se estén usando.
  
  Establecer los parámetros ns vpxparam:
  
  -cpuyield: Libere o no libere recursos de CPU asignados pero no utilizados.
  
  SÍ: Permitir que otra VM utilice recursos de CPU asignados pero no utilizados.
  
  NO: Reserve todos los recursos de CPU para la máquina virtual a la que se han asignado. Esta opción muestra un porcentaje mayor en entornos de Hypervisor y nube para el uso de CPU VPX.
  
  DETERMINADO: No.
  
  Nota
  
  En todas las plataformas Citrix ADC VPX, el uso de vCPU en el sistema host es del 100%. Escriba el comando set ns vpxparam –cpuyield YES para anular este uso.
  
  -masterclockcpu1: Puede mover el origen del reloj maestro de CPU0 (CPU de administración) a CPU1. Este parámetro tiene las siguientes opciones:
  
  SÍ: Permitir que VM mueva el origen del reloj maestro de CPU0 a CPU1.
  
  NO: VM usa CPU0 para el origen del reloj maestro. De forma predeterminada, CPU0 es el origen del reloj maestro.
- show ns vpxparam
  
  Muestra la configuración actual de vpxparam.

Para obtener información sobre los productos Citrix Ready, visite Citrix Ready Marketplace.

Para obtener asistencia técnica del producto Citrix Ready, consulte la sección de página de preguntas frecuentes.

La versión oficial de este contenido está en inglés. Para mayor comodidad, parte del contenido de la documentación de Citrix solo tiene traducción automática. Citrix no puede controlar el contenido con traducción automática, que puede contener errores, imprecisiones o un lenguaje inadecuado. No se ofrece ninguna garantía, ni implícita ni explícita, en cuanto a la exactitud, la fiabilidad, la idoneidad o la precisión de las traducciones realizadas del original en inglés a cualquier otro idioma, o que su producto o servicio de Citrix se ajusten a cualquier contenido con traducción automática, y cualquier garantía provista bajo el contrato de licencia del usuario final o las condiciones de servicio, o cualquier otro contrato con Citrix, de que el producto o el servicio se ajusten a la documentación no se aplicará en cuanto dicha documentación se ha traducido automáticamente. Citrix no se hace responsable de los daños o los problemas que puedan surgir del uso del contenido traducido automáticamente.

Tabla de compatibilidad y pautas de uso

January 12, 2021

Contribuido por:

January 12, 2021

Contribuido por:

En este artículo

Pautas de uso