engineering/System Eng.2007. 2. 9. 09:32
etting Up the OpenLDAP Server

All the software packages you need to set up an OpenLDAP server areincluded on the CDs or DVD that come with Fedora distributions. Withthose packages installed, you can start configuring your OpenLDAPserver.
Installing OpenLDAP packages

To configure your OpenLDAP server, you should start by installingall the openldap packages from your Fedora distribution. First, checkwhich openldap packages are installed:

# rpm -qa "openldap*"
openldap-2.2.13-2
openldap-servers-2.2.13-2
openldap-devel-2.2.13-2
openldap-clients-2.2.13-2

You only need the openldap-devel package if you are developing LDAPapplications. Otherwise, you can install the openldap package,openldap-clients and openldap-servers packages from the DVD that comeswith this book.
Configuring the OpenLDAP server (slapd.conf)

You configure the access and use of your OpenLDAP databases in the configuration file, /etc/openldap/slapd.conf.
Note

For a more complete description on features you can use in your slapd.conf file, refer to the slapd.conf man page.

1.

Edit slapd.conf. Open the /etc/openldap/slapd.conf file as rootuser, using any text editor. The following steps tell you some of theinformation you might want to change.
2.

Review the schemas. In the slapd.conf file, schemas are includedfrom the /etc/openldap/schema directory that are generally useful forcreating LDAP directories. Other schemas you might use will often relyon these schemas being included. So, unless you know you don’t needthem, don’t delete any of these schemas:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/redhat/autofs.schema

The core.schema file is required for all LDAP directories. Thecosine.schema and inetorgperson.schema files are particularly useful(and needed for this procedure). The nis.schema file is used to provideNetwork Information System data in an LDAP directory.
Tip

