F5 LTM: Migración a versión 11.6.0 HF3

f5.2.5

Aviso: En el momento de hacer este tutorial, la versión 11.6.0 resultó absolutamente inestable y decidimos volver a la versión 11.5, pese a la falta de monitorización.

Hemos tenido un problema con la versión 11.5, y la monitorización mediante nagios. Básicamente, al recoger los identificadores de ltm, han dejado de responder mediante snmp:

snmpwalk  -v 2c -c $community $host .1.3.6.1.4.1.3375.2.2.5.5

Por ello, nos lanzamos a la migración a la versión 11.6

Pasos en la migración

Descargamos los archivos de la web de F5

Esta vez, para subir los archivos, lo haremos directamente por scp, a la carpeta /shared/images.

[root@server:Active:In Sync] config # ls /shared/images/
BIGIP-11.5.1.0.0.110.iso  Hotfix-BIGIP-11.5.1.7.0.167-HF7.iso  Hotfix-BIGIP-11.6.0.3.36.412-HF3-ENG.iso
BIGIP-11.6.0.0.0.401.iso  Hotfix-BIGIP-11.6.0.3.0.412-HF3.iso

Verificamos que en la interfaz web aparezcan:

imagen de disco

hotfix
hotfix

Instalamos la imagen en alguna partición en ambos nodos y activamos

f5.2.4

Dejamos el pasivo con los virtual servers, y rompemos el grupo de disponibilidad. Para ello, solemos utilizar la funcionalidad “Reset Device group”.

A partir de este momento, ambos elementos están aislados, y cada uno, de forma manual debe tener sus Virtual Server sin que haya conflicto de IPs.

f5.2.5

A partir de aquí, cuando tengamos probados los virtual servers en la nueva versión, ya se puede re-crear el grupo de sincronización y

 Resultado de la migración

Al hacer las pruebas de estrés de los servidores virtuales, detectamos que la interfaz es absolutamente inestable.

Parece tener problemas de pérdida de memoria, y dan errores de buffer las peticiones a partir de las 300 peticiones en 10 threads simultáneos.

Por ello, volvemos a la versión 11.5 a la espera de nuevos hotfix en versión 11.6

F5 ltm: Crear un grupo de disponibilidad

f5.dg.4

Para crear un grupo de disponibilidad, partimos de una situación en la que tenemos dos nodos standalone:

f5.2.5

Primero, en uno de los nodos, configuramos la lista de pares con los otros nodos:

f5.dg.1

Cuando ya está añadido con IP, podemos ir al grupo de failover, y añadir tantos nodos, como se hayan presentado:

f5.dg.2

Por último, pasamos la configuración para que estén sincronizados:

f5.dg.3

F5 Big ip ltm: Migración a versión 11.5.1 con hotfix 7

Subir las imágenes a los dispositivos F5 mediante el interfaz web:

  • Hotfix-BIGIP-11.5.1.7.0.167-HF7.iso
  • BIGIP-11.5.1.0.0.110.iso

f5.2

Instalamos imagen y último hotfix sobre una partición del disco

f5.3

Deshacemos el grupo de dispositivos de alta disponibilidad para que no haya problemas.

f5.1

Arrancamos el pasivo con la nueva imagen de disco.

Esperamos a que el reinicio sea completo. Durante el arranque de los srevicios, por ssh, se ve  la consola con el siguietne prompt

[admin@!:!:!] ~ #

[admin@localhost:INOPERATIVE:] ~ #

En este caso, nos ha pedido reactivar la licencia para pasar de versión. Lo hemos hecho manual a través de la web de f5: https://activate.f5.com/license/dossier.jsp

[admin@F5ext02:REACTIVATE LICENSE:Disconnected] ~ [admin@F5ext02:INOPERATIVE:Disconnected] ~ #

De forma manual, pasamos toda la carga (en nuestro caso Virtual servers) al servidor actualizado, y activamos la partición de disco duro en el servidor antiguo.

Activación de licencias en F5

Activación de licencias en modo consola

En este punto, es necesario introducir la licencia. Se recomienda seguir esta guía : http://support.f5.com/kb/en-us/solutions/public/2000/500/sol2595.html?sr=27505445

get_dossier -b KEY_HEXADECIMAL > f1.dossier.txt

Una vez activadas las licencias en la web de F5, se colocan en el sistema de archivos y se carga la licencia:

mv f1.txt /config/bigip.license
reloadlic

F5 Virtual Edition 11.4

Para hacer las pruebas de nuestro entorno de producción, vamos a optar por un despliegue temporal de F5 virtual.

En primer lugar, descargamos la imagen, con el último hotfix que vamos a utilizar.

El usuario de la edición virtual es root:default.

En la consola, sacamos la configuración inicial mediante el comando config.

e1

Con red, ya es posible pasar a configurar vía red el equipo, con el usuario admin:admin.

Las pruebas requieren licencia de trial que se pueden conseguir a través de la web de F5.

 

 

 

 

 

F5 ltm 1600 Irules: Cerrando conexiones con http 1.0 y keepalived

Restringimos el tráfico de nuestros servidores virtuales de los F5, a través de una irule de throttle.

