Misión Mensajería: Diseño y funcionamiento de los clusters de WebSphere MQ

Los clusters de IBM® WebSphere® MQ ofrecen facilidad de administración y distribución de la carga de trabajo, además de contribuir a la gran disponibilidad de las soluciones de mensajería. Sin embargo, es necesario que el cluster esté en buen estado para poder aprovechar todos sus beneficios. Esta entrega de Misión Mensajería trae sugerencias para generar un cluster en buen estado y mantenerlo de esta manera. This content is part of the IBM WebSphere Developer Technical Journal.

T.Rob Wyatt, Senior Managing Consultant, WSO2 Inc

T. Rob Wyatt se desempeña como Senior Managing Consultant en IBM Software Services for WebSphere y ayuda a los clientes en la administración, la arquitectura y la seguridad de WebSphere MQ. En la actualidad se centra en la seguridad de WebSphere MQ, con publicaciones en IBM WebSphere Developer Technical Journal y presentaciones en las conferencias IMPACT y European Transaction and Messaging. Además, T. Rob presenta The Deep Queue, un podcast mensual sobre la seguridad en WebSphere MQ.


Nivel de autor profesional en developerWorks

19-01-2010

Verificación de estado del cluster

En mi carácter de consultor especializado en IBM WebSphere MQ, me suelen contactar para que solucione interrupciones de la producción en casos de emergencia. Muchas veces, el problema radica en un cluster en mal estado. Gracias a mi experiencia, pude reconocer patrones recurrentes en estos sistemas interrumpidos y elaboré una serie de recomendaciones para evitar estos problemas y mantener el cluster en buen estado.

El diseño y la gestión de clusters de WebSphere MQ sigue siendo una mezcla de arte y ciencia. No existe un único camino para alcanzar el éxito. De hecho, conocí muchos establecimientos que mantienen su cluster con éxito a pesar de incumplir algunas de mis reglas. Sin embargo, estos casos suelen ser muy contados y específicos, y el éxito depende en gran medida de consideraciones locales, que pueden suponer la presencia de factores atenuantes, como aptitudes avanzadas de supervisión o de administración, o bien la ausencia de factores agravantes, como incidentes de cambio de sistema con un riesgo inusualmente bajo o un cluster muy pequeño.

Sin embargo, con el transcurso del tiempo, todos los sistemas cambian, y las dependencias del entorno local pueden generar fragilidad en el sistema frente a estos cambios. Como consultor, me inclino por los métodos que tienen la máxima aplicabilidad posible. En lo que se refiere a los clusters de WebSphere MQ, los métodos que propongo en este artículo son aquellos que, según mi experiencia, se aplican a casi todos los casos.


¿Qué es un cluster? ¿Qué no es un cluster?

En esencia, un cluster de WebSphere MQ es simplemente una colección de gestores de colas que comparten un espacio de nombres en común, la delegación de ciertas funciones administrativas y una conectividad arbitraria (any-to-any) densa. Todos los beneficios de la agrupación en clusters de MQ se derivan de una o más de estas características. La facilidad de administración es una consecuencia directa de la delegación de un subconjunto de tareas administrativas en un proceso interno de gestión de colas. La capacidad de contar con múltiples instancias de una cola es un artefacto del espacio de nombres común combinado con una conectividad densa. Esto, a su vez, permite una distribución de la carga de trabajo y un enrutamiento dinámico.

Sin embargo, el cluster de WebSphere MQ no es más que una colección de gestores de colas; tampoco pretende ser otra cosa. No existe el concepto de "conectarse al cluster" con WebSphere MQ. Las conexiones siempre se establecen con un nodo específico dentro del cluster. Asimismo, la funcionalidad de la aplicación es la misma, sin importar si el gestor de colas participa en un cluster o no. Como ocurre con la mensajería punto a punto, una aplicación conectada con un gestor de colas en cluster puede recibir mensajes solamente de colas locales y puede colocar mensajes en cualquier cola que se pueda resolver localmente, independientemente del lugar donde esté alojada la cola de destino.

Todo esto puede resultar confuso debido a otros usos del término "cluster". Por ejemplo, un cluster de hardware es una entidad lógica compuesta de múltiples servidores físicos. Aquello que se conecte al cluster de hardware puede ver la entidad lógica, pero no los componentes físicos que la componen. Asimismo, es posible configurar muchos servidores de aplicaciones, bases de datos y otras plataformas de software de manera que parezcan una única entidad. Este uso es tan habitual que para mucha gente la palabra "cluster" implica una entidad lógica compuesta de múltiples componentes físicos que actúan como una unidad.

Por eso no es de extrañar que se generen malentendidos en torno a los clusters de WebSphere MQ. Mucha gente, la primera vez que oye el término cluster de WebSphere MQ, se imagina intuitivamente un gran gestor de colas virtuales compuesto de múltiples gestores de colas físicas que actúan como una unidad. Del mismo modo, el término cola en cluster suele evocar imágenes de múltiples instancias de cola que actúan colectivamente como una única cola lógica con la que una aplicación se puede conectar y luego colocar o recibir mensajes. Sin embargo, este supuesto paradigma no representa en absoluto el funcionamiento de WebSphere MQ, y la confusión que se genera puede dar lugar a malas decisiones de diseño u operación.

La agrupación en clusters de WebSphere MQ no se relaciona con la manera en que las aplicaciones se comunican con el gestor de colas, sino con la manera en que los gestores de colas se comunican entre sí.


Beneficios del cluster de WebSphere MQ

Cuando la agrupación en clusters fue introducida en WebSphere MQ, se comenzó a usar el retrónimo red punto a punto para hacer una distinción entre un cluster y la clásica topología de red de MQ. La principal diferencia consiste en que, en una red punto a punto, los mensajes en cola se trasladan desde un punto de origen hasta un destino único. El enrutamiento en esta red es determinado por cola e incrustado en la definición de red en el tiempo de generación.

Por el contrario, en un cluster, los mensajes se trasladan desde un punto de origen hasta varios destinos posibles. En este caso, la selección del destino y el enrutamiento están determinados por mensaje en tiempo de ejecución. Como consecuencia, la red de WebSphere MQ en cluster es flexible, dinámica y resistente.

Debido a estas características, los clusters de WebSphere MQ son perfectos para las arquitecturas orientadas a servicios (SOA). Pero lo más importante es que el cluster de WebSphere MQ no desplaza la red punto a punto. Cuando sea necesaria una interfaz punto a punto (por ejemplo, una interfaz de lotes), es muy fácil implementarla dentro del cluster de WebSphere MQ. Esta coexistencia de las topologías punto a punto y en cluster permite una transición sin problemas para implementar una SOA.

Sin embargo, es necesario que el cluster esté en buen estado para poder aprovechar todos sus beneficios. El resto de este artículo se centra en los métodos que fui seleccionando a lo largo de todos estos años para generar un cluster en buen estado y mantenerlo de esta manera.


Recomendaciones para los repositorios

Pero antes de empezar con las recomendaciones, les dejo una serie de reflexiones que nos permitirán estar en la misma sintonía.

Cualquier gestor de colas en cluster puede anunciar algunas de sus colas o temas en el cluster y tener otras conocidas solo localmente. De los objetos que se anuncian en el cluster, es necesario hacer un seguimiento de cierta información de estado para que el cluster pueda enrutar los mensajes correctamente. Además de las colas y los temas, el cluster hace un seguimiento del estado de los canales y de los gestores de colas del cluster. Los nombres y estados de todos estos objetos de cluster son los metadatos del cluster.

Dos gestores de colas del cluster son designados para mantener una copia completa y actualizada de todos los metadatos del cluster. En un cluster en buen estado, cada uno de estos nodos contiene una copia reflejada de toda la información relativa al estado del cluster. Como estos nodos poseen la totalidad del conjunto, se llaman repositorios completos.

Todos los demás miembros del cluster mantienen un subconjunto de metadatos de cluster, por lo que se denominan repositorios parciales. Cada uno de estos nodos mantiene el estado en tiempo real de cada objeto de cluster que aloja. Cualquier cambio en estos objetos se publica inmediatamente en los dos repositorios completos. Además, las aplicaciones conectadas a los gestores de colas de los repositorios parciales tienen que colocar mensajes en colas en cluster que pueden estar alojadas en algún otro nodo. El repositorio parcial se suscribe a las actualizaciones de estos objetos remotos y mantiene una copia local del último estado conocido de cada uno de ellos.

Esta terminología de repositorios completos y parciales puede resultar confusa y difícil de manejar. En el lenguaje cotidiano, "repositorio completo" se suele reducir a "repositorio"; todos los demás nodos son meros gestores de colas que participan en el cluster. Este uso concuerda con el conjunto de comandos de WebSphere MQ, que usa REPOS como parámetro.

Por ejemplo, es posible emitir REFRESH CLUSTER(*) REPOS(YES) o ALTER QMGR REPOS(nombre de cluster). Esta será la convención que usaré en este artículo. Cuando diga "repositorio", estaré haciendo referencia a uno de los dos gestores de colas designados como repositorios completos. Todo el resto serán meros miembros del cluster.

A continuación paso a exponer mis recomendaciones:

  • El número mágico es el dos

    Más arriba se mencionó que dos gestores de colas son designados como repositorios. Si bien esto no es obligatorio, lo recomiendo enfáticamente. Los clusters pueden funcionar con un solo repositorio e incluso pueden aguantar, durante un breve período de tiempo, sin ningún repositorio. Sin embargo, el uso de dos repositorios proporciona una mayor disponibilidad. A la larga, será necesario efectuar tareas de mantenimiento en los repositorios, y el hecho tener dos permite que el cluster funcione normalmente mientras uno de ellos está desconectado.

    Pero, si dos es mejor que uno, ¿tres no es mejor que dos? No necesariamente. Cada miembro del cluster publicará dos actualizaciones cuando cambie el estado de alguno de sus objetos. Si hay un solo repositorio, este recibirá ambas actualizaciones. Si hay dos repositorios, cada uno de ellos recibirá uno de los dos mensajes de actualización. En ambos casos, todos los nodos del cluster informan los cambios a todos los repositorios, y la topología tiene incorporada la seguridad de que el estado se mantendrá de forma consistente en todo el cluster.

    En caso de haber tres o más repositorios, cada miembro del cluster actualizará solamente dos de ellos. Para alcanzar la consistencia entre todos los repositorios, será necesario que ellos repliquen con éxito las actualizaciones entre sí. Con dos repositorios, el 100% de los metadatos será entregado directamente desde los miembros del cluster. Con tres repositorios, un promedio de 1/3 de los metadatos será entregado mediante la replicación. Con cuatro repositorios, esa cifra es de 1/2, y con cinco repositorios, la proporción asciende a 3/5. Cuanta más replicación exista, mayor será la probabilidad de errores de replicación. Si se sigue extrapolando, la probabilidad de error se convertirá prácticamente en una certeza.

    En este caso es evidente que cantidad no implica calidad. Todos mis diseños de clusters están basados en dos repositorios, ni uno más ni uno menos. Existen muy contadas excepciones a esta regla. Por ejemplo, en el caso de clusters transcontinentales, algunas veces uso pares de repositorios locales para superar la latencia. Pero esto no significa que usar cuatro repositorios sea algo bueno, sino que es menos malo que ejecutar dos repositorios en caso de latencia extrema.

  • La ubicación lo es todo

    Al momento de diseñar aplicaciones, es una práctica habitual estructurar la topología de manera que quede como en producción; el sitio de recuperación de desastres se convierte en un duplicado exacto. Por lo general, este modelo se denomina activo/pasivo. Si bien este modelo funciona bien en el mundo punto a punto, donde todo tiende a conmutarse por error a mismo tiempo, en el mundo SOA, los servicios están ampliamente distribuidos y deben poder conmutarse por error de manera individual. Es por eso que el modelo activo/activo es cada vez más común.

    Si bien el cluster de WebSphere MQ es infraestructura, también es, en el fondo, una aplicación SOA. Los miembros del cluster solicitan servicios de los repositorios, que a su vez ofrecen una administración de consultas y de estado en tiempo de ejecución. Si esto se abordara como una aplicación tradicional, habría dos repositorios activos en producción y dos repositorios inactivos en el sitio de recuperación de desastres. El problema que se generaría es que el sitio de recuperación de desastres debe mantener en espera el estado actual del cluster para poder ser de utilidad inmediata durante una conmutación por error. Esto se cumple especialmente cuando la conmutación por error incluye un subconjunto del entorno de producción general.

    La ejecución de un par activo de repositorios activos en producción y otro par activo en recuperación de desastres soluciona el problema de la validez, pero nos enfrentaría otra vez con el problema de la replicación. La solución para ambos problemas consiste en ejecutar un repositorio activo en producción y otro repositorio, también activo, en el sitio de recuperación de desastres.

  • Los servidores dedicados son los mejores

    Esta recomendación es la que más críticas despierta, ya que siempre propongo servidores dedicados para los repositorios, incluso en un cluster relativamente pequeño. Si tuviera que elegir, preferiría colocar los repositorios en servidores adicionales independientes de bajo costo antes que colocarlos en hardware de alta disponibilidad y de alto costo, junto a aplicaciones. Mi postura difiere bastante de la opinión predominante, por lo que considero necesario profundizar en este tema para defenderla, así que les pido que me tengan un poco de paciencia.

    En última instancia, si tuviera que colocar los repositorios en servidores junto a gestores de colas de aplicación, usaría un gestor de colas dedicado aparte. Los casos de uso, enumerados del mejor al peor, son:

    • Repositorios alojados en servidores dedicados.
    • Repositorios alojados en gestores de colas dedicados que compartan un nodo con uno o más gestores de colas de aplicación.
    • Repositorios ubicados junto a gestores de colas de aplicación.

    Se puede hacer una excepción a esta regla de servidores dedicados cuando el cluster es tan pequeño y las aplicaciones son tan tolerantes que los problemas se pueden resolver borrando el cluster y comenzando de nuevo. Si tengo entre cuatro y seis gestores de colas de aplicación de los cuales dos alojan los repositorios, por lo general mantengo un conjunto de scripts que anulan el cluster y lo vuelven a generan desde cero en cuestión de minutos. Sigue siendo necesario aplicar una interrupción de aplicación a todo el cluster, pero al menos es una interrupción pequeña. El problema es que se genera un escalado defectuoso. Si se agregan algunos gestores de colas, la capacidad de anular y volver a generar el cluster desde cero comienza a disminuir confiable y rápidamente. Como los clusters tienen tendencia a crecer con el tiempo, no considero que este enfoque sea un punto medio, sino, a lo sumo, una solución temporaria.

    El problema de ubicar repositorios junto a gestores de colas de aplicación es que se crean dependencias en diversos niveles. Una de ellas se da con las versiones de software en el host subyacente. Cuando se actualiza a una versión de WebSphere MQ, se recomienda actualizar los repositorios a la nueva versión en primer lugar. Si bien esta sugerencia no es obligatoria, el uso de repositorios de versiones anteriores en un cluster mixto puede impedir el uso de características avanzadas. En el peor de los casos, se pueden producir interrupciones en el cluster. Pero cuando el repositorio está ubicado junto a un gestor de colas de aplicación, la capacidad de actualización dependerá de los recursos de que disponga el equipo de aplicaciones para probar y certificar en la nueva versión. Esto presenta un problema incluso si existe una sola aplicación dependiente, aunque, la mayoría de las veces, hay varias aplicaciones que comparten el gestor de colas.

    Sin embargo, las actualizaciones representan la situación más favorable. El peor de los casos se da cuando surge un problema en el cluster que requiere la aplicación de un paquete o parche de corrección. Hace un tiempo, tuve un cliente que había estado varios meses con un cluster roto e interrupciones todas las noches porque no podía aplicar un paquete de corrección. La decisión de alojar repositorios en gestores de colas de aplicación, adoptada cinco años antes, parecía una buena idea en aquel momento. El impacto económico de las interrupciones hubiera compensado el costo de los servidores dedicados, las licencias y diez años de hospedaje.

    Pero las dependencias se extienden incluso a la interfaz administrativa de WebSphere MQ, y este es uno de los motivos por el que usaría un gestor de colas dedicadas si no pudiera obtener un host dedicado. El comando que se usa para reparar un repositorio es RESET y el que se usa para reparar un miembro del cluster es REFRESH. Estos comandos se excluyen mutuamente. En otras palabras, no se puede ejecutar REFRESH CLUSTER(*) REPOS(YES) en un repositorio completo. Para poder ejecutar el comando REFRESH en un repositorio, es necesario reducirlo a "no repositorio". Por lo general, es preciso ir al repositorio restante y ejecutar RESET en el antiguo repositorio. Cuando se ejecuta el comando REFRESH en el antiguo repositorio, este se "olvida" de todo lo que sabe acerca del cluster y se reincorpora como un miembro regular del cluster. Ahora sí se lo puede volver a ascender a "repositorio".

    Entre los comandos RESET y REFRESH, los restantes nodos del cluster pierden toda la información que tenían sobre el repositorio que se está reparando. Esto no constituiría un problema si el repositorio no alojara ningún objeto de la aplicación, pero como lo hace, se genera un impacto a nivel aplicación en el cluster. Asimismo, las aplicaciones locales pierden todo el conocimiento del resto del cluster durante el proceso REFRESH. Al volver a ascender el nodo a repositorio, se restituye el conocimiento de todas las colas del cluster, pero antes que eso suceda, es posible que las aplicaciones experimenten errores debido a que las colas que usan no se pueden resolver.

    También existen dependencias a nivel operativo. Los mensajes del cluster se entregan directamente desde el nodo emisor hasta el nodo receptor. En un cluster en buen estado, no existe la posibilidad de que los mensajes pasen por uno o más nodos intermedios antes de llegar a destino. Por lo tanto, el alojamiento de los repositorios en gestores de colas da lugar a una topología en que los datos de las aplicaciones y los datos del cluster nunca atraviesan los mismos canales. Según el tamaño del cluster y la naturaleza de las aplicaciones, cada uno de ellos produce un volumen de mensajes suficiente para producir un impacto negativo en el otro. El uso de gestores de colas de repositorios dedicados reduce la volatilidad atribuible a estas interacciones.

    Por supuesto que se producen muchas otras interacciones cuando las aplicaciones y el repositorio del cluster compiten por recursos limitados. Si bien el repositorio del cluster es un proceso nativo de MQ, está sujeto a limitaciones de recursos como cualquier otra aplicación. Por ejemplo, una aplicación que consume muchas conexiones de canal puede toparse con la limitación MAXCHANNELS. Privado de conexiones, no podrá publicar las actualizaciones puntualmente. Asimismo, es posible que el repositorio compita con las aplicaciones por transacciones de punto de sincronización, espacio en el registro de transacciones, MAXDEPTH de la cola de transmisión del cluster y muchos otros recursos. En todos estos casos, el cluster y las aplicaciones entran en competencia directa si están alojados en el mismo gestor de colas. Asimismo, se puede generar una contención en el nivel del servidor respecto del espacio en disco, la memoria, el CPU y otros recursos del sistema si los repositorios y los gestores de colas de aplicación comparten un servidor.

    La opinión generalizada aconseja colocar los repositorios en el hardware más confiable que esté disponible en el cluster de WebSphere MQ. Si bien es conveniente usar un servidor decente, yo siempre prefiero el aislamiento de los repositorios antes que un hardware resistente. Al momento de coordinar un paquete de corrección en diez aplicaciones diferentes, la confiabilidad del hardware es el menor de los problemas.


Recomendaciones para los miembros del cluster

  • Definición explícita de un solo CLUSSDR

    Si bien existen dos repositorios en el cluster, no es necesario definir explícitamente canales remitentes de cluster para ambos para lograr una unión con el cluster. Cuando se define el primer canal CLUSSDR y el gestor de colas se une al cluster exitosamente, este recibirá información sobre el otro repositorio y generará canales para comunicarse con él. Por ello no resulta necesaria una segunda definición de CLUSSDR.

    Si el segundo canal CLUSSDR no es necesario, ¿su definición generaría algún impacto negativo? La respuesta es afirmativa.

    Los miembros del cluster siempre publican los cambos en dos repositorios, pero ¿en cuáles? Esto dependerá en parte de los canales CLUSSDR que se hubieran definido. Como un CLUSSDR definido explícitamente tiene una mayor ponderación, las publicaciones siempre los preferirán a ellos antes que a los canales autodefinidos. Si existen dos canales CLUSSDR definidos explícitamente, las publicaciones siempre usarán los dos canales, independientemente de la disponibilidad de los gestores de colas en el otro extremo del canal y de la disponibilidad de cualquier destino alternativo.

    En el transcurso normal de las operaciones, esto no sería necesariamente negativo. Pero si se debe alojar un nuevo repositorio, ya sea de manera temporaria o como una migración permanente, el hecho de tener dos canales CLUSSDR explícitamente definidos le traerá muchos inconvenientes. La única manera de lograr que el miembro del cluster perciba el nuevo repositorio es eliminar una de las definiciones explícitas de CLUSSDR; este paso puede ir acompañado por un comando REFRESH CLUSTER(nombre de cluster) REPOS(YES).

    El uso de más de dos canales CLUSSDR explícitamente definidos es aún peor. En ese caso, es imposible saber cuál de los dos canales será publicado; además, si ambos repositorios están desconectados, las publicaciones del miembro del cluster quedarán varadas en la cola de transmisión del cluster.

    El método más confiable es usar un solo CLUSSDR explícitamente definido. De esta manera, el gestor de colas podrá buscar el segundo repositorio usando algoritmos de gestión de carga de trabajo normales. Por ejemplo, es posible poner en conexión un tercer repositorio y luego suspender uno de los repositorios principales antes de realizar el mantenimiento. Los miembros del cluster publicarían una vez en el repositorio indicado por el CLUSSDR explícito —sin importar si está conectado o no— y una vez en uno de los otros dos repositorios, en función de su disponibilidad.


