Vlákno názorů k článku Velká řešení otevřeně: spolehlivá a škálovatelná síť od Crow - Nekritizuju,jenom se ptám: Ad DNS - skutečně DNS server...
-
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.)
