A restart is pending on ... szakaggyá' meg

telnet_failed

Voltam olyan botor, hogy azt hittem, hogy egy Windows Server operációs rendszerhez tetszőleges időpontban hozzáadhatok egy olyan bonyolult (értsd: egy darab bináris) feature-t, mint egy telnet kliens (telnet.exe). Ez a "bonyolult" feature hozzáadás gyakorlatilag annyi tesz, hogy a telnet.exe valahogy bekerül a windows\system32 könyvtárba. Azt hiszed ez olyan egyszerű? Ha a rendszer újraindításra vár, mondjuk egy Patch Kedd utáni patchelésből kifolyólag, addig nem kerül be az egy szem bináris a megfelelő helyre, amíg az ember nem indítja újra a gépet.

Aki üzemeltet éles rendszert, az tudja, hogy nem akkor indítjuk újra a gépet, amikor akarjuk, hanem amikor a karbantartási ablakra rábólint az ügyfél, a szolgáltatásmenedzser vagy az atyaúristen. Most az tényleg komoly, hogy egy egyszerű .exe addig nem kerülhet a rendszerbe, amíg valaki újra nem indítja a gépet? A válasz: komoly. Ami szomorú valahol.

( gelei v | 2017. 09. 21., cs – 10:54 )

Gondolom ennek az az oka, hogy a patch-ek telepítése az újraindításkor fejeződik be, így nem tudhatod biztosra a rendszer állapotát. Ez a telnet kliensnél persze kevésbé releváns, komplexebb feature-ök telepítésénél viszont már érdekes lehet.

Lehetett volna a telnet.exe-re exceptiont tenni? Biztosan. Meg lehetett volna oldani jobban az egész frissítési mechanizmust? Valószínűleg. Meg lehetett volna oldani jobban úgy, hogy ne legyen gond a visszafelé kompatibilitással? Nem tudom.

Én inkább azt a szokásos kérdésemet tenném fel, hogy "ne tessék haragudni, szerveren az Xbox szarok és a többi Store mocsok mellett egy 130 KB-os telnet.exe nem fért volna el a fullos GUI-s telepítés esetén?" Tőlem a core és egyéb kiherélt SKU-kból nyugodtan kihagyhatnák...

--
trey @ gépház

Ügyes! :) Volt már erről kirohanásom.

A képmetsző is része, bassza szájba aki nem tette default-ra, külön kell telepíteni, valami "Desktop Expreience" feature a neve, jól eldugva a Features\User Interfaces and Infrastructure alatt.

Gondolom azt is csak reboot, szolgáltatásmenedzser, ITIL, ticketing rendszer, vérvétel, labor, kis- és nagy rutin, fénykép, ujjlenyomat stb. mellett, után lehet, ha éppen rebootra várunk.

--
trey @ gépház

Mindenki másnak ott a Windows + PrtScn. (Tudom, nem tud gombnyomásra téglalapot kivágni, miközben a "Linux" igen.)

Mondjuk azt nem értem, hogy miért a szerver konzolján akarod elkészíteni a screenshot-ot, amikor utána az elkészült file-t még le is kell hozd a kliensedre.
Egyszerűbb megcsinálni az admin kliensen helyben, amin mindig dolgozol... nem?

Üdv,
Marci

Sok mindentől függ. Például mi elég gyakran dolgozunk olyan szerverekkel, amik nincsenek hálózatra kapcsolva különböző okok miatt. Helyi konzol, monitor stb.

