Oracle RAC pe Azure

Aceasta este o intrebare consecventa pe care o primesc des si, desi lucram pentru a obtine un mesaj mai oficial, este un subiect important, deoarece mai multe sarcini de lucru se ridica si trec la Azure si exista absolut un motiv pentru a avea sau nu a avea clustere de aplicatii reale. , (RAC) ca parte a acestora. Cele trei optiuni disponibile pentru RAC pe Azure sunt:

• Flashgrid folosind imagini Azure VM in IaaS
• VMWare CloudSimple pe Azure Bare Metal
• Discuri partajate pe Azure, (NOU !!)

Scopul acestei postari este de a depasi ideea ca o ridicare si o schimbare ar trebui sa fie intotdeauna o miscare 1: 1. Este important atunci cand va deplasati in cloud sa utilizati instrumentele potrivite, nu doar instrumentele pe care le-ati folosit intotdeauna, ceea ce reprezinta o lectie foarte importanta atunci cand vine vorba de Oracle Real Application Cluster (RAC).

Primul lucru de remarcat este ca niciuna dintre solutiile RAC de mai sus pentru Azure nu este acceptata de Oracle. Primele doua necesita asistenta prin intermediul furnizorilor terti si al treilea fiind in previzualizare privata. Deci, sa incepem sa discutam de ce arhitectura pentru cloud poate fi foarte diferita de arhitectura on-prem prin dispersarea cu unele mituri.

RAC nu este de mare disponibilitate

Aceasta poate fi o opinie nepopulara a multora din lumea Oracle, dar RAC nu indeplineste multe dintre cerintele pentru HA. Daca o solutie nu indeplineste nici macar una, chiar aveti o solutie?

• RAC are patch-uri rulante care elimina o parte din timpul de nefunctionare pentru patch-uri, dar nu se asigura ca TOATE patch-urile sunt livrate in acest mod. Deoarece patch-urile sunt construite de diferite echipe la Oracle sau nu au avut suficient timp pentru a construi un patch rulant pentru RAC, vor exista perioade de nefunctionare.
• Unul dintre cele mai mari defecte din RAC pentru indeplinirea cerintelor HA este in mod implicit ca toate nodurile se afla intr-un singur centru de date, cu exceptia cazului in care a fost implementat un cluster de distanta extinsa. 
• RAC poseda o singura baza de date care interactioneaza cu mai multe noduri, spre deosebire de Grupurile de disponibilitate Always-on, care are mai multe baze de date. 

RAC a fost proiectat pentru scalabilitate si face acest lucru foarte bine, dar implementarea implicita va avea ca rezultat, daca exista un esec al centrului de date, pierderea tuturor nodurilor si a bazei de date, cerinte HA neindeplinite.

• O alta problema consecventa este ca majoritatea aplicatiilor inca conectate la baze de date RAC nu sunt „constiente de RAC”. Acest lucru duce la intreruperi atunci cand are loc un failover sau un patch, ceea ce reprezinta o alta provocare pentru garantia HA.
• Mediile RAC au o serie de componente suplimentare care adauga complexitate mediului care poate crea probleme care provoaca esecuri, in timpul reluarii si in afara acestuia. 

De multe ori am analizat un raport AWR si am crezut ca cel mai bun lucru pentru un mediu a fost sa-l UnRAC. Proiectarea codului si a bazei de date pur si simplu nu a fost conceputa pentru a rula eficient sau eficient pe RAC, rezultand in asteptari mari ale memoriei cache etc.

RAC, in opinia multor experti, este pentru scalabilitate, iar pentru mine scalabilitatea este la fel de probabila pentru crestere pe cat este necesara din cauza resurselor sau experientei lipsite de gestionare si construire de solutii care sa raspunda nevoilor. 

Doar un proiect din 100 cu care am lucrat la Microsoft a avut o nevoie reala de RAC si da, lucrez mai ales cu sarcini de lucru multi-terabyte, deci nu ar trebui sa se presupuna ca erau doar baze de date mici.

Implementarea RAC in Azure

Pentru ca RAC sa functioneze astazi pe Azure, (fara a lua in considerare noua previzualizare privata) necesita un serviciu terta parte care functioneaza ca centru de comunicatii pentru clusterul software.  

Flashgrid functioneaza cu IaaS VM Images si este acceptat prin Flashgrid daca apar probleme. O diagrama de arhitectura de nivel inalt arata dupa cum urmeaza:

VMWare CloudSimple este construit peste baremetal, dar arhitectura reala arata similara atunci cand este diagramata dupa cum urmeaza:

Dupa cum sa mentionat mai devreme, niciun suport de la Oracle pentru aceasta solutie si clientul ar trebui sa treaca prin VMWare pentru asistenta. VMWare are o relatie stransa cu Oracle si putem spera ca acest lucru se va schimba in curand.

Daca clientul ruleaza ceva mai mult decat un mediu Oracle RAC simplu – au implementat un model de date complex, un cod complex sau un strat de aplicatie sau nu indeplinesc niciuna dintre cerintele pentru scalarea cu RAC, voi incerca sa convingeti-i sa faca arhitect pentru cloud.

Arhitectura pentru Cloud

Un centru de date Azure este construit pe o infrastructura distribuita la nivel global, care contine numeroase straturi de redundanta si o retea interconectata rezistenta. Acest lucru este cu mult superior unui centru de date on-prem deoarece trebuie sa fie. Georegiunile sunt tolerante la erori in caz de esec complet al centrului de date regional, ceea ce inseamna ca modul in care arhitectam pentru cloud este adesea diferit de modul in care arhitectam in mod premat.

Principiul Keep It Simple Silly, (KISS) vine la indemana aici, intrucat complexitatea are impact doar asupra costurilor de gestionare, implementare si licentiere pentru proiectele noastre de lift si schimb Azure. Cea mai buna practica pentru Oracle, care este, de asemenea, mentionata in documente:

1. Odata cu scalabilitatea masinilor virtuale cloud Azure, baza de date de implementat ar trebui sa fie o singura instanta baza de date Oracle (sau produsul acceptat de Oracle).
2. Pentru a ajuta la scara, luati in considerare utilizarea Oracle Active Dataguard pentru a utiliza 1, 2 sau mai multe baze de date secundare pentru raportare, alimentarea ELT / ETL sau backup-uri.
3. Daca implementati un Dataguard secundar intr-o alta regiune, luati in considerare utilizarea unei instante Oracle Far Sync pentru a va ajuta sa le mentineti la zi.
4. Folositi, de asemenea, reluare automata configurata Oracle Active Dataguard in scopuri DR, desemnand pasi secventiali de reluare dupa necesitati.
5. Utilizati Azure Site Recovery, (ASR) pentru a face instantanee ale Oracle VM (s) si pentru a crea noi copii care pot fi utilizate pentru a efectua rapid o recuperare finala intr-o stare consistenta fata de clonare sau recuperare dintr-o copie de rezerva completa.
6. Utilizati RMAN pentru a face copii de rezerva si pentru a salva copii de siguranta in spatiul de stocare Azure Blob.

Diagrama de nivel inalt Oracle on Azure

Daca baza de date are nevoie de mai multe resurse, este usor sa extindeti VM (urile) dupa cum este necesar. Imi petrec o cantitate mai mare de timp calculand IO pentru a ma asigura ca IO-ul discului are loc sa creasca in timp. Acum, discul este separat de VM-urile si este important pentru Oracle – as dori sa-l salvez pentru o alta postare, asa ca va voi lasa cu urmatoarele:

• Discutati despre ce este cloudul Azure, orice nor si cum este arhitecturat diferit decat un centru de date on-prem.
• Intrebati clientul de ce utilizeaza RAC si apoi intrebati-l daca mediul lor RAC depaseste nevoile HA sau scalabilitatea RAC.  
• Luati in considerare modul in care Oracle Dataguard, fie pasiv, fie activ, poate juca un rol intr-o poveste puternica de HA si DR pentru client. Produsul este incredibil de robust si este superior nevoilor cloud pentru bazele de date Oracle ale clientului. Dataguard este mai mic decat RAC, poate economisi clientului si o suma considerabila de bani din costurile de licentiere.

Abilitati RAC

Este bine ca DBA ar putea dori sa-si pastreze abilitatile RAC la zi, intelegandu-le, am 2 decenii sub DBA. Lucrul este ca exista atat de multe instrumente si produse noi, precum Azure CLI, servicii Azure si automatizare cu DevOps de invatat, exista o multime de noi abilitati pe care le vor dobandi, care le vor face mai valoroase decat simpla cunoastere a Oracle RAC.