'Network'에 해당되는 글 31건

  1. 2011.12.01 gethostbyname() 도메인 이름으로 hostent 정보를 구함
  2. 2011.12.01 inet_addr, inet_aton 1
  3. 2011.11.23 언제 shutdown()를 써야 하는가?
  4. 2011.11.11 소켓 함수 모음
  5. 2011.11.07 struct sockaddr, sockaddr_in, sockaddr_un
  6. 2011.11.02 멀티캐스트 (Multicast)
  7. 2011.08.26 X25 와 TCP/IP
  8. 2010.04.06 NAS SAN SATA SCSI 방식 차이점
  9. 2010.04.06 네트워크 로드 밸런싱 시스템
  10. 2010.04.06 L4스위치

gethostbyname() 도메인 이름으로 hostent 정보를 구함

Network/Network 2011. 12. 1. 19:43

설명

주어진 호스트 name 에 상응하는 hostent 타입의 구조체를 반환한다. hostent 구조는 아래와 같습니다.

struct hostent
{
  char *h_name;                 /* Official name of host.  */
  char **h_aliases;             /* Alias list.  */
  int h_addrtype;               /* Host address type.  */
  int h_length;                 /* Length of address.  */
  char **h_addr_list;           /* List of addresses from name server.  */
#define h_addr  h_addr_list[0]  /* Address, for backward compatibility.  */
};

 

헤더 netdb.h
형태 struct hostent *gethostbyname(const char *name);
인수
const char *name 호스트 이름이거나 표준 점 표기법의 IPv4 주소, 콜론(그리고 점 표기법도 가능)표기법의 IPv6
반환
  hostent 구조체
NULL 에러, h_errno 변수에 에러 넘버 대입

예제

forum.falinux.com의 IP주소를 구합니다.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>

int   main( void)
{
    struct hostent *host_entry;
    int             ndx;

    host_entry = gethostbyname( "forum.falinux.com");

    if ( !host_entry)
    {
        printf( "gethostbyname() 실행 실패/n");
        exit( 1);
    }
    for ( ndx = 0; NULL != host_entry->h_addr_list[ndx]; ndx++)
        printf( "%s\n", inet_ntoa( *(struct in_addr*)host_entry->h_addr_list[ndx]));
    
/* // 바이너리(32bit 주소형태) long net_addr; memcpy(&net_addr, host_entry->h_addr, host_entry->h_length); */
return 0; }
]$ gcc gethostbyname.c 
]$ ./a.out 
211.239.155.97
]$

'Network > Network' 카테고리의 다른 글

IP Subnet  (0) 2011.12.02
멀티캐스트 원리  (0) 2011.12.02
inet_addr, inet_aton  (1) 2011.12.01
언제 shutdown()를 써야 하는가?  (0) 2011.11.23
소켓 함수 모음  (0) 2011.11.11
:

inet_addr, inet_aton

Network/Network 2011. 12. 1. 19:37

1장. inet_addr(3)

차례
1.1. 사용법
1.2. 설명
1.3. 예제
1.4. 참고문헌

인터넷 주소를 변환한다.


1.1. 사용법

#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

in_addr_t inet_addr(const char *cp);
int inet_aton(const char *cp, struct in_addr *inp);
in_addr_t inet_network(const char *cp);
char *inet_ntoa(struct in_addr in);
		


1.2. 설명

inet_addr()함수는 (점박이 3형제)인터넷 주소 cp를 32bit 바이너리 주소로 변경한값을 리턴한다. 리턴된 값은 네트워크 바이트 오더를 따른다. 만약 잘못된 값을 입력했다면 INADDR_NONE(-1)을 리턴한다. 이 함수는 입력을 제대로 검사할 수 없으므로 가능하면 이 함수보다 inet_aton()을 사용하기 바란다. 왜냐하면 리턴되는 값 -1은 255.255.255.255로 올바른 주소를 나타내기 때문이다. inet_aton()은 에러 체크를 위한 확실한 방법을 제공한다.

inet_aton()함수는 inet_addr()의 보다 최신 버젼이다. inet_aton()은 주어진 인터넷 주소 cp를 변경한 값을 inp에 복사한다. 잘못된 인터넷 주소를 입력했을 경우 0을 리턴한다. 변환값과 리턴값이 분리되어 있으므로 보다 확실한 입력 체크가 가능하다.

inet_network()함수는 인터넷 주소 cp에 대한 호스트 바이트 오더를 따르는 바이너리 주소값을 리턴하는 걸 제외하면 inet_addr()과 동일하다.

inet_ntoa()는 in의 바이너리 인터넷 주소를 점박이 3형제 인터넷 주소로 변경한 다음 되돌려준다. 입력되는 값은 네트워크 바이트 오더를 따라야 한다.

in_addr구조체는 netinet/in.h에 정의되어 있다.

struct in_addr
{
    unsigned long int s_addr;
}
		


1.3. 예제

#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <string.h>
#include <stdio.h>

int main(int argc, char **argv)
{
    char buf[256];
    struct in_addr laddr;
    int stat;

    while(1)
    {
        // 인터넷 주소를 입력 받는다.
        printf("INPUT ADDRESS : ");
        fgets(buf, 255, stdin);

        buf[strlen(buf) -1] = 0x00;
        if (strcmp(buf, "quit") == 0) break;

        stat = inet_aton(buf, &laddr);
        if (!stat)
        {
            printf("Format Error\n");
        }
        else
        {
            printf("inet_addr    : %s => %d\n", buf, laddr.s_addr);
            printf("inet_ntoa    : %d => %s\n", laddr.s_addr, inet_ntoa(laddr)); 
        }
    }
    return 0;
}
		


1.4. 참고문헌

  1. Endian에 대해서

  2. Socket Layer

:

언제 shutdown()를 써야 하는가?

Network/Network 2011. 11. 23. 17:38

 언제 shutdown()를 써야 하는가?

Michael Hunter (mphunter@qnx.com)로부터:

shutdown()은 여러분은 TCP를 사용하여 서버로 요청 하는일을 언제 끝냈는지 알아 내는데 유용하다. 전형적인 사용예는 서버 로 요청이 전달되고 나후에 shutdown()이 이루어 졌을 경우에 유용하다. 서버는 여러분의 호출을 EOF일때까지 받는다. 즉 이것 은 서버가 여러분의 완전한 요청을 받았다는 것을 의미한다. 그리고 나서 소켓에서의 read는 블록된다. 서버는 요청을 처리하고 필요한 데이터를 여러분에게 보내고 소켓을 닫게 된다. 여러분이 필요한 모든 내용을 소켓에서 읽었다면 마지막에 EOF를 읽게 될 것이다. 이것은 TTCP(TCP for Transactions)가 보다 나은 트랜잭션 처리를 위한 도구 라는 것을 보여준다.

S.Degtyarev (deg@sunsr.inp.nsk.su)는 이것에 관한 상세한 메시지를 내게 보내 주었다. 그는 하나는 "reader"이고 다른 하나는 "write" 프로세스인 클라이언트 프로세스의 동기화를 도와주는 shutdown()에 대한 실제 예제까 들었다. 여기 그것의 일부를 여기 싣는다.

