Archivo de la categoría: Recursos

Hyper-V Performance – Parte V – NUMA.


Para finalizar esta serie de Post hoy nos metemos con NUMA. Hago una breve introducción sobre esta serie de posts sobre Hyper-V Performance. Hemos hablado de los siguientes puntos:

  1. CPU.
  2. Memoria.
  3. Almacenamiento.
  4. Red.

Creo que primero trataremos de explicar qué es NUMA y para qué sirve. Si buscamos la definición canónica de NUMA, desde la Wikipedia nos dice que es “El acceso a memoria no uniforme”. Yo me quedé como estaba y seguí buscando por internet.

0001Al final me quedo con esta difinición. “Sistema que realiza una asociación de memoria de uso a CPU con la finalidad de evitar cuellos de botella”. Aqui os dejo un enorme post sobre Numa e Hyper-V, del gran Daniel Matey. Es de hace un par de años pero poco han cambiado las cosas.

Un detalle que me llamó la atención es como realiza la asociación CPU vs Memoria cada constructor. Como ejemplo:

  • Intel.- Asocia cada 4 Cores = 1 Nodo NUMA.
  • AMD.- Asocia cada 6 Cores = 1 Nodo NUMA.

Hyper-V, automáticamente utilizará la mejor opción posible y configurará la máquina virtual (VM) para optimizar la topologia existente NUMA. Los problemas aparecen cuando utilizamos memoria dinámica y cuando las VMs requieren mas memoria que la asignada a cada nodo NUMA.

Ahora, a lo nuestro, verificar y medir el rendimiento:

  • \\Hyper-V Hypervisor Virtual Processor(*)\% Remote RunTime.- El menor valor representará un buen rendimiento. Cuanto mas cercano a 0 mucho mejor.
  • \\Hyper-V VM VID Partition(*)\% Remote Physical Pages.- Lo ideal es que esté lo mas cercano posible a 0. Esto quiere decir que la VM estará utilizando únicamente recursos locales, de su nodo NUMA.

Otras recomendaciones que realiza Microsoft:

  • Los Componentes de integración (ICS) tienen que ser los recomendados/sugeridos dependiendo de la versión de Hyper-V donde esté alojada la VM.
  • Hyper-V debería ser el único rol habilitado en el Host.
  • Evitar tener una mezca del VMs con sus ICS y VM sin sus ICS, penalizará el rendimiento del Host.
  • No asignar mas de 2 procesadores a aquellas VM con sistema operativo 2003. (Esta me ha gustado mucho).
  • Por favor, no usuar “legacy network adapters” aumenta considerablemente el “Context Switching”. Lo explicamos en el Post sobre red.

Ya queda menos.

Bibliografía.

Blog de Daniel Matey.

Blog de Aidan Finn.

Windows Server Blog Post 1 y Post 2.

Hyper-V Performance – Parte IV – Red.


Me quedé sin espacio en la base de datos de mi WordPress en Azure, así que continuamos en “MasRobeznoQueNunca” hasta que solucione este pequeño problema.

Hoy continuamos con la monitorización de la red.

Después de haber visto la monitorización mas complicada como es la de Almacenamiento o la de memoria, la monitorización de rede la vamos a basar en dos simples contadores, uno para la tarjeta del host y otro para la tarjeta de las Máquinas Virtuales (VM):

a) Tarjeta de red del Host.- El siguiente contador indica el total de Bytes por segundo tanto de tráfico de entrada como de salida en una tarjeta de red física (NIC).

Network InterfaceBytes Total/Sec

Con la siguiente horquilla de valores recomendados:

0001

No tenemos que olvidar detalles tan importantes como la velocidad de nuestra tarjeta de red, como por ejemplo:

  • NIC de 10 GB puede enviar cerca de 1250 millones de bytes/sec
  • NIC de 1 GB puede enviar cerca de 125 millones de bytes/sec
  • NIC de 100 MB puede enviar cerca de 12,5 millones de bytes/sec

y la velocidad de los Switches o Routers a los que está conectado, ya que aunque tengamos la posibilidad de configurar las tarjetas de red a 10 GB si los Switches son de 1GB ……

.

