Hvordan distribuere SAP HANA: vi analyserer forskjellige metoder

SAP HANA er en populær DBMS i minnet som inkluderer lagringstjenester (Data Warehouse) og analyser, innebygd mellomvare, en applikasjonsserver og en plattform for å konfigurere eller utvikle nye verktøy. Ved å eliminere ventetiden til tradisjonelle DBMS-er med SAP HANA, kan du øke systemytelsen, transaksjonsbehandlingen (OLTP) og business intelligence (OLAP) betraktelig.

Hvordan distribuere SAP HANA: vi analyserer forskjellige metoder

Du kan distribuere SAP HANA i Appliance- og TDI-modus (hvis vi snakker om produksjonsmiljøer). For hvert alternativ har produsenten sine egne krav. I dette innlegget vil vi snakke om fordelene og ulempene ved forskjellige alternativer, samt, for klarhet, om våre virkelige prosjekter med SAP HANA.

SAP HANA består av 3 hovedkomponenter - vert, instans og system.

Vert er en server eller et driftsmiljø for å kjøre SAP HANA DBMS. De nødvendige komponentene er CPU, RAM, lagring, nettverk og OS. Verten gir lenker til installasjonskataloger, data, logger eller direkte til lagringssystemet. Samtidig trenger ikke lagringssystemet for å installere SAP HANA være plassert på verten. Hvis systemet har flere verter, trenger du enten delt lagring eller en som er tilgjengelig på forespørsel fra alle verter.

Forekomst — et sett med SAP HANA-systemkomponenter installert på én vert. Hovedkomponentene er indeksserveren og navneserveren. Den første, som også kalles "arbeidsserveren", behandler forespørsler, administrerer nåværende datalagre og databasemotorer. Name Server lagrer informasjon om topologien til SAP HANA-installasjonen - hvor komponentene kjører og hvilke data som er på serveren.

System – dette er en eller flere forekomster med samme nummer. I hovedsak er dette et eget element som kan aktiveres, deaktiveres eller kopieres (sikkerhetskopieres). Dataene distribueres i minnet til de ulike serverne som utgjør SAP HANA-systemet.

Hvordan distribuere SAP HANA: vi analyserer forskjellige metoder
Systemet kan konfigureres som enkeltvert (én forekomst på én vert) eller multivert, distribuert (flere SAP HANA-forekomster er fordelt over flere verter, med én forekomst per vert). I multi-host-systemer må hver forekomst ha samme nummer. Et SAP HANA-system identifiseres med en system-ID (SID), et unikt nummer som består av tre alfanumeriske tegn.

SAP HANA virtualisering

En av hovedbegrensningene til SAP HANA er støtten til kun ett system - én instans med en unik server-SID. For å bruke maskinvare mer effektivt eller redusere antall servere i et datasenter, kan du bruke virtualisering. På denne måten kan andre landskap sameksistere på samme server med systemer som har lavere krav (ikke-produktive systemer). For en standby HA/DR-server kan virtualisering forbedre hastigheten på veksling mellom produktive og ikke-produktive virtuelle maskiner.

SAP HANA inkluderer støtte for VMWare ESX hypervisor. Dette betyr at forskjellige SAP HANA-systemer - SAP HANA-installasjoner med forskjellige SID-nummer - kan eksistere side om side på en enkelt vert (felles fysisk server) i forskjellige virtuelle maskiner. Hver virtuell maskin må kjøre på et støttet operativsystem.

For produksjonsmiljøer har SAP HANA-virtualisering alvorlige begrensninger:

  • Skalering av utskalering støttes ikke - virtualisering kan bare brukes med oppskaleringssystemer, enten det er BwoH/DM/SoH eller "ren" SoH;
  • virtualisering må utføres innenfor reglene fastsatt for apparat- eller TDI-enheter;
  • General Availability (GA) kan bare ha én virtuell maskin – selskaper som ønsker å bruke virtualisering med HANA-produksjonsmiljøer må delta i Controlled Availability-programmet med SAP.

I ikke-produktive miljøer der disse begrensningene ikke eksisterer, kan virtualisering brukes til å optimalisere maskinvareutnyttelsen.

SAP HANA topologier

