Articolo
02/16/2017

Febbraio 2017

Volume 32 Numero 2

Il presente articolo è stato tradotto automaticamente.

Azure - Analisi dell'architettura del Servizio app di Azure

Da Yochay Kiriaty | 2017 febbraio

Servizio App di Azure viene considerato una piattaforma eccellente come servizio (PaaS), che offre una piattaforma delle applicazioni per gli sviluppatori creare Web, applicazioni mobili e API. L'intervallo di offerte dal semplice marketing e digital applicazioni presenza per soluzioni e-commerce scalabili e iperscalabili e personalizzabile.

Servizio App è completamente gestito, ovvero che nessuna attività amministrative sono necessarie per gestire le infrastrutture di calcolo sottostanti (server) in cui l'esecuzione delle applicazioni. Non è necessario preoccuparsi di manutenzione del server il carattere di sottolineatura come la piattaforma patch al sistema operativo e un framework per l'utente. L'applicazione viene eseguita sul server virtualizzati, ma è importante solo per impostare il numero massimo di istanze del server in cui si desidera eseguire l'applicazione. Gli handle di piattaforma ridimensionamento quando l'applicazione necessita di ulteriori risorse di calcolo e, contemporaneamente, consente di gestire il traffico di bilanciamento carico tra più istanze dell'applicazione.

Mentre il team del servizio App è eseguendo nel modo migliore per nascondere i dettagli di implementazione sottostanti, è consigliabile essere a conoscenza del funzionamento delle operazioni sotto il coperchio. In questo articolo vengono illustrati l'architettura interna di base del servizio App (come il servizio viene compilato e opera) e offre alcune procedure consigliate per determinati scenari.

Architettura globale e geograficamente distribuiti

Il cloud computing rapidamente scale e con capacità infinita. Scalabilità del cloud può essere spiegato come la ricerca in una schermata di computer. Aspetto da lontano e viene visualizzata un'immagine chiara e senza problemi; Quando un esame più attento, si nota che l'immagine sullo schermo è costituita da molti pixel minimo. Il cloud, ad esempio un'immagine, è costituito da più server. I cluster del servizio App procedura dei server in una singola unità chiamata "unità di scala" (o un indicatore di""). Esistono molti tali unità di scala in tutto il mondo in Data Center di Azure.

Come parte di Azure, il servizio App prevede un footprint globale. In ogni area supportati da Azure, sono disponibili unità di scala del servizio App in esecuzione i carichi di lavoro (applicazioni) e i set di unità di controllo dei clienti. Unità di controllo sono trasparenti per il cliente (fino a quando non sono malfunzionamento) e considerate parte della piattaforma. Esiste un'unità di controllo speciali che viene utilizzata come un gateway per tutte le chiamate API di gestione. Ad esempio, quando un cliente effettua una richiesta per creare una nuova applicazione, tramite il portale, interfaccia della riga di comando o direttamente tramite l'API REST di Azure, la richiesta viene indirizzata a un endpoint di Azure centrale (management.azure.com). Gestione risorse di Azure, o ARM (bit.ly/2i6UD07), consente di lavorare con diverse risorse di Azure nell'applicazione come un unico gruppo. L'API definito da Gestione risorse di AZURE consente di gestire risorse di Azure. ARM non gestisce effettivamente le singole risorse. Ogni servizio in Azure è la propria implementazione di API di gestione che viene inviata da ARM. Nel caso di servizio App, ARM inoltra le chiamate API del servizio App per App Geo-Master del servizio.

Il Master geografica ha contesto su tutte le unità di scala in tutto il mondo. Ad esempio, quando si crea un nuovo servizio App applicazione (o sito Web), Master geografica consente di trovare l'unità di scala più adatto per l'applicazione e quindi inoltra la richiesta di creazione per l'unità di scala appropriata. L'unità di scala è ora il compito di provisioning di una nuova app e allocare le risorse necessarie. Figura 1 viene illustrato il flusso di creazione di una nuova app.

Figura 1 distribuzione globale di unità di scala del servizio App

Questo è il processo per creare una nuova applicazione:

