Új hozzászólás Aktív témák

• #15692 vadger tag suomalainen #15691

  Új Válasz 2020-10-13 17:39:36 #15692

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  vadger

  tag

  válasz suomalainen #15691 üzenetére

  Nem feltétlenül azt írtam, hogy nem cloud kompatibilis (bár olyan is lehet, ami speciális hardveren fut csak pl). Hanem inkább úgy értettem, hogy néha architektuális változtatások kellenének egy alkalmazásnál, hogy igazán cloud alkalmazás legyen. És ezt sok cég nem lépi meg, sokszor nem is lehetséges egyáltalán. Cloud migrációs stratégiák, nálunk leginkább a lift and shift van.

  Mi például nagy F5 felhasználók vagyunk, nagyon sok alkalmazásunknál a traffic különböző advanced loadbalancing szabályok alapján kerül továbbításra (iRule-ok, cookie insert, SSL offload, http header változtatások). Mivel az alkalmazás ilyen körülmények között fut az on-prem környezetben is, ezért ez a fejlesztők elvárása cloud-ban is, mert nem fogják átírni az appot. És ezeket a dolgokat a cloud native loadbalancerek nem tudják.

  Aztán ott vannak a tűzfalak. Cloud native tűzfalak sokszor csak layer 4, vagy ha layer 7 is, akkor nem olyan szintű, mint amit nálunk a security elvár, inspection, logolás, stb.

  Így már ott tartunk, hogy egy sima web stack elérése így nézhet ki (leegyszerűsítve):
  cloud LB --> F5 LB --> cloud LB --> tűzfal --> cloud LB --> webszerver
  És mivel redundásnak kell lennie, minden nem natív cuccból legalább egy pár kell, mert a cloud provider bármikor lelőheti az egyiket kérdezés nélkül.

  Ilyenkor már annyi licenszes cuccot futtatsz, sokszor ugyanúgy túlméretezve, ergo drágán, kihasználatlanul, hogy árban már ki tudja, megéri-e... Egy igazán cloud alkalmazásnál, natív cloud szolgáltatásokkal jobban működne az, amiért a cloud igazán vonzó lehet, a horizontális és vertikális rugalmasság.

  [ Szerkesztve ]

  CCNA RS, Security és egyéb hálózati témák oktatása: https://ccnaoktatasmagyarul.hu

• #15694 soma314 tag suomalainen #15691

  Új Válasz 2020-10-13 20:53:04 #15694

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  soma314

  tag

  válasz suomalainen #15691 üzenetére

  Mert mondjuk alacsony latency-t követel meg, vagy multicast-et. Ezek nincsenek az interneten.
  De elég csak abba belegondolni, hogy a TCP hogy működik: a küldő nyugtázást vár a fogadótól. Ha a küldő és a fogadó két külön kontinensen van (ami felhő alapon sokszor megtörténik) akkor az nem teszi hatékonnyá a TCP-t. (Erre is vannak "megoldások" lásd Riverbed, de nem az igazi.)

  Miért van hardveres loadbalancer? Mert mondjuk a hypervisorok között is elosztja a terhelést vagy csak azért, mert sokkal hatékonyabb, mint a szoftveres (ASICS vs software általános hardveren).

  Cloude vs Enterpsie network.
  Igen talán a SOHO-ban lesznek felhő alapú hálózatmenedzsment megoldások (Meraki és társai), de nagy vállalalatoknák nem valószínű.
  Az Enterpsire pedig nem SOHO.
  Hogy mit gondolhat erről a Cisco: nemrég még volt CCNA Cloud, mára csak egy általános CCNA van. Régen R&S-nek hívták most Enterprise Structured Network-nek a szakágat. Talán ezzel is a nagy vállalati mivoltára akarhattak utalni.

  No meg attól, hogy a DC-k jó része, az alkalmazások kiköltöznek a felhőbe még nem lesz kisebb igény a vállalati hálózatokkal szemben. Sőt a jelenlegi trendek szerint az Access oldali biztonság lesz a kritikus a jövőben.

  Millió helyzet van, amikor nem érdemes / szabad felhőbe költözni. Persze ez nem általános. Most az a trend, hogy mindent outsource-oljanak a felhőbe.
  Persze, de volt idő, amikor a csapból is az folyt, hogy az OS/2 lesz a jövő oprendszere és "csak" egy IBM állt mögötte. Azt mégse így lett!

