Ono se to da udelat i na tucnakovi, ovsem script by sis na to musel napsat sam a rozhodne by to nebylo online.
Printable View
Ono se to da udelat i na tucnakovi, ovsem script by sis na to musel napsat sam a rozhodne by to nebylo online.
jak tak koukam, ono staci se podivat do gugelu ... :) http://conntrack-tools.netfilter.org/manual.html takze to jde i s tucnakem a asi i online ...
Pokud mozno to chci resit bez jakekoli nutnosti konfigurace na stanicich, protoze jednak jich je cca 70-80, jednak se do site pripojuji i nejake NTB, iphony a podobne, takze reseni pomoci VRRP pokud bude fungovat je asi idelani.
Jasne ze switche jsou SPoF, ale vymenit switch je precijenom jednoduzsi nez prehodit modemy ci router, protoze tam se daji poplest kabely, kdezto switch dokaze vymenit teoreticky i cvicena opice / uklizecka. A samozrejme pro kriticke stroje tu je stale moznost pouziti dvou switchu.
Rozpadnuti otevrenych spojeni pri vypadku jednoho routeru neni velky problem, protoze to jednak nebude casto (doufam), jednak nase crawleri si je bez problemu obnovi. Stejne tak verejnou adresu asi nepotrebujeme, respektive bude stacit kdyz budou dve, na kazdem routeru jedna.
S poslednim odstavcem nesouhlasim, protoze pokud toto mnou navhrhovane reseni bude fungovat tak jak zamyslim, je to porad lepsi, nez mit pri vypadku jednoho oruteru (umrela CF, umrely FS, umrely zdroj....) polovinu stroju bez netu. Navic hlavni funkce bude load ballancing, ktery by snad mel fungovat dobre. Samozrejme pocitam s tim, ze to nebude dokonale a nektere veci proste vyresit uspokojive treba nepujde, ale takovy je zivot :)
Samo, zavisi co od toho chces, posledni odstavec se tykal predevsimcoz pomoci tohoto neudelas.Citace:
bez single point of failure
Pokud ti staci ze se nejak sama prepne konektivita, tak je to celkem snadny. Pokud to chces tedy nejak nahrubo balancovat, tak bych dal kazdymu routeru jednu vnitrni IP a default routu rozdelil mezi ty stroje co chces +- balancovat. Pri vypadku jedno z nich by si pak ten druhy pridal IP mrtvoly jako sekundarni. Nevim jak rychle swiste zareagujou, ale moc dlouho to trvat nebude.
Spojeni se samo rozpadnou, ale pokud ti to neva, tak neni co resit.
BTW: Co FUP ? Nebylo by vhodnejsi poridit nejakou profi konektivitu na jiny technologii/umistit zelezo nekam kde konektivita je ?
Jinak prepichat router zvladne uklizecka taky, otestovano :D, jen musi byt stejny. To ze ma ty kably napichat do stejnych der pochopila.
Nyni to tu je tak, ze mame 4 routery a jejich vnistrni IP se nejak prideluji vnistrnim strojum. Problem je ze to moc nefunguje, casto jsou dve lajny zcela vytizeny, kdezto dalsi 3 se flakaj, protoze zatez tech stroju je v case ruzna a hlavne to pseudo-nahodne pridelovani IP lidmy v realu moc nefunguje. Navic ty routery stale tuhnou a pod, takze takhle to tu vazne nejde. Jedna se o firmu v mensim nemeckem mestecku a jine pripojeni nez ADSL tu proste neni, nebo neni financne dostupne. A platit umisteni 60ti stroju nekde na pateri, ke kterym navic casto fyzicky potrebujeme, je rovnez nevyhodne. Pravda je, ze to s tema switchema a hlavne s ARP zaznamama me nedoslo, kouknu zda VRRP neumi prehazovat i MAC adresy, to by se vyrazne zrychlylo.
Barevné kabely (žlutý, zelený, modrý, červený, černý, šedý) a na obou routrech (funkčním i záložním) barevné polepky u konektorů a výměnu pak zvládne i uklízečka... ;)
Potiz u DSL budes stejne mit v tom, ze parametry linky se ti menej v case => to co normalne linka da vpohode muze jindy znamenat jeji pretizeni. Zalezi taky na tom, co chces balancovat, jestli traffic nebo konexe. Ale tak jako tak, pokud se ti to meni v case nejak vic nez malo ;), tak se nevyhnes aktivnim zmenam konfigurace na tech serverech. Druha alternativa je pak jedina, mit vsechny linky privedeny do jednoho routeru a druhy mit jen jako pasivni backup.
Jasne ze ADSL vazne neni fiber, na tom se shodneme, ale nic lepsiho tu proste nemame a mit nebudeme a zadny QoS se na tom stejne delat neda, kdyz tam neni fronta (a hlavne kdyz ty data prijimam), takze ten round-robin load ballancing je asi tak to nejlepsi, co na tom jde udelat a samozrejme se budu snazit tech ADSL mit co nejvice, aby byly vytizene treba jen na 60%...to by pak uz mohlo precijen trochu fungovat. Jen jsem zvedav, jak to bude vsechno fungovat, kdyz na tom PPPoE samozrejme musi byt DHCP klient. Doufam ze MK je inteligentni a ze kdyz nahodim 4 PPPoE, ze je bude vsechny pouzivat stejne jako kdybych mel rucne nastavene 4 default gw. Zatim diky moc za postrehy, zkusim to implementovat a pak poreferuji.
Vidim tam staticky nastavenou default routu, coz ja mit nechci a coz je mozna chyba. Mas v nastaveni PPPoE povolenu use default route? Ja nechci mit zadnou routu staticky a u vsechn PPPoE chci mit pouzit default routu, takze ocekavam ze se jich tam objevi tolik kolik je aktivnich PPPoE. Jen nevim jake DNS vylosuje ;)
UPDATE: par postrehu.
1) VRRP skutecne umi virtualni MAC adresu, kterou ma vzdy master router (doufam), takze vypadek by mel byt minimalni: http://wiki.mikrotik.com/wiki/VRRP
2) PCC firewall matcher ma jako match dokonce i cilovou IP, coz je v mem pridpad lepsi nez zdrojova IP, protoze to umozni pripojeni na ruzne servery z jednoho stroje hnat ruznymi DSL ale zaroven se nestane ze by z jednoho kompu slo vice konexi na jeden cilovy stroj ruznymi DSL. Pokud to bude fungovat, tak to nema chybu :)
Tak jsem dnes zkusebne zapojil dve DSL lajny do jednoho mikrotiku, nahodil PCC a neveril jsem ze se to fakt rozjelo :) delim je v pomeru 2:1 (11Mb a 6Mb) a funguje to naprosto bajecne, vytizeni site skutecne prumerne odpovida pomeru 2:1 a to jak download, tak upload. Je to dane tim, ze tam jsou tisice spojeni a vsechny delaj relativne o same, kdyby to pouzivali zivi lide, nebylo by to asi tak idealni. VRRP jsem zkousel uz predtim, doba prepnuti je cca 1-2s (odpojil jsem kabel z master routeru), ping nevypadl ani jeden, cemuz se mi ani nechce verit. Takze zitra zkusim rozjet VRRP nazivo a do druheho routeru take napicham dalsi dve lajny a zkusim load ballance mezy vsechny 4 lajny. Mimochodem to ze to funguje i na PPPoE clientovi s dynamickou IP je diky tomu, ze mikrotik umoznuje definovat routovaci pravidlo jen pomoci interfejsu, zadnou pevnou gw nepotrebuje. Jestli to umi i normalni linux netusim, ale rozhodne to neni otazka par kliku jako v mikrotiku. Genialni :)
Tak jsem to nakonec vazne zprovoznil :) az v prubehu se ukazalo, ze tak jednoduche, jak to vypadalo,to vazne nebude, protoze policy routing prinasi urcite problemy, ktere je potreba osetrit. Dalsi neprijemnost je podivna implementace/vlastnost VRRP v mikrotiku (mozna to je standard), kdy je vyzadovana IP adresa ze stejneho rozsahu, jako ma VRRP interfejs, rovnez na materske sitovce. To zpusobuje problemy u slave routeru, bez obrazku to ale vysvetlit asi nepujde, takze ctenarum doporucuji pockat na vecer, kdy snad dodam nejaky obrazek s porobnou dokumentaci. Pokracovani tedy jindy, kazdopadne vysledek predcil vsecha ocekavani a funguje to bajecne:
1) muze spadnout jakykoli z obou routeru a internet bude fungovat i bez nej, doba vypadku je cca 1-2s (vyzkouseno)
2) dokud bude funkcni alespon jedna DSL lajna na alespon jednom funkcnim routeru, internet rovnez jede
3) zatez je rozdelovana mezi vsechny dostupne DSL lajny (overuje se pingem na branu) s tim, ze pro kazdy par zdrojove a cilove IP adresy se brana nemeni (do restartu routeru), takze navazana spojeni nepadaji a nejsou problemy zpusobene menici se verejnou IP
4) to vse bez potreby statickych IP adres od providera ci jinych nestandardnich sluzeb
UPDATE: takze pro zajemce nabizim k nastudovani nalsedujici odkazy (to je novinkaz ze): http://wiki.mikrotik.com/wiki/PCC a k tomu toto: http://wiki.mikrotik.com/wiki/VRRP
jak to vlastne u nas vypada u "ISP" to neni mozne pouzit BGP?
ptam se protoze s temihle low-level zarizenimi nemam zkusenost, tak se divim proc to neni reseno standartni cestou pres dynamicky protokol.
dekuji
jo a pochopil jsem dobre ze to je jen pro odchozi traffic, protoze v pripade weboveho serveru by to byl ponekud asymetricky routing a dost zbytecna divocina s DNS....
a fw tam neni? tomu by se to uz vubec nelibilo :D
Predevsim BGP (pripadne alternativy) by mozna prichazelo do uvahy pokud by slo o dve linky jedinyho ISP. Vzhledem k rozsahu IPcek ktery normalne doma mas (tedy 00 nic) ti nikdo nebute takovy pidiprefix propagovat :/.
Samo, resenim by bylo vice propojovacich bodu blize zakaznikum, pak by se daly i pidiprefixy propagovat v ramci te omezene lokality.
Priznam se ze vubec netusim, jak by slo BGP v teto situaci pouzit, ale to bude patrne tim, ze o BGP temer nic nevim :) predpokladam ale, ze s dynamickymi adresami by to bylo minimalne ponekud problematicke az nemozne ;) FW, pokud tim byl mysleny firewall, tam samozrejme je (stavovy).
Samozrejme, ze toto reseni se tyka uz z principu pouze odchozich spojeni, coz ale v nasem pripade neni na zavadu, protoze mame pomerne velky pocet spojeni a vsechny maji +- stejny download, takze jen pro predstavu realna data jsou takova, ze prichozi objem dat merenych mikrotikem na jednotlivych interfacech se lisi v radu procent, coz ja osobne povazuji za dost neuveritelne vyborny vysledek. Stejne tak pri vypadku nejake DSL lajny ( = shozeni PPPoE) se spojeni prislusejici teto brane okamzite zacnu routovat jiou dostupnou branou, po nahozeni PPPoE se vse vrati do puvodniho stavu. Navazana spojeni jsou samozrejme ukoncena, ale to nema bohuzel zadne reseni. Velka vyhoda je, ze nejsme zavisli na jednom providerovi a nejvetsi vyhoda je samozrejme cena celeho reseni. To doplnuje velmi snadna obnova konfigurace mikrotiku ze zalohy nastaveni, je to operace na 4 kliknuti kterou zvladne i naprosty diletant, coz by napriklad u nejakeho beznejsiho linuxu nehrozilo. Navic si nejsem uplne jisty, ze neco jako PCC v linuxu vubec je, obavam se ze to featura doprogramovana mikrotik teamem.
Takze, pokusim se nyni o jakysi navod pro pripad, ze by to nekoho zajimalo:
Predem upozornuji ze policy routing neni uplne trivialni vec a doporucuji si o nem nejdrive neco precist.
Prvni krok je zpovozneni HA clusteru na bazi VRRP. S pomoci tohoto navodu to je pomerne snadne: http://wiki.mikrotik.com/wiki/VRRP-examples
Jediny zadrhel je v tom, ze aby to fungovalo, to znamena aby virtualni VRRP interface (IF) nebyl faulty, musi mit matersky IF platnou nejakou IP adresu. Ted nevim jiste zda nemusi byt ze stejneho rozsahu, jaky ma VRRP IF.
VRRP tedy priradime napr. 192.168.0.1/24 na obou roterech a ti to hasne. Primarnimu budu rikat master, druhemu slave. dost zasadni je mit preemtion yes.
Ted je potreba zprovoznit vlastni PCC load ballancing. Predpokladam, ze oba routery jiz maji aktivni DSL lajny pomoci PPPoE, DSL modemy jsou tedy v rezimu bridge. na PPPoE muzeme zapnout obe dostupne komprese a v NAT nastavit maskaradu. routery jsou mezi sebou propojene dedikovanym spojem (DS) pro routing z mastera na slejva. Pouzil jsem tento mirne upraveny navod: http://wiki.mikrotik.com/wiki/PCC
Jeden z rozdilu je v tom, ze jsem vubec neresil prichozi spojeni, stejne jako output, ale to by nicemu uskodit nemelo. Dalsi, pomerne zasadni rozdil, je v tom, ze pri nastaveni jednotlivych zaznamu v routing table musime pouzit PPPoE IF namisto vychozi brany, protoze ta je dynamicka. Velmi doporucuji check gateway s pingem. V nastaveni PCC jsem pouzil both-addresses, coz je nastaveni, ktere zaruci, ze spojeni z jednoho pocitace na nejakou IP adresu v internetu pujde vzdy stejnou branou (pokud je up).
Nastaveni policy routingu se lisi pro master a pro slave, protoze master rozdeluje spojeni mezi DSL vlastni a DSL bezici na slejvu, kdezto slave jen mezi vlastni. Na masteru tedy budeme rozdelovat spojeni na N+1 casti, kde N je pocet DSL na masteru, ono +1 se bude routovat na slejva. V mem pripade mam na obou strojich jednu 12Mb lajnu a jednu 6Mb, rozdeluji tedy v pomeru 2:1:3 (12,6,slave) na masteru a 2:1 na slejvovi. Celkem tedy mam na masteru 6 zaznamu v mangle table markujci spojeni s pomoci PCC. (mozna by slo rovnou prirazovat routing mark???) In IF je VRRP.
Na slavu je situace jina v tom, ze v slave rezimu prichazi spojeni z dedikovaneho portu (od mastera), po vypadku hlavniho masteru se slave prepne ma docasneho mastera a spojeni zacnou prichazet z VRRP. Udelal jsem tedy dve sady shodnych PCC mangle zaznamu, jedenu s IN IF VRRP, druhou s IN IF dedikovaneho spoje (DS). A tady prichazi dalsi zadrhel a to je routa do nasi LAN, ve ktere mame nase kompy :) ve slave rezimu musi routa do LAN mirit na mastera skrz DS, po prepnuti na docasneho mastra musi mirit na VRRP. Pouzil jsem tedy moznost VRRP pri zmene stavu spustit skript, kde tuto routu nahazuju a shazuju.
Vysledek tedy je, ze master posila cast spojeni z LAN na vlastni DSL lajny a zbytek preposila na slejva, ktery tyto spojeni opet pomoci PCC rozdeluje mezi sve DSL. Na masteru je u zaznamu v routovaci tabulce pro preposilani na slejva opet pouziva funkce check gateway, takze pokud slave vypadne, master na nej prestane preposilat. Jediny problem, ktery muze nastat, je kdyz vypadnou vsechny DSL lajny na slejvovi, v takovem pripade na nej bude master stale preposilat spojeni a chudak slejv je nebude mit kam routovat (napada nekoho nejake jednoduche reseni?) Po vypadku masteru si slave nastavi na svem VRRP IF IP adresu (sy) co mel master, shodi routu na mastera a zacne vyrizovat prichozi spojeni pomoci svych DSL lajn. Vypadek cini priblizne 1-2s.
Po necelem tydnu musim prohlasit, ze to funguje bajecne a nejlepsi na tom je, ze to nema zadny single point of failure, kdyz nepocitam switch v LANce, bez ktereho to proste bohuzel nejak jednouse nejde :)
pouzity router je RB450G: http://www.roc-noc.com/images/P/rb150-complete_l-01.jpg
UPDATE: jeste dodam, ze VRRP si udela vlastni MAC a tu pak pouziva na vsech strojich, takze vypadek je skutecne pouze 2s, tedy nez si switche vymazou jeji zaznam z tabulky.