Viene effettuata una richiesta per creare un nuovo sito.
ARM garantisce utente dispone dell'accesso alla risorsa per consentire l'operazione in questione (creato in questo caso) e inoltra le richieste di servizio App geografica-Master.
Geo-Master consente di trovare l'unità di scala adatto migliore per la richiesta dell'utente e inoltra la richiesta.
L'unità di scala crea la nuova applicazione.
Esito positivo report geografica generale per la richiesta di creazione.

Anche se è importante comprendere che il servizio App ha molte unità di scala, l'applicazione viene eseguita in genere in un'unica unità di scala di servizio App. Anche quando si utilizza Gestione traffico di Azure per l'esecuzione in più aree, l'applicazione viene eseguita in due o più unità di scala distinto. Tuttavia, dalla scala singole unità punto di vista, l'app è vincolato a una singola unità di scala.

Che cos'è un'unità di scala del servizio App?

Un'unità di scala del servizio App è una raccolta di server di ospitare ed eseguire le applicazioni. Un'unità di scala tipico può avere più di 1.000 server. Il clustering dei server consente un'economia di scala e il riutilizzo dell'infrastruttura condivisa. Il blocco predefinito fondamentale di unità di scala del servizio App è una distribuzione di servizi Cloud di Azure (tenere presente che il servizio App rilasciato come un'anteprima di giugno 2012). Qualsiasi unità di scala specificato è autonomo e può essere eseguita autonomamente.

Blocchi di compilazione principale unità di scala

La funzionalità principale dell'unità di scala è per ospitare ed eseguire le applicazioni dei clienti. Le applicazioni eseguite su Windows Server e vengono definite i ruoli Web worker o lavoratori breve. La maggior parte dei server in un'unità di scala specificato sono processi di lavoro. Tuttavia, un'unità di scala include più server di supporto aggiuntive necessarie per ottenere la funzionalità fornita dal servizio App. Supporto server hanno ruoli e ogni ruolo viene distribuito in più istanze per la ridondanza e scalabilità.

Front-End

Il front-end è il bilanciamento del carico di sette livelli, che agisce come un proxy, la distribuzione delle richieste HTTP in ingresso tra diverse applicazioni e dai rispettivi dipendenti. Attualmente, l'algoritmo di bilanciamento del carico del servizio App è un semplice round robin tra un insieme di server allocata per una determinata applicazione.

Web worker

Processi di lavoro sono la struttura portante di unità di scala di servizio App. Eseguono le applicazioni.

Con il servizio App, è possibile scegliere come si desidera eseguire l'applicazione. È possibile selezionare l'esecuzione dell'applicazione server condiviso o dedicato. Tale scopo, selezionare un piano di servizio App. Piani di servizio App definisce un set di funzionalità, funzionalità e le allocazioni di server. Un thread di lavoro condivisi ospita le applicazioni da più clienti diversi che garantisce lavoratori dedicato per eseguire una o più applicazioni di un singolo cliente. Esistono diversi tipi di server dedicato e le dimensioni da cui è possibile scegliere. Maggiore è la dimensione del server, le altre risorse di CPU e memoria sono disponibili per le applicazioni allocate. Il piano di servizio App definisce la quantità di server pre-allocato per l'applicazione.

Un'unità di scala del servizio App ha diversi pool di thread di lavoro già disponibile e pronta per ospitare le applicazioni, come illustrato nella figura 2, sezione 1. Quando si definisce il piano di servizio App dedicati a una dimensione pari a due server, il servizio App alloca due server, come illustrato nella figura 2, sezione 2. Successivo, quando scala in orizzontale il piano di servizio App, ad esempio, aggiungere due ulteriori lavoratori-lavoratori disponibili vengono allocate da un pool di thread di lavoro pronti da utilizzare, come illustrato nella figura 2, 3 sezione. Poiché lavoratori già preventivamente il provisioning e calda, tutto ciò che deve essere eseguita è l'applicazione vengono distribuiti nel processo di lavoro. Dopo l'applicazione viene distribuita, il processo di lavoro viene inserita nella rotazione e il front-end può allocare il traffico a esso. In genere, l'intero processo richiede pochi secondi.

Figura 2 processo di applicazione Server nell'unità di scala del servizio App

Figura 2, sezione 4 Mostra più piani di servizio App, identificato come rettangoli colorati, ognuno dei quali rappresenta un piano di servizio App che possono appartenere a più clienti.

File server

Qualsiasi app deve disporre di archiviazione per contenere contenuto, ad esempio HTML, file con estensione js, immagini o file di codice e gli altri contenuti necessari per il funzionamento dell'applicazione. Un file server consente di montare il BLOB di archiviazione di Azure e li espone come unità di rete per il processo di lavoro. Un thread di lavoro, esegue il mapping di tali unità di rete come locale, consentendo di qualsiasi applicazione in esecuzione su qualsiasi thread di lavoro specificato affinché utilizzi l'unità "locale", esattamente come previsto se l'applicazione in esecuzione su un server utilizzando il disco locale. Qualsiasi operazione di lettura/scrittura relative ai file eseguito dall'applicazione passa attraverso un file server.

Controller API

Controller API può essere considerato come un'estensione di App Geo-Master del servizio. Geo-Master è a conoscenza di tutte le applicazioni di servizio App in tutte le unità di scala, ma è il controller di API che esegue effettivamente l'operazione di gestione che influisce sulle applicazioni. Adempimento geografica Master delegati API a un'unità di scala specificata tramite il controller API. Ad esempio, quando una chiamata API per creare una nuova applicazione Master geografica, il controller API Orchestra i passaggi necessari per creare l'applicazione in unità di scala. Quando si utilizza il portale di Azure per reimpostare l'applicazione, è il controller di API che notifica a tutti i Web worker attualmente allocato per l'applicazione per riavviare l'applicazione.

Server di pubblicazione

Servizio App di Azure supporta l'accesso a qualsiasi applicazione FTP. Poiché il contenuto di app è archiviato nei blob di archiviazione di Azure e mappato da file server, servizio App ha un ruolo di server di pubblicazione per esporre le funzionalità FTP. Il ruolo server di pubblicazione consente ai clienti di utilizzare FTP per accedere ai relativi registri e il contenuto dell'applicazione.

È importante tenere presente che esistono molti altri modi per distribuire applicazioni diverse da FTP. Uno dei metodi di distribuzione comune è la distribuzione Web (da Visual Studio) o una delle opzioni di distribuzione continua supportate, ad esempio Gestione versione di Visual Studio o GitHub.

SQL Azure

Ogni unità di scala del servizio App Usa Database di SQL Azure per rendere persistenti i metadati dell'applicazione. Ogni applicazione che viene assegnato a una determinata unità di scala è una rappresentazione in un Database SQL. Il Database SQL viene utilizzato anche per memorizzare le informazioni di runtime sulle applicazioni.

Ruolo di dati

Tutti i ruoli richiedono dati trovati nel database per il funzionamento. Esempi: un Web Worker necessarie informazioni di configurazione del sito quando si avvia un'applicazione; front-end è necessario conoscere quali server assegnati per l'esecuzione di un'applicazione specifica per inoltrare correttamente le richieste HTTP al server appropriato. e i controller di leggere e aggiornare i dati dal database in base alle chiamate API effettuate dai clienti. Il ruolo di dati può essere descritta come un livello di cache tra Database SQL e tutti gli altri ruoli in un'unità di scala specificata. E astrae il livello dati (Database SQL) dal resto dei ruoli, miglioramento della scalabilità e prestazioni, nonché semplificando la manutenzione e lo sviluppo di software.

Procedure consigliate ovvio

Dopo aver appreso come servizio App di Azure è compilato, vengono descritte le diverse suggerimenti dal team di servizio App. Questi sono pratiche lezioni apprese dal team di progettazione del servizio App da clienti numerus.

Controllo della densità

La maggior parte dei clienti di eseguire un numero basso (minore di 10) di applicazioni per ogni piano di servizio App. Tuttavia, esistono molti scenari in cui i clienti vengono eseguite molte altre applicazioni. È importante impedire accidentalmente su saturare la capacità di calcolo dei server sottostante.

Iniziamo con la gerarchia di base delle applicazioni e le relative risorse di calcolo. Esistono due App Web e un'applicazione back-end mobile associata a questo piano di servizio App. Il piano è impostato su due server.

Per impostazione predefinita, tutte le applicazioni contenute in un determinato piano servizio App eseguite su tutte le risorse di calcolo disponibili (server) allocate per il piano di servizio. Tutte le tre applicazioni eseguite in entrambi i server. Nel caso più semplice in cui un piano di servizio App ha un singolo server, è semplice da comprendere: Tutte le applicazioni incluse nel piano di servizio App vengono eseguite in un singolo server.

È meno intuitivo da cosa succede quando sono presenti più risorse di calcolo allocate per il piano di servizio App. Ad esempio, se dispone di un singolo piano 10 risorse di calcolo, quindi tutte le applicazioni di servizio dell'applicazione verranno eseguita in tutte le risorse di calcolo. Se sono presenti 50 applicazioni nel piano di servizio App, verrà eseguito sul primo server, tutte le 50 e 50 stesso verrà eseguito nel secondo server e così via, al server di 10, che verranno installati tutti i 50 applicazioni.

In alcuni scenari, in cui l'applicazione richiede una notevole quantità di risorse di calcolo, in genere per gestire un aumento di richieste HTTP in ingresso, è opportuno che l'applicazione in esecuzione su tutti i server disponibili. Tuttavia, talvolta questa è una conseguenza involontaria che si verifica quando un piano di servizio App viene ampliato da un server a-molti. Se un piano di servizio App è eccessivo della CPU e/o memoria a causa di un numero elevato di applicazioni in esecuzione, l'aumento del numero di server in tale piano di servizio App non risolvere il problema.

Al contrario, prendere in considerazione la distribuzione del traffico per ogni applicazione e separare la cosiddetta coda lunga di scarso App in un piano di servizio App separata. Si consiglia di eseguire le applicazioni di elevata nei piani del servizio App separata. Utilizzando i 50 esempio app dopo l'analisi dei modelli di traffico in precedenza, è possibile che finisce con l'assegnazione seguente a piani di servizio App e risorse di calcolo:

le applicazioni di scarso 40 rimangono in un singolo piano di servizio App in esecuzione su risorsa di un calcolo.
Cinque applicazioni volume mid verso il basso, utilizzano un secondo piano di servizio App in esecuzione su una risorsa di calcolo.
Le altre cinque applicazioni sono disponibili per l'utilizzo di volumi elevati. Ogni applicazione viene distribuita in un piano di servizio App separata. Una regola di scalabilità automatica è impostata su ogni piano di servizio App di utilizzare un minimo di una risorsa di calcolo, con le regole per la scalabilità in/out in base alle CPU e utilizzo della memoria.

Il risultato di questo approccio è che i 50 applicazioni usano sette risorse di calcolo come minimo, con le applicazioni di elevata cinque ognuno dei quali la capacità aggiuntiva necessaria per ampliare in modo indipendente su richiesta in base al carico.

Scalabilità per App

Un'altra alternativa per l'esecuzione di un numero elevato di applicazioni in modo più efficiente consiste nell'utilizzare la funzionalità di ridimensionamento per app di Azure App Service. Il documento nel bit.ly/2iQUm1S illustra in dettaglio la scalabilità per app. Scalabilità per App consente di controllare il numero massimo di server allocata per una determinata applicazione e per eseguire questa operazione per ogni applicazione. In questo caso, un'applicazione verrà eseguito per il numero massimo definito dei server e non in tutti i server disponibili.

Utilizzando i 50 precedente esempio app, con la scalabilità per app abilitate per il piano di servizio App, 50 tutte le applicazioni possono essere assegnate a stesso piano di servizio App. Quindi, è possibile modificare le caratteristiche di scalabilità delle singole App:

applicazioni scarso impostate per l'esecuzione su un massimo di un singolo server ogni 40.
Cinque medio-bassa volumi di applicazioni impostate per l'esecuzione su un massimo di due server.
Cinque applicazioni di elevata rimanenti impostato per eseguire un numero massimo di 10 server.

Il piano di servizio App sottostante può iniziare con un minimo di cinque server. E quindi è possono impostare regole di scalabilità automatica per scalare orizzontalmente man vs pressione della memoria in base alle esigenze. CPU.

Servizio App di Azure consente di gestire automaticamente l'assegnazione delle applicazioni per le risorse di calcolo. Il servizio gestirà automaticamente anche limitando il numero massimo di istanze dell'applicazione in base al numero di thread di lavoro in esecuzione l'impostazione per ogni applicazione. Di conseguenza, aumentando il numero di processi di lavoro nel piano di servizio App non comporterà 50 istanze app girando in ogni nuova macchina virtuale disponibile.

Per riepilogare, la scalabilità per app "pack" applicazioni nei server sottostante associata a un piano di servizio App. Scalabilità per app non comporta in ogni applicazione in esecuzione su ogni risorsa di calcolo associata a un piano di servizio App, come descritto in precedenza.

Slot di applicazione

Servizio App è una funzionalità denominata "gli slot di distribuzione" (bit.ly/2iJzv3f). In breve, uno slot di distribuzione consente di disporre di un'altra applicazione (slot) diverso da app di produzione. È un'altra applicazione che è possibile utilizzare per testare il nuovo codice prima di passare ambiente di produzione.

Gli slot di applicazione è tra la funzionalità più utilizzata nel servizio App. Tuttavia, è importante comprendere che slot ogni applicazione è anche un'applicazione in sé. Ciò significa slot applicazione domini personalizzati associati a essi, diversi certificati SSL, le impostazioni dell'applicazione diversi e così via. Inoltre, che l'assegnazione di uno slot di applicazione per un piano di servizio App può essere gestito separatamente dal piano di servizio App associate allo slot di produzione principale.

Per impostazione predefinita, viene creato uno slot di applicazione nello stesso servizio piano App come slot di produzione. Per applicazioni di scarso, applicazioni e/o con un utilizzo ridotto della CPU o memoria, questo approccio è corretto.

Tuttavia, poiché tutte le applicazioni in un piano di servizio App eseguiti negli stessi server, questo significa per impostazione predefinita che tutti gli intervalli di un'applicazione di sono in esecuzione nello stesso server esatto sottostante come produzione. Questo può causare problemi quali i vincoli di CPU o memoria se si decide di eseguire il test di stress slot non di produzione, eseguiti nello stesso server come slot di applicazione di produzione.

Se l'ambito di concorrenza di risorse è solo per scenari quali l'esecuzione di test di carico, quindi spostare temporaneamente uno slot a un diverso piano di servizio App, con un proprio set di server, verranno effettuate le seguenti:

Creare ulteriori piani di servizio App per gli slot non di produzione. Nota importante: Ogni piano di servizio App deve trovarsi nello stesso gruppo di risorse e piano di servizio App lo slot di produzione stessa area.
Spostare uno slot non di produzione in un piano di servizio App differente e, di conseguenza, un pool di risorse di calcolo separato.
Eseguire attività a elevato utilizzo di risorse (o rischiosa) durante l'esecuzione in cui il piano di servizio App separata. Ad esempio, test di carico possono essere eseguiti in uno slot non di produzione senza conseguenze negative per lo slot di produzione perché non ci sono eventuali conflitti di risorse.
Quando lo slot non di produzione è pronto per essere scambiato nell'ambiente di produzione, spostare nuovamente lo stesso piano di servizio App in esecuzione lo slot di produzione. Quindi l'operazione di scambio di slot può essere eseguita.

La distribuzione nell'ambiente di produzione senza tempi di inattività

Una corretta applicazione è in esecuzione su un piano di servizio App e si dispone di un grande team di eseguire aggiornamenti all'applicazione su base giornaliera. In questo caso, non si desidera distribuire i bit direttamente nell'ambiente di produzione. Si desidera controllare la distribuzione e ridurre al minimo i tempi di inattività. A tale scopo è possibile utilizzare gli intervalli di applicazione. Impostare la distribuzione nello slot di "pre-produzione", che può essere configurato con l'ambiente di produzione e distribuire il codice più recente. È ora possibile testare in modo sicuro l'app. Dopo aver completato, è possibile scambiare i bit di nuovo nell'ambiente di produzione. L'operazione di scambio non riavvia l'applicazione e il Controller di notifica il bilanciamento del carico di front-end per reindirizzare il traffico agli slot di più recente.

Alcune applicazioni richiedono esercitati prima che possano gestire il carico di produzione in modo sicuro, ad esempio, se l'applicazione deve caricare i dati nella cache o per un'applicazione .NET consentire al runtime .NET di JIT di assembly. In questo caso, sarà necessario anche utilizzare gli slot di applicazione per il riscaldamento dell'applicazione prima di scambiarlo nell'ambiente di produzione.

Vediamo spesso i clienti che dispongono di uno slot di pre-produzione che viene utilizzato per testare e riscaldamento dell'applicazione. È possibile utilizzare gli strumenti di distribuzione continua, ad esempio Gestione versione di Visual Studio per impostare una pipeline per il codice essere distribuita in pre-produzione slot, eseguire test di verifica e medio di tutti i percorsi necessari nell'applicazione prima di scambiarlo nell'ambiente di produzione.

Configurazione di rete di unità di scala

L'unità di scala del servizio App viene distribuita nel servizio Cloud. Di conseguenza, implica alcune funzionalità che è possibile acquisire familiarità con per una piena comprensione degli effetti di rete sulle applicazioni e la configurazione di rete.

L'unità di scala con un singolo indirizzo IP virtuale (VIP) esposto al mondo. Tutte le applicazioni allocate a una determinata unità di scala vengono servite tramite questo indirizzo VIP. L'indirizzo VIP è la rappresentazione del servizio Cloud in cui è distribuita l'unità di scala del servizio App.

Le applicazioni di servizio App forniscono solo HTTP (porta 80) e il traffico HTTPS (porta 443). Ogni applicazione di servizio App ha predefinito che supporto di HTTPS predefinite per il nome di dominio azurewebsites.net. Servizio App supporta i certificati di indicazione nome Server (SNI) sia basato su IP SSL Secure Sockets Layer (). Nel caso di SSL basato su IP, una determinata applicazione viene allocata un indirizzo IP dedicato per il solo traffico in ingresso, che è associato alla distribuzione di servizio Cloud. Nota: Front-end terminare la connessione SSL per tutte le richieste HTTPS per tutte le applicazioni e qualsiasi tipo di certificato. Il front-end quindi inoltra la richiesta al processo di lavoro definito per una determinata applicazione.

Indirizzo VIP pubblico

Per impostazione predefinita, non esiste un unico indirizzo VIP pubblico per tutto il traffico HTTP in ingresso. Qualsiasi applicazione è destinata a un singolo indirizzo VIP. Se si dispone di un'applicazione nel servizio App, provare a eseguire il comando nslookup (dalla console di Windows o PowerShell) e visualizzare il risultato. Ecco un esempio:

#1 PS C:\> nslookup awesomewebapp.azurewebsites.net
#2 Server:  UnKnown
#3 Address:  10.221.0.3
#4 Non-authoritative answer:
#5 Name:    waws-prod-bay-001.cloudapp.net
#6 Address:  168.62.20.37
#7 Aliases:  awesomewebapp.azurewebsites.net

Ecco una revisione dell'output di awesomewebapp.azurewebsites.net:

Riga #1 viene eseguito un comando nslookup risoluzione per awseomwebapp.azurewebsites.net l'esecuzione di query.
Riga #5 mostra il nome di dominio dell'unità di scala esecuzione awseomwebapp app. Si noterà che un'unità di scala del servizio App viene distribuita nel servizio Cloud di Azure (dal suffisso cloudapp.net). Siti Web di AZURE è l'acronimo di Windows Azure (quando Azure è stato ancora chiamato Windows) siti Web (il nome originale del servizio App).
Riga #6 viene mostrato l'indirizzo VIP dell'unità di scala. Tutte le applicazioni che sono ospitati e in esecuzione su siti Web di Azure-prod-bay-001 (riga n. 5) sono indirizzabili all'indirizzo VIP pubblico designato.
Riga #7 Mostra tutti gli alias di dominio mappati allo stesso indirizzo IP.

Indirizzi VIP in uscita

Molto probabile che l'applicazione è connessa a altri servizi di non di Azure e Azure. Di conseguenza, l'applicazione effettua le chiamate di rete in uscita agli endpoint non sull'unità di scala dell'applicazione. Ciò include chiamata a servizi di Azure, ad esempio Database SQL e archiviazione di Azure. Sono disponibili fino a cinque indirizzi VIP (quello VIP pubblico e quattro i VIP dedicati in uscita) utilizzato per le comunicazioni in uscita. Non è possibile scegliere che utilizza app VIP e tutte le chiamate in uscita da tutte le App in unità di scala utilizza cinque allocato VIP. Se l'applicazione utilizza un servizio che richiede l'elenco di indirizzi IP che sono autorizzati a effettuare chiamate API in tale servizio, è necessario registrare tutti gli indirizzi cinque VIP dell'unità di scala. Per visualizzare quali gli indirizzi IP sono indirizzi IP virtuali allocati a in uscita per una determinata unità di scala (o per l'applicazione dal punto di vista) passare al portale di Azure, come illustrato nella figura 3.

