Delame servery, jak to v enterprise nenajdete - dil III.

24.3.2013 13:40 | Přečteno: 3091× | vpsFree.cz |

Na konci meho tridilneho miniserialu o hardware ve vpsFree.cz zbyva jeste probrat sitovani.

Sit pred prechodem do racku

Dokud jsme meli akorat towery, nebylo moc co resit, Master Internet totiz doda linku ke kazdemu toweru zvlast. Po par mesicich provozu toweru se ukazala zajima vec - neni gigabitova sitovka, jako gigabitova sitovka. Na deskach Asus P6T je onboard jakysi Realtek - mohlo mne napadnout uz ze zkusenosti z Lbfree (jedna ze dvou libereckych CZFree-like siti), ze to nebude nejlepsi volba.

Tyhle Realteky se ukazaly jako dost smejdy, obzvlast, kdyz nimi proteka hodne malych paketu. Navic nemaji poradny offloading - sice mi prijde, ze offloading je silne "overrated feature", ale i mimo nej ty Realteky stoji celkove za nic. Takze se k cene desktopu pricetla jednoportova Intel e1000e sitovka.

Realteky jsme pouzili na vyrobeni vnitrni site - nepotrebovali jsme ji tehdy jeste temer k nicemu, protoze jsme nemeli zadne stroje, ktere by bylo vhodne mit jenom na interni siti, nicmene ja to vetsinou s takovymi featurami, ktere hned nutne nepotrebujeme, jsme na tom tak, ze je lepsi je mit dopredu, obzvlast, pokud to moc nestoji - clovek pak ma pri reseni ruznych infrastrukturnich situaci ma vic moznosti.

Jeste pri vyhradne towerovem provozu jsme tak koupili 24portovy managovatelny Linksys switch (SRW2024), s kterym i pri zpetnem ohledu nebyly vubec spatnou volbou. Dneska uz Linksys switche neexistuji, po tom, co Linksys koupilo Cisco, tuhle radu zaintegrovalo do sveho produktoveho portfolia jako SMB switchove reseni.

Sitova infrastruktura dnes

Dneska mame v Praze v racku sit postavenou nad dvema Cisco SG300-52 switchi, coz jsou prave potomci tech Linksysu, akorat s Cisco firmware. Ten ma uz aspon pouzitelne CLI (telnet, ssh), ktere se podoba klasickemu IOS. Tyhle modely jsou managovatelne L2 switche s par L3 prvky (ktere nepouzivame), maji celkem 52 gigabitovych portu a k tomu (pro lenochy) celkem obstojne webove rozhrani. Na puvodni Linksysy clovek potreboval Internet Explorer a CLI nemely - dalo se dohackovat, ale na produkcni pouziti na dulezite paterni prvky si to ani ja nedovolim.

Kazdy server je pripojeny do obou switchu, stejne jako oba dva routery, ktere mame. Nad touhle konfiguraci provozujeme bonding, aby mohl jeden ze switchu byt postradatelny. Dokud bezi oba, diky balance-xor se dostavame na 2Gbit rychlost po interni siti, coz je super hlavne pro zalohovani a budouci NAS.

Routery

Z predchozich clanku uz vam musi byt jasne, ze nejsem zastance zabehnutych enterprise reseni, ktere jsou mnohdy nekriticky prebirany jako dogma, a tak si spoustu veci resime po svem. Ani routery nejsou vyjimkou. Nevidim duvod, proc bych mel za stejnou funkcionalitu preplacet Cisco, Juniper, nebo podobne vendory.

Pred siti v Praze mame tedy 2 x86 routery, jsou to Supermicro servery s jednim ctyrjadrovym Xeon E3 CPU o taktu 3.3 GHz jeste Sandy Bridge varianty, v2 - Ivy Bridge vysel az nekolik mesicu po jejich nakupu.

Trochu zklamanim je stav opensourcovych routerovych reseni - nic z dostupneho se neda poradne provozovat, pokud vezmu do uvahy, ze na soucasnych routerech mame uz okolo 70 interfacu (VLANy, bondingy, IPIP tunely nad IPSecem, VRRP), nekolik instanci OSPF (i v3), BGP, potom nekolik oddelenych instanci DHCP a dalsi drobnosti jako OpenVPN. Tohle se proste neda na syrovem linuxovem boxu odmanagovat bez zesediveni. Nerikam, ze to nejde, ale je to na hlavu.

Na routerech nam tedy bezi jeden z mala proprietarnich softwaru, ktere v cele infrastrukture mame, a to Mikrotik RouterOS.

