Ayuda para tus sistemas: junio 2012

viernes, 29 de junio de 2012

XSCF - Alarmas del sistema

Si en uno de nuestros servidores Sun, aparece el led de alarma iluminado, deberemos investigar que es lo que ocurre, puede que haya algún hardware dañado y que sea necesario reparar.

Los servidores Sun de la serie MXXXX, incluyen un hardware (XSCF) para controlar, configurar y supervisar el servidor.

El XSCF proporciona una linea de comandos para ejecutar todas las operaciones, también es posible acceder al XSCF a través de un navegador web, siempre y cuando se haya habilitado. Desde este interface como ya hemos comentado podemos monitorizar, configurar y controlar todo el Hardware del servidor, localmente y remotamente si configuramos el interfaz de red.

A continuación vamos a ver algunos comandos básicos para obtener mas información acerca de los alarmas que nos está dando el servidor.

Para ver el estado general del sistema lo haremos con showstatus, en nuestro caso la alarma que vemos en el chassis es por el XSCFU que está en estado degradado.

XSCF> showstatus

* XSCFU Status:Degraded;

Para ver el log de errores, podemos usar el comando "showlogs error" o "fmdump", vamos a ver los dos con diferentes opciones para que nos muestre mas información. Nuestro problema es "A hard-to-diagnose failure of the XSCF has occurred."

XSCF> showlogs error
Date: May 07 11:18:43 UTC 2012 Code: 60000000-c201faff-011d001200000000
Status: Warning Occurred: May 07 11:18:37.456 UTC 2012
FRU: /XSCFU,/FIRMWARE
Msg: XSCF watchdog timeout
Date: Jun 28 17:42:38 UTC 2012 Code: 60000000-feff0000-0104250100000000
Status: Warning Occurred: Jun 28 17:42:38.700 UTC 2012
FRU: /ENVIRONMENT
Msg: High temperature at air inlet

XSCF> fmdump -m

MSG-ID: SCF-8006-YS, TYPE: upset, VER: 1, SEVERITY: Minor

EVENT-TIME: Mon May 7 11:18:43 UTC 2012

PLATFORM: SPARC Enterprise M4000, CSN: BCF102222D, HOSTNAME: SERVER-ADM

SOURCE: sde, REV: 1.16

EVENT-ID: ced395a2-85c3-42db-8bb0-801d40086d10

DESC: A hard-to-diagnose failure of the XSCF has occurred.

Refer to http://www.sun.com/msg/SCF-8006-YS for more information.

AUTO-RESPONSE: The XSCFU will reboot. If the configuration has redundant XSCFU's, the standby XSCFU

may take over as the active XSCFU.

IMPACT: The XSCFU will reboot. If the configuration has redundant XSCFU's, the standby XSCFU

may take over as the active XSCFU. There is no impact to the domains.

REC-ACTION: Please consult the detail section of the knowledge article for additional information.

MSG-ID: SCF-8006-3J, TYPE: Fault, VER: 1, SEVERITY: Critical

EVENT-TIME: Thu Jun 28 17:42:38 UTC 2012

PLATFORM: SPARC Enterprise M4000, CSN: BCF102222D, HOSTNAME: SERVER-ADM

SOURCE: sde, REV: 1.16

EVENT-ID: 39f21a38-d3b2-4620-999f-8a5a564ef6b8

DESC: Over-temperature warning condition has been detected by inlet temperature sensor, exhaust temperature

sensor, or CPU temperature sensor.

Refer to http://www.sun.com/msg/SCF-8006-3J for more information.

AUTO-RESPONSE: Fan speed will be raised for all fans on the platform. If the over-temperature warning

condition has been detected by an exhaust temperature sensor or a CPU temperature sensor, shutdown

messages will be sent to domains on the platform.

IMPACT: If the over-temperature warning condition has been detected by an exhaust temperature

sensor or a CPU temperature sensor, shutdown messages will be sent to domains on the platform.

REC-ACTION: Platform administrator should investigate the cause of the over-temperature condition.

Please consult the detail section of the knowledge article for additional information.

Con el EVENT-ID que nos ha dado el comando anterior podemos obtener mas información acerca del hardware que está fallando.

XSCF> fmdump -v -u ced395a2-85c3-42db-8bb0-801d40086d10

TIME UUID MSG-ID

May 07 11:18:43.6383 ced395a2-85c3-42db-8bb0-801d40086d10 SCF-8006-YS

100% upset.chassis.SPARC-Enterprise.xscfu

