Está en la página 1de 6

1. Explain different techniques to scale a distributed system.

Explain
vertical and horizontal
scalability and propose how to solve the slashdot effect in a web
application.
- Eliminar la latencia de las comunicaciones: consiste en tratar de
evitar la espera de respuestas a las peticiones que se hagan a servicios
remotos lo más que se pueda. Principalmente su funcionamiento es una
aplicación que realice peticiones a un servidor de forma asíncrona de tal
manera que el cliente haga peticiones al servidor, mientras el cliente
espere la respuesta de este, puede atender otras tareas pero cuando
reciba la respuesta del servidor interrumpe todos los procesos locales
que esté haciendo para poder atender la respuesta del server.

- Distribución: consiste en tomar un servicio y fragmentarlo en partes


pequeñas y servir esas partes en toda la red, sistema, etc... Un ejemplo
de un sistema distribuido que hace uso de la distribución es el servicio
de nombres de dominio (DNS o Domain Name Server), el cual está
repartido en diferentes servidores en todo el mundo que permiten el
acceso a la misma resolución de nombres de dominio a todos los
usuarios de internet.

- Replicación: consiste en incrementar la disponibilidad de los


componentes del sistema y además ayuda a balancear la carga entre los
componentes que se replican, con lo que se logra una mejora del
rendimiento del sistema en general y por consiguiente del procesamiento
de la información. Si alguna carga de trabajo necesita mayor rendimiento
que el sistema actual le está dando, ese sistema si está en un clúster o
en un pool de componentes o recursos del sistema, el sistema puede
asignar de ese pool o clúster mayores recursos para que la tarea no
aumente su latencia significativamente.

• Escalabilidad horizontal.

Consiste en tener varios servidores o nodos trabajando como si fuera


una máquina en sí. Se crea un grupo de servidores conectados en
red entre sí conocido como cluster, con la finalidad de balancearse la
carga de trabajo entre todos los nodos del cluster, cuando el
rendimiento del cluster se ve afectado con el incremento de trabajos,
procesos, usuarios, etc… se añaden nuevos nodos al cluster, de esta
forma a medida de si es necesitado, se pueden ir agregando más
nodos al cluster.
Para que la gestión del escalamiento horizontal debe existir un “main
server” desde el cual se gestionará el cluster. Cada servidor del
cluster deberá tener un software que permite integrarse al cluster.
• Escalabilidad vertical.
Consiste en aumentar el hardware de uno de los nodos, es decir
aumentar el hardware por uno con mayor potencia y rendimiento,
como un disco duro, memoria, procesador, etc… pero también puede
ser la migración completa del hardware por uno más potente. El
esfuerzo de este crecimiento es mínimo, pues no tiene repercusiones
en el software, ya que solo será respaldar y migrar los sistemas al
nuevo hardware.
Para solucionar el efecto slashdot (pico de sesiones de visitas a una
web, el servidor no puede atender tantas peticiones y se cae) es tener
un cluster y a medida de que haya peticiones o picos de sesiones el
cluster asigne más recursos para que el servicio no decaiga en
rendimiento ni se caiga y por consiguiente el visitante de la web no note
nada.
También con el almacenamiento en caché del contenido web y si
hubiese ese pico de sesiones en tan poco espacio de tiempo sólo
accederá al contenido web cacheado repartido en varios servidores y no
a la original.

2. Compare the thin client/fat server with the fat client/thin server models.
Give examples of real systems for each model.

