Tugas pemeliharaan¶

Bab ini ditujukan untuk tugas pemeliharaan khusus OpenStack-Ansible.

Pemeliharaan klaster Galera¶

Pemeliharaan rutin termasuk menambahkan atau menghapus node dari cluster tanpa mengurangi operasi dan juga memulai cluster setelah secara anggun menutup semua node.

Instance MySQL di-restart ketika membuat cluster, ketika menambahkan node, ketika layanan tidak berjalan, atau ketika perubahan dilakukan ke file konfigurasi /etc/mysql/my.cnf.

Verifikasi status kluster¶

Bandingkan output dari perintah berikut dengan output berikut. Ini seharusnya memberi Anda informasi tentang status kluster Anda.

# ansible galera_container -m shell -a "mysql \
-e 'show status like \"%wsrep_cluster_%\";'"
node3_galera_container-3ea2cbd3 | FAILED | rc=1 >>
ERROR 2002 (HY000): Can't connect to local MySQL server
through socket '/var/run/mysqld/mysqld.sock' (2)

node2_galera_container-49a47d25 | FAILED | rc=1 >>
ERROR 2002 (HY000): Can't connect to local MySQL server
through socket '/var/run/mysqld/mysqld.sock' (2)

node4_galera_container-76275635 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     7
wsrep_cluster_size        1
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

Dalam contoh ini, hanya satu simpul yang merespons.

Dengan halus menutup layanan MariaDB di semua kecuali satu node memungkinkan node operasional yang tersisa untuk melanjutkan pemrosesan permintaan SQL. Ketika secara halus mematikan beberapa node, lakukan tindakan secara berurutan untuk mempertahankan operasi.

Mulai kluster¶

Secara halus mematikan semua node akan menghancurkan cluster. Memulai atau memulai kembali kluster dari nol node membutuhkan pembuatan kluster baru di salah satu node.

Mulai kluster baru di node paling canggih. Ubah ke direktori playbook dan periksa nilai seqno di file grastate.dat pada semua node:

# ansible galera_container -m shell -a "cat /var/lib/mysql/grastate.dat"
node2_galera_container-49a47d25 | success | rc=0 >>
# GALERA saved state version: 2.1
uuid:    338b06b0-2948-11e4-9d06-bef42f6c52f1
seqno:   31
cert_index:

node3_galera_container-3ea2cbd3 | success | rc=0 >>
# GALERA saved state version: 2.1
uuid:    338b06b0-2948-11e4-9d06-bef42f6c52f1
seqno:   31
cert_index:

node4_galera_container-76275635 | success | rc=0 >>
# GALERA saved state version: 2.1
uuid:    338b06b0-2948-11e4-9d06-bef42f6c52f1
seqno:   31
cert_index:

Dalam contoh ini, semua node dalam kluster mengandung nilai positif seqno yang sama karena disinkronkan sesaat sebelum shutdown yang anggun. Jika semua nilai seqno sama, setiap node dapat memulai kluster baru.

## for init
# /etc/init.d/mysql start --wsrep-new-cluster
## for systemd
# systemctl set-environment _WSREP_NEW_CLUSTER='--wsrep-new-cluster'
# systemctl start mysql
# systemctl set-environment _WSREP_NEW_CLUSTER=''

Silakan juga melihatnya upstream starting a cluster page

Ini juga bisa dilakukan dengan bantuan ansible menggunakan modul shell:

# ansible galera_container -m shell -a "/etc/init.d/mysql start --wsrep-new-cluster" --limit galera_container[0]

Perintah ini menghasilkan kluster yang berisi single node. Nilai wsrep_cluster_size menunjukkan jumlah node dalam kluster.

node2_galera_container-49a47d25 | FAILED | rc=1 >>
ERROR 2002 (HY000): Can't connect to local MySQL server
through socket '/var/run/mysqld/mysqld.sock' (111)

node3_galera_container-3ea2cbd3 | FAILED | rc=1 >>
ERROR 2002 (HY000): Can't connect to local MySQL server
through socket '/var/run/mysqld/mysqld.sock' (2)

node4_galera_container-76275635 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     1
wsrep_cluster_size        1
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

Restart MariaDB pada node lain (ganti [0] dari perintah ansible sebelumnya dengan [1:]) dan verifikasi bahwa mereka bergabung kembali dengan cluster.

node2_galera_container-49a47d25 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     3
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

node3_galera_container-3ea2cbd3 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     3
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

node4_galera_container-76275635 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     3
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

Pemulihan klaster Galera¶

Run the openstack.osa.galera_server playbook using the galera_force_bootstrap variable to automatically recover a node or an entire environment.

Jalankan perintah Ansible berikut untuk menunjukkan node yang gagal:

# openstack-ansible openstack.osa.galera_server -e galera_force_bootstrap=True --tags galera_server-config

