Propojení systému Virtlab s cizími systémy
Z VirtlabWiki
| Verze z 06:57, 11. 8. 2009 Gry72 (Diskuse | příspěvky) ← Předchozí porovnání |
Verze z 14:27, 23. 8. 2009 Gry72 (Diskuse | příspěvky) Následující porovnání → |
||
| Řádka 1: | Řádka 1: | ||
| + | == Integrace s BGP modulem systému Edinet == | ||
| + | |||
| + | Integrace metodou začlenění externího systému enkapsulovaného jako pseudozařízení DO Virtlabu. Kooperace mezi rezervačními systémy. | ||
| + | |||
| == Interfacing s cizími systémy == | == Interfacing s cizími systémy == | ||
Verze z 14:27, 23. 8. 2009
Obsah |
Integrace s BGP modulem systému Edinet
Integrace metodou začlenění externího systému enkapsulovaného jako pseudozařízení DO Virtlabu. Kooperace mezi rezervačními systémy.
Interfacing s cizími systémy
Zde diskutujeme integraci s cizími systémy, které nemají charakter množiny volně dostupných a na požádání vzájemně kombinovatelných prvků, dostupných přes společné (vnější) rozhraní našeho standardního tunelovacího a konzolového serveru, mazatelné mazacím serverem a individuálně rezervovatelné našim rezervačním serverem (všechny zmíněné servery v instalovány v cizí lokalitě a dále napojeny, popř. vnitřně upraveny podle potřeb daného cizího systému).
Pro řízení na logické úrovni můžeme použít (do cizích lokalit implementovat) SOAP API řídících serverů lokalit
Typy/charakter systémů, které můžeme potenciálně chtít integrovat
- Systém s neměnnou topologií složený složený z více samostatných síťových prvků
- může být plně izolovaný nebo mít definována síťová rozhraní, jimiž se bude propojovat s dalšími částmi distribuované laboratorní topologie (chovat se jako enkapsulovaná entita s několika rozhraními)
- ... co ještě ?
Definovat zacházení s typy rozhraní (L2 rámců), o nichž nemáme zatím potuchy (umíme jen interface typu Ethernet a Serial)
- Mapovací alg. zatím chápe jako propojitelné rozhraní "stejného typu" (máme Serial a Ethernet). Tunelovací servery kompatibilitu neřeši, pošlou rámec tam, kam jsou nakonfigurovány. Tím se mohou na rozhraní při nevhodné konfiguraci dostávat i nesprávné typy rámců (což nevadí).
- Možná "vyčistit" definici typu rozhraní ne na Ethernet/Serial, ale podle typu rámce - linkového protokolu, OSI RM L2 (L1 rozhraní neřešit, je enkapsulována za tunelovacím serverem)
- Při tom vzít v úvahu Serial porty na způsob Cisco směrovačů, které umí několik typů rámců - rozhraní tedy definovat výčtem L2 protokolů, které umí
Implementace proxy tunserveru na hranici cizího systému, který se bude jevit jako standardní lokalita. Proxy tunserver bude směrem do Internetu (k ostatním lokalitám Virtlabu) používat standardní Virtlabovou UDP enkapsulaci, pro směr do cizího systému jeho vlastní,
Příklad integrace pro systém s fixní topologií:
Zavedeme speciální typ prvku, který bude obalovat celou cizí topologii s interfacy, která topologie poskytuje ven. V konfiguraci definujeme, že tento prvek je 1x k dispozici v lokalitě cizího systému. S tímto prvkem pak budeme v logických topologiích normálně pracovat a mapovat jej na tuto jedinou jeho instanci. Toto neřeší problém přístupu na konzoly jednotlivých prvků cizí topologie (kompozitní prvek by měl jen jednu konzoli jako každý jiný prvek). Šlo by řešit proxy konzolovým serverem, který by po přihlášení dovolil výběr konzoly konkrétního prvku (menu + rozvětvení).
