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

• #5753 Jürgenmüller kezdő Rick3D #5752

  Új Válasz 2022-09-18 08:59:03 #5753

  Ú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

  

  Jürgenmüller

  kezdő

  válasz Rick3D #5752 üzenetére

  Nagy teljesítményű grafika esetében a virtualizált környezet nem lesz megfelelő SOHO használatra, az más tészta, hogy egy nagy teljesítményű ESXi farmon, amikor Direch Path-al beletolják az ESXi alá a profi VGA-kat, de ott nem játszanak ezekkel.
  Ha pedig egy Hyper-Threadinget akarsz használni virtualizáció alatt, azt adott feladatokra lehet használni, de gondolj bele, ha mindet kiosztod a VM-nek, akkor mi marad a TypeII virtualizációs szoftvert futtató operációs rendszernek?
  A pCore és az lCore-okat használva ha meghajtod a processzormagot, akkor nagyon hamar kotra produktív lesz, mert ameddig a pCore-t kettő felé osztod, akkor az egyik lCore 95%-on fog menni, ameddig a másik lCore 5%-on, na ami csak 5%-on megy, az folyamatosan vissza fogja tartani a programodat.
  Más a helyzet pl Active Directory, vagy DNS szervereknél, ahol ha az Overcommitment 3 *-osa a pCore-ok számának belefér, mert ezek a szerverek ritkábban tekerik ki a processzormagokat 90%-ig, itt mikor frissítik az operációs rendszert, akkor fogyasztják a legtöbb processzormagot.
  Ezért nem szeretik a HT-t az adatbázis, vagy konverter szerverek sem, mert kontra produktív tud lenni. Persze, ha nagyon sok magom van, és kevesebb vCpu van beállítva a SUM VM esetében mint amennyi pCore van a 2 fizikai NUMA nodeban található össz pCore esetében akkor nincs probléma, de ez nem SOHO környezetben szokott lenni.
  Itt a pCpu számít inkább, és annak max a 2/3-t érdemes kihasználni.

• #5719 Jürgenmüller kezdő tasiadam #5697

  Új Válasz 2022-08-20 20:45:47 #5719

  Ú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

  

  Jürgenmüller

  kezdő

  válasz tasiadam #5697 üzenetére

  A VMware Tools nem erre való, és nem is erre tervezték. Erre megvannak a céleszközök. Vagy le tudod fejlesztetni, de ezért senki nem fog felelősséget vállalni, és nem is elvárható a VMware oldalról. Mi történik, ha a régi lesz a VMware tools, mert azt sok esetben egy ESXi szerver frissítés után utána kell húzni, valamint mi van akkor, ha a VMware tools megáll a VM-en? Ilyenbe nem szabad belemenni, bármennyire is low budget megoldásra van szükség.

  Ugyan nem Hyper-V fórum, de konyítok hozzá, nálunk volt egy 110 node-os Hyper-V farm ezt sikerült lebontanom 50-esre, azóta az ESXi farmunk 400 host felett van.
  A Hyper-V-t nem fejlesztik már, azaz kiadják az újabb verziókat, de nem sokat hoz a 2016-hoz képest.
  Sokkal több munkát igényel a rendszergazdától, mint a VMware. A Vmware egy fabalta a Hyper-V-hez képest, nem tudásban, mert abban a Hyper-V nagyon el van maradva. Sehol nincs ahhoz képest, ezt én biztosan meggondolnám, hogy szükség van-e arra, hogy egy Live Migration (Ez a vMotion megfelelője) fejreállítja Hyper-V node-ot ha nem állítod be jól, ez a VMware-nél egy install minden be van állítva. És a Hyper-V esetében ez kb 30 beállítást jelent csak addig, hogy működjön normálisan.

  #5704 [Newman]

  Ilyen sztorijaim nekem is vannak, tegyünk snapshotot az adatbázis, log szerverre, mert az a mentés. De amúgy tartsátok meg 2 hónapig, mert hát ki tudja.
  Csináljunk file szerverre vSphere Replicationnel, mert az majd nagyon jó visszaállási pont lesz. A file szerver 12 TB volt.
  Szintén Fault Tolerance, de kellene 12 vCpu és a gép 96 GB memóriával üzemel, ebből lenne 4 nem gond ugye? A hálozat 6 Gbit. A Clusterba 4 fizikai szerverrel, 2 Socket 6 Core.
  Állítsunk be VADP mentést az adatbázis szerverekre, mert az jó.
  stb.

  Hiába vannak ötletek, meg vannak olyan dolgok, amik nem oda valók, ahova elképzelik.
  p { line-height: 115%; margin-bottom: 0.25cm; background: transparent }a:link { color: #000080; so-language: zxx; text-decoration: underline }

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