Virtlab:Aktivační server
Z VirtlabWiki
| Verze z 06:19, 25. 10. 2007 Gry72 (Diskuse | příspěvky) ← Předchozí porovnání |
Aktuální verze Gry72 (Diskuse | příspěvky) |
||
| Řádka 5: | Řádka 5: | ||
| [[Virtlab:Komponenty/Rozdělení rezervačního a aktivačního serveru]] | [[Virtlab:Komponenty/Rozdělení rezervačního a aktivačního serveru]] | ||
| + | '''AKTIVAČNÍ SERVER JE MRTEV, RIPv1 (30. CERVENCE - 4. LISTOPADU 2007)''' | ||
| - | === Princip wrapperu pro hlídání timeoutu běhu aktivačního skriptu === | + | Závěť naleznete na stránce [[Virtlab:Komponenty/Náhrada aktivačního serveru]]. |
| - | 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). | ||
| + | === Procesy === | ||
| + | * Původní proces, resp. thready v rámci něj: Obsluha TCP spojení klientů | ||
| + | * Dětský proces (watch process): Hlídání časů aktivací (spouští další dětské procesy - wrappery pro aktivační skript, viz | ||
| + | níže). | ||
| - | '''Toto řešená není optimální, pro běžnou větší zátěž potřebujeme míž možnost plně paralelní aktivace konfigurací.''' | + | V případě přijetí příkazu RELOAD žádá původní proces svůj dětský o znovunačtení databáze signálem SIGUSR1. |
| + | |||
| + | === 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, počkáme na uvolnění globálního semaforu indikujícího, že jiná instance aktivačního skriptu už neběží, 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). | ||
| - | === V BUDOUCNU NUTNO PREDELAT GENERATOR A UPLOADER TAK, ABY BYLO REENTRANTNI === | + | '''Toto řešená není optimální, pro běžnou větší zátěž potřebujeme míž možnost plně paralelní aktivace konfigurací.''' BUDOUCNU PROTO 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). | 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í). | + | Přepsání je 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í). |
| - | ''' | + | |
| + | '''Vzhledem k plánovanému přechodu na jinou architekturu spojovače s pevnou konfigurací přepínačů a nahrazením ASSSK převodníky Serial-Ethernet se přechodem problém vyřeší - současný generátor konfigurací na bázi tunelovaných VLAN zanikne.''' | ||
| + | == Komunikační protokol aktivačního serveru == | ||
| + | [[Virtlab:Protokoly/Aktivační server]] | ||
| - | [[Kategorie:Komponenty virtlabu]] | + | [[Kategorie:OBSOLETE]] |
| - | [[Kategorie:Server]] | + | |
| - | [[Kategorie:Aktivační server]] | + | |
| - | [[Kategorie:UNCOMPLETE]] | + | |
Aktuální verze
Virtlab:Komponenty/Rozdělení rezervačního a aktivačního serveru
AKTIVAČNÍ SERVER JE MRTEV, RIPv1 (30. CERVENCE - 4. LISTOPADU 2007)
Závěť naleznete na stránce Virtlab:Komponenty/Náhrada aktivačního serveru.
Procesy
- Původní proces, resp. thready v rámci něj: Obsluha TCP spojení klientů
- Dětský proces (watch process): Hlídání časů aktivací (spouští další dětské procesy - wrappery pro aktivační skript, viz
níže).
V případě přijetí příkazu RELOAD žádá původní proces svůj dětský o znovunačtení databáze signálem SIGUSR1.
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, počkáme na uvolnění globálního semaforu indikujícího, že jiná instance aktivačního skriptu už neběží, 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í. BUDOUCNU PROTO 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í je 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í).
Vzhledem k plánovanému přechodu na jinou architekturu spojovače s pevnou konfigurací přepínačů a nahrazením ASSSK převodníky Serial-Ethernet se přechodem problém vyřeší - současný generátor konfigurací na bázi tunelovaných VLAN zanikne.
