martes, 29 de octubre de 2013

Dimensionamiento de filesystem en *nix

Un gran y famoso logo corporativo, no garantiza que las cosas se hagan bien, de hecho, lo más probable es que se hagan de la forma más barata posible, lo que se traduce en malos resultados.
Para los bien ponderados lectores, que aún no saben como tomar la decisión de dimensionar los fs en un sistema operativo *nix, este articulo les ayudara bastante.

Primero partimos de la base de que mínimo debe tener 40G si quieres poder rotar logs con holgura y evitar tener los FS a punto de llenarse.

Tomado en cuenta el punto anterior, siempre y como premisa usaremos LVM, ZFS, GEOM, Veritas LVM. instalar un sistema operativo "sin" volúmenes lógicos es pecado mortal y no se hace, porque no permite redimensionar los FS en el futuro, se trata de aprovisionar lo justo a cada punto de montaje y según se necesite se va ampliando, posterior a la instalación, algo que no se podría hacer sin un Logical Volumen Manager.

Tomado en cuenta el punto anterior, podemos crear los puntos de montaje que técnicamente se les denomina Logical Volume (LV) y formatearlos con el sistema de archivo que les parezca mejor. Infinidad de elecciones (UFS, XFS, ReiserFS, EXT[2-4], BtrFS, etc). 

Las particiones usuales básicas son:
  • /
  • /var
  • /tmp
  • /usr
  • /opt
  • swap
  • /home (queda a criterio personal)
Primero muchos aplicativos corporativos se instalan en /usr o /opt dependiendo de esto debemos otorgar más a uno u otro, lo que es seguro es que el OS en si esta instalado sobre /usr, con lo cual debe tener el tamaño que este requiere.
El "/" denominado root, debe tener mínimo 2G
El "/var" debe tener mínimo 4G dependiendo de los logs que genera el aplicativo o el historial que se requiere rotar.
El "/tmp" 1G
El "/usr" debe tener mínimo lo que se requiere para instalar el OS. 5G a 10G deberían bastar. El criterio base es mínimo requerido + 1G
El "/opt" es muy variable partir con 1G e ir ampliando según el aplicativo lo requiera.
La "swap" 2G para comenzar luego ampliar sobre demanda.

NOTA: en Linux es muy común crear una partición ext3 para el /boot de 300MB aunque 100MB bastan en algunos caso donde se actualiza el kernel podríamos quedar algo corto por tanto de 300 a 500MB es bastante recomendable si es un sistema LTS.

Si sumamos el gasto base, quedará libre más menos la mitad de un disco estándar 40G, aunque en la realidad los discos de servidores físicos son de mayor capacidad, el mundo de la virtualización permite aprovisionar tamaños menores. Estas recomendaciones son un punto de partida para servidores en en entornos productivos.

Por ultimo para los aplicativos productivos se recomienda crear un VG distinto, de tal forma que no genere acoplamiento con el OS.


jueves, 24 de octubre de 2013

*nix SysAdmin shellscripting framework

Como sysadmin recomiendo siempre saber programar y automatizar lo más posible las tareas cotidianas, todo proceso humano induce a error, si creas un script, puedes cometer errores en este, pero cuando esté ultra probado probablemente no vuelva a fallar, y el margen de error bajara considerablemente. Por otro lado alivia el trabajo rutinario, más tiempo de ocio al final, lo que se traduce en más tiempo para nuevas ideas. Por esto he decidido recopilar todas las cosas recurrentes escritas en varios scripts que voy encontrando por ahí, para ponerlas en un framework, y así poder escribir scripts más sencillos y pequeños centrándonos en la lógica del problema a solucionar y no en lo mismo de siempre.
Desde ya invito a quién quiera participar con ideas y mejoras a contactarme y cooperar en él, ya que es muy probable que tengamos problemas similares a los cuales aplicar este conjunto de funciones en para shellscripting.

Les dejo en enlace a github de nShell y a otros proyectos similares, obviamente esto no puede ser una idea nueva, pero yo no solo existe linux y bash (aunque ya lo quisieran muchos, me incluyo), por esto uno de los objectivos de nShell es hacerlo compatible con más de un shell unix.

martes, 8 de octubre de 2013

SQL JOINS

Hoy tuve un job tes,t que incluía una parte de SQL y como siempre he evitado los JOIN explícitos, ya que prefiero hacer las uniones en la clausula WHERE, algo que comienza a cambiar a partir de hoy, si lo hare solo por compatibilidad de lectura y para practicar querys standard.
Es importante aclarar que SQL no pasara de moda con los entornos NoSQL, ya que se está haciendo un gran esfuerzo en poner una capa SQL sobre NoSQL, Bigdata o MapReduce, está reeditada como newSQL. Por tanto tenemos Álgebra relacional para rato.

Dejo esta imagen que aclara todo sobre el producto cartesiano de un JOIN explicito.


sábado, 5 de octubre de 2013

Preparación de un ambiente de desarrollo python sin acoplamiento de dependencias.

Ingredientes:
  1. python 3 o 2
  2. virtualenv
  3. virtualenvwrapper
  4. IDE JetBrains PyCharm ( o el que te guste más, recomiendo pycharm. )
Para comenzar, se debe instalar la versión del interprete python, que se requiera para el proyecto o incluso podría instalar ambas ramas 2.x y 3.x.

