Facultad de Ingeniería

Escuela de Ingeniería de Sistemas y Computación

Carrera de Ingeniería de Sistemas de Información

ARQUITECTURA TECNOLOGICA DISTRIBUIDA, DE ALTA

DISPONIBILIDAD Y ESCALABLE QUE SOPORTE UNA RED
SOCIAL DE 1 MILLON DE USUARIOS

Autores:
U201220093 – Herdin Hiram Ríos Carbajal
U201220093 – Marco Quispe Rengifo
U201220093 – Ivette Ramírez Salazar

Lima, Junio 2018

 CAPITULO 1 DESCRIPCIÓN DEL PROYECTO

En este capítulo se explica la importancia del desarrollo de una Arquitectura tecnológica

que soporte una red social de 100 millones de usuarios. Además, se plantea la
problemática, el objetivo general, los objetivos específicos, los indicadores de éxito y los
riesgos que implica el desarrollo del proyecto. Por último, se detallarán los planes
elaborados para la gestión del proyecto.
 1. Objeto de Estudio

En el contexto actual, el objeto de estudio se enfoca en desarrollar la arquitectura

tecnológica distribuida que permite la alta disponibilidad y escalabilidad a las
grandes redes sociales (Facebook, Twitter, Amazon, gmail).

2. Dominio del Problema

Problema Causas

La información de cómo está construida la arquitectura Información descentralizada sobre la

física y lógica, además de los servicios que utilizan las mejor manera de implementar una
redes sociales de más de 50 millones de usuarios, no se arquitectura que sea de alta
encuentra compartida de manera pública, ante cualquier disponibilidad, escalable y que pueda
iniciativa de desarrollo e implementación de alguna red soportar una gran cantidad de
social. usuarios conectados.

Tabla 1: Problemática y Causa

Fuente: Elaboración propia

3. Planteamiento de la Solución

La solución que el proyecto plantea es la definición, características, licenciamiento

y precios de los servicios; así como el desarrollo de las arquitecturas y la realización
de las pruebas de conceptos de los mismos. Esta investigación tiene como
resultado final proponer un plan de continuidad para que la Arquitectura pueda ser
utilizada por cualquier persona u organización con una iniciativa.
4. Objetivos del Proyecto
4.1. Objetivo General

OG: Implementar una arquitectura tecnológica que permita desplegar una red social
mundial que soporte la información e interacciones de más de 100 millones de
usuarios.

4.2. Objetivos Específicos

OE1: Analizar las funcionalidades y arquitecturas tecnológicas de las redes sociales

que tenga una cantidad de usuarios mayor a 50M.

OE2: Diseñar la arquitectura tecnológica escalable y de alta disponibilidad

propuesta para la implementación de una red social.

OE3: Validar el modelo tecnológico mediante pruebas de concepto.

OE4: Elaborar un plan de continuidad que permita administrar y realizar el

mantenimiento de los servicios implementados.

5. Indicadores de Éxito

Los indicadores de éxito planteados para este proyecto se utilizarán para medir el
logro de cada uno de los objetivos se muestra

A continuación, en la Tabla 2 se muestran los indicadores de éxito definidos para

cada objetivo específico.

Indicador Objetivo
Indicador de Éxito
de éxito Específico

Aprobación por parte del cliente de la información y

IE1 OE1
metodologías analizadas.

Aprobación por parte del cliente el diseño de la

IE2 OE2
arquitectura.

Aprobación por 3 expertos la prueba funcional

IE3 OE3
presentada.

Aprobación por parte del cliente el plan de continuidad

IE4 OE4
de la Arquitectura

Tabla 2: Indicadores de éxito del Proyecto

Fuente: Elaboración propia

6. Planificación del Proyecto

1.6.1 Alcance

El proyecto considerará lo siguiente:

● Investigación sobre la infraestructura que poseen las redes sociales.

● Investigación sobre las herramientas de las infraestructuras que poseen las redes
sociales.
● Pruebas de concepto de cada producto que forme parte del diseño de la
arquitectura.
● Memoria del proyecto
● Diseño de la Arquitectura Tecnológica.
● Para la validación del proyecto se realizará una prueba funcional.
1.6.2 Plan de Gestión del Tiempo

El Plan de Gestión del Tiempo como objetivo principal indicar las fases que tendrá
el proyecto con sus respectivas actividades que se realizarán en cada una de estas,
estableciendo fechas de entrega con el fin de cumplir las actividades y sus
respectivos entregables.

A continuación, en la Tabla 3 se detallará las fases y entregables del Proyecto con

sus respectivas fechas de entrega.

Fase del Fecha Entregables

Hito del proyecto Prioridad
Proyecto Estimada incluidos

Inicio Iniciación 2018-1 Project Charter Alta

Plan de Trabajo,
Gestión del
2018-1 Entregables de Alta
Proyecto
Gestión

Análisis y
documentación de la
Planificación
funcionalidades y Alta
2018-1 arquitecturas de las
Factibilidad del
redes sociales
Proyecto

Memoria Parcial del

Alta
Proyecto

Marco Teórico y Marco Teórico

Ejecución 2018-1 Alta
Estado del Arte (Capitulo 4)
 Estado del Arte
Alta
(Capitulo 3)

Pruebas de las
herramientas a Pruebas de
2018-1 Alta
utilizar en la Concepto
solución

Desarrollo de la
Objetivo 2
Arquitectura y
2018-1 Alta
despliegue de una
Prueba Funcional
red social

Seguimiento y Continuidad y Documento Plan de

2018-2 Alta
Control Soporte Continuidad

Actas de Cierre y
2018-2 Alta
Aceptación
Cierre del
Cierre
Proyecto
Memoria Final del
2018-2 Alta
Proyecto

Tabla 3: Fases e Hitos del Proyecto

Fuente: Elaboración propia

 1.6.3 Plan de Gestión de Recursos Humanos

El Plan de Gestión de Recursos Humanos tiene como objetivo principal identificar

a todos los involucrados el Proyecto, indicando el rol que tienen y las
responsabilidades que tendrán en el desarrollo del Proyecto.

A continuación, en la Tabla 4 se detallará los miembros del proyecto con sus

respectivos roles y responsabilidades.

Rol Miembro Responsabilidades

Comité de Proyectos - Evaluar el desarrollo del proyecto.

- Gestionar y dirigir el proyecto

- Herdin Ríos
Jefe de Proyecto
- Marco Quispe
- Ivette Ramírez
buscando el cumplimiento de los
objetivos, el cronograma y el
alcance del proyecto.
- Obtener información en base a las
referencias encontradas.
- Velar por el desarrollo y
cumplimiento del proyecto.
- Es el responsable de los resultados
del proyecto.

Gerente Profesor - Monitoreo y control del proyecto

- Manuel Cuya
durante sus distintas etapas.

- Brindar los requerimientos y pautas

Cliente del proyecto.
-
- Validar la calidad de los
documentos del proyecto.
- Brindar los servicios de
Recurso de Investigación - Alumnos ITResearch investigación, documentación para
el desarrollo del proyecto.
- Apoyar en la elaboración de la red
Recurso de Software - Alumno de Software
social que será soportada en la
Factory
Arquitectura propuesta
Recursos asignados para
- Apoyar con el control de calidad de
Recursos QS los ciclos 2018-1 y 2018-
los entregables
2

Tabla 4: Tabla de Roles y Responsabilidades

Fuente: Elaboración propia

1.6.4 Plan de Comunicaciones

El Plan de Comunicaciones tiene como objetivo principal establecer las formas de

comunicación (interna y externa) con los involucrados del Proyecto, con el fin de
mantenerlos informados sobre los avances del Proyecto. Además, se establecen
los estándares que deben tener cada documento creado por el equipo del Proyecto,
como por ejemplo la codificación de versiones y las versiones.

Para más información sobre el Plan de Comunicaciones ver el documento Plan de

Gestión de Comunicaciones.

1.6.5 Plan de Gestión de Riesgos

El Plan de Gestión de Riesgos tiene como objetivo principal identificar aquellos

posibles riesgos que se puedan presentar en la realización del Proyecto, indicando
cual sería la probabilidad de que estos ocurran y el impacto que tendrían; además,
plantear estrategias de mitigación ante la posible materialización del riesgo.

A continuación, en la Tabla 5 se detallará los riesgos encontrados, su probabilidad,

impacto en el proyecto y mitigación.

# Riesgo Probabilidad Impacto Estrategia de mitigación

Establecer tiempos de
Retrasos en la holgura para la realización
elaboración y de actividades del
1 Media Alta
presentación de los proyecto con el objetivo de
entregables del proyecto cumplir con las fechas de
entrega.

Almacenar la información
Pérdida de información en repositorios en Cloud
2 Baja Alta
del proyecto como Google Drive y en
dispositivos propios.

