Linux 에서 외부 방향으로 TCP 6000-6010번 개방

1) 외장하드 자체의 문제

=> 판단 방법

다른 PC에 꽂아본다.

다른 PC에서도 안된다면?  외장하드의 문제.

다른 PC에선 잘 동작한다면?  PC 설정의 문제.

즉, PC 설정의 문제라는 것. 이런 경우 2번으로.

2) 디바이스 설정의 문제

=> 부팅 시에 BIOS 로 진입한다.

'Always On USB' 설정이 Disable 되어 있는 것을 Enable 로 바꾼다. 정상 작동 된다.

3) 하드웨어 USB 커넥터 연결부의 문제

=> 낮은 확률이지만 해당 하드웨어가 망가진 경우가 있다.

이 것은 저의 경우이며, 실제로 USB가 작동하지 않는 경우의 수는 무척 많음을 미리 알려드립니다.

상황에 따라 추정되는 원인을 계속 좁혀나가는 노력이 필요합니다.

for file in `ls *.zip`; do unzip "${file}" -d "${file:0:-4}"; done

현재 폴더에 zip 파일의 이름과 같은 폴더가 생성이 되고, 각각의 폴더 아래에 zip 파일의 내용물들이 생성된다.

예를 들어, 1.zip, 2.zip 파일이 있으면, 1, 2폴더가 생성되고 그 아래에 각각 내용물이 생김

현재 폴더 내 모든 gz파일의 압축을 푼다.

for file in `ls *.gz`; do gunzip "${file}" -d "${file:0:-4}"; done

for file in `ls *.zip`; do unzip "${file}"; done

해당 기능은 Linux 파일시스템 자체 보호를 위한 기능으로서, mount 횟수가 특정 수를 넘거나 점검한지 특정 일이 지나면, 재부팅시에 파일시스템을 점검하게 되는 옵션이다.

안전성을 위해 마련된 기능이므로 시간의 여유가 없는 경우가 아니라면 활성화 해두는 것이 권장 사항이다.

파티션 리스트 확인

# df -Th

Filesystem    Type     Size   Used  Avail Use% Mounted on

/dev/sdb5     ext3     180G   7.6G   164G   5% /

/dev/sdb2     ext3     102G   394M    96G   1% /var

/dev/sda1     ext3     295G    51G   229G  19% /srv

/dev/sdb1     ext3     104M    13M    87M  13% /boot

tmpfs        tmpfs     9.5G      0   9.5G   0% /dev/shm

체크 설정을 확인한다.

#tune2fs -l /dev/sda1 | egrep ^"Maximum|Check"

Maximum mount count:      33

Check interval:           15552000 (6 months)

33 번 이상 mount 되거나,  재부팅 6개월이 지나면 재부팅 시 자동으로 검사하는 옵션이 설정되어 있다.

File System이 클 경우,  굉장히 오랜 시간이 걸리므로 필자는 부득이한 경우가 아니면 해지하고 있다.

해지 옵션은 아래와 같다.

tune2fs -c -1 /dev/sda1

tune2fs -i 0 /dev/sda1

해지 후 설정 확인

# tune2fs -l /dev/sda1 | egrep ^"Maximum|Check"

Maximum mount count:      -1

Check interval:           0 (<none>)

이제 시스템 부팅 시 자동 파일시스템 검사 기능이 해지되어 진행되지 않는다.

리눅스는 최근 30일에 해당하는 하드웨어 사용량 정보를 /var/log/sa 아래에 보관한다. 

sa01,sa02,sa03,sa04. . . . . . . . . .

sar -r -f /var/log/sa/sa04

: 이번달 4일에 해당하는 정보 확인

06:00:01 PM kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty

06:10:01 PM    244344  15170888     98.41       100  13766076   3807512     11.78   7710300   6600556       696

06:20:01 PM    182160  15233072     98.82       100  13826040   3808744     11.79   7770524   6601320      1600

06:30:02 PM    670180  14745052     95.65       100  13332372   3808400     11.79   7207612   6669880       344