b) Tarjeta de red de la VM.- En el caso de que queramos estudiar el tráfico de las tarjetas de red virtuales (vNIC), utilizaremos el siguiente contador que representa el número total de byts que atraviesan dicho adaptador virtual.

Hyper-V Virtual Network AdapterBytes Total/Sec

Utilizaremos la misma horquilla descrita en el punto anterior.

Buena semana a todos.

Hyper-V Performance – Parte III – Almacenamiento.


Continuamos con esta serie de Post sobre como medir el rendimiento de nuestros Hyper-V, despues de la CPU y la memoria RAM, hoy nos toca el almacenamiento.

El almacenamiento suele ser uno de los puntos donde se originan mas cuellos de botella en nuestra infraestructura. Detectar dichos problemas suele ser uno de los dolores de cabeza mas frecuentes del informático. En Hyper-v no va a dejar de ocurrir lo mismo. Lo vamos a dividir en tres partes:

a) Logical Disk. Tenemos estos tres contadores de rendimiento recomendados de Disco lógico, como podreis intuir se trata de monitorizar si tenemos latencia en lectura, escritura y en transferencia por segundo, en valores medios:

LogicalDiskAvg Disk sec/Readalmacenamiento00011

LogicalDiskAvg Disk sec/Write

LogicalDisk(*)Disk Transfers/sec (IOPS desde el punto de vista de Windows).

Utilizaremos el siguiente baremo recomendado por Microsoft para saber si nuestros discos están en estado saludable o tenemos latencia:

b) Physical Disk.Tenemos los mismos contadores de rendimiento recomendados que en punto de Disco lógico, lectura, escritura y transferencia por segundo en valores medios. Además utilizaremos la misma horquilla para saber si tenemos latencia o no.

Physical DiskAvg Disk sec/Read

Physical DiskAvg Disk sec/Write

 LogicalDisk(*)Disk Transfers/sec

En el caso que estemos utilizando Cluster Shared Volumes (CSV) conectados como discos Passthrough, tendremos que monitorizarlos no solo para saber si tenemos latencia, también para ver el grado de fragmentación de dicho disco.

Physical Disk(*)Disk Transfers/sec (* CSV monitoring)

También tendremos que tener especial cuidado si hemos montado nuestra infraestructura de virtualización aprovechando las bondades de Server Message Block (SMB), ya en versión 3, con los siguientes contadores:

SMB Clients ShareAvg Disk sec/Read

SMB Clients ShareAvg Disk sec/Write

Es dificil poner un baremo en estos contadores ya que siempre dependerá de la infraestructura de red que tengamos.

c) Hyper-V Storage.- Estos contadores representan el número total de bytes que han sido leidos o escritos por segundo en el dispositivo virtual. Es complicado poner un baremo ya que en todo momento depende del tipo de almacenamiento físico que estemos utilizando:

Hyper-V Virtual Storage DeviceRead bytes/Sec

Hyper-V Virtual Storage DeviceWrite bytes/Sec

Cada fichero VHD o VHDX tendrá su propia instancia de contador de rendimiento y lo utilizaremos para determinar qué disco tiene mas o menos utilización (IOPS).

Como podreis comprobar hay innumerables post en blogs sobre el rendimiento y el almacenamiento, hay mucha información, en general, sobre el rendimiento. Os enumero unos poquitos:

¿Tenemos el control de los permisos en nuestro Directorio Activo? – Herramienta AD ACL Scanner.


El otro día me hacían una gran pregunta ¿Tenemos el control de los permisos en nuestro Directorio Activo? ¿Podemos revisar nuestra delegación de permisos en Directorio Activo?, es más ¿Podemos hacer tales cosas rápidamente.

Desde Suecia con amor nos llega una gran herramienta de consulta. Su Plataforma de PFE’s el pasado mayo editó un Post en su blog (ver aqui), donde hablaban de la herramienta AD ACL Scanner (la podemos descargar desde aqui).

¿Que hace AD ACL Scanner?

¿Quién tiene documentado todos los permisos y la delegación de los mismos en su Directorio Activo? …. Yo no. Mal ejemplo doy. Esto tenemos que cambiarlo.

Bien, esta herramienta genera informes sobre las listas de control de acceso a nuestro Directorio Activo. Ahora ya no tenemos escusa para no documentarlo.

