Odca compute iaa_s_masterum_es

ModelodeusoprincipaldeOPENDATACENTERALLIANCESM
:
InfraestructurainformáticacomoservicioREV.1.0

Copyright © 2012 Open Data Center Alliance, Inc. TODOS LOS DERECHOS RESERVADOS2
Open Data Center Alliance: Infraestructura informática como servicio Rev. 1.0
Tabla de contenido
Aviso legal........................................................................................................................................................................................................... 6
Reconocimientos................................................................................................................................................................................................. 6
Terminología y procedencia................................................................................................................................................................................. 6
1.0 Resumen ejecutivo......................................................................................................................................................................................... 7
2.0 Objetivo......................................................................................................................................................................................................... 7
3.0 Taxonomía..................................................................................................................................................................................................... 8
Tabla 3.1: Términos y definiciones......................................................................................................................................................... 8
4.0 Definición de CIaaS....................................................................................................................................................................................... 9
Figura 4.0.1 Marco conceptual de ODCA............................................................................................................................................... 9
4.1 Alcance de CIaaS................................................................................................................................................................................. 10
Figura 4.1.1 CIaaS en contexto............................................................................................................................................................ 10
4.2 Cargas de trabajo de CIaaS.................................................................................................................................................................. 11
4.3 Modelos de implementación................................................................................................................................................................. 11
Tabla 4.3.1 Modelos de la nube.......................................................................................................................................................... 11
4.4 Atributos del servicio de CIaaS............................................................................................................................................................. 12
Tabla 4.4.1 Atributos de niveles de servicio......................................................................................................................................... 12
4.5 Capacidades generales........................................................................................................................................................................ 13
4.6 Indicadores clave de rendimiento de CIaaS........................................................................................................................................... 15
5.0 Interoperabilidad.......................................................................................................................................................................................... 17
6.0 Impulsores del negocio y escenarios de uso................................................................................................................................................ 17
6.1 Escenarios de uso comercial................................................................................................................................................................ 17
Figura 6.1.1 Escenarios de uso modelo de CIaaS................................................................................................................................ 18
6.2 Desarrollo/Prueba................................................................................................................................................................................ 19
Tabla 6.2.1 Requisitos para el desarrollo y las pruebas....................................................................................................................... 19
6.3 Entorno de prueba de esfuerzo de carga..............................................................................................................................................20
Tabla 6.3.1 Prueba de esfuerzo de carga............................................................................................................................................ 20
6.4 Informática distribuida y de alto rendimiento........................................................................................................................................ 21
Tabla 6.4.1 Requisitos para la informática distribuida y de alto rendimiento........................................................................................ 21
6.5 Entorno de producción independiente tradicional.................................................................................................................................22
Tabla 6.5.1 Producción independiente habilitada para la nube.............................................................................................................22
6.6 Entorno de producción empresarial tradicional..................................................................................................................................... 23

Copyright © 2012 Open Data Center Alliance, Inc. TODOS LOS DERECHOS RESERVADOS 3
Tabla 6.6.1 Producción empresarial tradicional................................................................................................................................... 23
6.7 Entorno de producción empresarial para la nube.................................................................................................................................. 24
Tabla 6.7.1 Producción empresarial en la nube.................................................................................................................................... 24
6.8 Gestión de servicios y federación en la nube........................................................................................................................................ 24
7.0 Detalles de los atributos del servicio............................................................................................................................................................ 25
7.1 Funcionalidad....................................................................................................................................................................................... 25
7.2 Disponibilidad....................................................................................................................................................................................... 25
7.2.1 Resumen de los niveles de servicio: disponibilidad..................................................................................................................... 25
7.3 Capacidad de recuperación..................................................................................................................................................................26
7.3.1 Resumen de los niveles de servicio: capacidad de recuperación.................................................................................................26
7.4 Seguridad............................................................................................................................................................................................. 27
7.4.1 Resumen de los niveles de servicio: seguridad........................................................................................................................... 28
7.5 Elasticidad............................................................................................................................................................................................29
7.5.1 Resumen de los niveles de servicio: elasticidad..........................................................................................................................30
7.6 Servicios de capacidad de gestión........................................................................................................................................................30
7.6.1 Resumen de los niveles de servicio: monitoreo........................................................................................................................... 31
7.6.2 Resumen de los niveles de servicio: intervalo de muestreo informado........................................................................................ 31
7.6.3 Resumen de los niveles de servicio: cantidad de tareas automatizadas activas.......................................................................... 32
7.6.4 Resumen de los niveles de servicio: elaboración de informes..................................................................................................... 32
7.7 Rendimiento.........................................................................................................................................................................................33
7.7.1 SLA de rendimiento ...................................................................................................................................................................33
7.7.2 Medición del rendimiento...........................................................................................................................................................33
7.7.3 Elaboración de informes de rendimiento.....................................................................................................................................33
7.7.4 Monitoreo del rendimiento..........................................................................................................................................................33
7.7.5 Análisis del rendimiento..............................................................................................................................................................34
7.7.6 Interfaz y definición de rendimiento............................................................................................................................................34
8.0 Interfaz del servicio y modelo de referencia.................................................................................................................................................34
8.1 Arquitectura conceptual de ODCA.........................................................................................................................................................34
Figura 8.1.1 Marco conceptual de ODCA.............................................................................................................................................34
8.2 Ciclo de vida básico de la nube............................................................................................................................................................35
8.3 Requisitos de la interfaz del servicio....................................................................................................................................................35
8.4 Interfaces requeridas específicas......................................................................................................................................................... 37
Tabla 8.4.1 Interfaces requeridas específicas..................................................................................................................................... 37

8.5 Instrumentación del servicio................................................................................................................................................................40
Figura 8.5.1 Interfaces........................................................................................................................................................................40
8.6 Ejemplo de escenario de uso: capacidad de recolocación de recursos en la nube pública en un SLA especificado............................... 41
9.0 Operaciones y gestión................................................................................................................................................................................. 42
9.1 Información general.............................................................................................................................................................................. 42
9.2 Motivaciones........................................................................................................................................................................................ 42
9.3 Escenarios de uso de operaciones de CIaaS.........................................................................................................................................43
9.3.1 Escenario de uso 1: configuración de control y acceso...............................................................................................................43
9.3.2 Escenario de uso 2: capacidades de aprovisionamiento y de anulación de aprovisionamiento....................................................44
9.3.3 Escenario de uso 3: Identificación de fallas en el servicio o en el SLA por parte del proveedor..................................................45
9.3.4 Escenario de uso 4: Identificación de fallas en el servicio o en el SLA por parte del suscriptor...................................................45
9.3.5 Escenario de uso 5: notificación de interrupción o cambio del servicio......................................................................................46
9.3.6 Escenario de uso 6: monitoreo del servicio................................................................................................................................46
9.3.7 Escenario de uso 7: uso y facturación del suscriptor.................................................................................................................. 47
9.4 Niveles de servicio de operaciones y gestión........................................................................................................................................48
Tabla 9.4.1 Niveles de servicio de operaciones y gestión....................................................................................................................48
10.0 Arquitectura técnica...................................................................................................................................................................................48
10.1 Supuestos y contexto.........................................................................................................................................................................48
10.2 Componentes.....................................................................................................................................................................................48
Figura 10.2.1 Componentes de la arquitectura de CIaaS..................................................................................................................... 49
10.3 Nivel informático................................................................................................................................................................................ 49
10.3.1 Resumen de los niveles de servicio: atributos de instancias informáticas.................................................................................50
10.4 Nivel de almacenamiento...................................................................................................................................................................50
10.4.1 Requisitos para el almacenamiento en bloque..........................................................................................................................50
10.4.1.1 Resumen de los niveles de servicio: atributos del almacenamiento en bloque................................................................50
10.4.2 Requisitos para el almacenamiento de objetos......................................................................................................................... 51
10.4.3 Entramado de almacenamiento................................................................................................................................................ 51
10.4.3.1 Resumen de los niveles de servicio: atributos del entramado de almacenamiento.......................................................... 52
10.5 Entramado de red............................................................................................................................................................................... 52
10.5.1 Resumen de los niveles de servicio: atributos del entramado de red........................................................................................53
10.6 Gestión...............................................................................................................................................................................................53
10.6.1 Resumen de los niveles de servicio: gestión.............................................................................................................................54
11.0 Consideraciones de seguridad....................................................................................................................................................................54

11.1 Requisitos de seguridad......................................................................................................................................................................54
11.2 Pautas de implementación..................................................................................................................................................................56
11.2.1 Supuestos................................................................................................................................................................................56
11.2.2 Pautas generales.....................................................................................................................................................................56
11.2.3 Pautas específicas de los niveles de servicio........................................................................................................................... 57
11.3 Catálogo de servicios de seguridad.................................................................................................................................................... 57
11.4 Protección contra malware................................................................................................................................................................. 57
11.5 Control de admisión............................................................................................................................................................................58
11.6 Auditoría y gobierno de seguridad....................................................................................................................................................... 59
11.6.1 Escenario de uso del gobierno de seguridad............................................................................................................................. 59
12.0 Consideraciones comerciales.....................................................................................................................................................................60
13.0 Consideraciones regulatorias.....................................................................................................................................................................60
14.0 RFP Requirements.....................................................................................................................................................................................60
15.0 Próximos pasos y resumen de acciones industriales requeridas.................................................................................................................63
15.1 Acciones industriales requeridas........................................................................................................................................................63
15.2 Desarrollo de requisitos futuros de CIAAS..........................................................................................................................................63
16.0 Referencias...............................................................................................................................................................................................64
Modelos de uso de ODCA ..........................................................................................................................................................................64
Otras fuentes.............................................................................................................................................................................................65
Notas finales..............................................................................................................................................................................................66

