13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] Placement

  • 홈랩 DevStack 설치기 (2) — Neutron·Glance·Placement 연속 삽질과 원인 분석

    지난 편에서 CPU 함정을 넘었습니다. 하지만 그건 시작이었습니다. DevStack이 완주할 때까지 Neutron → Glance → Nova/Placement에서 연달아 막혔거든요. 이번 편은 그 실제 에러들과 원인, 그리고 관통하는 하나의 패턴을 정리합니다. 같은 벽을 만난 분께 지도가 되길 바랍니다.

    벽 2. 테넌트 네트워크 생성 실패 (503)

    다시 돌리자 이번엔 네트워크 생성에서 죽었습니다.

    HttpException: 503: No project network is available for allocation.

    OVN 기본 구성에서 테넌트 네트워크는 geneve를 쓰는데, ml2 설정에 tenant_network_types가 geneve로 잡혀있지 않았습니다. local.conf에 명시했습니다.

    [[local|localrc]]
    Q_ML2_TENANT_NETWORK_TYPE=geneve
    
    [[post-config|/$Q_PLUGIN_CONF_FILE]]
    [ml2]
    tenant_network_types = geneve
    [ml2_type_geneve]
    vni_ranges = 1:65536
    max_header_size = 38

    벽 3. geneve 할당 테이블이 비어 있다

    설정을 고쳤는데도 같은 503. DB를 열어보니 결정적 단서가 있었습니다.

    mysql -e "SELECT COUNT(*) FROM neutron.ml2_geneve_allocations;"
    # 0   ← geneve 세그먼트가 하나도 없음!

    neutron 로그엔 Non allocated segments: {}. 즉 neutron이 시작할 때 geneve 세그먼트 풀을 동기화하지 못한 겁니다. 설정은 맞는데 타이밍 문제였죠. 해결은 단순하지만 의외였습니다 — neutron을 한 번 재시작하니 —

    sudo systemctl restart [email protected]
    mysql -e "SELECT COUNT(*) FROM neutron.ml2_geneve_allocations;"
    # 65536   ← 재시작하자 채워짐!
    openstack network create testnet   # status: ACTIVE 

    재시작만으로 geneve 풀이 채워지고 네트워크가 생성됐습니다.

    벽 4. Glance 엔드포인트가 “버전 없음”

    다음은 이미지 서비스. openstack image list가 이렇게 뱉었습니다.

    The image service exists but does not have any supported versions.

    그런데 g-api 프로세스는 active(정상)였습니다. 즉 프로세스는 떴는데 프록시(apache) 엔드포인트가 안 열린 상태. neutron과 똑같은 패턴이라 똑같이 재시작했습니다.

    sudo systemctl restart apache2
    sudo systemctl restart [email protected]
    curl -s http://192.168.x.x/image/ | head -c 80
    # {"versions": [{"id": "v2.18", "status": "CURRENT" ...   ← 이제 열림

    재시작 후 cirros 이미지 업로드도 정상(active)이 됐습니다.

    벽 5. “No valid host” — placement에 자원 클래스가 없다

    서비스·네트워크·이미지가 다 됐는데 인스턴스가 ERROR. 이유는 “No valid host was found”. 하이퍼바이저는 up인데 왜? nova-compute 로그가 진짜 원인을 보여줬습니다.

    400 Bad Request: Unknown resource class in inventory ...
    No such resource class MEMORY_MB.

    즉 placement DB에 표준 자원 클래스(MEMORY_MB·VCPU·DISK_GB)가 로드되지 않아서, nova-compute가 자원 인벤토리를 placement에 등록하지 못했습니다. 인벤토리가 없으니 스케줄러가 “쓸 수 있는 호스트 없음”으로 판단한 거죠.

    관통하는 하나의 패턴

    벽 3·4·5를 보면 공통점이 보입니다.

    서비스 프로세스는 떠 있는데, 그 뒤에 와야 할 “초기화·동기화·등록”이 안 끝나 있다.

    geneve 풀 동기화, glance 엔드포인트, placement 자원 클래스 — 전부 stack.sh가 끝까지 완주하며 해줬어야 할 마무리 단계입니다. 제 경우 stack.sh가 중간에 여러 번 죽으면서 이 마무리들이 제각각 미완성으로 남았고, 그래서 재시도할 때마다 “부분적으로만 살아있는” 상태가 겹쳐 새 증상이 계속 튀어나온 겁니다.

    여기서 배운 교훈: DevStack은 “깨끗한 상태에서 한 번에 완주”가 생명입니다. 중간 실패 후 그 위에 계속 재시도하면, 서로 다른 실행의 잔재가 섞여 디버깅이 미궁에 빠집니다. 다음 편에서 이 교훈과 현실적인 후기를 정리하겠습니다.