Jak tworzyć obciążenia na maszynach wirtualnych typu spot

W tym artykule opisano najlepsze rozwiązania dotyczące tworzenia maszyn wirtualnych typu spot na platformie Azure i zawieramy przykładowy scenariusz z możliwością wdrożenia. Maszyny wirtualne typu spot zapewniają dostęp do pojemności obliczeniowej ze znaczącymi rabatami dla zwykłych maszyn wirtualnych. Ta zniżka sprawia, że są one atrakcyjnym rozwiązaniem dla organizacji, które chcą zoptymalizować koszty, ale oszczędności są dostarczane z warunkiem. Maszyny wirtualne typu spot mogą utracić dostęp do obliczeń w dowolnym momencie. Nazywamy ten proces eksmisją. Obciążenia uruchomione na maszynach wirtualnych typu spot muszą być w stanie obsłużyć te przerwy w obliczeniach. Odpowiednie obciążenie i elastyczny mechanizm aranżacji są kluczami do sukcesu. Poniżej przedstawiono nasze zalecenia dotyczące tworzenia maszyn wirtualnych na miejscu.

Informacje o maszynach wirtualnych typu spot

Na poziomie technicznym maszyny wirtualne typu spot są takie same jak zwykłe maszyny wirtualne. Używają tych samych obrazów, sprzętu i dysków, które przekładają się na tę samą wydajność. Różnica między maszynami wirtualnymi typu spot i zwykłymi maszynami wirtualnymi sprowadza się do priorytetu i dostępności. Maszyny wirtualne typu spot nie mają priorytetu dostępu do pojemności obliczeniowej i nie mają gwarancji dostępności po dokonaniu dostępu do tej pojemności obliczeniowej. Bardziej szczegółowo omówimy priorytet i dostępność.

Brak dostępu priorytetowego. Zwykłe maszyny wirtualne mają priorytetowy dostęp do pojemności obliczeniowej. Uzyskują dostęp do pojemności obliczeniowej za każdym razem, gdy żądają. Z drugiej strony maszyny wirtualne typu spot są wdrażane tylko wtedy, gdy jest oszczędzona pojemność obliczeniowa i działają tylko wtedy, gdy zwykła maszyna wirtualna nie potrzebuje bazowego sprzętu.

Brak gwarancji dostępności. Maszyny wirtualne typu spot nie mają żadnych gwarancji dostępności. Nie mają umów dotyczących poziomu usług (SLA). Maszyny wirtualne typu spot mogą utracić dostęp do pojemności obliczeniowej natychmiast lub w dowolnym momencie po wdrożeniu (eksmisji). Maszyny wirtualne typu spot są tańsze z powodu możliwości eksmisji. Za każdym razem, gdy platforma Azure potrzebuje pojemności obliczeniowej, zostanie wysłane powiadomienie o eksmisji i eksmituje maszynę wirtualną typu spot. Platforma Azure udostępnia co najmniej 30-sekundowe powiadomienie z wyprzedzeniem przed rozpoczęciem rzeczywistego eksmisji. Aby uzyskać więcej informacji, zobacz ciągłe monitorowanie eksmisji w tym artykule.

Informacje o cenach maszyn wirtualnych typu spot

Maszyny wirtualne typu spot mogą być do 90 procent tańsze niż zwykłe maszyny wirtualne (płatność zgodnie z rzeczywistym użyciem). Rabat zależy od zapotrzebowania, rozmiaru maszyny wirtualnej, regionu wdrożenia i systemu operacyjnego. Zalecamy użycie narzędzia cenowego maszyny wirtualnej typu spot platformy Azure, aby uzyskać oszacowanie oszczędności kosztów. Aby uzyskać więcej informacji, zobacz:

• Narzędzie cennika maszyn wirtualnych typu spot platformy Azure
• Omówienie cennika maszyn wirtualnych typu spot

Możesz również wysłać zapytanie do interfejsu API cen detalicznych platformy Azure, aby programowo uzyskać ceny typu spot dla dowolnej jednostki SKU.

Omówienie przerywanych obciążeń

