SafeChildren Banner

Havoc Oracle Solaris Experts

lunes, 24 de septiembre de 2007

Solaris ForceDirectIO y Sistemas de Backup para Oracle - Parte I

Oracle 8i ya es una "reliquia" aunque para muchos todavía nos encontramos muy contentos con esta versión, sin embargo, ... debemos "OraclEvolucionar"

Uno de los consejos que se daban por el mundo de los DBA's sobre Solaris + Oracle8i era el uso de ForceDirectIO en el montaje de los discos para hacer que Oracle no usase los buffers del sistema de archivos.

Esto ha sido optimizado en las versiones 9i y 10g, sin embargo todavía podemos utilizar, sobre todo en la 9i, la opción ForceDirectIO para obtener un beneficio extra en el rendimiento. El problema era que si se utilizaban las herramientas del sistema para realizar las copias de seguridad el impacto era realmente elevado. Esto hacía que la copia de seguridad se alargase en el tiempo de forma alarmante.

Para ello, podemos realizar las pruebas con los parámetros genéricos (mount -F ufs, mount -F ufs -o logging) y los opcionales (mount -F ufs -o forcedirectio) ForceDirectIO. Si nos fijamos y hacemos de las configuraciones básicas nuestra líneas base tenemos los siguientes datos:


Como podemos observar al utilizar forcedirectio con archivos grandes, el rendimiento de cp es realmente pésimo (esto también se refleja en rsync), sin embargo cp8m (GNU cp con modificaciones) realiza la copia en prácticamente la mitad de tiempo.

Si esto lo extrapolamos a una copia de 70 Gb estaríamos hablando de copiar en 2h lo que antes lo hacíamos en 8h.


Qué modificaciones Tiene CP8M

cp8m incluye una pequeña modificación en el tamaño del buffer, pasando de 512 Kb a 8 Mb, de esta forma se consigue un aumento de rendimiento.

Vamos a modificar el código de GNU Core Utils.

1.- Debemos bajarnos la versión de GNU Core Utils
2.- Descomprimimos el tar y editamos el archivo
/coreutils-6.9/src/copy.c

Sobre la línea 349 debemos sustituir
size_t buf_size = ST_BLKSIZE (sb);
por
size_t buf_size = 8388608;

3.- Compilamos con SunCC (Podemos utilizar -fast -native siempre que estemos en la misma arquitectura que producción)
4.- Instalamos el paquete en /usr/local/bin
5.- Copiamos /usr/local/bin/cp a /usr/sbin/cp8m

Con esto ya hemos concluido con la primera parte viendo como el impacto de forcedirectio sobre las herramientas del sistema puede hacer que nuestras tareas de copia de seguridad se vean realmente afectadas.

En la segunda parte, veremos como podemos hacer que cp8m + nfs sean muy buenos aliados para el sistema de backup.

Un Saludo,
Urko

martes, 18 de septiembre de 2007

Almacenamiento y Disponibilidad - Parte I

Hace mucho tiempo que se sabe del almacenamiento en Red, es cierto, sin embargo cada día nos damos cuenta de la importancia de tener nuestros datos disponibles desde cualquier punto en cualquier momento.

Una de las opciones que me ha gustado siempre ha sido iDisk por su simplicidad y su rendimiento. Esto unido a un diseño innovador (cuando se empezó a promocionar pocos usaban más allá del WWW en Internet) hizo que se ganara mis respetos.

Si trasladamos esto a un entorno profesional/semi-profesional vemos que existen algunas arquitecturas (desde tiempo memorables) que ya lo facilitan, nfs, cifs, entre otros.

Sin embargo, por qué ese resurgir del Almacenamiento en Red?
Por la movilidad! Ese nuevo concepto de todo debe estar conectado (sin cables) y todo debe estar disponible en cualquier momento y desde cualquier dispositivo.

Ahora las PDA, BlackBerry y sucedáneos son nuestros mejores amigos (oh dios! cómo he vivido sin mi correo push) y nuestros datos deben ser accesibles (aunque no los use) . Todo esto hace que nuestros requisitos y debamos volver a aquellos que durante muchos años se tachó como incorrecto: Centralización

Durante estos días continuaré con el artículo de "Opinión" sobre NAS y las nuevas problemáticas.

Un Saludo,
Urko


He Vuelto!

