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

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

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

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