소켓은 데이터 전달과 클라이언트/서버 트랜잭션에 사용된다는 점에서 파이프와 매우 비슷하다 그러나 파이프와 다른 점은 양 방향 성이라는 것이다. 소켓을 사용하는 프로그램은 자주 fork()하고 각 프로세스는 소켓 드스크립터를 상속받는다. 파이프에 기 본을 둔 프로그램은 데이터 상실이나 deadlock을 피하는 단방향성의 데이터 스트림으로 pipe line을 만들기 위해 사용되지 않는 모든 끝은 닫도록 엄격히 권고되고 있다. 그러나 소켓의 경우에는 한쪽은 쓰기만 하고 한쪽은 받기만 하는 것은 허용되지 않기 때문에 여러분들은 그 순서에 유념해야 할 필요가 있다.

일반적으로 close()와 shutdown()의 차이점은: close()는 프로세스에 대해 소켓 ID를 닫지만 만약 다른 프로세스가 소켓 ID를 공유하고 있다면 연결은 여전히 열려 있게 된다. 그 연결은 읽기,쓰기를 위해 유지 되며, 어떤때, 이것은 매우! 중요하다. shut down()은 그 소켓 ID를 공유하고 있는 모든 프로세스에 대해 연결을 끊어버린다. 커널 소켓 버퍼가 꽉 차이 있으면 읽기를 시도 하는 프로세스는 EOF를 발견하게 되고, 쓰기를 시도하는 프로세스는 SIGPIPE를 받게 된다. 게다가 shutdown()은 그 연결을 어떻 게 끊을지를 나타내는 두 번째 파라메터를 가지고 있는데, 0은 이후의 읽기를 못하게하고, 1은 쓰기를, 2는 양쪽 모두를 못하게 한다.

이 쉬운 예제는 단순한 클라이언트 프로세스를 자른 것이다. 연결을 설립한 후에 서버는 fork한다. 그리고 나서 child는 EOF 를 받거나 부모프로세스가 서버로부터 응답을 받을 때까지 키 입력을 서버에게 전송한다.

/*
 * 예제 클라이언트 쪼가리..
 * 변수선언과 에러 핸들링은 제외 됐음
 */

s=connect(...);

if( fork() ){     /* 자식은 그 stdin을 소켓으로 복사한다 */
   while( gets(buffer) >0)
   write(s,buf,strlen(buffer));

   close(s);
   exit(0);
   }
else {            /* 부모가 응답을 받는다 */
   while( (l=read(s,buffer,sizeof(buffer)){
      do_something(l,buffer);

   /* 서버가 연결을 끊는다 */
   /* ATTENTION: deadlock here */
   wait(0);       /* 자식이 나갈때까지 기다림 */
   exit(0);
   }

무엇을 기대할 수 있는가? 자식프로세스는 stdin으로부터 EOF를 받으면 소켓을 닫고 빠져 나간다. 서버는 EOF를 받으면 연결 을 끊고 빠져 나간다. 부모 프로세스는 EOF를 받으면 wai()을 호출하고 빠져 나간다. 이것 대신 우린 뭘 할 수 있을까? 비록 부 모 프로세스가 쓰기를 하지 않을지 모르지만 부모 프로세스에 있는 소켓 인스턴스는 읽기와 쓰기를 위해 여전히 열려 있다. 서버 는 EOF를 발견하지 못한다. 그리고 영원히 클라이언트로부터의 데이터를 기다린다. 그리고 서버도 죽~. (여기서 deadlock이 발생 된다.)

여러분은 클라이언트 프로그램을 다음과 같이 바꿔야 한다.

if( fork() ) { /* 자식 */
   while( gets(buffer) )
      write(s,buffer,strlen(buffer));

   shutdown(s,1); /* 쓰기를 위해 연결을 끊는다
      서버는 EOF를 받게 된다. Note: 소켓으로부터의 읽기는 여전히 허용된다.
      서버는 EOF를 받은 후에 몇 데이터를 보낼 것이다. */
   exit(0);
   }

나는 이 다듬어 지지 않은 예제가 여러분들이 가지고 있는 클라이언트/서버의 동기화의 문제를 설명해 줄 수 있기를 바란다. 일반적으로 여러분들이 모든 프로세스의 특정 소켓 인스턴스에서 기억하고 있어야 할 것이 있는데, 만약 여러분이 하나의 프로세 스 안에서 연결을 끊기 위해 close()또는 shutdown()을 사용하길 바란다면, 그들 모두를 공유하고 있다가 한 번에 닫아라.

출처 -  http://forum.falinux.com/zbxe/?document_srl=448212#26

'Network > Network' 카테고리의 다른 글

gethostbyname() 도메인 이름으로 hostent 정보를 구함  (0) 2011.12.01
inet_addr, inet_aton  (1) 2011.12.01
소켓 함수 모음  (0) 2011.11.11
struct sockaddr, sockaddr_in, sockaddr_un  (0) 2011.11.07
멀티캐스트 (Multicast)  (0) 2011.11.02
:

소켓 함수 모음

Network/Network 2011. 11. 11. 08:20

'Network > Network' 카테고리의 다른 글

inet_addr, inet_aton  (1) 2011.12.01
언제 shutdown()를 써야 하는가?  (0) 2011.11.23
struct sockaddr, sockaddr_in, sockaddr_un  (0) 2011.11.07
멀티캐스트 (Multicast)  (0) 2011.11.02
X25 와 TCP/IP  (0) 2011.08.26
:

struct sockaddr, sockaddr_in, sockaddr_un

Network/Network 2011. 11. 7. 16:35

사용

bind(), connect()를 사용하는 socket 네트워크 프로그래밍에서 주소와 포트정보를 저장하기 위해서 사용한다. 
<</usr/include/bits/socket.h>> 
struct sockaddr  
{ 
    unsigned short sa_family;  // Address family and length 
    char sa_data[14];            // Address data 
} 
 

위의 네트워크 관련 함수들은 기본 데이터형으로 sockaddr 을 받아들인다. 그런데 sockaddr 로는 다양한 유형의 socket을 받아들일 수 없다. 예를 들어 AF_INET 소켓도 있고 AF_UNIX 소켓이 있는데 이들은 구조자체가 완전히 다르기 때문이다.

AF_INET의 경우에는 struct sockaddr_in 을 사용하고 AF_UNIX 의 경우에는 struct sockaddr_un 을 사용한다. 그러므로 실제 소켓 프로그래밍에서는 sockaddr 로 형변환을 해서 사용해야 한다. 형변환된 데이터를 받아들인 함수는 sa_family 값을 이용해서 데이터의 종류를 알아낼 수 있다.

AF_UNIX에서의 사용
struct sockaddr_un serveraddr;  
 
bzero(&serveraddr, sizeof(serveraddr)); 
serveraddr.sun_family = AF_UNIX; 
strcpy(serveraddr.sun_path, argv[1]); 
 
if (bind(sockfd, (struct sockaddr *)&serveraddr, sizeof(serveraddr)) < 0) 
{ 
    perror("bind error : "); 
    exit(0); 
} 
clilen  = sizeof(clientaddr);  
 

AF_INET에서의 사용
struct sockaddr_in serveraddr; 
 
server_sockfd = socket(AF_INET, SOCK_STREAM, 0); 
serveraddr.sin_family = AF_INET; 
serveraddr.sin_addr.s_addr = inet_addr("218.234.19.87"); 
serveraddr.sin_port = htons(atoi(argv[1])); 
 
client_len = sizeof(serveraddr); 
 
if (connect(server_sockfd, (struct sockaddr *)&serveraddr, client_len) < 0) 
{ 
    perror("connect error :"); 
    exit(0); 
} 
 

struct sockaddr_in

AF_INET 도메인의 소켓에서 사용하는 구조체
<</usr/include/netinet/in.h 
struct sockaddr_in 
  { 
    __SOCKADDR_COMMON (sin_);  /* sa_family_t sin_family */ 
    in_port_t sin_port;                 /* Port number.  */ 
    struct in_addr sin_addr;            /* Internet address.  */ 
 
    /* Pad to size of `struct sockaddr'.  */ 
    /* 결국 8 byte */ 
    unsigned char sin_zero[sizeof (struct sockaddr) - 
                           __SOCKADDR_COMMON_SIZE - 
                           sizeof (in_port_t) - 
                           sizeof (struct in_addr)]; 
  }; 
 

struct sockaddr_un

<</usr/include/sys/un.h>> 
struct sockaddr_un 
  { 
    __SOCKADDR_COMMON (sun_); 
    char sun_path[108];         /* Path name.  */ 
  }; 

'Network > Network' 카테고리의 다른 글

언제 shutdown()를 써야 하는가?  (0) 2011.11.23
소켓 함수 모음  (0) 2011.11.11
멀티캐스트 (Multicast)  (0) 2011.11.02
X25 와 TCP/IP  (0) 2011.08.26
NAS SAN SATA SCSI 방식 차이점  (0) 2010.04.06
:

멀티캐스트 (Multicast)

Network/Network 2011. 11. 2. 17:10

내가 인터넷 방송국을 운영한다고 가정하고,

클라이언트가 조낸 늘어났다고 가정해보자... N명이라고 칭하자.

TCP 기반으로 다중 접속 서버를 구성하면 N개의 소켓이 필요하고

UDP 기반으로 다중 접속 서버를 구성하더라도 1개의 소켓으로 N번의 전송을 해야만 한다.

 

인터넷 방송국이기 때문에 전송되는 데이터들은 모두 동일하다.

동일하게 전송해야될 거를 send를 미친듯이 써서 보내는 것은 좀 그렇다.

 

이러한 문제를 라우터 차원에서 해결했다.

이는 멀티캐스트라고 불린다. 이 것은 UDP를 기반으로 한다.

서버쪽에서는 Multicast packet을 한 번 보내기만 하면

라우터에서 열라 늘려서 N명에게 짜잔하고 동시에 쫙 뿌린다.

여기서 이 패킷의 목적지는 Multicast group에 포함되어있는 모든 호스트들이다.

 

 

1] 전송 방식

Multicast group이란 클래스D (224.0.0.0 ~ 239.255.255.255)에 속하는 IP주소 그 자체를 뜻한다.

멀티캐스트 패킷을 받으려면, 이 그룹에 가입해야된다.

응? IP주소에 가입해야된다는 사실이 좀 말이 안되지 않냐고 물어볼테지만 개념상 그런 것이다.

Multicast packet이란 이러한 multicast group가 목적지로 설정되어있는 UDP packet이다.

 

하지만 멀티캐스트는 단순히 multicast group을 목적지로 설정해서 보내는 것만으로

이루어지지 않는다. 왜냐하면 대부분의 라우터가 멀티 캐스트를 지원하지 않거나

또는 트래픽 문제를 고려해서 일부러 막아놓기 때문이다.

(외부 네트워크의 상태도 고려해야된다...)

 

 

2] 라우팅과 TTL

Multicast packet을 전송하려면 TTL 설정 과정을 반드시 거쳐야한다.

이 값은 몇 개의 라우터를 거칠 수 있느냐를 결정하는 값이다.

멀티캐스트가 아닌 지금까지 했뜬 유니캐스트에서는 이 TTL이 얼만지 모르겠는데

멀티캐스트로 보내는 패킷은 TTL이 기본적으로 1로 잡혀있기 때문에

로컬 호스트를 벗어나지 못한다.

 

 

3] 멀티캐스트 서버 클라이언트

