CCIE.pl

site 4 CCIE wannabies
Dzisiaj jest 20 sty 2018, 12:02

Strefa czasowa UTC+01:00




Nowy temat  Odpowiedz w temacie  [ Posty: 2 ] 
Autor Wiadomość
 Tytuł: L3 DC Design
Post #1 : 29 lis 2015, 13:15 
Offline
CCIE
CCIE

Rejestracja: 17 gru 2010, 15:23
Posty: 791
Lokalizacja: Dublin
Witam,

Przeczytałem sobie ostatnio draft Use of BGP for routing in large-scale data centers i wydaje się to dość ciekawe podejście.

Ale nasuwa mi się kilka następujących pytań:

Jeśli dla każdego serwera będziemy mieli P2P subnet, która będzie rozgłaszana prze BGP, to jak osiągnąć Active/Active w przypadku podłączenia takiego serwera do dwóch rożnych ToR switchy? W przypadku P2P jest to dość zrozumiale, mamy jeden link od serwera do ToR switch i subnet /30 albo nawet /31. Idac dalej, jeśli chcielibyśmy zastosować A/A vPC to obecnie vPC nie wspiera L3, wiec pozostaje nam tworzenie SVI na każdym z ToR switch ale wtedy, wydaje mi sie, ze odchodzimy od celu jaki stawia w/w draft czyli L3 DC design.
Redundancje A/S można zastosować i skonfigurować drugi link z tym samym subnet, ponieważ w przypadku A/S drugi link będzie down wiec taki subnet nie będzie w RIB i w momencie failower zostanie podniesiony. Jak zastosować redundancje A/A nap z VPC, ponieważ vPC nie wspiera L3 i nie możemy aktualnie przypisać IP bezpośrednio do VPC? Moze, ktoś ma pomysł jak osiągnąć A/A w takim przypadku?


Kolejne pytanie co w przypadku jeśli mamy ESX na, którym jest np 100 hostów jak osiągnąć P2P link pomiędzy ToR switch a VM. Jedyne co mi przychodzi do głowy to to zastosowanie VM-FEX i skonfigurowanie IP na wirtualnym porcie, chociaż nie wiem czy jest taka możliwość, nigdy tego nie testowałem. Druga możliwość to stworzenie subinterfejsow w stronę ESX i zrobienie na każdym z nich P2P subnet dla poszczególnych wirtualnych maszyn.

Kolejna sprawa to na przykład jeśli chwielibyśmy zrobić vMotion to przy takim design nie mamy takiej możliwości bo wszystkie linki to L3. Wiec jeśli chcemy przenieść serwer z jednego DC do drugiego to musimy skonfigurować w drugim DC L3 P2P subnet itd. co wymaga czasu i z perspektywy sys Admin wymaga zaangażowania Network Team, gdzie przy L2 pomiędzy dwoma DC sys admin, może wykonać taka operacje bez angażowania Netwrok inżyniera. Jak w/w design wiec osiągnąć mobility pomiędzy rożnymi DC?



Myślałem, również o tym jak wyglądałoby usytuowanie FW w takim design i zarządzanie rulami. Tworzenie rule per /30 lub /31 subnet dla każdego serwer raczej mija się z celem. Jak sadzicie jaki byłoby najlepsze podejście w takim przypadku. Myślę, ze dobrze było by grupować mniejsze podsieci w subnet /24 i na takiej podstawie tworzyć rule. Chętnie się dowiem co inni to tym sadza.



Pozdro,


Na górę
Post #2 : 29 lis 2015, 23:20 
Offline
CCIE/CCDE
CCIE/CCDE
Awatar użytkownika

