Pomiar opóźnień do różnych datacenter Azure

W jednym z pierwszych wpisów na blogu pisałem w jaki sposób pingować maszyny wirtualne, co w jakiś sposób pozwala nam określić opóźnienia w czasie dostępu do swojego wdrożenia. No ale w co sytuacji gdy dopiero przymierzamy się do wdrożenia rozwiązania i zastanawiamy się gdzie najlepiej na świecie umieścić naszą stronę, aplikację? Oczywiście wybór pomiędzy np. Europą a USA jest dość prosty, bo jeśli mamy użytkowników głównie w Polsce no to logicznie, nie będziemy wdrażali strony do data center w USA, ale co wybrać w Europie? North czy West Europe? Co będzie wydajniejsze? Skąd szybciej będą ściągały się pliki?

Jest na szczęście na to rozwiązanie 🙂 Jeden z pracowników Microsoft przygotował specjalną witrynę, która umożliwia testowanie takich rzeczy. Przywitajcie http://azurespeed.com.

Po wejściu na stronę zobaczymy od razu latency test związany z dostępem do Azure Storage:

azurespeedstoragelatency

Inne dostępne opcje to możliwość sprawdzenia Upload-u, także Uploadu dużych plików. Oczywiście w drugą stronę także download plików z różnych datacenter.

Moim zdaniem bardzo fajna strona pokazująca przydatne wartości, a przy okazji zwracająca uwagę na fakt, w ilu miejscach na świecie Azure jest dostępny i jaki wybór mamy 🙂

Wyłączanie ARR Affinity Session (sticky sessions) w Azure Web Sites

Microsoft Azure Web Sites ma zaimplementowany Application Request Routing co oznacza, że wspiera tak zwane sticky sessions. Co to oznacza? Oznacza to w dużym skrócie, że request, który przychodzi od kogoś, dostaje w nagłówku zwrotnym informację z jakiego serwera został obsłużony i przy jego każdym kolejnym requescie load balancer będzie kierował go do tego samego serwera.

Jest to bardzo fajne rozwiązanie kiedy np. chcemy w bardzo prosty i szybki sposób przenieść naszą istniejącą stronę do Azure, a strona ta nigdy nie była przystosowana do bezstanowości, a w szczególności do trzymania sesji użytkownika w jakimś zewnętrznym kontenerze (cache, baza danych etc.). Jednak gdy taką zmianę dodamy lub chcemy wykorzystać takie usługi jak Traffic Manager do rozdysponowania ruchu pomiędzy nasze wdrożenia warto jest wyłączyć sticky sessions i wykorzystać prawdziwą skalowalność chmury.

Na potrzeby wpisu mam wgraną na Azure prostą witrynę z szablonu ASP.NET w Visual Studio i zobaczmy jej ruch sieciowy w narzędziach developerskich IE (klawisz F12):

arrcokie

Widać, że zostało dodane ciasteczko z informacją o ARRAffinity.

Teraz żeby wyłączyć tę funkcjonalność należy do pliku web.config dodać następujący wpis:

  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Arr-Disable-Session-Affinity" value="true"/>
      </customHeaders>
    </httpProtocol>
  </system.webServer>

Teraz po odświeżeniu strony i podejrzeniu ruchu sieciowego zobaczymy, że nie ma już ciasteczka odpowiedzialnego za sticky sessions:

arrnocookie

Project Kudu – tylne wejście do Azure

Nawiązując do porównania, które na swoim blogu umieścił Scott Hanselman Azure Web Sites jest jednym z bardziej odizolowanych od samej platformy Azure środowiskiem. Ma to swoje plusy i minusy. Plusem na pewno jest łatwości wykorzystania, zapewnienie działania etc.. Minusem natomiast może być fakt niemożliwości skonfigurowania wielu rzeczy lub podejrzenia co się dzieje na różnych poziomach samej platformy. Nie wszystko jednak stracone bo mamy Kudu! 🙂

Project Kudu jak można przeczytać na jego oficjalnej stronie githuba jest silnikiem umożliwiającym deployment z poziomu git-a do Azure Web Sites. Jednak to zdanie było chyba napisane bardzo dawno temu bo obecnie Kudu potrafi dużo więcej!