Aviso legal
Copyright © 2012 Open Data Center Alliance, Inc. TODOS LOS DERECHOS RESERVADOS.
Este “Modelo de uso principal de Open Data Center AllianceSM
: Infraestructura informática como servicio” es propiedad de Open Data Center
Alliance, Inc.
AVISO PARA LOS USUARIOS QUE NO SON PARTICIPANTES DE OPEN DATA CENTER ALLIANCE: los usuarios que no son participantes de Open
Data Center Alliance solo tienen derecho a revisar y a hacer referencia a este documento o a citarlo. Toda cita o referencia a este documento
debe otorgarle a Open Data Center Alliance, Inc. completa potestad y debe reconocer los derechos de propiedad de Open Data Center Alliance,
Inc. con respecto a este documento. Dichos usuarios no pueden revisar, alterar, modificar, editar, hacer derivaciones o de otro modo enmendar
este documento de ninguna manera.
AVISO PARA LOS USUARIOS QUE SON PARTICIPANTES DE OPEN DATA CENTER ALLIANCE: el uso de este documento por parte de los
participantes de Open Data Center Alliance está sujeto a los estatutos y otras políticas y procedimientos de Open Data Center Alliance.
OPEN DATA CENTER ALLIANCESM
, ODCASM
, y el logotipo® de OPEN DATA CENTER ALLIANCE son nombres comerciales, marcas registradas,
marcas de servicio y logotipos (en conjunto “Marcas”) de propiedad de Open Data Center Alliance, Inc. y se encuentran reservados todos los
derechos sobre ellos. Se encuentra estrictamente prohibido el uso sin autorización.
Este documento y su contenido se proporcionan “TAL COMO ESTÁN” y están sujetos a todas las limitaciones establecidas aquí.
Los usuarios de este documento no pueden hacer referencia a ninguna metodología, estadística, requisito u otros criterios recomendados o
iniciales que puedan encontrarse en este documento o en cualquier otro documento distribuido por Alliance (“Modelos iniciales”) de ninguna
manera que implique que el usuario o sus productos o servicios cumplen o han pasado por pruebas o certificaciones para demostrar su
cumplimiento con cualquiera de estos Modelos iniciales.
Las propuestas o recomendaciones contenidas en este documento, incluidos, entre otros, el alcance y contenido de cualquier metodología,
estadística, requisito u otros criterios propuestos, no implican que se le pedirá a Alliance en el futuro desarrollar un programa de prueba,
cumplimiento o certificación para verificar cualquier implementación o cumplimiento futuros de dichas propuestas o recomendaciones.
Este documento no le otorga a ningún usuario de este documento ningún derecho a usar ninguna de las marcas de Alliance.
Toda otra marca de servicio, marca comercial y nombre comercial al que se haga referencia en este documento son propiedad de sus
respectivos dueños.
Publicado en noviembre de 2012.
Reconocimientos
ODCA desea agradecer las importantes contribuciones de contenido y conocimientos previos al grupo de Enterprise Cloud Leadership Council
del TM Forum, CloudScaling y Atos.
Terminología y procedencia
Parte del contenido de este documento ha sido recopilado, con autorización, de productos de trabajo externos a ODCA. Se han realizado todos
los esfuerzos necesarios para compatibilizar la terminología y la nomenclatura. Sin embargo, en los casos en los que haya alguna diferencia,
prevalecerá la terminología de ODCA.

MODELODEUSOprincipaldeOPENDATACENTERALLIANCESM
:
InfraestructurainformáticacomoservicioREV.1.0
1.0 Resumen ejecutivo
Dado el amplio espectro de consumidores de productos de la nube y de sus requisitos de infraestructura informática, existe una amplia variedad
de capacidades que los proveedores de servicios podrían ofrecer para satisfacer estas necesidades de servicios informáticos y, en última
instancia, para ofrecer experiencias de uso de aplicaciones rentables y excelentes a los usuarios finales.
Claramente, los proveedores de servicios no pueden cumplir con todas las permutaciones posibles de demanda y capacidades, en particular, en
los casos extremos, donde la falta de escala o volumen limita la capacidad de los proveedores de servicios de lograr economías de escala.
Para poder cumplir con los requisitos de infraestructura informática para el amplio espectro de consumidores de servicios, se requiere un marco
común alrededor del cual se pueda definir, aprovisionar, monitorear y gestionar la infraestructura como servicio. Se puede definir un conjunto
común de principios, estadísticas y marcos arquitectónicos, lo que da como resultado capacidades, niveles de servicios y atributos de servicios
uniformes entre varios proveedores, y al mismo tiempo permite a los proveedores individuales innovar y diferenciarse.
Para el año 2014, Open Data Center Alliance (ODCA) y sus miembros desean ver un mercado sólido, con cobertura completa para todos los
escenarios de uso que se contemplan en este documento. Más aún, la mayoría de los proveedores debería ofrecer servicios para por lo menos
la mitad de los escenarios de uso. Este Modelo de uso principal de ODCA: Infraestructura informática como servicio (CIasS) tiene como objetivo
ayudar a facilitar el potencial para esto, al establecer un marco de requisitos para servicios de infraestructura informática interoperables y
abiertos.
A la fecha, los esfuerzos de ODCA se han enfocado en las principales inquietudes de los consumidores y proveedores de servicios. Los modelos
de uso originales resultantes se enfocaron en temas específicos, como la gestión de identidades y mediciones, entre otros. El objetivo de esta
nueva ronda de modelos de uso es continuar desarrollando estos temas de enfoque específicos y proveer una plataforma sobre la cual poder
colocar todos los temas juntos de una manera más holística. Los modelos de uso principales harán referencia a los modelos de uso publicados
anteriormente y los sustentarán.
Este documento sirve para una variedad de públicos. Las personas que toman decisiones comerciales y que buscan soluciones específicas,
y los grupos de TI empresariales involucrados en la planificación, las operaciones y las adquisiciones encontrarán útil este documento. Los
proveedores de soluciones y vendedores de tecnología se beneficiarán de su contenido ya que podrán comprender mejor las necesidades de
los clientes y personalizar las ofertas de productos y servicios. Las organizaciones de normalización encontrarán útil la información a la hora de
definir estándares abiertos relevantes para los usuarios finales.
2.0 Objetivo
Este documento y los modelos de uso de apoyo a los que hace referencia describen los requisitos para lograr una infraestructura informática como
servicio completa. Existen aspectos de este modelo de uso donde los requisitos son más estrictos que los que se encuentran hoy en día en las nubes
públicas populares. Es importante comprender que este documento especifica requisitos empresariales suficientes como para desplazar centros de
datos empresariales establecidos. Este marco común se requiere para que los servicios de CIaaS puedan ser evaluados, adquiridos y desechados por
empresarios de un modo tal que se refleje la visión de las firmas miembro de ODCA de un mercado sólido y activo para finales del año 2014.
El área de Infraestructura como servicio (IaaS) es bastante amplia y se puede segmentar en tres ofertas distintas de “servicio”: informática,
almacenamiento y red; cada una de ellas se ofrece en una variedad de modelos de uso. Mientras que las áreas de servicios de red y
almacenamiento son esenciales para los modelos de servicios de nube generales, los cimientos de la informática en la nube se basan
fundamentalmente en las capacidades de ”informática como servicio”. Por lo tanto, este documento aborda el área de la informática de IaaS con
más profundidad que para las áreas de red y almacenamiento. ODCA abordará estas otras áreas de IaaS en trabajos futuros.

3.0 Taxonomía
Término Definición
Aplicación para la nube Las aplicaciones para la nube han sido diseñadas y desarrolladas con el único propósito de poder
funcionar en entornos de nube.
Agente de servicios de la nube Un agente de servicios de la nube es una entidad que gestiona el uso, el rendimiento y la entrega de
servicios de nube y negocia las relaciones entre los proveedores y los suscriptores de la nube. En
general, un agente de servicios de la nube puede proporcionar servicios divididos en tres categorías:
mediación del servicio, agrupación del servicio y arbitraje del servicio.1
Federación en la nube Un concepto de agrupación del servicio, caracterizado por las características de interoperabilidad,
que aborda los problemas económicos de la dependencia de un proveedor y de la integración de
proveedores.2
Proveedor de la nube Una organización que proporciona servicios de nube y cobra una tarifa a los suscriptores de la nube.
Un proveedor de la nube ofrece servicios a través de Internet. Un suscriptor de la nube podría ser su
propio proveedor de la nube, como por ejemplo, en las nubes privadas.
Agencia de normalización
de la nube
Una entidad responsable de establecer y mantener los estándares de instrumentación de la nube
contemplados en este modelo de uso.
Suscriptor de la nube Una persona u organización que ha sido autenticada en una nube y que mantiene una relación
comercial con un proveedor de la nube.
Ventana de mantenimiento Un período designado de antemano por el proveedor de la nube, durante el cual se realiza un
mantenimiento preventivo que, de no hacerse, podría provocar una interrupción del servicio.3
Objetivo de compatibilidad de
recuperación (RCO)
El RCO define una medición de la compatibilidad de los datos comerciales distribuidos después de
que ocurra un desastre u otro evento que interrumpa la continuidad del negocio.6
Objetivo de punto de recuperación
(RPO)
El período máximo tolerable en el que los datos pueden perderse en un servicio de TI debido a un
incidente importante.4
Objetivo de tiempo de
recuperación (RTO)
La duración del tiempo y un nivel de servicio dentro de los cuales un proceso comercial debe ser
restablecido, luego de una interrupción, para evitar consecuencias inaceptables.5
Aplicación tradicional Un programa o sistema que no ha sido diseñado específicamente (o remediado) para utilizar de
manera transparente las capacidades únicas de la informática en la nube.
Carga de trabajo Una imagen de máquina o una instancia de máquina virtual, junto con la información necesaria
sobre el diseño técnico (por ejemplo, cantidad de núcleos, RAM), la configuración de red y el
almacenamiento de datos directamente asociados con la máquina virtual (VM). La VM es la
abstracción de todos los elementos que constituyen la carga de trabajo.
Tabla 3.1: Términos y definiciones

