AMD vs virtualizáció

Úgy kb 8 éve lehetett, mikor utoljára láttam AMD Opteron processzorral szerelt gépet, főleg VMware alatt. Egy időben pedig standard volt, hogy amennyiben VMware alá kell valami, az csak Opteron-os szerver lehet.

Ez alább egy picit régebbi modell, még 2009 környékéről. Akkoriban azért egy ilyen gép, nem volt gyengének nevezhető. Négy darab processzor, mindegyikben két fizikai mag. Abban az időben a 80 GB memória sem volt hétköznapi.

Aztán mikor az AMD szekere picit lassult, akkor szépen lassan kikoptak ezek a gépek és mindenhová Intel processzoros gép került. Lényeg, hogy ezen a piacon nem volt terméke az AMD-nek, egészen 2017-ig, amikor előálltak az Epyc processzorokkal.

Fontos megjegyezni, hogy mind a régi Opteronok, mind a mai Epyc processzorok, egy alapvetően eltérő alapelv mentén készültek, fakadjon ez gyártástechnológiából vagy egyéb okok miatt. Míg az Intel Xeon processzorok egy fizikai chip-ből állnak, addig az AMD – de még például sok más egyéb gyártó, az IBM Power CPU-i is – több chip-ből épülnek fel, amit egy lapon “szerelnek” össze. Ezt nevezik MCM-nek – Multi Chip Module.

Így tehát minden Epyc processzor 4 – 4 Zeppelin – részből áll, amelyben minden esetben 8 fizikai mag lapul – 2 CCX-, pusztán attól függ hogy végül 32 vagy 24 magos lesz a végeredmény, hogy szimmetrikusan mennyi magot tilt le a gyártó – tegye azt azért mert az a mag sérült/nem tökéletes vagy éppen azért, mert így olcsóbb mint több gyártósort és design-t használni a különböző magszámú kiépítések esetén.

Ezek a 8 magos “részek”, jobban lebontva két darab 4 magos Zen magból – CPU complex – tevődnek össze.

32 mag, 1 foglalatban….a legnagyobb Intel Xeon Platinum 8180 is csak 28 maggal rendelkezik. Ha lenne értelme magszám alapon összehasonlítani a processzorokat, akkor egyértelműen AMD, viszont aki így tesz az menjen inkább havat lapátolni.

Az Intel a Skylake-SP-vel bevezette az úgynevezett uncore-t, ami az addig megszokott kettős gyűrűt váltotta le.

Ha ezt összehasonlítjuk az AMD megoldásával, látszik hogy azért az Intel eléggé tud. Jelenleg 28 magot képes összekapcsolni egy mesh-be. A cache felépítésének részletezése, helyett annyi könnyen megérthető, hogy abban az esetben, mikor egy mag olyan adaton szeretne dolgozni, ami nincs a saját cache-ében, hanem egy másik maghoz tartózóban van, akkor függőlegesen mellette van akkor az 1 ugrásra van – ezáltal 1 ciklusra. Ha két szinttel van feljebb/lentebb, akkor 2 ugrásra/2 ciklusra, ha vízszintesen van 2 ugrásra, akkor az már 3 ciklust jelent. A legrosszabb esetben ha a bal felső mag szeretné elérné a jobb alsó mag cache adatát, akkor az maximum 13 ciklusba kerül.

Az AMD-nél egészen jól néz ki a dolog egészen addik amíg a közös L3-ba dolgozó magok, nem akarnak olyan adatokkal dolgozni, amik más cache-ben vannak. Akkor már távolra kell nyúlni, tehát máris túlnyúlunk a CCX-eken, amikből kettő teszi ki a Zeppelin chip-et, amiből négy darab alkotja az EPYC processzorokat. Itt tehát késleltetésben megfizeti az árát az AMD az architektúrának.

Ha a processzorok integer és lebegőpontos teljesítményét hasonlítjuk össze, akkor már pontosabb képet kaphatunk viszont itt almát, az almával kell hasonlítani. Itt esik hibába szerintem a legtöbb oldal, miképpen a legdurvább Epyc-et hasonlítja a legdurvább Xeon-nal. Véleményem szerint árban kell ezeket összehasonlítani, méginkább megnézni, hogy egy kiválasztott Xeon-hoz mérten melyik az az Epyc, ami hozza a teljesítményt. Az ára egész biztosan alacsonyabb lesz, mint a Xeon-é.

Az Intel Xeon 8180 megalázza a 7601-et INT teljesítményben, FP-ben egyenlít az AMD. Árban majdnem 250%-al több viszont az Intel termékének. Ha az 7061-es EPYC árához keresünk Intel processzort, akkor a 8160 áll hozzá a legközelebb. Annak teljesítményét picit túlszárnyalja INT-ben, FP-ben pedig nagyon magasan megveri. (A 8160 esetében nem teláltam a SPECint.org-on egy processzoros kiépítéssel elvégzett tesztet, ezért ott kicsit balga módon osztottam kettővel az eredményeket).

Hová nem tennék EPYC kiszolgálót?

Olyan esetekben, mikor a workload valami hatalmas tranzakcíós adatbázis vagy valami olyan alkalmazás, amely sok maggal dolgozik egyszerre azonos adatokon. Ekkor a sok cache szinkronizáció miatt az AMD megoldása nem lesz optimális.

Hová illeszkedhet?

  • virtualizáció: az esetek 90%-ra, ahol nem 1 VM/ hoszt konszolidációs aránnyal futtat valak virtuális gépet.
  • A rengeteg PCI-E csatorna miatt például SDS megoldásba
  • GPU-kkal teli szerverekbe
  • Ha VPS szolgáltató lennék, erre építenék
  • Olyan esetben, ahol eddig csak azért volt 2 utas a szerver mert kellett a memória mennyisége, vagy a bővítőkártyák száma miatt. EPYC-el megoldható egy processzorral, ezáltal sok esetben – pl VMware – a licenszköltség is alacsonyabb lehet
  • Minden olyan alkalmazás alá ami foglalat alapon licenszelődik

Ez utóbbi egyébként érdekes, régen a Microsoft Windows Server sem core alapon licenszelődött, már igen. A VMware vSphere ESXi még socket alapon licenszelődik, de ki tudja meddig. A Veeam B&R is ilyen, de ki tudja. A konszolidációs arány növekedése az ilyen magas magszámú processzorok használata esetén akár két generáción belül a felére vághatja a szükséges foglalatok számát, ezáltal eljön az a pillanat, hogy mindenki átáll vagy a mag alapú, vagy a kapacitás alapú licenszelésre – ha nem az instance alapúra. Ki lehet számolni, hogy megéri-e erősebb processzor venni, ezáltal kevesebb, de drágább szervert használni, illetve így alacsonyabb licenszköltséggel működni. Az érem másik oldala – bár nem hiszem hogy ez probléma – hogy a nagyobb szerverek, nagyobb failure domain-t jelentenek. Ha egy ilyen gép áll meg, rajta 150 VM-el, akkor nagyobb a probléma, mintha egy másik, 45 VM-el.

Élőben egy kétprocesszoros EPYC szerver teljesítményére lennék kíváncsi, azzal a 64 fizikai maggal.