Avro RCP yarn and slider

Siguiendo con los artículos relacionados con YARN, SLIDER y arquitecturas relacionadas con BigData mostramos a continuación una posible arquitectura basda en los siguientes tres elementos

Donde lo importante es que con este tipo de arquitectura podríamos disponer de servicios con las caraterísticas indicadas

La idea en este caso es desplegar los servicios que se pueden generar con AVRO en un cluster de yarn empaquetando estos servicios como aplicaciones YARN.

Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Online edition with Libreoffice in Alfresco 5

Last days I was asked for a tip (again) for enabling online edition via webdav with Libreoffice in Alfresco 5. It is tested with this setup:
  • Ubuntu 14.04 LTS (although it can work in other Linux)
  • Libreoffice 4.2.8.2 (it comes with the Linux distro)
  • Alfresco CE 5.0c && 5.0d (the jar is valid for Alfresco 4 too)
  • Last versions of Firefox and Chrome
So, in your Alfresco 5 server you need to download the jar file and copy in $ALF_HOME/tomcat/shared/lib directory, restarting alfresco service:
 
 
Once, you should see "Edit. Online" action for MS-Office and Libreoffice mimetypes. It is clear that you need webdav enabled in your repository (and access to the webdav context).
 
Then, for make it work, you need to register an url-handler based protocol for dav:// and davs:// urls with Libreoffice. This can be done via two methods (that can work in different versions of Linux).
 
Method 1:
 
Create the next file, and the corresponding path, if it does not exist.
 
$ vim ~/.local/share/applications/libreoffice-alf.desktop 
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Name=LibreOffice for Alfresco
GenericName=LibreOffice for Alfresco
Comment=Online Editing in Alfresco via webdav
Icon=libreoffice-writer
TryExec=soffice
Exec=soffice %U
Terminal=false
Type=Application
Categories=Office;
MimeType=x-scheme-handler/davs;x-scheme-handler/dav
 
2. Create the mimeapps.list file, if it does not exist. If it exist, just add the two x-scheme handlers,
 
$ vim ~/.local/share/applications/mimeapps.list
[Added Associations]
x-scheme-handler/davs=libreoffice-alf.desktop;
x-scheme-handler/dav=libreoffice-alf.desktop;
 
Method 2: 
 
This is done for all users of the operating systems, you need sudoer privileges
 
1. Just create the file in the next path:
 
$ sudo vim /usr/share/applications/libreoffice-alf.desktop
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Name=LibreOffice for Alfresco
GenericName=LibreOffice for Alfresco
Comment=Online Editing in Alfresco via webdav
Icon=libreoffice-writer
TryExec=soffice
Exec=soffice %U
Terminal=false
Type=Application
Categories=Office;
MimeType=x-scheme-handler/davs;x-scheme-handler/dav
 
2. Add x-scheme-handlers to mimeinfo.cache
 
$ sudo vim /usr/share/applications/mimeinfo.cache
 
# Add to the file
x-scheme-handler/davs=libreoffice-alf.desktop;
x-scheme-handler/dav=libreoffice-alf.desktop;
 
3. Update desktop cache
 
$ sudo update-desktop-database 
 
Then when you "Edit. online", you see some dialog for remembering the action for opening the url. Libreoffice asks for your credentials once in a session.
 
For Windows users, it is possible to register the protocol too, with the help of (there is also a .reg file in the downloads section of the googlecode project - put the correct path for the Libreoffice command):
 
Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Usando yarn y slider para levantar procesos en un cluster de hortonworks

Siguiendo con las pruebas y las arquitecturas relacionados con bigdata vamos a inspeccionar las capacidades de yarn para levantar procesos en un cluster HDP. Lo primero que habría que introducir es el producto yarn. De la página siguiente de hortonworks podemos obtener la siguiente definición

YARN is the prerequisite for Enterprise Hadoop, providing resource management and a central platform to deliver consistent operations, security, and data governance tools across Hadoop clusters.
YARN also extends the power of Hadoop to incumbent and new technologies found within the data center so that they can take advantage of cost effective, linear-scale storage and processing. It provides ISVs and developers a consistent framework for writing data access applications that run IN Hadoop.


Por tanto como podemos ver yarn es una suerte de sistema operativo para interactuar con hadoop y que éste (yarn) gestione los recursos del cluster de hadoop/hortonworks.