시나리오>

Sender: A라는 Multicast group으로 데이터를 방송(멀티캐스트)한다.

Receiver: Multicast group에 가입(join)하고 뉴스를 수신한다.

 

 

/* Sender 소스의 일부분 */

 

//그냥 유니캐스트처럼 보낸다고 생각.
//멀티캐스트 패킷인지 아닌지는 커널이 결정하는 것이다. (커널이 TTL을 다르게 할당하는 듯)
memset(&multiAddr, 0, sizeof(multiAddr));
multiAddr.sin_family = AF_INET;
multiAddr.sin_addr.s_addr = inet_addr(argv[1]);        //Multicast group 설정
multiAddr.sin_port = htons(atoi(argv[2]));                 //port도 일치시켜야 한다.

 

//setsockopt로 멀티캐스트 패킷의 TTL을 설정.
state = setsockopt(hSendSock, IPPROTO_IP, IP_MULTICAST_TTL, (char*)&multiTTL,

                          sizeof(multiTTL));

 

//이후로 sendto를 해서 멀티캐스트를 하면 된다.

 

 

 

/* Receiver 소스의 일부분 */

 

memset(&addr, 0, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = htonl(INADDR_ANY);//자기 자신? 바로 Multicast group을 안 넣네? 
addr.sin_port = htons(atoi(argv[2]));                              //포트도 일치시켜야 한다.

if(bind(hRecvSock, (SOCKADDR*)&addr, sizeof(addr)) == SOCKET_ERROR)
     ErrorHandling("bind() error");

 

//멀티캐스트 그룹 가입을 위한 구조체
joinAddr.imr_multiaddr.s_addr = inet_addr(argv[1]);    //argv[1] is Multicast group (=IP addr)
joinAddr.imr_interface.s_addr = htonl(INADDR_ANY);  //자기 자신
 
//setsockopt()로 멀티캐스트 그룹에 가입할 수 있다.
state = setsockopt(hRecvSock, IPPROTO_IP, IP_ADD_MEMBERSHIP, (char*)&joinAddr,

                          sizeof(joinAddr));

 

//이후로 이 Multicast group으로 멀티캐스트되는 것은로오는 것은

//hRecvSock으로 recvfrom할 수 있다.

'Network > Network' 카테고리의 다른 글

소켓 함수 모음  (0) 2011.11.11
struct sockaddr, sockaddr_in, sockaddr_un  (0) 2011.11.07
X25 와 TCP/IP  (0) 2011.08.26
NAS SAN SATA SCSI 방식 차이점  (0) 2010.04.06
네트워크 로드 밸런싱 시스템  (0) 2010.04.06
:

X25 와 TCP/IP

Network/Network 2011. 8. 26. 14:08

제목 : X25 와 TCP/IP

 

 

목 차  -

 

I.인터네트워킹 (Internetworking)을 위한 솔루션 X25의 개요

.X25의 정의

나.    X25의 등장배경

다.    X25의 필요성

 

II. X25의 구조 및 특성

가.    X25 프로토콜 구조

나.    X25 프로토콜의 장단점

다.    X25의 회선 및 장치 구성

라.    X25의 활용

 

III. X25와 TCP/IP

가.    TCP/IP 프로토콜 구조

나.    TCP/IP의 특징

다.    X25와 TCP/IP의 비교

라.    X25의 TCP/IP의 전환시 고려사항

 

IV. X25의 시스템 커맨드 및 향후 전망

가.    X25 세팅 및 모니터링

나.   X25의 향후 전망 

 

  

I. 인터네트워킹 (Internetworking)을 위한 초기 솔루션 X25의 개요

가.     X25 프로토콜의 정의

사용자측 단말과 패킷교환망의 기간망간의 접속을 위하여 물리계층,프레임계층,패킷계층으로 구성하여 정의된 단말-패킷교환망의 국제접속표준규약

 

나.     X25의 등장배경

                             - 패킷교환망의 등장으로 접속을 위한 프로토콜의 표준 필요

                             - 패킷교환망이란 일정 크기 단위로 패킷을 교환하는 통신방식으로 기존의 신호

                       교환 방식에 비하여 접속 효율이 높으며 전송속도 효율성,확장성,유연성, 오류

                       제어, 통신비용 등이 우수한 통신교환망 방식으로 군사용으로 사용하던 전송

                       방식을 대중적으로 사용한 방식

                            - 패킷교환방식은 향후 기간망의 전송방식의 근간이 됨

 

다.     X25의 필요성

패킷교환망이 교환기의 전달 방식으로 확립되고 사용자의 단말간 통신의 요구에 따라 단말과 패킷교환망의 접속에 대한 접속 방식 요구됨

이기종간 및 기기간의 개별적 접속에 따른 비효율성을 극복하고자 1976년 단말 – 패킷교환망간의 접속 표준안을 제정하게 됨

  

 

II. X25의 구조 및 특성

가.     X25 프로토콜 구조


<그림1-7 X.25의 프로토콜계층 구조>

Pysical 계층,Frame 계층,Packet 계층 과 사용자 정의 부분으로 구성

구성된 3계층은 OSI 7 Layer의 Physical, Data,Link 의 3계층의 역할

 

Layer

각 계층별 역할 및 기능

Physical

단말기나 패켓교환기 전송 장비 간의 물리적 접속 정의

Frame

원할한 데이터 전송을 위한 데이터 링크의 제어기능 수행 정의

Packet

트랜스포트 계층 데이터의 안정된 전송을 지원 정의

 

 

나.     X25 프로토콜의 장단점

구분

내용

장점

국제 표준화에 따른 우수한 호환성 및 안정성 우수

고 신뢰성을 보장하는 에러체크기능 우수

장애시 우회전송 가능

디지털 전송에 따른 전송품질 우수 및 재전송 기능

하나의 물리적 회선에 논리채널을 부여한 고효율 방식 (LU)

단점

축적교환방식으로 전송을 위해 다소의 처리지연 발생가능(FrameRelay로 대체)

전송시 부하 발생 가능

X25카드 및 접속 컨넥터등 주변 장치 비용 발생

 

 

 

다.     X25의 회선 및 장치 구성

X25 망의 구성 : 단말이 DTE, 교환망이 DCE로 구성

 

X25망의연결장치: 종단간 DSU를 통한 회선 연결 및 커넥터를 통한 서버연결

 

 

라.     X25의 활용

패킷교환망의 장점을 통한 X25의 등장후 X25 문제점을 해결한 Frame Relay의 등장으로 패킷교환망에서 사라짐

금융권의 통신 방법으로 활용되고 있으며 전용선 개념으로 사용

금융권에서 X25가 각광받고 있는 이유는 이미 검증된 프로토콜로 안정성이 우수하며 기구축된 프로토콜을 활용하는 의의가 큼

 

 

III. X25와 TCP/IP

 

. TCP/IP 프로토콜 구조

Pysical, Internet , Transport, Application 4계층으로 구성

 

OSI 7 Layer

 

TCP/IP

 

X25

Application

 

Application

 

User Define

Presentation

 

Session

 

Transport

 

Transport

 

Network

 

Internet

 

Packet

Data

 

Frame

Physical

 

Physical

 

Physical

 

 

Layer

계층별 기능 및 역할

Pysical

물리적 계층 즉 이더넷 카드와 같은 하드웨어를 정의

Internet

데이타를 정의하고 라우팅을 담당

라우팅 하기 위해서 IP프로토콜을 사용

Transport

시스템까지 데이타를 전송하기 위한 계층

TCP 프로토콜을 이용하여 데이터를 전송

Application

네트웍을 사용하는 응용프로그램(FTP, Telnet, SMTP)으로 구성

 

나.     TCP/IP의 특징

가장 최근의 인터넷트워킹을 위한 표준 프로토콜로 등장

미국 방위청에서 사용하던 통신 프로토콜로 인터넷의 발달에 따라 각광 받으며 인터넷 응용프로그램(FTP,WWW,EMIL,TELNET)의 기반으로 사용

IP는 인터넷 주소 체계에 따른 목적지로 전송가능 하도록 송신 하는 기능

TCP는 손실을 검색해내서, 이를 교정하고 순서를 재조합할수 있도록 해주는 연결 지향형 프로토콜로 재전송 및 패킷의 Sequence 조합 기능

같은 기반하의 비연결지향형 UDP 사용가능 (멀티미디어 실시간 방송등 )

TCP/IP의 최대장점은 개방성과 호환성이 뛰어나 벤더나 디바이스에 독립적임

개방형 구조로 인한 해킹의 위험성 존재하며 많은 해킹기법 알려져 있음

 

 

다.     X25와 TCP/IP의 비교

구분

X25

TCP/IP

시작

미국방부의 ARPA

미국방성의  ARANET

초기목적

패킷교환망의 사용자 단말 통신

클라이언트 – 서버간의 통신 접속

구성

Physical-Frame-Packet-User 계층

Pysical-Internet-Transport-Application

장점

장기간 표준화에 따른 안정성 검증

 

개방성,호환성,대중성

Application 의 다양성 및 기술적 간편함

단점

전송시 부하 및 주변장치 비용

최근 사용 급감

세션 계층의 보안취약

Root권한 획득등 해킹 위험성 존재

활용

- 금융권 전용 연결

인터넷 및 전용망 접속 프로토콜

인터넷트워킹의 표준으로 자리 잡아 기기간 통신 및 응용프로그램간 통신의 기반 구조

 

라.     X25의 TCP/IP의 전환시 고려사항

 

구분

내용

시스템 측면

기존 접속 형태

 X.25|HSI(RS232C)--DSU<==>전용선<==>DSU--HSI(RS232C)| X.25

TCP/IP의 전용선 형태

TCP/IP—Router--DSU<==>전용선 <==>DSU --Router --TP/

- TCP/IP의 공중망 이용시

TCP/IP--xDLS --공중망(혹은 VPN) <==> xDLS -- TCP/IP

보안적인 측면을 고려하여 공중망 이용방식은 지양

- 전용선 형태의 경우 기존의 X25방식과 구성 형태는 동일하나 X25커넥터 대신에 Router를 통한 연결 (시세의 경우 기존 X25 및 Async를 UDP로 전환, 시스템 구성은 보안 사항을 제외하고 시세와 동일)

보안 측면

TCP/IP로 연결된 시스템의 경우 공중망이 아니라고 하더라도 해킹의 위험성 존재함

TCP/IP로 연결된 시스템중 일부가 해킹되었을 경우 연결된 모든 시스템이 위험에 노출 되어 FireWall등의 보안 구축 필요

X25의 경우 Root 권한획득이 원천적으로 불가능하나 TCP/IP의 보안시스템을 적용하더라도 지속적으로 보안관련 Risk를 원천적으로 제거하기 어려움

보안에 소요되는 비용 및 Risk가 TCP의 효율성이상으로 클경우 불필요 

X25사용시 불필요했던 암호화 필요하며 부하 요소로 작용 가능

기타 측면

통합거래소의 출범으로 거래소 내부의 업무 통합으로 혼란 스러운 상태로 협의시 비협조적 성향 예상

통합거래소 업무Flow 변경시 프로토콜 변경 여부 반영 요구 필요

TCP의 보안적인 측면은 Stock망의 전용망을 사용할 경우 해결

전환시

.단점

시스템 통합 및 운용효율성 향상,주변장치 비용 불필요

보안 측면에서 Risk 상존, 별도의 보안구축비용, 암호화로 인한 부하 가능

 

IV. X25 의 시스템 커맨드 및 향후 전망

가.     X25 세팅 및 모니터링

X25셋팅확인  : /etc/x25에서 DevicName.cfg로 확인 (예 zx25m0p0.cfg)

                /opt/acc/cfg 에서 x25.anw 로 확인

X25stat:X25의 연결상태 및 Setup 확인 /usr/sbin/x25stat -d DeviceName

X25의 모니터링: 회선 연결시 패킷 및 LU정보 확인 : pdisplay tool 사용

                   Ex) display /var/opt/acc/log/anz_452.eve_16:17 -f