De ez megint mellékszál. A probléma az, hogy tele van haszontalan szarokkal a Windows (szerencsére a "horgászni mentem.jpg már a múlté), viszont aminek haszna lenne, az meg kínszenvedés sokszor előszedni.

--
trey @ gépház

Igen, Windows alatt másképp van kitalálva a frissítés/telepítés tranzakciókezelése: az ilyen események szépen sorbaállnak, és ha az előrébb lévőnek az az igénye, hogy rendszerinduláskor történjen meg ez vagy az, akkor a későbbi tranzakciók addig nem hajthatók végre, amíg ezek meg nem történtek.
Lehet, hogy fájl, registry, meg úgy bármi másféle függőség nincs az egyes telepítések/frissítések között, de ha ennek a vizsgálata nincs meg, sőt a függőségekről nem, vagy csak minimálisan kell tudnia egy telepítendő csomagnak, addig ez így fog maradni.

Másképp. Elég sok nem hülye ember munkaórája van benne - lehet, hogy több, mint amennyit te vagy én munkával töltöttünk eddig. És az azért nem kevés... Az, hogy a tervezés/implementáció során mire "lőttek" elsődlegesen, milyen tervezési elvek mentén (és miért) így csinálták meg - sok ismeret hiányzik nálad is meg nálam is - ezért mondom, hogy _másképp_, és nem azt, hogysz@rul.
Linux/Unix alatt is csilliom dolog van a Windows-hoz képest szuboptimálisan kitalálva, de ettől még nem anyázza az ember az adott OS-t.

Most írtál 3-4 mondatni foobar-t.

Értem én, hogy ez a felállás jó volt a '90-es években, de azért fejlődik ám a világ. Linux alatt is, a DragonFly alatt is, macOS alatt is korszerű fájlrendszert fejlesztenek.

Linux alatt használhatsz btrfs-t. Mindegyiknek megvan a snapshotolás előnye.... Nézd meg mondjuk a SLES-t, ahol a frissítés nem csak telepíthető a root fájlrendszeren, hanem revert-elhető is. Halad a világ előre.

Kérlek, a mai világban ez a "de hát 20 éve ezt sikerült" egy kicsit sovány már... Ez az egész felfogás, hogy basszuk újra a rendszert, mert megmozdult az egér, a Windows rákfenéje. Akár tetszik, akár nem.

--
trey @ gépház

Nem baj, hogy nem érted, illetve nem tudod, miért van így, legfeljebb az, hogy úgy tűnik, nem is akarod megérteni - pedig ez adja a kenyered egy részét, ha jól tévedek.
Bő húsz éve tolom az ipart, volt abban csilió egy dolog, amit "máshol máshogy van, itt miért ilyen sz@r" mondással lehetett volna illetnem (és pl. az AIX alatt az ODM meg is kapta ezt, meg a registry ibm módra benyögést tőlem- még valamikor az AIX 4.2 táján), aztán amikor megmagyarázták, hogy mi miért van úgy ahogy, akkor az esetek döntő többségében (vagy inkább mondhatnám azt, hogy elenyésző, mérési hiba szintű részében nem) kiderült, hogy nem hülyeség, csak ismerni kell, és akkor látszanak az előnyei is, nem csak a hátrányai.

Én is ezt szajkózom már elég régóta, hogy mindennek van előnye és hátránya is.
A Linux rendszer előnye, hogy nem kell újraindítani, a frissítés azonnal használható. Azonban ennek megvan az a nagy hátránya, hogy sokkal nehezebb a fejlesztése.
A Windows rendszernek meg ott van az előnye, hogy sokkal egyszerűbb fejleszteni.
Az egyiknél a felhasználók a haszonélvezők, a másiknál a fejlesztők.

Ha ennyire sz@rawindóz, akkor miért hasnzálod? Miért fogadod el munkaeszköznek? Miért nem mondod az ügyfeleknek, hogy b..ákmegawindózt, hasnzáljanak linuxot, mert azt a büdös életben nem kell újraindítani, az megy mint a doxa, te köszönödszépen, de nem kérsz ilyen fosch OS-ből, aminek a frissítési/telepítési dolgai ilyen gányláda módon vannak összerakva... :-P

De akkor visszatérve az eredeti felvetésre. Mi a ráknak kell egy nyomorult telnet.exe telepítéshez újraindítani a gépet, ha éppen függőben lévő frissítések vannak? Mi ez, ha nem egy szar megoldás?
Meg úgy általában, minek kell minden szarért újraindítani? Emlékeim szerint már ott tartunk, hogy menet közben akár kernelt is lehet 'peccselni'.

"Meg úgy általában, minek kell minden szarért újraindítani?"
Windows alatt a nyitott fileok lockolva vannak, ezért.
Ha egy file használatban van, mert mondjuk system service, csak akkor tudod kicserélni,ha leállítod a system service-t, kicseréled a file-t és elindítod a service-t.
Linuxon ilyen probléma nincs, nincs lockolva a file, ha használatban van, felülírható futás közben gond nélkül.

"Linuxon ilyen probléma nincs, nincs lockolva a file, ha használatban van, felülírható futás közben gond nélkül."
Azért azt tegyük hozzá, hogy ez előny is meg hátrány is. Tény, hogy ez miatt könnyen lehet frissíteni 1-1 dolgot, viszont ha ez épp egy security fix lenne, akkor a futó szolgáltatás addig ugyan úgy sebezhető marad amíg az nincs újra indítva (és minden cucca be van cache-elve a memóriába). Shared library-k esetén (ahol több szolgáltatás is használja ugyan azt a library-t egy időben) ez még "viccesebb", mert habár a Kernel live update-jére már léteznek módszerek (ahol a memóriában tárolt adatot is live patcheli), de azon felül másra nincs tudtommal.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Rossz a hasonlat. valamivel közelebb van az igazsághoz az, hogy ha fut egy masszívabb update, tudsz-e másik ablakban mc-t telepíteni?
Windows alatt van olyan frissítés, aminek a sikeres és tesztelt működése csak akkor garantálható, ha az a boot folyamat során véges bizonyos tevékenységeket. Ha ilyen van, akkor a frissítések/telepítések csak akkor zárulnak le, és csak akkor indulhat egy új frissítés/telepítés, ha az előző véget ért - azaz a boot-folyamat lezajlott.
Igen, lehetne kevesebb reboot-ot igénylő patch (erre törekszik egyébként a MIcrosoft, ezt azért gondolom észrevetted te is), viszont amíg van ilyen lehetőség, hogy a javítás települhet a jól definiált/tesztelhető boot-folyamat közben is, addig nem fogja a fejlesztő azt nézni, hogy élő, futó rendszeren hogyan lehet megoldani azt, hogy minden korrekten lefusson, és minden korrekten működjön utána. Pontosan jól látod: az olcsóbb fejlesztés/tesztelés miatt is van ez így - meg egy rakat egyéb dolog miatt is, de az messzire vezetne.

Sorban állnak a frissítésekhez meg a telepítéshez szükséges tranzakciók. Ha egy olyan frissítésed van, ami rendszerindításkor futó tevékenységet igényel, akkor az azt követő másik telepítés addig nem fog lefutni, amíg az előzőt nem végzett. És igen, lehetne függőséget vizsgálni, csak azt ne felejtsd el, hogy csiliom+1 telepítőformátum/csomagkészítő/gányoló iparos készít Windows-ra alkalmazásokat - és ezekre a Microsoft-nak nincs ráhatása olyan szinten, hogy kötelező érvényűen végigtolja (és végigteszteltesse!) az ilyen függőségkezelést. A "de házon belül miért nem?" - mert az a házon belül is lehet elég távol egymástól, és picivel messzebb vezetne fejlesztés/tesztelés/release vonalon, ha ezt a funkciót elkezdenék beépíteni a cuccaikba.
faék egyszerű a megoldás - viszont működik. Egy később jött igény kiszolgálását nem veri hókon egy korábban érkezett, csak azért, mert a korábban érkezett befejezéséhez újraindítás kell. Hogy miért kell egyáltalán reboot? Egy futó rendszer állapota nagyon nem jól definiált, a boot során viszont pontosan lehet tudni, hogy mi fut, mi, mit csinál.
A menet közbeni kernelfoltozásnál egy jól definiált szoftverkomponens jól ismert függőségekkel kerül lecserélésre - pontosabban a rá vonatkozó hivatkozások átvakarásra.

Értem én hogy én vagyok a b.lf.sz amiért _nem sikerült megértenem_ a témát. De ha már ennyire belemegyünk a dolgokba, akkor miért is kell hasonlítani egy UNIX*like Linuxot egy Windowshoz? Egyik alma másik körte nem ? Autós hasonlattal élve, a Dízelbe is tankolhatsz benzint, csak nem biztos hogy honorálja a motor és vica-versa. Pedig! mind a kettő autó! (OS) .. Mind1 is lapozzunk, úgyse értem! :)