Zacznijmy od zalogowania się do Kudu. Załóżmy, że adres naszej strony to http://mojamegasuperstrona.azurewebsites.net. Musimy go lekko zmodyfikować, aby wyglądał następująco https://mojamegasuperstrona.scm.azurewebsites.net. Po udanym logowaniu pojawi się nam się strona główna Kudu

projectkudumain

Na pierwszej stronie dostaniemy podstawowe informacje o naszym środowisku oraz linki do API REST-owego, dzięki czemu rzeczy, które dostarcza Kudu możemy także sami wywołać z poziomu kodu (sam Kudu tak naprawdę jest tylko nakładką UI na to API).

Druga zakładka Envoirement dostarcza bardziej szczegółowych informacji dotyczących naszego środowiska, w ramach , którego uruchomiona jest witryna. Podzielone są one na kategorię (jak na zdjęciu poniżej) i każda z tych kategorii zawiera szereg informacji. Część z nich jest dostępna z poziomu portalu zarządzania naszą witrynę, ale większość nie

projectkuduenv

Kolejna zakładka to Debug console, gdzie możemy sobie wybrać czy wolimy posługiwać się klasycznym wierszem poleceń czy PowerShellem 🙂 Dodatkowo znajduje się tam prosty explorer plików, z możliwością m.in. edycji, a także funkcją drag&drop więc jeśli szybko potrzebujemy przerzucić jakieś pliki na stronę można to zrobić w ten sposób

projectkududebugconsole

Idąc dalej znajdziemy zakładkę Process explorer, w której jak nie trudno się domyśleć, znajdują się informacje o działających procesach. Można podejrzeć właściwości wybranego procesu, pobrać memory czy GC dumpa, zobaczyć wątki,  moduły i dużo więcej. Przypominam, że to wszystko w przeglądarce! 🙂

projectkuduprocessex

Przedostatnia już zakładka to Tools. Znajdują się tam trzy narzędzia. Pierwsze z nich to Diagnostic dump, który powoduje tak de facto sciągnięcie katalogu Logs z naszej witryny, a tam będą znajdowały się różne logi, w zależności od tego co skonfigurowaliśmy w portalu dla naszej witryny. Log stream, powoduje wyświetlenie konsoli, która pokazuję w czasie rzeczywistym strumień logów, który możemy włączyć w panelu strony, a w kodzie aplikacji korzystać z metod klasy Trace, takich jak TraceError, TraceInformation, TraceWarning. Na samym końcu jest opcja Web hooks, która umożliwia podłączenie poprzez właśnie tę technologię różnych zewnętrznych serwisów. Przykładem może być tu Zapier, który potrafi się zintegrować z Azure Web Sites i ustawić jakąś akcję, która zostanie wykonana po deplymencie nowej wersji naszej wtiryny/aplikacji. Akcją to może być mail, sms, telefon i wiele, wiele innych 🙂

projectkudutools

Na sam koniec została zakładka Site extensions. Jak nazwa wskazuje są to rozszerzenia naszej witryny. O co chodzi. Chodzi o rozszerzenia, które nie są dostępne dla użytkowników, ale raczej dla administratorów. Jako przykład widać, że jest tutaj “Monaco“, czyli on-line’owa wersja Visual Studio, która umożliwia edycję plików witryny bezpośrednio w przeglądarce, czy np. phpMyAdmin, czyli są tu rzeczy, do których dostęp powinni mieć tylko administratorzy, ale działające w kontekście naszej witryny. Istnieje też galeria rozszerzeń, do której można wrzucać swoje rozszerzenia, można ją znaleźć pod adresem http://www.siteextensions.net/.

projectkudusiteexptensions

Ciekawą rzeczą jest też fakt, że Project Kudu można zainstalować u siebie na serwerze i korzystać z jego możliwości 🙂

Mam nadzieję, że dzięki temu narzędziu, oraz innym, które są przez nie dostarczane, łatwiejszy stanie się wgląd w bebechy
Azure Web Sites.

Zgłaszanie pomysłów i nowych funkcjonalności

Tym razem dość wakacyjny i lekki wpis, a mianowicie przypomnienie, albo uświadomienie niektórym, że można mieć całkiem duży wpływ na to jak wygląda Azure 🙂

Podstawowym miejscem gdzie można zgłaszać swoje potrzeby co do funkcjonalności w Azure lub szeroko pojętych pomysłów jest witryna http://feedback.azure.com

feedback

Na zgłoszenia odpowiadają ludzie z Microsoft którzy są bezpośrednio odpowiedzialni czy to marketingowo, czy też technicznie za dany fragment. Wiele z tych pomysłów już zostało wdrożony, część jest w planie, część jest rozpatrywana, a część jest odrzucona 🙂 (nie wszystko niestety da się zrealizować lub jest zgodne ze strategią Microsoft).

Strona jest hostowana za pomocą systemu UserVoice więc bardzo znanego system zgłaszania uwag, funkcjonalności. Warto pamiętać podczas zgłaszania czegoś, że po prawej stronie mamy listę kategorii i najlepiej jest od razu wpisać się do właściwej 🙂

azurefeedbackcategories

Jest to najlepsze miejsce, aby bezpośrednio zgłosić do grupy produktowej swój pomysł lub potrzebę wprowadzenia jakiejś funkcjonalności.

Pingowanie maszyn wirtualnych (oraz pingowanie z maszyn wirtualnych)

Dość często pojawia się potrzeba pingowania maszyny wirtualnej w Azure lub pingowanie na zewnątrz z maszyny wirtualnej. Jeśli spróbujemy wykonać prosty test:

PS C:\> ping pingdemotw.cloudapp.net

Pinging pingdemotw.cloudapp.net [191.238.97.93] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 191.238.97.93:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
PS C:\>

To zobaczymy, że nie da się takiej operacji przeprowadzić.

I tak samo stanie się kiedy spróbujemy wysłać pinga z wewnątrz maszyny wirtualnej:

PS C:\> ping www.microsoft.com

Pinging lb1.www.ms.akadns.net [134.170.184.133] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 134.170.184.133:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
PS C:\>

Sytuacja ta wynika z faktu, że na load balancerze, który jest w Azure blokowany jest ruch ICMP.

Najprostszym rozwiązaniem tej sytuacji jest skorzystanie z narzędzia PsPing, które jest częścią pakietu Sysinternals 🙂 Aplikacja ta pozwala wykonywać ping po protokole TCP a nie ICMP więc pozwoli nam wykonać takie testy.

Po jej sciągnięciu i zainstalowaniu można wykonać polecenie jak poniżej, podając dodatkowo otwarty port (za pomocą endpointa) dla naszej maszyny i dzięki temu otrzymamy wyniki:

PS C:\> psping pingdemotw.cloudapp.net:61025

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

TCP connect to 191.238.97.93:61025:
5 iterations (warmup 1) connecting test:
Connecting to 191.238.97.93:61025 (warmup): 57.06ms
Connecting to 191.238.97.93:61025: 54.98ms
Connecting to 191.238.97.93:61025: 55.69ms
Connecting to 191.238.97.93:61025: 54.53ms
Connecting to 191.238.97.93:61025: 56.86ms

TCP connect statistics for 191.238.97.93:61025:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 54.53ms, Maximum = 56.86ms, Average = 55.51ms
PS C:\>

No i oczywiście z poziomu samej maszyny wirtualnej też zadziała w drugą stronę:

PS C:\> psping www.microsoft.com:80

PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

TCP connect to 134.170.184.133:80:
5 iterations (warmup 1) connecting test:
Connecting to 134.170.184.133:80 (warmup): 140.72ms
Connecting to 134.170.184.133:80: 140.81ms
Connecting to 134.170.184.133:80: 140.67ms
Connecting to 134.170.184.133:80: 140.78ms
Connecting to 134.170.184.133:80: 140.81ms

TCP connect statistics for 134.170.184.133:80:
  Sent = 4, Received = 4, Lost = 0 (0% loss),
  Minimum = 140.67ms, Maximum = 140.81ms, Average = 140.77ms
PS C:\>