hbal - Online di Cloud

PROGRAM:

NAMA

hbal - Penyeimbang cluster untuk Ganeti

RINGKASAN

hbal {opsi backend...} [opsi algoritma...] [opsi pelaporan...]

hbal --Versi: kapan

Opsi latar belakang:

{ -m kelompok | -L[ path ] [-X] | -t file data | -I path }

Opsi algoritma:

[ --max-cpu rasio cpu ] [ --min-disk disk-rasio ] [ -l membatasi ] [ -e skor ] [ -g delta ] [
--min-mendapatkan-batas ambang ] [ -O nama... ] [ --tidak-disk-bergerak ] [ --tanpa-contoh-bergerak ] [
-U file-util ] [ --abaikan-dynu ] [ --abaikan-kesalahan lunak ] [ --mond ya|tidak ] [ --mond-xen ]
[ --keluar-saat-data-mond hilang ] [ --mode evac ] [ --migrasi-terbatas ] [
--pilih-contoh langsung... ] [ --kecuali-instance langsung... ]

Opsi pelaporan:

[ -C[ fillet ] ] [ -P[ bidang ] ] [ --cetak-contoh ] [ -S fillet ] [ -v... | -q ]

DESKRIPSI

hbal adalah penyeimbang cluster yang melihat status cluster saat ini (node ​​dengan
disk total dan bebas, memori, dll.) dan penempatan instans dan menghitung serangkaian
langkah-langkah yang dirancang untuk membawa cluster ke keadaan yang lebih baik.

Algoritme yang digunakan dirancang agar stabil (yaitu akan memberi Anda hasil yang sama ketika
memulai kembali dari tengah solusi) dan cukup cepat. Hal ini tidak, bagaimanapun,
dirancang untuk menjadi algoritma yang sempurna: dimungkinkan untuk membuatnya menjadi sudut dari mana
tidak dapat menemukan perbaikan, karena terlihat hanya satu "langkah" di depan.

Program mengakses status cluster melalui Rapi atau Luxi. Itu juga meminta data melalui
jaringan dari semua MonD dengan opsi --mond. Saat ini hanya menggunakan data yang dihasilkan oleh
Kolektor beban CPU.

Secara default, program akan menampilkan solusi secara bertahap saat dihitung, dalam a
format yang agak samar; untuk mendapatkan daftar perintah Ganeti yang sebenarnya, gunakan -C .

ALGORITMA
Program ini bekerja dalam langkah-langkah independen; pada setiap langkah, kami menghitung langkah instan terbaik
yang menurunkan skor cluster.

Jenis pemindahan yang mungkin untuk sebuah instans adalah kombinasi dari failover/migrasi dan
ganti-disk sedemikian rupa sehingga kami mengubah salah satu node instance, dan yang lainnya tetap
(tetapi mungkin dengan perubahan peran, misalnya dari primer menjadi sekunder). Daftarnya adalah:

· kegagalan (f)

· ganti sekunder (r)

· ganti primer, gerakan komposit (f, r, f)

· failover dan mengganti sekunder, juga komposit (f, r)

· ganti sekunder dan failover, juga komposit (r, f)

Kami tidak melakukan satu-satunya kemungkinan yang tersisa untuk mengganti kedua node (r,f,r,f atau the
ekuivalen f,r,f,r) karena langkah ini membutuhkan pencarian menyeluruh atas kedua kandidat
node primer dan sekunder, dan O(n*n) dalam jumlah node. Selanjutnya, itu
tampaknya tidak memberikan skor yang lebih baik tetapi akan menghasilkan lebih banyak penggantian disk.

PENEMPATAN BATASAN
Pada setiap langkah, kami mencegah perpindahan instans jika itu akan menyebabkan:

· sebuah simpul untuk masuk ke status kegagalan N+1

· sebuah instance untuk pindah ke node offline (node ​​offline dibaca dari cluster
atau dinyatakan dengan -O; node yang dikeringkan dianggap offline)

· konflik berbasis tag pengecualian (tag pengecualian dibaca dari cluster dan/atau ditentukan
melalui --pengecualian-tag opsional)

