Windows10 – Raid 0 Configuration using Storage Space

저장소 공간을 이용한 Raid 0은(단순-Simple 유형) 구성을해도 속도 향상이 거의 없어

스팬 볼륨일 거라는 말이 많았죠.

구글링을 해보니 저장소 공간 GUI에서는 제대로된 Raid 0 설정을 할 수 없고 파워쉘을 통해 구성을

해야만 되는 거였습니다.

저장소 공간의 “Columns”라는 “열” 설정이 동시에 읽기/쓰기를 할수 있는 피지컬 드라이브 숫자

설정인데 GUI에서 2개의 디스크로 단순(Simple) 유형을 만들면 “Columns”이 “1”로 설정되어 속도

향상이 없던거였습니다. GUI에는 바꿀수있는 옵션이 없습니다.

파워쉘로 “Columns” 를 설정해 만들어주면 Raid 0으로 아주 잘되고 속도 또한 좋습니다.

저장소 공간 Raid 0의 장점은 SSD 트림을 확실하게 지원합니다.

디스크관리자와 작업관리자에서 보드내장 Raid 처럼 하나의 드라이브만 표시 되어 관리가 쉽습니다.

데이터 삭제 없이 디스크를 추가할 수 있습니다.

** 디스크 추가는 처음 설정된 “Columns(열)” 수의 배수로 추가해야 되고 “Columns”수는 고정으로 변하지 않습니다.

예를들어 “2열” 설정으로 디스크 2개를 묶었으면 나중에 추가할때 디스크 2개를 추가해야하고(2,4,6,8…)

디스크 4개가 되도 열수는 “2열” 고정이라 2개 묶은 속도만 나옵니다.

속도는 상관 없고 추가 용량만 필요한 상황일때 좋겠죠.

이제 만드는 방법입니다.

처음부터 끝까지 파워쉘로만 만드는 방법이 있으나 어려우니 저장소 풀 까지는 GUI에서 만듭니다.

1. 디스크관리자를 실행해 Raid 0으로 묶을 디스크들의 볼륨을 삭제 합니다.

2. 제어판 – 저장소공간 – 새 풀 및 저장소 공간 만들기로 들어갑니다.

3. 드라이브를 선택하고 풀 만들기를 합니다.

* 생성 오류가 나는 경우 디스크 초기화를 합니다. 방법은 관리자모드 파워쉘을 실행하고

Get-PhysicalDisk | ft FriendlyName, SerialNumber, UniqueId -auto

하면 드라이브 목록이 뜹니다.

Reset-PhysicalDisk -FriendlyName “WDC WD20 EZRZ-00Z5HB0”

목록에서 초기화할 디스크의 FriendlyName 을 “WDC WD20 EZRZ-00Z5HB0” 에 적어 초기화합니다.

4. 저장소 풀은 만들어 졌으니 “취소” 를 누르고 나갑니다.

“저장소 공간 만들기” 누르면 “Columns” “1” 설정으로 바로 만들어져서 전부 삭제하고 다시 해야 됩니다.

5. 오른쪽에 “풀 이름 바꾸기”에 들어갑니다. 활성화가 안되어 있으면 “확인” 위에있는 설정변경을 누르면 됩니다.

6. 원하는 이름으로 바꾸고 “풀 이름 바꾸기”

7. 관리자모드 파워쉘을 열고

New-VirtualDisk -FriendlyName WriteBack -StoragePoolFriendlyName “NVME” -NumberOfColumns 2 -Interleave 32768 -ResiliencySettingName simple -UseMaximumSize

입력합니다.

-FriendlyName WriteBack : 만들어질 가상 드라이브(Raid0)의 이름인데 나중에 초기화 해야되니 아무거나 해도 됩니다.

-StoragePoolFriendlyName “NVME” : 6번에서 바꿔준 이름을 넣습니다.

-Interleave 32768 : 스트라이프 사이즈입니다. 이 옵션을 빼면 저장소 기본 256K로 됩니다. 일반환경에선 64K나 128K 정도가 성능이 가장 좋습니다. 1024를 곱해서 넣어주면 됩니다. 잔파일이 많을수록 작게, 큰파일이 많을수록 크게 잡는게 좋습니다.

저는 잔파일이 아주 많은 스크래치 디스크라 32K로 했습니다.

-NumberOfColumns 2 : 가장 중요한 2열을 쓴다는 설정입니다. 디스크가 3개면 3을 넣어야겠죠.

-ResiliencySettingName simple -UseMaximumSize : 유형을 단순(Raid0)으로, 디스크 크기는 적용할수있는 최대 사이즈로 만듭니다.

8. 또 다른 내 경우 4개의 NVMe disk Raid 0 으로 설정하기 위해 아래 설정을 이용

New-VirtualDisk -FriendlyName WriteBack -StoragePoolFriendlyName “NVME” -NumberOfColumns 4 -Interleave 131072 -ResiliencySettingName simple -UseMaximumSize

9.제대로 만들어지면 이렇게 나옵니다.

10. 디스크 관리자를 실행해서 초기화하고 포맷하고 쓰면 됩니다.

길어보여도 중간에 파워쉘 명령어만 잘 입력하면 쉽게 만들어 집니다.

참고 링크

https://answers.microsoft.com/en-us/windows/forum/windows_10-files/storage-spaces-trying-to-create-a-raid-0-with/c440086c-4bb6-410d-9e92-fd98ce6626cc

https://social.technet.microsoft.com/Forums/en-US/322755f0-6a38-49b5-9158-49ae04031098/storage-spaces-only-supports-jbod-and-not-raid0?forum=win10itprovirt

https://www.dell.com/support/manuals/ko-kr/storage-md1420-dsms/dsms_bpg_pub-v2/microsoft-storage-spaces-best-practices?guid=guid-8d032e58-86f2-4d36-9617-7a82596848f5

– 델의 마소 저장소 공간 설명서 인데 여러개의 하드를 묶고 SSD로 캐시를 구성하는 방법까지 잘 나와 있습니다.

———————————————————————————————————————————–

<추가합니다.>

** GUI로 풀생성시 물리섹터가 4K인 디스크들을 묶으면 논리섹터가 4K로 잡힙니다.

데이터 입출력에는 문제가 없으나 프로그램이나 게임 실행시 오류가 날수있습니다.

이럴땐 GUI가 아닌 파워쉘에서 논리섹터를 강제로 512로 잡아 풀을 생성해야 합니다.

물리섹터가 512인 디스크들은 자동 논리섹터 512로 잡힙니다.

관리자모드 파워쉘을 실행합니다.

Get-PhysicalDisk | sort-object SlotNumber | select SlotNumber, FriendlyName, Manufacturer, Model, PhysicalSectorSize, LogicalSectorSize | ft

연결된 디스크들의 물리와 논리 섹터를 보여주는 파워쉘 명령어 입니다.

묶을 디스크의 물리섹터가 4K(4096)이고 게임이나 프로그램을 실행한다면 파워쉘로 논리섹터 512로

저장소 풀을 생성합니다.

$PhysicalDisks = (Get-PhysicalDisk -CanPool $True)

풀생성 가능한 디스크들을 보여주고 “$PhysicalDisks” 항목으로 설정.

여기서 보이는 디스크들이 전부 저장소 풀이 됩니다.

New-StoragePool -FriendlyName NVME -StorageSubsystemFriendlyName “Windows Storage*” -PhysicalDisks $PhysicalDisks -LogicalSectorSizeDefault 512

“NVME”라는(원하시는거로 바꿔 주세요.) 새로운 풀을 생성합니다.

-LogicalSectorSizeDefault 512 : 논리섹터 사이즈 512로 설정.

이후 7번 항목 “New-VirtualDisk” 로 저장소 공간을 만들어 주면 됩니다.

프로그램 실행 안하면 물리4k, 논리4K로 쓰는게 속도가 더 빠릅니다.

프로그램이나 게임을 실행한다면 논리섹터 512로 풀을 생성해야 합니다.

전부 그런건 아니지만 일부 게임이나 프로그램에서 논리섹터 4K를 쓰면 오류가 납니다.

물리섹터가 512인 디스크는 논리섹터 4K는 안되고 512만 됩니다.

하드,SSD의 물리섹터는 제품마다 4K, 512 제각각입니다 ㅡㅡ;

Docker Root Directory 위치 변경

개발 중인 서버에 접근해보니 루트 디렉토리가 91% 사용 중이었습니다.

(*도커의 루트 디렉토리 증설은 불가피했음.)

초기 설치 시 /var/lib/docker/overlay 디렉토리 경로 그대로 사용

01. 루트 디렉토리 설정 확인하기

docker info | grep Root 명령어로 Docker Root Dir이 /var/lib/docker임을 확인했습니다.

[root@totoli]# docker info | grep Root
 Docker Root Dir: /var/lib/docker

02. 루트 디렉토리 설정 변경하기

도커의 설정은 /etc/docker/daemon.json를 변경하면 됩니다.
json 형식으로 작성하면 되며, data-root 요소를 작성합니다.

[root@totoli]# vi /etc/docker/daemon.json

{
  "data-root": "/docker-data/data"		# 변경하고자 할 디렉토리로 작성합니다.
}

