szerver hosting: virtuális IP mint publikus IP, IP cím átvétel failover esetén?

UNIX haladó

Sziasztok!

Van egy konkrét (elméleti) feladatra van megoldási javaslatom, csak nem tudom, hogy van-e logikusabb, jobb vagy nyilvánvalóbb erre.

Adott 4 gép. Mind a 4 azonos szerver teremben lenne, azonos switch-re kötve. Mind a 4 gépben van 2 hálózati kártya. A 2-2 gép párban össze lenne kötve. A párban összekötött gépeken DRBD, aktív/passzív üzemmódban. Az aktív gépen működnek a szolgáltatások (web szerver, levelezés, stb), a passzív gép pedig csak szinkronizál. Failover esetén a passzív gép átveszi az aktív gép szerepét, és elindítja a szolgáltatásokat.
Itt most a kérdés, az IP címek.
Ha VIP-ként, virtuális IP címként lenne kezelve a páronként 1-1 IP cím, az tökéletesen működhet? Tehát az aktívé a publikus IP, majd ha történik valami ezzel az aktív szerverrel, akkor a passzív veszi át a publikus IP címét.

Ilyen átvételnél a szerver fingerprint változik. Ez elkerülhető, vagy van értelme, hogy elkerülhető legyen?

A 4 gép azért is jó, mert egy subnetben lesznek és bármelyik publikusról el tudom majd érni a nem publikus IP-vel rendelkező gépeket.

A passzív gépet pedig az aktív gépről SSH hozzáférésről érném el.

A kérdésem, hogy ez így OK? Van más ésszerűbb megoldás erre?

Milyen alternatív megoldások vannak erre? Tehát hogy a 4 gépből egyszerre csak 2-nek van publikus IP-je, a másik 1-1 gép pedig tartalék gép.

Köszönöm előre is a véleményed... :-)

KaTT

( andrej_ v | 2014. 09. 16., k – 14:04 )

Nézz ezeknek utána: CARP és VRRP :)

Szia Andrej_! Köszönöm, utána nézek ezeknek, a CARP így első hallásra szimpatikus, mert pontyot jelent magyarra fordítva és jó a pontyra horgászni... VRRP-re még nem horgásztam... ;-)

CentOS-hez UCARP / U-CARP-ot találtam. ( http://www.pureftpd.org/project/ucarp )
Írok, ha elolvastam és megértettem.

Például az UCARP-ot hogy kell illeszteni DRBD-hez?
Ha lesz drbd + corosync + pacemaker, ez nem oldja ezt meg, kell az (U)CARP is?
(Kérdezem mindezt úgy, hogy még nem tudom, pontosan mit csinál a corosync és pacemaker... tudom, tudom, RTFM, RTFM... :-)

Sakk-matt,
KaTT :)

Az UCARP (linuon) azt tudja, hogy van egy master és X db slave. Ezek broadcaston kommunikálnak egymással, ha a master elesik, akkor a legnagyobb pontszámú slave lép elő masterré. Ekkor lefuttat egy szkriptet, ha visszajön másik master, stb. akkor meg lefuttat egy másik szkriptet és ennyi.

Köszönöm, hogy leírtad a lényegét.

Jól értelmezem, ha van 4 szerverem, 2-2 párban, és a párokon futna UCARP, egymástól külön, majd ha a párból az aktív kiesik, akkor a passzív átveszi a publikus IP címét, ami az aktívé volt? Azért írtam le, hogy 4 gép lesz, és 2-nek kell csak publikus IP, hogy egyértelmű legyen, ha hozzá akarok férni a passzív gépekhez, meg tudom tenni bármelyik aktív gépről (mert azoké a publikus IP, mint virtuális IP). Persze, ha kiesik az egyik aktív, és a passzív párja nem működik megfelelően, akkor a másik párból az aktívon át, aminek van publikus IP-je, azon keresztül meg tudom nézni a gépeket, már ha működnek.

Ezt elvileg nem tudja a corosync + pacemaker is, amit az U-CARP? Érdemes lehet ez a kettő mellé, ami a DRBD miatt lesz, U-CARP-ot is felrakni?