Recomendaciones para todos los nodos

  • Nombres de CLUSRCVR únicos para cada cluster

    En los ejemplos de los manuales técnicos que ilustran la agrupación en clusters, se usan nombres de canal como TO.<Nombre de gestor de colas>. Por ejemplo, un gestor de colas llamado QM1 generaría un canal receptor de cluster TO.QM1, y los restantes miembros del cluster usarían ese canal para conectarse con él. Sin embargo, esta convención de nombres da lugar a que se reutilice el mismo canal con clusters superpuestos, lo cual puede ocasionar problemas.

    Para entender por qué esto puede ser un inconveniente, en primer lugar es necesario entender para qué se usa un cluster superpuesto. Existen diversos motivos, pero lo que todos ellos tienen en común es que proporcionan granularidad de gestión de algún aspecto del cluster. Pero el CLUSRCVR está inseparablemente unido con las operaciones de gestión del cluster. Si se ejecuta el comando REFRESH en el cluster, es necesario detener el CLUSRCVR para todos los clusters en los que participa. Como esta convención de nombres facilita la reutilización de canales de cluster en clusters superpuestos, queda sin efecto la funcionalidad que el cluster superpuesto pretende proporcionar.

    La convención de nombres que procuro usar es <Nombre de cluster>.<Nombre de gestor de colas > ya que fuerza canales que son únicos para cada cluster. Con esta convención de nombres, es posible realizar el mantenimiento en un cluster sin afectar a los otros clusters en los que participa el gestor de colas.

  • MCAUSER que restringe el acceso administrativo

    Cualquier canal entrante con un valor MCAUSER en blanco permite que todo aquello que se conecte pueda administrar el gestor de colas locales. En caso de un canal CLUSRCVR, un MCAUSER en blanco implica que cualquier otro gestor de colas del cluster puede administrar el gestor de colas locales. Sin embargo, este no suele ser el comportamiento deseado, ya que, por lo general, un administrador legítimo se conectará directamente o administrará el gestor de colas desde la línea de comandos del host subyacente.

    Establecer el MCAUSER del canal CLUSRCVR para una cuenta de servicio lo forzará a usar los privilegios de esa cuenta. Es posible usar setmqaut para especificar en qué cuentas el canal puede colocar mensajes. Una configuración simple permitirá el acceso a todas las colas, con excepción de SYSTEM.ADMIN.COMMAND.QUEUE, así como a cualquier cola de iniciación o de transmisión y a la mayoría de las colas SYSTEM.*. Una opción más segura consiste en denegar el acceso a todas las colas, exceptuando aquellas respecto de las que se concedió acceso expresamente, y luego limitar estas últimas a un puñado de destinos autorizados.

    En todos los casos, se requiere que el canal pueda colocar mensajes en SYSTEM.CLUSTER.COMMAND.QUEUE para que el gestor de colas forme parte del cluster.

    Por supuesto que, para que todo esto surta efecto, sería necesario que todos los canales entrantes estén asegurados contra intrusiones administrativas. Por "canal entrante" hago referencia a todos los canales RCVR, RQSTR, CLUSRCVR o SVRCONN, incluidos los llamados SYSTEM.DEF.* y SYSTEM.AUTO.*, aun en gestores de colas donde la autodefinición de canales se encuentre desactivada.