06:40:01 PM    607100  14808132     96.06       100  13392108   3808436     11.79   7268644   6670388       404

06:50:01 PM    547724  14867508     96.45       100  13452116   3807988     11.79   7327304   6671260       728

[root@server-2 sa]# cd /var/log/sa

[root@server-2 sa]# ll -h

total 71M

-rw-r--r-- 1 root root 1.4M Jul  1 23:50 sa01

-rw-r--r-- 1 root root 1.4M Jul  2 23:50 sa02

-rw-r--r-- 1 root root 1.4M Jul  3 23:50 sa03

-rw-r--r-- 1 root root 1.4M Jul  4 23:50 sa04

-rw-r--r-- 1 root root 1.4M Jul  5 23:50 sa05

-rw-r--r-- 1 root root 1.4M Jul  6 23:50 sa06

-rw-r--r-- 1 root root 1.4M Jul  7 23:50 sa07

-rw-r--r-- 1 root root 1.4M Jul  8 23:50 sa08

-rw-r--r-- 1 root root 1.4M Jul  9 23:50 sa09

-rw-r--r-- 1 root root 1.4M Jul 10 23:50 sa10

-rw-r--r-- 1 root root 1.4M Jul 11 23:50 sa11

-rw-r--r-- 1 root root 1.4M Jul 12 23:50 sa12

-rw-r--r-- 1 root root 1.4M Jul 13 23:50 sa13

-rw-r--r-- 1 root root 1.4M Jul 14 23:50 sa14

-rw-r--r-- 1 root root 683K Jul 15 11:30 sa15

-rw-r--r-- 1 root root 1.4M Jun 16 23:50 sa16

-rw-r--r-- 1 root root 1.4M Jun 17 23:50 sa17

-rw-r--r-- 1 root root 1.4M Jun 18 23:50 sa18

-rw-r--r-- 1 root root 1.4M Jun 19 23:50 sa19

-rw-r--r-- 1 root root 1.4M Jun 20 23:50 sa20

-rw-r--r-- 1 root root 1.4M Jun 21 23:50 sa21

-rw-r--r-- 1 root root 1.4M Jun 22 23:50 sa22

-rw-r--r-- 1 root root 1.4M Jun 23 23:50 sa23

-rw-r--r-- 1 root root 1.4M Jun 24 23:50 sa24

-rw-r--r-- 1 root root 1.4M Jun 25 23:50 sa25

-rw-r--r-- 1 root root 1.4M Jun 26 23:50 sa26

-rw-r--r-- 1 root root 1.4M Jun 27 23:50 sa27

-rw-r--r-- 1 root root 1.4M Jun 28 23:50 sa28

-rw-r--r-- 1 root root 1.4M Jun 29 23:50 sa29

-rw-r--r-- 1 root root 1.4M Jun 30 23:50 sa30

-rw-r--r-- 1 root root 1.1M Jul  1 23:53 sar01

-rw-r--r-- 1 root root 1.1M Jul  2 23:53 sar02

정확한 시간대 확인을 위해서는 ls 명령어로 생성된 시각을 확인해보면 된다.

파이버 채널과 같은 일반적인 커뮤니케이션 및 데이터 전송 인프라에 연결된 상호 연결된 장치 (예: 디스크와 테이프)와 서버 모음으로 정의할 수 있다. 주어진 배포작업을 위한 일반적인 커뮤니케이션 및 데이터 전송 메커니즘은 스토리지 패브릭으로 통상 알려져 있다. SAN의 목적은 모든 서버가 모든 스토리지 장치에 액세스할 수 있는 스토리지 풀에 여러 대의 서버가 액세스 할 수 있도록 하는 것이다. 이러한 환경에서는 분명히 보안 (어떠한 장치에 누가 액세스하도록 허용되는지) 및 시퀀싱이나 직렬화 (누가 어느 시점에 어떠한 장치에 액세스할 수 있는지)를 보장하는 관리작업이 매우 중요한 역할을 한다. 

