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는 사전에 삭제 해 두어야 합니다.

IBM Cloud에서 Vyatta을 이용 중이거나 제안중인 분들에게, 체크 해야 할 포인트를 알려드립니다.

Vyatta Gateway Appliance(VGA) 또는 Vyatta 6.x Subscription Edition on Bare Metal Server는 IBM Cloud Bluemix Infrastructure (구 SoftLayer)에서 방화벽 (영역 사이의 필터링)과 암호화 통신 (IPsec VPN) 및 캡슐화 통신 (GRE) 등 에 이용되는 소프트웨어 라우터입니다.
현재 제안 중 · 구축 된 환경에서, Vyatta을 이용되는 분은 꼭 아래의 Q & A를 읽어보십시오.

Q1 : 현재 Vyatta의 End of Support (EOS:지원중지)는 언제인가?

A : 기존 Vyatta은 vRouter 5400을 사용하고 있었습니다. vRoter 5400 개발사인 Brocade 사의 EOS는 2017년 8월로 예정되어 있습니다. IBM Cloud에서의 EOS는 반년 후 2018년 2월 20일 (예정)입니다.
또한 vRouter5400의 EOM이 9/1되었다고 8/1에 발표되었습니다. 이 EOM 이후 vRouter5400이다 Vyatta Gateway Appliance는 새로 주문할 수 없습니다.
http://knowledgelayer.softlayer.com/faqs/1493#7423 (영문)
http://www.brocade.com/en/support/product-end-of-life.html (영문)

Q2 : 현재 Vyatta (vRouter 5400)의 후속 제품은?

A : Virtual Router Appliance (VRA)입니다. vRouter5600를 기반으로 제공되지만 이제 vRouter 5600로 판매되는 AT&T 제품은 없습니다. 하지만 VRA의 기반이되는 vRouter5600 지원은 IBM과 AT&T의 유지 보수 계약에 따라 계속 제공되므로 vRouter5600 자체의 EOS에는 영향을 받지 않습니다. 
자세한 내용은 아래 링크를 참조하십시오.
https://knowledgelayer.softlayer.com/topic/virtual-router-appliance (영문)

Q3 : VRA되면 무엇이 좋아지나요?

A : vRouter 5400는 소프트웨어적인 처리를 많이 사용하고 있기 때문에, 10Gbps NIC의 성능을 살릴 수 없었습니다. VRA의 기반이 되는 vRouter5600는 새로운 암호화 기능과 DPDK 사용으로 인해서 대폭적인 성능 향상이 있습니다.
VGA에서 VRA로 변경했을 때의 구체적인 장점은 다음과 같습니다.

• CPU 코어 당 처리량 향상
• Advanced Encryption Standards(AES)에 따른 IPSec VPN 세션 처리량 향상 (최대 3배)
• Routes, Flows 동시 연결 제한을 확장함
• Layer2 터널링 프로토콜 Version 3 (L2TPv3) 인터넷 키 교환, Version 2 (IKEv2), Secure Hash Algorithm 2 (SHA-2) 및 802.1Q tunneling (Q-in-Q) 캡슐화 기능을 구현

자세한 내용은 아래 링크를 참조하십시오.
http://knowledgelayer.softlayer.com/procedure/what-improvements-does-brocade-vrouter-5600-have-over-vyatta-5400 (영문)
https://www.slideshare.net/brocade/brocade-vyatta-5600vrouterarchitectureag

Q4 vRouter 5400에서 VRA로 전환상의 주의점은?

