{"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":"Rakendustele keskenduv infrastruktuur. Tuleviku v\u00f5rgu arhitektuur \u2014 arutlustest tegudeni","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Viimastel aastatel on Cisco aktiivselt edendanud uut andmesidev\u00f5rgu arhitektuuri andmekeskustes \u2014 Rakendusele keskenduv infrastruktuur (ehk ACI)<\/b>. M\u00f5ned on sellega juba tutvunud. Teised on isegi saanud selle oma ettev\u00f5tetesse rakendada, sealhulgas Venemaal. Siiski on ACI enamusele IT-spetsialistidest ja IT-juhtidest veel kas arusaamatu l\u00fchend v\u00f5i lihtsalt jutt tulevikust.
\nSelles artiklis proovime seda tulevikku l\u00e4hemale tuua. Selle eesm\u00e4rgi nimel r\u00e4\u00e4gime ACI p\u00f5hikomponentidest ning illustreerime, kuidas seda praktikas rakendada. Lisaks korraldame varsti ACI toimimise n\u00e4idisdemo, kuhu saab registreeruda iga huviline IT-spetsialist.
\n<\/a><\/noindex>
\nUue andmesidev\u00f5rgu arhitektuuri kohta saab rohkem teada 2019. aasta mais Peterburis. K\u00f5ik \u00fcksikasjad \u2013 aadressil lingi kaudu<\/a><\/noindex>. Registreerige end!<\/p>\n

Eelalugu<\/b>
\nTraditsiooniline ja k\u00f5ige populaarsem v\u00f5rgustruktuuri mudeleid on kolme taseme hierarhiline mudel: tuum > jaotamine (agregatsioon) > juurdep\u00e4\u00e4s. Aastate jooksul on see mudel olnud standard, mille j\u00e4rgi tootjad on v\u00e4lja andnud erinevaid v\u00f5rgu seadmeid, mis vastavad sellele funktsionaalsusele.
\nKunagi, kui infotehnoloogia oli omamoodi h\u00e4davajalik (ja, peab \u00fctlema, mitte alati soovitav) lisand \u00e4ri juurde, oli see mudel mugav, \u00fcsna staatiline ja usaldusv\u00e4\u00e4rne. Kuid n\u00fc\u00fcd, kui IT on muutunud \u00fcheks \u00e4riarengu mootoriks ja paljuski isegi \u00e4ri enda osaks, on selle mudeli staatilisus hakanud tekitama suuri probleeme.<\/p>\n

Kaasaegne \u00e4ri genereerib suurt hulka erinevaid keerulisi n\u00f5udmisi v\u00f5rguinfrastruktuurile. N\u00f5udmiste t\u00e4itmise ajad s\u00f5ltuvad otseselt \u00e4ri edust. Viivitamine sellistes tingimustes on vastuv\u00f5etamatu ning klassikaline v\u00f5rgumudel ei suuda tihti \u00f5igel ajal rahuldada k\u00f5iki \u00e4ri vajadusi. <\/p>\n

N\u00e4iteks toob uue keerulise \u00e4ritarkvara ilmumine kaasa suurte administraatorite vajaduse teha palju sarnaseid rutiinseid operatsioone paljudes erinevates v\u00f5rgu seadmetes erinevatel tasanditel. Lisaks sellele, et see v\u00f5tab palju aega, suurendab see ka riski teha viga, mis v\u00f5ib p\u00f5hjustada t\u00f5siseid katkestusi IT-teenustes ja seega ka rahalisikahjusid.<\/p>\n

Probleemi juureks ei ole isegi mitte t\u00e4htajad v\u00f5i n\u00f5uete keerukus. Asi on selles, et neid n\u00f5udeid tuleb 't\u00f5lkida' \u00e4ritarkvarast v\u00f5rgu infrastruktuuri keelde. Nagu teada, t\u00e4hendab iga t\u00f5lge alati osa t\u00e4henduse kaotust. Kui rakenduse omanik r\u00e4\u00e4gib oma rakenduse t\u00f6\u00f6logikast, m\u00f5istab v\u00f5rguadministraator hulka VLAN-e, Access List-e, mida tuleb toeks hoida, ajakohastada ja dokumenteerida.<\/p>\n

Kogutud kogemus ja pidev suhtlemine klientidega on v\u00f5imaldanud Cisco-l projekteerida ja rakendada uusi andmekeskuse andmeedastusv\u00f5rgu loomise p\u00f5him\u00f5tteid, mis vastavad kaasaegsetele suundumustele ja p\u00f5hinevad peamiselt \u00e4ri rakenduste loogikal. Seet\u00f5ttu ka nimi \u2014 Rakendusele Keskenduv Infrastruktur.<\/p>\n

ACI arhitektuur.<\/b>
\nACI arhitektuuri on k\u00f5ige \u00f5igem vaadelda mitte f\u00fc\u00fcsilisest k\u00fcljest, vaid loogilisest. See p\u00f5hineb automatiseeritud poliitikate mudelil, mille objekte saab k\u00f5rgel tasemel jagada j\u00e4rgmistesse komponentidesse:<\/p>\n

    \n
  1. Nexus l\u00fclitite p\u00f5hine v\u00f5rk.<\/li>\n
  2. APIC-kontrollerite klaster;<\/li>\n
  3. Rakenduse profiilid;<\/li>\n<\/ol>\n

    \n\"Rakendustele
    \nVaatame iga taset l\u00e4hemalt \u2013 liikudes kergemalt keerulisemaks.<\/p>\n

    Nexus l\u00fclitite p\u00f5hine v\u00f5rk<\/b>
    \nACI-fabriku v\u00f5rk sarnaneb traditsioonilise hierarhilise mudeliga, kuid seda on oluliselt lihtsam \u00fcles ehitada. V\u00f5rgu korraldamiseks kasutatakse Leaf-Spine mudelit, mis on muutunud uue p\u00f5lvkonna v\u00f5rkude rakendamiseks \u00fcldiselt aktsepteeritud l\u00e4henemisviisiks. See mudel koosneb kahest tasemest: Spine ja Leaf, vastavalt.
    \n \"Rakendustele
    \nSpine-tasandi vastutab ainult j\u00f5udluse eest. Spine-l\u00fclitite koguj\u00f5udlus on v\u00f5rgu kogu j\u00f5udlus, mist\u00f5ttu tuleb sellel tasemel kasutada 40G v\u00f5i k\u00f5rgemat kiirete l\u00fclititega.
    \nSpine-l\u00fclitid on \u00fchendatud k\u00f5igi j\u00e4rgmise taseme l\u00fclititega: Leaf-l\u00fclititega, millega on \u00fchendatud l\u00f5pp-teenindajad. Leaf-l\u00fclitite peamine roll on portide mahutavus. <\/p>\n

    Seega on skaleerimise k\u00fcsimused lihtsad: kui me peame suurendama tehase l\u00e4bilaskev\u00f5imet, lisame Spine-l\u00fclitid, ja kui me peame suurendama portide mahutavust \u2013 Leaf-l\u00fclitid.
    \nM\u00f5lemal tasemel kasutatakse Cisco Nexus 9000 seeria l\u00fcliteid, mis on Cisco p\u00f5hivahend andmekeskuse v\u00f5rkude ehitamiseks s\u00f5ltumata arhitektuurist. Spine-taseme jaoks kasutatakse Nexus 9300 v\u00f5i Nexus 9500 l\u00fcliteid, Leaf-taseme jaoks ainult Nexus 9300.
    \nNexus-l\u00fclitite mudelid, mida kasutatakse ACI tehases, on toodud alloleval joonisel.
    \n \"Rakendustele<\/p>\n

    APIC (Application Policy Infrastructure Controller) klaster. <\/b>
    \nAPIC-kontrollerid on spetsialiseeritud f\u00fc\u00fcsilised serverid, samas lubatakse v\u00e4iksemate rakenduste puhul kasutada \u00fchte f\u00fc\u00fcsilist APIC-kontrollerit ja kahte virtuaalset.
    \nAPIC-kontrollerid t\u00e4idavad haldus- ja j\u00e4lgimisfunktsioone. Oluline on, et kontrollerid ei osale kunagi andmete edastamises, seega, isegi kui k\u00f5ik klastrite kontrollerid eba\u00f5nnestuvad, ei m\u00f5juta see v\u00f5rgu stabiilsust absoluutselt. Samuti tuleb m\u00e4rkida, et APIC-ide abil haldab administraator k\u00f5iki f\u00fc\u00fcsilisi ja loogilisi ressursse tehases, ja et muudatuste tegemiseks ei ole vaja enam \u00fchendust v\u00f5tta \u00fcksikute seadmetega, kuna ACI-s kasutatakse \u00fchte halduspunkte.
    \n \"Rakendustele<\/p>\n

    N\u00fc\u00fcd liigume edasi \u00fche ACI peamise komponendi juurde \u2013 rakenduste profiilide juurde.<\/b>
    \nRakenduse profiil (Application Network Profile)<\/b> \u2013 see on ACI loogiline alus. Just rakendusprofiilid m\u00e4\u00e4ravad poliitikad, kuidas k\u00f5ikide v\u00f5rgu segmentide vahel suhelda, ja kirjeldavad otse v\u00f5rgu segmente. ANP v\u00f5imaldab abstraktiseerida f\u00fc\u00fcsiliselt tasemelt ja esindab, kuidas korraldada erinevate v\u00f5rgu segmente interaktsiooni rakenduse vaatenurgast. <\/p>\n

    Rakendusprofiil koosneb \u00fchendusgruppidest (End-point groups \u2013 EPG). \u00dchendusgrupp on loogiline grupp hoste (virtuaalmasinad, f\u00fc\u00fcsilised serverid, konteinerid jne), mis asuvad \u00fches turvasegmentis (mitte v\u00f5rgus, vaid just turvalisuse m\u00f5ttes). L\u00f5puhostid, mis kuuluvad teatud EPG-sse, v\u00f5ivad olla m\u00e4\u00e4ratletud paljude kriteeriumide alusel. Tavalised on j\u00e4rgmised: <\/p>\n