Después de muchos días, al fin he vuelto.

Esto supone que vamos a continuar con nuestras "cosillas" pendientes y otras nuevas que a día de hoy resultan muy interesantes.

Durante finalizaré la entrada sobre Solaris y Proxy Reverso, además de algunas nuevas sobre NAS (Network Area Storage) y cómo No, Solaris 10.

Me gustaría que la espera valga la pena!

Un Saludo,
Urko

domingo, 20 de mayo de 2007

Problemas en el blog

Queridos Amigos,

Como os habreís dado cuenta, durante este tiempo he tenido varios problemas con el servidor de test que utilizo (tanto para hacer los splash como para almacenar los scripts/configuraciones/etc.). Esto se debe a que me estoy mudando de casa, y entre una cosa y otra, no tengo todavía internet en la nueva casa (espero que sea pronto)

Por ello, os pido un poco de paciencia hasta tener todo solventado.

Un Saludo,
Urko

domingo, 29 de abril de 2007

Standard CHROOT vs Solaris 10 Zones

Hace un tiempo comencé una entrada sobre cómo Instalar BIND sobre Solaris 9 en un CHROOT, pero pasado un tiempo, las cosas evolucionan y como no, Solaris También.

Por ello, ahora teniendo Solaris 10u3 ya estamos en disposición de empezar a utilizarlo en entornos de producción, y con ello, las nuevas oportunidades que nos ofrece.

En Solaris 10 tenemos la evolución de los gestores dinámicos (pooladm) con la virtualización "Solaris Containers", por ello, es muy interesante utilizar esta tecnología para "securizar" partes de nuestro sistema operativo.

Podemos dividir la instalación de un Servidor de Nombres (BIND) sobre una Zona de Solaris No Global y de esta forma ya tendremos parte del trabajo hecho (la zona tiene soporte limitado)

Por ello, vamos a empezar una serie de artículos sobre la utilización de las Zonas para "securizar" aplicaciones.

Hasta Pronto,
Urko

viernes, 20 de abril de 2007

gUASAX La evolución de gUASAJ sobre Flex

Allá por año 2004, un grupo de amigos empezamos a crear un FrameWork para el diseño de aplicaciones J2EE llamado gUASAJ ahí empezó todo ... a día de hoy Angel Blesa portó gUASAJ a la tecnología Flex llamándolo gUASAX.

Por ello, y como nuevas prácticas (y por la parte que me toca) vamos a empezar una serie de artículos sobre Tuning de gUASAX, Instalación y Buenas Prácticas aplicadas a Sistemas.

La primera parte de esta serie de artículos irá orientado a la instalación del entorno de producción y pruebas.

Hasta pronto ...

Reverse Proxy APACHE + MOD_PROXY vs SQUID (Parte 2)

Updated SEP.2009: Esta entrada la escribí hace mucho tiempo, existe una versión más actualizada de cómo instalar squid sobre Solaris 10 en esta dirección http://sparcki.blogspot.com/2009/08/instalar-squid-en-solaris-10-parte-1.html o a en esta otra dirección http://sparcki.blogspot.com/2009/09/instalar-squid-como-proxy-reverso-en.html aunque si quieres puedes continuar con la entrada original para Solaris 9 y squid 2.6.

Ha pasado ya tiempo, pero aquí estamos de nuevo.

En el artículo anterios hacíamos un resumen de lo que debíamos tener (y qué queríamos montar) ahora, vamos a empezar con las partes necesarias.

Las tareas que vamos a realizar son las siguientes:
Descargar / Compilar SQUIDDescargar / Compilar ApacheDescargar / Compilar Mod_SecurityDescargar / Compilar Mod_html_proxyPruebas de Funcionamiento
Como la mejor de las explicaciones es la práctica, ahí vamos, pero debemos establecer unos requisitos mínimos antes de poder comenzar:


A.- Preparación Entorno de Compilación

Es importante entender que las pruebas las he realizado con un entorno Sun Solaris 9/10 SPARC/x86 utilizando el compilador SunCC 5.9 Build40_1 2007/02/08 y con el binario CC en nuestro PATH.

1.- Instalación SQUID Proxy Cache

La página oficial de Squid Proxy Cache es http://www.squid-cache.org y nos bajaremos la versión estable 2.6 más reciente (a día de hoy es la versión 2.6-STABLE12)

