AWS는 re:Invent 때 항상 깜짝 놀랄만한 서비스를 출시합니다.

아무도 예상 못해선... 설마했던... 그것을 아마존이 또 출시했네요.. 바로 VM이 아닌 물리서버인 베어메탈 서비스 입니다.

사실 VMware on AWS를 출시할 때 부터 가능성이 점쳐졌던 거긴 한데요...

설마 진짜 베어메탈 서비스를 출시 할지 몰랐네요. 사용자 입장에서의 사용성은 베어메탈도 VM과 동일 합니다.

서버의 순수한 성능을 다 확보 할수 있고, 라이센스 정책에서 좀 더 자유로울 수 있겠네요.

Softlayer(IBM Cloud)가 거의 베어메탈의 표준 처럼 잡고 있는 클라우드였는데요.... 이제 긴장해야겠습니다. 

아직 AWS가 프리뷰이긴하지만 언제 훅 치고 들어올지 모르니까요.

출처: https://aws.amazon.com/ko/blogs/aws/new-amazon-ec2-bare-metal-instances-with-direct-access-to-hardware/

Amazon EC2 Bare Metal Instances with Direct Access to Hardware

Polly 가 드디어 한국어를 합니다. 기계합성어 답지않게 정말 자연스럽습니다. 이제 음성합성은 구글보다 Polly를 이용할것 같습니다.

더 자연스럽고, 더 쉽게 쓸 수 있습니다. 아래 링크로 한번 들어 보시죠.

음성 파일

출처: https://aws.amazon.com/ko/blogs/korea/now-available-amazon-polly-in-seoul-region-and-korean-woman-voice-seoyeon

Amazon Polly 서울 리전 출시 및 한국어 여성 ‘서연(Seoyeon)’ 음성 공개

from boto3 import client
polly = client("polly", region_name="ap-northeast-2")
response = polly.synthesize_speech(
        Text="안녕하세요. 제 이름은 서연이에요! 저는 새내기 아마존 폴리 음성 비서입니다. 텍스트를 입력하시면 읽어드릴께요.",
        OutputFormat="mp3",
        VoiceId="Seoyeon")

<speak>
   오늘의 <prosody rate="x-slow">날씨를 전해 드리겠습니다</prosody>. 
   현재, 전국이 구름이 많은 가운데 일부 중부 지역과 전북에는 <prosody volume="x-loud">눈이 날리거나</prosody><break time="1s"/> <prosody pitch="x-high">빗방울이 떨어지는 곳이 있습니다.
   </prosody>. 서울의 경우 북부 지역을 중심으로 <amazon:effect name="whispered"><prosody rate="-10%">눈이 날리고 있으나,</prosody></amazon:effect> 공식적인 첫눈으로 기록되지는 않습니다.
</speak>

OpsWorks 가 원래 Chef 기반이죠.. 그런데 이제 Puppet도 지원하네요. (이제 Ansible만 하면 되겠습니다;;;)

Puppet에 익숙한 사용자들이 더욱 접근 하기 좋아졌네요...

출처: https://aws.amazon.com/ko/blogs/korea/new-aws-opsworks-for-puppet-enterprise/

AWS OpsWorks for Puppet Enterprise 지원

Amazon Redshift Spectrum은 Athena만큼 기대되는 제품이 였는데 드디어 서울리전에도 사용이 가능해졌습니다.

Athena가 EMR을 공유인프라를 활용한 SaaS 형으로 제공서비스라면

Redshift Spectrum은 이름처럼 Redshift를 공유인프라를 통해 SaaS형으로 제공하는 서비스입니다. 구글 빅쿼리랑 대응 되겠네요.

둘다 S3 데이터를 직접 다룰 수 있습니다. 

세부 내용은 아래 AWS 블로그 내용 참고 하시 면 되겠습니다.

출처: https://aws.amazon.com/ko/blogs/korea/10-best-practices-for-amazon-redshift-spectrum/

Amazon Redshift Spectrum에 대한 10가지 모범 사례

create external schema spectrum 
from data catalog 
database 'spectrumdb' 
iam_role 'arn:aws:iam::<AWS_ACCOUNT_ID>:role/aod-redshift-role'
create external database if not exists;

CREATE  external table spectrum.LINEITEM_PART_PARQ ( 
 L_ORDERKEY BIGINT,
 L_PARTKEY BIGINT,
 L_SUPPKEY BIGINT,
 L_LINENUMBER INT,
 L_QUANTITY DECIMAL(12,2),
 L_EXTENDEDPRICE DECIMAL(12,2),
 L_DISCOUNT DECIMAL(12,2),
 L_TAX DECIMAL(12,2),
 L_RETURNFLAG VARCHAR(128),
 L_LINESTATUS VARCHAR(128),
 L_COMMITDATE VARCHAR(128),
 L_RECEIPTDATE VARCHAR(128),
 L_SHIPINSTRUCT VARCHAR(128),
 L_SHIPMODE VARCHAR(128),
 L_COMMENT VARCHAR(128))
