{"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\/da\/blog\/administrirovanie\/application-centric-infrastructure-arhitektura-seti-budushhego-ot-rassuzhdenij-k-delu","title":{"rendered":"Application Centric Infrastructure. Fremtidens netv\u00e6rksarkitektur \u2014 fra overvejelser til handling","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I de seneste \u00e5r har Cisco aktivt promoveret en ny arkitektur til opbygning af datanetv\u00e6rk i datacentre \u2013 Application Centric Infrastructure (eller ACI)<\/b>. Nogle er allerede bekendt med den. Andre har endda implementeret den i deres virksomheder, herunder i Rusland. For de fleste IT-specialister og IT-ledere er ACI endnu enten en uforst\u00e5elig forkortelse eller blot en diskussion om fremtiden.
\nI denne artikel vil vi fors\u00f8ge at g\u00f8re denne fremtid mere n\u00e6rv\u00e6rende. Vi vil fort\u00e6lle om de vigtigste arkitektoniske komponenter i ACI samt illustrere, hvordan den anvendes i praksis. Derudover vil vi snart organisere en visuel demonstration af ACI, som hver interesseret IT-specialist kan tilmelde sig.
\n<\/a><\/noindex>
\nMan kan l\u00e6re mere om den nye arkitektur til opbygning af netv\u00e6rk i Sankt Petersborg i maj 2019. Alle detaljer \u2013 via linket<\/a><\/noindex>. Tilmeld dig!<\/p>\n

Background<\/b>
\nDen traditionelle og mest popul\u00e6re model til opbygning af netv\u00e6rk er den tre-lags hierarkiske model: kerne -> distribution (aggregering) -> adgang. I mange \u00e5r har denne model v\u00e6ret en standard, og producenter har udviklet forskellige netv\u00e6rksenheder baseret p\u00e5 denne funktionalitet.
\nTidligere, da informationsteknologi var en slags n\u00f8dvendig (og, lad os v\u00e6re \u00e6rlige, ikke altid \u00f8nsket) supplement til forretningen, var denne model praktisk, ret statisk og p\u00e5lidelig. Men nu, n\u00e5r IT er en af drivkr\u00e6fterne bag forretningsudvikling og i mange tilf\u00e6lde selve forretningen, begyndte statikken i denne model at skabe store problemer.<\/p>\n

Moderne forretninger genererer et stort antal forskellige komplekse krav til netv\u00e6rksinfrastrukturen. Succes for virksomheden afh\u00e6nger direkte af, hvor hurtigt disse krav kan opfyldes. I s\u00e5danne tilf\u00e6lde er forsinkelser uacceptable, og den klassiske model for netv\u00e6rksopbygning opfylder ofte ikke alle forretningsbehov til tiden. <\/p>\n

For example, the emergence of a new complex business application requires network administrators to perform a large number of similar routine operations on many different network devices at various levels. Besides taking a lot of time, it also increases the risk of making a mistake that could lead to significant downtime of IT services and, consequently, financial losses.<\/p>\n

The root of the problem is not even the deadlines or the complexity of the requirements. The issue is that these requirements need to be 'translated' from the language of business applications into the language of network infrastructure. As we know, any translation always entails a partial loss of meaning. When the application owner talks about the logic of how their application works, the network administrator thinks in terms of VLANs, Access lists across dozens of devices, which need to be maintained, updated, and documented.<\/p>\n

The accumulated experience and continuous communication with customers have enabled Cisco to design and implement new principles for building data transmission networks in data centers that respond to modern trends and are primarily based on the logic of business applications. Hence the name \u2014 Application Centric Infrastructure.<\/p>\n

ACI Architecture.<\/b>
\nThe ACI architecture is best viewed not from a physical standpoint but from a logical one. It is based on an automated policy model, the objects of which can be divided at the highest level into the following components:<\/p>\n

    \n
  1. Network based on Nexus switches.<\/li>\n
  2. APIC controller cluster;<\/li>\n
  3. Application profiles;<\/li>\n<\/ol>\n

    \n\"Application
    \nLet\u2019s look at each level in more detail \u2014 moving from simple to complex.<\/p>\n

    Network based on Nexus switches.<\/b>
    \nThe network in the ACI fabric resembles a traditional hierarchical model but is built much more simply. The Leaf-Spine model is used for network organization, which has become an accepted approach for implementing next-generation networks. This model consists of two levels: Spine and Leaf, respectively.
    \n \"Application
    \nThe Spine level is solely responsible for performance. The total performance of the Spine switches equals the performance of the entire fabric, so switches with ports of 40G or higher should be used at this level.
    \nSpine-switches forbinder alle switcher p\u00e5 n\u00e6ste niveau: Leaf-switcher, som de endelige v\u00e6rter tilsluttes. Den prim\u00e6re rolle for Leaf-switcherne er portkapaciteten. <\/p>\n

    Dermed l\u00f8ses skaleringsproblemer nemt: hvis vi skal \u00f8ge b\u00e5ndbredden i fabrikken, tilf\u00f8jer vi Spine-switcher, og hvis vi skal \u00f8ge portkapaciteten \u2013 Leaf.
    \nBegge niveauer bruger switcher fra serien Cisco Nexus 9000, som er det prim\u00e6re v\u00e6rkt\u00f8j for Cisco til opbygning af datacenter-netv\u00e6rk uanset deres arkitektur. Til Spine-niveauet bruges Nexus 9300- eller Nexus 9500-switcher, mens der kun bruges Nexus 9300 til Leaf.
    \nModellinjen af switches fra Nexus, der anvendes i ACI-fabrikken, er vist p\u00e5 billedet nedenfor.
    \n \"Application<\/p>\n

    APIC-controller-klyngen (Application Policy Infrastructure Controller) <\/b>
    \nAPIC-controllere er specialiserede fysiske servere, hvor det er tilladt at bruge en klynge best\u00e5ende af en fysisk APIC-controller og to virtuelle til sm\u00e5 installationer.
    \nAPIC-controllerne udf\u00f8rer administrations- og overv\u00e5gningsfunktioner. Det er vigtigt, at controllerne aldrig deltager i dataoverf\u00f8rsel, hvilket betyder, at selvom alle controllerne i klyngen skulle svigte, vil det ikke p\u00e5virke netv\u00e6rkets stabilitet. Det skal ogs\u00e5 bem\u00e6rkes, at med hj\u00e6lp fra APIC kan administratoren styre alle fysiske og logiske ressourcer i fabrikken, og for at foretage \u00e6ndringer kr\u00e6ves det ikke l\u00e6ngere at oprette forbindelse til enhederne, da ACI bruger et enkelt kontrolpunkt.
    \n \"Application<\/p>\n

    Lad os nu g\u00e5 videre til en af de vigtigste komponenter i ACI \u2013 applikationsprofiler.<\/b>
    \nApplikationsprofil (Application Network Profile)<\/b> er det logiske grundlag for ACI. Det er netop applikationsprofilerne, der definerer politikkerne for interaktion mellem alle netv\u00e6rkssegmenter og beskriver selve netv\u00e6rkssegmenterne. ANP g\u00f8r det muligt at abstrahere fra det fysiske niveau og reelt forestille sig, hvordan interaktionen mellem forskellige netv\u00e6rkssegmenter skal organiseres set fra applikationens perspektiv. <\/p>\n

    Applikationens profil best\u00e5r af forbindelsesgrupper (End-point groups \u2013 EPG). En forbindelsesgruppe er en logisk gruppe af v\u00e6rter (virtuel maskiner, fysiske servere, containere osv.), der befinder sig i et enkelt sikkerhedssegment (ikke netv\u00e6rk, men specifikt sikkerhed). De endelige v\u00e6rter, der tilh\u00f8rer en bestemt EPG, kan bestemmes ud fra mange kriterier. Normalt bruges f\u00f8lgende: <\/p>\n