Thin client / Fat server: un fat server es un servidor que tiene configurado e
instaladas aplicaciones y procesos que se sirven dentro de una red a través de
él. Los thin client son máquinas dentro de esa misma red que tienen bajos
recursos y dependen en gran medida del fat server ya que por sí solas no son
capaces de correr las aplicaciones, procesos, etc… que corren en el fat server.
Todos los equipos thin client dentro de la red interactúan y acceden a los
recursos que le brinda el servidor usando RPC´s (Remote procedural calls). Por
eso la mayoría del procesamiento se hace en el servidor.
Fat client / Thin server: es básicamente lo contrario a lo anterior, todas las
aplicaciones, procesos, etc… corren en cliente, son máquinas más potentes
que los thin client y por eso soportan la carga del procesamiento de forma local.
Un thin server es básicamente en infraestructura como si fuera otro equipo de
la red pero suele llevar instalado un sistema operativo avanzando (Windows
server 2012, etc…) en el que puedes configurar roles para poder ofrecer
servicios de compartir ficheros, almacenamiento, etc… La mayoría de
procesamiento se hace en el cliente.
Ejemplo de Thin Client / Fat Server:
https://averma82.blogspot.com.es/2012/04/thin-client.html

Ejemplo de Fat Client / Thin Server:

http://windowsitpro.com/hardware/thin
3. Explain if push or pull models are more appropriate for instant
communication like chats.
Explain different techniques in HTTP to develop interactive chat
applications.
Push: únicamente son posibles en entornos cliente- servidor, la comunicación
se inicia en el servidor y no en el cliente. Los clientes escuchan a través de un
socket si el servidor les envía paquetes de información (mails, whatsapp, etc..)
y cuando llega la información se notifica al usuario.
Pull: las transacciones son iniciadas por el cliente (por ejemplo, visitar una
web, consultar manualmente el correo electrónico, etc…) y cuando llega la
petición al servidor ahí termina la transacción.
Para comunicaciones instantáneas como Messenger, whatsapp, etc.. es más
apropiado usar el modelo push porque todas las notificaciones te llegan al
momento sin que el usuario tenga que hacer manualmente nada, se usa un
canal dedicado que está siempre abierto y en permanente escucha por parte
del cliente.
Una técnica usada actualmente para el desarrollo de aplicaciones de
mensajería interactiva podrían ser los websockets. WebSocket una tecnología
que da un canal de comunicación full-dúplex (bidireccional) sobre un sólo
socket TCP lo que nos da una comunicación mucho más ágil entre un
navegador y un servidor web. Está diseñado para ser integrada en
navegadores y servidores web, pero puede utilizarse en cualquier aplicación
cliente/servidor.

4. Read the following article and answer the questions:


Serverless Computation with OpenLambda
https://www.usenix.org/system/files/conference/hotcloud16/hotcloud16_h
endrickson.pdf
a) Explain the relationship of serverless programming with FaaS, PaaS
and IaaS models.

Faas: o Function as a service es una modalidad de desarrollo de aplicaciones


en la nube, provee la disponibilidad de desplegar una sola función o parte de
una aplicación. Es un modelo de arquitectura sin servidor como Paas. Si fuera
necesario, las funciones desarrolladas por el programador pueden iniciarse
muy rápidamente y llamar a varias instancias. Las funciones son esperadas
para iniciarse en milisegundos en base a permitir el manejo de peticiones
individuales.

Paas: o Platform as a service es otra modalidad de desarrollo de aplicaciones


en la nube, es el punto donde los programadores desarrollan con las
aplicaciones que usan para ello y éstas se encuentran y se ejecutan en la
nube. Para desarrolladores que desconocen la infraestructura que deben
construir y sólo quieren centrarse en escribir líneas de código.
Iaas: o Infraestruture as a service es otra modalidad de desarrollo de
aplicaciones en la nube, con este modelo el desarrollador se tiene que
encargar de gestionar también la infraestructura. El desarrollador se encarga
de escalar las aplicaciones según la necesidad que se tenga y preparar el
entorno (Linux, Windows…) dar la memoria que considere, cpu´s… todo desde
un entorno virtual.

La relación es que son 3 métodos de desarrollo en la nube distintos, uno


pudiendo gestionar la infraestructura por debajo que corra las aplicaciones que
se desarrollen y el otro sólo basándote en “picar código fuente”.