증권전산의 경우 PVC방식의 DTE로 설정

나.     X25의 향후 전망

이미 패킷교환망에서 X25와 Frame Relay를 거쳐 ATM으로 전환된 상태에서 광전송등의 고효율의 전송기능 요구로 패킷교환망에서의 전송표준으로서의 X25의 의미는 퇴색됨

증권거래소 및 은행의 전용망에서 일부 사용되고 있으나 TCP등 호환성 및 통합성을 위한 프로토콜로 전환요구 되고 있으며 시세는 이미 X25의 프로토콜이 완전 배제됨



출처 :  
http://blog.naver.com/pat_bbang?Redirect=Log&logNo=100017359702

[출처] X25와 TCP/IP|작성자 파빵

'Network > Network' 카테고리의 다른 글

struct sockaddr, sockaddr_in, sockaddr_un  (0) 2011.11.07
멀티캐스트 (Multicast)  (0) 2011.11.02
NAS SAN SATA SCSI 방식 차이점  (0) 2010.04.06
네트워크 로드 밸런싱 시스템  (0) 2010.04.06
L4스위치  (0) 2010.04.06
:

NAS SAN SATA SCSI 방식 차이점

Network/Network 2010. 4. 6. 19:23


DAS
서버와 스토리지에 직접적으로 연결
장점: 전용라인을 사용하기때문에 성능과 안정성에서 뛰어남
단점: 파일공유가 안됨

