Tugas pemeliharaan¶

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.

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

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)

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.

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

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.

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

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:

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

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

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 ]

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 *

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

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