Copyright © 2012 Open Data Center Alliance, Inc. TODOS LOS DERECHOS RESERVADOS
4.0 Definición de CIaaS
Para trabajar en un marco común, usamos la definición de Infraestructura como servicio que ofrece el Instituto nacional de estándares y
tecnología (NIST).
“Infraestructura como servicio (IaaS). La capacidad que se otorga al consumidor es el aprovisionamiento de procesamiento, almacenamiento,
redes y otros recursos informáticos fundamentales donde el consumidor puede implementar y ejecutar software arbitrario, que puede incluir
sistemas operativos y aplicaciones. El consumidor no gestiona ni controla la infraestructura subyacente de la nube, pero tiene control sobre
los sistemas operativos, el almacenamiento y las aplicaciones implementadas, y tiene un control posiblemente limitado de determinados
componentes de red (por ejemplo, firewalls del host)”.7
Específicamente, enfocamos el trabajo de este modelo de uso principal en un contenedor informático de la nube de uso general, que incluye las
capacidades necesarias de soporte de almacenamiento y de red para hacerlo más útil. Sin embargo, el énfasis de este modelo de uso está puesto
en las capacidades informáticas. Tal como se ilustra en el marco conceptual que se encuentra a continuación, estos cimientos nos permitirán
analizar por separado las soluciones de Infraestructura como servicio (IaaS), Plataforma como servicio (PaaS) y Software como servicio (SaaS)
de más alto nivel en áreas más elevadas de la pila. Además, si bien en este documento se abordan los requisitos de red y almacenamiento, los
requisitos específicos para los modelos de uso de almacenamiento como servicio y red como servicio serán abordados en el futuro.
Figura 4.0.1 Marco conceptual de ODCA v1.0
Rendimiento
y capacidad
Aplicaciones y SO de
entrega de software
Configuración
Evento
Seguridad
Consume/suscribe
Proporciona
Instalación
Aplicaciones para la nube
Web Base de datos
PaaS
SaaS
Interoperabilidad de servicios web y de datos
IaaS
Aplicaciones para la nube y tradicionales
Recursos
informáticos Almacenamiento Red
Espacio físico, enfriamiento, energía
Catálogodeserviciosaccionable(IUyAPI)
Procesoscomerciales
Instrumentaciónygestión
dinámicasdeservicioscompletos
Usuario
ﬁnal
Desarrollo de
aplicaciones
Operaciones
de TI
El marco conceptual de ODCA ilustrado anteriormente muestra que los servicios de CIaaS pueden ser usados tanto para aplicaciones “tradicionales”
como para aplicaciones “para la nube”. De hecho, este documento incluye escenarios de uso modelo para ambos tipos de aplicaciones. Sin
embargo, es importante que definamos primero a qué nos referimos cuando hablamos de aplicaciones tradicionales y para la nube.
• Para la nube: las aplicaciones para la nube han sido diseñadas y desarrolladas con el único propósito de poder funcionar en
entornos de nube. Se encuentran libres de las dependencias y los supuestos con los que cargan las aplicaciones tradicionales y
heredadas, y al mismo tiempo pueden explotar de manera completa las ventajas inherentes de la nube. También se han usado otros
términos para hacer referencia a estas aplicaciones, entre las que se incluyen, aplicaciones nativas de la nube, con arquitectura
para la nube, con origen en la nube o habilitadas en la nube. Sin embargo, los atributos usados para describir dichas arquitecturas
generalmente incluyen las siguientes características:8,9
ºº Capacidad de composición: las aplicaciones se distribuyen y se conectan de manera dinámica.
ºº Elasticidad: la capacidad de escalar, pero también de reducir su tamaño según la carga.
ºº Capacidad de evolución: esta característica está relacionada con la portabilidad y hace referencia a la capacidad de
reemplazar la tecnología subyacente existente o las decisiones de los proveedores con otras, a medida que cambian las
necesidades del mercado o del negocio, con un mínimo impacto en el negocio.
9

ºº Capacidad de extensión: las aplicaciones se implementan y prueban de manera gradual. Es decir, existe la posibilidad de
ampliar fácilmente la aplicación en el futuro.
ºº Granulación de mediciones y facturación
ºº Clientes múltiples: varios suscriptores de la nube pueden estar usando la misma infraestructura y los mismos recursos
subyacentes del proveedor de la nube, con confiabilidad, seguridad y rendimiento uniforme.
ºº Capacidad de portabilidad: las aplicaciones se pueden ejecutar en prácticamente cualquier lugar, con cualquier proveedor de
nube y desde cualquier dispositivo.
ºº Autoservicio
• Tradicionales: dicho de manera simple, son programas o sistemas que no han sido diseñados específicamente (o remediados)
para utilizar de manera transparente las capacidades únicas de la informática en la nube. En cambio, estas aplicaciones pueden
migrarse para ser ejecutadas en un contexto de nube, pero la materialización del valor de dichas instancias será limitada.
4.1 Alcance de CIaaS
CIaaS requiere los siguientes elementos:
• Instancias informáticas (pueden o no ser virtuales, aunque las máquinas virtuales [VM] son típicas)
• CPU y recursos de memoria
• Componentes de red
• Almacenamiento
Estos elementos serán implementados en diferentes configuraciones para cumplir con una amplia gama de capacidades y atributos de servicio.
No es nuestro objetivo definir la implementación técnica en este modelo de uso. En cambio, buscamos definir las capacidades requeridas en
términos y medidas simples.
Instrumentación
Contenedor
Servidor
Almacenamiento
Red
Instrumentación
Contenedor
Servidor
Almacenamiento
Red
Suscriptor de la nube
Agente de servicios
de la nube
Proveedor de
la nube 2
Proveedor de
la nube 1
Proveedor de
la nube 3
Instrumentación
Contenedor
Servidor
Almacenamiento
Red
Figura 4.1.1 CIaaS en contexto
10

4.2 Cargas de trabajo de CIaaS10
Genéricamente, una carga de trabajo es un encapsulamiento de lo siguiente:
• Procesos de aplicaciones
• Datos
• Información de configuración
• Estado
Esto también incluye metadatos que describen las relaciones entre estos elementos. Para los servicios de Infraestructura como servicio (IaaS), el
encapsulamiento de la carga de trabajo es generalmente la máquina virtual.
Las mejores prácticas11
indican que las descripciones y los niveles de servicios deben ser uniformes, a fin de garantizar la transparencia y
de comparar y contrastar de manera justa a los proveedores de la nube. Adicionalmente, los modelos de facturación, entre otros, deberían
ser comparables en diferentes entornos. Estos son funcionamientos prácticos y claves de la interoperabilidad de la nube. Para obtener más
información sobre este tema, consulte el Modelo de uso principal de ODCA: marco comercial12
y el Modelo de uso principal de ODCA: marco
regulatorio.13
4.3 Modelos de implementación
A menos que se especifique de otra manera, se da por sentado que los requisitos descritos en este documento se aplican a todos los posibles
modelos de adquisición e implementación en la nube:
11
Tabla 4.3.1 Modelos de nube
Modelo Definición
Nube privada La infraestructura de la nube funciona únicamente para una organización (suscriptor de la nube).
Puede ser gestionada por la organización misma (una nube privada interna de la empresa) o por un
tercero, y puede encontrarse en el sitio de la organización (nube privada interna gestionada) o en un
sitio externo (nube privada externa gestionada) (según la definición del NIST11
).
Nube de la comunidad La infraestructura de la nube se comparte entre varias organizaciones y admite una comunidad
específica o una industria vertical que tiene inquietudes compartidas (por ejemplo, la misión, los
requisitos de seguridad, la política y las cuestiones de cumplimiento). Puede ser gestionada por las
organizaciones o por un tercero y puede encontrarse dentro del sitio o fuera de este. Los miembros
pueden tener perfiles de utilización correlativos o similares (según la definición del NIST).
Nube sectorial La demanda puede estar altamente correlacionada entre los miembros de una nube de la
comunidad, y esto podría socavar su economía. Por lo tanto, una nube sectorial es una nube de la
comunidad para múltiples industrias donde los picos y caídas en la demanda pueden suavizarse,
para permitir una mayor cantidad de oportunidades de optimización.14
Nube pública La infraestructura de la nube se encuentra disponible para el público en general o para un grupo
industrial grande y es de propiedad de una organización que vende servicios de nube (según la
definición del NIST).
Nube híbrida La infraestructura de la nube se compone de dos o más nubes que se mantienen como entidades
únicas, pero que están unidas por una tecnología que permite la portabilidad de aplicaciones y datos
(por ejemplo, la recolocación de recursos en la nube pública para equilibrar la carga entre las nubes)
(según la definición del NIST).
Mercado de la nube Intercambios profesionales de servicios de nube por miembros (proveedores y suscriptores de la
nube) que acuerdan reglas comunes y también aceptan ser auditados y certificados por auditores de
nube externos para garantizar la uniformidad y calidad.

