6 Ventajas de la virtualización – Casos reales

virtualizacionLa virtualización se basa en unir, integrar, mejorar.

Unir: En los centros de computo por lo general vemos una gran cantidad de máquinas fisicas corriendo un servicio por máquina, dejando de utilizar todo el poder de los procesadores actuales. El administrador de infraestructura se siente orgulloso (y con razón) de que sus 30 servidores funcionan como un reloj, pero si una máquina falla por lo general no se tiene un segundo servidor que pueda reemplazarlo.Con virtualización puedo migrar o recuperar un backup en una nueva máquina para no tener largos tiempos muertos.

En ocasiones en un solo servidor (sin importar su tamaño) se encarga de 1 o 2 aplicaciones corriendo dentro de ella. Por ejemplo la pagina de tu compañía esta corriendo sobre 1 máquina física? Que % de uso de CPU está en uso?

Lo que un sysadmin por lo general implementaría en el anterior ejemplo es un servidor con poca memoria como para no desaprovechar mucho la máquina (estoy hablando de una pagina simple… nada de alto trafico / aplicaciones)

Si se virtualiza un número de esos sistemas infrautilizados en un solo servidor físico, se ahorrará energía, espacio, capacidad de refrigeración y administración, debido a que se ha reducido el número de servidores físicos.

Algunas ventajas de la virtualización son:

Aislamiento: las máquinas virtuales son totalmente independientes, entre sí y con el hypervisor. Por tanto un fallo en una aplicación o en una máquina virtual afectará únicamente a esa máquina virtual. El resto de máquinas virtuales y el hypervisor seguirán funcionando normalmente.

Un hipervisor (en inglés hypervisor) o monitor de máquina virtual (virtual machine monitor) es una plataforma que permite aplicar diversas técnicas de control de virtualización para utilizar, al mismo tiempo, diferentes sistemas operativos (sin modificar o modificados en el caso de paravirtualización) en una misma computadora. Es una extensión de un término anterior, “supervisor”, que se aplicaba a kernels de sistemas operativos. (Tomado de wikipedia – mas info: google)

Seguridad: cada máquina tiene un acceso privilegiado (root o administrador) independiente. Por tanto, un ataque de seguridad en una máquina virtual sólo afectará a esa máquina.

Flexibilidad: podemos crear las máquinas virtuales con las características de CPU, memoria, disco y red que necesitemos, inclusive especificando a que “vlan” debe estar conectada, sin necesidad de “comprar” un servidor con esas características. También podemos tener máquinas virtuales con distintos sistemas operativos, ejecutándose dentro de una misma máquina física.

Agilidad: el despliegue o creación de una máquina virtual es un proceso muy rápido, básicamente la ejecución de un comando. Por tanto, si necesitamos un nuevo servidor lo podremos tener casi al instante, sin pasar por el proceso de compra, configuración, etc.

Portabilidad: toda la configuración de una máquina virtual reside en uno o varios ficheros. Esto hace que sea muy fácil clonar o transportar la máquina virtual a otro servidor físico, simplemente copiando y moviendo dichos ficheros que encapsulan la máquina virtual.

Recuperación rápida en caso de fallo: si se dispone de una copia de los ficheros de configuración de la máquina virtual, en caso de desastre la recuperación será muy rápida, simplemente arrancar la máquina virtual con los ficheros de configuración guardados. No es necesario reinstalar, recuperar backups y otros procedimientos largos que se aplican en las máquinas físicas.

Estas ventajas tienen un precio, que consiste fundamentalmente en una pérdida de rendimiento, es decir, una aplicación generalmente correrá más despacio en una máquina virtual que en un servidor físico.
La degradación dependerá de la tecnología de virtualización utilizada, de la configuración realizada a nivel hypervisor y de la propia aplicación.
Por regla general, las aplicaciones que más repercuten la pérdida de rendimiento son las que realizan operaciones frecuentes de entrada/salida.

Y el hardware?

Otro aspecto a tener en cuenta es que la máquina física deberá contar con suficiente memoria para poder arrancar todas las máquinas virtuales.

Si queremos crear, por ejemplo, 10 máquinas virtuales en un servidor físico y que estén funcionando simultáneamente, hay tecnologías que permiten hacerlo con 1 sola CPU física.

