Convertir un servidor a virtual con VMWare

clonYa me he encontrado en más de una ocasión, con algún antiguo servidor que corría en un viejo hardware, pero que resultaba ser muy crítico y con configuraciones muy específicas. Quizá se trate de un antiguo servidor con decenas proyectos, cada cual con sus módulos y configuraciones específicas.

En estos casos, una buena opción es preparar un nuevo hardware, un nuevo SO, e ir migrando uno a uno, cada proyecto. Si se tiene tiempo y paciencia, claro. Si no, otra solución es usar VMWare Converter, una solución gratuita de VMWare que permite hacer un clonado de una máquina física, a virtual. De esta manera, podemos dejar de sufrir por si el viejo hardware del servidor decide pasar de forma definitiva a mejor vida.

La idea es ejecutar desde una máquina remota, VMWare  Converter, para crear una imagen clónica de una máquina física, y poder así, empezar a usar la nueva imagen VMWare, que sustituirá a la máquina remota. Lo bueno es que efectivamente, se realiza un clonado de la máquina física, incluyendo todos los ficheros, servicios, tareas programas, configuraciones, etc, asegurándonos así de contar con el mismo entorno, pero virtualizado.

En este ejemplo, he usado el siguiente escenario:

  • Máquina a clonar: Server físico Windows 2000 Server SP4 con IIS
  • Destino: ESX Host 4.0 en un VMware vCenter Server 4.1.0
  • Máquina desde la que se ejecuta el Converter: Windows Server 2003 32 bits

NOTA: No me he lanzado a usar la última versión de VMWare Converter, ya que he leído en múltiples sitios que aunque en la documentación oficial únicamente se advierte de no correr el VMWare Converter en una máquina Windows 2000, no dice nada de que este SO no pueda usarse como source. En cualquier caso, y para evitar problemas, he usado la última versión compatible con Windows 2000, la 4.0.1.

Continuar leyendo “Convertir un servidor a virtual con VMWare”

System DNS Cache en Linux

cache DNSEste fin de semana casi nos cargamos a un pobre servidor DNS por un exceso de consultas al realizar un envío de varios miles de mails. En algunos servidores Linux, no hay una caché DNS a nivel de sistema operativo, y por tanto, cada envío de mail requiere de su correspondiente resolución DNS, a pesar de que se estén enviando 1.000.000 de mails todos al mismo dominio @miempresa.com. [fuente, otra fuente, y más fuentes].

Ésto  lo podemos comprobar, por ejemplo desde mi portátil con Fedora, monitorizando con tcpdump las peticiones DNS y ejecutando en paralelo un “ping google.com”:

[root@AdriPC sh]# tcpdump -vvv -s 0 -l port 53
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:44:09.480324 IP (tos 0x0, ttl 64, id 14684, offset 0, flags [DF], proto UDP (17), length 59)
AdriIPC.36193 > google-public-dns-a.google.com.domain: [udp sum ok] 14321+ A? www.google.es. (31)
16:44:09.509206 IP (tos 0x0, ttl 64, id 14713, offset 0, flags [DF], proto UDP (17), length 66)
AdriIPC.51444 > google-public-dns-a.google.com.domain: [udp sum ok] 64003+ PTR? 8.8.8.8.in-addr.arpa. (38)
16:44:09.520190 IP (tos 0x0, ttl 48, id 61176, offset 0, flags [none], proto UDP (17), length 91)
google-public-dns-a.google.com.domain > AdriIPC.36193: [udp sum ok] 14321 q: A? www.google.es. 2/0/0 www.google.es. [3m28s] A 173.194.34.247, www.google.es. [3m28s] A 173.194.34.248 (63)
16:44:09.533873 IP (tos 0x0, ttl 64, id 14738, offset 0, flags [DF], proto UDP (17), length 73)
AdriIPC.50336 > google-public-dns-a.google.com.domain: [udp sum ok] 27187+ PTR? 247.34.194.173.in-addr.arpa. (45)

[…]

Si ejecutamos “ping google.com” una segunda vez, veremos como vuelve a capturarse la consulta DNS mediante tcpdump, confirmando así que no hay ningún tipo de caché DNS.

En la mayoría de escenarios, no necesitaremos una caché DNS, pero si tenemos un servidor que ofrece un servicio que hace un uso intensivo de resolución de nombres, seguramente nos merezca la pena buscar una solución.

Continuar leyendo “System DNS Cache en Linux”

Test de integridad de discos con S.M.A.R.T.

158829630_ad14f8265f_zHoy toca verificar el estado de los discos de un servidor CentOS 6 que en nuestro ejemplo, cuenta con un RAID 1 software con 2 discos SATA de 3TB cada uno. Para ello, lo primero que podemos hacer es asegurarnos de qué discos tiene nuestro servidor, con un simple df -h para ver las particiones y verificar como todas son del estilo “mdX” lo cual nos indica que se trata de un RAID software:

[root@myServer]# df -h
S.ficheros Size Used Avail Use% Montado en
/dev/md5 1,1T 81G 908G 9% /
[…]

Podemos verificar el estado del RAID con:

[root@myServer]# cat /proc/mdstat
Personalities : [raid1]
md5 : active raid1 sdb7[1] sda7[0]
[…]

Aquí observamos como por ejemplo, md5 está activo, y tiene un RAID1 entre sdb7 y sda7.

Con fdisk podemos ver si el servidor dispone de más discos, además de los que hemos observado a simple vista:

[root@myServer]# fdisk -l
Disco /dev/sdb: 3000.6 GB, 3000592982016 bytes
[…]
Disco /dev/sda: 3000.6 GB, 3000592982016 bytes
[…]

Además, el fdisk nos mostrará las particiones de cada disco, así como las particiones del tipo “mdX”. En nuestro caso, fdisk confirma que únicamente contamos con 2 discos, sda y sdb.

Pasemos, pues, a analizar la integridad de ambos discos con SMART.

Continuar leyendo “Test de integridad de discos con S.M.A.R.T.”

Python 2.7 en CentOS 6 con mod_wsgi

python2En este post, veremos cómo instalar una nueva versión de Python (la 2.7.5) manteniendo la versión del sistema (2.6.6 en CentOS 6), forzando al mod_wsgi de Apache a usar la nueva versión en lugar de la de sistema. La idea es no tocar la versión de sistema, puesto que si cambiamos dicha versión, seguramente nos encontraremos más adelante con problema de dependencias en prácticamente cualquier actualización o instalación que queramos hacer con yum.

De esta manera, lo que haríamos sería hacer una segunda instalación de la nueva versión de Python, que no comprometiera la instalación original. En el ejemplo, estamos usando un servidor CentOS 6.4 que por defecto, viene con Python 2.6.6, con un servidor Apache con mod_wsgi 3.2. Lo que queremos, es instalar Python 2.7.5 sin comprometer el Python del sistema, instalar los módulos de Python necesarios para nuestra aplicación, pero únicamente para la nueva versión 2.7.5, y finalmente, reconfigurar mod_wsgi para usar la nueva versión.

Para ello, podríamos seguir los pasos descritos a continuación:

Entorno

Comprobamos los detalles del sistema operativo:

[root@MyServer]#cat /etc/redhat-release
CentOS release 6.4 (Final)

Verificamos la versión de python del sistema:

[root@MyServer]# python --version
Python 2.6.6

Continuar leyendo “Python 2.7 en CentOS 6 con mod_wsgi”