4.4 Atributos del servicio de CIaaS
Una oferta de CIaaS será definida usando los atributos de aseguramiento de servicio que figuran a continuación; la mayoría de ellos, según el
Modelo de uso de ODCA: Unidades de medida estándares para IaaS.15
Adicionalmente, incluimos 2 términos más: funcionalidad e interoperabilidad.
• Disponibilidad: el grado de tiempo de actividad para la solución, teniendo en cuenta, por ejemplo, las probabilidades de contención
de recursos.
• Rendimiento: el grado hasta el que se asegura la solución para proporcionar un nivel de salida.
• Capacidad de recuperación: los objetivos de punto de recuperación y de tiempo de recuperación de la solución.
• Seguridad: el grado de protección de la solución (por ejemplo, cifrado, tripwire, red de área local virtual o VLAN,
filtros de puertos, etc.).
• Capacidad de gestión: el grado de automatización y control disponible para gestionar la solución.
• Prioridad del SLA del cliente: el diseño de contención del servicio para manejar los picos de demanda.
• Funcionalidad: los servicios esenciales provistos por el proveedor de la nube al suscriptor de la nube.
• Interoperabilidad: el grado hasta el cual el suscriptor de la nube puede hacer todo lo siguiente:16,17
ºº Migrar cargas de trabajo de una nube a otra (incluido entre los proveedores de la nube).
ºº Vincular nubes dispares.
ºº Comparar proveedores de la nube según el costo y las capacidades.
ºº Utilizar interfaces de gestión uniformes.
Los atributos del servicio se pueden describir en términos de múltiples niveles de servicio. Específicamente, cada uno de estos atributos se
puede definir en los niveles de servicio bronce, plata, oro y platino, que se describen en la tabla a continuación. El objetivo de este modelo de
uso principal es que los niveles de servicio se puedan combinar y unir entre los distintos atributos de servicio, pero no dentro de ellos. Es decir,
es posible tener un servicio de nube con una disponibilidad de nivel bronce, pero con un rendimiento de nivel oro. Sin embargo, se deben cumplir
todos estos elementos que conforman el nivel de servicio de un atributo dado. Por ejemplo, se deben cumplir todos los subrequisitos para el
rendimiento de nivel oro para que el servicio califique como servicio de nivel oro en su rendimiento (consulte la sección 7.0 Detalles de los niveles
de servicio).
Nivel de servicio Posición Descripción
Bronce Básica Representa el requisito corporativo más bajo, equivale posiblemente a un
nivel razonablemente alto para un cliente comercial entre pequeño y mediano.
Plata Equivalente empresarial Representa una calidad más alta que el nivel bronce, y un equilibrio con
costos más altos, dentro del rango del SLA.
Oro Equivalente a sector empresarial o
mercado crítico
Representa una preferencia por una calidad de servicio superior dentro del
rango del SLA.
Platino Equivalente a seguridad crítica o
militar
Representa el requisito corporativo máximo contemplado, y llega hasta el
límite más bajo de las necesidades de seguridad crítica o militar.
Tabla 4.4.1 Atributos de los niveles de servicio
Se supone que los niveles de servicio más bajos corresponden a precios de proveedores de nube más bajos.
Los niveles de servicio se definieron específicamente usando medidas cualitativas y cuantitativas alineadas con el Modelo de uso de ODCA:
Unidades de medida estándares para IaaS.15
Nota: los niveles de servicio para la “interoperabilidad” se definen en el Modelo de uso de ODCA: Guía
para la lograr la interoperabilidad entre nubes,17
y la “funcionalidad” de CIaaS se define aquí por primera vez.
Dado el amplio rango de requisitos y capacidades de CIaaS, una buena manera de comprender los atributos de servicios específicos para CIaaS
es mediante ejemplos. Estos se presentan en una sección posterior.

4.5 Capacidades generales
CIaaS debe incluir las siguientes capacidades operativas y de gestión generales como también lo destaca el grupo de TM Forum.18
ODCA ha
extendido estos requisitos para mejorar la seguridad y adaptarlos dentro de la empresa.
Gestión de operaciones de TI:
Nota: el punto 4 que figura a continuación es un requisito de ODCA, adicional a aquellos de TM Forum.
1. El servicio debe admitir un amplio espectro de sistemas operativos x86, incluidos Windows (SO para equipos de escritorio y servidores),
Solaris x64 y Linux (distribuciones líderes) en versiones de 32 y 64 bits.
2. El servicio debe admitir controles de aislamiento de red para tráfico entrante y saliente.
3. El servicio debe admitir la implementación de componentes web, de aplicaciones, de base de datos y de servicio de infraestructura,
como los componentes del Protocolo ligero de acceso a directorios (LDAP).
4. El servicio debe alinearse con los procesos de la Biblioteca de infraestructura de tecnología de la información (ITIL) para la gestión de
configuración, incidentes y cambios.
Gestión de red:
1. El proveedor de servicios debe proporcionar opciones para la conectividad de red del consumidor, como la red privada virtual (VPN) de
Internet y líneas arrendadas. Más aún, el proveedor de servicios debe articular cualquier otra restricción, condición o requisito de red,
como la traducción de dirección de red (NAT), la superposición de direcciones IP y los controles de latencia.
2. El servicio debe incluir instrumentación para proporcionarle al consumidor un panorama del ancho de banda, el rendimiento y la
latencia. Estos deberían estar disponibles a través de las interfaces de servicio (incluida la interfaz del usuario del portal de servicios y
la interfaz de programación de aplicaciones [API]).
Gestión de seguridad:
Nota: los puntos 3 a 5 que figuran a continuación son requisitos de ODCA, que se agregan a aquellos de TM Forum.
1. El proveedor de servicios debe proporcionar arquitectura, diseño, política y otros elementos que demuestren el grado en el cual el
servicio del suscriptor de la nube es segregado de otros suscriptores. Esto se aplica a servicios de nube de un solo cliente o de clientes
múltiples.
2. El proveedor de nube deber afirmar formal y explícitamente que la seguridad de procesamiento, de la red y del almacenamiento
cumplen con los requisitos del nivel contratado por el suscriptor de la nube (bronce, plata, oro o platino). Adicionalmente, el proveedor
de la nube debe admitir una verificación independiente.
3. El suscriptor debe cumplir con los procedimientos y las políticas de seguridad implementados por el proveedor para cumplir con el nivel
de aseguramiento real de la nube.
4. En un entorno de nube gestionado, ciertos software usados por el suscriptor dentro de la nube deben integrarse con las herramientas
de monitoreo provistas en la nube que aseguran la integridad de esta. Esto incluye los software de prevención y detección de
intrusiones, registros de umbrales de acceso y más.
5. El monitoreo de las aplicaciones es controlado por los suscriptores y se puede ejecutar de manera local en la nube, y también se puede
conectar a la infraestructura de monitoreo del suscriptor. El monitoreo de la seguridad en el nivel de la aplicación es responsabilidad del
suscriptor (Nota: en tipos de servicios de valor más elevado, un firewall de aplicación puede formar parte de la oferta del proveedor).
Gestión de la carga de trabajo:
Nota: el punto 4 que figura a continuación es un requisito de ODCA, adicional a aquellos de TM Forum.
1. El servicio debe proporcionar flexibilidad de volumen y permitirle al consumidor aumentar o disminuir los recursos que se consumen.
2. El servicio debe ser capaz de integrarse con las herramientas de gestión de la nube del consumidor, de manera programada y a través
de las API estándares.
3. El servicio debe permitirle al consumidor cambiar las reglas y los parámetros de la política de carga de trabajo cuando este lo desee y
dentro de criterios específicos.
4. El servicio debe proporcionar un portal de gestión de servicios de nube.

Gestión de cumplimiento:
1. El proveedor debe aceptar, cumplir y permitir el cumplimiento de las políticas y los marcos regulatorios, las auditorías externas e
internas, las certificaciones y los estándares mínimos y la gestión de resultados. Los proveedores pueden ser sancionados en el caso
de falta de control.
2. Pueden existir requisitos procedimentales y técnicos basados en el sector del suscriptor de nube o en el país en el que este opera
o tiene clientes. Esto también puede incluir requisitos, como datos que deben permanecer en el país de origen o pruebas de
recuperación ante desastres prescriptivas o regulares. Es posible que se requiera que el suscriptor de la nube proporcione evidencia de
cumplimiento, y por lo tanto, puede necesitar la asistencia del proveedor para proporcionarla.
Gestión de problemas:
1. Cada parte debe haber establecido un análisis efectivo del origen de los incidentes, relacionado con los servicios consumidos o
contratados, para prevenir la recurrencia de impactos negativos en el servicio.
Gestión de continuidad del servicio:
Nota: el punto 2 que figura a continuación es un requisito de ODCA, adicional a los de TM Forum.
1. Cada parte debe tener procesos efectivos para garantizar que los servicios de TI puedan recuperarse y continuar, incluso, después de
que ocurran incidentes graves. Esto también incluirá la continuidad del negocio de proveedores de materiales.
2. El proveedor de la nube debe garantizar que un suscriptor de nube externo no pueda impactar en el suscriptor de la nube, como en
situaciones de “vecino ruidoso”.
Gestión de vulnerabilidad:
Nota: los puntos 2 a 4 que figuran a continuación son requisitos de ODCA, que se agregan a TM Forum.
1. El proveedor de la nube debe establecer una práctica regular para identificar, clasificar, remediar y mitigar las vulnerabilidades,
incluida la gestión de parches. Además, el proveedor debe notificar al suscriptor de la nube cualquier acción o incidente, conocido o
sospechado, que pueda poner en riesgo los activos o los datos del suscriptor de la nube a través del servicio del proveedor.
2. El proveedor de la nube trabaja estrechamente con su proveedor de servicios de Internet (ISP) y con organizaciones de seguridad
internacionales y regionales, para prevenir ataques por Internet a los clientes o a su infraestructura. El proveedor tiene un equipo
de respuesta ante riesgos y un equipo de operaciones de seguridad que se encuentran capacitados para responder rápidamente
ante ataques y para evitar que sus clientes sufran algún impacto. Más aún, para los servicios de nivel oro y platino, los Ataques
de denegación de servicio (DOS) y los Ataques distribuidos de denegación de servicio (DDOS) se contienen al filtrar los servidores
atacantes tan pronto como sea posible en la infraestructura del ISP.
3. Para los niveles de servicio plata, oro y platino, el suscriptor cuenta con un sistema de gestión de vulnerabilidades en el sitio y aplica
parches de seguridad de manera oportuna, según se define en el Modelo de uso de ODCA: Garantía del proveedor.19
4. Para los niveles de servicio oro y platino, el suscriptor realiza análisis de sus registros de aplicaciones y accesos, y comunica patrones
identificados al proveedor, para mejorar la precisión de los filtros del proveedor.
Servicio de monitoreo:
Nota: el punto 2 es un requisito de ODCA, adicional a los de TM Forum.
1. El proveedor de la nube debe monitorear el entorno, incluido los eventos, la capacidad, la seguridad y la utilización, para garantizar que
se cumplan los SLA. Los datos de monitoreo del proveedor deben proporcionarse según las API estandarizadas.
2. Si los análisis y el monitoreo de los niveles de la aplicación apuntan a la infraestructura, las estadísticas de la infraestructura deben
ser de fácil acceso y disponibilidad para realizar análisis de origen de los problemas, para resolver los problemas y para proporcionar
advertencias tempranas de los problemas que pueden llegar a ser prevenibles.
Gestión de incidentes:
1. Cada parte debe informar a la otra sobre los incidentes que pueden afectar a cada una. Se deben establecer acuerdos predefinidos
sobre la prioridad de un incidente y el nivel de esfuerzo requerido por el proveedor de la nube durante un incidente. Se deben establecer
interfaces automatizadas y estandarizadas para gestionar incidentes.

