Posts Tagged ‘Oracle’


The Oracle RAC: what is it an how does it work


Wizdoc [Icon By Buuf]  Tips & Tricks

SP Versión en Español

One of the new features included within the Oracle software is the ability to create database clusters (also called Real Application Cluster – RAC). According to Oracle, this feature allows for high availability, performance and scalability. The transparent failover (Transparent Application Failover – TAF) feature is also included, which is used by the deployed applications to synchronize their requests through the Oracle cluster without knowing whenever any of the cluster nodes has been disconnected.

How does it work?

Conceptually, the Oracle RAC architecture is shown on the following diagram:

Diag conceptual Oracle RAC

Fig.1 Conceptual diagram of the Oracle RAC inner workings (failover configuration) including from top to bottom: the application server, the high-speed Ethernet where everything is connected, the Oracle RAC composed by Node 1 and Node 2, a pair of optic fiber connections, a SAN switch to connect the database server to the storage, and the disk array.

The database requests are generated by the application (for instance, from a database connection pool configured on the Application Server), and the Oracle RAC is in charge of redirecting these requests to the working server. Note that in this configuration there is no load balancing, so the showed configuration is plain failover – that is, all incoming requests will reach Node 1, and just in case it ceases to work or is disconnected, all requests will be redirected to Node 2.

However, we need to look how the Oracle RAC really works. This can be better explained if we use a UML component diagram:

Diagrama Componentes Oracle RAC
Fig.2 Oracle RAC component diagram
(click on the image to see larger version)

In fact, the Oracle client or service has the Node 1 configured as the primary connection; if it is not possible to resolve the request on that server, the service will redirect the request to the backup server (in this case the Node 2). Also, it is important to mention that it is the database engine listener what is running on nodes 1 and 2, not the database by itself: the information (that is, the files that form part of the database) are located on a disk array with a mirror configuration to provide redundancy – and therefore, high availability. On summary:

The Oracle RAC is a software component that allows the creation of multiple database engine instances on an independent manner, sharing the same storage.

However, RAC has two very important limitations that are necessary to take into account:

  1. There is no load balancing between the database nodes that form part of the Oracle RAC: this default configuration just allows the request failover for performed requests, and if the architecture design requires resource optimization, we are certainly wasting half the processing power of the back-end tier.
  2. This failover is not as transparent as Oracle claims (see next section).

Implementing TAF

Once an Oracle RAC node is disconnected – being the cause a hardware or network failure o a resource over-demand – all transactions must be automatically redirected to the backup node. The point of such scheme is not to loose the requests that were on-the-fly at the time of the disconnection.

The problem is, according to Oracle (see here), to use the TAF features we must implement the Oracle Call Interface – OCI API. In short, we need to install an Oracle client on the Application Server, and the use of a simple database connection driver – such as the Java Thin Client – is not enough.

Also, at least for the Oracle 10g version, TAF performs the transparent failover just for queries of the SELECT kind only. All other operation types will throw an error automatically:

  • Transactional or data manipulation queries: INSERT, UPDATE and DELETE.
  • Session management operations: ALTER SESSION and SQL*Plus.
  • Temporal objects (those that reside on the TEMP workspace).
  • States as result of stored procedure executions (PL/SQL).

Therefore, we reach the following conclusion:

Oracle RAC, by itself, does not guarantee a transparent failover; it only guarantees database availability. The failover is implemented by the Oracle OCI client, with some restrictions.

This limits the Oracle RAC viability, considering the cost-benefit as this is quoted separately from the database engine (see here).

Improving Oracle RAC

However, not all is lost. Both issues (load balancing and transparent failover) can be solved by a software or hardware load-balanced-cluster. The scalability of such solution depends more on the budget we have, but it supports our decision to implement the Oracle RAC for database high-availability.

The conceptual diagram is showed on the following image:

Diag conceptual Oracle RAC con balanceo
Fig.3 Oracle RAC with load balancing

