{"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\/ro\/blog\/administrirovanie\/application-centric-infrastructure-arhitektura-seti-budushhego-ot-rassuzhdenij-k-delu","title":{"rendered":"Infrastructure Centric\u0103 pe Aplica\u021bii. Arhitectura re\u021belei viitorului \u2014 de la reflec\u021bii la ac\u021biune","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00cen ultimii c\u00e2\u021biva ani, Cisco a promovat activ o nou\u0103 arhitectur\u0103 pentru construirea re\u021belelor de date \u00een centrele de date \u2014 Application Centric Infrastructure (sau ACI)<\/b>. Unii sunt deja familiariza\u021bi cu aceasta. Al\u021bii au reu\u0219it chiar s\u0103 o implementeze \u00een organiza\u021biile lor, inclusiv \u00een Rusia. Cu toate acestea, pentru majoritatea speciali\u0219tilor IT \u0219i liderilor IT, ACI r\u0103m\u00e2ne fie o abreviere neclar\u0103, fie doar o discu\u021bie despre viitor.
\n\u00cen acest articol, ne propunem s\u0103 apropiem acest viitor. Vom discuta despre componentele arhitecturale principale ale ACI \u0219i vom ilustra modul de aplicare a acesteia \u00een practic\u0103. \u00cen plus, \u00een cur\u00e2nd vom organiza o demonstra\u021bie vizual\u0103 a func\u021bion\u0103rii ACI, la care se pot \u00eenscrie to\u021bi speciali\u0219tii IT interesa\u021bi.
\n<\/a><\/noindex>
\nPentru a afla mai multe despre noua arhitectur\u0103 de re\u021bea, pute\u021bi participa \u00een Petersburg \u00een mai 2019. Toate detaliile le g\u0103si\u021bi la linkul<\/a><\/noindex>. \u00censcrie\u021bi-v\u0103!<\/p>\n

Povestea<\/b>
\nModelul tradi\u021bional \u0219i cel mai popular pentru construirea re\u021belei este modelul ierarhic pe trei niveluri: nucleu -> distribu\u021bie (agregare) -> acces. De-a lungul anilor, acest model a fost etalonul, iar produc\u0103torii au creat diverse dispozitive de re\u021bea corespunz\u0103toare func\u021bionalit\u0103\u021bii sale.
\n\u00cen trecut, c\u00e2nd tehnologiile informa\u021biei erau un fel de accesorii necesare (\u0219i, sincer, nu \u00eentotdeauna dorite) pentru afaceri, acest model era convenabil, foarte static \u0219i fiabil. Totu\u0219i, acum, c\u00e2nd IT-ul este unul dintre motoarele dezvolt\u0103rii afacerii \u0219i, \u00een multe cazuri, \u00eens\u0103\u0219i afacerea, staticitatea acestui model a \u00eenceput s\u0103 ridice mari probleme.<\/p>\n

Afacerea modern\u0103 genereaz\u0103 o mul\u021bime de cerin\u021be complexe pentru infrastructura de re\u021bea. Succesul afacerii depinde direct de termenele de realizare a acestor cerin\u021be. \u00cent\u00e2rzierea \u00een astfel de condi\u021bii este inacceptabil\u0103, iar modelul clasic de construc\u021bie a re\u021belei adesea nu permite satisfacerea la timp a toate nevoile de afaceri. <\/p>\n

De exemplu, apari\u021bia unei noi aplica\u021bii de afaceri complexe implic\u0103 realizarea unui num\u0103r mare de opera\u021biuni rutiniere de c\u0103tre administratorii de re\u021bea pe un num\u0103r mare de dispozitive de re\u021bea diferite la diverse niveluri. Pe l\u00e2ng\u0103 faptul c\u0103 acest lucru dureaz\u0103 mult timp, cre\u0219te \u0219i riscul de a face o gre\u0219eal\u0103 care poate duce la o \u00eentrerupere serioas\u0103 a serviciilor IT \u0219i, ca rezultat, la pierderi financiare.<\/p>\n

R\u0103d\u0103cina problemei nu sunt nici termenele, nici complexitatea cerin\u021belor. Problema este c\u0103 aceste cerin\u021be trebuie 'traduse' din limba aplica\u021biilor de afaceri \u00een limba infrastructurii de re\u021bea. A\u0219a cum se \u0219tie, orice traducere implic\u0103 \u00eentotdeauna o pierdere par\u021bial\u0103 a sensului. C\u00e2nd proprietarul aplica\u021biei vorbe\u0219te despre logica de func\u021bionare a aplica\u021biei sale, administratorul de re\u021bea \u00een\u021belege un set de VLAN-uri \u0219i liste de acces pe zeci de dispozitive care trebuie men\u021binute, actualizate \u0219i documentate.<\/p>\n

Experien\u021ba acumulat\u0103 \u0219i comunicarea constant\u0103 cu clien\u021bii au permis Cisco s\u0103 proiecteze \u0219i s\u0103 implementeze noi principii pentru construirea re\u021belei de transmisie de date a centrului de date, care r\u0103spund tendin\u021belor actuale \u0219i se bazeaz\u0103, \u00een primul r\u00e2nd, pe logica aplica\u021biilor de afaceri. De aici \u0219i numele \u2014 Infrastructure Centric\u0103 pe Aplica\u021bie.<\/p>\n

Arhitectura ACI.<\/b>
\nArhitectura ACI trebuie v\u0103zut\u0103 mai degrab\u0103 dintr-o perspectiv\u0103 logic\u0103 dec\u00e2t fizic\u0103. Aceasta se bazeaz\u0103 pe un model de politici automatizate, a c\u0103ror obiecte la nivel \u00eenalt pot fi \u00eemp\u0103r\u021bite \u00een urm\u0103toarele componente:<\/p>\n

    \n
  1. Re\u021bea bazat\u0103 pe comutatoare Nexus.<\/li>\n
  2. Cluster de controlere APIC;<\/li>\n
  3. Profiluri de aplica\u021bii;<\/li>\n<\/ol>\n

    \n\"Infrastructure
    \nS\u0103 analiz\u0103m fiecare nivel mai \u00een detaliu \u2013 iar noi vom trece de la simplu la complex.<\/p>\n

    Re\u021bea bazat\u0103 pe comutatoare Nexus<\/b>
    \nRe\u021beaua din fabrica ACI seam\u0103n\u0103 cu modelul ierarhic tradi\u021bional, dar este construit\u0103 mult mai simplu. Pentru organizarea re\u021belei se folose\u0219te modelul Leaf-Spine, care a devenit o abordare comun\u0103 pentru implementarea re\u021belelor de nou\u0103 genera\u021bie. Acest model este compus din dou\u0103 niveluri: Spine \u0219i Leaf.
    \n \"Infrastructure
    \nNivelul Spine se ocup\u0103 doar de performan\u021b\u0103. Performan\u021ba total\u0103 a comutatoarelor Spine este egal\u0103 cu performan\u021ba \u00eentregii fabrici, de aceea la acest nivel ar trebui folosite comutatoare cu porturi de 40G sau mai mari.
    \nComutatoarele Spine se conecteaz\u0103 la toate comutatoarele de nivel superior: comutatoarele Leaf, la care se conecteaz\u0103 gazdele finale. Rolul principal al comutatoarelor Leaf este capacitatea portului. <\/p>\n

    Astfel, se rezolv\u0103 cu u\u0219urin\u021b\u0103 problemele de scalabilitate: dac\u0103 avem nevoie s\u0103 cre\u0219tem capacitatea fabricii, ad\u0103ug\u0103m comutatoare Spine, iar dac\u0103 avem nevoie s\u0103 cre\u0219tem capacitatea portului \u2013 comutatoare Leaf.
    \nPentru ambele niveluri se utilizeaz\u0103 comutatoare din seria Cisco Nexus 9000, care pentru Cisco sunt instrumentul principal pentru construirea re\u021belelor de centre de date, indiferent de arhitectura acestora. Pentru nivelul Spine se folosesc comutatoare Nexus 9300 sau Nexus 9500, iar pentru Leaf doar Nexus 9300.
    \nGama de comutatoare Nexus utilizate \u00een fabrica ACI este prezentat\u0103 \u00een figura de mai jos.
    \n \"Infrastructure<\/p>\n

    Clusterul de control APIC (Application Policy Infrastructure Controller) <\/b>
    \nControlerele APIC reprezint\u0103 servere fizice specializate, iar pentru implement\u0103ri mai mici se permite utilizarea unui cluster format dintr-un singur controler APIC fizic \u0219i dou\u0103 virtuale.
    \nControlerele APIC exercit\u0103 func\u021bii de gestionare \u0219i monitorizare. Este important de men\u021bionat c\u0103 controlerele nu particip\u0103 niciodat\u0103 la transferul de date, adic\u0103, chiar dac\u0103 toate controlerele din cluster e\u0219ueaz\u0103, stabilitatea re\u021belei nu va fi afectat\u0103. De asemenea, este necesar s\u0103 subliniem c\u0103, prin intermediul APIC-urilor, administratorul gestioneaz\u0103 toate resursele fizice \u0219i logice ale fabricii, iar pentru a face modific\u0103ri, nu este nevoie s\u0103 se conecteze la un anumit dispozitiv, deoarece \u00een ACI se folose\u0219te un punct unic de gestionare.
    \n \"Infrastructure<\/p>\n

    Acum s\u0103 trecem la unul dintre cele mai importante componente ale ACI \u2013 profilurile aplica\u021biilor.<\/b>
    \nProfilul aplica\u021biei (Application Network Profile)<\/b> \u2013 este baza logic\u0103 a ACI. Anume profilurile aplica\u021biilor definesc politicile de interac\u021biune \u00eentre toate segmentele re\u021belei \u0219i descriu direct segmentele de re\u021bea. ANP permite abstractizarea de nivelul fizic \u0219i, \u00een esen\u021b\u0103, a\u0219a cum ar trebui organizat\u0103 interac\u021biunea \u00eentre diferitele segmente ale re\u021belei din perspectiva aplica\u021biei. <\/p>\n

    Profilul aplica\u021biei const\u0103 din grupuri de conexiuni (End-point groups \u2013 EPG). Un grup de conexiuni este un grup logic de gazde (ma\u0219ini virtuale, servere fizice, containere etc.) care se afl\u0103 \u00eentr-un singur segment de securitate (nu al re\u021belei, ci anume al securit\u0103\u021bii). Gazdele finale care apar\u021bin unui anumit EPG pot fi definite printr-un num\u0103r mare de criterii. De obicei, sunt folosite urm\u0103toarele: <\/p>\n