Dzisiaj chciałbym przedstawić pewien powszechny problem z Azure Load Balancerem. Przyjmijmy następujący scenariusz:

1. Klient posiada aplikację on-premises z load balancerem,
2. Ta aplikacja składa się z kilku modułów,
3. Każdy węzeł puli hostuje zestaw modułów,
4. Niektóre moduły korzystają z usług świadczonych przez inne moduły,
5. Moduły działają niezależnie,i używają Load Balancera jako proxy do pozostałych modułów wchodzących w skład aplikacji,
6. Używany jest nie tylko HTTP, ale też conajmniej jeden inny protokół oparty na TCP,
7. Klient chce przenieść infrastrukturę do Chmury Azure.

Przykład takiego scenariusza jest opisany w następującym artykule KB CyberArk: Artykuł KB CyberArk.
Microsoft opisuje ten przypadek w przewodniku po rozwiązywaniu problemów z Azure.
Możemy tam przeczytać, że:

Jeśli wirtualna sieć jest skonfigurowana z wewnętrznym load balancerem, i jeden z uczestniczących w niej węzłów backendowych próbuje uzyskać dostęp do wewnętrznego frontu load balancera, to mogą wystąpić problemy z komunikacją, gdy ruch jest mapowany z powrotem do źródłowej VM. Taki scenariusz nie jest obsługiwany.

I oczywiście, to prawda. Sprawdźmy przyczynę tego problemu.
Jak wspomniałem wcześniej, nasz klient chce przeprowadzić migrację „shift and lift” dla swojej infrastruktury CyberArk. Innymi słowy, chce użyć jak najwięcej wbudowanych usług w Chmurze. W takiej sytuacji Azure Load Balancer jest naturalnym wyborem.
Poniżej przytoczyłem przykład projektu architektonicznego CyberArk:

Żeby lepiej wyjaśnić przycznę problemu, najpierw przedstawię niektóre właściwości i ograniczenia Azure Load Balancera:

1. Azure Load Balancer działa tylko na warstwie 4 modelu OSI/ISO,
2. Azure Load Balancer działa przy użyciu standardowych metod zrównoważenia obciążenia pracy – czyli źródłowe i docelowe adresy IP oraz porty TCP,
3. Azure Internal Load Balancer używa wirtualnego adresu IP (VIP) z sieci klienta, co pozwala na zachowanie ruchu wewnątrz vNet,
4. Azure VM może być częścią tylko jednego wewnętrznego i jednego zewnętrznego Load Balancera,
5. Tylko podstawowy interfejs sieciowy (vNIC) danej Azure VM może być częścią backend pool Load Balancera. Tylko ten interfejs może mieć skonfigurowaną domyślną bramę,
6. Azure Load Balanver nie wykonuje translacji adresów IP wychodzących (SNAT). On po prostu nie ma przypisanego adresu IP wychodzącego, tylko przychodzący. Oznacza to, że Azure Load Balancer zmienia tylko adres docelowy z własnego VIP na podstawowy adres IP VMki podczas przetwarzania reguł NAT lub zrównoważania obciążenia. Z perspektywy maszyny wirtualnej w Azure, Azure Load Balancer jest całkowicie przeźroczysty i niewidoczny.

To ostatnie ograniczenie jest przyczyną naszego problemu. Microsoft stwierdza (powtórzmy to, to jest kluczowe!):

mogą wystąpić problemy z komunikacją, gdy ruch jest mapowany z powrotem do źródłowej VM

Dzieje się tak dlatego, że po opuszczeniu Azure Load Balancera pakiet IP będzie miał taki sam adres źródłowy i jak adres docelowy. Zgodnie z RFC 791, sekcja 3.2 taka sytuacja nie powinna się zdarzyć i platforma Azure odrzuca te pakiety IP jako spoofing.

