Chapter11 Network
i— layout: posts title: chapter11. Performance Tuning - Network date: 2019-02-26 10:37:36 +0900 type: posts published: true comments: true categories: [se] tags: [System, Server] —
- 네트워크의 성능과 수용력 측정
- 아무리 다른 것들을 완벽하게 튜닝했다 하더라도 네트워크 상에서 서버로 접근할 수 없다면 아무런 소용이 없을 것이다. 네트워크 성능을 최적화하려면 시스템 관리자는 특수한 성능 측정 기준을 계산하고 측정하는 방법을 배워야 하며, 그것에 영향을 미치는 요소를 이해할 수 있어야 한다.
- 대역폭 대 지연대기
- 대역폭은 접속의 최대 데이터 전송률이며 초당 비트수(bps)로 표시된다. 지연대기는 패킷이출발지에서 송신된 시간과 목적지에 수신되는 시간 사이의 간격인 지체(delay) 시간을 의미한다. 접속 지연 대기 시간을 테스트 하기 위해서는 ‘매우 빠르고 훌륭한’ 방법인 ping 명령어를 사용할 수 있다. ping은 목적 호스트로 ICMP 요청을 보내고 그것이 돌아오는데 걸린 왕복시간을 측정한다.
ping -s 192.168.0.5 56 10
지연대기에 원이 되는 요소는 일반적으로 다음과 같다. 거리, 물리적 미디어의 종류, 목적지까지의 홉(Hop) 수, 라우터의 부하, 라우터의 큐잉 우선순위- 홉 산정
- 지연대기에 원인이 되는 요소 중 하나가 패킷의 출발지에서 목적지까지 간의 홉 수이다. 홉은 출발지 호스트와 목적지 호스트 간에 있는 라우터를 말한다. 목적지 호스트도 홉 수 에 들어가게 되므로 동일 네트워크에 있는 두 개의 호스트 간의 홉 수는 항상 1이 된다. 각 홉은 접속에 있어서 지연대기를 증가시키는 결과를 가져오기 때문에 홉은 네트워크 상에서 거리의 논리적 단위가 된다. 모든 패킷은 TTL을 가지고 있으며, 이것은 각 홉마다 감소하게 된다. TTL이 0인체로 라우터에 도달하면 라우터는 더이상 패킷을 라우팅하는 것을 거부하고 icmp 시간 초과로 제어 메시지를 패킷의 출발지 호스트로 돌려보내게 된다. 너무 많은 홉은 지연대기를 증가시킬 수 있으므로, traceroute를 이용하여 특정 사이트까지의 홉 수를 자주 확인해 보는 것이 좋다.
/usr/sbin/traceroute -n 192.168.5.6
- 패킷 분실율 측정
- 네트워킹에 있어 고민거리 중 하나가 패킷 분실 혹은 드롭된 패킷이다. 패킷 분실은 패킷이 목적지로 도달하지 못하는 경우에 발생하며 클라이언트 측에 지체와 재전송을 유발하게 된다. 패킷 분실은 다음과 같은 것을 포함하여 다양한 문제에서 기인하게 된다.
- 망가진 케이블, 느슨한 접속
- 고장난 네트워크 인터페이스
- 네트워크 인터페이스의 과부화
- 스위치, 파이어월, 라우터의 기능 장애
- 잘못된 라우팅 정보
- 케이블에서의 전자기적 간섭
- ping 출력을 통해 패킷 분실 문제를 표시할 수 있다.
- 네트워크 오류 측정
- 시스템이 시스템에 있는 인터페이스로 들어오고 나가는 네트워크 커뮤니케이션에서 오류를 탐지하면 커널에 있는 계수기를 업데이터하게 된다. 이런 수기는 netstat -ni를 사용하여 출력할 수 있다. Ierrs는 입력 오류이며, Oerrs는 출력오류이다. 네트워크 오류는 다음을 포함하여 다양한 요소에 의해 발생한다.
- 기형의 패킷
- 고장난 인터페이스 카드나 포트
- 결함이 있는 케이블
- 듀플렉스 불일치
- 물리적 현상:
- 간섭(Inference): 모니터와 같은 장치에서 나오는 전자기적 시그널은 주위의 케이블에 시그널을 생성한다. 이런 시그널이 케이블에서 전송되는 정규 시그널과 간섭을 일으키게 된다.
- 혼선(Crosstalk): 간섭의 한 유형으로 동일 케이블에서 두 선이 다른 시그널을 전송할 때 두 선 사이에서 발생하게 되는 것이다.
- 시그널 감쇠(signal degradation): 긴 케이블을 지나가면서 시그널이 점차적으로 약화되는 것이다. 시그널은 너무 약화되어 목적지에서는 그것을 인식할 수 없게 될 수 있다.
- 충돌 측정: 공유 네트워크에 있는 두 대의 컴퓨터가 동시에 데이터를 전송하려고 시도할 때 발생한다. 각 컴퓨터는 충돌을 탐지하고 충돌이 다시 일어날 수 있는 가능성을 줄이기 위하여 임의의 시간을 기다린 후 패킷을 재전송한다. 충돌은 스위치 이더넷 네트워크에서는 좀처럼 일어나지 않는데 이는 각 포트가 단지 그 컴퓨터의 포트로 향해 오는 트래픽만 보게 되기 때문이다. 그러나 트래픽이 모든 포트로 브로드캐스트되는 허브에서는 주기적으로 충돌이 일어난다.이더넷 허브의 네트워크와 같은 비스위치 환경의 네트워크에서는 충돌 비율이 15%를 넘는다면 심각하다. 일반적인 솔류션은 스위치 환경의 네트워크로 바꾸거나 비스위치 환경이라면 노드 수를 줄이는 것이 될 것이다. 스위치 환경의 네트워크에서 5%를 상회하는 충돌 비율은 불안한 것이다. 다행이도 스위치 환경의 네트워크에서 일반적인 충돌 원인은 듀플렉스 불일치이다.
- 듀플렉스 고려사항: 동시에 전송가능하면 전 양방향통신, 한번에 한쪽만 전송가능하면 반 양방향통신이 된다. 반양방향통신에서는 양쪽이 일단 동시에 전송하게 되면 충돌이 일어난다. 이것이 스위치 환경의 네트워크에서 충돌이 생기는 유일한 이유이다. 하지만 요새 모든 이더넷 하드웨어는 전 양방향통신을 지원한다.
- 아무리 다른 것들을 완벽하게 튜닝했다 하더라도 네트워크 상에서 서버로 접근할 수 없다면 아무런 소용이 없을 것이다. 네트워크 성능을 최적화하려면 시스템 관리자는 특수한 성능 측정 기준을 계산하고 측정하는 방법을 배워야 하며, 그것에 영향을 미치는 요소를 이해할 수 있어야 한다.
- 네트워크 성능 튜닝: 몇 개의 튜닝 작업을 수행함으로써 네트워크 커뮤니케이션의 성능과 신뢰성을 크게 증가시킬 수 있다.
- 듀플렉스 모드 하드코딩: 양방향통신 커뮤니케이션은 지연시간을 줄일 수 있다. 그러나 양방향통신은 단지 동일 네트워크 세그먼트에서 하나의 피어만 있는 스위치 환경에서만 사용할 수 있다. 허브에 연결된 컴퓨터는 반양방향통신 모드에 속하게 된다. 생산 환경이라면 듀플렉스 모드를 자동교섭을 이용하여 결정하면 안 된다. 결과가 정확치 못하기 때문이다. 다중 아키텍처 환경에서 잘못된 자동교섭이 자주 일어나기 때문에 듀플렉스 불일치가 생기게 된 것이며, 네트워크 오류와 높은 지연대기를 유발하는 원인이 된다. 해결방안은 자동 교섭이 전혀 일어나지 않도록 스위치와 서버에 적합한 듀플렉스 모드를 하드코딩하는 것이다.
- 중요 트래픽에 우선순위 부여: T1,T3와 같은 WAN접속은 일반적으로 여러개의 프로토콜을 실어 나르는데 어떤 트래픽이 다른 트래픽보다 더 많은 중요성을 가질 수도 있으며 이 경우 적시에 전송하기 위해 트래픽에 우선순위를 부여해야한다. 우선순위는 네 개의 범주로 우선순위화 될 수 있다. 가장 높은 순위의 트래픽은 Telnet이나 SSH와 같은 대화형 어플리케이션, 그다음은 DNS를 포함한 기술 인프라를 지원하는 트래픽이 된다. 그 다음이 당신의 애플리케이션의 프로토콜이다. 그다음으로 나머지가 처리되어야 한다.
- Telnet(TCP 23), SSH(TCP 22)
- DNS(TCP,UDP 53), SNMP(UDP 161)
- HTTP(TCP 80), HTTPS(TCP 443)
- 기타 트래픽
- TCP 타이머 튜닝: TCP는 안정적인 프로토콜이며, 양쪽 모두가 상대편과의 접속을 유지하는데 책임을 진다. 유닉스 커널에는 이런 프로세스를 지원하기 위한 다양한 타이머가 채택되어 있으며, 그것들을 튜닝함으로써 용량과 성능의 큰 증대를 가져올 수 있다. Keepalive와 TIME_WAIT 인터벌이 이런 프로세스에 이용되는 가장 일반적인 두 개의 장치이다.
- keepalive 타이머: 한쪽만의 접속이 얼마나 열린 상태로 남아 있을 수 있는가를 지정한다. ndd를 이용하여 밀리초 단위로 타이머를 설정할 수 있다.
ndd -set /dev/tcp tcp_keepalive_interval 300000
- TIME_WAIT 인터벌: TCP접속이 닫힌 포트를 커널이 재사용하기 전에 기다릴 시간을 지정하는 것이다. 이런 지연을 두는 이유는 데이터의 무결성 때문이다. 클라이언트가 준비도 하기 전에 서버가 접속을 닫으면 무슨 일이 벌어지느가? 클라이언트는 여전히 서버로 데이터를 전송하는 과정 중이었을 수도 있다.서버의 포트가 재사용된 경우라면, 그 데이터는 잘못된 프로세스로 가게 될 것이고 모든 종류의 문제를 야기하는 원인이 된다. 하지만 재사용 대기시간이 길게 되면 수천개로 한정된 포트가 재사용되기 위하여 기다려야 하는 시간은 긴 시간인 것이다. ndd를 이용하여 튜닝할 수 있다.
.ndd -set /dev/tcp tcp_time_wait_interval 60000
- keepalive 타이머: 한쪽만의 접속이 얼마나 열린 상태로 남아 있을 수 있는가를 지정한다. ndd를 이용하여 밀리초 단위로 타이머를 설정할 수 있다.
- 차후의 네트워크 용량 계획: 네트워크 용량은 매우 제한적인 요소 중 하나인데, 이는 많은 수의 인프라에서 그것을 구현해야하기 때문이다. 예를 들어 사무실에서 인터넷으로 연결하는 단일 T1회선을 사용하기 위해서는 지역 전화회사에서 물리적인 회선과 T1시그널로 전환해주는 CSU/DSU 유니트, CSU/DSU 유니트에서 당신의 네트워크로 연결하는 라우터, 회선의 상대편에서 인터넷을 제공하는 ISP가 필요할 것이다. 이런 복잡한 과정을 처리하기 위해서 조직은 유연성 있는 ㄴ대역폭 솔루션을 가지고 있어야 한다.
- 장기적인 네트워크 트래픽 관찰: 기업이 커짐에 따라서 회선의 사용량이 증가하게 될 것이며 나중에는 병목현상이 일어날 것이다. 이를 막기 위해 대역폭활용도를 모니터하고 더 큰 대역폭이 필요로 하는 정확한 시점을 예측할 수 있게 해야한다. 회선에서의 평균 대역폭 활용도는 30% 이상을 넘어서는 안 되며, 피크 사용량은 70%를 초과해서는 안 된다. 이 선을 초과하게 되면, 사용량 스파이크가 일어나는 경우 위험할 정도로 회선의 용량에 근접하게 되며 회선 상의 다른 네트워크 트래픽의 성능을 감소시키게 될 것이다.
- 가변 대역폭 회선 사용: 가변 대역폭 회선은 일반적으로 제한된 대역폭을 제공하지만 짧은 시간동안 최대 대역폭보다 높은 대역폭을 증강할 수 있다.
Leave a comment