partitioned by (L_SHIPDATE VARCHAR(128))
stored as PARQUET
location 's3://<your-bucket>/<xyz>/lineitem_partition/'
;

CREATE  external table spectrum.LINEITEM_CSV ( 
 L_ORDERKEY BIGINT,
 L_PARTKEY INT,
 L_SUPPKEY INT,
 L_LINENUMBER INT,
 L_QUANTITY DECIMAL(12,2),
 L_EXTENDEDPRICE DECIMAL(12,2),
 L_DISCOUNT DECIMAL(12,2),
 L_TAX DECIMAL(12,2),
 L_RETURNFLAG VARCHAR(128),
 L_LINESTATUS VARCHAR(128),
 L_SHIPDATE VARCHAR(128) ,
 L_COMMITDATE VARCHAR(128),
 L_RECEIPTDATE VARCHAR(128),
 L_SHIPINSTRUCT VARCHAR(128),
 L_SHIPMODE VARCHAR(128),
 L_COMMENT VARCHAR(128))
row format delimited
fields terminated by '|'
stored as textfile
location 's3://<your-bucket>/<xyz>/lineitem_csv/'

SELECT l_returnflag,
       l_linestatus,
       sum(l_quantity) as sum_qty,
       sum(l_extendedprice) as sum_base_price,
       sum(l_extendedprice*(1-l_discount)) as sum_disc_price,
       sum(l_extendedprice*(1-l_discount)*(1+l_tax)) as sum_charge,
       avg(l_quantity) as avg_qty,
       avg(l_extendedprice) as avg_price,
       avg(l_discount) as avg_disc,
       count(*) as count_order
FROM lineitem
WHERE l_shipdate <= '1998-09-01'
GROUP BY l_returnflag, l_linestatus
ORDER BY l_returnflag, l_linestatus;

SELECT  l_orderkey,
       sum(l_extendedprice * (1 - l_discount)) as revenue,
       o_orderdate,
       o_shippriority
FROM	customer, orders, lineitem
WHERE	c_mktsegment = 'BUILDING'
       AND c_custkey = o_custkey
       AND l_orderkey = o_orderkey
       AND o_orderdate < date '1995-03-15'
       AND l_shipdate > date '1995-03-15'
GROUP BY l_orderkey, o_orderdate, o_shippriority
ORDER BY revenue desc, o_orderdate
LIMIT 20;

select * from SVL_S3QUERY_SUMMARY where query=<Query-ID>;

SELECT query,
	segment,
	max(assigned_partitions) as total_partitions,
	max(qualified_partitions) as qualified_partitions 
FROM svl_s3partition 
WHERE query=<Query-ID>
GROUP BY 1,2;

Select MIN(L_SHIPDATE), MAX(L_SHIPDATE), count(*)
	from spectrum.LINEITEM_NPART_PARQ;

Select MIN(DATE(L_SHIPDATE)), MAX(DATE(L_SHIPDATE)), count(*)
        from spectrum.LINEITEM_NPART_PARQ;

SELECT DISTINCT l_returnflag,
        l_linestatus 
FROM 	spectrum.LINEITEM_PART_PARQ 
WHERE 	EXTRACT(YEAR from l_shipdate::DATE) BETWEEN '1995' AND  '1998' 
ORDER BY l_returnflag, l_linestatus
;

SELECT l_returnflag,l_linestatus 
FROM 	spectrum.LINEITEM_PART_PARQ 
WHERE EXTRACT(YEAR from l_shipdate::DATE) BETWEEN '1995' AND  '1998' 
GROUP BY l_returnflag, l_linestatus 
ORDER BY l_returnflag, l_linestatus
;

Alibaba는 원래 KVM을 쓰고 있었는데... 선견지명인가;;;;

어째든 AWS덕분에 HyperVisor도 오픈소스 KVM이 탄력을 받을 듯하다.

http://www.ddaily.co.kr/news/article.html?no=162267

[디지털데일리 백지영기자] 세계 최대 클라우드 서비스 업체인 아마존웹서비스(AWS)가 C5 인스턴스를 새롭게 발표하면서 젠(Xen) 대신 KVM 기반 하이퍼바이저를 사용했다고 밝혀 주목된다.

그동안 AWS은 가상머신(VM) 제공을 위한 하이퍼바이저로 오픈소스인 젠을 활용해왔다. 하지만 이번 KVM 채택을 시작으로 향후 이를 다른 제품까지 확장할 계획이어서 귀추가 주목된다.

최근 AWS가 발표한 새 인스턴스는 배치 처리와 같은 컴퓨트 집약적인 워크로드나 분산 분석, 고성능컴퓨팅(HPC), 비디오 인코딩 등을 위해 디자인됐다. 기존 C4 인스턴스에 비해 가격 대비 성능이 25% 향상됐다. 총 6가지 형태로 출시됐다.