The LDAP Schema Viewer (http://ldap.akbkhome.com) enables you toview object classes, attributes, syntaxes, and matching rules forcommon schemas for LDAP. Definitions also point to RFCs that more fullydefine each object class.
3.

Add backend database definitions. In the slapd.conf file, you needto define some backend database definitions. Each set of backenddefinitions applies to a group of databases of the same type.

Here’s an example of how the backend database definitions wouldappear for a computer in the domain named linuxtoys.net (of course, youwould replace linuxtoys and net with those of your own domain):

###################################################
# ldbm and/or bdb database definitions
###################################################

database ldbm
suffix "dc=linuxtoys,dc=net"
directory /var/lib/ldap
rootdn "cn=manager,dc=linuxtoys,dc=net"
access to * by users read

This database is of the type ldbm (Lightweight Directory AccessProtocol Proxy backend), which defines how that data for this databaseare stored. The bdb (Berkeley DB transactional backend) is anothercommon backend database type you could use. The suffix specifies thatqueries to this slapd server for linuxtoys.net are directed to thisdatabase. The directory line identifies the /var/lib/ldap directory asthe location for this LDAP directory.

The rootdn line indicates that root access can be granted tochange data in databases associated with the linuxtoys.netdistinguished name (provided the password is supplied with rootpw, asdescribed in the next step). Access control and other restrictions youmay put on the database do not apply to this user. However, accesscontrol is applied to all other users, who are given read-onlypermission.
4.

Add a password. In the slapd.conf file, you need to enter thepassword that is required to modify your OpenLDAP backend database. Bydefault, the rootpw line defines a clear-text string that is yourpassword. The password will give you full control of the backenddatabase. It will look something like the following:

rootpw mysecret

Note

If you are going to use a clear-text password, you should makesure that your slapd.conf file has read permissions closed to the world(chmod 640 /etc/openldap/slapd.conf). See the "Creating an encryptedpassword" sidebar for information on creating an encrypted password toaccess your OpenLDAP backend database.
Image from book
Creating an encrypted password

To create an encrypted password for the administrator of theOpenLDAP database you can use the slappasswd command. You can createthe password using Crypt, SSHA, SMD5, MD5, or SSH encryption. Here’s anexample of creating a password for OpenLDAP using MD5 encryption:

# slappasswd -h {md5} > /tmp/myslap
New password: ********
Re-enter new password: ********
# cat /tmp/myslap
{MD5}uBoM+LOQg5GHHJ2Z4NLu9A==

Enter a password (twice) to create an encrypted MD5 password. Thisexample directs the encrypted password into the /tmp/myslap file, youcan read into the slapd.conf file later. In this example, I had you"cat" the file so you could see what the encrypted password looks like.Your password will be different. Here’s what the rootpw line will looklike with an encrypted, rather than a clear-text password:

rootpw {MD5}uBoM+LOQg5GHHJ2Z4NLu9A==

Image from book
5.

Save slapd.conf. Save your changes to the slapd.conf file and close it.
6.

Check slapd.conf. You can check for syntax errors in your slapd.conf file by running the slaptest command, as follows:

# slaptest
config file testing succeeded

If there were something wrong with the syntax of the file (forexample, if you left off a quote or misplaced a comma), the messagewould say slaptest: bad configuration file! instead. Try to correct theproblem and check the file again.

At this point, you can try starting the OpenLDAP
Starting the OpenLDAP service

You start the OpenLDAP as you do most services in Fedora Core and otherRed Hat Linux systems, using the service and chkconfig commands. Theservice name for OpenLDAP is ldap. To start the service immediately,type the following:

# service ldap start
Starting slapd: [ OK ]

To set the ldap service to start each time the system is rebooted, type the following:

# chkconfig ldap on

By default, the ldap service will have read permissions open to everyone.
Posted by theYoungman
engineering/System Eng.2007. 2. 8. 13:32

[리눅스 삭제]

리눅스 삭제는 리눅스내에서 fdisk를 이용해 삭제해야합니다.

윈도우 FDISK나 CD로 한다면 삭제하지 못할 경우도 있습니다.


1. root로 로그인


2. # fdisk  /dev/hda 입력

fdisk에서 명령을 내릴 수 있는 프롬프트가 나타납니다.


3. Command  (m for help) : p 입력

하드디스크 분할 영역 정보가 출력됩니다.

/dev/hda1 영역은 남기고 나머지를 삭제합니다.


4. Command  (m for help) : d 입력

Partition number  (1 - 7) : 삭제하고자 하는 분할 영역 숫자를 입력하면 됩니다.

다시 파티션 정보를 보려면 p 입력

방금 삭제한 분할영역이 없을겁니다.

이런식으로 /dev/hda1 영역을 제외한 나머지를 삭제합니다.

다 삭제했으면 저장하고 나가기 위해 w 입력합니다.

** 만약 분할영역 삭제를 잘못 진행했을 경우 q를 입력해 저장하지 않고 빠져나오세요.

그리고 처음부터 다시 진행하면 됩니다.


5. 마지막으로 MBR 영역에 남은 LILO를 삭제해야합니다.

# lilo -u 입력

** 만약 부트로더를 Grub로 설치했을 경우 lilo로 바꿔준 다음 삭제합니다.

# /sbin/lilo 입력


6. 이제 리눅스 삭제는 완료되었고 CMOS에서 부팅 순서를 정해 윈도우로 부팅하면 됩니다.

FDISK나 윈도우 CD로 부팅해서 파티션 분할, 포맷하고 설치하면 됩니다.


** 만약 부트로더(LILO,Grub)를 삭제하지 않고 윈도우를 설치했다면 윈도우로 부팅이 안될겁니다.

부트로더를 제거해야합니다.


윈도우 부팅 디스켓을 이용해서 MBR 영역을 삭제할 때

A: > fdisk  /mbr

Grub라면 (shift + F5)

A:\ > fdisk /mbr


** 윈도우 CD를 이용해서 MBR 영역을 삭제할 때

윈도우 CD로 부팅

R 입력 --> 복구콘솔

C:\ fixmbr 실행  --> yes

C:\ fixboot 실행 -->exit 입력하고 복구콘솔 종료하면 삭제됩니다.


//추가 답변//

PXE-E61 : Media test failure, check cable

부팅시 LAN으로 부팅될 때 나타나는 메세지입니다.

CMOS에서 부팅 순서를 다시 잡아 보시고 LAN 부팅은 사용안함으로 설정해보세요.

그래도 안될 경우 하드디스크 캐이블 다시 한번 점검하고,

다른 컴퓨터에서 테스트 해보는 것도 좋을겁니다.

Posted by theYoungman
engineering/Network Eng.2006. 11. 29. 01:05

출처 - http://www.alov.co.kr/trackback/87

Load balancing은 Destination까지 가는데 다중 경로가 있을 경우 Router 가 이를 이용할 수 있도록 하자는 생각에서 출발했다. 이러한 경로는 RIP, EIGRP, OSPF, IGRP와 같은 동적인 라우팅 프로토콜이나 정적인 라우팅 프로토콜인 static(Default Routing 포함)을 통해 구성 할 수 있다. Load Balancing은 동일한 Cost 값을 갖는 경로(equal cost path)와 서로 다른 코스트 값을 갖는 경로(unequal cost path) 모두 고려할 수 있다. IGRP나 EIGRP와 같은 특정한 Routing Protocol은 unequal cost Load Balancing과 equal cost Load Balancing 모두를 지원한다. IGRP와 EIGRP에서 unequal cost Load Balancing을 작동시키기 위해서는 variance Command을 사용할 수 있다.

Router#
Ex>Router# conf t
Router# router igrp 1237
Router# variance <1-128>

equal cost 경로가 있는 지 확인하는 것은 보통 show ip route 명령어를 사용한다. 예를 들어, 아래에 보이는 것은 show ip route를 사용해서 여러 경로를 갖는 특정한 Subnet의 정보를 나타낸 것이다. 두 개의 routing descriptor block이 있다는 것을 주의해라. 각 블록이 하나의 경로가 된다. 그리고 하나의 block entry에는 asterisk(*)가 있다. 이것은 다음번 새로운 트래픽은 이 경로를 사용하게 되는 것을 의미한다.

Router#
M2515-B#show ip route 1.0.0.0
Routing entry for 1.0.0.0/8
Known via "rip", distance 120, metric 1
Redistributing via rip
Advertised by rip (self originated)
Last update from 192.168.75.7 on Serial1, 00:00:00 ago
Routing Descriptor Blocks:
* 192.168.57.7, from 192.168.57.7, 00:00:18 ago, via Serial0
Route metric is 1, traffic share count is 1
192.168.75.7, from 192.168.75.7, 00:00:00 ago, via Serial1
Route metric is 1, traffic share count is 1

equal cost 경로는 6개 까지만 가능하다.(이러한 제한은 Cisco IOS에 의해 정해진다. ) 그러나 어떤 Interior Gateway Protocols(IGPs)는 프로토콜 자체에 의해 더 작은 경로로 제한한다. 예를 들어, EIGRP는 네 개까지 equal cost 루트를 가질 수 있다.

목적지 단위로 Load balancing을 할 것인지 아니면 Packet 단위로 Load balancing을 할 것인지를 Router에서 설정할 수 있다. 목적지 단위 Load Balancing은 Router가 목적지 주소를 근거로 하여 Packet을 전달하는 것을 의미한다. 같은 Network로 가는 두 가지 경로가 주어졌을 때, 그 네트워크에 있는 목적지1로 가는 모든 Packet들은 첫 번째 경로를 통해서 가게 되고, 목적지2로 가는 Packet들은 모두 두 번째 경로를 통해서 가게 된다.

IP packet의 경우, 목적지 단위로 Load Balancing을 할지 또는 Packet 단위의 Load Balancing을 할지는 Switch 형태에 따라 결정된다. 대부분의 Cisco Router는 기본값으로 fast switching을 Interface에서 설정되어 있다. fast switching을 위한 Caching 구조는 목적지 단위 Load Balancing을 하도록 설정되어 있다. Packet 단위 Load Balancing으로 수정하려면, 다음과 같은 명령어를 사용한다.

Router#
Router# config t
Router(config)# interface Ethernet 0
Router(config-if)# no ip route-cache
Router(config-if)# ^Z

위와 같이 설정하게 되면, Router의 CPU는 모든 하나 하나의 Packet을 조사하고 목적지 네트워크에 대한 Routing Table 상에 나타나는 경로에 따른 수만큼 Load Balancing하게 한다. 이것은 CPU가 모든 Packet에 대해서 처리를 해야 하기 때문에 Low-End급의 Router(예를 들면 Cisco 2501 정도)에서 위험해질 수 있다. Fast switching을 다시 설정 하기 위해서는 아래와 같은 명령어를 사용한다.

Router#
Router# config t
Router(config)# interface Ethernet 0
Router(config-if)# ip route-cache
Router(config-if)# ^Z

Cisco Express Forwarding(CEF)을 사용하면 보다 빠른 Packet 단위 Load Balancing과 목적지 단위 Load Balancing을 할 수 있다. 하지만 그것은 CEF entry와 adjacency를 유지하기 위해 추가적인 자원을 가지고 있어야 한다는 것을 의미한다.

Posted by theYoungman
engineering/Network Eng.2006. 11. 29. 01:03
IS-IS

IS-IS는 intermediate System to Intermediate System
의 약자이다.
IOS에서 예전에 connectinless network protocal(CLNP)를 위한 라우팅 프로토콜로 만들었다가 TCP/IP가 대중적으로 인기를 끌면서 OSI 기반의 프로토콜(IP)이 대두되면서 Intergrate IS-IS를 계발하였다. intergrate IS-IS는 IP도 라우팅이 가능하게 되었다. IS-IS도 OSPF와 마찬가지로 link-state 프로토콜이다.

IS-IS 와 ospf의 공통점

1. Dijkstra-based SPF로 링크정보를 계산한후 state database 정보를 유지.
2. adjacency을 형성하고 위지하기 위해 Hello 패킷을 이용.
3. two-level 계층적 토플로지를 형성하기 위해 area 개념을 사용.
4. 두 area 간의 summarization을 제공.
5. classless 제공.
6. broadcast 환경에서 ospf오 마찬가지로 DR 선정.
7. 인증기능 제공..


구성...

◈ sub area의 라우터들을 Level 1 이라고 한다.
◈ sub area와 연결된 backbone 라우터들을 Level 2라고 한다.
◈ sub area와 backbone area가 접해있는 라우터를 Level 1/2라고 한다.

IS-IS도 ospf와 마찬가지로 한 area의 모든 라우터들은 neighbor을 가지며 동일한 database를 유지한다.
그리고 각각 neighbor들은 자신의 database를 area 안의 모든 라우터들에게 flood한다.
정보를 받은 라우터는 destination에 대한 가장빠른 path를 SPF알고니즘을 이용하여 찾는다.
새로운 link-state packet(LSP)가 만들어지거나 수신될때마다 라우터들은 Dijkstra알고니즘을
수행하여 새로운 경로를 계산한다.

IS-IS 내의 라우터들은 intermediate system(IS)라고 부른다. 각 IS들은 Hello packet를 이용하여 다른 IS들과 adjacency를 형성한다.


용어정리

◈ IS(intermediate system) : 라우터나 라우터 노드
◈ DIS(Designated intermediate system) : BC 환경에서 선출되는 라우터
◈ ES(End system) : IS의 의존하여 통신을 하는 호스트들
◈ NSAP(Network Service access Point) : IS의 주소
◈ Net(Network entity title) : 정보를 단지 라우팅 하는데 사용하기 위한 NSAP address의 마지막 바이트
◈ PDU(Protocol data unit) : 프로토콜 패킷
◈ PSNP,CSNP : 여러종류의 매체에 대해 database 를 동기화하는데 사용되는 프로토콜
◈ IIH(intermediate system - to intermediate system hello) : 다른 is를 찾기 위한 PDU


※ IS-IS에서 라우터는 IS 이고 호스트는 ES이다.

호스트와 라우터는 ES-IS이며 라우터와 라우터는 IS-IS이다.

간단한 구성..


한노드에서 다른 노드로 전달되는 데이터 유닛을 PDU(protocol data unit)라고 한다.
프레임은 DLPDU(data link PDU) 그리고 패킷은 NPDU(network PDU)이다.

IS-IS도 OSPF의 LSA와 같은 역활을 하는 유닛을 LINK STATE PDU(LSP)라고 한다.
LSA 와 LSP의 차이점은 LSP는 그 자체가 하나의 패킷이다. 하지만
OSPF에서는 이를 encapsulation 된다.

IS-IS의 어드레스 포멧..

IS-IS에서 어드레스 명칭은 NASP(network service access point)로 각 노드를 정의한다.

IDP : Initial Domain Part
DSP: Domain Specific Part
AFI : Authority Format Identifier
IDI : Initial Domain Identifier
HO-DSP: High-Order Domain Specific Part
Area ID: Area Identifier
System ID: System Identifier
N Sel: N-Selector

ISIS 라우터는 하나의 area에 속하기 때문에 area address는 interface 단위가 아닌 라우터 전체가 area에 속해야 한다.
하나의 라우터는 최대 3개의 area address 를 가질수 있다.
라우터는 Network Entity Title(NET)를 box 단위로 구성한다.

이는 인터페이스의 어드레스가 unique해야 한다는 것이 아닌 라우터자신의 SystemID가 unique 해야한다는 것이다. ospf의 routerID와 비슷하다.
area address와 systemID는 ISIS 라우터에서 하나의 address를 정의하며 이를 NET라고 부른다. NET으로 설정하기 위해서는 Nselector 가 0으로 설정되어야 한다.

IS-IS address 형식.

48.0001.0000.0000.0001.00

area address : 48.0001
system ID : 0000.0000.0001
N sel : 00

NET을 할당하기 위해서는 다음 세가지 규칙.

1. NET은 47.XXXX……처럼 1 octet을 가지고 시작해야한다.

2. NET은 1 octet을 가지고 끝나야 하며 0x00으로 설정되어야 한다.

3. Cisco 라우터에서 NET의 System ID 부분은 6 octet이여야 한다.

ISO network address에 대한 좀 더 자세한 내용은 RFC 1237을 참조한다

IS-IS area

IS-IS는 two-level 계층을 가지는 토플로지를 지원하기 위해 area란 개념을 사용한다.

예를 들어 ospf에서는 area와 area를 연결하는 라우터를 ABR이라고 하는데 ospf의 ABR은 두 area사이에 걸쳐있다. 한마디로 서로다른 area에 속한다는 것이다.

하지만 IS-IS에서는 모든라우터가 완벽하게 독립적인 area에 속한다. 다시말해 area의 경계는 라우터가 아닌 라우터의 인터페이스이다. 하나의 area에 독립적인 라우터를 level-1 라우터라 부른다.

그리고 백본 area의 라우터를 level-2 라우터.. area 사이에서 중계하는 라우터를 level-1/2라우터라 부른다. level-1/2라우터는 각각 area의 database를 동시에 유지한다. ospf와 같은 의미이다.

한 area내의 모든 라우터는 같은 database를 유지한다. 하지만 L1/2라우터는 L1 라우터에게 L2경로를 제공하지 않는다. 그러므로 L1라우터는 area 외부의 destination정보를 가지고 있지 않다.
이는 ospf의 totally stubby area와 같은의미이다.

하지만 L1라우터는 외부로 나가기는 해야 하기 때문에 L1/L2라우터는 area 안으로 L1 LSP를 보낼때 LSP내의 Attached(ATT)라는 bit를 1로 해서 보낸다. bit가 1로 되어있다는 것은 이 LSP를 보낸 L1/L2라우터가 다른 area로 가는 정보를 가지고 있다는 의미이다.

ospf area.

OSPF의 area 사이의 ABR은 각 area에 걸쳐 있다.
IS-IS area ..

IS-IS의 area를 묶는 라우터들은 오직 하나의 area에 속한다.

simple is-is configuration(one area)


R1
interface loopback 0
ip address 172.16.1.1 255.255.255.255
interface ethernet 0
ip address 172.16.12.1 255.255.255.0
ip router isis

router isis
passive-interface loopback0
net 49.0001.1720.1600.1001.00

R2

interface loopback 0
ip address 172.16.2.2 255.255.255.255
interface ethernet 0
ip address 172.16.12.2 255.255.255.0
ip router isis
interface serial 0
ip address 172.16.23.1 255.255.255.252
ip router isis

router isis
passive-interface loopback0
net 49.0001.1720.1600.2002.00


R3
interface loopback 0
ip address 172.16.3.3 255.255.255.255
interface serial 0
ip address 172.16.23.2 255.255.255.0
ip router isis

router isis
passive-interface loopback0
net 49.0001.1234.1600.2231.00

Simple is-is configuration (multi area)

간단한 설정인데 serial 0는 BackBone 와 연결되어 있는 link etheret 1 과 2 는 오직 하나의 area 안에 있는 link

Router#
clns routing
int serial 0
ip address 10.0.0.5 255.255.255.0
ip router isis BB (BackBone area 연결 link)
clns router isis BB
int ethernet 1
ip address 10.1.1.5 255.255.255.0
ip router isis A3253-01 (isis tag를 A3253-01 로 설정)
clns router isis A3253-01

int ethernet 2
ip address 10.2.2.5 255.255.255.0
ip router isis A3253-02 (isis tag를 A3253-02 로 설정)
clns router isis A3253-02

router isis BB (is-type의 아무런 설정이 없을 경우 L1/L2)
net 49.2222.0000.0000.0005.00

router isis A3253-01
net 49.0553.0001.0000.0000.0005.00
is-type level-1 (
is-type level-1 라우터로 설정)

router isis A3253-02
net 49.0553.0002.0000.0000.0005.00
is-type level-1 (is-type level-1 라우터로 설정)

Posted by theYoungman
engineering/ITSM / ITIL2006. 11. 19. 23:56
출처 블로그 > 슈마의 네트워크 이야기
원본 http://blog.naver.com/airbag1/80010741207

"ITIL 자격증이 힘이다"

[전자신문 2005-03-04 09:23]  

올해 국내 IT 시장은 그 어느 해보다도 발전적인 변화가 많았던 시기로 평가되고 있다. 온 디맨드 컴퓨팅 또는 유틸리티 컴퓨팅이라는 새로운 IT 패러다임을 시작으로 전통적인 SMS 시장에 변화가 예고되었고, ITIL 기반의 IT 서비스 관리라는 영역은 시장에 엄청난 효과를 불러 일으켰다.

정보기술(IT) 환경이 나날이 복잡해짐에 따라, 컴퓨팅 인프라의 관리 및 보장에 대한 중요성이 그 어느 때보다 증대되고 있으며, 기업들은 비즈니스 환경에 가장 적합한 최적의 실용사례에 의존하지 않을 수 없게 된 것이다.
비즈니스 상황에 따라 적절한 실용사례를 구현할 경우, 기업들은 위험을 덜 감수하면서도 보다 효과적으로 비즈니스 프로세스를 표준화하고 IT 환경을 관리할 수 있다는 점이 기업들이 주시하고 있는 부분이다. 이러한 실용사례에는 ITIL(Information Technology Infrastructure Library), BS(British Standard) 15000 등 국제적인 지침들이 있다.
이 같은 실용사례를 바탕으로, 기업들은 각자의 비즈니스 요구사항에 맞게 관련 프로세스를 효과적으로 수정, 보완할 수 있다. 이는 곧, 기업별로 맞춤화된 방법을 적용하기 위해서는 해당 툴의 융통성이 보장되어야 한다는 것을 의미하기도 한다. 물론 각 IT벤더들은 기업들이 ITIL, BS15000 및 ISO 17799 표준에 따라 e비즈니스 IT 서비스를 비용효율적으로 구현하는 데 일조하기 위한 솔루션들을 선보이고 있는 것이다.

이러한 IT 서비스 관리에 대한 관심은 한 순간에 사그라지는 과거의 IT 유행과는 확연히 다른 것이다. 그 이유는 ITIL에 기반한 IT 서비스 관리는 바로 IT운영의 베스트 프렉티스를 의미하는 것이기 때문이다. IT 서비스 관리에 대한 패러다임은 하나의 개념으로 고정되어 있는 것이 아니라 지속적으로 IT의 발전과 함께 빠르게 발전하고 항상 존재할 것이다.
그렇다면 어떤 방향으로 발전을 거듭할 것인가에 대한 방향성은 어떤가? 이는 너무도 자명하게 IT관리의 모든 영역을 한데 묶는 통합으로의 발전이 더욱 가속화될 것이라는 것이다. IT의 모든 자산인 인력, 기술 및 프로세스에 대한 관리를 ITIL 기반의 관점에서 재정의하고 구축하려는 IT관리의 새로운 기술이 시스템 관리의 표준으로 자리잡으면서 시스템 관리, 보안, 스토리지 및 개발 등의 일련의 IT 환경 요소들이 통합적으로 관리되고 기업의 비즈니스 변화에 유연하게 대응할 수 있는 온 디맨드형 통합관리 환경으로 가는 것이다.

온 디맨드형 컴퓨팅의 개념은 매력적이지만, 이를 실현하기 위해서는 IT 인프라에 대한 관리를 비즈니스적 관점에서 자동화해야 한다는 것이다. 여기에는 유연하고 동적인 자동화된 비즈니스 프로세스가 필요하다.

User inserted image

또, 이런 프로세스는 비즈니스 요구에 적합하며 효율적이고 효과적이면서도 강력한 것이어야 한다. 최적의 모범사례가 필요한 것도 이 때문이다.
베스트 프렉티스는 전체적인 효율을 높이고 비용을 절감하며 비즈니스 요구에 부합하는 IT 시스템을 구축하는 데 필요한 IT 관리 프로세스를 설계할 수 있도록 길잡이가 되어준다.
이처럼 사용자가 운영 효율을 개선할 수 있도록 안내해주는 베스트 프렉티스로 ITIL에 대한 각 기업들의 관심이 고조되고 있는 것이다.

ITIL은 효과적인 IT 서비스 관리를 목표로 하는 일련의 모듈로 구성되며, 각 모듈은 IT 서비스 관리의 베스트 프렉티스에 대한 가이드라인을 제시한다.

ITIL을 통해 IT 조직은 IT 서비스의 품질을 관리하고 효율을 개선하며 유효성을 높이고 위험을 완화할 수 있다.

ITIL 프로세스는 명령하는 것이 아니라, 조직의 비즈니스 프로세스를 뒷받침해야 한다. IT 서비스 공급자는 서비스의 품질을 개선하는 한편으로 비용을 억제하거나 절감하기 위해 안간힘을 쓰고 있다.

이와 같은 베스트 프렉티스는 다양한 영역에서 IT 환경과 비즈니스의 품질을 개선하는 데 유용하지만, 이를 실현하기 위해서 몇몇 주요 기업들은 이미 프로세스 컨설팅 단계를 넘어서 프로세스 정의의 자동화를 지원할 솔루션을 검토하고 있는 단계이다. 이에 맞춰 각 글로벌 IT 벤더사들도 속속들이 관련 솔루션들을 선보이고 저마다 공격적인 마케팅을 하고 있다.

CA를 비롯한 관리 소프트웨어 회사들이 새롭게 선보이고 있는 여러 기술, 유틸리티 컴퓨팅이나 온 디맨드 컴퓨팅 등의 컨셉트, 그리고 ITIL에 기반한 서비스 관리를 실질적으로 각 기업이 명확한 ROI를 경험할 수 있는 방향으로 정착시키기 위해서는 기업들, 특히 기업의 CIO 들에게 새로운 IT 관리에 대한 개념의 대해 충분한 전달이 필요하다.

또한 지난 2000년도 초부터 불기 시작한 정보보호컨설팅과 더불어 기업이 보유하고 있는 IT 자산에 대한 평가를 위한 ITIL을 기반으로 한 시스템관리컨설팅 분야의 활성화 여부가 새로운 솔루션 성패의 관건 중 하나이다. 그리고 고객의 요구와 환경에 맞는 고객 중심적인 솔루션 개발도 시장에 영향을 미치는 요소 중의 하나이고, 또한 ITIL과 관련된 단체들의 활동도 2005년도 시스템관리솔루션 시장에 많은 영향을 미칠 수 있다.

User inserted image

ITIL은 IT 서비스 관리를 위한 베스트 프렉티스 가이드라인을 제공한다. ITIL은 현재는 물론 향후의 비즈니스 요구 및 고객의 요구와 부합하는 IT 서비스를 구축할 수 있도록 지원할 것이다. 이 베스트 프렉티스는 IT 서비스의 전체적인 품질을 향상시키고 장기적인 서비스 공급 비용을 절감하기 위해 개발된 것이다. 이제 IT 시장은 이와 같은 목표를 실현할 수 있도록 지원하는 큰 방향으로 진행될 것이다. IT 운영은 SLA관리, 서비스데스크 및 IT 자원관리의 통합을 통해 서비스 관리를 위한 포괄적 기능의 ITIL 솔루션들이 핵심을 이룰 것이다.
따라서 서비스 관리, IT 자원 관리, 운영 관리 솔루션간의 긴밀한 통합은 진정한 의미에서 프로세스 중심의 IT 관리를 가능케 하기 때문이다. 이미 각 기업들이 ITIL 기반의 서비스 관리 솔루션 적용을 검토하고 있으며, 앞으로도 많은 기업들이 ITIL 베스트 프렉티스에 의거한 프로세스 정립과 솔루션 적용을 진행할 것이 확실하다. SMS 시장이 전반적으로 포화상태라는 이야기가 있지만 ITIL 기반 솔루션의 바람몰이는 SMS 시장 활성화에 큰 역할을 할 것이다.

CA@focus, 2005 Winter Vol 16.


===========================================
IT서비스관리(ITSM) 관련 세계 표준화 참조모델인 ITIL(Information Technology Infrastructure Library) 자격증 획득이 봇물을 이루고 있다.
 보통 기업들이 추진하는 국제 인증 ‘BS 15000’이 ITIL 기반의 IT 프로세스를 갖추고 있다는 것을 증명하는 인증이라면, 개인들이 취득하는 ITIL 자격증은 ITSM을 구축하기 위해 필요한 컨설팅을 제공할 수 있는 능력이나 구축 후 변화 관리를 직접 처리할 수 있는 능력을 보유하고 있음을 인증해주는 의미다.


 SI 및 주요 솔루션 업체들은 ITIL 일반 파운데이션(기초) 과정은 물론 최고 전문가 과정인 ‘마스터’ 자격증을 보유한 인력을 업체별로 많게는 수십여명 확보하고 있는 것으로 확인됐다.

 특히 대부분의 업체들이 자격증 획득에 필요한 교육비를 지원하는 등 적극적인 지원책을 가동하고 있다는 점에서 과거 어느 자격증 획득 바람과 차별화되고 있다.


 SI 업체 중 ITSM에 가장 적극적으로 나서고 있는 삼성SDS는 올해까지 ITIL 마스터 누적 숫자를 100여명까지 늘린다는 방침을 정하고 관련 지원을 아끼지 않고 있다. 이와 함께 오는 4월 자체적으로 마련한 ‘ITIL 프로세스 실무자’ 과정도 개설, 올해 말까지 삼성그룹 계열사 서비스 관리(SM)를 담당하는 임직원 3700여명을 대상으로 ‘ITIL 기초(Foundation)’

Posted by theYoungman
카테고리 없음2006. 11. 12. 10:58




ㄱ. 일단 공개버전의 Ghostscript 와 MakePDF를 구합니다.
       -- 네이버나 기타 검색창에서 검색을 하면 바로 구할 수 있음.
       Ghostscript는 용량이 5.631M정도(gs800w32.exe)(http://www.cs.wisc.edu/~ghost/)
       MakePDF는 용량이 30KB정도(makepdf25.zip)(http://www.lexacorp.com.pg/)   

  ㄴ. 시작-설정-프린터를 열고 프린터추가를 누른다.
       -프린터추가마법사에서 설정은 -로컬프린터
       -프린터의 종류는 HP DesignJet 755CM/PS나 Apple Color LW 12/660 PS등
        Postscript가 가능한 프린터를 설정한다.
       -프린터사용할 포트는 “FILE : 디스크에 파일작성”을 선택 -중요-
       -기본프린터 사용 안함
       -시험인쇄 안함
  
       그러면 새로운 프린터가 설치됨.
       프린터 가능한 파일은 모두 PDF로 변환이 가능함.

  ㄷ. Ghostscript를 설치함. (아무설정없이 Setup-Install을 누름-그러면 마침)

  ㄹ. MakePDF를 설치함.(일단 필요한 곳, 바탕화면에 바로가기나 복사를 함.)
       처음실행을 하면 Select Input File을 찾음. 그러면 Ghostscript가 설치된
       C:/gs/gs8.00/bin/ 폴더내의 gswin32파일을 선택해줌.
       그러면 MakePDF가 설치됨과 동시에 MakePDF창이 실행됨-끄면 됩니다(Quit).

       일단 설치가 다 끝났으므로 사용하는 방법을 알려드림.

    ㅁ. 원하는 문서(doc, hwp or etc)를 프로그램(MS Word, 한글 등 기타 프린터 가능한
       프로그램)상에서 인쇄를 함.

   ㅂ. 프린터 이름은 위에서 새로 설치한 Postscript가 가능한 프린터를 선택하여
       인쇄를 함.

  ㅅ. 사용폴더를 지정하여 파일명을 기입하고 확인을 누르면 지정 폴더에
      *.ps파일이나 *.prn파일이 생김.

   ㅇ. MakePDF를 실행함, Input File Name에 위에 생성된 *.ps or *.prn파일을 지정하고
       Output Drectory를 지정하고 MakePDF를 누르면 PDF파일 생성됨. 끝
       (컴터 성능에 따라 생성속도가 약간씩 차이가 있으나 기다리면 “확인” 버튼이 생김.)


Posted by theYoungman
engineering/Network Eng.2006. 10. 26. 22:25
 

2. IETF 표준화 절차


1) IETF 문서

모든 IETF 표준문서는 RFC(Request For Comments)로 출간된다⑩. 또한, 모든 RFC 문서는 처음에 I-D(Internet Draft) 상태로 시작하며, I-D 문서가 RFC 문서로 채택되기까지의 과정은 대략 다음과 같다[4].

       (1) 작성한 작업문서를 I-D로 등록한 후, 문서내용에 대한 Comments를 받는다.

       (2) Comments를 기반으로 I-D를 수정한 후 재등록 한다.

       (3) 상기 (1), (2)의 과정을 반복한 후, 문서내용이 견고해졌다고 판단되면, 해당        AD에게 IESG 검토를 요청한다.

       (4) 이후 IESG 검토 작업이 진행되고, 검토과정에서 추가의견이 발생하는 경우 다        시 (2)번 과정으로 되돌아갈 수 있다. IESG 검토에서 승인되는 경우 RFC Editor에        의해 RFC로 출간된다.



2) I-D(Internet Drafts)

I-D는 IETF 표준화의 시작점으로써, 개인(individual) I-D와 WG I-D로 구분된다. 누구나 개인 I-D를 IETF에 등록할 수 있으나, WG I-D의 경우 WG 의장 및 관련 WG 전문가들의 합의에 의해서 등록된다. 사실상 WG I-D는 IETF의 공식문서로 볼 수 있다.

대개의 경우, IETF 표준화를 위해서는 먼저 개인 I-D를 제출한 다음, 이를 토대로 WG에서의 E-mail 토론 혹은 IETF WG 회의 발표 등을 통하여, WG의 합의를 도출해내야 한다.

이처럼 개인 I-D에서 WG I-D로 승인 받는 과정이 IETF 표준화의 핵심이라 볼 수 있다. 일단, WG I-D로 채택되면, 추가적인 WG 검토 및 보완작업을 마친 후, WG 의장이 해당 AD에서 RFC 승인을 요청하게 된다.



3) RFC(Request For Comments)

