Buscador

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.

GroupBox

La Solución cols Problema planteado En El anterior Apartado Pasa porciones encerrar el los Conjuntos de CONTROLES RadioButton en la ONU el control GroupBox, agrupándolos ASI Funcionalidades POR. De this forma, añadiremos al Formulario dos GroupBox; en Uno situaremos los RadioButton Que informan del Tipo de Transporte, y en El Otro Los Que Indican el Tipo de Cliente. A partir de ESE Momento, Podremos select values ​​simultaneamente en Ambos Grupos, Como Muestra la Figura 151.
Figura 151. Uso de Controles GroupBox párr una organizadora RadioButton.

RadioButton

Los Controles RadioButton nep permiten Definir Conjuntos de opciones autoexcluyentes, de Modo de Que situando controles Varios de este pisos en la ONU UNO Seleccionado Tener Formulario, Podremos SÓLO en Ocasión Cada. Ya Que do Función es la de seleccionar Una Opción Entre VARIAS Posibles, las Propiedades de Este controlan Hijo muy Similares a las del CheckBox, Porción Lo Que no vamos a incidir especialmente en Ellas. Añadiremos sin nuestra EJEMPLO dos RadioButton Que nos permitan sable El Medio De Transporte utilizado Parr Llegar al Establecimiento, COMO Muestra la Figura 149.
Figura 149. Inserción de Controles RadioButton en el Formulario.
La ubicación realizada realizada de Controles RadioButton de esta Manera en el Formulario Tiene el pecado Pecado embargo Inconveniente, ya Que Si añadimos dos Nuevos Controles de este pisos, Parr Indicar si ESTAMOS ante la ONU compradora habitual o uno del del nuevo, de Los Cuatro RadioButton SÓLO Podremos Tener UNO Seleccionado en Momento Cada, COMO VEMOS en la Figura 150
Figura 150. Es SOLO seleccionar Posible pecado RadioButton.