Pero al menos necesitaremos 1 GB de memoria para cada máquina virtual, más la requerida por el hypervisor, lo que daría lugar a unos requerimientos de unos 12 GB de memoria.
Es decir, necesitaríamos un servidor con 1 CPU y 12 GB de memoria (lo que es una configuración bastante extraña). Recordemos sin embargo que la mayoría de servidores actuales manejan procesadores de múltiples núcleos y algunas herramientas para virtualización permiten asignar por ejemplo a una máquina virtual múltiples núcleos.

En casa por ejemplo se pueden desplegar múltiples máquinas virtuales con el fin de realizar pruebas (instalar al mismo tiempo Windows y todas las máquinas Linux que queramos probar sin necesidad de formatear el disco duro con cada instalación)

Comandos útiles para el Programa Vi / Vim

Si eres como yo una persona que utiliza Vi / Vim a diario y que no conoce todas las opciones escribo esta pequeña guía para tu trabajo diario.

Para obtener un desplazamiento por páginas en el programa Vi / Vim:

Ctrl + f = Avanzar una página
Ctrl + b = Retroceder una página

Para obtener un desplazamiento en la línea donde se encuentra el cursor en el programa Vi / Vim:

$ = Ir al final de la línea
0 = Ir al principio de la línea (cero)
G = Ir a la última línea del documento

Eliminar información

x = Elimina el carácter donde se encuentra el cursor
dd = Elimina la línea donde se encuentre el cursor y desplaza todo el texto arriba.
D = Elimina el texto de la línea en la que se encuentra el cursor

Por ultimo en esta ocasión el comando más útil:

u = Deshacer el último comando ejecutado

Verificando sistema archivos ext3

Hace poco en /var/log/messages para los discos sda1 (500 Gb datos) y sdb1 (160 Gb disco2) apareció el mensaje:

EXT3-fs warning: maximal mount count reached, running e2fsck is recommended

Así que luego de investigar un poco y desmontar las particiones ejecuté:

Obtener información de disco sda1:

# tune2fs -l /dev/sda1
tune2fs 1.41.2 (02-Oct-2008)
Filesystem volume name:   datos
Last mounted on:
Filesystem UUID:          91d4689b-7ded-48eb-b1fe-e5f775fc465a
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              30531584
Block count:              122096000
Reserved block count:     0
Free blocks:              79567233
Free inodes:              30529428
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      994
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Wed Oct  8 13:38:57 2008
Last mount time:          Sat Nov 15 10:32:00 2008
Last write time:          Sat Nov 15 10:53:13 2008
Mount count:              0
Maximum mount count:      20
Last checked:             Sat Nov 15 10:44:54 2008
Check interval:           15552000 (6 months)
Next check after:         Thu May 14 10:44:54 2009
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      0e79fbd0-8686-423f-84b6-5fb7809c78c7
Journal backup:           inode blocks

Obtener información de disco sdb1

# tune2fs -l /dev/sdb1
tune2fs 1.41.2 (02-Oct-2008)
Filesystem volume name:   Disco2
Last mounted on:
Filesystem UUID:          b51558fe-7481-48bc-a8d8-1feb35dab6b3
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              9773056
Block count:              39072080
Reserved block count:     0
Free blocks:              31091518
Free inodes:              9763218
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1014
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Thu Aug 28 11:17:37 2008
Last mount time:          Sat Nov 15 10:32:00 2008
Last write time:          Sat Nov 15 10:45:33 2008
Mount count:              0
Maximum mount count:      31
Last checked:             Sat Nov 15 10:45:33 2008
Check interval:           15552000 (6 months)
Next check after:         Thu May 14 10:45:33 2009
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      896b186d-e037-4b44-9da0-3043010d1e54
Journal backup:           inode blocks

Verificación y tunning de sda1

# e2fsck -fpDv /dev/sda1<

2156 inodes used (0.01%)
84 non-contiguous inodes (3.9%)
número de nodos-i con bloques ind/dind/tind: 1922/846/0
42528767 blocks used (34.83%)
0 bad blocks
2 large files
2043 regular files
104 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
--------
2147 files

Verificación y tunning de sdb1