모든 IETF 공식문서는 RFC로 출간된다. RFC는 크게 표준문서(Standard Track)와 비표준문서(Non-standard Track)로 구분되며, 총 6가지 종류의 RFC가 있다.

       (1) Proposed Standard

       (2) Draft Standard

       (3) Internet Standard (or Full Standard)

       (4) Experimental

       (5) Informational

       (6) Historic

처음 3가지는 표준문서에 해당하며 나머지는 비표준문서에 해당한다. 다음 그림은 상기 6가지 RFC간의 상호관계 및 진행절차를 보여준다.


그림에서 알 수 있듯이, 표준문서 문서의 경우 I-D에서 출발하여 Proposed, Draft 표준을 거쳐 최종적인 Internet Standard로 승인된다. 모든 RFC 문서는 새로운 문서에 의해 개정될 수 있으며, 이 경우 별도의 새로운 RFC 문서번호를 받게 된다. 문서가 개정되는 경우, 이전 RFC 문서는 Historic RFCs로 남는다.

IETF에서는 RFC 일련번호와는 별도로 다음과 같이 3종류의 부가적인 일련번호를 관리하고 있다.

       o FYI (For Your Information)

       o BCP (Best Current Practice)

       o STD (Standard)


FYI 문서는 주로 독자들의 관심이 높으며 개론적인 내용을 담은 RFC를 선정하여 별도의 일련번호를 부가하며⑪, BCP 문서는 인터넷에 일반적으로 적용될만한 내용을 담은 RFC를 대상으로 일련번호를 부여한다⑫. STD 문서는 용어 그대로 “완전한 인터넷 표준”에 해당하는 표준문서이다⑬. 2003년 9월 현재 등록된 RFC는 3500여개에 달하며, 부가적인 일련번호의 경우 STD는 62번까지, FYI는 38번까지, 그리고 BCP는 73번까지 부여되었다. RFC 표준문서의 경우 STD 번호를 받기까지 다음과 같은 절차가 진행된다. 먼저 I-D 제출 후 충분한 의견수렴 및 개정이 이루어졌다고 판단될 경우, 해당 저자는 AD에게 RFC 승인을 위한 IESG 검토를 요청한다. WG I-D의 경우 먼저 WG Last Call을 거친 후에 WG 의장이 AD를 통해 IESG 검토를 요청하며, 개인 I-D의 경우 바로 AD에게 요청한다. IESG에게 제출된 경우, IESG는 IETF 차원의 Last Call을 추진하게 되며, 이 과정에서 승인을 거부하거나 문서에 대한 추가적인 수정작업을 요청할 수 있다. 일단 IESG 승인을 받게 되면 I-D는 RFC Editor에게 전달되어 RFC 번호를 할당받고 Proposed Standard 문서가 된다. Proposed Standard 상태에서 6개월 이상이 경과한 다음, WG 의장은 해당 문서를 Draft Standard로의 승인을 요청할 수 있다. 단, 이를 위해서는 두 군데 이상에서 관련 프로토콜을 구현하고, 구현코드간 상호운용성이 보장됨을 증빙할 수 있어야 한다. 실제 인터넷에서 사용되고 있는 많은 프로토콜이 Proposed Standard 상태에 머무르고 있다. 최종적으로 Draft Standard 상태에서 상당한 시일이 지난 후에 Internet Standard로의 승인을 요청할 수 있다.


