Questa è una domanda piuttosto carica. Il mio consiglio generale è di focalizzare la vostra attenzione sulla gestione della complessità e consentire al sistema di crescere organicamente.
virtualizzazione:
Vuoi davvero evitare l'espansione del server e in questi giorni tutto è virtualizzato. Scegli una piattaforma che ti consenta di aggiungere rapidamente server virtuali e gestirli in modo efficiente. Una tendenza che ho visto è quella di avere due (ad esempio) cluster AIX o VMWare, uno per prod, uno per non prod. Il non-prod è usato per tutti gli ambienti di sviluppo, test e staging. Questi ambienti sono perfetti per server Web o application server, ma proverei a evitare di mettere database di produzione di grandi dimensioni in crescita come VM (almeno su Windows).
Banche dati
Questi possono facilmente sfuggire di mano ogni volta che devono condividere risorse con altri server. Avere sempre database in esecuzione su un sistema operativo dedicato, mai condiviso con un'applicazione o un server Web a meno che non ci sia una buona ragione per farlo. Se si utilizza una macchina virtuale o hardware è l'unica domanda.
Desideri un'infrastruttura scalabile che non ti limiti se, ad esempio, dovessi passare a una soluzione cluster. Molti database andranno bene in una VM, ma per i pochi che alla fine avranno bisogno di più potenza di quella che è conveniente fornire in un ambiente VM, ti ritroverai a desiderare di metterli invece su hardware grezzo .
Se non stai parlando di Windows, alcune di queste linee guida non saranno pertinenti. È pratica comune accettata mettere grandi database in crescita come LPAR in un hypervisor AIX, per esempio.
Conservazione
Non è possibile avere una virtualizzazione reale (con mobilità VM e clustering host) senza archiviazione condivisa. I server Prod, Dev, Test e QA sembrano tutti uguali per il tuo spazio di archiviazione, tuttavia potresti voler dedicare un po 'di tempo a trovare un modo per dare la priorità al tuo prodotto. È una pessima idea, ad esempio, avere un database prod pesantemente tassato che condivide dischi (set di raid, pool, qualunque cosa) con un server di sviluppo. Lo sviluppatore può colpire i dischi con la stessa forza del prod, a volte, e l'ultima cosa di cui hai bisogno è capire se una sorta di test è ciò che rallenta la tua produzione.
Chiedi a qualcuno che conosce il tuo spazio di archiviazione di sedersi e analizzare tutti i potenziali colli di bottiglia (porte, cache, controller, disco, ecc.) E fare del tuo meglio per prevenire la contesa per il maggior numero possibile di questi tra prod e non-prod.
Detto questo, a volte le persone dell'applicazione devono eseguire benchmark di sviluppo per aiutare a quantificare gli effetti di una nuova patch o qualcosa del genere. In questa situazione, potresti dover essere in grado di offrire loro quantità simili (o almeno quantificabilmente diverse) di potenza di accumulo.