19 marzo 2008

RAC cluster interconnect: twisted!

Una delle "limitazioni" più famose delle implementazioni Oracle RAC a due nodi è l'impossibilità, secondo la documentazione, di utilizzare un'interconnect formata da un solo cavo diretto tra un server e l'altro.
Le FAQ di RAC riportano:
NO. CROSS OVER CABLES ARE NOT SUPPORTED.
The requirement is to use a switch:
Detailed Reasons:
1) cross-cabling limits the expansion of RAC to two nodes
2) cross-cabling is unstable:
a) Some NIC cards do not work properly with it. They are not able to negotiate the DTE/DCE clocking, and will thus not function. These NICS were made cheaper by assuming that the switch was going to have the clock. Unfortunately there is no way to know which NICs do not have that clock.
b) Media sense behaviour on various OS's (most notably Windows) will bring a NIC down when a cable is disconnected.
Either of these issues can lead to cluster instability and lead to ORA-29740 errors (node evictions).

Due to the benefits and stability provided by a switch, and their afforability ($200 for a simple 16 port GigE switch), and the expense and time related to dealing with issues when one does not exist, this is the only supported configuration.
Please see certify.us.oracle.com as well.

Vorrei però precisare quanto segue:
  1. Per gli switch moderni a 1 Gb i cavi "cross" sono equivalenti a quelli normali; a me risulta che siano equivalenti anche a 100 Mb (verificato sul mio router di casa).
  2. L'instabilità non è giustificata, a meno che si pensi ai SO Microsoft e ad eventuali versioni Linux che spengono la scheda di rete in caso di inattività prolungata o assenza di segnale all'altro capo in fase di avvio.
  3. Per il funzionamento effettivo del cross-link, basta provare e vedere se funziona
Aggiungiamo che le schede di rete recenti (es. e1000) hanno tutte le migliori caratteristiche desiderabili, e soprattutto possono essere configurate in bonding.

Gli scenari da confrontare sarebbero due:
  1. I 2 nodi collegati a uno switch
  2. I due nodi collegati tra loro
Gli oggetti che si possono rompere, nel caso del "sistema interconnect", sono:
  1. lo switch
  2. i due cavi di rete
  3. le quattro schede di rete
I cavi di rete di per sè sono molto poco propensi a rompersi, visto che strutturalmente sono molto semplici; eventualmente potrebbero essere soggetti a sollecitazioni meccaniche esterne. Sono due, quindi devono rompersi entrambi nello stesso periodo per dare problemi.
Le schede di rete hanno più o meno la stessa probabilità di rompersi di qualsiasi altro elemento attivo. Sono due per server, quindi la ridondanza abbassa di molto la probabilità di disservizio.
Lo switch è unico. Per avere una certa affidabilità e velocità bisogna acquistare qualcosa di più di "$200 for a simple 16 port GigE switch"; qualcosa di molto costoso rispetto ai server. Sta di fatto che è un elemento unico; se si vogliono due switch i costi raddoppiano.

Veniamo ora agli scenari problematici:
  1. Shutdown di una delle due istanze, più o meno volontario
  2. Reset o shutdown software di un server
  3. Spegnimento togliendo la corrente
Le istanze RAC comunicano via interconnect e voting disk. Un reset o uno spegnimento di un nodo sarebbe facilmente risolto dal voting-disk, in teoria. Tra le configurazioni con e senza switch di mezzo c'è una differenza: la mancanza di alimentazione a uno dei capi dell'interconnect, ad esempio per spegnimento di un server, provoca l'errore di link down.
Consideriamo solo il caso senza switch: gli scenari peggiori quindi sono l'interruzione totale e improvvisa dell'alimentazione per un nodo, e il distacco di entrambi i cavi di rete.
La prima possibilità è realistica, e provoca il link down. La seconda possibilità è, consentitemi, praticamente irrealizzabile.

