Dos comandos útiles en ESXi 5.1 para iSCSI

 Eliminar el adaptador iSCSI software

 #esxcli iscsi software set -e false

Cambiar el IQN del adaptador iSCSI

 # esxcli iscsi adapter set -A vmhba33 -n iqn.1998-01.com.vmware:xxxxxxxxx
 # esxcli iscsi adapget get -A vmhba33

Búsqueda de 'bottlenecks' en VMWare ESX/ESXi con ESXTOP

Elementos de visualización:

c - CPU
m - Memoria
n - Network
d - Interfaces de disco (HBA)
u - Discos físicos conectados a HBAs (LUN)
v - Discos virtuales de las VMs (vmdk)

Opciones genéricas de visualización:

s - Segundos de refresco
v - Mostrar solo VMs
f - Añadir/Eliminar campos a mostrar
o - Ordenación de campos
L - Número de caracteres a mostrar por campo (util si los nombres de las VMs son muy largos)
2 - Resaltar fila hacia abajo
8 - Resaltar fila hacia arriba
4 - Eliminar fila de la visualización

Búsqueda de cuellos de botella relativos a recursos de CPU física

    #esxtop
    c
    s 2
    L 45

Campos significativos:

CPU load average. Estos valores son los clásicos de carga media a 1, 5 y 15 minutos sobre los procesadores. Cuanto más se aproximen a 0, mejor.
 Los valores "PCPU USED (%)" y "PCPU UTIL(%)" indican la carga de las CPUs físicas (por core). Cuanto más se acerquen al 100% significará que menos ciclos de cpu libres quedan para picos de carga de las VMs o nuevas VMs. Es decir, sobresuscripción; se ha alcanzado el límite de los recursos de cpu. Por encima del 90% de uso sostenido comienza a se problemático teniendo que cuenta que la carga física es variable en función de la carga de las cpu virtuales.
Los valores por core de estas medidas pueden estar equilibrados o descompensados. Si la descompensación de carga entre unos cores y otros es muy grande, indica problemas de afinidad. Para mantener un grado aceptable de afinidad y no perjudicar el rendimiento, no se recomienda crear máquinas virtuales con mayor número de vCPUs que el número de cores de cada procesador físico (4 en caso de quad-core).

CPU de máquinas virtuales

    #esxtop
    c
    s 2
    L 45

Para un determinado World (VM):

• %RUN: Ciclos de cpu que la máquina consume respecto a los procesadores virtuales que se le han asignado. Es el valor de carga de cpu que encontraríamos en las estadísticas del OS de la propia máquina.

• %SYS: Ciclos de cpu de sobrecarga por I/O que el hypervisor debe usar para las operaciones de IO de la máquina virtual.

• %USED: ~(%RUN + $SYS). Valor real de cpu que la VM está consumiendo.

• %MLMTD: Ciclos de cpu que no se han podido ejecutar porque se viola un límite de cpu establecido para esa máquina. Es util para saber si una máquina que tiene un límite lo supera. Si este valor permanece en 0.00, el límite podría ampliarse aun más.

• %RDY: Quizá el valor más representativo. Este valor indica la cantidad de tiempo que las vCPU de la VM ha solicitado ejecución de instrucciones en el procesador físico, pero ha tenido que esperar porque no había recursos para darle. Este valor debe estar lo más próximo a 0. Pro encima de 0 significa que la VM encola ciclos de cpu sobre el procesador físico. Hasta 5% puede ser aceptable. Por encima del 10% los problemas de rendimiento son bastante graves e indican una sobrecarga de los recusos de cpu físicos. Es el valor más representativo de que se han agotado los recursos.

• Tiempos de espera por IO: ~(%WAIT - %IDLE)

• %SWPWT: Tiempo de espera por información que está en swap. Este valor distinto de 0.00 es desastroso. Indica que el ESX está swapeando la máquina sin conocimiento de la misma. Los accesos a memoria se ralentizarán en al menos un orden de magnitud. Indica alta sobresuscripción.

Memoria física (pRAM)

    #esxtop
    m
    s 2
    L 45

De entre los valores globales:

