PDF de programación - 5 Servicio de Nombres - Sistemas Distribuidos

Sistemas Distribuidos

Fernando Pérez Costoya

Índice

Sistemas Distribuidos

Servicio de
Nombres

Introducción

•
• Servicio de nombres

– Estudio de un ejemplo práctico: DNS

• Servicio de directorio

– Estudio de un ejemplo práctico: LDAP

• Descubrimiento de servicios

Sistemas Distribuidos

2

Fernando Pérez Costoya

Una historia basada en hechos reales

Una historia basada en hechos reales

• Quiero contactar con persona en un contexto para pedirle algo

– Contexto: una organización, una ciudad, un país, el mundo, ...
– Necesito su dirección de contacto (p.e. nº teléfono en ese contexto)
– Nombre (quién) [permanente] → Dirección (dónde) [transitorio]

– Veremos que nombres y direcciones no son tan diferentes…

• Servicio telefónico “páginas blancas” (Servicio de nombres)
– Necesito conocer nº teléfono de servicio de guía del contexto dado
– Y especificar la persona con “nombre” unívoco en ese contexto

• Nombre/apellidos | nº empleado | nº DNI

– Guía proporciona nivel de indirección respecto a dirección contacto

• Permite que persona cambie nº tfno (cuidado con agenda-caché)

– Puede requerirse cadena de consultas; ¿nº tfno empleado?:

• 1º obtengo nº tfno empresa; 2º centralita empresa me da tfno empleado

• Nombres y direcciones suelen tener carácter jerárquico

– Facilita su administración y gestión
– Ejs. Nombres: ID empleado internacional (ISBN, cuenta bancaria, ...)

• Cambio de recurso en jerarquía puede invalidar el nombre

– Ejs. Direcciones: nº teléfono o dirección postal
– Encaminamiento jerárquico

• A veces quiero contactar con cualquiera que dé un servicio

– Necesito conocer condiciones de servicio para elegir

• Servicio telefónico “páginas amarillas” (Servicio de directorio)
• ¿Y si ni siquiera sé nº tfno. de servicios de guía (o no los hay)?

– Quizás debería gritar pidiendo ayuda
– Descubrimiento de servicios

Sistemas Distribuidos

3

Fernando Pérez Costoya

Sistemas Distribuidos

4

Fernando Pérez Costoya

5-Servicio de nombres

1

Sistemas Distribuidos

Fernando Pérez Costoya

URI: Uniform Resource Identifier

Ejemplo: Niveles de traducción de URL

• 2 tipos de identificadores de recursos URIs en Internet:

– Nombres URNs y direcciones URLs

• Uniform Resource Name: Nombre (qué) [permanente]

– Identifican recurso sin incluir información de localización
– Requiere un proceso de traducción

• Uniform Resource Locator: Dirección (dónde) [¿transitorio?]

– Pueden verse afectados si recurso “se mueve”
– Algunos URL se pueden considerar permanentes

• Ejemplos wikipedia URN vs. URL

– urn:ietf:rfc:3187
– http://tools.ietf.org/html/rfc3187.html

http://www.datsi.fi.upm.es/informacion.html

DNS

IP 138.100.9.22 | Puerto 80 TCP

ARP

httpd

00:26:B9:2D:DE:5B

/usr/local/apache2/htdocs/informacion.html

URL queda inválido sólo si
cambio dominio o puerto

SF

Disco 0; partición 4; inodo 321689

Sistemas Distribuidos

5

Fernando Pérez Costoya

Sistemas Distribuidos

6

Fernando Pérez Costoya

Servicio de nombres

• Nombre de entidad en SD → punto(s) de acceso a la entidad

– Sockets: Dir(s) IP+ puerto(s)+ protocolo(s)
– RMI o CORBA: referencia(s) a objeto(s)

• Nombre permite referirse a una entidad única en SD

– Aunque puede estar replicada (p.e. fichero en Coda)
– y puede haber varios nombres para la misma entidad (alias)

• Hay diversos tipos de entidades en SD

– ficheros, usuarios, grupos, procesos, dispositivos, máquinas, ...

• Serv. de nombres específicos para algunos tipos de entidades

•

– para ficheros (SFD), para máquinas (DNS), ...
Ideal: servicio de nombres integral para todas las entidades
– Excepto ficheros por gran volumen y frecuencia de actualizaciones

Jerarquía de nombres
• SD incluye muchas entidades muy diversas

– Como SFD, organización jerárquica facilita asignación y gestión

• Impresoras de distintos departamentos con el mismo nombre

• Espacio de nombres jerárquico

– Entidades contenedoras de otras entidades (directorios)

• Traducción de nombres (pathnames):

– Proceso iterativo que parte de un nodo inicial

• Necesidad de conocer traducción de nodo inicial
• Absoluta (nodo raíz) vs. Relativa (nodo intermedio)

– Proceso costoso: Uso de caché en traducción

• Información inválida si migración
• Garantía de validez vs. coste de mantener la coherencia de la caché
• Muchos servicios de nombres pueden devolver información obsoleta

Sistemas Distribuidos

7

Fernando Pérez Costoya

Sistemas Distribuidos

8

Fernando Pérez Costoya

5-Servicio de nombres

2

Sistemas Distribuidos

Fernando Pérez Costoya

Implementación de servicio de nombres

Distribución y replicación

• Operaciones del servicio de nombres

– Asociar/Desasociar nombre con una entidad; Crear directorio
– Traducir nombre

• No factible uso de servidor de nombres único:

– Problemas de escala, rendimiento y fiabilidad

