maas 트러블 슈팅

Maas

물리 노드 관리

# maas 설치과정
  sudo snap install maas-test-db
  sudo snap install maas --channel=3.3/stable
  sudo maas init region+rack --maas-url http://192.168.100.110:5240/MAAS --database-uri maas-test-db:///
  sudo maas createadmin --username admin --password ubuntu --email admin@example.com
  sudo maas apikey --username admin > ~/admin-api-key

Machine Add 이슈

  • Machine으로 등록할 모든 컴퓨터/서버 pxe 부팅 enable 및 우선순위 작업 선행되어야 함
  • 최초 Pxe Boot → New 상태로 등록될 때 Power Type 자동으로 인식함. 인식하지 못하는 경우는 Manual로 등록해서 직접 서버의 전원관리 (껐다 켰다) 해줘야함. iDRAC 확인 필요!

DHCP 설정

  • 설정 경로
    • 대시보드 → 컨트롤러 → vlan → DCHP 설정
  • DHCP 설정 시 범위 지정 고려
    • 서브넷이 관리되고 있는 경우(Managed), Maas는 Reserved로 설정한 IP Range는 절대 침범하지 않음.
    • 라우터의 DHCP 범위, Openstack의 Floating IP 범위 등으로 사용할 Range를 정하여 설정해주어야 함.
    • Dynamic 타입의 경우 Maas가 노드들을 Commission 및 Deploy하는 단계에서 사용하는 Ip. Juju를 통해 Deploy하는 경우 해당 과정에서만 사용되고, 배포되고 난 이후에는 예약되지 않은 범위의 ip를 재할당 받기 때문에 넓은 범위를 지정할 필요는 없음.
  • 설정 시 반드시 DNS 서버 설정 해야함. 안 그럴시 부팅 시 에러 (cloudinit 관련)

Dell EMC 서버 Commission(Add machine 단계) fail 이슈

  • 로그
    Unknown section `None'
  INFO: Loading IPMI kernel modules...
  INFO: Checking for HP Moonshot...
  INFO: Checking for Redfish...
  INFO: Reading current IPMI BMC values...
  INFO: Found existing IPMI user "maas"!
  INFO: Configuring IPMI BMC user "maas"...
  INFO: IPMI user number - User3
  INFO: IPMI user privilege level - Administrator
  ERROR: Redfish HTTP Error 401: Unauthorized
  Traceback (most recent call last):
    File "/tmp/user_data.sh.mMBXli/scripts/commissioning/30-maas-01-bmc-config", line 1118, in detect_and_configure
      if bmc.detected():
    File "/tmp/user_data.sh.mMBXli/scripts/commissioning/30-maas-01-bmc-config", line 1052, in detected
      return self.get_bmc_ip() is not None
    File "/tmp/user_data.sh.mMBXli/scripts/commissioning/30-maas-01-bmc-config", line 1107, in get_bmc_ip
      self._bmc_ip = self._get_bmc_ip()
    File "/tmp/user_data.sh.mMBXli/scripts/commissioning/30-maas-01-bmc-config", line 1070, in _get_bmc_ip
      response = urllib.request.urlopen(
    File "/usr/lib/python3.10/urllib/request.py", line 216, in urlopen
      return opener.open(url, data, timeout)
    File "/usr/lib/python3.10/urllib/request.py", line 525, in open
      response = meth(req, response)
    File "/usr/lib/python3.10/urllib/request.py", line 634, in http_response
      response = self.parent.error(
    File "/usr/lib/python3.10/urllib/request.py", line 563, in error
      return self._call_chain(*args)
    File "/usr/lib/python3.10/urllib/request.py", line 496, in _call_chain
      result = func(*args)
    File "/usr/lib/python3.10/urllib/request.py", line 643, in http_error_default
      raise HTTPError(req.full_url, code, msg, hdrs, fp)
  urllib.error.HTTPError: HTTP Error 401: Unauthorized
  
  INFO: Checking for IPMI...
  INFO: IPMI detected!
  INFO: Reading current IPMI BMC values...
  INFO: Configuring IPMI Lan_Channel...
  INFO: Configuring IPMI Lan_Channel_Auth...
  INFO: Lan_Channel_Auth settings unavailable!
  WARNING: No K_g BMC key found or configured, communication with BMC will not use a session key!
  INFO: Configuring IPMI Serial_Channel...
  INFO: Configuring IPMI SOL_Conf...
  INFO: Found existing IPMI user "maas"!
  INFO: Configuring IPMI BMC user "maas"...
  INFO: IPMI user number - User3
  INFO: IPMI user privilege level - Administrator
  INFO: IPMI Version - LAN_2_0
  INFO: IPMI boot type - efi
  INFO: Attempting to enable preconfigured static IP on BMC...
  ERROR: IPMI Command '['bmc-config', '--commit', '--key-pair=None:IP_Address_Source=Static']' returned non-zero exit status 1.
  Traceback (most recent call last):
    File "/tmp/user_data.sh.mMBXli/scripts/commissioning/30-maas-01-bmc-config", line 1126, in detect_and_configure
      **bmc.get_credentials(),
    File "/tmp/user_data.sh.mMBXli/scripts/commissioning/30-maas-01-bmc-config", line 660, in get_credentials
      ip_address, mac_address = self.get_bmc_ip()
    File "/tmp/user_data.sh.mMBXli/scripts/commissioning/30-maas-01-bmc-config", line 628, in get_bmc_ip
      self._bmc_set(section_name, "IP_Address_Source", "Static")
    File "/tmp/user_data.sh.mMBXli/scripts/commissioning/30-maas-01-bmc-config", line 271, in _bmc_set
      check_call(
    File "/usr/lib/python3.10/subprocess.py", line 369, in check_call
      raise CalledProcessError(retcode, cmd)
  subprocess.CalledProcessError: Command '['bmc-config', '--commit', '--key-pair=None:IP_Address_Source=Static']' returned non-zero exit status 1.
  
  INFO: Checking for Facebook Wedge...
  INFO: No BMC automatically detected!
  • 원인
    • maas 부팅 시 ipmi(전원 관련) 정보를 idrac 서버에서 가져온다.
    • 서버 장비 뒷편에 idrac 전용 랜선 포트가 있는데 이 포트에 연결해야 idrac에서 정보를 가져올 수 있음.
  • 해결
    • 랜선 2개 (기본 네트워크 용 랜선 1, idrac 용1) 연결이 필요하다.

Power Type Error

Dell 서버의 경우 Idrac 과 같은 Power Type을 얻어오는 lan 정보(ip 등)이 초기 정보와 다르게 변경 되었을 수 있다. 변경 된 정보 확인 후 Mass Controller에 해당 정보 갱신하여 해결.

  • ipmi lan 정보 확인
    sudo apt install impi tool
  sudo impitool print lan
  • 서버 impi 정보 변경
    sudo ipmitool lan set 1 ipsrc static       # IP 주소를 수동(static)으로 설정
  sudo ipmitool lan set 1 ipaddr <new_ip>    # 새로운 IP 주소 설정
  sudo ipmitool lan set 1 netmask <subnet_mask>  # 새로운 서브넷 마스크 설정
  sudo ipmitool lan set 1 defgw ipaddr <gateway_ip>  # 새로운 게이트웨이 주소 설정

Machine 상태

  • New → Commisioning → Ready → Deploy
  • Ready 단계에서의 machine 설정
    • 노드 이름, 태그 설정
    • Network → br-ex, openVswitch 브릿지 설정

Juju

각 노드에 application 배포 역할

# 설치
  sudo snap install juju --classic --channel 2.9
  # 보안
  juju add-cloud --client -f maas-cloud.yaml(만들어야함) maas-one
  juju add-credential --client -f maas-creds.yaml(만들어야함) maas-one
  # Juju Controller 노드 배포 
  juju bootstrap --bootstrap-series=jammy --constraints tags=juju maas-one maas-controller
  • maas-cloud.yaml
    clouds:
    maas-one:
      type: maas
      auth-types: [oauth1]
      endpoint: http://maas-controller IP:5240/MAAS
  • maas-creds.yaml
    # maas-oauth 는 Maas 설치 단계에서 생성한 admin-api-key
  
  credentials:
    maas-one:
      anyuser:
        auth-type: oauth1
        maas-oauth: LGJ8svffZZ5kSdeA8E:9kVM7jJpHGG6J9apk3:KE65tLnjpPuqVHZ6vb97T8VWfVB9tM3j
  • BootStrap 이후 
juju add-model --config default-series=jammy openstack
  juju switch maas-controller:openstack

Openstack Charms

참고 명령어

# 설정 변경 예시
  juju config ceph-osd osd-devices='/dev/sdb /dev/sdc'
  #조회 예시
  juju run-action ceph-osd/8 --wait restart
  #로그 계속 조회
  watch -n 5 -c juju status --color
  #특정 서비스 로그 조회
  juju debug-log --replay --include ceph-osd

Nas → Ceph Osd 활용

문제 상황 : openstack Charms 중 Ceph-osd를 배포하려면 파티션 되어있지 않은 빈 디스크가 노드당 최소 한개씩은 필요하다. 그러나, 4개의 노드에 디스크가 하나씩 밖에 없고 해당 디스크는 부팅 과정에서 이미 파티셔닝 되어서 Ceph-osd의 Osd Device로 사용하지 못하는 상태.

해결 : Synology Nas에서 Lun을 생성하여 각 노드의 Block Device로 사용.

  • Nas Lun → 리눅스 Block 스토리지 사용
# (해당 노드 juju ssh 후) Nas 서버 연결
  sudo iscsiadm --mode discoverydb --type sendtargets --portal 192.168.2.60 --discover
  
  #노드 당 Lun 연결
  node 1 : sudo iscsiadm --mode node --targetname iqn.2000-01.com.synology:infra-nas.Target-1.5495a7e60f7
  node 2 : sudo iscsiadm --mode node --targetname iqn.2000-01.com.synology:infra-nas.Target-11.5495a7e60f7 -o update -n node.startup -v automatic
  node 3 : sudo iscsiadm --mode node --targetname iqn.2000-01.com.synology:infra-nas.Target-12.5495a7e60f7
  node 4 : sudo iscsiadm --mode node --targetname iqn.2000-01.com.synology:infra-nas.Target-13.5495a7e60f7
  
  #부팅 시 자동 연결 설정
  -o update -n node.startup -v automatic
  -o update -n node.conn[0].startup -v automatic
  
  #block device 연결 확인
  lsblk
  
  #수동 로그인
  --login

재부팅 이후 Ceph-Osd Block 상태

증상 : 각 ceph-osd block 상태. list-disks 해보면 disk는 인식하지만, skipping osd devices previously processed by this unit 이런 로그 나옴.

해결 : ssh 접속 후 sudo ceph-volume lvm activate --all

Vault 이후 처리

vault init

export VAULT_ADDR="http://192.168.2.107:8200"
  # Unseal 용 키 생성
  vault operator init -key-shares=5 -key-threshold=3
  • 예시 결과 
    Unseal Key 1: CHSnzWk34pFcyU2Xll/sTU+NeJYgNMGnZ6S+9a+Mifhv
  Unseal Key 2: UJJyNMepdHm5fvqo4pPuNpLX9IPKPbhr1Dj9SPj8YWOF
  Unseal Key 3: PsdAILzwsjZtD8SjtBtYxBpQ4ywo48iBSlCdGQR64ixB
  Unseal Key 4: E3/MR4odJutnwJGD2xLsQ/0FTglW8ZkrDX3NFu++SXVH
  Unseal Key 5: iTiiWxNqGWRz+YnjGaMxFjtuVAXUuM7QeyExA1kx2bhz
  
  Initial Root Token: s.8r7ojjWIyqqzsQCJvDbuUeRj
  
  Vault initialized with 5 key shares and a key threshold of 3. Please securely
  distribute the key shares printed above. When the Vault is re-sealed,
  restarted, or stopped, you must supply at least 3 of these keys to unseal it
  before it can start servicing requests.
  
  Vault does not store the generated root key. Without at least 3 keys to
  reconstruct the root key, Vault will remain permanently sealed!
  
  It is possible to generate new unseal keys, provided you have a quorum of
  existing unseal keys shares. See "vault operator rekey" for more information.
# Unseal (3(threshold)개 이상)
  vault operator unseal CHSnzWk34pFcyU2Xll/sTU+NeJYgNMGnZ6S+9a+Mifhv
  vault operator unseal UJJyNMepdHm5fvqo4pPuNpLX9IPKPbhr1Dj9SPj8YWOF
  vault operator unseal PsdAILzwsjZtD8SjtBtYxBpQ4ywo48iBSlCdGQR64ixB
  
  export VAULT_TOKEN=s.8r7ojjWIyqqzsQCJvDbuUeRj
  vault token create -ttl=10m
  
  juju run vault/leader authorize-charm token=s.4ex7of1cqi2rY4rhWTN658oe
  • Unseal 과정 중 init 되지 않았다는 에러 발생시
    • vault status 확인
    • init=false 일 경우 init 명령어 한번 더 실행

Enable Tls

juju run vault/leader generate-root-ca

Vault Unseal Key 유실 케이스

재부팅 등의 이유로 vault 가 sealed 되어 있다면 unseal 키로 unseal 해줘야 함.
unseal 키를 유실 했다면 vault 서버를 초기화 및 재시작 후 재 init 해야함. 

juju ssh vault/0
  sudo apt install mysql-client
  sudo cat /var/snap/vault/common/vault.hcl -> pwd 확인
  
  mysql -u vault -p vault -h 127.0.0.1
  패스워드 입력
  
  drop database vault;
  exit
  
  systemctl restart vault.
  
  이후 init 과정 + tls 재시작.

Apache2.0 실패 이슈 (Cert)

  • Glance, DashBoard 에서 apache 구동 실패 하는 경우 있었음.
  • 원인 : Vault 에서 생성한 ca의 심볼릭 링크가 안걸림
  • 해결 1 (dashboard는 이걸로 해결됐으나 Glance, Cinder는 해결 안됨)
    juju run-action --wait vault/0 reissue-certificates (Maas Controller)
  
  systemctl restart apache2.service (에러 발생한 lxd 내부)
  • 해결 2

    위와 같이 심볼릭 링크가 걸려있어야 하나, 걸려있지 않았음. 

    # glance lxd 내부 /etc/apache2/ssl/glance
  #심볼릭 링크 생성
  (glance)
  ln -s /etc/apache2/ssl/glance/cert_juju-0c4b28-3-lxd-3.maas cert_192.168.100.113
  ln -s /etc/apache2/ssl/glance/key_juju-0c4b28-3-lxd-3.maas key_192.168.100.113
  
  (cinder)
  ln -s /etc/apache2/ssl/cinder/cert_juju-0c4b28-1-lxd-4.maas cert_192.168.100.117
  ln -s /etc/apache2/ssl/cinder/key_juju-0c4b28-1-lxd-4.maas key_192.168.100.117
  
  systemctl restart apache2.service (에러 발생한 lxd 내부)

재부팅 이슈

  1. mysql cluster → leader(로 추정되는) 노드 까지 껏다 키니 해결
    • juju 2.9 기준
      • 재부팅 또는 각 노드에 대해 juju run-action --wait mysql-innodb-cluster/leader reboot-cluster-from-complete-outage
        • 리더 유닛 정상 실행 되면 일정 시간 후에 slave 유닛들도 정상화됨.
    • juju 3.1 기준
      • 아무 mysql 클러스터 노드에 대해 juju run mysql-innodb-cluster/1 reboot-cluster-from-complete-outage 실행
      • 한번에 성공하거나 아래와 같은 에러 발생 
        RuntimeError: Dba.reboot_cluster_from_complete_outage: The active session instance (10.0.0.208:3306)
  isn't the most updated in comparison with the ONLINE instances of the Cluster's metadata.
  Please use the most up to date instance: '10.0.0.218:3306'.
        • 위 에러 발생시 로그에 출력된 ip (10.0.0.208)에 해당하는 유닛으로 다시한번 실행
          • juju run mysql-innodb-cluster/0 reboot-cluster-from-complete-outage
  1. vault → vault 서비스 inactive 및 vault sealed 되어있었음
    • vault/0 ssh 후 vault.service restart
    • unseal 후 기다리면 정상화
  1. ceph-osd → nas ip 바뀜, 등록된 osd 재부팅 후 inactivate 상태였음
    • nas lun 재연결
    • ssh 접속 후 노드별 osd activate 후 해결
    • 자동화 설정 추가해서 해결
  • 현재 설정 상 명령어(osd는 재부팅 후 자동실행 처리 했다고 가정)
    # Mysql 클러스터 복구
  juju run-action --wait mysql-innodb-cluster/leader reboot-cluster-from-complete-outage
  
  #Vault 복구(Unseal) - Mysql 관련 유닛 Active 상태 확인 후 진행
  export VAULT_ADDR="http://192.168.100.120:8200"
  
  juju ssh vault/0
  sudo systemctl restart vault.service
  exit
  
  vault operator unseal JoWo2xPQOWFX4Q5hxUG0v08uvbWjifsHs3m5yVyxjLXY
  vault operator unseal lkx5PtwJLihoA3MLyt2HL03+SBS1gm93psqdfoPPH1H3
  vault operator unseal 2Ovzneb6nHejAFNw5rh34C9aNSUkiZaSHyqAJ+kSa6Zr

Openstack 설정

이미지 생성

https://download.rockylinux.org/pub/rocky/8/images/x86_64/Rocky-8-GenericCloud-Base.latest.x86_64.qcow2 -O rocky8.qcow2

openstack image create --public --container-format bare \
     --disk-format qcow2 --file ~/cloud-images/rocky8.qcow2 \
     rocky8

네트워크 생성p

openstack subnet create --network user1_net --dns-nameserver 192.168.100.10 \
     --subnet-range 10.0.2.0/24 \
     --allocation-pool start=10.0.2.10,end=10.0.2.199 \
     admin_subnet
openstack router create user1_router
  openstack router add subnet user 1_router user1_subnet
  openstack router set user1_router --external-gateway ext_net

인스턴스 생성

openstack server create --image rocky8 --flavor m1.tiny \
     --key-name user1 --network user1_net --security-group Allow_SSH \
     rocky8
FLOATING_IP=$(openstack floating ip create -f value -c floating_ip_address ext_net)
  openstack server add floating ip rocky8 $FLOATING_IP

타 서브넷 정적 라우팅(Cisco rv340 문제)

  • 상황
    • Mass & Openstack Cluster ⇒ 192.168.100.0/24 대역
      • 100.0 대역 라우터의 wan 포트 ↔ 1.0 대역 라우터의 lan 포트 서로 연결
      • 100.0 대역 네트워크는 1.0 대역 및 1.0 라우터를 통한 인터넷 통신 가능
    • 사내 사용되고 있는 네트워크 대역 ⇒ 192.168.0.0, 1.0, 2.0 대역 존재
      • 현재 3개의 네트워크에서는 100.0 대역 접근 불가 → 접근 되도록 설정하고자 함

문의 링크

추가 실행 사항

  • nas - volume 확인
  • 볼륨 공유 openstack 용 확인
  • 로키 8 이미지 추가
  • 엑셀 → 서버 사양 정리
  • 노드 구성 그림
  • keycloack 권한 관리
  • 다른 라우터 wan 포트 테스트
  • vpn 설정 추가
  • 노드 리소스 모니터링 → Maas 노드

env | grep OS_

yaleeyu7Akaabaeb

마스 → 물리 서버 클러스터링

  • 자체적으로 가상 서버 생성 가능

juju 대시보드 설치 + 접속

juju 계정 관리

Juju

기능

  • 복잡한 애플리케이션 배포에 대한 모델링
  • 복잡한 배포 과정에 대한 캡슐화 및 재사용
  • 오픈소스

모델링

  • 애플리케이션, 의존성 집중
  • 최근의 솔루션은 단일 애플리케이션이 아니라 서로 연관된 다중 애플리케이션으로 이루어진 경우가 많음.(micro service, cloud)
    • juju는 서로 다른 컴포넌트들이 (설정 값등을) 소통하는 방법, 환경을 제공

Juju Dashboard

  • 3.0 미만 버전에서는 juju 설치시 자동 배포됨
juju register MGMTBGFwaW0wJhMPbG9jYWxob3N0OjE3MDcwExMxOTIuMTY4LjEwMC4yOjE3MDcwBCBCGVBS3Xf98lYqxV2wYxxsKDeBTi4OHJ-fl5JO8HcErBMPbWFhcy1jb250cm9sbGVyEwAA
  
  "apim" has not been granted access to any models. You can use "juju grant" to grant access.

Juju User

  • 유저 별 model, cloud 권한 설정 가능.

Openstack

  • Boot Strap

https://help.cloud.grnet.gr/t/use-openstack-as-cloud-provider-with-juju/47

juju metadata generate-image -d ~/simplestreams -i f8cc865c-bec7-4480-a6c0-ee50bd653b08 -s bionic -r RegionOne -u https://192.168.100.124:5000/v3

juju bootstrap openstack openstack-controller --metadata-source /home/direa/simplestreams/images --config network="admin_net" --config external-network="ext_net" --debug

juju credentials --client --show-secrets --format yaml

node1 → 810c

node2 → 80ac

node3 → 7f8c

네트워크 Bond + 재배포

문제 상황 1

  • openstack 배포 과정에 unit 배포 조차 제대로 안되는 경우 및 juju ssh 도 간헐적으로 안되는 현상 발생
  • maas 클러스터 정상적으로 배포 완료 하더라도 이후 openstack 인스턴스 생성 시 해당 ip로 접근이 안됨
  • maas node ssh 후 ovs-vsctl show 쳤을 때 br-ex 에 bond0 인터페이스가 제대로 올라오지 않고 에러

예상 원인

  • maas 에서 bond 생성 시 Unconfigured가 아닌 서브넷 지정 후 Auto-Assign 까지 해준 상태에서 브릿지 걸었음

해결

  • 본딩 알고리즘을 balance-xor(mac 기반 hash func로 로드밸런싱)로 변경

Resize

  • Resizing 요청 보냈으나 아무 응답 없음(대시보드, cli 모두)
  • 디버깅
    • 인스턴스 액션 로그 확인
    • nova-controller 노드의 /var/log/nova/ 하위의 nova-conductor, nova-scheduler 로그 확인
    • nova.exception_Remote.NoValidHost_Remote: No valid host was found. 확인
    • Got no allocation candidates from the Placement API. This could be due to insufficient resources or a temporary occurrence as compute nodes start up.
  • 실 사용 가능량 조회
    • openstack hypervisor show 1 -f shell | grep -E 'memory_mb|vcpus|free'
  • 해결
    • 메모리 줄인(128g → 64g) flavor 적용 후 resizing 진행

특정 인스턴스 종료되는 문제

  • 문제 상황

    인스턴스 액션로그에는 “-” 로 user id 가 없는 상황인데 stop을 실행시킴

  • 예상 원인

    https://serverfault.com/questions/783053/openstack-instances-power-off-by-itself

    db 와의 동기화에서 실패가 원인인 것 같음 실제 문제의 인스턴스가 배치된 노드의 nova 로그에서도 같은 로그가 발생하는 것을 확인

    ubuntu@node4:~$ sudo zcat /var/log/nova/nova-compute.log.3.gz | grep power_state | head -1
  2024-02-16 00:18:06.544 22164 INFO nova.compute.manager [None req-7b98b5d9-92bd-4362-8a18-be95b9d163a9 - - - - - -] [instance: e60932e9-3437-4fbb-a5e6-3d0bb9d861c6] During _sync_instance_power_state the DB power_state (1) does not match the vm_power_state from the hypervisor (4). Updating power_state in the DB to match the hypervisor.

Probing EDD 문제

/etc/default/grub
  GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200n8 edd=off_no_timer_check net.ifnames=0 crashkernel=auto"

인스턴스에서 ‘e’ 눌러서 커널 진입후 수정 필요

되돌아가기 수정