Ú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]

• #9 nyaralasptt csendes tag bambano #8

  Új Válasz 2007-08-01 11:42:13 #9

  Ú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

  

  nyaralasptt

  csendes tag

  válasz bambano #8 üzenetére

  Az uml-lel megoldhato, hogy csak a specifikus resz memoriastack-jet lemendsd es egy masik gepen /akar masik hw kornyezet pl.: mainframe -> x-86 vagy egy gep -> tobb server stb./ tovabb futtasd ugy, hogy az alkalmazas ebbol nem vesz eszre semmit?
  
  Amikor olvastam a cikket nekem is az ugrott be, hogy sebessegben valoszinuleg nem sokat szamit /mondjuk lassabb valoszinuleg nem lesz, de tipikus javas kornyezetben nem a javas server szokott a szuk keresztmetszet lenni, hanem az adatbazis(ok)/. Az hw eroforrasok kihasznaltsaga viszont kellemesen alakulhat a dinamikus eroforrashozzarendeles miatt, aminek a tamogatasat ez a technika segitheti.
  
  Java vilagban az optimalizaciot tipikusan a jol atlathato strukturak es a JIT jellemzi, szoval en nem latom gondnak, hogy kidobjak a francba az alacsony szintu, es tulajdonkeppen felesleges retegeket az azokban implementalt optimalizaciokkal egyutt. A targyalt felepitest is azert latom frankonak, mert sikerul megszabadulni egy csomo olyan dologtol ,ami nem tartozik kozvetlenul /vagy sehogy/ a lenyeges funkcionalitashoz.

• #7 Eperfa tag bambano #5

  Új Válasz 2007-07-31 22:04:10 #7

  Ú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 #5 üzenetére

  bár a tendencia valóban ez, maradjunk inkább annyiban h ez egy átgodolatlan fikázás volt [noflame]
  
  A hardver- és szoftverkörnyezetek összekapcsolását végző hypervisorréteg kialakításához a BEA a VMware ESX szerverét használja fel, mely közvetlenül, operációs rendszer nélkül fut a szervergépen. Az egyes virtuális környezetek erre a rétegre épülnek, s fontos elemük a Java virtuális gép.[..], a LiquidVM-t. Ez a Java virtuális gép operációs rendszer nélkül képes a hypervisoron futni, így a Java alkalmazások is közvetlenül a virtualizációs rétegen működnek. A BEA architektúra előnye, hogy teljesen elhagyja az operációs rendszert, ami a teljesítmény növekedését eredményezi.
  
  az elnevezéseken lehet vitatkozni, de alapvetően megvan minden ami kell. egy vmware esx server, amit ők hypervisor-rétegnek hívnak [sztem ezt nem egybe kell írni], és ez biztosítja azokat az oprendszer-funkciókat amit hiányolsz. ezen csücsül egy java vm (virtualizációra felkészítve) stb
  most hogy teljesen elhagyja az oprendszert stb az nyilván elégég marketingszagú és úgy kell érteni hogy a virtualizáció nem a hagyományos os-ek fölött történik, de nyilván aki akarja érti. ez maga az esx.
  
  [Szerkesztve]

• #6 nyaralasptt csendes tag bambano #1

  Új Válasz 2007-07-31 20:48:15 #6

  Ú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

  

  nyaralasptt

  csendes tag

  válasz bambano #1 üzenetére

  most lehet faszsagot irok /meg talan ildomosabb lenne konkretan utannanezni, mielott osztom az eszt/, de szerintem a VMware ESX illetve maga a futtatokornyezet biztositja azokat az alap oprendszer funkciokat, amik szuksegesek a futashoz. Ezekbol egyebkent valoszinuleg tenyleg nincs tul sok, legalabbis ha valaki szokott java/jvm/ forrast olvasgatni, akkor feltunhet, hogy gyakran igen alacsony szintu funkciok is javaban vannak implementalva /ami a JIT miatt tipikusan nem jelent tul nagy teljesitmenyveszteseget/.

• #4 shev7 veterán bambano #3

  Új Válasz 2007-07-31 19:02:36 #4

  Ú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

  

  shev7

  veterán

  válasz bambano #3 üzenetére

  a virtualis gep meg javan

• #2 shev7 veterán bambano #1

  Új Válasz 2007-07-31 16:56:19 #2

  Ú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

  

  shev7

  veterán

  válasz bambano #1 üzenetére

  javan

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