Egy korszak vége: Sun Fire E25K

Sun Solaris adminisztrátorként az egyik legnagyobb hardware közeli élmény a Sun Fire E25K okozta. Mire én megismerkedtem vele, addigra is már a SUN hivatalosan is a Fujitsu-val karöltve fejlesztett Sun SPARC Enterprise M9000-et ajánlotta helyette. Ettől függetlenül én most szeretnék egy rövid és nem teljes átfogó képet alkotni erről a platformról, ami a maga idejében elég nagy dobásnak számított.

Hardware

Megjelenés
Ahogy az a képről is jól látszik ez egy komoly kiépítés; saját, SUN rack-ben forgalmazza, gyakorlatilag majdnem készre szerelve. Ezzel próbálta a SUN a profi kategóriában is előnyben részesíteni az egységes, és egyszerű rendszereket.

Ezen felül szubjektív okokból egy tiszteletet és komolyságot sugárzó gép, nem hiába szeretnek vele, vagy mellette parádézni a felsőbb vezetésnél.

Méretek:

Magasság: 191 cm
Szélesség: 85 cm
Mélység: 166cm

Súly: 1122 kg (teljes kiépítésben)

Erő és skálázhatóság

Természetesen, mint minden ilyen nagy és komoly rendszernek, kell hogy legyen egy vezérlő eleme, ami felelős a hardware elemekért, és azok felhasználásáért, csoportosításáért. Ezt itt a System Controller (SC) testesíti meg. Nyilvánvalóan minden alkatrész redundánsnak kell, hogy legyen, ezért mindjárt két SC található, melyek Active-Standby rendszer szerint funkcionálnak. Ha a jobban ismert BLADE rendszerekhez akarnám hasonlítani akkor ez egy BLACE Center frame.

Ezek után jöhetnek a System Board-ok (SB), maguk a BLADE-k. Ezek a vékony kártyák amiket sorba be tudunk csúsztatni a frame-be. Minden egyes SB egy teljes értékű „gépet” testesít meg. Van neki saját CPU, Memória-ja. és megfelelő csatolói.

Egy SB egyesével a következő kiépítésben érhető el:

CPU Architecture: 1.5GHz UltraSPARC IV+ and/or 1.05GHz/1.2GHz/1.35GHz UltraSPARC IV and/or 1.2GHz UltraSPARC III processors; Superscalar SPARC V9, ECC protected
CPU Cache per processor: Level 1: 64 KB data and 64 KB instruction per pipeline Level 2: 2 MB on-chip Level 3: 32 MB external
Memory: Maximum 64GB per Board

(SUN Uniboard Matrix link)

Összesen 18 SB-al bővíthető a E25K. Ezáltal a következő maximális konstrukció alakítható ki:

Processor: Maximum 72 processors, 144 simultaneous threade.
Memory: Maximum 1.15 TB per domain
I/O: Up to 72 hot swappable PCI-X I/O slots, 54 slots are 90MHz, 18 slots are 33MHz. supports 10/100 BaseT Ethernet, Gigabit Ethernet, UltraSCSI (LVD and HVD), ATM, FC-AL, HSI, and SCI

Tároló kapacitás

Az E25K alapvetően semmilyen adat tárolási funkcióval nem rendelkezik, csupán a I/O portok vannak kialakítva hozzá. Tehát ha valaki egy ilyenbe ruház annak szükséges gondoskodnia valamilyen storage-ről még pluszban. Ez szokta többnyire a másik „szekrényt” reprezentálni az E25K mellett (ami szintén egy „szekrény”).

250+ TB storage kezelését teszi lehetővé a kiépítés. Ezt pedig mind Fibre Channel (1GB és 2GB) vagy UltraSCSI csatolóval tehtjük meg.
Az fontos, hogy bootoláshoz viszont a következő tároló megoldásokat ajánlja a SUN:
Sun StorageTek 3120, Sun StorageTek S1, Sun StorageTek D240, Sun StorageTek 3510, Sun StorageTek 3310, Sun StorageTek 9990

A teljes elméleti I/O sávszélesség 35.8 GB/s-ig tornázható fel.

Rendszer a rendszerben – Domain

Tehát már ismerjük a vasat, nézzük hogyan tudjuk kezelni. Ott van nekünk maximális kiépítésben 18 System Board (SB), amikre más esetben mindre tudnánk egy Solaris-t installálni. Mostani esetben viszont lehetőségünk van egy logikai egységet képezni, ami alá tetszés szerint csoportosíthatunk hardware erőforrásokat.

Ez a logikai egység, kötet lesz a DOMAIN. Egy domain tehát egy olyan „virtuális” gép, ami reprezentál a külső világ felé egyetlen hardware eszközt, de alatta tetszés szerinti SB és ezáltal resource kezelhető. A System Controller (SC) feladat ezen logikai egységek kezelése, felügyelete, és vezérlése.

A SC amúgy egy Solaris OS-t tartalmazó mini gép, amin vagy egy System Management Service (SMS) van telepítve. Ez az egész E25K vezérlésének a lelke gyakorlatilag. (SUN SMS link)

