[ English | русский | Deutsch | español | Indonesia | English (United Kingdom) ]
Scaling lingkungan Anda¶
Ini adalah halaman skala lingkungan draf untuk panduan operasi OpenStack-Ansible yang diusulkan.
Tambahkan host infrastruktur baru¶
Sementara tiga host infrastruktur direkomendasikan, jika host lebih lanjut diperlukan dalam suatu lingkungan, adalah mungkin untuk membuat node tambahan.
Peringatan
Pastikan Anda mencadangkan lingkungan OpenStack Anda saat ini sebelum menambahkan node baru apa pun. Lihat Cadangkan dan pulihkan cloud Anda untuk informasi lebih lanjut.
Tambahkan node ke stanza
infra_hosts
dari/etc/openstack_deploy/openstack_user_config.yml
infra_hosts: [...] infra<node-ID>: ip: 10.17.136.32
Ubah ke folder playbook di host penyebaran (deployment).
# cd /opt/openstack-ansible
To prepare new hosts and deploy containers on them run
setup-hosts.yml
playbook with thelimit
argument.# openstack-ansible openstack.osa.setup_hosts --limit localhost,infra<node-ID>,infra<node-ID>-host_containers
In case you're relying on
/etc/hosts
content, you should also update it for all hosts# openstack-ansible openstack.osa.openstack_hosts_setup -e openstack_hosts_group=all --tags openstack_hosts-file
Next we need to expand galera/rabbitmq clusters, which is done during
setup-infrastructure.yml
. So we will run this playbook without limits.Peringatan
Make sure that containers from new infra host does not appear in inventory as first one for groups
galera_all
,rabbitmq_all
andrepo_all
. You can varify that with ad-hoc commands:# ansible -m debug -a "var=groups['galera_all'][0]" localhost # ansible -m debug -a "var=groups['rabbitmq_all'][0]" localhost # ansible -m debug -a "var=groups['repo_all'][0]" localhost
# openstack-ansible openstack.osa.setup_infrastructure -e galera_force_bootstrap=true
Once infrastructure playboks are done, it's turn of openstack services to be deployed. Most of the services are fine to be ran with limits, but some, like keystone, are not. So we run keystone playbook separately from all others:
# openstack-ansible openstack.osa.keystone # openstack-ansible openstack.osa.setup_openstack --limit '!keystone_all',localhost,infra<node-ID>,infra<node-ID>-host_containers
Uji infra node baru¶
Setelah membuat infra node baru, uji bahwa node berjalan dengan benar dengan meluncurkan instance baru. Pastikan bahwa node baru dapat menanggapi tes koneksi jaringan melalui perintah ping. Masuk ke sistem pemantauan Anda, dan verifikasi bahwa monitor mengembalikan sinyal hijau untuk node baru.
Tambahkan host komputasi¶
Gunakan prosedur berikut untuk menambahkan host komputasi ke cluster operasional.
Konfigurasikan host sebagai host target. Lihat target hosts configuration section dari panduan penyebaran. untuk informasi lebih lanjut.
Edit file
/etc/openstack_deploy/openstack_user_config.yml
dan tambahkan host ke bait (stanza)compute_hosts
.Jika perlu, ubah juga bait (stanza)
used_ips
.Jika cluster menggunakan Telemetry/Metering (ceilometer), edit file
/etc/openstack_deploy/conf.d/ceilometer.yml
dan tambahkan host ke stanzametering-compute_hosts
.Jalankan perintah berikut untuk menambahkan host. Ganti
NEW_HOST_NAME
dengan nama host baru.# cd /opt/openstack-ansible/playbooks # openstack-ansible openstack.osa.setup_hosts --limit localhost,NEW_HOST_NAME # openstack-ansible openstack.osa.openstack_hosts_setup -e openstack_hosts_group=nova_compute --tags openstack_hosts-file # openstack-ansible openstack.osa.setup_openstack --limit localhost,NEW_HOST_NAME
Atau Anda dapat mencoba menggunakan skrip penyebaran node komputasi baru
/opt/openstack-ansible/scripts/add-compute.sh
.Anda dapat memberikan skrip ini tugas tambahan yang akan dieksekusi sebelum atau tepat setelah peran OSA. Untuk melakukannya, Anda harus mengatur variabel lingkungan
PRE_OSA_TASKS
atauPOST_OSA_TASKS
dengan memainkan untuk menjalankan dibagi dengan titik koma (semicolon):# export POST_OSA_TASKS="/opt/custom/setup.yml --limit HOST_NAME;/opt/custom/tasks.yml --tags deploy" # /opt/openstack-ansible/scripts/add-compute.sh HOST_NAME,HOST_NAME_2
Uji node komputasi baru¶
Setelah membuat node baru, uji bahwa node berjalan dengan benar dengan meluncurkan sebuah instance pada node baru.
$ openstack server create --image IMAGE --flavor m1.tiny \
--key-name KEY --availability-zone ZONE:HOST:NODE \
--nic net-id=UUID SERVER
Pastikan instance baru dapat menanggapi tes koneksi jaringan melalui perintah ping. Masuk ke sistem pemantauan Anda, dan verifikasi bahwa monitor mengembalikan sinyal hijau untuk simpul node.
Hapus host komputasi¶
The openstack-ansible-ops repositori berisi buku pedoman untuk menghapus host komputasi dari lingkungan OpenStack-Ansible. Untuk menghapus host komputasi, ikuti prosedur di bawah ini.
Catatan
Panduan ini menjelaskan cara menghapus node komputasi dari lingkungan yang dimungkinkan oleh OpenStack. Lakukan langkah-langkah ini dengan hati-hati, karena node komputasi tidak akan lagi berfungsi setelah langkah-langkah tersebut selesai. Panduan ini mengasumsikan bahwa semua data dan instance telah dimigrasi dengan benar.
Nonaktifkan semua layanan OpenStack yang berjalan pada node komputasi. Ini dapat termasuk, tetapi tidak terbatas pada, layanan
nova-compute
dan layanan agen neutron.Catatan
Pastikan langkah ini dilakukan terlebih dahulu
# Run these commands on the compute node to be removed # stop nova-compute # stop neutron-linuxbridge-agent
Klon repositori
openstack-ansible-ops
ke host penyebaran Anda:$ git clone https://opendev.org/openstack/openstack-ansible-ops \ /opt/openstack-ansible-ops
Jalankan playbook
remove_compute_node.yml
yang dimungkinkan dengan set variabel penggunahost_to_be_removed
:$ cd /opt/openstack-ansible-ops/ansible_tools/playbooks openstack-ansible remove_compute_node.yml \ -e host_to_be_removed="<name-of-compute-host>"
Setelah playbook selesai, hapus node komputasi dari file konfigurasi OpenStack-Ansible di
/etc/openstack_deploy/openstack_user_config.yml
.
Memulihkan kegagalan host komputasi¶
Prosedur berikut membahas kegagalan simpul Node jika penyimpanan bersama digunakan.
Catatan
Jika penyimpanan bersama tidak digunakan, data dapat disalin dari direktori /var/lib/nova/instances
pada Compute node yang gagal ${FAILED_NODE}
ke simpul lain ${RECEIVING_NODE}
sebelum melakukan prosedur berikut. Harap dicatat metode ini tidak didukung.
Luncurkan ulang semua instance pada node yang gagal.
Aktifkan alat baris perintah (command line tool) MySQL
Buat daftar instance UUID yang dihosting pada node yang gagal:
mysql> select uuid from instances where host = '${FAILED_NODE}' and deleted = 0;
Setel instance pada node yang gagal untuk di-host pada node yang berbeda:
mysql> update instances set host ='${RECEIVING_NODE}' where host = '${FAILED_NODE}' \ and deleted = 0;
Reboot setiap instance pada node gagal yang tercantum dalam kueri sebelumnya untuk membuat ulang file XML:
# nova reboot —hard $INSTANCE_UUID
Temukan volume untuk memeriksa instance telah berhasil di-boot dan sedang masuk:
mysql> select nova.instances.uuid as instance_uuid, cinder.volumes.id \ as voume_uuid, cinder.volumes.status, cinder.volumes.attach_status, \ cinder.volumes.mountpoint, cinder.volumes,display_name from \ cinder.volumes inner join nova.instances on cinder.volumes.instance_uuid=nova.instances.uuid \ where nova.instances.host = '${FAILED_NODE}';
Jika baris ditemukan, lepaskan dan pasang kembali volume menggunakan nilai yang tercantum dalam permintaan sebelumnya:
# nova volume-detach $INSTANCE_UUID $VOLUME_UUID && \ # nova volume-attach $INSTANCE_UUID $VOLUME_UUID $VOLUME_MOUNTPOINT
Bangun kembali atau ganti node yang gagal seperti yang dijelaskan dalam add-compute-host.
Mengganti perangkat keras yang gagal¶
Sangat penting untuk merencanakan dan mengetahui cara mengganti perangkat keras yang gagal di cluster Anda tanpa membahayakan lingkungan cloud Anda.
Pertimbangkan yang berikut ini untuk membantu menyusun rencana penggantian perangkat keras:
Apa jenis node yang saya ganti perangkat keras?
Bisakah penggantian perangkat keras dilakukan tanpa host turun (down) ? Misalnya, satu disk dalam RAID-10.
Jika host TIDAK harus dibawa down untuk penggantian perangkat keras, bagaimana sumber daya pada host itu harus ditangani?
Jika Anda memiliki host Compute (nova) yang memiliki kegagalan disk pada RAID-10, Anda dapat menukar disk yang gagal tanpa mematikan host. Di sisi lain, jika RAM gagal, Anda harus mematikan host. Memiliki rencana tentang bagaimana Anda akan mengelola jenis peristiwa ini adalah bagian penting dari menjaga lingkungan OpenStack Anda.
Untuk host Compute, matikan instance pada host sebelum down. Untuk host Block Storage (cinder) yang menggunakan penyimpanan non-redundan, matikan instance dengan volume yang terpasang yang mengharuskan titik pemasangan itu. Lepas drive dalam sistem operasi Anda dan pasang kembali drive setelah host Block Storage kembali online.
Mematikan host Compute¶
Jika host Compute perlu dimatikan:
Nonaktifkan biner
nova-compute
:# nova service-disable --reason "Hardware replacement" HOSTNAME nova-compute
Daftar semua instance yang berjalan pada host Compute:
# nova list --all-t --host <compute_name> | awk '/ACTIVE/ {print $2}' > \ /home/user/running_instances && for i in `cat /home/user/running_instances`; do nova stop $i ; done
Gunakan SSH untuk terhubung ke host Compute.
Konfirmasikan semua instance tidak aktif:
# virsh list --all
Matikan host Compute:
# shutdown -h now
Setelah Compute hos kembali online, konfirmasi semuanya sudah berfungsi dan mulai instance pada host. Sebagai contoh:
# cat /home/user/running_instances # do nova start $instance done
Aktifkan layanan
nova-compute
di lingkungan:# nova service-enable HOSTNAME nova-compute
Mematikan host Block Storage¶
Jika host Block Storage yang didukung LVM perlu dimatikan:
Nonaktifkan layanan
cinder-volume
:# cinder service-list --host CINDER SERVICE NAME INCLUDING @BACKEND # cinder service-disable CINDER SERVICE NAME INCLUDING @BACKEND \ cinder-volume --reason 'RAM maintenance'
Daftar semua instance dengan volume Block Storage yang terlampir:
# mysql cinder -BNe 'select instance_uuid from volumes where deleted=0 '\ 'and host like "%<cinder host>%"' | tee /home/user/running_instances
Matikan instance:
# cat /home/user/running_instances | xargs -n1 nova stop
Pastikan instance dimatikan:
# cat /home/user/running_instances | xargs -n1 nova show | fgrep vm_state
Matikan host Block Storage:
# shutdown -h now
Ganti perangkat keras yang gagal dan validasikan perangkat keras yang berfungsi.
Aktifkan layanan
cinder-volume
:# cinder service-enable CINDER SERVICE NAME INCLUDING @BACKEND cinder-volume
Verifikasi bahwa layanan di host terhubung kembali ke lingkungan:
# cinder service-list --host CINDER SERVICE NAME INCLUDING @BACKEND
Mulai instance Anda dan konfirmasikan semua instance sudah dimulai:
# cat /home/user/running_instances | xargs -n1 nova start # cat /home/user/running_instances | xargs -n1 nova show | fgrep vm_state
Menghancurkan Kontainer¶
Untuk menghancurkan kontainer, jalankan yang berikut:
# openstack-ansible openstack.osa.containers_lxc_destroy --limit localhost,<container name|container group>Catatan
Anda akan ditanya dua pertanyaan:
Anda yakin ingin menghancurkan kontainer LXC? Anda yakin ingin menghancurkan data kontainer LXC?
Yang pertama hanya akan menghapus kontainer tetapi meninggalkan data di bind mounts dan log. Yang kedua akan menghapus data di bind mounts dan juga log.
Peringatan
Jika Anda menghapus kontainer dan data untuk seluruh grup kontainer galera_server Anda akan kehilangan semua basis data Anda! Juga, jika Anda menghancurkan kontainer pertama di banyak grup host, Anda akan kehilangan item penting lainnya seperti sertifikat, kunci, dll. Pastikan Anda memahami apa yang Anda lakukan saat menggunakan alat ini.
Untuk membuat kontainer lagi, jalankan yang berikut:
# cd /opt/openstack-ansible/playbooks # openstack-ansible openstack.osa.containers_lxc_create --limit localhost,lxc_hosts,<container name|container group>
Grup host lxc_hosts harus dimasukkan karena playbook dan peran yang dijalankan memerlukan penggunaan fakta dari host.
[ English | русский | Deutsch | español | Indonesia | English (United Kingdom) ]
Aksesibilitas untuk r multi-region Object Storage¶
Dalam multi-region Object Storage menggunakan backend database terpisah, objek dapat diambil dari lokasi alternatif jika default_project_id
untuk pengguna dalam database keystone adalah sama di setiap backend database.
Penting
Dianjurkan untuk melakukan langkah-langkah berikut sebelum terjadi kegagalan untuk menghindari harus membuang dan mengembalikan database.
Jika terjadi kegagalan, ikuti langkah-langkah ini untuk memulihkan database dari Primary (failed) Region:
Rekam output Primary Region dari
default_project_id
untuk pengguna yang ditentukan dari tabel pengguna di database keystone:Catatan
Pengguna adalah
admin
dalam contoh ini.# mysql -e "SELECT default_project_id from keystone.user WHERE \ name='admin';" +----------------------------------+ | default_project_id | +----------------------------------+ | 76ef6df109744a03b64ffaad2a7cf504 | +-----------------—————————————————+
Rekam output Secondary Region dari
default_project_id
untuk pengguna yang ditentukan dari tabel pengguna di database keystone:# mysql -e "SELECT default_project_id from keystone.user WHERE \ name='admin';" +----------------------------------+ | default_project_id | +----------------------------------+ | 69c46f8ad1cf4a058aa76640985c | +----------------------------------+
Di Secondary Region, perbarui referensi ke
project_id
untuk mencocokkan ID dari Primary Region:# export PRIMARY_REGION_TENANT_ID="76ef6df109744a03b64ffaad2a7cf504" # export SECONDARY_REGION_TENANT_ID="69c46f8ad1cf4a058aa76640985c" # mysql -e "UPDATE keystone.assignment set \ target_id='${PRIMARY_REGION_TENANT_ID}' \ WHERE target_id='${SECONDARY_REGION_TENANT_ID}';" # mysql -e "UPDATE keystone.user set \ default_project_id='${PRIMARY_REGION_TENANT_ID}' WHERE \ default_project_id='${SECONDARY_REGION_TENANT_ID}';" # mysql -e "UPDATE keystone.project set \ id='${PRIMARY_REGION_TENANT_ID}' WHERE \ id='${SECONDARY_REGION_TENANT_ID}';"
Pengguna di Secondary Region sekarang memiliki akses ke objek PUT di Primary Region. Secondary Region dapat PUT objek yang dapat diakses oleh pengguna di Primary Region.