Resumen

La agrupación en clusters abarca mucho más de lo que se analizó en este artículo, pero estos temas son, en mi opinión, los más importantes. La mayoría de las recomendaciones incluidas implican cambios en las directivas o en los procesos. La única recomendación que requiere una inversión es la de alojar repositorios en servidores dedicados, y ese punto es el que más me cuestionan, especialmente cuando el cluster consiste en unos pocos nodos.

La pregunta más frecuente es: "¿No puedo esperar a que el cluster sea más grande y luego comprar los nuevos nodos?" Por supuesto que sí. Sin embargo, si es posible implementar la topología de destino inmediatamente —cuando el cluster es pequeño—, se generarán numerosos beneficios; por ejemplo, nunca tendrá que decidir qué criterios se deben usar a fin de determinar el momento adecuado para actualizar. Salvo que se genere algún impacto, cualquier decisión será algo arbitraria. La mayoría de las veces, la decisión queda pospuesta hasta que surja algún problema, y, en ese caso, el cambio deja de ser opcional. Cuando escucho esa pregunta, mi mente la traduce así: "¿Puedo aplazar este cambio hasta que exista un impacto garantizado?".

No es posible garantizar la inexistencia de problemas en el cluster; sin embargo, si usted adopta estas recomendaciones, estoy convencido de que tendrá menos problemas de los que tendría si no lo hace y de que los problemas que puedan surgir serán más fáciles de resolver.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere
ArticleID=462480
ArticleTitle=Misión Mensajería: Diseño y funcionamiento de los clusters de WebSphere MQ
publish-date=01192010