Qual è un metodo tipico per scalare un software di bilanciamento del carico?

Spesso vedo le architetture di applicazioni web con un SLB / reverse-proxy di fronte a un gruppo di server di applicazioni.

Cosa succede quando il numero di connessioni al SLB richiede troppe risorse per un singolo SLB per gestire efficacemente? Per un esempio concreto ma troppo alto, prendi in considerazione 2 milioni di connessioni HTTP persistenti. Chiaramente un singolo SLB non può gestire questo.

  • Come utilizzare nginx come proxy inverso con più IP e SSL?
  • Come faccio a scalare l'istanza EC2?
  • Come utilizzare la vernice per la prova A / B e la function di lancio?
  • Scalabilità 1-way. Cosa significa?
  • Quale hardware devo aggiungere una connessione Internet di backup?
  • Quanti database possono esprimere gestire SQL server
  • Qual è la configuration consigliata per ridimensionare un SLB?

    È tipico creare un gruppo / cluster di LB? In caso affermativo, come si estende il carico del client tra il gruppo di LB?

    6 Solutions collect form web for “Qual è un metodo tipico per scalare un software di bilanciamento del carico?”

    I bilanciatori di carico non possono essere facilmente scalati da altri bilanciatori di carico poiché in essenza sarà un singolo bilanciatore di carico sulla catena da qualche parte mantenendo le connessioni. Detto questo, i bilanciatori come LVS o HAProxy hanno una capacità assurda nella gamma Gbps. Una volta che si supera le capacità di un singolo bilanciere del carico (software, hardware, qualunque cosa), allora devi spostarsi in altre tecniche come il DNS rotondo.

    OK, c'è già una risposta accettata, ma c'è qualcosa da aggiungere .. I più comuni modi "classici" di ridimensionamento del livello di bilanciamento del carico sono (in nessun ordine particolare):

    • DNS Round Robin per pubblicizzare più indirizzi IP per il dominio. Per ciascun indirizzo IP, implementare una coppia server altamente disponibile (2 server che cooperano per mantenere un indirizzo IP sempre in function). Ogni IP corrisponde a un cluster di bilanciamento del carico, utilizzando apparecchi o server con software di bilanciamento del carico. Scala orizzontalmente aggiungendo altre coppie di bilanciamento del carico come necessario.

    • Modifica di routing o firewall per distribuire il carico a più bilanciere del carico. Avere il router frontale o il firewall anteriore diffondere le connessioni in arrivo a più indirizzi IP (ciascuno che rappresenta una coppia di bilanciamento del carico), usando l'indirizzo IP di origine , avendo più itinerari a costi equivalenti ai bilancieri di carico o simili.

    • Uno strato di bilancieri di carico a livello IP davanti a uno strato di bilanciatori di carico di livello HTTP . Il bilanciamento del carico a livello IP può essere implementato in ASIC / silicio e può essere veloce per alcune cose. Così una coppia di bilanciatori di carico IP può spesso "tenere il passo" con diversi bilanciatori di carico a livello di HTTP / HTTPS e fornire livelli di performance multi-gigabit mantenendo l'architettura piacevole e semplice.

    Andando completamente in profondità sui diversi modi di fare quanto sopra, richiederebbe una risposta molto lunga. Ma in generale non è difficile scalare il livello di bilanciamento del carico , è molto più difficile scalare il livello del server delle applicazioni e in particolare il livello di database.

    Se si sceglie un fattore di forma dell'apparecchio (F5, Cisco, A10) o un server generico (Windows / Linux + software), è più importnte. Le considerazioni principali quando si scalano il livello di bilanciamento del carico sono:

    • Stato pieno rispetto agli apolidi. Hai assolutamente bisogno di sedute appiccicose o puoi vivere senza? Non mantenere lo stato rende tutto più semplice.
    • 'Hardware' (ASIC) rispetto a 'software' (server di uso generale) per il bilanciamento del carico. Ognuno ha i suoi vantaggi e contro, vedere la documentazione di panoramica HAProxy collegata sopra.
    • L3 / 4 (IP / TCP / IP) bilanciamento del carico rispetto al bilanciamento del carico L7 (HTTP) . Ancora, i pro ei contro, il documento HAProxy fornisce una buona panoramica.
    • Terminazione SSL , where, sui webnodes o sull'equilibratore di carico.

    In genere, non è necessario preoccuparsi di questo prima che il tuo sito web diventa molto grande – un singolo server moderno con fx nginx gestirà decine di migliaia di richieste HTTP ordinarie al secondo. Quindi non fare ottimizzazione precoce, non occupatevi di questo prima di wherervi fare.

    La chiave per scalare un livello di bilanciamento del carico HTTP è quello di aggiungere un altro livello di bilanciamento del carico di livello inferiore (IP o TCP). Questo livello può essere costruito interamente con software open source, anche se si ottengono risultati migliori se si dispone di moderni router.

    I flussi (sessioni TCP) dovrebbero essere smascherati utilizzando intestazioni come porte IP e TCP di origine / destinazione, per decidere quale front-end in cui vanno. Hai anche bisogno di un meccanismo per assicurarsi che quando un frontend muoia, si smette di utilizzare.

    Ci sono diverse strategie, ho intenzione di definire una coppia che ho usato nella produzione su siti che servono milioni di utenti, in modo da poter get l'idea. Sarebbe troppo lungo per spiegare tutto in dettaglio, ma spero che questa risposta ti darà informazioni / puntatori sufficienti per iniziare. Al fine di implementare queste soluzioni hai bisogno di qualcuno che sia veramente informato sulla networking.

    Certamente quello che sto descritto qui è molto più difficile da implementare rispetto a quello che è descritto in altre risposte, ma questo è veramente lo stato dell'arte se hai un sito web ad alto traffico con grandi problemi di scalabilità e requisiti di disponibilità oltre il 99,9% . Se si dispone già di un tecnico di networking, il tipo di ragazzo a bordo, costa less l'installazione e l'esecuzione (sia in capex che in opex) rispetto agli apparecchi di bilanciamento del carico e può essere ulteriormente ridimensionato a quasi nessun costo aggiuntivo (rispetto all'acquisto di un nuovo, costoso apparecchio quando si supera il model corrente).

    Prima strategia: con un firewall

    Presumibilmente si dispone di un paio di router su cui i collegamenti ISP sono collegati. Il tuo ISP fornisce 2 collegamenti (attivi / passivi, utilizzando VRRP). Nei tuoi router, utilizzi anche VRRP e instradai il traffico verso la networking pubblica a un firewall. I firewall (anche FW 1 e FW 2 ) sono attivi / passivi e filtreranno il traffico e invieranno each stream ad un server frontale sani (i bilanci di carico HTTP, FE 1 e FE 2 basso).

           + -------------- + + -------------- +
           |  Router ISP A |  |  Router ISP B |
           + -------------- + + -------------- +
                  |  |
                == # ====================== # == (networking pubblica)
                  |  |
           + --------------- + + --------------- +
           |  Il router A |  |  Il router B |
           + --------------- + + --------------- +
                  |  |
                == # ===== # ========== # ===== # == (networking privata RFC 1918)
                  |  |  |  |
            + ------ + + ------ + + ------ + + ------ +
            |  FW 1 |  |  FE 1 |  |  FE 2 |  |  FW 2 |
            + ------ + + ------ + + ------ + + ------ +
    

    L'objective è quello di avere un stream simile a questo:

    1. ISP indirizza il traffico verso i tuoi IP al router attivo.
    2. I tuoi router indirizzano il traffico a un VIP che utilizza un indirizzo RFC 1918 . Questo VIP è di properties; del firewall attivo, molto simile a VRRP. Se si utilizza OpenBSD per i propri firewall, è ansible utilizzare CARP , un'alternativa libera a VRRP / HSRP.
    3. Il firewall applica il filter (ad esempio "consente solo 80 / tcp e 443 / tcp ad andare a questo particolare indirizzo IP").
    4. Il firewall funziona anche come router e inoltra i pacchetti a un frontend sano.
    5. Il tuo frontend termina la connessione TCP.

    Ora la magia accade nei passaggi 4 e 5, quindi vediamo più in dettaglio ciò che fanno.

    Il firewall conosce l'elenco dei frontend ( FE 1 e FE 2 ) e selezionerà uno di essi in base ad un particolare aspetto del stream (ad esempio per hashing l'origine IP e la port, tra le altre intestazioni). Ma ha anche bisogno di assicurarsi che è inoltrare il traffico verso un frontend sano, altrimenti si blackhole traffico. Se si utilizza OpenBSD, ad esempio, è ansible utilizzare relayd . Quello che relayd è semplice: controlla tutti i vostri frontend (ad esempio inviando loro una richiesta HTTP di sonda) e each volta che un frontend è sano, lo aggiunge a una tabella che il firewall utilizza per select il salto successivo dei pacchetti di un dato stream. Se un frontend non riesce a verificare la salute, viene rimosso dalla tabella e nessun pacchetto viene inviato ad esso più. Quando si inoltra un pacchetto a un frontend, tutto il firewall fa scambiare l'indirizzo MAC di destinazione del pacchetto come quello del frontend scelto.

    Nel passaggio 5, i pacchetti dall'utente vengono ricevuti dal tuo bilanciatore di carico (vernice, nginx o altro). A questo punto, il pacchetto è ancora destinato all'indirizzo IP pubblico in modo da poter applicare alias i tuoi VIP sull'interface di loopback. Questo è chiamato DSR (Return Server Return), perché i frontend terminano la connessione TCP e il firewall in mezzo vede solo traffico simplex (solo pacchetti in arrivo). Il tuo router indirizza i pacchetti in output direttamente ai router ISP. Ciò è particolarmente utile per il traffico HTTP perché le richieste tendono ad essere più piccole delle risposte, talvolta in modo significativo. Solo per essere chiaro: questa non è una cosa specifica di OpenBSD e è ampiamente utilizzata nei siti web ad alto traffico.

    grattacapi:

    • Gli utenti finali si collegheranno direttamente ai server frontend perché si utilizza DSR. Forse è già stato il caso, ma se non lo è, è necessario assicurarsi che siano adeguatamente protetti.
    • Se si utilizza OpenBSD, fare attenzione a che il kernel sia filettato singolarmente e quindi le performance di un singolo nucleo CPU limitino il throughput di un firewall. Potrebbe essere un problema a seconda del tipo di NIC e del tasso di pacchetti che stai visualizzando. Ci sono modi per risolvere questo problema (più su questo sotto).

    Seconda strategia: senza un firewall

    Questa strategia è più efficiente ma è più difficile da configurare perché dipende più dalle specifiche dei router che hai. L'idea è quella di bypassare il firewall sopra e di avere i router facendo tutto il lavoro che i firewall stanno facendo.

    Avnetworking bisogno di router che supportno gli ACL L3 / L4 per-port, BGP e ECMP e il PBR ( Policy Based Routing ). Solo i router di fascia alta supportno queste funzionalità e spesso hanno tariffe supplementari per la licenza per utilizzare BGP. Ciò è in genere ancora più economico rispetto ai bilancieri di carico hardware, ed è anche molto più facile da scalare. La buona cosa su questi router high-end è che essi tendono ad essere line-rate (per esempio, possono sempre massimizzare il collegamento, anche su interfacce da 10GbE, perché tutte le decisioni che fanno sono fatte in hardware da ASIC).

    Sulle porte su cui hai i tuoi uplink ISP, applica l'ACL che era usato nel firewall (ad esempio "consente solo 80 / tcp e 443 / tcp a questo particolare indirizzo IP"). Quindi ognuno dei vostri frontali gestisca una session BGP con il tuo router. È ansible utilizzare l'ottimo OpenBGPD (se i frontend sono su OpenBSD) o Quagga . Il tuo router ECMP genera il traffico verso le frontali che sono sane (perché stanno mantenendo le sessioni BGP). Il router inoltre percorrerà il traffico in modo appropriato utilizzando PBR.

    perfezionamenti

    • Con la soluzione di coppia di firewall, è bello se è ansible sincronizzare gli stati TCP attraverso i firewall, in modo che quando un firewall non riesce, tutto non riesce più facilmente all'altro. Puoi raggiungere questo con pfsync .
      • Tenga presente che pfsync in genere raddouble la velocità dei pacchetti sui firewall.
      • HTTP è un protocollo senza statale, quindi non è la fine del mondo se si reimposta tutti i collegamenti durante un failover firewall perché non si utilizza pfsync .
    • Se si supera un unico firewall, è ansible utilizzare l'ECMP sul router per indirizzare il traffico a più di un paio di firewall.
    • Se utilizzi più di un paio di firewall, puoi anche renderli attivi / attivi. È ansible get questo risultato avendo i firewall mantenere una session di BGP con i router, molto simile ai frontenders necessari per mantenere uno nel secondo design senza firewall.

    Esempio di relayd config

    Vedere anche HOWTO all'indirizzo https://calomel.org/relayd.html

     vip = "1.2.3.4" # L'indirizzo IP pubblico
                    # (è ansible avere più di uno, ma non è necessario)
     fe1 = "10.1.2.101"
     Fe2 = "10.1.2.102"
     Fe3 = "10.1.2.103"
     fe4 = "10.1.2.104" # Puoi avere un numero di frontend.
     int_if = "em0"
     tabella <fe> {$ fe1 riprova 2, $ fe2 riprova 2, $ fe3 riprova 2, $ fe4 riprova 2}
     tabella <fallback> {127.0.0.1}
    
     redirect webtraffic {
             ascoltare su $ vip port 80
             session timeout 60
             itinerario per <fe> controlla http "/healthcheck.html" digest "(il sha1sum di healthcheck.html)" interface $ int_if
     }
    

    Personalmente vado a bilanciere di carico hardware più semplici e less configurabili in quel momento – cose come ACE / ASA di Cisco, Foundry ServerIrons, forse anche Zeus ZXTMs (un SW LB che è progettato per carichi molto pesanti).

    Forse, invece di mantenere costantemente tante connessioni aperte per submit risposte, codificare la tua applicazione in modo tale che i clienti periodicamente esaminino i tuoi server il più spesso ansible?

    È tutto ciò che stai facendo effettivamente richiede una risposta in questo millisecondo o un cliente può aspettare 15/20 secondi fino al prossimo polling period?

    Un approccio tipico sarebbe quello di creare un cluster abbastanza grande da gestire il carico richiesto e di utilizzare un SLB che può fare bilanciamento del carico deterministico (nel caso di connessioni persistenti).

    Qualcosa come CARP utilizza un hash del IP richiedente per determinare quale backend web server gestire la richiesta, questo dovrebbe essere deterministico ma non molto utile se c'è un firewall o NAT davanti al tuo bilanciatore di carico.
    È anche ansible trovare qualcosa di simile a IPVS utile se si esegue su Linux.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.