You can additionally define a different bootstrap node through galera_server_bootstrap_node variable, in case current bootstrap node is in desynced/broken state. You can check what node is currently selected for bootstrap using this ad-hoc:

root@aio1:/opt/openstack-ansible# ansible -m debug -a var="groups['galera_all'][0]" localhost

Cluster kembali online setelah menyelesaikan perintah ini. Jika ini gagal, silakan tinjau restarting the cluster and recovering the primary component dalam dokumentasi galera karena mereka tidak ternilai untuk pemulihan cluster penuh.

Pulihkan kegagalan single-node¶

Jika satu simpul gagal, simpul lainnya mempertahankan kuorum dan terus memproses permintaan SQL.

Ubah ke direktori playbooks dan jalankan perintah Ansible berikut untuk menentukan node gagal:

# ansible galera_container -m shell -a "mysql \
-e 'show status like \"%wsrep_cluster_%\";'"
node3_galera_container-3ea2cbd3 | FAILED | rc=1 >>
ERROR 2002 (HY000): Can't connect to local MySQL server through
socket '/var/run/mysqld/mysqld.sock' (111)

node2_galera_container-49a47d25 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     17
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

node4_galera_container-76275635 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     17
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

Dalam contoh ini, node 3 telah gagal.

Restart MariaDB pada node gagal dan verifikasi bahwa itu bergabung kembali dengan cluster.
Jika MariaDB gagal untuk memulai, jalankan perintah mysqld dan lakukan analisis lebih lanjut pada output. Sebagai usaha terakhir, buat kembali kontainer untuk node.

Memulihkan kegagalan multi-node¶

Ketika semua kecuali satu node gagal, node yang tersisa tidak dapat mencapai quorum dan berhenti memproses permintaan SQL. Dalam situasi ini, node gagal yang pulih tidak dapat bergabung dengan kluster karena tidak ada lagi.

Jalankan perintah Ansible berikut untuk menunjukkan node yang gagal:

# ansible galera_container -m shell -a "mysql \
-e 'show status like \"%wsrep_cluster_%\";'"
node2_galera_container-49a47d25 | FAILED | rc=1 >>
ERROR 2002 (HY000): Can't connect to local MySQL server
through socket '/var/run/mysqld/mysqld.sock' (111)

node3_galera_container-3ea2cbd3 | FAILED | rc=1 >>
ERROR 2002 (HY000): Can't connect to local MySQL server
through socket '/var/run/mysqld/mysqld.sock' (111)

node4_galera_container-76275635 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     18446744073709551615
wsrep_cluster_size        1
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      non-Primary

Dalam contoh ini, node 2 dan 3 gagal. Server operasional yang tersisa menunjukkan non-Primer karena tidak dapat mencapai kuorum.

Jalankan perintah berikut untuk rebootstrap node operasional ke dalam kluster:

# mysql -e "SET GLOBAL wsrep_provider_options='pc.bootstrap=yes';"
node4_galera_container-76275635 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     15
wsrep_cluster_size        1
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

node3_galera_container-3ea2cbd3 | FAILED | rc=1 >>
ERROR 2002 (HY000): Can't connect to local MySQL server
through socket '/var/run/mysqld/mysqld.sock' (111)

node2_galera_container-49a47d25 | FAILED | rc=1 >>
ERROR 2002 (HY000): Can't connect to local MySQL server
through socket '/var/run/mysqld/mysqld.sock' (111)

Node operasi yang tersisa menjadi simpul utama dan mulai memproses permintaan SQL.

Restart MariaDB pada node gagal dan verifikasi bahwa mereka bergabung kembali dengan cluster:

# ansible galera_container -m shell -a "mysql \
-e 'show status like \"%wsrep_cluster_%\";'"
node3_galera_container-3ea2cbd3 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     17
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

node2_galera_container-49a47d25 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     17
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

node4_galera_container-76275635 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     17
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

Jika MariaDB gagal memulai pada salah satu node yang gagal, jalankan perintah mysqld dan lakukan analisis lebih lanjut pada output. Sebagai usaha terakhir, buat kembali kontainer untuk node.

Memulihkan kegagalan environment yang lengkap¶

Kembalikan dari backup jika semua node dalam gugus Galera gagal (jangan mematikan dengan perlahan). Ubah ke direktori playbook dan jalankan perintah berikut untuk menentukan apakah semua node dalam gugus telah gagal:

# ansible galera_container -m shell -a "cat /var/lib/mysql/grastate.dat"
node3_galera_container-3ea2cbd3 | success | rc=0 >>
# GALERA saved state
version: 2.1
uuid:    338b06b0-2948-11e4-9d06-bef42f6c52f1
seqno:   -1
cert_index:

node2_galera_container-49a47d25 | success | rc=0 >>
# GALERA saved state
version: 2.1
uuid:    338b06b0-2948-11e4-9d06-bef42f6c52f1
seqno:   -1
cert_index:

