Your SlideShare is downloading. ×
infoShare 2014: Marek Landowski, Architektura SWIFT obiektowego przechowywania danych.
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

infoShare 2014: Marek Landowski, Architektura SWIFT obiektowego przechowywania danych.

139
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
139
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ‘Architektura SWIFT obiektowego przechowywania danych’ Marek Landowski SII
  • 2. Twierdzenie Brewera Stanowi, iż w rozproszonych systemach przetwarzania danych nie jest możliwe jednoczesne utrzymanie trzech właściwości: • spójności (consistency) oznaczającej że wszystkie węzły mają jednoczesny dostęp do jednakowych danych, • dostępności (availability) oznaczającej, że każde żądanie doczeka się odpowiedzi, • odporności na rozbicie (partition tolerance) oznaczającej, że system potrafi działać pomimo utraty części komunikatów lub uszkodzenia niektórych węzłów.
  • 3. Dlaczego SWIFT?
  • 4. Wybrane cechy SWIFTa • 5% rozwiązania wchodzącego w OpenStack, • Dostęp do danych jest za pomoca protokołu HTTP (REST API) • Obiekty sa zapisywane do kilku lokalizacji, gdzie software odpowiada za replikację. Gdy zdarzy się, że węzał przestanie działać, automatycznie tworzona jest kopia utraconych danych z wersji przechowywanych na innych węzłach, • SWIFT jest skalowalny horyzontalnie (na poziomie proxy serwerów oraz na poziomie węzłów przechowujących dane), • Nie wymaga dedykowanego sprzętu.
  • 5. OpenStack
  • 6. Działanie SWIFTa na przykładzie uploadu ZONE 3ZONE 2ZONE 1 Storage Server Storage Server Storage Server Storage Server Storage Server Storage Server Storage Server Storage Server Storage Server REST API Proxy Server Ring Upload object
  • 7. Proxy Server • Odpowiedzialny za komunikację z resztą architektury SWIFTa, • Zapis lub odczyt każdorazowo przechodzi przez proxy server, który komunikuje się z pierścieniem w celu odnalezienia fizycznej lokalizacji, • Gdy węzeł do którego powinien być wykonany zapis nie jest dostępny, proxy server odpyta pierścień w celu ustalenia nowej lokalizacji dla obiektu, • W rozwiązaniu możliwe jest zastosowanie wielu proxy serwerów, jednakże potrzeby jest wtedy dodatkowy element w architekturze, który będzie wybierał do którego proxy ma być skierowane zapytanie.
  • 8. Storage server • Węzły przechowują partycje przypisane do róznych lokalizacji, • Account oraz container to indywidualne bazy danych SQLite, które są rozproszone w SWIFTcie, • Baza danych account zawiera listę kontenerów, natomiast baza danych container zawiera listę obiektów, PARTITION Account database Container database Container database Object Object Object Object Object Container database
  • 9. Ring • Jest odpowiedzialny za mapowanie pomiędzy nazwami danych przechowywanych w SWIFTcie a ich fizyczna lokalizacją w klastrze, • Każda partycja jest domyślnie replikowana 3 krotnie, • Gregory Holt (http://greg.brim.net/page/building_a_consistent_hashing_ring.html) Partition Partition Partition Ring Storage Server
  • 10. Horizon
  • 11. REST API GET Container
  • 12. REST API GET Object