L3 DC Design

Problemy i dyskusje z zakresu rozwiązań i technologii Data Center
Wiadomość
Autor
martino76
CCIE
CCIE
Posty: 883
Rejestracja: 17 gru 2010, 15:23
Lokalizacja: Barczewo

L3 DC Design

#1

#1 Post autor: martino76 »

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,

Awatar użytkownika
gangrena
CCIE/CCDE
CCIE/CCDE
Posty: 2349
Rejestracja: 08 mar 2004, 12:17
Lokalizacja: Wawa

Re: L3 DC Design

#2

#2 Post autor: gangrena »

martino76 pisze: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.
martino76 pisze: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.
martino76 pisze: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.
martino76 pisze: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.
martino76 pisze: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/
martino76 pisze: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.

ODPOWIEDZ