Cegah Master VRRP menjadi Master setelah gagal

12

Saya memiliki dua mesin (A dan B, A adalah Master) yang menjalankan VRPP (dari keepalived) untuk IP Virtual.

Bagaimana saya bisa mencegah A dari menjadi Guru lagi jika gagal dan muncul kembali (untuk alasan apa pun)?

Saya melakukan ini sehingga kami memiliki satu kegagalan-ke kotak kedua, dan kembali normal akan memerlukan intervensi manual.

linux keepalived vrrp

— MrMagu
sumber

Saya terlalu baru untuk membuat tag "VRRP"

— MrMagu

14

Menurut ini benang yang relatif tua di daftar pengembang keepalived, hal itu bisa dilakukan. Anda menetapkan kedua server menjadi prioritas yang sama (atau tidak sama sekali), dan tidak mendeklarasikan status untuk MASTER atau BACKUP, dan sebagai gantinya setel status ke EQUAL untuk keduanya.

EDIT (07-Des-2017):

Tampaknya EQUAL sebenarnya bukan keadaan yang valid, meskipun tampaknya memberikan efek yang diinginkan pada saat jawaban ini diposting. Harap perhatikan komentar di bawah ini, khususnya tautan ke daftar masalah saat ini untuk tetap disediakan oleh @cristi.

— James Sneeringer
sumber

3

Terima kasih - Juga patut dicatat, menggunakan konfigurasi di atas (dengan prioritas yang sama dan menggunakan "EQUAL") jika tidak ada master yang mengambil alih, instance VRRP dengan IP terendah akan menjadi MASTER.

— MrMagu

1

Ini salah. Lihat pesan ini dari pengembang: github.com/acassen/keepalived/issues/707

— cristi

@cristi - Ini adalah solusi yang berfungsi pada saat itu diposting (2009), yang pada gilirannya didasarkan pada informasi yang saya jelas sudah tahu sudah tua (2003). Saya telah memperbarui tautan dalam jawaban saya untuk yang berfungsi sejak osdir.com tampaknya tidak lagi memiliki arsip keepalived-devel. Saya akan menebak bahwa, pada saat itu, perangkat lunak diam-diam mengabaikan EQUALarahan yang tidak valid dan memperlakukannya seolah-olah tidak ada prioritas sama sekali (yang kebetulan memiliki efek yang diinginkan).

— James Sneeringer

8

Cara kami mengatasi ini adalah dengan menambahkan nopreemptbendera ke file konfigurasi keepalived kami. Tidak harus mengubah apa pun (masih tersisa satu as MASTERdan satu as BACKUPdan sebagainya). Pada dasarnya ini memberitahukannya untuk tidak beralih master hanya karena server baru online, hanya beralih ketika master saat ini gagal.

— davr
sumber

4

dari " article.gmane.org/gmane.linux.keepalived.devel/1537 " Jika "state" diatur ke MASTER, "nopreempt" pada dasarnya diabaikan karena ketika mesin dengan "state MASTER" kembali, ia hanya akan mengambil IP dari mesin dengan "state BACKUP" bahkan tanpa mengadakan pemilihan. Saya harus mengatur kedua mesin saya untuk menyatakan CADANGAN dengan yang memiliki prioritas lebih tinggi agar "nopreempt" berfungsi sebagaimana dimaksud.

— MrMagu

Prioritas dan status dihapus dan ditambahkan nopreempt. Bekerja dengan baik untuk saya

— Rihard Novozhilov

-1

Seperti yang saya pahami, ketika server VRRP baru muncul, itu memaksa pemilihan, dan server saat ini tidak mendapatkan manfaat apa pun, sehingga master lama akan datang dan memenangkan pemilihan. Saya ragu ada banyak yang bisa Anda lakukan untuk menghentikan ini, di luar Tembak Yang Lain Node Di Kepala. Keepalive mungkin memiliki beberapa konfigurasi untuk mengontrol proses pemilihan. Sayangnya saya tidak punya waktu untuk memeriksa sekarang, tetapi saya akan mencoba untuk melihat nanti.

— David Pashley
sumber

Ada bendera konfigurasi untuk melakukan ini, jadi jawaban ini salah.

— davr

Jawaban yang dipilih sudah benar untuk penggunaan umum vrrp di mana Anda tidak ingin master mengambil alih ketika kembali ke layanan. Seperti yang Anda katakan, ada juga cara tetap melakukan hal ini yang mungkin lebih tepat untuk ketika melakukan hal-hal linux HA daripada hanya menggunakan vrrp untuk menyediakan redundansi L3 untuk rute default (alasan tradisional untuk menggunakan vrrp).

— chris