node4_galera_container-76275635 | success | rc=0 >>
# GALERA saved state
version: 2.1
uuid:    338b06b0-2948-11e4-9d06-bef42f6c52f1
seqno:   -1
cert_index:

Semua node telah gagal jika mysqld tidak berjalan di salah satu node dan semua node mengandung nilai seqno dari -1.

Jika ada node tunggal yang memiliki nilai seqno positif, maka node tersebut dapat digunakan untuk me-restart klaster. Namun, karena tidak ada jaminan bahwa setiap node memiliki salinan data yang identik, kami tidak menyarankan untuk me-restart klaster menggunakan perintah --wsrep-new-cluster pada satu node.

Buat kembali sebuah kontainer¶

Memulihkan dari kegagalan tertentu memerlukan pembangunan kembali satu atau lebih kontainer.

Nonaktifkan node gagal pada load balancer.

Catatan

Jangan mengandalkan pemeriksaan kesehatan penyeimbang beban (load balancer) untuk menonaktifkan node. Jika node tidak dinonaktifkan, load balancer mengirim permintaan SQL ke dalamnya sebelum bergabung kembali dengan cluster dan menyebabkan inkonsistensi data.
Hancurkan kontainer dan hapus data MariaDB yang disimpan di luar kontainer:
```
# openstack-ansible openstack.osa.containers_lxc_destroy \
-l node3_galera_container-3ea2cbd3
```
Dalam contoh ini, node 3 gagal.
Jalankan host setup playbook untuk membangun kembali kontainer pada node 3:
```
# openstack-ansible oopenstack.osa.containers_lxc_create -l node3 \
-l node3_galera_container-3ea2cbd3
```
Playbook ini me-restart semua kontainer lain di node.

Jalankan playbook infrastruktur untuk mengonfigurasi kontainer secara spesifik di node 3:

# openstack-ansible openstack.osa.setup_infrastructure \
--limit node3_galera_container-3ea2cbd3

Peringatan

Kontainer baru menjalankan kluster single-node Galera, yang merupakan keadaan berbahaya karena environment berisi lebih dari satu database aktif dengan data yang berpotensi berbeda.

# ansible galera_container -m shell -a "mysql \
-e 'show status like \"%wsrep_cluster_%\";'"
node3_galera_container-3ea2cbd3 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     1
wsrep_cluster_size        1
wsrep_cluster_state_uuid  da078d01-29e5-11e4-a051-03d896dbdb2d
wsrep_cluster_status      Primary

node2_galera_container-49a47d25 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     4
wsrep_cluster_size        2
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

node4_galera_container-76275635 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     4
wsrep_cluster_size        2
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

Mulai ulang MariaDB di kontainer baru dan verifikasi bahwa ini bergabung kembali dengan kluster.

Catatan

Dalam penyebaran yang lebih besar, mungkin diperlukan beberapa waktu untuk daemon MariaDB untuk memulai di kontainer baru. Ini akan menyinkronkan data dari server MariaDB lain selama waktu ini. Anda dapat memantau status selama proses ini dengan mengikuti bagian akhir (tailing) file log /var/log/mysql_logs/galera_server_error.log.

Baris yang dimulai dengan WSREP_SST akan muncul selama proses sinkronisasi dan Anda akan melihat baris dengan WSREP: SST complete, seqno: <NUMBER> jika sinkronisasi berhasil.

# ansible galera_container -m shell -a "mysql \
-e 'show status like \"%wsrep_cluster_%\";'"
node2_galera_container-49a47d25 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     5
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

node3_galera_container-3ea2cbd3 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     5
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

node4_galera_container-76275635 | success | rc=0 >>
Variable_name             Value
wsrep_cluster_conf_id     5
wsrep_cluster_size        3
wsrep_cluster_state_uuid  338b06b0-2948-11e4-9d06-bef42f6c52f1
wsrep_cluster_status      Primary

Aktifkan node yang gagal sebelumnya pada load balancer.

Pemeliharaan klaster RabbitMQ¶

Broker RabbitMQ adalah pengelompokan logis dari satu atau beberapa node Erlang dengan setiap node yang menjalankan aplikasi RabbitMQ dan berbagi pengguna, host virtual, antrian, pertukaran, bindings, dan parameter runtime. Kumpulan node sering disebut sebagai cluster. Untuk informasi lebih lanjut tentang pengelompokan RabbitMQ, lihat RabbitMQ cluster.

Dalam OpenStack-Ansible, semua data dan status yang diperlukan untuk pengoperasian kluster RabbitMQ direplikasi di semua node termasuk antrian pesan yang menyediakan ketersediaan tinggi. Node RabbitMQ membahas satu sama lain menggunakan nama domain. Nama host dari semua anggota cluster harus dapat dipecahkan dari semua node cluster, serta mesin apa pun yang mana alat CLI yang terkait dengan RabbitMQ dapat digunakan. Ada alternatif yang dapat bekerja di lingkungan yang lebih ketat. Untuk detail lebih lanjut tentang pengaturan itu, lihat Inet Configuration.

