29 abr

Comprobación base de datos de Bacula DBCHECK

Vamos hablar muy rápidamente del comando dbcheck, que nos permite limpiar la base de datos de Bacula de registros que estén mal y que ya no sean útiles, por norma general esto nunca nos debería pasar ya que si todas las tareas empiezan y terminan bien, los registros deben ser correctos, aun así en ciertas situaciones con muchos Jobs y muchos clientes nos puede pasar.

La solución muy muy sencilla, utilizamos en comando DBCHECK

Tal que así,

dbcheck  -c /usr/local/etc/bacula-dir.conf -v

Con la opción -c le damos la ruta del fichero de configuración de bacula-dir, nos mostrá todas las posibles opciones.

Hello, this is the database check/correct program.
Modify database is off. Verbose is on.
Please select the function you want to perform.

1) Toggle modify database flag
2) Toggle verbose flag
3) Check for bad Filename records
4) Check for bad Path records
5) Check for duplicate Filename records
6) Check for duplicate Path records
7) Check for orphaned Jobmedia records
8) Check for orphaned File records
9) Check for orphaned Path records
10) Check for orphaned Filename records
11) Check for orphaned FileSet records
12) Check for orphaned Client records
13) Check for orphaned Job records
14) Check for all Admin records
15) Check for all Restore records
16) All (3-15)
17) Quit

La opción 16, que somos valientes.

Select function number: 16
Checking for Filenames with a trailing slash
Found 0 bad Filename records.
Checking for Paths without a trailing slash
Found 1 bad Path records.
Print them? (yes/no): yes

Checking for duplicate Filename entries.
Found 0 duplicate Filename records.
Checking for duplicate Path entries.
Found 0 duplicate Path records.
Checking for orphaned JobMedia entries.
Checking for orphaned File entries. This may take some time!
Pruning orphaned Path entries isn't possible when using BVFS.
Note. Index over the FilenameId column not found, that can greatly slow down dbcheck.
Create temporary index? (yes/no): yes
Create temporary index... This may take some time!
CREATE INDEX idxFIchk ON File (FilenameId)
Temporary index created.
Checking for orphaned Filename entries. This may take some time!
Found 300000 orphaned Filename records.
Print them? (yes/no):

Y nada vamos dándole al yes/no según creamos oportuno las preguntas que nos hace.

Ale a disfrutarlo!

22 abr

Cerrar conexiones Time_wait en Linux

Algunas veces cuando utilizamos programas o ejecutamos servicios que tienden a crear muchas conexiones, nos podemos encontrar que si lanzamos.

netstat -a

Muchas de las conexiones que nos aparecen están en Time_wait, estas conexiones representan conexiones TCP que están esperando el tiempo suficiente para que el servidor remoto haya recibido su petición de finalizacion de la conexión, realmente son conexiones ocupando, si nos hacen daño incluso a la vista podemos hacer lo siguiente.

Comprobamos el tiempo en segundo que tenemos ahora configurado, por defecto en la mayoría de los sistemas son 60 segundos

cat /proc/sys/net/ipv4/tcp_fin_timeout60

Si queremos librarnos de esas conexiones de Time_wait de forma puntual hasta el próximo reinicio, deberemos hacer lo siguiente, así en caliente en real time que ahora se lleva mucho.

echo 20 ; /proc/sys/net/ipv4/tcp_fin_timeout

Si por lo contrario queremos un cambio mas permanente, deberemos hacer.

sudo vi /etc/sysctl.confnet.ipv4.tcp_fin_timeout=20

Y cuando reiniciemos el sistema tendremos el valor activo.

Y listo!!

NOOOO que aún hay más!

Imaginemos que lo que queremos es cortar esas conexiones que nos molestan a la vista, o que nos molesta al rendimiento de la máquina, que por viene siendo lo mismo, pues podemos utilizar…

Cutter, lo podemos instalar con

sudo apt-get install cutter

Esta aplicación nos permite cortar conexiones especificas según unos patrones, por ejemplo:

Queremos cortar todas las conexiones desde la ip 10.10.1.10, pues haremos

cutter 10.10.1.10

Ahora, queremos cortar todas las conexiones desde la ip 10.10.1.10, pero que lleguen por el puerto 22, pues haremos

cutter 10.10.1.10 22