Mając to na uwadze, możemy teraz spróbować znaleźć jakieś rozwiązanie. Z punktu widzenia architektury, musimy stworzyć takie warunki, gdzie adres źródłowy będzie różnił się od adresu docelowego po przejściu przez load balancer. Znaczy to tyle, że nasza maszyna wirtualna musi mieć dodatkowy adres IP.
Dodatkowe adresy IP na karcie sieciowej Azure vNic są obsługiwane w Azure, ale tylko podstawowy adres IP z danego interfejsu może być domyślnie używany jako źródło pakietu IP. Oznacza to, że nie możemy wykorzystać tej funkcji w naszym scenariuszu.
Inną możliwością jest dodanie kolejnej karty sieciowej (vNic) do VM. To również jest wspierane. Maszyna wirtualna w Azure może mieć jedną podstawową kartę sieciową i do ośmiu dodatkowych kart sieciowych. Dodatkowe karty sieciowe mogą być przypisane do dowolnej podsieci w ramach vNet podstawowej karty sieciowej. Więc maszyna wirtualna w Azure nie może należeć do więcej niż jednego vNet Azure. To nam wystarczy. Musimy utworzyć dodatkową podsieć i dołączyć do niej drugą kartę sieciową.
Dodatkowe karty sieciowe mają jeszcze jedno ograniczenie. Nie mogą mieć domyślnej trasy. W zasadzie nie mogą mieć żadnej trasy. Dodatkowe karty sieciowe mogą gromadzić ruch, ale trudno jest przez nie coś wysłać. Więc takie naiwne podejście nie będzie działać. Adres źródłowy nadal zostanie ustawiony na podstawowy adres IP karty sieciowej.

Sztuczka polega na zmianie VIP Internal Load Balancera.
To jedyny sposób na wymuszenie przesłania pakietu IP przez drugą kartę sieciową. Gdy VIP wewnętrznego Load Balancera jest z tej samej podsieci co dodatkowa karta sieciowa, możemy wykorzystać domyślne zachowanie IP – adresy IP z lokalnej sieci są osiągane poprzez lokalny segment ethernetu lub inne medium. Normalnie, to jest kwestia optymalizacji, ale w tym scenariuszu jest to nasza jedyna szansa.

Ostateczną architekturę przedstawiłem na poniższym obrazku:

Happy Load Balancing!

Na serwerze Windows 2016, tak samo jak w wersji poprzedniej, nie ma narzędzia konfiguracyjnego umożliwiającego ustawienie certyfikatów RDP.
Można dokonać konfiguracji certyfikatu przy użyciu WMI. Najłatwiej jest tego dokonać poprzez Powershella.
Poniżej skrypt konfigurujący:

Jest to metoda uniwersalna, działająca zarówno na systemie klienckim, jak i serwerowym.

Jest mało znanym faktem, że Event Log Viewer umożliwia filtrowanie nie tylko graficzne, ale także zaawansowane query uwzględniające dowolne dane zawarte we wpisach określonego typu.
Drugim mało znanym faktem jest, że Event Log Viewer umożliwia wyświetlenie i filtrowanie po tak zwanym „Correlation ID”. Oczywiście, aplikacja wpisująca rekordy do dziennika zdarzeń także musi wspierać Correlation ID, gdyż część aplikacji nie zapisuje tego pola.
Niezwykle przydatną sprawą jeśli chodzi o Correlation ID jest to, że możemy odfiltrować zdarzenia związane z jakąś jedną konkretną czynnością, która generuje szereg zdarzeń, zakończony, na przykład, błędem.
Oto przykładowe query:

Każdy wpis w logu systemu windows od 2008 w górę jest prezentowany w formacie XML. Query się odnosi do pól we wpisie. Niestety nie jest to wyrażenie XPATH, ale jest równie intuicyjne i proste do odczytania.
Przedstawiam przykładowy wpis z dziennika zdarzeń:

Najprostszą metodą do rozpoczęcia prac nad kwerendą jest wyjście od ustalenia elementarnych warunków Filtrowania poprzez wybranie opcji „Filter Current Log”.
Poniższy wycinek ekranu pokazuje przykładowe warunki filtru.

