PEC1 solucion OFICIAL PDF

Preview

Summary

PEC1 SOLUCION OFICIAL...

Description

PAC1 Sistemas Distribuidos

2019

1. Describe the concept of transparency in distributed systems. Explain the transparency models (location, replication, failure) related to the scalability of a distributed system. Definimos transparencia en los sistemas distribuidos como la ocultación al usuario y al programador de aplicaciones, la separación de los componentes que forman el sistema, de manera que se perciben desde el exterior como un todo en vez de una colección de componentes independientes.

Distinguimos 8 tipos de transparencia: Transparencia de acceso: Permite el acceso local y remoto a los recursos, permitiendo su acceso con operaciones idénticas. Transparencia de ubicación: Permite el acceso a los recursos sin tener conocimiento de su ubicación física. Transparencia de replicación: Permite activar múltiples instancias de los recursos que se utilizarán para aumentar la seguridad y rendimiento sin que los actores del sistema conozcan su existencia. Transparencia frente a fallos: Permite ocultar los fallos, facilitando que los usuarios terminen sus tareas, a pesar de posibles fallos que se produzcan en el hardware o en el software. Transparencia de movilidad: Permite que los recursos se muevan si que esto afecte a las operaciones de los usuarios sobre el sistema. Transparencia de concurrencia: Permite que múltiples procesos operen de forma concurrente, utilizando recursos compartidos sin interferencias entre ellos. Transparencia de rendimiento: Permite que un sistema se pueda reconfigurar para mejorar el rendimiento si las cargas varían. Transparencia de escalado: Permite que el sistema y las aplicaciones se expandan en escala sin cambiar la estructura del sistema o los algoritmos de las aplicaciones.

1/14

PAC1 Sistemas Distribuidos

2019

Explain the transparency models (location, replication, failure) related to the scalability of a distributed system.

Transparencia de ubicación: Cuando un sistema no depende de una ubicación específica permite un mayor grado de escalabilidad, un ejemplo de esto son los sistemas CDN, que ayudan a servir recursos web desde diferentes ubicaciones, siempre desde la posición más cercana al cliente final, consiguiendo que las peticiones no se concentren en una sola localización, evitando la saturación debida al volumen de solicitudes concurrentes. Podemos escalar un sistema fácilmente creando nuevas ubicaciones desde donde se sirvan los recursos web.

Transparencia de replicación: La posibilidad de replicación de los componentes de un sistema distribuido permite un escalado horizontal respecto al acceso de los recursos. Un ejemplo podría ser un docker con una aplicación que consuma mensajes de un servidor de rabbitmq para enviar correos electrónicos. Como podemos replicar fácilmente las instancias de la aplicación dockerizada, escalamos horizontalmente los consumidores de mensajes, por ejemplo en un cluster de kubernetes.

Transparencia de tolerancias a fallos: La tolerancia a fallos permite que los sistemas respondan, aunque se produzcan fallos en algún componente. El ejemplo anterior también nos sirve para darnos cuenta de que si un consumidor de mensajes cae por algún fallo hardware o de la aplicación, el resto seguirá consumiendo mensajes. Al existir menos consumidores los mensajes tardarán más en enviarse pero el servicio no se detendrá. Esto facilita que el sistema sea más escalable porque tenemos la seguridad de que su funcionamiento global no se verá afectado por fallos en los componentes.

2/14

PAC1 Sistemas Distribuidos

2019

2. Describe the relationships between the following concepts: resource sharing, quality of service (QoS), SLA (service Level Agreement), isolation, security, and multi-tenancy.

Todos los conceptos están relacionados desde la visión actual del cloud computing y del modelo de distribución de software Software as a Service ( SaaS). En SaaS, las aplicaciones se pueden consumir como un servicio, accediendo a ellas a través de la web. En entornos cloud, la compartición de recursos es clave no sólo a nivel de infraestructura, sino también a nivel software. Las aplicaciones son utilizadas por distintos clientes para que la reducción de costes se haga efectiva y aumenten por tanto el número de usuarios y el negocio de los proveedores.

La mayoría de la empresas que ofrecen software como servicio incluyen SLAs a medida para cada tipo de usuario. De este modo, los clientes SaaS ejercer un mayor control sobre los proveedores respecto al software tradicional. Mientras que los proveedores SaaS están sujetos a los SLAs, con el software tradicional una vez realizada la venta, la responsabilidad de los vendedores es mucho más difícil de clarificar. Si los niveles de calidad de servicio no cumplen con los SLAs reflejados en el contrato, entonces los clientes pueden presionar con mayor fuerza legal a los proveedores Multi-tenancy es un patrón arquitectónico de las aplicaciones cloud, y es un componente clave en el éxito de una implantación de SaaS. Si aplicamos este modelo a SaaS, podemos agrupar varios clientes para compartir el uso de una misma aplicación y reducir los costes a nivel de hardware y software.