Para ejecutar esta herramienta/script, necesitamos lo siguiente:

  • PowerShell 2.0 o superior.
  • Windows 7/Windows Server 2008 o superior.
  • Habilitar la ejecución de scripts no firmados => Set-ExecutionPolicy Unrestricted , de andar por casa, o si queremos ser mas selectivos, Set-ExecutionPolicy Unrestricted -Scope CurrentUser

adaclscan0001

¿Cómo creamos un informe de una OU?

Básicamente son tres sencillos pasos:

  1. Hacemos click en el botón de Connect la herramienta se conectará a nuestro Directorio Activo o a la partición que necesitemos, Configuración, Dominio, Esquema o Custom.
  2. Nos aparecerá el arbol del Directorio Activo con todas sus Unidades Organizativas donde podremos ir moviendonos y seleccionando.
  3. Cuando hayamos seleccionado una OU, ejecutaremos el escaneo pertinente, o sea, click en botón Run.

Este es un ejemplo de informe:

adaclscan0002

Opciones del Escaner:

  • Por defecto solo se nos mostrará la información sobre la OU en la que estamos. Si queremos también la de todas sus hijas, deschequearemos el botón One Level. No tenemos que preocuparnos si la herramienta tarda en hacer su trabajo, sobre todo en grandes estructuras con infinitas OUs.
  • Si queremos la fecha cuando los permisos fueron modificados tenemos que hacer un check en la opción Replication Medatada, añadiéndonos una columna a nuestro informe con dicho valor. Veamos otro ejemplo:

adaclscan0003

adaclscan0004

  • También podemos visualizar todos los bojetos, cambiado la selección de OU a All Objects.
  • Podemos seleccionar que el informe sea formato HTML o CSV o ambos formatos, fijando la ruta de destino del fichero en formato CSV así como podemos intercambiar el resultado entre ambos formatos.

Aunque donde esta herramienta demuestra todo su potencial es en los siguientes puntos:

Comparaciones.- Podemos comparar el resultado del estado actual con un resultado de un estado previo. Al poder guardar la salida del informe en formato CSV podemos comparar ficheros a lo largo del tiempo y poder descubrir quién tiene ahora permisos que antes no tenía y viceversa.

adaclscan0005

Filtrado.- Podemos realizar los siguientes filtros:

  • Filtro de permiso de Permitir o Denegar.
  • Filtro por tipo de objeto, como pueden ser Usuarios, contactos, grupos, equipos, etc.
  • Filtro “By Trustee”, o sea por cualquier conjunto de letras que puedan corresponder a algo que se encuentre en nuestro Directorio Activo.

Con esta herramienta no se que escusa poner ahora.

Suerte.

Hyper-V Performance – Parte II – Consumo de Memoria.


Continuo con esta serie de Post sobre como medir el rendimiento de nuestros Hyper-V, despues de la CPU hoy llega la memoria RAM.

 

Obviamente lo dividimos en la parte del Host de virtualización, ya sea Windows Server 2012 con el rol de Hyper-V o sea Hyper-V server 2012, y la parte de las máquinas virtuales (VMs).

 

Host.- Los principales contadores para monizar la memoria del Host son los siguientes:

 

  • MemoryAvailable MBytes.- Microsoft nos recomienda monitorizar la memoria disponible de cada Host de virtualización a través de esta orquilla de valores:

0001

  • MemoryPages /Sec.- Con este contador monitorizaremos las páginas que se están leyendo o escribiendo en disco por segundo, para tratar de detectar errores de paginación, o sea, que tengamos un caso que el sistema operativo no dispone de mas memoria disponible y está utilizando el disco duro para volcar el resto de  memoria que necesita, con su correspondiente impacto negativo en el rendimiento.   Microsoft nos recomienda esta orquilla de valores a la hora de medir este contador:

0002

Como ejemplo, un alto número de paginas por segundo unido a una baja memoria disponible nos está indicando una falta de memoria en el servidor, obviamente.

 

Recordamos los principios básicos de la relación existente entre la memoria y la paginación a disco “a mas memoria RAM asignada a un equipo menos paginará en disco“, sin olvidarnos de que “no siempre disponemos de toda la memoria RAM que queremos y/o necesitamos”.

 

