Datenverwaltung in Rechnernetzen...Name hinzufügen 1 HEINZ NIXDORF INSTITUT Universität Paderborn...

Name hinzufügen 1

HEINZ NIXDORF INSTITUT

Universität PaderbornAlgorithmen und Komplexität

Datenverwaltungin Rechnernetzen

SS07Vorl. 7, 04.6.07

Friedhelm Meyer auf der Heide

(Exkurs: Mario Mense)

Name hinzufügen 2



Recap: Parallel Random Access Machine

- Realisierung durch Simulation auf DMMs

- Deterministische und probabilistische Ansätze

Name hinzufügen 3



Recap: Our goals

Support efficient (quick) access to global objects in networks.

Global objects:

- global variables in parallel programs

- pages or cache-lines in virtual shared memory systems

- files in distributed file servers

- (multimedia) information in distributed data servers

- web content in the internet

Name hinzufügen 4



Recap: Scenario I

Networks have high bandwidth, local access to data items is slow. (Data items are large, are stored in secondary memory (disks).)

• typical for, e.g., distributed data servers (or storage networks)

• bottleneck: Contention at memory modules

task: Distribute objects among modules, and designaccess protocols such that

• Contention is very small,• Link-Congestion is small,• storage overhead is small,• access protocols are efficient.

Name hinzufügen 5



The Storage (Area) Network

NetworkNetwork

D1

D2

D3

D4

Dn

C1

C2C3

C4

Cn

B1

B2B3

B4

Bn

Name hinzufügen 6



Exkurs: Storage (Area) Network (SAN)

Charakteristik (SAN):

• vollständiger bipartiter Graph (G=(V1 V2, E))• Zugriff nur von V1 (servers) nach V2 (storage) • simultaner globaler Zugriff auf alle Module

Aufgabe: Verteilen der Objekte über die Module und Design eines Zugriffsprotokolls, so dass

• Contention(Anfragelast) pro Modul ist klein,• Speicheroverhead ist klein,• Zugriffsprotokoll ist effizient,• Hohe Datenverfügbarkeit,• Dynamischer I/O ist berücksichtigt,• Systemskalierung ist effizient und online behandelt,• Nicht-uniforme Module sind berücksichtigt

Name hinzufügen 7



Contention (Anfragelast)

Ziel: schneller Zugriff auf die Daten (vgl. PRAM-Simulationen)

Problem hier: hohe I/O-Kosten (Systemlatenz) durch

• Langsamer Datenzugriff in den Modulen

⇒ (Flaschenhals: 9 ms (Disk) vs. ≈ 10-100 ns (RAM))

• Zugriff auf meist junge Daten (80/20-Regel)

⇒ hohe I/O-Belastung einer kleinen Teilmenge der Module

Indiana

Jones

Tele-

kolleg

1-100

ArchivTrash

Indiana

Jones

Tele-

kolleg

1-100

ArchivTrash

Name hinzufügen 8



Contention: Load Balancing

Lösung: gleichmässige Verteilung von Daten/Anfragen über die Module (Lastbalancierung)

• Blockweises Verteilung von I/O-Anfragen (striping) über Module

⇒ Ausnutzung von Parallelismus

• Balancierung:

– deterministisch (z.B. RAID; vgl. Übungsaufgabe 8)

– randomisiert (Hashing) (vgl. Skript bzw. Übungsaufgabe 1)

Indiana

Jones

Name hinzufügen 9



Dynamischer I/O und Systemskalierungen

Charakteristik:

• I/O-Anfragen als online-Spiel

• System skaliert (Storage-on-demand, Alter der Module, …)

Problem: Feste Zuordnungsschemata fordern Reorganisation ALLER Daten (Downtimes sind nicht akzeptabel !!)

⇒ Adaptive Datenplatzierungsschemata gefordert: Replatzierung des möglichst geringsten Datenanteils (Bewertung: Competitive Analysis))

Adaptivität:

• Deterministische Verfahren: eingeschränkt

– meist: fixe Stripesize (z.B. RAID);

– Ausnahmen: online-RAID-expansion (ORE), RW-Codes

• Hashverfahren: bislang nicht (vgl. Skript)

(betrachte z.B.: )

Name hinzufügen 10



Genauer: Das Speichernetz als Hash-Tabelle

• Jedes Speichermodul i=0,..,n-1 ist Behälter (Bucket) für m Datenobjekte

– Platzierung: mittels Hashfunktion z.B. H: K→ N, K sei eindeutiger Bitstring

. . . .

1 2 3 n-1

prog1

apple

foo pearbarrao

d.htmc:pp

H(„orange“)

Buckets

Name hinzufügen 11



Consistent Hashing (Idee)

• Skalierung: Wegfall eines Speichermoduls

a) Bislang: inkonsistentes Hashing: neue Hashfkt. ⇒ komplette Replatzierung �

b) Neu: consistent Hashing: nur Nachbarn sind von Replazierung betroffen ☺

. . . .

1 2 3 n-1

prog1

apple

foo pearbarrao

