2012-08-31

RIverbed offtopic érdekességek

Egy kis érdekesség egy Riverbed Steelhead 550-es WAN optimizer CLI-jéből. A legmenőbb networkös cégeknél mindig vannak magyarok:

amnesiac > show ver
Product name:      rbt_sh
Product release:   7.0.1
Build ID:          #202_11
Build date:        2012-02-09 17:16:08
Build arch:        i386
Built by:          root@miskolc

Uptime:            2m 29s

Product model:     550
System memory:     1549 MB used / 475 MB free / 2024 MB total
Number of CPUs:    2
CPU load averages: 1.85 / 0.76 / 0.28
amnesiac >

Ha már Riverbed, akkor még egy dolog, amiről érdemes tudni: kb. két éve megvették kilóra a Wireshark mögött álló céget, persze maga a kód GPL-es, de a tudás, a kulcsemberek, mind-mind Riverbed alkalmazottak. A legszebb az egészben, hogy itt nem történtek olyan baklövések, mint amelyek például az OpenOffice és az Oracle esetében a LibreOffice forkhoz vezettek -- szintén ugye két éve. Nem tépték szét a fejlesztői közösséget, nem akarták kisajátítani a Wiresharknak a protokoll analizátorok közötti páratlan népszerűségét, építettek rá egy üzleti modellt, tök jó termékek kaphatók, egy Cascade Shark appliance-t például egyszer szívesen meghajtanék.

Szóval riszpekt, köszi, hogy nem kúrtátok el, és persze üdv a magyar kollégá(k)nak.

Mekkora egy switch késleltetése?

A napokban egy összetett alkalmazáskésleltetés-mérési projekt kapcsán felmerült a kérdés, hogy hol legyen az első mérési pont a rendszerben. Maga a rendszer egy több hostos elosztott alkalmazás, amiben mindenfelé létre lettek hozva mérési pontok. Nyilvánvaló, hogy az első mérési pont ott kell, hogy legyen, ahol bejutnak az adatok a rendszerbe, ezt történetesen egy Linux. A teljes elosztott alkalmazás késleltetési ideje sok milliszekundumos nagyságrendben mozog, nekem meg sem fordult a fejemben, hogy az említett első mérési pontot nem ezen a gateway Linux rendszeren kellene létrehozni, de egy kolléga felvetette, hogy van ám az előtt a Linux előtt egy switch is, és hogy gyakorlatilag az az első eszköz a teljes rendszerben, azon kellene egy monitor portot konfigurálni, hogy valóban a legkorábbi ponton kapjuk el a bejövő adatokat.

Ekkor kibújt belőlem a networkös, hiszen a switching, akár a gyorsabb cut-through de még a lassabb store-and-forward esetében is a milliszekundumos nagyságrend alatt, mikroszekundumos berkekben mozog. Arról nem is szólva, hogy az elosztott rendszer hostjai közötti NTP szinkronizációnak is vannak korlátai, sosem törtem ilyenen a fejem, de állítólag LAN-on az NTP szinkronizáció precizitása jó, ha megüti a 20 mikroszekundumos tartományt. Ergo felesleges vesződni a monitor porttal, ha nem is tudjuk olyan precízen jegyzetelni az adatokat, amennyit az egyetlen switcheléssel korábbi sniffing jelentene.