Una de las principales preocupaciones para la adopción de aplicaciones en multitenancy es la privacidad de los datos, el aislamiento y la seguridad. La confianza en el sistema depende de ellos y cualquier acceso no permitido puede provocar que la aplicación deje de usarse, además de afectar negativamente la reputación del proveedor y terminar incurriendo en disputas legales. En un modelo multi-tenancy podemos encontrar diferentes niveles de aislamiento ( aislamiento de datos, aislamiento de código, aislamiento de recursos, aislamiento de rendimiento ) que nos pueden indicar el nivel de madurez de la solución SaaS que estamos adquiriendo. 3/14

PAC1 Sistemas Distribuidos

2019

3. Compare the thin client/ fat server model with the fat client/thin server model with examples.

Una de las características del modelo cliente/servidor es que nos permite balancear la potencia de cálculo hacia un lado u otro según convenga. Cuando definimos las arquitecturas cliente servidor, consideramos la parte pesada como el componente que maneja la mayor carga de proceso o la lógica de la aplicación.

Niveles de un modelo cliente servidor: Nivel de presentación: Es el nivel que maneja la interacción con el usuario y actualiza la visualización apoyándose en la capa de aplicación. Nivel de aplicación: Controla la lógica de negocio de la aplicación donde se mantiene las reglas que definen la coherencia de los cálculos requeridos por el negocio. Nivel de datos: Suele ser donde residen los servidores de base de datos, y se encarga de almacenar y recuperar la información.

Cliente ligero / Servidor pesado: Este es el caso en el que la lógica de la aplicación reside en el servidor, normalmente junto con la base de datos si solo tenemos 2 capas, o en un servidor independiente si tenemos 3 o más capas.

Un ejemplo de este tipo son la mayoría de aplicaciones web de gestión que mantienen la lógica en servlets o microservicios en la parte servidora y solo dejan la parte visual al cliente que utiliza un navegador estándar.

Tenemos que hilar muy fino con esta distinción, actualmente y cada vez más existen muchas aplicaciones web que hacen un uso intensivo de javascript en el cliente. Aunque en apariencia sean clientes ligeros por el hecho de ejecutarse en un navegador, encontramos aplicaciones que tienen un mal desempeño porque ejecutan gran parte de la lógica en el lado del cliente, lo que las convierte en un cliente no tan ligero. Un ejemplo de estas aplicaciones podría ser Gmail, cada vez necesita más recursos para ejecutarse por la cantidad de javascript del lado del cliente, aunque esto permita que Google reduzca la carga en sus servidores.

4/14

PAC1 Sistemas Distribuidos

2019

Los clientes ligeros suelen ser menos escalables en la parte del servidor porque necesitan más capacidad de cómputo centralizada en los servidores, lo que obliga a adquirir hardware más costoso para centralizar la lógica de todos los clientes.

Cliente pesado / Servidor ligero: En este caso la lógica de la aplicación reside en la parte cliente y solo se transportan datos entre y hacia la capa del servidor.

La mayoría de las aplicaciones legacy que nos encontramos en el mercado, desarrolladas con herramientas tipo Visual Basic, Visual Foxpro, Delphi, etc. mantienen el grueso de la lógica en el cliente y solo envían los datos al servidor de base de datos. Debemos tener en cuenta que la lógica en la parte del cliente, reduce la capacidad de encapsulación respecto al acceso y la representación de los datos.

Por contra los clientes pesados son más fáciles de escalar, porque gran parte de la carga de la aplicación la realiza el cliente, lo que reduce el coste de adquirir grandes sistemas en la parte del servidor.

4. Compare the following communication models: pull/push, synchronous/asynchronous, stateless/stateful. Which ones are more scalable? Why? Push vs pull Distinguiremos dos términos: transacciones push y transacciones pull. Hay una diferencia entre ambas, y tiene que ver con quién inicia la comunicación en arquitecturas publicadorsuscriptor (arquitecturas donde los clientes se suscriben a las actualizaciones de un publicador, o a un tema disponible).

En la transacción push, el servidor inicia la transacción. Un ejemplo de esto podría ser un sistema de recuento de piezas fabricadas en un proceso productivo que envía la cantidad de piezas en tiempo real al operador de la máquina desde el plc. Es el servidor quien envía un mensaje al cliente para avisar de un cambio en la cantidad de piezas.

5/14

PAC1 Sistemas Distribuidos

2019