( _ventura_ v | 2017. 09. 21., cs – 10:55 )

Mert kell neked flancolni windows telepitovel :D

putty.exe letolt, hasznal :P

Fedora 25, Thinkpad x220

( mrceeka v | 2017. 09. 21., cs – 11:20 )

Nem értem a meglepődést.
Úgy látszik, örök átka marad a Windows-nak, hogy a nyitott fájlokat lockolja, azt hiszem, itt is ez a root cause.
Emiatt egy frissítésnél is csak azelőtt tudja cserélni őket, mielőtt megnyitná.
Ez a mai állapotban rebootot jelent.
Az meg már nem vethető a rendszer szemére, hogy nem hajlandó az OS korábbi, többé nem létező állapota alapján elvégezni a telepítést.

"Aki üzemeltet éles rendszert, az tudja, hogy nem akkor indítjuk újra a gépet, amikor akarjuk, hanem amikor a karbantartási ablakra rábólint az ügyfél, a szolgáltatásmenedzser vagy az atyaúristen." - És ugyanez vonatkozik a change-ek elvégzésére is, nem?...

Üdv,
Marci

"Úgy látszik, örök átka marad a Windows-nak, hogy a nyitott fájlokat lockolja, azt hiszem, itt is ez a root cause."

Milyen nyitott fájl? Nem felül kellett volna írni, hanem odamásolni egy .cab vagy mit tudom én milyen fájlból. Egyszerű fájlkitömörítés.

