Revisión y resumen de acuerdos del nivel de servicio en nube

Del "Cloud Computing Use Cases Whitepaper" Versión 4.0

Esta es una revisión de la sección acuerdos de nivel de servicio de "Cloud Computing Use Cases Whitepaper" Versión 4.0 — publicada por el Cloud Computing Use Cases Discussion Group — para destacar los inconvenientes relacionados con los acuerdos de nivel de servicio que los arquitectos y desarrolladores deberían tener en cuenta cuando se transladan a la nube.

developerWorks cloud computing editors, developerWorks Editors, IBM

A los editores de informática en nube de developerWorks les gustaría saber sobre los tipos de recursos técnicos que desea para lograr que el viaje de su aplicación a las nubes sea más sencillo, para que la jornada sea más efectiva. Encuéntrenos en dwcloud@us.ibm.com.



03-02-2011

Este artículo le da un vistazo al "Cloud Computing Use Cases Whitepaper," Versión 4.0 del Cloud Computing Use Case group — un depósito de información creado por una comunidad web abierta de más de 1,400 participantes (en la Versión 3.0 eran 900). Este comenzó con un grupo de partidarios del Open Cloud Manifesto y creció hasta incluir a representantes de pequeñas y grandes empresas, agencias gubernamentales, asesores, y vendors.

El alcance del "Cloud Computing Use Cases Whitepaper" es amplio, de modo que no intentaremos abarcar todo el documento en una sola lectura. En esta revisión, nos concentraremos en la evaluación que realizó el grupo de los inconvenientes del acuerdo de nivel de servicio en la nube, una observación importante porque los ANSs describen la relación entre el proveedor de la nube y el consumidor de la nube, definiendo esencialmente las bases de la confianza que los consumidores de la nube tienen en la habilidad de un proveedor de la nube para ofrecer servicios de infraestructura.

¿Quién lo hace posible?

Quienes contribuyeron en el "Cloud Computing Use Cases Whitepaper," Versión 4.0 son Dustin Amrhein, Patrick Anderson, Andrew de Andrade, Joe Armstrong, Ezhil Arasan B, James Bartlett, Richard Bruklis, Ken Cameron, Reuven Cohen, Tim M. Crawford, Vikas Deolaliker, Andrew Easton, Rodrigo Flores, Gaston Fourcade, Thomas Freund, Valery Herrington, Babak Hosseinzadeh, Steve Hughes, William Jay Huie, Nguyen Quang Hung, Pam Isom, Sam Johnston, Ravi Kulkarni, Anil Kunjunny, Thomas Lukasik, Bob Marcus, Gary Mazzaferro, Craig McClanahan, Meredith Medley, Walt Melo, Andres Monroy-Hernandez, Dirk Nicol, Lisa Noon, Santosh Padhy, Greg Pfister, Thomas Plunkett, Ling Qian, Balu Ramachandran, Jason Reed, German Retana, Bhaskar Prasad Rimal, Dave Russell, Matt F. Rutkowski, Clark Sanford, Krishna Sankar, Alfonso Olias Sanz, Mark B. Sigler, Wil Sinclair, Erik Sliman, Patrick Stingley, Robert Syputa, Doug Tidwell, Kris Walker, Kurt Williams, John M Willis, Yutaka Sasaki, Michael Vesace, Eric Windisch, Pavan Yara, y Fred Zappert.

¿Qué es un ANS?

Los autores concuerdan en que el ANS debería contener:

  • La lista de servicios que proporciona el proveedor y una definición completa de cada servicio.
  • Las métricas para determinar si el proveedor está suministrando los servicios tal como lo prometió y un mecanismo de auditoría para monitorear el servicio.
  • Las responsabilidades del proveedor y el consumidor y los recursos disponibles para ambos si los términos del ANS no se cumplen.
  • Una descripción de cómo el ANS se modificará con el correr del tiempo.

Los autores analizan los dos tipos de ANSs — acuerdos listos para la venta y acuerdos negociados personalizados. Ellos señalan que los clientes con necesidades de datos críticos no estarán satisfechos con acuerdos listos para la venta, de modo de un primer paso antes de ir a la nube es determinar cuán críticos son sus datos y aplicaciones.

Las nubes públicas a menudo ofrecen un ANS no negociable que puede no ser aceptable para quienes poseen aplicaciones o datos de misión crítica.