*example mount path : "/docker-data" 
mkdir /docker-data/data
cp -rp /var/lib/docker/* /docker-data/data/

03. 설정 변경 후 도커 재기동하기

[root@totoli]# systemctl restart docker

04. 루트 디렉토리 설정 재확인하기

docker info | grep Root 명령어로 다시 한번 확인합니다.
설정했던 바와 같이 /docker-data/data로 변경됨을 확인할 수 있습니다.

[root@totoli]# docker info | grep Root
 Docker Root Dir: /docker-data/data

/var/lib/docker/~~~에서 /docker-data/data/~~~ 로 변경됨을 확인.

05. 기존 루트 디렉토리 삭제

docker info | grep Root 명령어로 다시 한번 확인합니다.
설정했던 바와 같이 /docker-data/data로 변경됨을 확인할 수 있습니다.

ls /docker-data/data
* 잘 복사된것 확인 후 .

[root@totoli]# rm /var/lib/docker -Rf

Connect Synology and APC UPS with SNMP protocol

Synology NAS의 안정적인 운영을 위하여 APC사의 UPS를 설치하였다.

UPS 사양은 다음과 같다.

APCSmart-UPS CMS-1500IC

APC UPS의 경우 PowerChute 어플리케이션을 통해서 상황에 따라 서버 전원을 내릴 수 있게 지원하고 있다.

하지만 Synology의 경우 해당 어플리케이션이 없었고, 기본적으로 제공하는 SNMP 기반의 안전모드를 사용해야 했다.

먼저 UPS SNMP를 먼저 설정해준다.

## SNMP V1 이용 시

1. UPS Management Web 접속
2. UPS Management 로그인
3. PowerChute -> SNMP Setting -> SNMPv1(+) 로 이동
4. Enable 체크 후 Apply 클릭
5. User Profiles Add Profile 클릭
6. Community Name 입력 (원하는 값으로)
7. NMS IP/Host Name 설정 (기본값은 0.0.0.0 으로 모두 접속 허용)
   > NMS IP값에 특정 IP를 적으면 그 IP 장비만 SNMP에 접속 할 수 있음.(*Host Name 안됨.)
8. Access Type은 Read로 설정
9. OK 선택 후 Apply 클릭

위와 같이 SNMP 설정이 끝나면, 다음은 Synology NAS 설정이다.

1. Synology NAS 로그인
2. 제어판 열기
3. 하드웨어 및 전원 -> UPS 이동
4. UPS 지원 활성화 체크
5. 네트워크 UPS 유형 "SNMP UPS" 선택
6. RackStation이 안전 모드로 설정되기 전 대기 시간 설정
   (원하는 시간, 예를 들어 20분 등)
7. SNMP UPS IP 주소 입력 (UPS 주소)
8. SNMP MIB는 auto로 설정 (* "apcc" 로 잡아주는게 정확한 값임)
9. SNMP 버전은 v1으로 설정
10. SNMP 커뮤니티는 UPS에서 설정한 값을 입력
11. 적용

위의 절차를 진행하고 잠시 기다리면 장치정보를 확인할 수 있다.

## SNMP V3 이용 시

위와 같이 SNMP 설정이 끝나면, 다음은 Synology NAS 설정이다.

장치 정보 확인 시 UPS 검색 잘 되면

그럼 끝!

VirtualBox network settings (Upgrade settings)

Virtualbox NETWORK 설정

하드웨어 가상화의 핵심 아이디어 중 하나는 물리적 컴퓨터도 사용할 수 있는 거의 모든 경우에 가상 컴퓨터를 사용할 수 있다는 것입니다.

Virtual Network Adapters

각각 VirtualBox VM은 8개의 가상 네트워크 어댑터를 사용할 수 있고, VM은 NIC(Network Interface Controller)를 가지고 있는데 GUI에서는 4개의 어댑터를 설정할 수 있지만, cli의 VBoxManage modifyvm 명령어를 통해서 총 8개까지 설정할 수 있습니다.

VBoxManage 로 조정하는 것은 GUI로 봤을 때 vm 을 클릭 하고 setting을 눌러 network를 세팅하는 것을 말합니다.

Virtualbox에서 제공하는 Network Adapters 종류

AMD PCnet-PCI II (Am79C970A)
AMD PCnet-FASt III (Am79C973)
Intel PRO/1000 MT Desktop (82540EM)
Intel PRO/1000 T Server (82543GC)
Intel PRO/1000 MT Server (825456EM)
Paravirtualized Network Adapter (virtui-net)

※ 업계 표준 virtIO 네트워킹 드라이버는 VirtualBox에서 지원됩니다. (VirtIO 네트워킹 드라이버는 KVM 프로젝트의 일부이며 오픈소스 입니다.)

Jumbo frames support

VirtualBox는 jumbo frames (Ethernet frames that can carry packets which size is more than 1,500 bytes)에 대한 제한된 지원을 제공합니다.

jumbo frames를 사용해야 할 경우

intel virtualized network adapter는 bridged mode를 설정해 사용합니다.
AMD-based virtual network adapter는 위 기능을 지원하지 않습니다.
- 사용할 경우 입력 및 출력 트래픽에 대해 점보 프레임이 자동으로 삭제됩니다. (jumbo frames are disabled by default)

VirtualBox Network Modes

VirtualBox는여러 네트워크 모드를 제공합니다.(VM을 클릭, setting을 수정할 경우 VM의 어댑터가 연결될 네트워크와 VM의 네트워크 어댑터를 선택합니다.)

Not attached
NAT
NAT Network
Bridged Adapter
Internal Network
Host-only Adapter
Generic Driver

Not attached

VM에는 네트워크 어댑터가 설치 되어 있지만, 물리적으로 이더넷 케이블 뽑아 놓은 상황

NAT

네트워크 어댑터 기본 설정으로 인터넷은 되지만, 외부에서 VM에 접속은 안 됩니다.
DHCP을 통해 (10.0.2.15) IP를 고정 할당 받습니다.
(IP가 Virtualbox 에 built-in으로 고정되어 있습니다.)
각 VM의 기본 게이트웨이는 10.0.2.2 입니다.
네트워크 마스크 255.255.255.0 입니다.

※ 각각의 VM은 독립적인 NAT 디바이스로 구성되어 있습니다.

NAT 모드 활성화 cli 명령어

VBoxManage modifyvm VM_name --nic1 nat

VM_name : 가상 기기 이름

nic1 : 가상 네트워크 어댑터 갯수

nat : 임의로 설정할 VirtualBox 네트워크 모드의 이름

[ none

null

nat

natnetwork

bridged

intnet

hostonly

generic ]

사용하지 않음 [none]
Not attached [null]
NAT [nat]
NAT Network [natnetwork]
Bridged Adapter [bridged]
Internal Network [intnet]
Host-only Adapter [hostonly]
Generic Driver [generic]

NAT Network

여러 VM에서 NAT Network를 사용할 경우 VM들은 NAT 네트워크를 통해서 VM들 끼리 통신이 가능하며, VM은 host 기기의 Physical NIC를 통해 외부 네트워크와 통신이 됩니다.

반면, 외부 네트워크의 모든 시스템과 호스트 시스템이 연결된 물리적 네트워크의 시스템은 NAT Network를 사용하도록 구성된 VM에 액세스 할 수 없습니다. (홈 네트워크에서 인터넷 액세스를 위해 라우터를 구성하는 경우와 비슷합니다.)

VirtualBox에서 NAT Network를 추가 구성할 수 있습니다.

default NatNetwork 구성 스위치 IP CIDR 구성은 10.0.2.0/24 입니다.

해당 관리 gateway IP는 10.0.2.1 (구성했던 CIDR 형태에서 x.x.x.1 형태로 IP는 default Gateway IP로 할당 됩니다.)

ex) CIDR 192.168.22.0/24

-> Gateway IP는 : 192.168.22.1으로 설정됩니다.

-> DHCP Server : 192.168.22.3 으로 설정됩니다.

※ NAT Network에서 사용되는 네트워크 게이트웨이 IP 주소는 변경할 수 없으며 DHCP 서버에서 발급한 IP 주소 범위는 변경할 수 없습니다. (마찬가지로 DHCP 서버 IP 주소는 기본적으로 x.x.x.3 형태로 할당 됩니다.)

위에서 설정했던 설정을 cli로 설정할 경우

$ VBoxManage natnetwork add --netname natnet1 --network "192.168.22.0/24" --enable

natnet1 : NAT 네트워크 이름

192.168.22.0/24 : NAT 네트워크에 설정할 CIDR

VM 어댑터에 NAT Network를 붙이도록 설정할 경우

$ VBoxManage modifyvm VM_name --nic1 natnetwork

VM_name : 설정을 세팅할 VM

nic1 : 첫번째 VM 네트워크 어댑터

natnetwork : 사용할 Virtualbox network mode

※ VM 에 위의 세팅을 적용할 경우 VM을 restart 시켜줘야 할 수 있습니다.

윈도우 6.0.12 r133076 GUI 로 수정 테스트 했을 때는 VM restart 없이 적용 되었습니다.

Port Forwarding

VM > Settings > Network : VM에서 사용할 NIC 어댑터와 연결할 네트워크에 대한 설정
File > Preferences > Network : NAT network를 설정, 추가 할 수 있는 설정

Bridged Adapter

VM의 가상 네트워크 어댑터를 VirtualBox 호스트 컴퓨터의 물리적 네트워크 어댑터가 연결된 물리적 네트워크에 연결하는 데 사용됩니다. VM 가상 네트워크 어댑터는 네트워크 연결에 호스트 네트워크 인터페이스를 사용합니다. 간단히 말해 네트워크 패킷은 추가 라우팅 없이 가상 네트워크 어댑터와 직접 주고 받습니다.

로컬 물리 네트워크에 접속하기 위해 주로 사용하며, VM에서 host, host와 연결된 네트워크, 외부 네트워크에 접속이 가능합니다. 이때 호스트에서 여러개의 물리 어댑터를 사용할 경우 사용할 어댑터를 설정해 주어야 합니다.

Bridged Adapter를 사용할 경우 VM 가상 네트워크 어댑터의 IP 주소는 호스트 컴퓨터의 물리적 네트워크 어댑터 IP 주소와 동일한 네트워크에 속할 수 있습니다. 이때 물리적 네트워크에 DHCP 서버가 있는 경우 VM의 가상 네트워크 어댑터는 Bridged mode에서 자동으로 IP주소를 얻습니다.

※ 게스트 OS의 네트워크 인터페이스 설정에서 자동으로 IP 주소 받기가 설정 된 경우에 가능

예를 들면

물리적 네트워크 주소 : 10.10.10.0/24

물리적 네트워크에 있는 기본 게이트웨이의 IP 주소 : 10.10.10.1

물리적 네트워크에 있는 DHCP 서버의 IP 주소 : 10.10.10.1

호스트 컴퓨터 IP 구성 : 10.10.10.72

넷 마스크 : 255.255.255.0

기본게이트웨이 : 10.10.10.1

게스트 컴퓨터의 IP 구성 : 10.10.10.91

넷 마스크 : 255.255.255.0

기본 게이트웨이 : 10.10.10.1

※ 따라서 bridge mode에서 작동하는 가상 네트워크 어댑터의 기본 게이트웨이는 호스트 컴퓨터와 동일합니다.

경우에 따라 물리적 네트워크에 여러 게이트웨이가 있는 경우가 있습니다. 하나의 게이트웨이를 통해 필요한 네트워크에 연결하기 위해 호스트 머신을 사용하고 두 번째 게이트웨이를 통해 다른 네트워크에 연결하기 위해 게스트 머신을 사용할 수 있습니다.

VM에서 라우팅 테이블을 편집하고 두 게이트웨이를 사용해 적절한 네트워크에 연결하기 위한 경로를 추가할 수도 있습니다.

Promiscuous mode (무작위 모드)

이 모드는 네트워크 어댑터가 지정되는 어댑터 주소에 관계없이 수신된 모든 트래픽을 전달할 수 있습니다. 일반 모드에서 네트워크 어댑터는 특정 네트워크 어댑터의 MAC 주소를 헤더의 대상 주소로 포함하는 프레임만 수신합니다.

이 모드는 물리적 네트워크 어댑터가 여러 MAC 주소를 가질수 있도록 할 수 있으며 모든 트래픽이 호스트 시스템의 물리적 네트워크 어댑터를 통과하고 호스트 어댑터에 표시되는 자체 MAC 주소가 있는 VM의 가상 네트워크 어댑터에 도달 할 수 있도록 합니다. IP가 설정되지 않은 VM 가상 네트워크 어댑터에도 도달됩니다.

무작위 모드 종류는 3개로 나뉘는데

Deny : VM의 가상 네트워크 어댑터로 보내지 않은 트래픽은 VM에서 숨겨집니다. (default)
Allow VMs : 다른 VM 과 주고 받는 트래픽을 제외하고 모든 트래픽은 VM 네트워크 어댑터에서 숨겨집니다.
Allow All : 제한이 없으며, VM 네트워크 어댑터는 모든 수신 및 발신 트래픽을 볼 수 있습니다.

Internal Network

내부 네트워크 모드에서 작동하도록 구성된 가상 머신은 격리된 가상 네트워크에 연결됩니다. 이 네트워크에 연결된 VM은 서로 통신할 수 있지만 VirtualBox 호스트 컴퓨터나 물리적 네트워크 또는 외부 네트워크의 다른 호스트와는 통신 할 수 없습니다. 내부 네트워크에 연결된 VM은 호스트 또는 다른 장치에서 액세스 할 수 없습니다. 주로 네트워크 모델링에 사용합니다.

예를 들어 각각 내부 네트워크에 연결된 가상 네트워크 어댑터(어댑터1)가 있는 세개의 VM을 만들 수 있습니다. 이러한 네트워크 어댑터의 IP 주소는 Virtualbox 내부 네트워크에 사용되는 서브넷에서 정의됩니다.(서브넷을 수동으로 정의해야 합니다.)

VM1 – (어댑터2) NAT mode 추가 설정 하여 라우터로 구성 (라우터 역할을 하기 위해 VM에 리눅스를 설치하고 iptables를 설치하는 것이 좋지만, 간단한 라우팅을 사용하기 위해서 내장된 기능을 사용한다.)

VM2, VM3 – 어댑터의 내부 네트워크 어댑터의 IP 주소가 있으면 외부 네트워크에 액세스 할 수있는 유일한 Virtual network에 접속되어 VM1은 네트워크 설정에서 게이트웨이로서 설정합니다.

구성으로 표현하자면

VM1

IP : 192.168.23.1 (내부 네트워크 모드), 10.0.2.15 (NAT 모드), 게이트웨이 10.0.2.2 (내장 VirtualBox NAT 장치 IP 주소)

VM2

IP : 192.168.23.2 (내부 네트워크 모드), 게이트웨이 192.168.23.1

VM2

IP : 192.168.23.3 (내부 네트워크 모드), 게이트웨이 192.168.23.1

VirtualBox 내부 네트워크 서브넷 192.168.23.0/24

※ 실제 네트워크 인프라에서 방화벽 규칙을 구현하기 전에 IPTABLES에서 방화벽 규칙을 테스트하기 위해 이러한 인프라를 배포 할 수도 있지만 외부네트워크에서 연결할 때 VM1의 두 번째 가상 네트워크 어댑터가 NAT 모드가 아닌 Bridge 모드를 사용하는 것이 좋습니다.

Host-only Adapter

호스트와 guest 간의 통신을 위해 사용됩니다. VM은 Host-only로 연결된 VM과 host에 통신이 가능합니다.

Host-only network를 사용하기 위해서는 호스트에서 해당 네트워크 어댑터를 생성해 주어야 합니다. File > Host Network Manager.

위의 경우 Host-only network의 기본 네트워크 주소는 192.168.56.0/24 이고 호스트 컴퓨터에 있는 가상 네트워크 어댑터의 IP 주소는 192.168.56.1 입니다. 이러한 IP 주소는 수동으로 IP를 편집할 수 있습니다.

추가적으로 DHCP 서버 설정을 활성화/비활성화 할 수 있습니다. DHCP 서버 탭에서는 DHCP의 IP주소, 넷 마스크 및 DHCP 클라이언트에 대해 발급할 IP 주소 범위를 설정할 수 있습니다.

※ Host-only mode에서는 외부의 장치에서 호스트 전용 네트워크에 연결할 수 없기 때문에 VM의 가상 네트워크 어댑터에는 IP 구성에 게이트웨이가 없습니다.

Generic Driver

이 모드를 사용하면 일반 네트워크 인터페이스를 공유할 수 있습니다. 사용자는 확장 팩에 배포하거나 VirtualBox에 포함할 적절한 드라이버를 선택할 수 있습니다.

UDP Tunnel : 다른 호스트에서 실행되는 가상머신은 기존 네트워크 인프라를 사용하여 투명하게 통신할 수 있습니다.
VDE Networking : 가상 머신은 Linux 또는 FreeBSD 호스트의 가상 Distributed Switch에 연결할 수 있습니다. 표준 Virtualbox 패키지에는 이 기능이 포함되어 있지 않으므로 VDE 네트워킹을 사용하려면 Virtualbox 소스에서 컴파일해서 만들어진 프로그램을 사용해야 합니다.

네트워크 모드에 따른 접속 가능 확인

Port Forwarding

포트포워딩은 트래픽을 다른 IP 주소 혹은 포트로 리디렉션하는 것 외에도 적절한 IP 주소 및 포트로 주소가 지정된 트래픽을 가로채는 프로세스입니다.

컴퓨터 및 기타 라우터 장치에서 특수 응용프로그램을 사용하여 포트 전달을 구성할 수 있습니다.

포트 포워딩의 가장 일반적인 사용 사례 중 하나는 외부 네트워크에서 NAT 뒤에 숨겨진 특정 네트워크 서비스에 대한 액세스를 제공하는 것입니다. 포트포워딩 규칙을 구성한 후 클라이언트는 라우터 (호스트)의 외부 IP 주소 및 지정된 포트에 연결하여 외부에서 적절한 서비스에 액세스 할 수 있습니다.

패킷은 먼저 라우터의 응용 프로그램에서 가로채고 응용 프로그램은 해당 헤더 (IP 패킷 헤더, TCP 또는 UDP 세그먼트의 헤더)의 대상 IP 주소와 포트 번호를 읽습니다.

헤더의 대상 IP 주소 및 포트 번호 조합이 포트 포워딩 규칙과 일치하는 경우 라우팅 애플리케이션은 헤더 정보 (IP 정보 및 포트 번호)를 다시 쓰고 다른 네트워크 패킷 / 세그먼트로 보냅니다.

포트 포워딩 적용 예시 (SSH 액세스)

호스트 IP : 10.10.10.72 (물리적 NIC)

VM IP : 10.0.2.15 (NAT mode)

사용자 이름 : user1

NAT로 구성된 VM 어댑터에서 Port Forwarding 규칙 설정

VM 클릭 » Settings » Network » Adapter1

SSH 서버는 기본적으로 22 TCP 포트를 수신합니다.

포트 8022로 들어오는 연결을 VM 22번 포트로 전달 할 수 있는 규칙을 만들면 다음과 같습니다.

※ Host는 host, Guest는 guest

Virtualbox 호스트의 실제 네트워크 어댑터의 실제 IP 주소가 될 유사한 포트 전달 규칙을 만드는 경우 물리적 네트워크의 다른 호스트는 포트 8022에서 Virtualbox 호스트 시스템에 연결하여 SSH를 통해 VM에 액세스 할 수 있습니다.

이 예에서는 Virtualbox 호스트에 있는 물리적 NIC IP 주소는 10.10.10.72 입니다.

이렇게 되면 Virtualbox 호스트 또는 LAN에 연결된 다른 호스트에서 SSH 클라이언트를 열고 포트 8022에서 Virtualbox 호스트 IP에 연결합니다.

포트 포워딩 적용 예시 (HTTP 액세스)

VM에 웹 서버를 배포하고 외부에서 웹 사이트에 대한 액세스를 제공하려는 경우 다른 포트 전달 규칙을 추가 할 수 있습니다.

Virtualbox 호스트 머신과 물리적 LAN (Local Area Network)에 연결된 다른 머신에서 VM에 배포된 웹 사이트에 액세스하기 위해 해당 포트 전달 규칙을 구성하는 방법을 예로 들면 다음과 같습니다.

먼저 웹 사이트가 정상 접속 되는지 확인한 후에 진행합니다. 웹은 TCP 8080 를 사용합니다.

VM settings > Network > select adapter > Port Forwarding

RDP, FTP 및 기타 프로토콜을 통해 VM에 액세스하기 위한 규칙을 정의할수도 있습니다.

결론

Virtualbox는 유연하고 다양한 네트워크 설정을 제공하는 강력한 가상화 솔루션입니다.

각 VM은 최대 8개의 가상 네트워크 어댑터를 사용할 수 있으며(단, GUI에서는 4개까지만 설정 가능) 각 네트워크 어댑터는 실제 Intel 및 AMD 네트워크 인터페이스 컨트롤러 (NIC)의 적절한 모델로 에뮬레이션 될 수 있습니다.

Remote-FX : Enable GPU use during RDP mstsc remote connection

원격데스크톱 연결시, Remote-FX 사용하기.

원래 RDP(Remote Desktop Protocol)는 Client Rendering 입니다.

반면, Remote-FX 기술은 Host Rendering입니다.

* 컴퓨터에 원격데스크톱 클라이언트 7.1 이상이 있어야함. (* Win7 Ulti – SP1이상, WinXP SP3이상)

1. 관리자 권한으로 ‘실행’을 실행해주세요. (*RDP Server 역할에서 설정해야 함.)

2. gpedit.msc를 치고 엔터. (그룹정책편집기 실행)

2. 컴퓨터구성 -> 관리 템플린 -> Windows 구성요소
-> 터미널 서비스 -> 원격 데스크톱 세션 호스트 -> 원격 세션 환경으로 갑니다.

3. 원격 세션 환경에 들어가셔서,

모든 원격 데스크톱 서비스 세션에 “하드웨어 그래픽 어탭터 사용”을 “사용”으로 바꿔 줍니다.

> WinXP, 7 : Remote FX 구성을 더블클릭하셔서 사용에 체크하고 확인.
> Win 8 이상 : Enable RemoteFX encoding for RemoteFX clients designed for Windows Server 2008 R2 SP1 항목 더블클릭 후 사용에 체크하고 확인.

나머지는 읽어 보시면서 필요한걸 사용으로 바꿔주도록 합니다.

“하드웨어 그래픽 사용” 이외 셋팅을 하실땐, 가능하면 옆에 노트북 or 옆에 자리 사람 pc 에서 원격 테스트를 하는게 좋습니다. 귀찮다고 모두 사용으로 바꿔 버리면 아래처럼 진짜 집에서 할때 연결이 안되 낭패를 볼 수 있습니다.

제 PC의 셋팅값. 성능을 잡으면서 원격 접속 오류가 안나는 셋팅을 찾는게 중요하고 모르겠으면 하드웨어 그래픽 어댑터 사용만 합니다..

다 되었으면 RemoteFX For Windows Server 2008 R2 .. 폴더로 들어갑니다.

4. Configure RemoteFX (RemoteFX 구성) 을 사용으로 바꿔 줍니다.

* RemoteFX를 사용하시려면, 호스트 컴퓨터의 사용자에게도 Remote Desktop User 권한이 주어져 있어야합니다.

1. 관리자권한으로 ‘실행’을 실행해주세요.

2. lusrmgr.msc를 치고 엔터.(로컬사용자편집기)

3. 사용자 폴더에 가셔서, 자신의 계정을 오른쪽클릭 -> 속성

4. 소속 그룹 탭에 가셔서, 밑의 추가버튼을 눌러주세요.

5. 그룹 선택 창에서 고급을 누르시고, 찾기 버튼을 눌러주세요.

6. 그러면 밑에 좌라락 뜨는데요, 거기서 Remote Desktop Users 를 누르시고 확인.

7. 확인 확인 확인 누르시고, 창 닫아주시면 됩니다.

이렇게 다 해주시고, 컴퓨터 다시 껐다가 켜주시면 Remote FX가 활성화 된 상태가 됩니다.

이후 리붓하고 노트북등으로 RDP접속 해 보면 한결 빨라진걸 느낄 수 있습니다.

Docker를 이용한 로컬 환경에서 GitLab-CE 서버 구축 (with docker-compose)

버전 관리 서버를 private 하게 내부에서 관리할 필요가 있다는 판단하여 docker를 가지고 GitLab 서버를 구축하였다. 구축 과정을 블로그에 남긴다.

DB서버를 사용하는 내부 서버가 있다. 그곳에다 GitLab서버를 구축하려고하였다. 그래서 다른것 하나 생각치않고 docker부터 떠올렸다. 이유는 해당 서버에 DB서버가 구축되어 있기 때문에 GitLab서버를 그대로 설치해버리면 기존에 사용하던 시스템이 망가질 우려가 있었기 때문이다.

따라서 기존의 시스템에 전혀 영향이 가지 않게끔 도커를 이용하여 GitLab 서버를 설치하였다.

hub.docker.com/r/gitlab/gitlab-ce

Docker Hub

hub.docker.com

GitLab 서버 설치

gitlab 서버 설치에 사용한 이미지는 Docker Hub에서 제공하는 이미지를 사용하였다.

docker-compose를 사용한 gitlab 서버 설치의 공식 가이드는 아래의 링크에서 볼 수 있다.

docs.gitlab.com/omnibus/docker/README.html#install-gitlab-using-docker-compose

GitLab Docker images | GitLab

GitLab Docker images The GitLab Docker images are monolithic images of GitLab running all the necessary services in a single container. If you instead want to install GitLab on Kubernetes, see GitLab Helm Charts. Find GitLab’s official Docker image at: T

docs.gitlab.com

나 또한 gitlab 서버 설치할 때 공식 가이드를 참고하여 설치하였다. 내가 작성한 docker-compose.yml 파일의 내용은 아래와 같다.

gitlab:
  image: 'gitlab/gitlab-ce:latest'
  restart: always
  hostname: '127.0.0.1'
  container_name: gitlab
  environment:
    GITLAB_OMNIBUS_CONFIG: |
      external_url 'http://127.0.0.1:8829'
      gitlab_rails['gitlab_shell_ssh_port'] = 2224
      nginx['enable'] = true
      nginx['listen_port'] = 80
      nginx['client_max_body_size'] = '10G'
    GITLAB_TIMEZONE: Asia/Seoul
  ports:
    - '8829:80'
    - '4443:443'
    - '2224:22'
  volumes:
    - '~/Documents/gitlab/config:/etc/gitlab'
    - '~/Documents/gitlab/logs:/var/log/gitlab'
    - '~/Documents/gitlab/data:/var/opt/gitlab'
    - '~/Documents/gitlab/backups:/var/opt/gitlab/backups'

hostname : 설치할 서버의 IP 혹은 호스트명을 입력한다.
ports : 8829 -> 80, 4443 -> 443, 2224 -> 22 로 매핑시켰다. 이유는 혹시 모를 중복되어지는 포트가 있을 수 있기 때문이다. 그리고 해당 서버에서 벌써 22번 포트를 사용하고 있었기에 ssh 포트를 변경하면서 나머지도 변경하였다.
external_url : ‘http://호스트명:포트번호’ 이런식으로 입력한다. 이 주소는 추후 gitlab에서의 clone을 이용할 때 사용되어지는 주소이다. 포트번호를 적지 않으면 gitlab에서 포트번호가 보이지 않게 되어 clone할 때 매번 포트 번호를 적어줘야하는 귀찮은 일이 발생하므로 필히 적어주는 것이 좋을 것이다.
gitlab_rails[‘gitlab_shell_ssh_port’] : 이 값에 새로운 ssh 포트 값을 입력하였다.
nginx[‘listen_port’] : external_url 옵션에 포트번호가 들어가는데 이 옵션이 빠진다면, gitlab 접속이 불가능할 것이다. 그러므로 nginx의 포트를 지정해주었다.
nginx[‘client_max_body_size’] : 만약 큰 용량의 파일을 올릴 수 있다면 용량을 크게 잡는다. 한번에 올릴 수 있는 용량의 크기를 정하는 옵션이다.
volumes : gitlab 서버 컨테이너를 삭제하여도 기존의 쌓였던 데이터들을 고스란히 보관하기 위하여 volumes 옵션을 주었다.
volumes – backups : 이것은 추후 gitlab 서버 데이터의 백업 및 복구를 편하게 하기 위하여 설정한 것이다.

위의 파일을 작성했다면 다음의 명령으로 gitlab 서버 컨테이너를 실행시킨다.

$ docker-compose up -d

참고로 gitlab 서버가 정지되었을 경우 아래의 명령처럼 gitlab 서버 컨테이너를 실행시키면 된다.

$ docker start gitlab

GitLab 이미지 Update

gitlab의 버전을 업데이트할 때는 gitlab 컨테이너를 제거하고, gitlab 도커 이미지를 업데이트 한 후 그 이미지로 컨테이너를 만들면 된다.

// 도커 컨테이너 정지
$ docker container stop gitlab

// 혹은 아래와 같이 docker-compose로 컨테이너를 볼륨과 함께 정지 후 제거
$ docker-compose -f <docker-compose.yml 경로> down -v


// 도커 이미지 제거
$ docker image rm gitlab

// gitlab 최신버전 이미지 가져오기
$ docker image pull gitlab/gitlab-ce:latest

// gitlab 실행
$ docker-compose up -d

하지만 docker-compose.yml 파일을 작성했다면 아래와 같이 간단한 방법으로 update를 할 수 있다.

// docker-compose.yml 파일 위치로 이동 후

// gitlab update
$ docker-compose pull

// gitlab 재실행
$ docker-compose up -d

// 혹은, 컨테이너를 완전하게 삭제 후 실행
$ docker-compose up -d --force-recreate

이메일 발송 설정

이메일을 설정해 놓으면 사용자가 비밀번호를 분실했을 경우, 비밀번호 재설정을 이메일로 받아 볼 수 있다. 이런 설정을 하려면 gitlab 컨테이너에 접속하여 설정 파일을 수정해야 한다.

// gitlab 컨테이너 접속
$ docker container exec -it gitlab /bin/bash

// 설정 파일 수정
$ vim /etc/gitlab/gitlab.rb

아래의 공식 가이드 문서에 가면 본인이 원하는 이메일 설정 방법이 자세히 나와 있으므로 그것을 보고 따라하면 되겠다.

docs.gitlab.com/omnibus/settings/smtp.html

SMTP settings | GitLab

SMTP settings If you would rather send application email via an SMTP server instead of via Sendmail, add the following configuration information to /etc/gitlab/gitlab.rb and run gitlab-ctl reconfigure. cautionYour smtp_password should not contain any Strin

docs.gitlab.com

이메일 설정을 모두 마쳤다면 다음과 같은 명령을 통해 변경된 설정을 적용하자.

// /etc/gitlab/gitlab.rb 파일을 변경한 후에는 항상 다음의 명령을 통해 변경 사항을 적용시켜줘야 한다.

gitlab-ctl reconfigure

GitLab 서버 Backup

/var/opt/gitlab/backups 디렉토리를 공유 디렉토리로 매핑시켰다. 그것은 gitlab 서버 복원을 편하게 하기 위함이다.

백업된 gitlab 데이터 파일을 /var/opt/gitlab/backups 디렉토리 즉, 현재 셋팅해서는 ~/Documents/gitlab/backups 디렉토리에 넣고 아래의 명령을 실행하면 gitlab 데이터가 복원된다.

docker exec -it <name of="" container=""> gitlab-rake gitlab:backup:restore

백업에 관련된 공식 문서는 아래의 링크를 참고하면 된다.

docs.gitlab.com/ee/raketasks/backup_restore.html#restore-for-docker-image-and-gitlab-helm-chart-installations

Back up and restore GitLab | GitLab

Back up and restore GitLab GitLab provides Rake tasks for backing up and restoring GitLab instances. An application data backup creates an archive file that contains the database, all repositories and all attachments. You can only restore a backup to exact

docs.gitlab.com

참고로, 실행중인 gitlab 서버 컨테이너 백업/복구의 명령은 다음과 같다.

// gitlab 서버 데이터 백업 명령어
docker container exec -t <컨테이너 이름> gitlab-backup create

// gitlab 서버 데이터 복구 명령어
docker exec -it <컨테이너 이름> gitlab-backup restore

ORACLE DB dump backup and recovery (export / import)

오라클에서 데이터베이스나 스키마 별로 데이터를 저장, 백업하거나

다시 복구해야할때, DB Dump를 떠논다고 말한다.

Dump는 간단한 명령어로 쉽게 떠지지만,

반드시 Dump를 저장할 디렉토리를 만들어 지정해줘야한다.

1. 오라클시스템상 디렉토리 만들기.

CREATE DIRECTORY datadump AS 'C:\dump';
GRANT READ, WRITE ON DIRECTORY datadump TO SYSTEM;
GRANT CREATE ANY DIRECTORY TO SYSTEM;

SELECT * FROM DBA_DIRECTORIES;

1. C밑에 물리적인 폴더를 생성하고, (dump라는 이름으로 생성했다)

이후 “CREATE DIRECTORY datadump AS ‘C:\dump'”를 수행하여

데이터 베이스 상에 논리적 디렉토리를 지정해준다. (datadump라는 폴더를 만들었다.)

2. 이후 읽고 쓰기 권한을 부여해주어야 한다.

GRANT READ, WRITE ON DIRECTORY datadump TO SYSTEM
;
GRANT CREATE ANY DIRECTORY TO SYSTEM;

3. 확인

SELECT * FROM DBA_DIRECTORIES; 를 수행하면 만들어졌음을 확인할수있다.

로컬이라면, CMD에서 sqlplus 명령어로 dba로 접속하여 진행해도 무방하다.

cmd> sqlplus / as sysdba

2. export / emport 시작

CMD창에서 반출 명령어를 입력한다. (접속 스키마 id/pw , ip:포트, db풀, 만든 directory정보 확인)

-- expdp 반출
--db full
expdp userid=ECUBE2/ECUBE2@//127.0.0.1:1521/OBZMETA dumpfile= OBZMETA.dmp directory=datadump  full=y logfile=fullexp.log

*localhost 경우 @//127.0.0.1:1521/OBZMETA 생략 가능
--schema (ECUBE2, ECUBEEBM2)
expdp userid=ECUBE2/ECUBE2@//127.0.0.1:1521/OBZMETA  dumpfile=ECUBE2.dmp directory=datadump  schemas=ECUBE2 logfile=fullimp.log

expdp userid=ECUBEEBM2/ECUBEEBM2@//127.0.0.1:1521/OBZMETA  dumpfile=ECUBEEBM2.dmp directory=datadump  schemas=ECUBEEBM2 logfile=fullimp.log

--반입
--db full
expdp userid=ECUBE2/ECUBE2@//127.0.0.1:1521/OBZMETA dumpfile= OBZMETA.dmp directory=datadump  full=y logfile=fullexp.log


--schema (ECUBE2, ECUBEEBM2)
impdp userid=ECUBE2/ECUBE2@//127.0.0.1:1521/OBZMETA  dumpfile=ECUBE2.dmp directory=datadump  schemas=ECUBE2 logfile=fullimp.log

impdp userid=ECUBEEBM2/ECUBEEBM2@//127.0.0.1:1521/OBZMETA  dumpfile=ECUBEEBM2.dmp directory=datadump  schemas=ECUBEEBM2 logfile=fullimp.log

Understanding the task scheduler (Schtasks) cmd input method

작업스케줄러(schtasks)를 cmd로 입력하는 방법

Microsoft Docs Windows 2008 server , Windows command help, etc / schtasks

▣ 시간 단위 작업

30분마다 실행되는 작업

schtasks /create /tn “back up” /tr \\data\task01.bat /sc minute /mo 30

참고 : /sc minute인 경우 /mo의 유효값은 1-1439분이다.

매일 오전 9시부터 18시이전까지 60분마다 실행되는 작업

schtasks /create /tn “back up” /tr task01.bat /sc minute /mo 60 /st 09:00 /et 18:00 /k

참고 : /k는 /et 또는 /du 시간이 되면 작업을 중지한다.

/k는 onstart, onlogon, onidle, onevent는 해당되지 않는다.

2018년 6월 1일부터 12시간단위마다 실행되는 작업

schtasks /create /tn check /tr %userprofile%\desktop\schedule.txt /sc hourly /mo 12 /sd 2018/06/01

참고 : /sc hourly인 경우 /mo의 유효값은 1-23시간이다.

/sd : startdate는 yyyy/mm/dd의 한국 날짜 형식이다.

매 시간 50분에 실행되는 작업

schtasks /create /tn “My Schedule” /tr MySchedule.txt /sc hourly /st 00:50

참고 : /hourly에서 /mo가 생략 되면 기본값은 1이다.

명령입력 현재시간이 00:53분이었다면 다음날에 00:50에 명령이 실행된다.

3시간 간격으로 자정부터 10시간 동안 반복 작업

schtasks /create /tn “My Program” /tr “C:\Program\MyProgram.exe” /sc hourly /mo 3 /st 00:00 /du 0010:00

참고 : 오전 12시, 오전 3시, 오전 6시 , 오전9시에 실행된다. 지속시간이 10시간이므로 오후 12시에는

실행되지 않고 다음날 오전 12시에 실행된다.

/k를 사용하여 작업시간 이후에 중지 할 수 있으나 지속시간이 길지 않으면 굳이 중지할 필요가 없다.

▣ 일 단위 작업

매일 오전 9시에 2020년 12월 31일까지 실행되는 작업

schtasks /create /tn “My Program” /tr C:\Program\MyProgram.exe /sc daily /st 09:00 /ed 2020/12/31

참고 : /sc daily인 경우 /mo가 생략되면 기본값은 1이다. /sc daily에서 /mo의 유효값은 1-365일이다.

2018년 6월 1일부터 5일마다 오후 6시에 실행되는 작업

schtasks /create /tn “My Program” /tr C:\Program\MyProgram.exe /sc daily /mo 5 /sd 2018/06/01 /st 18:00

사용자가 로그온 되어 있을때 10일마다 실행되는 대화형 작업

schtasks /create /tn “My Script” /tr MyScript.vbs /sc daily /mo 10 /it

참고 : “다음 사용자계정으로 실행”되는 (RU)계정으로 로그온 되어 있는 있을때만 실행 (/it)

▣ 주 단위 작업

6주마다 실행되는 작업

schtasks /create /tn “My Program” /tr c:\programs\myprogram.exe /sc weekly /mo 6 /s Server03 /u Administrator1

참고 : /sc weekly /mo의 기본값은 1(주)이다. /sc weekly에서 /mo의 유효값은 1-52주이다.

/d day 매개변수가 생략되면 월요일부터 실행

/s 연결할 원격시스템 지정

/u 사용자의 관리자계정 권한을 지닌 Adiministrator1 계정으로 지정

격주마다 월요일에 실행되는 작업

schtasks /create /tn “My prog” /tr c:\prg\myprog.exe /sc weekly /mo 2 /d MON

참고 : /mo 2 격주 간격

/sc weekly /d 매개변수의 유효값은 MON, TUE, WED, THU, FRI, SAT, SUN

▣ 월 단위 작업

매달 1일에 실행되는 작업

schtasks /create /tn “My Prg” /tr myprg.exe /sc monthly

참고 : /sc monthly 에서 /d 매개변수의 유효값은 1-31일이다. /d 매개변수가 생략되면 기본값 1이 적용된다.

/sc monthly에서 /mo 매개변수의 유효값은 1-12 또는 First, Second, Third, Fourth, Last, Lastday이다.

/mo 매개변수가 생략되면 기본값 1이 적용된다.

3개월마다 1번씩 실행되는 작업

schtasks /create /tn “My Prg” /tr c:\prg\myprg.exe /sc monthly /mo 3

참고 : 3월 ,6월, 9월, 12월 에 1번씩 1일에 작업실행

/d 매개변수가 생략되었으므로 기본값 1일이 적용된다.

격월의 25일에 09:00시간에 실행되는 작업

schtasks /create /tn “My Prg” /tr c:\prg\myprg.exe /sc monthly /mo 2 /d 25 /st 09:00 /sd 2018/06/01 /ed 2025/05/31

참고 : /sc monthly에서 /mo 매개변수가 2이므로 격월로 작업실행

/d 25 25일에 작업 실행

/sd는 start date, /ed는 end date를 지정

/et가 생략되면 시작시간과 상관없이 00:00이 기본값이다.

▣ 요일 단위 작업

매주 월요일부터 금요일에 실행되는 작업

schtasks /create /tn “My Prg” /tr c:\prg\myprg.exe /sc weekly /d MON,TUE,WED,THU,FRI

매주 금요일에 실행 되는 작업

schtasks /create /tn “My Prg” /tr c:\prg\myprg.exe /sc weekly /d FRI

참고 : /se weekly에서 /mo는 작업을 실행할 간격(주)이며 생략되면 기본값 1이므로 매주 작업 실행

/d *(와일드카드) 는 일일작업실행의 의미와 같다.

4주마다 월요일과 금요일에 실행되는 작업

schtasks /create /tn “My Prg” /tr c:\prg\myprg.exe /sc weekly /mo 4 /d MON,FRI

▣ 한달 중 특정 주 단위 작업

매월 셋째주 월요일에 실행되는 작업

schtasks /create /tn “My Prg” /tr c:\prg\myprg.exe /sc monthly /mo Third /d MON

참고 : /sc monthly에서 /mo 매개변수를 1~12 또는 First, Second, Third, Fourth를 선택할 수 있다.

예를 들어 /mo 2 이면 격월이란 의미로 2,4,6,8,10,12월에 해당되고 /d 매개변수는 1~31일까지

지정이 가능하다.

반면에 /mo SECOND로 지정하면 둘째주라는 의미이며 /d 매개변수는 MON, TUE, WED, THU,

FRI, SAT, SUN로 지정이 가능하다.

/sc /monthly /mo last /d sat : 매월 마지막 토요일

– /mo last 에는 /d 매개변수가 반드시 필요하며 /d 매개변수에는 1~31이 아닌 MON, TUE, WED,

THU, FRI, SAT, SUN로 지정해야 한다.

/sc /monthly /mo lastday /m Jan, Feb 1월 2월 마지막 일

– /mo lastday에는 /m 매개변수가 반드시 필요하며 유효값에는 JAN, FEB, MAR, APR, MAY,

JUN, JUL, AUG, SEP, OCT, NOV, DEC. 와일드카드 “*”가 있다.

1월과 7월의 첫번째 월요일에 실행되는 작업

schtasks /create /tn “My Prg” /tr c:\prg\myprg.exe /sc monthly /mo FIRST /d MON /m JAN,JUL

참고 : /sc monthly에서 /m이 생략되면 매월 실행

▣ 특정 일 단위 작업

매월 1일에 실행되는 작업

schtasks /create /tn “My Prg” /tr c:\prg\myprg.exe /sc monthly

참고 : /sc monthly에서 /m이 없으면 매월 실행, /d가 없으면 기본값은 1이다.

6월 1일과 7월 1일 오후 6시에 실행되는 작업

schtasks /create /tn “My Prg” /tr c:\prg\myprg.exe /sc monthly /d 1 /m JUN,JUL /st 18:00

매월 말일에 실행되는 작업

schtasks /create /tn “My Prg” /tr c:\prg\myprg.exe /sc monthly /mo lastday /m *

참고 : /sc monthly /mo lastday에서는 반드시 /m 매개변수가 필요하다.

5,6,7월의 마지막 일 18:00에 실행되는 작업

schtasks /create /tn “My Prg” /tr c:\prg\myprg.exe /sc monthly /mo lastday /m MAY,JUN, JUL /st 18:00

▣ 한번만 필요한 작업

한번 실행되는 작업

schtasks /create /tn “My Prg” /tr c:\prg\myprg.exe /sc once /sd 2018/06/01 /st 00:00

참고 : 한번만 실행되는 작업의 /sc 매개변수는 once이다.

/sd 매개변수는 선택사항이며 /st 매개변수는 필수사항이다.

▣ 시스템이 시작될 때 작업

시스템이 시작 될때 실행되는 작업

schtasks /create /tn “My Prg” /tr c:\prg\myprg.exe /sc onstart /sd 2018/05/13

참고 : 시스템이 시작할 때 실행되는 작업의 /sc 매개변수는 onstart이다.

/sd 매개변수는 선택사항이며 기본값은 현재 날짜이다.

▣ 로그온 할 때 작업

로그온 할 때 실행 되는 작업

schtasks /create /tn “Virus Check3” /tr “cmd /k cd \”c:\Program Files\Windows Defender\” & MpCmdRun.exe -Scan -scantype 2″ /sc onlogon

참고 : 로그온 할 때 실행되는 작업의 /sc 매개변수는 onlogon이다.

/sd 매개변수는 선택사항이며 기본값은 현재 날짜이다.

/s 매개변수는 연결할 원격시스템이며 생략되면 로컬시스템이 기본값이다.

▣ 시스템이 유휴상태일 때 작업

시스템이 유휴상태일 때 실행되는 작업

schtasks /create /tn “My Prg” /tr c:\prg\myprg.exe /sc onidle /i 10

참고 : 시스템이 유휴상태(사용자 사용이 없는 상태)

/i 매개변수는 유휴상태 대기 시간을 설정하며 유효값은 1~999분이다.

위 구문은 사용자입력이 10분동안 없으면 작업이 실행된다.

▣ 시스템 이벤트가 게시될 때 작업

특정 이벤트가 채널에 게시될때 마다 실행되는 작업

schtasks /create /tn “Event Check” /tr “Msg Admin01 계정이 변경되었습니다.” /sc onevent /ec Security /MO “*[System[Provider[@Name=’Microsoft-Windows-Security-Auditing’] and EventID=4738]]”

참고 : /sc onevent 에서 /ec는 event channel이며 유효값은 Application, Security, Setup, System 이다.

이벤트 쿼리 스트링에서는 반드시 대문자, 소문자 구별을 해야 한다.

이벤트 쿼리 스트링부분은 다음과 같이 간략하게 줄일 수 있다.

/MO *[System/EventID=4738]

▣ 지금 작업

지금부터 몇분 후에 한번 실행되는 작업

schtasks /create /tn “My Prg” /tr c:\prg\myprg.exe /sc once /st 14:18 /sd 2018/05/13

참고 : 지금실행이라는 옵션은 없지만 현재시간으로부터 몇분 후에 한번 실행되는 작업을 만들 수 있다.

/st 매개변수는 필수사항이고 /sd 매개변수는 선택사항이다.

▣ 다른 권한으로 작업

로컬시스템에서 관리자권한으로 실행되는 작업

schtasks /create /tn “My Prg” /tr myprg.exe /sc weekly /d FRI /ru Admin01

참고 : 관리자권한(Admin01)으로 실행되는 작업을 만드려면 /ru 매개변수가 필요하다.

만약 명령을 입력하는 현재의 계정이 표준계정이라면 암호를 입력하는 메시지가 표시되며

암호를 입력해야만 한다.

이러한 암호는 /rp 매개변수로 처음부터 입력할 수 있으며 선택사항이다.

입력하는 계정이 관리자 계정에서는 암호가 필요하지 않다.

원격 시스템에서 다른 권한으로 3일마다 실행되는 작업

schtasks /create /tn “My Prg” /tr myprg.exe /sc daily /mo 3 /s office04 /u office04\Admin01 /ru Domain01\UserAcnt03

Type the password for office04\Admin01:********

Please enter the run as password for Domain01\UserAcnt03: ********

SUCCESS: The scheduled task “My Prg” has successfully been created.

참고 : /s 매개변수는 원격시스템이며

/u 매개변수는 원격시스템에서 작업권한이 있는 계정을 지정 – 작업예약 계정

/ru 작업을 실행할 때 사용되는 계정 지정 – 작업실행 계정

/ru 매개변수가 생략되면 /u 매개변수의 계정으로 실행

특정 사용자가 로그온 되어 있는 경우에만 매주 월요일 오후 5시에 실행되는 작업

schtasks /create /tn “My Prg” /tr myprg.exe /sc weekly /d MON /st 17:00 /s System10 /u Domain3\Admin03 /ru System10\Admin01 /it

참고 : System10\Admin01계정이 로그온되어 있는 경우에만 매주 금요일 오전 4시에 작업을 실행.

/it 매개변수는 System10\Admin01계정이 로그온되어 있는 경우에만 작업이 실행되는 옵션이다.

interactive전용(/it)속성이 있는 작업을 식별하려면 상세 쿼리(/Query/v)를 사용. /it 옵션이 포함된

작업의 상세 조회 표시에서 로그온 모드 필드의 값은 대화형만 가진다.

schtasks /query /v

시스템 권한으로 매월 7일에 실행되는 작업

schtasks /create /tn “My Prg” /tr c:\prg\myprg.exe /sc monthly /d 7 /ru System

참고 : /ru System(또는/ru “”)매개 변수(시스템보안 컨텍스트)가 필요하며 /rp 매개 변수가 유효하지 않는다.

/ru시스템 작업에서 암호를 사용하지 않으므로 /rp 매개 변수를 생략한다.

시스템 계정에 대화형 로그온 권한이 없으므로 사용자는 시스템 사용 권한으로 실행되는 프로그램

또는 작업을 보거나 상호 작용할 수 없다.

/ru 매개 변수는 작업을 예약하는 데 사용되는 권한이 아니라 작업이 실행되는 사용 권한을 결정.

/ru 매개 변수 값에 관계 없이 관리자(administrator)만 작업을 예약할 수 있다.

시스템 권한으로 실행되는 작업을 식별하려면 세부 쿼리(/query/v)를 사용.

시스템 실행 작업의 상세 조회 표시에서 “다음 계정으로 실행” 필드의 값은

NTAUTHORITY\SYSTEM이고 로그온 모드 필드의 값은 백그라운드 값이다.

원격 컴퓨터에서 시스템권한으로 매일 아침 8시에 실행되는 작업

schtasks /create /tn “My Prg” /tr myprg.exe /sc daily /st 08:00 /s computer01 /u Admin01 /ru System

참고 : /tr 매개 변수를 사용하여 myprg프로그램의 원격 복사본을 지정.

/sc 매개 변수를 사용하여 일일 작업을 지정하고 /mo 매개 변수를 생략하여 기본 값이 1(매일)으로

구성한다.

/u 매개 변수를 사용하여 원격 시스템에서 작업을 예약할 수 있는 권한이 있는 계정을 지정.

/ru 매개 변수를 사용하여 시스템 계정에서 작업을 실행하도록 지정.

/ru 매개 변수가 없으면 /u 에서 지정한 계정 권한으로 작업이 실행된다.

2개 이상의 프로그램이 실행되는 작업

schtasks /create /tn “security check” /tr c:\secuchk.bat /sc onlogon /ru Domain3\Admin01

참고 : 기본적으로 /tr 에서는 하나의 프로그램만 실행된다.

2개 이상의 프로그램을 실행하는 작업을 하려면 메모장에 프로그램을 나열하고 배치파일

(secuchk.bat)로 저장

예 : c:\Windows\System32\wf.msc

c:\Windows\Sytem32\secpol.msc

로그온 할때마다 관리자계정 권한으로 방화벽과 로컬보안정책이 동시에 실행된다.

원격 시스템에서 15일마다 실행되는 작업

schtasks /create /tn “My Prg” /tr “c:\program files\programs\myprg.exe” /sc daily /mo 15 /s server01

참고 : 로컬 현재 사용자는 원격 시스템의 관리자이므로 작업 예약에 대한 대체 권한을 제공하는

/u 매개 변수는 필요하지 않는다.

원격 컴퓨터에서 작업을 예약할 때는 모든 매개 변수가 원격 컴퓨터를 참조한다. /tr r매개 변수로

지정된 실행 파일은 원격 시스템에 있는 실행파일의 복사본을 참조한다.

참고 : 원격 시스템에서 실행되도록 작업을 예약하려면 다음 조건을 충족해야 한다.

◈ 작업을 예약할 수 있는 권한이 있어야 한다. 따라서 원격 시스템의 관리자 그룹에 속한 계정으로

로컬 시스템에서 로그온 하거나 원격 시스템의 관리자 자격 증명을 제공하려면 /u 매개 변수를

사용해야 한다.

◈ 로컬 및 원격 컴퓨터가 동일한 도메인에 있거나 원격 컴퓨터 도메인이 신뢰하는 도메인에

있는 경우에만 /u 매개 변수를 사용할 수 있다. 그렇지 않으면 원격 시스템이 지정된 사용자 계정을

인증할 수 없고 해당 계정이 관리자 그룹의 구성원인지 확인할 수 없다.

◈ 원격 컴퓨터에서 실행할 수 있는 충분한 권한이 있어야 한다. 기본적으로 작업은 로컬 컴퓨터의

현재 사용자 권한으로 실행되거나 /u 매개 변수를 사용하는 경우 /u 매개 변수로 지정된 계정의

사용 권한으로 실행된다. 그러나 /ru 매개 변수를 사용하여 다른 사용자 계정이나 시스템 사용

권한으로 작업을 실행할 수도 있다.

사용자가 원격 컴퓨터에서 3시간 마다 명령을 예약하는 경우

schtasks /create /tn “My Prg” /tr “c:\program files\programs\myprg.exe” /sc hourly /mo 3 /s server01 /u Domain1\admin01 /p N28$sp4X /ru server01\user04 /rp MyPw!9aD

참고 : 작업을 예약하려면 관리자 권한이 필요하므로 명령은 /u및 /p매개 변수를 사용하여 사용자의 관리자 계정 (Reskits도메인의 관리자 11)의 자격 증명을 제공한다. 기본적으로 이러한 권한은 작업를 실행하는 데도 사용된다.

그러나 작업을 실행하는 데 관리자 권한이 필요하지 않으므로 명령에는 /u및 /rp매개 변수가 포함되어 기본 값을 재정의하고 원격 시스템에서 사용자의 비 관리자 계정 권한으로 작업을 실행한다.

사용자가 원격 컴퓨터에서 매월 마지막 일에 명령을 예약하는 경우

schtasks /create /tn “My Prg” /tr “c:\program files\programs\myprg.exe” /sc monthly /mo LASTDAY /m * /s server2 /u business1\admin01

참고 : 로컬 현재 사용자(user01)는 원격 시스템의 관리자가 아니므로 명령은 /u 매개 변수를

사용하여 사용자의 관리자 계정(business도메인의 관리자 11)의 자격 증명을 제공하여 작업을 예약한다.

관리자 계정 권한은 작업을 예약하고 작업을 실행하는데 사용된다.

명령에 /p (비밀 번호)매개 변수가 포함되어 있지 않기 때문에 schtasks는 비밀 번호를 묻는 메시지를 표시한다.

그런 다음 성공 메시지와 경고를 표시한다.

다른 도메인 내 iframe의 세션이 유지가 안될때 ( Same Site )

문 제

A.com 내에 내가만든 B.com/B.jsp 을 iframe 으로 걸었다.

내가 만든 B.com/B.jsp 내의 세션값을 뽑아도 계속 null인 상황이다.

줄곧 크롬으로 테스트 했던터라 IE로 하니까 또 잘된다.

확인한 부분을 정리하면 이렇다.

1. 크롬 개발자 도구로 Response Headers 를 확인 보았다.

2. Set-Cookie 값안에 JSESSIONID 값이 만들어 지는데, 이값이 호출때마다 변경 된다.

자세히 보면 오른쪽에 노란색 느낌표가 떠있고, 마우스를 가져가면, SameSite 관련 부연설명이 나온다.

웹 search를 해보면 SameSite관련 이슈로 A.com -> B.com POST 방식으로

리다이렉트 했을때 기존에 읽어지던 쿠키값을 읽을수 없는케이스가 제일 많은듯 했다.

3. iframe을 걸어놓은 B.com/B.jsp 에서는 session.getAttribute를 통해서 값이 꺼내지지만,

java servlet 레벨에서 아래와 같이 뽑아도 null 값만 나오게 된다.

request.getSession().getAttribute("String");

원인 – Chrome 80 쿠키 SameSite 정책이 변경 되었다.

– 도메인이 서로 다른 사이트 간 이동을 하는 경우 쿠키 전달 불가

– 기본 SameSite를 Lax로 변경

( 2020년 2월4일 크롬 80버전 부터 변경 !! )

SamteSite 쿠키에 대해

SameSite 쿠키의 정책으로 None, Lax, Strict 세 가지 종류를 선택할 수 있고

동작하는 방식이 다르다고 할수 있다.

None:

– SameSite 가 탄생하기 전 쿠키와 동작하는 방식

– None으로 설정된 쿠키의 경우 크로스 사이트 요청의 경우에도 항상 전송

– SameSite를 None으로 설정할 경우 쿠키에 암호화된 HTTPS 연결이 필요함을 나타내는

Secure 속성을 같이 설정해주어야 한다.
– HTTPS 일때만 사용 가능.

Lax:

Strict에 비해 상대적으로 느슨한 정책입니다. Lax로 설정된 경우, 대체로 서드 파티 쿠키는 전송되지 않지만, 몇 가지 예외적인 요청에는 전송 된다.

Strict:

– 가장 보수적인 정책.

– Strict로 설정된 쿠키는 크로스 사이트 요청에는 항상 전송않음.

– 즉, 서드 파티 쿠키는 전송되지 않고, 퍼스트 파티 쿠키만 전송 된다

해 결

결론은 크롬의 쿠키 보안정책이 바뀌어서,

기본이 SameSite의 레벨이 NONE에서 LAX 올라갔으니, 다시 NONE으로 내려주면 된다는 것이다.

중요한점은 HTTPS 일때 사용가능하다.

SameSite 설정시에 None 옵션과 Secure를 함께 주도록되어있는데,

이때 Https일때만 사용이 가능하다고 한다.

즉 B.com 의 도메인은 https 호출이 가능해야 한다.

A.com 의 설정을 건드릴 필요없이 iframe이 걸리는 B.com 쪽에 서버 설정을 수정해야 했다.

나는 앞단에 Apache 서버가 있고, WAS 가 따로 있는 상황이었다.

이럴경우는 apache 웹서버에서 설정을 해줄수 있다.

Apache_HOME / conf / httpd.conf

<IfModule headers_module>
        Header edit Set-Cookie ^(.*)$ $1;SameSite=None;Secure;
</IfModule>

값을 넣어주고 apache 재기동을 했다.

다음부터는 호출시 B.com/b.jsp에서도 세션값에서 정상적으로 값이 꺼내지고

Set-Cookie 값안에 JSESSIONID 값 자체가 유지되는 것을 확인 할수 있었다.

구글 공지

https://blog.chromium.org/2019/10/developers-get-ready-for-new.html

참고자료

https://web.dev/samesite-cookies-explained/

https://chromestatus.com/feature/5088147346030592

http://www.gnujava.com/board/article_view.jsp?board_no=37&article_no=8583

https://velog.io/@jsj3282/%EA%B5%AC%EA%B8%80-Chrome-SameSite-%EC%9D%B4%EC%8A%88

[Kubernetes] Understanding how the Calico CNI works

[Kubernetes] Calico CNI 동작원리 이해하기

Calico란, 컨테이너, 가상 머신 및 기본 호스트 기반 워크로드를 위한 오픈 소스 네트워킹 및 네트워크 보안 솔루션이다.
Kubernetes, OpenShift, Mirantis Kubernetes Engine(MKE), OpenStack 및 베어메탈 서비스를 포함한 광범위한 플랫폼 지원한다.
Calico의 eBPF 데이터 플레인을 사용하든 Linux의 표준 네트워킹 파이프라인을 사용하든 Calico는 진정한 클라우드 네이티브 확장성과 함께 놀랍도록 빠른 성능을 제공한다.
Calico는 공용 클라우드나 온프레미스, 단일 노드 또는 수천 개의 노드 클러스터에서 실행되는지 여부에 관계없이 개발자와 클러스터 운영자에게 일관된 경험과 기능 세트를 제공한다.

구성 요소 아키텍처(링크)

- BGP(Border Gateway Protocol): AS 사이에서 이용되는 라우팅 프로토콜. 대규모 네트워크(수천만의 경로 수)에 대응하도록 설계됐다. 그래서 BGP로 동작하는 라우터는 비교적 고가인 제품이 많다.
- AS(Autonomous System): 하나의 정책을 바탕으로 관리되는 네트워크(자율 시스템)를 말한다. ISP, 엔터프라이즈 기업, 공공기관 같은 조직이 이에 해당하며 인터넷은 이러한 자율 시스템의 집합체이다.여러가지 구성 요소가 많지만, 일단 눈여겨 볼 내용은 Calico가 사용하는 Datastore[1]와 마스터 노드를 포함한 모든 노드들에 존재하는 Calico Pods[2]
  - Felix (필릭스) : 인터페이스 관리, 라우팅 정보 관리, ACL 관리, 상태 체크
  - BIRD (버드): BGP Peer 에 라우팅 정보 전파 및 수신, BGP RR(Route Reflector)
  - Confd : calico global 설정과 BGP 설정 변경 시(트리거) BIRD 에 적용해줌
  - Datastore plugin : calico 설정 정보를 저장하는 곳 – k8s API datastore(kdd) 혹은 etcd 중 선택
  - Calico IPAM plugin : 클러스터 내에서 파드에 할당할 IP 대역
  - calico-kube-controllers : calico 동작 관련 감시(watch)
  - calicoctl : calico 오브젝트를 CRUD 할 수 있다, 즉 datastore 접근 가능

구성 요소 확인하기

데몬셋으로 각 노드에 calico-node 파드가 동작하여, 해당 파드에 bird, felix, confd 등이 동작 + Calico 컨트롤러 파드는 디플로이먼트로 생성
- Calico의 특징은 BGP를 이용해 각 노드에 할당된 Pod 대역의 정보를 전달한다. 즉, 쿠버네티스 서버뿐만 아니라 물리적인 라우터와도 연동이 가능 하다는 뜻이다. (Flannel의 경우 해당 구성 불가)
- Calico Pod 안에서 Bird라고 하는 오픈소스 라우팅 데몬 프로그램이 프로세스로 동작하여 각 Node의 Pod 정보가 전파되는 것이다.
- 이후 Felix라는 컴포넌트가 리눅스 라우터의 라우팅 테이블 및 iptables rule에 전달 받은 정보를 주입하는 형태이다.
- confd는 변경되는 값을 계속 반영할 수 있도록 트리거 하는 역할이다.

Calico 기본 통신 과정 확인하기

calicoctl 설치

리소스 관리를 위해 Calico CLI를 설치 및 구성

마스터 노드 확인

Calico CNI 설치시, 데몬셋이므로 모든 노드에 칼리코 파드가 하나씩 존재하게 된다. (calico-node-*)
칼리코 컨트롤러가 하나 존재하는 것을 확인할 수 있다.
calicoctl ipm show 명령어를 통해, IAPM 정보를 확인할 수 있다. 아래 스크린샷에서는 172.16.0.0/16 대역을 해당 쿠버네티스 클러스터에서 사용할 수 있다는 내용을 알 수 있다.
- IPAM(IP Address Management): 풍부한 사용자 환경을 통해 IP 주소 인프라의 엔드 투 엔드 계획, 배포, 관리 및 모니터링을 지원하는 통합 도구 모음이다.
  IPAM은 네트워크상의 IP 주소 인프라 서버 및 DNS(도메인 이름 시스템) 서버를 자동으로 검색하여 중앙 인터페이스에서 이들 서버를 관리할 수 있다.
- 옵션을 통해 아래와 같이 특정한 노드에 할당 가능한 대역대를 확인할 수도 있음(Block는 각 노드에 할당된 Pod CIDR 정보를 나타냄)
calicoctl node 정보 확인
ippool 정보 확인
파드와 서비스 사용 네트워크 대역 정보 확인

실습 1.

동일 노드 내 파드 간 통신

결론: 동일 노드 내의 파드 간 통신은 내부에서 직접 통신됨

파드 생성 전 노드(k8s-w1)의 기본 상태

노드(k8s-w1)에 파드 2개 생성

아래 내용으로 node1-pod2.yaml 파일 작성 후 파드 생성
파드 생성 전후의 변화를 관찰하기 위해 터미널 하단 추가 탭에watch calicoctl get workloadEndpoint 명령어를 사용하여 모니터링
- calicoctl 명령어로 endpoint 확인: veth 정보도 확인할 수 있음

생성된 파드 정보 확인

네트워크 인터페이스 정보 확인(k8s-w1)

calice#~ 두개 추가된 것을 확인할 수 있음
각각 net ns 0,1로 호스트와 구별되는 것을 확인할 수 있음

네트워크 네임스페이스 확인

아래 2개 PAUSE 컨테이너가 각각 파드별로 생성된 것을 확인할 수 있음
바로 위 스크린샷인 link-netnsid 0, link-netnsid 1과 매칭됨

라우팅 테이블 확인

파드의 IP/32bit 호스트 라우팅 대역이 라우팅 테이블에 추가된 것을 확인할 수 있음

파드간 통신 실행 이해

(위) 마스터 노드에서 Pod1 Shell에 접근하여 Pod2로 Ping 테스트
(아래) 워커 노드(k8s-w1)에서 iptables 필터 테이블에 FORWARD 리스트 중 cali-FORWARD 룰 정보를 필터링해서 watch로 확인
테스트 결과 아래 이미지와 같이 Host iptables에서 FOWRARD라는 테이블의 허용 조건에 따라 정상적으로 통신이 가능한 것을 확인할 수 있다.

파드에서 외부(인터넷)로의 통신

결론: 파드에서 외부(인터넷) 통신 시에는 해당 노드의 네트워크 인터페이스 IP 주소로 MASQUERADE(출발지 IP가 변경) 되어서 외부에 연결됨

파드 배포 전 calico 설정 정보 확인 & 노드에 iptables 확인

마스터 노드에서 아래 내용 확인: natOutgoing의 기본값이 true로 설정되어 있는 것을 확인 할 수 있다. 즉 이 노드에서 외부로 통신할 때 NAT의 MASQUERADE를 사용하겠다는 의미이다.

NAT – MASQUERADE : 조건에 일치하는 패킷의 출발지 주소를 변환하는 것. 내부에서 전달되는 요청의 출발지 주소를 조건에 지정된 인터페이스의 IP로 변환한다.
워커 노드(k8s-w1)에서도 외부로 통신시 MASQUERADE 동작 Rule이 존재하는 것을 확인할 수 있다.

마스터 노드에서 워커 노드(k8s-w1)에 아래 내용의 파드 1개 생성

외부 통신 가능 여부 확인

통신 전, 워커 노드(k8s-w1)에 iptables NAT MASQUERADE 모니터링을 활성화 하면 외부 통신시 pkts값이 증가하는지 확인할 수 있다.
(위) 마스터 노드에서 Pod1 Shell 실행 후, 8.8.8.8로의 통신 성공
(아래) pkts 값이 이전 이미지와 다르게 증가한 것을 확인할 수 있다.

다른 노드에서 파드 간 통신

결론: 다른 노드 환경에서 파드 간 통신시에는 IPIP터널(기본값) 모드를 통해서 이루어진다.
- 각 노드에 파드 네트워크 대역은 Bird에 의해서 BGP로 광고 전파/전달 되며, Felix에 의해서 호스트의 라우팅 테이블에 자동으로 추가/삭제 된다.
- 다른 노드 간의 파드 통신은 tunl0 인터페이스를 통해 IP 헤더에 감싸져서 상대측 노드로 도달 후 tunl0 인터페이스에서 Outer 헤더를 제거하고 내부 파드와 통신한다.

파드 배포 전, 노드에서 BGP에 의해 전달 받은 정보가 호스트 라우팅 테이블에 존재하는지 확인

아래 명령어를 통해 나머지 노드들의 파드 대역을 자신의 호스트 라우팅 테이블에 가지고 있고, 해당 경로는 tunl0 인터페이스로 보내게 된다는 사실을 알 수 있다.

워커 노드(k8s-w1, w2)의 tunl0 정보 확인

터널 인터페이스가 IP에 할당되어 있음
MTU는 1480 (칼리코 사용 시 파드의 인터페이스도 기본 MTU 1480 사용)
현재 TX/RX 카운트는 0 –> 잠시 후, 오버레이 통신시 카운트 값이 증가할 것

마스터 노드에서 워커 노드(k8s-w1, w2) 대상으로 각각 파드 1개씩 생성

calicoctl 명령어를 이용하여 생성된 파드의 엔드포인트 확인

각 노드에서 파드 간 통신을 처리하는 라우팅 정보 확인

k8s-w1(172.16.158.4/32) 노드에서 w2(172.16.184.0) 노드 대역에 통신하려면 192.168.10.102를 거쳐야 한다는 것을 확인할 수 있다.
반대로 w2(172.16.184.1/32) 노드에서 w1(172.16.158.0) 노드 대역에 통신하려면 192.168.10.101를 거쳐야 한다.

다른 노드 파드 간 통신이 어떻게 실행되는지 확인 ⇒ IPIP

(상) Pod2가 속한 노드(k8s-w2)에 tunl0 인터페이스 TX/RX 패킷 카운트 모니터링 세팅
(중) 마스터 노드에서 Pod1 Shell 접속 후, Pod2로 Ping 통신 테스트 준비
(하) Pod1이 속한 노드(k8s-w1)에서 패킷 덤프 세팅: tunl0 – 터널 인터페이스에 파드간 IP 패킷 정보를 확인할 수 있음
결과
- (중) Pod1 –> Pod2로 정상 통신 확인
- (상) tunl0 인터페이스의 TX/RX 패킷 카운트가 각각 10개로 증가
- (하) 실제 통신을 하게 되는 파드 간 IP 패킷 정보 확인
실제로 오버레이 통신을 하고 있는지 확인하기 위해 패킷덤프 명령어를 아래와 같이 수정하여 Ping 통신을 다시 하였고, 결과적으로 IP Outer(파란색 박스) 헤더 정보 안쪽에 Inner(빨간색 박스) 헤더가 1개 더 있음을 확인할 수 있다.

Calico 네트워크 모드

Calico Mode 요약

칼리코는 다양한 네트워크 통신 방법을 제공한다.

IPIP 모드

파드 간 통신이 노드와 노드 구간에서는 IPIP 인캡슐레이션을 통해 이루어진다.
단, Azure 네트워크에서는 IPIP 통신이 불가능하기 때문에 대신 VXLAN 모드를 사용한다고 한다.

Direct 모드

파드 통신 패킷이 출발지 노드의 라우팅 정보를 보고 목적지 노드로 원본 패킷 그대로 전달된다.
단, 클라우드 사업자 네트워크 사용 시, NIC에 매칭되지 않는 IP 패킷은 차단되니 NIC의 Source/Destination Check 기능을 Disable해야 정상 통신 가능 (AWS 문서 링크)

BGP 연동

Kubernetes 클러스터 내부 네트워크와 IDC 내부망 네트워크 간 직접 라우팅도 가능

VXLAN 모드

파드 간 통신이 노드와 노드 구간에서는 VXLAN 인캡슐레이션을 통해서 이루어진다.
다른 노드 간의 파드 통신은 vxlan 인터페이스를 통해 L2 프레임이 UDP – VXLAN에 감싸져 상대 노드로 도달 후 vxlan 인터페이스에서 Outer헤더를 제거하고 내부의 파드와 통신하게 된다.
BGP 미사용, VXLAN L3 라우팅을 통해서 동작한다.
UDP를 사용하므로 Azure 네트워크에서도 사용 가능하다.

Pod 패킷 암호화(네트워크 레벨)

Calico의 다양한 네트워크 모드 환경 위에서 WireGuard 터널을 자동 생성 및 파드 트래픽을 암호화하여 노드 간 전달한다.
Yaml 파일에 간단하게 추가하는 것만으로도 네트워크 레벨의 패킷 암호화를 설정할 수 있다.

WireGuard는 구닥다리 IPsec 및 OpenVPN의 대항마로 등장한 open source VPN project이며 작년, Linux 5.6 커널에 WireGuard 1.0.0 기본 패키지로 탑재되었다.

정말 간결한 코드 구조와 빠른 성능 (모든 것이 kernel에서 동작하고, 주요 암호 알고리즘에 대해서 병렬처리하므로써 빠른 속도를 자랑함)

실습 2. WireGuard

WireGuard 설정

모든 노드에 WireGuard를 설치(apt install wireguard -y)하고, Enabled 설정
현재 노드에 존재하는 Wireguard 퍼블릭 키 확인
wireguard.cali 인터페이스 정보 확인
wg로 시작하는 명령어를 사용하여 wireguard.cali 설정 확인: 노드 별로 각각의 상대방 Peer의 IP와 퍼블릭 키를 확인할 수 있음

동작 확인

아래 내용으로 파드 생성
(상) 파드가 생성된 노드의 eth0(enp0s8)에서 패킷 덤프 모니터링 세팅
(하) 생성한 파드 Shell 접속 후 Ping 통신 준비
(하) Pod2 IP 확인
(중) Pod1 –> Pod2 Ping 정상 통신
(상) 51820 포트 패킷 덤프 내용 확인