Buscador

Arquitectura de Componentes - II

Servicio de datos 
El servicio de datos contiene bases de datos de soporte como almacenes persistentes y seguimiento para el tiempo de ejecución del flujo de trabajo. En esta arquitectura, también es probable que exista un almacén que contenga resultados o agregados a resultados. Es posible que los archivos de entrada y salida de datos se traten como archivos para mover de un modo más fácil los clústeres hacia los nodos de proceso respectivos. Finalmente, hay una base de datos que contiene un catálogo de los flujos de trabajo disponibles para su ejecución. 

Servicio de cómputos 
El servicio de cómputos es el “más simple” de la arquitectura y está compuesto de un clúster de x nodos en una configuración determinada. 

Comunicación 
La comunicación en todo el proceso de arquitectura se gestiona utilizando Windows Communication Foundation mediante un TCP (conexión remota) o un canal HTTP. Esto mantiene a la arquitectura escalable y desacoplada y ofrece beneficios para las interfaces de usuario diferentes, según requisitos del usuario (autoría, ejecución, emisión de informes).

Seguridad 
En una estructura distribuida orientada al servicio, que potencialmente pasa por varios dominios de seguridad, es fundamental la federación de identidades para permitir el control de acceso a nivel del usuario y el inicio de sesión único para todos los aspectos de la arquitectura de componentes. Las tecnologías que ofrecen estas capacidades son aquellas que están basadas en certificados, federación de directorio activo (junto con extensiones para integrarse con los sistemas Unix) y Windows CardSpace de Microsoft.

Arquitectura de Componentes - I

La arquitectura principal se parece a la conocida arquitectura de aplicación de n-capas y, en líneas generales, éste es de hecho el caso. La organización de la funcionalidad es bastante lógica. La Figura 1 muestra los componentes necesarios para la arquitectura. 
Interfaz de usuario 
La experiencia de la interfaz de usuario puede dividirse en tres partes. Cada una desempeña una función diferente de la solución general: 
• La experiencia de usuario principal para planificar y ejecutar un procesamiento puede proporcionarse mediante varias tecnologías. Algunos ejemplos podrían ser Windows Forms, Windows Presentation Foundation, ASP.NET o Microsoft Office SharePoint Server. La elección de la tecnología debe ser apropiada para las características de un entorno particular (por ejemplo, el uso de tecnologías de Web en las que se requiere amplia disponibilidad o WPF en el que se necesita una interacción muy variada). 
• La experiencia de autoría del flujo de trabajo es proporcionada por Visual Studio 2005 que utiliza la superficie de diseño de autoría del Windows Workflow Foundation (WF). El uso del modelo “code beside” (código al lado) de los flujos de trabajo en desarrollo permite utilizar una nueva interfaz API de Control de Código Fuente para enviar archivos “XAML” de WF hacia un depósito de bases de datos central, por ejemplo, para ejecutar en la interfaz de usuario. 
• Para los administradores informáticos, el Microsoft Operations Manager puede utilizarse para controlar el buen funcionamiento y el estado del clúster de HPC, si bien para los usuarios finales de un sistema HPC, se pueden poner a disposición observaciones más comprensibles para el usuario mediante el uso de Windows PowerShell. 
 Capa de aplicación 
La capa de aplicación está compuesta por el tiempo de ejecución del WF alojado como un servicio NT. Esta capa se utiliza principalmente para comunicarse con el programador de tareas del clúster, pero ofrece una variedad de funciones: 
• Biblioteca de flujos de trabajo y actividades para controlar el clúster y realizar movimientos de datos y otros pasos pre y post procesamiento. 
• Motor de reglas y políticas para administrar el acceso a un clúster y, potencialmente, proporcionar prioridades y capacidades de “metaprogramación” y seguridad. 
• Información de seguimiento para la ejecución de trabajos brindando información documentada, según sea necesario. 
• Información de persistencia que permita escalar la solución y proporcionar eficacia a los flujos de trabajo de larga duración y, potencialmente, la capacidad de volver a ejecutar un flujo de trabajo desde un estado en particular

Bibliotecas de actividades

Las bibliotecas de actividades son los bloques de construcción necesarios para la solución del HPC. Algunos ejemplos son los siguientes: 
• Comunicación del clúster. Es posible crear una actividad personalizada que utilice la interfaz de programación de la aplicación CCS para comunicarse con el programador de tareas y crear o cancelar trabajos en el clúster. Esta actividad personalizada puede entonces ser utilizada por cualquier flujo de trabajo que necesite comunicarse con el programador de tareas y proporcionar un nivel más alto de abstracción para los “usuarios avanzados” quienes pueden necesitar crear nuevos flujos de trabajo o corregir los existentes sin conocimiento detallado de programación

Lógica de aplicación con Windows Workflow Foundation

Ya que podemos considerar que el proceso informático total es una instancia de un flujo de trabajo de máquinas y personas de larga duración, podemos considerar a Windows Workflow Foundation (WF) como el punto de inicio para la construcción de una estructura y capa de aplicación de la solución de HPC. En realidad, HPC posee varios componentes que se pueden utilizar para proporcionar una capa de aplicación completa para la solución de HPC. Las áreas particulares (pero no exhaustivas) que puede cubrir el WF se muestran en la Figura 6. WF forma una parte fundamental del marco de trabajo .NET 3.0 y ofrece un motor de flujo de trabajo completo que se puede alojar en varios entornos. La sección de recursos de este artículo contiene varios vínculos para obtener más información sobre el Windows Workflow Foundation. Algunas de las características principales del WF para considerar son las siguientes: 
• Flujos de trabajo de estado y en secuencia: El tiempo de ejecución del WF puede administrar flujos de trabajo orientados al estado y secuenciales, por lo tanto, se pueden describir una gran variedad de procesos. Estos flujos de trabajo también pueden gestionar excepciones y reintentos. 
• Bibliotecas de actividades: Los flujos de trabajo están compuestos de “actividades” como toma de decisiones, ejecución de bucles y ejecuciones en paralelo, así como también, actividades de “código” arbitrario y varias de estas actividades están listas para usar en el .NET 3.0. Además, debido a que el WF se utiliza para productos de servidor muy eficaces (por ejemplo, Microsoft Office SharePoint Server 2007), estos productos poseen actividades básicas para utilizar dentro del WF. Finalmente, las actividades se pueden construir en la medida que sean necesarias para crear una biblioteca individualizada y cumplir con un requisito específico. 
• Motor de reglas: WF posee un variado motor de reglas de encadenamiento progresivo que se puede utilizar para la toma de decisiones dentro de un flujo de trabajo, pero también se puede ejecutar fuera de las instancias del flujo de trabajo. Las actividades se diseñan para que funcionen con este motor de reglas. 
• Diseñador y realojamiento: WF también posee una superficie de diseño completa de “arrastrar y soltar” que se utiliza dentro de Visual Studio 2005 pero también puede ser realojada dentro de, por ejemplo, una aplicación de formularios de Windows. 
• Servicios en tiempo de ejecución: El tiempo de ejecución del WF puede contar con servicios que han sido incluidos antes de la ejecución del flujo de trabajo para interceptar la ejecución de un flujo de trabajo y desempeñar acciones como persistencia o seguimiento. Los servicios también se pueden construir en la medida que sean necesarios. 
• Lenguaje de Marcado de Aplicaciones Extensible (XAML): Por último, WF utiliza en gran medida el XAML para describir flujos de trabajo y conjuntos de reglas, lo que significa que la serialización es trivial y que realmente es posible la generación de administradores de reglas y superficies de diseño individualizadas. Dadas estas características, podemos ahora ver el modo en el que WF ofrece capacidad a la arquitectura.

Workflow Foundation

Workflow Foundation puede brindar una capa de aplicación completa que abarque la mayoría de las áreas en los pasos de Solicitud, Proceso y Análisis.

Una cadena de valor mejorada

Proporcionar una solución basada en HPC utilizando una arquitectura similar a la descripta puede tener varios beneficios para la cadena de valor total. (Figura 2) Existen varias áreas que podrían estar afectadas inicialmente: 
• Planificación para un trabajo de larga ejecución. Las reducciones de tiempo y gastos son posibles mediante el uso de interfaces intuitivas, validación y otra lógica para garantizar la captura de información adecuada. Además, los administradores o codificadores especializados pueden ya no ser necesarios en esta instancia del proceso. 
• Publicar un trabajo de larga ejecución. Tanto el tiempo como los gastos se pueden reducir debido a que la información es capturada por el sistema y, por lo tanto, la publicación del trabajo puede automatizarse completamente 
• Costo de la informática. El costo se reduce mediante la especialización de las funciones – el monitoreo puede ocurrir desde la perspectiva de un usuario final– y el costo total entre varios trabajos puede reducirse mediante el reconocimiento mejorado de trabajos erróneos o fallas que pueden cancelarse antes de haber finalizado la ejecución. Este reconocimiento mejorado es nuevamente proporcionado por el uso del monitoreo y mecanismos de feedback que se presentan a la interfaz del usuario. 
• Análisis. El análisis se puede iniciar de un modo más rápido si la interfaz del usuario presenta información durante la ejecución del trabajo; puede estar disponible algún análisis automático que reduce los costos iniciales antes de que se necesite intervención especializada.
• Análisis paramétrico: Este tipo de trabajo podría ejecutar varias instancias de un único programa pero con una serie de parámetros diferentes, permitiendo varios resultados en el mismo período de tiempo como una tarea única.
• Tarea de interfaz de paso de mensajes: El trabajo más sofisticado sería el uso de una Interfaz de Paso de Mensajes (MPI) para paralelizar un algoritmo y dividir el trabajo del procesamiento entre varios procesadores que se coordinan para proporcionar aumentos de velocidad en procesamientos complejos y largos. Varios o todos estos tipos de trabajo se pueden encontrar dentro de un único proceso de informática. CCS debe poder ofrecer una plataforma sólida para cualquiera de las tareas de pre- o postprocesamiento así como también la tarea principal de procesamiento.

