2011-06-06 11 views
5

Załóżmy, że dołączam dość długo działającą startup task do mojej roli Azure - działając przez kilka minut. Co się stanie, jeśli zadanie uruchamiania będzie "zbyt długie".Czy istnieje długi limit czasu uruchamiania usługi Azure Role?

Aktualnie testuję Emulator obliczeń i przestrzegam następujących zasad.

Mam plik .zip 450 megabajtów razem z Info-Zip unzip. Zadanie uruchomienia rozpakowuje archiwum. Rozpoczyna się wdrażanie i zajmuję się Menedżerem zadań. Uruchomione zostaną liczne procesy serwisowe, a następnie uruchom plik unzip.exe. Po około dwóch minutach wszystkie te procesy zatrzymują się i zaczynają od nowa, a unzip.exe uruchamia się ponownie.

Wygląda na to, że wdrożenie może działać przez około dwie minuty, a następnie jest wymuszane resetowanie i uruchamiane ponownie.

Czy to oczekiwane zachowanie? Czy utrzymuje się na prawdziwej chmurze? Czy istnieją jakieś twarde ograniczenia dotyczące czasu, jaki może upłynąć uruchomienie roli? Jak rozwiązać tę sytuację, z wyjątkiem przenoszenia rozpakowywania do RoleEntryPoint.OnStart()?

Odpowiedz

7

Miałem to samo pytanie, więc wypróbowałem eksperyment. Uruchomiłem zadanie uruchamiania - taskType = "simple", aby zablokować role od początku do wykonania - i pozwolić mu działać przez 50 godzin. Kontroler Fabric nie złożył skargi, a portal nie wykazał żadnego błędu. Zakończyło to długą pętlę "do zrobienia niczego" po 50 godzinach, po czym to zadanie startowe zostało zakończone, a moja ról internetowych rozpoczęła się dobrze.

Tak więc mój test emperialny mówi, że zadania uruchamiania mogą zająć dużo czasu! Co najmniej 50 godzin.

0

Istnieje kilka uderzeń serca, które Agent Azure Fabric zrobi przeciwko tej roli. Jeśli nie zostaną potwierdzone (na przykład długotrwały proces blokowania), może to oznaczać, że rola zostanie oznaczona jako niedostępna.

Możesz spróbować umieścić proces uruchamiania w wątku tła działającym niezależnie. Powinno to pomóc w zapobieganiu recyklingowi roli podczas uruchamiania procesu. Pamiętaj, że może być konieczne wprowadzenie pewnych poprawek, jeśli otrzymasz żądania, zanim rola zostanie w pełni uruchomiona. Istnieje również sposób (który nie mogę przywołać ATM), aby oznaczyć rolę i tymczasowo wyjąć ją z modułu równoważenia obciążenia, gdy proces się zakończy.

2

ta powinna poinformować równoważenia obciążenia, że ​​proces ten jest wciąż zajęty:

http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleinstancestatuscheckeventargs.setbusy.aspx

+0

Jak mogę wywołać tę metodę z poziomu zadania uruchamiania? – sharptooth

+0

Nie sądzę, że metoda SetBusy ma zastosowanie do zadań uruchamiania. Możesz użyć SetBusy do swojej roli, jeśli twój kod RoleEntryPoint (np. Metoda Run) robiłby coś czasochłonnego i nie chciał, aby kontroler Fabric pomyślał, że został zawieszony. Jeśli używasz taskType = "proste" zadania uruchamiania (takie, które są uruchamiane do zakończenia przed wywołaniem OnStart), to i tak system równoważenia obciążenia nie wysyła jeszcze ruchu do ciebie. A jeśli używasz albo innego uruchomienia typu taskType (tła lub pierwszego planu), te działałyby niezależnie od twoich metod OnStart i Run. – codingoutloud

1

Mam biegać zadań startowych, które działają na dość długi czas (myślę 20-30 minut) oraz roli jest po prostu w stanie "Zajęty". Nie sądzę, że istnieje twardy limit na to, jak długo ta rola pozostanie w tym stanie, dopóki zadanie Startup nadal będzie wykonywane i nie zakończy się z niezerowym kodem powrotu (w rzeczywistości jest to błąd dla większości po raz pierwszy uruchamianie kreatorów zadań po wyświetleniu monitu). FC nadal działa poprawnie, więc nie ma powodu, aby "odzyskać" rolę (np. Bicie serca nadal trwa).

Emulator dev po prostu zauważa, kiedy rola się nie zaczęła i ostrzega. Jeśli klikniesz opcję "nie przerywaj", zadanie Uruchamianie będzie kontynuowane do końca. Chmura nie robi tego oczywiście (ostrzec).

Nigdy nie próbowałem zadania, które trwało bardzo długo, więc może być bardzo długi limit. Przypominam sobie, że 3 godziny to magiczna liczba w niektórych przypadkach przekroczenia limitu czasu, ale nigdy nie próbowałem ...