• #15696 soma314 tag suomalainen #15695

  Új Válasz 2020-10-14 06:16:52 #15696

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  soma314

  tag

  válasz suomalainen #15695 üzenetére

  A DMVPN-t nem értem hogy jön ide a latency-hez?

  Nem azt jelenti. Ez nyilván csak elméleti okoskodás, mert nem tudjuk mit akar a Cisco, de ezek a dolgok (CCNA szakirányok megszűnése, CCNA általános "felületesedése", R&S Enterprise-á válása...) nálam azt sugallja, hogy a Cisco arra számít, hogy a SOHO-ban felhő alapon menedzselt megoldások terjednek majd el, ezért nem lesz igazán szüksig alacsonyabb szintű tudással rendelkező CCNA specialistákra (lásd CCNA Cloud, Security, R&S....)
  A voice-ot nem rángatnám ide, mert az már jóval korábban megszűnt és a collaboration vette át. Egyébként nálam is életszerűtlen a "klasszikus" VoIP 2020-ban egy zöld mezős irodai megoldásnál. Ma már nem kérdés szerintem, hogy a mobiltelefon a hanghívás fő eszköze. (A személyt akarod hívni, nem az asztalát.)

  Nem, nem mindig volt kritikus az access oldali biztonság. Nézd meg egy átlagos vállalati rendszerben még nagyvállalati szinten sem áltanás a vezetékes eszközök dot1x-es authentikációja, a wifi-t még ma is sok helyen egyszerű jelszóval védik. És "régen" még elég általános model volt, hogy a végberendezések nem rendelkeztek internet eléréssel, hanem proxy-ztak.
  Na próbálj meg proxy-zva felhőszolgáltatásokat igénybe venni. Nem lesz könnyű.

  Nem a Cisco soha nem nevezte az ACI-t cloud-nek. Miért is nevezte volna? SDN-nek nevezte/nevezi.
  Szerintem a fogalmak terén nem egy malomban örlünk: a felhő lehet konkurenciája a DC-nek, de nem lehet a strukturált enterprise network-nek. Függetlenül attól, hogy a szerverek egy helyi DC-ben vagy az interneten egy távoli DC-ben működnek a végberendezéstől az internetig kell hálózat. Az interneten keesztül kellenek VPN-ek. Hogy esetleg egyszerűsödik az enterprise hálózat azáltal, hogy a helyszínek egymás közti kommunikációját hanyagoljuk, és csak az "internetben lévő felhővel" kommunikálnak. Ebben még lehetne valami, de ez megint visszalépés: volt már ilyen hub and spoke topológia.
  Képzeld csak el van egy videokonferencia, amit egy vállalat 3 városában lévő telephelyei között rendeznek. Egy on premise megoldásban ez simán működhet bidirekcionális multicast-el, aza a 3 helyszínről a kimenő hang/kép információ eljut a másik kettőhöz. A latency a lehető legkisebb lesz, mert a csomag nem jár meg felesleges köröket. Ugyanez egy felhő megoldásnál minden helyszínről eljut minden egy központi szerverhez ami valahol az interneten üzemel, majd onnan vissza mind a három helyszínre. A kettő műszaki megoldás közül " modernebbnek" mondott felhő rosszabb felhasználói élményt, több biztonsági rést és rosszabb hatékonyságot okoz.

  Szóval én még emlékszem az OS/2-es időkre. Szerintem nem volt nagyobb vágyálom, mint ma a felhő. Akkor az IBM még meghatározóbb cég volt, mint a Microsoft.
  Továbbra se mondom azt, hogy nem lesz felhő megoldás, mert sok mindenre alkalmas, főleg ha a privát felhőt is idevesszük.
  Viszont van egy csomó helyzet amit nem tudsz felhő megoldással kezelni:
  - kezdem a legextrémebben: mit teszel, ha mindened a felhőben van. A felhő egy USA cég felügyelete alat és Magyarország hadat üzem az USA-nak? Ugye extrém?! De kétszer már megtörtént a történelemben.
  - hogyan oldod meg a allback-et, ha egyszerűen pénzügyi okból összerúgod a port a felhőszolgáltatóddal? Nem lesz se eszközöd, se személyzeted, know how-d, se backup-od a saját adataidról, teljesen ki vagy szolgáltatva a felhő szolgáltatónak. Hogy ilyen nincs, mert a felhőszolgáltatók jók? Lásd Fortnite Apple store esetet.
  - mit csinálsz, ha a felhőszolgáltató leáll, feltörik...Persze kártérítést követelsz, vagy akár perelsz. Ja jó eséllyel perelsz egy sok milliárd dolláros céget, miközben a saját cégednek legjob esetben nincs bevétele, és nem működik az IT rendszere, nincsenek bizonyítékul szolgáló adataid mert a felhőben vannak. Rosszabb esetben, meg már te fizetsz kártérítést az ügyfeleidnek. Hogy ilyen nincs, mert a felhőszolgáltatók nagy IT cégek, ahol mindíg minden működik és nem törik fel! Hát erre két szavam van a közelmultból: Zoom és Garmin.
  - talán a legkevésbé extrém, de talán a legfontontosabb: hogyan oldod fel azt, hogy ahol a saját szolgáltatásodat végzed, mondjuk EU és ahol az igénybe vett felhőszolgáltatást felügyelik, mondjuk USA különböző jogszabályi feltételeket szab az adatkezeléssel kapcsolatosan? Vállalod a kockázatát? Auditálod a felhő szolgáltatót és folyamatosan felügyeled?
  - hogy oldod meg a backup kérdését: rábízod a felhő szolgáltatóra? És mi van, ha a gebasz olyan, hogy a felhő szolgáltatót teljesen érinti (lásd összerugod vele a port ketegória). Vgay helyben tárolod, amit letöltögettél a felhőről. Ez már egy fokkal jobb, de kb mennyi idő alatt állítasz fel egy működő rendszert a backup-jaidból egy másik felhőszolgáltatón? Ugye kell hozzá hozzáértő személyzet (akiket korábban elküldtél és már a felhőszolgáltatónál dolgoznak) és ha van is ott lesz a tömérdek adat, amit fel kell töltened egy másik felhő szolgáltatóra. Az aztán gyors lesz!

  Igazából a hybrid on premise és felhő DC-kben lenne a jövő, de itt jön be a latency kérdés. Én nem tudok olyan strech clusterről, ami így működne, mert hatalmas sávszélességet és alacsony latency-t igényelnek, ami az interneten nem megy. Vannak amit úgy hírdetnek, de kiderül, hogy csak a winess kerül fel a felhőbe, ami hát nem nagy előny.

