IBM DB2 pureScale på Azure
IBM DB2 pureScale-miljön tillhandahåller ett databaskluster för Azure med hög tillgänglighet och skalbarhet på Linux-operativsystem. Den här artikeln visar en arkitektur för att köra DB2 pureScale på Azure.
Översikt
Företag har länge använt traditionella PLATTFORMAR för hantering av relationsdatabaser (RDBMS) för att tillgodose sina BEHOV av onlinetransaktionsbearbetning (OLTP). Idag migrerar många sina stordatorbaserade databasmiljöer till Azure som ett sätt att utöka kapaciteten, minska kostnaderna och upprätthålla en stadig driftkostnadsstruktur. Migrering är ofta det första steget i moderniseringen av en äldre plattform.
Nyligen bytte en företagskund sin IBM DB2-miljö som körs på z/OS till IBM DB2 pureScale på Azure. Databasklusterlösningen Db2 pureScale ger hög tillgänglighet och skalbarhet på Linux-operativsystem. Kunden körde Db2 som en fristående, uppskalningsinstans på en enda virtuell dator (VM) i ett storskaligt uppskalningssystem i Azure innan db2 pureScale installerades.
Ibm DB2 pureScale på Linux är inte identiskt med den ursprungliga miljön, men har liknande funktioner för hög tillgänglighet och skalbarhet som IBM DB2 för z/OS som körs i en parallell Sysplex-konfiguration på stordatorn. I det här scenariot ansluts klustret via iSCSI till ett delat lagringskluster. Vi använde GlusterFS-filsystemet, ett kostnadsfritt, skalbart öppen källkod distribuerat filsystem som är särskilt optimerat för molnlagring. IBM stöder dock inte längre den här lösningen. För att behålla ditt stöd från IBM måste du använda ett iSCSI-kompatibelt filsystem som stöds. Microsoft erbjuder Lagringsdirigering (S2D) som ett alternativ
I den här artikeln beskrivs arkitekturen som används för den här Azure-migreringen. Kunden använde Red Hat Linux 7.4 för att testa konfigurationen. Den här versionen är tillgänglig från Azure Marketplace. Innan du väljer en Linux-distribution kontrollerar du vilka versioner som stöds för närvarande. Mer information finns i dokumentationen för IBM DB2 pureScale och GlusterFS.
Den här artikeln är en startpunkt för din DB2-implementeringsplan. Dina affärskrav skiljer sig åt, men samma grundläggande mönster gäller. Du kan också använda det här arkitekturmönstret för OLAP-program (Online Analytical Processing) i Azure.
Den här artikeln beskriver inte skillnader och möjliga migreringsuppgifter för att flytta en IBM DB2 för z/OS-databas till IBM DB2 pureScale som körs på Linux. Och den ger inte storleksuppskattningar och arbetsbelastningsanalyser för att flytta från DB2 z/OS till DB2 pureScale.
För att hjälpa dig att välja den bästa DB2 pureScale-arkitekturen för din miljö rekommenderar vi att du helt beräknar storlek och gör en hypotes. I källsystemet bör du överväga DB2 z/OS Parallel Sysplex med datadelningsarkitektur, konfiguration av kopplingsanläggning och användningsstatistik för distribuerad dataanläggning (DDF).
Anteckning
Den här artikeln beskriver en metod för DB2-migrering, men det finns andra. Db2 pureScale kan till exempel också köras i virtualiserade lokala miljöer. IBM stöder DB2 på Microsoft Hyper-V i olika konfigurationer. Mer information finns i DB2 pureScale virtualiseringsarkitektur i IBM Knowledge Center.
Arkitektur
Om du vill ha stöd för hög tillgänglighet och skalbarhet i Azure kan du använda en skalbar, delad dataarkitektur för DB2 pureScale. Kundmigreringen använde följande exempelarkitektur.
Diagrammet visar de logiska lager som behövs för ett DB2 pureScale-kluster. Dessa inkluderar virtuella datorer för en klient, för hantering, för cachelagring, för databasmotorn och för delad lagring.
Förutom databasmotornoderna innehåller diagrammet två noder som används för cachelagring av kluster (CFs). Minst två noder används för själva databasmotorn. En DB2-server som tillhör ett pureScale-kluster kallas för medlem.
Klustret är anslutet via iSCSI till ett delat lagringskluster med tre noder för att tillhandahålla skalbar lagring och hög tillgänglighet. DB2 pureScale installeras på virtuella Azure-datorer som kör Linux.
Den här metoden är en mall som du kan ändra för organisationens storlek och skala. Den baseras på följande:
Två eller flera databasmedlemmar kombineras med minst två CF-noder. Noderna hanterar en global buffertpool (GBP) för delade minne och GLM-tjänster (Global Lock Manager) för att styra delad åtkomst och låsa konkurrens från aktiva medlemmar. En CF-nod fungerar som den primära och den andra som den sekundära CF-noden för redundans. För att undvika en enskild felpunkt i miljön kräver ett DB2 pureScale-kluster minst fyra noder.
Delad lagring med höga prestanda (visas i P30-storlek i diagrammet). Varje nod använder den här lagringen.
Högpresterande nätverk för datamedlemmar och delad lagring.
Beräkningsöverväganden
Den här arkitekturen kör program-, lagrings- och datanivåerna på virtuella Azure-datorer. Distributionskonfigurationsskripten skapar följande:
Ett DB2 pureScale-kluster. Vilken typ av beräkningsresurser du behöver på Azure beror på din konfiguration. I allmänhet kan du använda två metoder:
Använd ett nätverk i HPC-format (databehandling med flera noder med höga prestanda) där små till medelstora instanser har åtkomst till delad lagring. För den här HPC-typen av konfiguration ger Azure minnesoptimerade virtuella datorer i E-serien eller lagringsoptimerade virtuella datorer i L-serien den beräkningskraft som behövs.
Använd färre stora virtuella datorinstanser för datamotorerna. För stora instanser är de största minnesoptimerade virtuella datorerna i M-serien idealiska för tunga minnesinterna arbetsbelastningar. Du kan behöva en dedikerad instans, beroende på storleken på den logiska partitionen (LPAR) som används för att köra DB2.
DB2 CF använder minnesoptimerade virtuella datorer, till exempel E-serien eller L-serien.
Ett delat lagringskluster som använder Standard_DS4_v2 virtuella datorer som kör Linux.
Jumpbox för hantering är en Standard_DS2_v2 virtuell dator som kör Linux. Ett alternativ är Azure Bastion, en tjänst som ger en säker RDP/SSH-upplevelse för alla virtuella datorer i ditt virtuella nätverk.
Klienten är en Standard_DS3_v2 virtuell dator som kör Windows (används för testning).
Valfritt. En vittnesserver. Detta behövs bara med vissa tidigare versioner av Db2 pureScale. I det här exemplet används en Standard_DS3_v2 virtuell dator som kör Linux (används för DB2 pureScale).
Anteckning
Ett DB2 pureScale-kluster kräver minst två DB2-instanser. Det krävs också en cacheinstans och en instans av låshanteraren.
Överväganden för lagring
Precis som Oracle RAC är DB2 pureScale en skalbar I/O-databas med höga prestanda. Vi rekommenderar att du använder det största Azure Premium SSD-alternativet som passar dina behov. Mindre lagringsalternativ kan vara lämpliga för utvecklings- och testmiljöer, medan produktionsmiljöer ofta behöver mer lagringskapacitet. Exempelarkitekturen använder P30 på grund av dess förhållande mellan IOPS och storlek och pris. Oavsett storlek använder du Premium Storage för bästa prestanda.
DB2 pureScale använder en shared-everything-arkitektur, där alla data är tillgängliga från alla klusternoder. Premium Storage måste delas mellan flera instanser, oavsett om det är på begäran eller på dedikerade instanser.
Ett stort DB2 pureScale-kluster kan kräva 200 terabyte (TB) eller mer premium delad lagring, med IOPS på 100 000. DB2 pureScale stöder ett iSCSI-blockgränssnitt som du kan använda i Azure. ISCSI-gränssnittet krävs ett delat lagringskluster som du kan implementera med S2D eller något annat verktyg. Den här typen av lösning skapar en vSAN-enhet (Virtual Storage Area Network) i Azure. DB2 pureScale använder vSAN för att installera det klustrade filsystemet som används för att dela data mellan virtuella datorer.
Nätverksöverväganden
IBM rekommenderar InfiniBand-nätverk för alla medlemmar i ett DB2 pureScale-kluster. DB2 pureScale använder även fjärråtkomst till direkt minne (RDMA), där det är tillgängligt, för CF:erna.
Under installationen skapar du en Azure-resursgrupp som ska innehålla alla virtuella datorer. I allmänhet grupperar du resurser baserat på deras livslängd och vem som ska hantera dem. De virtuella datorerna i den här arkitekturen kräver accelererat nätverk. Det är en Azure-funktion som ger konsekvent, ultralåg nätverksfördröjning via SR-IOV (Single Root I/O Virtualization) till en virtuell dator.
Varje virtuell Azure-dator distribueras till ett virtuellt nätverk som har undernät: main, Gluster FS-klientdelen (gfsfe), Gluster FS-serverdelen (bfsbe), DB2 pureScale (db2be) och DB2 pureScale-klientdelen (db2fe). Installationsskriptet skapar också de primära nätverkskorten på de virtuella datorerna i huvudundernätet.
Använd nätverkssäkerhetsgrupper för att begränsa nätverkstrafiken i det virtuella nätverket och för att isolera undernäten.
I Azure måste DB2 pureScale använda TCP/IP som nätverksanslutning för lagring.