SPARC esettanulmány Karácsony László Remedios ZRt április 11.

Átírás

1 SPARC esettanulmány Készítette: Karácsony László Remedios ZRt április 11.

2 Agenda Komplex Oracle S7-2 és Oracle VM for SPARC alapú virtuális, többrétegű alkalmazás platform kialakításának tapasztalatait szeretnénk bemutatni az előadás során. Az előadásban érintjük a projekt fázisait: Tervezési szempontok meghatározása, tervezés (teljesítmény, rendelkezésre állás, biztonság), Implementáció, Teljesítmény tesztelés és hangolás, Az előadás végén bemutatjuk, hogy a tervezési célok milyen módon valósultak meg, a teljesítmény tesztelés zárásával. 2

3 Éles adatbázis hardver környezet régi és új Eredeti konfiguráció: 2xT4-4 szerver 4x8 magos T4 processzor 256 GB memória 4x4 Gb FC 4x1 Gb Ethernet hálózat 2x10 Gb optikai Ethernet hálózat Éles új konfiguráció: 2xS7-2L szerver 2x8 magos S7 processzor 512GB GB memória 4x16 Gb FC diszk elérés 2x16 Gb FC - mentés 2x2 10 Gb optikai Ethernet 4x10 Gb RJ45 Ethernet 3

4 Éles Weblogic hardver környezet régi és új Eredeti konfiguráció: 4xT4-2 szerver 2x8 magos T4 processzor 128 GB memória 4x1 Gb Ethernet hálózat 2x10 Gb optikai Ethernet hálózat Éles új konfiguráció: 2x3xS7-2L szerver 2x8 magos S7 processzor 512GB GB memória 4x16 Gb FC diszk elérés 2x16 Gb FC - mentés 2x2 10 Gb optikai Ethernet 4x10 Gb RJ45 Ethernet 4

5 S7-2(L) szerverek specifikációja Nyolc magos SPARC processzor Fix két processzoros vagy egy processzoros kiépítés Processzorra integrált kriptográfiai segéd áramkörök, hatékony SSL/TLS gyorsítás. Három, illetve hat PCIe hely. Maximum 1024 GB memória. 5

6 Méretezési alapelvek A fentiek alapján látszik, hogy az S7 mag 2,87 szeres teljesítményt nyújt, mint a korábbi T4 mag, így a magszám csökkenés ellenére az új platform teljesítménye valójában nagyobb lesz a valós alkalmazás terhelés mellett is. Megjegyzendő, hogy csak adatbázis teljesítményre nincs ilyen hivatalos mérés, de más projektben a T4 mag és a M7/S7 mag esetében legalább kétszeres növekedést mértünk. A titkosítás csak minimális teljesítmény csökkenést okoz ,00 800,00 600,00 400,00 200,00 0,00 EjOPS/core 900,05 784,16 532,30 313,32 147,75 T3-4 T4-4 T5-2 T7-1 S7-2 EjOPS/core 6

7 Rendelkezésre állás - Root complex a redundancia alapja Root complex: A root complex is the CMP circuitry that provides the base to a PCIe I/O fabric. Each PCIe I/O fabric consists of the PCIe switches, PCIe slots, and leaf devices associated with the root complex. Understanding the relationship of the PCIe root complexes to the PCIe I/O fabrics will help you properly assign devices when configuring Oracle VM Server for SPARC logical domains. 7

8 Rendelkezésre állás - Oracle VM for SPARC alapfogalmak Control domain: Ez a domain látja el a virtuális környezet menedzsmentjét, amit domain-ek konfigurálásához és erőforrások kezeléséhez használnak. Ez az első domain, ami elindul a rendszer indítás során, ez egy I/O domain és általában egy service domain is egyben. Control Domain-ból mindössze egy lehet. I/O domain: Egy domain, ami a fizikai I/O eszközökhöz van hozzárendelve, ilyenek lehetnek: egy PCIe root complex, egy PCI eszköz, vagy egy SR-IOV (Single-Root I/O Virtualizáció) funkció. Az IO eszközöknek natív teljesítménye és funkcionalitása van, amiket birtokol. Ezeket az IO eszközöket nem közvetíti egy virtualizációs réteg sem. I/O domainból több is lehet. Service domain: Egy domain, ami virtuális hálózatot és lemezeszközöket biztosít guest domaineknek. Több service domain is lehet, habár a gyakorlatban általában egy, vagy 2 vagy több van a redundancia miatt. Egy Service Domain mindig egy I/O domain, mert fizikai I/O erőforrásokat kell birtokolnia annak érdekében, hogy virtualizálni tudja őket a guest domaineknek. Guest domain: Egy domain akinek az eszközei vagy virtuálisak vagy fizikaiak: a virtuális hálózat és lemez eszközöket egy vagy több Service domain biztosítja. Bevett gyakorlatban ezt a domain típust használják az alkalmazások futtatására. Guest domain-ből általában több van egy rendszerben. 8