Realizar actas de reunión

Cambios en el alcance
3 Baja Alta indicando el alcance real
del proyecto
que requiere el cliente.
# Riesgo Probabilidad Impacto Estrategia de mitigación

Retrasos en las
actividades asignadas a Realizar escala vertical
4 los recursos de las Media Media para que el caso sea
empresas virtuales de la atendido prontamente.
EISC

Realizar actas de reunión

indicando las
5 Cambio de Cliente Baja Media aprobaciones de
entregables para evitar
cambios en el alcance.

Monitorear el status de los

Caída de los servicios de
6 Muy Baja Alta servicios de Microsoft
Microsoft Azure
Azure.

El equipo restante debe

Retiro de miembros del
7 Muy Baja Muy Alta continuar con el desarrollo
equipo de proyecto
del proyecto.

Cambios en el catálogo Mantener un catálogo de

8 de servicios de Microsoft Baja Alta servicios fijo para el
Azure desarrollo del proyecto.

Tabla 5: Tabla de Riesgos

Fuente: Elaboración propia

 CAPITULO 2 STUDENT OUTCOMES

El objetivo de este capítulo es mostrar como el presente proyecto se

relaciona con cada uno de los Student Outcomes definidos por la
acreditadora internacional ABET.
2.1 Student Outcome (a): Propone soluciones en sistemas de
información aplicando principios de matemática, ciencias,
computación e ingeniería.
2.2 Student Outcome (b): Formula y administra proyectos y
experimentos en base al análisis e interpretación de datos
relevantes en la implementación de sistemas de información.
2.3 Student Outcome (c): Diseña la arquitectura de negocio y
tecnológica para la implementación de un sistema de
información, teniendo en cuenta restricciones económicas,
sociales, políticas, éticas y otras propias del entorno
empresarial.
2.4 Student Outcome (d): Participa en equipos
multidisciplinarios liderando o desarrollando sus tareas
eficientemente con profesionales de diferentes
especialidades o dominios de aplicación.
2.5 Student Outcome (e): Identifica y analiza problemas de
negocio o tecnológicos dentro del ciclo de vida de un sistema
de información con alcance empresarial o inter empresarial.
2.6 Student Outcome (f): Propone soluciones en sistemas de
información con responsabilidad profesional y ética.
2.7 Student Outcome (g): Comunica ideas o resultados orales o
escritos con claridad y efectividad a públicos de diferentes
especialidades y niveles jerárquicos.
2.8 Student Outcome (h): Identifica el impacto de las soluciones
en sistemas de información en el contexto global, económico
y del entorno en la sociedad.
2.9 Student Outcome (i): Actualiza los conocimientos en
metodologías, técnicas, herramientas por ser necesarios
para mantener la vigencia en el desarrollo de sistemas de
información.
2.10 Student Outcome (j): Analiza hechos del mundo
contemporáneo identificando el impacto en el desempeño
profesional del ingeniero de sistemas de información.
2.11 Student Outcome (k): Utiliza técnicas y herramientas de
última generación en el desarrollo de sistemas de
información.
2.12 Student Outcome J - CAC: Comprende y brinda soporte para
el uso, entrega y gestión de sistemas de información dentro
de un entorno de sistemas de información
 CAPITULO 3 MARCO TEÓRICO

En este capítulo se definen los conceptos necesarios y requeridos para el adecuado

entendimiento del proyecto. Así mismo, se detalla el origen del término Cloud y el origen y
evolución de Microsoft Azure.
 CAPITULO 4 ESTADO DEL ARTE

En el siguiente capítulo se presenta el estado del arte de la arquitectura tecnológica de alta

disponibilidad y escalable para la implementación de una red social de 1 millón de usuarios,
el cual expone la recopilación de investigaciones relacionadas al tema de principal del
proyecto. Estos son agrupados dependiendo de su aporte al proyecto. La segmentación
que se ha realizado está dividida en: Arquitectura tecnológica, Escalabilidad y alta
disponibilidad. A continuación, se inició la búsqueda de trabajos que hayan realizado
proyecto de investigación, implementación o modelos similares que atiendan el mismo
problema que el nuestro. Esta búsqueda se dio en dos fuentes de datos: IEEE, Scopus y
Proquest. Para esta investigación se ha utilizado una metodológia de 3 fases.
 3.1. Metodología

Para la selección de los artículos relacionados a la Arquitectura tecnológica de alta

disponibilidad y escalable para la implementación de una red social de 1 millón de
usuarios. Se ha seguido una metodología de 3 fases usadas en varios trabajos
como los de: Castañeda & Mauricio (2018), Mendoza (2008), Cabrera (2017).

 Planificación:

En la planificación, se definirán los bancos de información de los cuales se puede

obtener información, las palabras clave que se utilizaran durante la investigación,
el periodo en el cual se deben encontrar los artículos a seleccionar y los criterios
para definir las tipologías en la investigación.

 Desarrollo:

Durante el desarrollo, se aplicará la planificación del estudio, se realizará la

selección de artículos y la identificación de temas por tipología.

 Análisis:

En el análisis, se responderán las preguntas formuladas con durante la planificación

con los artículos seleccionados durante el desarrollo.

3.2. Planificación
3.2.1. Preguntas de investigación
Con el fin de lograr un mejor entendimiento nos planteamos las siguientes
preguntas:
o ¿Qué Arquitectura soporta los sistemas de información?
o ¿Cómo se consigue la escalabilidad en los sistemas de información o
aplicaciones?
o ¿Cómo se consigue la Alta disponibilidad en los sistemas de
información?
 3.2.2. Bancos Bibliográficos

Para la selección de los artículos se seleccionó bancos de artículos de donde se

pueden sacar información acerca del tema en cuestión. Estos bancos son
Proquest, IEEE y SCOPUS. Estos son organizaciones sin fines de lucro que
contienen artículos, journals y conferences papers de temas actuales de
investigación y brindan una visión global de la producción de investigación en el
mundo en los campos de la ciencia, la tecnología, medicina, las ciencias sociales
y las artes y las humanidades. Estos tres bancos presentan herramientas
inteligentes para rastrear, analizar y visualizar la investigación.

3.2.3. Palabras

Para poder hacer una búsqueda selectiva de los artículos, se necesita reducir el
tamaño de la búsqueda bajo ciertos parámetros que se relacionen con el tema de
investigación. Para dicho fin se utilizaron palabras clave como:

• Arquitectura tecnológica / Technology Architecture

• Infraestructura tecnológica / Technology Infrastructure
• Escalabilidad / Scalability
• Alta disponibilidad / High Availability
• Red social / Social Networking

3.2.4. Periodo
Además, para poder reducir la búsqueda a temas actuales el período se debe
reducir a tres años de investigaciones. Los años para los que se ha reducido esta
búsqueda, desde el año 2015 al año 2018.

Años Artículos

2015 5

2016 1

2017 3

2018 1

Tabla 1: Año x N° de Artículos

 3.2.5. Criterios de Inclusión y Exclusión

Criterios de Inclusión Razón de la Inclusión

Se incluyen artículos que puedan proveer

Estudios con resultados cuantitativos
un resultado empírico

Estudios que hablen sobre las

Estudios relacionados con Arquitectura
arquitecturas tecnológica de diferentes
tecnológica
sistemas de información.

Artículos con palabras clave relacionadas Las palabras clave muestran a simple
relacionadas a la Arquitectura vista el contenido relacionado con
tecnológica, alta disponibilidad y Arquitectura tecnológica, alta
escalabilidad disponibilidad y escalabilidad.

Estudios relacionados con escalabilidad Estudios que hablen sobre escalabilidad.

Estudios relacionados con alta Estudios que hablen sobre alta

disponibilidad disponibilidad.

Tabla 2: Criterios de inclusión

Criterios de Exclusión Razón de la Exclusión

Tipo de publicación Se excluyen libros y capítulos de libros

Artículos con una antigüedad mayor a 4 Se excluyen los artículos con fecha
años menores a 2015

Estudios sobre redes sociales enfocados Se excluyen artículos que no tengan un

a la relación entre personas. enfoque tecnológico.

Tabla 3: Criterios de exclusión

Desarrollo

El desarrollo convalida la etapa de investigación de acuerdo con los criterio y

planteamientos en la etapa anterior, por lo cual se realizará un debido proceso de
búsqueda tomando los bancos de investigaciones referentes al tema. Y se
realizaran filtros según a los criterios previamente establecidos.

3.2.6. Proceso de Investigación

Figura 1: Proceso de Búsqueda

 3.2.7. Resultados

Durante la investigación, se encontraron 46 artículos de los bancos de

información IEEE, Scopus y Proquest de los cuales solo se seleccionaron
15 artículos.

