20T15 Co to jest SD-WAN – Agregacja Uplink贸w

W tym odcinku pokazuj臋 jak SD-WAN pomaga w:
馃憠Agregowaniu przepustowo艣膰 wielu 艂膮cz do jednego wydajnego uplinku
馃憠Badaniu jako艣ci 艂膮cz i dynamicznym kierowaniu ruchu

W tym odcinku pokazuj臋 zalety zastosowania SD-WAN鈥檜 w zakresie agregacji 艂膮cz wielu operator贸w.

Pokazuj臋 jak bazuj膮c na 艂膮czach niegwarantowanych, zapewnia膰 jako艣膰 dla po艂膮cze艅 g艂osowych oraz wideo.

Chcesz wi臋cej informacji?

Grupa na Facebook

Wi臋cej miejsc do pos艂uchania:

Spotify

 

Transkrypcja filmu:

0:00:02.780,0:00:06.440
Czy interesuje Ci臋 jak zagregowa膰 po艂膮czenia na WAN-ie,
0:00:07.100,0:00:08.900
偶eby uzyska膰 wi臋ksz膮 przepustowo艣膰?
0:00:09.260,0:00:11.260
Albo masz problem z jako艣ci膮
0:00:11.260,0:00:13.260
po艂膮czenia z lokalizacji?
0:00:13.260,0:00:15.260
Tak, 偶eby telekonferencje wideo
0:00:15.260,0:00:18.120
czy rozmowy g艂osowe dzia艂a艂y dobrze?
0:00:18.640,0:00:20.860
Je偶eli tego typu tematy Ci臋 interesuj膮,
0:00:20.980,0:00:22.760
to ten odcinek jest dla Ciebie.

Co to jest SD-WAN – Agregacja Uplink贸w