# e2fsck -fpDv /dev/sdb1
9838 inodes used (0.10%)
276 non-contiguous inodes (2.8%)
número de nodos-i con bloques ind/dind/tind: 5864/964/1
7980562 blocks used (20.43%)
0 bad blocks
2 large files
9276 regular files
553 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
--------
9829 files

Además coloqué para que el sistema verificara automáticamente luego de 20 montajes de las particiones:

# tune2fs -c 20 /dev/sda1
# tune2fs -c 20 /dev/sdb1

Y listo

Rsync para sincronización local (2 directorios mismo pc)

El escenario

Tengo los datos importantes en mi disco duro local y deseo hacer una copia de seguridad ya sea en una memoria USB previamente montada o en un segundo disco duro dentro de la misma máquina la cual solo utilizo para backups.

Dentro de dicho directorio (origen) tengo archivos que no cambian de backup en backup (o cambian muy poco) y por lo tanto no es necesario sobre-escribirlos en el destino de backup. En el directorio origen adicional tengo subdirectorios algunos de los cuales están vacíos y por lo tanto no deben ser copiados.

Parece complejo cierto? pero la solución es simple

El comando

# rsync -uarmzhP /dir/origen/ /dir/destino

-u : update

-a: archive mode

-r: recursive

-m: no envía los directorios vacíos

-z: comprime mientras transfiere (así se ahorra tiempo y ancho de banda)

-h: presentación para humanos

-P: muestra el progreso de la copia

Si deseo borrar en el directorio destino los archivos que ya no esten en el directorio origen el comando completo sería:
# rsync -uarmzhP --delete /dir/origen/ /dir/destino

donde

– -delete: borra en el destin0 los archivos que ya no estén en el origen

Nota: son dos guiones seguidos (-  -)

Acceso por SSH con llave de autenticación en lugar de clave.

Introducción

Para este escrito utilizo las palabras llave en lugar de Key y clave en lugar de password.

SSH es una herramienta muy utilizada entre los administradores de sistemas. Sin embargo, confiar el acceso en una clave ingresada por un humano no es algo muy astuto. Algunos scripts de ruptura de claves pueden irrumpir en el sistema debido a un usuario perezoso con una clave simple o débil. Un buen administrador de sistemas es el que escoge e implementa buenas claves de acceso.

La buena noticia es que existen formas de permitir el acceso sin preocuparse por estar escribiendo complicadas claves en ocasiones difíciles de memorizar. El método que intentare explicar es llamada criptografía asimétrica.
La llave privada del usuario es la que garantiza la autenticación. De tal manera que al usted bloquear la cuenta del usuario se bloquea también el acceso.
Otra ventaja de este método es que no se necesitan diferentes claves para ingresar a diferentes servidores. Así que te puedes autenticar utilizando la llave personal pero privada en todos los servidores sin escribir complicadas claves.
Por lo tanto es posible hacer accesos a los servidores sin la pregunta de tu clave con este método.

Como hacerlo

1.Generando la llave de autenticación.

En la máquina cliente, el usuario debe generar un par de llaves publica / privada que lo identificaran a si mismo en los servidores. Puede así mismo elegir si ser protegida con clave o no.
Al dejar la llave sin clave cualquiera que tenga acceso al archivo de la llave (por ejemplo root en la máquina del cliente) obtendría el mismo nivel de acceso que el usuario y no se le preguntaría ninguna clave cuando el cliente intente conectarse al servidor.
Protegiendo las llaves con clave significa que cada vez que el usuario intenta conectarse al servidor con su llave personal la clave para descifrarla es preguntada.
Esto por supuesto es mas seguro, ya que cualquiera que obtenga el archivo de la llave solamente verá una versión codificada.

Para generar el par de llaves ejecutamos (en el equipo cliente)

~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/mmejiav/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/mmejiav/.ssh/id_rsa.
Your public key has been saved in /home/mmejiav/.ssh/id_rsa.pub.
The key fingerprint is:
de:32:99:54:12:92:1b:5b:4e:da:68:e2:10:b1:cb:b0 mmejiav@feroz
The key\’s randomart image is:
+–[ RSA 2048]—-+
|  ..  …        |
|  ..  o.o.       |
|. ..   @. .      |
| +… * oo       |
|E oo o  S        |
|    .  o +       |
|        * .      |
|         o       |
|                 |
+—————–+

