Igår kom jag över detta vitbok från Oracle Corp om Oracle RAC-stöd på tredjepartsmoln. Tidningen är definitivt ett måste att läsa för den som vill köra Oracle RAC på AWS, Google eller Azure molnleverantörer. Första stycket var lovande där det stod:
Det här låter bra, men citatet talar om Oracle-databasen och inte om RAC-alternativet. Jag tyckte att det var intressant att tidningen ägnar mycket tid åt att prata om AWS och Azure men aldrig nämner Googles moln.
Här är slutsatsen om Oracles position för att stödja RAC på andra molnerbjudanden:
Uppsatsen går långt för att illustrera hur AWS lerar vattnet med avseende på lagrings- och nätverkskraven som krävs för att köra RAC i AWS.
Det borde vara uppenbart att Oracle försöker styra bort sina kunder från att köra RAC i AWS genom att läsa detta dokument. Amazon har lagt ut information som låter oss veta hur enkelt det är att köra RAC i AWS. Men efter att ha läst den här Oracle-vitboken skulle jag ha en viss oro över hur väl AWS-miljön skulle fungera för uppdragskritiska RAC-distributioner.
AWS tillhandahåller delad lagring för RAC genom att använda iSCSI-mål på virtuella datorer, som jag aldrig skulle använda för något annat än en testbädd. Ett problem är redundans på lagringsnivå. För att ha redundans på lagringsnivå:
För det privata nätverket stöder AWS inte multicasting, ett krav för Grid Infrastructure Cluster Interconnect. AWS kommer runt detta genom att använda ett punkt-till-punkt VPN-nätverk med n2n ntop. Men från ntops egen webbplats har det inte skett någon vidare utveckling på detta de senaste två åren.
Missförstå mig inte. Jag tror att AWS är en bra molnlösning för många olika saker. Jag har visserligen inte kört RAC på AWS, åtminstone inte än. Men om jag var ute efter att flytta mitt företags RAC-databasinfrastruktur till molnet, skulle jag seriöst undersöka påståendena i denna Oracle-vitbok innan jag ansluter mig till AWS-lösningen. Den sista meningen är hela poängen med det här blogginlägget.