Sobre Yarn existen varios APIs que podemos usar para desplegar nuestros propios procesos.

  • YARN (API de más bajo nivel sobre el que se montan, TEZ y SLIDER)
  • TEZ (API para simplificar el desarrollo de aplicaciones que se pueden ejecutar sobre YARN, se puede ver como un API para ejecutar procesos, por ejemplo scripts de PIG, HIVE etc...)
  • SLIDER (API que simplifica el desarrollo de aplicaciones que se pueden ejecutar sobre YARN, a diferencia de TEZ slider está diseñado para es levantar servicios, como explican el la página de howtonworks, Slider is a framework for deployment and management of these long-running data access applications in Hadoop)


Una vez presentados los tres "sabores" principales vamos con el caso de uso que estamos probando. En este caso lo que vamos a crear es bot para slack que va a leer los mensajes de un canal y va a contestar a los mensajes de dicho canal. La idea es que una vez que tengamos esa aplicación java desarrollada la levantemos sobre el cluster de hdp/yarn usando slider.

La arquitectura general de la solución es la siguiente




Donde podemos ver que los eventos producidos en un canal de slack son consumidos por el bot que se ha levantado en un cluster de hadoop usando slider. Para desarrollar esta prueba de concepto los requisitos son

El primer requisito se ha tratado en otros posts en este blog. El segundo requisito es la parte en la que nos hemos centrado para crear esta entrada. Un paquete slider se compone (a grandes rasgos) de los elementos que vemos en la siguiente imagen



Donde lo principal son los ficheros de configuración, los scripts de arranque, y los binarios que se ejecutan. Los binarios son la parte que en este caso hemos desarrollado en java. Los archivos de configuración nos permiten definir las siguientes características:

  • classloader de la aplicación
  • version de java que se quiere usar
  • memoria reservada para el proceso
  • nombre del paquete/servicio
  • parámetros extra que se pasan al proceso (pueden ser parámetros gestionados por el que despliega el proceso o por el propio nodo donde se levanta el proceso)
  • threshold que nos permite definir los límites que hacen que un proceso que se ha detenido se vuelva a levantar automáticamente. Por ejemplo si se ha producido un error de comunicación y el proceso se muere según definamos los límites el proceos se volverá a levantar de manera automática.
  • numero mínimo y máximo de procesos que se deben levantar
  • ... y un montón más de características que podemos ver en el site del proyecto

Una vez que tenemos el paquete creado podríamos desplegarlo usando los siguientes comandos de slider

  • slider  package --install --replacepkg  --name MOMO_BOT --package /home/hadoop/jenkins/jobs/slack_bot/slack_bot-0.0.1-SNAPSHOT-slider-package.zip
  • slider stop momo_bot
  • slider  destroy momo_bot
  • slider  create momo_bot --template /home/hadoop/jenkins/jobs/slack_bot/appConfig-default.json --resources /home/hadoop/jenkins/jobs/slack_bot/resources-default.json

Una vez ejecutada esta secuencia podremos ver nuestro proceso desde la vista slider de nuestro ambari.

Para la generación del paquete hemos usando maven y para el despliegue automatizado jenkins. El objetivo de esta prueba era analizar las características de slider como modelo de despliegue de aplicaciones. El hecho de desplegar una aplicación usando este modelo dota al servicio de las siguientes características

  • auto-escalado
  • monitorización y re-arranque de containers en base de los parámetros definidos en la configuración del paquete slider
  • gestión de los recursos asociados al servicio usando del modelo de containers de yarn
  • registro automático del servicio etc..