Figura 3 visualizzazione di indirizzo IP in uscita di applicazioni servizio App nel portale di Azure

Se sta cercando un set di indirizzi IP in ingresso e in uscita dedicate, è possibile esplorare questo utilizzando un ambiente del servizio App completamente isolato e dedicato a bit.ly/2hVRSlR.

SNI SSL e IP

Servizio App supporta i certificati SSL basati su IP. Quando si utilizza SSL IP, il servizio App alloca all'applicazione un indirizzo IP dedicato per il traffico HTTP solo in ingresso.

Diversamente dal resto dell'Azure indirizzi IP dedicati, viene allocato l'indirizzo IP con il servizio App tramite SSL IP, purché si decide di usarlo. L'indirizzo IP non si è proprietari e quando si elimina l'IP SSL, si potrebbe perdere l'indirizzo IP (come può essere allocata in un'altra applicazione).

Servizio App supporta SNI SSL, che non richiede un indirizzo IP dedicato ed è supportato dai browser moderni.

Capacità di porta di rete per le chiamate di rete in uscita

Un requisito comune per le applicazioni è la possibilità di effettuare chiamate di rete in uscita ad altri endpoint di rete. Ciò include chiama Azure servizi interni, ad esempio Database SQL e archiviazione di Azure. Include inoltre casi in cui le applicazioni eseguono chiamate agli endpoint dell'API di HTTP/HTTPS, ad esempio, chiama un'API di ricerca Bing o chiamando un'API "applicazione" che implementa la logica di business back-end per un'applicazione Web.