En la transacción pull, el cliente inicia la transacción. Si nos basamos en el caso anterior, el pc del operador realizará peticiones constantes al plc de la máquina para conocer si se ha producido un cambio en la cantidad de piezas fabricadas.

La tecnología push es más escalable, las peticiones sólo se envían cuando se produce un cambio de la información en origen, en este caso una pieza nueva que se haya fabricado. Por contra si utilizamos tecnología pull saturamos la red de peticiones repetidas aunque la máquina esté parada.

Ejemplos de pull en la web serían las peticiones http/1.1 el cliente envía una petición al servidor por cada recurso que solicita y push en http/2, cuando el browser/cliente solicita una página html el servidor envía la página más el resto de páginas que sean necesarias para cargar la web como css, imágenes, etc ..

Synchronous vs Asynchronous

Comunicación síncrona: El emisor envía una petición y espera a recibir una respuesta del receptor antes de continuar. Ambos deben estar activos. En una tarea síncrona debemos esperar a que la tarea termine para poder ejecutar la siguiente. Ejemplos de comunicación síncrona son la mayoría de aplicaciones legacy de gestión empresarial, que están desarrolladas sobre el modelo cliente pesado y servidor ligero, este tipo de aplicaciones suelen realizar las peticiones de consultas a la base de datos y esperan de forma síncrona a que el servidor ejecute la operación y devuelva la información.

6/14

PAC1 Sistemas Distribuidos

2019

Comunicación asíncrona: Una vez enviada la petición el emisor no espera la respuesta del receptor. El receptor puede tardar en contestar pero el emisor seguirá su proceso. Con una tarea asíncrona, podemos ejecutar la tarea siguiente sin esperar a la respuesta de la actual.

En el caso de comunicación asíncrona podemos utilizar como ejemplo las aplicaciones de chat, whatsapp, telegram, etc., se puede comprobar que todas la comunicaciones se realizan mediante colas y comunicación asíncrona. Cualquier aplicación de mensajería continúa respondiendo incluso si la comunicación física se pierde, lo que permite al sistema seguir respondiendo a las operaciones del usuario.

Debido a esto la comunicación asíncrona es mucho más escalable, al no tener que esperar el resultado para continuar con la siguiente tarea, el sistema responde y continúa funcionando sin bloquearse pudiendo ejecutar el siguiente trabajo en paralelo aunque no haya recibido la respuesta anterior.

Por contra la comunicación síncrona bloquea el sistema hasta que se devuelve el resultado, esto hace que las aplicaciones se congelen y no puedan seguir interactuando con el usuario o realizando otras tareas en segundo plano.

En esta figura se puede apreciar como la comunicación asíncrona termina el proceso antes que la síncrona por lo que podemos obtener un mayor grado de escalabilidad.

7/14

PAC1 Sistemas Distribuidos

2019

Stateless vs Stateful

La principal característica del modelo de comunicación stateless o sin estado, es que trata cada petición de forma independiente, sin que tenga ninguna relación con la solicitud anterior. Esto simplifica el diseño del servidor ya que no tiene necesidad de asignar recursos para mantener el estado de las comunicaciones en curso.

Un ejemplo de comunicación sin estado es la comunicación HTTP, este protocolo fue pensado para soportar un gran número de peticiones simultáneas y optimizar al máximo los recursos que necesita el servidor para gestionar la comunicación.

Aunque el protocolo HTTP no tiene estado, en la práctica, para la mayoría de los casos, es necesario añadir por parte del cliente algún tipo de información en los envíos, ( normalmente cookies o parámetros en la url ) que permita a las aplicaciones que residen en el servidor, mantener un control para detectar peticiones que provienen del mismo cliente.

En la figura podemos observar como la independencia del estado permite que haproxy envíe cada petición a un servidor web diferente si tener que preocuparse por el estado. Esto también podría conseguirse con una configuración round robin de los dns.

8/14

PAC1 Sistemas Distribuidos

2019

En el caso de la comunicación con estado o stateful, el servidor mantiene una asignación de recursos para mantener el estado de la comunicación, y asignar a la misma sesión los paquetes que llegan desde el cliente. El ejemplo más evidente sería una comunicación TCP donde después del handshake inicial cada comunicación posterior se identifica por una serie de parámetros ( ips, combinación de puertos, tamaño de la ventana, números de secuencia etc.. ) que permiten reconocer la sesión y mantener su estado.

Según las definiciones anteriores las comunicaciones sin estado serán mucho más escalables, el principal impedimento para la escalabilidad es la necesidad de mantener un estado compartido, que obligue al servidor a reservar recursos, que aumentarán con el número de conexiones, por lo que resulta evidente que una comunicación si estado consume menos recursos y es mucho más fácil de escalar vertical y horizontalmente añadiendo más servidores.

