Cosa significa che "il primo è già funzionante"?
Hai installato anche SQL Server? Sul secondo che cosa hai installato?
Ti ricordo che un cluster non sono 2 server "identici" con gli stessi programmi installati ma sono 2 server (fisici) che lavorano logicamente come se fosse uno solo. Quindi già in fase di installazione delle applicazioni la procedura di setup è diversa a seconda se devi installare un server singolo o un cluster. Riassumendo al massimo i passi che devi compiere sono

1) installazione del so su entrambi i nodi + tutte le patch necessarie
2) creazione del cluster a livello di sistema operativo
3) installazione delle applicazioni cluster aware

E' fondamentale che al termine di ogni fase ti prendi un ampio periodo di test per eseguire tutti i test possibili per accertare il buon funzionamento e gli event viewer devono essere perfettamente puliti. In particolare dopo le fasi 2 e 3, prima di procedere con il passo successivo (il passo successivo al punto 3 è andare in produzione) devi eseguire tutte le prove possibili di failover, sia manuale (spostando manualmente i gruppi di risorse da un nodo all'altro) che automatico (facendo shutdown o restart di ciascun nodo) ma anche simulando delle situazioni critiche tipo staccare l'alimentazione da uno o da entrambi i nodi simultaneamente, far ripartire le macchine nello stesso istante, ecc al fine di verificare ANCHE il comportamento dello storage...

Bye

chrimai ha scritto:

Il primo server è funzionante nel senso che è già in produzione: ha installato sql 2000 enterprise e sta già lavorando. Adesso hanno deciso di voler fare un cluster.
Infatti i miei dubbi sono sulla possibilità di poterlo fare, visto che la documentazione che sto leggendo parla sempre di cluster partendo da zero.

Sul Book On Line di SQL Server 2000 è documentata la procedura per aggiornare una istanza da una installazione stand-alone ad una istanza clustered. Copia la stringa che segue

mk:@MSITStore:howtosql.chm::/ht_clustering_0pwl.htm

nel menù GO->URL del BOL

Anche sul secondo c'è installato sql 2000 enterprise.

Rimuovilo. Non ti serve...

Ora leggendo quello che riguarda il cluster a livello OS ho visto che avrò bisogno di windows 2003 enterprise, giusto?

Oppure Windows 2000 versione Advanced Server. Ovviamente entrambi i nodi devono avere lo stesso so e lo stesso livello di patching.
Cosa non trascurabile, l'hw deve essere identico e deve trattarsi di hw certificato per l'uso con il cluster.
Inoltre hai pensato allo storage?

Fare un cluster Network Load Balancing invece? stessa cosa?

NLB lo puoi utilizzare per fare clustering di contenuti statici (vedi ad esempio un server web); la profonda differenza tra un cluster di failover ed un cluster NLB è che nel primo caso le risorse del cluster possono lavorare alternativamente su un nodo OPPURE sull'altro. Sempre e soltanto una macchina, quindi, erogherà una determinata risorsa. Un cluster NLB, invece, serve a "bilanciare" il carico tra le macchine che erogano il servizio. Nel cluster di failover è indispensabile che lo storage sia condiviso tra le risorse (fermo restando che solo una risorsa può accedere ai medesimi dati in un dato momento); nel secondo caso non c'è necessità di storage condiviso e ogni macchina accede alle proprie risorse. Visto che parliamo di SQL Server, l'unità minima di "suddivisione" delle risorse è l'istanza, per cui una istanza rappresenterà una risorsa del cluster.

Molto probabilmente sto facendo un po' di confusione e mi scuso in anticipo, ma ho iniziato da poco.

Nessun problema... piuttosto prima di andare in produzione ti consiglio di farti le ossa in un ambiente di test dove fare tutti i test più disparati.
Se un'azienda decide di investire risorse (economiche e umane) su un cluster significa che vuole avere una disponibilità di servizio più elevata di quanto non possa assicurare un server singolo.
In assenza di conoscenze specifiche è molto probabile, invece, che mettere in piedi un cluster senza essere padroni della materia, possa rappresentare una minaccia in grado di ridurre, anzichè elevare, i livelli di servizio.
L'hw certificato per essere cluster aware costa più dell'hw che non nasce per essere clusterizzato (ed a questo devi aggiungere lo storage SAN o SCSI che sia), quindi l'azienda che ha sostenuto tali costi può certamente investire in qualche giornata di consulenza *QUALIFICATA* se vuole proteggere gli investimenti fatti...

Bye

chrimai ha scritto:

creo un nodo standalone per il momento, installo sql 2000 enterp e sposto i database del primo sul secondo.

Reinstallo l'altro server e una volta compleato provo a fare il cluster tra i due.

E' fattibile come cosa?

Si, ma... lo storage condiviso ce l'hai? :-)

Piuttosto che fare tutti i giri che hai intenzione di fare, puoi seguire una strada più semplice, ovvero utilizzare Virtual Server sulla macchina che hai disponibile (e non hai più necessità di avere uno storage dedicato). Segui per le nozioni sull'architettura quanto riportato in questo documento

http://www.microsoft.com/technet/prodtechnol/virtualserver/deploy/cvs2005.mspx

mentre al seguente link trovi gli step dettagliati da seguire

http://www.microsoft.com/downloads/details.aspx?FamilyID=09cc042b-154f-4eba-a548-89282d6eb1b3&displaylang=en

Bye

chrimai ha scritto:

Ma lo storage condiviso non lo creo in fase di costruzione del cluster?

Lo storage non lo crei dal nulla. Se hai una SAN o uno storage SCSI lo sai già da oggi senza dover aspettare domani. Poi quando configurerai le risorse del cluster allora della SAN ne tagli una "fetta" e crei la LUN da far vedere al cluster...

Pensavo di spostare i databases da un'altra parte, in modo da poter creare il cluster in santa pace da zero. Quindi reinstallare entrambe le macchine con win2003 enterprise, seguire la documentazione per la creazione del cluster e quindi rispostare tutti i db nel cluster appena creato con i due server uguali.

Se questi sono i database che dovranno andare su un cluster, ovvero su una soluzione ad alta disponibilità, creare un fermo del servizio per fare i tuoi spostamenti credo che arrechi qualche disagio all'azienda. Allora non è meglio lasciare l'ambiente di produzione dove sta e utilizzare il server libero su cui creare le necessarie VM?

Bye