안녕하세요 MANVSCLOUD 김수현입니다.
네이버 클라우드 서버에서 route PRINT(Windows) 또는 route -n(Linux) 명령어를 사용하여 라우트 설정을 보면 169.254.0.0/16 대역을 확인할 수 있습니다.
오늘은 이 대역이 네이버 클라우드에서 어떻게 사용되고 있는지 그리고 이것이 왜 필요한지에 대한 내용을 준비했습니다.
169.254.0.0/16
네이버 클라우드의 내부 네트워크는 이 169.254.0.0/16 대역을 사용하여 특정 서비스에 대한 접근을 관리하고 있습니다. 이 주소는 일반적으로 링크-로컬 주소로 사용되는 대역인데 네이버 클라우드에서는 이러한 설정으로 관리 대역과 서버 간 네트워크 트래픽을 효율적으로 관리하고 특정 서비스에 대한 접근을 빠르고 안정적으로 유지하기 위해 사용하고 있습니다.
[root@manvscloud ~]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.0.31.1 0.0.0.0 UG 0 0 0 eth0 10.0.31.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
대표적으로 Cloud Insight의 Collector는 collector.nsight.ncloud.com (169.254.80.17) IP와 통신하며 Cloud Insight의 API는 nsight.ncloud.com (169.254.80.16), 네이버 클라우드의 DNS 서버 (169.254.169.53,54) 등이 존재합니다.
만약 169.254.0.0/16 대역을 라우팅 설정에서 제거하게 된다면 어떤 일이 발생할까요?
답은 간단합니다. 네이버 클라우드 내부 관리 서비스들과 통신이 정상적으로 이루어지지 않을 것입니다.
🚧 주의 : 169.254.0.0/16 대역에 대한 설명은 VPC 환경만 해당됩니다.
Classic 환경은 10.0.0.0/8 대역이 사용되고 있습니다.
ex) Classic 환경의 Cloud Insight API는 repo-nsight.ncloud.com (10.213.208.165)로 VPC와 다르다.
Case
최근에 겪었던 사례를 통해 이 내용을 좀 더 명확히 알아보겠습니다.
네이버 클라우드의 Windows 서버는 서버 이미지 생성 후 해당 서버 이미지로 서버를 생성할 때 sysprep 작업, administrator의 패스워드 변경, 라우팅 설정 등이 이루어지는 초기화 스크립트가 동작합니다.
하지만 운영 중이던 Windows 서버의 이미지를 사용하여 서버를 추가로 생성했을 때 문제가 발생했습니다. 서버가 정상적으로 부팅되지 않았고 원격 접속을 통해 서버에 접속할 수 없었습니다. 또한 해당 서버의 관리자 비밀번호도 콘솔에서 확인할 수 없는 상태였습니다.
단, 콘솔에서 [서버 접속 콘솔] 화면에서는 서버가 정상적으로 부팅된 화면으로 보였기에 이를 해결하기 위해 아래와 같은 트러블 슈팅을 진행했습니다.
1) 다시 이미지를 생성하여 해당 이미지로 서버 재생성 시도
→ 동일하게 정상 부팅 실패
2) 콘솔에서 [서버 접속 콘솔]에서 기존 서버의 패스워드로 접속 시도
→ 기존 서버 패스워드로 접속 성공
3) 접속된 신규 서버 및 기존 서버에서 route를 확인하여 169.254.0.0/16 대역 확인
→ 정상적으로 적용 상태
4) 접속된 신규 서버 및 기존 서버에서 Xen Agent 확인
→ 서비스 정상
5) whoami /user 명령어로 SID 확인
→ 기존 서버와 신규 서버의 SID가 동일
여기서 알 수 있었던 것은 이미지로 서버 생성 시 초기화 작업이 진행되지 않았다는 점입니다. 이미지로 서버 생성 시 init.ncloud.com 도메인의 특정 URL 접근이 필요한데 이 부분이 진행되지 않은 것으로 보여 해당 도메인으로 Ping을 진행하였습니다.
원래 169.254 대역의 IP가 나와야하는데 원본 서버 및 신규 생성된 서버에서 10.250 대역으로 Ping이 가는 것이 확인되었고 DNS 설정이 변경되었음을 예측할 수 있었으며 이후 네이버 클라우드의 기본 DNS 서버로 변경하고 정상적으로 이미지 생성 및 서버 생성을 진행할 수 있었습니다.
원인을 찾는데 그리 오랜 시간이 걸리지는 않았습니다. 하지만 오늘 포스팅 내용과 같이 어느정도 네이버 클라우드에 대한 이해도가 없었다면 원인을 모른채 헤맸을 것같아 이렇게 공유하게 되었습니다.
참고로 저와 같이 트러블 슈팅을 하며 고민하고 하나씩 해결해 나가는 것이 어렵게 느껴지거나 시간이 아깝다면 위 상황에서는 NTK(Ncloud Tool Kit)을 이용하여 원본 서버를 점검하면 빠른 원인 파악에 도움이 될 것입니다.
- Ncloud Tool Kit(Windows) : https://guide.ncloud-docs.com/docs/ncloud-tool-kit-windows
- Ncloud Tool Kit(Linux) : https://guide.ncloud-docs.com/docs/server-ntk
Personal Comments
네이버 클라우드에서 일어나는 일련의 네트워크 흐름을 이해하고 있다면 운영 상 발생하는 문제를 원활하게 해결할 수 있을 것이며 Ncloud Tool Kit와 같이 유용한 툴을 적절히 사용하여 문제 상황에 더 빠르게 대응할 수 있을 것입니다.
긴 글 읽어주셔서 감사합니다.
