Zaawansowane użycie Azure Storage Ewa Baćmaga Integral Technologies ewa.bacmaga@integral-tech.pl
Obiekty Azure Storage Blob Blob Tabela Table Kolejka Queue Napęd Drive Możliwość wykorzystania Windows Azure Storage do składowania plików wraz z towarzyszącymi im metadanymi. Zapewnia ogromnie skalowalny mechanizm składowania danych strukturalnych. Tabela Azure Storage jest zestawem encji, a każda encja jest zestawem właściwości. Zapewnia niezawodny sposób składowania i dostarczania komunikatów do aplikacji. Umożliwia wykorzystywanie w aplikacjach istniejących interfejsów API do sięgania do systemu plików dostępnego z trwałego napędu dołączonego sieciowo. Każdy taki napęd jest stronicowanym blob-em sformatowanym jako pojedynczy wolumin NTFS VHD.
Adresy dostępu do poszczególnych obiektów Azure Storage
Bloby Azure Storage Konto Storage Account Kontener Blob Container Dostęp do Azure Storage odbywa się za pośrednictwem konta składowania storage account Konto może zawierać wiele kontenerów na bloby Kontener zapewnia możliwość zgrupowania zestawu blobów. Nazwa kontenera funkcjonuje w zakresie konta składowania. Polityki wspóldzielenia prywatna lub publiczna. Z kontenerem mogą być związane jego metadane. Składowane są w postaci par <name, value>, maksymalnie 8KB na kontener. Blob Bloby są składowane i dostępne w obrębie kontenera. Z blobem mogą być związane jego metadane. Składowane są w postaci par <name, value>, maksymalnie 8KB na blob. Blob blokowy (block blob) Blob stronicowany (page blob) Sekwencja bloków Max 200GB Tablica stron Max 1TB
Tabele Azure Storage Konto Storage Account Tabela Table Dostęp do Azure Storage odbywa się za pośrednictwem konta składowania storage account. Konto może zawierać wiele tabel. Zawiera zestaw encji. Tabele dostępne są w obrębie konta. Encja zawiera zestaw właściwości. Encja Każda tabla ma dwie właściwości (Wiersz) PartitionKey oraz RowKey, które stanowią Entity unikalny klucz identyfikujący encję. Encja może zawierać do 255 właściwości. (Row) Połączony rozmiar wszystkich właściwości encji nie może przekraczać 1MB. Wlicza się w to nazwy właściwości, jak również rozmiar wartości właściwości oraz ich typy. Właściwość (Kolumna) Property (Cloumn) Pozwala składować pojedynczą wartość w encji.
Tabele Azure Storage PartitionKey Pierwsza kluczowa właściwość każdej tabeli. System automatycznie wykorzystuje PartitionKey do rozpraszania i równoważenia obciążenia przetwarzania encji tabeli w obrębie wielu serwerów. RowKey Druga kluczowa właściwość każdej tabeli. Jest to unikalny identyfikator encji w obrębie partycji, do której należy. Kombinacja PartitionKey i RowKey unikalnie identyfikuje encję w ramach tabeli. Timestamp Data ostatniej modyfikacji encji. Używana wewnętrznie przez Azure Storage dla celów optimistic concurrency. Próba jej modyfikacji przez użytkownika jest ignorowana. optimistic concurrency. Próba jej modyfikacji przez użytkownika jest ignorowana. Porządek sortowania Typy właściwości Tabele Windows Azure mają pojedynczy indeks, gdzie wszystkie encje tabeli są sortowane po PartitionKey, a następnie po RowKey. Oznacza to, że zapytania specyfikujące te właściwości są bardziej efektywne, a ich rezultaty są zwracane posortowane po PartitionKey, a następnie po RowKey. PartitionKey i RowKey są typu string Inne właściwości mogą być następujących typów: Binary, Bool, DateTime, Double, GUID, Int, Int64, String. Brak ustalonego schematu Dla tabel Azure Storage nie jest zadawany żaden schemat. Wszystkie właściwości składowane są w postaci par <name, typed value>. Dwie encje w tej samej tabeli mogą mieć różne właściwości.
Kolejki Azure Storage Konto Storage Account Kolejka Queue Komunikat Message Dostęp do Azure Storage odbywa się za pośrednictwem konta składowania storage account. Konto może zawierać wiele kolejek. Kolejka zawiera wiele komunikatów. Nie ma bezpośredniego limitu na liczbę komunikatów w kolejce. Komunikat składowany jest w kolejce co najwyżej przez tydzień. Z kolejką mogą być związane jej metadane. Składowane są w postaci par <name, value>, maksymalnie 8KB na kolejkę. Komunikaty są składowane w kolejkach. Rozmiar pojedynczego komunikatu nie może przekraczać 8KB. Rozwiązaniem na składowanie większej ilości danych może być zapisanie w komunikacie jedynie nazwy blob-a lub informacji identyfikującej encję w tabeli, gdzie dane takie zostaną zapisane.
Kolejki Azure Storage widoczność komunikatów Producent 1 Worker 1 M1 Front End (ASP.NET, ) M4 M2 M3 M1 M3 M1 Back End (Worker) Producent 2 Worker 2 M3 M1 1. W1 przetwarza komunikat M1 2. M1 niewidoczny na 30 sek 3. W2 przetwarza komunikat M3 4. M3 niewidoczny na 30 sek 5. W2 poprawnie zakończył przetwarzanie M3 6. W2 kasuje komunikat M3 z kolejki 7. Awaria W1 przetwarzanie M1 nie zakończyło się poprawnie 8. M1 stanie się z powrotem widoczny dla W2
Przykładowy scenariusz użycia kolejek - spójność między tabelami Usuwanie (fora/posty, kanały/komunikaty, etc.) FrontEnd usuń Forum11 usuń Forum05 usuń Forum01 Worker usuwania usuń Forum01 FrontEnd Wyjęcie z kolejki komunikatu usuńforum01 Usunięcie Forum01 z tabeli Fora Usuwanie postów Forum01 z tabeli Posty Usunięcie komunikatu usuńforum01 z kolejki Posty IdentyfikatorPosta Forum01Post01 Forum01Post01 Forum01Post01 Forum05Post01 Fora IdentyfikatorForum Forum01 Forum02 Forum05
Przykładowy scenariusz użycia kolejek - spójność między tabelami Usuwanie - wznowienie po niepowodzeniu FrontEnd usuń Forum11 usuń Forum05 usuń Forum01 Worker usuwania usuń Forum01 FrontEnd Wyjęcie z kolejki komunikatu usuńforum01 i rozpoczęcie kasowania Wyjątek po kasowaniu Forum01 i Forum01Post01 Komunikat usuńforum01 jest znów widoczny w kolejce Ponowne wyjęcie z kolejki komunikatu usuńforum01 Powtórzenie operacji Posty IdentyfikatorPosta Forum01Post01 Forum01Post01 Forum01Post01 Forum05Post01 Fora Worker usuń usuwania Forum01 IdentyfikatorForum Forum01 Forum02 Forum05
Partycje Każdy obiekt danych Azure Storage (blob, encja w tabeli, komunikat w kolejce) posiada klucz identyfikujący partycję. Używane są następujące klucze partycji: PartitionKey Jakie są tego konsekwencje? Blob NazwaKontenera + NazwaBloba Ponieważ nazwa bloba stanowi klucz partycji, dostęp do różnych blobów jest rozkładany i równoważony między serwerami. Encja NazwaTabeli + PartitionKey Każda encja w tabeli użytkuje PartitionKey zadawany na poziomie aplikacji wykorzystującej tabele Azure Storage. Oznacza to, że Azure równoważy obciążenie przetwarzania encji w obrębie tabeli między różnymi serwerami na podstawie wartości PartitionKey. Encje w obrębie tej samej partycji, czyli obsługiwane przez ten sam serwer partycji, mogą być przetwarzane transakcyjnie. Komunikat NazwaKolejki Ponieważ klucz partycji w przypadku komunikatów stanowi nazwa kolejki, wszystkie komunikaty w danej kolejce przetwarzane są przez ten sam, pojedynczy serwer partycji.
3-warstwowa architektura Azure Storage Warstwa Front-End (FE) Odbiera przychodzące żądania, dokonuje ich uwierzytelnienia i autoryzacji, a następnie przekierowuje do odpowiedniego serwera partycji. Warstwa partycji Zarządza partycjami wszystkich obiektów Azure Storage. Każdy obiekt (blob, encja w tabeli, komunikat w kolejce) należy do pojedynczej partycji, a każda partycja jest obsługiwana przez tylko jeden serwer partycji. Zarządza tym, która partycja jest obsługiwana przez który serwer partycji. Zapewnia automatyczne równoważenie obciążenia serwerów partycji obsługą partycji, tak aby zapewnić przepustowość wymaganą przez bloby, tabele, czy kolejki. Pojedynczy serwer partycji może obsługiwać wiele partycji. Warstwa DFS (Distributed File System) rozproszony i replikowany system plików Zapewnia składowanie danych na dyskach. Odpowiada za rozpraszanie i replikowanie danych między wieloma serwerami, aby zapewnić ich trwałe składowanie. Dane są składowane na warstwie DFS, a wszystkie serwery DFS (i wszystkie dane składowane na warstwie DFS) są dostępne z każdego serwera partycji.
Zaprojektowana skalowalność (scalability targets) dla konta Azure Storage Pojemność Do 100 TBs Transakcje Do 5000 encji/komunikatów/blobów na sekundę Przepustowość Do 3 GB na sekundę Zaprojektowana wydajność (performance targets) dla pojedynczej partycji Pojedyncza kolejka Pojedyncza partycja tabeli Pojedynczy blob Wszystkie komunikaty w kolejce dostępne są za pośrednictwem pojedynczej partycji. Kolejki są zaprojektowane tak, aby pojedyncza była w stanie przetworzyć do 500 komunikatów na sekundę Wszystkie encje w tabeli mające ten sam klucz partycji przetwarzane są w ramach tej samej, pojedynczej partycji, przy czym większość tabel ma wiele partycji. Zaprojektowana przepustowość dla pojedynczej partycji wynosi: do 500 encji na sekundę Kluczem partycji dla blobów jest wartość NazwaKontenera + NazwaBloba, stąd też pojedynczy blob przetwarzany jest w ramach pojedynczej partycji. A zatem przetwarzanie rozpraszane jest między serwerami na poziomie pojedynczych blobów. Zaprojektowana przepustowość dla pojedynczego bloba wynosi: Do 60 MB na sekundę
Tabele Azure Storage dobór klucza partycji PartitionKey Zagadnienia do rozważenia przy doborze klucza partycji PartitionKey: Możliwość wykorzystania transakcji na grupie encji Entity Group Transactions Skalowalność Wydajność zapytań
Tabele Azure Storage - Entity Group Transactions Entity Group Transaction zapewnia transakcję atomową na grupie encji w pojedynczej tabeli z tym samym identyfikatorem partycji PartitionKey czyli w obrębie tej samej partycji. Pojedynczy pakiet transakcyjny (batch transaction) nie może przekraczać 100 encji. Rozmiar żądania pakietu transakcyjnego nie może przekraczać 4MB. W pojedynczym pakiecie transakcyjnym encja nie może się powtarzać (tzn. encje muszą mieć inne wartości właściwości RowKey).
Tabele Azure Storage - Skalowalność Pojedyncza partycja może serwować do 500 encji na sekundę. Jeżeli wymagania aplikacji są wyższe, konieczne jest takie jej zaprojektowanie, aby żądania przetwarzania encji mogły być rozproszone między różnymi partycjami. Użytkowanie pojedynczej partycji (takie samo PartitionKey dla każdej encji tabeli) Zalety: Przetwarzanie transakcyjne (Entity Group Transactions) do 100 encji insert/update/delete w pojedynczym pakiecie transakcyjnym. Zapytania dotyczące zakresu wierszy (row range query) mogą być szybkie, zależnie od rozmiaru zakresu zawsze przetwarzane będą przez pojedynczy serwer partycji. Wady: Nie skaluje się dobrze w przypadku przekroczenia limitów serwera partycji (partycja jest zawsze obsługiwana przez pojedynczy serwer) Nie powinno być stosowane w scenariuszach, gdzie przewidywane jest duże obciążenie. Użytkowanie oddzielnej partycji dla każdej encji (nowe PartitionKey dla każdej encji) Zalety: Dobre skalowanie ze względu na rozłożenie obciążenia między wiele partycji Wady: Zapytania dotyczące zakresu wierszy (row range query) są kosztowne powodują pełen scan tabeli Nie może być użyte przetwarzanie transakcyjne (Entity Group Transactions)
Tabele Azure Storage Efektywność zapytań PartitionKey == SciFi and RowKey == Star Wars Najefektywniejsze zapytanie wyszukiwania pojedynczej encji PartitionKey == SciFi and Sphere RowKey Star Wars Skanowanie encji w pojedynczej partycji, wydajność zależy od liczby encji, po których przebiaga RowKey w podanym zakresie. Action PartitionKey Thriller Skanowanie encji w obrębie wielu partycji. Wydajność zależy od liczby encji w przetwarzanych partycjach. PartitionKey == Action PartitionKey == Thriller Aktualna implementacja predykatu OR LINQ nie jest optymalizowana pod kątem skanowania dwóch partycji, stąd takie zapytanie zrealizowane będzie przez pełen scan tabeli. W takim przypadku rekomendowane jest wykonanie równoległe dwóch zapytań i połączenie wyników po stronie klienta. Cars RowKey Star Wars Brak określenia PartitionKey skutkuje skanowaniem całej tabeli.
Przykładowy scenariusz aplikacja dla wypożyczalni filmów CASE STUDY Cel Opracowanie rozwiązania dla stworzenia aplikacji dla wypożyczalni filmów. Konieczne jest odnotowywanie wypożyczeń oraz utrzymywanie licznika wypożyczeń dla danego Klienta. Wymagania obejmują: Utrzymanie informacji o koncie Klienta ID_Konta (identyfikator konta Klienta) NazwaKlienta (nazwa Klienta) Adres (adres Klienta) LiczbaWypozyczen (liczba wypożyczeń) Utrzymanie informacji o wypożyczeniach filmu ID_Konta (identyfikator konta Klienta) ID_Filmu (identyfikator filmu dalej w przykładzie tytuł filmu) DataWypozyczenia (data wypożyczenia) DataZwrotu (data zwrotu)
Przykładowy scenariusz aplikacja dla wypożyczalni filmów CASE STUDY Rozwiązanie 1 Utrzymywanie dwóch tabel Azure Storage: Wypozyczenia oraz Konta Tabela Wypozyczenia przechowuje informacje dotyczące aktualnie wypożyczonych filmów. Tabela Konta przechowuje między innymi liczbę filmów wypożyczonych przez każdego Klienta wypożyczalni. Aplikacja musi mieć opracowane i zaimplementowane (w kodzie) mechanizmy obsługi sytuacji, w krórej wstawienie encji do tabeli Wypozyczenia udaje się, ale niepowodzeniem kończy się uaktualnienie tabeli Konta. Możliwe rozwiązanie z zastosowaniem Windows Azure Storage to zastosowanie kolejki do zapewnienia spójności.
Przykładowy scenariusz aplikacja dla wypożyczalni filmów CASE STUDY PartitionKey (ID_Wypozyczalni) RowKey (ID_Konta) Rozwiązanie 1 (cd) Obsługa spójności uaktualniania przy zastosowaniu kolejki 01 00123 Jan Nowak Konta NazwaKlienta Adres LiczbaWypozyczen Wykonaj: ++1 ID_Konta: 00123 12 kolejka do worker-a kont Wykonaj: ++1 ID_Konta: 00123 Worker uaktualniania kont Wykonaj: ++1 ID_Konta: 00123 FrontEnd zarządzania wypożyczeniami PartitionKey (ID_Konta) RowKey (ID_Filmu) DataWypozyczenia Wypozyczenia DataZwrotu 00123 Rejs 2011-06-10 2011-06-17 00123 Miś 2011-06-16 2011-06-23
Przykładowy scenariusz aplikacja dla wypożyczalni filmów CASE STUDY PartitionKey (ID_Wypozyczalni) RowKey (ID_Konta) Rozwiązanie 1 (cd) Obsługa spójności uaktualniania przy zastosowaniu kolejki, awaria workera 01 00123 Jan Nowak Konta NazwaKlienta Adres LiczbaWypozyczen Wykonaj: ++1 ID_Konta: 00123 12 kolejka do worker-a kont Wykonaj: ++1 ID_Konta: 00123 Worker uaktualniania kont Wykonaj: ++1 ID_Konta: 00123 FrontEnd zarządzania wypożyczeniami PartitionKey (ID_Konta) RowKey (ID_Filmu) DataWypozyczenia Wypozyczenia DataZwrotu 00123 Rejs 2011-06-10 2011-06-17 00123 Miś 2011-06-16 2011-06-23
Przykładowy scenariusz aplikacja dla wypożyczalni filmów CASE STUDY Rozwiązanie 2 Składowanie encji typu Wypożyczenie i Konto w jednej tabeli Azure ID_Konta jako PartitionKey Dzięki temu można aktualizować sumę i dodawać nowe wypożyczenia używając Entity Group Transaction RowKey poprzedzony kodem typu encji (K = Konto, W = Wypożyczenie) RowKey dla encji typu Konto RowKey dla encji typu Wypożyczenie [TypEncji]_[ID_Konta] [TypEncji]_[ID_Filmu]
Przykładowy scenariusz aplikacja dla wypożyczalni filmów PartitionKey (ID_Konta) CASE STUDY RowKey (TypEncji_*) Rozwiązanie 2 (cd) Składowanie encji typu Wypożyczenie i Konto w jednej tabeli Azure Storage TypEncji Nazwa Klienta Adres Liczba Wypozy czen ID_Filmu KontaWypozyczenia Data Wpozy czenia 00123 K_00123 K Jan Nowak Pereca Data Zwrotu 00123 W_Rejs W Rejs 2011-06-10 2011-06-17 00123 W_Miś W Miś 2011-06-16 2011-06-23 2 Azure Table może mieć różne kolekcje encji w jednej tabeli Właściwości encji typu Wypożyczenie nie są ustawiane dla encji typu Konto i odwrotnie
Przykładowy scenariusz aplikacja dla wypożyczalni filmów PartitionKey (ID_Konta) CASE STUDY RowKey (TypEncji_*) Rozwiązanie 2 (cd) Wstawianie i uaktualnianie encji typu Wypożyczenie i Konto w jednej tabeli Azure Storage TypEncji Nazwa Klienta Adres Liczba Wypozy czen ID_Filmu KontaWypozyczenia Data Wpozy czenia 00123 K_00123 K Jan Nowak Pereca Data Zwrotu 00123 W_Rejs W Rejs 2011-06-10 2011-06-17 00123 W_Miś W Miś 2011-06-16 2011-06-23 00123 W_Killer W Killer 2011-06-16 2011-06-25 23 Zarządca wypożyczeń Entity Group Transaction w obrębie tej samej partycji:» wstawienie nowej encji typu Wypożyczenie» uaktualnienie encji typu Konto
Przykładowy scenariusz system prowadzenia logów aplikacji CASE STUDY Cel Opracowanie systemu prowadzenia log ów aplikacji, w ramach którego możliwe byłoby dokonywanie rejestrowania błędów oraz użycia przez każdą instancję każdego komponentu rozproszonej aplikacji. Rozproszona aplikacja składa się z szeregu różnych komponentów: Ról web owych portalu Klientów Ról typu worker przetwarzania danych Ról web owych na potrzeby raportowania Pozostałe założenia: W danym wdrożeniu będzie działać wiele instancji każdej roli Każdy komponent (typ roli) ma przypisaną unikalną nazwę Każda instancja danego komponentu ma unikalny identyfikator instancji
Przykładowy scenariusz system prowadzenia logów aplikacji CASE STUDY Możliwe rozwiązania Zbudowanie wymaganego sysytemu prowadzenia log ów z wykorzystaniem tabeli Azure Storage Opcje doboru właściwego klucza partycji PartitionKey: PartitionKey = Component_Name Każdy komponent wykorzystywał będzię własną partycję. Problemy mogą pojawić się w przypadku, gdy pojedynczy komponent logował będzie wiele komunikatów przez wiele działających jego instancji. Taka gorąca partycja może osiągnąć limity przepustowości dla pojedynczej partycji. PartitionKey = Component_Name + Instance_Id Każda instancja komponentu wykorzystywać będzie własną partycję. Rozwiązanie dużo lepsze pod kątem skalowania. Problemy mogą pojawić się w przypadku, gdy dla danego komponentu każda jego instancja wykonuje intensywne logowanie komunikatów. PartitionKey = Component_Name + Instance_Id + Bucket_Id W przypadku zajścia powyższego problemu możliwe jest zastosowanie rozproszenia komunikatów logowanych przez każdą instancję komponentu do oddzielnych partycji przez dokonanie losowego ich rodziału na kubełki, których liczba może zostać wyznaczona przez oszacowanie maksymalnego wymaganego obciążenia.
Przykładowy scenariusz potwierdzanie 2-fazowe Koordynator potwierdzanie 2-fazowe Rejestracja Głosuj Mój głos Commit/Abort Uczestnik 1 Rejestracja Głosuj Mój głos Commit/Abort Rejestracja Głosuj Mój głos Commit/Abort Uczestnik 2 Uczestnik 3
Przykładowy scenariusz potwierdzanie 2-fazowe (commit) txid timeout 2011-06-16 15:35:10 liczba_ucz oddano_glosow czy_był_głos_abort rezultat 3 2013 nie commited commit głosuj kolejka uczestnika 1 UCZESTNIK 1 commit głosuj KOORDYNATOR commit głosuj kolejka uczestnika 2 UCZESTNIK 2 commit głosuj commit głosuj kolejka uczestnika 3 UCZESTNIK 3 commit głosuj kolejka koordynatora głosuję na TAK
Przykładowy scenariusz potwierdzanie 2-fazowe (abort) txid timeout liczba_ucz oddano_glosow czy_był_głos_abort rezultat 3 013 2 nie aborted 2011-06-16 15:35:10 tak głosuj abort kolejka uczestnika 1 UCZESTNIK 1 głosuj abort KOORDYNATOR głosuj abort kolejka uczestnika 2 UCZESTNIK 2 głosuj abort głosuj abort kolejka uczestnika 3 UCZESTNIK 3 głosuj abort kolejka koordynatora głosuję na TAK NIE
Przykładowy scenariusz potwierdzanie 2-fazowe (abort awaria uczestnika) txid timeout 2011-06-16 15:35:10 liczba_ucz oddano_glosow czy_był_głos_abort rezultat 3 01 2 nie aborted głosuj abort kolejka uczestnika 1 UCZESTNIK 1 głosuj abort KOORDYNATOR głosuj abort kolejka uczestnika 2 UCZESTNIK 2 głosuj abort głosuj abort kolejka uczestnika 3 głosuj UCZESTNIK 3 głosuj abort kolejka koordynatora głosuję na TAK
Dziękuję za uwagę ewa.bacmaga@integral-tech.pl