• MEM overcommit avg: De forma genérica, cantidad de memoria que ha tenido que ser swapeada por sobresuscripción. Idealmente estos valores deberían ser 0.00. El valor viene dado en 'tantos por uno', de forma que 0.20 indica un 20%. Es una forma de saber no solo la existencia de sobresuscripción, sino de cuanto representa.

• PMEM  /MB: Uso de la memoria física. Cantidad total, usada y libre.

• VMKMEM, COSMEM: Uso de memoria de la "Console Of Service"
• SWAP  /MB: Ritmo al que swapea el ESX. El valor ideal es 0.

• MEMCTL/MB: Cantidad de memoria que el ESX ha recuperado de las VMs haciendo Ballooning. El valor ideal es '0 curr'.

Memoria de las máquinas virtuales (vRAM)

    #esxtop
    m
    s 2
    L 45

   
Para un determinado World (VM):

• MEMSZ: Memoria (MBs) asignadas a la configuración de la VM

• GRANT: Memoria (MBs) que ya ha sido otorgada a la VM   

• SZTGT: Memoria (MBs) GRANT + overhead. Si el overhead es grande, este valor puede superar el MEMSZ.

• Overhead (OVHD, OVHDMAX, OVHDUW): El overhead es la cantidad de memoria que el ESX necesita para mantener una determinada máquina en funcionamiento. Almacena metadatos y depende del número de procesadores virtuales y memoria virtual de una máquina. Toda VM precisa una cantidad de memoria overhead. al menos habrá una cantidad fija de overhead (OVHDUW) dependiente casi únicamente de la cantidad de recursos, otra (OVHD) para el resource pool (frame-buffers, etc) y una cantidad máxima (OVHDMAX) que el ESX podría llegar a reclamar para el correcto funcionamiento de la máquina. Como al menos una cantidad de overhead es fija y depende de los recursos asignados a la máquina (número de cpus, RAM...), conviene saber que toda máquina sobredimensionada no solo compromete los recusos propios de su definición, sino también los recursos de overhead, que crecen a medida que la máquina tiene más recursos asignadso.

•         SW*: Ritmo al que la máquina está haciendo swapping. Cuando una VM swapea su rendimiento se ve afectado.

Disco

    Los cuellos de botella en el almacenamiento suelen estar en tres posibles sitios: La interfaces de almacenameinto (HBAs, etc), los sistemas de almacenamiento externos o discos físicos o en último lugar en el acceso a discos virtuales de las propias máquinas, aunque estos últimos suelen derivar de alguno de los anteriores.

    Monitorización de las HBA

        #esxtop
        d
        s 2
        f

    Monitorización del acceso a disco físico (LUNs)

        #esxtop
        u
        s 2
        f

    Monitorización del acceso a discos virtuales por parte de las VMs (vmdks)

        #esxtop
        v
        s 2
        L 45
        f

Interpretación de valores.

        Latencias:

• KAVG: Latencia de los comandos de acceso a disco del VMKernel. Es la latencia que se produce desde que un dato debe ser pedido a disco hasta que el VMKernel del ESX procesa la petición. No incluye el acceso real al dato, sino solo lo que le lleva al ESX ejecutar los comandos de petición. Debe estar muy próximo a cero salvo que el ESX esté sobrecargado y tenga que encolar comandos de IO a disco. Hasta 0.05 son valores aceptables.

• DAVG: Latencia de entrada salida del almacenamiento. Es la latencia desde que el ESX ha realizado los comandos de petición (KAVG) hasta que el sistema de almacenamiento le ha devuelto el dato. Implica el tiempo que el almacenamiento tarda en posicionar las cabezas en los disco, leer y devolver la información. Como este valor no depende del ESX, debe compararse con los valores que son óptimos para el sistema de almacenamiento. De forma estandar, valores por encima de 20 se consideran latencias altas.

• GAVG: (KAVG + DAVG). Es la latencia completa de una petición de acceso a disco. Si este valor no es óptimo se debe comprobar si es devido a KAVG o a DAVG. Este es el valor de latencia que percive la VM.

        IOPS:

• CMDS/s, READS/s, WRITES/s: IOPS totales, de lectura y de escritura. Conviene comparar estos valores con los rangos que acepta el almacenamiento para ver si se está superando el límite.

MBREAD/s, MBWRTN/s: Ritmo al que se lee/escribe.

Problemas/Errores:

• ABRTS/s: Comandos "Abort" por segundo. Se producen cuando el VMKernel solicita un acceso a disco pero el almacenamiento no es capaz de propocionarselo a tiempo. En ese momento se produce un comando Abort. El valor óptimo es 0.00, que indica que todas las peticiones son atendidas (aunque sus latencias pueden ser altas). 
• RESETS/s: Similar al anterior pero con comandos 'Reset'. Indica el número de reseteos del bus SCSI. El valor óptimo es 0.00. Si crece podría deberse a desconexiones intermitentes del almacenamiento y supone un serio problema.
• RESV/s: Número de reservas SCSI por segundo. Un número alto (>20) indica demasiadas VMs por LUN. Este valor toma sentido al cruzarlo con el siguiente.

• CONS/s: Número de conflictos SCSI por segundo. El valor ideal es 0.00

Networking   

    #esxtop
    n
    s 2
    L 45
    f

1.     Relativo a las interfaces físicas del ESX: Filas "vmnic*"
2.     Relativo a las interfaces virtuales de las VMs: Filas con nombre de cada VM

Interpretación de valores:

• PKTTX/s: Paquetes transmitidos por segundo (Diferenciar lo que sale por cada vmnic de lo de las VMs).
•  MbTX/s:  Mb's transmitidos por segundo (IDEM)

• PTTRX/s: Paquetes recibidos por segundo (IDEM)

• MbRX/s:  Mb's recibidos por segundo (IDEM)

• %DRPTX / %DRPRX: Los valores más representativos. Indican la cantidad de paquetes que no pueden ser encolados ni atendidos para envío o recepción y se han perdido. El valor ideal para ambos es 0.00. Valores superiores indican un cuello de botella la red. Si se 'dropean' paquetes en las interfaces físicas (vmnic*), indica que las VMs piden acceso a la red a un ritmo mayor de lo que el ESX puede atender (superior al ancho de banda de la interfaz). Si se dropean en las VMs, indica que la VM intenta sacar paquetes de su interfaz virtual a mayor ritmo que el ancho de banda de lo que es posible. Normalmente no se verá una VM dropeando paquetes sin que además exista un dropeo en las interfaces físicas salvo que el ancho de banda de las vmnic* sea mucho mayor que el de las interfaces virtuales.    

Referencias:

http://communities.vmware.com/docs/DOC-9279
http://communities.vmware.com/docs/DOC-11812
http://hispavirt.com/tag/esxtop/
http://www.windowsitpro.com/article/virtualization2/q-how-can-i-use-esxtop-to-identify-storage-performance-problems-

Monitorización y búsqueda de cuellos de botella en NetAPP 3140

Previo

Existen herramientas gráficas para controlar esto, pero en este caso se va a utilizar solamente herramientas de comandos.


La monitorización de un sistema de almacenamiento NetAPP se basa principalmente en la interpretación de la salida de los comandos 'sysstat' y 'stats'.

stats

Lista de elementos monitorizables:

#stats list objects
#stats list instances
#stats list counters

Descripción de cada contador

#stats explain [COUNTER]

IOPS

#priv set advanced
#stats show -i SEGUNDOS -n NUMEROPRUEBAS volume:NOMBREVOLUMEN:PARAMETRO

Siendo:

• SEGUNDOS: Tiempo entre mediciones.
• NUMEROPRUEBAS: Número de repeticiones.
• NOMBREVOLUMEN: Volumen a monitorizar.
• PARAMETRO: "read_ops", "write_ops", "total_ops"

vg.-

    filer2*>  stats show -i 3 -n 10 volume:LunsSATA:read_ops volume:LunsSATA:write_ops volume:LunsSATA:total_ops
        Instance read_ops write_ops total_ops
                       /s        /s        /s
        LunsSATA      265       390       656
        LunsSATA      176       253       430
        LunsSATA      221       237       458
        LunsSATA      174       182       356
        LunsSATA      250       256       508
        LunsSATA      349       339       688
        LunsSATA      219      1163      1383
        LunsSATA      207       300       507
        LunsSATA      482       327       809
        LunsSATA      204       346       552