Virtual Machines.- En este caso se nos presentan dos opciones de configuración en la gestión de la memoria:

 

  • Sin memoria Dinámica configurada.- Al no tener configurada esta característica, utilizaríamos los mismos contadores que para un Host de virtualización. Volvemos al punto anterior.

 

 

  • Con memoria Dinámica configurada.- Tenemos los siguientes contadores de rendmiento:
  • Hyper-V Dinamic Memory BalancerAvailable Memory.- Este contador representa la cantidad de memoria que queda disponible en el “nodo balancer” (gestor del balanceo de memoria entre las VM cuando están configuradas con memoria dinámica), y que puede ser asignada a las VMs.

Aqui prestaremos atención a que el valor de dicho contador no esté próximo a 0, que nos indicará que el sistema está cerca del consumo del 100% de la memoria, con los consiguientes problemas de rendimiento en las mismas.

  • Hyper-V Dinamic Memory BalancerPhysical Memory.- Este contador representa la cantidad de memoria en la VM. Es muy util para entender el consumo histórico de una VM.

Tendremos que tener cuidado de que el valor que nos da este contador no esté cerca de la memoria máxima asignada, ya que nos indicaría que este servidor está consumiendo toda su memoria RAM y, probablemente, esté paginando a disco y necesite mas.

  • Hyper-V Dinamic Memory BalancerAverage.- Este último contador representa la presión media sobre el “nodo balancer”. Esta es la orquilla de valores recomendados:

0003

 

Por defecto en Windows Server 2012 con el rol de Hyper-V, automáticamente se fija una memoria para el Host. Para sistemas operativos anteriores, como Windows Server 2008 R2, necesitamos habilitar y configurar una entrada en el registro:

HKLMSOFTWAREMicrosoftWindows NTCurrentVersionVirtualization

  • Nombre:MemoryReserve
  • Tipo: DWORD
  • Valor: Memoria a reservar en MB.

 

Dos cosas para terminar. Recordar que estos datos no son extrapolables al 100% a todos y cada uno de nuestros entornos, como ya dije en el Post anterior, son recomendaciones. Y, segundo, recordar, también, en el caso de configurar memoria dinámica a las VMs, qué parámetros tenemos que tener en cuenta:

 

Buena semana a todos,

Hyper-V Performance – Parte I – Consumo de CPU.


Aprovechando que hace poco estube en un Workshop en Microsoft sobre el rendimiento de nuestros servidores con el rol de Hyper-V, adelanto esta serie de Posts sobre “cómo medir dicho rendimiento así cómo detectar posibles cuellos de botella en nuestro entorno de virtualización”.

Para empezar, me gustaría recordar este Post sobre “10 errores típicos en una revisión de salud de un entorno de Virtualización“, que considero indispensable releer cada vez que me meto en un proyecto de virtualización, independientemente del tipo de Hypervisor que se vaya a utilizar.

 

0001

i) Host Processor.- Normalmente en cualquier servidor, si queremos verificar el consumo de nuestro procesador lo que haremos será cargar los siguientes contadores de rendimiento:

 

  • Processor(*)% Processor Time
  • Task Manager (ver imagen =>)
  • SystemProcessor Queue Lenght

 

Pues en nuestro caso, para saber qué consumo tiene la partición padre, que no hay que olvidar que es una máquina virtual (VM) en si misma, ya sea Hyper-V Server 2012 o Windows Server 2012 con el rol de Hyper-V, serán los mismos.

 

Veamos en que rangos de consumo de tiempo de procesador nos movemos:

0003

En el caso de que hayamos visto o intuyamos que pueda haber un problema de rendimiento en la CPU, o sea, nos hayemos en la zona de Caution o Critical, utilizaremos el contador de la Longitud de la cola del procesador, como referente inicial disponemos de la siguiente horquilla de valores que nos puede ayudar:

0002

Siempre hay que tener en cuenta que si ocurre en un momento puntual, no pasa nada. Otra cosa es que estos valores se alcancen durante un tiempo continuado. En cuanto a la horquilla de valores, éstos son orientativos, hay que saber extrapolarlos a las situaciones reales, a la carga del servidor, a los roles que tengamos instalados en el mismo, etc., no cogerlos como una regla de tres o lo que dice el KB de Microsoft va a Misa.

 

