Platforma Windows Azure - Azure Fabric

Autor: Grzegorz Glonek

Opublikowano: 2011-06-13

Pobierz i uruchom Windows Azure SDK 1.6

Wprowadzenie

Ostatnim elementem składającym się na Windows Azure jest moduł odpowiedzialny za kontrolę stanów fizycznych maszyn w centrum obliczeniowym – Azure Fabric. Moduł ten zarządza ogromną liczbą fizycznych maszyn znajdujących się w danym centrum obliczeniowym (przykładowo w centrum w Chicago znajduje się 360 000 komputerów). Za nadzór nad maszynami odpowiada oprogramowanie o nazwie fabric controler, które zreplikowane jest na kilku komputerach (od pięciu do siedmiu maszyn) w celu zapewnienia możliwie dużej niezawodności tego elementu. Jest to kluczowe zagadnienie, ponieważ kontroler ten zarządza wszystkimi maszynami fizycznymi, przełącznikami sieciowymi, a także load balacerem.

Działanie

Fabric controler, oprócz możliwości komunikacji z urządzeniami fizycznymi składającymi się na chmurę, może także komunikować się z maszynami wirtualnymi poprzez moduł agenta. Dzięki temu kontroler ma dostęp do instancji aplikacji, a także do przestrzeni Azure Storage, jednak są one reprezentowane dokładnie w taki sam sposób, więc w trakcie replikowania danych pomiędzy maszynami kontroler ,,nie wie'' jakie dane tak naprawdę kopiuje i jaką mają wartość. Przyczynia się to do wzrostu bezpieczeństwa i poufności danych.

Oprócz replikowania aplikacji i danych pomiędzy maszynami w chmurze, kontroler ma za zadanie monitorować stan chmury, a także nadzorować aktualizację systemów operacyjnych na maszynach wirtualnych. Na podstawie zebranych danych na temat komputerów w chmurze kontroler podejmuje decyzję, na jakiej maszynie uruchomić nową instancję aplikacji, tak aby zoptymalizować zużycie sprzętu i zminimalizować koszty działania całego centrum obliczeniowego. Polega przy tym na konfiguracji dołączonej do aplikacji, która określa m.in. jak wiele instancji określonego typu (Web lub Worker Role) potrzebuje aplikacja do poprawnego działania. Programista ma możliwość zdefiniowania także podstawowej konfiguracji sprzętowej maszyny wirtualnej, jaka ma być używana. I tak na Platformie Windows Azure dostępne jest pięć konfiguracji zebranychw tabeli 1.

Nazwa	Ilość wirtualnych procesorów	Moc rdzenia [GHz]	Ilość pamięci RAM [GB]	Rozmiar dysku w ramach instancji [GB]
Extra Small	1	1	0,75	20
Small	1	1,6	1,75	225
Medium	2	1,6	3,5	490
Large	4	1,6	7	1000
Extra large	8	1,6	14	2040

Tab.1. Konfiguracje sprzętowe maszyn wirtualnych na platformie Windows Azure.

Warto w tym miejscu nadmienić, że każdy wirtualny procesor użyty w instancji wirtualnej maszyny odpowiada jednemu rdzeniowi fizycznego procesora maszyny, na której dana instancja jest uruchomiona. Gwarantuje to wysoką wydajność uruchomionych aplikacji. Jak widać z tabeli 1, poza instancją Extra Small bazową konfiguracją jest instancja o nazwie Small, a kolejne są jej zwielokrotnieniem (zasada ta nie dotyczy przestrzeni dyskowej). Opłaty za korzystanie z takiej instancji również są wprost proporcjonalne do kwoty bazowej, która wynosi $0.12/h używania maszyny (w tym przypadku instancja Extra Small również odbiega od schematu, ponieważ jej koszt wynosi $0.05/h). W związku z tym można zadać pytanie, w jaki sposób postępować w przypadku zwiększenia ilości użytkowników korzystających z aplikacji? Zwiększyć wydajność pojedynczej instancji, czy zwiększyć liczbę mniej wydajnych maszyn? Zgodnie z przyjętą strategią skalowania (scalling out), większy wzrost wydajności otrzymamy, uruchamiając równolegle więcej instancji mogących równolegle przyjmować zadania i je przetwarzać.

Uruchamiając nowe instancje, kontroler nie może posługiwać się prostym podejściem uruchomienia ich na jednej maszynie. Łatwo można wyobrazić sobie sytuację, w której cała aplikacja i wszystkie jej dane zostają utracone, ponieważ maszyna, na której były uruchomione, uległa zniszczeniu. Aby temu zapobiec, kontroler dzieli całą dostępną infrastrukturę na tzw. obszary awarii (fault domains), czyli grupy urządzeń, które w wyniku pojedynczej awarii przestają być dostępne (przedstawione na rys. 1). Następnie, uruchamiając instancję aplikacji lub replikując dane umieszczone w ramach Azure Storage, wybiera komputery umieszczone w różnych obszarach. Dzięki temu ryzyko całkowitego unieruchomienia aplikacji zostaje zminimalizowane. Co więcej, w przypadku zatrzymania jakiejś instancji kontroler odpowiada za jej ponowne uruchomienie, tak aby liczba dostępnych instancji była zgodna z tą określoną w konfiguracji.

Rys.1. Podział na obszary awarii w Azure Fabric.

Ciekawa sytuacja następuje w trakcie procesu aktualizacji aplikacji. Jeżeli jest ona uruchomiona na wielu instancjach, kontroler grupuje je w obszary aktualizacji (update domains) (rys. 2), a następnie wyłącza i aktualizuje je w ramach takiego obszaru. Po zakończeniu procesu aktualizacji obszaru i ponownym uruchomieniu wszystkich instancji, które się w nim znajdują, kontroler powtarza cały proces na kolejnym obszarze. Taki sposób zapewnia ciągłość pracy całej aplikacji, a jedynym objawem trwania aktualizacji, widocznym dla użytkownika, jest chwilowy spadek wydajności aplikacji i możliwe wydłużenie czasu odpowiedzi na zgłoszone żądanie.

Rys.2. Podział na obszary aktualizacji w Azure Fabric.

Podsumowanie

W tym artykule znalazły się informacje na temat modułu Azure Fabric, będącego ostatnim elementem komponentu Windows Azure.

W następnym artykule zajmiemy się kolejnym składnikiem platformy Windows Azure – relacyjną bazą danych SQL Azure.

---

          

Grzegorz Glonek (MCP, MCTS)

Absolwent Wydziału Fizyki Technicznej, Informatyki i Matematyki Stosowanej Politechniki Łódzkiej. Uczestnik konkursu ImagineCup. Wraz z drużyną fteams zdobył w 2009 roku drugie miejsce na finałach światowych tego konkursu w kategorii Software Design : InteroperabilityAward oraz pierwsze miejsce w finałach krajowych kategorii Software Design w 2010 roku. Obecnie zatrudniony w polskim oddziale firmy Microsoft na stanowisku Software Development Engineer in Test.