La oss gå videre til å distribuere SAP HANA. To topologier er definert her.

  • Oppskalering – én stor server. Etter hvert som HANA-basen vokser, vokser selve serveren: antall CPUer og mengden minne øker. I løsninger med High Availability (HA) og Disaster Recovery (DR), må backup- eller feiltolerante servere samsvare med egenskapene til produktive servere.
  • Skalering – hele volumet av SAP HANA-systemet er fordelt på flere identiske servere. Hovedserveren inneholder informasjon for indeksserveren og navneserveren. Slaveservere inneholder ikke disse dataene - bortsett fra serveren, som overtar funksjonene til Master i tilfelle feil på hovedserveren. Indeksservere administrerer datasegmentene som er tilordnet dem og svarer også på forespørsler. Navnetjenere er klar over hvordan data distribueres mellom produksjonsservere. Hvis HANA vokser, legges en annen node ganske enkelt til den gjeldende serverkonfigurasjonen. I denne topologien er det nok å ha én backup-node for å sikre sikkerheten til hele serveren.

Hvordan distribuere SAP HANA: vi analyserer forskjellige metoder

Krav til SAP-maskinvare

SAP har obligatoriske maskinvarekrav for HANA. De forholder seg til produktive miljøer - for ikke-prod er minimale egenskaper tilstrekkelig. Så her er kravene til produksjonsmiljøer:

  • CPU Intel Xeon v5 (SkyLake) / 8880/90/94 v4 (Broadwell)
  • fra 128 GB RAM for BW-applikasjoner med 2 CPUer, 256 GB med 4+ CPUer;

Utrulling av SAP HANA i enhets- og TDI-modus

La oss nå gå videre til praksis og snakke om hvordan du implementerer SAP HANA i Appliance- og TDI-moduser. Til dette bruker vi våre SAP HANA-plattformer basert på BullSequana S- og Bullion S-serverne, som er sertifisert av SAP for å operere i disse modusene.

Litt informasjon om produktene. BullSequana S basert på Intel Xeon Scalable inkluderer ulike modeller, opptil 32 CPUer på en enkelt server. Serveren er bygget ved hjelp av en modulær design som gir skalerbarhet opptil 32 CPUer og samme antall GPUer. RAM – fra 64 GB til 48 TB. BullSequana S-funksjoner inkluderer enterprise AI-støtte for forbedret ytelse, akselerert dataanalyse, forbedret databehandling i minnet og modernisering med virtualisering og skyteknologier.

Bullion S kommer med Intel Xeon E7 v4 familie-CPUer. Maksimalt antall prosessorer er 16. RAM er skalerbar fra 128 GB til 24 TB. Et stort antall RAS-funksjoner gir høye nivåer av tilgjengelighet for virksomhetskritiske infrastrukturer som SAP HANA. Bullion S er egnet for massedatasenterkonsolidering, kjøring av In-Memory-applikasjoner, migrering av stormaskiner eller eldre systemer.

SAP HANA Appliance

Appliance er en forhåndskonfigurert løsning som inkluderer en server, lagringssystem og en programvarepakke for nøkkelferdig implementering, med en sentralisert støttetjeneste og et avtalt ytelsesnivå. Her kommer HANA som forhåndskonfigurert maskinvare og programvare, fullt integrert og sertifisert. Enheten i Appliance-modus er klar for installasjon i datasenteret, og operativsystemet, SAP HANA og (om nødvendig) en ekstra VMWare-instans er allerede konfigurert og installert.

SAP-sertifisering bestemmer det garanterte ytelsesnivået, samt CPU-modellen, mengde RAM og lagring. Når den er sertifisert, kan ikke konfigurasjonen endres uten å ugyldiggjøre garantien. For å skalere HANA-plattformen tilbyr SAP tre alternativer.

  • Oppskalering BWoH/DM/SoH – vertikal skalering, som er egnet for enkeltsystemer (én SID). Apparater vokser med 256/384 GB fra og med SAP HANA SPS 11. Dette forholdet viser maksimal kapasitet som støttes av én CPU og er felles for hele listen over sertifiserte apparater. Apparat BWoH/DM/SoH med vertikal skalering er ideell for BW på HANA (BWoH), Data Mart (DM) og SAP Suite på HANA (SoH)-applikasjoner.
  • Oppskalering SoH – Dette er en lettvektsversjon av den forrige modellen, med færre begrensninger på mengden RAM. Dette er fortsatt en vertikalt skalerbar server, men den maksimale mengden RAM for 2 prosessorer er allerede 1536 GB (opp til versjon SPS11) og 3 TB (SPS12+). Kun egnet for SoH.
  • Skalere ut – Dette er et horisontalt skalerbart alternativ, et system som støtter multi-server konfigurasjoner. Horisontal skalering er optimal for BW og, med noen begrensninger, for SoH.

I BullSequana S- og Bullion S-serverne er vertikal skalering i fokus fordi den har færre operasjonelle begrensninger og krever mindre administrasjon. For apparatmodus er det et stort utvalg av forskjellige enheter.

Hvordan distribuere SAP HANA: vi analyserer forskjellige metoder
BullSequana S-løsninger for SAP HANA i enhetsmodus

Hvordan distribuere SAP HANA: vi analyserer forskjellige metoder
*Valgfri E7-8890/94v4
Bullion S-løsninger for SAP HANA i Appliance-modus

Alle Bull-løsninger i Appliance-modus fra SAP HANA SPS 12 er sertifisert. Utstyret er installert i et standard 19-tommers 42U-rack, med to strømforsyninger - interne PDUer. Følgende servere har SAP-sertifisering:

  • BullSequana S med Intel Xeon Skylake 8176, 8176M, 8180, 8180M (prosessorer med bokstaven "M" støtter 128 GB minnemoduler). Når det gjelder forhold mellom pris og kvalitet, ser alternativene med Intel 8176 best ut
  • Bullion S med Intel Xeon E7-8880 v4, 8890 og 8894.

Lagringssystemet kobles direkte til serveren via FC-porter, så SAN-svitsjer er ikke nødvendig her. De kan være nyttige for å få tilgang til systemer koblet til et LAN eller SAN.

Her er et eksempel på EMC Unity 450F-lagringssystemkonfigurasjonen i oppsettet vårt:

  • Høyde: 5U (DPE 3U (25×2,5" HDD/SSD) + DAE 2U (25×2,5" HDD/SSD))
  • Kontrollere: 2
  • Disker: fra 6 til 250 SAS SSD, fra 600 GB til 15.36 TB hver
  • RAID: nivå 5 (8+1), 4 RAID-grupper
  • Grensesnitt: 4 FC per kontroller, 8 eller 16 Gbit/s
  • Programvare: Unisphere Block Suite

Apparatet er et pålitelig distribusjonsalternativ, men det har en stor ulempe: liten frihet til å konfigurere maskinvare. I tillegg kan dette alternativet kreve endringer i prosessene til IT-avdelingen.

SAP HANA TDI

Et alternativ til Appliance er TDI (Tailored Data Center Integration)-modus, der du kan velge spesifikke produsenter og infrastrukturkomponenter avhengig av kundens ønsker - med hensyn til utførte oppgaver og arbeidsmengde. For eksempel kan et SAN gjenbrukes i et datasenter, med noen disker dedikert til en HANA-installasjon.

Sammenlignet med Appliance gir TDI-modus brukeren mye større frihet til å oppfylle kravene. Dette forenkler i stor grad integreringen av HANA i datasenteret – du kan bygge din egen tilpassede infrastruktur. Varier for eksempel type og antall prosessorer avhengig av belastningen.

Hvordan distribuere SAP HANA: vi analyserer forskjellige metoder
For kapasitetsberegninger anbefaler vi å bruke SAP Quick Sizer, et enkelt verktøy som gir CPU- og minnekrav for ulike arbeidsbelastninger i SAP HANA. Du kan deretter kontakte SAP Active Global Support for å planlegge IT-landskapet ditt. Etter dette konverterer SAP HANA maskinvarepartneren beregningsresultatene til ulike mulige systemkonfigurasjoner - både på topp-end og på enklere maskinvare. I TDI-modus for servere det er akseptabelt å bruke Intel E7 CPUer, inkludert Intel Broadwell E7 og Skylake-SP (Platinum, Gold, Silver med 8 eller flere kjerner per prosessor), samt IBM Power8/ 9.