Catatan

Saat ini ada bug Ansible dalam hal HOSTNAME. Jika host .bashrc menyimpan var bernama HOSTNAME, penampung dimana modul lxc_container 'menempel akan mewarisi var ini dan berpotensi menyetel $HOSTNAME yang salah. Lihat the Ansible fix yang akan dirilis dalam Ansible versi 2.3.

Buat klaster RabbitMQ¶

Kluster RabbitMQ dapat dibentuk dengan dua cara:

Secara manual dengan rabbitmqctl
Deklaratif (daftar node kluster dalam konfigurasi, dengan rabbitmq-autocluster, atau rabbitmq-clusterer plugins)

Catatan

Broker RabbitMQ dapat mentoleransi kegagalan node individu dalam cluster. Node ini dapat mulai dan berhenti sesuka hati selama mereka memiliki kemampuan untuk menjangkau anggota yang diketahui sebelumnya pada saat shutdown.

Ada dua jenis node yang dapat Anda konfigurasi: node disk dan RAM. Paling umum, Anda akan menggunakan node Anda sebagai node disk (lebih disukai). Sedangkan node RAM lebih dari konfigurasi khusus yang digunakan dalam kelompok kinerja.

Node RabbitMQ dan alat CLI menggunakan erlang cookie untuk menentukan apakah mereka memiliki izin untuk berkomunikasi atau tidak. Cookie adalah serangkaian karakter alfanumerik dan bisa sesingkat atau selama yang Anda inginkan.

Catatan

Nilai cookie adalah rahasia bersama dan harus dilindungi dan dijaga kerahasiaannya.

Lokasi default dari cookie pada lingkungan /var/lib/rabbitmq/.erlang.cookie atau di $HOME/.erlang.cookie.

Tip

Sementara pemecahan masalah, jika Anda melihat satu node menolak untuk bergabung dengan cluster, itu pasti bernilai memeriksa apakah cookie erlang sesuai dengan node lainnya. Ketika cookie salah dikonfigurasi (misalnya, tidak identik), RabbitMQ akan mencatat kesalahan seperti "Connection attempt from disallowed node" dan "Could not auto-cluster". Lihat clustering untuk informasi lebih lanjut.

Untuk membentuk Cluster RabbitMQ, Anda mulai dengan mengambil broker RabbitMQ independen dan mengkonfigurasi kembali node-node ini ke dalam konfigurasi cluster.

Menggunakan contoh 3 node, Anda akan memberitahu node 2 dan 3 untuk bergabung dengan cluster dari node pertama.

Bergabunglah dengan kluster, lalu mulai ulang aplikasi:

rabbit2$ rabbitmqctl stop_app
Stopping node rabbit@rabbit2 ...done.
rabbit2$ rabbitmqctl join_cluster rabbit@rabbit1
Clustering node rabbit@rabbit2 with [rabbit@rabbit1] ...done.
rabbit2$ rabbitmqctl start_app
Starting node rabbit@rabbit2 ...done.

Periksa status cluster RabbitMQ¶

Jalankan rabbitmqctl cluster_status dari salah satu node.

Anda akan melihat rabbit1 dan rabbit2 sama-sama berjalan seperti sebelumnya.

Perbedaannya adalah bahwa bagian status klaster dari output, kedua node sekarang dikelompokkan bersama:

rabbit1$ rabbitmqctl cluster_status
Cluster status of node rabbit@rabbit1 ...
[{nodes,[{disc,[rabbit@rabbit1,rabbit@rabbit2]}]},
{running_nodes,[rabbit@rabbit2,rabbit@rabbit1]}]
...done.

Untuk menambahkan node RabbitMQ ketiga ke cluster, ulangi proses di atas dengan menghentikan aplikasi RabbitMQ pada node ketiga.

Bergabunglah dengan cluster, dan restart aplikasi pada node ketiga.

Jalankan rabbitmq cluster_status untuk melihat semua 3 node:

rabbit1$ rabbitmqctl cluster_status
Cluster status of node rabbit@rabbit1 ...
[{nodes,[{disc,[rabbit@rabbit1,rabbit@rabbit2,rabbit@rabbit3]}]},
 {running_nodes,[rabbit@rabbit3,rabbit@rabbit2,rabbit@rabbit1]}]
...done.

Berhenti dan mulai kembali klaster RabbitMQ¶

Untuk menghentikan dan memulai cluster, ingatlah urutan urutan Anda mematikan node. Node terakhir yang Anda hentikan, harus menjadi node pertama yang Anda mulai. Node ini adalah master.

Jika Anda memulai nodes yang tidak berurutan, Anda dapat mengalami masalah saat berpikir master saat ini tidak boleh menjadi master dan menghapus pesan untuk memastikan bahwa tidak ada pesan baru yang diantrikan sementara master asli turun.

RabbitMQ dan mnesia¶

