서버 주소와 이름 해석

#핵심 요약

Oracle 접속 장애는 tnsnames.ora를 열기 전에 서버 IP, 기본 경로, 호스트명, 그 이름이 어떤 IP로 해석되는지를 먼저 확인함

/etc/hosts는 이름과 IP를 직접 적는 파일이고, /etc/nsswitch.conf의 hosts: files dns는 이 파일을 DNS보다 먼저 본다는 뜻임

getent hosts 이름은 이름 해석만, ping은 도달성까지 보며, 둘 다 리스너 포트가 열렸다는 뜻은 아님

DB 서버는 정적 IP를 쓰며 nmcli로 주소, 게이트웨이, DNS를 정하고, VM을 복제했다면 호스트명, MAC, UUID 중복을 확인함

#개념과 동작 원리

ip route의 <대역>/24 dev enp0s3는 같은 대역으로는 직접 나간다는 뜻이고, default via <GATEWAY>는 그 밖의 모든 목적지를 게이트웨이에 넘긴다는 뜻임
게이트웨이는 지금 네트워크를 벗어날 때 거치는 출입구(집에서는 공유기)이며, 그 뒤 경로는 게이트웨이와 다음 라우터들이 이어서 처리함

같은 대역의 클라이언트가 붙지 못하면 IP, 방화벽, 리스너를, 다른 대역에서 붙지 못하면 게이트웨이, 라우팅, 중간 방화벽까지 봄

#필수 명령어 또는 SQL

#IP, 경로, 호스트명 확인과 변경

ip addr
ip -br addr
ip route
hostname
hostnamectl

hostnamectl set-hostname <HOST1>
hostname
hostnamectl --static
cat /etc/hostname

결과 해석:

lo는 자기 자신을 가리키는 루프백이며, 리스너가 localhost에만 열렸는지 실제 IP에 열렸는지 가를 때 이 구분이 필요함

/24는 서브넷 마스크를 줄여 쓴 것이며, 같은 x.x.x.0/24 대역끼리는 게이트웨이 없이 통신함

hostname 새이름은 재부팅하면 돌아갈 수 있어 영구 변경은 hostnamectl set-hostname으로 하고 /etc/hostname에 남았는지 확인함

호스트명은 리스너, 네트워크 설정, 백업 스크립트, 모니터링, Data Guard 구성에서 계속 참조되므로 설치 초기에 정하고 함부로 바꾸지 않음

#/etc/hosts 작성과 이름 해석 확인

cp -p /etc/hosts /etc/hosts.bak_$(date +%Y%m%d_%H%M)
vi /etc/hosts

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
<IP_DB01>   <HOST1_FQDN> <HOST1>
<IP_DB02>   <HOST2_FQDN> <HOST2>

getent hosts <HOST1>
getent hosts <HOST2>
ping -c 2 <HOST2>
grep "^hosts" /etc/nsswitch.conf
cat /etc/resolv.conf
nmcli dev show enp0s3 | grep -E "IP4.DNS|IP4.DOMAIN"
getent hosts unknown-db
echo $?

결과 해석:

한 줄은 IP, 대표 이름, 별칭 순서이며 짧은 이름과 FQDN을 함께 적는 경우가 많음
수정 전에는 cp -p로 권한, 시각을 보존해 백업함

hosts: files dns myhostname이면 /etc/hosts에서 먼저 찾고 없을 때 DNS에 물음
그래서 /etc/hosts에 잘못된 값이 있으면 DNS가 맞아도 이 서버만 엉뚱한 IP로 감

getent가 아무것도 출력하지 않고 종료 코드 2를 돌려주면 이름을 찾지 못한 것임

NetworkManager가 관리하는 환경에서는 /etc/resolv.conf를 직접 고치기보다 nmcli로 DNS를 정함

RAC, Data Guard처럼 서로 이름으로 통신하는 서버는 모든 서버의 /etc/hosts를 같은 기준으로 맞추고, 각 서버에서 getent hosts <HOST1> <HOST2>가 같은 결과를 내는지 확인함
한쪽만 고치면 한 방향 접속만 되는 상황이 생김

#nmcli로 정적 IP 설정

nmcli device status
nmcli connection show
nmcli connection show enp0s3 | grep -E "ipv4.method|ipv4.addresses|ipv4.gateway|ipv4.dns"
ls /etc/sysconfig/network-scripts/

nmcli connection modify enp0s3 \
  ipv4.method manual \
  ipv4.addresses <IP>/24 \
  ipv4.gateway <GATEWAY> \
  ipv4.dns "<DNS_IP>" \
  connection.autoconnect yes
nmcli connection down enp0s3
nmcli connection up enp0s3
ip -br addr show enp0s3
ip route

결과 해석:

