{"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\/et\/blog\/administrirovanie\/application-centric-infrastructure-arhitektura-seti-budushhego-ot-rassuzhdenij-k-delu","title":{"rendered":"Rakendusele keskenduv infrastruktuur. Tuleviku v\u00f5rgu arhitektuur \u2014 teooriast praktikani","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Viimastel aastatel on Cisco aktiivselt edendanud uut andmesidev\u00f5rgu arhitektuuri andmekeskustes \u2014 Rakenduskeskne infrastruktuur (v\u00f5i ACI)<\/b>, millest m\u00f5ned on juba tuttavad. On ka neid, kes on j\u00f5udnud seda oma ettev\u00f5tetes rakendada, sealhulgas Venemaal. Kuid enamikule IT-spetsialistidest ja IT-juhtidest on ACI kas arusaamatu akron\u00fc\u00fcm v\u00f5i lihtsalt arutelu tuleviku \u00fcle.
\nSelles artiklis \u00fcritame seda tulevikku l\u00e4hemale tuua. Selleks r\u00e4\u00e4gime ACI p\u00f5hikomponentidest ning illustreerime, kuidas seda praktikas rakendada. Lisaks korraldame peagi visuaalse demonstreerimise ACI t\u00f6\u00f6tamisest, kuhu saab registreeruda iga huvitatud IT-spetsialist.
\n<\/a><\/noindex>
\nUue v\u00f5rgu arhitektuuri kohta saab rohkem teada Saint-Peterburis mai 2019. aastal. K\u00f5ik \u00fcksikasjad on lingil<\/a><\/noindex>. Registreeruge!<\/p>\n

Eellugu<\/b>
\nTraditsiooniline ja k\u00f5ige populaarsem v\u00f5rguline mudel on kolmetasandiline hierarhiline mudel: tuum -> jaotamine (agregatsioon) -> juurdep\u00e4\u00e4s. Aastaid on see mudel olnud ideaal, mille j\u00e4rgi tootjad on v\u00e4lja t\u00f6\u00f6tanud erinevaid v\u00f5rguseadmeid vastava funktsionaalsusega.
\nVarem, kui infotehnoloogia oli mingil m\u00e4\u00e4ral vajalik (ja, olgem ausad, mitte alati soovitud) lisand \u00e4ritegevusele, oli see mudel mugav, \u00fcsna staatiline ja usaldusv\u00e4\u00e4rne. Kuid n\u00fc\u00fcd, kui IT on muutunud \u00fcheks \u00e4riarenduse juhiks ja paljude juhtude puhul ka \u00e4ritegevuseks endaks, on selle mudeli staatilisus tekitanud suuri probleeme.<\/p>\n

Kaasaegne \u00e4ri genereerib suure hulga erinevaid keerulisi n\u00f5udmisi v\u00f5rgu infrastruktuurile. Nende n\u00f5udmiste t\u00e4itmise ajast s\u00f5ltub otse ettev\u00f5tte edukus. Viivitamine sellistes olukordades on vastuv\u00f5etamatu ning klassikaline v\u00f5rgu mudel ei suuda sageli \u00f5igel ajal rahuldada k\u00f5iki \u00e4ri vajadusi. <\/p>\n

N\u00e4iteks uue keerulise \u00e4riteabe rakenduse ilmumine eeldab v\u00f5rguadministraatorite poolt suurt hulka \u00fchesuguseid rutiinseid toiminguid paljudes erinevates v\u00f5rgu seadmetes erinevatel tasemetel. Pealegi v\u00f5tab see aega ja suurendab ohtu teha viga, mis v\u00f5ib viia t\u00f5sise IT-teenuste seiskumiseni ja seega rahaliste kahjudeni.<\/p>\n

Probleemi juured ei seisne isegi mitte t\u00e4htaegades v\u00f5i n\u00f5uete keerukuses. Asi on selles, et neid n\u00f5udeid on vaja \"t\u00f5lkida\" \u00e4riteabe rakenduste keelest v\u00f5rgu infrastruktuuri keelde. Nagu teada, toob iga t\u00f5lge alati kaasa osalise t\u00e4henduse kaotuse. Kui rakenduse omanik r\u00e4\u00e4gib oma rakenduse t\u00f6\u00f6logikast, m\u00f5istab v\u00f5rguadministraator k\u00fcmnete seadmete VLANide ja Access listide kogumit, mida on vaja hallata, ajakohastada ja dokumenteerida.<\/p>\n

Kogutud kogemus ja pidev suhtlemine klientidega on v\u00f5imaldanud Cisco-l projekteerida ja rakendada uusi p\u00f5him\u00f5tteid andmeedastusv\u00f5rgu ehitamiseks, mis vastavad kaasaegsetele suundumustele ja p\u00f5hinevad peamiselt \u00e4riteabe rakenduste loogikal. Seet\u00f5ttu nimetatakse seda Application Centric Infrastructure'iks.<\/p>\n

ACI arhitektuur.<\/b>
\nACI arhitektuuri tuleks k\u00f5ige paremini k\u00e4sitleda mitte f\u00fc\u00fcsiliselt, vaid loogiliselt. See p\u00f5hineb automatiseeritud poliitikate mudelil, mille objektiid on k\u00f5rgel tasemel jagatavad j\u00e4rgmisteks komponentideks:<\/p>\n

    \n
  1. Nexus-l\u00fclititel p\u00f5hinev v\u00f5rk.<\/li>\n
  2. APIC-i kontrollerite klaster;<\/li>\n
  3. Rakenduse profilid;<\/li>\n<\/ol>\n

    \n\"Rakendusele
    \nVaatleme iga taset \u00fcksikasjalikumalt \u2013 liikudes lihtsast keeruliseni.<\/p>\n

    Nexus-l\u00fclititel p\u00f5hinev v\u00f5rk<\/b>
    \nACI tehases asuv v\u00f5rk sarnaneb traditsioonilisele hierarhilisele mudelile, kuid seda ehitatakse oluliselt lihtsamalt. V\u00f5rgu korraldamiseks kasutatakse Leaf-Spine mudelit, mis on saanud uue p\u00f5lvkonna v\u00f5rkude rakendamisel \u00fcldiselt aktsepteeritud l\u00e4henemisviisiks. See mudel koosneb kahest tasemest: Spine ja Leaf, vastavalt.
    \n \"Rakendusele
    \nSpine-tase vastutab ainult j\u00f5udluse eest. Spine-l\u00fclitite koguj\u00f5udlus on kogu tehase j\u00f5udluse summa, seega tuleks sellel tasemel kasutada l\u00fcliteid, mille portide kiirus on 40G v\u00f5i rohkem.
    \nSpine-l\u00fclitid \u00fchenduvad k\u00f5igi j\u00e4rgmise taseme l\u00fclititega: Leaf-l\u00fclititega, millele on \u00fchendatud l\u00f5pp-hostid. Leaf-l\u00fclitite peamine roll on portide maht. <\/p>\n

    Seega on lihtne lahendada skaleerimise k\u00fcsimusi: kui me vajame tehase l\u00e4bilaskev\u00f5ime suurendamist, lisame Spine-l\u00fcliteid, ja kui me vajame portide mahu suurendamist \u2013 Leaf.
    \nM\u00f5lema taseme jaoks kasutatakse Cisco Nexus 9000 seeria l\u00fcliteid, mis on Cisco p\u00f5hivahend andmekeskuste (DC) v\u00f5rkude loomisel s\u00f5ltumata nende arhitektuurist. Spine-taseme jaoks kasutatakse Nexus 9300 v\u00f5i Nexus 9500 l\u00fcliteid, Leaf-taseme jaoks ainult Nexus 9300.
    \nACI tehases kasutatavate Nexus-l\u00fclite seeria on esitatud alloleval joonisel.
    \n \"Rakendusele<\/p>\n

    APIC (Application Policy Infrastructure Controller) juhtr\u00fchma klaster <\/b>
    \nAPIC-juhtimisseadmed on spetsialiseeritud f\u00fc\u00fcsilised serverid, samas v\u00e4ikeste rakenduste puhul on lubatud kasutada \u00fchte f\u00fc\u00fcsilist APIC-juhtimisseadet ja kahte virtuaalset.
    \nAPIC-juhtimisseadmed t\u00e4idavad haldus- ja j\u00e4lgimisfunktsioone. Oluline on see, et juhtr\u00fchmad ei osale kunagi andmete edastamises, see t\u00e4hendab, et isegi kui k\u00f5ik klastris olevad juhtr\u00fchmad eba\u00f5nnestuvad, ei m\u00f5juta see v\u00f5rgu stabiilsust. Samuti tuleb m\u00e4rkida, et APIC-ide abil haldab administraator k\u00f5iki f\u00fc\u00fcsilisi ja loogilisi tehase ressursse, ning et muudatuste tegemiseks ei ole vajalik enam seadmele otse juurde p\u00e4\u00e4seda, kuna ACI-s kasutatakse \u00fchtset juhtimispunkti.
    \n \"Rakendusele<\/p>\n

    N\u00fc\u00fcd liigume \u00fche ACI peamise komponente juurde \u2013 rakenduse profiilide juurde.<\/b>
    \nRakenduse profiil (Application Network Profile)<\/b> on ACI loogiline alus. Just rakenduse profiilid m\u00e4\u00e4ravad poliitikad, mille kaudu k\u00f5ik v\u00f5rgu segmendid suhtlevad, ja kirjeldavad otse neid v\u00f5rgu segmente. ANP v\u00f5imaldab eristada f\u00fc\u00fcsilisest tasemest ja p\u00f5him\u00f5tteliselt kujutada, kuidas korraldada suhtlemist erinevate v\u00f5rgu segmentide vahel rakenduse vaatenurgast. <\/p>\n

    Rakenduse profiil koosneb \u00fchenduste r\u00fchmadest (End-point groups \u2013 EPG). \u00dchenduste r\u00fchm on loogiline hostide (virtuaalmasinate, f\u00fc\u00fcsiliste serverite, konteinerite jne) grupp, mis asub samas turvasegmendis (mitte v\u00f5rgus, vaid t\u00e4pselt turvalisuses). L\u00f5pp\u00fchendid, mis kuuluvad teatud EPG-sse, v\u00f5ivad olla m\u00e4\u00e4ratud suure hulga kriteeriumitega. Tavaliselt kasutatakse j\u00e4rgmisi: <\/p>\n