Mnesia adalah database terdistribusi yang digunakan RabbitMQ untuk menyimpan informasi tentang pengguna, pertukaran, antrian, dan binding. Pesan, namun tidak disimpan dalam database.

Untuk informasi lebih lanjut tentang Mnesia, lihat Mnesia overview.

Untuk melihat lokasi file Rabbit yang penting, lihat File Locations.

Perbaiki klaster RabbitMQ yang dipartisi untuk satu node¶

Tanpa kecuali penyebab sesuatu di lingkungan Anda, Anda cenderung kehilangan node di kluster Anda. Dalam skenario ini, beberapa kontainer LXC di host yang sama menjalankan Rabbit dan berada dalam satu cluster Rabbit.

Jika host masih menunjukkan sebagai bagian dari cluster, tetapi tidak berjalan, laksanakan:

# rabbitmqctl start_app

Namun, Anda mungkin melihat beberapa masalah dengan aplikasi Anda karena klien mungkin mencoba untuk mendorong pesan ke node yang tidak responsif. Untuk memperbaiki ini, lupakan node dari cluster dengan mengeksekusi yang berikut:

Pastikan RabbitMQ tidak berjalan di node:
```
# rabbitmqctl stop_app
```

Pada node Rabbit2, jalankan:

# rabbitmqctl forget_cluster_node rabbit@rabbit1

Dengan melakukan ini, cluster dapat terus berjalan dengan efektif dan Anda dapat memperbaiki node yang gagal.

Penting

Perhatikan ketika Anda me-restart node, itu masih akan berpikir itu adalah bagian dari cluster dan akan meminta Anda untuk mereset node. Setelah mereset, Anda harus dapat bergabung kembali ke node lain sesuai kebutuhan.

rabbit1$ rabbitmqctl start_app
Starting node rabbit@rabbit1 ...

Error: inconsistent_cluster: Node rabbit@rabbit1 thinks it's clustered
       with node rabbit@rabbit2, but rabbit@rabbit2 disagrees

rabbit1$ rabbitmqctl reset
Resetting node rabbit@rabbit1 ...done.
rabbit1$ rabbitmqctl start_app
Starting node rabbit@mcnulty ...
...done.

Memperbaiki cluster RabbitMQ yang dipartisi untuk cluster multi-node¶

Konsep yang sama berlaku untuk cluster multi-node yang ada di cluster node tunggal. Satu-satunya perbedaan adalah bahwa berbagai node sebenarnya akan berjalan pada host yang berbeda. Hal utama yang perlu diingat ketika berhadapan dengan multi-node cluster adalah:

Ketika seluruh klaster diturunkan, node terakhir yang harus turun harus menjadi node pertama yang dibawa online. Jika ini tidak terjadi, node akan menunggu 30 detik untuk node disk terakhir untuk kembali online, dan gagal setelahnya.

Jika node terakhir untuk offline tidak dapat dibawa kembali, itu dapat dihapus dari cluster menggunakan perintah forget_cluster_node .
Jika semua node cluster berhenti secara simultan dan tidak terkontrol, (misalnya, dengan pemadaman listrik), Anda dapat ditinggalkan dengan situasi di mana semua node berpikir bahwa beberapa node lain berhenti setelahnya. Dalam hal ini Anda dapat menggunakan perintah force_boot pada satu node untuk membuatnya dapat di-boot kembali.

Lihat halaman manual rabbitmqctl untuk informasi lebih lanjut.

Migrate between HA and Quorum queues¶

In the 2024.1 (Caracal) release OpenStack Ansible switches to use RabbitMQ Quorum Queues by default, rather than the legacy High Availability classic queues. Migration to Quorum Queues can be performed at upgrade time, but may result in extended control plane downtime as this requires all OpenStack services to be restarted with their new configuration.

In order to speed up the migration, the following playbooks can be run to migrate either to or from Quorum Queues, whilst skipping package install and other configuration tasks. These tasks are available from the 2024.1 release onwards.

$ openstack-ansible openstack.osa.rabbitmq_server --tags rabbitmq-config
$ openstack-ansible openstack.osa.setup_openstack --tags common-mq,post-install

In order to take advantage of these steps, we suggest setting oslomsg_rabbit_quorum_queues to False before upgrading to 2024.1. Then, once you have upgraded, set oslomsg_rabbit_quorum_queues back to the default of True and run the playbooks above.

Menjalankan ad-hoc Ansible plays¶

Menjadi terbiasa dengan menjalankan ad-hoc Ansible commands sangat membantu saat mengoperasikan penyebaran OpenStack-Ansible Anda. Untuk ulasan, kita dapat melihat struktur dari perintah berikut yang mungkin:

$ ansible example_group -m shell -a 'hostname'

