Dotaz: Simple failover cluster - MAC adress duplicity

[pavele]

Leta mi funguje dvounódový Simple failover cluster založený na ucarp.

Virtuální IP adresa má stejnou MAC jako IP adresa hostitele, což se mi nezdá dobré.

Řešení znám několik:

- upravit skript vytvářející virtuální IP adresu, aby k ní také vytvořil unikátní MAC

- pomocí arptables "zakrýt" IP adresu hostitele - např. při ssh VirtualIP se požadavek přesměruje z viditelné VirtalIP na "skrytou" IP hostitele

- nedělat nic, vše funguje. Podle některých zdrojů na internetu to nevadí.

Program ucarp je původně vytvořen pro OpenBSD, kde se při vytvoření VirtualIP vytvoří unikátní MAC adresa.

Jak to řešíte vy?

Odpovědi

[Max]

Zkoumal jsem v práci několik možností a nakonec jsem šel cestou Keepalived, který využívá VRRP.
Tzn. mám vyhrazenou jednu vlan pro komunikaci VRRP, mám definováno, že se má IP překlopit v případě, že koncová služba není dostupná (v mém případě nginx server).
Funguje to dobře a rychle. Mám takto řešen failover pro nginx proxy server.
Tzn. jedu active/pasive. Nicméně lze tím řešit i load balancer a jet active-active (=mít dvě IP, u jedné mít větší prioritu na node1, u druhé větší prioritu pro node2 a v rámci DNS řešit rozhazování provozu, v takovém případě je ale pořeba mít vyřešený sticky session). Já load balancer nepotřebuji, takže jedu active-pasive (mám to kvůli lepším možnostem údržby serverů a v případě pádu jedné lokality nemusím nikde nic ručně přepínat a druhá strana naběhne sama).
Další možností je toto řešit na úrovni corosync a pacemaker, ale to mí přijde pro tento účel naprosto zbytečné.
Když nad tím přemýšlím, tak si říkám, že když už to mám sepsané ve firemní wiki, mohl bych to trochu obalit a vydat jako článek (nginx a keepalived).
Zdar Max

[Max]

Jop, jinak ta virtuální IP, co se migruje mezi nody, se nastavuje jako druhá IP na primární interface konkrétního node. Tzn., že MAC je stejná jako primární IP toho node, což je podle mně ok.
Každý interface může mít více IP a není to problém, nevidím v tom nic špatného.
Zdar Max

[Max]

Jinak ucarp implementuje CARP protokol, Keepalived implementuje VRRP.
Oba se chovají podobně (aspoň, co jsem zběžně zkouknul). Rozdíl v tom asi tedy nebude moc velký, dočetl jsem se jen, že CARP není standardizován (od IANA, je to popsáno na wiki), kdežto VRRP je.
Zdar Max

[pavele]

Díky za odpovědi.

Vyhradil jsem pro komunikaci s ucarp samostatnou síťovou kartu a tak jsou PC připojeny mezi sebou přímo přes kabel, bez switche - občas se stalo, že byl výpadek na switchi a PC na sebe neviděli, i když žádný z nich neměl výpadek.

O Keepalived jsem uvažoval, ale nakonec mi ucarp přišel jednodušší na nastavení.

[Max]

Keepalived nastavení je fakt easy, má to jen pár řádků a to jest celé. Každopádně podle mně je jedno, zda používáš UCARP (=z BSD světa), nebo Keepalived. Obojí má dle všeho stejné fce a chová se podobně, né-li stejně a toto chování je podle mně naprosto ok.
Co mi ale přijde jako prasárna jsou řešení alá stejná IP i stejná MAC na dvou různých serverech najednou (např. NLB v režimu unicast od MS).
Zdar Max

[Michal Kubeček]

Virtuální IP adresa má stejnou MAC jako IP adresa hostitele, což se mi nezdá dobré.

Proč?

[pavele]

Kvůli switchi, který spáruje IP adresu s MAC, takže musí měnit MAC tabulku při každé změně IP = zvýšení provozu. Ucarp v OpenBsd vytváří unikátní MAC adresu automaticky, v linuxové verzi ne.

[nelson]

Proč by L2 switch pároval IP a MAC adresu? Switch si udržuje FDB tabulku - MAC x Fyzický port.

[Michal Kubeček]

Přesně tak. Sice je pravda, že v enterprise speaku se občas "switch" říká ledasčemu včetně čistokrevných routerů, ale i tak je to nesmysl. Jakékoli zařízení, které ta korespondence zajímá, prostě musí počítat s možností, že několika různým IP adresám odpovídá stejná MAC adresa.

[V.]

Noo switch hlavně zajímá vazba port - MAC adresa. Vazba MAC adresa - IP adresa zajímá tu funkci krabice, která mluví do "L3".
Výrobci prodávají různé rozšiřující karty pro krabice, takže pak switch může routovat nebo router switchovat.

[Peter Golis]

Nie je to chovanie v dnešnej dobe kadejakých bondingov už trochu obsolete?

[Pepan]

Bonding je na switchi port...

[Peter Golis]

Akurát že pri bondingoch jedna MAC lezie cez viacej portov, a na to som narážal.

[Michal Kubeček]

Ne nutně. Ale switchů, které s tím mají problém, už naštěstí tak moc není.