2. Tenga en cuenta que los incidentes que deben comunicarse también incluyen aquellos donde el suscriptor de la nube debe informar al
proveedor de la nube sobre incidentes que puedan afectar a otros suscriptores externos.
3. Cuando se producen incidentes más serios, tal como se acordó en un contrato entre el proveedor y el suscriptor, el proveedor de la
nube debe notificar a los clientes afectados dentro de las 48 horas.
4. Se deben acordar las respuestas ante incidentes entre ambas partes para que estas sean lo más efectivas posible. Las actividades
coordinadas ayudan a prevenir la degradación de servicios al evitar las acciones que generan conflictos.
Gestión de cambios:
1. Cada parte notificará a la otra cuando un cambio en la configuración u otro aspecto operativo pueda afectar las capacidades del
servicio de la otra parte. La gestión proactiva se requiere para garantizar un entorno estable.
Gobierno:
1. El proveedor debe cumplir y permitir el cumplimiento de las políticas y los marcos regulatorios, las auditorías externas e internas, las
certificaciones y los estándares mínimos y los controles de seguridad. Cuando no se cumplen los requisitos, se pueden establecer
sanciones y la extinción de contratos.
2. Para los niveles de servicio oro y platino, el contrato entre el subscriptor y el proveedor, por lo general, estipulará limitaciones
jurisdiccionales o geográficas de la ubicación en donde pueden almacenarse y procesarse los datos del suscriptor, incluida la ubicación
de las cintas de copias de seguridad y de los sitios secundarios.
3. Para los niveles oro y platino, el proveedor debe notificar al suscriptor de la casa matriz o de la jurisdicción legal, si tiene una casa
matriz estadounidense que se rige por la Ley Patriota de los EE. UU. (US PATRIOT ACT).
Aprovisionamiento de servicios:
1. El proveedor debe contar con mecanismos automatizados eficaces para solicitar, aprovisionar, gestionar y medir el uso de los servicios,
cuando sea posible.
4.6 Indicadores clave de rendimiento de CIaaS
Un indicador clave de rendimiento (KPI) es un término técnico de TI que se usa para hacer referencia a un tipo de medida de rendimiento. Una
manera muy común de elegir un KPI es aplicar un marco de gestión (por ejemplo, el cuadro de mando integral) y consolidar una cantidad de
perspectivas y estadísticas del SLA en un conjunto más pequeño de indicadores generales. Algunos tipos de KPI incluyen lo siguiente:20
• Indicadores cuantitativos; prácticamente cualquier elemento que sea numérico y relevante para el contrato de servicios y los
objetivos del negocio.
• Indicadores prácticos que interactúan o se alinean con los procesos empresariales.
• Indicadores direccionales que especifican si un servicio o una organización están mejorando o no.
• Los indicadores accionables son aquellos indicadores del control de una organización que son suficientes como para poder afectar
el cambio.
• Los indicadores financieros son aquellos que podrían incluir gastos, ahorros y créditos de servicio por fallas en el SLA, etc.
Los indicadores clave de rendimiento, en términos prácticos y para un desarrollo estratégico, son objetivos que deben alcanzarse y que otorgarán
más valor al negocio.
Principios de los KPI:
• Los KPI deben definir títulos o etiquetas de medidas específicas y no ambiguas.
• Los parámetros de los KPI ayudan a conformar el SLA.
• Los KPI tienen marcas de agua altas y bajas, sobre las que se establecen los SLA.
• Los KPI pueden tener varias dimensiones, y algunas de ellas se pueden compartir, como por ejemplo:
ºº La visión del suscriptor de la nube para evaluar la calidad del servicio.
ºº La visión del proveedor de la nube para gestionar los servicios generales.
ºº Una visión compartida de algunos elementos.

Los indicadores clave de rendimiento para CIaaS se corresponden estrechamente con los atributos del servicio. Se definen para proporcionar
una manera efectiva de medir el servicio. También son importantes para los suscriptores de la nube cuando realizan compras de servicios, y
para los proveedores de la nube cuando evalúan sus servicios. Los KPI deben enfocarse en una cantidad pequeña de estadísticas principales y
significativas que sean rentables y útiles.
KPI asociados con los atributos del servicio
Estos son los KPI que serán usados diariamente por los suscriptores de la nube para garantizar que el servicio se proporcione de conformidad
con los requisitos y para hacer un seguimiento de las desviaciones de la norma. Se pueden describir fácilmente, usando los elementos y niveles
de servicio deseados de las secciones “Atributos del servicio” y “Consideraciones comerciales” de este documento. Sin embargo, los temas
principales de los KPI incluyen lo siguiente:21
• Capacidad contratada y provista
• Utilización y uso de la capacidad
• Parámetros de rendimiento
• Invocación de acciones automatizadas y definidas
• Disponibilidad del servicio
• Niveles de servicio admitidos (bronce, plata, oro y platino)
• Parámetros de continuidad del servicio (RTO, RPO, RCO)
• Clasificación de datos y estadísticas de retención
• Controles de seguridad
• Informes definidos y estadísticas de auditoría
Ejemplo
KPI:
El servicio se encuentra
disponible como se espera
Puede incluir:
• Tiempo de actividad del sistema
• Tiempo de actividad de la red
• Tiempo de actividad del
almacenamiento
• Tiempo de respuesta ante incidentes
Marca de agua baja:
Nivel de aceptación mínimo
Marca de agua alta:
Logro objetivo
Logro realSLA agregado y ejecutado
KPI de valor comercial adicionales y sugeridos para suscriptores de la nube
Los suscriptores de la nube deben considerar el desarrollo de KPI internos, que pueden usarse para evaluar el valor producido por sus negocios a
partir de la adopción de CIaaS. Estos son opcionales, pero pueden incluir lo siguiente:22
• Estadísticas que miden el rendimiento del servicio de acuerdo con los planes de TI y de negocios estratégicos.
• Estadísticas sobre riesgos y cumplimiento en lo que respecta a requisitos regulatorios, de seguridad y de gobierno corporativo para
el servicio.
• Estadísticas que miden las contribuciones financieras del servicio al negocio.

5.0 Interoperabilidad
La interoperabilidad está relacionada con la portabilidad de cargas de trabajo, la interconectividad de las nubes y la capacidad de integrar
sistemas. La interoperabilidad es importante para los suscriptores de la nube porque ayuda a prevenir la dependencia de un proveedor y al
mismo tiempo garantiza la flexibilidad al suscriptor. Permite que las decisiones de servicio informático estén menos asociadas con las prioridades
del negocio. La interoperabilidad también es importante para los proveedores de la nube porque ayuda a prevenir descalificaciones por parte de
clientes potenciales que teman depender de un proveedor.
Tal como se analiza en el Modelo de uso de ODCA: Guía para la lograr la interoperabilidad entre nubes,17
existen dos aspectos clave de la
interoperabilidad: la portabilidad de las cargas de trabajo y la interconectividad de sistemas. Cada uno de estos aspectos tiene su propio conjunto
de requisitos únicos.
• La portabilidad debe ser desencadenada según sea necesario, como un evento, que incluya el mantenimiento del acceso a los
datos y el control de la carga de trabajo, y que permita una configuración y reconfiguración dinámicas.
• La interconectividad aborda la necesidad de que las aplicaciones y los servicios establezcan y preserven de manera continua,
conexiones complejas entre diferentes sistemas.
6.0 Impulsores del negocio y escenarios de uso
El objetivo de este modelo de uso principal no es definir en detalle lo que los proveedores de servicios proporcionan en términos de arquitectura
técnica precisa. Algunos consumidores desean que los proveedores proporcionen una infraestructura de nivel “empresarial”, es decir, una
infraestructura informática que pueda reemplazar una infraestructura interna gestionada y provista por una empresa y que pueda usarse de
manera intercambiable. Sin embargo, las economías y los beneficios reales del modelo de nube provienen de enfoques donde las aplicaciones
están diseñadas y desarrolladas desde la base para aprovechar los servicios comunes de productos disponibles a través de múltiples
proveedores. Existen dos enfoques para tener en cuenta: ¿debería la nube adaptarse a los requisitos de la empresa heredados, como en el caso
de las aplicaciones tradicionales, o debería la empresa adaptarse a la nube, como en el caso de las aplicaciones para nubes?
La respuesta es ambas. Las grandes empresas tienen respectivamente grandes carteras de aplicaciones, muchas de las cuales han sido
diseñadas e implementadas dentro de entornos informáticos distribuidos tradicionales. Estas empresas no tienen ni el deseo ni la justificación
económica para refactorizar su propiedad entera de aplicaciones para aprovechar de manera óptima el modelo de entrega de la nube. Con el
tiempo, se puede esperar que las empresas se adapten al modelo de entrega de la nube. Sin embargo, esto será un viaje extenso. Existe una
oportunidad para que los proveedores de servicios ofrezcan una amplia gama de capacidades y niveles de servicios, que abarca desde una
infraestructura informática de “nivel empresarial” a una capacidad de consumo completamente masivo.
Garantizar que los proveedores de servicios ofrezcan entornos, servicios y herramientas asociadas que permitan a las empresas funcionar de
manera efectiva y eficiente en estos entornos híbridos será la clave, ya que la penetración de la informática en la nube aumenta y las empresas
también continúan aprovechando al máximo sus inversiones existentes.
6.1 Escenarios de USO comercial
En esta sección, proponemos algunos ejemplos de escenarios de uso comercial para la implementación de CIaaS. Para cada uno, presentamos
los atributos generales del servicio de los escenarios de uso. Estos atributos generales están elaborados de manera más detallada en otra parte
de este documento. Para obtener información más detallada, consulte las secciones “Arquitectura técnica” y “Niveles de servicio”.
Los escenarios de uso contemplados aquí no tienen como objetivo ser exhaustivos, sino más bien, ser representativos de los tipos de problemas
comerciales para los que los servicios de CIaaS son apropiados. Existen otras innumerables combinaciones posibles de requisitos. El marco de
CIaaS propuesto por este modelo de uso principal deber permitir al lector describir de manera similar otros escenarios de uso.
KPI de relación adicionales y sugeridos para proveedores de la nube
A continuación figuran algunos KPI sugeridos, a los que los proveedores de la nube deben realizarles seguimientos para garantizar la satisfacción
de los clientes y para evaluar los servicios en comparación con sus pares.22
De ser posible, los proveedores de la nube también deben mantener
un diálogo abierto y continuo con los suscriptores de la nube empresarial, en lo que respecta a los KPI de "valor comercial" que se mencionaron
anteriormente. Estos son opcionales, pero pueden incluir lo siguiente:
• Estadísticas que monitorean los procesos claves de TI que soportan el servicio.
• Estadísticas que miden la satisfacción del cliente.