Sakk-matt,
KaTT :)

( Zs | 2014. 09. 16., k – 14:14 )

Az alapelgondolás nem rossz - de ne hagyjunk figyelmen kívül olyan lehetőséget, hogy az aktív gép valamiért nem vált be, illetve mi van akkor, ha a crosslink megáll? Szóval az a rész, hogy a passzív gép nem érhető el, nem tűnik jó iránynak. Mindegyik gépnek legyen saját publikus IP-je, amin maga a gép érhető el és a szolgáltatást nyújtó IP legyen ezen felül! Az jó elgondolás, hogy a szolgáltatást nyújtó IP mindig az aktív tagnál van - de hogy a passzív ilyenkor teljesen elérhetetlen, az már nem annyira.

4 gép lesz, ebből 2-nek publikus IP-je.

Akkor lehet gond, ha a 2 aktív gép kiesik és a passzívok nem veszik át a helyüket, mert akkor nincs publikus IP.

Crosslink megállás esetén ott van az, hogy 2 ring lesz definiálva: elsődleges a crosslink, másodlagos a switch-en át. Ez így?

Ha pedig az általad javasolt megoldás lesz, hogy mind a 4 gépnek külön IP, akkor hogy lesz megoldva, hogy a kitt.katt domain néven elérhető lesz az aktív gép a 2 közül? Arra nincs mód, hogy a DNS-t módosítsuk failover esetére. Legalábbis nem akarnék ilyet... Még 2 IP? És akkor lesz 6 publikus IP-je a 4 gépnek, ebből 2 az aktívnak? Ez nem tűnik SZÉP megoldásnak... Gondolom ez még extra költség lenne, a +2 IP...

Sakk-matt,
KaTT :)

A fentebb javasolt CARP szintén 6 IP-t igényel: a CARP kezeli a virtuális IP-t, ami az aktív tagon van - de mindegyik node-nak van saját IP-je is!

A crosslink megállásra definiált két ring nem tiszta: milyen protokollt használna? Csak mert eddig majd minden IP alapokon ment át, akkor viszont a másodlagosnak nevezett switch-en át hogy vezet út? Külső háló felé privát IP-n forgalmazni akkor sem ildomos, ha a szomszéd gépnek üzenek és közös switch-en lógunk. A publikus IP meg ugyan jó a célra, de akkor megint csak 6 IP-nél jársz megint...

Kérdés: miért kell mind a négy gépnek a neten lógnia? Az nem opció, hogy kiválasztasz két gépet, ez a két gép lesz egy pár, mindegyiknek saját IP-je + 1 szolgáltatást nyújtó IP - így összesen csak 3 valós IP kell, a 6 fele de a 2-nél még pincurit ez is több -, ezekre tűzfalat teszel, az összes többi hóbelevancot meg belső hálóba teszed, ahol annyi IP-t használhatsz el, amennyit nem szégyelsz. A szolgáltatásokat meg szépen portforwarddal simán elérheted.

No, jött egy haránt-impulzus... :-) Ha abba az irányba mész, hogy összesen két IP és csak az aktív gépre legyen felhúzva, akkor ez az egész hóbelevanc teljesen jól működhet úgy is, hogy ami miatt én a további IP-ket kértem volna, azt IPv6 alapokon oldod meg! Nem lehetetlen és link-local IPv6 címet minden interface magára ránt. Szép kihívás! ;-)

Helló Zs!

Igen, én is úgy gondoltam, ahogy írtad, hogy mind a 4 gépnek saját IP, valamint az aktívoknak 1-1. Akkor legalább ezt jól látom. Ezt... :D

"A crosslink megállásra definiált két ring nem tiszta: milyen protokollt használna? Csak mert eddig majd minden IP alapokon ment át, akkor viszont a másodlagosnak nevezett switch-en át hogy vezet út? Külső háló felé privát IP-n forgalmazni akkor sem ildomos, ha a szomszéd gépnek üzenek és közös switch-en lógunk. A publikus IP meg ugyan jó a célra, de akkor megint csak 6 IP-nél jársz megint..."