AWS 측은 “네트워킹과 스토리지, 컴퓨팅이 최대의 성능을 낼 수 있도록 오랜기간 동안 AWS 자체적으로 디자인한 하드웨어에 집중해 왔다”며 “C5가 이같은 연구의 결과물이며, 이번 새 하이퍼바이저를 추가하며 이를 극대화했다”고 설명했다.

또 각 vCPU는 3.0GHZ 속도의 인텔 제온 플래티넘 8000시리즈를 기반으로 했다. 인털 터보부스트 기술을 활용할 경우 하나의 코어에서 3.5GHz까지 구동이 가능하다.

이번 AWS의 KVM 하이퍼바이저 채택으로 ‘젠’ 진영의 위축이 예상된다. 젠은 AWS 덕분에 퍼블릭 클라우드 서비스 시장에서 가장 많이 사용되는 하이퍼바이저로 위상을 누려왔다. AWS 측은 관련 내용을 이달 말 열리는 AWS 리인벤트 행사에서 발표할 예정이다.

한편 새 C5 인스턴스는 현재 미국 동부(북부 버지니아)와 서부(오레곤), EU(아일랜드)에사 사용 가능하다.

<백지영 기자>jyp@ddaily.co.kr

포털에서 파일 스토리지 주문 후 

주문된 파일 스토리지 세부 내용으로 들어가서 

"호스트 권한 부여" 메뉴 선택 후 접근할 서버들을 추가함

또는 아래 커맨드로 생성 후 호스트 권한 부여

slcli file volume-order --storage-type endurance --size 100 --tier 4 --location seo01 --snapshot-size 100 --billing hourly

slcli file access-authorize -v 51497695 40209179