En este ejemplo dejé el directorio y archivo por defecto y escribí una clave a ser utilizada como explique antes.
Si necesita cambiar la clave o adicionar una nueva

~$ ssh-keygen -p
Enter file in which the key is (/home/mmejiav/.ssh/id_rsa):
Enter old passphrase:
Key has comment \’/home/mmejiav/.ssh/id_rsa\’
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.

Pregunta ubicación de la llave, clave antigua, nueva clave y repetir la nueva clave.
Esta operación no cambia las llaves publicas / privadas. Solo cambia la clave para el login.

2. Instalar la llave publica en los servidores

Una vez que la llave publica es instalada en el servidor, el acceso es concedido sin pregunta de clave.
SSH usualmente viene con una utilidad llamada ssh-copy-id que sencillamente adiciona el contenido de ~/.ssh/id_rsa.pub del cliente a la localización ~/.ssh/authorized_keys en el servidor.

El paso es copiar la llave antes generada en el servidor al cual queremos ingresar.

~$ ssh-copy-id -i .ssh/id_rsa.pub mmejiav@192.168.0.6
mmejiav@192.168.0.6\’s password:
Now try logging into the machine, with \”ssh \’mmejiav@192.168.0.6\’\”, and check in:

.ssh/authorized_keys

to make sure we haven\’t added extra keys that you weren\’t expecting.

En este punto la clave de acceso es necesaria.  También se puede copiar la llave generada en el primer paso con el comando scp.
En dicho caso se debe copiar el archivo id_rsa.pub en el servidor y agregar el contenido de dicho archivo en el final del archivo authorized_keys luego de copiar el archivo

En el servidor:

#cat id_rsa.pub >> .ssh/authorized_keys

Conclusión

Este método mejora bastante la seguridad y además permite mejorar el acceso en varios servidores sin muchas claves. Existen otros métodos algoritmos y opciones para utilizar, se los dejo a ustedes.

Si encuentras errores o discrepancias, no te funciona algo o algún consejo para mejorar por favor dímelo para corregirlo.

Mejoramiento de conexiones ssh – algunos consejos

Puntos a mejorar en el sistema de logeo a las máquinas GNU/Linux

Recomendaciones de mejoramiento

  • Configurar el servicio SSH en cada servidor con el fin de que utilice el Protocol 2 de SSH:
    Hay dos versiones de ssh en cuanto a su protocolo de comunicación, la versión 1 y la versión 2. La 1 esta en desuso pero todavía se incluye por compatibilidad, tiene varias vulnerabilidades conocidas y su uso no es ya recomendable. Un error frecuente es dejar al demonio ssh que permita el uso de las dos versiones (Protocol 2,1). Para evitar el uso del protocolo 1 y sus posibles ataques a este, basta con indicar en el archivo de configuración de ssh que solo admita comunicaciones de ssh basadas en el protocolo 2.
  • Configurar el número de segundos en que la pantalla de login estará disponible para que el usuario ingrese su nombre de usuario y contraseña, si no lo hace el login se cerrará, evitando así dejar por tiempo indeterminado pantallas de login sin que nadie las use, o peor aun, que alguien este intentando mediante un script varias veces el adivinar un usuario y contraseña.
  • No permitir acceso al usuario root por defecto. En su reemplazo se puede crear en cada máquina un usuario y darle a este permiso de ejecutar comandos como super-usuario o poder subir a super-usuario.

Para monitorear los comandos que dicho usuario ejecuta en la máquina se puede configurar el servicio SUDO y generar logs de las actividades.

  • Configurar la cantidad de veces que un usuario puede equivocarse al ingresar el usuario y/o contraseña, luego de dicha cantidad se perderá o cerrará la conexión. Por supuesto es totalmente posible volver a intentarlo, pero de esta forma evitaremos ataques basados en la persistencia de la conexión o reintentos de ingresar con un usuario y/o contraseña errados, como se perderá al N veces intentos de conexión, el ataque cesará.
  • Configurar la cantidad de conexiones simultáneas de login que permitirá el sshd por ip que intente conectarse. Sin embargo, una vez logueados en el sistema, es posible tener más de 3 terminales de ssh, se refiere exclusivamente a pantallas de login.

