Oracle RAC 11.2 on Windows 2008 R2 – Part I

Tuesday, 31.07.2012 – Noctua4u

DO NOT… IN PRODUCTION!


Obzirom da su mi se više puta obraćali, sa raznih strana sveta, za mišljenje i iskustvo u radu Oracle RAC-a 11.2.0.2 pod Windows 2008 R2 evo sistematizovanih činjenica.

Zapravo, ovo je kratki info i instrukcije o upotrebi RAC-a u produkciji. Sve što je napisano je plod ličnog iskustva i uopšte ne mora da znači da bi se ponovo reprodukovalo ako bi neko ponovo pokušao to isto. Ovo je samo skup činjenica o kojima bi trebalo voditi računa ukoliko neko planira uvođenje ovakvog sistema u produkciju (pod sličnim okruženjem).

Dakle,

Prirpeme za prelazak na RAC su trajale duže vreme. Isprobavali smo svašta nešto i pokušavali razne scenarije. Na kraju smo skupili svo znanje, informacije i hrabrost i krenuli u migraciju. Naravno, kao i kod svakog dobrog Marfijevog zakona, ono što nismo nikada naišli u testiranju, pojavilo se odmah po pokretanju produkcije!

HW i SW

Hardver kojim smo raspolagali u trenutku zvanične “produkcije” je, u to vreme (januar 2011), bio na zavidnom nivou. Bez zalaženja u tehničke detalje, radi se o dva identična servera (HP ProLiant familija) sa 4 procesora od po 4 jezgra. Memorija je po 52GB po nodu. Prostora na storage-u više nego dovoljno.

Problemi pre

Testiranje je obavljeno pod Windows 2008 R2 i Real Application Cluster Oracle 11.1.0.1.  (very last updates u tom momentu i za OS i za DB) – U daljem tekstu Win i Test RAC.
Instalacija je pokušana školski, na osnovu uputstva sa Support-a (u daljem tekstu MetaLink) . Međutim…

Instalacija puca, tj. nije moguće instalirati ClusterWare jer postoji BUG u instalaciji!

Zapravo, ne bug, već je ispusten jedan ključan korak u svim uputstvima, u setovanju Win-a koji izaziva krah i prekid rada installera, pa samim tim i propast celokupne instalacije.

Naravno, to nigde nije dokumentovano niti je, u tom momentu, bilo prijavljeno na Metalinku. Obzirom na to da smo uredno registrovani, legalizovani, plaćamo pozamašne svote i da su ubeđivanja oko naše migracije na RAC bili dugi i obilni, kolege iz Oracle Serbia su zalegli i pronašli rešenje za mali problemčić!
Uz njihove insajderske informacije, uspela je instalacija. (Inače, instalacija ko instalacija, ništa vredno pomena…)

OCFS problemi sa priviledijama

Dalje, naš scenario je bio, obzirom da imamo nešto malo pisanja iz DB po disku (neki nestandardni exporti u fajl i slično), da “između” dva noda postoji jedan shared disk sa nekim mrežnim fajl sistemom. Normalno i prirodno, odluka je pala na OCFS. Instalacija, formatiranje i podešavanje tog “zajedničkog” diska nije problem. Međutim…
Prilikom testiranja konstatujemo jedan Win limit!

Naime, Win NE MOŽE da barata ACL listama na OCFS-u!!!

U prevodu na govorni srpski: Win nema podršku za prava pristupa fajlovima na OCFS prilikom share nekog direktorijuma!
Dakle, situacija je sledeća: ili su svi korisnici mrežni administratori i mogu po defaultu sve ili nema pristupa uopšte.

Hvala i doviđenja!

Obzirom da prvi scenario nije bio prihvatljiv u našem okruženju, a drugi nije zadovoljavao potrebe, rešavamo problem metodom zakrpe: Problematične aplikacije se konektuju samo na jedan nod (!) na kome je fizički zakačen HDD koji je NTFS formatiran. Normalno, da ne bi bilo čudnih alerta i grešaka u samom RACu, morali smo da zakačimo i za drugi nod jedan disk… tek da glumi prisustvo shared diska…
No, dobro… znam… glupo… ali tako je moralo…
U međuvremenu, prerađene su adekvatne aplikacije tako da umeju da “izbace” fajl na neku mrežnu lokaciju, i… vratili smo se prvobitnom scenariju. Može se reći problem rešen.

Veoma bitno za dalju priču je i činjenica da nismo imali redundantne serverske mrežne kartice, u trenutku kretanja u produkciju. (Za one koji nisu imali prilike da vide iste, razlikuju se od “običnih”… ako ništa drugo ono po tome što imaju mogućnost da se ubodu dva mrežna kabla i da se… da ne dužim, nije bitno za priču. Bitno je da su različite i da ih nismo imali u dovoljnom broju u tom trenutku).

UPGRADE RACa NE RADI pod Win-om!

Kada je trebalo ući u konačnu produkciju, rešio sam da probam nove mehanizme o kojima je Oracle toliko pričao. Naravno, sve je teklo uz pomoć “Master Note For Oracle Database Upgrades and Migrations” MOS ID 1152016.1. Rešio sam da probam “out of place upgrade” sa 11.1 na 11.2. (Btw, sada je upgrade zapravo klasična instalacija). Međutim…

Iako sam pripremio i uradio sve kako piše po njihovim dokumentima, javila se… GREŠKA! Update Clusterware-a nije prošao. Do DB nisam ni stigao…
Žao mi je što nisam sačuvao tadašnje logove i greške koje sam dobijao, šta da se radi…
Probao ja i rollback (uputstvo tipa: šta ako pođe nešto naopako prilikom update-a)… za divno čudo to radi… tj… hmmm… Ne znam koliko kvalitetno radi jer nakon toga nisam pokušavao tesiranje a nije bilo nikakvih poruka o greškama…