Consideración de la cadena de valor

Por lo general, los usuarios de soluciones de informática de alta productividad son altamente cualificados y son recursos muy preciados para los equipos de investigación y desarrollo. Sus habilidades y experiencia profesional son necesarias para brindar aportes en los procesos, algoritmos para los cálculos y el análisis del producto resultante. Sin embargo, se debe permitir que estos recursos trabajen lo más eficaz y eficientemente posible. La creación de soluciones poco claras, de un modo u otro, afectarían esto de varios modos posibles: 
• Es posible que el usuario deba tener cierto conocimiento del sistema que va más allá de lo que habitualmente se esperaría. Por ejemplo, necesito saber los principios básicos de un control remoto para poder operar mi televisor, pero para mirar televisión, no necesito saber el voltaje requerido para activar su pantalla de LCD. 
• Los expertos que han participado de una solución individual pueden encontrar difícil liberarse de eso. Por ejemplo, si Alicia ha codificado un algoritmo para la solución, puede encontrar que está muy involucrada en la operación diaria de la solución porque sólo ella comprende el mejor modo de interactuar con el sistema para utilizar el algoritmo. Ella debería realmente dedicarse a crear algoritmos aún mejores. El resultado después de una o dos creaciones de mejoras no sólo representa un alto costo en la operación de la solución, sino también un problema de riesgo ya que Alicia se ha vuelto un componente fundamental de la solución. 
• La solución también puede ser un problema en lo que respecta a la administración para los equipos fundamentales de informática. Una solución de HPC creada con gran destreza por expertos en dominio podría fácilmente ser análoga para las “soluciones de hojas de cálculo vinculadas” del equipo de ventas que puede ser problemático para cualquier desarrollo interno o para los equipos de soporte. El diagrama de la Figura 1 representa el proceso de alto nivel para la provisión y uso de una solución de HPC. La compresión de la cadena de valor en lo que respecta a tiempo y costo debe ser la inquietud principal para la provisión de la solución. 
Dados los problemas detallados con mejoras en la velocidad para el trabajo informático, las mejoras deben identificarse fuera de este ámbito y en otras áreas del proceso. Candidatos ideales para la reducción del costo en el proceso son, ampliamente, todos los aspectos de la cadena de valor con la probable excepción de la creación del algoritmo, que es la invención y propiedad intelectual de la solución. La reducción de costos se divide en dos partes: el costo para utilizar la solución y el costo de administración. Mejorar el proceso para la publicación y uso de algoritmos, y brindar soporte analítico podría reducir el costo total del proceso. A partir de la consideración de la cadena de valor, un conjunto de soluciones debe estar compuesto de herramientas que proporcionen dos características fundamentales: simplificar la finalización de la tarea y oportunidades para la interacción mejorada.

Informática de alto rendimiento con la edición de Microsoft "Compute Cluster Server”

El servicio fundamental necesario para la solución es la capacidad de los clústeres de la Informática de Alto Rendimiento en sí. La edición de Microsoft “Compute Cluster Server” (CCS) ofrece capacidades de clústeres para cumplir con el paso “Proceso” del escenario del problema. (Ver Figura 5) CCS brinda capacidades de clústeres para una versión reducida de Windows Server 2003 que permiten, por ejemplo, el uso de procesamientos paralelizados, aprovechando varios procesadores para completar procesamientos particularmente complejos o intensivos como aquellos que se basan en estadísticas generales. El control de un clúster de CCS es realizado por un “nodo principal” que se comunica con los nodos del clúster para impartir instrucciones y coordinar una serie de tareas sobre un trabajo específico. Los nodos del clúster pueden estar en una red privada, para un desempeño óptimo, y probablemente sea una red de tiempo de espera mínimo para asegurar que el tiempo de espera de red no tenga un impacto sobre el tiempo del procesamiento. 
La sección de recursos al final de este documento contiene vínculos hacia artículos técnicos sobre la configuración e implementación del CCS. El nodo principal posee un “programador de tareas” que permite la inserción de una tarea de procesamiento dentro de una cola para que se ejecute cuando la cantidad necesaria o deseada de procesadores están disponibles para completar la tarea. Se proporciona una base de datos pequeña al nodo principal para mantener un seguimiento de la cola de tareas en curso. Se puede acceder al programador de tareas mediante una interfaz en el nodo principal, vía línea de comando, que se puede parametrizar o ejecutar con una definición de XML de los parámetros, o vía API (CCS API) para interacción programática. 
Un clúster CCS puede controlar diferentes tipos de trabajos como los que se detallan a continuación: 
• Trabajo en serie: Ésta es una tarea de procesamiento habitual que simplemente ejecuta un programa necesario. 
• Flujo de tareas: Varios trabajos en serie compuestos de múltiples tareas/programas en potencia.

Escenario de la solución

Después de haber detallado varios escenarios generales que pueden representar los requisitos para una solución de HPC y considerando el valor descripto al comienzo en la construcción de una solución de HPC, podemos ahora considerar algunos escenarios de la solución para cumplir con estos requisitos.

Escenario de administración.

Finalmente, se necesita la administración de la plataforma de HPC. En este caso, consideramos que las tareas principales para respaldar al usuario final comprenden el monitoreo y la contabilidad y excluyen otras tareas de administración básicas como configuración del clúster y otras actividades generales de infraestructura informática. (Ver Figura 4) El escenario de administración se puede describir de la siguiente manera: 
Publicación: 
• Monitoreo: Por lo general, los clústeres son recursos compartidos administrados por personal especializado. Ellos deben controlar que las instalaciones proporcionen funcionalidad y rendimiento, por ejemplo, analizar las colas de trabajo y las tendencias de consumo de recursos. 
• Cuenta: Es recomendable justificar el uso de la utilización de recursos por parte de ciertas cuentas. Esto ayuda cuando los clústeres son financiados y utilizados por varios grupos. 
• Facturación: Es posible crear modelos de cargo al usuario para facturar su uso de un modo explícito.

Escenario de autoría:

El escenario de autoría trata los aspectos del proceso total para proporcionar capacidades para que un usuario final complete un trabajo de cálculos. En términos generales, el autor de un proceso debe poder desarrollar nuevas capacidades y procesos y publicarlos para el consumo de los usuarios finales. La Figura 3 muestra el escenario de autoría para dos participantes: autores y usuarios avanzados. La diferencia entre estas funciones es que un autor probablemente desarrolle código, mientras que un usuario avanzado posiblemente configure el código existente. El escenario de autoría puede describirse de la siguiente manera: 
Desarrollo: 
• Actividades: Un desarrollador puede querer construir actividades o elementos del proceso diferenciados que puedan utilizarse como parte del proceso total de una tarea de informática. Un ejemplo podría ser una actividad genérica para llevar a cabo un FTP del conjunto de resultados.
• Algoritmos: El desarrollador puede crear los algoritmos reales para que se utilicen en el paso de cálculos del proceso del usuario final. 
 • Flujo de trabajo: Un desarrollador de usuarios avanzados puede definir flujos de trabajo de cálculos específicos mediante la unión de actividades y algoritmos para crear un paso de cómputos total compuesto de pre y post procesamientos así como también de la tarea de cómputos en sí. 
Publicación: 
• Catálogo: Después del desarrollo de actividades, algoritmos y flujos de trabajo, el autor deseará realizar un catálogo del desarrollo para que lo utilicen otros autores o usuarios finales. 
• Configuración: Es posible que se requiera la configuración de algunas actividades o flujos de trabajo, como restricción de acceso u otras normas que regulen el uso de la tarea desarrollada. 
• Publicación: Por último, el autor debe presentar la tarea desarrollada cuando esté lista para utilizar. Lo ideal sería que esto no requiera ningún esfuerzo de administración informática.

Escenario de informática.