The balancer is in charge of the load balancing; this can be either a software component (for instance, a web server with round-robin balancing like Apache) or a hardware component (like an F5 Switch) in such configuration as to allow:

  • No dependencies to an Oracle client installed on the application server. This is especially important when it is not possible to install such component or it is necessary to increment the portability of the platform.
  • The resources are optimized when distributing the load between two or more servers that form part of the solution.
  • The load balancing component is in charge of detecting failures/disconnection events on the back-end tier nodes. How are detected such disconnections depends upon the deployed component – for instance, through the use of pings to each node heartbeat – and can be configured as follows:
    • Redirecting at first error. Whenever a disconnection error occurs, the component redirects the remaining requests to the live nodes of the platform, until the affected node’s heartbeat is regain. The problem is that the on-the-fly requests return an error state. This should be resolved with a retry mechanism by the application itself or the application container (in case the Application Server and the database driver support such feature). For this particular case, it can be used Oracle Cache Fusion, which is a component that allows us to synchronize data blocks between the cluster nodes; however we loss the load balancing feature with this solution.
    • Lossless redirection. This is accomplished by using a combination of the OCI client, the load balancer and a special TAF configuration which specifies that requests must be sent to both nodes of the platform and the request that comes first is resolved – discarding the second. This allows for a completely transparent failover without requiring modifications to the application, but has one drawback: traffic between the middle and back end tiers is effectively doubled.
    • The Sun Cluster option. According to Sun Microsystems, the Sun Cluster software allows for request redirection without loss and no need for additional configurations to the platform: Sun Cluster and the agents installed on each of the cluster nodes synchronize the requests, avoiding transaction loss in case of a disconnection. This is the equivalent of a web application failover where the user sessions migrate between the active nodes of the cluster in the event that one fails. (Modified on [12/12/2007]: We already have an implementation of Sun Cluster with Oracle RAC 10g R2: see here the concept and here how to configure it).


Oracle RAC is a component that provides high availability to our back-end by allowing the deployment of multiple instances of a database listener – and a single storage unit. This in turn, allows us – with the help of a balancing component – high availability and scalability of the services offered by the database.

Update on (12/12/2007)

The latest version of Oracle RAC (for Oracle 10g release 2) includes a major overhaul in terms of technology implemented by the solution. Therefore, we now have two features that were very much absent on the previous version:

  • As part of the architecture of Oracle RAC, we now have load balancing between the nodes that make up the cluster. That balancing can be done either through round-robin, or resources consumption (mainly CPU and memory).
  • The load balancing configuration can be done from either the client or the server:
    • The thin clients – such as JDBC – can be configured to make use of load balancing, by changing the connection URL so that they can connect to any of the N nodes that make up the cluster:
      Conventional URL

      "jdbc:oracle:thin:@unique_node:1521", "username", "password"

      Oracle RAC URL (nodes node_1 and node_2)

      "jdbc:oracle:thin:@ (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = node_1)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = node_2)(PORT =1521)) (LOAD_BALANCE = yes) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = myservice) (FAILOVER_MODE = (TYPE = SELECT) (METHOD = BASIC) (RETRIES = 180) (DELAY = 5))))", "username", "password"

      As can be seen, the connection string has practically all the contents of a tnsnames.ora file, and it is not necessary to install additional components.

    • Both thick clients as well as OCI clients still can use the load balancing from the tnsnames.ora file.

As a side note, load balancing is done by the RAC itself as long as the only content that exists in the nodes of the Oracle RAC is the database itself – i.e. the RAC does not work properly if within the filesystems of such nodes there is something else, such as external logging files or additional information to be stored and synchronized. In that case, we must use the alternative of an additional balancing component.


El wait-based tuning: un ejemplo de la vida real


Wizdoc [Icon By Buuf]

 Tips & Tricks

La semana pasada vimos qué es la Administración del Desempeño de Aplicaciones (APM) y los fundamentos del wait-based tuning (WBT). En esta parte la intención es demostrar cómo opera esta metodología con un ejemplo de la vida real.

1. Arquitectura y configuración

Para este ejemplo utilizaremos una arquitectura web estándar:

Una arquitectura web estándar.
[Click en imagen para ver versión más grande]