In quasi tutti questi casi, l'applicazione chiamante in esecuzione nel servizio App di Azure in modo implicito ad aprire un socket di rete ed effettuando chiamate in uscita agli endpoint che sono considerati "remoto" da un punto di vista della rete di Azure. Si tratta di un punto importante poiché le chiamate effettuate da un'app in esecuzione in Azure App Service a un endpoint remoto si basano sulla rete di Azure per configurare e gestire una tabella di mapping Network Address Translation (NAT).

La creazione di nuove voci in questo mapping NAT richiede tempo ed è in definitiva un limite finito al numero totale di mapping NAT che possono essere stabilite per una singola unità di scala di servizio App di Azure. Per questo motivo, il servizio App consente di applicare limiti al numero di connessioni in uscita che possono essere in sospeso in qualsiasi punto nel tempo.

I limiti di numero massimo di connessioni sono i seguenti:

1.920 connessioni per ciascuna istanza B1/S1/P1
3,968 connessioni per ciascuna istanza B2/S2/P2
8,064 connessioni per ciascuna istanza S3/B3/P3
Max limite massimo di 64 KB per ogni ambiente del servizio App

Le applicazioni "perdite" invariabilmente le connessioni eseguite in tali limiti di connessione. Applicazioni verranno avviato intermittente perché non vengono chiamate all'endpoint remoto, con gli errori talvolta correlazione strettamente per periodi di maggiore carico dell'applicazione. Verrà visualizzato di frequente errori simile al seguente: "Un tentativo di accedere a un socket in modalità non consentite dal relativo ddd le autorizzazioni di accesso."