Ahora, queremos cortar todas las conexiones que llegue a nuestro server desde la ip publica 8.8.8.8, por el puerto 80, pues haremos

cutter 8.8.8.8 ipserver 80

Y con esto podemos ir librándonos de forma puntal, de las conexiones que veamos sospechosas, son prudencia….

Ale a disfrutarlo!!!

Extra Lap

Copio un comentario del compañero de labores Tomàs, que es muy interesante, se puede ver en los comentarios o seguir leyendo ;)

Dice algo tal que así,

Otra opción para no limitar el tiempo de las Time_Wait es decir al sistema operativo que las recicle a medida que lo necesita. Eso se hace con las opciones:

net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1

Para activarlo puedes hacerlo con sysctl:

[[email protected] ~]# sysctl -a|grep _tw_net.ipv4.tcp_max_tw_buckets = 131072
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
[[email protected] ~]# sysctl -w net.ipv4.tcp_tw_recycle=1
[[email protected] ~]# sysctl -w net.ipv4.tcp_tw_reuse=1
[[email protected] ~]# sysctl -a|grep _tw_
net.ipv4.tcp_max_tw_buckets = 131072
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1

O con el echo:

[[email protected] ~]# cat /proc/sys/net/ipv4/tcp_tw_recycle /proc/sys/net/ipv4/tcp_tw_reuse
0
0
[[email protected] ~]# echo "1" ; /proc/sys/net/ipv4/tcp_tw_recycle
[[email protected] ~]# echo "1" ; /proc/sys/net/ipv4/tcp_tw_reuse
[[email protected] ~]# cat /proc/sys/net/ipv4/tcp_tw_recycle

/proc/sys/net/ipv4/tcp_tw_reuse 1
1

Claro, si quieres que se mantenga tras los reinicios, lo tienes que poner en el /etc/sysctl.conf:

net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

Y a partir de ese momento, el sistema reciclará las conexiones en time_wait y se acabarán los problemas.

18 abr

Mejorar el rendimiento de ZFS

El un post anterior explicamos como montar un zpool, con raidz con deduplicacion  más compresión, suele pasar que, por norma general instalamos el tinglado de ZFS por defecto, y normalmente al inicio funciona perfectamente y muy muy rápido, pero de repente un día nos damos cuanta que el rendimiento bajo sustancialmente. Entonces se nos empieza a caer el mito, el cielo se pone negro y todo se vuelve borroso.

Bueno, pues lo que voy a intentar es dar un poco de luz a ese panorama, explicando ciertos valores que son recomendables tocar en nuestro FreeBSD, para que gestione mejor todo el tinglado.

Vamos al lio.

Primero de todo, nos vamos a centrar en valores del sistema (Boot Loader Parameters), y van configurados en (/boot/loader.conf), nos debemos fijar como tenemos el sistema ahora, por si acaso debemos volver atrás, para eso utilizaremos.

sysctl -a

O podemos ver el valor establecido de aquella variable que queremos cambiar con

sysctl vfs.zfs.arc_meta_used

Primero de todo lo que vamos hacer es un comprobación muy sencilla, vamos a mirar como esta utilizando nuestro sistema la tabla ARC (La tabla ARC es el lugar en memoria, donde el sistema guarda los metadata y la cache de datos).

Debemos tener en cuenta que la memoria mínima que le asignemos al ARC será la que mantenga, todo lo demás desde mínimo al máximo, puede ser solicitado por cualquier otro proceso del sistema, la memoria de ARC no dispone de una prioridad alta, así que si algun proceso solicita memoria es más que probable que ARC ceda la que tiene utilizándose.

Esto nos sirve en el caso que dispongamos de otra aplicación que utilice un tamaño de memoria RAM mínimo para arrancar, podemos asegurarnos que el tamaño mínimo asignado a ARC dejara memoria suficiente para el resto de servicios

Memoria utilizada

sysctl vfs.zfs.arc_meta_used
vfs.zfs.arc_meta_used: 3839717456

Limite de la memoria permitida

sysctl vfs.zfs.arc_meta_limit
vfs.zfs.arc_meta_limit: 3887218688

Como podemos ver estamos al limite…, cosa que debemos cambiar.

