Virtlab:Aktivační server

Z VirtlabWiki

(Rozdíly mezi verzemi)
Přejít na: navigace, hledání
Verze z 19:35, 18. 10. 2007
Vav166 (Diskuse | příspěvky)

← Předchozí porovnání
Aktuální verze
Gry72 (Diskuse | příspěvky)

Řádka 1: Řádka 1:
[[Activator-script]] [[Activator-script]]
 +
[[VLANstore]] [[VLANstore]]
-[[Kategorie:Komponenty virtlabu]]+[[Virtlab:Komponenty/Rozdělení rezervačního a aktivačního serveru]]
-[[Kategorie:Server]]+ 
-[[Kategorie:Aktivační server]]+'''AKTIVAČNÍ SERVER JE MRTEV, RIPv1 (30. CERVENCE - 4. LISTOPADU 2007)'''
-[[Kategorie:UNCOMPLETE]]+ 
 +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.'''
 + 
 +== Komunikační protokol aktivačního serveru ==
 +[[Virtlab:Protokoly/Aktivační server]]
 + 
 +[[Kategorie:OBSOLETE]]

Aktuální verze

Activator-script

VLANstore

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.

Komunikační protokol aktivačního serveru

Virtlab:Protokoly/Aktivační server

Osobní nástroje