TS átállás – VI.

Hétfőn reggel a főnökömmel újra lefolytattuk a „Tamás, ez tovább nem mehet” beszélgetést, amely alapján számára is tisztázódott, hogy valamennyi lépésünkhöz idő kell, semmit nem tehetünk 10 perc alatt. A péntek krónikájához tartozott még, hogy Krisztián kollégám kihúzta a router és a telefonközpont közötti kábeleket, így már nem lehet VoIP kapcsolatokat létrehozni MALKER felől vagy felé. Ennek a hatása már ma (április3.) mérhető lesz. Lett is. Azt tapasztaltuk, hogy nincs változás, a MALKER válaszidők ugyanolyan gyengék, mint pénteken voltak.

A második ösvény az hálózat rendbe hozása. Sajnos tavaly novemberben nem engedélyezte a cég a székesfehérvári központ switche-einek cseréjét, így a mi eszközeink nem támogatják az IGMP snooping funkciót. Pedig az jó dolog. Az NLBS, mint tudjuk, kétféle üzemmódban képes működni, unicast illetve multicast. Unicast esetén minden node eredeti MAC címét elmaszkolja az NLBS és gyárt egy újat, méghozzá az NLBS cluster IP címéből generálva. Íme egy példa: Ha az cluster IP cím 10.10.10.10, akkor az unicast MAC cím  02-BF-0A-0A-0A-0A Ez úgy áll össze, hogy a 02-BF jelzi a cím unicast jellegét, a négy db 0A pedig nem más, mint a 10 hexadecimálisan. Unicast üzemmód esetén – ahogy azt már korábban is írtam – a MAC cím azonossága miatt nem lehet switchre kötni a node-okat, mert a switch csak egyetlen porton engedélyezné a forgalmat. A megoldás ilyenkor egy hub közbeiktatása. A hub nem foglalkozik a MAC címekkel, a switchnek pedig csak egyetlen porton kell az unicast MAC címet nyilvántartani. A megoldás szépséghibája, hogy a HUB (amellett, hogy általában nem is menedzselhető) esetlegesen szűk sávszélességet eredményezhet.

Trükközéssel a helyzet javítható. Ilyenkor a node-oknak két kártyája van, az egyik a hubon, a másik a switchen. Az NLBS a hubra kötött adapteren konfigurált, a node-ok TCPIP beállításainál eltérő const metric-et állítunk be az egyik illetve a másik kártyán. A local routing során az NLBS-es kártyákon beérkező forgalomra a másik kártyán keresztül érkezik a válasz. Így a szűk sávszélesség csak a forgalom egyik irányában marad meg, ami azért javulás.

A legjobb megoldás a sávszélesség szempontjából mégis a multicast üzemmód. Ekkor elég egyetlen kártya, amelyen két MAC cím jelenik meg. Az egyik egy unicast MAC cím, amelyhez a a node saját IP címe tartozik, és egy multicast MAC cím, amelyhez viszont a cluster virtuális IP címe rendelődik. Ez a switchet már nem zavarja, multicast MAC cím ugyanis több porton is megjelenhet. Annál inkább zavarba jön a router. Amikor egy CISCO router kiad egy ARP_Request csomagot, amelyben az adott virtuális IP-cím MAC címét tudakolja, a fürt válaszol, pontos információval, ám az IP csomag forrás MAC címe az adott node unicast MAC címét tartalmazza. Ezt a csomagot a router érvénytelennek tartja és eldobja. Nincs más megoldás tehát, mint kézzel be kell varrni a multicast MAC cím és az unicast cluster IP cím öszerendelést.

Az IGMP Snooping a siwtch azon tulajdonsága, amely segítségével meg tudja állapítani, hogy adott multicast MAC címek mely portokon jelennek meg, így az oda irányuló forgalmat oda, és csak oda kapcsolja. IGMP snooping hiányában a forgalom a switch minden portján megjelenne, a switch flooding pedig ugyanúgy sávszél-szűköt okoz(hat).

No, ez tehát az elmélet, és most már látható, hogy az IGMP Snooping a számunkra kívánatos funkció, amit ez esetben kunyerálással lehet összehozni. Felhivtuk sorra a partnereinket, elmeséltük nekik a problémánkat,, végül kértünk egy olyan switchet tőlük kölcsönbe, amely az alábbiakat tudja: legalább 24 portos, van GBIC-es gigabit linkje és tud IGMP Snoopingot.

Első szállító hamar kiesett, neki nem volt kéznél gigabitet is tudó switch-e. A második, Varánusz bácsitól kölcsönzött kifejezéssel „kosárlabdacsapatos” szállító már bíztatott minket, de aztán kiderült, hogy nekik csak egy 3524-es eszközük van, pont olyan, mint a miénk, az pedig híján van ennek a kívánt tulajdonságnak. Végül az LNX segített rajtunk, de csak szerdára tudták leszállítani az eszközt (ezúton is köszönet nekik!). Hétfőn egyetlen esélyünk maradt, az unicastos-kétkártyás megoldás. Mivel ez leállással nem járt, ezért délután nekiálltunk a konfigurálásnak. Kudarcot vallottunk. Bár a routing tábla tökéletes volt, a noetwork monitor szépen jelezte, hogy bizony a bejövő forgalom és a kimenő forgalom ugyanazon a kártyán valósul meg. Ha hétvége lett volna, akkor tovább küzdünk, de hét közben a dolgot hamar feladtuk. Jöjjön az a switch.

