Opracowanie - Instytut Łączności

Transkrypt

Zakład Zaawansowanych Technik Informacyjnych Z-6
Zarządzanie usługami informatycznymi oraz
infrastrukturą informatyczną
(Z6)06.30.002.6
(OI)07.30.002.6
(Z2)02.30.007.6
Warszawa 2006 – 12 – 13
Zarządzanie usługami informatycznymi oraz infrastrukturą informatyczną
Zarządzanie umowami Service Level Agreement
Praca nr 06.30.002.6, 07.30.002.6, 08.30.002.6
Słowa kluczowe (maksimum 5 słów): SLA SNMP zarządzanie usługi
Kierownik pracy: dr inż. Janusz Granat
Wykonawcy pracy: mgr inż. Michał Majdan
mgr inż. Jerzy Paczocha
mgr inż. Wojciech Pietroń
dr inż. Waldemar Szczęsny
mgr inż. Grzegorz Wójcik
Kierownik Zakładu: inż. dr inż. Janusz Granat
© Copyright by Instytut Łączności, Warszawa 2006
4
Spis Treści
1.
2.
3.
Wstęp.................................................................................................................................. 4
Zarządzanie SLA................................................................................................................ 4
Określanie kosztów usług................................................................................................... 5
3.1.
Przyjęta metodyka ...................................................................................................... 6
3.2.
Założenia dla potrzeb określenia parametrów infrastruktury teleinformatycznej...... 7
3.3.
Analiza SWOT wariantów realizacji i eksploatacji ................................................... 7
3.4.
Składowe elementy infrastruktury ............................................................................. 9
3.5.
Oszacowanie przepustowości łącza do Internetu ..................................................... 11
3.6.
Oszacowanie kosztów instalacji i eksploatacji......................................................... 11
3.7.
Parametry odnoszące się do usług i aplikacji........................................................... 13
3.8.
Koszty, a SLA .......................................................................................................... 15
4. Monitorowanie parametrów usług ................................................................................... 15
4.1.
Systemy zarządzania w pomiarze parametrów SLA................................................ 15
4.2.
Architektura systemu zarządzania............................................................................ 16
4.3.
Simple Network Management Protocol ................................................................... 16
4.4.
Management Information Base ................................................................................ 17
4.5.
Remote Network Monitoring ................................................................................... 19
4.6.
Inne protokoły zarządzania siecią ............................................................................ 20
5. Modele naliczania kar za niedotrzymanie SLA ............................................................... 20
6. Koncepcja rozwiązania .................................................................................................... 21
6.1.
Model Danych .......................................................................................................... 21
6.2.
Architektura zasilania bazy danych.......................................................................... 25
Wyładowanie danych ....................................................................................................... 25
Pobieranie wartości parametrów ...................................................................................... 26
Ładowanie wartości parametrów ..................................................................................... 26
Pobieranie danych umów SLA......................................................................................... 26
6.3.
Specyfikacja aplikacji do zarządzania umowami..................................................... 26
6.3.1.
Definicja umowy .................................................................................................. 27
6.3.2.
Monitorowanie wykonania umowy...................................................................... 30
6.3.3.
Struktura statyczna systemu ................................................................................. 31
6.3.4.
Dynamiczne aspekty systemu .............................................................................. 34
7. Realizacja ......................................................................................................................... 37
7.1.
Wyładowanie danych z systemów źródłowych ....................................................... 37
7.1.1.
Kryteria wyboru parametrów ............................................................................... 38
7.1.2.
Przykładowe parametry wykorzystywane na potrzeby systemu.......................... 38
7.1.3.
System pobierania danych z baz cyklicznych ...................................................... 39
7.1.4.
Środowisko pracy................................................................................................. 39
7.2.
Ładowanie danych do bazy danych systemu. .......................................................... 39
8. Wnioski ............................................................................................................................ 40
3
1. Wstęp
SLA (Service Level Agrement) jest to umowa formalizująca związek pomiędzy dostawcą a
odbiorcą usługi informatycznej, mająca formę kontraktu z wynegocjowanymi wartościami
poziomów utrzymania i wykorzystania usług w stosunku do których podejmowane jest
zobowiązanie. Umowa dodatkowo precyzuje konsekwencje niedotrzymania warunków
umowy, najczęściej w postaci kar umownych powiązanych z wynegocjowanymi wartościami
parametrów utrzymania usługi.
Poziom utrzymania usługi – zestaw parametrów oraz ich wartości maksymalnych i
minimalnych za pomocą których strony SLA określają stopień spełnienia przez dostawcę
uzgodnionych warunków.
Poziom wykorzystania usługi - zestaw parametrów oraz ich wartości maksymalnych i
minimalnych za pomocą których strony SLA określają stopień wykorzystania usługi przez
odbiorcę do którego zobowiązał się on w ramach uzgodnionych warunków umowy.
Parametr utrzymania – wielkość związana z działaniem usługi na podstawie której
mierzona jest jakość zapewnienia funkcjonowania usługi przez jej dostawcę (np. dostępność
serwera).
Parametr wykorzystania - wielkość związana z działaniem usługi na podstawie której
mierzony jest stopień wykorzystania usługi przez jej odbiorcę.
Administrator usługi - osoba ze strony dostawcy odpowiedzialna za dotrzymania
postanowień umowy SLA
Właściciel usługi – osoba ze strony odbiorcy odpowiedzialna za dotrzymanie postanowień
umowy SLA.
Celem niniejszego opracowania jest projekt systemu wspomagającego osoby
odpowiedzialne za zapewnienie przestrzegania umów SLA w organizacji w procesie
monitorowania wykonania warunków umowy. Zadaniem systemu jest gromadzenie informacji
o statusie monitorowanych usługi i udostępnianie tej informacji odbiorcy. Projektowany
system jest hurtownią danych w której w sensie logicznym można wydzielić dwa elementy:
• Obiekty gromadzące informację o określonych parametrach utrzymania i
wykorzystania usług (zasilanie automatycznie z systemów operacyjnych
przedsiębiorstwa)
• Obiekty metadanych przechowujące informacje o przyjętych zobowiązaniach SLA
(zasilane i modyfikowane ręcznie przez operatora)
Jako interfejs użytkownika systemu zostały przewidziane specjalizowane narzędzia
raportowe przeznaczone dla projektowanego systemu w postaci aplikacji WWW.
2. Zarządzanie SLA
Umowy Service Level Agrement formalizują związek pomiędzy dostawcą a odbiorcą usługi.
Korzyści z zawarcia takiego zobowiązania są ewidentne dla strony odbiorcy. Posiadanie
umów gwarantujących określony stopień zapewnienie poprawnego funkcjonowania usługi
informatycznej pozwala odbiorcy minimalizować ryzyko funkcjonowania własnej organizacji.
Pozwala na bardziej wiarygodną ocenę tego co odbiorca może otrzymać w ramach środków
finansowych, które przeznacza na wykorzystywane usługi. Układ który jasno precyzuje
związek pomiędzy wartością środków przeznaczanych na zakup usługi a poziomem jej
świadczenia pozwala odbiorcy sterować kosztami i jakością w miarę jak zmieniają się cele i
priorytety jego organizacji.
4
Dla dostawcy usługi posiadanie umów SLA jest korzystne ponieważ jasno określa to
odpowiedzialność dostawcy i pozwala uniknąć nieporozumień z odbiorcami na tle
oczekiwanego poziomu utrzymania świadczonych usług. Ponadto informacja o poziomach
utrzymania i wykorzystania świadczonych usług jest pomocne w planowaniu rozwoju
infrastruktury, planowaniu zatrudnienia i określania opłacalności utrzymywania określonej
usługi na danym poziomie oraz co za tym idzie ustalania cenników.
Jedną z cech umów SLA jest fakt że precyzują one nie tylko zobowiązania dostawcy ale
również precyzują jakie obowiązki lub ograniczenia w związku z wykorzystaniem usługi ma
jej odbiorca.
Podstawową zaletą SLA dla obydwu stron umowy jest jasne ustalenie zobowiązań, obydwu
stron, które, o ile zostaną dotrzymane,
pozwolą na zapewnienie prawidłowego
funkcjonowania organizacji zarówno odbiorcy jak i i dostawcy usługi.
Nowym czynnikiem jakie umowy SLA wprowadzają w relacje pomiędzy odbiorcami a
dostawcami usług jest aspekt finansowy, który z jednej strony precyzuje koszt usługi dla
odbiorcy a z drugiej strony określa finansowe skutki niedotrzymania postanowień umowy.
Obecność umów SLA w organizacji dostawcy wpływa również na organizacje pracy u
dostawcy, a konkretnie na priorytety planowanych zdań. Z oczywistych przyczyn zgłoszenia
dotyczące awarii usług objętych umowami zyskują wyższy priorytet z racji na grożące
konsekwencje finansowe.
Dla konkretnej usługi możliwe jest zdefiniowanie więcej niż jednej umowy SLA. Każda z tych
umów może ustanawiać różne wartości poziomów utrzymania i wykorzystania usługi.
Możliwe jest również skonstruowanie pojedynczej umowy SLA obejmującej więcej niż jedną
usługę jeżeli strony dojdą do porozumienia co do faktu iż dane grupa usług powinna być
rozpatrywana jako całość.
Prawidłowa umowa SLA powinna precyzować następujące zagadnienia 1
1. Definicję produktu/usługi,
2. Mierniki i metodykę pomiaru jakości utrzymania,
3. Metody komunikacji pomiędzy dostawcą a odbiorcą usługi,
4. Zasady serwisowania,
5. Postanowienia dotyczące postępowania w przypadku naruszenia warunków umowy.
Dla prawidłowej implementacji SLA w relacjach pomiędzy dostawcą o odbiorca usług
konieczne jest zapewnienie wiarygodnej kontroli wykonania warunków umowy przez każdą
ze stron. Z punktu widzenia odbiorcy usługi monitorowane i oceniane jest spełnienie przez
dostawcę założonych poziomów utrzymania. Podstawowym parametrem dla odbiorcy jest
dostępność usługi definiowana jako możliwość korzystania z niej w określonym miejscu, w
określonym czasie i zgodnie z jej specyfikacją zapisaną w umowie. Drugim ważnym
czynnikiem oceny przez odbiorcę wykonania SLA jest obsługa umowy ze strony dostawcy,
kompletność i dokładność pomiarów usługi, dostępność i jakość obsługi odbiorcy, szybkość
reakcji na zgłoszenia.
Z punktu widzenia dostawcy dodatkowo analizowane powinny być koszty produkcji i
utrzymania usługi na założonych w umowach poziomach, oraz koszty kar naliczonych za
niedotrzymanie warunków umowy. Pozwoli to ocenić rentowność każdej z posiadanych
umów. W zależności od wyników takiej analizy dostawca może modyfikować swoje działania
lub w skrajnych przypadkach zdecydować się na zerwanie umowy lub renegocjacje jej
postanowień.
3. Określanie kosztów usług
Analiza kosztów usług obejmuje podstawowe zastosowania teleinformatyczne dla małych
(50 pracowników)i średnich firm (do 250 osób).
1
Integrating Service Level Agreements John J. Lee, Ron Ben-Natan WILEY 2002
5
Obecnie następuje rozwój usług świadczonych drogą sieciową, co nie wymaga od firm
zakupu serwerów i oprogramowania, dysponowania pomieszczeniami do instalacji serwerów
i stosowania procedur eksploatacji dla zapewnienia bezpieczeństwa danych.
Przeprowadzono analizę dla wariantu inwestycyjnego i usługowego dla małej i średniej firmy
dla dwóch wariantów.
Wybrano aplikację teleinformatyczną, które umożliwiają przeprowadzenia analizy z uwagi na
dostępność informacji cenowych dla obu wariantów: inwestycyjnego i usługowego.
Podejmowanie
analiz
ekonomicznych
w
zakresie
wdrożenia
podstawowego
teleinformatycznego wyposażenia jest problemem złożonym, dlatego przyjęto uproszczenia.
W obu wariantach przyjęto, że firma rozpoczyna działalność.
Z punktu widzenia podejmowania decyzji najbardziej istotne będą m.in.:
-
rodzaj wdrażanych aplikacji,
-
zapewnienie funkcjonalności,
-
krótki, efektywny czas wdrożenia,
-
niski koszt eksploatacji,
-
elastyczność rozwiązania,
-
zapewnienie poziomu bezpieczeństwa teleinformatycznego.
3.1.
Przyjęta metodyka
Dla potrzeb analiz kosztów przyjęto następujące założenia:
- warianty wielkości firm: mała 50 pracowników i średnia 250 pracowników
-
wszyscy pracownicy korzystają z usług teleinformatycznych z poczty elektronicznej i
korzystają z zewnętrznych serwerów WWW,
-
zakłada się, że wyposażona jest w sieć LAN (urządzenia pasywne i aktywne) i
wszyscy pracownicy mają dostęp do stacji roboczych.
Firma rozpoczyna działalność niezbędne jest uruchomienie serwisów internetowych i
przeprowadzenia pełnego cyklu wdrożeniowego oraz ponoszenia kosztów eksploatacji.
Wybrano aplikację firmy Microsoft Exchange, która będzie mogła być realizowana na
lokalnym serwerze (wariant inwestycyjny) lub sieciowo (wariant usługowy).
Dla obu wariantów przeprowadzono analizę SWOT w celu podjęcia decyzji o wyborze
wariantu wg cech, które będą dla bieżącej działalności i przyszłości firmy najbardziej istotne.
Określono niezbędne wyposażenie oraz zakres prac:
- dla dołączenia sieci LAN do Internetu,
- dla instalacji serwera Exchange.
Zakłada się, że pomieszczenie do serwera będzie typowym pomieszczeniem biurowym
wymagającym adaptacji.
Dla potrzeb określenia przepustowości połączenia z siecią Internet przyjęto:
- średnie parametry ruchowe występujące w sieci Instytutu Łączności wynikające z
aktywności użytkowników,
- ilości danych oraz parametrów opóźnieniowych dla transakcji danego rodzaju na
podstawie tabeli w zamieszczonej w punkcie Błąd! Nie można odnaleźć źródła
odwołania..
6
3.2.
Założenia dla potrzeb określenia parametrów infrastruktury
teleinformatycznej
Dla określenia rodzaju kosztów przyjęto następujące założenia obejmujące:
1. Obszar eksploatacji:
- małe przedsiębiorstwo do 50 pracowników i średnie 250,
- wszystkie stanowiska pracy znajdują się w jednym obiekcie, brak oddziałów firmy,
- działalność typowa biurowa,
- czas pracy w godzinach stosowany we większości firm 8 godz. np. od 8.00 do 16.00.
2. Wymagania w zakresie bezpieczeństwa teleinformatycznego:
- poziom tajemnicy handlowej – ustalany przez przedsiębiorcę,
- poziom ochrony danych osobowych – nie ma wymagań szczególnych,
- stosowanie typowych rozwiązań – nie wymagane jest dublowanie infrastruktury.
3. Wymagania w zakresie paramentów i jakości usług
Zgodnie z parametrami określonymi w zaleceniu G.1010:
- Web-browsing HTML - ilość danych ~10 KB – opóźnienie akceptowane < 4 s/stronę,
- E-mail (dostęp do serwera)- < 10 KB - opóźnienie akceptowane < 4,
- E-mail (transfer serwer do serwera)- ilość danych <10 KB-opóźnienie do kilku minut.
4. Wymagania ruchowe
Liczba przesyłanych email dla 400 kont dziennie:
- użytkowych 8 tys. – na jednego użytkownika 20 dziennie, (przy pracy 8 godz.) –
0,0007/s
- odbieranego spamu 300 tys. - na jednego użytkownika 750 -(w ciągu doby) - 0,009/s.
Liczba odwołań do serwera przy 200 użytkownikach 5 stron/s – na jednego użytkownika
odwołań 0,025/s.
3.3.
Analiza SWOT wariantów realizacji i eksploatacji
Poniżej przedstawiono analizę SWOT dla dwóch wariantów realizacji usług internetowych:
inwestycyjnego i usługowego.
Przedstawiono mocne, słabe strony oraz szanse i zagrożenia. Decyzja na podstawie analizy
SWOT będzie mogła być możliwa po określeniu rodzaju działalności, sposobu prowadzenia i
przyjętej strategii działania firmy.
Tabela 1 Analiza SWOT wariantów realizacji i eksploatacji
I Wariant
Wariant
Lp.
Inwestycyjny
Sieciowy
7
III
Mocne strony
1.
3.
Szanse
Słabe strony
2.
całkowitych
kosztów
1. Firma posiada kontrolę na swoimi 1. Obniżenie
wykorzystania Microsoft Exchange
danymi
Server
2. Wymiana danych wewnątrz budynku
odbywa się w sieci LAN w ramach 2. Procedury obsługi i archiwizacji
danych
realizowane
przez
obiektu
usługodawcę
3. Mniejsze wymagania w zakresie
opóźnień dla przesyłania mail (transfer 3. Użytkownicy mobilni nie obciążają
łącza dostępowego- korzystny w
serwer do serwera)
przypadku
dużej
mobilności
4. Posiadanie
własnej
infrastruktury
użytkowników
teleinformatycznej
4. Krótki czas wdrożenia
5. Szyfrowanie
transmisji
danych
pomiędzy komputerami użytkowników i
serwerem z wykorzystaniem SSL
6. Eliminacja kosztów, które związane są
z
samodzielnym
wdrożeniem
Exchange Server oraz późniejszym
utrzymaniem i rozwojem środowiska
pocztowego
7. Spam nie obciąża łącza dostępowego
1. Uzależnienie do dostawcy usługi
1. Koszt eksploatacji serwera
2. Koszt pomieszczenia przeznaczonego 2. Funkcjonowanie firmy uzależnione od
łącza dostępu do Internetu
do
instalacji
serwera
i
prac
3. Przesyłanie
poczty
między
adaptacyjnych
pracownikami wewnątrz firmy odbywa
3. Koszty zasilania serwera
się poprzez sieć Internet
4. Koszty instalacji: kontroli dostępu,
przeciwpożarowej, antywłamaniowej i
przeciwpożarowej
pomieszczenia
serwera
5. Duży jednorazowy koszt wdrożenia
6. Konieczność posiadania dużej wiedzy
przez administratora, konieczność
zakupienia wsparcia
7. Mobilni użytkownicy będą obciążali
łącze dostępowe
możliwość
skalowania
1. Posiadana
infrastruktura 1. Prosta
rozwiązania
ze
wzrostem
liczy
teleinformatyczna (serwerownia) oraz
użytkowników
specjalizowany personel może być
wykorzystany do wdrożenia innych
systemów w firmie.
8
Zagrożenia
4.
1. Konieczność zakupu nowego serwera 1. Dostawca usługi może mieć dostęp
do danych
w przypadku zwiększenia potrzeb
2. Zakup nowych wersji oprogramowania 2. Utrudnione wdrażanie następnych
aplikacji wspomagających obsługę
3. Prawidłowość
funkcjonowania
i
firmy w związku z brakiem serwerowni
bezpieczeństwo danych uzależnione
od
pracownika,
administratora 3. Dostawca usługi może wyłączyć
usługę w przypadku konfliktu ze
systemu
zleceniodawcę
4. Dostawca może zawrzeć w umowie
ograniczenie odpowiedzialności np. w
przypadku wystąpienia siły wyższej
5. Zaburzenia funkcjonowania firmy w
przypadku
niewywiązywania
się
dostawcy usług
6. Jakość połączeń uzależniona od
funkcjonowania sieci Internet
3.4.
Składowe elementy infrastruktury
Poniżej przedstawiono w tabeli elementy kładowe infrastruktury teleinformatycznej (sprzętu i
oprogramowania dla obu wariantów inwestycyjnego i usługowego.
Tabela 2 Elementy infrastruktury teleinformatycznej dla wariantów realizacji
Wariant
I Wariant II
Lp. Rodzaj elementu infrastruktury
Uwagi
inwestycyjny usługowy
1.
Sieć LAN (okablowanie, elementy
pasywne i aktywne)
do
lub
inne
TAK
TAK
TAK
2.
Szerokopasmowy
Internetu
3.
Firewall
urządzenie
rozwiązanie
TAK
TAK
4.
Oprogramowanie klienckie Microsoft
TAK
Outlook
TAK
5.
Pomieszczenie serwera
TAK
NIE
6.
Zasilacz UPS do zasilania serwera
TAK
NIE
7.
Komputer serwera
TAK
NIE
8.
Licencja Microsoft Serwer dla
TAK
wymaganej liczby użytkowników
NIE
9.
Serwer dla usług internetowych
(Exchange) dla wymaganej liczby TAK
użytkowników
NIE
Oprogramowanie
serwera
NIE
10.
dostęp
TAK
antywirusowe
TAK
9
Występuje jako
wyposażenie
obiektu,
nie
ujęto
w
analizach
11.
12.
Certyfikat SSL dla bezpiecznego
dostępu przez OWA i RPC over TAK
HTTPS
NIE
Oprogramowanie dla backupu
NIE
TAK
W związku z instalacją serwera niezbędne będą następujące niezbędne elementy:
-
serwerownia – pomieszczenie (wraz z instalacjami i urządzeniami) przeznaczone do
zainstalowania serwera,
-
szafa teleinformatyczna do instalacji serwera i urządzeń sieciowych,
-
sieć LAN – okablowanie strukturalne i urządzenia aktywne dla dołączenia
użytkowników serwera,
-
punkt dostępu do sieci Internet - urządzenia dostępowe: router i urządzenia transmisji
danych,
-
telekomunikacyjna instalacja wewnętrzna budynku
telekomunikacyjnej z pomieszczeniem serwerowni,
-
użytkownicy korzystający z serwera (lokalnie lub zdalnie) połączeni siecią LAN.
dla
połączenia
głowicy
Zakłada się, że lokalizacja pomieszczenia w obiekcie zostanie dobrana zgodnie z
wymaganiami dla potrzeb instalacji sprzętu.
Zakłada się, że dla instalacji serwera potrzebne będą prace adaptacyjne, które mogą
obejmować następujący zakres prac:
-
Budowlane
instalacja drzwi z zamkami w wykonaniu antywłamaniowym,
-
zabezpieczenie przed włamaniem okien,
-
pomalowanie ścian niepylącą farbą,
-
ułożenie gładkiej zmywalnej wykładziny antyelektrostatycznej trudnopalną.
-
Instalacje elektryczne
instalacja tablicy rozdzielczej niskiego napięcia zasilanej z rozdzielni głównej
budynku,
1.
2.
-
instalacja uziemienia technologicznego połączona z głównym punktem uziemienia w
rozdzielni głównej,
-
instalacja zasilacza UPS.
-
Prace związane z okablowaniem
instalacja kabla telekomunikacyjnego w budynku
3.
4.
instalacja punktu dostępu sieci LAN dla dołączenia użytkowników serwera do sieci
LAN
Instalacje bezpieczeństwa
Pomieszczenie serwera należy wyposażyć w instalacje:
-
sygnalizacji pożaru -optyczne czujki dymowe
-
włamania – czułki ruchu
-
kontroli dostępu- zamkiem z ryglem magnetycznym wyzwalanym z czytnika kart
magnetycznych lub chinowych z manipulatorem kodowym
5.
-
Instalacje dla parametry środowiskowych
Instalacja klimatyzatora
10
-
Urządzenie monitorowania środowiska w pomieszczeniu
Jak z powyższego wynika adaptacja pomieszczenia serwera, w zależności od warunków
lokalnych, może obejmować różne rodzaje i zakres prac.
Dla potrzeb analiz mogą jedynie być określone jako kwota ryczałtowa.
3.5.
Oszacowanie przepustowości łącza do Internetu
Oszacowanie przeprowadzono dla wartości średnich biorąc pod uwagę założenia (patrz
punkt 3.2). Biorąc pod uwagę, że oszacowanie wykonano dla wartości średnich i aktualnie
przesyłane strony i email (użytkowe) mają większą pojemność zakłada się przepustowość
kilka razy większą do obliczonej i przybliżeniu do wielości typowych na rynku.
Tabela 3 Oszacowanie przepustowości łącza dostępu do Internetu
LP.
Rodzaj aplikacji
Liczba
Ilość
danych transferów
/s
[bit]
2.
Liczba
użykowników
Web-browsing
HTML
80000
0,025
3.
E-mail (dostęp do
serwera)
80000
0,0007
80000
0,0007
80000
0,009
80000
0,009
1.
4.
5.
E-mail (transfer
serwer do
serwera)
E-mail (dostęp do
serwera) - spam
6.
E-mail (transfer
serwer do
serwera) - spam
7.
Suma
przepustowości
Wariant I
Wariant II
50
250
100000
500000
2800
50
100000 500000
2800
14000
0
0
0
0
14000
36000
180000
136000
680000
100000 500000
W wobec powyższego przyjmuje się, niezależnie od wariantu realizacji:
- dla firmy malej – łącze o przepustowości do / od abonenta 1024 kbit/s / 256 kbit/s,
- dla firmy średniej – łącze o przepustowości do / od abonenta 4096 kbit/s / 512 kbit/s.
3.6.
Oszacowanie kosztów instalacji i eksploatacji
Dla oszacowania kosztów przyjęto następujące założenia:
11
250
-
analizę opracowano dla konfiguracji 50 i 250 użytkowników dla wariantu
inwestycyjnego i usługowego,
cenę oprogramowania firmy Microsoft na postawie cenników autoryzowanych
sprzedawców,
cenę za usługi hostingu wg oferty firmy DCS Computer Consultants Group
zamieszczonej na stronie http://www.hostedexchange.pl/.
koszt łącza dostępu do Internetu określono na podstawie TP S.A.,
wykorzystanie funkcji wirtualnego firewall’a, spowodowało, że uznano nie ma
potrzeby używania odrębnego urządzenia,
dla konfiguracji nie występujących w cennikach dla zadanej liczby użytkowników
przyjęto ceny proporcjonalnie,
wszystkie prace instalacyjne serwera wykonuje zatrudniony administrator – koszt
etatu administratora 9000 zł miesięcznie,
koszt przygotowania pomieszczenie dla instalacji serwera przyjęto ryczałtowo 20 tys.
zł.
12
Tabela 4 Analiza kosztów wariantów inwestycyjnego i usługowego
Wariant I
Specyfikacja
cena
Liczba użytkowników
50
250
Infrastruktura podstawowa - dostęp do Internetu
I.
Koszty jednorazowe
I.1
Instalacja usługi dostęp do Internetu DSL TP dla
799
799
799
1. wszystkich opcji
Lp.
Wariant II
50
250
799
799
99
99
99
898
898
3. Razem jednorazowe - infrastruktura podstawowa
Koszty miesięczne
I.2
1. DSL 1000- 1024 kbit/s / 256 kbit/s (miesięczna)
229
229
2. DSL 4000- 4096 kbit/s / 512 kbit/s (miesięczna)
349
349
Zaawansowany pakiet bezpieczeństwa
49
49
49
realizowany w oparciu o wirtualny Firewall
3. realizowany na platformie TP (miesięczna)
278
398
4. Opłaty miesięczne razem
II.
Instalacja serwera (jednorazowe)
1. Prygotowanie pomieszczenia + instalacje
20 000
20 000
20 000
Serwer Intel P4 3,2 GHz, 1 GB RAM, dysk 2x
8 000
8 000
2. 160 GB i streamer do backupu
Serwer Intel P4 3,2 GHz, 2 GB RAM, dysk 4x
16 000
16 000
3. 160 GB i streamer do backupu
Windows Server Ent 2003 R2 Win32 PL - 50
8 500
8 500
5. użyt.
Windows Server Ent 2003 R2 Win32 PL - 250
42 500
42 500
6. użyt.
Exchange Server 2003 Enterprise English 50
31 600
31 600
7. użyt.
Exchange Server 2003 Enterprise English - 250
158 000
158 000
8. użyt.
Oprogramowanie do backupu (Symantec
30 000
30 000
30 000
9. BackupExec + agent dla Exchange Server)
Certyfikat SSL dla bezpiecznego dostępu przez
785
785
785
10. OWA i RPC over HTTPS (w pierwszym roku)
11. Instalacja serwera razem
98 885
267 285
Koszt ekspoatacji serwera - miesięcznie
III.
1. Koszt serwisu sprzętu 10 % ceny
67
133
Zatrudnienie administratora całkowity koszt etatu
9 000
4 500
13 500
2. miesięcznie (0,5 - 50 użyt. i 1,5 użyt.)
3. Razem koszt ekploatacji serwera
4 567
13 633
Koszt usługi hostingu Exchange
IV.
1. Jednorazowa opłata instalacyjna 25 szkrzynek
300
2. Firma 25 GB - 25 skrzynek miesiecznie
1 185
Podsumowanie wariantów
V.
1. Koszty za opłaty jednorazowe (bez VAT) zł
99 783
268 183
2. Koszty miesięczne rocznie (bez VAT) zł
58 136
168 376
157 919
436 559
3. Koszty roczne razem (bez VAT) zł
3 158
1 746
VI. Koszty roczne/ użytkonika (bez VAT) zł
898
898
Serwer DHCP dla funkcjonalności routera z
2. translacją adresów NAT (jednorazowa)
99
99
229
349
49
49
278
398
600
2 370
3 000
11 850
1 498
31 776
33 274
665
3 898
146 976
150 874
603
3.7.
Parametry odnoszące się do usług i aplikacji
Niezależnie do sposobu realizacji, czy aplikacje wykonywane są na lokalnym serwerze, czy
sieciowo, dla użytkownika istotne są parametry związane z danymi aplikacjami.
13
Oszacowanie parametrów dla danych rodzajów aplikacji jest niezbędne dla:
-
oszacowania przepustowości sieci,
-
określenia parametrów SLA.
W oparciu o zamieszczoną niż tabelę oszacowano niezbędną przepustowość łącza dostępu
do Internetu.
Tabela 5 Docelowe parametry wydajnościowe wg zastosowań wg Tabeli I.2/G.1010
Parametry
wydajnościowe
Typowa
Stopień
i wartości docelowe
Lp Zastosowania
liczba
symetrii
Opóźnienie
w Utrata
danych
jednym kierunku
informacji
Zalecane < 2 s
1.
Przeważający
Web-browsing
/stronę
jednokierunko
~10 KB
Zero
– HTML
Akceptowane < 4 s /
wy
stronę
2.
Zbiory
danych Przeważający
Zalecane < 15 s
10 KB-10 MB
Zero
transfer/wyszukiwa jednokierunko
Akceptowane < 60 s
nie
wy
3.
Usługi transakcyjne
Zalecane < 2 s
o
wysokim Dwukierunkow
< 10 KB
Zero
priorytecie
np. y
Akceptowane < 4 s
e-commerce, ATM
4.
Zarządzanie/
Dwukierunkow
~ 1 KB
< 250 ms
Zero
sterowanie
y
Zalecane < 15 s
5.
Jednokierunko
Zero
< 100 KB
Stały obraz
wy
Akceptowane < 60 s
6.
Dwukierunkow
Gry interaktywne
< 1 KB
< 200 ms
Zero
y
7.
Dwukierunkow
y
< 1 KB
< 200 ms
Zero
Telnet
(asymetryczny
)
8.
Przeważający
Zalecane < 2 s
E-mail (dostęp do
jednokierunko
Zero
< 10 KB
serwera)
Akceptowane < 4 s
wy
9.
Przeważający
E-mail
(transfer
jednokierunko
< 10 KB
Może być kilka minut Zero
serwer do serwera)
wy
10.
Przeważający
e
<10-6
~ 10 KB
< 30 s/stronę
Fax ("real-time")
BER
jednokierunko
wy
11.
Przeważający
<10-6
Fax
(zapisz
&
~ 10 KB
Może być kilka minut
jednokierunko
BER
przekaż)
wy
12.
Przeważający
Transakcje
o
< 10 KB
< 30 s
Zero
jednokierunko
niskim priorytecie
wy
13.
Przeważający
Może być 1
Usenet
jednokierunko
MB
lub Może być kilka minut Zero
wy
więcej
14
3.8.
Koszty, a SLA
W analizowanym przypadku trudno jest określić zależności ekonomiczne między
parametrami oraz warunkami SLA.
W wariancie I inwestycyjnym komunikacja wewnątrz firmy będzie odbywała się poprzez sieć
LAN i parametry usług będą zależały głównie od wydajności serwera.
W wariancie II usługowych komunikacja będzie się odbywała do użytkowników:
- wewnętrznych poprzez łącze dostępowe do siedziby firmy,
- zewnętrznych poprzez łączenie z centrum danych dostawcy usługi.
W wariancie I mogłaby to być zależność między wydajności serwera, a jego ceną.
W wariancie II jest trudno jest ocenić, ponieważ w sieci Internet nie stosowane są
mechanizmy gwarancji pasma. Można sądzić, że łącze większej przepustowości będzie
gwarantowało większe wydajności. W tym przypadku nie ma także mechanizmów
zapewniającym gwarancje parametrów transmisji z serwerem zainstalowanym u dostawcy
usług.
Biorąc pod uwagę wyniki analizy SWOT i ekonomicznej dla firmy korzystne będzie w
przypadku, jeśli:
- zamierza wdrażać systemy informatyczne i budować własną infrastrukturę
teleinformatyczną realizować usługi poczty elektronicznej w oparciu o własny serwer,
- zamierza ograniczyć zastosowania tylko do poczty elektronicznej i pracy grupowej
może wziąć pod uwagę korzystanie z usługi sieciowej biorąc pod uwagę obniżenie
kosztów.
4. Monitorowanie parametrów usług
Z punktu widzenia odbiorcy usług pomiary parametrów powinny być wykonywane w punkcie
dostępu odbiorcy do usługi. Dla monitorowania postanowień umowy SLA nie powinno
wykorzystywać się mierników związanych z wewnętrznymi systemami dostawcy
wspierającymi działanie usługi głównej. Dla odbiorcy znaczenie mają tylko te parametry,
które są mierzone w punkcie dostępu odbiorcy do usługi. Właściwe konstruowanie mierników
umów SLA jest zadaniem obydwu stron kontraktu i wymaga od negocjatorów pewnej
znajomości domeny technicznej która stoi za definicją określonych parametrów. Z tego
punktu widzenia w negocjowaniu definicji parametrów ze strony odbiorcy powinny
uczestniczyć osoby rozumiejące naturę monitorowanych procesów. Konstruowane mierniki
powinny być oparte o uznane standardy funkcjonujące na rynku by zapewnić łatwość i
utrzymania i adaptacji do zmieniających się wymagań dotyczących monitorowanych
procesów.
4.1.
Systemy zarządzania w pomiarze parametrów SLA
Fundamentalnym elementem umów SLA (ang. Service Level Agreement) zawieranych
zarówno między dwoma firmami, jak wewnętrznie – między działami firmy, jest możliwość
obiektywnego pomiaru parametrów SLA przez obie strony umowy. Obecnie najczęstszym
źródłem danych o charakterze technicznym są systemy zarządzania sieciami
komputerowymi lub systemami informatycznymi. Większość współczesnych systemów
operacyjnych, urządzeń sieciowych, a nawet urządzeń peryferyjnych pozwala na
gromadzenie szeregu danych pomiarowych.
Podstawowe obszary działania systemów zarządzania definiuje standard ISO/D15 7498-4.
Obejmują one zarządzanie: obsługą błędów, konfiguracją, rozliczeniami, wydajnością
i zabezpieczeniami. Obsługa błędów oznacza możliwość wykrywania, izolowania i usuwania
niesprawności w trakcie działania. Zarządzanie konfiguracją pozwala na sprawdzenie
konfiguracji każdego elementu sieci oraz dokonywanie w niej odpowiednich zmian.
Rozliczenia, pojęcie bardzo rzadko pojawiające się w kontekście sieci TCP/IP, oznaczają
możliwość monitorowania kosztów połączeń i wykorzystania zasobów sieci. Zarządzanie
15
wydajnością to przede wszystkim monitorowanie ruchu w sieci w celu określenia ew.
„wąskich gardeł”. Zarządzanie bezpieczeństwem zaś, to kontrola i autoryzacja dostępu,
szyfrowanie danych oraz alarmowanie o wszelkich przypadkach naruszenia zasad
bezpieczeństwa.
W zakresie niniejszej pracy znajdują się przede wszystkim zagadnienia związane z
monitorowaniem złożonych systemów informatycznych. Obecnie praktycznie wszystkie tego
typu systemy oparte są o protokół SNMP (ang. Simple Network Management Protocol)
4.2.
Architektura systemu zarządzania
Zwykle budowa systemu zarządzania jest bardzo prosta. Składa się on z elementów
(nazywanych agentami) pozwalających na monitorowanie i zarządzanie jakimś obiektem
(komputerem, urządzeniem sieciowym itp.) i ze stacji zarządzania.
Agenci mogą to być części systemu (np. oprogramowania), moduły sprzętowe lub zupełnie
osobne urządzenia. Komunikacja pomiędzy agentami, a stacją zarządzającą może się
odbywać na dwa sposoby: przy wykorzystaniu tej samej sieci, którą zarządzamy lub poprzez
stworzoną do tego celu sieć odrębną 2 .
Komunikacja jest zwykle inicjowana przez stację zarządzającą, która stale sprawdza stan
poszczególnych agentów i zarządzanych przez nich urządzeń. Agenci rozpoczynają
komunikację ze stacją tylko w razie sytuacji krytycznych (awaria, przekroczenie określonych
wcześniej limitów itp.).
W niektórych przypadkach pomiędzy agentami a stacją zarządzającą mogą znajdować się
urządzenia pośredniczące (ang. proxy). Urządzenia takie są potrzebne np. wtedy, gdy agent
i stacja zarządzająca korzystają z różnych protokołów komunikacji. Pełnią one wtedy rolę
„tłumacza”.
W przypadku bardzo rozbudowanych sieci lub wtedy, gdy stała bezpośrednia łączność
pomiędzy agentem a stacją zarządzającą jest zbyt kosztowna (np. w przypadku sieci
rozległych) stosuje się tzw. super-agentów. Są to zazwyczaj komputery, które zbierają dane
od agentów z wyróżnionej części sieci (a więc pełnią dla nich niejako rolę stacji
zarządzającej), dokonują wstępnej obróbki i agregacji informacji, a następnie wysyłają już
przetworzone dane do centralnej stacji zarządzającej.
4.3.
Simple Network Management Protocol
Pierwsze mechanizmy zarządzania dla sieci TCP/IP powstały jeszcze w latach
siedemdziesiątych. Należał do nich protokół ICMP (Internet Control Message Protocol).
Pozwalał on między innymi na testowanie połączeń pomiędzy poszczególnymi węzłami sieci
oraz na sprawdzenie opóźnień jakie w tej sieci występują.
SNMP (1989) jest następcą pierwszego protokołu zarządzania powstałego dla sieci TCP/IP.
Był to Simple Gateway Monitoring Protocol (1987). Równolegle z nim powstała wersja
protokołu CMIP (ang. Common Management Information Protocol) dla sieci TCP/IP,
definiująca zarówno protokół zarządzania sieciami, jak i dostępne usługi i bazy danych
przechowujące informacje o urządzeniach. Ponieważ liczono się z szybkim wprowadzeniem
standardów ISO-OSI, protokół SNMP był traktowany jako szybkie rozwiązanie tymczasowe.
Docelowym protokołem miał być CMIP.
Stało się jednak inaczej. Ze względu na bardzo skomplikowaną strukturę i nie mniej
skomplikowaną implementację, CMIP nie zdobył szerszej popularności; natomiast SNMP właśnie dlatego, że był bardzo prymitywny, ale za to nie stawiał wielkich wymagań przed
sprzętem, jest najczęściej wykorzystywanym obecnie protokołem zarządzania w sieciach
komputerowych.
Protokołem transportowym dla SNMP jest UDP (ang. User Datagram Protocol). Budowa
ramek SNMP i sposób jego działania jest bardzo prosty.
2
W sieciach telekomunikacyjnych, często stosowanym rozwiązaniem jest przesyłanie informacji systemu
zarządzania wprawdzie przy użyciu tej samej sieci fizycznej, ale wyodrębnionym kanałem, tak by nie wpływał
on na przesyłanie danych.
16
Pakiet SNMP składa się z trzech części: numeru wersji protokołu, community i PDU (ang.
Protocol Data Unit). Community określa z jednej strony przynależność urządzenia do
określonej grupy, a z drugiej - jest najprostszym (i jednym w pierwotnej wersji protokołu)
sposobem autoryzacji. Istnieją dwa trybu dostępu do danych (można dla nich zdefiniować
odrębne community. Pierwszy z nich to dane „tylko do odczytu” (zwyczajowo community
nazywa się public). Drugi to dostęp do „odczytu i zapisu” (standardowo nadawaną nazwą
community jest private. Zazwyczaj w trybie do „tylko do odczytu” udostępniane są wszystkie
dane urządzenia, w trybie „odczytu i zapisu” - tylko wybrane.
W protokole występuje tylko pięć rodzajów komunikatów (PDU). Stacja zrządzająca wysyła
żądania przesłania danych do agenta: GetRequest (zapytanie o pojedynczy element bazy
danych agenta), GetNextRequest (zapytanie o następny element bazy danych). Polecenia
systemu zarządzania są wysyłane jako rozkazy wstawienia odpowiedniej wartości do
określonego elementu bazy danych (domyślnie - zmiana wartości w bazie danych, pociąga
za sobą odpowiednie zmiany w stanie urządzenia). Służy do tego PDU SetRequest. Agent
na wszystkie te polecenia odpowiada zawsze pakietem GetResponse. W przypadku
wystąpienia w sieci nagłych zdarzeń, agent informuje o tym stację zarządzania wysyłając
pakiet Trap. Zawiera on informacje o typie zdarzenia, czasie jego powstania i ew. dalsze
dane na temat stanu urządzenia.
Już w 1992 r. rozpoczęto prace nad nową wersją protokołu SNMP - SNMPv2. Dążenie do
poprawienia standardu miało dwie przyczyny: po pierwsze w wielu przypadkach SNMP
okazał się jednak zbyt prymitywny, a po drugie protokół ten nie oferował praktycznie żadnych
zabezpieczeń nie tylko w przesyłaniu informacji, ale także w dostępie do urządzeń.
Ostateczna wersja standardu została opublikowana w 1996 r. Zawierała definicje nowych
typów danych, dodano nowe PDU pozwalające na przesłanie większej liczby danych:
GetBulkRequest oraz PDU do wymiany informacji między stacjami zarządzającymi
InformRequest. Niestety zaproponowane rozwiązania dotyczące zabezpieczeń nie znalazły
uznania producentów urządzeń sieciowych i nie są praktycznie implementowane.
Standard SNMPv3 (1998) wzbogacił protokół SNMP o rozwiązania związane z
bezpieczeństwem przesyłanych danych.
4.4.
Management Information Base
Podstawową częścią agenta jest hierarchiczna baza danych. Baza danych ma kształt
drzewa. Liście tego drzewa definiują obiekty, którymi zarządzamy. Mogą to być właściwości
urządzenia, sposób jego działania, dane statystyczne itp. Samo zaś drzewo definiuje relacje
logiczne zachodzące pomiędzy obiektami. Założono, że w bazie danych mogą być
przechowywane bardzo proste obiekty. Są to albo dane skalarne, albo dwuwymiarowe
tablice danych skalarnych. Protokół SNMP obsługuje wyłącznie przesyłanie danych
skalarnych, a więc tablice muszą być przesyłane element po elemencie.
Każda zmiana stanu zarządzanego urządzenia powinna natychmiast znajdować odbicie
w odpowiedniej zmianie stanu stosownego elementu bazy MIB agenta. I na odwrót - każda
zmiana wartości w bazie danych, powinna powodować to, że agent dokona odpowiedniej
zmiany stanu urządzenia.
Standardowa baza danych MIB zawiera wyłącznie podstawowe informacje na temat
urządzenia i podstawowe statystyki, dotyczące głównie ruchu w warstwie fizycznej. Została
ona celowo ograniczona, aby mogła być zaimplementowana bez konieczności znacznej
rozbudowy sprzętu. Przewidziano również wydzielona hierarchie dla wytwórców urządzeń
sieciowych. Mogą oni rozszerzać standardową bazę MIB o informacje charakterystyczne dla
ich produktów (jest to jeden z powodów, dla których nie ma praktycznie systemów
zarządzania, które pozwalałyby na zarządzanie sprzętem pochodzącym od różnych
producentów - każdy z nich inaczej definiuje parametry swoich urządzeń).
W 1991 roku zostało zaproponowane rozszerzenie definicji bazy danych MIB. Stworzono
standard MIB-II. Rozszerza on dane dotąd gromadzone przez bazę MIB o statystyki
dotyczące m. in.: interfejsów sieciowych, translacji adresów, protokołów: IP, ICMP, UDP,
TCP i SNMP.
17
Każdy element w bazie danych ma swój identyfikator. Identyfikator ten to ciąg liczb
całkowitych, oddzielonych od siebie kropkami. Każda liczba, to numer obiektu na
poszczególnym stopniu hierarchii. Np. tablicę połączeń TCP otrzymamy podając adres:
1.3.6.1.2.1.6.13 (patrz Rys. 1).
Rys. 1. Budowa bazy MIB-II.
18
4.5.
Remote Network Monitoring
RMON (ang. Remote Network Monitoring) jest jednym z najistotniejszych rozszerzeń, o jakie
uzupełniono protokół SNMP. Pierwotna definicja bazy MIB, MIB-II i samego SNMP tworzona
była na potrzeby monitorowania i zarządzania poszczególnymi urządzeniami sieciowymi.
Standard RMON powstał w celu zapewnienia możliwości analizy ruchu w całym segmencie
sieci. Wykorzystywane są do tego specjalne urządzenia - analizatory (sondy) sieciowe. Co
raz częściej analizatory RMON stają się też częściami zaawansowanych urządzeń
sieciowych (np. przełączników i routerów). Pozwalają one na gromadzenie danych
statystycznych (np. liczba pakietów przesyłanych w ciągu sekundy, rozmiary pakietów, liczba
błędów, kolizji itp), a także na przechwytywanie wybranych pakietów z segmentu sieci,
w którym się znajdują.
Standard RMON powstał jako rozszerzenie bazy MIB-II. Dodanych zostało dziewięć nowych
grup obiektów dotyczących sieci Ethernet i jedna opisująca zachowanie sieci Token Ring:
• statistics zapewnia bieżące statystyki wykorzystania pasma i statystyki błędów dla
warstwy fizycznej podsieci,
• history tworzy stały, cykliczny zapis statystyk z grupy statistics,
• alarm pozwala na ustawienie ograniczeń, na każdą z zapisywanych przez sondę
wartości, po przekroczeniu których będzie generowany alarm,
• host przechowuje dane na temat ruchu wysyłanego z i do komputerów podłączonych
do danego segmentu sieci,
• hostTopN zawiera listę najbardziej aktywnych komputerów,
• matrix przechowuje dane na temat błędów i ruchu pomiędzy komputerami w sieci w
postaci tablicy, (można łatwo sprawdzić jak wygląda ruch pomiędzy dwoma
dowolnymi maszynami w sieci i jaka jest stopa błędów),
• filter pozwala na ustawienie filtrów zarówno dla przechwytywania pakietów, jak
również tylko po to, aby można było ograniczyć statystyki,
• capture zarządza tym, w jaki sposób przechwycone pakiety zostaną przesłane do
stacji zarządzającej,
• event zawiera tablicę zdarzeń tworzonych przez sondę RMON,
• tokenRing zawiera statystyki i informacje konfiguracyjne dla sieci Token Ring.
W 1996 r. rozszerzono specyfikację standardu RMON, tworząc RMON2. Pozwala on nie
tylko na analizę ruchu w warstwie fizycznej, ale dodano też nowe grupy pozwalające na
zbieranie statystyk dla wyższych warstw sieciowych.
Nowe grupy to:
• protocolDir (protocol directory) zawiera katalog wszystkich protokołów sieciowych,
które mogą być przez sondę interpretowane,
• protocolDist (protocol distribution) statystyki ruchu w każdym z protokołów,
• addressMap (address map) przechowuje tablice adresów fizycznych i sieciowych dla
wszystkich maszyn podłączonych do danego segmentu sieci,
• nlHost (network-layer host) statystyka ruchu w warstwie sieciowej, dla
poszczególnych komputerów,
• nlMatrix (network-layer matrix) tablica zawierająca dane o ruchu pomiędzy każdymi
dwoma komputerami, zebrane na podstawie ich adresów sieciowych,
• alHost (application-layer host) statystyka ruchu dla poszczególnych komputerów
zebrana na podstawie ich adresów w warstwie aplikacji,
• alMatrix (application-layer matrix) tablica zawierająca dane o ruchu pomiędzy
każdymi dwoma komputerami, zebrane na podstawie ich adresów w warstwie
aplikacji,
• usrHistory (user history collection) dane historyczne, zbierane z innych tabel (o tym,
które wartości będą przechowywane decyduje użytkownik),
• probeConfig (probe configuration) standardowe parametry konfiguracyjne sondy
RMON.
19
4.6.
Inne protokoły zarządzania siecią
Protokół SNMP ma dwóch wielkich konkurentów. Są to: zaproponowany przez OSI
CMIP (Common Management Information Protocol) i TMN (Telecommunications
Management Network) będący standardem ITU-T.
Z całą pewnością przewyższają one SNMP swoimi możliwościami sterowania, zarządzania
i monitorowania. Jednak to właśnie dzięki swej prostocie SNMP zdobył tak wielką
popularność.
TMN bazuje na niektórych rozwiązaniach zastosowanych w standardach zarządzania ISO.
Powoli zaczyna on zdobywać popularność jako standard sterowania dużymi sieciami
telekomunikacyjnymi. W sieciach komputerowych, ze względu na swą złożoność nie został
wdrożony.
5. Modele naliczania kar za niedotrzymanie SLA
Sama umowa SLA nie zabezpiecza skutecznie interesów odbiorcy usługi gdy jej wykonanie
nie jest zabezpieczone rygorem sankcji dla dostawcy w przypadku naruszenia jej
postanowień. Podstawową sankcją w relacjach biznesowych pomiędzy podmiotami umowy
jest kara finansowa
Najczęściej zasada określania wysokości kary bazuje na definicji kary jako ułamka lub
wielokrotności kwoty gwarancyjnej zapisanej w umowie, lub jednostkowego wynagrodzenia
dostawcy z tytułu świadczenia usługi w okresie rozliczeniowym. Naruszenie postanowień
umowy zwykle dotyczy dwóch podstawowych aspektów usługi:
• Dostępność
• Jakość
Dostępność określa liczbę dni w podanym okresie (zwykle rozliczeniowym) w czasie których
usługa była/nie była dostępna dla użytkowników lub pewnej podgrupy użytkowników. Jakość
usługi, inaczej poziom jej świadczenia zwykle określany jest jako zdolność udostępnianego
systemu informatycznego(usługi) do reakcji na działania użytkowników w pewnym z góry
określonym czasie.
W omawianym podejściu kara za naruszenie postanowień umowy jest wyliczana na
podstawie wzoru w którym ujęte są parametry dostępności i jakości. W przypadku
parametrów dostępności kara jest naliczana jako procent kwoty gwarancyjnej wynikający z
procentowej niedostępności usługi w stosunku do podanego okresu rozliczeniowego. Przy
czym wartość ta może być podzielona na przedziały z zastrzeżeniem że przy niedostępności
wyższej niż założone maksimum kary rosną silnie nieliniowo w stosunku do liczby okresów
niedostępności. Analogicznie w przypadku parametrów jakościowych kara wynika ze stopnia
upośledzenia usługi w stosunku do jej założonych granicznych parametrów na przykład
spadek wydajności serwera WWW skutkujący odrzucaniem więcej niż 10 połączeń klientów
na minutę. Oczywiście kontrakt może zakładać że spadek wydajności usługi poniżej
podanego minimum traktowany jest jako brak dostępności usługi i kary naliczane są tylko
według tego parametru. Powyższe podejście wynika ze spojrzenia na umowę SLA z punktu
widzenia dostawcy ponieważ nie uwzględnia rzeczywistych kosztów dla odbiorcy jakie wiążą
się z awarią usługi.
Uzależnienie ewentualnych kwot kar od rzeczywistych strat poniesionych przez
odbiorcę należy rozpatrywać w dwóch aspektach. Po pierwsze straty poniesione przez
odbiorcę usługi mogą wynikać z faktu niedotrzymania przez odbiorcę umów podpisanych z
podmiotami trzecimi w zakresie świadczonych przez odbiorcę usług lub produkowanych
towarów. W takim przypadku algorytm wyznaczania kwot kar za niedotrzymanie SLA można
uzależnić od analogicznych algorytmów obowiązujących odbiorcę. Znacznie większą
trudnością jest zdefiniowanie w umowie wartości korzyści utraconych przez odbiorcę usługi z
tytułu braku dostępności lub ograniczonej dostępności usługi informatycznej. Sposobem
rozwiązanie tego problemu jest odniesienie kwoty przychodów uzyskanych przez odbiorcę w
czasie prawidłowego działania usługi do kwot uzyskanych przy niedostępności lub
ograniczonej dostępności usługi. Kwestią osobną aczkolwiek kluczową w tym podejściu jest
obiektywne oszacowanie i monitorowanie utraconych korzyści ze strony odbiorcy. Z racji
20
trudności w określeniu wysokości roszczeń odbiorcy w drugim podejściu, w projektowanym
przez nas rozwiązaniu uwzględniony zostanie pierwszy z modeli wyznaczania wysokości kar.
6. Koncepcja rozwiązania
Niniejszy projekt jest elementem systemu kompleksowego monitorowania SLA we
wszystkich wyżej przedstawionych aspektach. Reprezentuje on część przewidziana dla
analizy parametrów technicznych usług, oraz określania wysokości kar na podstawie
ustalonej w umowie wysokości kary za jednostkę czasu nieodstępności (ograniczonej
dostępności) usługi. Stanowi on narzędzie pozwalające stronom umowy w sposób
obiektywny stwierdzić naruszenie jej parametrów, oraz określić wysokość należnych kar.
6.1.
Model Danych
Rys. 2. Model danych
21
SLM_SERVICE
Nazwa kolumny
SRV_ID
SRV_NAME
Typ
NUMBER
VARCHAR2(100)
Opis
Identyfikator usługi
Nazwa usługi
Tabela zawiera informacje o usługach będących przedmiotem umów SLA.
SLM_USERS
Nazwa kolumny
Typ
Opis
USR_ID
NUMBER
Identyfikator użytkownika
USR_NAME
VARCHAR2(100)
Nazwa użytkownika
Informacje o użytkownikach systemu. Użytkownicy systemu mogą pełnić różne role w
stosunku do umów SLA. W szczególności każda umowa musi mieć zdefiniowanego
administratora umowy ze strony dostawcy, jako osoby odpowiedzialnej za świadczoną
usługę do której powinny być kierowane wszystkie zgłoszenia związane z umową. Poza
administratorem ze strony dostawcy określony musi być administrator umowy ze strony
dostawcy który pełni analogiczną rolę w przypadku zgłoszeń dotyczących nie wywiązywania
się odbiorcy z postanowień zawartej umowy.
SLM_UNITS
Nazwa kolumny
Typ
Opis
UNT_ID
NUMBER
Identyfikator jednostki organizacyjnej
UNT_NAME
VARCHAR2(100)
Nazwa jednostki organizacyjnej
UNT_PARENT_ID
NUMBER
Identyfikator jednostki nadrzędnej
Jednostki organizacyjne przyjmujące i podejmujące zobowiązania do zapewnienia określonej
w umowie wartości parametru.
SLM _TYPES
Nazwa kolumny
Typ
Opis
TPE_ID
NUMBER
Identyfikator typu
TPE_NAME
VARCHAR2(100)
Nazwa Typu (utrzymanie/wykorzystanie)
Słownik typów zobowiązań. Możliwe wartości to „Utrzymanie” – zobowiązanie do
zapewnienia określonego zachowania się podanego parametru, „Wykorzystanie” –
zobowiązanie do utrzymania intensywności korzystania z usługi na określonym poziomie
mierzonym poprzez zadany parametr.
SLM _ROLES
Nazwa kolumny
Typ
Opis
RLE_ID
NUMBER
Identyfikator roli
RLE_NAME
VARCHAR2(100)
Nazwa roli
Słownik ról jakie poszczególne osoby mogę spełniać w stosunku do umowy SLA. Przykłady:
administrator umowy ze strony odbiorcy, administrator umowy ze strony dostawcy.
SLM_ACCOUNTS
Nazwa kolumny
Typ
SRL_RLE_ID
NUMBER
SRL_SLA_ID
NUMBER
SRL_USR_ID
NUMBER
Definicje powiązań pomiędzy rolami, umowami
stosunku do poszczególnych umów.
SLM_COMMITMENTS
22
Opis
Identyfikator roli
Identyfikator umowy
Identyfikator użytkownika
a osobami które pełnia poszczególne role w
Nazwa kolumny
CMT_ID
CMT_SLA_ID
CMT_SRV_ID
CMT_PROVIDER
Typ
NUMBER
NUMBER
NUMBER
NUMBER
CMT_RECIPANT
NUMBER
CMT_TYPE_ID
NUMBER
Opis
Identyfikator zobowiązania
Identyfikator umowy, której dotyczy zobowiązanie
Identyfikator usługi, której dotyczy zobowiązanie
Identyfikator jednostki zobowiązującej się do
świadczenia usługi na poziomie określonym w
umowie SLA(SLM_UNITS)
Identyfikator
jednostki
przyjmującej
zobowiązanie.(SLM_UNITS)
Identyfikator
rodzaju
zobowiązania
(utrzymanie/wykorzystanie/koszt).
Data utworzenia zobowiązania.
CMT_DATE_CREATE DATE
D
Zobowiązania stron umowy mające na celu zapewnienie bezawaryjnej pracy określonej
usługi informatycznej. Każda umowa może zawierać jedno lub więcej zobowiązań.
Zobowiązanie to jednostkowe uzgodnienie pomiędzy jednostką organizacyjną dostarczającą
usługę a jednostką organizacyjną odbierającą usługę, definiujące czas obowiązywania
porozumienia oraz miernik na podstawie którego strony zobowiązują się monitorować
przestrzeganie zawartego uzgodnienia. Niedotrzymanie co najmniej jednego uzgodnienia
skutkuje niedotrzymaniem całej umowy SLA.
SLM_THRESHOLDS
Nazwa kolumny
Typ
Opis
THD_ID
NUMBER
Identyfikator definicji zobowiązania
THD_CMT_ID
NUMBER
Identyfikator zobowiązania
THD_PSH_ID
NUIMBER
Identyfikator modelu naliczania kar
THD_VALUE_MIN
NUMBER
Wartość minimalna parametru
THD_VALUE_MAX
NUMBER
Wartość maksymalna parametru
THD_MSR_ID
NUMBER
Typ miernika parametru
THD_DATE_START
DATE
Początek obowiązywania zobowiązania
THD_DATE_END
DATE
Koniec obowiązanie zobowiązania
Definicje ograniczeń dla poszczególnych parametrów w związku z przyjętymi przez strony
umowy SLA zobowiązaniami. Zobowiązanie w okresie jego ważności może być
modyfikowane. Modyfikacjom mogą podlegać: rodzaj miernika, sposób naliczenia kary za
jego nieotrzymanie, górne i dolne ograniczenie miernika. Każdorazowo określany jest
początek obowiązywania nowych ograniczeń oraz koniec obowiązywania poprzedniej wersji.
SLM_MEASURES
Nazwa kolumny
Typ
Opis
MSR_ID
NUMBER
Identyfikator miernika parametru
MSR_IVL_ID
NUMBER
Identyfikator typu przedziału czasu
MSR_PRM_ID
NUMBER
Identyfikator miernika usługi - parametru
MSR_STC_ID
NUMBER
Identyfikator statystyki agregującej
Mierniki czyli sposoby agregacji wartości parametrów w czasie. Przechowują powiązania
interwałów czasowych ze statystykami. Obiekty przechowywane w tej tabeli definiują pojęcia
typu: wartość średnia w tygodniu, wartość maksymalna w miesiącu, suma wartości w
kwartale … .
SLM_INTERVALS
Nazwa kolumny
IVL_ID
IVL_NAME
Typ
NUMBER
VARCHAR(10)
Opis
Identyfikator typu przedziału czasu
Nazwa
przedziału:
minute,
hour,
week,month, quater, year
23
day,
Słownik interwałów czasowych: minuta, godzina, dzień, tydzień, miesiąc, kwartał, rok. W
których mierzona jest wartość parametru. Parametry mogą być mierzone w odstępach czasu
innych niż zawarte w umowie ustalenia. Zwykle umowa precyzuje postanowienia stron co do
pewnej statystycznej wartości określonego technicznego parametru infrastruktury
informatycznej. Częstotliwość próbkowania takiego parametru może być na tyle duża że
pojedyncze spadki jego wartości nie powinny mieć wpływu na jakość świadczonej usługi. W
takich przypadkach zakłada się że porównywane z wartościami granicznymi będą pewne
statystyczne miary tych wartości w zadanych okresach.
SLM_STATISTICS
Nazwa kolumny
Typ
STC_ID
NUMBER
STC_NAME
VARCHAR(10)
Słownik statystyk: suma, średnia, maksimum,
mierników.
Opis
Identyfikator statystyki
Nazwa statystyki : SUM,AVG, MAX, MIN
minimum… wykorzystywanych do definicji
SLM_PARAMETERS
Nazwa kolumny
Typ
Opis
PRM_ID
NUMBER
Identyfikator parametru
PRM_URL
VARCHAR2(1024)
URL parametru
PRM_NAME
VARCHAR2(100)
Nazwa parametru
PRM_ACTIVE
CHAR(3)
Parametr wykorzystywany/niewykorzystywany
PRM_FILE_NAME
VARCHAR2(30)
Nazwa pliku aktualizacji
Słownik parametrów przechowuje między innymi informacje o sposobie dostępu do
wyładowań danych dla poszczególnych parametrów w postaci adresu URL pod którym
usługa wyładowująca wartości parametru udostępnia swoje dane.
SLM_SLA
Nazwa kolumny
SLA_ID
SLA_NAME
Słownik umów SLA
SLM_PENALTIES
Nazwa kolumny
PNL_ID
PNL_PSH_ID
PNL_LVL_NO_LOW
Typ
NUMBER
VARCHAR2
Opis
Identyfikator umowy
Opis umowy
Typ
NUMBER
NUMBER
NUMBER
Opis
Identyfikator składnika kary
Identyfikator modelu naliczania kar
Minimalna liczba okresów pomiarowych, dla
których
stwierdzone niedotrzymanie umowy,
skutkuje naliczeniem jednostki kary
PNL_LVL_NO_HIGH
NUMBER
Maksymalna liczba okresów pomiarowych, dla
których
stwierdzone niedotrzymanie umowy,
skutkuje naliczeniem danej jednostki kary
PNL_COST
NUMBER
Jednostkowy koszt kary za niedotrzymanie
warunków umowy.
PNL_CONST
CHAR(1)
Czy kwota kary jest zależna od liczby okresów
niedostępności czy też jest stała dla zadanych
wartości minimalnej maksymalnej.
Tabela przechowuje definicje składników modelu kary w postaci funkcji odcinkowo liniowej.
W tabeli podane są minimalne i maksymalne wartości liczby okresów zdefiniowanych dla
miernika w tabeli SLM_MEASURES. Jeżeli w danym okresie wystąpi naruszenie
zobowiązania w liczbie okresów pomiędzy zadanymi wartościami maksymalną i minimalną
naliczona zostanie wartość kary wynikająca z pomnożenia liczby tych okresów przez
24
jednostkową kwotę kary (PNL_CONST=’N’) lub określona zostanie w wysokości podanej w
wierszu (PNL_CONST=’Y’)
SLM_PENALTY_SCHEMES
Nazwa kolumny
Typ
PSH_ID
NUMBER
PSH_NAME
VARCHAR2
Słownik modeli naliczania kar.
Opis
Identyfikator modelu naliczania kary
Nazwa modelu naliczania kary
SLM_PARAM_VALUES
Nazwa kolumny
Typ
Opis
PVL_PRM_ID
NUMBER
Identyfikator parametru(miernika)
PVL_VALUE
NUMBER
Wartość parametru
PVL_DATE
DATE
Data obserwacji wartości parametru
Tabela przechowuje dane szczegółowe dotyczące zmian wartości monitorowanych
parametrów w czasie. Dane do tej tabeli są ładowane w drugim etapie przetwarzania
danych, po wyładowaniu ich z systemów źródłowych.
6.2.
Architektura zasilania bazy danych
Warstwa zasilania bazy danych SLM składa się z 2 etapów . Pierwszym jest wyładowanie
danych z systemów źródłowych. W następnej kolejności następuje zasilenie struktur danych.
Założeniem konstrukcji warstwy zasilania jest minimalizacja prac wdrożeniowych
potrzebnych do wykonania przy uruchamianiu systemu w nowym otoczeniu.
Rys. 3. Architektura przetwarzania danych
Wyładowanie danych
Wyładowanie danych z systemów źródłowych leży poza ścisłym obszarem systemu i jest
realizowane przez aplikacje zewnętrzne w złożeniu powiązane z systemami dostarczającymi
dane do analiz parametrów. Aplikacje realizujące wyładowanie muszą spełniać następujące
warunki:
•
•
Plik wynikowy działania musi być dostępny poprzez protokół http lub ftp,
Plik wynikowy musi mieć następującą strukturę
25
•
Kolumna nr.
Opis
1
Czas zarejestrowania wartości parametru
2
Wartość parametru
Wartości W kolumnach muszą być oddzielane przecinkami
Dane wynikowe muszą być dostępne w określonym czasie przeznaczonym na proces
ładowania hurtowni danych.
Pobieranie wartości parametrów
Lista parametrów wykorzystywanych w systemie zawarta jest w słowniku
SLM_PARAMETERS. Proces ładujący dane dotyczące zmian wartości monitorowanych
parametrów w czasie działa według następującego algorytmu
1. Pobierz listę parametrów które są aktywne na dany okres zasilania HD,
2. Dla każdego parametru aktywnego pobierz jego URL,
3. Pobierz zbiór z danymi i zapisz go w katalogu tymczasowym,
Ładowanie wartości parametrów
Zbiory zawierające aktualizacje przebiegów wartości parametrów są umieszczone w
tymczasowym katalogu w systemie SLM. Proces ładujący dane do Hurtowni Danych działa
według następującego algorytmu.
1. Pobierz listę parametrów aktywnych za dany okres zasilania HD
2. Dla każdego parametru aktywnego pobierz nazwę pliku z aktualizacją
3. Wczytaj plik aktualizacji do tabeli tymczasowej w bazie danych oracle dla danego
okresu zasilania
4. Usuń plik tymczasowy
5. Uaktualnij tabelę SLM_PARAMETER_VALUES na podstawi tabeli tymczasowej
6. Wyczyść zawartość tabeli tymczasowej.
Pobieranie danych umów SLA
Dane dotyczące konstrukcji umów SLA gromadzone są w metadanych sytemu SLM.
Informacje te opisują strony umowy, oraz ich zobowiązania dotyczące zachowania
określonych wartości parametrów w czasie. Szczegółowy opis tabel metadanych
przedstawiony jest w punkcie 3. Dane dotyczące umów SLA są wprowadzane do systemu
przez odpowiednie osoby upoważnione do administracji systemem SLM. Do wprowadzania
danych służy interfejs WWW będący elementem systemu SLM.
6.3.
Specyfikacja aplikacji do zarządzania umowami
Podstawowym interfejsem dostępu do systemu jest aplikacja do zarządzania umowami SLA.
Jej zadaniem jest umożliwienie administratorowi:
• Definicji umów i ich ograniczeń,
• Definiowania nowych parametrów
• Monitorowania stanu wykonania umowy,
Definicja umowy SLA polega na określeniu jej parametrów pozwalających stwierdzić czy
zawarte uzgodnienia są dotrzymane oraz kto wobec kogo ponosi odpowiedzialności w
przypadku ich naruszenia. Stronami umowy SLA mogą być tylko organizacje
reprezentowane przez pełnomocników nazywanych dalej administratorami umowy. W celu
definicji umowy administrator musi znać:
• Przynajmniej dwie strony umowy z których jedna jest dostawcą a druga
odbiorcą usługi,
• Przynajmniej jeden parametr opisujący poziom utrzymania usługi.
Prawidłowo zdefiniowana umowa SLA musi spełniać następujące warunki
26
•
•
•
•
•
Może mieć więcej niż jednego odbiorcę,
Może mieć tylko jednego dostawcę,
Może dotyczyć więcej niż jednej usługi,
Może mieć więcej niż jednego administratora,
Może mieć zdefiniowaną dowolną liczbę parametrów wykorzystania i
utrzymania,
• Parametry umowy są od siebie niezależne i mogą być określone na różnych,
poziomach agregacji względem czasu,
• Parametry muszą mieć wartości liczbowe,
• Na parametr można nałożyć ograniczenie górne i dolne,
• Parametr może służyć do monitorowania więcej niż jednej usługi.
W celu umożliwienia zapisania powyższych informacji w metadanych systemu SLM
projektowany jest dostępny przez WWW kreator umów. W celu weryfikacji stopnia spełnienia
zobowiązać zastrzeżonych w umowie SLA projektowany jest interfejs do monitorowania
poziomów utrzymania i wykorzystania będący częścią aplikacji do administrowania
umowami.
W kolejnych punktach zostaną przedstawione scenariusze operacji (przypadki użycia) jakie
mogą zostać wykonanie przy wykorzystaniu projektowanej aplikacji.
Definicja
umowy
6.3.1.
Rys. 4. Definicja umowy
W pierwszym kroku administrator określa tytuł umowy. W kolejnym kroku przypisywane są
role poszczególnych osób w stosunku do umowy:
• Administrator umowy ze strony odbiorcy,
• Administrator umowy ze strony dostawcy,
• Zastępca administratora ze strony odbiorcy,
• Zastępca administratora ze strony dostawcy.
27
Po zakończeniu definicji ról poszczególnych osób w stosunku do definiowanej umowy należy
określić przynajmniej jedno zobowiązanie jakie przyjmuje na siebie dostawca wobec
odbiorcy. Definicja zobowiązania pociąga za sobą konieczność określenia.
• Jednostki organizacyjnej, która wymaga określonego zobowiązania,
• Jednostki organizacyjnej, odpowiedzialnej za poziom danego parametru,
• Parametru będącego przedmiotem zobowiązania,
• Typu zobowiązania, określającego czy jest to zobowiązanie co do utrzymania lub
wykorzystania usługi,
• Usługi której dotyczy zobowiązanie,
• Daty powzięcia zobowiązania.
Każde zobowiązanie powinno mieć zdefiniowane ograniczenia pozwalające na wykrycie
naruszenia warunków umowy. Ograniczenia określają:
• Maksymalny dopuszczalny poziom wartości parametru w danym interwale czasowym
• Minimalny dopuszczalny poziom wartości parametru w danym interwale czasowym
• Sposób agregacji parametru (interwały czasowe w których wartości parametru
powinny być zagregowane, oraz sposób agregacji)
• Datę rozpoczęcia obowiązywania ograniczenia
• Datę zakończenia obowiązywania ograniczenia
Wartości progowe ograniczeń oraz sposób agregacji wartości parametrów mogą się
zmieniać w czasie, jeżeli odpowiednia definicja zostanie zmodyfikowana przez
administratora.
28
SLAScreen
ParameterScreen
CommimentScreen
SummaryScreen
Okreś dostawcę
Twórz nową umowę
Określ Administratora Usługi
Określ Właściciela Usługi
Określ początek obowiązywania
Wyświetl podsumowanie
Twórz zobowiązanie
Określ koniec obowiązywania
Określ odbiorcę
Start Aplikacji
Określ maksimum
Definiuj ograniczenia
określ minimum
Określ Parametr
Edytuj zobowiązanie
Określ model kar
Edytuj istniejącą umowę
Określ statystykę
Określ miernik
Rys. 5. Algorytm definicji umowy SLA z podziałem na ekrany interfejsu użytkownika
29
Określ interwał
6.3.2. Monitorowanie wykonania umowy
Rys. 6. Weryfikacja umowy - przypadki użycia
Po pomyślnym zalogowaniu się do systemu administrator otrzymuje dostęp do listy umów
które są pod jego nadzorem. Przy każdej umowie oznaczony symbolem graficznym jest
status umowy :
• Umowa jest dotrzymana
• Naruszenie ze strony dostawcy
• Naruszenie ze strony odbiorcy
Wybór konkretnej umowy powoduje wyświetlenie listy parametrów z podziałem na parametry
utrzymania i wykorzystania. Przy każdym parametrze wyświetlona jest informacja o
przekroczeniu przez dany parametr zadanych progów.
Wybór konkretnego parametru powoduje wyświetlenie wykresu przebiegu danego
parametru, wraz z zaznaczonymi progami.
Rys. 7. Procedura weryfikacji umowy SLA
30
6.3.3. Struktura statyczna systemu
TUSER
TROLE
-usrId : short(idl)
-usrName : string(idl)
-roleId : short(idl)
-name : string(idl)
TSERVICE
TUNIT
-serviceId : short(idl)
-serviceName : string(idl)
-unitId : short(idl)
-unitName : string(idl)
-parentId : short(idl)
+generate() : TUNIT
TACCOUNT
1
1
1
-srlId : short(idl)
-sla : TSLA
-role : TROLE
-usr : TUSER
+getAccount(wartość slaId, wartość userId) : TACCOUNT
Odbiorca
1
*
SlaViewScreen
ParametersViewScreen
Dostawca
1
TCOMMITMENT
TSLA
-name : string(idl)
-date_signed : object(idl)
+getCommitments() : sequence(idl)
+setAdmin(wartość admin : TACCOUNT)
+setOwner(wartość owner : TACCOUNT)
+save() : TSLA
+generate() : TSLA
+getSla(wartość slaId) : TSLA
wyświetla
1
1
1
«uses»
*
1
TTYPE
-typeId : short(idl)
-typeName
+getType(wartość type)
1
1
*
ParameterDisplayScreen
-id : short(idl)
-SLA : TSLA
-service : TSERVICE
-provider : TUNIT
-recipant : TUNIT
-type : TTYPE
-dateCreated : object(idl)
+getDefinitions() : sequence(idl)
+setProvider()
+setRecipant()
+createDefinition() : TTHRESHOLD
+generate() : TCOMMITMENT
+getCommitment(wartość commitmentId) : TCOMMITMENT
TUSAGECOMMITMENT
1
1
TSUPPORTCOMMITMENT
1
wyświetla
TBASEOBJ
+isSatified(wartość calendar : Calendar)
+countPenalty(wartość calendar : Calendar) : <nieokreślone>
«uses»
SLAScreen
+renderScreen() : <nieokreślone>
*
TPENALTYSCHEME
«uses»
TTHRESHOLD
uruchamia
-cmtDefId : short(idl)
-commitment : TCOMMITMENT
-aggregation : TMEASURE
-valueMin : float(idl)
-valueMax : float(idl)
-dateStart : object(idl)
-dateEnd : object(idl)
-penaltyScheme : TPENALTYSCHEME
+generate() : TTHRESHOLD
+setStartDate()
+setEndDate()
+setMinValue()
+setMaxValue()
+isValidFor(wartość calendar : Calendar)
Obiekty Widoku i Kontrolera aplikacji
mają dostep do modelu wyłącznie
poprzez obiekty typu TSLA
Calendar
-startDate
-endDate
+getCalendar() : Calendar
SlaDefinitionAction
+doPerformAction(wartość slaScreen : SLAScreen)
wyświetla
uruchamia
*
zawiera
CommitmnetScreen
«uses»
*
TPENALTY
-cost
-lowIntervalNumber
-highIntervalNumber
+isAplicable(wartość failedIntervals)
TPARAMETER
TMEASURE
MeasureValue
-calendar : Calendar
-value
generuje
CommitmentDefinitionAction
1
-aggregationID : short(idl)
-interval : TINTERVAL
-statistic : TSTATISTIC
-parameter : TPARAMETER
+getAggregation()
+apply(wartość parameter : TPARAMETER, wartość calendar : Calendar)
+save()
+doPerformAction(wartość commitmentScreen : CommitmnetScreen)
1
1
ParameterScreen
+renderScreen()
wyświetla
1
-prmId : short(idl)
-prmName : string(idl)
-prmURL : string(idl)
-prmActive : string(idl)
-prmFileName : string(idl)
+getParameter(wartość name)
«uses»
TPARAMETERVALUES
TINTERVAL
-intervalId : short(idl)
-intervalName : string(idl)
+getInterval()
+startDate()
+endDate()
+getTimeBox()
+chopCalendar(wartość calendar : Calendar)
1
1
*
1*
1
«traces»
+renderScreen()
+count(wartość intervalNumber)
+addPenalty(wartość lowNo, wartość highNo, wartość cost)
+getParameterValues(wartość parameter : TPARAMETER, wartość calendar : Calendar)
+getParameter() : TPARAMETER
1
TSTATISTIC
1
uruchamia
-statisticId : short(idl)
-statisticName : string(idl)
+getStatistic()
+apply(wartość valueList)
ParameterDefinitionAction
+doPerformAction(wartość parameterScreen : ParameterScreen)
TMONTH
TWEEK
TDAY
THOUR
TAVG
TSUM
TMIN
TMAX
TRANGE
Rys. 8. Diagram klas aplikacji SLM
Struktura danych aplikacji SLM podzielona jest na dwa pakiety:
• Pakiet widoku i kontrolera
• Pakiet modelu
Klasy widoku i kontrolera mogą być powiązane z pakietem Apache Struts i wspólnie tworzyć
aplikację webową gotową do wdrożenia na dowolnym serwerze aplikacyjnym Java 2 EE.
Klasy modelu zasadniczo odpowiadają modelowi danych w relacyjnej bazie danych tworząc
mapowanie z dziedziny relacyjnej do obiektowej. Każda z klas modelu, której instancje mogą
być powoływane w czasie działania aplikacji, implementuje metody pozwalające na jej
zapisanie w bazie danych oraz metodę statyczną pozwalającą na utworzenie nowego
egzemplarza klasy. Nie jest przewidywane powoływanie obiektów bezpośrednio lecz
wyłącznie poprzez metodę fabrykującą każdej z klas bazowych modelu.
TUSER
31
Klasa reprezentuje użytkownika systemu – reprezentanta strony umowy SLA. Każda ze stron
powinna mieć przynajmniej jednego reprezentanta w tym najwyżej jednego administratora
umowy ze strony dostawcy. Klasa jest zapisywana w sposób trwały w tabeli SLM_USERS.
TROLE
Klasa reprezentuje rolę użytkownika w systemie co pozwala regulować uprawnienia do
poszczególnych jego funkcjonalności. Wyróżnionymi rolami są:
• administrator umowy ze strony dostawcy
• administrator umowy ze strony odbiorcy
Klasa jest zapisywana w sposób trwały w tabeli SLM_ROLES
TACCOUNT
Klasa realizuje przypisanie ról do użytkowników w ramach poszczególnych umów SLA.
Klasa jest zapisywana w sposób trwały w tabeli SLM_ACCOUNTS.
TSERVICE
Klasa reprezentuje usługę której dotyczy umowa. Klasa jest zapisywana w sposób trwały w
tabeli SLM_SERVICES.
TUNIT
Klasa reprezentuje jednostkę organizacyjną będącą stroną umowy SLA. Klasa jest
zapisywana w sposób trwały w tabeli SLM_UNITS
TTYPE
Klasa reprezentuje rolę jaką parametr może pełnić w danej umowie SLA. Wyróżnione są dwa
typy parametrów:
• parametry utrzymania
• parametry wykorzystania
Klasa jest zapisywana w sposób trwały w tabeli SLM_TYPES.
TBASEOBJ
Klasa abstrakcyjna podstawowa dla klas TSLA, TCOMMITMENT i TCOMMITMENTDEF
definiująca metodę isSatisfied, która pozwala stwierdzić czy dany element spełnia
wymagania umowy.
TSLA
Klasa odpowiada tabeli SLA w relacyjnym modelu danych i udostępnia metody pozwalające
na:
• Ustalenie administratorów umowy ze strony dostawcy
• Ustalenie administratorów umowy ze strony odbiorcy
• Weryfikację statusu umowy
Obiekty tej klasy są zapisywane w sposób trwały w tabeli SLM_SLA.
TCOMMITMENT
Klasa reprezentująca zobowiązanie pomiędzy jednostką organizacyjną – dostawcą usługi a
jednostką organizacyjną – odbiorcą usługi. Pozwala określić:
• Odbiorcę
• Dostawcę
• Usługę będącą przedmiotem umowy
• Datę powstania związku pomiędzy dostawcą a odbiorcą
• Rodzaj zobowiązania (utrzymanie, wykorzystanie)
Obiekty tej klasy są zapisywane w sposób trwały w tabeli SLM_COMMITMENT.
TUSAGECOMMITMENT
Klasa potomna względem klasy TCOMMITMENT reprezentująca zobowiązania odbiorcy do
nie przekraczania określonych umową poziomów wykorzystania usługi.
TSUPPORTCOMMITMENT
Klasa potomna względem klasy TCOMMITMENT reprezentująca zobowiązania dostawcy do
zapewnienia określonych umową poziomów utrzymania usługi.
TPARAMETER
32
Klasa reprezentująca parametr, pozwalający na określenie w jaki sposób zachowuje się
dana usługa.
Obiekty tej klasy są zapisywane w sposób trwały w tabeli SLM_PARAMETERS.
TMEASURE
Klasa reprezentuje miernik usługi zdefiniowany w umowie SLA. Mierniki są definiowane jako
powiązanie parametru, rodzaju okresu w jakim badane są jego wartości oraz statystyki
agregującej wartości parametru w zadanym okresie. Jeżeli dla danego parametru zostanie
wybrany okres – godzina i statystyka-średnia, oznacza to że badane będą przekroczenia
zadanych ograniczeń dla wartości średnich w godzinie.
Obiekty tej klasy są zapisywane w sposób trwały w tabeli SLM_MEASURES.
TINTERVAL
Klasa abstrakcyjna reprezentująca rodzaj okresu agregacji parametrów. Klasa udostępnia
metodę zwracającą listę kolejnych obiektów klasy Calendar reprezentujących największą
pełną liczbę okresów agregacji mieszczących się pomiędzy podaną datą początku i końca
analizy.
Obiekty tej klasy są zapisywane w sposób trwały w tabeli SLM_INTERVALS.
TMONTH
Klasa potomna względem klasy TINTERVAL reprezentuje miesięczne agregacje wartości
parametrów.
TWEEK
Klasa potomna względem klasy TINTERVAL reprezentuje tygodniowe agregacje wartości
parametrów.
TDAY
Klasa potomna względem klasy TINTERVAL reprezentuje dzienne agregacje wartości
parametrów.
THOUR
Klasa potomna względem klasy TINTERVAL reprezentuje godzinowe agregacje wartości
parametrów.
TSTATISTIC
Klasa abstrakcyjna reprezentująca statystykę według której przeprowadzona będzie
agregacja wartości parametru. Obiekty tej klasy są zapisywane w sposób trwały w tabeli
SLM_STATISTIC.
TSUM
Klasa potomna względem klasy TSTATISTIC reprezentująca sumowanie.
TAVG
Klasa potomna względem klasy TSTATISTIC reprezentująca uśrednianie
TMIN
Klasa potomna względem klasy TSTATISTIC reprezentująca odnajdywanie wartości
minimalnej
TMAX
Klasa potomna względem klasy TSTATISTIC reprezentująca odnajdywanie wartości
maksymalnej
TRANGE
Klasa potomna względem klasy TSTATISTIC reprezentująca odnajdywanie odstępu
pomiędzy wartością maksymalną a minimalną parametru.
TTHRESHOLD
Klasa reprezentuje ograniczenia górne i dolne nałożone na wartość miernika w ramach
określonego zobowiązania. Klasa udostępnia informacje na temat:
• Powiązanego zobowiązania
• Powiązanego miernika
• Wartości górnego ograniczenia
• Wartości dolnego ograniczenia
• Początku i końca obowiązywania ograniczeń.
Obiekty tej klasy są zapisywane w sposób trwały w bazie danych w tabeli
SLM_TRESHHOLDS.
33
TPARAMETERVALUES
Klasa reprezentuje pojedynczy pomiar parametru zapisany w bazie danych. Udostępnia
metody pozwalające na pobranie listy pomiarów danego parametru za podany okres.
Obiekty tej klasy przechowywane są w tabeli SLM_PARAMTER_VALUES.
TPENALTYSCHEME
Klasa reprezentuje model naliczania kar za niedotrzymanie postanowień umowy a konkretnie
za naruszenie ograniczeń określonych w konkretnym zobowiązaniu. Model naliczania kar
jest implementowany w postaci funkcji odcinkami liniowej której definicja jest przechowywana
w o postaci listy obiektów klasy TPENALTIES
Obiekty tej klasy przechowywane są w tabeli SLM_PENALTY_SCHEMES
TPENALTIES
Obiekty klasy przechowują kolejne odcinki w definicji funkcji kar za naruszenie postanowień
umowy.
Obiekty tej klasy przechowywane są w tabeli SLM_PENALTIES
Calendar
Klasa reprezentuje odstęp czasu. Przechowuje datę początku i końca tego okresu może być
to wielokrotność jednego z okresów agregacji parametrów lecz nie jest to wymagane.
MeasureValue
Klasa reprezentuje jednostkę zagregowanej wartości parametru. W wyniku agregacji
parametrów za wskazany okres powstaje lista obiektów tej klasy które mogą służyć
porównaniu z Pragami zadanymi w ograniczeniu.
SLAScreen
Klasa interfejsu użytkownika realizująca ekran definicji podstawowych parametrów umowy.
SLADefinitionAction
Klasa kontrolera realizująca operacje zlecone przez użytkownika na ekranie SLAScreen.
CommitmentScreen
Klasa interfejsu realizująca ekran definicji zobowiązania.
CommitmentDefinitionAction
Klasa kontrolera realizująca operacje zlecone przez użytkownika na ekranie
CommitmentScreen
ParameterScreen
Klasa interfejsu realizująca ekran definicji miernika do zobowiązania
ParameterDefinitionAction
Klasa kontrolera realizująca operacje zlecone przez użytkownika na ekranie
ParameterScreen.
6.3.4. Dynamiczne aspekty systemu
Przypadki użycia systemu inicjowane przez aktorów – użytkowników aplikacji grupują się w
kilku podstawowych operacjach do których dostęp jest możliwy z poziomu poszczególnych
ekranów aplikacji klienckiej.
Wprowadzanie nowej umowy do systemu użytkownik rozpoczyna od definicji podstawowych
parametrów samej umowy. Na ekranie użytkownik wpisuje tytuł umowy oraz inne informacje
identyfikacyjne samego dokumentu. Następnie wybiera z listy rozwijanej użytkowników oraz
role i tworzy kolejne przypisania ról do użytkowników w ramach definiowanej umowy. Do
tego ekranu dostęp prowadzi również poprzez operację edycji umowy SLA. W przypadku
edycji nie ma możliwości modyfikacji sygnatury umowy lecz jedynie opis i przypisanie ról do
użytkowników. Po zakończeniu działać stan modelu zapisywany jest w bazie danych. Na
ilustracji kooperacji podanej poniżej przedstawiona jest sekwencja wywołać operacji na rzecz
poszczególnych obiektów.
34
Rys. 9. Definicja podstawowych parametrów umowy
Po wprowadzeniu umowy do systemu użytkownik jest kierowany do ekranu definicji
zobowiązań. Na ekranie definicji zobowiązań użytkownik wybiera z listy rozwijanej jednostki
organizacyjne będące stronami zobowiązania oraz określa typ zobowiązania.
Rys. 10. Definicja zobowiązania
Zatwierdzenie operacji przez użytkownika powoduje pobranie obiektu SLA dla definiowanej
umowy. Następnie tworzone są obiekty dostawcy i odbiorcy usługi związanych
zobowiązaniem. W ostatnim kroku w zależności od rodzaju zobowiązania wybranego przez
użytkownika tworzony jest obiekt zobowiązania dostawcy wobec odbiorcy (utrzymanie), lub
35
odbiorcy wobec dostawcy (wykorzystanie). Po zakończeniu stan modelu zapisywany jest w
bazie danych.
Ostatni ekran definicji umowy służy do określenia mierników zobowiązania. Na ekranie
definicji mierników i ograniczeń użytkownik wybiera datę początku i końca obowiązywania
ograniczenia oraz maksymalną i minimalna wartość ograniczenia
Rys. 11. Definicja ograniczeń i miernika
Następnie określa na podstawie listy wyboru parametr, okres agregacji wartości parametru
oraz statystykę agregującą. W ostatnim etapie definiowany jest model naliczania kar.
Operacja ta ma charakter iteracyjny. W każdej iteracji definiowany jest jeden element funkcji
kary poprzez podanie dolnej i górnej granicy liczby cykli w których zobowiązanie nie zostało
spełnione, oraz kwoty kary za jeden cykl. W szczególnym przypadku gdy funkcja kary
zdefiniowana jest jako liniowa zależność wysokości kary od liczby cykli niedostępności usługi
następuje tylko jedna iteracja przy czym górna granica liczby cykli nie jest podawana.
Zatwierdzenie dokonanych wyborów powoduje wywołanie sekwencji operacji kontrolera jak
to zostało przestawione na powyższym diagramie kooperacji. Po zakończeniu działania
kontroler wywołuje operacje zapisania stanu modelu w bazie danych.
Weryfikacja umowy SLA jest możliwa z poziomu interfejsu użytkownika. Ekran weryfikacji
umów prezentuje listę umów których użytkownikiem jest zalogowana osoba. Przy każdej
36
umowie wyświetlona jest informacja o statusie umowy. Umowa jest oznaczona jako
naruszona jeżeli naruszone jest przynajmniej jedno zobowiązanie. W innym przypadku
umowa jest dotrzymana.
1: isSatified(calendar)
1.1.1: isSatified(calendar)
1.1: isSatified(calendar)
sla
comitment
interval
threshhold
.
1.1
:
1.2
ply
ap
ra
(pa
te
me
{LUB}
ar)
nd
ale
r, c
{LUB}
{LUB}
:
3.1
.1.
1.1
o
ch
pC
le
ca
ar (
nd
ale
a
nd
r)
dla wszystkoch kalendarzy interwału: getParameterValues(parameter, calendar)
measure
paramValues
dla
countPenalty:=countPenalty(calendar)
sla
commitment
threshold
ws
zys
tkic
h
kale
nda
rzy
inte
rwa
łu:
ap
ply
(va
lue
Lis
t)
statistic
Rys. 12. Weryfikacja stanu umowy
Zobowiązanie jest dotrzymane jeżeli wszystkie ograniczenia obowiązujące w danym okresie
są spełnione, przy czym pod uwagę brane są jedynie ograniczenia obowiązujące przez co
najmniej jeden pełny okres dla którego zdefiniowany jest miernik dla tych ograniczeń.
Spełnienie ograniczenia sprawdzane jest poprzez następującą sekwencją operacji. W
pierwszym kroku pobierana jest lista pełnych rzeczywistych okresów właściwych dla danego
miernika ograniczenia. Dla każdego z tych okresów pobierana jest lista wartości parametru z
danego okresu i przeprowadzana jest jego agregacja według podanej w definicji miernika
statystyki. Jeżeli wynik agregacji mieści się w przedziale podanym w ograniczeniu
ograniczenie jest spełnione w innym przypadku ograniczenie nie jest spełnione.
Alternatywnie użytkownik może podejść do sprawdzenia wysokości naliczonych kar za
niespełnienie postanowień umowy SLA. Weryfikacja wysokości kar przypisanych do umowy
SLA powoduje wywołanie operacji sprawdzenia wysokości kar dla każdego zobowiązania
przypisanego do umowy co z kolei powoduje sprawdzenie wysokości naliczonych kar dla
każdego obowiązującego ograniczenia związanego z tym zobowiązaniem.
7. Realizacja
Aplikacja zaprojektowana zgodnie z założeniami przedstawionymi powyżej jest
implementowana w Instytucie Łączności. Implementacja zakłada konieczność zastosowania
popularnych technologii dostępnych w większość przedsiębiorstw. Ma to na celu obniżenie
kosztów produkcyjnego wdrożenia systemu w środowisku docelowym.
Jako serwer bazy danych zastosowano RDBMS Oracle jako de facto standard w
rozwiązaniach korporacyjnych. Jako język implementacji sterowania warstwy zasilania
wybrano PERL jako język skryptowy dostępny na większości systemów operacyjnych. Do
implementacji interfejsu użytkownika wybrano język JAVA
7.1.
Wyładowanie danych z systemów źródłowych
Etap wyładowania danych źródłowych z systemów realizowany jest przez usługi, których
implementacja jest niezależna od struktury samego systemu monitorowania SLA. Takie
37
założenie ma ułatwić wdrożenie aplikacji w zróżnicowanych środowiskach jakie funkcjonują
w przedsiębiorstwach będących grupą docelową dla projektowanego systemu. Architektura
systemu narzuca jedynie format danych wyjściowych z modułów wyładowujących dane.
Poniżej przedstawiono proponowane przez autorów rozwiązanie dla realizacji podsystemu
wyładowywania danych. Zostało ono zaimplementowane w sieci komputerowej Instytutu
Łączności.
Parametry usług zbierane na potrzeby aplikacji pobierane są z bazy typu RRD
(Round Robin Database) zaimplementowanej w postaci aplikacji RRDtool autorstwa Tobiasa
Oetikera. Aplikacja ta stała się faktycznym standardem dla przechowywania danych
zebranych w wyniku monitorowania infrastruktury informatycznej. Do efektywnego
przechowywania wykorzystywana jest cykliczna baza danych. Archiwum cykliczne
przechowuje określoną ilość pobranych danych i zaczyna nadpisywać najstarsze wartości w
momencie zakończenia jednego i rozpoczęcia nowego cyklu. Ponadto, istnieje możliwość
utworzenia w obrębie bazy dodatkowych archiwów, które mogą przechowywać zagregowaną
wartość (np. średnia, minimum, maksimum) próbki za dłuższy okres czasu.
Cykliczna baza danych korzysta z wielu tzw. źródeł, które przechowują informacje na temat
pojedynczego parametru. Administrator zobligowany jest do podania czterech wartości dla
każdego źródła danych w trakcie tworzenia bazy danych: nazwę, rodzaj źródła danych, ilość
danych pobieranych w jednym kroku oraz progowe wartości minimum i maksimum. Nazwa w
sposób jednoznaczny identyfikuje źródło danych w RRDtool. Rodzaj źródła określa, czy mają
być zapisywane dokładne wartości czy ich zmiana w stosunku do poprzedniej wartości.
7.1.1. Kryteria wyboru parametrów
Podczas wyboru parametrów przyjęto następujące kryteria:
•
monitorowane parametry powinny być próbkowane nie rzadziej niż raz na 10 minut;
•
powinna istnieć możliwość
zakończonego dnia;
•
parametry powinny być częściowo z sobą skorelowane tak aby analiza ich wartości
mogła pokazywać zależności między nimi.
pobrania
pełnego
spektrum
próbek
z
całego
Wynikiem tych rozważań było przyjęcie założenia, że analizie będą podlegały usługi
w3cache oraz usługa pocztowa działające na serwerze berd. Ponadto założono, że pliki
tekstowe z wartościami próbek parametrów powinny być dostępne przez protokół HTTP.
7.1.2. Przykładowe parametry wykorzystywane na potrzeby systemu
Do analizy pracy usługi w3cache wybrano następujące parametry:
•
w3cache_hit_ratio - współczynnik trafień próbkowany; baza hitratio.rrd;
•
w3cache_number_of_request – liczba odwołań ze strony klientów (przeglądarek);
baza requests.rrd
•
w3cache_number_of_hits – liczba trafień; baza requests.rrd
Do analizy usług pocztowych wybrano następujące parametry:
•
mail_sent – liczba wysłanych listów; baza mailgraph.rrd
•
mail_received – liczba odebranych listów; baza mailgraph.rrd
•
mail_rejected
mailgraph.rrd
•
mailqueue_active – liczba aktywnych listów w kolejce; baza mailqueues.rrd
•
mailqueue_deferred – liczba odroczonych listów w kolejce; baza mailqueues.rrd
–
liczba
listów
zablokowanych
Wszystkie parametry próbkowane są co 5 minut.
38
do
odebrania
(spam);
baza
7.1.3. System pobierania danych z baz cyklicznych
Program do pobierania danych z baz cyklicznych został napisany w języku perl. Do jego
implementacji zostały wykorzystane następujące moduły:
•
RRDTool:OO – udostępnia obiektowy interfejs do bazy RRDtool;
•
IO::File – wspiera mechanizm równoległego
zastosowanie referencji do otwartych plików.
zapisywania
danych
poprzez
Program łączy się z odpowiednimi bazami RRDtool i pobiera z nich dane z okresu minionego
dnia. Następnie są one zapisywane do plików tekstowych. Pliki te zawierają dwie kolumny.
Pierwsza określa czas pobierania próbki w formacie RRRR-MM-DD HH24:MI:SS. W drugiej
kolumnie podana jest wartość parametru. Kolumny rozdzielone są średnikiem.
7.1.4. Środowisko pracy
Skrypt realizujący pobieranie danych ma nazwę rrd.pl i uruchamiany jest przez program perl
w wersji 5.6.1 na serwerze berd. Znajduje się w katalogu /home/berd/p7/wojtek/cvs/rrd.
Jest on automatycznie uruchamiany codziennie o godzinie 0.05 przez program cron. Logi
działania programu zapisywane są w pliku /home/berd/p7/wojtek/cvs/rrd/rrd.log.
Bazy cykliczne programu RRDtool przechowywane są odpowiednio w podkatalogach cache i
mail katalogu /services/mrtg-2/stat zaś pliki wynikowe o nazwach odpowiadających nazwom
parametrów z dodaną końcówką „.txt” zapisywane są do katalogu /services/intranet/data/slm.
Pliki
widoczne
są
w
Intranecie
https://intranet.itl.waw.pl/slm/<nazwa_parametru>.txt,
https://intranet.itl.waw.pl/slm/mailqueue_active.txt
Instytutu
Łączności
jako
np.
Skryptowe pobieranie plików można zrealizować z wykorzystaniem programów wget lub
lynx,
np.:
wget http://intranet.itl.waw.pl/slm/w3cache_hit_ratio.txt
lub
lynx -source http://intranet.itl.waw.pl/slm/mail_sent.txt
7.2.
Ładowanie danych do bazy danych systemu.
Wyładowywane dane są pobierane przez podsystem transformacji i ładowania danych do
bazy systemu monitorowania umów SLA. Warstwę ta jest realizowana przez następujące
skrypty zaimplementowane w języku PERL:
• extract.pl – wyładowanie danych z systemów monitorujących
• transform.pl – załadowanie danych z plików do tabel dziennych w bazie danych
• load.pl – załadowanie danych z tabel dziennych do tabeli SLM_PARAM_VALUES
extract.pl
1.
2.
3.
4.
pobranie z parametrów wywołania datę za którą wykonywane jest zasilanie.
nawiązanie połączenia z bazą danych
pobranie listy URL do wszystkich wykorzystywanych parametrów
pobranie danych za pomocą uzyskanych URL i zapisanie ich w plikach
oznaczonych datą zasilania.
Wejście:
• Dane użytkownika bazy danych (nazwa, hasło SID)
• Katalog docelowy na pliki zaimportowanych danych
Wyjście
• Pliki z wyładowaniem wartości parametrów w formacie CSV. Nazwa pliku
składa
się
ze
złożenia
wartości
z
kolumny
SLM_PARAMETERS.PRM_CODE z datą zasilania i rozszerzeniem DAT.
39
transform.pl
1. pobranie z parametrów wywołania datę za którą wykonywane jest zasilanie.
2. nawiązanie połączenia z bazą danych
3. pobranie z bazy danych nazw kodowych poszczególnych parametrów
4. usuniecie o ile istnieją tabel o nazwach takich jak pobrane nazwy parametrów
5. utworzenie pustych tabel o nazwach takich jak pobrane nazwy parametrów
6. wywołanie programu SQL leader w celu załadowania do nowoutworzonych
tabel danych zawartych w pobranych w etapie poprzednim plikach.
Wejście
• Pliki z wyładowaniem wartości parametrów w formacie CSV. Nazwa
pliku
składa
się
ze
złożenia
wartości
z
kolumny
SLM_PARAMETERS.PRM_CODE z datą zasilania i rozszerzeniem
DAT.
Wyjście
• Tabele tymczasowe w bazie danych zawierające wyładowanie danych
za jeden dzień
load.pl
1.
2.
3.
4.
pobranie z parametrów wywołania datę za którą wykonywane jest zasilanie.
nawiązanie połączenia z bazą danych
pobranie z bazy danych identyfikatorów i nazw poszczególnych parametrów
usuniecie o ile istnieją w tabeli SLM_PARAMETER_VALUES wartości
parametrów oznaczonych datami pomiarów identycznymi jak w tabeli
tymczasowej dla danego parametru
5. załadowanie
wartości
z
tabeli
tymczasowej
do
tabeli
SLM_PARAMETER_VALUES
Wejście
• Tabele tymczasowe w bazie danych zawierające wyładowanie danych
za jeden dzień
Wyjście
• Uzupełniona tabeli SLM_PARAMETER_VALUES
Skrypty zasilające są uruchamiane cyklicznie raz dziennie zasilając bazę danych w kolejne
porcje informacji o przebiegu monitorowanych parametrów.
8. Wnioski
Celem opracowywania powyższego systemu jest umożliwienie małym i średnim
przedsiębiorstwom wdrożenia procedur monitorowania podpisanych umów SLA zarówno z
punktu widzenia dostawcy jak i odbiorcy usługi. Wykonany projekt oraz testy wybranych
funkcjonalności wykazały iż realizacja takiego systemu jest możliwa przy niedużej ingerencji
w istniejące systemy informatyczne przedsiębiorstwa. Pozwala to ograniczyć koszt
wdrożenia i sprawi że produkt taki będzie dostępny dla szerszej grupy odbiorców niż
specjalizowane systemy realizowane na zamówienie.
40
Bibliografia
[1] J. Case, K. McCloghrie, M. Rose, and S.Waldbusser. Management Information Base for
Version 2 of the Simple Network Management Protocol (SNMPv2). SNMPv2 Working Group,
January 1996. RFC1907.
[2] J. D. Case, M. Fedor, M. L. Schoffstall, and C. Davin. Simple Network Management
Protocol
(SNMP), May 1990. RFC1157.
[3] Douglas E. Comer. Sieci komputerowe TCP/IP. T. 1. Zasady, protokoły i architektura.
Wydawnictwa Naukowo-Techniczne, Warszawa, 1997.
[4] K. McCloghrie and M. T. Rose. Management Information Base for Network Management
of
TCP/IP-based internets: MIB-II, March 1991. RFC1213.
[5] M. T. Rose and K. McCloghrie. Structure and identification of management information
for
TCP/IP-based internets, May 1990. RFC1155.
[6] William Stallings. SNMP, SNMPv2, and RMON: practical network management.
AddisonWesley Publishing Company, Inc, 2nd edition, 1996.
[7] S.Waldbusser. Remote Network Monitoring Management Information Base, February
1995.
RFC1757.
[8] S. Waldbusser. Remote Network Monitoring Management Information Base Version 2
using
SMIv2, January 1997. RFC2021.
[9] John J. Lee Ron Ben-Natan.: Integrateing Service Level Agreements. Wiley Publishing,
Inc. 2002
41

Opracowanie - Instytut Łączności

Transkrypt

Podobne dokumenty

POL-AUDIO SLA 210 CX ND

kawdrog_s.11f.

PN Nazwa ilość

Od zapytania oferowego do kontraktu