يقوم مشغل مدير OSP بإنشاء مجموعة من تعريفات الموارد المخصصة على رأس OpenShift لإدارة الموارد التي تم إنشاؤها عادةً بواسطة Tripleo's undercloud. يتم تقسيم هذه CRD إلى نوعين لتوفير الأجهزة وتكوين البرامج.
يتم تثبيت مشغل مدير OSP وإدارته عبر مدير دورة حياة OLM Operator. يتم تثبيت 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 متاحًا تلقائيًا في مصادر كتالوج OCP الافتراضية OCP الخاصة بك.
قم بإنشاء حجم بيانات RHEL الأساسي قبل نشر OpenStack. سيتم استخدام ذلك بواسطة VMs وحدة التحكم التي يتم توفيرها عبر المحاكاة الافتراضية OpenShift. النهج للقيام بذلك هو على النحو التالي:
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
: 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 معلومات تستخدم لتحديد سياسة تكوين الشبكة المستخدمة لتوصيل أي VM بهذه الشبكة عبر المحاكاة الافتراضية OpenShift. فيما يلي مثال على شبكة IPv4 CTLPlane بسيطة تستخدم Linux Bridge لتكوين المضيف الخاص بها.
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 إلى مواصفات تعريف الشبكة
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
عند استخدام VLAN لعزل الشبكة مع Linux-Bridge
ملاحظة : لاستخدام إطارات Jumbo لجسر ، قم بإنشاء تكوين للجهاز لتكوين 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
قم بإنشاء ConfigMaps التي تحدد أي بيئات حرارة مخصصة وقوالب الحرارة وملف الأدوار المخصصة (يجب أن يكون الاسم roles_data.yaml
) يستخدم لتكوين شبكة Tripleo. يمكن توفير أي ملفات بيئة حرارية محددة في ConfigMap وسيتم استخدامها كاتفاقية في الخطوات اللاحقة المستخدمة لإنشاء مكدس الحرارة لنشر OverCloud. كاتفاقية ، سيستخدم كل تثبيت مدير OSP 2 خرائط تكوين تسمى heat-env-config
و tripleo-tarball-config
لتقديم هذه المعلومات. يحتفظ heat-env-config
بجميع ملفات بيئة النشر حيث يتم إضافة كل ملف -e file.yaml
إلى أمر openstack stack create
. مثال جيد هو:
يمكن استخدام "خريطة تكوين Tarball" لتوفير كرات القطران (الثنائية) التي يتم استخلاصها في المذرات الثلاثية المليئة عند إنشاء كتب اللعب. يجب أن تحتوي كل قطران على دليل للملفات بالنسبة إلى جذر دليل THT. سترغب في تخزين أشياء مثل الأمثلة التالية في خريطة التكوين التي تحتوي على كرات القطران المخصصة:
ملفات Net-Config.
بيئة الشبكة
ملاحظة : يتم إنشاء ملفات Net-Config للأجهزة الظاهرية من قبل المشغل ، ولكن يمكن الكتابة فوقها باستخدام "خريطة تكوين Tarball". للكتابة فوق شبكة صافية تم تقديمها مسبقًا ، استخدم اسم ملف <role lowercase>-nic-template.yaml
لـ OSP16.2 أو <role lowercase>-nic-template.j2
لـ OSP17. ملاحظة : يتم طلب أسماء واجهة الشبكة لـ VMS التي تم إنشاؤها بواسطة وحدة تحكم OpenStackVMSET أبجديًا بواسطة أسماء الشبكة المعينة لدور VM. الاستثناء هو واجهة الشبكة default
لجراب VM الذي سيكون دائمًا الواجهة الأولى. سيبدو قسم 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 إلى شبكة مستأجر VLAN مع ML2/OVN و DVR. يتم تمكين DVR بشكل افتراضي. إذا كنت بحاجة إلى شبكات مستأجر VLAN مع OVN ، فيمكنك تعطيل DVR. لتعطيل DVR ، قم بتضمين الأسطر التالية في ملف البيئة:
parameter_defaults :
NeutronEnableDVR : false
يتم تتبع دعم "حركة مرور VLAN الموزعة في OVN" في إدارة عناوين MAC لـ "إضافة دعم في Tripleo لحركة VLAN الموزعة في OVN" (https://bugs.launchpad.net/tripleo/+bug/1881593)
[GIT REPO CONFIG MAP] يحتوي هذا configmap على مفتاح SSH وعنوان URL لإعادة الريبو GIT المستخدمة لتخزين كتب اللعب التي تم إنشاؤها (أدناه)
بمجرد تخصيص القالب/الأمثلة أعلاه لبيئتك ، يمكنك إنشاء ConfigMaps لكل من "Config Meach-Config" و "Tripleo-Tarball-Config" (Tarballs) باستخدام أوامر المثال على الملفات التي تحتوي (دليل واحد لكل نوع من أنواع configmap):
# 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. سيوفر هذا السر كلمة المرور الافتراضية لجهازك الظاهري ومضيفي الباريما. إذا لم يتم توفير سر ، فستتمكن فقط من تسجيل الدخول باستخدام مفاتيح SSH المحددة في سر OSP-Controlplane-Ssh-Keys.
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 مكانًا رئيسيًا لإنشاء وتوسيع نطاق VMs المستخدمة في وحدات التحكم OSP مع أي VMSTs إضافية لنشرك. مطلوب ما لا يقل عن وحدة تحكم واحدة VM لتثبيت تجريبي أساسي و Per OSP إرشادات التوفر عالية 3 وحدة تحكم VMs.
ملاحظة : إذا تم استخدام صورة Rhel-Guest كأساس لنشر الأجهزة الظاهرية OpenStackControlplane ، فتأكد من إزالة net.Ifnames = 0 kernel من الصورة لتسمية واجهة شبكة 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
لاحظ أن VMs ضمن نفس VSST (دور VM) يتم توزيعها في جميع أنحاء العقد العامل المتاحة باستخدام قاعدة مضادة لخطوطة (PRIEFREDDRINGSCHEDULINGUREDREDDURINGEXECUTION). مع هذا ، لا يزال من الممكن أن ينتهي VMs المتعددة للدور على عقدة العامل نفسها إذا لم تتوفر موارد أخرى (مثل إعادة تشغيل العمال أثناء التحديث). لا يوجد أي ترحيل حي تلقائي ، إذا ظهرت عقدة على سبيل المثال بعد الصيانة/إعادة التشغيل. بناءً على طلب الجدولة التالي ، يتم نقل VM مرة أخرى.
حدد OpenStackBaremetalset لتوسيع نطاق OSP Compute Hosts. يمكن استخدام مورد OpenStackBareMetal لتحديد موارد حساب وتوسيع نطاقها واستخدامها اختياريًا لتحديد المضيفين الباريميين وتوسيع نطاقه لأنواع أخرى من الأدوار الثلاثية. يحدد المثال أدناه مضيف حساب واحد ليتم إنشاؤه.
ملاحظة : إذا تم استخدام صورة Rhel-Guest كأساس لنشر العقد حساب OpenStackBareMetalset ، فتأكد من إزالة net.ifnames = 0 kernel من الصورة لتسمية واجهة شبكة 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
تسجيل العقدة (سجل أنظمة OverCloud على القنوات المطلوبة)
انتظر المورد أعلاه لإنهاء النشر (حساب ومراقبة لوحة التحكم). بمجرد الانتهاء من النشر في النشر مع تسجيل العقدة.
استخدم الإجراء كما هو موضح في 5.9. تشغيل التسجيل القائم على ANSIBLE يدويًا ، قم بذلك.
ملاحظة: نوصي باستخدام التسجيل اليدوي لأنه يعمل بغض النظر عن اختيار الصورة الأساسية. إذا كنت تستخدم Overcloud-Full كصورة نشر الأساس الخاصة بك ، فيمكن استخدام تسجيل RHSM التلقائي عبر دور/ملف البيئة Tht Rhsm.Yaml كبديل لهذا النهج.
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
(اختياري) إنشاء أدوار ملف أ) استخدم جراب OpenStackClient لإنشاء ملف أدوار مخصصة
oc rsh openstackclient
unset OS_CLOUD
cd /home/cloud-admin/
openstack overcloud roles generate Controller ComputeHCI > roles_data.yaml
exit
ب) انسخ ملف الأدوار المخصصة من OpenStackClient Pod
oc cp openstackclient:/home/cloud-admin/roles_data.yaml roles_data.yaml
قم بتحديث tarballConfigMap
لإضافة ملف roles_data.yaml
إلى Tarball وتحديث ConfigMap.
ملاحظة : تأكد من استخدام roles_data.yaml
كاسم الملف.
حدد OpenStackConfiggenerator لإنشاء كتب اللعب ANSIBLE لنشر نظام OSP.
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 أعلاه في ملف يسمى المولد.
oc create -f generator.yaml
سيقوم OsconFiggenerator الذي تم إنشاؤه أعلاه بإنشاء كتب Playbooks تلقائيًا في أي وقت تقوم فيه بتقييم أو تعديل ConfigMaps لنشر OSP الخاص بك. يستغرق توليد كتب اللعب هذه عدة دقائق. يمكنك مراقبة حالة حالة OsconFiggenerator حتى تنتهي.
الحصول على أحدث OsconFigversion (Ansible Playbooks). حدد التجزئة/Digest لأحدث OsconFigversion للاستخدام في الخطوة التالية.
oc get -n openstack --sort-by {.metadata.creationTimestamp} osconfigversions -o json
ملاحظة: تحتوي كائنات OsconFigversion أيضًا على سمة "Git Diff" التي يمكن استخدامها لمقارنة التغييرات بين إصدارات Playbook ANSIBLE بسهولة.
قم بإنشاء OsDeploy (ينفذ كتاب 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. يمكنك ذاكرة سجلات هذه الوظيفة/الجراب لمشاهدة أجهزة Playbooks ANSIBLE. بالإضافة إلى ذلك ، يمكنك الوصول يدويًا إلى كتب اللعب ANSIBLE التي تم تنفيذها عن طريق تسجيل الدخول إلى جراب "OpenStackClient" ، والذهاب إلى/دليل/cloud-admin/work //. هناك ستجد كتب playbooks Ansible مع ملف Ansible.log للنشر قيد التشغيل.
من الممكن نشر البنية التحتية المفرطة في Tripleo حيث تعمل العقد أيضًا كعقد Ceph OSD. سيكون سير العمل لتثبيت Ceph عبر Tripleo:
تأكد من استخدام quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210521.1
أو في وقت لاحق لـ OpenStackClient openStackClientImageURL
.
قم بحساب العقد ذات الأقراص الإضافية لاستخدامها كـ OSDs وإنشاء baremetalset لدور computehci الذي يحتوي على شبكة storagemgmt بالإضافة إلى شبكات الحساب الافتراضية ومعلمة IsHCI
.
ملاحظة : إذا تم استخدام صورة RHEL-GUESTS كأساس لنشر العقد حساب OpenStackBaremetalset ، فتأكد من إزالة net.IfNames = 0 معلمة kernel من الصورة لتسمية واجهة شبكة 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
والذي يتضمن دور computehci/usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml
وأي تخصيص آخر لنشر tripleo configmap المخصصة ، على سبيل المثال 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
بمجرد تخصيص القالب/الأمثلة أعلاه لبيئتك ، قم بإنشاء/تحديث Configmaps كما هو موضح في Deploying OpenStack once you have the OSP Director Operator installed
Deploying OpenStack once you have the OSP Director Operator installed
وتحديد ملف الأدوار الذي تم إنشاؤه. ملاحظة : تأكد من استخدام quay.io/openstack-k8s-operators/rhosp16-openstack-tripleoclient:16.2_20210521.1
أو في وقت لاحق لـ OsconFiggenerator imageURL
.
انتظر حتى ينهي OpenStackConfiggenerator وظيفة تقديم Playbook.
الحصول على التجزئة/Digest من أحدث OpenStackConfigversion.
إنشاء OpenStackDeploy ل OpenStackConfigversion المحدد. سيؤدي ذلك إلى نشر كتب اللعب Ansible.
يتطلب إزالة مضيف حساب الباريميات الخطوات التالية:
في حالة إزالة عقدة حساب ، قم بتعطيل خدمة الحساب على العقدة الصادرة على OverCloud لمنع العقدة من جدولة مثيلات جديدة
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
تنعكس حالة التعليقات التوضيحية في Osbaremetalset/OSVMSET باستخدام معلمة annotatedForDeletion
:
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
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
تقليل مورد RoleCount من VirtualMachineroles في OpenStackControlplane CR. وحدة تحكم corrensponding للتعامل مع حذف الموارد
oc patch osctlplane overcloud --type=merge --patch ' {"spec":{"virtualMachineRoles":{"<RoleName>":{"roleCount":2}}}} '
نتيجة ل:
هذا ينتج عنه السلوك التالي
إذا استضاف VM أي خدمة OSP التي يجب إزالتها ، فقم بحذف الخدمة باستخدام أمر OpenStack المقابل.
من الممكن نشر بنية شبكات Tripleo الموجه (شبكات العمود الفقري/الأوراق) لتكوين شبكات أوراق Overcloud. استخدم معلمة الشبكات الفرعية لتحديد الشبكات الفرعية الأوراق الإضافية مع شبكة أساسية.
القيد في الوقت الحالي هو أنه لا يمكن أن يكون هناك سوى شبكة توفير واحدة لـ Metal3.
سيكون سير العمل لتثبيت vercloud باستخدام شبكات فرعية متعددة:
حدد OpenStackNetConfig مورد مخصص وحدد جميع الشبكات الفرعية لشبكات OverCloud. سيقوم المشغل بتقديم Tripleo Network_Data.yaml لإصدار OSP المستخدم.
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
لإضافة ملف roles_data.yaml
إلى Tarball وتحديث ConfigMap.
ملاحظة : تأكد من استخدام roles_data.yaml
كاسم الملف.
قوالب OSP 16.2 Tripleo NIC لها معلمة interfaceroutes لكل افتراضي. عادةً ما يتم تعيين معلمة الطرق المقدمة في البيئات/الشبكة-البيئة. نظرًا لعدم وجود نيوترون ، يلزم إضافة طرق {{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
يتم تقديم معلومات الشبكة الفرعية للمسارات تلقائيًا إلى environments/network-environment.yaml
التي تستخدم في البرنامج النصي مما يجعل كتب Playbooks ANSIBLE. في قوالب NIC ، استخدم Routes_ <ubnet_name> ، مثل Storageroutes_Storage_Leaf1 لتعيين التوجيه الصحيح على المضيف.
بالنسبة إلى دور حساب Computeleaf1 ، يجب تعديل قالب 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
...
قم بتحديث ملف ConfigMap tarballConfigMap
لإضافة ملف NIC Templates roles_data.yaml
إلى Tarball وتحديث ConfigMap.
ملاحظة : تأكد من استخدام 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
في هذه المرحلة يمكننا توفير OverCloud.
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 لإنشاء كتب اللعب ANSible لنشر نظام OSP كما في Deploying OpenStack once you have the OSP Director Operator installed
وتحديد ملف الأدوار الذي تم إنشاؤه.
كما هو موضح من قبل في Run the software deployment
، قم بتقديم ، قم بتسجيل العقد OverCloud على المستودعات المطلوبة وتشغيل نشر Sofware من داخل OpenStackClient Pod.
يوفر OSP-D Operator API لإنشاء واستعادة النسخ الاحتياطية لتكوينات CR الحالية والتكوينات السرية. يتكون واجهة برمجة التطبيقات هذه من اثنين من CRDS:
OpenStackBackupRequest
OpenStackBackup
يتم استخدام OpenStackBackupRequest
CRD لبدء إنشاء أو استعادة النسخ الاحتياطي ، في حين يتم استخدام OpenStackBackup
CRD لتخزين CR و ConfigMap و Secret Data التي تنتمي إلى المشغل بالفعل. هذا يسمح لعدة فوائد:
OpenStackBackup
CR ، لا يتعين على المستخدم تصدير/استيراد كل قطعة من تكوين المشغل يدويًاOpenStackBackup
جديد ، قم بإنشاء OpenStackBackupRequest
مع تعيين mode
save
في مواصفاته. على سبيل المثال: apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBackupRequest
metadata :
name : openstackbackupsave
namespace : openstack
spec :
mode : save
additionalConfigMaps : []
additionalSecrets : []
حقول المواصفات هي كما يلي:
mode: save
إلى أن هذا طلب لإنشاء نسخة احتياطية.additionalConfigMaps
و additionalSecrets
لتضمين خرائط التكوين الإضافية والأسرار التي لا يدركها المشغل (أي configmaps والأسرار التي تم إنشاؤها يدويًا لأغراض معينة).OpenStackControlPlane
، OpenStackBaremetalSet
، إلخ) في مساحة الاسم ، دون مطالبة المستخدم بتضمينها في هذه القوائم الإضافية.OpenStackBackupRequest
، راقب حالتها: oc get -n openstack osbackuprequest openstackbackupsave
يجب أن يظهر شيء من هذا القبيل:
NAME OPERATION SOURCE STATUS COMPLETION TIMESTAMP
openstackbackupsave save Quiescing
تشير حالة Quiescing
إلى أن المشغل ينتظر توفير جميع مشغل OSP-D CRS للوصول إلى ما يعادل "الانتهاء". سيختلف الوقت اللازم لهذا بناءً على كمية مشغل OSP-D CRS وحدث حالة التوفير الحالية. ملاحظة: من الممكن أن يقوم المشغل أبدًا بالهدوء بالكامل بسبب الأخطاء و/أو "الانتظار" في CRS الحالية. لمعرفة أي CRDS/CRS يمنع الهدوء ، التحقيق في سجلات المشغل. على سبيل المثال:
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
من خلال إنشاء وحفظ OpenStackBackup
الذي يمثل تكوين مشغل OSP-D الحالي ، فإنه سيدخل الحالة 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
، قم بإنشاء OpenStackBackupRequest
مع تعيين mode
restore
في مواصفاته. على سبيل المثال: apiVersion : osp-director.openstack.org/v1beta1
kind : OpenStackBackupRequest
metadata :
name : openstackbackuprestore
namespace : openstack
spec :
mode : restore
restoreSource : openstackbackupsave-1641928378
حقول المواصفات هي كما يلي:
mode: restore
إلى أن هذا طلب لاستعادة OpenStackBackup
موجود.restoreSource
إلى OpenStackBackup
الذي يجب استعادته. مع تعيين mode
restore
، سيأخذ مشغل OSP-D محتويات restoreSource
OpenStackBackup
ومحاولة تطبيقها على CRS و configmaps والأسرار الموجودة حاليًا داخل مساحة الاسم. وبالتالي ، فإنه سيقوم بالكتابة فوق أي موارد مشغل OSP-D موجودة في مساحة الاسم مع نفس الأسماء الموجودة في OpenStackBackup
، وستنشئ موارد جديدة لأولئك الذين لم يتم العثور عليهم حاليًا في مساحة الاسم. إذا رغبت في ذلك ، يمكن ضبط 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
المختار وتزويدها بالكامل.
يقوم مشغل Director OSP تلقائيًا بإنشاء configmap بعد انتهاء كل مورد OSDeploy. تم تسمية هذا configmap على اسم مورد OsDeploy ومسبق مع Tripleo-Exports-. على سبيل المثال ، سيكون Tripleo-Exports-Default اسم ConfigMap لمورد OSDeploy "الافتراضي". يحتوي كل configmap على ملفين yaml:
اسم الملف | وصف | Tripleo أمر ما يعادل |
---|---|---|
ctlplane-export.yaml | تستخدم مع مداخن متعددة لـ DCN | Overcloud التصدير |
Ctlplane-pirted | تستخدم لمكارات متعددة مع مكدسات "وحدة تحكم" الخلية | Overcloud Cell Export |
استخدم الأمر أدناه لاستخراج ملفات yaml من configmap. بمجرد استخراج ملفات YAML يمكن إضافة إلى معلمات حرارة مخصصة على موارد OsconFiggenerator.
oc extract cm/tripleo-exports-default
ملاحظة: لم يولد مشغل مدير OSP صادرات لـ Ceph Stacks.
إذا لزم الأمر ، فمن الممكن تغيير وحدة المعالجة المركزية/ذاكرة الوصول العشوائي لـ OpenStackVMSET التي تم تكوينها عبر OpenStackControlplane. سير العمل كما يلي:
على سبيل المثال ، لتغيير وحدة التحكم VirtualMachinerole لتكون 8 نوى و 22 جيجابايت من ذاكرة الوصول العشوائي:
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