Ho appena esaminato i bilanciatori di carico elastici. A quanto ho capito, fanno solo il round robin, distribuendo uniformemente le connessioni ai server dietro di loro. Quindi cosa succede se si hanno istanze di dimensioni diverse dietro un ELB? Invia più connessioni all'istanza più grande o continua a distribuire uniformemente le connessioni, il che significa che in realtà non dovresti usare istanze di dimensioni diverse.
Risposte:
A quanto ho capito, fanno solo il round robin, distribuendo uniformemente le connessioni ai server dietro di loro.
Un po ', ma non del tutto credo - purtroppo, la documentazione di routing Amazon ELB non è inesistente, quindi è necessario assemblare alcuni pezzi per trarre una conclusione. Ecco l'unico frammento della Guida per gli sviluppatori del bilanciamento del carico elastico di cui sono a conoscenza, vedere la sezione Sessioni adesive in Panoramica sul bilanciamento del carico elastico :
Per impostazione predefinita, un bilanciamento del carico indirizza ciascuna richiesta in modo indipendente all'istanza dell'applicazione con il carico più piccolo . Tuttavia, è possibile utilizzare la funzione di sessione adesiva (nota anche come affinità di sessione), che consente al bilanciamento del carico di associare la sessione di un utente a un'istanza specifica dell'applicazione. Ciò garantisce che tutte le richieste provenienti dall'utente durante la sessione vengano inviate alla stessa istanza dell'applicazione. [enfasi mia]
Cosa significa esattamente il carico più piccolo ? Ancora una volta, l'unica spiegazione di cui sono a conoscenza è la risposta alquanto vaga del team AWS dal 2009 alla strategia ELB :
ELB tiene traccia vagamente di quante richieste (o connessioni nel caso di TCP) sono in sospeso in ogni istanza. Non monitora l'utilizzo delle risorse (come CPU o memoria) in ogni istanza. Attualmente ELB effettuerà il round robin tra quei casi che ritiene abbia il minor numero di richieste in sospeso. [enfasi mia]
Questo ha molto senso riguardo alla loro architettura di sistema e ai casi d'uso indirizzati, ma ovviamente non fornisce la trasparenza e / o il controllo del routing che potresti desiderare o di cui hai bisogno per scenari HA avanzati.
Si noti che, a seconda dell'interpretazione, ciò può essere o meno contraddetto da una risposta più recente del team AWS al bilanciamento del carico elastico - Politiche di distribuzione del carico :
Il round-robin entra in gioco ma le sessioni client non sempre rispettano le cache TTL o DNS in modo da poter ottenere risultati distorti e distribuzioni irregolari delle richieste. L'ELB non ha effetto su ciò che le istanze di traffico / richieste hanno ricevuto finora nelle decisioni relative al routing del traffico. [enfasi mia]
Ovviamente, quanto sopra è modificato con i controlli sanitari adeguatamente documentati, trasparenti e controllabili , che ti danno una certa leva per rimuovere (potenzialmente temporaneamente) le istanze dall'inclusione nel routing in primo luogo, come riassunto nella summenzionata risposta del team AWS a ELB Anche la strategia :
Il bilanciamento del carico controlla lo stato delle istanze registrate con il bilanciamento del carico. Quando il bilanciamento del carico rileva un problema con un'istanza, interrompe la distribuzione del traffico ad essa. Quando l'istanza è di nuovo integra, il bilanciamento del carico riavvia la distribuzione del traffico ad essa. Questo processo consente all'applicazione di reagire automaticamente alle istanze non riuscite senza che tu debba essere coinvolto oltre la configurazione del controllo sanitario.
Sebbene certamente insolito, non vedo perché ELB non dovrebbe funzionare anche con un pool di diversi tipi di istanze Amazon EC2 : non ho provato questo da solo e consiglierei entrambi, Monitoraggio del bilanciamento del carico utilizzando CloudWatch e monitoraggio le tue singole istanze EC2 e correlare i risultati al fine di ottenere informazioni e confidenza relative a tale impostazione alla fine.
Sulla base delle dichiarazioni fatte finora, l'algoritmo di distribuzione è estremamente semplice.
Il front-end di ELB è in genere più di un'istanza ELB e la distribuzione è round robin.
L'algo back-end (le tue istanze) afferma di essere:
ELB tiene traccia vagamente di quante richieste (o connessioni nel caso di TCP) sono in sospeso in ogni istanza. Non monitora l'utilizzo delle risorse (come CPU o memoria) in ogni istanza. Attualmente ELB effettuerà il round robin tra quei casi che ritiene abbia il minor numero di richieste in sospeso.
Ciò significherebbe che se un'istanza più grande ha richieste in sospeso meno, allora più traffico verrebbe indirizzato a loro. Non c'è modo di garantirlo.