MPP 로 구성된 CAS 서버에서 워커 노드를 빼는 순서다. 순서를 지키지 않으면 컨트롤러가 없는 노드를 계속 기다린다.
inventory.ini 에서 [sas_casserver_worker] 항목의 해당 호스트를 지운다.site.yml 을 실행한다. 이 플레이북은 SAS Viya 전체를 정지했다가 다시 올린다. 서비스 중단 시간을 확보하고 돌린다.ansible-playbook -i inventory.ini site.yml
cat /opt/sas/viya/config/etc/cas/default/cas.hosts
site.yml 실패 메시지나 검증 단계에 8777 이 등장한다. 이 포트는 CAS 컨트롤러의 HTTP · REST 포트이고, 설정 키는 cas.HTTPPORT 다. 고정값이 아니라 설정으로 바뀔 수 있다.
grep -i httpport /opt/sas/viya/config/etc/cas/default/casconfig_usermods.lua
여기서 중요한 것은 해석이다.
8777 connection refused 는 원인이 아니라 결과인 경우가 대부분이다.
CAS 컨트롤러가 뜨지 못하면 8777 이 열리지 않고, 그 뒤 검증 단계가 8777 접속에 실패한다. 포트 설정을 뒤지기 전에 컨트롤러가 왜 안 떴는지를 본다.
ss -lntp | grep 8777
systemctl status sas-viya-cascontroller-default --no-pager -l
ls -ltr /opt/sas/viya/config/var/log/cas/default/
tail -200 /opt/sas/viya/config/var/log/cas/default/*
에러 본문에서 실패한 태스크 이름이 8777 이라는 숫자보다 중요하다.
grep -n -A5 -B10 -i "failed\|fatal" deployment.log
실패 태스크가 인증서 생성, 호스트 도달성, 템플릿 렌더링, CAS 기동, 잔존 호스트 정리 중 무엇인지에 따라 대응이 완전히 달라진다.
파일에서 주석 처리했다고 끝이 아니다. 다른 인벤토리 파일이 포함돼 있거나 group_vars 가 호스트를 다시 넣을 수 있다.
ansible-inventory -i inventory.ini --list
grep -R "<제거한호스트명>" /opt/sas/viya/config /sas/install/playbook
Ansible 로그에 제거한 호스트로 SSH 를 시도하는 줄이 보이면 인벤토리 해석 결과에 아직 남아 있는 것이다.
<worker-hostname> SSH EXEC ...
Broken pipe
다만 반대 경우도 있다. 로그에 뜬 호스트가 제거 대상이 아닌 다른 노드일 수 있다. 로그에 보이는 호스트명을 실제 제거 목록과 한 글자씩 대조한 뒤에 결론을 낸다.
워커 제거 뒤 site.yml 이 전에 10초 걸리던 구간에서 수 분씩 머무는데, 다른 서버로 가는 태스크는 빠르고 자기 자신을 대상으로 하는 단계만 느린 경우가 있다. 이름 해석과 권한 상승이 원인인 경우가 대부분이다.
hostname; hostname -f
time getent hosts $(hostname -f)
time nslookup $(hostname -f)
cat /etc/hosts
/etc/hosts 에 자기 FQDN 이 없거나, 제거한 워커가 DNS · /etc/hosts 에 남아 역방향 조회가 타임아웃까지 가는 경우다. 최소한 자기 자신에 대한 매핑은 넣어 둔다.
<서버IP> <호스트명> <호스트명>.<도메인>
time sudo -l
time sudo id
time sudo /bin/true
sudoers 의 FQDN 옵션, PAM · SSSD · LDAP 질의 지연이 여기서 드러난다. sudo 한 번이 수 초 걸리면 태스크 수만큼 곱해져 전체가 느려진다.
제거한 워커가 /etc/hosts, known_hosts, Consul 서비스 등록 어딘가에 남아 있으면 매 단계에서 연결을 시도하다 타임아웃한다.
grep -R "<제거한호스트명>" /etc/hosts ~/.ssh/known_hosts
inventory.ini · cas.hosts 를 모두 정리한 뒤에도 남았던 8777 관련 실패의 최종 원인을 확정하지 못했다. CAS 컨트롤러 기동 실패 쪽으로 좁혔으나 컨트롤러 로그로 확인하는 단계까지 가지 못했다.