I går stødte jeg på denne hvidbog fra Oracle Corp om Oracle RAC Support på tredjepartsskyer. Avisen er absolut et must-read for dem, der ønsker at køre Oracle RAC på AWS, Google eller Azure cloud-udbydere. Det første afsnit var lovende, hvor det stod:
Det lyder godt, men citatet taler om Oracle-databasen og ikke om RAC-muligheden. Jeg fandt det interessant, at avisen bruger meget tid på at tale om AWS og Azure, men aldrig nævner Googles sky.
Her er den nederste linje om Oracles position til at understøtte RAC på andre cloud-tilbud:
Papiret går meget langt for at illustrere, hvordan AWS mudder vandet med hensyn til de lagrings- og netværkskrav, der er nødvendige for at køre RAC i AWS.
Det burde være indlysende, at Oracle forsøger at styre sine kunder væk fra at køre RAC i AWS ved at læse dette papir. Amazon har udsendt information, der fortæller os, hvor nemt det er at køre RAC i AWS. Men efter at have læst denne Oracle-hvidbog, ville jeg være bekymret over, hvor godt AWS-miljøet ville fungere til missionskritiske RAC-udrulninger.
AWS leverer delt lagring til RAC ved at bruge iSCSI-mål på VM'er, som jeg aldrig ville bruge til andet end en testbed. Et problem er redundans på lagerniveau. For at have redundans på lagerniveau:
For det private netværk understøtter AWS ikke multi-casting, et krav til Grid Infrastructure Cluster Interconnect. AWS kommer uden om dette ved at bruge et punkt-til-punkt VPN-netværk ved hjælp af n2n ntop. Men fra ntops egen hjemmeside er der ingen yderligere udvikling på dette i de sidste to år.
Misforstå mig ikke. Jeg tror, at AWS er en god skyløsning til mange forskellige ting. Indrømmet, jeg har ikke kørt RAC på AWS, i hvert fald ikke endnu. Men hvis jeg søgte at flytte min virksomheds RAC-databaseinfrastruktur til skyen, ville jeg seriøst undersøge påstandene i denne Oracle-hvidbog, før jeg forpligtede mig til AWS-løsningen. Den sidste sætning er hele pointen med dette blogindlæg.