Figura 6.1.1 Escenarios de uso modelo de CIaaS
Escenarios
de uso
de CIaaS
Producción
No relacionado
con la producción
Desarrollo
estratégico
Pruebas
y desarrollos
ad hoc
Control de
calidad
Base Variable
Independiente Empresarial EmpresarialDistribución
Tradicional Para la nube
Desarrollo/
prueba
Prueba
de carga
Tradicional Para la nube
Por momentos, también haremos referencia a los entornos de nubes híbridas. Existe un requisito para que los profesionales de operaciones de
TI puedan gestionar y medir la ejecución de sistemas detrás del firewall e informar sobre ella, de manera uniforme y compatible con los sistemas
de la nube, ya sean tradicionales o para la nube. El sector puede y debe proporcionar esta capacidad para que los suscriptores de la nube puedan
funcionar en entornos híbridos.
Tenga en cuenta que los escenarios de uso que figuran a continuación no diferencian entre los escenarios internos que usan los empleados y los
escenarios externos que usan los clientes o el público. Sin embargo, es razonable asumir que cuando se indican niveles de servicios de atributos
múltiples, los requisitos que usan los clientes y el público excederán, con frecuencia, a aquellos escenarios internos que usan los empleados. La
criticidad del negocio también se indica para cada ejemplo.
La mayoría de los escenarios de uso que figuran a continuación se mencionan y se expanden en escenarios previamente documentados por el
grupo Enterprise Cloud Leadership Council (ECLC) de TM Forum.
Para los escenarios de uso de producción que se incluyen a continuación, la prioridad del SLA del cliente surgió como resultado de los siguientes
supuestos de escenarios:
• Para eventos y solicitudes de prioridad alta, tal como se acordó entre el proveedor y el suscriptor de la nube.
• Tiempo de respuesta: bronce, 4 horas; plata, 1 hora; oro, 10 minutos; platino, de manera inmediata o instantánea.
A continuación, presentamos un simple diagrama que ilustra la jerarquía de escenarios de uso descritos en este modelo de uso. Las aplicaciones
tradicionales y para la nube se describen en otra parte.

6.2 Desarrollo/Prueba
Esta es una subclase de uso de CIaaS no relacionado con la producción. Para este ejemplo, suponemos cargas de trabajo tradicionales o que no
sean para la nube. A continuación presentamos la descripción del ECLC:
Este es uno de los escenarios de uso más obvios y accesibles para CIaaS, ya que los entornos de prueba y desarrollo son típicamente
temporales y desechables. Al adoptar CIaaS para las tareas de desarrollo y prueba, los entornos pueden segregarse, o aislarse de manera
lógica, más fácilmente de la producción; lo que ayuda a eliminar interdependencias y consecuencias negativas que deriven de interacciones
inadvertidas con los sistemas de producción. Estos entornos también pueden proporcionarse e implementarse mucho más rápido que lo que
sería factible con sistemas físicos, lo que permite mejorar la agilidad del negocio y el tiempo de salida al mercado.
Los requisitos para las tareas de desarrollo y prueba en la nube pueden dividirse aún más en otras tres subclases: desarrollo estratégico,
pruebas y desarrollos ad hoc y control de calidad.
• Desarrollo estratégico: grandes esfuerzos de desarrollo de software a largo plazo, esenciales para el negocio del suscriptor
de la nube.
• Pruebas y desarrollos ad hoc: desarrollo de software informal, experimental y a corto plazo que no es esencial para el negocio del
suscriptor de la nube.
• Control de calidad: las pruebas formales de software por parte del suscriptor de la nube, como parte del control de calidad, la
integración de sistemas u otras pruebas de software formales similares que son esenciales para el negocio del suscriptor de la
nube. Esto requerirá una mayor uniformidad de rendimiento y resistencia por parte del servicio de nube.
Tabla 6.2.1. Requisitos para el desarrollo y las pruebas
19
Requisito
(O: opcional; N: necesario)
Desarrollo estratégico Pruebas y desarrollos
ad hoc
Control de calidad
Criticidad del negocio Baja o media Baja Baja o media
Atributo del servicio Nivel Nivel Nivel
Disponibilidad Bronce o plata Bronce Bronce o plata
Rendimiento Bronce Bronce Bronce o plata
Capacidad de recuperación Bronce o plata Bronce Bronce o plata
Seguridad Plata u oro Plata Plata u oro
Elasticidad Bronce Bronce Bronce
Capacidad de gestión Plata Bronce o plata Plata
Prioridad del SLA del cliente Bronce Bronce Bronce
Interoperabilidad Plata Bronce Plata

6.3 Entorno de prueba de tensión de carga
Esta también es una subclase de uso de CIaaS no relacionado con la producción. Para este ejemplo, suponemos cargas de trabajo tradicionales o
que no sean para la nube. De la descripción del ECLC sobre el escenario de uso con el mismo nombre:
“Este escenario de uso emerge como un habilitador clave para los negocios en línea y para otros negocios que requieren un escalamiento
masivo. Como una extensión de las tareas de desarrollo y prueba, la prueba de carga es un dominio especializado que puede usarse para
detectar debilidades algorítmicas que solo surgen en sistemas a escala. Si bien una aplicación puede funcionar según lo esperado, ya sea como
una unidad simple o como parte de un clúster pequeño, al duplicar o aumentar de manera exponencial la cantidad de nodos de procesamiento
pueden producirse resultados inesperados. CIaaS le permite al desarrollador simular este escalamiento, usando un recurso externo o interno
compartido que elimina el gasto de capital que se requeriría para proporcionar la capacidad necesaria para los niveles de carga hipotéticos.
Además, los sistemas cliente-servidor pueden beneficiarse de la nube al aprovechar la capacidad de CIaaS de simular grandes cantidades de
clientes para aumentar la carga en sus servidores”.
Asimismo, ahora existen medios por los cuales las secuencias de comandos de prueba reflejan patrones de transacciones de usuarios reales que
ocurren de manera simultánea y que provocan una tensión en los servicios subyacentes de IaaS de diferentes maneras. Las pruebas de tensión
de carga deben incorporar patrones de uso de usuarios reales a partir de sistemas de monitoreo de usuarios reales para implementar estas
pruebas.
Tabla 6.3.1. Prueba de tensión de carga
20
Requisito
Prueba de tensión de carga
Criticidad del negocio Baja
Atributo del servicio Nivel
Disponibilidad Bronce
Rendimiento Oro (la fidelidad con el entorno de producción
objetivo es un factor clave)
Capacidad de recuperación Bronce
Seguridad Bronce o plata
Elasticidad Plata u oro
Capacidad de gestión Plata
Prioridad del SLA del cliente Bronce
Interoperabilidad Bronce

6.4 Informática distribuida y de alto rendimiento
Las aplicaciones de Informática distribuida y de alto rendimiento (HPC) pueden ser tradicionales o para la nube. Debido a su patrón informático
distribuido, paralelo o inherente, las aplicaciones distribuidas generalmente se ajustan bien a las arquitecturas de nube. Para este ejemplo,
suponemos que la aplicación distribuida es una aplicación para la nube. Sin embargo, un sistema distribuido, tradicional y que no sea para la
nube no debe tener requisitos substancialmente diferentes.
De la descripción del ECLC para las aplicaciones de informática distribuida:
“Si bien la informática distribuida antecede a la informática en la nube, la nube se puede usar para optimizar los modelos de uso basados en
la distribución. Teniendo en cuenta que la informática clásica distribuida se almacenaba tradicionalmente en una granja estática de servidores
informáticos físicos, CIaaS ofrece una gestión dinámica de capacidad, que permite que la distribución lógica se expanda y contraiga según la
demanda del negocio y los costos o beneficios marginales, para habilitar nodos de procesamiento paralelos adicionales”.
Los requisitos para la informática distribuida y de alto rendimiento en la nube pueden dividirse aún más en otras dos subclases: capacidad de
distribución base y distribución variable.
Tabla 6.4.1. Requisitos para la informática distribuida y de alto rendimiento
Requisito
Capacidad de distribución
base
Capacidad de distribución
variable
Criticidad del negocio Alta Media o alta
Atributo del servicio Nivel Nivel
Disponibilidad Oro o platino Bronce
Rendimiento* De bronce a oro De bronce a oro
Capacidad de recuperación Bronce Bronce
Seguridad Oro o platino Oro o platino
Elasticidad Bronce Oro o platino
Capacidad de gestión Plata Plata
Prioridad del SLA del cliente Oro o platino Bronce
Interoperabilidad Plata u oro Plata u oro
Supuestos adicionales:
En los dos subtipos de escenario de uso mencionados anteriormente, suponemos explícitamente que en el modelo operativo, el suscriptor de la
nube realiza su propia gestión y soporte desde el sistema operativo.
Ambos subtipos de escenarios de uso suponen cargas de trabajo de producción empresariales.
*Tenga en cuenta que el rendimiento puede ser tan bajo como de nivel bronce para las distribuciones de economías de bajo costo, según los requisitos
del suscriptor de la nube y la sensibilidad del precio.