NAS
렌으로 스토리지 서버와 연결, 프로토콜로는 nsf cifs 가 있음
장점: 어플리케이션 서버 사이에 파일 공유 가능
단점: lan과 채널로 접속 단계가 많아 장애가 일어날 수 있음

SAN
서버와 스토리지 사이에 파이버 채널 스위치를 넣음
장점: 서버와 관계없이 저장 장치 사이에 데이터를 공유
        사용자 네트워크와 별도의 네트워크를 이용하여 데이터 서비스 제공 -> 사용자부하를 줄임
단점: 비용, 구성 복잡

2차 스토리지, 정보시스템 주연으로 떠올라



시장조사 전문업체인 IDC는 오는 2006년까지 스토리지 수요의 연평균 성장률이 46%에 달할 전망이며, 2006년에는 60%까지 치솟을 것으로 전망했다. 그러나 기업들의 평균 스토리지 예산은 연간 한 자리 수의 증가율을 보인다고 예상했다. 결론적으로 많은 기업들이 높은 용량을 최저의 가격에 구현하기 위한 방법을 고안하고 있는 셈이다. 저렴한 비용으로 대용량의 데이터를 저장할 수 있으면서, 직접 접근까지 가능한 2차 스토리지의 등장에 많은 기업들이 촉각을 곤두세우고 있는 이유도 바로 여기에 있다.

본지는 4회에 걸쳐 2차 스토리지의 기술적 배경과 적용 방안에 대해 살펴 보고자 한다.



 인터넷 사용의 증가와 더불어 저장할 데이터의 양도 폭발적으로 늘어나면서 그동안 서버에 밀려 조연에 머물렀던 스토리지가 점차 서버를 따돌리고 정보산업의 주역으로 부상하고 있다.
 전산시스템을 구축하는 기업들이 전사적자원관리(ERP)나 데이터웨어하우징(DW), 그리고 고객관계관리(CRM) 등 대규모 데이터처리가 필요한 시스템을 잇달아 도입하고 있다. 인터넷 서비스 제공업체나 애플리케이션 소프트웨어 제공업체들이 경쟁력 있는 서비스를 제공하기 위해 스토리지 도입을 최우선의 과제로 삼고 있다. 
 DW나 ERP의 경우 도입 초기에는 용량이 얼마되지 않는다. 하지만 구축이 완료된 후 운용 과정에서는 처리해야 할 데이터의 양이 2~3배로 급증하게 된다. 기업 입장에서는 업무 효율성을 위해 스토리지 도입을 최우선의 과제로 서두르게 된다.


급부상하는 2차 스토리지


 또한 인터넷 사용의 폭발적인 증가로 인터넷 서비스 제공업체나 애플리케이션 소프트웨어 제공업체 또한 급증하고 있다. 이들 업체들은 보다 경쟁력이 있는  인터넷 사업을 전개하기 위해 고객드르이 정보를 효율적으로 저장하고자 한다. 하지만 다양하고 차별화된 서비스를 제공하려면 이를 충분히 감당할 수 있는 대용량의 스토리지가 절실하게 필요하다.
 한편 PC와 인터넷 기반의 멀티미디어 서비스의 확대로 개인이 보유하고 있는 데이터의 양도 급증하고 있다.
 최근에는 기업의 저장용량의 확대에 대한 요구가 급속히 늘어나면서 페타바이트를 넘어 엑사바이트라는 용어를 사용할 정도로 대용량 데이터가 일반화 되어 가고 있다.
 양키 그룹의 한 조사 연구에 따르면, 2001년을 기준으로 1년 동안 1테라바이트의 스토리지 용량을 사용했던 기업이 2002년에 1테라바이트를 사용하는데 걸린 시간은 고작 30일, 2003년에는 하루, 2004년에는 불과 2시간만에 1테라바이트를 사용할 것으로 전망했다.


