Bilanciamento del carico di Apache con un budget?

Sto cercando di orientarmi intorno al concetto di bilanciamento del carico per garantire la disponibilità e la ridondanza per rendere felici gli utenti quando le cose vanno male, piuttosto che bilanciare il carico per offrire velocità incredibile a milioni di utenti.

Abbiamo un budget limitato e stiamo cercando di attenerci alle cose in cui c'è molta conoscenza disponibile, quindi eseguire Apache su Ubuntu VPS sembra la strategia fino a quando un famoso motore di ricerca non ci acquisisce ( inclusa l'ironia del sabato, per favore ).

Almeno per me, è una giungla completa di diverse soluzioni disponibili. Mod_proxy e HAproxy di Apaches sono due che abbiamo trovato da una rapida ricerca su Google, ma avendo un'esperienza zero di bilanciamento del carico, non ho idea di cosa sarebbe appropriato per la nostra situazione o di cosa avremmo cura scegliendo la soluzione per risolvere il nostro problemi di disponibilità.

Qual è l'opzione migliore per noi? Cosa dovremmo fare per ottenere una disponibilità elevata rimanendo all'interno dei nostri budget?

La soluzione che utilizzo e può essere facilmente implementata con VPS è la seguente:

• Il DNS è round robin'ed (sp?) A 6 diversi indirizzi IP validi.
• Ho 3 bilanciatori di carico con configurazione identica e utilizzo di corosync / pacemaker per distribuire uniformemente i 6 indirizzi IP (in modo che ogni macchina ottenga 2 indirizzi).
• Ciascuno dei bilanciatori del carico ha una configurazione nginx + vernice . Nginx si occupa di ricevere le connessioni, eseguire riscritture e alcune operazioni statiche e passarle a Varnish che esegue il bilanciamento del carico e la memorizzazione nella cache.

Questo arco ha i seguenti vantaggi, a mio avviso parziale:

1. corosync / pacemaker ridistribuirà gli indirizzi IP nel caso in cui uno degli LB fallisca.
2. nginx può essere usato per servire SSL, alcuni tipi di file direttamente dal filesystem o NFS senza usare la cache (video di grandi dimensioni, audio o file di grandi dimensioni).
3. Varnish è un ottimo bilanciamento del carico che supporta peso, verifica dello stato del back-end e svolge un lavoro eccezionale come proxy inverso.
4. Nel caso in cui siano necessari più LB per gestire il traffico, basta aggiungere più macchine al cluster e gli indirizzi IP verranno ribilanciati tra tutte le macchine. Puoi persino farlo automaticamente (aggiungendo e rimuovendo i bilanciatori del carico). Ecco perché uso 6 ips per 3 macchine, per lasciare spazio alla crescita.

Nel tuo caso, avere VPS fisicamente separati è una buona idea, ma rende più difficile la condivisione dell'ip. L'obiettivo è avere un sistema ridondante resistente agli errori e alcune configurazioni per il bilanciamento del carico / HA finiscono per rovinarlo aggiungendo un singolo punto di errore (come un unico bilanciamento del carico per ricevere tutto il traffico).

So anche che hai chiesto informazioni su Apache, ma in quei giorni abbiamo strumenti specifici più adatti al lavoro (come nginx e vernice). Lascia apache per eseguire le applicazioni sul back-end e servirlo usando altri strumenti (non che apache non possa fare un buon bilanciamento del carico o invertire il proxy, è solo una questione di scaricare diverse parti del lavoro su più servizi, quindi ogni parte può fare bene è condivisione).

HAproxy è una buona soluzione. La configurazione è abbastanza semplice.

Avrai bisogno di un'altra istanza VPS per sedere di fronte ad almeno altri 2 VPS. Pertanto, per il bilanciamento del carico / failover sono necessari almeno 3 VPS

Alcune cose a cui pensare è anche:

1. Terminazione SSL. Se si utilizza HTTPS: // tale connessione dovrebbe terminare sul bilanciamento del carico, dietro il bilanciamento del carico dovrebbe passare tutto il traffico su una connessione non crittografata.

2. Archiviazione dei file. Se un utente carica un'immagine dove va? Si siede su una sola macchina? Devi in ​​qualche modo condividere i file istantaneamente tra le macchine: potresti utilizzare il servizio S3 di Amazon per archiviare tutti i tuoi file statici o potresti avere un altro VPS che fungerebbe da file server, ma raccomanderei S3 perché è ridondante e follemente economico.

3. informazioni sulla sessione. ogni macchina nella configurazione del bilanciamento del carico deve essere in grado di accedere alle informazioni sulla sessione dell'utente, perché non si sa mai quale macchina colpirà.

4. db - hai un server db separato? se hai solo una macchina in questo momento, come ti assicurerai che la tua nuova macchina avrà accesso al server db - e se si tratta di un server db VPS separato, quanto è ridondante. Non ha necessariamente senso avere front-end Web ad alta disponibilità e un singolo punto di errore con un server db, ora è necessario considerare anche la replica db e la promozione degli slave.

Quindi sono stato nei tuoi panni, questo è il problema con un sito Web che fa qualche centinaio di visite al giorno a una vera operazione. Diventa complesso velocemente. Spero che ti abbia dato qualche spunto di riflessione :)

Il mio voto è per Linux Virtual Server come bilanciamento del carico. Ciò rende il direttore LVS un singolo punto di errore, ma anche un collo di bottiglia

1. Il collo di bottiglia non è, nella mia esperienza, un problema; il passaggio di reindirizzamento LVS è di livello 3 ed estremamente (computazionalmente) economico.
2. Il singolo punto di errore dovrebbe essere affrontato con un secondo direttore, con i due controllati da Linux HA .

Il costo può essere ridotto facendo in modo che il primo direttore si trovi sulla stessa macchina del primo nodo LVS e il secondo direttore sulla stessa macchina del secondo nodo LVS. I nodi terzi e successivi sono nodi puri, senza implicazioni LVS o HA.

Questo ti lascia anche libero di eseguire qualsiasi software web server che ti piace, poiché il reindirizzamento avviene sotto il livello dell'applicazione.

Che ne dici di questa catena?

round robin dns> haproxy su entrambe le macchine> nginx per separare i file statici> apache

Probabilmente usa anche ucarp o il battito cardiaco per assicurarti che il haproxy risponda sempre. Stunnel starebbe di fronte a haproxy se anche tu avessi bisogno di SSL

Si consiglia di utilizzare un software di clustering appropriato. Cluster Suite di RedHat (o CentOS) o Oracle ClusterWare . Questi possono essere utilizzati per impostare cluster attivi-passivi e possono essere utilizzati per riavviare i servizi e fallire tra i nodi in caso di problemi gravi. Questo è essenzialmente quello che stai cercando.

Tutte queste soluzioni cluster sono incluse nelle rispettive licenze del sistema operativo, quindi probabilmente hai un buon costo. Richiedono un qualche modo di archiviazione condivisa: un mount NFS o un disco fisico a cui accedono entrambi i nodi con un file system cluster. Un esempio di questi ultimi sarebbero i dischi SAN con accesso multiplo all'host, formattati con OCFS2 o GFS . Credo che tu possa usare i dischi condivisi VMWare per questo.

Il software del cluster viene utilizzato per definire "servizi" che funzionano sempre su nodi o solo quando quel nodo è "attivo". I nodi comunicano tramite heartbeat e monitorano anche tali servizi. Possono riavviarli se notano errori e riavviare se non possono essere riparati.

Fondamentalmente configureresti un singolo indirizzo IP "condiviso" a cui sarebbe diretto il traffico. Quindi è possibile definire anche apache e tutti gli altri servizi necessari ed eseguirli solo sul server attivo. Il disco condiviso verrebbe utilizzato per tutto il contenuto Web, i file caricati e le directory di configurazione di Apache. (con httpd.conf, ecc.)

Nella mia esperienza, questo funziona incredibilmente bene.

• Non è necessario il round robin DNS o qualsiasi altro servizio di bilanciamento del carico a singolo punto di errore: tutto colpisce un IP / FQDN.
• I file caricati dagli utenti vengono archiviati in tale archivio condiviso e quindi non importa se il computer esegue il failover.
• Gli sviluppatori caricano contenuti su quel singolo IP / FQDN con zero formazione aggiuntiva ed è sempre aggiornato se fallisce.
• L'amministratore può prendere la macchina offline, correggerla, riavviare, ecc. Quindi eseguire il failover del nodo attivo. Fare un aggiornamento richiede tempi di inattività minimi.
• Quel nodo ormai obsoleto può essere mantenuto senza patch per un po ', rendendo un failback un processo altrettanto semplice. (Più veloce delle istantanee di VMWare)
• Le modifiche alla configurazione di Apache sono condivise, in modo che durante un failover non accada nulla di strano, poiché un amministratore ha dimenticato di apportare modifiche sulla casella offline.

--Christopher Karel

Il bilanciamento del carico ottimale può essere molto costoso e complicato. Il bilanciamento del carico di base dovrebbe garantire che ogni server esegua lo stesso numero di accessi in qualsiasi momento.

Il metodo di bilanciamento del carico più semplice consiste nel fornire più record A nel DNS. Per impostazione predefinita, l'indirizzo IP verrà configurato con un metodo round robin. Ciò comporterà una distribuzione relativamente uniforme degli utenti tra i server. Questo funziona bene per i siti senza stato. Un metodo un po 'più complesso è richiesto quando si dispone di un sito con stato.

