동기 부여

OCHaCafe Premium#1: Oracle Cloud에서 생각하는 고가용성 아키텍처 에서 보조 IP를 페일 오버 데모를보고보고 싶어졌습니다.

결과

IP 페일 오버 할 수 있었다!

당초 여러 VNIC와 보조 IP를 엉망으로 만들었던 것과 보조 IP를 만드는 oci cli 명령이 좀처럼 찾지 못했기 때문에 조금 시간이 걸렸다.

시도한 것

인스턴스를 2개 만들어서 보조 IP를 설정. oci cli를 사용하여 보조 IP 장애 조치

1. 같은 서브넷에 속하는 Compute 인스턴스 2개 만들기

2. oci 사용자의 홈 디렉토리에 oci cli 명령 설치

3. 동적 그룹 만들기

instance # 1과 instance # 2가 속한 동적 그룹 만들기
다음 규칙을 설정하고 시도했습니다.

Any{instance.id='ocid1.instance.oc1.ap-tokyo-1.xxxxxxxxxxxxxxxxxxxxxxxxxx',instance.id='ocid1.instance.oc1.ap-tokyo-1.xxxxxxxxxxxxxxxxxxxxxxxxxx'}

4. 정책 만들기

특정 구획 내에서 private-ip manage 및 인스턴스 VCN에 대한 use 권한 부여
동적 그룹에 대해 다음 정책을 설정하고 시도했습니다.

allow dynamic-group <動的グループ名> to manage private-ip in compartment <コンパートメント名>
allow dynamic-group <動的グループ名> to use virtual-network-family in compartment <コンパートメント名>
allow dynamic-group <動的グループ名> to use instance-family in compartment <コンパートメント名>

5.private-ip를 설정하는 스크립트 만들기

두 노드 모두 다음 스크립트를 작성하고 시도했습니다.
private-ip를 작성/이동한 것만으로는 OS 레벨에서 IP가 설정되지 않으므로 별도의 ip 명령으로 설정해 줘야 한다.

#!/bin/bash


HOST1=instance1 # instance#1のホスト名
HOST2=instance2 # instnace#2のホスト名
VIP_ADDR=172.16.2.10 # セカンダリIP
VIP_NETMASK=24       # セカンダリIPのネットマスク
DEVNAME=ens3:0       # セカンダリIPのインタフェース名

case $(hostname -s) in
    "${HOST1}")
        # instance#1のVNIC OCID
        VNIC_OCID=ocid1.vnic.oc1.ap-tokyo-1.xxxxxxxxxxxxxxxxxxxxxxx
        ;;
    "${HOST2}")
        # instance#2のVNIC OCID
        VNIC_OCID=ocid1.vnic.oc1.ap-tokyo-1.xxxxxxxxxxxxxxxxxxxxxxx
        ;;
esac

oci --auth instance_principal network vnic assign-private-ip \
    --vnic-id ${VNIC_OCID}\
    --ip-address ${VIP_ADDR}\
    --unassign-if-already-assigned

if [[ ${?} -ne 0 ]]; then
    echo "oci cli command Error"
    exit 1
fi

sudo ip addr add ${VIP_ADDR}/${VIP_NETMASK} dev ${DEVNAME} label ${DEVNAME}
if [[ ${?} -ne 0 ]]; then
    echo "ip command Error"
    exit 1
fi

exit 0

6. 다른 호스트에서 부여한 private ip에 ssh하여 호스트 이름을 얻습니다.

※SSH 패스스루 인증 설정
※host 키가 바뀌어, ssh 접속시 WARNING이 나오기 때문에, StrictHostKeyChecking을 no로 해, 표준 에러를 null로 하고 있다

$ VIP=172.16.2.10 # セカンダリIPを指定
$ while true
  do
  echo -n "$(date '+%Y/%m/%d %H:%M:%S') : "
  ssh -o StrictHostKeyChecking=no -o UpdateHostKeys=yes ${VIP} hostname -s 2>/dev/null
  sleep 1
  done

7. 작성한 스크립트를 실행하여 개인 IP를 이동합니다.

2019/12/04 01:51:36 : instance1
2019/12/04 01:51:37 : instance1
2019/12/04 01:51:38 : instance1
2019/12/04 01:51:40 : instance1
★ ここで切り替わる
2019/12/04 01:51:41 : instance2
2019/12/04 01:51:43 : instance2
2019/12/04 01:51:44 : instance2

스크립트를 실행하면 private ip는 F/O하지만 OS 레벨에서 F/O 원래 IP 설정은 남아 있습니다. 그래도 문제없이 통신할 수 있는 것은, 가상 네트워크의 제어측에서 Private IP와 MAC 주소의 대응을 바꾸어 주고 있기 때문일까. .

→ arp 캐시와 tcpdump를 취하고 있으면, arp 캐시 엔트리는 변함없이. echo request의 목적지 MAC과 echo reply의 소스 MAC이 다른 패턴을 볼 수 있으므로 가상 네트워크 제어 측에서 MAC 프레임을 다시 쓰고 있을지도 모른다.

tcpdump

09:00:39.473785 02:00:17:00:75:07 > 02:00:17:00:5e:18, ethertype IPv4 (0x0800), length 98: 172.16.1.2 > 172.16.1.20: ICMP echo request, id 29651, seq 1016, length 64
09:00:39.474351 02:00:17:00:49:b2 > 02:00:17:00:75:07, ethertype IPv4 (0x0800), length 98: 172.16.1.20 > 172.16.1.2: ICMP echo reply, id 29651, seq 1016, length 64
★ F/O
09:00:40.497816 02:00:17:00:75:07 > 02:00:17:00:5e:18, ethertype IPv4 (0x0800), length 98: 172.16.1.2 > 172.16.1.20: ICMP echo request, id 29651, seq 1017, length 64
→ echo requestの宛先MACは02:00:17:00:5e:18 (F/O元)
09:00:40.498566 02:00:17:00:49:b2 > 02:00:17:00:75:07, ethertype IPv4 (0x0800), length 98: 172.16.1.20 > 172.16.1.2: ICMP echo reply, id 29651, seq 1017, length 64
→ echo replyの送信元MACは02:00:17:00:49:b2 (F/O先)
09:00:41.521801 02:00:17:00:75:07 > 02:00:17:00:5e:18, ethertype IPv4 (0x0800), length 98: 172.16.1.2 > 172.16.1.20: ICMP echo request, id 29651, seq 1018, length 64
09:00:41.522357 02:00:17:00:49:b2 > 02:00:17:00:75:07, ethertype IPv4 (0x0800), length 98: 172.16.1.20 > 172.16.1.2: ICMP echo reply, id 29651, seq 1018, length 64