6.5 Entorno de producción independiente tradicional
Este entorno puede ser pensado como una implementación monolítica. Es un subtipo de las cargas de trabajo tradicionales o heredadas,
migradas a la nube. Por ejemplo, una aplicación de producción de un equipo o departamento que es importante, pero no esencial para las
operaciones diarias del negocio. La descripción del ECLC para una producción independiente es adecuada.
“Las aplicaciones con dependencias externas mínimas pueden ejecutarse más o menos aisladas de los entornos corporativos. Si bien se puede
requerir una solución puente para integrarlas con servicios de identidades u otros servicios de directorios, o para conectarlas a otros flujos
de trabajo del negocio, estas aplicaciones pueden funcionar bien en cualquier ubicación. Estos tipos de aplicaciones pueden ser adecuadas
para implementarse en un entorno de CIaaS, ya que esto les permitiría beneficiarse de la migración o la extensión hacia otras ubicaciones
geográficas para mejorar la productividad o los costos (estrategias follow-the-moon/follow-the-sun [seguir la luna/seguir el sol])”.
Este es un tipo específico de requisito de producción. Sin embargo, como sucede con otros escenarios de producción empresarial, el servicio, en
este caso, es considerado como esencial para la misión. La pérdida del servicio informático tendrá impactos materiales negativos en el suscriptor
de la nube, como una pérdida de ingresos o daño a la reputación.
Los entornos de producción independientes tienen como objetivo la cobertura de aplicaciones de grupos o departamentos que son consideradas
de producción a los fines del soporte y la recuperación, pero tienen un impacto limitado en el negocio. Ejemplos de estos entornos son los
servidores de archivos internos, los servidores web y los sitios de colaboración. La pérdida de estos servicios se considera un inconveniente más
que una interrupción a las operaciones del negocio y las soluciones manuales, si bien son posibles, son poco deseadas.
Tabla 6.5.1 Producción independiente habilitada para la nube
Requisito
Producción independiente
habilitada para la nube
Criticidad del negocio De baja a media
Disponibilidad Plata o superior
Rendimiento Plata o superior
Capacidad de recuperación Plata o superior
Seguridad Plata o superior
Elasticidad Bronce
Capacidad de gestión Plata
Prioridad del SLA del cliente Plata

6.6 Entorno de producción empresarial tradicional
Estos entornos son, en general, sistemas informáticos distribuidos heredados que se han migrado a la nube, pero que no han sido
completamente remediados como para formar parte de la nube. Esta es una subclase de uso de producción.
Las aplicaciones empresariales difieren de las aplicaciones de producción independientes en su alcance e importancia para la organización.
Estas son aplicaciones esenciales para la misión que afectan la reputación y el flujo de ingresos de una organización. La pérdida del entorno de
producción empresarial tendría como resultado una pérdida significativa de ingresos o daño a la reputación del suscriptor. Ejemplos de estos
son los sistemas de transacciones de grandes volúmenes (Planificación de recursos empresariales, ERP), los sitios web de clientes, los sitios de
integración de socios y los sistemas de procesamiento de datos financieros donde las opciones de procesamiento manual no son posibles debido
al volumen o a la naturaleza de las transacciones.
Estas aplicaciones tienen dependencias externas y requisitos de integración. Es posible que se requieran soluciones puente para integrarlas
con servicios de identidades u otros servicios de directorios, o para conectarlas a otros flujos de trabajo del negocio. Es posible que no puedan
explotar completamente la elasticidad de la nube. En comparación con las aplicaciones “independientes”, estas aplicaciones son más grandes
y más complejas y, posiblemente, no sean adecuadas para la migración de una ubicación geográfica a otra, debido al tamaño o volumen de los
datos requeridos.
Tabla 6.6.1 Producción empresarial tradicional
Requisito
Producción empresarial
tradicional
Criticidad del negocio De media a alta
Disponibilidad Oro o platino
Rendimiento Oro o platino
Capacidad de recuperación Oro o platino
Seguridad Oro o platino
Elasticidad Bronce o plata
Capacidad de gestión Oro
Prioridad del SLA del cliente Oro o platino
Interoperabilidad Plata u oro

6.7 Entorno de producción empresarial para la nube
Este entorno puede ser considerado como un conjunto de sistemas informáticos que, aunque no están basados completamente en PaaS, han
sido diseñados para la nube desde el comienzo. Estos sistemas pueden incluir aplicaciones web más nuevas, pueden aprovechar una mayor
automatización y pueden consultarle al servidor de la infraestructura sobre la capacidad disponible, los servicios y demás. Esta es una subclase
de uso de producción.
Las aplicaciones para la infraestructura son aplicaciones más nuevas desarrolladas para tolerar las fallas de los componentes subyacentes
de la infraestructura. Estas aplicaciones usan los servicios de los proveedores de infraestructura para recuperarse de las interrupciones
de funcionamiento de los componentes o pueden escalarse según sea necesario para afrontar las demandas de carga de trabajo de las
aplicaciones. Al igual que con la variante de la informática distribuida tradicional, la pérdida de la aplicación de producción daría como resultado
una pérdida significativa de ingresos o daño a la reputación del suscriptor. La diferencia es que la aplicación tiene una arquitectura para ser
ejecutada en una infraestructura con un nivel más bajo de servicio, confiabilidad y disponibilidad. Estas aplicaciones también pueden distribuirse
en los recursos de múltiples proveedores.
Estas aplicaciones tienen dependencias internas y externas, y requisitos de integración.
Tabla 6.7.1 Producción empresarial para la nube
Requisito
Producción empresarial para
la nube
Criticidad del negocio Media o alta
Disponibilidad Plata o superior
Rendimiento Bronce o superior
Capacidad de recuperación Oro o platino
Seguridad Oro o platino
Elasticidad Oro o platino
Capacidad de gestión Oro o platino
Prioridad del SLA del cliente Oro o platino
Interoperabilidad Oro o platino
6.8 Gestión de servicios y federación en la nube
La gestión de servicios y la federación en la nube son una parte importante del ecosistema de la nube y serán abordados en una actualización
futura del Modelo de uso principal de ODCA: Infraestructura informática como servicio (CIaaS).

7.2.1 Resumen de los niveles de servicio: disponibilidad
Elementos Bronce Plata Oro Platino
Disponibilidad general 99 % 99.9 % 99.9 % 99.99 %
Ventana de mantenimiento Fija Fija Flexible Flexible
Frecuencia de interrupciones no planificadas y permisibles* 2 1 0 0
RTO por incidente** 60 min 30 min 0 min 0 min
Duración de las interrupciones objetivo no planificadas
y acumuladas
120 min 30 min 0 min 0 min
Interrupciones de conectividad a Internet,
no planificadas y permisibles
3 2 0 o 1 0
Sanción por violación del SLA Ninguna Sí Sí Sí
*Cantidad de interrupciones dentro de una ventana de tiempo especificada y alineada con períodos de facturación. Todos los créditos
por sanción existentes se aplicarán al ciclo de facturación correspondiente. El objetivo aquí es abordar comportamientos intermitentes o
temporales, donde las interrupciones y las interferencias sean muy breves, pero puedan impactar materialmente en el rendimiento de la
carga de trabajo o la calidad del servicio.
**Tiempo total de duración por incidente de interrupción
7.0 Detalles de los atributos del servicio
Cada uno de los atributos del servicio presentados anteriormente se explica con más detalle a continuación. Cada atributo se subdivide en uno o
más elementos. Juntos, los valores de los elementos determinan el nivel de servicio de ese atributo. Se deben cumplir todos los elementos que
conforman el nivel de servicio de un atributo dado. Por ejemplo, deben cumplirse todos los subrequisitos para el rendimiento de nivel oro para que
el rendimiento se considere en el nivel de servicio oro. Los siguientes supuestos rigen para cada sección de atributos del servicio a continuación:
Estandarización: los servicios del proveedor de la nube son uniformes y estandarizados.
Se encuentra disponible la documentación.
7.1 Funcionalidad
La infraestructura debe admitir servicios de nube básicos y funcionales, según la definición del NIST. El proveedor debe admitir al menos la
versión n.º 1 de la última actualización de los estándares de servicios de nube actuales y futuros, que se encuentran especificados aquí o que
son proporcionados como respuesta a los requisitos de ODCA por las Organizaciones de desarrollo de estándares (SDO).
7.2 DISPONIBILIDAD
En el Modelo de uso de ODCA: Unidades de medida estándares para IaaS,15
ODCA ha definido la disponibilidad como el grado de tiempo de
actividad para la solución, teniendo en cuenta, por ejemplo, las probabilidades de contención de recursos. Esto debe entenderse como un
servicio general en su totalidad. Existen algunos aspectos generales que se deben abordar con respecto a la disponibilidad de CIaaS. El alcance
de la disponibilidad de CIaaS incluye lo siguiente:
• Cantidad de disponibilidad general, por ejemplo el número de nueves.
• Conexión desde los Puntos de presencia (POP) o puntos de conexión de Internet del proveedor.
• La manera en que se definen las ventanas de mantenimiento, por ejemplo, de manera fija si lo elige el proveedor de la nube o de
manera flexible si lo elige el suscriptor de la nube.
• La posibilidad de definir “ventanas de tiempo críticas” estaría disponible en las versiones flexibles.
• Tenga en cuenta que las ventanas de mantenimiento planeadas y acordadas por contrato no cuentan para los objetivos de
disponibilidad.
• La duración de la interrupción objetivo en oposición a la cantidad de interrupciones. Algunas cargas de trabajo pueden manejar
de mejor manera las interrupciones cortas, incluso aunque existan muchas. Otras cargas necesitan tener la menor cantidad de
interrupciones posibles, lo que genera un tiempo de inactividad más largo para cada una de ellas.
• Existencia de sanciones especificadas por contrato e impuestas en caso de violación del SLA, como se muestra en la tabla a
continuación.