· rasio vcpu/pcpu maks yang harus dilampaui (dikonfigurasi melalui --max-cpu)

· Persentase minimum disk gratis untuk berada di bawah batas yang dikonfigurasi (dikonfigurasi melalui --min-disk)

KLASTER SKOR
Seperti yang dikatakan sebelumnya, algoritma mencoba untuk meminimalkan skor cluster pada setiap langkah. Saat ini
skor ini dihitung sebagai jumlah tertimbang dari komponen berikut:

· standar deviasi persentase memori bebas

· standar deviasi dari persentase memori yang dicadangkan

· jumlah persentase memori yang dicadangkan

· standar deviasi persentase disk kosong

· jumlah node gagal N+1 check

· jumlah instance yang hidup (baik sebagai primer atau sekunder) pada node offline; dalam
rasa node terkuras hbal (dan htools lainnya) dianggap offline

· jumlah instance yang hidup (sebagai primer) di node offline; ini berbeda dari yang di atas
metrik dengan membantu failover dari instance semacam itu di cluster 2-node

· standar deviasi rasio CPU virtual-ke-fisik (untuk contoh utama dari
simpul)

· standar deviasi dari fraksi spindel yang tersedia (dalam mode khusus,
spindel mewakili spindel fisik; jika tidak, ukuran kelebihan permintaan ini untuk IO
beban, dan faktor kelebihan langganan diperhitungkan saat menghitung jumlah
poros yang tersedia)

· standar deviasi dari beban dinamis pada node, untuk cpus, memori, disk dan jaringan

· standar deviasi beban CPU yang disediakan oleh MonD

· jumlah instance dengan primer dan sekunder dalam domain kegagalan yang sama

Memori bebas dan nilai disk kosong membantu memastikan bahwa semua node agak seimbang dalam
penggunaan sumber daya mereka. Memori yang dicadangkan membantu memastikan bahwa node agak
seimbang dalam memegang instance sekunder, dan tidak ada node yang menyimpan terlalu banyak memori yang dicadangkan
untuk N+1. Dan akhirnya, persentase N+1 membantu memandu algoritme menuju eliminasi
N+1 kegagalan, jika memungkinkan.

Kecuali untuk kegagalan N+1, jumlah instance offline, dan pelanggaran domain kegagalan
dihitung, kami menggunakan standar deviasi karena ketika digunakan dengan nilai dalam rentang tetap (kami
gunakan persen yang dinyatakan sebagai nilai antara nol dan satu) ini memberikan hasil yang konsisten di seluruh
semua metrik (ada beberapa masalah kecil yang terkait dengan cara yang berbeda, tetapi berhasil
umumnya baik). Nilai tipe 'hitungan' akan memiliki skor yang lebih tinggi dan dengan demikian akan lebih berarti
untuk menyeimbangkan; jadi ini lebih baik untuk kendala keras (seperti mengevakuasi node dan
memperbaiki N+1 kegagalan). Misalnya, jumlah instans offline (yaitu jumlah
instance yang hidup di node offline) akan menyebabkan algoritme memindahkan instance secara aktif
jauh dari node offline. Ini, ditambah dengan pembatasan penempatan yang diberikan secara offline
node, akan menyebabkan evakuasi node tersebut.

Nilai beban dinamis perlu dibaca dari file eksternal (Ganeti tidak menyediakan
mereka), dan dihitung untuk setiap node sebagai: jumlah beban cpu instance primer, jumlah beban cpu primer
beban memori instans, jumlah beban disk instans primer dan sekunder (seperti yang dihasilkan DRBD
tulis beban pada node sekunder juga dalam kasus normal dan dalam skenario yang terdegradasi juga baca
load), dan jumlah beban jaringan instance utama. Contoh cara menghasilkan ini
nilai untuk input ke hbal adalah melacak daftar xm untuk instance selama satu hari dan
menghitung delta nilai cpu, dan memasukkannya melalui -U opsi untuk semua instance
(dan pertahankan metrik lainnya sebagai satu). Agar algoritme berfungsi, yang diperlukan hanyalah
bahwa nilainya konsisten untuk metrik di semua instance (mis. semua instance menggunakan
cpu% untuk melaporkan penggunaan cpu, dan bukan sesuatu yang berhubungan dengan jumlah detik CPU yang digunakan jika
CPU berbeda), dan dinormalisasi antara nol dan satu. Perhatikan bahwa itu
direkomendasikan untuk tidak memiliki nol sebagai nilai beban untuk metrik instans apa pun sejak saat itu
contoh sekunder tidak seimbang.