ii) Logical processor.- Para medir el total del consumo de procesador por parte del Host y todas las VM, utilizaremos los siguientes contadores de rendimiento:

  • Hyper-v Hypervisor Logical Processor(*)% Total Runtime
  • Hyper-v Hypervisor Logical Processor(*)Context Switches /Sec

% Total Runtime, con su consiguiente horquilla de valores indicativos (si os fijais son los mismos que en el punto anterior):

0003

Para el caso de los Content Switches, ocurren cuando el kernel cambia el procesador asignado de un subproceso a otro, verificaremos cuántos se producen por procesador y por segundo, con la consiguiente horquilla de valores indicativos:

0004

Cuando detectamos que estamos en zona Critical, suele venir motivado por:

  • Adaptadores del tipo Legacy Network.
  • Mal diseño de aplicaciones.
  • Drivers mal instalados.

 

ii)  Virtual processor.- Determinar el consumo de procesador de cada VM:

  • Hyper-v Hypervisor Virtual Processor(*)% Guest Runtime

Con la misma o muy parecida horquilla de valores indicativos que en el punto anterior:

0005

Como consejo final, si detectamos que Hyper-V Hypervisor Virtual Processor (_Total)% Total Run Time (Virtual Procesor Total Run Time – VPTR) está muy alto y Hyper-V Hypervisor Logical Processor (_Total)% Total Run Time (Logical Procesor Total Run Time – LPTR) es bajo, consideremos en asignar procesadores adicionales a esa VM.

El próximo día la memoria RAM.

>Dexpot, mútiples escritorios para Windows.


>

Buenos dias,

Para aquellos que nos iniciamos en Unix, la posibilidad de tener varios escritorios ejecutándose al mismo tiempo era algo habitual, cada uno de ellos con una serie de aplicativos preparados directamente para su ejecución, por ejemplo.

Acabo de conocer la aplicación Dexpot para plataforma Windows, y estoy disipuesto a darla caña. en entornos Windows sólo tenemos un escritorio, si no nos movemos con productos de Escritorios Remotos, etc.,

Dexpot colo un listado de los escritorios virtuales en nuestra barra del sistema para que vayamos intercambiandonos entre ellos, pudiendo elegir qué ventanas se abren por defecto en cada uno de ellos.

Se me olvidaba, es gratuito, de momento!
Espero que os sea util.
Nos vemos.

Herramienta gráfica para la resolución de nombres de internet – Servicio DNS.


Ya de vuelta de las vacaciones, nos ponemos un poco las pilas, pero despacito.

Navegando me he encontrado con esta herramienta gráfica para la resolución de nombres, DNSDataView, de NirSoft.

Para los menos habituados, sustituye a la herramienta de línea de comando llamada nslookup, pudiendo, incluso, exportar la información a informes en formato HTML. Funciona desde Windows XP hasta Windows 7, en Desktop, y desde Windows 2003 hasta Windows 2008.

Introduces el dominio que quieres verificar su estado o situación, ejemplo bircomingenieria.com

Seleccionamos los tipos de registros de DNS, como ejemplo NS para los servidores de nombres, MX para los servidores de correo electrónico, etc. Y nos aparece el resultado:

Interesante también es la posibilidad de múltiples idiomas:

Sinceramente, simple pero eficaz, sobre todo para los no iniciados.

Nos vemos,

Medición del rendimiento – ¿Cómo detectar problemas de latencia en disco en VMware vSphere ESXi?


Continuando con las mediciones del rendimiento de nuestros servidores, llevaba tiempo para sacar un Post sobre cómo detectar problemas de latencia en discos, tanto FC, iSCSI como NFS, al menos desde que hice el curso para la obtención de la certificación VCP-410 y, hoy, al hilo de un artículo aparecido en el Blog de la Virtualización en Español, de nuestro gran maestro Jose María Gonzalez, retomo una de sus enseñanzas.