Más adelante se puede igualmente configurar manejo de llaves públicas y privadas entre los servidores y las máquinas o personas que tendrán acceso a dichos servidores (fingerprint). Esto evitaría el ingreso de personal no autorizado aun conociendo el usuario y/o password y manejo controlado de quien ingreso y a que horas a cada servidor.

Comando Awk aplicado

Hace poco mi amigo Fabian tenía la necesidad de sacar unos datos de un archivo log. Mas específicamente unos campos para obtener estadísticas. el contenido del archivo (llamado errores.log) se veía mas o menos así:

[23/Jul/2007:13:49:30] info ( 7298): CORE3282: stdout: INFO [23 Jul 2007 08:49:30,862] – EventID = launchApplication
[23/Jul/2007:13:49:30] info ( 7298): CORE3282: stdout: INFO [23 Jul 2007 08:49:30,863] – ActionID = null
[23/Jul/2007:13:49:30] info ( 7298): CORE3282: stdout: INFO [23 Jul 2007 08:49:30,863] – Adding appID=109
[23/Jul/2007:13:49:30] info ( 7298): CORE3282: stdout: INFO [23 Jul 2007 08:49:30,863] – Starting to process the event …
[23/Jul/2007:13:49:30] info ( 7298): CORE3282: stdout: INFO [23 Jul 2007 08:49:30,863] – Setting state to MyDesktop
[23/Jul/2007:13:49:31] info ( 7298): CORE3282: stdout: TAWSHELL=rsh
[23/Jul/2007:13:49:31] info ( 7298): CORE3282: stdout: Username=pepejefe
[23/Jul/2007:13:49:31] info ( 7298): CORE3282: stdout: AppServerName=192.168.1.2
[23/Jul/2007:13:49:31] info ( 7298): CORE3282: stdout: AppCommandLine=/apps/dir1/di2/app.sh
[23/Jul/2007:13:49:31] info ( 7298): CORE3282: stdout: AppServerOS=Linux
[23/Jul/2007:13:49:31] info ( 7298): CORE3282: stdout: ProtocolType 0
[23/Jul/2007:13:49:31] info ( 7298): CORE3282: stdout: UseProxy 0

Necesitaba extraer las lineas con la información del Username y del AppCommandLine.
Aquí entra en acción la herramienta AWK

AWK es un lenguaje de programación diseñado para procesar datos basados en texto, ya sean ficheros o flujos de datos.awk es un lenguaje de búsqueda y procesamiento de patrones. Esto quiere decir que awk es capaz de buscar un patrón dentro de un archivo (al igual que grep) y tratarlo según unas operaciones determinadas. Con awk se pueden desarrollar auténticos programas.

Según esto awk es capaz de procesar un archivo con datos organizados por columnas y generar nuevas columnas con los valores resultantes de realizar ciertos cálculos u operaciones.

A diferencia de comandos Unix como grep y sed, que filtran y procesan texto, awk incorpora su propio lenguaje de programación, siendo capaz de ofrecer operaciones aritméticas, relaciones lógicas y variables. Se pueden desarrollar programas con awk que procesen la entrada estándar o un archivo, realizando tareas como tratar archivos de texto como bases de datos. El lenguaje de programación awk incluye estamentos como for, while e if-else, así como un conjunto de funciones y variables incorporadas.

Algunos enlaces para saber más opciones sobre esta herramienta pueden ser:

  • The GNU Awk User’s Guide
  • Guía interesante con opciones y ejemplos de Awk

Mas información? recuerda, el man (man awk) y google son tus amigos:

Antes de entrar en materia primero se debe señalar que el separador por defecto de awk es el espacio.
El comando seria entonces:
$ awk '/Username/||/AppCommandLine=/{print $1" "$6,$7}' errores.log >> depurado.log

Extraigo los campos Username o AppCommandLine. El doble pipe “||” es el operador OR y los campos $1 (fecha) y $6 y $7 que tienen la información necesaria. Todo esto lo envío al archivo “depurado.log”

De esta manera un archivo de 146 mb conteniendo muchos campos no útiles se convierte en 850 kb de útiles resultados que pueden ser pasados a una hoja de calculo para su organización y presentación.