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?
Wi臋cej miejsc do pos艂uchania:
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%