A : vRouter 5400에서 사용했던 Customer Portal에서 VLAN Association / Bypass mode / Routed mode 등의 Vyatta Gateway Appliance가 제공하는 라우팅 구조 자체는 바뀌지 않습니다. 즉, 기존과 같은 DMZ 구성 및 VPN 구성을 할 수 있습니다. 
그러나 DPDK를 사용하고 및 기존 내부 아키텍처를 변경함에 따라 인터페이스의 변경 (예 : eth0 -> dp0s0, bond0 -> dp0bond0 등)이나 명령의 변경 (set firewall name xxxx -> set security firewall name xxxx)이 되었고, vRouter 5400 구성 스크립트를 그대로 VRA에서 사용할 수 없습니다. 
또한 Vyatta은 self managed 서비스 이므로, IBM에 의한 자동 전환은 지원 되지 않습니다. 
따라서 이전(migration)을 하기 전에 충분한 검토와 테스트 기간을 두는 것이 좋습니다. 
또한 이전에 따른주의 사항은 아래 "vRouter5400 (Vyatta Gateway Appliance)에서 vRouter5600 (Virtual Router Appliance)로 전환"을 참조하십시오.
(참고 자료)
vRouter5400 (Vyatta Gateway Appliance)에서 vRouter5600 (Virtual Router Appliance)로 전환 (1)
vRouter5400 (Vyatta Gateway Appliance)에서 vRouter5600 (Virtual Router Appliance)로 전환 (2) 

VYATTA 5400 TO VIRTUAL ROUTER APPLIANCE UPGRADE OPTIONS 
http://knowledgelayer.softlayer.com/procedure/learn-about-virtual-router-appliance-upgrade-options (영문)

Brocade 5600 vRouter Software Documentation Library 
http://www.brocade.com/content/html/en/technical-documentation-library/5600-vrouter-50r1-library/GUID-9F13C099-B7E0-4FF9-AC65-5B3CA911E05A-homepage.html (영문)
http://www.brocade.com/content/dam/common/documents/content-types/technical-documentation-library/brocade-5600-vrouter-doc-library-index.pdf (Index PDF)

Q5 : VRA는 어떻게 주문할 수 있나요?

A : 현재 다음의 데이터 센터에서 사용할 수 있습니다.
https://knowledgelayer.softlayer.com/faqs/1495#7461 (영문)

Q6 : VRA의 가격은 얼마인가요?

A : vRouter 5400 OS 라이선스 비용은 $219 이었지만, 

Virtual Router Appliance 5.x (up to 1Gbps) Subscription Edition (64 Bit) [$219.00]

Virtual Router Appliance 5.x (up to 20Gbps) Subscription Edition (64 Bit) [$399.00]

http://knowledgelayer.softlayer.com/faqs/1493#7423 (영문)

Q7 : Early Adapter Program의 알려진 문제점이 있나요?

A : 아래 링크를 참조하십시오. 
또한 현재 Early Adapter Program으로 vRouter5600을 이용하신 고객에 대해서는, OS 다시로드를 사용하여 2017 / 8 / 31까지 vRouter5600에서 VRA 전환을 실시합니다.
http://knowledgelayer.softlayer.com/procedure/please-note-following-about-brocade-vrouter-5600-eap (영문)

Q8 : 현재 구축 된 시스템은 VRA에 언제 이행해야 하나요?

A : 마이그레이션을 위해 충분한 준비 기간이있는 것이 바람직합니다. 따라서 vRouter5400의 EOS 3개월 전인 2017년 11월 이전에 검토를 시작하십시오. EOS를 맞이해도 이용자의 책임으로 계속 작동 할 수 있지만, 보수의 관점에서 EOS의 시기를 목표로 VRA로 전환 할 것을 권장합니다.

CentOS7 HA Cluster 구축 하기

* 요구사항

 - 두대의 Private IP를 가진 서버, 별개의 VIP를 통한 Failover 구성

 - 상기 두개의 서버에서 1개의 공유 스토리지 사용 : Block Storage, GFS2, 100GB/1000IOPS (성능은 맞추어서)

* 아키텍처

* HA 구성을 위한 리소스 구매

- Linux Server 2대 신청 : CentOS 7.x - Minimal Install (64 bit)

==>  svr01.mungi.com  10.178.80.44

==>  svr02.mungi.com  10.178.80.45

- Performance Storage 100GB/1000IOPS 신청

==>  대상 주소 :161.26.102.18

==>  허용서버 추가 (2대)

==>  svr01

   사용자명: IBM01SU1040169-V36035181

   패스워드: Sm99G8pgxSlfH3EG

   호스트 IQN: iqn.2005-05.com.softlayer:IBM01SU1040169-V36035181

==>  svr02

   사용자명: IBM01SU1040169-V29352927

   패스워드: EZlHmrKzNgexS9ar

   호스트 IQN: iqn.2005-05.com.softlayer:IBM01SU1040169-V29352927

