Service Level Agreement (SLA) jest to porozumienie pomiędzy

Transkrypt

Service Level Agreement (SLA) jest to porozumienie pomiędzy
SERVICE LEVEL AGREEMENT (SLA) – CZ. I
Service Level Agreement (SLA) jest to porozumienie pomiędzy klientem
a dostawcą usługi.
SLA powinno określać w sposób jasny i zrozumiały dla klienta, czego
może on oczekiwać w ramach danej usługi. Kontrakt taki powinien
również zawierać jednoznacznie określone sposoby oceny jakości
otrzymywanej usługi, czyli zgodności dostarczonej usługi z zawartym
kontraktem SLA. Dodatkowo konieczne jest kontrolowanie klienta, czy
dotrzymuje warunków umowy. Ważne elementem jest również ustalenie
zakresu odpowiedzialności za złamanie kontraktu przez każdą ze stron.
Ponadto SLA powinno definiować następujące parametry:
klasę dostarczanej usługi (CoS) lub wartości gwarantowanych
parametrów QoS;
dostępność usługi;
zakres gwarantowanej obsługi technicznej;
zasady naliczania i pobierania opłat za dostarczane usługi.
SERVICE LEVEL AGREEMENT (SLA) – CZ. II
Service Level Specification (SLS) jest to zbiór parametrów
technicznych o określonych wartościach, z jakimi będzie przesyłany
przez sieć strumień pakietów związanych z daną usługą.
SLS stanowi techniczną część kontraktu SLA pomiędzy klientem a
dostawcą usługi.
W ramach IETF są prowadzone prace mające na celu szczegółowe
zdefiniowanie SLS. Dyskutowane są dwie koncepcje. Jedna z nich
zakłada możliwość dynamicznego negocjowania parametrów SLS
pomiędzy klientem i operatorem, druga zaś przewiduje opracowanie
predefiniowanych typów SLS i zasad posługiwania się nimi,
obowiązujących wszystkich operatorów.
Traffic Conditioning Specification (TCS) jest to zbiór parametrów o
określonych wartościach, który jednoznacznie określa profil ruchu oraz
reguły klasyfikowania pakietów. TCS jest pojęciem ściśle technicznym,
podczas gdy TCA jest pojęciem szerszym, obejmującym oprócz TCS
definicje poszczególnych usług i uzgodnienia z klientem. TCS jest
integralną częścią SLS.
SERVICE LEVEL AGREEMENT (SLA) – CZ. III
Traffic Conditioning Agreement (TCA) jest to porozumienie określające
reguły klasyfikowania pakietów oraz profile ruchu odpowiednie dla
różnych strumieni ruchu.
TCA definiuje zasady oznaczania pakietów (nadawanie wartości
punktu kodowego DSCP, ang. marking), odrzucania pakietów,
kształtowania ruchu (proces opóźniania pakietów mający na celu
dostosowanie strumienia ruchu do określonego profilu ruchu ang.
shaping) oraz wykonywania pomiarów ruchu (ang. Metering).
Zbiór reguł formowania ruchu zdefiniowany w TCA stanowi część SLA.
Porozumienie TCA nakłada na klienta obowiązek do stosowania
generowanego ruchu do uzgodnionego profilu ruchu z
operatorem. Określa ono również, w jaki sposób będą traktowane
pakiety klienta zarówno w przypadku zgodności z profilem ruchu,
jak i w przypadku naruszenia warunków umowy.
JAKOŚĆ USŁUG W SIECIACH PAKIETOWYCH
Pojęcie jakości usług w sieciach pakietowych to zbiór technologii,
które pozwalają użytkownikom otrzymywać od sieci przewidywalny
poziom usług w kontekście przepustowości (ang. bandwith),
opóźnienia (ang. delay) i zmienności opóźnienia (ang. jitter).
Aby węzeł danych otrzymał wymaganą jakość usług, każdy węzeł
sieci musi być powiadomiony o tych wymaganiach.
Wyróżnia się dwie metody powiadamiania o wymaganiach
związanych z jakością usług.
Etykietowanie pakietów – powiadamianie poprzez oznaczanie
pakietów.
Sygnalizacja – powiadamianie poprzez specjalny protokół.
Obecnie dominują dwa modele QoS w sieciach pakietowych:
Model oparty na rezerwacji zasobów.
Model oparty na rozróżnianiu klas ruchu.
MODEL OPARTY NA REZERWACJI ZASOBÓW
Aplikacje przy pomocy protokołu sygnalizacyjnego zgłaszają sieci
swoje wymagania z zakresu przepustowości i opóźnienia.
Węzły sieci przeprowadzają kontrolę dostępności zasobów
potrzebnych do zapewnienia żądanego poziomu usługi.
W przypadku dostępności odpowiednich zasobów następuje ich
rezerwacja tak, aby dany węzeł sieci mógł świadczyć żądaną jakość
usługi.
Rezerwacja gwarantuje aplikacji żądaną jakość usługi, o ile
generowany przez nią ruch nie przekracza zgłoszonych parametrów.
Węzeł sieciowy sprawdza i ewentualnie ogranicza ruch do
zgłoszonych parametrów.
Przykładowe rozwiązanie opierające się o model z rezerwacją
zasobów to model IEFT IntServ z użyciem protokołu RSVP.
MODEL OPARTY NA ROZRÓŻNIANIU KLAS
RUCHU
W modelu tym nie ma jawnego zgłaszania przez aplikację wymagań
co do jakości usługi, natomiast strumień danych generowany przez
aplikację zaliczany jest do jednej z kilku klas ruchu.
Każda klasa ruchu oznaczana jest odpowiednią etykietą zawartą w
pakietach danych, na podstawie której węzły sieci dostarczają
odpowiedniej jakości usług.
Węzły sieci nie dostarczają bezwzględnej jakości usług, lecz
względną, rozróżniając ruch na podstawie przynależności do danej
klasy.
Model ten jest bardzo łatwo skalowalny z tego względu, że nie ma
konieczności rozpoznawania pojedynczych strumieni danych.
Przykładowe rozwiązanie opierające się o rozróżnianie klas ruchu model
IETF DiffServ.
PODSTAWY KLASYFIKACJI PAKIETÓW
Celem jest odpowiednie zidentyfikowanie pakietów, tak aby
prawidłowo rozpoznać ich wymagania co do jakości usług.
Pakiety zostaną zakwalifikowane do odpowiedniej klasy usług na
podstawie następujących kryteriów:
źródłowy / docelowy adres IP
Numery portów TCP /UDP
interfejs
Adres MAC
Możliwa jest również klasyfikacja pakietów na podstawie warstwy aplikacji
(NBAR)
KLASYFIKACJA PAKIETÓW NBAR
NBAR – Network-Based Application Recognition
Klasyfikacja pakietów na podstawie:
Protokołów warstwy 5- 7 modelu OSI
Dynamicznie uzgadnianych portów TCP/UDP
HTTP URL
W tej chwili przez NBAR obsługiwane są np. następujące protokoły:
HTTP / URL
SAP
RealAudio
MSExchange
PeopleSoft
MS Netshow
SUN RPC
r-commands
SQL-Net
TIBCO
H.323
VDOLive
NBAR zakłada możliwość zdefiniowania obsługi nowych
protokołów poprzez skrypty w języku PDL (ang. Packet
Description Language)
ETYKIETOWANIE PAKIETÓW
Pakiet po zakwalifikowaniu do odpowiedniej klasy usług
oznaczany jest etykietą identyfikującą daną klasę usług.
Etykieta pozwala innym węzłom sieci na szybkie rozpoznawanie
klasy usług
Do technik etykietowania pakietów można zaliczyć:
Warstwa 3 modelu OSI
IPv4 IP Precedence Field
IPv4 DiffServ Differentiated Services Field
IPv6 DiffServ Differentiated Services Field
Warstwa 2 modelu OSI
IEEE 802.1d (802.1p+q) User Priority Field
MPLS Exp / CoS Field
ETYKIETOWANIE W WARSTWIE 2 MODELU OSI
Pierwsze dwa bajty - 802.1Q Tag Type, który jest ustawiany na 0x8100
– zastępuje pole “Length/Type Field”
Następne dwa bajty:
– User Priority Field (3 bity) – wskazuje na poziom priorytetu ramki
– Canonical Format Indicator (1 bit) – wskazuje na tzw. Routing Information
Field
– VLAN Identifier (12 bitów) - VID jednoznacznie wskazuje na VLAN, do
którego dana ramka przynależy
ETYKIETOWANIE W WARSTWIE 3 MODELU OSI
USTAWIENIA POLA TOS W IPv4
Minimize
delay
Maximize
throughput
Maximize
reliability
Minimize
monetary cost
Wart.
hex
Telnet/Rlogin
1
0
0
0
0x10
FTP
control
data
1
0
0
1
0
0
0
0
0x10
any bulk data
0
1
0
0
0x08
TFTP
1
0
0
0
0x10
SMTP
command phase
data phase
1
0
0
1
0
0
0
0
0x10
DNS
UDP query
TCP query
zone transfer
1
0
0
0
0
1
0
0
0
0
0
0
0x10
ICMP
error
query
0
0
0
0
0
0
0
0
0x00
any IGP
0
0
1
0
0x04
SNMP
0
0
1
0
0x04
BOOTP
0
0
0
0
0x00
NNTP
0
0
0
1
0x02
Usługa
0x08
0x08
0x00
0x08
0x00
ALTERNATYWNE ETYKIETY W IPv4
Pole DS – Differientiated Services Field opisany w RFC 2747.
ARCHITEKTURA USŁUG ZINTEGROWANYCH
• Usługi zintegrowane – rezerwacja zasobów w sieciach
– klasyfikatory
Elementy architektury
– kolejki
IntServ
– mechanizmy rezerwacji
• statyczne
• dynamiczne (protokół RSVP)
Rozszerzenia tradycyjnych mechanizmów Internetu
• Związanie każdego pakietu IP z przepływem (strumieniem
pakietów wymagających tego samego QoS)
• Kontrola dopuszczania do zasobów sieci nowego
przepływu
Założenia IntServ
• Algorytmy rutowania
• Dyscyplina kolejkowania
• Polityka odrzucania pakietów
REZERWACJA ZASOBÓW
PRZETWARZANIE PAKIETÓW W INTSERV
USŁUGI W ARCHITEKTURZE INTSERV – CZ. I
Usługi
Controlled Load
Cechy:
• Brak górnej granicy czasu opóźnienia pakietów
• Bardzo wysoki procent pakietów jest dostarczany
pomyślnie
• Aproksymacja do usługi best-effort w warunkach sieci
nieobciążonej
Zastosowania dla aplikacji:
• Adaptacyjnych czasu rzeczywistego
• Wrażliwych na szybkie zmiany obciążenia sieci
USŁUGI W ARCHITEKTURZE INTSERV – CZ. II
Usługi
Guaranted
Service
Cechy:
• Stały poziom przepustowości danych
• Górna granica czasu opóźnienia pakietów
• Brak strat pakietów
• Najbardziej wymagająca usługa w architekturze
Integrated Services
Zastosowania dla aplikacji:
• Wrażliwych na stratę pojedynczych pakietów
• Wymagających obsługi w czasie rzeczywistym
WADY USŁUG ZINTEGROWANYCH
Wysokie wymagania sprzętowe
1. Protokół sygnalizacyjny RSVP (Resource Reservation Protocol)
2. Admission control
3. Packet classification
4. Packet scheduling
Nadmiar informacji
Pomimo dużej ilości informacji sterującej wymaganej do
zastosowania w sieci architektury IntServ, pakiety danych nie
zawierają tak kluczowych dla obserwatora informacji, jak status
bieżącego QoS.
Skomplikowany routing, opóźnienia
Zmiana routingu pociąga za sobą konieczność zmiany
rezerwacji, co komplikuje zarządzanie siecią oraz powoduje
opóźnienia w ruchu pakietów.

Podobne dokumenty