Básicamente, guardamos una subtabla con el número de peticiones en una ventana (1 hora), y cuando sobre pasa el límite, fijamos el estado de la IP a bloqueado.

La irule, se basa en el evento: when HTTP_REQUEST.

Hemos detectado, que se nos pasaban algunas peticiones.

Los que abren conexiones http 1.0 con el flag de keepalived. Estas conexiones, sólo lanzan el evento de HTTP_REQUEST en el primer Request (get o post).

  • El primer GET por la conexión, lanza el evento, y se devuelve el código de error.
  • Los siguientes, ya no aplica la irule, y se sirven.

Se añade a la lógica del programa el cierre TCP, para evitar que la conexión la mantengan abierta:

HTTP::respond 403 content “RequestLimit: THROTTLED”
TCP::close

Si usamos HTTP::Close, el cierre de http es demasiado brusco, y los navegadores no  devuelven el error que enviamos desde los F5. Lo que se ve es “Connection reset by server”

 

 

 

 

 

F5 Diferencias TCL entre versión 11.2.1 y 11.3

Comparador !

En 11.2.1, el operador !, sirve para

if  { ([HTTP::method] eq "POST") and
! (  [HTTP::header SOAPAction]  eq ""  ) }

 

En 11.3, lo tenemos que sustituir por:

if { ([HTTP::method] eq "POST") and
( [HTTP::header SOAPAction] ne "" ) }

Toda la información de los operadores en TCL (irule) está en la página de F5.

String map para quitar el identificador de vlan

Se puede quitar varios identificadores de vlan a la vez, con un único map:

# Remove vlan identifier
set my_client_ip [string map { "%123" "" "%512" "" } [IP::remote_addr]]

Depuración Errores TCL

grep -i  "tcl error"  ltm | cut -d' ' -f12-26 |uniq

Actualización F5 Big IP 11.3.0 HF 8

La descarga de imágenes se hace desde la web de F5:

https://downloads.f5.com/esd/product.jsp?sw=BIG-IP&pro=big-ip_v11.x&ver=11.3.0

Hotfix-BIGIP-11.3.0-3144.0-HF8 11.3.0 HotFix 10/14/2013 Hotfix-BIGIP-11.3.0-3144.0-HF8
11.3.0 11.3.0 Release 12/17/12 11,3,0

Dado que en F5 no se distinguen por su madurez al sacar versiones, hemos optado por pasar de una 11.2.1 a una 11.3.0 con HF8. Existen versiones más recientes, pero de hace sólo 15 días.

Se suben las imágenes al equipo a actualizar, en una partición no utilizada:

 

Del mismo modo, se sube el hotfix

Si queremos actualizar por la interfaz web, selecionamos install y la partición que vamos a utilizar. Debe ser una que no esté ya en uso

Se instala también el HF:

Si queremos actualizar por tmsh, una vez subidas las imágenes, podemos aplicarlas sobre un volumen existente:

Por tmsh, se instala en un volumen existente

admin@f5pre(Standby)(/Common)(tmos)# install sys software image BIGIP-11.3.0.2806.0.iso volume HD1.2

 O, sobre un volumen nuevo:

admin@f5pre(Standby)(/Common)(tmos)# install sys software image BIGIP-11.3.0.2806.0.iso volume HD1.4 create-volume

En caso de tener varios nodos, es necesario que estén en la misma versión, para mantener el grupo de device.

 

Instalando cherokee 0.8.0 en debian 4.0


El servidor web Cherokee 0.8.0 verá la luz en breve con aun mejor rendimiento, y realmente estoy impaciente por empezar a migrar todos mis dominios a cherokee: Las pruebas que he hecho han reducido la latencia en un 70% permitiendo muchas más conexiones y reduciendo drásticamente  el consumo de memoria.

Aquí os dejo los pasos para instalar cherokee 0.8.0 desde subversion en una debian 4.0 limpia:


# cd /usr/src
# apt-get update
# apt-get install make subversion automake autoconf gcc pcre-dev libssl-dev libtool libpcre3-dev python
# svn co svn://svn.cherokee-project.com/cherokee/trunk cherokee-trunk
# cd cherokee-trunk
# ./autogen.sh --localstatedir=/var --prefix=/usr --sysconfdir=/etc --with-wwwroot=/var/www
# make install

Alcanzado este punto ya podréis configurar vuestro servidor con cherokee-admin: http://www.cherokee-project.com/doc/admin.html

Google comienza a indexar contenido flash.

Leo en 33rockers que google a comenzado a indexar contenido flash, permitiendo así búsquedas dentro del contenido de texto de cualquier widget o aplicación en flash. Hasta este momento, los sitios web basados  en flash sufrían una desventaja competitiva importante respecto a los sitios que utilizaban únicamente HTML, ya que su contenido y enlaces no era indexado ni analizado por los buscadores.

Era un paso lógico tras la apertura del formato SWF y los acuerdos adquiridos entre adobe y grandes buscadores como Google y Yahoo.

Veremos como afecta este giro al mercado web. Mi opinión respecto de los sitios flash es la misma que la de la gente de 33rockers: flash es práctico para pequeños contenidos interactivos, pero no para hacer sitios web completos. Incluso diría que hoy en día los navegadores, con el uso de javascript permiten un nivel de interactividad tal que flash me parece prescindible.