- VIP 사용을 위한 Portable Private IP 신청 

==>  10.178.5.230

* iSCSI연결

yum install -y iscsi-initiator-utils device-mapper-multipath

touch /etc/multipath.conf

systemctl start multipathd

systemctl enable multipathd

cp /etc/iscsi/initiatorname.iscsi{,.orig}

vi /etc/iscsi/initiatorname.iscsi #=> CloudZ포털에서 확인한 HOST IQN 값으로 변경

cp /etc/iscsi/iscsid.conf{,.orig}

vi /etc/iscsi/iscsid.conf  #=> 아래 항목을 주석 해제 및 CloudZ 포털에서 확인한 값으로 변경

    node.session.auth.authmethod = CHAP

    node.session.auth.username = "Username-value-from-SL-Portal"

    node.session.auth.password = "Password-value-from-SL-Portal"

    discovery.sendtargets.auth.authmethod = CHAP

    discovery.sendtargets.auth.username = "Username-value-from-SL-Portal"

    discovery.sendtargets.auth.password = "Password-value-from-SL-Portal"

systemctl enable iscsi

systemctl enable iscsid

systemctl start iscsi

systemctl start iscsid

systemctl status iscsid #=> active (running) 인지 확인

iscsiadm -m discovery -t sendtargets -p "161.26.102.18" #=> CloudZ 포털에서 확인한 IP 값으로 변경

iscsiadm -m node -L automatic

multipath -l #=> 아래 처럼 보여야 함

* Cluster 구성

/etc/hosts에 상대 정보 추가

10.178.80.44  svr01.mungi.com svr01

10.178.80.45  svr02.mungi.com svr02

==> VIP

yum install -y corosync pacemaker pcs resource-agents

systemctl start pcsd

systemctl enable pcsd

systemctl enable corosync

systemctl enable pacemaker

passwd hacluster                   #자동생성된 hacluster유저의 패스워드 설정

# --> 여기서 부터는 한쪽에서만 해도 됨.

pcs cluster auth svr01          #인증 계정 적용

pcs cluster auth svr02

# MyCluster 이름의 클러스터를 생성

#해당 클러스터엔 svr01 svr02 두대의 서버가 포함

#데이터 전송은 UDP통신을 사용하도록 설정

pcs cluster setup --start --name MyCluster svr01 svr02 --transport udpu

pcs property set stonith-enabled=false

pcs cluster start --all

pcs status #옵션 정상 구성확인, 계속볼려면 crm_mon

* VIP 클러스터 리소스 설정, Portable Private IP 사용

pcs resource create SVC_VIP IPaddr2 ip=10.178.77.230 cidr_netmask=32 nic=eth0:1 op monitor interval=5s  #사용할 VIP로 설정, 퍼블릭이면 eth1:1

* 스토리지 클러스터 리소스 설정

iscsiadm -m session  #각서버에서 세션 맺어진 것 확인

yum install -y fence-agents-scsi  gfs2-utils  lvm2-cluster

# multipath -l dev id 확인후 3600a098038303743372b4966496d724d 변경

pcs stonith create SCSI-STONITH fence_scsi devices=/dev/mapper/3600a098038303743372b4966496d724d pcmk_monitor_action=metadata  pcmk_reboot_action=off pcmk_host_list="svr01 svr02" meta provides=unfencing

pcs property set stonith-enabled=true

pcs property set no-quorum-policy=ignore

pcs property set default-resource-stickiness=100

#볼륨 매니저 설정

lvmconf --enable-cluster

pcs cluster cib dlm_cfg

pcs -f dlm_cfg resource create dlm ocf:pacemaker:controld op monitor interval=120s on-fail=fence clone interleave=true ordered=true

pcs -f dlm_cfg resource create clvmd ocf:heartbeat:clvm op monitor interval=120s on-fail=fence clone interleave=true ordered=true

pcs -f dlm_cfg constraint order start dlm-clone then clvmd-clone

pcs -f dlm_cfg constraint colocation add clvmd-clone with dlm-clone

pcs -f dlm_cfg property set no-quorum-policy=freeze

pcs -f dlm_cfg constraint

pcs -f dlm_cfg resource show

pcs cluster cib-push dlm_cfg

