Raport dotyczący przeprowadzonych zmian w aplikacji

Transkrypt

1 Łukasz Dobrodziej Warszawa, Jakub Madkowiak Raport dotyczący przeprowadzonych zmian w aplikacji Optymalizacja wydajnościowa Operacjami wykazującymi znaczący czas wykonywania się są grupowe operacje SNMP: odświeżanie wizualizacji i weryfikacja konfiguracji. Do tej pory, były one realizowane poprzez sekwencyjne wykonywanie zapytao SNMP. Wprowadzenie wielowątkowego wykonywania zapytao SNMP pozwoliło osiągnąd dużo lepszą wydajnośd wykonywania ww. operacji. Równoległe wykonywanie zapytao SNMP znacznie skraca czas oczekiwania na odświeżenie wizualizacji i weryfikacje konfiguracji, co przekłada się na poprawie komfortu pracy z aplikacją. 1. Odświeżanie wizualizacji. Dla każdego routera pobierane są dane wymagane do wizualizacji (stan interfejsów, przydzielone adresy IP, numery ASN). Odświeżenie występuje w chwili użycia przycisku Odśwież. Dotychczasowa złożonośd obliczeniowa: Złożonośd tego działania jest klasy: Ө (N * P), gdzie N liczba routerów, P liczba zapytao wymagana do pobrania podstawowej konfiguracji jednego routera Obecna złożonośd obliczeniowa: Złożonośd tego działania jest klasy: Ө (P) Skrócenie czasu dla przykładowego laboratorium: Przed zmianą: 5 s Po zmianie: 1,5 s Uniezależnienie czasu wykonywania tego działania od liczby routerów gwarantuje skalowalnośd aplikacji i pozwala na przeprowadzanie przy jej użyciu bardziej skomplikowanych scenariuszy laboratoryjnych. Dodatkową korzyścią jest skrócenie czasu zawieszenia aplikacji w przypadku, gdy

2 istnieją problemy z komunikacją SNMP (wówczas czas wykonywania zapytania jest równy wartości parametru timeout, ustawionej dla konkretnego typu zapytania SNMP). 2. Weryfikacja wykonania laboratorium. Dla każdego routera wykonywane są zapytania potrzebne do przeprowadzenia testów, które mają na celu sprawdzenie poprawności konfiguracji. Weryfikacja występuje w chwili użycia przycisku Verify. Dotychczasowa złożonośd obliczeniowa: Złożonośd tego działania wynosi: (x) (i) T xi,gdzie T xi złożonośd i tego testu dla routera x. Obecna złożonośd obliczeniowa: Złożonośd tego działania wynosi: max (x, i) (T xi ), gdzie T xi złożonośd i tego testu dla routera x. Skrócenie czasu dla przykładowego laboratorium: Przed zmianą: 40 s Po zmianie: 3 s Uniezależnienie złożoności tego działania od liczby routerów i od liczby testów na routerze daje w efekcie znaczny zysk wydajności czasowej. Obecna złożonośd czasowa, zależna wyłącznie od czasu wykonania najdłuższego sprawdzenia SNMP, zapewnia, że rozwiązanie będzie bardzo wydajne dla wszystkich scenariuszy laboratoryjnych. Przebudowa struktury klas Konieczną zmianą przed wprowadzaniem zmian funkcjonalnych do aplikacji było uporządkowanie struktury klas. W poprzedniej wersji programu, znacząca większośd logiki aplikacji była zawarta w klasie MainWindow. Rozbudowane panele np. prezentujący wizualizację scenariusza laboratoryjnego, panel zawierający drzewo MIB, konsola, panele informacyjne i funkcjonalne (RouterInfo, InterfaceInfo, Traceroute, SNMPInfo), były częścią klasy MainWindow. Naszym pomysłem było wyniesienie paneli do osobnych klas dziedziczących po klasie Panel. Dzięki temu zabiegowi znacząco zmniejszyła się objętośd klasy głównej MainWindow, a funkcjonalności związane z działaniami w obrębie danego panelu są pogrupowane w oddzielnych klasach. Z powodu podobieostwa paneli informacyjnych/funkcjonalnych, pod względem ich reprezentacji w graficznym interfejsie użytkownika i przeznaczenia, powstał pomysł utworzenia klas FunctionalPanel i FunctionalRow. Wszystkie panele informacyjne i funkcjonalne są teraz obiektami klasy FunctionalPanel agregującymi obiekty klasy FunctionalRow. Panele te są tworzone dynamicznie, mogą zawierad dowolną ilośd wierszy (obiekty klasy FunctionalRow), w których umieszczane są kontrolki w postaci przycisków, pól tekstowych i pól edytowalnych. Podstawową korzyścią wynikającą z istnienia klas FunctionalPanel i FunctionalRow, jest możliwośd łatwego tworzenia nowych paneli, które będą musiały powstawad w celu obsługi przez program innych protokołów niż przewidziane w pierwszej wersji aplikacji. Kolejnym udogodnieniem, jest brak konieczności umieszczania kontrolek i paneli ręcznie (z poziomu GUI Designer). Obecnie panele FunctionalPanel są wdokowane w ustawione statycznie panele. Obecną struktura klas reprezentuje poniższy rysunek. Na rysunku wyróżniono nowoutworzone klasy.

3 Rys. 1. Diagram klas Interfejs graficzny obecnej wersji aplikacji został zaprezentowany na Rys. 2. Zaznaczono i opisano na nim wydzielone do osobnych klas panele. Na zrzucie ekranu widoczny jest również nowopowstały panel funkcjonalny ScenarioPanel służący do wczytywania i zapisywania scenariuszy laboratoryjnych bez konieczności ponownego uruchomienia/kompilacji programu. Rys. 2. Interfejs graficzny aplikacji

4 Format danych wejściowych Aplikacja wczytuje z pliku następujące dane wejściowe: Topologię sieci wykorzystanej w laboratorium (routery oraz łącza), informacje potrzebne do komunikacji z routerami przez telnet i SNMP, nazwy oraz współrzędne routerów wykorzystywane w wizualizacji scenariusza, definicje testów do weryfikacji przeprowadzonej konfiguracji. W poprzedniej wersji aplikacji wszystkie powyższe informacje były zapisane w jednym pliku, który był jednocześnie plikiem wejściowym definiującym scenariusz dla emulatora Dynamips (plik z rozszerzeniem.net). Informacje dodatkowe niezgodne ze składnią emulatora umieszczane były za znakami komentarza. Aby uporządkowad dane wejściowe i umożliwid ich łatwiejsza edycję dokonaliśmy podziału danych na plik.net definiujący scenariusz przeznaczony wyłącznie dla emulatora Dynamips oraz plik.xml zawierający wszystkie niezbędne informacje przeznaczone dla aplikacji. Z powyższymi zmianami wiąże się możliwośd wczytywania scenariuszy (zarówno w formacie.xml jak i.net) w trakcie pracy aplikacji, a także możliwośd eksportowania danych do formatu.xml. 1. Plik wejściowy emulatora Plik z rozszerzeniem.net zawiera wyłącznie informacje interpretowane przez emulator i nie jest potrzebny do uruchomienia aplikacji. Zawiera definicje emulowanych routerów oraz połączeo. Po dokonaniu eksportu konfiguracji przechowuje również konfiguracje routerów. Poniżej przedstawiony jest przykładowy plik z zapisem scenariusza laboratorium przeznaczony dla emulatora Dynamips: [localhost] [[7200]] image = \Program Files\Dynamips\images\c7200-jk9o3s-mz.124-7a.image npe = npe-400 ram = 160 [[ROUTER R1]] s1/0 = R2 s1/0 s1/1 = R3 s1/1 f0/0 = SW1 1 configuration = IQp2ZXJzaW9uIDEyLjQKc2VydmljZSB0a( ) [[ROUTER R2]] s1/1 = R4 s1/1 f0/0 = SW1 3 configuration = IQp2ZXJzaW9uIDEyLjQKc2VydmljZSB0a( ) [[ROUTER R3]] s1/0 = R4 s1/0 f0/0 = SW1 4 configuration = IQp2ZXJzaW9uIDEyLjQKc2VydmljZSB0a( ) [[ROUTER R4]] f0/0 = SW1 5

5 configuration = IQp2ZXJzaW9uIDEyLjQKc2VydmljZSB0a( ) [[ethsw SW1]] 1 = access 1 2 = access 1 NIO_gen_eth:\Device\NPF_{9D3FA9E6-AEC5-46CD D9126} 3 = access 1 4 = access 1 5 = access 1 2. Plik wejściowy aplikacji Plik z rozszerzeniem.xml przechowuje informacje wymagane do działania aplikacji. Składnia XML pozwala na łatwą edycję danych, co jest szczególnie ważne przy definiowaniu testów wykorzystywanych do weryfikacji dwiczenia. Podczas tworzenia nowego scenariusza można posłużyd się dowolnym edytorem plików.xml, aby uprościd dodawanie nowych testów i wypełnianie wartości atrybutów. Poniżej przedstawiono przykładowy plik wejściowy aplikacji: Rys. 3. Plik wejściowy aplikacji w formacie XML Plik rozpoczyna się podstawowymi informacjami dotyczącymi scenariusza laboratoryjnego. Podane są nazwa, wersja, autorzy, data powstania oraz opis laboratorium. Następnie opisane są routery wchodzące w skład sieci laboratoryjnej. Każdy router charakteryzowany jest przez swoją nazwę, współrzędne X i Y określające położenie routera na wizualizacji oraz informacje potrzebne do komunikacji z danym routerem z wykorzystaniem protokołów telnet i SNMP (adres IP interfejsu

6 routera wykorzystywanego do komunikacji, port SNMP, community oraz port telnet). Każdy router zawiera dwie listy: Lista łączy. Każde łącze zdefiniowane jest przez interfejs danego routera oraz adres IP i interfejs routera do którego prowadzi łącze. Lista testów weryfikacyjnych. Test określany jest przez nazwę, obiekt, na którym jest wykonywany (router lub interfejs), typ zapytania SNMP (get lub gettable), identyfikator OID oraz opis testu. Test zawiera również listę sprawdzanych par: numer atrybutu - oczekiwana wartośd (w przypadku tabel numery atrybutu są numerami kolumn). 3. Opcja zapisu/odczytu Plik wejściowy aplikacji zawiera częśd informacji zawartych w pliku wejściowym emulatora Dynamips (routery, nazwy routerów, łącza). Aby uprościd proces generowania pliku.xml dostępna jest opcja wczytania pliku wejściowego emulatora.net (z samym scenariuszem lub według dawnej składni z informacjami dodatkowymi w formie komentarzy) oraz zapisu wczytanych informacji do pliku.xml zgodnego z nową konwencją. Dzięki temu po zdefiniowaniu scenariusza laboratoryjnego dla emulatora Dynamips możemy w prosty sposób uzyskad szkielet pliku zawierający podstawowe informacje przeznaczone dla aplikacji. Do aplikacji dodano również panel pozwalający na wielokrotne wczytywanie plików wejściowych różnych scenariuszy (z formatu.xml lub dawnego wzbogaconego.net) bez konieczności ponownego uruchamiania aplikacji.