Uptime Project

Lehet, hogy ez pontosabban mér, de nekem valahogy a Netcraft szimpibb... :)

Tudja valaki hogy a Netcraft honnan szedi az uptime-ot?

De ha Open Source a kliens akkor be lehet csapni nem??

tcp fejlécből

Miert jo az, hogy bugyuta uptimeversenges miatt 2 eve nem frissited a kernelt/rendszert?

persze :D

bocs, kb 2perc átírni a kernelt, hogy az uptimot működés közben tudd változtatni. ráadásul hibernálásor sem resetelődik az uptime :S

Az új épületben OpenBSD lesz a tűzfal ahol be fogjuk kapcsolni a scrub opciót ami randomizálja a tcp timestamp és sequence számokat úgyhogy ott "alapból" nem fog működni.

Inkább azt mondd hova mész egyetemre?

Megvan már az eredmény?

Azért érdekes, az első 10-ben 8 FreeBSD 1 NetBSD 1 Solaris.

Bocs, de ez uptime-nak semmi koze semelyik bsd-hez csak kizarolag az uptime-hoz...

Masreszt kevered a webszolgaltatas es a webszerver mint szoftver illetve hardver kifejezeseket. Ahhoz hogy akar 5 vagy 6 kilences rendelkezesreallasi idovel birjon a webszolgaltatasod megfelelo redundancia eseten NEM szukseges kobmeteres uptime... Sosem ertettem az ilyen jellego az en .. nagyobb tipusu ovis vitakat... Pl sok (bsd-tol 1000x nagyobb hirnevo OS mint pl AIX) sem bir ilyen kepessegekkel. Noha ha hiszed ha nem 4-5 kilences rendelkezesre allast siman tudunk vele biztositani.... Sot meg csak rosszul sem erezzuk ettol magunkat hiaba nagyobb a te @-od ;o))

Legyel ra buszke ;o))) Nekunk fontosabb hogy mindig a legrissebb firmware legyen a drive-jainkon illetve vezerlokartyainkon, fent legyenek a stabilitast novelo patchek es sose omoljon ossze a tobb szaz milliot ero adatbazisszevereink ;o)) Sot mondjuk egy 3 system landscape tipusu SAP rendszeren mint tudod idorol idore migralni es updatelni kell amint modositjak a fejlesztoi adatbazist es az bevalt a QA systemen ;o)) Csak tudod tobb geppel ez nem gaz... ;o)))) Nem kell magas uptime csak backup masina...

Bocs a kifakadasert de mar marha unom ezt az ertelmetlen es egyoldalu uptime frocsogest...

szerintem össz-vissz 280 regisztrált hoszt-ból még nem érdemes ilyen jellegű következtetéseket levonni...

Bocs te kevered a dolgokat: Az hogy vmi elerheto kell hogy legyen nem az egyetlen csoro vasnak kell ejjel-nappal mukodnie... csak a szolgaltatasnak kell elerhetonek lennie... Kiveve ha a szolgaltatas az az adott vas szeriaszama ;o)) Ket ev utan nincs az a rendszer amire ne ferne ra frissites....

Miert kell frissiteni? Az hogy egy hiba nem jott elo attol meg idovel elojohet (Nem egy peldat lattam ra... es az hogy egy hiba letezik de meg nem hasznaltak ki lasd security attol meg hiba). (megfelelo terheles kerdese, vagy a frissitett db koveteli meg a megfelelo upgrade szintet) (Vagy pl a backup rendszer szoftvere kovetel meg uj szintet... stb pl tivoli)) Masreszt pl AIX eseten bizonyos hibajavitasok megfelelo firmware revizokat igenyelnek az SSA vezerlokon, merevlemezeken. Pl egy jol mukodo outsourcing company eseten a szerzodes leirja hogy egyreszt fel evente fel kell tennunk a biztonsagi frissiteseket masreszt a szervererek valaszideje 1 sec alatt kell hogy legyen. Azt nem mondtam hogy egybol fejetlenul feltenni, erre vannak a QA (quality assurance) rendszerek hogy bebizonyosodjon jo-e a javitas... (ha load balancingos szervereitek vannak akkor az evi ecceri leallas siman belefer ha pl a masik 2-3 szerver elerheto marad, de ezt mar leirtam) Erre kulon team figyel aki teszteli a javitasokat hogy a 600-700 (mindegyik tobb gepbol allo (3-20) rendszeren ha frissitesre kerul a sor mar ne legyen fennakadas. Es spec az AIX-ra kijovo javitasok, javitasok tehat a celjuk nem ujabb fícsörök hanem teljesítményjavítás illetve kritikus hibák kiküszöbölése. Pl. Lattam mar olyan javítást amin tudott volt hogy a portmapper ki fog bizonyos szervereken fagyni de fel kellett tenni mert erősen javította az nfs teljesítményt. De volt ra megoldas meg lehetett csinalni... Elore kesz doksikbol dolgozol ami taglaljaa lehetseges hibak orvoslasat. De kb 10-bol 5 szerveren jott csak elo a hiba amire mar ott volt a megoldas is...

Nem akarom az esetleges sap frisites utan elojovi hibak es a sapnote-on javasolt frissitesek osszefuggeseit taglalni... Oranken x millio euros termelesi kiesest majd magyarazz meg a customernek amikor a sap firssitese (ugyanis egy db-t allandoan fejlesztenek, allandoan uj funkciokat implementalnak hetrol hetre...) utan nem megy az uj feat. de az oprendszered okes ;o)) Legy ra buszke ;o)) tedd vitrinbe ;o))) simogasd, kenegesd a bsd-det ;o)) Es legy buszke hogy fent vagy a nemtom mijen tablazaton... Aztan amasnap a customer megkoszoni a faradozasaidat... es egy jo kis per kereteben elvonul...