Ennek apropóján utánanéztem, hogy tulajdonképpen mennyi az annyi: mekkora manapság a switchek késleltetése? Átpörgettem pár adatlapot különböző gyártóktól, és arra jutottam, hogy az enterprise termékek esetében a mezei 100Mb/s-es eszközöktől a 10Gb/s-es Ethernet eszközökig nagyjából néhány tíz mikroszekundumos késleltetéssel lehet számolni. Persze nehéz ezeket az adatokat összehasonlítani, hiszen nem ugyanazokkal a módszerekkel dolgoznak a különböző műhelyek a mérések során, van ahol a beérkező keret első bitjétől megy a stopper a kimenő keret első bitjéig, máshol (store-and-forward méréseknél) a beérkező keret utolsó bitjétől a kimenő első bitjéig. Gyakran nincs feltüntetve, hogy mekkora Ethernet keretméret mellett végezték a mérést, máshol egész adatsorok vannak egészen jumbo frame méretig. De úgy körülbelül a néhány tíz mikroszekundum jó közelítést ad, és ez nagyjából a kilencvenes évek közepe, az ASIC áramkörök switchekben való megjelenése óta így van. Az alapok a cisco.com-on elolvashatók a "Cut-Through and Store-and-Forward Ethernet Switching for Low-Latency Environments" doksiban.

Persze vannak extrém igényeket kielégítő termékek is. Úgy tűnik, hogy mostanában a low latency switching piacot leginkább a tőzsdei rendszerek, illetve azoknak is egy speciális szegmense, a High-Frequency Trading rendszerek fűtik. Az egyik, erre a piacra szakosodott gyártó, az Arista például 600 nanoszekundumos késleltetésű cut-through switchekkel hergeli a vevőit már a tervezési dokumentumaiban is, így rackek között is már 2,4 mikroszekundomot képesek elérni.

No, ettől messze vannak azok az eszközök, amikhez én hozzáférek, de épp volt kéznél egy 3Com 5500-EI, gondoltam kipróbálom, hogy mekkora a késleltetése, nem éppen mai darab, de legalább enterprise cucc. Az adatlap pusztán annyit közöl, hogy "Store-and-forward switching; latency <10 μs". Lássuk. Elővettem a Systimax patchkábeleket, két egyforma laptopot, egyforma OS-szel (Ubuntu 12.04.1), és céleszköz híján ment a ping, először 1000 bájtos mérettel:


50 packets transmitted, 50 received, 0% packet loss, time 48998ms
rtt min/avg/max/mdev = 0.462/0.495/0.528/0.036 ms

Hm... 495μs átlagos RTT-re, annak a fele 247,5μs, igaz ebben benne van az is, hogy a switchtől független két OS-en át kell verekednie magát, valószínűleg maga a kapcsolás sokkal rövidebb ideig tart, mint amennyi idő alatt a két végen lévő TCP/IP stacken átjut az ICMP, de valahogy akkor is kevesebbre számítottam. Aztán kipróbáltam 32 bájtos mérettel is:


50 packets transmitted, 50 received, 0% packet loss, time 48998ms
rtt min/avg/max/mdev = 0.167/0.184/0.218/0.021 ms

Így már csak 184μs az átlagos RTT, azaz egy átlagos odaút már csak 92μs, úgy, hogy ebben a két Linux TCP/IP stackje is benne van, nem csak a kapcsolás. Ez valóban sokkal közelebb van az adatlap alapján megcélzott <10μs-hez, gyakorlatilag én ezt a a <10μs adatot már simán el is hiszem.

2012-08-23

Interaktív SSH wrapper parancssorból

Egy volt kollégám többször bizonygatta, hogy SecureCRT nélkül ebben a szakmában manapság már nem lehet meglenni, hogy enélkül nem veszik komolyan az embert. Valóban, az említett program legalább akkora változást hozott a remote shell hozzáférések egyszerű kezelésében Windows alatt, mint annak idején a PuTTY. A két programot igazából nem is érdemes hasonlítgatni, annyival okosabb, szebb, modernebb a SecureCRT, hogy a PuTTY csak egyetlen területen veheti fel a versenyt vele: az árában, merthogy ez utóbbi ingyenes. Minden másban, pl. hostok csoportosítása, jelszavak megjegyzése, alapból megnyíló sessionök stb. a SecureCRT viszi a prímet.