왜 모든 데이터를 같은 디스크에 보관하는가


 스토리지는 데이터의 온라인 백업과 대용량 데이터의 저장 등에 효율적으로 사용할 수 있다. 그러나 데이터 센터의 규모가 커짐에 따라 그리고 회사들이 멀티미디어를 기반한 애플리케이션에 점점 더 많이 의존함에 따라 전통적인 스토리지 모델들은 더 이상 효과적이지 않게 되었다.
 스토리지 분야에는 다양한 제품이 나와 있다. 하지만 기본적인 개념을 이해하고 스토리지 특성을 파악한 다음 스토리지를 구입하여 사용한다면 기업환경에 최적의 가용성, 확작성, 신뢰성을 보장하여 투자대비 높은 효율을 얻을 것이다. 데이터의 급증은 기업들의 스토리지, 특히 디스크의 용량 확장으로 이어지고 있다. 하지만 기업의 입장에서는 무작정 디스크 용량만 늘릴 수도 없는 노릇이다.
 최근 SCSI 디스크 어레이 가겨이 크게 내려갔다고는 해도 여전히 1테라당 1억원을 호가하는 고가 장비이다. 그렇다고 값싼 테이프 라이브러리에 모든 데이터를 저장하고 필요할 때마다 꺼내서 돌린다는 것은 상상조차 하기 힘들다.
 시장조사 전문업체인 IDC는 오는 2006년까지 스토리지 수요의 연평균 성장률은 46%에 달할 전망이며, 2006년에는 60%까지 치솟을 것으로 전망했다. 그러나 기업들의 평균 스토리지 예산은 연간 한자리 수의 증가율을 보인다고 예상했다. 결론적으로 많은 기업들이 높은 용량을 최저의 가격에 구현하기 위한 방법을 고안하고 있는 셈이다. 저렴한 비용으로 대용량의 데이터를 저장할 수 있으면서, 직접 접근까지 가능한 2차 스토리지의 등장에 많은 기업들이 촉각을 곤두세우고 있는 이유도 바로 여기에 있다.
 현재 기업들이 디스크에 저장하는 데이터의 90%는 가끔, 혹은 거의 사용하지 않는 데이터다. 데이터 생성 후 처음 1~2일 내에는 데이터 접근 발생이 빈번하게 일어나지만, 일주일 후에는 데이터 접근빈도가 현저히 저하되고, 90일이 지나면 사실상 데이터 접근 빈도가 거의 없는 게 사실이다. 그럼에도 불구하고 대부분의 기업들이 이와같은 불필요한 데이터를 고가의 디스크에 저장하고 있는 상황이다.
 즉 2차 스토리지는 데이터 생명주기에 따라 탄력적으로 정보생명주기관리(ILM)를 수행할 수 있는 바탕을 제공하는 셈이다.


애플리케이션 특성에 따른 스토리지의 계층 변화


*무작위 접근
 
무작위 접근을 특성으로 하는 대표적인 애플리케이션 유형은 트랜젝션 시스템, ERP 시스템, MRP 시스템, 인터넷 전자 상거래, 고객 서비스 및 지원, 멀티유저 데이터베이스 애플리케이션 등이 있다.


*순차적인 접근
 
순차적인 접근이 필요한 애플리케이션은 영화, 음악, 비디오, 그래픽 이미지 등이다. 이러한 유형의 애플이케이션에서는 전체의 데이터가 읽혀지지만 대다수의 데이터는 프로세스에 위해 변경되지 않으므로 캐시에 데이터를 보유할 필요가 거의 없다.
 한번 생성된 후 거의 수저오디지 않고 사용되는 특성을 가진 순차적인 데이터-동영상(영화, 비디오), 이밎, 그래픽 처리 등의 경우 대부분 디스크 어레이에 보관되고 있는 실정이다. 데이터 특성상 직접 접근을 필요로 하는 만큼 테잎 라이브러리에 저장하는 경우는 극히 드물다. 하지만 이러한 데이터의 경우 대용량 캐시가 필요하지 앟기 때문에 고가의 디스크에 저장하는 방법도 효율적이라고 볼 수 없다.
 2차 스토리지는 저렴한 비용으로 직접 접근이 가능하기 때문에 순차적인 데이터 저장에 가장 적합한 시스템이다. 최신 테잎 드라이브보다 2~3배 이상 빠른 백업 및 복구가 가능하다. 베용 대비 효육적인 데이터 복제 기능을 제공함으로써 ㅗ가도한 비용이 소요되던 기존 시스템에 새로운 대안을 제시한다. 또한 백업 및 복구와 재해복구시스템에서도 많은 이점을 제공한다.


스토리지 접속 방법


 스토리지 접속 방법으로는 전통적인 스토리지 접속 방법인 DAS(Direct Attahced Stroage)와 LAN을 통해 스토리지를 접속하는 NAS(Network Attached Storage) 그리고 중앙집중형의 SAN(Storage Area Network)등이 있다.


*DAS

 
DAS는 서버와 외장형 스토리지 사이를 전용의 케이블로 직접 접속하는 전통적인 접속방법이다. 현재도 가장 많이 사용되고 있는 방법이다.
 만약 서버가 유닉스 혹은 NT 서버와 같은 오픈시스템이면 SCSI또는 파이버 채널 방식으로 접속한다. 메인 프레임을 외장형 스토리지에 접속하고자 한다면 ESCON 또는 패러럴 버스 방식을 사용하여 접속하면 된다.
 DAS 방식에서는 스토리지에 따라 지원되는 접속 방식과 접속 포트의 개수가 다르며 접속 지원되는 서버 종류도 다르다. 스토리지에 따라 다양한 오픈 시스템과 메인 프레임을 동시에 접속 지원하는 스토리지가 있는 반명 한 가지 종류의 서버밖에 접속하지 못하는 스토리지도 있다.
 그리고 SCSI, 파이버 채널, ESCON 등 다양한 접속 방법을 지원하는 스토리지도 있는 반명 SCSI 또는 파이버 채널 한 가지만을 지원하는 스토리지도 있다. 또한 접속 포트수가 많아서 여러대의 서버를 동시에 접속할 수 있는 스토리지가 있는 반명 접속 포트수가 접속 서버의 1~2개 정도로 제한되는 스토리지도 있다.
 이처럼 스토리지의 종류는 다양하고 기술도 천차만별이므로 도입하려는 환경과 향후 계획에 따라 적합한 스토리지를 충분히 비교 검토하여야 한다. 외장형 스토리지는 접속된 서버에 스토리지내의 모든 저장 영역을 사용할 수 있게 한다. 그러나 이 경우 서버가 다른 서버에 할당된 영역에 침범하여 보안 문제가 발생 할 수 있다.
 이를 방지하기 위해 DAS 방식에서는 스토리지의 설정시 접속된 서버들이 스토리지에 각자 자신들에게 할당된 영역을 가지며 다른 서버에 할당된 영역을 쓰지 못하도록 스토리지를 설정한다. 물론 여러 대의 서버가 같은 스토리지 영역을 공유하도록 할 수는 있다.
 그러나 여러 대의 서버가 동일 파일 시스템을 문제없이 공유하도록 보장해주는 록킹(locking), 및 컨시스턴시(Consistency) 기술이 없는 현재의 상태로는 같은 스토리지 영역을 여러 대의 서버가 공유하도록 하는 것은 아무 이득이 없다. 뿐만 아니라 보아느이 문제가 발생할 소지가 있기 때문에 현재로는 쓰이지 않는 방법이다.
 DAS 방식의 장점은 전용의 라인을 사용하기 때문에 주어진 성능이 보장되며 안정성도 뛰어나다. 단점은 파일 시스템을 공유하도록 하는 기술이 없기때문에 파일 공유가 안된다는 단점이 있다. 구성의 확장성 및 유연성도 상대적으로 떨어지고 대량의 서버 구축시 관리 비용이 증가한다는 단점이 있다.


*NAS


