Tugas pemeliharaan

[ English | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia ]

Tugas pemeliharaan

Bab ini ditujukan untuk tugas pemeliharaan khusus OpenStack-Ansible.

[ English | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia ]

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 -h 127.0.0.1 \
-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.

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

Jalankan galera-install playbook menggunakan tag galera-bootstrap untuk memulihkan node atau seluruh lingkungan secara otomatis.

  1. Jalankan perintah Ansible berikut untuk menunjukkan node yang gagal:

    # openstack-ansible galera-install.yml --tags galera-bootstrap
    

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.

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

    # ansible galera_container -m shell -a "mysql -h 127.0.0.1 \
    -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.

  2. Restart MariaDB pada node gagal dan verifikasi bahwa itu bergabung kembali dengan cluster.

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

  1. Jalankan perintah Ansible berikut untuk menunjukkan node yang gagal:

    # ansible galera_container -m shell -a "mysql \
    -h 127.0.0.1 -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.

  2. Jalankan perintah berikut ke rebootstrap node operasional ke dalam klaster:

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

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

    # ansible galera_container -m shell -a "mysql \
    -h 127.0.0.1 -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
    
  4. 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.

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

  2. Hancurkan kontainer dan hapus data MariaDB yang disimpan di luar kontainer:

    # lxc-stop -n node3_galera_container-3ea2cbd3
    # lxc-destroy -n node3_galera_container-3ea2cbd3
    # rm -rf /openstack/node3_galera_container-3ea2cbd3/*
    

    Dalam contoh ini, node 3 gagal.

  3. Jalankan host setup playbook untuk membangun kembali kontainer pada node 3:

    # openstack-ansible setup-hosts.yml -l node3 \
    -l node3_galera_container-3ea2cbd3
    

    Playbook ini me-restart semua kontainer lain di node.

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

    # openstack-ansible setup-infrastructure.yml \
    --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 \
    -h 127.0.0.1 -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
    
  5. 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 \
    -h 127.0.0.1 -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
    
  6. Aktifkan node yang gagal sebelumnya pada load balancer.

[ English | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia ]

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.

  1. Login ke node ke-2 dan ke-3 dan hentikan aplikasi rabbitmq.

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

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

  1. Bergabunglah dengan cluster, dan restart aplikasi pada node ketiga.

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

  1. Pastikan RabbitMQ tidak berjalan di node:

    # rabbitmqctl stop_app
    
  2. 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.

[ English | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia ]

Menjalankan ad-hoc Ansible plays

Menjadi terbiasa dengan menjalankan perintah Ad-hoc Ansible sangat membantu ketika mengoperasikan penyebaran OpenStack-Ansible Anda. Misalnya, jika kita melihat struktur perintah ansible berikut:

$ ansible example_group -m shell -a 'hostname'

Perintah ini memanggil Ansible untuk menjalankan example_group menggunakan modul shell -m dengan argumen -a sebagai perintah hostname. Anda dapat mengganti grup untuk grup lain yang telah Anda tentukan. Misalnya, jika Anda memiliki compute_hosts dalam satu grup dan infra_hosts di grup lain, berikan salah satu nama grup dan jalankan perintah. Anda juga dapat menggunakan wild card * jika Anda hanya mengetahui bagian pertama dari nama grup, misalnya, compute_h * ``. Argumen ``-m 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 subkumpulan grup, Anda bisa menggunakan tanda batas (limit flag) -l. Sebagai contoh, jika grup compute_hosts berisi compute1, compute2, compute3, dan compute4, dan Anda hanya perlu menjalankan perintah pada compute1 dan compute4:

$ 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 dan 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 -h 127.0.0.1\
-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

Copy modul menyalin file di komputer lokal ke lokasi remote. Gunakan modul fetch untuk menyalin file dari lokasi remote ke mesin lokal. 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'

Jika Anda ingin mengumpulkan file dari mesin jarak jauh (remote), gunakan modul ambil (fetch). Modul fetch menyimpan file secara lokal di dalam sebuah pohon file (file tree), diorganisir oleh hostname dari mesin remote dan menyimpannya secara lokal di dalam sebuah file tree, diatur oleh hostname.

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 limit flag untuk grup kecuali tag digunakan hanya untuk menjalankan tugas tertentu dalam pedoman. 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:

[ English | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia ]

Manajemen kontainer

Dengan Ansible, proses instalasi OpenStack sepenuhnya otomatis menggunakan playbook yang ditulis dalam YAML. Setelah instalasi, pengaturan yang dikonfigurasi oleh playbook dapat diubah dan dimodifikasi. Layanan dan kontainer dapat bergeser untuk mengakomodasi persyaratan lingkungan tertentu. Layanan skala dapat dicapai dengan menyesuaikan layanan dalam kontainer, atau menambahkan grup penerapan baru. Juga dimungkinkan untuk menghancurkan kontainer jika diperlukan 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

  1. Arahkan ke file /etc/openstack_deploy/openstack_user_config.yml.

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

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

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

  1. Arahkan ke direktori openstack-ansible.

  2. 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"
    
  3. Ganti ``CONTAINER_NAME`` dengan kontainer target.

[ English | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia ]

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 firewall OpenStack generik, lihat Firewalls and default ports

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

Catatan

OpenStack-Ansible's vars grup dengan mudah mengekspos var di luar role scope jika Anda mengandalkan grup OpenStack-Ansible untuk mengkonfigurasi firewall Anda.

Menemukan port untuk penyeimbang beban (load balancer) eksternal Anda

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

For example, the os_glance documentation lists the variable glance_service_publicuri. This contains the port used for the reaching the service externally. In this example, it is equal to glance_service_port, whose value is 9292.

Sebagai petunjuk, Anda dapat menemukan seluruh daftar standar URI publik dengan mengeksekusi 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 cukup informasi pada port yang terbuka untuk lingkungan Anda.

[ English | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia ]

Memangkas Arsip Cadangan Inventaris

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

Pemangkasan massal

Anda dapat melakukan pemangkasan massal cadangan 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
Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.