Discos HotSpot

#priv set advanced
 #sysstat -x 1

El valor “Disk Util” indica el nivel de uso del disco con más uso en la lectura actual.
Si este valor está de forma continua en valores del 100% o muy cercanos, significa que al menos un disco es un punto caliente o “hot spot”, lo que indica que está siendo sometido al máximo estrés. Esto afecta al rendimiento, aunque es habitual ver estos valores mientras el sistema ejecuta taréas de reconstrucción de RAID o deduplicación.
¿Existen procesos de deduplicación activos?:

#sis status
#sis status -l

¿Existen procesos de reconstrucción de raid activos?:

#aggr status

Si no se están ejecutando tareas de este tipo, el volumen o agregado que contiene el problema debe pasar por un proceso de “reallocate” para redistribuir de forma balanceada los datos entre todos los discos y eliminar el hot spot.
Para descubrir que disco es un hot-spot:

#stats show disk:*:disk_busy

Muestra el nivel de ocupación de todos los discos. Para saber que disco es exactamente y buscarlo en el agregado:

# storage show disk -a

Los valores aceptables de uso de disco deben situarse por debajo del 70% en media.

Fragmentación/Desfragmentación:

El comando

#filer2*> reallocate measure -o /vol/vol23

sobre un volumen o agregado devuelve valores del estilo (la ejecución tarda varios minutos):

#filer2*> Tue Oct  9 17:38:20 CEST [filer2: wafl.reallocate.check.value:info]: Allocation measurement check on '/vol/vol23' is 1.

El valor de 1 indica una fragmentación óptima (baja). Valores superiores a 4 comienzan a afectar significativamente al rendimiento.
La fragmentación se soluciona con los procesos de “reallocate”. Ejecutar (con cuidado) el comando reallocate para desfragmentar volúmenes y LUNs fragmentadas. Estos procesos deben ser ejecutados siempre que se añadan nuevos discos a agregados ya existentes.
En realidad “reallocate” se puede ejecutar sobre volúmenes, LUNs o agregados, pero sobre estos últimos no es recomendable hacerlo salvo en circunstancias muy especiales y supervisión del soporte de NetAPP.

Latencias de acceso a volúmenes

#priv set advanced
#stats show -i SEGUNDOS -n NUMEROPRUEBAS volume:NOMBREVOLUMEN:PARAMETRO

SEGUNDOS: Tiempo entre mediciones.
NOMBREVOLUMEN: Volumen que se monitoriza.
NUMEROPRUEBAS: Número de testeos.
PARAMETRO: - “read_latency”, “write_latency”, “total_ops”, “avg_latency”.

vg.-

     filer*> stats show -i 1 volume:LunsFC:read_latency volume:LunsFC:write_latency
        Instance read_latency write_latenc
                           us           us
          LunsFC      6786.93      2249.36
          LunsFC      1688.08      1964.02
          LunsFC      6594.67       561.32
          LunsFC      8214.19       210.74
          LunsFC      8856.70       956.05
          LunsFC      7876.88      1415.67
          LunsFC      5996.99      1465.29
        [...]

El límite de latencia en la industria está en 20ms. Por debajo de 20ms de latencia se consideran niveles aceptables. Según profesionales de NetAPP, para volúmenes albergados en discos SATA, la latencia normal se sitúa en torno a los 20ms. Para discos FC sería de unos 5ms. Particularmente para discos SAS,  hay un advisor de NetAPP con la siguiente tabla:

De 0 -1000 us    Good
De 1000 us – 2000 us    Reasonable
De 2000 us – 5000 us    Busy
> 5000 us    Bad

Alineamientos

A partir de On-TAP 8, la forma más sencilla de comprobar el alineamiento de LUNs es ejecutando el comando:

#lun show -v

HITs de Caché