#디스크 파티션 구성 및 포맷

fdisk /dev/mapper/3600a098038303743372b4966496d724d

  n -> primary -> 계속 엔터, t -> 8e

partprobe /dev/mapper/3600a098038303743372b4966496d724d

pvcreate -ff /dev/mapper/3600a098038303743372b4966496d724d

vgcreate --clustered=y vg_cluster /dev/mapper/3600a098038303743372b4966496d724d

lvcreate -l 100%FREE --name lv_storage vg_cluster

mkfs.gfs2 -j2 -t MyCluster:DataDisk -p lock_dlm /dev/vg_cluster/lv_storage

# 디스크 마운트

mkdir -p /DataDisk  #디렉토리 생성은 양쪽 서버에 수행

pcs resource create ClusterFS Filesystem device="/dev/vg_cluster/lv_storage" directory="/DataDisk" fstype="gfs2" "options=noatime" op monitor interval=10s on-fail=fence clone interleave=true

CentOS 7 기준

사설 - eth0

cp /etc/sysconfig/network-scripts/ifcfg-eth0{,:1}

vi /etc/sysconfig/network-scripts/ifcfg-eth0:1

   DEVICE=eth0:1

   IPADDR=10.178.5.230

   #나머진 그대로.

ifup eth0:1

공인 - eth1

cp /etc/sysconfig/network-scripts/ifcfg-eth1{,:1}

vi /etc/sysconfig/network-scripts/ifcfg-eth1:1

BOOTPROTO=static

DEFROUTE=yes

DEVICE=eth1:1

GATEWAY=169.56.115.25

IPADDR=169.56.115.26

NETMASK=255.255.255.248

ONBOOT=yes

알리윤이 두바이 리전도 오픈했습니다.

오픈때 유튜브로 실시간 중계도 했는데요.

케피야를 쓴 중동 사람들이 인상적이였습니다. ㅎㅎ

유니크는 영어로 하는데 역시 CEO는 중국어로 하네요.

이제 호주 리전만 오픈 하면 계획 했던로 14개 리전 오픈 완료이네요.

Alibaba Cloud 리전은 AWS와 다르게 AZ가 1개만 되어도 오픈합니다.

무조건 AZ가 최소2개(히든까지 3개)가 되어야 하는 AWS 정책과는 좀 다르죠..

Mainland 싸이트에만 있던 Container 서비스가 International 싸이트에도 오픈 되었다.

Docker 및 Cluster를 관리 할 수 있다.

관련 문서 : https://intl.aliyun.com/help/product/25972.htm

Mainland 싸이트에만 있던 KMS (Key  Management Service) 가 International 싸이트에도 오픈 되었다.

문서 : https://intl.aliyun.com/help/product/28933.htm

지난 주 일본 리전 런칭에 이어

이번주는 독일 리전을 런칭했다.

리전 코드는 eu-central-1 이며, 가용존은 A 하나만 있다.

시간단위 과금 을 1  => 100% 로  봤을때

월단위 과금은 시간과금의 1/3 => 33% 이며

년단위 과금은 월단위 과금에서 2개월을 더준다, 즉 10개월치 가격

즉 월요금의 10/12 => 5/6  가격이며, 시간요금의  (1/3) * (5/6)  => 5/18 => 1/3.6 => 28% 가 되겠다.

일반적으로 월단위 정산을 하고, 년단위 일시불은 비용부담을 생각했을때 월단위 과금이 제일 효과적일수 있다.

다만, 1년이상 고정비가 확정된건 역시 년단위로 하는게 맞을것 이다.

AWS의 RI가 최소 1년단위임을 생각해보면 월단위 요금제는 굉장히 현실적으로 다가오는 요금제라고 생각된다.

알리윤에서 윈도 2008 인스턴스를 생성할때 실수로 중국어로 생성할 때가 있다. 

이럴때 월과금으로 생성했으면 지울수 없으니 그냥 언어를 변경하면 된다.

=> 한글 또는 영문 MUI 팩 설치 후 언어, 로케일 변경

https://www.microsoft.com/ko-kr/download/confirmation.aspx?id=12250

그래도 중문으로 종종 나오는 메뉴들이 있지만 불편함은 없을 정도 이다.