Obciążenia przerywane to najlepszy przypadek użycia maszyn wirtualnych typu spot. Obciążenia przerywane mają kilka typowych cech. Nie mają ograniczeń czasowych, niskiego priorytetu organizacyjnego i krótkiego czasu przetwarzania. Uruchamiają procesy, które mogą przestać nagle i wznawiać później bez szkody dla podstawowych procesów organizacyjnych. Przykłady przerywanych obciążeń to aplikacje przetwarzania wsadowego, analiza danych i obciążenia, które tworzą agenta ciągłego ciągłego wdrażania integracji dla środowiska nieprodukcyjnego. Te funkcje kontrastją z regularnymi lub krytycznymi obciążeniami, które mają umowy dotyczące poziomu usług (SLA), lepkie sesje i dane stanowe. Tabela zawiera przykłady dla obu typów obciążeń.

Maszyny wirtualne typu spot można używać w obciążeniach niezwiązanych z przerwami, ale nie powinny być pojedynczym źródłem pojemności obliczeniowej. Użyj jak największej liczby zwykłych maszyn wirtualnych, aby spełnić wymagania dotyczące czasu pracy.

Omówienie eksmisji

Maszyny wirtualne typu spot nie mają umów dotyczących poziomu usług (SLA) po ich utworzeniu i mogą utracić dostęp do obliczeń w dowolnym momencie. Nazywamy to utratą zasobów obliczeniowych eksmisją. Podaż obliczeniowa i zapotrzebowanie napędza eksmisję. Gdy zapotrzebowanie na określony rozmiar maszyny wirtualnej przekroczy określony poziom, platforma Azure eksmituje maszyny wirtualne typu spot, aby udostępnić obliczenia zwykłym maszynom wirtualnym. Zapotrzebowanie jest specyficzne dla lokalizacji. Wzrost zapotrzebowania w regionie A nie wpłynie na maszyny wirtualne typu spot w regionie B.

Maszyny wirtualne typu spot mają dwie opcje konfiguracji, które mają wpływ na eksmisji. Te konfiguracje to "typ eksmisji" i "zasady eksmisji" maszyny wirtualnej typu spot. Te konfiguracje są ustawiane podczas tworzenia maszyny wirtualnej typu spot. "Typ eksmisji" definiuje warunki eksmisji. Zasady eksmisji określają, co robi eksmisji na maszynie wirtualnej typu spot. Przyjrzyjmy się obu wyborom konfiguracji.

Typ eksmisji

Eksmisja jest spowodowana zmianami pojemności lub zmianami cen. Sposób, w jaki wpływają one na maszyny wirtualne typu spot, zależy od typu eksmisji wybranego podczas tworzenia maszyny wirtualnej. Typ eksmisji definiuje warunki eksmisji. Typy eksmisji to "eksmisja tylko pojemności" i "cena lub eksmisja pojemności".

Eksmisja tylko pojemności: ten typ eksmisji wyzwala eksmisję, gdy znika nadmiarowa pojemność obliczeniowa. Domyślnie cena jest ograniczona do stawki płatności zgodnie z rzeczywistym użyciem. Użyj tego typu eksmisji, gdy chcesz zapłacić do ceny maszyny wirtualnej z płatnością zgodnie z rzeczywistym użyciem.

Eksmisja cen lub pojemności: ten typ eksmisji ma dwa wyzwalacze. Platforma Azure eksmituje maszynę wirtualną typu spot, gdy nadmiar pojemności obliczeniowej zniknie lub koszt maszyny wirtualnej przekroczy ustawioną maksymalną cenę. Ten typ eksmisji umożliwia ustawienie maksymalnej ceny poniżej ceny płatności zgodnie z rzeczywistym użyciem. Użyj tego typu eksmisji, aby ustawić własny limit cen.

Zasady eksmisji

Zasady eksmisji wybrane dla maszyny wirtualnej typu spot wpływają na jego aranżację. Orkiestracja oznacza proces obsługi eksmisji. Szczegółowo omówimy aranżację później. Zasady eksmisji to zasady "Zatrzymaj/Cofnij przydział" i "Usuń zasady".

Zasady zatrzymywania/cofania przydziału: zasady eksmisji Stop/Deallocate są najlepsze, gdy obciążenie może czekać na pojemność wydania w ramach tej samej lokalizacji i typu maszyny wirtualnej. Zasady Zatrzymywanie/cofanie przydziału zatrzymuje maszynę wirtualną i kończy dzierżawę z bazowym sprzętem. Zatrzymywanie i cofanie przydziału maszyny wirtualnej typu spot jest takie samo jak zatrzymywanie i cofanie przydziału zwykłej maszyny wirtualnej. Maszyna wirtualna pozostaje dostępna na platformie Azure i możesz uruchomić ponownie tę samą maszynę wirtualną później. Dzięki zasadom Zatrzymywanie/cofanie przydziału maszyna wirtualna traci pojemność obliczeniową i niestatyczne adresy IP. Jednak dyski danych maszyny wirtualnej pozostają i nadal są naliczane opłaty. Maszyna wirtualna zajmuje również rdzenie w subskrypcji. Maszyny wirtualne nie mogą być przenoszone z ich regionu lub strefy nawet po zatrzymaniu/cofnięciu przydziału. Aby uzyskać więcej informacji, zobacz Stany zasilania maszyny wirtualnej i rozliczenia.