Problem in: hc:///chassis=0/xscfu=0

Affects: -

FRU: hc://:product-id=SPARC Enterprise M4000:chassis-id=BCF102222D:server-id=SERVER-ADM:serial=BF10074DTH:part=CF00541-0481 04 \541-0481-04:revision=0101/component=/XSCFU_B#0

Location: /XSCFU_B#0

Si hacemos un check de todo el hardware del sistema veremos marcado con un "*" el problema.

XSCF> showhardconf

SPARC Enterprise M4000;

+ Serial:BCF102222D; Operator_Panel_Switch:Locked;

+ Power_Supply_System:Single; SCF-ID:XSCF#0;

+ System_Power:On; System_Phase:Cabinet Power On;

Domain#0 Domain_Status:Running;

MBU_A Status:Normal; Ver:0101h; Serial:BC10090C0C ;

+ FRU-Part-Number:CF00541-0893 08 /541-0893-08 ;

+ Memory_Size:32 GB;

CPUM#0-CHIP#0 Status:Normal; Ver:0501h; Serial:PP100705UJ ;

+ FRU-Part-Number:CA06761-D204 B1 /371-4615-02 ;

+ Freq:2.530 GHz; Type:32;

+ Core:4; Strand:2;

CPUM#0-CHIP#1 Status:Normal; Ver:0501h; Serial:PP100705UJ ;

+ FRU-Part-Number:CA06761-D204 B1 /371-4615-02 ;

+ Freq:2.530 GHz; Type:32;

+ Core:4; Strand:2;

MEMB#0 Status:Normal; Ver:0101h; Serial:BF100744E8 ;

+ FRU-Part-Number:CF00541-0545 09 /541-0545-09 ;

MEM#0A Status:Normal;

+ Code:ce0000000000000001M3 93T5660QZA-CE6 4151-439dd600;

+ Type:2A; Size:2 GB;

MEM#0B Status:Normal;

+ Code:ce0000000000000001M3 93T5660QZA-CE6 4151-439dd630;

+ Type:2A; Size:2 GB;

MEM#1A Status:Normal;

+ Code:ce0000000000000001M3 93T5660QZA-CE6 4151-439e7e02;

+ Type:2A; Size:2 GB;

MEM#1B Status:Normal;

+ Code:ce0000000000000001M3 93T5660QZA-CE6 4151-439dfb4a;

+ Type:2A; Size:2 GB;

MEM#2A Status:Normal;

+ Code:ce0000000000000001M3 93T5660QZA-CE6 4151-43a00ff0;

+ Type:2A; Size:2 GB;

MEM#2B Status:Normal;

+ Code:ce0000000000000001M3 93T5660QZA-CE6 4151-43a00fd1;

+ Type:2A; Size:2 GB;

MEM#3A Status:Normal;

+ Code:ce0000000000000001M3 93T5660QZA-CE6 4151-522ca0bf;

+ Type:2A; Size:2 GB;

MEM#3B Status:Normal;

+ Code:ce0000000000000001M3 93T5660QZA-CE6 4151-439dd5fb;

+ Type:2A; Size:2 GB;

MEMB#1 Status:Normal; Ver:0101h; Serial:BF0951JN81 ;

+ FRU-Part-Number:CF00541-0545 09 /541-0545-09 ;

MEM#0A Status:Normal;

+ Code:ad0000000000000001HYMP125P72CP4-Y5 4141-3e823576;

+ Type:2A; Size:2 GB;

MEM#0B Status:Normal;

+ Code:ad0000000000000001HYMP125P72CP4-Y5 4141-3e327188;

+ Type:2A; Size:2 GB;

MEM#1A Status:Normal;

+ Code:ad0000000000000001HYMP125P72CP4-Y5 4141-3e42718c;

+ Type:2A; Size:2 GB;

MEM#1B Status:Normal;

+ Code:ad0000000000000001HYMP125P72CP4-Y5 4141-3e22719f;

+ Type:2A; Size:2 GB;

MEM#2A Status:Normal;

+ Code:ad0000000000000001HYMP125P72CP4-Y5 4141-3e52358c;

+ Type:2A; Size:2 GB;

MEM#2B Status:Normal;

+ Code:ad0000000000000001HYMP125P72CP4-Y5 4141-3e42718e;

+ Type:2A; Size:2 GB;

MEM#3A Status:Normal;

+ Code:ad0000000000000001HYMP125P72CP4-Y5 4141-3e22719e;

+ Type:2A; Size:2 GB;

