배포 검증하기
Calico 기반 OpenStack 배포가 트래픽을 올바르게 포워딩하고 정책을 제대로 적용하는지 확인하는 절차를 소개해요. 인스턴스 배치, 컴퓨트 노드의 FIB, VM 연결성까지 순서대로 점검해요. 배포 직후 한 번, 그리고 구성을 바꾼 뒤에 다시 돌려보면 좋아요.
출처: 문서
본문
이 문서는 Calico 기반 OpenStack 배포가 올바르게 동작하는지 확인하기 위해 수행할 수 있는 절차를 안내해요.
사전 준비
이 문서를 따르려면 다음 것들이 필요해요:
- Calico 기반 OpenStack 배포의 노드에 SSH로 접근할 수 있어야 해요.
- Calico 기반 OpenStack 배포의 관리자 계정에 접근할 수 있어야 해요.
절차
관리자 계정을 사용해서 OpenStack 배포에 인스턴스를 여러 개 만드는 것부터 시작해요. 이 인스턴스들이 모두 기동되고 IP 주소를 올바르게 받는지 확인하세요.
새 인스턴스들이 하이퍼바이저에 골고루 분산됐는지도 확인하고 싶을 거예요. 컨트롤 노드에서 다음을 실행해요:
nova list --fields host
컴퓨트 노드에 걸쳐 균등하게 분산됐는지 확인하세요. 그렇지 않다면 해당 컴퓨트 노드의 nova나 Calico에서 오류가 발생했을 가능성이 커요. 해당 노드의 로그를 확인해 보고, 어려움을 겪고 있다면 메일링 리스트에 알려주세요.
이제 컴퓨트 노드 중 하나에 SSH로 접속해요. 컴퓨트 노드의 FIB가 Calico에 의해 올바르게 채워졌는지 검증할 거예요. 그러려면 route 명령을 실행해요. 다음과 비슷한 출력이 나올 거예요:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default net-vl401-hsrp- 0.0.0.0 UG 0 0 0 eth0
10.65.0.0 * 255.255.255.0 U 0 0 0 ns-b1163e65-42
10.65.0.103 npt06.datcon.co 255.255.255.255 UGH 0 0 0 eth0
10.65.0.104 npt09.datcon.co 255.255.255.255 UGH 0 0 0 eth0
10.65.0.105 * 255.255.255.255 UH 0 0 0 tap242f8163-08
10.65.0.106 npt09.datcon.co 255.255.255.255 UGH 0 0 0 eth0
10.65.0.107 npt07.datcon.co 255.255.255.255 UGH 0 0 0 eth0
10.65.0.108 npt08.datcon.co 255.255.255.255 UGH 0 0 0 eth0
10.65.0.109 npt07.datcon.co 255.255.255.255 UGH 0 0 0 eth0
10.65.0.110 npt06.datcon.co 255.255.255.255 UGH 0 0 0 eth0
10.65.0.111 npt08.datcon.co 255.255.255.255 UGH 0 0 0 eth0
10.65.0.112 * 255.255.255.255 UH 0 0 0 tap3b561211-dd
link-local * 255.255.0.0 U 1000 0 0 eth0
172.18.192.0 * 255.255.255.0 U 0 0 0 eth0
이 표에는 각 VM IP 주소마다 라우트가 하나씩 보여야 해요. 다른 컴퓨트 노드에 있는 VM이라면 그 컴퓨트 노드의 IP 주소(또는 도메인 이름)가 gateway로 보여요. 이 컴퓨트 노드에 있는 VM이라면 gateway가 *로 보이고, Iface 필드에 그 VM의 tap 인터페이스가 보여요. 모든 VM으로 가는 라우트가 존재하면 FIB가 올바르게 구성된 거예요. 라우팅 테이블에서 VM이 빠져 있다면, 그 VM을 호스팅하는 컴퓨트 노드의 BGP 연결 상태를 확인해 보세요.
FIB가 존재하고 올바른지 확인했으면, 방금 만든 VM 인스턴스 중 하나의 콘솔을 열어요. google.com(또는 라우팅이 되고 ping에 응답할 거라고 확신하는 다른 호스트)에 ping을 보내서 외부 연결성을 확인하세요. 또 생성해 둔 다른 인스턴스에(IP로) ping을 보내서 내부 연결성도 확인하세요.
이 테스트들이 모두 정상 동작하면 Calico 기반 OpenStack 배포는 건강한 상태예요.
문제 해결
아래 조언 중 어느 것도 문제를 해결하지 못한다면, 진단 수집 스크립트로 진단 정보를 생성한 뒤 우리 저장소에 GitHub 이슈를 등록해 주세요. 진단 정보를 생성하려면 다음을 실행해요:
/usr/bin/calico-diags
VM이 DHCP를 받지 못함
iptables가 INPUT 또는 FORWARD 체인에 기본 DROP 동작을 설정한 경우에 일어날 수 있어요. iptables -L -t filter를 실행하고 출력을 확인해서 테스트할 수 있어요. 다음과 비슷한 출력이 보여야 해요:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
중요한 부분은 Chain INPUT과 Chain FORWARD예요. 이 두 체인 모두 정책(policy)이 ACCEPT여야 해요. 일부 시스템에서는 이 정책이 DENY로 설정되어 있을 수 있어요. 바꾸려면 iptables -P <chain> ACCEPT를 실행하고 <chain>을 INPUT이나 FORWARD로 바꿔 주세요.
일부 네트워크에서는 이렇게 하는 게 보안상 위험으로 간주될 수 있다는 점에 유의하세요. 이 단계가 필요 없도록 하는 Calico 개선이 향후 예정되어 있어요.
FIB에 라우트가 없음
route를 실행했을 때 일부 VM으로 가는 라우트가 없다면 BGP 세션이 올바르게 동작하지 않는다는 뜻이에요. BGP 데몬에는 대화형 콘솔이나 로그가 있을 거예요. 해당하는 것을 열어서 모든 BGP 세션이 적절히 올라왔는지, 그리고 라우트를 복제하고 있는지 확인하세요. 풀 메시 구성을 사용 중이라면 모든 다른 Calico 노드와 BGP 세션을 구성했는지 확인하세요.
VM이 VM이 아닌 IP에 ping을 보내지 못함
FIB에 모든 라우트가 존재한다면(위 참고), 가장 흔한 원인은 게이트웨이에 VM IP 주소로 가는 라우트가 구성되어 있지 않은 거예요. Calico의 완전한 기능을 쓰려면 게이트웨이가 컴퓨트 노드(또는 라우트 리플렉터)의 BGP 피어이기도 해야 해요.
게이트웨이에 VM으로 가는 라우트가 있는지 확인하세요. 있다면, 게이트웨이가 그 라우트를 외부 피어에도 광고하고 있는지 확인하세요. eBGP로 할 수도 있지만 다른 라우팅 프로토콜을 쓰고 있을 수도 있어요.
VM이 다른 VM에 ping을 보내지 못함
계속하기 전에 두 VM이 서로의 인바운드 트래픽을 허용하는 보안 그룹에 속해 있는지(또는 둘 다 자기 자신의 인바운드 트래픽을 허용하는 같은 보안 그룹에 속해 있는지) 확인하세요. 서로의 인바운드 트래픽을 허용하지 않는 VM 사이에서는 트래픽이 라우팅되지 않아요.
보안 그룹 구성이 올바르다고 가정하면, 각 VM을 호스팅하는 머신(같은 머신일 수도 있음)이 두 VM 모두로 가는 라우트를 갖고 있는지 확인하세요. 그렇지 않다면 위의 문제 해결 섹션을 확인하세요.
웹 UI가 "Error: Unable to get quota info"와/또는 "Error: Unable to get volume limit" 오류 상자를 보여줌
OpenStack의 논리 볼륨 관리 컴포넌트인 cinder에서 디바이스 매핑 문제로 발생하는 경우가 많아요. 이런 문제 대부분은 cinder를 재시작하면 해결돼요.
service cinder-volume restart
service cinder-scheduler restart
service cinder-api restart
인스턴스를 만들 수 없고, 오류 로그에 "could not open /dev/net/tun: Operation not permitted"라고 표시됨
/etc/libvirt/qemu.conf 끝에 줄을 추가한 뒤 libvirt를 재시작하지 않아서 발생해요. 시스템 전체를 재부팅하거나 다음을 실행해서 해결할 수 있어요:
service libvirt-bin restart
더 알아보기 (Learn more)
검증의 핵심은 컴퓨트 노드 FIB에 모든 VM 라우트가 있고, VM이 외부·내부 양쪽으로 ping이 되는지 확인하는 거예요. INPUT/FORWARD 체인 정책이 ACCEPT인지도 잊지 마세요. 문제가 남으면 calico-diags로 진단 번들을 만들어 이슈로 올리는 게 가장 빠른 길이에요.