Usuń zasady: użyj zasad "Usuń", jeśli obciążenie może zmienić lokalizację lub rozmiar maszyny wirtualnej. Zmiana lokalizacji i/lub rozmiaru maszyny wirtualnej umożliwia szybsze wdrażanie maszyny wirtualnej. Zasady Usuwania usuwają maszynę wirtualną i dowolny dysk danych. Maszyna wirtualna nie zajmuje rdzeni w subskrypcjach. Aby uzyskać więcej informacji na temat zasad eksmisji, zobacz zasady eksmisji.

Projektowanie pod kątem elastycznej aranżacji

Orkiestracja to proces zastępowania maszyny wirtualnej typu spot po eksmisji. Jest to podstawa tworzenia niezawodnego przerywanego obciążenia. Dobry system aranżacji ma wbudowaną elastyczność. Dzięki elastyczności oznaczamy projektowanie aranżacji, aby mieć opcje, używać wielu rozmiarów maszyn wirtualnych, wdrażać w różnych regionach, uwzględniać eksmisji i uwzględniać różne scenariusze eksmisji, aby zwiększyć niezawodność i szybkość obciążenia.

Poniżej przedstawiono zalecenia ułatwiające projektowanie elastycznej aranżacji dla obciążenia, które można przerwać.

Projektowanie pod kątem szybkości

W przypadku obciążenia uruchomionego na maszynach wirtualnych typu spot pojemność obliczeniowa jest skarbem. Nieuchronny potencjał eksmisji powinien podnieść uznanie czasu obliczeniowego przydzielonego i powinien przekładać się na znaczące decyzje projektowe, które priorytetują szybkość obciążenia. Ogólnie rzecz biorąc, zalecamy optymalizację czasu obliczeniowego. Należy utworzyć obraz maszyny wirtualnej ze wszystkimi wymaganymi wstępnie zainstalowanymi oprogramowaniem. Wstępnie zainstalowane oprogramowanie pomoże zminimalizować czas między eksmisji a w pełni uruchomioną aplikacją. Chcesz unikać używania czasu obliczeniowego w procesach, które nie przyczyniają się do przeznaczenia obciążenia. Obciążenie na potrzeby analizy danych powinno na przykład skupić się na większości czasu obliczeniowego na przetwarzaniu danych i jak najmniejszej godzinie zbierania metadanych eksmisji. Wyeliminuj nieistotnych procesów z aplikacji.

Używanie wielu rozmiarów i lokalizacji maszyn wirtualnych

Zalecamy utworzenie orkiestracji w celu korzystania z wielu typów i rozmiarów maszyn wirtualnych w celu zwiększenia elastyczności. Celem jest przekazanie opcji aranżacji w celu zastąpienia eksmitowanej maszyny wirtualnej. Platforma Azure ma różne typy i rozmiary maszyn wirtualnych, które zapewniają podobne możliwości dla mniej więcej tej samej ceny. Należy filtrować maszyny wirtualne, minimalną liczbę procesorów wirtualnych/rdzeni i/lub minimalną pamięć RAM oraz maksymalną cenę, aby znaleźć wiele maszyn wirtualnych, które mają możliwość uruchamiania obciążenia i mieścić się w budżecie. Każdy typ maszyny wirtualnej ma wskaźnik eksmisji wyrażony jako zakres procentowy (0–5%, 5–10%, 10–15%, 15–20%, 20+%). Stawki eksmisji mogą się różnić w różnych regionach. Możesz znaleźć lepszy współczynnik eksmisji dla tego samego typu maszyny wirtualnej w innym regionie. Wskaźniki eksmisji dla każdego typu maszyny wirtualnej można znaleźć w portalu na karcie "Podstawy". Wybierz łącza "Rozmiar" ("Wyświetl historię cen" lub "Zobacz wszystkie rozmiary"). Możesz również programowo pobrać dane maszyny wirtualnej typu spot przy użyciu usługi Azure Resource Graph. Aby uzyskać więcej informacji, zobacz:

• Stawki eksmisji
• Azure Resource Graph

Korzystanie z najbardziej elastycznych zasad eksmisji

Zasady eksmisji eksmitowanej maszyny wirtualnej typu spot wpływają na proces wymiany. Zasady eksmisji usuwania są bardziej elastyczne niż zatrzymane/cofnięto zasady eksmisji.

Najpierw rozważ usunięcie zasad: zalecamy użycie zasad eksmisji usuwania, jeśli obciążenie może je obsłużyć. Usunięcie umożliwia orkiestrację wdrażania zastępczych maszyn wirtualnych typu spot w nowych strefach i regionach. Ta elastyczność wdrażania może pomóc w szybszym znalezieniu zapasowej pojemności obliczeniowej niż zatrzymana/cofnięto przydział maszyny wirtualnej. Zatrzymane/cofnięto przydział maszyn wirtualnych muszą czekać na oszczędzonej pojemności obliczeniowej w tej samej strefie, w której została utworzona. W przypadku zasad usuwania potrzebny jest proces monitorowania eksmisji spoza aplikacji i organizowania wdrożeń w różnych regionach i/lub z różnymi jednostkami SKU maszyn wirtualnych.

Informacje o zatrzymanych/cofniętych przydziałach zasad: zasady zatrzymane/cofnięto przydział mają mniejszą elastyczność niż zasady usuwania. Maszyny wirtualne typu spot muszą pozostać w tym samym regionie i strefie. Nie można przenieść zatrzymanej/cofniętej maszyny wirtualnej do innej lokalizacji. Ponieważ maszyny wirtualne mają stałą lokalizację, musisz coś zrobić, aby ponownie przydzielić maszynę wirtualną, gdy pojemność obliczeniowa stanie się dostępna. Nie ma możliwości przewidywania, kiedy będzie dostępna pojemność obliczeniowa. Dlatego zalecamy użycie zautomatyzowanego potoku harmonogramu w celu podjęcia próby ponownego wdrożenia po eksmisji. Eksmisja powinna wyzwolić potok harmonogramu, a próby ponownego wdrożenia powinny stale sprawdzać wydajność obliczeniową, dopóki nie stanie się ona dostępna.

Ciągłe monitorowanie eksmisji

Monitorowanie jest kluczem do niezawodności obciążeń na maszynach wirtualnych typu spot. Maszyny wirtualne typu spot nie mają umowy SLA po utworzeniu i można je wykluczyć w dowolnym momencie. Najlepszym sposobem na zwiększenie niezawodności obciążeń na maszynach wirtualnych na miejscu jest przewidywanie, kiedy zostaną one wykluczone. Dzięki tym informacjom można spróbować bezpiecznie zamknąć obciążenie i wyzwolić automatyzację, która organizuje zastąpienie.

Użyj zaplanowanych zdarzeń: zalecamy użycie usługi Zaplanowane zdarzenia dla każdej maszyny wirtualnej. Platforma Azure wysyła sygnały do maszyn wirtualnych, gdy będą one miały wpływ na konserwację infrastruktury. Eksmisje kwalifikują się do konserwacji infrastruktury. Platforma Azure wysyła Preempt sygnał do wszystkich maszyn wirtualnych co najmniej 30 sekund, zanim zostaną eksmitowane. Usługa o nazwie Schedule Events (Zdarzenia harmonogramu) umożliwia przechwytywanie tego Preempt sygnału przez wykonywanie zapytań dotyczących punktu końcowego pod statycznym, niepodstawiającym routingiem adresu 169.254.169.254IP.

Użyj częstych zapytań: zalecamy wykonywanie zapytań dotyczących punktu końcowego Harmonogramu zdarzeń często na tyle, aby zorganizować bezproblemowe zamykanie. Możesz wykonać zapytanie do punktu końcowego Zaplanowane zdarzenia maksymalnie co sekundę, ale jedna sekunda może nie być konieczna dla wszystkich przypadków użycia. Te zapytania muszą pochodzić z aplikacji uruchomionej na maszynie wirtualnej typu spot. Kwerenda nie może pochodzić ze źródła zewnętrznego. W związku z tym zapytania zużywają pojemność obliczeniową maszyny wirtualnej i kradną moc obliczeniową z głównego obciążenia. Musisz zrównoważyć te konkurencyjne priorytety, aby spełnić twoją określoną sytuację.