Banco de Artículos Artículos

Información Potenciales Seleccionados
IEEE 11 2
Scopus 13 2
Proquest 12 6
Total 36 10

Tabla 4: Selección de Artículos

Al realizar la investigación, se identificaron los siguientes temas:

- Arquitectura tecnológica - Alta Disponibilidad

- Escalabilidad

Los cuales, se ven relacionados con los artículos seleccionados bajo la siguiente
distribución
# Título Referencia

A modular software architecture for processing of big

1 Krämer, M., & Senner, I. (2015)
geospatial data in the cloud.

Roy, A., Zeng, H., Bagga, J., Porter,

2 Inside the Social Network’s (Datacenter) Network.
G., & Snoeren, A. C. (2015)

A Dynamically Scalable Cloud Data Infrastructure for Li, T., Keahey, K., Wang, K., Zhao,
3
Sensor Networks D., & Raicu, I. (2015)

A Novel Approach for Optimization Auto-Scaling in Mogouie, K., Arani, M. G., & Shamsi,
4
Cloud Computing Environment M. (2015)

5 Want to scale in centralized systems? Think P2P. Kermarrec, A. M., & Taïani, (2015)

Developing architecture of a traveler information Noranian, M. H., & Tahsiri, A.

6
system for dynamic equilibrium in traffic networks. R.(2017)

Auction-Based Cloud Service Pricing and Penalty

7 Wu, X., & Han, J. (2018)
with Availability on Demand

Intelligent Hybrid Cloud Data Hosting Services with Myneni, M. B., Prasad, L. N., &
8
Effective Cost and High Availability Kumar, D. N. (2017)

Automated Forecasting Approach Minimizing

Sekma, N. C., Elleuch, A., & Dridi, N.
9 Prediction Errors of CPU Availability in Distributed
(2016)
Computing Systems.

A study of Cloud Computing-based Disaster

10 Recovery System for Security High Availability of Park, K. H., & Jang, H. S. (2017)
Academic Affairs Information Service.
Tabla 5: Relación de Artículos
 3.3. Análisis
3.3.1. ¿Qué Arquitectura soporta los sistemas de información?

No existe literatura sobre la arquitectura de redes sociales, sin embargo, se realizó la

investigación de las arquitecturas den otro tipo de aplicaciones.

TÍTULO 1: A MODULAR SOFTWARE ARCHITECTURE FOR PROCESSING OF BIG

GEOSPATIAL DATA IN THE CLOUD.

Los autores observan que con la disponibilidad de sensores modernos y escáneres LiDAR
(Light Detection And Ranging) que entregan cientos de GiB hasta varios TiB por hora, el
volumen mundial de datos geoespaciales crece exponencialmente. Si bien el
procesamiento de información espacial siempre ha sido una tarea compleja y lenta, este
nuevo tipo de datos de gran volumen (Big Data o Big Geo Data) requiere nuevas técnicas
que hagan uso de tecnología moderna, como programación multinúcleo y programación
GPGPU. Sin embargo, tales datos grandes generalmente no caben en la memoria de una
computadora. A menudo se almacena de forma distribuida en múltiples sistemas
informáticos. Estas computadoras conforman los nodos de una infraestructura distribuida,
generalmente denominada nube.

Los autores proponen una arquitectura de software que permite el procesamiento de

grandes conjuntos de datos geoespaciales en la nube. El sistema es modular y flexible y
admite múltiples paradigmas de diseño de algoritmos como MapReduce, computación en
memoria o programación basada en agentes.

Contiene una interfaz de usuario basada en web donde los expertos de dominio (por
ejemplo, analistas de SIG o planificadores urbanos) pueden definir flujos de trabajo de
procesamiento de alto nivel utilizando un lenguaje específico de dominio (DSL). Los flujos
de trabajo se pasan a través de una serie de componentes que incluyen un analizador, un
intérprete y un servicio llamado administrador de trabajos. Estos componentes usan
conocimiento declarativo y de procedimiento codificado en reglas para generar una cadena
de procesamiento que especifica la ejecución de los flujos de trabajo en una infraestructura
de nube dada de acuerdo con las restricciones definidas por el usuario. Los servicios se
comunican entre sí a través de un sistema de archivos distribuidos que es escalable y
tolerante a las fallas.

En comparación con trabajos previos que describen infraestructuras y arquitecturas en la

nube, se centran en el procesamiento de datos geoespaciales grandes y heterogéneos.
Además de eso, no depende de un solo modelo de programación específico o de una cierta
infraestructura en la nube, sino que admitimos varios. Combinado con la posibilidad de
controlar el procesamiento a través de flujos de trabajo basados en DSL, esto hace que
nuestra arquitectura sea muy flexible y configurable. No solo vemos la nube como un medio
para almacenar y distribuir grandes conjuntos de datos, sino también como una forma de
aprovechar el poder de procesamiento de los entornos informáticos distribuidos para
conjuntos de datos geoespaciales de gran volumen.

Figura 2: Arquitectura DSL

Se presenta una arquitectura modular para el procesamiento de Big Geo Data en la nube.
Se describe la arquitectura general, sus componentes y cómo funcionan entre ellos.
También se describe los requisitos para los sistemas que procesan Big Geo Data y cómo
los abordan en nuestra arquitectura. La arquitectura es modular y permite ejecutar una
amplia gama de servicios de procesamiento (incluso heredados). Esto hace que el sistema
sea adecuado para muchas aplicaciones. Además de eso, no se enfoca en cierta
infraestructura de la nube. En cambio, esta solución hace uso de un sistema basado en
reglas que nos permite controlar la ejecución de flujos de trabajo en múltiples plataformas.
La flexibilidad adicional viene dada por el hecho de que nuestra arquitectura permite que
expertos de dominio controlen el procesamiento de Big Geo Data a través de un lenguaje
específico de dominio. Esto hace que la nube y, por lo tanto, su potencia de procesamiento
esté disponible para los usuarios del dominio geospatial sin que tengan que tener un
conocimiento profundo de la infraestructura y sus detalles técnicos.
El DSL es muy potente y permite a los expertos en el dominio controlar el procesamiento
en la nube con solo un par de comandos. La ganancia de rendimiento del uso de
procesamiento distribuido es enorme en comparación con una única estación de trabajo de
alta gama. La arquitectura se ha implementado en un nivel prototípico que permitió realizar
la evaluación.

TITULO 2: INSIDE THE SOCIAL NETWORK’S (DATACENTER) NETWORK.

Los autores notaron que los centros de datos están revolucionando la forma en que diseñan
redes, debido en gran parte a las restricciones de ingeniería enormemente diferentes que
surgen al interconectar una gran cantidad de nodos homogéneos altamente
interdependientes en un espacio físico relativamente pequeño, en oposición a puntos
finales heterogéneos débilmente acoplados dispersos a través del mundo. Si bien muchos
aspectos del diseño de la red y el protocolo dependen de estos atributos físicos, muchos
otros requieren una comprensión firme de la demanda que los anfitriones finales pondrán
en la red. Desafortunadamente, si bien se entiende, mucho acerca de lo primero (es decir,
que los modernos centros de datos en la nube conectan decenas de miles de servidores
usando una combinación de Ethernet de 10 Gbps y cantidades crecientes de
interconexiones de fibra de alta velocidad), estos últimos tienden a no ser divulgados en
público. Por lo tanto, muchas propuestas recientes están motivadas por suposiciones
ligeramente validadas con respecto a las cargas de trabajo del centro de datos o, en
algunos casos, los rastros de carga de trabajo de un solo operador de centro de datos
grande. Estos rastros están dominados por el tráfico generado como parte de un importante
servicio de búsqueda web, que, si bien es significativo, puede diferir de las demandas de
otros servicios principales en la nube. En este documento, se estudia las cargas de trabajo
de muestra desde los centros de datos de Facebook. Se encuentra que los estudios de
tráfico en la literatura no son completamente representativos de las demandas de
Facebook, cuestionando la aplicabilidad de algunas de las propuestas basadas en estas
suposiciones prevalentes sobre el comportamiento del tráfico del centro de datos. Esta
situación es particularmente aguda cuando se consideran nuevas telas de red, protocolos
de ingeniería de tráfico y diseños de interruptores.

Los autores proponen el estudio de una red de centro de datos que conecta cientos de
miles de nodos de 10 Gbps. Utilizando sistemas de monitoreo en todo Facebook y rastreos
de encabezado de paquete por host, examinamos los servicios que generan la mayoría del
tráfico en la red de Facebook. Aunque se encontró que los patrones de tráfico exhibidos
por las implementaciones Hadoop de Facebook se ajustan bien a los reportados en la
literatura, porciones significativas de la arquitectura de servicio de Facebook varían
dramáticamente de las infraestructuras de estilo MapReduce estudiadas previamente,
conduciendo a patrones de tráfico muy diferentes. Los hallazgos del estudio con
importantes implicaciones arquitectónicas incluyen:

