Fórumok
Sziasztok!
Szeretném megkérdezni, hogy akinek nagyobb Windows szerver infrastruktúrája van az eltudná mondani milyen módszerrel frissíti őket?
Azzal tisztában vagyok, hogy WSUS és GPO-val lehet szabályozni. Engem leginkább az a része érdekel, hogy használjátok-e az automatikus frissítés funkciót, automatikus újraindítás stb.
Én azt vallom, hogy éles szerverekre ne menjen automatikusan Windows frissítés. Viszont nagyon sok szerverünk van és nagyon elhúzódhat mire minden szerverre manuálisan végig megyünk.
Előre is köszönöm!
Hozzászólások
sub
szerintem erre nem fogsz kapni választ pont olyanoktól, akik idehaza üzemeltetnek nemzetközi multi méretű rendszereket
Ivanti DSM-et hasznalunk, kulso ceg allitja ossze hozza a package-eket. Vannak maintenance window policy-k (every week sunday, meg hasonlok) azok vannak rahuzva a Win Serverekre. Ezek foleg persze hotfixek, nagyobb funkciofrissitesre negyedevenkenti karbantartasi ablak van.
Azért vannak teszt szerverek. Ha nincsenek, akkor legyenek. Ha nem azonosak az élessel, akkor legyenek azonosak. Ha meg nem lehet mindezt, akkor marad a szopás.
https://iotguru.cloud
Vannak teszt szerverek. De azokat messze nem annyi ember használja. És nem is olyan széles skálán. Így ott sokkal később bukhat ki bármilyen hiba.
Canary deployment amit keresel szerintem.
Gábriel Ákos
Akkor legyen rajtuk terhelés és a terhelés legyen hasonló, mint az éles üzem. Különben valóban csak teszt szerverek vannak, értelmes teszt nélkül. Szóval ez egy ilyen műfaj, valahol fájni fog a dolog, másoknak se lesz ingyen varázsgömbjük, hogy jó lesz-e a frissítés, legyen beépítve a folyamatokba a folyamatosan bővülő tesztelés, mint szemlélet.
https://iotguru.cloud
Alapvetően egyetértek de ez pont nem egy jól tesztelhető történet.
Canary deploymentet gyors (és biztos) visszaállítási módszerrel javaslok.
Ez persze csak kiegészíti, nem helyettesíti az előzetes lehető legjob tesztelést. (ld fent)
Gábriel Ákos
A Canary deployment feltételezi azt, hogy több szerver szolgálja ki az igényeket és azt is, hogy van olyan eszköz a hálózatban, amivel valamilyen sticky-session elv mentén meg lehet mondani, hogy kinek melyik a szervere.
https://iotguru.cloud
sub
Én üzemeltetek nagy windows infrat (10k+ szerver), nem tudom nálad mekkoráról van szó.
Van automtikus frissítés de mivel kicsit nagyobb kontroll kell ezért natív WSUS és GPO már nem játszik. Legtöbb helyen Ivanti vagy MEMCM (SCCM) van.
Nálunk úgy néz ki, hogy egy CMDB-ben a server ownerek konfigurálják, mikor patchelődjenek a szerverek. Minden szervernek van egy pár órás work windowja ami minden héten ismétlődik, van egy beállítás, hogy rebootolhat-e a szerver vagy sem patch után, illetve, hogy melyik patch cycleben vesz részt.
Összesen 3 cycle van.
Dev ami rögtön patch tuesday után kezdődik (ez manuálisan történik a patchelő csapat által), QA ami patch tuesday péntekén és tart egy hétig és Prod ami a rákövetkező hét péntekén kezdődik.
Jellemzően úgy vannak felosztva, hogy a nonprod gépek QA cycleben kapják a patcheket, a PROD gépek meg QA és PROD cycleben. Ha HA-ban van az említett szerver akkor egyik node QA másik PROD (ha lehetséges) ha csak 1 server van és az PROD akkor az PROD cycle.
Ezen felül még ugye lokáció alapján szokták taglalni.
Az nem kérdés, hogy minden hónapban minden szervert meg kel patchelni a lehető leghamarabb, szóval én arról lebeszélnélek, hogy PROD gépeket nem patchelsz.
Akkor kb hasonlo a helyzet, mint nalunk. Nalunk azert kevesebb VM van (par szaz csak, max ezer.), de a logika kb ez. Annyi, hogy nalunk teljesen az IT planning allitja be az utemezeseket (elore egyeztetve a servert hasznalokkal)
Igen kell egy csapat aki ezt koorindálja, különben a szerver ownerek nem foglalkoznak vele. :)
A manuálisan mindenhol tolni egy frissítést erősen szuboptimális, pláne sok szerver/kevés admin esetében - ahogy az automatikus frissítés is rossz irány - igaz más okból.
Automatizált, de szabálybázis alapján végrehajtott (mi, hova, mikor mehet/megy ki) frissítésekre van sok megoldás, amik közül lehet válogatni (velem a ManageEngine jött több esetben szembe) - A kulimunkát (kattogtatás minden gépen 1234-szer) mindegyik le tudja venni az üzemeltetés válláról - a tesztelést és a "jó/nem jó" döntés kimondásának terhét nem. Épp ezért kell tesztkörnyezet, ahol gyakorlatilag minden úgy van ott, ahogy az élesben (UAT környezet), ahova ki lehet tolni első körben a frissítéseket, és ha azon a kulcsfelhasználók/alkalmazásgazdák szerint nincs gond, akkor lehet "megkattintani" az éles környezetek frissítését is. (Ez a két/több lépcsős frissítés kritikus sérülékenység esetében áthágható kell legyen!)
vagy (mint esetunkben) van egy kulsos ceg, aki osszeallitja a patch "csomagot" ami biztonsagosan kitolhato az adott infrastrukturaba.
Jaaaakérem, ahol van pénz a lóvéra... :-D :-D :-D
Reboot közben mi történik? Van, aki átveszi addig a szolgáltatásokat? Utána hogy működik a szinkronizálás, ez jelentős teljesítménykiesés?
Linux szervereknél is nagyjából hasonló sűrűséggel "kell" frissítés miatt újraindítani a szerverparkot, vagy ott meg lehet oldani ritkábban?
Ha reboot van, akkor "természetesen" az adott gép által nyújtott szolgáltatás kiesik a reboot idejére. Ha ez egy clusterezetten/több gépen elérhető szolgáltatás (pl. egy domain controller), akkor maximum a szolgáltatás performanciája esik vissza erre az időre.
Linuxon kernelfrissítéskor mindenképp reboot, bár a ksplice és hasonlók használata elvileg megoldják reboot nélkül, de volt olyan környezetem, ahol a ksplice bekapcs után khm. voltak stabilitásbeli problémák, úgyhogy ment a levesbe, szóval ez is olyan, hogy előbb tesztelni, aztán tesztelni, utána tesztelni, és ezt követően tesztelés után mehet élesbe :-)
Windows-on nem tudom, hogy van-e jelezve egy-egy patch esetén, hogy reboot-ot igényel-e vagy sem - Linuxon gyakorlatilag csak a kernelcsere az, ami explicit reboot-ot igényel, de szolgáltatáskiesést/degradációt nem csak a reboot okozhat - saját tapasztalat, hogy egy futó WildFly-os alkalmazásszerver "alatt" nem jó megfrissíteni a JDK-t, mert a wf képes tőle magába fordulni - és nem csak ilyen "bammeg"-ek voltak már a pályafutásom során (adott szolgáltatás a frissítést ugyan "túlélte", de később egy stop/start során a stop még ment, de a start nem - pont olyankor, amikor SOS-ben kellett volna újrarúgni...) , úgyhogy élesben én kifejezetten hasznosnak tartom a frissítést reboot-tal összekötni, bár tudom, hogy az uptime-fetisiszták ezért gyenge parázson pirítanának a Linux Desktop évének eljöveteléig :-)
Linux szerverknél amelyeket üzemeltetésében részt vettem ott managment cuccal frissítették és a restartot is azzal adták ki. Nem kellet minden gépre belépegetni és engedélyezni a restartott. Meg ütemezni is tudtunk restartott.
Sajnos a szolgáltatások nincsenek clusterben. Így ha újraindul az egyik szerver akkor szolgáltatás kiesés van. Ha clusterben lennének akkor eltolt ütemzéssel egy lépéssel beljebb lennék. Most csak WSUS áll rendelkezésünkre.
Hány gépről van szó?
Most kb 170. De esélyes, hogy késpbb több lesz.
Ha szeretnél nagyobb kontrollt a gépek felet akkor én scriptelnék és registryben lokálisan letárolnék dolgokat amik fontosak lehetnek a patcheléshez, vagy reboot managementhez.
Írsz egy kicsit az IT környezetről?
Van egy {Windows} infrastruktúra-szolgáltató csapat, a szerverekért és a rajtuk futó szolgáltatásokért pedig az adott projekt felelős, vagy minden egykézben van?
Ha jól értettem nincsenek dedikált DEV / NONPROD / PROD környezetek, vagy ha vannak is, utóbbi kettő nincs szinkronban.
PROD szerverek nem HA-ban vannak, ezeket egy dedikált maintenance window-ban szeretnétek frissíteni, vagy szükség van egyedi időzítésre?
Windows Update kell csak, Microsoft Update is vagy esetleges 3rd party szoftverek frissítése is a ti feladatotok?
Van policy arra, hogy a gépek mennyi időt kaphatnak a frissítések publikálása és a telepítés között?
Használtok valamilyen vulnerability scanner szolgáltatást?
A Windows-ok konfigurációja GPO alapon megy, vagy IaC-ot használtok?