SAN은 스토리지 사용량이 폭발적으로 급증할 때 보다 어려워지는 스토리지 관리작업을 해결하기 위해 생겼다. 주어진 서버에 로컬로 연결된 장치들이나 서버 엔클로저 자체의 장치들로 인해 일상적인 관리 업무 수행작업이 더욱 복잡해지고 있다. 데이터센터에 데이터를 백업하는 것은 그 데이터가 노드 사이에서 배포되고 연결된 서버를 통해서만 액세스될 수 있기 때문에 절차가 매우 복잡하다. 하나의 서버가 자신의 현재 스토리지 풀보다 커질 때 그 서버에 대한 스토리지는 다른 서버의 스토리지 여유공간이 여유 있더라도 보충되고 추가되어야 한다. 그 밖의 다른 이점들로는 다수의 서버가 데이터를 공유할 수 있고 (순차적으로 또는 경우에 따라선 병렬로), 데이터를 백업 서버에 먼저 전송하지 않고도 장치에서 장치로 직접 데이터를 전송하여 장치를 백업할 수 있다. 

그런데 왜 다른 상호 연결 기술 들을 여전히 사용할까? SAN은 다른 네트워크와 마찬가지이다.(예를 들어 LAN 인프라와 같은). SAN은 어느 곳에서나 모든 장치로 액세스 할 수 있도록 서로 다른 장치들과 호스트를 연결하는 데 사용된다. SCSI와 같은 기존의 스토리지 기술은 대형 스토리지 장치를 호스트 컴퓨터에 연결하기 위해서 특별한 조정이 필요하다. 특히 이는 상당히 높은 데이터 무결성 구조를 지닌 낮은 대기시간과 높은 대역폭 연결이다. 반면에 네트워크 기술은 어플리케이션 간의 연결에 있어 더욱 복잡하고 대규모적인 환경을 제공하도록 조정된다. 일반적인 네트워크 인프라는 연결성이 높고, 매우 멀리 떨어져 있는 다수의 독립 네트워크 세그먼트들 간에 데이터를 라우트할 수 있으며 수많은 네트워크 관리 기능 및 문제해결 도구가 있다. 

SAN은 먼 지역까지 확장될 수 있고 높은 연결성과 우수한 관리 인프라를 보유하며 낮은 대기 시간과 높은 대역폭의 상호 연결을 제공하기 위해 최고의 스토리지 기술과 네트워크 기술을 사용한다.

SAN 환경 이점 #

단일 풀로 스토리지를 집중시킨다. 이는 스토리지 리소스와 서버 리소스가 독립적으로 성장할 수 있도록 해 주고 필요 시 풀에서 스토리지가 동적으로 할당될 수 있게 해 준다. 해당 서버의 스토리지는 복잡한 재구성 또는 장치의 재연결 없이도 필요에 따라 증가되거나 감소될 수 있다.

스토리지 연결을 위한 일반적인 인프라는 구성과 배포를 위해 하나의 일반적인 관리 모델을 허용한다.

스토리지 장치란 본래 다수의 시스템에 의해 공유된다. 해당 장치의 데이터 무결성을 보장하는 것과 액세스 권한을 위한 보안 정책을 실행하는 것은 해당 인프라의 핵심적인 부분이다.

데이터는 서버의 작업없이도 장치간에 직접적으로 전송될 수 있다. 예를 들어 데이터는 백업 서버 메모리에 먼저 읽혀지지 않더라도 디스크에서 테이프로 이동 될 수 있다. 이는 관리 관련 작업들보다는 비즈니스 로직에 대한 계산 주기를 계산한다.
여러 대의 서버가 스토리지 장치로 직접 액세스 하기 때문에, SAN 기술은 데이터 모음에 대한 공유 액세스가 요구되는 환경에 클러스터를 구축할 때 특히 관심을 가지게 되는 기술이다. 클러스터링된 SQL Server™ 환경을 생각해 보면, SQL Server 인스턴스는 언제든지 클러스터 내의 하나의 시스템에 호스트 될 수 있고 자신이 호스트된 노드에서 디스크의 관련 데이터베이스로의 독점적인 액세스 권한을 가질 수 있어야 한다. 장애나 명시적인 관리 작업의 경우, SQL Server 인스턴스는 클러스터의 다른 노드로 장애조치 될 것이다. 장애가 조치되었을 때 SQL Server 인스턴스는 자신의 새로운 호스트 노드에서 디스크상의 데이터베이스에 대한 독점적인 액세스 권한을 가질 수 있어야 한다.

