Trovo che quando le persone progettano l'architettura Oracle RAC, spesso non pensano alla ridondanza N+1 nei loro piani di implementazione. Ci sono due ragioni per implementare Oracle RAC, disponibilità e scalabilità. Ai fini di questa discussione, mi sto concentrando solo sul lato della disponibilità. Se le tue implementazioni RAC sono solo per motivi di scalabilità, questo argomento potrebbe non essere applicabile a te.
Allora, cos'è la ridondanza N+1? In poche parole, se hai bisogno di N unità di qualcosa, per motivi di ridondanza, dovresti avere N + 1 di quell'oggetto. Diamo un'occhiata a un server di database. Deve avere un alimentatore. Questo è un requisito. Senza un alimentatore funzionante, il server non funzionerà affatto. Il numero minimo di alimentatori è 1. Se vogliamo che questo server abbia un alto grado di disponibilità, ci assicureremo che abbia N+1 alimentatori o, in questo caso, alimentatori doppi. Se c'è un solo alimentatore e si guasta, porta con sé il server. Se disponiamo di un alimentatore aggiuntivo, un'unità di riserva, la perdita di un alimentatore non interromperà il server con esso. La ridondanza è un'ottima cosa da avere e un componente essenziale per un'infrastruttura ad alta disponibilità.
Durante la progettazione di un sistema Oracle RAC, il DBA deve determinare quanti nodi sono necessari per supportare le richieste dell'utente finale. Se il DBA determina che sono necessari 4 nodi e questo cluster RAC deve presentare caratteristiche di disponibilità elevata, è fondamentale che il DBA crei un cluster a 5 nodi (4+1). Se le richieste di risorse sono sufficienti per mantenere occupati 4 nodi e un nodo viene perso, i restanti 3 non saranno in grado di tenere il passo con il carico di lavoro. Se il DBA costruisce il sistema RAC tenendo conto della capacità N+1, la perdita di un nodo non sarà rilevabile dagli utenti finali. Se il DBA crea il cluster RAC senza ridondanza N+1, la perdita di un nodo potrebbe essere così terribile per le prestazioni dell'utente finale, che l'intero cluster potrebbe anche essere inattivo. Durante la progettazione delle implementazioni RAC, cerca di ottenere una ridondanza N+1.
Ricordo che due anni fa avevo un cluster RAC che aveva perso un nodo. Nessun problema, avevamo ancora due nodi disponibili. Mentre osservavo le prestazioni dei due nodi rimanenti, sembravano essere piuttosto sopraffatti. Il nostro call center ha iniziato a ricevere reclami. Ho collaborato con altri amministratori del team IT per ripristinare e funzionare il nodo il più velocemente possibile, ma potrebbe non essere sempre così se il motivo dell'interruzione è legato all'hardware e le parti devono essere sostituite. Dopo che il nodo è tornato in servizio, ho monitorato le prestazioni del cluster per settimane. Il nostro utilizzo è cresciuto da quando questo sistema è stato inizialmente progettato. Inizialmente avevamo progettato questo sistema pensando alla ridondanza N+1, ma il nostro utilizzo è cresciuto e N è passato da 2 a 3. Il nostro attuale cluster a 3 nodi non era più N+1 ridondante. Quindi ho lavorato con la direzione per mettere nel budget dell'anno successivo fondi sufficienti per procurarmi un nuovo nodo e assicurarmi che Oracle fosse autorizzato su di esso. Dormo molto meglio la notte sapendo che sono tornato alla ridondanza N+1.
Come molte implementazioni là fuori, il mio sistema RAC non è l'unica funzionalità ad alta disponibilità integrata nella nostra infrastruttura. Questo database RAC è un database primario in standby con Oracle Data Guard. Sono sorpreso quando discuto dei database di standby RAC con altri DBA Oracle di quanti di loro non stanno pensando alla capacità N+1 per il loro standby. Il database fisico in standby è la mia rete di sicurezza nel caso in cui il data center principale non sia disponibile per qualche motivo. Ho visto così tanti DBA Oracle implementare una singola istanza in standby per un primario RAC multinodo. Ahia! Spero che non debbano mai fallire. L'intero carico di lavoro del cluster RAC multinodo avrà enormi difficoltà in quella singola istanza in standby. Quindi, mentre stai progettando le tue implementazioni RAC sia per il primario che per lo standby, considera le tue implicazioni di ridondanza N+1 sulla progettazione dell'architettura.
Dove probabilmente differisco da molte persone è che le mie implementazioni di standby fisico non sono in grado di N+1, ma piuttosto N. Salto il nodo aggiuntivo ridondante per il mio standby fisico. Perché? Puramente dal punto di vista dei costi. Il mio standby fisico è solo una rete di sicurezza. Voglio che funzioni per me il giorno in cui ne ho bisogno. Ma spero di non averne mai bisogno. Lo standby fisico è la mia polizza assicurativa nel caso in cui il rischio diventi realtà. Per me, quel "+1" in più sul sito di standby è un'assicurazione eccessiva. Posso risparmiare sull'hardware fisico e sulle licenze Oracle.
Quindi diciamo che arriva il giorno e io eseguo il failover in standby. Ho perso la mia ridondanza N+1. Ma quali sono le possibilità che perda il data center primario *e* perda uno dei nodi nel mio cluster di standby? Possibilità piuttosto scarse. La probabilità di guasti in due siti contemporaneamente è piuttosto ridotta. A questo punto, il nostro team IT sta valutando perché il nostro data center principale è andato perso e quando molto probabilmente potremo riportare le nostre operazioni in quella struttura. Se il data center principale ha perso tutta la sua potenza e la società di servizi pubblici dice che il servizio sarà ripristinato entro domani, allora ci limiteremo a funzionare nel data center in standby anche se abbiamo solo N nodi per il database RAC lì. Tuttavia, se il data center principale è stato spazzato via da un incendio, ci vorranno molti mesi prima che sia di nuovo operativo. È a questo punto che devo pianificare di portare lo standby fisico fino alla ridondanza N + 1 poiché il nostro tempo che utilizza quello standby come primario sarà un periodo molto più lungo. Quindi ci affrettiamo a ordinare un altro server e lo aggiungiamo al cluster il prima possibile. Quindi progetto il mio database RAC in standby come N, non N+1 con l'obiettivo di aumentarlo a N+1 in breve tempo se determiniamo che utilizzeremo lo standby reale per un periodo di tempo più lungo.
Quindi c'è un altro caso speciale di cui vorrei discutere. È qui che il DBA determina che N=1. Per gli attuali requisiti del carico di lavoro, un nodo è sufficiente. Ma vogliamo avere un'elevata disponibilità, quindi progettiamo un cluster RAC a due nodi per il database primario. Ora abbiamo una ridondanza N+1 integrata nel primario. Dopo il mio ultimo paragrafo, il mio database in standby necessita solo di 1 nodo. L'errore che vedo fare da alcune persone è creare lo standby come database a istanza singola. Finora, la loro logica ha senso. Il primario è N+1 e lo standby è N. Fin qui tutto bene. La mia differenza è che rendo lo standby un cluster RAC a un nodo, non una pura implementazione a istanza singola. Il motivo è per la crescita futura. Ad un certo punto, il DBA potrebbe scoprire che N non è più uguale a 1 al primario. L'utilizzo è cresciuto e N deve essere 2 ora. Il DBA vuole far crescere il primario a 3 nodi (2+1). Questo è facilmente risolvibile con zero tempi di inattività per aggiungere un nuovo nodo al cluster ed estendere il database RAC a quel nuovo nodo. Ma non è così facile fare in standby per rendere lo standby un cluster a 2 nodi se quel nodo esistente non è abilitato per RAC. Se esiste solo uno standby a istanza singola puro, il DBA deve eliminarlo e spostarlo in un cluster a due nodi. Se il DBA ha previsto e ha installato Grid Infrastructure come se lo standby fisico fosse un cluster a nodo singolo, tutto ciò che il DBA deve fare è aggiungere un nuovo nodo, proprio come hanno fatto sul lato primario.
Mentre stai progettando le tue implementazioni RAC, considera di assicurarti di avere capacità N+1 sul primario e almeno N in standby. Se un'azienda determina che lo standby è troppo critico, potrebbe voler implementare N+1 anche in standby. Se il DBA determina che N=1, prendere in considerazione l'idea di rendere lo standby almeno un cluster RAC a nodo singolo.