Hol dolgozom? Sajna nem arulhatom el ;o( de maradjunk anniyban hogy 10 folott van a tobb teras adatbazisaink szama es kb 1000 cegnek dolgozunk amik kulon kulon nagyobb infrastukturat hasznalnak mint egy korhaz... es hidd el megbizhatoak vagyunk mint europa egyik jonevu cege.

Nem hinnem hogy verziobuzi lennek... (bar a sajat pc-men igen, de ennek teszt okai vannak) ezt sosem mondtam hogy mindig a legfrissebbre... csak az osregit kiprobaltan frissebbre... Mondjuk ezt nem irtam de igy gondoltam...

Nem akarom a bsd-rol,a hup-rol es az uptime-rol szolo cikkeidet emliteni az elmult idokben mert unom... es ertelmetlen hozongesnek tartom... Egy szerver uptime-jatol nem lesz jobb semmi... Sajna senkit nem lattam aki megprobalt volna ez ellen vedekezni... es ha ennyi uptime-rol szolo nyalveres egyetlen ellenvelemenye neked frocsoges akkor nemtom hogy rossz uton jarok-e de szerintem nem...

Mindenesetre nagyon jót mulattam ezen a thread -on... :)

ott volt a cikk vegen is, h mire jo ez az egesz. semmire. ezek utan nekiallni kotozkodni...

"Oranken x millio euros termelesi kiesest majd magyarazz meg a customernek"

Szerintem trey el fog gondolkozni a tanácsaidon, ha a HUP-szerver(ek) nemfrissítése óránként x millio eurós termelési kiesést fog okozni, nemde? ;-D

> A verziobuzikat nem szeretem

teccik ez a szó ;-)

2 evig adtam aix-et SAP ala 2 db SP-n, de nem emlekszem, hogy allandoan frissitettem volna. Igaz, a vasat cserelgettuk bennuk rendesen es ilyenkor csak frissultek a dolgok, de nem nagyon remlik, hogy barmilyen aix patch miatt kulon megalltunk volna. (Nem outsourcing-ben ment a dolog, nem volt szerzodes, hogy 1-2 havonta, ha kell, ha nem,jo penzert karbantartas ......)

Kulonben meg erdekes lehet az uptime, en ugy latom az 5-10-... ev koruli gepeknel a legfontosabb az uptime. Ma mukodik, talan holnap is, de megallitva nem biztos, hogy meg egyszer elindul. Nincs az a patch, amiert egy >10 eves gepet megallitanek :)

Képzeld el mennyivel bonyolultabb BSD-n frissíteni, mint mondjuk Debianon. Ezért nem is csinálja senki->magasak az uptime-ok :)

ja tényleg ;-)

Tulajdonképpen jogos. Bár ha konkrét gép fele megy a csomag akkor végülis elég jól levédhetö. Csak felesleges.

Egyébként télleg kismillió ilyen van még. uptime-project.net pl.

Itthonra jól L van :) Enni nem kér és home(less) gép uptimeját küldözgeti :) Serverre böven elég nekem ha netcraft csinálja. ( már ha csinálja :) ) + progit nem ér meg. Gondolom tray is csak azé rakta fel hogy tudja miről is ír.

Én nem vallom magam uptime buzinak, de az is igaz, hogy 1-2 éves uptime után már nem szívesen kapcsolom le a gépet, vagy rebbotolok. De ez azért nem gátol meg abban hogy ha valami télleg fontos frissítés van azt fel tegyem.

( Azért nem fogok restartolni, mert az új kernel menuconfigjának más a háttrészíne... )

NetBSD-nel es OpenBSD-nel egyebkent sem nyerheto ki az uptime informacio a csomagjaibol... ;)

Hmm, jó és szép dolog ez az uptime téma, én is szeretem, ha nagy... ;)

De nemhiszem, hogy egy ilyenért hajlandó lennék +1 programot futtatni a háttérben akármelyik szeveren is csak azért, hogy fenn legyek egy ilyen listán. Hogy miért? Mert ez is egy újabb biztonsági problémát jelenthet...

Lehet az OpenBSD portsban ezért nincs benne? ;D

http://uptimes.hostingwired.com/

Ez is egy ugyan ilyen project.