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

• #10 Eperfa tag bambano #8

  Új Válasz 2007-08-01 15:22:54 #10

  Ú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

  

  Eperfa

  tag

  válasz bambano #8 üzenetére

  (azt nem értem mondjuk hogy miért bassza fel mindenki az agyát ha a sajátjától eltérő véleményt hall de nem baj)
  
  mielőtt idézgetek, leszögezem a következő, számomra vitathatatlan igazságokat:
  a.) sok példányban futtatni egy OSt csak azért h sok java vmed legyen felesleges és erőforráspazarló
  b.) nem a bea kezdte két hét alatt újraírni a világot, nem véletlen használják az esxet
  c.) a vmware esx az egyik igen elterjedt, nagyvállalati környezetben is sokat használt, jó minőségű virtualizációs megoldás. ebből két dolog következik: az egyik, hogy ők sem két hete kezdtek gondolkozni a saját kerneljük felépítésén, a másik pedig hogy jobb támogatást nyújt a virtualizációhoz mint a 'hagyományos' oprendszerek (ez egy meglepő állítás annak fényében h erre lett kitalálva..)
  d.) ez természetesen egy pr cikk marad, aminek az a lényege h az üzleti vezető is megértse meg neked és nekem is legyen fogalmam arról h mi is ez. nem arról vitatkozok h ez tökéletes lenne, főlegnem szakmai szempotból, csak annyit mondtam h a csuklóból odavágott szarozás (amikor nem is értetted hogy hogy működik) kicsit gyorsvolt sztem.
  
  'ha a virtualizációt hagyományos eszközökkel kívánjuk megoldani, a konszolidáció kevésbé hatékony'': mik azok a hagyományos eszközök? mit tekint ő kevésbé hatékonynak?
  
  a hagyományos eszköz nála feltételezhetően az egy oprendszeren belül futtatok több másiakt, mindegyiken egy vm. ez képest nyilván kevésbé hatékony mint az övék, de ugye ide tartozik a következő idézet is (vagyis hogy tényleg ez-e a legjobb 'hagyományos' megoldás)
  
  ''Ebben az esetben ugyanis a teljes alkalmazásstacket, beleértve az operációs rendszert is, annyi példányban kell futtatnunk, ahány virtuális környezetet szeretnénk kialakítani.'': ez konkrétan nem igaz, mert lehet chrootolva vagy uml-ben is futtatni java vm-eket.
  
  mélyen technikailag nem tudok vitatkozni a dologgal, de (javíts ki ha tévedek) feltételezem h a fentiek közül egyik sem nyújt pl olyan minőségű szeparációt, erőforráskontrollt, userkontrollt, mozgathatóságot és redundanciát mint amilyet egy esx alapú megoldással el lehet érni (a szavak szépek de tényleg gondold végig h pl egy chrootos megoldásnál hogy is néz ki pl az erőforráskontroll. a nice level azért nem egyenlő azzal amit egy esxben be lehet állítani.. meg ugye tényleg az hogy akármikor átteszem másik gépre, megszakítás nélkül fut stb) (ezen felül pedig kicsit házi hekkelés szagot érzek ami nagy cégeknél nem dívik, márpedig a célközönség nem én vagyok, de mondom, javíts ha nem így van. arról nem is beszélve h ha már amúgyis van esx alapú cucca a cégnek akkor valszeg még könnyebb az átállás)
  
  figyelembe véve még azt a későbbi állítást, miszerint az oprendszerből keveset használ a jvm, ezért nem lehet azt mondani, hogy hajde nagyon sokat ront egy oprendszer a jvm teljesítményén.
  
  sztem ez egy alapvető félreértelmezés. a jvm keveset használ az oprendszerből, azaz ottvan egy egész nagy oprendszer ami a bedugott usbs eszközök kezelésétől a hangkártyadriveren keresztül az automatikus updateig minden szart futtat, pedig mi csak egy szaros java vmet használunk rajta, amihez semmi szükség a fentiekre. éppen ezért ebből a 'hagyományos' oprendszerből futtatni 20 példányt a 20 vmhez sztem valóban pazarló (persze újra előjön a fenti kérdés h ez tényleg szükséges-e, nicns-e jobb megoldás)
  
  ''operációs rendszer szolgáltatásai közül csak nagyon keveset használ fel, ezért a hagyományos megoldás igen erőforrás-pazarló.'': ha keveset használ, akkor legfeljebb pár százK memóriát pazarol, az operációs rendszer (pontosítsunk: a rendszermag) azon részei nem foglalnak semmi erőforrást, amit nem használ a jvm. Mivel kevés ilyet használ, ezért kevés pazarlás történik (nem nulla a pazarlás, ezt elismerem).
  
  te is tudod h a dolog nem ilyen egyszerű, az a pár száz K nem pár száz K (főleg ha nem egy kiherélt linuxkernelről beszélünk hanem egy winről, persze jogosan merül fel a kérdés h annak van-e értelme, de lehet h vhol van), a prociterhelés nem 0, alá kell még egy teljes hwemuláció is, továbbá az összes oprendszert karban kell tartani, updateelni kell stb.
  
  Az ok, hogy csináltak spéci vm-et, ami közvetlenül a hypervisoron fut, és itt esetleg kimaradt az oprendszer. Ennek hasznosságán lehetne vitatkozni, hiszen ha kihajítják pl. a linux kernelt (de itt akár windows kernelt is mondhatnék), akkor ezzel kihajítják azt a rengeteg optimalizálást, finomhangolást is, amit a linux és a windows fejlesztők 15-20 év alatt beleöltek a rendszermagokba és megírták ennek egy részét újra. Kétségeim vannak afelől, hogy egy jvm fejlesztő jobb block cache-t ír, mint akár az ms, akár a linuxosok.
  
  pont ez a lényeg, ők nem foglalkoznak a hypervisor réteggel (amit hasonlíani lehet az ms/linux/... rendszerekhez), azt meghagyják a vmware-es srácoknak, akik pedig ebben azért nem rosszak..
  ők csak az esxen futó java vmtől kezdtek fejleszteni (és azt sem a 0ról)
  
  Tehát maradjunk annyiban, hogy indokok nélkül nevezheted fikázásnak a témát, de vannak indokok is, amik a leadott pr anyag szintjét bizonyítják. [...] Amiben nem vagyok teljesen biztos, de ez utóbbi mondatod veheted flémnek.
  
  az ilyenek nem tudom minek kellenek de biztos.
  
  sztem oda ahova ezt tervezték oda ötletes és jó a cucc. magánvélemény.
  
  (kíváncsi vagyok h közelednek-e majd az álláspontok de sajnos megyek el este uh válaszolni nem fogok tudni egy jó hétig)
  
  
  
  [Szerkesztve]

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