(slcli file access-authorize -v VMID VID

아래 커맨드

#nfs프로그램 설치

yum -y install nfs-utils nfs-utils-lib

#마운트할 디렉토리 생성

mkdir /data

#/etc/fstab 파일을 열고 마지막에 아래 내용 추가 후 저장 (앞쪽 nfs서버주소는 포털에서 확인) , nfs4.1로 바뀌면서 sec=sys를 안하면 write가 안되므로 꼭 쓰도록 하자.

vi /etc/fstab

nfsseo0101c-fz.adn.networklayer.com:/IBM01SEV1511949_1   /data    nfs4    hard,intr,rw,sec=sys    0 0

#/etc/fstab 내용을 실제로 마운트 시킴

mount -a

IBM Bluemix Load Balancer

• 애플리케이션 서버 팜 앞에 로드 밸런서를 배치하여 애플리케이션의 가용성과 성능을 향상시킵니다. 
• 애플리케이션 서버의 상태를 모니터링하고 개별 서버 장애로부터 보호합니다. 
• 관리는 직관적인 그래픽 인터페이스와 API를 사용하여 쉽게 사용할 수 있습니다. 
• 무엇보다도 사용하는 것에 대해서만 지불하면 됩니다.

특징들

종량제 가격 책정

로드 밸런서 사용 시간 및 처리 된 데이터를 기준으로 매월 사용한 양에 대해서 만 비용을 지불하면 됩니다.

Offload SSL handshake

SSL 오프로드를 사용하면 서버 자원을 실제 애플리케이션 처리하는 데만 집중할 수 있습니다.
암호화로 인한 서버 자원을 낭비할 필요가 없습니다.

프리미엄 Layer-4

최종 사용자 데이터 트래픽을 여러 응용 프로그램 서버에 지능적으로 배포하고 최종 사용자 환경을 향상시킵니다. 가상 및 베어 메탈 서버을 모두 지원하며,  HTTP, HTTPS 및 TCP 기반 애플리케이션을 위한 Layer-4 스위칭을 수행합니다.

지능형 트래픽 분산

라운드 로빈 (round-robin), 가중 라운드 로빈 (weighted round-robin) 및 최소 연결(least connections)을 사용하여 트래픽을 균형있게 조정할 수 있습니다.

신속한 서버 장애 감지

서버 상태를 정기적으로 모니터링하여 다운된 서버로의 트래픽 전송을 방지합니다.

고급 트래픽 관리

애플리케이션 트래픽 흐름에 맞게 세션 지속성(Session Persistence, 소스 IP 기반)을 설정하거나 VIP포트당 최대 연결 한도를 설정 할 수 있습니다.

비용

다음 메트릭의 실제 소비량에 대해 청구합니다. (아래 SEO01 기준)

SoftLayer 네트워크에는 
퍼블릭 네트워크(인터넷망)과 프라이빗 네트워크(사설망) (10.0.0.0/8)가 있습니다. 
퍼블릭 네트워크를 통해 통신 과금이 발생하는 경우가 있습니다. 
서버에 데이터를 업로드하는 분은 무료입니다만 
서버에서 데이터를 다운로드 (아웃 바운드) 통신 과금 대상이됩니다. 
간단하게 생각하면 Public Interface에서 나가는 트래픽은 과금 대상입니다. (VM 및 Baremetal)

아웃 바운드 통신은 서버 1 대 1 달 다음 무료 프레임이 있습니다.

• 물리적 서버는 500GB
• 가상 서버는 250GB
• 네트워크 어플라이언스 (Vyatta / Citrix NetScaler VPX)은 20TB
  • ※ 어플라이언스는 만약을 위해, 구입 전에 티켓에 확인하는 것이 좋습니다. VPX는 무제한 이라는 얘기도 있습니다.

※ 방화벽은 Bandwidth 의한 청구하지 않습니다. 

즉, Hardware Firewall (Shared,Dedicated), Fortigate Security Appliance 모두 트래픽을 과금 하지 않습니다.
단, 트래픽의 양을 제한하는 기능을 사용할 수 있습니다. 
http://knowledgelayer.softlayer.com/faq/does-softlayer-charge-firewall-bandwidth

그것을 넘은만큼의 트래픽에 대해서는 DC에 대해 다음 요금이 발생합니다. 
서울 PoD는 $ 0.12/GB입니다. 
※ 다음의 값은 1TB의 Bandwidth를 구입할 때 까지의 단가와 동일합니다.

• USA / Amsterdam / London / Frankfurt - $ 0.09 /GB
• Canada / Paris / Milan / Singapore / Seoul - $ 0.12 /GB
• Hong Kong / Tokyo / Australia - $ 0.14 /GB
• Mexico - $ 0.18 /GB
• Brazil / India - $ 0.25 /GB

통신량이 무료 범위를 크게 초과 할 이미 예상된다 있다면, 
사전에 데이터 통신량을 구입할 수 할인됩니다. ( 물리적 서버의 경우 5T 이상에서 거래 ) 
(1000GB을 구입 및 500GB 무료 + 500GB 종량 과금 동일한 금액)

무제한 Unlimited Bandwidth (100 Mbps Uplink)의 가격은 다음과 같습니다.  100Mbps만 제공합니다.
- USA / Amsterdam / London / Frankfurt - $ 2000 
- Canada / Paris / Milan / Singapore / Seoul - $ 2660 
- Hong Kong / Tokyo / Australia - $ 3120
- Mexico - $ 4000 
- Brazil / India - $ 5560

추가 Bandwidth 용량이 필요하신 분은 1TB로 구분하여 티켓을 통해 주문 가능합니다. 
http://knowledgelayer.softlayer.com/faqs/56#671

How can I get additional bandwidth for my server ? 
The best way to purchase additional bandwidth for your server is to open a "Sales"ticket, requesting additional bandwidth. Please specify the amount of additional bandwidth and the server you are requesting the bandwidth for . 
Note : Bandwidth is only available in 1000GB increments or as an unmetered service .

또한 무상 프레임의 2 배를 초과하면 즉시 종량 과금하고 무상 프레임의 2 배 이내이면 추가 분은 다음달에 청구됩니다.
http://knowledgelayer.softlayer.com/faq/how-much-do-you-charge-bandwidth-overages

If you exceed twice the amount of bandwidth you are allotted, we will automatically charge you for excess bandwidth used at the time. If you exceed your allotment by less than twice the allowance, the overages will be added to your next monthly invoice.

Bandwidth는 풀링 할 수 있습니다. 즉 각 서버들의 트래픽을 모아서 하나의 풀 안에서 꺼내어 쓸 수 있습니다.
다만, Pooling하려면 서버마다 $ 25 필요합니다. 
Unlimited Bandwidth를 포함 할 수는 없습니다.

다음은 vRouter 5400과 vRouter 5600의 차이점을 설명하고 있습니다. 
앞서 언급 한 바와 같이, 불행히도 공식 마이그레이션 가이드 같은 것은 존재하지 않기 때문에 전반적인 포괄적인 가이드를 하기에는 어려운 상황입니다.

5. 인터페이스

vRouter 5600에서는 컨트롤 플레인과 데이터 플레인이 분리된 DPDK를 이용하기 때문에 인터페이스가 아래처럼 각각 변경되었습니다.

• eth0, eth1, eth2, eth3 -> dp0s0, dp0s1, dp0s2, dp0s3
• bond0, bond1 -> dp0bond0, dp0bond1

그리고 vRouter 5400에서 eth0과 eth2이 bond0으로 eth1과 eth3가 bond1으로 각각 LACP로 구성하고 있던 것처럼,
vRouter 5600에서는 dp0s0와 dp0s2이 dp0bond0으로 dp0s1과 dp0s3이 dp0bond1으로 각각 LACP 구성하고 다음과 같이 옵션이 변경되었습니다.

• hash-policy -> vRouter 5600에서는 폐지
• mode 802.3ad -> mode lacp

또한 VRRP는 다음과 같이 변경됩니다.

• rfc3768-compatibility -> rfc-compatibility
• VRRP 광고 간격을 나타내는 advertisement 값은 vRouter 5400에서는 bond0/bond1에 주문 후 생성된 초기 구성에서 명시적으로 1 초에 설정되어 있습니다.
  vRouter 5600에서는 dp0bond0/dp0bond1에 주문 직후의 초기 구성은 설정되어 있지 않지만, 기본값은 1 초이므로 동작은 동일합니다.
  하지만 명시적으로 설정해 줄 것을 권장합니다.

또한 VRRP인터페이스는 RFC 규격에 따라 bondXvX 에서 dp0vrrpX 로 변경되어 있습니다. 이것은 show vrrp명령을 실행하는 것으로 확인할 수 있습니다.

• VIF의 설정 방법은 기존과 동일합니다. rfc-compatibility는 native interface에만 설정하고 VIF는 TAG VLAN이므로 설정하지 않는다는것도 vRouter 5400 때와 동일합니다. (설정하면 VIP의 Arp Resolution이 실패합니다)
• Vyatta의 vrrp-group 번호와 sync-group 번호도 vRouter 5400 때와 동일하게, IBM Cloud에서 할당 해 준 것을 최대한 이용해야 합니다. 사용자가 변경 했을 때, 만약 Vyatta의 HA 구성이 여러 세트로 준비 된 경우 나중에 도입 된 다른 세트의 vRouter에 할당 된 vrrp-group 번호가 중복되어 vrrp의 flapping이 발생하여 통신 불가에 빠질 수 있습니다. 만약 사용자가 독자적으로 할당할 경우 중복이 일어나지 않도록 주의해야 합니다.

6. SSH 서비스

vRouter 5400에서는 SSH 포트는 하나만 설정 가능했습니다. 그러나 vRouter 5600에서는 여러개의 포트를 설정 가능합니다. 만약 하나만 사용한다면 사용하지 않는 포트는 명시적으로 제거해야 합니다.

7. Firewall

vRouter 5400에서는 iptables 기반 (커널 기반) 이었지만, vRouter 5600에서는 사용자 영역(User Space)에서 제어하도록 구현되어 있습니다. 따라서 규칙의 설정 방법과 해석이 vRouter 5400과는 크게 변경되어 있습니다. 
Vyatta에서 Firewall은 반드시 사용하는 기능이므로 여기가 마이그레이션중 제일 어려운 곳이라고 생각됩니다.

7.1 설정 방법

vRouter 5400에서 set firewall로 설정하고 있었지만, vRouter 5600에서 set security firewall설정합니다.

그리고 vRouter 5400는 하나의 인터페이스에 대한 in/out/local을 하나씩만 firewall을 설정할 수 있었지만, vRouter 5600에서는 다음 처럼 여러 개 지정할 수있게 되었습니다.

7.2 인터페이스 기반 규칙 해석 순서

vRouter는 인터페이스 기반의 방화벽(Firewall)과 영역기반(zone-based) 방화벽이 있습니다. 인터페이스 기반의 방화벽은 vRouter 5400에서는 아래와 같이 iptable의 CHAIN과 동일하게 DNAT -> 방화벽(IN/OUT) -> SNAT 순서로 패킷이 처리되고 있습니다.

하지만, vRouter 5600에서는 다음과 같이 DNAT 전에 IN-방화벽이 먼저 평가됩니다.
Vyatta(로컬프로세스)에 대상 패킷이 도달하기 위해 IN-방화벽과 LOCAL-방화벽을 모두 통과해야만 한다는 것을 주의해야 합니다.
따라서 LOCAL로 접근하기 위해서는, vRouter 5400에서 기존 LOCAL-방화벽 설정을 IN-방화벽에 반영시킬 필요가 있습니다.
※ 앞서 얘기한 바와 같이 하나의 인터페이스에 여러개의 설정을 반영시킬 수 있기 때문에 vRouter 5400에서 LOCAL-방화벽으로 지정했던 정책을 vRouter 5600에서 IN-방화벽으로 지정하고 LOCAL-방화벽은 사용하지 않도록 해도 충분할 수 있습니다.

7.3 state policy의 global 옵션 설정

vRouter 5400에서는 iptables에서 사용하던 established/related 상태에 대한 설정을 global 수준에서만 지정 가능했습니다.
vRouter 5600에서는 TCP/UDP/ICMP 마다 stateful할지 여부를 지정할 수 있습니다.

7.4 stateful firewall

vRouter 5400에서는 iptables에서 사용하던 established/related 상태에 대한 설정을 지정할 수 있었습니다. 또한 새 세션의 지정에 대해서는 new라는 상태를 이용했습니다.
vRouter 5600에서는 stateful하기 위해 단순히 state enable을 지정합니다. 새 세션의 지정에 관해서는 TCP에 관해서는 TCP Flag를 이용합니다.

7.5 여러개의 port를 설정 하는 방법

vRouter 5400에서는 destination port를 직접 쓸 수 있습니다. (iptables의 multiport 옵션에 해당)
vRouter 5600에서는 명시적으로 port-group을 작성해서 사용 해야합니다.

7.6 QOS / Traffic policy

5400에서는 QOS / Traffic policy 설정시 set traffic-policy를 사용했습니다.
5600에서는 set policy qos를 사용하거나 firewall rule에서 설정할 수 있습니다.

8. NAT

예전에는 NAT는 set nat xxx로 설정했지만 앞으로는 set service nat xxx로 설정합니다.

9. IPsec VPN

• vRouter 5400에서 set vpn로 설정했던 것을 vRouter 5600에서는 set security vpn로 설정합니다.
• IKEv2를 지원합니다. set security vpn ipsec ike-group IKEGROUP1 ike-version 2
• IKE 실행 모드는 Main mode와 Aggressive mode의 2가지가 있습니다만, vRouter 5600에서도 Aggressive mode는 지원하지 않는 것 같습니다. 따라서 vRouter 5400 때와 마찬가지로 상대 기종에서는 Aggressive mode를 비활성화해야 합니다.
• vRouter 5400에서는 ipsec-interfaces 의 지정이 필요했지만, vRouter 5600에서는 필요없습니다.
• Site-to-Site VPN을 이용할 때는 prefix 지정으로 터널을 설정하는 방법과, VTI인터페이스를 설정하고 별도 라우팅을 설정하는 방법이 있습니다.
  • zone-based firewall을 이용하고있는 경우에는 prefix 지정 터널은 잘 동작하지 않는 것 같습니다. 만약 zone-based firewall을 이용하고있는 경우에는 VTI를 사용합시다.
  • prefix지정 VPN터널에서 흐르는 트래픽은 송신 원본 인터페이스가 불분명 하기 때문에 zone-based firewall에 의해 drop될 가능성이 있습니다.

10. OpenVPN

OpenVPN에 대한 설정 방법은 기본적으로 변경이 없습니다.

11. conntrack module

vRouter 5400에서는 다음과 같이 conntrak모듈을 사용합니다.

12. root가되는 방법 / sudo 대해

vRouter 5400에서는 sudo -s 로 암호없이 root 사용자 수있었습니다. 그러나 vRouter 5600에서는 vyatta 사용자가 sudo를 실행할 권한이 없습니다. 이것은 vRouetr5600에 admin보다 더 상위의 권한 수준으로 superuser가 만들어졌기 때문입니다. vRouter 5400 처럼 vyatta 사용자가 sudo를 실행하기 위해서는 superuser로 변경해야 합니다.

그러나 sudo 실행시 비밀번호 입력을 요구하게됩니다. 비밀번호 입력없이 sudo를 실행하기 위해서는 /etc/sudoers를 편집해야 합니다.
시스템 설정을 직접 편집 하는 것은 vRouter의 지원 범위를 벗어나지 만, 아무래도 비밀번호 입력없이 sudo를 실행해야 한다면 다음 단계를 수행하면 됩니다.
(반복하지만 vRouter의 지원 대상에서 제외 되므로 이 변경 작업으로 인한 어떤 문제가 발생하더라도 책임 지지 않습니다!).
재부팅시 설정이 사라지지 않겠지만, 버전 업 등을 행한 경우 이 정보는 유실 되어 재구성이 필요할 수 있습니다.

참고 : 버그

• Version 5.2R5S3 에서 # set system login user vyatta level superuser를 한 번 설정 한 후 다시 # set system login user vyatta level superuser로 admin을 복원해도 $ show login 명령의 출력 결과는 Superuser 상태가되어 버리는 표시 버그가 있습니다.  "Bug ID : VRVDR-37958"로 등록되어 있으며 vRouter 5600 17.2 이상 (Yountville)에서 수정 예정입니다.

13. SSL/TLS의 버전

vRouter 5400에서는 TLS1.0 만을 지원하고 있으며, SSLv3, TLS1.1, TLS1.2은 지원하지 않습니다.
vRouter 5600에서는 TLS1.0, TLS1.1, TLS1.2을 지원하고 있으며, SSLv3는 지원하지 않습니다.

14. tcpdump

tcpdump를 캡처 할 때 어떤 인터페이스의 통신인지를 확인하는 것이 귀찮을 때 -i any를 사용하는 일이 자주 있습니다.vRouter 5400에서는 그렇게 해도 문제가 없었습니다만,
vRouter 5600에서 -i any 사용은 vRouter가 보낸 패킷은 캡처하고 주는데, vRouter를 통한 패킷(dataplane 이용)은 캡처를 하지 않으므로, 명시적으로 인터페이스를 지정할 필요가 있습니다.

1. 첫번째

본 기사에서는 IBM Cloud (Bluemix Infrastructure / SoftLayer)의 Vyatta Gateway Appliance (vRouter 5400)와 Virtual Router Appliance (vRouter 5600)의 차이를 설명하고, 5400에서 5600으로 마이그레이션 하는 것을 목표로 합니다. 
불행히도 Vyatta Gateway Appliance (vRouter 5400)는

• 2017 년 9 월 1 일에 EOM (End of Market : 판매 종료)
• 2018 년 2 월 20 일에 EOS (End of Support : 지원 종료)

됩니다. 공식 마이그레이션 가이드 같은 것은 존재하지 않기 때문에 전반적으로 설명 하기는  어려운 상황입니다.
먼저 마이그레이션전 준비사항에 대해 알아 보겠습니다.
참고 자료 :

• KnowledgeLayer : Virtual Router Appliance
• Vyatta의 새로운 버전의 이용에 대해 (Bluemix Infrastructure 용)
• SoftLayer Product Life Cycle Policy

2. vRouter5400 / 5600의 차이점 요약

• vRouter 5400의 후속 버전이 vRouter 5600이지만, 불행히도 설정이 서로 호환 되지 않습니다. 따라서 5400 구성 스크립트를 5600에서 그대로 실행할 수 없습니다. 기본적인 설정 방법은 기존 방법 처럼, Operation Mode와 Configuration Mode를 구분하여 설정합니다.
• CloudZ IBM Bluemix IaaS는 Portal에서 Vyatta Gateway Appliance (vRouter 5400)를  여러 VLAN을 연결(associated)시킨 후, Routed 모드로  전환하여, 연결 된 VLAN에 대한 라우팅을 Vyatta Gateway Appliance의 VRRP에 할당 된 VIP 통하도록 설정 가능했습니다. 당연히 Virtual Router Appliance (vRouter 5600)에서도 동일 하게 할 수 있습니다.
• 기존 vRouter 5400은 받은 패킷을 Linux Kernel에서 처리했지만 이것만으로는 10Gbps 같은 고속 NIC환경에서는 인터럽트 처리가 따라잡지 못했습니다. 충분한 성능 상의 혜택을 받기 위해서, vRouter 5600에서는 컨트롤 플레인(전송 경로의 결정)와 데이터 플레인(실제 전송)처리 부분을 분리하고 특히 데이터 플레인에서 Intel DPDK를 이용하고 유저 랜드에서 효율적으로 처리를 목표로 하였습니다. (https://namu.wiki/w/Intel%20DPDK) 따라서 데이터 플레인의 인터페이스가 설치되고, iptables를 이용하지 않는 유저 랜드에서 처리하는 필터링 방식으로 변경되어 있습니다. slideshare에있는 «고성능 가상 Router»Brocade Vyatta 5600 vRouter 아키텍처 개요를 참조하십시오.
• vRouter의 OS 비용은 vRouter 5400는 $219 로 고정이 였지만, vRouter5600는 다음과 같이 변경되어 있습니다. (기타 비용은 변경되지 않습니다)
  • Single Processor 모델은 $219그대로 동결.
  • Dual Processor 모델은 $399로 증가.

3. 마이그레이션 전략

마이그레이션 전략은 다음의 두가지 방법을 생각할 수 있습니다.

3.1 새로 vRouter 5600을 구축하는 방법.

장점

• 새로운 환경에서 충분히 테스트 한 후 기존 vRouter 5400에서 VLAN disassociate 후 신규 vRouter 5600에 VLAN associate 함으로써 다운타임을 최소화 하면서 전환 할 수있다.
• 전환시 문제가 발견된 경우에는 VLAN의 associate / disassociate 만 바꾸어서 즉시 이전 vRouter 5400 환경으로 되돌릴 수있다.

단점

• vRouter 자신의 IP 주소와 VRRP의 VIP 등의 IP 주소가 변경되어 버린다. 그 결과 vRouter 와 연결된 상대 쪽 VPN 장비 및 On-Prem의 NW 구성 변경이 필요하기 때문에, 만약 이러한 상대 쪽 환경이 존재한다면 영향 범위를 클라우드로만 볼 수 없다.
• 신규로 프로비저닝한 vRouter 5600과 기존 vRouter 5400의 동시 사용을 위한 과금을 고려해야 한다. (월말 변경 추천)
• 전환전 Firewall등을 검증 하기 위해 서버 및 스토리지가 필요하다.( 테스트만 사용할 시간 과금 추천)

3.2 기존 vRouter 5400을 직접 OS Reload에서 마이그레이션하는 방법

기존 자원의 OS를 vRouter5400 -> vRouter 5600 로 바꾸는 것은 OS reload (기존 서버에 OS를 다시 설치하는 기능)기능으로 실행 가능하며, 다음 문서에 방법이 나와 있습니다.

• Learn about Virtual Router Appliance upgrade options?

장점

• IP 주소가 변경되지 않는다.
• 기존 서버를 재사용하기 때문에 추가 요금이 최소 밖에 발생하지 않는다. (OS 라이선스 비용 일할 과금)
• 기존 서버를 재사용하기 때문에 서버를 새로 주문을 할 필요가 없다.
• vRouter 5400의 EOM(End of Market)까지는 OS reload를 해서vRouter 5600을 다시 vRouter 5400에 되돌릴수도 있다.
• 기존 HA로 구성이 되어 있을 경우 Slave 1대만 reload를 해서 vRouter 5400과 vRouter 5600 두개로 VRRP에 따른 HA 구성을 만들 수 있기 때문에, vRouter 5600로 전환하고 본격적인 테스트를 한 후, 문제가 발생하면 vRouter 5400로 되돌릴 수 있다.

단점

• 서비스 영향을 최소화하기 위한 테스트를 충분히 실시 할 수 없을 가능성이 있다. (특히, HA 구성이 안되어 있는 경우)

vRouter 5400과 vRouter 5600에는 많은 차이가 있기 때문에 사전에 이론적으로 문서상으로만 탁상 공론해서 정리하기는 어렵다고 생각됩니다. 만약 OS Reload으로 전환하더라도 1) vRouter 5600에서 동작 확인을 다른 환경에서 미리 실시하는 것과, 2) 유지 보수 시간을 충분히 마련하여 테스트 시간와 장애시 복구할 시간을 확보해 둔 다음 작업하는 것이 바람직 합니다.

