![Virtualized platform migration on a validated system GAZDAG, Ferenc Head of IT operation EGIS Nyrt. [email_address] SAP World Tour ‘09 Siófok, 2009. szeptember 13-15. 1/130](https://image.slidesharecdn.com/virtualizedplatformmigrationonavalidatedsystem-12640228949998-phpapp01/85/Virtualized-Platform-Migration-On-A-Validated-System-1-320.jpg)
![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (16)
Similar a Virtualized Platform Migration On A Validated System
Similar a Virtualized Platform Migration On A Validated System (20)
Más de gazdagf
Virtualized Platform Migration On A Validated System
- 1. Virtualized platform migration on a validated system GAZDAG, Ferenc Head of IT operation EGIS Nyrt. [email_address] SAP World Tour ‘09 Siófok, 2009. szeptember 13-15. 1/130
- 8. QA in virtual systems Virtual infrastructure Qualification of virtual template(s) Qualification of virtual platform Validation of application Virtual machine Application OS Virtual machine Application OS Virtual machine Application OS Virtual machine Application OS Virtual machine Application OS Virtual machine Application OS Virtual template OS Virtual machine Application OS
- 10. Planned architecture 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. Implemented architecture 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
- 14. Reaction time of SAP
- 23. Thank you for your attention! GAZDAG Ferenc Head of IT Operation EGIS Plc. [email_address]
Notas del editor
- 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 Virtual 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 Virtual 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. Virtualan 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 Applicationokat mindkét esetben ugyanolyan erőforrás felhasználással validálni kell, de Applicationt 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 Virtual felhőben képzeltük el, amiben az EGISnél használt egyéb (azaz az összes) Application 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 Virtual 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 Applicationok a Virtual rendszer által kínált fájlrendszerben foglalna helyet. három különböző Virtual 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 – Virtual á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 Application maradt a Virtual 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 – Virtual á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 – Applicationtól függő idejű– validáció követett, addig a Virtual világban egyszer kell a kéthetes alapkvalifikációt megcsinálni, amit a Virtual sablonok (nálunk ebből kb 7 darab van) követ. A sablonokból készítünk machineeket, 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 Applicationtó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 Virtual számítási felhőt a budapesti machinetermek 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ő Virtual rendszerein támogatott.
- S egy összefoglalás: a platformváltás, mint projekt, egyike volt az EGIS informatikai legsikeresebb projektjeinek elmondható, hogy a Virtual 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!