Szerdára megérkezett, elrendeltük a rendkívüli leállást és délután 5-kor nekiveselkedtünk a dolognak. Már a switch beállítása sem volt piskóta, mi nem vagyunk CISCO szakmeberek, a gigabites interfészek meg nem akarták ismerni egymást. Egy kis LNX segítséggel ezen átvergődtuünk, jöhetett az IGMP Snooping. Beállítottuk, és az NLBS multicastra módosítása után meg is jelentek a megfelelő porton a megfelelő MAC címek. a WAN szolgáltatónk elvégezte a router konfigurációját is, jöhetett a tesztelés. Jött is, akár a betonfal. Ha szabad a router gazdájától kölcsönzött kifejezéssel élnem, horrorisztikus volt, amit láttunk. LAN-on belül a multicast és az IGMP Snooping úgy működött, ahogy a nagy könyvben megírták, de a router megbolondult.  Hiába  véstük be kézzel a MAC-IP cím párost, ő bizony a multicast címet cím helyett uincast címre cserélte a csomag cél MAC címét, amit aztán már tényleg csak egy node kapott meg. Mivel azonban az NLBS algoritmus szerint néha nem egyik, hanem egy másik szervert kellett volna elérni, az ilyen esetekben a csomagokat a kiszolgáló eldobta. Lepattantunk a feladatról. Úgy fél hétig próbálkoztunk, aztán feladtuk ismét, a sávszélesség bővítését – egyelőre – fel kellett adnunk. Másnap a felhasználók persze jelezték, hogy „hiába javítottunk a helyzeten, nekik még mindig rossz a rendszer”.

A harmadik puskagolyónk a vékonykliensek image frissítése volt. A HP ehhez nem saját szoftvert fejlesztett, hanem „szövetséget kötött” az Altirisszel, amely a Deployment Server-ét tette alkalmassá a HP gépek menedzselésére. Nos, ez nem egyszerű történtet, nyűglődtem vele hétfőtől csütörtökig. A Deployment szerver telepítésére a saját menedzsment kiszolgálónkat szemeltem ki, ezzel rögtön válaszút elé is állítottam magam. Az Altiris ugyanis feldob egy PXE szervert, amely funkció üti a Microsoft RIS-t. Hmm. Előbb kihagytam a PXE telepítést, viszont feltettem a nagyon-nagyon ajánlott hotfixet, amelytől a 6.0-s szoftverem rögtön 6.5-ös lett. Utólag, a súgó nézegetésével rájöttem, hogy a PXE megkerülhetetlen komponens. Feltettem és közben lekapcsoltam a TFTP-t és a RIS-t. Az Altirises PXE persze cseszett elindulni. Google és egyéb reszelések után azt gondoltam, hogy Reapply patch. Ez bejött. Volt már PXE kiszolgálóm, csak most meg operációs rendszerem nem volt, pontosabban egy olyan image, amelyet a PXE betöltött volna. Külön le kellett vadásznom a FreeDOS-t az Altiris weblapjáról (jól eldugták) és beapplikálnom a PXE konfigjába. Még így sem akart menni az a frissítés. Ekkor gondoltam egy nagyot és hagytam az egészet a fenébe. A letöltött HP image kicsomagolója felajánlotta azt is, hogy az egészet holmit kiírja egy USB kulcsra, hogy aztán kézzel ezt csináljunk a vékonykliensekkel, amit akarunk. Kiírattam a kulcsra az anyagot, 249 MB lett. (Ezt kellene 22x leküldeni egy 512K-s vonalon, vagy beizzítani az Altiris multicast alapú deploymentjét. Multicast – kezdek begurulni!!)

No előkaptam egy még ki nem osztott klienst és megfrissítettem. 3 perc. Elfelejtett ugyan mindent, cserébe egy fürgébb és okosabb verziót kaptam. Korábban a rdesktop tuningolása abból állt, hogy megadhatta, kérek-e bitmap caching-et. Most viszont épp olyan alapos beállítási lehetőségem keletkeztek, mint egy Windows XP kliens esetén. Pikkpakk összevarázsoltam a saját kívánalmaim szerinti kapcsolatot. És hurrá, megjelentek a bginfo feliratok, és végre feldobhattam a futófényt is, amit a felhasználók úgy hiányoltak. Csütörtök délután volt – pénteken irány a MALKER.

Folytatom…

2 Responses to TS átállás – VI.

  1. Berta Krisztián says:

    Tamás, az istennek nem akar eszembejutni, mit is érthettem akkor a kosárlabdacsapatouzás alatt…

  2. Tamas says:

    Ezt nem te mondtad. Azt szerettem volna kifejezni (azt akarta mondani a költő :-)))), hogy "ha ezt te mondanád, akkor úgy mondanád, hogy". Szóval nem mondtál ilyet, hogy "kosárlabdacsapatos" szállító, de ha azt a cégnevet nem szeretnék kimondani, de valahogy mégis utalnál rá, akkor én úgy képzelem, hogy te valami ilyesmit mondtál volna.
     
    Na most akkor a fenti négy sort tömörítettem az eredeti szövegben. :-))

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: