세상에 뿌려진 사랑만큼....

출처 : cafe.naver.com/osschool

오늘 날에 존재하는 모든 컴퓨터는 모두 사람이 만들었습니다.
즉 신께서 만든 존재가 아니지요.
신께서 컴퓨터를 만들어 주셨다면 아마 완벽 했을 텐데
사람이 만들다보니 잦은 고장과 알 수 없는 문제들이 참 많습니다.
이런 알 수 없는 문제들을 해결하기 위해 오늘날 많은 system engineer 들이
밤을 새며 때로는 휴일날도 자신의 시간을 반납해 일을 하지요.
너무들 불쌍 합니다. 저도 System engineer 일을 해보았지만 너무 고생해요.

만일 컴퓨터에 문제가 생겼을때 스스로 복구 할 수 있는 방법이 있다면
얼마나 좋을 까요?
마치 사람처럼 몸에 상처가 생겼을때 스스로 치유가 되는 방법이 있다면
정말 좋지 않을 까요!
얼마 후에는 이런 컴퓨터가 등장하겠지요.
기대를 해 봅니다.

스스로 복구하는 이기능 이미 예전부터 사용하고 있던 기능이 있습니다.
그 기능은 바로 panic 입니다.

1. panic :
 

 panic 은 컴퓨터 내부의 일종의 커널 프로그램중에 하나 입니다.
   커널은 시스템의 중요한 부분을 주기적으로 검사 합니다.
   만일 시스템 내부에 중요한 결함이 발생되면 이를 사용자에게 통지 하고
   시스템을 자동 reset 하게 됩니다.
   왜냐하면 중요한 결함에 의해 다른 정상적인 부분에게도 문제를 일으킨 다면
   큰일 이기 때문에 중단하지요.
   예를 들어 filesystem 의 superblock 에 문제가 생겼다고 가정 하겠습니다.
   filesystem 은 데이터를 보관하는 중요한 곳입니다.
   이 부분의 문제가 생겼을때 바로 중단하지 않고 내버려 두게 된다면 filesystem
   안의 데이터에 손상을 입힐 수 있습니다. 즉 한 곳의 문제로 더 큰 문제로
   발전하기 전에 시스템은 바로 중단 해야 합니다.
   그런데 그냥 중단해 버린다면 사용자는 원인을 파악 할 수가 없지요
   그랳서 커널은 심각한 오류가 발생했을 때 내부의 커널 프로그램중 panic()
   을 실행하여 다음과 같은 순서로 시스템을 reset 합니다.

    1) 모든 프로그램을 중지 한다.
    2) 화면에 하얀바탕 화면에 검정 글씨로 PANIC 원인을 표시한다.
    3) 계속해서 현시점에서 동작한 프로그램을 알 수 있는 stack 과 register
       정보를 화면에 표시한다.
    4) 메모리의 정보중 커널 영역에 해당하는 부분을 swap 장치로 복사한다.
       이것을 dump 라고 말하며 설정 옵션에 따라 메모리 전체의 내용을
       특정 장치에 복사 할 수 있도록 할 수 있다.
    5) 시스템을 reset 하게 한다.
    6) rebooting 하면서 swap 에 복사된 정보를 /var/crash/HOSTNAME/ 아래에
       파일로 저장하는데
       unix.0  파일은 커널의 name list(변수명과 함수명)를 저장하고
       vmcore.0 파일은 실제 메모리 내용을 파일로 저장하는데 이파일을
       메모리 내용을 그대로 dump 하여 가져 왔다하여 vmcore  파일 이라고한다.
  
    7) mdb , scat ,adb , crash 등의 tool 들로  vmcore 파일을 분석하여
       원인이 무었인지 파악한다.

  panic이 발생한다는 것은 참 좋지 않은 일이다. 하지만 컴퓨터에 문제가
  발생했을당시에 원인을 발히기 위해서는 반드시 발생이 되어야 하지만
  문제가 발생했는데로 불구하고 panic 이 일어나지 않는 경우는 대부분 hang 이된다.

2. hang :
 

  hang 은 말그대로 정지된 상태를 말하는데 커널 자신이 스스로 시스템의
   문제를 인식하지 못하여 결국은 시스템 마비 사태를 일으킨 상태다.
   이런 경우 분석하긴 좀 어렵다.
   이렇게 hang 이 된 컴퓨터를 강제로 panic 하는 방법이 있다.
   그건 바로 ok> 모드 에서 'sync' 하는 방법이다.
   ok> mode 에서의 sync는 panic 처럼 메모리의 정보를 swap 장치로 dump 하고
   강제로 reset 을 해주는 기능이다.
   간혹 어떤 사람들은 O/S 명령에서의 'sync' 와 혼돈하는 경우가 있는데
   절대 다른 내용이라는 것을 알아야 한다. O/S 모드에서 'sync' 명령은
   mount 되어 있는 파일 시스템의 super block 을 메모리와 disk 간에 동기화
   하는 방법이고 ok> 모드에서의 'sync' 는 강제 panic 의 방법이기 때문이기에
   전혀 다르다.

참고로 위의 내용에 대해 좀더 깊게 배우고자하면 sun 교육센터의 과정중
 ST-375 Crash Dump Analysis Tools 과정을 수강하면 좋을 듯 합니다.
 아직 계획이 나오지 않았지만 하반기에 이보다더 수준 높은 과정인
 ST-475 Advanced Crash Dump Analysis 과정을 수강하면 너무 좋을 듯합니다.

                                                                                                조재구 ..

우선 무조건 korea language 를 설치후,
1번 시디에서 아래의 패키지를 깐다...

ALE         SUNWkleu                         Korean Language Environment user files
ALE         SUNWkleux                        Korean Language Environment user files (64-bit)
ALE         SUNWkttf                         Korean True Type Fonts
ALE         SUNWkxfnt                        Korean X Windows Platform Required Fonts
ALE         SUNWkxplt                        Korean X Windows Platform Software Package
system      SUNWkdt                          Korean L10N for CDE DESKTOP LOGIN ENVIRONMENT
application NSCPkpcom                        Korean (Common) Netscape Communicator

1번 시디 E:\SOLARIS_9\PRODUCT


* 정상적으로 깔린 서버와 비정상적으로 작동하는 서버간의 pkg를 비교하여 깔면 된다.. ^^;;


-------------------- UTF-8 깔기 ----------------------------------------------
UTF-8 locale

SPARC platform