El proceso informático se divide en cuatro pasos fundamentales para un usuario típico que aseguran la finalización de la tarea: acceso, solicitud, proceso y análisis. (Ver Figura 2) 
Acceso: 
• Inicio de sesión: El usuario debe poder iniciar la sesión de la solución y deberá identificarse como usuario válido. Es posible que entonces puedan ver sólo la información relevante a su función y/o grupo. 
• Inicialización: Antes de realizar una solicitud del trabajo, puede existir la necesidad de configurar un panel de control para ejecutar la tarea. Dada la naturaleza de la informática de larga ejecución, una ejecución del proceso puede considerarse un “proyecto”. 
Solicitud
• Carga: Un usuario debe poder cargar o acceder a grupos de datos que están previstos para ser utilizados como parte de un trabajo. Los grupos de datos pueden ser grandes, no homogéneos o de origen externo, por lo tanto, se necesita un paso específico en el flujo de trabajo para obtener estos datos y dividirlos entre el nodo del clúster de manera que equilibre la cantidad prevista de trabajo. 
• Inserción de datos: un usuario debe poder añadir parámetros y metadatos asociados para garantizar que el trabajo se ejecute exitosamente. Estos parámetros se capturan para reutilización y auditoría. 
• Aprobación: después de añadir parámetros y cualquier otra información requerida, es probable que se pida aprobación antes de presentar el trabajo. Entonces, probablemente se producirá algún tipo de flujo de trabajo de aprobación, seguido de una presentación del trabajo del usuario. 
Proceso 
• Preproceso: El paso de preproceso para un trabajo puede realizar diversas cosas. Probablemente traslade los grupos de datos a los nodos del clúster y tal vez realice un grupo de procesamientos iniciales, como la generación de medidas analíticas para ser utilizadas en el procesamiento principal. También puede inicializar estructuras de datos y evaluar todos los datos para su validación antes de ejecutarlos. 
• Proceso: Esta fase representa el procesamiento paralelo en sí. Cada nodo ejecutará una porción y puede ser necesario pasar resultados intermedios a otros nodos para que se complete el proceso total (trabajo de paso de mensajes). Otra opción es que los datos pueden ser propicios para ser computados dentro de porciones totalmente aisladas, como situaciones “que pasaría si” o un análisis paramétrico. Esta fase puede ocurrir durante un tiempo potencialmente significativo. Lo ideal sería que se proporcione algún comentario al usuario final durante este tiempo. 
• Post-proceso: El paso final en el procesamiento en sí es similar al del preprocesamiento en el sentido de que es posible que se complete algún trabajo con los datos obtenidos. Esto puede comprender movimientos de datos hacia almacenes, agregación de datos de nodos separados, operaciones de depurado, tareas de visualización, etc. 
Análisis: 
• Automático: Si bien es probable que los resultados de la tarea necesiten intervención especializada para comprenderlos verdaderamente, es posible realizar un análisis automático, en particular, en el caso de un análisis estadístico en el que los patrones son importantes y fáciles de automatizar. 
• Con conexión: El usuario debe poder realizar un análisis básico sin tener que solicitar todo el grupo de datos. Esto puede presentarse como herramientas con paradigmas de inteligencia comercial – segmentación y separación, etc. 
• Descarga: Por último, el usuario debe poder recuperar los grupos de resultados para la manipulación avanzada sin conexión, según sea necesario.

Ciencia ambiental de alta productividad integral

El proyecto de modelo del sistema Grid-ENabled Integrated Earth (GENIE) proporciona una estructura accesible por red que facilita la integración, ejecución y administración de los modelos componentes para el estudio del sistema terrestre sobre escalas de tiempo milenarias. Los simulacros basados en la estructura GENIE deben seguir procedimientos de operaciones complicados entre diferentes modelos y recursos informáticos heterogéneos. 
El proyecto GENIE ha desarrollado una estructura para la composición, ejecución y administración de modelos integrados del sistema terrestre. Los códigos componentes (océano, atmósfera, superficie terrestre, hielo marino, capas de hielo, biogeoquímica, y demás) de complejidad y resolución variada pueden unirse de un modo flexible para formar una serie de modelos del clima, eficaces, que sean capaces de simular sobre escalas de tiempo milenarias. El proyecto reúne un grupo distribuido de científicos del medio ambiente con un interés en común por el desarrollo y uso de los modelos GENIE para comprender el sistema terrestre. Los simulacros del sistema terrestre comprenden muchos datos así como también mucha informática. 
La estructura GENIE se ha diseñado para soportar la ejecución de estos simulacros entre múltiples recursos informáticos y datos distribuidos por un período de tiempo extenso. Aprovechamos la variedad de recursos heterogéneos, incluyendo la Red Nacional del Reino Unido de recursos informáticos en paralelo (que ejecuta Linux y Windows Compute Cluster Server) y el aprovechamiento de los ciclos de escritorio en sitios distribuidos. 
Nuestro almacén de datos de infraestructura informática utiliza Oracle 10G para almacenar metadatos sobre nuestros simulacros y el servidor SQL para coordinar el seguimiento de persistencia de nuestros flujos de trabajo en ejecución. (Ver Figura 1) En Supercomputing 2006, en Tampa, Fla., mostramos el modo en el que la aplicación de la metodología de flujo de trabajo descripta en el articulo puede proporcionar los simulacros de GENIE con un entorno de rápida composición de simulacros y un entorno de hosting eficaz para coordinar su ejecución. Los científicos que participan en la colaboración, están investigando el modo en el que la circulación termosalina en el Atlántico – la densidad del agua marina es controlada por la temperatura (termo) y la salinidad (salina) y las diferencias de densidad impulsan la circulación oceánica– responde a los cambios de niveles de dióxido de carbono en la atmósfera e intenta comprender, en particular, las estabilidad de las corrientes oceánicas más importantes bajo distintos contextos de cambios climáticos. 
Microsoft Institute of High Performance Computing: Matthew J. Fairman, Andrew R. Price, Gang Xue, Marc Molinari, Denis A. Nicole, Kenji Takeda, and Simon J. Cox Colaboradores externos:: Tim Lenton (Facultad de Ciencias Ambientales, Universidad de East Anglia) y Robert Marsh (Centro Nacional de Oceanografía, Universidad de Southampton)

Escenarios del problema

Es difícil generalizar completamente una solución de HPC debido a las necesidades específicas de un dominio individual y a los procesos comerciales que surgen como parte de los desafíos de ingeniería que se presentan normalmente. Sin embargo, podríamos considerar tres situaciones posibles para la solución. La primera es la situación básica del usuario: finalizar una tarea de informática. Las otras dos situaciones posibles son administración y creación y soporte para este proceso.

Definir el problema y la solución

Utilizar la cartera disponible de tecnologías de Microsoft nos permite crear una arquitectura más completa para una solución de HPC y posibilita la realización de funciones que brindan valor adicional a los equipos que utilizan la solución. Además, el uso de estas tecnologías puede construir de un modo integrado e interactuar con las infraestructuras existentes. Esta sección del artículo describe una arquitectura posible y algunas características de esta arquitectura así como también el valor que proporcionan.

Mejorar el valor de las soluciones de informática de alta productividad

Debido a la complejidad de los problemas de dominio y los requisitos descriptos anteriormente, la conclusión final es que las soluciones generalmente se diseñan para obtener resultados. Esto, es en cierto modo un logro y, en primer lugar, deja de lado el esfuerzo intelectual que implica el desarrollo de algoritmos informáticos y soluciones conceptuales. Existe, por supuesto, un modo simple de mejorar el valor de una solución de HPC: 
Hacerla más rápido. Sin embargo, para problemas de suficiente complejidad informática, en cierto punto, pasa a ser poco provechoso continuar el intento de mejorar la solución debido a las limitaciones de la tecnología. Los esfuerzos para intentar mejorar la velocidad de los procesamientos se pueden representar mediante el ciclo que se muestra en el Figura 1. Para mejorar la velocidad de los procesamientos, un equipo de desarrollo debe: 
• Utilizar más o mejor hardware. Los beneficios de los procesadores más rápidos, discos más rápidos, mayor memoria, etc., podrían estar limitados por la capacidad del software o los algoritmos para utilizar el hardware disponible. También, está limitado por los ciclos de lanzamiento de hardware de nueva generación y probablemente esté muy limitado por el presupuesto. 
• Utilizar más o mejor software. Es más probable que los algoritmos en sí mismos sean un problema que el software subyacente, pero a veces, pueden existir mejoras en la manipulación de datos u otras funciones para proporcionar un avance útil. Esto también puede estar afectado por restricciones presupuestarias. 
• Utilizar mejores algoritmos. Mejores algoritmos requieren invención que simplemente puede no ser posible y es probablemente menos predecible que las mejoras de software o hardware, aunque cuando ocurre puede brindar la mejora más importante de todas. 
Por lo tanto, el desafío ante mejoras continuas de plataforma sobre un nivel básico es fácil de comprender pero difícil de lograr. Como resultado, los equipos que utilizan soluciones de HPC tienden a ser pragmáticos respecto de la cantidad de tiempo que les lleva completar los cálculos ya que comprenden que están aprovechando al máximo las tecnologías disponibles y, como mencionamos anteriormente, pueden sentirse satisfechos por al menos haber completado la operación. Una vez que se han reducido los tiempos informáticos hasta ser lo más prácticos posible, entonces, mejorar el valor de estas soluciones es cuestión de considerar el proceso total y las repercusiones de realizar cálculos para reducir aún más el tiempo total en nuevas comprensiones científicas o de la industria. Dada la naturaleza de la investigación/ingeniería de los problemas, entonces el proceso total generalmente implica un flujo de trabajo humano antes o después de la tarea informática. También se trata del desarrollo de un grupo de soluciones para proporcionar interfaces y controles que posibiliten una ejecución eficaz del proceso total, permitiendo a los investigadores e ingenieros realizar sus tareas de un modo más rápido y eficaz.

Requisitos para la información documentada