- El tráfico no es ni local ni en rack; la localidad depende del servicio, pero es estable

en períodos de segundos a días. Las telas eficientes pueden beneficiarse de grados
variables de sobresuscripción y menor ancho de banda en el raíl que el que
normalmente se implementa.
- Muchos flujos son de larga duración, pero no muy pesados. El equilibrio de carga
distribuye efectivamente el tráfico entre los hosts; tanto que las demandas de tráfico
son bastante estables incluso en intervalos de menos de segundo. Como resultado,
los bateadores pesados no son mucho más grandes que el flujo mediano, y el grupo
de bateadores pesados cambia rápidamente. Los bateadores pesados
instantáneos con frecuencia no son pesados durante periodos de tiempo más
largos, lo que puede confundir muchos enfoques de la ingeniería de tráfico.
- Los paquetes son pequeños (la mediana de la longitud del tráfico que no es de
Hadoop es inferior a 200 bytes) y no muestran el comportamiento de llegada /
apagado. Los servidores se comunican con cientos de hosts y bastidores al mismo
tiempo (es decir, dentro del mismo intervalo de 5 ms), pero la mayoría del tráfico a
menudo está destinado a (pocos) 10 s de bastidores.

Si bien no se ofrecen estas cargas de trabajo como más representativas que otras, pueden
cambiar a medida que los servicios de Facebook evolucionan, sugieren que el espacio de
carga de trabajo del centro de datos en la nube es más rico de lo que la literatura puede
implicar. Como una forma de caracterizar la importancia de nuestros hallazgos, la Tabla 1
muestra cómo nuestros resultados se comparan con la literatura, y cita sistemas
ejemplares que incorporan estos supuestos en su diseño.
 Figura 4: Arquitectura FBflow

Se encontró que la red del centro de datos de Facebook admite una variedad de servicios
distintos que muestran diferentes patrones de tráfico. Así también se encontró que varios
se desvían sustancialmente de los servicios considerados en la literatura. Las diferentes
aplicaciones, combinadas con la escala (cientos de miles de nodos) y la velocidad (enlaces
de borde de 10 Gbps) de la red del centro de datos de Facebook resultan en cargas de
trabajo que contrastan de varias maneras con la mayoría de los conjuntos de datos
publicados anteriormente. Las limitaciones de espacio nos impiden proporcionar una
cuenta exhaustiva; se describen las características que pueden tener implicaciones para la
topología, la ingeniería de tráfico y el diseño de conmutadores de la parte superior del rack.
Nuestra metodología impone algunas limitaciones en el alcance de este estudio. El uso de
hosts finales para capturar paquetes de marca de tiempo introduce variaciones basadas
en el programador sobre la precisión de la marca de tiempo. Además, solo se pudo capturar
el tráfico de unos pocos hosts a la vez sin correr el riesgo de caer en la recopilación de
paquetes. En conjunto, estas restricciones impiden evaluar los efectos como incast o
microburbujas, que se consideran como contribuyentes al bajo rendimiento de las
aplicaciones. Además, los volcados de paquetes por host son necesariamente anecdóticos
y ad hoc, dependiendo de la presencia de un host de captura no utilizado en el mismo
bastidor que el objetivo. Si bien Fbflow se implementa en todo el centro de datos, la gran
cantidad de datos de medición que ofrece presenta otro desafío, específicamente uno de
procesamiento y retención de datos, que limita la resolución en la que puede operar. Por
lo tanto, se considera que el monitoreo y análisis efectivos de la red es un problema en
constante evolución.
 Referencia
Arquitectura Descripción

Permite a los expertos en el dominio

controlar el procesamiento en la nube
con solo un par de comandos. La
(Krämer, 2015)
ganancia de rendimiento del uso de
Arquitectura DSL
procesamiento distribuido es enorme
en comparación con una única
estación de trabajo de alta gama.
Fbflow es un sistema de monitoreo de
producción que muestrea los (Roy, 2015)
Arquitectura FBflow encabezados de paquetes de toda la
flota de máquinas de Facebook.

Tabla 6: Arquitecturas encontradas

3.3.2. ¿Qué beneficios trae consigo la escalabilidad en los sistemas de información

o aplicaciones?
TITULO 3: A DYNAMICALLY SCALABLE CLOUD DATA INFRASTRUCTURE FOR
SENSOR NETWORKS

Los autores observaron que los últimos años han visto un aumento en el uso de sensores,
actuadores y sus redes para detectar, monitorear e interactuar con el medioambiente.

Hay una proliferación de sensores pequeños, baratos y robustos para medir diversas
características físicas, químicas y biológicas de Permiso para hacer copias digitales o en
papel de todo o parte de este trabajo para uso personal o en el aula se otorga sin cargo
siempre que no se hagan copias o distribuidos con fines de lucro o ventajas comerciales y
que las copias lleven este aviso y la cita completa en la primera página.

Para copiar lo contrario, para volver a publicar, para publicar en servidores o para
redistribuir a listas, se requiere un permiso específico previo y / o una tarifa. El medio
ambiente que abre nuevos y confiables métodos para monitorear las cualidades que van
desde las variables geofísicas, las condiciones del suelo, el control de la calidad del aire y
el agua hasta el crecimiento y la descomposición de la vegetación.

Las implementaciones estructuradas, como la red global de torres ux, se están

incrementando mediante el uso innovador de dispositivos móviles personales (por ejemplo,
como el uso de teléfonos celulares para detectar terremotos), el uso de datos de redes
sociales e incluso la ciencia ciudadana.

En otras palabras, en lugar de construir un único instrumento compuesto por millones de

sensores, un "instrumento virtual" podría comprender grupos de sensores dinámicos,
potencialmente ad hoc, capaces de funcionar de forma independiente pero también
capaces de combinarse para responder preguntas específicas.

Los proyectos organizados en torno a este enfoque representan áreas importantes que van
desde las ciencias oceánicas, la ecología, la construcción e investigación urbana, hasta la
hidrología. Esto requiere una infraestructura capaz de recopilar, almacenar, consultar y
procesar el conjunto de datos de las redes de sensores.

Diseñan una arquitectura multicapa ligeramente acoplada para aumentar la escalabilidad

y mantener un buen rendimiento.

Diseñando servicios dinámicos y escalables:

Figura 5: Diseño de servicios dinámicos

Todas las capas de componentes de nuestro sistema están organizadas como servicios
escalables, la mayoría de los cuales pueden escalar de forma dinámica y automática. Para
permitir que lo hagan, deben cumplirse un par de requisitos. En primer lugar, las instancias
paralelas de un servicio se pueden ejecutar en múltiples máquinas de forma independiente.
Esto garantiza que un servicio se pueda ampliar. En segundo lugar, una nueva instancia
del servicio debería ser capaz de descubrir y unirse a un servicio en ejecución. Esto
garantiza el escalamiento en vivo de un servicio, lo que significa que el servicio puede
escalar en cualquier momento a pedido sin detenerse.

Para determinar la escalabilidad del lado del servidor y medir el rendimiento general, se
ajustó el tamaño del mensaje a 1000 bytes y realizamos experimentos similares con hasta
128 clientes y 8 servidores. A medida que se unieron más clientes, las latencias de todas
las escalas de servidores aumentaron como se muestra en la figura 3. Cuanto más se
usaban los servidores, menos aumentaba la latencia. En el sistema de un solo nodo, la
latencia comenzó a aumentar rápidamente en una escala de 32 clientes y superior. Esto
sugirió que el servidor único se saturó al atender a más de 32 clientes.

Figura 6: Latencia vs N° de clientes

El trabajo adopta técnicas conocidas y amplía el trabajo previo en el modelo de datos y

almacenamiento. Sin embargo, no se conoce otros sistemas implementados que cubran
un modelo de datos versátil, almacenamiento escalable, interacción transaccional y,
especialmente, escalabilidad dinámica en cada nivel del sistema. El patrón de
comunicación y almacenamiento utilizado en nuestro sistema se puede encontrar en otros
tipos de sistemas, como la gestión del estado del sistema, que estaba más diseñada para
manejar una carga de trabajo relativamente constante.

En los sistemas de almacenamiento distribuido escalables para aplicaciones intensivas en

datos y en la nube, se han realizado trabajos en bases de datos NoSQL, le systems. En el
nivel de almacenamiento de datos, utilizamos bases de datos NoSQL en lugar de bases de
datos SQL convencionales, debido a su escalabilidad limitada en la implementación de
múltiples nodos. Hay varios tipos de bases de datos NoSQL para diferentes aplicaciones:

 Almacenes de Primary-Key, almacenes de documentos (MongoDB) y bases de