Una vez tenga el interprete python instalado se puden instalar nuevas librerias con la herramienta pip (requiere ser instalado manualmente si utiliza OSX o Windows) o el package manager del sistema.(ports, pacman, MacPorts, apt, yum, etc.)

Para todos los ejemplos se usa pip, ya que es propio de python y no varia de sistema operativo.

¿Que es virtualenv?
virtualenv es una herramienta que permite crear entornos de desarrollo en python aislados, lo cual es de gran ayuda cuando se requiere trabajar con varios proyectos, debido a que evita el conflicto de librerías. También, mediante pip, permite exportar un lista de las librerías e importarlas en un nuevo entorno.

¿Que es virtualenvwrapper?
virtualenvwrapper no es más que un envoltorio con funciones en shell, para ayudar a trabajar con virtualenv de forma más rápida, cómoda y eficiente. (para Windows existe virtualenvwrapper-win)

pip install virtualenv
pip install virtualenvwrapper

Una vez instalado se debe configurar el .bashrc o profile de la Shell que este utilizando, soporta: bash, zsh y ksh

Edite el profile de su shell preferida y agregue la siguientes variables de entorno:

export WORKON_HOME=$HOME/.virtualenvs
source /usr/bin/virtualenvwrapper.sh

Guarde los cambios y recargue su profile,  ejemplo:

soruce .bashrc
mkdir $WORKON_HOME

A partir de aquí viene la parte emocionante y que más nos interesa, al tener cargado en nuestro $SHELL las funciones de viertualenvwrapper.sh, ya se puede comenzar a trabajar con el virtualenv e instalar paquetes con pip u otro PKGMGR de elección particular, todo dentro del entorno virtual.

Funciones básicas más importantes:

workon
mkvirtualenv
rmvirtualenv
lsvirtualenv


Comenzar a trabajar con el wrapper, se utiliza la instrucción workon permite ver los virtualenv creados y seleccionar un virtualenv para trabajar, el siguiente ejemplo muestra como crear un virtualenv:

workon
mkvirtualenv -p /usr/bin/python3 [test_env]

Ya está creado el nuevo virtualenv test_env, el cual puede ser integrado dentro del PyCharm IDE para trabajar e instalar paquetes como django.
Al no poner --no-pip contamos con pip dentro del virtualenv, con lo que se puede importar todos los paquetes de un requirements.txt anteriormente exportado con pip o en un futuro exportarlos para que nuestros colegas de profesión creen su propio entorno virtual.

Exportar paquetes requeridos (recomiendo hacer esto y ponerlo en el CSM[git|svn|mercurial|etc.] del proyecto)

pip freeze requirements.txt

Instalar los paquetes del requirements.txt

pip install -r requirements.txt

Con esto estaría relativamente cubierto todo lo referente a preparar un entorno de desarrollo lejos del caos!
Suerte.

viernes, 4 de octubre de 2013

FreeBSD 9.2 VirtIO

FreeBSD 9.2 Release

Mucho presume IBM pSeries virtualización de IO y hoy contamos por primera vez con esta característica en FreeBSD, Esto mejora el rendimiento de virtualizar las tarjetas de Ethernet y SCSI. virtio(4)
Esta característica nos permitiría crear nuestro propio VIO Server sobre FreeBSD

FreeBSD soporta los siguientes dispositivos VirtIO


  • Ethernet: dispositivo emulado por vtnet(4)
  • Block: controlador de disco emulado por virtio_blk(4) 
  • SCSI: emulacion de HBA SCSI mediante virtio_scsi(4)
  • Balloon: un pseudo-device que permite a una VM liberar memoria y retornarla al hypervisor medinate virtio_balloon(4)


para mas informacion:

  • virtio_balloon(4), virtio_blk(4), virtio_scsi(4), vtnet(4)


El soporte para VirtIO aparece por primera vez en 9.2.

jueves, 3 de octubre de 2013

IBM POWER SYSTEMS

PSERIES IBM POWER SYSTEMS, las princesas tecnológicas de las grandes empresas, como el mac book y OSX para un ciudadano común y corriente, es el POWER y AIX a una empresa. Muy cierto es su alto poder de procesamiento (RISC) su escalabilidad, la gran calidad del hardware, La paravirtualización del hardware IO. Pero cuando todo esto se mal dimensiona o se implementa mal y administra de peor manera durante años, se sufre mucho. Ya que parar la operación parar y poder mejorar el entorno es inviable producto del descontrol del los entornos. Lo normal es que esto no suceda y todo este relativamente en orden, pero existen excepciones y me toco pasar por un mal caso.
Mi objetivo no es enseñar como montarlo ya que esta todo aquí, por el contrario quiero comentar dos cosas fundamentales. Ordenar la arquitectura, definir bien que LPAR crear, dimensionar con capacidad de escalar las particiones, tomar en cuenta la redundancia, aprovisionar almacenamiento suficiente y duplicarlo cuando supera el 70% de la capacidad asignada hasta ese momento. Usar preferentemente NPIV en vez de vSCSI

miércoles, 2 de octubre de 2013

The Lord of Bandwidth Control!

Nine megs for the secretaries fair,
Seven megs for the hackers scarce,
Five megs for the grads in smoky lairs,
Three megs for system source;

One disk to rule them all,

One disk to bind them,
One disk to hold the files
And in the darkness grind 'em.