Ante la imparable tendencia de migración a “la nube”, muchos responsables de los centros de datos se han fijado, en su plan de trabajo, disponer de parte de sus activos, actualmente “in situ”, en servicios gestionados mediante el modelo “cloud”. Para afrontar esta tarea desean conocer mejor cómo pueden gestionar y controlar los niveles de servicio (SLA´s) que pueden obtener de sus proveedores contratados para esta clase de servicio. Al utilizar el modelo “cloud”, los usuarios mueven sus datos y aplicaciones de centros propios a otros externos y compartidos.
Desde el punto de vista del responsable tecnológico de una organización, los recursos que en su conjunto forman toda su capacidad de servicio a su organización admiten ser estructuradas siguiendo diferentes puntos de vista. Sin embargo cualquier recurso total o parcial se caracteriza por tener tres propiedades inherentes y características: producción, transporte y consumo. En la noción de producción se incluye la computación y el almacenamiento de información. En definitiva, su potencia básica. El consumo es el trabajo realizado en los PCs, dispositivos portátiles y móviles, que ofrecen la solución y soporte al trabajo de los usuarios mediante las aplicaciones, su interfaz, etc. El transporte es la tecnología de red que enlaza la producción con el consumo. Con esta noción muchos responsables de IT han podido determinar la granularidad de la funcionalidad que su infraestructura y demás recursos, hardware y software, proporcionan en su empresa. Al mismo tiempo, los centros de datos son organismos vivos que evolucionan y cambian de forma y contenido permanentemente. De hecho, un gran vector de la planificación estratégica, en la mayoría de los centros de datos, es la evolución funcional totalmente vinculada, a su vez con la evolución tecnológica.
De esta situación se deriva una segunda noción de gran importancia en la migración al modelo Cloud. Es preciso conciliar la evolución orgánica del conjunto en su formato anterior, convencional, con un nuevo organismo externo que está siendo compartido y tiene por tanto, dimensiones variables en función de la respuesta flexible a las necesidades cambiantes en cada momento. Como puede inferirse, cada una de las propiedades anteriormente citadas, producción, transporte y consumo, serán variables en su capacidad debido a que el nuevo “organismo” tiene una elasticidad previsible para atender dinámicamente a las necesidades potenciales.
No puede olvidarse que todos los centros de datos tienen en su morfología un importante contenido de las evoluciones que han ido transformando su forma de prestar servicios. Este factor es aún más relevante en las grandes organizaciones que, por necesidades de sus volúmenes o de su competencia tuvieron que ser con frecuencia “early adopters” de las sucesivas oleadas tecnológicas.
Las diferentes formas de adopción tecnológica han dado un importante giro con el transcurso del tiempo, que de cierta forma viene a cubrir un ciclo cerrado como se expresa en la figura, que se incluye seguidamente. Como se muestra en dicho esquema, se representan las distintas fases producidas a lo largo de ese ciclo, que cubre un grna número de años y de generaciones de expertos y experiencias.
En la fase A, cuando los equipos eran escasos y muy caros, la producción se hacía mediante un sistema de Time Sharing tiempo compartido, es decir, alquilando tiempo en equipos propiedad de terceros sitos en otros lugares. En una fase B, la producción se trasladó a mainframes alojados en centros de datos propios y posteriormente, con la aparición de los “minis” a una computación distribuida remota. Con el tiempo, y los PC´s, mucha parte de la producción emigró a los escritorios de los usuarios finales. Posteriormente, fase C, los departamentos y los centros de trabajo fueron atendidos con servidores departamentales que más tarde se consolidaron en servidores que permitieron una creciente virtualización de los usuarios y así contribuían favorablemente a su movilidad. En esta situación se plantea la adopción de la fase D, donde parte de los servicios de la nueva arquitectura del centro de datos va a ser migrada a servicios en la nube, bien privada o pública.
Hay diversas formas de plantear este problema, pero en el mercado hay una predominante técnica de gestión basada en conocer los flujos de datos y servicios a través de la red y así medir los rendimientos obtenidos en cada caso.
Otra forma mucho más detallada y eficaz de incluir los cambios que han ido proporcionando los cambios tecnológicos puede conseguirse con el esquema evolutivo propuesto por la consultora alemana R. J. Sievers, en 2009, anticipando notablemente los criterios más relevantes para desarrollar la planificación del centro de datos en un contexto de recursos variables como plantea la migración e integración de los servicios gestionados y flexibles del modelo Cloud.
Para adoptar esta técnica correctamente, en un nuevo escenario, con la intervención de terceros, cuya presencia en el conjunto general es flexible dinámicamente, resulta necesario establecer el correcto mapa de la arquitectura disponible. Recomendamos que cada centro de datos construya su propio mapa, basándose en el modelo propuesto por R. J. Sievers, para conseguir una mayor visibilidad de la situación presente y de los condicionantes que pueden determinar las evoluciones necesarias.
Cuando, como en la fase B, se ejecutan a menudo las aplicaciones en el escritorio del usuario, medir el rendimiento de la aplicación era discutible porque la producción y el consumo ocurren en la misma máquina. Pero cuando las aplicaciones se ejecutan en un servidor departamental, en una oficina remota, la medición del rendimiento empieza a ser más útil porque la producción y el consumo están separados y están enlazados por una red. En este entorno, las estadísticas de rendimiento del servidor reflejan la experiencia del usuario lo suficientemente bien que no hacen necesaria ninguna herramienta especial.
Cuando la producción se mueve a la nube, sin embargo, la medida no sólo es de suma importancia, sino que además presenta una serie de desafíos. De hecho, al consolidar las aplicaciones en Centros de datos, fase C, las mediciones obtenidas en el servidor no sirven igual que en los entornos del servidor remoto, ya que no proporcionan una visión precisa del rendimiento al no reflejar el efecto que ejerce sobre la experiencia del usuario el transito por la red (denominemos la distancia de la red, que será parte del servicio gestionado, posiblemente por otro proveedor externo)
Para leer la segunda parte, haz click aquí