Hát, én leegyszerűsítve úgy gondoltam, hogy a crosslink lenne a gépek eth1-én s1+s2 és s3+s4 között, ez 10.22.22.11, 10.22.22.12, valamint 10.22.22.21 és 10.22.22.22 IP-k,
255.255.255.0 (/24) netmask. Azért ez és így, ha valami miatt mégis külön switch-re vagy VLAN-ra kerülne ez a 4 gép 2. hálókártyája, akkor ne ütközzenek és lássák egymást akár. De itt crosslink kábel lenne, tehát nem látná ugye a 10.22.22.11 a 10.22.22.21-et, csak a 10.22.22.12-t, stb.

Azt eth0 lenne a publikus IP az aktív gépnek, sajnos én első körben privát IP-re gondoltam, mint alap, egyedi IP cím, és a virtuális lenne a publikus IP cím, amit automatizáltan venne fel. Ez mondjuk lehetne 10.99.99.11, 10.99.99.12 és 10.99.99.21, 10.99.99.21, 255.255.255.0 (/24) netmask.

Jól gondolom, hogy kelleni fog routing beállítás is ilyen esetben? Esetleg VLAN támogatás sem lenne rossz? :)

"Kérdés: miért kell mind a négy gépnek a neten lógnia? Az nem opció, hogy kiválasztasz két gépet, ez a két gép lesz egy pár, mindegyiknek saját IP-je + 1 szolgáltatást nyújtó IP - így összesen csak 3 valós IP kell, a 6 fele de a 2-nél még pincurit ez is több -, ezekre tűzfalat teszel, az összes többi hóbelevancot meg belső hálóba teszed, ahol annyi IP-t használhatsz el, amennyit nem szégyelsz. A szolgáltatásokat meg szépen portforwarddal simán elérheted."

Nem kell mind a 4 gépnek a neten lógnia, csak 2-nek, ez is lenne a cél, hogy 2 publikus IP-vel meg lehessen oldani, a 2 pár gépnek az elérhetőségét.
Az első pár web szerver lenne kb, a második pár pedig apróbb feladatok és monitoring. Azért így, hogy mindig menjen 1 működő web szerver és l működő monitoring, ezért kell +1 és +1 gép, de ezért kell csak 1-1 publikus ip.

"No, jött egy haránt-impulzus... :-) "

Sajnos nekem még nem... :-)

IPV6-ról már hallottam, hogy látta valaki amint fotón megörökítik a használatát, így az egyre növekvő IPV4 tudásommal szeretném megoldani ezt.

Sakk-matt,
KaTT :)

Már vártam a kérdést: " kerdes, hogy mi van split brain eseten :-)"

Lesz egy 3. virtuális node (arbiter), ami megmondja, hogy "ki a király" szakadás esetén.
Hogy miként oldom meg, még nem tiszta... :)

A stacked (3) nodes megoldás lehet erre?

http://www.drbd.org/users-guide-8.3/s-pacemaker-stacked-resources.html

Sakk-matt,
KaTT :)

( wpeople v | 2014. 09. 16., k – 21:07 )

csak 1 tipp: nem opció, ha van 1 db saját eszközöd előtte - mondjuk egy Mikrotik router (v egyéb linuxos) router/switch amivel az aktív gépre tudod bökni a portforwardot?
Értem én, hogy parasztos, de ebben az esetben nem feltétlen kell a gépekbe még további hálókártya, a linuxos routerből tudod nézni, h adott port nyitva van-e (azaz a gépen él-e a szolgáltatás) etc.

Nincs, és nem is lenne saját eszköz a 4 szerver előtt. Csak van valami jó megoldás ezek nélkül is... :)
Meg a +1 eszköz előtte pont hogy a redundancia adta előnyöket megszüntetné, mert ha ez az eszközzel van valami, akkor nem megy semmi.
A 2 gép aktív/passzív pont erre jó, ha egyik elszáll, ott a másik, ami megy és üzemel.
Nincs Mikrotik üzemeltetési tapasztalatom, de ha gigabites forgalom menne át a szerveren (csak elméletben), szerintem "palacknyak" lenne ez az eszköz.