SAN (Storage Area Network) 구성요소 #

파이버 채널 (Fibre Channel) 토폴로지 #

지점간 (Point-to-point)
#

지점간 파이버 채널은 그림 1과 같이 2개의 장치만 직접 연결하는 간단한 방법입니다. 이는 DAS (Direct Attached Storage)와 동일한 파이버 채널이다.

그림1. 지점간 연결 
(이미지출처 - blog.syszone.co.kr/attachment/zb4_pds_doc_240.doc)

연결 루프 (Arbitrated Loops) #

FC-AL (Fibre Channel Arbitrated Loop)은 정확히 말 그대로 아래 그림 2와 같이 하나의 루프에 연결된 호스트와 장치들의 모음이다. 이는 비용 효율적인 방법으로 하나의 네트워크에 최대126개의 장치와 호스트를 연결한다. 

루프상의 장치들은 미디어를 공유한다. 루프에서 각 장치는 다음 장치로 연속적으로 연결되면서 루프 둘레에 위치한다. 한 장치에서 다른 장치로 이동하는 모든 패킷은 중간의 모든 장치를 지나가야만 한다. 예를 들어 호스트 A가 장치 D와 커뮤니케이션하기 위해서 이 장치들 사이의 모든 트래픽은 호스트 B와 장치C의 어댑터를 통해 지나가야 한다. 루프의 장치들은 패킷을 볼 필요가 없고 단지 그들을 지나가게만 할 것이다. 물리적인 측면에서 이는 파이버 채널 인터페이스 카드가 하는 일이다. 호스트나 장치에서 프로세싱해줄 필요는 없다. 이는 토큰 링 토폴로지가 작동하는 방법과 매우 유사하다.

그림2. FC-AL (Fibre Channel Arbitrated Loop) 
(이미지출처 - blog.syszone.co.kr/attachment/zb4_pds_doc_240.doc)

FC-SW (Fibre Channel Switched Fabric) #

FC-SW에서 장치들은 아래 그림 3에서처럼 파이버 채널 스위치 (fibre channel switches)를 사용하여 다 대 다 (many-to-many) 토폴로지로 연결된다. 호스트나 장치가 다른 호스트 또는 장치와 커뮤니케이션할 때 진원지와 목표 지점 사이에 지점간 연결 (가상 회로와 같은)이 설정되고 서로간의 직접 커뮤니케이션이 이루어진다. 패브릭 그 자체는 진원지로부터 목표 지점으로 데이터를 라우트한다. FC-SW에서 미디어는 공유되지 않는다. 모든 장치는 다른 모든 장치와 커뮤니케이션할 수 있고 (커뮤니케이션 하고 있지 않다는 가정하에), 커뮤니케이션은 다른 장치나 호스트간의 커뮤니케이션에 상관없이 최대 버스 스피드로 이루어진다.

그림3. FC-SW (Switched Fibre Channel Fabric) 
(이미지출처 - blog.syszone.co.kr/attachment/zb4_pds_doc_240.doc)

호스트 버스 어댑터 (HBA) #

HBA는 서버나 호스트 컴퓨터 내부에 장착되는 인터페이스 카드이다. 이는 기존의 이더넷 네트워크의 NIC와 같은 기능을 한다. 스토리지 패브릭이나 루프로의 모든 트래픽은 HBA를 통해 이루어진다.

HBA는 과거의 Compaq 카드와 기존의 Tachyon 기반 카드를 제외하고 FC-AL과 패브릭 모두를 지원한다(1999년 이후). 하지만 구성은 생각한 만큼 간단하거나 자동적이지 못하다. HBA 가 자신을 적절한 설정으로 구성했는지를 알아내기는 어렵다. Brocade 패브릭에서는 모든 것들을 연결할 수 있지만 그들 중 일부는 루프에서처럼 작동하고 여전히 작업 중인 것으로 보일 수 있다. 스위치 측에서 호스트들이 적절한 모드로 작동하고 있는지를 확인하는 것이 중요하다.
 

