Azure Compute

Autor: Grzegorz Glonek

Opublikowano: 2011-05-04

Wprowadzenie

Moduł ten jest odpowiedzialny za wykonywanie aplikacji umieszczonych w chmurze. Jego głównym zadaniem jest obsługa programów wykorzystywanych równolegle przez wielu użytkowników. Aby uzyskać wymaganą do tego celu wydajność, naturalne wydaje się uruchamianie takiej aplikacji na coraz wydajniejszych maszynach (taki sposób skalowania aplikacji nosi nazwę scaling up). Niestety, jest to bardzo kosztowne podejście, ze względu na ceny najbardziej wydajnych podzespołów komputerowych. Doprowadza to też bardzo szybko do granic możliwości technicznych dzisiejszych komputerów i uniemożliwia dalszy rozwój aplikacji. Platforma Windows Azure wykorzystuje strategię skalowania, nazywaną scaling out, polegającą na równoczesnym uruchomieniu wielu instancji tego samego kodu na różnych maszynach. Dzięki temu możliwy jest szybki wzrost liczby użytkowników bez straty wydajności programu przy jednoczesnym minimalizowaniu kosztów związanych ze skalowaniem aplikacji. Dla osiągnięcia jak największej wydajności każda instancja aplikacji uruchamiana jest na oddzielnej dedykowanej maszynie wirtualnej udostępnianej przez moduł hypervisora oparty na systemie Microsoft Hyper-V.

Budowa

Rysunek 1 przedstawia ogólne założenia budowy modułu Azure Compute. Jak widzimy na tej ilustracji, Windows Azure Guest OS udostępnia programiście typy (role) instancji, jakich może używać przy budowie aplikacji uruchamianej w chmurze: Web Role, Worker Role oraz VM Role.

Rys.1.Architektura AzureCompute.

Web Role służy jako swoisty interfejs aplikacji, pozwalający na odbiór i obsługę zapytań przychodzących za pośrednictwem protokołu HTTP lub HTTPS. W praktyce są to aplikacje przygotowane w technologii ASP.NET, serwisy WCF oraz aplikacje przygotowane w innych technologiach sieciowych opartych na platformie .NET. Aby było to możliwe, każda instancja maszyny wirtualnej tego typu posiada zainstalowaną pełną wersję serwera IIS.

Tym, co wyróżnia chmurę Windows Azure na tle innych, jest to, że nie jest ona związana z jedną tylko technologią. Ponieważ systemem operacyjnym zainstalowanym na każdej z maszyn wirtualnych jest system oparty na Windows Server, do tworzenia aplikacji możemy wykorzystać technologie inne, niż .NET Framework. W szczególności będą to aplikacje tworzone w natywnym języku C++, PHP czy nawet oparte na kontenerze aplikacji internetowych Apache Tomcat.

Drugim typem instancji jest Worker Role. W przeciwieństwie do poprzedniej roli, ta instancja nie posiada zainstalowanego serwera IIS, co sprawia, że jest uruchamiana samodzielnie. Możemy co prawda zainstalować i uruchomić na niej rozmaite serwery aplikacyjne, jednak nie jest to jej przeznaczeniem. Instancje typu Worker Role stanowią swoisty odpowiednik dla aplikacji Windows Services, które działają w systemie, wykonując swoje zadania w tle.

Projektując aplikację na Platformie Azure, architekt systemowy lub programista ma pełną dowolność co do ilości poszczególnych typów instancji. W szczególności może tworzyć usługi oparte wyłącznie na Web Role lub tylko na Worker Role. Podobna elastyczność występuje także w przypadku późniejszego zarządzania aplikacją. W razie potrzeby istnieje możliwość niezależnego zmieniania ilości każdej z instancji zarówno manualnie, jak i bezpośrednio w kodzie aplikacji.

Wraz z premierą Windows Azure SDK 1.3 dodano także trzecią rolę o nazwie VM Role. Powodem jej wprowadzenia była chęć ułatwienia migracji istniejących programów działających pod kontrolą Windows Server 2008 do chmury Windows Azure. Dzięki temu udogodnieniu możliwe stało się uruchamianie w chmurze wirtualnych dysków (VHD) z systemem Windows Server 2008 R2 przygotowanych w środowisku lokalnym.

Inną nowością wprowadzoną wraz z SDK 1.3 jest także możliwość wykorzystania przez użytkownika zdalnego pulpitu do monitorowania działania instancji jego aplikacji i łatwiejszego rozwiązywania problemów.

Na rysunku 1 widoczne są jeszcze dwa elementy wchodzące w skład  łańcucha przetwarzania zapytań użytkownika. Pierwszym z nich jest loadbalancer – wyspecjalizowane urządzenie odpowiedzialne za równomierne rozłożenie obciążenia pomiędzy wszystkie uruchomione instancje. Z jednej strony pozwala to zachować optymalną wydajność całego systemu, z drugiej – utrzymać ciągłość pracy w przypadku awarii którejś z uruchomionych instancji. Z punktu widzenia programisty tworzącego aplikację na chmurę Azure istotny jest fakt, że load balancer nie gwarantuje, że wszystkie zapytania od jednego użytkownika zostaną skierowane na tę samą instancję. Wiąże się to z tym, że wszelkie usługi uruchamiane w chmurze Windows Azure muszą być bezstanowe, a dane krytyczne z punktu widzenia obsługi zapytań użytkownika muszą być albo przechowywane w jakimś kontenerze Azure Storage, albo w bazie danych umieszczonej w SQL Azure, albo zachowywane po stronie użytkownika i przekazywane każdorazowo pomiędzy klientem a chmurą.

Zarówno specyfikacja, jak i szczegółowy opis działania tego modułu nie zostały opublikowane przez firmę Microsoft, a więc ten komponent należy po prostu traktować jako czarną skrzynkę. Na podstawie szczątkowych informacji, jakie można znaleźć na forum MSDN, można wnioskować, że algorytmem odpowiedzialnym za przydział instancji do zadań jest algorytm karuzelowy (ang. round-robin) z wagami określanymi na podstawie aktualnego obciążenia maszyn.

Ostatnim elementem widocznym na rysunku 1 jest agent. Element ten umożliwia interakcję pomiędzy uruchomioną instancją a komponentem Azure Fabric. Dzięki temu kontrolery odpowiedzialne za nadzór i diagnostykę całej infrastruktury, która składa się na chmurę, mogą monitorować stan poszczególnych maszyn fizycznych oraz instancji maszyn wirtualnych i zarządzać nimi (np. uruchamiać nowe instancje w miejsce tych, których stan wskazuje, że niebawem mogą przestać poprawnie działać).

Podsumowanie

W tym artykule opisano najważniejsze możliwości, jakie oferuje nam komponent AzureCompute. Dowiedzieliśmy się, jakie role możemy wykorzystać do budowy aplikacji i co one oferują.

W kolejnym artykule znajdziesz opis magazynu danych Azure Storage.