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

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

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