Archivo

Archive for the ‘WebLogic’ Category

Introdución a Kubernetes: Orquestando dockers

Resultado de imagen de kubernetesEn anteriores entradas vimos una introducción a docker, además de cómo crearlos y manternerlos.

Pero, ¿cómo los gestionamos y utilizamos? Hay diferentes herramientas para orquestar docker, como swarn, apache mesos o kubernetes. En esta entrada nos vamos a centrar en la herramienta que google donó al software libre en 2015: kubernetes. A Google siempre le ha gustado hacer trabajar a otros y que éstos le aporten contenidos: maps, youtube, etc…. Y no iba a ser diferente con kubernetes, una de las herramientas que tiene ahora mismo más desarrolladores y commits.

Kubernetes consta de diferentes componentes que nos ayudan a gestionar nuestros contenedores docker, como dns, red, proxy, monitorización, apis, scheduler, etc. La instalación es bastante complicada, pero vamos a ver dos formas que nos la facilitan: minikube y kubeadm.

Minikube levanta máquinas virtuales con todos los componentes para que funcione kubernetes. Podemos elegir virtualbox, kvm, hyperv… Es muy sencillo y nos servirá para probarlo. Es poco operativo porque levanta los contenedores dentro de las máquinas virtuales, con la limitación que pueden tener éstas de memoria o espacio.

Kubeadm nos levanta en local contenedores docker con los componentes de kubernetes y se conecta al demonio local de docker.

En avanttic tenemos un cluster con dos nodos de kubernetes instalados con kubeadm, los llamamos kubernetes1 y kubernetes 2, vamos a ver unos ejemplos.

Selection_027

Primero vamos a ver unos conceptos importantes:

  • Deployment: es el contenedor docker que vamos a desplegar que contiene la aplicación. Por ejemplo un servidor web.
  • Pod: un pod es cada unidad de Deployment que tenemos funcionando. Con kubernetes gestionamos cuantos pods queremos levantar de cada aplicación.
  • Services: son los servicios que exponemos que hacen referencia a los PODS

Vamos a desplegar una aplicación, por ejemplo, un servidor web o un weblogic que podemos descargar de nuestro repositorio docker de avanttic https://hub.docker.com/u/avanttic. Como estos últimos son privados por tener licencias, vamos a probar con un apache.

Leer más…

Categorías:WebLogic Etiquetas: , , ,

OHS 12.2.x privilege ports (<1024) UNIX

junio 29, 2017 Deja un comentario

En versiones previas a la 12.2.x, como ya se indicaba en este post, el procedimiento para iniciar el OHS en los puertos inferiores a 1024 ha ido modificando con el tiempo y esta versión no iba a ser menos que las anteriores.

Dicho procedimiento se ha simplificado en esta última versión y las tareas a realizar son las siguientes:

  1. Parar los procesos de OHS:
    $DOMAIN_HOME/bin/stopComponent.sh ohs1
    
  2. Como usuario root modificar el propietario del fichero “launch” y sus permisos:
    chown root $ORACLE_HOME/ohs/bin/launch
    chmod 4750 $ORACLE_HOME/ohs/bin/launch
    
  3. Modificar el fichero $DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/httpd.conf (o ssl.conf si se va a securizar). En este caso modificamos ssl.conf:
    ###################################################################
    # Oracle HTTP Server mod_ossl configuration file: ssl.conf        #
    ###################################################################
    
    # The Listen directive below has a comment preceding it that is used
    # by tooling which updates the configuration.  Do not delete the comment.
    #[Listen] OHS_SSL_PORT
    Listen 443
    [...]
    #[VirtualHost] OHS_SSL_VH
    <VirtualHost *:443>
    
  4. Iniciar el proceso OHS y verificar el puerto:
    $DOMAIN_HOME/bin/startComponent.sh ohs1
    
Categorías:WebLogic Etiquetas: ,

Docker: Imágenes y vida de los contenedores

Al iniciarse en Docker suelen surgir dudas sobre la volatilidad del contenedor, es decir, su tiempo de vida.