9 Rendelkezésre állás - Redundáns domain modell Szerverenként redundáns service egyben IO domainek A primary domain-ek látják el a control domain szerepét, azok leállása során az alternate domain veszi át a szerepet A service domain-ekben egy egy virtuális switch található, melyekhez IPMPvel (IP multi path) redundánsan kapcsolódnak a Guest LDOM-ok. 9

10 Rendelkezésre állás - Logical Domain Channel (LDC) Az Oracle VM for SPARC úgynevezett logical domain channel-t (LDC) használja a konzol, virtuális IO és az LDOMok vezérlésre. Egy LDC két végpont közötti kommunikáció egy módja. Általában két LDOM közti kommunikációt biztosítja, de lehetőséget ad ugyan azon LDOM-on belüli kommunikációra is lehetőséget biztosít (loopback). 10

11 Rendelkezésre állás és teljesítmény - SR-IOV virtualizáció A Single Root I/O Virtualization (SR-IOV) olyan szabványos Peripheral component interconnect express (PCIe) architektúra, amely PCIe specifikációkhoz határoz meg kiterjesztéseket, lehetővé téve ezzel a PCIe eszközök rendszeren belüli megosztását több logikai domaint futtatva egyidejűleg. Ez megoldás az LDC elkerülésével rövidebb várakozási időket és alacsonyabb CPU terhelést biztosít. 11

12 Rendelkezésre állás és a virtualizáció módjának meghatározása A Redundant SR-IOV Guest Domain model -t az adatbázis virtualizációjára javasoljuk, mert az IO virtualizációt (SR- IOV) hardver szinten valósítja meg, így jóval kevesebb virtualizációs veszteséggel jár az alkalmazása. Az alkalmazás környezetben az egyszerűbb Oracle VM Redundant Guest Domain model lett alkalmazva. 12

13 Rendelkezésre állás - Döntési szempontok Hiba esemény Leírás Gyakoriság szerverenként Hatás Kivédése IO kártya meghibásodása Szerver meghibásodása (CPU, memória) Guest és service domain patch és vagy kártya FW cseréje Bizonyos útvonalon nem lesz elérhető IO, később tervezetten leállás kell a cseréhez A leállást követően javítás befejezéséig nem lesz elérhető az adott szerver Tervezetten, az LDOM-okat újra kell indítani Több év Alacsony Root complex-enként szeparált redundáns konfiguráció, több portos kártyákkal Több év Közepes LDOM-ok újra indítása működőképes szerveren, az adatbázis szempontjából RAC klaszterrel védekezünk 3-6 hónap Magas, mert gyakori Részben lehet kivédeni a redundáns service domain alkalmazásával, így csak az alkalmazás guest domain-ek esetében van tényleges leállás, de lehetőség van tervezett RAC node leállásra Szerver FW frissítése Tervezett, de teljes szerver leállással jár 1-3 év Alacsony, mert tervezett Tervezetten fel lehet készülni a feladat elvégzésére 13

14 Erőforrások elosztása LDOM-on belül - Oracle Zones alapfogalmak A Solaris legegyszerűbb, és ezzel együtt legrugalmasabb operációs rendszerszintű virtualizációs megoldása a Solaris zónák. A zóna és a container kifejezést gyakran felcserélhetően használják; egy elterjedt definíció szerint a container kifejezés a zónákat és azok erőforrásmenedzsmentjét együttesen jelenti. Elérhető mind x86(_64), mind SPARC platformon. A bare metal vagy virtuális környezetben létrehozott LDOM OS installációt, vagyis a host OS-t global zone-nak nevezzük, míg a rajta futó zónákat non-global zone-nak. Az egy hoszton (GZ-n) futó zónák userspace-ei egymástól elszigetelve futnak, míg a global zone és az NGZ-ék kernelspace kódja közös (a fizikai hoszton csak egyetlen kernel fut). 14

15 Erőforrások elosztása LDOM-on belül - Oracle Zones alapfogalmak A virtualizáció egyik fő motivációja a hatékonyabb erőforráskihasználás. Mivel a Containers technológia operációs rendszer virtualizációs technológia, ezért az egyes zónák a telepítés és a futás során sokmindent örököl(het)nek az őket futtató global zone-től. A global zone-ből lehet delegálni erőforrásokat az egyes zónáknak. Az erőforrások lehetnek: Fizikai jellegűek: CPU-k, CPU-set-ek; memória, swap, locked memory; hálózati interface device (valamilyen hardware eszköz) Logikai jellegűek: ütemezési osztály (scheduling-class); lwps; brand 15