• #15698 soma314 tag suomalainen #15697

  Új Válasz 2020-10-15 16:45:41 #15698

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  soma314

  tag

  válasz suomalainen #15697 üzenetére

  Ehhez nincs köze a DMVPN-nek, legfeljebb anyiban, hogy DMVPN-t jellemzően hagyományos internetkapcsolaton építenek ki. De ezt nem kell feltétlenül így csinálni, lehet akár "bérelt vonalon" keresztül is.
  A latency-nek a távolsághoz, meg a "sima" internetkapcsolathoz van köze: a fizikát nehéz megkerülni, a távolságot nem kell magyarázni. A sima internetkapcsolat meg mikor ilyen, mikor olyan, de nincs rá mód, hogy integrated service QoS modelben végponttól végpontig garantált sávszélességet, és latency-t kaphatsz.

  "Building the Cisco Cloud with Application Centric Infrastructure" Hát ebben a mondatban sem nevezi az ACI-t felhőnek, hanem egy eszköznek, amit felhőszolgáltatásokhoz létrehozásához ajánl.

  Voice- collaboration
  Nem krumpli burgonya, sőt! Pont az a lényeg, hogy régen a VoIP technológia a telefonálást hivatott kiváltani és arra épült az egész architektúrája, addigra ma megváltozott az igény vállalati eszközökben. Már nem igen tudok arról, hogy komoly cég tömegével telepítetne IP telefonokat. Szoftfon alkalmazás még csak-csak, de leginkább már mindenhol olyan collaboration tool-okat használnak, ahol a hang mellett videó, file megosztás is történik. Mondjuk Webex, ha már Cisco. És igen ebben is van on premise és vannak előnyei és nyomják a felhősödést itt is.

  Nem, nem mindegy, hogy hol van a szerver. Milló oka van miért előnyös az on premise és miért a felhős megoldás, de mindig az adott cég, alkalmazás, piaci helyzet...határozza meg melyik a jobb az adott cégnek.

  Miért lenne corner case szituáció? Mert rámutat a felhős megoldás hiányaira? Az elmúlt hónapokban szerinted mennyi videókonferencia zajlott, zajlik nap mint nap? Egy átlagos konferencia résztvevőidől 10-ből 7-en néhány 100 méter közelségből egy cég különböző irodáiból kapcsolódnak (ha nem home office helyzet van éppen). Ez azt jelenti, hogy feleslegesen küldjül el a packetek nagy részét az internetre és vissza.

  Látom vannak érveid és érted a Világot! Hadat üzenni levéllel szoktak. Lehet ma e-mail-ben menne. Abszurd a példa elismerem, de 2x megtörtént!

  Milyen esetben következhet be pénzügyi vita gazdasági szereplők között? Most komolyan? A sulinet-ről írsz?
  Hallotál az Apple-ről és az Epicgames-ről például?

  Mer' az csak úgy megy, hogy a szolgáltatásodat átviszed egyik kontinensről a másikra! És átküldöd a ki tudja mekkora adatmennyiségedet e-mail csatolmányként?

  Persze, hogy megtörténhet privát DC-vel is, de egy privát DC-t te felügyelsz, te tudod milyen óvintézkedések vannak, hogy ne történjen meg. Ha meg havária van, akkor a privát DC minden embere a te DC-d helyreállításán dolgozik, míg amikor egy felhőszolgáltató döl be, akkor az 1024-dik leszel, akit helyreállítanak.
  Arról nem is beszélve, hogy mennyire nagyobb célpont egy nagy felhőszolgáltató, mint egy külön DC. No meg attól, hogy a "szomszéd cég" DC-jét feltörik, még nem fog a tied veszélybe kerülni. Ezzel szemben a felhőnél bizony vannak helyzetek, amikor igen.

  Sajnos nincs hybrid cloud pont ezt írtam le. Nem tudok olyan technológiáról, amivel streched cluster-t lehet csinálni on premis és cloud között. Ahogy már írtam csak olyan van, ahol a witness-t tudod felhőbe tenni.