En áreas de investigación, existe una necesidad muy importante de registrar la información por varios motivos. Puede simplemente existir la necesidad de volver a ejecutar algoritmos para asegurar que se produzcan los mismos grupos de resultados como un ejercicio de “tranquilidad”, pero muy probablemente, esto será requerido como parte de prueba y de backup científico para publicar una investigación. Pueden también existir razones estatutarias para esta información documentada: en la industria aeroespacial, en el caso de una investigación de accidente aéreo, los ingenieros que toman decisiones determinadas de ingeniería pueden ser responsables de la causa del accidente y estar sometidos a procesos penales. 
Por lo tanto, la necesidad de recrear estados específicos y grupos de resultados según sea necesario y de seguir los pasos de decisión hacia estas elecciones es de extrema importancia. La complejidad de estas tareas es aún mayor cuando uno considera que el ciclo de vida del diseño de un avión podría ser de 50 años. Volúmenes significativos de datos y movimiento de datos Deep Thought desempeñó una de las tareas más grandes de HPC en los últimos tiempos (de ficción). Dada una pregunta simple (“¿Cuál es la respuesta a la vida, el universo y todo lo demás?”), arrojó una respuesta simple (“42”), aunque, después de varios millones de años de procesamiento y una pequeña pausa desconcertadora al final del proceso.
Sin embargo, la realidad es que es muy probable que los cálculos significativos que requieren una gran cantidad de procesamiento impliquen importantes cantidades de datos a lo largo de todo el ciclo de vida del cálculo. Aún, con la simplicidad del ingreso de datos y el resultado del estilo de Deep Thought, los grupos de datos operativos dentro del espacio de problema durante el cálculo, pueden ser significativos. Se deben desarrollar estrategias para administrar estos datos y sus metadatos. Dada la necesidad de la información documentada, estas estrategias deben ser flexibles y eficaces, y deben estar integradas dentro procesos de flujo de trabajo utilizados para coordinar los cálculos.

Procesos y cálculos de larga ejecución

El avance tecnológico de la infraestructura requerida para realizar procesamientos a gran escala y administrar cantidades masivas de datos ha brindado oportunidades para desempeñar procesos que anteriormente eran poco prácticos desde el punto de vista de la informática. El desarrollo de nuevos algoritmos y la paralelización del código para que se ejecuten de modo simultáneo sobre varios clústeres informáticos pueden tener un efecto radical, reduciendo el tiempo de procesamiento en diversos órdenes de magnitud. Por lo tanto, un procesamiento interminable, tal vez, podría ejecutarse en varias semanas o meses. Este éxito ha permitido a las industrias lograr importantes resultados y aprovechar estas posibilidades para ofrecer más orientación a los desarrollos.

Diseñada para una solución a un problema específico

Debido a que las interacciones de la industria y los cálculos son diversos, no hay proveedores de soluciones particulares para un problema determinado, lo que da como resultado soluciones altamente individualizadas que surgen de empresas o departamentos de investigaciones que necesitan estos cálculos. Esta individualidad se compone de una pequeña cantidad de equipos que realmente buscan resolver estos problemas y tal vez necesitan mantener la propiedad intelectual de los algoritmos u otros aspectos de procesos específicos. La individualidad en sí misma no es un problema –puede ser algo muy bueno– pero debido a que las soluciones técnicas son medios para lograr un objetivo, es probable que estas soluciones individuales no sean “productizadas” y por lo tanto, probablemente sean difíciles de relacionar y poco claras.

Requisitos para soluciones de informática de alta productividad

En los dominios de ingeniería y ciencia, las soluciones HPC pueden utilizarse para resolver problemas matemáticos complejos en una diversidad de áreas, como cálculos estadísticos para epidemiología genética, cálculos de dinámica de fluidos para la industria aeroespacial y modelado del medio ambiente global. Cada vez más, el desafío está en integrar todos los componentes requeridos para componer, procesar y analizar los resultados de problemas de manipulación de datos e informática de gran escala. Aún con diferencias tan diversas en los problemas, los requisitos para las soluciones poseen las mismas características debido al contexto del dominio y la complejidad del problema en cuestión.

Brindar informática integral de alta productividad

Síntesis 
En la actualidad, realizar un cálculo informático complejo científico y de ingeniería significa mucho más que simplemente comprar una gran supercomputadora. Si bien tradicionalmente HPC significa “High Performance Computing” (Informática de Alto Rendimiento), creemos que la solución integral real debería ser “Informática de Alta Productividad”. A lo que queremos referirnos con “Informática de Alta Productividad” es a toda la estructura de manipulación de datos e informática y también a las herramientas, tecnologías y plataformas necesarias para coordinar, procesar y monitorear este cálculo integral. Muchos desafíos están asociados con la producción de una solución general de Informática de Alta Productividad (HPC) para problemas de dominio científicos y de ingeniería. En este artículo tratamos estos desafíos basados en los requisitos típicos de estos problemas, proponemos varias soluciones y demostramos el modo en el que han sido implementados para usuarios a través de un modelo científico específico del entorno, siguiendo el proceso desde el comienzo hasta el final. Nuestra solución técnica general se podrá poner en práctica para cualquier solución que requiera capas de interfaz y control para un servicio de HPC orientado al servicio distribuido.

Conclusión

Los proveedores de servicios deben enfrentar continuamente desafíos para cumplir con la creciente demanda de los clientes de nuevos servicios que ofrecen mayor valor para las pequeñas y medianas empresas, desarrolladores, consumidores y diseñadores. 
Deben brindar un alto grado de servicio para mantener la lealtad del cliente y lograr sus objetivos comerciales. Los proveedores de servicios buscan la forma de producir la plataforma de Web “milagrosa” que ayude a reducir el costo total de propiedad (TCO) y brindar a sus clientes una respuesta de forma efectiva y eficaz. Cuando hacemos referencia a una solución de plataforma de Web compuesta de servicios de Web, almacenamiento de datos y almacenamiento de bases de datos, inevitablemente ocurre un problema dentro de alguno de estos componentes. Una solución es tan sólida como su punto más débil. Fundamentalmente, cada componente de una solución debe ser escalable a nivel exterior y de forma ascendente y también debe ser rentable. Este artículo no trata las tecnologías (código abierto o código cerrado) que pueden cumplir el objetivo o lo han cumplido en algunas áreas, sino que trata los problemas básicos de arquitectura que no se tienen en cuenta como “primordiales” cuando se desarrollan tecnologías. En la actualidad, no es suficiente crear tecnología porque sí con el objeto de ocupar una posición. Sólo mediante la estrategia, planificación y desarrollo de soluciones de gran escala podremos respaldar requisitos de gran escala. El mundo está creciendo, las necesidades son cada vez mayores y sólo tiene sentido que las infraestructuras también.

Clúster de SQL

SQL es un servicio importante que ofrecen varios hosters a la mayoría de sus clientes. Sin embargo, es una de las áreas claves que muchos hosts no implementan como un clúster. Existen varias razones para esto y la más importante es el costo y la licencia. No obstante, los hosts que eligen un cluster de SQL altamente disponible deben diseñar su arquitectura de modo que seleccionen el tipo correcto de metodología de clúster que soporte diversas bases de datos. A diferencia de otras empresas en las que el clúster de SQL está compuesto de una cantidad relativamente pequeña de bases de datos, las compañías de hosting implementarán cientos, sino miles, de bases de datos para un único clúster de base de datos. Este clúster debe ser resistente tanto en rendimiento como en tiempo de actividad. Debido a que las compañías de hosting no tienen control sobre la forma en la que sus clientes escriben sus aplicaciones, se presentan algunos problemas únicos al diseñar un clúster para un hosting masivo. En un entorno de hosting, cada cliente posee 1-n bases de datos asignadas a él. Estas bases de datos pueden almacenarse en un único clúster o distribuirse entre múltiples clústeres. El clúster más común que un hoster construiría para un hosting SQL masivo es el clúster de SQL activo-pasivo estándar. Sin embargo, en la medida que los hosts entran en un hosting de software como servicio (SaaS), los requisitos del clúster de SQL se convierten de redundancia del nodo a redundancia de datos. Esto agrega más problemas ya que estos mismos sistemas aún alojarán numerosas bases de datos. 
No existe un modo rentable de construir una plataforma de clúster de SQL compacta, de alta disponibilidad y escalable. Cada topología del clúster tiene sus desventajas junto con el hecho de que los hosts no tienen control sobre el diseño de la aplicación de los clientes. El clúster de SQL ideal permitiría a los hosts realizar una distribución de carga, además de duplicar la base de datos, sin tener que ocuparse de los problemas de colisión de datos mientras mantienen una gran cantidad de bases de datos entre los clústeres.

Red de área de almacenamiento (SAN)

Varios sistemas de almacenamiento de las empresas pueden operar tanto una SAN como un NAS, con una diferencia clave que es el método que se utiliza para conectarlos. En el caso de una SAN, los métodos más importantes son el Canal de Fibra (FC) y iSCSI. 
Las compañías de hosting pueden construir sistemas de correo y SQL escalables de alta disponibilidad, como por ejemplo Exchange, si utilizan las capacidades de una SAN como el almacenamiento centralizado para estos tipos de clústeres. Además, cuanto más avanzada es la SAN, más opciones tiene la compañía de hosting para realizar tareas como gestión de recuperación y captura de imágenes dentro del SQL o Exchange. Uno de los principales inconvenientes para un sistema de almacenamiento empresarial es el costo en el que incurre el hoster. Los hosters son cuidadosos al asegurar que el producto que van a implementar tenga un rendimiento de la inversión (ROI) lo suficientemente alto como para justificar el costo de un SAN.

“NO EXISTE UN MODO RENTABLE DE CONSTRUIR UNA
PLATAFORMA DE CLÚSTER DE SQL COMPACTA, DE
ALTA DISPONIBILIDAD Y ESCALABLE. CADA
TOPOLOGÍA DEL CLÚSTER TIENE SUS DESVENTAJAS
JUNTO CON EL HECHO DE QUE LOS HOSTS NO TIENEN
CONTROL SOBRE EL DISEÑO DE LA APLICACIÓN DE
LOS CLIENTES”.

Almacenamiento conectado a la red (NAS)