16 Biztonsággal kapcsolatos megfontolások Értékelések Szoftver Common Criteria FIPS Oracle Solaris 11.3 EAL4+ Igen Oracle Database 12cR1 EAL4+ (11gR2) Nem Weblogic Server 12cR2 EAL2 Igen (JDK) OHS 12cR2 Nincs Igen Biztonsági tervezés alapelvei Hálózati szegmentáció kommunikáció típusa (admin, szolgáltatás, ) és a környezetek típusa között (ÉLES, TESZT, ) A platformon belül minden komponens között TLS kommunikáció, amit a HW gyorsító áramkörökkel támogat Az OTP Bank belső szabályozása felhasználásával CIS (Center for Internet Security) benchmark-ok felhasználásával, konkrét ellenőrző/beállító scriptek késztése 16

17 Kialakított virtualizált ÉLES és DEV környezet Két telephelyen vannak elhelyezve a szerverek melyeken belül vannak a virtuális RAC node-ok és más adatbázis környezetek kialakítva, melyek a SR-IOV virtuális adaptereken keresztül érik el diszkeket. Az Oracle adatbázis esetében nincs kiterjesztett működés; az éles adatbázis Lajos utcában, míg a tartalék adatbázis a Babér utcában fog elhelyezkedni. Köztük katasztrófa tűréshez szükséges adatok átviteléről az adatbázis Data Guard szolgáltatása gondoskodik. 17

18 Kialakított virtualizált Data Guard és teszt, statisztikai és archív környezetek Az adatbázis LDOM-ok szemben az alkalmazás LDOM-okkal nem mozognak sem a szerver sem a telephelyek között. Az LDOM-ok a megfelelő teljesítményt nyújtásának érdekében katasztrófa helyzetben természetesen átméretezhetők. A DR szituációban a Data Guard-t futtató LDOM-ok CPU mag száma 4-ről 12-re növelhető, miután a PREP és a TST1, TST2 környezeteket leállnak, illetve a STAT és a ARCH környezettől 2 2 CPU (core) elvételre kerül. 18

19 Weblogic éles környezetek két telephelyen Világos kék szín jelöli az éles LDOMokat Az egyes színek a Weblogic klasztereket, illetve admin szervereket jelölik A zónák Exclusive IP típusúak, így zóna szinten is megvalósul a hálózati szegmentáció A zónák nem mozognak az LDOM-ok között A Weblogic klaszterek egyes tagjai eltérő telephelyen futnak Több mint 30 zóna lett kialakítva A zónákon a következő korlátokat (capping) állítottuk be: CPU Virtuális memória Fizikai memória 19

20 Adatbázis - Teljesítmény összehasonlítás 62% csökkent a Oracle licence igény SQL hangolással még mindig van lehetőség a CPU terhelés csökkentésére Az alkalmazás háttérfolyamatainak optimalizálásával még tovább csökkenthető a terhelés, igazodva a gyorsabb CPU magokhoz Mivel virtuális a szerver környezet így a CPU szám tovább csökkenthető szemben a fizikai szerverrel 1st (T4-4) 2nd (S7-2L) Diff %Diff Number of CPU Threads: Number of CPU Cores: Number of CPU Sockets: Physical Memory: M M M 25.2 Load at Start Snapshot: 35,84 8,68-27, Load at End Snapshot: 11,15 4, %User Time: 4,44 6,89 2, %System Time: 2,85 1,59-1, %Idle Time: 92,71 91,53-1, %IO Wait Time:

21 Weblogic - Teljesítmény összehasonlítás JMeter scriptek lettek fejlesztve a teljesítmény teszteléshez Kétféle script készült: Háttér folyamatok tesztelésére End to End folyamatok tesztelése Az adatbázis további hangolására szükséges volt Az eredeti tervekhez képest az LDOM (magok száma) és zóna CPU (capping) paramétereket csökkenteni kellett Teljesítmény tesztelés célja, hogy a 1.8 Java (GC, String Deduplication) beállítások és Weblogic Server paraméterek beállítása Az alkalmazás háttérfolyamatainak optimalizálásával még tovább csökkenthető a terhelés, igazodva a gyorsabb CPU magokhoz Speciális tranzakció csoportokra 3-5 szeres volt a teljesítmény növekedés a biztonsági beállításokkal együtt Még nincs élesítve az alkalmazás réteg, hamarosan üzembe fog állni 21

22 Kérdések és válaszok? 22