Esiste un limite rigido per quanto tempo può richiedere l'avvio del ruolo di Azure?

Question

Supponiamo che includa uno startup task piuttosto longevo nel ruolo di Azure, eseguendo qualcosa di simile a diversi minuti. Cosa succede se l'attività di avvio viene eseguita "troppo lunga".

Attualmente sto testando su Compute Emulator e osservo quanto segue.

Ho un file .zip da 450 megabyte insieme a Info-Zip unzip. L'operazione di avvio decomprime l'archivio. La distribuzione inizia e guardo in Task Manager. Vengono avviati numerosi processi di servizio, quindi viene eseguito unzip.exe. Dopo circa due minuti tutti questi processi si interrompono, quindi ricominciano di nuovo e si avvia nuovamente unzip.exe.

Quindi sembra che una distribuzione possa essere eseguita per circa due minuti, quindi viene forzatamente reimpostata e riavviata.

È questo il comportamento previsto? Persiste sul cloud reale? Esistono limiti rigidi sulla durata di un ruolo che può assumere l'avvio? Come posso risolvere questa situazione, ad eccezione dello spostamento della decompressione in RoleEntryPoint.OnStart()?

Answer 1

Ho avuto la stessa domanda, quindi ho provato un esperimento. Ho eseguito un'attività di avvio - taskType = "simple" in modo che blocchi i ruoli dall'inizio alla fine - e lo faccia funzionare per 50 ore. Fabric Controller non si è lamentato e il portale non ha mostrato alcun errore. Ha terminato il suo lungo ciclo di "non fare niente" dopo che erano trascorse le 50 ore, quindi questa attività di avvio è stata interrotta e il mio ruolo Web è stato avviato correttamente.

Quindi il mio test di funzionamento dice che le attività di avvio possono richiedere molto tempo! Almeno 50 ore.

Answer 2

Ci sono alcuni heartbeat che Azure Fabric Agent farà contro il ruolo. Se questi non sono riconosciuti (ad esempio un processo di blocco di lunga durata), ciò potrebbe causare la segnalazione del ruolo come non disponibile.

Si potrebbe provare a mettere il processo di avvio in un thread in background che viene eseguito in modo indipendente. Questo dovrebbe aiutare a mantenere il ruolo di essere riciclato durante l'avvio del processo. Tieni presente che potrebbe essere necessario apportare alcune modifiche se ricevi richieste prima che il ruolo inizi completamente. C'è anche un modo (che non riesco a ricordare ATM) per contrassegnare il ruolo e portarlo fuori dal bilanciamento del carico temporarialmente mentre il processo si completa.

Answer 3

Questo dovrebbe informare il bilanciamento del carico che il processo è ancora occupato:

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

Answer 4

Ho eseguito le attività di avvio che vengono eseguiti per un tempo piuttosto lungo (si pensi 20-30 minuti) e il ruolo è semplicemente in uno stato 'Occupato'. Non penso ci sia un limite difficile per quanto a lungo il ruolo rimarrà in quello stato finché l'attività di avvio è ancora in esecuzione e non è uscita con un codice di ritorno diverso da zero (in realtà, questo è un trucco per la maggior parte i creatori di attività di avvio prima volta che visualizzano un prompt). La FC sta ancora funzionando tecnicamente, quindi non ci sarebbe alcun motivo per "recuperare" il ruolo (cioè i battiti del cuore stanno ancora andando).

L'emulatore di dev nota solo quando il ruolo non è stato avviato e avvisa. Se si fa clic sull'opzione 'mantieni in attesa', continuerà a eseguire l'attività di avvio fino al completamento. Il cloud non lo fa ovviamente (avvisalo).

Non ho mai provato un'operazione che è durata molto tempo, quindi potrebbe esserci un limite molto lungo. Mi sembra di ricordare 3 ore era un numero magico in alcuni casi di timeout come ricicla il ruolo, ma non ho mai provato ...