La mayoría de los host que han elegido plataformas altamente escalables han optado por utilizar NAS como el almacenamiento remoto centralizado para todos sus clientes. En entornos de Windows altamente disponibles, NAS se accede mediante el Sistema Común de Archivos de Internet (CISS), generalmente entre una red de almacenamiento dedicado. El contenido de Web de los clientes se almacena centralmente en el NAS con la ruta hacia el NAS almacenada como ruta lógica utilizando un sistema de archivos distribuido (DFS). La combinación de NAS y DFS permite que un hoster basado en Windows distribuya los clientes entre múltiples subsistemas de almacenamiento NAS, impidiendo que un problema global, afecte a esos clientes. 
Optimizar CISS, TCP/IP y el NAS contribuye en gran medida respecto de lo escalable que es el NAS con la cantidad de sitios de clientes simultáneos para los cuales puede estar sirviendo contenido. Si el NAS posee una escasa optimización, los hosts pueden presentar problemas que pueden afectar toda la base del cliente. Sin embargo, los hosts mitigan esto utilizando múltiples subsistemas de NAS para diferentes segmentos de clientes y dedicando interfaces y redes de almacenamiento para este tipo de tráfico. Varios subsistemas de NAS poseen capacidades de duplicación y captura de imagen. Los hosters utilizan estas tecnologías para ofrecer un proceso consistente para la recuperación y emergencias –en especial, si se considera que el sistema de almacenamiento podría contener cientos de miles de clientes. Un problema con el subsistema de almacenamiento NAS puro es que debido a que tecnologías como SQL no admiten el almacenamiento remoto de sus bases de datos entre los CISS, esto limita al hoster respecto del tipo de servicio que puede ofrecer.

Almacenamiento directamente conectado (DAS)

DAS es uno de los métodos de almacenamiento más comunes y clásicos que utilizan las compañías de hosting de Web. Se trata de servidores de Web autónomos en los que el contenido se ubica de forma local. El beneficio principal es que si un único servidor autónomo deja de funcionar, toda la base del cliente no queda sin conexión. La desventaja es que los clientes están sujetos a cualquier tipo de falla del hardware, no simplemente a una falla del subsistema del disco. Además, este tipo de configuración presenta problemas como límites de densidad, problemas de migración y falta de alta disponibilidad para los sitios de Web y distribución de la carga. 

“LA INCORPORACIÓN DE LA ARQUITECTURA DE 64- BITS LE HA PERMITIDO A VARIOS HOSTERS DARSE EL LUJO DE AGREGAR ENORMES CANTIDADES DE MEMORIA A SUS SERVIDORES. SI BIEN ESTO LES PERMITE IR MÁS ALLÁ DE OBSTÁCULOS POTENCIALES, TAMBIÉN SE PUEDEN DESCUBRIR OTROS PROBLEMAS”.

Almacenamiento del contenido

Uno de los principios centrales para las plataformas de hosting masivo, altamente escalables que enfrentan los arquitectos es determinar la ubicación del contenido del cliente que será almacenado. En la mayoría de los casos, se trata contenido que está dentro de SQL o en el disco. Ya que el punto de inicio de la arquitectura es un clúster configurado con miles de sitios, no es práctico ubicar el contenido en discos directamente conectados a la placa. Las secciones que se detallan a continuación dividen las diferentes arquitecturas de almacenamiento que son comunes entre las compañías de hosting.

Duplicación de la configuración

Otro requisito fundamental para el hosting masivo en entornos de alta disponibilidad, es mantener el estado y la configuración entre todos los usuarios de Web del grupo. Si bien hay otras configuraciones que deben existir en cada usuario, la más importante es la del servidor de Web. Algunos servidores de Web poseen soporte para un almacén de configuración centralizada. Para quienes no lo poseen, se debe implementar alguna solución de software para duplicar la configuración entre los servidores.

Planificación de un grupo de aplicaciones con alta disponibilidad

El desafío de los hoster es lograr un equilibrio entre lograr altos niveles de aislamiento y maximizar la escala. Debido a esto, varios de ellos se ven obligados a utilizar el escenario de grupo de aplicaciones híbridas que mencionamos anteriormente. Un escenario típico incluiría múltiples grupos de aplicaciones, cada uno de los cuales cumple un propósito específico. Por ejemplo, los sitios de Web que sólo poseen contenido estático, podrían colocarse todos en un único grupo de aplicaciones compartidas. Esto es posible ya que el contenido estático no está asociado con los problemas de rendimiento y seguridad que surgen con el contenido dinámico. Todos los otros grupos de aplicaciones estarían dedicados a sitios que tengan contenido dinámico. Esto permite que el hoster asigne mayores recursos para estos sitios. Esta configuración es más frecuente en entornos de hosting compartido en los que una única plataforma debe brindar servicio a clientes que poseen tanto contenido estático como dinámico.

Escenario del grupo de aplicaciones compartidas

Un escenario del grupo de aplicaciones compartidas describe una situación en la que más de una aplicación o sitio de Web reside en el mismo grupo de aplicaciones. Existen dos configuraciones diferentes para grupos de aplicaciones compartidas. La primera es uno-para-N en la que el proveedor de hosting dedica un único grupo de aplicaciones a una cantidad predefinida de sitios de Web. La segunda es una configuración uno-para-todos en la que el host coloca todos los sitios de Web en un único grupo de aplicaciones. Un escenario del grupo de aplicaciones compartidas permite escalar mejor ya que no somete al sistema a las limitaciones de la memoria impuestas por un diseño de grupo de aplicaciones uno-a-uno. 
Existe una preocupación y es que las aplicaciones y sitios de Web en un grupo de aplicaciones compartidas podrían potencialmente dar a algunos usuarios acceso a los datos de otros. Se deben realizar ciertas migraciones para garantizar que estas aplicaciones y sitios de Web estén asegurados. Por ejemplo, es necesario que cada sitio de Web tenga un usuario anónimo único y se debe aplicar una lista de control de acceso a los archivos de la Web. También, las aplicaciones ASP.Net se deben configurar con seguridad de acceso al código y se deben ajustar a un nivel medio de confianza. Estos pasos ayudarán a garantizar que las aplicaciones y los sitios de Web en el servidor sean seguros, aún en un grupo de aplicaciones compartidas. Debido a que todas las aplicaciones se ejecutan bajo el mismo proceso de grupo de aplicaciones compartidas es que carecen del aislamiento que varios proveedores de hosting necesitan. Esto puede ser una preocupación en escenarios de alta disponibilidad ya que un problema afecta a todos los otros sitios de Web y aplicaciones del mismo grupo. Por ejemplo, una aplicación podría causar que un grupo de aplicaciones se reinicie o aún peor, que se cierre completamente. También es más difícil para los administradores del sistema identificar un problema cuando hay varios sitios y aplicaciones en un único grupo. Si bien hay herramientas disponibles que permiten al host aislar los problemas dentro del grupo de aplicaciones, esta tarea se logra con mayor facilidad cuando se utiliza un grupo de aplicaciones uno-a-uno para modelar un sitio de Web.

Análisis de tendencias: Aislamiento vs. Escala

El escenario de aislamiento uno-a-uno se define con un grupo de aplicaciones asignado a una aplicación única o en un escenario de hosting de Web compartido para un sitio de Web único. Esto permite que un hoster logre un alto nivel de aislamiento ya que cada aplicación o sitio de Web se ejecuta dentro de un proceso único y no comparte recursos con otros en el servidor. Ésta es una solución óptima para un proveedor de software independiente o hoster que debe asegurar a sus clientes que otros en el mismo servidor no tendrán acceso a sus datos importantes. Sin embargo, este escenario es limitado en un escenario de hosting masivo. Si bien brinda el nivel deseado de aislamiento y seguridad debido a los requisitos de memoria, no cumple el objetivo de proporcionar a los hosters la escala que desean. Ya que cada grupo de aplicaciones ejecuta la memoria de sus consumidores y finalmente se produce un embotellamiento. 
La incorporación de código dinámico dentro de la plataforma añade un nuevo nivel de complejidad. Por ejemplo, las aplicaciones ASP.NET aumentan la cantidad de memoria necesaria para el grupo de aplicaciones. Esto se vuelve un problema para el hoster porque limita la cantidad de sitios de Web dinámicos que pueden ejecutarse en un servidor. Comienzan a observar que pueden escalar dentro de cientos de sitios en vez de miles de sitios, que es el punto de referencia para la mayoría de los progresos en la tecnología del hardware. Concretamente, la incorporación de la arquitectura de 64-bits le ha permitido a varios hosters darse el lujo de agregar enormes cantidades de memoria a sus servidores. Si bien esto les permite ir más allá de obstáculos potenciales, también se pueden descubrir otros problemas.

Ajustar Microsoft IIS para el hosting masivo

Dentro de una compañía de hosting masivo que se centra en la plataforma de Microsoft, existe una constante presión de un nivel más alto de densidad sobre cada servidor del grupo. Con una arquitectura alta disponibilidad compleja, el hoster aumenta su modelo de densidad; sin embargo, aún aparecen obstáculos en el desempeño, en particular, con los grupos de aplicaciones. En IIS, el diseño del grupo de aplicaciones es fundamental para lograr la máxima densidad. Si no se dedica tiempo a planificar de un modo apropiado el diseño del grupo de aplicaciones, esto puede causar problemas inesperados de estabilidad y rendimiento. Los grupos de aplicaciones tratan verdaderamente el aislamiento y existe una correlación directa entre el nivel de aislamiento que se elige y la cantidad de aplicaciones que se colocan en el servidor. Al diseñar grupos de aplicaciones se debe comparar la necesidad de seguridad con la estabilidad deseada. Los hosters deben elegir entre dos escenarios de grupos de aplicaciones, un escenario de grupo de aplicaciones compartidas uno-a-muchos o un escenario uno-a-uno. Es importante observar que en la Figura 2, el escenario del grupo de aplicaciones uno-a-uno muestra una tendencia más hacia el aislamiento pero lejos de la escala. Por otro lado, el escenario del grupo de aplicaciones compartidas, muestra una tendencia hacia niveles superiores de la escala mientras que se aleja del aislamiento. En el mejor de los casos, el hoster elegiría una solución que le permitiera maximizar la escala sin sacrificar el aislamiento y la seguridad.

