User:Mrajur

Erialatutvustuse aine arvestustöö

Autor: Martin Rajur
Esitamise kuupäev: 01. november 2011

Essee

Süsteemi muutmine kõrgkäideldavaks SAP näitel.

Tänapäeval on järjest kasvava käideldavuse nõudluse tõttu muutunud tähtsamaks süsteemide kättesaadavus. Seetõttu peab järjest enam pöörama tähelepanu it süsteemide katkematule tööle. Selleks, et seda saavutada, rakendatakse erinevaid meetmeid. Antud essee teema ongi, kuidas kõrgkäideldavust saavutada ning millisena võiks süsteemi üleviimine kõrgkäideldavaks toimuda.

Iga õige projekt algab analüüsiga ning seetõttu on tähtis süsteemi puhul ära määratleda, millised on antud süsteemi nõuded. Esiteks tuleks selgitada, millised osad süsteemist on kõige kriitilisemad ja välja selgitada potentsiaalsed veakohad (SPOF/Single point of failured). Kui esialgne analüüs on tehtud, saab edasi otsustada, millised sammud on järgnevalt vajalikud. Kuna HA(High availability – kõrgkäideldav) süsteemid on muutumas järjest tavalisemaks, on õnneks olemas ka Best Practice juhendid, mida tuleks siiski võtta soovitusena. See, milline antud projektile sobib, tuleb ikkagi igal administraatoril ise välja mõelda. SAP puhul peetakse HA süsteemideks süsteeme, mille uptime peab olema >99.9% ning seetõttu rakendatakse seda üldiselt vaid toodang süsteemidele ja sealgi vaid neile, mis tõesti ärikriitilised on.

Kui on teada, milliste süsteemide puhul on kõrgkäideldavus vajalik, tuleks järgmisena analüüsida, kuidas on võimalik süsteemi komponente täiustada ja dubleerida nii, et saavutada vajalik tõrkekindlust. SAP süsteemid tavaliselt koosnevad ühest serverist, kus on koos nii andmebaas kui ka applikatsiooniserver. Sellisel kujul ei ole süsteem kindlasti kõrgkäideldav, sest ta on haavatav erinevate tõrgete poolt. Kui peaks juhtuma, et ühe masinaga midagi juhtub, on kohe kogu süsteem maas ja ei ole kasutatav. Selleks, et seda vältida ning saavutada katkematu töö, lüüakse serveri osad lahku. Sap-i puhul eristatakse kolme tüüpi servereid.

Esimene serveri tüüp on lukuserver (load balancer). Selleks, et tagada kõrgem tõrkekindlus, on lukuserver löödud andmebaasist lahku ja selle juurde tekitatud replikatsiooni teenus. Antud serveri eesmärgid on pidada andmebaasi lukutabelit, replikatsiooni protsess, mis hoiab antud lukutabelit ka secondary serveris ning lisaks sellele suudab see server tegeleda ka koormuse jaotamisega. Kui klient soovib ligipääsu süsteemi, võtab ta kõigepealt ühendust lukuserveriga, kust ta ühendatakse edasi applikatsiooniserverisse. Antud süsteem on eriti tõhus juhul, kui on kasutusel mitmeid servereid ning seeläbi on võimalik koormust hajutada, et ei tekiks olukordi, kus üks server on ülekoormatud, kui teised samal ajal nö jalgu kõlgutavad. Kuna selline süsteem on lihtne, on võimalik kasutada odavamaid servereid ning seeläbi investeeringutelt kokku hoida.

Teine serveri tüüp on andmebaas. Andmebaasi eraldamine annab selle, et on võimalik baasi hoida eraldi ning tõrke tekke korral on maas ainult üks süsteem. Juhul kui baas kukub, jäävad lukuserver ja applikatsiooniserver ning lülitudes üle teisele süsteemile on võimalik jätkata eelnevat tööd vähese katkestusega. Testid on näidanud, et juhul, kui andmebaas hetkeks maha võtta ja hiljem üles tõsta, jätkub eelnev töö katkestusteta. Kasutajatel on mõnda aega viivitus, kuid see on kõik, mida nad tajuvad. Lisaks sellele on baasi eraldamise juures see hea asi, et süsteem on võimalik seadistada ainult baasi nõudeid silmas pidades, ei ole enam vaja juurde arvestada, kas applikatsioon seal ka jooksma mahub ning ka failoverit on lihtsam selliselt teha. Andmebaasi puhul kasutan Oraclet ning selleks, et baase kogu aeg syncis hoida kasutame dataguardi.

