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.