1. Virtuális platformváltás validált környezetben GAZDAG Ferenc IT Üzemeltetési osztályvezető EGIS Nyrt. [email_address] SAP World Tour ‘09 Siófok, 2009. szeptember 13-15. 1/130
2.
3.
4.
5.
6.
7.
8. Minőségbiztosítás virtuális rendszereknél Virtuális infrastruktúra Virtuális sablon(ok) kvalifikálása Virtuális platform kvalifikálása Alkalmazás validálás Virtuális gép Alkalmazás Oprendszer Virtuális gép Alkalmazás Oprendszer Virtuális gép Alkalmazás Oprendszer Virtuális gép Alkalmazás Oprendszer Virtuális gép Alkalmazás Oprendszer Virtuális gép Alkalmazás Oprendszer Virtuális sablon Oprendszer Virtuális gép Alkalmazás Oprendszer
10. Tervezett architektúra SAP P DB SAP Q DI SAP Q CI SAP Q DB SAP P DI SAP P CI SAP D1 DB, CI SAP D2 DB, CI Exchange SAP D3 DB, CI DC PORTAL vCenter Empower Citrix Q OS VMFS P OS VMFS Q DB RDM P DB RDM D2 OS,DB VMFS D2 OS,DB VMFS D1 OS,DB VMFS D1 OS, DB VMFS
11. Megvalósult architektúra SAP Q DB SAP Q DI SAP Q CI SAP P DB SAP P DI SAP P CI SAP D1 DB, CI SAP D2 DB, CI Exchange SAP D3 DB, CI DC PORTAL vCenter Empower Citrix Q OS VMFS, APP RDM P OS VMFS, APP RDM Q DB RDM P DB RDM D2 OS,DB VMFS D2 OS,DB VMFS D1 OS,DB VMFS D1 OS, DB VMFS
Tisztelt Hölgyei és Uram! Köszönöm a szót és köszönöm a meghívást, hogy részt vehetek ezen a konferencián. Gazdag Ferenc vagyok, az EGIS Nyrt IT üzemeltetési osztályvezetője. A következő néhány dián az EGIS Nyrt SAP platformváltásáról szeretnék egy áttekintést adni. Ebéd előtt ez egy kicsit hálátlan feladat, így próbálom a lehető leggyorsabban lepörgetni a 130 diát – ami persze csak viccként van kint.
Íme a témák, amivel foglalkozni fogok.
Ez a kötelező kommunikációs dia, technikai szempontból a 4 magyarországi telephelyet és a 20 nemzetközi irodát, leányvállalatot emelném ki.
A platformváltáshoz vezető út az azt futtató infrastruktúra technikai elavulásával kezdődött. Amikor vizsgáltuk, hogy hova is mehetnénk. Az alapgondolat a virtualizálás volt, azonban ezzel volt (és van) jelenleg is némi probléma. Az Oracle jelen pillanatig nem támogatja rendszereinek éles üzemét nem általa gyártott virtuális rendszerben. Valószínű emiatt sem találtunk a mienkhez hasonló rendszert virtualizálva, így mérvadó referencia nélkül kezdtünk bele a projektbe.
Itt láthatók a projekt hardver résztvevői. A régi Alpha ES45 és az új IBM penge. Az SAP teljesítményt leíró szám, a SAPS érték szerint e két vas között nagyjából 6x sebességkülönbség van. Látható, hogy a komponensekből mit mire terveztünk cserélni. Egyedüli új elemként a virtualizációs réteg jelent meg az architektúrában.
A projekt humán oldali résztvevői. Meglepő módon, a projekt fővállalkozója az SAP HUngary Kft volt (nem bántuk meg a döntést). Viszont mivel az alap infrastruktúrához annyira nem értett, ezért a HUMANsoft Kft-t kértük fel a projekt infrastruktúra igényeinek ksizolgálására. A projekt során az EGIS Nyrt. SAP üzemeltetést támogató cége adta a minőségbiztosításhoz és az ellenőrző feladatokhoz az erőforrásokat. A referencialátogatásokból kettőt emelnék ki, akik nagyon sokat segítettek nekünk. Ezúton is nagyon köszönjük a BorsodChem informatikai főosztályának a részletekbe is lemenő bemutatót, nagyon sokat tanultunk belőle. A másik egy CrossIT nevű osztrák cég (ilyen apróságokkal foglalkozik mint ÖMV), aki a virtualizácó SAP, Oracle oldali támogatását ismertette és mutatta be nekünk.
Az EGIS Nyrt., mint gyógyszergyár nagyon sok energiát fektet a megfelelő minőség fenntartására, s ehhez egy jól működő minőségbiztosítás kell. S ebből az informatikának is ki kell vennie a részét.
Röviden összefoglalva a virtuális rendszerek minőségbiztosítását, az mondható, hogy ebben a részben is jelentős áttérést ért el a virtualizáció. A fizikai világban az alapinfrastruktúrát, az egyedi szervereket és operációs rendszereket kell kvailfikálni. Virtuálisan sem ússzuk meg a rendszer-kvalifikációt, azonban ezt csak egyszer kell megcsinálni minden rajta lévő rendszerrel. Ugyanígy az alap sablonokat is csak egyszer kell kvalifikálni, s az egyediesítést követően akutalizálni. Az alkalmazásokat mindkét esetben ugyanolyan erőforrás felhasználással validálni kell, de alkalmazást talán kevesebbszer cserél az ember mint vasat
Ez a régi architektúra vázlata. Amit kiemelnék, hogy egy-egy vas több fejlesztői rendszert is futtatott, a vasak nem azonos képességűek voltak (még az éles és a teszt sem), a fejlesztői rendszerek teljesítménye pedig erősen elmaradt az élestől.
A tervezett architektúrát egy virtuális felhőben képzeltük el, amiben az EGISnél használt egyéb (azaz az összes) alkalmazás is helyt kapna: a központi portáltól a Citrix kiszolgálókon és az Exchange szerveren át a mérőberendezéseket kiszolgáló Empower szerverekig. Ezen a felhőn belül az SAP egy „alfelhőt” képezne, azaz más nem tudná az alfelhő működését megzavarni, de bármilyen hiba esetén az SAP virtuális szerverei kiléphetnének a nagy felhőbe. Az éles és a minőségbiztosító trendszer tökéletes azonos konfigurációban épülne fel, ahol a minél nagyobb teljesítmény miatt az adatbázis közvetlenül a tárolón lenne (Raw Device Mapping), míg az operációs rendszer és az alkalmazások a virtuális rendszer által kínált fájlrendszerben foglalna helyet. három különböző virtuális szerveren. A fejlesztői rendszerek esetében mindent egybegyúrnánk, hiszen ezek nem annyira teljesítménykritikus rendszerek. Az RDM lemezelérés nemcsak a teljesítmény fokozására való, hanem ezzel oldható meg az a feladat is, amit az SAP is javasolt virtualizáció esetére, hogy az Oracle DB visszaállítható fizikai vasról való futásra.
A megvalósult architektúra egy kicsit tért el a tervezettől, a dedikált pengék közti kevert rendszerek a hálózati lassúság miatt inkább egy pengére kerültek – a hálózati fejlesztés, átállás 10 GbE még nem készült el erre az időre, míg a fizikai – virtuális átállás gyorsítása miatt az adatbázis kezelő és az SAP komponensei közvetlen elérésű lemezeken kaptak helyet, míg az operációs rendszer és SAP alkalmazás maradt a virtuális rendszer fájlrendszerén.
További hasznos elemei a megvalósult architektúrának, hogy elkészítettük a fejlesztő rendszerek sablonjait, így kb 2 nap alatt tudunk új fejlesztő rendszert létrehozni, nagyjából 6 emberóra befektetésével. S természetesen előkészítettük a hibakeresésre illetve az Oracle támogatásra a rendszer fizikai – virtuális átállását, mind az éles, mind a minőségbiztosító rendszerben. Tesztek szerint egy szabályosan leállt rendszer kb 16 perc alatt állítható át és indítható el újra.
És az eredmények: A vas nyers ereje hatszorosára nőtt, azonban az új pengében lévő 8 processzorból 4-et kapott az adatbázis és 4-et a centrális és a dialógus instancia. A VMware saját állítása szerint adatbázis kezelők virtualizációja esetében 15% overheaddel ajánlott számolni a méretezésénél. Ezeket összevetve szűk háromszoros sebességnövekedést vártunk az éles rendszernél, míg a minőségbiztosító és a fejlesztői rendszereknél ennél sokkal jelentősebbet. A projekt hivatalos indulása 2009. április 27-én volt, s másnaptól már neki is estünk az átállásnak. Az új platformon az éles indulás 2009. július 6-án, hétfő reggel 6-kor volt. (Selmeci Attilával együtt néztük az irodámból a napfelkeltét). Az elmúlt két hónapban csak pozitív tapasztalatunk volt,a felhasználók jelentős teljesítményjavulásról számoltak be, a jobok futása jelentősen felgyorsult.
Válaszidő változása a platformváltás előtt és után
A SAP honlapján olvastam, hogy a SAP elnyerte ezzel a konferenciasorozattal a Zöld fesztivált díjat. Gratulálok a szervezőknek ezért. Az EGIS NYrt-nek is nagyon fontos a környezetvédelem, nézzük, hogy az informatika milyen rendszerekkel tud ehhez hozzájárulni.
Elsőként vegyük a tárolókat. Nem szép dolog egymástól majdnem 10 évre lévő technológiákat összehasonlítani, azonban nem termékmarketinget szeretnék itt tartani, hanem a fejlesztésből adódó nyereségeket. Sokáig kerestem a megfelelő mérőszámot, amivel leírható a javulás, végül az összeg/GB mértékegységnél maradtam. Ennyibe kerül az adott nagyságú terület technikai üzemeltetése.
Azonban ha bekapcsoljuk a NetApp deduplikációs eljárását – ezt nagyon ajánlom mindenkinek, azonban használatát csak erősebb kontrollereken ajánlom, akkor a NetApp önmagához képest jelentős zöldülést mutat. Az EGISben jelenleg rendelkezésre álló 22 TB tárolókapacitáson majdnem 30 TB-t tárolunk. Észrevehető teljesítmény vesztés nélkül.
Mi is ez a deduplikáció? Mind a neve mutatja, a tárolón előforduló többszörös azonosságokat gyűjti ki, s csökkenti a tároló igényt. Virtualizációhoz, megfelelő szervezéssel, erősen javaslom. Nézzük egy példát az mi fejlesztő rendszereinken. Ezek egy kötetre vannak gyűjtve, egy SAP fejlesztői rendszer 800 GB tárhelyet foglal. Az első ennyit is foglalt. Azonban ahogy tettük mellé a többit, az elfoglalt terület nem nőtt arányosan. Sőt, elmondható, hogy minél több rendszert teszünk rá, annál hatékonyabb a tárolás. Sajnos, a D1 szerver egy nagyon régi, majdnem 2 éves adatbázist tartalmaz, így ez nem deduplikálható hatékonyan, de a négy fejlesztői rendszer így is 3200 GB helyett mindösszesen 1600 GB helyet foglal el.
A VMware, mint virtualizációs réteg hatékonyságáról elég sokat lehetett hallani, így csak néhány főbb pontot emelnék ki. Az EGIS szerverparkjában bekövetkező virtualizáció után a szerverek üzemeltetéséhez szükséges teljesítmény ára igen jelentősen, mintegy harmadára csökken. Ezzel 10 MFt-t tudunk évente megtakarítani. A szünetmentesünk megvan, így ennek beszerzésén már nem tudunk spórolni, azonban szolgáltatási szintként az eddigi áthidalási idők mintegy háromszorosára nőnek. Ezeken felül a teljes központi infrastruktúra, mentőrendszerrel együtt elfér egyetlen rackszekrényben, egy másikban meg a tároló, így jelentős helymegtakarítás érhető el, s nem mellesleg áttekinthetőbb lesz a kábelezés. A felhasználói vagy informatikai fejlesztői igényeket is sokkal jobban tudjuk kiszolgálni. Szélsőséges esetben az este hatkor leadott „szerverrendelést” másnap reggel 8-ra tudjuk teljesíteni.
A minőségbiztosítás és a dokumentáció nem az informatikai üzemeltetők kedvenc témája. Azonban a virtualizációval ez a teher is jelentősen csökkenthető. Míg a fizikai világban egy rendszer virtualizációja nagyjából két hétig tartott, amit egy – alkalmazástól függő idejű– validáció követett, addig a virtuális világban egyszer kell a kéthetes alapkvalifikációt megcsinálni, amit a virtuális sablonok (nálunk ebből kb 7 darab van) követ. A sablonokból készítünk gépeket, ezek egyediesítése utáni ellenőrzésére 1 napot még szánnunk kell. S természetesen itt is validálni kell, ami alkalmazástól függ. Elképzelhető, hogy egy gyógyszergyár esetén ez mekkora időnyereséget okoz, mivel legalább 30 validált rendszerünk van, aminek az infrastruktúra részét kvalifikálni kell. Az SAP esetében ez 132 munkanap helyett 34 munkanapot vesz igénybe.
A jövőben szeretnénk az üzemmenet folytonosságot tovább növelni, ennek egyik lehetséges megoldása a NetApp metroclsuter kialakítása. SAP archiválásra a jelenlegi eszközt tervezzük lecserélni – mivel nem virtuálizálhat – egy SnapLock funkcióval ellátott tárolóra. A tárolás hatékonyságának további növelésére a FlexVol funkciót tervezzük használni, míg a rendszermásolásokra az erre épülő SnapManagert (for VI és for SAP). A jelenleg a telephelyekre zárt virtuális számítási felhőt a budapesti géptermek között megvalósított közvetlen sötétszálas összeköttetéseken alapulva vállalati felhővé fogjuk alakítani, ami mind a BCP, mint a DR támogatja. SAP szinten tervezzük a verzióváltást ECC 6.0-ra, áttérést az UniCodere és lehetőleg olyan adatbázisra – ez egy üzenet az Oracle vezetőségének -, ami a piac vezető virtuális rendszerein támogatott.
S egy összefoglalás: a platformváltás, mint projekt, egyike volt az EGIS informatikai legsikeresebb projektjeinek elmondható, hogy a virtuális platform stabil és megfelelő teljesítménymutatókkal rendelkezilk az üzemeltetés hatékonyságát növeli s mint látható, sokkal több, egyéb feladatra vagyok alkalmas ezekután!
![Virtuális platformváltás validált környezetben GAZDAG Ferenc IT Üzemeltetési osztályvezető EGIS Nyrt. [email_address] SAP World Tour ‘09 Siófok, 2009. szeptember 13-15. 1/130](https://image.slidesharecdn.com/virtulisplatformvltsvalidltkrnyezetben-12640230204974-phpapp02/85/Virtualis-Platformvaltas-validalt-kornyezetben-1-320.jpg)
![Témák ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)