Fórumok
Hello!
Van 2 debian szerverunk, publikus IP cimen. Node A es Node B. A ket szerver nek van 1 darab Floating IP je, ami szinten a publikus neten figyel.
KB 10 darab /30 as kis haloztatot szeretnenk a szerverekkel szurni. Mindegyikben lenne 1 szerver, es 1 db Gateway.
Van arra mod, hogy Floating IP-t hasznaljunk a 2 node kozott es beleferjunk a /30 as subnetbe? Valahogy csak a floating IP interface-et huzzuk fel a 2 node kozott, es ne legyen kulon cim node-onkent abban a subnetben ahol a szerver van?
Lehet picit bonyolult a kerdes, de remelem valaki erteni fogja :)
Koszi!
Hozzászólások
egy interfészre fel tudsz venni több ip címet is. teszem azt,
node A: eth0 -> 10.0.1.2/30, 10.10.0.1/24
node B: eth0 -> 10.10.0.2/24
ahol 10.0.1.0/30 az mini subnet, 10.10.0.0/24 egy másik subnet mondjuk adminisztratív célokra, és a 10.0.1.2 a floating IP ebben a subnetben.
erre gondolsz?
Igen nagyjabol erre.
csak az a furcsasag, hogy a /30 as subnetben nem tudok meg 2 cimet felvenni a 2 node nak. Csak a floating van. Ez igy mukodhet? Hogy fogom felhuzni azt a floating cimet a 10.0.1.2/30 ba ha nincs benne csak 2 hasznalhato, es az HA-ban hogy fog “vandorolni” az eppen aktiv node-ra, NodeA es NodeB kozott?
kell egyáltalán az a 2 fix cím ugyanabból a /30-as subnetből? nem lehet másikból?
es miert nem hirdeted mondjuk ospf-el a ket /30 link folott a single /32-t ?
aztan hogy melyiken van azt meg eldonti egy vrrp/barmi
Lehet hogy én nem vagyok képben, de a floating ip önmagában nem mond semmit azon felül, hogy egy megadott ip cím a node-ok között vándorolhat és azok gondoskodnak arról, hogy az arp announcing megfelelően végigmenjen a hálózaton ha váltás van.
Az alapján amit mondtál, te CARP-ot használsz (de lehet még ez is téves következtetés). Lehet egyszerűbb ha onnan indulunk, mi a jelenlegi beállítás :)
// Happy debugging, suckers
#define true (rand() > 10)
Jelenleg nincs semmi meg.
A floating IP hez 3 cim kell:
1.) NodeA
2.) NodeB
3.) Floating IP
a /30 al viszont csak 2 cim hasznalhato. Az egyiet szeretnenk a floating IP re a masiknak pedig egy Host ot, amin mondjuk web szerver futna. Vagy ftp, vagy mind1 mi.
a Floating Ip-t szeretnenk hasznalni gateway kent, hogy redundansan legyen megoldva a /30 as subnet.
Nagyjabol ez lenne.
Ahogy fentebb leírták, neked CARP-ra van szükséged!
Mivel OS-t nem írtál, nézd meg hogy adott OS-nál ez hogyan van implementálva.
WAN, és LAN oldalakon is fel kell húznod egy CARP interface-t, erre fogod a "floating IP"-ket konfigurálni.
Ha ügyesebben akarod megoldani, és adott OS tudja, akkor WAN oldalon a forgalmat szinkronizálod (states), erre kell egy dedikált interface a két gép közé. Ebben az esetben master node kiesése esetén minden kapcsolat szakadás nélkül átvándorol backup node-ra.
Amiket még ilyenkor érdemes megoldani:
- DHCP szinkronizálása (ha van)
- VPN szinkronizálása (ha van)
- valamilyen daemon ami CARP-on felül figyeli master->backup váltást, szükség esetén bizonyos szolgáltatásokat backup elindítt, majd leállít.
Vannak OS-ok amik a fentieket csuklóból tudják, pl. OpenBSD (carp, pfsync, sasync, ifstated, dhcpd, ....)
Ami még fontos, WAN és LAN oldalon se legyenek szűrve mulicast csomagok! (WAN oldalon előfordul hogy szolgáltató szűri)
Irtam, hogy 2 debian van tervben.
De meg mindig nem ertem, hogy akkor csak egy interface-t huzok fel mind a 2 gepen a CRAP-nak. pl eth0:1 es valojaban eth0 meg csak ures es ott "csucsul"
A ket gepet meg ossze tudjuk kotni egy kabellel is hogy a szinkronizalas meglegyen egy dedikalt interface-en.
Pl egy bond esetén pont az van hogy az 'eth0 meg csak ures es ott "csucsul"', nincs itt semmi látnivaló...
Ezt a peldat neztem:
https://debian-administration.org/article/678/Virtual_IP_addresses_with…
Ezek szerint a CARP interface-nek meg mindig kell egy fizikai interface, amire IP-t kell felhuzni. es pont ez a gond... hogy a /30 as subnetben nem tudunk majd kiosztani 2 ipt a ket node nak, 1 et a CARP nak es 1 et meg a HOST nak ami abban a subnetben van.
Vagy meg lehet ugy is oldani a configot, hogy eth0-ra nem huzok fel ipt-, csak be van kotve, es csak a CARP nak van egy IP-je ami vandorol?
iface eth0 inet manual
Mint fentebb írtam, nézd meg a keepalived csomagot, ami egy VRRP megvalósítás. Nem kell dedikált IP cím.
CARP, VRRP, … és társaik egy virtuális interface-t hoznak létre, az minden egyes member-en fent van. (akár 2-nél több member is lehet!).
Súlyozással határozod meg hogy melyik a master, melyik a slave/backup interface.
A virtuális interface-ek fizikai interface-re „bind”-elnek, de ettől még a fizikai interface-en is lehet pl. dedikált IP cím.
A carp member-ek egymás között multicast csomagokkal kommunikálnak, minden CARP-nak van egy ID-je, és normális esetben egy jelszava. Itt beszélik meg hogy látják-e egymást, ha valamiért szétszakadnak, akkor backup gépen, master állapotra fog váltani a CAPR interface.
Tehát innentől ott van az IP címed, ha van a két gép között csomag állapot szinkronizáció, akkor a meglévő kapcsolataid sem szakadnak!
Nagyon sok jó leírás, videó, etc … van erről neten.
Keress rá, hozz létre valamilyen virtuális környezetben egy teszt rendszert és próbáld ki.
Egyszerű mint a faék!
Amire figyelni kell!
Ha egy CARP interface állapota változik, akkor azon a gépen lévő többi CARP-nak is illik vele mennie.
Tehát ha pl. WAN oldali CARP master A gépről átkerül B gépre, akkor a LAN oldali CARP interface(ek)-nek is utána kell mennie!
keepalived (vrrp)
Ez valami nagyon zöld, védjük az IP-ket mozgalom? Legyél bátor és pazarló, szerencsére a belső IP-k újra felhasználhatók ;)
Ha ez hálózatos vizsgafeladat, akkor szép kérdés, le a kalappal. Ha nem, akkor egyszerűbb elkerülni a problémát.
1. /29
2. Ha mindenképpen /30, akkor vidd alsóbb szintre a belépő pont redundanciáját - egy db virtuális gép, ami tud sétálni az 1db IP-jével együtt
Nem vizsga feladat. :)))
A reszletekbe ne menunj bele hogy miert ez lett "megszavazva" es miert ebbe az iranyban kell menni.
a /30 as virtualis gep jo otlet lenne, de ha frissiteni kell, vagy barmi update van akkor az leallas. Ezert van 2 gep.
Troll on
Vannak helyek ahol előbb körbejárnak egy problémát, letesztelik, alternatívákat keresnek, azt is letesztelik majd szavaznak...
Aztán ha kiderül, hogy van egyszerűbb megoldás akkor újraterveznek :)
Ha spórolni akarsz a publikus ip címmel, nem kell publikus ip címmel megoldani a routolást, GW címe lehet bármi akár privát ip cím is, a kliens pedig használhat egyetlen /32-es publikus IP címet, ugyan ehhez manuálisan kell beállítanod a routingot a kliens gépen, pl linuxon:
auto eth0
iface eth0 inet static
address 87.229.115.255
netmask 255.255.255.255
up ip ro add 172.16.0.1 dev eth0
up ip ro add default via 172.16.0.1
Ugyan nem mostanában csináltam ilyet, pár évvel ezelőtt egy korábbi melóhelyen kellett, de akkor működött a linuxokon, freebsd-n, és windowson is (utóbbin nem kellett semmi extra mágia, csak beállítani a GW-t). A hátránya ennek a megoldásnak, hogy tudtommal nem lehet pl DHCP-n kiadni az IP címeket a statikus routing szabályok miatt, viszont ha külön privát IP címeket használsz mindenhova, akkor később egyszerűbb lesz skálázni, ugyanis könnyű lesz ezt a float IP-t átrakni más GW-re.
vps4you.hu kupon VPS szolgáltatásra: HUP2023
Hat valahogy ez nem akar mukodni.
Ahogy latom az a problema, hogy ens224-nek nincs dedikat ip cime, ami mell felhuzna keepalived a virtualis cimet, es pont ez a problema, hogy nem szeretnenk minden subneten 2 cimet a 2 node-nak, es 1 et keepalived nek, es meg a kliensnek, es meg a networknek is...
Soval meg lehet ezt oldani ugy is, hogy csak a keepalived cime figyel aktivan ens224-en mind a ket node-on ?
Node1:
etc/network/interfaces
/etc/keepalived/keepalived.conf
Node2:
etc/network/interfaces
/etc/keepalived/keepalived.conf
service keepalived status
Húzz fel két IP címet rá privát vagy CGNAT tartományból (100.64.0.0/10) és kész! VRRP IPv4-en IP multicast-ot használ.
Es ha Vlan-t is kellene felhuzni az interface-re ?
Meg Iptables-ben jo lenne egy picit szabalyozni?...
Meg tudom, el kene mennem is valahova jo messzire :DD
VLAN nem okoz problémát, ott alinterfészeket használsz és kész (eth0.100 stb..). Egyébként még multicast támogatás sem szükséges, mert Keepalived támogatja az unicast kommunikációt is, csak be kell konfigurálni. A VRRP által használt adminisztratív IP címek között pedig titkosíthatod a forgalmat például IPSec-el (transport mode) és mást nem fogadsz el.
KOSZONOM!
Ezzel a sorral sikerult megoldani! Nem kell a Keepalived-vel sem az UCARP-el taknyolnom.
Siman full egyszeruen csak felhuzom Heartbeat-nek a haresources-ben az ip-t amit hasznalni szeretnek, es fizikainak meg megadom a CGNAT-ot.
Full egyszeru az IPTABLES szabalyokat csinalni rajuk, es tokkeletesen mukodik!
KOSZI MEG 1x! :D