Cada entreda delas Innovaciones a su alcance brindan una nueva información y debates sobre nuevos los tópicos relacionados con las nuevas technologías emergentes, tanto desde el punto de vista del desarrollador como así también desde el punto de vista del profesional, además de las miradas "detrás de la escena" a los productos de avanzada de IBM® WebSphere® .

Fundamentar las palabras de moda

Algo que sucede mucho en la industria del sofware empresarialel uso de las palabras de moda. A veces es abrumador, las palabras de moda son necesarias a fin de ampliar el vocabulario que utilizamos para describir las soluciones y las herramientas disponibles a fin de resolver una constante evolución del conjunto de los problemas empresariales. Sin esta expansión, muchos de los conceptos lucharían para dejar sus origenes. Un concepto por el cual hemos estado tratando de luchar es por el del significado específico del término elástico para describir una solución empresarial.

Es fácil caer en la trampa de usar la idea de elasticidad para hacer hincapié en el objetivo fijado para una solución dada. En su versión más simple, una solución podría ser elástica simplemente permitiendo que más recursos se agreguen o se quiten sin desconectar el sistema. En aras de crear un sistema mejor y más útil, me gustaría proponer un objetivo más ambicioso de una definición específica.

Elasticidad en un sistema o componente de un sistema (Utilizaré un sofware como ejemplo, ya que yo trabajo con IBM WebSphere eXtreme Scale todos los días) implica tres grados específicos de libertad:

• Escalar sin un límite razonable
• Tolerancia al error y auto-corrección
• Simplicidad administrativa.

Ahora, antes de etiquetar estos conceptos como palabras de moda o vacías de concepto, permítanme fundamentar estas ideas.

Escalar sin límites razonables

No debemos esperar una gran controversia con respecto a la idea de que un sistema elástico puede ser escalado hacia arriba y hacia abajo sin ningún efecto significativo sobre la disponibilidad del sistemea durante estas operaciones. Sin embargo, creo que también se debe esperar que el sistema no imponga ninguna restricción real en un escenario mejorado razonable. Con esto quiero decir que la infraestructua en sí misma debería ser diseñada para permitir el crecimiento contínuo del sistema y permitir que los nuevos recursos estén disponibles con poco o nada de sobrecarga. Esto implica la posibilidad del escalamiento lineal verdadero.

Hemos abordado el concepto de elasticidad sin WebSphere eXtreme Scale considerando los efectos de las redes extremadamente grandes en cada aspecto del producto. Unos pocos ejemplos pueden ilustrar esto muy bien:

• En primer lugar el diseño de la infraestructura de los miembros de la red en sí misma está en los componentes solubles más pequeños y que contienen los problemas de escala. En lugar de disputarse miles de servidores en un único grupo central, el servicio de catálogo (un proceso administativo que se ocupa de la estructura de la red) divide a los miembros en grupos de 20. Luego cada uno de estos grupos de personas ejecuta un algoritmo de la vista de membresía que involucra el pulso, el que tiene un registro de las pistas comprobado y comparte la función con IBM WebSphere Application Server. Un líder elegido de este grupo más pequeño mantiene el catálogo de sevicio al día con respecto a la situación del grupo, que sólo necesita permanecer en contacto con el 1/20 del total de los miembros de la red.
• Otro ejemplo es la interacción del cliente con la red misma. Una pregunta que surge a menudo es el posible cuello de botella que un único proceso administrativo ocasiona, por ejemplo el servicio de catálgo. Los servicios de catálogos pueden ser duplicados y agrupados, pero esto es redundante. Lo cierto es que un servicio de catalogo único puede manejar las necesidades de una cantidad casi ilimitada de clientes porque esos clientes interactúan con el servico de catálogo solamente para iniciarse en la red. En esa interacción el catálogo de servicio devuelve la información de la red incluyendo un mapa de ruta completo definiendo el lugar de toda las particiones de la red y el espacio asociado clave para cada una de ellas. Después de esto, los clientes interactúan directamente con las particiones e incluso guardan esta tabla de ruta actualizada a través de subcanales de interacción durante el proceso de transacción normal. Por lo tanto, el servicio de catálogo es libre de centrar solamente su atención en administrar el equilibrio y la membresía de la red a medida que se añaden o se quitan los recursos.

Con planteos como estos, hemos sido capaces de escalar en forma eficiente una red a un tamaño arbitrariamente grande. En el laboratorio, hemos logrado una red de 1.500 contenedores sin ninguna diferencia real percibida en la performance. Después de eso, nos quedamos sin tiempo para ir más lejos, pero no existe ninguna limitación específica o razonable a este escalamiento. Éste es un factor realmente importante a tener en cuenta para que una solución sea elástica.

Es importante saber que esto no emplica que CADA despliegue de una infraestructura elástica proporcionará la aplicación total con un escalamiento lineal a medida que se agreguen los recursos. Todavía existen algunas consideraciones relacionadas con la lógica y la empresa que se llevan a cabo dentro de la infraestructura, y si se emplean o no los fundamentos extremos del procesamiento de las transacciones. En este aspecto, la aplicación de la empresa deberá tener características elásticas. Sin embargo, una infraestructua elástica debe prever el sondeo para alcanzar estos objetivos en forma efectiva.