Beban CPU dari pengumpul data MonD hanya akan digunakan jika semua MonD berjalan,
jika tidak, itu tidak akan mempengaruhi skor cluster. Karena kami tidak dapat menemukan beban CPU masing-masing
contoh, kita dapat mengasumsikan bahwa beban CPU dari sebuah instance sebanding dengan jumlah
vcpus-nya. Dengan heuristik ini, instance dari node dengan beban CPU tinggi akan cenderung berpindah
ke node dengan beban CPU yang lebih sedikit.

Pada cluster yang seimbang sempurna (semua node berukuran sama, semua instance berukuran sama dan
tersebar di seluruh node secara merata), nilai untuk semua metrik akan menjadi nol, dengan
pengecualian dari persentase total memori yang dicadangkan. Ini tidak terlalu sering terjadi di
praktek :)

OFFLINE CONTOH
Karena versi Ganeti saat ini tidak melaporkan memori yang digunakan oleh instance offline (down),
mengabaikan status menjalankan instance akan menyebabkan perhitungan yang salah. Untuk alasan ini,
algoritme mengurangi ukuran memori instance turun dari memori node bebas dari mereka
node utama, pada dasarnya mensimulasikan startup dari instance tersebut.

PENGECUALIAN TAGS
Mekanisme tag pengecualian dirancang untuk mencegah instance yang menjalankan beban kerja yang sama
(misalnya dua server DNS) untuk mendarat di node yang sama, yang akan membuat node masing-masing a
SPOF untuk layanan yang diberikan.

Ini bekerja dengan menandai instance dengan tag tertentu dan kemudian membuat peta pengecualian berdasarkan
ini. Tag mana yang sebenarnya digunakan dikonfigurasi baik melalui baris perintah (opsi
--pengecualian-tag) atau dengan menambahkannya ke tag cluster:

--tag-pengecualian=a,b
Ini akan membuat semua tag instan dari formulir sebuah:*, B:* dipertimbangkan untuk
peta pengecualian

kelompok tag htools:iextags:a, htools:iextags:b
Ini akan membuat tag instan sebuah:*, B:* dipertimbangkan untuk peta pengecualian. Lagi
tepatnya, akhiran tag cluster dimulai dengan htools:iextags: akan menjadi
awalan tag pengecualian.

Kedua bentuk di atas berarti bahwa dua contoh keduanya memiliki (misalnya) tag a: foo or b: batang
tidak akan berakhir pada simpul yang sama.

MIGRASI TAGS
Jika Ganeti digunakan pada cluster yang heterogen, migrasi mungkin tidak dapat dilakukan antara
semua node dari grup node. Salah satu contoh situasi seperti itu adalah meningkatkan hypervisor
simpul demi simpul. Untuk membuat hbal mengetahui batasan tersebut, tag cluster berikut adalah:
bekas.

kelompok tag htools:migrasi:a, htools:migrasi:b, dll
Ini membuat tag simpul dari formulir sebuah:*, B:*, dll dianggap migrasi
larangan. Lebih tepatnya, akhiran tag cluster dimulai dengan
htools:migrasi: akan menjadi awalan dari tag migrasi. Hanya itu
migrasi akan dipertimbangkan di mana semua tag migrasi dari sumber
node juga hadir pada node target.

kelompok tag htools:izinkanmigrasi:x::y untuk migrasi tag x dan y
Ini menegaskan bahwa sebuah simpul diberi tag y dapat menerima instance dengan cara yang sama seperti jika
mereka punya x menandai.