Podemos hacer 2 cosas, o modificar el tamaño que utilizara la parte metadata de ARC añadiendo la variables vfs.zfs.arc_meta_limit o hacerlo de forma general, ya que en la tabla de ARC, guardaremos tanto los metadata como la cache de datos y que freebsd se lo gestione como buenamente quiera, pensemos que si modificamos por ejemplo el ARC_max a 4Gb y el arc_meta_limit a > 4GB,  es más que seguro que estemos forzando a que el sistema pase la cache de datos a disco, se puede aumentar el arc_meta, si tenemos activada la cache secundaria en disco SSD, que lo explicare como hacerlo en otro momento.

Bueno pues vamos a reservar un mínimo para todo el tinglado que expliqué del ARC.

Recomiendan utilizar esta regla para asignar un tamaño mínimo al ARC
4GB -> 512MB
8GB -> 1GB
etc

vfs.zfs.arc_min="8096M"

Contando que la máquina solo se dedique almacenar datos podemos aplicar las siguiente “reglas”, que por supuesto no son 100% fiables, debemos aplicar y ver como se comporta el sistema.

Ram x 0.5 – 512 MB

vfs.zfs.arc_max="3584M"

Ram x 2

vm.kmem_size_max="16G"

Ram x 1.5

vm.kmem_size="12G"

Una vez realizado esto debemos asegurarnos que los cambios que hemos hecho se comportan correctamente con el espacio libre del kernel, lo podemos hacer con el siguiente script.

#!/bin/sh

TEXT=`kldstat | awk 'BEGIN {print "16i 0";} NR>1 {print toupper($4) "+"} END {print "p"}' | dc`
DATA=`vmstat -m | sed -Ee '1s/.*/0/;s/.* ([0-9]+)K.*/1+/;$s/$/1024*p/' | dc`
TOTAL=$((DATA + TEXT))

echo TEXT=$TEXT, `echo $TEXT | awk '{print $1/1048576 " MB"}'`
echo DATA=$DATA, `echo $DATA | awk '{print $1/1048576 " MB"}'`
echo TOTAL=$TOTAL, `echo $TOTAL | awk '{print $1/1048576 " MB"}'`

Sumamos el espacio de utilización del kernel, más el utilizado por VDEV cache size, debemos controlar sobretodo vm.kmem_size ya que si nos pasamos con el valor, podemos tener un kernel panic al inicio del sistema, también debemos tener en consideración que vfs.zfs.arc_max, debe ser inferior a vm.kmem_size (ya que no solo ZFS utiliza la memoria), también debemos tener en cuenta, que si ponemos un valor muy alto en vm.kmem_size independientemente de vfs.zfs.arc_max, puede ser que el sistema no nos arranque, no hay problema, podemos cambiar en el gestor de arranque del sistema y asignar con (set vm.kmem_size = “512M”).

Si hemos cambiado los valores vfs.zfs.arc_max y vm.kmem_size el valor de kmem_size_max no se toma en consideración, pero se requiere ponerlo.

Seguimos con más opciones.

vfs.zfs.prefetch_disable="1"

Activar o desactivar esta opción, nos permite hacer que el sistema sea menos restrictivo a la hora de realizar las lecturas, de tal manera que la velocidad de lectura tiende a subir activandolo, este valor hace la función de precargar el siguiente bloque que el sistema predice que pueda ser leído, por supuesto en RAM , desactivarlo solo es recomendable para sistemas que tengan poca RAM.

Venga a por otro más

vfs.zfs.txg.timeout="5"

Este valor es el que controla el ZFS txg timeout, por defecto es 30 segundos, debemos cambiarlo si nos encontramos con cortes en la transferencia, ya que puede ser debido a esto,  normalmente el comportamiento por ejemplo en una linea de 1GB puede ser que  la tasa de trasferencia es oscilante,  o sea que por ejemplo se envían 100MB se para y de golpe envía 200MB etc etc, pensemos también que en el caso que tengamos activado la compresión, puede ser normal que baje la tasa de transferencia a disco mientras el sistema esta comprimiendo los datos, en ese caso lo que aumentara es la CPU

Ahora vamos a subir el numero de vnodes.

Los vnodes es un objeto dentro de la memoria del kernel que habla con la interfaz del sistema de ficheros( abre, lee, escribe, cierra,etc..), los vnodes pueden representar ficheros, directorios, colas….

De tal manera que en el caso que lleguemos al tope de vnodes que el sistema puede gestionar, pues nos encontraremos con la bajada de rendimiento del mismo. Con esto comprobamos su valor

