SAP HANA estas populara en-memora DBMS, kiu inkluzivas stokadservojn (Data Warehouse) kaj analizojn, enkonstruitan mezvaron, aplikaĵoservilon kaj platformon por agordi aŭ disvolvi novajn servaĵojn. Forigante la latentecon de tradiciaj DBMS-oj kun SAP HANA, vi povas multe pliigi sisteman rendimenton, transakcian prilaboradon (OLTP) kaj komercan inteligentecon (OLAP).
Vi povas disfaldi SAP HANA en Aparato kaj TDI-reĝimoj (se ni parolas pri produktadmedioj). Por ĉiu opcio, la fabrikanto havas siajn proprajn postulojn. En ĉi tiu afiŝo ni parolos pri la avantaĝoj kaj malavantaĝoj de malsamaj opcioj, kaj ankaŭ, por klareco, pri niaj realaj projektoj kun SAP HANA.
SAP HANA konsistas el 3 ĉefaj komponantoj - gastiganto, petskribo kaj sistemo.
Gastiganto estas servilo aŭ operaciumo por funkcii la SAP HANA DBMS. Ĝiaj postulataj komponantoj estas CPU, RAM, stokado, reto kaj OS. La gastiganto disponigas ligilojn al instalaj dosierujoj, datumoj, protokoloj, aŭ rekte al la stokadsistemo. Samtempe, la stokadosistemo por instali SAP HANA ne devas esti lokita sur la gastiganto. Se la sistemo havas plurajn gastigantojn, vi bezonos aŭ komunan stokadon aŭ unu kiu estas disponebla laŭpeto de ĉiuj gastigantoj.
Kazo — aro de SAP HANA-sistemkomponentoj instalitaj sur unu gastiganto. La ĉefaj komponantoj estas la Indeksa Servilo kaj NomServilo. La unua, kiu ankaŭ estas nomita la "funkcianta servilo", procesas petojn, administras aktualajn datumbutikojn kaj datumbazajn motorojn. Nomservilo stokas informojn pri la topologio de la instalaĵo de SAP HANA - kie la komponantoj funkcias kaj kiaj datumoj estas sur la servilo.
sistemo – ĉi tio estas unu aŭ pluraj okazoj kun la sama nombro. Esence, ĉi tio estas aparta elemento kiu povas esti ebligita, malŝaltita aŭ kopiita (sekurkopiita). La datumoj estas distribuitaj en la memoro de la diversaj serviloj kiuj konsistigas la SAP HANA-sistemon.
La sistemo povas esti agordita kiel unu-gastiganto (unu kazo sur unu gastiganto) aŭ plur-gastiganto, distribuita (pluraj SAP HANA-kazoj estas distribuitaj super pluraj gastigantoj, kun unu kazo per gastiganto). En multi-gastigaj sistemoj, ĉiu kazo devas havi la saman nombron. SAP HANA-sistemo estas identigita per System ID (SID), unika nombro konsistanta el tri alfanombraj signoj.
Virtualigo de SAP HANA
Unu el la ĉefaj limigoj de SAP HANA estas la subteno de nur unu sistemo - unu kazo kun unika servilo SID. Por uzi aparataron pli efike aŭ redukti la nombron da serviloj en datumcentro, vi povas uzi virtualigon. Tiel, aliaj pejzaĝoj povas kunekzisti sur la sama servilo kun sistemoj kiuj havas pli malaltajn postulojn (neproduktivaj sistemoj). Por standby HA/DR-servilo, virtualigo povas plibonigi la rapidecon de ŝanĝado inter produktivaj kaj neproduktivaj virtualaj maŝinoj.
SAP HANA inkluzivas subtenon por la hiperviziero VMWare ESX. Ĉi tio signifas, ke malsamaj SAP HANA-sistemoj - SAP HANA-instalaĵoj kun malsamaj SID-nombroj - povas kunekzisti sur ununura gastiganto (komuna fizika servilo) en malsamaj virtualaj maŝinoj. Ĉiu virtuala maŝino devas funkcii per subtenata OS.
Por produktadmedioj, SAP HANA-virtualigo havas gravajn limojn:
- Malgrandiga skalo ne estas subtenata - virtualigo povas esti uzata nur kun Scale-Up-sistemoj, ĉu ĝi estas BwoH/DM/SoH aŭ "pura" SoH;
- virtualigo devas esti efektivigita ene de la reguloj establitaj por Aparato aŭ TDI-aparatoj;
- Ĝenerala Havebleco (GA) povas nur havi unu virtualan maŝinon—firmaoj dezirantaj uzi virtualigon kun HANA-produktadmedioj devas partopreni la Programon de Kontrolita Disponebleco kun SAP.
En ne-produktivaj medioj kie tiuj limigoj ne ekzistas, virtualigo povas esti uzita por optimumigi hardvarutiligon.
SAP HANA-topologioj
Ni pluiru al deplojo de SAP HANA. Du topologioj estas difinitaj ĉi tie.
- Pligrandigo - unu granda servilo. Dum la bazo de HANA kreskas, la servilo mem kreskas: la nombro da CPUoj kaj la kvanto de memoro pliiĝas. En solvoj kun Alta Havebleco (HA) kaj Disaster Recovery (DR), sekurkopioj aŭ misfunkciaj serviloj devas kongrui kun la karakterizaĵoj de produktivaj serviloj.
- Malgrandiĝo - la tuta volumo de la SAP HANA-sistemo estas distribuita tra pluraj identaj serviloj. La Majstra Servilo enhavas informojn por la Indeksa Servilo kaj NomServilo. Sklavaj serviloj ne enhavas ĉi tiujn datumojn - krom la servilo, kiu transprenas la funkciojn de la Majstro okaze de malsukceso de la ĉefa servilo. Indeksserviloj administras la datumsegmentojn kiuj estas asignitaj al ili kaj ankaŭ respondas al petoj. Nomserviloj konscias kiel datumoj estas distribuitaj inter produktaj serviloj. Se HANA kreskas, alia nodo simple aldoniĝas al la nuna servila agordo. En ĉi tiu topologio, sufiĉas havi unu rezervan nodon por certigi la sekurecon de la tuta servilo.
Postuloj pri aparataro de SAP
SAP havas devigajn aparatajn postulojn por HANA. Ili rilatas al produktivaj medioj - por neproduktaj, sufiĉas minimumaj trajtoj. Do, jen la postuloj por produktadmedioj:
- CPU Intel Xeon v5 (SkyLake)/8880/90/94 v4 (Broadwell)
- de 128 GB RAM por BW-aplikoj kun 2 CPUoj, 256 GB kun 4+ CPUoj;
Deplojante SAP HANA en Aparato kaj TDI-reĝimoj
Nun ni plu praktiku kaj parolu pri kiel efektivigi SAP HANA en Aparato kaj TDI-reĝimoj. Por tio ni uzas niajn SAP HANA-platformojn bazitajn sur la serviloj BullSequana S kaj Bullion S, kiuj estas atestitaj de SAP por funkcii en ĉi tiuj reĝimoj.
Iom da informoj pri la produktoj. BullSequana S bazita sur Intel Xeon Scalable inkluzivas diversajn modelojn, ĝis 32 CPUojn en ununura servilo. La servilo estas konstruita uzante modulan dezajnon, kiu provizas skaleblon ĝis 32 CPUoj kaj la saman nombron da GPUoj. RAM - de 64 GB ĝis 48 TB. La funkcioj de BullSequana S inkluzivas entreprenan AI-subtenon por plibonigita efikeco, akcelita datuma analizo, plibonigita en-memora komputado kaj modernigo kun virtualigo kaj nubaj teknologioj.
Bullion S venas kun Intel Xeon E7 v4 Family CPUs. La maksimuma nombro da procesoroj estas 16. RAM estas skalebla de 128 GB ĝis 24 TB. Granda nombro da RAS-funkcioj disponigas altajn nivelojn de havebleco por misi-kritikaj infrastrukturoj kiel SAP HANA. Bullion S taŭgas por amasa datumcentra firmiĝo, funkciado de En-memoraj aplikoj, migrantaj komputilegoj aŭ heredaj sistemoj.
SAP HANA Aparato
Aparato estas antaŭ-agordita solvo, kiu inkluzivas servilon, stoksistemon kaj programaron por klavŝlosila efektivigo, kun centralizita subtena servo kaj interkonsentita agado. Ĉi tie, HANA venas kiel antaŭ-agordita aparataro kaj programaro, plene integrita kaj atestita. La aparato en Aparato-reĝimo estas preta por instalo en la datumcentro, kaj la operaciumo, SAP HANA kaj (se necese) plia VMWare-instanco jam estas agordita kaj instalita.
SAP-atestilo determinas la garantian nivelon de rendimento, same kiel la CPU-modelon, kvanton de RAM kaj stokado. Post kiam atestita, la agordo ne povas esti ŝanĝita sen nuligi la garantion. Por grimpi la HANA-platformon, SAP ofertas tri eblojn.
- Pligrandigo BWoH/DM/SoH – vertikala skalo, kiu taŭgas por unuopaj sistemoj (unu SID). Aparatoj kreskas je 256/384 GB ekde SAP HANA SPS 11. Ĉi tiu proporcio montras la maksimuman kapablon subtenata de unu CPU kaj estas ofta por la tuta listo de atestitaj Aparatoj. Aparato BWoH/DM/SoH kun vertikala skalo estas ideala por BW sur HANA (BWoH), Data Mart (DM) kaj SAP Suite sur HANA (SoH) aplikoj.
- Pligrandigo SoH - Ĉi tio estas malpeza versio de la antaŭa modelo, kun malpli da limigoj pri la kvanto de RAM. Ĉi tio ankoraŭ estas vertikale skalebla servilo, sed la maksimuma kvanto de RAM por 2 procesoroj jam estas 1536 GB (ĝis versio SPS11) kaj 3 TB (SPS12+). Taŭga por SoH nur.
- Skala-eksteren - Ĉi tio estas horizontale skalebla opcio, sistemo kiu subtenas plurservilajn agordojn. Horizontala skalo estas optimuma por BW kaj, kun kelkaj limigoj, por SoH.
En la serviloj BullSequana S kaj Bullion S, vertikala skalo estas la fokuso ĉar ĝi havas malpli da funkciaj limigoj kaj postulas malpli da administrado. Por Aparato-reĝimo ekzistas granda gamo da malsamaj aparatoj.
BullSequana S-solvoj por SAP HANA en Aparato-reĝimo
*Laŭvola E7-8890/94v4
Bullion S-solvoj por SAP HANA en Aparato-reĝimo
Ĉiuj Bull-solvoj en Aparato-reĝimo de SAP HANA SPS 12 estas atestitaj. La ekipaĵo estas instalita en norma 19-cola 42U-rako, kun du elektrofontoj - internaj PDU-oj. La sekvaj serviloj havas SAP-atestilon:
- BullSequana S kun Intel Xeon Skylake 8176, 8176M, 8180, 8180M (procesoroj kun la litero "M" subtenas 128 GB-memormodulojn). Laŭ prezo-kvalita rilatumo, la ebloj kun Intel 8176 aspektas plej bone
- Bullion S kun Intel Xeon E7-8880 v4, 8890 kaj 8894.
La stokadsistemo konektas rekte al la servilo per FC-havenoj, do SAN-ŝaltiloj ne bezonas ĉi tie. Ili povas esti utilaj por aliri sistemojn konektitajn al LAN aŭ SAN.
Jen ekzemplo de la agordo de la konserva sistemo de EMC Unity 450F en nia aranĝo:
- Alteco: 5U (DPE 3U (25×2,5″ HDD/SSD) + DAE 2U (25×2,5″ HDD/SSD))
- Regiloj: 2
- Diskoj: de 6 ĝis 250 SAS SSD, de 600 GB ĝis 15.36 TB ĉiu
- RAID: nivelo 5 (8+1), 4 RAID-grupoj
- Interfaco: 4 FC per regilo, 8 aŭ 16 Gbit/s
- Programaro: Unisphere Block Suite
Aparato estas fidinda disfalda opcio, sed ĝi havas grandan malavantaĝon: malmulte da libereco en agordo de aparataro. Krome, ĉi tiu opcio povas postuli ŝanĝojn en la procezoj de la IT-fako.
SAP HANA TDI
Alternativo al Appliance estas TDI (Tailored Datacenter Integration) reĝimo, en kiu vi povas elekti specifajn produktantojn kaj infrastrukturajn komponantojn depende de la deziroj de la kliento - konsiderante la taskojn plenumitajn kaj laborkvanton. Ekzemple, SAN povas esti reuzita en datumcentro, kun kelkaj diskoj dediĉitaj al HANA-instalaĵo.
Kompare kun Aparato, TDI-reĝimo donas al la uzanto multe pli da libereco por plenumi postulojn. Ĉi tio multe simpligas la integriĝon de HANA en la datumcentron - vi povas konstrui vian propran personigitan infrastrukturon. Ekzemple, variu la tipon kaj nombron da procesoroj depende de la ŝarĝo.
Por kapacitkalkuloj, ni rekomendas uzi SAP Quick Sizer, simplan ilon, kiu provizas CPU- kaj memorpostulojn por malsamaj laborŝarĝoj en SAP HANA. Vi povas tiam kontakti SAP Active Global Support por plani vian IT-pejzaĝon. Post tio, la partnero de aparataro de SAP HANA konvertas la kalkulrezultojn en malsamajn eblajn sistemajn agordojn - kaj sur la plej alta gamo kaj sur pli simpla aparataro. En TDI-reĝimo por serviloj estas akcepteble uzi CPU Intel E7, inkluzive de Intel Broadwell E7 kaj Skylake-SP (Plateno, Oro, Arĝento kun 8 aŭ pli da kernoj per procesoro), same kiel IBM Power8/ 9.
Serviloj estas liveritaj sen stokaj sistemoj, ŝaltiloj kaj rakoj, sed la aparataro postuloj restas la samaj kiel en Aparato-reĝimo - la samaj ununuraj nodoj, solvoj kun vertikala aŭ horizontala skalo. SAP postulas tion nur atestitaj serviloj, stokadsistemoj kaj ŝaltiloj estis uzitaj, sed ĉi tio ne estas timiga - plej multaj fabrikantoj havas preskaŭ ĉiujn ekipaĵojn atestitajn.
Efikectestado devus esti farita per HWCCT (Hardware Configuration Check Tool) testoj., kiuj permesas vin kontroli konformecon kun certaj SAP-KPIoj. Kaj estas ne-aparataro postulo: HANA, OS kaj hiperviziero (laŭvola) devas esti instalitaj de SAP-atestitaj specialistoj. Nur sistemoj, kiuj plenumas ĉiujn listigitajn regulojn, povas ricevi SAP-efikecsubtenon.
La BullSequana S-linio de serviloj en TDI-reĝimo estas simila al la linio en Aparato-reĝimo, sed sen stokaj sistemoj, ŝaltiloj kaj rakoj. Vi povas instali ajnan stokan sistemon el la listo de atestitaj SAP-sistemoj - VNX, XtremIO, NetApp kaj aliaj. Ekzemple, se la VNX5400 plenumas la agadojn de SAP HANA, vi povas konekti Dell EMC Unity 450F-stokadon kiel parto de la TDI-agordo. Se necese, FC-adaptiloj (1 aŭ 10 Gbit/s), same kiel Ethernet-ŝaltiloj, estas instalitaj.
Nun, por ke vi povu pli klare imagi la priskribitajn reĝimojn, ni rakontos al vi pri pluraj el niaj realaj kazoj.
Aparato + TDI: HANA por reta vendejo
La reta butiko Mall.cz, parto de la Butikcentro-Grupo, estis fondita en 2000. Ĝi havas branĉojn en Ĉeĥio, Slovakio, Pollando, Hungario, Slovenio, Kroatio kaj Rumanio. Ĉi tiu estas la plej granda reta butiko en la lando, vendante ĝis 75 mil produktojn tage, ĝia enspezo fine de 2017 sumiĝis al ĉirkaŭ 280 milionoj da eŭroj.
Ĝisdatigi la datumcentran infrastrukturon estis postulata lige kun migrado al SAP HANA. La laŭtaksa grandeco estis 2x6 TB por prod-medioj kaj 6 TB por testaj/dev-medioj. Samtempe, solvo kun katastrofa reakiro estis postulata por produktiva SAP HANA-medio en aktiva-aktiva areto.
En la momento de la oferto anonco, la kliento havis sistemon por SAP bazita sur normaj rako kaj klingoserviloj. Du datumcentroj, situantaj proksimume 10 km unu de la alia, estis ekipitaj per diversaj stoksistemoj - IBM SVC, HP kaj Dell. Ŝlosilsistemoj funkciis en katastrofa reakiro.
Unue, la kliento petis atestitan solvon en Aparato-reĝimo por SAP HANA por ĉiuj sistemoj (Produktado kaj testaj/devmedioj) kun kresko ĝis 12 TB. Sed pro buĝetaj limigoj, ili komencis pripensi aliajn eblojn - ekzemple, pli da CPUoj kun pli malgrandaj RAM-moduloj (64 GB-moduloj anstataŭ 128 GB-moduloj). Krome, por optimumigi la prezon, oni konsideris komunan stokadon por la Produktado kaj test/dev-medioj.
Ni konsentis pri 4 CPUoj kaj 6 TB RAM por la Produktada medio, kun loko por kresko. Por test/dev-medioj en TDI-reĝimo, ni decidis uzi malpli multekostajn CPUojn - ni finis kun 8 CPUoj kaj 6 TB da RAM. Pro la pli granda nombro da funkcioj petitaj de la kliento - reproduktado, sekurkopio, komuna Produktado kaj testaj/dev-medioj sur la dua retejo - anstataŭ internaj diskoj, DellEMC Unity stokadsistemoj estis uzitaj en plen-fulma agordo. Krome, la kliento petis solvon pri katastrofa reakiro bazita sur HANA-sistema reproduktado (HSR) kun kvoruma nodo sur tria retejo.
La fina agordo por la Prod-medio konsistis el BullSequana S400-servilo sur Intel Xeon P8176M (28 kernoj, 2.10 GHz, 165 W) kaj 6 TB da RAM. Stokadosistemo - Unity 450F 10x 3.84 TB. Por katastrofa reakiro, por la medio Prod ni uzis BullSequana S400 sur Intel Xeon P8176M (28 kernoj, 2.10 GHz, 165 W) kun 6 TB da RAM. Por la testo/dev-medio, ni prenis BullSequana S800-servilon kun Intel Xeon P8153 (16 kernoj, 2.00 GHz, 125 W) kaj 6 TB da RAM plus Unity 450F 15x 3.84 TB stokadsistemo. Niaj specialistoj instalis kaj agordis DellEMC-servilojn kiel kvorumon, aplikaĵservilojn (VxRail Solution) kaj rezervan solvon (DataDomain).
La ekipaĵo estas preta por estontaj ĝisdatigoj. La kliento atendas, ke la grandeco de HANA pliiĝos en 2019, kaj ĉio, kion li devas fari, estas instali novajn modulojn en la rakoj.
Aparato: HANA por granda turisma integristo
Ĉi-foje nia kliento estis granda IT-servoprovizanto evoluiganta teknologiajn solvojn por vojaĝkompanioj. La kliento lanĉis ambician SAP HANA-projekton por efektivigi novan fakturan sistemon. Solvo estis postulata en Aparato-reĝimo kun 8 TB da RAM por Produktado kaj PreProd-medioj. Konforme al SAP-rekomendoj, la kliento elektis la vertikalan skalan opcion.
La ŝlosila tasko estis la efektivigo de aparatara infrastrukturo bazita sur aparatoj atestitaj en Aparato-reĝimo por SAP HANA. La prioritatkriterioj estis kostefikeco, alta efikeco, skaleblo kaj alta datenhavebleco.
Ni proponis kaj efektivigis SAP-atestitan solvon, inkluzive de du Bullion S16-serviloj - por Prod kaj PreProd-medioj. La ekipaĵo funkcias per procesoroj Intel Xeon E7-v4 8890 (24 kernoj, 2.20 GHz, 165 W) kaj estas ekipita per 16 TB da RAM. Por BW kaj Dev/Test-medioj, naŭ Bullion S4-serviloj (22 kernoj, 2.20 GHz, 150 W) kun 4 TB da RAM estis instalitaj. Hybrid EMC Unity estis utiligita kiel stokadsistemo.
Ĉi tiu solvo provizas grimpigan subtenon por ĉiuj elementoj de la aparato - ekzemple ĝis 16 ingoj kun CPU Intel Xeon E7-v4. Administrado en ĉi tiu agordo estas simpligita - precipe por reagordi aŭ dividi la servilon.
Aparato + TDI: HANA por metalurgiistoj
MMC Norilsk Nickel, unu el la plej grandaj produktantoj de nikelo kaj paladio, decidis ĝisdatigi sian aparataron SAP HANA por subteni kritikajn komercajn aplikojn kaj projektojn. Estis bezono vastigi la ekzistantan pejzaĝon laŭ komputa potenco. Unu el la ĉefaj kondiĉoj prezentitaj de la kliento estis la alta havebleco de la platformo - malgraŭ aparatara limigo.
Por produktaj medioj, ni uzis la servilon kaj stoksistemojn Bullion S8 en SAP HANA Aparato-reĝimo. Por HA kaj testo/dev, la platformo estis deplojita en TDI-reĝimo. Ni uzis unu Bull Bullion S8-servilon, du Bull Bullion S6-servilojn kaj hibridan stoksistemon. Ĉi tiu kombinaĵo ebligis signife pliigi la rapidecon de aplikoj en la SAP-pejzaĝo, pliigi la kvanton de komputika potenco kaj datumstokado-resursoj, kaj minimumigi funkciigadkostojn. Gravas, ke la kliento ankoraŭ havas la kapablon grimpi ĝis 16 CPUoj.
Ni invitas vin al la SAP-Forumo
En ĉi tiu afiŝo, ni rigardis disfaldi SAP HANA en malsamaj manieroj kaj provis reliefigi la avantaĝojn kaj malavantaĝojn de la disponeblaj opcioj. Se vi havas demandojn pri efektivigo de SAP HANA, ni volonte respondos ilin en la komentoj.
Ni invitas ĉiujn, kiuj interesiĝas pri Bull-solvoj kaj la eblecoj de ilia efektivigo sub SAP HANA al la plej granda SAP-evento de la jaro: SAP Forumo 17 okazos en Moskvo la 2019-an de aprilo. Ni atendas vin ĉe nia stando en la IoT. zono: ni rakontos al vi multajn interesajn aferojn, kaj ankaŭ fordonos multajn premiojn.
Ĝis revido sur la forumo!
fonto: www.habr.com