Impacto en el rendimiento de Kerberos en los volúmenes NFS v4.1 de Azure NetApp Files
Azure NetApp Files admite el cifrado de cliente NFS en los modos de Kerberos (krb5, krb5i y krb5p) con el cifrado AES-256. En este artículo se describe el impacto en el rendimiento de Kerberos en los volúmenes de NFS v4.1. Las comparaciones de rendimiento a las que se hace referencia en este artículo se realizan en relación con el parámetro de seguridad sec=sys
, realizando pruebas en un único volumen con un solo cliente.
Opciones de seguridad disponibles
Las opciones de seguridad disponibles actualmente para los volúmenes de NFSv4.1 son las siguientes:
- sec=sys usa UID y GID de UNIX locales mediante AUTH_SYS para autenticar las operaciones de NFS.
- sec=krb5 usa la versión 5 de Kerberos en lugar de los UID y GID de UNIX locales para autenticar a los usuarios.
- sec=krb5i usa la versión 5 de Kerberos para la autenticación de usuarios y realiza la comprobación de la integridad de las operaciones de NFS con sumas de comprobación seguras para evitar la manipulación de datos.
- sec=krb5p usa la versión 5 de Kerberos para la autenticación de usuarios y la comprobación de la integridad. Cifra el tráfico de NFS para evitar el examen del tráfico. Esta opción es la más segura, pero también implica la mayor sobrecarga en el rendimiento.
Vectores de rendimiento probados
En esta sección se describe el impacto en el rendimiento del cliente único de las diversas opciones de sec=*
.
- El impacto en el rendimiento se probó en dos niveles: baja simultaneidad (baja carga) y alta simultaneidad (límites superiores de E/S y rendimiento).
- Se probaron tres tipos de cargas de trabajo:
- Lectura/escritura aleatoria de operación pequeña (mediante FIO)
- Lectura/escritura secuencial de operación grande (mediante FIO)
- Carga de trabajo pesada de metadatos generada por aplicaciones como Git
Impacto en el rendimiento esperado
Hay dos áreas de enfoque: carga ligera y límite superior. En las listas siguientes se describe la configuración de seguridad del impacto de rendimiento por configuración de seguridad y escenario por escenario.
Ámbito de la prueba
- Todas las comparaciones se realizan en relación con el parámetro de seguridad
sec=sys
. - La prueba se realizó en un único volumen con un solo cliente.
Impacto en el rendimiento de krb5:
- El promedio de IOPS disminuyó en un 53 %
- El rendimiento medio disminuyó en un 53 %
- Latencia media aumentada en 0,2 ms
Impacto en el rendimiento de krb5i:
- El promedio de IOPS disminuyó en un 55 %
- El rendimiento medio disminuyó en un 55 %
- La latencia media aumentó en 0,6 ms
Impacto en el rendimiento de krb5p:
- El promedio de IOPS disminuyó en un 77 %
- El rendimiento medio disminuyó en un 77 %
- La latencia media aumentó en 1,6 ms
Consideraciones de rendimiento con nconnect
No se recomienda utilizar las opciones de montaje nconnect
y sec=krb5*
juntas. Se ha observado una degradación del rendimiento al usar las dos opciones en combinación.
La interfaz de programación de aplicaciones del estándar de seguridad genérico (GSS-API) proporciona una manera de que las aplicaciones protejan los datos enviados a aplicaciones del mismo nivel. Estos datos se pueden enviar desde un cliente de una máquina a un servidor en otro equipo.
Cuando nconnect
se usa en Linux, el contexto de seguridad de GSS se comparte entre todas las conexiones nconnect
a un servidor determinado. TCP es un transporte confiable que admite la entrega de paquetes desordenados para tratar paquetes desordenados en un flujo GSS, mediante una ventana deslizante de números de secuencia. Cuando se reciben paquetes que no están en la ventana de secuencia, se descarta el contexto de seguridad y se negocia un nuevo contexto de seguridad. Todos los mensajes enviados con en el contexto ahora descartado ya no son válidos, por lo que es necesario volver a enviar los mensajes. Un mayor número de paquetes en una configuración de nconnect
provoca frecuentes paquetes fuera de la ventana, desencadenando el comportamiento descrito. No se pueden indicar porcentajes de degradación específicos con este comportamiento.
Pasos siguientes
Comentarios
https://aka.ms/ContentUserFeedback.
Próximamente: A lo largo de 2024 iremos eliminando gradualmente las Cuestiones de GitHub como mecanismo de retroalimentación para el contenido y lo sustituiremos por un nuevo sistema de retroalimentación. Para más información, consulta:Enviar y ver comentarios de