Posted by theYoungman
카테고리 없음2006. 10. 10. 10:54
// 먼저 이글은 SLR Club의 강좌란에 'jjungi'님이 올리긴 게시물이 원본임을 밝혀 둡니다.
// 'jjungi'님의 허락없이 다른 곳에 게시물을 올리시면 안됩니다.
// 원본 게시물 주소 :
http://www.slrclub.com/bbs/vx2.php?id=user_lecture&page=1&sn1=&sid1=&divpage=1&sn=off&sid=off&ss=on&sc=off&select_arrange=headnum&desc=asc&no=3309
// 저도 허락을 받고 제 블로그에 올립니다. 허락해 주셔서 감사합니다.^^

// 다음은 'jjungi'님이 올리신 저작권 관련 공지(?)시네요..^^

벌써 민족의 대 이동이 시작되는 추석입니다~
모두 즐건 추석 되시구요~~ 나름 열심히 써본 강좌 올라갑니다
조금이나마 도움이 되시길 바랍니다~^^
SLRCLUB에 게시하기 위해 작성한 것이라 다른곳에 퍼가진 않길 부탁드립니다...^^


Posted by theYoungman
engineering/ITSM / ITIL2006. 9. 27. 14:27

[Tech Report - ITSM과 ITIL ②]

서비스 관리의 표준 프로세스