Jadi dalam kasus sederhana upgrade hypervisor, menandai semua node yang telah
ditingkatkan dengan tag migrasi sudah cukup. Dalam situasi yang lebih rumit, selalu
memungkinkan untuk menggunakan tag migrasi yang berbeda untuk setiap hypervisor yang digunakan dan secara eksplisit menyatakan
arah migrasi yang diizinkan melalui htools:izinkanmigrasi: tag.

LOKASI TAGS
Dalam grup node, node tertentu mungkin lebih mungkin gagal secara bersamaan karena a
penyebab umum kesalahan (misalnya, jika mereka berbagi unit catu daya yang sama). Ganeti bisa jadi
disadarkan tentang penyebab umum kegagalan melalui tag.

kelompok tag htools: lokasi: a, htools: lokasi: b, dll
Ini membuat tag simpul dari formulir sebuah:*, B:*, dll dianggap memiliki kesamaan
penyebab kegagalan.

Instance dengan node primer dan sekunder yang memiliki penyebab umum kegagalan dipertimbangkan
ditempatkan dengan buruk. Meskipun penempatan seperti itu selalu diizinkan, mereka sangat diperhitungkan dalam
skor klaster.

PILIHAN

Opsi yang dapat diteruskan ke program adalah sebagai berikut:

-C, --print-perintah
Cetak daftar perintah di akhir proses. Tanpa ini, program hanya akan
menunjukkan output yang lebih pendek, tetapi samar.

Perhatikan bahwa daftar gerakan akan dibagi menjadi langkah-langkah independen, yang disebut "jobsets",
tetapi hanya untuk inspeksi visual, bukan untuk paralelisasi yang sebenarnya. Bukan itu
mungkin untuk memparalelkan ini secara langsung ketika dijalankan melalui perintah "gnt-instance",
karena perintah gabungan (misalnya failover dan replace-disk) harus dijalankan
secara berurutan. Eksekusi paralel hanya dimungkinkan saat menggunakan backend Luxi dan
-L .

Algoritma untuk membagi gerakan menjadi kumpulan pekerjaan adalah dengan mengumpulkan gerakan sampai
langkah selanjutnya menyentuh node yang sudah tersentuh oleh gerakan saat ini; ini berarti kita
tidak dapat dijalankan secara paralel (karena alokasi sumber daya di Ganeti) dan dengan demikian kami mulai
kumpulan pekerjaan baru.

-P, --print-node
Mencetak status node sebelum dan sesudah, dalam format yang dirancang untuk memungkinkan pengguna
memahami parameter node yang paling penting. Lihat halaman manual alat(1) untuk
lebih detail tentang opsi ini.

--cetak-contoh
Mencetak peta contoh sebelum dan sesudah. Ini kurang berguna sebagai status simpul,
tetapi dapat membantu dalam memahami gerakan instan.

-O nama
Opsi ini (yang dapat diberikan beberapa kali) akan menandai node sebagai Pengunjung.
Ini berarti beberapa hal:

· contoh tidak akan ditempatkan pada node ini, bahkan untuk sementara; misalnya menggantikan
primer pemindahan tidak tersedia jika simpul sekunder sedang offline, karena pemindahan ini
membutuhkan failover.

· node ini tidak akan dimasukkan dalam perhitungan skor (kecuali untuk
persentase instance pada node offline)

Perhatikan bahwa algoritme juga akan menandai sebagai offline setiap node yang dilaporkan oleh RAPI
seperti itu, atau yang memiliki "?" dalam input berbasis file di bidang numerik apa pun.

-e skor, --min-skor=*skor*
Parameter ini menunjukkan seberapa banyak di atas N+1 terikat skor cluster dapat bagi kita untuk
senang dengan dan mengubah perhitungan dalam dua cara:

· jika cluster memiliki skor awal lebih rendah dari nilai ini, maka kami tidak masuk
algoritma sama sekali, dan keluar dengan sukses

· selama proses berulang, jika kami mencapai skor lebih rendah dari nilai ini, kami keluar
algoritme

Nilai default parameter saat ini adalah 1e-9 (dipilih secara empiris).

