13.1.5 Egyéb telepítési lépések 13.1.5.1 Tűzfal beállítások A PVSR helyes működéséhez az alábbi kapcsolatokat kell beállítani a rendszer komponensei közötti tűzfalakon: Honnan | Hova | Port | PVSR szerverek (mindegyik modult futtató szerver, beleértve a WEB felületet és az adatgyűjtő komponenseket is) | PVSR Oracle szervere | Oracle SQL*Net (alapesetben TCP 1521) | PVSR SQLLDR komponenst futtató gép | PVSR adatgyűjtő szerverek | SSH és SFTP (TCP 22) | PVSR alkalmazás manager komponenst futtató gép | PVSR szerverek (mindegyik modult futtató szerver, beleértve a WEB felületet és az adatgyűjtő komponenseket is) | SSH (TCP 22) | PVSR adatgyűjtő szerverek | Hozzá tartozó threshold feldolgozó | Threshold feldolgozónál beállított UDP vagy TCP port | Felhasználói gépek | PVSR WEB szerver | HTTP és/vagy HTTPS (alapesetben TCP 80 és 443) | PVSR WEB szerver | PVSR adatgyűjtő szerverek | SSH (TCP 22) | PVSR WEB szerver | PVSR WEB szerver | Chart szerver portja, alapesetben TCP 4444 A chart szerver modulnak minden esetben a WEB szerveren kell elhelyezkednie, így a kapcsolat csak lokálisan kell hogy felépíthető legyen | SOAP interfészt használó gépek | PVSR SOAP modul szervere | SOAP szerver portja, alapesetben TCP 8082 | SNMP Trap-eket küldő eszközök | PVSR Trap/Syslog modul szervere | SNMP Trap port (alapesetben UDP 162) | Syslog-okat küldő eszközök | PVSR Trap/Syslog modul szervere | Syslog port (alapesetben UDP 514) | PVSR alkalmazás manager és SQLLDR modul szervere | SMTP szerver | SMTP port (TPC 25) | PVSR SNMP, IPSec, Cisco QoS, Cisco PING és Cisco SAA mérő szerver | Mért eszközök | SNMP port (UDP 161) Cisco PING esetében read-write, Cisco SAA esetében opcionálisan read-write jogosultsággal | PVSR Jaga mérő szerver | Mért eszközök | ICMP Echo (ping) | PVSR Unix/Linux mérő szerver | Mért eszközök | SSH (TCP 22) | PVSR Oracle mérő szerver | Mért eszközök | Oracle SQL*Net (alapesetben TCP 1521) | Mért eszközök | PVSR Netflow mérő szerver | UDP 9996 | PVSR Szintetikus tranzakciók mérő szerver | Mért eszközök | A végzett mérésektől függően: - HTTP (alapesetben TCP 80)
- HTTPS (alapesetben TCP 443)
- DNS (UDP 53)
- SMTP (TCP 25)
- POP3 (TCP 110)
- BOOTPS (UDP 67)
- NTP (UDP 123)
- SSH (TCP 22)
- TCP mérések: a megadott TCP port
- RADIUS (UDP 1812 vagy UDP 1645)
- LDAP (alapesetben TCP 389)
| 13.1.5.2 Adatbázis méretezés Az installálás egyik első lépése az adatbázis séma létrehozása az Oracle adatbázisban. A szükséges paramétereket a define.sql file tartalmazza. Ezeket két részre lehet osztani: tablespace konfiguráció és tábla illetve partíció méret konfiguráció. Tablespace Az alkalmazás opcionálisan két külön tablespace-t képes használni: egyet a konfigurációs táblák (pvsr_conf_data_tablespace) és egyet a mérési eredmények (pvsr_res_data_tablespace) számára. A mérési adatokat az alkalmazás ún. IOT-kben, azaz Index Organized Table-ekben tárolja, ami azt jelenti, hogy nincsen külön index és adat tárolás, ezért nincsen külön index tablespace. A tablespace-ek esetében kétféle konfiguráció támogatott (bővebben lásd Oracle 9i Database Concepts): - lokálisan menedzselt, uniform extent méretekkel rendelkezően
- adatszótárban menedzselt, ugyanakkora default INITIAL és NEXT értékekkel
Mindkét esetben az adatbázisban található tábla adattárolási egységek – az ún. extent-ek –ugyanakkora méretűek lesznek. Ez azért lényeges az alkalmazás számára, hogy a törölt mérési adatokkal opcionálisan felszabadítható területek újbóli kiosztása minél kisebb terhelést jelentsen az adatbázis számára. A táblák, illetve partíciók méretét lényegesen meghatározza a fent említett egységes extent méret. Az ajánlás az alábbiak szerint alakul a tablespace és az opcionális partícionálás használatától: - konfigurációt tároló tablespace: az itt tárolt adatok mérete elhanyagolható a mérési eredmények tárolására szolgáló tábláktól, ezért használható alacsony (pl 32-64K) érték
- mérési eredményeket tároló tablespace:
- partícionálás opció esetében: a tervezett partíció méretek legnagyobb közös osztóját válasszuk, hogy minél ritkábban kerüljön sor új extentek létrehozására. Figyelem: egy extentbe csak egy partíció adatai kerülnek, tehát irreálisan nagy extent méret olyan üres helyeket fog eredményezni, amiket az alkalmazás nem fog majd tudni felhasználni. A kezdeti installálás után lehetőség van arra, hogy az egyes partíciókat az alkalmazás a későbbiekben másik tablespace-ben hozza létre, külön-külön mindegyik táblára megadhatóan. Ha valamelyik opciót nem kívánjuk használni (például threshold riasztások), akkor azokat ajánlott külön tablespace-ben létrehozatni kis mérettel. Tipikus értékek: 128-512K
- partícionálás nélküli esetben: ez esetben nyugodtan megadhatunk nagyobb értéket is, mivel nem keletkezik többszörösen nem felhasználható terület. Tipikus érték 1M-10M
Tábla vagy partíció méretek A további paraméterek jelentése attól függ, hogy az alkalmazást partícionált vagy normál táblákkal használjuk: - Normál táblák esetében: A paraméterek a tábla kezdeti méretét határozzák meg
- Partícionált táblák esetében: A paraméterek az újonnan létrejövő partíciók alap méretét határozzák meg. Az installálás során ezek alapján töltődik fel az adatbázisban található PVSR_RES_PART nevű tábla, és a későbbiekben az ott tárolt adatok alapján jönnek létre az új partíciók. Ha változtatni akarunk az installálás után valamikor a define.sql-ben beállított értékeken, akkor a TABLE_NAME oszlopban található táblanévnek megfelelő sorokban kell módosítani a MINEXTENTS_NUMBER és a TBS_NAME paramétereket
Mivel partícionált esetben bizonyos időközönként új partíció keletkezik, ezért a méretezést ilyenkor ennek figyelembe vételével kell megtenni, törekedve nem csak a minél kevésbé fragmentált táblák kialakítására, hanem a kihasználatlanul maradt partíció területek csökkentésére is. Az egyes időközök az alábbi táblázatban és a define.sql file-ban is órákban vannak megadva. Minden táblához egy paraméter tartozik: …_minext, ami a kezdeti esetben lefoglalandó extent-ek számát határozza meg. Paraméter neve | Idő | Leírás | mon_res | 4 | A részletes mérési eredményeket tároló tábla, egy mérés kb ~40 byte felhasználást jelent, amennyiben direkt betöltéssel kerülnek be az adatok, és ~52 byte felhasználást, amennyiben nem direkt betöltéssel kerülnek be az adatok | mon_res_arch | 4 | A részletes mérési eredményeket tároló archív tábla, ahova a MOVE_MON_RES konfigurációs paraméternek megfelelő nap után kerülnek a mérések. Egy mérés kb ~40 byte felhasználást jelent | mon_res_daily | 24 | A részletes mérési eredményekből számított órás átlagokat tároló tábla (Hány napig őrizze meg az adatokat paraméter a felületen). Egy mérés órás átlaga kb ~40 byte felhasználást jelent | mon_res_daily_rep | 24 | Minden mérés esetében naponta egy érték kerül eltárolásra, mérésenként ~80 byte felhasználást jelent | mon_res_viol | 24 | Minden egyes threshold sértés esetében keletkezik bejegyzés, sértésenként ~75 byte felhasználást jelent, és annyiszor ~40 byte-ot, ahány mérésből áll a threshold kifejezés | mon_res_rep | 4 | Minden riport változó esetében minden site-hoz és eszközhöz (ha az utóbbi is be van állítva) keletkezik egy érték olyan ciklussal, mint ami a riport változónál meg van határozva, ha a site vagy eszköz alatt létezik a megadott változó. Egy bejegyzés ~55 byte felhasználást jelent | mon_res_group_daily_rep | 24 | Minden riport változó esetében minden site-hoz és eszközhöz keletkezik egy érték naponta, ha a site vagy eszköz alatt létezik a megadott változó. Egy bejegyzés ~260 byte felhasználást jelent | |