#sysstat -x 1

 Este valor “Cache hit” indica que cantidad de peticiones de lectura son procesadas con información que ya está en caché y no es necesario acceder a disco para obtenerla. Este valor debe ser lo más cercano a 100% para un rendimiento óptimo. Un 100% de hit significa que todas las peticiones se resuelven desde caché. Valores sostenidos de hit por debajo del 85% suponen una merma de rendimiento aunque es un problema de difícil solución.

LUN's Longitudes de cola (Queue Length) y latencias medias

#priv set advanced
#lun stats -o -i5 -c1

Average lantency es la latencia de respuesta de cada LUN en milisegundos. Valores por encima de 20 indican alta carga y afectan negativamente al rendimiento.
Queue Length es la longitud de la cola. Las peticiones de bloques a LUN pueden comenzar a encolarse en caso de no poder ser respondidas al ritmo suficiente. Valores por encima de 2.0 ó 3.0 indican una sobrecarga excesiva de la LUN o del propio sistema completo.
El valor de QFULL, en caso de ser diferente a cero significa que la cantidad de peticiones encoladas en superior a la que el sistema puede atender (superior al tamaño de la cola) y empezará a descartar algunas. Cualquier valor diferente a cero en este item implica un problema de congestión serio en el sistema. Normalmente la longitud máxima de la cola tiene que ver con el buffer y la capacidad de la interfaz física por la que viaja el almacenamiento.

 CONSISTENCY POINTS (CP)

Los CP son operaciones de escritura a disco físico. Normalmente toda la IO se produce desde la memoria caché del sistema, pero periódicamente los cambios son escritos a disco o los datos son recuperados del mismo si no se encuentran en la caché. También se producen por muchas otras cosas.
Observar el tipo de CPs (Columna CP ty)  y el tiempo que consumen (CP time):

#priv set advanced
#sysstat -x 1

Sirve para saber cuantos flush se realiza al disco y la causa. Aunque el tipo de CP es importante, lo es más el CP time, que indica cuanto del tiempo que ha tardado en realizarse el CP se ha usado realmente en tal operación y cuanto se ha desperdiciado (en esperas por los recursos). De esta forma, cuanto más se aproxime al 100% el CP Time, mejor rendimiento habrá pq menos debe esperar la operación en terminarse. El tipo de CP es representativo de cuanto de ocupado está el sistema e idealmente habría pocas. Si no hay CP en ejecución (valor '-'), el CP time lógicamente será 0%.

Explicación de los “CP Type" en este enlace.

CPU

#priv set diag
#sysstat -M 1

 Valores sostenidos por encima del 65% indican cargas altas de CPU. Según NetAPP, valores por debajo de 85% son aceptables.

Chequeos pasivos con Nagios 3.x (NSCA)

Aclaraciones previas
NSCA es una pequeña pieza de software creada específicamente para permitir "passive checks" en Nagios. Tras su compilación, ofrece dos herramientas: El receptor de mensajes 'nsca', que irá instalada en el servidor central de Nagios y el programa que permite enviar mensajes al receptor. Esta parte irá instalada en los clientes que se monitorizan.
En realidad y dado que ambos programas están integrados en el mismo paquete de software en todas las distribuciones Linux, normalmente ambos se instaland en servidor Nagios y clientes, usando en cada uno solamente la parte realmente necesaria.

Sea como fuere, se debe disponer de una instalación operativa de Nagios 3.x (en principio sirve en versiones anteriores, pero no lo he testeado en todas) con algún cliente monitorizado.