• #15709 soma314 tag suomalainen #15708

  Új Válasz 2020-10-16 18:56:35 #15709

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  soma314

  tag

  válasz suomalainen #15708 üzenetére

  "Ez ugyanúgy igaz a cloud elérés esetében is. Becsattanhatsz bérelt vonalon is saját tűzfallal. Igy a latency probléma a cloud esetében meg is oldódott."
  Ez sajnos nem így van. A DMVPN, vagy "bérelt vonal" vagy akármi, ami a te saját telephelyeidet köti össze, azok általában nem olyan nagy földrajzi távolságok, leginkább néhány 100 km. Egy felhőszolgáltatás meg akár lehet egy másik kontinensen.
  Amíg magadnak rendelsz "bérelt vonalat" két vagy több telephely között, addig általában egy szolgáltatón megy keresztül egy-egy vonal. Hány szolgáltatóval kell szerződnöd egy másik kontinensen lévő felhőszolgáltatás elérésére. No meg hogyan máred, hogy betartják-e az SLA-kat? Az rendben, hogy látod, hogy a végeredmény nem fogja kiadni a szerződések együttes tartalmát, de mégis melyik szolgáltatónál reklamálj?
  Arról nem is beszélve, hogy a "csőnek" az egyik vége lesz csak nálad, ha "becsattansz egy bérelsz vonallal a felhőszolgáltatóhoz. Ez popszakma meg olyan, hogy attól, hogy odafele jó a latency, jitter, svászélesség, attól még visszafele simán lehet rossz.
  Technikai kérdés, de csak gondolj bele egy szolgáltató saját hálózatán át tudja vinni CE-től CE-ig mpls-en integrated service QoS-el a packet-jeidet, míg, ha szolgáltatókat váltasz, annyiszor lesz egy-egy PE-CE-PE (provider-edge, customer edge) .
  A másik lényegi dolog, hogy ha a P2P vagy P2MP tunnel, amit te kértél egy szolgáltatótól az a te DC-den az általad ismert sávszélességgel csatlakozik az internetre és te állítod be ki, mely tunnel-ek tudják azokat használni és milyen esetleges QoS policy-val kit milyen mértékben korlátozol. Ezzel szemben egy felhőszolgáltató internetkapcsolatára nincs ráhatásod. Nyilvánvalóan piszkos anyagi okból oversubscibing van ott is. Egy tranziens terhelés esetén elég jó eséllyel megsínyli valakinek a szolgáltatása.

  "Arra céloztam, hogy én azt állítottam, hogy az ACI régen a cloud irány része volt. Se többet, se kevesebbet."
  Egészen pontosan ezt írtad:
  " Amit a Cisco cloudnak nevezett, az gyakorlatilag az ACI volt (ma a DC irány része)."
  Egyébként szerintem az ACI a DC vonal része volt és annak a része ma is.

  "Ez igy is van, de a gyakorlatban mégis a neten keresztül csattanunk fel egy szerverre."
  Már aki és már amihez. Nem csak SOHO-ból áll a világ. Léteznek komoly üzleti, ipari, katonai hálózatok is.

  "A cloud nem úgy épül fel, hogy van egy ajtaja valahol a világban, bemész rajta meg kijössz. Az Azurenak pl rengeteg DC-je van és simán megoldható, hogy egy szolgáltatást Nyugat-Európába telepíted, de keleten van a redundáns DC-ben a backup."
  
  És hogy megy át? És, ha vavária volt, és teszem azt a semmiből kell felépítened egy harmadik szolgáltatónál, mert az Azure-ban már nem bízol, akkor hogy kapod meg? Küldenek egy fél teherautónyí HDD-t, amit aztán upload-olsz?
  Az egész felhő, de akár a hybrid technológia egyik Achiles sarka, hogy az igazán fontos dolgokhoz neked egy adatbázisra van szükséged minimum két példányban. (Ez nem a backup mielőtt ebbe valaki beleköt!) Ha az egyik kiesik, a másikról hitless menjen minden tovább. A baj ott kezdődik, hogy ehhez nagy sávszélesség és kis latency kell. Meg lehet csinálni mindezt Azurban úgy, hogy van egy ilyan "kettőzött" storage-on Berlinben, meg Hongkong-ban is, de azt nem lehet, hogy Berlin és Hongkong között legyen megosztva a storage kettőzése. Ennek az lesz a hatása, hogy amíg te azt hiszed, hogy ugyanaz van Berlinben és Hongkongban, addig a két helyszín időről időre szinkronizálja egymást. Tehát a két adatbázis a két helyszínen soha nem lesz azonos!
  Ehhez jön a backup kérdés. Ugya azért van redundancia, hogy a folyamatos üzemet fenntartsuk. A backup másra szolgál. A példánál maradva: Berlinben egy ransomware tönkre teszi az adatbázist és mire észreveszed, addigra Hongkongba is átjutott a szinkronizálással a vírus. Na ilyenkor kellene elővenni azt a backup-ot, ami még garantáltan nem vírusos. Update-elni az IPS-t az őj víris szignatúrájával, majd a semmiről újradeployolni mindent a backup használatával. Ezt egy DC-ban meg lehet tenni. A felhőben is, csak ott kell lennie helyben hozzá a know-how-unak (a te szolgáltatásodhoz!) a backupnak...Na és valószínű ha egy új 0day sérülés érintett, akkor nem te voltál az egyetlen, aki így járt, ezért írtam, hogy te leszel az 1024-dik, akit helyreállítanak.

  "Ez nem úgy működik, hogy "feltörték a cloudot" és szaladgál mindenki, mint pók a falon. Hogy a te dolgaid biztonságban legyenek te felelsz, amire rengeteg megoldás létezik. Attól még a másik customer lehet hanyag és feltörhetik a hálózatát, de ez téged semmiben nem fog érinteni."
  
  Jaj, de most komolyan virtualizáció alapfokon: vannak vasak, amin futnak a hypervisor rendszerek (pl VMware, Proxmox, Hyper-V, Zen...). A Felhő azért éri meg, megy a vasakon, nem csak egy-egy cég VM-jai futnak, hanem folyamatosan több cégé. Sőt általában még azt sem lehet mindig előre tudni, hogy X cégé mindig csak Y, vagy Z gép virtuális gépeivel osztozkodik az adott vason, mert a VM-ek terheléstől függően a hypervisor clusterben szépen mászkálnak. Amikor egy VM-et "feltörnek", akkor azt azért is tehetik, hogy egy másik VM-hez férjenek hozzá a hypervisor-on futó virtuális hálózaton keresztül, de akár azért is, hogy a guest VM-en keresztül érjék el a host-ot, vagyik a hypervisor-t futtató vasat magát.
  Persze van elvileg minden: mikroszegmentáció, meg a vas erőforrásainak korlátozása..., de mégis van minderre mód és történnek "feltörések". Ha az ember már nem kamasz, akkor ezt nem úgy képzeli el, mint a tévében, ahol a hacker egy szobából because he can alapon érzékeny adatokat lopkod, vagy éppen tölt fel, hanem esetleg már látott olyat, amikor bot-ok 10 ezreiről indítanak DDoS támadást, amitől a VM-ek memóriája, a prociterhelése túlnő azon amit a vas bír. Mert igen itt is van oversubscription: attól, hogy eladnak egy serverre 10x64 Giga RAM-nyi VM-et, attól még nem a serverben 640 Giga RAM, csak lehet 320. És akkor még nem beszéltem a containerizációról, ahol ez még akár sokkal rosszabb lehet. Hát hogy az mennyire felhő (IaaS) vagy inkább SaaS azt már nem is tudom pontosan eldönteni így hirtelen.
  És igen te leszel a saját adataidért felelős, de nem lesz backup-od, nem lesz személyzeted hiszen elküldted az felhős outsource-ing miatt.
  Engem nem zavar ez a tendencia, mert munkám lesz legrosszabb esetben felhő szolgáltatóknál, sokkal valószínűbb, hogy a felhő szolgáltatásban már csalódott cégeknél. A tendencia és a "felhő" ismeret nélküli imádata pont azokra a kollégákra "veszélyes" akik most SOHO szektorban dolgoznak. Elnézést, de egy batanított majom is tud egy Meraki-t beüzemelni egy fagyizóba, de egy DC-hez, nagyvállalati környezethez, felhőszolgáltatáshoz már kecskepásztor kell.

