Van valakinek headless server?
Az érdekel, hogy a BIOS-ban ki kell e kapcsolni a "halt on error"-t, és ha igen, akkor ez nem e okoz olyan gondot, hogy az ecc hard error-okat is ignorálja a rendszer?
Esetleg ha van, akkor az ecc-t row hammer-el lehet tesztelni egy erre a célra telepített oprendszerrel (kis eséllyel, de előfordulhat, hogy kárt tesz az oprendszerben), hogy tényleg működik e, vagy memtest86+-al, ami az erre készült ecc teszt api-t használja. Utóbbival szerintem nem lehet tesztelni ezt a feature-t, legalábbis nem hiszem, hogy halt lenne a dolog vége, valszeg az api elkapja az ő szintjén a hibaüzenetet.
A másik érdekes dolog, hogy vajon megoldható e a wake on demand Apple termékek használata nélkül?
■ Esetleg ha van, akkor az ecc-t row hammer-el lehet tesztelni egy erre a célra telepített oprendszerrel (kis eséllyel, de előfordulhat, hogy kárt tesz az oprendszerben), hogy tényleg működik e, vagy memtest86+-al, ami az erre készült ecc teszt api-t használja. Utóbbival szerintem nem lehet tesztelni ezt a feature-t, legalábbis nem hiszem, hogy halt lenne a dolog vége, valszeg az api elkapja az ő szintjén a hibaüzenetet.
A másik érdekes dolog, hogy vajon megoldható e a wake on demand Apple termékek használata nélkül?
Azt írják néhány helyen, hogy
A wake on demand-re egyelőre
Valszeg bele kell ágyazni az alkalmazásaim kódjába valamilyen állapot jelzést, hogy tudja a szerver mikor busy egy-egy app, és mikor lehet altatni.
A technikai megvalósítása a felébresztésnek is érdekes, mert mehet wake on LAN-al is, de azt hiszem talán IPMI-n keresztül is működhet. Az utóbbit talán jobb nem feszegetni, mert amennyire én tudom jelszó kell hozzá, ahhoz meg menteni kell a jelszót a sleep proxy-ra, ami onnantól lenyúlható. Szóval a WOL talán a jobb opció erre a célra és az IPMI-t inkább csak rendszer telepítésre, BIOS beállítások debuggolására, ilyesmire érdemes használni.
A shell script érdekes kérdés, szeretném nodejs alapon megoldani, ha lehetséges. Nem tudom az open WRT mennyire támogatja az ilyesmit. Ha nem, akkor muszáj lesz proxy irányba elmennem. Igazából mindkettő plusz költség a részemről, olyan +25k-val használok, ami nagyon drágává teszi ezt a feature-t. A saját router vásárlása jobban megéri hosszú távon. A mostani UPC-s box jó, de ha költözök vagy szolgáltatót váltok, akkor ki tudja milyen szemetet hoznak erre a célra.
Itt van nodejs cross compile open WRT-re, szóval elvileg lehetséges: https://github.com/netbeast/docs
A proxy irányába nem érdemes elmenni szerintem, mert úgy elfelezem a sávszélességet. Legalábbis a routeren kétszer kell átmenni ugyanannak a csomagnak. Egyszer, amikor a proxy-nak küldi a kliens, egyszer meg, amikor a proxy továbbítja a szervernek. Szóval ha csak lehet a router-en kell ezt a wake on demand részt megoldani.
Találtam valami használhatót, ami kiindulási alapnak esetleg jó lehet, de úgy sejtem, hogy ennél azért több fog kelleni, hogy ne csak HTTP-vel működjön. http://gaddgets.blogspot.hu/2007/02/auto-wol-on-dd-wrt-on-linksys-wrt54gl.html
mi a cél?
Szokásodhoz híven elég extra, rendhagyó cuccot akarsz építeni, nekem az is új, hogy egy szerver miért lenne sleep-elve, de nagyon érdekes téma, ha lesz eredmény, kérlek oszd meg azt is. :)
Csak minimalizálni szeretném
Ha odáig jutok, hogy elkészül, akkor majd bloggolok róla egy sorozatot.
Belelóg a kezed a bilibe
- El akarsz költeni egy rakást pénzt, de az áramszámlán spórolnál
- Nagy teljesítményt szeretnél (8000 passmark, 4 mag-8 szál), de legyen passzív (megoldható egy pár kilós hűtőbordával)
- A BIOS-t szeretnéd állandóan állítgatni (Minek? Mindig újra akarod indítgatni?)
- ECC RAM-ot akarsz beletenni, azaz szerver alaplap és valószínűleg processzor is kell hozzá, amit passzív hűtéssel nem igazán fogsz találni
Nekem erős a gyanúm, hogy fogalmad sincs a leírt dolgokról, amit tetézel azzal a végén, hogy valószínűleg routerrel oldod meg a problémák egy részét, ami egy teljesen más feladatra kitalált eszköz.Persze nem tartom kizártnak, hogy megvalósítható a cucc, csak ránézésre nem valószínű, hogy összejön.
Fantasztikusak ezek a
Gyakorlatilag az összes L-es Xeon kihűthető passzívan, pl: Intel Xeon E3-1230L v3; 7207 pont, <15W idle, 25W TDP. Melléje meg mondjuk egy Asus P9D jellegű vagy egy Supermicro X10SLM+-F lap. Ritkán, de előfordulnak nem szerver lapok is, amik támogatják az ECC-t, de én nem feltétlen húzok feléjük. Inkább az IPMI, ami húzósabb ezen a téren, de arról majd akkor döntök, hogy lesz e, ha eldőlt, hogy milyen CPU lesz. Most várok az AMD Naples-re, meg közben nézegetem aprón a Xeonokat. Már a Ryzen is jót tett a piacnak szerintem, de ha kijön a Naples, akkor aprón komolyan megrogyhatnak a használt Xeon árak. Aztán vagy egyiket, vagy másikat veszem, attól függ a Naples milyen árban lesz.
Meleg
Ha a Xeon, amit kinéztél, 25W-os TDP-jű, az azt jelenti, hogy a 15-ösbe már nem fért bele, azaz 15 Wattnyi hőenergiát biztosan le fog adni.
Jó lenne, de magyar aprón
Kína
Közben letettem az IPMI-ről,
Router téren utánajártam, nagyjából 40k egy hasonló tudású Linksys WRT router, mint ami most van, de lehet dobom az AC wifi-t és inkább az n-es jelerősségére megyek rá, meg olcsósítok. Úgy talán kijön 30-ból is egy normális router. Igazából én nem használok wifi-t, max ha böngészek tableten, és szinte biztos, hogy sosem lesz szükségem 100Mbit-nél nagyobb sávszélességre wifi-n. A gigabites forgalmat meg bármi van, mindig kábelen fogom vinni.
A szoftveres részének is jobban utánajártam, azt mondják lehetséges elkapni TCP packet-eket router-en TCP dump-al. Elvileg a node net moduljával is megoldható ugyanaz százszor egyszerűbben, de majd csak ha látom, akkor fog eldőlni, hogy tényleg megy e. Ami persze még mindig nem tiszta, hogy mi történik, amikor a router kap egy üzenetet a klienstől, hogy továbbítsa a szerver felé, de a szerver alszik, úgyhogy nem tudja fogadni. Majd egy kicsit jobban beleások az OpenWRT lelkivilágába emiatt, hátha találok valami infot erről. Ha így van, akkor talán nem is kell azzal komplikálni a szoftveres részét, hogy a router számon tartja a szerver állapotát, hanem csak szimplán megpróbálja felébreszteni, ha az nem fogadja a kéréseket. Igazából ez azon múlik, hogy vár e ilyenkor timeout-ig a kliens, meg hogy újra próbálkozik e a router egy darabig, vagy pontosan mi történik a háttérben. Egyelőre ebbe még nem látok bele.
Közben még tovább bonyolódott