Dicha volatilidad depende en gran medida de la utilidad que le queramos asignar al contenedor. Por ejemplo, si lo utilizamos para hacer una prueba de una configuración tendremos que levantar el Docker desde cero hasta que demos con la configuración buena, o podamos grabarla y seguir trabajando sobre él. Además, una de las utilidades de Docker es que todo está en un script y no tenemos que ir recordando los pasos previos, por lo tanto, se recomienda ir pasando los cambios a script.

Para este ejemplo vamos a crear un servicio en el Service bus de Oracle. Para hacer la prueba nos descargaremos una imagen del Service Bus 11.1.1.7 como ya indicamos en la entrada anterior del blog.

docker pull avanttic/osb1117

Si visualizamos las imágenes que tenemos, aparecerá la recién descargada.

# docker images
REPOSITORY              TAG        IMAGE ID        CREATED           SIZE
avanttic/osb1117       latest   e558b012f4a5   3 minutes ago    10.1 GB

Aquí es donde tenemos que diferenciar entre imagen y contenedor. Una imagen es la base a partir de la cual se ejecutan los contenedores. Es decir, cada vez que hacemos un run sobre la imagen nos levanta un contenedor con esa configuración. Si modificamos el contenedor, lo paramos y arrancamos otra vez la imagen, los datos no estarán, porque arrancará un nuevo contenedor.

Por ejemplo, arrancamos nuestra imagen de Service Bus:

# docker run -ti avanttic/osb1117

Para mirar los contenedores que tenemos se usa el comando:

# docker ps -a
CONTAINER ID         IMAGE                    CREATED            STATUS
ac43456e2203      avanttic/osb1117    4 minutes ago      Up 4 minutes

Sobre ella, creamos un proyecto que moverá mensajes entre dos colas:

selection_717

Leer más…

Categorías:WebLogic Etiquetas: , ,

Solventar problemas de Oracle WebLogic con IPv6

Un error común en instalaciones de Oracle WebLogic, en sistemas operativos con IPv6 habilitado, es que al arrancar tras la instalación en los logs aparece un error similar a:

javax.naming.CommunicationException [Root exception is java.net.ConnectException: t3://[2001:0:5ef5:79fd:34ba:276a:f5fe:fecb]:7001: Destination unreachable; nested exception is:
java.net.NoRouteToHostException: No route to host: connect; No available router to destination]

Este error de resolución aparece en equipos con IPv6 habilitado pero sin configurar, incluso teniendo los DNS y el fichero de hosts bien configurados. Este error es muy común en entornos Windows (nunca he visto este error en otros sistemas operativos).

Existen dos posibles soluciones para este problema:

  • Arrancar Weblogic con el flag -Djava.net.preferIPv4Stack=true

Ejecutar regedit.exe

Buscar la siguiente subclave:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\

Hacer doble clic en DisabledComponents.

Si la entrada DisabledComponents no está disponible, debe crearse:

  1. En el menú Edición , seleccione Nuevo y, a continuación, haga clic en valor DWORD (32 bits).
  2. Escriba DisabledComponents y, a continuación, presione ENTRAR.
  3. Haga doble clic en DisabledComponents.

Escribir 0xFF para deshabilitar todos los componentes de IPv6 salvo la interfaz de bucle invertido de IPv6. Este valor también configura Windows para que utilice preferentemente IPv4 sobre IPv6, cambiando las entradas de la tabla de directivas de prefijo.

Una vez modificado el registro y reiniciado el sistema, tanto AdminServer como todos sus managed servers arrancarán sin problemas

Categorías:WebLogic Etiquetas: , ,

Análisis de thread dumps en WebLogic: ThreadLogic

marzo 29, 2016 Deja un comentario

icono threadlogicSiguiendo con el tema de análisis de thread dumps, que se empezó en este otro post, vamos a centrarnos en la utilización de la aplicación ThreadLogic, que ha sido desarrollada por el equipo de arquitectos de Oracle FMW orientándola a dumps de servidores de aplicaciones. Se puede descargar aquí.

Al igual que Samurai y Thread Dump Analyzer (TDA), se trata de una aplicación libre que se arranca lanzando: java -jar <path fichero jar>

Comentar que para las pruebas se han utilizado las mismas aplicaciones que en el post anterior.

Diferencias con Thread Dump Analyzer (TDA)

El desarrollo de esta herramienta se ha realizado a partir de TDA:

  1. La información se muestra de una forma mucho más visual.
  2. La información está más categorizada:

threadlogic categorias dumps

  1. Está muy orientada al análisis de thread dumps de Oracle WebLogic Server:

threadlogic categorias dumps WLS

  1. Se puede filtrar por el estado del thread:

threadlogic filtro health

Stuck threads

Los stuck threads se marcan con este estado a nivel de servidor de aplicaciones cuando un thread está corriendo durante más de X segundos.

Leer más…

Análisis de thread dumps en WebLogic

Hace unos meses escribí este post donde os explicaba qué son los stuck threads y cómo detectarlos.

En el post de hoy os voy a presentar algunas herramientas que os pueden ser útiles para realizar el análisis de thread dumps, necesarios para la detección de stuck threads, deadlocks, etc.

Sin embargo, no hay que perder de vista el hecho de que como administradores únicamente podremos saber dónde está el problema, no solventarlo.

 

Ejecución de pruebas

Por si tenéis interés en realizar vuestras propias pruebas, aquí podéis encontrar una aplicación para provocar deadlocks, gentileza de nuestro compañero Àngel Ollé.

Una vez desplegada en una instancia WebLogic, se puede provocar un deadlock realizando peticiones a http://ip:puerto/DeadLockServlet/dl

Para generar stuck threads podéis utilizar la aplicación StuckThreadForFree realizando llamadas a http://ip:puerto/StuckThreadForFree sobre la instancia WebLogic.

Se definen cuántos threads levantar, cuántos segundos mantenerlos levantados y qué operación estarán ejecutando durante ese tiempo:

stuckthreadforfree prueba

¿Qué herramienta utilizar?

Hay muchas herramientas en el mercado pero las más comúnmente utilizadas, que además son libres, son:

  1. Samurai
  2. Thread Dump Analyzer (TDA)
  3. ThreadLogic

Todas consisten en un JAR, por lo que su ejecución es tan simple como lanzar ‘java -jar <path fichero jar>’. La diferencia reside en cómo se muestra la información en la interfaz.

Una vez se ha iniciado la aplicación, abrimos el fichero de texto donde tenemos el thread dump.

Comentar que las aplicaciones pueden interpretar ficheros con varios thread dumps.

 

1. Samurai

Descarga: http://yusuke.homeip.net/samurai/en/samurai.jar

Es una aplicación muy intuitiva donde se identifican con facilidad bloqueos:

Samurai threads bloqueados

Leer más…

Problemas de rendimiento en una JVM

agosto 20, 2015 1 comentario

java

Si te dedicas a la administración de sistemas Middleware, tarde o temprano acabas encontrando problemas de rendimiento sobre las aplicaciones. Hay muchos factores que pueden afectar al rendimiento, como puede ser una aplicación mal desarrollada, consultas en base de datos con tiempo de ejecución elevado, latencias de comunicaciones y un largo etcétera.

En el caso de WebLogic, las instancias no son otra cosa que un proceso Java y, como tal, una mala configuración también puede empeorar el rendimiento.

En este post nos vamos a centrar en la configuración de la memoria de procesos Java.

¿Qué información necesitamos?

Para poder analizar el comportamiento de la memoria de procesos Java es imprescindible recoger las trazas de Garbage Collector (GC). Esto se configura en el arranque del proceso Java mediante unas variables.

Estas trazas aportan datos sobre:

  • Tiempo de ejecución de GC.
  • Estado de la memoria (young, old y permanent) antes y después de las limpiezas.
  • Si se han ejecutado Full GC (FGC) y cuánto han estado ejecutándose: este dato es especialmente importante puesto que durante un FGC la instancia se queda congelada.

Un ejemplo de esta información sería (en esta traza de ejecución no se han realizado FGC):