$ export CC=cc
$ export CXX=cc
$ export CFLAGS="-fast -native"
$ export CXXFLAGS="-fast -native"
$ cd SQUID-CACHE-DIR
$ ./configure
--enable-delay-pools
--enable-forward-log
--enable-default-err-language=Spanish
--enable-cache-digests
--with-large-files
--with-pthreads
--enable-x-accelerator-vary
--enable-removal-policies
--enable-delay-pools
--disable-internal-dns
--prefix=/opt/applications/squid-2.6

...

$ make
...
$ make install
...

El uso de los flags "-native -fast" sólo son válidos si estamos compilando en un entorno igual al de producción, si no es así podemos utilizar la siguiente parametrización

UltraSPARC III
CFLAGS="-fast -xarch=v8plusb"

UltraSPARC IV
CFLAGS="-fast -xarch=v9 -xlibmopt -xreduction"

x86 - Opteron/Intel
CFLAGS="-fast -xarch=ss2"

x64 - Opteron
CFLAGS="-fast -xarch=amd64"

Puedes encontrar un archivo shell para realizar las tareas de forma automática aquí un poco "manual"

2.- Configuración SQUID Proxy Cache


2.1.- Configuración Directorios

Vamos a crear un grupo y un usuario para hacer más segura la instalación, además después de instalar squid, tendremos la siguiente estructura de directorios, sin embargo

$SQUID_BASE
/bin
/etc
/libexec
/man
/sbin
/share


Para hacer una configuración más personalizada vamos a realizar algunos cambios, como crear una nueva estructura de directorios para la caché, el PID, y el log de la siguiente forma:

$SQUID_BASE
/var
/cache
/logs
/run


# export SQUID_BASE=/opt/applications/squid-2.6
# mkdir -p $SQUID_BASE/var/logs
# mkdir -p $SQUID_BASE/var/run
# mkdir -p $SQUID_BASE/var/cache
# groupadd -g 7000 proxy
# useradd -g proxy -s /bin/false -d /dev/null -u 7000 proxy
# passwd -l proxy
# chown -R root:root $SQUID_BASE
# chmod -R o-r,o-w,o-x $SQUID_BASE
# chmod -R proxy:proxy $SQUID_BASE/var
# chown root:proxy $SQUID_BASE/var/run

2.2.- Configuración SQUID

Desde la versión 2.6 de SQUID se han introducido cambios en el archivo de configuración, muchos de ellos pertenecen a la versión 3.x de SQUID que está en fase de desarrollo. Por ello, la forma antigua de configuración de Transparent Proxy, ha sido modificada (y simplificada). Los parámetros que debemos ajustar son los siguientes:

########################################################
## PARAMETROS ADMINISTRATIVOS
########################################################
visible_hostname NOMBRE-REVERSE-PROXY (en nuestro caso rev-proxy1.test.com)
cache_effective_user USUARIO-QUE-EJECUTA (en nuestro caso proxy)
cache_effective_group GRUPO-QUE-EJECUTA (en nuestro caso proxy)
httpd_suppress_version_string on (elimina la versión en el header)

########################################################
## PARAMETROS PROXY TRANSPARENTE
########################################################
http_port PUERTO vhost (en nuestro caso el puerto 80)
icp_port 0
cache_peer WEBSERVER-ORIGINAL parent 80 0 originserver default (en nuestro caso 192.168.1.72)

Aquí tenemos varias propiedades que han sido importadas de la versión de desarrollo como son:
httpd_suppress_version_string y http_port PUERTO vhost
  • httpd_suppress_version: Tiene una función igual a ServerTokens Minimal de Apache y tiene como objetivo no mostrar la versión de SQUID
  • http_port Nº_PUERTO PARAMETRO: Tiene como función hacer que SQUID se comporte como un proxy transparente si ponemos como parámetro vhost.
  • cache_peer WEBSERVER-ORIGIANL parent 80 0 originserver default: De esta forma hacemos que WEBSERVER-ORIGINAL (su IP) sea el servidor principal (aunque la propiedad sirve para hacer que WEBSERVER-ORIGINAL sea la caché principal, por ese mismo pincipio, se puede hacer el proxy transparente).
Más parámetros de configuración necesarios para una correcta configuración del sistema SQUID

