PDF de programación - Aplicaciones operacionales distribuidas geográficamente

Aplicaciones operacionales
distribuidas geográficamente

Mangesh Kasbekar

8 de mayo de 2002

Resumen del coloquio

1. Introducción y motivación
2. Problemas con el modelo de aplicación distribuido

geográficamente

3. Fundamentos básicos de las transacciones
4. ¿Puede ser útil una reconsideración de los modelos de aplicación?
5. Conclusión y P & R

Resumen del coloquio

1. Introducción y motivación
2. Problemas con el modelo de aplicación distribuido

geográficamente

3. Fundamentos básicos de las transacciones
4. ¿Puede ser útil una reconsideración de los modelos de aplicación?
5. Conclusión y P & R

Introducción y motivación

Plataforma común de aplicación web:

Introducción y motivación

El modelo común de aplicación web de 3 niveles:

– Nivel web para la presentación de contenido
– Nivel medio para la tramitación de solicitudes y la lógica de negocios
– Nivel de base de datos para información y transacciones continuas

Introducción y motivación

Una aplicación web típica en un sitio de comercio electrónico

SW

SA

BD

S1

S2

Id elem. Nombre

Color

Transacción:

Seleccione * de los productos donde el

Nombre = `shirt´ y el Color = ‘blue’

Introducción y motivación

Problemas con aplicaciones centralizadas

– Cuestiones de fiabilidad:
• Único punto de fracaso
• Un único fallo puede afectar potencialmente a miles de usuarios

simultáneos

– Cuestiones de disponibilidad:

• Los problemas de partición o conectividad de Internet pueden

hacer que el sitio sea inalcanzable desde alguna parte de Internet

• El volumen alto de tráfico inesperado puede saturar los enlaces de red

– El rendimiento del sitio, tal y como lo ven los usuarios finales, es impredecible

Introducción y motivación

Introducción y motivación

Una solución:
Reproducción y distribución geográficas del sitio

Servidores
de borde Servidor
de origen

Introducción y motivación

– Los servidores de borde ejecutan el nivel web
– Los servidores de borde ejecutan el nivel web y el nivel medio
– Reproducción completa del sitio: todos los servidores

de borde contienen los tres niveles de la aplicación, con
bases de datos reproducidas.
– Los servidores de borde ejecutan el nivel web, el nivel medio
y poseen una caché de base de datos, no una base de datos
completa

Introducción y motivación

Otros ejemplos de aplicaciones distribuidas geográficamente

– Utilización de servicios web disponibles en algún punto de Internet
– Informática de red, utilizando ciclos libres de máquinas para el

cálculo en el ámbito global

Introduction and Motivation

Requisitos básicos para las aplicaciones distribuidas
– exactitud
– como mínimo, el mismo nivel de rendimiento
– como mínimo, el mismo nivel de fiabilidad
– mejor disponibilidad

Otros requisitos
– seguridad
– control
– manejabilidad

Resumen del coloquio

1. Introducción y motivación
2. Problemas con el modelo de aplicación distribuido

geográficamente

3. Fundamentos básicos de las transacciones
4. ¿Puede ser útil una reconsideración de los modelos de aplicación?
5. Conclusión y P & R

Problemas con el modelo

Problemas:

– Una plataforma muy poco fiable
– Las transacciones y la inescalabilidad de esquemas

de reproducción de bases de datos

– La consistencia de las réplicas de aplicación
– Por último, el teorema CAP

Problemas con el modelo

Plataforma:
– Latencias, pérdidas y congestiones muy elevadas:
– tiempo de respuesta de latencias de 20ms a 1000ms
– 2% a 20% de pérdida de paquetes

– Enrutamiento no satisfactorio/routers mal configurados
– Los países asiáticos se conectan a través de Los Ángeles
– De Nepal a Bombay, alrededor del mundo

– Divisiones frecuentes de la Red

Comparar con un entorno LAN/Server farm (agrupación centralizada de servidores)

Problemas con el modelo

Reproducción de bases de datos:
– Esquema rápido: las actualizaciones de todas las transacciones
se propagan a todas las réplicas antes de poder ser ejecutadas
– Consistencia estricta entre las réplicas
– Imposibilidad de escala; exceso de comunicación
– Se bloquea durante las divisiones de red
– El peligro de interbloqueo es alto

– Esquema lento: la actualización de las transacciones se ejecuta

sin actualizaciones de propagación, y las actualizaciones se
propagan a las réplicas de forma muy lenta
– Consistencia débil entre las réplicas
– Alto grado de colisiones entre transacciones, a menudo se necesita una compensación

Problemas con el modelo

Problemas con las transacciones en zonas extensas:

• Transacciones más largas: utilización deficiente de recursos
• Sin autonomía: si no hay un coordinador disponible, no se puede

ejecutar una transacción

• El protocolo 2PC detecta todos los problemas por medio de tiempos límite:

– Mayor oportunidad de fallos debido a las divisiones
– Tiempos límite más largos
– Mayor tiempo de bloqueo para los participantes
– Mayores oportunidades de decisiones de compromiso heurístico

Problemas con el modelo

Consistencia de las réplicas de aplicación

– Aplicaciones con alta capacidad stateful (configuración predeterminada)
– Es necesario reproducir el estado para evitar los fallos en los

sitios individuales

– Es necesario mantener una consistencia en las réplicas en el caso

de que si un usuario individual es atendido por dos máquinas
diferentes en una única sesión no haya inconsistencias.

– Actualizaciones rápidas
– Actualizaciones lentas

Problemas con el modelo

El denominado teorema CAP:

Teorema:
Se pueden tener como máximo dos de tres

Ej.
• Las bases de datos de grupos escogen A y C
• DNS escoge A y P

Consistencia

Disponibilidad

Tolerancia a las

divisiones

de red

Problemas con el modelo

Por fin, algunas buenas noticias

Para las aplicaciones de red,
– Un alto porcentaje de los accesos de las bases de datos
son transacciones de sólo lectura (no es necesaria una
propagación de actualización de las réplicas)

– Como un amplio volumen de datos está cambiando lentamente,
el caching de las bases de datos del borde puede ser de ayuda

– Un buen porcentaje de escritos no entran en conflicto

(único autor)

Resumen del coloquio

1. Introducción y motivación
2. Problemas con el modelo de aplicación distribuido

geográficamente

3. Fundamentos básicos de las transacciones
4. ¿Puede ser útil una reconsideración de los modelos de aplicación?
5. Conclusión y P & R

Fundamentos básicos del procesamiento de transacciones

Propiedades de las transacciones

• Propiedades ACID
• Capacidades de serialización y de recuperación
• Niveles de aislamiento

Fundamentos básicos del procesamiento de transacciones

¿Qué es una transacción?

Una acción de software compuesta que se inicia con una
orden begin , realiza varias operaciones read/write s
en los datos y finaliza bien con una orden commit o con
una orden abort . Ejemplo:

Begin, r(x), r(y), w(x,1), w(y,0), commit.
Begin, r(x), w(x,2), r(y), r(z), abort.

Fundamentos básicos del procesamiento de transacciones

Propiedades ACID de una transacción:
- Atomicidad
- Consistencia
- Aislamiento
- Durabilidad

Fundamentos básicos del procesamiento de transacciones

Atomicidad:
propiedad de todo o nada

Begin, r(x), r(y), w(x,1), w(y,0), commit.
Begin, r(x), r(y), w(x,2), w(y,1), r(z),
abort.

Fundamentos básicos del procesamiento de transacciones

Consistencia:
Cualquier conjunto de transacciones que se ejecute simultáneamente
no dejará la base de datos en un estado inconsistente.

Begin, r(x), r(y), w(x,1), w(y,0), commit.
Begin, r(x), r(z), w(x,5), w(y,10), commit.

Fundamentos básicos del procesamiento de transacciones

Aislamiento:

Una transacción no interferirá en la ejecución de otra transacción
que se esté realizando simultáneamente.

Begin, r(x), r(y), w(x,1), w(y,0), abort.

Begin, r(x), r(z), w(x,5), w(y,10), commit.

Fundamentos básicos del procesamiento de transacciones

Durabilidad:
Persistencia de datos después de una confirmación (commit).

Begin, r(x), r(y), w(x,1), w(y,0), commit.

Fundamentos básicos del procesamiento de transacciones

Ejemplo : transferencia de dinero entre dos cuentas bancarias

function Transfer ( from , to , amount ) {

begin transaction ;
if ( from.balance < amount ) {

abort transaction ;
return ;

}
from.balance -= amount ;
to.balance += amount ;
commit transaction;

}

Fundamentos básicos del procesamiento de transacciones

Las transacciones ACID son serializables:

Cuando un conjunto de transacciones se ejecuta simultáneamente, sus operaciones
pueden ser intercaladas. La ejecución concurrente se establece por un historial
(que no es nada más y nada menos que una orden parcial de operaciones).

Un historial es serializable en vistas (view-serializable) si existe una ejecución
serial posible de las operaciones, de tal forma que, en ambas ejecuciones (tanto
concurrentes como seriales), cada transacción lee los mismos valores y los
valores finales de la base de datos son iguales.

Un historial es serializable en conflicto (conflict-serializable) si existe una ejecución
serial posible de las operaciones, de tal forma que, en ambas ejecuciones (tanto
conscurrentes como seriales), el orden de las operaciones en conflicto es el mismo.

Fundamentos básicos del procesamiento de transacciones

Capacidad de recuperación:
Para poder mantener una exactitud de la presencia de fallos, es
necesario que los historiales de ejecución sean recuperables
además de serializables. No todos los historiales son recuperables.

• Un historial es recuperable si cada transacción se confirma
después de la confirmación de otras transacciones a partir
de las cuales leyó.

• Un historial recuperable evita las cancelaciones en cascada si

lee valores escritos únicamente por transacciones confirmadas.

Fundamentos básicos del procesamiento de transacciones

¿Por qué es im