The packages in the list below can be found on the Solaris Software 1 of 2 CD in the directory .../Solaris_8/Product/:

SUNWale SUNWaled SUNWalex SUNWiiimr SUNWiiimu SUNWxi18n SUNWxi18x SUNWxim SUNWximx SUNWarrf SUNWeugrf SUNWi2rf SUNWi4rf SUNWi5rf SUNWi7rf SUNWi8rf SUNWi9rf SUNWi13rf SUNWi15rf SUNWtxfnt SUNW5xmft SUNWcxmft SUNWjxmft SUNWkxmft SUNWeuluf SUNWeulux SUNWeuodf SUNWeuxwe SUNWuiu8 SUNWuiu8x SUNWuium SUNWulcf SUNWulcfx SUNWulocf SUNWuxlcf SUNWuxlcx NSCPkpcom SUNW5ttf SUNWcttf SUNWi2of SUNWi5of SUNWi7of SUNWkttf SUNWkudt SUNWkuleu SUNWkulex SUNWkuxpl SUNWlj3dv SUNWlj3rt SUNWtleu


The packages in the list below can be found on the Languages CD in the directory .../components/Korean/sparc/Packages/:

NSCPkucom SUNWkcoft SUNWkdcl SUNWkdcst SUNWkddst SUNWkfdl SUNWkj2rt SUNWkjmfp SUNWkjvdv SUNWkjvrt SUNWkmga SUNWkodte SUNWkoj2p SUNWkpdas SUNWkreg SUNWkscgu SUNWksmc SUNWkttfe SUNWkuadi SUNWkuadm SUNWkudab SUNWkudbs SUNWkudda SUNWkuddt SUNWkudft SUNWkudhr SUNWkudhv SUNWkudhz SUNWkudic SUNWkudim SUNWkudwm SUNWkudzt SUNWkulee SUNWkuodf SUNWkupmw SUNWkurdm SUNWkusal SUNWkuudc SUNWkuxe SUNWkuxft SUNWkwbc SUNWkwdev SUNWkwsr2 SUNWkwsrv

core 파일은 시스템이 갑작스런 다운이나 hang이 되었을때 그 때의 메모리에 기록 되어 있던 데이터를
기록하는 파일로 이것을 잘 분석한다면 시스템이 다운된 원인을 찾을 수 있을 것이다.
* 일반적으로 system dump core는 SUN Technical Center 에서 해석하여 결과를 알려준다.
Solaris 2.6이하는 core 파일은 자동으로 생성되지 않는다.
Solaris 7부터는 default로 생성되게 설정되어 있다.

/etc/init.d/sysetup 파일의 내용중 아래와 같은 부분이 있는데 이 부분의 # 상태로 막혀 있는 부분을
열어 줘야 생성이 된다.


7버전이상의 버전 경로 : /etc/rc2.d/S75savecore
if [ -x /usr/bin/savecore ]; then
        [ -r /etc/dumpadm.conf ] && . /etc/dumpadm.conf

        if [ "x$DUMPADM_ENABLE" != xno ] && mksavedir; then
                /usr/bin/savecore $DUMPADM_SAVDIR
                shift $#
                set -- `/usr/sbin/dumpadm 2>/dev/null | /usr/bin/grep 'device:'`
                savedev=${3:-none}
        fi
else
        echo "WARNING: /usr/bin/savecore is missing or not executable" >& 2
fi

IPMP 이해 및 설정

Objectives

IPMP 기능 이해

IPMP 관련 화일및 명령어 이해

IPMP 설정 및 테스트

 

Description

솔라리스 8부터 새로이 추가된 기능중 하나인 IPMP(IP MultiPathing)는 솔라리스의 core package인 SUNWcsr에 포함되어 있다. IPMP는 하나의 시스템이 여러개의 NIC(Network Interface Card)를  사용할때 네트웍 카드들을 그룹핑을 하여서 그중 하나의 네트웍 카드가 failure 되었을때 이를 검사하여 정상적인 네트웍 카드로 failover해주는 기능이다. 그러므로써 네트웍 서비스를 제공하는데  있어서 네트웍 카드의 장애로 생기는 네트웍 장애 문제를 극복할 수 있는 안정적인 환경을 구성해 줄 수 있다. 또한 failback 기능을 가지고 있는데 이는 장애가 발생한 네트웍 카드를 복구한 후 관리자가 메뉴얼하게 네트웍 카드의 설정을 하지 않아도 자동으로 이전 설정으로 돌려주는 기능이다.

IPMP 설정 방법으로는 크게 두가지가 있다. Standby NIC를 가지는 환경과 그렇지 않은 환경이다. Standby NIC란 네트웍 서비스를 일반적으로 하지 않는 NIC를 하나 설정하여 실제 서비스중인 NIC의 failover에 집중적으로 책임을 지는 인터페이스이다. 이것이 Standby NIC를 가지고 IPMP를 설정하는 것이다.

Standby NIC를 가지지 않는 환경이란 그룹에 있는 NIC들이 네트웍 서비스를 각각 하고 있다가  그룹내 NIC 하나가 failure가 발생하면 남아있던 정상의 NIC로 failover하는 것이다. IPMP를 설정하는데 있어서 Standby를 갖는냐 갖지 않는냐의 가장 큰 차이는 failover를 할 수 있는 대상 NIC 차이이다.

Standby NIC는 Standby가 아닌 다른 NIC의 failover를 제공하지만 반대는 할 수 없다. 즉, Standby가  아닌 NIC는 Standby NIC의 failure에 대해 failover를 하지 않는다.

Standby NIC가 없이 NIC들을 모두 active path로 잡아주는 환경은 그룹에 있는 NIC들이 어떤것이든 서로를 failover하며 서비스 해 줄 수 있다.

아래의 Lab에서는 Standby NIC를 두는 IPMP 환경 설정과 그렇지 않는 설정에 대해 설명할것이다.

 

IPMP 구현 관련 명령어와 파일

 

1. in.mpathd : IPMP의 main control daemon이다. NIC를 그룹핑하는 Ifconfig 명령어를 실행하면  실행하는 프로세스로써 그룹내에 있는 네트웍 카드가 failure가 발생했는지 검사하여 정상적인 네트웍 카드를 failover를 시켜주고 failback을 시켜주는 프로세스이다. 이때 in.mpathd가  failover, failback을 하기위해 (NIC를 테스트하기 위해) 사용하는 logical interface가 필요한데 이것이  test interface이다. test interface는 failover하지 않는다. 단지 테스트를 위한 virtual interface이다.