È possibile ridurre notevolmente la probabilità dell'esecuzione di questo problema con alcune procedure consigliate:

Per le applicazioni .NET utilizzando ADO.NET/EF, utilizzare il pool di connessioni di database.
Per php/mySql, utilizzare connessioni di database permanenti.
Per le applicazioni Node. js effettuando chiamate HTTP/HTTPS in uscita, configurare i keep-alive in modo che vengono riutilizzate le connessioni in uscita. Questa configurazione è descritta in bit.ly/2iGrcoo.
Per le applicazioni .NET effettuando chiamate HTTP/HTTPS in uscita del pool e riutilizzare le istanze di System.Net.Http.HttpClient oppure utilizzare le connessioni Keep-alive con System.Net.HttpWebRequest. Nota: Ricordare di aumentare la System.Net.ServicePointManager.DefaultConnectionLimit perché in caso contrario sarà limitato a due connessioni simultanee in uscita allo stesso endpoint.

Ci sono altre limitazioni imposte dalla Sandbox del servizio App. Questi sono i limiti di livello inferiore e i vincoli per Azure App Service e le informazioni più approfonditamente in bit.ly/2hXJ6lL.

Conclusioni

Servizio App di Azure fornisce un'offerta PaaS avanzata per il Web, applicazioni mobili e API. Mentre il servizio dispone di molte parti interne di spostamento, questi sono esclusi in modo che gli sviluppatori possono concentrarsi sulla scrittura di applicazioni eccezionali mentre il servizio gestisce la complessità di tali applicazioni in esecuzione su scala globale.

