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

• #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.

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