datos orientadas a columnas, etc. También se realizan trabajos en sistemas de
actuales distribuidos que admiten lecturas concurrentes muy altas y escribe como
Fusion FS. Similar al servicio de cola en WaggleDB, el trabajo de Liu utiliza el burst
burst en sistemas escalables de levas paralelas. Con la perspectiva de transmisión
de datos, JetStream permite la transmisión de eventos a través de los centros de
datos de la nube.

En conclusión, este trabajo se presenta un conjunto de protocolos y una infraestructura de

transmisión de datos basada en la nube llamada WaggleDB que aborda esos desafíos. El
sistema agrega y almacena eficientemente datos de redes de sensores y permite a los
usuarios consultar esos conjuntos de datos. Aborda los desafíos para acomodar los flujos
de datos de red de sensores en la nube con una arquitectura escalable de niveles múltiples,
que está diseñada de tal manera que cada nivel puede escalarse agregando más recursos
independientes provisionados a pedido en la nube. La alta disponibilidad y escalabilidad
destacada, el esquema de datos flexible y la ejecución de comandos transaccionales lo
convierten en un buen candidato para la infraestructura de datos de redes de sensores en
la era de la nube.

TÍTULO 4: A NOVEL APPROACH FOR OPTIMIZATION AUTO-SCALING IN CLOUD

COMPUTING ENVIRONMENT.

En los últimos años, las aplicaciones de servicios en la nube se han ampliado cada vez
más. Los servicios en la nube son infraestructuras distribuidas que desarrollan la
comunicación y los servicios. El escalado automático es una de las características más
importantes de los servicios en la nube, que dedica y retoma el recurso dinámico asignado
en proporción al volumen de solicitudes. El escalado intenta utilizar la máxima potencia de
los recursos disponibles también para usar recursos inactivos, con el fin de maximizar la
eficiencia o cerrar recursos innecesarios para reducir el costo de ejecutar solicitudes.
La computación en la nube es una nueva tecnología que ha encontrado su lugar en la vida
humana como una necesidad básica, y su popularidad aumenta entre los usuarios de
Internet día a día. Los usuarios del servicio en la nube solo pagan el precio en función de
la cantidad de recursos que han utilizado (pago por uso). Por otro lado, se requiere una
gran precisión para establecer un equilibrio entre el precio y la eficiencia. Proporcionar
servicios en la nube de alta calidad al precio más bajo posible, satisfacer las solicitudes y
mantener la estabilidad del sistema son el deseo final. La escalabilidad es uno de los
desafíos y características importantes de la tecnología de computación en la nube que
puede proporcionar esta característica para los usuarios de servicios en la nube.
Una de las técnicas de gestión para escalar en la computación en la nube es utilizar un
enfoque de umbral. El umbral se determina en función de factores como la fuerza y la
velocidad de procesamiento y la capacidad de almacenamiento. Cuando la utilización del
recurso es mayor que el valor del umbral, las solicitudes se remitirán a otras fuentes y
cuando el uso del recurso sea menor que el umbral, algunos de los recursos innecesarios
se seleccionarán y desactivarán para disminuir los costos. Por lo tanto, la cantidad de
actividades de implementación en un recurso se ha medido periódicamente, luego la escala
se hará en su base.
La determinación y el uso de un enfoque de escalado eficiente requiere crear y utilizar un
marco adecuado que incluya factores efectivos en el mecanismo de escalado. Por lo tanto,
Ofrecen un marco, luego el enfoque de escala propuesto se presenta en base a este marco.
La figura muestra los principales componentes del marco de escalabilidad que incluyen:
Load Balancer, Scaling Manager, Cost Manager, Virtualization Manager y Server Cluster.

Figura 7: Framework de escalabilidad

Se evaluó el enfoque propuesto basado en 3 criterios que incluyen costo, violación de SLA
y cantidad de escala. Hemos utilizado Cloudsim para simular el enfoque propuesto.
Utilizaremos 4 tipos de máquinas virtuales basadas en máquinas virtuales de la empresa
Amazon en pruebas de simulación. En cuanto a la variedad en los servicios existentes en
la nube, hemos realizado cuatro tipos diferentes de servicios y no nos hemos centrado en
un servicio o programa especial para que los servicios sean independientes del programa.
El servicio combina todas las aplicaciones heterogéneas como HPC, Web y más. La carga
de trabajo del sistema se ha modelado según la distribución normal para que esté más
cerca del mundo real.

Tabla 7: Información de VM’s

Se evalúa el número de escalas para el enfoque propuesto frente a los otros dos enfoques
descritos anteriormente. La eliminación o adición de máquinas virtuales previamente
formuladas se realiza en función de la violación de los valores de umbral. El número de
escalas que indica que el sistema está equilibrado o no, también puede imponer gastos
operativos y costos al sistema. De modo que una gestión adecuada de los criterios y la
elección de valores de umbral adecuados pueden ayudar a que el enfoque de escalado
para acceder a la velocidad de respuesta más alta y al menor costo resulte en una tasa
decreciente de violación de SLA. En la Figura, los resultados de la simulación se han
representado para tres enfoques en comparación con 4 por día en función del número de
escalas para cada enfoque en la nube. Según los resultados, el número de escalabilidad
está cambiando continuamente en un enfoque aleatorio en respuesta a las diversas
solicitudes, por lo tanto, el sistema no tiene una estabilidad adecuada. Por otro lado, estos
valores son aproximadamente iguales en nuestro enfoque y en el enfoque de Costo-
consciente, por lo que podemos decir que la estabilidad del sistema se ha preservado en
parte.

Figura 8: Comparación del escalado en diferentes enfoques

En conclusión, Se tiene un equilibrio entre las medidas de desempeño. Con base en los
resultados de la evaluación, el enfoque de escalamiento propuesto que se ha ofrecido en
base a los autómatas de aprendizaje puede gestionar el equilibrio entre los factores de la
Infracción del SLA y los costos. El objetivo principal de nuestro enfoque orientado a la
escalabilidad es la gestión entre dos parámetros de referencia clave, incluida la tasa de
violación de SLA, y el costo. Se propone como trabajo futuro, considerar el escalado
automático basado en el autómata con respecto a los plazos. Cabe señalar que la fecha
límite es aplicable solo para las obras en las que el rendimiento significa eficiencia, no sus
resultados catastróficos. También puede usar escalas automáticas basadas en autómatas
para aplicaciones intensivas de datos.

TÍTULO 5: WANT TO SCALE IN CENTRALIZED SYSTEMS? THINK P2P.

Los sistemas punto a punto (P2P) se han investigado ampliamente en la última década, lo
que lleva a implementaciones altamente escalables para una amplia gama de aplicaciones
y servicios distribuidos. Un sistema P2P asigna roles simétricos a las máquinas, que
pueden actuar como cliente y servidor. Esto alivia la necesidad de cualquier componente
central para mantener un conocimiento global del sistema. En cambio, cada par toma
decisiones individuales basadas en el conocimiento local del resto del sistema,
proporcionando escalabilidad por diseño.
Mientras que los sistemas P2P se han aplicado con éxito a una amplia gama de
aplicaciones distribuidas (multidifusión, enrutamiento, almacenamiento, pub-sub,
transmisión de video), con algunos éxitos altamente visibles (Skype, Bitcoin), tienden a
pasar de moda a favor de una visión mucho más centrada en la nube de la Internet actual.
Creemos que esto es paradójico, ya que los sistemas basados en la nube son en sí mismos
infraestructuras a gran escala y altamente distribuidas. Residen en centros de datos
masivos y densamente interconectados, y deben ejecutarse de manera eficiente en un
número cada vez mayor de máquinas, al tiempo que se ocupan de volúmenes crecientes
de datos. Hoy, incluso más de una década atrás, los sistemas a gran escala requieren
diseños escalables para brindar servicios eficientes.

Los sistemas P2P son escalables por diseño: el hecho de que cada par potencialmente
actúe como un servidor evita el cuello de botella de la mayoría de los sistemas distribuidos
haciendo que el número de servidores aumente linealmente con la cantidad de clientes.
Esta capacidad natural de escalar se complementa con el hecho de que no se requiere que
ninguna entidad mantenga un conocimiento global del sistema, una operación costosa y
difícil en sistemas a gran escala. En cambio, cada par solo depende de la información local
y restringida para controlar su comportamiento. Esto garantiza la escalabilidad por dos
razones:

o Primero, los pares individuales solo necesitan procesar una pequeña cantidad de
información.

o Segundo, la información por lo general solo necesita ser diseminada a un

subconjunto limitado de pares, reduciendo así los costos de comunicación.

En Pastry, que proporciona una funcionalidad de enrutamiento en una red de superposición