Molte delle procedure consigliate per il servizio App riguardano il ridimensionamento dell'applicazione. Disporre di una buona conoscenza dei mapping di applicazioni ai Web worker in un piano di servizio App è importante quando si aumenta il numero delle applicazioni in esecuzione nel servizio, pur mantenendo una configurazione di scalabilità ottimale.

Dato il mondo incentrato sul cloud in che operano, Azure e Azure App Service sono sempre in continua evoluzione a un ritmo rapido. Molte nuove innovazioni verranno inserite nella 2017.

Componenti di unità di scala

Potrebbe sembrare come se i componenti di unità di scala sono fortemente dipendenti tra loro. Tuttavia, per impostazione predefinita, si sta regime di controllo. Un'applicazione attualmente in esecuzione (attivamente il traffico HTTP serving) in un determinato Web Worker può continuare a gestire traffico HTTP, anche se altri ruoli nell'unità di scala sono funziona correttamente.

Ad esempio, un server di pubblicazione non funziona correttamente potrebbero ostacolare l'accesso FTP, ma che non interessano il traffico HTTP di un'applicazione o altre opzioni di distribuzione. Se il controller dispone di un bug che impedisce la creazione di nuove applicazioni, questo non significa applicazioni già assegnate all'unità di scala smettono di funzionare.

Yochay Kiriatyè un principal program manager di Microsoft Azure team, in particolare Guida Web, mobili, API e funzioni come parte della piattaforma servizio App di Azure. Kiriaty lavora con tecnologie Web dopo la fine degli anni ' 90 e ha una spiccata passione per la scalabilità e prestazioni. È possibile contattarlo all'indirizzo yochay@microsoft.com e seguirlo su Twitter: @yochayk.

Stefan Schackowè un program manager del team di servizi App di Azure che ha lavorato nel cloud di app Web che offre rispetto ai giorni primo. In Azure, dirige un team di responsabili del programma che si occupano di sviluppo e distribuzione del servizio App di Azure, nonché lo sviluppo di prodotti ibrida locale/cloud di Microsoft (Azure Pack e Stack di Azure). È possibile contattarlo all'indirizzo stefsch@microsoft.com.

Grazie per i seguenti esperti tecnici Microsoft per la revisione dell'articolo: Eduardo Laureano e Nir Mashkowski

Condividi tramite