Arról azonban sosem sikerült meggyőznöm a kollégát, hogy Linuxon azért van élet a SecureCRT-n kívül is. Persze olyan szintű dolog nincs, mint amilyen a SecureCRT, illetve azt úgy hívják, hogy SecureCRT for Linux, de azért csak fel lehet a bash-t okosítani, hogy menjen az a Tab-os kiegészítés gyakran használt hostnevekre vagy ilyesmi. Nyilván az ember elsősorban már csak SSH-t használ, meg általában parancssort, még ha Linux desktop is fut a gépen, legtöbbször a terminálablak takar ki minden mást. A GNOME 2-es környezetben volt egy klassz kis app, az "SSH Menu", az egész élhető volt, közvetlenül a panelből lehetett kiválasztani a hostokat, de a mostani új desktopokból (GNOME 3, Unity) fájóan hiányzik egy igazán ütős alkalmazás erre. A Remmina lehet, hogy egyszer jó lesz, egyáltalán nem ördögtől való ötlet egyetlen kliensben integrálni az összes hasonló célú funkciót (SSH, VNC, RDP...), de jelen állapotában a Remmina CLI-s felületek használatához meglehetősen kényelmetlen. Szóval mostanában egyre inkább kezd igaza lenni a volt kollégának.

Egészen eddig a percig. Közzéteszem ugyanis a pótolhatatlan, teljesen CLI-s, interaktív SSH indító felületet, amit csak feldobunk egy jump szerverre, és okostelefonról, Windowsról, Linuxról egyaránt használhatjuk, itt van kérem a csodálatos, hasznos, mc-kék SSH menü szkript:


Még akár felhasználónevet is választhatunk (az alapértelmezett a $USER) egy előre megadott listából, vagy beírhatunk tetszés szerinti nevet:


Khm... nos, itt nagyjából véget is ér a szkript tudása, én jelenleg egy kb. 80 hosztos listával használom, és már annyira a szívemhez nőtt, hogy el sem tudnám képzelni a napi munkát nélküle. Különösebb függősége nincs, szükség van a "dialog" csomagra, "ncurses"-re. Kód:

#!/bin/sh

if ! $(which dialog); then
   echo "Can't find \"dialog\" binary on PATH."
   exit 1
fi

SSHHOST=$(dialog --stdout --title " SSH Menu " --menu "       IP............Hostname...............Function/Description" 22 74 100 \
192.168.0.1      "domain-name-host1      Comment for host1" \
192.168.0.2      "domain-name-host2      Comment for host2" \
192.168.0.3      "domain-name-host3      Comment for host3" \
192.168.0.4      "domain-name-host4      Comment for host4" \
192.168.0.5      "domain-name-host5      Comment for host5" \
192.168.0.6      "domain-name-host6      Comment for host6" \
192.168.0.7      "domain-name-host7      Comment for host7" \
192.168.0.8      "domain-name-host8      Comment for host8" \
192.168.0.9      "domain-name-host9      Comment for host9" \
192.168.0.10     "domain-name-host10     Comment for host10" \
192.168.0.11     "domain-name-host11     Comment for host11" \
192.168.0.12     "domain-name-host12     Comment for host12" \
192.168.0.13     "domain-name-host13     Comment for host13" \
192.168.0.14     "domain-name-host14     Comment for host14" \
192.168.0.15     "domain-name-host15     Comment for host15" \
192.168.0.16     "domain-name-host16     Comment for host16" \
)

if test -z $SSHHOST; then
   exit 1
fi

REMOTEUSR=$(dialog --stdout --title " Select remote user name " --menu "If you would like to type in a username select \"Cancel\"" 15 40 10 \
$USER "" \
root "" \
admin "" \
cisco "" \
vyatta "" \
)

if test -z $REMOTEUSR; then
   REMOTEUSR=$(dialog --stdout --title " Enter remote user name " --inputbox "" 7 40 )
fi

if test -z $REMOTEUSR; then
   exit 1
fi

clear
exec ssh -l $REMOTEUSR $SSHHOST