Następnie przechodzimy na zakładkę „XML” i zaznaczamy checkbox „Edit query manually”

Po zatwierdzeniu komunikatu o fakcie, iż nie będzie można tego query już więcej edytować graficznie, otrzymujemy edytor query.

Filozofia tworzenia query jest prosta. Każdy tag, na podstawie którego będzie wykonywane filtrowanie znajduje swoje odzwierciedlenie w postaci składni:

Oczywiście można zagnieżdżać w wyrażeniu kolejne tagi, jak również łączyć je operatorami. Każdy wpis w logu systemowym, który spełni wszystkie warunki zostanie pokazany w odfiltrowanym widoku.
Przedstawię jeszcze raz filtr, który pojawił się na początku. Zostanie on sformatowany w trochę inny sposób, należy jednak pamiętać, że query powinno być zapisane w jednej linii.

1. Linia query mówi, że wyszukiwania należy wykonywać w dowolnych node’ach najwyższego rzędu. Tak naprawdę chodzi o node
2. Linia nakazuje przeszukać Tag . W ten sam sposób można się odnieść do sekcji
3. Linia nakazuje przeszukać Tag , który znajduje się wewnątrz tagu
4. Linia definiuje warunek, w którym przyrównujemy wartość atrybutu o nazwie ActivityID do określonego ciągu znaków
5. Linia zamyka listę warunków sprawdzanych w obrębie tagu
6. Linia definiuje warunek sprawdzający zawartość tagu nie posiadającego żadnych subtagów, tylko wartość.
7. Linia i kolejne definiują warunek w obrębie tagu i odnoszą się do dwóch atrybutów tego tagu.

Dzisiaj chciałbym poświęcić trochę miejsca bardzo słabo udokumentowanej funkcjonalności Klastra.
Skrypty zasobów generycznych (Generic Script Resource) umożliwiają uruchomić w środowisku klastrowym nawet bardzo skomplikowane z punktu widzenia startu i potrzebnych zasobów usługi, które nie mają wbudowanych mechanizmów zapewniających wysoką dostępność.
W systemie Windows Failover Cluster umożliwia tworzenie skryptów zarządzających stanem zasobów JEDYNIE w języku Visual Basic (VBScript).
Ponieważ jest to technologia archaiczna, to powstały różne skrypty dostępne w sieci, służące do wywoływania innych narzędzi skryptowych. Ja posłużę się wersją uruchamiającą skrypty Powershell, gdyż jest to najlepszy obecnie dostępny język skryptowy dla systemu Windows.
Jednak, zanim dojdziemy do przedstawienia właściwych rozwiązań, chciałbym omówić filozofię tworzenia takich skryptów.
W środowisku klastrowym każdy zasób ma swojego właściciela (Owner Host). Jest host, na którym w danym momencie uruchamiany jest kod odpowiadający za obsługę zasobu. Celowo piszę „kod odpowiadający za obsługę”, gdyż może być to trojaki typ kodu:

1. Manager Usług
2. Biblioteka DLL zarządzająca zasobem (na przykład maszyny wirtualne)
3. Skrypt zasobu generycznego

Po prawdzie, to implementacja zarówno managera usług jak i zasobu skryptu generycznego jest wewnętrznie realizowana przez odpowiednią DLL, ale rozróżnienie to jest przydatne dla administratorów i wdrożeniowców mających zdecydować, w jaki sposób należy zapewnić wysoką dostępność.

Cykl życia zasobu można opisać pewnymi etapami, które są charakterystyczne dla każdego właściciela. Należą do nich:

1. Inicjalizacja managera zasobu (Open)
2. Uruchomienie zasobu (Online)
3. „Obejrzenie stanu zasobu” (LooksAlive)
4. Sprawdzenie stanu zasobu (IsAlive)
5. Wyłączenie zasobu (Offline)
6. Zniszczenie zasobu (Terminate)
7. Zamknięcie managera zasobu (Close)

Nazwy funkcji Callback implementowane w skrypcie zasobu Podane zostały w nawiasach.
Istotne jest wyjaśnienie różnicy między LooksAlive a IsAlive, gdyż na pierwszy rzut oka wydaje się to być dość nietypowe rozwiązanie. Callback LooksAlive jest wywoływany często, żeby zmniejszyć możliwie najbardziej czas reakcji na ewentualną awarię. Czas wykonania tego callback’a jest ograniczony do 300ms.
Dopiero, gdy ta funkcja zwróci błąd wywoływana jest funkcja IsAlive.
Ponadto raz na około minutę wywoływana jest funkcja IsAlive niezależnie od opisanego powyżej mechanizmu. Wynika to z pryncypium szybkiego wykonania LooksAlive, a w konsekwencji pobieżnego sprawdzenia, które może coś (celowo, lub nie) przeoczyć.
Dlatego manager klastra i tak sprawdza pełną diagnostykę zasobu raz na minutę. Jest to na tyle nieduży czas, że jeszcze akceptowalny dla większości usług, a z drugiej strony jest on na tyle duży, że nie wprowadza znacznego obciążenia do systemu „władającego” usługą.
Pozostałe funkcje callback ze skryptu nie wymagają dłuższego omówienia.

Bardzo ważną sprawą do omówienia, gdyż z tym się mogą wiązać błędu i w konsekwencji problemy z uruchomieniem, jest kwestia zmiennych zasobu. Każdy zasób może (i powinien) przechowywać swój stan konfiguracji w przestrzeni klastra – dzięki temu unikniemy sytuacji, w której usługa będzie zachowywać się niespójnie na różnych hostach-właścicielach zasobu.
Istotnym jest, aby definiować zmienne zasobu na samym zasobie skryptu, a nie na grupie zasobów, czy też na zasobie adresu ip albo jakimkolwiek innym zasobie w grupie. Tylko zmienne zasobu skryptu (czyli zdefiniowane dla instancji typu Generic Script Resource) będą dostępne przez Api Klastra.

API klastra reprezentowane jest przez obiekt VBScript o nazwie

Przykład użycia tego obiektu prezentuje poniższa funkcja:

W chmurze Microsoft Azure użytkownik może posiadać dowolną liczbę subskrypcji. Subskrypcja jest najmniejszą jednostką konfigurującą sposób płatności i zakres własności zasobów.
Każda subskrypcja generuje swój osobny Billing. Nie ma żadnego znaczenia w tym przypadku fakt, że jeden użytkownik, czy organizacja jest właścicielem subskrypcji. Jedna subskrypcja, jeden rachunek. Istnieje wyjątek w postaci umów typu Enterprise, gdzie ten model jest bardziej skomplikowany, ale ten temat zostawiamy na boku.
Istotne jest to, że będąc indywidualnym właścicielem kilku subskrypcji, można dostać na przykład 3 rachunki opiewające na 2 euro. To potrafi być irytujące.
Dlatego zaistniała potrzeba połączenia subskrypcji ze sobą.
Jedną metodą, jaka jest dostępna w Azure, na wykonanie takiej akcji jest migracja zasobów do jednej z subskrypcji i odwołanie pozostałych. W sieci można znaleźć dużo pytań na ten temat, jednak mało która odpowiedź jest konkretna. Okazuje się jednak, że rozwiązanie jest bardzo proste i wspierane. Opisane dokładnie w szczegółach jest w tym artykule.
Tutaj tylko przytoczę informację o tym, że możliwość migracji jest uzależniona od konkretnego typu zasobu i niektóre zasoby posiadają pewne ograniczenia w przenoszeniu.
Pełna lista zasobów wspierających przenoszenie dostępna jest tutaj.

W dniu 23. czerwca 2016 miało miejsce drugie spotkanie krakowskiej grupy Azure Users Group Poland.
W ramach tego wydarzenia przedstawiłem prezentację dotyczącą różnych sposobów optymalizacji kosztów utrzymania Azure WebApps.
Prezentację z tego wystąpienia można znaleźć tutaj