P2P, los pares individuales solo necesitan mantener una pequeña tabla de enrutamiento
de tamaño O (logN), siendo N el número de pares en el sistema. Del mismo modo, cada
vez que un nodo sale o ingresa al sistema, solo un muy pequeño número de pares, c + O
(logN), necesitan ser notificados y actualizar sus estructuras de datos. Chord y muchas
otras infraestructuras P2P exhiben propiedades similares.

Figura 8: Descentralización de objetivos y los niveles donde se aplican

TÍTULO 6: DEVELOPING ARCHITECTURE OF A TRAVELER INFORMATION SYSTEM

FOR DYNAMIC EQUILIBRIUM IN TRAFFIC NETWORKS.

Este trabajo analiza una nueva base de requisitos para desarrollar un nuevo paradigma
para los sistemas de información de tráfico. Integra principalmente tres dimensiones dentro
de un sistema de tráfico; patrón de conducta y preferencias de los conductores, deseos de
tráfico urbano y capacidades de los proveedores de servicios de información de tráfico. En
base a lo anterior, los segmentos funcionales de varios fondos relacionados se unen para
estructurar una nueva arquitectura, llamada Sistema Interactivo de Información para
Viajeros (ITIS). La característica interactiva principal de esta nueva arquitectura es una vía
de comunicación bidireccional entre los conductores y el proveedor del sistema de
información de tráfico; de hecho, la decisión de elegir una carretera en un momento
determinado para un individuo se basará en la utilidad de ambos lados.

Esta nueva configuración consiste en la aplicación del teléfono inteligente del lado del
conductor, la predicción del tráfico central y las unidades de toma de decisiones, lo que
dará forma a un nuevo enfoque de los procesos de toma de decisiones. Todos estos
trabajan juntos para satisfacer el objetivo designado de ITIS de preservar la condición de
equilibrio de Wardrop en el nivel de la red de tráfico. Finalmente, nos concentramos en un
estudio de comparación, que muestra una diferenciación entre el rendimiento del ITIS
propuesto y el modelo ATIS actual en una situación real. Esto se ha hecho con
simulaciones de escenarios analógicos. La ventaja más notable de la arquitectura
propuesta no se limita a un límite de saturación, y el efecto positivo de aumentar la
penetración del sistema en el rendimiento del sistema de información recién introducido.
En conclusión, se sugiere llevar a cabo nuevos temas de investigación.

Figura 9: Arquitectura para ATIs

Los resultados de la simulación se proporcionan para mostrar cómo la estrategia de
difusión selectiva de información puede superar el fenómeno de sobrerreacción, que ocurre
en las estrategias de difusión de información pública que se utilizan en las arquitecturas
ATIS actuales. Por lo tanto, el requisito principal que se ocupa de esta simulación
conceptual es el desarrollo de un mecanismo de asignación de tráfico dinámico de base
individual. De hecho, los otros requisitos son requisitos de nivel de implementación que se
considerarán en la fase de implementación de los subsistemas. Por lo tanto, se presenta
un escenario simple de simulación de trabajo para mostrar las diferencias entre la
arquitectura actual y la recientemente introducida para el sistema de información del
viajero. Para mostrar mejor cómo se utiliza la arquitectura para realizar la simulación, el
esquema del proceso de simulación se representa en la siguiente figura.

Imagen 10: Arquitectura para ATIS propuesta

Como se indica en este documento, la principal contribución de la investigación es

encontrar una manera de resolver los problemas que enfrentan las ATIS actuales. Para
hacerlo, se presenta una nueva arquitectura para ATIS basada en los requisitos
presentados en el documento. La arquitectura introducida consiste en diferentes
subsistemas que trabajan en conjunto para proporcionar los requisitos de las diferentes
partes interesadas del sistema que son controladores, organizaciones de control de tráfico
y proveedores de servicios ATIS. Como se indica en las ventajas y desventajas de la nueva
arquitectura, la ventaja más importante de la arquitectura es la escalabilidad del sistema,
tanto en la utilización como en el rendimiento. Esto significa que todos los controladores
pueden usar el sistema y todos los controladores pueden beneficiarse del uso de este
sistema. Por otro lado, la mayor desventaja de la arquitectura es el tamaño masivo de las
tareas de cálculo que se comparan terriblemente con el poder computacional de los
procesadores de hoy. El efecto de la arquitectura de difusión de información de tráfico
sugerida se presenta conceptualmente en los resultados de la simulación para mostrar
cómo puede mejorar la confiabilidad del tiempo de viaje y cómo afecta el tiempo de viaje
de los enlaces en la red.

REFERENCIA
ESCALABILIDAD DESCRIPCION

(Noranian, 2017)
Capacidad de incrementar el
espacio o capacidad
AUTO
automáticamente cuando el
ESCALABALIDAD
sistema lo necesite (Mogouie, 2015)

Un sistema P2P asigna roles

simétricos a las máquinas, que (Kermarrec, 2015)

pueden actuar como cliente y

servidor. Esto alivia la
P2P necesidad de cualquier
componente central para (Li, 2015)

mantener un conocimiento
global del sistema

Tabla 8: Información de escalabilidad

3.3.3. ¿Cuáles son las características y beneficios de la Alta disponibilidad en los

sistemas de información?

TÍTULO 7: AUCTION-BASED CLOUD SERVICE PRICING AND PENALTY WITH

AVAILABILITY ON DEMAND

La disponibilidad es una de las principales preocupaciones de los usuarios de la nube, y

los proveedores de la nube siempre intentan proporcionar una mayor disponibilidad para
mejorar la satisfacción del usuario. Sin embargo, una mayor disponibilidad da como
resultado mayores costos del proveedor y un menor bienestar social. En este documento,
teniendo en cuenta tanto la valoración de los usuarios como la disponibilidad deseada,
diseñamos la asignación de recursos, los precios y los mecanismos de penalización con
disponibilidad según demanda. Considerando dos escenarios: disponibilidad pública en la
cual las disponibilidades deseadas de todos los usuarios son información pública, y
disponibilidad privada en la que las disponibilidades deseadas son información privada de
usuarios, y, analizando los posibles comportamientos de los usuarios, diseñamos un
mecanismo determinista veraz con 2- aproximación en el escenario de disponibilidad
pública y un mecanismo veraz universal con 11 + g de aproximación en el escenario de
disponibilidad privada, donde g es la proporción de respaldo de los recursos con la mayor
disponibilidad. Los resultados del experimento muestran que nuestros mecanismos
mejoran significativamente el bienestar social en comparación con el mecanismo sin
considerar la demanda de disponibilidad de los usuarios.

La calidad del servicio es un factor importante que afecta la selección del servicio de los
usuarios de la nube, que ha atraído la atención de muchos investigadores. Como una
métrica crucial para la calidad del servicio, la disponibilidad es el atributo más discutido,
que se incluye en casi todos los acuerdos de nivel de servicio en la nube (SLA).
De acuerdo con Pan et al., Más del 70 por ciento del SLA de usuario / proveedor incluía
preocupaciones de disponibilidad. Por lo tanto, muchos trabajos de investigación se
centraron en mejorar la disponibilidad mediante diversas optimizaciones. Para mejorar la
satisfacción del usuario, el proveedor de la nube infraestructura como servicio (IaaS)
proporciona mayor disponibilidad para sus usuarios, y proporciona una penalización
cuando se infringe el SLA.

La Figura 1 muestra la penalización denominada crédito de servicio en diferentes nubes,

que es un porcentaje del precio correspondiente. Sin embargo, en términos de los tipos de
aplicaciones, los usuarios pueden tener diferentes demandas de disponibilidad. Por
ejemplo, un servicio de alojamiento web no crítico siempre tiene una menor demanda de
disponibilidad que un servicio bancario de misión crítica. De acuerdo con la discusión en la
literatura [12], todas las técnicas de alta disponibilidad aumentan los costos administrativos
y las necesidades de recursos. Por lo tanto, las soluciones existentes en el centro de la
nube, que intentan proporcionar mayor disponibilidad sin tener en cuenta la demanda de
disponibilidad diferente, darán lugar a mayores costos del proveedor y consumirán más
recursos. Especialmente en el escenario de recursos insuficientes, hará que más usuarios
pierdan el servicio. Por lo tanto, el bienestar social, que es la suma de la valoración de los
usuarios, disminuirá. La siguiente figura muestra la asignación de recursos para las
solicitudes de servicio con disponibilidad fija y Precio.
 Imagen 11: Ilustración de dos enfoques de asignación de recursos: (a) asignación con
disponibilidad y precio fijos; (b) asignación según las diferentes demandas de
disponibilidad y valoración de los usuarios con diferentes precios. Los diferentes colores
representan diferente disponibilidad, y los diferentes tamaños de bloques grises
representan una proporción de respaldo diferente.

