Adatközpontok 978-963-279-552-2 [PDF]

Zitiervorschau

Írta: Sima Dezső, Schubert Tamás Lektorálta: Schubert Tamás

ADATKÖZPONTOK

INFORMATIKAI SZOLGÁLTATÁSMENEDZSMENT MODUL

PROAKTÍV INFORMATIKAI MODULFEJLESZTÉS 1

COPYRIGHT: 2011-2016, Dr. Sima Dezső, Dr. Schubert Tamás, Óbudai Egyetem, Neumann János Informatikai Kar LEKTORÁLTA: Dr. Schubert Tamás Creative Commons NonCommercial-NoDerivs 3.0 (CC BY-NC-ND 3.0) A szerző nevének feltüntetése mellett nem kereskedelmi céllal szabadon másolható, terjeszthető, megjelentethető és előadható, de nem módosítható. TÁMOGATÁS: Készült a TÁMOP-4.1.2-08/2/A/KMR-2009-0053 számú, “Proaktív informatikai modulfejlesztés (PRIM1): IT Szolgáltatásmenedzsment modul és Többszálas processzorok és programozásuk modul” című pályázat keretében

KÉSZÜLT: a Typotex Kiadó gondozásában FELELŐS VEZETŐ: Votisky Zsuzsa ISBN 978-963-279-552-2

2

KULCSSZAVAK: hálózati tároló, SAN, NAS, iSCSI, Fibre channel, FCoE, Infiniband, SNIA, penge szerverek, virtualizáció, desktop óvirtualizáció, VMware workstation, VMware vSphere, rendelkezésre állás, High Availability, Failover Cluster, DP szerverek, MP szerverek, DP platformok, MP platformok

ÖSSZEFOGLALÓ: Az elmúlt évtized informatikai fejlesztései lehetővé tették, az üzleti igények pedig kikényszerítették, hogy az informatika is egyre inkább szolgáltatássá váljék, és az üzleti alkalmazások megfelelő minőségű, költséghatékony ellátását biztosítsa. Az e feladatot ellátó adatközpontok és elosztott informatikai rendszerek üzemeltetését csak a rendszerelemeket, folyamatokat, a felügyeleti megoldásokat és a kidolgozott módszertanokat jól ismerő szakemberek tudják elvégezni. A tantárgy keretei között a hallgatók megismerkednek az adatközpontok, a párhuzamos és elosztott rendszerek, és ezen belül a DP és MP szerverek, a tároló hálózatok sajátosságaival, felépítésével, az alkalmazási környezet által támasztott teljesítmény-, megbízhatósági, és biztonsági elvárásokkal, valamint adott elvárásoknak eleget tevő szerverrendszerek kialakításának szempontjaival, módjával. Az előadásokon hangsúlyt kapnak a különböző virtualizáló megoldások, amelyek megértését gyakorlati bemutatók is segítik.

3

Tartalomjegyzék

• • • • •

1. 2. 3. 4. 5.

Tárolók Penge szerverek Virtualizáció VMware vSphere Az informatikai infrastruktúra rendelkezésre állását növelő megoldások • 6. Multicore-Manycore processors • 7. Intel’s DP/MP Servers

© Schubert Tamás, ÓE NIK

4

www.tankonyvtar.hu

Adatközpontok Tárolók

Schubert Tamás

© Schubert Tamás, ÓE NIK

5

www.tankonyvtar.hu

Tartalom 1. 2. 3. 4.

Bevezetés Elvárások, követelmények a tárolókkal szemben Szabványosítási szervezetek, egyesületek Tároló architektúrák 4.1 Direct Access Storage (DAS) 4.2 Storage Area Network (SAN) 4.3 Network Access Storage (NAS) 4.4 SAN vs. NAS? 5. Tárolóeszközök 5.1 Just a Bunch of Disks (JBOD) 5.2 Redundant Array of Independent/Inexpensive Disks (RAID) 5.3 Tape Drives és Tape Libraries 5.4 Egyéb Storage (Optikai, félvezető alapú)

© Schubert Tamás, ÓE NIK

6

www.tankonyvtar.hu

Tartalom 6. 7. 8. 9.

Párhuzamos vs. soros átvitel SCSI Architecture Model A SAN-ok használatának előnyei Fibre Channel SAN 9.1 A Fibre Channel rétegstruktúrája 9.2 Fibre Channel szolgáltatásosztályok 9.3 A Fibre Channel működése 9.4 Fibre Channel biztonság 9.5 A Fibre Channel technológia jövője 10. IP tárolóhálózatok (IP Storage Networks) 10.1 Internet SCSI tárolóhálózatok (iSCSI) 10.2 Fibre Channel over IP – FCIP 10.3 Internet Fibre Channel Protocol – iFCP 10.4 FCIP, iFCP vagy iSCSI?

© Schubert Tamás, ÓE NIK

7

www.tankonyvtar.hu

Tartalom 11. Fibre Channel over Ethernet (FCoE) 12. Network Access Storage (NAS) 12.1 Fájlrendszerek NAS és SAN környezetben 12.2 IBM Generalized Parallel File System (GPFS) 13. IBM System Storage N Series – Gateway model 14. Tárolóvirtualizáció – Storage Virtualization Irodalom

© Schubert Tamás, ÓE NIK

8

www.tankonyvtar.hu

1. Bevezetés

© Schubert Tamás, ÓE NIK

9

www.tankonyvtar.hu

1. Bevezetés (2) Új technológiai megoldások a tárolás területén az utóbbi 10-15 évben • Fibre Channel hálózati technológia. • Hálózatalapú tárolás – Network-attached storage (NAS). • Szerver fürtözés – Server Clustering. • Szerver nélküli adatmentés. • Magas rendelkezésre állás duplikált adatútvonallal. • Pillanatfelvétel-alapú adatmentés – Point-in-time data copy (snapshot). • Elosztott szalag hozzáférés – Shared tape access. • Nagy távolságú tárolás – Storage over distance. • iSCSI (Internet Small Computer System Interface). • Az adattárak és az adatátvitel Common Information Model (CIM) alapú menedzsmentje. • Tárolóvirtualizáció – Storage virtualization.

© Schubert Tamás, ÓE NIK

10

www.tankonyvtar.hu

1. Bevezetés (3) Új technológiai megoldások a tárolás területén az utóbbi 10–15 évben • A fenti újítások külön-külön és együttesen felforgatták a tárolásról alkotott korábbi képet és gyakorlatot. • A gyártókat új fejlesztésekre és versenyre sarkallta. • A fejlesztéseket a felhasználói igények is ösztönözték: o egyre nagyobb tömegű adat tárolása, o gyors elérés, o költséghatékony tárolás, o egyszerű és olcsó felügyelet az adatok teljes életciklusában.

© Schubert Tamás, ÓE NIK

11

www.tankonyvtar.hu

2. Elvárások, követelmények a tárolókkal szemben

© Schubert Tamás, ÓE NIK

12

www.tankonyvtar.hu

2. Elvárások, követelmények a tárolókkal szemben (1) • A tárolásnak szolgáltatássá kell válnia a szerverek/állomások, operációs rendszerek és alkalmazások számára. • Tároló erőforrások konszolidálása. • Tároló hierarchia létrehozása különböző sebességű, kapacitású, megbízhatóságú, rendelkezésre állású és költségű tárolók együttes kezelésével. • A tárolás centralizálásával a költségek csökkentése és a menedzselés/felügyelet egyszerűsödése, a hatékonyság növelése. • Tárolórendszer változtatása és kezelése működő környezetben. • Snapshot készítése és felhasználása backup/recovery környezetben. • Másolatok készítése visszaállítás céljából az elsődleges tárolás helyétől elkülönítve. • Másolatok készítésének lehetősége blokk módban a hatékonyság növelése érdekében. • Másolatok készítése szerver használata nélkül. • Különbségi másolat készítése a helytakarékosság érdekében. • Az információ életciklusának menedzselése (ILM), az adatok tárolási helyének policy alapú megválasztása értékük és koruk alapján.

© Schubert Tamás, ÓE NIK

13

www.tankonyvtar.hu

3. Szabványosítási szervezetek, egyesületek

© Schubert Tamás, ÓE NIK

14

www.tankonyvtar.hu

3. Szabványosítási szervezetek, egyesületek (1) Szabványosítási szervezetek • InterNational Committee for Information Technology Standards (INCITS), • Internet Engineering Task Force (IETF), • Institute of Electrical and Electronics Engineers (IEEE), • American National Standards Institute (ANSI), • International Organization for Standardization (ISO). Egyesületek • Storage Networking Industry Association (SNIA), • Fibre Channel Industry Association (FCIA).

© Schubert Tamás, ÓE NIK

15

www.tankonyvtar.hu

4. Tároló architektúrák

© Schubert Tamás, ÓE NIK

16

www.tankonyvtar.hu

4. Tároló architektúrák (1) A tárolás jellemzői • A tárolás alapvető építőelemei alig változtak az idők folyamán. • Tartalmukban, megvalósításukban, technológiájukban sokat változtak. • Változott az elhelyezésük: a számítógépen belül vagy kívül. • Intelligens diszktömbök, kapcsoló infrastruktúra és nagy teljesítményű átviteli hálózatok jelentősen megváltoztatták a tárolás tervezését. • Számos architektúra közül lehet választani a tervezés során. A tárolók alapvető építőelemei

© Schubert Tamás, ÓE NIK

17

www.tankonyvtar.hu

4. Tároló architektúrák (2) Fájlrendszerek (File Systems), Kötetek (Volumes) és Blokkok (Blocks) Elosztott tárolómodell

© Schubert Tamás, ÓE NIK

18

www.tankonyvtar.hu

4. Tároló architektúrák (3) Fájlrendszerek (File Systems), Kötetek (Volumes) és Blokkok (Blocks) • A fizikai tároló (diszk) elérése lehet: o

közvetlen a szerverről vagy az állomásról – DAS rendszerek,

o

tárolóhálózaton keresztül (Fibre Channel, Infiniband, IP) – SAN rendszerek,

o

speciális eszközön keresztül: NAS head, NAS szerver (Network Access Storage ) – NAS rendszerek.

• A fenti eszközök valamelyike végzi el a blokkaggregációt a felette lévő réteg számára.

Elosztott tárolómodell

© Schubert Tamás, ÓE NIK

19

www.tankonyvtar.hu

4. Tároló architektúrák (4) Elosztott tárolómodell A különböző architektúrák egyetlen keretrendszerben láthatók. A SNIA elosztott tárolómodellje: DAS, NAS, SAN

© Schubert Tamás, ÓE NIK

20

www.tankonyvtar.hu

4.1 Direct Access Storage (DAS) (1) A Direct Access Storage jellemzői • Blokktárolás. • Állomások és szerverek közvetlenül csatlakoznak a diszkekhez a logikai kötetkezelő szoftver segítségével (logical volume management – LVM). • Az állomás biztosítja a nagyobb rendelkezésre állást hardver vagy szoftver RAID (Redundant Array of Independent Disks) kialakításával. • A diszkek intelligenciával nem rendelkeznek (just a bunch of disks – JBOD). • A kötetkezelés és a fájlrendszer feladatait az állomás/szerver látja el.

Szerverek Nagy sebességű SCSI vagy Fibre Channel összeköttetés (SCSI protokoll) Tárolóeszközök © Schubert Tamás, ÓE NIK

21

www.tankonyvtar.hu

4.1 Direct Access Storage (DAS) (2) A Direct Access Storage előnyei és hátrányai • Előnyei: o o o

Könnyű konfigurálhatóság. A külső tárolás könnyű bővíthetőséget tesz lehetővé. SCSI vagy Fibre Channel összeköttetés.

• Hátrányai o o o

Korlátozott méretezhetőség. Erőforrás-megosztás nehézkes. Egypontos hibaforrás.

© Schubert Tamás, ÓE NIK

22

www.tankonyvtar.hu

4.2 Storage Area Network (SAN) (1) Elosztott tárolómodell A különböző architektúrák egyetlen keretrendszerben láthatók. A SNIA elosztott tárolómodellje: DAS, NAS, SAN

© Schubert Tamás, ÓE NIK

23

www.tankonyvtar.hu

4.2 Storage Area Network (SAN) (2) A Storage Area Network jellemzői • Az állomások tárolóhálózaton keresztül csatlakoznak a diszktömbhöz. • A tároló elérési mechanizmus: blokk alapú. A szerverek közvetlenül hozzáférnek az adatblokkokhoz a tárolóhálózaton keresztül. • A fájlrendszert az állomások/szerverek, a NAS vagy egyéb eszközök biztosítják. • Az állomás ellátja a kötet menedzselést, de a RAID feladatait a tároló látja el, a blokkaggregáció feladata megoszlik az állomás és az eszközök között. A SAN hálózati technológia lehet: • Fibre Channel, • InfiniBand, • Ethernet, • Myrinet.

Fibre Channel szerverek Fibre Channel Storage Area Network

Tárolóeszközök © Schubert Tamás, ÓE NIK

24

www.tankonyvtar.hu

4.2 Storage Area Network (SAN) (3) Fibre Channel SAN (FC SAN) • A Fibre Channel (FC) lényegében egysoros, SCSI-re épülő protokoll. • Az Initiator és a Target közötti műveletek SCSI parancsokra (read, write, acknowledge) épülnek. • Az áthidalható távolság és az eszközök száma a parallel SCSI-hoz képest megnövekedett.

© Schubert Tamás, ÓE NIK

25

www.tankonyvtar.hu

4.2 Storage Area Network (SAN) (4) Fibre Channel SAN (FC SAN) • Előnyei: o o o o

Gigabit sebesség. A tárolóhálózat kiterjedése MAN méretű (~100km). A tárolóhálózat jól méretezhető (több ezer csomópont). A tárolókapacitás könnyen megosztható a szerverek között.

• Hátrányai o o o o

Fibre Channel inkompatibilitási hibák előfordulhatnak (több gyártó eszközei között). Kevés képzett szakember. Kettős hálózat létrehozása (tároló- és adathálózat). Kettős menedzsmentrendszer.

© Schubert Tamás, ÓE NIK

26

www.tankonyvtar.hu

4.3 Network Access Storage (NAS) (1) Elosztott tárolómodell A különböző architektúrák egyetlen keretrendszerben láthatók. A SNIA elosztott tárolómodellje: DAS, NAS, SAN

© Schubert Tamás, ÓE NIK

27

www.tankonyvtar.hu

4.3 Network Access Storage (NAS) (2) A Network Access Storage jellemzői • A tároló elérési mechanizmus változik: fájl alapú (ellentétben a DAS és a SAN blokk-szintű hozzáférési mechanizmust biztosít a diszkekhez –SCSI alapú hozzáférési mechanizmus: SCSI, Fibre Channel, iSCSI). • LAN kapcsolja össze az állomásokat a NAS head/szerverrel (Ethernet+IP). • A fájlrendszer és a kötetkezelés feladata a NAS szerverre kerül. • A NAS funkciója átfedi a File/record réteget. • A kommunikációs kérés az állomás részéről fájlra vonatkozik. • Fájlhozzáférés leggyakrabban: NFS és CIFS segítségével. • Fájlmegosztás lehetséges. • A NAS eszköz gyakran SAN-on tárolja a blokk szintű adatokat.

© Schubert Tamás, ÓE NIK

28

www.tankonyvtar.hu

4.3 Network Access Storage (NAS) (3) A Network Access Storage előnyei és hátrányai • Előnyei: o o o o

Szabványos Ethernet és IP protokoll használata. Kiterjedése: korlátlan (az IP irányítható protokoll). Fájlkezelés optimális teljesítménnyel. A DAS-hoz képest sokkal jobban méretezhető.

• Hátrányai o o o o

LAN túlterhelés/torlódás előfordulhat. A tárolóval a NAS fájlkezelő rendelkezik. Általában speciális operációs rendszert alkalmaz. A központosított fájlkezelés nem felel meg bizonyos blokk szintű hozzáférést igénylő alkalmazásoknak.

© Schubert Tamás, ÓE NIK

29

www.tankonyvtar.hu

4.4 SAN vs. NAS (1) A SAN és a NAS összehasonlítása

© Schubert Tamás, ÓE NIK

30

www.tankonyvtar.hu

4.4 SAN vs. NAS (2) A SAN és a NAS összehasonlítása SAN

NAS

•

Blokk szintű hozzáférés.

•

Fájl szintű hozzáférés.

•

Fájlrendszert az állomás/szerver, NAS tároló biztosítja.

•

Fájlmegosztás.

•

Elérés: NFS, CIFS segítségével.

•

Elérés tárolóhálózaton keresztül: FC, Infiniband, stb.

•

•

Kiterjedése: ~100km.

Elérés adathálózaton keresztül (Ethernet, IP).

•

Elérés lehetséges adathálózaton keresztül is: iSCSI.

•

Kiterjedése: korlátlan (a késleltetéssel számolni kell).

•

Teljesítménykorlát.

•

Speciális OS.

•

Nagy átviteli teljesítmény.

•

Jól méretezhető.

© Schubert Tamás, ÓE NIK

31

www.tankonyvtar.hu

5. Tárolóeszközök

© Schubert Tamás, ÓE NIK

32

www.tankonyvtar.hu

5. Tárolóeszközök (1) Belső tárolás/Szerver alapú tárolás • A tárolók a szerver vagy a munkaállomás szekrényében/dobozában helyezkednek el. • A fájlrendszerkezelés, a kötetmenedzsment és a tárolás feladatait a számítógép látja el. • Egyszerű felépítés, alacsony költség. • Diszkmeghajtó interfészek: o SCSI (Small Computer System Interface), o IDE (Integrated Device Electronics), o ATA (Advanced Technology Attachment). • Méretezhetősége rossz. • Méretezhetősége csak külső tárolással javítható.

© Schubert Tamás, ÓE NIK

33

www.tankonyvtar.hu

5. Tárolóeszközök (2) Külső tárolás • Just a Bunch of Disks (JBOD). • Redundant Array of Independent/Inexpensive Disks (RAID). • Tape Drives és Tape Libraries. • Egyéb Storage (Optikai, félvezető alapú).

© Schubert Tamás, ÓE NIK

34

www.tankonyvtar.hu

5.1 Just a Bunch of Disks

© Schubert Tamás, ÓE NIK

35

www.tankonyvtar.hu

5.1 Just a Bunch of Disks (1) A JBOD jellemzői • Olcsó diszkek különösebb intelligencia nélkül. • A redundanciát és az intelligenciát az architektúrát alkotó más eszközökben adják hozzá (pl. állomás vagy hálózat). • A diszkeket Daisy-chain mechanizmussal kapcsolják össze: párhuzamos SCSI busz, Fibre Channel loop. JBOD: Fibre Channel loop

© Schubert Tamás, ÓE NIK

36

www.tankonyvtar.hu

5.2 Redundant Array of Independent/Inexpensive Disks

© Schubert Tamás, ÓE NIK

37

www.tankonyvtar.hu

5.2 Redundant Array of Independent/Inexpensive Disks (1) A RAID jellemzői • Olcsó diszkek különösebb intelligencia nélkül. • A RAID megvalósítható a tároló hardver eszközben, tárolóvezérlőben (host bus adapter – HBAs), szoftverben. • Számos redundanciát biztosító változat: tükrözés, paritás. • Teljesítménynövelés: stripe. • Menet közben cserélhető diszkek. • 5.25 inch és 3.5 inch meghajtók. • Tároló menedzsment szolgáltatás.

© Schubert Tamás, ÓE NIK

38

www.tankonyvtar.hu

5.2 Redundant Array of Independent/Inexpensive Disks (2) A RAID jellemzői http://en.wikipedia.org/wiki/Standard_RAID_levels JBOD • Nem valódi RAID. • Különböző méretű diszkek konkatenációja. • A diszkterület jobb kihasználását teszi lehetővé.

RAID 0 • Nem valódi RAID: stripe set vagy striped volume. • Egyenletesen szétdarabolja az összefüggő adatblokkokat két vagy több diszkre. • Nincs paritás, nincs redundancia. • Teljesítménynövelést lehet elérni. © Schubert Tamás, ÓE NIK

39

www.tankonyvtar.hu

5.2 Redundant Array of Independent/Inexpensive Disks (3) A RAID jellemzői RAID 1 • Tükrözés, pontos másolat. • Teljesítménynövelés, redundancia.

RAID 2 • Nem használják. • Bit szintű stripe. • Hibajavítás (Hamming code).

© Schubert Tamás, ÓE NIK

40

www.tankonyvtar.hu

5.2 Redundant Array of Independent/Inexpensive Disks (4) A RAID jellemzői RAID 3 • Bájt szintű striping. • Dedikált paritás diszk. • Ritkán használják. • Több kérés egyidejű kiszolgálását nem biztosítja.

RAID 4 • Blokk szintű striping. • Dedikált paritás diszk. • Több kérés egyidejű kiszolgálását biztosítja. • Legalább 3 diszk szükséges.

© Schubert Tamás, ÓE NIK

41

www.tankonyvtar.hu

5.2 Redundant Array of Independent/Inexpensive Disks (5) A RAID jellemzői RAID 5 • Blokk szintű striping. • Paritás elosztott a diszkek között. • Alacsony költségű redundancia. • Lehet hardver paritásszámítás támogatás. • Legalább 3 diszk szükséges. • Véletlenszerű írás teljesítménye gyenge, főleg sok egyidejű kérés kiszolgálásakor. RAID 6 • RAID 5 kiterjesztése további paritás diszkekkel. • Nagyobb adatbiztonság. • Kisebb tárolókapacitás kihasználás.

© Schubert Tamás, ÓE NIK

42

www.tankonyvtar.hu

5.2 Redundant Array of Independent/Inexpensive Disks (6) A RAID jellemzői RAID 6 (folytatás) •

According to SNIA (Storage Networking Industry Association), the definition of RAID 6 is: "Any form of RAID that can continue to execute read and write requests to all of a RAID array's virtual disks in the presence of any two concurrent disk failures. Several methods, including dual check data computations (parity and Reed Solomon), orthogonal dual parity check data and diagonal parity have been used to implement RAID Level 6."

Nem szabványos szintek (http://en.wikipedia.org/wiki/Non-standard_RAID_levels) •

RAID 5 és 6 kiterjesztései: 5E, 5EE és 6E extend RAID 5 and 6 (meleg tartalék meghajtók).

•

Egyéb: RAID 1.5, RAID 7, RAID-DP, RAID S vagy Parity RAID, Matrix RAID, RAID-K, RAID-Z, RAIDn, Linux MD RAID 10, IBM ServeRAID 1E és unRAID.

© Schubert Tamás, ÓE NIK

43

www.tankonyvtar.hu

5.3 Tape Drives és Tape Libraries

© Schubert Tamás, ÓE NIK

44

www.tankonyvtar.hu

5.3 Tape Drives és Tape Libraries (1) A Tape Drives és Tape Libraries jellemzői •

Mágneses elvű tárolás.

•

Nagykapacitású, alacsony költségű tárolók (diszkekhez viszonyítva).

•

Cserélhető szalagegységek.

•

A SAN lehetővé teszi a szalagkönyvtárak megosztását a szerverek között. Közvetlen kapcsolat a szerverek és a szalagkönyvtárak között. Ez tehermentesíti az adathálózatot.

•

Megfelelő szoftvertámogatással gazdaságos, könnyen kezelhető backup rendszer.

•

Többféle médiatípus: digital linear tape (DLT), linear tape-open (LTO), és advanced intelligent tape (AIT).

•

A szalagkönyvtárnak a vállalati tárolási architektúrába kell illeszkednie.

•

A média öregedésével is számolni kell.

•

Hosszú távú tárolás esetén évenkénti adatfelújítás szükséges.

© Schubert Tamás, ÓE NIK

45

www.tankonyvtar.hu

5.4 Egyéb Storage

© Schubert Tamás, ÓE NIK

46

www.tankonyvtar.hu

5.4 Egyéb Storage (optikai, félvezető alapú) (1) Az optikai és félvezető alapú tárolók jellemzői Optikai tárolók •

Elektromágneses elvű tárolás.

•

A mágnesszalagénál nagyobb élettartam.

•

CD/DVD, 5.25” WORM (write once, read many) és 12” optikai diszk.

•

Független meghajtók vagy könyvtár (jukebox).

Félvezető alapú tárolók •

Tárolás memóriachipekben.

•

Nagy teljesítmény.

•

Magas költség.

•

Korlátozott felhasználás.

© Schubert Tamás, ÓE NIK

47

www.tankonyvtar.hu

6. Párhuzamos vs. soros átvitel

© Schubert Tamás, ÓE NIK

48

www.tankonyvtar.hu

6. Párhuzamos vs. soros átvitel (1) Elvárások, követelmények a tárolókkal szemben Párhuzamos adatátvitel 0 1 2 3 4 5 6 7

Soros átvitel

Adatbitek

Adatvonalak

skew Párhuzamos átvitel

Soros átvitel

• Az adatszó egyes bitjei időben eltolva érkeznek (skew). • Áthallás a vezetékek között (crosstalk). • A kábel hossza nem növelhető.

• A skew probléma megszűnik. • Vezetékek közötti áthallás megszűnik. • A csatlakoztatás egyszerűsödik. • Nagyobb átviteli sebesség érhető el. • Pont-pont kapcsolat jön létre.

© Schubert Tamás, ÓE NIK

49

www.tankonyvtar.hu

6. Párhuzamos vs. soros átvitel (2) Signal skew párhuzamos buszon

A Small Computer System Interface (SCSI) jelek terjedési késleltetése © Schubert Tamás, ÓE NIK

50

www.tankonyvtar.hu

6. Párhuzamos vs. soros átvitel (3) SCSI távolságkorlátok

© Schubert Tamás, ÓE NIK

51

www.tankonyvtar.hu

6. Párhuzamos vs. soros átvitel (4) Serial Attached SCSI (SAS) paraméterek

© Schubert Tamás, ÓE NIK

52

www.tankonyvtar.hu

7. SCSI Architecture Model

© Schubert Tamás, ÓE NIK

53

www.tankonyvtar.hu

7. SCSI Architecture Model (SAM) (1) ANSI of T10, a Technical Committee of Accredited Standards Committee NCITS

© Schubert Tamás, ÓE NIK

54

www.tankonyvtar.hu

7. SCSI Architecture Model (2) SCSI szabványcsalád

© Schubert Tamás, ÓE NIK

55

www.tankonyvtar.hu

7. SCSI Architecture Model (3) SCSI ügyfél-szerver modell

© Schubert Tamás, ÓE NIK

56

www.tankonyvtar.hu

7. SCSI Architecture Model (4) SCSI protokoll és a Logical Units (LU) •

Az ügyfél/szerver funkció választja el, illetve kapcsolja össze a feldolgozó egységet (initiator) és a tároló egységet (target), amely az SCSI szolgáltatást biztosítja.

•

A target SCSI feldolgozó egysége képviseli a Logical Unitot (LU).

•

Ezt egy Logical Unit Number (LUN) azonosítja.

•

Hagyományosan a LUN felépítése: bus/target/LUN descriptor (a párhuzamos SCSI eszközökből eredően).

•

LUN: o Bus: SCSI interfész (adapter). o Target: diszk a párhuzamos buszon. o LUN descriptor .

•

Fibre Channel LUN: o Bus: A Fibre Channel host bus adaptert (HBA) az operációs rendszer SCSI busznak tekinti. o Target: Storage. o LUN descriptor: SCSI diszk.

© Schubert Tamás, ÓE NIK

57

www.tankonyvtar.hu

7. SCSI Architecture Model (5) SCSI protokoll és a Logical Units (LU) •

Pl.: egy RAID eszköz azonosítható egy bus/target párossal + több LUN descriptorral (több logikai egység).

•

Pl.: FC SAN-on a bus/target/LUN descriptor hármast (op. rendszer) megfeleltetik eszköz ID/LUN párosnak (tárolóhálózat).

•

A LUN biztosítja a tárolórendszer integritását az olvasási/írási műveletek szempontjából.

•

Egy-egy tárolótömb több/sok LUN-nal rendelkezhet, amelyek mérete dinamikusan változtatható (növelhető/csökkenthető).

•

A LUN logikailag összefüggő, a Logical Blokk Numberrel (LBA) címezhető blokkok sorozatából áll.

•

A LUN fizikai blokkjai nem alkotnak feltétlenül összefüggő tartományt, sőt fizikailag különböző tárolókon is elhelyezkedhetnek (virtualizáció).

•

A virtualizációt a szerver/állomás, a tároló egység, a SAN infrastruktúra (fabric), vagy speciális hardver eszköz (appliance) egyaránt végezheti.

© Schubert Tamás, ÓE NIK

58

www.tankonyvtar.hu

7. SCSI Architecture Model (6) LUN mapping •

A LUN azonosítók egyediek.

•

Gyakran az operációs rendszerek csak a LUN 0-ról bootolhatnak.

•

Ha több szerver is ugyanarról a tárolótömbről bootol, mindegyik szemszögéből kell lennie egy LUN 0-nak.

•

A LUN mapping teszi lehetővé, hogy virtuális LUN-számról leképezés történjen a valós LUN-ra.

•

A leképezést elvégezheti a host bus adapter (HBA), a SAN kapcsoló vagy a tárolóvezérlője is.

© Schubert Tamás, ÓE NIK

59

www.tankonyvtar.hu

7. SCSI Architecture Model (7) LUN mapping •

A fájlrendszer adatai fájlrendszer blokkok formájában érhetőek el a számítógépek számára.

•

A fájlrendszer blokkok mérete: 512 bájt–512 Kbájt közötti lehet (a fájlrendszer létesítésekor kell meghatározni).

•

Ezek a blokkok a tároló összefüggő, 512 bájt méretű fizikai blokkjaiban (szektoraiban) vannak tárolva.

•

Egy-egy kötet a kötetmenedzser (volume manager) felügyelete alatt áll. Ez biztosítja logikailag összefüggő, sorszámozott blokkok halmazát a fájlrendszer számára.

•

A SCSI protokoll biztosítja a fizikai blokkok írását és olvasását a kötetet alkotó logikai egységekre/ről.

© Schubert Tamás, ÓE NIK

60

www.tankonyvtar.hu

8. A SAN-ok használatának előnyei

© Schubert Tamás, ÓE NIK

61

www.tankonyvtar.hu

8. A SAN-ok használatának előnyei (1) Az infrastruktúra egyszerűsödése •

Konszolidáció o Az erőforrások számának csökkenése. o Kisebb számú, nagyobb teljesítményű eszköz koncentrálása (storage pools). o IT hatékonyság növelése. o Infrastruktúra egyszerűsödése. o Menedzsment központosítható. o Méretezhetőség javulása. o Rendelkezésre állás növelése. o Katasztrófatűrés növelése.

© Schubert Tamás, ÓE NIK

62

www.tankonyvtar.hu

8. A SAN-ok használatának előnyei (2) Az infrastruktúra egyszerűsödése (folytatás) •

Virtualizáció o Különböző típusú fizikai tárolók összekapcsolása. o Egyetlen, egységes eszközként látszanak az operációs rendszerek/alkalmazások számára. o Elrejti a különböző tároló és összekapcsoló technológiákat és protokollokat az operációs rendszerek/alkalmazások elől. o Csökken az adminisztratív és felügyeleti költség. o Jobb szolgáltatást biztosít.

•

Automatizálás o Tároló típusának kiválasztása (policy-based). o LUN méretének növelése, csökkentése. o Snapshot készítése. o Mentés.

•

Integráció o Felügyelet egyszerűsödik. o Biztonság növekszik.

© Schubert Tamás, ÓE NIK

63

www.tankonyvtar.hu

8. A SAN-ok használatának előnyei (3) Az infrastruktúra egyszerűsödése (folytatás) Diszk és szalag tároló konszolidáció

Elszigetelt tárolás

© Schubert Tamás, ÓE NIK

Konszolidált tárolás

64

www.tankonyvtar.hu

8. A SAN-ok használatának előnyei (4) Information lifecycle management (ILM) •

Az információ automatikus felügyelete a keletkezésétől a szándékos felszámolásáig.

•

Optimalizált tárolás a teljes életciklus alatt.

•

Hatékony elérés a szükségleteknek megfelelően.

•

Költségek minimalizálása.

© Schubert Tamás, ÓE NIK

65

www.tankonyvtar.hu

8. A SAN-ok használatának előnyei (5) Üzletfolytonosság biztosítása (Business continuity) •

Az információt elérhetővé kell tenni a nap bármelyik órájában, a Föld bármelyik pontjáról.

•

A folyamatos működés szükségszerű követelmény.

•

A bizalmasság és a biztonság alapkövetelmény.

•

A törvényi előírásoknak meg kell felelni.

© Schubert Tamás, ÓE NIK

66

www.tankonyvtar.hu

9. Fibre Channel SAN

© Schubert Tamás, ÓE NIK

67

www.tankonyvtar.hu

9. Fibre Channel SAN (1) Fibre Channel •

A Fibre Channel a legelterjedtebb architektúra a SAN-ok megvalósítására.

•

InterNational Committee for Information Technology Standards (INCITS) T11 Technical Committee fejlesztette ki. (Az American National Standard Institute (ANSI) által akkreditált szabványosítási bizottság.)

•

A Fibre Channel Protocol (FCP) megvalósítása az FC infrastruktúrán.

•

SCSI interfész protokoll beágyazása a Fibre Channel hálózati protokollba.

•

Réz- és optikai hálózaton egyaránt használható.

•

Fibre or Fiber? o

Fibre Channel – eredetileg üvegszálas technológiára tervezték.

o

Később fejlesztették ki réz alapú technológiára. Ekkor úgy döntött a T11 Technical Committee, hogy megtartják a nevet, de a szabványra való hivatkozáskor az UK English betűzést (Fibre) használják.

o

Amikor az üvegszálas kábelezésről van szó, továbbra is az US English betűzést (Fiber) használják.

© Schubert Tamás, ÓE NIK

68

www.tankonyvtar.hu

9. Fibre Channel SAN (2) A Fibre Channel előnyei •

Nagy teljesítmény nagy mennyiségű adatok átvitele esetén.

•

Egyszerű átviteli protokoll.

•

Kiterjedt hardvertámogatás.

•

Soros átvitel.

•

Fizikai interfész megvalósítása alacsony hibaaránnyal.

•

Garantált hibamentes adatátvitel.

•

Adatok csomagokba (keretekbe) szervezése.

•

Legkülönbözőbb típusú adatok szállítása (adat, videó, hang).

•

Már létező eszközorientált parancskészlet használata (SCSI, FCP).

•

Nagy címtartomány az eszközök címzésére.

© Schubert Tamás, ÓE NIK

69

www.tankonyvtar.hu

9. Fibre Channel SAN (3) A Fibre Channel infrastruktúra elemei • • • • • • •

switch-ek, directorok, routerek, hubok, összeköttetések, Host Bus Adapterek, Menedzsmentszoftver.

Fibre Channel szerverek

Fibre Channel Storage Area Network Tárolóeszközök © Schubert Tamás, ÓE NIK

70

www.tankonyvtar.hu

9.1 A Fibre Channel rétegstruktúrája

© Schubert Tamás, ÓE NIK

71

www.tankonyvtar.hu

9.1 A Fibre Channel rétegstruktúrája (1) A Fibre Channel rétegstruktúrája •

Követi az ISO/OSI modellt.

© Schubert Tamás, ÓE NIK

72

www.tankonyvtar.hu

9.1 A Fibre Channel rétegstruktúrája (2) Az FC rétegstruktúrája •

FC-0, fizikai interfész és média: kábelek, csatlakozók, villamos paraméterek, adatátvitel sebesség, stb.

•

FC-1, adatátviteli protokoll: Kódolás/dekódolás (8B/10B), DC-balance.

•

FC-2, keretezés és jelzés protokoll: az adatok továbbításáról, a keretek átviteléről gondoskodik. Biztosítja a megbízható adatátvitelt. Önkonfiguráló képesség. Point-to-point, arbitrated loop és kapcsolt topológia támogatása.

Az FC-0, FC-1 és FC-2 alkotják a Fibre Channel fizikai és jelzési interfészét (FC-PH).

© Schubert Tamás, ÓE NIK

73

www.tankonyvtar.hu

9.1 A Fibre Channel rétegstruktúrája (3) Az FC rétegstruktúrája •

•

FC-3, általános szolgáltatások, pl.: o

Striping: megtöbbszörözi a sávszélességet. Több portot használ párhuzamosan az információ átvitelére több útvonal használatával.

o

Multicast: üzenet elküldése több vagy az összes állomásnak.

FC-4, Felsőbb rétegbeli protokollok leképzése (Upper layer protocol mapping – ULP). o

Definiálja a futtatható alkalmazásinterfészeket. Megadja, hogy a FC protokoll milyen felsőbb szintű protokollal áll kapcsolatban.

o

Ugyanazon a fizikai interfészen egyidejűleg haladhat csatorna és hálózati információ. Csatorna: pl.: Fibre Channel Protocol (FCP) SCSI adatokat szállít az FC fölött.. Hálózat: IP csomagok küldése csomópontok között.

© Schubert Tamás, ÓE NIK

74

www.tankonyvtar.hu

9.1 A Fibre Channel rétegstruktúrája (4) Az FC rétegstruktúrája

© Schubert Tamás, ÓE NIK

75

www.tankonyvtar.hu

9.2 Fibre Channel szolgáltatásosztályok

© Schubert Tamás, ÓE NIK

76

www.tankonyvtar.hu

9.2 Fibre Channel szolgáltatásosztályok (1) Az FC szolgáltatásosztályok (Classes of services) Az egyes alkalmazástípusok különböző szolgáltatási szinteket várnak el az átviteli rendszertől a kézbesítést, az összeköttetést és a sávszélességet illetően. 6 szolgáltatásosztály létezik: •

•

Class 1. o

Dedikált összeköttetés a hálózaton (fabric) keresztül az átvitel ideje alatt.

o

Teljes sávszélességet biztosít az összeköttetésen a két végpont között.

o

Nyugtázás van.

o

A sávszélesség kihasználása nem nagyon jó.

Class 2. o

Összeköttetés nélküli átvitel a hálózaton (fabric) keresztül.

o

Nyugtázás van.

o

Sorrendhiba előfordulhat (felsőbb réteg javíthatja).

o

A sávszélesség kihasználása jobb mint a Class 1-é.

© Schubert Tamás, ÓE NIK

77

www.tankonyvtar.hu

9.2 Fibre Channel szolgáltatásosztályok (2) Az FC szolgáltatásosztályok (Classes of services) •

Class 3. o

Nincs dedikált összeköttetés a hálózaton (fabric) keresztül (datagram connectionless service).

o

Nincs nyugtázás.

o

Hibákat a felsőbb réteg javítja (sorrend javítása, hiányzó keret újrakérése).

o

A sávszélesség kihasználása jó.

o

A leggyakrabban használt szolgáltatásosztály.

© Schubert Tamás, ÓE NIK

78

www.tankonyvtar.hu

9.2 Fibre Channel szolgáltatásosztályok (3) Az FC szolgáltatásosztályok (Classes of services) •

Class 4. o

Hasonlít a Class 1-re.

o

Dedikált összeköttetés (garantált kézbesítési sorrend).

o

Nem biztosít teljes sávszélességet (csak egy részét) az összeköttetésen a kapcsolók (N-portok) között.

o

Virtuális áramkör (VC), garantált QoS (sávszélesség és késleltetés) az N-portok között.

o

Nyugtázás van.

o

A sávszélesség kihasználása nem nagyon jó.

o

Főleg multimédia alkalmazásokban használják.

© Schubert Tamás, ÓE NIK

79

www.tankonyvtar.hu

9.2 Fibre Channel szolgáltatásosztályok (4) Az FC szolgáltatásosztályok (Classes of services) •

Class 5. o o o

•

Isochron szolgáltatás. Azonnali kézbesítés. Nincs pufferelés.

Class 6. o o o

Class 1. változata Dedikált összeköttetés. Megbízható multicast (audió, videó).

© Schubert Tamás, ÓE NIK

80

www.tankonyvtar.hu

9.3 A Fibre Channel működése

© Schubert Tamás, ÓE NIK

81

www.tankonyvtar.hu

9.3 A Fibre Channel működése (1) FC keret •

Adathossz 528 szó (2112 bájt).

Fibre Channel keretfelépítés

© Schubert Tamás, ÓE NIK

82

www.tankonyvtar.hu

9.3 A Fibre Channel működése (2) Címzés a Fibre Channel hálózatban •

Minden eszköz azonosítóval rendelkezik.

•

A cím hozzárendelésének módja és használata az FC topológiától függ (arbitrated loop vagy fabric).

World Wide Name (WWN) •

Szerkezete hasonlít az Ethernet cím szerkezetére.

•

Minden N-port (végállomás: gép, tároló) rendelkezik WWN-nel.

•

A WWN cím 64-bites és globálisan egyedi.

•

Az IEEE két WWN címformát definiált.

•

Több adapterrel rendelkező eszköz minden portja rendelkezik WWN-nel (world wide port name – WWPN).

© Schubert Tamás, ÓE NIK

83

www.tankonyvtar.hu

9.3 A Fibre Channel működése (3) World Wide Name címséma

hex 10 vagy hex 20 a cím első 2 bájtjában

hex 5 vagy 6 a cím első fél bájtjában

© Schubert Tamás, ÓE NIK

84

www.tankonyvtar.hu

9.3 A Fibre Channel működése (4) Port-címek •

A 64 bites címek túl hosszúak, használatuk nem hatékony.

•

Készült egy másik címzési séma is 24 bites címekkel.

•

A kapcsolt hálózatban (fabric) minden port rendelkezik ilyen címmel.

•

Szükség van a 64 bites WWN címek és a 24 bites címek megfeleltetésére.

•

A kapcsolók végzik el a címzést és a címek karbantartását.

•

Amikor az eszköz bejelentkezik a kapcsolóra, a kapcsoló rendel címet a porthoz, és nyilvántartja az eszköz WWN és port címének megfeleltetését.

•

Ezt a feladatot a kapcsoló Name Servere látja el.

© Schubert Tamás, ÓE NIK

85

www.tankonyvtar.hu

9.3 A Fibre Channel működése (5) Port címek •

A 24 bites címek szerkezete: o

Domain: a kapcsolót azonosítja.

o

Area: az Fl_portot azonosítja (arbitrated loop esetén).

o

Port: a csatlakozó készülék N_Port és NL_Port címe.

© Schubert Tamás, ÓE NIK

86

www.tankonyvtar.hu

9.3 A Fibre Channel működése (6) FC topológiák •

Az FC hálózatok infrastruktúra elemei: director, switch, hub, router, gateway, bridge.

•

A használt eszközök típusa a hálózat méretétől és bonyolultságától függ.

•

Minden eszköztípus rendelkezik menedzsment szolgáltatással, amely szerepet játszik a végállomásokat is magában foglaló összetett felügyeleti környezet kialakításában.

•

Három Fibre Channel topológia típus:

•

o

Point-to-point,

o

Arbitrated loop,

o

Switched fabric.

Full duplex kapcsolat mindhárom topológia esetén.

© Schubert Tamás, ÓE NIK

87

www.tankonyvtar.hu

9.3 A Fibre Channel működése (7) FC topológiák

© Schubert Tamás, ÓE NIK

88

www.tankonyvtar.hu

9.3 A Fibre Channel működése (8) FC topológiák: Point-to-Point •

2 csomópont vesz részt benne.

Point-to-Point

© Schubert Tamás, ÓE NIK

89

www.tankonyvtar.hu

9.3 A Fibre Channel működése (9) FC topológiák: Arbitrated Loop (FC-AL) •

126 csomópont (NL_Ports).

•

Az átvitel idejére összeköttetés jön létre a végpontok között.

•

Távolság max. 10 km.

•

Osztott sávszélesség.

Arbitrated Loop (FC-AL)

© Schubert Tamás, ÓE NIK

90

www.tankonyvtar.hu

9.3 A Fibre Channel működése (10) FC topológiák: Switched fabric (FC-SW) •

Kapcsolók, directorok, hidak alkotják.

•

Portonként teljes sávszélesség.

Switched fabric (FC-SW)

© Schubert Tamás, ÓE NIK

91

www.tankonyvtar.hu

9.3 A Fibre Channel működése (11) FC port-típusok

© Schubert Tamás, ÓE NIK

92

www.tankonyvtar.hu

9.3 A Fibre Channel működése (12) FC port-típusok (nem teljes felsorolás) •

E_Port: Bővítő port (inter-switch expansion port (ISL)) összeköttetés esetén.

•

F_Port: Fabric port (nem loop-képes). N_Port point-point csatolása kapcsolóhoz.

•

FL_Port: Fabric port (loop-képes). NL_Port csatolása kapcsolóhoz public loop konfigurációban.

•

G_Port: Generikus port, működhet E_Port vagy F_Port módban.

•

L_Port: Loop-képes csomópont vagy kapcsolóport.

•

U_Port: Univerzális port — a G_Portnál általánosabb működésre képes: E_Port, F_Port vagy FL_Port.

•

N_Port: Nem loop-képes csomóponti port. Eszköz csatlakoztatása kapcsolóhoz.

•

NL_Port: loop-képes csomóponti port. Eszköz csatlakoztatása kapcsolóhoz (L_Port vagy FL_Port ) loop konfigurációban.

© Schubert Tamás, ÓE NIK

93

www.tankonyvtar.hu

9.3 A Fibre Channel működése (13) Fibre Channel login Az eszközök csatlakozásakor, kapcsolatépítéskor különböző login folyamatok játszódnak le: • Port login (session felépítés két N_Port között), •

Process login,

•

Fabric login.

(Részletesen nem ismertetjük.) Fibre Channel fabric services A kapcsolók és a directorok az eszközök számára elosztott szolgáltatásokat nyújtanak: • Management services, •

Time services,

•

Simple name server,

•

Login services,

•

Registered State Change Notification (RSCN)

(Részletesen nem ismertetjük.) © Schubert Tamás, ÓE NIK

94

www.tankonyvtar.hu

9.3 A Fibre Channel működése (14) Fibre Channel routing mechanizmus Kapcsolók, directorok, esetleg más hálózatok (LAN/WAN) közötti forgalom biztosítása. • Spanning tree: Redundancia alternatív útvonalakkal. Egy aktív útvonal. • IEEE 802.1 standard. • Útvonalválasztás: fabric shortest path first (FSPF). • Minden útvonal automatikusan létrejön indításkor. • Működése hasonlít az OSPF protokolléhoz. • Az útvonalak jóságát az ugrások száma határozza meg.

© Schubert Tamás, ÓE NIK

95

www.tankonyvtar.hu

9.4 Fibre Channel biztonság

© Schubert Tamás, ÓE NIK

96

www.tankonyvtar.hu

9.4 Fibre Channel biztonság (1) Fibre Channel biztonság A SAN-okkal kapcsolatos biztonságnak az alábbi területekre kell kiterjedniük: •

Biztosítani kell, hogy csak meghatározott eszközök (kapcsolók, HBA-k) csatlakozhassanak a SAN infrastruktúrához.

•

Az infrastruktúra felügyeletét biztonságossá kell tenni.

•

A konfiguráció változásait naplózni kell.

•

Szabályozni kell a SAN-hoz csatlakozó állomások hozzáférését az egyes LUN-okhoz.

•

Az adattovábbítást titkosítani kell.

•

Az adattovábbítás integritását biztosítani kell.

•

Az ANSI T11 group az FC-SP projekt keretében 2002 óta foglalkozik a SAN környezetben alkalmazható biztonsági technológiák kidolgozásával.

•

Az FC-SP egy biztonsági keretrendszer, amely magában foglalja a Fibre Channel eszközök hitelesítését, a biztonságos kulcscserét, és a kriptográfiailag biztonságos kommunikációt az FC eszközök között.

•

Az FC-SP a hálózaton áthaladó adatok biztonságára koncentrál, és nem foglalkozik az adattárolás biztonságával.

© Schubert Tamás, ÓE NIK

97

www.tankonyvtar.hu

9.4 Fibre Channel biztonság (2) Fibre Channel Authentication Protocol •

A Switch Link Authentication Protocol (SLAP/FC-SW-3) bizalmi viszonyt épít ki az FC infrastruktúrát alkotó eszközök egy régiójában.

•

Ehhez az összes eszköznek közreműködnie kell: kapcsolók, HBA-k.

•

A Brocade és az Emulex kidolgozott egy másik protokollt, a Fibre Channel Authentication Protocol (FCAP), amely a SLAP utódja.

•

Az FCAP egy Public Key Infrastructure (PKI) alapú technológia a bizalmi viszony kialakítására az FC infrastruktúrát alkotó eszközök tartományában.

© Schubert Tamás, ÓE NIK

98

www.tankonyvtar.hu

9.4 Fibre Channel biztonság (3) Virtual SAN-ok (VSAN) •

Virtuális FC SAN infrastruktúra (fabric) kialakításának lehetősége.

•

A VLAN-ok mintájára készült.

•

A Cisco dolgozta ki.

•

2004-ben az InterNational Committee for Information Technology Standards (INCITS) T11 bizottsága választotta ki a Cisco megoldását, és javasolta az ANSI-nak elfogadásra.

•

Ugyanaz a hardver infrastruktúra logikailag több, különálló infrastruktúrának tekinthető.

•

VSAN-ok kialakításának előnyei: jobb méretezhetőség, a tartományok függetlensége, nagyobb biztonság.

•

Minden VSAN rendelkezik saját hardver zónákkal, dedikált fabric szolgáltatással, menedzsment lehetőséggel.

•

A VSAN-ok forgalma elkülönül.

•

A VSAN-ok között nincs átjárás.

© Schubert Tamás, ÓE NIK

99

www.tankonyvtar.hu

9.4 Fibre Channel biztonság (4) Egyéb biztonsági megoldások •

Zónák kialakítása.

•

LUN maszkolás.

•

Az adatátvitel biztonsága. o

Az adattovábbítást titkosítani kell.

o

Az adattovábbítás integritását biztosítani kell.

o

A LAN-éval azonos biztonságra van szükség.

o

Az FC-SP az IP hálózatokban használt biztonsági megoldásokat javasolja: 



FCPAP hivatkozik a Secure Remote Password Protocolra (SRP), RFC 2945. DH-CHAP hivatkozik a Challenge Handshake Authentication Protocolra (CHAP) RFC 1994.



FCSec hivatkozik az IP Security-ra (IPsec), RFC 2406.



Az FCSec javasolja az alábbi eszközök közötti hitelesítést: Node-to-node, Node-to-switch, Switch-to-switch.

© Schubert Tamás, ÓE NIK

100

www.tankonyvtar.hu

9.4 Fibre Channel biztonság (5) Zónázás • Lehetővé teszi a kapcsolt hálózat szegmentálását. •

Különböző környezetek alakíthatók ki.

•

Csak az azonos zónában lévő csomópontok kommunikálhatnak egymással.

•

Biztonsági szerepet tölt be.

© Schubert Tamás, ÓE NIK

101

www.tankonyvtar.hu

9.4 Fibre Channel biztonság (6) Zónázás (folytatás) Két megvalósítása van: •

Hardverzónázás o

A fabric fizikai port számaira épül.

o

A zóna elemei a kapcsolóportok.

o

A zónák és a kapcsolóportok kapcsolata lehet: 

One-to-one,



One-to-many,



Many-to-many.

o

ASIC végzi a műveletet.

o

Nagyobb biztonság a SW-hez képest.

o

Portváltás nehézkes.

© Schubert Tamás, ÓE NIK

102

www.tankonyvtar.hu

9.4 Fibre Channel biztonság (7) Zónázás (folytatás) •

Szoftverzónázás o

A fabric kapcsoló operációs rendszere valósítja meg.

o

A Name Server és az FCP együttesen teszi lehetővé a működést.

o

A Name Server csak a saját zónához tartozó portokkal válaszol.

o

Az eszköz bejelentkezéskor lekéri a rendelkezésre álló tárolóeszközöket. A simple name server (SNS) kikeresi a zónatáblából a zónába tartozó eszközöket.

© Schubert Tamás, ÓE NIK

103

www.tankonyvtar.hu

9.4 Fibre Channel biztonság (8) LUN masking •

Biztonsági szolgáltatás.

•

A szerverek kérhetik a SAN-tól bizonyos LUN-ok használatát.

•

Biztonsági okokból nem szabad megengedni, hogy egy-egy szerver tetszőlegesen hozzáférjen bármelyik LUN-hoz.

•

A LUN masking teszi ezt lehetővé.

•

A tároló engedélyezheti vagy tilthatja a szervereknek az egyes LUN-ok elérését.

•

A LUN mapping menedzsmentszoftverekkel konfigurálható a tárolóban.

•

A tároló hozzáférés kérés esetén hozzáférés listák alapján engedélyezi vagy tiltja a hozzáférést.

© Schubert Tamás, ÓE NIK

104

www.tankonyvtar.hu

9.5. A Fibre Channel technológia jövője

© Schubert Tamás, ÓE NIK

105

www.tankonyvtar.hu

9.5 A Fibre Channel technológia jövője (1) A Fibre Channel technológia jövője

© Schubert Tamás, ÓE NIK

106

www.tankonyvtar.hu

10. IP tárolóhálózatok (IP Storage Networks)

© Schubert Tamás, ÓE NIK

107

www.tankonyvtar.hu

10. IP tárolóhálózatok (IP Storage Networks) (1) Az IP tárolóhálózatok jellemzői •

Az IP SAN ötlete 2000-ben alakult ki.

•

Szerverek és tárolóeszközök összekapcsolása, és blokkátvitel Ethernet/IP hálózaton keresztül.

•

Kiérlelt hálózati technológia és a blokkátvitelt biztosító eszközök együttes használata SAN kialakítására.

•

A technológia neve: Internet Small Computer Systems Interface, röviden iSCSI.

•

Egyetlen hálózati technológia használata adatátvitel és a tároló forgalom biztosítására (konszolidáció).

•

Az iSCSI protokoll SCSI parancsokat, adatokat és állapotinformációt visz át az SCSI Initiator és az SCSI Target között TCP/IP hálózaton keresztül.

© Schubert Tamás, ÓE NIK

108

www.tankonyvtar.hu

10.1 Internet SCSI tárolóhálózatok (iSCSI)

© Schubert Tamás, ÓE NIK

109

www.tankonyvtar.hu

10.1 Internet SCSI tárolóhálózatok (iSCSI) (1) Az iSCSI tárolóhálózat protokoll szintű felépítése

© Schubert Tamás, ÓE NIK

110

www.tankonyvtar.hu

10.1 Internet SCSI tárolóhálózatok (iSCSI) (2) iSCSI – protokoll rétegek

© Schubert Tamás, ÓE NIK

111

www.tankonyvtar.hu

10.1 Internet SCSI tárolóhálózatok (iSCSI) (3) Az iSCSI tárolóhálózatok jellemzői • Az iSCSI protokoll a szerverekben és a tárolóeszközökben van megvalósítva. • Végpontok között működő iSCSI protokoll. • A Fibre Channel protokoll itt egyáltalán nem játszik szerepet. Tisztán iSCSI tárolóhálózat

© Schubert Tamás, ÓE NIK

112

www.tankonyvtar.hu

10.1 Internet SCSI tárolóhálózatok (iSCSI) (4) Az iSCSI protokoll értékelése •

Előnyei: o Közös Gigabit Ethernet és IP protokoll használata LAN és SAN célra. o Alacsonyabb költségű megoldás lehet az FC-hez képest. o Gigabit átviteli teljesítmény. o Egységes hálózatmenedzsment. o Kiterjeszthető MAN és WAN hálózatokra. o Optimalizált szolgáltatói architektúra. o Jól képzett hálózati szakembergárda rendelkezésre áll. o Jól meghatározott fejlesztési irány: 10 Gbps+.

•

Hátrányai: o Viszonylag új technológia. o Új IP szabványok állnak fejlesztés alatt. o A végberendezések cseréje szükséges (adapterek).

© Schubert Tamás, ÓE NIK

113

www.tankonyvtar.hu

10.1 Internet SCSI tárolóhálózatok (iSCSI) (5) Tároló architektúrák – protokoll rétegek

© Schubert Tamás, ÓE NIK

114

www.tankonyvtar.hu

10.1 Internet SCSI tárolóhálózatok (iSCSI) (6) A Fibre Channel és az Ethernet/IP hálózati infrastruktúra (fabric) összehasonlítása

© Schubert Tamás, ÓE NIK

115

www.tankonyvtar.hu

10.2 Fibre Channel over IP – FCIP

© Schubert Tamás, ÓE NIK

116

www.tankonyvtar.hu

10.2 Fibre Channel over IP – FCIP) (1) A Fibre Channel over IP jellemzői •

Gyakran Fibre Channel alagútnak vagy tároló alagútnak is nevezik.

•

Az FC információt az IP protokoll szállítja.

•

Olcsó megoldást kínál földrajzilag távol eső SAN hálózatok összekapcsolására.

•

Az FCIP a Fibre Channel adatblokkokat TCP szegmensekbe ágyazva továbbítja az IP hálózaton.

•

A TCP összeköttetés hivatott a távoli SAN rendszerek közötti kapcsolat megteremtésére.

•

A hálózati torlódások vezérlését és felügyeletét, valamint a hibakezelést a TCP/IP szolgáltatás végzi el, és nincs hatással az FC szolgáltatásra.

•

Az IP nem helyettesíti az FC-t, csak alagutat biztosít az FC hálózatok között.

•

Az IP-re kizárólag az olyan nagy távolságok áthidalása miatt van szükség, amely a jelenlegi FCP SAN technológia távolságkorlátját meghaladják.

•

Lényege: elosztott SAN szigetek összekapcsolása a meglévő IP infrastruktúra segítségével, miközben az eredeti FC kiszolgálást érintetlenül hagyja.

© Schubert Tamás, ÓE NIK

117

www.tankonyvtar.hu

10.2 Fibre Channel over IP – FCIP) (2) Az FCIP alagút protokoll szerkezete

FCIP átjáró

© Schubert Tamás, ÓE NIK

FCIP átjáró

118

www.tankonyvtar.hu

10.3 Internet Fibre Channel Protocol – iFCP

© Schubert Tamás, ÓE NIK

119

www.tankonyvtar.hu

10.3 Internet Fibre Channel Protocol – iFCP (1) Az Internet Fibre Channel Protocol (iFCP) jellemzői •

Adatokat visz át SAN-okban lévő Fibre Channel tárolókból és tárolókba a TCP/IP hálózaton keresztül.

•

Egyesít már létező SCSI és FC hálózatokat az internettel.

•

Az iFCP egy FCP-t irányító megoldás ellentétben az FCIP-vel, amely egy alagút technológiát használó megoldás.

•

A lényegi különbség a FCIP-hez képest, hogy az iFCP helyettesíti az FC alsó rétegbeli szállító protokollját a TCP/IP-vel és a Gigabit Ethernettel.

•

A Fibre Channel eszközök egy iFCP átjáróra vagy kapcsolóra csatlakoznak, és minden FC kapcsolat a helyi átjáróban végződik, majd az iFCP segítségével egy TCP/IP kapcsolattá alakul át.

•

A távoli átjáró vagy kapcsoló fogadja az iFCP kapcsolatot, majd FC kapcsolatot kezdeményez.

•

Az iFCP vonzereje, hogy azon felhasználók, akik sokféle FC eszközzel rendelkeznek, és ezeket az eszközöket az IP hálózatra szeretnék csatlakoztatni, az iFCP-vel megtehetik.

© Schubert Tamás, ÓE NIK

120

www.tankonyvtar.hu

10.3 Internet Fibre Channel Protocol – iFCP (2) Az iFCP protokoll szerkezete • Az FC-2 réteget IP-re cserélték.

© Schubert Tamás, ÓE NIK

121

www.tankonyvtar.hu

10.4 FCIP, iFCP vagy iSCSI?

© Schubert Tamás, ÓE NIK

122

www.tankonyvtar.hu

10.4 FCIP, iFCP vagy iSCSI? (1) A három IP alapú protokoll egymás mellett

© Schubert Tamás, ÓE NIK

123

www.tankonyvtar.hu

10.4 FCIP, iFCP vagy iSCSI? (2) IP technológiák néhány előnyös tulajdonsága •

A szervezeti egységek elszigeteltségének enyhítése.

•

Az erőforrás-megosztás megkönnyítése.

•

Új technológiára áttérés és integráció megkönnyítése.

•

Diszkrendszerek távoli replikációjának megkönnyítése.

•

Diszk és szalagos tárolók távoli elérése.

•

SAN-okhoz csatlakozás alacsony költséggel.

•

FC SAN-ok közti irányítás lehetővé tétele.

•

Távolságkorlátok eltűnése.

© Schubert Tamás, ÓE NIK

124

www.tankonyvtar.hu

11. Fibre Channel over Ethernet (FCoE)

© Schubert Tamás, ÓE NIK

125

www.tankonyvtar.hu

11. Fibre Channel over Ethernet (FCoE) (1) Az FCoE technológia jellemzői •

FC keretek továbbítása full duplex IEEE 802.3 (Ethernet) hálózaton.

•

Továbbítás 10 Gigabit kapcsolt Ethernet hálózaton megőrizve az FC protokollt.

•

Számos gyártó támogatja.

•

Az FCoE helyettesíti az FC0 és az FC1 réteget Ethernettel, de független marad az Ethernet továbbítási mechanizmusától.

© Schubert Tamás, ÓE NIK

126

www.tankonyvtar.hu

11. Fibre Channel over Ethernet (FCoE) (2) Az FCoE technológia jellemzői •

Megmarad az eredeti FC konstrukció, ezért tökéletesen összekapcsolható a létező FC hálózattal.

•

Tipikusan adatközponti alkalmazásra szánták, mivel az Ethernet nem irányítható protokoll.

•

Az FCoE nem használja az IP-t.

•

Ugyanakkor együtt tud működni a hagyományos Ethernet/IP forgalommal.

•

A hagyományos Ethernet az FC-vel ellentétben nem garantálja a kézbesítést (lossy).

•

Az IEEE Data Center Bridging Task Group dolgozik a veszteségmentes (loss-less) Ethernet szabványon. 3 alapvető követelmény: o

Native fibre channel keret beágyazása Ethernet keretbe,

o

veszteségmentes Ethernet kiterjesztés,

o

FC összeköttetés helyettesítése Ethernet MAC címekkel.

•

Az FCoE fabric FCoE kapcsolókból épül fel (kapcsolók Ethernet portokkal, FCoE képességgel: FC Forwarder – FCF).

•

Lehetnek hagyományos Ethernet kapcsolók is a hálózatban.

© Schubert Tamás, ÓE NIK

127

www.tankonyvtar.hu

11. Fibre Channel over Ethernet (FCoE) (3) Integrált Ethernet és FCoE kapcsoló FC csatlakozókkal • CEE: Converged Enhanced Ethernet. • Lossless Ethernet: o IEEE 802.3x (PAUSE), o Jumbo keret támogatása, o Priority-based flow control. Dummy

© Schubert Tamás, ÓE NIK

128

www.tankonyvtar.hu

11. Fibre Channel over Ethernet (FCoE) (4) Az FC keretek továbbítása

© Schubert Tamás, ÓE NIK

129

www.tankonyvtar.hu

11. Fibre Channel over Ethernet (FCoE) (5) FC kereteket veszteségmentes Ethernet továbbítja

© Schubert Tamás, ÓE NIK

130

www.tankonyvtar.hu

11. Fibre Channel over Ethernet (FCoE) (6) Egy modern tárolórendszer

© Schubert Tamás, ÓE NIK

131

www.tankonyvtar.hu

12. Network Access Storage (NAS)

© Schubert Tamás, ÓE NIK

132

www.tankonyvtar.hu

12. Network Access Storage (NAS) (1) A Network Access Storage jellemzői • • • • • • •

NAS hálózatra kapcsolódó számítógép, amelynek kizárólagos célja fájlszolgáltatás biztosítása más eszközök számára hálózaton keresztül. Tartalma: speciális vagy általános célú számítógép, diszkekkel vagy RAID alrendszerrel, operációs rendszer, egyéb szoftver. Funkciók: adattárolás, fájlrendszer, hozzáférésvezérlés fájlokhoz, menedzsment. Általában nincs egyéb szolgáltatás. Nincs billentyűzet és monitor. Hálózatról felügyelik gyakran HTTP protokollon keresztül. Fájlszerverektől különbözik: nincs egyéb szolgáltatás, fájl szolgáltatásra optimalizált.

© Schubert Tamás, ÓE NIK

133

www.tankonyvtar.hu

12. Network Access Storage (NAS) (2) Topológia

© Schubert Tamás, ÓE NIK

134

www.tankonyvtar.hu

12. Network Access Storage (NAS) (3) Topológia

IP hálózaton keresztül érhető el.

NAS átjárón keresztül a tárolást SAN biztosítja.

© Schubert Tamás, ÓE NIK

135

www.tankonyvtar.hu

12. Network Access Storage (NAS) (4) A Network Access Storage jellemzői (folytatás) •

Gyakran egy általános célú operációs rendszert „csontoznak ki” NAS célra. Pl.: o

FreeNAS (open source) a FreeBSD egy változata,

o

NASLite optimalizált Linux változat,

o

NexentaStor a NexentaOS-re épül (OpenSolaris kernel, Linux user interfész).

•

Tárolórendszer változtatása és kezelése lehetséges működő környezetben is.

•

A NAS tehermentesíti a többi szervert a fájlszolgáltatástól.

•

A NAS leggyakrabban az NFS-t (Network File System) és a CIFS-t (Common Internet File System) használja a fájlszolgáltatáshoz.

•

A NAS tárolást és fájlrendszert egyaránt biztosít (SAN csak blokk elérésű tárolást tesz lehetővé).

•

A NAS-t és a SAN-t gyakran együtt használják (SAN-NAS hibrid), a NAS a tároló funkciót a SAN-tól veszi igénybe.

•

A NAS és a SAN határvonal elmosódni látszik. Ugyanaz a készülék mindkét funkciót biztosítja: fájlszolgáltatást és blokkos tároló szolgáltatást. Pl.: Openfiler.

© Schubert Tamás, ÓE NIK

136

www.tankonyvtar.hu

12. Network Access Storage (NAS) (5) A NAS előnyei • Rendelkezésre állás növekedhet (RAID, egyéb redundancia, klaszter kialakítás). •

A kizárólagos tevékenység miatt nagyobb teljesítmény a fájlszerverekhez képest.

•

Nagy terhelés esetén speciális tervezés szükséges és alternatív adatútvonalak.

•

A tároló gazdaságosan kihasználható, egyszerűen bővíthető.

A NAS hátrányai •

Kisebb teljesítmény érhető el a DAS/FC rendszerekhez képest.

•

NAS nehezen upgrade-elhető.

•

Tükrözése nem hatékony (NFS-en és hálózaton keresztül).

© Schubert Tamás, ÓE NIK

137

www.tankonyvtar.hu

12. Network Access Storage (NAS) (6) A NAS felhasználása •

Alapszolgáltatás: központosított fájlszolgáltatás szerverek és ügyfelek számára.

•

Egyszerűbbé teszi az egyéb szolgáltatások biztosítását: o

terhelésmegosztás,

o

hibatűrő web és,

o

e-mail szolgáltatás.

•

Kis-, közép- és nagyvállalati szektorban is gazdaságosan használható.

•

Új a piaca a fogyasztói szegmensben nagy tömegű multimédia adatok tárolására.

•

Pl.: Buffalo TeraStation, Linksys NSLU2.

© Schubert Tamás, ÓE NIK

138

www.tankonyvtar.hu

12.1 Fájlrendszerek NAS és SAN környezetben

© Schubert Tamás, ÓE NIK

139

www.tankonyvtar.hu

12.1 Fájlrendszerek NAS és SAN környezetben (1) Fájlrendszerek feladatai, jellegzetességei • A fájlrendszerek általános feladata:

•

o

Elvégzik a fájlok és a fizikai blokkok összerendelését (File Allocation Table).

o

Nyilvántartják a szabad blokkokat.

o

Végrehajtják az alkalmazások olvasás/írás műveleteit.

o

Kezelik a könyvtárstruktúrát.

o

Kezelik a fájlgyorsítótárat (cache).

A hálózati tárolók fájlrendszereit és fájljait egyidejűleg több számítógépről is használják. Ilyen rendszerek pl.: o

Általános fájlkiszolgálók.

o

Klaszter technológia (használata növeli a teljesítményt, lehetővé teszi a hálózati terheléselosztást és nagyobb rendelkezésre állást biztosít).

•

Osztott fájlrendszerre (Shared File System) van szükség.

•

A fájlrendszernek biztosítania kell az adatok konzisztenciáját.

•

NAS esetén kizárólag a NAS szerver kezeli fájlrendszert és fér hozzá az adatblokkhoz. Az adat konzisztencia biztosított. Az alkalmazások a NAS szerverhez fordulnak fájladatokért a hálózaton keresztül.

© Schubert Tamás, ÓE NIK

140

www.tankonyvtar.hu

12.1 Fájlrendszerek NAS és SAN környezetben (2) Fájlkiszolgálás NAS környezetben

© Schubert Tamás, ÓE NIK

141

www.tankonyvtar.hu

12.1 Fájlrendszerek NAS és SAN környezetben (3) Fájlkiszolgálás SAN környezetben (Cluster File System) •

SAN esetén a hálózati eszközök közvetlenül elérik az adatblokkokat.

•

A SAN biztosítja a diszkek osztott elérését (Shared Disks), de önmagában nem biztosítja a fájlrendszer osztott elérését (Shared File System).

•

Az osztott fájlelérést az ún. klaszter fájlrendszernek (Cluster File System) kell biztosítania.

•

E nélkül sem a diszkterület allokációjának, sem a fájladatoknak a konzisztenciája nem biztosított.

•

Hagyományos fájlrendszer csak akkor használható, ha csak egy számítógép használja a fájlrendszert.

•

SAN esetén a hálózati eszközök közvetlenül elérik az adatblokkokat.

•

A klaszter fájlrendszer beágyazó (wrapper) fájlrendszert létesít a hagyományos fájlrendszer köré.

© Schubert Tamás, ÓE NIK

142

www.tankonyvtar.hu

12.1 Fájlrendszerek NAS és SAN környezetben (4) Fájlkiszolgálás SAN környezetben (Cluster File System) (folytatás) •

Az osztott fájlrendszert használó eszközök (szerverek/állomások) a hálózaton keresztül (FC, Ethernet/IP vagy speciális összeköttetés: cluster interconnect) kommunikálnak és szinkronizálják tevékenységüket.

•

Blokkolvasás: File1, Blokk5. o

•

Az alkalmazás a beágyazó fájlrendszerhez fordul, ez továbbítja a kérést a hagyományos fájlrendszerhez, amely kiolvassa az adatblokkot a SAN-on keresztül.

Blokkírás: File2, Blokk7. o

Az alkalmazás a beágyazó fájlrendszerhez fordul, ez a hálózaton keresztül értesíti a többi beágyazó fájlrendszert a változásról, amelyek törlik a blokkot a gyorsítótárukból.

o

A beágyazó fájlrendszer a hagyományos fájlrendszeren keresztül elvégzi az esetleges blokkallokációt.

o

Értesíti a többi szerver beágyazó fájlrendszerét az allokációs tábla módosulásáról.

o

A fájlrendszer elvégzi a blokk kiírását a diszkre a SAN-on keresztül.

© Schubert Tamás, ÓE NIK

143

www.tankonyvtar.hu

12.1 Fájlrendszerek NAS és SAN környezetben (5) Fájlkiszolgálás SAN környezetben (Cluster File System)

© Schubert Tamás, ÓE NIK

144

www.tankonyvtar.hu

12.1 Fájlrendszerek NAS és SAN környezetben (6) Példák klaszter fájlrendszerre

Klaszter fájlrendszer

Operációs rendszer

Tru64 Cluster 5.x

HP Tru64

VERITAS Cluster File System

Sun Solaris, HP/UX

Sun Cluster 3.0

Sun Solaris

Generalized Parallel File System IBM AIX, Linux (GPFS) DataPlow

Linux, Solaris, Windows, IRIX

PolyServe

Linux

GFS

Linux

NonStop Cluster

Unixware

© Schubert Tamás, ÓE NIK

145

www.tankonyvtar.hu

12.2 IBM Generalized Parallel File System (GPFS)

© Schubert Tamás, ÓE NIK

146

www.tankonyvtar.hu

12.2 IBM Generalized Parallel File System (GPFS) (1) A GPFS jellemzői •

IBM termék.

•

Használható AIX és Linux (Red Hat és SUSE Linux) klaszterekben, akár vegyesen is.

•

Nagy sebességű fájlelérés egyidejűleg több (ezer) eszközről.

•

Párhuzamos alkalmazások konkurensen olvashatják és írhatják ugyanazokat a fájlokat különböző csomópontokról.

•

A konzisztenciát bájt és blokk szintű zárolás, zárolásmenedzsment és naplózás biztosítja.

•

Grid rendszerekben is használható.

•

Fájlok elérése standard UNIX fájlrendszer interfészen keresztül.

•

Max. 256 fájlrendszer mountolható.

•

Tároló menedzsment szolgáltatás.

•

Information Life Cycle menedzsment.

•

Központosított adminisztráció.

•

High performance computing (HPC) támogatás.

© Schubert Tamás, ÓE NIK

147

www.tankonyvtar.hu

12.2 IBM Generalized Parallel File System (GPFS) (2) A GPFS adminisztrációja • Menedzselhető a klaszter bármelyik csomópontjáról. •

Fájlkvóta állítható.

•

Snapshot készíthető a GPFS fájlrendszerről egy adott időpontban. Ez lehetővé teszi a backup program és a rendes adatforgalom egyidejű használatát.

•

A GPFS fájlrendszer SNNP interfésszel rendelkezik, így hálózatmenedzsment eszközökkel is felügyelhető.

•

Támogatja a Data Management API (DMAPI) interfészt (az X/Open data storage management API IBM implementációja).

•

IBM Tivoli® Storage Manager (TSM) segítségével Hierarchical Storage Management (HSM) biztosítható.

•

Hozzáférésvezérlés:

•

o

Standard hozzáférési módok read (r), write (w) és execute (x) kiterjesztése a file owner, file group és other felhasználókon kívül további felhasználókra és csoportokra.

o

Új hozzáférési mód, a control (c) vezérli, hogy ki menedzselheti az ACL-eket.

o

A hagyományos ACL-en kívül a GPFS támogatja az NFS V4 ACL-t.

A GPFS fájlrendszer exportálható NFS-sel és Samba-val.

© Schubert Tamás, ÓE NIK

148

www.tankonyvtar.hu

12.2 IBM Generalized Parallel File System (GPFS) (3) Rendelkezésre állás • A GPFS hibatűrő rendszer. •

Támogatja az adatreplikációt.

•

Folyamatosan figyeli a fájlrendszer-komponensek működését.

•

Hiba esetén automatikusan helyreállítja a működést.

•

Kiterjedt naplózással és a helyreállító képességével biztosítja az adatok és metaadatok konzisztenciáját.

Information lifecycle management (ILM) • A tárolás (költség)hatékonyságának felügyelete policy által meghatározott automatizmussal. •

Több rétegű tárolás (Multi-tiered) menedzselése.

•

A tárolás költségének és az adatok értékének párosítása tárolókészletekkel (storage pool), fájlkészletekkel (fileset) és felhasználó által definiált policy-k segítségével.

•

Storage pool: belső/külső tárolók (storage menedzsment alkalmazás), diszkek (SATA/SCSI) szalag, stb. Csoportosítás: költség, elérés sebessége, megbízhatóság szerint.

•

Fileset: a fájlrendszer egy része (sub-tree).

© Schubert Tamás, ÓE NIK

149

www.tankonyvtar.hu

12.2 IBM Generalized Parallel File System (GPFS) (4) Information lifecycle management (ILM) (folytatás) • A tárolás helyét, és a különböző tárolókészletek közötti mozgatás módját a policy-kben megadott szabályok határozzák meg. •

Két policy típus létezik: o

Fájlelhelyezés (File placement) attribútumok (fájlnév, felhasználó, csoport vagy fileset) alapján meghatározza, hogy a fájl létrehozásakor milyen tárolóba kerüljön.

o

Fájlmenedzsment (File management) meghatározza, hogy a fájl struktúrabeli hely megváltoztatása nélkül a fájl milyen tárolóra kerüljön át. Attribútumok lehetnek: ua., mint a file placement + utolsó hozzáférés időpontja, a fájl mérete, felhasználó stb. Pl.: •

‘Törölni kell minden *.temp nevű fájlt, amelyet 180 napja nem használtak.’

•

‘Minden 2GB-nál nagyobb fájlt át kell mozgatni Poolt-re.’

•

‘XY 4GB-nál nagyobb fájljait a SATA storage pool-ba kell költöztetni. ’

o

Storage pool küszöbértékére (threshold) alapuló policy: pl. költöztetés 80% telitettség esetén.

o

A policy szabályok szintaxisa az SQL-re épül, és összetett szabályok alakíthatók ki.

© Schubert Tamás, ÓE NIK

150

www.tankonyvtar.hu

12.2 IBM Generalized Parallel File System (GPFS) (5) Klaszter konfigurációk: • SAN Attached Storage. •

Network block IO.

•

Sharing data between clusters: Multi-cluster.

SAN Attached Storage

© Schubert Tamás, ÓE NIK

151

www.tankonyvtar.hu

12.2 IBM Generalized Parallel File System (GPFS) (6) SAN Attached Storage • A szerverek kizárólag a tárolóhálózaton (pl. FC SAN) keresztül használják a tárolót. •

A vezérlőinformációk a LAN-on át haladnak a szerverek között.

•

Használata: nagy sebességet igénylő alkalmazások. A szerverek a fájl szolgáltatást NFS-en vagy Sambán keresztül biztosítják az ügyfélrendszerek számára.

•

Pl.: digitális média alkalmazások, grid infrastruktúra.

SAN Attached Storage

© Schubert Tamás, ÓE NIK

152

www.tankonyvtar.hu

12.2 IBM Generalized Parallel File System (GPFS) (7) Network block IO

© Schubert Tamás, ÓE NIK

153

www.tankonyvtar.hu

12.2 IBM Generalized Parallel File System (GPFS) (8) Network block IO •

Nem mindegyik csomópont csatlakozik a SAN-ra.

•

Ezek az eszközök a LAN-on keresztül érik el a blokkszolgáltatást a Network Shared Disk (NSD) interfész segítségével.

•

A fájlrendszer az ügyfelek számára az NSD szervereken keresztül érhető el.

•

Az adat- és vezérlőinformáció továbbítására a TCP/IP protokollt használja.

•

A LAN nem feltétlenül dedikált, de kellő sávszélességgel kell rendelkeznie.

•

A GPFS támogatja a 10 Gigabit Ethernet, a Myrinet és az InfiniBand protokollt.

•

A SAN Attached Storage és a Network block I/O közti választás a szükséges teljesítmény és költség kérdése.

•

Használata: grid rendszerek, Web alkalmazások.

© Schubert Tamás, ÓE NIK

154

www.tankonyvtar.hu

12.2 IBM Generalized Parallel File System (GPFS) (9) Sharing data between clusters: Multi-cluster

© Schubert Tamás, ÓE NIK

155

www.tankonyvtar.hu

12.2 IBM Generalized Parallel File System (GPFS) (10) Sharing data between clusters: Multi-cluster •

A fájlok megoszthatók a különböző klaszterek között is.

•

Ez nagyobb teljesítményt nyújt, mint az NFS és a Samba, de nem helyettesíti.

•

Az NFS és a Samba inkább a munkaállomásokat szolgálja ki, vagy kevésbé megbízható hálózati környezetben használják.

•

Használata: adatok megosztása különböző együttműködő csoportok között, pl. részlegek vagy telephelyek.

© Schubert Tamás, ÓE NIK

156

www.tankonyvtar.hu

13. IBM System Storage N Series – Gateway model

© Schubert Tamás, ÓE NIK

157

www.tankonyvtar.hu

13. IBM System Storage N Series – Gateway model (1)

© Schubert Tamás, ÓE NIK

158

www.tankonyvtar.hu

13. IBM System Storage N Series – Gateway model (2)

© Schubert Tamás, ÓE NIK

159

www.tankonyvtar.hu

13. IBM System Storage N Series – Gateway model (3) Jellemzők •

Hálózatalapú virtualizációs megoldás.

•

Képes virtualizálni heterogén típusú tárolótömböket.

•

Dinamikus virtualizációs képesség.

•

Data ONTAP mikrokernel operációs rendszere segítségével egyesített architektúrájával blokk- és fájlszolgáltatást nyújt.

•

Az N series Gateway úgy viselkedik, mint a SAN tömb egy állomása.

•

NAS, SAN vagy IP SAN adatelérés.

© Schubert Tamás, ÓE NIK

160

www.tankonyvtar.hu

13. IBM System Storage N Series – Gateway model (4) Heterogén SAN tömbök használata

© Schubert Tamás, ÓE NIK

161

www.tankonyvtar.hu

13. IBM System Storage N Series – Gateway model (5) Egyesített NAS – SAN topológia

© Schubert Tamás, ÓE NIK

162

www.tankonyvtar.hu

13. IBM System Storage N Series – Gateway model (6) Data ONTAP operációs rendszer •

Robosztus, multi-tasking, real-time micro-kernel.

•

Hasonlít a Unixhoz.

•

A Network Appliance Inc. Terméke.

•

Az ONTAP kernel komponensei: o

Network interface driver,

o

RAID manager,

o

Write Anywhere File Layout (WAFL) file system.

•

Saját parancskészlettel rendelkezik.

•

NTLM támogatás.

•

DES encryption.

•

Hozzáférés-szolgáltatás a kernelbe építve.

© Schubert Tamás, ÓE NIK

163

www.tankonyvtar.hu

13. IBM System Storage N Series – Gateway model (7) Data ONTAP operációs rendszer komponensei •

WAFL Protection RAID & Mirroring,

•

NVRAM menedzsment,

•

WAFL virtualizáció,

•

Snapshot menedzsment,

•

File Services,

•

Block Services,

•

Network layer,

•

Protocol layer,

•

System Administration.

© Schubert Tamás, ÓE NIK

164

www.tankonyvtar.hu

13. IBM System Storage N Series – Gateway model (8) Write Anywhere File Layout (WAFL) file system •

Gyors NFS szolgáltatás.

•

Nagy fájlrendszerek támogatása (N x 10 TB), amelyek dinamikusan növelhetők.

•

Nagy teljesítmény RAID támogatás mellett.

•

Gyors újraindulás áramkimaradás vagy rendszerösszeomlás esetén.

•

Hasonlít a UNIX fájlrendszerekre (Berkeley Fast File System (FFS) és TransArc Episode file system).

•

Blokk alapú tárolás, fájlok leírása inode segítségével.

•

4 KB méretű blokkok (töredékek nincsenek).

•

A metaadatokat fájlokban tárolja: o

•

az inode fájl tárolja az inodeokat a fájlrendszer számára,

o

a block-map fájl azonosítja a szabad blokkokat,

o

az inode-map fájl azonosítja a szabad inodeokat.

A metaadatok fájlokban való tárolása teszi lehetővé, hogy a diszkeken bárhova kerülhetnek. Ez növeli a hatékonyságot.

© Schubert Tamás, ÓE NIK

165

www.tankonyvtar.hu

14. Tárolóvirtualizáció – Storage Virtualization

© Schubert Tamás, ÓE NIK

166

www.tankonyvtar.hu

14. Tárolóvirtualizáció – Storage Virtualization (1) A tárolóvirtualizáció definíciója •

A tárolóvirtualizáció a fizikai tárolórendszer logikai absztrakciója.

•

Elrejti a fizikai tárolóeszközök bonyolultságát és speciális követelményeit a rendszerfelügyelet elől.

•

Megkönnyíti és költséghatékonnyá teszi a különböző típusú, elosztott tárolórendszerek adminisztrációját.

•

Eltávolítja a tárolórendszerek nézőpontját a fizikai szintről.

•

Célja: a költségek csökkentése az integritás és a teljesítmény csorbítása nélkül.

•

A Compaq’ Enterprise Network Storage Architecture (ENSA) kezdeményezés szerint: „A tárolásnak szolgáltatássá kell válnia, amely megbízhatóan és transzparensen a felhasználók rendelkezésére áll, és a háttérben professzionális eszközökkel és technológiákkal menedzselhető. Ez a diszkek nagy, konszolidált tömbökbe szervezésével, és a felhasználói alkalmazások virtuális diszkekkel való ellátásával érhető el.”

A különböző virtualizációs technológiák és megoldások között a SNIA modellje teremtett rendet. © Schubert Tamás, ÓE NIK

167

www.tankonyvtar.hu

14. Tárolóvirtualizáció – Storage Virtualization (2) A virtualizációs technológiák SNIA modellje

Disk Virtualization

© Schubert Tamás, ÓE NIK

168

www.tankonyvtar.hu

14. Tárolóvirtualizáció – Storage Virtualization (3) Mit virtualizálunk? • Diszk: cilinder, fej, szektor virtualizációja logikai blokk címekké (LBA). •

Blokk: elkülönült tárolók logikai blokkjai egyesített tárolóvá alakítható.

•

Szalagrendszer: szalagmeghajtók és szalagrendszerek közös szalagrendszerré alakítható.

•

Fájlrendszerek: teljes fájlrendszerek elosztott fájlrendszerré virtualizálhatók.

•

Fájl vagy rekord: fájlok vagy rekordok virtualizálhatók különböző köteteken.

Hol végezzük el a virtualizációt? • Állomás/szerver: a virtualizáció a számítógépen történik. •

Tárolórendszer: a virtualizáció a tárolórendszeren történik.

•

Hálózat: intelligens infrastruktúra (fabric) vagy SAN-csatolt hardver eszköz (appliance).

Hogyan végezzük el a virtualizációt? • In-band: a vezérlés és az adatútvonal azonos. •

Out-of-band: a vezérlés és az adatútvonal különbözik.

© Schubert Tamás, ÓE NIK

169

www.tankonyvtar.hu

14. Tárolóvirtualizáció – Storage Virtualization (4) Elvárások a virtualizációval szemben •

Automatizmus: bizonyos visszatérő feladatokat önműködően elvégez a rendszer. Pl.: további tárterület allokálása egy szerver számára, vagy a tárolóbővítés automatikus felismerése.

•

Irányelv alapú automatizmus: a rendszer felismeri, hogy az adatokat milyen rendelkezésre állású tárolóra kell tennie, mely adatokat kell olcsóbb tárolóra írnia, vagy mely adatokat kell replikálnia, stb. Több szintű infrastruktúra: kezeli a tárolási osztályokat. Irányelv alapján választ tárolási szintet.

•

Alkalmazástudatos virtualizáció: irányelv alapon dönt, hogy a különböző alkalmazástípusok adatait hol tárolja. Pl.: banki tranzakciók adatairól gyakran kell snapshotot készíteni, digitális videoadatokat megfelelő teljesítményű tárolóra kell írni.

•

Az alkalmazástudatos virtualizáció megfelelő kommunikációt tételez fel az alkalmazás és a tároló menedzsment között. Az alkalmazásnak tárolótudatosnak kell lennie.

© Schubert Tamás, ÓE NIK

170

www.tankonyvtar.hu

14. Tárolóvirtualizáció – Storage Virtualization (5) A teljesen automatizált tároló adminisztráció egymásra épülő rétegei

© Schubert Tamás, ÓE NIK

171

www.tankonyvtar.hu

14. Tárolóvirtualizáció – Storage Virtualization (6) Virtualizáció az állomáson/szerveren •

A logikai kötet menedzselését (LVM) a számítógép végzi.

•

Integrált része az operációs rendszernek vagy külön álló szoftver.

•

Az LVM kezelhet alternatív útvonalat a tároló eléréséhez.

•

A köteteket (LUN) minden állomás elszigetelten kezeli.

•

Megnehezíti a kötetek megosztását szerverek között (pl. klaszterezés).

•

Klaszterezéshez Clustered Volume Management szoftver szükséges, amely koordinálja az elosztott kötetkezelést.

•

Továbblépés a tároló metaadatszerver (Storage Metadata Server) bevezetése.

•

Elvégzi a logikai és a valós blokkcímek leképzését.

•

Egyfajta Out-of-band virtualizáció.

•

Megosztja a metaadatokat a szerverek között, lehetővé teszi a szerverklaszter használatát.

•

Ezen keresztül fájl szintű megosztás is készíthető.

•

A SAN blokk adatok elérése továbbra is a tárolóhálózaton keresztül történik.

•

A metaadatok elérése a LAN-on keresztül történik.

© Schubert Tamás, ÓE NIK

172

www.tankonyvtar.hu

14. Tárolóvirtualizáció – Storage Virtualization (7) Virtualizáció az állomáson/szerveren A metaadatszerver végzi a SAN blokkok leképzését a virtualizált kötet számára.

Tároló metaadatszerver

LAN SAN kapcsoló

Szerverek © Schubert Tamás, ÓE NIK

Tárolók 173

www.tankonyvtar.hu

14. Tárolóvirtualizáció – Storage Virtualization (8) Virtualizáció a tárolóban (Array-based virtualization) •

A tárolóvezérlők (storage controller) végzi el az elsődleges virtualizációt: RAID menedzsment, LUN mapping/masking.

•

A tárolóvezérlők által kezelt protokollok: FC, iSCSI, SCSI.

•

Nagyvállalati megvalósításokban FC a leggyakoribb.

•

A tárolóvezérlők egy-egy LUN-t több szerverhez is hozzárendelhetik. Pl. szerverklaszterezés.

•

A tárolótömbök használhatnak gyorsítótárakat a nagyobb teljesítmény elérésére.

•

A tárolók között koordinációra lehet szükség a magasabb rendelkezésre állás eléréséhez.

•

A tárolók közötti kommunikáció egyelőre nem szabványosított.

•

A rendszer szintű, tároló alapú virtualizációhoz a tárolóvezérlők koordinálják a blokkműveleteket a tömbök között.

© Schubert Tamás, ÓE NIK

174

www.tankonyvtar.hu

14. Tárolóvirtualizáció – Storage Virtualization (9) Virtualizáció a tárolóban

A

Tárolóvezérlő

SAN kapcsoló

B

Ports

Cache Processors

Device virtualization LUN 2

C

LUN 3 LUN 4 LUN 5

D

LUN 6 Diszk csoport

Szerverek © Schubert Tamás, ÓE NIK

175

www.tankonyvtar.hu

14. Tárolóvirtualizáció – Storage Virtualization (10) Virtualizáció a tárolóban Storage pool kialakítása – Rendszer szintű virtualizálás – tömbök közötti koordináció.

System virtualization System virtualization System virtualization Ports

Cache Processors

Ports

Cache Processors

Ports

Cache Processors

Device virtualization

Device virtualization

Device virtualization

Storage pool © Schubert Tamás, ÓE NIK

176

www.tankonyvtar.hu

14. Tárolóvirtualizáció – Storage Virtualization (11) Tárolótömb alapú adatreplikáció •

A tárolóvezérlőknek initiatorként és targetként is kell tudnia viselkedniük.

•

Szinkron replikáció esetén az adatfelírásnak be kell fejeződnie a másodlagos tárolón, mielőtt az elsődleges tároló nyugtázza a felírást a szervernek.

•

A szinkron replikációt legfeljebb LAN/MAN környezetben használják elfogadható teljesítmény mellett.

•

Az aszinkron replikáció estén az elsődleges tömb nyugtázza a felírást a szervernek, mielőtt az adat tárolása befejeződne a másodlagos tárolón.

•

Az aszinkron replikáció kevésbé érzékeny a hálózati késleltetésre.

•

Az írás tranzakciókat időbélyeggel látják el a pufferelt írások időrendjének megőrzése érdekében aszinkron replikáció esetén.

•

A szinkron és az aszinkron replikáció együttesen is használható.

© Schubert Tamás, ÓE NIK

177

www.tankonyvtar.hu

14. Tárolóvirtualizáció – Storage Virtualization (12)

LAN vagy WAN Szinkron array-to-array replikáció

secondary array

primary array

System virtualization

System virtualization

1

Ports Cache Processors

Device virtualization

Device virtualization

Tükrözés

Írás a primaryra Primary ír a secondaryra

2 3 4

Ports Cache Processors

Secondary nyugtázza a felírást Írás kész

© Schubert Tamás, ÓE NIK

178

www.tankonyvtar.hu

14. Tárolóvirtualizáció – Storage Virtualization (13)

LAN vagy WAN Aszinkron array-to-array replikáció

secondary array

primary array

System virtualization

System virtualization

1 2

Ports Cache Processors

Ports Cache Processors

Device virtualization

Device virtualization

Tükrözés

Írás a primaryra Írás kész

3 4 © Schubert Tamás, ÓE NIK

Primary ír a secondaryra Secondary nyugtázza a felírást 179

www.tankonyvtar.hu

14. Tárolóvirtualizáció – Storage Virtualization (14) Elosztott, moduláris, tömb alapú virtualizáció •

A tárolóvezérlőt leválasztják a tárolótömbről.

•

Ez nagyobb rugalmasságot biztosít heterogén diszktömbök együttes használatára.

•

Osztott a virtualizáció intelligencia.

•

Alkalmas a tárolási osztályok (class of storage) kezelésére és az adatok felügyeletére a teljes életciklusuk idején (Information Lifecycle Management – ILM).

•

A tárolóvezérlő leválasztása a tárolótömbről előrevetíti a hálózatalapú virtualizáció kialakítását.

© Schubert Tamás, ÓE NIK

180

www.tankonyvtar.hu

14. Tárolóvirtualizáció – Storage Virtualization (15) Storage controller leválasztva a tárolótömbről iSCSI szerverek FC szerverek SAN kapcsoló

Storage controller

Drive bays

LAN/WAN

Storage controller

Drive bays

Drive bays

Storage controller

Drive bays

Serial ATA Fibre Channel

Serial ATA

Serial SCSI

SCSI

Storage pool © Schubert Tamás, ÓE NIK

181

www.tankonyvtar.hu

14. Tárolóvirtualizáció – Storage Virtualization (16) Hálózat alapú virtualizáció (Fabric-based virtualization) Érzékelő/érző (sentient) SAN •

A tárolóhálózat intelligens szolgáltatásokkal ellensúlyozza a tárolók relatíve passzív mivoltát.

•

Az FC architektúra intelligens szolgáltatásai: o

bejelentkezés,

o

egyszerű név szolgáltatás,

o

változások hirdetése,

o

hálózati címek hozzárendelése,

o

zónázás,

o

LUN mapping/masking.

•

A fabric-based virtualizáció lényegében a fabric architektúra intelligens szolgáltatásainak a kiterjesztése.

•

A fabric kapcsolók valósítják meg az összeköttetést az összes tranzakció számára, és biztosítják az együttműködést az elosztott szerverek és a tárolók (targets) között.

•

A fabric-based virtualizációnak együtt kell működnie a host alapú, a tároló alapú és a célberendezés (appliance) alapú virtualizáló eszközökkel.

© Schubert Tamás, ÓE NIK

182

www.tankonyvtar.hu

14. Tárolóvirtualizáció – Storage Virtualization (17) Hálózat alapú virtualizáció (Fabric-based virtualization) Érzékelő/érző (sentient) SAN •

A fabric-based virtualizáció megvalósítható a kapcsolókon vagy ún. directorokon.

•

A director alapú eszközök magas rendelkezésre állást (five nines) biztosítanak.

•

A virtualizáció PC alapú blade-del vagy ASIC-hardver elemekkel is megvalósítható a directorokban.

•

A magas rendelkezésre állás biztosítható elosztott fabric-based virtualizációval, ahol a virtuális térképeket elosztják és szinkronizálják az intelligens kapcsolók között.

•

Az ANSI/INCITS T11.5 task group a Fabric Application Interface Standard (FAIS) keretében egy API-t dolgozott ki, amely megkönnyíti az állomás-, tároló-, célberendezés (appliance) és fabric alapú virtualizációs összetevők együttműködését akár különböző gyártók között is.

© Schubert Tamás, ÓE NIK

183

www.tankonyvtar.hu

Irodalom (1) [1]: Gary Orenstein: IP Storage Networking: Straight to the Core, Addison Wesley, 2003. [2]: Rekha Singhal, Zia Saquib: Continuous Available Commodity Storage, SNIA Education, 2008. [3]: Tom Clark: Storage Virtualization, Technologies for Simplifying Data Storage and Management, Addison-Wesley, 2005. [4]: Scott Fadden: An Introduction to GPFS Version 3.2, IBM Corporation, 2007. [5]: Scott Fadden: The next step forward in storage virtualization: IBM General Parallel File System (GPFS) and IBM TotalStorage SAN File System (SFS) Come Together, IBM Corporation, 2007. [6]: Alex Osuna, Chrisanthy Carlane, Bruce Clarke, Prashanta Kumar Goswami, Kurt Kiefer, Jinsu Kim, Silvio Martins: IBM System Storage N series, RedBooks, 2007. [7]: Jon Tate, Fabiano Lucchese, Richard Moore: Introduction to Storage Area Networks, RedBooks, 2006. [8]: John L. Hufferd: Fibre Channel over Ethernet (FCoE), SNIA Education, 2008.

© Schubert Tamás, ÓE NIK

184

www.tankonyvtar.hu

Irodalom (2) [9]: Richard Austin: Saving Private Data, An Introduction to Storage Security, SNIA Education, 2008. [10]:Rob Peglar: Storage Virtualization II., Effective Use of Virtualization, SNIA Education, 2008. [11]:Mark S Fleming: High Availability Using Fault Tolerance in the SAN, SNIA Education, 2008.

© Schubert Tamás, ÓE NIK

185

www.tankonyvtar.hu

Adatközpontok Penge szerverek Blade servers

Schubert Tamás

© Schubert Tamás, ÓE NIK

186

www.tankonyvtar.hu

Tartalom 1. 2. 3. 4.

Szervermegoldások Rack-mount szerverek Blade szerverek IBM BladeCenter Irodalom

© Schubert Tamás, ÓE NIK

187

www.tankonyvtar.hu

1. Szervermegoldások

© Schubert Tamás, ÓE NIK

188

www.tankonyvtar.hu

1. Szervermegoldások (1) Az utóbbi évtized szervermegoldásai és technológiái •

Kezdetben önmagában álló PC, amely fájlmegosztást tett lehetővé egy munkacsoport vagy egy szervezeti egység alkalmazásai számára.

•

A szerverek száma, típusa és az alkalmazások száma megsokszorozódott.

•

Ma az üzletileg kritikus internet, intranet, extranet, ERP, elektronikus kereskedelem, biztonságtechnikai és egyéb alkalmazások számtalan különböző típusú szerveren futnak, és mindtől elvárják, hogy a nap 24 órájában és az év 365 napján hibátlanul működjenek.

•

Sok vállalat és szolgáltató előnyben részesíti az olcsó, kisebb teljesítményű szervereket.

•

Ezek jobban méretezhetők az alkalmazások feldolgozóteljesítményigényének növekedésével, mint néhány nagy teljesítményű szerver.

•

Ez a megoldás további előnyökkel is jár, mint például a nagyobb hibatűrő képesség, és rendelkezésre állás, amely abból fakad, hogy majd minden feladatra minden szervezeti egységben dedikált szervert alkalmaznak.

•

A szerverek számának növekedése együtt jár a nagyobb területigénnyel.

© Schubert Tamás, ÓE NIK

189

www.tankonyvtar.hu

1. Szervermegoldások (2) Az utóbbi évtized szervermegoldásai és technológiái (folytatás) •

A kifejlesztett rack-mount és blade szerverek azt a célt szolgálják, hogy a mai adatközpontok és szerverszobák rendelkezésre álló területét minél gazdaságosabban használják ki.

•

A rack-mount szerverek jó néhány éve piacon vannak, és oly mértékben fejlődtek, hogy azon a területen, ahol korábban csak néhány hagyományos szerver fért el, akár néhány száz szerver is elhelyezhető.

•

A blade szerverek ezt a számot még tízzel megszorozzák, de e rendszerek szabványosítása és felügyelhetősége újabb kihívások elé állítja a gyártókat és az alkalmazókat.

© Schubert Tamás, ÓE NIK

190

www.tankonyvtar.hu

2. Rack-mount szerverek

© Schubert Tamás, ÓE NIK

191

www.tankonyvtar.hu

2. Rack-mount szerverek (1) A rack-mount szerverek jellemzői •

A rack-mount szervereket speciális szabványoknak (Electronic Industries Association – EIA) megfelelően tervezik, amely lehetővé teszi, hogy szabványosított rack szekrényekbe, egyiket a másik fölé lehessen építeni.

•

A legtöbb esetben mindegyik szerver 19 hüvelyk széles, a magassága pedig a szabványos „U” egységméret egész számú többszöröse (1 U=1,75 hüvelyk).

•

Egy 1 U szerver mintegy 1,75” magasságú, illetve annyival kisebb, hogy az egymás fölé helyezett szerverek között a levegőáramlás biztosítva legyen. Ennek megfelelően a 2 U szerver 3,5”, a 8 U szerver pedig 14” magas.

•

A szabványos rack szekrények számos magasságméretben kaphatók, hogy a legkülönbözőbb igényeknek megfeleljenek. A rack szekrények befogadják a szervereket, tároló berendezéseket, hálózati eszközöket, és gondoskodnak az eszközök tápellátásáról és hűtéséről.

© Schubert Tamás, ÓE NIK

192

www.tankonyvtar.hu

2. Rack-mount szerverek (2) A Rack-mount szerverek jellemzői (folytatás) •

Az utóbbi évtizedben olyan rackbe építhető kompakt szerverek jöttek divatba, amelyek mindössze 1 U vagy 2 U magasságúak, ennek ellenére jelentős teljesítményt nyújtanak.

•

Egy-két processzorral, több GB memóriával, 2–3 PCI csatlakozóval, redundáns hűtőventillátorral és tápegységgel a megfelelő hibatűrés biztosítására, és 2–3 diszk férőhellyel rendelkeznek.

•

A nagyobb vállalatok előszeretettel alkalmazzák e kompakt szervereket, mivel kis helyigényűek, nagy teljesítményűek, a feldolgozásigény növekedésével új szerverek építhetők be anélkül, hogy a helyigény növekedne.

•

Olyan kiszolgáló alkalmazások, amelyek terhelésmegosztással működnek, könnyen méretezhetők új szerverek beállításával, amint a terhelés növekszik.

•

Több gyártó is készít olyan nagy teljesítményű szervereket, amelyek 8–16 processzorral, memória, I/O és tároló bővítési lehetőséggel rendelkeznek.

© Schubert Tamás, ÓE NIK

193

www.tankonyvtar.hu

2. Rack-mount szerverek (3) A Rack-mount szerverek jellemzői (folytatás) •

Egy tipikus rack-konfiguráció az alábbi eszközöket tartalmazhatja: o

Több, rackbe építhető szerver, mindegyik saját processzorokkal, memóriával, háttértárolóval és tápegységgel.

o

Egy vagy több váltakozó áramelosztó egység, amelyek biztosítják a szerverek áramellátását.

o

Egy konzol, amely magában foglalja a videomonitort, a billentyűzetet, egeret és egy konzolkapcsolót, amely lehetővé teszi, hogy a konzol (monitor, billentyűzet, egér) bármelyik szerverhez hozzárendelhető legyen.

o

Sínek és egyéb rögzítő elemek, amelyekkel a szerverek karbantartás céljából ki-be csúsztathatók.

o

Kábelrögzítő elemek.

o

Szünetmentes áramforrások (UPS), amelyek áramkimaradás esetén is biztosítják az ideiglenes működést.

© Schubert Tamás, ÓE NIK

194

www.tankonyvtar.hu

2. Rack-mount szerverek (4) A Rack-mount szerverek jellemzői (folytatás) •

Sok rack szerver konfigurációban a tárolók a szerverektől elkülönítve RAID tornyokban vagy SAN-okban helyezkednek el egyetlen nagy tárolóterületet alkotva, amely könnyen hozzárendelhető a tárolót igénylő alkalmazáshoz.

•

A rack szekrényekhez gyakran kaphatók olyan kiegészítő szerelvények, amelyekkel az ilyen különálló berendezések a rackbe illeszthetők.

•

Mihelyt a szerverek sokasodnak a rack szekrényben, az általa kínált és a rendelkezésre álló magasabb szintű menedzsmentszolgáltatások egyre fontosabbá válnak.

•

A szervergyártók számtalan menedzsmentszolgáltatást kínálnak a termékeikhez, mint például teljesítménymonitorozás, hardverhibaelőrejelzés, riasztás küszöbértékek elérésekor, eseménynaplózás, tevékenységnaplózás, hardver- és szoftverleltár.

•

Gyakran lehetőség van arra, hogy a rendszergazda betárcsázzon, és a szükséges beavatkozásokat elvégezze, mint például BIOS frissítés, szoftvertelepítés stb.

© Schubert Tamás, ÓE NIK

195

www.tankonyvtar.hu

3. Blade szerverek

© Schubert Tamás, ÓE NIK

196

www.tankonyvtar.hu

2. Blade szerverek (1) A blade szerverek jellemzői •

A rack szerverek alkalmazása lehetővé teszi, hogy sok szervert viszonylag kis területen helyezzünk el.

•

De egy újabb típusú szerver a blade (penge) szerver a rendelkezésre álló helyet még jobban kihasználja, még több szerverkapacitás zsúfolható össze ugyanakkora területen.

•

A blade szerverek kis méretű, függőlegesen álló modulok, amelyek processzorokat, chip-seteket, memóriát és viszonylag kis háttértárolót tartalmaznak, és rack keretben helyezkednek el más szerverekkel együtt, hasonlóan a könyvekhez a könyvespolcon.

•

Ahelyett, hogy minden szerver saját hálózati csatlakozóval, tápegységgel és kábelezéssel rendelkezne, a blade szerverek nagy sebességű rack hátlaphoz csatlakoznak, amely közös áramforráshoz, hűtőrendszerhez és hálózati csatolóhoz illeszti őket.

•

Néha a szerverek valamekkora tárolóval is rendelkeznek, de leggyakrabban a tároló külön helyezkedik el RAID, NAS vagy SAN megoldást használva.

© Schubert Tamás, ÓE NIK

197

www.tankonyvtar.hu

2. Blade szerverek (2) Az IBM BladeCenter H elölnézeti képe

© Schubert Tamás, ÓE NIK

198

www.tankonyvtar.hu

2. Blade szerverek (3) HP BladeSystem c7000 szerverrekesz

© Schubert Tamás, ÓE NIK

199

www.tankonyvtar.hu

2. Blade szerverek (4) A blade szerverek jellemzői (folytatás) •

A blade szerverek ma már néhány éves múltra tekintenek vissza, több generációjuk is megjelent a piacon.

•

A nagy számítógépgyártók mindegyike kínál blade szervereket.

•

Az egyes gyártók azonban különböző, egymással versengő szabványokat alkalmaznak a termékeikben, ezáltal lehetetlen az egyes rendszerelemeket különböző gyártóktól beszerezni.

•

Például nem lehetséges az IBM BladeCenter-ben HP blade szerverek használata.

•

A szabványosítás lassan halad, az együttműködésre inkább az jellemző, hogy a nagy gyártók konzorciumot alapítanak kisebb gyártókkal, hogy azok kiegészítő eszközöket gyárthassanak.

© Schubert Tamás, ÓE NIK

200

www.tankonyvtar.hu

2. Blade szerverek (5) A blade szerverek jellemzői (folytatás) •

A függőlegesen álló blade szerverek magassága 2 U és 13 U között van, és fél vagy teljes rack mélységű.

•

A legkisebb mérettel számolva egy 42 U magas rackben akár 150 szerver is elhelyezhető. A nagy sebességű hátlap, az osztott tápellátás, és Ethernet nagyon leegyszerűsíti a kábelezést, csökkenti a tápellátás és a hűtéskialakítás költségét. Gyakran kis fogyasztású processzorokat használnak a blade szerverekben, hogy csökkentsék a szerverek energiaigényét.

•

A legtöbb bladeszerver-konfiguráció megengedi a hibás szerverek cseréjét vagy új szerverek hozzáadását anélkül, hogy az egész rendszert le kellene állítani.

•

A blade menedzsment szoftverek automatizálják az eredeti alkalmazások újra installálását. Dedikált blade szerver kiegészítők is működés közben csatlakoztathatók, eltávolíthatók és percek alatt konfigurálhatók.

© Schubert Tamás, ÓE NIK

201

www.tankonyvtar.hu

2. Blade szerverek (6) A blade szerverek jellemzői (folytatás) •

A blade szerverek újabb szolgáltatása az ún. CPU provisioning, amely lehetővé teszi, hogy rugalmasan CPU teljesítményt rendeljünk az egyes alkalmazásokhoz, hasonlóan ahhoz, ahogyan a SAN-ok és a tároló virtualizációs szoftver képes dinamikusan tárolót rendelni az egyes alkalmazásokhoz.

•

Ez a képesség különösen olyan alkalmazások esetén fontos, mint amilyen az elektronikus kereskedelem vagy az üzenetkezelés, amelyek a napszak vagy évszak függvényében nagyon változó teljesítményt igényelnek.

•

Összefoglalva a rackbe épített szerverek és a blade szerverek helytakarékosan képesek ellátni egy fejlődő vállalat igényeit. Szinte minden vállalatméretre lehet megfelelő eszközöket találni, és a kiszolgálórendszer együtt növekedhet a növekvő feldolgozás igénnyel.

© Schubert Tamás, ÓE NIK

202

www.tankonyvtar.hu

2. Blade szerverek (7) Szerverkonszolidáció •

Egyszerű, moduláris felépítésű, kis hely és áramfelvétel igényű, könnyen bővíthető és felügyelhető eszközpark.

•

Az üzemeltetésre fordított kiadások drasztikus csökkenése.

•

2006-ban az eladott blade eszközök több mint 90%-át az IBM, a HewlettPackard, a Dell Computer és a Sun Microsystems gyártotta.

•

Ezen belül az IBM 40%-kal, a HP pedig 35%-kal részesedik.

© Schubert Tamás, ÓE NIK

203

www.tankonyvtar.hu

4. IBM BladeCenter

© Schubert Tamás, ÓE NIK

204

www.tankonyvtar.hu

4. IBM BladeCenter (1) IBM BladeCenter sasszék •

IBM BladeCenter E: legkisebbre zsugorított megoldás, leggyakrabban használt rendszerkomponensek, legalacsonyabb költség.

•

IBM BladeCenter H: nagy teljesítmény és megbízhatóság, nagyfokú rugalmasság, a legigényesebb IT környezetben is használható.

•

IBM BladeCenter T: telekommunikációs hálózati infrastruktúrához tervezték, mostoha környezetben is használható.

•

IBM BladeCenter HT: nagy teljesítményű, rugalmas telekommunikációs környezetben való alkalmazásra tervezték. Nagy sebességű internettechnológiák (10 G Ethernet).

•

IBM BladeCenter S: ötvözi a blade szerver teljesítményét a beépített tárolóval. Elsősorban irodai és elosztott vállalati környezetre tervezték.

© Schubert Tamás, ÓE NIK

205

www.tankonyvtar.hu

4. IBM BladeCenter (2) IBM BladeCenter szerverválaszték •

HS sorozat: Intel Xeon processzor.

•

LS sorozat: AMD Opteron processzor.

•

JS sorozat: IBM Power processzor.

•

QS sorozat: IBM Cell Broadband Engine (Cell/B.E.) processzor.

© Schubert Tamás, ÓE NIK

206

www.tankonyvtar.hu

4. IBM BladeCenter (3) IBM BladeCenter szerverválaszték (folytatás)

© Schubert Tamás, ÓE NIK

207

www.tankonyvtar.hu

4. IBM BladeCenter (4) IBM BladeCenter szerverválaszték (folytatás)

© Schubert Tamás, ÓE NIK

208

www.tankonyvtar.hu

4. IBM BladeCenter (5) IBM BladeCenter szerverválaszték (folytatás)

© Schubert Tamás, ÓE NIK

209

www.tankonyvtar.hu

4. IBM BladeCenter (6) IBM BladeCenter szerverválaszték (folytatás)

© Schubert Tamás, ÓE NIK

210

www.tankonyvtar.hu

4. IBM BladeCenter (7) IBM BladeCenter szerverválaszték (folytatás)

© Schubert Tamás, ÓE NIK

211

www.tankonyvtar.hu

4. IBM BladeCenter (8) IBM BladeCenter szerverválaszték (folytatás)

© Schubert Tamás, ÓE NIK

212

www.tankonyvtar.hu

4. IBM BladeCenter (9) Blade szerverek és sasszék lehetséges párosítása

© Schubert Tamás, ÓE NIK

213

www.tankonyvtar.hu

4. IBM BladeCenter (10) Az IBM BladeCenter H •

2002-ben jelentették be, azóta piacvezető.

•

Nagyfokú integráltság, menedzsmentszolgáltatás.

•

IBM blade szerverek, kommunikációs eszközök, tároló hálózati kapcsolók alkotják.

•

A blade vagy penge szerver egy vékony áramköri lap, amelyen a memória, processzorok, merevlemezek és egyéb kiegészítő kártyák modulárisan helyezhetőek el.

•

A penge szervereket magában foglaló 7 U magas keret (chassis) minden alkotórészében – a szervereket a különböző egységekhez kapcsoló buszrendszer (midplane), tápellátás, menedzsment modul, konzol, hálózati és tároló hálózati kapcsolatok – redundáns.

•

Magas üzembiztonság, rendelkezésre állás, az integrálható hálózati és tároló hálózati kapcsolók minimális külső kábelfelhasználást tesznek szükségessé.

© Schubert Tamás, ÓE NIK

214

www.tankonyvtar.hu

4. IBM BladeCenter (11) Az IBM BladeCenter H elölnézeti képe

© Schubert Tamás, ÓE NIK

215

www.tankonyvtar.hu

4. IBM BladeCenter (12) Az IBM BladeCenter H sematikus elölnézeti képe

© Schubert Tamás, ÓE NIK

216

www.tankonyvtar.hu

4. IBM BladeCenter (13) Az IBM BladeCenter H elölnézeti képe

© Schubert Tamás, ÓE NIK

217

www.tankonyvtar.hu

4. IBM BladeCenter (14) Az IBM BladeCenter H •

Elölről 14 penge szerver csatlakoztatható.

•

A Media Tray ad helyet a CD/DVD meghajtónak, USB portnak és információs panelnek.

•

A keretbe hátulról illeszthető négy kommunikációs és tároló hálózati (SAN) kapcsolómodul, redundáns párt alkotó két felügyeleti, négy táp- és két nagy hatásfokú ventillátor modul.

•

A keret közepén található az a redundáns buszrendszer (midplane), amely a szerverek, kapcsolók, tápellátás, felügyeleti eszközök között biztosítja a kommunikációt.

© Schubert Tamás, ÓE NIK

218

www.tankonyvtar.hu

4. IBM BladeCenter (15) Media Tray

© Schubert Tamás, ÓE NIK

219

www.tankonyvtar.hu

4. IBM BladeCenter (16) Az IBM BladeCenter H hátulnézeti képe

© Schubert Tamás, ÓE NIK

220

www.tankonyvtar.hu

4. IBM BladeCenter (17) Az IBM BladeCenter H hátulnézeti képe

© Schubert Tamás, ÓE NIK

221

www.tankonyvtar.hu

4. IBM BladeCenter (18) Az IBM BladeCenter – Midplane

© Schubert Tamás, ÓE NIK

222

www.tankonyvtar.hu

4. IBM BladeCenter (19) Az IBM BladeCenter – Midplane •

Nagy sebességű blade-to-blade, blade-to-switch-module és module-tomodule kommunikáció a BladeCenteren belül és kívül.

•

A midplane 4 10 GB sebességű adatcsatornát biztosít minden blade szerver számára, és támogatja a 4X InfiniBand és a 10 GB Ethernet kapcsolómodulokat.

© Schubert Tamás, ÓE NIK

223

www.tankonyvtar.hu

4. IBM BladeCenter (20) Az IBM BladeCenter® HS21 blade server elölnézeti képe

© Schubert Tamás, ÓE NIK

224

www.tankonyvtar.hu

4. IBM BladeCenter (21) Az IBM BladeCenter® HS21 blade server belső nézete

© Schubert Tamás, ÓE NIK

225

www.tankonyvtar.hu

4. IBM BladeCenter (22) Az IBM BladeCenter® HS21 XM blade server belső nézete (XM – Extended memory)

© Schubert Tamás, ÓE NIK

226

www.tankonyvtar.hu

4. IBM BladeCenter (23) Az IBM BladeCenter® HS21 XM blade server jellemzői (XM – Extended memory)

© Schubert Tamás, ÓE NIK

227

www.tankonyvtar.hu

4. IBM BladeCenter (24) Az IBM BladeCenter® HS21 XM blade server modellek összehasonlítása

© Schubert Tamás, ÓE NIK

228

www.tankonyvtar.hu

4. IBM BladeCenter (25) Az IBM BladeCenter® HS21 XM blade server modellek összehasonlítása

© Schubert Tamás, ÓE NIK

229

www.tankonyvtar.hu

4. IBM BladeCenter (26) Az IBM BladeCenter® HS21 blade server •

Penge magassága: 5 U.

•

Szélessége: 30 mm.

•

Két, legújabb fejlesztésű, nagy teljesítményű quad- vagy dual-core Intel® Xeon® processzor.

•

A Xeon processzorok 4 MB vagy 6 MB (dual-core), illetve 8 MB vagy 12 MB (quad-core) L2 gyorsítótárral rendelkeznek.

•

A front-side bus (FSB) 1066 MHz vagy 1333 MHz.

•

64 bit extensions (EM64T).

•

Memória: legfeljebb 32 GB, 667 MHz PC2-5300 Fully Buffered ECC (Error Checking and Correcting) double data rate II (DDR2) 8 DIMM slot, opcionális Chipkill™ védelem.

© Schubert Tamás, ÓE NIK

230

www.tankonyvtar.hu

4. IBM BladeCenter (27) Az IBM BladeCenter® HS21 blade server •

Integrált dual Gigabit Ethernet vezérlő, TOE (TCP Offload Engine) támogatás, terhelésmegosztás, redundancia.

•

A Memory and I/O Expansion Unit 2 további Gigabit Ethernet vezérlővel rendelkezik (TOE támogatás nélkül).

•

Opcionálisan beépíthető bővítő kártyák segítségével a blade szerverek Ethernet, Myrinet, Fibre Channel, iSCSI, InfiniBand™ és más nagy sebességű kommunikációs kapcsolókhoz csatlakozhatnak a keretben.

•

Opcionális 2 portos bővítő kártyák (Expansion Cards) segítségével további hálózati infrastruktúra (fabric) hozható létre a keretben (max. 10 kapcsoló vagy híd).

•

Ez helymegtakarítással is jár az adatközpontban, és csökkenti a kábelezési költséget.

•

Power management képesség: növekvő hőterhelés esetén a szerver teljes leállása helyett a HS21 automatikusan csökkenti a processzor frekvenciát, hogy csökkenjen a teljesítményigény.

© Schubert Tamás, ÓE NIK

231

www.tankonyvtar.hu

4. IBM BladeCenter (28) Az IBM BladeCenter® HS21 blade server •

1 vagy 2 SAS meghajtó (RAID-0 vagy RAID-1), vagy

•

2 SATA 15.8 GB / 31.4 GB Solid State Drives (SSD).

•

Opcionális 30 mm Storage and I/O Expansion Unit segítségével 3 2.5” SAS HDD csatlakoztatható (hot-swap support, opcionális RAID-5, batterybacked cache).

•

Diszk nélküli megoldás: Fibre Channel vagy iSCSI SAN használata.

15.8 GB Dual Solid State Drive (SSD)

© Schubert Tamás, ÓE NIK

232

www.tankonyvtar.hu

4. IBM BladeCenter (29) A BladeCenter menedzselhetősége •

A Baseboard Management Controller (BMC) segítségével monitorozza a szerver elérhetőségét availability, prediktív Failure Analysis-t végez és riasztást küld az IBM Directornak.

•

Az Advanced Management Module további rendszerfelügyeleti szolgáltatásokat nyújt: Web-based out-of-band control; virtual floppy és CDROM támogatás; Windows „blue screen” error capture; LDAP és SSL támogatás; és videó, szöveg, billentyűzet és egér távoli átirányítása.

•

Az IPMI 2.0 integrált ipari szabvány támogatás együttműködik a BMC-vel, hogy riasztást küldjön az IBM Directornak a szerver rendellenességeiről, pl.: feszültség, hőmérséklet. Nagy biztonságú távoli teljesítményvezérlést is támogat.

•

Konkurens Keyboard-Video-Mouse – KVM (cKVM) és konkurens media (cMedia) elérés egyidejűleg több rendszergazda részére.

© Schubert Tamás, ÓE NIK

233

www.tankonyvtar.hu

4. IBM BladeCenter (30) A BladeCenter menedzselhetősége •

Az IBM Director a BladeCenterrel együtt szállított menedzsment alkalmazás.

•

Együttműködik a szerver BMC-vel és a sasszé (keret) menedzsment moduljával.

•

Szolgáltatásai: o o o o o o

IBM Systems Director Active Energy Manager for x86, Management Processor Assistant, RAID Manager, Update Assistant, Software Distribution, rendszergazda riasztása.

© Schubert Tamás, ÓE NIK

234

www.tankonyvtar.hu

4. IBM BladeCenter (31) Az IBM BladeCenter® HS21 blade server jellemzőinek összefoglalása

© Schubert Tamás, ÓE NIK

235

www.tankonyvtar.hu

4. IBM BladeCenter (32) Az IBM BladeCenter® HS21 blade server jellemzőinek összefoglalása

© Schubert Tamás, ÓE NIK

236

www.tankonyvtar.hu

4. IBM BladeCenter (33) Az IBM BladeCenter® HS21 blade server jellemzőinek összefoglalása

© Schubert Tamás, ÓE NIK

237

www.tankonyvtar.hu

4. IBM BladeCenter (34) A BladeCenter hálózati integrációja •

A következő ábrán látható, beépíthető kapcsoló modulok közül lehet választani (ESM = Ethernet Switch Modul – típusfüggetlen elnevezés).

•

Ún. pass-thru modulok használata esetén a blade szerverek közvetlenül összekapcsolhatók a külvilággal.

•

A beépített kapcsolók egyszerűsítik a kábelezést, ezért ezt érdemes használni.

•

Az IBM Server Connectivity Modul 6 külső porttal (hálózat felé) és 14 belső porttal rendelkezik (blade szerverek felé).

•

Az egyes ESM típusok jelentősen eltérő szolgáltatásokkal rendelkeznek. Legjellemzőbb szolgáltatások: o

Spanning Tree Protocol (STP),

o

Trunk Failover with NIC Teaming,

o

Virtual Router Redundancy Protocol (VRRP),

o

Routing Protocol (RIP vagy OSPF).

© Schubert Tamás, ÓE NIK

238

www.tankonyvtar.hu

4. IBM BladeCenter (35) A BladeCenter hálózati integrációja – kapcsolómodul választása

© Schubert Tamás, ÓE NIK

239

www.tankonyvtar.hu

4. IBM BladeCenter (36) A BladeCenter hálózati integrációja – Redundáns hálózati topológia

A linkaggregáció redundanciát és terhelésmegosztást biztosít.

Ethernet Switch Modul A linkaggregáció redundanciát és terhelésmegosztást biztosít. Az alternatív útvonalak nagyobb redundanciát nyújtanak. A Spanning Tree engedélyezése szükséges a hurkok elkerülésére. Az IBM Server Connectivity Modul ebben a konfigurációban nem használható. © Schubert Tamás, ÓE NIK

240

www.tankonyvtar.hu

4. IBM BladeCenter (37) A BladeCenter tároló integráció •

A külső tároló használatának lehetőségei: o

Directly attached SAS storage,

o

iSCSI technológiára épülő Storage area networks (SAN),

o

Fibre Channel technológiára épülő SAN,

o

InfiniBand technológiára épülő tárolás natív InfiniBand interfésszel vagy közvetetten InifiniBand-to-Fibre Channel híd segítségével.

© Schubert Tamás, ÓE NIK

241

www.tankonyvtar.hu

4. IBM BladeCenter (38) BladeCenter SAN modulok összehasonlító táblázata

© Schubert Tamás, ÓE NIK

242

www.tankonyvtar.hu

4. IBM BladeCenter (39) BladeCenter SAN infrastruktúra topológia

© Schubert Tamás, ÓE NIK

243

www.tankonyvtar.hu

4. IBM BladeCenter (40) A Bladecenter és hálózat többi részének kapcsolódása – példa

BladeCenter H keret Management kártya

10.0.2.36 10.0.2.39 10.0.2.40

10.0.2.41

Blade01

FC1 FC2

Belső kommunikációs busz 2

NIC2

Belső kommunikációs busz 1

NIC1

FC switch 1 HP Procurve switch

FC switch 2

Ethernet switch 1

Ethernet switch 2 10.0.2.37 10.0.2.38 FC1a FC1b

FC2a FC2b

NIC1

NIC2

IBM DS3400 SAN Storage

© Schubert Tamás, ÓE NIK

244

www.tankonyvtar.hu

Irodalom (1) [1]: David Watts, Randall Davis, Ilia Kroutov: IBM BladeCenter, Products and Technology, RedBooks, 2008.

© Schubert Tamás, ÓE NIK

245

www.tankonyvtar.hu

Adatközpontok Virtualizáció

Schubert Tamás

© Schubert Tamás, ÓE NIK

246

www.tankonyvtar.hu

Tartalom 1.

Bevezetés 1.1 Definíció 1.2 A virtualizáció fajtái 1.3 Virtuális gép – Platformvirtualizáció 1.4 A platformvirtualizáció létrejöttének okai 1.5 Virtuális gép – Alkalmazásvirtualizáció 1.6 Desktop-virtualizáció 1.7 Virtualizáció megvalósítások 2. x86 virtualizáció 2.1 CPU virtualizáció 2.2 Memóriavirtualizáció 2.3 Eszközvirtualizáció 3. VMware workstation Irodalom

© Schubert Tamás, ÓE NIK

247

www.tankonyvtar.hu

1. Bevezetés

© Schubert Tamás, ÓE NIK

248

www.tankonyvtar.hu

1.1 Definíció

© Schubert Tamás, ÓE NIK

249

www.tankonyvtar.hu

1.1 Definíció (1) Definíció •

Virtualization is a framework or methodology of dividing the resources of a computer into multiple execution environments, by applying one or more concepts or technologies such as hardware and software partitioning, timesharing, partial or complete machine simulation, emulation, quality of service, and many others.

© Schubert Tamás, ÓE NIK

250

www.tankonyvtar.hu

1.2 A virtualizáció fajtái

© Schubert Tamás, ÓE NIK

251

www.tankonyvtar.hu

1.2 A virtualizáció fajtái (1) A virtualizáció a számítógépi erőforrások absztrakciója •

Virtual machine (VM): egy számítógép szoftver megvalósítása, amely a valós számítógéphez hasonlóan hajtja végre a programokat. o

Platform virtualization: a számítógépes platform erőforrásainak és a rajta futó operációs rendszer elkülönítése.

o

Application virtualization: egyedi alkalmazások futtatása idegen hardver/szoftver környezetben.

•

Storage virtualization: absztrakt logikai tároló kialakítása tetszőleges, akár heterogén, elosztott fizikai tárolókörnyezetben.

•

Memory virtualization: Hálózati környezetben rendelkezésre álló RAM tárak aggregálása virtuális memória tömbbe (pl.: RNAcache).

•

Network virtualization: virtuális hálózati címtartomány létrehozása fizikai hálózati szegmenseken keresztül.

•

Desktop virtualization: asztali számítógépek távoli használata/menedzselése.

•

Database virtualization: elválasztja az alkalmazási réteget és a tárolási réteget, amellyel rugalmasabbá válik az adatok fizikai tárolása anélkül, hogy az alkalmazásokat érintené.

•

Virtual Chargeback: a virtuális erőforrás használat költségének felhasználókhoz, alkalmazásokhoz rendelése.

© Schubert Tamás, ÓE NIK

252

www.tankonyvtar.hu

1.3 Virtuális gép – Platformvirtualizáció

© Schubert Tamás, ÓE NIK

253

www.tankonyvtar.hu

1.3 Virtuális gép – Platformvirtualizáció (1) Virtual machine (VM) •

Egy számítógép szoftver megvalósítása (pseudo machine), amely a valós számítógéphez hasonlóan hajtja végre a programokat.

Platform virtualization (hardvervirtualizáció, szervervirtualizáció) •

Egy számítógép vagy operációs rendszer virtualizációja, amely elrejti az eredeti hardver tulajdonságait, és absztrakt számítógépi platformot hoz létre.

•

Kell lennie vezérlő programnak a számítógépen, amely létrehozza és felügyeli a szimulált számítógépi környezetet, a virtuális gépet a vendég szoftver számára (guest software).

•

A vendég szoftver lehet alkalmazás és teljes operációs rendszer.

•

A vendég szoftver bizonyos megszorításokkal úgy fut, mintha a fizikai gépen futna.

•

A megszorítások általában a fizikai erőforrásokra vonatkoznak: hálózatelérés, billentyűzet, display, diszktároló, processzor, memória.

•

A vendég szoftver gyakran korlátozva van a perifériák használatát illetően, vagy csak szűkített funkcionalitással használhatja őket.

© Schubert Tamás, ÓE NIK

254

www.tankonyvtar.hu

1.4 A platformvirtualizáció létrejöttének okai

© Schubert Tamás, ÓE NIK

255

www.tankonyvtar.hu

1.4 A platformvirtualizáció létrejöttének okai (1) A virtualizáció okai •

Szerverkonszolidáció: sok kis szerver helyett nagy teljesítményű szervereket állítottak be, hogy növeljék a kihasználást és csökkentsék a költségeket.

•

Az operációs rendszert azonban nem konszolidálták (nem telepítenek túl sok alkalmazást egy-egy szerverre).

•

A korábban alkalmazott kis teljesítményű szervereket különálló operációs rendszerekké konvertálják a virtuális gépeken belül.

•

A nagy szerverek sok vendég virtuális gépet fogadnak be.: fizikai -> virtuális transzformáció (P2V).

•

A virtuális gépek egyszerűbben felügyelhetők mint a fizikai gépek.

•

Rugalmasabban konfigurálhatók.

•

Jól alkalmazható kernel fejlesztéskor vagy oktatásra.

•

A virtuális gépek könnyen telepíthetők, mozgathatók/másolhatók egyik hardverről a másikra anélkül, hogy a fizikai gépet mozgatni kellene.

•

A virtuális gépen bekövetkező hiba nincs hatással a befogadó gépre és a többi vendég gépre.

•

A virtuális gépek könnyű mozgathatósága miatt jól alkalmazható disaster recovery műveletekben.

© Schubert Tamás, ÓE NIK

256

www.tankonyvtar.hu

1.5 Virtuális gép – Alkalmazásvirtualizáció

© Schubert Tamás, ÓE NIK

257

www.tankonyvtar.hu

1.5 Virtuális gép – Alkalmazásvirtualizáció (1) Az alkalmazásvirtualizáció jellemzői (Application virtualization) •

Olyan szoftvertechnológiák, amelyek az alkalmazásokat beágyazzák az eredeti operációs rendszer környezetükbe, amelyeken végrehajthatók.

•

Egy az alkalmazást és a környezetét befoglaló csomag készül, amely lehetővé teszi a hordozhatóságot, a könnyű kezelhetőséget, és a kompatibilitást.

•

A virtualizált alkalmazást nem kell installálni, hanem úgy, ahogy van futtatni lehet.

•

Az alkalmazás be van csapva. Végrehajtáskor azt hiszi, hogy az eredeti operációs rendszer alatt, az eredeti környezetében fut.

•

Az alkalmazásvirtualizációhoz virtualizációs rétegre van szükség.

© Schubert Tamás, ÓE NIK

258

www.tankonyvtar.hu

1.5 Virtuális gép – Alkalmazásvirtualizáció (2) Az alkalmazásvirtualizáció jellemzői (folytatás) •

Ez a réteg részben helyettesíti az operációs rendszer futtató környezetét (runtime environment).

•

Érzékeli a virtualizált alkalmazás összes fájl és Registry műveletét, és láthatatlanul átirányítja őket egy virtualizált helyre (esetleg egyetlen fájlba).

•

Az alkalmazás nem érzékeli, hogy virtualizált erőforrásokkal tart kapcsolatot.

•

Mivel az alkalmazás egyetlen fájllal dolgozik, könnyen átvihető más rendszerre is.

•

Windowsalkalmazás-virtualizáló technológiák: o

Ceedo,

o

InstallFree,

o

Citrix XenApp,

o

Novell ZENworks Application Virtualization,

o

Endeavors Technologies Application Jukebox,

o

Microsoft Application Virtualization,

o

Software Virtualization Solution,

o

VMware ThinApp.

© Schubert Tamás, ÓE NIK

259

www.tankonyvtar.hu

1.5 Virtuális gép – Alkalmazásvirtualizáció (3) Az alkalmazásvirtualizáció előnyei •

Megengedi, hogy az alkalmazásokat olyan környezetben futtassuk, amely nem felel meg az eredeti környezetének (pl. a Wine lehetővé teszi Windows alkalmazások futtatását Linuxon).

•

Védi az operációs rendszert és más alkalmazásokat a hibás kódoktól.

•

Kevesebb erőforrásra van szüksége, mint egy virtuális gépnek.

•

Egymással nem kompatibilis alkalmazások futtatása együtt.

•

Standard konfigurációk alkalmazása a futtató számítógépeken függetlenül az alkalmazásoktól (költségcsökkentés, egyszerűsítés).

•

A gyengén megírt alkalmazások esetén is lehetséges a lehető legkevesebb jogosultság elv (principle of least privilege) érvényesítése. Nem kell Administrator jogosultságot adni a végfelhasználóknak.

•

Az operációs rendszerek migrációja egyszerűbb.

•

Az alkalmazások terjesztése egyszerűbb (application streaming).

•

Növekvő biztonság: az alkalmazások elszigetelődnek az operációs rendszertől.

© Schubert Tamás, ÓE NIK

260

www.tankonyvtar.hu

1.5 Virtuális gép – Alkalmazásvirtualizáció (4) Az alkalmazásvirtualizáció előnyei (folytatás) •

A licencek követése egyszerűbb a vállalatok számára.

•

Nincs szükség az alkalmazások installálására, hordozható médián is átvihető az ügyfél számítógépére.

Az alkalmazásvirtualizáció korlátai •

Nem minden szoftver virtualizálható.

•

Az operációs rendszerhez erősen kötődő alkalmazásokat vagy a vírusirtó programokat nehéz virtualizálni.

•

Csak a fájl és Registry szintű kompatibilitást igénylő alkalmazások kezelhetők virtualizációval a régebbi és az újabb operációs rendszerek között.

© Schubert Tamás, ÓE NIK

261

www.tankonyvtar.hu

1.6 Desktop-virtualizáció

© Schubert Tamás, ÓE NIK

262

www.tankonyvtar.hu

1.6 Desktop-virtualizáció (1) Desktop virtualization: asztali számítógépek távoli használata/menedzselése •

A személyi számítógép környezetének leválasztása a fizikai számítógépről.

•

A virtualizált desktop központi szerveren fut: operációs rendszer, folyamatok, alkalmazások, adatok.

•

A felhasználói interfészt elláthatja: személyi számítógép, notebook, smartphone, vékony kliens.

•

A kapcsolat a desktop és a felhasználó ügyfél berendezése között ügyfélszerver architektúrát követ.

•

A virtual desktop infrastructure (VDI) az a modell, amely a biztosítja a virtualizált környezethez szükséges hardver és szoftver infrastruktúrát. o

A technológia egyszerű alkalmazása a remote administration távoli asztal használatával.

o

A legfontosabb alkalmazás, amikor a virtualizációhoz egy szerver erőforrásait használjuk, és minden távoli ügyfél saját virtuális desktoppal rendelkezik.

© Schubert Tamás, ÓE NIK

263

www.tankonyvtar.hu

1.6 Desktop-virtualizáció (2) A desktop virtualization előnyei •

Új desktop létesítése egyszerű és gyors.

•

Szerver- vagy ügyfélhiba esetén gyors regenerálhatóság.

•

Az új alkalmazások központi telepítése kis költséggel jár.

•

A desktop image-ek központi menedzsmentje egyszerű.

•

Ritkábban szükséges az ügyfél hardver cseréje.

•

Biztonságos kapcsolat az ügyfél készülék és a virtuális desktop között.

•

A Total Cost of Ownership (TCO) alacsonyabb, mint fizikai desktop környezetben.

© Schubert Tamás, ÓE NIK

264

www.tankonyvtar.hu

1.6 Desktop-virtualizáció (3) A desktop virtualization hátrányai •

Biztonsági kockázat nem megfelelően konfigurált hálózat esetén.

•

A felhasználó önállósága és adatainak titkossága csorbulhat.

•

Bizonyos perifériák meghajtóinak telepítése nehézségbe ütközhet.

•

Összetett alkalmazások (pl. multimédia) távoli használata nehézséget okozhat.

•

Hálózat leállás esetén – esetleg több felhasználót is érintő – hosszabb állásidő.

•

A virtual desktop infrastructure (VDI) telepítése és felügyelete bonyolult és költséges.

•

A beruházás megtérülési ideje tág határok között változik.

© Schubert Tamás, ÓE NIK

265

www.tankonyvtar.hu

1.6 Desktop-virtualizáció (4) Fontosabb gyártók és termékek •

Citrix ( XenDesktop),

•

VMware (VMware View),

•

Microsoft (Remote Desktop Services, a Terminal Services utódja),

•

Paralells (Parallels Virtual Desktop Infrastructure).

© Schubert Tamás, ÓE NIK

266

www.tankonyvtar.hu

1.7 Virtualizáció megvalósítások

© Schubert Tamás, ÓE NIK

267

www.tankonyvtar.hu

1.7 Virtualizáció megvalósítások (1) Name

Creator

Host CPU

Guest CPU

Windows 2008 w/Hyper-V Role, Windows Hyper-V Server

x64 + hardwareassisted x64,x86 virtualization (Intel VT or AMD-V)

Hyper-V

Microsoft

KVM

Intel/AMD processor with X86 same as Qumranet [4] virtualization,IA64,s platform 390,PowerPC

Parallels Parallels, Inc. x86, Intel VT-x Workstation

QEMU

Fabrice Bellard helped by other developers

Sun xVM Server

Sun x86-64, SPARC Microsystems

© Schubert Tamás, ÓE NIK

Host OS(s)

x86

x86, AMD64, x86, AMD64, IA-64, ARM, SPARC PowerPC, Alpha, 32 and 64, SPARC 32 and 64, PowerPC, ARM, S/390, M68k MIPS (Same as host) 268

Guest OS(s) License Supported Drivers for Windows 2000, Windows 2003, Windows 2008, Proprietary Windows XP, Windows Vista, Linux (SUSE 10 Released, More Announced))

Linux

Linux, Windows, FreeBSD, Solaris

Windows, Linux

Windows, Linux, FreeBSD, OS/2, Proprietary eComStation, MS-DOS, Solaris

Windows, Linux, Mac OS X, Solaris, Changes regularly [6] FreeBSD, OpenBSD, BeOS no host OS

Windows XP & 2003 Server (x86-64 only), Linux, Solaris

GPL version 2

GPL/LGPL

GPL version 3

www.tankonyvtar.hu

1.7 Virtualizáció megvalósítások (2) Name

Virtual PC 2007

Windows Virtual PC

Creator

VMware ESX Server

Guest CPU

License

x86, x86-64

Microsoft

x86, x86-64 with Intel VT or AMD-V

x86

Windows 7

Windows XP SP3, Windows Vista, Windows 7

Intel x86, AMD64

Intel x86

Windows 2003, XP

Windows NT, 2000, 2003, Proprietary Linux (Red Hat and SUSE)

x86, IA-64, AMD64

Linux, Windows

Linux, Windows

SWsoft, now x86, IA-64, AMD64 Parallels, Inc.

VMware

© Schubert Tamás, ÓE NIK

x86, x86-64

x86

Host OS(s) Guest OS(s) Windows Vista (Business, DOS, Windows, OS/2, Enterprise, Linux(Suse, Xubuntu), Ultimate), XP OpenSolaris(Belenix) Pro, XP Tablet PC Edition

Microsoft

Virtual Server Microsoft 2005 R2

Virtuozzo

Host CPU

x86, x86-64 no host OS

269

Proprietary

Proprietary

Proprietary

Windows, Linux, Solaris, FreeBSD, Virtual appliances, Netware, Proprietary OS/2, SCO, BeOS, Darwin, others: runs Arbitrary OS[2] www.tankonyvtar.hu

1.7 Virtualizáció megvalósítások (3) Name

Creator

Host CPU

Guest CPU

Host OS(s)

Guest OS(s)

License

VMware ESXi VMware

x86, x86-64

x86, x86-64

no host OS

Same as VMware ESX Server

Proprietary

VMware Server

VMware

x86, x86-64

x86, x86-64

Windows, Linux

Same as VMware ESX Server

Proprietary

VMware Workstation 6.0

VMware

x86, x86-64

x86, x86-64

Windows, Linux

Same as VMware ESX Server

Proprietary

VMware Player 2.0

VMware

x86, x86-64

x86, x86-64

Windows, Linux

Same as VMware ESX Server

Proprietary

© Schubert Tamás, ÓE NIK

270

www.tankonyvtar.hu

2. x86 virtualizáció

© Schubert Tamás, ÓE NIK

271

www.tankonyvtar.hu

2. x86 virtualizáció (1) Az x86 virtualizáció jellemzői •

Az x86 processzorokat használó számítógépek esetén a hardver és a vendég operációs rendszerek közé virtualizációs réteg ékelődik be.

•

Ez a réteg teszi lehetővé, hogy virtuális számítógépen futó operációs rendszerek konkurensen fussanak egy fizikai gépen.

•

A virtuális gépek osztoznak a fizikai gép erőforrásaiban: CPU, RAM, tároló, I/O eszközök.

x86 virtualizációs réteg (Vmware)

© Schubert Tamás, ÓE NIK

272

www.tankonyvtar.hu

2. x86 virtualizáció (2) Az x86 virtualizáció architektúrái •

•

Hosted (befogadó) o

A virtualizáló réteg a befogadó operációs rendszer alkalmazásaként fut.

o

Számos hardvertípuson megvalósítható.

o

Megvalósítások: VMware Player, Workstation és Server.

Hypervisor o

A virtualizáló réteg közvetlenül a hardveren fut.

o

Sokkal hatékonyabb, jobban méretezhető, robosztusabb mint a hosted architektúra.

o

Megvalósítások: VMware ESX Server (adatközpontokban használják).

© Schubert Tamás, ÓE NIK

273

www.tankonyvtar.hu

2. x86 virtualizáció (3) A hypervisor architektúra •

A hypervisor funkciói architektúra és megvalósítás függő.

•

A Virtual Machine Monitor (VMM) a hypervisor felett fut.

•

A VMM absztrakt virtuális gépet implementál, és a vendég operációs rendszer futtatásáért felelős.

•

Megosztja és virtualizálja a hardver erőforrásokat (CPU, RAM, I/O eszközök) a virtuális gépek között.

•

A hypervisor felügyeli a Virtual Machine Monitorokat (VMM), amelyek magukban foglalják a virtuális gépeket.

© Schubert Tamás, ÓE NIK

274

www.tankonyvtar.hu

2.1 CPU virtualizáció

© Schubert Tamás, ÓE NIK

275

www.tankonyvtar.hu

2.1 CPU virtualizáció (1) A CPU virtualizáció jellemzői •

Az x86 processzor architektúra 4 privilégium szintet (ring) biztosít az operációs rendszerek, a perifériális berendezések és az alkalmazások számára.

•

Az egyes privilégium szintek korlátozzák az egyes utasítástípusok végrehajtását, ezzel védve az operációs rendszert az alkalmazásoktól és az alkalmazásokat egymástól.

•

Az operációs rendszerek a 0. szinten futnak, a teljes számítógépet birtokolják. Csak a 0. szinten lehet a teljes számítógépet vezérlő (pl. szegmensregiszterek tartalmának megváltoztatása, közvetlen memóriahozzáférés) utasításokat kiadni.

•

A virtualizációhoz a virtualizációs rétegnek magasabb prioritási szinttel kell futnia, mint az operációs rendszereknek a virtuális gépek létrehozásához és menedzseléséhez.

•

További probléma, hogy léteznek olyan utasítások is, amelyeknek a szemantikája attól függően, hogy melyik szinten hajtják végre más és más.

© Schubert Tamás, ÓE NIK

276

x86 privilégium szintek virtualizáció nélkül

www.tankonyvtar.hu

2.1 CPU virtualizáció (2) A CPU virtualizáció jellemzői (folytatás) •

A megoldandó feladat: o

Az operációs rendszerek által végrehajtott privilegizált utasítások futás közbeni elfogása és átadása az alattuk futó virtualizácós rétegnek.

o

Ezeket az utasításokat kell helyettesíteni olyan műveletsorral, amely transzparens módon elvégzi az erőforrások virtualizációját (saját Bios, memóriamenedzsment, perifériakezelés, stb.).

•

A virtualizáció technikája nincs szabványosítva.

•

Három technikát alkalmaznak (néha vegyesen is) a virtualizáció megvalósítására: o

teljes virtualizáció (Full Virtualization),

o

operációs rendszer által támogatott virtualizáció (OS Assisted Virtualization vagy Paravirtualization),

o

hardver által támogatott virtualizáció (Hardware Assisted Virtualization).

© Schubert Tamás, ÓE NIK

277

www.tankonyvtar.hu

2.1 CPU virtualizáció (3) Teljes virtualizáció bináris fordítással (Full Virtualization using Binary Translation) – VMware megoldás •

A bináris fordítás és a közvetlen végrehajtás kombinációja: o

A kernel kódot lefordítja, és a nem virtualizálható utasításokat helyettesíti egy új utasítássorozattal, amely a virtuális hardverre vonatkozik.

o

A felhasználói program kódjai közvetlenül lesznek végrehajtva a processzoron a nagyobb teljesítmény elérése érdekében.

•

A virtuális monitorok (VMM) minden virtuális gép számára biztosítják a fizikai géptől igényelt erőforrásokat (virtuális BIOS virtuális eszközök és virtuális memóriamenedzsment).

•

A virtualizációs réteg teljesen elválasztja virtuális OR-eket a fizikai hardvertől.

•

A virtuális OR-ek nem tudnak a virtualizálásról, nem kell módosítani őket.

© Schubert Tamás, ÓE NIK

278

Bináris fordítás az x86 virtualizációhoz

www.tankonyvtar.hu

2.1 CPU virtualizáció (4) Teljes virtualizáció bináris fordítással (Full Virtualization using Binary Translation) – VMware megoldás •

A virtualizáláshoz – ez esetben – nincs szükség hardvertámogatásra.

•

A hypervisor röptében (on the fly) fordítja a privilegizált utasításokat, majd cache-eli a gyorsabb végrehajtás érdekében.

•

A felhasználói szintű utasításokat a processzor közvetlenül hajtja végre.

•

A teljes virtualizáció biztosítja a virtuális gépek legteljesebb elszigetelését és biztonságát.

•

Az operációs rendszerek migrálása és áttelepítése egyszerű egyik környezetből a másikba.

•

Példák a teljes virtualizációra: o

Vmware változatok,

o

Microsoft Virtual Server.

© Schubert Tamás, ÓE NIK

279

www.tankonyvtar.hu

2.1 CPU virtualizáció (5) Operációs rendszer által támogatott virtualizáció (OS Assisted Virtualization vagy paravirtualization) •

A paravirtualizáció a vendég OS és a Hypervisor közti kommunikációra utal.

•

A vendég OS kernelt módosítani kell, hogy a nem virtualizálható (privilegizált) utasításokat ún. hypercall-lal helyettesítsék, amely kapcsolatot teremt az alatta lévő hypervisorral.

•

A hypervisor hypercall interfészt biztosít az olyan kritikus kernel funkciókhoz is, mint pl. a memóriamenedzsment vagy a megszakításkezelés.

Paravirtualizáció az x86 virtualizációhoz

© Schubert Tamás, ÓE NIK

280

www.tankonyvtar.hu

2.1 CPU virtualizáció (6) Operációs rendszer által támogatott virtualizáció (OS Assisted Virtualization vagy paravirtualization) •

A paravirtualizáció abban különbözik a teljes virtualizációtól, hogy a kernelt módosítani kell.

•

A virtualizációs többletterhelés (overhead) kisebb, mint a teljes virtualizáció esetén (bár ez erősen terhelés függő).

•

Az operációs rendszerek kompatibilitása gyenge, mivel környezetfüggő (hypervisor).

•

Az operációs rendszerek hordozhatósága szintén gyenge.

•

A paravirtualizált OS-ek támogatása körülményes.

•

Példa a paravirtualizációra: Xen.

•

A Vmware termékek a VMware toolban használ paravirtualizált megoldást optimalizált eszközmeghajtókhoz, időszinkronizáláshoz, naplózáshoz vagy a vendég OS leállításához. Ezek a megoldások a kernelt nem érintik, a vendég OS-ben installált meghajtókról van szó.

© Schubert Tamás, ÓE NIK

281

www.tankonyvtar.hu

2.1 CPU virtualizáció (7) Hardver által támogatott virtualizáció (Hardware Assisted Virtualization HAV) •

A processzorokban olyan új megoldásokra van szükség, amelyek támogatják a virtualizációt.

•

Jelenleg első generációs megoldások léteznek:

•

o

Intel Virtualization Technology (VT-x),

o

AMD’s AMD-V.

Mindkét megoldásban új végrehajtási üzemmódot hoztak létre a Ring 0 alatt: Root mode.

Hardver támogatás az x86 virtualizációhoz

© Schubert Tamás, ÓE NIK

282

www.tankonyvtar.hu

2.1 CPU virtualizáció (8) Hardver által támogatott virtualizáció (Hardware Assisted Virtualization HAV) •

Az érzékeny és a privilegizált utasítások ún. trapet (csapdát) váltanak ki a hypervisorban.

•

Emiatt nincs szükség sem bináris fordításra, sem pedig paravirtualizációra.

•

A vendég OS állapotát hardver adatstruktúrában tárolják: o

Intel: Virtual Machine Control Structures (VT-x),

o

AMD: Virtual Machine Control Blocks (AMD-V).

•

2006-tól elérhető opció a processzorokban.

•

Ezt az első generációs hardvertámogatást túl merevnek tartják a fejlesztők.

•

Jelenleg a VMware csak az Intel 64 bites processzorai esetén veszi igénybe a hardvertámogatást.

© Schubert Tamás, ÓE NIK

283

www.tankonyvtar.hu

2.1 CPU virtualizáció (9) Az x86 CPU virtualizációs technikák összehasonlítása Teljes virtualizáció bináris fordítással

Hardver által támogatott virtualizáció

Operációs rendszer által támogatott virtualizáció (paravirtualizáció)

Technika

Bináris fordítás és közvetlen végrehajtás.

Privilegizált utasítások esetén Root módba lép.

Hypercall.

Vendég módosítás/ kompatibilitás

Vendég OS nem módosul, kiváló kompatibilitás.

Vendég OS nem módosul, kiváló kompatibilitás.

Vendég OS Hypercallokat vált ki, nem fut más hypervisoron, gyenge kompatibilitás.

Teljesítmény

Jó

Elfogadható. Még hátrányban van a BT-hez képest.

Bizonyos esetekben jobb.

Gyártó

VMware, Microsoft, Paralells

VMware, Microsoft, Paralells, Xen

VMware, Xen

Vendég OS/ hypervisor független

Igen

Igen

Nem

© Schubert Tamás, ÓE NIK

284

www.tankonyvtar.hu

2.2 Memóriavirtualizáció

© Schubert Tamás, ÓE NIK

285

www.tankonyvtar.hu

2.2 Memóriavirtualizáció (1) A memóriavirtualizáció jellemzői •

A memóriavirtualizáció feladata a rendszermemória megosztása és dinamikus hozzárendelése a virtuális gépekhez.

•

A memóriavirtualizációt az Intel x86 processzorok hardveresen támogatják, és az egyetlen operációs rendszert használó rendszerekben is évtizedek óta alkalmazzák.

•

A modern operációs rendszerekben az alkalmazások összefüggő címtartományt alkotnak, de ezek általában nem összefüggőek a fizikai tárolóban.

•

Ennek okai, hogy az összes futó alkalmazás memóriaszükséglete és a tényleges memória mérete között nagy különbség van, a memóriaszükséglet állandóan változik, és a programokat a fizikai memória bármelyik címtartományába be kell tudni tölteni.

© Schubert Tamás, ÓE NIK

286

www.tankonyvtar.hu

2.2 Memóriavirtualizáció (2) A memóriavirtualizáció jellemzői (folytatás) •

Az alkalmazások által éppen nem használt memóriablokkokat a diszkre lapozzák ki, és szükség szerint töltik be, illetve cserélik ki.

•

A virtuális memória és a fizikai memória között leképzéshez két mechanizmust használnak (külön-külön, és együtt is): o

szegmentálás,

o

lapozás.

© Schubert Tamás, ÓE NIK

287

www.tankonyvtar.hu

2.2 Memóriavirtualizáció (3) A memóriavirtualizáció jellemzői (folytatás) •

A szegmentálás megvalósításához a processzorok és operációs rendszerek szegmens- és laptáblázatokat használnak: http://prog.hu/cikkek/843/A+memoria+kezelese.html

© Schubert Tamás, ÓE NIK

288

www.tankonyvtar.hu

2.2 Memóriavirtualizáció (4) A memóriavirtualizáció jellemzői (folytatás) •

Az x86 CPU-k memory management unitot (MMU) és translation lookaside buffert (TLB) használnak a virtuális memória kezelés gyorsítására.

•

Több virtuális gép használata esetén a memória virtualizálásnak újabb szintjére van szükség. Vagyis az MMU-t is virtualizálni kell a virtuális gépekben.

•

A vendég OS leképzi a virtuális címtartományát a vendég memória fizikai címére.

•

A vendég OS azonban nem fér hozzá a tényleges fizikai memóriához.

© Schubert Tamás, ÓE NIK

289

www.tankonyvtar.hu

2.2 Memóriavirtualizáció (5) A memóriavirtualizáció jellemzői (folytatás) •

A VMM felelős a vendég fizikai memóriájának a leképzéséért a tényleges gépi memóriára.

•

A leképzéshez ún. árnyék (shadow) laptáblázatokat használ.

•

Hogy elkerülje a két szintű címfordítást minden memóriahozzáférésnél, a VMM a TLB hardvert használja a vendég virtuális memóriájának a leképzésére a tényleges fizikai memóriára. (piros nyíl).

•

Valahányszor a vendég OS változtat a virtuális -> fizikai memória leképzésen, a VMM frissíti az árnyék laptáblázatot. Hatékonyabbá tétele a 2. generációs hardver virtualizációs megoldásoktól várható.

© Schubert Tamás, ÓE NIK

290

www.tankonyvtar.hu

2.3 Eszközvirtualizáció

© Schubert Tamás, ÓE NIK

291

www.tankonyvtar.hu

2.3 Eszközvirtualizáció (1) Az eszköz és I/O virtualizáció jellemzői •

Az I/O kérések kezelését és továbbítását végzi a virtuális eszközök és az osztott, fizikai hardvereszközök között.

•

A szoftver alapú I/O virtualizáció egy sor szolgáltatást és egyszerű menedzsmentet jelent a „pass-through” megoldással szemben.

© Schubert Tamás, ÓE NIK

292

www.tankonyvtar.hu

2.3 Eszközvirtualizáció (2) Az eszköz- és I/O virtualizáció jellemzői (folytatás) •

Pl. virtuális gépek virtuális hálózati interfészei (NIC) virtuális kapcsolókkal (vSwitch) lehetnek összekötve. Ezáltal virtuális hálózatok alakíthatók ki. A virtuális hálózati forgalom nem foglal sávszélességet a fizikai hálózaton.

•

A virtuális gépek, és így a fizikai gép számára természetesen a virtuális hálózati forgalom processzorterhelést ró.

Minta konfiguráció VMwareben • Kettős tűzfallal védett belső hálózat (Internal PC). •

Demilitarizált zónában (DMZ) lévő szolgáltató hálózat (Web szerver).

•

Internet kapcsolat.

© Schubert Tamás, ÓE NIK

293

www.tankonyvtar.hu

2.3 Eszközvirtualizáció (3) Az eszköz- és I/O virtualizáció jellemzői (folytatás) •

A hypervisor virtualizálja a fizikai hardvert és a virtuális gépek számára standard virtuális eszközkészletet biztosít.

•

A virtuális eszközök jól ismert, bevált hardvereszközöket emulálnak, és a virtuális gépek I/O kéréseit (műveleteit) lefordítják a fizikai eszköz parancskészletére.

•

Ez a virtuális gépek szabványosítását szolgálja, és lehetővé teszi a virtuális gépek hordozhatóságát a különböző fizikai platformok között.

© Schubert Tamás, ÓE NIK

294

www.tankonyvtar.hu

3. VMware workstation

© Schubert Tamás, ÓE NIK

295

www.tankonyvtar.hu

3. VMware workstation (1) A VMware workstation (v 7.0) szolgáltatásai •

Platform: Intel x86, x86-64 processzor.

•

Gazda (Host) operációs rendszer lehet: o

Windows,

o

Linux.

•

Virtuális gép max. memóriája: 32 GB (beállítható).

•

A virtuális gép által használt processzorok/magok száma beállítható.

•

Diszkmeghajtó: a vendég operációs rendszer elhelyezkedhet:

•

o

fizikai diszk partíción,

o

virtuális diszk fájlban.

A vendég (Guest) operációs rendszer lehet: o

Windows 32 bit

o

Microsoft MS‐DOS

o

Linux 32 bit (számos disztribúció) Linux 64 bit (számos disztribúció)

o

Novell NetWare 32 Bit

Novell Open Enterprise Server 32 bit

o

FreeBSD 32 bit

FreeBSD 64 bit

o

Sun 32 bit (Solaris)

Sun 64 bit (Solaris)

© Schubert Tamás, ÓE NIK

Windows 64 bit

296

www.tankonyvtar.hu

3. VMware workstation (2) A VMware workstation (v 7.0) szolgáltatásai (folytatás) •

•

A vendég operációs rendszer által használható eszközök: o

CD/DVD meghajtó, ISO image,

o

USB meghajtó,

o

floppy meghajtó,

o

hangeszköz,

o

hálózati kártyák,

o

soros port,

o

párhuzamos port.

Fájlok és szöveg átvitele a gazda és a vendég operációs rendszer között: o

drag and drop,

o

copy and paste,

o

könyvtárak megosztása,

o

virtuális meghajtók leképzése a gazda operációs rendszerben.

© Schubert Tamás, ÓE NIK

297

www.tankonyvtar.hu

3. VMware workstation (3) A VMware workstation (v 7.0) szolgáltatásai (folytatás) •

Virtuális gép felfüggesztése, futásának folytatása o

•

•

A virtuális gép felfüggesztése és a futás folytatása néhány x tizedmásodperc alatt megtörténik.

VMware® Player o

A VMware workstation része.

o

Külön letölthető a VMware honlapjáról (ingyenes).

o

VMware® Player 3.0 verzióval már virtuális gépek is készíthetők.

Team készítése o

Virtuális gépek teambe szervezése.

o

Hálózati kapcsolatok kialakítása egyszerűbb. A többi virtuális és fizikai hálózattól elkülönített LAN szegmensek alakíthatóak ki.

o

Egy kezelői paranccsal egymás után automatikusan elindíthatók, leállíthatók, felfüggeszthetők vagy folytathatók a team virtuális gépei.

© Schubert Tamás, ÓE NIK

298

www.tankonyvtar.hu

3. VMware workstation (4) A VMware virtuális gép készítésének módjai •

Virtuális gép készítése (varázsló), operációs rendszer installálása a hagyományos módon.

•

Virtuális gép klónozása létező VMware virtuális gépből. Másolás helyett a klónozást célszerű használni (új MAC címek és UUID).

•

Fizikai gép, virtuális gép vagy system image konvertálása virtuális géppé (Windows).

•

Más VMware változattal vagy más gyártó eszközével készített virtuális gépek konvertálása.

•

A klónozással előállított új virtuális gép lehet: o

Teljes másolat (Full copy) Az új virtuális gép független az eredeti virtuális géptől.

o

Kapcsolt másolat (Linked copy) Az új virtuális gépnek el kell érnie az eredeti virtuális gépet, de az eredetinek nem kell futnia. Az eredeti operációs rendszerben végrehajtott változtatások nem hatnak ki a kapcsolt operációs rendszerekre.

© Schubert Tamás, ÓE NIK

299

www.tankonyvtar.hu

3. VMware workstation (5) VMware Workstation – indító ablak

© Schubert Tamás, ÓE NIK

300

www.tankonyvtar.hu

3. VMware workstation (6) VMware Workstation – hardver konfigurálás

© Schubert Tamás, ÓE NIK

301

www.tankonyvtar.hu

3. VMware workstation (7) Mintahálózat

Internet

Network-2010

e0

IB Rt. Domain: ir.hu 198.41.50.0/24

DNS

R2 S 1/0 .1 S 1/0 .2

S 1/1 .1

WAN 2

WAN 1

LAN 4

ISA1

DNS (pri) RADIUS

e1 - .1

A

D

F 0/0 - .1 e2

F 0/0 - .1 e1 LAN 1 e2 - .2

e0 - .254

R3

R4

R1

LAN 2 Perimeter

e0 LAN 7 LAN 5 e2 ISA3 .1 e3 S 1/0 .2 e1 F 0/0 .1 e0 - .254 .1 .1 WAN 3 LAN 6 S 1/0 E Perimeter .2 e0 - .254

S 1/1 .2

ISP IP-címek

e0 - .254

C

e1 - .2

ISA2 e2

LAN 3 e0 - .254

B Budapest ISP

Telephelyek

© Schubert Tamás, ÓE NIK

Pécs

Network-2010 302

WAN 1 WAN 2 WAN 3

198.41.10.0/30 198.41.20.0/30 198.41.30.0/30

LAN 1 LAN 2 LAN 3 LAN 4 LAN 5 LAN 6 LAN 7

172.16.1.0/24 172.16.2.0/24 172.16.3.0/24 172.16.4.0/24 198.41.40.0/30 198.41.41.0/24 192.168.2.0/24

VPN www.tankonyvtar.hu

3. VMware workstation (8) VMware Team – LAN beállítás

© Schubert Tamás, ÓE NIK

303

www.tankonyvtar.hu

3. VMware workstation (9) VMware Team – konfiguráció

© Schubert Tamás, ÓE NIK

304

www.tankonyvtar.hu

3. VMware workstation (10) VMware Workstation – hálózat konfiguráció •

•

•

Virtuális interfészek o

A virtuális gépekhez virtuális interfészeket hozhatunk létre (Network Adapter).

o

Típusa: AMD PCNET PCI II. vagy Intel Pro/1000 MT Server Adapter (64 bites vendég esetén).

o

Max. száma: 10.

Virtuális kapcsoló (Switch) o

A komponensek (virtuális gépek – guest, befogadó – host) összekapcsolására szolgál.

o

Max. száma: 10.

Alapértelmezetten néhány kapcsoló és hálózat létrejöno

Bridged network:

VMnet0

o

Host only network:

VMnet1

o

Nat network:

VMnet8

o

Egyéb hálózatok:

VMnet2 – 7, VMnet9

© Schubert Tamás, ÓE NIK

305

www.tankonyvtar.hu

3. VMware workstation (11) VMware Workstation – hálózat konfiguráció (folytatás) •

•

DHCP szerver o

A VMware DHCP szervert is működtet.

o

Lehetővé teszi, hogy a virtuális hálózatokon DHCP-vel kapjanak IP címet az interfészek.

Tipikus hálózati konfigurációk 1. Bridged network. 2. Network Address Translation (NAT). 3. Host-Only Networking. 4. Custom Networking.

© Schubert Tamás, ÓE NIK

306

www.tankonyvtar.hu

3. VMware workstation (12) 1. Bridged network • A vendég gép virtuális interfésze egy LAN-ba kerül a gazda számítógép fizikai interfészével. • IP címüknek közös NetID-vel kell rendelkezniük (Pl.: 192.168.1.0/24). • A vendég gép más fizikai számítógépekkel, hálózatokkal (Internet) kommunikálhat.

© Schubert Tamás, ÓE NIK

307

www.tankonyvtar.hu

3. VMware workstation (13) 2. Network Address Translation (NAT) • A virtuális interfész NAT eszközön keresztül kapcsolódhat külső hálózathoz. • Saját IP címe nem jelenik meg a külső hálózaton.

© Schubert Tamás, ÓE NIK

308

www.tankonyvtar.hu

3. VMware workstation (14) 3. Host-Only Networking • A vendég gép hálózati interfésze a gazdagép virtuális interfészével közös hálózatba kerül. • Így a gazdagép is kommunikálhat virtuális gépekkel anélkül, hogy a fizikai interfésszel kapcsolatba kerülne. • Ez esetben a gazdagép is rendelkezik virtuális interfészekkel.

© Schubert Tamás, ÓE NIK

309

www.tankonyvtar.hu

3. VMware workstation (15) 4. Custom Networking • A virtuális interfészeket olyan virtuális hálózatba soroljuk, amelyekhez csak virtuális gépek csatlakoznak. A virtuális gépek egymással kommunikálhatnak. • Az alábbi konfigurációban a „Virtual machine 3 Firewall” és a „Virtual machine 4 internal PC” közös hálózatban van. • IP címük hálózati része is közös. • A „Virtual machine 4 internal PC” csak a „Virtual machine 3 Firewall”-on keresztül tud más hálózatokat elérni. • A két gép a VMnet3 virtuális hálózathoz csatlakozik.

© Schubert Tamás, ÓE NIK

310

www.tankonyvtar.hu

3. VMware workstation (16) 4. Custom Networking (folytatás)

© Schubert Tamás, ÓE NIK

311

www.tankonyvtar.hu

3. VMware workstation (17) Virtuális hálózatok és interfészek konfigurálása •

Virtuális hálózat, DHCP konfigurálása VMware > Edit > Virtual Network Setting…

•

Vendég gép interfész létrehozása, típusának beállítása VMware > VM > Settings > Hardware > …

•

A vendég operációs rendszer hálózati interfészének beállítása Az operációs rendszer indítása után a Control Panelből: (IP cím, maszk, alapértelmezett átjáró stb.)

© Schubert Tamás, ÓE NIK

312

www.tankonyvtar.hu

Irodalom (1) [1]: Understanding Full Virtualization, Paravirtualization, and Hardware Assist, White paper, Vmware Inc. [2]: Az x86 architektúra alapjai… http://prog.hu/cikkek/823/Az+x86+architektura+alapjai.html [3]: Workstation User’s Manual, VMware Workstation 7.0, VMware, Inc., EN000168-00.

© Schubert Tamás, ÓE NIK

313

www.tankonyvtar.hu

Adatközpontok VMware vSphere

Schubert Tamás

© Schubert Tamás, ÓE NIK

314

www.tankonyvtar.hu

Tartalom 1. 2. 3. 4. 5. 6. 7.

Bevezetés VMware vSphere komponensek A vSphere adatközpont fizikai topológiája A virtuális adatközpont architektúrája Hálózati architektúra Tároló architektúra A VMware vCenter szerver Irodalom

© Schubert Tamás, ÓE NIK

315

www.tankonyvtar.hu

1. Bevezetés

© Schubert Tamás, ÓE NIK

316

www.tankonyvtar.hu

1. Bevezetés (1) A VMware vSphere célja •

A VMware vSphere a virtualizáció segítségével az adatközpontokat egyszerű cloud computing infrastruktúrává alakítja.

•

Lehetővé teszi rugalmas, megbízható IT szolgáltatások létesítését.

•

Több fizikai rendszer együttes kezelésével virtualizálja és egyesíti a fizikai hardver erőforrásokat.

•

Virtuális erőforrások halmazát teszi elérhetővé az adatközpontban.

•

A VMware vSphere a fizikai erőforrásokat (CPU, memória, tároló, hálózat) dinamikus működési környezetként kezeli, és elrejti a rendszer összetettségét.

© Schubert Tamás, ÓE NIK

317

www.tankonyvtar.hu

1. Bevezetés (2) VMware vSphere Component Layers [1]

© Schubert Tamás, ÓE NIK

318

www.tankonyvtar.hu

1. Bevezetés (3) VMware vSphere Component Layers (folytatás) •

Infrastructure Services Az Infrastructure Services absztrahálja, egyesíti és lefoglalja a fizikai erőforrásokat. Kategóriái: o VMware vCompute Services Elvonatkoztat a különálló szerver erőforrásoktól. Egyesíti ezeket az erőforrásokat és alkalmazásokhoz rendeli őket. o

VMware vStorage Services Olyan technológiák, amelyek lehetővé teszik a tárolók hatékony használatát és felügyeletét virtuális környezetben.

o

VMware vNetwork Services Olyan technológiák, amelyek egyszerűsítik és feljavítják a hálózatok használatát virtuális környezetben.

© Schubert Tamás, ÓE NIK

319

www.tankonyvtar.hu

1. Bevezetés (4) VMware vSphere Component Layers (folytatás) •

Application Services Olyan szolgáltatások, amelyek az alkalmazások üzemkészségét, biztonságát és méretezhetőségét szolgálják. Pl.: High Availability és Fault Tolerance.

•

VMware vCenter Server Az adatközpont egyetlen helyről történő irányítását végzi. Legfontosabb feladatai: hozzáférésvezérlés, teljesítmény monitorozás, konfigurálás.

•

Clients A VMware vSphere adatközpont elérésére a felhasználók 2 ügyfélprogrammal rendelkeznek: o vSphere Client, o Web Access (webböngészővel).

© Schubert Tamás, ÓE NIK

320

www.tankonyvtar.hu

2. VMware vSphere komponensek

© Schubert Tamás, ÓE NIK

321

www.tankonyvtar.hu

2. VMware vSphere komponensek (1) VMware vSphere komponensek •

VMware® ESX és VMware® ESXi,

•

VMware® vCenter Server,

•

VMware® vSphere Client,

•

VMware® vSphere Web Access,

•

VMware® Virtual Machine File System (VMFS),

•

VMware® Virtual SMP,

•

VMware® vMotion és Storage vMotion,

•

VMware® High Availability (HA),

•

VMware® Distributed Resource Scheduler (DRS),

•

VMware® vSphere SDK,

•

VMware® Fault Tolerance,

•

vNetwork Distributed Switch (vDS),

•

Host Profiles,

•

Pluggable Storage Architecture (PSA).

© Schubert Tamás, ÓE NIK

322

www.tankonyvtar.hu

2. VMware vSphere komponensek (2) VMware vSphere komponensek (folytatás) •

VMware® ESX és VMware® ESXi Virtualizációs réteg, amely fizikai szerveren fut, és virtualizálja a processzort, a memóriát, a tárolót és más erőforrásokat több virtuális számítógép számára. Két megvalósítása:

•

o

Vmware ESX 4.1, amely beépített service consollal rendelkezik. Installálható CD-ROM boot image formában érhető el.

o

Vmware ESXi 4.1, amely nem rendelkezik beépített service consollal. Installálható CD-ROM boot image, és firmware-be égethető formában érhető el.

VMware® vCenter Server A virtualizált IT környezet telepítésének, konfigurálásának és felügyeletének központi rendszere.

•

VMware® vSphere Client Interfész, amely a vCenter Server vagy az ESX/ESXi szerverek távoli csatlakozását biztosítja Windows PC-ről.

© Schubert Tamás, ÓE NIK

323

www.tankonyvtar.hu

2. VMware vSphere komponensek (3) VMware vSphere komponensek (folytatás) •

VMware® vSphere Web Access Lehetővé teszi a virtuális gépek menedzselését és elérését távoli konzollal.

•

VMware® Virtual Machine File System (VMFS) Nagy teljesítményű klaszter fájlrendszer az ESX/ESXi virtuális gépei számára.

•

VMware® Virtual SMP Olyan képesség, amely biztosítja, hogy egy virtuális gép egyidejűleg több fizikai processzort is használhasson.

© Schubert Tamás, ÓE NIK

324

www.tankonyvtar.hu

2. VMware vSphere komponensek (4) VMware vSphere komponensek (folytatás) •

VMware® vMotion és Storage vMotion o

A VMware vMotion lehetővé teszi futó virtuális gépek leállás nélküli migrációját egyik fizikai gépről a másikra, a szolgáltatások folyamatos rendelkezésre állása mellett a tranzakciók integritásának megtartásával.

o

A Storage vMotion lehetővé teszi a virtuális gépek állományainak migrációját egy tárolóról a másikra a szolgáltatások megszakítása nélkül.

A vMotion nem biztosítja virtuális gépek migrációját adatközpontok között. •

VMware® High Availability (HA) Biztosítja a virtuális gépek magas rendelkezésre állását. Ha egy szerver meghibásodik, az érintett virtuális gépek újraindulnak más, tartalék kapacitással rendelkező gépeken.

•

VMware® Distributed Resource Scheduler (DRS) Dinamikusan foglal feldolgozó kapacitást a virtuális gépek számára, és kiegyensúlyozza a fizikai szerverek erőforrását. A distributed power management (DPM) szolgáltatással együtt elősegíti a szerverek energiafelhasználásának csökkentését.

© Schubert Tamás, ÓE NIK

325

www.tankonyvtar.hu

2. VMware vSphere komponensek (5) VMware vSphere komponensek (folytatás) •

VMware® vSphere SDK Szabványos interfészt biztosít a VMware vSphere-hez a fejlesztők számára.

•

•

VMware® Fault Tolerance o

Hibatűrő megoldás (Fault Tolerance), amelynek bekapcsolásakor a virtuális gépnek (primary) egy második (secondary) példánya jön létre.

o

Minden műveletet, amelyet az elsődleges virtuális gép végrehajt, végrehajt a másodlagos virtuális gép is.

o

Ha az elsődleges virtuális gép elérhetetlenné válik, a másodlagos válik aktívvá, és folytatja a kiszolgálást.

vNetwork Distributed Switch (vDS) o

Különböző ESX/ESXi szerverek között elosztott (közös) virtuális Ethernet kapcsolók (distributed virtual switch – vDS) hozhatók létre.

o

Ezek alkalmazása jelentősen csökkenti a hálózatok kezelésével járó munkát, és növeli a hálózat teljesítményét.

o

Konzisztens hálózati konfigurációk hozhatók létre a virtuális gépek számára olyan esetekben, amikor a virtuális gépek mozognak a fizikai szerverek között.

© Schubert Tamás, ÓE NIK

326

www.tankonyvtar.hu

2. VMware vSphere komponensek (6) VMware vSphere komponensek (folytatás) •

•

Host Profiles o

Konfigurációs irányelvek (configuration policy) készítésével egyszerűsíthető a virtuális gépek konfigurációjának menedzselése.

o

Egy konfigurált és ellenőrzött állomás konfigurációjának lenyomatát (blueprint) készíti el, amelynek segítségével más állomások hálózati, tároló, biztonsági és egyéb konfigurációja készíthető el.

o

A konfigurációs irányelvek segítségével folyamatosan ellenőrizhető (monitor) az irányelveknek való megfelelés az adatközpontban.

Pluggable Storage Architecture (PSA) A PSA a tároló gyártók számára készült keretrendszer (storage partner plug-in framework), amely lehetővé teszi, hogy a gyártók optimalizálják a tárolók elérését több alternatív útvonal egyidejű (performance-enhancing multipath load-balancing) használatával.

© Schubert Tamás, ÓE NIK

327

www.tankonyvtar.hu

3. A vSphere adatközpont fizikai topológiája

© Schubert Tamás, ÓE NIK

328

www.tankonyvtar.hu

3. A vSphere adatközpont fizikai topológiája (1) VMware vSphere Datacenter Physical Topology [1]

© Schubert Tamás, ÓE NIK

329

www.tankonyvtar.hu

3. A vSphere adatközpont fizikai topológiája (2) A fizikai topológia összetevői •

•

Computing servers o

Standard x86-os szerverek, amelyek az ESX/ESXi rendszereket közvetlenül a hardveren futtatják.

o

Biztosítják az erőforrást a rajtuk futó virtuális gépek számára.

o

Hasonlóan konfigurált szerverek, amelyek ugyanahhoz a hálózathoz és tároló alrendszerhez csatlakoznak klaszterbe szervezhetők, hogy egyesített erőforráskészletet biztosítsanak a virtuális gépek számára.

Storage networks and arrays o

o o

A VMware vSphere által támogatott tároló technológiák: 

Fibre Channel SAN array,



iSCSI SAN array,



NAS array.

A tárolók tárolóhálózaton keresztül megoszthatók a szervercsoportok között. A tároló aggregálás nagyobb rugalmasságot biztosít a tárolókapacitás virtuális gépekhez rendelésekor.

© Schubert Tamás, ÓE NIK

330

www.tankonyvtar.hu

3. A vSphere adatközpont fizikai topológiája (3) A fizikai topológia összetevői (folytatás) •

IP networks o

•

Minden szerver több hálózati interfésszel (NIC) rendelkezhet a nagyobb rendelkezésre állás és sávszélesség érdekében.

vCenter Server o

Az adatközpont egyetlen központi vezérlő eleme.

o

Legfontosabb adatközponti szolgáltatásai: hozzáférésvezérlés, teljesítmény monitorozás, konfigurálás.

o

Egyesíti az adatközpont egyedi szervereinek erőforrásait, amelyeket megoszt a virtuális gépek között.

o

A szerverek folytatják működésüket a vCenter Server meghibásodása vagy elérhetetlensége esetén is. 

A szerverek külön-külön is menedzselhetők.



A rajtuk futó virtuális gépek tovább futnak az utolsó erőforráshozzárendelés szerinti paraméterekkel.



A vCenter Server helyreállítása után az adatközpont központi menedzselése folytatódik.

© Schubert Tamás, ÓE NIK

331

www.tankonyvtar.hu

3. A vSphere adatközpont fizikai topológiája (4) A fizikai topológia összetevői (folytatás) •

Management clients o

Az adatközpont menedzselése és a virtuális gépek elérésének módjai: 

VMware vSphere Client (vSphere Client),



Web elérés webböngészővel,



vSphere Command-Line Interface (vSphere CLI),



vSphere Management Assistant (vMA).

© Schubert Tamás, ÓE NIK

332

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája

© Schubert Tamás, ÓE NIK

333

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (1) A VMware vSphere feladatai •

A VMware vSphere virtualizálja a teljes IT infrastruktúrát: szerverek, tárolók, hálózat.

•

Egyesíti a fenti erőforrásokat, majd egynemű elemek készletét biztosítja a virtuális környezet számára.

•

Az IT erőforrások osztott szolgáltatásként menedzselhetők, és dinamikusan kioszthatók a különböző üzleti projektek részére.

•

Segítségével a rendszer kulcselemei megtekinthetők, konfigurálhatók és menedzselhetők.

•

A rendszer kulcselemei: o

Feldolgozó és memória-erőforrások: hosts, clusters, és resource pools.

o

Tároló erőforrások: datastores.

o

Hálózati erőforrások: networks.

o

Virtuális gépek: virtual machines.

© Schubert Tamás, ÓE NIK

334

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (2) Virtual Datacenter Architecture [1]

© Schubert Tamás, ÓE NIK

335

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (3) Host, cluster és resource pool •

Egy host a fizikai feldolgozó kapacitás és memória virtuális reprezentációja, amelyen ESX/ESXi operációs rendszer fut.

•

Ha több fizikai gép erőforrásait egyesíteni kell kezelni, clusterbe szervezik őket.

•

Gépek dinamikusan hozzáadhatók a clusterhez, vagy eltávolíthatók a clusterből.

•

A hostok és a clusterek feldolgozó és memória-erőforrásai végül resource poolok hierarchiájába szervezhetők.

Datastore •

A Datastore-ok az alábbi fizikai tároló erőforrások virtuális reprezentációi: o

a szerver helyi SCSI, SAS vagy SATA diszkjei,

o

Fibre Channel SAN diszktömbök,

o

iSCSI SAN diszktömbök,

o

Network Attached Storage (NAS) tömbök.

© Schubert Tamás, ÓE NIK

336

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (4) Network •

A network összekapcsolja a virtuális gépeket egymással és az adatközponton kívül eső fizikai hálózattal.

Virtual machines •

A virtual machines a létrehozásukkor hozzárendelhetők egy hosthoz, clusterhez vagy resource poolhoz, és egy datastore-hoz.

•

A virtuális gépek dinamikusan növelhetik erőforrás-felhasználásukat a terhelés növekedésével, vagy visszaadják a szükségtelen erőforrásokat a rendszernek a terhelésük csökkenésekor.

•

A virtuális gépek létesítése sokkal egyszerűbb és gyorsabb, mint a fizikai gépeké.

•

Az operációs rendszerek és alkalmazások ugyanúgy installálhatók a virtuális gépeken, mint a fizikai gépeken.

•

A virtuális gépek az operációs rendszerrel és az alkalmazásokkal együtt mozgathatók, másolhatók.

© Schubert Tamás, ÓE NIK

337

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (5) Virtual machines (folytatás) •

A virtuális gépekhez erőforrások a rendszergazda által létrehozott irányelvek alapján rendelhetők.

•

Az irányelv bizonyos mennyiségű erőforrást lefoglal a virtuális gép számára, hogy garantálja a megfelelő teljesítményét.

•

Az irányelv meghatározhat bizonyos mennyiségű, igény szerint felhasználható erőforrást a virtuális gép számára.

•

Azon virtuális gépek, amelyek megsértik az erőforrás allokációs irányelvet, nem indíthatóak el.

© Schubert Tamás, ÓE NIK

338

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (6) Hostok, clusterek és resource poolok – példák •

Egy host egy x86-os fizikai szerver egyesített erőforrásait képviseli.

•

Példa: o

Egy szerver 4 db 4 GHz-es dual-core CPU-val, és 32 GB rendszermemóriával rendelkezik.

o

Így a host 32 GHz feldolgozó teljesítménnyel és 32 GB rendszermemóriával rendelkezik, amely a virtuális gépekhez rendelhető.

•

Egy cluster képviseli a hozzá rendelt x86-os fizikai szerverek egyesített erőforrásait, és egyetlen entitásként kezelhető.

•

A szerverek ugyanazon a hálózaton helyezkednek el, és közös tárolótömbön osztoznak.

•

Példa: o

Egy cluster 8 db szerverből áll, mindegyik 4 db 4 GHz-es dual-core CPUval, és 32 GB rendszermemóriával rendelkezik.

o

Így a cluster 256 GHz feldolgozó teljesítménnyel és 256 GB rendszermemóriával rendelkezik, amely a virtuális gépekhez rendelhető.

© Schubert Tamás, ÓE NIK

339

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (7) Hostok, clusterek és resource poolok – példák (folytatás) •

A resource pool egyetlen clusterből vagy szerverből származó feldolgozó kapacitás és memóriamennyiség egy partíciója.

•

A resource poolok hierarchiába szervezhetők és egymásba ágyazhatók, vagyis a resource poolok kisebb resource poolokra oszthatók, hogy a dinamikus erőforrás-gazdálkodást elősegítsék.

•

A resource poolokhoz aztán virtuális gépek társulnak, amelyek felhasználják a resource poolok erőforrásait.

© Schubert Tamás, ÓE NIK

340

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (8) Hostok, clusterek és resource poolok – példák [1] (folytatás)

© Schubert Tamás, ÓE NIK

341

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (9) Hostok, clusterek és resource poolok – példák (folytatás) •

Az előző ábra illusztrálja a resource poolok használatát.

•

A cluster 3 db x86-os, 4 GHz-es, 16 GB memóriával rendelkező szerverből áll.

•

A cluster paraméterei: 12 GHz feldolgozó teljesítmény és 48 GB memória.

•

A Finance Department resource pool 8 GHz teljesítményt és 32 GB memóriát igényel a clustertől.

•

A maradék 4 GHz teljesítmény és 16 GB memória egy másik virtuális gép számára van félretéve.

•

A Finance Department resource poolból a kisebb Accounting resource pool lefoglal 4 GHz teljesítményt és 16 GB memóriát az Accounting részleg virtuális gépei számára.

•

A Payroll virtuális gép számára 4 GHz teljesítmény és 16 GB memória marad.

© Schubert Tamás, ÓE NIK

342

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (9) Hostok, clusterek és resource poolok – példák (folytatás) •

Az erőforrás allokációs irányelvek dinamikusan változtathatók.

•

Például az Accounting resource pool 4 GHz teljesítményigénye megnövelhető 6 GHz-re.

•

A resource poolok paraméterei dinamikusan változtathatók anélkül, hogy a hozzájuk rendelt virtuális gépeket le kellene állítani.

•

Ha a lefoglalt erőforrásokat egy resource pool vagy egy virtuális gép nem használja fel, az erőforrások megoszthatók.

•

Például, ha az Accounting részleg nem használja fel a számára lefoglalt 4 GHz teljesítményt, a Payroll virtuális gép szükség esetén megkaphatja.

•

Ha az Accounting részlegnek újra szüksége van az erőforrásra, a Payroll dinamikusan visszaadja.

•

Tehát a resource poolok által lefoglalt erőforrások nem vesznek el, ha az erőforrás tulajdonosa éppen nem használja őket.

•

Ez a fajta működési mód maximalizálja az erőforrások kihasználását, miközben az irányelvekben rögzített erőforrás-lefoglalás nem sérül.

© Schubert Tamás, ÓE NIK

343

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (10) Hostok, clusterek és resource poolok – példák (folytatás) •

Lehetőség van több memória lefoglalására is, mint a fizikai memória mennyisége (overcommitment).

•

Memória túlterhelés esetén az ESX/ESXi szerver kénytelen lenne a memórialapokat diszkre másolni (swap).

•

Ezt az ESX/ESXi a memórialapok tömörítésével, és a virtuális gépek tömörítési gyorsító tárában (compression cache) való elhelyezéssel igyekszik meggátolni.

•

A memóriatömörítés alapbeállításként be van kapcsolva.

© Schubert Tamás, ÓE NIK

344

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (11) VMware vSphere Distributed Services •

A vSphere elosztott szolgáltatásai a virtuális gépek hatékony és automatizált erőforrás kezelését és magas rendelkezésre állását szolgálják.

•

Ezek: o

VMware vMotion,

o

VMware Storage vMotion,

o

VMware Distributed Resource Scheduler – DRS,

o

VMware Storage I/O Control,

o

VMware High Availability – HA,

o

VMware Fault Tolerance – FT.

© Schubert Tamás, ÓE NIK

345

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (12) Migrálás vMotion-nel •

A virtuális gépek az erőforrásokat az ESX/ESXi szerverektől kapják.

•

A vMotion technológia a futó virtuális gépek migrálását teszi lehetővé a fizikai szerverek között a szolgáltatás megszakítása nélkül.

•

Ez a lehetőség rugalmasabbá és hatékonyabbá teszi az erőforráshozzárendelést a virtuális gépekhez.

•

Az erőforrások dinamikusan újra allokálhatók a virtuális gépekhez másik fizikai szerveren.

Migrálás vMotion-nel [1]

© Schubert Tamás, ÓE NIK

346

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (13) VMware Storage vMotion •

A Storage vMotion technológia a futó virtuális gépek migrálását teszi lehetővé egyik datastore-ról a másikra, a szolgáltatás megszakítása nélkül.

•

Ennek előnyei: 

Karbantartás céljából felszabadíthatók a tárolók.



LUN-ok átkonfigurálhatók.



Megoldhatók a kapacitásproblémák.



VMFS kötetek upgrade-elhetők.



A tárolókörnyezet teljesítménye optimalizálható.

© Schubert Tamás, ÓE NIK

347

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (14) VMware Distributed Resource Scheduler - DRS •

A Distributed Resource Scheduler (DRS) automatizálja a virtuális gépek optimális elhelyezését a megfelelő fizikai gépen a clusteren belül.

•

A DRS úgy rendeli a virtuális gépet a clusterhez, hogy a cluster terhelése kiegyensúlyozott legyen, és ezzel együtt az erőforrások kiosztásának irányelvei (pl.: foglalások, prioritások, korlátok) megmaradjanak.

•

A virtuális gép indításakor a DRS hozzárendeli a virtuális gépet egy hosthoz.

•

A cluster terhelési viszonyai változnak, a DRS a vMotion segítségével szükség szerint átmozgatja a virtuális gépet egy másik hostra.

•

Például, ha egy új szervert csatlakoztatnak a clusterhez, a DRS azonnal reagál az új helyzetre.

•

A distributed power management (DPM) szolgáltatás bekapcsolása esetén a rendszer összeveti a cluster és a hostok kapacitását a virtuális gépek erőforrásigényével.

•

Ha az erőforrásigények megengedik, hogy a kevesebb host lássa el a szolgáltatásokat, a DPM úgy migrálja a virtuális gépeket a hostok között, hogy a nem szükséges hostokat leállíthassa.

•

Ha ismét több erőforrásra van szükség, a DRS visszakapcsolja a leállított hostokat és bevonja őket a kiszolgálásba (dynamic cluster right-sizing).

•

A DPM működése lehet automatikus vagy javaslattevő.

© Schubert Tamás, ÓE NIK

348

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (15) VMware Distributed Resource Scheduler - DRS [1]

© Schubert Tamás, ÓE NIK

349

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (16) VMware Storage I/O Control •

A tárolóhozzáférés túlterhelése (kérések torlódása) esetén versenyhelyzet alakulhat ki, és kiszámíthatatlan, hogy melyik virtuális gép mikor kapja meg az átviteli csatornát.

•

Szükséges lehet, hogy bizonyos gépek előnyt élvezzenek a tárolóhozzáférésben, illetve szabályozható legyen a csatornához való hozzáférés.

•

VMware Storage I/O Control segítségével szabályok és irányelvek állíthatók fel, amelyek meghatározzák a virtuális gépek prioritását.

•

Torlódás esetén a VMware Storage I/O Control a szabályok szerint dinamikusan allokálja az I/O erőforrásokat a virtuális gépek számára.

•

Alkalmazásának előnyei: o

Javítja a kritikus alkalmazások kiszolgálásának minőségét.

o

Az I/O-intenzív üzletkritikus alkalmazások is biztonsággal használhatók virtuális környezetben.

o

Az I/O erőforrások igazságosan eloszthatók az alkalmazások között.

o

Nincs szükség dedikált tárolóra a kritikus alkalmazások részére.

© Schubert Tamás, ÓE NIK

350

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (17) VMware Storage I/O Control [1]

© Schubert Tamás, ÓE NIK

351

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (18) VMware High Availability – HA •

A VMware HA lehetővé teszi a virtuális gépek automatikus újraindítását a cluster egy másik fizikai szerverén a virtuális gépeket futtató host meghibásodása esetén.

•

A virtuális gépek összes alkalmazása HA tulajdonsággal rendelkezik.

•

A HA monitorozza a cluster fizikai hostjait és érzékeli az állomáshibákat.

•

A hostokon egy-egy ügynök (agent) ún. „heartbeat” kapcsolatban van a resource pool többi hostjával.

•

A heartbeat elvesztése elindítja a virtuális gépek újraindításának folyamatát más hostokon.

•

A HA mindig tartalékol annyi erőforrást, hogy meghibásodás esetén a virtuális gépek elindíthatók legyenek.

•

A HA Virtual Machine Monitoring szolgáltatása figyeli a virtuális gépek „heartbeat”-jét is.

•

Ha bizonyos ideig nem érkezik heartbeat, a HA újraindítja a virtuális gépet.

•

Az újraindítások megengedett számát az irányelvek határozzák meg.

•

A HA a vCenter Serverrel konfigurálható, azonban a vCenter Server meghibásodása nem befolyásolja a HA működését.

© Schubert Tamás, ÓE NIK

352

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (19) VMware High Availability - HA [1]

© Schubert Tamás, ÓE NIK

353

www.tankonyvtar.hu

4. A virtuális adatközpont architektúrája (20) VMware Fault Tolerance - FT •

A VMware Fault Tolerance (FT) használatával az ESX/ESXi hostokon biztosítható a virtuális gépek folyamatos rendelkezésre állása.

•

Az elsődleges virtuális gép (primary virtual machine) egy árnyék másolata (shadow copy – secondary virtual machine) egy másik fizikai hoston ún. virtual lockstep üzemmódban fut.

•

Az FT rögzíti elsődleges VM inputjait és egyéb eseményeit, és „lejátssza” a másodlagos VM-en, amely biztosítja a két VM azonos állapotát.

•

A két VM azonos állapota miatt a másodlagos VM bármikor átveheti az elsődleges szerepét a kiszolgálás megszakadása és adatveszteség nélkül.

© Schubert Tamás, ÓE NIK

354

www.tankonyvtar.hu

5. Hálózati architektúra

© Schubert Tamás, ÓE NIK

355

www.tankonyvtar.hu

5. Hálózati architektúra (1) Hálózati architektúra – jellemzők •

A VMware vSphere hálózati elemei biztosítják, hogy az adatközpont virtuális gépei a fizikai környezethez hasonlóan vehessenek részt a hálózat munkájában.

•

A VMware vSphere hálózati elemei: o

Virtual network interface cards (vNIC),

o

vNetwork Standard Switches (vSwitch),

o

vNetwork Distributed Switches (vDS),

o

Port groups.

Virtual network interface cards (vNIC) •

A virtuális gépek egy vagy több vNIC-kel rendelkeznek.

•

A vendég operációs rendszer VMware device driverrel kommunikál.

•

A vNIC saját MAC címmel, és egy vagy több IP-címmel rendelkezik.

© Schubert Tamás, ÓE NIK

356

www.tankonyvtar.hu

5. Hálózati architektúra (2) vNetwork Standard Switches (vSwitch) •

A vNetwork Standard Switch (vSwitch) úgy viselkedik, mint egy Layer 2-es fizikai kapcsoló.

•

Minden szerver saját virtuális kapcsolóval rendelkezik.

•

A kapcsoló egyik oldalán port groupok vannak, amelyek a virtuális gépekhez csatlakoznak.

•

A kapcsoló másik oldalán uplink portok találhatók, amelyek a szerver fizikai adaptereihez csatlakoznak.

•

Ha a virtuális kapcsoló uplink portja több fizikai adapterhez is csatlakozik (NIC teaming), a fizikai adapterek terhelésmegosztást végezhetnek (share the traffic load), vagy tartalékot képezhetnek hiba esetére (passive failover).

© Schubert Tamás, ÓE NIK

357

www.tankonyvtar.hu

5. Hálózati architektúra (3) Port groups •

A port group a virtuális környezet konstrukciója.

•

Segítségével irányelvek állíthatók fel, amelyek meghatározzák a hozzá csatlakozó hálózat működését.

•

Egy-egy vSwitch több port grouppal is rendelkezhet.

•

A virtuális gépek vNIC-jei nem portokhoz, hanem port groupokhoz csatlakoznak.

•

Azon VM-ek, amelyek azonos port groupokhoz kapcsolódnak, azonos hálózathoz csatlakoznak a virtuális környezetben még akkor is, ha különböző fizikai szerveren futnak.

•

A port groupokhoz rendelt irányelvek meghatározzák a hálózat o

biztonsági beállításait,

o

a hálózat szegmentálását,

o

teljesítményét,

o

rendelkezésre állását,

o

forgalom menedzsmentjét.

© Schubert Tamás, ÓE NIK

358

www.tankonyvtar.hu

5. Hálózati architektúra (4) Networking with vNetwork Standard Switches [1]

© Schubert Tamás, ÓE NIK

359

www.tankonyvtar.hu

5. Hálózati architektúra (5) vNetwork Distributed Switches (vDS) •

A vNetwork Distributed Switch (vDs) úgy viselkedik, mint a csatlakozó hostok egyetlen közös virtuális kapcsolója.

•

Ezáltal a virtuális gépek konzisztens hálózati konfigurációja állítható elő migrálás esetére.

•

A vDS működése hasonló a vSwitch működéséhez.

•

A vDS a hoston belüli virtuális gépek közötti hálózati forgalmat a hoston belül továbbítja, míg a különböző hostokon futó virtuális gépek közötti forgalmat a fizikai adaptereken keresztül továbbítja.

•

A vDS-eken egy vagy több dvPort groupot lehet létesíteni.

•

A dvPort groupok az azonos hálózati jellemzőkkel rendelkező virtuális gépeket fogják össze.

© Schubert Tamás, ÓE NIK

360

www.tankonyvtar.hu

5. Hálózati architektúra (6) Networking with vNetwork Distributed Switches [1]

© Schubert Tamás, ÓE NIK

361

www.tankonyvtar.hu

5. Hálózati architektúra (7) vDS – Network resource pools •

A network resource poolok meghatározzák a különböző típusú forgalmak prioritását a vDS-en.

•

Ha a network resource management be van kapcsolva, a vDS forgalom 6 network resource poolba van sorolva:

•

o

FT forgalom,

o

iSCSI forgalom,

o

vMotion forgalom,

o

menedzsmentforgalom,

o

NFS forgalom,

o

virtual machine forgalom.

Minden fizikai adapteren beállítható az egyes resource poolok forgalmának részesedési aránya és korlátja.

© Schubert Tamás, ÓE NIK

362

www.tankonyvtar.hu

5. Hálózati architektúra (8) vDS port group opciók •

Layer 2 security options A port groupokhoz rendelt vNIC-ek promiscuous módbeli viselkedése, MAC címek változtathatósága, és hamis címmel továbbított forgalom kezelése adható meg.

•

VLAN support A virtuális hálózat integrálható a fizikai hálózat VLAN-jaival.

•

Private VLAN Segítségével a VLAN-hoz tartozó gépek egymás közötti forgalma korlátozható.

•

Traffic shaping Az átlagos és a csúcs sávszélesség QoS (Quality of Service) irányelvei, és a többletforgalom (traffic burst size) mennyisége adható meg.

•

NIC teaming A port group NIC-teaming irányelveinek megadásával terhelésmegosztás és tartalék adatút konfigurálható.

© Schubert Tamás, ÓE NIK

363

www.tankonyvtar.hu

6. Tároló architektúra

© Schubert Tamás, ÓE NIK

364

www.tankonyvtar.hu

6. Tároló architektúra (1) A tároló architektúra jellemzői •

A VMware vSphere tároló architektúrája absztrakciós rétegekből épül fel, amely elfedi és felügyeli a fizikai tároló alrendszerek bonyolultságát és különbözőségét.

•

A VM operációs rendszere számára a tároló alrendszer virtuális SCSI vezérlőként jelentkezik, amelyhez egy vagy több virtuális SCSI diszk csatlakozik.

•

A vezérlők típusai: BusLogic Parallel, LSI Logic Parallel, LSI Logic SAS és VMware Paravirtual.

•

A virtuális SCSI diszkek az adatközpont datastore elemeit képzik le.

•

A datastore pedig egy absztrakció, amellyel tároló terület rendelhető a virtuális gépekhez.

•

Egy-egy datastore több hosthoz is tartozhat.

•

A virtuális gépeknek nincs dolga a Fibre Channel SAN-nal, iSCSI SAN-nal, DAS-sal vagy NAS-sal.

© Schubert Tamás, ÓE NIK

365

www.tankonyvtar.hu

6. Tároló architektúra (2) Storage Architecture [1]

© Schubert Tamás, ÓE NIK

366

www.tankonyvtar.hu

6. Tároló architektúra (3) A tároló architektúra jellemzői (folytatás) •

Minden datastore VMFS kötetként látszik a tároló eszközön.

•

A NAS datastore-ok NFS kötetként látszanak VMFS jellemzőkkel.

•

A datastore-ok több fizikai tároló alrendszert is átfedhetnek.

•

Egy-egy VMFS kötet egy vagy több LUN-t tartalmazhat helyi SCSI diszken, Fibre Channel SAN diszkfarmon vagy iSCSI SAN diszkfarmon.

•

Új LUN-ok transzparensen hozzáadhatók a tároló alrendszerekhez.

•

A datastore-ok tárolókapacitása a fizikai hostok és a tároló alrendszerek újraindítása nélkül kiterjeszthető.

•

Egy VMFS egy LUN-jának meghibásodása csak azt a VM-et érinti, amelyik használja.

•

A virtuális gépek a datastore egy könyvtárának néhány fájljában vannak tárolva.

•

A virtuális gépek diszk tárolóit a könyvtár egy-egy fájlja tartalmazza.

•

A diszk tároló másolható, mozgatható, elmenthető (back up).

•

Új virtuális diszkek leállítás nélkül hozzáadhatók a VM-hez (.vmdk kiterjesztésű fájl).

© Schubert Tamás, ÓE NIK

367

www.tankonyvtar.hu

6. Tároló architektúra (4) A tároló architektúra jellemzői (folytatás) •

A VMFS egy cluster file system, amely lehetővé teszi, hogy egyidejűleg több fizikai host olvasson ugyanabból, illetve írjon ugyanabba a tárolóba.

•

A VMFS támogatja a raw device mapping (RDM) mechanizmust, amely lehetővé teszi a fizikai tároló alrendszerek (csak Fibre Channel és iSCSI) LUN-jainak közvetlen elérését.

•

Az RDM hatékonyabbá teszi pl. az adatmentést és a snapshotok készítését.

© Schubert Tamás, ÓE NIK

368

www.tankonyvtar.hu

6. Tároló architektúra (5) Raw Device Mapping [1]

© Schubert Tamás, ÓE NIK

369

www.tankonyvtar.hu

7. A VMware vCenter szerver

© Schubert Tamás, ÓE NIK

370

www.tankonyvtar.hu

7. A VMware vCenter szerver (1) A VMware vCenter Server szolgáltatásai •

VMware vCenter Server végzi az adatközpont központi felügyeletét.

•

Egyesíti az ESX/ESXi hostok fizikai erőforrásait, és virtuális erőforrások gyűjteményét teszi elérhetővé a virtuális gépek számára.

•

A vCenter Server összetevői: o

User access control,

o

Core services,

o

Distributed services,

o

Plug-ins,

o

Various interfaces.

© Schubert Tamás, ÓE NIK

371

www.tankonyvtar.hu

7. A VMware vCenter szerver (2) vCenter Server Components [1]

© Schubert Tamás, ÓE NIK

372

www.tankonyvtar.hu

7. A VMware vCenter szerver (3) User Access Control •

User Access Control segítségével a rendszergazda különböző szintű hozzáférést biztosíthat különböző felhasználó osztályoknak.

•

Pl. egy osztály felhasználói felügyelhetik és konfigurálhatják az adatközpont fizikai szerver hardvert.

•

Pl. egy másik osztály felhasználói felügyelhetik egy cluster egy bizonyos resource poolját.

vCenter Server Core Services A Core Services alkotják a virtuális adatközpont alapvető szolgáltatásait. •

Virtual machine provisioning Irányítja és automatizálja a virtuális gépek használatbavételét, és erőforrással való ellátását.

•

Host and VM configuration Biztosítja a hostok és a virtuális gépek konfigurálását.

•

Resources and virtual machine inventory management Szervezi a virtuális gépeket és az erőforrásokat a virtuális környezetben, és biztosítja a felügyeletüket.

© Schubert Tamás, ÓE NIK

373

www.tankonyvtar.hu

7. A VMware vCenter szerver (4) vCenter Server Core Services (folytatás) •

Statistics and logging Naplót és jelentéseket készít az adatközpont elemeinek (virtual machines, hosts, storage, clusters) teljesítmény- és erőforrás kihasználás statisztikáiról.

•

Alarms and event management Nyomon követi és figyelmezteti a felhasználókat az esetleges erőforrás túlterhelésről vagy bizonyos események bekövetkezéséről. Triggerek hozhatók létre bizonyos eseményekre, és a rendszer figyelmeztetést küld, ha kritikus hibafeltételek állnak elő.

•

Task scheduler Feladat ütemező. Pl. vMotion elindítása adott időben.

•

Consolidation Analizálja az adatközpont fizikai erőforrásainak kapacitását és felhasználását. Feltérképezi a fizikai rendszereket, és javaslatot tesz azok esetleges virtualizálására és konszolidálására az ESX/ESXi környezetben. Automatizálja a konszolidációs folyamatot, és finomítja a konszolidáció paramétereit.

© Schubert Tamás, ÓE NIK

374

www.tankonyvtar.hu

7. A VMware vCenter szerver (5) vCenter Server Core Services (folytatás) •

vApp o

A vApp egy olyan szoftver megoldás, amelyet cloud operációs rendszerre optimalizáltak.

o

Logikai entitás, amely egy vagy több virtuális gépet vagy appliance-t egyetlen egységként kezel.

o

Meghatározza és befoglalja egy több rétegű alkalmazás összetevőit a működési irányelveivel és a szolgáltatási szintjével együtt.

o

A vApp becsomagolja, futtatja és menedzseli az alkalmazásokat a cloud operációs rendszer alatt.

o

Pl.: klónozás, elindítás, leállítás, monitorozás.

© Schubert Tamás, ÓE NIK

375

www.tankonyvtar.hu

7. A VMware vCenter szerver (6) Distributed services •

A Distributed Services kiterjeszti a VMware vSphere szolgáltatásait egyetlen fizikai szerveren túl.

•

Ilyen megoldások (korábban tárgyaltuk): o

VMware vMotion,

o

VMware Storage vMotion,

o

VMware Distributed Resource Scheduler – DRS,

o

VMware Storage I/O Control,

o

VMware High Availability – HA,

o

VMware Fault Tolerance – FT.

•

Az elosztott szolgáltatások központilag, egyetlen vCenter Serverrel konfigurálhatók és felügyelhetők.

•

Több vCenter Server rendszer egy összekapcsolt csoportban egyesíthető.

•

A vCenter Server csoport együttesen menedzselhető.

© Schubert Tamás, ÓE NIK

376

www.tankonyvtar.hu

7. A VMware vCenter szerver (7) vCenter Server Plug-Ins •

A Plug-ins olyan alkalmazások, amelyek külön installálhatók a vCenter Serveren, és járulékos szolgáltatásokat nyújtanak.

•

Ilyen plug-ins: o

VMware vCenter Converter Segítségével fizikai és virtuális gépek konvertálhatók ESX/ESXi virtuális gépekké. A konvertált rendszerek a vCenter Server környezet tetszőleges helyére importálható.

o

VMware Update Manager Segítségével a rendszergazdák az ESX/ESXi hostokra és a virtuális gépekre kiterjedően egy, a biztonsági szabványoknak megfelelő ún. security baseline-t hozhatnak létre. Aztán a rendszergazdák összevethetik a hostokat és a virtuális gépeket a security baseline-nal, hogy megfelelnek-e a biztonsági követelményeknek.

© Schubert Tamás, ÓE NIK

377

www.tankonyvtar.hu

7. A VMware vCenter szerver (8) vCenter Server Interfaces •

A vCenter Server interfaces integrálják a vCenter Servert más gyártók termékeivel és alkalmazásaival.

•

Ilyen interfészek: o

ESX management A vCenter Server agent interfészek a fizikai szerverek menedzseléséhez.

o

VMware vSphere API A Vmware menedzsment ügyfélprogramok, és külső gyártók megoldásainak interfészei.

o

Database interface Adatbáziskezelő rendszerek interfészei (Oracle, Microsoft SQL Server, IBM DB2), hogy virtuális gépek és hostok konfigurációinak, erőforrások, virtuális gép nyilvántartások, teljesítmény statisztikák, események, riasztások, felhasználói engedélyek és szabályok adatbázisban tárolhatók legyenek.

o

Active Directory interface Csatlakozás az Active Directory-hoz a felhasználók hozzáférésvezérlés információinak kinyerésére.

© Schubert Tamás, ÓE NIK

378

www.tankonyvtar.hu

7. A VMware vCenter szerver (9) A vCenter Server és az ESX közötti kommunikáció •

A vCenter Server az ESX/ESXi host agentekkel a VMware vSphere API segítségével kommunikál.

•

Amikor egy host először a vCenter Serverhez csatlakozik, a vCenter Server agentet installál a hoston, amely a kommunikációjukat biztosítja.

•

Az agent feladatai: o

Továbbítja és kikényszeríti a vCenter Server erőforrás allokációra vonatkozó döntéseit az ESX szerveren.

o

Továbbítja a VM indítására és konfigurálására vonatkozó parancsokat az ESX szervernek.

o

Továbbítja a host konfigurációjára vonatkozó parancsokat az ESX szervernek.

o

Összegyűjti a teljesítmény statisztikákat, riasztásokat és hibafeltételeket a hostról, és továbbítja a vCenter Serverre.

© Schubert Tamás, ÓE NIK

379

www.tankonyvtar.hu

7. A VMware vCenter szerver (10) Communication Between vCenter Server and ESX [1]

© Schubert Tamás, ÓE NIK

380

www.tankonyvtar.hu

7. A VMware vCenter szerver (11) A virtuális adatközpont elérése •

A VMware vSphere adatközpont elérésének módjai: o

vSphere Client,

o

Web Access webböngészővel (csak ESX, ESXi nem),

o

terminal services (pl.: Windows Terminal Services).

•

A hostok közvetlen elérésére általában nincs szükség, a legtöbb feladat elvégezhető a vCenter Serverből.

•

A vSphere Client a VMware API-n keresztül éri el a vCenter Server-t.

•

A felhasználó hitelesítése után a felhasználó láthatja a hozzárendelt erőforrásokat és virtuális gépeket.

•

A virtuális gép konzolos eléréséhez a vSphere Client először megkapja a vCenter Servertől a VM helyét, majd csatlakozik a megfelelő hosthoz, aztán a VM konzolhoz.

•

A vCenter Server webböngészőn keresztüli elérésében egy Apache Tomcat Server közvetít a vCenter Serveren a VMware API-n keresztül.

•

A felhasználók a VM IP-címének ismeretében a Windows Terminal Services segítségével érhetik el a VM konzolt.

© Schubert Tamás, ÓE NIK

381

www.tankonyvtar.hu

7. A VMware vCenter szerver (12) VMware vSphere Access and Control [1]

© Schubert Tamás, ÓE NIK

382

www.tankonyvtar.hu

Irodalom (1) [1]: Introduction to VMware vSphere, EN-000284-00, VMware, Inc., 2009, 2010.

© Schubert Tamás, ÓE NIK

383

www.tankonyvtar.hu

Adatközpontok Az informatikai infrastruktúra rendelkezésre állását növelő megoldások High Availability – HA Schubert Tamás

© Schubert Tamás, ÓE NIK

384

www.tankonyvtar.hu

Tartalom 1. 2. 3.

Bevezetés High Availability Cluster – Failover Cluster Hálózatok High Availability megoldásai 3.1 HA építőelemek 3.2 Hierarchikus hálózattervezési modell 3.3 Redundáns kapcsolóblokkok Irodalom

© Schubert Tamás, ÓE NIK

385

www.tankonyvtar.hu

1. Bevezetés

© Schubert Tamás, ÓE NIK

386

www.tankonyvtar.hu

1. Bevezetés (1) Magas rendelkezésre állás (High Availability) – fogalmak •

A magas rendelkezésre állás az informatikai rendszer olyan tervezési és megvalósítási protokollja, amely meghatározott ideig biztosítja a rendszer folyamatos működését.

•

Fő elvek

•

•

o

Redundancia: Tartalék (backup) képesség, amely lehetővé teszi, hogy hiba esetén a tartalék berendezések automatikusan átvegyék a szolgáltatást.

o

Rendszerhibából való állapottartó, nem észrevehető helyreállás.

o

A rendszer kiesés idejének minimumra szorítása (Minimization of Mean time to repair – MTTR).

o

Hiba előrejelzés/elkerülés – beavatkozás a hiba bekövetkezése előtt.

Tervezett és nem tervezett leállás o

Leállás karbantartás miatt.

o

Gyakran rendszerkarbantartás miatt sem megengedett a leállás.

A hibatűrő képesség többnyire kiterjed a szerverekre, tárolókra, hálózatokra.

© Schubert Tamás, ÓE NIK

387

www.tankonyvtar.hu

1. Bevezetés (2) Magas rendelkezésre állás (High Availability) – állásidő Üzemkészség, %

Állásidő/év

Állásidő/hó

Állásidő/hét

90%

36.5 nap

72 óra

16.8 óra

95%

18.25 nap

36 óra

8.4 óra

98%

7.30 nap

14.4 óra

3.36 óra

99%

3.65 nap

7.20 óra

1.68 óra

99.5%

1.83 nap

3.60 óra

50.4 perc

99.8%

17.52 óra

86.23 perc

20.16 perc

99.9% („three nines")

8.76 óra

43.2 perc

10.1 perc

99.95%

4.38 óra

21.56 perc

5.04 perc

99.99% („four nines")

52.6 perc

4.32 perc

1.01 perc

99.999% („five nines")

5.26 perc

25.9 másodperc

6.05 másodperc

99.9999% („six nines")

31.5 másodperc

2.59 másodperc

0.605 másodperc

© Schubert Tamás, ÓE NIK

388

www.tankonyvtar.hu

2. High Availability Cluster – Failover Cluster

© Schubert Tamás, ÓE NIK

389

www.tankonyvtar.hu

2. High Availability Cluster – Failover Cluster (1) High Availability Cluster – Failover Cluster •

Két vagy több szerver alkot egy HA Clustert.

•

A külvilág számára úgy tűnik, mintha egyetlen szerver végezné a szolgáltatást.

•

A Cluster egységei LAN-on vagy más dedikált hálózaton keresztül vannak összekapcsolva.

•

A szerverek ún. „heartbeat” kapcsolaton keresztül figyelik a többi résztvevő hardver és szoftver komponenseinek működését.

•

Ha hibát észlelnek, automatikusan újraindítják/folytatják az alkalmazást egy másik szerveren.

•

A cluster résztvevőinek el kell érniük a közös adattárolót (SAN, NAS).

•

A clustert többnyire egy virtuális IP-cím/név képviseli.

•

Erre az IP-címre mindig az a szerver hallgat, amelyik éppen aktív.

© Schubert Tamás, ÓE NIK

390

www.tankonyvtar.hu

2. High Availability Cluster – Failover Cluster (2) Két csomópontból álló HA Cluster hálózati elrendezése

© Schubert Tamás, ÓE NIK

391

www.tankonyvtar.hu

2. High Availability Cluster – Failover Cluster (3) A HA cluster csomópontok konfigurációi •

•

•

Aktív/Aktív o

A hibás csomópontra irányuló forgalmat egy másik csomópontra (standby szerver) irányítják, vagy a terhelést elosztják több csomópont között.

o

Teljesen homogén szoftver konfiguráció esetén használható.

Aktív/Passzív o

Minden csomópont teljes redundanciával rendelkezik.

o

A redundáns csomópontok csak meghibásodás esetén indulnak el.

o

Költséges megoldás.

N+1 o

Egyetlen tartalék csomópont áll rendelkezésre az összes aktív csomópont számára.

o

Az elsődleges csomópontok heterogén szoftver konfigurációja esetén a tartalék csomópontnak univerzálisnak kell lennie.

© Schubert Tamás, ÓE NIK

392

www.tankonyvtar.hu

2. High Availability Cluster – Failover Cluster (4) A HA cluster csomópontok konfigurációi (folytatás) •

•

•

N+M o

Ha a cluster sok szolgáltatást nyújt, több (M) standby szerverre lehet szükség.

o

A standby szerverek száma mindig kompromisszum a megbízhatóság és a költség között.

N-to-1 o

A standby szerver csak ideiglenesen válik aktívvá.

o

Mihelyt az eredeti szerver újra működőképessé válik, visszaveszi az aktív szerepkört.

N-to-N o

Az Aktív/Aktív és az N+M cluster kombinációja.

o

Nincs külön standby csomópont.

o

A szerverek extra kapacitással rendelkeznek.

o

Meghibásodás esetén a kieső csomópont szolgáltatásai szét lesznek osztva a működő csomópontok között.

© Schubert Tamás, ÓE NIK

393

www.tankonyvtar.hu

2. High Availability Cluster – Failover Cluster (5) A clusteren futó alkalmazásokkal szemben támasztott követelmények •

Nem minden alkalmazás cluster-képes.

•

Az alkalmazás tervezésének idején meg kell hozni bizonyos tervezési döntéseket, és az implementáció idején ezeket érvényesíteni kell: o

Az alkalmazásokat el kell tudni indítani, leállítani, ellenőrizni az állapotukat, vagyis az alkalmazásoknak rendelkezniük kell parancssoros interfésszel (CLI) vagy script vezérlési lehetőséggel.

o

Az alkalmazásnak képesnek kell lennie osztott tároló használatára (SAN, NAS).

o

Az alkalmazásnak annyi állapot információt kell tárolnia osztott tárolón, amennyit csak lehet.

o

Az alkalmazást el kell tudni indítani egy másik csomóponton abban az állapotban, amely az osztott tárolón rögzítve van.

o

Az alkalmazás nem teheti tönkre az adatokat sem összeomláskor, sem pedig újraindításkor.

© Schubert Tamás, ÓE NIK

394

www.tankonyvtar.hu

2. High Availability Cluster – Failover Cluster (6) A csomóponttal (szerver) támasztott követelmények •

Diszktükrözés: a belső diszk hibája ne okozzon rendszer leállást.

•

Redundáns hálózat.

•

Redundáns SAN.

•

Redundáns tápellátás (Uniterruptible Power Supply – UPS).

© Schubert Tamás, ÓE NIK

395

www.tankonyvtar.hu

3. Hálózatok High Availability megoldásai

© Schubert Tamás, ÓE NIK

396

www.tankonyvtar.hu

3.1 HA építőelemek

© Schubert Tamás, ÓE NIK

397

www.tankonyvtar.hu

3.1 HA építőelemek (1) A számítógép hálózatok HA megoldásainak jellemzői •

•

Az OSI 2. rétegű (kapcsolt) hálózati rétegében redundáns kapcsolókat és összeköttetéseket használnak. o

Hurkok elkerülése feszítőfa protokoll segítségével.

o

Hurkok elkerülése és terhelésmegosztás EtherChannel protokollal.

Az OSI 3. rétegű (irányított) hálózati rétegében redundáns forgalomirányítókat, interfészeket és összeköttetéseket használnak. o

Alternatív útvonalak.

o

Multilink (többszörös összeköttetés).

•

A redundáns összeköttetések mindkét esetben egyszerre biztosítanak tartalékképzést és terhelésmegosztást.

•

Meghibásodás esetén a tartalékra váltás teljesen automatikus, és többnyire transzparens.

•

A HA megoldások kiválasztásakor a hierarchikus hálózat tervezési modellre építünk.

© Schubert Tamás, ÓE NIK

398

www.tankonyvtar.hu

3.1 HA építőelemek (2) Feszítőfa protokoll (Spanning tree) – Redundáns összeköttetések •

A kapcsolt hálózatokban gyakran használnak redundáns összeköttetéseket.

•

Ezek növelik a megbízhatóságot, a hibatűrést.

•

A redundancia növeli a költségeket. Egyensúlyt kell teremteni a költségek és a rendelkezésre állás mértéke között.

•

A redundáns összeköttetések (fizikai hurkok) broadcast viharokat, többszörös kerettovábbítást és instabil MAC címtáblázatokat okozhatnak. S1

S3

S5 S7

S2

Munkacsoport © Schubert Tamás, ÓE NIK

S4

S6

Gerinchálózat 399

Szerverek www.tankonyvtar.hu

3.1 HA építőelemek (3) Feszítőfa protokoll (Spanning tree) – Redundáns összeköttetések •

A Spanning-Tree Protocol (STP) hurokmentes logikai hálózatot épít fel hurkokat tartalmazó fizikai hálózaton az adatkapcsolati rétegben.

•

Az STP protokoll kapcsolókból, portokból és összeköttetésekből álló logikai fastruktúrát hoz létre, amely az átviteli kapacitás szempontjából lehetőleg optimális összekötetést biztosít a kapcsolók között.

S1

Feszítőfa

S3

S5 S7

S2

Munkacsoport © Schubert Tamás, ÓE NIK

S4

S6

Gerinchálózat 400

Szerverek www.tankonyvtar.hu

3.1 HA építőelemek (4) Feszítőfa protokoll (Spanning tree) – Redundáns összeköttetések •

A kapcsolók ún. bridge protocol data unit (BPDU) keretek segítségével érintkeznek egymással.

•

A protokoll végrehajtásának eredményeképpen bizonyos kapcsolók, portok és összeköttetések blokkolt állapotba kerülnek, adattovábbítást nem végeznek.

•

Topológiaváltozás vagy meghibásodás esetén a blokkolt portok gyorsan aktív állapotba kerülhetnek és a teljes hálózat újra összefüggő lesz.

•

A feszítőfa kialakításához, újraszámolásához kb. 50 másodpercre van szükség.

•

Azon portoknak, amelyekre szervereket és munkaállomásokat kapcsolunk nem kell részt venniük a feszítőfa kialakításában, hiszen mindig kerettovábbítási üzemmódban lesznek, sosem blokkolódnak. Ha ezeket ún. „portfast” módba kapcsoljuk, azonnal képesek lesznek kerettovábbításra.

© Schubert Tamás, ÓE NIK

401

www.tankonyvtar.hu

3.1 HA építőelemek (5) EtherChannel •

Kapcsoló-kapcsoló és kapcsoló-forgalomirányító között több Ethernet alapú összeköttetés.

•

A fizikai kapcsolatok kötegelése – egyetlen logikai összeköttetésű.

•

A terhelés megoszlik a köteget alkotó összeköttetések között.

•

A Spanning-Tree protokoll nem blokkol egyetlen interfészt sem.

•

Egyszerre biztosít nagyobb rendelkezésre állást és terhelésmegosztást.

•

Interfész/kábel meghibásodás esetén a többi összeköttetés tovább működik.

•

Az Interfész/kábel megjavítása után automatikusan részt vesz a köteg munkájában. L3 kapcsoló (Multilayer Switch) Route/Switch Processorral

L3 kapcsoló (Multilayer Switch)

© Schubert Tamás, ÓE NIK

402

www.tankonyvtar.hu

3.1 HA építőelemek (6) Alternatív útvonalak irányított hálózatban •

Redundáns útvonalak forgalomirányítókat tartalmazó hálózatban.

•

A dinamikus forgalomirányító protokollok mindig a legjobb útvonalat választják ki.

•

Egy útvonal kiesése esetén a következő legjobb útvonal lép életbe.

•

A forgalomirányító táblák konvergenciájának időigényével számolni kell.

•

Bizonyos forgalomirányító protokollok lehetővé teszik az egyenlő (esetleg nem egyenlő) jóságú útvonalak egyidejű használatát (terhelésmegosztás). 2. LAN

2. útvonal

1. útvonal 1. LAN © Schubert Tamás, ÓE NIK

3. LAN 403

www.tankonyvtar.hu

3.1 HA építőelemek (7) Multilink PPP irányított hálózatban •

Forgalomirányító-forgalomirányító között több összeköttetés.

•

A kapcsolatok kötegelése – egyetlen logikai összeköttetés.

•

Adatkapcsolati protokoll: PPP (Point-to-Point Protocol).

•

A köteg egyetlen IP-címet kap.

•

Egyszerre biztosít nagyobb rendelkezésre állást és terhelésmegosztást.

•

Interfész/kábel meghibásodás esetén a többi összeköttetés tovább működik.

•

Az Interfész/kábel megjavítása után automatikusan részt vesz a köteg munkájában.

•

A csomagok tördelve is lehetnek, Round-Robin rendszerű továbbítás. WAN: • Bérelt vonal • ISDN • Frame-Relay • ATM • stb.

WAN

© Schubert Tamás, ÓE NIK

404

www.tankonyvtar.hu

3.1 HA építőelemek (8) Többrétegű kapcsolás (Layer 3 switching) •

A forgalomirányítást a hálózati rétegben a forgalomirányítók végzik.

•

A forgalomirányítást szoftveresen végzik, ami jelentősen lassítja az átvitelt.

•

A forgalomirányítási funkció elkerülhetetlen a hálózatokban.

•

A hálózat teljesítménye növelhető a 2. és a 3. rétegfunkciók kapcsolókba integrálásával. Itt kombinált hardver és szoftver megoldást alkalmaznak.

•

A Multi Layer Switching (MLS) technológia: o

A kapcsolóba beépített Route Processor segítségével az adatfolyam első csomagja alapján kiszámolja, hogy melyik kapcsolóportra kell továbbítani a csomagot.

o

Az adatfolyamra jellemző adatokat a kimenő port azonosítójával együtt gyorsító tárban helyezi el.

o

Az adatfolyam következő csomagjait a gyorsító tár bejegyzése alapján a kapcsoló modul hardveresen továbbítja.

o

A gyorsító tár bejegyzés tartalmazza a forrás és cél MAC címet, a forrás és cél IP-címet, a protokollt, és a port címeket.

o

Vannak olyan kapcsolók, amelyek beépített Route Processort nem tartalmaznak, ezek külső forgalomirányítót vesznek igénybe.

© Schubert Tamás, ÓE NIK

405

www.tankonyvtar.hu

3.2 Hierarchikus hálózattervezési modell

© Schubert Tamás, ÓE NIK

406

www.tankonyvtar.hu

3.2 Hierarchikus hálózattervezési modell (1) Hierarchikus hálózattervezési modell •

A hierarchikus hálózati tervezési modell ma a hálózatok kialakításának legjobb gyakorlata.

•

Segítségével a hálózati biztonság, a teljesítmény, a menedzselhetőség, és a méretezhetőség szem előtt tartásával tervezhetjük meg a hálózatot.

•

A tervezési modell segítségével a hálózatot rétegekre osztjuk. Minden rétegnek megvan a maga szerepe és felelőssége.

Magréteg (Core)

Elosztási réteg (Distribution) Hozzáférési réteg (Access) © Schubert Tamás, ÓE NIK

407

www.tankonyvtar.hu

3.2 Hierarchikus hálózattervezési modell (2) Hierarchikus hálózattervezési modell

© Schubert Tamás, ÓE NIK

408

www.tankonyvtar.hu

3.2 Hierarchikus hálózattervezési modell (3) Hierarchikus hálózattervezési modell - Rétegfunkciók •

A magréteg nagysebességű, redundáns gerinchálózatnak tekinthető.

•

Az elosztási réteg kapcsolókat és forgalomirányítókat tartalmaz, amelyek kapcsolatot teremtenek az alhálózatok és a VLAN-ok között.

•

A hozzáférési réteg többnyire kapcsolókat tartalmaz és a PC-ket, munkaállomásokat, munkacsoportos szervereket csatlakoztatja a hálózathoz.

Nem minden hálózat követi ezt a modellt. Általában a kisebb hálózatok egyszerűbbek ennél.

© Schubert Tamás, ÓE NIK

409

www.tankonyvtar.hu

3.2 Hierarchikus hálózattervezési modell (4) Hagyományos architektúrák •

Hozzáférési réteg: L2 kapcsoló

•

Elosztási réteg: forgalomirányító

•

Magréteg: L2 hálózat (itt FDDI)

FDDI

© Schubert Tamás, ÓE NIK

410

www.tankonyvtar.hu

3.2 Hierarchikus hálózattervezési modell (5) Hagyományos architektúrák (folytatás) •

Hozzáférési réteg: L2 kapcsoló

•

Elosztási réteg: forgalomirányító

•

Magréteg: L2 kapcsoló

© Schubert Tamás, ÓE NIK

411

www.tankonyvtar.hu

3.2 Hierarchikus hálózattervezési modell (6) Hagyományos architektúrák (folytatás) •

Hozzáférési réteg: L2 kapcsoló

•

Elosztási réteg: forgalomirányító

•

Magréteg: Redundáns L2 kapcsolók

© Schubert Tamás, ÓE NIK

412

www.tankonyvtar.hu

3.2 Hierarchikus hálózattervezési modell (7) Hagyományos architektúrák (folytatás) •

Hozzáférési réteg: L2 kapcsoló

•

Elosztási réteg: forgalomirányító

•

Magréteg: Redundáns L3 összeköttetések

© Schubert Tamás, ÓE NIK

413

www.tankonyvtar.hu

3.2 Hierarchikus hálózattervezési modell (8) Hierarchikus hálózattervezési modell – Magréteg (Core Layer) •

A magréteg nagysebességű, redundáns gerinchálózatnak tekinthető.

•

Kétféle kialakítása lehetséges: o

3. rétegű (irányított) hálózat. Forgalomirányítókat és/vagy L3-as kapcsolókat tartalmaz. Ez a preferált megoldás.

o

2. rétegű (kapcsolt) hálózat. L2-es kapcsolókat tartalmaz.

© Schubert Tamás, ÓE NIK

414

www.tankonyvtar.hu

3.2 Hierarchikus hálózattervezési modell (9) Hierarchikus hálózattervezési modell – Magréteg (Core Layer) •

Viszonylag kevés számú eszközből áll.

•

Redundancia szükséges a megbízhatóság és a rendelkezésre állás növelése érdekében.

•

Csak az elosztási réteg eszközei közötti forgalmat továbbítja.

•

Itt sosem szűrjük a hálózati forgalmat, ez a teljesítmény rovására menne. Ezt a feladatot más rétegek végzik.

© Schubert Tamás, ÓE NIK

415

www.tankonyvtar.hu

3.2 Hierarchikus hálózattervezési modell (10) Hierarchikus hálózattervezési modell – Elosztási réteg (Distribution Layer) •

Közbenső réteg a magréteg és a hozzáférési réteg között.

•

Forgalomirányítást és/vagy kapcsolást végez.

•

Itt kapcsolják össze a különböző média típusú hálózatokat (Ethernet, FDDI stb.).

•

A vállalati biztonsági politikát itt valósítják meg (pl. Access List).

•

Itt helyezik el a vállalatszerte használt szervereket, mivel ezeket sok helyről el kell érni.

•

Itt végezhető el a forgalomirányítókban az útvonalösszegzés.

•

Itt történik a szórási tartományok elválasztása (a forgalomirányítók használata miatt).

© Schubert Tamás, ÓE NIK

416

www.tankonyvtar.hu

3.2 Hierarchikus hálózattervezési modell (11) Hierarchikus hálózattervezési modell – Hozzáférési réteg (Access Layer) •

Itt csatlakoznak a számítógépek és munkacsoportos szerverek a hálózathoz.

•

Általában L2-es kapcsolókat tartalmaz.

•

Bizonyos hálózatbiztonsági feladatok itt is elvégezhetők.

•

A hozzáférési réteg kapcsolói redundáns összeköttetéssel csatlakoznak az elosztási réteghez.

•

Ha ezek 3. rétegbeli összeköttetések, nincs szükség az STP protokollra, így minden összeköttetés továbbít adatokat.

© Schubert Tamás, ÓE NIK

417

www.tankonyvtar.hu

3.2 Hierarchikus hálózattervezési modell (12) A hierarchikus hálózattervezési modell jellegzetességei •

Moduláris építő blokkokból (Building Block) épül fel.

•

Egyszerű újabb építő blokkokkal bővíteni a hálózatot.

•

A sávszélesség igény nő a hozzáférési > elosztási > magréteg láncon.

•

A hibakeresés, a problémák elhatárolása és a rendszer menedzselése egyszerű.

© Schubert Tamás, ÓE NIK

418

www.tankonyvtar.hu

3.2 Hierarchikus hálózattervezési modell (13) A hierarchikus hálózattervezési modell – Redundáns hálózati csomópontok

© Schubert Tamás, ÓE NIK

419

www.tankonyvtar.hu

3.2 Hierarchikus hálózattervezési modell (14) A hierarchikus hálózattervezési modell – Redundáns hálózati csomópontok •

A hozzáférési rétegben fordulhat elő olyan meghibásodás, amely lehetetlenné teszi a számítógépek/szerverek munkáját (Single Point of Failure).

•

A munkaállomásokban általában nem alkalmaznak kettős csatlakozást a hozzáférési réteghez.

•

Adatközpontokban ezzel szemben ez a gyakori. Ekkor a szerver hálózati interfészei külön-külön kapcsolóhoz csatlakoznak.

© Schubert Tamás, ÓE NIK

420

www.tankonyvtar.hu

3.3 Redundáns kapcsolóblokkok

© Schubert Tamás, ÓE NIK

421

www.tankonyvtar.hu

3.3 Redundáns kapcsolóblokkok (1) Kapcsoló egység (Switch Block) Distributed switch (DSW): L3 kapcsoló

A A

DSW 1

B

DSW 1 © Schubert Tamás, ÓE NIK

B

DSW 2

DSW 2 422

www.tankonyvtar.hu

3.3 Redundáns kapcsolóblokkok (2) Kapcsoló egység (Switch Block) A hozzáférési kapcsolókban VLAN-okat használunk: •

STP protokoll működik, a hozzáférési kapcsolónak csak egy portja van továbbító állapotban VLAN-onként.

•

Az L3-as kapcsolóban a VLAN-t egy virtuális interfész képviseli. VLAN-ok: 2 3 4 5

2 3

f2 f3 Link A

f2 f3 b3 b2

f4 f5 b5 b4

4 5

f4 f5 b5 b4

Link B

L2 t r ö n k ö k f: forwarding b: blocked L2 trönk

DSW 1 © Schubert Tamás, ÓE NIK

DSW 2 423

www.tankonyvtar.hu

3.3 Redundáns kapcsolóblokkok (3) Közvetlen SB kapcsolat a magrétegben •

Átjárás a két blokk között Switch Block 1

Switch Block 2

Access Layer

Access Layer

Core Connectivity Distribution/Core Layer

Distribution/Core Layer

Core Connectivity © Schubert Tamás, ÓE NIK

424

www.tankonyvtar.hu

3.3 Redundáns kapcsolóblokkok (4) Közvetlen SB kapcsolat a magrétegben •

Meghibásodás Switch Block 1

Switch Block 2

Access Layer

Access Layer

Core Connectivity Distribution/Core Layer

Distribution/Core Layer

Core Connectivity © Schubert Tamás, ÓE NIK

425

www.tankonyvtar.hu

3.3 Redundáns kapcsolóblokkok (5) Közvetlen SB kapcsolat a magrétegben •

A tartalék kapcsolat belép Switch Block 1

Switch Block 2

Access Layer

Access Layer

Core Connectivity Distribution/Core Layer

Distribution/Core Layer

Core Connectivity © Schubert Tamás, ÓE NIK

426

www.tankonyvtar.hu

3.3 Redundáns kapcsolóblokkok (6) Kiépített magréteg

M2

M

A

P

P2

M1

B

D

C

A épület

B épület X

© Schubert Tamás, ÓE NIK

P1

Y 427

www.tankonyvtar.hu

3.3 Redundáns kapcsolóblokkok (7) Kiépített magréteg •

Meghibásodás M2

M

A

P

P2

M1

B

C

D

A épület © Schubert Tamás, ÓE NIK

P1

B épület X

428

Y

www.tankonyvtar.hu

3.3 Redundáns kapcsolóblokkok (8) Kiépített magréteg •

Meghibásodás M2

M

A

P

P2

M1

B

D

C

A épület

B épület X

© Schubert Tamás, ÓE NIK

P1

429

Y www.tankonyvtar.hu

3.3 Redundáns kapcsolóblokkok (9) Kiépített magréteg •

Meghibásodás M2

M

A

P

P2

M1

B

D

C

A épület

B épület X

© Schubert Tamás, ÓE NIK

P1

430

Y www.tankonyvtar.hu

3.3 Redundáns kapcsolóblokkok (10) A hierarchikus hálózattervezési modell – A magréteg elhagyásának hátrányai •

Az építő blokkok számának növekedésével rohamosan növekszik az összeköttetések száma.

•

Az irányítóprotokoll szomszédsági kapcsolatai is növekednek, ami a hatékonyságot csökkenti. 2. blokk: + 4 új vonal 3 IGP szomszéd

4. blokk: + 12 új vonal 7 IGP szomszéd

IGP –

3. blokk: + 8 új vonal 5 IGP szomszéd

Interior Gateway Protocol

© Schubert Tamás, ÓE NIK

1. blokk 431

www.tankonyvtar.hu

3.3 Redundáns kapcsolóblokkok (11) A hierarchikus hálózattervezési modell – A magréteg kiépítésének előnyei •

A hátrányok kiküszöbölése.

•

Jobb méretezhetőség.

© Schubert Tamás, ÓE NIK

432

www.tankonyvtar.hu

Irodalom (1) [1]: Campus Network for High Availability Design Guide, Cisco Validated Design, May 21, 2008, hacampusdg.pdf.

© Schubert Tamás, ÓE NIK

433

www.tankonyvtar.hu

Multicore-Manycore Processors Dezső Sima

© Sima Dezső, ÓE NIK

434

www.tankonyvtar.hu

Contents •

1.The inevitable era of multicores

•

2. Homogeneous multicores •

2.1 Conventional multicores

•

2.2 Many-core processors

•

3. Heterogeneous multicores •

3.1 Master-slave type heterogeneous multicores

•

3.2 Add-on type heterogeneous multicores

•

4. Outlook

•

5. References

© Sima Dezső, ÓE NIK

435

www.tankonyvtar.hu

1. The inevitable era of multicores

© Sima Dezső, ÓE NIK

436

www.tankonyvtar.hu

1. The inevitable era of multicores (1) 1. The inevitable era of multicores Integer performance grows SPECint92

Levelling off

10000

P4/3200 * * Prescott (2M) * * *Prescott (1M) P4/3060 * Northwood B P4/2400 * **P4/2800 P4/2000 * *P4/2200 P4/1500 * * P4/1700 PIII/600 PIII/1000 * **PIII/500 PII/400 * PII/300 * PII/450 *

5000 2000 1000 500

* Pentium Pro/200 Pentium/200 * * * Pentium/166 Pentium/133 * Pentium/120 Pentium/100 * Pentium/66* * 486-DX4/100 486/50 * 486-DX2/66 * * 486/33 486-DX2/50 *

~ 100*/10 years

200 100 50 20

486/25 * 10 386/20

5

386/16 *

*

80286/12 *

2 80286/10

1

8088/8 0.5 0.2

* 386/33 * 386/25

*

*

*

8088/5

79

1980 81

Year 82

83

84

85

86

87

88

89 1990

91

92

93

94

95

96

97

98

99 2000

01

02

Figure 1.1: Integer performance growth of Intel’s x86 processors

© Sima Dezső, ÓE NIK

437

03

04

05

www.tankonyvtar.hu

1. The inevitable era of multicores (2) Performance (Pa)

Pa = fC x IPC

Clock frequency x Instructions Per Cycle

Pa

© Sima Dezső, ÓE NIK

=

Clock frequency

x

438

Efficiency (Pa/fC)

www.tankonyvtar.hu

1. The inevitable era of multicores (3)

SPECint_base2000/ f c

2. generation superscalars Levelling off

1 0.5

*

~10*/10 years

0.2

* 0.1 *

0.05

0.02 0.01

386DX

486DX

Pentium Pro Pentium II * * * * * Pentium III * * Pentium

*

*

* 286 ~ ~ 78

Year 79 1980 81

82

83

84

85

86

87

88

89 1990 91

92

93

94

95

96

97

98

99 2000 01

02

Figure 1.2: Efficiency of Intel processors

© Sima Dezső, ÓE NIK

439

www.tankonyvtar.hu

1. The inevitable era of multicores (4) Main sources of processor efficiency (IPC)

Processor width

1

2

4

Core enhancements

Cache enhancements

• branch prediction • speculative loads • ...

L2/L3 enhancements (size, associativity ...)

superscalar pipeline 1. Gen. 2. Gen.

Figure 1.3: Main sources of processor efficiency

© Sima Dezső, ÓE NIK

440

www.tankonyvtar.hu

1. The inevitable era of multicores (5)

Figure 1.4: Extent of parallelism available in general purpose applications for 2. generation superscalars [37] © Sima Dezső, ÓE NIK

441

www.tankonyvtar.hu

1. The inevitable era of multicores (6) Main sources of processor efficiency (IPC)

Processor width

1

2

4

Core enhancements

Cache enhancements

• branch prediction • speculative loads • ...

L2/L3 enhancements (size, associativity ...)

superscalar pipeline 1. Gen. 2. Gen.

Figure 1.5: Main sources of processor efficiency

© Sima Dezső, ÓE NIK

442

www.tankonyvtar.hu

1. The inevitable era of multicores (7)

Beginning with 2. generation superscalars • the era of extensively increasing processor efficiency came to an end • processor efficiency levelled off.

Pa = fC x IPC

Clock frequency x Instructions Per Cycle

Performance increase can basically be achived by fc

© Sima Dezső, ÓE NIK

443

www.tankonyvtar.hu

1. The inevitable era of multicores (8)

Shrinking: ~ 0.7/2 Years

Figure 1.6: Evolution of Intel’s process technology [38] © Sima Dezső, ÓE NIK

444

www.tankonyvtar.hu

1. The inevitable era of multicores (9)

Figure 1.7: The actual rise of IC complexity in DRAMs and microprocessors [39] © Sima Dezső, ÓE NIK

445

www.tankonyvtar.hu

1. The inevitable era of multicores (10) Main sources of processor efficiency (IPC)

Processor width

1

2

4

Core enhancements

Cache enhancements

• branch prediction • speculative loads • ...

L2/L3 enhancements (size, associativity ...)

superscalar pipeline 1. Gen. 2. Gen.

Doubling transistor counts ~ every two years

What is the best use of ever increasing number of processors ??? © Sima Dezső, ÓE NIK

446

Moore’s law www.tankonyvtar.hu

1. The inevitable era of multicores (11) IC fab technology ~ Doubling transistor counts / 2 years

(Linear shrink ~ 0.7x/2 years)

Moore’s law Possible use of surplus transistors

Processor width

1

2

4

Core enhancements

Cache enhancements

• branch prediction • speculative loads • ...

L2/L3 enhancements (size, associativity ...)

superscalar pipeline 1. Gen. 2. Gen.

Figure 1.8: Possible use of surplus transistors © Sima Dezső, ÓE NIK

447

www.tankonyvtar.hu

1. The inevitable era of multicores (12)

Increasing number of transistors

Diminishing return in performance

Use available surplus transistors for multiple cores

The inevitable era of multicores

© Sima Dezső, ÓE NIK

448

www.tankonyvtar.hu

1. The inevitable era of multicores (13)

Figure 1.9: Rapid spreading of Intel’s multicore processors [40] © Sima Dezső, ÓE NIK

449

www.tankonyvtar.hu

2. Homogeneous multicores

•

2.1 Conventional multicores

•

2.2 Manycore processors

© Sima Dezső, ÓE NIK

450

www.tankonyvtar.hu

2. Homogeneous multicores (1) Multicore processors

Heterogeneous multicores

Homogeneous multicores

Conventional multicores 2≤

Mobiles

n≤8

Manycore processors

cores

Desktops

Master/slave type multicores

Add-on type multicores

with >8 cores

Servers MPC CPU

General purpose computing © Sima Dezső, ÓE NIK

Prototypes/ experimental systems

MM/3D/HPC production stage

Figure 2.1: Major classes451 of multicore processors

GPU

HPC

www.tankonyvtar.hu

2.1 Conventional multicores

•

2.1.1 Example: Intel’s MP servers

© Sima Dezső, ÓE NIK

452

www.tankonyvtar.hu

2.1 Conventional multicores (1) Multicore processors

Heterogeneous multicores

Homogeneous multicores

Conventional multicores 2≤

Mobiles

n≤8

Manycore processors

cores

Desktops

Master/slave type multicores

Add-on type multicores

with >8 cores

Servers MPC CPU

General purpose computing © Sima Dezső, ÓE NIK

Prototypes/ experimental systems

MM/3D/HPC production stage

Figure 2.1: Major classes453 of multicore processors

GPU

HPC

www.tankonyvtar.hu

2.1.1 Example: Intel’s MP servers •

2.1.1.1 Introduction

•

2.1.1.2 The Pentium 4 based Truland MP platform

•

2.1.1.3 The Core 2 based Caneland MP platform

•

2.1.1.4 The Nehalem-EX based Boxboro-EX MP platform

•

2.1.1.5 Evolution of MP platforms

© Sima Dezső, ÓE NIK

454

www.tankonyvtar.hu

2.1.1.1 Introduction (1) 2.1.1.1 Introduction

Servers

Uni-Processors (UP)

© Sima Dezső, ÓE NIK

Dual Processors (DP)

Multi Processors (typically 4 processors) (MP)

455

Servers with more than 8 processors

www.tankonyvtar.hu

2.1.1.1 Introduction (2) Basic Arch.

Pentium 4 (Prescott)

Core/technology

MP server processors

Pentium 4

90 nm

11/2005

Pentium 4

65 nm

8/2006

7100 (Tulsa)

Core2

65 nm

9/2007

7200 (Tigerton DC) 7300 (Tigerton QC)

1x2 C, 4 MB L2/C 2x2 C, 4 MB L2/C

Penryn

45 nm

9/2008

7400 (Dunnington)

1x6 C, 3 MB L2/2C 16 MB L3

Nehalem-EP

45 nm

Westmere-EP

32 nm

Nehalem-EX

45 nm

3/2010

7500 (Beckton)

1x8 C, ¼ MB L2/C 24 MB L3

Westmere-EX

32nm

4/2011

Sandy Bidge

32 nm

/2011

Ivy Bridge

22 nm

11/2012

Core 2

Paxville MP

2x1 C, 2 MB L2/C

2x1 C, 1 MB L2/C 16 MB L3

Nehalem

Sandy Bridge

© Sima Dezső, ÓE NIK

E7-48xx (Westmere-EX)

456 multicore MP servers Table 2.1: Overview of Intel’s

1x10 C, ¼ MB L2/C 30 MB L3

www.tankonyvtar.hu

2.1.1.1 Introduction (3)

MP server platforms

Pentium 4 based MP server platform

Core 2 based MP server platform

Nehalem-EX based MP server platform

Sandy Bridge based MP server platform

Truland (2005) (90 nm/65 nm Pentium 4 Prescott MP based)

Caneland (2007)

Boxboro-EX (2010)

To be announced yet

© Sima Dezső, ÓE NIK

457

www.tankonyvtar.hu

2.1.1.2 The Pentium 4 Prescott MP based Truland MP server platform (1) 2.1.1.2 The Pentium 4 Prescott MP based Truland MP server platform Overview Remark For presenting a more complete view of the evolution of multicore MP server platforms we include also the single core (SC) 90 nm Pentium 4 Prescott based Xeon MP (Potomac) processor that was the first 64-bit MP server processor and gave rise to the Truland platform.

© Sima Dezső, ÓE NIK

458

www.tankonyvtar.hu

2.1.1.2 The Pentium 4 Prescott MP based Truland MP server platform (2) 3/2005 MP platforms

Truland 3/2005

MP cores

11/2005 Truland( updated) 11/2005

8/2006

Xeon MP

Xeon 7000

Xeon 7100

(Potomac) 1C

(Paxville MP) 2x1C

(Tulsa) 2C

90 nm/675 mtrs 90 nm/2x169 mtrs 65 nm/1328 mtrs 1 MB L2 2x1 (2) MB L2 2x1 MB L2 8/4 MB L3 16/8/4 MB L3 667 MT/s 800/667 MT/s 800/667 MT/s mPGA 604 mPGA 604 mPGA 604 3/2005 MCH

11/2005

E8500

E8501

(Twin Castle)

(Twin Castle?)

2xFSB 667 MT/s HI 1.5 4 x XMB (2 channels/XMB 4 DIMMs/channel DDR-266/333 DDR2-400 32GB

2xFSB 800 MT/s HI 1.5 4 x XMB (2 channels/XMB 4 DIMMs/channel DDR-266/333 DDR2-400 32GB

4/2003 ICH

Pentium 4 based

ICH5

Core 2 based Penryn based

© Sima Dezső, ÓE NIK

Pentium 4-based/90 nm459

Pentium 4-based/65 nm

www.tankonyvtar.hu

2.1.1.2 The Pentium 4 Prescott MP based Truland MP server platform (3) 3/02

11/02

^

^

Foster-MP

Gallatin

0.18 µ /108 mtrs 1.4/1.5/1.6 GHz

0.13 µ /178 mtrs 1.5/1.9/2 GHz

On-die 256K L2 On-die 512K/1M L3 400 MHz FSB µ PGA 603

On-die 512K L2 On-die 1M/2M L3 400 MHz FSB µ PGA 603

Xeon - MP line

Xeon DP line

2Q/05

3/04

^

^

Potomac

Gallatin

0.09µ > 3.5 MHz

0.13 µ /286 mtrs 2.2/2.7/3.0 GHz

On-die 1M L2 On-die 8M L3 (?)

On-die 512K L2 On-die 2M/4M L3 400 MHz FSB µ PGA 603

5/01

2/02

11/02

7/03

6/04

^

^

^

^

^

2Q/05

^

Foster

Prestonia-A

Prestonia-B

Prestonia-C

Nocona

Jayhawk

0.18 µ /42 mtrs 1.4/1.5/1.7 GHz

0.13 µ /55 mtrs 1.8/2/2.2 GHz

0.09µ 3.8 GHz

On-die 512K L2 400 MHz FSB µ PGA 603

0.13 µ/178 mtrs 3.06 GHz On-die 512K L2, 1M L3 533 MHz FSB µ PGA 603

0.09 µ/ 125 mtrs 2.8/3.0/3.2/3.4/3.6 GHz

On-die 256 K L2 400 MHz FSB µPGA 603

0.13 µ /55 mtrs 2/2.4/2.6/2.8 GHz On-die 512K L2 533 MHz FSB µ PGA 603

On-die 1M L2 800 MHz FSB µ PGA 604

On-die 1M L2 (Cancelled 5/04)

Extreme Edition

11/03

11/04

1Q/05

^

^

^

Irwindale-B1

Irwindale-A1 0.13µ /178 mtrs 3.2EE GHz On-die 512K L2, 2M L3 800 MHz FSB µPGA 478

Desktop-line

11/00

8/01

1/02

5/02

11/02

5/03

2/04

^

^

^

^

^

^

^

^

Willamette

Willamette

0.18 µ /42 mtrs

0.18 µ /42 mtrs

1.4/1.5 GHz On-die 256K L2 400 MHz FSB

1.4 ... 2.0 GHz On-die 256K L2 400 MHz FSB

µ PGA 423

µ PGA 478

Northwood-A2,3

Northwood-B 4

Willamette-128 0.18µ 1.7 GHz On-die 128K L2 400 MHz FSB

µPGA 478

2001 Cores supporting hyperthreading

µPGA604

8/04

3Q/05

^

Prescott

8,9,10

^ Prescott-F11

Tejas

0.13 µ /55 mtrs 0.09µ /125mtrs 0.09 µ / 0.09µ /125mtrs 0.13 µ /55 mtrs 0.13 µ /55 mtrs 0.09µ /125mtrs 3.06 GHz 2.40C/2.60C/2.80C GHz 2.80E/3E/3.20E/3.40E GHz 2.8/3.0/3.2/3.4/3.6 GHz 3.20F/3.40F/3.60F GHz 4.0/4.2 GHz 2.26/2.40B/2.53 GHz 2A/2.2 GHz On-die 1M L2 On-die 1M L2 On-die 512K L2 On-die 512K L2 On-die 512K L2 On-die 1M L2 On-die 1M L2 On-die 512K L2 (Cancelled 5/04) 800 MHz FSB 800 MHz FSB 533 MHz FSB 533 MHz FSB 800 MHz FSB 800 MHz FSB 400 MHz FSB µ PGA 478 µPGA 478 LGA 775 LGA 775 µPGA 478 µ PGA 478 µ PGA 478

^

2000

Prescott 6,7

0.09 µ 3.0/3.2/3.4/3.6 GHz On-die 512K L2, 2M L3

0.13 µ /55 mtrs

5/02

Celeron-line (Value PC-s)

Northwood-B

Northwood-C5

Irwindale-C

0.13µ /178mtrs 3.4EE GHz On-die 512K L2, 2 MB L3 1066 MHz FSB LGA 775 6/04

2/05

9/02

6/04

9/04

^

^

^

Northwood-128

Celeron-D12

0.13µ 2 GHz On-die 128K L2 400 MHz FSB

0.09µ 2.4/2.53/2.66/2.8 GHz On-die 256K L2 533 MHz FSB µ PGA 478

µPGA 478

2002

2003

Cores with EM64T implemented but not enabled

Celeron-D13 0.09µ 2.53/2.66/2.80/2.93 GHz On-die 256K L2 533 MHz FSB LGA 775

2005

2004 Cores supporting EM64T

Figure 2.2: The Potomac processor as Intel’s first 64-bit Xeon MP processor based on the 460 Pentium 4 family of processors www.tankonyvtar.hu © Sima Dezső, ÓE NIK third core (Prescott core) of the

2.1.1.2 The Pentium 4 Prescott MP based Truland MP server platform (4) Basic system architecture of the 90 nm Pentium 4 Prescott MP based Truland MP server platform Xeon MP Xeon 7000 Xeon 7100 / / (Potomac) 1C (Paxville MP) 2x1C (Tulsa) 2C

Pentium 4 Xeon 1C/2x1C

Pentium 4 Xeon 1C/2x1C

Pentium 4 XeonP 1C/2x1C

Pentium 4 XeonP 1C/2x1C

FSB

XMB 85001/8501 XMB

XMB: eXxternal Memory Bridge Provides a serial link, 5.33 GB inbound BW 2.65 GB outbound BW (simultaneously)l

XMB XMB

HI 1.5 DDR-266/333 DDR2-400

ICH5

DDR-266/333 DDR2-400

HI 1.5 (Hub Interface 1.5) 8 bit wide, 66 MHz clock, QDR, 66 MB/s peak transfer rate

Pentium 4 Prescott MP based Truland MP server platform (for up to 2 cores)

1

© Sima Dezső, ÓE NIK

The E8500 MCH supports an FSB of 667 MT/s and consequently only the SC Xeon MP (Potomac)

461

www.tankonyvtar.hu

2.1.1.2 The Pentium 4 Prescott MP based Truland MP server platform (5) Expanding the Truland platform to 3 generations of Pentium 4 based Xeon MP servers

Xeon MP 1C

Xeon 7000 2x1C

Xeon 7100 2C

Figure 2.3: Expanding the Truland platform [1]

© Sima Dezső, ÓE NIK

462

www.tankonyvtar.hu

2.1.1.2 The Pentium 4 Prescott MP based Truland MP server platform (6) Example 1: Block diagram of a 8500 chipset based Truland MP server board [2]

Figure 2.4: Block diagram of a 8500 chipset based Truland MP server board [2] © Sima Dezső, ÓE NIK

463

www.tankonyvtar.hu

2.1.1.2 The Pentium 4 Prescott MP based Truland MP server platform (7) Example 2: Block diagram of the E8501 based Truland MP server platform [3]

Xeon DC MP 7000 (4/2005) or later DC/QC MP 7000 processors

IMI: Independent Memory Interface IMI: Serial link 5.33 GB inbound BW 2.67 GB outbound BW simultaneously XMB: eXxternal Memory Bridge

(North Bridge)

Intelligent MC Dual mem. channels DDR 266/333/400 4 DIMMs/channel

Figure 2.5: Intel’s 8501 chipset based Truland MP server platform (4/ 2006) [3] © Sima Dezső, ÓE NIK

464

www.tankonyvtar.hu

2.1.1.2 The Pentium 4 Prescott MP based Truland MP server platform (8) Example 3: E8501 based MP server board implementing the Truland platform

2 x XMB

DDR2 DIMMs

Xeon DC

64 GB

7000/7100

2 x XMB

E8501 NB

ICH5R SB

Figure 2.6: Intel E8501 chipset based MP server board (Supermicro X6QT8) for the Xeon 7000/7100 DC MP processor families [4]

© Sima Dezső, ÓE NIK

465

www.tankonyvtar.hu

2.1.1.2 The Pentium 4 Prescott MP based Truland MP server platform (9)

Figure 2.7: Bandwith bottlenecks in Intel’s 8501 based Truland MP server platform [5] © Sima Dezső, ÓE NIK

466

www.tankonyvtar.hu

2.1.1.2 The Pentium 4 Prescott MP based Truland MP server platform (10) Remark Previous (first generation) MP servers made use of a symmetric topology including only a single FSB that connects all 4 single core processors to the MCH (north bridge), as shown below. Typical system architecture of a first generation Xeon MP based MP server platform

Xeon MP1 SC

Xeon MP1 SC

Xeon MP1 SC

Xeon MP1 SC

FSB

Preceding NBs E.g. DDR-200/266

E.g. HI 1.5

Preceding ICH

E.g. DDR-200/266

HI 1.5 266 MB/s

Figure 2.8: Previous Pentium 4 MP based MP server platform (for single core processors) © Sima Dezső, ÓE NIK

467

www.tankonyvtar.hu

2.1.1.2 The Pentium 4 Prescott MP based Truland MP server platform (11) Example: Block diagram of an MP server board that is based on Pentium 4 (Willamette MP) single core 32-bit Xeon MP processors (called Foster)

The memory is placed on an extra card. There are 4 memory controllers each supporting 4 DIMMs (DDR-266/200) The chipset (CMIC/CSB5) is ServerWorks’ Grand Champion HE Classic chipset

Figure 2.9: Block diagram of an MP server board [6] © Sima Dezső, ÓE NIK

468

www.tankonyvtar.hu

2.1.1.2 The Pentium 4 Prescott MP based Truland MP server platform (12) Evolution from the first generation MP servers supporting SC processors to the 90 nm Pentium 4 Prescott MP based Truland MP server platform (supporting up to 2 cores) Xeon MP Xeon 7000 Xeon 7100 / / (Potomac) 1C (Paxville MP) 2x1C (Tulsa) 2C

Xeon MP1 SC

Xeon MP1 SC

Xeon MP1 SC

Pentium 4 Xeon MP 1C/2x1C

Xeon MP1 SC

Pentium 4 Xeon MP 1C/2x1C

Pentium 4 Xeon MP 1C/2x1C FSB

FSB

XMB Preceding NBs

85001/8501 XMB

E.g. HI 1.5

E.g. DDR-200/266

Pentium 4 Xeon MP 1C/2x1C

E.g. DDR-200/266

XMB XMB

HI 1.5 DDR-266/333 DDR2-400

Preceding ICH

ICH5

DDR-266/333 DDR2-400

HI 1.5 266 MB/s

90 nm Pentium 4 Prescott MP based Truland MP server platform (for up to 2 C)

Previous Pentium 4 MP based MP server (for single core processors)

© Sima Dezső, ÓE NIK

469

www.tankonyvtar.hu

2.1.1.3 The Core 2 based Caneland MP server platform (1) 2.1.1.3 The Core 2 based Caneland MP server platform

© Sima Dezső, ÓE NIK

470

www.tankonyvtar.hu

2.1.1.3 The Core 2 based Caneland MP server platform (2) 9/2007 MP platforms

Caneland 9/2007

MP cores

Xeon 7200

9/2008 Xeon 7300

Xeon 7400

(Tigerton DC) 1x2C (Tigerton QC) 2x2C 65 nm/2x291 mtrs 65 nm/2x291 mtrs

(Dunnington 6C) 45 nm/1900 mtrs

2x4 MB L2 -

2x(4/3/2) MB L2 -

9/6 MB L2 16/12/8 MB L3

1066 MT/s mPGA 604

1066 MT/s mPGA 604

1066 MT/s mPGA 604

9/2007 MCH

E7300 (Clarksboro) 4xFSB 1066 MT/s ESI 4 x FBDIMM (DDR2-533/667 8 DIMMs/channel) 512GB

5/2006 ICH

Pentium 4 based

631xESB 632xESB

Core 2 based Penryn based

© Sima Dezső, ÓE NIK

Core2-based/65 471 nm

Penryn 45 nm

www.tankonyvtar.hu

2.1.1.3 The Core 2 based Caneland MP server platform (3) Basic system architecture of the Core 2 based Caneland MP server platform

Xeon MP Xeon 7000 Xeon 7100 / / (Potomac) 1C (Paxville MP) 2x1C (Tulsa) 2C

Pentium 4 Xeon MP 1C/2x1C

Pentium 4 Xeon MP 1C/2x1C

Pentium 4 Xeon MP 1C/2x1C

Pentium 4 Xeon MP 1C/2x1C

Xeon 7200 Xeon 7300 Xeon 7400 / / (Tigerton DC) 1x2C (Tigerton QC) 2x2C (Dunnington 6C)

Core2 (2C/4C) Penryn (6C)

FSB

XMB 85001/8501 XMB

Core2 (2C/4C) Penryn (6C)

Core2 (2C/4C) Penryn (6C)

Core2 (2C/4C) Penryn (6C)

FSB

XMB

up to 8 DIMMs

7300

XMB ESI

HI 1.5

DDR-266/333 DDR2-400

ICH5

DDR-266/333 DDR2-400

631xESB/ 632xESB

90 nm Pentium 4 Prescott MP based Truland MP server platform (for up to 2 C)

Core 2 based Caneland MP server platform (for up to 6 C)

ESI: Enterprise System Interface 4 PCIe lanes, 0.25 GB/s per lane (like the DMI interface, providing 1 GB/s transfer rate in each direction)

HI 1.5 (Hub Interface 1.5) 8 bit wide, 66 MHz clock, QDR, 66 MB/s peak transfer rate 1

© Sima Dezső, ÓE NIK

FBDIMM DDR2-533/667

The E8500 MCH supports an FSB of 667 MT/s and consequently only the SC Xeon MP (Potomac)

472

www.tankonyvtar.hu

2.1.1.3 The Core 2 based Caneland MP server platform (4) Example 1: Intel’s Nehalem-EP based Tylersburg-EP DP server platform with a single IOH Xeon 7200 (Tigerton DC, Core 2), 2C 7300 (Tigerton QC, Core 2), QC

FB-DIMM 4 channels 8 DIMMs/channel up to 512 GB

Figure 2.10: Intel’s 7300 chipset based Caneland platform for the Xeon 7200/7300 DC/QC processors (9/2007) [7] © Sima Dezső, ÓE NIK

473

www.tankonyvtar.hu

2.1.1.3 The Core 2 based Caneland MP server platform (5) Example 3: Caneland MP serverboard

Xeon

FB-DIMM DDR2

7200 DC 7300 QC (Tigerton)

192 GB

ATI ES1000 Graphics with 32MB video memory

7300 NB

SBE2 SB

Figure 2.11: Caneland MP Supermicro serverboard, with the 7300 (Clarksboro) chipset for the Xeon 7200/7300 DC/QC MP processor families [4]

© Sima Dezső, ÓE NIK

474

www.tankonyvtar.hu

2.1.1.3 The Core 2 based Caneland MP server platform (6)

Figure 2.12: Performance comparison of the Caneland platform with a quad core Xeon (7300 family) vs the Bensley platform with a dual core Xeon 7140M [8] © Sima Dezső, ÓE NIK

475

www.tankonyvtar.hu

2.1.1.4 The Nehalem-EX based Boxboro-EX MP server platform (1) 2.1.1.4 The Nehalem-EX based Boxboro-EX MP server platform

© Sima Dezső, ÓE NIK

476

www.tankonyvtar.hu

2.1.1.4 The Nehalem-EX based Boxboro-EX MP server platform (2) 3/2010 Boxboro-EX

MP platforms

MP cores

3/2010

4/2011

Xeon 7500

Xeon E7-4800

(Nehalem-EX) (Becton) 8C

(Westmere-EX) 10C

45 nm/2300 mtrs/513 mm2 ¼ MB L2/C 24 MB L3 4 QPI links 4 SMI links 2 mem. channels/link 2 DIMMs/mem. channel DDR3 1067 MT/s 1 TB (64x16 GB) LGA1567

32 nm/2600 mtrs/584 mm2 ¼ MB L2/C 30 MB L3 4 QPI links 4 SMI links 2 mem. channels/link 2 DIMMs/mem. channel DDR3 1333 MT/s 1 TB (64x16 GB) LGA1567

3/2010 7500

IOH

(Boxboro) 2 QPI links 32xPCIe 2. Gen. 0.5 GB/s/lane/direction ESI 1GB/s/directon 6/2008 ICH

© Sima Dezső, ÓE NIK

ICH10

Nehalem-EX-based 45 nm 477

Westmere-EX 45 nm

www.tankonyvtar.hu

2.1.1.4 The Nehalem-EX based Boxboro-EX MP server platform (3) The 8 core Nehalem-EX (Xeon 7500/Beckton) Xeon 7500 MP server processor

2 cores

Figure 2.13: The 8 core Nehalem-EX (Xeon 7500/Beckton) Xeon 7500 MP server processor [9] © Sima Dezső, ÓE NIK

478

www.tankonyvtar.hu

2.1.1.4 The Nehalem-EX based Boxboro-EX MP server platform (4) The 10 core Westmere-EX (Xeon E7-!800) MP server processor [10]

© Sima Dezső, ÓE NIK

479

www.tankonyvtar.hu

2.1.1.4 The Nehalem-EX based Boxboro-EX MP server platform (5) Block diagram of the Westmere-EX (E7-8800/4800/2800) processors [11]

E7-8800: for 8 P systems E7-4800: for MP systems E7-2800: for DP systems

© Sima Dezső, ÓE NIK

480

www.tankonyvtar.hu

2.1.1.4 The Nehalem-EX based Boxboro-EX MP server platform (6) Main platform features introduced in the 7500 Boxboro IOH (1) Along with their Nehalem-EX based Boxboro platform Intel continued their move to increase system security and manageability by introducing platform features provided else by their continuously enhanced vPro technology for enterprise oriented desktops since 2006 and DP servers since 2007. The platform features introduced in the 7500 IOH are basically the same as described for the Tylersburg-EP DP platform that is based on the 5500 IOH which is akin to the 7500 IOH of the Boxboro-EX platform. They include: a) Intel Management Engine (ME) b) Intel Virtualization Technology for Directed I/O (VT-d2) VT-d2 is an upgraded version of VT-d. c) Intel Trusted Execution Technology (TXT) .

© Sima Dezső, ÓE NIK

481

www.tankonyvtar.hu

2.1.1.4 The Nehalem-EX based Boxboro-EX MP server platform (7) Basic system architecture of the Nehalem-EX based Boxboro-EX MP server platform (assuming 1 IOH) Xeon 7500 (Nehalem-EX) (Becton) 8C

SMB SMB SMB

/

Xeon 7-4800 (Westmere-EX) 10C SMB

Nehalem-EX 8C Westmere-EX 10C

Nehalem-EX 8C Westmere-EX 10C

QPI

SMB SMB SMB

SMB

QPI

QPI

QPI

QPI

SMB SMB SMB

SMB Nehalem-EX 8C Westmere-EX 10C

SMB

Nehalem-EX 8C Westmere-EX 10C

QPI

QPI

DDR3-1067

SMB SMB SMB

QPI

2x4 SMI channels

2x4 SMI channels

7500 IOH ESI

ICH10

DDR3-1067

ME

SMI: Serial link between the processor and the SMB SMB: Scalable Memory Buffer Parallel/serial conversion ME: Management Engine

Nehalem-EX based Boxboro-EX MP server platform (for up to 10 C)

© Sima Dezső, ÓE NIK

482

www.tankonyvtar.hu

2.1.1.4 The Nehalem-EX based Boxboro-EX MP server platform (8) Wide range of scalability of the 7500/6500 IOH based Boxboro-EX platform [12]

© Sima Dezső, ÓE NIK

483

www.tankonyvtar.hu

2.1.1.4 The Nehalem-EX based Boxboro-EX MP server platform (9) Example: Block diagram of a 7500 chipset based Boxboro-EX MP serverboard [13]

ESI

© Sima Dezső, ÓE NIK

484

www.tankonyvtar.hu

2.1.1.5 Evolution of MP server platforms (1) 2.1.1.5 Evolution of MP server platforms

© Sima Dezső, ÓE NIK

485

www.tankonyvtar.hu

2.1.1.5 Evolution of MP server platforms (2) Evolution from the first generation MP servers supporting SC processors to the 90 nm Pentium 4 Prescott MP based Truland MP server platform (supporting up to 2 cores) Xeon MP Xeon 7000 Xeon 7100 / / (Potomac) 1C (Paxville MP) 2x1C (Tulsa) 2C

Xeon MP1 SC

Xeon MP1 SC

Xeon MP1 SC

Pentium 4 Xeon MP 1C/2x1C

Xeon MP1 SC

Pentium 4 Xeon MP 1C/2x1C

Pentium 4 Xeon MP 1C/2x1C FSB

FSB

XMB Preceding NBs

85001/8501 XMB

E.g. HI 1.5

E.g. DDR-200/266

Pentium 4 Xeon MP 1C/2x1C

E.g. DDR-200/266

XMB XMB

HI 1.5 DDR-266/333 DDR2-400

Preceding ICH

ICH5

DDR-266/333 DDR2-400

HI 1.5 266 MB/s

90 nm Pentium 4 Prescott MP based Truland MP server platform (for up to 2 C)

Previous Pentium 4 MP based MP server platform (for single core processors)

© Sima Dezső, ÓE NIK

486

www.tankonyvtar.hu

2.1.1.5 Evolution of MP server platforms (3) Evolution from the 90 nm Pentium 4 Prescott MP based Truland MP platform (up to 2 cores) to the Core 2 based Caneland MP platform (up to 6 cores)

Xeon MP Xeon 7000 Xeon 7100 / / (Potomac) 1C (Paxville MP) 2x1C (Tulsa) 2C

Pentium 4 Xeon MP 1C/2x1C

Pentium 4 Xeon MP 1C/2x1C

Pentium 4 Xeon MP 1C/2x1C

Pentium 4 Xeon MP 1C/2x1C

Xeon 7200 Xeon 7300 Xeon 7400 / / (Tigerton DC) 1x2C (Tigerton QC) 2x2C (Dunnington 6C)

Core2 (2C/4C) Penryn (6C)

FSB

XMB 85001/8501 XMB

Core2 (2C/4C) Penryn (6C)

Core2 (2C/4C) Penryn (6C)

Core2 (2C/4C) Penryn (6C)

FSB

XMB

up to 8 DIMMs

7300

XMB ESI

HI 1.5

DDR-266/333 DDR2-400

ICH5

DDR-266/333 DDR2-400

631xESB/ 632xESB

90 nm Pentium 4 Prescott MP based Truland MP server platform (for up to 2 C)

Core 2 based Caneland MP server platform (for up to 6 C) ESI: Enterprise System Interface 4 PCIe lanes, 0.25 GB/s per lane (like the DMI interface, providing 1 GB/s transfer rate in each direction)

HI 1.5 (Hub Interface 1.5) 8 bit wide, 66 MHz clock, QDR, 266 MB/s peak transfer rate 1

© Sima Dezső, ÓE NIK

FBDIMM DDR2-533/667

The E8500 MCH supports an FSB of 667 MT/s and consequently only the SC Xeon MP (Potomac)

487

www.tankonyvtar.hu

2.1.1.5 Evolution of MP server platforms (4) Evolution to the Nehalem-EX based Boxboro-EX MP platform (that supports up to 10 cores) (In the basic system architecture we show the single IOH alternative)

Xeon 7500 (Nehalem-EX) (Becton) 8C

SMB SMB SMB

/

Xeon 7-4800 (Westmere-EX) 10C SMB

Nehalem-EX 8C Westmere-EX 10C

Nehalem-EX 8C Westmere-EX 10C

QPI

SMB SMB SMB

SMB

QPI

QPI

QPI

QPI

SMB SMB SMB

SMB Nehalem-EX 8C Westmere-EX 10C

SMB

Nehalem-EX 8C Westmere-EX 10C

QPI

QPI

DDR3-1067

SMB SMB SMB

QPI

2x4 SMI channels

2x4 SMI channels

7500 IOH ESI

ICH10

DDR3-1067

ME

SMI: Serial link between the processor and the SMBs SMB: Scalable Memory Buffer Parallel/serial converter ME: Management Engine

© Sima Dezső, ÓE NIK

Nehalem-EX based Boxboro-EX MP server platform (for up to 10 C)

488

www.tankonyvtar.hu

2.2 Many-core processors

•

2.2.1 Intel’s Larrabee

•

2.2.2 Intel’s Tile processor

•

2.2.3 Intel’s SCC

© Sima Dezső, ÓE NIK

489

www.tankonyvtar.hu

2.2 Manycore processors (1) Multicore processors

Heterogeneous multicores

Homogeneous multicores

Conventional multicores 2≤

Mobiles

n≤8

Manycore processors

cores

Desktops

Master/slave type multicores

Add-on type multicores

with >8 cores

Servers MPC CPU

General purpose computing © Sima Dezső, ÓE NIK

Prototypes/ experimental systems

MM/3D/HPC production stage

Figure 2.1: Major classes490 of multicore processors

GPU

HPC

www.tankonyvtar.hu

2.2.1 Intel’s Larrabee

© Sima Dezső, ÓE NIK

491

www.tankonyvtar.hu

2.2.1 Intel’s Larrabee (1) 2.2.1 Larrabee Part of Intel’s Tera-Scale Initiative. • Objectives: High end graphics processing, HPC Not a single product but a base architecture for a number of different products. • Brief history: Project started ~ 2005 First unofficial public presentation: 03/2006 (withdrawn) First official public presentation: 08/2008 (SIGGRAPH) Due in ~ 2009 • Performance (targeted): 2 TFlops

© Sima Dezső, ÓE NIK

492

www.tankonyvtar.hu

2.2.1 Intel’s Larrabee (2) Basic architecture

Figure 2.14: Block diagram of a GPU-oriented Larrabee (2006, outdated) [41] Update: SIMD processing width: SIMD-64 rather than SIMD-16

© Sima Dezső, ÓE NIK

493

www.tankonyvtar.hu

2.2.1 Intel’s Larrabee (3)

Figure 2.15: Board layout of a GPU-oriented Larrabee (2006, outdated) [42]

© Sima Dezső, ÓE NIK

494

www.tankonyvtar.hu

2.2.1 Intel’s Larrabee (4)

Figure 2.16: Four socket MP server design with 24-core Larrabees connected by the CSI bus [41] © Sima Dezső, ÓE NIK

495

www.tankonyvtar.hu

2.2.2 Intel’s Tile processor

© Sima Dezső, ÓE NIK

496

www.tankonyvtar.hu

2.2.2 Intel’s Tile processor (1) 2.2.2 Tile processor • First incarnation of Intel’s Tera-Scale Initiative (more than 100 projects underway) • Objective: Tera-Scale experimental chip • Brief history: Announced at Due in

© Sima Dezső, ÓE NIK

IDF 9/2006 2009/2010

497

www.tankonyvtar.hu

2.2.2 Intel’s Tile processor (2)

Figure 2.17: A forerunner: The Raw processor (MIT 2002) (16 tiles, each tile has a compute element, router, instruction and data memory) [43]

© Sima Dezső, ÓE NIK

498

www.tankonyvtar.hu

2.2.2 Intel’s Tile processor (3)

Bisection bandwidth: If the network is segmented into two equal parts, this is the bandwidth between the two parts

Figure 2.18: Die photo and chip details of the Tile processor [14]

© Sima Dezső, ÓE NIK

499

www.tankonyvtar.hu

2.2.2 Intel’s Tile processor (4)

Figure 2.19: Main blocks of a tile [14]

© Sima Dezső, ÓE NIK

500

www.tankonyvtar.hu

2.2.2 Intel’s Tile processor (5)

(Clocks run with the same frequency but unknown phases

FP Multiply-Accumulate (AxB+C)

Figure 2.20: Block diagram of a tile [14] © Sima Dezső, ÓE NIK

501

www.tankonyvtar.hu

2.2.2 Intel’s Tile processor (6)

Figure 2.21: On board implementation of the 80-core Tile Processor [15] © Sima Dezső, ÓE NIK

502

www.tankonyvtar.hu

2.2.2 Intel’s Tile processor (7)

Figure 2.22: Performance and dissipation figures of the Tile-processor [15] © Sima Dezső, ÓE NIK

503

www.tankonyvtar.hu

2.2.2 Intel’s Tile processor (8) Performance at 4 GHz: Peak SP FP: up to 1.28 TFlops (2 FPMA x 2 instr./cyclex80x4 GHz = 1.28 TFlops)

© Sima Dezső, ÓE NIK

504

www.tankonyvtar.hu

2.2.2 Intel’s Tile processor (9)

Figure 2.23: Programmer’s perspective of the Tile processor [14]

© Sima Dezső, ÓE NIK

505

www.tankonyvtar.hu

2.2.2 Intel’s Tile processor (10)

Figure 2.24: The full instruction set of the Tile processor [14] © Sima Dezső, ÓE NIK

506

www.tankonyvtar.hu

2.2.2 Intel’s Tile processor (11)

VLIW

Figure 2.25: Instruction word and latencies of the Tile processor [14]

© Sima Dezső, ÓE NIK

507

www.tankonyvtar.hu

2.2.2 Intel’s Tile processor (12)

Figure 2.26: Performance of the Tile processor – the workloads [14] © Sima Dezső, ÓE NIK

508

www.tankonyvtar.hu

2.2.2 Intel’s Tile processor (13)

Figure 2.27: Instruction word and latencies of the Tile processor [14] © Sima Dezső, ÓE NIK

509

www.tankonyvtar.hu

2.2.2 Intel’s Tile processor (14)

Figure 2.28: The significance of the Tile processor [14] © Sima Dezső, ÓE NIK

510

www.tankonyvtar.hu

2.2.2 Intel’s Tile processor (15)

Figure 2.29: Lessons learned from the Tile processor (1) [14]

© Sima Dezső, ÓE NIK

511

www.tankonyvtar.hu

2.2.2 Intel’s Tile processor (16)

Figure 2.30: Lessons learned from the Tile processor (2) [14]

© Sima Dezső, ÓE NIK

512

www.tankonyvtar.hu

2.2.3 Intel’s SCC

© Sima Dezső, ÓE NIK

513

www.tankonyvtar.hu

2.2.3 Intel’s SCC (1) 2.2.3 Intel’s SCC (Single-chip Cloud Computer) • 12/2009: Announced • 9/2010: Many-core Application Research Project (MARC) initiative started on the SCC platform • Designed in Braunschweig and Bangalore • 48 core, 2D-mesh system topology, message passing

© Sima Dezső, ÓE NIK

514

www.tankonyvtar.hu

2.2.3 Intel’s SCC (2)

Figure 2.31: The SCC chip [14]

© Sima Dezső, ÓE NIK

515

www.tankonyvtar.hu

2.2.3 Intel’s SCC (3)

Figure 2.32: Hardware view of SCC [14]

© Sima Dezső, ÓE NIK

516

www.tankonyvtar.hu

2.2.3 Intel’s SCC (4)

Figure 2.33: Dual core tile of SCC [14]

© Sima Dezső, ÓE NIK

517

www.tankonyvtar.hu

2.2.3 Intel’s SCC (5)

(Joint Test Action Group) Standard Test Access Port

Figure 2.34: SCC system overview [14]

© Sima Dezső, ÓE NIK

518

www.tankonyvtar.hu

2.2.3 Intel’s SCC (6)

Figure 2.35: Removing hardware cache coherency [16] © Sima Dezső, ÓE NIK

519

www.tankonyvtar.hu

2.2.3 Intel’s SCC (7)

Figure 2.36: Improving energy efficiency [16] © Sima Dezső, ÓE NIK

520

www.tankonyvtar.hu

2.2.3 Intel’s SCC (8)

Figure 2.37: A programmer’s view of SCC [14]

© Sima Dezső, ÓE NIK

521

www.tankonyvtar.hu

2.2.3 Intel’s SCC (9)

(Message Passing Buffer)

Figure 2.38: Operation of SCC [14] © Sima Dezső, ÓE NIK

522

www.tankonyvtar.hu

3. Heterogeneous multicores

•

3.1 Master-slave type multicores

•

3.2 Add-on type multicores

© Sima Dezső, ÓE NIK

523

www.tankonyvtar.hu

3. Heterogeneous multicores (1) Multicore processors

Heterogeneous multicores

Homogeneous multicores

Conventional multicores 2≤

Mobiles

n≤8

Manycore processors

cores

Desktops

Master/slave type multicores

Add-on type multicores

with >8 cores

Servers MPC CPU

General purpose computing © Sima Dezső, ÓE NIK

Prototypes/ experimental systems

MM/3D/HPC production stage

Figure 3.1: Major classes524 of multicore processors

GPU

HPC

www.tankonyvtar.hu

3.1 Master-slave type multicores

•

3.1.1 The Cell processor

© Sima Dezső, ÓE NIK

525

www.tankonyvtar.hu

3.1 Master-slave type multicores (1) Multicore processors

Heterogenous multicores

Homogenous multicores

Conventional MC processors 2≤

n≤8

Desktops

cores

Manycore processors

Master/slave architectures

Add-on architectures

with >8 cores

Servers MPC CPU

General purpose computing © Sima Dezső, ÓE NIK

Prototypes/ experimental systems

MM/3D/HPC production stage

Figure 3.1: Major classes 526 of multicore processors

GPU

HPC near future www.tankonyvtar.hu

3.1.1 The Cell Processor (1) 3.1.1 The Cell Processor • Designated also as the Cell BE (Broadband Engine) • Collaborative effort from Sony, IBM and Toshiba • Objective: Game/multimedia, HPC apps. Playstation 3 (PS3) • Brief history: Summer 2000: 02/2006: 08/ 2007 05/ 2008

© Sima Dezső, ÓE NIK

QS2x Blade Server family (2 Cell BE/blade)

High level Cell Blade Cell Blade Cell Blade

architectural discussions QS20 QS21 QS22

527

www.tankonyvtar.hu

3.1.1 The Cell Processor (2)

SPE: Synergistic Procesing Element SPU: Synergistic Processor Unit SXU: Synergistic Execution Unit LS: Local Store of 256 KB SMF: Synergistic Mem. Flow Unit

EIB: Element Interface Bus PPE: Power Processing Element PPU: Power Processing Unit PXU: POWER Execution Unit MIC: Memory Interface Contr. BIC: Bus Interface Contr.

XDR: Rambus DRAM

Figure 3.2: Block diagram of the Cell BE [44] © Sima Dezső, ÓE NIK

528

www.tankonyvtar.hu

3.1.1 The Cell Processor (3)

Figure 3.3: Die shot of the Cell BE (221mm2, 234 mtrs) [44] © Sima Dezső, ÓE NIK

529

www.tankonyvtar.hu

3.1.1 The Cell Processor (4)

Figure 3.4: Die shot of the Cell BE – PPE [44] © Sima Dezső, ÓE NIK

530

www.tankonyvtar.hu

3.1.1 The Cell Processor (5)

Figure 3.5: Block diagram of the PPE [44] © Sima Dezső, ÓE NIK

531

www.tankonyvtar.hu

3.1.1 The Cell Processor (6)

© Sima Dezső, ÓE NIK

Figure 3.6: Die shot of532 the Cell BE – SPEs [44]

www.tankonyvtar.hu

3.1.1 The Cell Processor (7)

Figure 3.7: Block diagram of the SPE [44]

© Sima Dezső, ÓE NIK

533

www.tankonyvtar.hu

3.1.1 The Cell Processor (8)

Figure 3.8: Die shot of the Cell BE – Memory interface [44] © Sima Dezső, ÓE NIK

534

www.tankonyvtar.hu

3.1.1 The Cell Processor (9)

Figure 3.9: Die shot of the Cell BE – I/O interface [44] © Sima Dezső, ÓE NIK

535

www.tankonyvtar.hu

3.1.1 The Cell Processor (10)

Figure 3.10: Die shot of the Cell BE – EIB [44] © Sima Dezső, ÓE NIK

536

www.tankonyvtar.hu

3.1.1 The Cell Processor (11)

Figure 3.11: Principle of the operation of the EIB [44] © Sima Dezső, ÓE NIK

537

www.tankonyvtar.hu

3.1.1 The Cell Processor (12)

Figure 3.12: Concurrent transactions of the EIB [44] © Sima Dezső, ÓE NIK

538

www.tankonyvtar.hu

3.1.1 The Cell Processor (13)

• Performance @ 3.2 GHz: QS21 Peak SP FP: 409,6 GFlops (3.2 GHz x 2x8 SPE x 2x4 SP FP/cycle) • Cell BE - NIK 2007: Faculty Award (Cell 3Đ app./Teaching) 2008: IBM – NIK Reserch Agreement and Cooperation: Performance investigations • IBM Böblingen Lab • IBM Austin Lab

© Sima Dezső, ÓE NIK

539

www.tankonyvtar.hu

3.1.1 The Cell Processor (14)

© Sima Dezső, ÓE NIK

Picture 3.1: IBM’s Roadrunner (Los Alamos 2008) [45] www.tankonyvtar.hu 540

3.1.1 The Cell Processor (15) The Roadrunner 6/2008 : International Supercomputing Conference, Dresden Top 500 supercomputers 1. Roadrunner

© Sima Dezső, ÓE NIK

1 Petaflops (1015) sustained Linpack

541

www.tankonyvtar.hu

3.1.1 The Cell Processor (16)

Figure 3.13: Key features of Roadrunner [44] © Sima Dezső, ÓE NIK

542

www.tankonyvtar.hu

3.2 Add-on type multicores

•

3.2.1 GPGPUs

© Sima Dezső, ÓE NIK

543

www.tankonyvtar.hu

3.2 Add-on type multicores (1) Multicore processors

Heterogeneous multicores

Homogeneous multicores

Conventional multicores 2≤

Mobiles

n≤8

Manycore processors

cores

Desktops

Master/slave type multicores

Add-on type multicores

with >8 cores

Servers MPC CPU

General purpose computing © Sima Dezső, ÓE NIK

Prototypes/ experimental systems

MM/3D/HPC production stage

Figure 3.1: Major classes544 of multicore processors

GPU

HPC

www.tankonyvtar.hu

3.2.1 GPGPUs

•

3.2.1.1 Introduction to GPGPUs

•

3.2.1.2 Overview of GPGPUs

•

3.2.1.3 Example 1: Nvidia’s Fermi GF100

•

3.2.1.4 Example 2: Intel’s on-die integrated CPU/GPU lines – Sandy Bridge

© Sima Dezső, ÓE NIK

545

www.tankonyvtar.hu

3.2.1.1 Introduction to GPGPUs (1) 3.2.1.1 Introduction to GPGPUs

Unified shader model of GPUs (introduced in the SM 4.0 of DirectX 10.0)

Unified, programable shader architecture

The same (programmable) processor can be used to implement all shaders; • the vertex shader • the pixel shader and • the geometry shader (new feature of the SMl 4)

© Sima Dezső, ÓE NIK

546

www.tankonyvtar.hu

3.2.1.1 Introduction to GPGPUs (2)

Based on its FP32 computing capability and the large number of FP-units available

the unified shader is a prospective candidate for speeding up HPC!

GPUs with unified shader architectures also termed as GPGPUs (General Purpose GPUs) or cGPUs (computational GPUs)

© Sima Dezső, ÓE NIK

547

www.tankonyvtar.hu

3.2.1.1 Introduction to GPGPUs (3) Peak FP32/FP64 performance of Nvidia’s GPUs vs Intel’ P4 and Core2 processors [17]

© Sima Dezső, ÓE NIK

548

www.tankonyvtar.hu

3.2.1.1 Introduction to GPGPUs (4) Peak FP32 performance of AMD’s GPGPUs [18]

© Sima Dezső, ÓE NIK

549

www.tankonyvtar.hu

3.2.1.1 Introduction to GPGPUs (5) Evolution of the FP-32 performance of GPGPUs [19]

© Sima Dezső, ÓE NIK

550

www.tankonyvtar.hu

3.2.1.1 Introduction to GPGPUs (6) Evolution of the bandwidth of Nvidia’s GPU’s vs Intel’s P4 and Core2 processors [20]

© Sima Dezső, ÓE NIK

551

www.tankonyvtar.hu

3.2.1.1 Introduction to GPGPUs (7)

Figure 3.14: Contrasting the utilization of the silicon area in CPUs and GPUs [21]

• Less area for control since GPGPUs have simplified control (same instruction for all ALUs) • Less area for caches since GPGPUs support massive multithereading to hide latency of long operations, such as memory accesses in case of cache misses.

© Sima Dezső, ÓE NIK

552

www.tankonyvtar.hu

3.2.1.2 Overview of GPGPUs (1) 3.2.1.2 Overview of GPGPUs

Basic implementation alternatives of the SIMT execution

Data parallel accelerators

GPGPUs

Dedicated units Programmable GPUs supporting data parallel execution with appropriate with appropriate programming environments programming environment Have display outputs

E.g.

No display outputs Have larger memories than GPGPUs

Nvidia’s Tesla lines AMD’s FireStream lines

Nvidia’s 8800 and GTX lines AMD’s HD 38xx, HD48xx lines

Figure 3.15: Basic implementation alternatives of the SIMT execution © Sima Dezső, ÓE NIK

553

www.tankonyvtar.hu

3.2.1.2 Overview of GPGPUs (2)

GPGPUs

AMD/ATI’s line

Nvidia’s line

90 nm

G80 80 nm Shrink

65 nm

G92

Enhanced arch. G200 Shrink

40 nm

R600 Shrink

Enhanced arch.

55 nm

RV670

Enhanced arch.

RV770

Shrink

Enhanced Enhanced arch. arch.

RV870

GF100 (Fermi)

Cayman

Figure 3.16: Overview of Nvidia’s and AMD/ATI’s GPGPU lines

© Sima Dezső, ÓE NIK

554

www.tankonyvtar.hu

3.2.1.2 Overview of GPGPUs (3) NVidia 10/07

11/06 G80

G92

GT200

90 nm/681 mtrs

65 nm/754 mtrs

65 nm/1400 mtrs

Cores

Cards

6/08

8800 GTS 96 ALUs 320-bit

8800 GTX

8800 GT

GTX260

GTX280

128 ALUs 384-bit

112 ALUs 256-bit

192 ALUs 448-bit

240 ALUs 512-bit

OpenCL

OpenCL Standard 11/07

6/07

CUDA

Version 1.0

Version 1.1

6/08

11/08

Version 2.0

Version 2.1

AMD/ATI Cores Cards

11/05

5/07

11/07

5/08

R500

R600

R670

RV770

80 nm/681 mtrs

55 nm/666 mtrs

55 nm/956 mtrs

(Xbox)

HD 2900XT

HD 3850

HD 3870

HD 4850

HD 4870

48 ALUs

320 ALUs 512-bit

320 ALUs 256-bit

320 ALUs 256-bit

800 ALUs 256-bit

800 ALUs 256-bit

OpenCL

12/08

OpenCL 11/07

Brooks+

Standard 9/08 12/08

Brook+

Brook+ 1.2

Brook+ 1.3

(SDK v.1.0)

(SDK v.1.2)

(SDK v.1.3)

6/08

RapidMind

3870 support

2005

© Sima Dezső, ÓE NIK

2006

2007

2008

Figure 3.17: Overview of GPGPUs and their basic software support (1) 555

www.tankonyvtar.hu

3.2.1.2 Overview of GPGPUs (4) NVidia Cores

Cards

3/10

07/10

11/10

GF100 (Fermi)

GF104 (Fermi)

GF110 (Fermi)

40 nm/3000 mtrs

40 nm/1950 mtrs

40 nm/3000 mtrs

GTX 470 448 ALUs 320-bit

OpenCL

GTX 460

10/09

6/10

OpenCL 1.0

OpenCL 1.0

OpenCL 1.1

SDK 1.0 Early release

SDK 1.0

SDK 1.1

Version 22

3/10 Version 3.0

Version 2.3

GTX 580

336 ALUs 192/256-bit

6/09

5/09 6/09

CUDA

GTX 480 480 ALUs 384-bit

GTX 560 Ti

512 ALUs 384-bit

6/10

480 ALUs 384-bit

1/11

Version 3.1

Version 3.2

1/11

3/11 Version 4.0 Beta

AMD/ATI

9/09

Cores

10/10 Barts Pro/XT

Cayman Pro/XT

40 nm/2100 mtrs

40 nm/1700 mtrs

40 nm/2640 mtrs

Cards

HD 5850/70

HD 6850/70

1440/1600 ALUs 256-bit

OpenCL

03/10

OpenCL 1.0

OpenCL 1.0

08/10 OpenCL 1.1 (SDK V.2.2)

(SDK V.2.01)

8/09 Intel bought RapidMind 2009

© Sima Dezső, ÓE NIK

HD 6950/70 1408/1536 ALUs 256-bit

Brook+ 1.4 (SDK V.1.4 Beta)

RapidMind

960/1120 ALUs 256-bit

11/09 (SDK V.2.0)

3/09

Brooks+

12/10

RV870 (Cypress)

2010

2011

Figure 3.18: Overview of GPGPUs and their basic software support (2) 556

www.tankonyvtar.hu

3.2.1.3 Example 1: Nvidia’s Fermi GF 100 (1) 3.2.1.3 Example 1: Nvidia’s Fermi GF 100 Announced: 30. Sept. 2009 at NVidia’s GPU Technology Conference, available: 1Q 2010 [22]

© Sima Dezső, ÓE NIK

557

www.tankonyvtar.hu

3.2.1.3 Example 1: Nvidia’s Fermi GF 100 (2) Sub-families of Fermi Fermi includes three sub-families with the following representative cores and features:

GPGPU

Available since

Max. no. of cores

Max. no. of ALUs

No of transistors

Compute capability

Aimed at

GF100

3/2010

161

5121

3200 mtrs

2.0

Gen. purpose

GF104

7/2010

8

384

1950 mtrs

2.1

Graphics

GF110

11/2010

16

512

3000 mtrs

2.0

Gen. purpose

1

In the associated flagship card (GTX 480) however, one of the SMs has been disabled, due to overheating problems, so it has actually only 15 SIMD cores, called Streaming Multiprocessors (SMs) by Nvidia and 480 FP32 EUs [69]

© Sima Dezső, ÓE NIK

558

www.tankonyvtar.hu

3.2.1.3 Example 1: Nvidia’s Fermi GF 100 (3) Overall structure of Fermi GF100 [22], [23]

NVidia: 16 cores (Streaming Multiprocessors) (SMs) Each core: 32 ALUs 512 ALUs

Remark In the associated flagship card (GTX 480) however, one SM has been disabled, due to overheating problems, so it has actually 15 SMs and 480 ALUs [a]

6x Dual Channel GDDR5 (6x 64 = 384 bit) © Sima Dezső, ÓE NIK

559

www.tankonyvtar.hu

3.2.1.3 Example 1: Nvidia’s Fermi GF 100 (4) High level microarchitecture of Fermi GT100

© Sima Dezső, ÓE NIK

Figure 3.19: Fermi’s system architecture [24] 560

www.tankonyvtar.hu

3.2.1.3 Example 1: Nvidia’s Fermi GF 100 (5) Evolution of the high level microachitecture of Nvidia’s GPGPUs [24]

Fermi GF100

Note The high level microarchitecture of Fermi evolved from a graphics oriented structure to a computation oriented one complemented with a units needed for graphics processing.

© Sima Dezső, ÓE NIK

561

www.tankonyvtar.hu

3.2.1.3 Example 1: Nvidia’s Fermi GF 100 (6) Layout of a Cuda GF100 core (SM) [25] (SM: Streaming Multiprocessor)

SFU: Special Function Unit

1 SM includes 32 ALUs called “Cuda cores” by NVidia)

© Sima Dezső, ÓE NIK

562

www.tankonyvtar.hu

3.2.1.3 Example 1: Nvidia’s Fermi GF 100 (7) Layout of a Cuda GF100 core (SM) [25]

Special Function Units calculate FP32 transcendental functions (such as trigonometric functions etc.)

1 SM includes 32 ALUs called “Cuda cores” by NVidia)

© Sima Dezső, ÓE NIK

563

www.tankonyvtar.hu

3.2.1.3 Example 1: Nvidia’s Fermi GF 100 (8) A single ALU (“CUDA core”)

SP FP:32-bit

FP64 • First implementation of the IEEE 754-2008 standard • Needs 2 clock cycles to issue the entire warp for execution. FP64 performance: ½ of FP32 performance!! (Enabled only on Tesla devices!

Fermi’s integer units (INT Units) • are 32-bit wide. • became stand alone units, i.e. they are no longer merged with the MAD units as in prior designs. • In addition, each floating-point unit (FP Unit) is now capable of producing IEEE 754-2008compliant double-precision (DP) FP results in every 2. clock cycles, at ½ of the performance of single-precision FP calculations.

Figure 3.20: A single ALU [26] © Sima Dezső, ÓE NIK

564

www.tankonyvtar.hu

3.2.1.3 Example 1: Nvidia’s Fermi GF 100 (9) Remark The Fermi line supports the Fused Multiply-Add (FMA) operation, rather than the Multiply-Add operation performed in previous generations.

Previous lines

Fermi

Figure 3.21: Contrasting the Multiply-Add (MAD) and the Fused-Multiply-Add (FMA) operations [27] © Sima Dezső, ÓE NIK

565

www.tankonyvtar.hu

3.2.1.3 Example 1: Nvidia’s Fermi GF 100 (10) Principle of the SIMT execution in case of serial kernel execution Host

Device

Each kernel invocation lets execute all thread blocks (Block(i,j))

kernel0()

Thread blocks may be executed independently from each other kernel1()

Figure 3.22: Hierarchy of threads [28] © Sima Dezső, ÓE NIK

566

www.tankonyvtar.hu

3.2.1.3 Example 1: Nvidia’s Fermi GF 100 (11) Nvidia GeForce GTX 480 and 580 cards [29]

GTX 480 (GF 100 based)

© Sima Dezső, ÓE NIK

GTX 580 (GF 110 based)

567

www.tankonyvtar.hu

3.2.1.3 Example 1: Nvidia’s Fermi GF 100 (12) A pair of GeForce GTX 480 cards [30] (GF100 based)

© Sima Dezső, ÓE NIK

568

www.tankonyvtar.hu

3.2.1.3 Example 1: Nvidia’s Fermi GF 100 (13) FP64 performance increase in Nvidia’s Tesla and GPGPU lines Performance is bound by the number of available DP FP execution units.

Avail. FP64 units operations

G80/G92

GT200

GF100

GF110

(11/06, 10/07)

(06/08)

(03/10)

(11/10)

No FP64 support

1

16 FP64 units (Add, Mul, FMA )

16 FP64 units (Add, Mul, FMA)

FP64 unit (Add, Mul, MAD) 1 FP64 MAD

Peak FP64 load/SM Peak FP64 perf./cycle/SM

16 FP64 FMA

1x2 operations/SM

16x2 operations/SM

16 FP64 MAD 16x2 operations/SM

Tesla cards Flagship Tesla card

C1060

Peak FP64 perf./card

C2070

30x1x2x1296

14x16x2x1150

77.76 GFLOPS

515.2 GFLOPS

GPGPU cards Flagship GPGPU úcard

GT280

Peak FP64 perf./card

1

© Sima Dezső, ÓE NIK

GTX 4801

30x1x2x1296

15x4x2x1401

77.76 GFLOPS

168.12 GFLOPS

GTX 5801 16x4x2x1544 197.632 GFLOPS

In their GPGPU Fermi cards Nvidia activates only 4 FP64 units from the available 16 569

www.tankonyvtar.hu

3.2.1.4 Example 2: Intel’s on-die integrated CPU/GPUs (1) 3.2.1.4 Example 2: Intel’s on-die integrated CPU/GPUs – Sandy Bridge

Integration to the chip

Figure 3.23: Evolution of add-on MC architectures © Sima Dezső, ÓE NIK

570

www.tankonyvtar.hu

3.2.1.4 Example 2: Intel’s on-die integrated CPU/GPUs (2) The Sandy Bridge processor [31] • Shipped in Jan. 2011 • Provides on-die integrated CPU and GPU

© Sima Dezső, ÓE NIK

571

www.tankonyvtar.hu

3.2.1.4 Example 2: Intel’s on-die integrated CPU/GPUs (3) Main features of Sandy Bridge [32]

© Sima Dezső, ÓE NIK

572

www.tankonyvtar.hu

3.2.1.4 Example 2: Intel’s on-die integrated CPU/GPUs (4) Key specification data of Sandy Bridge [33]

Branding

Core i5

Core i5

Core i5

Core i7

Core i7

Processor

2400

2500

2500K

2600

2600K

Price

$184

$205

$216

$294

$317

TDP

95W

95W

95W

95W

95W

Cores / Threads

4/4

4/4

4/4

4/8

4/8

Frequency GHz

3.1

3.3

3.3

3.4

3.4

Max Turbo GHz

3.4

3.7

3.7

3.8

3.8

DDR3 MHz

1333 MHz

1333 MHz

1333 MHz

1333 MHz

1333 MHz

L3 Cache

6MB

6MB

6MB

8MB

8MB

Intel HD Graphics

2000

2000

3000

2000

3000

GPU Max freq

1100 MHz

1100 MHz

1100 MHz

1350 MHz

1350 MHz

HyperThreading

No

No

No

Yes

Yes

AVX Extensions

Yes

Yes

Yes

Yes

Yes

Socket

LGA 1155

LGA 1155

LGA 1155

LGA 1155

LGA 1155

© Sima Dezső, ÓE NIK

573

www.tankonyvtar.hu

3.2.1.4 Example 2: Intel’s on-die integrated CPU/GPUs (5) Die photo of Sandy Bridge [34]

256 KB L2 (9 clk)

256 KB L2 (9 clk)

256 KB L2 (9 clk)

256 KB L2 (9 clk)

Hyperthreading 32K L1D (3 clk) AES Instr. AVX 256 bit VMX Unrestrict. 4 Operands 20 nm2 / Core

@ 1.0 1.4 GHz (to L3 connected)

(25 clk) 256 b/cycle Ring Architecture DDR3-1600

PCIe 2.0

25.6 GB/s

32 nm process / ~225 nm2 die size / 85W TDP Figure 3.24: Die photo of Sandy Bridge [34] © Sima Dezső, ÓE NIK

574

www.tankonyvtar.hu

3.2.1.4 Example 2: Intel’s on-die integrated CPU/GPUs (6) Sandy Bridge’s integrated graphics unit [31]

© Sima Dezső, ÓE NIK

575

www.tankonyvtar.hu

3.2.1.4 Example 2: Intel’s on-die integrated CPU/GPUs (7) Specification data of the HD 2000 and HD 3000 graphics [35]

-

© Sima Dezső, ÓE NIK

576

www.tankonyvtar.hu

3.2.1.4 Example 2: Intel’s on-die integrated CPU/GPUs (8) Performance comparison: gaming [36]

HD5570 400 ALUs i5/i7 2xxx: Sandy Bridge

i56xx Arrandale frames per sec © Sima Dezső, ÓE NIK

577

www.tankonyvtar.hu

4. Outlook

© Sima Dezső, ÓE NIK

578

www.tankonyvtar.hu

4. Outlook (1) 4. Outlook

Heterogenous multicores

Master/slave type multicores

1(Ma):M(S)

2(Ma):M(S)

Add-on type multicores

M(Ma):M(S)

1(CPU):1(D)

M(CPU):1(D)

M(CPU):M(D)

M(Ma) = M(CPU) M(S)

Ma: Master S: Slave M: Many

© Sima Dezső, ÓE NIK

=

M(D)

D: Dedicated (like GPU) H: Homogenous M: Many

Figure 4.1: Expected evolution 579 of heterogeneous multicores

www.tankonyvtar.hu

4. Outlook (2) Master-slave type multicores require much more intricate workflow control and synchronization than add-on type multicores It can expected that add-on type multicores will dominate the future of heterogeneous multicores.

© Sima Dezső, ÓE NIK

580

www.tankonyvtar.hu

5. References

© Sima Dezső, ÓE NIK

581

www.tankonyvtar.hu

References (1) [1]: Gilbert J. D., Hunt S. H., Gunadi D., Srinivas G., The Tulsa Processor: A Dual Core Large Shared-Cache Intel Xeon Processor 7000 Sequence for the MP Server Market Segment, Aug 21 2006, http://www.hotchips.org/archives/hc18/3_Tues/HC18.S9/HC18.S9T1.pdf [2]: Intel Server Board Set SE8500HW4, Technical Product Specification, Revision 1.0, May 2005, ftp://download.intel.com/support/motherboards/server/sb/se8500hw4_board_ set_tpsr10.pdf [3]: Intel® E8501 Chipset North Bridge (NB) Datasheet, Mai 2006, http://www.intel.com/design/chipsets/e8501/datashts/309620.htm [4]: Supermicro Motherboards, http://www.supermicro.com/products/motherboard/ [5]: Next-Generation AMD Opteron Processor with Direct Connect Architecture – 4P Server Comparison, http://www.amd.com/us-en/assets/content_type/DownloadableAssets/4P_ Server_Comparison_PID_41461.pdf [6]: Supermicro P4QH6 / P4QH8 User’s Manual, 2002, http://www.supermicro.com/manuals/motherboard/GC-HE/MNL-0665.pdf [7]: Intel® 7300 Chipset Memory Controller Hub (MCH) – Datasheet, Sept. 2007, http://www.intel.com/design/chipsets/datashts/313082.htm [8]: Quad-Core Intel® Xeon® Processor 7300 Series Product Brief, Intel, Nov. 2007 http://download.intel.com/products/processor/xeon/7300_prodbrief.pdf [9]: Mitchell D., Intel Nehalem-EX review, PCPro, http://www.pcpro.co.uk/reviews/processors/357709/intel-nehalem-ex [10]: Nagaraj D., Kottapalli S.: Westmere-EX: A 20 thread server CPU, Hot Chips 2010 http://www.hotchips.org/uploads/archive22/HC22.24.610-Nagara-Intel-6-Westmere-EX.pdf

© Sima Dezső, ÓE NIK

582

www.tankonyvtar.hu

References (2) [11]: Intel Xeon Processor E7-8800/4800/2800 Product Families, Datasheet Vol. 1 of 2, April 2011, http://www.intel.com/Assets/PDF/datasheet/325119.pdf [12]: Intel Xeon Processor 7500/6500 Series, Public Gold Presentation, March 30 2010, http://cache-www.intel.com/cd/00/00/44/64/446456_446456.pdf [13]: Supermicro X8QB6-F / X8QBE-F User’s Manual, 2010, http://files.siliconmechanics.com/Documentation/Rackform/iServ/R413/Mainboard/MNL -X8QB-E-6-F.pdf [14]: Mattson T., The Future of Many Core Computing: A tale of two processors, March 4 2010, http://og-hpc.com/Rice2010/Slides/Mattson-OG-HPC-2010-Intel.pdf [15]: Kirsch N., An Overview of Intel's Teraflops Research Chip, Febr. 13 2007, Legit Reviews, http://www.legitreviews.com/article/460/1/ [16]: Rattner J., „Single-chip Cloud Computer”, Dec. 2 2009 http://www.pcper.com/reviews/Processors/Intel-Shows-48-core-x86-Processor-Singlechip-Cloud-Computer [17]: Nvidia CUDA C Programming Guide, Version 3.2, October 22 2010 http://developer.download.nvidia.com/compute/cuda/3_2/toolkit/docs/CUDA_C_ Programming_Guide.pdf [18]: Chu M. M., GPU Computing: Past, Present and Future with ATI Stream Technology, AMD, March 9 2010, http://developer.amd.com/gpu_assets/GPU%20Computing%20-%20Past%20 Present%20and%20Future%20with%20ATI%20Stream%20Technology.pdf © Sima Dezső, ÓE NIK

583

www.tankonyvtar.hu

References (3) [19]: Hwu W., Kirk D., Nvidia, Advanced Algorithmic Techniques for GPUs, Berkeley, January 24-25 2011 http://iccs.lbl.gov/assets/docs/20110124/lecture1_computational_thinking_Berkeley_2011.pdf [20]: Shrout R., Nvidia GT200 Revealed – GeForce GTX 280 and GTX 260 Review, PC Perspective, June 16 2008, http://www.pcper.com/article.php?aid=577&type=expert&pid=3 [21]: Nvidia CUDA Compute Unified Device Architecture Programming Guide, Version 2.0, June 2008, Nvidia, http://developer.download.nvidia.com/compute/cuda/2_0/docs/NVIDIA_CUDA_Programming Guide_2.0.pdf [22]: Next Gen CUDA GPU Architecture, Code-Named “Fermi”, Press Presentation at Nvidia’s 2009 GPU Technology Conference, (GTC), Sept. 30 2009, http://www.nvidia.com/object/gpu_tech_conf_press_room.html [23]: Nvidia’s Next Generation CUDATM Compute Architecture: FermiTM, Version 1.1, 2009 http://www.nvidia.com/content/PDF/fermi_white_papers/NVIDIA_Fermi_Compute_ Architecture_Whitepaper.pdf [24]: Kanter D., Inside Fermi: Nvidia's HPC Push, Real World Technologies Sept 30 2009, http://www.realworldtech.com/includes/templates/articles.cfm?ArticleID=RWT093009110932& mode=print [25]: Kirsch N., NVIDIA GF100 Fermi Architecture and Performance Preview, Legit Reviews, Jan 20 2010, http://www.legitreviews.com/article/1193/2/ © Sima Dezső, ÓE NIK

584

www.tankonyvtar.hu

References (4) [26]: Wasson S., Inside Fermi: Nvidia's 'Fermi' GPU architecture revealed, Tech Report, Sept 30 2009, http://techreport.com/articles.x/17670/1 [27]: Glaskowsky P. N., Nvidia’s Fermi: The First Complete GPU Computing Architecture Sept 2009, http://www.nvidia.com/content/PDF/fermi_white_papers/ P.Glaskowsky_NVIDIA's_Fermi-The_First_Complete_GPU_Architecture.pdf [28]: Kanter D., “NVIDIA’s GT200: Inside a Parallel Processor,” Real World Technologies, Sept. 8 2008, http://www.realworldtech.com/page.cfm?ArticleID=RWT090808195242 [29]: Hoenig M., Nvidia GeForce 580 Review, HardwareCanucks, Nov. 8, 2010, http://www.hardwarecanucks.com/forum/hardware-canucks-reviews/37789-nvidiageforce-gtx-580-review-5.html [30]: Wasson S., Nvidia's GeForce GTX 480 and 470 graphics processors, Tech Report, March 31 2010, http://techreport.com/articles.x/18682 [31]: Piazza T., Dr. Jiang H., Microarchitecture Codename Sandy Bridge: Processor Graphics, Presentation ARCS002, IDF San Francisco, Sept. 2010 [32]: Kahn O., Valentine B., Microarchitecture Codename Sandy Bridge: New Processor Innovations, Presentation ARCS001, IDF San Francisco Sept. 2010 [33]: Hagedoorn H. Mohammad S., Barling I. R., Core i5 2500K and Core i7 2600K review, Jan. 3 2011, http://www.guru3d.com/article/core-i5-2500k-and-core-i7-2600k-review/2 [34]: Intel Sandy Bridge Review, Bit-tech, Jan. 3 2011, http://www.bit-tech.net/hardware/cpus/2011/01/03/intel-sandy-bridge-review/1 © Sima Dezső, ÓE NIK

585

www.tankonyvtar.hu

References (5) [35]: Wikipedia: Intel GMA, 2011, http://en.wikipedia.org/wiki/Intel_GMA [36]: Shimpi A. L., The Sandy Bridge Review: Intel Core i7-2600K, i5-2500K and Core i3-2100 Tested, AnandTech, Jan. 3 2011, http://www.anandtech.com/show/4083/the-sandy-bridge-review-intel-core-i7-600k-i5-2500kcore-i3-2100-tested/11 [37]: Wall D. W.: Limits of Instruction Level Parallelism, WRL TN-15, Dec. 1990 [38]: Bhandarkar D.: „The Dawn of a New Era”, Presentation EMEA, May 11 2006. [39]: Moore G. E., No Exponential is Forever… ISSCC 2003, http://download.intel.com/research/silicon/Gordon_Moore_ISSCC_021003.pdf [40]: Intel Roadmap 2006, Source Intel [41]: Davis E.: Tera Tera Tera Presentation, 2008 http://bt.pa.msu.edu/TM/BocaRaton2006/talks/davis.pdf [42]: Stokes J.: Clearing up the confusion over Intel’s Larrabee, Part II http://arstechnica.com/hardware/news/2007/06/clearing-up-the-confusion-over-intelslarrabee-part-ii.ars [43]: Taylor M. B. & all: Evaluation of the Raw Microprocessor, Proc. ISCA 2004 http://groups.csail.mit.edu/cag/raw/documents/raw_isca_2004.pdf [44]: Wright C., Henning P.: Roadrunner Tutorial, An Introduction to Roadrunner and the Cell Processor, Febr. 7 2008, http://ebookbrowse.com/roadrunner-tutorial-session-1-web1-pdf-d34334105 © Sima Dezső, ÓE NIK

586

www.tankonyvtar.hu

References (6) [45]: Seguin S.: IBM Roadrunner Beats Cray’s Jaguar, Tom’s Hardware, Nov. 18 2008 http://www.tomshardware.com/news/IBM-Roadrunner-Top500-Supercomputer,6610.html

© Sima Dezső, ÓE NIK

587

www.tankonyvtar.hu

Intel’s DP/MP Servers Dezső Sima

© Sima Dezső, ÓE NIK

588

www.tankonyvtar.hu

Contents • 1. The worldwide server market • 2. Intel’s DP servers • 3. Intel’s MP servers • 4. References

© Sima Dezső, ÓE NIK

589

www.tankonyvtar.hu

1. The worldwide server market

© Sima Dezső, ÓE NIK

590

www.tankonyvtar.hu

1. The worldwide server market 1. The worldwide server market 2010 [52]

According to IDC's Server Tracker (Q4 2010) • the RISC/mainframe market share has halved since 2002, while Intel’s x86 chips now command almost 60% of the market. • AMD grew from a negligible 0.7% in 2002 (no Opteron servers on the market yet) to a decent 5.5% in 2010. © Sima Dezső, ÓE NIK

591

www.tankonyvtar.hu

2. Intel’s DP platforms •

2.1 Introduction

•

2.2 The Pentium 4 Prescott DP based DP platform

•

2.3 Core 2 and Penryn based DP platforms

•

2.4 Nehalem based DP server platforms

•

2.5 Sandy Bridge based DP server platforms

•

2.6 Evolution of DP platforms

© Sima Dezső, ÓE NIK

592

www.tankonyvtar.hu

2.1 Introduction (1) 2.1 Introduction

© Sima Dezső, ÓE NIK

593

www.tankonyvtar.hu

2.1 Introduction (2) Basic Arch.

Pentium 4 (Prescott)

Core/technology

DP server processors

Pentium 4

90 nm

10/2005

Paxville DP 2.8

2x1 C, 2 MB L2/C

Pentium 4

65 nm

5/2006

5000 (Dempsy)

2x1 C, 2 MB L2/C

Core2

65 nm

6/2006 11/206

5100 (Woodchrest) 5300 (Clowertown)

1x2 C, 4 MB L2/C 2x2 C, 4 MB L2/C

Penryn

45 nm

11/2007

5400 (Harpertown)

2x2 C, 6 MB L2/2C

Nehalem-EP

45 nm

3/2009

5500 (Gainstown)

Westmere-EP

32 nm

3/2010

56xx (Gulftown)

1x6 C, ¼ MB L2/C 12 MB L3

Nehalem-EX

45 nm

3/2010

6500 (Beckton)

1x8C, ¼ MB L2/C, 24 MB L3

Westmere-EX

32 nm

4/2011

E7-28xx (Westmere-EX)

Sandy Bidge

32 nm

1/2011

Ivy Bridge

22 nm

11/2012?

Core 2

1x4 C, ¼ MB L2/C 8 MB L3

Nehalem

Sandy Bridge

© Sima Dezső, ÓE NIK

1X10 C, ¼ MB L2/C 30 MB L3

Table 2.1: Overview of Intel’s multicore DP server processors 594

www.tankonyvtar.hu

2.1 Introduction (3)

DP server platforms

Pentium 4 Prescott 90-nm based DP server platform

Core 2 and Penryn based DP server platforms

Nehalem based DP server platforms

Sandy Bridge based DP server platforms

Xeon DP 2.8 based (without a designation) (2005)

Bensley (2006) Cranberry Lake (2007)

Tylersburg-EP (2009) Boxboro-EP (2010)

Romley-EP (Socket R) Romley-EP (Socket B2) (2H 2011)

© Sima Dezső, ÓE NIK

595

www.tankonyvtar.hu

2.2 The 90 nm Pentium 4 Prescott DP based DP server platform (1) 2.2 The 90 nm Pentium 4 Prescott DP based DP server platform

© Sima Dezső, ÓE NIK

596

www.tankonyvtar.hu

2.2 The 90 nm Pentium 4 Prescott DP based DP server platform (2)

DP platform

10/2005 DP core

Xeon DP 2.8 DC /Paxville DP 2.8) 2x1C 90 nm/2*169 mtrs 2*2 MB L2 800 MT/s PGA604 6/2004

MCH

E7520 (Lindenhurst) 1xFSB HI 1.5 800 MT/s 2 DDR/DDR2 channels DDR-200/266, DDR2-400 4 DiMMs/channel max. 32 GB max. 16 GB DDR-266 DDR-333/DDR2-400 4/2003/2/2004

ICH

© Sima Dezső, ÓE NIK

ICH5R/ 6300ESB Pentium 4 Prescott DP-based (90597 nm)

Pentium 4 based Core 2 based Penryn based

www.tankonyvtar.hu

2.2 The 90 nm Pentium 4 Prescott DP based DP server platform (3) Geneaology of the Paxville DP 2.8 processor [68] Nocona (Intel’s first 64-bit Xeon DP) (DP enhanced Prescott)

Irwindale (L2 enlarged to 2MB)

Nocona

Paxville DP 2.8 (2 x Irwindale cores)

(DP enhanced Prescott 2M)

6/2004

2/2005

10/2005

90 nm 112 mm2 125 mtrs

90 nm 135 mm2 169 mtrs

90 nm 2 x 135 mm2 2 x 169 mtrs

mPGA 604

mPGA 604

In contrast: corresponding desktop processors have the LGA 775 socket.

Xeon DP 2.8 Xeon MP 7020-7041 mPGA 604

Figure 2.1: Genealogy of the Xeon Paxville processor © Sima Dezső, ÓE NIK

598

www.tankonyvtar.hu

2.2 The 90 nm Pentium 4 Prescott DP based DP server platform (4) 3/02

11/02

^

^

Foster-MP

Gallatin

0.18 µ /108 mtrs 1.4/1.5/1.6 GHz

0.13 µ /178 mtrs 1.5/1.9/2 GHz

On-die 256K L2 On-die 512K/1M L3 400 MHz FSB µ PGA 603

On-die 512K L2 On-die 1M/2M L3 400 MHz FSB µ PGA 603

Xeon - MP line

Xeon DP line

11/02

7/03

^

^

0.13 µ /55 mtrs 1.8/2/2.2 GHz

On-die 256 K L2 400 MHz FSB µPGA 603

On-die 512K L2 400 MHz FSB µ PGA 603

0.13 µ /55 mtrs 2/2.4/2.6/2.8 GHz On-die 512K L2 533 MHz FSB µ PGA 603

On-die 1M L2 On-die 8M L3 (?)

On-die 512K L2 On-die 2M/4M L3 400 MHz FSB µ PGA 603

^

0.18 µ /42 mtrs 1.4/1.5/1.7 GHz

0.09µ > 3.5 MHz

0.13 µ /286 mtrs 2.2/2.7/3.0 GHz

2/02

Prestonia-B

Potomac

Gallatin

^

Prestonia-A

^

^

5/01 Foster

2Q/05

3/04

6/04

2Q/05

^

^

Prestonia-C

Nocona

Jayhawk

0.13 µ/178 mtrs 3.06 GHz On-die 512K L2, 1M L3 533 MHz FSB µ PGA 603

0.09 µ/ 125 mtrs 2.8/3.0/3.2/3.4/3.6 GHz

0.09µ 3.8 GHz

On-die 1M L2 800 MHz FSB µ PGA 604

On-die 1M L2 (Cancelled 5/04)

Extreme Edition

11/03

11/04

1Q/05

^

^

^

Irwindale-B1

Irwindale-A1 0.13µ /178 mtrs 3.2EE GHz On-die 512K L2, 2M L3 800 MHz FSB µPGA 478

Desktop-line

Irwindale-C

11/00

8/01

1/02

5/02

11/02

5/03

2/04

6/04

8/04

^

^

^

^

^

^

^

^

^

Willamette

Willamette

0.18 µ /42 mtrs

0.18 µ /42 mtrs

1.4/1.5 GHz On-die 256K L2 400 MHz FSB

1.4 ... 2.0 GHz On-die 256K L2 400 MHz FSB

µ PGA 423

µ PGA 478

Northwood-A2,3

Northwood-B 4

Willamette-128 0.18µ 1.7 GHz On-die 128K L2 400 MHz FSB

µPGA 478

2001 Cores supporting hyperthreading

Prescott 6,7

Prescott 8,9,10

^ Prescott-F11

Tejas

0.13 µ /55 mtrs 0.09µ /125mtrs 0.09 µ / 0.13 µ /55 mtrs 0.09µ /125mtrs 0.13 µ /55 mtrs 0.09µ /125mtrs 2A/2.2 GHz 3.06 GHz 2.40C/2.60C/2.80C GHz 2.80E/3E/3.20E/3.40E GHz 2.8/3.0/3.2/3.4/3.6 GHz 3.20F/3.40F/3.60F GHz 4.0/4.2 GHz 2.26/2.40B/2.53 GHz On-die 1M L2 On-die 512K L2 On-die 512K L2 On-die 1M L2 On-die 512K L2 On-die 512K L2 On-die 1M L2 On-die 1M L2 (Cancelled 5/04) 800 MHz FSB 800 MHz FSB 400 MHz FSB 533 MHz FSB 533 MHz FSB 800 MHz FSB 800 MHz FSB µ PGA 478 µ LGA 775 PGA 478 LGA 775 µPGA 478 µ PGA 478 µ PGA 478

^

2000

Northwood-C5

3Q/05

0.13 µ /55 mtrs

5/02

Celeron-line (Value PC-s)

Northwood-B

0.09 µ 3.0/3.2/3.4/3.6 GHz On-die 512K L2, 2M L3

0.13µ /178mtrs 3.4EE GHz On-die 512K L2, 2 MB L3 1066 MHz FSB LGA 775

9/02

6/04

9/04

^

^

^

Northwood-128

Celeron-D12

0.13µ 2 GHz On-die 128K L2 400 MHz FSB

0.09µ 2.4/2.53/2.66/2.8 GHz On-die 256K L2 533 MHz FSB µ PGA 478

µPGA 478

2002

2003

Cores with EM64T implemented but not enabled

Celeron-D13 0.09µ 2.53/2.66/2.80/2.93 GHz On-die 256K L2 533 MHz FSB LGA 775

2005

2004 Cores supporting EM64T

Figure 2.2: Intel’s Pentium 4 processor family (Netburst architecture) © Sima Dezső, ÓE NIK

599

www.tankonyvtar.hu

2.2 The 90 nm Pentium 4 Prescott DP based DP server platform (5) Basic system architecture of the 90 nm Pentium 4 Prescott DP based DP server platform Xeon DP 2.8 /Paxville DP)

90 nm Pentium 4 Prescott DP (2x1C)

Pentium 4 Prescott DP (2x1C)

FSB

E7520 MCH

DDR-266/333 DDR2-400

HI 1.5 ICH5R/ 6300ESB

90 nm Pentium 4 Prescott DP based DP platform (for up to 2 C) HI 1.5 (Hub Interface 1.5) 8 bit wide, 66 MHz clock, QDR, 66 MB/s peak transfer rate

© Sima Dezső, ÓE NIK

600

www.tankonyvtar.hu

2.2 The 90 nm Pentium 4 Prescott DP based DP server platform (6) Example: Typical 90 nm Pentium 4 Prescott DP (Paxville DP 2.8) based DP platform Pentium 4

Pentium 4

Paxville DP proc.

Paxville DP proc.

FSB 800 MHz PCI-X v.1.0b

GbE SCSI

PCI E. x8

GbE c.

PCI-X bridge

SCSI c.

PCI E. x8 PCI E. x8

PCI-X v.1.0b

4000 4000

3200

E7520

21283200

SDRAM interface

21283200

SDRAM interface

MCH

4000

DDR/DDR2

16/24/32 GB DDR 266/333, DDR2 400 registered, ECC opt.

DDR/DDR2

(with RASUM)

PCI E. x8 (or 2x x4)

HI 1.5

266

DDR/DDR2 SVGA

Video c.

MbE

MbE c.

PCI v.2.3

133

LAN

PCI v.2.3

ICH5R USB v. 2.0 (4 ports) AC' 97 v.2.3

Ultra ATA/100 (2 ports)

2*100

SATA (2 ports)

2*150

60

GPIO ~1.4

~5

LPC

SIO

FWH FD

© Sima Dezső, ÓE NIK

601

KB MS

SP

PP

www.tankonyvtar.hu

2.3 Core 2 and Penryn based DP server platforms (1) 2.3 Core 2 and Penryn based DP server platforms Overview

© Sima Dezső, ÓE NIK

602

www.tankonyvtar.hu

2.3 Core 2 and Penryn based DP server platforms (2) 5/2006 DP platforms

DP cores

5000

6/2006 5000

(Bensley)

(Bensley)

5/2006

6/2006

Xeon 5000

10/2007 5100 (Cranberry Lake) 11/2006

Xeon 5100

(Dempsey) 2x1C (Woodcrest) 2C

11/2007

Xeon 5300 (Clowertown) 2x2C

Xeon 5200

(Harpertown) 2C (Harpertown) 4C

65 nm/2*188 mtrs 65 nm/291 mtrs 65 nm/2*291 mtrs 4 MB L2 2*2 MB L2 2*4 MB L2 667/1066 MT/s 667/1066 MT/s 667/1066 MT/s LGA771 LGA771 LGA771 5/2006 MCH

E5000P/V1/Z1 (Blackford) 2xFSB ESI 1066 MT/s

6/2006

E5100 (San Clemente)

(Blackford enhanced)

1333 MT/s

4 FBDIMM channels DDR2-533 4 DIMMs/channel 1500V/Z: 2x FBDIMM channels max. 64GB max. 16 GB

ICH

Pentium 4 based

© Sima Dezső, ÓE NIK

Core 2 based

631xESB 632xESB

Penryn based

Core 2-based (65 nm)

45 nm/850 mtrs 45 nm/850 mtrs 2*6 MB L2 2*6 MB L2 1066/1333 MT/s 1066/1333 MT/s LGA771 LGA771 10/2007

E5000P/V1/Z1

5/2006

Xeon 5400

603

2xFSB ESI 1333/1066 MT/s 2 x DDR2 channels DDR2-533/667 3 DIMMs/channel max. 32/48 GB 6/2007

ICHR9 Penryn-based (45 nm)

www.tankonyvtar.hu

2.3.1 The Core 2 based Bensley DP server platform (1) 2.3.1 The Core 2 based Bensley DP server platform

© Sima Dezső, ÓE NIK

604

www.tankonyvtar.hu

2.3.1 The Core 2 based Bensley DP server platform (2) 5/2006 DP platform

5000

DP cores

6/2006 5000

(Bensley)

(Bensley)

5/2006

6/2006

Xeon 5000

11/2006

Xeon 5100

(Dempsey) 2x1C (Woodcrest) 2C

Xeon 5300 (Clowertown) 2x2C

65 nm/2*188 mtrs 65 nm/291 mtrs 65 nm/2*291 mtrs 4 MB L2 2*2 MB L2 2*4 MB L2 667/1066 MT/s 667/1066 MT/s 667/1066 MT/s LGA771 LGA771 LGA771 5/2006 MCH

E5000P/V1/Z1 (Blackford) 2xFSB ESI 1066 MT/s

11/2007 Xeon 5200

Xeon 5400

(Harpertown) 2C (Harpertown) 4C 45 nm/850 mtrs 45 nm/850 mtrs 2*6 MB L2 2*6 MB L2 1066/1333 MT/s 1066/1333 MT/s LGA771 LGA771

6/2006 E5000P/V1/Z1 (Blackford enhanced)

1333 MT/s

4 FBDIMM channels DDR2-533 4 DIMMs/channel 1500V/Z: 2x FBDIMM channels max. 64GB max. 16 GB 5/2006 ICH

© Sima Dezső, ÓE NIK

Pentium 4 based Core 2 based

631xESB 632xESB

Penryn based Core 2-based (65 nm)

605

www.tankonyvtar.hu

2.3.1 The Core 2 based Bensley DP server platform (3) Remarks 1) • The Bensley platform appeared along with the 65 nm Pentium 4 Prescott DP based Xeon 5000 that supports FSB speeds up to 1066 MT/s in 5/2006. • One months later however, along with the introduction of the Core 2 based Xeon 5100 line of processors the Bensley platform became enhanced to 1333 MT/s FSB speed to support the Xeon 5100 line of processors. • Based on this, it can be assumed, that the Bensley platform was originally developed to support Core 2 based processor lines, along with the preceding 65 nm Pentium 4 Prescott DP (Xeon 5000) line of processors. This is the reason why we consider the Bensley platform as being Core 2 based. 2) • The Bensey platform became a long-lived one, as it supports also the later Penryn based Xeon 5200/5400 lines of processors. • Compared with the subsequent E5100 chipset based Cranberry Lake platform it represents the high performance higher cost solution.

© Sima Dezső, ÓE NIK

606

www.tankonyvtar.hu

2.3.1 The Core 2 based Bensley DP server platform (4)

Xeon 5000 (Dempsey)

Paxville DP 2.8

2xCedar Mill/65 nm (65 nm shrink of the Irwindale)

2xIrwindale cores/90 nm

Figure 2.3: Intel’s Pentium 4 based DC DP server processors [33], [34] © Sima Dezső, ÓE NIK

607

www.tankonyvtar.hu

2.3.1 The Core 2 based Bensley DP server platform (5) Basic system architecture of the Core 2 based Bensley DPserver platform Xeon 5400 Xeon 5200 Xeon 5000 Xeon 5100 Xeon 5300 / / / / / (Harpertown) (Harpertown) (Dempsey) (Woodcrest) (Clowertown) 4C 2C 2x1C 2C 2x2C

Xeon DP 2.8 /Paxville DP)

90 nm Pentium 4 Prescott DP (2x1C)

65 nm Pentium 4 Prescott DP (2x1C)/ Core2 (2C/2*2C/4C)

90 nm Pentium 4 Prescott DP (2x1C)

FSB

FSB

E7520 MCH

E5000 MCH

HI 1.5

ICH5R/ 6300ESB IOH

ESI DDR-266/333 DDR2-400

631*ESB/ 632*ESB IOH

90 nm Pentium 4 Prescott DP based DP server platform (for up to 2 C) HI 1.5 (Hub Interface 1.5) 8 bit wide, 66 MHz clock, QDR, 66 MB/s peak transfer rate

© Sima Dezső, ÓE NIK

65 nm Pentium 4 Prescott DP (2C)/ Core2 (2C/2*2C/4C)

FBDIMM w/DDR2-533

Core 2 based Bensley DP server platform (for up to 4 C)

608

ESI: Enterprise System Interface 4 PCIe lanes, 0.25 GB/s per lane (like the DMI interface, providing 1 GB/s transfer rate in each direction)

www.tankonyvtar.hu

2.3.1 The Core 2 based Bensley DP server platform (6) Note • A key statement for platform components is that higher processor performance, achieved e.g. by more cores per processors needs • higher FSB transfer rate, to serve more memory and I/O traffic (in case of system architectures based upon FSB), • higher memory bandwidth to satisfy increased memory traffic (both data and instructions), and • usually also higher memory capacity to serve more complex applications or larger data sets often used on higher performance systems. • As the 65 nm Pentium 4 DP / Core 2 based Bensley platform is intended to serve up to 4 cores per processor instead of 2 supported by the previous platform, the Bensley platform became redesigned to avoid possible system bottlenecks by • implementing two FSBs instead of one used in the previous platform, • introducing serially connected FBDIMM memory that allows doubling the number of memory channels and consequently to double the memory bandwidth and memory capacity, • using higher memory speed, i.e. DDR2-533 memory instead of DDR2-400 or lower memory speed supported by the previous platform.

© Sima Dezső, ÓE NIK

609

www.tankonyvtar.hu

2.3.1 The Core 2 based Bensley DP server platform (7) Example 1: Core 2 based Bensley DP server platform

Xeon 5000 Xeon 5100 / (Dempsey) (Woodcrest) 2x1C 2C

The 500V/Z chipsets support only 2 FBDIMM channels (max. 16 GB)

Figure 2.4: Intel’s Bensley DP server platform [53] (Actually the block diagram of Tyan’s S5370 DP server) © Sima Dezső, ÓE NIK

610

www.tankonyvtar.hu

2.3.1 The Core 2 based Bensley DP server platform (8) Example 2: Core 2 based Bensley DP server board

FB-DIMM DDR2

Xeon DC/QC 5000 DC 5100 DC 5300 QC

64 GB

5000P

SBE2

Figure 2.5: Bensley DP server board, with the 5000 (Blackford) chipset (Supermicro X7DB8+) for the Xeon 5000 DC/QC DP processor families [7] © Sima Dezső, ÓE NIK

611

www.tankonyvtar.hu

2.3.1 The Core 2 based Bensley DP server platform (9)

Table 2.2: Latency and bandwidth scaling of the Intel 5000 platform (2006) vs the earlier generation (2004) [1] © Sima Dezső, ÓE NIK

612

www.tankonyvtar.hu

2.3.2 The Penryn based Cranberry Lake DP server platform (1) 2.3.2 The Penryn based Cranberry Lake DP server platform

© Sima Dezső, ÓE NIK

613

www.tankonyvtar.hu

2.3.2 The Penryn based Cranberry Lake DP server platform (2) 5/2006 DP platforms

DP cores

5000

6/2006 5000

(Bensley)

(Bensley)

5/2006

6/2006

Xeon 5000

10/2007 5100 (Cranberry Lake) 11/2006

Xeon 5100

(Dempsey) 2x1C (Woodcrest) 2C

11/2007

Xeon 5300 (Clowertown) 2x2C

Xeon 5200

(Harpertown) 2C (Harpertown) 4C

65 nm/2*188 mtrs 65 nm/291 mtrs 65 nm/2*291 mtrs 4 MB L2 2*2 MB L2 2*4 MB L2 667/1066 MT/s 667/1066 MT/s 667/1066 MT/s LGA771 LGA771 LGA771 5/2006 MCH

E5000P/V1/Z1 (Blackford) 2xFSB ESI 1066 MT/s

6/2006

E5100

E5000P/V1/Z1

(San Clemente)

(Blackford enhanced)

1333 MT/s

Pentium 4 based

5/2006

© Sima Dezső, ÓE NIK

Core 2 based

631xESB 632xESB

Penryn based

Core 2-based (65 nm)

45 nm/850 mtrs 45 nm/850 mtrs 2*6 MB L2 2*6 MB L2 1066/1333 MT/s 1066/1333 MT/s LGA771 LGA771 10/2007

4 FBDIMM channels DDR2-533 4 DIMMs/channel 1500V/Z: 2x FBDIMM channels max. 64GB max. 16 GB

ICH

Xeon 5400

614

2xFSB ESI 1333/1066 MT/s 2 x DDR2 channels DDR2-533/667 3 DIMMs/channel max. 32/48 GB 6/2007

ICHR9 Penryn-based (45 nm)

www.tankonyvtar.hu

2.3.2 The Penryn based Cranberry Lake DP server platform (3) Basic system architecture of the Penryn based Cranberry Lake DP server platform Xeon 5400 Xeon 5200 Xeon 5000 Xeon 5100 Xeon 5300 / / / / / (Harpertown) (Dempsey) (Woodcrest) (Clowertown) (Harpertown) 4C 2C 2x1C 2C 2x2C 65 nm Pentium 4 Prescott DP (2x1C)/ Core2 (2C/2*2C/4C)

65 nm Pentium 4 Prescott DP (2Cx1)/ Core2 (2C/2*2C/4C)

Core 2 (2C/2x2C)/ Penryn (2C/4C)

Core 2 (2C/2x2C)/ Penryn (2C/4C)

FSB

FSB

E5000 MCH

E5100 MCH

ESI

631*ESB/ 632*ESB IOH

ESI

FBDIMM w/DDR2-533

Core 2 based Bensley DP server platform (for up to 4 C)

© Sima Dezső, ÓE NIK

Xeon 5300 / Xeon 5200 / Xeon 5400 Xeon 5100 (Harpertown) Woodcrest /(Clowertown) (Harpertown) 2x2C 4C 2C 2C

DDR2-533/667

ICHR9

Penryn based Cranberry Lake DP server platform (for up to 4 C)

615

www.tankonyvtar.hu

2.3.2 The Penryn based Cranberry Lake DP server platform (4) Note The Cranberry Lake platform provides a lower cost/lower dissipation and lower performance alternative to the previous Bensley platform by substituting the serially connected FBDIMM memory by parallel connected commodity DDR2 DRAM. Due to the restrictions of parallel connected memories in 3-chip system architectures the number of memory channels is limited to two, consequently this platform provides about ½ of the memory bandwidth and ¼ of the memory capacity of the previous Bensley platform.

© Sima Dezső, ÓE NIK

616

www.tankonyvtar.hu

2.3.2 The Penryn based Cranberry Lake DP server platform (5) Example: Intel’s Penryn based Cranberry Lake DP server platform

Xeon 5400 (QC) Xeon 5200 (DC)

5100 chipset

Figure 2.6: The Cranberry Lake DP server platform [19] © Sima Dezső, ÓE NIK

617

www.tankonyvtar.hu

2.4 Nehalem based DP server platforms (1) 2.4 Nehalem based DP server platforms Overview

© Sima Dezső, ÓE NIK

618

www.tankonyvtar.hu

2.4 Nehalem based DP server platforms (2) 3/2009 DP platforms

DP cores

3/2010

Tylersburg-EP

Boxboro-EP

3/2009

3/2010

3/2010

4/2011

Xeon 55xx

Xeon 56xx

Xeon 65xx

Xeon E7-28xx

(Gainestown Nehalem-EP) 4C

(Gulftown Westmere-EP) 6C

(Nehalem-EX) (Becton) 8C

(Westmere-EX) 10C

45 nm/731 mtrs/263 mm2 ¼ MB L2/C 8 MB L3 2 QPI links 3 DDR3/channels 1333 MT/s 3 DIMMs/channels LGA-1366

32 nm/1170 mtrs/248 mm2 ¼ MB L2/C

45 nm/2300 mtrs/513 mm2 ¼ MB L2/C 24 MB L3 2 QPI links 4 SMI links 2 mem. channels/link 2 DIMMs/mem. channel DDR3 1067 MT/s 1 TB (64x16 GB) LGA1567

32 nm/2600 mtrs/584 mm2 ¼ MB L2/C 30 MB L3 4 QPI links 4 SMI links 2 mem. channels/link 2 DIMMs/mem. channel DDR3 1333 MT/s 1 TB (64x16 GB) LGA1567

12 MB L3 2 QPI links 3 DDR3 channels 1333 MT/s 3 DIMMs/channel LGA-1366

3/2009 IOH

3/2010

55xx IOH

7500

(Boxboro) 2 QPI links

(Boxboro) 2 QPI links 32xPCIe 2. Gen. 0.5 GB/s/lane/direction ESI 1GB/s/directon

36xPCIe 2. Gen. 0.5 GB/s/lane/direction ESI 1GB/directon 2007/2008 ICH

6/2008

ICH9/ICH10

Nehalem-EP-based 45 nm © Sima Dezső, ÓE NIK

ICH10

Westmere-EP 32 nm

619

Nehalem-EX-based 45 nm

Westmere-EX 32 nm www.tankonyvtar.hu

2.4.1 The Nehalem-EP based Tylersburg-EP DP server platform (1) 2.4.1 The Nehalem-EP based Tylersburg-EP DP server platform

© Sima Dezső, ÓE NIK

620

www.tankonyvtar.hu

2.4.1 The Nehalem-EP based Tylersburg-EP DP server platform (2) 3/2009 DP platforms

DP cores

Tylersburg-EP 3/2009

3/2010

Xeon 55xx

Xeon 56xx

(Gainestown Nehalem-EP) 4C

(Gulftown Westmere-EP) 6C

45 nm/731 mtrs/263 mm2 ¼ MB L2/C 8 MB L3 2 QPI links 3 DDR3/channels 1333 MT/s 3 DIMMs/channels LGA-1366

32 nm/1170 mtrs/248 mm2 ¼ MB L2/C 12 MB L3 2 QPI links 3 DDR3 channels 1333 MT/s 3 DIMMs/channel LGA-1366

3/2009 IOH

55xx IOH (Boxboro) 2 QPI links 36xPCIe 2. Gen. 0.5 GB/s/lane/direction ESI 1GB/directon 2007/2008

ICH

ICH9/ICH10

Nehalem-EP-based 45 nm © Sima Dezső, ÓE NIK

Westmere-EP 32 nm 621

www.tankonyvtar.hu

2.4.1 The Nehalem-EP based Tylersburg-EP DP server platform (3) Basic system architecture of the Nehalem-EP based Tylersburg-EP DP server platform Xeon 5300 (Clowertown)

or

Xeon 5400 Xeon 5200 or (Harpertown) (Harpertown)

Core 2 (2C/2x2C)/ Penryn (2C/4C) proc.

Xeon 55xx or (Gainestown)

Core 2 (2c/2x2C)/ Penryn (2C/4C) proc.

Nehalem-EP (4C) Westmere-EP (6C) proc.

Xeon 56xx (Gulftown)

Nehalem-EP (4C) Westmere-EP (6C) proc.

QPI

QPI

QPI FSB DDR3-1333

DDR3-1333

55xx IOH1

ME

5100 MCH ESI

ESI

DDR2-533/667

CLink

ICH9/ICH10

ICHR9

Penryn based Cranberry Lake DP server platform (for up to 4 C)

Nehalem-EP based Tylersburg DP server platform (for up to 4 C) ME: Management Engine

© Sima Dezső, ÓE NIK

622

1First

chipset with PCI 2.0

www.tankonyvtar.hu

2.4.1 The Nehalem-EP based Tylersburg-EP DP server platform (4) Note • In 3-chip Nehalem based or subsequent system architectures the MCH (Memory Control Hub) is renamed to IOH (IO Hub) as in these kind of processors the memory is attached to the processors. • By contrast, in 2-chip system architectures the chipset part is designated as the PCH (Platform Control Hub).

© Sima Dezső, ÓE NIK

623

www.tankonyvtar.hu

2.4.1 The Nehalem-EP based Tylersburg-EP DP server platform (5) Remarks 1) Clink • The Clink connects the ME (Management Engine) included in the IOH to the ICH9/ICH10. • This is needed as data and firmware required for the operation of ME are stored in the nonvolatile flash memory (along with the BIOS) that is connected to the ICH9/ICH10 via the SPI (Serial Peripheral Interface) bus. • The Clink also passes the Platform Environmental Control Interface (PECI) signals (used for the dissipation control of the entire platform) from the ICH to the ME. 2) The Tylersburg_EP DP server platform substitutes both the Core 2 based Bensley and the Penryn based Cranberry Lake DP platforms.

© Sima Dezső, ÓE NIK

624

www.tankonyvtar.hu

2.4.1 The Nehalem-EP based Tylersburg-EP DP server platform (6) 65 nm Pentium 4 Prescott DP (2C)/ Core2 (2C/2*2C)

65 nm Pentium 4 Prescott DP (2C)/ Core2 (2C/2*2C)

Nehalem-EP (4C) Westmere-EP (6C)

FBDIMM w/DDR2-533

DDR3-1333

55xx IOH1 ESI

ESI 631*ESB/ 632*ESB IOH

Nehalem-EP (4C) Westmere-EP (6C)

QPI

CLink

DDR3-1333

55xx IOH1

ESI

ESI DDR2-533/667 ICHR9

55xx IOH1

DDR3-1333

CLink

ICH9/ICH10

625

QPI

ME

Nehalem-EP (4C) Westmere-EP (6C) QPI

QPI

FSB

Penryn based lower performance Cranberry Lake DP server platform (for up to 4 C)

DDR3-1333

Nehalem-EP based Tylersburg-EP DP server platform with a single IOH (for up to 6 C)

Core 2 (2c/2x2C)/ Penryn (2C/4C)

5100 MCH

ME

ICH9/ICH10

Core 2 based high performance Bensley DP server platform (for up to 4 C) Core 2 (2C/2x2C)/ Penryn (2C/4C)

QPI

QPI

FSB 5000 MCH

Nehalem-EP (4C) Westmere-EP (6C)

QPI

ME: Management Engine chipset with PCI 2.0

1First

Nehalem-EP based Tylersburg DP server platform with dual IOHs (for up to 6 C)

2.4.1 The Nehalem-EP based Tylersburg-EP DP server platform (7) Alternative implementations of the 55xx IOH [54]

© Sima Dezső, ÓE NIK

626

www.tankonyvtar.hu

2.4.1 The Nehalem-EP based Tylersburg-EP DP server platform (8) Platform innovations introduced in the Nehalem-EP processors (1) • On-die memory controller • Provides scalable memory bandwidth and capacity while increasing the number of processors. • Allows to increase the number of memory channels beyond two if needed since the processor has now to maintain much less connections altogether than the MCH did and consequently the number of memory channels is not more limited physically by the large number of copper trails to be implemented on the motherboard to two. • QPI links instead of the FSB Allow low pin count (84 connections) high speed sequential connection between the processors and the processors and the IOH. The FSB of 64-bit processors needs almost 200 pins.

© Sima Dezső, ÓE NIK

627

www.tankonyvtar.hu

2.4.1 The Nehalem-EP based Tylersburg-EP DP server platform (9) Note With on-die memory controllers and the serial QPI bus as system link Intel introduced basically the same system architecture in 2008 as AMD did with their Direct Connect Architecture in 2003. There are however two minor differences • In 2008 Intel implemented up to four system links per chip rather than 3 as AMD did in 2003. This allows to implement a fully connected MP server (including 4 processors). Nevertheless, AMD increased the number of links to four as well in their first major revision of the 2003 introduced Opteron (K8) servers, called the Barcelona (K10) line of processors in 2007. • As system link AMD implemented the standard serial Hypertransport (HT) link whereas Intel made use of their proprietary QPI link.

© Sima Dezső, ÓE NIK

628

www.tankonyvtar.hu

2.4.1 The Nehalem-EP based Tylersburg-EP DP server platform (10) Platform innovation introduced in the 55xx DP IOH (2) PCIe 2.0 links instead of PCIe 1.0 links The 2. gen. PCIe technology doubles the per lane transfer rate of PCI 1.0 from 250 MB/s to 500 MB/s in each direction. It uses a base clock frequency of 5 GHz vs. 2.5 GHz of the PCI 1.0 with a 10 bit/8 bit encoding. For PCI 2.0 links this results in a per lane transfer rate of (5 GHz x 8 bit/10 bit)/8 = 0.5 GB/s in each direction.

© Sima Dezső, ÓE NIK

629

www.tankonyvtar.hu

2.4.1 The Nehalem-EP based Tylersburg-EP DP server platform (11) Security and manageability features introduced in the 55xx IOH (1) Along with their Nehalem based Tylersburg-EP platform Intel continued their move to increase system security and manageability by introducing platform features provided else by their continuously enhanced vPro technology for enterprise oriented desktops since 2006. Main platform features introduced in the 55xx IOH include:

© Sima Dezső, ÓE NIK

630

www.tankonyvtar.hu

2.4.1 The Nehalem-EP based Tylersburg-EP DP server platform (12) Security and manageability features introduced in the 55xx IOH (2) a) Intel Management Engine (ME) • ME is actually an embedded microcontroller that is included in the 55xx IOH. • In the Tylersburg-EP platform it provides out-of-band (without standard OS control) server platform services, not further specified in the 5500 datasheet. • ME runs a dedicated microkernel OS that allows an out-of-band processor management. The firmware of ME is held in a nonvolatile flash memory along with the BIOs and will be loaded into the ME via the ICH9/ICH10 and the Clink at system initialization before the main OS is started. Remark In the vPro technology implemented for enterprise desktops the ME is the heart of the AMT (Active management Technology) that allows system administrators to remotely manage PCs when the PC is shut down or there is a hardware error (e.g. hard disk failure) or the OS is unavailable.

[54] 5500 datasheet © Sima Dezső, ÓE NIK

631

www.tankonyvtar.hu

2.4.1 The Nehalem-EP based Tylersburg-EP DP server platform (13) Security and manageability features introduced in the 55xx IOH (3) b) Intel Virtualization Technology for Directed I/O (VT-d) [55], [56], [57] Virtualization technology in general • consists of a set of hardware and software components that allow running multiple OSs and applications in independent partitions. • Each partition is isolated and protected from all other partitions. • Virtualization enables among others • Server consolidation Substituting multiple dedicated servers by a single virtualized platform. • Legacy software migration Legacy software: software commonly used previously, written often in not more commonly used languages (such as Cobol) and running under not more commonly used OSs or platforms. Legacy software migration: moving legacy software to a recent platform. • Effective disaster recovery.

© Sima Dezső, ÓE NIK

632

www.tankonyvtar.hu

2.4.1 The Nehalem-EP based Tylersburg-EP DP server platform (14) Security and manageability features introduced in the 55xx IOH (4) Overview of the evolution of Intel’s virtualization technology VT It is Intel’s general designation for virtualization technology VT-x • Intel’s first generation VT implementation for x86 architectures. • It provides hardware support for processor virtualization. • Appeared first in 2005 for two Pentium 4 models (662. 672). VT-i • Intel’s first generation VT implementation for IA-64 (Itanium) architectures. • It provides hardware support for processor virtualization. • First implemented in the Montecito line of Itanium Processors in 2006. VT-d (Intel Virtualization Technology for Directed I/O) • Intel’s second generation VT implementation. • It adds chipset hardware features to enhance I/O performance and robustness of virtualization. • First implemented in the desktop oriented Bearlake chipset (x35) in 2007. • VT-d is supported now in the Tylersburg-EP DP server platform with the 55xx IOH.

© Sima Dezső, ÓE NIK

633

www.tankonyvtar.hu

2.4.1 The Nehalem-EP based Tylersburg-EP DP server platform (15) Security and manageability features introduced in the 55xx IOH (5) c) Intel Trusted Execution Technology (TXT) Set of extensions designed to control launching of system software in order to establish a protected environment for both the system software and any further software that it may execute.

© Sima Dezső, ÓE NIK

634

www.tankonyvtar.hu

2.4.1 The Nehalem-EP based Tylersburg-EP DP server platform (16) Example 1: Intel’s Nehalem-EP based Tylersburg-EP DP server platform with a single IOH [58]

ICH9/10

© Sima Dezső, ÓE NIK

635

www.tankonyvtar.hu

2.4.1 The Nehalem-EP based Tylersburg-EP DP server platform (17) Example 2: Intel’s Nehalem-EP based Tylersburg-EP DP server platform with dual IOHs [58]

© Sima Dezső, ÓE NIK

636

www.tankonyvtar.hu

2.4.2 The Nehalem-EX based Boxboro-EP DP server platform (1) 2.4.2 The Nehalem-EX based Boxboro-EP DP server platform

© Sima Dezső, ÓE NIK

637

www.tankonyvtar.hu

2.4.2 The Nehalem-EX based Boxboro-EP DP server platform (2) 3/2009 DP platforms

DP cores

3/2010

Tylersburg-EP

Boxboro-EP

3/2009

3/2010

3/2010

4/2011

Xeon 55xx

Xeon 56xx

Xeon 65xx

Xeon E7-28xx

(Gainestown Nehalem-EP) 4C

(Gulftown Westmere-EP) 6C

(Nehalem-EX) (Becton) 8C

(Westmere-EX) 10C

45 nm/731 mtrs/263 mm2 ¼ MB L2/C 8 MB L3 2 QPI links 3 DDR3/channels 1333 MT/s 3 DIMMs/channels LGA-1366

32 nm/1170 mtrs/248 mm2 ¼ MB L2/C

45 nm/2300 mtrs/513 mm2 ¼ MB L2/C 24 MB L3 2 QPI links 4 SMI links 2 mem. channels/link 2 DIMMs/mem. channel DDR3 1067 MT/s 1 TB (64x16 GB) LGA1567

32 nm/2600 mtrs/584 mm2 ¼ MB L2/C 30 MB L3 4 QPI links 4 SMI links 2 mem. channels/link 2 DIMMs/mem. channel DDR3 1333 MT/s 1 TB (64x16 GB) LGA1567

12 MB L3 2 QPI links 3 DDR3 channels 1333 MT/s 3 DIMMs/channel LGA-1366

3/2009 IOH

3/2010

55xx IOH

7500

(Boxboro) 2 QPI links

(Boxboro) 2 QPI links 32xPCIe 2. Gen. 0.5 GB/s/lane/direction ESI 1GB/s/directon

36xPCIe 2. Gen. 0.5 GB/s/lane/direction ESI 1GB/directon 2007/2008 ICH

6/2008

ICH9/ICH10

Nehalem-EP-based © Sima Dezső, ÓE NIK 45 nm

ICH10

Westmere-EP 32 nm 638

Nehalem-EX-based 45 nm

Westmere-EX 32 nm www.tankonyvtar.hu

2.4.2 The Nehalem-EX based Boxboro-EP DP server platform (3) Basic system architecture of the Nehalem-EX based Boxboro-EP DP server platform

SMB SMB SMB SMB

Xeon 6500 (Nehalem-EX) or (Becton) Nehalem-EX (8C) Westmere-EX (10C)

Xeon E7-2800 (Westmere-EX)

QPI

SMB SMB SMB

QPI

QPI

DDR3-1067

Nehalem-EX (8C) Westmere-EX (10C)

SMB

7500 IOH

DDR3-1067

ESI

ICH10

Figure 2.7: Nehalem-EX based Boxboro-EP DP server platform (for up to 10 cores)

© Sima Dezső, ÓE NIK

639

SMB: Scalable Memory Buffer (provides a serial bus connection to the processor)

www.tankonyvtar.hu

2.4.2 The Nehalem-EX based Boxboro-EP DP server platform (4) Xeon 56xx (Gulftown)

Xeon 55xx or (Gainestown) Nehalem –EP (4C) Westmere-EP (6C)

QPI

Nehalem-EP (4C) Westmere-EP (6C)

DMI2 DDR3-1333

34xx PCH

DDR3-1333

ME

Nehalem-EP based Tylersburg-EP DP server platform (for up to 6 cores)

SMB SMB SMB SMB

Xeon 6500 (Nehalem-EX) (Becton) Nehalem-EX (8C) Westmere-EX (10C)

Xeon E7-2800 (Westmere-EX)

or QPI

Nehalem-EX (8C) Westmere-EX (10C)

SMB SMB SMB SMB

QPI

QPI DDR3-1067

DDR3-1067 7500 IOH

ME

ESI

ICH10

Nehalem-EX based Boxboro-EP DP server platform (for up to 10 cores)

© Sima Dezső, ÓE NIK

640

www.tankonyvtar.hu

2.4.2 The Nehalem-EX based Boxboro-EP DP server platform (5) Notes 1) The DMI2 link • The DMI2 link is the 2. generation DMI (Direct Media Interface) point-to-point link. • It is typically a 4 lane PCIe 2.0 link (designated as PCIe 2.0 x4). • Its transfer rate is 4 x 5 Gb/s x 8/10 (encoding) = 16 Gb/s = 2 GB/s in each direction. By contrast, DMI provided 4 x 2.5 Gb/s x 8/10 (encoding) = 8 Gb/s = 1 GB/s in each direction. Compared to the QPI link the DMI2 link is a lower pin count link with reduced transfer rate. No. of signals QPI link DMI2 link

84 20

Transfer rate in each direction Up to 12.8 GB/s 2 GB/s

For the embedded DP Picket Post platform Intel presumably opted for a lower cost solution compared to the previous Tylersburg-EP platform. 2) Lack of the Clink In the 2-chip system solution the nonvolatile flash memory that holds the firmware for the ME is connected directly to the PCH thus there is no need for the Clink which is used in the 3-chip system solution to boot ME firmware from the nonvolatile flash memory to the IOH.

© Sima Dezső, ÓE NIK

641

www.tankonyvtar.hu

2.5 Sandy Bridge based Romley-EP DP server platforms (1) 2.5 Sandy Bridge based Romley-EP DP server platforms Overview

© Sima Dezső, ÓE NIK

642

www.tankonyvtar.hu

2.5 Sandy Bridge based Romley-EP DP server platforms (2)

DP Platforms

DP Cores

PCH

H2/2011

H2/2011

Romley-EP (Socket R)

Romley-EP (Socket B2)

H2/2011

H2/2011

E5-2xxx

E5-2xxx

Sandy Bridge–EN 8C

Sandy Bridge-EP 8C

32 nm/?? mtrs/?? mm2 ¼ MB L2/C 20 MB L3??

32 nm/?? mtrs/?? mm2 ¼ MB L2/C 20 MB L3??

2 QPI links/1 DMI2 link

1 QPI link/1 DMI2 link

4 DDR3 channels 1600 MT/s 3 DIMMs/channel

3 DDR3 channels 1600 MT/s 2 DIMMs/channel

LGA-2011

LGA-1356

H2/2011

H2/2011

C600 PCH

C600 PCH

(Patsburg)

(Patsburg)

1 DMI2 link/PECI

1 DMI2 link/PECI

Sandy Bridge-EN based 32 nm © Sima Dezső, ÓE NIK

Sandy Bridge-EP based 32 nm 643

www.tankonyvtar.hu

2.5 Sandy Bridge based Romley-EP DP server platforms (3) Basic system architecture of the Sandy Bridge-EN and -EP based Romley-EN and –EP DP server platforms

High performance alternative

E5-2000 Sandy Bridge–EN 8C Sandy BridgeEN (8C) Socket R (8C)

or QPI 1.1 QPI 1.1

E5-2000 Sandy Bridge-EP 8C Sandy BridgeEN (8C) Socket R (8C)

DMI2 Xeon 55xx or (Gainestown) Nehalem –EP (4C) Westmere-EP (6C)

QPI

C600 PCH

Xeon 56xx (Gulftown)

Sandy Bridge-EN (Socket R) based Romley-EP DP server platform (for up to 8 cores) (LGA 2011)

Nehalem-EP (4C) Westmere-EP (6C)

DMI2 DDR3-1333

34xx PCH

ME

DDR3-1600

Lower cost alternative DDR3-1333

Nehalem-EP based Tylersburg-EP DP server platform (for up to 6 cores)

E5-2000 Sandy Bridge–EN 8C Sandy BridgeEP (8C) Socket B2

or

QPI 1.1

E5-2000 Sandy Bridge-EP 8C Sandy BridgeEP (8C) Socket B2

DMI2 DDR3-1600

C600 PCH

© Sima Dezső, ÓE NIK

644

Sandy Bridge-EP (Socket B2) based Romley-EP DP server platform (for up to 8 cores)( (LGA 1356)

www.tankonyvtar.hu

2.5 Sandy Bridge based Romley-EP DP server platforms (4) Remark QPI 1.1 • It is the first revision of the QPI serial bus. • It planned to be used first in the Romley platform. • No specifications are published yet.

© Sima Dezső, ÓE NIK

645

www.tankonyvtar.hu

2.5 Sandy Bridge based Romley-EP DP server platforms (5) Remark At writing this slides no official documentation is available about the platform features provided by the Sandy Bridge based Romley-EP platforms.

© Sima Dezső, ÓE NIK

646

www.tankonyvtar.hu

2.5 Sandy Bridge based Romley-EP DP server platforms (6) Example: Sandy Bridge-EN (Socket R) and Sandy Bridge-EP (Socket B2) based Romley-EN/Romley-EP DP server platforms [59]

© Sima Dezső, ÓE NIK

647

www.tankonyvtar.hu

2.6 Evolution of DP server platforms (1) 2.6 Evolution of DP server platforms 2.6.1 Evolution of performance oriented DP server platforms

© Sima Dezső, ÓE NIK

648

www.tankonyvtar.hu

2.6.1 Evolution of performance oriented DP server platforms (1) Evolution from the Pentium 4 Prescott DP based DP platform (up to 2 cores) to the Core 2 based Bensley DP platform (up to 4 cores) Xeon 5400 Xeon 5200 Xeon 5000 Xeon 5100 Xeon 5300 / / / / / (Harpertown) (Harpertown) (Dempsey) (Woodcrest) (Clowertown) 4C 2C 2x1C 2C 2x2C

Xeon DP 2.8 /Paxville DP)

90 nm Pentium 4 Prescott DP (2C)

65 nm Pentium 4 Prescott DP (2x1C)/ Core2 (2C/2*2C/4C)

90 nm Pentium 4 Prescott DP (2C)

FSB

FSB

E7520 MCH

E5000 MCH

HI 1.5

ICH5R/ 6300ESB IOH

ESI DDR-266/333 DDR2-400

631*ESB/ 632*ESB IOH

90 nm Pentium 4 Prescott DP based DP server platform (for up to 2 C) HI 1.5 (Hub Interface 1.5) 8 bit wide, 66 MHz clock, QDR, 66 MB/s peak transfer rate

© Sima Dezső, ÓE NIK

65 nm Pentium 4 Prescott DP (2C)/ Core2 (2C/2*2C/4C)

FBDIMM w/DDR2-533

Core 2 based Bensley DPserver platform (for up to 4 C)

649

ESI: Enterprise System Interface 4 PCIe lanes, 0.25 GB/s per lane (like the DMI interface, providing 1 GB/s transfer rate in each direction)

www.tankonyvtar.hu

2.6.1 Evolution of performance oriented DP server platforms (2) Evolution from the Core 2 based Bensley DP platform (up to 4 cores) to the Nehalem-EP based Tylersburg-EP DP platform (up to 6 cores)

Nehalem-EP (4C) Westmere-EP (6C)

Nehalem-EP (4C) Westmere-EP (6C)

QPI

QPI

QPI

65 nm Pentium 4 Prescott DP (2C)/ Core2 (2C/2*2C)

DDR3-1333

65 nm Pentium 4 Prescott DP (2C)/ Core2 (2C/2*2C)

FSB

55xx IOH1 ESI

FBDIMM w/DDR2-533

DDR3-1333

CLink

ICH9/ICH10

Nehalem-EP based Tylersburg-EP DP server platform with a single IOH (for up to 6 C)

5000 MCH ESI

Nehalem-EP (4C) Westmere-EP (6C)

631*ESB/ 632*ESB IOH

QPI

DDR3-1333

55xx IOH1

ESI

55xx IOH1

DDR3-1333

CLink

ICH9/ICH10

650

QPI

ME

Nehalem-EP (4C) Westmere-EP (6C) QPI

QPI

65 nm Core 2 based high performance Bensley DP server platform (for up to 4 C)

© Sima Dezső, ÓE NIK

ME

ME: Management Engine chipset with PCI 2.0

1First

Nehalem-EP based Tylersburg DP server platform with dual IOHs (for up to 6 C) www.tankonyvtar.hu

2.6.1 Evolution of performance oriented DP server platforms (3) Evolution from the Nehalem-EP based Tylersburg-EP DP platform (up to 6 cores) to the Nehalem-EX based Boxboro-EX DP platform (up to 10 cores) Xeon 5600 Xeon 5500 or (Gulftown) (Gainestown) Nehalem –EP (4C) Westmere-EP (6C)

Nehalem –EP (4C) Westmere-EP (6C)

QPI

ESI DDR3-1333

34xx PCH

DDR3-1333

ME

Nehalem-EP based Tylersburg-EP DP server platform (for up to 6 cores)

SMB SMB SMB SMB

Xeon 6500 (Nehalem-EX) (Becton) Nehalem-EX (8C) Westmere-EX (10C)

Xeon E7-2800

or (Westmere-EX) Nehalem-EX (8C) Westmere-EX (10C)

QPI

QPI

QPI DDR3-1067

7500 IOH

SMB SMB SMB SMB DDR3-1067

ME

ESI ICH10

© Sima Dezső, ÓE NIK

Nehalem-EX based Boxboro-EX DP server platform (for up to 10 cores) 651

www.tankonyvtar.hu

2.6.2 Evolution of low cost oriented DP server platforms (1) 2.6.2 Evolution of low cost oriented DP server platforms

© Sima Dezső, ÓE NIK

652

www.tankonyvtar.hu

2.6.2 Evolution of low cost oriented DP server platforms (2) Evolution from the Pentium 4 Prescott DP based DP platform (up to 2 cores) to the Penryn based Cranberry Lake DP platform (up to 4 cores) Xeon 5300 (Clowertown) 2x2C

Xeon DP 2.8 /Paxville DP)

90 nm Pentium 4 Prescott DP (2C)

90 nm Pentium 4 Prescott DP (2C)

Core 2 (2C/2x2C)/ Penryn (2C/4C) proc.

FSB

E7520 MCH

E5100 MCH

HI 1.5

ESI

DDR-266/333 DDR2-400

HI 1.5 (Hub Interface 1.5) 8 bit wide, 66 MHz clock, QDR, 66 MB/s peak transfer rate

DDR2-533/667

ICHR9

Penryn based Cranberry Lake DP server platform (for up to 4 C)

90 nm Pentium 4 Prescott DP based DP server platform (for up to 2 C)

© Sima Dezső, ÓE NIK

Xeon 5400 Xeon 5200 or (Harpertown) (Harpertown) 4C 2C

Core 2 (2C/2x2C)/ Penryn (2C/4C) proc.

FSB

ICH5R/ 6300ESB IOH

or

653

ESI: Enterprise System Interface 4 PCIe lanes, 0.25 GB/s per lane (like the DMI interface, providing 1 GB/s transfer rate in each direction)

www.tankonyvtar.hu

2.6.2 Evolution of low cost oriented DP server platforms (3) Evolution from the Penryn based Cranberry Lake DP platform (up to 4 cores) to the Sandy Bridge-EP based Romley-EP DP platform (up to 8 cores)

Xeon 5300 (Clowertown) 2x2C

or

Xeon 5400 Xeon 5200 or (Harpertown) (Harpertown) 4C 2C

Core 2 (2C/2x2C)/ Penryn (2C/4C) proc.

Core 2 (2C/2x2C)/ Penryn (2C/4C) proc.

E5-2000 E5-2000 or Sandy Bridge–EN 8C Sandy Bridge-EP 8C

Sandy Bridge-EP (8C) Socket B2

FSB

Sandy Bridge-EP (8C) Socket B2

DMI2

E5100 MCH

ESI

QPI

C600 PCH

DDR3-1600

DDR2-533/667

ICHR9

Penryn based Cranberry Lake DP platform (for up to 4 C)

© Sima Dezső, ÓE NIK

Sandy Bridge-EP (Socket B2) based Romley-EP DP server platform (for up to 8 cores)( (LGA 1356)

654

www.tankonyvtar.hu

3. Intel’s MP platforms •

3.1 Introduction

•

3.2 The Pentium 4 based Truland MP platform

•

3.3 The Core 2 based Caneland MP platform

•

3.4 The Nehalem-EX based Boxboro-EX MP platform

•

3.5 Evolution of MP platforms

© Sima Dezső, ÓE NIK

655

www.tankonyvtar.hu

3.1 Introduction (1) 3.1 Introduction

© Sima Dezső, ÓE NIK

656

www.tankonyvtar.hu

3.1 Introduction (2) Basic Arch.

Pentium 4 (Prescott)

Core/technology

MP server processors

Pentium 4

90 nm

11/2005

Pentium 4

65 nm

8/2006

7100 (Tulsa)

Core2

65 nm

9/2007

7200 (Tigerton DC) 7300 (Tigerton QC)

1x2 C, 4 MB L2/C 2x2 C, 4 MB L2/C

Penryn

45 nm

9/2008

7400 (Dunnington)

1x6 C, 3 MB L2/2C 16 MB L3

Nehalem-EP

45 nm

Westmere-EP

32 nm

Nehalem-EX

45 nm

3/2010

7500 (Beckton)

1x8 C, ¼ MB L2/C 24 MB L3

Westmere-EX

32nm

4/2011

Sandy Bidge

32 nm

/2011

Ivy Bridge

22 nm

11/2012

Core 2

Paxville MP

2x1 C, 2 MB L2/C

2x1 C, 1 MB L2/C 16 MB L3

Nehalem

Sandy Bridge

© Sima Dezső, ÓE NIK

E7-48xx (Westmere-EX)

Table 3.1: Overview of Intel’s 657 multicore MP servers

1x10 C, ¼ MB L2/C 30 MB L3

www.tankonyvtar.hu

3.1 Introduction (3)

MP server platforms

Pentium 4 based MP server platform

Core 2 based MP server platform

Nehalem-EX based MP server platform

Sandy Bridge based MP server platform

Truland (2005) (90 nm/65 nm Pentium 4 Prescott MP based)

Caneland (2007)

Boxboro-EX (2010)

To be announced yet

© Sima Dezső, ÓE NIK

658

www.tankonyvtar.hu

3.2 The Pentium 4 Prescott MP based Truland MP server platform (1) 3.2 The Pentium 4 Prescott MP based Truland MP server platform Overview Remark For presenting a more complete view of the evolution of multicore MP server platforms we include also the single core (SC) 90 nm Pentium 4 Prescott based Xeon MP (Potomac) processor that was the first 64-bit MP server processor and gave rise to the Truland platform.

© Sima Dezső, ÓE NIK

659

www.tankonyvtar.hu

3.2 The Pentium 4 Prescott MP based Truland MP server platform (2) 3/2005 MP platforms

Truland 3/2005

MP cores

11/2005 Truland( updated) 11/2005

8/2006

Xeon MP

Xeon 7000

Xeon 7100

(Potomac) 1C

(Paxville MP) 2x1C

(Tulsa) 2C

90 nm/675 mtrs 90 nm/2x169 mtrs 65 nm/1328 mtrs 1 MB L2 2x1 (2) MB L2 2x1 MB L2 8/4 MB L3 16/8/4 MB L3 667 MT/s 800/667 MT/s 800/667 MT/s mPGA 604 mPGA 604 mPGA 604 3/2005 MCH

11/2005

E8500

E8501

(Twin Castle)

(Twin Castle?)

2xFSB 667 MT/s HI 1.5 4 x XMB (2 channels/XMB 4 DIMMs/channel DDR-266/333 DDR2-400 32GB

2xFSB 800 MT/s HI 1.5 4 x XMB (2 channels/XMB 4 DIMMs/channel DDR-266/333 DDR2-400 32GB

4/2003 ICH

Pentium 4 based

ICH5

Core 2 based Penryn based

© Sima Dezső, ÓE NIK

Pentium 4-based/90 nm660

Pentium 4-based/65 nm

www.tankonyvtar.hu

3.2 The Pentium 4 Prescott MP based Truland MP server platform (3) 3/02

11/02

^

^

Foster-MP

Gallatin

0.18 µ /108 mtrs 1.4/1.5/1.6 GHz

0.13 µ /178 mtrs 1.5/1.9/2 GHz

On-die 256K L2 On-die 512K/1M L3 400 MHz FSB µ PGA 603

On-die 512K L2 On-die 1M/2M L3 400 MHz FSB µ PGA 603

Xeon - MP line

Xeon DP line

2Q/05

3/04

^

^

Potomac

Gallatin

0.09µ > 3.5 MHz

0.13 µ /286 mtrs 2.2/2.7/3.0 GHz

On-die 1M L2 On-die 8M L3 (?)

On-die 512K L2 On-die 2M/4M L3 400 MHz FSB µ PGA 603

5/01

2/02

11/02

7/03

6/04

^

^

^

^

^

2Q/05

^

Foster

Prestonia-A

Prestonia-B

Prestonia-C

Nocona

Jayhawk

0.18 µ /42 mtrs 1.4/1.5/1.7 GHz

0.13 µ /55 mtrs 1.8/2/2.2 GHz

0.09µ 3.8 GHz

On-die 512K L2 400 MHz FSB µ PGA 603

0.13 µ/178 mtrs 3.06 GHz On-die 512K L2, 1M L3 533 MHz FSB µ PGA 603

0.09 µ/ 125 mtrs 2.8/3.0/3.2/3.4/3.6 GHz

On-die 256 K L2 400 MHz FSB µPGA 603

0.13 µ /55 mtrs 2/2.4/2.6/2.8 GHz On-die 512K L2 533 MHz FSB µ PGA 603

On-die 1M L2 800 MHz FSB µ PGA 604

On-die 1M L2 (Cancelled 5/04)

Extreme Edition

11/03

11/04

1Q/05

^

^

^

Irwindale-B1

Irwindale-A1 0.13µ /178 mtrs 3.2EE GHz On-die 512K L2, 2M L3 800 MHz FSB µPGA 478

Desktop-line

8/01

1/02

5/02

11/02

5/03

2/04

6/04

8/04

^

^

^

^

^

^

^

^

^

Willamette

0.18 µ /42 mtrs

0.18 µ /42 mtrs

1.4/1.5 GHz On-die 256K L2 400 MHz FSB

1.4 ... 2.0 GHz On-die 256K L2 400 MHz FSB

µ PGA 423

µ PGA 478

Northwood-A2,3

Northwood-B 4

Willamette-128 0.18µ 1.7 GHz On-die 128K L2 400 MHz FSB

µPGA 478

2001 Cores supporting hyperthreading

Prescott 6,7

Prescott 8,9,10

3Q/05

^ Prescott-F11

Tejas

0.13 µ /55 mtrs 0.09µ /125mtrs 0.09 µ / 0.09µ /125mtrs 0.13 µ /55 mtrs 0.13 µ /55 mtrs 0.09µ /125mtrs 3.06 GHz 2.40C/2.60C/2.80C GHz 2.80E/3E/3.20E/3.40E GHz 2.8/3.0/3.2/3.4/3.6 GHz 3.20F/3.40F/3.60F GHz 4.0/4.2 GHz 2A/2.2 GHz 2.26/2.40B/2.53 GHz On-die 1M L2 On-die 1M L2 On-die 512K L2 On-die 512K L2 On-die 512K L2 On-die 512K L2 On-die 1M L2 On-die 1M L2 (Cancelled 5/04) 800 MHz FSB 800 MHz FSB 533 MHz FSB 400 MHz FSB 533 MHz FSB 800 MHz FSB 800 MHz FSB µ PGA 478 µPGA 478 LGA 775 LGA 775 µPGA 478 µ PGA 478 µ PGA 478

^

2000

Northwood-C5

µPGA604

0.13 µ /55 mtrs

5/02

Celeron-line (Value PC-s)

Northwood-B

0.09 µ 3.0/3.2/3.4/3.6 GHz On-die 512K L2, 2M L3

0.13µ /178mtrs 3.4EE GHz On-die 512K L2, 2 MB L3 1066 MHz FSB LGA 775

11/00 Willamette

2/05

Irwindale-C

9/02

6/04

9/04

^

^

^

Northwood-128

Celeron-D12

0.13µ 2 GHz On-die 128K L2 400 MHz FSB

0.09µ 2.4/2.53/2.66/2.8 GHz On-die 256K L2 533 MHz FSB µ PGA 478

µPGA 478

2002

2003

Cores with EM64T implemented but not enabled

Celeron-D13 0.09µ 2.53/2.66/2.80/2.93 GHz On-die 256K L2 533 MHz FSB LGA 775

2005

2004 Cores supporting EM64T

Figure 3.1: The Potomac processor as Intel’s first 64-bit Xeon MP processor based on the third core (Prescott core) of the Pentium 4 family of processors © Sima Dezső, ÓE NIK

661

www.tankonyvtar.hu

3.2 The Pentium 4 Prescott MP based Truland MP server platform (4) Basic system architecture of the 90 nm Pentium 4 Prescott MP based Truland MP server platform Xeon MP Xeon 7000 Xeon 7100 / / (Potomac) 1C (Paxville MP) 2x1C (Tulsa) 2C

Pentium 4 Xeon 1C/2x1C

Pentium 4 Xeon 1C/2x1C

Pentium 4 XeonP 1C/2x1C

Pentium 4 XeonP 1C/2x1C

FSB

XMB 85001/8501 XMB

XMB: eXxternal Memory Bridge Provides a serial link, 5.33 GB inbound BW 2.65 GB outbound BW (simultaneously)l

XMB XMB

HI 1.5 DDR-266/333 DDR2-400

ICH5

DDR-266/333 DDR2-400

HI 1.5 (Hub Interface 1.5) 8 bit wide, 66 MHz clock, QDR, 66 MB/s peak transfer rate

Pentium 4 Prescott MP based Truland MP server platform (for up to 2 cores)

1

© Sima Dezső, ÓE NIK

The E8500 MCH supports an FSB of 667 MT/s and consequently only the SC Xeon MP (Potomac)

662

www.tankonyvtar.hu

3.2 The Pentium 4 Prescott MP based Truland MP server platform (5) Expanding the Truland platform to 3 generations of Pentium 4 based Xeon MP servers [60]

Xeon MP 1C

© Sima Dezső, ÓE NIK

Xeon 7000 2x1C

663

Xeon 7100 2C

www.tankonyvtar.hu

3.2 The Pentium 4 Prescott MP based Truland MP server platform (6) Example 1: Block diagram of a 8500 chipset based Truland MP server board [61]

Figure 3.2: Block diagram of a 8500 chipset based Truland MP server board [61] © Sima Dezső, ÓE NIK

664

www.tankonyvtar.hu

3.2 The Pentium 4 Prescott MP based Truland MP server platform (7) Example 2: Block diagram of the E8501 based Truland MP server platform [4]

Xeon DC MP 7000 (4/2005) or later DC/QC MP 7000 processors

IMI: Independent Memory Interface IMI: Serial link 5.33 GB inbound BW 2.67 GB outbound BW simultaneously XMB: eXxternal Memory Bridge

(North Bridge)

Intelligent MC Dual mem. channels DDR 266/333/400 4 DIMMs/channel

Figure 3.3: Intel’s 8501 chipset based Truland MP server platform (4/ 2006) [4] © Sima Dezső, ÓE NIK

665

www.tankonyvtar.hu

3.2 The Pentium 4 Prescott MP based Truland MP server platform (8) Example 3: E8501 based MP server board implementing the Truland platform 2 x XMB

DDR2 DIMMs

Xeon DC

64 GB

7000/7100

2 x XMB

E8501 NB

ICH5R SB

Figure 3.4: Intel E8501 chipset based MP server board (Supermicro X6QT8) for the Xeon 7000/7100 DC MP processor families [7]

© Sima Dezső, ÓE NIK

666

www.tankonyvtar.hu

3.2 The Pentium 4 Prescott MP based Truland MP server platform (9)

Figure 3.5: Bandwith bottlenecks in Intel’s 8501 based Truland MP server platform [2] © Sima Dezső, ÓE NIK

667

www.tankonyvtar.hu

3.2 The Pentium 4 Prescott MP based Truland MP server platform (10) Remark Previous (first generation) MP servers made use of a symmetric topology including only a single FSB that connects all 4 single core processors to the MCH (north bridge), as shown below. Typical system architecture of a first generation Xeon MP based MP server platform

Xeon MP1 SC

Xeon MP1 SC

Xeon MP1 SC

Xeon MP1 SC

FSB

Preceding NBs E.g. DDR-200/266

E.g. HI 1.5

Preceding ICH

E.g. DDR-200/266

HI 1.5 266 MB/s

Figure 3.6: Previous Pentium 4 MP based MP server platform (for single core processors) © Sima Dezső, ÓE NIK

668

www.tankonyvtar.hu

3.2 The Pentium 4 Prescott MP based Truland MP server platform (11) Example: Block diagram of an MP server board [65] that is based on Pentium 4 (Willamette MP) single core 32-bit Xeon MP processors (called Foster)

The memory is placed on an extra card. There are 4 memory controllers each supporting 4 DIMMs (DDR-266/200) The chipset (CMIC/CSB5) is ServerWorks’ Grand Champion HE Classic chipset

© Sima Dezső, ÓE NIK

669

www.tankonyvtar.hu

3.2 The Pentium 4 Prescott MP based Truland MP server platform (12) Evolution from the first generation MP servers supporting SC processors to the 90 nm Pentium 4 Prescott MP based Truland MP server platform (supporting up to 2 cores) Xeon MP Xeon 7000 Xeon 7100 / / (Potomac) 1C (Paxville MP) 2x1C (Tulsa) 2C

Xeon MP1 SC

Xeon MP1 SC

Xeon MP1 SC

Pentium 4 Xeon MP 1C/2x1C

Xeon MP1 SC

Pentium 4 Xeon MP 1C/2x1C

Pentium 4 Xeon MP 1C/2x1C FSB

FSB

XMB Preceding NBs

85001/8501 XMB

E.g. HI 1.5

E.g. DDR-200/266

Pentium 4 Xeon MP 1C/2x1C

E.g. DDR-200/266

XMB XMB

HI 1.5 DDR-266/333 DDR2-400

Preceding ICH

ICH5

DDR-266/333 DDR2-400

HI 1.5 266 MB/s

90 nm Pentium 4 Prescott MP based Truland MP server platform (for up to 2 C)

Previous Pentium 4 MP based MP server (for single core processors)

© Sima Dezső, ÓE NIK

670

www.tankonyvtar.hu

3.3 The Core 2 based Caneland MP server platform (1) 3.3 The Core 2 based Caneland MP server platform

© Sima Dezső, ÓE NIK

671

www.tankonyvtar.hu

3.3 The Core 2 based Caneland MP server platform (2) 9/2007 MP platforms

Caneland 9/2007

MP cores

Xeon 7200

9/2008 Xeon 7300

Xeon 7400

(Tigerton DC) 1x2C (Tigerton QC) 2x2C 65 nm/2x291 mtrs 65 nm/2x291 mtrs

(Dunnington 6C) 45 nm/1900 mtrs

2x4 MB L2 -

2x(4/3/2) MB L2 -

9/6 MB L2 16/12/8 MB L3

1066 MT/s mPGA 604

1066 MT/s mPGA 604

1066 MT/s mPGA 604

9/2007 MCH

E7300 (Clarksboro) 4xFSB 1066 MT/s ESI 4 x FBDIMM (DDR2-533/667 8 DIMMs/channel) 512GB

5/2006 ICH

Pentium 4 based

631xESB 632xESB

Core 2 based Penryn based

© Sima Dezső, ÓE NIK

Core2-based/65 672 nm

Penryn 45 nm

www.tankonyvtar.hu

3.3 The Core 2 based Caneland MP server platform (3) Basic system architecture of the Core 2 based Caneland MP server platform

Xeon MP Xeon 7000 Xeon 7100 / / (Potomac) 1C (Paxville MP) 2x1C (Tulsa) 2C

Pentium 4 Xeon MP 1C/2x1C

Pentium 4 Xeon MP 1C/2x1C

Pentium 4 Xeon MP 1C/2x1C

Pentium 4 Xeon MP 1C/2x1C

Xeon 7200 Xeon 7300 Xeon 7400 / / (Tigerton DC) 1x2C (Tigerton QC) 2x2C (Dunnington 6C)

Core2 (2C/4C) Penryn (6C)

FSB

XMB 85001/8501 XMB

Core2 (2C/4C) Penryn (6C)

Core2 (2C/4C) Penryn (6C)

Core2 (2C/4C) Penryn (6C)

FSB

XMB

up to 8 DIMMs

7300

XMB ESI

HI 1.5

DDR-266/333 DDR2-400

ICH5

DDR-266/333 DDR2-400

631xESB/ 632xESB

90 nm Pentium 4 Prescott MP based Truland MP server platform (for up to 2 C)

Core 2 based Caneland MP server platform (for up to 6 C)

ESI: Enterprise System Interface 4 PCIe lanes, 0.25 GB/s per lane (like the DMI interface, providing 1 GB/s transfer rate in each direction)

HI 1.5 (Hub Interface 1.5) 8 bit wide, 66 MHz clock, QDR, 66 MB/s peak transfer rate 1

© Sima Dezső, ÓE NIK

FBDIMM DDR2-533/667

The E8500 MCH supports an FSB of 667 MT/s and consequently only the SC Xeon MP (Potomac)

673

www.tankonyvtar.hu

3.3 The Core 2 based Caneland MP server platform (4) Example 1: Intel’s Nehalem-EP based Tylersburg-EP DP server platform with a single IOH Xeon 7200 (Tigerton DC, Core 2), 2C 7300 (Tigerton QC, Core 2), QC

FB-DIMM 4 channels 8 DIMMs/channel up to 512 GB

Figure 3.7: Intel’s 7300 chipset based Caneland platform for the Xeon 7200/7300 DC/QC processors (9/2007) [6] © Sima Dezső, ÓE NIK

674

www.tankonyvtar.hu

3.3 The Core 2 based Caneland MP server platform (5) Example 3: Caneland MP serverboard

Xeon

FB-DIMM DDR2

7200 DC 7300 QC (Tigerton)

192 GB

ATI ES1000 Graphics with 32MB video memory

7300 NB

SBE2 SB

Figure 3.8: Caneland MP Supermicro serverboard, with the 7300 (Clarksboro) chipset for the Xeon 7200/7300 DC/QC MP processor families [7]

© Sima Dezső, ÓE NIK

675

www.tankonyvtar.hu

3.3 The Core 2 based Caneland MP server platform (6)

Figure 3.9: Performance comparison of the Caneland platform with a quad core Xeon (7300 family) vs the Bensley platform with a dual core Xeon 7140M [13] © Sima Dezső, ÓE NIK

676

www.tankonyvtar.hu

3.4 The Nehalem-EX based Boxboro-EX MP server platform (1) 3.4 The Nehalem-EX based Boxboro-EX MP server platform

© Sima Dezső, ÓE NIK

677

www.tankonyvtar.hu

3.4 The Nehalem-EX based Boxboro-EX MP server platform (2) 3/2010 Boxboro-EX

MP platforms

MP cores

3/2010

4/2011

Xeon 7500

Xeon E7-4800

(Nehalem-EX) (Becton) 8C

(Westmere-EX) 10C

45 nm/2300 mtrs/513 mm2 ¼ MB L2/C 24 MB L3 4 QPI links 4 SMI links 2 mem. channels/link 2 DIMMs/mem. channel DDR3 1067 MT/s 1 TB (64x16 GB) LGA1567

32 nm/2600 mtrs/584 mm2 ¼ MB L2/C 30 MB L3 4 QPI links 4 SMI links 2 mem. channels/link 2 DIMMs/mem. channel DDR3 1333 MT/s 1 TB (64x16 GB) LGA1567

3/2010 7500

IOH

(Boxboro) 2 QPI links 32xPCIe 2. Gen. 0.5 GB/s/lane/direction ESI 1GB/s/directon 6/2008 ICH

© Sima Dezső, ÓE NIK

ICH10

Nehalem-EX-based 45 nm 678

Westmere-EX 45 nm

www.tankonyvtar.hu

3.4 The Nehalem-EX based Boxboro-EX MP server platform (3) The 8 core Nehalem-EX (Xeon 7500/Beckton) Xeon 7500 MP server processor [62]

2 cores

© Sima Dezső, ÓE NIK

679

www.tankonyvtar.hu

3.4 The Nehalem-EX based Boxboro-EX MP server platform (4) The 10 core Westmere-EX (Xeon E7-!800) MP server processor[63]

© Sima Dezső, ÓE NIK

680

www.tankonyvtar.hu

3.4 The Nehalem-EX based Boxboro-EX MP server platform (5) Block diagram of the Westmere-EX (E7-8800/4800/2800) processors [64]

E7-8800: for 8 P systems E7-4800: for MP systems E7-2800: for DP systems

© Sima Dezső, ÓE NIK

681

www.tankonyvtar.hu

3.4 The Nehalem-EX based Boxboro-EX MP server platform (6) Main platform features introduced in the 7500 Boxboro IOH (1) Along with their Nehalem-EX based Boxboro platform Intel continued their move to increase system security and manageability by introducing platform features provided else by their continuously enhanced vPro technology for enterprise oriented desktops since 2006 and DP servers since 2007. The platform features introduced in the 7500 IOH are basically the same as described for the Tylersburg-EP DP platform that is based on the 5500 IOH which is akin to the 7500 IOH of the Boxboro-EX platform. They include: a) Intel Management Engine (ME) b) Intel Virtualization Technology for Directed I/O (VT-d2) VT-d2 is an upgraded version of VT-d. c) Intel Trusted Execution Technology (TXT) .

© Sima Dezső, ÓE NIK

682

www.tankonyvtar.hu

3.4 The Nehalem-EX based Boxboro-EX MP server platform (7) Basic system architecture of the Nehalem-EX based Boxboro-EX MP server platform (assuming 1 IOH) Xeon 7500 (Nehalem-EX) (Becton) 8C

SMB SMB SMB

/

Xeon 7-4800 (Westmere-EX) 10C SMB

Nehalem-EX 8C Westmere-EX 10C

Nehalem-EX 8C Westmere-EX 10C

QPI

SMB SMB SMB

SMB

QPI

QPI

QPI

QPI

SMB SMB SMB

SMB Nehalem-EX 8C Westmere-EX 10C

SMB

Nehalem-EX 8C Westmere-EX 10C

QPI

QPI

DDR3-1067

SMB SMB SMB

QPI

2x4 SMI channels

2x4 SMI channels

7500 IOH ESI

ICH10

DDR3-1067

ME

SMI: Serial link between the processor and the SMB SMB: Scalable Memory Buffer Parallel/serial conversion ME: Management Engine

Nehalem-EX based Boxboro-EX MP server platform (for up to 10 C)

© Sima Dezső, ÓE NIK

683

www.tankonyvtar.hu

3.4 The Nehalem-EX based Boxboro-EX MP server platform (8) Wide range of scalability of the 7500/6500 IOH based Boxboro-EX platform [66]

© Sima Dezső, ÓE NIK

684

www.tankonyvtar.hu

3.4 The Nehalem-EX based Boxboro-EX MP server platform (9) Example: Block diagram of a 7500 chipset based Boxboro-EX MP serverboard [67]

ESI

© Sima Dezső, ÓE NIK

685

www.tankonyvtar.hu

3.5 Evolution of MP server platforms (1) 3.5 Evolution of MP server platforms

© Sima Dezső, ÓE NIK

686

www.tankonyvtar.hu

3.5 Evolution of MP server platforms (2) Evolution from the first generation MP servers supporting SC processors to the 90 nm Pentium 4 Prescott MP based Truland MP server platform (supporting up to 2 cores) Xeon MP Xeon 7000 Xeon 7100 / / (Potomac) 1C (Paxville MP) 2x1C (Tulsa) 2C

Xeon MP1 SC

Xeon MP1 SC

Xeon MP1 SC

Pentium 4 Xeon MP 1C/2x1C

Xeon MP1 SC

Pentium 4 Xeon MP 1C/2x1C

Pentium 4 Xeon MP 1C/2x1C FSB

FSB

XMB Preceding NBs

85001/8501 XMB

E.g. HI 1.5

E.g. DDR-200/266

Pentium 4 Xeon MP 1C/2x1C

E.g. DDR-200/266

XMB XMB

HI 1.5 DDR-266/333 DDR2-400

Preceding ICH

ICH5

DDR-266/333 DDR2-400

HI 1.5 266 MB/s

90 nm Pentium 4 Prescott MP based Truland MP server platform (for up to 2 C)

Previous Pentium 4 MP based MP server platform (for single core processors)

© Sima Dezső, ÓE NIK

687

www.tankonyvtar.hu

3.5 Evolution of MP server platforms (3) Evolution from the 90 nm Pentium 4 Prescott MP based Truland MP platform (up to 2 cores) to the Core 2 based Caneland MP platform (up to 6 cores)

Xeon MP Xeon 7000 Xeon 7100 / / (Potomac) 1C (Paxville MP) 2x1C (Tulsa) 2C

Pentium 4 Xeon MP 1C/2x1C

Pentium 4 Xeon MP 1C/2x1C

Pentium 4 Xeon MP 1C/2x1C

Pentium 4 Xeon MP 1C/2x1C

Xeon 7200 Xeon 7300 Xeon 7400 / / (Tigerton DC) 1x2C (Tigerton QC) 2x2C (Dunnington 6C)

Core2 (2C/4C) Penryn (6C)

FSB

XMB 85001/8501 XMB

Core2 (2C/4C) Penryn (6C)

Core2 (2C/4C) Penryn (6C)

Core2 (2C/4C) Penryn (6C)

FSB

XMB

up to 8 DIMMs

7300

XMB ESI

HI 1.5

DDR-266/333 DDR2-400

ICH5

DDR-266/333 DDR2-400

631xESB/ 632xESB

90 nm Pentium 4 Prescott MP based Truland MP server platform (for up to 2 C)

Core 2 based Caneland MP server platform (for up to 6 C) ESI: Enterprise System Interface 4 PCIe lanes, 0.25 GB/s per lane (like the DMI interface, providing 1 GB/s transfer rate in each direction)

HI 1.5 (Hub Interface 1.5) 8 bit wide, 66 MHz clock, QDR, 266 MB/s peak transfer rate 1

© Sima Dezső, ÓE NIK

FBDIMM DDR2-533/667

The E8500 MCH supports an FSB of 667 MT/s and consequently only the SC Xeon MP (Potomac)

688

www.tankonyvtar.hu

3.5 Evolution of MP server platforms (4) Evolution to the Nehalem-EX based Boxboro-EX MP platform (that supports up to 10 cores) (In the basic system architecture we show the single IOH alternative)

Xeon 7500 (Nehalem-EX) (Becton) 8C

SMB SMB SMB

/

Xeon 7-4800 (Westmere-EX) 10C SMB

Nehalem-EX 8C Westmere-EX 10C

Nehalem-EX 8C Westmere-EX 10C

QPI

SMB SMB SMB

SMB

QPI

QPI

QPI

QPI

SMB SMB SMB

SMB Nehalem-EX 8C Westmere-EX 10C

SMB

Nehalem-EX 8C Westmere-EX 10C

QPI

QPI

DDR3-1067

SMB SMB SMB

QPI

2x4 SMI channels

2x4 SMI channels

7500 IOH ESI

ICH10

DDR3-1067

ME

SMI: Serial link between the processor and the SMBs SMB: Scalable Memory Buffer Parallel/serial converter ME: Management Engine

© Sima Dezső, ÓE NIK

Nehalem-EX based Boxboro-EX MP server platform (for up to 10 C)

689

www.tankonyvtar.hu

4. References

© Sima Dezső, ÓE NIK

690

www.tankonyvtar.hu

References (1) [1]: Radhakrisnan S., Sundaram C. and Cheng K., „The Blackford Northbridge Chipset for the Intel 5000”, IEEE Micro, March/April 2007, pp. 22-33 [2]: Next-Generation AMD Opteron Processor with Direct Connect Architecture – 4P Server Comparison, http://www.amd.com/us-en/assets/content_type/DownloadableAssets/4P_ Server_Comparison_PID_41461.pdf [3]: Intel® 5000P/5000V/5000Z Chipset Memory Controller Hub (MCH) – Datasheet, Sept. 2006. http://www.intel.com/design/chipsets/datashts/313071.htm [4]: Intel® E8501 Chipset North Bridge (NB) Datasheet, Mai 2006, http://www.intel.com/design/chipsets/e8501/datashts/309620.htm [5]: Conway P & Hughes B., „The AMD Opteron Northbridge Architecture”, IEEE MICRO, March/April 2007, pp. 10-21 [6]: Intel® 7300 Chipset Memory Controller Hub (MCH) – Datasheet, Sept. 2007, http://www.intel.com/design/chipsets/datashts/313082.htm [7]: Supermicro Motherboards, http://www.supermicro.com/products/motherboard/ [8] Sander B., „AMD Microprocessor Technologies,” 2006, http://www.ewh.ieee.org/r4/chicago/foxvalley/IEEE_AMD_Meeting.ppt [9]: AMD Quad FX Platform with Dual Socket Direct Connect (DSDC) Architecture, http://www.asisupport.com/ts_amd_quad_fx.htm [10]: Asustek motherboards - http://www.asus.com.tw/products.aspx?l1=9&l2=39 http://support.asus.com/download/model_list.aspx?product=5&SLanguage=en-us © Sima Dezső, ÓE NIK

691

www.tankonyvtar.hu

References (2) [11] Kanter, D. „A Preview of Intel's Bensley Platform (Part I),” Real Word Technologies, Aug. 2005, http://www.realworldtech.com/page.cfm?ArticleID=RWT110805135916&p=2 [12] Kanter, D. „A Preview of Intel's Bensley Platform (Part II),” Real Word Technologies, Nov. 2005, http://www.realworldtech.com/page.cfm?ArticleID=RWT112905011743&p=7 [13] Quad-Core Intel® Xeon® Processor 7300 Series Product Brief, Intel, Nov. 2007 http://download.intel.com/products/processor/xeon/7300_prodbrief.pdf [14] „AMD Shows Off More Quad-Core Server Processors Benchmark” X-bit labs, Nov. 2007 http://www.xbitlabs.com/news/cpu/display/20070702235635.html [15] AMD, Nov. 2006 http://www.asisupport.com/ts_amd_quad_fx.htm [16]: Rusu S., “A Dual-Core Multi-Threaded Xeon Processor with 16 MB L3 Cache,” Intel, 2006, http://ewh.ieee.org/r5/denver/sscs/Presentations/2006_04_Rusu.pdf [17]: Goto H., Intel Processors, PCWatch, March 04 2005, http://pc.watch.impress.co.jp/docs/2005/0304/kaigai162.htm [18]: Gilbert J. D., Hunt S., Gunadi D., Srinivas G., “The Tulsa Processor,” Hot Chips 18, 2006, http://www.hotchips.org/archives/hc18/3_Tues/HC18.S9/HC18.S9T1.pdf [19]:Goto H., IDF 2007 Spring, PC Watch, April 26 2007, http://pc.watch.impress.co.jp/docs/2007/0426/hot481.htm © Sima Dezső, ÓE NIK

692

www.tankonyvtar.hu

References (3) [20]: Hruska J., “Details slip on upcoming Intel Dunnington six-core processor,” Ars technica, February 26, 2008, http://arstechnica.com/news.ars/post/20080226-details-slip-onupcoming-intel-dunnington-six-core-processor.html [21]: Goto H,, 32 nm Westmere arrives in 2009-2010, PC Watch, March 26 2008, http://pc.watch.impress.co.jp/docs/2008/0326/kaigai428.htm [22]: Singhal R., “Next Generation Intel Microarchitecture (Nehalem) Family: Architecture Insight and Power Management , IDF Taipeh, Oct. 2008, http://intel.wingateweb.com/taiwan08/published/sessions/TPTS001/FA08%20IDF -Taipei_TPTS001_100.pdf [23]: Smith S. L., “45 nm Product Press Briefing,”, IDF Fall 2007, ftp://download.intel.com/pressroom/kits/events/idffall_2007/BriefingSmith45nm.pdf [24]: Bryant D., “Intel Hitting on All Cylinders,” UBS Conf., Nov. 2007, http://files.shareholder.com/downloads/INTC/0x0x191011/e2b3bcc5-0a37-4d06aa5a-0c46e8a1a76d/UBSConfNov2007Bryant.pdf [25]: Barcelona's Innovative Architecture Is Driven by a New Shared Cache , http://developer.amd.com/documentation/articles/pages/8142007173.aspx [26]: Larger L3 cache in Shanghai, Nov. 13 2008, AMD, http://forums.amd.com/devblog/blogpost.cfm?threadid=103010&catid=271 [27]: Shimpi A. L., “Barcelona Architecture: AMD on the Counterattack,” March 1 2007, Anandtech, http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2939&p=1 © Sima Dezső, ÓE NIK

693

www.tankonyvtar.hu

References (4) [28]: Rivas M., “Roadmap update,”, 2007 Financial Analyst Day, Dec. 2007, AMD, http://download.amd.com/Corporate/MarioRivasDec2007AMDAnalystDay.pdf [29]: Scansen D., “Under the Hood: AMD’s Shanghai marks move to 45 nm node,” EE Times, Nov. 11 2008, http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=212002243 [30]: 2-way Intel Dempsey/Woodcrest CPU Bensley Server Platform, Tyan, http://www.tyan.com/tempest/training/s5370.pdf [31]: Gelsinger P. P., “Intel Architecture Press Briefing,”, 17. March 2008, http://download.intel.com/pressroom/archive/reference/Gelsinger_briefing_0308.pdf [32]: Mueller S., Soper M. E., Sosinsky B., Server Chipsets, Jun 12, 2006, http://www.informit.com/articles/article.aspx?p=481869 [33]: Goto H., IDF, Aug. 26 2005, http://pc.watch.impress.co.jp/docs/2005/0826/kaigai207.htm [34]: TechChannel, http://www.tecchannel.de/_misc/img/detail1000.cfm?pk=342850& fk=432919&id=il-74145482909021379 [35]: Intel quadcore Xeon 5300 review, Nov. 13 2006, Hardware.Info, http://www.hardware.info/en-US/articles/amdnY2ppZGWa/Intel_quadcore_Xeon_5300_review

© Sima Dezső, ÓE NIK

694

www.tankonyvtar.hu

References (5)

•

[36]: Wasson S., Intel's Woodcrest processor previewed, The Bensley server platform debuts, Mai 23, 2006, The Tech Report, http://techreport.com/articles.x/10021/1 [37]: Enderle R., AMD Shanghai “We are back! TGDaily, November 13, 2008, http://www.tgdaily.com/content/view/40176/128/ [38]: Clark J. & Whitehead R., “AMD Shanghai Launch, Anandtech, Nov. 13 2008, http://www.anandtech.com/showdoc.aspx?i=3456 [39]: Chiappetta M., AMD Barcelona Architecture Launch: Native Quad-Core, Hothardware, AMD Shanghai Launch Launch - Database Database Testing Sept. 10, 2007, Testing http://hothardware.com/Articles/AMD_Barcelona_Architecture_Launch_Native_QuadCore/ Date: November 13th, 2008 [40]: Hachman M., “AMD Phenom, Barcelona Chips Hit By Lock-up Bug,”, ExtremeTech, Dec. 5 2007, http://www.extremetech.com/article2/0,2845,2228878,00.asp [41]: AMD Opteron™ Processor for Servers and Workstations, http://amd.com.cn/CHCN/Processors/ProductInformation/0,,30_118_8826_8832,00-1.html [42]: AMD Opteron Processor with Direct Connect Architecture, 2P Server Power Savings Comparison, AMD, http://enterprise.amd.com/downloads/2P_Power_PID_41497.pdf [43]: AMD Opteron Processor with Direct Connect Architecture, 4P Server Power Savings Comparison, AMD, http://enterprise.amd.com/downloads/4P_Power_PID_41498.pdf © Sima Dezső, ÓE NIK

695

www.tankonyvtar.hu

References (6) [44]: AMD Opteron Product Data Sheet, AMD, http://pdfs.icecat.biz/pdf/1868812-2278.pdf [45]: Images, Xtreview, http://xtreview.com/images/K10%20processor%2045nm%20architec%203.jpg [46]: Kanter D., “Inside Barcelona: AMD's Next Generation, Real World Tech., Mai 16 2007, http://www.realworldtech.com/page.cfm?ArticleID=RWT051607033728 [47]: Kanter D,, “AMD's K8L and 4x4 Preview, Real World Tech. June 02 2006, http://www.realworldtech.com/page.cfm?ArticleID=RWT060206035626&p=1 [48]: Kottapali S., Baxter J., “Nehalem-EX CPU Architecture”, Hot Chips 21, 2009, http://www.hotchips.org/archives/hc21/2_mon/HC21.24.100.ServerSystemsI-Epub/ HC21.24.122-Kottapalli-Intel-NHM-EX.pdf [49]: Kahn O., Piazza T., Valentine B., “Technology Insight: Intel next Generation Microarchitecture Codename Sandy Bridge, IDF, San Francisco, Sept. 2010 [50]: Piazza T., Jiang H., “Intel Next Generation Microarchitecture Codename Sandy Bridge: Processor Graphics, IDF, San Francisco, Sept. 2010 [51]: Braun-Protte T., “Intel die neuste Generation”, March 2010, https://sp.ts.fujitsu.com/dmsp/docs/02_fujitsu_intel_server_cpu.pdf [52]: De Gelas J., Westmere-EX: Intel's Flagship Benchmarked, May 19 2011, AnandTech, http://www.anandtech.com/show/4285/westmereex-intels-flagship-benchmarked [53]: Tyan Confidential, Tempest i5000VF S5370, 2-way Intel Dempsey/Woodcrest CPU Bensley Server Platform, http://www.tyan.com/tempest/training/s5370.pdf © Sima Dezső, ÓE NIK

696

www.tankonyvtar.hu

References (7) [54]: Intel 5520 Chipset and Intel 5500 Chipset, Datasheet, March 2009, http://www.intel.com/content/www/us/en/chipsets/5520-5500-chipset-ioh-datasheet.html [55]: Neiger G., Santoni A., Leung F., Rodgers D., Uhlig R., Intel® Virtualization Technology: Hardware support for efficient processor virtualization, Aug. 10 2006, Vol. 10, Issue 3, http://www.intel.com/technology/itj/2006/v10i3/1-hardware/1-abstract.htm [56]: Intel Software Networks: Forums, http://software.intel.com/en-us/forums/showthread.php?t=56802 [57]: Wikipedia: x86 virtualization, 2011, http://en.wikipedia.org/wiki/X86_virtualization#Intel_virtualization_.28VT-x.29 [58]: Sharma D. D., Intel 5520 Chipset: An I/O Hub Chipset for Server, Workstation, and High End Desktop, Hotchips 2009, http://www.hotchips.org/archives/hc21/2_mon/ HC21.24.200.I-O-Epub/HC21.24.230.DasSharma-Intel-5520-Chipset.pdf [59]: Morgan T. P., Intel's future Sandy Bridge Xeons exposed, May 30 2011, The Register, http://www.theregister.co.uk/2011/05/30/intel_sandy_bridge_xeon_platforms/page2.html [60]: Gilbert J. D., Hunt S. H., Gunadi D., Srinivas G., The Tulsa Processor: A Dual Core Large Shared-Cache Intel Xeon Processor 7000 Sequence for the MP Server Market Segment, Aug 21 2006, http://www.hotchips.org/archives/hc18/3_Tues/HC18.S9/HC18.S9T1.pdf [61]: Intel Server Board Set SE8500HW4, Technical Product Specification, Revision 1.0, May 2005, ftp://download.intel.com/support/motherboards/server/sb/se8500hw4_board _set_tpsr10.pdf [62]: Mitchell D., Intel Nehalem-EX review, PCPro, http://www.pcpro.co.uk/reviews/processors/357709/intel-nehalem-ex © Sima Dezső, ÓE NIK

697

www.tankonyvtar.hu

References (8) [63]: Nagaraj D., Kottapalli S.: Westmere-EX: A 20 thread server CPU, Hot Chips 2010 http://www.hotchips.org/uploads/archive22/HC22.24.610-Nagara-Intel-6-Westmere-EX.pdf [64]: Intel Xeon Processor E7-8800/4800/2800 Product Families, Datasheet Vol. 1 of 2, April 2011, http://www.intel.com/Assets/PDF/datasheet/325119.pdf [65]: Supermicro P4QH6 / P4QH8 User’s Manual, 2002, http://www.supermicro.com/manuals/motherboard/GC-HE/MNL-0665.pdf [66]: Intel Xeon Processor 7500/6500 Series, Public Gold Presentation, March 30 2010, http://cache-www.intel.com/cd/00/00/44/64/446456_446456.pdf [67]: Supermicro X8QB6-F / X8QBE-F User’s Manual, 2010, http://files.siliconmechanics.com/Documentation/Rackform/iServ/R413/Mainboard/MNL -X8QB-E-6-F.pdf [68]: Gavrichenkov I.: Workstation Processors Duel: AMD Opteron against Intel Xeon, Xbit Labs, Dec. 21 2005, http://www.xbitlabs.com/articles/cpu/display/opteron-xeon-workstation_5.html

© Sima Dezső, ÓE NIK

698

www.tankonyvtar.hu