티스토리 뷰

tripleO

Jacob_baek 2016. 10. 19. 15:33

[TripleO 소개]


특징

- Ironic 과 Heat 그리고 nova 기반으로 동작하게 된다.

- undercloud와 overcloud라는 개념으로 환경을 deploy 한다.

  (undercloud는 TripleO가 동작하는 노드라 보면 되고 overcloud는 배포된 openstack 환경이라 볼수 있다.)

- undercloud는 baremetal을 대상으로 openstack이 구성이되고 overcloud는 KVM기반으로 openstack이 구성되는 개념

- Puppet을 이용해 배포



https://docs.openstack.org/tripleo-docs/latest/introduction/architecture.html



위와 같은 구성을 가지게 된다.


[Network Topology]

네트워크 구성은 각 VLAN을 모두 사용함을 권장한다.


중요하게 고려해야할 것은 Provision Network은 격리된 상태가 좋다.

말인즉슨 다른 dhcp request가 발생하는 경우 pxe 동작에 문제가 발생될 수 있기 때문이다.


참고로 provision network은 10G 이상을 사용하는것이 좋다.

아무래도 고용량의 OS를 배포하는것이기에 1G 같은 경우 배포에 다수의 시간이 소요된다.


[WorkFlow]

실제 workflow는 다음과 같다.

- undercloud 노드를 설치한다.

- ipmi 및 pxe를 이용하여 lightweight한 OS를 undercloud로 부터 pxe를 이용해 각 baremetal에 설치한다.

- 설치된 baremetal에서 기본정보를 undercloud로 가져온다.

- undercloud는 heat를 이용해 kvm 기반의 openstack을 baremetal에 pxe를 이용해 배포하여 overcloud를 구성한다.

   - https://github.com/rbrady/tripleo/blob/master/docs/architecture_overview.rst


1. undercloud 설치

당시 설정파일(undercloud.conf)은 아래를 참고한다.

local_ip = 192.168.0.100/24

network_gateway = 192.168.0.100

undercloud_public_vip = 192.168.0.101/32

undercloud_admin_vip = 192.168.0.102/32

dhcp_start = 10.1.38.20                                     # overcloud deploy 시 dhcp range

dhcp_end = 10.1.38.40                                      # overcloud deploy 시 dhcp range
inspection_interface = br-ctlplane                        # provisioning 에 사용되는 ovs interface
inspection_iprange = 10.1.38.120,10.1.38.140          # provisioning 에 사용되는 dhcp range 

참고로 위 comment중 dhcp range라 표시된 것들은 pxe를 통해 설치될때 사용되는 ip이다.


[root@rhosp_director ~]# openstack undercloud install

위 command를 수행하면 /usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py 를 실행하게 된다.


2. introspection

introspection 수행을 위해서는 별도의 access network이 존재해야 한다.

실제 provision을 수행할 네트워크에 다른 대역의 dhcp packet이 존재해서는 안된다.(즉, native vlan으로 사용해야 한다.)


아래와 같은 subnet이 검색될 거고 해당 subnet에 dns를 추가한다.
[stack@director9 images]$ neutron subnet-list
+--------------------------------------+------+--------------+----------------------------------------------+
| id                                   | name | cidr         | allocation_pools                             |
+--------------------------------------+------+--------------+----------------------------------------------+
| 31f710a3-6a5d-4e48-afb6-63fef725b04f |      | 10.1.38.0/24 | {"start": "10.1.38.20", "end": "10.1.38.40"} |
+--------------------------------------+------+--------------+----------------------------------------------+

introspection 단계에서 boot sequence를 force_pxe로 설정해야 한다.(즉, boot order 상에 pxe interface가 최상단에 있으면 된다.) 아래의 ipmitool을 통해 자동화할수 있다. 

# once pxe boot  (한번만 pxe로 boot 된다. 이후 기존 boot order로 원복)

ipmitool -I lanplus -H hostip -U root -P password chassis bootdev pxe

# persistent pxe boot (강제적으로 바꿔 향후에도 변경된 boot order로 boot 된다.)

ipmitool -I lanplus -H hostip -U root -P password chassis bootparam set force_pxe


introspection 할 대상은 ironic node-list(혹은 openstack baremetal list)로 확인이 가능하다.

만약 director(tripleO)의 network service를 변경하여 재시작한경우 ironic도 재시작해줘야 한다.

아닐경우 dhcp,pxe response가 안되는 경우가 있다.


만약 아래와 같이 Provisioning State가 manageable 일 경우 완료되지 않은것으로 볼수 있다.

[root@rhosp_director ~]# ironic node-list
+--------------------------------------+------+---------------+-------------+--------------------+-------------+
| UUID                                 | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+------+---------------+-------------+--------------------+-------------+
| 6bda493f-a15f-4a4c-9dc8-4b81b50fcc68 | None | None          | power on    | manageable         | False       |
| 84853c99-fcb4-42e6-9b8c-a3a1c8aa4b54 | None | None          | power on    | manageable         | False       |
+--------------------------------------+------+---------------+-------------+--------------------+-------------+


최초 pxe로 boot 되어 lightweight한 OS를 설치한다. 설치된 OS를 이용해 기본정보를 확인한 후 해당 baremetal을 

power off 한다.


만약 다수의 disk를 사용하는 경우 필요에 따라 root disk 설정을 수행할 수 있다.

아래 작업은 disk 정보를 gathering 하는 방법이다.

mkdir ~/swift-data

cd ~/swift-data

export SWIFT_PASSWORD=`sudo crudini --get /etc/ironic-inspector/inspector.conf swift password`

for node in $(ironic node-list | grep -v UUID| awk '{print $2}'); do swift -U service:ironic -K $SWIFT_PASSWORD download ironic-inspector inspector_data-$node; done

for node in $(ironic node-list | awk '!/UUID/ {print $2}'); do echo "NODE: $node" ; cat inspector_data-$node | jq '.inventory.disks' ; echo "-----" ; done


사실 이부분보다는 아래와 같이 각 baremetal의 UUID(혹은 name) 별로 disk 정보를 확인하고 profile을 update 해주는 방법이 더 깔끔하다.
openstack baremetal introspection data save [UUID or Name] | jq '.inventory.disks'

실제로 아래와 같이 정보가 출력된다.
[
  {
    "size": 85899345920,
    "serial": null,
    "rotational": true,
    "vendor": "VMware",
    "name": "/dev/sda",
    "wwn_vendor_extension": null,
    "hctl": "2:0:0:0",
    "wwn_with_extension": null,
    "model": "Virtual disk",
    "wwn": null
  },
  {
    "size": 53687091200,
    "serial": null,
    "rotational": true,
    "vendor": "VMware",
    "name": "/dev/sdb",
    "wwn_vendor_extension": null,
    "hctl": "2:0:1:0",
    "wwn_with_extension": null,
    "model": "Virtual disk",
    "wwn": null
  }
]
위 정보는 vmware 위에 VM으로 한작업이기에 wwn이 null로 출력된다. 실제 wwn은 null이지 않다.

위와 같이 확인된 UUID 및 Serial 정보를 가지고 property를 설정한다.
openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87- 0bd8a3819bc0 

profile 설정을 다음과 같이 좀더 쉽게 할수 있다.
#!/bin/bash

openstack baremetal node list -c UUID -f value > /tmp/node_ids.txt

ctl=`sed -n 1p /tmp/node_ids.txt`
com=`sed -n 2p /tmp/node_ids.txt`

openstack baremetal node set --property capabilities='profile:control,boot_option:local' $ctl
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' $com

openstack overcloud profiles list
+--------------------------------------+-----------------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name       | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------------+-----------------+-----------------+-------------------+
| 0f30da12-3463-4977-87a8-7a03d4b93fbe | osp10compute    | available       | compute         |                   |
| ca92b69d-75d3-4153-a2f5-d4f7e38e644f | osp10controller | available       | control         |                   |
+--------------------------------------+-----------------+-----------------+-----------------+-------------------+

최종적으로 아래와 같이 출력되어야 한다.

[stack@director9 ~]$ openstack baremetal list

+--------------------------------------+---------+---------------+-------------+--------------------+-------------+

| UUID                                 | Name    | Instance UUID | Power State | Provisioning State | Maintenance |

+--------------------------------------+---------+---------------+-------------+--------------------+-------------+

| 9ac08e4f-bf4d-4b49-9c37-085620203e68 | ctl1 | None          | power off   | available          | False       |

| 235ad607-f7e7-40c6-aad4-d781671b159d | ctl2 | None          | power off   | available          | False       |

| 754598a2-f786-458f-bd04-5bc2d02b23bb | ctl3 | None          | power off   | available          | False       |

| f836b9c0-2df7-4f1c-9dda-9fdadf69ed45 | com1 | None          | power off   | available          | False       |

| 41ef4ba9-a87b-4d2f-b4c3-753d8059957e | com2 | None          | power off   | available          | False       |

| b82928f2-04a0-47b1-9ff1-50aed5569cdb | com3 | None          | power off   | available          | False       |

+--------------------------------------+---------+---------------+-------------+--------------------+-------------+


간혹 introspection 수행시 "port still in use" 실패가 발생되기도 하는데 아래 설정을 변경하여 수행하면 좀 개선이 된다고 한다. (newton 버전부터는 개선되었다고 하는데 우선 참고용 https://bugzilla.redhat.com/show_bug.cgi?id=1400488

vi /etc/nova/nova.conf

scheduler_host_subset_size=6


introspection 단계에서 아래와 같은 에러가 발생할수 있다.

[stack@director9 ~]$ ./before_deploy.sh

Setting nodes for introspection to manageable...

Starting introspection of node: 5dd06945-2714-4922-ab2e-0faf09610099

Starting introspection of node: 5b64b972-839a-4bce-b19e-f9e86617bb5d

Starting introspection of node: b1cc9f02-b32f-4372-9407-cbf133462976

Starting introspection of node: 9de50ff4-398a-417d-bcb8-827d37c56aeb

Starting introspection of node: e8a63504-4c18-49da-8202-6ec51d8ec032

Waiting for introspection to finish...

Introspection for UUID b1cc9f02-b32f-4372-9407-cbf133462976 finished successfully.

Introspection for UUID e8a63504-4c18-49da-8202-6ec51d8ec032 finished successfully.

Introspection for UUID 5dd06945-2714-4922-ab2e-0faf09610099 finished successfully.

Introspection for UUID 5b64b972-839a-4bce-b19e-f9e86617bb5d finished successfully.

Introspection for UUID 9de50ff4-398a-417d-bcb8-827d37c56aeb finished with error: Preprocessing hook validate_interfaces: No suitable interfaces found in {u'p2p2': {'ip': None, 'mac': u'90:e2:ba:86:0b:8d'}, u'p2p1': {'ip': None, 'mac': u'90:e2:ba:86:0b:8c'}, u'em1': {'ip': u'10.1.38.125', 'mac': u'90:e2:ba:86:0b:8c'}, u'em2': {'ip': None, 'mac': u'10:98:36:a4:a7:d8'}}

Setting manageable nodes to available...

Node 5dd06945-2714-4922-ab2e-0faf09610099 has been set to available.

Node 5b64b972-839a-4bce-b19e-f9e86617bb5d has been set to available.

Node b1cc9f02-b32f-4372-9407-cbf133462976 has been set to available.

Node e8a63504-4c18-49da-8202-6ec51d8ec032 has been set to available.

Introspection completed with errors:

9de50ff4-398a-417d-bcb8-827d37c56aeb: Preprocessing hook validate_interfaces: No suitable interfaces found in {u'p2p2': {'ip': None, 'mac': u'90:e2:ba:86:0b:8d'}, u'p2p1': {'ip': None, 'mac': u'90:e2:ba:86:0b:8c'}, u'em1': {'ip': u'10.1.38.125', 'mac': u'90:e2:ba:86:0b:8c'}, u'em2': {'ip': None, 'mac': u'10:98:36:a4:a7:d8'}}

mac이 동일한 mac으로 interface가 올라와 문제가 되는데... 이유는 아직 명확하지 않다. (랜덤하게 발생)
이유는 다음과 같았다. (https://bugzilla.redhat.com/show_bug.cgi?id=1384187)
RedHat Linux 7.3에서 나타난 문제로 httpboot/inspector.ipxe에 
ipa-debug=1 initrd=agent.ramdisk net.ifnames=0 biosdevname=0|| goto retry_boot 
와 같이 net.ifnames=0 biosdevname=0를 추가하고 inspectation을 수행하면 된다.


3. overcloud 배포

overcloud deploy의 경우 heat 를 사용하여 배포한다.


template 기반으로 다음과 같은 파일들을 기본 sample들로 부터 복사해서 사용할 수 있다.(newton 기반)

cp -r /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml ~/templates

cp -r /usr/share/openstack-tripleo-heat-templates/environments/network/ ~/templates

cp -r /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml ~/templates

touch ~/tempaltes/node-info.yaml

필수로 포함되어야 하는 내용이라 보면 되며 추가적인 설정이 필요한 경우 template을 추가로 작성하거나복사해야 한다.


node-info.yaml은 다음과 같이 생성하여 진행한다.(해당 내용은 참고용 샘플이다.)

parameter_defaults:
  OvercloudControlFlavor: control
  OvercloudComputeFlavor: compute
  OvercloudCephStorageFlavor: ceph-storage
  ControllerCount: 3
  ComputeCount: 3
  CephStorageCount: 3


template 생성 및 작성시 아래의 내용을 참고하면 좋다. 필요에 따라 single-nic 혹은 bond-nic 으로 복사하여 사용이 가능하다.

간편하게 설정하기위해 아래와 같이 모든 sample yaml을 복사한다.

cp -rf /usr/share/openstack-tripleo-heat-templates/* ~/templates/


일반적으로 수정되어야 하는 config 파일은 아래와 같다.

~/templates/network/config/[single or bond, multiple]-nic-vlans/controller.yaml

~/templates/network/config/[single or bond, multiple]-nic-vlans/compute.yaml

~/templates/environments/net-[single or bond, multiple]-nics-with-vlans.yaml

~/templates/environments/network-isolation.yaml

~/templates/environments/network-environment.yaml


sample templates

#1. ~/templates/network/config/single-nic-vlans/controller.yaml & compute.yaml



#2. ~/templates/environments/net-single-nics-with-vlans.yaml

현상황에서는 수정 불필요

resource_registry:
  OS::TripleO::BlockStorage::Net::SoftwareConfig: ../network/config/single-nic-vlans/cinder-storage.yaml
  OS::TripleO::Compute::Net::SoftwareConfig: ../network/config/single-nic-vlans/compute.yaml
  OS::TripleO::Controller::Net::SoftwareConfig: ../network/config/single-nic-vlans/controller.yaml
  OS::TripleO::ObjectStorage::Net::SoftwareConfig: ../network/config/single-nic-vlans/swift-storage.yaml
  OS::TripleO::CephStorage::Net::SoftwareConfig: ../network/config/single-nic-vlans/ceph-storage.yaml

#3. ~/templates/environments/network-isolation.yaml
현 상황에서는 수정 불필요

사용되는 heat template은 아래 링크에서도 확인할 수 있다.

https://github.com/openstack/tripleo-heat-templates/


마지막단계인 overcloud deploy에서는 network-environment.yaml과 nic-configs 폴더내 controller.yaml, compute.yaml 등과 같은 일반적인 network config yaml 파일이 있으면 된다.
위 repo에 참고용 sample이 있다.

배포시 아래 사항들을 확인해보는것이 좋다.
- ironic node-list(= openstack baremetal list) : baremetal 노드 리스트 정보 확인
- ironic port-list : instackenv.json으로 등록한 mac 정보 확인

deploy 수행시 기본적으로 아래 template은 포함하여 배포할수 있다.(storage 및 다른 template도 포함)
openstack overcloud deploy --templates \
  -e ~/templates/node-info.yaml\
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e ~/templates/network-environment.yaml \
  --ntp-server pool.ntp.org \

배포과정은 다음과 같다.

순서 

 작업내용

 Power State

 Provisioning State 

 1

 heat stack 등록 

power off

available 

 2

 ipmi 도구를 통한 전원 on을 수행 

power on

available 

 3

 pxe로 boot 되기를 대기 

 power on 

wait call-back 

 4

 pxe로 boot 된 이후 

power on

deploying 

 5

 배포가 완료된 이후

power on

active


배포가 완료된 이후에는 openstack server list로 배포된 노드들에 대한 정보를 확인해볼수 있다.

[stack@rhosp-director ~]$ openstack server list

+--------------------------------------+-------------------------+--------+---------------------+----------------+

| ID                                   | Name                    | Status | Networks            | Image Name     |

+--------------------------------------+-------------------------+--------+---------------------+----------------+

| fb5b5429-66f2-4718-b490-796264004015 | overcloud-compute-1     | ACTIVE | ctlplane=1.2.3.8 | overcloud-full |

| e7fd6d12-009c-446b-ad1a-12ffd6ba6dd6 | overcloud-compute-0     | ACTIVE | ctlplane=1.2.3.7 | overcloud-full |

| 0face385-1a65-4f20-bb5e-5f4057fe7189 | overcloud-controller-0  | ACTIVE | ctlplane=1.2.3.5 | overcloud-full |

| 8551f925-de7d-49c1-916b-2fdf1037c51e | overcloud-controller-1  | ACTIVE | ctlplane=1.2.3.4 | overcloud-full |

| 25fb27c9-5ee7-4d6b-99bb-b1c4ba460b8a | overcloud-controller-2  | ACTIVE | ctlplane=1.2.3.6 | overcloud-full |

+--------------------------------------+-------------------------+--------+---------------------+----------------+


실제 deploy 시에 introspection 이 실패하거나 시간이 오래동안 지연되는 경우가 있는데 dhcp packet 캡처를 통해 정상적으로 deploy가 진행되는지 확인해볼수 있다.
tcpdump -nnei br-ctlplane
위 패킷 캡처를 통해 pxe 과정중 dhcp processing이 제대로 되었는지 확인해볼수 있다. 혹은 실제 virtual console을 이용해 직접 확인해봐도 되고 console에서 직접 확인해도 무방하다. 

참고로 local_ip를 subnet을 주지않은 경우 dhcp request에 대한 reply가 발생안될수 있다.
(기본적인 부분임에도 실수하는 경우가 있어서 참고용으로 기록해놓는다.)

배포과정은 아래와 같은 []로 표현된 task로 진행된다.
2017-03-17 07:31:02 [UserData]: CREATE_COMPLETE state changed
2017-03-17 07:31:02 [NovaCompute]: CREATE_IN_PROGRESS state changed
2017-03-17 07:31:03 [UpdateConfig]: CREATE_IN_PROGRESS state changed
2017-03-17 07:31:06 [UserData]: CREATE_COMPLETE state changed
2017-03-17 07:31:06 [NodeAdminUserData]: CREATE_COMPLETE state changed
2017-03-17 07:31:06 [UserData]: CREATE_IN_PROGRESS state changed
2017-03-17 07:31:06 [NodeUserData]: CREATE_IN_PROGRESS state changed
2017-03-17 07:31:07 [Controller]: CREATE_IN_PROGRESS state changed
2017-03-17 07:31:07 [UserData]: CREATE_COMPLETE state changed
2017-03-17 07:31:08 [Controller]: CREATE_IN_PROGRESS state changed
2017-03-17 07:31:08 [UpdateConfig]: CREATE_COMPLETE state changed
2017-03-17 07:31:08 [NodeUserData]: CREATE_COMPLETE state changed
2017-03-17 07:31:08 [NodeAdminUserData]: CREATE_COMPLETE state changed
novacompute, networkdeployment 등 각 task별 작업들을 수행하게 된다.

openstack overcloud deploy command를 이용해 배포가 시작되면 각 baremetal에 OS 설치 및 cloud-init을 수행한다.
cloud-init은 ip 설정을 수행하고 systemd에 의해 os-collect-config가 호출된다.
- os-collect-config 수행 순서
  1. systemd 에서 시스템 시작후 os-collect-config를 호출한다.
  2. os-collect-config는 os-refresh-config를 호출한다.
  3. os-net-config는 os-refresh-config에 의해 호출된다.
  4. os-refresh-config는 os-apply-config를 호출한다.

참고로 아래와 같은 배포용 도구가 존재하고 해당 도구들을 통한 인스턴스 배포를 자동화한다.
- os-refresh-config
- os-collect-config
- os-apply-config

아래의 순서로 os-collect-config가 수행된다.
- writing /etc/os-net-config/config.json
- writing /var/run/heat-config/heat-config
- writing /etc/puppet/hiera.yaml
- writing /etc/os-collect-config.conf
- /usr/libexec/os-refresh-config/configure.d/20-os-net-config


아래 링크에서와 같이 os-net-config는 network 설정을 수행한다.
실제 설정파일은 /etc/os-net-config/config.yaml 및 json 파일을 참고한다.
http://alesnosek.com/blog/2015/09/28/network-configuration-with-os-net-config/

os-net-config는 os-refresh-config에 의해 실행되어진다.

os-net-config를 통해 생성되어야 할 config.yaml 파일이 empty로 생성되는 문제

이슈를 간략히 정리하면 UpdateDeployment와 NetworkDeployment가 동시에 발생되어 간혹 NetworkDeployment를 수행하는 os-net-config가 empty 상태로 deploy가 되는 경우가 발생되었고

이를 우선적으로 NetworkDeployment가 이루어지도록 puppet의 heat template을 변경한 이슈

- https://bugs.launchpad.net/tripleo/+bug/1666227

실제 현상은 deploy가 어느정도 이루어진후에 네트워크가 연결되지 않는 현상이 발생된다.

실제 openstack server list에서는 ip가 확인이 되지만 ssh 및 ping 연결은 되지 않는다 해당 서버를 console(만약 virtual console이 있다면)로 연결해보면 로그인화면이 보인다. 즉 설치가 완료된것이다.

이와 같은 경우는 아래와 같은 puppet 파일을 변경하면 배포시 network설정까지 완료하여 문제없이 배포가 된다.

/usr/share/openstack-tripleo-heat-templates/puppet/controller.yaml 

/usr/share/openstack-tripleo-heat-templates/puppet/compute.yaml 


  UpdateDeployment:

    type: OS::Heat::SoftwareDeployment

    depends_on: NetworkDeployment

    properties:


아래 코드를 참고한다.

- https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=626b820b57498ff5002c5530962e6e4fd5644b51


DIB (Disk Image Builder)


배포시 발생되었던 이슈

- https://bugs.launchpad.net/tripleo/+bug/1622360


참고로 1G interface를 통해 배포한 결과 5노드에 대해 약 1시간 20분정도 소요가 되었다.


배포시 "no valid host" 와 같이 메세지가 deploy시 발생되는 경우가 있다. (nova-condutor.log에서도 확인이 가능하다.) 

이와 같은 경우는 node가 pxe로 부팅되지 못해서 그러는 경우도 있고 profile이 매칭되지 않아서 발생되는 경우가 있다. 우선 pxe 부팅의 경우 ipmitool 혹은 각 ipmi 접근할수 있는 도구, console로 pxe 부팅을 수행한다. profile이 매칭되지 않는 경우는 heat command를 이용해 debuging을 수행한다.

https://docs.openstack.org/developer/tripleo-docs/troubleshooting/troubleshooting-overcloud.html


아래는 idrac에서 pxe의 부팅순서가 ipmitool로는 모든 nic을 다 순서화시킬수 없어 아래의 racadm를 이용하는 방법을 기술한 것이다.

racadm set BioS.biosBootSettings.Bootseq NIC.Embedded.2-1-1,NIC.Embedded.1-1-1,NIC.Slot.2-2,NIC.Slot.2-1,HardDisk.List.1-1,Optical.SATAEmbedded.E-1

racadm jobqueue create BIOS.Setup.1-1 -r pwrcycle -s TIME_NOW -e TIME_NA


ipmitool의 경우 chassis bootdev pxe 와 같은 option을 써서 가능하지만 pxe 설정이 단순 하나의 nic만을 설정하게 되어 다수의 nic이 있는 경우 pxe로 부팅이 안될 가능성이 있다.


혹 flavor에 지정된 사이즈가 만족되지 못하는 경우도 발생될수 있다.

nova-scheduler.log를 확인해보면 아래와 같은 host_passes 라는 로그가 확인된다.

2018-01-15 03:54:12.298 24729 DEBUG nova.filters [req-b6c741e1-6d29-446b-bb70-4e97219022f0 6d13202c47594eb2b171ad326055261a 33fd4f71b2e84c5495a163cec23acc28 - - -] Filter RamFilter returned 1 host(s) get_filtered_objects /usr/lib/python2.7/site-packages/nova/filters.py:104
2018-01-15 03:54:12.298 24729 DEBUG nova.scheduler.filters.disk_filter [req-b6c741e1-6d29-446b-bb70-4e97219022f0 6d13202c47594eb2b171ad326055261a 33fd4f71b2e84c5495a163cec23acc28 - - -] (ospd.lab.com, 57eda267-8c2f-499a-ab55-885984406d14) ram: 4096MB disk: 39936MB io_ops: 0 instances: 0 does not have 40960 MB usable disk space before overcommit, it only has 39936 MB. host_passes /usr/lib/python2.7/site-packages/nova/scheduler/filters/disk_filter.py:53
2018-01-15 03:54:12.298 24729 INFO nova.filters [req-b6c741e1-6d29-446b-bb70-4e97219022f0 6d13202c47594eb2b171ad326055261a 33fd4f71b2e84c5495a163cec23acc28 - - -] Filter DiskFilter returned 0 hosts
이때는 flavor의 size를 변경하던지 물리 디스크의 사이즈를 늘리던지 해야 한다.


4. 배포완료 

배포완료후에는 아래 링크를 참조하여 각 노드에 접속한다.
접속은 ssh를 사용하고 아래와 같이 baremetal VM(instance) networks 정보를 확인하여 접속을 수행한다.
접속 당시의 tripleO client가 수행되는 서버의 계정은 stack 이어야 하고 대상 접속 계정은 heat-admin 이다.

re-deploy를 해야 하는 경우가 발생될 경우 pxe boot로 실제 설치가 되는지를 확인해보는게 좋다.

간혹 pxe로 다시 설치가 되어야 하는데 pxe를 bypass 하여 가능 경우가 발생된다.

실제 확인은 console(virtual console 도 포함)에 연결하여 설치되는 과정을 확인해야 한다. 실제로 ipxe ~~와 같은 메세지 출력된다.



Mitaka의 경우 배포 실패후(stack create-failed) stack 만 delete후 deploy를 수행하면 pxe로 진입이 안되는 경우가 있다. 원인은 확인해봐야할것으로 보인다.


또한 만약 deploy 실패가 발생되어 다시 배포를 하는 경우라면 openstack-ironic-*를 재구동하는 것이 필요할 수 있다. 기존 node의 정보가 갱신되지 않은 상태라 deploy가 실패될 수 있다.


설치 완료후 login page에서 admin password는 undercloud 의 tripleo-overcloud-passwords 을 참고하여 로그인하면 된다. 혹은 undercloud(tripleo로 구성된 노드)의 stack 계정에 보면 overcloudrc 파일이 있고 Password를 확인할 수 있다.


5. 배포후 compute node 증설


ironic으로 baremetal 의 provision 상태를 변경하고 introspection 단계를 거쳐 deploy를 수행한다.


ironic node-set-provision-state $UUID manage

openstack baremetal introspection start $UUID

# 위 command를 수행하면 몇초내에 return이 된다. 즉 해당 task가 수행이 완료될때 까지 대기하지 않는다.

openstack baremetal introspection status $UUID

[stack@director9 ~]$ openstack baremetal introspection status 7a0e6ffd-9c62-40ee-93f9-e85bd1bbeb4c

+----------+-------+

| Field    | Value |

+----------+-------+

| error    | None  |

| finished | True  |

+----------+-------+

# 위와 같이 finished field 가 True로 변경됨을 확인하고 아래의 provision state를 변경한다.

ironic node-set-provision-state $UUID provide

openstack baremetal set $UUID --property name=compute-XX

# 원하는 name으로 지정하면 된다.

ironic node-update $UUID add properties/capabilities='profile:compute,boot_option:local'


이후 기존에 사용했던 deploy.sh 의 compute node count를 +1 혹은 그이상하여 deploy를 다시한다.


당시에 기존 active 상태의 baremetal 서버들은 영향을 받지 않는다. 다만 deploy command를 기존과 다르게 사용할 경우(다른 template를 추가한다던지) stack이 update failed되고 복구가 어려워진다. 이점을 확실히 확인하고 배포를 진행해야 한다.


admin password가 변경된다.(변경하여 사용중이던 password가 random한 password로 변경되어 있다.)

또한 배포시 service restart를 수행해 기존 서비스에 영향을 줄수 있다. 만약 기존에 lbaas와 같은 수동으로 설정한 service가 있을 경우 해당 서비스도 다시 설정해야 한다.


만약 controller에서 제공하는 service의 restart를 원치않는 경우 아래 Red Hat link를 참고하여 yaml을 추가한다.

- https://access.redhat.com/solutions/2345231


environment.yaml내에 아래 항목을 추가한다.

parameter_defaults:

  StackAction: CREATE

http://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=c577755082a92e638ca03ae8a8bd38045bf7901c


https://docs.openstack.org/developer/tripleo-docs/advanced_deployment/introspect_single_node.html


6. 그외 참고

참고사항

- storage management network을 사용했을 경우 swift는 해당 network을 사용하게 된다.

- overcloud에서 사용하는 external network을 undercloud에 설정했던 external vlan id를 꼭 써야할 필요는 없다.

  (필요에 따라 underlay 의 switch 설정에 필요한 vlan을 추가하고 추가한 vlan을 external network으로 설정가능) 


아래 링크에 heat template 예제로 nic 설정에 대한 설명이 나와있다.

http://blog.nemebean.com/content/network-isolation-tripleo-home-networks


아래 동영상은 tripleo를 통한 설정에 대해 시연을 통해 보여주고 있다.

https://www.youtube.com/watch?v=ulpxlNFfbF8


아래 동영상은 tripleo GUI환경에 대한 설명이다.

https://www.youtube.com/watch?v=UKH6tRoJvaE


newton 이후 버전부터는 openstack command를 이용해 debug 정보를 확인할 수 있다.

http://abregman.com/2017/02/12/tripleo-debugging-overcloud-deployment-failure/


만약 baremetal 환경이 아닌 virtual 환경에서 tripleo를 사용할 경우

virtual 환경에서 테스트용도로 tripleo 를 사용하는 경우는 아래와 같이 사용이 가능하다.

- kvm을 기반으로 한 경우 pxe_ssh

- 그외 hypervisor인 경우 수동으로 vm의 전원을 reboot 해주고 각 virtual machine의 boot option을 pxe로 되어지도록 한다.

  실제 deploy를 위한 pm_type 은 fake_pxe로 설정한다. 말그대로 fake_pxe는 pxe 역할을 실제 deploy를 하는 사람이 해줘야 

  한다. 예로 introspect 시점에는 맞춰 on을 해주고 bios 설정에서 pxe로 부팅되도록 해야한다.


vmware vswitch의 경우 아래 설정을 해주어야 한다.

(위 설정이 되어야 introspection에 pxe 부팅시 os 설치가 가능하다.)


vmware의 VM에 배포시 아래의 이슈도 참고해볼 필요가 있다.

https://access.redhat.com/solutions/2121601

https://access.redhat.com/solutions/2177431

vmware의 vDS(가상 분산 스위치)를 이용한 경우 network 연결이 늦게 되는 경우가 있었다.

늦게 된다는 것이 /var/log/message에 ping X.X.X.X faile ... retrying .. FAILURE 와 같은 메세지가 출력되고 deploy가

실패하는데 막상 실패된 후에 해당 노드에서 직접 ping을 연결해 보면 몇개의 packet이 loss된후 이후부터는

정상적으로 연결이 되는 케이스가 있었다.


만약 아래와 같은 error message가 deploy 시 발생될 경우

deploy시 아래와 같은 에러가 발생되는 경우

2017-06-21 08:57:30Z [overcloud.Networks]: CREATE_FAILED  Resource CREATE failed: resources.ExternalNetwork: Resource CREATE failed: 'ascii' codec can't encode characters in position 38-39: ordinal not in range(128)

2017-06-21 08:57:31Z [overcloud.Networks]: CREATE_FAILED  resources.ExternalNetwork: resources.Networks.Resource CREATE failed: 'ascii' codec can't encode characters in position 38-39: ordinal not in range(128)

2017-06-21 08:57:31Z [overcloud]: CREATE_FAILED  Resource CREATE failed: resources.ExternalNetwork: resources.Networks.Resource CREATE failed: 'ascii' codec can't encode characters in position 38-39: ordinal not in range(128)

아래 링크를 참조하여 locale 설정을 한다.


Deployment to server failed: deploy_status_code 발생시 deploy command option을 다음링크에서 소개된데로 수행해본다.

ComputeAllNodesValidationDeployment CREATE_FAILED 발생시
network 연결을 확인해보고 아래링크를 참조한다.

간혹 배포시 문제가 되어 실제 physical machine에 접속해서 확인을 해보고 싶은 경우가 발생한다.
당시 확인을 위해서는 heat-admin 계정에 맞는 키가 등록되어 있는 상황이어야 하고 network 문제인경우라면 아예 접속할 방법이 없다. 이런경우 debug을 하기 위해서는 image 자체에 계정을 사전에 등록해놓는 방법이 있다.
아래의 command들을 사용하면 된다.
virt-customize -a overcloud-full.qcow2 --run-command 'useradd test'
virt-customize -a overcloud-full.qcow2 --run-command 'echo "test4321" | passwd --stdin test'
위 작업을 image upload 전 수행하면 배포후 네트워크 문제로 debug가 어려울때 유용하게 사용할 수 있다.

RHOSP deploy fail시 아래와 같은 command를 통해 확인이 가능하다.
(해당 command 는 RHOSP 10 혹은 11부터 가능한 command)
[stack@director11 ~]$ openstack stack failures list overcloud
overcloud.AllNodesDeploySteps.ControllerDeployment_Step3.0:
  resource_type: OS::Heat::StructuredDeployment
  physical_resource_id: bdfb0d7e-4810-4d62-b051-e2324d458404
  status: CREATE_FAILED
  status_reason: |
    Error: resources[0]: Deployment to server failed: deploy_status_code : Deployment exited with non-zero status code: 1
  deploy_stdout: |
    ...
    Notice: /Stage[main]/Glance::Db::Metadefs/Exec[glance-manage db_load_metadefs]: Dependency Package[db_backend_package] has failures: true
    Notice: /Stage[main]/Heat::Deps/Anchor[heat::dbsync::begin]: Dependency Package[db_backend_package] has failures: true
    Notice: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: Dependency Package[db_backend_package] has failures: true
    Notice: /Stage[main]/Heat::Deps/Anchor[heat::dbsync::end]: Dependency Package[db_backend_package] has failures: true
    Notice: /Stage[main]/Heat::Deps/Anchor[heat::service::begin]: Dependency Package[db_backend_package] has failures: true
    Notice: /Stage[main]/Heat::Engine/Service[heat-engine]: Dependency Package[db_backend_package] has failures: true
    Notice: /Stage[main]/Neutron::Deps/Anchor[neutron::dbsync::begin]: Dependency Package[db_backend_package] has failures: true
    Notice: /Stage[main]/Neutron::Deps/Anchor[neutron::dbsync::end]: Dependency Package[db_backend_package] has failures: true
    Notice: /Stage[main]/Neutron::Deps/Anchor[neutron::service::begin]: Dependency Package[db_backend_package] has failures: true
    Notice: /Stage[main]/Nova::Deps/Anchor[nova::dbsync::begin]: Dependency Package[db_backend_package] has failures: true
    (truncated, view all with --long)
  deploy_stderr: |
    ...
    Warning: /Stage[main]/Heat::Deps/Anchor[heat::dbsync::begin]: Skipping because of failed dependencies
    Warning: /Stage[main]/Heat::Db::Sync/Exec[heat-dbsync]: Skipping because of failed dependencies
    Warning: /Stage[main]/Heat::Deps/Anchor[heat::dbsync::end]: Skipping because of failed dependencies
    Warning: /Stage[main]/Heat::Deps/Anchor[heat::service::begin]: Skipping because of failed dependencies
    Warning: /Stage[main]/Heat::Engine/Service[heat-engine]: Skipping because of failed dependencies
    Warning: /Stage[main]/Neutron::Deps/Anchor[neutron::dbsync::begin]: Skipping because of failed dependencies
    Warning: /Stage[main]/Neutron::Deps/Anchor[neutron::dbsync::end]: Skipping because of failed dependencies
    Warning: /Stage[main]/Neutron::Deps/Anchor[neutron::service::begin]: Skipping because of failed dependencies
    Warning: /Stage[main]/Nova::Deps/Anchor[nova::dbsync::begin]: Skipping because of failed dependencies
    Error: Failed to apply catalog: Cannot allocate memory - fork(2)
    (truncated, view all with --long)

참고로 위와 같은 cannot allocate memory가 나오는 이유는 OOM 현상으로 VM상에서 openstack을 운영중에 새로운 compute node를 
추가하는 경우 memory가 부족한 상황이다.

아래의 사이트에 step별로 잘 설명이 되어 있다. 참고하자
- https://images.rdoproject.org/docs/baremetal/introduction.html

참고사이트

- http://docs.openstack.org/developer/tripleo-docs/troubleshooting/troubleshooting-overcloud.html

- http://docs.openstack.org/developer/tripleo-docs/environments/virtual.html

- https://bugs.launchpad.net/tripleo/+bug/1666227


'' 카테고리의 다른 글

spice console  (0) 2017.06.19
error message about mysql is not running with galera  (0) 2017.06.15
no valid host error  (0) 2017.06.13
can not delete loadbalancer by pending_create state  (0) 2017.04.25
autoscaling with heat  (3) 2017.01.23
tripleO  (0) 2016.10.19
댓글
댓글쓰기 폼