4. 마이그레이션 전에 해 두어야 할 일

4.1 유지 보수 시간의 확보

VLAN의 route / bypass 변경 및 associate / disassociate 중 네트워크 중단이 발생하기 때문에, 이전 하는 동안에 Vyatta 통한 스토리지 액세스 등은 피해야 합니다. 마이그레이션 시간과 테스트 시간, 만일의 경우 복구 시간까지 고려해서  유지 보수 시간을 미리 확보 해 두어야 합니다.

4.2 미리 백업해두기

• vRouter 5400에서 vRouter 5600은 IBM Cloud에서 OS reload을하여 upgrade 할 수 있습니다. 이때에는 설정 파일은 초기화되어 버리기 때문에 다음 방법등을 이용하여 백업을 해 두어야 합니다. 당연하지만 백업 한 파일은 다른 서버 등으로 복사 해 두십세요.

•  Vyatta / VyOS 설정 정보를 그대로 또는 암호 정보를 은폐하고 명령 형식으로 추출하는 방법

4.3 Master / Backup 노드의 확인

두 노드가 MASTER / BACKUP인지 확인합니다. 만약 OS Reload 마이그레이션을 수행 할 때 BACKUP NODE에서 실시합시다.

MASTER / BACKUP을 전환하기 위해서는 MASTER 노드 측에서 reset vrrp master명령을 실행합니다. 다음 예제는 group 1을 전환 하였을 때의 예이지만, group 2, 3도 마찬가지로 명령을 실행하여 전환 할 수 있습니다.