2015-08-19T00:49:03.965+0200: 9,759: [GC pause (young), 0,0176360 secs]
   [Parallel Time: 15,7 ms, GC Workers: 2]
      [GC Worker Start (ms): Min: 9759,0, Avg: 9759,3, Max: 9759,6, Diff: 0,6]
      [Ext Root Scanning (ms): Min: 3,2, Avg: 3,5, Max: 3,7, Diff: 0,5, Sum: 7,0]
      [Update RS (ms): Min: 0,0, Avg: 0,0, Max: 0,0, Diff: 0,0, Sum: 0,0]
         [Processed Buffers: Min: 0, Avg: 6,5, Max: 13, Diff: 13, Sum: 13]
      [Scan RS (ms): Min: 0,0, Avg: 0,1, Max: 0,1, Diff: 0,1, Sum: 0,1]
      [Object Copy (ms): Min: 11,8, Avg: 11,8, Max: 11,8, Diff: 0,0, Sum: 23,6]
      [Termination (ms): Min: 0,0, Avg: 0,0, Max: 0,0, Diff: 0,0, Sum: 0,0]
      [GC Worker Other (ms): Min: 0,0, Avg: 0,0, Max: 0,0, Diff: 0,0, Sum: 0,1]
      [GC Worker Total (ms): Min: 15,1, Avg: 15,4, Max: 15,7, Diff: 0,6, Sum: 30,8]
      [GC Worker End (ms): Min: 9774,7, Avg: 9774,7, Max: 9774,7, Diff: 0,0]
   [Code Root Fixup: 0,1 ms]
   [Clear CT: 0,1 ms]
   [Other: 1,8 ms]
      [Choose CSet: 0,0 ms]
      [Ref Proc: 1,6 ms]
      [Ref Enq: 0,1 ms]
      [Free CSet: 0,1 ms]
   [Eden: 89,0M(89,0M)->0,0B(89,0M) Survivors: 13,0M->13,0M Heap: 102,2M(2048,0M)->15,0M(2048,0M)]
 [Times: user=0,03 sys=0,00, real=0,02 secs]

¿Cómo interpretamos esta información?

A pesar que las trazas de GC se pueden abrir con cualquier editor de texto, analizar estas trazas manualmente es muy tedioso y lento.

Hay varias herramientas que permiten ver esta información gráficamente y que, además, muestran estadísticas. La más comúnmente utilizada es GCViewer. Es un proyecto opensource que se mantiene vivo.

Antes de empezar

Explicar cómo ver si hay algún problema y cómo solucionarlo es un tema para el que se han escrito libros enteros, por lo que es imposible explicarlo en un post.

Aunque va a gustos, dejo algún libro que he utilizado como referencia (para mi opinión, de obligada lectura si te dedicas al sector):

  • Java Performance: The Definitive Guide“, de Scott Oaks
  • Java Performance“, de Charlie Hunt y Binu John (chapter 7: Tuning the JVM, Step by Step)

Antes de empezar, hay que tener muy en cuenta que:

  1. Realizar un buen análisis es una tarea que no se realiza en un momento. En la mayoría de los casos estamos hablando de una semana de trabajo exhaustivo.
  2. Una mala configuración puede empeorar el rendimiento. Puede llegar a ser peor el remedio que la enfermedad.

Resumiendo: ármate de paciencia y de buena documentación.

Ideas generales

  1.  ¿Cada vez que se ejecuta un FGC es realmente necesario? En versiones anteriores de JDK, cada 60 segundos se ejecutaba, de forma sistemática, un FGC. Este comportamiento no es el deseado, pero se puede evitar añadiendo unas variables en el arranque del proceso Java.
  2. Ampliar el tiempo entre ejecuciones de FGC puede sacar a la luz otros problemas. Los FGC ejecutados sin necesidad pueden estar ocultando leaks de memoria, que acabarían degradando aún más el rendimiento del proceso Java.
  3. Aumentar los espacios de memoria (sea cual sea) provoca un aumento en el tiempo de ejecución de GC y FGC. A veces, menos es más.
  4. La solución no tiene por qué venir únicamente del tuning de la VM. En algunos casos, pasa por el desarrollo de la aplicación que corre por encima (reducir los objetos en memoria y/o el tiempo de permanencia de estos objetos en memoria).
  5. Si se observa que el espacio de memoria young se llena con facilidad y estos objetos se van promocionando a la old, para al poco tiempo borrarse de la old, una solución podría ser aumentar el tamaño de la zona Young en detrimento de la old con el objetivo de disminuir estas promociones a la zona old, además de disminuir el tiempo y frecuencia de los FGC.
  6. Cada vez que se modifica un parámetro de configuración en el arranque, hay que volver a recolectar logs de GC para realizar una comparativa y ver si el cambio ha sido positivo.