Je postaveny nad Linuxem, takze kompatibilita s hardware je dost slusna, spravovatelnost takoveho systemu je podle meho nazoru perfektni - maji prijemne UI (Winbox) i CLI. Jako kazdy software i RouterOS se nevyhne bugum, ale to se stava i s Cisco IOS pri obskurnejsich konfiguracich, takze se to tezko da pocitat jako nevyhodu jedinecnou RouterOSu.

Fyzicky jsou ty routery osazene 3mi 2portovymi igb sitovkami, ktere maji z hlediska latence tady uz celkem podstatny offloading VLAN i checksumming.

Oproti e1000e sitovkam mi prijde, ze igb jsou vice vhodne na seriozni nasazeni, nemaji minimalne takove trapne chyby jako takedown vhodne tvarovanym paketem (jako e1000e 82574L), igb driver je mene zabugovany a offloading narozdil od e1000e opravdu funguje.

Na softwarovych routerech, ktere nemaji ASICy na offloadovani routovani, je z hlediska propustnosti i latence kriticka frekvence CPU a propustnost PCIe sbernic. Dalsi dulezitou featurou je podpora MSI-X signalu misto klasickych preruseni (samozremost u PCIe), jejichz obslouzeni se v Linuxu umi pekne balancovat mezi ruzna jadra CPU. V souvislosti s MSI-X je dobre zminit opet proklete Intel 82574L, ktere pri nekterych konkretnich konfiguracich proste umiraji a pada jim link (workaround v e1000e je uz dlouho, proste vypne na tech cipech podporu MSI-X a jede se pres legacy MSI, ktere se ale hur balancuje).

Propustnost nasich routeru s RouterOS 5 je nekde u 3 Mpps, tedy 3 miliony packetu za sekundu, coz dava suma sumarum nejhorsi moznou propustnost pri malickych paketech na urovni asi 180 Mbit. Kdyby se mi hodne chtelo, mohl bych maskaradu, kterou tam mame pro interni sit, prehodit na dedikovany router, cimz bych mohl vypnout connection tracking, majici za nasledek zdvojnasobeni propustnosti.

Vzhledem k charakteru bezneho provozu na vpsFree jsou tyhle routery uplne skvele dostacujici, dokonce hodne naddimenzovane - prumernou velikosti paketu, ktery nam protece routerem, je nejakych 1000B, coz dava okolo 2.5Gbit propustnosti pri conntracku, 5Gbit propustnosti bez nej. To uz je slusne pouzitelne i pro "entry-level" 10G routing.

Navic pri nasi topologii site, pri pouziti OSPF a BGP, se traffic balancuje mezi ty dva routery, takze propustnost site do Internetu se nasobi jejich poctem.

Cena za takovy router je nekde u 30ti tisic Kc i s licenci RouterOSu, to bych chtel videt, jak neco takoveho jde dosahnout s klasickymi routery a la Cisco.

Brno

V Brne mame vseho vsudy 80 VPS a neplanujeme tam nijak extremne expandovat, ucel te lokace je spis pro zalozni VPS (MX, DNS, ...) pro cleny, kteri to potrebujuji, takze tam to s propustnosti neni potreba prehanet.

Proto tam misto x86 routeru a SG300 switchu mame dva Routerboardy RB1100AHx2, coz jsou dvoujadrove PowerPC routery s dostatkem gigabitovych portu. Nejnizsi propustnost pri nejmensich paketech je nekde u 80 Mbit, coz je stejne 4x nad maximalni hodnotou trafficu, ktery tam tece. Opet, kdybych vypnul conntrack, jsme na dvojnasobne propustnosti, stejne tak jsou tam ty routery dva, take se zatez rozklada pres ne oba.

Linky a uplink do datacentra

Jak v Praze, tak v Brne mame uplink privedeny dvema linkami, na kterych si privatnim BGP peeringem s Masterem vymenujeme routy. Na vlastni ASN nemame zatim narok, protoze podle pravidel RIPE (kde jsme cleny uz pul roku) nemame alespon dva upstream poskytovatele. Asi by se to dalo ukecat kvuli dvema nezavislym lokacim, ale nepotrebujeme to, takze jsem zatim neresil.

Vyhoda je, ze napr. pri DoSu prichazejicim na konkretni IP adresu ve vpsFree muzu danou IP poslat do null-routy diky BGP blackholingu sam, aniz bych musel cekat na podporu v MAI.

Latence v nasi siti

