Ridimensionamento orizzontale: instradamento dei sottodomini generati dall'utente tra i server

Question

Gestisco un'applicazione Web che sta superando un singolo VPS. L'architettura è composta da un gran numero di piccoli utenti, ciascuno con il proprio sottodominio. Gli utenti non interagiscono. Il caricamento indica che devo spostare alcuni utenti e tutti i nuovi utenti in un'altra installazione dell'applicazione Web su un server separato.

Attualmente, ogni sottodominio utente cade sullo stesso virtualhost, dove un singolo front controller PHP visualizza il contenuto appropriato in base al nome host. Un singolo record DNS con caratteri jolly per * .mydomain.com punta al server corrente.

Qual è la mia opzione migliore per il routing di diversi sottodomini utente a server diversi?

I miei pensieri:

• un nuovo dominio di primo livello per tutti i server. user.s1.mydomain.com, user.s2.mydomain.com e così via (informazioni ineleganti e perdite)
• Eseguire il mio server DNS per instradare gli utenti tra server (punto di errore aggiuntivo, tecnologia non familiare)
• A anteriore di controllo/sistema di bilanciamento centrale che reverse-proxy ogni richiesta al server appropriato (punto in più di guasto, i collegamenti potenzialmente limitato)

Answer 1

a quel punto nella scala-out della domanda, mi piacerebbe andare con una centrale bilanciamento del carico anteriore. Nginx dovrebbe gestire qualsiasi carico che viene offerto dinamicamente da un singolo server. Abbiamo nginx come front-end per sei server dinamici e un server con contenuto statico, e non ci sono colli di bottiglia in vista su nginx.

Al punto della scala, configurare nginx per gestire tutto il contenuto statico stesso e invertire il contenuto dinamico del proxy su tutte le caselle necessarie. Il setup per semplice passaggio proxy è vicino a:

upstream upstream_regular_backend { 
    fair; 
    server 10.0.0.1:80; 
    server 10.0.0.2:80; 
} 

server { 
    listen 0.0.0.0:80; 
    server_name example.com; 
    proxy_set_header Host $host; 
    proxy_set_header X-Real-IP $remote_addr; 
    location/{ 
     proxy_pass http://upstream_regular_backend; 
    } 
} 

Per servire contenuti statici e passando di nuovo tutto il resto, qualcosa di simile:

server { 
    listen 0.0.0.0:80; 
    server_name example.com; 
    proxy_set_header Host $host; 
    proxy_set_header X-Real-IP $remote_addr; 
    index index.php; 
    root /some/dir/: 
    location ~ \.php { 
     proxy_pass http://upstream_regular_backend; 
    } 
} 

Naturalmente, se non si sta utilizzando PHP, modificare la configurazione di conseguenza.

Nella definizione upstream, "fair;" eseguirà il bilanciamento del carico dei back-end in base al tempo di risposta. Per i motivi di memorizzazione nella cache, potresti voler usare "ip_hash;" invece, poiché attaccherà le richieste da un client sempre sullo stesso server.

La nostra configurazione è un po 'più in basso sulla strada. Disponiamo di bilanciatori di carico nginx che eseguono il proxy di una cache di vernice, che a sua volta trasmette proxy ai server di contenuti dinamici.

Se si è preoccupati che nginx sia un singolo punto di errore, configurare un server secondario pronto ad assumere l'IP del frontend in caso di errore.