Perintah ini memanggil Ansible untuk menjalankan example_group menggunakan modul shell `` -m`` dengan argumen `` -a`` yang merupakan perintah nama host. Anda dapat mengganti example_group dengan grup apa pun yang mungkin telah Anda tentukan. Misalnya, jika Anda memiliki `` compute_hosts`` dalam satu grup dan `` infra_hosts`` di yang lain, masukkan salah satu nama grup dan jalankan perintah. Anda juga dapat menggunakan wild card `` * `` jika Anda hanya tahu bagian pertama dari nama grup, misalnya jika Anda tahu nama grup dimulai dengan compute Anda akan menggunakan compute_h * ``. Argumen ``-m adalah untuk modul.

Modul dapat digunakan untuk mengontrol sumber daya sistem atau menangani eksekusi perintah sistem. Untuk informasi lebih lanjut tentang modul, lihat Module Index dan About Modules.

Jika Anda perlu menjalankan perintah tertentu terhadap subset grup, Anda bisa menggunakan flag batas `` -l``. Misalnya, jika grup compute_hosts berisi `` compute1``, `` compute2``, `` compute3``, dan compute4, dan Anda hanya perlu menjalankan perintah pada compute1` ` dan ` `compute4 Anda dapat membatasi perintah sebagai berikut:

$ ansible example_group -m shell -a 'hostname' -l compute1,compute4

Catatan

Setiap host dipisahkan dengan koma tanpa spasi.

Catatan

Jalankan perintah Ad-hoc Ansible dari direktori openstack-ansible/playbooks.

Untuk informasi lebih lanjut, lihat Inventory and Patterns.

Menjalankan modul shell¶

Dua modul yang paling umum digunakan adalah modul shell dan copy. Modul shell akan mengambil nama perintah diikuti dengan daftar space delimited argument. Ini hampir seperti modul perintah, tetapi menjalankan perintah melalui shell (/bin/sh) pada node remote.

Misalnya, Anda bisa menggunakan modul shell untuk memeriksa jumlah ruang disk pada satu set host Compute:

$ ansible compute_hosts -m shell -a 'df -h'

Untuk memeriksa status cluster Galera Anda:

$ ansible galera_container -m shell -a "mysql \
-e 'show status like \"%wsrep_cluster_%\";'"

Ketika sebuah modul digunakan sebagai perintah ad-hoc, ada beberapa parameter yang tidak diperlukan. Sebagai contoh, untuk perintah chdir, tidak perlu chdir=/home/user ls saat menjalankan Ansible dari CLI:

$ ansible compute_hosts -m shell -a 'ls -la /home/user'

Untuk informasi lebih lanjut, lihat shell - Execute commands in nodes.

Menjalankan modul copy¶

Modul salin menyalin file di mesin lokal ke lokasi terpencil. Untuk menyalin file dari lokasi yang jauh ke mesin lokal Anda akan menggunakan modul fetch. Jika Anda membutuhkan interpolasi variabel dalam file yang disalin, gunakan modul template. Untuk informasi lebih lanjut, lihat copy - Copies files to remote locations.

Contoh berikut menunjukkan cara memindahkan file dari host penyebaran Anda ke direktori /tmp pada satu set mesin remote:

$ ansible remote_machines -m copy -a 'src=/root/FILE '\
'dest=/tmp/FILE'

Modul fetch mengumpulkan file dari mesin jarak jauh dan menyimpan file secara lokal di file tree, yang diatur oleh nama host dari mesin jarak jauh dan menyimpannya secara lokal di file tree, yang diatur oleh nama host.

Catatan

Modul ini mentransfer file log yang mungkin tidak ada, jadi file remote yang hilang tidak akan menjadi kesalahan kecuali kalau fail_on_missing diatur ke yes.

Contoh berikut menunjukkan file nova-compute.log ditarik dari satu host Compute:

root@libertylab:/opt/rpc-openstack/openstack-ansible/playbooks# ansible compute_hosts -m fetch -a 'src=/var/log/nova/nova-compute.log dest=/tmp'
aio1 | success >> {
    "changed": true,
    "checksum": "865211db6285dca06829eb2215ee6a897416fe02",
    "dest": "/tmp/aio1/var/log/nova/nova-compute.log",
    "md5sum": "dbd52b5fd65ea23cb255d2617e36729c",
    "remote_checksum": "865211db6285dca06829eb2215ee6a897416fe02",
    "remote_md5sum": null
}

root@libertylab:/opt/rpc-openstack/openstack-ansible/playbooks# ls -la /tmp/aio1/var/log/nova/nova-compute.log
-rw-r--r-- 1 root root 2428624 Dec 15 01:23 /tmp/aio1/var/log/nova/nova-compute.log

Menggunakan tag¶

Tag mirip dengan flag batas untuk grup, kecuali tag digunakan untuk hanya menjalankan tugas tertentu dalam sebuah playbook. Untuk informasi lebih lanjut tentang tag, lihat Tags dan Understanding ansible tags.

Ansible forks¶