b) Explain how it achieves scalability, heterogeneity and fault tolerance


(brief answers)
Escalabilidad: cuando AWS Lambda detecta mayor carga de trabajo de
repente asigna más instancias de trabajo y servidores (container-based
services) para que el procesamiento que se le ha mandado no se demore
mucho en el tiempo y ahí es donde se nota la diferencia respecto con otras
soluciones de otros proveedores. Además no requiere ningún tipo de
configuración adicional, ya te lo da el mismo servicio.
Heterogeneidad: la plataforma Lambda da soporte especial a ciertos paquetes
de repositorios como npm para Node.js (JavaScript) o Pip para Python. Al ser
una solución para desarrolladores la compatibilidad es con la mayoría de
lenguajes de programación usados como Java, JavaScript, Python, etc…
Tolerancia a fallos: Al ser una modalidad cloud, no deberemos de
preocuparnos en absoluto por algún fallo de servicio, petición o dato… ya que
el proveedor te asegurará el servicio, rendimiento y las pérdidas de datos que
pudieran haber. Todos los datos estarán garantizados ante cualquier desastre
que pudiera haber y siempre podrías volver a un estado anterior sin ningún
problema.
Lambdas son significativamente más lentos que los contenedores a bajo
volumen de solicitudes / peticiones, cuando la carga de trabajo es baja esta
solución tiene un rendimiento bajo pero cuando la carga de trabajo es alta es
cuando rinde bien y es donde muestra la diferencia con las otras soluciones de
la competencia.

5. Read the following article and answer the questions:


Occupy the Cloud: Distributed Computing for the 99%
https://arxiv.org/pdf/1702.04024.pdf
a) Describe the overall distributed architecture proposed in this article.
Justify the major
contribution proposed by the author.

En el artículo nos muestra los beneficios de usar un modelo basado en las


funciones sin estado trabajando junto con el almacenamiento remoto para
conseguir un rendimiento de sistema de procesamiento de datos muy alto
añadiendo la elasticidad y simplicidad que te da el olvidarte de la infraestructura
que hay por detrás para su procesamiento.
El autor propone añadir una API simple que estará estrechamente integrada
con las bibliotecas existentes, con eso lo que se ganará es compensar el
rendimiento de utilizar un almacenamiento remoto y así equilibrar la pérdida de
utilizar una plataforma “cloud”.

b) Explain how it achieves scalability, heterogeneity and fault tolerance


(brief answers)

Tolerancia a fallos: cuando una función falla se puede volverla a lanzar y


ejecutar en la misma entrada. Sólo se necesitan escrituras atómicas en un
almacenamiento remoto para rastrear cuáles funciones se han ejecutado
exitosamente. Básicamente se tienen garantías similares que teniendo la
infraestructura delante y ejecutando los procesos en ella.
Escalabilidad: un número de trabajos programados en cluster se encargan de
proveer baja latencia para los frameworks corriendo en paralelo, de tal manera
que a mayor necesidad de procesamiento de cálculo (muchos frameworks,
etc..) , mayores requisitos mandará utilizar el cluster para no decaer el
rendimiento e irse a un procesamiento mucho más largo en el tiempo (que la
latencia sea baja).
Heterogeneidad: Es compatible con muchas aplicaciones aunque de momento
no con las que tienen hardware especializado como GPU´s or FPGA´s ya que
no soportan AWS Lambda. PyWren es una aplicación compatible para
funcionar con AWS Lambda y tener un tener un mayor procesamiento de datos
(PyWren es un 17% más lento que PySpark pero te ahorras los 5-10 minutos
de configuración de instancias en los servidores dedicados)
Una de las cosas a mejorar en esta solución son la cargas de trabajo intensivas
ya que el rendimiento decae al estar por un lado el almacenamiento y por otro
el procesamiento / computación.

También podría gustarte