{"id":35291,"date":"2019-10-31T22:03:28","date_gmt":"2019-10-31T19:03:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/setevaya-fabrika-dlya-tsoda-cisco-aci-v-pomoshh-adminu\/"},"modified":"2019-10-31T22:03:28","modified_gmt":"2019-10-31T19:03:28","slug":"setevaya-fabrika-dlya-tsoda-cisco-aci-v-pomoshh-adminu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/setevaya-fabrika-dlya-tsoda-cisco-aci-v-pomoshh-adminu","title":{"rendered":"Cisco ACI v\u00f5rgufabrik andmekeskusele \u2014 abi administraatorile","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Cisco
\nSelle imelise Cisco ACI skripti abil saab v\u00f5rku kiiresti seadistada.<\/i><\/p>\n

Cisco ACI andmehalduse tehas on juba viis aastat olemas, kuid Habr's ei ole selle kohta t\u00f5eliselt midagi r\u00e4\u00e4gitud, seega otsustasin seda veidi parandada. R\u00e4\u00e4gin oma kogemuse p\u00f5hjal, mis see on, millist kasu sellest on ja millised on seal leitud mured. <\/p>\n

Mis see on ja kust see tuli?<\/h3>\n

\nAastal 2013 ACI (Rakendusele keskendatud infrastruktuur) v\u00e4lja kuulutamise hetkeks said andmehalduse traditsioonilised l\u00e4henemised samaaegselt kolme allika poolt konkurentsi. <\/p>\n

Esiteks lubasid esimese p\u00f5lvkonna SDN-lahendused OpenFlow baasil muuta v\u00f5rgud samal ajal paindlikumaks ja odavamaks. Idee seisnes selles, et muudeti otsuste tegemise, mis tavaliselt toimus kommutaatorite omaniku tarkvara kaudu, keskseks kontrolleriks. <\/p>\n

See kontroller omaks \u00fchtset n\u00e4gemust sellest, mis toimub, ja selle p\u00f5hjal programmeeriks k\u00f5igi l\u00fclitite riistvara konkreetselt voogude t\u00f6\u00f6tlemise reeglite tasandil. <\/a><\/noindex>
\nTeiselt poolt v\u00f5imaldasid overlay v\u00f5rgulahendused saavutada vajaliku \u00fchenduvuse ja turvapoliitikad ilma f\u00fc\u00fcsilises v\u00f5rgus muutusteta, luues tarkvaralisi tunnelite vahel virtualiseeritud majutajate vahel. K\u00f5ige tuntum n\u00e4ide selle l\u00e4henemise kohta oli Nicira lahendus, mis oli juba ostetud VMWare poolt 1,26 miljardi dollari eest ja andis alguse t\u00e4nap\u00e4eva VMWare NSX-ile. Kuna Nicira kaasasutajateks olid samad inimesed, kes olid eelnevalt OpenFlow alguses, tekkis olukorrale teatav soolakus. OpenFlow ei sobi.<\/a><\/noindex>.<\/p>\n

L\u00f5puks on avatud turul saadaval olevad kommutaatorite spetsiaalsetele kiipidele (mis nimetatakse merchant silicon) saavutanud k\u00fcpsuse taseme, kus need kujutavad endast reaalselt ohtu traditsioonilistele kommutaatoritootjatele. Kui varem arendas iga tootja oma kommutaatorite kiipe, siis aja jooksul on kolmandate osapoolte, eelk\u00f5ige Br\u043eadcomi kiibid, hakanud funktsioonide poolest tootjate kiipidega taset t\u00f5stma, samas kui hinna ja j\u00f5udluse suhte poolest neist \u00fcle. Seet\u00f5ttu arvas paljud, et nende p\u00e4evad on loetud tosinkond aastat tagasi v\u00e4lja t\u00f6\u00f6tatud kiipidel.<\/p>\n

ACI oli Cisco (t\u00e4psemalt tema koosseisu kuuluv Insieme, mille asutasid endised t\u00f6\u00f6tajad) \u00abas\u00fcmmeetriline vastus\u00bb k\u00f5ikidele sellele. <\/p>\n

Millis on OpenFlow'i erinevus?<\/h3>\n

\nFunktsioonide jaotamise vaatenurgast on ACI tegelikult OpenFlow'i vastand.
\nOpenFlow'i arhitektuuris vastutab kontrolls\u00fcsteem detailsete reeglite (voogude) m\u00e4\u00e4ratlemise eest
\nk\u00f5ikides l\u00fclitite riistvarades, mist\u00f5ttu v\u00f5ib suurtes v\u00f5rkudes lasuda temal vastutus hoida ja, mis k\u00f5ige t\u00e4htsam, muuta k\u00fcmneid miljoneid kirjeid sadades kohtades v\u00f5rgus, mist\u00f5ttu tema j\u00f5udlus ja usaldusv\u00e4\u00e4rsus suurel rakendusel saavad kitsaskohaks.<\/p>\n

ACI kasutab vastupidist l\u00e4henemist: kontrolls\u00fcsteem on loomulikult olemas, kuid l\u00fclitid saavad temalt k\u00f5rgetasemelisi deklaratiivseid poliitikaid, samas kui nende konvertimine konkreetseteks seadistusteks riistvaras toimub l\u00fcliti enda poolt. Kontrolls\u00fcsteemi saab taask\u00e4ivitada v\u00f5i isegi v\u00e4lja l\u00fclitada ning v\u00f5rguga ei juhtu midagi halba, v\u00e4lja arvatud loomulikult see, et sellel hetkel ei ole juhtimise v\u00f5imalust. Huvi pakub, et ACI-s on olukordi, kus OpenFlow'i siiski kasutatakse, kuid kohapeal, hosti piires Open vSwitch'i programmeerimiseks.<\/p>\n

ACI on t\u00e4ielikult \u00fcles ehitatud VXLANi p\u00f5hjal \u00fclekatte (overlay) transpordile, kuid sisaldab samas ainulaadses lahenduses ka aluseks olevat IP-transpordit. Cisco nimetas seda terminiks \u201eintegreeritud overlay\u201d. ACI-s kasutatakse enamikul juhtudel overlay\u2019ide l\u00f5pp-punkte tehase l\u00fclitid (teevad seda kanalikiirusel). Hostid ei ole kohustatud teadma tehase, kapseldamise jne kohta, kuid m\u00f5ningatel juhtudel (n\u00e4iteks OpenStacki hostide \u00fchendamiseks) v\u00f5ib VXLAN-i liiklus j\u00f5uda ka nende juurde.<\/p>\n

Overlaid kasutatakse ACI-s mitte ainult paindliku \u00fchenduvuse tagamiseks transpordiv\u00f5rgus, vaid ka metaandmete edastamiseks (mida kasutatakse n\u00e4iteks turvapoliitikate rakendamiseks). <\/p>\n

Broadcom'i kiipe hakati juba varem kasutama Cisco Nexus 3000 seeria l\u00fclitites. Nexus 9000 peres, mis on spetsiaalselt v\u00e4lja t\u00f6\u00f6tatud ACI toetamiseks, rakendati algselt h\u00fcbriidmudeleid nimega Merchant+. L\u00fclitites kasutati samaaegselt uut Broadcom Trident 2 kiipi ja Cisco arendatud lisakiipi, mis rakendas kogu ACI maagia. Tundub, et see v\u00f5imaldas kiirendada toote turule viimist ja langetada l\u00fclitite hinda tasemele, mis oli l\u00e4hedane mudelitele, mis kasutasid lihtsalt Trident 2. Seda l\u00e4henemist j\u00e4tkus ACI tarnete esimeseks kaheks-kolmaks aastaks. Selle aja jooksul arendas Cisco v\u00e4lja ja t\u00f5i turule j\u00e4rgmise p\u00f5lvkonna Nexus 9000, mis p\u00f5hines omaenda kiipidel, millel oli suurem j\u00f5udlus ja funktsioonide komplekt, kuid sama hinnatasemega. V\u00e4lised spetsifikatsioonid suhtlemiseks tehases j\u00e4\u00e4vad t\u00e4ielikult muutumatuks. Sellegipoolest seestpoolt oli kogu sisu muutunud: midagi sellist nagu refaktooring, kuid riistvara jaoks.<\/p>\n

Kuidas on \u00fcles ehitatud Cisco ACI arhitektuur <\/h3>\n

\nLihtsaimal juhul ehitatakse ACI Kloosi v\u00f5rgu topoloogiale, v\u00f5i nagu sageli \u00f6eldakse, Spine-Leaf. Spine-taseme l\u00fcliteid v\u00f5ib olla kahest (v\u00f5i \u00fchest, kui me ei muretse t\u00f5rkev\u00f5ime \u00fcle) kuue. Vastavalt sellele, mida rohkem l\u00fcliteid, seda suurem on t\u00f5rkev\u00f5ime (v\u00e4hem riba ja usaldusv\u00e4\u00e4rsuse langust, kui \u00fcks Spine on rikki l\u00e4inud v\u00f5i hoolduses) ja kogu j\u00f5udlus. K\u00f5ik v\u00e4list\u00fckid \u00fchendatakse Leaf-taseme l\u00fclititega: need on nii serverid kui ka \u00fchendused v\u00e4liste v\u00f5rkudega kas L2 v\u00f5i L3 kaudu ning APIC-i kontrollerite \u00fchendamine. \u00dcldiselt toimub ACI puhul mitte ainult seadistamine, vaid ka statistika kogumine, t\u00f5rgete j\u00e4lgimine jm \u2014 k\u00f5ik toimub kontrollerite liidese kaudu, mida tavap\u00e4rastes rakendustes on kolm. <\/p>\n

L\u00fclititega ei pea kunagi konsoliga \u00fchendama, isegi v\u00f5rgu k\u00e4ivitamiseks: kontroller avastab ise l\u00fclitid ja kogub neist tehase, sealhulgas k\u00f5ik teenindusprotokollide seadistused. Seet\u00f5ttu on see v\u00e4ga oluline, et montaa\u017ei k\u00e4igus \u00fcles kirjutada paigaldatava seadme seerianumbrid, et hiljem ei peaks m\u00f5tlema, milline l\u00fcliti mis kapis asub. Probleemide lahendamiseks on l\u00fclititega vajadusel v\u00f5imalik liituda SSH kaudu: nende peal on p\u00f5hjalikult taastatud tavalised Cisco show-k\u00e4sud. <\/p>\n

Sises kasutatakse IP-transpordi tehnikat, nii et Spanning Tree ja muud mineviku probleemid on seal kadunud: k\u00f5ik lingid on aktiivsed, ja t\u00f5rgete korral on taastumine v\u00e4ga kiire. Tehases edastatakse liiklus tunnelite kaudu, mis p\u00f5hinevad VXLAN-il. T\u00e4psemalt \u00f6eldes nimetab Cisco kapseldust iVXLAN-iks, mis erineb tavalisest VXLAN-ist sellega, et v\u00f5rgupealkirja reserveeritud v\u00e4ljad kasutatakse teenusinfo edastamiseks, eelk\u00f5ige \u2014 liikluse seondumise kohta EPG r\u00fchmaga. See v\u00f5imaldab rakendada suhtlemisreegleid r\u00fchmade vahel riistvara kaudu, kasutades nende numbreid, just nagu tavalistes juurdelasku loendites kasutatakse aadresse. <\/p>\n

Tunnelid v\u00f5imaldavad venitada nii L2-segmente kui ka L3 (st VRF) l\u00e4bi sise IP-transpordi. Samuti on vaikimisi marsruuter jaotatud. See t\u00e4hendab, et tehase sisse tuleva liikluse marsruuri m\u00e4\u00e4rab iga l\u00fcliti eraldi. Saadetava liikluse loogika osas sarnaneb ACI VXLAN\/EVPN-tehasele. <\/p>\n

Kui nii, siis milles on erinevused? K\u00f5igis muudates! <\/h3>\n

\nEsimene erinevus, millega ACI-s kokku puututakse, on see, kuidas serverid v\u00f5rku \u00fchendatakse. Traditsioonilistes v\u00f5rkudes \u00fchendatakse nii f\u00fc\u00fcsilised serverid kui ka virtuaalsed VLAN-idesse, ning k\u00f5ik muu s\u00f5ltub sellest: \u00fchenduvus, turvalisus jne. ACI-s kasutatakse konstruktsiooni, mida Cisco nimetab EPG-ks (L\u00f5pp-punkti grupp), millest ei p\u00e4\u00e4se. Kas seda on v\u00f5imalik v\u00f5rdsustada VLAN-iga? Jah, kuid sel juhul on oht kaotada enamik ACI eeliseid. <\/p>\n

EPG suhtes formuleeritakse k\u00f5ik ligip\u00e4\u00e4sureeglid, ja ACI-s kasutatakse vaikimisi 'valge nimekirja' l\u00e4henemist, st lubatud on ainult see liiklus, mille l\u00e4bip\u00e4\u00e4s on selgelt lubatud. Seega saame luua EPG r\u00fchmad 'Web' ja 'MySQL' ning m\u00e4\u00e4rata reegli, mis lubab nendevahelist suhtlemist ainult portaali 3306 kaudu. See t\u00f6\u00f6tab isegi ilma v\u00f5rgu aadresside sidumiseta ja isegi \u00fches samas alamv\u00f5rgus! <\/p>\n

Meil on kliente, kes valisid ACI just selle funktsiooni t\u00f5ttu, kuna see v\u00f5imaldab piirata ligip\u00e4\u00e4se serverite (kas virtuaalsete v\u00f5i f\u00fc\u00fcsiliste \u2013 pole vahet) vahel, ilma et oleks vaja neid alamv\u00f5rkudest \u00fcmber t\u00f5sta, mis t\u00e4hendab, et aadressimist ei puudutata. Jah- jah, me teame, et keegi ei kirjuta neid k\u00e4sitsi IP-aadressid<\/a> rakenduste konfiguratsioonides, eks?<\/p>\n

ACI-s liiklust l\u00e4bimise reeglid on lepingud. Sellises lepingus muutuvad \u00fcks v\u00f5i mitu gruppi v\u00f5i taset mitmeastmelises rakenduses teenuse pakkujateks (\u00f6eldes, andmebaasi teenus), teised aga tarbijateks. Leping v\u00f5ib lihtsalt liiklust edastada v\u00f5i teha midagi keerukamat, n\u00e4iteks suunata tulem\u00fc\u00fcrile v\u00f5i tasakaalustajale ning samuti muuta QoS-i v\u00e4\u00e4rtust.<\/p>\n

Kuidas serverid nendesse gruppidesse satuvad? Kui need on f\u00fc\u00fcsilised serverid v\u00f5i midagi, mis on osa olemasolevast v\u00f5rgust, kuhu oleme loonud VLAN-i trunk, tuleb need EPG-sse paigutamiseks viidata l\u00fcliti portile ja sellel kasutatavale VLAN-ile. Nagu n\u00e4eme, ilmuvad VLAN-id sinna, kus ilma nendeta ei saa.<\/p>\n

Kui aga serverid on virtuaalmasinad, piisab, kui viidata \u00fchendatud virtualiseerimise keskkonnale ja edasi toimub k\u00f5ik iseenesest: luuakse port-grupp (kui r\u00e4\u00e4kida VMWare'i terminoloogiast) VM-ide \u00fchendamiseks, m\u00e4\u00e4ratakse vajalikud VLAN-id v\u00f5i VXLAN-id, kirjutatakse vajalikesse switchi portidesse jne. Nii et kuigi ACI on \u00fcles ehitatud f\u00fc\u00fcsilise v\u00f5rgu \u00fcmber, n\u00e4evad virtuaalserverite \u00fchendused oluliselt lihtsamad v\u00e4lja kui f\u00fc\u00fcsiliste puhul. ACI-s on juba sisseehitatud \u00fchendused VMWare'i ja MS Hyper-V-ga, samuti tugi OpenStackile ja RedHat Virtualization'ile. Teatud hetkest alates on lisaks sisseehitatud tugi konteinerite platvormidele: Kubernetes, OpenShift, Cloud Foundry, kusjuures see h\u00f5lmab nii poliitikate rakendamist kui ka j\u00e4lgimist, see t\u00e4hendab, et v\u00f5rguadministraator n\u00e4eb kohe, millistel hostidel t\u00f6\u00f6tavad millised podid ja millistesse gruppidesse nad kuuluvad.<\/p>\n

Lisaks kuuluvusele \u00fchte v\u00f5i teise port-gruppi on virtuaalserveritel ka t\u00e4iendavad omadused: nimi, atribuudid jne, mida v\u00f5ib kasutada kriteeriumidena nende viimiseks teise gruppi, n\u00e4iteks VM-i \u00fcmbernimetamisel v\u00f5i sellel lisateegi ilmumise korral. Cisco nimetab seda mikrosegmentide gruppideks, kuigi suuremas plaanis on see konstruktsioon, millega on v\u00f5imalik luua palju turvasegmente EPG-de kujul samas alamv\u00f5rgus \u2014 samuti p\u00e4ris mikrosegmentatsioon. No, tootjale on selgem. <\/p>\n

EPG-d on puhtalt loogilised konstruktsioonid, mis ei ole seotud konkreetsete l\u00fclitite, serverite jne, mist\u00f5ttu on nendega ja nende baasil loodud konstruktsioonidega (rakendustega ja tenantidega) v\u00f5imalik teha asju, mida tavap\u00e4rastes v\u00f5rkudes on raske teostada, n\u00e4iteks kloonimine. Seel\u00e4bi on n\u00e4iteks v\u00e4ga lihtne luua kloon tootmiskeskkonnast, et saada testkeskkond, mis on garanteeritult identne tootmisega. Seda saab teha k\u00e4sitsi, kuid parem (ja lihtsam) on kasutada API-d. <\/p>\n

\u00dcldiselt ei sarnane ACI haldustegevuse loogika sellega, millega tavaliselt kokku puututakse
\ntraditsioonilistes Cisco v\u00f5rkudes: programmiline liides on esmase t\u00e4htsusega, samas kui GUI v\u00f5i CLI on sekundaarne, kuna need toimivad sama API kaudu. Seet\u00f5ttu hakkab peaaegu iga\u00fcks, kes tegeleb ACI-ga, m\u00f5ne aja p\u00e4rast orienteeruma haldamiseks kasutatavas objekti mudelis ja automatiseerima midagi vastavalt oma vajadustele. Selleks on k\u00f5ige lihtsam kasutada Pythonit: selle jaoks on olemas mugavad valmis t\u00f6\u00f6riistad. <\/p>\n

Lubatud karid<\/h3>\n

\nPeamine probleem on see, et paljusid asju ACI-s on tehtud teistmoodi. Et hakata sellega \u00f5igesti t\u00f6\u00f6tama, tuleb \u00fcmber \u00f5ppida. Eriti kehtib see v\u00f5rguhooldusmeeskondade kohta suurtes kundedes, kus insenerid on aastaid tegelenud VLAN-ide 'registreerimisega' taotlustes. See, et n\u00fc\u00fcd VLAN ei ole enam VLAN, ja uute v\u00f5rkude loomine virtualiseeritud hostides ei n\u00f5ua VLAN-ide k\u00e4sitsi loomist, 'viib traditsioonilised v\u00f5rgukonsolidatsiooni grave katuselt' ja sunnib neid kinni j\u00e4\u00e4ma harjumusp\u00e4rastes l\u00e4henemisviisides. Tuleb m\u00e4rkida, et Cisco on p\u00fc\u00fcdnud veidi magusamaks muuta ja lisanud kontrollerisse 'NXOS-sarnase' CLI, mis v\u00f5imaldab seadistamist traditsiooniliste l\u00fclitite sarnases liideses. Siiski, et ACI-d korralikult kasutada, tuleb m\u00f5ista, kuidas see t\u00f6\u00f6tab. <\/p>\n

Hinnavaateid vaadates ei erine ACI v\u00f5rgu kulud oluliselt traditsioonilistest Cisco seadmetega v\u00f5rkudest, kuna nende \u00fclesehituseks kasutatakse samu l\u00fclitajaid (Nexus 9000 t\u00f6\u00f6tab nii ACI kui ka traditsioonilises re\u017eiimis ja on n\u00fc\u00fcdseks saanud peamiseks \"t\u00f6\u00f6hobuseks\" uutes andmekeskuse projektides). Ent andmekeskustes, kus on kaks l\u00fclitit, annavad kontrollerite ja Spine-Leaf arhitektuuri olemasolu kindlasti tunda. Hiljuti ilmus Mini ACI tehas, kus kahest kontrollerist kolm on asendatud virtuaalmasinatega. See aitab v\u00e4hendada hinnaerinevust, kuid see j\u00e4\u00e4b siiski olemas. Seega, kliendi valik s\u00f5ltub sellest, kui suures osas ta on huvitatud turvafunktsioonidest, virtualiseerimise integreerimisest, \u00fchest juhtimispunktist ja muudest omadustest.
\n
Allikas: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0421 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0432\u043e\u0442 \u044d\u0442\u043e\u0433\u043e \u0432\u043e\u043b\u0448\u0435\u0431\u043d\u043e\u0433\u043e \u043a\u0443\u0441\u043a\u0430 \u0441\u043a\u0440\u0438\u043f\u0442\u0430 Cisco ACI \u043c\u043e\u0436\u043d\u043e \u0431\u044b\u0441\u0442\u0440\u043e \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0441\u0435\u0442\u044c. \u0421\u0435\u0442\u0435\u0432\u0430\u044f \u0444\u0430\u0431\u0440\u0438\u043a\u0430 \u0434\u043b\u044f \u0426\u041e\u0414\u0430 Cisco ACI c\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u0435\u0442 \u0443\u0436\u0435 \u043f\u044f\u0442\u044c \u043b\u0435\u0442, \u043d\u043e \u043d\u0430 \u0425\u0430\u0431\u0440\u0435 \u043f\u0440\u043e \u043d\u0435\u0451 \u0442\u043e\u043b\u043a\u043e\u043c \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043d\u043e, \u0432\u043e\u0442 \u0438 \u0440\u0435\u0448\u0438\u043b \u044d\u0442\u043e \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u0438\u0441\u043f\u0440\u0430\u0432\u0438\u0442\u044c. \u0420\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043d\u0430 \u0441\u0432\u043e\u0451\u043c \u043e\u043f\u044b\u0442\u0435, \u0447\u0442\u043e \u044d\u0442\u043e \u0442\u0430\u043a\u043e\u0435, \u043a\u0430\u043a\u0430\u044f \u043e\u0442 \u043d\u0435\u0451 \u043f\u043e\u043b\u044c\u0437\u0430 \u0438 \u0433\u0434\u0435 \u0443 \u043d\u0435\u0451 \u0433\u0440\u0430\u0431\u043b\u0438. \u0427\u0442\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35291","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Cisco ACI andmekeskuse l\u00fcliti \u2014 abiks administraatorile | ProHoster","description":"Selle maagilise skripti t\u00fckiga.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/setevaya-fabrika-dlya-tsoda-cisco-aci-v-pomoshh-adminu","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u0435\u0442\u0435\u0432\u0430\u044f \u0444\u0430\u0431\u0440\u0438\u043a\u0430 \u0434\u043b\u044f \u0426\u041e\u0414\u0430 Cisco ACI \u2014 \u0432 \u043f\u043e\u043c\u043e\u0449\u044c \u0430\u0434\u043c\u0438\u043d\u0443 | ProHoster","og:description":"\u0421 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u0432\u043e\u0442 \u044d\u0442\u043e\u0433\u043e \u0432\u043e\u043b\u0448\u0435\u0431\u043d\u043e\u0433\u043e \u043a\u0443\u0441\u043a\u0430 \u0441\u043a\u0440\u0438\u043f\u0442\u0430.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/setevaya-fabrika-dlya-tsoda-cisco-aci-v-pomoshh-adminu","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:03:28+00:00","article:modified_time":"2019-10-31T19:03:28+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35291","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-08 20:27:18","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:06:24","updated":"2026-02-08 20:27:18","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/35291","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=35291"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/35291\/revisions"}],"predecessor-version":[{"id":157819,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/35291\/revisions\/157819"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=35291"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=35291"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=35291"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}