{"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\/hr\/blog\/administrirovanie\/application-centric-infrastructure-arhitektura-seti-budushhego-ot-rassuzhdenij-k-delu","title":{"rendered":"Application Centric Infrastructure. Arhitektura mre\u017ee budu\u0107nosti \u2014 od razmi\u0161ljanja do dela","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Posljednjih nekoliko godina Cisco aktivno promovira novu arhitekturu za izgradnju mre\u017ee prijenosa podataka u podatkovnim centrima \u2014 Application Centric Infrastructure (ili ACI)<\/b>. Neki su ve\u0107 upoznati s njom. A neki su je \u010dak uspjeli implementirati u svojim poduze\u0107ima, uklju\u010duju\u0107i i u Rusiji. Me\u0111utim, za ve\u0107inu IT stru\u010dnjaka i menad\u017eera ACI jo\u0161 uvijek predstavlja ili nejasnu kraticu, ili samo raspravu o budu\u0107nosti.
\nU ovom \u010dlanku potrudit \u0107emo se da tu budu\u0107nost pribli\u017eimo. Za to \u0107emo objasniti osnovne arhitekturne komponente ACI, a tako\u0111er \u0107emo ilustrirati na\u010din njezine primjene u praksi. Osim toga, u bliskoj budu\u0107nosti organizirat \u0107emo vizualnu demonstraciju rada ACI, na koju se mo\u017ee prijaviti svaki zainteresirani IT stru\u010dnjak.
\n<\/a><\/noindex>
\nVi\u0161e o novoj arhitekturi izgradnje mre\u017ee mo\u0107i \u0107e se saznati u Sankt Peterburgu u svibnju 2019. godine. Sve pojedinosti \u2013 na vezi<\/a><\/noindex>. Prijavite se!<\/p>\n

Povijest<\/b>
\nTradicionalni i najpopularniji model izgradnje mre\u017ee je trostupanjska hijerarhijska mre\u017ea: jezgra -> distribucija (agregacija) -> pristup. Tijekom mnogih godina ovaj model bio je etalon, a proizvo\u0111a\u010di su po njemu razvijali razne mre\u017ene ure\u0111aje odgovaraju\u0107e funkcionalnosti.
\nRanije, kada su informacijske tehnologije bile svojevrsni nu\u017eni (i, da budemo iskreni, ne uvijek po\u017eeljni) dodatak poslovanju, ovaj model bio je prikladan, prili\u010dno stati\u010dan i pouzdan. Me\u0111utim, sada, kada su IT jedan od pokreta\u010da razvoja poslovanja, a u mnogim slu\u010dajevima i samo poslovanje, stati\u010dnost ovog modela postala je uzrok velikih problema.<\/p>\n

Moderni biznis generira mnogo razli\u010ditih slo\u017eenih zahtjeva za mre\u017enom infrastrukturom. Od rokova ispunjenja tih zahtjeva izravno ovisi uspje\u0161nost poslovanja. Ka\u0161njenje u takvim okolnostima nije dopu\u0161teno, a klasi\u010dni model izgradnje mre\u017ee \u010desto ne omogu\u0107ava pravovremeno zadovoljenje svih poslovnih potreba. <\/p>\n

Na primjer, pojava nove kompleksne poslovne aplikacije zahtijeva da mre\u017eni administratori izvezu veliku koli\u010dinu istovjetnih rutinskih operacija na mnogim razli\u010ditim mre\u017enim ure\u0111ajima na razli\u010ditim nivoima. Osim \u0161to to oduzima puno vremena, pove\u0107ava i rizik od gre\u0161ke koja mo\u017ee dovesti do ozbiljnog zastoja IT usluga i, kao posljedice, financijski gubitak.<\/p>\n

Korijen problema nije samo u rokom ili slo\u017eenosti zahtjeva. Radi se o tome da se ti zahtjevi moraju \"prevoditi\" s jezika poslovnih aplikacija na jezik mre\u017ene infrastrukture. Kao \u0161to je poznato, svaki prijevod uvijek nosi djelomi\u010dan gubitak zna\u010denja. Kada vlasnik aplikacije govori o logici funkcioniranja svoje aplikacije, mre\u017eni administrator razumije skup VLAN-ova, Access list-a na desetinama ure\u0111aja koji trebaju biti odr\u017eavani, a\u017eurirani i dokumentirani.<\/p>\n

Nakupljeno iskustvo i stalna komunikacija s klijentima omogu\u0107ili su Cisco-u da projektira i implementira nove principe izgradnje mre\u017ee podatkovnog centra koji odgovaraju modernim trendovima, a temelje se, prije svega, na logici poslovnih aplikacija. Odatle i naziv \u2014 Application Centric Infrastructure.<\/p>\n

Arhitektura ACI.<\/b>
\nArhitekturu ACI najispravnije je posmatrati ne s fizi\u010dke strane, ve\u0107 s logi\u010dke. Ona se temelji na modelu automatiziranih politika, \u010diji se objekti na vi\u0161em nivou mogu podijeliti na sljede\u0107e komponente:<\/p>\n

    \n
  1. Mre\u017ea zasnovana na Nexus preklopnicima.<\/li>\n
  2. Klaster kontrolera APIC;<\/li>\n
  3. Profili aplikacija;<\/li>\n<\/ol>\n

    \n\"Application
    \nRazmotrit \u0107emo svaki nivo detaljnije \u2013 pritom \u0107emo prelaziti od jednostavnog ka slo\u017eenom.<\/p>\n

    Mre\u017ea zasnovana na Nexus preklopnicima<\/b>
    \nMre\u017ea u ACI fabrici sli\u010dna je tradicionalnom hijerarhijskom modelu, ali se gradi znatno jednostavnije. Za organizaciju mre\u017ee koristi se Leaf-Spine model, koji je postao op\u0107eprihva\u0107en pristup za implementaciju mre\u017ea nove generacije. Ovaj model sastoji se od dva nivoa: Spine i Leaf, redom.
    \n \"Application
    \nNivo Spine odgovara isklju\u010divo za performanse. Ukupna performansa Spine preklopnika jednaka je performansi cjelokupne fabrike, stoga se na ovom nivou trebaju koristiti preklopnici s portovima od 40G ili vi\u0161e.
    \nSpine preklopnici povezuju se sa svim prekida\u010dima sljede\u0107e razine: Leaf prekida\u010dima, kojima se priklju\u010duju krajnji hostovi. Osnovna uloga Leaf prekida\u010da je kapacitet portova. <\/p>\n

    Na taj na\u010din lako se rje\u0161avaju pitanja skaliranja: ako trebamo pove\u0107ati propusnost fabrike, dodajemo Spine preklopnike, a ako trebamo pove\u0107ati kapacitet portova \u2013 Leaf.
    \nZa obje razine koriste se preklopnici serije Cisco Nexus 9000, koji su za Cisco glavni alat za izgradnju data centara bez obzira na njihovu arhitekturu. Za nivo Spine koriste se preklopnici Nexus 9300 ili Nexus 9500, a za Leaf samo Nexus 9300.
    \nModel serije preklopnika Nexus koji se koristi u ACI fabrici prikazan je na slici ispod.
    \n \"Application<\/p>\n

    Klaster kontrola APIC (Kontroler infrastrukture aplikacijske politike) <\/b>
    \nAPIC kontroleri su specijalizirani fizi\u010dki serveri, pri \u010demu je za mala implementiranja dozvoljeno kori\u0161tenje klastera od jednog fizi\u010dkog APIC kontrolera i dva virtualna.
    \nAPIC kontroleri izvr\u0161avaju funkcije upravljanja i nadzora. Va\u017eno je napomenuti da kontroleri nikada ne sudjeluju u prijenosu podataka, \u0161to zna\u010di da \u010dak i ako svi kontroleri klastera otka\u017eu, stabilnost mre\u017ee time ne\u0107e biti pogo\u0111ena. Tako\u0111er, potrebno je istaknuti da upravitelj pomo\u0107u APIC-a upravlja svim fizi\u010dkim i logi\u010dkim resursima fabrike, i da za uvo\u0111enje bilo kakvih promjena vi\u0161e nije potrebno povezivati se s tim ili onim ure\u0111ajem, budu\u0107i da ACI koristi jedinstvenu to\u010dku upravljanja.
    \n \"Application<\/p>\n

    Sada \u0107emo se prebaciti na jednu od glavnih komponenti ACI \u2013 profile aplikacija.<\/b>
    \nProfil aplikacije (Profil mre\u017ee aplikacija)<\/b> je logi\u010dka osnova ACI. Upravo profili aplikacija definiraju politike interakcije izme\u0111u svih mre\u017enih segmenata i opisuju same mre\u017ene segmente. ANP omogu\u0107uje apstrakciju od fizi\u010dke razine i, u su\u0161tini, predstavlja kako organizirati interakciju izme\u0111u razli\u010ditih mre\u017enih segmenata s aspekta aplikacije. <\/p>\n

    Profil aplikacije sastoji se od grupa konekcija (End-point groups \u2013 EPG). Grupa konekcija je logi\u010dka grupa hostova (virtuelnih ma\u0161ina, fizi\u010dkih servera, kontejnera itd.) koji se nalaze u jednom segmentu bezbednosti (ne mre\u017ee, ve\u0107 upravo bezbednosti). Krajni hostovi koji pripadaju odre\u0111enoj EPG mogu se definisati velikim brojem kriterijuma. Obi\u010dno se koriste slede\u0107i: <\/p>\n