¿Qué es un ONS?

Un ANS contiene objetivos de nivel de servicio u ONS (service level objectives o SLOs en inglés) que definen las condiciones objetivamente medibles para el servicio; algunos ejemplos son los parámetros de rendimiento, y la frecuencia y la sincronización de la corriente de datos, los porcentajes de disponibilidad para VMs y otros recursos e instancias, o las valoraciones de las urgencias para clasificar la importancia de los diferentes ONSs (como "la disponibilidad es más importante que el tiempo de respuesta").

Lo que se espera de los ONSs debería variar según las aplicaciones y los datos a los que tienen acceso las aplicaciones están hospedados en la misma nube o en nubes diferentes.

Monitoreo y medición

La administración del nivel de servicio, basada en ONSs, es la forma de reunir y administrar la información de performance en la nube. Este es el modo en el cual se la emplea:

  • El proveedor de la nube utiliza la administración de nivel de servicio para tomar decisiones relacionadas con la infraestructura; por ejemplo, si el rendimiento no siempre cumple con los requisitos del cliente, el proveedor puede reubicar el ancho de banda o agregar más hardware. O decidir hacer feliz a un cliente a expensas de otro. Para los proveedores, SLM ha sido diseñado para ayudar a tomar las mejores decisiones en base a los objetivos empresariales y las realidades técnicas.
  • El consumidor de la nube utiliza SLM para decidir cómo desea usar los servicios de la nube; por ejemplo, si agregar o no más máquinas virtuales y a que precio se determinará que esa opción es demasiado cara como para justificar los beneficio que acarrea. Para los clientes, SLM los ayuda a tomar decisiones en el modo en el cual utilizan la nube. Y a veces sobre cómo automatizar dichas decisiones.

¿Qué factores deberían considerarse en los términos del SLA?

Los autores realizaron una lista de 10 factores que se deben tener en cuenta al definir los términos de un ANS:

  1. Los objetivos de nivel empresarial: una organización debe definir porqué utilizará los servicios de la nube antes de definir exactamente qué servicios utilizará. Esta parte está más relacionada con cuestiones del área de la política organizativa que del área técnica: algunos grupos pueden obtener recortes de presupuesto o perder el control de su infraestructura.
  2. Las responsabilidades de ambas partes: es importante definir el balance de las responsabilidades entre el proveedor y el consumidor. Por ejemplo, el proveedor será responsable por los aspectos de Software-as-a-Service (Software como Servicio), pero el consumidor puede generalmente ser responsable por su VM, la cual contiene software registrado y trabaja con datos sensibles.
  3. Continuidad empresarial/recuperación de desastres: el consumidor asegura que el proveedor tiene una protección contra desastres adecuada. Dos ejemplos nos vienen a la mente: el almacenamiento de datos valiosos en la nube como backup y cloud bursting o rebalse de nubes (se intercambian cuando los centros de datos internos no pueden encargarse del procesamiento de las cargas).
  4. Redundancia: evalúe cuán redundantes son los sistemas de su proveedor.
  5. Mantenimiento: uno de los aspectos más agradables del uso de la nube es que el proveedor administra el mantenimiento. Pero cuando los proveedores realizan las tareas de mantenimiento, los consumidores deberían saber:
    • ¿Los servicios no estarán disponibles durante este tiempo?
    • ¿Estarán disponibles los servicios pero el rendimiento será mucho menor?
    • ¿El consumidor tendrá la oportunidad de comparar sus aplicaciones con el servicio actualizado?
  6. Ubicación de los datos: existen regulaciones con ciertos tipos de datos que sólo pueden almacenarse en ubicaciones físicas determinadas. Los proveedores pueden responder a esos requisitos con la garantía de que los datos del consumidor serán almacenados solamente en ciertas ubicaciones y con la habilidad de auditar la situación.
  7. Embargo de datos: si por cumplimiento de la ley se embarga el equipo de un proveedor para capturar los datos y las aplicaciones que pertenecen a un consumidor en particular, dicho embargo probablemente afecte a otros consumidores que utilizan el mismo proveedor. Evalúe la posibilidad de que una tercera parte proporcione backup adicional.
  8. Error del proveedor: realice planes de contingencia que tengan en cuenta el estado financiero del proveedor.
  9. Jurisdicción: de nuevo, comprenda las leyes locales que se aplican a su proveedor, al igual que comprende las leyes que se aplican a usted.
  10. Agentes de bolsa y revendedores: si su proveedor es un agente de bolsa o un revendedor de servicios nube, debe comprender las políticas de su proveedor y al actual proveedor.