• #15715 soma314 tag suomalainen #15713

  Új Válasz 2020-10-17 17:11:12 #15715

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  soma314

  tag

  válasz suomalainen #15713 üzenetére

  "Hány olyan MO, vagy Kelet-Európai cég van, ami elmondhatja magáról hogy multi?"
  magyar: OTP, MOL hogy legismertebbeket mondjam, de mi köze ennek a claud-hoz?
  
  Azt jelenti, hogy ismert technológiákat használsz, amihez van tapasztalat. A felhőtechnológiákhoz még nincs sok.
  
  Elég rendesen kell tesztelni.Sőt tudok olyat is, hogy van egy "legacy" DC éles üzemben és évek óta üzemel mellette tesztben egy újabb. Csak akkor fognak átállni rá, ha megyőződtek róla, hogy kellően megbízható és érdemes migrálni. Mindegyik on premise.
  Az a baj, hogy én meg pont úgy látom, hogy illuzióid vannak inkább csak.
  
  Miattam hiheted azt, hogy az Enterprise vonal halott. Ha valakit erről meg tudsz győzni, annak úgy kell. Nekem nem fáj, kisebb lesz a konkurencia
  
  Senki nem mondta, hogy Catalyst-tal csinálnak DC-t, bár akár. Sok sok olyan rendszert láttam, ahol Nexus switch-ekkel oldottak meg Catalyst-eknek való feladatot, mert az volt olcsóbb, azt ismerte a tervezője jobban...
  Óriási különbség nincs funkciókat tekintve és az ISO-XE és az NX-OS működésében sem. Mindegyikél van MLAG, mindegyikkel meg lehet valósítani L3-as technológiákat. Midegyikből van szekrény méretű és 1 U-s is...
  Ami lényegi különbség, az az FCoE (Fiberchannel over Ethernet) ha egyben akarod megvalósítani a SAN és a LAN switch feladatokat, akkor Nexus kell. Ha a klasszikus modelt követed és külön SAN hálózatot építesz ki, akkor MDS (ha már Cisco) és hagyományos FC, ha meg "trendi agy", akkor hyperkonvergens szervereket használsz és nincs is fizikai SAN hálózatod. Na és persze nem csak a Cisco-ban lehet és kell gondolkodni. Ott van például az Arista, ami DC környezetben eléggé jó piaci részesedésű. Azt udtad, hogy az Arista alapítója tervezte a Catalyst 6500-ast? És tudtad, hogy az EoS (Arista oprendszere) kísértetiesen hasonlít az ios-re? Én például megtaláltam benne ugyanazt a bug-ot No meg, hogy peren kívüli egyezséggel kötöttek békét a Cisco-val?
  Ennyit arról mennyire van távol a Catalst világa a DC-től.
  
  "Egy on-prem DCben elég komoly lehet a kapacitás kihasználatlanság, ami a cloudról nem mondható el." Ez blődség egy DC-ben függetlenül attól, hogy on premise, vagy cloud a kihasználtság attól függ milyen és mennyi task-ot, VM-t, container-t...futtatsz rajta.
  Ha már építettél DC-t, vagy foglalkoztál kicsit mélyebben a kérdéssel, akkor tudod, hogy egy C környezetben a skálázhatóság korlátja, nem a szerverek száma, a memória, a storage kapacitás... hanem leginkább a hely és utána rögtön a hálózati átviteli képessége. A hagyományos hardverek (CPU, RAM...) sebessége, mérete évről évre jelentősen nő ahhoz képest, hogy a hálózatok átviteli képessége hogy alakul, különös tekintettel az internetre.
  Kicserélni az összes szervert egy olyanra, ami 20%-al gyorsabb, vagy több memória bankolható bele simán megérheti, ha azt nézed, hogy mennyibe kerül egy DC kibővítése (építészetileg, tápellátásilag, klimatizálással, kezelt levegővel...). Ez a fizkai bővítés ráadásul a "zöldmezős" beruházásoknál lehet pálya, mert egy város központban lévő DC bővítéséhez nem tudod lebontani a szomszéd háztömböt. A Microsoft például ezért (is) kísérletez tengerbe merített DC-kkel.
  
  Viszont én úgy látom, hogy nálad sem a szakmailag kiveséztük a témát a többi dologra meg annyit tudok mondani, hogy "a kutya ugat a karaván halad".
  
  
  
  
  
  
  
  
  
  