9/14

PAC1 Sistemas Distribuidos

2019

5. Read the following article and answer the questions: Serverless Computing: One Step Forward, Two Steps Back https://arxiv.org/pdf/1812.03651.pdf

a) Summarize the article and outline the major benefits and problems of the serverless FaaS model.

El artículo nos encuadra en el concepto de computación sin servidor (serverless ) o de funciones como un servicio (FaaS)

La computación sin servidor nos ofrece la posibilidad de programar la nube de forma automática y con sistemas de pago por uso, además de proporcionar sistemas de autoescalado. Como modelo de ejemplo el artículo se centra en la infraestructura de Amazon Web Services, por tratarse del proveedor más grande y que más tiempo lleva ofreciendo servicios de nube pública, centrando los ejemplos en el modelo AWS FaaS Lambda.

Las principales características de los sistemas Serverless o FaaS: Auto escalado: La carga de trabajo dirige automáticamente la asignación y desasignación de recursos. Pago por uso: Nos permite pagar sólo por los recursos de computación utilizados. Casos de uso que encajan en FaaS: Funciones altamente paralelas: Aplicaciones en las que cada invocación de una función es una tarea independiente y nunca necesita la comunicación con otras funciones. Ejemplos: re-dimensionado de imágenes, reconocimiento de objetos, etc.

Funciones de orquestación: Funciones que se utilizan para orquestar llamadas a servicios de auto-escalado. Ejemplos: Orquestar consultas analíticas ejecutadas por AWS Athena

10/14

PAC1 Sistemas Distribuidos

2019

Funciones de composición: Conjunto de funciones que se componen para crear aplicaciones, generalmente manipulan el estado y se diseñan como flujos de trabajo guiados por eventos, enlazadas entre sí mediante sistemas de colas como (SQS) o almacenes de objetos como (S3). Ejemplo: Plataforma de cuentas de Autodesk Principales ventajas de la arquitectura serverless o FaaS: Infraestructura delegada, sin necesidad de costosas configuraciones ni mantenimientos Infraestructura auto-escalable, los proveedores se encargan de realizar el escalado automático. Pago por uso, solo pagamos por los recursos que se utilicen. Principales desventajas: Altas restricciones a la capacidad de trabajar eficientemente con datos o recursos informáticos distribuidos. Vendor lock-in: Al utilizar Faas nos casamos con el proveedor de servicios, las soluciones actuales son altamente propietarias. Entornos limitados: Entornos de programación, lenguajes y librerías limitadas a las ofrecidas por el proveedor. Al tratarse de servicios sin estado, las operaciones que tengan que recordar el estado deberán apoyarse en otros servicios, que por norma general terminarán siendo servicios propietarios ofertados por el proveedor. Vida útil de las funciones limitada: En el caso de AWS después de 15 minutos las invocaciones son desactivadas, y no se puede garantizar que las siguientes invocaciones se ejecuten en la misma máquina virtual. Cuellos de botella de E/S: Los lambdas se conectan a los servicios de la nube por una interfaz de red, la ejecución de múltiples funciones en el mismo servidor virtual, limita el ancho de banda asignado a cada función.

11/14

PAC1 Sistemas Distribuidos

2019

Falta de hardware especializado: Actualmente no hay hardware especializado, que mejore el desempeño de las soluciones FaaS, aunque es posible que esto cambie en los próximos años, si se produce un crecimiento en la demanda de estas soluciones.

Casos de estudio: Modelo de aprendizaje automático con TensorFlow, entrenando una red neuronal de predicción de valoraciones medias de los clientes. Se aprecia que la solución que se implementa en FaaS es más lenta y costosa que su solución implementada en una instancia de AWS. Servicio de predicción de baja latencia por lotes, usando un modelo entrenado para realizar predicciones en vivo. Se utiliza una sencilla aplicación en lambda que canaliza el trabajo de dosificación realizado por SQS con un clasificador que utiliza funciones lambda. En el segundo ejemplo se utiliza ZeroMQ en vez de SQS. Comparando los tiempos y los costes de implementar este caso con lambda vs instancias de EC2 vuelve a ser más eficiente y económico no utilizar lambdas para realizar el despliegue. Estudio de si el almacenamiento en la nube es un medio de comunicación razonable entre lambdas. Se implementa un caso de agentes distribuidos, con DynamoDB que pone de manifiesto que la comunicación a través de almacenamiento no es un sustituto razonable si lo comparamos con la comunicación basada en redes con dirección directa, incluso si el almacenamiento se produce con E/S direc...