7.3 Capacidad de recuperación
ODCA ha definido la capacidad de recuperación como los objetivos de tiempo de recuperación y punto de recuperación de la solución.15
Esto debe
entenderse para la recuperación del servicio general en su totalidad. Existen algunos aspectos generales que se deben abordar con respecto a la
capacidad de recuperación de CIaaS. El alcance de la capacidad de recuperación de CIaaS incluye lo siguiente:
• Copias de seguridad y restauración con o sin revisiones graduales
• Tiempo medio para la recuperación
• Cantidad o frecuencia de puntos de recuperación
7.3.1 Resumen de los niveles de servicio: capacidad de recuperación
Elementos
Bronce Plata Oro Platino
Copia de seguridad de los
datos
Sin copia de
seguridad
Una copia Dos copias Tres copias
Dispersión geográfica de
las copias de seguridad de
los datos
Ninguna Un sitio Dos sitios Tres sitios y fuera del sitio
RTO para la restauración de
datos
N/C Dentro de las
doce horas de la
restauración del
servicio
Dentro de las nueve
horas de la restauración
del servicio
Dentro de las seis horas
de la restauración del
servicio
Replicación de datos Ninguna Ninguna Instantánea, al menos
cuatro veces al día
Sincrónica y asincrónica a
sitios remotos
Frecuencia de la copia de
seguridad
N/C Semanal, completa Diaria, gradual;
semanal, completa
Diaria, completa
RTO para la restauración de
instancias informáticas
Responsabilidad
del suscriptor
60 minutos 15 minutos 10 minutos
RCO para datos distribuidos Ninguno 80 % 90 % 100 %

7.4 Seguridad
ODCA ha definido a la seguridad como el alcance de la protección del proveedor de la nube o de la solución de la nube. A continuación se
encuentra el detalle de los elementos de seguridad que se deben abordar:
• Antivirus y protección contra malware (con actualizaciones de definiciones dentro de las 24 horas)
• Existe un proceso de gestión de vulnerabilidades y está completamente probado para garantizar que no haya ningún impacto en los
host objetivo
• Aislamiento de red y firewall de los sistemas del suscriptor de la nube
• Control de acceso físico al centro de datos de la nube
• Protocolos de seguridad usados para la administración remota (por ejemplo, SSL, SSH y RDP)
• Se eliminan todas las contraseñas predeterminadas y el acceso de invitado
• Uso de Acuerdos de confidencialidad (NDA) para el personal del proveedor de la nube
• Uso de los procesos de la Biblioteca de infraestructura de tecnología de la información (ITIL) para la gestión de configuración,
incidentes y cambios
• Gestión de identidades para los activos del suscriptor
• Retención y eliminación gestionadas de los datos
• Monitoreo de eventos e incidentes de seguridad
• Prevención de intrusiones en la red
• Registro de todos los eventos en el ámbito de la administración (requiere acceso controlado a los registros)
• Principio de supervisión doble (Four-eye principle) para los cambios claves del administrador
• El proveedor de la nube tiene un plan de continuidad técnica implementado y probado
• Red controlada y documentada por completo
• Opción para realizar pruebas de penetración en sistemas hospedados
• Segmentación física de hardware (servidor, almacenamiento, red, etc.) para garantizar el aislamiento de todos los otros sistemas
• Comunicación cifrada entre el proveedor y el suscriptor de la nube para la gestión
• Autenticación de varios factores
• Capacidad del suscriptor de la nube de definir límites geográficos para el hospedaje
• Cifrado del almacenamiento en el nivel de número de unidad lógica (LUN)
• Sin acceso administrativo para el personal del proveedor de la nube
• Cifrado de alta seguridad para todos los datos al vuelo y en reposo

7.4.1 Resumen de los niveles de servicio: seguridad
Elementos (O: opcional; N: necesario) Bronce Plata Oro Platino
Antivirus y protección contra malware con actualizaciones de definiciones dentro
de las 24 horas
N N N N
Existe un proceso de gestión de vulnerabilidades y se pone a prueba completamente para
garantizar que no haya ningún impacto en los host objetivo
N N N N
Aislamiento de red y firewall de los sistemas del suscriptor de la nube N N N N
Control de acceso físico al centro de datos de la nube N N N N
Protocolos de seguridad usados para la administración remota
(por ejemplo, SSL, SSH y RDP)
N N N N
Se eliminan todas las contraseñas predeterminadas y el acceso de invitado N N N N
Uso de Acuerdos de confidencialidad (NDA) para el personal del proveedor de la nube N N N N
Uso de los procesos de la Biblioteca de infraestructura de tecnología de la información
(ITIL) para la gestión de configuración, incidentes y cambios
N N N N
Gestión de identidades para los activos del suscriptor (Consulte el Modelo de uso principal
de ODCA: Guía de interoperabilidad para la gestión de identidades)
N N N N
Retención y eliminación gestionadas de los datos N N N N
Monitoreo de eventos e incidentes de seguridad N N N N
Prevención de intrusiones en la red O N N N
Registro de todos los eventos en el ámbito de la administración (requiere acceso
controlado a los registros)
O N N N
Principio de supervisión doble (Four-eye principle) para los cambios claves del
administrador
O N N N
El proveedor de la nube tiene un plan de continuidad técnica implementado y probado O N N N
Red controlada y documentada por completo O N N N
Opción para realizar pruebas de penetración en sistemas hospedados O O N N
Segmentación física de hardware (servidor, almacenamiento, red, etc.) para garantizar el
aislamiento de todos los otros sistemas
O O N N
Comunicación cifrada entre el proveedor y el suscriptor de la nube para la gestión O O N N
Autenticación de varios factores de la nube para el acceso administrativo del proveedor N N N N
Oferta de capacidad de autenticación de varios factores para la nube para el acceso
administrativo del suscriptor
O O N N
Capacidad del suscriptor de la nube de definir límites geográficos para el hospedaje O O N N
Cifrado del almacenamiento en el nivel de número de unidad lógica (LUN) O O N N
Sin acceso administrativo para la nube para el personal del proveedor O O O N
Cifrado de alta seguridad para todos los datos al vuelo y en reposo O O O N

7.5 Elasticidad
ODCA define la elasticidad como la capacidad de configuración y expansión de la solución (coincide con la taxonomía según el NIST7,23
).
Básicamente, es la capacidad de escalar y reducir la capacidad según la carga de trabajo del suscriptor. Existen algunos aspectos generales que
se deben abordar con respecto a la elasticidad de CIaaS.
El alcance de la elasticidad de CIaaS incluye lo siguiente:
• Capacidad para escalar y reducir el tamaño
• La definición de una o más políticas que controlan cómo debe ser escalada la aplicación del suscriptor de la nube
• Capacidad de respuesta, como la velocidad del escalamiento dinámico
• Configuración de clones
• Configuración del entorno, como los elementos de seguridad y de red
• Ejecución de tareas adicionales desencadenadas
• Proporción posible, hasta X veces la cantidad inicial de instancias
• Capacidad de automatización, a través de una API
• Notificación
• Manejo de excepciones
Niveles de servicio
La capacidad de escalar depende de los recursos informáticos, la red, la cuota de almacenamiento y el plazo de arrendamiento.
Aumento (capacidad de respuesta e índice de aumento)
• Tanto los suscriptores como los proveedores tienen la responsabilidad de planificar en función de las necesidades de capacidad y
de predecir respectivamente, pero el enfoque, por supuesto, se centra en las responsabilidades del proveedor.
• Un área que se podría considerar para la diferenciación potencial del proveedor es la forma de arbitrar la contención del suscriptor.
Es decir, ¿qué sucedería si varios clientes compiten por una cantidad limitada de recursos? ¿Quién debería poder obtener los
recursos? ¿Deberían considerarse otras cuestiones económicas de mercado? ¿Quizás quienes pagan por los niveles oro o platino
tienen prioridad?
• Los proveedores de la nube tienen oportunidades adicionales para la diferenciación a través de una combinación de opciones, como
por ejemplo:

7.5.1 Resumen de los niveles de servicio: elasticidad
Elementos Bronce Plata Oro Platino
Admite escalamiento
horizontal
Sí o no Sí Sí Sí
Admite escalamiento vertical Sí o no Sí o no Sí o no Sí o no
Capacidad de automatización
a través de una API
Sí o no Sí Sí Sí
Crecimiento (escalamiento
horizontal)
=10 % =10 % 25 % dentro de las 2 horas
50 % dentro de las 24 horas
100 % dentro de las 2 horas
1000 % dentro del mes
Capacidad de respuesta Dentro de los cinco
días hábiles
Dentro del día
hábil
Del 300 al 1000 % dentro
del mes
7.6 Servicios de capacidad de gestión
ODCA define la capacidad de gestión como el grado de automatización y disponibilidad de control para gestionar la solución. Existen algunos
aspectos generales que se deben abordar con respecto a la capacidad de gestión de CIaaS. Tenga en cuenta que esta sección aborda la gestión
de las diferentes características del servicio que figuran a continuación y no las características en sí mismas.
El alcance de la capacidad de gestión de CIaaS incluye lo siguiente:
Monitoreo del rendimiento, los eventos y la disponibilidad de:
• infraestructura
ºº recursos informáticos
ºº almacenamiento
ºº red
• máquinas virtuales, cuando se usan
• regiones y zonas de disponibilidad
• aplicaciones y los servicios
• correcciones
Esto abarca la gestión del comportamiento automatizado, desencadenado por los problemas en los servicios de nube, como las secuencias de
comandos que se ejecutan en respuesta a una pérdida de paquetes inaceptablemente alta o a una recolocación automática de la capacidad en la
nube pública si la utilización impacta en el umbral designado. Para ser claros, esto no incluye la funcionalidad de corrección dada, sino que solo
incluye la gestión de dicha funcionalidad.
• Tareas programadas y automatizadas
• Escalamiento automatizado (elasticidad de demanda y suministro)
• Autorecuperación de aplicaciones y servicios

Odca compute iaa_s_masterum_es

Odca compute iaa_s_masterum_es

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Similar a Odca compute iaa_s_masterum_es

Similar a Odca compute iaa_s_masterum_es (20)

Último

Último (20)

Odca compute iaa_s_masterum_es