Názory k článku Velká řešení otevřeně: spolehlivá a škálovatelná síť
-
Petr M (neregistrovaný)
1) Tak jsem musel chvíli přemýšlet, než jsem pochopil, že je to druhý díl toho seriálu, kdy se řeší všechno a nic... Nakonec OK, identifikováno podle zmatku.
2) Zmíněno několik možností konfigurace, jedna zvolena, ale PROČ? Jaký jsou výhody nebo nevýhody ostatních řešení? Je nějaký odkaz na ostatní řešení?
3) Má to "hospodský závěr". Když to nakonec začne být zajímavý, pán bez jakékoliv pointy škytne a padne znaven pod stůl. -
1) Ano, je to stale tataz slatanina, jak je videt ze stejneho retezce pred dvojteckou v nazvu a jmena autora
2) Vyhody a nevyhody ostatnich reseni nejsou zrejme zmineny proto, ze se nejedna o clanek, ktery by mel za cil jejich rozdily probirat. systemd je zvoleno kvuli tomu, ze v soucasnem debianu je snaha o prosazovani systemd jako default vec na vsechno; odkaz na ostatni reseni samozrejme je: man ip; man ifconfig; man systemd.network, ...
3) Pan padl znaven doporucenou maximalni delkou textu na jeden dil -
MasoxCZ (neregistrovaný)
Tak bod 2) by mi vadil ze všeho nejmíň, protože to jediné v celém článku je relativně racionální future-proof volba: systemd sice ještě prochází vývojem, ale usilovně se na něm maká, ergo je předpoklad že s postupem času převládne a bude fungovat dobře.
Z toho ostatního we ovšem i mě kroutí nehty do kornoutů. -
Filip JirsákStříbrný podporovatelifconfigfunguje na ostatních Unixech mimo Linuxu – pokud není seriál věnován jen Linuxu, je jeho uvedení v článku správné. Na Linuxu aleifconfignefunguje už skoro dvě desetiletí. „Používat ifconfig na featury, které umí“, je v Linuxu nesmysl, protožeifconfigneumí v Linuxu správně nic – neumí ani správně zobrazit aktuální nastavení síťových rozhraní. Kdybyste chtěl v Linuxu používatifconfigpoužívat pro to, co umí, musel byste si vždy nejprve přesipzkontrolovat, že systém je ve stavu, kterýifconfig„umí“ – a to už je rovnou lepší použítipke všemu, nemyslíte? Navíc byste musel přesně znát všechna omezeníifconfig, to mi také připadá zbytečné. -
Filip JirsákStříbrný podporovatel
Jaký „pseudobug“ myslíte? To, že je
ifconfigod linuxového jádra verze 2.2 zastaralý a nemá se na Linuxu používat, není bug, to je vlastnost. Prostě jádro tenkrát přišlo s takovými změnami v síťové vrstvě, se kterými neníifconfigkompatibilní. -
samalama (neregistrovaný)
# ip a show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 74:d4:35:0b:18:06 brd ff:ff:ff:ff:ff:ff inet 10.0.0.3/24 brd 10.0.0.255 scope global eth0 valid_lft forever preferred_lft forever inet 192.168.123.3/24 scope global eth0 valid_lft forever preferred_lft forever# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 74:d4:35:0b:18:06 inet addr:10.0.0.3 Bcast:10.0.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:26780924 errors:0 dropped:163 overruns:0 frame:0 TX packets:14459079 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:25594412615 (23.8 GiB) TX bytes:1871716916 (1.7 GiB) -
j (neregistrovaný)
ifconfig uz celou radku let v linuxu vubec neni, a to co tam je je emulace jeho chovani za pomoci ip. Ta emulace pak umi par zakladnich veci a na obyceny nastaveni IPcka prevazne staci, ale v okamziku, kdy se zacne resit vic IPcek, vlany, ... tak velmi rychle narazis na to, ze to nefunguje jak by melo. Respektive, nefunguje to tak, jak je popisovano v milionech vsemoznych navodu, ktery pocitaj prave s tim puvodnim, uz nepodporovanym chovanim.
Treba pokud mi skleroza slouzi, tak puvodni ifconfig neumel pridat iface vic IPcek, a bylo treba kvuli tomu vytvaret dalsi virtualni iface. Coz jako "spravnej" postup jeste stale bezne na netu najdes.
Dtto trebas vlany, ktery ifconfig nikdy neumel, a byl na to treba dalsi tool, ip to samozrejme bez potizi nastavi.
-
Crow (neregistrovaný)
Nekritizuju,jenom se ptám:
Ad DNS - skutečně DNS server v takovém nastavení posílá v odpovědi více A záznamů? Vždy jsem měl za to, že se dělá round-robin přes záznamy na serveru.
Ad bridge - Proč je ip na bridge a ne na fyzickém rozhraní.
Ad keepalived - Proč dělat failover na rozhraní fyzického stroje (nebo to je bridge?) a ne na rozhraních virtuálních strojů, které jak jsem pochopil budou běžet na obou serverech?
Trocha kritiky:
- Chce to diagram infrastruktury (klidně v malování)
- Uvítal bych odůvodnění, proč zrovna takové řešení. Manažery skutečně nic jiného nezajímá ;-)
- Asi bych to nazval "Poor mans cloud/HA". Tohle je věc co vyzkouším i na RPi :-D -
1) DNS -- minimalne bind9 to v default nastaveni dela, posila vice zaznamu a jejich poradi je cyklicke (round-robin)
2) IP na br -- matne saham do pameti. Mam pocit, ze mne kdysi zlobil nefungujici bridge bez sitove konfigurace, zvykl jsem si tedy konfigurovat bridge a chovat se k nemu jako ke klasickemu rozhrani.. on v tomto pripade ten bridge vlastne ani neni potreba
3) keepalived -- snad jsem se neprepsal, opravdu se dela failover na urovni bridge; jinak na obou strojich bude bezet vicero virtualnich, ale ty prave v pristim dile odstinime tim, ze tam vrzneme HAProxy, ktera bude poslouchat prave na tomto rozhraniKe kritice:
* Diagram struktury bude asi priste, ted jsem tam jeste nevidel nic moc zajimaveho (dva servery ve spolecnem switchi)
* Duvod: asi hlavne ten, ze je to na open-source technologiich (nehrozi tedy vendor lock-in a neplati se silene castky za licence a support, co se nevyuzije); jinak je to proste jen jedna z mnoha cest, zkusim se zamyslet nad nejakym zaverecnym (manazerskym) shrnutim, proc zrovna tudy ano
* Ano! Presne z takhle pojmenovane prednasky to puvodne vzniklo a mrzi mne, ze jsem si na to nevzpomnel driv. -
Ad IP na bridge, to tak skutecne musi byt a pokud to mate jinak, tak vam to funguje jen cirou nahodou. Bridge je totiz v takovem setupu jedina, kdo vi kam ma posilat ARP odpovedi, typicky kdyz IP budete mit na eth0, tak bude IP videt jen zvenku, ale neuvidi ji virtualni stroje. Uz jsem par virtualizaci presne s timhle problemem opravoval.
-
M. (neregistrovaný)
Pokud je IP adresa, tak musí být na bridge a ne fyzickém interface, jinak blbne ARP jak popsal Dan. Mohu mít bridge bez IP adresy, pokud se má jen bridgovat mezi ethernet a virtuály, akorát je otázka, jak se s tím v různých distribucích vyrovnají startovací network scripty (třeba starším RHEL to dělalo problémy, od RHEL/CentOS6 už je to OK).
Jinak bych očekával, že když stavím dva severy pro zálohu, že tam budu mít i dva Ethernet switche, kdyby jeden chcípl, a tak nad dvěma ethX bude bond (nebo nověji team) a teprve ten půjde do bridge do kterého se pak napojují virtuály. :-) -
john (neregistrovaný)
Ako cloud mi to nepripada. Failover na urovni IP je nieco, co sa podla mna sa vylucuje s cloudom. Cloud by mal byt nadizajnovany principom Design For Failure. Tu sa vsak budeme snazit zachranovat nieco pokazene migraciou VM/IP. Nie, v cloude jednoducho prestane problemova VM servovat traffic, bude killnuta a bude vytvorena nova. Nikto za nou nebude plakat, pretoze nie je pet, ale je cattle. Prevadzky sa to tiez nedotkne pretoze traffic prejde transparentne (load balancing) na iny dobytok (cattle), ktory ho spracuje.
Takze za mna nazov "Poor mans HA infrastructure" ;-)
-
Ale tady zatim jeste nejsme na urovni jednotlivych VM, kde se vypadek proste nemusi resit, protoze traffic bude obsluhovat nejaka dalsi instance. Resime vypadek celeho hypervisoru a chceme, aby traffic mireny na tento konkretni hypervisor presel na jiny. (A nechceme si na to kupovat zadnou cernou krabicku typu F5 Load Balancer.)
-
Je treba pochvalit, ze clanek je napsany tak, ze by podle nej zakladni load balancing rozchodil i linuxovy neznalek.
Chci se zeptat jak funguje to posledni reseni v pripade prepnuti. Rekneme, ze srv1 je nedostupny a vsechna spojeni tecou na srv2. Jakmile srv1 najede, tak jsou spojeni (urcene pro jeho VIP) presmerovany ze srv2 na srv1. Zvladne srv1 obslouzit jiz navazana spojeni (drive komunikovana se srv2), nebo je nutne, aby klient navazal tato spojeni znovu?
-
A mohl byste navrhnout vhodnejsi reseni? Prijde mi, ze delat pomoci DNS load-balancing jen a pouze samotnych load-balanceru (ktere pak jiz podle aktualni zateze smeruji traffic na samostatne aplikacni servery) je koser reseni, i kdyz ano, je potreba nejak ohlidat, ze soucet provozu na obou uzlech neni vetsi nez je kapacita libovolneho z nich.
-
lojzak (neregistrovaný)
@bez přezdívky
Load balancing má dělat (ne zcela překvapivě) load balancer, nikoli DNS server.
DNS server nemá žádné informace o vytížení serverů, na které by se měla zátěž rozkládat, nesleduje zda fungují či ne a nerespektuje to, že jednoho klienta by měl obsluhovat po dobu trvání session stále jedn server.
DNS load balancing se nehodí ani na rozdělování provozu podle lokalit, to jde dělat mnohem lépe pomocí BGP.
-
lojzak (neregistrovaný)
Failover se dělá pomocí floating IP (jak bylo popsáno v článku). Pro více load balancerů nevidím význam. Pokud nejsou nastavena extrémně složitá pravidla, tak samotný loadbalancing nepředstavuje velkou zátěž. Ostatně stackoverflow funguje pouze na 2 loadbalancerec, které jsou v režimu failover.
Jestli výkon loadbalancerů nestačí, tak se bude pravděpodobně jednat o službu s velkým traffickem, kde nebude problém si zařídit load balancing pomocí BGP.
Pokud by výkon loadbalancerů nestačil z důvodu složitých pravidel, tak je možné využívat dvě úrovně. jeden (nebo 2 v režimu failover) loadbalancer na základní rozdělení mezi třeba 10 dalších, co budou zpracovávat složitá pravidla.
-
Při dvou loadbalancerech nerozdělovat požadavky na oba dva. Kapacita toho balanceru je totiž neznámá, se kterou nemůžete efektivně pracovat. Loadbalancer nebude škálovat lineárně, takže 20% zátěž na procesoru a síťových kartách rozhodně neznamená, že máte ještě 80% rezervu. Na to abyste znal přesné limity loadbalanceru, musel byste mít naprosto totožný kus HW v labu a při každém upgradu jádra, balancovacího SW, rekonfiguraci nějaké hodnoty,... provést nové měření abyste znal přesný limit. A i když přesnou hranici znáte ( resp. myslíte si, že jí znáte ), tak je to nebezpečné, protože v praxi se budete řidit především grafy, kde při sebelepší použité technologii nemáte všechny peaky - a je jedno jakou máte frekvenci sběru dat.
Proto je praktičtější mít aktivní pouze jeden node, když na něm bude výkonostní problém, tak je to hned vidět a switchnutí na popsaný active-active může být rychlý a funkční workaround, nicméně s vědomím, že komponenta je v tu chvíli bez redundance a je třeba situaci začít ihned řešit. Když se dostanete do stejného stavu se 2 aktivními nody, tak jste bez redundance a nevíte o tom ... Neřeší to ani pravidelné testy redundance - na těch se typicky ověřují funkčnosti failover mechanizmů, ale v praxi se to nikdy neděla v době nejvetší špičky - zákazník to prostě nedovolí.
Pokud je třeba mít z výkonostních důvodů víc jak jeden balancer, je třeba to provozovat v režimu alespoň N+1, aby to mělo smysl.
-
backup (neregistrovaný)
kde koupit hotove reseni?
clanek je pro mne OK, nejsme vsichni specialiste na zalohovane systemy. My dodavama pro mensi firmy podnikove reseni a doposud to nebylo nejak zvlast pojistene (tedy nekde ve sklepe stoji nahradni server a vecer se udela backup). Ale stale vice zjistujeme, ze i u nasich (ne tak narocnych zakazniku) by byla obnova ze zalohy velka neprijemnost.
Nejradeji bychom ale nejake takove reseni koupili uz hotove. (treba i s hardware). Mate s tim zkusenosti? Zejmena jak je to s tou administraci - obcas musime nahrat na server pres yum nejake nase specialni software, upravy ale musi delat i dodavatel toho 'spolehliveho reseni'. Dokazeme sami po zaskoleni reagovat na problemy. My se opravdu nechceme zabyvat s ruznym nastavenim DNS a rozumnet proc nekam dat radsi bridge a kam to nakonfigurovat. Muzete doporucit nekoho, kdo to dodava za rozumne ceny?
-
muf (neregistrovaný)
Divný článek.
Autor třeba poněkud mate čtenáře ohledně DNS load ballanceru. Je trochu divné se tvářit, že je to věc aplikací. Aplikace přece využívají resolver a je to tedy na něm - použije zpravidla první vrácenou položku. Vlastní střídání/prohazování vracených položek provádí DNS server(viz. rrset-order v konfiguraci bindu). V případě MX záznamů je to, pravda, trochu složitější.Očekával jsem odborný seriál, je to ale jen zmatená školní práce člověka, který ty věci teprve objevuje. Redakce by k tomu měla vždy přidat vysvětlující komentáře :-)
-
Filip JirsákStříbrný podporovatel
Je to i věc aplikací. Aplikace může použít první vrácenou adresu (a pak to skutečně závisí na serveru, aby adresy prohazoval), a nebo může získat seznam všech adres (respektive nějaké omezené množství, které jí poskytne resolver), a pak je na aplikaci, co s tím seznamem bude dělat. Aplikace si teoreticky může pamatovat/zjišťovat, která IP adresa odpovídá nejrychleji; pokud je nějaká IP adresa nedostupná, může použít další; nebo může poslat každý požadavek na jinou IP adresu, pokud potřebuje poslat víc požadavků (nic z toho bohužel prohlížeče nedělají).
MX je speciální případ, protože tam se i v DNS uvádí priorita záznamů.
-
muf (neregistrovaný)
No, teď v manu vidím, že gethostbyname() skutečně může vrátit přes **h_addr_list více adres a to, co mám léta zažité je tam jen jako macro pro zpětnou kompatibilitu(první prvek pole). Upřímně, vůbec nevím, kdy k tomu rozšíření došlo :-) Možná už dávno.
Ale skutečně to tak dnes aplikace používají? Třeba, dejme tomu, Firefox? Nevím, do kódu jsem se nedíval.... -
Filip JirsákStříbrný podporovatel
Jak jsem psal, běžné prohlížeče to bohužel nepoužívají. Některé jiné aplikace to používají – v článku je uvedeno OpenLDAP a obecně se to používá tam, kde se už při návrhu počítalo s tím, že může být jeden server nedostupný. V případě HTTP se spíš dodatečně zjistilo, že přesměrování na jiný server nic nebrání – a moc nechápu, proč se prohlížeče drží tradice a další adresy nezkoušejí. Byl by to ten nejlevnější způsob, jak zajistit jistou odolnost proti výpadkům, a podle mne to nemůže nic rozbít – pokud se prohlížeč nedokáže na první IP adresu připojit, není na tom už co zkazit a případné úspěšné navázání spojení s druhou nebo další IP adresou může být jedině plus. Snad jedině že by krátký výpadek spojení mohl uživateli zrušit session, ale to se dá na straně prohlížeče ošetřit.
-
j (neregistrovaný)
Prohlizece to ve skutecnosti pouzivaj ... uplne vsechny. Jen imbecilni vyvojari si toho jeste nestacili vsimnout. Nemaj totiz chudaci cas, musej menit UI.
Protoze copak asi tak dela browser, kdyz se nejdriv de pripojit na ipv6 ... a kdyz to nejde, tak jde na ipv4 ... (pripadne dokonce v rozporu s rfc rovnou posila na oboji a co odpovi driv to pouzije).
-
Ivan (neregistrovaný)
Pouziva to napr. Oracle RAC cluster. scan addresa listeneru se resolvuje na 3 IPcka, ktera by mela byt vracena v nahodnem poradi. Uplne 100% to ale neni, napr pokud je mezi DNS a vami BigIP(3DNS). Navic s tim musely byt i nejake jine problemy, protoze od posledni verze OCI ovladace uz obsahuji vlastni resolver a na gethostbyname kaslou. (To mimochodem dela cim dal vice aplikaci).
-
j (neregistrovaný)
Ono to ma ale vic aspektu ...
1) dns ti vrati 2-N zaznamu
2) ty zaznamy sou pokazdy v jinym poradi
3) tzn lze to pouzit k rozlozeni zatizeni
4) protoze aplikace (kazda normalni) zkusi nejdriv prvni IP ... a kdyz nevyjde tak druhy, treti ... atd
5) coz zaroven poresi vypadek nejaky IPSamo to neresi zatizeni toho konkretniho stroje, ale to te v mnoha ohledech naprosto nezajima, jednoduse pokud ti jeden stroj udrzi par tisic klientu, tak to samo o sobe znamena, ze jeden klient generuje naprosto nepatrnou zatez, takze to rozlozeni bude defakto zcela dostatecny.
Jenze ... pokud si klient vybere prvni IP a zrovna tenhle stroj padne nahubu ... tak samozrejme pokud takova situace neni osetrena, tak proste padne nahubu i klient. Coz se ale stane i v pripade, ze to IPcko nekde cestou forwardnes na bezici stroj - protoze se ti stejne rozpadne session.
Takze takovy "uzasny a jednoduchy reseni" ve skutecnosti neresi lautr nic.
Ve finale mas jen jedinou moznost - musi to umet klient. Ty bys sice moh resit predani session na strane serveru, ale to muzes resit leda v pripade, ze ten server nejak korektne vypnes. Pokud padne, tak se nic nikam nepreda. Takze je to na klientovi. Ten musi poznat, ze server nekomunikuje a musi umet komunikaci obnovit s jinym serverem. Coz znamena minimalne resit neco na tema transakce = nepotvrzena transakce neprobehla = poslu ji znova/vynadam uzivateli/.....
Coz je prozmenu neco, o cem autor nema nejspis ani paru - on proste zajistuje provoz neceho, co z principu stejne nemuze fungovat tak jak si mysli.
-
Filip JirsákStříbrný podporovatel
Jako „session“ se ve světě webových aplikací označuje situace, kdy server pošle klientovi nějaký jednoduchý identifikátor, který klient přibaluje ke každému požadavku (třeba ve formě cookie), a server si k tomuto identifikátoru pamatuje nějaká další data. Takže předání session musí řešit server, protože ten jediný má ta data spojená se session – klient má jenom identifikátor té session, ale ne data. Kvůli tomu, aby ta data měl server a ne klient, se celá ta šaráda se session dělá. Takže klient to opravdu nijak nevyřeší.
Řeší se to tak, že data session si nedrží přímo server, ale existuje nějaké sdílené úložiště, do kterého si pro data session může sáhnout kterýkoli server. Výpadek serveru pak nevadí, když se klient připojí k jinému serveru, ten si vytáhne data ze společného úložiště a jede se dál. Samozřejmě to znamená, že se to kritické místo „akorát“ přesunulo z webového serveru na to úložiště dat pro session.
-
j (neregistrovaný)
Jasne, takze reknemez se servery sdilej RAM ... mno a reknemez se klient odesle texbox a jeden ze serveru padne nahubu. Mno a jelikoz druhej server najednou dostane req na zobrazeni odpovedi na neco o cem nic nevi, tak se podiva co ze to ten klient delal naposled, a zjisti, ze naposled se mu zobrazil textbox ... co bude delat dal? Sem vazne zvedav na reseni ala Jirsak ...
Protoze ve skutecnosti si stav session drzi jak server tak predevsim klient, ten jedinej totiz vi, co delal nez server prestal odpovidat. A ten jedinej na to muze korektne reagovat.
Pricemz v pripade browseru zcela obecne plati, ze si kazdej poradi (vice ci mene) dobre s tim, ze server neodpovi (minimalne vrati nejakou pomerne rozumnou chybu a treba umozni akci opakovat), kdezto rozhodne si neporadi s tim, ze server vrati neco zcela neocekavatelnyho (respektive presne to uzivateli zobrazi, coz v tomhle pripade bude treba prave prazdny textbox).
Nacez bude nasledovat fyzicka likvidace obou serveru velkou palici.
-
Filip JirsákStříbrný podporovatel
Jasne, takze reknemez se servery sdilej RAM
Ne, servery nesdílí RAM. Servery sdílí úložiště session informací. Může to být třeba relační databáze, kterou obvykle servery sdílí i kvůli ukládání dat, ale to moc dobře neškáluje. Častěji se používají různé NoSQL databáze, třeba ty používající protokol memcached apod.mno a reknemez se klient odesle texbox
Webové prohlížeče neodesílají texboxy, ať už je to cokoli, ale HTTP požadavky. Webové servery na to odpovídají HTTP odpověďmi.tak se podiva co ze to ten klient delal naposled
Takhle se naštěstí webové aplikace nepíšou – jediný, kdo tenhle princip masově používal, byly staré ASP:NET MVC aplikace. Naštěstí i Microsoft brzy pochopil, že tudy cesta nevede.zjisti, ze naposled se mu zobrazil textbox ... co bude delat dal?
Nic takového nezjistí. Server z požadavku například zjistí, že uživatel požaduje zobrazení košíku. Jako identifikaci pošle v cookie identifikátor session. Webový server se podívá do sdílené cache, tam zjistí, že tenhle identifikátor session patří uživateli XY – a buď má obsah jeho košíku uložený také v té cache pod tím session ID, tak si ho vytáhne odsud, nebo, pokud je obsah košíku uložený třeba v databázi, načte obsah košíku uživatele XY z databáze.Protoze ve skutecnosti si stav session drzi jak server tak predevsim klient
Kdyby si stav session držel klient, nemusí si ho držet server. V začátcích webu ale bylo jediné místo, kde si klient mohl držet nějaký stav – cookies. A ty byly omezené velikostí. Proto se do cookies ukládal jen identifikátor a stav si držel server.klient, ten jedinej totiz vi, co delal nez server prestal odpovidat
Klient nedělal nic. Na klientovi byla zobrazená webová stránka.(respektive presne to uzivateli zobrazi, coz v tomhle pripade bude treba prave prazdny textbox
Předbíháte dobu, prohlížeče zatím neumí samy od sebe vyměnit část stránky. Prohlížeč pošle požadavek na webovou stránku, server mu vrátí celou webovou stránku a prohlížeč jí celou vykreslí. -
Filip JirsákStříbrný podporovatel
JavaScript jsem nezmiňoval schválně. Pak totiž klientem není webový prohlížeč, ale ta javascriptová aplikace – a je čistě na autorech té javascriptové aplikace, jak a jaký stav si bude držet a jak se bude chovat v případě nedostupnosti serveru. Javascriptová aplikace klidně může i obejít to omezení prohlížečů, že resolvují jen jednu IP adresu, a může mít v sobě zadrátováno víc DNS názvů, a zkoušet je, dokud jeden z nich nebude fungovat.
-
Filip JirsákStříbrný podporovatel
Pokud klient poslal požadavek na server, a server během jeho zpracování havaroval nebo se přerušilo spojení s klientem, klient logicky nedostane od serveru odpověď. Tudíž klient nebude mít žádný důvod domnívat se, že operace skončila úspěšně, právě naopak.
Pokud je klientem přímo webový prohlížeč, zobrazí nějakou chybovou hlášku, třeba že server neočekávaně ukončil spojení. Uživatel může použít tlačítko zpět, čímž se dostane na předchozí stránku s formulářem, kde mu prohlížeč vyplní uživatelem dříve vyplněná data (pokud autor webu prohlížeči v tomto směru nehází klacky pod nohy). Uživatel pak může dát formulář znovu odeslat, a pokud je server mezi tím znovu dostupný (třeba protože loadbalancer vyřadil havarovaný server z clusteru a přesměrovává na zbývající živé servery), formulář se znovu odešle.
Pokud je klientem javascriptová aplikace v prohlížeči, musí návratovou chybu ošetřit její autor, ale zase je jednoduché zobrazit uživateli hlášku „odeslání se nezdařilo, přejete si pokus zopakovat?“ A opět, pokud se mezi tím podaří komunikaci přesměrovat na jiný server, opakovaný pokus se podaří.
Samozřejmě to komplikuje session, která třeba drží údaje o přihlášeném uživateli. Pokud servery používají sdílené úložiště session, není to problém, nový server si prostě data session vytáhne odsud. Pokud se o data session přišlo při pádu serveru, je potřeba data session nějak obnovit, pokud to je možné – např. že se uživatel znovu přihlásí. V případě javascriptové aplikace je to poměrně jednoduché – když se pokusí znovu odeslat data, vrátí se chyba autorizace, aplikace se znovu zeptá uživatele na přihlašovací údaje, přihlásí ho a příslušná data odešle potřetí. Pokud je to klasická formulářová aplikace, je to komplikovanější – je potřeba někam uschovat data, která klient poslal, přesměrovat ho na přihlašovací stránku a po přihlášení ho přesměrovat zpět na stránku, kde byl předtím, a znovu mu vyplnit data, která předtím poslal. Na druhou stranu to je úplně stejné řešení, jakým se řeší vypršení platnosti session, takže uživatelsky přívětivá aplikace to řeší stejně.
Jinak samozřejmě je z tohohle pohledu nejlepší bezestavová aplikace, kdy je klient autentizován při každém požadavku (např. HTTP autentizace). Pak není potřeba na straně serverů řešit nějaké uchování session a perzistenci spojení, prostě může každý požadavek zpracovat jiný server. -
j (neregistrovaný)
Takze co jirsak, dalsi kolecko? Prave si potvrdil to, proti cemu si pred par postama protestoval.
"Jenze ... pokud si klient vybere prvni IP a zrovna tenhle stroj padne nahubu ... tak samozrejme pokud takova situace neni osetrena, tak proste padne nahubu i klient. Coz se ale stane i v pripade, ze to IPcko nekde cestou forwardnes na bezici stroj - protoze se ti stejne rozpadne session."
-
KateStříbrný podporovatel
Wow. Ještě jednou tady j prohlásí že dělá admina a já padnu smíchy. Takovou snůšku bludu jen tak někdo vyplodit nezvládne. Odpovídat na to nemá smysl, výše už bylo řečeno výše :)
-
KateStříbrný podporovatel
Neadminuju, programuju. Každopádně, to že ani nevíš jakým způsobem se ukládají a dají sdílet sessions je docela fail, nemyslíš?
-
j (neregistrovaný)
Ja velmi dobre vim jak se ukladaji sesions ... narozdil od tebe taky vim, to co jirsaka jeste ani nenapadlo, a to ze se mu slozi tcp konexe (protoze dneska bezne browser udrzuje spojeni otevreny), ale jo, treba si do ty svy databaze uklada pekne poradovy cislo kazdyho paketu ... a kdyz mu cestou nejakej vypadne, tak je vprdeli taky.
Jesli sis totiz nevsimla, tak se tu resi situace, ze jeden ze dvou serveru padne nahubu a co se bude dit potom. ukaz mi server, kterej kdyz padne nahubu, tak se jeste pekne slusne rozlouci, posle vsem klientum pozdrav, a pekne vsechno ulozi.
Ukaz mi jediny reseni webu, ktery prezije presmerovani na jinej server. Sem vazne zvedav. Protoze bez spoluprace s klientem to realizovat sice za jistych okolnosti lze, ale to rozhodne nebude "velky" reseni za 20k. Pricezm prave replikace RAM je toho podminkou. Coz mimo jiny zase znamena, ze samozrejme nejde druhej stroj pouzit pro rozkladani zateze. Obecne se totiz da rict, ze se tyhle dva pozadavky navzajem pomerne slusne vylucujou.
-
Filip JirsákStříbrný podporovatel
ukaz mi server, kterej kdyz padne nahubu, tak se jeste pekne slusne rozlouci, posle vsem klientum pozdrav, a pekne vsechno ulozi.
Vtip je v tom, že jste stále nepochopil, že když server neočekávaně odpadne, klient nedostane požadovanou odpověď a bude ve stavu, jako kdyby nic neodeslal. Váš předpoklad, že server nejprve stihne odeslat klientovi kompletní odpověď, a teprve pak se poroučí do věčných lovišť, je chybný. A když to tak náhodou je, je kolečko požadavek–odpověď dokončené, takže pád serveru ničemu nevadí – příští požadavek prostě půjde na jiný server.Ukaz mi jediny reseni webu, ktery prezije presmerovani na jinej server.
Všechna cloudová řešení – cloud je na tomhle principu postaven. Takže třeba Google, GMail, Seznam, Dropbox, YouTube, Mapy.cz a tisíce dalších.Pricezm prave replikace RAM je toho podminkou.
Replikace RAM je nebetyčná hloupost hodná vašeho jména. Už jsem vám vysvětloval, že pokud je potřeba držet stav na serveru, řeší se to sdíleným úložištěm session nejčastěji v nějaké NoSQL databázi. A ještě lepší je nedržet stav vůbec. -
Petr M (neregistrovaný)
Na co pozdrav na rozloučenou? Ty když přijdeš do místnosti, kde je zhasnuto a zeptáš se, jestli tam někdo je, dostaneš odpověď "není", když je prázdná?
Logicky, na straně serveru
1. Dostanu požadavek
2. Zpracuju požadavek
3. Pošlu výsledekKdyž selže 1, nedostanu odpověď. Server neví, že po něm někdo něco chce.
Když selže 2, nedostane odpověď, nebo je odeslána chyba.
Když selže 3, neodejde kompletní odpověď.Takže pokud není odpověď, ber to jako rozloučení v kterékoliv fázi...
Web v browseru a na serveru běží na aplikační vrstvě TCP/IP. Fragmentace, MTU, IPSEC a podobně ho nezajímá. Došlo všechno, nebo nic.
Zapomeň na replikaci RAM, dej si tam obecný uložiště. Sdílený mezi web servery (řešíme front end web server).
1. Přijde login request, podívá se do DB klientů (ta musí být sdílená), vytvoří session, vrátí token. Klientovi nepřišel token - login fail, může zkusit jiný server. Ten buďto najde platnou session pro klienta (nepovedlo se potvrzení), nebo vyrtvoří novou.
2. Uživatel něco odešle. Nedostane ACK, zkusí to znovu na jiný server, ten buďto zná detaily a pošle předchozí výsledek, nebo ne a operace proběhne znovu,...
3. ...Data a tokeny jsou uloženy v nějaké cache, klidně jako JSON na ramdrive, v DB, jakkoliv. Ale to není starost front endu, ten se jenom uložiště ptá na session a existenci/výsledek operace.
-
Filip JirsákStříbrný podporovatel
Petr M: Jenom doplním, že pokud se session používá jenom pro identifikaci uživatele, lze se snadno obejít i bez toho sdíleného úložiště. Stačí identifikaci uživatele uložit do tokenu (spolu s datem expirace) a digitálně ho podepsat. Token pak dokáže ověřit kterýkoli server bez nutnosti mít nějaké sdílené úložiště session. Nevýhodou takového řešení je, že není možné vynutit odhlášení uživatele před expirací tokenu.
-
j (neregistrovaný)
2Petr M: Co to zase proboha zvanis ... zadny SDILENY uloziste NEMAS, mas DVA servery, mezi nima mas nejspis soho switch za 3 kila, mozna v kombinaci s routerem za petikilo.
A resis, jak vyresit, ze provoz je ... BEZ VYPADKU. A ZAROVEN, jak rozlozis na ty dva servery ZATIZENI.
Pricemz JA tvrdim, ze pokouset se preforwardovat IPcko z jednoho na druhe je uplne khovnu, protoze to neresi vubec NIC, to je to jediny, o cem je tu celou dobu rec.
Nemluve o tom, ze 90% webu (vcetne roota, lupy a dalsich) ti pri opakovanym odeslani vytvori novej zaznam.
-
Filip JirsákStříbrný podporovatel
zadny SDILENY uloziste NEMAS
Mohl byste nám popsat, co zhruba tak ty vaše dva servery dělají, a co je uložené v té session? Webové servery totiž často čtou data ze sdíleného úložiště (zobrazení článků, zobrazení e-mailů, zobrazení zboží), zapisují do sdíleného úložiště (komentáře k článku, e-mail k odeslání, objednávku zboží). V session obvykle bývá identifikace přihlášeného uživatele, přičemž pro přihlášení uživatele obvykle potřebujete ověřit přihlašovací jméno a heslo ve sdíleném úložišti.
Jistě, existují weby, které nepotřebují sdílené úložiště – třeba poskytují jenom statické stránky. Jenže takové weby zase nemají nic uloženého v session a každý požadavek může přijít na jiný webový server.Pricemz JA tvrdim, ze pokouset se preforwardovat IPcko z jednoho na druhe je uplne khovnu, protoze to neresi vubec NIC, to je to jediny, o cem je tu celou dobu rec.
To je zvláštní, že to všem provozovatelům cloudu funguje. Vy třeba když vyhledáváte na Google, tak nějak zaznamenáte, že váš druhý dotaz šel na jiný server, než první dotaz? Poznáte na YouTube, že vás začal odbavovat jiný server?Nemluve o tom, ze 90% webu (vcetne roota, lupy a dalsich) ti pri opakovanym odeslani vytvori novej zaznam.
Opakovaném odeslání čeho? Nový záznam v čem? -
ded.kenedy (neregistrovaný)
ale jo, treba si do ty svy databaze uklada pekne poradovy cislo kazdyho paketu ... a kdyz mu cestou nejakej vypadne, tak je vprdeli taky.
Ty jsi dobry expert, cislo paketu te zajima na transportni vrstve a na vyssi urovni, nedejboze na urovni protokolu http, k tomu pristup vubec nemas.
Jesli sis totiz nevsimla, tak se tu resi situace, ze jeden ze dvou serveru padne nahubu a co se bude dit potom.
Na urovni protokolu HTTP se prijme bud cely request nebo odesla cela response. Proste se ten pozadavek nezpracuje a klient muze ohlasit, ze nedostal odpovidajici response od serveru. Opacne, server pozadavek zpracuje, ale klient si nevyzvednet response. Muze dat refresh a data se nactou podle aktualniho stavu.
Ukaz mi jediny reseni webu, ktery prezije presmerovani na jinej server. Sem vazne zvedav. Protoze bez spoluprace s klientem to realizovat sice za jistych okolnosti lze, ale to rozhodne nebude "velky" reseni za 20k. Pricezm prave replikace RAM je toho podminkou
Naprosto jednoduse. Nastavis si pro example.com dve IP/CNAME (srv1.example.com, srv2.example.com), predpokladejme, ze loadbalancing bude nejak zarizeny. Jednotlive hodnoty session si budes ukladat v nejake databazi (postgres, mysql, bdb, nejake nosql), prijde pozadavek, prislusny server srv1/srv2 si data vytahne z databaze, provede odpoved klientovi a zmenene hodnoty session ulozi opet do databaze.
Opravdu me prekvapuje, ze odbornik jako ty, takovou zakladni konfiguraci nezna.
-
ded.kenedy (neregistrovaný)
nedokazes si ani precist zadani.
Pozadavek zni, ze provoz bude bez vypadku komunikace (o webu nebyla vubec rec).
Myslis? Nevim kdo se tu ptal:
Ukaz mi jediny reseni webu, ktery prezije presmerovani na jinej server.
Mas dva stroje a mezi nima blbej switch, nic jinyho nemas.
Bolelo by to moc, kdybys jednou priznal, ze necemu nerozumis. Nejdriv pozadujes sdilenou RAM, ted, ze mezi pocitaci je jen blby switch, pricemz pro realne nasazeni jsou tyhle pozadavky absurdni a zbytecne. Sdilene uloziste pro sessions je naprosto bezna a standardni zalezitost, stejne jako dedikovany server pro databazi.
-
Petr M (neregistrovaný)
No ale to se od webu dostaneme k DB, od front endu k back endu.
Fakt je problém na fyzickým serveru mít dva virtuály, v jednom front end a ve druhým back end, který skladuje ty sessions? A je problém zrcadlit stajnou databázi na obou strojích s tím, že front end primárně sahá na data na stejné fyzické mašině a když se k nim nedostane, tak sáhne na vedlejší stroj?
