Oracle és a virtualizáció

Legalább hatszor találkoztam mostanság az Oracle licenszelési “igényei” és a VMware kapcsolatával. Azért írtam az “igényt”, mert nem szeretnék trágár szavakat használni, de azért az látszik, hogy egy 1990-ben ragadt licenszelési ideológiáról van szó, ami arról szól hogy miképp bonyolítsuk meg az életét a vásárlóiknak, ráadásul úgy hogy még egy rakás pénzt le tudjanak gombolni róla.

Remek dolognak tartom, hogy nincs általános guide, olyan reference design amelyre az Oracle és a VMware is rámondaná, hogy “ez így jó”. A VMware részéről én nem látok problémát, de előbbi esetén nyilvánvaló üzleti oka van a lebegtetésnek, a gumiszabályoknak, melyeket úgy lehet érteni, ahogy éppen az olvasónak kedve tartja. Régen fogalmazott guide-ok vannak, amelyek teljességgel használhatatlanok bármely rendszerben ami ebben az évezredben épült.

De mi a probléma?

Tulajdonképpen ott, hogy learagadtak a hard partitioning-nél. Amit nyilván értelmezni sem lehet VMware alatt – x86 rendszeren – Intel és AMD vonalon. Nincs statisztikám erről, de azokban az esetekben amelyekben érintett voltam, minden esetben Intel Xeon processzoron futó VMware virtualizáció volt és ezen lett volna igény Oracle DB VM-ek futtatására. Nyilván lehet nyomni a Sparc processzorokat az ügyfél torkán lefelé csak éppen nem mindenki akar szigetet építeni, úgy hogy 5 éve arról szól az IT, hogy konszolidáljunk, sztenderdizáljunk és oldjuk fel a silókat.

Szóval teljesen érthető az igény, hogy az igen elterjedt VMware virtualizáción valaki Oracle-t akar futtatni. De a hivatalos dokumentum a kedvencem, mert nincs olyan aminek nincs az alján az a lábléc, hogy oktatási célú dokumentum. Hol van az ami nem az és normálisan használható? link

Soft partitioning

Igen, ez a VMware öröksége, ezért szeretik annyian és ezért haladt előre a világ.

A dokumentum szerint CPU-t növelni “fairly easy” – bármit is jelentsen ez valós komplexitásban – de ha jól értem itt tulajdnonképpen pont az a baj, hogy “fairly” és nem “very cumbersome and daunting”. Explicit nincs meghatározva pontosan mi a “fairly easy”, de elfogadjuk hogy ez az oka annak, hogy a “hard partitioning” a menő.

Hard partitioning

Picit lentebb lapozva kiderül, hogy igazából a majdnem hard partitioning is jó, ami tulajdonképpen olyan mint VMware-ben a CPU affinitás. Csak ez KVM meg Oracle VM Server és nem VMware. Ezért is elfogadott, míg utóbbi nem.

Mi történik azzal aki mégis VMware-en szeretne Oracle-t futtatni?

Ha a tanácsra vagy kíváncsi, akkor nem húzom az időt. Inkább dolgozzon a hidegfúzió kifejlesztésén, arra nagyobb az esély hogy sikerül, mint pecsétes papírt kapni arról, hogy a megépült környezet elfogadott és teljesíti a licenszelési feltételeket.

Az még teljesen világos, hogy ha egy ügyfél vásárol mondjuk 2 darab Intel Xeon processzorral szerelt kiszolgálót, akkor azokban mondjuk az összes magot/fogalaltot licenszeli – 0.5-ös szorszóval. Mivel kokain árban van a licensz ezért inkább az “olcsó” processzor oldalon megy bele a Intel Xeon Platinum 8256. Kevés mag, magas órajel.

Aztán ezt a két kiszolgálót egy központi tárolóhoz köti SAN-on és az ethernet hálózatba is.

Azt a szabályt feloldottuk, hogy licenszelési szempontból nem lesz gond ha “fairly easy” módon adunk még vCPU-t a VM-eknek. Viszont itt bejön az a rész, hogy hogy tudjuk megakadályozni, hogy máshová – nem licenszelt processzorokra menjenek az Oracle VM-ek? Nyilvánvalóan üzemszerűen ez SOHA nem történik meg mert a VMware HA határa – SRM nélkül – a vSphere cluster. De itt arról van szó, hogy nem bízik meg a költő a vásárlójában, ezért a vásárlónak be kell bizonyítani, hogy ha akarja, akkor sem tudja majd megsérteni ilyen módon a gyártó szabályait. (Az logikai bukfenc, hogy amit ember állít be, azt ember vissza is tud állítani, de nem adok tippeket.)

Tehát a következőkent mindenképpen meg kell tenni:

  • közös tárolóról lévén szó, az adott datastore mögötti LUN-okat nem kiexportálni más vSphere hosztoknak, mint a két licenszelt hoszt.
  • közös fabric-ról lévén szó, nem zónázni össze-vissza.
  • közös ethernet-ről lévén szó, dedikált VLAN-ba tenni már a hosztok minden lábától kezdve a dolgokat. vMotion – ha van, ha nincs – külön VLAN-ba, ráadásul a két VMware klaszter között a különböző vMotion VLAN szegmensek ne legyenek egymáshoz routoltak.
  • a switch-eken csak az adott VLAN legyen rajta a trönkön.

Ez már gondolom elég lenne nem? NEM!

Akkor külön vCenter is kell. Oké.

Van cross vCenter vMotion ráadásul már a vSphere-be beépítve. Eddig szkriptelve vagy VMware Fling-ként volt elérhető, de most a VMware integrálta. Tehát klaszterek között tudok mozgatni VM-et ha akarok, ráadásul olyan klaszterek között, amelyeket különböztő vCenter Server kezel.

Verdikt

Szóval a lényeg az az, hogy a használhatóság rovására lehetséges a rendszer további szabdalása de ezek nagyságrendekkel növelik az ügyfelek üzemeltetési feladatait, ráadásul soha az életben nem kapnak olyan papírt, hogy egy rendszer teljesíti az Oracle feltételeit.

Teljesen nyilvánvaló a stratégia:

  • Csináld Sparc-on vagy Oracle virtualizáción.
  • Csináld Oracle Appliance-on (Exadata/ODA stb.)
  • Csináld a felhőben.

Kár hogy nem mindenki akar felhőbe menni, hogy nem mindenki akar Sparc-ot, nem mindenki akar más virtualizációt és nem mindenki akar erre silós appliance-ot. Az is kicsit érdekes, hogy az ügyfél bizonyítsa be jóelőre hogy nem tudja majd megsérteni a feltételeket. Kb olyan mintha az internetszolgáltatódnak kellene bizonyítanod azt, hogy nem tudsz majd torrentezni, túlhasználni a szolgáltatást stb.

Jó lenne egy referencia design, ami up to date és ami x86-on mutat VMware-es megoldást. Elképzelhetetlennek tartom, hogy erre nincs ember/szakértelem/idő az Oracle részéről.