Na kazdou IP adresu navesenou na VPS mame separatni /32 (nebo /128 v pripade IPv6) routu diky pouziti OpenVZ "venet" interface. Diky tomu se vsechna smerovaci rozhodnuti delaji uz na L3 urovni, node, na kterem VPS sidli, tak um udelat routovaci rozhodnuti rovnou, v ARP tabulkach tak jsou akorat IP-MAC hardwarovych masin, nemusim resit pretekajici ARP tabulky a rozhodnuti "co s paketem" se da udelat rychleji, coz je pocitit hlavne, kdyz je potreba komunikace mezi dvema VPS na ruznych hardwarovych nodech.

Nasledkem je o asi 100 mikrosekund nizsi latence oproti klasicke konfiguraci site. Dalsi latenci stahuje bonding, protoze existuji dve cesty, kterymi se daji posilat pakety k jednomu cili, tim padem paket stoji mensi frontu na odeslani.

Tohle sice nebyl zamysleny dusledek pri navrhu site, ale je to prijemny bonus, ktery poznate, kdyz nad tou siti mezi VPS potrebujete sdilet data pres NFS. Coz ostatne v par pripadech delame a pribydou dalsi s tim, jak prijde NAS v prubehu nasledujicich par tydnu.

Zaverem

Tady bych asi povidani o hardwaru ukoncil, myslim, ze jsem se dotknul apon letmo vsech podstatnych bodu, ktere popisuji nasi infrastrukturu ve vpsFree. Necekam, ze za to sklidim ovace, slo mi o to ukazat mistnim milovnikum enterprise, ze trava se na hristi umi zelenat i bez pouziti "industry standard" enterprise technologii .

By the way, tenhle tridilny serialek jsem sepsal pri ceste tam a zpatky vlakem mezi Bratislavou a Brnem behem dvou dni, takze kdyz najdu vic zaminek jezdit vlakem, bude i vic spamu na blogu ode mne

       

Komentáře

[disorder]

mne sa v laptope dvakrat pokazil intel, expresscard nahrada hreje a tiez nefunguje zdaleka tak dobre ako stary laptop. realteky co mam v htpc a starom laptope slapu bezchybne.

food for thought

[disorder]

oprava: v starom laptope je broadcom, tg3 driver.

[alkoholik]

Jo, Intel se uz sitovky celkem naucil. Pamatuju doby Intel PRO/100, kdy se rikalo: tohle je prvni karta od Intelu, ktera vazi vic nez jeji errata.
:)

[ewew]

Poznáš aj konkrétny typ sieťovky, ktorá má problémy s malými paketmi ?

[snajpa]

Byla to ta, co byla na Asus P6T, ale co to presne bylo... Realtek 8111[neco], aspon myslim, ale fakt si to nepamatuju a uz tyhle desky ani nikde nemam.

[Radek Hladik]

Chválím za pěknou sérii.

K tomu CLI u linksysů, ono se nemusí dohackovávat, stačí se normálně přihlásit přes tu jejich obludnost, udělat ALT+Z a spustit binárku, co tam normálně je Jinak ty switche jsou/byly fakt super, ikdyž teď zrovna mi jeden v kombinaci s Intel 82574L předvedl "zajímavou" věc. Připojil jsem server, udělal ifup a nestačil jsem se divit...

kernel: [  335.465527] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
kernel: [  340.706092] e1000e: eth1 NIC Link is Up 100 Mbps Half Duplex, Flow Control: None
kernel: [  340.722659] e1000e 0000:03:00.0 eth1: Autonegotiated half duplex but link partner cannot autoneg.  Try forcing full duplex if link gets many collisions.
kernel: [  340.745904] e1000e 0000:03:00.0 eth1: 10/100 speed: disabling TSO
kernel: [  340.759794] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
kernel: [  340.775184] e1000e: eth1 NIC Link is Down
kernel: [  340.790571] e1000e 0000:03:00.0 eth1: Reset adapter
kernel: [  342.696207] e1000e 0000:03:00.0 eth1: Reset adapter
kernel: [  346.914047] e1000e: eth1 NIC Link is Up 100 Mbps Half Duplex, Flow Control: None
kernel: [  346.949849] e1000e 0000:03:00.0 eth1: Autonegotiated half duplex but link partner cannot autoneg.  Try forcing full duplex if link gets many collisions.
kernel: [  346.992419] e1000e 0000:03:00.0 eth1: 10/100 speed: disabling TSO

A pak pořád dokola... Druhý stejný switch neměl nejmenší problém. A protože tomuhle už zlobí ten webmanagement, tak místo něj přijde nejspíš přávě nějaké to Cisco...

[RAket]

Nemáte prosím zkušennosti s novým ethernet chipsetem od Intelu i210AT? Nové supermicro mb mají toto a nevím, jestli radši nejít do osvědčené igb síťovky PG-I2. Díky.