Requisitos del ANS

Los autores realizaron una lista de 14 responsabilidades a tener en cuenta al evaluar un ANS:

  1. Seguridad: un consumidor debe comprender sus requisitos de seguridad y qué controles y patrones de federación son necesarios para cubrir dichos requisitos. Un proveedor debe comprender lo que debe ofrecer al consumidor para permitir los controles y los patrones de federación correspondientes.
  2. Encriptamiento de datos: los datos deben ser encriptados mientras que se encuentren en movimiento y mientras se encuentran en reposo. Los detalles de los algoritmos de encriptamiento y las políticas de control de acceso deberían especificarse.
  3. Privacidad: las principales preocupaciones relacionadas con la privacidad están relacionadas con los requisitos como el encriptamiento, la conservación y la eliminación de datos. Un ANS debería aclarar cómo el proveedor nube aisla los datos y las aplicaciones en un entorno multi-tenant.
  4. Conservación y eliminación de datos: ¿cómo comprueba su proveedor que cumple con las leyes para la retención y las políticas de eliminación de datos?
  5. Borrado y destrucción de hardware: idem #4.
  6. Cumplimiento regulatorio: Si las regulaciones deben implementarse según el tipo de datos, el proveedor nube debe ser capaz de probar que cumple con las mismas.
  7. Transparencia: en el caso de datos y aplicaciones críticas, los proveedores deben notificar por adelantado a los consumidores cuando no se respetan los términos del ANS. Esto incluye las cuestiones de infraestructura, como las interrupciones y los problemas de performance, además de los incidentes relativos a la seguridad.
  8. Certificación: el proveedor debería responsabilizarse por el suministro de la certificación necesaria y por mantenerse al día.
  9. Definiciones de performance: ¿Qué significa uptime? ¿Todos los servidores en todos los continentes están disponibles? ¿O sólo uno está disponible? Vale la pena aclarar estas definiciones. (Los autores de este paper sugieren estandarizar la terminología de la performance para que esto resulte más sencillo.)
  10. Monitoreo: por cuestiones de posibles incumplimientos, quizá desee determinar una organización de terceros que sea neutral para monitorear la performance del proveedor.
  11. Auditabilidad: dado que el consumidor es responsable por los incumplimientos que ocurrieran y provocaran pérdida de datos o de disponibilidad, es vital que el consumidor pueda auditar los sistemas y procedimientos del proveedor. El SLA debería dejar claro cómo y cuando tendrán lugar dichas auditorías. Estas pueden ser perjudiciales y costosas para el proveedor.
  12. Métricas: estas son algunas de las cosas tangibles que pueden monitorearse cuando suceden y realizar la auditoría después. Las métricas de un ANS deben definirse objetivamente y con claridad. A continuación encontrará una lista de las métricas comunes.
  13. Suministro de un ANS legible por máquina: esto puede permitir una selección dinámica y automatizada de un agente nube. En otras palabras, si su ANS requiere que el agente utilice el proveedor más económico posible para algunas tareas pero el más seguro para otras, este tipo de automatización lo hace posible. (Este tipo de servicio no se encuentra fácilmente disponible aún, pero es algo para tener en cuenta al contribuir con el análisis de estandarización del ANS de la nube.
  14. Interacción humana: el autoservicio a pedido es una de las características principales de la computación en nube, pero su SLA debería tener en cuenta que cuando usted necesita un ser humano, podrá contar con uno.

Algunas de las métricas de performance comunes (para la observación #12) son las siguientes

  • Rendimiento: velocidad de respuesta del sistema.
  • Confiabilidad: disponibilidad del sistema.
  • Balanceo de la carga: cuando contribuye la elasticidad.
  • Durabilidad: probabilidad de perder los datos.
  • Elasticidad: cuánto puede crecer un recurso.
  • Linealidad: performance del sistema a medida que aumenta la carga.
  • Agilidad: rapidez de repuesta del proveedor ante las variaciones de carga.
  • Automatización: porcentaje de solicitudes administradas sin intervención humana.
  • Tiempos de respuesta del servicio al cliente.

Algunas normas fundamentales sobre la responsabilidad

Los autores proporcionan un tratado conciso sobre una definición del trabajo de la responsabilidad relacionada con la performance en la nube. Este dice más o menos lo siguiente:

  • La regla de los nueves. Una métrica común relacionada con la responsabilidad es la cantidad de nueves que ofrece un proveedor (por ejemplo, si el servicio está disponible el 99.99999 % del tiempo, cinco nueves, entonces las interrupciones totales del sistema son de unos 5 minutos cada 12 meses). El problema es, ¿Qué es una interrupción? (Puede resultar una situación muy negativa si el proveedor llega a decidir lo que es una interrupción.)
  • Las capas de las nubes. Muchos ofrecimientos nube están construidos sobre otros ofrecimientos nube — esto es muy bueno para la flexibilidad y la potencia pero cada proveedor adicional hace que el sistema sea menos confiable. (Como si se estimara cada uno a cinco nueves, entonces el sistema en su conjunto es menor a cinco nueves.)
  • Distancia entre su aplicación y sus datos. Nuevamente, a medida que la cantidad de proveedores aumenta, otros factores que pueden afectar la responsabilidad se afirman. No sólo se encuentra usted afectado cuando uno de los sistemas cae, también se ve afectado cuando cae la red entre ellos.

Nada de esto debe asustar al consumidor nube; estos son sólo factores estructurales que se deben tener en cuenta al elegir un proveedor.

Requisitos y modelos de entrega, casos de uso

En el paper original, los autores presentan dos tablas:

  • Tabla 8.7: requisitos del SLA y modelos de entrega en la nube. Esta tabla compara los requisitos del SLA que analizamos (encriptamiento de datos, privacidad, certificación, etc.) con los modelos de entrega PaaS, IaaS, y SaaS (que se analizan en el paper original).
  • Tabla 8.8: requisitos del SLA y escenarios de casos de uso. Esta tabla compara los requisitos del SLA con los siete escenarios de casos de uso:
    1. Usuario final con la nube.
    2. Empresa con la nube con el usuario final.
    3. Empresa con la nube.
    4. Empresa con la nube con la empresa.
    5. Nube privada(en las instalaciones del cliente).
    6. Cambio de vendors de la nube.
    7. Nube híbrida.

En conclusión

Las conclusiones del "Cloud Computing Use Cases Whitepaper," Versión 4.0 sobre los acuerdo de nivel de servicio para la nube son claras:

  • La computación en nube no es factible sin adminstración de servicio, control, medición, monitoreo, identidad federada, ANSs y comparaciones, federación de datos y aplicaciones, despliegue, y administración del ciclo de vida.
  • La transparencia y la comunicación significativas por parte de los proveedores de la nube es una necesidad.
  • Si existe un estándar actual para cumplir con un requisito, los usuarios de la nube deben insistir para que los proveedores lo utilicen; si no, estos deben insistir para que la comunidad desarrolle uno.

Los autores declaran:

Mientras que las organizaciones utilicen servicios nube, las responsabilidades de ambos, el consumidor y el proveedor, deben establecerse claramente en un acuerdo de nivel de servicio. Un ANS define cómo el consumidor utilizará los servicios y cómo el proveedor los entregará. Es fundamental que el consumidor de los servicios nube comprenda completamente todos los términos del SLA del proveedor, y que el consumidor evalúe las necesidades de su organización antes de firmar cualquier acuerdo.

Este resumen y revisión ofrece un punto de referencia para ilustrar las preocupaciones sobre el acuerdo de nivel de servicio y las consideraciones tanto para los consumidores como para los proveedores de servicios. Lo invitamos a leer "Cloud Computing Use Cases Whitepaper" Versión 4.0 por completo para ver el análisis del Cloud Computing Use Case Discussion group sobre lo que los desarrolladores y los planificadores deberían solicitar a sus proveedores nube para que estos le suministren un entorno confiable para los datos y aplicaciones importantes.

Recursos

Aprender

Obtener los productos y tecnologías

  • Con el IBM trial software, el cual puede descargar directamente desde developerWorks, cree su próximo proyecto de desarrollo.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Cloud computing
ArticleID=622308
ArticleTitle=Revisión y resumen de acuerdos del nivel de servicio en nube
publish-date=02032011