########################################################
## PARAMETROS CACHE
########################################################
cache_dir ufs /opt/applications/squid-2.6/var/cache 2048 16 256
pid_filename /opt/applications/squid-2.6/var/run/squid.pid

########################################################
## PARAMETRIZACION DE LA CACHE MEMORIA
########################################################
cache_replacement_policy heap LFUDA
memory_replacement_policy lru

########################################################
## PARAMETROS TAMA!NO CACHE
########################################################
cache_mem 50 MB
cache_swap_low 90
cache_swap_high 96
maximum_object_size 150 MB
maximum_object_size_in_memory 64 KB

########################################################
## PARAMETRIZACION ERRORES
########################################################
error_directory /opt/applications/squid-2.6/share/errors/Spanish
err_html_text NOMBRE@CORREO.COM

########################################################
## PARAMETRIZACION SEGURIDAD
########################################################
acl SSL_ports port 443-563 # SSL
acl Safe_ports port 80-84 # http

# Permitimos utilizar el CONNECT a puertos seguros, hemos deshabilitado el acces
# para POP y SMTP puesto que nos pueden ocasionar fallos de seguridad, ademas, nos
# pueden utilizar como SPAMMER's
acl CONNECT method CONNECT

# Permitimos acceder al sistema de configuracion solo desde LOCALHOST
http_access allow manager localhost
http_access deny manager

# Cualquier llamada a puertos que no sean seguros denegada
http_access deny !Safe_ports
#Denegamos cualquier intento de CONNECT a los puertos que no sean los especificados
http_access deny CONNECT !Safe_ports

########################################################
## ACCESO A LA CACHE PERMITIDO A TODO EL MUNDO
########################################################
acl all world 0.0.0.0/0.0.0.0
http_access allow world
# No cachemaos los cgi
no_cache deny QUERY


Con esto tenemos una configuración base de SQUID capáz de realizar tareas de Reverse Proxy, como todas las configuraciones que hemos expuesto aquí pueden ser un poco difíciles de ver, tienes un archivo de configuración completo aquí


Hasta el próximo capítulo,

Urko


sábado, 3 de marzo de 2007

Reverse Proxy APACHE + MOD_PROXY vs SQUID (Parte 1)

Updated SEP.2009: Esta entrada la escribí hace mucho tiempo, existe una versión más actualizada de cómo instalar squid sobre Solaris 10 en esta dirección http://sparcki.blogspot.com/2009/08/instalar-squid-en-solaris-10-parte-1.html o a en esta otra dirección http://sparcki.blogspot.com/2009/09/instalar-squid-como-proxy-reverso-en.html aunque si quieres puedes continuar con la entrada original para Solaris 9 y squid 2.6.

Introducción

Durante varios días (semanas) he estado realizando pruebas sobre qué método era mejor para realizar un Proxy Reverso. Antes de comenzar con un artículo explicando mis conclusiones, tal vez es hora de explicar qué es y para qué sirve un Reverse Proxy.


Qué es y Para Qué Sirve un Reverse Proxy?

La funcionalidad principal de un Reverse Proxy es la ocultar(1) la infraestructura de red que hay detrás de una petición. Esto supone, por ejemplo, ocultar el inseguro IIS como si de un Servidor Apache se tratase. Esto puede que algunos no os parezca algo muy importante, pero creedme, es algo muy importante.

Nosotros podemos tener nuestra estructura a salvo(2) de miradas no autorizadas, o más allá, la posibilidad de retocar las paginas para hacer más seguras la peticiones.

(1) Existe la posibilidad de intuir/adivinar/conocer pero de una forma no tan fácil.
(2) No existe la posibilidad de asegurar que este método te protege al 100% de cualquier ataque.

Estamos acostumbrados al Clustering de entornos JSP/Servlet, porque aquí si se ha explotado, pero ... y aquellos que no son JSP/Servlet? La solución a estos problemas es utilizar un Reverse Proxy, un almacenamiento compartido, entre otras cosas.

Y por último, tenemos la posibilidad de incrustar un Firewall horizontal a aquellas instalaciones que no permiten hacerlo, por ejemplo, Oracle Financials.

En la imagen se puede ver un esquema de los dos entornos y de un cómo va a quedar nuestro ejemplo.


Una vez
establecido el punto de partida y el destino, podemos continuar con los preparativos en siguientes partes ....

Urko