En conclusión, para reducir los costos de los proveedores y mejorar la suma de la

valoración de los usuarios (bienestar social), propusimos los precios de los recursos y los
mecanismos de penalización basados en las subastas. En nuestros mecanismos, les
permitimos a los usuarios solicitar su disponibilidad deseada, y asignar recursos con
disponibilidad a pedido. Teniendo en cuenta los usuarios inteligentes y racionales,
diseñamos dos mecanismos: un mecanismo de AoD HalfGreedy determinista para un
escenario de disponibilidad pública y un mecanismo de AoD no aleatorio RandomGreedy
para un escenario de disponibilidad privada. Los resultados del experimento mostraron que
nuestros mecanismos tienen mayor bienestar social que HalfGreedy con mayor
disponibilidad.
Sin embargo, este es solo un trabajo inicial para explorar la asignación de recursos, el
precio y el diseño del mecanismo de penalización en el escenario de disponibilidad
seleccionado por el usuario, y también hay algunos problemas que deben ser resueltos.
Dado que, en nuestro trabajo, la disponibilidad deseada de cada usuario es fija y solo se
trata de la asignación de recursos de tiempo único. En el trabajo futuro, nos centraremos
en la fijación de precios y penalización de los recursos en el entorno de disponibilidad
dinámico y en línea seleccionado por el usuario.

TITULO 8: INTELLIGENT HYBRID CLOUD DATA HOSTING SERVICES WITH

EFFECTIVE COST AND HIGH AVAILABILITY.

En este documento, la principal concentración es un servicio de hospedaje de datos

eficiente y basado en el usuario para la nube híbrida. Proporciona un esquema de
transacción amigable con las características de costo efectivo y alta disponibilidad para
todos los usuarios. Este marco inteligentemente coloca los datos en la nube con un costo
efectivo y alta disponibilidad. Esto proporciona un plan de prueba de respetabilidad de la
información en el que el cliente ha utilizado para verificar la corrección de su información.
En este estudio se consideran los principales proveedores de almacenamiento en la nube
en la India y los parámetros como el espacio de almacenamiento, el costo de
almacenamiento, el ancho de banda de salida y el tipo de modo de transición. Según el
conocimiento disponible sobre todos los parámetros de los proveedores de servicios en la
nube existentes en India, el marco inteligente de alojamiento de datos híbridos en la nube
asegura a los clientes bajo costo y alta disponibilidad con el modo de transición. Garantiza
que la capacidad del lado del cliente sea insignificante y que sea útil para los clientes.
Servicios de hospedaje de datos en la nube en el mundo actual de la web, por ejemplo,
Windows Azure, Amazon S3, el almacenamiento en la nube de Google tiene un lugar con
increíbles contrastes en lo que respecta a exhibiciones de trabajo y arreglos de valoración.
Elegir un sistema de exceso de ajuste razonable para almacenar información con el menor
costo y la accesibilidad garantizada supone que una parte importante es la eliminación de
la información. Muchos vendedores construyen su marco y continúan actualizándolos con
las recientes innovaciones en aumento. Se puede llegar a las administraciones utilizando
modelos distintivos, como organizaciones especializadas únicas y numerosos proveedores
de administraciones. El problema con los servicios existentes no es seguro, es fácil de
hackear y no se garantiza su accesibilidad. El alojamiento de información para el
almacenamiento de datos en la nube disgrega el perfil educativo entre muchas
organizaciones y clientes. Los clientes atribuibles relacionados con sus puntos financieros
de interés implican que el propietario de la información mueve sus movimientos de
información a un servidor externo de almacenamiento en la nube que aparentemente
debería cobrar por almacenar la información y devolverla al propietario en el punto
requerido. Como la era de la información está lejos de conducir la información, resulta
costoso para las pequeñas empresas rediseñar sus equipos de forma regular en cualquier
punto en el que se genere información adicional. Además, mantener las reservas puede
ser una tarea problemática. Poner fuera de la información del cliente en las circunstancias
favorables tiene muchas preocupaciones de seguridad que deben ser ampliamente
investigadas para que sea una respuesta sólida para el problema de evadir el
almacenamiento de información en las cercanías. En esta investigación existente se
examinaron numerosos problemas, como la validación de la información y la información
codificada de la subcontratación de la honestidad y los problemas relacionados que
manejan el cuestionamiento sobre el espacio codificado.

Figura 12: Arquitectura hibridad en la nube

Los modos de almacenamiento en el servicio en la nube están etiquetados como "frío",

"frío", "cálido", "caliente" según la frecuencia de transición del archivo. Por ejemplo, el modo
de almacenamiento cambiará de "caliente" a "frío" de acuerdo con el nivel de frecuencia
de acceso que se reduce por debajo del valor de umbral para ahorrar dinero. El valor está
determinado por los precios existentes, que varían de vez en cuando. El costo del modo
de almacenamiento diferente proporcionado por diferentes proveedores en India se
muestra en la Tabla siguiente.
 Tabla 9: Costos de diferentes modos de almacenamiento

Este documento propone, un enfoque inteligente para el alojamiento de datos en el entorno

de nube híbrida con un costo efectivo y la disponibilidad son las principales características.
Este marco identifica dos componentes clave como el ancho de banda y los modos de
acceso clave para impactar el alojamiento de datos en la nube híbrida. La solución empírica
considera los principales parámetros como el ancho de banda, el espacio de
almacenamiento requerido, los precios operativos y los indicadores del rendimiento de la
nube. Por lo tanto, es necesario proporcionar diferentes pesos para cada parámetro debido
a la variación de un costo de operación de efectos de archivo. El modo de almacenamiento
es un factor más para influir en la disponibilidad y el costo operativo del servicio en la nube.
Los algoritmos propuestos garantizan la forma inteligente de alojamiento de datos de
acuerdo con las necesidades del usuario como el modo de almacenamiento y otros
parámetros disponibles para un costo operativo efectivo y una alta disponibilidad de los
usuarios.

TÍTULO 9: AUTOMATED FORECASTING APPROACH MINIMIZING PREDICTION

ERRORS OF CPU AVAILABILITY IN DISTRIBUTED COMPUTING SYSTEMS.

Pronosticar la disponibilidad de la CPU en sistemas informáticos voluntarios utilizando un

único algoritmo de predicción es insuficiente debido a la diversidad de los recursos
distribuidos en todo el mundo. En este documento, elaboramos las directrices principales
para desarrollar un sistema de predicción de disponibilidad de CPU apropiado para dichas
infraestructuras informáticas. Para reducir el tiempo de solución y mejorar la precisión,
utilizamos técnicas de predicción simples, modelos vectoriales auto regresivos y una
técnica basada en la tendencia. Se propone un proceso de construcción de predictores que
verifica automáticamente los supuestos de los modelos auto regresivos de vectores en
series de tiempo. Se realizaron tres análisis pasados diferentes. Para un recurso voluntario
dado, el sistema de predicción propuesto selecciona el predictor apropiado usando la
técnica de predicción basada en varios estados. Luego, utiliza el predictor seleccionado
para pronosticar los indicadores de disponibilidad de la CPU. Evalúa el sistema de
predicción usando rastros reales de más de 226,000 hosts de Seti @ home. Encontramos
que el sistema de predicción propuesto mejora la precisión de predicción en alrededor del
24%.
 Consideramos un modelo de disponibilidad multi-estado similar al de [32]. Sin embargo,
no generamos rastros, pero, como se mencionó anteriormente, utilizamos rastros
reales de Seti @ home. Desde la perspectiva de la grilla de computación, la CPU del
recurso voluntario puede estar en uno de los tres estados siguientes:
o Totalmente disponible, para el uso de la red, durante toda la hora: en este caso,
toda la potencia de procesamiento del recurso pertenece al entorno de la red
durante toda la hora.
o No disponible, a la red durante toda la hora, debido a fallas, usuario presente en la
máquina, apagado, etc.
o Parcialmente disponible para el uso de la red durante toda la hora: en algunos
intervalos de la hora, el recurso voluntario puede no estar disponible para el uso de
la red. En este caso, solo una parte de su potencia de procesamiento está
disponible para el uso de la red durante la hora.

En este documento, se propone un enfoque automatizado para identificar, en cada tiempo

