Virtlab:Komponenty/Virtuální spojovací pole
Z VirtlabWiki
| Verze z 17:02, 21. 10. 2007 Gry72 (Diskuse | příspěvky) ← Předchozí porovnání |
Verze z 17:03, 21. 10. 2007 Gry72 (Diskuse | příspěvky) Následující porovnání → |
||
| Řádka 1: | Řádka 1: | ||
| - | Distribuovaní virtuální spojovací pole je distribuovaný spojovací systém založený na lokálním propojování pomocí VLAN a tunelování VLAN (802.1q rámců) pomocí UDP přes volný Internet. Spojování laboratorních síťových prvků v lokalitách se děje jejich zařazováním do stejných VLAN (příp. VLAN tunelů QinQ při spojování trunků) na přepínačích Cisco 3550, tunely přes Internet jsou zajišťovány speciálním softwarem – [[Virtab:Komponenty/Tunelovací_server | tunelovacím serverem]]. Propojování WAN portů se realizuje pomocí k tomu účelu vyvinutých [[Virtlab:ASSSK | hardwarových zařízení]]. | + | Distribuovaní virtuální spojovací pole je distribuovaný spojovací systém založený na lokálním propojování pomocí VLAN a tunelování VLAN (802.1q rámců) pomocí UDP přes volný Internet. Spojování laboratorních síťových prvků v lokalitách se děje jejich zařazováním do stejných VLAN (příp. VLAN tunelů QinQ při spojování trunků) na přepínačích Cisco 3550, tunely přes Internet jsou zajišťovány speciálním softwarem – [[Virtab:Komponenty/Tunelovací_server|tunelovacím serverem]]. Propojování WAN portů se realizuje pomocí k tomu účelu vyvinutých [[Virtlab:ASSSK | hardwarových zařízení]]. |
| ---- | ---- | ||
Verze z 17:03, 21. 10. 2007
Distribuovaní virtuální spojovací pole je distribuovaný spojovací systém založený na lokálním propojování pomocí VLAN a tunelování VLAN (802.1q rámců) pomocí UDP přes volný Internet. Spojování laboratorních síťových prvků v lokalitách se děje jejich zařazováním do stejných VLAN (příp. VLAN tunelů QinQ při spojování trunků) na přepínačích Cisco 3550, tunely přes Internet jsou zajišťovány speciálním softwarem – tunelovacím serverem. Propojování WAN portů se realizuje pomocí k tomu účelu vyvinutých hardwarových zařízení.
Obsah |
Generování a upload konfigurací spojovacích prvků distribuovaného spojovacího pole
Obstarava Aktivacni server. V case nejblizsi rezervace (zjisti z DB nebo je informovan o nove rezervaci rezervacnim serverem pomoci TCP) spusti aktivacni skript podle polozky conf-activator v souboru act-server.conf (implicitne activator-script/activate.sh). Jako parametry se předává čas ukončení dané rezervace a odkaz na soubor s popisem požadované topologie. V nem se nejprve spusti skript generatoru konfiguraci pro spojovaci prvky (ten si po dobu sveho behu spusti VLANstore), nasledne skript pro generovani konfiguraci tunelovacich serveru vsech lokalit a nakonec se vsechny vygenerovane konfigurace pomoci uploadovaciho skriptu zaslou konfiguracnim serverum prislusnych lokalit, ktere je nahraji do zadanych spojovacich prvku. Z aktivačního skriptu se rovněž spouští skript pro výmaz konfigurací laboratorních prvků použitých v dané rezervaci.
Skripty generátoru konfigurací se spouští v domovském adresáři spojovače (/opt/virtlab/opt/virtlab/spojovac), skript uploaderu v adresáři aktivátoru konfigurací (/opt/virtlab/act-server/activator-script) a skript mazače konfigurací laboratorních prvků z /opt/virtlab/act-server/erase-activator. Konfigurace pro spojovací prvky se generují do /opt/virtlab/spojovac/workdir.
Pozor, generátor make-conn-configs přepisuje novými výstupy případné konfigurace z předchozího běhu a také VLANstore se nesmí spustit současně vícekrát. Aktivační server by měl tedy volání skriptu activate.sh serializovat (nesmí se spustit podruhé, než poprvé skončí). Musí se také zajistit sériovost provádění všech dalších skriptů spouštěných z activate.sh, resp. čekání na jejich dokončení, abychom věděli, že activate.sh skutečně dokončil veškerou práci, když skončil.
Serializace je v aktivačním serveru realizována pomocí globálního semaforu hlídajícího spouštění dětských procesů, z nichž se pak spouští aktivační skript. V serializaci je potenciální problém, protože aktivace se může zadrhnout i na dost dlouho (navazování spojení netcatem při uploadu konfigurace spojovacího prvku nebo mazání laboratorního prvku), možná i nekonečně, čímž by se aktivační server zablokoval. Proto se při volání aktivačního skriptu spustí nejprve další pomocný proces (wrapper), který hlídá maximální dobu běhu svého dítěte - procesu aktivačního skriptu (a z něj spuštěných mazacích a uploadovacích skriptů). V případě překročení pevně přednastaveného času celou větev procesů (označenou stejným Process Group) zabije a uvolní semafor.
Princip wrapperu pro hlídání timeoutu běhu aktivačního skriptu
Aktivační server spouští nový proces pro každou aktivaci. My v něm provedeme fork() procesu wrapperu, nastavíme alarm(), nastavíme process group (setpgrp()) na PID wrapper procesu. Z wrapper procesu provedeme fork() dalšího procesu, z něj se execl() spustí aktivační skript. Všechny procesy pod aktivačním skriptem dědí hodnotu process group. Tím je můžeme v případě vypršení časového limitu ze signal handleru pro alarm() wrapper procesu všechny společně zlikvidovat pomocí kill(cela process group), Předpokládáme, že tím skončí i proces samotného wrapperu (group leader).
Toto řešená není optimální, pro běžnou větší zátěž potřebujeme míž možnost plně paralelní aktivace konfigurací.
V BUDOUCNU NUTNO PREDELAT GENERATOR A UPLOADER TAK, ABY BYLO REENTRANTNI
Nejlépe tak, že bude generovat konfigurační soubory spojovacích prvků do zvláštních adresářů podle PID generátoru konfigurace. Z nich si je pak budou brát uploader a mazač konfigurací. Úzkým místem stále bude VLANstore, ale interakce s ním je krátká (pokud se nic nezacyklí chybou skriptu make-conn-configs). Pro realizaci kritické sekce pro komunikaci s VLANStore bashi potřebujeme mutex. Možná realizace v Bashi viz Nápověda a HOWTOs, Linuxové okénko. Skripty generátoru konfigurací by už stejně bylo vhodné přepsat do rozumnějšího jazyka, než Bash (asi C).
Přepsání docela důležité, protože úplná serializace generování a uploadu konfigurací není vhodná - upload potenciálně může trvat dlouho (ikdyž se bufferuje přes konfigurační servery, takže např. povinné meziznakové prodlevy při konfiguraci Bazmeku to neovlivní).
Návaznosti
Rezervační server přijme popis požadované topologie (a.k.a. "topologie.conf") přiřazený ke konkrétní rezervaci příkazem ATTACH. Uloží si jej do souboru <RESID>.dat (z historických důvodů). Soubor rovnou přepošle dále aktivačními serveru a u sebe smaže, aktivační server topologii ukládá do svého souboru <RESID>.dat.
Skript aktivátoru konfigurací spouštěný v době spuštění úlohy (začátku jejího timeslotu) aktivačním serverem se určuje v souboru /etc/virtlab/act-server.conf položkou conf-activator (implicitně /opt/virtlab/act-server/activator-script/activate.sh)
Souboru <RESID>.dat maže
- skript aktivátoru konfigurace po provedení aktivace
- při CANCEL rezervace aktivační server (rezervační příkaz CANCEL přepošle aktivačnímu).
Aktivačnímu skriptu activate.sh předává aktivační server tyto parametry:
- čas konce timeslotu rezervace (v jednotkách funkce time() ) - přeposílá se při žádosti o číslo VLAN na vlanstore.
- jméno souboru s rezervací (bez cesty - aktivační server vytváří ve svém current adresáři)
Komunikace mezi generátorem konfigurací a vlanstore
Vlanstore dočasně zapůjčuje čísla VLAN z rozsahu přiděleného lokalitě (skript activate.sh, proměnné VLANS_FROM a VLANS_TO).
Komunikace probíhá pomocí named pipes:
- /opt/virtlab/vlanstore/npToVlanStore - žádosti o čísla VLAN (vždy s určením konce timeslotu rezervace)
- /opt/virtlab/vlanstore/npFromVlanStore - odpovědi, přidělená čísla VLAN.
Konfigurace
- activate.sh: Upravit VLANS_FROM a VLANS_TO, aby určovaly dolní a horní mez rozsahu čísel VLAN přidělených pro účely spojování prvků místní lokalitě. Nesmí se překrývat s rozsahem žádné jiné lokality.