참고로 Standby interface는 test interface 형태로만 설정한다. 하지만 그룹내 NIC들이 모두  active한 환경이라면 (즉 Standby NIC를 가지지 않는 설정) NIC들은 public한 ip address와 test를 위한 ip address 모두를 갖도록 설정해야한다.

 

2. /etc/default/mpathd : in.mpathd의 configuration file이다. 예를 들어 in.mpathd가 그룹내 NIC들의 failover를 체크할 시간 간격을 정의하는 파라메터등을 설정하는 화일이다.

 

3. ifconfig : 너무나 잘 알고 있듯이 네트웍 카드 설정을 해주는 명령어이다. 예를 들어 ip address나 netmask등을 설정해주는 명령어이다. 그러한 기본 기능뿐만이 아니라 IPMP를 설정시에도 그룹을 지정하거나 테스트 NIC를 설정하는데 사용된다. IPMP 설정에 관련있는 ifconfig 명령어들의 옵션이나 아규먼트 몇 가지를 살펴보자.

group : IPMP failover를 할 그룹을 설정한다.

deprecated -failover : test interface 에 설정하는 옵션

addif : test interface 이면서 active path 를 가지고 있으면서 test interface를 add 하기 위해

사용하는 아규먼트

standby : active path를 갖지 않는 standby test interface 를 설정하는 아규먼트

 

Implementation

아래의 구현 내용은 IPMP를 설정하는 방법으로 첫째로 standby를 사용하지 않고 두 NIC가 모두  active하게 서비스를 할 수 있는 상태로 만든후 failover, failback을 하는 내용이다. 두번째 구현의  내용은 standby를 사용하는 테스트의 예이다.

 

1.      Standby 없이 dual active path 의 IPMP설정 및 확인

설정

host1#eeprom local-mac-address? local-mac-address?=false host1# eeprom local-mac-address?=true --> 각 interface의 ethernet address를 달리 설정하기 위한 eeprom parameter를 true로 설정 host1# eeprom local-mac-address? local-mac-address?=true   host1# ifconfig ge0 unplumb host1# ifconfig ge1 unplumb host1# ifconfig ge0 plumb 192.168.0.86 group testgrp2 up   host1# ps -ef|grep mpath root 477 1 0 17:18:09 ? 0:00 /sbin/in.mpathd   host1# ifconfig ge0 addif 192.168.0.87 deprecated -failover up ---> test interface 설정 . Created new logical interface ge0:1   host1# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4>mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6 inet 192.168.0.86 netmask ffffff00 broadcast 192.168.0.255 groupname testgrp2 ether 8:0:20:c0:ff:ec ge0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 6 inet 192.168.0.87 netmask ffffff00 broadcast 192.169.0.255   host1# ifconfig ge1 plumb 192.168.0.88 group testgrp2 up host2# ifconfig ge1 addif 192.168.0.89 deprecated -failover up  --> test interface설정 . Created new logical interface ge1:1   host1# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4>mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6 inet 192.168.0.86 netmask ffffff00 broadcast 192.168.0.255 groupname testgrp2 ether 8:0:20:c0:ff:ec ge0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 6 inet 192.168.0.87 netmask ffffff00 broadcast 192.168.0.255 ge1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>mtu 1500 index 7 inet 192.168.0.88 netmask ffffff00 broadcast 192.168.0.255 groupname testgrp2 ether 8:0:20:c0:ff:ec ge1:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 7 inet 192.168.0.89 netmask ffffff00 broadcast 192.168.0.255

 

Failover 테스트

다른 호스트 host2 로부터 192.168.0.88 번으로 ping을 날리고 host1은 그러는 중간에 ge1에 장애를 일으켰다. lab에서는 네트웍 포트를 뽑아버렸다

host2# ping -s 192.168.0.88 PING 192.168.0.88: 56 data bytes 64 bytes from host1 (192.168.0.88): icmp_seq=0. time=0. ms 64 bytes from host1 (192.168.0.88): icmp_seq=1. time=0. ms 64 bytes from host1(192.168.0.88): icmp_seq=2. time=0. ms 64 bytes from host1(192.168.0.88): icmp_seq=3. time=0. ms 64 bytes from host1 (192.168.0.88): icmp_seq=4. time=0. ms 64 bytes from host1 (192.168.0.88): icmp_seq=5. time=0. ms 64 bytes from host1 (192.168.0.88): icmp_seq=6. time=0. ms . . 64 bytes from host1 (192.168.0.88): icmp_seq=14. time=0. ms 64 bytes from host1 (192.168.0.88): icmp_seq=15. time=0. ms 64 bytes from host1 (192.168.0.88): icmp_seq=16. time=0. ms

위의 결과에서 보듯이 중간에 잠시 멈추는 부분이 보이는데 이때 host1의 ge1이 장애를 일으켰다. 하지만 잠시 시간이 흐른 후 계속 ping 이 잘 진행되는 것을 확인할 수 있다.

host1에서 IPMP설정에 의해 failover가 되는 것이다. 이러한 테스트는 ge0에 장애를 일으켜도 마찬가지로 ge1으로 failover 된다.

그럼 host1쪽의 failover된 환경을 확인해 보자.

 

host1# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4>mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6 inet 192.168.0.86 netmask ffffff00 broadcast 192.168.0.255 groupname testgrp2 ether 8:0:20:c0:ff:ec ge0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 6 inet 192.168.0.87 netmask ffffff00 broadcast 192.168.0.255 ge0:2: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6 inet 192.168.0.88 netmask ffffff00 broadcast 192.168.0.255 ge1: flags=19000842 <BROADCAST,RUNNING,MULTICAST,IPv4,NOFAILOVER,FAILED>mtu 0 index 7 inet 0.0.0.0 netmask 0 groupname testgrp2 ether 8:0:20:c0:ff:ec ge1:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 7 inet 192.168.0.89 netmask ffffff00 broadcast 192.168.0.255

 

Failback 테스트

ge1을 복구한 후 얼마 지나지 않아 자동으로 failback 하는 것을 확인할 수 있다. 아래의 내용은 failback을 한 후의 host1의 네트웍 카드 설정을 보면 이전 상태로 돌아가 있는 것을 확인할 수 있다.

host1# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4>mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6 inet 192.168.0.86 netmask ffffff00 broadcast 192.168.0.255 groupname testgrp2 ether 8:0:20:c0:ff:ec ge0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 6 inet 192.168.0.87 netmask ffffff00 broadcast 192.168.0.255 ge1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>mtu 1500 index 7 inet 192.168.0.88 netmask ffffff00 broadcast 192.168.0.255 groupname testgrp2 ether 8:0:20:c0:ff:ec ge1:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 7 inet 192.168.0.89 netmask ffffff00 broadcast 192.168.0.255

 

/etc/hostnanme.<interface> 설정 내용

# cat /etc/hostname.hme0 192.168.10.215 broadcast + netmask + up group test  \ addif 192.168.10.216 –failover  deprecated netmask + broadcast + up # cat /etc/hostname.hme1 192.168.10.217 broadcast + netmask + up group test  \ addif 192.168.10.218 –failover  deprecated netmask + broadcast + up

 

2.      Standby 를 가진 single active path의 IPMP 설정하기

 

설정

host1#eeprom local-mac-address? local-mac-address?=false host1# eeprom local-mac-address?=true --> 각 interface의 ethernet address를 달리 설정하기 위한 eeprom parameter를 true로 설정 host1# eeprom local-mac-address? local-mac-address?=true   host1# ifconfig ge0 unplumb host1# ifconfig ge1 unplumb host1# ifconfig ge0 plumb 192.168.0.86 group testgrp2 up   host1# ps -ef|grep mpath root 477 1 0 17:18:09 ? 0:00 /sbin/in.mpathd   host1# ifconfig ge0 addif 192.168.0.87 deprecated -failover up ---> test interface 설정 . Created new logical interface ge0:1   host1# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4>mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6 inet 192.168.0.86 netmask ffffff00 broadcast 192.168.0.255 groupname testgrp2 ether 8:0:20:c0:ff:ec ge0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 6 inet 192.168.0.87 netmask ffffff00 broadcast 192.169.0.255   host1# ifconfig ge1 plumb 203.234.247.88 group testgrp1 deprecated -failover standby up host1# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4>mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6 inet 192.168.0.86 netmask ffffff00 broadcast 192.168.0.255 groupname testgrp2 ether 8:0:20:c0:ff:ec ge0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 6 inet 192.168.0.87 netmask ffffff00 broadcast 192.169.0.255 ge1: flags=69040843 <UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER,STANDBY,INACTIVE> mtu 1500 index 5 inet 192.168.0.88 netmask ffffff00 broadcast 192.168.0.255 groupname testgrp1 ether 8:0:20:c0:ff:ec

 

Failover 테스트

다른 호스트 host2 로부터 192.168.0.86 번으로 ping을 날리고 host1은 그러는 중간에 ge1에 장애를 일으켰다.  lab에서는 네트웍 포트를 뽑아버렸다.

host2# ping -s 192.168.0.86 PING 192.168.0.86: 56 data bytes 64 bytes from host1 (192.168.0.86): icmp_seq=0. time=0. ms 64 bytes from host1 (192.168.0.86): icmp_seq=1. time=0. ms 64 bytes from host1(192.168.0.86): icmp_seq=2. time=0. ms 64 bytes from host1(192.168.0.86): icmp_seq=3. time=0. ms 64 bytes from host1 (192.168.0.86): icmp_seq=4. time=0. ms 64 bytes from host1 (192.168.0.86): icmp_seq=5. time=0. ms 64 bytes from host1 (192.168.0.86): icmp_seq=11. time=0. ms 64 bytes from host1 (192.168.0.86): icmp_seq=12. time=0. ms 64 bytes from host1 (192.168.0.86): icmp_seq=13. time=0. ms

위의 결과에서 보듯이 중간에 잠시 멈추는 부분이 보이는데 이때 host1의 ge1이 장애를 일으켰다. 하지만 잠시 시간이 흐른 후 계속 ping 이 잘 진행되는 것을 확인할 수 있다.

host1에서 IPMP설정에 의해 failover가 되는 것이다. 하지만 이때 ge0이 아닌 standby 인 ge1에 장애가 발생하면 ge0으로는 failover되지 않는다.

 

/etc/hostnanme.<interface> 설정 내용

# cat /etc/hostname.ge0 192.168.0.86 netmask 255.255.255.0 broadcast + group host1 up \ addif 192.168.0.87 deprecated -failover netmask 255.255.255.0 broadcast + up   #cat /etc/hostname.ge1 192.168.0.88 netmask 255.255.255.0 broadcast + group host1 deprecated -failover standby up

 

 

 

자 보통 솔라리스에서는 2G이상의 파일은 생성할 수 없다고 알고 있나요?
이는 정말일까? 사실 이부분도 system performance의 한 종류다.
 
만약 이런 사실이 정말이라면 솔라리스는 개떡 같은 시스템일 수 있다.
왜냐? 대형 서비스를 하는 곳에서 운영하는 DBM의 경우 하나의 파일이
2G의 용량을 훌쩍 넘길 수 있기 때문이다.
 
[root@/www] # df -h
Filesystem             size   used  avail capacity  Mounted on
/dev/dsk/c0d0s0        6.4G   3.3G   3.0G    53%    /
/proc                    0K     0K     0K     0%    /proc
mnttab                   0K     0K     0K     0%    /etc/mnttab
fd                       0K     0K     0K     0%    /dev/fd
swap                  1022M   156K  1022M     1%    /var/run
swap                  1022M    16K  1022M     1%    /tmp
/dev/dsk/c0d1s0        3.9G   302M   3.6G     8%    /www
/dev/dsk/c0d0s7        480M   2.8M   430M     1%    /export/home
[root@/www] #
 
현재 내 파일 시스템의 영역이다. 아마도 글을 올린 다음.. 칸이 엉망으로
망가질 것이다. 그러나 잘 살펴보도록 하자.
 
우리는 정말 2G 이상의 파일은 만들 수 없는지 확인하기 위해 딱 2G 이상
용량의 파일을 구현해보자. 그런데 이리저리 파일 시스템을 살펴서 처리해보자
자 잘 살펴보니 /dev/dsk/c0d0s0 의 root (/)파일 시스템의 사용한 공간이 3.3G
이다. 앗 그러고 보니 /dev/dsk/c0d1s0 의 /www 파일 시스템의 경우 3.6G
의 남은 용량을 보니 이것을 테스트해보면 딱이겠다.
 