A Mikrotik eszközökről csak semlegeset, de főként rosszat hallottam. De amúgy sem merült fel alternatívaként ide.

Az U szájú ponty (U-CARP) ahogy itt ajánlották fentebb, jónak tűnik, itt egy példa:

http://iarlyy.wordpress.com/2010/03/11/ip-failover-with-ucarp-centos/

Én inkább a corosync pacemaker irányba mennék el, az kezeli majd a DRBD-t is, csak még nem használtam:

http://www.linuxquestions.org/questions/linux-software-2/2-node-cluster…

Van értelme corosync + pacemaker mellett U-CARP-ot is felrakni?

Sakk-matt,
KaTT :)

( dap | 2014. 09. 16., k – 23:13 )

Természetesen a Pacemaker kezelje az IP címeket is, semmi VRRP vagy CARP nem kell mellé, gányolás.

A publikus IP címeket ne használd managementre, mert azok kiosztása dinamikusan változik. Legyen mind a 4 szerveren VPN szerver ami a 2 publikus IP-n elérhető. A privát IP címeken menedzseld a szervereket a VPN-en át, másképp csak szivatod magad. Az OpenVPN pl kliens oldalon lekezeli a failovert abban az esetben ha az egyik publikus IP kiesne (csak dupla remote bejegyzés kell).

Milyen fingerprint változik? ssh? Ezt is megoldja az, ha a menedzsment privát IP címen történik.

Nagyon fontos a STONITH konfigurálása, mert ha az aktív node csak letérdel de nem hal meg, akkor képtelen leszel átvenni a passzív node-ra a terhelést. Azt meg ne tudjam, hogy nincs távmenedzsment lehetőség a szerverekben. :)

Helló Dap!

Nem 100% tiszta, hogy működne a javaslatod, így próbálom leírni, hátha kiderül, mit nem értek jól esetlegesen.

Tehát adott mondjuk ez:

Crosslink lenne a gépek eth1-én s1+s2 és s3+s4 között, ez 10.22.22.11, 10.22.22.12, valamint 10.22.22.21 és 10.22.22.22 IP-k,
255.255.255.0 (/24) netmask. Azért ez és így, ha valami miatt mégis külön switch-re vagy VLAN-ra kerülne ez a 4 gép 2. hálókártyája, akkor ne ütközzenek és lássák egymást akár. De itt crosslink kábel lenne, tehát nem látná ugye a 10.22.22.11 a 10.22.22.21-et, csak a 10.22.22.12-t, stb.

Tehát össze van kötve a 2 pár szerver páronként az eth1-en. Az s1 az s2-nek a passzív párja, DRBD-s szinkronizálással, pacemaker + corosync.
Aztán ott az eth0, ami felveszi majd a publikus IP-t, ha aktív, páronként 1-1 darabot.

Azt eth0 lenne a publikus IP az aktív gépnek, sajnos én első körben privát IP-re gondoltam, mint alap, egyedi IP cím, és a virtuális lenne a publikus IP cím, amit automatizáltan venne fel. Ez mondjuk lehetne 10.99.99.11, 10.99.99.12 és 10.99.99.21, 10.99.99.21, 255.255.255.0 (/24) netmask.
Ezek mivel közös switch-en lesznek, így el tudják egymást érni, nem úgy, mint az eth1-en, ami csak crosslink a gépek között.
Ide az eth0-ra jó lenne egy VLAN, amit ha jó fej a szerver hosting cég, akkor megold? Vagy mi lenne ide a jó?
Mennyi a biztonsági kockázata, hogy a szerver teremben valaki megpróbálja elérni ezeket a szervereket az eth0-n a privát címeken, és hogyan? Bár ez a kérdés részben offtopic, viszont érdekes... :)

Szóval ott a felrakott OpenVPN, majd bemegyek a publikus IP címek közül az egyikre VPN-en és el tudom érni a gépeket a kedvenc 10.99.99.x -es címekkel.