NAS 방식은 서버가 LAN을 통하여 전용 파일 서버의 스토리지에 접속한다는 개념이다. 즉 서버와 파일 서버사이는 TCP/IP를 기반으로 한 LAN으로 접속이 된다. 파일 서버와 스토리지 사이는 SCSI 프로토콜을 기반으로 한 SCSI 또는 파이버 채널로 이용한다.
 업체에 따라 전용 파일 서버와 스토리지가 한 캐비닛에 구성된 경우도 있으며, 전용 파일 서버와 스토리지가 별도의 장치로 구성되는 경우도 있다. 일반적으로 중소 규모의 캐비닛으로 구서오디는 경우가 많으며, 대용량의 NAS 장비는 전용 파일 서버와 스토리지가 별도로 구성된다. 한 캐비닛의 NAS는 설치가 용이하고 간편한 장점이 있는 반면 스토리지 용량의 확장이 제한되고 스토리지 사용 용도가 NAS로 한정되는 단점이 있다.
 한편, 전용파일 서버와 스토리지가 별도로 구성되는 경우 설치가 복잡해지는 대신 스토리지 용량의 확장성이 좋으며 스토리지가 DAS, NAS,SAN 등의 용도로 동시에 자유자재로 사용할 수 있는 장점이 있다.
 NAS 방식에서 사용하는 프로토콜은 서버의 NFS와 CIFS를 사용하여 파일을 공유한다. 즉 파일서버는 NFS(Network File System: 유닉스의 파일 공유 프로토콜) 서버 프로세서가 탑재된 유닉스 머신 또는 CIFS(Common Internet File System: 윈도우의 파일 공유 프로토콜) 서버 프로토콜이 탑재된 윈도 NT 또는 윈도 2000 서버와 같은 역할을 한다.
 다만 범용 서버와 전용 파일 서버의 차이점은 유닉스나 윈도 NT와 같은 범용 운영체제를 사용하지 않고 NFS, CIFS와 같은 파일 서비스에 특화된 전용 운영체제를 사용하여 파일 서비스의 성능이 뛰어나다는 점과 일 서버로서의 가용성을 확보하고 있다는 점이다.
 또한 NFS 프로토콜과 CIFS 프로토콜이 커널의 동등한 계층에 위치하여 같은 파일 시스템을 사용하여 유닉스 머신과 윈도 NT 머신 사이에 파일공유를 할 수 있다는 점이다. NAS의 장점은 파일 공유이다. NAS의 파일 서버가 NFS와 CIFS 프로토콜을 통해 여러 애플리케이션 서버들 사이에 파일을 공유할 수 있게 해주는 것이다.
 NAS는 현재 존재하는 파일 공유 솔루션 중 가장 안정적인 솔루션이다. NAS의 파일 서버가 파일 시스템을 한 곳에서 관리하여 DAS 에서 여러 서버들이 파일을 공유하려 했을 때 나타났던 록킹과 컨시스턴스 문제는 생기지 않는다.
 NAS의 단점은 NAS가 파일 서비스에 특화되어 있기 때문에 데이터베이스를 사용하는 온라인 트랜젝션 환경에서는 DAS만큼 성능이 나지 않는다는 점이다. 또한 LAN 과 채널로 접속 단계가 많아서 장애가 일어날 수 있는 포인트가 많아진다. LAN이 불안정할 경우 많은 문제점이 나타날 수 있다. 그리고 사용빈도가 높아질수록 하용자의 네트워크에도 문제를 야기할 수 있다.
 그러나 현재 LAN은 기술이 상당히 성숙되어 있고 기가비트 이더넷의 성능도 많이 향상되어 있다. 최근 최신 기술로 LAN을 구성한 곳이라면 LAN이 문제가 되어 NAS를 쓰지 못하는 곳은 없으리라 생각된다.
 NAS의 장단점을 종합해 보았을 때 NAS는 웹 호스팅 및 CAD/CAM 과 같은 파일 공유가 필요한 파일서비스에 가장 적합한 솔루션이라고 생각된다.


* SAN


SAN  방식은 서버와 스토리지 사이에 파이버 채널 스위치를 넣은 구성으로 스토리지에 대한 고속 액세스와 일원적인 관리, 그리고 확장성과 내장애성을 높이는 것이 목적이다.
 SNIA(Storage Networking Industry Association)의 용어 정의에 따르면 "대용량의 데이터를 연결된 서버에 관계없이 원거리에 분산된 저장 장치 사이에 주고받을 수 있도록 해주는 초고속 통신망" 이라고 한다.
  SAN 환경에서 저장장치는 호스트 서버와의 주종 관계에서 벗어나 여러 개의 서버와 공유되며 호스트 서버에 의존하지 않고 저장 장치간(Any-to-any)에 운영이 가능하도록 연결되어 디스크나 테이프 장비의 공동사용, 복제 기능과 고가용성을 위한 클러스터링을 가능하게 한다.
 SAN 방식의 장점은 DAS에서 스토리지당 접속 서비스의 증가, 서버당 접속 스토리지 수의 증가, 관리 비용의 절감 등을 목적으로 채널 접속에 네트워크의 개념을 도입한 것이다. 사용자 네트워크와는 별도의 네트워크를 이용하여 데이터 서비스를 제공하므로 사용자 네트워크 부하를 줄여준다. 구성의 유연성, 확작성, 가용서이 뛰어나며, 스토리지 장비를 한곳에 모아둘 수 있고, 모든 서버들을 백업하기 위해 공동의 자동화된 테잎 라이브러리를 사용할 수 있다.
 또한 관리 자원을 통합할 수 있어 스토리지 통합에 따른 관리비용절감 효과가 크다. SAN은 현재 세간의 관심사로 향후 스토리지의 구축방향이 통합 관리되어지는 형태로 구성될 것으로 보인다.
 SAN 방식의 단점은 별도의 백엔드 네트워크 구축을 위한 비용이 증가하여 고가라는 점과 구성이 복잡하다는 것이다.


SCSI에 견줄 만큼 막강해진 'ATA'


 현재 2차 스토리지라고 불리는 모든 제품들은 공통적으로 ATA(Advanced Technology Attachment) 드라이브를 탑재하고 있다. ATA 는 흔히 IDE(Integrated Drive Electronics)라 부르던 것을 ANSI(American National Standards Institute)의 X2T10 그룹이 공식으로 명명한 명칭이다.
 컴퓨터 마더보드의 데이터 경로, 즉 버스(Bus)와 디스크스토리지간의 전기적인 표준 인터페이스를 말한다. 오늘날 대부분의 컴퓨터는 개선된 버전인 EIDE(Enhanced IDE)를 사용하고 있고, 마더보드 내에 IDE/EIDE 컨트롤러를 장착하고 있는 경우가 많다.
 이 기술을 지금까지 PC에 주로 적용돼 온 탓에 스토리지 장비용으로는 신뢰할 수 없는 인터페이스라는 게 일반적인 평가여쓰나  ATA 드라이브의 품질이 크게 개선되면서 상황이 달라지고 있다.
 ATA는 여전히 SCSI나 파이버 채널보다 느리긴 하지만, 그 차이는 지난 몇해 동안 크게 좁혀졌다. 최근 드디어 상용화 단계에 접어든 시리얼 ATA(SATA)는 기존 병렬 ATA(PATA) 방식(130Mbps)과 달리 150Mbps의 속도를 지원하고 있다. 2세대에 이르면 300Mbps, 3세대 방식은 600Mbps까지 속도를 높일 수 있을 것으로 예상된다.