[root@/] # pwd
/
[root@/] # ls
TT_DB       devices     lib         platform    usr
bin         etc         lost+found  proc        var
boot        export      mnt         root        vol
cdrom       home        net         sbin        www
dev         kernel      opt         tmp         xfn
[root@/] # tar cvf /www/www.tar TT_DB devices lib platform usr bin etc var
> boot root vol sbin kernel opt xfn
..
..
(상당히 오래걸렸다.)
 
자 파일이 생성된 곳을 찾아가서 파일 용량을 확인해보자.
 
[root@/] # cd www/
[root@/www] # du -h www.tar
 3.3G   www.tar
[root@/www] #
 
분명히 3.3G의 파일이 하나 만들어졌다. 이로 보아 솔라리스에서는 하나의 파일
이 가질 수 있는 용량은 정해진 것은 아닌 것이다.
 
시스템의 설정을 살펴보자.
 
[root@/] # ulimit -a
core file size (blocks)     unlimited
data seg size (kbytes)      unlimited
file size (blocks)          unlimited
open files                  256
pipe size (512 bytes)       10
stack size (kbytes)         8480
cpu time (seconds)          unlimited
max user processes          1925
virtual memory (kbytes)     unlimited
[root@/] #
 
자 잘살펴본다면 뭔가 보일 것이다.
 
file size (blocks)          unlimited
이부분이다.
 
man ulimit 명령어를 사용해보면 최대 파일 블럭 지정은 -f 이다.
 
솔라리스에서 하나의 블럭은 512 byte를 가지므로 파일 생성시 최대 파일 용량을
1 mega byte로 지정하려면 최대 블럭을 2048로 지정하면 될것이다.
 
[root@/] # ulimit -f 2048
[root@/] # ulimit -a
core file size (blocks)     unlimited
data seg size (kbytes)      unlimited
file size (blocks)          2048
open files                  256
pipe size (512 bytes)       10
stack size (kbytes)         8480
cpu time (seconds)          unlimited
max user processes          1925
virtual memory (kbytes)     unlimited
[root@/] #
 
자 몇가지 명령어를 사용해서 파일을 생성해 보라. 분명히 1 M 이상의 파일은 생
성할 수 없을 것이다.
 
ulimit 명령어를 사용해서 여러가지 조작을 해서 설정해서 테스트해보는 것도 하
나의 방법일 것이다. ulimit를 살펴보면 file size 및 다른 설정도 많이 있다.
 
팁..
시스템 V 이상의 버전에서 하나의 프로세서가 파일을 생성할 시, 몇가지 시스템
을 불러온다. 우선 write 시스템을 호출하여 쓰기 모드로 들어가며, 이때 ulimit
시스템도 불러와 시스템 상태를 살펴본다. 당연히 cmask 시스템도 적용시켜봐서
이 파일을 내가 건들어도 퍼미션에 문제가 없는지 살피기도 한다. 열거해 놓은
이러한 작업 뿐 아니라, 무수히 많은 작업이 이루어진다. 그래서 대표적인 것만
말해 놓았다. ^^! 솔라리스를 처음 설치해 놓으면 ulimit 에 파일 쓰기에 대한
제한을 걸어 놓지 않는다. 그러나 시스템 관리자에 의해서 ulimit 시스템에 제
동을 걸어 놓을 수 있다. 가끔 게시판에 어느 용량 이상의 파일은 생성되지 않
아요..하는 물음이 나올 수는 있으나,  특정 파일 시스템 특징으로 인해서 2G 이
상의 파일을 생성할 수 없는 경우를 제외하고는 최근의 시스템은 대부분 2G 이상
의 파일 용량을 허용하고 있다. (fat32 시스템에 2G 이상의 파일을 생성해보라.
분명히 실패한다. -ㅁ-; 그래서 vmware에서 2G 이상의 하드 파일을 만들 때 스필
트(split 분할모드)모드가 존재하는 것이다. 우리는 이것을 꼭 참고하자.
다음 안건은 acct 냐햐햐햐햐

출처 : http://blog.naver.com/canard

OS에서 설치된 바이너리 실행 파일은 MD5 알고리즘으로 16진수 암호화된 고유 번호를

가지고 있어서 이 번호의 일치 여부로 파일의 변조 여부를 확인할 수 있습니다.

일단 암호화 번호를 알기 위해서는 아래 URL에서 프로그램을 다운 받으세요.

http://sunsolve.sun.com/md5/md5.tar.Z

다운 받은 후 압축을 풉니다.

#> zcat md5.tar.Z | tar xvf -

압축을 푼 다음 다음과 같이 실행합니다.

#> ./md5-sparc /usr/bin/csh

MD5 (/usr/bin/csh) = 00e416f3d48289c0e192a202450c9ada

위 숫자 부분을 복사해서 아래 사이트로 들어가서

http://sunsolve.sun.com/pub-cgi/fileFingerprints.pl

맨 아래 부분에 입력하는 텍스트란에다 넣고 submit 버튼을 누르면 결과가 나옵니다.

정상적인 경우는

Results of Last Search

00e416f3d48289c0e192a202450c9ada - - 1 match(es)
canonical-path: /usr/bin/csh
package: SUNWcsu
version: 11.8.0,REV=2000.01.08.18.12
architecture: sparc
source: Solaris 8/SPARC
patch: 110898-02

변조되거나 훼손된 경우는

Results of Last Search

47762485d0c3e7fe0387421619db3776 - - 0 match(es)
Not found in this database.
이런식으로 나옵니다.

==== 출처 : 솔라리스/해킹/정보보안 테크넷 ====

1장. NetBackup Essentials

다음을 학습하고 이해한다.

  ▶ 여러분들이 친숙해 져야할 NetBackup 제품들
  ▶ NetBackup이란 무엇인가?
  ▶ NetBackup으로 무엇을 할 수 있는가?
  ▶ 용어

-----------------------------------------------------------------------------

가. NetBackup 제품과 구조 [Page 1-4]

1). NetBackup Server와 NetBackup Enterprise Server와의 공통점과 차이점

A. 공통점

▶ 두 제품은 여러분 조직의 전산환경에 존재하는 데이터들을
    만약에 발생할 수 있는 재난에 대비하여 데이터를 보호를 위해
    NetBackup 서버로 부터 Storage Device로 자동적으로 백업을 할 수 있는
    기능을 제공한다.
▶ 데이터 손실이 있을 경우 백업된 데이터로 부터 빠른 복구를 제공한다.

B. 어떻게 동작하는가?

▶ 여러분들이 NetBackup을 가지고 Policies와 Schedules를 생성을 하여
    주기적으로 백업을 할 수 있는 환경을 만들어 준다.