Pengaturan MaxSessions default untuk OpenSSH Daemon adalah 10. Setiap fork Ansible memanfaatkan sesi. Secara default, Ansible menetapkan jumlah fork menjadi 5. Namun, Anda dapat meningkatkan jumlah fork yang digunakan untuk meningkatkan kinerja penerapan di lingkungan yang besar.

Perhatikan bahwa lebih dari 10 fork akan menyebabkan masalah untuk setiap playbook yang menggunakan delegate_to atau local_action dalam tugas. Disarankan bahwa jumlah fork tidak dinaikkan saat mengeksekusi terhadap control plane, karena ini adalah tempat delegasi paling sering digunakan.

Jumlah fork yang digunakan dapat diubah secara permanen dengan memasukkan perubahan yang sesuai ke ANSIBLE_FORKS dalam file .bashrc Anda. Alternatifnya dapat diubah untuk eksekusi playbook tertentu dengan menggunakan parameter CLI --forks. Sebagai contoh, berikut ini mengeksekusi nova playbook terhadap control plane dengan 10 fork, kemudian terhadap node komputasi dengan 50 fork.

# openstack-ansible --forks 10 os-nova-install.yml --limit compute_containers
# openstack-ansible --forks 50 os-nova-install.yml --limit compute_hosts

Untuk informasi lebih lanjut tentang fork, silakan lihat referensi berikut:

OpenStack-Ansible Bug 1479812
Ansible forks entry untuk ansible.cfg
Ansible Performance Tuning

Manajemen kontainer¶

Dengan Ansible, proses instalasi OpenStack sepenuhnya otomatis menggunakan playbooks yang ditulis dalam YAML. Setelah instalasi, pengaturan yang dikonfigurasikan oleh playbook dapat diubah dan dimodifikasi. Layanan dan kontainer dapat bergeser untuk mengakomodasi persyaratan lingkungan tertentu. Layanan penskalaan dicapai dengan menyesuaikan layanan di dalam kontainer, atau menambahkan grup penempatan baru. Dimungkinkan juga untuk menghancurkan kontainer, jika perlu, setelah perubahan dan modifikasi selesai.

Skala layanan individual¶

Layanan OpenStack individu, dan layanan proyek open source lainnya, dijalankan dalam kontainer. Dimungkinkan untuk meningkatkan layanan ini dengan memodifikasi file /etc/openstack_deploy/openstack_user_config.yml

Arahkan ke file /etc/openstack_deploy/openstack_user_config.yml.
Akses bagian kelompok penerapan dari file konfigurasi. Di bawah nama grup penerapan, tambahkan garis nilai afinitas (affinity value line) ke skala kontainer layanan OpenStack:
```
infra_hosts:
  infra1:
    ip: 10.10.236.100
    # Rabbitmq
    affinity:
      galera_container: 1
      rabbit_mq_container: 2
```
Dalam contoh ini, galera_container memiliki nilai kontainer satu. Dalam prakteknya, setiap kontainer yang tidak perlu penyesuaian dapat tetap pada nilai default satu, dan tidak boleh disesuaikan di atas atau di bawah nilai satu.

Nilai afinitas untuk setiap kontainer ditetapkan secara default. Sesuaikan nilai afinitas ke nol untuk situasi di mana layanan OpenStack yang disimpan dalam kontainer tertentu tidak akan diperlukan ketika mengukur layanan lain yang diperlukan.
Perbarui nomor kontainer yang tercantum di bawah konfigurasi affinity ke nomor yang diinginkan. Contoh di atas memiliki galera_container yang disetel pada satu dan rabbit_mq_container pada dua, yang mengukur layanan RabbitMQ, tetapi meninggalkan layanan Galera tetap.
Jalankan perintah playbook yang sesuai setelah mengubah konfigurasi untuk membuat kontainer baru, dan instal layanan yang sesuai.

Sebagai contoh, jalankan perintah openstack-ansible lxc-containers-create.yml rabbitmq-install.yml dari repositori openstack-ansible/playbooks untuk menyelesaikan proses penskalaan yang dijelaskan pada contoh di atas:
```
$ cd openstack-ansible/playbooks
$ openstack-ansible lxc-containers-create.yml rabbitmq-install.yml
```

Hancurkan dan buat ulang kontainer¶

Menyelesaikan beberapa masalah mungkin memerlukan penghancuran kontainer, dan membangun kembali kontainer itu dari awal. Anda dapat menghancurkan dan menciptakan kembali kontainer dengan perintah lxc-containers-destroy.yml dan lxc-containers-create.yml. Skrip Ansible ini berada di repositori openstack-ansible/playbooks.

Arahkan ke direktori openstack-ansible.

Jalankan perintah openstack-ansible lxc-containers-destroy.yml, tentukan kontainer target dan kontainer yang akan dihancurkan.

$ openstack-ansible lxc-containers-destroy.yml --limit "CONTAINER_NAME"
$ openstack-ansible lxc-containers-create.yml --limit "CONTAINER_NAME"

