Problemas conocidos
Esta sección describe problemas conocidos de imágenes públicas en diferentes plataformas. Las imágenes privadas también tienen estos problemas.
Desconexión de red causada por un arrendamiento DHCP de Windows Server de más de 99 días
Síntoma:
Si la concesión DHCP es superior a 99 días, las direcciones IP de instancia no se pueden renovar automáticamente. Como resultado, la red de instancia se desconectará cuando la concesión llegue a su fin. Es un problema conocido del servicio cliente DHCP de Windows Server 2008.
Imágenes involucradas:
Imágenes públicas y privadas de Windows Server 2008, Windows Server 2012 R2, Windows Server 2016 y Windows Server 2019
Solución:
- Cambie la concesión DHCP de la subred donde se encuentra la instancia a un día o ilimitada.
- Ejecute el siguiente comando para hacer que el cambio surta efecto:
El siguiente comando le desconectará temporalmente de la red. Hágalo durante las horas no pico.
ipconfig /renew
Errores ocasionales del sistema desencadenados al agregar o eliminar NIC
Síntoma:
Después de iniciar un ECS, agregar o eliminar una NIC u otras acciones equivalentes puede:
- Activa un pánico del kernel y el sistema operativo se reinicia automáticamente.
- Activar interrupciones frecuentes de software, y la red puede no recibir o enviar paquetes.
Enlace de parche:https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=f00e35e259948b995aa1f3ee7fddb05f34a50157
Imágenes involucradas:
Imágenes públicas y privadas de CentOS 7
Solución:
Actualice el kernel a una versión que coincida con el kernel 3.10.0-1160.25.1.e17.x86_64 de CentOS 7.
Los núcleos se desconectan ocasionalmente de la red TCP
Síntoma:
Este problema se debe a la vulnerabilidad del kernel CVE-2019-11477 (TCP SACK). Cuando la memoria intermedia de socket está baja, la red puede desconectarse.
Las imágenes involucradas se enumeran en la siguiente tabla.
Tipo de imagen |
Versión del núcleo |
---|---|
CentOS 7 imágenes públicas del 26/06/2019 al 29/09/2019 |
3.10.0-957.21.3.e17.x86_64 |
Ubuntu 16 y Ubuntu 18 imágenes públicas de 2019-06-26 a 2019-10-15 |
Ubuntu 16.04: 4.4.0-151-genric Ubuntu 18.04: 4.15.0-52-generic |
Imágenes públicas de Debian 9.0 del 26/06/2019 al 15-10/2019 |
4.9.0-9-amd64 |
Imágenes públicas de Fedora 29 y openSUSE 15.0 del 27/06/2019 al 15-10/2019 |
Fedora 29: 5.1.11-200.fc29.x86_64 openSUSE 15.0: 4.12.14-1p150.12.64-predeterminado |
Solución:
Actualice el núcleo a la última versión. Ejecute los siguientes comandos para actualizar el núcleo de cada tipo de imagen:
- CentOS/Fedora: yum update kernel
- Ubuntu: apt-get update && apt-get install linux-image-generic
- openSUSE: zypper refresh && zypper install kernel-default
- Debian: apt-get update && apt search linux-image && apt-get install linux-image-xxx
Puede ejecutar el comando apt search linux-image para consultar la última versión del núcleo. El comando apt-get install linux-image-xxx se utiliza para actualizar un núcleo a la última versión.
La configuración del parámetro del sistema operativo no tiene efecto
Síntoma:
Después de configurar net.ipv4.tcp_max_tw_buckets en el archivo /etc/sysctl.conf, el resultado de la comprobación de sysctl -a indica que la configuración no tiene efecto. Las configuraciones en /etc/sysctl.d/huawei.conf y /etc/security/limits.d/huawei-nofile.conf se han construido en imágenes públicas y estas configuraciones tienen prioridades más altas que las de /etc/sysctl.conf. Como resultado, las configuraciones en /etc/sysctl.conf no tienen efecto.
Los parámetros implicados se enumeran en la siguiente tabla.
Parámetro |
Archivo de configuración |
---|---|
vm.swappiness net.core.somaxconn net.ipv4.tcp_max_tw_buckets net.ipv4.tcp_max_syn_backlog |
/etc/sysctl.d/huawei.conf |
* soft nofile 65535 * hard nofile 65535 |
/etc/security/limits.d/huawei-nofile.conf |
Imágenes involucradas:
- Imágenes públicas de CentOS 7 del 25-09-2018 al 29-09-2019
- Imágenes públicas de CentOS 6 desde 2018-09-25 hasta 2019-10-10
- Imágenes públicas de Ubuntu, openSUSE 15.0, Debian y Fedora 29 del 28-09-2018 al 15-10-2019
Solución:
- Elimine los archivos de configuración integrados.
rm -rf /etc/sysctl.d/huawei.conf
rm -rf /etc/security/limits.d/huawei-nofile.conf
- Modifique los archivos de configuración de parámetros del núcleo (limits.conf y sysctl.conf).
cat >>/etc/security/limits.conf <<EOF
root soft nofile 65535
root hard nofile 65535
* soft nofile 65535
* hard nofile 65535
EOF
cat >>/etc/sysctl.conf <<EOF
vm.swappiness=0
net.core.somaxconn=1024
net.ipv4.tcp_max_tw_buckets=5000
net.ipv4.tcp_max_syn_backlog=1024
EOF
La instancia de descarga basada en NIC 1822 es incompatible con el kernel de Linux 3.16.x
Síntoma:
Los ECS que utilizan la función de descarga de hardware proporcionada por la NIC inteligente de alta velocidad de 25GE desarrollada por Huawei pueden ser incompatibles con los sistemas operativos Linux 3.16.47-3.16.x, lo que puede causar desconexiones ocasionales de red de los ECS. Los ECS que tienen este problema incluyen pero no se limitan a C3ne, M3ne, C6, M6, G5, P2v, G5r, P2vs, P2s, Pi2, FP1cn1, Ai1, e3.26xlarge.14, e3.52xlarge.14, e3.52xlarge.20, KC1 y KM1.
Imágenes involucradas:
Imágenes públicas de Debian 8.2.0 64bit y Debian 8.8.0
Solución:
Elimine las imágenes públicas de Debian 8 de las normas. Migre los servicios de los ECS utilizando esta función de descarga a los ECS S3 y C3 tan pronto como sea posible.
Los datos se pierden durante el restablecimiento del disco debido a la incompatibilidad entre el administrador del servidor de Windows Server 2012 R2 y VMTools
Síntoma:
Un ECS de Windows Server 2012 R2 se configura con dos discos de datos. Cuando Windows Server Manager restablece el segundo disco de datos, se restablece el primer disco de datos. Como resultado, se pierden los datos del primer disco de datos.
Imágenes involucradas:
Imagen pública de Windows Server 2012 R2 antes de 2019-02-19
Solución:
Actualizce VMTools de ECS involucrados a 2.5.0.156 o posterior.
Interrupciones de servicio causadas por conexiones persistentes CLOSE_WAIT
Síntoma:
Algunos servicios se interrumpen porque un socket en una conexión TCP creado por el proceso del plug-in de restablecimiento de contraseña de un solo clic permanece en el estado CLOSE_WAIT.
Imágenes involucradas:
- Imágenes públicas de CentOS y EulerOS emitidas antes del 5 de junio de 2019
- Imágenes públicas de Ubuntu y Debian publicadas antes del 3 de junio de 2019
Solución:
Actualice los complementos de restablecimiento de contraseña con un solo clic para los ECS.