'"Aki üzemeltet éles rendszert, az tudja, hogy nem akkor indítjuk újra a gépet, amikor akarjuk, hanem amikor a karbantartási ablakra rábólint az ügyfél, a szolgáltatásmenedzser vagy az atyaúristen." - És ugyanez vonatkozik a change-ek elvégzésére is, nem?...'

Szerződés kérdése, egyébként a válasz: nem

--
trey @ gépház

"Milyen nyitott fájl?" Az, amit a befejezetlen, reboot előtti frissítés még nem cserélt le, de fog.

"egyébként a válasz: nem" Pedig jóváhagyás nélküli change-ekből már sokkal több baj származott az én tapasztalataim szerint, mint jóváhagyás nélküli rebootból.

Üdv,
Marci

"Az, amit a befejezetlen, reboot előtti frissítés még nem cserélt le, de fog."

Semmi köze a telnet-hez, ami előtte nem létezett a rendszeren. Gelei jól megfogalmazta, egy tetves telnet-et kiszedhettek volna ebből a szar mechanizmusból. Szerintem meg egy tetves telnet-et gyárilag benne hagyhattak volna a Windows Server-ben.

Milyen jóváhagyást vársz? Nem igazán értem.

A szervert mi üzemeltetjük. Én adom ki a változásra a jóváhagyást. Egy telnet telepítése alapesetben nem érinti az ügyfél üzletmenetét. Bebaszna, ha érintené: mehet.

Egy reboot érinti az ügyfél üzletmenetét. Nem az explicit jóváhagyása kell a _reboot_-ra, hanem a visszajelzése, hogy most alkalmas neki egy reboot.

Az egyébként megvan, hogy Linuxon csont nélkül telepíthetek egy telnet-et (vagy akármit), ha előtte lecserélte az egész rendszert (beleértve akár a kernelt is) is a system updater? Akkor is ha esetleg kiírta, hogy a változások miatt célszerű lenne egy reboot?

--
trey @ gépház

Én desktop felhasználó vagyok, tapasztalatom (méginkább érzéseim) szerint a pending restart a leginstabilabb állapota a Windows-nak, nem jó abban tartani huzamosan, mert fura dolgok történnek.
Ettől még lehet ez Nálatok üzemeltetési best practice.

"Az egyébként megvan, hogy Linuxon csont nélkül telepíthetek egy telnet-et" - meg. (Hint: örök átka marad a Windows-nak, hogy a nyitott fájlokat lockolja)

Üdv,
Marci

Azért pending és nem instant mandatory, mert ráér. Még a "sárga" figyelmeztetést is odázni lehet 10 perc, 1 óra, 4 óra időközre, amit bármikor meghosszabbíthatsz a "Postpone" gombbal.

https://flic.kr/p/YHakNM

De itt nem is sárga állapot van, hanem zöld...

"(Hint: örök átka marad a Windows-nak, hogy a nyitott fájlokat lockolja)"

Maradhatunk volna ennyiben, a felesleges "hogyan üzemeltetsz" köröket megspórolva.

--
trey @ gépház

Nem érint érzékenyen, csak mellékszálnak/mellébeszélésnek gondolom. Az eredeti probléma az, hogy egy nevetséges fájlmásolás miatt reboot kell* Windows-on 2017-ben.

(* bizonyos esetben, lásd a címet)

Ja és ez nem is a szokásos sárga "reboot kell" üzenet. Zöld a Windows Update rész. Annyit ír tájékoztatásul, hogy majd valamit szarakodik még a következő reboot-nál. Nem azt, hogy most azonnal reboot kell. Három állapot szokott ilyenkor lenni:

- vörös - nem sikerült / nem tudtam frissíteni, rebootolj
- sárga - sikerült a frissítés / reboot kell majd még, légyszi
- a fenti zöld / majd valamikor rebootolj, mert néhány dolgot még meg kell akkor csinálni

Ez kurvára nem a siess, most! kategória.

--
trey @ gépház