Ganti ``CONTAINER_NAME`` dengan kontainer target.

Firewalls¶

OpenStack-Ansible tidak mengkonfigurasi firewall untuk infrastrukturnya. Terserah deployer untuk menentukan perimeter dan konfigurasi firewallnya.

Secara default, OpenStack-Ansible bergantung pada koneksi SSH Ansible, dan membutuhkan port TCP 22 untuk dibuka pada semua host secara internal.

Untuk informasi lebih lanjut tentang konfigurasi firewall OpenStack generik, lihat Firewalls and default ports

Di setiap dokumentasi peran masing-masing, Anda dapat menemukan variabel default untuk port yang digunakan dalam lingkup peran. Meninjau dokumentasi memungkinkan Anda menemukan nama variabel jika Anda ingin menggunakan port yang berbeda.

Catatan

Kelompok vars OpenStack-Ansible dengan mudah mengekspos vars di luar role scope <https://opendev.org/openstack/openstack-ansible/src/inventory/group_vars/all/all.yml> _ jika Anda mengandalkan kelompok OpenStack-Ansible untuk mengkonfigurasi firewall Anda.

Menemukan port untuk penyeimbang beban (load balancer) eksternal Anda¶

Seperti dijelaskan di bagian sebelumnya, Anda dapat menemukan (dalam setiap dokumentasi peran) variabel default yang digunakan untuk port endpoint antarmuka publik.

Misalnya, os_glance documentation mendaftar variabel glance_service_publicuri. Ini berisi port yang digunakan untuk mencapai layanan secara eksternal. Dalam contoh ini, itu sama dengan glance_service_port, yang nilainya 9292.

Sebagai petunjuk, Anda dapat menemukan daftar semua default URI publik dengan menjalankan yang berikut:

cd /etc/ansible/roles
grep -R -e publicuri -e port *

Catatan

Haproxy dapat dikonfigurasi dengan OpenStack-Ansible. File /etc/haproxy/haproxy.cfg yang dihasilkan secara otomatis memiliki informasi yang cukup pada port untuk dibuka bagi lingkungan Anda.

Memangkas Arsip Cadangan Inventaris¶

Arsip cadangan inventaris akan membutuhkan perawatan selama jangka waktu yang cukup lama.

Pemangkasan massal¶

Dimungkinkan untuk melakukan pemangkasan massal backup inventaris. Contoh berikut akan memangkas semua kecuali 15 inventaris terakhir dari arsip yang sedang berjalan.

ARCHIVE="/etc/openstack_deploy/backup_openstack_inventory.tar"
tar -tvf ${ARCHIVE} | \
  head -n -15 | awk '{print $6}' | \
  xargs -n 1 tar -vf ${ARCHIVE} --delete

Pemangkasan Selektif¶

Untuk memangkas arsip inventaris secara selektif, kenali dulu file yang ingin Anda hapus dengan mencantumkannya.

tar -tvf /etc/openstack_deploy/backup_openstack_inventory.tar

-rw-r--r-- root/root    110096 2018-05-03 10:11 openstack_inventory.json-20180503_151147.json
-rw-r--r-- root/root    110090 2018-05-03 10:11 openstack_inventory.json-20180503_151205.json
-rw-r--r-- root/root    110098 2018-05-03 10:12 openstack_inventory.json-20180503_151217.json

Sekarang hapus arsip inventaris yang ditargetkan.

tar -vf /etc/openstack_deploy/backup_openstack_inventory.tar --delete openstack_inventory.json-20180503_151205.json

Tugas pemeliharaan

Tugas pemeliharaan¶

Pemeliharaan klaster Galera¶

Verifikasi status kluster¶

Mulai kluster¶

Pemulihan klaster Galera¶

Pulihkan kegagalan single-node¶

Memulihkan kegagalan multi-node¶

Memulihkan kegagalan environment yang lengkap¶

Buat kembali sebuah kontainer¶

Pemeliharaan klaster RabbitMQ¶

Buat klaster RabbitMQ¶

Periksa status cluster RabbitMQ¶

Berhenti dan mulai kembali klaster RabbitMQ¶

RabbitMQ dan mnesia¶

Perbaiki klaster RabbitMQ yang dipartisi untuk satu node¶

Memperbaiki cluster RabbitMQ yang dipartisi untuk cluster multi-node¶

Migrate between HA and Quorum queues¶

Menjalankan ad-hoc Ansible plays¶

Menjalankan modul shell¶

Menjalankan modul copy¶

Menggunakan tag¶

Ansible forks¶

Manajemen kontainer¶

Skala layanan individual¶

Hancurkan dan buat ulang kontainer¶

Firewalls¶

Menemukan port untuk penyeimbang beban (load balancer) eksternal Anda¶

Memangkas Arsip Cadangan Inventaris¶

Pemangkasan massal¶

Pemangkasan Selektif¶

openstack-ansible 30.0.0.0b2.dev31

Page Contents