sysctl vfs.numvnodes

Si nos quedamos sin “espacios” en la tabla nos saldrá en el messange.

La norma de freebsd es que 1 gb por cada 4Gb de RAM

vfs.zfs.write_limit_override=1073741824

Parámetros del sistema de ficheros

Ahora vamos a dejar el sistema base a un lado y nos centramos en opciones de ZFS.

Venga al lio!

Si los datos que tenemos en el raidz, no tiene una criticidad alta, podemos plantearnos quitar la opción de checksum, ya que la paridad del RaidZ yo nos proporciona una protección básica, de esta manera libramos carga del sistema de ficheros, pero como digo siempre y cuando los datos que tengamos no son críticos, sino en ningún caso debemos desactivar esta opción

Este cambio se realiza a nivel de pool de zfs, y debemos activarlo y desactivarlo en aquellos que nos interesen, de la siguiente manera.

sudo zfs set checksum=off myzpool

Podemos también desactivar a nivel de pool la opción atime, con esto evitamos que el kernel tenga que realizar updates de tiempo por cada acceso de lectura fichero, esto es necesario si o si, en el caso que los datos que tenemos en el zpool seas accesibles por diferentes servicios a la vez, como contra partida los snapshot ocuparan más.

Haremos

sudo zfs set atime=off myzpool

Ahora vamos a tocar lo que guardara ZFS en la cache, normalmente tendremos 1 cache, que es donde guardara por un lado los metadata de la tabla ARC y por otro cache de datos, si lo que queremos es ahorrar RAM, lo que podemos hacer es decirle a ZFS que solo guarde metadata en la cache. La buena practica seria activar 2 cache, en la primera cache, que va a RAM, le diremos que solo guarde la información metadata, y en la segunda cache que seria un disco rápido (SSD por ejemplo),  le diremos que guarde cache de datos.

Tenemos 3 opciones para “jugar” con la cache, all, metadata o none.

Mas adelante explicare como añadir un disco SSD, para utilizarlo de cache. Con el panorama actual lo dejaremos en all, pero para cambiarla seria.

zfs set primarycache=metadata myzpool

Como comento lo recomendable seria utilizar dos tiempos de cache, en el caso que dispongamos de un disco SSD para la segunda cache lo que haremos es decirle que la segunda cache que va a nuestro disco SSD. Tal que así

zfs set secondarycache=all myzpool

De esta manera lo que conseguimos es que se guarde en memoria la base de datos de metadata, y en el disco SSD se guarde la cache de datos más la metadata, la metadata solo se escribira en el caso que la cache de primer nivel se agote, cosa que no nos interesa, debemos evitar que llegue al disco, ya que en eso momento hemos muerto…. Game Over y a otra cosa mariposa.

Ahora toca la variable recordsize, el cambiar el valor de esta variable, se aplicara desde ese momento para los datos nuevos que añadamos.

Con esta variable le diremos la asignación de tamaño de bloque del pool, debemos tener cuidado con esto ya que la asignación de un tamaño grande, no es contraproducente a nivel de escritura, ya que si tenemos por ejemplo 128 k de bloque y escribimos bloques de 64k, realmente en el rendimiento no tendremos aumento de latencia, el problema nos lo podemos encontrar si la media de bloques escritos en nuestro sistemas es por ejemplo de 64k y tenemos el bloque de 128, por cada envía que hagamos enviaremos 128k, de los cuales 64k son datos vacíos que tiene que gestionar el sistema, a parte si  disponemos por ejemplo de una red de 100MB/s, si tenemos un tamaño de bloque ocupado de 128k, podremos enviar 700 veces por segundo.

Bueno aqui cada cual, yo personalmente lo tengo en 64k, el comando para modificarlo es

sudo zfs set recordsize=16k myzpool

Por ultimo podemos probar si existe alguna actualizacion de ZFS

sudo zfs upgrade my_poolsudo
sudo zpool upgrade my_pool

Con esto reiniciamos y comprobamos el rendimiento, podemos utilizar estos 3 sistemas para comprobar el rendimiento.

zfs-mon

atop -l  2

zpool iostat -v 2

Ale a disfrutarlo!!

16 abr

Splunk Storm ( API )