¿Cómo detectar problemas de latencia en disco de un ESXi? Dentro de nuestra herramienta de rendimiento, nos fijaremos en los siguientes contadores:

  • Kernel command latency.- tiempo medio empleado por el VMkernel para procesar un comando SCSI. Un número alto en este contador, (entre 2 a 3 milisegundos, puede significar:
    • Que la cabina tenga un exceso de trabajo
    • O que el servidor ESX/ESXi tenga un exceso de trabajo.
  • Physical device command latency.- Mide el tiempo medio que el dispositivo físico (disco) necesita para completar un comando SCSI. Un número alto en este contador (depende d la cabina, pero, en general, este valor está entre 15 y 20 milisegundos), puede significar dos cosas:
    • O la cabina va muy lenta.
    • O la cabina tiene un exceso de trabajo.

Vayamos a un ejemplo real. Configuro el primer contador (Kernel command latency) para mi cabina de discos y este es el resultado:

En este caso nos fijamos en el último dispositivo, que es el que no está dando unos valores anómalos. Como se puede apreciar, la SAN es una HITACHI.

Por otro lado, ahora nos fijamos en el segundo contador, (Physical device command latency). Este valor, en principio, nos tiene que venir dado por el fabricante de la cabina, en mi caso HITACHI, pero yo no lo he conseguido. Me voy a basar en los estándares.

En este caso tenemos que los siguientes discos:

  • t10.HITACHI_770501211902.- Este disco está por encima de los 20 milisegundos.

  • t10.HITACHI_770501211901.- Este disco ronda los 11 milisegundos en media con ligeros picos por encima de los 20 milisegundos.

¿Cómo seguir desde aquí? Bien, sabemos qué maquinas componen la citada LUN, en mi caso contiene las siguientes Máquinas Virtuales (VM):

Habría que ir moviendo una a una cada VM a otra LUN y verificar cuál es la que está provocando este fallo.

El próximo día Iperf en modo gráfico.

Un saludo,

Medición del rendimiento – Networking con Iperf.


Uno de los problemas más difíciles de detectar hoy en día en las “grandes empresas” es ver que el rendimiento de la red es el correcto. Digo grandes empresas ya que o tienen subcontratados los departamentos de comunicaciones, o siendo de la misma empresa, se llevan a matar. Este es mi caso pero con una salvedad, aquí se inventó la técnica de “balones fuera”.

Al grano. Utilizaremos la herramienta Iperf, válida para sistemas operativos tales como Sun Solaris, Linux, Windows, etc. Estos son todos los parámetros:

Destacamos los siguientes parámetros:

  • -D    instalación como servicio.
  • -R    Desinstalación (remove) como servicio.
  • -i    intervalo de tiempo en segundos entre reportes.
  • -l    longitud del buffer a leer o escribir (por defecto 8 KB)
  • -u    recepción de datagramas UDP en vez de tramas TCP que es la opción por defecto.
  • -P n    donde n es el nº de conexiones simultáneas.
  • -t    tiempo en segundos de transmisión (10 segundos por defecto)
  • -w    tamaño de ventana TCP.
  • -f[bkmBKM] formato del resultado: bits/s, kilobits/s, megabits/s, Bytes/s, KiloBytes/s, MegaBytes/s.

Pruebas realizadas:

i) Básica.- Definimos un equipo como servidor y otro como cliente y ejecutamos el aplicativo en ambos equipos.-

Ejecutamos en el equipo servidor Iperf -s

Ejecutamos en el equipo cliente Iperf –c <equipo servidor>

En este caso tenemos un ejemplo claro de una pobre comunicación en una red de 100MBits. 38,7 Mbits/sec.

En este otro caso tenemos una mejor comunicación en una red de 100MBits. 75,1 Mbits/sec.

ii) Parametrizada.- Como hemos visto en la definición del comando vamos a utilizar los siguientes parámetros:

Servidor: Iperf –s –f MB –i1 (tamaño en MegaBytes e intervalos de 1 segundo)

Cliente: Iperf –c 10.144.8.123 –f MB –t 30 (tamaño en MegaBytes y durante 30 segundos de duración)

Bibliografía.

El próximo Iperf gráfico, Iometer, etc.

Un saludo,

masrobeznoquenunca

Comparto lo que hago y lo que veo.

El camino de un ITPro

El camino de un ITPro

adumont

Just another WordPress.com weblog

Marco Antonio's space

Una mirada dentro de mis ratos libres...

Marcelo Ruiz

Network and SocialMedia

A Digital Frontier...

Blog personal de Robert Garrandés Simancas ("Versión Beta")

enero11

Literatura para romper el tiempo.

A %d blogueros les gusta esto: