7.5 KiB
TEMA 1: Introducción a los sistemas distribuidos
El paradigma clásico cliente-servidor es lo que se llama centralizado. Un ejemplo de arquitectura distribuida sería una red P2P (como torrent). Y por último un ejemplo de red descentralizada sería una red como la red Tor.
1. Introducción a los SSDD
Qué es un sistema distribuido
Un sistema distribuido es un conjunto de computadores débilmente acoplados (independientes) interconectados a través de una red que colaboran para realizar una tarea. Los orígenes se remontan a los años 80:
- Principios de los 80: Los computadores son máquinas costosas y muy grandes. Sistemas operativos multiusuario de tiempo compartido.
- A partir de los años 80: Auge de los computadores personales. Bajo coste. Avances tecnológicos continuos. SO monousuario.
- A partir de los años 90: Aparecen las redes de computadores de alta velocidad (LAN y WAN).
Propiedades de los sistemas distribuidos
- Concurrencia de los componentes: no se habla ya de concurrencia a nivel de componente del computador, si no de los distintos computadores que componen el sistema.
- Carencia de un reloj global: no existe un reloj que sincronice todos los computadores, sino un coreógrafo que se dedica a hacerlo.
- Fallos independientes de los componentes: si falla una máquina se balancea la carga a otras máquinas.
- Uso de un sistema de comunicación: WAN, LAN, etc.
- Ausencia de memoria común: entendiendo como memoria, la física (RAM, HD). Sin embargo, puede y hay BD compartida.
- Sincronización del trabajo
- Ausencia de un estado global
- Comunicación a través de mensajes
Ejemplos de sistemas distribuidos
- Internet
- Intranet
- Computación móvil y ubicua: computación que se puede llevar a cabo en cualquier lugar
- Redes P2P
- Grid computing: paralelizar el problema a resolver con varios equipos para reducir el tiempo de resolución. De ahí viene el nombre de "grid" es una cuadrícula de equipos en paralelo.
- Redes de sensores
- Red bancaria
- Servidor FTP
- BD distribuidas
2. Características de los SSDD
El principal objetivo de un SD es que el sistema se presente a los usuarios como un único computador monoprocesador virtual. Para ello se persiguen los siguientes conceptos:
| Transparencia | Descripcion |
|---|---|
| Acceso | Diferencias en la representación de los datos y como acceder a los recursos |
| Localización | Dónde se encuentra un recurso |
| Migración | Que un recurso pueda moverse de un lugar a otro |
| Relocalización | Que un recurso pueda moverse de un lugar a otro mientras está en uso |
| Replicación | Que puedan existir réplicas de un recurso |
| Concurrencia | Que un recurso pueda ser compartido por varios usuarios |
| Resiliencia | Permitir la recuperación de un recurso en caso de fallos sin que se vea afectado |
| Persistencia | Que un recurso pueda estar en memoria o en disco |
Seguridad en SSDD
En un sistema distribuido la información se transmite entre los diferentes nodos del mismo mediante paso de mensajes. Hay varios requisitos para garantizar la seguridad:
- El emisor debería saber que su mensaje se ha recibido.
- El receptor de un mensaje debería saber que el que le ha enviado el mensaje es el emisor adecuado.
- Tanto el emisor como el receptor deberían tener garantías de que los mensajes no son observados ni alterados durante la transmisión (no hay un ataque MITM).
Rendimiento en SSDD
La existencia de más recursos debería permitir que las apps se ejecuten más rápido en un SD que en uno centralizado. Sin embargo, hay algunos problemas:
- Las apps tienen que ser paralelizadas
- Minimizar el tráfico de red
- Equilibrio de carga
- Conseguir que un SD sea transparente, flexible y fiable
Heterogeneidad
Un SD se puede componer de conjuntos de computadores que pueden difrerir tanto en HW como en SW, esto implica que pueda haber incompatibilidades:
- Los CPUs y lenguajes no usan la misma representación de los datos
- Gran diversidad de protocolos
### Plataformas de computación en la nube
#### Amazon Web Services (AWS)
!
#### Google Cloud Platform (GCP)
!
#### Microsoft Azure
!
## 5. Problemas
- **Compatibilidad de tipos de datos:** distintos SO que tienen distintos tipos de datos que no siempre son compatibles entre sí.
- **Fallos del servido:** debido a que los componentes pueden ser remotos, un fallo de cualquiera puede hacer que toda la app falle.
- **Fallos del cliente:** el servidor debe saber como responder a fallos del cliente.
- **Reintento de llamadas:** si se hace una llamada a un método en un servidor para generar una orden de compra muy grande, y el servidor responde, pero se pierde la respuesta por un fallo de red, no es muy eficiente volver a enviar la orden de compra.
- **Seguridad:** autenticar a los usuarios, cifrar la información que viaja por la red, evitar DDoS, etc.
- **Sincronización de la hora:** para que no haya incoherencia con la hora real.
- **Formato de los datos**
- **Disponibilidad de los servidores**
- **Acceso a los sistemas de forma remota**
- **Posibilidad de ver los datos por muchas personas**