Distribución de carga conjunta

Para mantener un costo mínimo y también para lograr que la administración de la plataforma sea menos compleja, un hoster puede elegir implementar un modelo de distribución de carga conjunta. Denominamos modelo de distribución de carga conjunta a aquél en el que todos los servidores comparten exactamente la misma configuración. Cada servidor en el centro de servidores también es capaz de servir tanto el contenido estático como el dinámico. En los sistemas que ejecutan IIS, el diseño del grupo de aplicaciones es indispensable para maximizar la escala en este tipo de modelo.

Modelos de distribución de carga

Debido a que hay múltiples usuarios de Web, los arquitectos de hosting deben considerar diversas opciones para distribuir la configuración entre todos los servidores de Web. Esta configuración depende del tipo de modelo de distribución de carga que se elige. Existen varios modelos para distribuir la carga entre los múltiples usuarios de Web. Analizaremos dos que son comunes para las posibles situaciones de hosting: distribución de carga de aplicación y distribución de carga conjunta. 
Distribución de carga de aplicación
La distribución de carga de aplicación describe un modelo en el que la carga se distribuye entre múltiples nodos de usuarios de Web basándose en la función del servidor. Este modelo por lo general está basado en la solicitud y utiliza las capacidades de enrutamiento de la capa de aplicación que varios balanceadores de carga de red soportan en la actualidad. Este modelo permite a los hosters dividir el grupo de servidores basándose en las cargas de trabajo del servidor. Al analizar una implementación típica de este modelo, veremos que los servidores se separan de aquellos que tratan contenido dinámico como ASP.NET o se diseña un PHP para el contenido estático (Figura 1). Se puede agregar aún más granularidad a esta configuración si se dividen más los servidores dinámicos de acuerdo a su función específica. Esto implica la creación de subgrupos de servidores más pequeños para cada tipo de aplicación. Todo el tráfico de ASP.NET sería enrutado hacia un subgrupo de servidores de ASP.NET y todo el contenido de PHP sería enrutado hacia otro subgrupo de servidores. Debido a que los servidores de contenido dinámico normalmente necesitan más recursos, el diseño permite al hoster utilizar para esos sitios una clase diferente de hardware del que se necesitaría para el contenido estático. La mayoría de los hosters deben considerar el costo al diseñar sus plataformas; por lo tanto, el modelo de distribución de carga de aplicación tal vez no siempre sea posible simplemente porque este modelo aumenta la cantidad de servidores requeridos. La aplicación de carga de distribución también incrementa la complejidad al administrar los servidores y se basa en gran medida en los equipos de conexión de redes.

Consideraciones al planificar arquitecturas de alta disponibilidad para hostings masivos

Cuando el hoster reflexiona y comienza a pensar en las tecnologías que podría agrupar y el modo de crear una plataforma para soportar varios servicios y sitios de Web, se le ocurren varios requisitos claves. Estos requisitos abarcan desde la cantidad de aplicaciones o usuarios hasta el tipo de funciones y servicios que deberían soportarse y su impacto sobre el sistema subyacente –ASP.NET, PHP, SQL y demás– y finalmente el costo por aplicación o sitio alojado.
El objetivo primario al diseñar una plataforma alojada es optimizar la escalabilidad, disponibilidad, densidad y paridad de precios al mismo tiempo que se sigue un nivel de seguridad lo más granular posible aislando los clientes entre sí.
Separamos estos servicios en amplios segmentos, con las siguientes piezas principales de arquitectura: IIS clúster(es), SQL clúster(es), servicios de infraestructura de soporte, como servicios del Active Directory, System Center Operations Manager, almacenamiento centralizado, ya sea en una red de área de almacenamiento o en un almacenamiento conectado a la red, clústeres SSL de descarga, clústeres FTP, y otros clústeres similares. La separación de estos servicios en varios segmentos le permite al hoster escalar la arquitectura de diferentes modos. Un hoster podría escalar un clúster de SQL de un modo diferente que un clúster de Web y presentar un conjunto diferente de problemas de arquitectura. Otro factor que forma parte de la arquitectura es el requisito de legado, cuyo mejor ejemplo son las Extensiones del Servidor de FrontPage (FPSE). Miles de clientes todavía las utilizan y son necesarias si la plataforma de hosting masivo espera atraerlos. Por lo general, estas extensiones las utilizan pequeños negocios para crear sitios simples.
Todavía se utilizan para herramientas de desarrollo como Visual Studio y Visual Web Developer por su funcionalidad de carga para HTTP, a pesar del desaliento por parte de Microsoft. Los componentes de legado, como FPSE, no pueden ser eliminados de un modo simple por grandes hosts sin una pérdida de la base de clientes. Analicemos ahora algunos de estos clústeres dentro de la arquitectura. La pieza más grande es el clúster de Web y el segundo es el clúster de SQL. Es importante recordar que un diferenciador clave entre lo que hacen los hosters frente a lo que hacen otras empresas como departamentos internos de TI, es que intentarán colocar la mayor cantidad posible de sitios o bases de datos en un clúster. Por este motivo, ciertas soluciones empresariales no funcionan para ellos. Además, no siempre controlan el tipo de aplicaciones que se colocan en un servidor y por lo tanto, no pueden definir la capacidad del mismo modo que lo pueden hacer las empresas típicas.

Historia de la industria del hosting y problemas actuales - II

“EL OBJETIVO PRIMARIO AL DISEÑAR UNA PLATAFORMA ALOJADA ES OPTIMIZAR LA ESCALABILIDAD, DISPONIBILIDAD, DENSIDAD Y PARIDAD DE PRECIOS AL MISMO TIEMPO QUE SE SIGUE UN NIVEL DE SEGURIDAD LO MÁS GRANULAR POSIBLE AISLANDO LOS CLIENTES ENTRE SÍ”. 
La industria del hosting continuó saturándose de compañías competitivas en respuesta a la alta demanda de servicios en la Web como sitios de Web dinámicos y carritos de compras para el comercio electrónico. Este mercado próspero obligó a los hosters a diferenciar sus servicios de los otros mediante la creación de acuerdos de nivel de servicio (SLAs). No sólo los hosters deben ofrecer sus servicios a un bajo costo, sino que también deben estar siempre disponibles. Esto se confirma con la creciente dependencia que poseen los clientes y negocios sobre la Web y sus demandas de aplicaciones más interactivas y complejas. La producción de servicios altamente disponibles, por lo general, da como resultado más servidores para soportar la redundancia así como también nuevos requisitos de rendimiento, seguridad y gestión. ¿De qué manera pueden los hosters escalar y respaldar estos servicios con la arquitectura de software y hardware ofrecida? Debido a estos cambios en la industria, las empresas de tecnología de software que ofrecían la base para estos servicios se dieron cuenta que sus actuales sistemas operativos no podían satisfacer las necesidades del los hosters. 
Todavía se necesitaba un alto nivel de interacción con el administrador del sistema para que las operaciones siguieran ejecutándose con la menor cantidad de problemas posible. Los ingenieros de la industria y los proveedores de servicios independientes tomaron conciencia de la carencia que había en los servicios en relación con software/hardware y emprendieron su propio objetivo desarrollando tecnologías que cubrían las carencias al mismo tiempo que se beneficiaban. En ese momento los hosters comenzaron a considerar la creación de plataformas que fueran más escalables y que pudieran lograr una mayor densidad. También debían ser de fácil gestión. Un buen comienzo al construir este tipo de arquitectura es analizar los varios servicios que el hoster necesita soportar y administrar.

Historia de la industria del hosting y problemas actuales - I

Para comprender totalmente las complejidades de la plataforma de Web hosting, primero debemos comprender el modo en el que se inicio el mercado del hosting y cómo evolucionó hasta su estado actual. Antes de que el hosting tradicional comenzara a tomar forma, los simples sitios de Web estáticos eran populares y relativamente nuevos para el público en general. 
La infraestructura que se construyó para respaldar este movimiento era igualmente básica y se concentró en obtener la mayor cantidad posible de clientes en vez de brindar servicios de última generación, como aplicaciones interactivas y alta disponibilidad. Comencemos con la descripción de la arquitectura clásica que han utilizado en el pasado los hosters basados en Microsoft. Un único servidor de Web autónomo, con servicios de FTP, que ejecuta IIS con contenido alojado localmente en el servidor. Cada sistema autónomo tiene un cierto costo –hardware, software, licencias, redes, energía, espacio en gabinete y demás. Algunos hosters, aún han llevado esto al extremo alojando todos los servicios en un servidor único para una cantidad x de clientes. 
Por ejemplo, tienen servidores con IIS, SQL, software para servidor de correo de terceros y almacenamiento local para el contenido alojado. Estos módulos son fáciles de imaginar y de rápida implementación, en especial, si se venden paquetes básicos a clientes que sólo desean alojar muy pocas páginas y nada más complicado. En la media que este tipo de plataforma crecía, comenzaron a surgir varios problemas: necesidad de restauración y backup, uso de un espacio costoso para un centro de datos, capacidad para el servidor, clientes con alta carga y administración general. A los problemas de plataforma se sumaban una demanda cada vez mayor por parte de los clientes y progresos en la nueva tecnología de Web. Surgieron tecnologías como PHP, Cold Fusion, ASP, JSP y ASP.NET que ofrecían plataformas más complejas impulsadas por el deseo de los clientes de una funcionalidad más rica y mejores negocios. Esto, a su vez, produjo nuevas aplicaciones que requerían almacenes de datos como SQL y otras tecnologías relacionadas. 
En la medida que se creaban nuevas aplicaciones, el potencial comercial que ofrecían estas aplicaciones se volvió más evidente y más solicitado. Los hosters, en el intento de maximizar los resultados y simplificar la gestión, continuaron con la gestión de todos servicios requeridos para soportar a sus clientes sobre un servidor autónomo. Esto creó una mayor carga en un único servidor, obstaculizándolo y reduciendo la cantidad de sitios Web que podía servir. La demanda del consumidor aumentó de un modo más rápido de lo que la tecnología de hardware podía soportar. Los hosters tuvieron que escalar a nivel exterior, aislando y separando los servicios en varios servidores en vez de escalar de forma vertical con un hardware más rápido.

