{"id":33050,"date":"2019-10-31T21:50:27","date_gmt":"2019-10-31T18:50:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/application-centric-infrastructure-arhitektura-seti-budushhego-ot-rassuzhdenij-k-delu\/"},"modified":"2019-10-31T21:50:27","modified_gmt":"2019-10-31T18:50:27","slug":"application-centric-infrastructure-arhitektura-seti-budushhego-ot-rassuzhdenij-k-delu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/application-centric-infrastructure-arhitektura-seti-budushhego-ot-rassuzhdenij-k-delu","title":{"rendered":"Architektura zorientowana na aplikacje. Sie\u0107 przysz\u0142o\u015bci \u2014 od rozwa\u017ca\u0144 do dzia\u0142ania","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

W ci\u0105gu ostatnich kilku lat Cisco aktywnie promuje now\u0105 architektur\u0119 budowy sieci przesy\u0142owej w centrach danych \u2014 Application Centric Infrastructure (czyli ACI)<\/b>. Niekt\u00f3rzy s\u0105 ju\u017c jej zaznajomieni. Inni nawet wdro\u017cyli j\u0105 w swoich przedsi\u0119biorstwach, w tym w Rosji. Jednak dla wi\u0119kszo\u015bci specjalist\u00f3w IT i kierownik\u00f3w IT ACI nadal pozostaje albo niejasnym akronimem, albo jedynie rozwa\u017caniem o przysz\u0142o\u015bci.
\nW tym artykule spr\u00f3bujemy przybli\u017cy\u0107 t\u0119 przysz\u0142o\u015b\u0107. W tym celu opowiemy o g\u0142\u00f3wnych komponentach architektury ACI, a tak\u017ce zilustrujemy spos\u00f3b jej zastosowania w praktyce. Dodatkowo w najbli\u017cszym czasie zorganizujemy wizualn\u0105 demonstracj\u0119 dzia\u0142ania ACI, na kt\u00f3r\u0105 mo\u017ce zapisa\u0107 si\u0119 ka\u017cdy zainteresowany specjalista IT.
\n<\/a><\/noindex>
\nWi\u0119cej informacji na temat nowej architektury budowy sieci b\u0119dzie mo\u017cna uzyska\u0107 w Petersburgu w maju 2019 roku. Wszystkie szczeg\u00f3\u0142y \u2013 w linkiem<\/a><\/noindex>. Zapisz si\u0119!<\/p>\n

T\u0142o<\/b>
\nTradycyjnym i najpopularniejszym modelem budowy sieci jest model hierarchiczny trzech warstw: j\u0105dro -> dystrybucja (agregacja) -> dost\u0119p. Przez wiele lat model ten by\u0142 wzorem, wed\u0142ug kt\u00f3rego producenci wprowadzali r\u00f3\u017cne urz\u0105dzenia sieciowe o odpowiedniej funkcjonalno\u015bci.
\nKiedy\u015b, gdy technologie informacyjne by\u0142y swoistym niezb\u0119dnym (i, szczerze m\u00f3wi\u0105c, nie zawsze po\u017c\u0105danym) dodatkiem do biznesu, model ten by\u0142 wygodny, do\u015b\u0107 statyczny i niezawodny. Jednak obecnie, gdy IT sta\u0142y si\u0119 jednym z motor\u00f3w rozwoju biznesu, a w wielu przypadkach samego biznesu, statyczno\u015b\u0107 tego modelu zacz\u0119\u0142a powodowa\u0107 du\u017ce problemy.<\/p>\n

Nowoczesny biznes generuje du\u017c\u0105 ilo\u015b\u0107 r\u00f3\u017cnych skomplikowanych wymaga\u0144 dotycz\u0105cych infrastruktury sieciowej. Od termin\u00f3w realizacji tych wymaga\u0144 bezpo\u015brednio zale\u017cy sukces biznesu. Op\u00f3\u017anienia w takich warunkach s\u0105 niedopuszczalne, a klasyczny model budowy sieci cz\u0119sto nie pozwala na terminowe zaspokojenie wszystkich potrzeb biznesowych. <\/p>\n

Na przyk\u0142ad, powstanie nowego z\u0142o\u017conego biznesowego aplikacji wi\u0105\u017ce si\u0119 z konieczno\u015bci\u0105 wykonania przez administrator\u00f3w sieci wielu jednorodnych rutynowych operacji na du\u017cej liczbie r\u00f3\u017cnych urz\u0105dze\u0144 sieciowych na r\u00f3\u017cnych poziomach. Opr\u00f3cz tego, \u017ce zajmuje to du\u017co czasu, zwi\u0119ksza to r\u00f3wnie\u017c ryzyko pope\u0142nienia b\u0142\u0119du, kt\u00f3ry mo\u017ce prowadzi\u0107 do powa\u017cnych przestoj\u00f3w us\u0142ug IT i, w rezultacie, do strat finansowych.<\/p>\n

Korzeniem problemu nie s\u0105 nawet terminy ani z\u0142o\u017cono\u015b\u0107 wymaga\u0144. Chodzi o to, \u017ce te wymagania trzeba \u201et\u0142umaczy\u0107\u201d z j\u0119zyka aplikacji biznesowych na j\u0119zyk infrastruktury sieciowej. Jak wiadomo, ka\u017cdy przek\u0142ad zawsze wi\u0105\u017ce si\u0119 z cz\u0119\u015bciow\u0105 utrat\u0105 znaczenia. Kiedy w\u0142a\u015bciciel aplikacji m\u00f3wi o logice dzia\u0142ania swojej aplikacji, administrator sieci rozumie zestaw VLAN-\u00f3w, listy dost\u0119pu na dziesi\u0105tkach urz\u0105dze\u0144, kt\u00f3re trzeba utrzymywa\u0107, aktualizowa\u0107 i dokumentowa\u0107.<\/p>\n

Zgromadzona wiedza i ci\u0105g\u0142a komunikacja z klientami pozwoli\u0142y firmie Cisco zaprojektowa\u0107 i wdro\u017cy\u0107 nowe zasady budowy sieci przesy\u0142u danych w centrum przetwarzania danych, kt\u00f3re odpowiadaj\u0105 wsp\u00f3\u0142czesnym trendom i opieraj\u0105 si\u0119 przede wszystkim na logice aplikacji biznesowych. St\u0105d nazwa \u2014 Application Centric Infrastructure.<\/p>\n

Architektura ACI.<\/b>
\nArchitektur\u0119 ACI najlepiej postrzega\u0107 nie z perspektywy fizycznej, lecz logicznej. Opiera si\u0119 na modelu zautomatyzowanych polityk, kt\u00f3rych obiekty na najwy\u017cszym poziomie mo\u017cna podzieli\u0107 na nast\u0119puj\u0105ce komponenty:<\/p>\n

    \n
  1. Sie\u0107 oparta na prze\u0142\u0105cznikach Nexus.<\/li>\n
  2. Klaster kontroler\u00f3w APIC;<\/li>\n
  3. Profile aplikacji;<\/li>\n<\/ol>\n

    \n\"Architektura
    \nRozwa\u017cmy ka\u017cdy poziom bardziej szczeg\u00f3\u0142owo \u2014 przy tym b\u0119dziemy przechodzi\u0107 od prostego do bardziej z\u0142o\u017conego.<\/p>\n

    Sie\u0107 oparta na prze\u0142\u0105cznikach Nexus.<\/b>
    \nSie\u0107 w fabryce ACI przypomina tradycyjny model hierarchiczny, ale jest znacznie prostsza w budowie. Do organizacji sieci wykorzystuje si\u0119 model Leaf-Spine, kt\u00f3ry sta\u0142 si\u0119 powszechnie przyj\u0119tym podej\u015bciem do realizacji nowoczesnych sieci. Model ten sk\u0142ada si\u0119 z dw\u00f3ch poziom\u00f3w: Spine i Leaf.
    \n \"Architektura
    \nPoziom Spine odpowiada wy\u0142\u0105cznie za wydajno\u015b\u0107. \u0141\u0105czna wydajno\u015b\u0107 prze\u0142\u0105cznik\u00f3w Spine jest r\u00f3wna wydajno\u015bci ca\u0142ej fabryki, dlatego na tym poziomie nale\u017cy wykorzysta\u0107 prze\u0142\u0105czniki z portami 40G lub wy\u017cszymi.
    \nPrze\u0142\u0105czniki Spine \u0142\u0105cz\u0105 si\u0119 z wszystkimi prze\u0142\u0105cznikami wy\u017cszego poziomu: prze\u0142\u0105cznikami Leaf, do kt\u00f3rych pod\u0142\u0105czone s\u0105 ko\u0144cowe hosty. G\u0142\u00f3wn\u0105 rol\u0105 prze\u0142\u0105cznik\u00f3w Leaf jest pojemno\u015b\u0107 port\u00f3w. <\/p>\n

    W ten spos\u00f3b \u0142atwo rozwi\u0105zywane s\u0105 kwestie skalowalno\u015bci: je\u015bli potrzebujemy zwi\u0119kszy\u0107 przepustowo\u015b\u0107 fabryki, dodajemy prze\u0142\u0105czniki Spine, a je\u015bli potrzebujemy zwi\u0119kszy\u0107 pojemno\u015b\u0107 port\u00f3w \u2013 prze\u0142\u0105czniki Leaf.
    \nDla obu poziom\u00f3w wykorzystywane s\u0105 prze\u0142\u0105czniki z serii Cisco Nexus 9000, kt\u00f3re s\u0105 dla Cisco g\u0142\u00f3wnym narz\u0119dziem do budowy sieci w centrach danych, niezale\u017cnie od ich architektury. Dla poziomu Spine u\u017cywane s\u0105 prze\u0142\u0105czniki Nexus 9300 lub Nexus 9500, natomiast dla Leaf tylko Nexus 9300.
    \nLinia modelowa prze\u0142\u0105cznik\u00f3w Nexus u\u017cywanych w fabryce ACI jest przedstawiona na poni\u017cszym rysunku.
    \n \"Architektura<\/p>\n

    Klaster kontroler\u00f3w APIC (Application Policy Infrastructure Controller) <\/b>
    \nKontrolery APIC to specjalistyczne serwery fizyczne, przy czym dla mniejszych wdro\u017ce\u0144 dopuszcza si\u0119 u\u017cycie klastra z jednego fizycznego kontrolera APIC i dw\u00f3ch wirtualnych.
    \nKontrolery APIC pe\u0142ni\u0105 funkcje zarz\u0105dzania i monitorowania. Wa\u017cne jest to, \u017ce kontrolery nigdy nie uczestnicz\u0105 w przesy\u0142aniu danych, co oznacza, \u017ce nawet je\u015bli wszystkie kontrolery klastra ulegn\u0105 awarii, stabilno\u015b\u0107 dzia\u0142ania sieci nie zostanie tego w \u017caden spos\u00f3b naruszona. Nale\u017cy r\u00f3wnie\u017c zauwa\u017cy\u0107, \u017ce za pomoc\u0105 APIC-\u00f3w administrator zarz\u0105dza wszystkimi fizycznymi i logicznymi zasobami fabryki, a do wprowadzenia jakichkolwiek zmian nie trzeba ju\u017c \u0142\u0105czy\u0107 si\u0119 z danym urz\u0105dzeniem, poniewa\u017c w ACI u\u017cywana jest jedna punkt kontrolny.
    \n \"Architektura<\/p>\n

    Przejd\u017amy teraz do jednego z g\u0142\u00f3wnych komponent\u00f3w ACI \u2013 profili aplikacji.<\/b>
    \nProfil aplikacji (Application Network Profile)<\/b> \u2013 to logiczna podstawa ACI. To w\u0142a\u015bnie profile aplikacji definiuj\u0105 zasady interakcji mi\u0119dzy wszystkimi segmentami sieci i opisuj\u0105 same segmenty sieciowe. ANP umo\u017cliwia abstrahowanie od poziomu fizycznego i w zasadzie przedstawia, jak nale\u017cy zorganizowa\u0107 interakcje mi\u0119dzy r\u00f3\u017cnymi segmentami sieci z perspektywy aplikacji. <\/p>\n

    Profil aplikacji sk\u0142ada si\u0119 z grup po\u0142\u0105cze\u0144 (End-point groups \u2013 EPG). Grupa po\u0142\u0105cze\u0144 to logiczna grupa host\u00f3w (maszyn wirtualnych, serwer\u00f3w fizycznych, kontener\u00f3w itp.), kt\u00f3re znajduj\u0105 si\u0119 w tym samym segmencie bezpiecze\u0144stwa (nie sieci, a w\u0142a\u015bnie bezpiecze\u0144stwa). Ko\u0144cowe hosty, kt\u00f3re nale\u017c\u0105 do danej EPG, mog\u0105 by\u0107 definiowane przez wiele kryteri\u00f3w. Zazwyczaj u\u017cywane s\u0105 nast\u0119puj\u0105ce: <\/p>\n