-g delta, --pendapatan-min=*delta*
Karena algoritme penyeimbangan terkadang hanya menghasilkan peningkatan yang sangat kecil,
yang membawa lebih sedikit keuntungan daripada biayanya dalam waktu relokasi, parameter ini (default
hingga 0.01) mewakili perolehan minimum yang kami butuhkan selama satu langkah, untuk melanjutkan
menyeimbangkan.

--min-gain-limit=*ambang*
Opsi min-gain di atas hanya akan berlaku jika skor cluster sudah
di bawah ambang (default ke 0.1). Alasan di balik pengaturan ini adalah bahwa di
skor cluster tinggi (cluster sangat seimbang), kami tidak ingin membatalkan penyeimbangan kembali
terlalu cepat, karena keuntungan di kemudian hari mungkin masih signifikan. Namun, di bawah
threshold, total gain hanya nilai threshold, jadi kita bisa exit lebih awal.

--tidak-disk-bergerak
Parameter ini mencegah hbal menggunakan pemindahan disk (yaitu "gnt-instance
ganti-disk") operasi. Ini akan menghasilkan penyeimbangan yang jauh lebih cepat, tetapi tentu saja
tentu saja perbaikannya terbatas. Terserah pengguna untuk memutuskan kapan harus menggunakan
satu atau yang lain.

--tanpa-contoh-bergerak
Parameter ini mencegah hbal menggunakan perpindahan instans (yaitu "gnt-instance
operasi migrasi/failover"). Ini hanya akan menggunakan penggantian disk yang lambat
operasi, dan juga akan memberikan keseimbangan yang lebih buruk, tetapi dapat berguna jika bergerak
contoh di sekitar dianggap tidak aman atau tidak disukai.

--mode evac
Parameter ini membatasi daftar instance yang dipertimbangkan untuk dipindahkan ke yang
hidup di node offline/terkuras. Ini dapat digunakan sebagai pengganti (massal) untuk
milik Ganeti gnt-node mengungsi, dengan catatan tidak menjamin full
pengungsian.

--migrasi-terbatas
Parameter ini melarang setiap gerakan utama pengganti (frf), serta yang
gerakan replace-and-failover (rf) di mana node utama dari instance tidak
dikeringkan. Jika digunakan bersama dengan opsi --evac-mode, satu-satunya migrasi yang
hbal akan lakukan adalah migrasi instance dari node yang terkuras. Ini bisa berguna jika
selama penginstalan ulang migrasi sistem operasi dasar hanya dimungkinkan dari
OS lama ke OS baru. Namun, perhatikan bahwa biasanya penggunaan tag migrasi adalah
pilihan yang lebih baik.

--select-instances=*contoh*
Parameter ini menandai instance yang diberikan (sebagai daftar yang dipisahkan koma) sebagai satu-satunya
yang dipindahkan selama penyeimbangan kembali.

--exclude-instances=*contoh*
Parameter ini menandai instance yang diberikan (sebagai daftar yang dipisahkan koma) dari menjadi
dipindahkan selama penyeimbangan kembali.

-U file-util
Parameter ini menentukan file yang menyimpan informasi pemanfaatan dinamis instan
yang akan digunakan untuk men-tweak algoritma penyeimbangan untuk menyamakan beban pada node
(sebagai lawan dari penggunaan sumber daya statis). File dalam format "instance_name
cpu_util mem_util disk_util net_util" di mana parameter "_util" ditafsirkan
sebagai angka dan nama instance harus sama persis dengan instance yang dibaca dari
Ganeti. Jika nama instance tidak diketahui, program akan dibatalkan.

Jika tidak diberikan, nilai default adalah satu untuk semua metrik dan dengan demikian dinamis
pemanfaatan hanya memiliki satu efek pada algoritme: pemerataan sekunder
instance di seluruh node (ini adalah satu-satunya metrik yang tidak dilacak oleh yang lain,
nilai khusus, dan dengan demikian beban disk instance akan menyebabkan instance sekunder
hal menyamakan). Perhatikan bahwa nilai satu juga akan sedikit memengaruhi yang utama
jumlah instance, tetapi itu sudah dilacak melalui metrik lain dan dengan demikian
pengaruh pemanfaatan dinamis akan praktis tidak signifikan.

--abaikan-dynu
Jika diberikan, semua informasi pemanfaatan dinamis akan diabaikan dengan menganggapnya sebagai
0. Opsi ini akan didahulukan dari data apa pun yang diteruskan oleh opsi -U atau oleh
MonD dengan opsi --mond dan --mond-data.

--abaikan-kesalahan lunak
Jika diberikan, semua pemeriksaan untuk kesalahan lunak akan dihilangkan saat mempertimbangkan penyeimbangan
bergerak. Dengan cara ini, kemajuan dapat dibuat dalam sebuah cluster di mana semua node berada dalam a
keadaan buruk dari segi kebijakan, seperti melebihi rasio langganan berlebih pada CPU atau spindel.

-S nama file, --save-cluster=*nama file*
Jika diberikan, status cluster sebelum penyeimbangan disimpan ke file yang diberikan
ditambah ekstensi "asli" (mis nama file.original), dan status di akhir
dari penyeimbangan disimpan ke file yang diberikan ditambah ekstensi "seimbang" (mis
nama file.seimbang). Ini memungkinkan memberi makan kembali status cluster ke hbal itu sendiri
atau misalnya hspace melalui opsi -t.

-t file data, --text-data=*file data*
Spesifikasi backend: nama node penyimpanan file dan informasi instance
(jika tidak mengumpulkan melalui RAPI atau LUXI). Ini atau salah satu backend lainnya harus
terpilih. Opsi dijelaskan di halaman manual alat(1).

--mond=*ya|tidak*
Jika diberikan, program akan meminta semua MonD untuk mengambil data dari data yang didukung
kolektor melalui jaringan.

--mond-xen
Jika diberikan, tanyakan juga kolektor khusus Xen dari MonD, asalkan pemantauan itu
daemon ditanyakan sama sekali.

--keluar-saat-data-mond hilang
Jika diberikan, batalkan jika data yang diperoleh dari kueri MonDs tidak lengkap. Itu
perilaku default adalah melanjutkan dengan tebakan terbaik berdasarkan informasi statis.

--mond-data file data
Nama file yang menyimpan data yang disediakan oleh MonD, untuk menggantikan kueri MonDs
melalui jaringan. Ini sebagian besar digunakan untuk debugging. File harus dalam JSON
memformat dan menyajikan larik objek JSON , satu untuk setiap node, dengan dua anggota.
Anggota pertama bernama node adalah nama node dan anggota kedua bernama
laporan adalah array objek laporan. Objek laporan harus sama
format seperti yang dihasilkan oleh agen pemantau.

-m kelompok
Spesifikasi backend: kumpulkan data langsung dari kelompok diberikan sebagai argumen
melalui RAPI. Opsi dijelaskan di halaman manual alat(1).

-L [path]
Spesifikasi backend: mengumpulkan data langsung dari daemon master, yang akan menjadi
dihubungi melalui LUXI (protokol internal Ganeti). Opsi dijelaskan dalam
halaman manual alat(1).

-X Saat menggunakan backend Luxi, hbal juga dapat menjalankan perintah yang diberikan. Itu
metode eksekusi adalah untuk mengeksekusi jobset individu (lihat -C pilihan untuk
detail) dalam tahap terpisah, dibatalkan jika suatu saat suatu jobset tidak memiliki semua pekerjaan
berhasil. Setiap langkah dalam solusi penyeimbangan akan diterjemahkan menjadi tepat
satu pekerjaan Ganeti (memiliki antara satu dan tiga OpCodes), dan semua langkah dalam a
jobset akan dieksekusi secara paralel. Jobset itu sendiri dieksekusi secara serial.

Eksekusi rangkaian pekerjaan dapat terganggu, lihat di bawah untuk penanganan sinyal.

-l N, --max-panjang=*N*
Batasi solusi untuk panjang ini. Ini dapat digunakan misalnya untuk mengotomatisasi
pelaksanaan penimbangan.

--max-cpu=*rasio-cpu*
Rasio cpu virtual ke fisik maksimum, sebagai angka floating point lebih besar dari
atau sama dengan satu. Misalnya, menentukan rasio cpu as 2.5 berarti bahwa, untuk 4-cpu
mesin, maksimal 10 cpus virtual harus diizinkan untuk digunakan untuk primer
contoh. Nilai tepat satu berarti tidak akan ada kelebihan langganan CPU
(kecuali untuk waktu CPU yang digunakan oleh node itu sendiri), dan nilai di bawah satu tidak membuat
masuk akal, karena itu berarti sumber daya lain (misalnya disk) tidak akan digunakan sepenuhnya karena
pembatasan CPU.

--min-disk=*rasio-disk*
Jumlah minimum ruang disk kosong yang tersisa, sebagai angka floating point. Untuk
contoh, menentukan disk-rasio as 0.25 berarti setidaknya seperempat dari disk
ruang harus dibiarkan bebas pada node.

-G uuid, --grup=*uuid*
Pada cluster multi-grup, pilih grup ini untuk diproses. Jika tidak, hbal akan
batalkan, karena tidak dapat menyeimbangkan beberapa grup secara bersamaan.

-di, --bertele-tele
Meningkatkan verbositas keluaran. Setiap penggunaan opsi ini akan meningkatkan
verbositas (saat ini lebih dari 2 tidak masuk akal) dari default satu.

-Q, --diam
Kurangi verbositas keluaran. Setiap penggunaan opsi ini akan mengurangi
verbositas (kurang dari nol tidak masuk akal) dari default satu.

-V, --Versi: kapan
Cukup tunjukkan versi program dan keluar.

SINYAL PENANGANAN

Saat menjalankan pekerjaan melalui LUXI (menggunakan opsi -X), biasanya hbal akan menjalankan semua pekerjaan
sampai salah satu kesalahan keluar atau semua pekerjaan selesai dengan sukses.

Karena penyeimbangan bisa memakan waktu lama, adalah mungkin untuk menghentikan hbal lebih awal dengan dua cara:

· dengan mengirimkan SIGINT (^C), hbal akan mendaftarkan permintaan penghentian, dan akan menunggu
sampai pekerjaan yang dikirimkan saat ini selesai, pada titik mana pekerjaan itu akan keluar (dengan kode keluar 0
jika semua pekerjaan selesai dengan benar, sebaliknya dengan kode keluar 1 seperti biasa)

· dengan mengirimkan SIGTERM, hbal akan langsung exit (dengan exit code 2); ini adalah
tanggung jawab pengguna untuk menindaklanjuti dengan Ganeti dan memeriksa hasil dari
pekerjaan yang sedang dijalankan

Perhatikan bahwa dalam situasi apa pun, sangat aman untuk membunuh hbal, baik melalui sinyal di atas
atau melalui sinyal lain (misalnya SIGQUIT, SIGKILL), karena pekerjaan itu sendiri diproses
oleh Ganeti sedangkan hbal (setelah penyerahan) hanya melihat perkembangan mereka. Pada kasus ini,
pengguna harus menanyakan Ganeti untuk hasil pekerjaan.

EXIT STATUS

Status keluar dari perintah akan menjadi nol, kecuali karena alasan tertentu algoritme gagal
(mis. node atau data instance yang salah), opsi baris perintah yang tidak valid, atau (jika ada pekerjaan
eksekusi) salah satu pekerjaan telah gagal.

Setelah eksekusi pekerjaan melalui Luxi telah dimulai (-X), jika penyeimbangan terganggu lebih awal (via
SIGINT, atau melalui --max-length) tetapi semua pekerjaan berhasil dijalankan, maka status keluarnya adalah
nol; kode keluar bukan nol berarti bahwa status cluster harus diselidiki, karena a
pekerjaan gagal atau kami tidak dapat menghitung statusnya dan ini juga dapat menunjukkan masalah pada
sisi Ganeti.

Gunakan hbal online menggunakan layanan onworks.net