Servere leveres uten lagringssystemer, brytere og rack, men maskinvarekravene forblir de samme som i Appliance-modus - de samme enkeltnodene, løsninger med vertikal eller horisontal skalering. SAP krever det kun sertifiserte servere, lagringssystemer og svitsjer ble brukt, men dette er ikke skummelt - de fleste produsenter har nesten alt utstyr sertifisert.

Ytelsestesting bør utføres ved hjelp av HWCCT-tester (Hardware Configuration Check Tool)., som lar deg kontrollere samsvar med visse SAP KPIer. Og det er et ikke-maskinvarekrav: HANA, OS og hypervisor (valgfritt) må installeres av SAP-sertifiserte spesialister. Bare systemer som oppfyller alle de oppførte reglene kan motta SAP-ytelsesstøtte.

BullSequana S-serien med servere i TDI-modus ligner på linjen i Appliance-modus, men uten lagringssystemer, brytere og rack. Du kan installere et hvilket som helst lagringssystem fra listen over sertifiserte SAP-systemer - VNX, XtremIO, NetApp og andre. For eksempel, hvis VNX5400 oppfyller SAP HANA-ytelseskravene, kan du koble til Dell EMC Unity 450F-lagring som en del av TDI-konfigurasjonen. Om nødvendig er FC-adaptere (1 eller 10 Gbit/s), samt Ethernet-svitsjer, installert.

Nå, slik at du klarere kan forestille deg de beskrevne modusene, vil vi fortelle deg om flere av våre virkelige tilfeller.

Apparat + TDI: HANA for nettbutikk

Nettbutikken Mall.cz, en del av Mall Group, ble grunnlagt i 2000. Den har avdelinger i Tsjekkia, Slovakia, Polen, Ungarn, Slovenia, Kroatia og Romania. Dette er den største nettbutikken i landet, som selger opptil 75 tusen produkter per dag, inntektene ved slutten av 2017 utgjorde rundt 280 millioner euro.

Oppdatering av datasenterinfrastrukturen var nødvendig i forbindelse med migrering til SAP HANA. Den estimerte størrelsen var 2x6 TB for prod-miljøer og 6 TB for test-/dev-miljøer. Samtidig var det nødvendig med en løsning med katastrofegjenoppretting for et produktivt SAP HANA-miljø i en aktiv-aktiv klynge.

På tidspunktet for anbudskunngjøringen hadde kunden et system for SAP basert på standard rack- og bladservere. To datasentre, som ligger omtrent 10 km fra hverandre, var utstyrt med forskjellige lagringssystemer - IBM SVC, HP og Dell. Nøkkelsystemer operert i katastrofegjenopprettingsmodus.

Først ba kunden om en sertifisert løsning i Appliance-modus for SAP HANA for alle systemer (Produksjons- og test/dev-miljøer) med vekst opp til 12 TB. Men på grunn av budsjettbegrensninger begynte de å vurdere andre alternativer - for eksempel flere CPUer med mindre RAM-moduler (64 GB-moduler i stedet for 128 GB-moduler). I tillegg, for å optimalisere prisen, ble felles lagring for produksjons- og test/dev-miljøene vurdert.

Hvordan distribuere SAP HANA: vi analyserer forskjellige metoder

Vi ble enige om 4 CPUer og 6 TB RAM for produksjonsmiljøet, med rom for vekst. For test/dev-miljøer i TDI-modus bestemte vi oss for å bruke rimeligere CPUer – vi endte opp med 8 CPUer og 6 TB RAM. På grunn av det større antallet funksjoner kunden etterspør - replikering, sikkerhetskopiering, felles produksjon og test/dev-miljøer på den andre siden - i stedet for interne disker, ble DellEMC Unity-lagringssystemer brukt i en full-flash-konfigurasjon. I tillegg ba kunden om en nødgjenopprettingsløsning basert på HANA systemreplikering (HSR) med en quorum node på et tredje nettsted.

Den endelige konfigurasjonen for Prod-miljøet besto av en BullSequana S400-server på en Intel Xeon P8176M (28 kjerner, 2.10 GHz, 165 W) og 6 TB RAM. Lagringssystem - Unity 450F 10x 3.84 TB. For gjenopprettingsformål brukte vi for Prod-miljøet en BullSequana S400 på en Intel Xeon P8176M (28 kjerner, 2.10 GHz, 165 W) med 6 TB RAM. For test/dev-miljøet tok vi en BullSequana S800-server med en Intel Xeon P8153 (16 kjerner, 2.00 GHz, 125 W) og 6 TB RAM pluss et Unity 450F 15x 3.84 TB lagringssystem. Våre spesialister installerte og konfigurerte DellEMC-servere som et quorum, applikasjonsservere (VxRail Solution) og backup-løsning (DataDomain).

Hvordan distribuere SAP HANA: vi analyserer forskjellige metoder
Utstyret er klart for fremtidige oppgraderinger. Kunden forventer at HANA-dimensjoneringen vil øke i 2019, og alt han trenger å gjøre er å installere nye moduler i stativene.

Apparat: HANA for en stor reiselivsintegrator

Denne gangen var vår klient en stor IT-tjenesteleverandør som utvikler teknologiske løsninger for reiseselskaper. Kunden lanserte et ambisiøst SAP HANA-prosjekt for å implementere et nytt faktureringssystem. En løsning var nødvendig i Appliance-modus med 8 TB RAM for produksjons- og PreProd-miljøer. I samsvar med SAP-anbefalingene valgte kunden alternativet for vertikal skalering.

Nøkkeloppgaven var implementeringen av en maskinvareinfrastruktur basert på enheter sertifisert i Appliance-modus for SAP HANA. Prioriteringskriteriene var kostnadseffektivitet, høy ytelse, skalerbarhet og høy datatilgjengelighet.

Vi foreslo og implementerte en SAP-sertifisert løsning, inkludert to Bullion S16-servere – for Prod- og PreProd-miljøer. Utstyret kjører på Intel Xeon E7-v4 8890-prosessorer (24 kjerner, 2.20 GHz, 165 W) og er utstyrt med 16 TB RAM. For BW- og Dev/Test-miljøer ble ni Bullion S4-servere (22 kjerner, 2.20 GHz, 150 W) med 4 TB RAM installert. Hybrid EMC Unity ble brukt som lagringssystem.

Denne løsningen gir skaleringsstøtte for alle elementer i enheten - for eksempel opptil 16 sokler med en Intel Xeon E7-v4 CPU. Administrasjon i denne konfigurasjonen er forenklet - spesielt for rekonfigurering eller partisjonering av serveren.

Apparat + TDI: HANA for metallurger

MMC Norilsk Nickel, en av de største produsentene av nikkel og palladium, bestemte seg for å oppdatere sin SAP HANA maskinvareplattform for å støtte kritiske forretningsapplikasjoner og prosjekter. Det var behov for å utvide det eksisterende landskapet når det gjelder datakraft. En av hovedbetingelsene som ble fremsatt av kunden var den høye tilgjengeligheten til plattformen – til tross for maskinvarebegrensninger.

Hvordan distribuere SAP HANA: vi analyserer forskjellige metoder

For produksjonsmiljøer brukte vi Bullion S8-serveren og lagringssystemer i SAP HANA Appliance-modus. For HA og test/dev ble plattformen distribuert i TDI-modus. Vi brukte én Bull Bullion S8-server, to Bull Bullion S6-servere og et hybrid lagringssystem. Denne kombinasjonen gjorde det mulig å øke hastigheten på applikasjoner betydelig i SAP-landskapet, øke mengden datakraft og datalagringsressurser og minimere driftskostnadene. Det er viktig at klienten fortsatt har muligheten til å skalere opp til 16 CPUer.

Vi inviterer deg til SAP-forumet

I dette innlegget så vi på distribusjon av SAP HANA på forskjellige måter og prøvde å fremheve fordelene og ulempene ved de tilgjengelige alternativene. Hvis du har spørsmål om implementering av SAP HANA, vil vi gjerne svare på dem i kommentarene.

Vi inviterer alle som er interessert i Bull-løsninger og mulighetene for deres implementering under SAP HANA til årets største SAP-arrangement: SAP Forum 17 arrangeres i Moskva 2019. april. Vi venter på deg på vår stand i IoT sone: vi vil fortelle deg mye interessant, og også gi bort mange premier.

Vi sees på forumet!

Kilde: www.habr.com

Legg til en kommentar