NAME은 NetworkManager의 연결 프로필 이름, DEVICE는 실제 네트워크 카드이며 둘이 늘 같지는 않음
실습 VM에서는 enp0s8처럼 DEVICE가 --인, 연결되지 않은 프로필도 보임

DB 서버는 클라이언트, 리스너, 백업, 모니터링, Data Guard 상대가 모두 주소를 기억하므로 DHCP가 아닌 정적 IP를 씀

게이트웨이는 같은 대역 안의 주소여야 함
수업의 고정 IP 메모는 /24 주소와 다른 대역의 게이트웨이를 함께 적어 두어, 그대로 쓰면 기본 경로가 동작하지 않을 수 있음

OL 7에는 /etc/sysconfig/network-scripts/ifcfg-* 파일도 있지만 NetworkManager가 최종 관리하는 경우가 많아, 파일을 고쳤다면 nmcli connection reload와 up으로 적용 상태를 확인함

down 순간 원격 세션이 끊기므로 운영 서버에서는 콘솔 수단, 변경 전 설정 백업, 되돌리는 명령을 준비하고 함

#VM 복제 뒤 확인할 것

hostnamectl set-hostname으로 배정받은 호스트명으로 바꾸고 /etc/hostname을 확인함

/etc/hosts에 자기 IP와 호스트명을 등록함
Grid, ASM 설치에서 필수임

복제할 때 새 MAC 주소를 만들지 않으면 같은 MAC으로 IP 충돌이 날 수 있으며, ip neigh로 같은 대역 이웃의 IP, MAC을 볼 수 있음

ifcfg-* 파일에 원래 VM의 UUID가 남아 있으면 지움

#tnsnames.ora의 HOST와 이름 해석

cat tnsnames.ora
getent hosts <HOSTNAME>
vi listener.ora
lsnrctl stop
lsnrctl start
tnsping ORCL2
sqlplus scott/<PASSWORD>@orcl2

결과 해석:

tnsnames.ora의 HOST = <HOST1>은 문자열일 뿐이고, 접속 순간 OS가 이 이름을 IP로 바꿈
그래서 접속 장애 때는 getent hosts <HOST1>로 해석 결과를 반드시 봄

실습은 호스트명을 <HOST>처럼 바꾼 뒤 /etc/hosts, listener.ora, tnsnames.ora의 HOST를 모두 새 이름으로 고치고 tnsping과 접속으로 확인함
리스너 설정을 고친 뒤에는 리스너를 다시 올려야 반영됨

실습 기록: tnsping ORCL2가 확인(10밀리초)로 응답하고 scott으로 접속됨
짝꿍 서버의 이름을 /etc/hosts에, 별칭을 tnsnames.ora에 넣어 다른 서버의 DB에도 접속함

이름을 바꾼 뒤 예전 이름이 /etc/hosts나 tnsnames.ora, 스크립트, 모니터링 설정에 남아 있으면 접속 장애가 남

#접속 장애 1차 점검과 기록

mkdir -p /root/netcheck
REPORT=/root/netcheck/net_$(date +%Y%m%d_%H%M%S).txt
{
echo "===== DATE ====="; date
echo "===== HOSTNAME ====="; hostnamectl --static
echo "===== IP ADDR ====="; ip -br addr
echo "===== IP ROUTE ====="; ip route
echo "===== NSSWITCH HOSTS ====="; grep "^hosts" /etc/nsswitch.conf
echo "===== RESOLV.CONF ====="; cat /etc/resolv.conf
echo "===== HOSTS ====="; cat /etc/hosts
} > "$REPORT"
ls -l /root/netcheck

결과 해석:

점검 순서: 서버 IP(ip addr) → HOST 이름이 맞는 IP로 해석되는지(getent hosts) → 그 IP까지 닿는지(ping) → 리스너 포트가 열렸는지(ss, telnet) → 리스너가 서비스를 아는지(lsnrctl status)

"이름을 아예 못 찾음", "잘못된 IP로 찾음", "이름은 맞는데 닿지 않음"을 나눠 봐야 같은 접속 오류 메시지로 보이는 원인을 가를 수 있음

네트워크 상태는 시간이 지나면 바뀌므로 점검 결과를 시각과 함께 파일로 남겨 두면 "어제는 됐다"는 상황에서 비교 기준이 됨
포트와 방화벽 점검은 포트와 방화벽에서 이어서 다룸

#사용 조건과 주의사항

nmcli connection down, IP 변경, /etc/hosts, 리스너 HOST 변경은 운영 중인 접속을 끊을 수 있으므로 작업 시간과 되돌리는 방법을 정하고 함

ping이 막힌 네트워크(ICMP 차단)도 많으므로 ping 실패만으로 서버가 꺼졌다고 판단하지 않음