En esta página se puede ver todo lo que slider puede hacer (https://slider.incubator.apache.org/docs/manpage.html). Lo más destacable a nuestro modo de ver sería

  • A user can create an application instance.
  • Users can flex an application instance: adding or removing components dynamically. If the application instance is live, the changes will have immediate effect. If not, the changes will be picked up when the instance is next started.

Y como última conclusión ... slider es mucho más que de lo que se ha explicado en este post... parafraseando a pedro salinas ... Eso no es nada aún. Buscaos bien, hay más.

Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

How to track SOLR indexation process in Alfresco

For tracking indexation in SOLR, we have the Alfresco Administration Console, which gives us the indexation status, the indices in disk, and an estimation of the remaining time of transactions to be indexed. This is available in Enterprise edition in Admin Console:
 
  http://localhost:8080/alfresco/service/enterprise/admin/admin-searchservice
 
This information is directly taken from SOLR Summary XML Report (in this case the url is using 8080 instead of the default secured 8843):
 
  http://localhost:8080/solr/admin/cores?action=SUMMARY&wt=xml
 
Another way for tracking or monitoring the indexation progress is to set debug logger in log4j.properties of SOLR application:
 
  log4j.logger.org.alfresco.solr.tracker.CoreTracker=DEBUG
 
In SOLR, the log4j can not be extended out of WEB-INF (as in Alfresco Share) and you should change it directly under WEB-INF directory at:
 
  /opt/alfresco424/tomcat/webapps/solr/WEB-INF/classes/log4j.properties
 
The best part of this is that you can activate it or reload it (without restarting the service) with this action:
 
  http://localhost:8080/solr/admin/cores?action=LOG4J
 
By last, you can monitor size data.dir.root for SOLR via operating system, or via JMX (only in EE edition) with the next bean and their corresponding variables:
 
In jmxterm the sequence is the next one:
 
> jvms
> open <tomcat-id>
> domain Alfresco
> bean Alfresco:Category=Search,Type=Configuration,id1=managed,id2=solr
 
> get tracker.alfresco.active
> get tracker.alfresco.approx.indexing.time.remaining
> get tracker.alfresco.approx.txns.remaining
> get tracker.alfresco.disk
> get tracker.alfresco.lag
> get tracker.alfresco.lag.duration
> get tracker.alfresco.last.indexed.txn
> get tracker.alfresco.memory
 
Finally, you must take into consideration that there is an issue for getting this data if archive core is disabled by config in SOLR (in < Alfresco 4.2.5).
 
Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

How to get logs for Alfresco querys

For getting more information about Alfresco querys just edit (extend) custom-log4j.properties in extension directory, for example:
 
/opt/alfresco/tomcat/shared/classes/alfresco/extension/custom-log4j.properties
 
SQL queries:
 
  log4j.logger.java.sql=debug
  log4j.logger.java.sql.Connection=DEBUG
  log4j.logger.java.sql.Statement=DEBUG
  log4j.logger.java.sql.PreparedStatement=DEBUG
  log4j.logger.java.sql.ResultSet=DEBUG
 
Be careful, this is pretty verbose. Be careful with caches too!.
 
SOLR queries:
 
  log4j.logger.org.alfresco.repo.search.impl.solr.SolrQueryHTTPClient=DEBUG
  log4j.logger.org.alfresco.repo.search.impl.solr.DbOrIndexSwitchingQueryLanguage=DEBUG
 
Javascript API queries:
 
  log4j.logger.org.alfresco.repo.jscript.ScriptLogger=DEBUG
  log4j.logger.org.alfresco.repo.jscript.Search=DEBUG
 
In Alfresco Enterprise, you have more options for doing this without restarting the service:
although not all classes are enabled via JMX or support tools, for example the SQL and DbOrIndexSwitchingQueryLanguage loggers. Tested in Alfresco 4.2.4 EE.
 
Links:
Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Ambari hortonworks stacks and services solrCloud for liferay

Siguiendo con el post de ayer y después de unos mínimos ajustes en los scripts del stack, ya podemos crear un cluster de solr (tipo cloud) y crear en él una collection con dos shards y factor de replica 2. Para ellos basta con ejecutar el siguiente comando en alguno de los nodos gestionados desde ambari

./bin/solr create_collection -c liferay-collection -shards 2 -replicationFactor 2

Este comando crea una collection con dos shards y replica 2 llamada liferay-collection que la usaremos más adelante para almacenar los índices de liferay. SolrCloud se apoya en el zookeeper del laboratorio de bigdata (hortonworks 2.3). A continuación unas imágenes de cómo se ve esta colección desde la consola web de administración de solr

Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Ambari hortonworks stacks and services

 

Dentro del proyecto ambari[0] hay dos partes que son claramente extensibles.

  1. Las vistas[1]
  2. Los stacks services[2]

En este artículo vamos a ver, muy someramente, para que creemos que se pueden usar los stacks y un ejemplo de stack para gestionar un motor de búsqueda como solr[3].

Según el propio proyecto ambari la definición de un stack es

Ambari supports the concept of Stacks and associated Services in a Stack Definition. By leveraging the Stack Definition, Ambari has a consistent and defined interface to install, manage and monitor a set of Services and provides extensibility model for new Stacks + Services to be introduced.

Por tanto creemos que es bastante claro para que sirve y cual podría ser su uso extendido. En este caso vamos a analizar la anatomía de un paquete tipo stack. Analizando e instalando el stack anteriormente mencionado [3]

Según vemos en el git del proyecto a primera nivel tenemos

  • kerberos.json (define el modelo de seguridad)
  • metainfo.xml (define las dependencias del stack, el nombre que se va a visualizar en la interfaz de ambari etc..)
  • remove.sh (el script que elimina un servicio ya instalado de un nodo del cluster gestionado por ambari)
  • configuration (contiene los ficheros de configuración que ambari va a manejar para gestionar el servicio instalado)
  • package (el paquete con las dependencias, scripts de instalación, arranque, monitorización etc...)

Una vez que más o menos tenemos claro que es un stack, procederemos a su instalación. Para ello seguimos el readme que tiene el propio proyecto y vemos que lo único que hay que hacer es copiar estos ficheros/carpetas en la zona reservada a tal efecto en el servidor de ambari y reiniciarlo. En este caso se ha hecho clonando el repositorio git en nuestra máquina lug012 que es la que contiene el servidor ambari. En nuestro caso lo haremos clonando el repositorio git

  • sudo git clone https://github.com/abajwa-hw/solr-stack.git /var/lib/ambari-server/resources/stacks/HDP/2.3/services/SOLR
  • sudo service ambari-server restart

Y ya podemos ver en el ambari el nuevo servicio de solr que podremos instalar, configurar y monitorizar desde la interfaz web de ambari.

A continuación dejamos unas imágenes del proceso de instalación de un nodo master de solr[4]. El proceso de instalación tiene sus particularidades y hay que ayudarle un poco para que finalice correctamente ;-)

 

Siguiendo este modelo lo siguiente que queremos añadir a nuestro laboratorio de bigdata son servicios/stacks de tomcat, por ejemplo. Para poder gestionar desde ambari las aplicaciones java normales que desarrollamos en zylk.net

 

UPDATE: Hablando ayer con una otro developer me hizo el siguiente comentario, que creo que es interesante añadir en la entrada (Ya que creo que tiene razón y que en el post no queda suficientemente claro, gracias Carlos por la apreciación) :

 

A mi entender, HDP es un STACK de Ambari, que tiene disponible N servicios (HDFS, HBase, YARN…). En la entrada del blog, lo que se da a entender es que se ha creado un stack cuando en realidad lo que se ha creado es un servicio para un stack, en el caso de zylk para el stack de HDP.

 

[0] https://ambari.apache.org/

[1] https://cwiki.apache.org/confluence/display/AMBARI/Views

[2] https://cwiki.apache.org/confluence/display/AMBARI/Stacks+and+Services

[3] https://github.com/abajwa-hw/solr-stack

[4] http://lucene.apache.org/solr/

Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

How to copy files in linux faster and safer than cp

Sometimes a simple cp -a command is a very painful and slow process. It's true that -v (verbose) option can give you some information on the details of the copy process, but not normally the progress of it. In fact, cp -a is a quite slow process that sometimes is faster (and safer) implemented by tar, for example:
 
$ tar cf - . | (cd /dst; tar xvf -)
 
Usually faster, and more verbose. Another commands such as pv can help you too, to monitor the progress of a copy between two directories, for example:
 
$ tar cf - . | pv | (cd /dst; tar xf -)
 
2,06GB 0:00:09 [ 194MB/s] [  <=>                     ]
 
But copying several gigabytes/terabytes of data and many files between quite old NFS disks is painful via cp. Let's see two alternatives for:
  •  Monitoring the progress of the copy and the copied files.
  •  Skipping to next file before an error (gcp)
  •  Syncing directories (rsync)
  •  Copying files via network (rsync)
One of the better commands for doing copies is rsync, that allows you to synchronize two directories, and in this sense src/ can have live data, that incrementally is synced to dst/ in several executions of the command
 
$ rsync --info=progress2 -auvz ~/Music/ /data/music/
 
giving a result like this:
 