Sledeće je bilo, kad sam već zabrljao, da probam “inplace update”.
Naravno da… to pa tek nije htelo da radi!

Problemi posle

Normalno, obzirom da je sve bilo pripremljeno, sledio je format c:/ pa krenimo iznova na verziju 11.2.0.2 (u daljem tekstu RAC) koja je u međuvremenu zašla i “kao” postala stabilna.

Instalacija ovog puta prolazi bez problema jer, poučen iskustvom koristim “trik” iz prethodne priče. Migraciju obavljamo lagano jednog vikenda, januara 2011 godne.

RAC is up and ready.

Normalno, dan posle, počinjem da primećujem neke stvari koje na testiranju nisu bile uočene.

VIRTUAL CIRCUIT WAIT – Network event

Kada se konektuje veći broj korisnika na DB, pojavi se dramatično trošenje resursa u vidu network event -> virtual circuit wait. Ali baš dramatično. Nešto tipa, od fizičkih 16 jezgara, “trošimo” na taj event 120 jezgara!
Prevedeno na govorni srpski, problema nema, sve radi, samo što je periodično usporeno do bola.

Pokušavam razne stvari, analize koda, aplikacije, setovanja, i svega ostalog što bi moglo uroditi plodom, međutim… ništa pametno. Metalink je beskoristan po tom pitanju, u tom trenutku… odgovori i dokumenti su tipa: “To svašta nešto može da znači… kontaktiraj support”… Ajde?
Na rešenje nailazim sasvim slučajno, posle nekoliko meseci kopanja i rešavanja drugih problema… na nekom totalno nebitnom (po oracle) forumu gde tražim rešenje za problem Win update-a.

Naime, radi se o registrovanom Oracle Bug-u za koji su napisali da je razrešen u verziji 11.2 za Win!!!
Bug se ogleda u tome da se problemi javljaju ukoliko se na RAC-u koriste shared konekcije.
Rešenje je samo u tome da se koristi dedicated konekcija!!!!

Plaćam danak svom neiskustvu u radu sa RAC-om.
Takođe, plaćam danak svom, naivnom verovanju da Oracle kad napiše da je rešeno, onda je rešeno…
Moja greška, šta da se radi…

Sada gledam baš na Metalinku, postoji gomila sličnih bugova (U međuvremenu se 11.2 RAC odomaćio pa se javlja i kod drugih sličan problem… Najpribližnije je sledeći, tekući bug 10264920).

WIN Update

HUGE PROBLEM, što bi rekli na maternjem engleskom.
Naime, podučen iskustvom automackog update-a Windows-a (kada je preko noći došao i primenjen je update gde se menja ODBC Connect String), zabranio sam automatiku.
Dragi serveri, obavestite me o update-u, pa da vidimo šta sa tim… Međutim…
Iako su ljudi iz MSofta bili ubedljivi i uverljivi u objašnjavanju da broj pristiglih update-ova (a neinstaliranih) nema nikakav uticaj na rad, ja sam stekao neki subjektivni osećaj da to nije baš tako. Nisam baš stručnjak (ali Stručnjak) za Win pa zato i kažem subjektivni osećaj. Naime, čim pristigne veći broj update-ova za Win, i ne instaliraju se nekoliko nedelja, server počne da se “ponaša”.

Ja se stvarno izvinjavam svima na ovom maglovitom opisu, ali ne mogu detaljnije… jer nikad nije bilo isto i indikativno je bilo da nakon insalacije update-ova problema više nema…

A problemi su bili šarenoliki: usporenje odziva OS-a bez nekih razloga (event logovi OK, monitoring OK) ali se jednostavno uspori; ponekad se listeneri obaraju “sami od sebe” takođe, bez ikakvih vidljivih i razumljivih razloga iz logova; ponekad je pristup, onim ranije pomenutim, diskovima usporen do neupotrebljivosti; ponekad RMAN pravi backup relativno male baze i po 8-9 sati, ponekad…
Sve u svemu, evidentno je bilo da se problemi javljaju samo kada postoji veći broj neinstaliranih Win update-ova…

Dalje,

Sam proces instalacije Win update-a bi, ako je suditi po svim knjigama i uputsvima koje sam pročitao, trebao da teče na sledeći način: instaliraš na jednom nodu update, restart noda ako treba, pa to isto na svim sledećim nodovima… Aliii…
Instalacija ponekog update-a ne prolazi jer DB koristi neki sistemski dll u tom trenutku… Tako da… update nije prošao i vraćamo se na početak ovog pasusa…
Best practice bi bio ugasi RAC, instaliraj update, restartuj nodove ako treba ili digni RAC. Praktično, a?
Doduše, ovo nije slučaj čest, ali… bilo ih je par komada koji su me sludeli…

I da završim ovaj pasus, i ljudi iz Oracle-a i ljudi iz MSofta su dali preporuke da se Win update-uje do… nisam siguran kako se to u Win svetu zove, ali nazvaćemo ga Major Realize Number.
Npr. imaš Win 2008 R1… update radiš dokle god taj Win ne postaje R2 (Nekad se to zvalo, valjda, ServicePak)!!!
Ili gledano iz Oracle sveta, Win update radiš od drugog broja nadalje (11.1.X.Y gde se X i Y menjaju. Ni u kom slučaju ne radi update na 11.2).

My finall solution was: Turn off Update for Win. On every node. Full stop.

Glupo? Nepraktično? Netaktično?
Slažem se…
Otvoren sam za svaki predlog… da probamo!

Obzirom da ovde ima još što šta da se kaže, nastavak sutra.

Post a Comment