Archivo

Archive for the ‘WebLogic’ Category

Autoescalado con Kubernetes

septiembre 22, 2017 Deja un comentario

Una de las funcionalidades más demandadas últimamente es el autoescalado de aplicaciones.

¿Por qué siempre se colapsa la web de venta de entradas y me tengo que quedar sin ver a Guns n’Roses? ¿Nunca podré comprar un billete barato en RENFE? En los momentos de alta interacción su web me deja en espera indefinidamente…

Para esta prueba vamos a utilizar un clúster de Kubernetes de 2 nodos y el típico ejemplo de aplicación:
servidor web (ohs) -> servidor de aplicaciones (weblogic 12c) -> BBDD (12c)

Recordad, tal y como mostramos en un post anterior sobre kubernetes, que el pod corresponde a cada instancia levantada de nuestra aplicación. Empezamos con 2 pods de ohs, 2 de weblogic y uno de BBDD.

Selection_040

Desplegamos con Ansible una sencilla aplicación en weblogic que solo hace una consulta a BBDD.

Se suele crear un autoescalado sobre la CPU cuando llega al 80%. En nuestro caso como es una prueba y debe saltar antes, lo vamos a hacer sobre el 20%. Kubernetes está en continua evolución y actualmente se están añadiendo otros criterios a parte de CPU.

Leer más…

Categorías:WebLogic Etiquetas: , ,

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…