Hur man distribuerar SAP HANA: vi analyserar olika metoder

SAP HANA är ett populärt DBMS i minnet som inkluderar lagringstjänster (Data Warehouse) och analys, inbyggd mellanprogram, en applikationsserver och en plattform för att konfigurera eller utveckla nya verktyg. Genom att eliminera latensen för traditionella DBMS med SAP HANA kan du avsevärt öka systemets prestanda, transaktionsbearbetning (OLTP) och affärsinformation (OLAP).

Hur man distribuerar SAP HANA: vi analyserar olika metoder

Du kan distribuera SAP HANA i Appliance- och TDI-lägen (om vi pratar om produktionsmiljöer). För varje alternativ har tillverkaren sina egna krav. I det här inlägget kommer vi att prata om fördelarna och nackdelarna med olika alternativ, samt, för tydlighetens skull, om våra verkliga projekt med SAP HANA.

SAP HANA består av 3 huvudkomponenter - värd, instans och system.

Värd är en server eller operativ miljö för att köra SAP HANA DBMS. Dess nödvändiga komponenter är CPU, RAM, lagring, nätverk och OS. Värden tillhandahåller länkar till installationskataloger, data, loggar eller direkt till lagringssystemet. Samtidigt behöver inte lagringssystemet för installation av SAP HANA finnas på värden. Om systemet har flera värdar behöver du antingen delad lagring eller en som är tillgänglig på begäran från alla värdar.

Exempel — en uppsättning SAP HANA-systemkomponenter installerade på en värd. Huvudkomponenterna är indexservern och namnservern. Den första, som också kallas "arbetsservern", behandlar förfrågningar, hanterar aktuella datalager och databasmotorer. Name Server lagrar information om topologin för SAP HANA-installationen - var komponenterna körs och vilken data som finns på servern.

System – detta är en eller flera instanser med samma nummer. I huvudsak är detta ett separat element som kan aktiveras, inaktiveras eller kopieras (säkerhetskopieras). Datan distribueras i minnet på de olika servrarna som utgör SAP HANA-systemet.

Hur man distribuerar SAP HANA: vi analyserar olika metoder
Systemet kan konfigureras som singelvärd (en instans på en värd) eller multivärd, distribuerat (flera SAP HANA-instanser är fördelade över flera värdar, med en instans per värd). I flera värdsystem måste varje instans ha samma nummer. Ett SAP HANA-system identifieras av ett system-ID (SID), ett unikt nummer som består av tre alfanumeriska tecken.

SAP HANA virtualisering

En av de viktigaste begränsningarna för SAP HANA är stödet för endast ett system - en instans med ett unikt server-SID. För att använda hårdvara mer effektivt eller minska antalet servrar i ett datacenter kan du använda virtualisering. På så sätt kan andra landskap samexistera på samma server med system som har lägre krav (icke-produktiva system). För en standby-HA/DR-server kan virtualisering förbättra hastigheten för att växla mellan produktiva och icke-produktiva virtuella maskiner.

SAP HANA inkluderar stöd för VMWare ESX hypervisor. Detta innebär att olika SAP HANA-system - SAP HANA-installationer med olika SID-nummer - kan samexistera på en enda värd (gemensam fysisk server) i olika virtuella maskiner. Varje virtuell maskin måste köras på ett operativsystem som stöds.

För produktionsmiljöer har SAP HANA-virtualisering allvarliga begränsningar:

  • Skalning utskalning stöds inte - virtualisering kan endast användas med Scale-Up-system, vare sig det är BwoH/DM/SoH eller "ren" SoH;
  • virtualisering måste utföras inom de regler som fastställts för Appliance eller TDI-enheter;
  • General Availability (GA) kan bara ha en virtuell maskin – företag som vill använda virtualisering med HANA-produktionsmiljöer måste delta i programmet Controlled Availability med SAP.

I icke-produktiva miljöer där dessa begränsningar inte finns, kan virtualisering användas för att optimera hårdvaruanvändningen.

SAP HANA topologier

