A modern adatközpontokban több száz aktív eszköz van telepítve, amelyekre különböző típusú megfigyelések vonatkoznak. De még egy tökéletes felügyelettel rendelkező ideális mérnök is képes néhány perc alatt helyesen reagálni a hálózati hibákra. A Next Hop 2020 konferencián egy beszámolóban bemutattam egy egyenáramú hálózattervezési módszert, amely egyedülálló tulajdonsággal rendelkezik - az adatközpont ezredmásodpercek alatt meggyógyul. Pontosabban a mérnök higgadtan orvosolja a problémát, miközben a szervizek egyszerűen nem veszik észre.
Sok hálózati mérnök számára az adatközponti hálózat természetesen a ToR-ral kezdődik, egy kapcsolóval a rackben. A ToR rendszerint kétféle hivatkozást tartalmaz. A kicsik a szerverekre, mások - N-szer többen vannak - az első szint gerincei, vagyis annak uplinkjei felé mennek. A felfelé irányuló kapcsolatokat általában egyenlőnek tekintik, és a felfelé irányuló kapcsolatok közötti forgalom kiegyensúlyozása az 5 sorból származó hash alapján történik, amely magában foglalja a proto, src_ip, dst_ip, src_port és dst_port fájlokat. Itt nincs meglepetés.
Ezután hogyan néz ki a terv architektúrája? Az első szint tüskék nem kapcsolódnak egymáshoz, hanem szupertüskéken keresztül kapcsolódnak egymáshoz. Az X betű lesz a felelős a szupertüskékért; majdnem olyan, mint egy keresztkapcsolat.
És nyilvánvaló, hogy a tori az első szint összes gerincéhez kapcsolódik. Mi a fontos ezen a képen? Ha interakciónk van a rack-en belül, akkor az interakció természetesen a ToR-on keresztül megy végbe. Ha az interakció a modulon belül történik, akkor az interakció az első szintű gerinceken keresztül történik. Ha a kölcsönhatás intermoduláris - mint itt, a ToR 1 és a ToR 2 -, akkor az interakció az első és a második szint gerincein is átmegy.
Elméletileg egy ilyen architektúra könnyen méretezhető. Ha van portkapacitásunk, szabad helyünk az adatközpontban és előre lefektetett üvegszálunk, akkor a sávok száma mindig növelhető, ezzel is növelve a rendszer teljes kapacitását. Ezt papíron nagyon könnyű megtenni. Ilyen lenne az életben. De a mai történet nem erről szól.
Azt akarom, hogy levonják a megfelelő következtetéseket. Az adatközponton belül számos út áll rendelkezésre. Feltételesen függetlenek. Az adatközponton belüli egy útvonal csak a ToR-on belül lehetséges. A modulon belül a sávok számával megegyező számú útvonalunk van. A modulok közötti utak száma megegyezik az egyes síkok síkjainak és szupertüskék számának szorzatával. A világosabbá tétel és a méretarány érzékelése érdekében olyan számokat adok, amelyek az egyik Yandex adatközpontra érvényesek.
Nyolc sík van, mindegyik síknak 32 szupertüskéje van. Ennek eredményeként kiderül, hogy nyolc útvonal van a modulon belül, és a modulok közötti interakcióval már 256 van belőlük.
Vagyis, ha a Cookbookot fejlesztjük, és megpróbáljuk megtanulni, hogyan építsünk hibatűrő adatközpontokat, amelyek öngyógyulnak, akkor a síkbeli architektúra a megfelelő választás. Megoldja a méretezési problémát, és elméletileg egyszerű. Számos független út létezik. A kérdés továbbra is fennáll: hogyan éli túl egy ilyen architektúra a kudarcokat? Különféle kudarcok vannak. És ezt most megbeszéljük.
Hagyja, hogy valamelyik szupergerincünk „megbetegedjen”. Itt visszatértem a kétsík architektúrához. Maradjunk ezeknél példaként, mert egyszerűen könnyebb lesz látni, mi történik kevesebb mozgó alkatrész esetén. Hagyd, hogy X11 beteg legyen. Hogyan érinti ez az adatközpontokban élő szolgáltatásokat? Sok múlik azon, hogy valójában hogyan is néz ki a hiba.
Ha jó a meghibásodás, ugyanannak a BFD-nek az automatizálási szintjén elkapják, az automatika vígan felrakja a problémás kötéseket és elkülöníti a problémát, akkor minden rendben. Sok útvonalunk van, a forgalom azonnal átterelődik alternatív útvonalakra, és a szolgálatok nem vesznek észre semmit. Ez egy jó forgatókönyv.
Rossz forgatókönyv, ha állandó veszteségeink vannak, és az automatizálás nem veszi észre a problémát. Ahhoz, hogy megértsük, ez hogyan érinti az alkalmazást, el kell szánnunk egy kis időt a TCP működésének megbeszélésére.
Remélem ezzel az információval nem sokkolok senkit: a TCP egy átvitel-megerősítő protokoll. Vagyis a legegyszerűbb esetben a feladó két csomagot küld, és kumulatív visszajelzést kap rájuk: „Két csomagot kaptam”.
Ezután még két csomagot küld, és a helyzet megismétlődik. Előre is elnézést kérek némi egyszerűsítésért. Ez a forgatókönyv akkor helyes, ha az ablak (a repülés közbeni csomagok száma) kettő. Természetesen általános esetben ez nem feltétlenül van így. De az ablak mérete nem befolyásolja a csomagtovábbítási környezetet.
Mi történik, ha elveszítjük a 3. csomagot? Ebben az esetben a címzett megkapja az 1-es, 2-es és 4-es csomagokat. A SACK opcióval pedig kifejezetten közli a feladóval: „Tudod, három megérkezett, de a közepe elveszett.” Azt mondja: "Ack 2, SACK 4."
Ebben a pillanatban a feladó minden probléma nélkül pontosan megismétli az elveszett csomagot.
De ha az utolsó csomag elveszik az ablakban, a helyzet teljesen másképp fog kinézni.
A címzett megkapja az első három csomagot, és először várni kezd. A Linux kernel TCP-verme néhány optimalizálásának köszönhetően vár egy párosított csomagra, hacsak a jelzők nem jelzik kifejezetten, hogy az utolsó csomag vagy valami hasonló. Megvárja, amíg a késleltetett ACK időtúllépés lejár, majd visszaigazolást küld az első három csomagról. De most a feladó várni fog. Nem tudja, hogy a negyedik csomag elveszett-e, vagy hamarosan megérkezik. És annak érdekében, hogy ne terhelje túl a hálózatot, megpróbálja megvárni a csomag elvesztésének kifejezett jelzését, vagy az RTO időtúllépésének lejártát.
Mi az RTO időtúllépés? Ez a TCP-verem és néhány állandó által számított RTT maximuma. Hogy ez milyen állandó, azt most megvitatjuk.
De az a fontos, hogy ha megint nincs szerencsénk, és ismét elveszik a negyedik csomag, akkor az RTO megduplázódik. Vagyis minden sikertelen kísérlet az időtúllépés megduplázását jelenti.
Most pedig nézzük meg, mivel egyenlő ez az alap. Alapértelmezés szerint a minimális RTO 200 ms. Ez az adatcsomagok minimális RTO. A SYN csomagoknál ez más, 1 másodperc. Amint láthatja, még a csomagok újraküldésének első kísérlete is százszor tovább tart, mint az adatközponton belüli RTT.
Most térjünk vissza a forgatókönyvünkhöz. Mi történik a szolgáltatással? A szolgáltatás elkezdi elveszíteni a csomagokat. Legyen a szolgáltatás eleinte feltételesen szerencsés, és az ablak közepén veszítsen valamit, majd kap egy SACK-ot és újraküldi az elveszett csomagokat.
De ha a balszerencse megismétlődik, akkor RTO-nk van. Mi itt a fontos? Igen, sok út van a hálózatunkban. De egy adott TCP-kapcsolat TCP-forgalma továbbra is ugyanazon a megszakadt veremen megy keresztül. A csomagvesztés, feltéve, hogy ez a varázslatos X11-ünk nem megy ki magától, nem vezet a forgalom nem problémás területekre való beáramlásához. A csomagot ugyanazon a törött veremen keresztül próbáljuk kézbesíteni. Ez lépcsőzetes meghibásodáshoz vezet: az adatközpont egymással kölcsönhatásban álló alkalmazások halmaza, és ezeknek az alkalmazásoknak néhány TCP-kapcsolata leépül – mivel a szuperspine az adatközpontban létező összes alkalmazást érinti. Ahogy a mondás tartja: ha lovat nem patkoltál, sánta lett a ló; a ló megbénult - a jelentést nem kézbesítették; a jelentést nem kézbesítették – elvesztettük a háborút. Csak itt a számlálás másodpercekben történik a probléma felmerülésének pillanatától a leromlás azon szakaszáig, amelyet a szolgáltatások kezdenek érezni. Ez azt jelenti, hogy a felhasználók valahol lemaradhatnak valamiről.
Két klasszikus megoldás létezik, amelyek kiegészítik egymást. Az első a szolgáltatások, amelyek megpróbálják a szalmaszálakat beletenni, és így oldják meg a problémát: „Csípjünk meg valamit a TCP-veremben. Tegyünk időtúllépéseket az alkalmazás szintjén vagy hosszú életű TCP-munkameneteket belső állapotellenőrzéssel.” A probléma az, hogy az ilyen megoldások: a) egyáltalán nem skálázódnak; b) nagyon rosszul ellenőrizték. Vagyis még akkor is, ha a szolgáltatás véletlenül úgy konfigurálja a TCP-vermet, hogy jobbá tegye, egyrészt valószínűleg nem lesz alkalmazható minden alkalmazásra és minden adatközpontra, másrészt valószínűleg nem fogja megérteni, hogy megtörtént. helyesen, és mit nem. Vagyis működik, de rosszul működik és nem skálázódik. És ha hálózati probléma van, ki a hibás? Természetesen NOC. Mit csinál a NOC?
Sok szolgálat úgy véli, hogy a NOC-ban ilyesmi történik. De hogy őszinte legyek, nem csak ez.
A klasszikus sémában a NOC számos megfigyelő rendszer fejlesztésével foglalkozik. Ezek a fekete dobozok és a fehér dobozok figyelése is. Egy példa a fekete doboz gerincének megfigyelésére Alexander Klimenko az utolsó Next Hop-on. Ez a megfigyelés egyébként működik. De még az ideális megfigyelésnek is lesz időeltolódása. Általában ez néhány perc. Miután kialudt, az ügyeletes mérnököknek időre van szükségük, hogy még egyszer ellenőrizzék a működését, lokalizálják a problémát, majd eloltsák a problémás területet. Vagyis a probléma kezelése a legjobb esetben 5 percet, legrosszabb esetben 20 percet vesz igénybe, ha nem egyértelmű, hogy hol keletkeznek a veszteségek. Nyilvánvaló, hogy ennyi ideig - 5 vagy 20 percig - szolgáltatásaink továbbra is szenvedni fognak, ami valószínűleg nem jó.
Mit szeretnél igazán kapni? Nagyon sok módunk van. A problémák pedig éppen azért merülnek fel, mert a szerencsétlen TCP-folyamok továbbra is ugyanazt az útvonalat használják. Szükségünk van valamire, ami lehetővé teszi több útvonal használatát egyetlen TCP-kapcsolaton belül. Úgy tűnik, van megoldásunk. Létezik TCP, amit többútvonalas TCP-nek neveznek, vagyis TCP több útvonalhoz. Igaz, teljesen más feladatra fejlesztették ki - több hálózati eszközzel rendelkező okostelefonokhoz. Az átvitel maximalizálása vagy az elsődleges/tartalék mód létrehozása érdekében egy olyan mechanizmust fejlesztettek ki, amely több szálat (munkamenetet) hoz létre átláthatóan az alkalmazás számára, és hiba esetén lehetővé teszi a köztük való váltást. Vagy, ahogy mondtam, maximalizáld a sorozatot.
De van itt egy árnyalat. Ahhoz, hogy megértsük, mi ez, meg kell vizsgálnunk, hogyan jönnek létre a szálak.
A szálak egymás után kerülnek telepítésre. Először az első szál kerül telepítésre. A következő szálakat a rendszer az adott szálon belül már egyeztetett cookie használatával állítja be. És itt van a probléma.
A probléma az, hogy ha az első szál nem jön létre, akkor a második és a harmadik szál soha nem jön létre. Vagyis a többutas TCP nem oldja meg a SYN-csomag elvesztését az első folyamban. És ha a SYN elveszik, a többutas TCP normál TCP-vé változik. Ez azt jelenti, hogy adatközponti környezetben ez nem segít abban, hogy megoldjuk a gyári veszteségek problémáját, és megtanuljunk több utat használni meghibásodás esetén.
Mi segíthet nekünk? Néhányan már a címből sejtették, hogy további történetünk fontos mezője lesz az IPv6 folyamcímke fejléc mezője. Valóban, ez egy olyan mező, amely a v6-ban megjelenik, a v4-ben nem, 20 bitet foglal el, és régóta vita folyik a használatáról. Ez nagyon érdekes - voltak viták, valamit javítottak az RFC-n belül, és ezzel egyidejűleg megjelent egy implementáció a Linux kernelben, ami sehol nem volt dokumentálva.
Meghívom, hogy menjen el velem egy kis nyomozásra. Vessünk egy pillantást arra, hogy mi történt a Linux kernelben az elmúlt néhány évben.
2014-es év. Egy nagy és elismert vállalat mérnöke a Linux kernel funkcionalitását a folyamatcímke értékének a socket hash-től való függésével bővíti. Mit akartak itt megjavítani? Ez az RFC 6438 szabványhoz kapcsolódik, amely a következő problémát tárgyalta. Az adatközponton belül az IPv4 gyakran IPv6-os csomagokba van zárva, mert maga a gyár IPv6, de az IPv4-et valahogy kívül kell adni. Sokáig gondok voltak azokkal a kapcsolókkal, amelyek nem tudtak két IP-fejléc alatt átnézni a TCP-re vagy az UDP-re, és ott megtalálni az src_ports, dst_ports-t. Kiderült, hogy a hash, ha megnézzük az első két IP-fejlécet, szinte javítottnak bizonyult. Ennek elkerülése érdekében, hogy ennek a beágyazott forgalomnak a kiegyensúlyozása megfelelően működjön, azt javasolták, hogy az 5 sorból álló csomag kivonatát adják hozzá a folyamatcímke mező értékéhez. Körülbelül ugyanezt csinálták más beágyazási sémáknál, UDP-nél, GRE-nél, utóbbi a GRE Key mezőt használta. Így vagy úgy, a célok itt egyértelműek. És legalább abban az időben hasznosak voltak.
2015-ben egy új javítás érkezik ugyanattól a tekintélyes mérnöktől. Nagyon érdekes. A következőt írja ki - negatív útválasztási esemény esetén véletlenszerűvé tesszük a hash-t. Mi az a negatív útválasztási esemény? Ez az RTO, amit korábban tárgyaltunk, vagyis az ablak farkának elvesztése valóban negatív esemény. Igaz, viszonylag nehéz kitalálni, hogy ez az.
2016, egy másik jó nevű cég, szintén nagy. Szétszedi az utolsó mankókat, és úgy csinálja, hogy a korábban véletlenszerűen készített hash most minden SYN újraadásnál és minden RTO időtúllépés után megváltozik. Ebben a levélben pedig először és utoljára kerül megfogalmazásra a végső cél – annak biztosítása, hogy a forgalom veszteségek vagy csatornatorlódások esetén képes legyen lágyan átirányítani és több útvonalat használni. Persze ezek után rengeteg publikáció született, ezeket könnyen megtalálod.
Bár nem, nem lehet, mert egyetlen publikáció sem jelent meg ebben a témában. De tudjuk!
És ha nem teljesen érted, mi történt, akkor most elmondom.
Mi történt, milyen funkciókkal bővült a Linux kernel? A txhash minden RTO esemény után véletlenszerű értékre változik. Ez az útválasztás nagyon negatív eredménye. A hash ettől a txhash-től, a folyamatcímke pedig az skb-kivonattól függ. Itt van néhány számítás a függvényekre vonatkozóan, minden részlet nem helyezhető el egy diára. Ha valaki kíváncsi, átnézheti a kernel kódját és ellenőrizheti.
Mi itt a fontos? A folyamatcímke mező értéke minden RTO után véletlenszerű számra változik. Hogyan érinti ez a szerencsétlen TCP adatfolyamunkat?
Ha SACK történik, semmi sem változik, mert egy ismert elveszett csomagot próbálunk újra elküldeni. Eddig jó.
De az RTO esetében, feltéve, hogy a ToR hash függvényéhez folyamcímkét adtunk, a forgalom más útvonalon haladhat. És minél több a sáv, annál nagyobb az esélye, hogy olyan utat talál, amelyet nem érint egy adott eszköz meghibásodása.
Egy probléma maradt - az RTO. Természetesen van egy másik útvonal is, de sok idő elpazarol erre. 200 ms sok. Egy másodperc teljesen vad. Korábban beszéltem az időkorlátokról, amikor a szolgáltatások be vannak állítva. A második tehát egy időtúllépés, amit általában alkalmazás szinten konfigurál a szolgáltatás, és ebben még viszonylag helyes is lesz a szolgáltatás. Sőt, ismétlem, a valódi RTT egy modern adatközpontban körülbelül 1 ezredmásodperc.
Mit lehet tenni az RTO időtúllépésekkel? Az adatcsomagok elvesztése esetén az RTO-ért felelős timeout viszonylag egyszerűen konfigurálható felhasználói térből: van egy IP segédprogram, amelynek egyik paramétere ugyanazt az rto_min értéket tartalmazza. Figyelembe véve, hogy az RTO-t természetesen nem globálisan, hanem adott előtagokhoz kell igazítani, egy ilyen mechanizmus meglehetősen működőképesnek tűnik.
Igaz, a SYN_RTO-val minden valamivel rosszabb. Természetesen le van szögezve. A kernel fix értéke 1 másodperc, és ennyi. A felhasználói területről nem lehet elérni. Csak egy út van.
Az eBPF segít. Leegyszerűsítve kis C-programokról van szó, amelyek a kernel-verem és a TCP-verem végrehajtása során különböző helyeken hook-okba illeszthetők, amelyekkel nagyon sok beállítást módosíthatunk. Általában az eBPF egy hosszú távú trend. Ahelyett, hogy több tucat új sysctl paramétert levágnának és bővítenék az IP-segédprogramot, a mozgás az eBPF felé halad, és bővíti annak funkcionalitását. Az eBPF használatával dinamikusan módosíthatja a torlódásvezérlést és számos egyéb TCP-beállítást.
De fontos számunkra, hogy a SYN_RTO értékek megváltoztatására használható legyen. Sőt, van egy nyilvánosan közzétett példa: . Mit csináltak itt? A példa működik, de önmagában nagyon durva. Itt azt feltételezzük, hogy az adatközponton belül összehasonlítjuk az első 44 bitet, ha egyezik, akkor az adatközpontban vagyunk. És ebben az esetben módosítjuk a SYN_RTO időtúllépés értékét 4 ms-ra. Ugyanez a feladat sokkal elegánsabban is elvégezhető. De ez az egyszerű példa azt mutatja, hogy ez a) lehetséges; b) viszonylag egyszerű.
Mit tudunk már? Az a tény, hogy a sík architektúra lehetővé teszi a skálázást, rendkívül hasznosnak bizonyul számunkra, ha engedélyezzük az áramlási címkét a ToR-on, és megkapjuk a problémás területek körüli áramlásának képességét. Az RTO és SYN-RTO értékek csökkentésének legjobb módja az eBPF programok használata. A kérdés továbbra is fennáll: biztonságos-e az áramlási címkét használni a kiegyensúlyozáshoz? És van itt egy árnyalat.
Tegyük fel, hogy van egy szolgáltatás a hálózatán, amely az anycastban él. Sajnos nincs időm részletezni, hogy mi az anycast, de ez egy elosztott szolgáltatás, különböző fizikai szerverekkel, amelyek ugyanazon az IP címen érhetők el. És itt van egy lehetséges probléma: az RTO esemény nem csak akkor fordulhat elő, ha a forgalom áthalad a szöveten. Előfordulhat a ToR puffer szintjén is: amikor egy incast esemény történik, akkor akár a gazdagépen is előfordulhat, amikor a gazdagép kiönt valamit. Amikor egy RTO esemény történik, és megváltoztatja a folyamat címkéjét. Ebben az esetben a forgalom egy másik anycast példányra irányulhat. Tételezzük fel, hogy ez egy állapottartó anycast, tartalmaz egy kapcsolati állapotot – lehet L3 Balancer vagy más szolgáltatás. Ekkor egy probléma adódik, mert az RTO után a TCP kapcsolat érkezik a szerverhez, amely semmit sem tud erről a TCP kapcsolatról. És ha nincs állapotmegosztásunk az anycast szerverek között, akkor az ilyen forgalom megszűnik, és a TCP kapcsolat megszakad.
Mit lehet itt csinálni? Az ellenőrzött környezetben, ahol engedélyezi a folyamcímke kiegyensúlyozását, rögzítenie kell a folyamatcímke értékét az anycast szerverek elérésekor. Ezt a legegyszerűbb ugyanazon az eBPF programon keresztül megtenni. De itt van egy nagyon fontos pont – mit tegyünk, ha nem üzemeltetünk adatközponti hálózatot, de távközlési szolgáltató vagyunk? Ez a te problémád is: a Juniper és az Arista bizonyos verzióitól kezdve alapértelmezés szerint áramlási címkét tartalmaznak a hash függvényeikben - őszintén szólva, számomra tisztázatlan okból. Emiatt megszakadhat a hálózaton áthaladó felhasználók TCP-kapcsolata. Ezért nagyon ajánlom, hogy ellenőrizze a routerek beállításait itt.
Így vagy úgy, úgy tűnik számomra, hogy készen állunk a kísérletekre.
Amikor engedélyeztük az áramlási címkét a ToR-on, előkészítettük az eBPF-ügynököt, amely jelenleg a gazdagépeken él, úgy döntöttünk, hogy nem várjuk meg a következő nagy kudarcot, hanem irányított robbanásokat hajtunk végre. Elvettük a ToR-t, amelynek négy felfelé irányuló kapcsolata van, és az egyiken beállítottuk a dropokat. Szabályt húztak, és azt mondták - most elveszíti az összes csomagot. Ahogy a bal oldalon látható, csomagonkénti figyelésünk van, ami 75%-ra esett vissza, vagyis a csomagok 25%-a elvész. A jobb oldalon grafikonok láthatók a jelen ToR mögött élő szolgáltatásokról. Lényegében ezek a rack-en belüli szerverek interfészeinek forgalmi grafikonjai. Mint látható, még lejjebb süllyedtek. Miért estek lejjebb - nem 25%-kal, hanem bizonyos esetekben 3-4-szeresére? Ha a TCP-kapcsolat nem szerencsés, továbbra is megpróbálja elérni a megszakadt csomóponton. Ezt súlyosbítja a szolgáltatás tipikus viselkedése a DC-n belül - egy felhasználói kérés esetén N kérés generálódik a belső szolgáltatásokhoz, és a válasz akkor érkezik a felhasználóhoz, amikor minden adatforrás válaszol, vagy amikor az alkalmazásnál időtúllépés lép fel. szinten, amelyet még konfigurálni kell. Vagyis minden nagyon-nagyon rossz.
Most ugyanaz a kísérlet, de a folyamatcímke érték engedélyezve van. Amint láthatja, a bal oldalon a kötegfigyelésünk ugyanilyen 25%-kal esett vissza. Ez teljesen helyes, mert nem tud semmit az újraküldésről, csomagokat küld, és egyszerűen megszámolja a kézbesített és elveszett csomagok arányát.
A jobb oldalon pedig a szerviz menetrend. Itt nem találja meg a problémás ízület hatását. Ugyanezen ezredmásodperc alatt a forgalom a problémás területről a három fennmaradó, a probléma által nem érintett felfelé irányuló kapcsolatra áramlott. Van egy hálózatunk, amely önmagát gyógyítja.
Ez az utolsó diám, ideje összefoglalni. Remélem, tudja, hogyan kell öngyógyító adatközpont-hálózatot felépíteni. Nem kell átmennie a Linux kernel archívumán, és ott speciális javításokat keresnie; tudja, hogy a Flow címke ebben az esetben megoldja a problémát, de óvatosan kell megközelítenie ezt a mechanizmust. És még egyszer hangsúlyozom, hogy ha Ön távközlési szolgáltató, ne használja a flow label-t hash függvényként, különben megzavarja a felhasználók munkameneteit.
A hálózati mérnököknek koncepcionális váltáson kell keresztülmenniük: a hálózat nem a feladatsorral kezdődik, nem a hálózati eszközzel, hanem a gazdagéppel. Meglehetősen szembetűnő példa, hogy az eBPF-et az RTO megváltoztatására és az anycast szolgáltatásokhoz való áramlási címke rögzítésére egyaránt használjuk.
Az áramlási címkemechanika minden bizonnyal alkalmas más alkalmazásokra is az ellenőrzött adminisztratív szegmensen belül. Ez lehet adatközpontok közötti forgalom, vagy speciális módon használhatja az ilyen mechanikát a kimenő forgalom kezelésére. De erről, remélem, legközelebb mesélek. Köszönöm szépen a figyelmet.
Forrás: will.com