MEM#3B Status:Normal;

+ Code:ad0000000000000001HYMP125P72CP4-Y5 4141-3e82358c;

+ Type:2A; Size:2 GB;

DDC_A#0 Status:Normal;

DDC_A#1 Status:Normal;

DDC_B#0 Status:Normal;

IOU#0 Status:Normal; Ver:0101h; Serial:BF100852C9 ;

+ FRU-Part-Number:CF00541-2240 05 /541-2240-05 ;

DDC_A#0 Status:Normal;

DDCR Status:Normal;

DDC_B#0 Status:Normal;

PCI#1 Name_Property:SUNW,emlxs; Card_Type:Other;

PCI#2 Name_Property:network; Card_Type:Other;

* XSCFU Status:Degraded,Active; Ver:0101h; Serial:BF10074DTH ;

+ FRU-Part-Number:CF00541-0481 04 /541-0481-04 ;

OPNL Status:Normal; Ver:0101h; Serial:BF10063ENT ;

+ FRU-Part-Number:CF00541-0850 06 /541-0850-06 ;

PSU#0 Status:Normal; Serial:0017527-1005028791;

+ FRU-Part-Number:CF00300-2011 0250 /300-2011-02-50;

+ Power_Status:On; AC:200 V;

PSU#1 Status:Normal; Serial:0017527-1005028785;

+ FRU-Part-Number:CF00300-2011 0250 /300-2011-02-50;

+ Power_Status:On; AC:200 V;

FAN_A#0 Status:Normal;

FAN_A#1 Status:Normal;

FANBP_B Status:Normal; Ver:0401h; Serial:BF10063T4V ;

+ FRU-Part-Number:CF00541-3098 01 /541-3098-01 ;

FAN_B#0 Status:Normal;

FAN_B#1 Status:Normal;

Con toda la información que hemos obtenido, podemos encontrar una posible solución buscando en metalink con el MSG-ID o contactar directamente con tu proveedor de servicios.

jueves, 28 de junio de 2012

Escalado de Cluster OBIEE11

Hola,

OBIEE se puede instalar como servidor único, como se veía en el post anterior, o como servidores distribuidos formando un cluster, en este ejemplo vamos a ver como instalar un segundo servidor OBIEE para escalarlo a partir de la instalación hecha anteriormente.

El OBIEE que instalamos en el anterior post será el MASTER y éste nuevo será el secundario, podemos escalar horizontalmente con mas servidores.

Pasos a seguir.

Los pasos a seguir son los siguientes:

1.- Instalación Servidor OBIEE MASTER.

2.- Preparación del entorno para el cluster.

3.- Instalación del Servidor OBIEE Secundario.

-----------------------------------------------------------------------------------------------------------

El primer paso si no lo tenemos todavía podemos realizarlo siguiendo los pasos en el enlace que hay justo encima (punto nº 1).

2.- Preparación del entorno.

Antes de hacer la instalación del servidor secundario es necesario hacer algunos pasos previos para que el cluster de OBIEE funcione correctamente.
Los directorios que se ponen en los siguientes ejemplos han sido creados en una tercera máquina y compartidos y montados por NFS en los servidores MASTER y SECUNDARIO.

2.1.- Creación de un repositorio compartido (Repositorio de BI server), el MASTER debe tener permisos de lectura/escritura y los Secundarios sólo de lectura. Se configura en Fusion Middleware Control -> Coreapplication -> Pestaña Despliegue -> Pestaña Repositorio.

2.2.- BI Presentation catalog, se debe compartir desde el OBIEE MASTER el directorio de BI presentation catalog, este directorio debe ser de lectura/escritura para todos los miembros del clúster. Se configura en Fusion Middleware Control -> Coreapplication -> Pestaña Despliegue -> Pestaña Repositorio.

2.3.- Caché Global, se debe crear un directorio compartido de caché global en el OBIEE MASTER, con permisos de lectura/escritura para todos los servidores OBIEE del clúster. Se configura en Fusion Middleware Control -> Coreapplication -> Pestaña Gestión de capacidad -> Pestaña Rendimiento.
Se puede configurar la ruta compartida y el tamaño de la caché global.

3.- Instalación del Servidor OBIEE Secundario.

El siguiente paso es hacer la instalación del OBIEE secundario para añadirlo al clúster creado con la primera instalación.

-bash-3.2$ ./runInstaller
Starting Oracle Universal Installer...