Per gestire i requisiti con stato, è possibile utilizzare i reindirizzamenti. Assegna a ciascun server Web un indirizzo alternativo come www1, www2, www3, ecc. Reindirizza la connessione www iniziale all'indirizzo alternativo dell'host. È possibile che si verifichino problemi con i segnalibri in questo modo, ma dovrebbero essere distribuiti uniformemente sui server.

In alternativa, l'utilizzo di un percorso diverso per indicare quale server sta gestendo la sessione stateful consentirebbe sessioni proxy che hanno cambiato host al server originale. Questo potrebbe essere un problema quando la sessione per un server guasto arriva al server che ha preso il posto del server guasto. Tuttavia, escludendo il software di clustering lo stato mancherà comunque. A causa della memorizzazione nella cache del browser, è possibile che non si verifichino molte sessioni che cambiano server.

Il failover può essere gestito configurando il server per assumere l'indirizzo IP di un server guasto. Ciò ridurrà al minimo i tempi di inattività se un server si guasta. Senza il software di clustering, le sessioni stateful andranno perse se un server si guasta.

Senza failover, gli utenti subiranno un ritardo fino a quando il browser non passa al successivo indirizzo IP.

L'uso dei servizi Restful anziché delle sessioni stateful dovrebbe eliminare i problemi di clustering sul front-end. I problemi di clustering sul lato di archiviazione continuerebbero ad applicarsi.

Anche con i sistemi di bilanciamento del carico davanti ai server, probabilmente avrai DNS round robin davanti a loro. Ciò garantirà l'utilizzo di tutti i servizi di bilanciamento del carico. Aggiungeranno un altro livello al tuo design, con ulteriore complessità e un altro punto di errore. Tuttavia, possono fornire alcune funzionalità di sicurezza.

La soluzione migliore dipenderà dai requisiti pertinenti.

L'implementazione di server di immagini per offrire contenuti come immagini, file CSS e altri contenuti statici può facilitare il carico sui server delle applicazioni.

In genere utilizzo un paio di macchine OpenBSD identiche:

• Utilizzare RelayD per il bilanciamento del carico, il monitoraggio del server Web e la gestione di un server Web guasto
• Utilizzare CARP per l'alta disponibilità dei bilanciatori di carico stessi.

OpenBSD è leggero, stabile e abbastanza sicuro: perfetto per i servizi di rete.

• http://www.openbsd.org - Sito principale
• http://www.openbsd.org/faq/pf/carp.html - Documentazione sulla carpa
• https://calomel.org/relayd.html - Un discreto insieme di informazioni howto su RelayD

Per iniziare, raccomando una configurazione layer3. Evita l'installazione del firewall complicazioni (PF). Ecco un esempio di file /etc/relayd.conf che mostra l'installazione di un semplice bilanciamento del carico di inoltro con il monitoraggio dei server web back-end:

# $OpenBSD: relayd.conf,v 1.13 2008/03/03 16:58:41 reyk Exp $
#
# Macros
#

# The production internal load balanced address
intralbaddr="1.1.1.100"

# The interface on this load balancer with the alias for the intralbaddr address
intralbint="carp0"

# The list of web/app servers serving weblbaddress
intra1="1.1.1.90"
intra2="1.1.1.91"

# Global Options
#
# interval 10
timeout 1000
# prefork 5

log updates

# The "relaylb" interface group is assigned to the intralbint carp interface
# The following forces a demotion in carp if relayd stops
demote relaylb

#
# Each table will be mapped to a pf table.
#
table <intrahosts> { $intra1 $intra2 }

# Assumes local webserver that can provide a sorry page
table <fallback> { 127.0.0.1 }

#
# Relay and protocol for HTTP layer 7 loadbalancing and SSL acceleration
#
http protocol httprelay {
        return error
        header append "$REMOTE_ADDR" to "X-Forwarded-For"
        header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By"
        # header change "Connection" to "close"

        # Various TCP performance options
        tcp { nodelay, sack, socket buffer 65536, backlog 128 }

#       ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
#       ssl session cache disable
}

relay intra-httprelay {
        listen on $intralbaddr port 80
        protocol httprelay

        # Forward to hosts in the intrahosts table using a src/dst hash
        # The example shows use of a page with dynamic content to provide
        # application aware site checking.  This page should return a 200 on success,
        # including database or appserver connection, and a 500 or other on failure
        forward to <intrahosts> port http mode loadbalance \
                check http "/nlbcheck.asp" code 200

}

Hai dato ec2 con cloudfoundry o forse Elastic beanstalk o solo un semplice vecchio AWS che scalava automaticamente un pensiero. L'ho usato e si adatta abbastanza bene ed essere elastico può scalare / abbassare senza alcun intervento umano.

Dato che dici di non avere esperienza con il bilanciamento del carico, suggerirei queste opzioni in quanto richiedono un minimo "cervello" per iniziare a funzionare.

Potrebbe essere un uso migliore del tuo tempo.