▶ 주기적으로 여러분의 소중한 데이터를 Policies에 따라 테이프, 디스크,
    다른 스토리지 장비에 네트워크를 통해서 자동적으로 저장할 수 있도록
    만든다.
▶ 관리자로서 User-level Backup을 할 수 있는 권한을 부여할 수 있다.
▶ NetBackup Catalog를 유지를 하여 요구시 Data를 복구할 수 있게 해준다.
▶ 관리콘솔에서 NetBackup의 전체 운영을 관찰하고 운영에 대한 보고서를
    볼 수가 있다.

C. NetBackup Enterprise Server와 NetBackup Server의 차이점

▶ NetBackup Enterprise Server는 거대한 UNIX와 Windows System을 위해
    디자인 되었다. 하나의 Master Server와 여러대의 Media Server로
    구성을 할 수가 있다.
▶ NetBackup Server는 하나의 Master/Media Server로 구성할 수 있다.

▶ 확장성에 대한 차이점이 있다

2). NetBackup 구조 [Page 1-6]

 GDM[Global Data Manager] master of masters  [Tier 4]
 ------------------------------------------
 Master Servers Master Server  [Tier 3]
 ------------------------------------------
 Media Servers Media Server  [Tier 2]
 ------------------------------------------
 Client  Client  Client  Client  [Tier 1]

▶ Client : 백업할 데이터를 보관하고 있는 시스템. Data Stream으로 Backup할
              내용을 Media Server로 보냄

▶ Media Server : Storage 자원을 제공 시스템.
  master Server로 부터 명령을 받아서 client에서 보내져오는
  data stream을 서버에 부착된 storage unit에 저장하는 시스템

▶ Master Server : 중앙집중식 운영과 관리를 하기 위한 NetBackup 환경에서
  두뇌역활을 하는 시스템이다. 전반적인 백업환경 운영을 담당하고
              있으며 NetBackup Environment당 하나의 Master Server가 존재한다.

  - 백업 운영
   - 아카이브 운영
  - 복구 운영
  - 자동화백업 스케쥴링
  - 백업 구성 정보기록
  - 작업상태 정보기록
  - 백업 이미지 정보기록

▶ GDM [NetBackup Global Data Manager] : 물리적으로 떨어져 있는 기업의
  환경에서 한 장소에서 백업과 복구를 수행할 수 있는 능력이 필요한데
  GDM은 그러한 기능을 제공해 준다. GDM은 master of masters로서
  물리적으로 떨어져 있는 Master Server들을 관리할 수 있으며 한
  장소에서 여러 백업과 복구에 대한 운영을 쉽게 할 수가 있다.
  확장을 용이하게 해준다.

3). 구조의 예 [Page 1-8]

A. One Master/Media Server

▶ NetBackup Server환경의 전형적인 구성이며 소규모 망에서 적합하다.
    하나의 Master Server에서 Storage Devices와 Clients들을 관리한다.

B. a Master Server and a Media Server [Page 1-9]

▶ NetBackup Enterprise Server에 대한 기본구성이다.
    Media Server에 Storage Device가 부착이 되며 Clients와는 Network로
    보통 연결된다. 보통 Client에는 백업할 데이터량이 적고 Media Server에
    백업할 데이터량이 많을 때도 이렇게 구성을 한다.

C. One Master Server / Multiple Media Servers

▶ 분산네트워크 환경에서 구성하는 구조이다.
    백업은 Local Netword에서 발생한다.

나. NetBackup Terminology [넷백업 용어]

▶ 어느 전산환경에서 그렇듯 효율적인 작업을 하기 위해서는 그 전산환경에서
    사용되는 용어와 친숙해 져야 한다.
▶ 다음과 같은 용어는 다른 제품과 기술에서도 보편적으로 통용이 된다.

1). 용어

A. NetBackup Image

▶ 하나의 클라이언트에서 백업이 발생할때 백업될 데이터가 Media Server로
    GNU tar 형식으로 압축이 되어 Backup Media[Tape, Optical Disk, Disk]로
    저장된 것을 NetBackup Image라 한다. 또는 Backup Image, Image라 부른다.

B. Storage Units

▶ 클라이언트의 백업할 데이터의 논리적인 목적지를 말함.
▶ NetBackup Server에 연결된 명확한 Type와 Density를 가지는 하나 이상의
    Storage Device의 Group이다. 

 Storage Units의 이점

 - Storage Units은 NetBackup관리를 간소화한다.
 - NetBackup은 명확한 Storage Device 보다 Storage Unit을 사용한다.
 
 4가지의 Storage Unit Types

 - Disk storage unit

   ▶ Disk-Based Storage Unit이라 불리는데 하드디스크 상의 디렉토리로
       존재하는 Storage Unit이다.
   ▶ 테스트나 빠른 백업을 할 때 유용하다. 그리고 Disk의 Random Search
       특징으로 빠른 복구기능을 제공한다.
   ▶ 하지만 더 많은 디스크 공간이 필요하게 되고 Disk Space Full을 주의
       해야 한다.

 - Disk staging storage unit

   ▶ 처음에 Backup Image를 Disk에 저장을 하고 후에 다른 Media Type에
       Image를 옮길수 있는 방법을 제공한다. Image가 Disk에 있는 동안
       장애가 난 경우 빠른 복구기능을 제공한다.
   ▶ Disk Staging는 짧은 기간 Tape는 긴 기간동안 Backup Image를 저장
       할 수 있도록 해준다.

 - Media Manager storage unit

   ▶ Disk 기반이 아닌 Storage Unit이다. 보통 Robotic Tape Library와
       Stand-alone Tape, Optical Disk Device를 사용한다.

 - NDMP storage unit

   ▶ Media Manager에 의해 제어가 되지만 NDMP[Network Data
                  ManageMent Protocol] host에 연력이 되어 있고 옵션제품이다.

 Storage Unit 구성방법

 - On demand Only

   ▶ policy나 스케줄이 단지 그 Storage unit를 사용할 수 있도록
  구성

 - Any Available

   ▶ Backup policy에 대해 storage unit에 대해 명시를 하지 않는
       다면 any availible로 지정되게 된다. Volume Pool에 사용가능한
                   Media가 존재해야 한다.    

C. Storage Unit Groups

  ▶ storage unit들을 단일 unit으로 주소화 시켜주는 group이다. 그리고 각각의 storage unit에
      대해 우선순위를 부여 할 수 있다.