d.htmc:pp

. . . .

1 2 3 n-1

prog1

applefoo

pear

barraod.htmc:pp

. . . .prog1

apple

foopear

bar rao

d.htmc:pp

1 2 3 n-1

Name hinzufügen 12



Distributed Hash-Table (DHT)

Idee (benutzt consistent hashing):

• Aufweichen des starren Gerüsts

• Module werden an eine Stelle in best. Bereich (z.B. [0,1)-Intervall) gehasht

• Jedem Modul wird ein Bereich um seinen entspr. Hashwert zugeordnet

• Datenobjekte werden auch gehasht: Zuordnung zu genau einem Bereich

Name hinzufügen 13



Einfügen in DHTs

Distributed Hash-Table:

• Module werden in Bereich gehasht• Dokumente ebenso• Jedes Modul verantwortet einen Bereich

Kommt ein neuer Knoten hinzu:

• müssen die Nachbarn teilen

Verläßt ein Knoten das Netzwerk:

• übernehmen die Nachbarn sein Gebiet

Name hinzufügen 14



ConsistentHashing: Effizienz

• Betrachte Anordnung in [0,1)-Intervall (als Modulo-Ring)

• Zufällige Hashfunktion fB für Hashen der Blöcke in das [0,1)-Intervall• k zufällige Hashfunktionen g1,…, gk, gj: {1,…,N}→ [0,1) pro Bin

• fB(b): Blockpunkt, gk(i): Binpunkt

• Bin bi speichert alle Blöcke b, für die gilt:

gj(i) fB(b)0 1

aij

Name hinzufügen 15



DHTs: Eigenschaften

Vorteile:

– effizientes Load Balancing per Hashfunktion

– Suchen und Ersetzen in O(1) möglich

– Oblivious bzgl. join/leave der Datenobjekte

– Adaptiv bzgl. Systemskalierung

Nachteile:

– Balancierung der Bereichsgrößen erfordert k=Θ(log n) Kopien (d.h. Speichern der k Hashfunktionen)

– nur auf homogene Buckets (Speichermodule) anwendbar

– nicht gedundant (d.h. geringe Datensicherheit)

Name hinzufügen 16



Share: Behandlung nicht-uniformer Module

Share: Zwei universelle Hashfkt. h und g:

– h(d) → [0,1) abbilden der Daten zufällig ins das [0,1)-Interval

– g(b) → [0,1) abbilden der Module (Buckets) zufällig in das Intervall

2 Phasen: – 1.) Reduktionsphase

– 2.) Anwendung einer uniformen Platzierungsstrategie (consistent hashing)

0 1

I1

I2

I3I4 I5

I6

Fj

g(i)

h(b)

Name hinzufügen 17



Praxis: Speichervirtualisierung

Status Quo: Exponentielles Datenwachstum und stetiger Zugriff erfordert

– Speicherkonsolidierung

• Trennung von Speicher und zugreifenden Clients

• Zusammenfassung versch. Elemente in einheitlichem System (SAN)

⇒ Speicher Management (Anforderungen):

• Dynamischer Umgang mit exponentiellem Datenwachstum

• Unterstützung heterogener Teilnehmer (Speicher, Betriebssysteme)

• Einfacher Zugriff für den Benutzer (Benutzerinterface)

• Integration verschiedener Speicherpolicies

• Erhöhung der Datensicherheit

Name hinzufügen 18



Speichervirtualisierung

• Abstraktion des Speichers, die eine Trennung zwischen Host-Sicht und Speicherimplementierung vornimmt

• Verbirgt für den Host:

– Physikalische Verbindung zum Speichersystem

– Charakteristiken des Speichersystems

– Exakten Ort der Datenspeicherung

• Dynamisch

– Ermöglich „On-the-fly Konfiguration“ und Skalierung

– Daten sind für den Host transparent verschiebbar

• Verschiedene Arten der Umsetzung möglich

– Ebenen (Disksubsystem, etc.)

– Arten (in-band, out-of-band)

Name hinzufügen 19



V:Drive: Modularer Aufbau

SANSAN

Cluster Umgebung

Metadata-Server

Speicher

V:DriveV:Drive

V:Drive

Pool 1 Pool 2

Virtual (V:Drive) Volume

SHARE

Name hinzufügen 20



Orte der Speichervirtualisierung

Name hinzufügen 21



Heinz Nixdorf Institut

& Institut für Informatik

Universität Paderborn

Fürstenallee 11

33102 Paderborn

Tel.: 0 52 51/60 64 66

Fax: 0 52 51/62 64 82

E-Mail: [email protected]

http://www.upb.de/cs/ag-madh

Wir danken für Ihre Aufmerksamkeit!

Wir danken für Ihre Aufmerksamkeit!

Datenverwaltung in Rechnernetzen...Name hinzufügen 1 HEINZ NIXDORF INSTITUT Universität Paderborn...

Documents

Transcript of Datenverwaltung in Rechnernetzen...Name hinzufügen 1 HEINZ NIXDORF INSTITUT Universität Paderborn...