Előző 13.1 Telepítés Következő

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