D. Volumes

  ▶ volume은 하나의 removable media이다.

E. Volume Pools

  ▶ 명확한 목적을 위해 정의된 volume의 집합이다.

F. Volume Groups

  ▶ media에 대한 물리적 위치이다.

G. Backup Policies

  ▶ 어떻게 백업을 수행을 할 것인지에 대한 세부사항을 정의한 파라미터들의
      리스트들의 집합이다.

 - attributes : where, how
 - schedules : when
 - backup selection : what
 - clients : who

  ▶ Backup policy 의 갯수 제한은 없다.
  ▶ policy는 master server에 정의되어야 한다.

H. Catalogs [Page 1-20]

  ▶ 구성과 백업정보를 가지고 있는 내부 데이터베이스이다.
  ▶ 이곳에는 NetBackup의 구성과 백업이 수행된 내용에 정보를 가지고 있다.

 Master Server Catalogs Media Server Catalogs
 ------------------- ------------------
 [NetBackup Catalog] [Nebackup Catalog]
 Image   Media
 Config   [Media Manager Catalog]
 Policy   Device
 Jobs
 Error
 [Media Manager]
 Volume
 Global Device

  ▶ Client는 Catalog를 가지지 않는다.
  ▶ NetBackup 제품을 구성하여 구성요소

다. NetBackup 5.x의 옵션

  ▶ 백업환경을 발전시키기 위해 사용되는 옵션제품이다.
  ▶ 세부정보는 http://www.veritas.com을 참조

 - Bare Metal Restore
 - Vault
 - Shared Storage Option
 - GDM
 - Advanced Reporter
 - Database Agents
 - Storage Migrator
 - NDMP
 - Advanced Client
   * Offhost Backups
   * Instant Recovery
   * Array Intergration
   * FlashBackup
   * Oracle Advanced BLI Agent

다음을 학습하고 이해한다.

  ▶ NetBackup 설치전 고려해야 할 사항
    - 기본설치경로
    - NetBackup 설치전 알아야할 일반적인 사항
    - NetBackup License Keys 관리
    - NetBackup Catalogs의 위치와 Size 식별
  ▶ NetBackup 설치, 구성 및 설치 확인
    - 설치
    - 특정 디렉토리의 사용
    - 구성
    - 설치 확인
  ▶ 보편적인 설치 문제에 대한 해결

-----------------------------------------------------------------------

가. 기본적인 설치경로 [Page 2-5]

 NetBackup /usr/openv/netbackup
 Media Manager /usr/openv/volmgr
 License Keys /usr/openv/var    [ license.txt file ]
 Java  /usr/openv/java

  주의 : 기본경로가 아닌 다른 경로에 설치를 하면 문제가 발생할 수도 있다.

나. 설치전의 임무 [Page 2-6]

1). 설치 요구사항 확인

  ▶ 호환성. 호환리스트 확인
  ▶ Memory와 Hard Disk 용량

     * Mater Server에 150MBytes가 필요
     * Media Server에 35MBytes가 필요
     * Client에 15MBytes가 필요하다.
     * CatalogDB에 관련된 용량측정도 필요하다.
     * 512MB Memory를 권장하지만 256에서도 Java Interface Program 운영가능.

  ▶ Old SoftWare 삭제
  ▶ 다른 시스템과 통신이 가능한지 ping test 필요.
  ▶ Devices에 관련된 driver 설치와 연결 및 연결확인
  ▶ License Key [Optional Product에 관련된 License Key]
  ▶ 관리자권한 필요
  ▶ 설치를 위한 NetBackup Software 필요

2). 호환성 검사

  ▶ Software 호환성 [ http://support.veritas.com ]
    - Operating System 호환성
    - Database Agent 호환성
    - Cluster 호환성
    - Shared Storage Option(SSO) Device 호환성
  ▶ Hardware 호환성
    - http://support.veritas.com => NetBackup Product => NetBackup Enterprise
      Server => Compatibility & Reference 에서 NetBackup 5.x HCL 검색

다. NetBackup Licensing [Page 2-10]

1). NetBackup Licensing
 
  ▶ NetBackup 5.X는 새로운 라이센스 키를 요구한다. NetBackup을 설치할때
      입력을 요청한다.
  ▶ NetBackup 설치후 NetBackup Administration Console이나
      get_license_key  명령을 통해 라이센스 키를 관리 할 수 있다.

2). Licenses for Enabling Options and Agents

  ▶ Option 제품을 사용하기 위하여 필요한 License Key를 Master Serer에
      입력하여야 한다.

3). License Keys
 
  ▶ Key의 값은 숫자와 영문자 조합으로 이루어져 있다. 이 문자들은
      다음과 관련된 정보를 포함하고 있다.
  
    - Server
    - Client
    - Agent
    - Option
    - Permanent Key
    - Evaluation Key
    - How and where the key was generated

4) NetBackup Administration Console을 통한 License Key 관리 [Page 2-12]

  ▶ # jnbSA & => Help Menu => License Keys => License Key 추가
 
      => 모든 NetBackup Utility 재시작

5) License Key Utility를 사용한 License Key 관리

  ▶ # /usr/openv/netbackup/bin/admincmd/get_license_key
     
      A,D,F,L,H,q Keyword를 사용하여 key를 확인, 추가 삭제를 할 수 있다.

  ▶ License Key는 /usr/openv/var/license.txt에 암호화되어 저장된다.

라. Catalog Space Requirements [Page 2-15]

1). Catalog Space Requirements

  ▶ NetBackup 설치전 Catalog에 대한 공간 염두해 두어야 한다.
  ▶ 여러정보가 있지만 그중에 크기가 크고 중요한 Catalog가 Image Catalog이다.
  ▶ 개별적인 파일에 대한 전체수와 유지기간에 따라 필요한 공간의 크기가
      달라진다.

  Master Server Catalogs  Media Server Catalogs
  ------------------------------------------------------
   - Images     - Media
   - Config     - Device
   - Policy
   - Jobs
   - Error
   - Volume
   - Global Device

2). Images Catalog Sizing [Page 2-16]

A. NetBackup Images Catalog Sizing

  ▶ 파일1개에 관련된 metadata를 저장하기 위한 기본 필요용량은 150bytes 이다.
      만약 매일 30만개의 파일을 백업을 하는데 유지기간이 30일이라면
      (300000x30x150)/(1024x1024) ≒ 1.3GBytes가 필요하다.
  ▶ Error와 Status log에 대한 공간도 염두해두어야 한다.

