OSP 디렉터 운영자는 OpenShift 위에 일련의 사용자 정의 리소스 정의를 만들어 Tripleo의 언더 클라우드에 의해 일반적으로 생성 된 리소스를 관리합니다. 이 CRD는 하드웨어 프로비저닝 및 소프트웨어 구성을 위해 두 가지 유형으로 나뉩니다.
OSP 이사 운영자는 OLM 운영자 Lifecycle Manager를 통해 설치 및 관리됩니다. OLM은 OpenShift 설치를 통해 자동으로 설치됩니다. 최신 OSP 디렉터 운영자 스냅 샷을 얻으려면 OLM으로 설치를 주도하려면 적절한 카탈로그 소스, 운영자 그룹 및 구독을 만들어야합니다.
oc new-project openstack
apiVersion : operators.coreos.com/v1alpha1
kind : CatalogSource
metadata :
name : osp-director-operator-index
namespace : openstack
spec :
sourceType : grpc
image : quay.io/openstack-k8s-operators/osp-director-operator-index:0.0.1
apiVersion : operators.coreos.com/v1
kind : OperatorGroup
metadata :
name : " osp-director-operator-group "
namespace : openstack
spec :
targetNamespaces :
- openstack
apiVersion : operators.coreos.com/v1alpha1
kind : Subscription
metadata :
name : osp-director-operator-subscription
namespace : openstack
spec :
config :
env :
- name : WATCH_NAMESPACE
value : openstack,openshift-machine-api,openshift-sriov-network-operator
source : osp-director-operator-index
sourceNamespace : openstack
name : osp-director-operator
startingCSV : osp-director-operator.v0.0.1
channel : alpha
특정 태그를 위해 OLM을 사용하여 설치를 자동화하는 스크립트가 있습니다. 설치를 자동화하기위한 스크립트
참고 : 향후 어느 시점에서 우리는 OSP 설치 기본 OLM 카탈로그 소스에서 OSP 디렉터 운영자를 자동으로 사용할 수 있도록 OperaterHub에 통합 할 수 있습니다.
OpenStack을 배포하기 전에 Base Rhel 데이터 볼륨을 만듭니다. 이것은 OpenShift 가상화를 통해 프로비저닝되는 컨트롤러 VM에 의해 사용됩니다. 이를 수행하는 방법은 다음과 같습니다.
virtctl
: sudo subscription-manager repos --enable=cnv-2.6-for-rhel-8-x86_64-rpms
sudo dnf install -y kubevirt-virtctl
curl -O http://download.devel.redhat.com/brewroot/packages/rhel-guest-image/8.4/1168/images/rhel-guest-image-8.4-1168.x86_64.qcow2
dnf install -y libguestfs-tools-c
virt-customize -a < rhel guest image > --run-command ' sed -i -e "s/^(kernelopts=.*)net.ifnames=0 (.*)/12/" /boot/grub2/grubenv '
virt-customize -a < rhel guest image > --run-command ' sed -i -e "s/^(GRUB_CMDLINE_LINUX=.*)net.ifnames=0 (.*)/12/" /etc/default/grub '
/etc/hosts
에 다음을 추가하십시오. <cluster ingress VIP> cdi-uploadproxy-openshift-cnv.apps.<cluster name>.<domain name>
virtctl
을 통해 이미지를 OpenShift 가상화로 업로드하십시오. virtctl image-upload dv openstack-base-img -n openstack --size=50Gi --image-path=<local path to image> --storage-class <desired storage class> --insecure
storage-class
의 경우 다음에 표시된 것 중에서 사용하려는 것을 선택하십시오. oc get storageclass
OpenStackNetConfig 사용자 정의 리소스를 정의하십시오. CTLPLANE에는 하나 이상의 네트워크가 필요합니다. 선택적으로 CR의 여러 네트워크를 정의하여 Tripleo의 네트워크 격리 아키텍처와 함께 사용될 수 있습니다. OpenStackNet에는 네트워크 정의 외에도 OpenShift 가상화를 통해 VM을이 네트워크에 첨부하는 데 사용되는 네트워크 구성 정책을 정의하는 데 사용되는 정보가 포함되어 있습니다. 다음은 호스트 구성을 위해 Linux Bridge를 사용하는 간단한 IPv4 CTLPLANE 네트워크의 예입니다.
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackNetConfig
metadata :
name : openstacknetconfig
spec :
attachConfigurations :
br-osp :
nodeNetworkConfigurationPolicy :
nodeSelector :
node-role.kubernetes.io/worker : " "
desiredState :
interfaces :
- bridge :
options :
stp :
enabled : false
port :
- name : enp7s0
description : Linux bridge with enp7s0 as a port
name : br-osp
state : up
type : linux-bridge
mtu : 1500
# optional DnsServers list
dnsServers :
- 192.168.25.1
# optional DnsSearchDomains list
dnsSearchDomains :
- osptest.test.metalkube.org
- some.other.domain
# DomainName of the OSP environment
domainName : osptest.test.metalkube.org
networks :
- name : Control
nameLower : ctlplane
subnets :
- name : ctlplane
ipv4 :
allocationEnd : 192.168.25.250
allocationStart : 192.168.25.100
cidr : 192.168.25.0/24
gateway : 192.168.25.1
attachConfiguration : br-osp
# optional: (OSP17 only) specify all phys networks with optional MAC address prefix, used to
# create static OVN Bridge MAC address mappings. Unique OVN bridge mac address per node is
# dynamically allocated by creating OpenStackMACAddress resource and create a MAC per physnet per node.
# - If PhysNetworks is not provided, the tripleo default physnet datacentre gets created.
# - If the macPrefix is not specified for a physnet, the default macPrefix "fa:16:3a" is used.
# - If PreserveReservations is not specified, the default is true.
ovnBridgeMacMappings :
preserveReservations : True
physNetworks :
- macPrefix : fa:16:3a
name : datacentre
- macPrefix : fa:16:3b
name : datacentre2
# optional: configure static mapping for the networks per nodes. If there is none, a random gets created
reservations :
controller-0 :
macReservations :
datacentre : fa:16:3a:aa:aa:aa
datacentre2 : fa:16:3b:aa:aa:aa
compute-0 :
macReservations :
datacentre : fa:16:3a:bb:bb:bb
datacentre2 : fa:16:3b:bb:bb:bb
위의 YAML을 NetworkConfig.yaml이라는 파일에 쓰면이 명령을 통해 OpenStackNetConfig를 만들 수 있습니다.
oc create -n openstack -f networkconfig.yaml
VLAN을 사용하여 네트워크 격리를 사용하려면 네트워크 정의 사양에 VLAN ID를 추가합니다.
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackNetConfig
metadata :
name : openstacknetconfig
spec :
attachConfigurations :
br-osp :
nodeNetworkConfigurationPolicy :
nodeSelector :
node-role.kubernetes.io/worker : " "
desiredState :
interfaces :
- bridge :
options :
stp :
enabled : false
port :
- name : enp7s0
description : Linux bridge with enp7s0 as a port
name : br-osp
state : up
type : linux-bridge
mtu : 1500
br-ex :
nodeNetworkConfigurationPolicy :
nodeSelector :
node-role.kubernetes.io/worker : " "
desiredState :
interfaces :
- bridge :
options :
stp :
enabled : false
port :
- name : enp6s0
description : Linux bridge with enp6s0 as a port
name : br-ex-osp
state : up
type : linux-bridge
mtu : 1500
# optional DnsServers list
dnsServers :
- 192.168.25.1
# optional DnsSearchDomains list
dnsSearchDomains :
- osptest.test.metalkube.org
- some.other.domain
# DomainName of the OSP environment
domainName : osptest.test.metalkube.org
networks :
- name : Control
nameLower : ctlplane
subnets :
- name : ctlplane
ipv4 :
allocationEnd : 192.168.25.250
allocationStart : 192.168.25.100
cidr : 192.168.25.0/24
gateway : 192.168.25.1
attachConfiguration : br-osp
- name : InternalApi
nameLower : internal_api
mtu : 1350
subnets :
- name : internal_api
attachConfiguration : br-osp
vlan : 20
ipv4 :
allocationEnd : 172.17.0.250
allocationStart : 172.17.0.10
cidr : 172.17.0.0/24
- name : External
nameLower : external
subnets :
- name : external
ipv6 :
allocationEnd : 2001:db8:fd00:1000:ffff:ffff:ffff:fffe
allocationStart : 2001:db8:fd00:1000::10
cidr : 2001:db8:fd00:1000::/64
gateway : 2001:db8:fd00:1000::1
attachConfiguration : br-ex
- name : Storage
nameLower : storage
mtu : 1350
subnets :
- name : storage
ipv4 :
allocationEnd : 172.18.0.250
allocationStart : 172.18.0.10
cidr : 172.18.0.0/24
vlan : 30
attachConfiguration : br-osp
- name : StorageMgmt
nameLower : storage_mgmt
mtu : 1350
subnets :
- name : storage_mgmt
ipv4 :
allocationEnd : 172.19.0.250
allocationStart : 172.19.0.10
cidr : 172.19.0.0/24
vlan : 40
attachConfiguration : br-osp
- name : Tenant
nameLower : tenant
vip : False
mtu : 1350
subnets :
- name : tenant
ipv4 :
allocationEnd : 172.20.0.250
allocationStart : 172.20.0.10
cidr : 172.20.0.0/24
vlan : 50
attachConfiguration : br-osp
Linux-Bridge와 함께 네트워크 격리에 VLAN을 사용할 때
참고 : 브리지에 점보 프레임을 사용하려면 장치가 Correnct MTU를 구성하기위한 구성을 만듭니다.
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackNetConfig
metadata :
name : openstacknetconfig
spec :
attachConfigurations :
br-osp :
nodeNetworkConfigurationPolicy :
nodeSelector :
node-role.kubernetes.io/worker : " "
desiredState :
interfaces :
- bridge :
options :
stp :
enabled : false
port :
- name : enp7s0
description : Linux bridge with enp7s0 as a port
name : br-osp
state : up
type : linux-bridge
mtu : 9000
- name : enp7s0
description : Configuring enp7s0 on workers
type : ethernet
state : up
mtu : 9000
Tripleo 네트워크 구성에 사용되는 사용자 정의 열 환경, 열 템플릿 및 사용자 정의 역할 파일 (이름은 roles_data.yaml
이어야 함)을 정의하는 구성 맵을 만듭니다. 모든 관리자 정의 열 환경 파일은 configmap에 제공 될 수 있으며 오버 클라우드 배치를 위해 열 스택을 생성하는 데 사용되는 이후 단계에서 컨벤션으로 사용됩니다. 컨벤션으로 각 OSP 디렉터 설치는 heat-env-config
와 tripleo-tarball-config
Config라는 2 개의 구성을 사용 하여이 정보를 제공합니다. heat-env-config
CONFIGMAP는 각 파일이 openstack stack create
명령에 -e file.yaml
로 추가되는 모든 배포 환경 파일을 보유합니다. 좋은 예는 다음과 같습니다.
"Tarball Config Map"은 플레이 북이 생성 될 때 트리플 로열 테일 테이트에서 추출되는 (이진) 타르 볼을 제공하는 데 사용될 수 있습니다. 각 Tarball에는 THT 디렉토리의 루트와 관련된 파일 디렉토리가 포함되어야합니다. 사용자 정의 타르 볼이 포함 된 구성 맵에 다음 예제와 같은 것들을 저장하고 싶을 것입니다.
net-config 파일.
NET-CONFIG 환경
참고 : 가상 머신의 Net-Config 파일은 연산자가 생성하지만 "Tarball Config Map"을 사용하여 덮어 쓰일 수 있습니다. 사전 렌더링 된 Net-Config를 덮어 쓰려면 OSP16.2의 경우 <role lowercase>-nic-template.yaml
<role lowercase>-nic-template.j2
이름을 사용하십시오. 참고 : OpenStackVMSet 컨트롤러에서 생성 한 VM의 네트워크 인터페이스 이름은 VM 역할에 할당 된 네트워크 이름에 의해 알파벳 순서입니다. VM POD의 default
네트워크 인터페이스는 항상 첫 번째 인터페이스입니다. 가상 머신 정의의 결과 Inteface 섹션은 다음과 같습니다.
interfaces :
- masquerade : {}
model : virtio
name : default
- bridge : {}
model : virtio
name : ctlplane
- bridge : {}
model : virtio
name : external
- bridge : {}
model : virtio
name : internalapi
- bridge : {}
model : virtio
name : storage
- bridge : {}
model : virtio
name : storagemgmt
- bridge : {}
model : virtio
name : tenant
이를 통해 CTLPLANE 인터페이스는 NIC2, 외부 NIC3 등입니다.
참고 : FIP 트래픽은 ML2/OVN 및 DVR을 사용하여 VLAN 테넌트 네트워크로 전달하지 않습니다. DVR은 기본적으로 활성화됩니다. OVN이있는 VLAN 테넌트 네트워크가 필요한 경우 DVR을 비활성화 할 수 있습니다. DVR을 비활성화하려면 환경 파일에 다음 줄을 포함시킵니다.
parameter_defaults :
NeutronEnableDVR : false
"OVN의 배포 된 VLAN 트래픽"에 대한 지원은 "OVN의 분산 VLAN 트래픽에 대한 Tripleo의 지원 추가"(https://bugs.launchpad.net/tripleo/+bug/1881593)에서 MAC 주소 관리에서 추적됩니다.
[git repo config map]이 configmap에는 생성 된 플레이 북을 저장하는 데 사용되는 git repo의 SSH 키와 URL이 포함되어 있습니다 (아래)
환경에 대한 위의 템플릿/예제를 사용자 정의하면 각각의 각 configmap 유형을 포함하는 파일 에이 예제 명령을 사용하여 '열-엔브-코피그'및 'Tripleo-Tarball-Config'(Tarballs) 구성 맵에 대한 구성 맵을 만들 수 있습니다. (각 유형의 구성 맵에 대한 하나의 디렉토리) :
# create the configmap for heat-env-config
oc create configmap -n openstack heat-env-config --from-file=heat-env-config/ --dry-run=client -o yaml | oc apply -f -
# create the configmap containing a tarball of t-h-t network config files. NOTE: these files may overwrite default t-h-t files so keep this in mind when naming them.
cd < dir with net config files >
tar -cvzf net-config.tar.gz * .yaml
oc create configmap -n openstack tripleo-tarball-config --from-file=tarball-config.tar.gz
# create the Git secret used for the repo where Ansible playbooks are stored
oc create secret generic git-secret -n openstack --from-file=git_ssh_identity= < path to git id_rsa > --from-literal=git_url= < your git server URL (git@...) >
(선택 사항) OpenStackControlPlane에 대한 비밀을 만듭니다. 이 비밀은 가상 머신 및 Baremetal 호스트의 기본 비밀번호를 제공합니다. 비밀이 제공되지 않으면 OSP-Controlplane-SSH-Keys 비밀에 정의 된 SSH 키로 만 로그인 할 수 있습니다.
apiVersion : v1
kind : Secret
metadata :
name : userpassword
namespace : openstack
data :
# 12345678
NodeRootPassword : MTIzNDU2Nzg=
위의 YAML을 ctlplane-secret.yaml이라는 파일에 작성하면이 명령을 통해 비밀을 만들 수 있습니다.
oc create -n openstack -f ctlplane-secret.yaml
OpenStackControlPlane 사용자 정의 리소스를 정의하십시오. OpenStackControlPlane Custom Resource는 배포를위한 추가 VMSET과 함께 OSP 컨트롤러에 사용되는 VM을 생성하고 확장 할 수있는 중앙 장소를 제공합니다. 기본 데모 설치에는 최소 1 개의 컨트롤러 VM이 필요하며 OSP 당 고 가용성 지침 3 컨트롤러 VM이 권장됩니다.
참고 : RHEL-GUEST-IMAGE가 OpenStackControlPlane Virtual Machines를 배포하기 위해 기본으로 사용되는 경우 NET.IFNAMES = 0 커널 매개 변수를 제거하여 BiOSDEV 네트워크 인터페이스 이름 지정을 갖도록하십시오. 이것은 다음과 같이 할 수 있습니다.
dnf install -y libguestfs-tools-c
virt-customize -a bms-image.qcow2 --run-command ' sed -i -e "s/^(kernelopts=.*)net.ifnames=0 (.*)/12/" /boot/grub2/grubenv '
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackControlPlane
metadata :
name : overcloud
namespace : openstack
spec :
openStackClientImageURL : quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210713.1
openStackClientNetworks :
- ctlplane
- external
- internalapi
# openStackClientStorageClass must support RWX
# https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes
openStackClientStorageClass : host-nfs-storageclass
passwordSecret : userpassword
gitSecret : git-secret
virtualMachineRoles :
controller :
roleName : Controller
roleCount : 3
networks :
- ctlplane
- internalapi
- external
- tenant
- storage
- storagemgmt
cores : 6
memory : 12
rootDisk :
diskSize : 50
baseImageVolumeName : openstack-base-img
# storageClass must support RWX to be able to live migrate VMs
storageClass : host-nfs-storageclass
storageAccessMode : ReadWriteMany
# When using OpenShift Virtualization with OpenShift Container Platform Container Storage,
# specify RBD block mode persistent volume claims (PVCs) when creating virtual machine disks. With virtual machine disks,
# RBD block mode volumes are more efficient and provide better performance than Ceph FS or RBD filesystem-mode PVCs.
# To specify RBD block mode PVCs, use the 'ocs-storagecluster-ceph-rbd' storage class and VolumeMode: Block.
storageVolumeMode : Filesystem
# Optional
# DedicatedIOThread - Disks with dedicatedIOThread set to true will be allocated an exclusive thread.
# This is generally useful if a specific Disk is expected to have heavy I/O traffic, e.g. a database spindle.
dedicatedIOThread : false
additionalDisks :
# name must be uniqe and must not be rootDisk
- name : dataDisk1
diskSize : 100
storageClass : host-nfs-storageclass
storageAccessMode : ReadWriteMany
storageVolumeMode : Filesystem
# Optional block storage settings
# IOThreadsPolicy - IO thread policy for the domain. Currently valid policies are shared and auto.
# However, if any disk requests a dedicated IOThread, ioThreadsPolicy will be enabled and default to shared.
# When ioThreadsPolicy is set to auto IOThreads will also be "isolated" from the vCPUs and placed on the same physical CPU as the QEMU emulator thread.
# An ioThreadsPolicy of shared indicates that KubeVirt should use one thread that will be shared by all disk devices.
ioThreadsPolicy : auto
# Block Multi-Queue is a framework for the Linux block layer that maps Device I/O queries to multiple queues.
# This splits I/O processing up across multiple threads, and therefor multiple CPUs. libvirt recommends that the
# number of queues used should match the number of CPUs allocated for optimal performance.
blockMultiQueue : false
위의 YAML을 OpenStackControlPlane.yaml이라는 파일에 작성하면이 명령을 통해 OpenStackControlPlane을 만들 수 있습니다.
oc create -f openstackcontrolplane.yaml
참고 동일한 VMSET (VM REL) 내의 VM 참고 POD 안티 친화도 규칙 (PreferredDuringschedulingIgnoduringExecution)을 사용하여 사용 가능한 작업자 노드 전체에 배포됩니다. 이를 통해 다른 리소스를 사용할 수없는 경우 (예 : 업데이트 중에 작업자 재부팅) 다른 작업자 노드에서 여러 역할이 끝날 수 있습니다. 유지 보수/재부팅 후 노드가 나오면 자동 라이브 마이그레이션이 발생하지 않습니다. 다음 일정 요청에서 VM이 다시 재배치됩니다.
OSP Compute 호스트를 확장하기 위해 OpenStackBaremetalset을 정의하십시오. OpenStackBaremetal 리소스는 자원 계산을 정의하고 스케일링하는 데 사용될 수 있으며 선택적으로 다른 유형의 트리플로 역할에 대한 Baremetal 호스트를 정의하고 확장하는 데 사용됩니다. 아래의 예는 작성할 단일 컴퓨팅 호스트를 정의합니다.
참고 : RHEL-GUEST-IMAGE가 OpenStackBaremetalset Compute 노드를 배포하기 위해 기본으로 사용되는 경우 Net.ifnames = 0 커널 매개 변수를 제거하여 BioSDEV 네트워크 인터페이스 명명을 갖도록하십시오. 이것은 다음과 같이 할 수 있습니다.
dnf install -y libguestfs-tools-c
virt-customize -a bms-image.qcow2 --run-command ' sed -i -e "s/^(kernelopts=.*)net.ifnames=0 (.*)/12/" /boot/grub2/grubenv '
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBaremetalSet
metadata :
name : compute
namespace : openstack
spec :
# How many nodes to provision
count : 1
# The image to install on the provisioned nodes. NOTE: needs to be accessible on the OpenShift Metal3 provisioning network.
baseImageUrl : http://host/images/rhel-image-8.4.x86_64.qcow2
# NOTE: these are automatically created via the OpenStackControlplane CR above
deploymentSSHSecret : osp-controlplane-ssh-keys
# The interface on the nodes that will be assigned an IP from the mgmtCidr
ctlplaneInterface : enp7s0
# Networks to associate with this host
networks :
- ctlplane
- internalapi
- tenant
- storage
roleName : Compute
passwordSecret : userpassword
위의 YAML을 Compute.yaml이라는 파일에 작성하면이 명령을 통해 OpenStackBaremetalset을 만들 수 있습니다.
oc create -f compute.yaml
노드 등록 (오버 클라우드 시스템을 필수 채널에 등록)
위의 리소스가 배포를 완료 할 때까지 기다립니다 (Compute 및 ControlPlane). 리소스가 완료되면 배포가 노드 등록으로 진행됩니다.
5.9에 설명 된대로 절차를 사용하십시오. ansible 기반 등록을 수동으로 실행하면 그렇게됩니다.
참고 : 기본 이미지 선택에 관계없이 작동하므로 수동 등록을 사용하는 것이 좋습니다. 기본 배포 이미지로서 오버 클라우드를 사용하는 경우 THT RHSM.YAML 환경 역할/파일을 통해 자동 RHSM 등록을 사용할 수 있습니다.
oc rsh openstackclient
bash
cd /home/cloud-admin
< create the ansible playbook for the overcloud nodes - e.g. rhsm.yaml >
# register the overcloud nodes to required repositories
ansible-playbook -i /home/cloud-admin/ctlplane-ansible-inventory ./rhsm.yaml
(선택 사항) 역할 생성 파일 a) OpenStackClient POD를 사용하여 사용자 정의 역할 파일을 생성합니다.
oc rsh openstackclient
unset OS_CLOUD
cd /home/cloud-admin/
openstack overcloud roles generate Controller ComputeHCI > roles_data.yaml
exit
b) OpenStackClient POD에서 사용자 정의 역할 파일 복사
oc cp openstackclient:/home/cloud-admin/roles_data.yaml roles_data.yaml
tarballConfigMap
configmap을 업데이트하여 roles_data.yaml
파일을 Tarball에 추가하고 configmap을 업데이트하십시오.
참고 : roles_data.yaml
파일 이름으로 사용하십시오.
OpenStackConfigGenerator를 정의하여 OSP 클러스터 배포를위한 Ansible Playbook을 생성하십시오.
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackConfigGenerator
metadata :
name : default
namespace : openstack
spec :
enableFencing : False
imageURL : quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210713.1
gitSecret : git-secret
heatEnvConfigMap : heat-env-config
tarballConfigMap : tripleo-tarball-config
# (optional) for debugging it is possible to set the interactive mode.
# In this mode the playbooks won't get rendered automatically. Just the environment to start the rendering gets created
# interactive: true
# (optional) provide custom registry or specific container versions via the ephemeralHeatSettings
# ephemeralHeatSettings:
# heatAPIImageURL: quay.io/tripleotraincentos8/centos-binary-heat-api:current-tripleo
# heatEngineImageURL: quay.io/tripleotraincentos8/centos-binary-heat-engine:current-tripleo
# mariadbImageURL: quay.io/tripleotraincentos8/centos-binary-mariadb:current-tripleo
# rabbitImageURL: quay.io/tripleotraincentos8/centos-binary-rabbitmq:current-tripleo
위의 YAML을 Generator.yaml이라는 파일에 작성하면이 명령을 통해 OpenStackConfigGenerator를 만들 수 있습니다.
oc create -f generator.yaml
위에서 생성 된 OsconFigGenerator는 OST 배치의 구성 맵을 확장하거나 수정할 때마다 플레이 북을 자동으로 생성합니다. 이 플레이 북을 생성하는 데 몇 분이 걸립니다. OsconFigGenerator의 상태 조건을 모니터링하여 완료 할 수 있습니다.
최신 OSCONFIGVERSION (Ansible Playbooks)을 얻으십시오. 다음 단계에서 사용하려면 최신 OsconFigversion의 해시/다이제스트를 선택하십시오.
oc get -n openstack --sort-by {.metadata.creationTimestamp} osconfigversions -o json
참고 : osconfigversion 객체에는 Ansible Playbook 버전 간의 변경 사항을 쉽게 비교하는 데 사용할 수있는 'git diff'속성이 있습니다.
OSDEPLOY 만들기 (ansible playbooks 실행)
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackDeploy
metadata :
name : default
spec :
configVersion : n5fch96h548h75hf4hbdhb8hfdh676h57bh96h5c5h59hf4h88h...
configGenerator : default
위의 YAML을 deploy.yaml이라는 파일에 쓰면이 명령을 통해 OpenStackDeploy를 만들 수 있습니다.
oc create -f deploy.yaml
배포가 실행되면 kubernetes 작업이 생성되어 Ansible Playbook을 실행합니다. 이 작업/포드의 로그를 꼬리시켜 Ansible Playbook이 실행되는 것을 볼 수 있습니다. 또한 'OpenStackClient'포드에 로그인하여/home/cloud-admin/work // directory로 이동하여 실행 된 Ansible Playbook에 수동으로 액세스 할 수 있습니다. 거기에서 실행중인 배포를위한 Ansible.log 파일과 함께 Ansible Playbook을 찾을 수 있습니다.
컴퓨팅 노드가 CEPH OSD 노드 역할을하는 Tripleo의 하이퍼 컨버전 인프라를 배포 할 수 있습니다. Tripleo를 통해 Ceph를 설치하는 워크 플로는 다음과 같습니다.
OpenStackClient openStackClientImageURL
에 대해 quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210521.1
이상을 사용하십시오.
추가 디스크가있는 컴퓨팅 노드를 OSDS로 사용할 수 있고 기본 컴퓨팅 네트워크 및 IsHCI
매개 변수 외에도 StoragemGMT 네트워크를 갖는 ComputeHCI 역할을위한 BaremetalSet을 작성하십시오.
참고 : RHEL-GUEST-IMAGE가 OpenStackBaremetalset Compute 노드를 배포하기 위해 기본으로 사용되는 경우 NET.IFNAMES = 0 커널 매개 변수는 이미지를 형성하여 BiOSDEV 네트워크 인터페이스 명명을 갖습니다. 이것은 다음과 같이 할 수 있습니다.
dnf install -y libguestfs-tools-c
virt-customize -a bms-image.qcow2 --run-command ' sed -i -e "s/^(kernelopts=.*)net.ifnames=0 (.*)/12/" /boot/grub2/grubenv '
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBaremetalSet
metadata :
name : computehci
namespace : openstack
spec :
# How many nodes to provision
replicas : 2
# The image to install on the provisioned nodes
baseImageUrl : http://host/images/rhel-image-8.4.x86_64.qcow2
# The secret containing the SSH pub key to place on the provisioned nodes
deploymentSSHSecret : osp-controlplane-ssh-keys
# The interface on the nodes that will be assigned an IP from the mgmtCidr
ctlplaneInterface : enp7s0
# Networks to associate with this host
networks :
- ctlplane
- internalapi
- tenant
- storage
- storagemgmt
roleName : ComputeHCI
passwordSecret : userpassword
Deploying OpenStack once you have the OSP Director Operator installed
섹션에 설명 된 역할 파일 작성/usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml
에서 Ceph 관련 배포 매개 변수를 추가하고 Tripleo 배포 사용자 정의 configmap, eG storage-backend.yaml
에 다른 사용자 정의 : resource_registry :
OS::TripleO::Services::CephMgr : deployment/ceph-ansible/ceph-mgr.yaml
OS::TripleO::Services::CephMon : deployment/ceph-ansible/ceph-mon.yaml
OS::TripleO::Services::CephOSD : deployment/ceph-ansible/ceph-osd.yaml
OS::TripleO::Services::CephClient : deployment/ceph-ansible/ceph-client.yaml
parameter_defaults :
# needed for now because of the repo used to create tripleo-deploy image
CephAnsibleRepo : " rhelosp-ceph-4-tools "
CephAnsiblePlaybookVerbosity : 3
CinderEnableIscsiBackend : false
CinderEnableRbdBackend : true
CinderBackupBackend : ceph
CinderEnableNfsBackend : false
NovaEnableRbdBackend : true
GlanceBackend : rbd
CinderRbdPoolName : " volumes "
NovaRbdPoolName : " vms "
GlanceRbdPoolName : " images "
CephPoolDefaultPgNum : 32
CephPoolDefaultSize : 2
CephAnsibleDisksConfig :
devices :
- ' /dev/sdb '
- ' /dev/sdc '
- ' /dev/sdd '
osd_scenario : lvm
osd_objectstore : bluestore
CephAnsibleExtraConfig :
is_hci : true
CephConfigOverrides :
rgw_swift_enforce_content_length : true
rgw_swift_versioning_enabled : true
환경에 대한 위의 템플릿/예제를 사용자 정의하면 Deploying OpenStack once you have the OSP Director Operator installed
Deploying OpenStack once you have the OSP Director Operator installed
에서와 같이 OSP 클러스터 배포 용 Ansible Playbook을 생성하고 역할을 생성 한 역할 파일을 지정하십시오. 참고 : osconfiggenerator imageURL
에 대해 quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210521.1
이상을 사용하십시오.
OpenStackConfigGenerator가 플레이 북 렌더링 작업을 완료 할 때까지 기다리십시오.
최신 OpenStackConfigversion의 해시/다이제스트를 얻습니다.
지정된 OpenStackConfigversion에 대한 OpenStackDeploy를 만듭니다. 이것은 Ansible Playbook을 배포합니다.
Baremetal Compute 호스트를 제거하려면 다음 단계가 필요합니다.
Compute 노드가 제거되는 경우 Overcloud의 나가는 노드에서 Compute 서비스를 비활성화하여 Node가 새 인스턴스를 예약하지 않도록합니다.
openstack compute service list
openstack compute service set < hostname > nova-compute --disable
BMH 자원의 주석
oc annotate -n openshift-machine-api bmh/openshift-worker-3 osp-director.openstack.org/delete-host=true --overwrite
주석 상태는 annotatedForDeletion
매개 변수를 사용하여 osbaremetalset/osvmset에 반영됩니다.
oc get osbms computehci -o json | jq .status
{
" baremetalHosts " : {
" computehci-0 " : {
" annotatedForDeletion " : true,
" ctlplaneIP " : " 192.168.25.105/24 " ,
" hostRef " : " openshift-worker-3 " ,
" hostname " : " computehci-0 " ,
" networkDataSecretName " : " computehci-cloudinit-networkdata-openshift-worker-3 " ,
" provisioningState " : " provisioned " ,
" userDataSecretName " : " computehci-cloudinit-userdata-openshift-worker-3 "
},
" computehci-1 " : {
" annotatedForDeletion " : false,
" ctlplaneIP " : " 192.168.25.106/24 " ,
" hostRef " : " openshift-worker-4 " ,
" hostname " : " computehci-1 " ,
" networkDataSecretName " : " computehci-cloudinit-networkdata-openshift-worker-4 " ,
" provisioningState " : " provisioned " ,
" userDataSecretName " : " computehci-cloudinit-userdata-openshift-worker-4 "
}
},
" provisioningStatus " : {
" readyCount " : 2,
" reason " : " All requested BaremetalHosts have been provisioned " ,
" state " : " provisioned "
}
}
Osbaremetalset의 리소스 수를 줄이면 Corrensponding 컨트롤러가 트리거되어 리소스 삭제를 처리합니다.
oc patch osbms computehci --type=merge --patch ' {"spec":{"count":1}} '
결과적으로:
oc get osnet ctlplane -o json | jq .status.roleReservations.ComputeHCI
{
" addToPredictableIPs " : true,
" reservations " : [
{
" deleted " : true,
" hostname " : " computehci-0 " ,
" ip " : " 192.168.25.105 " ,
" vip " : false
},
{
" deleted " : false,
" hostname " : " computehci-1 " ,
" ip " : " 192.168.25.106 " ,
" vip " : false
}
]
}
이것은 다음 행동을 초래합니다
현재 컴퓨팅 노드가 제거되면 OpenStack 제어 평면에 등록 된 몇 개의 남은 항목이 있으며 자동으로 정리되지 않습니다. 정리하려면 다음 단계를 수행하십시오.
openstack compute service list
openstack compute service delete < service-id >
openstack network agent list
for AGENT in $( openstack network agent list --host < scaled-down-node > -c ID -f value ) ; do openstack network agent delete $AGENT ; done
VM을 제거하려면 다음 단계가 필요합니다.
VM이 제거 전에 비활성화 해야하는 OSP 서비스를 주최하는 경우 그렇게하십시오.
VM 리소스의 주석
oc annotate -n openstack vm/controller-1 osp-director.openstack.org/delete-host=true --overwrite
OpenStackControlPlane CR에서 VirtualMachineroles의 리소스 rolecount 감소. 리소스 삭제를 처리하기위한 Corrensponding 컨트롤러
oc patch osctlplane overcloud --type=merge --patch ' {"spec":{"virtualMachineRoles":{"<RoleName>":{"roleCount":2}}}} '
결과적으로:
이것은 다음 행동을 초래합니다
VM이 제거 해야하는 OSP 서비스를 호스트 한 경우 해당 OpenStack 명령을 사용하여 서비스를 삭제하십시오.
오버 클라우드 리프 네트워크를 구성하기 위해 Tripleo의 라우팅 된 네트워크 (Spine/Leaf Networking) 아키텍처를 배포 할 수 있습니다. 서브넷 매개 변수를 사용하여 기본 네트워크로 추가 리프 서브넷을 정의하십시오.
현재 제한 사항은 Metal3에 대한 하나의 조항 네트워크 만있을 수 있다는 것입니다.
여러 서브넷을 사용하여 오버 클라우드를 설치하는 워크 플로우는 다음과 같습니다.
OpenStackNetConfig 사용자 정의 리소스를 정의하고 오버 클라우드 네트워크의 모든 서브넷을 지정하십시오. 연산자는 중고 OSP 릴리스를 위해 Tripleo Network_Data.yaml을 렌더링합니다.
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackNetConfig
metadata :
name : openstacknetconfig
spec :
attachConfigurations :
br-osp :
nodeNetworkConfigurationPolicy :
nodeSelector :
node-role.kubernetes.io/worker : " "
desiredState :
interfaces :
- bridge :
options :
stp :
enabled : false
port :
- name : enp7s0
description : Linux bridge with enp7s0 as a port
name : br-osp
state : up
type : linux-bridge
mtu : 1500
br-ex :
nodeNetworkConfigurationPolicy :
nodeSelector :
node-role.kubernetes.io/worker : " "
desiredState :
interfaces :
- bridge :
options :
stp :
enabled : false
port :
- name : enp6s0
description : Linux bridge with enp6s0 as a port
name : br-ex-osp
state : up
type : linux-bridge
mtu : 1500
# optional DnsServers list
dnsServers :
- 192.168.25.1
# optional DnsSearchDomains list
dnsSearchDomains :
- osptest.test.metalkube.org
- some.other.domain
# DomainName of the OSP environment
domainName : osptest.test.metalkube.org
networks :
- name : Control
nameLower : ctlplane
subnets :
- name : ctlplane
ipv4 :
allocationEnd : 192.168.25.250
allocationStart : 192.168.25.100
cidr : 192.168.25.0/24
gateway : 192.168.25.1
attachConfiguration : br-osp
- name : InternalApi
nameLower : internal_api
mtu : 1350
subnets :
- name : internal_api
ipv4 :
allocationEnd : 172.17.0.250
allocationStart : 172.17.0.10
cidr : 172.17.0.0/24
routes :
- destination : 172.17.1.0/24
nexthop : 172.17.0.1
- destination : 172.17.2.0/24
nexthop : 172.17.0.1
vlan : 20
attachConfiguration : br-osp
- name : internal_api_leaf1
ipv4 :
allocationEnd : 172.17.1.250
allocationStart : 172.17.1.10
cidr : 172.17.1.0/24
routes :
- destination : 172.17.0.0/24
nexthop : 172.17.1.1
- destination : 172.17.2.0/24
nexthop : 172.17.1.1
vlan : 21
attachConfiguration : br-osp
- name : internal_api_leaf2
ipv4 :
allocationEnd : 172.17.2.250
allocationStart : 172.17.2.10
cidr : 172.17.2.0/24
routes :
- destination : 172.17.1.0/24
nexthop : 172.17.2.1
- destination : 172.17.0.0/24
nexthop : 172.17.2.1
vlan : 22
attachConfiguration : br-osp
- name : External
nameLower : external
subnets :
- name : external
ipv4 :
allocationEnd : 10.0.0.250
allocationStart : 10.0.0.10
cidr : 10.0.0.0/24
gateway : 10.0.0.1
attachConfiguration : br-ex
- name : Storage
nameLower : storage
mtu : 1350
subnets :
- name : storage
ipv4 :
allocationEnd : 172.18.0.250
allocationStart : 172.18.0.10
cidr : 172.18.0.0/24
routes :
- destination : 172.18.1.0/24
nexthop : 172.18.0.1
- destination : 172.18.2.0/24
nexthop : 172.18.0.1
vlan : 30
attachConfiguration : br-osp
- name : storage_leaf1
ipv4 :
allocationEnd : 172.18.1.250
allocationStart : 172.18.1.10
cidr : 172.18.1.0/24
routes :
- destination : 172.18.0.0/24
nexthop : 172.18.1.1
- destination : 172.18.2.0/24
nexthop : 172.18.1.1
vlan : 31
attachConfiguration : br-osp
- name : storage_leaf2
ipv4 :
allocationEnd : 172.18.2.250
allocationStart : 172.18.2.10
cidr : 172.18.2.0/24
routes :
- destination : 172.18.0.0/24
nexthop : 172.18.2.1
- destination : 172.18.1.0/24
nexthop : 172.18.2.1
vlan : 32
attachConfiguration : br-osp
- name : StorageMgmt
nameLower : storage_mgmt
mtu : 1350
subnets :
- name : storage_mgmt
ipv4 :
allocationEnd : 172.19.0.250
allocationStart : 172.19.0.10
cidr : 172.19.0.0/24
routes :
- destination : 172.19.1.0/24
nexthop : 172.19.0.1
- destination : 172.19.2.0/24
nexthop : 172.19.0.1
vlan : 40
attachConfiguration : br-osp
- name : storage_mgmt_leaf1
ipv4 :
allocationEnd : 172.19.1.250
allocationStart : 172.19.1.10
cidr : 172.19.1.0/24
routes :
- destination : 172.19.0.0/24
nexthop : 172.19.1.1
- destination : 172.19.2.0/24
nexthop : 172.19.1.1
vlan : 41
attachConfiguration : br-osp
- name : storage_mgmt_leaf2
ipv4 :
allocationEnd : 172.19.2.250
allocationStart : 172.19.2.10
cidr : 172.19.2.0/24
routes :
- destination : 172.19.0.0/24
nexthop : 172.19.2.1
- destination : 172.19.1.0/24
nexthop : 172.19.2.1
vlan : 42
attachConfiguration : br-osp
- name : Tenant
nameLower : tenant
vip : False
mtu : 1350
subnets :
- name : tenant
ipv4 :
allocationEnd : 172.20.0.250
allocationStart : 172.20.0.10
cidr : 172.20.0.0/24
routes :
- destination : 172.20.1.0/24
nexthop : 172.20.0.1
- destination : 172.20.2.0/24
nexthop : 172.20.0.1
vlan : 50
attachConfiguration : br-osp
- name : tenant_leaf1
ipv4 :
allocationEnd : 172.20.1.250
allocationStart : 172.20.1.10
cidr : 172.20.1.0/24
routes :
- destination : 172.20.0.0/24
nexthop : 172.20.1.1
- destination : 172.20.2.0/24
nexthop : 172.20.1.1
vlan : 51
attachConfiguration : br-osp
- name : tenant_leaf2
ipv4 :
allocationEnd : 172.20.2.250
allocationStart : 172.20.2.10
cidr : 172.20.2.0/24
routes :
- destination : 172.20.0.0/24
nexthop : 172.20.2.1
- destination : 172.20.1.0/24
nexthop : 172.20.2.1
vlan : 52
attachConfiguration : br-osp
위의 YAML을 NetworkConfig.yaml이라는 파일에 쓰면이 명령을 통해 OpenStackNetConfig를 만들 수 있습니다.
oc create -n openstack -f networkconfig.yaml
...
# ##############################################################################
# Role: ComputeLeaf1 #
# ##############################################################################
- name : ComputeLeaf1
description : |
Basic ComputeLeaf1 Node role
# Create external Neutron bridge (unset if using ML2/OVS without DVR)
tags :
- external_bridge
networks :
InternalApi :
subnet : internal_api_leaf1
Tenant :
subnet : tenant_leaf1
Storage :
subnet : storage_leaf1
HostnameFormatDefault : ' %stackname%-novacompute-leaf1-%index% '
...
# ##############################################################################
# Role: ComputeLeaf2 #
# ##############################################################################
- name : ComputeLeaf2
description : |
Basic ComputeLeaf1 Node role
# Create external Neutron bridge (unset if using ML2/OVS without DVR)
tags :
- external_bridge
networks :
InternalApi :
subnet : internal_api_leaf2
Tenant :
subnet : tenant_leaf2
Storage :
subnet : storage_leaf2
HostnameFormatDefault : ' %stackname%-novacompute-leaf2-%index% '
...
tarballConfigMap
configmap을 업데이트하여 roles_data.yaml
파일을 Tarball에 추가하고 configmap을 업데이트하십시오.
참고 : roles_data.yaml
파일 이름으로 사용하십시오.
OSP 16.2 Tripleo NIC 템플릿에는 기본값이 포함 된 인터페이스 아웃 매개 변수가 있습니다. Routes라는 환경/네트워크-환경에서 렌더링 된 경로 매개 변수는 일반적으로 Neutron Network host_routes 속성에 설정되어 역할 인터페이스 아웃 매개 변수에 추가됩니다. 중성자가 없으므로 필요한 경우 {{network.name}} 경로를 NIC 템플릿에 추가하고 두 목록을 동의해야합니다.
parameters:
...
{{ $net.Name }}Routes:
default: []
description: >
Routes for the storage network traffic.
JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
Unless the default is changed, the parameter is automatically resolved
from the subnet host_routes attribute.
type: json
...
- type: interface
...
routes:
list_concat_unique:
- get_param: {{ $net.Name }}Routes
- get_param: {{ $net.Name }}InterfaceRoutes
경로 서브넷 정보는 스크립트에 사용되는 Tripleo 환경 파일 environments/network-environment.yaml
에 자동으로 렌더링됩니다. 따라서 NIC 템플릿에서는 lourse_ <subnet_name> (예 : StoragerOutes_storage_leaf1)을 사용하여 호스트에서 올바른 라우팅을 설정합니다.
computeleaf1 compute 역할을 위해서는 NIC 템플릿을 수정해야합니다.
...
StorageRoutes_storage_leaf1 :
default : []
description : >
Routes for the storage network traffic.
JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
Unless the default is changed, the parameter is automatically resolved
from the subnet host_routes attribute.
type : json
...
InternalApiRoutes_internal_api_leaf1 :
default : []
description : >
Routes for the internal_api network traffic.
JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
Unless the default is changed, the parameter is automatically resolved
from the subnet host_routes attribute.
type : json
...
TenantRoutes_tenant_leaf1 :
default : []
description : >
Routes for the internal_api network traffic.
JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
Unless the default is changed, the parameter is automatically resolved
from the subnet host_routes attribute.
type : json
...
get_param : StorageIpSubnet
routes :
list_concat_unique :
- get_param : StorageRoutes_storage_leaf1
- type : vlan
...
get_param : InternalApiIpSubnet
routes :
list_concat_unique :
- get_param : InternalApiRoutes_internal_api_leaf1
...
get_param : TenantIpSubnet
routes :
list_concat_unique :
- get_param : TenantRoutes_tenant_leaf1
- type : ovs_bridge
...
tarballConfigMap
ConfigMap을 업데이트하여 NIC Templates roles_data.yaml
파일을 TARBALL에 추가하고 구성 맵을 업데이트하십시오.
참고 : roles_data.yaml
파일 이름으로 사용하십시오.
지금까지 OSP16.2만이 다중 서브넷 배포로 테스트되었으며 OSP17.0 단일 서브넷과 호환됩니다.
TBD
새 노드 역할을 위해 새 생성 된 NIC 템플릿을 resource_registry
에 환경 파일에 추가하십시오.
resource_registry :
OS::TripleO::Compute::Net::SoftwareConfig : net-config-two-nic-vlan-compute.yaml
OS::TripleO::ComputeLeaf1::Net::SoftwareConfig : net-config-two-nic-vlan-compute_leaf1.yaml
OS::TripleO::ComputeLeaf2::Net::SoftwareConfig : net-config-two-nic-vlan-compute_leaf2.yaml
이 시점에서 우리는 오버 클라우드를 제공 할 수 있습니다.
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackControlPlane
metadata :
name : overcloud
namespace : openstack
spec :
gitSecret : git-secret
openStackClientImageURL : registry.redhat.io/rhosp-rhel8/openstack-tripleoclient:16.2
openStackClientNetworks :
- ctlplane
- external
- internal_api
- internal_api_leaf1 # optionally the openstackclient can also be connected to subnets
openStackClientStorageClass : host-nfs-storageclass
passwordSecret : userpassword
domainName : ostest.test.metalkube.org
virtualMachineRoles :
Controller :
roleName : Controller
roleCount : 1
networks :
- ctlplane
- internal_api
- external
- tenant
- storage
- storage_mgmt
cores : 6
memory : 20
rootDisk :
diskSize : 40
baseImageVolumeName : controller-base-img
storageClass : host-nfs-storageclass
storageAccessMode : ReadWriteMany
storageVolumeMode : Filesystem
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBaremetalSet
metadata :
name : computeleaf1
namespace : openstack
spec :
# How many nodes to provision
count : 1
# The image to install on the provisioned nodes
baseImageUrl : http://192.168.111.1/images/rhel-guest-image-8.4-1168.x86_64.qcow2
provisionServerName : openstack
# The secret containing the SSH pub key to place on the provisioned nodes
deploymentSSHSecret : osp-controlplane-ssh-keys
# The interface on the nodes that will be assigned an IP from the mgmtCidr
ctlplaneInterface : enp7s0
# Networks to associate with this host
networks :
- ctlplane
- internal_api_leaf1
- external
- tenant_leaf1
- storage_leaf1
roleName : ComputeLeaf1
passwordSecret : userpassword
apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBaremetalSet
metadata :
name : computeleaf2
namespace : openstack
spec :
# How many nodes to provision
count : 1
# The image to install on the provisioned nodes
baseImageUrl : http://192.168.111.1/images/rhel-guest-image-8.4-1168.x86_64.qcow2
provisionServerName : openstack
# The secret containing the SSH pub key to place on the provisioned nodes
deploymentSSHSecret : osp-controlplane-ssh-keys
# The interface on the nodes that will be assigned an IP from the mgmtCidr
ctlplaneInterface : enp7s0
# Networks to associate with this host
networks :
- ctlplane
- internal_api_leaf2
- external
- tenant_leaf2
- storage_leaf2
roleName : ComputeLeaf2
passwordSecret : userpassword
OpenStackConfigGenerator를 정의하여 Deploying OpenStack once you have the OSP Director Operator installed
에서와 같이 OSP 클러스터 배포 용 Ansible Playbook을 생성하고 역할을 생성 한 역할 파일을 지정하십시오.
앞에서 설명한대로 Run the software deployment
, 적용하고, 오버 클라우드 노드를 필요한 리포지토리에 등록하고 OpenStackClient POD 내부에서 SOFWARE 배포를 실행하십시오.
OSP-D 연산자는 현재 CR, 구성 및 비밀 구성의 백업을 생성하고 복원 할 수있는 API를 제공합니다. 이 API는 두 개의 CRD로 구성됩니다.
OpenStackBackupRequest
OpenStackBackup
OpenStackBackupRequest
CRD는 백업의 생성 또는 복원을 시작하는 데 사용되는 반면 OpenStackBackup
CRD는 실제로 운영자에 속하는 CR, ConfigMap 및 비밀 데이터를 저장하는 데 사용됩니다. 이것은 몇 가지 이점을 허용합니다.
OpenStackBackup
CR로 표현하면 사용자는 운영자 구성의 각 부분을 수동으로 내보내거나 가져올 필요가 없습니다.OpenStackBackup
의 생성을 시작하려면 사양을 save
위해 mode
설정된 OpenStackBackupRequest
를 만듭니다. 예를 들어: apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBackupRequest
metadata :
name : openstackbackupsave
namespace : openstack
spec :
mode : save
additionalConfigMaps : []
additionalSecrets : []
사양 필드는 다음과 같습니다.
mode: save
이것이 백업을 작성하라는 요청임을 나타냅니다.additionalConfigMaps
및 additionalSecrets
목록은 보충 구성 및 비밀을 포함하는 데 사용될 수 있습니다. 그렇지 않으면 운영자가 알지 못하는 비밀 (예 : 특정 목적으로 수동으로 생성 된 구성 및 비밀).OpenStackControlPlane
, OpenStackBaremetalSet
등)과 관련된 모든 구성 및 비밀을 포함 시키려고 시도합니다.OpenStackBackupRequest
가 생성되면 상태를 모니터링하십시오. oc get -n openstack osbackuprequest openstackbackupsave
이와 같은 것이 나타나야합니다.
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackupsave save Quiescing
Quiescing
상태는 운영자가 모든 OSP-D 운영자 CR의 프로비저닝 상태를 기다리고 있음을 나타냅니다. 이에 필요한 시간은 OSP-D 운영자 CR의 수량과 현재의 프로비저닝 상태의 발생에 따라 다릅니다. 참고 : 기존 CR의 오류 및/또는 "대기"상태로 인해 운영자가 완전히 정기 할 수 있습니다. 어떤 CRD/CR이 정지를 방지하는지 확인하려면 운영자 로그를 조사하십시오. 예를 들어:
oc logs < OSP-D operator pod > -c manager -f
...
2022-01-11T18:26:15.180Z INFO controllers.OpenStackBackupRequest Quiesce for save for OpenStackBackupRequest openstackbackupsave is waiting for: [OpenStackBaremetalSet: compute, OpenStackControlPlane: overcloud, OpenStackVMSet: controller]
OpenStackBackupRequest
가 Error
상태에 들어가면 전체 내용을보고 발생한 오류를 확인하십시오 ( oc get -n openstack openstackbackuprequest <name> -o yaml
).
OpenStackBackupRequest
가 현재 OSP-D 연산자 구성을 나타내는 OpenStackBackup
을 생성하고 저장함으로써 영광을 누리면 Saved
상태로 들어갑니다. 예를 들어: oc get -n openstack osbackuprequest
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackupsave save Saved 2022-01-11T19:12:58Z
관련 OpenStackBackup
도 생성되었습니다. 예를 들어:
oc get -n openstack osbackup
NAME AGE
openstackbackupsave-1641928378 6m7s
OpenStackBackup
의 복원을 시작하려면 사양에서 restore
mode
설정된 OpenStackBackupRequest
를 만듭니다. 예를 들어: apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBackupRequest
metadata :
name : openstackbackuprestore
namespace : openstack
spec :
mode : restore
restoreSource : openstackbackupsave-1641928378
사양 필드는 다음과 같습니다.
mode: restore
이것이 기존 OpenStackBackup
복원하라는 요청임을 나타냅니다.restoreSource
어떤 OpenStackBackup
복원 해야하는지 나타냅니다. restore
mode
설정되면 OSP-D 연산자는 restoreSource
OpenStackBackup
의 내용을 가져 와서 현재 네임 스페이스 내에 존재하는 기존 CRS, 구성 맵 및 비밀에 적용하려고 시도합니다. 따라서 OpenStackBackup
의 이름과 동일한 이름으로 네임 스페이스의 기존 OSP-D 운영자 리소스를 덮어 쓸 수 있으며 현재 네임 스페이스에서 발견되지 않은 사람들을 위해 새로운 리소스를 생성합니다. 원하는 경우, mode
cleanRestore
로 설정하여 복원을 시도하기 전에 네임 스페이스 내의 기존 OSP-D 운영자 리소스를 완전히 닦아내어 OpenStackBackup
내의 모든 자원이 완전히 새로 생성되도록합니다.
OpenStackBackupRequest
가 생성되면 상태를 모니터링하십시오. oc get -n openstack osbackuprequest openstackbackuprestore
이와 같은 것은 OpenStackBackup
의 모든 리소스가 클러스터에 적용되고 있음을 나타냅니다.
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackuprestore restore openstackbackupsave-1641928378 Loading
그런 다음 모든 리소스가로드되면 운영자는 모든 리소스를 제공하기 위해 조정을 시작합니다.
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackuprestore restore openstackbackupsave-1641928378 Reconciling
OpenStackBackupRequest
가 Error
상태에 들어가면 전체 내용을보고 발생한 오류를 확인하십시오 ( oc get -n openstack openstackbackuprequest <name> -o yaml
).
OpenStackBackupRequest
OpenStackBackup
완전히 복원하여 영광을 누리면 Restored
상태로 들어갑니다. 예를 들어: oc get -n openstack osbackuprequest
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackuprestore restore openstackbackupsave-1641928378 Restored 2022-01-12T13:48:57Z
이 시점에서 선택한 OpenStackBackup
에 포함 된 모든 리소스를 복원하고 완전히 프로비저닝해야합니다.
OSP 디렉터 운영자는 각 OSDEPLOY 리소스가 실행 된 후 구성 맵을 자동으로 만듭니다. 이 configmap은 OSDEPLOY 리소스 이름의 이름을 따서 명명되었으며 Tripleo-Exports-로 접두사를 표시합니다. 예를 들어 Tripleo-Exports-Default는 'Default'OsDeploy Resource의 구성 맵의 이름입니다. 각 구성 맵에는 2 개의 YAML 파일이 포함됩니다.
파일 이름 | 설명 | 트리플로 명령에 해당합니다 |
---|---|---|
ctlplane-export.yaml | DCN 용 여러 스택과 함께 사용됩니다 | 오버 클라우드 수출 |
ctlplane-export filtered.yaml | 셀 "컨트롤러"스택이있는 여러 스택에 사용됩니다 | 오버 클라우드 세포 내보내기 |
아래 명령을 사용하여 configmap에서 Yaml 파일을 추출하십시오. 추출되면 YAML 파일을 OsconFigGenerator 리소스의 사용자 정의 열 매개 변수에 추가 할 수 있습니다.
oc extract cm/tripleo-exports-default
참고 : OSP 이사 운영자는 아직 Ceph Stacks 수출을 생성하지 않습니다.
필요한 경우 OpenStackControlPlane을 통해 구성된 OpenStackVMSet의 CPU/RAM을 변경할 수 있습니다. 워크 플로는 다음과 같습니다.
예를 들어 컨트롤러 virtualmachinerole을 변경하여 8 코어와 22GB의 RAM을 갖도록합니다.
oc patch -n openstack osctlplane overcloud --type= ' json ' -p= ' [{"op": "add", "path": "/spec/virtualMachineRoles/controller/cores", "value": 8 }] '
oc patch -n openstack osctlplane overcloud --type= ' json ' -p= ' [{"op": "add", "path": "/spec/virtualMachineRoles/controller/memory", "value": 22 }] '
oc get osvmset
NAME CORES RAM DESIRED READY STATUS REASON
controller 8 22 1 1 Provisioned All requested VirtualMachines have been provisioned
virtctl start <VM>
사용하여 VM에 전원을 공급하는 것입니다. OSP 업데이트 프로세스 문서를 참조하십시오