A SC-n kiadva a showplatform parancsot a következő hasznos információkhoz juthatunk:

# showplatform

A fenti képen jól látszik, hogy A-tól Q-ig van lehetőségünk DOMAIN-eket kezelni. Az itteni esetben pedig két domain létezik. Lentebb pedig jól látszik, hogy a Domain Status alatt Running Solaris szerepel. Tehát bennük aktívan fut Solairs OS.

Amennyiben a nem DOMAIN-ek szemszögéből közelítünk, hanem SB felől akkor a showboards parancsot adjuk ki az SC-n.

# showboards

Fentebbi képen jól látszik, hogy itt már a SB-k és I/O modulok szemszögéből láthatjuk a 25K-t. A Type of Board esetében láthatjuk milyen típusú kártyával van dolgunk. Ha Empty Slot szerepel, értelemszerűen az a bővítőhely üres. A Board Status-a aktív és PWR mező alatt látjuk be is van kapcsolva. Az egész végén pedig láthatjuk melyik DOMAIN-hez tartozik. Itt jól kitűnik, hogy egy DOMAIN-hez több SB is hozzá lehet rendelve, de egy SB csak egy DOMAIN-hez tartozhat.

Hardver Diagnosztika

Egy SB-nek is lehet millió kis kütyüje, aminek egyetlen meghibásodása is kihathat az egész kártyára. Egy parancs segítségével lekérhetjük az összes Component Health Status (CHS) információt:

# showchs

Mivel ez egy végtelen futó listát eredményez, rászürhetünk a NEM „OK” üzenetekre, illetve lehetőségünk van, a -c kapcsoló után argumentumként megadni minek a státuszára vagyunk kíváncsiak.

# showchs -c SB5

Illetve részletes információkhoz is juthatunk, ha a -v kapcsolót is használjuk. Ilyenkor olyan információkhoz is hozzájuthatunk, hogy esetleg régebben, volt e rossz valami.

# showchs -v -c SB5

DOMAIN és Online resource kezelés

Tehát van már DOMAIN-ünk, amihez hozzárendeltünk sok-sok hardware erőforrást, System Board-ot (SB). Persze felvetődik a kérdés mi történik akkor, ha az egyik SB feladja a harcot, vagy mi döntenénk úgy, hogy eltávolítanánk a DOMAIN-ből. Jó hír hogy erőforrások mozgatása online megtehető (persze egy kivétel van, ha a SB memóriájában kernel specifikus adatok tárolódnak, akkor azt nem lehet evakuálni).

SB hozzáadása
Pontosabb leírás inkább, hogy egy DOMAIN-hez hozzárendelünk egy még szabad SB-t. A -d kapcsoló után kell megadni melyik DOMAIN-hez akarjuk hozzárendelni, majd -r után azt, hogy hányszor próbálja meg, végül pedig -t után, hogy mennyi időt adunk neki erre az akcióhoz másodpercben.

# addboard -d A -r 2 -t 600 SB2

SB törlése
Pontosabb leírás inkább, hogy megszüntetjük az SB valamely DOMAIN-hez való hozzárendelését. Ezzel szabaddá téve.A parancs után a -r követően azt kell megadn, hogy hányszor próbálja meg, végül pedig -t után, hogy mennyi időt adunk neki erre az akcióhoz másodpercben.

# deleteboard -r 2 -t 900 SB2

SB hozzárendelése egyik DOMAIN-től egy másik DOMAIN-hoz

Lehetőségünk van, egy paranccsal megoldani egy deleteboard és addboard metódust. A -d kapcsoló után kell megadni melyik DOMAIN-hez akarjuk hozzárendelni, majd -r után azt, hogy hányszor próbálja meg, végül pedig -t után, hogy mennyi időt adunk neki erre az akcióhoz másodpercben.

Domain leállítása

Akkor az már világos, hogy a DOMAIN az gyakorlatilag egy logikai SPARC masina. Akkor vigyük le OK PROMPT-ba. Adjuk ki a következő parancsot a DOMAIN-en belül, és ne a System Controlleren :)

# init 5

Nézzük most mi látszik a System Controller felől:
# showplatform

Jól látszik, hogy most a Domain Status az megváltozott. Ekkor a domain továbbra is működő. Csupán a benne lévő OS kapcsolt le.

Ha a DOMAIN-t mint logikai gépet ki akarjuk kapcsolni, akkor el kell fordítanunk a logikai kulcsát a gépnek, akár csak egy fizikai esetében.

# setkeyswitch -d A off

Jól látszik, ahogy a logikai gépünk, a DOMAIN leáll, és ezáltal az eddig általa fogott eszközök is kikapcsolnak.

Domain elindítása

# setkeyswitch -d A on

Elfordítjuk az A DOMAIN virtuális kulcsát ON-ra. Ezzel szépen bekapcsolja a szükséges hardware elemeket, és elindul a rendszer. Pontosabban még csak a POST (Power-On Self Test).

# showplatform

A logikai rendszer, a DOMAIN is fogja és végigteszteli szépen a hozzá kapcsolt hardware elemeket.

A POST szintjét a /etc/opt/SUNWSMS/SMS1.6/config/A/.postrc file-ban lehet meghatározni (persze itt az A domain postját tudjuk állítani).

Egy magasra emelet POST szint és több System Board esetében ez akár több óra is lehet. A mi mérésünk szerintm 10 SB 96-os POST level-el 3.5 óra volt.

Túlélőparancsok E25K-hoz

SMS userek listázása
# smsconfig –l platform

Console kapcsolat System Controllerről egy DOMAIN-hez (-d után a DOMAIN)
# console –d A

Console kapcsolatból kilépés
~.

Break signal küldése, ami OK PROMPT-ba visz
~#

System Board Firmware flashelése
# flashupdate -f $SMSOPT/hostobjs/sgcpu.flash SB3

Domain resetelése (-d után a DOMAIN)
# reset –d A

Mely folyamatok tartoznak az SMS-hez?
13 ( dsmd,efe,esmd,fomd,frad,hwad,kmd,mand,mld,osd,pcd,ssd,tmd)

Mely agent-ek tartoznak az SMS-hez?
2 ( dca , dxs)

Hol találhatóak a fontosabb log file-k?
Platform logok:
/var/opt/SUNWSMS/adm/platform/messages
Domain logok:
/var/opt/SUNWSMS/adm/domain_id/messages
Domain console:
/var/opt/SUNWSMS/adm/domain_id/console

Hogyan nevezhető el egy DOMAIN?
# addtag –d A testname

Hogyan törölhető egy DOMAIN neve?
# deletetag –d A testname

SMS és CFGADM összehasonlító táblázat

Amit nagyba tud az SMS azt kicsibe tudja a sima cfgadm is kicsiben. Erről íme egy rövid összehasonlító táblázat.

DR Operation	High-End System SMS Command	cfgadm Command(s)
Display board state, type, and condition	rcfgadm -la -d domain_id	cfgadm -la
Display info about board slots and components	None	prtdiag
Display high-end system board status	See showboards	cfgadm -a -v -s "select=class(sbd)"
Display midrange system board status	n/a	cfgadm -a -v
Display boards available to a domain	See showplatform	cfgadm -l
Display status of system boards in a particular domain	See showdevices	cfgadm -a -v -s "select=class(sbd)"
Display class of a system or I/O board	rcfgadm -d domain_id -s "cols=ap_id:class"	cfgadm -s "cols=ap_id:class"
To display classes associated with attachment points	rcfgadm -a -d domain_id -s "cols=ap_id:class"	cfgadm -a -s "cols=ap_id:class"
Test a system board	rcfgadm -d domain_id -t ap_id	cfgadm -t ap_id
Test an I/O board	n/a	See To Test an I/O Board (Midrange Only)
Add a board to a domain	addboard -d domain_id board_id	cfgadm -v -c configure board_id – or – cfgadm -v -c configure ap_id
Delete a board from a domain	deleteboard board_id	cfgadm -v -c disconnect board_id – or – cfgadm -v -c disconnect ap_id
Move a board from one domain to another	See Move a Board	N/A
Configure a CPU on a system board	rcfgadm -c configure -d domain_id SBx::cpuy	cfgadm -c configure SBx::cpuy
Configure memory on a system board	rcfgadm -c configure -d domain_id SBx::memory	cfgadm -c configure SBx::memory
Unconfigure all CPUs and memory on a system board	rcfgadm -c unconfigure -d domain_id SBx	cfgadm -c unconfigure SBx
Track memory unconfiguration	rcfgadm -a -d domain_id -s "select=type (memory), cols=ap_id:o_state:info"	cfgadm -a -s "select=type (memory), cols=ap_id:o_state:info"
Unconfigure a system board with permanent memory	rcfgadm -c unconfigure -d domain_id -y SBO	cfgadm -c unconfigure -y SBO
Disconnect a system board or I/O board	rcfgadm -c disconnect -d domain_id board_id	cfgadm -c disconnect board_id
Connect PCI slot on I/O board	rcfgadm -c connect -d domain_id pci_ap_id	cfgadm -c connect pci_ap_id
Configure PCI slot on I/O board	rcfgadm -c configure -d domain_id pci_ap_id	cfgadm -c configure pci_ap_id
Disconnect PCI slot on I/O board	rcfgadm -c disconnect -d domain_id pci_ap_id	cfgadm -c disconnect pci_ap_id
Unconfigure PCI slot on I/O board	rcfgadm -c unconfigure -d domain_id pci_ap_id	cfgadm -c unconfigure pci_ap_id

Végszó

Sajnos a trend azt mutatja, az ilyen nagy gépeknek leáldozóba van a soruk. A válság virtualizáció felé int, és kicsi, olcsón adminisztrálható osztott rendszereké a jövő.

A mi E25K-nk is így tűnt el a semmiben. Ami egyszer robosztus, hivalkodó és csillogó volt, az most drága, pocsékló és felesleges.

Nekem ettől függetlenül nagy élmény marad a 25K és a vele töltött adminisztráció. Itt elérhető egy rövid datasheet az eszközről, a SUN marketingesek tollából.