B. Image Catalog Size 추정하기

  ▶ 실질적으로 저장하는 데이터 용량에 1~3% 에 해당하는 용량이 Catalog Size로
      계산할 수 있다.
  ▶ 2.5TBytes를 저장하기 위해 사용되는 Catalog Size는 50GBytes정도 된다.

C. 향상된 Catalog Format

  ▶4.x에서 업그레이드 하였다면 몇개의 Catalog는 ASCII로 되어 있을 것이다.
  ▶ /usr/openv/netbackup/bin/cat_convert명령을 사용하여 Binary Format으로
     전환할 수 있다. 약 2/3로 용량이 줄어든다.

마. NetBackup 설치

1). 설치

  ▶ CDROM에 CD를 넣는다.
  ▶ # cd /cdrom/cdrom0
  ▶ ./install
  ▶ NetBackup install
  ▶ Directory Path 와 평가 License Key를 입력하여 설치
  ▶ # bpps -a 명령을 사용하여 Daemon Processes 확인

2). 주요 디렉토리

  /usr/openv/netbackup/bin   실행파일
  /usr/openv/netbackup/bin/admincmd  NetBackup Command
  /usr/openv/netbackup/bin/goodies  Script File
  /usr/openv/volmgr/bin   Media Manager Command
  /usr/openv/man    Manual Page

  ▶ /etc/rc2.d/S77netbackup ----> /etc/init.d/netbackup 에 심볼릭 링크
  ▶ /etc/rc0.d/K77netbackup ----> /etc/init.d/netbackup 에 심볼릭 링크
 
  ▶ 설치가 끝났으면 Command Path와 Manual Path를 정의하여 준다.

--------- /.profile  file -------------------------------------------------
PATH=/usr/sbin:/usr/bin:/usr/openv/volmgr/bin:/usr/openv/netbackup/bin:/usr/openv/netbackup/bin/goodies
PATH=$PATH:/usr/openv/netbackup/bin/admincmd:/usr/openwin/bin
LD_LIBRARY_PATH=/usr/lib:/usr/share/lib:/usr/openv/lib:/usr/openv/java/jre/lib
MANPATH=/usr/share/man:/usr/openwin/man:/usr/openv/man
export PATH LD_LIBRARY_PATH MANPATH DISPLAY
set -o vi
ENV=/.kshrc
stty erase ^h

--------------------------------------------------------------------
-------- /.kshrc   file --------------------------------------------------
PS1='[$PWD]# '
export PS1
--------------------------------------------------------------------

바. NetBackup Host Properties 구성하기
 
1). Host Properties 

  ▶ 대부분의 NetBackup Setting을 NetBackupAdministration Console의
      Host Properties Section에서 할 수 있다. Master, Media Servers, Clients
  ▶ /usr/openv/netbackup/bp.conf는 Master Server Host Properties에 대한
     내용을 포함한다.
  ▶ /usr/openv/volmgr/vm.conf는 Media Server Host Properties 대한 내용을
     포함한다.
  ▶ NetBackup Global Attributes는 NetBackupAdministration Console와 CLI를
     통해 구성할 수 있다.

2). NetBackup Host Properties에 접근하기

  ▶ # jnbSA &
  ▶ 왼쪽 창에서 NetBackup Management => Host Properties 선택 =>
      오른쪽창에서 해당 Machine 선택 => 마우스오른쪽 클릭 Properties 선택

3). Mater Server Properties [Page 2-25]

  ▶ Global Attributes
   - 정책과 client에 모든 운영에 영향을 끼침.
   - 설정에 대한 내용은 Master Server의 /usr/openv/netbackup/db/config에
     저장이 됨

A. Wakeup Interval

  ▶ 얼마나 자주 scheduler가 백업을 위한 schedule을 검사하는지에 대한 시간간격
  ▶ bprd가 bpsched를 fork 시키는 시간간격[10분]

B. Schedule Backup Attempts

  ▶ 명시간 시간 기간동안 백업을 완료하기 위해 NetBackup이 시도하는 횟수[12시간당2회]
  
C. Status Report Interval
 
  ▶ NetBackup에 의해 축적된 정보를 Report로 만드는 시간 간격[24시간]

D. Maximum Jobs per Client

  ▶ Client가 동시에 작업할 수 있는 Backup작업의 수[1건]

E. Compress Catalog Interval

  ▶ Image Catalog File를 압축하기 위한 일수

F. Keep Log

  ▶ Master Server가 error/job catalog, debug log정보를 보간하고 있는 일수[28일]

G. Delete Vault Log

  ▶ Vault Session Directory를 유지하는 일수 [30일]

H. Keep True Image Restoration(TIR) Information

  ▶ True Image Restoration(TIR) Information를 보관하고 있는 일수 [1일]

I. Move Restore Job from Incomplete State to Done state

  ▶ 실패한 복구작업이 작업완료상태로 되기전 incomplete state로 남아
     있을수 있는 일수 [7일]

J. Move Backup Job from Incomplete State to Done state
 
  ▶ 실패한 백업작업이 작업완료상태로 되기전 incomplete state로 남아
     있을수 있는 시간 [3시간]

K. Administrator's E-mail Address

  ▶Schedule Backup, Administrator-directed manual backup, NetBackup
     Catalog Backup시 메일로 알림내용을 보낼 메일주소

4). Host Properties : Master Server

  ▶ Addtional Servers에 Media Server가 존재할시
      Media Server는 Master Server 처럼 NetBackup을 관리할 수 있다.

  ▶ Media Server에 Media Server가 존재할시
      Local Media와 Devices만 Console에서 관리 할 수 있다.

  ▶ 두군데 다 존재할 시
      구성정보는 볼수 있지만 Master서버처럼 구성정보를 수정 할 수는 없다.

사. NetBackup 설치 확인하기 [Page 2-28]

  ▶ GUI에서 Active monitor의 Processes tab를 통해 Processes 확인
  ▶ bpps -a 명령을 사용하여 Processes를 확인

  ▶ Master Server에서는 bprd, bpdbm, bpjobd process확인
  ▶ Media Server에서는 vmd process를 확인

아. 보편적으로 발생하는 문제해결

  ▶ Network/Communication
   - 시스템간 ping 테스트
   - NetBackup Service를 가지고 확인
  ▶ Host Communication Setup (/etc/hosts)
  ▶ 부정확한 hostname 확인