Keresés

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

  • Cifu

    nagyúr

    Így, hogy a különféle szoftver licenszeknél már nem a foglalat, hanem a magszám kezd el számítani, már kevésbé van értelme egyutas szerverek felé fordulni. Eddig ugye ebben az volt a poén, hogy prociszám után mentek a licenszek, tehát ugyanannyi volt például a VMWare esetén a licensz ha 16 magvas vagy ha 32 (illetve akár 64) mag volt a prociban. Viszont ha két 16 magos volt, akkor 2 CPU licensz kellett, tehát kétszer annyit fizettél. Ezért lettek az egy utas szerverek egyre népszerűbbek.

    Persze aztán a különféle szoftvercégek rájöttek, hogy ez annyira nem jó dolog a pénztárcájuknak, ezért például a VMWare esetén 32 magonként kell CPU licensz, tehát ha 192 magvas, egy utas rendszered lesz, akkor 6 CPU licenszt kell megvegyél.

    Ilyen feltételek mellett már nem biztos, hogy olyan hű, de jó ötlet az egy utas szerverek felé fordulni, pláne, ha az adott esetben drágább lesz magszámot is figyelembe véve, mint a két utas megoldások.

    Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.

  • Cifu

    nagyúr

    válasz #16939776 #6 üzenetére

    Most hogyan viszonyul mondjuk két külön tokozott 64 magos processzor közötti sávszélesség mondjuk egybetokozott 128 magos processzorhoz képest, ez nem lehet valamilyen módon limitáló tényező és indok arra hogy inkább egy utas rendszert építsenek, ha lehet, és tegyük fel olcsóbb is maga a hardver?

    Itt a kérdés az, hogy mire szeretnéd használni az adott szervert. Azért zömmel az ilyen sokmagvas gépek már virtuális szerverek hostjaként szolgálnak, mondjuk egy 128 magos szerveren fut két-három fájlszerver, DNS szerver, backupszerver, VoIP szerver és teszem azt egy marék virtuális kliensgép (Távoli eléréshez).

    Ilyen esetben picit sem tényező, hogy a két CPU között mennyire fogná vissza a sávszélességet, ez csak ott számít, ahol egy host alól fut sok szálat kihasználó alkalmazás. Ott nyilván még esetleg lehet értelme.

    Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.

  • Cifu

    nagyúr

    válasz McDuglas #9 üzenetére

    Az Amazon tudomásom szerint nem harapott rá nagy Epyc procikra, 32 magvas verzióikat emlegettek, mikor legutóbb e kapcsán szembe jött velem valami. De ők ugye minél inkább a saját ARM N1 magvas, 7nm-es Graviton2 CPU-ra szeretnének támaszkodni.

    Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.

  • Cifu

    nagyúr

    válasz #16939776 #13 üzenetére

    Szerény véleményem szerint igen, mivel csak akkor lenne létjogosultsága egy ilyen szerverproci-szörnynek, ha olcsóbb, mint két fele ekkora.

    Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.

  • Cifu

    nagyúr

    válasz koko52 #15 üzenetére

    Apró probléma, ha például van egy szerver-infrastruktúrád Intel procikkal, VMWare virtuális hostokkal, akkor abba nem tudod beilleszteni az AMD szervert tudomásom szerint. A VMWare előnye az lenne, hogy leállítás nélkül tudnád a VM-eket mozgatni a szerver hostok között például, aminek előnyét aligha kell ecsetelni. Na a fentiek alapján sejthető, hogy mennyire lelkesedne bárki is az AMD szerverre való átállásért egy ilyen környezetben...

    Szóval itt nem arról van szó, hogy mindenki hülye, aki Intelt vesz, hanem arról (is), hogy az, hogy az AMD a szerverpiacon kvázi láthatatlan volt az EPYC előtti időkben...

    Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.

  • Cifu

    nagyúr

    válasz dokanin #20 üzenetére

    Azért az elég durva, hogy lehet hostot cserlélni leállítás nélkül. Nem gondoltam volna, hogy ilyen lehetséges technikailag.

    vMotion-nak hívják a VMWare esetén a Live Migration-t, de létezik Hyper-V alatt is (ahhoz nem értek annyira, no nem mintha VMWare esetén olyan hú, de penge lennék :DDD ).

    És ez AMD alatt miért nem megy?

    AMD alatt is megy, amennyiben AMD alapú szervereken (clusteren) fut a VMWare vSphere. A probléma az, hogy nem tudsz beilleszteni egy AMD alapú clusterbe Intel, mígy Intel alapú clusterbe AMD procis szervert. Tehát Intel alap esetén csak Intel alapon tudod bővíteni, míg AMD alapon csak AMD szerverrel tudsz bővíteni.

    Alaphangon hogy a rendszer gördülékeny legyen, a szerver hostoknak azonos CPU-val, de legalábbis azonos családba tartozó CPU-val kell bírjanak. Így lehet biztosítani, hogy a VM minden szerveren azonos feltételek mellett (azonos utasításkészleten) fusson.

    Az egy ideje elérhető, hogy újabb szervereket tudj beilleszteni, ezt hívják Enhanced vMotion-nak. Ennek az első verziói alapvetően elrejtették az új proci új utasításkészletét a VM-ek elől, azt hazudva, hogy a clusterben lévő legrégebbi CPUID-t vették alapul.

    Magyarul van egy clustered Ivy Bridge-EP alapon, de be szeretnél illeszteni egy Haswell-EP procis szervert. Ilyenkor az EVM azt csinálja, hogy az ESXi felett a VM-ek Ivy Bridge-EP alapú hostot látnak, tehát "lebutítja" az újabb szervert a régiek szintjére. Ez némileg favágó módszer, de ha fejleszteni kell a cluster méretét, még mindig életképesebb ez a megoldás, minthogy régi szerverekből próbálsz vásárolni. Hátránya, hogy az új szerverek is a clusternek megfelelő régebbi CPUID (és utasításkészlet) lesz csak elérhető.

    A következő lépcső a Per-VM alapú EVM, ilyenkor a VM-k létrehozásakor meghatározod, hogy milyen hoston futtatod, és ez korlátozza be utána, ez a VMWare esetén a 6.7-től jelent meg. A fenti példával élve a clusterbe beillesztett Haswell vagy Skylake alapú szerverre továbbra is át lehet migrálni a régebbi szervereken futtatott VM-eket gond nélkül, de az új szerveren létre tudsz hozni már olyan VM-eket, amik kihasználják az új utasításkészleteket. A Per-VM alapú EVM hátránya, hogy a clusteren belül már nem tudod teljesen szabadon migrálni a VM-eket bármelyik szerverről bármelyikre, de viszont azt meg tudod oldani vele, hogy rugalmasan mozgas és hozz létre VM-eket, így például egy ritkábban használt VM-et (mondjuk pl. VoIP, ami relatíve ritkábban szokott cserélve lenni) akár úgy is viheted folyamatosan tovább, hogy alatta közben lecseréled a teljes infrastruktúrát.

    [ Szerkesztve ]

    Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.

  • Cifu

    nagyúr

    válasz #06658560 #21 üzenetére

    Ennek a procinak én mérnökirodákban látom a helyét. CFD, FEA stb. Vagy kisebb stúdiók, akik nem akarnak rohadt nagy farmra beruházni, mert az nem térülne meg De egy ilyen alapú cucc elfér a szekrényben, és egész normálisan tudják terhelni munkával. Vágás, render, crash stb.

    Dunno, oda inkább Threadripper-t tartanék reálisnak az AMD eddigi felállásából. Ráadásul a mérnökök főleg CAD alapú megoldásokkal dolgoznak, ott pedig (amennyire én követem az eseményeket) továbbra is fontosabb az IPC, mint a több mag.

    Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.

  • Cifu

    nagyúr

    válasz dokanin #24 üzenetére

    A vMotion esetén mozgathatod a működő, dolgozó VM-et mondjuk egy 16 magos szerverről egy 24 magosra, de mindkettőnek azonos családba kell tartoznia (pl. Skylake-EP).

    A hostot akár újabbra is cserélheted már, tehát Skylake-SP helyett Cascade Lake-SP procis szerverekre, ehhez kell az EVM.

    És igen, ez azt jelenti, hogy a VM közben fut, dolgozik, végrehajt, semmi vagy minimális lassulással...

    [ Szerkesztve ]

    Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.

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