1 record A per ogni sottodominio (10000+); eventuali problemi potenziali? Qualche altra soluzione?

Question

La maggior parte delle soluzioni che ho letto qui per supportare il sottodominio per utente a livello DNS consiste nel puntare tutto su un IP usando * .domain.com.

È una soluzione facile e semplice, ma cosa succede se desidero indirizzare i primi 1000 utenti registrati al server A e i successivi 1000 utenti registrati al server B? Questa è la soluzione preferita per noi per contenere i nostri costi in software e hardware per il clustering.

alt text http://learn.iis.net/file.axd?i = 1101 (diagramma citato dal sito MS IIS)

La soluzione più logica sembra avere 1 record A per sottodominio nei file di dati di zona. BIND non sembra avere alcun limite di dimensione sui file di dati di zona, limitato solo alla memoria disponibile.

Tuttavia, il mio team è preoccupato per la latenza di preparazione e preparazione del nuovo subdoamin, poiché la creazione di un nuovo sottodominio consiste nell'inserimento di un nuovo A-record & amp; riavvio del server DNS.

Le prestazioni del riavvio del server DNS sono qualcosa di cui dovremmo preoccuparci?

Grazie in anticipo.

UPDATE:

Sembra che molti di voi mi suggeriscano di utilizzare invece una configurazione proxy inversa:

alt text http://learn.iis.net/file.axd?i = 1102

(ARR è la soluzione proxy inverso di IIS7)

Tuttavia, ecco i contro che posso vedere:

1. singolo punto di errore
2. non può configurare strategicamente server in posizioni diverse in base alla geolocalizzazione IP.

Answer 1

Il proxy front-end con una voce DNS jolly è davvero la strada da percorrere. È così che funzionano grandi siti come LiveJournal.

Nota che questo non è solo un bilanciamento del carico di livello TCP: ci sono molte soluzioni che esamineranno la parte host dell'URL per capire quale server back-end inoltrare anche la query. Puoi farlo facilmente con Apache in esecuzione su un server con specifiche basse con configurazione adatta .

Il proxy assicura che la sessione di ogni utente vada sempre sul server back-end giusto e la maggior parte dei metodi di gestione della sessione continuerà a funzionare.

Inoltre, il proxy non deve essere un singolo punto di errore. È perfettamente possibile e abbastanza facile eseguire due o più proxy front-end in una configurazione ridondante (per evitare guasti) o persino farli condividere il carico (per evitare stress).

Vorrei anche secondare il suggerimento di John Sheehan che l'applicazione guardasse solo la parte sinistra dell'URL per determinare quale contenuto dell'utente visualizzare.

Se si utilizza Apache per il back-end, consultare questo post anche per informazioni su come configurarlo.

Answer 2

Utilizzare la voce DNS con caratteri jolly, quindi utilizzare il bilanciamento del carico per distribuire il carico tra i server, indipendentemente dal client in cui si trovano.

Mentre ci sei, salta il passaggio di riscrittura dell'URL e chiedi alla tua applicazione di determinare quale account si basa sull'URL inserito (puoi facilmente determinare cosa X è in X.domain.com come nel dominio. com? user = X).

EDIT: Sulla base delle tue informazioni aggiuntive, potresti voler sviluppare un " broker " che memorizza quali client devono accedere a quali server. Rendi tale pubblico quindi attingi alle risorse associate al client memorizzato con il broker. Il tuo front-end può essere bilanciato in base al carico, quindi puoi prendere i file / db server in base a chi sono.

Answer 3

Se usi tinydns, non è necessario riavviare il nameserver se si modifica il suo database e non dovrebbe essere un collo di bottiglia perché è generalmente molto veloce. Non so se funziona bene con oltre 10000 voci (mi sorprenderebbe altrimenti).

http://cr.yp.to/djbdns.html