4.4 Preempt 기능 비활성화 및 Priority 값 확인

Preempt 기능을 비활성화하면 1호기에 장애가 생겨서 2호기로 Takeover가 발생한 후, 1호기가 다시 복구되어도 Priority 값(높을수록 우선 순위 높음)과 관계없이 2 호기가 계속 MASTER로 동작합니다. 
반면, Preempt 기능을 활성화하면, 1호기에 장애가 생겨서 2호기에 Takeover가 발생한 후, 1호기가 다시 복구되었을 때 만약 1호기의 Prioirty 값이 높으면 1호기에 다시 FailBack을 합니다. 작업 중에 Priority값이 높은 서버로 자동적으로 돌아가고 싶지 않으면 두 노드에서 Preempt기능은 미리 해제하도록 권장합니다.
※ 원래 Preempt 기능은 VRRP 구성을 하는 두대의 Vyatta에 성능 차이가있을 때 가능한 성능 수치가 높은 노드에서 처리시키는 경우에 유효하지만, 모두 동일한 성능과 기종을 이용한다면 Preempt 기능을 이용하는 것은 별로 의미가 없습니다.

4.5 Config-Sync 기능 해제 확인

# show system config-sync구성에서 알 수 있듯이 기본적으로 nat, firewall, vpn 구성이 자동으로 동기화되도록 구성되어 있습니다. 만약 vRouter 5400과 5600을 섞어서 구성하면 동기화하려고 됨으로써 시스템이 불안정해질 수 있습니다. 5400과 5600의 구성이 다르기 때문에 서로 동기화하는 것은 의미가 없습니다. 만약 Config-Sync를 수행한다면 두 노드를 5600로 upgrade 후에해야합니다. 마이그레이션 전에 두 노드에서 Config-Sync는 사전에 삭제 해 두어야 합니다.