Kolmas serveritüüp on applikatsiooniserver. Erinevus eelnevate süsteemidega applikatsiooniserveri puhul on see, et siin ei ole tähtis üksiku applikatsiooniserveri toimimine. Kuna kasutusel on mitmeid applikatsiooniservereid, ei ole hullu, kui üks neist ära sureb. Kasutajatel küll ühendus kaob, kuna server ei ole enam kasutatav, kuid süsteem tervikuna jääb siiski kasutatavaks. Siin on üks suur pluss veel- skaleeritavus. Juhul, kui ma tunnen, et kasutajatel jääb serveri võimsusest väheseks, on võimalik lihtsa vaevaga lisada juurde uusi applikatsiooniservereid ilma süsteemile katkestust tegemata. Samuti on sellise süsteemi puhul võimalik lihtsalt reserveerida serverpoolis olevaid servereid ainult teatud kasutajatele. See lähenemine on eriti hea perioodide lõpetamisel, kui tehakse suuremaid raporteid ja päringuid. Kui sellised kasutajad panna eraldi serverisse, on võimalik, et isegi kui nende päringud muutuvad süsteemile väga koormavaks, on ülejäänud kasutajad teistes serverites, kus töö on normaalse kiirusega ning seeläbi süsteemi käideldavus ei kannata.

Lisaks eelnevale on kõrgkäideldaval süsteemil veel plusse, mis on samad üle kõikide masinate. Juhul kui administraatoritel on vaja teha hooldustöid, on võimalik lihtsa vaevaga süsteeme ümber lülitada ning samal ajal primary servereid restartida ja uuendada ilma süsteemi üldist tööd häirimata. Selle abil on lõpuks ometi võimalik, et administraatorid ei pea öösel 00-04 vahemikus servereid uuendama ja restartima, vaid saavad ka magada. Lisaks süsteemide kõrgkäideldavaks muutmisele tuleb kindlasti ka üle vaadata kogu infrastruktuur. Praktika on näidanud, et kõige tähtsam on kõiki süsteeme enne toodangusse viimist korduvalt testida, ning testima peaks pikalt ja põhjalikult. Paljud administraatorid ei pea vajalikuks stresstestide jooksutamist rohkem kui 1-2 tsüklit, aga reaalsuses ei tule 1-2 tsükli peale vead välja ning seetõttu on pikem testimine vajalik.

Tänapäeva järjest kasvavas Internetiteenuste maailmas on väga tähtsaks muutunud, et kõik süsteemid ja teenused oleks kogu aeg kättesaadavad. Seetõttu on järjest enam süsteeme muutumas kõrgkäideldavaks. Juhul, kui eelnev kogemus sellist tüüpi projektidega puudub, soovitan kindlasti osta konsultatsiooniteenust kuskilt väljastpoolt sisse, ning karta ei tohiks spetsialiste välismaalt. Kohati võib olla raske selgitada, milleks selliseid väljaminekuid vaja on, kuna sellise lahenduse puhul on infrastruktuuri ja litsentside kulutused päris suured, kuid projekti algfaasis tuleb kindlasti kõrvale tuua ka süsteemi maasolekust tingitud saamata jääv tulu ja tekkiv kulu.

Õpingukorralduse küsimused

Küsimus A

Kukkusid eksamil läbi. Kuidas edasi? Kaua on võimalik eksamit teha? Kellega kokkuleppida, et eksamit teha? Kuidas toimub järeleksamile registreerimine? Mis on tähtajad? Palju maksab, kui oled riigieelarvelisel (RE) kohal? Palju maksab, kui oled riigieelarvevälisel (REV) kohal?

Vastus

Eksamit on võimalik uuesti sooritada kahe semestri jooksul peale aine õpetamissemestri lõppu. Õppur peab registreerima ennast korduseksamile õppeosakonnas. Õppur peab olema eksamile registreerunud ja kordussoorituse puhul tasunud tasu hiljemalt üleeelmise tööpäeva lõpuks arvestatuna eksami toimumise päevast. Juhul kui õpid RE kohal siis on korduseksam tasuta, REV kohal õppides kehtestatakse tasu suurus rektori käskkirjaga.

Küsimus 4

Millised võimalused on minna akadeemilisele puhkusele esimesel õppeaastal? Mis tegevused tuleb selleks teha? Kui pikk on maksimaalne puhkuse aeg? Kuidas toimub puhkuse lõpetamine? Kas puhkuse ajal saab deklareerida õppeaineid? Kas saab teha järele eksameid ja arvestusi?

Vastus

Esimesel õppeaastal saab akadeemilisele puhkusele minna tervislikel põhjustel (koos meditsiiniasutuse tõendiga kus on märgitud arsti soovitus akadeemilise puhkuse osas ja akadeemilise puhkuse soovitatav periood, kuni 2 aastat), Eesti kaitsejõududesse teenima astumisel (vajalik kutse kaitseväe tegevteenistusse, kuni 1 aasta), Lapse hooldamiseks (lisama peab lapse sünnitunnistuse, kuni 3 aastat). Muudel põhjustel kuni üheks aastaks lubatakse minna ainult alates teisest õpiaastast ja juhul kui avaldus esitatakse enne punase joone päeva. Akadeemilise puhkuse ajal ei ole võimalik sooritada arvestusi ja eksameid. punkti 5.2.8.2 järgi on võimalik akadeemilisel puhkusel oleval õpilasel teha järelarvestusi/eksameid kuid seda lisatasu eest mis on sätestatud punktis 5.2.7