Automatyzowanie orkiestracji: po zebraniu sygnału Preempt orkiestracja powinna działać na tym sygnałie. Biorąc pod uwagę ograniczenia czasowe, Preempt sygnał powinien podjąć próbę bezpiecznego zamknięcia obciążenia i uruchomić zautomatyzowany proces, który zastępuje maszynę wirtualną typu spot. Aby uzyskać więcej informacji, zobacz:

• Zaplanowane zdarzenia
• Zaplanowane typy zdarzeń
• Częstotliwość wykonywania zapytań dotyczących punktu końcowego

Tworzenie systemu wdrażania

Orkiestracja wymaga zautomatyzowanego potoku w celu wdrożenia nowych maszyn wirtualnych typu spot po eksmitacji. Potok powinien działać poza samym obciążeniem przerywanym, aby zapewnić trwałość. Sposób działania potoku wdrażania zależy od zasad eksmisji wybranych dla maszyn wirtualnych typu spot.

W przypadku zasad usuwania zalecamy utworzenie potoku korzystającego z różnych rozmiarów maszyn wirtualnych i wdrożeń w różnych regionach. W przypadku zasad zatrzymania/cofnięcia przydziału potok wdrażania będzie potrzebować dwóch odrębnych akcji. W przypadku początkowego utworzenia maszyny wirtualnej potok musi wdrożyć odpowiednie maszyny wirtualne o odpowiednim rozmiarze w odpowiedniej lokalizacji. W przypadku eksmitowanej maszyny wirtualnej potok musi spróbować ponownie uruchomić maszynę wirtualną, dopóki nie będzie działać. Połączenie alertów usługi Azure Monitor i usługi Azure Functions to jeden z kilku sposobów automatyzowania systemu wdrażania. Potok może używać szablonów bicep. Są deklaratywne i idempotentne i reprezentują najlepsze rozwiązanie w zakresie wdrażania infrastruktury.

Przygotowanie do natychmiastowego eksmisji

Istnieje możliwość, że maszyna wirtualna typu spot zostanie wyznaczona do eksmisji, gdy tylko zostanie utworzona, a nawet przed wykonaniem obciążenia. Tylko dlatego, że istniała pojemność tworzenia maszyny wirtualnej typu spot, nie oznacza, że będzie ona trwała. Maszyny wirtualne typu spot nie mają gwarancji dostępności (SLA) po utworzeniu. Aranżacja musi uwzględniać natychmiastowe eksmisje. Sygnał Preempt będzie nadal dostarczać co najmniej 30-sekundowe powiadomienie o eksmisji.

Zalecamy włączenie kontroli kondycji maszyny wirtualnej do aranżacji, aby przygotować się do natychmiastowej eksmisji. Orkiestracja natychmiastowych eksmisji nie może polegać na sygnałie Schedule Events Preempt . Tylko sama maszyna wirtualna może wysyłać zapytania do sygnału Preempt i nie ma wystarczająco dużo czasu, aby uruchomić aplikację, wysłać zapytanie do punktu końcowego Schedule Events i bezpiecznie zamknąć. Dlatego sprawdzanie kondycji musi znajdować się poza środowiskiem obciążenia. Testy kondycji muszą obserwować stan maszyny wirtualnej typu spot i uruchomić potok wdrażania, aby zastąpić maszynę wirtualną typu spot, gdy stan zmieni się na cofnięcie przydziału lub zatrzymanie.

Planowanie wielu równoczesnych eksmisji

Jeśli używasz klastra maszyn wirtualnych typu spot, należy zaprojektować obciążenie tak, aby wytrzymało wiele równoczesnych eksmisji. W tym samym czasie można wykluczyć wiele maszyn wirtualnych typu spot w obciążeniu. Jednoczesne eksmisja wielu maszyn wirtualnych może mieć wpływ na przepływność aplikacji. Aby uniknąć takiej sytuacji, potok wdrażania powinien mieć możliwość zbierania sygnałów z wielu maszyn wirtualnych i wdrażania wielu zastępczych maszyn wirtualnych jednocześnie.

Projektowanie pod kątem bezproblemowego zamknięcia