Bibliografía y recursos

Bibliografía
“VB.NET Programming”. Billy Hollis, Rockford Lhotka. Ed. Wrox, 2001
“Microsoft Visual Basic .NET step by step”. Michael Halvorson. Ed. Microsoft Press, 2002
“Fundamentos de Programación”. Luis Joyanes Aguilar. Ed. Mc.Graw Hill, 1996
“The Microsoft .NET Framework”. Equipo de desarrollo de Microsoft. Ed. Microsoft Press, 2001

Recursos en Internet

http://www.algoritmodigital.com
http://msdn.microsoft.com/msdnmag/
http://www.dnjonline.com/webwatch/index.html

Arquitecturas de alta disponibilidad para hosting masivo

Síntesis 

Escalabilidad y alta disponibilidad son propiedades esenciales y a la vez opuestas para las infraestructuras de hosting. Ya sea ingeniero de programas de código abierto, consumidor de soluciones comerciales o ingeniero TI de Microsoft, parece que no existe la “solución milagrosa”. Al investigar diferentes aspectos de una infraestructura de hosting, podemos encontrar tecnologías existentes que se pueden agrupar para crear la “solución milagrosa”. Este proceso también ayudará a detectar las diferencias que debemos reducir. La plataforma de la “solución milagrosa” debe ofrecer una infraestructura que permita una gran cantidad de cuentas de clientes y debe ser escalable y con alto grado de redundancia. Este artículo se centrará en los componentes necesarios para la construcción de un entorno exclusivo que sea escalable, confiable, seguro y fácil de mantener y que al mismo tiempo ofrezca alta disponibilidad (HA, sus siglas en inglés). Los proveedores de aplicaciones solitarias, hasta hosters compartidos de alta densidad, se beneficiarían de esta solución. Pero, ¿Existe? De lo contrario, ¿Cuáles son los desafíos que nos bloquean en la actualidad? y ¿Cuánto podemos aproximarnos a esto?.

Codificación de menús - IV

Como muestra el Código fuente 392, el proceso a codificar para el menú mnuGrabar es muy similar al empleado para visualizar por pantalla los datos de la encuesta, sólo que en esta ocasión el destino de los datos es un archivo que manipulamos a través de un objeto StreamWriter.