Checking Temp space: must be greater than 1536 MB. Actual 2480 MB Passed
Checking swap space: must be greater than 500 MB. Actual 7439 MB Passed
Checking monitor: must be configured to display at least 256 colors. Actual 16777216 Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2012-06-28_11-17-21AM. Please wait ...

Pulsamos en OK y ejecutamos los scripts que nos solicita como root.

-bash-3.2$ su -
Password:
Oracle Corporation SunOS 5.10 Generic Patch January 2005
# bash
bash-3.2# /export/home/oraclebi/oraInventory/createCentralInventory.sh
Setting the inventory to /export/home/oraclebi/oraInventory
Setting the group name to dba
Creating the Oracle inventory pointer file (/var/opt/oracle/oraInst.loc)
Changing permissions of /export/home/oraclebi/oraInventory to 770.
Changing groupname of /export/home/oraclebi/oraInventory to dba.
The execution of the script is complete

Pulsamos sobre el botón siguiente.

Configuramos las actualizaciones automáticas.

Seleccionamos la Enterprise.

Elegimos la opción Escalar Sistema BI.

En este paso seleccionamos los directorios que queremos para instalar el OBIEE.

Para hacer la instalación lo mas simple posible, configuración automática.

Pulsamos sobre Instalar para comenzar con la instalación.

Pulsamos Siguiente y Terminar para finalizar con la instalación.

Solaris 10 - añadir swap en un sistema ZFS

Si necesitamos aumentar el tamaño de la swap de nuestro sistema Solaris 10, con un filesystem ZFS, podemos hacerlo de dos formas.

- Redimensionando un volumen de swap existente, si no está en uso.

bash-3.2# swap -l
swapfile dev swaplo bloques libre
/dev/zvol/dsk/rpool/swap 256,1 16 4194288 4194288

bash-3.2# zfs get volsize rpool/swap

NAME PROPERTY VALUE SOURCE

rpool/swap volsize 2G local

bash-3.2# zfs set volsize=4G rpool/swap

bash-3.2# zfs get volsize rpool/swap

NAME PROPERTY VALUE SOURCE

rpool/swap volsize 4G local

- Añadiendo un nuevo volumen swap, a la swap existente.

bash-3.2# swap -l
swapfile dev swaplo bloques libre
/dev/zvol/dsk/rpool/swap 256,1 16 4194288 4194288

bash-3.2# zfs create -V 2G rpool/swap2

bash-3.2# swap -a /dev/zvol/dsk/rpool/swap2

bash-3.2# swap -l

swapfile dev swaplo bloques libre

/dev/zvol/dsk/rpool/swap 256,1 16 4194288 4194288

/dev/zvol/dsk/rpool/swap2 256,3 16 4194288 4194288

jueves, 21 de junio de 2012

Tomcat Cluster - HA

Hola!

En este post veremos como configurar dos Tomcats en diferentes servidores para hacerlos funcionar Cluster con sesiones replicadas.

Para este ejemplo usamos los servidores:

Server01 -> IP: 10.1.1.101
Server02 -> IP: 10.1.1.102

Para empezar descargaremos la última versión de Tomcat disponible,:
http://apache.rediris.es/tomcat/tomcat-7/v7.0.28/bin/apache-tomcat-7.0.28.tar.gz

Descargamos y descomprimimos el software en cada uno de los servidores en el destino que queramos, yo lo he puesto en /opt/www.

[root@SERVER01 ~]# mkdir /opt/www
[root@SERVER01 ~]# wget http://apache.rediris.es/tomcat/tomcat-7/v7.0.28/bin/apache-tomcat-7.0.28.tar.gz
[root@SERVER01 ~]# tar zxvf apache-tomcat-7.0.28.tar.gz

Configuración Server01

[root@SERVER01 ~]# vim /opt/www/apache-tomcat-7.0.28/conf/server.xml

Añadimos esta parte dentro de la etiqueta Host.

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="8">

<Manager className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>

<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.McastService"
address="228.0.0.4"
port="45564"
frequency="500"
dropTime="3000"/>
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="10.1.1.101"
port="4000"
selectorTimeout="5000"
maxThreads="6"/>
<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
</Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=""/>
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
<Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/tmp/war-temp/"
deployDir="/tmp/war-deploy/"
watchDir="/tmp/war-listen/"
watchEnabled="false"/>
<ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>

Configuración Server02

[root@SERVER02 ~]# vim /opt/www/apache-tomcat-7.0.28/conf/server.xml

Añadimos esta parte dentro de la etiqueta Host.

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="8">

<Manager className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>