La tolerancia al error y auto corrección

Si usted espera confiar en un desplegador para que sus soluciones escalen en forma indefinida, también deberá tolerar los eventos que suceden con mayor probabilidad y frecuencia a medida que el sistema crece, tales como el agregado o la pérdida de los nodos debido al mantenimiento o a las fallas, las fallas y los cambios en la red, y así sucesivamente. Con más cantidad de recursos aparecen mayores posibilidades de fracasar, y un sistema elástico deberá ser capaz de superar estas fallas de una manera predecible y eficiente, mientras regresa a un estado de tolerancia a las fallas, si fuera posible.

Continuando con nuestro ejemplo de la red de datos de WebSphere eXtreme Scale, a medida que usted crece a redes de cientos o miles de procesos de soporte, la pérdida o el mantenimiento de esos procedimientos es más y más probable. A través de la repetición -- que es una competencia básica de WebSphere eXtreme Scale y de los ofrecimientos de la red de datos en la memoria -- estos eventos pueden ser tolerados. No sólo eso, sino que dado que la ubicación y la migración de los datos es completamente transparente detrás de la "caja negra" de las APIs de los clientes de WebSphere eXtreme Scale, una nueva réplica se crea en forma automática y se logra nuevamente la tolerancia a las fallas.

La elasticidad necesita tener presente este apéndice conceptual para poder ser realmente útil a medida que el despliegue crece y se hace más complejo.

La simplicidad administrativa

Las necesidades especializadas con respecto a la administración y el mantenimiento de un sistema pueden ser sutiles si se tiene en cuenta el significado de una infraestructura elástica. Sin embargo, al igual que con la necesidad de la tolerancia a las fallas, a medida que el sisema crece y se hace más complejo, usted también deberá tener en cuenta la capacidad del desplegador de realizar las tareas administrativas comunes.

El concepto clave aquí es que la configuración y el mantenimiento de cada nodo deberá ser idéntico o mínimamente diferente. Usted no debe esperar que el desplegador le proporcione una lista de todas las máquinas o los procesos de los miembros para que el sistema funcione. Debería haber algún nivel de detección automática y de administración que se base en un conjunto común de dispositivos de configuración.

En el caso de WebSphere eXtreme Scale, el enfoque es bastante sencillo. La información de la configuración se centra en la estructura y en las características de la red misma, no en cualquier detalle de los procesos específicos de los miembros. Por ejemplo usted configura en cuántas particiones puede dividir los datos, y cómo esas particiones deberán ser duplicadas. Con esta información WebSphere eXtreme Scale correlaciona eso con los miembros de la red disponibles y hace cumplir las políticas establecidas en la configuración. El conjunto exacto de dispositivos de la misma configuración es proporcional a cada miembro de la red cuando se inicia y los detalles del lugar de ese miembro en el mundo de las redes son administrados y determinaados en forma automática.

Esta filosofía se lleva a cabo a lo largo de la administración y el espectro de mantenimiento, con cada interacción diseñada para separar los detalles de la red física de la estructura lógica de los modelos de la red.

Podemos encontrar muchos ejemplos más, como la separación de la ubicación de la réplica a través del uso de la abstracción de las zonas, o de la posibilidad de actualizar el nivel del código de la red actual sin desconectar la red. El concepto clave es que las tareas administrativas deben tener una complejidad constante a medida que el sistema escala hacia el exterior o al menos, lo constante posible. A partir de esto usted podrá ver qué bien el software y el hardware elásticos (es decir, la virtualización y el despliegue en nube) pueden complementarse para proporcionar un nuevo nivel de libertad a las soluciones empresariales.

Volver arriba

Elogio a las palabras de moda

Es muy casi seguro decir que incluso nuestras tecnologías de base más dominantes en la computación comenzaron como una especie de palabra de moda. Nosotros simplemente necesitamos definir el significado y darle un propósito útil cuando se añade un nuevo concepto u objetivo a nuestro vocabulario. De esta manera creo que queda claro que la elasticidad en las soluciones empresariales puede ser un concepto útil cuando es claramente definido y pensado hasta llegar a una conclusión lógica. Siempre hemos tratado en forma consistente de relacionar el sentido concreto y útil cuando hablamos de WebSphere eXtreme Scale como una red de datos elásticos, y nos esforzaremos por seguir haciéndolo a medida que se apliquen estos conceptos a otras soluciones que están diseñadas para crear infraestructuras verdaderamente flexibles.

Recursos

Aprender

• Transformación del producto WebSphere eXtreme Scale
  
  
• WebSphere eXtreme Scale Information Center
  
  
• IBM developerWorks WebSphere
  
  

Obtener los productos y tecnologías

• Descarga de la prueba de IBM developerWorks WebSphere eXtreme Scale
  
  

Comentar

• WebSphere eXtreme Scale XTP Development Community
  
  

Sobre el autor

Califique este artículo

Comentario

Volver arriba

Tabla de contenidos

• Fundamentar las palabras de moda
• Elogio a las palabras de moda
• Recursos
• Sobre el autor
• Comentarios