Configurando Nagios para aceptar chequeos pasivos
    Asegurarse que Nagios está arrancado con las siguientes opciones en "nagios.cfg":

        log_passive_checks=1
        accept_passive_service_checks=1
        accept_passive_host_checks=1
        translate_passive_host_checks=0
        passive_host_checks_are_soft=0

   
    Instalar el paquete NSCA. Si la distribución utilizada lo soporta, instalarlo con el gestor de paquetes adecuado. También se puede compilar a mano, opción recomendada si nagios fué también compilado a mano. Para compilarlo e instalarlo valdría algo como lo siguiente:

        #> cd /tmp
        #> wget http://downloads.sourceforge.net/project/nagios/nsca-2.x/nsca-2.9.1/nsca-2.9.1.tar.gz
        #> tar xvfz nsca-2.9.1.tar.gz
        #> cd nsca-2.9.1
        #> export NAGIOS_PATH="Ruta de instalación de Nagios"
        #> ./configure --prefix=$NAGIOS_PATH
        #> make
        #> make all

       
   Los archivos compilados están en ./src

            Makefile
            Makefile.in
            netutils.c
            nsca        #Binario del servidor receptor de chequeos pasivos           
            nsca.c
            send_nsca    #Binario que permite enviar mensajes de chequeo pasivo al servidor
            send_nsca.c
            utils.c

    Como se está configurando el servidor, debemos hacer uso del binario "nsca", que copiaremos en algún lugar de la instalación de la instalación de Nagios:

        #> mkdir /opt/nagios-3.3.1/nsca-2.9.1
        #> cp nsca /opt/nagios-3.3.1/nsca-2.9.1

       
    Generar un archivo de configuración con los parámetros que debe ejecutarse el servicio de "nsca". A continuación, los mínimos necesarios. Revisar para su configuración en particular.

        #> vi /opt/nagios-3.3.1/nsca-2.9.1/nsca.cfg
            log_facility=daemon
            pid_file=/var/run/nsca.pid
            server_port=5667
            nsca_user=nagios
            nsca_group=nagios
            debug=0
            command_file=/opt/nagios-3.3.1/var/rw/nagios.cmd
            alternate_dump_file=/opt/nagios-3.3.1/var/rw/nsca.dump
            aggregate_writes=0
            append_to_file=0
            max_packet_age=30
            decryption_method=1
            password=CONTRASENHA

    Ahora se debe definir un nuevo tipo de servicio en Nagios que permita los chequeos pasivos. Después de deben definir qué servicios de qué hosts serán pasivos, pero esta parte se explicará más adelante.
        /opt/nagios-3.3.1/etc/objects/templates.cfg

            [...]
            define service{
                    name                            passive-service
                    active_checks_enabled           0
                    passive_checks_enabled          1
                    parallelize_check               1
                    notifications_enabled           1
                    event_handler_enabled           1
                    register                        0
                    is_volatile                     1
                    parallelize_check               1         
                    obsess_over_service             1                      
                    check_freshness                 0                      
                    flap_detection_enabled          1                      
                    failure_prediction_enabled      1                      
                    process_perf_data               1                      
                    retain_status_information       1                      
                    retain_nonstatus_information    1                      
                    check_period                    24x7                   
                    max_check_attempts              3                      
                    normal_check_interval           10                     
                    retry_check_interval            2                      
                    contact_groups                  admins                 
                    notification_options            u,c,r                  
                    notification_interval           10                     
                    notification_period             24x7
            }
            [...]

    También se debe definir un nuevo "command" tonto:
        /opt/nagios-3.3.1/etc/objects/commands.cfg

            [...]
            # Comando para chequeos pasivos
            define command {
                    command_name    check_dummy
                    command_line    $USER1$/check_dummy $ARG1$ "$ARG2$"
            }
            [...]   

    Iniciar el demonio "nsca"   
        Hay varias opciones para hacer esto. La recomendada es utilizar "xinet" para gestionarlo, aunque también se puede ejecutar como servicio aislado y controlarlo con scripts en "init.d". En cualquier caso esto no se explica y se remite a alguno de los siguientes enlaces:

            http://raman-kumar.blogspot.com.es/2010/03/nagios-nsca-setup-details.html

       
