Ser administrador de una base de datos puede ser muy desafiante en momentos en los que tiene que solucionar problemas de rendimiento. El servidor de la base de datos es solo un componente del ecosistema de la aplicación y habitualmente se le culpa por ser el problema de rendimiento. SQL Server es una de esas cajas negras que muchos no entienden, al igual que la SAN y la red. Los administradores de bases de datos de producción que supervisan sus servidores pueden identificar rápidamente si SQL Server se está desempeñando fuera de su línea de base normal; sin embargo, hay dos áreas principales de las que tenemos poca visibilidad:la SAN y la red. Los administradores de bases de datos tienen que trabajar regularmente con otros ingenieros cuando se trata de solucionar problemas de rendimiento que no están directamente relacionados con SQL Server. Podemos rastrear fácilmente el rendimiento del disco al monitorear sys.dm_io_virtual_file_stats , sobre el que escribí en Supervisión de la latencia de lectura/escritura; sin embargo, el seguimiento de los problemas de rendimiento de la red dentro de SQL Server no es tan fácil.
El rendimiento deficiente de la red puede ser un asesino silencioso para el rendimiento de la aplicación y mi experiencia personal ha demostrado que este es el caso en muchas ocasiones. A menudo, una aplicación comenzaba a tener problemas de rendimiento y el ingeniero de aplicaciones decía que el servidor de aplicaciones se ve bien y comienza a señalar con el dedo a la base de datos. Recibía una llamada para ver el servidor de la base de datos y todas las indicaciones mostraban que el servidor de la base de datos estaba en buen estado (¡y aquí es donde ayuda el monitoreo de los indicadores clave de rendimiento y tener una línea de base!). Dado que los equipos de la aplicación y la base de datos decían que todo estaba bien, le pedíamos al equipo de la red que revisara las cosas. El equipo de la red analizaría algunas cosas y también daría todo en claro de su parte. Cada equipo resolvió problemas y revisó sus respectivos sistemas tomó tiempo, mientras tanto, el rendimiento de la aplicación seguía sufriendo. Luego, el problema se intensificaría hasta que se pidiera a todos los equipos que se unieran a un puente de conferencia para solucionar problemas juntos. Eventualmente, alguien iniciaría una prueba de red más profunda y determinaría que teníamos una saturación de puertos, enrutamiento o algún otro problema de red complejo. Unos pocos clics o cambiar algo en su extremo eventualmente resolvería la lentitud de la aplicación.
El problema de red más importante que he encontrado con los clientes generalmente involucra el ancho de banda cuando se realizan copias de seguridad. Muchas organizaciones más grandes están migrando a redes de 10 Gb para la infraestructura principal; sin embargo, cuando se trabaja con redes tanto físicas como virtuales, es fácil configurar incorrectamente una configuración o un puerto y reducirlo a 1 Gb. Para el tráfico regular de la red de aplicaciones, es posible que no note la degradación en el rendimiento; sin embargo, tan pronto como comience a intentar copiar cientos de GB de datos para las copias de seguridad, ese 1 Gb se saturará y sus trabajos de copia de seguridad y restauración se verán afectados.
Para los administradores de bases de datos puede ser un desafío lograr que otros analicen con tanta profundidad los problemas que no creen que sean de su incumbencia porque los indicadores iniciales no revelan el problema. Ser capaz de armarse con datos antes de comunicarse con otros equipos ayudará a involucrarlos. Al utilizar iPerf para realizar una prueba de ancho de banda inicial, puede determinar rápidamente si está obteniendo las velocidades de red que se supone que debe obtener. Por ejemplo, si está utilizando una red de 10 Gb entre el servidor de aplicaciones y el servidor de la base de datos y ejecuta una prueba y solo obtiene 1 Gb, entonces sabe que algo no está del todo bien. Si puede documentar este hallazgo, entonces puede pedir con confianza a sus ingenieros de red que analicen un problema de ancho de banda.
¿Cómo empiezas a usar iPerf? Primero debe descargar la herramienta desde iPerf.fr. Como estoy trabajando en Windows Server 2012, descargué los archivos binarios de Windows en mi máquina. Una vez que descargue y descomprima el paquete, deberá ejecutar el programa desde una línea de comandos. Descargué iPerf 3.0.11, que ha estado disponible durante casi un año. Asegúrese de leer la documentación de esta utilidad. Dado que esta es una herramienta de línea de comandos, hay docenas de opciones que puede usar. En el siguiente ejemplo, solo usaré algunos de ellos; sin embargo, según su situación, es posible que deba usar otras opciones, como especificar el puerto o aumentar el tamaño del paquete. Tenga en cuenta que los comandos de opción distinguen entre mayúsculas y minúsculas.
Para usar iPerf, debe usar al menos dos servidores para probar el ancho de banda. Una vez que haya copiado los archivos binarios en los dos servidores, primero debe iniciar el oyente iPerf en uno de los servidores. Para ello ejecutaré el siguiente comando:
iperf3 -sEste comando ejecuta iPerf en modo servidor y solo permitirá una conexión a la vez.
En el segundo servidor, deberá iniciar iPerf utilizando varias opciones de cliente. Primero vamos a especificar -c para especificar el modo cliente. También usaremos -t para especificar el tiempo para ejecutar cada prueba y -P para especificar el número de conexiones simultáneas a realizar. Queremos especificar múltiples conexiones para que podamos poner una tensión adecuada en la red. Para esta prueba voy a ejecutar el siguiente comando:
iperf3 -c (nombre del servidor o dirección IP del primer servidor) -t 30 -P 10El comando anterior iniciará una prueba de transmisión de 30 segundos con 10 conexiones simultáneas.
Ejecuté esta prueba en dos máquinas virtuales en mi Dell M6800, por lo que no había una red física por la que pasaran estas máquinas virtuales.
Desde el servidor 2 que se conecta al servidor 1, obtuve 7,57 GBytes transferidos con un ancho de banda de 2,17 Gbits/seg. No está mal para un par de máquinas virtuales en una computadora portátil.
Estadísticas de red/salida de iPerf:Servidor 2 conectándose al Servidor 1
Desde el servidor 1 que se conecta al servidor 2, obtuve 6,98 GBytes transferidos con un ancho de banda de 2,00 Gbits/seg. Como puede ver, hay una ligera diferencia en los números, pero todavía relativamente cerca. Si estos números hubieran sido drásticamente diferentes, tendría que investigar la causa.
Estadísticas de red/salida iPerf:Servidor 1 conectándose al Servidor 2
Es importante ejecutar estas pruebas antes de entrar en producción y adquirir el hábito de repetirlas regularmente en sus servidores de producción. Necesita saber qué es normal, si no lo está monitoreando, entonces no puede medirlo. Si sabe que se están realizando actualizaciones de firmware en sus servidores, el host virtual o cualquier equipo de red central, una prueba de iPerf antes y después de los cambios podría alertarlo rápidamente para identificar cualquier efecto secundario negativo.
También es importante realizar esta prueba en cualquier servidor que interactúe directamente con el servidor de la base de datos y cualquier servidor con el que el servidor de la base de datos interactúe directamente, como los dispositivos de copia de seguridad de la red. IPerf funciona tanto en Windows como en Linux, lo que facilita la prueba entre los dos sistemas operativos.
Para los DBA, la red ya no tiene que ser una caja negra de la que no sabe nada. El uso de iPerf puede alertarlo sobre cualquier problema de ancho de banda con la red entre su servidor de base de datos y cualquier otro servidor. No hay motivo para confiar únicamente en PING y TRACERT para la resolución de problemas de red limitados. Descarga iPerf y empieza a documentar el ancho de banda de tu red.