• Espacio de nombres partido y distribuido entre servidores
– Se requiere info. que “monte” particiones para formar árbol único
– Cada partición gestionada por (al menos) un servidor
– Mismas alternativas de navegación que en SFD

• Posibilita administración distribuida

• Iterativa, Transitiva y Recursiva

• Partición replicada en varios servidores

– Fiabilidad y rendimiento, pero hay que asegurar coherencia
– Esquema simétrico:

– Fiabilidad: mejor réplicas en distintas subredes

• Consulta a cualquier réplica
• Actualización simultánea en todas las réplicas

– Esquema asimétrico: 1 primario/maestro y N secundarios/esclavos

• Consulta a cualquier réplica
• Actualización en primario con propagación a réplicas (Modo push o pull)

• Tres técnicas para paliarlos:

– Caché de traducciones
– Distribución de espacio de nombres
– Replicación de espacio de nombres

• Caché de traducciones:
– Problema de coherencia
– En DNS: No hay garantía

• Servidor retorna TTL (“tiempo de vida”) de información

Sistemas Distribuidos

9

Fernando Pérez Costoya

Sistemas Distribuidos

10

Fernando Pérez Costoya

Implementaciones alternativas

Domain Name System (DNS)

• Uso de broadcast/multicast:

• ¿Dónde está recurso de nombre N?
• No aplicable a SD propósito general (mala escalabilidad y eficiencia)
• Uso en descubrimiento servicios o para aspectos específicos (ARP)

• Uso de DHT

• Al fin y al cabo es un mecanismo de traducción

• Uso de cadenas de ubicación probable
• Aplicable a sistemas con recursos móviles
• Cuando recurso migra, antigua ubicación almacena la nueva
• Se crean cadenas de ubicación probable de un objeto
• Localización sigue cadena hasta encontrar ubicación actual
• Si respuesta atraviesa cadena, intermediarios saben nueva ubicación
• El recurso puede tener un nodo home

• Servicio de nombres de máquinas en Internet: nombre → IP

– No es un serv. nombres general pero ilustrativo por escalabilidad
– Diseño genérico: aunque uso habitual nombre de máquinas Internet
– Inicios de Internet: fichero HOST que se actualizaba periódicamente

• Espacio de nombres de DNS jerárquico

– Nombre: secuencia de dominios (≈directorios) de dcha. a izda.

• www.datsi.fi.upm.es. → . + es + upm + fi + datsi

• Dominio raíz: . → Caminos absolutos (FQDN) terminan con .
• Dominios nivel superior (TLD)

• gTLDs: genéricos (com, org, ...)
• ccTLDs: por país (¿qué pasa con el de Tuvalu?)

• De segundo nivel, de tercero, ...
Implementación más usada BIND

•

Sistemas Distribuidos

11

Fernando Pérez Costoya

Sistemas Distribuidos

12

Fernando Pérez Costoya

5-Servicio de nombres

3

Sistemas Distribuidos

Fernando Pérez Costoya

Espacio de nombres distribuido: Zonas
• Zona DNS: partición del árbol global (zona ≠ dominio)

Información recursos de un dominio y sus subdominios no delegados

•
• Delegación de dominios

• Un subdominio puede tener su propia zona
• Dominio padre incluye “punto de montaje” a esa zona subordinada

• Diseño habitual: delegar todos los subdominios
• Una zona para cada dominio (zona ≈ dominio)
• Incluso a veces a los mismos servidores que el dominio del que cuelgan

• Cada zona está replicada:

• 1 servidor maestro/primario y N (al menos 1) esclavos/secundarios
• Fiabilidad: mejor réplicas en distintas subredes
Información contenida en una zona:
• Colección de Resource Records (RR) que describen sus recursos

•

Resource Record

• Definición de un recurso: Nombre Tipo Clase TTL Datos

• Clase IN para Internet (otros HS, para Hesiod, y CH, para Chaos)
• NOTA: Nombre puede tener * a la izqda. (wildcard RR; no lo tratamos)

• Fichero de zona:

• Fichero de texto en primario define RRs de una zona: 1 RR/línea

• Aunque RRs se transmiten en binario
•
Incluye RRs de recursos del dominio y de subdominios no delegados
• Sintaxis definida para facilitar introducción de datos en fichero de zona
• Macros, caracteres especiales, caminos relativos, omisión de campos,...

• Diversos tipos de RRs

• Nos centramos en SOA, A, AAAA, PTR, CNAME, MX, SRV, TXT y NS
• No tratamos los RRs relacionados con la extensión DNSSEC

• Proporciona autenticación e integridad en DNS

Sistemas Distribuidos

13

Fernando Pérez Costoya

Sistemas Distribuidos

14

Fernando Pérez Costoya

RR de tipo SOA (Start of Authority)

RR de tipo A o AAAA

• Comienzo de definición de una zona
• Ejemplo de definición en fichero de zona (wikipedia)
example.com. IN SOA ns.example.com. username.example.com. (

2007120710 ; serial number of this zone file
1d ; slave refresh (1 day)
2h ; slave retry time in case of a problem (2 hours)
4w ; slave expiration time (4 weeks)
1h ; maximum caching time in case of failed lookups (1 hour)
)

• Ejemplo de consulta: dig fi.upm.es. SOA
fi.upm.es. 86400 IN SOA chita.fi.upm.es. hostmaster.fi.upm.es. 2013102101 28800 7200 2419200

3600

Dominio; TTL; Clase Internet; Start Of Authority; S. maestro; responsable; nº serie (incrementar si cambio);
Periodo de actualización de secundario; Tiempo de reintento de secundario antes actualización fallida;
Tiempo de expiración de info. de secundario ante actualización fallida; TTL para cac