0:00:23.860,0:00:26.660
Cze艣膰! Nazywam si臋 Darek Koralewski i dzisiaj opowiem
0:00:26.980,0:00:29.940
o agregacji 艂膮cz w rozwi膮zaniu SD-WAN.
0:00:31.260,0:00:33.480
Ale zanim do tego przejdziemy, najpierw zacznijmy
0:00:33.480,0:00:35.400
od okre艣lenia problemu.
0:00:36.220,0:00:39.020
Po co zosta艂 stworzony SD-WAN
0:00:39.260,0:00:41.240
i jakie mechanizmy zosta艂y wdro偶one,
0:00:41.260,0:00:45.040
偶eby rozwi膮za膰 problem, zwi膮zany
0:00:45.260,0:00:47.900
z nisk膮 przepustowo艣ci膮 艂膮czy.
0:00:48.500,0:00:52.460
呕eby mo偶na by艂o zagregowa膰 艂膮cze o niskiej przepustowo艣ci
0:00:52.760,0:00:56.100
w SD-WAN-ie zaimplementowano r贸偶ne algorytmy
0:00:56.100,0:00:57.640
rozk艂adania ruchu.
0:00:58.740,0:01:01.480
Opr贸cz tego, 偶eby mo偶na by艂o zastosowa膰
0:01:01.480,0:01:03.480
w rozwi膮zaniu SD-WAN-owym
0:01:03.480,0:01:05.480
wykorzystanie 艂膮cz szerokopasmowych
0:01:05.700,0:01:07.700
niegwarantowanych,
0:01:07.700,0:01:10.280
zastosowano mo偶liwo艣膰
0:01:10.500,0:01:12.500
dynamicznego prze艂膮czania 艣cie偶ki
0:01:12.600,0:01:15.480
pomi臋dzy danymi tunelami,
0:01:15.480,0:01:17.480
czy uplinkami,
0:01:17.480,0:01:19.480
je偶eli m贸wimy o doj艣ciu do Internetu,
0:01:19.880,0:01:22.060
w zale偶no艣ci od jako艣ci.
0:01:23.180,0:01:25.180
Sp贸jrzcie tutaj na tablic臋.
0:01:25.480,0:01:28.040
Je偶eli sobie popatrzymy na to
0:01:28.040,0:01:31.920
jak tunele s膮 zestawiane ze zdalnej lokalizacji.
0:01:32.220,0:01:35.480
M贸wi艂em troszeczk臋 o tym w zesz艂ym odcinku.
0:01:35.480,0:01:39.460
To dla ka偶dego koncentratora, czyli VPN koncentratora,
0:01:40.200,0:01:44.980
mamy dwa tunele, kt贸re id膮 przez ka偶dego operatora.
0:01:45.860,0:01:48.100
Je偶eli popatrzymy sobie na drugi koncentrator,
0:01:48.980,0:01:50.980
to tak samo, dwa tunele
0:01:51.320,0:01:53.320
do niego b臋d膮 prowadzi膰
0:01:53.660,0:01:57.460
przez dw贸ch r贸偶nych operator贸w.
0:01:58.040,0:02:03.200
艢wietnie. I teraz jak mo偶e to rozwi膮zanie SD-WAN-owe
0:02:03.620,0:02:05.620
zdecydowa膰, kt贸rymi tunelami
0:02:05.620,0:02:07.620
b臋dzie ten ruch kierowany.
0:02:07.620,0:02:09.620
Ta decyzja jest dynamiczna
0:02:09.620,0:02:11.980
i ona bazuje na testach jako艣ciowych.
0:02:12.480,0:02:16.140
Pierwszym z tych test贸w jest test najprostszy.
0:02:16.140,0:02:19.580
Test oparty o protok贸艂 ICMP,
0:02:19.760,0:02:21.540
czyli po prostu ping.
0:02:22.860,0:02:25.160
Zobacz, 偶e je偶eli popatrzymy sobie
0:02:25.620,0:02:28.560
[zmniejszmy tutaj z艂o偶ono艣膰 tego rysunku]
0:02:28.560,0:02:32.560
Je偶eli popatrzymy sobie na ten router w lokalizacji,
0:02:33.320,0:02:35.320
to on wykonuje nast臋puj膮ce testy:
0:02:35.480,0:02:38.560
test, kt贸ry tutaj idzie na pewno b臋dzie dotyczy艂
0:02:38.560,0:02:42.120
ka偶dego z uplink贸w do serwera w internecie
0:02:42.460,0:02:44.460
i przez drugie 艂膮cze.
0:02:47.220,0:02:50.240
I te pakiety ICMP, kt贸re b臋d膮 wraca膰,
0:02:51.860,0:02:53.860
b臋d膮 dostarcza膰 informacje
0:02:54.660,0:02:58.840
do tego routera w lokalizacji.
0:02:59.020,0:03:00.480
Na temat op贸藕nienia,
0:03:00.560,0:03:02.560
bazuj膮c na ICMP.
0:03:02.560,0:03:05.600
Jak r贸wnie偶 na temat utraty pakiet贸w.
0:03:05.840,0:03:08.800
Te dwie informacje, daj膮 nam kluczow膮
0:03:08.800,0:03:12.600
baz臋 do tego, 偶eby mo偶na by艂o programowo
0:03:12.600,0:03:16.980
zdecydowa膰 czy jako艣膰 danego tunelu,
0:03:17.200,0:03:19.720
uplinku, jest wystarczaj膮ca czy te偶 nie.
0:03:19.960,0:03:24.020
Co jeszcze badamy, 偶eby okre艣li膰 jako艣膰 dotycz膮c膮 tunelu.
0:03:24.280,0:03:27.100
Nie tylko ten element w Internecie,
0:03:28.560,0:03:32.680
ale r贸wnie偶 badana jest jako艣膰 w 艣rodku ka偶dego tunelu.
0:03:33.620,0:03:36.180
Czyli jak sobie tutaj popatrzymy na ten rysunek.
0:03:36.540,0:03:39.980
To dla ka偶dego tunelu wysy艂ane s膮 pakiety
0:03:40.720,0:03:43.080
przez ka偶dy z tych tuneli
0:03:43.080,0:03:47.680
do adresu na koncentratorze VPN-owym.
0:03:48.060,0:03:51.880
I wynik tego testu decyduje czy ten tunel b臋dzie utrzymywany.
0:03:52.020,0:03:54.860
Je偶eli te pakiety s膮 tracone,
0:03:55.080,0:03:58.320
czyli jako艣膰 na poziomie jednego operatora,
0:03:58.460,0:04:00.940
czyli czy to w chmurze MPLS-owej
0:04:01.080,0:04:03.420
czy w internecie, spada,
0:04:03.420,0:04:05.420
pakiety s膮 tracone.
0:04:05.420,0:04:07.420
Wtedy jeden z tych tuneli
0:04:07.420,0:04:09.960
lub oba, w zale偶no艣ci od operator贸w.
0:04:09.960,0:04:12.520
No ale zak艂adamy, 偶e jednocze艣nie nie wyst膮pi
0:04:12.600,0:04:15.480
ten sam problem u dw贸ch r贸偶nych operator贸w.
0:04:15.780,0:04:19.360
Na tym bazuje to za艂o偶enie balansowania
0:04:19.360,0:04:21.360
ruchu w SD-WAN-ie.
0:04:22.100,0:04:25.520
To mamy zapewnion膮 ca艂y czas jako艣膰
0:04:25.520,0:04:27.520
mo偶liwie najwy偶sz膮,
0:04:27.520,0:04:30.480
wykorzystuj膮c wszystkie z dost臋pnych po艂膮cze艅.
0:04:30.480,0:04:33.240
Je偶eli kt贸re艣 z tych po艂膮cze艅
0:04:33.240,0:04:37.000
b臋dzie s艂abej jako艣ci, tunel zostanie po艂o偶ony.
0:04:37.100,0:04:41.220
I w tym momencie trasa, kt贸ra jest rozg艂aszana te偶 przez ten tunel,
0:04:41.220,0:04:45.960
r贸wnie偶 zostanie wykasowana od strony centrali.
0:04:47.060,0:04:49.860
Dzi臋ki takiemu mechanizmowi mamy mo偶liwo艣膰
0:04:49.860,0:04:52.120
zwi臋kszenia przepustowo艣ci
0:04:52.120,0:04:54.720
na naszym po艂膮czeniu do internetu.
0:04:54.720,0:04:58.120
Czyli je偶eli mamy lokalizacj臋, gdzie jest dost臋pny jedynie
0:04:58.120,0:05:00.580
ADSL 2 Mb
0:05:00.580,0:05:04.360
to mo偶emy zagregowa膰 na przyk艂ad 4 takie po艂膮czenia
0:05:05.400,0:05:07.720
i uzyska膰 8 Mb
0:05:07.720,0:05:10.080
wykorzystuj膮c wszystkie z nich jednocze艣nie
0:05:10.080,0:05:12.780
balansuj膮c ruch na tych 艂膮czach.
0:05:12.780,0:05:15.580
Tak, 偶eby stworzy膰 wirtualne jedno
0:05:15.580,0:05:18.040
du偶e po艂膮czenie do Internetu.
0:05:19.040,0:05:21.040
Teraz poka偶臋 jak
0:05:21.560,0:05:23.700
mo偶na wykorzysta膰 r贸偶ne algorytmy
0:05:23.780,0:05:26.060
dost臋pne w rozwi膮zaniach SD-WAN-owych,
0:05:26.140,0:05:28.960
do tego, 偶eby odpowiednio kierowa膰 ruchem
0:05:28.960,0:05:32.600
w zale偶no艣ci od tego, jaki cel chcemy osi膮gn膮膰.
0:05:33.920,0:05:36.460
Pierwszy algorytm najbardziej typowy.
0:05:36.460,0:05:43.280
To jest algorytm zwi膮zany z kolejk膮 round robin.
0:05:44.780,0:05:49.620
Nie pami臋tam jak po polsku to t艂umaczenie mo偶e brzmie膰,
0:05:49.700,0:05:52.160
wi臋c je偶eli pami臋tacie, to napiszcie w komentarzu.
0:05:52.160,0:05:55.380
Ch臋tnie r贸wnie偶 si臋 z t膮 opini膮 zapoznam.
0:05:55.380,0:05:59.300
W ka偶dym razie, je偶eli chodzi o mechanizm round robin
0:05:59.300,0:06:01.480
no to za艂o偶enie jest takie, 偶e
0:06:01.480,0:06:05.540
ka偶da z sesji, kt贸ra przychodzi od laptopa,
0:06:05.540,0:06:08.040
[mo偶e tu wezm臋 inny kolorek]
0:06:09.040,0:06:13.280
czyli ka偶da z tych sesji, wychodz膮ca od laptopa b臋dzie sz艂a innym tunelem.
0:06:15.180,0:06:17.180
Pierwsza p贸jdzie t臋dy.
0:06:18.480,0:06:21.980
A druga sesja b臋dzie sz艂a t臋dy.
0:06:25.240,0:06:29.400
I ka偶da kolejna b臋dzie kierowana na inny uplink.
0:06:29.400,0:06:32.920
Je偶eli b臋dziemy mieli w grupie 4, te uplinki,
0:06:33.000,0:06:35.540
4 tunele do danego koncentratora,
0:06:35.800,0:06:38.340
no to na poszczeg贸lny tunel b臋dzie kierowana
0:06:38.340,0:06:40.000
kolejna sesja.
0:06:40.000,0:06:43.240
Kolejna mo偶liwo艣膰 to jest balansowanie
0:06:43.240,0:06:45.940
ilo艣ci膮 sesji 艂膮cza,
0:06:45.940,0:06:49.380
czyli tutaj zak艂adamy, 偶e ka偶da z sesji
0:06:49.380,0:06:52.820
jest por贸wnywalnie wa偶膮ca
0:06:52.820,0:06:56.380
je偶eli chodzi o poziom obci膮偶enia 艂膮cza.
0:06:56.380,0:06:59.420
Rozk艂adamy po prostu sesje r贸wnomiernie
0:06:59.420,0:07:01.760
na wszystkie dost臋pne tunele
0:07:01.760,0:07:05.060
i uplinki, w zale偶no艣ci od tego, co posiadamy.
0:07:05.580,0:07:09.100
Czyli je偶eli pierwsza sesja b臋dzie sz艂a sobie t臋dy,
0:07:11.800,0:07:16.620
to druga sesja p贸jdzie sobie t臋dy.
0:07:20.520,0:07:24.660
Trzecia b臋dzie sz艂a w ten spos贸b.
0:07:25.560,0:07:28.400
A czwarta sesja b臋dzie
0:07:28.400,0:07:30.880
kierowana w zale偶no艣ci od tego,
0:07:31.020,0:07:34.040
kt贸re z tych sesji nadal funkcjonuj膮.
0:07:34.260,0:07:37.740
Czyli je偶eli tutaj ta niebieska sesja ju偶 by wygas艂a,
0:07:37.740,0:07:41.720
a zielona i fioletowa nadal b臋d膮 istnie膰.
0:07:41.720,0:07:45.060
To kolejna sesja przez ten nasz router
0:07:45.060,0:07:48.320
w lokalizacji, b臋dzie oczywi艣cie kierowana
0:07:50.040,0:07:52.040
w tunel, kt贸ry jest
0:07:52.040,0:07:55.500
obci膮偶ony najmniejsz膮 ilo艣ci膮 sesji.
0:07:56.220,0:07:59.280
Kolejnym trybem rozk艂adania ruchu
0:07:59.280,0:08:01.280
jest obci膮偶enie 艂膮cza.
0:08:01.280,0:08:04.400
Czyli tu m贸wimy o wariancie, gdzie ka偶dy z uplink贸w
0:08:04.440,0:08:06.440
ma zdefiniowan膮 swoj膮 przepustowo艣膰
0:08:06.440,0:08:09.360
i ten router wie, 偶e ka偶dy z tych
0:08:09.360,0:08:11.360
mo偶liwych uplink贸w
0:08:11.360,0:08:14.720
ma 100 Mb, 20 Mb, 2 Mb…
0:08:14.720,0:08:17.380
Czyli wie jaka jest ich wydajno艣膰.
0:08:17.520,0:08:19.660
I wtedy mo偶e sobie liczy膰
0:08:19.660,0:08:24.240
ile ruchu jest przesy艂ane przez ka偶dy z uplink贸w.
0:08:24.240,0:08:27.840
I wybiera膰 tunel lub uplink
0:08:27.840,0:08:29.840
w taki spos贸b, kt贸ry umo偶liwia
0:08:29.840,0:08:34.000
optymalizacj臋 wykorzystania ka偶dego z tych uplink贸w.
0:08:34.000,0:08:38.480
Mimo, 偶e ka偶dy z nich mo偶e mie膰 inn膮 pr臋dko艣膰.
0:08:38.480,0:08:40.800
Czyli wygl膮da艂oby to w ten spos贸b, 偶e
0:08:40.800,0:08:43.180
je偶eli mamy tutaj pierwszy
0:08:43.800,0:08:45.800
pierwsze po艂膮czenie przez ten MPLS.
0:08:45.800,0:08:49.660
I to za艂贸偶my, 偶e b臋dzie 20 Mb.
0:08:51.400,0:08:55.400
A drugie po艂膮czenie przez Internet
0:08:57.480,0:08:59.480
b臋dzie 2 Mb.
0:09:00.720,0:09:03.960
To ka偶e kolejne po艂膮czenie,
0:09:03.960,0:09:06.920
czyli kolejna sesja b臋dzie
0:09:07.580,0:09:11.960
weryfikowana pod k膮tem w艂a艣nie tej przepustowo艣ci.
0:09:11.960,0:09:14.780
Czyli je偶eli mamy 20 mega do 2 mega
0:09:14.780,0:09:18.380
to prawdopodobnie jak sobie popatrzymy na rozk艂ad
0:09:18.380,0:09:20.380
poszczeg贸lnych sesji,
0:09:20.380,0:09:23.920
to tutaj tych sesji b臋dzie 10 razy wi臋cej
0:09:24.340,0:09:26.340
ni偶 z tej strony.
0:09:28.140,0:09:30.140
W ten spos贸b b臋dzie dzia艂a艂o
0:09:30.140,0:09:33.000
rozk艂adanie ruchu w oparciu o
0:09:33.140,0:09:34.620
wykorzystanie 艂膮cza.
0:09:35.380,0:09:38.180
No i na koniec taka wersja
0:09:38.180,0:09:41.280
kierowania ruchem zwi膮zana z typem sesji.
0:09:41.340,0:09:44.360
Czyli m贸wimy tu przede wszystkim o takich sesjach wra偶liwych
0:09:44.500,0:09:48.280
na op贸藕nienia i wra偶liwych na zmiany op贸藕nie艅, czyli gitter.
0:09:48.440,0:09:51.540
W op贸藕nieniach, czy jakby kierowaniu tego ruchu
0:09:51.540,0:09:54.700
dla sesji, kt贸re s膮 wideo lub audio.
0:09:54.860,0:09:58.760
I tutaj oczywi艣cie to rozwi膮zanie SD-WAN-owe musi rozpoznawa膰
0:09:58.760,0:10:00.420
aplikacyjnie dany ruch,
0:10:00.420,0:10:02.760
偶eby m贸c zrealizowa膰 taki wariant.
0:10:02.760,0:10:05.100
Natomiast wi臋kszo艣膰 z tych rozwi膮za艅,
0:10:05.100,0:10:08.140
kt贸re ja widzia艂em, tak膮 funkcjonalno艣膰 oczywi艣cie dostarczaj膮.
0:10:08.180,0:10:10.180
I dzia艂a to w ten spos贸b, 偶e
0:10:10.180,0:10:12.180
ka偶de z tych 艂膮czy, jakie jest badane
0:10:12.180,0:10:14.180
to wybierane s膮 艂膮cza,
0:10:14.180,0:10:16.180
kt贸re zapewniaj膮 w danym momencie
0:10:16.180,0:10:18.900
przy podejmowaniu decyzji, w kt贸ry tunel, kt贸ry uplink
0:10:18.900,0:10:20.880
wysy艂a膰 dan膮 sesj臋
0:10:20.880,0:10:23.440
jest badana jako艣膰
0:10:23.440,0:10:25.440
i wybierany jest uplink, kt贸ry jest
0:10:26.000,0:10:28.600
zwi膮zany z najwy偶sz膮 jako艣ci膮, najni偶szym op贸藕nieniem
0:10:28.900,0:10:30.900
i najni偶szym gitterem.
0:10:31.060,0:10:33.060
Zobaczcie jak to mo偶e na rysunku wygl膮da膰.
0:10:33.060,0:10:37.460
Mamy tutaj rozmow臋 jak膮艣 wideo, na przyk艂ad Skype.
0:10:38.080,0:10:40.960
I wychodzi na to, 偶e w tym konkretnym przypadku
0:10:40.960,0:10:44.080
MPLS ma na przyk艂ad op贸藕nienie
0:10:44.080,0:10:46.080
na poziomie 15 milisekund,
0:10:48.300,0:10:53.920
A Internet ma op贸藕nienie na poziomie 200 milisekund.
0:10:54.720,0:10:56.720
No i oczywi艣cie, patrz膮c na
0:10:56.720,0:11:00.160
perspektyw臋 tej lokalizacji, czyli tego routera,
0:11:00.160,0:11:04.000
zostanie wybrana 艣cie偶ka przez MPLS.
0:11:05.700,0:11:07.700
Tak to ma zadzia艂a膰.
0:11:08.920,0:11:11.620
Podsumowuj膮c, SD-WAN jest
0:11:11.620,0:11:13.620
narz臋dziem, gdzie mamy
0:11:13.620,0:11:16.940
wbudowane mn贸stwo mechanizm贸w badania jako艣ci,
0:11:16.940,0:11:19.820
mechanizmy, kt贸re s膮 zwi膮zane z balansowaniem
0:11:19.940,0:11:21.940
tego ruchu pomi臋dzy uplinkami.
0:11:22.700,0:11:25.480
Mamy mo偶liwo艣膰 wykorzystania jednocze艣nie
0:11:25.480,0:11:28.740
wielu z tych uplink贸w, tak 偶eby zwi臋kszy膰 przepustowo艣膰.
0:11:28.740,0:11:31.760
I jednocze艣nie zarz膮dza膰 tym kierowaniem
0:11:31.760,0:11:33.320
w spos贸b automatyczny.
0:11:33.320,0:11:35.320
Czyli je偶eli chcesz wykorzysta膰
0:11:35.320,0:11:38.320
optymalnie, wszystko co jest dost臋pne
0:11:38.500,0:11:40.500
w kontek艣cie uplink贸w w danej lokalizacji,
0:11:40.500,0:11:44.280
SD-WAN jest w艂a艣nie takim rozwi膮zaniem, kt贸re to zapewnia.
0:11:45.000,0:11:47.160
Dzi臋kuj臋 Ci za uwag臋 w tym odcinku.
0:11:47.160,0:11:49.480
I do us艂yszenia w kolejnym.

%MCEPASTEBIN%


Autor: Darek Koralewski

Od pocz膮tku swojej kariery, czyli od 2004 roku, zajmuj臋 si臋 sieciami komputerowymi ze szczeg贸lnym uwzgl臋dnieniem ich bezpiecze艅stwa oraz sieciami programowalnymi. Mam na swoim koncie ca艂膮 list臋 certyfikat贸w r贸偶nych producent贸w, dwa najwa偶niejsze to te po艣wiadczaj膮ce najwy偶szy poziom wiedzy eksperckiej z zakresu rozwi膮za艅 Aruba ClearPass ACCX#901 oraz z projektowania sieci opartych o rozwi膮zania Aruba ACDX#1255. Wi臋cej informacji mo偶esz znale藕膰 na moich portalach spo艂eczno艣ciowych.