Itt pont az a rész hiányzik, ami megállapítja, hogy a hal.dll (vagy mit tudom én mi) cseréjére várásnak semmi köze nincs egy tools.cab-ból (elnézést, hogy nem a pontos nevét használom, leszarom, hogy miből másolja) a system32-be másolásnak (nem, nem felülírás, másolás).

Számomra ez érthetetlen és elfogadhatatlan.

--
trey @ gépház

Erről eszembe jutott a közellenség :) (na jó, persze nem egy kategória a telnet telepítésével :) )

[the NSA team is watching satellite footage of a conversation between Dean and Brill on a rooftop]
Hicks: Can you get a feature scan and pattern matching on him?
Van: No, he's smart, he never looks up.
Jones: Why does he have to look up?
Fiedler: The satellite is 155 miles above the Earth. It can only look straight down.
Jones: That's a bit limited, isn't it?
Van: [Sarcastically] Well, maybe you should design a better one.
Jones: Maybe I will idiot.

A ccleaneres ügy amúgy téged igazol, jobb mindenből a beépítettet használni, minél fontosabb a feladatkör.

Az van, hogy a Microsoftnál külön van választva a role és a feature. A feature meg még két szint mélyre... Lehetne implementálni, hogy ami nem rendszerszintű változtatás (telnet.exe belepottyantása a system32-be, ha már nincs ott alapból), ahhoz nem hívjuk meg a ha_meg_nem_rebootoltal_rebootolj_mert_mind_meghalunk!!! hookot vagy akármit.

Baromi bonyolult lenne imho.

--
trey @ gépház

Szerintem abból az időből, amit a témára eddig ráfordítottál, bőven kifejleszthetted volna a BEALLITOK_ES_TELEPITEK_MINDENT_EGY_WINDOWS_SERVERRE_UGY_AHOGYAN_NEKEM_A_LEGJOBB_AZ_UZEMELTETESHEZ.BAT-ot. telnet, képmetsző, akármi. Aztán 1x futtatod, ahol üzemeltetsz. Nem?

Üdv,
Marci

Szerverekre az update-eket akkor szokás telepíteni, amikor annak a kijelölt időablaka van és utána (Windows esetén) újraindítjuk.

De remélem, közel a világ, amikor nem telepítünk update-et, hanem a lejárt szavatosságút eldobjuk és veszünk egy frisset.

Üdv,
Marci

Kukazni a Windowst ilyen kornyezetbol, mert masnak ugy latszik nem okoz gondot.

Esetleg virtualizalni mindent, plusz redundanssa tenni az egyes komponenseket, es akkor kulon-kulon lehet a gepeket frissiteni a teljes szolgaltatas kiesese nelkul.

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

nem azt mondtam, hogy kötelező, hanem hogy van rá lehetőség az ITILben. Hiszen az ITIL alapvetően csak egy risk management framework, és belefér, hogy ha tudatosan úgy döntünk, hogy annak a riskje, hogy egy apt-get install telnet gondot okoz, elég alacsony ahhoz, hogy routine change legyen, akkor lehet ezt tenni. Az, hogy a te melóhelyeden nem így döntöttek, az egy másik kérdés :)

Itt inkább a fordítottja van szerintem: Nem az van, hogy átgondolták, és nem engedélyezték, hanem szimplán nincs szabályozva (finom hangolva), és kb minden change köteles.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Nem biztos, sok mindentől függ ez. Pl nincs ilyen mélységű működő software leltár, a security meg emiatt sír, és így volt egyszerűbb. De kétségtelen tény, hogy az ITILt -- egyébként minden más metodikához hasonlóan -- szokás gondolkodás nélkül bevezetni, majd nyüsszügni, hogy nehézkes szar.

(Egyébként meg nem fordítottja, én is abból indultam ki, hogy a default change management processz az él, csak valaki leül routine change listát csinálni. ebbe belefér az is, hogy tudatosan nincs rajta, meg az is, hogy nem is gondolkodtak)

Mondjuk meg nalunk van emergency maintenance es lehetne irni a felhasznaloknak egy koremailt hogy bocsi sracok akkor most restart van.

Report szerveren(6 node) is siman nyomok restartot napkozben ha kell (amit amugy is nehez definialni mert AUS,US,JPN is hasznalja) szoval valakinek mindig munkaidoben lesz.

Ilyenkor megy egy koruzenet hogy viszlat fel ora mulva. Arra nincs penz,hogy legyen 6 masik szerverunk licencelve csak ezert ,hogy ne legyen kieses.

( lajos22 | 2017. 09. 21., cs – 14:55 )

A windows nem szerver oprendszer, még ha azt is írják rá. Soha nem is lesz belőle az.

--
openSUSE 42.2 x86_64

Vannak dolgok, amire tuti nem használnék windowst, de biztos van igény, amire pedig igen. Na most user kezelés jelenleg nem feladat nálam.
Az viszont nem hit kérdése, hogy egy frissítés miatt leállítani a rendszert, hetente, az nem járható út minden helyzetben.

--
openSUSE 42.2 x86_64

Ööööö, sztem sufni bt-nek pont mindegy, hogy néha újra van indítva, egy komolyabb cégnél, ahol sok kilences rendelkezésre állás kell, ott nem. Talán a google, facebook, stb az sufni bt szintű cég, hogy nem windows szervereket használ? Biztos nem a licencek ára miatt ;)

Miert nem akarod megerteni?
Feltetelezem te is eszrevetted mar, hogy minel tobb 9-est varnak el rendelkezesre allaskent, altalaban annal fukarabbul bannak a scheduled maintenance windowok kiosztasanal. Tehat a rendelkezesre allast valoban nem csokkenti a reboot, viszont a heti patch-kedd (es utana a restart) eleg komoly fogfajast tud okozni.

Minél több 9-es arendelkezésre állás, annál nagyobb a redundancia, és ott akármikor meg is halhat gép, van helyette automatikusan másik.

Szerinted a Facebook, a Google, és a többi nagy hogyan csinálja a nagy rendelkezésre állást? Eldobható gépekkel és nagy redundanciával. Itt újraindítás sincs. Leállítják a gépet, és 0-ról felhúznak egy újat. Le se szarják, ha leáll egy. Automatán elindul egy másik, ha kell.

Így van, a redundancia növelése növeli a rendelkezésre állást.
Viszont az újraindítások, a hardver hibák, a szoftver hibák, a karbantartások, ... meg csökkentik.
Minél nagyobb a redundancia, annál kisebb mértékben, de csökkentik.

1 gép esetén jelentősen, 2 gépnél már kevésbé jelentős, de ott is megvan az esélye, hogy a másik géppel is történik valami, illetve az 1 gépnek kell elvinnie a 2 gép terhét.
Még nagyobb redundancia és automatikus új gépek indításával ez a hatás eléggé elhanyagolhatóvá válik.

Sok esetben pl. nem elvárás a 99,99%-os rendelkezésre állás, de azért igény van rá. Ilyenkor 1 gép, 1 tartalék gép és megfelelő mentéssel rövid idő alatt beállítható az új gép hiba estén a régi helyére. 1-2 heti újraindítással viszont nagyon hamar el is lőjük azt az 53 percet.

"az újraindítások, a hardver hibák, a szoftver hibák, a karbantartások, ... meg csökkentik."

Kevered a tervezett és nem tervezett leállásokat. A tervezett (pl. újraindítás) jó architektúra esetén nem csökkent rendelkezésre állást, mert a szolgáltatás előbb átterhelhető máshová.

Üdv,
Marci

A tervezett (pl. újraindítás) jó architektúra esetén nem csökkent rendelkezésre állást, mert a szolgáltatás előbb átterhelhető máshová.

Én is ezt írtam, növeled a redundanciát, amivel nő a rendelkezésre állás és újraindítod a szervered, amivel csökken, az eredő 0, tehát nem csökken a rendelkezésre állásod a kettő együttes hatásától.

Alapvetoen egyetertunk; azonban ahhoz, hogy az "eredo 0 legyen", a restartok miatt nagyobb redundanciat kell biztositanod.
Emiatt nem fogom elfogadni, hogy "tokmindegy a reboot" (marci irta lentebb), mert ugyis olyan az architekturad. Igenis van koltsege annak, hogy rebootolgatni kell minden szarert.

Ahogy persicsb leírta.
Ahol magas az elvárt rendelkezésre állás, ott olyan az alkalmazás-architektúra, hogy nemhogy egy gép vagy egy rack, de nemritkán egy adatközpont elvesztése sem csökkenti a rendelkezésre állást. Ergo nem számít, újra kell-e egy gépet indítani.

Ajánlott olvasmány: https://docs.microsoft.com/en-us/aspnet/aspnet/overview/developing-apps…

Üdv,
Marci

( gabrielakos v | 2017. 09. 22., p – 17:28 )

és ha bemásolod akárhova majd belerakod a PATH-ba hogy el is tudd indítani?
újraindításig gondolom pont olyan jó lesz mint a felinstallált (LOL) telnet.exe
--
Gábriel Ákos