ITIL에 근거한 서비스 서포트와 딜리버리


지난 호에서는 ITIL과 ITSM의 개념과 필요성에 대해 알아보았다. 이번 호에서는 ITIL에서 정의하는 두 영역, 즉 서비스 서포트(Service Support)와 서비스 딜리버리(Service Delivery)에 대한 각각의 프로세스와 그 기능에 대해서 살펴보도록 한다.

장인석/ 한국HP 교육사업부 대리 in-suk.jang@hp.com

1. IT 서비스를 위한 ITSM과 ITIL (2003년 9월호)

2. ITIL에 근거한 Service Support와 Service Delivery(이번 호)



서비스 서포트
서비스 서포트(Service Support)는 고객이 비즈니스에 필요한 IT 서비스를 제공하기 위한 프로세스들이다. 이 영역에서는 서비스 레벨 매니지먼트(SLA)에 정의된 서비스 품질을 보장하도록 IT 서비스를 운영하는 절차들에 대해 기술하고 있으며, IT 인프라에 대한 관리와 가용성 보장을 위한 장애 처리 절차, 서비스 데스크에 대한 내용들을 포함하고 있다.

1. Configuration Management
구성관리는 IT 서비스관리 프레임워크의 근간을 형성하며 서비스 서포트 프로세스, 서비스 딜리버 프로세스와 밀접히 관계되어 있다.
구성관리 프로세스에서 담당하는 일들은 다음과 같다.
·Configuration Management
·Planning
·Identification
·Control
·Status Accounting
·Verification & Audit