Normál esetben az s1+s2 párosból az aktív (s1) felveszi a 109.109.109.1 publikus ip címet, majd a s3+s4 párosból az aktív (s3) pedig a 109.109.109.2 publikus címet.

Így értetted?

"OpenVPN pl kliens oldalon lekezeli a failovert abban az esetben ha az egyik publikus IP kiesne (csak dupla remote bejegyzés kell)."
Az openvpn konfigjában melyik ip címek legyenek megadva? Ezt hogy érted, a fenti példás címeket értve? az eth0 fix privát címei? Vagy melyikek?

"Nagyon fontos a STONITH konfigurálása, mert ha az aktív node csak letérdel de nem hal meg, akkor képtelen leszel átvenni a passzív node-ra a terhelést. "
Erre azt találtam ki. Azt mondták a nálam okosabbak, hogy legyen a DRBD-nél is 3. node (az s1+s2 szervereknek a 3. node-ja az s4-en, az s3+s4 szervereknek pedig az s2-n), valamint ugyanígy a Galera MySQL Cluster-nek is lesz 3. - 3. node-ja (arbiter) ugyanezeken a gépeken. Így elvileg megbízhatóan fog működni az átvétel. Most itt tartok.

A Stonith testvére állítólag a Quorum, bár én sajnos egyiket sem ismerem, de ha cluster-t akarok, akkor jóban kell lennem elvileg mindkettővel... ;-)

"Azt meg ne tudjam, hogy nincs távmenedzsment lehetőség a szerverekben. :)"
Jogos a kérdés, Mester! Természetesen lesz, nem kell izgulnod: bármikor oda tudok menni és bele tudok rúgni a gépbe... :-D
Köszönöm, hogy a hiányos tudásomnak adsz esélyt, hogy javuljon.

Sakk-matt,
KaTT :)

Ok, én is így képzeltem a hálózatot.

> Ide az eth0-ra jó lenne egy VLAN, amit ha jó fej a szerver hosting cég, akkor megold? Vagy mi lenne ide a jó? [...] Mennyi a biztonsági kockázata, hogy a szerver teremben valaki megpróbálja elérni ezeket a szervereket az eth0-n a privát címeken, és hogyan? Bár ez a kérdés részben offtopic, viszont érdekes... :)
Igen, jó lenne, de nem fogja megoldani, mindegy, nem is fontos. Minimális az esélye szerintem, hogy bárki privát IP című gépekre vadászna a LAN-ban, de készülj úgy, hogy igen.

> Szóval ott a felrakott OpenVPN, majd bemegyek a publikus IP címek közül az egyikre VPN-en és el tudom érni a gépeket a kedvenc 10.99.99.x -es címekkel.
Pontosan.

> Az openvpn konfigjában melyik ip címek legyenek megadva? Ezt hogy érted, a fenti példás címeket értve? az eth0 fix privát címei? Vagy melyikek?
Az openvpn füleljen a publikus címeken (de akár a 0.0.0.0/0-n is fülelhet, azaz minden IP-n, így egyszerűbb a konfig) és a szerverek route-oljanak (és masq-oljanak) a privát címek felé a tunnelből. Ez utóbbi iptables feladat. Az openvpn bármilyen tartományból oszhat a VPN-ben IP címet, az nem számít, úgyis el kell masq-olni ha kommunikálsz a szerverek felé.

> Azt mondták a nálam okosabbak, hogy legyen a DRBD-nél is 3. node [...]
Ez nem váltja ki a STONITH-t. Pl képzeld el azt, hogy az aktív node-ban meghal a rendszerdiszk. A cluster megpróbálja majd leléptetni az aktív szerepből, de nem fog neki menni, mert egyetlen scriptje se tud lefutni, így a publikus IP címet se tudja ledobni magáról. A rossz rendszerdiszk viszont nem akadályozza meg a kernelt abban, hogy továbbra is fogja az IP címet. Ha bárhol máshol felhúzod, akkor ütközés lesz, nem tud kommunikálni rajta egyik gép se. Ugyan a rendszerdiszk lehet raid1, de számtalan példa lehet még arra, hogy az aktív node zombi állapotba kerül (OOM, kernel panic, stb).