Configurar el cliente para enviar mensajes
    Instalar "nsca" en la máquina cliente de forma similar al servidor. El programa a utilizar será "send_nsca" y se deberá crear un archivo con las opciones de ejecución similar al siguiente:
        ./send_nsca.cfg

            password=CONTRASENHA
            encryption_method=1

    Se puede probar a enviar mensajes directamente al servidor nagios-nsca de la siguiente forma:

        #echo "mensaje" | send_nsca -H IP_Nagios -d ';' -c send_nsca.cfg

    donde:
        el mensaje debe tener una estructura como la siguiente:  HOSTNAME;SERVICIO;{1,2,3};MENSAJE
            HOSTNAME: Es el nombre con el que está definido el cliente en nagios respecto al cual se hace el chequeo.
            SERVICIO: Es el nombre con el que está definido el servicio en el cliente en nagios respecto al cual se hace el chequeo.
            1,2,3: OK, Warning, Critical
            MENSAJE: Texto que aparecerá en en campo "Status Information" de Nagios
    ';' es el delimitador que separa los campos del "mensaje".

    Si se ejecuta este ejemplo, como no se ha definido en nagios ningún servicio pasivo, no ocurrirá nada, excepto que aparezca un mensaje como el siguiente:
        1 data packet(s) sent to host successfully.

    Que indica que el cliente se "habla" correctamente con el servidor.

    El siguiente paso es definir un servicio en nagios para el cliente que se chequee de forma pasiva

Definiendo servicio pasivo
    El ejemplo más clásico de chequeo pasivo son los traps snmp. El cliente chequea el estado de sus servicios internamente y cuando debe notificar un cambio, solo en ese momento, se pone en contacto con el servidor de monitorización para indicarle en cambio.

    Como jugar con traps en nagios necesita de más piezas, se va a suponer que en el cliente se hace el chequeo pasivo del espacio libre en disco. En el cliente existirá un script, posiblemente ejecutado mediante CRON, que comprobará el espacio libre en disco. En caso de superar cierto límite, el script ejecutará además un comando "send_nsca" que enviará el aviso a nagios que mostrará la alarma correpondiente

    Definición del servicio pasivo en nagios:

            /opt/nagios-3.3.1/etc/objects/cliente.cfg

                define service{
                        use                             passive-service
                        host_name                       cliente.domain.tld
                        service_description             Disk Free
                        check_command                   check_dummy
                        notifications_enabled           1
                    }

       
    El script que se ejecutaría en el cliente sería similar al siguiente:

        [...]
            #Comprueba espacio libre
            # Si espacio libre < limite, entonces
                echo "cliente.domain.tld;Disk Free;3;Espacio insuficiente en disco" | send_nsca -H IP_Nagios -d ';' -c send_nsca.cfg     
        [...]

           
   
   

Limpiar caché en RAM (Linux)

#> sync
#> echo 3 > /proc/sys/vm/drop_caches

vg.-

 root@host:/proc$ free -m
             total       used       free     shared    buffers     cached
Mem:          5917       5671        246          0        110       2385
-/+ buffers/cache:       3175       2742
Swap:         9345         53       9292

root@host:/proc$ sync
root@host:/proc$ sudo echo 3 > /proc/sys/vm/drop_caches


root@mcfly:/proc# free -m
             total       used       free     shared    buffers     cached
Mem:          5917       3207       2710          0          1        139
-/+ buffers/cache:       3066       2851
Swap:         9345         53       9292

Utilidad: Muy poca...

Disco (vmdk) compartido entre VMs con VSphere 4

(MicroChuleta)

Pasos para compartir un disco (en este caso para Oracle RAC) virtual entre varias máquinas virtuales:

Crear un disco virtual desde una Service Console de la siguiente forma:

vmkfstools -c 2g -d eagerzeroedthick -a lsilogic /vmfs/volumes/XXXXX/ORACLE_SHARED_LUN_1.vmdk
vmkfstools -w /vmfs/volumes/XXXXX/hd.vmdk

 Agregar el disco a la primera VM en una nueva controladora SCSI cuyo modo de funcionamiento se cambiará a "Bus Sharing":

Usar una nueva controladora SCSI

Antes de arrancar la VM, convertir la nueva controladora SCSI de la que depende el disco compartido en Virtual o Phisical (según si nuestra arquitectura de VSphere tiene o no múltiples hosts ESX).

Repetir el proceso en el resto de VMs. Recordar que el disco compartido siempre debe ir a una nueva controladora SCSI con el "Bus Sharing" activado.

Thanks to: http://professionalvmware.com/2008/12/share-and-share-alike-sharing-vmdks-between-virtual-machines/