구성관리는 IT 인프라와 IT 서비스를 구성하고 있는 다양한 종류와 다양한 버전의 구성요소(Configuration Item: CI)를 식별하고 이것들을 데이터베이스화(Configuration Management Data Base: CMDB)하여 관리하는 것을 의미한다. CI는 각종 애플리케이션, 드라이버 등의 소프트웨어와 컴퓨터, 네트워크 장비, 그 부속품 등의 하드웨어들이 될 수 있으며, CI의 범위와 상세 수준은 IT 조직의 규모와 환경에 맞게 설정할 수 있다.
또한 구성관리는 다음과 같은 기능들을 제공해야 한다.
·IT 서비스 관리와 지원 조직에 현재 IT자원의 상세한 구성 정보와 그것들의 물리적, 기능적 정보를 제공
·IT 인프라의 구성요소에 대한 현재 상태와 과거 이력을 기록
·IT 서비스와 구성요소에 대한 관계를 설정하여 구성요소가 서비스에 미치는 영향을 파악
·다른 모든 프로세스에 대한 IT의 기본 정보를 제공

2. 서비스 데스크(Service Desk)
서비스 데스크는 고객, 사용자, IT 조직과 기타 지원 조직 간의 최일선 접점 역할을 하는 중요한 기능 조직이다. 서비스 데스크는 IT 서비스가 이상 없이 운영되는지 관리하며 장애의 최초 접수에서부터 최종 장애가 해결될 때까지 관계되는 다른 모든 프로세스와 긴밀히 정보를 주고받으며 단일 접점(Single Point of Contact : SPOC)의 역할을 수행한다. 또한 장애가 발생하였을 때 비즈니스에 충격을 최소화하도록 사고의 신속한 복구를 가능하게 해야 한다.
이러한 기능들로 인해 고객 만족에 있어 가장 중요한 역할을 하는 조직이 서비스 데스크이다.
서비스 데스크는 다음과 같은 일들을 책임진다.
·서비스 콜의 접수, 등록, 우선 순위화, 이력관리
·등록된 콜에 대한 처리 상태 감시
·장애 처리에 대한 일선 지원 역할 담당 및 2선, 3선 조직의 역할 할당
·장애처리의 종결

3. Incident Management
장애관리 프로세스는 가능한 SLA를 위반하지 않도록 최대한 빨리, 그리고 비즈니스에 영향을 최소로 하여 장애를 해결하는 것이다. 이것은 장애의 근본 원인을 해결하는 것을 의미하지는 않고 비즈니스의 연속성을 유지하도록 IT 서비스의 중단을 해결하는 것이다. 서비스 데스크로부터 통보받은 서비스의 장애를 분석하여 장애를 없애는 것이 목적이며 장애의 근본 원인 해결은 다음에 나오는 Problem Management 프로세스에서 담당한다.
일반적인 장애관리 절차는 다음과 같다.
·Incident Detection and Recording
·Classification of All Incidents and Initial Support
·Investigation and Diagnosis
·Resolution and Recovery
·Incident Closure
장애의 최초 접수는 서비스 데스크에서 하며 SLA를 고려하여 장애의 비즈니스에 대한 충격(Impact)과 긴급성(Urgency)을 기준으로 장애의 우선 순위를 결정한다. 장애에 대한 최초 해결은 일단 서비스 데스크에서 담당하며 해결이 불가능할 경우 장애관리 프로세스로 통보한다.
장애관리에서는 통보 받은 장애에 대한 범주를 식별하는 것(Categorization)이 첫 번째 임무이다. 그 후에 장애의 내용을 분석하여 이미 처리되었던 장애의 유형인지, 알려진 해결책 등이 있는지를 파악한다. 장애를 해결한 경우 이것은 서비스 데스크로 보고되고 서비스 데스크에서 최종 장애에 대한 종결을 담당한다.


4. Problem Management
문제관리 프로세스의 기본적인 목적은 장애관리와 마찬가지로 IT 인프라에서 발생한 비즈니스에 영향을 주는 다양한 문제들을 해결하는 데 있다. 또한 이 프로세스에서는 장애의 근본 원인을 해결함과 동시에 그러한 문제들이 재발되지 않도록 하여 IT 서비스의 가용성을 높이는 기능을 포함하고 있다.
장애관리 프로세스에서는 장애 서비스의 연속성에 초점을 맞추어 장애를 해결하고 장애에 대한 근본 원인의 해결과 장애예방을 위한 방법은 문제관리 프로세스에서 처리되어야 한다.
장애관리 프로세스로부터 발생한 각각의 문제는 먼저 분류되어 다음 해당 지원 조직에 할당되고, 지원 조직은 문제를 분석하여 근본적인 해결책을 찾아낸다. 또한 알려진 에러에 대해서는 데이터베이스를 만들어 나중에 장애관리 프로세스에서 활용하여 신속히 장애를 해결할 수 있도록 해야 하며 알려진 에러의 영구적인 해결을 위해 변경관리 프로세스로 변경요청(Request For Change : RFC)을 할 수 있다.

문제관리 프로세스의 일반적인 절차는 다음과 같다.
·Problem Identification and
Registration
·Classification
·Assigning Resources
·Investigation and Diagnosis
·Establish Known Error



5. Change Management
변경관리의 주 목적은 IT 인프라와 IT 서비스를 이루는 모든 구성요소들의 변경에 대한 표준화된 절차를 만들고, 변경으로 인한 영향이 서비스 품질과 연속성에 주는 영향을 최소로 하도록 효율적인 변경작업을 보장하는 것이다. 기본적으로 ‘변경’은 변경요청에 의해 시작되고 승인된 변경요청만이 실제 변경으로 이어진다. 그러나 변경관리 프로세스가 실제 변경을 구현하는 것을 의미하는 것은 아니며 변경요청에 대한 심사와 승인 및 거부 등의 절차에만 관여한다.
변경관리 프로세스가 모든 변경에 대해 같은 절차를 필요로 하지는 않고 변경의 내용과 다른 프로세스에 미치는 영향에 따라 다른 절차에 의해 변경요청을 처리할 수 있다. 예를 들어 사용자의 패스워드를 변경하는 수준의 변경은 간단한 프로세스들에 의해 처리될 수 있으며 서버의 마이그레이션과 같은 변경은 변경자문위원회(Change Advisory Board : CAB)의 전체 구성원을 소집하여 장기간에 걸친 분석과 검토를 통해 이루어질 것이다.
그리고 전체 위원회의 소집이 불가능한 긴급 변경이 필요한 경우 긴급변경자문위원회(Change Advisory Board Emergency Committee: CAB/EC)를 통해 변경을 처리하도록 할 수 있다.

6. Release Management
많은 IT 서비스들은 다양한 종류의 하드웨어와 소프트웨어에 연관되어 있다. 릴리즈관리의 목적은 이러한 서비스와 연관된 프로덕트들의 릴리즈를 예측하고 적용하여 효율적인 IT 서비스를 제공하도록 하는 것이다.
또한 신뢰할 수 있는 버전의 프로덕트만이 설치되도록 하여 임의의 변경을 방지하고 설치된 내용은 CMDB에 저장하여 릴리즈의 설치 현황과 과거 기록을 조회할 수 있어야 한다. 승인된 릴리즈의 소프트웨어는 Definitive Software Library로 관리하고 승인된 하드웨어는 Definitive Hard ware Store를 통해 관리한다.
릴리즈관리 프로세스는 변경관리 프로세스, 구성관리 프로세스와 밀접히 연관되어 있고 프로세스 간에 필요한 정보들은 CMDB를 통해 공유된다.


서비스 딜리버리(Service Delivery)
서비스 딜리버리 영역은 비즈니스 사용자가 어떠한 IT 서비스와 지원을 요구하는지 파악하여 그것에 적합한 서비스를 서비스 제공자가 사용자에게 지원하도록 하는 데 목적이 있다. 이러한 프로세스들은 고객의 비즈니스와 IT 기술 간의 다리 역할을 하여 비즈니스 목표를 달성하도록 돕는다.

1. Capacity Management
용량관리의 목적은 비즈니스에 요구되는 IT 자원과 성능을 적시에, 그리고 비용 면에서 효과적으로 지원하도록 보장하는 것이다. 이를 위해서는 IT 서비스가 제공하는 성능의 지속적인 모니터링과 기존의 자원을 효율적으로 사용하도록 하는 튜닝 활동이 필요하다. 또한 현재 비즈니스가 요구하고 있는 성능과 향후에 요구되는 용량에 대한 예측과 분석을 통해 용량계획을 수립하여야 한다. 용량계획은 SLA에 기반한 서비스 품질을 기반으로 재무관리(Financial Management) 프로세스와 연계해 수립되도록 한다.
용량관리는 다음과 같은 하위 프로세스들로 구성된다.

·Business Capacity Management
이 프로세스는 향후 비즈니스 요구에 부합하도록 IT 서비스를 계획하고 적절한 시점에 구현하는 것이다. 이것은 기존의 성능 트렌드 분석과 모델링에 의한 예측을 통해 이루어지며 IT의 성능뿐만 아니라 비즈니스 자체에 대한 계획과 예측을 필요로 한다.
·Service Capacity Management
이 프로세스에서는 IT 서비스의 성능을 관리하는 것이 주 목적으로 모든 서비스들에 대한 성능이 정의된 SLA에 맞게 유지되는지 감시한다.
·Resource Capacity Management
이 프로세스에서는 IT 인프라를 구성하는 개별 요소들의 성능 측정과 리포팅, 데이터 분석이 요구된다.