A STONTIH-t nem minden esetben váltja ki a quorum, pl a fenti szkenárióban sem. (2 gépes redundánsan kommunikáló DRBD mellé szerintem fölösleges a quorum.)

> Természetesen lesz, nem kell izgulnod: bármikor oda tudok menni és bele tudok rúgni a gépbe
Tehát a STONITH: meatware (nem vicc, levelet küld, hogy "lőjj agyon"). Ezzel ne vállalj túl nagy rendelkezésre állást, mert van pár nagyon is reális szkenárió, amikor szükség lesz arra, hogy odamenj és belerúgj. Egy olcsó IPMI-t beszélő szerver lap alapkövetelmény egy ilyen felállásban ha nem csak játékra kell. :(

"és a szerverek route-oljanak (és masq-oljanak) a privát címek felé a tunnelből. "

A routing tudásom frissítem hamarosan, sajnos nagyon keveset kellett használnom.

A Stonith hogy oldja meg az általad javasolt kellemetlen szituációt, amikor meghal a rendszerdiszk és azon a gépen az aktív ip? Mit csinál, hogy a zombi gép eldobja az IP-t?

Dap, ha jól tippelek, neked többször volt kellemetlenséged, hogy leállt a szerver és oda kellett menni, azért javaslod az IPMI-ket, ugye? Remélem, hogy tévedek.

Elvileg ha ez élesbe menne majd egyszer, lenne HP-s iLo-t támogató 2 szerver.
Azon nem gondolkoztam még, ha iLo lenne, amit kicsit ismerek és teszteltem helyi hálózaton HTTPS-en, hogy miként érném el a szerver teremből az iLo-kat. Nyilván nem úgy, hogy azoknak is lenne véve 1-1 publikus IP. Erre mi a standard megoldás? OpenVPN, majd az iLo azon belül? A szerver hosting cég ad +1 +1 csatlakozást a switch-be az iLo-nak?
De ha elromlik az OpenVPN mind a 4 gépen, akkor nem tudom az iLo-t sem elérni. Bár erre kicsi az esély elvileg.

Sakk-matt,
KaTT :)

> Mit csinál, hogy a zombi gép eldobja az IP-t?
Ezt. :) Hardveres reset-et kér, amihez nem kell az oprendszer. Tapasztalat, hogy kell a STONITH.

Az iLo IP címe lehetne ugyanabból a privát tartományból, amit a szerverek használnak, igen. A hostingcég pedig adjon linket az iLo-nak. Ha elromlik a 4 VPN, még mindig be tudsz menni egy $RANDOM szerverre a publikus IP címen és azon megjavítani. Nem muszáj letiltani a publikus címen az SSH-t, csak ne azt használd.

> A hosting cég hogy tud adni linket az iLo-nak, ha az privát tartományban van?
Eh, fejlesztők..! :)

Adjon linket = dugjon bele kábelt. Ugyanúgy fog rajta működni a privát IP cím mint a szervereken, gondolom azt se a szolgáltató rendelte ki neked, csak egyszerűen felhúztad a gépekre. A hosting switch-e (jellemzően) layer 2 (ld. OSI model), hogy a gépek milyen IP címen kommunikálnak rajta egymással, azzal nem törődik.

"Eh, fejlesztők..! :)"
Thanks GOD, _real_ system administrators! :) I wannabe sysadmin! ;)

Én úgy értettem, ha valami ok miatt mind a 4 szerverrel történne valami, akkor hogy érem el az iLo-t? Mert VPN-nel nem tudok belépni egyikre sem ugye, hogy onnan privát IP-n elérjem. Ha lenne publikus IP, akkor nyilván elérném, de az nem lesz. Mit tesz a szolgáltató, vagy mi a megoldás erre? Ha bemegyek a hosting terembe dugnak konzolt a szerverre, vagy elérhetem IP-n az iLo-t. De ha nem megyek be, és el akarom érni a privát IP-n lévő iLo-t, mi lesz?

Értem én, hogy gőzgép, de mi hajtja? (hiányzó lánc(szemek)...)

Sakk-matt,
KaTT :)