Rejestracja: 08 mar 2004, 12:17
Posty: 2327
Lokalizacja: Wawa
Cytuj:
Przeczytałem sobie ostatnio draft Use of BGP for routing in large-scale data centers i wydaje się to dość ciekawe podejście.
Postrzegam je, jako rozwiązanie do DC active/standby lub DR. Ewentualnie A/A jeżeli jest to zrobione na poziomie aplikacji.
Cytuj:
Jeśli dla każdego serwera będziemy mieli P2P subnet, która będzie rozgłaszana prze BGP, to jak osiągnąć Active/Active w przypadku podłączenia takiego serwera do dwóch rożnych ToR switchy?
A/A można uzyskać poprzez odpowiednie napisanie aplikacji, które korzystają z różnych adresów IP i wykonywany jest geo load-balancing. Można by też wykorzystać anycast, co w routingu nie sprawia problemów. Nie sądzę jednak, by ktoś napisał synchronizację sesji dla front-endu. Jeszcze inny sposób do sieci nakładkowe np. VXLAN.
Cytuj:
W przypadku P2P jest to dość zrozumiale, mamy jeden link od serwera do ToR switch i subnet /30 albo nawet /31. Idac dalej, jeśli chcielibyśmy zastosować A/A vPC to obecnie vPC nie wspiera L3, wiec pozostaje nam tworzenie SVI na każdym z ToR switch ale wtedy, wydaje mi sie, ze odchodzimy od celu jaki stawia w/w draft czyli L3 DC design.
Redundancje A/S można zastosować i skonfigurować drugi link z tym samym subnet, ponieważ w przypadku A/S drugi link będzie down wiec taki subnet nie będzie w RIB i w momencie failower zostanie podniesiony. Jak zastosować redundancje A/A nap z VPC, ponieważ vPC nie wspiera L3 i nie możemy aktualnie przypisać IP bezpośrednio do VPC? Moze, ktoś ma pomysł jak osiągnąć A/A w takim przypadku?
W designie L3 nie przejmowałbym się vPC. Redundancję można zapewnić na poziomie aplikacji, na poziomie DVS/AVS lub funkcjonalności "pervasive gateway" w ACI w przypadku vPC.
Cytuj:
Kolejne pytanie co w przypadku jeśli mamy ESX na, którym jest np 100 hostów jak osiągnąć P2P link pomiędzy ToR switch a VM. Jedyne co mi przychodzi do głowy to to zastosowanie VM-FEX i skonfigurowanie IP na wirtualnym porcie, chociaż nie wiem czy jest taka możliwość, nigdy tego nie testowałem. Druga możliwość to stworzenie subinterfejsow w stronę ESX i zrobienie na każdym z nich P2P subnet dla poszczególnych wirtualnych maszyn.
Ponownie, łatwiej będzie wykorzystać overlay i wykorzystać różne adresy IP pod VTEP w ramach puli /24 dostępnej na łączu L3.
Cytuj:
Kolejna sprawa to na przykład jeśli chwielibyśmy zrobić vMotion to przy takim design nie mamy takiej możliwości bo wszystkie linki to L3. Wiec jeśli chcemy przenieść serwer z jednego DC do drugiego to musimy skonfigurować w drugim DC L3 P2P subnet itd. co wymaga czasu i z perspektywy sys Admin wymaga zaangażowania Network Team, gdzie przy L2 pomiędzy dwoma DC sys admin, może wykonać taka operacje bez angażowania Netwrok inżyniera. Jak w/w design wiec osiągnąć mobility pomiędzy rożnymi DC?
Mobility można osiągnąć poprzez Routed vMotion lub sieci nakładkowe np. VXLAN.
https://cumulusnetworks.com/blog/routed-vmotion-why/
Cytuj:
Myślałem, również o tym jak wyglądałoby usytuowanie FW w takim design i zarządzanie rulami. Tworzenie rule per /30 lub /31 subnet dla każdego serwer raczej mija się z celem. Jak sadzicie jaki byłoby najlepsze podejście w takim przypadku. Myślę, ze dobrze było by grupować mniejsze podsieci w subnet /24 i na takiej podstawie tworzyć rule. Chętnie się dowiem co inni to tym sadza.
Z FW trzeba zejść na poziom VM jeżeli ruch East-West miałby być filtrowany. Jeżeli wystarczy North-South, to gdzieś na wyjściu z DC. Koncepcja large scale raczej jest pozycjonowana do mnogiej ilości klientów zewnętrznych dla takich firm jak właśnie Facebook, czy Microsoft. W takim przypadku nie trzeba korzystać ze zcentralizowanych FW. Klienci mogą sobie ewentualnie sami uruchomić FW na VM.


Na górę
Wyświetl posty nie starsze niż:  Sortuj wg  
Nowy temat  Odpowiedz w temacie  [ Posty: 2 ] 

Strefa czasowa UTC+01:00


Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 1 gość


Nie możesz tworzyć nowych tematów
Nie możesz odpowiadać w tematach
Nie możesz zmieniać swoich postów
Nie możesz usuwać swoich postów
Nie możesz dodawać załączników

Szukaj:
Przejdź do:  
cron
This Website is not sponsored by, endorsed by or affiliated with Cisco Systems, Inc. Cisco, Cisco Systems, CCDA, CCNA, CCDP, CCNP, CCIE, CCSI, CCIP, the Cisco Systems logo and the CCIE logo are trademarks or registered trademarks of Cisco Systems, Inc. in the United States and certain other countries. Używamy informacji zapisanych za pomocą cookies i podobnych technologii m.in. w celach reklamowych i statystycznych oraz w celu dostosowania naszych serwisów do indywidualnych potrzeb użytkowników. Mogą też stosować je współpracujące z nami firmy. W programie służącym do obsługi internetu można zmienić ustawienia dotyczące cookies. Korzystanie z naszych serwisów internetowych bez zmiany ustawień dotyczących cookies oznacza, że będą one zapisane w pamięci urządzenia.



Technologię dostarcza phpBB® Forum Software © phpBB Limited
Polski pakiet językowy dostarcza phpBB.pl