허브 #

허브는 파이버 채널 장치의 가장 단순한 형태이며 연결 루프 구성에서 장치와 호스트를 연결하는데 사용된다. 허브는 일반적으로 최대 16개의 장치와 호스트를 연결할 수 있도록 4, 8, 12 또는16 포트를 가지고 있지만 허브상의 대역폭은 허브의 모든 장치에 의해 공유된다. 또한 허브는 일반적으로 양방향 교차 통신 방식이다 (새로운 양방향 동시 통신 방식이 곧 상용화 될 것 이다). 즉 다시 말해서 허브상의 장치나 호스트 간의 커뮤니케이션은 한번에 한 방향으로만 이루어질 수 있다. 이러한 성능상의 제약 때문에 허브는 일반적으로 소규모나 낮은 대역폭 구성에 사용된다.

아래의 그림 4는 허브에 연결된 2개의 호스트와 2개의 스토리지 장치를 보여 주며, 검은 색 화살표는 허브에 의해서 제공되는 물리적인 루프를 보여준다.

그림4. FC-AL 허브 구성 
(이미지출처 - blog.syszone.co.kr/attachment/zb4_pds_doc_240.doc) 

일반적인 허브는 허브상의 비어있는 포트를 탐지하고 그것들을 루프에 구성하지 않는다. 일부 허브들은 포트가 구성되는 방법과 루프에 장치가 추가되는 시점을 제어하는 더 높은 수준의 제어기능을 제공한다.

스위치 #

스위치는 아래의 그림 5에서처럼 각 포트에 독립적으로 완전 파이버 채널 대역폭을 제공하는 보다 복잡한 스토리지 패브릭 장치이다. 일반적인 스위치는 연결 루프 또는 Switched 모드 패브릭에 상관없이 어느 곳에나 포트가 구성되도록 한다.

스위치가 연결 루프 구성에 사용될 때 일반적으로 포트는 장치와 호스트가 양방향으로 최대 파이버 채널 속도로 커뮤니케이션할 수 있는 완전 대역폭, 양방향이다. 이러한 모드에서 포트는 연결 루프 구성에서 성능을 제공하도록 구성된다.

스위치는 대규모, 지점간, Switched 패브릭용으로 사용되는 기본적인 인프라이다. 이러한 모드에서 스위치는 모든 장치가 다른 장치와 직접적으로 최대 파이버 채널 속도로 커뮤니케이션할 수 있도록 해 준다.

그림5. Switched 파이버 구성 
(이미지출처 - blog.syszone.co.kr/attachment/zb4_pds_doc_240.doc)

브릿지와 라우터 #

이상적으로 모든 장치와 호스트는 SAN을 인식할 수 있고 단일, 편재하는 환경에서 상호운영이 가능하다. 유감스럽게도 많은 호스트와 스토리지 구성요소는 다른 상호 연결 기술을 사용하여 이미 배포되었다. 이러한 유형의 장치가 스토리지 패브릭 환경에서 역할을 다하도록 하기 위해 여러 종류의 브릿지나 라우터 장치가 상호 운영된다. 예를 들어 아래 그림 6과 같이 SCSI에서 파이버 브릿지 또는 라우터로는 병렬 SCSI (일반적으로 SCSI-2와 SCSI-3 장치)를 사용하여 파이버 네트워크에 연결한다. 앞으로 브릿지는 iSCSI (iSCSI는 커뮤니케이션 메커니즘으로 IP를 사용하고 상위 IP에 SCSI 프로토콜이 계층화되어 있는 상호 연결 장치입니다) 장치가 스위치 SAN 패브릭으로의 연결에 사용될 것이다.

그림6. Switched 파이버 구성 
(이미지출처 - blog.syszone.co.kr/attachment/zb4_pds_doc_240.doc)