User Tools

Site Tools


netquest_documentation

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
netquest_documentation [2012/03/02 17:00] dodgernetquest_documentation [2018/04/17 08:54] (current) – removed dodger
Line 1: Line 1:
-====== Descripcion ====== 
-Documentación de la prueba para netquest. 
- 
-====== Bitacora ====== 
-===== pre ===== 
-  * Configurado JVM para jboss con los siguientes parámetros: 
-<code> 
--Xms128m -Xmx1024m -XX:MaxPermSize=256m 
-</code> 
- 
-===== 27/02 ===== 
-  * Configuro Mysql en el jboss como DefaultDS 
-  * Configuro Mysql en el jboss para JMS, elimino hypersonic 
-  * La aplicación está configurada para usar un DS propio con credenciales de root. 
- 
-===== 28/02 ===== 
-  * Configuro el DS de la aplicación en JBOSS con unas credenciales con menos privilegios 
-  * Reempaqueto la aplicación sin el DS para que use la de JBOSS 
-  * Sincronizo JBOSS en el nodo2 
-  * Sincronizo MySQL en el nodo2 
-  * Sincronizo /etc en el nodo2 
-  * Comienzo la configuración de réplica en mysql. 
- 
-===== 29/02 ===== 
-Objetivo: 
-  * Configurar la réplica de mysql 
-  * Eliminar nginx de rh y compilarlo con los módulos "nginx-sticky-module", "nginx-upstream-jvm-route" y "nginx-cache-purge" 
-  * Configurar nginx con los 2 servidores de jboss en el pool 
- 
-DONE: 
-  * Configurar réplica para la bbdd "exam" 
-  * Eliminado nginx, instalada la última versión "from source": 
-<code> 
-nginx version: nginx/1.0.12 
-built by gcc 4.4.5 20110214 (Red Hat 4.4.5-6) (GCC)  
-TLS SNI support enabled 
-</code> 
-  * Done, configurados los 2 jboss'es, cada uno es backup del otro, en modo failover, solo se pasarán peticiones al otro nodo si tenemos el jboss local caído. 
- 
-===== 01/03 ===== 
-Objetivo: 
-  * Configurar caché y el purgado de nginx 
- 
-DONE: 
-  * Caché de nginx configurada, para purgar ficheros de la caché se ha de realizar lo siguiente: 
-<code> 
-http://server01/purge/dinamico 
-</code> 
-Si la URL que queremos purgar es: 
-<code> 
-http://server01/dinamico 
-</code> 
-La limpieza de caché se debe realizar desde la ip local (localhost), limitado en config. 
- 
- 
-===== 02/03 ===== 
-Objetivo: 
-  * Instalar y configurar MysqlProxy 
- 
-DONE: 
-  * Instalado, actualmente el datasource de "exam" accede mediante el mysql-proxy, también se puede probar accediendo a cualquiera de los nodos mediante: 
-<code> 
-mysql --port=4040 --host=server02 -p -u exam 
-mysql --port=4040 --host=server01 -p -u exam 
-</code> 
- 
-===== 0x/03 ===== 
-Objetivo: 
-  * Cambios en las ips de los nodos. 
-  * <del>AWS balancing</del> 
-DONE: 
-  * Programado script para arranque en frio (ver [[netquest_documentation#Arranque frío]]) 
- 
- 
-====== Management ====== 
-Resumen de las acciones principales del sistema: 
-===== nginx ===== 
-==== start ==== 
-<code>/etc/init.d/nginx start 
-</code> 
-==== stop ==== 
-<code>/etc/init.d/nginx stop 
-</code> 
-==== restart ==== 
-<code>/etc/init.d/nginx restart 
-</code> 
-==== Limpieza de la caché ==== 
-Sin usar el método recomendado (por URL), podemos limpiar la caché mediante: 
-<code>rm -fr /dev/shm/nginx* 
-/etc/init.d/nginx restart 
-</code> 
- 
-==== Configuración ==== 
-La configuración ha de realizarse en los directorios: 
-  * ''/etc/nginx'' 
-  * ''/etc/nginx/conf.d'' 
-  * ''/etc/nginx/sites'' 
- 
- 
-===== mysql ===== 
-==== start ==== 
-<code>/etc/init.d/mysqld start 
-</code> 
-==== stop ==== 
-<code>/etc/init.d/mysqld stop 
-</code> 
-==== restart ==== 
-<code>/etc/init.d/mysqld restart 
-</code> 
- 
-==== Acceso al "cluster" ==== 
-El acceso debería realizarse mediante el servicio mysql-proxy o en su defecto por el nodo1 del servicio para no romper la réplica. 
-Para conectarse: 
-<code>mysql -u USUARIO -p -P4040 -h server01 
-</code> 
-==== Replica ==== 
-Conectados al/los nodos SLAVE. 
-=== Parar === 
-<code>stop slave; 
-</code> 
-=== Arrancar === 
-<code>start slave; 
-</code> 
-=== Slave Status === 
-<code>show slave status \G 
-</code> 
-=== Master status === 
-Conectado al nodo MASTER: 
-<code>show master status \G 
-</code> 
- 
- 
-===== mysql-proxy ===== 
-==== start ==== 
-<code>/etc/init.d/MySQL-Proxy start 
-</code> 
-==== stop ==== 
-<code>/etc/init.d/MySQL-Proxy stop 
-</code> 
-==== restart ==== 
-<code>/etc/init.d/MySQL-Proxy stop && sleep 5 && /etc/init.d/MySQL-Proxy start 
-</code> 
- 
-===== jboss ===== 
-==== start ==== 
-<code>/etc/init.d/jboss start 
-</code> 
-==== stop ==== 
-<code>/etc/init.d/jboss stop 
-</code> 
-==== restart ==== 
-<code>/etc/init.d/jboss stop && sleep 5 && /etc/init.d/jboss start 
-</code> 
- 
-===== Arranque frío ===== 
-Para un cold start, se ha programado un script: 
-<code>/root/netquest_cluster_ip_updater.sh 
-</code> 
-Que realiza las siguientes acciones: 
-  * Actualiza el fichero de hosts local con la nueva ip local y las ips locales del resto de los nodos. 
-  * Da la opción de reiniciar los servicios asociados: 
-    * mysql 
-    * mysql-proxy 
-    * jboss 
-    * nginx 
- 
-Nota adicional: [[netquest_documentation#Slave Status|Comprobar el estado de la réplica]] de mysql después de un inicio en frío. 
- 
-====== Objetivo Final (WIP) ====== 
-{{:netquestschema.png?nolink|}} 
-===== Descripción de la arquitectura ===== 
-De arriba a abajo: 
-  * Mediante las herramientas de Amazon se balancearán los webservers 
-  * Ambos webservers están configurados de manera que ataquen a ambos jboss pero priorizando el jboss local, de tal forma que el 2º JBOSS se usará en caso de caída. 
-  * Para obtener el máximo rendimiento de nginx, hemos de separar contenido estático de dinámico, de tal forma que el estático siempre se servirá desde nginx. 
-  * Adicionalmente se usará lo máximo posible la caché de nginx para reducir en la medida de lo posible los accesos a JBOSS. Se proporcionará a los programadores de un sistema de borrado de caché desde la propia aplicación. 
-  * Hay que concretar con el equipo de desarrollo donde sí y donde no se puede instalar la caché dentro de la aplicación web. 
-  * Para evitar el uso del sistema de clustering de jboss se debería tener en cuenta por parte de los programadores un sistema de recuperación de la sesión del cliente desde BBDD para que en caso de caída de un nodo, al balancearse la carga al otro, este sea capaz de comprobar mediante la COOKIE del cliente, las credenciales del mismo y que ya estaba logado. 
-  * En ambos nodos habrá un mysqlproxy de tal forma que cada jboss atacará al mysqlproxy local y este realizará el balanceo de querys de la forma que se puede ver en el esquema. 
- 
  
netquest_documentation.1330707652.txt.gz · Last modified: 2012/03/02 17:00 by dodger