Vamos a comentar la solución Splunk Storm, básicamente nos ofrece la posibilidad de tener un visor centralizado para poder ver los logs de nuestro sistema de forma más amigable, os pego la imagen que sale en su pagina principal ya que es muy descriptiva.

splunkstrom

Como veis en la imagen, la idea es enviar los datos al servidor splunk de tal manera que después desde su pagina web podamos verlos.

Tenemos diferentes formas de enviar los logs:

1.- A través de los Forwarders, que básicamente lo que hacemos es instalar un cliente en nuestro servidor y configurarlo para que envíe los  logs al servidor de splunk.

2.- Network data, esta alternativa lo que hacemos es configurar el syslog de nuestro servidor para que envié los logs al servidor de splunk.

3.- File upload, pues eso, subimos el fichero directamente.

4.- A través de la API, podemos enviar el fichero/s a través de una llamadas curl.

Es este post voy a explicar como montarlo a través de la API.

Pues vamos al lio.

Primero de todo nos tenemos que dar de alta en www.splunkstorm.com, como veremos tenemos una cuota de 1GB gratis, una vez sobrepasada no podremos enviar mas logs, a no ser que vaciemos el storage o saquemos la cartera.

Bueno una vez dados de alta, debemos ir a la pagina principal y seleccionamos Inputs

ss1

Nos aparecerá algo tal que

ss2

Aquí tenemos las 4 formas de enviar que comete antes, como veréis tenéis en cada una un Learn more, que os permitirá saber como realizara.

Bueno nosotros seguimos con la API, le damos sobre el apartado de API y nos mostrar la siguiente imagen.

ss3

Nos quedaremos con los datos del Access token y Project ID.

Pues con todo esto ahora vamos hacer la llamada a la API con curl.