Låt oss gå vidare till att distribuera SAP HANA. Två topologier definieras här.

  • Uppskalning – en stor server. När HANA-basen växer växer själva servern: antalet processorer och mängden minne ökar. I lösningar med High Availability (HA) och Disaster Recovery (DR) måste backup- eller feltoleranta servrar matcha egenskaperna hos produktiva servrar.
  • Skala ut – hela volymen av SAP HANA-systemet är fördelat på flera identiska servrar. Masterservern innehåller information för indexservern och namnservern. Slavservrar innehåller inte denna data - förutom servern, som tar över Masters funktioner i händelse av fel på huvudservern. Indexservrar hanterar datasegmenten som är tilldelade dem och svarar även på frågor. Namnservrar är medvetna om hur data fördelas mellan produktionsservrar. Om HANA växer läggs en annan nod helt enkelt till i den aktuella serverkonfigurationen. I denna topologi räcker det med en backupnod för att säkerställa säkerheten för hela servern.

Hur man distribuerar SAP HANA: vi analyserar olika metoder

SAP-hårdvarukrav

SAP har obligatoriska hårdvarukrav för HANA. De relaterar till produktiva miljöer - för icke-prod räcker det med minimala egenskaper. Så här är kraven för produktionsmiljöer:

  • CPU Intel Xeon v5 (SkyLake) / 8880/90/94 v4 (Broadwell)
  • från 128 GB RAM för BW-applikationer med 2 processorer, 256 GB med 4+ processorer;

Implementera SAP HANA i Appliance- och TDI-lägen

Låt oss nu gå vidare till att öva och prata om hur man implementerar SAP HANA i Appliance- och TDI-lägen. För detta använder vi våra SAP HANA-plattformar baserade på BullSequana S- och Bullion S-servrarna, som är certifierade av SAP för att fungera i dessa lägen.

Lite information om produkterna. BullSequana S baserad på Intel Xeon Scalable inkluderar olika modeller, upp till 32 processorer i en enda server. Servern är byggd med en modulär design som ger skalbarhet upp till 32 CPU:er och samma antal GPU:er. RAM – från 64 GB till 48 TB. BullSequana S-funktioner inkluderar företags-AI-stöd för förbättrad prestanda, accelererad dataanalys, förbättrad in-memory-beräkning och modernisering med virtualisering och molnteknik.

Bullion S kommer med Intel Xeon E7 v4 familjeprocessorer. Maximalt antal processorer är 16. RAM är skalbart från 128 GB till 24 TB. Ett stort antal RAS-funktioner ger hög tillgänglighet för verksamhetskritiska infrastrukturer som SAP HANA. Bullion S är lämplig för massdatacenterkonsolidering, körning av In-Memory-applikationer, migrering av stordatorer eller äldre system.

SAP HANA Appliance

Appliance är en förkonfigurerad lösning som inkluderar en server, lagringssystem och ett mjukvarupaket för nyckelfärdig implementering, med en centraliserad supporttjänst och en överenskommen prestandanivå. Här kommer HANA som förkonfigurerad hårdvara och mjukvara, helt integrerad och certifierad. Enheten i Appliance-läge är klar för installation i datacentret, och operativsystemet, SAP HANA och (om nödvändigt) ytterligare en VMWare-instans är redan konfigurerade och installerade.

SAP-certifiering bestämmer den garanterade prestandanivån, såväl som CPU-modellen, mängden RAM och lagringsutrymme. När den väl är certifierad kan konfigurationen inte ändras utan att garantin ogiltigförklaras. För att skala HANA-plattformen erbjuder SAP tre alternativ.

  • Uppskalning BWoH/DM/SoH – vertikal skalning, som är lämplig för enstaka system (ett SID). Apparater växer med 256/384 GB från och med SAP HANA SPS 11. Detta förhållande visar den maximala kapaciteten som stöds av en CPU och är gemensam för hela listan över certifierade apparater. Appliance BWoH/DM/SoH med vertikal skalning är idealisk för BW på HANA (BWoH), Data Mart (DM) och SAP Suite på HANA (SoH) applikationer.
  • Skala upp SoH – Det här är en lättviktsversion av den tidigare modellen, med färre begränsningar på mängden RAM. Detta är fortfarande en vertikalt skalbar server, men den maximala mängden RAM för 2 processorer är redan 1536 GB (upp till version SPS11) och 3 TB (SPS12+). Endast lämplig för SoH.
  • Skala ut – Det här är ett horisontellt skalbart alternativ, ett system som stöder konfigurationer med flera servrar. Horisontell skalning är optimal för BW och, med vissa begränsningar, för SoH.

I BullSequana S- och Bullion S-servrarna är vertikal skalning i fokus eftersom den har färre driftsbegränsningar och kräver mindre administration. För Appliance-läge finns det ett stort utbud av olika enheter.

Hur man distribuerar SAP HANA: vi analyserar olika metoder
BullSequana S-lösningar för SAP HANA i Appliance-läge

Hur man distribuerar SAP HANA: vi analyserar olika metoder
*Tillval E7-8890/94v4
Bullion S-lösningar för SAP HANA i Appliance-läge

Alla Bull-lösningar i Appliance-läge från SAP HANA SPS 12 är certifierade. Utrustningen är installerad i ett standard 19-tums 42U-rack, med två nätaggregat - interna PDU:er. Följande servrar har SAP-certifiering:

  • BullSequana S med Intel Xeon Skylake 8176, 8176M, 8180, 8180M (processorer med bokstaven "M" stöder 128 GB minnesmoduler). När det gäller pris-kvalitetsförhållande ser alternativen med Intel 8176 bäst ut
  • Bullion S med Intel Xeon E7-8880 v4, 8890 och 8894.

Lagringssystemet ansluter direkt till servern via FC-portar, så SAN-switchar behövs inte här. De kan vara användbara för att komma åt system anslutna till ett LAN eller SAN.

Här är ett exempel på konfigurationen av EMC Unity 450F-lagringssystem i vår installation:

  • Höjd: 5U (DPE 3U (25×2,5″ HDD/SSD) + DAE 2U (25×2,5″ HDD/SSD))
  • Styrenheter: 2
  • Diskar: från 6 till 250 SAS SSD, från 600 GB till 15.36 TB vardera
  • RAID: nivå 5 (8+1), 4 RAID-grupper
  • Gränssnitt: 4 FC per styrenhet, 8 eller 16 Gbit/s
  • Programvara: Unisphere Block Suite

Appliance är ett pålitligt distributionsalternativ, men det har en stor nackdel: liten frihet att konfigurera hårdvara. Dessutom kan detta alternativ kräva förändringar i IT-avdelningens processer.

SAP HANA TDI

Ett alternativ till Appliance är TDI-läget (Tailored Data Center Integration), där du kan välja specifika tillverkare och infrastrukturkomponenter beroende på kundens önskemål – med hänsyn till utförda uppgifter och arbetsbelastning. Till exempel kan ett SAN återanvändas i ett datacenter, med vissa diskar dedikerade till en HANA-installation.

Jämfört med Appliance ger TDI-läget användaren mycket större frihet att uppfylla kraven. Detta förenklar integreringen av HANA i datacentret avsevärt - du kan bygga din egen skräddarsydda infrastruktur. Variera till exempel typen och antalet processorer beroende på belastningen.

Hur man distribuerar SAP HANA: vi analyserar olika metoder
För kapacitetsberäkningar rekommenderar vi att du använder SAP Quick Sizer, ett enkelt verktyg som tillhandahåller CPU- och minneskrav för olika arbetsbelastningar i SAP HANA. Du kan sedan kontakta SAP Active Global Support för att planera ditt IT-landskap. Efter detta omvandlar SAP HANA-hårdvarupartnern beräkningsresultaten till olika möjliga systemkonfigurationer - både på top-end och på enklare hårdvara. I TDI-läge för servrar det är acceptabelt att använda Intel E7-processorer, inklusive Intel Broadwell E7 och Skylake-SP (Platinum, Gold, Silver med 8 eller fler kärnor per processor), samt IBM Power8/ 9.

Servrar levereras utan lagringssystem, switchar och rack, men hårdvarukraven förblir desamma som i Appliance-läge - samma enstaka noder, lösningar med vertikal eller horisontell skalning. SAP kräver det endast certifierade servrar, lagringssystem och switchar användes, men detta är inte skrämmande - de flesta tillverkare har nästan all utrustning certifierad.

Prestandatestning bör göras med HWCCT-tester (Hardware Configuration Check Tool)., som låter dig kontrollera överensstämmelse med vissa SAP KPI:er. Och det finns ett icke-hårdvarukrav: HANA, OS och hypervisor (tillval) måste installeras av SAP-certifierade specialister. Endast system som uppfyller alla listade regler kan få SAP-prestandastöd.

BullSequana S-serien med servrar i TDI-läge liknar linjen i Appliance-läge, men utan lagringssystem, switchar och rack. Du kan installera vilket lagringssystem som helst från listan över certifierade SAP-system - VNX, XtremIO, NetApp och andra. Till exempel, om VNX5400 uppfyller SAP HANA-prestandakraven kan du ansluta Dell EMC Unity 450F-lagring som en del av TDI-konfigurationen. Vid behov installeras FC-adaptrar (1 eller 10 Gbit/s), samt Ethernet-switchar.

Nu, så att du tydligare kan föreställa dig de beskrivna lägena, kommer vi att berätta om flera av våra verkliga fall.

Apparat + TDI: HANA för webbutik

Webbutiken Mall.cz, en del av Mall Group, grundades 2000. Det har filialer i Tjeckien, Slovakien, Polen, Ungern, Slovenien, Kroatien och Rumänien. Detta är den största onlinebutiken i landet, som säljer upp till 75 tusen produkter per dag, dess intäkter i slutet av 2017 uppgick till cirka 280 miljoner euro.

Uppdatering av datacenterinfrastrukturen krävdes i samband med migreringen till SAP HANA. Den uppskattade storleken var 2x6 TB för prod-miljöer och 6 TB för test/dev-miljöer. Samtidigt krävdes en lösning med katastrofåterställning för en produktiv SAP HANA-miljö i ett aktivt aktivt kluster.

Vid tidpunkten för anbudsannonseringen hade kunden ett system för SAP baserat på vanliga rack- och bladservrar. Två datacenter, belägna cirka 10 km från varandra, var utrustade med olika lagringssystem - IBM SVC, HP och Dell. Nyckelsystem som drivs i katastrofåterställningsläge.

Först efterfrågade kunden en certifierad lösning i Appliance-läge för SAP HANA för alla system (Produktions- och test/dev-miljöer) med tillväxt upp till 12 TB. Men på grund av budgetrestriktioner började de överväga andra alternativ - till exempel fler processorer med mindre RAM-moduler (64 GB-moduler istället för 128 GB-moduler). För att optimera priset övervägdes dessutom gemensam lagring för produktions- och test/dev-miljöerna.

Hur man distribuerar SAP HANA: vi analyserar olika metoder

Vi kom överens om 4 processorer och 6 TB RAM för produktionsmiljön, med utrymme för tillväxt. För test/dev-miljöer i TDI-läge bestämde vi oss för att använda billigare processorer - vi slutade med 8 processorer och 6 TB RAM. På grund av det större antalet funktioner som efterfrågas av kunden - replikering, backup, gemensam produktion och test/dev-miljöer på den andra platsen - istället för interna diskar, användes DellEMC Unity-lagringssystem i en full-flash-konfiguration. Dessutom efterfrågade kunden en katastrofåterställningslösning baserad på HANA-systemreplikering (HSR) med en kvorumnod på en tredje plats.

Den slutliga konfigurationen för Prod-miljön bestod av en BullSequana S400-server på en Intel Xeon P8176M (28 kärnor, 2.10 GHz, 165 W) och 6 TB RAM. Lagringssystem - Unity 450F 10x 3.84 TB. För återställningsändamål använde vi för Prod-miljön en BullSequana S400 på en Intel Xeon P8176M (28 kärnor, 2.10 GHz, 165 W) med 6 TB RAM. För test/dev-miljön tog vi en BullSequana S800-server med en Intel Xeon P8153 (16 kärnor, 2.00 GHz, 125 W) och 6 TB RAM plus ett Unity 450F 15x 3.84 TB lagringssystem. Våra specialister installerade och konfigurerade DellEMC-servrar som ett kvorum, applikationsservrar (VxRail Solution) och backuplösning (DataDomain).

Hur man distribuerar SAP HANA: vi analyserar olika metoder
Utrustningen är redo för framtida uppgraderingar. Kunden förväntar sig att HANA-dimensioneringen kommer att öka under 2019, och allt han behöver göra är att installera nya moduler i racken.

Apparat: HANA för en stor turistintegratör

Den här gången var vår kund en stor IT-tjänsteleverantör som utvecklade tekniska lösningar för reseföretag. Kunden lanserade ett ambitiöst SAP HANA-projekt för att implementera ett nytt faktureringssystem. En lösning krävdes i Appliance-läge med 8 TB RAM för produktions- och PreProd-miljöer. I enlighet med SAPs rekommendationer valde kunden alternativet för vertikal skalning.

Nyckeluppgiften var implementeringen av en hårdvaruinfrastruktur baserad på enheter certifierade i Appliance-läge för SAP HANA. Prioriterade kriterier var kostnadseffektivitet, hög prestanda, skalbarhet och hög datatillgänglighet.

Vi föreslog och implementerade en SAP-certifierad lösning, inklusive två Bullion S16-servrar - för Prod- och PreProd-miljöer. Utrustningen körs på Intel Xeon E7-v4 8890-processorer (24 kärnor, 2.20 GHz, 165 W) och är utrustad med 16 TB RAM. För BW- och Dev/Test-miljöer installerades nio Bullion S4-servrar (22 kärnor, 2.20 GHz, 150 W) med 4 TB RAM. Hybrid EMC Unity användes som lagringssystem.

Denna lösning ger skalningsstöd för alla delar av enheten - till exempel upp till 16 socklar med en Intel Xeon E7-v4 CPU. Administrationen i denna konfiguration är förenklad - i synnerhet för att omkonfigurera eller partitionera servern.

Apparat + TDI: HANA för metallurger

MMC Norilsk Nickel, en av de största tillverkarna av nickel och palladium, beslutade att uppdatera sin SAP HANA-hårdvaruplattform för att stödja kritiska affärsapplikationer och projekt. Det fanns ett behov av att utöka det befintliga landskapet när det gäller datorkraft. En av de viktigaste förutsättningarna som kunden lade fram var den höga tillgängligheten för plattformen – trots hårdvarubegränsningar.

Hur man distribuerar SAP HANA: vi analyserar olika metoder

För produktionsmiljöer använde vi Bullion S8-servern och lagringssystem i SAP HANA Appliance-läge. För HA och test/dev distribuerades plattformen i TDI-läge. Vi använde en Bullion S8-server, två Bullion S6-servrar och ett hybridlagringssystem. Denna kombination gjorde det möjligt att avsevärt öka hastigheten på applikationer i SAP-landskapet, öka mängden datorkraft och datalagringsresurser och minimera driftskostnaderna. Det är viktigt att klienten fortfarande har möjlighet att skala upp till 16 processorer.

Vi inbjuder dig till SAP Forum

I det här inlägget tittade vi på att distribuera SAP HANA på olika sätt och försökte lyfta fram fördelarna och nackdelarna med de tillgängliga alternativen. Om du har några frågor om implementering av SAP HANA svarar vi gärna på dem i kommentarerna.

Vi inbjuder alla som är intresserade av Bull-lösningar och möjligheterna för deras implementering under SAP HANA till årets största SAP-evenemang: SAP Forum 17 kommer att hållas i Moskva den 2019 april. Vi väntar på dig i vår monter i IoT zon: vi kommer att berätta många intressanta saker och även ge bort många priser.

Vi ses på forumet!

Källa: will.com

Lägg en kommentar