Imports System.IO
Public Class Form1
Inherits System.Windows.Forms.Form
'....
'....
Private Sub mnuGrabar_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles mnuGrabar.Click
Dim Archivo As String
Dim Escritor As StreamWriter
Archivo = InputBox("Ruta y nombre de archivo")
Escritor = New StreamWriter(Archivo)
Escritor.WriteLine(Me.txtNombre.Text)
Escritor.WriteLine(Me.txtObservaciones.Text)
Escritor.WriteLine(IIf(Me.chkCompra.Checked, "Ha realizado compra", "No ha
comprado"))
If Me.rbtHabitual.Checked Then
Escritor.WriteLine("Es un cliente habitual")
End If
If Me.rbtNuevo.Checked Then
Escritor.WriteLine("Es un nuevo cliente")
End If
If Me.rbtPropio.Checked Then
Escritor.WriteLine("Ha venido en vehículo propio")
End If
If Me.rbtPublico.Checked Then
Escritor.WriteLine("Ha venido utilizando transporte público")
End If
Escritor.WriteLine("Ha visitado la sección: " & Me.lstSecciones.SelectedItem)
Escritor.WriteLine("Su música preferida es: " & Me.cboEstiloMusical.Text)
Escritor.Close()
MessageBox.Show("Archivo de datos grabado")
End Sub
'....
'....
End Class
Código fuente 392

Finalizado el proceso de volcado a un archivo, podemos abrir el mismo con el Bloc de notas por ejemplo, para ver que su contenido corresponde a la información introducida en el formulario

Codificación de menús - III

La Figura 158 muestra el mensaje obtenido al usar el objeto MessageBox durante la ejecución del programa.
Figura 158. Caja de mensajes visualizada con el objeto MessageBox.
Por último, la opción de menú Grabar va a ser la encargada de tomar la información del formulario y guardarla en un archivo de texto. El nombre del archivo lo solicitaremos al usuario a través de la función del lenguaje InputBox( ), que muestra una caja de mensaje estándar incluyendo un cuadro de texto en el que en nuestro caso se deberá introducir la ruta y el nombre del archivo a crear. Debido a que vamos a trabajar con archivos, es necesario que al comienzo de la ventana del editor de código del IDE importemos el espacio de nombres System.IO.

Codificación de menús - II

No debemos preocuparnos porción this Aspecto, PORQUE vamos a recurrir a la Enumeración de la Plataforma. NET ControlChars, Qué COMO do Nombre indica, contains Caracteres de control. De Este Modo, si seleccionamos el Miembro CrLf, y he aquí una Cadena concatenamos una, enviaremos la Combinación de caractères de retorno de carro y nueva línea, y la siguiente Porción de texto Sera ubicada en Una línea nueva. El Código fuente 391 Muestra el Código del evento ¿clic de mnuDatos. Simplificar Para El Ejemplo, sí ASUME Que el usuario del Programa ha introducido Valores del tanto en el ListBox Control de Como en el ComboBox, of this Manera evitamos Código Adicional de comprobación.

Private Sub remitente mnuDatos_Click (ByVal como System.Object, ByVal e As
System.EventArgs) Handles mnuDatos.Click
Dim Texto As String
Texto = Me.txtNombre.Text y ControlChars.CrLf
Texto & = Me.txtObservaciones.Text y ControlChars.CrLf
Texto & = IIf (Me.chkCompra.Checked "Ha Realizado compra", "No ha comprado") y
ControlChars.CrLf
Si Me.rbtHabitual.Checked Entonces
Texto & = "Es Un Cliente habitual" y ControlChars.CrLf
End If
Si Me.rbtNuevo.Checked Entonces
Texto & = "Es Un Nuevo cliente" y ControlChars.CrLf
End If
Si Me.rbtPropio.Checked Entonces
Texto & = "Ha Venido en vehicle proprio" & ControlChars.CrLf
End If
Si Me.rbtPublico.Checked Entonces
Texto & = "Ha Venido utilizando Transporte Público" y ControlChars.CrLf
End If
Texto & = "Ha visitado la Sección:" & Me.lstSecciones.SelectedItem y
ControlChars.CrLf
Texto & = "Su Música Preferida es:" & Me.cboEstiloMusical.Text
MessageBox.Show (Texto, "Datos introducidos en el Formulario")
End Sub
Código fuente 391

Codificación de menús - I

Al seleccionar Una Opción de menú en la ONU Formulario Sí Producir el Evento clic Sobre el Control de MenuItem Correspondiente, PODEMOS de Que Codificar al Igual Qué hacemos estafa Cualquier Otro Controlar del Formulario. Que Es El Puesto clic Evento Por Defecto del Control de MenuItem, al HACER clic doble Sobre el Mismo en Modo de Diseño, pasaremos al editor de Código, Que nos situará en el manipulador Procedimiento de este Evento. El Código fuente 389 corresponde a la Opción de menú Salir (control mnuSalir), en La Que escribiremos el Código necesario para cerrar el Formulario.

Private Sub Remitente mnuSalir_Click (ByVal COMO System.Object, ByVal e As
System.EventArgs) Handles mnuSalir.Click
Me.Close ()
End Sub
Código fuente 389

En La opcion de menu Datos introducidos (control mnuDatos), Vamos a recopilar Toda La Información introducida Sobre el Cliente en el Formulario de Encuesta, visualizándola des Través De Una caja de Mensajes. Dicha Caja La mostraremos empleando la del CLASE de Mensajes, y Haz método Compartido Show (), en Cuyo imprimación Parámetro situamos el Texto a mostrar, MIENTRAS Que de En El Podemos Segundo INCLUIR sin título Para El Mensaje. En el Código fuente 390 mostramos ONU Pequeño EJEMPLO de la USO.

MessageBox.Show ("Hola")
Código fuente 390

En nuestro de Caso concreto, el Texto a mostrar es muy extenso, PODEMOS Como comprobar Por La CANTIDAD de Controles del Formulario; ADEMÁS, LO MÁS apropiado Seria Que CADA dato FUERA mostrado en Una línea Distinta del Mensaje

Diseño de menús - II

El proceso de edición del menú se realiza directamente en el formulario, en el mismo lugar en el que el menú aparecerá en tiempo de ejecución. Al hacer clic en la primera opción del menú, podemos dar nombre y propiedades a la misma. Simultáneamente y de un modo muy intuitivo, veremos las próximas opciones disponibles, tanto las desplegables a partir de dicho menú, como las de la barra principal. Sólo hemos de movernos en la dirección que necesitemos, asignando nombre a las opciones, y valores a sus propiedades. Ver la Figura 157.
Figura 157. Diseño de las opciones de menú de un formulario. 
Cada una de las opciones que componen el menú es a su vez un control MenuItem, puesto que como hemos dicho anteriormente, un menú está compuesto del control contenedor MainMenu y una serie de controles MenuItem, tantos como opciones tenga el menú. Si durante la creación de los MenuItem sólo proporcionamos el nombre, el IDE va asignando a dicho control valores por defecto en sus propiedades. En este caso asignaremos los siguientes nombres a las opciones de nuestro menú: mnuArchivo, mnuDatos, mnuGrabar y mnuSalir. 
Para modificar las propiedades de una opción de menú, sólo hemos de seleccionarlo en la estructura de menú que estamos creando en el diseñador del formulario, y pasar a la ventana de propiedades. Entre las propiedades disponibles para un control MenuItem podemos destacar las siguientes. 
• Text. Contiene una cadena con el literal o texto descriptivo de la opción de menú. 
• Enabled. Permite habilitar/deshabilitar la opción de menú. Cuando se encuentra deshabilitada, se muestra su nombre en un tono gris, indicando que no puede ser seleccionada por el usuario. 
• Checked. Marca/desmarca la opción. Cuando una opción está marcada, muestra junto a su nombre un pequeño símbolo de verificación o punteo. 
• ShortCut. Se trata de un atajo de teclado, o combinación de teclas que nos van a permitir ejecutar la opción de menú sin tener que desplegarlo. Al elegir esta propiedad, aparecerá una lista con todos los atajos disponibles para asignar. 
Podemos adicionalmente, asignar una tecla de acceso rápido o hotkey a una opción de menú, anteponiendo el carácter & a la letra que deseemos, de las que se encuentran en la propiedad Text del control MenuItem. Al igual que sucede con los demás tipos de controles, en el texto de la opción de menú, aparecerá subrayada la mencionada letra. De este modo, cuando despleguemos un menú, no será necesario posicionarnos en una de ellas para ejecutarla, sino que simplemente pulsando la tecla rápida, se ejecutará el código de dicha opción.

Diseño de menús - I

En Primer Lugar, debemos ESQUEMA Añadir control de la ONU MainMenu al: Diseñador del Formulario. Este control de Actua Como contenedor de Las DIVERSAS OPCIONES de Que compondrán de el menú. En la ventana de Propiedades daremos el Nombre mnuPrincipal un control Este. Una Vez insertado, this controlar Qaeda del situado Debajo de la Plantilla del: Diseñador del Formulario, en un panel no inferior Reservado Para Controles Especiales. 
Por Otro Lado, Debajo De La Barra de sin título Podemos ver La Primera Opción Con El Nombre Escribá here, sin Indicador Que SIRVE COMO punto de partida párr Comenzar el Diseño del menú. Ver la Figura 156.
Figura 156. Control MainMenu insertado en el Formulario.

Menús

Un menú coinci En Un Conjunto de options situadas horizontalmente Debajo de la barra de título de Formulario de la ONU. Al seleccionar ESTAS OPCIONES, SI despliegan Listas de Nuevas Opciones Dependientes, Que permiten ejecutar Acciones de servicio e IMCMEXICO. 

Controles de pisos menú 

Desde la Perspectiva del Programador de VB.NET, la construcción del menú PARA UN Formulario sí Realiza utilizando de forma Combinada dos controls : MainMenu y MenuItem. Para completar our EJEMPLO del Formulario de Encuesta, Veremos a continuacion Los Pasos necesarios un para dar ESQUEMA Añadir menú de un sencillo a la ventana, que contenga algunas opciones.

ComboBox - II

La Figura 155 Muestra el Formulario estafa Este nuevo añadido control.
Figura 155. Control ComboBox desplegando Lista de Valores.

ComboBox - I

Control de la ONU El ComboBox es basado en la Combinación (de Ahí do Nombre) de dos Controles Que ya TRATADO: hemos: TextBox y ListBox. ComboBox control de la ONU DISPONE De Una zona de Edición de texto y de Una Lista de Valores, de Que Podemos desplegar desde el Cuadro de Edición. IGUALMENTE Tiene ONU Estilo De Visualizacion de Que Podemos establecer MEDIANTE la Propiedad DropDownStyle, Cuyos Valores Hijo del los siguientes:
• Sencillo. El control de sí Muestra Con La Misma apariencia Que sin ListBox. 
• DropDown. Estilo defecto por. Muestra El control de do cerrada Lista, y permite select values ​​La Lista. En el Caso de Que de el valor necesitemos de Que No Se encuentre en la Lista, de Podemos escribirlo en Do Cuadro de texto. 
• DropDownList. Muestra El control de do cerrada Lista, y permite select values ​​La Lista, Pero no permite ESCRIBIR Valores en el Cuadro de texto. 
En el Caso de Que La Lista desplegable muy grande mar, MEDIANTE la Propiedad MaxDropDownItems asignaremos El Número de Elementos Máximo Que mostrará la Lista del control. El resto de Propiedades y Métodos hijo Comunes Con Los Controles TextBox y ListBox. Para our Formulario de EJEMPLO, añadiremos control de la ONU of this pisos Con El Nombre cboEstiloMusical, en el Que seleccionaremos el Estilo musical del Cliente Preferido. Sin embargo, no añadiremos values ​​a la lista en Modo de Diseño, Lo Que Sino HAREMOS porción Código en El Momento En que el mar Formulario Cargado al ejecutarse
Podemos Lo ESTO conseguir codificando el Evento Load () del Formulario, Que producen CUANDO La Ventana es Cargada Durante la ejecución celebra del Programa. Situándonos en el editor de Código, abriremos La Lista de Nombre de Clase y seleccionaremos el valor de base de Eventos del clase. A continuacion, abriremos La Lista de Nombre de Método, seleccionaremos y El Evento Load (), ESCRIBIENDO el Código Que se Muestra en el Código fuente 388, de el CuAl utiliza la Propiedad Items del control ComboBox, Llamando un su metodo AddRange (), y le pasa COMO Parámetro array sin de cadenas, Con values ​​Que apareceran en el ComboBox.

Private Sub Form1_Load (remitente de ByVal como objeto, ByVal e As System.EventArgs) Handles
MyBase.Load
Me.cboEstiloMusical.Items.AddRange (New String () {"Pop", "Rock", "Clásica", "Nueva
Edad "})
End Sub
Código fuente 388

ListBox - II

• Ordenado. This de Cuando Propiedad Contiene el valor verdadero, Ordena el Contenido de la Lista. Contiene de Cuando, Los Elementos de Que hubiera previamente ordenados falsas, permanecen Orden estafa DICHO, MIENTRAS de Que Los Nuevos no ordenados seran.
• IntegralHeight. Los Valores de la Lista hijo mostrados al completo this CUANDO Propiedad contains Verdadero. Sin embargo, al asignar el valor False, Segun el no molestar del control, Que Puede del El último valor de la Lista del mar visualizado SÓLO en parte. La Figura 154 Muestra de la ONU Propiedad estafa ListBox this a Incorrecta.
Figura 154. ListBox mostrando a instancia de parte del ÚLTIMO Elemento debido a la Propiedad IntegralHeight.
• SelectionMode. Establece el Modo en el Que vamos un Poder select Los Elementos de la Lista. Contiene Si this Propiedad Ninguno, No Se realizará Selección; One, permite SELECCIONAR values ​​Uno a Uno; MultiSimple permite select Múltiples values ​​La Lista Pero debemos seleccionarlos INDEPENDIENTEMENTE; ULTIMO POR, MultiExtended nos posibilita La Selección múltiple, Con La Ventaja De que Podemos HACER clic en valor un, y ARRASTRAR, seleccionando en La Misma Operación Varios Elementos de la Lista. 
• SelectedItem. Devuelve el Elemento de la Lista ACTUALMENTE Seleccionado. 
• SelectedItems. Una Devuelve Colección ListBox.SelectedObjectCollection, contains Que Los Elementos de la Lista Que Han Sido Seleccionados

ListBox - I

Un control de ListBox Contiene Una Lista de Valores, De Los Cuales, el usuario Puede del select UNO O Varios simultaneamente. Para Nuestro Programa de EJEMPLO, insertaremos control de la ONU de Este TIPO En El Formulario Con El lstSecciones Nombre, MEDIANTE EL Podremos de Que Indicar las Secciones del Establecimiento Que ha visitado el Cliente encuestado. Entre las Principales Propiedades de control de Este, PODEMOS resaltar Las Siguientes. 
• Artículos. Contiene la Lista de Valores Que Visualiza el control de el. Se Trata de ListBox.ObjectCollection sin pisos, de Manera Que el Contenido de la Lista Puede Ser del tanto Tipos caracter, COMO Numéricos y Objetos de Distintas Clases. Al select this Propiedad en la ventana de Propiedades del control, pulsar y El Que Button Contiene, de Podemos introducir en Una ventana Elementos de control el párr. Ver Figura 152.
Figura 152. Introducción de Valores PARA UN ListBox en Tiempo de Diseño.
El control de porción quedaria lo del tanto estafa Valores asignados en la Etapa de Diseño, COMO Muestra la Figura 153.
Figura 153. ListBox en Diseño estafa values ​​En Su Lista.