curl -u x:$ACCESS_TOKEN "https://api.splunkstorm.com/1/inputs/http?index=$PROJECT_ID&sourcetype=$SOURCETYPE"  -H "Content-Type: text/plain"  --data-binary @$FILE`

En la linea tenemos 4 variables.

$ACCESS_TOKEN = Debemos poner el numero que nos mostró en la ultima imagen

$PROJECT_ID = La identificación del proyecto (podemos tener mas de un proyecto)

$SOURCETYPE = Esta es la etiqueta con la que se marcara el “tipo” de fichero que vamos a subir, por ejemplo si queremos subir los logs de apache, el sourcetype podría ser “apache”

$FILE = La ruta hacia el fichero.

Como podéis ver es muy sencillo, y más sencillo es hacerse un pequeño scrprit que se vaya ejecutando cada x tiempo y nos envíe los logs a nuestro splunkstorm.

Una posible solución puede ser el siguiente script.

#!/bin/bash
 ACCESS_TOKEN=nnHQo1EJB8b3
 PROJECT_ID=d18c24f49dd
 function send_log {

echo Enviando $1

res=`curl -u x:$ACCESS_TOKEN 
 "https://api.splunkstorm.com/1/inputs/http?index=$PROJECT_ID&sourcetype=$2" 
 -H "Content-Type: text/plain" 
 --data-binary @$1`

if [[ $res == *ERROR* ]]; then

echo Mal
 else
 cat /dev/null > $1;
 /etc/init.d/$3 $4
 fi
 }

# Envio del messages
 send_log /var/log/messages messages

#Envio del syslog
 send_log /var/log/syslog syslog rsyslog rotate

# Envio log php
 send_log /mnt/usb/fpm-log/php5-fpm.log php-fpm php5-fpm reload

# Envio log nginx
 send_log /mnt/usb/nginx/error.log nginx

# Envio log nginx access
 send_log /mnt/usb/nginx/access.log nginxaccess nginx reload

# Envio de log rsync.log
 send_log /mnt/usb/rsync.log rsync rsync reload

# Envio del log de envio de splunk
 send_log /mnt/usb/splunk.log splunk

#Envio Accesos owncloud
 send_log /mnt/descargas/owncloud/owncloud.log owncloud

Bueno lo que hace el script es lo siguiente.

Añadimos nuestros datos de ACCESS_TOKEN y PROJECT_ID, al final del fichero iremos colocando los datos que queremos enviar a splunk, de la siguiente forma:, por ejemplo

# Envio log nginx access
send_log /mnt/usb/nginx/access.log nginxaccess nginx reload

Donde:

Send_log = Nombre de la funcion

/mnt/usb/nginx/access.log = ruta donde esta el log que queremos enviar

nginxaccess = sourcetype

nginx = servicio

reload = opcion

Como veis se realiza un reload de servicio del cual estamos enviando el log, ya que en el caso que el envío haya ido bien, el fichero se vacía, si en ese momento el servicio esta escribiendo en el log, es probable que deje de hacerlo, por ello hacemos en reload.

Es necesario en este caso, vaciar los ficheros que enviamos ya que sino siempre enviaremos datos repetidos.

Por ultimo una vez enviado los datos nos podemos ir a la opción de explore data, donde empezaremos a ver los datos enviados de una forma muy bontia.

A disfrutarlo!!

02 abr

Añadir memoria y cpu en caliente linux

Bueno como ahora está de moda el tema de la virtualizacion, muchos sistemas de virtualizacion nos permiten añadir CPU o RAM en las máquinas virtuales sin necesidad de apagarlas, o sea en caliente. En este post explicare como hacerlo en Linux, ya que en windows es bastante trivial.

Así que vamos al lio,

Es sistema de virtualización que utilizaremos es vmware esxi 5.1, lo primero de todo deberemos activar ambas opciones en las características de la máquina virtual, asi pues nos iremos a edit settings y marcaremos las siguientes opciones.

activate hot memory

Una vez activada las opciones arrancamos la máquina virtual.

Ahora vamos a ver la situación actual de la máquina, la memoria

free -m

total       used       free     shared    buffers     cached
Mem:          3825        264       3560          0         88         63
-/+ buffers/cache:        112       3712
Swap:         2047          0       2047

La cpu,

cat /proc/cpuinfo

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 37
model name      : Intel(R) Xeon(R) CPU           X5650  @ 2.67GHz
stepping        : 1
cpu MHz         : 2666.761
cache size      : 12288 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology tsc_reliable nonstop_ts
c aperfmperf unfair_spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm arat epb dts
bogomips        : 5333.52
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

etc

En resumen la maquina tiene 4 CPUS y 4 GB de RAM.

Bueno pues empezamos con la RAM, vamos al vcenter y aumentamos en 2GB la memoria RAM.

Captura de pantalla de 2013-04-02 13:45:47

Bueno, ahora nos vamos a la maquina Linux, lanzamos

grep line /sys/devices/system/memory/*/state

Nos debemos fijar en aquellos que nos salga offline.

Y ahora los activamos, tal que

echo online > /sys/devices/system/memory/memory[number]/state
free -m

Donde [number] pondremos el numero, si son muchos los que tenemos en offline, facilmente podemos hacer un for, ya que por norma general suelen ser secuenciales.

for i in numbers; do "echo online > /sys/devices/system/memory/memory$i/state"; done

free -m

Bueno ahora vemos el aumento de la RAM

total       used       free     shared    buffers     cached
Mem:        5873        309       5564          0         88         63
-/+ buffers/cache:        157       5716
Swap:         2047          0       2047

Pues ahora que tenemos la ram en su punto, vamos a por la CPU

Ampliamos la CPU en el vcenter.

Captura de pantalla de 2013-04-02 14:00:06

Y nuevamente nos vamos al linux, utilizamos el siguiente script ya hecho :)

#!/bin/bash
# William Lam
# http://engineering.ucsb.edu/~duonglt/vmware/

for CPU in $(ls /sys/devices/system/cpu/ | grep cpu | grep -v idle)
do
CPU_DIR="/sys/devices/system/cpu/${CPU}"
echo "Found cpu: "${CPU_DIR}" ..."
CPU_STATE_FILE="${CPU_DIR}/online"
if [ -f "${CPU_STATE_FILE}" ]; then
STATE=$(cat "${CPU_STATE_FILE}" | grep 1)
if [ "${STATE}" == "1" ]; then
echo -e "t${CPU} already online"
else
echo -e "t${CPU} is new cpu, onlining cpu ..."
echo 1 > "${CPU_STATE_FILE}"
fi
else
echo -e "t${CPU} already configured prior to hot-add"
fi
done

Comprobamos

cat /proc/cpuinfo | grep processor | wc -l
8

Y con esto ya tenemos más potencia en la máquina sin perder el uptime…

Ale a disfrutarlo!!!