SCSI와 파이버 채널 드라이브에게는 힘겨운 경쟁상대가 등장한 것이다.
 이와 같이 저가형 대용량 ATA 드라이브는 오늘날의 D2D(Disk to Disk) 닝라인 백업 장비 개발과 NAS 업체들에게 폭발적인 호응을 얻고 있다. 특히 D2D 업체들은 SAN 이나 SCSI에 파이버 채널이 직접 연결되도록 어레이에 인터페이스를 포함시키고 있다. ATA 는 데이터센터에서도 사용할 수 있는 방법을 제시하고 있다.
 시장조사 전문업체인 가트너의 존 몬로 사장은 "시리언 ATA는 비교적 저렴한 비용으로 사용할 수 있는 인터페이스로, 기업용 스토리지 애플리케이션에서 매우 중요한 역할을 할 것으로 기대된다. 최근 대기업들은 스토리지 시스템에서 다양한 멀티플 인터페이스를 신중히 받아들이기 시작했다. 이에 따라 서버 및 스토리지 시장 환경에서 2007년까지 모든 하드디스크드라이브의 30% 이상이 기업용 시리얼 ATA 인터페이스를 사용할 전망이다" 라고 말했다.
 ATA 기수르이 눈부신 발전과 고객들의 요구가 맞물리면서 2차 스토리지 시장은 본격적인 개화를 맞이하고 있다. 그 가운데 현재 가장 먼저 반응을 보이고 있는 고객층은 순차적인 접근을 특성으로 하는 애플리케이션 데이터, 즉 고정 콘텐츠를 저장하기 위해 그 동안 값지싼 온라인 디스크를 사용하던 기업들이다.
 지금까지 주요 스토리지 제조업체들은 물론 기업들조차 멀티유저 데이터베이스 애플리케이션에서 생성되는 가변 데이터에 더 많은 관심을 뒀던 것이 사실이다. 하지만 디지털 콘텐츠의 75%가 고정 콘텐츠라는 조사 결과를 감안한다면, 이제 고정 콘텐츠 관리에 더 많은 노력을 기울여야 한다는 계산이 나온다. 최근 고정 콘텐츠 관리를 위한 확장성, 관리의 편의성, 데이터 보호 및 보안성을 보장하는 저렴한 솔루션이등장하여 고객들이 관심을 보이기 시작했다.
 고정 콘텐츠 만을 저장하기 위한 용도가 아니라 온라인 디스크와 마찬가지로 직접 접근이 필요한 모든 데이터를 저장하는 1차 스토리지 용도로 2차 스토리지를 구매하는 기업들도 늘고 있다. 주로 중소기업들이 여기에 속하는데, 이들은 ATA 디스크의 에러율이 SCSI의 80%까지 쫒아온 마당에 굳이 10배 이상 가격 차이가 나는 디스크 어레이를 고집할 이유가 없다고 주자한다. 이들의 주장에 일부 금융권까지 동조하고 나서면서, 2차 스토리지가 급성장을 예고하고 있다.
 SMB 시장에서도 적지 않은 인터넷 업체들이 1차 스토리지 용도로 ATA 디스크를 채택했으며, 일부 시중은행도 ATA디스크를 1차 스토리지 용도로 사용중이다.

'Network > Network' 카테고리의 다른 글

멀티캐스트 (Multicast)  (0) 2011.11.02
X25 와 TCP/IP  (0) 2011.08.26
네트워크 로드 밸런싱 시스템  (0) 2010.04.06
L4스위치  (0) 2010.04.06
폴트 톨러런트 (Fault Tolerant), 로드 밸런싱 (Load Balancing)  (1) 2010.04.06
:

네트워크 로드 밸런싱 시스템

Network/Network 2010. 4. 6. 18:35

네트워크 로드 밸런싱 시스템
  • 자체 부하 분산 알고리즘에 의하여 응답이 없거나 이상이 생긴 서버 자동 감지
  • 이상이 생긴 서버 자동 감지 후는 약 5초 후에 나머지 정상적인 서버에서 사용자 서비스를 함으로서 무정지 서비스 제공
  • Web Server 또는 IP 기반의 서비스에 대한 부하 분산 및 Fail-Over 제공(최대 32 Node 지원)
  • 새로운 network load balancing 관리자 도구로 클러스터 원격에서 관리, TCP/IP 및 NLBS 세팅을 원격에서 제어, 수정
  • 다중 NICs 카드가 NLBS에 바운드 가능, IP 주소 별 포트 규칙 설정, 웹 사이트나 어플리케이션 서비스를 제공할 호스트 선택 가능 

'Network > Network' 카테고리의 다른 글

멀티캐스트 (Multicast)  (0) 2011.11.02
X25 와 TCP/IP  (0) 2011.08.26
NAS SAN SATA SCSI 방식 차이점  (0) 2010.04.06
L4스위치  (0) 2010.04.06
폴트 톨러런트 (Fault Tolerant), 로드 밸런싱 (Load Balancing)  (1) 2010.04.06
:

L4스위치

Network/Network 2010. 4. 6. 18:21

L4스위치

: 시스템에 대규모로 들어오는 요청을 로드밸런싱 기능을 이용하여 여러
서버에 고속 분배하는 라우팅 기능을 포함한 스위칭 장비입니다.


www.naver.com으로 접속한다고 치고 네이버에 웹서버가 두대가 있다면

그 서버가 211.218.150.200과 211.218.150.201이라고 치고 각 서버가

L4스위치에 물려있고 사용자는 www.naver.com으로 서비스 요청을 하겠져

처음 사용자가 www.naver.com에 접속을 한다면 211.218.150.200으로 접속이

된다고 칩시다 그러면 그다음 사용자는 211.218.150.201로 접속이 되고요.

이렇게 한쪽으로 치우치지 않게 사용량을 분배하는 것이 서버로드벨런싱입니다.

그리고 한쪽 서버(211.218.150.200)가 죽어버리면 그 서버가 정상동작

을 할때까지 그 포트를 차단시키는 기능도 있읍니다. 이렇게 되면 211.218.150.201

에만 접속이 되고 속도도 처하됩니다. 빨리고쳐야 정상적인 속도를 찾겠져.

만약에 이 기능이 정상적으로 동작을 안하면 어떤 때에는 접속이 되고

어떤 때에는 안돼고 그렇겠져...--; 쓰바 왜 안돼는 거야...TT

그리고 서버는 여러개인데 순차적으로 첫번째 것에만 사용자가 달라붙으면

느려 지겠고요 - 접속 서버가 여러대일 경우 로드밸런싱이 적용 안됀 경우는


서버1-사용자1 서버2-사용자2 서버3-사용자3 서버4-사용자4 서버5-미접속

서버1-사용자1 서버2-접속해제 서버3-사용자3 서버4-사용자4 서버5-미접속

서버1-사용자1 서버2-사용자5 서버3-사용자3 서버4-사용자4 서버5-미접속

서버1-접속해제 서버2-사용자5 서버3-사용자3 서버4-사용자4 서버5-미접속

서버1-사용자6 서버2-사용자2 서버3-사용자3 서버4-사용자4 서버5-미접속

이런식으로 서버5부터 다음 서버는 놀겠져...--;


이런 것을 해결하기 위한 기능이져.

이 로드벨런싱은 회선에서도 적용이되져 어느정도 트래픽이 한쪽으로

치우치면 트래픽이 사용량이 적은 쪽으로 데이타를 보내는 기능 등이져....


로드 벨런싱 한마디로 여러 경로를 한쪽으로 치우침없이 균등하게 사용하겠다는 겁니다.

단점이 있다면 하나가 다운되면 트래픽이 한쪽으로 치우쳐서 둘다 퍼지는 경우도 있읍니다.
: