Platforma Windows Azure - Azure Storage cz. 1

Autor: Grzegorz Glonek

Opublikowano: 2011-05-16

Wprowadzenie

Ważnym elementem każdej platformy do tworzenia aplikacji (a więc i platformy Windows Azure) jest przestrzeń do składowania danych. Komponent Windows Azure oferuje usługę Azure Storage, pozwalającą przechowywać informacje w trzech różnych strukturach danych.

Rys.1.  Struktury danych w Azure Storage.

Jak widać na rysunku 1, są to: 

• Blobs (ang. binary large objects) – przechowują pliki binarne oraz tekstowe, często dużych rozmiarów. Dane umieszczone w ten sposób mogą zawierać dodatkowe metadane w postaci tagów reprezentujących np. opisy zdjęć.
• Tables – tabele wykorzystywane do przechowywania danych o określonej strukturze. Nie należy ich mylić z tabelami relacyjnymi, które udostępniane są za pośrednictwem SQL Azure.
• Queues – struktury będące kolejkami wykorzystywanymi do komunikacji asynchronicznej pomiędzy instancjami typu Web Role i Worker Role.

Dla wygody dostępu do danych, niezależnie od wykorzystywanej technologii, wszystkie dane udostępnione są zgodnie z wzorcem REST.

W celu zabezpieczenia przed przypadkową utratą informacji, Azure Storage zapewnia automatyczną replikację danych. Każda informacja umieszczona w chmurze przechowywana jest w trzech kopiach, dzięki czemu nawet częściowa utrata danych na skutek błędów lub awarii nie jest krytyczna i mimo to pozwala na dostęp do informacji. Istotne jest to, że chmura pomimo tej replikacji gwarantuje bardzo silną spójność danych. Dodatkowym zabezpieczeniem przed utratą informacji jest przechowywanie kopii danych w innym centrum przetwarzania, ale znajdującym się wciąż w tym samym regionie.

Blobs

Najpopularniejszymi i najczęściej wykorzystywanymi typami danych używanych w Azure są pliki typu BLOB (Binary Large OBjects). Mogą to być np. pliki audio, wideo, pliki tekstowe czy inne dane niezawierające ściśle zdefiniowanej struktury. Istnieją dwie formy tego typu plików, z których możemy skorzystać – blokowe (Block blobs) oraz stronicowe (Page blobs).

Pliki blokowe posiadają ograniczenie wielkości do 200 GB. W celu optymalizacji transmisji danych większych niż 64 MB dzieli się je na bloki nie większe niż 4 MB i w takiej formie przesyłane są pomiędzy klientem a chmurą. W przypadku wystąpienia błędu, przesyłany jest ponownie jedynie blok, który został zniszczony. Aby po przesłaniu całości plik był widoczny, musi być wykonana na nim operacja Commit.

Pliki stronicowe również posiadają ograniczenie rozmiaru, które w tym przypadku wynosi 1 TB, i dzielone są na strony rozmiaru 512 bajtów. W odróżnieniu od plików blokowych, aplikacja może odczytywać i zapisywać strony w dowolnej kolejności, co znacznie przyspiesza wykonywanie na nich operacji.

Pliki te składowane są według określonego schematu, przedstawionego na rysunku 2.

Rys.2. Schemat umieszczania danych Blob w Azure Storage.

Dane typu Blob muszą być umieszczane w kontenerach. Każdy kontener może zawierać wiele plików, ale niedozwolone jest zagnieżdżanie kontenerów, co wprowadza duże ograniczenie w możliwości segregacji danych. Istnieje jednak sposób stworzenia namiastki takiej hierarchii poprzez wykorzystanie w nazwie pliku znaku ,,/'', co jest oczywiście dozwolone. Dane będą wciąż umieszczone w jednym kontenerze, ale budując ścieżkę dostępu do takiego pliku będziemy mieli wrażenie, że jest on umieszczony w kolejnych kontenerach. Jak widać na rysunku 2, każdy plik posiada dodatkowe metadane. Z punktu widzenia programisty jest to więc kolekcja par łańcuchów znakowych klucz-wartość.

Kontenery posiadają dwa możliwe poziomy dostępu do zgromadzonych w nich danych – prywatny (private)  oraz publiczny (public). Gdy kontener jest określony jako prywatny, zarówno odczyt, jak i zapis umieszczonych w nim plików musi być potwierdzony kluczem wygenerowanym podczas zakładania przez użytkownika konta. Technicznie polega to na dołączeniu wartości klucza jako parametru żądania wysłanego przez aplikację do chmury. W przypadku kontenerów publicznych podania takiego klucza wymaga jedynie operacja zapisu. Prawo do odczytu danych posiada każda aplikacja korzystająca z dostępu do naszego konta.

Dla zwiększenia wydajności aplikacji klienckich, które łączą się z wielu miejsc na świecie (najczęściej są to aplikacje internetowe, np. stworzone w Silverlight), platforma Windows Azure posiada zaimplementowany mechanizm CDN (content delivery network lub content distribution network). Polega to na tworzeniu kopii danych na serwerach umieszczonych możliwie jak najbliżej klienta. Dzięki temu dane są szybciej dostępne dla użytkownika oraz zostaje zmniejszone obciążenie serwera centralnego.

Stworzona usługa ma pełen dostęp do danych znajdujących się na maszynie wirtualnej, na której jest uruchomiona. Dużym problemem w trakcie życia aplikacji może okazać się niezapamiętywanie zgromadzonych danych w chwili zamykania instancji maszyny. Mechanizmem, który pozwala na rozwiązanie tego problemu, jest wsparcie dla obiektów Azure Drive. Wśród autorów dostępnych źródeł nie ma zgodności co do tego, czy traktować Azure Drive jako czwartą strukturę danych, czy też jako szczególny przypadek struktury Blob. Jest to spowodowane tym, że są to de facto wirtualne dyski twarde formatu VHD, sformatowane z systemem plików NTFS i opierające się na typie stronicowym struktury Blob. W tej pracy zostało przyjęte, że jest to szczególny przykład struktury Blob. Oparcie tych dysków na typie stronicowym skutkuje m.in. tym, że wszelkie wprowadzone zmiany widoczne są natychmiast po ich zapisaniu.

Pojedyncza instancja usługi może montować takie wirtualne dyski z pełnymi prawami odczytu i zapisu danych. Jeśli jednak chcemy zrobić to samo na kilku instancjach, do dyspozycji mamy jedynie możliwość tworzenia migawek dysku (snapshots) posiadających wyłącznie prawa do odczytu danych. Montowanie pliku VHD na kilku instancjach jest jednocześnie sposobem współdzielenia dużych ilości informacji pomiędzy usługami. Każda maszyna wirtualna może korzystać maksymalnie z ośmiu takich dysków.

Wirtualne dyski możemy tworzyć zarówno z poziomu kodu aplikacji za pomocą udostępnionego API, jak również lokalnie, a następnie wysłać takie pliki w chmurę. Istotnym ograniczeniem, o którym trzeba pamiętać przygotowując pliki lokalnie, jest konieczność stworzenia wirtualnego dysku o z góry ustalonym rozmiarze pomiędzy 16MB a 1TB.

Podsumowanie

W tym artykule poznaliśmy ogólnie, jakie struktury danych oferuje nam Azure Storage oraz poznaliśmy szczegółowo możliwości struktury Blob.

W kolejnym artykule znajdą się opisy pozostałych dwóch struktur danych – Tables i Queues.