Jake Bugg - Jake Bugg Album 2012/
Jake Bugg - Jake Bugg Album 2012/01 - Lighting Bolt.mp3
  1,913,897,967  15%   22.79MB/s    0:01:20 (xfr#277, ir-chk=1019/1825)
Jake Bugg - Jake Bugg Album 2012/05 - Simple As This.mp3
  1,936,698,070  15%   22.80MB/s    0:01:21 (xfr#281, ir-chk=1015/1825)
 
You can also use it with -n option to perform a dry run (this is more used than the skype test call), that checks and lists the differences between the two given directories. You can use it too with "-e ssh" user@host:dst/ or without --info option in older versions of rsync. It is slower for copying but it does a lot of useful things such syncing, checkings md5sums.... You will remember rsync if something goes bad.
 
Another fantastic command for copy is gcp. Besides of progress estimation, gcp does not copy when the file exists, skips to the next file if occurs an error, and all the fails are written to a journal file. 
 
$ gcp -rv ~/Music/* /data/music/
 
Copying 13.53 GiB   2% |#                                  | 165.50 MB/s ETA:  0:01:25
 
Please check journal: /home/cesar/.gcp/journal
 
$ cat /home/cesar/.gcp/journal
 
/home/cesar/Music/Alabama Shakes-Boys & Girls (2014)/01 - Alabama Shakes - Hold On.mp3
FAILED: already exists
/home/cesar/Music/Alabama Shakes-Boys & Girls (2014)/03 - Alabama Shakes - Hang Loose.mp3
FAILED: already exists
 
In an Alfresco context, many simple migrations (or restoring processes) are tracked via CIFS or Webdav drives. In these cases the above commands are useful. Even they can be useful, if you are doing a local copy in an Alfresco instance, for performing a later Filesystem Bulk process in Alfresco. From a system administrator point of view, when restoring huge contentstores or Lucene / SOLR indices, or moving backups, these commands can save you so much time.
 
Another day we took some time in alternatives for scp copies between two machines.
 
Some useful links for reading and just patience for copying:

NOTE: ~/Music and /data/music are simple tests on a local SSD disk. 

Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Linux commands for network checking in Alfresco

Last day we wrote a little bit about basic commands to check disks in an Alfresco installation [4]. This post is inspired in some basic network recipes and tests for an Alfresco installation, usually in a three tier configuration composed by three boxes. For example:
  • A - Apache Frontend
  • B - Alfresco Server
  • C - Database Server 
First checking we do is to try simple pings between the boxes via ping -c command. A suitable network perfomance (for Alfresco) is getting roundtrips (rtt) smaller than 1 ms and a standard deviation less than 0.1 ms between Alfresco and Database Server. This test in fact, is part of Alfresco Environment Validation Tool (EVT) and it is part of Alfresco documentation.
 
From Computer B:
 
$ ping -c database-server
 
We usually need first to check some ports, for example via nc command [1] & [2], a very useful tool for checking ports, telnet usage, transfer files or partitions, and so on. For example from Apache Web server we may want to check if there are available 8009 and 8080 ports in Alfresco server for reverse proxy. It is clear that all ports mentioned must be available via local iptables (in the following example 8009 and 8080 in Alfresco Server).
 
From Computer A:
 
$ nc -v alfresco-server 8009
$ nc -v alfresco-server 8080
 
NOTE: You must check these ports in an Alfresco installation [3]
 
These ports are typical in any tomcat server. From your nagios / icinga box, you may want to monitor JMX in Alfresco. Then you need to enable JMX in Alfresco Server and configure JMX monitor port (monitor.rmi.service.port=50508) defined in alfresco-global.properties
 
And from Nagios / Icinga Box:
 
$ nc -v alfresco-server 50508
 
A network perfomance can be achieved via a combination of nc and dd command. Last day, we used dd to test how fast our disks write. 
 
For example:
 
In Computer C (database server), we can open a socket in 12345 (this port must be opened via local iptables).
 
$ nc -vvlnp 12345 > /dev/null
 
In Computer B (application server):
 
$ dd if=/dev/zero bs=1M count=1K | nc -vvn database-server 12345
 
Connection to database-server 12345 port [tcp/*] succeeded!
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 9.11995 s, 118 MB/s
 
Another possibility, mentioned by Gustavo in this blog for doing this [5] and [6], is via iperf (we need iperf installed in both boxes) which uses 5001 as default port 
 
Then on Computer C (as server - needs 5001 port):
 
$ iperf -s -p 5001 
 
And on Computer B:
 
$ iperf -c <address of Computer C>
 
------------------------------------------------------------
Client connecting to database, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local alfresco port 37248 connected with database port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.04 GBytes    893 Mbits/sec
 
Links:
Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude

Linux commands to check network performance

Siguiendo un poco con el post de mi compañero Cesar , voy a poner una receta para comprobar la velocidad de transferencia entre equipos. En realidad para ello se uso el comando iperf, que se puede instalar en ubuntu, debian y centos/redhat con los gestores de paquetes de cada distro. Lo que hay que hacer es

  1. Levantar un socket de recpción en la maquina destino (iperf -s)
  2. Desde la máquina origen llamar al servicio que se ha inciado en el puerto 5001 (iperf -c IP_DE_LA_OTRA_MAQUINA)

El resultado será un pequeño informe, por pantalla de la velocidad de transferencia entre ambos equipos.

Sencillo pero muy útil...

 

Kategoriak: Sailkatugabeak | Komentarioak desgaituta daude