• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
10 Sposobow Na Efektywne Laczenie DC
 

10 Sposobow Na Efektywne Laczenie DC

on

  • 135 views

10 sposobów, jak połączyć kilka Data Center.

10 sposobów, jak połączyć kilka Data Center.

Statistics

Views

Total Views
135
Views on SlideShare
135
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    10 Sposobow Na Efektywne Laczenie DC 10 Sposobow Na Efektywne Laczenie DC Presentation Transcript

    • 10 Sposobów Na Efektywne Łączenie Ośrodków Przetwarzania Danych (DC) Na Potrzeby Usług w Chmurze Mirek Burnejko CCNP R&S, CCDP
    • O Czym Nie Będzie? O konfiguracji urządzeń (z małym wyjątkiem) O producentach (postaram się) O projektowaniu usług Cloud O orkiestracji usług Cloud O usługach non-Cloud O sieciach wew. DC (z małymi wyjątkami) O replikacji/synchronizacji storage O bezpieczeństwie/szyfrowaniu
    • O Czym Będzie? O wybieraniu L3 kiedy możesz i L2 gdy musisz O używaniu Load Balancerów O unikaniu problemów przy łączeniu DC O 10 metodach łączenia DC O rekomendacjach Atendian
    • O Mnie Starszy Inżynier Wsparcia Sprzedaży w Atende Bloger, Ćwierkacz Fan Nowości (ACI, VXLAN, OpenFlow) Brak Animacji  Zasada 10 Punktów http://blog.netfi.co http://itcertificationmaster.com http://twitter.com/miroburn
    • Agenda Po co łączymy Data Center? L2 czy L3? 1. L3 – Brak Separacji 2. L3 – Z Separacją 3. L2 + Spanning Tree 4. L2 + Brak Spanning Tree 5. VPLS 6. OTV 7. EtherIP 8. VXLAN 9. Przyszłość + OpenFlow 10.Przyszłość + SDN i Jeszcze Dalej Rekomendacje Atendian
    • 3 Opcje w 10 Punktach Wystarczy L3 Potrzeba L2 Potrzeba L2, ale L3 w rdzeniu
    • Zbudujmy Chmurę
    • Zbudujmy Chmurę
    • Punkt Wyjścia
    • Po ca nam drugie/trzecie DC? DR (Disaster Recovery) Boom i za kilkadziesiąt minut/godzin mamy usługi w drugim DC DA (Disaster Avoidance) Boom i za kilka sekund/minut mamy usługi w drugim DC Active-Active (CLOUD) Boom i Nikt niczego nie widział
    • L2 vs. L3 L2 czy L3?
    • L2 vs. L3
    • L2 vs. L3 Po co L2?
    • Po co L2? FCoE pomiędzy dwoma DC? Kilka km, VLAN pomiędzy DC = DWDM/Dark Fiber FC (DWDM) FCIP, iSCSI, Replikatory
    • Po co L2? vMotion + DRS?
    • VMotion – TAK, ale… http://blog.netfi.co/atende-vmotion
    • VMotion – TAK, ale…
    • VMotion – TAK, ale…
    • VMotion – TAK, ale…
    • VMotion – TAK, ale…
    • VMotion – TAK, ale… Dodatkowe Problemy HSRP/VRRP Bazy Danych Orkiestracja Firewalle Stanowe, Load Balancery
    • Po co L2? Rozciąganie Klastrów (Oracle RAC, Firewalls, Load Balancery) Awaria połączeń pomiędzy DC = Split Brain (?) Co z danymi na storage (?) Błąd konfiguracyjny na klastrze (?)
    • Klaster – TAK, ale… HSRP/VRRP Te Same Podsieci Współdzielone IP Niczym Jedno DC 
    • Klaster - Tak, ale…
    • Klaster – TAK, ale…
    • Problemy z L2 Problemy z Pętlami Unknown Unicast Problemy Fizyczne Nieoptymalny Ruch Urządzenia Stanowe
    • L2 i L3 – Do Przemyślenia Jak zrealizować ruch do naszych DC? Niezależne sieci L3 Rozciągnięte L2 Anycast Global Load Balancing LISP Firewalling Stanowe/Bezstanowe Gdzie? A Może Wirtualnie? Load Balancing Global (DNS) Local Anycast Połączenie/Synchronizacja/Replikacja Storage
    • Projektując pamiętajmy o… Praca z: Administratorami Developerami Właścicielami aplikacji Otwierajmy im oczy na problemy L2 Nikt nie lubi mieć problemów
    • 1. L3 1.L3 – Brak Separacji
    • 1. L3 - Brak Separacji
    • 1. L3 - Dwie opcje Każde z DC ma oddzielną aplikację Każde z DC ma tą samą aplikację (ta sama baza)
    • 1. L3 – Load Balancing Globalny Load Balancing Do którego Data Center w jakiej proporcji ma wchodzić ruch Lokalny Load Balancing Czy ruch ma korzystać z zasobów tylko jednego DC, czy dwóch
    • 2. L3 2.L3 – Z Separacją (VRF, MPLS VPN, MPLS over GRE)
    • 2. L3
    • 3. L2 + Spanning Tree 3. L2 + Spanning Tree
    • 3. L2 + Spanning Tree
    • 3. L2 + Spanning Tree Marnujemy połowę pasma Awarie blisko root bridge powodują problemy w obu DC Bugi, problemy z modułami SFP, światłowodami = pętle = 
    • ? 3. L2 + Spanning Tree
    • ? 3. L2 + Spanning Tree
    • Rozwiązanie Multiple Spanning Trees (802.1s) Multi-Chassis Link Aggregation A Jeszcze lepiej: MST + MLAG 3. L2 + Spanning Tree
    • 3. L2 + Spanning Tree MST Region 1 MST Region 2 MST Region 3
    • 3. L2 + Spanning Tree Jeden region per DC Problem w jednym DC nie przenosi się dalej Problem na linku nie przenosi się do DC
    • 4. L2 + Brak Spanning Tree 4. L2 + Brak Spanning Tree
    • 4. L2 + Brak Spanning Tree = MLAG VSS/vPC/MLAG Przy dwóch DC możemy wyłączyć SPT pomiędzy DC (?) Niestety przy 3+ DC potrzebujemy Spanning Tree
    • 4. L2 + Brak Spanning Tree
    • 4. L2 + Brak Spanning Tree = TRILL
    • 4. L2 + Brak Spanning Tree = TRILL Routing Warstwy 2 (IS-IS) „MAC in MAC” Natywne Wsparcie dla ECMP Eliminacja Spanning Tree Liść (Leaf) – Mapowanie MAC do Switch ID Kręgosłup (Spine) – Info o Switch ID Zastosowanie wew. DC Niektórzy producenci widzą przyszłość w łączeniu DC http://blog.netfi.co/atende-trill-video
    • 5. VPLS 5. VPLS
    • 5. VPLS
    • 5. VPLS Czy przenosimy Spanning Tree? TAK, NIE, Interakcja A-VPLS (VPLS + MLAG) TRILL (nie wszyscy producenci) EoMPLSoGREoIPoVPLS L3? 
    • 6. OTV 6. OTV
    • 6. OTV L2 over IP Adresy MAC over IS-IS Pełna izolacja Spanning Tree ARP Cache/Proxy Brak Unknown Unicast Flooding
    • 6. OTV - EoMPLSoGREoIP http://blog.netfi.co/atende-otv
    • 6. OTV LOMZA# show otv route OTV Unicast MAC Routing Table For Overlay100 VLAN MAC-Address Metric Uptime Owner Next-hop(s) ---- -------------- ------ -------- --------- ----------- 2001 0000.0c07.ac01 1 3d15h site Ethernet1/1 2001 0000.1641.d70e 1 3d15h site Ethernet1/2 2001 0000.49f3.88ff 42 2d22h overlay SUWALKI 2001 0000.49f3.8900 42 2d22h overlay ZAKOPANE
    • 6. OTV – Idealnie – Wejście do DC Global Load Balancing
    • 6. OTV – Idealnie - Wyjście z DC HSRP/VRRP Pamiętajmy o urządzeniach stanowych
    • 7. EtherIP 7. EtherIP
    • 7. EtherIP Ruch vMotion jest rutowany Ruch wirtualnych maszyn jest przełączany Ruch jest ZAWSZE przysyłany do lokalnych maszyn Oba Load Balancery wiedzą gdzie jest dana maszyna Brak Spanning Tree lub innych mechanizmów ala OTV http://blog.netfi.co/atende-etherip
    • 8. VXLAN 8. VXLAN
    • 8. Bez VXLAN
    • 8. Z VXLAN
    • 8. VXLAN VXLAN ID = 24b 16777215
    • 8. VXLAN L2 z poziomu wirtualnego przełącznika (transport L3) Ogrom wirtualnych segmentów Zaprojektowany do jednego DC Nie przygotowany (jeszcze) do łączenia DC Brak czegoś na przykład HSRP/VRRP Brak redukcji problemów z Unknown Unicast Flooding Potrzebujemy VXLAN Gateways Projektowany dla Multicast w transporcie http://blog.netfi.co/atende-vxlan-perf http://blog.netfi.co/atende-vxlan-deployment
    • 8. VXLAN Źródło: http://blog.netfi.co/atende-vxlan-dci
    • 8. VXLAN
    • 8. VXLAN
    • 8. VXLAN Źródło: http://blog.netfi.co/atende-vxlan-porownanie
    • 9. OpenFlow 9. Przyszłość + OpenFlow
    • 9. OpenFlow
    • 9. OpenFlow Sprawdź ACL na wejściu do sieci Sprawdź bity QoS Sprawdź adres MAC. Jeżeli adres MAC przerzuć go na interfejs X i dodaje etykietę MPLS
    • 9. OpenFlow Port Wejściowy Źródłowy, Docelowy IP Źródłowy, Docelowy MAC VLAN MPLS Tag Numer Portu TCP/UDP Dużo więcej
    • 9. OpenFlow Wyślij na port X Dodaj tag VLAN Zmień MAC/IP Push/Pop tag MPLS MPLS Tag Zmień numer portu TCP/UDP Dużo więcej
    • 10. Real SDN 10. Przyszłość + SDN i Jeszcze Dalej
    • Standardowe DC
    • DC z OpenFlow
    • DC z Real SDN
    • 10. Real SDN NSX ACI
    • 10. Real SDN
    • 10. Real SDN
    • Dobre Praktyki
    • Dobre Praktyki – część 1-wsza Unikajmy producentów ze złotym środkiem… …Najpierw biznes, potem aplikacje, potem sieć, potem producenci L2 kiedy musisz L3 kiedy możesz!
    • Dobre Praktyki – część 2-ga Disaster Recovery Rekomendujemy L3 z Separacją Odpowiednie VRFy dla poszczególnych bloków/klientów Jeżeli możesz sobie pozwolić – Load Balancery
    • Dobre Praktyki – część 3-cia Cloud, lub Disaster Avoidance L3 + Local/Global Load Balancing Dobra Polityka Disaster Recovery Jeżeli L2 to OTV (Koszt i Czas Wdrożenia) Pamiętajmy o MTU Skorzystajmy z wiedzy inżynierów Atende
    • Dobre Praktyki – część 4-ta Jutro? VXLAN + Sterydy + Mózg Nowy poziom abstrakcji – ACI, NSX
    • Dziękuję za uwagę [miroslaw.burnejko@atende.pl] www.atende.pl
    • 1. Jaką warstwę zabieramy w rozwiązaniach Real SDN?
    • 2. Jaki protokół rozgłasza adresy MAC w OTV?
    • 3. Ile logicznych sieci z VXLAN? (Można się pomylić o 5 MLN)