Procesy zamykania maszyny wirtualnej powinny być krótsze niż 30 sekund i umożliwić maszynie wirtualnej zamknięcie przed eksmisją. Czas zamknięcia zależy od tego, jak często obciążenie wysyła zapytanie do punktu końcowego Zaplanowane zdarzenia. Tym częściej wysyłasz zapytanie do punktu końcowego, tym dłużej może być proces zamykania. Proces zamykania powinien zwalniać zasoby, opróżniać połączenia i opróżniać dzienniki zdarzeń. Należy regularnie tworzyć i zapisywać punkty kontrolne, aby zapisać kontekst i utworzyć bardziej wydajną strategię odzyskiwania. Punkt kontrolny to tylko informacje na temat procesów lub transakcji, od których musi rozpocząć się następna maszyna wirtualna. Powinny one wskazywać, czy maszyna wirtualna powinna wznowić działanie, w którym została przerwana poprzednia maszyna wirtualna, czy nowa maszyna wirtualna powinna wycofać zmiany i ponownie uruchomić cały proces. Punkty kontrolne należy przechowywać poza środowiskiem maszyny wirtualnej typu spot. Konto magazynu działałoby.

Testowanie aranżacji

Zalecamy symulowanie zdarzeń eksmisji w celu przetestowania orkiestracji w środowiskach deweloperskich/testowych. Aby uzyskać więcej informacji, zobacz symulowanie eksmisji.

Projektowanie obciążenia idempotentnego

Zalecamy projektowanie obciążenia idempotentnego. Wynik przetwarzania zdarzenia więcej niż raz powinien być taki sam jak przetwarzanie go raz. Eksmisje mogą prowadzić do wymuszonego zamknięcia pomimo wysiłków w celu zapewnienia bezproblemowych zamykania. Wymuszone zamknięcia mogą zakończyć procesy przed zakończeniem. Obciążenia idempotentne mogą odbierać ten sam komunikat więcej niż raz, a wynik pozostaje taki sam. Aby uzyskać więcej informacji, zobacz idempotencyjność.

Używanie okresu rozgrzewania aplikacji

Większość przerywanych obciążeń uruchamia aplikacje. Aplikacje wymagają czasu na zainstalowanie i czas rozruchu. Potrzebują czasu na nawiązanie połączenia z magazynem zewnętrznym i zebranie informacji z punktów kontrolnych. Zalecamy posiadanie okresu rozgrzewania aplikacji przed rozpoczęciem przetwarzania. W okresie rozgrzewki aplikacja powinna uruchamiać, łączyć się i przygotowywać do współtworzenia. Należy zezwolić aplikacji tylko na rozpoczęcie przetwarzania danych po zweryfikowaniu kondycji aplikacji.

Konfigurowanie tożsamości zarządzanych przypisanych przez użytkownika

Zalecamy użycie tożsamości zarządzanych przypisanych przez użytkownika w celu usprawnienia procesu uwierzytelniania i autoryzacji. Tożsamości zarządzane przypisane przez użytkownika pozwalają uniknąć umieszczania poświadczeń w kodzie i nie są powiązane z jednym zasobem, na przykład tożsamościami zarządzanymi przypisanymi przez system. Tożsamości zarządzane przypisane przez użytkownika zawierają uprawnienia i tokeny dostępu z identyfikatora Entra firmy Microsoft, które mogą być ponownie używane i przypisywane do maszyn wirtualnych typu spot podczas orkiestracji. Spójność tokenów między maszynami wirtualnymi typu spot pomaga usprawnić aranżację i dostęp do zasobów obciążeń, które mają maszyny wirtualne typu spot.

W przypadku tożsamości zarządzanych przypisanych przez system nowa maszyna wirtualna typu spot może uzyskać inny token dostępu od identyfikatora Entra firmy Microsoft. Jeśli musisz używać tożsamości zarządzanych przypisanych przez system, zalecamy, aby obciążenia były odporne na 403 Forbidden Error odpowiedzi. Orkiestracja będzie musiała uzyskać tokeny z identyfikatora Entra firmy Microsoft z odpowiednimi uprawnieniami. Aby uzyskać więcej informacji, zobacz Tożsamości zarządzane.

Przykładowy scenariusz

Przykładowy scenariusz wdraża aplikację przetwarzania kolejek, która kwalifikuje się jako przerywane obciążenie. Skrypty w scenariuszu są ilustracyjne. Scenariusz przeprowadzi Cię przez jednorazowe, ręczne wypychanie w celu wdrożenia zasobów. Nie udostępniliśmy potoku wdrażania z tą implementacją. Jednak potok wdrażania jest niezbędny do automatyzacji procesu aranżacji. Diagram ilustruje architekturę przykładowego scenariusza.