2. Availability Management
가용성관리의 목적은 IT 인프라의 성능과 지원 조직을 최적화하여 신뢰할 만한 수준으로 가용성을 유지시키는 것이다. 이것은 비즈니스에 요구되는 가용성 수준을 파악하고 거기에 맞게 IT 인프라의 성능과 지원 조직을 구성함으로써 얻어질 수 있으며, 가용성을 충족시키기 위해서는 가능한 비용에 대한 문제 또한 고려되어야 한다.
가용성관리에서 중요한 문제는 가용성 수준의 측정 방법과 모니터링이며 일관된 결과를 얻을 수 있는 방법과 도구가 선택되어야 한다.
이 프로세스에서의 주된 기능은 다음과 같다.
·비즈니스에 요구되는 가용성을 위한 요구 조건들의 파악과 가용성 계산 공식 산출과 장애 발생 시 복구 기준 설정
·ITSCM(IT Service Continuity Management)와 관련하여 비즈니스의 핵심 기능 요소와 IT 서비스의 장애발생 시 비즈니스의 영향 분석
·SLA, OLA와 계약에 근거한 가용성과 신뢰성, 복구에 대한 목표 설정 및 그것의 측정 방법과 리포팅 내용에 대한 설정
·가용성 계획 수립
·주기적인 가용성과 신뢰성의 모니터링과 트렌드 분석을 통한 가용성의 향상

또한 가용성관리에 있어 중요한 부분 중의 하나는 위험 분석(Risk Analysis)인데, 이를 통해 잠재적인 위험요소들이 어떤 것들이며 그것들의 위협 수준과 그 위협에 대한 IT 조직의 취약 정도를 파악하는 것이 필요하다.
3. IT Service Continuity Management
(ITSCM)
ITSCM은 많은 위험요소를 안고 있는 비즈니스 상황에서 비즈니스의 연속성을 보장해 주는 중요한 도구이다. 적절한 ITSCM 조치들을 구현함으로써 비즈니스에 미치는 영향을 최소화할 수 있고 다양한 환경의 변화에 대해 신속하고도 효과적으로 대응하도록 주기적인 검증 절차를 통해 더욱 확실한 연속성을 보증한다.
ITSCM의 주된 목표는 필요한 IT 기술과 서비스 자원들을 요구되는 기간 내에 제공하여 전체적인 비즈니스의 연속성을 지원하는 것이다. 이것을 위해서는 위험요소의 분석과 평가를 기반으로 비즈니스의 연속성을 보장할 수 있는 전략을 수립하고 조직의 구성과 역할에 맞게 적용하여야 한다. 장애 발생 시 잘 짜여진 운영 및 복구 전략은 비즈니스와 IT 서비스의 중단을 최소화할 수 있다.


4. Financial Management
재무관리는 IT와 관련한 기업의 재무 자원을 건실하게 관리하는 것으로서 비즈니스 목표를 수립하고 실행하는 데 있어 발생 비용과 수입에 대한 정확한 계획과 예측을 도와준다.
재무관리는 다음의 세 부분으로 나뉜다.

·Budgeting
이 프로세스에서는 IT를 위한 예산을 예측하고 할당하며 예산 범위 내에서 비용이 소요되도록 한다. 설정된 목표에 맞는 성능을 위한 IT 서비스 소요 비용을 예측하고 집행되도록 함으로써 효과적인 예산 운영이 가능하도록 한다.
· IT Accounting
이 프로세스는 IT 서비스를 위한 비용이 비즈니스의 목적에 맞게 사용되었는지에 대한 정보를 제공한다. 어떤 서비스에 얼마의 비용이 소요되었는지에 대한 정보와 향후 투자를 위한 가이드라인을 제공한다.
· Charging
이 프로세스는 지출과 수입의 균형을 맞추는 프로세스이다. 고객이 사용하는 서비스의 수준에 맞추고 비용을 회수할 수 있도록 해야 하며 서비스에 대한 향후 투자를 고려해 운영되어야 한다.

5. Service Level Management
서비스 수준관리는 비즈니스에 필요한 수준과 제공할 수 있는 IT 서비스 수준을 파악하여 밸런싱하는 프로세스이다. 서비스 제공자와 고객 간에 상호 만족할 수 있는 수준의 서비스를 협의하여 협의된 수준에 맞게 IT 서비스를 운영하도록 하는 것이 목적이다.
서비스 수준관리에 관련된 내용은 다음과 같다.

·Service Catalogue
IT 조직에서 제공할 수 있는 서비스 전체에 대한 목록으로 다양한 서비스 수준과 각 서비스 수준별 상세 내용을 포함한다.
·Service Level Agreements
고객과의 협의를 통해 도달된 동의된 서비스 수준에 대한 약속이다.
·Operational Level Agreement
SLA를 위해 IT 조직과 내부 공급자와 외부 공급자 간에 체결된 계약이다.
·Service Quality Plan
협의된 서비스 수준을 보장하기 위해 필요한 모든 내용을 기술한 내부 계획이다.
·Monitoring, Review and Report
주기적으로 서비스 수준 위반 여부를 검토함과 동시에 서비스 수준 향상 계획을 수립하고 기존의 SLA와 OLA를 갱신한다.

Posted by theYoungman
engineering/Network Eng.2006. 8. 30. 14:21

IP ACCOUNTING 

─────────────────────────────────────────────

1. 내부 트래픽 확인 (IP Accounting은 output-packets만 적용)

Serial Interface 적용시 - 유출양 확인
Ethernet Interface 적용시 - 유입양 확인

2. 설정법

ROUTER#
ROUTER# config t
ROUTER(conf)# int s0  (또는 int e0)
ROUTER(conf-if)# ip accounting output-packets
ROUTER(conf-if)# ^z

ROUTER# sh ip accounting output-packets

Source                Destination                Packets            Bytes
203.200.39.50      203.239.36.121                   6                  328
202.109.117.194   203.239.36.122                   1                    40
203.235.205.231   203.239.36.123                195               12849
202.109.117.194   203.239.36.124                   1                    40
203.235.205.231   203.239.36.125                832               51043

접속하는 IP들의 경로와 Packets양을 보여줍니다.

Accounting data age is 0 ----- 분 단위 (30이 넘어가지 않도록 주의한다) 

3. 해지법

ROUTER#
ROUTER# config t
ROUTER(conf)# int s0 (또는 int e0) --- 설정했던 인터페이스
ROUTER(conf-if)# no ip accounting output-packets (앞에 no를 붙여준다)
ROUTER(conf-if)# ^z

ROUTER# sh ip accounting output-packets
더 이상 나타나지 않는다.

4. clear 방법

ROUTER# clear ip accounting

5. 주의사항

Encapsulation이 Frame-relay로 sub-interface로 설정이 되어 있을 경우

ROUTER(config)# int s0.1
ROUTER(config-subif)# ip accounting output-packets (해지시 앞에 no)
ROUTER(config-subif)# ^z

scripts --------

config t
interface FastEthernet0/1
ip accounting output-packets
exit
exit
sh ip accounting output-packets


config t
interface FastEthernet0/1
no ip accounting output-packets
exit
exit
clear ip accounting


config t
interface Hssi1/0
ip accounting output-packets
exit
exit
sh ip accounting output-packets


config t
interface Hssi1/0
no ip accounting output-packets
exit
exit
clear ip accounting


출처 블로그 > 슈가님의 블로그
원본 http://blog.naver.com/sugarkoo/60019063978

Posted by theYoungman