<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.McastService"
address="228.0.0.4"
port="45564"
frequency="500"
dropTime="3000"/>
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="10.1.1.102"
port="4000"
selectorTimeout="5000"
maxThreads="6"/>
<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
</Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=""/>
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
<Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/tmp/war-temp/"
deployDir="/tmp/war-deploy/"
watchDir="/tmp/war-listen/"
watchEnabled="false"/>
<ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>

*Nota:

<Membership /> es donde se especifica el miembro para conectar con los otros miembros del cluster, estos datos tienen que ser los mismos en todos los miembros del cluster.

<Receiver /> aquí es donde se ponen los datos del servidor que quiere ser miembro del cluster, en cada servidor se tendrá que configurar su ip.

Arrancamos los servicios.

[root@SERVER01 ~]# /opt/www/apache-tomcat-7.0.28/bin/startup.sh

[root@SERVER02 ~]# /opt/www/apache-tomcat-7.0.28/bin/startup.sh

[root@SERVER01 ~]# tail -200f /opt/www/apache-tomcat-7.0.28/logs/catalina.out

INFO: Receiver Server Socket bound to:/10.1.1.101:4000

15-mar-2012 13:29:21 org.apache.catalina.tribes.membership.McastServiceImpl setupSocket

INFO: Setting cluster mcast soTimeout to 500

15-mar-2012 13:29:21 org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers

INFO: Sleeping for 1000 milliseconds to establish cluster membership, start level:4

15-mar-2012 13:29:21 org.apache.catalina.ha.tcp.SimpleTcpCluster memberAdded

INFO: Replication member added:org.apache.catalina.tribes.membership.MemberImpl[tcp://{10, 1, 1, 102}:4000,{10, 1, 1, 102},

4000, alive=19531, securePort=-1, UDP Port=-1, id={-9 10 29 -58 25 -70 74 -56 -70 0 -6 -40 -89 69 62 -111 }, payload={}, command=

{}, domain={}, ]

15-mar-2012 13:29:22 org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers

INFO: Done sleeping, membership established, start level:4

15-mar-2012 13:29:22 org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers

INFO: Sleeping for 1000 milliseconds to establish cluster membership, start level:8

15-mar-2012 13:29:22 org.apache.catalina.tribes.io.BufferPool getBufferPool

INFO: Created a buffer pool with max size:104857600 bytes of type:org.apache.catalina.tribes.io.BufferPool15Impl

15-mar-2012 13:29:23 org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers

INFO: Done sleeping, membership established, start level:8

15-mar-2012 13:29:23 org.apache.catalina.ha.deploy.FarmWarDeployer start

INFO: Cluster FarmWarDeployer started.

*Nota: Como se puede ver en el log, al arrancar los dos Tomcats los miembros se encuentran y se forma el cluster.

Configuración Aplicación.

Ahora lo único que falta es desplegar la aplicación que queramos configurar en alta disponibilidad, antes de desplegarla en cada uno de los tomcats, deberemos añadir la propiedad <distributable /> en el web.xml de la aplicación.

[root@SERVER01 ~]# vim /opt/www/apache-tomcat/webapps/app1/WEB-INF/web.xml

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
<distributable />

Pruebas de sesión.

En las pruebas que se hacen en este ejemplo, hay un servidor web por delante que es el que le pasa las peticiones a los tomcat, por ejemplo un servidor web Apache pasando las conexiones con mod_jk. Si uno de los dos tomcat se cae Apache se da cuenta y solo le pasa el tráfico al que está vivo, cuando el servidor que se ha caído vuelve a responder, Apache vuelve a pasarle peticiones.

Ahora ya podemos desplegar la aplicación y empezar a hacer las pruebas de replicación de sesión.

Para las pruebas y para monitorizar las aplicaciones, recomiendo usar probe, es una aplicación que monitoriza en tiempo real los recursos del servidor Tomcat y las aplicaciones.

https://code.google.com/p/psi-probe/

En la pantalla principal vemos las aplicaciones desplegadas y las sesiones, nuestra aplicación en cluster es la "ap", que como vemos en la parte de la derecha en CLUSTERED está en YES.

Server01

Server02

Si pinchamos sobre "SESS" de la aplicación en cluster veremos que las sesiones coinciden en los dos servidores.

Server01

Server02

Ahora solo falta que probemos nosotros mismos, si apagamos por ejemplo el tomcat del server01, veremos que en el server02 están los clientes funcionando, cuando levantamos el tomcat del server01, automáticamente las sesiones se replican y vuelven a existir.