Pensiamoci un attimo: la differenza col caso switch è che in mezzo c'è un altro componente che potenzialmente può dare problemi. La cosa migliore è quindi che lo switch non sia presente! Con un solo switch in mezzo, in caso di spegnimento dello switch stesso per qualsiasi motivo, si realizzerebbe la condizione per cui i nodi non si sentono più via interconnect, hanno un link down, e le istanze sono entrambe nello stesso stato: è la situazione di gran lunga peggiore: quella del distacco dei due cavi di rete dell'interconnect. La configurazione con i cavi diretti è quindi, a mio modo di vedere, addirittura migliore di quella consigliata da Oracle senza appello.

Rimane da provare l'interruzione improvvisa dell'alimentazione per un nodo.
L'ho provata.
In questo caso le istanze non sono nello stesso stato: una non c'è più.
Ecco ciò che succede all'altra istanza:
Tue Mar 11 15:01:42 2008
ospid 1179: network interface with IP address 192.168.1.107 no longer running (check cable)
Tue Mar 11 15:01:52 2008
Reconfiguration started (old inc 2, new inc 4)
List of nodes:
0
Global Resource Directory frozen
* dead instance detected - domain 0 invalid = TRUE
...

Il link down viene rilevato. Tutto prosegue regolarmente. In caso di dubbio Clusterware avrebbe riavviato la macchina. Quindi tutto bene.
Gli indirizzi IP VIP vengono correttamente riconfigurati.

Al ripristino del nodo in failure si ottiene:
Tue Mar 11 15:12:42 2008
ospid 1179: network interface with IP address 192.168.1.107 is now running
Tue Mar 11 15:15:12 2008
Reconfiguration started (old inc 4, new inc 6)
List of nodes:
0 1
Global Resource Directory frozen
Communication channels reestablished
Master broadcasted resource hash value bitmaps
Non-local Process blocks cleaned out
...

Ottimo: link up e riconfigurazione del cluster. Tutto regolare.

In sintesi, per un sistema RAC a due nodi non espandibile, a quanto sembra, è molto meglio avere un'interconnect a cavi diretti piuttosto che avere di mezzo un apparato di rete.

2 commenti:

Cristian Cudizio ha detto...

Interessante post, effettivamente mi ricordo di aver letto da qualche parte (o forse me lo aveva detto qualche consulente) che era meglio avere uno switch ma in effetti non avevo mai fatto una seria riflessione . L'unico test che ho fatto e che posso riportare come testimonianza è quello di scollegare il cavo di interconnessione, in questo caso (su Linux), il clusterware provoca il reboot di una delle due macchine.

Stefano ha detto...

Concettualmente è giusto che sia così. Inoltre Oracle dicendo questo abbraccia ovviamente lo scenario più complicato possibile:
RAC a 2 nodi distanti anche solo 4/5 rack l'uno dall'altro. Come fai? metti un cross? Mmm il cross è meglio lungo 50cm. Ma anche fosse.. intanto l'interconnect deve essere almeno 2gbit (o 4 ..non ricordo) quindi non puoi farlo con un cavo. Inoltre per una questione di massima affidabilità i cavi devono essere collegati a due switch. Non sono se vuoi dare a questo bonding un ulteriore ridondanza di cavi ne dovresti usare 4, in bonding e se passano su switch il tuo switch deve supportare il bonding delle interfacce (cosa che non fa quello da 200 dollari). La cosa migliore, potendo, sarebbe quella di avere una coppia di schede in fibra e di tirare delle fibre, anche in cross, tra le due macchine. Tieni conto che la fibra in cross non ha perdite come spesso succede a un cavo. Dal punto di vista unicamente sistemistico ti dico si a più cavi con switch e no a due cavetti cross. Ne ho appena fatto uno di RAC così 4 gbit di interconnect su rame con due switch in mezzo. Adesso parola al mio DBA sulle performance di questa interconnect (cosa che come saprai molti sottovalutano e lasciano a un misero cavetto a 100mbit o peggio a un trunk su una delle due schede fisiche!)