de predicción, el modelo de predicción más apropiado para un recurso voluntario dado, de
acuerdo con la naturaleza de su serie de tiempo. Para este fin, analizamos el rendimiento
de varias técnicas de predicción. Ampliamos la utilidad de los modelos auto regresivos
analizados en el pasado reciente mediante la explotación de otros dos análisis pasados
diferentes. Nuestro enfoque fue evaluado utilizando rastros de CPU reales del proyecto de
computación a gran escala Seti @ home. El estudio comparativo mostró que los modelos
VAR superan a las otras técnicas de predicción consideradas para una fracción significativa
de las predicciones. Se conserva los modelos más adecuados para reducir el tiempo de
solución y minimizar los errores de predicción. Teniendo en cuenta su precisión, los
modelos de VAR combinados con la estrategia basada en la tendencia se deben usar
cuando cambia la disponibilidad. Para predecir si la disponibilidad del recurso cambiará, se
identifica la técnica adecuada de predicción de múltiples estados y luego se utiliza. En
consecuencia, el modelo de predicción más apropiado se selecciona entre los modelos
retenidos. En promedio, el enfoque propuesto mejora la precisión en alrededor del 24%.

TÍTULO 10: A STUDY OF CLOUD COMPUTING-BASED DISASTER RECOVERY

SYSTEM FOR SECURITY HIGH AVAILABILITY OF ACADEMIC AFFAIRS
INFORMATION SERVICE.

El Cloud Computing ha sido utilizado por diferentes tipos de clientes porque tiene muchas
ventajas, incluida la minimización de los costos de los recursos de infraestructura, y su
propiedad de elasticidad, que permite que los servicios se amplíen o disminuyan de
acuerdo con la demanda actual. Desde el punto de vista del proveedor de la nube, hay
muchos desafíos que superar para poder ofrecer servicios en la nube que cumplan con
todos los requisitos definidos en los acuerdos de nivel de servicio (SLA).
La disponibilidad se calcula como el porcentaje de tiempo que una aplicación y sus
servicios están disponibles, dado un intervalo de tiempo específico. Uno logra alta
disponibilidad (HA) cuando el servicio en cuestión no está disponible menos de 5.25
minutos por año, lo que significa al menos 99.999% de disponibilidad ("cinco nueves").
los autores definen que los sistemas HA son sistemas tolerantes a fallas sin un único punto
de falla; en otras palabras, cuando un componente del sistema falla, no necesariamente
causa la terminación del servicio provisto por ese componente. Ofrecer un mayor nivel de
disponibilidad ha sido uno de los mayores desafíos para los proveedores de la nube. El
objetivo principal de este trabajo es presentar una revisión sistemática y analizar las
soluciones de HA de última generación para Cloud Computing. Los autores esperan que la
observación de tales soluciones se pueda utilizar como un buen punto de partida para
abordar algunos de los problemas presentes en el área de computación en la nube de HA.
La alta disponibilidad ha sido uno de los mayores desafíos para los proveedores, y muchos
servicios se pueden utilizar para mejorar la disponibilidad de un servicio, como el punto de
control, el equilibrio de carga y la redundancia. Más allá de los servicios, también podemos
encontrar soluciones de infraestructura y middleware. Esta revisión sistemática tiene como
objetivo principal presentar y debatir soluciones de alta disponibilidad (HA) para el cómputo
en la nube e introducir algunos desafíos de investigación en esta área. Esperamos que
este trabajo se pueda utilizar como punto de partida para comprender y enfrentar los
problemas de HA en la nube.

Imagen 12: Diagrama de procesos

 Imagen 12: Diagrama de Proceso

Como se describió en esta revisión sistemática, los proveedores de Cloud pueden hacer
uso de varias tecnologías y mecanismos para ofrecer servicios de HA. Los autores
clasifican las soluciones HA en dos categorías: enfoques de middleware y enfoques
basados en virtualización. Proponen un marco para evaluar la disponibilidad de la máquina
virtual contra tres tipos de fallas:
a) falla de la aplicación,
b) falla de la máquina virtual y
c) falla del sistema principal.
Los autores usan OpenStack, Pacemaker, OpenSAF y VMware para aplicar su framework,
que considera stateful y stateless-HA.
 Imagen 13: Clasificación para Alta disponibilidad

En conclusión, la alta disponibilidad es un gran desafío para los proveedores de la nube

debido a su complejidad (desde la infraestructura hasta el nivel de la aplicación). Hay
muchos problemas que estudiar para minimizar las interrupciones de Clouds, como la
portabilidad, la viabilidad y la seguridad. Un siguiente paso podría ser la implementación
de HA-as-a-service, destacando aún más la importancia de esta área de investigación para
los proveedores de la nube.

Alta disponibilidad Descripción Referencias

auction-based cloud service

Según los autores, la alta pricing and penalty with
disponibilidad proporciona availability on demand.
Calidad de Servicios una buena calidad de
servicios, el intelligent hybrid cloud data
validando
cumplimiento de los SLAs. hosting services with effective
cost and high availability.

La combinación de
Arquitectura de Cloud intelligent hybrid cloud data
Arquitectura en la nube e hosting services with effective
Hibrida
infraestructura fisca cost and high availability.

Implementar la alta
disponibilidad como a study of cloud computing-based
disaster recovery system for
HA- as a services servicio como propuesta de security high availability of
despreocupación de las academic affairs information
service.
organizaciones
3.2 Conclusiones.

No existe documentación de las Arquitecturas de las redes sociales, Sin

embargo, incluimos la arquitectura otros sistemas de información. Gracias a
esto, Podemos concluir que la arquitectura tecnológica de una organización
recoge el conjunto de decisiones significativas sobre la organización del
software, sus interfaces, su comportamiento y su interacción, así como la
selección y composición de los elementos estructurales (infraestructura
tecnológica). Por encima de todo, sin embargo, la arquitectura tecnológica
tiene que ser una definición de estilo: la descripción de las motivaciones o
fundamentos que determinan por qué un sistema está diseñado de la forma
en que lo está.
Una arquitectura se selecciona y se diseña en función de objetivos y
restricciones, y es una visión a alto nivel. Por lo tanto, no explica cómo está
implementado un sistema, sino que define conceptos como sus principios y
factores, la organización, estilos, patrones, responsabilidades,
colaboraciones, conexiones y motivaciones.

Con la pregunta 2 se concluye que, Para los modelos adaptados a la

escalabilidad de Internet se benefician de fases de crecimiento mucho más
fluidas, y con cambios en infraestructura que no interrumpen la actividad y
el negocio. Las herramientas y la estructura de funcionamiento son
perfectamente escalables, y permiten el aumento de nodos y usuarios, así
como de los niveles, con agilidad. Al mismo tiempo, si el producto que
diseñaron ya llevaba implícito el carácter escalable, podrán lanzarse a
campañas ambiciosas sin temor a no poder cubrir la demanda que se
genere.
En conclusión, la alta disponibilidad es un gran desafío para los proveedores
de la nube debido a su complejidad (desde la infraestructura hasta el nivel
de la aplicación). Hay muchos problemas que estudiar para minimizar las
interrupciones, como la portabilidad, la viabilidad y la seguridad. Un
siguiente paso podría ser la implementación de HA como servicio,
destacando aún más la importancia de esta área de investigación para los
proveedores de la nube.
3.2.1 Conclusión General
El presente trabajo de investigación busca generar una Arquitectura
Tecnológica que sea escalable y de alta disponibilidad y que soporte una red
social de 100 millones de usuarios a través de esta arquitectura facilite a las
organizaciones o personas que tengan como iniciativa implementar una red
social. Por lo que analizando lo aplicado por los diversos autores se llega a
concluir que aplicando estas disciplinas en conjunto permite tener una
aplicación robusta y estable.
 CAPITULO 5 DESARROLLO DEL PROYECTO

En el presente capítulo se presentarán todos los entregables desarrollados a lo largo del

ciclo de vida del proyecto, los cuales nos sirvieron para poder cumplir con los objetivos del
proyecto.
 CAPITULO 6 GESTION DEL PROYECTO

En este capítulo se explica cómo se llevó a cabo el proyecto para cumplir con cada uno de
los objetivos y poder entregar un producto final. En primer lugar, se habla sobre la gestión
del proyecto.
5.1 Producto Final
5.2 Lecciones Aprendidas
Conclusiones
Recomendaciones
Glosario
Siglario
Bibliografía

Referencias electrónicas

Referencia de Imágenes
Anexos

Anexo 1: INVMA - Proyección de Costo del uso de Virtual Machines v1.0

Anexo 2: INVMA - Costo del uso de Virtual Machines v1.0

Anexo 3: INVMA - S&P IT Expert

Anexo 4: INVMA - S&P Quality Services

Anexo 5: INVMA - S&P Software Factory

Anexo 6: Proyectos InnovaTI 2015-2016

Anexo 7: Proyectos ITConsulting 2015-2016

Anexo 8: Compute - Precios Virtual Machines

Anexo 9: Web+Mobile - Precio Media Services

Anexo 10: INVMA – Tecnologías v1.2

Anexo 11: INVMA – Análisis de Servidores de Datacenter y Virtual Machines

Anexo 12: INVMA - Cálculo de horas trabajadas por alumno