Podemos describir la arquitectura en función del tier donde nos encontremos:

  • Hardware. Seis servidores con arquitectura RISC de dos procesadores por socket a 1.5 GHz c/u; 4 GB en RAM y un disco duro de 73 GB de espacio. Dos servidores balanceados por cada tier.
  • Front End. Dos servidores cada uno con una instancia de un servidor web (Apache Http Server) y configuración inicial de 150 threads activos.
  • Middle End. Dos servidores con dos instancias lógicas del servidor de aplicaciones (Sun Application Server), cada una con 50 threads, 30 conexiones a base de datos, un cache asignado para 500 Entity Beans y 1 GB de memoria asignada al heap de la Máquina Virtual de Java.
  • Back End. Dos servidores con un motor de base de datos como parte de un Oracle 10g RAC configurado. En el diagrama no se incluyen el disco externo ni el balanceador de alta disponibilidad – requisitos de dicha instalación – para efectos de simplicidad.
  • Firewalls. Los equipos se encuentran separados en dos zonas de seguridad: una DMZ para el front end y una intranet segura para los equipos de middle y back-end. La única forma de acceder a los equipos del back end es mediante los firewalls y todos los puertos y servicios no esenciales han sido deshabilitados.
  • Conectividad. El balanceo de cargas es implementado por dos balanceadores dedicados específicamente para este fin; la configuración de ambas capas es activo-activo (es decir, ambos nodos están funcionando con balanceo de carga, al contrario de una configuración activo-pasivo donde uno funciona y el otro entra en acción en caso de falla).

2. Diagnóstico

De acuerdo al plan original, esta plataforma está diseñada para un ambiente de producción mediano, con la capacidad para 2,000 usuarios concurrentes. Para validar qué tanto tuning es necesario hacer, se realizan las pruebas de desempeño, carga y estrés: Se genera una prueba base con 1,000 usuarios concurrentes durante 20 minutos y a partir de dichos 20 minutos, se agregan 50 usuarios cada 5 minutos hasta llegar a 2,200. Sin ahondar mucho en cómo corre la prueba, después de los 2,200 usuarios los servidores empiezan a congelarse y a generar errores OutOfMemoryError.

El resultado de las pruebas proporciona el siguiente diagnóstico:

  • Existe un alto desperdicio de recursos, pues bajo estrés los servidores de aplicaciones y base de datos llegan a un máximo de uso de CPU del 20% y 40% respectivamente.
  • La caída del sistema se debe a falta de memoria, no CPU. Esto implica falta de tuning de pools, caches y heap del JVM.
  • La falta de tuning puede comprobarse al verificar que el pool de conexiones a base de datos y threads de procesamiento de peticiones del application server están siendo utilizados al 100%; quedando pendientes de procesar (en espera) 10 threads y 20 peticiones en promedio.
  • El Cache Hit Ratio de Entity EJBs tiene una tasa del 40%, es decir, que de 100 peticiones a la capa de persistencia, 60 tienen que ir a la base de datos y sólo 40 se extraen de memoria.

El diagrama mostrado a continuación muestra esquemáticamente los resultados de las pruebas:

Los resultados de las pruebas de diagnóstico de desempeño.
[Click en imagen para ver versión más grande]

3. Iteración 1

Enfocándonos en la última tina, cuya capacidad está siendo desperdiciada, analizamos el punto donde las peticiones esperan demasiado: Los pools y caches de recursos del Application Server. Por lo tanto, incrementamos los hilos de ejecución y conexiones a base de datos para aumentar el uso de CPU de ésta. Entonces re-configuramos y volvemos a correr el batch de pruebas de volumen para ver los resultados. Los cambios de configuración y sus efectos son los siguientes:



Threads de ejecución +50
Conexiones BdD +30
Entity EJB +500

CPU (Web Server) 75%
CPU (App Server) 50%
CPU (BdD) 70%
Entity EJB CHR 80%

Básicamente, al duplicar los pools y caches de recursos, incrementamos el uso de CPU de la plataforma en su conjunto en poco menos del doble. Esto se puede ver en el siguiente diagrama:

Los resultados de la primera iteración del tuning.
[Click en imagen para ver versión más grande]

Como puede verse, todavía no llegamos al óptimo pues aunque ya tenemos 80% de Cache Hit Ratio de Entity EJBs, todavía persiste un desperdicio de CPU y un excedente de peticiones en espera de ser atendidas.

4. Iteración 2

Incrementamos 20 hilos de ejecución y otras 30 conexiones a base de datos, esperando alcanzar el uso óptimo de CPU de esta última…



Threads de ejecución +20
Conexiones BdD +30

CPU (Web Server) 85%
CPU (App Server) 40%
CPU (BdD) 95%
Peticiones Pendientes 40

…sin embargo llegamos a un punto de saturación con 95% procesador. También mejoró el uso del Web Server, pero la saturación de la Base de Datos hace que en el Application Server se queden más peticiones en espera (¡casi el doble!). Esto puede verse en el siguiente diagrama:

Los resultados de la segunda iteración del tuning
(Una saturación de la Base de Datos)
[Click en imagen para ver versión más grande]

Por lo tanto, tendremos que disminuir un poco la capacidad de dichos recursos.

5. Iteración 3

Al disminuir los hilos de ejecución y conexiones a base de datos a 100 y 75 respectivamente, incrementamos notablemente el desempeño de nuestra plataforma:



Threads de ejecución -20
Conexiones BdD -15

CPU (App Server) +80%
CPU (BdD) 85%%
Threads pendientes de ejecución 5
Peticiones pendientes de ejecución 10

Como puede verse en el diagrama más abajo, prácticamente ya estamos hechos: sólo falta disminuir un poco el flujo de entrada de y hacia el application server para no tener más peticiones o hilos pendientes de ser atendidos.

Los resultados de la tercera iteración del tuning.
[Click en imagen para ver versión más grande]

6. Iteración 4

Así entonces, disminuimos los hilos de ejecución de y hacia el application server por 10 y 25 respectivamente. Volvemos a correr nuestro set de pruebas y… ¡voila! alcanzamos el tuning perfecto:

Los resultados de la tercera iteración del tuning.
[Click en imagen para ver versión más grande]

Con un uso de CPUs de aproximadamente el 85% (excelente número bajo pruebas de estrés), pools de conexiones a base de datos e hilos de ejecución a 95% y 90% de capacidad respectivamente y cero peticiones pendientes de procesar, hemos alcanzado un buen nivel de tuning. Los siguientes pasos serían la optimización sobre la base de datos y la aplicación misma, si no es que ya han sido realizados.


Como hemos podido ver en los dos últimos posts, la APM nos permite generar arquitecturas siempre tomando en cuenta el desempeño final de nuestra solución; formando parte del ciclo de vida de desarrollo y puesta en producción obteniendo resultados en términos cualitativos y cuantitativos.

Por otro lado, el modelo Wait-Based Tuning nos da un marco de referencia para desarrollar pruebas de desempeño, carga y estrés, donde cualquier refinamiento debe empezar por los niveles de ejecución más altos (la aplicación) y finalizar con los más bajos (el hardware).


El Oracle RAC: Qué es y cómo funciona


Wizdoc [Icon By Buuf]  Tips & Tricks

EN Versión en Inglés / English Version

Una de las nuevas características incluidas en el software de Oracle es la creación de clusters de base de datos (llamado Real Application Cluster – RAC). De acuerdo a Oracle, esta funcionalidad permite disponibilidad 24/7, desempeño y escalabilidad. Adicionalmente a esto se incluye la definición de failover transparente (Transparent Application Failover – TAF) que utilizan las aplicaciones para sincronizar sus peticiones con el clúster de Oracle sin que éstas se enteren que alguno de los nodos del clúster se ha desconectado.

¿Cómo funciona?

Conceptualmente, la arquitectura del Oracle RAC se muestra en la siguiente figura:

Diag conceptual Oracle RAC
Fig.1 Diagrama conceptual del
funcionamiento de un Oracle RAC
(configuración en failover)

Las peticiones a la base de datos son generadas por la aplicación (por ejemplo, desde un pool de conexiones configurado en un Application Server), y el Oracle RAC en su conjunto es el encargado de direccionar las peticiones al servidor que esté en funcionamiento. Nótese que en esta configuración no existe un balanceo de cargas, por lo que la configuración mostrada es exclusivamente en failover (es decir, todas las peticiones llegarán al Nodo 1, y sólo en caso de que éste deje de funcionar, las peticiones se redireccionarán al Nodo 2).

Ahora bien, es necesario contemplar cómo funciona realmente el Oracle RAC. Esto se puede ver mejor si utilizamos un diagrama de componentes de software:

Diagrama Componentes Oracle RAC
Fig.2 Diagrama de componentes Oracle RAC
(dar click en imagen para ver versión más grande)

En realidad, el cliente o servicio de Oracle está configurado para tener como conexión primaria el Nodo 1; si no es posible ejecutar la petición enviada a dicho servidor, el servicio se encarga de realizar un redireccionamiento de la misma hacia el servidor de respaldo (en este caso el Nodo 2). Adicionalmente, es necesario mencionar que lo que está corriendo en los Nodos 1 y 2 es el listener del motor de base de datos, no la base en sí: la información de la base (los archivos que componen la DB) se encuentra en un arreglo de discos con configuración en mirror para proveer redundancia y por lo tanto, alta disponibilidad. En resumen:

Oracle RAC es un componente de software que permite la creación de múltiples instancias del motor de base de datos de forma independiente, compartiendo un mismo almacenamiento.

Sin embargo, RAC posee dos limitaciones muy importantes que es necesario considerar:

  1. No existe un balanceo de carga entre los nodos de base de datos que componen el Oracle RAC: ésta configuración por default sólo permite el failover de las peticiones realizadas sobre la base de datos y si el diseño de la arquitectura requiere la optimización de recursos, prácticamente se está desperdiciando la mitad del poder de procesamiento de la capa del back-end.
  2. Dicho failover no es tan transparente como dice Oracle (ver adelante).

Utilizando TAF

Una vez que un nodo del Oracle RAC se desconecta (ya sea por falla de hardware, red o sobredemanda de recursos), todas las transacciones deben ser redireccionadas automáticamente al nodo de respaldo. El punto de dicho esquema consiste en no perder las transacciones que se encontraban en vuelo en el momento de la desconexión.

El problema radica en que de acuerdo al mismo Oracle (ver aquí), para hacer uso la funcionalidad de TAF es necesario utilizar el API del Oracle Call Interface – OCI. En pocas palabras, es necesario instalar un cliente de Oracle en el servidor de aplicaciones, y el simple uso de un driver de conexión a la base de datos (por ejemplo, el Thin Client de Java) no es suficiente.

Adicionalmente, cuando menos para la versión 10g de Oracle, TAF sólo realiza failover transparente para queries de tipo SELECT. Todos los demás tipos de operaciones marcarán un error automáticamente:

  • Queries transaccionales o de manipulación de datos: INSERT, UPDATE y DELETE.
  • Operaciones de manejo de sesión: ALTER SESSION y SQL*Plus.
  • Objetos temporales (aquellos que utilizan el espacio de trabajo TEMP).
  • Estados obtenidos durante la ejecución de Stored Procedures (PL/SQL).

Así entonces, llegamos a la siguiente conclusión:

Oracle RAC no garantiza por sí mismo un failover transparente (sólo garantiza disponibilidad de la base de datos). El failover es implementado por el OCI en el cliente de Oracle, con ciertas restricciones.

Esto limita la viabilidad de Oracle RAC considerando el costo-beneficio pues éste se cotiza de forma separada al motor de la base de datos (ver aquí).

Mejorando Oracle RAC

Sin embargo, no todo está perdido. Ambos problemas (balanceo de cargas y failover transparente) pueden ser resueltos mediante un clúster con balanceo de carga por hardware o software. La escalabilidad de dicha solución depende más bien del presupuesto con el que se cuenta, pero soporta la decisión de implementar un Oracle RAC para alta disponibilidad de la base de datos.

El esquema conceptual se muestra en la siguiente figura:

Diag conceptual Oracle RAC con balanceo
Fig.3 Oracle RAC con balanceo de cargas

El encargado de realizar la distribución de carga es el balanceador. Éste puede ser un componente de software (por ejemplo, un Web Server con balanceo round-robin como Apache) o uno de hardware (como un Switch F5) de tal forma que:

  • No exista dependencia hacia un Oracle Client instalado en el servidor de aplicaciones. Esto es especialmente importante cuando no se puede instalar este componente o es necesario incrementar la portabilidad de la plataforma.
  • Se optimizan los recursos al distribuir la carga entre los dos o más servidores que componen la solución.
  • El componente de balanceo es el encargado de detectar las caídas de los nodos de la capa de back-end. El cómo se detectan dichas caídas depende del componente utilizado (por ejemplo, mediante pings al heartbeat de los nodos) y puede configurarse de la siguiente manera:
    • Redireccionamiento al primer error. Cuando ocurre un error de desconexión, el componente redirecciona las demás peticiones que lleguen hacia los demás nodos de la plataforma, hasta que vuelva a recuperar el heartbeat del nodo afectado. El detalle es que las peticiones en vuelo regresan un error. Esto se tendría que resolver con un mecanismo de reintento ya sea en la aplicación misma o en el contenedor (en caso de que el Servidor de Aplicaciones y el driver de base de datos soporten dicha funcionalidad). Para este caso particular, puede utilizarse el Oracle Cache Fusion, que básicamente es un componente que permite sincronizar bloques de datos entre los nodos del clúster, pero con esta solución perdemos el balanceo de cargas.
    • Redireccionamiento sin pérdida. Este se logra utilizando una combinación del cliente OCI, el balanceador de carga y una configuración especial del TAF donde se especifica que las peticiones deben lanzarse a ambos nodos de la plataforma y el que llega primero es resuelto (descartando el segundo). Esto en efecto permite un failover completamente transparente sin necesidad de modificaciones en la aplicación, pero tiene un inconveniente: duplica el tráfico transaccional entre las capas de middle y back end.
    • La opción con Sun Cluster. De acuerdo a Sun Microsystems, el Sun Cluster permite realizar un redireccionamiento sin pérdida y sin necesidad de configuraciones adicionales a la plataforma: el Sun Cluster y los agentes instalados en cada uno de los nodos se dedican a sincronizar las peticiones evitando la pérdida de transacciones en caso de un error. Esto es el equivalente al failover de una aplicación web donde las sesiones de usuario se migran entre los nodos activos del clúster en caso de que uno falle. (Modificado [12/12/2007]: Ya tenemos una implementación de Sun Cluster con Oracle RAC 10g R2: ver aqui el concepto y aqui cómo configurarlo).


Oracle RAC es un componente que nos permite agregar alta disponibilidad a nuestro back-end al ofrecer múltiples instancias de una base de datos (con una sola unidad de almacenamiento), permitiendo con la ayuda de un componente de balanceo, alta escalabilidad y disponibilidad de los servicios ofrecidos por la base de datos.

Actualización (12/12/2007)

La última versión del Oracle RAC (para Oracle 10g release 2) incluye un cambio mayor en cuanto a la tecnología implementada por la solución. Así entonces, ya se tienen dos características que hacían bastante falta:

  • Ya existe, como parte de la arquitectura del Oracle RAC, el balanceo de carga entre los nodos que componen el cluster. Dicho balanceo puede hacerse ya sea mediante round robin, o consumo de recursos (CPU y memoria).
  • La configuración del balanceo puede hacerse desde el cliente o el servidor:
    • Los clientes delgados (thin clients), como es el caso de JDBC, pueden configurarse para hacer uso del balanceo de cargas, cambiando la URL de conexión de tal forma que puedan conectarse a cualquiera de los N nodos que conforman el cluster:
      URL convencional

      "jdbc:oracle:thin:@nodo_unico:1521", "username", "password"

      URL para un Oracle RAC (nodos nodo_1 y nodo_2)

      "jdbc:oracle:thin:@ (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = nodo_1)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = nodo_2)(PORT =1521)) (LOAD_BALANCE = yes) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = miservicio) (FAILOVER_MODE = (TYPE = SELECT) (METHOD = BASIC) (RETRIES = 180) (DELAY = 5))))", "username", "password"

      Como puede apreciarse, es prácticamente el contenido de un archivo tnsnames.ora lo que se está definiendo en el URL de conexión del driver, y no es necesario instalar componentes adicionales.

    • Tanto los thick clients como los OCI clients pueden configurar el balanceo desde el tnsnames.ora como se venía haciendo anteriormente.

Como nota adicional, el balanceo de cargas se realiza solito sin ningún problema, siempre y cuando lo único que exista en los nodos del Oracle RAC sea la base de datos en sí; es decir el RAC no funciona correctamente si en los filesystems de dichos nodos existe algo más, como archivos de logueo o información adicional que se desea almacenar y sincronizar en dichos nodos. En ese caso, sí debe utilizarse la alternativa de un componente de balanceo adicional.