• #15832 SnoopDoggOG csendes újonc suomalainen #15831

  Új Válasz 2020-11-10 09:10:56 #15832

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  SnoopDoggOG

  csendes újonc

  válasz suomalainen #15831 üzenetére

  xdd

• #15893 crok Topikgazda suomalainen #15892

  Új Válasz 2020-12-05 19:50:26 #15893

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  crok

  Topikgazda

  válasz suomalainen #15892 üzenetére

  

  Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..

• #15894 FecoGee Topikgazda suomalainen #15892

  Új Válasz 2020-12-06 01:30:17 #15894

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  FecoGee

  Topikgazda

  válasz suomalainen #15892 üzenetére

  Ááááááá

• #15904 Gyurike tag suomalainen #15903

  Új Válasz 2020-12-11 00:03:04 #15904

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Gyurike

  tag

  válasz suomalainen #15903 üzenetére

  Köszi!
  Esetleg a kezdetekhez van valami videós tréningsorozat IOS-XR témában?

• #15995 FecoGee Topikgazda suomalainen #15994

  Új Válasz 2021-03-23 18:00:35 #15995

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  FecoGee

  Topikgazda

  válasz suomalainen #15994 üzenetére

  A premium ebook-hoz is adnak, legalabbis nekem mindig volt.

Új hozzászólás Aktív témák