Poniższe uwagi wyjaśniają kluczowe aspekty architektury:

1. Definicja aplikacji maszyny wirtualnej: definicja aplikacji maszyny wirtualnej jest tworzona w galerii obliczeń platformy Azure. Definiuje ona nazwę aplikacji, lokalizację, system operacyjny i metadane. Wersja aplikacji jest wersją numerowaną definicji aplikacji maszyny wirtualnej. Wersja aplikacji jest wystąpieniem aplikacji maszyny wirtualnej. Musi znajdować się w tym samym regionie co maszyna wirtualna typu spot. Wersja aplikacji łączy się z pakietem aplikacji źródłowej na koncie magazynu.
2. Konto magazynu: konto magazynu przechowuje pakiet aplikacji źródłowej. W tej architekturze jest to skompresowany plik tar o nazwie worker-0.1.0.tar.gz. Zawiera dwa pliki. Jednym z plików jest orchestrate.sh skrypt powłoki bash, który instaluje aplikację procesu roboczego platformy .NET.
3. Maszyna wirtualna typu spot: wdrażana jest maszyna wirtualna typu spot. Musi znajdować się w tym samym regionie co wersja aplikacji. Po wdrożeniu jest pobierany worker-0.1.0.tar.gz do maszyny wirtualnej. Szablon bicep wdraża obraz z systemem Ubuntu na maszynie wirtualnej rodziny Standardowa. Te konfiguracje spełniają potrzeby tej aplikacji i nie są ogólnymi zaleceniami dotyczącymi aplikacji.
4. Kolejka magazynu: inna usługa uruchomiona w ramach procesu roboczego platformy .NET zawiera logikę kolejki komunikatów. Identyfikator entra firmy Microsoft przyznaje maszynie wirtualnej typu spot dostęp do kolejki magazynu z tożsamością przypisaną przez użytkownika przy użyciu kontroli dostępu opartej na rolach.
5. Aplikacja procesu roboczego platformy .Net: skrypt orchestrate.sh instaluje aplikację procesu roboczego platformy .NET, która uruchamia dwie usługi w tle. Pierwsza usługa wysyła zapytanie do punktu końcowego Schedule Events i wyszukuje Preempt sygnał i wysyła ten sygnał do drugiej usługi. Druga usługa przetwarza komunikaty z kolejki magazynu i nasłuchuje sygnału Preempt z pierwszej usługi. Gdy druga usługa odbiera sygnał, przerywa przetwarzanie kolejek magazynu i zaczyna się zamykać.
6. Punkt końcowy zdarzeń zaplanowanych zapytań: żądanie interfejsu API jest wysyłane do statycznego adresu IP bez routingu 169.254.169.254. Żądanie interfejsu API wysyła zapytanie do punktu końcowego zaplanowanego zdarzenia dla sygnałów konserwacji infrastruktury.
7. Szczegółowe informacje aplikacji: architektura używa Szczegółowe informacje aplikacji tylko do celów szkoleniowych. Nie jest to istotny składnik orkiestracji obciążeń przerywanych. Dołączyliśmy ją jako sposób weryfikacji danych telemetrycznych z aplikacji procesów roboczych platformy .NET. Skonfigurowaliśmy aplikację procesów roboczych platformy .NET do wysyłania danych telemetrycznych do usługi Application Szczegółowe informacje. Aby uzyskać więcej informacji, zobacz włączanie metryk na żywo z poziomu aplikacji .NET.

Wdrażanie tego scenariusza

Utworzyliśmy repozytorium GitHub o nazwie przerywane obciążenie na miejscu za pomocą szablonów, skryptów i instrukcji krok po kroku, aby wdrożyć tę architekturę. Więcej szczegółów technicznych dotyczących architektury i artefaktów inżynieryjnych znajdziesz w tym repozytorium.

Następny krok

Aby uzyskać więcej informacji na temat maszyn wirtualnych typu spot, zobacz Maszyny wirtualne typu spot platformy Azure.

Powiązane zasoby

• Podejścia architektoniczne do zarządzania kosztami i alokacji w rozwiązaniu wielodostępnym
• Uruchamianie maszyny wirtualnej z systemem Windows na platformie Azure
• Uruchamianie maszyny wirtualnej z systemem Linux na platformie Azure