[ 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.

  1. Tambahkan node ke stanza infra_hosts dari /etc/openstack_deploy/openstack_user_config.yml

    infra_hosts:
[...]
  infra<node-ID>:
    ip: 10.17.136.32

  2. Ubah ke folder playbook di host penyebaran (deployment).

    # cd /opt/openstack-ansible

  3. To prepare new hosts and deploy containers on them run setup-hosts.yml playbook with the limit argument.

    # openstack-ansible openstack.osa.setup_hosts --limit localhost,infra<node-ID>,infra<node-ID>-host_containers

  4. 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

  5. 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 and repo_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

  6. 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.

  1. Konfigurasikan host sebagai host target. Lihat target hosts configuration section dari panduan penyebaran. untuk informasi lebih lanjut.

  2. 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.

  3. Jika cluster menggunakan Telemetry/Metering (ceilometer), edit file /etc/openstack_deploy/conf.d/ceilometer.yml dan tambahkan host ke stanza metering-compute_hosts.

  4. 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 atau POST_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.

  1. 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

  2. Klon repositori openstack-ansible-ops ke host penyebaran Anda:

    $ git clone https://opendev.org/openstack/openstack-ansible-ops \
  /opt/openstack-ansible-ops

  3. Jalankan playbook remove_compute_node.yml yang dimungkinkan dengan set variabel pengguna host_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>"

  4. 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.

  1. Luncurkan ulang semua instance pada node yang gagal.

  2. Aktifkan alat baris perintah (command line tool) MySQL

  3. Buat daftar instance UUID yang dihosting pada node yang gagal:

    mysql> select uuid from instances where host = '${FAILED_NODE}' and deleted = 0;

  4. 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;

  5. Reboot setiap instance pada node gagal yang tercantum dalam kueri sebelumnya untuk membuat ulang file XML:

    # nova reboot —hard $INSTANCE_UUID

  6. 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}';

  7. 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

  8. 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:

  1. Nonaktifkan biner nova-compute:

    # nova service-disable --reason "Hardware replacement" HOSTNAME nova-compute

  2. 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

  3. Gunakan SSH untuk terhubung ke host Compute.

  4. Konfirmasikan semua instance tidak aktif:

    # virsh list --all

  5. Matikan host Compute:

    # shutdown -h now

  6. 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

  7. 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:

  1. 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'

  2. 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

  3. Matikan instance:

    # cat /home/user/running_instances | xargs -n1 nova stop

  4. Pastikan instance dimatikan:

    # cat /home/user/running_instances | xargs -n1 nova show | fgrep vm_state

  5. Matikan host Block Storage:

    # shutdown -h now

  6. Ganti perangkat keras yang gagal dan validasikan perangkat keras yang berfungsi.

  7. Aktifkan layanan cinder-volume:

    # cinder service-enable CINDER SERVICE NAME INCLUDING @BACKEND cinder-volume

  8. Verifikasi bahwa layanan di host terhubung kembali ke lingkungan:

    # cinder service-list --host CINDER SERVICE NAME INCLUDING @BACKEND

  9. 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

  1. 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.

  1. 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:

  1. 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 |
+-----------------—————————————————+

  2. 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     |
+----------------------------------+

  3. 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.