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

401 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
401
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 1. ‘Architektura SWIFT obiektowego przechowywania danych’ Marek Landowski SII
  2. 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. 3. Dlaczego SWIFT?
  4. 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. 5. OpenStack
  6. 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. 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. 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. 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. 10. Horizon
  11. 11. REST API GET Container
  12. 12. REST API GET Object

×